Universidade Federal do Rio Grande do Norte Centro de Ciências Exatas e da Terra Departamento de Informática e Matemática Aplicada Programa de Pós-Graduação em Sistemas e Computação Uma Arquitetura de Referência para o Desenvolvimento de Sistemas Interativos Multiplataformas FABÍOLA MARIZ DA FONSECA Natal – RN Agosto de 2008 ii FABÍOLA MARIZ DA FONSECA UMA ARQUITETURA DE REFERÊNCIA PARA O DESENVOLVIMENTO DE SISTEMAS INTERATIVOS MULTIPLATAFORMAS Dissertação submetida ao Programa de Pós- Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como parte dos requisitos para obtenção do título de Mestre em Sistemas e Computação Orientador: Professor Dr. Jair Cavalcanti Leite, D.Sc. – UFRN Área de concentração: Engenharia de Software Natal – RN Agosto de 2008 iii Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial Especializada do Centro de Ciências Exatas e da Terra – CCET. FABÍOLA MARIZ DA FONSECA UMA ARQUITETURA DE REFERÊNCIA PARA O DESENVOLVIMENTO DE SISTEMAS INTERATIVOS MULTIPLATAFORMAS . Fonseca, Fabíola Mariz da. Uma arquitetura de referência para o desenvolvimento de sistemas interativos multiplataformas / Fabíola Mariz da Fonseca. – Natal, 2008. 82 f. : il. Orientador: Prof. Dr. Jair Cavalcanti Leite. Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. Programa de Pós-Graduação em Sistemas e Computação. 1. Engenharia de software - Dissertação. 2. Sistemas interativos multiplataformas - Dissertação. 3. IMML – Dissertação. 4. Solução arquitetural – Dissertação. I. Leite, Jair Cavalcanti. II. Título iv Esta Dissertação foi julgada adequada para a obtenção do título de mestre em Sistemas e Computação e aprovado em sua forma final pelo Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte. _________________________________________ Prof. Dr. Jair Cavalcanti Leite, D. Sc – UFRN Orientador _________________________________________ Profa. Dra. Thais Vasconcelos Batista, D.Sc – UFRN Coordenadora do Programa Banca Examinadora _________________________________________ Prof. Dr. Jair Cavalcanti Leite, D.Sc. – UFRN Presidente _______________________________________ Prof. Dr. Paulo de Figueiredo Pires, D.Sc. – UFRN _______________________________________ Profa. Dra. Maria Elizabeth Sucupira Furtado, D.Sc. – UNIFOR Natal – RN Agosto de 2008 v AGRADECIMENTOS Agradeço a toda a minha família pelo apoio, paciência, força e coragem, de forma especial, a minha mãe, Francisca do Socorro Mariz, pelo incentivo em todos os aspectos. Ao meu namorado, Rodrigo dos Santos Diniz, pelos momentos de incentivo e apoio incondicional, sem os quais não teria conseguido concluir este trabalho. Ao meu orientador, o professor Jair Cavalcanti Leite, pela paciência e orientação durante todo o processo de construção deste trabalho, tirando dúvidas e transmitindo conhecimentos que serão válidos durante toda a minha vida profissional. Ao colega Jackson, que me ajudou no desenvolvimento desse trabalho, implementando as soluções propostas. Aos meus amigos da pós-graduação e do grupo de trabalho do projeto GEDIG pelo grande apoio a realização desse trabalho, por todos os momentos de brincadeiras e descontração que também foram necessários durante todo esse período. Em fim, por todos aqueles que contribuíram direta ou indiretamente na realização desse trabalho. Muito obrigada! vi RESUMO É cada vez mais comum o uso de um mesmo sistema computacional utilizando diferentes dispositivos – computadores pessoais, telefones celulares e outros – e plataformas de software – sistemas de interfaces de usuário gráficas, sistemas WEB e outros. Dependendo das tecnologias envolvidas, arquiteturas de software distintas podem ser empregadas. Por exemplo, em sistemas WEB, utiliza-se uma arquitetura cliente-servidor – normalmente estendida em três camadas. Em sistemas com interfaces gráficas, é mais comum arquiteturas com o estilo MVC. A utilização de arquiteturas com diferentes estilos dificulta a interoperabilidade de sistemas com múltiplas plataformas. Um outro agravante é que muitas vezes, as interfaces de usuário em cada um dos dispositivos possuem estrutura, aparência e comportamentos diferentes em cada dispositivo, o que leva a uma baixa usabilidade. Por fim, as interfaces de usuário específicas para cada um dos dispositivos envolvidos, com características e tecnologias distintas é um trabalho que precisa ser realizado individualmente e não permite escalabilidade. Esse trabalho procura resolver alguns destes problemas apresentando uma arquitetura de referência independente de plataforma e que possibilita que a interface de usuário possa ser construída a partir de uma especificação abstrata descrita na linguagem de especificação de interface de usuário, a IMML. Esta solução visa oferecer uma maior interoperabilidade entre as diferentes plataformas, uma maior consistência entre as interfaces de usuário e maior flexibilidade e escalabilidade para a incorporação de novos dispositivos. Área de Concentração: Engenharia de Software Palavras-chaves: Sistemas interativos multiplataformas, IMML, solução arquitetural. vii ABSTRACT It is increasingly common use of a single computer system using different devices - personal computers, telephones cellular and others - and software platforms - systems graphical user interfaces, Web and other systems. Depending on the technologies involved, different software architectures may be employed. For example, in Web systems, it utilizes architecture client-server - usually extended in three layers. In systems with graphical interfaces, it is common architecture with the style MVC. The use of architectures with different styles hinders the interoperability of systems with multiple platforms. Another aggravating is that often the user interface in each of the devices have structure, appearance and behaviour different on each device, which leads to a low usability. Finally, the user interfaces specific to each of the devices involved, with distinct features and technologies is a job that needs to be done individually and not allow scalability. This study sought to address some of these problems by presenting a reference architecture platform-independent and that allows the user interface can be built from an abstract specification described in the language in the specification of the user interface, the MML. This solution is designed to offer greater interoperability between different platforms, greater consistency between the user interfaces and greater flexibility and scalability for the incorporation of new devices. Area of Concentration: Software Engineering. Key words: Systems interactive multi-platform, IMML and architectural solution. viii SUMÁRIO 1. Introdução ......................................................................................................................... 14 1.1. Motivação ...................................................................................................................... 14 1.2. Definição do Problema .................................................................................................. 15 1.3. Objetivos ........................................................................................................................ 17 2. Conceitos Básicos ............................................................................................................. 19 2.1 Arquitetura de Software .................................................................................................. 19 2.2 Estilos arquiteturais para sistemas interativos ........................................................... 22 2.2.1 MVC - Model-View-Controller .............................................................................. 22 2.2.2 PAC - Presentation-Abstraction-Control ............................................................... 23 2.3 Sistemas Interativos Multiplataforma ............................................................................. 24 2.4 Desenvolvimento de Interfaces de Usuários Baseada em Modelos................................ 26 2.5 Linguagens de descrição de interfaces de usuário. ......................................................... 28 3. Trabalhos Correlatos ......................................................................................................... 30 3.1 Arquitetura para Sistemas Interativos Multiplataformas ................................................ 30 3.2 Sistema de interface de usuário unificada baseada em XML ......................................... 32 3.3. Arquiteturas de Adaptação de Conteúdo ....................................................................... 32 4. A Aplicação da IMML em Sistemas Interativos Multiplaformas ..................................... 34 4.1 A IMML – Interactive Message Modeling Language .................................................... 37 4.1.1. Modelo de domínio (domain model) ..................................................................... 38 4.1.2. Modelo de Interação (interaction model) .............................................................. 39 4.1.3. Modelo de Comunicação (communication model) ................................................ 42 4.2. Modificações na IMML ................................................................................................. 45 4.3 Trabalhos relacionados à IMML ..................................................................................... 46 5. A Arquitetura de Referência ............................................................................................. 49 5.1 Visão Conceitual ............................................................................................................. 49 ix 5.1.1 Componente Cliente ............................................................................................... 52 5.1.2 Componente Servidor de Conexão ......................................................................... 52 5.1.3 Componentes Controlador e Repositório ................................................................ 53 5.1.4 Componente Servidor Funcional ............................................................................ 54 5.2 Visão de Módulo ............................................................................................................. 55 5.2.1 Descrevendo a Arquitetura para as Plataformas no Estilo de Interação GUI ......... 56 5.2.2. Descrevendo a arquitetura para Plataformas no Estilo de Interação WUI .................. 60 5.3 Aplicando a Solução Arquitetural em um Estudo de Caso ............................................. 62 5.3.1 Comportamento do Sistema .................................................................................... 62 6. Conclusão .......................................................................................................................... 73 REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................................... 78 ANEXO I .................................................................................................................................. 82 x LISTA DE FIGURAS Figura 2-1:Arquitetura como uma ponte (figura extraída de [Garlan, 2000]) .......................... 20 Figura 2-2: Estrutura do MVC .................................................................................................. 22 Figura 2-3: Estrutura do PAC ................................................................................................... 24 Figura 4-1: Objeto de Domínio Extrato .................................................................................... 38 Figura 4-2: Função de domínio "EmitirExtrato" ...................................................................... 39 Figura 4-3: Comando de Função para a função de domínio "EmitirExtrato" ........................... 40 Figura 4-4: Resultado de função "SaidaExtrato" ...................................................................... 41 Figura 4-5: Exceção da função ‘EmitirExtrato’ ........................................................................ 41 Figura 4-6: Tarefa "EmitirExtrato" ........................................................................................... 41 Figura 4-7: Painel de comando para a função de comando "Saldo" ......................................... 42 Figura 4-8:Área de exibição do resultado de função "SaidaSaldo" .......................................... 43 Figura 4-9: Área de exibição para os dados inválidos .............................................................. 43 Figura 4-10: Menu de tarefas do sistema 'BancoRico' .............................................................. 43 Figura 4-11: Unidades de interfaces para a tarefa ‘ConsultarSaldo’ ........................................ 44 Figura 4-12: Ambiente de tarefa para a plataforma "Desktop-gui" .......................................... 45 Figura 5-1: Visão Conceitual para Sistemas Interativos Multiplataformas .............................. 50 Figura 5-2: Estrutura em camadas ............................................................................................ 55 Figura 5-3: Interfaces da camada Cliente no estilo GUI ......................................................... 56 Figura 5-4: Interfaces da camada Conexão no estilo GUI ........................................................ 57 Figura 5-5: Interfaces da camada Controlador ......................................................................... 58 Figura 5-6: Interfaces dos módulos Repositórios ..................................................................... 59 Figura 5-7: Interfaces dos módulos Executor Funcional e Repositório de Dados .................... 60 Figura 5-9: Representação dos componentes Clientes e Servidor Conexão para plataformas WUI .......................................................................................................................................... 61 Figura 5-10: Diagrama de colaboração para a seqüência de abrir a tela inicial do sistema ..... 62 Figura 5-11: Seqüência de interação para a tarefa ‘Principal’ da aplicação ‘BancoRico’........ 64 Figura 5-12: Interface concreta para tarefa ‘Principal’ da aplicação ‘BancoRico’na plataforma Desktop_GUI ............................................................................................................................ 64 Figura 5-13: Diagrama de colaboração da seqüência para solicitação do saldo ....................... 65 Figura 5-14: Seqüência de interações para a tarefa saldo ......................................................... 66 Figura 5-15: Interface concreta para a tarefa ‘saldo’ da aplicação ‘BancoRico’ ...................... 67 xi Figura 5-16 : Interface concreta para a interação function-command da tarefa ‘saldo’............ 68 Figura 5-17: Diagrama de colaboração para a seqüência do resultado do saldo ...................... 69 Figura 5-18: Interface concreta para a interação function-result da tarefa ‘saldo’ ................... 70 Figura 5-19: Interface concreta para a interação function-exception da tarefa ‘saldo’ ............. 71 Figura 5-20: Comunicação entre cliente e servidor de conexão para as plataformas WUI. ..... 72 xii LISTA DE SIGLAS AIO Abstract Interaction Objects API Application Programming Interface AUIML Abstract User Interface Markup Language AUIT Adaptative User Interface Technology BRIDGE Interface Design Generator Environment CIO Concrete Interaction Objects CORBA Common Object Request Broker Architecture DBC Desenvolvimento Baseado em Componentes DIUBM Desenvolvimento de Interface de Usuário Baseado em Modelos DHTML Dinamic HTML GOMS Goals, Operators, Methods, and Selection rules GUI Graphics User Interface HTML HyperText Markup Language HTTP Hypertext Transfer Protocol HUI Handheld User Interface IHC Interação Humano - Computador IMML Interactive Message Modeling Language IU Interface de Usuário JDBC Java Database Connectivity LDIU Linguagem de Descrição de Interface de Usuário JSP JavaServer Page LEMD Linguagem de Especificação da Mensagem de Designer MVC Model-view-controller PAC Presentation-Abstraction-Control PDAs Personal Digital Assistant RMI Remote Method Invocation SBB Sistema Baseado em Browser SQL Structured Query Language UIML User Interface Markup Language UML Unified Modeling Language xiii URLs Uniform Resource Locator WAP Wireless Application Protocol WML Wireless Markup Language WUI Web-based User Interface W3C World Wide Web Consortium XICL eXtensinble User Interface Components Language XIML Extensible Interface Markup Language XML eXtensible Markup Language XUL XML User Interface Language 14 CAPÍTULO 1 1. Introdução Este capítulo introdutório mostra uma visão geral do trabalho, começando pelos fatores que motivaram a realização do mesmo, e seguindo com os problemas relevantes dentro do escopo de sistemas interativos multiplataformas que propomos solucionar. E, em seguida, descrevemos os objetivos para os quais este trabalho foi realizado. 1.1. Motivação A variedade dos dispositivos tecnológicos onde sistemas podem ser utilizados, como em celulares ou palmtops, oferece vantagens de praticidade e comodidade aos usuários que utilizarem os serviços que lhes sejam úteis. Digamos, por exemplo, que um cliente de um banco deseje efetuar um pagamento, mas no momento o único dispositivo que tenha acesso é o seu celular, e que este possua um navegador da WEB. Então, o problema do cliente seria resolvido se o sistema bancário permitisse efetuar a operação de pagamento pelo celular. Em outro momento, poderia ser que o cliente dispondo de um computador convencional (desktop) desejasse verificar o seu extrato. Nesse caso, a consulta poderia ser realizada se o sistema fosse desenvolvido para aplicações WEB, onde um navegador WEB para desktop pudesse ser utilizado para acessar o sistema. Ou então, se uma aplicação utilizando alguma API - Interface de Programação de Aplicação – fosse desenvolvida para acessar o sistema bancário. Um cenário que ilustra possibilidades interessantes é poder acessar e editar um mesmo arquivo de trabalho em casa, utilizando um computador de mesa, no carro através de um PDA (Personal Digital Assistant), ou numa reunião no escritório, utilizando uma tela de grande escala, com interação por controle remoto. Com o desejo dos usuários em usarem aplicativos em qualquer lugar e a partir de diferentes tipos de dispositivos computacionais, surge a necessidade de que aplicações sejam desenvolvidas para todos eles, independente de características de dispositivos de entrada/saída, de sistema operacional utilizado, de tecnologias para desenvolvimento das 15 aplicações, ou de forma de acesso à aplicação (seja acessando a aplicação via navegador da WEB, ou utilizando alguma API - Interface de Programação de Aplicação- de interface de usuário gráfica GUI). 1.2. Definição do Problema Diversos desafios precisam ser resolvidos para o desenvolvimento de sistemas que possam ser utilizados em vários tipos de dispositivos (por exemplo, celulares ou desktops) e plataformas operacionais (por exemplo, o sistema operacional utilizado, tecnologias utilizadas para desenvolvimento das aplicações, aplicativo utilizado para acessar o sistema ou linguagem de programação utilizada). Eles vão desde problemas de infraestrutura de comunicação até o desenvolvimento de interfaces de usuário (IU) para cada um dos diferentes tipos de dispositivos. As aplicações e os seus dados devem permitir acesso remoto e visualização por diferentes tipos de IU. Isto requer uma infraestrutura de rede com pontos de acesso os mais amplos possíveis. É necessária ainda uma arquitetura de sistema baseada em cliente-servidor de forma que a aplicação e os dados possam ser acessados a partir dos diversos clientes distribuídos geograficamente. O foco desse trabalho está nos desafios associados ao desenvolvimento de sistemas interativos, que possam ser utilizados em vários tipos de dispositivos e plataformas operacionais. Um dos principais desafios no desenvolvimento de sistemas interativos multiplataformas é a separação dos aspectos do sistema que são específicos de dispositivos e plataformas (por exemplo, tipos de elementos de interface, quantidade de telas apresentadas para a realização de uma função) daqueles que são comuns (funcionalidades das aplicações). Essa separação é importante para que clientes, em diferentes plataformas (utilizando vários dispositivos tecnológicos, com diferentes características de entrada e saída de dados, com diferentes sistemas operacionais e usando meios distintos de acesso à aplicação), possam utilizar, de maneira transparente, as mesmas funções do sistema, garantindo assim a característica de interoperabilidade. Outro desafio é a preservação de aspectos de usabilidade do sistema nas multiplataformas. A necessidade de que os sistemas atendam as expectativas dos usuários em relação à satisfação de uso, permitindo que eles possam realizar suas tarefas de forma satisfatória em qualquer dispositivo para a qual a aplicação seja desenvolvida nos vários estilos de interfaces de usuários, faz-se necessário que as interfaces de usuário para as diferentes plataformas considerem os aspectos de usabilidade. 16 Não faz sentido, por exemplo, que a interface para um sistema bancário tenha boa usabilidade em um sistema num computador tipo desktop, com uma interface gráfica (GUI) e uma péssima usabilidade em um celular, com acesso via WAP, com navegador para este protocolo. A principal característica de usabilidade que deve ser considerada para o desenvolvimento de interfaces de usuários múltiplas é a consistência, que se refere às interfaces que possuem diferentes look-and-feel manterem o mesmo comportamento nas diferentes plataformas [Seffah and Javahery, 2004]. Segundo Nielsen [1990], consistência é a garantia de que um mesmo comando ou ação tenha sempre a mesma estrutura e o mesmo efeito de forma que as interfaces não possuam convenções ambíguas. Ressaltando também que a forma de interação do usuário com o sistema deve ser a mesma para qualquer plataforma que execute o sistema. Um exemplo simples dessa consistência seria um sistema bancário que deve disponibilizar em todas as plataformas não apenas as mesmas funções – como, calcular saldo, emitir extrato e efetuar pagamento – mas também uma forma padronizada de interação. Para a execução de cada uma dessas funções, os mesmos dados devem ser requisitados e, em seguida, o resultado deve ser mostrado. Por exemplo, para a consulta do saldo, o sistema deve requisitar a agência, a conta e a senha do usuário, seguindo essa ordem, e em seguida deve exibir o nome do cliente, a data da emissão do saldo e o valor deste. O que vai diferir são os elementos de interfaces utilizados por cada plataforma de acordo o seu estilo de interface, como também a quantidade de telas necessárias para visualização dos elementos interativos. Para um desktop o resultado da função extrato cabe em uma única tela, enquanto em um celular é necessária a exibição de várias telas. Portanto, é trabalho dos desenvolvedores gerar interfaces de usuários finais para cada dispositivo (que utilizam diferentes plataformas operacionais) de forma que as interfaces sejam portáveis para as multiplataformas que devem interagir com o servidor da aplicação. Se o sistema for desenvolvido levando em consideração a consistência do diálogo das informações e o usuário souber usá-lo de forma correta em uma plataforma específica ele não terá dificuldade de usá-lo em outra plataforma e, conseqüentemente, diminuirá a probabilidade de ocorrência de erro. Portanto, os problemas que estamos considerando para o desenvolvimento de sistemas interativos multiplataformas resumem-se em definir uma organização do sistema de forma a separar os aspectos comuns a todos os dispositivos e plataformas (por exemplo, a funcionalidade do sistema acessado) dos aspectos específicos aos mesmos (por exemplo, a 17 forma de apresentação e interação com o sistema). Dessa forma, a organização do sistema deve considerar os aspectos de portabilidade, ou seja, a mesma estrutura do sistema deve ser usada nas diferentes plataformas, em que aspectos específicos de plataformas devem interagir com um mesmo servidor do sistema. Também é importante que as interfaces de usuários geradas pelos desenvolvedores sejam portáveis para diferentes plataformas. Evitando assim desenvolver diversas versões de uma mesma IU para cada uma das diferentes plataformas, pois isso requer que o desenvolvedor conheça cada uma das plataformas alvo e as diversas variações que cada uma delas possa requerer. 1.3. Objetivos Para o desenvolvimento de sistemas interativos que executem em múltiplos dispositivos e plataformas, muitos atributos de qualidade são envolvidos no processo e no produto. Este trabalho não tem por objetivo resolver todos os problemas relacionados ao desenvolvimento de sistemas interativos multiplataformas. A proposta é resolver os problemas descritos na seção anterior. O trabalho propõe o estilo de arquitetura que deve ser utilizado com o objetivo de oferecer uma referência para os desenvolvedores construir sistemas interativos multiplataformas, ou seja, propomos uma arquitetura de referência [Bass et al., 2003] que é uma arquitetura generalizada de diversos sistemas que compartilham um ou mais domínios comuns, nesse caso os domínios são os sistemas interativos que possam ser executados em multiplataformas. Essa arquitetura deve permitir que o sistema tenha características de portabilidade, interoperabilidade e usabilidade. Para garantir a portabilidade, a arquitetura deve ser organizada de maneira que permita que os sistemas possam ser utilizados em qualquer plataforma. Para satisfazer à interoperabilidade, a arquitetura deve possibilitar que os vários clientes, nas diferentes plataformas, utilizem o mesmo núcleo funcional do sistema, de forma transparente. E a característica de consistência das interações do usuário com o sistema (importante medida de usabilidade) pode ser obtida usando os modelos de especificação da IMML [Leite, 2007] na arquitetura proposta. A IMML é linguagem abstrata para especificação de interfaces de usuários. A utilização dessa linguagem aliada à arquitetura proposta possibilita organizar os sistemas, especificando as interações do usuário com o sistema de maneira independente de dispositivo e plataforma, como também descrever a organização das interfaces para cada plataforma de maneira abstrata seguindo um único 18 modelo de interação, ou seja, um único conjunto de interações é definido na IMML e deve ser utilizado para gerar as interfaces de usuários para as diferentes plataformas. Isso é possível por utilizar, na arquitetura, as especificações dos modelos de interação e de comunicação da IMML descritos no capítulo 4 aliado as regras de mapeamento definidas por [Sousa, 2004] e [Silva, 2007]. O nosso interesse é o desenvolvimento de sistemas interativos multiplataformas, onde estamos considerando como dispositivos computacionais os computadores convencionais (desktops) e celulares e como estilos de interfaces o GUI e WUI. Ou seja, as aplicações do sistema poderão ser acessadas através de computadores convencionais usando como plataforma de execução um navegador da WEB ou uma aplicação de interface gráfica GUI. Ou podem ser acessadas através de um celular usando como plataforma de execução um navegador da WEB para celular. A solução arquitetural proposta deve ser utilizada em sistemas interativos que possam ser acessados por clientes em vários dispositivos com diferentes tamanhos de telas, independente de sistemas operacionais, e que acessem a aplicação (núcleo funcional) do sistema através de um navegador WEB (para desktops ou celulares) ou usando aplicações de interfaces gráficas GUI. Este documento está organizado em 6 capítulos incluindo a introdução. O capítulo 2 descreve alguns conceitos básicos de forma a contextualizar o trabalho. No capítulo 3 constam os trabalhos relacionados encontrado nessa pesquisa. O quarto capítulo apresenta a linguagem IMML, incluindo as alterações feitas nessa linguagem. O capítulo 5 introduz a arquitetura de referência proposta. O último capítulo faz as considerações finais. 19 CAPÍTULO 2 2. Conceitos Básicos Este trabalho tem por objetivo definir uma arquitetura de referência, que é um padrão arquitetural específico de um domínio, que possa ser utilizada para o desenvolvimento de sistemas interativos multiplataformas capaz de tratar os problemas nos quais o desenvolvimento destes sistemas estão inseridos, conforme descrito na introdução. Para isso vamos esclarecer alguns conceitos necessários para entender a solução que será apresentada adiante. Inicialmente consideramos o design da arquitetura, englobando os estilos arquiteturais para sistemas interativos. Em seguida, descrevemos o que são sistemas interativos multiplataformas. Adiante, descrevemos as propostas de desenvolvimento baseadas em modelos. E, por fim vamos discutir as abordagens que propõem soluções baseadas em linguagens de descrição de interfaces de usuário (LDIU). 2.1 Arquitetura de Software Um aspecto necessário e complementar ao desenvolvimento de sistemas interativos multiplataformas é o modelo arquitetural empregado. Durante o desenvolvimento de sistemas, os projetistas fazem uso de uma arquitetura de software para estruturar o sistema em termos de seus componentes (entidades computacionais com funcionalidade específica). Tamanha importância dada à arquitetura é devida a alguns fatores, entre eles: a capacidade de diminuir os custos devido à característica de reusabilidade e características que facilitam o processo de manutenção e evolução dos sistemas [Garlan; Shaw, 1994]; [Garlan, 2000]. A principal contribuição em elaborar o design da arquitetura, em termos gerais, é diminuir o “gap” entre a especificação dos requisitos e a implementação do sistema em código fonte [Garlan, 2000]. A figura 2-1 mostra o momento em que esta se encontra. 20 A solução arquitetural proposta nesse trabalho deve ser utilizada com o objetivo de oferecer uma referência para os desenvolvedores construir sistemas interativos multiplataformas. No contexto aqui abordado a elaboração de uma arquitetura permite especificar como os sistemas interativos multiplataformas podem ser organizados de forma a incluir características de portabilidade, interoperabilidade e garantir as características presentes na especificação em IMML. Figura 2-1:Arquitetura como uma ponte (figura extraída de [Garlan, 2000]) Dentre as várias definições de arquitetura de software que existem na literatura, podemos dizer que elaborar arquitetura do sistema significa organizá-lo de maneira abstrata em componentes e conectores e definir a topologia, ou seja, mostrar como esses elementos estão relacionados uns com os outros [Garlan, 2000]. Garlan [2000] define componentes como blocos de alto nível que descrevem as partes da arquitetura que realizam algum tipo de computação e que armazenam algum dado do sistema. Cada componente possui uma funcionalidade bem definida, sendo assim capaz de oferecer modularidade e separação dos conceitos. Eles também publicam uma ou mais interfaces que constitui(em) sua identificação. As interfaces publicam as propriedades visíveis externamente, que possibilitam fazer a conexão entre os componentes. Neste trabalho, os componentes arquiteturais são definidos de forma conceitual, especificados de forma abstrata, servindo para auxiliar a construção dos sistemas interativos multiplataformas. Os componentes conhecem uns aos outros através das suas interfaces publicadas. Não constitui parte do componente a exibição da implementação, ou seja, eles são blocos abstratos que escondem completamente a implementação. 21 Os conectores descrevem as estruturas de comunicação entre os componentes estabelecendo restrições de como as mensagens fluem entre os componentes. Ex: chamadas de métodos ou procedimentos, protocolos de comunicação cliente-servidor. Na elaboração de uma arquitetura de software comumente são utilizados diferentes terminologias ou conceitos. Conceitos importantes são o de padrão arquitetural e estilo arquitetural. Eles são usados com o mesmo significado e servem para definir alguns aspectos como o mecanismo e o relacionamento entre os componentes, caracterizando uma família de sistemas que são relacionados pelo compartilhamento de propriedades estruturais e comportamentais (semântica) [Hofmeister et al., 2000]. Eles definem um vocabulário para os elementos da arquitetura: componentes e conectores. Além disso, apresentam regras e restrições sobre a combinação dos componentes arquiteturais, indicando como organizar os elementos de um sistema para solucionar problemas específicos em determinado contexto [Garlan; Shaw, 1994]. Exemplos de padrões arquiteturais são: camadas, pipes e filtros e o padrão model-view -controller (MVC). Outros termos comumente usados são: arquitetura de referência e arquitetura de software de domínio específico. Eles são utilizados com o mesmo significado. Da mesma forma que os padrões arquiteturais eles definem os tipos dos elementos arquiteturais e como eles podem ser relacionados, mas nesse caso eles são aplicados em um domínio de sistema particular definindo como as funcionalidades de um domínio de sistema são representadas em elementos arquiteturais, ou seja, em componentes e conectores [Hofmeister et al., 2000]. Uma arquitetura de referência ou arquitetura de software de domínio específico deve usar um conjunto de padrões arquiteturais na sua estrutura. Uma definição dada por [Bass et al., 2003] é que uma arquitetura de referência é uma arquitetura generalizada de diversos sistemas que compartilham um ou mais domínios comuns. Ela pode ser instanciada para criar uma arquitetura de software específico. Nesse trabalho a arquitetura de referência é a solução proposta para se construir sistemas interativos que possam ser utilizados em multiplataformas. Essa solução foi descrita utilizando as visões conceitual e de módulo [Hofmeister et al., 2000], que diferente do que propõe [Kruchten, 2000] não necessariamente deve ser totalmente instanciada, testada e descrita utilizando as visões 4+1. Ela deve auxiliar a construção de sistemas interativos multiplataformas indicando qual funcionalidade do sistema cada elemento arquitetural representa. 22 2.2 Estilos arquiteturais para sistemas interativos No contexto do desenvolvimento de sistemas interativos encontramos alguns padrões arquiteturais onde os mais conhecidos são: o MVC (Model-View-Controller) [Goldberg, 1984] e PAC (Presentation-Abstraction-Control) [Coutaz, 1987]. Essas soluções arquiteturais são para aplicações seguindo o estilo de interface de usuário GUI, não suportando o desenvolvimento de múltiplas interfaces de usuários. Diante do problema tratado, que é o desenvolvimento de sistemas interativos para multiplataformas, estamos usando o propósito básico desses estilos que é a separação da parte da apresentação da parte que contém os dados da aplicação, adicionando os aspectos de portabilidade e usabilidade. 2.2.1 MVC - Model-View-Controller O MVC divide as aplicações em três módulos: o model (responsável pela funcionalidade da aplicação), o view (que recebe, recupera e exibe dados) e o controller (que gerencia os eventos de entrada dos usuários, coordenando o model e o view). Desse modo ele desacopla os módulos do sistema, cada um com a sua responsabilidade. A estrutura desse padrão arquitetural permite que um único model possa se ligar a vários pares de controller – view, como mostra a figura 2-2. Figura 2-2: Estrutura do MVC O seu controle do fluxo ocorre da seguinte maneira: 1. O usuário interage com a interface de alguma forma (por exemplo, o usuário aperta um botão). 23 2. O Controller manipula o evento da interface do usuário através de uma rotina pré- escrita. 3. O Controller acessa o Model, possivelmente atualizando-o de maneira apropriada, baseado na interação do usuário (por exemplo, atualizando os dados de cadastro do usuário). 4. Algumas implementações de View utilizam o Model para gerar uma interface apropriada (por exemplo, mostrando na tela os dados que foram alterados juntamente com uma confirmação). O View obtém seus próprios dados do Model. O Model não toma conhecimento direto do View. 5. A interface do usuário espera por próximas interações, que iniciarão o ciclo novamente. 2.2.2 PAC - Presentation-Abstraction-Control O PAC é um estilo muito similar ao MVC. Ele é usado como uma estrutura hierárquica de agentes, cada um constituído de três partes: apresentação, abstração e controle. Essas partes se comunicam uma com a outra somente através da parte de controle de cada trio, conforme mostra a figura 2-3. Cada agente do PAC é formada por:  Apresentação – é exatamente como o view do MCV. Ele mostra as informações da abstração.  Abstração – contém os dados da aplicação e é responsável pela funcionalidade da aplicação, como o model do MVC, mas não tem o papel de notificar mudanças.  Controle – é similar ao controller do MVC. Ele é o responsável pelo controle do diálogo e por gerenciar o relacionamento entre os diferentes trios. Ele processa eventos externos e atualiza o modelo. Ele também atualiza diretamente a parte da apresentação. Ele é diferente do controller do MVC porque um componente PAC pode sofrer mudanças de outro componente PAC pai. 24 Figura 2-3: Estrutura do PAC A diferença entre o PAC e o MVC é que o PAC não tem o model como seu componente central, mas uma estrutura hierárquica de componentes PAC. A solução arquitetural proposta neste trabalho utiliza a proposta dos estilos descritos acima, que é a separação da parte da apresentação (Componente Cliente) da parte que contém os dados da aplicação (Componente Servidor Funcional), inserindo partes intermediárias (Componentes Controle e Repositório). Diante do problema que estamos tratando, que é o desenvolvimento de sistemas interativos para multiplataformas, estamos incluindo também a característica de portabilidade, considerando os vários tipos de dispositivos (Celular, Desktop, ou outros dispositivos móveis) e estilos de interfaces (GUI e WUI), onde o sistema poderá ser executado. 2.3 Sistemas Interativos Multiplataforma Com o surgimento cada vez maior de vários dispositivos computacionais, como por exemplo, telefones celulares e computadores de mão (palmtops), com diferentes características de tamanho da tela e formato do teclado, diversos termos surgiram para classificá-los. Os sistemas que podem ser usados em diversos dispositivos computacionais (por exemplo, desktops ou celulares), considerando os vários estilos de interfaces de usuários (por exemplo, GUI e WUI), são chamados de sistemas interativos multiplataformas. Seffah &Javahery [2004] apresentam uma proposta em três categorias: • Graphics User Interface (GUI): este estilo é o mais conhecido pela maioria dos usuários, normalmente usado nos desktops. Também é conhecido com WIMP (Windows, Icons, Menus and Pointers); 25 • Web-based User Interface (WUI): utilizado nas aplicações que têm como plataforma de execução um navegador WEB; este por sua vez é um software que segue o estilo GUI. • Handheld User Interface (HUI): estilo presente nos telefones móveis, nos assistentes digitais pessoais (PDAs) e em alguns terminais eletrônicos. O usuário interage através de gestos, usando caneta especial e/ou toque na tela. Para o desenvolvimento de sistemas interativos que possam ser acessados por clientes em vários dispositivos com diferentes tamanhos de telas, independente de sistemas operacionais, e que acessem a aplicação (núcleo funcional) do sistema através de um navegador WEB (para desktops ou celulares) ou usando aplicações de interfaces gráficas GUI, diversas tecnologias devem ser empregadas no desenvolvimento desses sistemas. Não é o foco deste trabalho o detalhamento dessas tecnologias, porém citamo-las como forma de inseri-las no contexto dos sistemas interativos multiplataformas. Para computadores desktop, aplicações que apresentem o sistema aos usuários seguindo o estilo de interface GUI, podem ser implementadas, por exemplo, usando a API do Java Swing, que possui classes para a construção de interfaces de janelas de forma totalmente independente de sistema operacional ou ambiente de janelas. Os seus componentes utilizados para construir objetos de interfaces só dependem da máquina virtual Java. A comunicação entre as aplicações dos clientes e os servidores funcionais pode ser feita, digamos, com a comunicação sockets, que é uma espécie de interface lógica utilizada pelo cliente para se conectar ao servidor. Para dispositivo desktop com o estilo de interface WUI, um browser baseado em HTML deve ser usado para apresentar o sistema aos usuários e acessar as funções do sistema através de algum servidor WEB usando o protocolo de comunicação HTTP. Para os dispositivos celulares no estilo de interface WUI, o sistema deve ser apresentado aos usuários através de browser baseado em WML que acessa as funções do sistema usando um servidor WEB através do protocolo WAP. As páginas geradas pelos servidores WEB podem ser implementadas usando a tecnologia JSP para gerar as páginas HTML ou WML, conforme o dispositivo. As funções do sistema podem ser implementadas usando a linguagem Java, por possuir a característica de portabilidade. E, dessa forma, todas as aplicações usando o Java Swing ou o JSP podem acessar as funções do sistema. Esses são exemplos de possíveis tecnologias que podem ser empregadas para o desenvolvimento de sistemas interativos multiplataformas. 26 O foco desta dissertação é desenvolver uma solução arquitetural de maneira conceitual que possibilite o uso dessas tecnologias nas plataformas citadas: desktop e celular nos estilos de interfaces GUI e WUI. É importante que a solução arquitetural utilize de especificações de interfaces de usuários, para que as interfaces finais de usuários sejam baseadas em especificações de interfaces abstratas e que possam ser construídas de forma dinâmica e independente de plataforma. Não faz parte desse trabalho a construção de interfaces multimodais [Coutaz, 1991], ou seja, interfaces capazes de processar vários tipos de entrada do usuário de uma maneira combinada permitindo que os usuários escolham o modo de interação. Também não estamos considerando a adaptação do conteúdo das interfaces de acordo com o contexto de uso, por exemplo, o conteúdo das interfaces variando conforme as características dos usuários. Nossa proposta é que os usuários possam acessar todas as funções do sistema em qualquer dispositivo ou plataforma, o que deve variar são os elementos de interfaces de acordo com o estilo de interação utilizado e a quantidade de telas necessárias para apresentar a seqüência das interações. 2.4 Desenvolvimento de Interfaces de Usuários Baseada em Modelos Uma das abordagens na qual a IMML esta baseada é o desenvolvimento de interface de usuário baseado em modelos (DIUBM). Este é um paradigma de desenvolvimento que usa um repositório central para armazenar uma descrição de todos os aspectos do projeto de uma interface. Este repositório central é chamado de modelo, que tipicamente contém informações sobre os objetos do domínio da aplicação, as características dos usuários, as tarefas que os usuários esperam realizar utilizando a interface, bem como a estrutura e o comportamento da própria interface [Puerta & Szkeley, 1994]. O trabalho de Puerta & Eisenstein [2001] define os modelos que compõem uma interface de usuário. Esses modelos são os seguintes: modelo de tarefa, modelo de domínio, modelo de usuário, modelo de apresentação e modelo de diálogo. Cada modelo apresenta aspectos específicos de uma interface, e cada um deles é classificado segundo a categoria de abstrato, que são todos aqueles independentes de plataformas e que são encontrados nos modelos de tarefas, domínio e usuário; e de concretos, que são todos aqueles que possuem características específicas de plataformas e que são encontrados nos modelos de apresentação e diálogo. 27 O DIUBM propõe o mapeamento entre os modelos abstratos, independente de dispositivos, e concretos, específicos de dispositivos, e a partir deste mapeamento são derivadas as IUs executáveis. O mapeamento pode ocorrer de forma automática, semi- automática ou manual. Exemplos de mapeamentos entre estes modelos são: tarefa-diálogo, tarefa-apresentação, domínio-apresentação, tarefa-usuário, tarefa-domínio, apresentação- diálogo. Outra abordagem para o DIUBM é o Framework de Referência Camaleon (Calvary et al., 2003), que propõe que o desenvolvimento de IU multiplataforma seja feito em quatro etapas. Em cada etapa são tratados modelos em um nível de abstração diferente. Os níveis de abstração são: • Tarefas e conceitos: neste nível são descritas as tarefas a serem executadas e os conceitos relacionados ao domínio da aplicação. • IU abstrata: define o agrupamento de tarefas e o relacionamento semântico entre as mesmas. Neste nível são usados objetos de interação abstratos (AIO), os quais são independentes de mecanismos de interação, ou seja, não importa se o usuário vai fornecer um dado através de um teclado ou de um comando de voz. • IU concreta: neste nível os objetos de interação concreta (CIO) são dependentes do contexto de uso. Uma IU concreta descreve se o usuário vai inserir um dado através de uma caixa de seleção ou através de uma caixa de texto. • IU final: é uma IU que pode ser executada em uma plataforma computacional, por exemplo, uma IU que pode ser executada em um navegador WEB. A solução aqui apresentada segue a idéia de desenvolvimento baseado em modelos, uma vez que as descrições das interfaces, descritas em IMML, estão armazenadas em repositórios. Esses modelos são utilizados para gerar a interface de usuário final dinamicamente. Como veremos em mais detalhes no capítulo 4, na IMML, as IUs são descritas em três modelos: de domínio, de interação e de comunicação. Em relação aos níveis de abstração, o modelo de domínio especifica os conceitos da aplicação, o modelo de interação especifica as interfaces abstratas e o modelo de comunicação especifica as interfaces concretas. Os modelos de domínio e de interação são independentes de plataforma, já o modelo de comunicação possibilita a descrição dos aspectos com que a IU deve comunicar a funcionalidade ao usuário, de forma dependente da plataforma em que a IU será utilizada. O modelo de comunicação não é utilizado para descrever aspectos de implementação na plataforma alvo, 28 mas com este modelo o designer pode definir melhor os aspectos de interatividade entre os usuários e a IU na plataforma alvo. Em relação aos sistemas baseados em modelos, usa-se representações genéricas abstratas das interfaces em linguagens de descrição de interfaces de usuário (LDIU), descritas na próxima seção, para tentar produzir automaticamente modelos de interfaces concretas através de um mapeamento dos elementos abstratos (AIO) em elementos concretos da interface (CIO). 2.5 Linguagens de descrição de interfaces de usuário. Para o desenvolvimento de interfaces de usuários considerando os vários estilos de interfaces, ou seja, de interfaces de usuários multiplataformas, comumente são utilizadas as linguagens de descrição de interfaces de usuários (LDIU). Neste trabalho a LDIU utilizada para especificar os aspectos funcionais, interativos e comunicativos de interfaces de usuário para múltiplataformas é a IMML, descrita no capítulo 4. Uma LDIU (Linguagem de Descrição de Interfaces de Usuários) é uma das formas mais utilizadas para descrever aspectos interativos de interfaces de usuários. Elas oferecem um suporte para a descrição de interfaces de usuário segundo o DIUBM. É através destas linguagens que o designer descreve os modelos que compõem uma IU. A partir destas descrições, podem ser geradas interfaces de usuário finais, através do mapeamento entre modelos. Segundo Trewin et al. [2003], inúmeras propostas de LDIU surgiram nos últimos anos, principalmente pela necessidade de desenvolver interfaces de usuários para múltiplas plataformas e dispositivos. Usando uma LDIU é possível descrever diferentes aspectos de uma interface do usuário de forma abstrata e independente de plataforma ou dispositivo. Ela é composta por uma sintaxe, que define os termos e a gramática da linguagem, e uma semântica, que define o significado e as relações entre os termos [Souchon e Vamderconckt, 2003]. A maioria das LDIUs são linguagens de marcação baseadas em XML (eXtensible Markup Language) [Bray et al., 1998], que é um padrão recomendado pelo W3C, bem estabelecido e extensível, que pode trabalhar com novas plataformas sem muitas mudanças. Essas linguagens são especialmente adequadas para a especificação de interfaces independentes de dispositivos, plataformas e contexto de uso. Segundo Trewin el al. [2003], existe atualmente uma grande variedade de linguagens com vários propósitos e que descrevem a interface em diferentes níveis de abstração. São exemplos de LDIUs: UIML 29 [Abrams; Phanouriou, 1999], XIML [Puerta; Eisenstein, 2001], Tesesa XML [Mori, 2003], AUIL [Siebelink, 2000] e XUL [XUL, 2001]. 30 CAPÍTULO 3 3. Trabalhos Correlatos A heterogeneidade dos dispositivos e plataformas operacionais impõe desafios para o desenvolvimento de aplicações, dos quais podemos citar os seguintes: a descrição, independente de dispositivo e plataforma, da interface com usuário; e o desenvolvimento de aplicações multiplataformas. Diversos trabalhos foram propostos para solucionar cada um desses desafios. Contudo, não foi encontrada na literatura nenhuma abordagem arquitetural que auxiliasse o desenvolvimento de sistemas que pudessem ser utilizados em plataformas seguindo o estilo de interface WUI e GUI e que permitisse a geração automática de interfaces de usuários para as multiplataformas utilizando uma descrição da interface e dos seus dados, de forma que essa descrição seja independente de um dispositivo específico ou de uma plataforma de programação. Neste capítulo são citados alguns trabalhos que estão relacionados com o desenvolvimento de sistemas interativos para multiplataformas. Todos eles propõem soluções arquiteturais para múltiplos dispositivos, contudo somente para aplicações desenvolvidas para WEB. E nenhum deles, inclui como parte da solução a vantagem da utilização de uma linguagem de especificação de interface de usuário juntamente com a arquitetura. 3.1 Arquitetura para Sistemas Interativos Multiplataformas Grundy & Zou, [2004] apresentam uma arquitetura de sistema composta por quatro camadas. Essa arquitetura é para aplicações WEB considerando os diferentes tipos de usuários e tarefas específicas. As camadas da arquitetura são: 1. Dispositivos dos clientes: acessam o sistema através de dispositivos móveis, utilizando browsers baseados em WML, e/ou através de laptops ou desktops executando browsers em HTML. Esses dispositivos usam serviços dos servidores WEB, através de protocolos HTTP ou WAP. 31 2. Servidores WEB oferecem os serviços utilizados pela WEB. Eles requisitam serviços, usando o protocolo Java RMI dos Servidores de aplicação. 3. Servidores de aplicação executam o interpretador Java beans. Este encapsula a lógica do negócio e realiza o processamento dos dados, acesssando as funções da aplicação, através da interface CORBA e protocolos XML, e acessando os serviços do servidor de banco de dados, através de protocolos SQL ou JDBC. 4. Funções da aplicação oferecem as funcionalidades da aplicação. 5. Servidor de banco de dados oferece os dados necessários para a realização das funções. Esse trabalho propõe o uso da tecnologia AUIT – Adaptative User Interface Technology – para representar as páginas geradas pelos servidores WEB. As páginas em AUIT são implementadas em JSPs contendo uma linguagem de marcação independente de dispositivos, que geram páginas HTML e WML, com descrições de elementos da tela organizados em layouts. Essas descrições são representadas usando tags da XML, organizando os elementos de telas em layouts de acordo com os papéis dos usuários e tarefas dos usuários. As descrições das interfaces AUIT contêm aspectos comuns às linguagens de especificação baseada em modelos por especificar elementos da tela, o layout, o usuário e suas tarefas. Os elementos arquiteturais definidos nessa arquitetura se assemelham aos elementos arquiteturais propostos nesse trabalho. As principais diferenças apresentadas são: Ela não possui em sua estrutura um elemento responsável em controlar as interações do usuário com o sistema, não é aplicada para o desenvolvimento de sistemas seguindo o estilo de interface GUI, e embora utilize a tecnologia AUIT para representar aspectos de interfaces de usuários, ela não usa as vantagens de uma linguagem de descrição de interface de usuários. 32 3.2 Sistema de interface de usuário unificada baseada em XML Outro trabalho, descrito em [CHI-HSING; CHIEN-HSUAN; LEE, 2000], apresenta uma arquitetura para o desenvolvimento de aplicações para internet. A arquitetura é projetada para prover diferentes visualizações de dados e serviços contidos em um servidor WEB, permitindo o acesso a esses serviços por diferentes clientes (e.g., PCs, PDAs). A arquitetura, intitulada de XML-Based Unified User Interface System, é dividida em três camadas: a cliente, que possui um navegador com suporte a linguagens de marcação WEB (e.g., XHTML); a middlelayer, que contém a lógica de programação; e a camada de dados na qual estão as bases de dados legadas ou os bancos de dados. A arquitetura é proposta para ser desenvolvida utilizando J2EE [J2EE, 2008], tecnologia Java para servidores. A arquitetura sugere que a interface das aplicações seja descrita também em XML e que conversores devem ser escritos para mapear essa descrição em uma linguagem de marcação aceita pelos navegadores dos computadores ou dos PDAs (e.g., XHTML, WML). Esse trabalho apresenta como trabalhos futuros o desenvolvimento de uma linguagem para descrever as aplicações e a construção de conversores para linguagens de marcação (e.g., HTML, WML). Esse trabalho não utiliza uma linguagem de especificação de interfaces como parte da solução, embora sugira a descrição das aplicações em XML. A sua idéia também envolve conversores que converta documentos XML para interfaces finais de usuários, mas somente para o estilo de interface WUI. 3.3. Arquiteturas de Adaptação de Conteúdo Alguns trabalhos como em [HAGIMONT; LAYAÏDA, 2002], [CASTRO; LOUREIRO, 2004] e [LEMLOUMA; LAYAIDA, 2004], são descritas arquiteturas de sistemas considerando as vantagens de utilizar adaptação de conteúdo. Esses trabalhos apresentam propostas de soluções arquiteturais para os casos de sistemas poderem ser acessados por dispositivos móveis e computadores desktops, usando navegadores da WEB. Eles têm como foco a adaptação do conteúdo de acordo com os dispositivos. Para eles, o conteúdo deve ser cuidadosamente selecionado e adaptado às condições restritivas do equipamento de destino (e.g. dimensões do display, quantidade de cores, memória disponível). Esses trabalhos enfatizam que o mesmo conteúdo direcionado para um computador fixo (i.e. desktop) não deve ser enviado a um celular, por exemplo. Nesse caso, 33 tanto deve haver redução das informações, como modificação da forma de apresentação dos dados. A adaptação de conteúdo não, necessariamente, baseia-se somente nas características dos dispositivos que acessam as informações. As preferências e o contexto do usuário que utiliza a aplicação também podem ser relevantes nessa adaptação. A nossa solução arquitetural proposta não esta considerando a adaptação do conteúdo para cada plataforma. Aqui, as mesmas informações (funcionalidades e interações) devem ser apresentadas em todos os dispositivos em todas as plataformas, o que deve mudar são os elementos de interfaces utilizados e a quantidade de telas para apresentar as funções do sistema. 34 CAPÍTULO 4 4. A Aplicação da IMML em Sistemas Interativos Multiplaformas As diferentes partes de um software podem ter propósitos distintos. Uma clássica separação, já discutida na seção anterior. A solução que propomos segue a proposta de separação de partes de um software em seus aspectos funcionais, interativos e comunicativos [Leite, 2007]. Nessa visão, a especificação do software deve separar esses aspectos em diferentes modelos. O modelo funcional especifica os requisitos funcionais, representado às tarefas que o desinger considera que o usuário quer realizar com a aplicação. Um exemplo de requisito funcional é consultar um extrato de conta corrente num sistema bancário ou fazer a reserva de um quarto de hotel. O modelo de interação descreve as regras e protocolos pelos quais os usuários interagem com o sistema. Ela deve estar adequada às capacidades físicas e cognitivas dos usuários e aos recursos tecnológicos dos sistemas, permitindo a estes serem atraentes, proporcionando uma boa interação com o usuário. Por exemplo, para a funcionalidade de consultar o extrato bancário, o especialista em IHC deve especificar de que forma o usuário vai acessar a consulta ao seu extrato, como vai fornecer os dados de entrada e de saída. As decisões envolvem se o usuário vai digitar comandos, escolher opções de um menu ou preencher dados de um formulário. A interatividade refere-se à forma como o designer pretende que o usuário utilize a aplicação para realizar as tarefas. O modelo de comunicação descreve os aspectos de comunicabilidade. A comunicabilidade refere-se à maneira como o designer comunica os aspectos de funcionalidade e interatividade [Leite, 2005]. A comunicabilidade do sistema bancário será satisfatória, por exemplo, se os elementos utilizados na interface conseguem informar ao usuário que existe a possibilidade de fazer consulta ao extrato e quais são as ações para ele 35 escolher essa função e fornecer os dados necessários. A comunicabilidade é um conceito baseado na teoria da engenharia semiótica de Souza [2005], que considera o sistema computacional um artefato de meta-comunicação, que conduz uma mensagem unidirecional do designer ao usuário. A separação dos conceitos de funcionalidade, interatividade e comunicabilidade traz alguns benefícios para o desenvolvimento de software. Alguns destes benefícios já foram discutidos por Leite [2007]. No presente trabalho, tratamos dos benefícios que esta separação de conceitos traz para o desenvolvimento de sistemas que precisam executar em múltiplataformas. Para descrever os modelos, precisamos de uma linguagem de propósito específico. A IMML [Leite, 2005] é uma Linguagem de Descrição de Interface de Usuário (LDIU) abstrata baseada na abordagem de Desenvolvimento de IU Baseado em Modelos (DIUBM) [Puerta; Szkeley, 1994] e na teoria Engenharia Semiótica [De Souza, 1993]. No capítulo de conceitos básicos já explicamos a abordagem do DIUBM. A teoria da Engenharia Semiótica é uma abordagem na qual os sistemas computacionais são vistos como artefatos de meta- comunicação. Nessa abordagem, a interface de um sistema é vista como sendo uma mensagem enviada pelo designer ao usuário [De Souza, 1993]. A Engenharia Semiótica considera que a mensagem do designer para o usuário descreve os aspectos de funcionalidade, interatividade e comunicabilidade. A IMML permite representar a funcionalidade, interatividade e comunicabilidade dos sistemas interativos em seus modelos constituintes. Esses modelos foram criados para fornecer um maior controle em níveis diferentes de abstração, possibilitando o mapeamento entre os mesmos. No modelo de domínio é descrita a funcionalidade da interface, no modelo de interação é feita a descrição do processo de interação entre usuário e o sistema. No modelo de comunicação é descrito de que forma o designer quer comunicar para o usuário sobre o que foi definido nos modelos anteriores, ou seja, como serão apresentados as funcionalidades, os comandos e os resultados. O modelo de comunicação, desenvolvido por Costa Neto [2005], descreve o que foi especificado nos demais modelos – de domínio e de interação – mapeando as soluções específicas para cada plataforma de aplicação. Dessa forma, pode-se gerar diferentes interfaces de usuários concretas a partir das descrições de cada modelo de interação para plataformas específicas. Ou seja, um único conjunto de interações é definido e as interfaces concretas para as multiplataformas (especificadas no modelo de comunicação) são baseadas nesse conjunto de interações. 36 A proposta de Costa Neto [2005] foi implementada em Sousa [2004]. Nesta, um compilador faz a tradução das descrições da interface em IMML e gera código em DHTML para os dispositivos celular e desktop. Embora a IMML permita a especificação levando em consideração esta separação de conceitos, ela não indica como o sistema deve ser desenvolvido e como os diferentes aspectos podem ser preservados durante a implementação, isto é, se o produto final está completamente de acordo com a especificação IMML. A separação dos conceitos da IMML já é um caminho importante em busca da solução para este problema. De uma maneira geral, ela indica como o sistema precisa preservar esta separação conceitual em seus componentes constituintes. A incorporação da linguagem de especificação de interface de usuário, a IMML, na solução arquitetural proposta, permite que as interfaces de usuários sejam descritas em vários níveis de abstração mantendo o mesmo processo de interação usuário-sistema nas multiplataformas. Dessa forma, o que se espera é que as interfaces finais de usuários, construídas com base nas interfaces abstratas, possuam consistência comportamental nas multiplataformas. A solução hora apresentada tem como base a separação dos conceitos representados pela IMML. A arquitetura proposta utiliza especificações em IMML, especificamente os modelos de interação e de comunicação, que ficam armazenadas em repositórios, para que as interfaces de usuários finais sejam construídas baseadas nas interfaces abstratas especificadas em IMML. Dessa forma, o elemento arquitetural Controlador, descrito no capítulo 5, utiliza as interações (definidas no modelo de interação) e interfaces concretas (definidas no modelo de comunicação) para gerenciar todo o fluxo de entrada e saída dos dados apresentados nas telas para os usuários. Em Costa Neto [2005], foi apresentado o uso da IMML de maneira satisfatória para o desenvolvimento de IU multiplataformas. Neste foi apresentado o modelo de comunicação da linguagem que define interfaces concretas específicas de dispositivos utilizando os elementos interativos especificados no modelo de interação. Embora a IMML permita especificar características importantes de sistemas interativos e para múltiplas plataformas, ela não é suficiente para implementação dos sistemas, e só consegue elaborar protótipos de interfaces de usuários sem funcionalidades reais, como demonstra os trabalhos de Silva [2007] e de Sousa [2004]. É necessário incluir o design da arquitetura no processo de desenvolvimento de sistemas possibilitando descrever 37 características mais específicas que tornem a modelagem mais próxima da implementação do sistema. Esse capítulo apresenta um resumo da linguagem IMML, já descrita em trabalhos anteriores [Costa Neto, 2005], [Sousa, 2004], [Machado, 2006], [Lira, 2006] e [Silva, 2007] mostrando os seus modelos constituintes e como eles podem ser utilizados no desenvolvimento de sistemas interativos multiplataformas. Algumas alterações na IMML, feita nesse trabalho, também são descritas aqui, justificando-as. 4.1 A IMML – Interactive Message Modeling Language A IMML é uma linguagem baseada na XML - Extensible Markup Language [Bray et al., 1998]. Ela originou-se de um aprimoramento da LEMD (Linguagem de Especificação da Mensagem de Designer) [Leite, 1998] que passou por uma série de transformações em sua sintaxe com o aperfeiçoamento, adaptação e surgimento de novos termos e conceitos. A gramática da IMML foi escrita em XML Schema para facilitar o processamento por ferramentas de desenvolvimento de IU [Costa Neto, 2005]. A solução arquitetural proposta nesse trabalho, tem como base a separação dos aspectos definidos na IMML. A principal vantagem em usar os modelos da IMML na arquitetura, além de permitir a separação dos conceitos, é poder construir interfaces de usuários finais, com funcionalidades reais, baseada nas interfaces abstratas e concretas definidas pelos modelos de interação e de comunicação. No presente trabalho, algumas alterações na IMML foram realizadas com a finalidade de incluir dois aspectos importantes: o tratamento de exceções que possam ocorrer durante a execução dos sistemas e a composição das interfaces, de forma que para cada ação realizada pelo usuário o sistema forneça uma interface formada por um conjunto de outras tarefas, ou seja, para cada interação do usuário com o sistema, este mostre um conjunto de outras interações que possam ser realizadas. Essas alterações resultaram em mudanças nos três modelos da IMML. A seguir, está descrito, brevemente, cada um desses modelos, indicando a inclusão dos novos elementos. Mais detalhes de cada modelo podem ser encontrados em outros trabalhos como, por exemplo, em [Costa Neto, 2005]. Os exemplos descritos a seguir foram extraídos de um estudo de caso um sistema bancário fictício, chamado “Banco Rico”. Este sistema possui quatro funcionalidades básicas: consultar saldo, emitir extrato, efetuar pagamento simples e efetuar pagamento com consulta de saldo. Esse sistema já foi descrito usando cenários descritivos e especificado em IMML em trabalhos anteriores – Fonseca [2005], Lira [2006] e Costa Neto [2005] –, utilizado como 38 exemplo exploratório no próprio desenvolvimento da IMML. Os cenários descritivos são mostrados no anexo I deste trabalho. A especificação completa em IMML feita com base nos cenários descritivos foi originalmente descrita por Costa Neto [2005], e está reproduzida em [http://www.ppgsc.ufrn.br/~fabiola/BancoRicoIMML.xml]. 4.1.1. Modelo de domínio (domain model) O modelo de domínio (domain model) determina a funcionalidade do sistema, ou seja, aquilo que um sistema permite fazer através dos objetos e funções de domínio. Os objetos do domínio (domain-objects) se referem a registros de banco de dados, arquivos, mensagens eletrônicas, e vários outros objetos que os usuários possam conhecer em seu domínio. Eles são representados em um sistema computacional como estrutura de dados no nível de programação e como texto, ícones ou widgets no nível de interface. Para especificar cada objeto de domínio, o designer deve determinar o nome do objeto e o tipo de representação. Alguns objetos são formados a partir de outros. A figura 4-1 exibe um objeto de domínio (domain-object) que define para o sistema bancário um objeto composto chamado “Extrato”. Este objeto “Extrato” é formado por dois outros objetos de domínio: transação e saldo. Cada item utilizado para formar objeto “Extrato” deve ser declarado como elemento . As figuras apresentadas a seguir não descrevem a sintaxe da linguagem. Elas mostram trechos de um exemplo, um sistema bancário fictício, que já foi descrito em outros trabalhos. Figura 4-1: Objeto de Domínio Extrato As funções do domínio (domain-function) referem-se aos processos executados pelo computador que mudam o estado de um objeto do domínio. Do ponto de vista do usuário, é um serviço computacional que realiza um caso de uso. Uma função do domínio deve definir os operandos (input-operands e output-operands) (objetos do domínio), exceções (exceptions), pré-condições (pre-conditions), pós-condições (pos-conditions), controle de execução (controls) e estado da execução (states). A figura 4-2 exibe a função de domínio “EmitirExtrato”. Os operandos de entrada (linhas 3 a 7) da função são: “Conta”, “Agencia”, 39 “Senha”, “DataInicio” e “DataFim”. O operando de saída (linha 10) é o objeto “Extrato”. A exceção (linha 13) indica que um dado de entrada incorreto foi fornecido pelo usuário. Os estados (linhas 20 a 22) são: “inicial”, “consultando” e “final”. A função tem dois controles (linhas 16 e 17): o primeiro controle é o “consultar”, e faz uma transição do estado “inicial” para o estado “consultando”; o segundo controle faz uma transição do estado “consultando” para o estado “final”. Neste último a transição é feita de forma automática, após o processamento da função que faz a consulta do extrato. A descrição de uma pré-condição é feita como um texto em linguagem natural. Este texto deve ser lido pelo desenvolvedor para auxiliá-lo no processo de implementação da função. Na solução arquitetural proposta, foi definido um elemento arquitetural, Servidor Funcional, descrito no próximo capítulo, com a mesma função do modelo de domínio. Ele deve possibilitar a execução das funções definidas no modelo de domínio, incluindo os objetos de domínio especificados nesse esse modelo. Figura 4-2: Função de domínio "EmitirExtrato" 4.1.2. Modelo de Interação (interaction model) O modelo de interação representa o processo de interação entre o usuário e a aplicação. Define as ações executadas pelo usuário para comandar funções do domínio. Os elementos básicos deste modelo são: tarefas (tasks), comandos de função (function- commands), resultados de função (function-results), exceções de funções (function- exceptions), interações básicas e estruturas de interação. Uma interação básica refere-se a 40 determinada interação do usuário com a interface através de uma ação, como clicar num botão, selecionar um elemento em uma lista, digitar um texto ou número e visualizar um resultado. As estruturas de interação são as responsáveis por organizar os comandos e resultados de função dentro de uma tarefa, e as interações básicas dentro dos comandos e resultados de função. As estruturas podem estar aninhadas com outras estruturas. Um comando de função é usado para inserir informação e para controlar a execução de funções do domínio. Ele permite ao usuário o controle da execução da função. É importante informar que cada comando de função deve estar associado com uma função de domínio. Uma função de domínio pode estar associada a vários comandos de função. Já um comando de função é uma composição de um conjunto de interações básicas de forma estruturada, onde uma interação básica se refere a uma ação do usuário ao interagir com um widget de interface. A figura 4-3 exibe o comando de função (function-command) para a função de domínio (domain-function) “EmitirExtrato”. Os elementos de interação básica estão estruturados como select, sequence, e join. Existe um elemento