169. Carlos Alberto Batista de Queiroz Filho
Transcrição
169. Carlos Alberto Batista de Queiroz Filho
UNIVERSIDADE FEDERAL DO CEARÁ CENTRO DE CIÊNCIAS DEPARTAMENTO DE COMPUTAÇÃO MESTRADO E DOUTORADO EM CIÊNCIAS DA COMPUTAÇÃO CARLOS ALBERTO BATISTA DE QUEIROZ FILHO UM MECANISMO DE TRATAMENTO DE EXCEÇÕES SENSÍVEL AO CONTEXTO PARA SISTEMAS UBÍQUOS ORIENTADOS A TAREFAS FORTALEZA, CEARÁ 2012 CARLOS ALBERTO BATISTA DE QUEIROZ FILHO UM MECANISMO DE TRATAMENTO DE EXCEÇÕES SENSÍVEL AO CONTEXTO PARA SISTEMAS UBÍQUOS ORIENTADOS A TAREFAS Dissertação submetida à Coordenação do Programa de Pós-Graduação em Ciências da Computação da Universidade Federal do Ceará, como requisito parcial para a obtenção do grau de Mestre em Ciência da Computação. Área de concentração: Engenharia de Software Orientadora: Profa. Dra. Rossana Maria de Castro Andrade Co-Orientador: Prof. Lincoln Sousa Rocha FORTALEZA, CEARÁ 2012 Aos meus Pais, minhas irmãs e a minha esposa Juliana. AGRADECIMENTOS Em primeiro lugar, agradeço a Deus por ter me garantido a vida e os meios para que eu conseguisse chegar até a realização deste trabalho. Agradeço à minha mãe, mulher de amor e força, que tanto me educou e demonstrou como vencer dificuldades. Ao meu pai, por suas preocupações. Às minhas lindas irmãs Ana Paula, Debora e Larissa, pelo carinho, paciência e torcida incondicionais. Agradeço a minha amada esposa Juliana, por sua compreensão, companheirismo e incentivo. Por acreditar que o mundo pode ser melhor e mostrar-me que todo trabalho deve ser feito em prol disso. Agradeço também a minha orientadora professora Rossana, pelo incentivo à formação acadêmica, pelas várias oportunidades de crescimento profissional, pelas suas conversas, revisões, palavras de incentivo e por todo o suporte dado nos momentos mais difíceis. Por proporcionar um ambiente agradável, produtivo e com todo aparato necessário para o desenvolvimento desta pesquisa e de muitas outras que virão. Ao amigo e coorientador professor Lincoln Rocha, que muito colaborou desde a concepção da ideia deste trabalho. Por ajudar na minha formação e amadurecimento acadêmico. Pela parceria durante todos esses semestres de pesquisa. Ao amigo Francisco Fabrício, por sua ajuda com o SysSU, que foi essencial para as implementações realizadas no decorrer desta pesquisa. Aos meus familiares da calçada de domingo a noite, a minha segunda família Nogueira-Avelar, aos amigos do GREat, aos amigos PGR, aos amigos do CEFET, por me proporcionarem momentos de alegria que sempre “recarregaram minhas baterias” durante o mestrado. Aos companheiros do projeto GREat/SoMC, pelo incentivo e compreensão nas horas em que tive que dedicar mais tempo ao mestrado. Agradeço a CAPES/PROPAG, pelo suporte financeiro que foi essencial para manter o meu foco e dedicação voltados a esta pesquisa. Por último, agradeço ao GREat, ao MDCC e a Universidade Federal do Ceará, pelo espaço de aprendizagem e fomento ao crescimento acadêmico e profissional. “Não existe nenhuma regra útil sem uma exceção.” (Thomas Fuller) RESUMO O principal propósito da Computação Ubíqua é o fornecimento de informações e funcionalidades necessárias para ajudar as pessoas em suas tarefas cotidianas, de maneira proativa e transparente, a qualquer instante e em qualquer lugar. O desenvolvimento de sistemas ubíquos envolve um conjunto de requisitos desafiadores, dentre eles: sensibilidade ao contexto, que permite que os sistemas adaptem o seu comportamento para responder de forma apropriada diante de mudanças do ambiente; e dependabilidade, que está relacionado à capacidade dos sistemas de prestarem um serviço os quais ofereçam fortes indícios de que são confiáveis. Em relação aos atributos de dependabilidade, negligenciá-los pode trazer desde pequenas insatisfações até graves riscos à integridade física dos usuários. O tratamento de exceções é uma das principais técnicas de tolerância a faltas empregadas no desenvolvimento de software para atingir maiores níveis de dependabilidade. Essa técnica, apesar de já ser amplamente utilizada no desenvolvimento de software tradicional, ainda é pouco empregada no desenvolvimento de sistemas ubíquos. Isso ocorre em virtude das características e requisitos desafiadores desse tipo de sistema, dentre os quais se destacam a sensibilidade ao contexto e a distribuição, a qual pode fazer com que as possibilidades necessárias de tratamento de exceções de um sistema como um todo seja maior do que a soma das possibilidades de tratamento de exceções das partes que o compõe. Portanto, essa dissertação tem como objetivo propor um mecanismo de tratamento de exceções sensível ao contexto para sistemas ubíquos orientados a tarefas. O mecanismo proposto é disponibilizado através de um framework, denominado FRonTES, que permite a reutilização do mecanismo. Através da utilização desse framework, funcionalidades do sistema podem ser implementadas sob uma abstração de tarefa, que responde de maneira adequada a mudanças de contexto, detectando e tratando situações excepcionais. Para a validação do mecanismo proposto foi implementado um protótipo de sistema de controle de estacionamento ubíquo como uma prova de conceito, que foca na demonstração de como são implementadas as tarefas que compõem esse sistema e como são definidas as exceções contextuais e seus tratadores. Palavras-chave: Tratamento de Exceções. Sistemas Ubíquos. Sensibilidade ao contexto. Sistemas orientados a tarefas. ABSTRACT The main purpose of Ubiquitous Computing is to provide information and functionalities needed to help people in their daily activities, in a proactive and invisible way, anytime and everywhere. The development of ubiquitous systems involves a set of challenging requirements, including: context-awareness, which enables systems to adapt their behavior to appropriately respond to environmental changes, and dependability, which is related to the systems ability of providing a service that offers strong indications that can be reliable. Regarding the attributes of dependability, neglecting them can bring from small grievances to serious risks to the physical integrity of the users. Exception handling is one of the major fault tolerance techniques employed in software development to achieve greater levels of dependability. This technique, despite has already been widely used in traditional software development, is still not vastly used in the development of ubiquitous systems. This is due to the challenging characteristics and requirements of this type of system, among which is important to highlight the contextawareness and distribution, which can make the necessary exceptional handling possibilities of a system as a whole greater than the sum of the exceptional handling possibilities of the parts that compose it. Therefore, this dissertation aims to propose a mechanism for contextaware exceptional handling for task oriented ubiquitous systems. The proposed mechanism is available through a framework, called FRonTES, which allows its reuse. By using this framework, functionalities of a system can be implemented on a task abstraction, which responds appropriately to changes in context, detecting and handling exceptional situations. A prototype of a ubiquitous parking control system was implemented to validate the proposed mechanism. That proof of concept focuses on the demonstration of how the tasks that compose this system are implemented and how the contextual exceptions and their handlers are defined. Keywords: Exception Handling. Ubiquitous Systems. Context-awareness. Task-oriented systems. LISTA DE FIGURAS Figura 2.1 Gráfico retratando três eras da computação moderna. Figurada adaptada de (KRUMM, 2009). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Figura 2.2 Arquitetura de referência do SysSU (LIMA et al., 2011). . . . . . . . . . . . . . . . . . 27 Figura 2.3 Arquitetura abstrata em camadas de Loke (2009). Figura adaptada de (LOKE, 2009). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Figura 2.4 Árvore da dependabilidade. Figura adaptada de (AVIZIENIS; LAPRIE; RANDELL, 2004). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Figura 2.5 Componente tolerante a faltas ideal. Figura adaptada de (GARCIA et al., 2001). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Figura 3.1 Hierarquia de processos de um Exlet (ADAMS et al., 2007). . . . . . . . . . . . . . . 40 Figura 3.2 Abstrações do CAMA, adaptado de (ARIEF; ILIASOV; ROMANOVSKY, 2006). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Figura 3.3 Visão geral da arquitetura (RANGANATHAN; CAMPBELL, 2005). Figura 3.4 Cenário com diferentes escopos (DAMASCENO et al., 2006a). . . . . . . 43 . . . . . . . . . . . 44 Figura 3.5 Arquitetura para tratamento de exceções sensível ao contexto (DAMASCENO, 2006). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Figura 3.6 Visão geral da organização da proposta de (KULKARNI; TRIPATHI, 2010). 48 Figura 4.1 Diagrama de componentes com uma visão geral da arquitetura do framework. 57 Figura 4.2 Diagrama de sequência ilustrando o funcionamento da detecção de exceções contextuais a partir da invalidação de contextos. . . . . . . . . . . . . . . . . . . . . . . . . . 62 Figura 4.3 Diagrama de sequência ilustrando o funcionamento da detecção de exceções contextuais globais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Figura 4.4 Diagrama de sequência ilustrando o fluxo de tratamento de uma exceção contextual lançada a partir da detecção de um contexto indesejado. . . . . . . . . 66 Figura 4.5 Diagrama de sequência ilustrando o fluxo de tratamento de uma exceção contextual global. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Figura 5.1 Imagens do sistema SFPark (SFMTA, 2012). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Figura 5.2 Organização dos agentes no protótipo desenvolvido como prova de conceito. Figura 5.3 Imagens do Protótipo do UbiParking. 76 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Figura A.1 Diagrama de classes simplificado do FRonTES. . . . . . . . . . . . . . . . . . . . . . . . . . 95 LISTA DE ALGORITMOS 5.1 Trecho de código com a criação do primeiro passo da tarefa ParkingTask. . . . . . 77 5.2 Trecho de código com a criação do terceiro passo da tarefa ParkingTask. . . . . . . 78 5.3 Trecho de código com a instanciação da tarefa ParkingTask. . . . . . . . . . . . . . . . . 78 5.4 Trecho de código especificando uma exceção contextual para o terceiro passo da tarefa ParkingTask. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.5 Trecho de código especificando o tratamento para exceções contextuais globais. . 80 LISTA DE TABELAS Tabela 2.1 Comparação entre algumas definições de Computação Ubíqua. Tabela adaptada de (JEON et al., 2007, tradução nossa). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Tabela 3.1 Comparativo entre os trabalhos relacionados e os principais requisitos explorados nesta dissertação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Tabela 6.1 Comparativo entre os trabalhos relacionados e os principais requisitos explorados nesta dissertação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 LISTA DE ABREVIATURAS E SIGLAS API Application Programming Interface CAMA Context-Aware Mobile Agents FRonTES Framework para o Desenvolvimento de Software Ubíquo com suporte ao Tratamento de Exceção Sensível ao Contexto GREat Grupo de Redes de Computadores, Engenharia de Software e Sistemas MDBT Modelo de Desenvolvimento Baseado em Tarefas MoCA Mobile Collaboration Architecture PoC Proof-of-Concept SysSU Sistema de Suporte para Computação Ubíqua SUMÁRIO 1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.1 Contextualização e Caracterização do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.3 Objetivos e Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.4 Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1 Computação Ubíqua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.1 Principais Características e Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.1.2 Sistema de Suporte para Computação Ubíqua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.1.3 Modelo de Desenvolvimento Baseado em Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2 Dependabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2.1 Atributos da dependabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.2.2 Ameaças a dependabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.2.3 Meios para atingir a dependabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3 Tratamento de Exceções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.1 Principais Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.3.2 Tratamento de Exceções Sensível ao Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.1 Exlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2 CAMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.3 Task Execution Framework for Autonomic Ubiquitous Computing . . . . . . . . . . . . 42 3.4 Tratamento de Exceções com o MoCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.5 Situation-Based Exception Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.6 Tratamento de Exceções em Active Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.7 Tratamento de Exceções para Service Component Architecture . . . . . . . . . . . . . . 50 3.8 Verificação de Modelos para o Tratamento de Exceções Sensível ao Contexto . 51 3.9 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.10 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4 FRAMEWORK E MECANISMO PROPOSTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.1 Visão geral da proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.2 FRonTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.3 Mecanismo de Tratamento de Exceções Sensível ao Contexto . . . . . . . . . . . . . . . 59 4.3.1 Detecção de Exceções Contextuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.3.1.1 Detecção de Exceções Contextuais Locais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.3.1.2 Detecção de Exceções Contextuais Globais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.3.2 Propagação de Exceções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.3.3 Tratamento Sensível ao Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.3.3.1 Tratamento de Exceções Contextuais Locais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.3.3.2 Tratamento de Exceções Contextuais Globais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5 PROVA DE CONCEITO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.1 Estudo de Caso versus Prova de Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.2 Descrição do Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.2.1 Aplicação Motivadora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.2.2 Delimitação do Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2.3 Organização da Prova de Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.3 UbiParking: Instanciação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.3.1 Criação da Tarefa ParkingTask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.3.2 Definição do Tratamento de Exceções Contextuais . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6 CONCLUSÃO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.1 Resultados Alcançados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 6.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 REFERÊNCIAS BIBLIOGRÁFICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 APÊNDICE A -- DIAGRAMA DE CLASSES DO FRONTES . . . . . . . . . . . . . . . . . . . . . . . 95 14 1 INTRODUÇÃO Esta dissertação propõe um mecanismo de tratamento de exceções sensível ao contexto como principal contribuição. Além disso, é proposto o FRonTES, um framework que incorpora esse mecanismo para o desenvolvimento de sistemas ubíquos orientados a tarefas. Este capítulo introduz, na seção 1.1, uma visão geral sobre a computação ubíqua e problemas relacionados a esse tema. Em seguida, na seção 1.2 é apresentada a motivação para o desenvolvimento deste trabalho. A seção 1.3 expõe os principais objetivos desta dissertação. Por fim, na seção 1.4 é descrita a organização desta dissertação. 1.1 Contextualização e Caracterização do Problema A contínua evolução das tecnologias relacionadas à Computação Móvel, como o aumento da capacidade de armazenamento, processamento e comunicação dos dispositivos, permitiu tornar realidade a Computação Ubíqua vislumbrada por Mark Weiser (WEISER, 1991). Esse paradigma de computação fundamenta-se em prover informações e processamento, a qualquer instante e em todo lugar, com o objetivo de auxiliar as pessoas em suas atividades cotidianas de forma transparente e proativa (KINDBERG; FOX, 2002)(WEISER, 1991). Entretanto, o desenvolvimento de sistemas ubíquos não é trivial e envolve um conjunto de requisitos desafiadores, tais como: sensibilidade ao contexto, adaptabilidade, autonomicidade, mobilidade, descoberta de serviços, dentre outros (MAIA; ROCHA; ANDRADE, 2009)(ABOWD, 1999)(SATYANARAYANAN, 2001)(COSTA; YAMIN; GEYER, 2008). Diversas pesquisas já propuseram soluções importantes de frameworks (KULKARNI; TRIPATHI, 2010; ENDRES; BUTZ; MACWILLIAMS, 2005; VO; TORABI; LOKE, 2010; SOUSA; GARLAN, 2002), middlewares (VITERBO et al., 2008; ROMáN et al., 2002; JAROUCHEH; LIU; SMITH, 2009; EDWARDS et al., 2007; ROCHA et al., 2007) e infraestruturas de software diversas (LIMA et al., 2011; ROMAN et al., 2003) em busca de mitigar aspectos complexos do desenvolvimento de sistemas ubíquos. Entretanto, essas soluções apesar de permitirem aos engenheiros de software abstraírem da implementação aspectos de mais baixo nível, como por exemplo, a comunicação assíncrona e distribuída, para se preocuparem apenas com as funcionalidades do domínio específico das aplicações, elas não oferecem abstrações para lidar com a implementação dessas funcionalidades específicas. Apesar desses trabalhos terem proporcionado direcionamentos e contribuições importantes relacionadas ao desenvolvimento de sistemas ubíquos, uma outra visão sobre a forma de se construir esses sistemas surge com o modelo de desenvolvimento baseado em tarefas (MDBT) (WANG; GARLAN, 2000). O uso do MDBT favorece o desenvolvimento de sistemas ubíquos, uma vez que permite a construção de sistemas complexos através do mapeamento dos objetivos dos usuários, representados pelas tarefas, para serviços disponíveis no ambiente (LOKE, 2009)(GARLAN et al., 2002)(SOUSA et al., 2006)(HUANG et al., 2008). Em consequência dessa estratégia de reutilização de serviços para construção de sistemas ubíquos, esse modelo possibilita maior rapidez (ROMAN et al., 2003) e menor complexidade no desenvolvimento desse tipo de 15 sistema (LOKE, 2009). Outra característica importante do MDBT é a capacidade, fortemente relacionada à computação ubíqua, de execução de tarefas de forma automática e transparente através de gatilhos baseados em informações de contexto (VO; TORABI; LOKE, 2010). A característica de proatividade, inerente nos sistemas ubíquos, torna possível a construção de sistemas capazes de automaticamente tomar decisões e executar atividades que antes eram realizadas somente por seres humanos. Essa propriedade de proatividade desse tipo de sistema traz oportunidades relacionadas a novos tipos de aplicações e novas formas de interação entre seres humanos e computadores. Contudo, essa possibilidade também traz preocupações relacionadas ao grau de confiabilidade esperado desses sistemas. Falhas em sistemas ubíquos podem causar desde pequenos inconvenientes aos usuários até colocar a vida de pessoas em risco (CHETAN; RANGANATHAN; CAMPBELL, 2005). Em consequência disso, é possível perceber-se a importância de um outro requisito para esse tipo de sistema: a dependabilidade1 . Dependabilidade, conceitualmente, é a propriedade que define a capacidade dos sistemas computacionais de prestar um serviço em que se possa justificadamente confiar, oferecendo fortes indícios de que são confiáveis (AVIZIENIS et al., 2004). Com isso, ao focar nesse requisito, a atividade de desenvolver sistemas ubíquos torna-se ainda mais complexa (FETZER; HöGSTEDT, 2003)(ROCHA; ANDRADE, 2012). 1.2 Motivação Qualquer sistema computacional, incluindo os ubíquos, estão cada vez mais presentes em diferentes situações do cotidiano das pessoas. Nas mais diversas atividades pessoas fazem uso ou estão sujeitas a ação dos mesmos, às vezes até inconscientemente, dos quais se espera sempre o funcionamento adequado. Entretanto, eles são passíveis de sofrer com diferentes tipos de problemas e tornarem-se propensos a falhar. Falhas em sistemas computacionais podem ocorrer por diferentes causas, por exemplo, desde problemas com origem física (de hardware) até problemas causados por um mau design de software. A presença de diversos tipos de sistemas computacionais no dia-a-dia das pessoas já é essencial para muitas atividades, tais como, sistemas de controle de tráfego, sistemas financeiros, sistemas de suporte à saúde ou até sistemas de automação. Para os sistemas ubíquos, conforme já mencionado anteriormente, por poderem interferir, proativamente e de forma transparente, no modo como as pessoas realizam suas atividades cotidianas, o nível de dependência dos usuários em relação a esses sistemas pode ser ainda maior. Logo, espera-se que quanto maior o grau de dependência dos usuários em relação a um sistema computacional maior devem ser os níveis de dependabilidade desse sistema, justificando a confiança depositada pelos usuários no seu funcionamento correto. Além do conceito de dependabilidade apresentado anteriormente, sob um aspecto quantitativo, pode-se defini-lo como a capacidade de um sistema evitar falhas que sejam mais frequentes e mais graves do que é aceitável pelo usuário (AVIZIENIS et al., 2004), sendo que esse limiar de aceitação pode variar com o tipo e a severidade do domínio de aplicação. Apesar 1 Neologismo adotado neste trabalho como equivalente ao termo dependable do inglês. 16 deste ser um conceito mais quantitativo, ele ainda pode ser decomposto em seis atributos, sendo eles: disponibilidade (availability) , confiabilidade (reliability), segurança no uso (safety), confidencialidade (confidentiality), integridade (integrity) e manutenibilidade (maintainability) (AVIZIENIS et al., 2004). Faltas2 , segundo a terminologia apresentada em (AVIZIENIS et al., 2004), são as causas físicas ou algoritmicas que podem levar um sistema a um estado interno inconsistente, ou de erro2 . Com o propósito de tentar garantir níveis mais altos nos atributos de dependabilidade foram definidas quatro tipos de estratégias (AVIZIENIS et al., 2004; KNIGHT, 2012), que são: evitar a existência de faltas, eliminar faltas existentes, tolerar a ocorrência de faltas e prever efeitos de faltas. No âmbito da computação ubíqua, a abordagem de tolerância a faltas é acentuada, dado que, mesmo com a utilização de métodos para evitar e remover faltas, como, por exemplo, verificação e testes de software, é difícil desenvolver um sistema complexo livre de faltas. Quando um sistema deixa de funcionar conforme sua especificação devido a ocorrência de um erro, é caracterizada a ocorrência de uma falha2 . Um dos métodos mais difundidos de tolerância a faltas é o tratamento de exceções. As exceções são utilizadas mais comumente para modelar situações indesejadas, para que sejam detectadas e tratadas, em busca de manter o funcionamento de um sistema em conformidade com sua especificação. Além disso, exceções podem ser utilizadas também para comunicação de eventos ou situações diversas, previamente esperadas, entre componentes de software distintos. Ao passo que o MDBT pode tornar mais fácil o desenvolvimento de sistemas ubíquos, por conta do reuso de serviços disponíveis no ambiente, por outro lado, ele também pode dificultar o tratamento de exceções, devido a maior distribuição dos componentes responsáveis pela realização das tarefas. Uma abordagem capaz de lidar com essas dificuldades, fornecendo uma implementação reutilizável e um mecanismo de tratamento de exceções, e ainda permitir aproveitar os benefícios do MDBT é o uso do conceito de framework. A organização estrutural, ou arquitetura, de um framework é composta por pontos customizáveis que asseguram a flexibilidade necessária para geração de novos sistemas. Contudo, existem ainda pontos não customizáveis que fornecem implementações prontas e comportamentos predefinidos. Esses pontos não customizáveis são classificados como frozenspots, já os outros, customizáveis, são classificados como hot-spots (SCHMID, 1997). Funcionalidades comuns necessárias para o desenvolvimento baseado em tarefas, como, por exemplo, o gerenciamento do fluxo de execução, podem ser então reunidas através do desenvolvimento de um framework. Além disso, é possível integrar mecanismos que colaborem para a manutenção da robustez nos sistemas instanciados, como, por exemplo, mecanismos de tratamento de exceções. Além disso, a definição das ações de tratamento de exceções sensíveis ao contexto pode ser partes específicas das instâncias do framework e as abstrações relacionadas ao MDBT podem compor os hot-spots do framework desenvolvido. Um framework, seguindo o que foi apresentado em (GAMMA et al., 1995), pode ser definido como um conjunto de classes que cooperam e compõem um projeto reutilizável 2 Os termos falta, erro e falha foram adotados nesse trabalho como tradução para os termos fault, error e failure, respectivamente, do inglês. 17 para uma classe específica de software, que, no caso desta dissertação, são os sistemas ubíquos orientados a tarefas. A derivação de sistemas, ou instanciação do framework, pode ser obtida com a criação de subclasses específicas das aplicações, a partir de classes abstratas fornecidas pelo framework. Além disso, um framework dita a arquitetura a ser seguida pelas aplicações que o instanciam (GAMMA et al., 1995). Ao predefinir decisões de projeto importantes, como por exemplo, a arquitetura adotada, capturadas a partir de características comuns das aplicações de um determinado domínio, um framework permite que desenvolvedores e projetistas se concentrem apenas em especificidades de suas aplicações. Apesar de já existirem mecanismos de tratamento de exceções para o desenvolvimento de software tradicional, como os que foram apresentados em (GARCIA et al., 2001), pouco se avançou em relação ao tratamento de exceções em sistemas ubíquos. Por exemplo, assim como a sensibilidade ao contexto é um requisito importante para a computação ubíqua, esse requisito torna-se também importante para o tratamento de exceções em sistemas desse tipo. Informações de contexto podem ajudar desde a detecção de situações excepcionais até a escolha de estratégias mais apropriadas para o tratamento de exceções. Informações acerca do que está acontecendo tanto internamente no sistema quanto no ambiente podem servir, por exemplo, como entrada para expressões lógicas, que, por sua vez, podem ser utilizadas para disparar medidas de contingência ou de adaptações no próprio sistema. Essas medidas de contingência, em sistemas ubíquos orientado a tarefas, podem resultar desde a inicialização de novas tarefas até a adaptação dinâmica em tarefas que estejam em execução, a fim de buscar o tratamento adequado para exceções e manter o sistema funcionando dentro de suas especificações. 1.3 Objetivos e Contribuições O presente trabalho tem como objetivo principal propor um mecanismo de tratamento de exceções sensível ao contexto aplicável em sistemas ubíquos. Esse mecanismo é fornecido através de um framework, denominado FRonTES3 . Para atingir os objetivos, as abstrações, a organização e as estratégias concebidas no mecanismo proposto são incorporadas ao FRonTES. Isso possibilita que, em sistemas criados a partir da instanciação deste framework, exceções contextuais sejam tratadas de forma flexível e adaptativa. Através da utilização desse framework, é possível aproveitar tanto o MDBT, adotado nele como forma de facilitar o desenvolvimento de sistemas ubíquos, quanto o mecanismo de tratamento de exceções proposto. Além disso, o mecanismo proposto pode facilitar o desenvolvimento de sistemas ubíquos conciliando os benefícios do MDBT com a capacidade de prover o tratamento de exceções sensível ao contexto. Essa capacidade permite que esses sistemas lidem com situações indesejadas, buscando manter o seu comportamento em acordo a sua especificação ou procurando realizar suas tarefas de maneira mais adequada possível. Logo, uma vez que os 3 Acrônimo adotado neste trabalho como referencia para "Framework para o Desenvolvimento de Software Ubíquo Orientado a Tarefas com suporte ao Tratamento de Exceções Sensível ao Contexto". 18 sistemas ubíquos desenvolvidos tornam-se capazes de tratar exceções caracterizadas por estados de contexto indesejados, podendo efetuar ações para restabelecer alguma condição do contexto ou, até mesmo, alterar o seu fluxo de funcionamento interno, o grau de dependabilidade desses sistema é também beneficiado. Para validação desta proposta foi desenvolvido um sistema ubíquo de controle de estacionamento, que de forma simplificada, como uma prova de conceito, que segundo Pressman (2001, p. 205), demonstra e põe à prova a viabilidade de uma nova tecnologia. Nesta prova de conceito realizada, as funcionalidades relacionadas às atividades dos usuários do sistema de estacionamento ubíquo foram desenvolvidas utilizando o MDBT. Logo, através da implementação das tarefas desse sistema, explorando principalmente os cenários excepcionais, foi possível demonstrar a capacidade do mecanismo proposto de detectar, propagar e tratar exceções contextuais. Em resumo, a principal contribuição desta dissertação é a demonstração de um caminho viável para organização e implementação do tratamento de exceções sensível ao contexto em sistemas ubíquos orientados a tarefas, através da utilização de um mecanismo de tratamento de exceções que permite desde a representação de exceções contextuais até a detecção, propagação e o tratamento dessas exceções. 1.4 Organização da Dissertação Esta dissertação está organizada em sete capítulos. O presente capítulo apresentou uma breve introdução ao tema, contextualizando o assunto abordado neste trabalho. Além disso, foram apresentados a motivação, objetivos e contribuição desta dissertação. O Capítulo 2 expõe a fundamentação teórica, apresentando os principais conceitos e técnicas relacionados a Computação Ubíqua e ao Tratamento de Exceções, que compõem a temática desta dissertação. O modelo de desenvolvimento baseado em tarefas e o uso de sistemas de suporte aplicados a computação ubíqua são também apresentados. Ainda no capítulo 2 são enunciados alguns conceitos e técnicas relacionados ao tratamento de exceções sensível ao contexto. No Capítulo 3 são relatados os principais trabalhos relacionados a esta pesquisa com uma análise comparativa. O Capítulo 4 expõe uma visão geral sobre o framework FRonTES. Nele é descrita a arquitetura adotada e estendida para a construção do framework. Os principais componentes dessa arquitetura são detalhados, delimitando a função de cada um na arquitetura. Além disso, este capítulo apresenta a principal contribuição desta dissertação, que é o mecanismo de tratamento de exceções contextuais. As três principais funcionalidades do mecanismo proposto são delineadas, que são: detecção, propagação e tratamento de exceções contextuais. O Capítulo 5 descreve a avaliação deste trabalho de dissertação, relatando sobre uma prova de conceito realizada. Inicialmente é descrito o cenário ao qual é proposto o desenvolvimento de um sistema ubíquo orientado a tarefas. Em seguida é apresentado, em maior 19 nível de detalhes, como esse sistema foi desenvolvido através da instanciação do FRonTES e como está implementado o tratamento das exceções contextuais. Por fim, o Capítulo 6 sumariza os resultados alcançados neste trabalho, assim como apresenta possíveis linhas de pesquisa a serem consideradas em trabalhos futuros. 20 2 FUNDAMENTAÇÃO TEÓRICA Este capítulo apresenta os conceitos e técnicas fundamentais para esta dissertação. Nele são discutidos os referenciais teóricos sobre Computação Ubíqua e o Tratamento de Exceções, que compõem a temática desta dissertação. A seção 2.1 apresenta definições sobre computação ubíqua, assim como, também apresenta os principais requisitos e desafios relacionados a esse paradigma de computação. Além disso, é mostrada uma visão geral sobre a utilização de sistemas de suporte e o modelo de desenvolvimento baseado em tarefas (MDBT). Já nas seções 2.2 e 2.3, são expostos desde a definição de dependabilidade até o tratamento de exceções sensível ao contexto. Por último, a seção 2.4 sintetiza as conclusões deste capítulo. 2.1 Computação Ubíqua Entre o final da década de 80 e o começo da década de 90, o termo computação ubíqua foi cunhado por Mark Weiser a fim de definir uma nova era da computação, que surgia visionada por ele. Weiser vislumbrava um futuro no qual as tecnologias de computação tornariam-se totalmente integradas aos objetos, podendo ser utilizadas para auxiliar nas atividades cotidianas, fossem elas de trabalho ou diversão (KRUMM, 2009). Esse autor, considerado por muitos como o fundador da computação ubíqua, enunciou uma frase que tornou-se famosa pela forma como a retratou: As tecnologias mais profundas são aquelas que desaparecem. Elas se misturam com os objetos do dia a dia até que se tornam indistinguíveis no ambiente (WEISER, 1991, tradução livre). Diferente da época de Weiser, como afirmado em (ROCHA et al., 2011), os recursos de hardware disponíveis atualmente (e.g., smartphones, tablets, sensores e outros objetos com poder de processamento e comunicação) tornam possível a realização da Computação Ubíqua. Para que as tecnologias, não somente de hardware mas também de software, chegassem até esse patamar, diversas evoluções foram necessárias. Entretanto, para Weiser e Brown (1997) não são essas evoluções tecnológicas, por si, que realmente importam, mas sim a forma como as pessoas passam a se relacionar com as tecnologias. Em (WEISER; BROWN, 1997), foram delineadas três eras da computação, nas quais se apresentam mudanças na relação entre as pessoas e os computadores. A primeira era seria a da computação através dos mainframes, onde os recursos computacionais eram divididos por várias pessoas e, geralmente, eram operados somente por especialistas. A segunda foi caracterizada pelo uso dos computadores pessoais(personal computers - PCs), quando a relação das pessoas com os computadores tornou-se direta e mais profunda, já que obtiveram mais possibilidades de acesso a esse recurso para realização das suas atividades de forma independente dos especialistas. Todavia, a realização dessas atividades com uso dos PCs, nessa fase, ainda ocorre de forma que em que se deve desprender muita atenção. 21 Antecedendo a terceira era, Weiser e Brown definiram uma fase de transição caracterizada pela presença da Internet e da computação distribuída. Esta seria uma fase intermediária entre a era dos PCs e a era da computação ubíqua. Essa última é caracterizada pela conexão entre o mundo físico e o virtual das coisas do dia-a-dia. Na era da computação ubíqua os computadores estariam embutidos nos mais diversos objetos, nas mais diversas escalas de tamanho e estariam imersos no cotidiano das pessoas. Um dos grandes desafios dessa era, segundo os autores, é permitir que as pessoas façam uso desses computadores imersos em seu cotidiano sem que tenham que direcionar atenção para isso, promovendo a interação de forma “calma” (WEISER; BROWN, 1997). A figura 2.1 retrata graficamente como cada uma dessas eras se estabeleceu ao longo do tempo, mostrando, também, a distribuição do número de dispositivos. Figura 2.1: Gráfico retratando três eras da computação moderna. (KRUMM, 2009). Figurada adaptada de Ao expor esse panorama das eras da computação definidas por Weiser e Brown (1997), tornam-se mais tangíveis as mudanças ocorridas na forma como as pessoas e os dispositivos computacionais se relacionam. Porém, com isso, torna-se imprescindível uma definição mais precisa e completa do que é computação ubíqua. Nesse sentido, pode-se retomar algumas noções e definições já analisadas por Jeon et al. (2007) no artigo “A taxonomy of ubiquitous computing applications”, sumarizadas na Tabela 2.1. Tabela 2.1: Comparação entre algumas definições de Computação Ubíqua. Tabela adaptada de (JEON et al., 2007, tradução nossa). Autores Ken Sakamura (SAKAMURA, 1987) Definições Computação ubíqua é estar apto a usar computadores em qualquer lugar e a qualquer hora. Computação ubíqua tem como seu objetivo melhorar o uso dos computadores fazendo com Mark Weiser (WEISER, 1993a) que diversos deles estejam disponíveis em toda lugar, mas fazendo-os efetivamente invisíveis para os usuários. Friedermann Mattern (MATTERN, 2001) Os objetos do cotidiano se tornarão inteligentes e estarão todos interconectados. Computação pervasiva provê acesso móvel a informações de negócio sem limitações de disIBM (IBM, 2005) positivos, rede ou estilo de interação. Ela dá às pessoas o controle sobre o tempo e espaço, sob demanda. Computação ubíquia é uma tecnologia, na qual computadores invisíveis estão incorporados Leem et al. (LEEM et al., 2005) e conectados com todas as coisas de modo que qualquer pessoa possa se comunicar, trocar e compartilhar informações em qualquer lugar e a qualquer momento. 22 Ao observar cada uma dessas definições, é possível perceber que elas possuem alguns aspectos comuns, todavia também possuem diferenças. Na definição de Weiser a computação ubíqua é apresentada de forma ligeiramente visionária, tanto que essa definição serviu de referência para o desenvolvimento na área. Já Mattern fundamentou sua definição, refinando o aspecto ideal da computação ubíqua de Weiser, nos aspectos mais técnicos desse novo paradigma (MATTERN, 2001). Ao esmiuçar o que foi apresentado em (JEON et al., 2007), pode-se relacionar as diferenças percebidas entre algumas definições para computação ubíqua com a conjuntura (e.g., país onde foi realizado a pesquisa, estado de desenvolvimento das tecnologias, etc) na qual elas foram propostas. Por exemplo, enquanto nos Estados Unidos o foco de diversas pesquisas de computação ubíqua estava voltado para computação em tempo real através de objetos inteligentes, no Japão o foco estava em prover ambientes com conectividade ubíqua e na Europa, de maneira geral, a preocupação era em prover a colaboração entre dispositivos móveis. Poslad (2009), em seu livro “Ubiquitous Computing - Smart devices, environments and interactions” que consolida diversos aspectos importantes da computação ubíqua, apresenta algumas outras definições de computação ubíqua e afirma que diferentes noções e definições podem se sobrepor. Percebe-se que as variações nas definições ocorrem porque elas compõem de forma diferente as propriedades da computação ubíqua. Além disso, é identificado e reiterado por Poslad a relação, e até sobreposição, entre o conceito de computação ubíqua com diversos outros conceitos, como, por exemplo, computação pervasiva, computação sensível ao contexto e ambientes inteligentes. Poslad (2009) trata como um mito a existência de uma única definição capaz de caracterizar de forma precisa a computação ubíqua. Considerando essa afirmação do autor, não se pretende nesta dissertação propor ou adotar uma definição de computação ubíqua que seja irrefutável. Porém, com a finalidade de estabelecer um vocabulário comum neste trabalho, assim como Leem et al. e outros autores estenderam a definição de Weiser, adota-se nesta dissertação a definição de computação ubíqua como sendo um modelo de computação altamente distribuído o qual realiza-se através de dispositivos computacionais heterogêneos, móveis ou não, que atuam de forma discreta nos ambientes onde estão, fornecendo informações, provendo serviços ou realizando tarefas em qualquer lugar e a todo instante. Apesar da falta de uma definição precisa e amplamente aceita do que é computação ubíqua, existe, entre muitos pesquisadores desta área, um certo direcionamento comum para considerar um sistema como ubíquo ou não. Tal categorização é obtida tomando como base as principais características da computação ubíqua. Spínola, Massollar e Travassos (2007), através de uma revisão sistemática que cobriu 116 artigos relacionados a esse paradigma de computação, conseguiram listar 10 características comuns em sistemas de computação ubíqua, apresentadas na seção seguinte. 2.1.1 Principais Características e Requisitos É necessário expor, antes de enumerar algumas das principais características da computação ubíqua e alguns dos desafios atrelados a elas, que um sistema de software pode ser considerado ubíquo mesmo quando não apresenta todas as características desse paradigma de 23 computação, como foi observado em (SPíNOLA; TRAVASSOS, 2012) e (POSLAD, 2009). Para reunir as principais características dos sistemas ubíquos, esta dissertação embasou-se nos trabalhos de Spínola e Travassos (2012), Lima (2011), Maia, Rocha e Andrade (2009), Badram e Friday (2010), Poslad (2009), Niemelä e Latvakoski (2004), Kindberg e Fox (2002), Satyanarayanan (2001). Apesar dos termos “característica” e “requisito” não serem intercambiáveis entre si, por possuírem valor semântico diferente na Engenharia de Software, nesta subseção os dois termos são considerados afins. Oferecer suporte a uma determinada característica normalmente implica em atender a um requisito análogo ou fortemente relacionado. Com isso, são enumeradas (por ordem alfabética) as principais características levantadas na literatura mencionada anteriormente. C1 – Autonomicidade: característica de um sistema de ser capaz de controlar suas próprias ações de forma independente, mesmo quando possui interfaces com outros sistemas. Essa característica permite, por exemplo, que usuários interajam com um sistema fornecendo apenas o seu objetivo, que pode ser uma meta ou uma política a ser seguida, sem se preocupar com o que o sistema terá que fazer para atingi-lo. Nesse caso, o sistema deverá automaticamente planejar e escalonar as tarefas que devem ser executadas para atingir o objetivo do usuário. Essa característica pode ser subdividida em quatro atributos, que são: autoconfiguração, auto-otimização, autorreparo e autoproteção (MAIA; ROCHA; ANDRADE, 2009). C2 – Captura de experiência: habilidade de detectar as necessidades dos usuários e das atividades que precisam ou podem ser realizadas tomando como base a percepção de informações previamente capturadas e atuais. C3 – Comportamento adaptável: capacidade de um sistema de se auto-adaptar às limitações do ambiente, dos dispositivos e dos serviços para permanecer em funcionamento de forma otimizada e personalizada, de acordo com suas especificações. C4 – Composição de serviço: representa a habilidade de prover uma nova funcionalidade ou serviço, requerido por um usuário ou outro sistema, a partir da organização e interação de serviços existentes. C5 – Descoberta de serviço: possibilita encontrar e utilizar serviços, de forma proativa, assim que os mesmos estejam disponíveis. Essa característica permite, por exemplo, que um sistema identifique que um novo serviço está disponível e passe a usá-lo para prover uma nova funcionalidade ou modificar uma já existente. C6 – Escalabilidade: está relacionada a capacidade de um sistema permanecer funcionando efetivamente mediante o aumento significante de recursos e/ou usuários (COULOURIS et al., 2011). Essa característica é pertinente em sistemas ubíquos, pois além do seu caráter distribuído, seu crescimento pode ser difícil de ser previsto e mensurado. Logo, nesses sistemas, lidar com possíveis aumentos na carga de trabalho de forma graciosa ou estar prontamente preparado para ampliação torna-se relevante. 24 C7 – Heterogeneidade: capacidade de suportar uma grande variedade de dispositivos, serviços e protocolos. Contudo, ao propiciar essa característica a um sistema, deve-se atentar ao fato de que adaptações podem ser necessárias. C8 – Interoperabilidade espontânea: dispositivos e serviços podem interagir de forma automática e sem intervenção do usuário, trocando informações ou compartilhando recursos, em prol de algum objetivo do usuário, ou do próprio sistema. C9 – Invisibilidade: pode ser interpretada em dois sentidos. O primeiro diz respeito a miniaturização dos dispositivos computacionais e a capacidade de se incorporar1 aos objetos do dia-a-dia (e.g., móveis, vestimentas, equipamentos médicos, etc), tornandoos fisicamente invisíveis ao olho humano. Já a segunda interpretação trata da forma como os dispositivos trabalham sem desviar a atenção do usuário, tornando-os imperceptíveis. Nesse aspecto, apesar da tecnologia estar fisicamente visível (audível ou háptico) ela realiza sua função sem requerer a atenção dos usuários. C10 – Mobilidade: do ponto de vista de software, essa característica pode ser dividida em três tipos. O primeiro deles é a mobilidade de código, que, quando necessário, proporciona a transferência dinâmica dos dados e operações de parte de um sistema entre dispositivos distintos. Outro tipo de mobilidade é a de usuário, que pode acessar as aplicações e serviços a partir de diferentes lugares e dispositivos mantendo os estados de execução. Nesse caso, o software deve estar ciente da natureza distribuída do ambiente e deve conseguir localizar e acessar recursos e informações compartilhados dos usuários. O terceiro tipo é a mobilidade física, que está relacionada a capacidade dos dispositivos, os quais recebem os softwares, de permanecerem conectados através de infraestrutura de comunicação móvel e sem fio. C11 – Onipresença de serviço: capacidade de fazer com que os usuários tenham a percepção de que carregam os serviços que fazem uso consigo, independente da sua situação de mobilidade. C12 – Segurança: com o foco na garantia da preservação das informações, esta característica pode ser dividida nos aspectos de confidencialidade(proteger do acesso não autorizado), integridade (proteger contra alterações indevidas) e disponibilidade (proteger de problemas que possam vir a impossibilitar o acesso aos recursos) (COULOURIS et al., 2011). C13 – Sensibilidade ao Contexto: em uma definição tradicional, contexto é qualquer informação que pode ser usada para caracterizar a situação de uma entidade. Uma entidade, por sua vez, pode ser uma pessoa, lugar ou objeto que seja considerado relevante para a interação entre um usuário e uma aplicação, incluindo o próprio usuário e a aplicação (DEY, 2001, tradução nossa). Essa definição foi revisitada em (BUTHPITIYA et al., 2012) para adicionar a noção de contexto como qualquer informação que caracterize uma situação de um usuário e possibilite mudanças dinâmicas em aplicações e/ou a chamada automática de novas aplicações. Um sistema é sensível ao contexto se usa informações contextuais para prover informações relevantes e/ou serviços para o usuário, 1 Tradução adotada para o termo embedded, do inglês. 25 onde a relevância depende das tarefas do usuário (DEY, 2001, tradução nossa). Essa característica deve ser destacada, pois possuí relação direta com algumas das outras características já enumeradas. Por exemplo, a autonomicidade, a captura de experiência e a invisibilidade são características importantes da computação ubíqua e normalmente dependem da observação do contexto para terem êxito. No âmbito desta dissertação a característica de sensibilidade ao contexto é fundamental. O mecanismo de tratamento de exceções proposto utiliza-se dessa característica para perceber a ocorrência de situações indesejadas, previamente identificadas, em busca de manter os sistemas envolvidos funcionando conforme suas especificações. C14 – Tolerância a faltas: de forma simplificada, faltas são problemas físicos ou algoritmos que podem levar um sistema a um estado defeituoso. Logo, a capacidade de tolerar faltas provê aos sistema a possibilidade manter o seu funcionamento conforme especificado mesmo mediante a ocorrência de faltas. Essa característica representa também uma das técnicas empregadas em sistemas computacionais para buscar níveis mais elevados de dependabilidade, por isso é discutida de forma mais detalhada na seção 2.2. Assim como já mencionado em (ROCHA; ANDRADE, 2012), atualmente essas características e requisitos são suportados por uma variada gama de frameworks, sistemas de middleware e sistemas de suporte a ubiquidade (MAIA; ROCHA; ANDRADE, 2009; GRIMM et al., 2004; JAROUCHEH; LIU; SMITH, 2009; COSTA; YAMIN; GEYER, 2008). 2.1.2 Sistema de Suporte para Computação Ubíqua Diversas plataformas de desenvolvimento e execução para sistemas distribuídos tradicionais estão disponíveis atualmente, como Java RMI, CORBA, plataformas baseadas em RPC e diversas outras. No entanto, as soluções empregadas a problemas de sistemas distribuídos ou, até mesmo, de sistemas móveis muitas vezes não são suficientes para resolver questões relacionadas ao desenvolvimento e execução de sistemas ubíquos, como a capacidade de adaptação ao contexto, autonomicidade, suporte a comunicação e notificação de eventos de forma assíncrona, dentre outros. Conforme apresentado em (ROMAN et al., 2003), sistemas de suporte proveem funcionalidades genéricas que simplificam o desenvolvimento de sistemas ubíquos. Diversas pesquisas endereçaram problemas relacionados a esse domínio da computação e apresentaram contribuições importantes. Todavia, o desenvolvimento de um sistema de suporte que atenda de forma simultânea a várias características da computação ubíqua ainda é desafiador, pois tratá-las de forma integrada torna esta atividade complexa. Um projeto de sistema de suporte a computação ubíqua específico é destacado nesta subseção: o SysSU (LIMA et al., 2011). O SysSU é ressaltado pois está fundamentado em arquitetura que permite a coordenação e comunicação em sistemas ubíquos de forma interoperável e desacoplada, conforme apresentado em (LIMA et al., 2011). Esta arquitetura, apresentada em mais detalhes a seguir, demonstra-se adequada para utilização no desenvolvimento de sistemas ubíquos pois possibilita, através do reuso do modelo de comunicação baseados em espaço 26 de tuplas e o modelo de eventos, a troca de informações de forma assíncrona e desacoplada temporal e espacialmente. No modelo de comunicação baseado em espaço de tuplas, criado com base no que foi proposto em (CARRIERO; GELERNTER, 1989), processos concorrentes se comunicam de forma indireta, através de um espaço compartilhado chamado espaço de tuplas. Uma tupla, por sua vez, é um conjunto de dados organizados em campos tipados. Estes dados representam alguma informação relevante para o sistema e servem para trocar informações entre os processos (LIMA, 2011). Já o modelo de eventos fundamenta-se em infraestruturas, independentes de aplicação, que permitem a comunicação baseada em eventos, onde elementos fornecedores comunicam de forma assíncrona a ocorrência de eventos para um grupo de elementos consumidores, de forma ideal, sem o conhecimento do número de consumidores e suas localizações (MEIER, 2000). No caso do SysSU, o modelo de eventos é utilizado em conjunto ao modelo de comunicação baseado em espaço de tuplas para notificação da adição, remoção ou alteração de informações (no formato de tuplas). Essa arquitetura de referência é, sob alguns aspectos, extensível. Ela permite, por exemplo, ser utilizada como infraestrutura para propagação de informações de contexto, para coordenação e invocação de serviços distribuídos, ou até mesmo como meio de propagação de exceções. A arquitetura utilizada no SysSU é ilustrada na Figura 2.2, onde um sistema ubíquo hipotético é ilustrado. Este sistema é composto por vários dispositivos, que por sua vez pode conter vários agentes(na figura é mostrado apenas um por dispositivo). Um agente, nesse caso, representa qualquer entidade de software presente em um sistema que seja capaz de realizar algum processamento e se comunicar com outros agentes (LIMA et al., 2011). O UbiCentre é o componente responsável por abrigar os espaços de tuplas que poderão ser acessados de forma concorrente por vários agentes. Os agentes, por sua vez, acessam aos espaços de tuplas através do middleware denominado UbiBroker. O UbiCentre disponibiliza um conjunto de operações, que seguem um comportamento padronizado (LIMA et al., 2011), que podem ser realizadas nos espaços de tuplas. Os espaços de tuplas gerenciados por um UbiCentre são diferenciados entre si através de identificadores únicos. Já os UbiBrokers devem permitir realizar, com uso de alguma tecnologia de execução remota de métodos (e.g. CORBA, webservices,etc), chamadas às operações disponíveis no UbiCentre para adicionar, remover ou modificar tuplas existentes. A implementação de um UbiBroker deve seguir a definição de interface que foi padronizada para esse sistema (LIMA et al., 2011). Uma implementação desse sistema de suporte está disponível na web como modelo de referência para a arquitetura proposta 2 . 2 Implementação 08/06/2012. de referência disponível em <http://code.google.com/p/syssu/>. Último acesso em 27 Figura 2.2: Arquitetura de referência do SysSU (LIMA et al., 2011). 2.1.3 Modelo de Desenvolvimento Baseado em Tarefas A Computação orientada a tarefas representa uma nova visão em relação ao desenvolvimento de sistemas (WANG; GARLAN, 2000). Rocha et al. (2011) apontaram a utilização desse modelo de desenvolvimento como um passo na evolução da modularização de sistemas, partindo da unidade de abstração de rotinas nos anos 60, passando por módulos (anos 70), objetos (anos 80), componentes (anos 90) até chegar nas tarefas nos anos 2000. Contudo, essa abstração não se limita apenas a uma forma de modularização. Wang e Garlan (2000) foram os pioneiros em apresentar uma abordagem relacionada ao desenvolvimento de sistemas úbíquos utilizando a abstração de tarefas. Segundo estes autores, essa abordagem possibilita que usuários interajam com ambientes de computação através de tarefas de alto nível, sem se preocupar com as ações (de mais baixo nível) que devem ser executadas, deixando-as a cargo de um sistema de suporte. Ainda sobre essa abordagem, Wang e Garlan afirmam que ela pode reduzir significativamente o nível de atenção e conhecimento requeridos dos usuários de um sistema. Além disso, ela pode tornar possível a adaptação automática, seja por mudanças contextuais ou causadas por faltas. Em sistemas orientados a tarefas os usuários especificam suas tarefas ou objetivos e deixam sob responsabilidade do sistema o mapeamento dessas tarefas em funcionalidades disponíveis nos ambientes ubíquos (SOUSA et al., 2006). Uma tarefa representa a intenção de um usuário (WANG; GARLAN, 2000). Pode-se entender que uma tarefa possui nível de abstração mais próximo de um objetivo do usuário, ao invés da forma com que esse objetivo será atendido (MASUOKA; PARSIA; LABROU, 2003). 28 Ferreira et al. (2009) citaram a Teoria da Atividade Humana (TAH) (KAENAMPORNPAN; O’NEILL, 2004, 2005) como ligação entre o conceito de tarefa e atividade. Segundo essa teoria as atividades humanas podem ser modeladas utilizando-se de quatro conceitos, que são: • sujeito, quem pratica a atividade; • objetivo, meta da atividade; • ação, processos envolvidos para atingir o objetivo; e • operações, como a ação é executada. Em (FERREIRA et al., 2009), por exemplo, foi abordado o domínio de sistemas médicos ubíquos, onde a atividade clinica de “atendimento a pacientes” é modelada para uma tarefa (conceitualmente uma ação na TAH) composta pelas operações “identificar o paciente” e “buscar o prontuário eletrônico”. Outros exemplos de utilização desse modelo podem ser vistos em (BARDRAM; CHRISTENSEN, 2007; HUANG et al., 2008; VO et al., 2011). As tarefas possuem um nível de abstração próximo a meta do usuário. Entretanto, como mencionado anteriormente, as tarefas podem ser quebradas em ações com nível relativamente mais baixo de abstração. Nesta dissertação, as operações que compõem uma tarefa são definidas como passos de tarefa. Por exemplo, uma tarefa “estacionar” poderia ser dividida em um conjunto de passos: receber comprovante de bilhetagem, procurar vaga disponível e ocupar vaga. Diferente da noção de casos de uso, as tarefas não tem o foco principal no fluxo das interações, mas sim no fluxo de intenções do usuário. Em (LAUESEN; KUHAIL, 2011) são analisadas as diferenças entre essas abstrações, suas vantagens e desvantagens. Essa abordagem em mais alto nível, como apresentado em (WANG; GARLAN, 2000), permite desenvolver sistemas que exijam pouco conhecimento quanto a forma de utilização (por não exigir que o usuário tenha ciência da sequência de operações necessárias para realização de uma tarefa) e tomem menos a atenção do usuário durante o uso. Além disso, tarefas podem ser iniciadas ou recomendadas a partir de gatilhos relacionados ao contexto (HUANG et al., 2008; SOUZA; AUGUSTIN, 2010). Consequentemente, esse modelo orientado a tarefas ajuda aos sistemas a aproximarem-se do requisito de invisibilidade vislumbrado para computação ubíqua. Loke (2009) apresenta uma das principais alternativas para construção de taskable spaces, que são ambientes providos de um sistema que oferece aos usuários a possibilidade de execução de tarefas, construídos através de serviços ubíquos. Na abordagem desse autor, os usuários tem acesso a diversas tarefas, que podem ser expressas em alto nível de abstração (mais legível para os usuários). Essas tarefas, no entanto, são descritas e mapeadas para serviços ubíquos através de arquivos XML. A figura 2.3 ilustra, utilizando uma abstração de camadas, como está organizada essa abordagem. Ranganathan (2005) e Vo, Torabi e Loke (2010) propuseram framework que fornecem abstrações relacionadas ao MDBT. Ranganathan em sua tese de doutorado propôs um 29 Figura 2.3: Arquitetura abstrata em camadas de Loke (2009). Figura adaptada de (LOKE, 2009). framework para execução de tarefas em sistemas ubíquos e autônomos. Na abordagem do autor, os desenvolvedores, usuários do framework, programam sistemas ubíquos usando tarefas ou workflows e especificam parâmetros que influenciam em como essas tarefas são executadas. Através desses parâmetros, o framework consegue prover auto-configuração (self-configuration, do inglês) através de escolhas automáticas ou semi-automáticas dos valores dos parâmetros especificados para as tarefas. Além disso, pode prover também auto-reparo (self-repair, do inglês) através da escolha de valores alternativos dos parâmetros, caso a escolha inicial falhe. Percebe-se nessa abordagem adaptativa que a construção de sistemas ubíquos complexos pode ter um menor esforço de desenvolvimento e maior confiabilidade, uma vez que o framework se encarrega da escolha adequada dos parâmetros das tarefas para responder a alguns tipos de faltas ou, por exemplo, a mudanças contextuais. Apesar de trazer contribuições com estratégias para auto-configuração e auto-reparo em (RANGANATHAN, 2005), o tratamento de exceções não é abordado. O framework de Vo, Torabi e Loke utiliza uma abordagem semelhante, contudo adicionam a funcionalidade de recomendação de tarefas com base em informações contextuais. Em (VO; TORABI; LOKE, 2010) pode-se observar detalhes sobre a implementação de um sistema usando a abordagem apresentada em (LOKE, 2009) e (VO; TORABI; LOKE, 2010). 2.2 Dependabilidade Como já foi apresentado na motivação desta dissertação, seção 1.2, sistemas computacionais estão cada vez mais presentes no cotidiano das pessoas e esperam-se que estes funcionem sempre de maneira adequada. Todavia, a criação de sistemas totalmente livres de falhas não é uma tarefa viável (KNIGHT, 2012). Para lidar com esse problema e possibilitar a criação de sistemas capazes de transmitir a sensação aos seus usuários de que não serão afetados por nenhum problema que vá afetar o seu funcionamento, busca-se garantir nesses sistemas níveis apropriados de dependabilidade. 30 Uma definição tradicional e amplamente aceita do termo dependabilidade encontrase em (AVIZIENIS et al., 2004) sob dois aspectos, um qualitativo e outro quantitativo. Sob o aspecto qualitativo, dependabilidade foi definida como a habilidade de se prover um serviço em que se podem justificadamente confiar. Nesse caso, a utilização da palavra “justificadamente” na definição dos autores garante a subjetividade necessária para oferecer a noção de que o sistema poderá oferecer uma quantidade maior ou menor de subsídios para obter a confiança dos usuários. Já sob o aspecto quantitativo, Avizienis et al. (2004) afirmaram que dependabilidade pode ser entendida como a capacidade de um sistema evitar falhas que sejam mais frequentes e mais graves do que é aceitável pelo usuário. Nesse caso, o nível do que é aceitável também pode variar de acordo com o tipo de sistema. Knight (2012) consolidou em seu livro outra definição de dependabilidade como a habilidade de um sistema de evitar falhas de serviço que sejam mais frequentes e mais severas do que é aceitável. Com essa definição, Knight conseguiu contemplar quatro pontos importantes em relação a dependabilidade em sistemas em geral. Porém, antes de expor esses pontos é necessário apresentar uma definição mais precisa do que é uma falha. Para alcançar uma compreensão abrangente sobre o que é uma falha é necessário também ter uma noção sobre dois outros conceitos importantes, apresentados em (KNIGHT, 2012), que são: • função do sistema, que é aquilo o que o sistema se destina a fazer e está descrito em sua especificação; e • serviço correto, que é o serviço entregue por um sistema enquanto implementa a função do sistema (i.e., o funcionamento está de acordo com o que foi especificado para o sistema). Logo, seguindo a definição de falha que foi apresentada em (LAPRIE; AVIZIENIS; KOPETZ, 1992; AVIZIENIS; LAPRIE; RANDELL, 2004), para Knight uma falha de serviço é caracterizada quando ocorre algum evento que desvia um serviço do seu comportamento correto. A partir desta definição de falha é possível expor os quatro pontos destacados por Knight da definição de dependabilidade. O primeiro ponto da definição de dependabilidade, apesar de aparentemente óbvio, está relacionado a evitar a ocorrência de falhas de serviço. Considerando hipoteticamente que um sistema tenha uma taxa de falhas de serviço e que essa taxa esteja abaixo de um valor de referência considerado aceitável para esse sistema, ele ainda assim será considerado fidedigno ou “dependable”. Portanto, para que sistemas atendam a requisitos de dependabilidade deve-se procurar identificar todas as maneiras pelas quais falhas possam ocorrer e criar-los de forma que mantenham a sua taxa de falhas em níveis aceitáveis. O segundo ponto é decorrente da utilização da palavra “frequente” na definição de dependabilidade, o que faz com que esta definição possa ser vista como uma média. Como consequência desse ponto deve-se indicar meios pelos quais a frequência de falhas possa ser determinada. 31 O terceiro ponto, que aparentemente vai de encontro a precisão buscada na definição de dependabilidade, é que esse requisito pode ser subjetivo. A utilização da palavra “aceitável” na definição de dependabilidade garante essa subjetividade, pois uma vez que não é possível desenvolver sistemas perfeitos (KNIGHT, 2012), totalmente livre de falhas, então deve-se estabelecer algum nível o qual as falhas serão ou não admitidas. O quarto ponto não está explícito na definição de dependabilidade. Este último aponta que a dependabilidade de um sistema está relacionada com um contexto de operação, que é o conjunto de condições que devem ser atendidas para que o sistema funcione conforme sua especificação. A consequência dessa última afirmação é que um sistema executa de forma esperada no contexto de operação o qual ele foi projetado e implementado para executar. Caso esse contexto não seja atendido as falhas de serviço estarão mais propensas a ocorrer, possivelmente levando ao não atendimento dos níveis de dependabilidade estabelecidos. Avizienis, Laprie e Randell (2004) delinearam ainda uma taxonomia sobre dependabilidade. Essa taxonomia divide-se em três dimensões, que são: atributos, ameaças e meios. A figura 2.4 apresenta uma árvore que esquematiza essas três dimensões. Figura 2.4: Árvore da dependabilidade. RANDELL, 2004). 2.2.1 Figura adaptada de (AVIZIENIS; LAPRIE; Atributos da dependabilidade O primeiro ramo da árvore da dependabilidade mostra os seis principais atributos que decompõem a dependabilidade. Esses atributos são qualidades que devem ser buscados para que sistemas, de forma geral, possam alcançar o seu nível planejado de dependabilidade. Tais atributos3 são descritos brevemente a seguir (AVIZIENIS et al., 2004; KNIGHT, 2012). • Disponibilidade: é definida como a probabilidade do sistema estar apto a prestar um serviço correto em um determinado instante de tempo. Está relacionada a capacidade do sistema de estar pronto para uso quando necessário. 3 Os termos disponibilidade, confiabilidade, segurança no uso, confidencialidade, integridade e manutenibilidade foram adotados nesta dissertação, respectivamente, como tradução para os temos availability, reliability, safety, confidentiality, integrity e maintanability do inglês. 32 • Confiabilidade: é a probabilidade do sistema operar conforme sua especificação por um período de tempo específico. Tem relação direta com a habilidade de um sistema prestar um serviço correto. • Segurança no uso: sistemas de segurança no uso crítica (tradução adotada para safetycritical systems) são aqueles cujas falhas podem ter consequências catastróficas, por exemplo, machucar pessoas ou causar danos ao meio-ambiente. Logo, esse atributo está relacionado a inexistência de consequências catastróficas para os usuários ou ambiente enquanto um sistema estiver sendo utilizado. • Confidencialidade: ausência de acesso não autorizado a informações. Esse atributo oferece a noção de que somente entidades autorizadas, sejam elas pessoas ou sistemas, podem acessar informações de um sistema. • Integridade: ausência de modificações impróprias no sistema. Este atributo está relacionado ao atributo de confidencialidade, entretanto difere no que diz respeito a alteração indevidas de informações do sistema. • Manutenibilidade: é a capacidade de sofrer reparos e modificações. Esta capacidade é requerida, por exemplo, quando ocorre uma falha no sistema que exige alguma intervenção no software. Já a “segurança” não é considerada com um simples atributo de dependabilidade. Esta é apresentada como uma composição dos atributos disponibilidade, confidencialidade e integridade. 2.2.2 Ameaças a dependabilidade Como já foi mencionado no início desta seção, uma falha (failure, do inglês) é caracterizada quando ocorre algum evento que desvia um serviço do seu comportamento correto (AVIZIENIS et al., 2004; KNIGHT, 2012). Avizienis, Laprie e Randell expõem uma noção de serviço como sendo uma sequência de estados do sistema “visíveis” externamente, portanto a mencionar que ocorreu uma falha em um sistema significa dizer que pelo menos um estado externo do sistema desviou-se do seu estado de serviço correto. Já o estado interno do sistema que pode levar a uma falha é definido como erro (error, do inglês). Na taxonomia de Avizienis et al. (2004) um erro foi definido como a parte do total de estados do sistema que pode levar a uma posterior falha de serviço. Os autores afirmam ainda que erros podem ocorrer sem que sejam manifestados em estados externos do sistema, não causando falhas. As causas físicas ou algorítmicas dos erros são definidas como faltas (fault, do inglês). Uma falta é considerada ativa quando ela efetivamente causa um erro, caso contrário ela é considerada inativa (dormant, do inglês) . 33 2.2.3 Meios para atingir a dependabilidade Para permitir obter níveis especificados nos atributos de dependabilidade de um sistema quatro tipos de meios foram especificados na taxonomia de Avizienis et al. (2004). Tais meios são descritos brevemente a seguir. • Prevenção de faltas: é um conjunto de técnicas que são aplicáveis durante o desenvolvimento de um sistema com objetivo de evitar que faltas sejam inseridas no software gerado. As técnicas desse tipo tem como premissa a hipótese de que se um sistema for construído sem a inserção de faltas, então não será necessário aplicar nenhuma outra técnica para garantir sua dependabilidade. Knight (2012) afirma que a prevenção de faltas deve ser sempre a primeira alternativa a ser adota para buscar atingir a dependabilidade esperada. Técnicas de Engenharia de Software como métodos formais, especificação de requisitos rigorosa, reutilização de software e outras diversas podem contribuir na prevenção de faltas. • Remoção de faltas: é um conjunto de técnicas utilizado para reduzir a quantidade e a severidade das faltas já inseridas em um sistema. Este tem como premissa a hipótese de que é impossível construir um software livre de faltas, logo busca identificá-las e removêlas antes da fase implantação. Teste e inspeção de software são exemplos de técnicas que ajudam na remoção de faltas. • Tolerância à faltas: é um conjunto de técnicas que permite que um sistema evite a ocorrência de falhas mesmo na presença de faltas. Um dos métodos de tolerância à faltas mais difundidos é o tratamento de exceções, este é discutido com maior detalhamento na seção 2.3. • Previsão de faltas: é um conjunto de técnicas utilizado para estimar a presença de faltas e suas possíveis consequências. Estas técnicas são utilizadas quando, mesmo com a utilização das outras, ainda restam faltas as quais os sistemas não são capazes de lidar. Por isso, deve-se prever seus possíveis efeitos a fim de permitir a decisão de que essas faltas seja aceitáveis ou não para um determinado sistema. 2.3 Tratamento de Exceções Trabalhos precursores em relação ao tratamento de exceções apresentaram alguns conceitos que, de certo modo, perduram até hoje. Goodenough (1975a) definiu o conceito de lançamento de exceções (do inglês raising exception) como um meio de parametrizar a resposta a certa condição detectada por uma operação. Por outro lado, a resposta ou reação a uma exceção levantada recebe o nome de tratamento de exceção (do inglês exception handling). Antes de apresentar um conceito mais preciso sobre o que é uma exceção, é necessário ter uma noção da essência desse conceito. Parnas e Würges (1976) apresentou o conceito de eventos indesejados, que são todos os eventos que causam desvio do comportamento normal de um software. Já em (GOODENOUGH, 1975a), a essência das exceções está 34 relacionada com a generalização de operações para fazê-las reusáveis em um escopo mais amplo, de modo que possam dar suporte a interações entre diferentes níveis de abstração de um sistema. É importante destacar, a partir dessas compreensões precursoras sobre exceções, que estas não estão relacionadas apenas a condições de erro no software (GOODENOUGH, 1975a; KNIGHT, 2012). Lee e Anderson (1990) definiram exceções como abstrações que modelam condições de erro em um componente. Essas abstrações permitem aos componentes realizarem o tratamento adequado às condições de erro detectadas. Dessa forma, o tratamento de exceções pode ser entendido como a capacidade que um software possui de reagir de maneira adequada perante a ocorrência de exceções, continuando ou interrompendo a sua execução, com o intuito de preservar a integridade do sistema (GARCIA et al., 2001). Garcia et al. (2001) definiram como mecanismo de tratamento de exceções o elemento que provê o suporte a detecção e recuperação de erros, e estrutura as atividades de tolerância a faltas em um sistema. Segundo os autores, é desejável que esses mecanismos ofereçam simplicidade para o uso e forneçam uma separação explícita entre o comportamento normal e o comportamento excepcional do software. Mecanismos de tratamento de exceções podem ser construídos como (DAMASCENO, 2006) uma parte inerente das linguagens de programação, com sua própria sintaxe, e como características de middlewares ou frameworks, capazes de tratar particularidades de diferentes domínios de aplicação. Lee e Anderson (1990) definiram um sistema de software como um conjunto de componente que cooperam sobre o controle de um projeto para servir as demandas de um ambiente. A partir dessa definição de sistema como um conjunto de componentes que interagem para prover um serviço, Campbell e Randell (1986) e posteriormente Garcia et al. (2001) identificaram que a atividade de um componente de software pode ser dividida em duas partes: atividade normal e atividade anormal (excepcional). Figura 2.5: Componente tolerante a faltas ideal. Figura adaptada de (GARCIA et al., 2001). 35 Em (CAMPBELL; RANDELL, 1986; GARCIA et al., 2001) foi definido também como seria um componente tolerante a faltas ideal. Na figura 2.5 é ilustrado esse componente. Durante a parte de atividade normal, o componente consegue suprir as requisições de serviço, se necessário, fazendo requisições a outros componentes, retornando respostas normais. Entretanto, três categorias de exceções podem ocorrer, forçando o componente a mudar para a porção de atividades excepcionais. A primeira categoria de exceções são as internas, que ocorre quando um componente detecta uma circunstância inesperada durante seu fluxo de execução normal, nesse momento um tratador local é ativado. Nesse caso, um tratador constitui a parte da atividade excepcional, que seria a parte do código do software responsável por prover medidas específicas de como lidar com a exceção levantada. Já a segunda categoria compreende as exceções de interface, que são lançadas quando um serviço é requisitado a um componente que não dispõe de tal serviço ou foi requisitado de maneira inadequada. A última categoria é a de exceções de falha, que são sinalizadas quando um componente não consegue fornecer um serviço conforme sua especificação (GARCIA et al., 2001; DAMASCENO, 2006). Todas essas categorias de exceções podem levar um determinado componente a um estado excepcional. Contudo, se as exceções forem tratadas adequadamente, o dado componente pode retornar ao seu estado de funcionamento normal. 2.3.1 Principais Requisitos Uma taxonomia com dez aspectos importantes para o tratamento de exceções em sistemas construídos utilizando um paradigma orientado a objetos foi elaborada em (GARCIA et al., 2001). A partir desses aspectos, Damasceno (2006) destacou cinco que se relacionam com o tratamento de exceções em aplicações móveis sensíveis ao contexto, descritos a seguir. A1 – Representação da exceção: que permite que exceções sejam utilizadas e processadas internamente aos sistemas, podendo estar representadas sob desde uma forma simples de tipos de dados (e.g., um número inteiro ou uma string) até a forma de objetos completos; A2 – Separação entre exceção externa e interna: essa característica permite a diferenciação entre exceções levantas dentro de um componente das que foram sinalizadas (ou propagadas, utilizando um termo mais apropriado) até ele mas que foram levantadas internamente a outro(s) componente(s); A3 – Localização de tratadores: que possibilita a busca por tratadores em diferentes regiões protegidas, que vão desde a porções de código dentro de um objeto de uma aplicação orientada a objetos até o escopo da própria aplicação onde encontram-se tratadores globais (que são válidos em qualquer parte da aplicação); A4 – Associação de tratadores: que realiza a ligação entre os tratadores e as regiões protegidas onde alguma exceção deve ser tratada. Essa ligação pode ser realizada de forma estática, dinâmica ou semi-dinâmica; e 36 A5 – Propagação de exceção: uma exceção é propagada quando um tratador local para uma ocorrência de exceção não é localizado, logo a exceção pode ser propagada, ou enviada, para um outro componente. Nesta dissertação, em busca de simplificar as principais funcionalidades de um mecanismo de tratamento de exceções, esses aspectos são considerados como parte de três requisitos, que são: i) detecção de exceções, que envolve os aspectos A1, A2 ; ii) seleção de tratadores, que envolve os aspectos A3 e A4; e iii) propagação de exceções, que é semelhante ao aspecto A5. 2.3.2 Tratamento de Exceções Sensível ao Contexto Apesar do tratamento de exceções ser uma técnica já bastante utilizada no desenvolvimento de sistemas tradicionais, para o desenvolvimento de sistemas ubíquos, por exemplo, essa técnica ainda não é muito empregada. Isso ocorre por causa dos requisitos desafiadores desse tipo de sistema. A sensibilidade ao contexto é um desses requisitos que dificultam o tratamento de exceções em sistemas não tradicionais. Em sistemas ubíquos, assim como durante o comportamento normal desses sistemas o contexto exerce forte influência, podendo, por exemplo, fazer com eles se adaptem, durante o comportamento anormal ele também deve ser considerado. Logo, para o tratamento de exceções em sistemas desse tipo a sensibilidade ao contexto torna-se importante. Beder e Araújo (2011), em seu trabalho sobre tratamento de exceções sensível ao contexto aplicado a um middleware multi-camadas para redes de sensores sem fio, identificaram que a caracterização de uma exceção pode depender do contexto, pois o estado de um sistema pode ser considerado errôneo dado uma condição específica do contexto e outro momento, em um contexto diferente, pode não ser. O trabalho desse autores demonstra a importância de se considerar a necessidade de se tratar exceções de forma sensível ao contexto, assim como também já foi feito para aplicações móveis sensíveis ao contexto em (DAMASCENO et al., 2006a; DAMASCENO, 2006; DAMASCENO et al., 2006b). Damasceno et al. (2006a) criaram a definição de contextos excepcionais, que são uma ou mais condições associadas ao estado do contexto as quais juntas denotam uma falta no ambiente, hardware ou no próprio software. Um contexto excepcional caracteriza uma situação excepcional de uma entidade, onde “excepcional” pode variar de acordo com os requisitos da aplicação. Os autores apresentam um exemplos simplório, mas bastante didático, da caracterização de um contexto excepcional com uma situação onde a temperatura de ambiente excede um limite estabelecido para um sistema, nesse caso essa condição indica para o sistema que algum problema ocorreu. Uma outra situação que também é apresentada como exemplo é a alteração na frequência cardíaca de um paciente, para um sistema de monitoramento de saúde. Semelhante a definição de contexto excepcional, (KULKARNI; TRIPATHI, 2010) identificaram a concepção de invalidação de contexto, que ocorre quando uma aplicação requer que algum contexto específico permaneça válido durante a execução de alguma tarefa do sistema e essa condição é violada. Segundo os autores, ao ocorrer uma invalidação de contexto em uma aplicação, as suas tarefas que dependem de um estado de contexto específico tornam-se propensas a falhar. 37 Para viabilizar o tratamento de exceções sensível ao contexto foi também definida uma nova categoria de exceções, que são as exceções contextuais, identificadas em (DAMASCENO et al., 2006a). Essas exceções modelam um contexto que caracteriza uma situação excepcional de uma entidade, onde “excepcional” pode variar de acordo com os requisitos da aplicação. Pode ser considerado, então, como contexto excepcional um conjunto indesejado de condições que podem estar relacionadas a diferentes tipos de informação. Conceitos importantes, como o de propagação de exceções e busca por tratadores, foram revisitados em (DAMASCENO et al., 2006a) incorporando a sensibilidade ao contexto a essas funcionalidades do tratamento de exceções. A propagação de exceções, tradicionalmente, acontece quando uma exceção não pode ser tratada localmente (por exemplo, pela falta de um tratador adequado) e é então sinalizada para outro elemento do sistema, geralmente de mais alto nível. Já a busca por tratadores, como mencionado na seção anterior, está relacionada à associação entre diferentes regiões protegidas e a escolha de tratadores (DAMASCENO, 2006). Para (DAMASCENO, 2006), assim como durante a execução normal do sistema, durante a atividade excepcional, o contexto pode afetar o comportamento do software influenciando na forma como essas funcionalidades de escolha de tratadores, propagação e o próprio tratamento das exceções são realizadas. Outro avanço em relação ao tratamento de exceções sensível ao contexto foi exposto em (LOPES; CACHO; BATISTA, 2007), onde foi proposto um mecanismo de composição de eventos para a resolução de exceções. Em geral, a resolução de exceções é realizada como uma função de um mecanismo de resolução de exceções, que determina qual estratégia ou tratamento deve ser realizado nos casos onde duas ou mais exceções ocorrem concorrentemente. Duas abordagens são utilizadas para resolução de exceções (CAMPBELL; RANDELL, 1986; LOPES; CACHO; BATISTA, 2007), a hierarquia de exceções e a árvore de exceções. Na estratégia de hierarquia de exceções ao ocorrem exceções concorrentemente são analisadas as prioridades atribuídas a cada uma das exceções, dessa forma a que possuir maior prioridade será considerada de maior nível e será aplicado o seu tratamento. Já na estratégia de árvore, as exceções são organizadas em uma estrutura de dados de árvore onde a raiz indica a exceção mais genérica e as folhas as exceções mais específicas. Nessa segunda estratégia a função de resolução das exceções deve ser capaz de encontrar a raiz da menor árvore que contém as exceções que tenham ocorrido concorrentemente. Logo, pode-se buscar o tratamento de uma exceção mais geral. Lopes, Cacho e Batista (2007) utilizaram essa estratégia em árvore para prover a resolução de eventos atribuídos a alterações nas condições de contexto que podem caracterizar exceções contextuais. Estendendo a noção de exceções contextuais, Cho e Helal (2011) apontam a necessidade do tratamento de exceções baseadas em situações. Uma situação para esses autores é um conceito mais amplo do que o conceito de contexto, pois envolve uma sequência temporal de estados do contexto. Por exemplo, uma situação excepcional pode ser caracterizada através da observação de sensores de luminosidade, ao perceber que o contexto de iluminação está alternando entre “iluminado” e “escuro” repetidamente em um intervalo de tempo determinado (e.g., 10 ou 30 segundo) pode significar algum problema nos acionadores da iluminação 38 ou problemas no fornecimento de energia. Assim pode-se detectar que algum tratamento excepcional deve ser realizado. Por último, um outro aspecto do tratamento de exceções sensível ao contexto, diferente do tratamento de exceções tradicional, é a necessidade de se especificar níveis de escopo de tratamento mais específicos e flexíveis. O escopo de tratamento é a porção protegida de código que poderá se ligar a tratadores de exceções. No tratamento de exceções tradicional o escopo de tratamento de uma exceção está normalmente confinado apenas a um método, objeto ou mesmo ao dispositivo sob o qual o sistema esteja executando. Entretanto, esses níveis de escopo não são suficientes para o tratamento sensível ao contexto. Damasceno et al. (2006a) identificaram algumas circunstâncias em que o tratamento de exceções poderia envolver diversos dispositivos, dependendo de sua localização ou outras informações de contexto (servidor ao qual ele está conectado, grupo de dispositivos a qual ele pertença e outros). Assim, foi proposto pelos autores quatro níveis de escopo, que são: dispositivo, servidor, localização ou grupos de dispositivos. Para os autores, uma exceção contextual deve ser capaz de ser propagada entre esses diversos níveis de escopo, dependendo da severidade especificada para uma exceção. 2.4 Conclusão Este capítulo teve como finalidade delinear o embasamento teórico essencial para essa dissertação. Nesse capítulo foram apontados alguns conceitos e técnicas importantes relacionadas a computação ubíqua, ao MDBT e ao tratamento de exceções sensível ao contexto, que compõem a temática desta dissertação. Sobre a computação ubíqua, além de terem sido expostos algumas de suas definições foram listadas as principais características desse paradigma de computação. O levantamento dessas características é fundamental para possibilitar o entendimento sobre as vantagens da utilização de sistemas de suporte (como o SysSU) e do MDBT. Ademais, também permite perceber alguns motivos pelos quais o tratamento de exceções tradicional não consegue suprir as necessidades desse domínio. Além disso, nesse capítulo foram apresentados conceitos relacionados a dependabilidade, delineado seus atributos, suas ameaças e os meios pelos quais se pode alcançá-la. Dentre os meios para se buscar a dependabilidade em sistemas de software é destacado neste capítulo o tratamento de exceções. Este meio é uma técnica de tolerância a faltas que pode ser aplicado também a sistemas ubíquos. Por fim, para que o tratamento de exceções possa suprir alguns requisitos desses sistemas não tradicionais, é agregado a essa técnica a capacidade de sensibilidade ao contexto. O próximo capítulo apresenta e discute trabalhos relacionados que trouxeram contribuições ligadas ao tratamento de exceções ou ao desenvolvimento de sistemas seguindo uma abordagem orientada a tarefas. Além disso, no capítulo 3 é mostrado um breve comparativo entre esses trabalhos. 39 3 TRABALHOS RELACIONADOS Diversas pesquisas apresentaram fortes contribuições relacionadas ao tratamento de exceções, ao desenvolvimento de sistemas ubíquos e ao desenvolvimento de sistemas seguindo uma abordagem orientada a tarefas. Um resumo dessas pesquisas é descrito neste capítulo. Este capítulo está dividido em 10 seções. Destas, as oite primeiras analisam, isoladamente, contribuições relacionadas ao tratamento de exceções e a esta pesquisa. Nas pesquisas realizadas nesta dissertação não foi encontrado nenhum trabalho que abordasse de forma simultânea o desenvolvimento de sistemas ubíquos, o tratamento de exceções e a utilização do MDBT. Uma discussão comparativa destas investigações é descrita na seção 3.9. Por último, a seção 3.10 apresenta as conclusões deste capítulo. 3.1 Exlets Adams et al. (2007) propuseram uma abordagem dinâmica, extensível e sensível ao contexto para o tratamento de exceções em workflows, sob uma plataforma web. A abordagem dos autores foi desenvolvida sob um ambiente de código aberto e vastamente utilizado para a execução de workflows chamado YAWL1 (AALST et al., 2004). Antecedendo a descrição da proposta de Adams et al., faz-se necessário contextualizar o YAWL. Este ambiente é composto por uma linguagem para especificação de workflows, um motor de execução, capaz de instanciar os workflows especificados, e um conjunto de serviços que dão suporte a esse sistema. Uma arquitetura orientada a serviços foi tomada como base para o desenvolvimento do YAWL. Com essa breve descrição das principais características do YAWL, pode-se retomar a discussão sobre a proposta de Adams et al. . Detalhes sobre a implementação do YAWL estão disponíveis em (AALST et al., 2004). Na proposta de Adams et al. foi criado um serviço, sob o YAWL, para orquestrar o tratamento de exceções em instâncias de workflows. Nesta proposta, o tratamento de exceções é fornecido por processos denominados Exlets. Os Exlets podem ser criados e atribuídos aos passos que compõem os workflows. O conjunto de Exlets atribuídos a um determinado passo é denominado como repertório2 . Desse modo, quando lançada uma exceção, é verificado o “repertório” de Exlets do ponto do workflow onde a exceção foi lançada. Um Exlet é selecionado do repertório de acordo com o tipo de exceção detectada. Além do tipo de exceção, para a seleção de um Exlet, são analisadas informações de contexto, que podem ser provenientes do estado interno do workflow, de dados históricos obtidos através dos logs dos processos, e outras fontes externas, estas ultimas sendo extensíveis. 1 Sigla adotada pelos autores como acrônimo para Yet Another Workflow Language, do inglês. adotado pelos próprios autores. 2 Termo 40 Na figura 3.1, é exemplificado a utilização dos Exlets como unidade de tratamento excepcional em um workflow simples. Na camada inferior desta figura está representada a especificação do workflow para uma atividade chamada “OrganiseConcert”, composta por: uma condição de inicio, três passos dessa atividade (“book stadium”,“sell tickets” e “do show”) e uma condição de saída. Para esse atividade, no seu passo “do show”, foram definidos quatro Exlets, ilustrados na camada do meio. Já na camada superior, é mostrado um fluxo compensatório necessário para tratar uma exceção detectada no passo “do show”. Figura 3.1: Hierarquia de processos de um Exlet (ADAMS et al., 2007). A abordagem dos autores é classificada como extensível por oferecer a possibilidade de criação de novos Exlets. Ademais é considerada dinâmica por permitir a seleção de Exlets, em tempo de execução, para tratar uma exceção. Essa seleção, por sua vez, é realizada levando em consideração informações de contexto. Apesar da utilização dos Exlets permitirem o tratamento de exceções em workflows, essa abordagem é viável somente por conta da infraestrutura centralizada do YAWL. Além disso, uma forte limitação da proposta de Adams et al. (2007) em relação a proposta apresentada nesta dissertação, é que o contexto é considerado apenas na seleção dinâmica de um Exlet. Outros aspectos do tratamento de exceções sensível ao contexto, como a propagação ou o próprio tratamento, não foram contemplados pelos autores. 3.2 CAMA Iliasov e Romanovsky (2005) propuseram um framework, chamado CAMA3 , para o desenvolvimento de aplicações utilizando o paradigma de agentes móveis. Um agente móvel é uma porção de software independente, capaz de migrar entre dispositivos interconectados em uma 3 Nome adotado em referência a expressão Context-Aware Mobile Agents, do inglês 41 rede, que realiza uma funcionalidade específica (COULOURIS et al., 2011). Esse paradigma promove a abertura dos sistemas, flexibilidade e escalabilidade. Além dessas características, o paradigma de agentes móveis possibilita lidar com mobilidade de código e dos dispositivos em uma aplicação (ARIEF; ILIASOV; ROMANOVSKY, 2006). O CAMA foi desenvolvido buscando facilitar o desenvolvimento disciplinado de aplicações desenvolvidas utilizando agentes móveis, abertas e tolerantes a falhas, através de um conjunto de abstrações que possibilitam o tratamento de exceções. Outro ponto que deve ser destacado do CAMA é a capacidade de lidar com o tipo de comunicação dessas aplicações, que são de natureza assíncrona e dinâmica, através da utilização de um modelo de coordenação baseado em espaço de tuplas. Na figura 3.2, são ilustradas as principais abstrações do CAMA, que são: Plataforma, Agente, Escopo e Localização. Os Agentes, em CAMA, são as entidades ativas do sistema. Esses componentes ativos são executados sob uma Plataforma, que, por sua vez, pode abrigar um ou vários agentes. Além de prover o ambiente de execução para os agentes, uma Plataforma fornece uma interface para um middleware de localização. Já a definição de Escopo, para Arief, Iliasov e Romanovsky, está relacionada ao provimento de espaço de coordenação no qual um conjunto de agentes podem interagir. Um conjunto de Escopos formam uma Localização. Além disso, uma Localização pode estar associada a uma localização física particular e pode impor restrições sobre os tipos de escopos suportados. É através de uma localização que os agentes envolvidos em um mesmo escopo conseguem coordenar suas ações para a realização de alguma atividade (ARIEF; ILIASOV; ROMANOVSKY, 2006). Figura 3.2: Abstrações do CAMA, adaptado de (ARIEF; ILIASOV; ROMANOVSKY, 2006). Através da utilização dessas abstrações básicas, os autores definiram três operações fundamentais para o tratamento de exceções no CAMA, de forma a não violar o requisito de anonimidade do paradigma de agentes, são elas: • raise - que permite “levantar” uma exceção como reação a uma mensagem para um agente ou para todos os agentes participantes de um escopo; • check - verifica e “levanta” uma exceção, caso haja alguma pendente para o agente que chamou esta operação; e 42 • wait - aguarda uma exceção inter-agentes surgir para “levantá-la” para um agente. Essas três operações são utilizadas basicamente para a propagação de exceções entre agentes, de forma sensível ao contexto. Já as ações de recuperação ou tratamento das exceções são implementadas por tratadores específicos das aplicações, que porventura estejam ligados aos agentes. De forma mais direta, o CAMA provê o mecanismo de propagação de exceções sensível ao contexto, mas deve ser complementado com o tratamento em nível de aplicação. Através da discussão sobre a importante contribuição na propagação de exceções de forma sensível ao contexto entre agentes móveis, são vislumbradas outras possibilidades de utilização do contexto para a detecção e tratamento das exceções. Logo, pode ser considerado uma fronteira entre as propostas de Arief, Iliasov e Romanovsky e a desta dissertação, a utilização do contexto apenas para delimitar o escopo de propagação das exceções entre agentes, e não para a detecção e o tratamento, como neste trabalho. 3.3 Task Execution Framework for Autonomic Ubiquitous Computing Um framework com suporte a execução de tarefas para computação ubíqua e autonômica foi apresentado em (RANGANATHAN, 2005). Este framework foi proposto para possibilitar a criação de tarefas em ambientes físicos garantindo-lhes as propriedades de auto-configuração, auto-cura e adaptação. A implementação deste framewrok utilizou alguns serviços do meta-sistema operacional chamado Gaia, que permite coordenar os recursos de um ambiente físico, nesse caso denominado Active Space. Conceitualmente, um Active Space é definido como uma coleção de entidades físicas interconectadas, sendo essas entidades formadas pelo ambiente físico, os dispositivos, objetos, serviços e aplicações (ROMáN et al., 2002). Com o uso deste framework é possível obter um nível básico de auto-configuração e auto-cura em tarefas em execução no ambiente, através da seleção automática ou semiautomática de parâmetros especificados em tempo de projeto. A figura 3.3 mostra uma visão geral da forma de funcionamento e da arquitetura desta solução. 43 Figura 3.3: Visão geral da arquitetura (RANGANATHAN; CAMPBELL, 2005). Assim como ilustrado na figura 3.3, a execução de uma tarefa pode ser iniciada pela interação entre algum usuário e uma interface de controle. Além disso, uma tarefa pode ser iniciada por algum serviço em resposta a algum evento. O serviço de execução das tarefas (ilustrado na figura como Task Execution Service) é o responsável por processar as diferentes atividades4 de uma tarefa. Nesse processo, a especificação das tarefas e os seus possíveis parâmetros de configuração da execução são fornecidos como entrada para o serviço. Dessa forma, ao executar uma tarefa, o serviço é capaz de adaptá-la a fim de contornar a ocorrência de falhas. É interessante evidenciar que a proposta de Ranganathan não está diretamente relacionada ao tratamento de exceções. Entretanto, ela provê melhoria na robustez das aplicações desenvolvidas uma vez que os mecanismos de auto-configuração e auto-cura conseguem contornar alguns tipos de falhas. Apesar dessa capacidade de adaptação fornecer certo grau de robustez para execução de uma determinada tarefa, não extingue-se a necessidade de um mecanismo de tratamento de exceções. É possível que ocorram falhas, durante execução de determinados tipos de tarefas, as quais a simples adaptação baseada em parâmetros previamente fornecidos não seja suficiente para tratar adequadamente. Além disso, a utilização de um mecanismo de tratamento de exceção sensível ao contexto possibilita a especificação de exceções semanticamente mais ricas e de comportamentos excepcionais mais flexíveis. 3.4 Tratamento de Exceções com o MoCA Dentre os trabalhos relacionados a esta dissertação, destaca-se ainda a proposta apresentada em (DAMASCENO, 2006). Neste trabalho, os autores conseguiram, dentre outras coisas, propor e implementar um mecanismo de tratamento de exceções sensível ao contexto para 4 Neste caso, os autores usam o termo “atividades” para se referir aos passos que compõem uma tarefa. 44 aplicações móveis. Para a implementação da solução, os autores utilizaram o middleware MoCA (SACRAMENTO et al., 2004). O MoCA permite a construção de aplicações móveis e colaborativas sob um modelo baseado em publish-subscribe para coordenação dos agentes de software. Além disso, este middleware possui serviços, incorporados a ele, que possibilitam aos agentes que compõem uma determinada aplicação perceber o contexto (DAMASCENO et al., 2006a). Damasceno et al. estabeleceram dois conceitos fundamentais para esta dissertação, os conceitos de contexto excepcional e escopo. Para os autores, é denominado contexto excepcional um conjunto formado por uma ou mais condições contextuais que denotem uma falta no ambiente, hardware ou software. Um contexto excepcional corresponde a um conjunto de condições contextuais indesejadas ou perigosas e podem estar associadas a um usuário específico, a um agente da aplicação ou a um dispositivo móvel (DAMASCENO et al., 2006a). Logo, os autores estabeleceram a sua definição de escopo com a delimitação de quatro níveis, nos quais uma exceção contextual pode ser capturada, sendo eles: um dispositivo, um grupo de dispositivos, um servidor e uma região. A figura 3.4 ilustra como são formados os diferentes níveis de escopo. Figura 3.4: Cenário com diferentes escopos (DAMASCENO et al., 2006a). Esse conceito de escopo é indispensável para o gerenciamento dos fluxos resultantes da detecção de contextos excepcionais nos agentes de uma aplicação. A forma como o mecanismo proposto gerencia esses fluxos está organizada em quatro funcionalidades principais, que são: • detecção de exceções contextuais, • busca sensível ao contexto de tratadores, • tratamento sensível ao contexto, e • propagação sensível ao contexto de exceções. 45 Essas funcionalidades abrangem os principais requisitos do tratamento de exceções, descritos na subseção 2.3.1 e discutidos em (GARCIA et al., 2001), agregando-lhes a capacidade de levar em consideração o contexto. Tais funcionalidades do mecanismo são providas através de componentes definidos em uma arquitetura de alto nível. A figura 3.5 mostra os componentes dessa arquitetura e como eles estão organizados. Figura 3.5: Arquitetura para tratamento de exceções sensível ao contexto (DAMASCENO, 2006). Assim como está sintetizado em (DAMASCENO et al., 2006b) e ilustrado na figura 3.5, o Middleware Pub/Sub é um componente externo que representa a infraestrutura publish-subscribe utilizada para coordenação dos agentes e recuperação das informações de contexto. No caso da implementação específica de Damasceno (2006) é utilizado o MoCA. Já o componente ContextualException é o responsável pela especificação de exceções contextuais e por subscrever interesse a elas, quando associado um contexto excepcional. É esse componente que levanta as exceções contextuais quando são sinalizadas as ocorrências das condições de contexto excepcionais, ou quando são solicitadas pelo componente de propagação (o Exception Propagation). Relacionados diretamente as funcionalidades de busca de tratadores e do tratamento em si, de forma sensível ao contexto, estão os componentes ExceptionHandling Strategy, Handling Scope e Hanlder. O ExceptionHandling Strategy possui a atribuição de gerenciar as exceções e seus respectivos tratadores, permitindo a especificação de estratégias de busca de tratadores e a ordem de prioridade entre os tipos de escopos. Esses escopos são gerenciados pelo Handling Scope, que lida com quais tratadores e dispositivos estão associados a um determinado escopo. Por último, o componente Handler é o responsável pela especificação dos tratadores e pela verificação do contexto para habilitá-los quando necessário. 46 Nesta dissertação, o mecanismo proposto pelos autores é reconhecido como uma contribuição pertinente relacionada ao tratamento de exceções sensível ao contexto. Além disso, o mecanismo foi consolidado de forma reusável, flexível e com uma clara separação entre o o fluxo normal e excepcional. Apesar da solução proposta possuir diversos aspectos positivos e lidar de forma primorosa com o tratamento de exceções contextuais em aplicações desenvolvidas sobre um modelo baseado em agentes móveis, ela não consegue cobrir alguns pontos importantes relacionados a computação ubíqua, como, por exemplo, permitir o tratamento de exceções de forma mais desacoplada ou mediante alguma indisponibilidade temporária de conexão com o ambiente. Nesse sentido o trabalho dos autores diferencia-se da proposta desta dissertação em alguns aspectos. Um primeiro aspecto a ser destacado é que, no modelo de desenvolvimento baseado em agentes o qual a proposta dos autores se aplica, não há uma noção de unidade de aplicação, sendo difícil especificar o fluxo de atividades de caráter globais ou colaborativas realizadas no sistema. Nesse caso, as exceções contextuais são tratadas apenas com medidas executadas internamente a um agente. Outro ponto de melhoria é em relação a pró-atividade do tratamento de exceções apontado pelos autores, que não ocorre efetivamente. Isso porque o modelo de comunicação/coordenação publish-subscribe utilizado obriga aos elementos dos sistemas informarem explicitamente o interesse na notificação da ocorrência de determinadas exceções. Já no mecanismo proposto nesta dissertação, exceções contextuais de caráter global podem prover maior grau de pró-atividade no tratamento dessas condições adversas para os sistemas, mas essas características são explicadas em detalhes no Capítulo 4. Além disso, já havia sido apontado pelos próprios autores, em (DAMASCENO, 2006), a necessidade de avaliar o modelo de tratamento de exceções adotado no mecanismo proposto utilizando outros paradigmas de coordenação, como, por exemplo, o paradigma baseado em espaços de tuplas (adotado nesta dissertação). A utilização deste paradigma de coordenação possibilita a construção de sistemas com maior nível de desacoplamento entre os elementos que os compõem, característica fundamental para os sistemas ubíquos. Por fim, não estava no escopo de trabalho de Damasceno (2006) o suporte a um modelo de programação orientado a tarefas, sendo este um dos diferenciais mais importantes em relação ao mecanismo que é proposto nesta dissertação. A utilização do MDBT pode ajudar tanto na melhoraria da separação da implementação do comportamento normal e excepcional das aplicações quanto para prover uma melhor especificação dos fluxos normais e excepcionais, e na definição de tratamentos excepcionais proativos. A abstração de tarefa utilizada nessa dissertação pode ser capaz inclusive de cobrir o nível de escopo de papel do agente no sistema, que apesar de ter sido apontado por Damasceno não foi implementado. 3.5 Situation-Based Exception Detection Em (CHO; HELAL, 2011) é proposto uma nova estratégia de definição de exceções com base no conceito de situações. Esse conceito foi definido com intuito de estender a noção 47 de contexto. Enquanto o contexto pode ser visto como um mapeamento entre itens de contexto, que estão ligados a atributos do ambiente, e os possíveis valores que eles podem assumir, por exemplo “humidade=baixa” e “temperatura=alta”, uma situação é vista como uma sequência de contextos em conjunto com os eventos ocorridos no sistema. Um aspecto interessante dessa solução é a capacidade de detectar exceções contextuais que não poderiam ser detectadas com apenas a observação de snapshots do contexto, mas sim com a sua observação ao longo de uma janela de tempo. Por exemplo, como discutido pelos autores, é possível detectar o mal funcionamento de um sensor de presença, caso algum usuário entre duas vezes no mesmo ambiente, sem que uma saída tenha sido efetuada. Logo, essa solução está fortemente relacionada apenas com a a detecção e avaliação de exceções contextuais de forma mais rica. Para o tratamento de exceções contextuais lançadas a partir da detecção de padrões de situações, os autores assumem uma estratégia baseada em regras ECA (Evento-CondiçãoAção) (CHEN et al., 2010). Apesar da solução proposta por Cho e Helal (2011) ser um passo importante em relação a detecção de exceções contextuais em sistemas pervasivos, outros aspectos do tratamento de exceções, como a seleção de tratadores e o tratamento adaptativo, não foram considerados. 3.6 Tratamento de Exceções em Active Space Active Space é um conceito que foi apresentado em (ROMáN et al., 2002) para se referir a ambientes físicos, coordenados por uma infraestrutura de software sensível ao contexto, capazes de permitir a interação de aplicações em dispositivos móveis de forma transparente. Kulkarni e Tripathi (2010), considerando a utilização de um sistema de middleware baseado em Active Space, propuseram um framework para o desenvolvimento de aplicações colaborativas sensíveis ao contexto a partir de suas especificações em alto nível. No framework proposto pelos autores foi adotado um paradigma de programação generativo5 , onde as especificações das aplicações sensíveis ao contexto são definidas utilizando um modelo de programação específico do domínio (expresso em XML). A partir dessas especificações os ambientes de execução das aplicações são gerados e executados pelo middleware. As aplicações, nesse caso, são especificadas a partir da abstração de “Atividade” (Activity, do inglês). Um atividade, segundo os autores, define um espaço compartilhado de objetos e um conjunto de papéis. Uma atividade define um agrupamento, ou namespace, de objetos, papéis e reações. Um objeto, segundo a definição dos autores, é a abstração provida em uma atividade para permitir o acesso a recursos e serviços, em active spaces, necessários para as aplicações. Um papel provê um conjunto de operações e limita os privilégios dos usuários em relação a execução dessas operações em tarefas de aplicações. As operações de um papel podem envolver 5 Neologismo adotado como tradução para o termo Generative, do inglês. 48 uma ou várias ações e são realizadas através de chamadas aos serviços. Essas operações podem ser relacionadas com o conceito de tarefa, já apresentado na subseção 2.1.3. Já as reações possuem definição e funcionamento semelhantes às operações de papéis, diferente apenas porque estas são iniciadas com a detecção de eventos e não pela interação com algum usuário (como são nas operações de um papel). Na figura 3.6(a) é apresentado, de forma geral, como são organizadas as formas de interação entre esses conceitos para execução de operações. Duas formas de interação são definidas, que são: • Method Invocation Model, onde uma ação envolve apenas a invocação de métodos de um objeto (por exemplo, como ocorre em uma reação); • Session Interaction Model, onde a invocação de uma ação resulta no inicio de um seção entre o usuário e os objetos. Além disso, na figura 3.6(b) é ilustrado a organização desses conceitos em um estudo de caso de uma aplicação de reprodução de música móvel sensível ao contexto, descrita em (KULKARNI; TRIPATHI, 2010). (a) Modelos de interação. (b) Visão esquemática de um o estudo de caso destacando a organização das abstrações do framework. Figura 3.6: Visão geral da organização da proposta de (KULKARNI; TRIPATHI, 2010). Tais conceitos e estratégias de interação estabelecidos por Kulkarni e Tripathi possibilitaram a definição de um modelo de recuperação de erro para aplicações colaborativas sensíveis ao contexto. Esse modelo é considerado a principal contribuição apresentada em (KULKARNI; TRIPATHI, 2010). Ele adota uma estratégia de recuperação por avanço (foward error recovery, do inglês), que é empregada em mecanismos divididos em duas categorias: (i) tratamento síncrono de exceções e (ii) tratamento assíncrono de eventos. 49 Esses mecanismos permitem que as aplicações desenvolvidas tratem falhas de diferentes tipos, tais como: falhas em adaptações disparadas por condições de contexto6 , falhas de ligação7 de serviços, exceções levantadas pelos próprios serviços e invalidação do contexto. Em sistemas sensíveis ao contexto, é possível que adaptações no próprio sistema sejam requiridas com mudanças do contexto. Essas adaptações, no caso das aplicações colaborativas sensíveis ao contexto, podem implicar na busca por serviços no active space. Para os autores, falhas durante essas adaptações podem ser causadas durante a descoberta de serviços requeridos, caso não sejam encontrados serviços disponíveis no ambiente que satisfaçam as condições de busca. Já as falhas de ligação de serviços estão relacionadas a condições onde os serviços aos quais um objeto deve se “conectar” estão inacessíveis. Essa condição de inacessibilidade, por sua vez, pode ser causada, por exemplo, por problemas de conectividade na rede. As exceções levantadas pelos próprios serviços são exceções clássicas que podem ser disparadas internamente dos serviços de domínio. Por fim, a invalidação do contexto possui relação a manutenção de uma condição de contexto específica durante toda a execução de uma operação, atividade ou aplicação. Caso essa condição não seja satisfeita, a aplicação pode vir a falhar. O modelo de recuperação de falhas por avanço de Kulkarni e Tripathi é uma solução complexa, no sentido de que envolve uma série de abstrações e níveis de escopo de tratamento de falhas. Entretanto essa solução oferece uma forma poderosa para criação de aplicações sensíveis ao contexto robustas. Algumas abstrações do modelo definido pelos autores, como as reações e os eventos de invalidação de contextos, serviram como base para criação do mecanismo de tratamento de exceções apresentado como contribuição desta dissertação. Um aspecto a ser destacado é o trade-off 8 da utilização de uma abordagem generativa no framework desenvolvido pelos autores. Essa abordagem facilita o desenvolvimento das aplicações, uma vez que elas são geradas a partir de uma especificação de mais alto nível. Porém, essa facilidade implica na perda de flexibilidade para modificação ou extensão das aplicações geradas. Apesar do modelo de recuperação proposto ser bastante rico e permitir lidar com vários tipos de situações excepcionais, um outro ponto importante deve ser apontado, os autores não tinham como alvo a implementação de um mecanismo capaz de atender aos requisitos de seleção de tratadores, propagação de exceções e tratamento de exceções, todas de forma sensível ao contexto de forma mais explícita. Ainda assim, o contexto é utilizado no modelo e no mecanismo dos autores como precondição para execução das operações e das ações de recuperação. 6 context-driven reconfiguration, do inglês. do inglês. 8 Termo em inglês que expressa a ideia de optar por beneficiar algo em detrimento de alguma perca. 7 Binding, 50 3.7 Tratamento de Exceções para Service Component Architecture Diversas tecnologias podem ser usadas para implementar-se uma arquitetura sob o paradigma de orientanção a serviços (Service Oriented Architecture - SOA), como por exemplo, WebServices baseados em padrões XML e SOAP9 . Service Component Architecture (SCA) é uma outra tecnologia que padroniza a composição e implantação de aplicações orientadas a serviços (MARGOLIS; SHARPE, 2007). Leite, Rubira e Castor (2011) propuseram um modelo de tratamento de exceções coordenadas, buscando prover maior dependabilidade, para sistemas desenvolvidos utilizando SCA. Este modelo é fundamentado em um outro modelo de tratamento de exceções já bastante difundido, apresentado em (MILLER; TRIPATHI, 2002), chamado Guardian. O Guardian baseia-se na noção de tratamento de exceções globais. Exceções globais, no contexto de mecanismos de tratamento de exceções coordenadas, são exceções que necessitam ser manejadas de forma cooperativa por um conjunto de participantes (que em uma SCA, são os componentes de serviços). Por outro lado, uma exceção que pode ser tratada dentro dos limites de um participante é chamada de exceção local (MILLER; TRIPATHI, 2002). O Guardian utiliza uma abstração de árvore para resolução de exceções diferentes levantadas concorrentemente. Resolver uma exceção, nesse caso, é uma tarefa realizada por um “guardião” e tem como propósito encontrar o menor nó predecessor comum na árvore de exceções. Um “guardião” é uma entidade distribuída e global que orquestra as ações de tratamento de exceções, baseando-se em um conjunto de regras, para cada participante envolvido (MILLER; TRIPATHI, 2004). Leite, Rubira e Castor implementaram o modelo proposto em um framework, denominado por eles EH-SCA. No EH-SCA é adotado um modelo de programação, semelhante ao que foi definido para o Guardian em (MILLER; TRIPATHI, 2002)(MILLER; TRIPATHI, 2004), que consiste na invocação de primitivas de guarda pelos participantes utilizando padrões de programação prédefinidos (LEITE; RUBIRA; CASTOR, 2011). No EH-SCA foi, também, adotado um paradigma de programação orientado a aspectos (AOP) para permitir a separação entre o código de tratamento de exceções da parte de código que define o comportamento normal. Além disso, com uso de AOP, possibilitou-se a interceptação de exceções relacionadas a composição, em si, dos componentes de serviço, e não apenas as exceções das implementações desses serviços de forma individual. A proposta dos autores trouxe uma contribuição importante por demonstrar uma alternativa de tratamento de exceções sob uma arquitetura orientada a serviços, como SCA. Por outro lado, a proposta do autores distancia-se desta pesquisa no que diz respeito ao que é considerado contexto. Sob análise dos autores desta dissertação, contexto na proposta de Leite, Rubira e Castor tem forte ligação com uma definição de escopo entre os participantes, guardiões e grupos de guardiões, ao invés de tratar sobre as informações das condições que caracterizam um ambiente. Logo, não está no escopo da contribuição de Leite, Rubira e Castor a detecção de exceções contextuais. 9 Simple Object Access Protocol 51 Ademais, também não faz parte do escopo da contribuição dos autores o suporte a um modelo de desenvolvimento orientado a tarefas. 3.8 Verificação de Modelos para o Tratamento de Exceções Sensível ao Contexto A análise dos possíveis fluxos de execução de um software, através da utilização de especificações e técnicas de verificação formais, permite prover melhorias no seu nível de dependabilidade, já que torna-se possível validar tanto os seus fluxos de execução normais quanto os excepcionais (BRITO et al., 2009). Entretanto, apesar de existirem abordagens formais para modelar o comportamento adaptativo de sistemas ubíquos, ainda existem lacunas nessas abordagens para oferecer suporte a análise formal do tratamento de exceções sensível ao contexto nesses sistemas. Em busca de soluções para essas lacunas, Rocha e Andrade (2012) propuseram um modelo formal capaz de representar os estados de contexto de um sistema ubíquo e que possibilita raciocinar de forma automatizada sobre o comportamento excepcional do sistema. O modelo proposto busca oferecer meios para que os engenheiros de softwares responsáveis pela especificação e implementação do tratamento de exceções sejam capazes de responder alguns tipos de questionamentos, como os seguintes: Existe algum estado possível para o sistema onde um determinado tipo de exceção contextual seja lançada? Dado um estado do sistema, quais as exceções contextuais podem ser lançadas? Considerando a ocorrência de uma exceção contextual em um determinado estado do sistema, é possível que o sistema consiga tratar essa exceção e retornar para um estado correto? O modelo proposto pelos autores utiliza-se do formalismo das estruturas de Kripke para representar o comportamento de um sistema e de lógicas temporais para especificação das propriedades a serem verificadas. Essas estruturas são construídas sob a forma de um grafo orientado, onde os nós representam os possíveis estados do sistema e as arestas indicam as transições. Logo, o comportamento de um sistema, ou fluxo de execução, pode ser visto como uma sequencia de estados e transições. Os autores propuseram também, além do modelo capaz de representar o comportamento adaptativo e sensível ao contexto dos sistemas ubíquos, uma função de transformação capaz de derivar novos estados e novas transições possíveis em um modelo a partir de um conjunto finito de estados de contexto o qual o sistema deverá ser exposto. O objetivo dessa função é expandir o modelo inicial do comportamento do sistema com os possíveis fluxos excepcionais onde as propriedades do sistema devem ser mantidas. Apesar da proposta do autores possibilitar melhorias no grau de dependabilidade dos sistemas modelados e verificados, através de uma melhor compreensão dos fluxos adaptativos e dos fluxos excepcionais, essa solução aplica-se apenas em tempo de projeto. Não foi apresentado nenhum tipo de mapeamento, por exemplo, para um framework, para guiar a implementação e a execução de um sistema ubíquo modelado seguindo a proposta dos autores, buscando garantir que estas atividades sejam realizadas de forma fidedigna ao que foi modelado. 52 3.9 Discussão Entre os trabalhos discutidos neste capítulo, destaca-se a contribuição apresentada em (DAMASCENO et al., 2006a). Esta abordagem é a que atende de forma mais completa os requisitos para o tratamento de exceções apresentados na subseção 2.3.1, adicionando ainda a capacidade de tratar exceções de forma sensível ao contexto. A tabela 3.1 sumariza as características de cada um dos trabalhos relacionados apresentados neste capítulo quanto a estes requisitos e ao suporte ao modelo de desenvolvimento baseado em tarefas. A partir da análise das contribuições de Damasceno et al. (2006a) e Ranganathan (2005), apresentadas nas seções 3.3 e 3.4 e na tabela 3.1, é possível considerar que esses trabalhos, de forma complementar um ao outro, se relacionam fortemente aos objetivos buscados nesta dissertação. Dentre todos os trabalhos estudados, não foi encontrado nenhum mecanismo que fosse capaz de, simultaneamente, tratar exceções de forma sensível ao contexto e suportar o desenvolvimento de sistemas ubíquos sob a abstração de tarefas, cujos benefícios já foram discutidos anteriormente. Portanto, esta dissertação propõe um mecanismo de tratamento de exceções sensível ao contexto e, como forma de disponibilizá-lo aos desenvolvedores, o framework FRonTES. No capítulo 4 são descritos em detalhes, respectivamente, o framework e o mecanismo propostos. Tabela 3.1: Comparativo entre os trabalhos relacionados e os principais requisitos explorados nesta dissertação. Requisitos Detecção de Exceções Seleção Sensível ao Propagação de Exceções Tratamento de Exceções Orientação a Tarefas Sensível ao Contexto Contexto de Tratadores Sensível ao Contexto Sensível ao Contexto Soluções Iliasov e Romanovsky (2005) Ranganathan (2005) Damasceno et al. (2006a) Adams et al. (2007) Kulkarni e Tripathi (2010) Cho e Helal (2011) Leite, Rubira e Castor (2011) Rocha e Andrade (2012) Possui suporte 3.10 Possui suporte parcial Não possui suporte Conclusão Neste capítulo foram apresentados trabalhos relacionados que abordam o tratamento de exceções ou o desenvolvimento de sistemas seguindo uma abordagem orientada a tarefas. A análise desses trabalhos possibilita visualizar desafios existentes na interseção dessas áreas de pesquisa que ainda não foram fortemente explorados. Além disso, neste capítulo foram apresentados alguns aspectos dos trabalhos relacionados em uma análise comparativa. Através da análise desses trabalhos, é possível perceber que não foi encontrado nenhum mecanismo capaz de, simultaneamente, tratar exceções de 53 forma sensível ao contexto e suportar o desenvolvimento de sistemas ubíquos sob a abstração de tarefas, os quais já tiveram seus benefícios destacados anteriormente. No capítulo seguinte são detalhados o mecanismo de tratamento de exceções sensível ao contexto e o framework FRonTES. Estes são propostos nesta dissertação para prover simultaneamente o tratamento de exceções de forma sensível ao contexto e suportar o desenvolvimento de sistemas ubíquos sob a abstração de tarefas. 54 4 FRAMEWORK E MECANISMO PROPOSTOS Neste capítulo são detalhados o mecanismo de tratamento de exceções sensível ao contexto e o framework FRonTES. Estes são propostos nesta dissertação para prover simultaneamente o tratamento de exceções de forma sensível ao contexto e suportar o desenvolvimento de sistemas ubíquos sob a abstração de tarefas. Inicialmente, na seção 4.1 deste capítulo são retomadas os principais aspectos motivacionais deste trabalho. Nesta seção, uma visão geral sobre o mecanismo de tratamento de exceções sensível ao contexto e a sua implementação através do framework FRonTES são discutidos. Já na seção 4.2 é delineada a arquitetura que foi adotada e estendida para o desenvolvimento do FRonTES, assim como são apresentados os componentes adicionados a ela. Na Seção 4.3 é apresentado a principal contribuição desta dissertação, que é o mecanismo de tratamento de exceções contextuais proposto. Por fim, na seção 4.4, são discutidas as considerações finais sobre o framework e o mecanismo. 4.1 Visão geral da proposta Conforme já exposto nos Capítulos 1 e 2, o tratamento de exceções sensível ao contexto é fundamental para ajudar na solução de problemas relacionados a garantia de níveis elevados de dependabilidade em sistemas ubíquos. Um dos problemas nos quais mecanismos de tolerância a faltas podem ajudar, assim como o tratamento de exceções sensível ao contexto, por exemplo, é na manutenção da segurança e integridade física dos usuários de um sistema ubíquo durante o seu uso (CHETAN; RANGANATHAN; CAMPBELL, 2005). Nesse exemplo, o contexto pode auxiliar na elaboração ou escolha de tratamentos mais apropriados para situações excepcionais detectadas. Além disso, como já mencionado, a atividade de desenvolver e implantar sistemas ubíquos é complexa e passível de sofrer falhas que podem ser causadas por diferentes tipos de faltas. O tratamento de exceções, como já apresentado na Seção 2.3, não é uma atividade trivial. Essa atividade envolve desde a detecção de condições excepcionais, que podem ser relacionadas ou não ao contexto, durante a execução de um software até a propagação e o tratamento de exceções por componentes adequados. Para o tratamento de exceções que não estejam diretamente relacionadas a informações de contexto, diversos mecanismos de tratamento de exceção tradicionais podem ser utilizados. Mecanismos de tratamento de exceções, como também já apresentado anteriormente, proveem suporte a detecção e propagação de exceções, seleção de tratadores e controle do fluxo de execução normal e excepcional (GOODENOUGH, 1975b)(PARNAS; WüRGES, 1976)(GARCIA et al., 2001). Para permitir o tratamento de exceções contextuais, é proposto, como contribuição principal deste trabalho, um mecanismo de tratamento de exceções sensível ao contexto. Sobre esse mecanismo proposto, é importante destacar que ele agrega funcionalidades que permitem lidar com exceções contextuais, mas, ao mesmo tempo, não afeta ou dispensa os mecanismos disponibilizados nativamente em muitas linguagens de programação. O mecanismo proposto 55 é capaz de, por exemplo, funcionar concomitantemente com o mecanismo de tratamento de exceções tradicional da linguagem Java. Nesse exemplo, as exceções tradicionais podem ser protegidas e tratadas com blocos de código envolvidos pelas instruções reservadas try e catch, enquanto que exceções de mais alto nível que envolvam informações do ambiente, denominadas exceções contextuais, podem ser tratadas usando o mecanismo proposto nesta dissertação e apresentado na Seção 4.3. Um dos principais aspectos que corroboram para disponibilização do mecanismo proposto através de um framework é que essa forma de reuso concilia a flexibilidade necessária para criação de novas aplicações, sendo elas de um mesmo domínio, com o reuso de arquiteturas e componentes prontos. Essa estratégia de fornecer um framework para (i) reduzir o esforço e a dificuldade de desenvolvimento, provendo componentes que implementam funcionalidades e características complexas de um determinado nicho de aplicação; e (ii) aumentar a manutenibilidade, uma vez que alterações no framework são refletidas em todas as aplicações que o instanciam; é recorrente em algumas pesquisas realizadas (KULKARNI; TRIPATHI, 2010)(ENDRES; BUTZ; MACWILLIAMS, 2005)(VO; TORABI; LOKE, 2010)(SOUSA; GARLAN, 2002). Logo, com a utilização do framework FRonTES1 , a atividade de desenvolver sistemas ubíquos orientados a tarefas capazes de tratar exceções contextuais, em consequência do maior grau de reutilização, também pode se tornar mais simples. Outro aspecto que suscita a disponibilização do mecanismo proposto através de um framework é a característica de inversão de controle (IoC)2 (FAYAD; SCHMIDT; JOHNSON, 1999). Essa característica, comum aos frameworks, faz com que o controle do fluxo de chamada dos métodos dos objetos que compõem uma aplicação fique a cargo do próprio framework. Dessa forma, cabe aos desenvolvedores especificar as ações que devem ser realizadas em resposta a eventos provenientes dos frameworks utilizados, definidos através de interfaces e classes abstratas. Em relação ao desenvolvimento de sistemas ubíquos orientado a tarefas e ao tratamento de exceções sensível ao contexto, essa característica de IoC possibilita deixar a cargo do framework proposto e apresentado na seção 4.2 todo o controle do fluxo de execução das tarefas e do fluxo de tratamento das exceções contextuais previstas durante a instanciação das aplicações. Portanto, nesta dissertação, para materializar o mecanismo de tratamento de exceções sensível ao contexto, foi desenvolvido o framework FRonTES. Este framework incorpora abstrações, técnicas e componentes necessários para o funcionamento do mecanismo proposto. Uma implementação de referência do FRonTES3 foi desenvolvida sob a plataforma Android e com uso da linguagem Java. 1 Acrônimo adotado neste trabalho como referência para "Framework para o Desenvolvimento de Software Ubíquo Orientado a Tarefas com suporte ao Tratamento de Exceções Sensível ao Contexto". 2 IoC - Inversion of Control, do inglês. 3 Implementação de referência disponível através do endereço http://code.google.com/p/frontesframework/ , acessado em 09/08/2012. 56 4.2 FRonTES O mecanismo de tratamento de exceções sensível ao contexto incorporado ao FRonTES, e o próprio framework em si, apresentados neste capítulo, foram construídos através do reuso da arquitetura do SysSU (LIMA et al., 2011), já apresentada na Subseção 2.1.2. O SysSU foi adotado por permitir a comunicação e coordenação de agentes, em um sistema ubíquo, de forma desacoplada e interoperável. Além disso, esse sistema de suporte permite, através de um modelo de comunicação baseado em espaço de tuplas, a propagação e notificação de informações contextuais estruturadas na forma de tuplas. Assim, do mesmo modo que um estado de contexto pode ser representado sob tuplas, o mecanismo proposto nesta dissertação se apoia na utilização de tuplas para propagação de exceções contextuais. Por reutilizarem o SysSU, os sistemas criados através de instanciações do FRonTES seguirão a mesma organização arquitetônica desse sistema de suporte. Essa arquitetura reusada oferece um conjunto de componentes que facilitam a comunicação e coordenação de agentes em um sistema ubíquo. Entretanto, mesmo com esses componentes fornecidos pelo SysSU, essa arquitetura foi estendida com a adição de novos componentes, com o objetivo de tornar mais fácil o tratamento de exceções nesses sistemas. Os componentes adicionados a essa arquitetura são capazes de tornar menos complexa a manipulação de tarefas executadas de forma distribuída no ambiente, em aderência ao MDBT. Além disso, foram adicionados componentes responsáveis por implementar funcionalidades do mecanismo de tratamento de exceções contextuais proposto, por exemplo, a detecção, propagação e tratamento de exceções contextuais que possam ocorrer durante a execução de uma tarefa. Na figura 4.1 é ilustrado um diagrama de componentes simplificado com uma visão geral da arquitetura do FRonTES e seus componentes. Além disso, essa figura possibilita uma visão em alto nível dos pontos flexíveis, ou hot-spots, do framework, que são os componentes: Task, TaskControlFlow, TaskStep e ContextualExceptionHandler. Com base na abordagem apresentada em (LOKE, 2009), onde tarefas são descritas e mapeadas para uma composição de serviços ubíquos, as tarefas no FRonTES estão relacionadas a organização de um conjunto de invocações a serviços disponíveis no ambiente. Cada etapa de uma tarefa, que pode envolver chamadas a um ou mais serviços, é denominada nesta proposta como “passo de tarefa”. Cada “passo de tarefa” deve ter seu comportamento implementado através do componente TaskStep. O componente Task é responsável por agregar um grupo de passos de tarefas que, se executados seguindo uma sequência determinada, permitem atingir alguma meta específica dos usuários de um sistema. Os “passos de tarefa” caracterizam a extensibilidade do componente Task, sendo através deles que os desenvolvedores, usuários do framework, adicionam funcionalidades específicas aos sistemas instanciados com a utilização do FRonTES. A representação unitária de uma “Tarefa”, sob uma perspectiva do MDBT, é fornecida pelo componente Task. Já o controle da ordem de execução dos passos de uma tarefa é responsabilidade do componente “Controlador de Fluxo de Tarefa”, ou TaskControlFlow, como ilustrado no 57 Figura 4.1: Diagrama de componentes com uma visão geral da arquitetura do framework. diagrama da figura 4.1. Duas implementações desse componente são fornecidas no FRonTES. Essas implementações permitem que os passos de uma tarefa sejam executados seguindo uma estrutura de fila ou de lista encadeada. Essas duas implementações permitem tanto a execução sequencial de passos seguindo a ordem em que foram adicionados a uma tarefa, através da estrutura de fila, quanto a execução de passos de uma tarefa em loop ou em uma ordem diferente da ordem em que foram adicionados a uma tarefa, através da estrutura de lista encadeada. Além de prover o controle da sequência de execução dos passos de tarefas durante o fluxo de execução normal, as estratégias de encadeamento dos passos, fornecidas pelo componente TaskControlFlow, podem ser utilizadas durante o fluxo de execução excepcional das tarefas. Com essas estratégias, o TaskControlFlow pode adaptar o fluxo de execução de uma tarefa perante alguma alteração no estado do contexto ou, até mesmo, com a detecção de uma exceção. Para adaptar o fluxo na primeira estratégia, seguindo a estrutura de fila, o TaskControlFlow cria uma nova estrutura contendo os novos passos que devem ser executados. Já na segunda estratégia, o TaskControlFlow manipula a estrutura de controle dos passos, adicionando um conjunto de passos e definindo o fluxo a ser seguido, após o término do passo que estiver em execução. Apesar de serem fornecidas duas implementações de referência para o componente TaskControlFlow, outras implementações podem ser criadas estendendo as estratégias de fluxo de execução de passos do framework. É importante destacar que, apesar do fluxo de execução de uma tarefa ser organizado e controlado pelo componente TaskControlFlow, alterações no fluxo de uma tarefa, sejam elas para terminar ou adaptar uma tarefa, podem ser necessárias perante a ocorrência de exceções ou mudanças no contexto. O componente UbiBroker, reusado do SysSU, é o responsável por garantir a comunicação síncrona e assíncrona, de forma interoperável, dos sistemas instanciados a partir 58 do FRonTES com o sistema de suporte. Esse componente permite que tarefas possam realizar a busca e invocação de serviços através da comunicação provida pela infra-estrutura baseada em Espaço de Tuplas do SysSU. É através do UbiBroker que os demais componentes do framework podem ter acesso ao sistema de suporte, para, por exemplo, receber notificações de alterações no contexto ou, até mesmo, para propagar exceções. Já os componentes ContextManagerService e ExceptionManagerService podem ser considerados como frozen-spots do framework. O primeiro deles é responsável por monitorar informações de contexto do ambiente e notificar as tarefas em execução sobre possíveis mudanças ocorridas, consumindo e postando essas informações através do uso do SysSU. Já o segundo componente é responsável pela detecção de exceções contextuais propagadas externamente a um dispositivo, o qual possua instâncias de tarefas em execução. Esse componente também é responsável pela notificação de tais exceções para as instâncias de tarefas em execução no próprio dispositivo. Além dessas atribuições, esse segundo componente deve propagar exceções que não possam ser tratadas de forma adequada localmente, em um dispositivo, ou que precisem ser notificadas em um escopo maior. Uma apresentação sobre como esses componentes atuam no mecanismo proposto e uma definição mais precisa de “escopo” são apresentadas na Seção 4.3, onde o funcionamento do mecanismo proposto é exposto em detalhes. O TaskExecutor é o componente responsável por manter o controle sob todas as tarefas em execução em um determinado dispositivo, apresentado por vezes nesta dissertação como ambiente de execução local. Através de referências às instâncias de tarefas, esse componente permite consultar informações a respeito do estado de tarefas em execução, como, por exemplo, qual passo está em progresso em um dado momento. Esse componente permite ainda acessar informações geradas por uma tarefa que tenha executado com sucesso todos os seus passos, atingido assim a sua meta. Em consequência desse controle sobre as tarefas, fornecido pelo TaskExecutor, é possível que exceções contextuais detectadas pelo ExceptionManagerService sejam encaminhadas, por exemplo, somente para as instâncias de um determinado tipo de tarefa cujos passos em execução sejam suscetíveis a falhar nesse contexto. O contexto, nesse caso, engloba tanto informações do ambiente externo ao dispositivo onde as tarefas estão sendo executadas quanto informações sobre as próprias tarefas, como o seu tipo, estado (qual passo está em execução) e ainda o tipo de exceção detectada. A utilização dessa característica é interessante para o mecanismo proposto, pois em momentos diferentes é possível que uma exceção de um mesmo tipo interfira ou não em uma tarefa, dependendo do contexto, ou até do passo que estiver sendo executado. Considerando que exceções contextuais podem ocorrer, em algum momento durante a execução de um sistema, faz-se necessário a presença de algum componente de software capaz de atuar como tratador, evitando nesse caso uma possível falha e mantendo a robustez do sistema. Nesse caso, os componentes DefaultContextualExceptionHandlerService e ContextualExeceptionHandler fazem o papel de tratadores de exceções contextuais. O primeiro deles é responsável pelo tratamento de exceções contextuais críticas, que são aquelas que afetam a todas as tarefas em execução em um determinado dispositivo. Como exemplo de 59 uma exceção desse tipo, pode-se imaginar uma situação que modele uma condição de incêndio, ou algum outro evento errôneo para um tipo de sistema. No caso desse tipo de exceção, todas as tarefas devem ser interrompidas para execução, por exemplo, de uma tarefa de contingência que afaste os usuários da situação de perigo detectada. Já o ContextualExceptionHandler é o componente que deverá tratar exceções contextuais relacionadas diretamente às metas de uma tarefa ou um grupo de tarefas. Para prover o tratamento às exceções lançadas ou detectadas no ambiente, estes componentes podem desde adaptar tarefas em execução com a mudança dos “passos” que compõem seu fluxo de execução, até abortar tarefas ou lançar outras novas, afim de continuar tentando cumprir uma meta estabelecida. O comportamento destes componentes de tratamento de exceções devem ser especificados programaticamente durante a instanciação de uma aplicação ou sistema utilizando o FRonTES. É importante destacar que a separação de responsabilidades entre os dois componentes tratadores permite, além da separação do código responsável pelo comportamento normal e excepcional do software, a separação do tratamento de exceções por nível de severidade. Essa característica é interessante para sistemas ubíquos, uma vez que esses sistemas podem ser formados por um conjunto de agentes distribuídos em um ambiente. Essa propriedade de distribuição dos agentes que compõem um sistemas ubíquos pode aumentar a dificuldade de especificar e implementar tratamentos para situações excepcionais em cada um deles. Exceções contextuais mais restritas, que afetam somente alguma tarefa específica executando em um tipo de agente, por exemplo, podem ter o seu tratamento especificado e implementado por analistas que não necessariamente tenham uma visão global do sistema. Por outro lado, exceções mais severas, não diretamente relacionadas a uma tarefa específica, podem ter o seu tratamento especificado e implementado por analistas com conhecimento sobre todas as exceções que podem ocorrer em um dado ambiente. A separação do comportamento excepcional, através dos componentes DefaultContextualExceptionHandlerService e ContextualExeceptionHandler, permite que as atividades relacionadas ao tratamento de exceções, durante a instanciação de um sistema qualquer, sejam separadas das atividades de desenvolvimento mais gerais (e.g., especificação e codificação das funcionalidades principais do sistema). Esses dois componentes permitem, também, a separação explícita nas tarefas que compõem um sistema entre o código responsável pela execução normal e o código responsável pela execução excepcional. Essa separação explícita entre código normal e excepcional segue um dos requisitos da definição de mecanismo de tratamento de exceções apresentado em (GARCIA et al., 2001). 4.3 Mecanismo de Tratamento de Exceções Sensível ao Contexto O mecanismo de tratamento de exceções sensível ao contexto incorporado ao FRonTES permite que tarefas em execução em um ambiente lidem com condições de contexto indesejadas, que podem ser representadas como exceções contextuais. Essas exceções podem ser lançadas a partir da detecção de estados de contexto que invalidem ou afetem a execução normal de 60 uma tarefa. Além disso, assim como foi apresentado por Goodenough (1975a) em relação as exceções tradicionais, as contextuais também podem representar condições ou eventos que não, necessariamente, estejam ligados a estados errôneos do software. Exceções contextuais podem ser utilizadas tanto para representar condições que possam levar uma determinada tarefa a falhar quanto para parametrizar interações entre diferentes níveis de abstração em um software. Para exemplificar esses dois aspectos das exceções contextuais, as quais podem servir tanto para representar situações indesejadas quanto como meio de parametrizar a interação entre componentes distintos, é retomado o exemplo do estacionamento ubíquo, já apresentado na Subseção 2.1.3. No estacionamento ubíquo, é possível ilustrar o primeiro aspecto das exceções contextuais, por exemplo, com uma discussão sobre invalidações de contexto que podem ocorrer durante a execução da tarefa ParkingTask. Para o funcionamento desta tarefa, as informações sobre vagas disponíveis podem compor o contexto. Logo, alterações indesejadas nessas informações podem caracterizar a ocorrência de alguma exceção contextual. Assim, durante a execução dessa tarefa, é possível que, enquanto o motorista guia o seu veículo até uma vaga recomendada, a vaga reservada para o usuário não esteja mais disponível, por algum problema alheio ao funcionamento do sistema. Nesse cenário, a exceção contextual “BrokenParkingSpaceContextualException” pode ser levantada com escopo restrito a própria tarefa, possibilitando o sistema evitar um funcionamento inapropriado através do tratamento desta exceção. Ainda sobre esse mesmo sistema hipotético, é possível ilustrar o segundo aspecto das exceções contextuais. Em uma instância de ParkingTask, supondo a ocorrência da exceção “BrokenParkingSpaceContextualException”, a instância da tarefa pode ser capaz de se adaptar e localizar uma nova vaga, como forma de tratamento para a exceção detectada. Entretanto, durante a busca de uma nova vaga, a tarefa pode ser informada pelo sistema de que não existam mais vagas disponíveis, tornando ineficaz o tratamento previsto. Todavia, essa tarefa pode, no momento em que não for possível tratar a exceção contextual detectada, lançar uma nova exceção contextual modelando essa situação, dessa vez propagando-a para um escopo maior. O escopo, nesse caso, pode ser todo o ambiente do estacionamento, que pode ser provido de agentes capazes de tratar essa exceção. Outra característica do mecanismo proposto é que a ocorrência de diferentes exceções contextuais, como é esperado, pode levar a adaptações ou tratamentos diferentes em uma tarefa. Do mesmo modo, assim como diferentes exceções podem requerer tratamentos diferentes, a ocorrência de uma mesma exceção contextual pode, também, ser tratada de maneiras distintas em relação a uma mesma tarefa, dependendo do estado em que a tarefa se encontre no momento da exceção. Para exemplificar essa característica, é possível considerar a ocorrência de uma outra exceção contextual hipotética de “Estacionamento lotado” no sistema de estacionamento, onde duas instancias da tarefa ParkingTask, em execução em automóveis distintos, poderão ser afetadas. Apesar disso, caso uma das instancias da tarefa ParkingTask esteja em um passo no qual apenas a confirmação de estacionamento ainda não foi realizada (mas a vaga já foi 61 efetivamente ocupada), enquanto a outra ainda esteja buscando uma vaga livre, os tratamentos aplicados em cada instância deverão ser diferentes. Na primeira instância a exceção contextual de “Estacionamento lotado” pode, simplesmente, ser ignorada, enquanto na segunda instância um tratamento mais específico deve ser empregado. 4.3.1 Detecção de Exceções Contextuais No mecanismo proposto as exceções contextuais são detectadas de duas formas. A primeira forma ocorre localmente, onde as exceções contextuais são detectadas internamente a um dispositivo onde uma tarefa está sendo executada. A segunda forma tem um caráter global, onde uma exceção é levantada em algum dispositivo que compõe o sistema e é propagada aos demais. Essas duas formas são detalhadas nas subseções a seguir. 4.3.1.1 Detecção de Exceções Contextuais Locais A primeira forma tratada no mecanismo está relacionada a detecção de exceções contextuais a partir da invalidação do contexto, em relação à tarefas em execução. Essa invalidação do contexto é detectada a partir da avaliação de expressões envolvendo informações contextuais recebidas do ambiente e condições contextuais predefinidas pelas tarefas. As condições contextuais que podem invalidar a execução de uma tarefa podem ser especificadas de forma diferenciada em cada passo que compõe uma determinada tarefa. Em cada passo de tarefa é possível especificar um conjunto de exceções contextuais caracterizando-as através de um conjunto de chaves e valores de informações de contexto. As chaves e valores especificados em cada passo é que serão comparados com o contexto, que é recebido através de notificações do sistema de suporte, sob o qual uma tarefa esteja em execução. O funcionamento adotado no mecanismo proposto para essa primeira frente da detecção de exceções contextuais é ilustrado na Figura 4.2. A forma como acontece essa primeira frente da detecção de exceções contextuais pode ser considerado sensível ao contexto. Isso porque exceções podem ser levantadas, para um conjunto de tarefas qualquer, de forma independente em cada instância de tarefa, dependendo do que esteja especificado como contexto normal e excepcional em cada passo de tarefa envolvido. Além disso, nesse primeiro fluxo da detecção de exceções contextuais, é possível que uma mesma mudança no estado do contexto do ambiente venha a causar o lançamento de exceções contextuais em uma tarefa em um momento e em outro não, dependendo do encadeamento da mudança contextual em relação ao fluxo de execução dos passos que compõem uma tarefa. Como exemplo, é possível retomar a situação, já apresentada no começo desta seção, do estacionamento lotado. Nesse cenário, a mudança no ambiente, passando a não ter mais vagas disponíveis, pode ocasionar ou não o lançamento da exceção contextual de estacionamento lotado, dependendo do passo onde as instâncias da tarefa ParkingTask se encontrem. 62 Figura 4.2: Diagrama de sequência ilustrando o funcionamento da detecção de exceções contextuais a partir da invalidação de contextos. O funcionamento desse primeiro fluxo de detecção de exceções contextuais, como apresentado na Figura 4.2, envolve diversos componentes da arquitetura estendida, apresentada na seção 4.2. Ao iniciar-se uma tarefa qualquer, uma ligação entre serviço ContextManagerService e a própria tarefa é realizada, seguindo a organização do padrão de projeto Observer. Através dessa ligação, as tarefas podem ser notificadas sobre mudanças no estado do contexto. Essas mudanças são percebidas pelo ContextManagerService através do uso do mecanismo de subscrição disponível no SysSU. Nesse serviço, ao receber a notificação de mudança no contexto, é realizado uma transformação de tuplas para uma representação interna de contexto. Esse contexto é notificado pelo serviço para todas as tarefas em execução no ambiente. Em uma tarefa, ao ocorrer uma notificação de contexto, faz-se necessário realizar a avaliação desse contexto a fim de descobrir se alguma exceção contextual será levantada. Por outro lado, essa avaliação é relevante somente nos passos de tarefa que estiverem em execução. O componente TaskControlFlow, por sua vez, se encarrega de encaminhar a notificação recebida para os passos de tarefa em execução. Em cada passo em execução, durante uma notificação de contexto, é realizada uma avaliação entre a expressão que especifica o contexto excepcional e os valores recebidos como informações de contexto. Essa avaliação realizada fundamenta-se basicamente na comparação entre valores de um conjunto de chaves, que representam informações de contexto. Para especificação de contextos excepcionais em um passo, é possível construir expressões compostas por conjunções e disjunções entre chaves e valores de informações de contexto. Outra informação importante para caracterização de uma exceção é o papel sob o qual uma tarefa está sendo executada, que é mapeável, também, através de chave e valor. Uma exceção contextual é 63 levantada caso a comparação entre essas informações coincida com o que foi modelado como excepcional para um dado passo. Nesse caso, a tarefa é interrompida, possibilitando que o seu fluxo de execução seja desviado para um tratador adequado. 4.3.1.2 Detecção de Exceções Contextuais Globais Já a segunda frente da detecção de exceções contextuais é responsável pela sensibilidade à ocorrência de exceções contextuais mais amplas, normalmente mais severas, em um ambiente. Essas exceções contextuais são denominadas neste trabalho como exceções contextuais globais. A figura 4.3 ilustra detalhes do fluxo de funcionamento desta frente de detecção no mecanismo proposto. A detecção de exceções contextuais globais é fornecida pelo componente ExceptionManagerService. Assim como o ContextManagerService observa as alterações contextuais, o ExceptionManagerService observa a ocorrência de exceções globais representadas através de tuplas no SysSU. Esse serviço é iniciado no momento em que o componente TaskExecutor é utilizado pela primeira vez, ilustrado na figura 4.3 através da chamada ao método getInstance() do serviço. O TaskExecutor é o responsável por inicializar esse serviço pelo fato dele controlar a execução de várias tarefas em um dispositivo, logo, caso uma exceção global seja detectada, todas as tarefas em execução ligadas a esse controlador poderão ser notificadas. Figura 4.3: Diagrama de sequência ilustrando o funcionamento da detecção de exceções contextuais globais. O ExceptionManagerService além de monitorar a ocorrência de exceções contextuais globais, que tem nível de severidade mais alto, monitora o recebimento de exceções 64 contextuais que foram propagadas no ambiente. Nesse caso, a propagação deve-se a necessidade de busca no ambiente por tratadores capazes de lidar com exceções contextuais não tratadas no escopo de uma tarefa. Essa funcionalidade de propagação de exceções contextuais é apresentada em detalhes na Subseção 4.3.2. Para exemplificar o funcionamento da detecção de exceções contextuais globais, pode-se retomar o exemplo de uma exceção de incêndio no sistema de estacionamento ubíquo. Nessa situação hipotética, durante a implementação das tarefas do sistema de estacionamento, não necessariamente deverá ser previsto o tratamento para essa exceção, pois não está diretamente relacionado aos objetivos das tarefas desse sistema. De forma mais específica, por exemplo, não existe uma relação direta entre tarefas do tipo ParkingTask e condições de contexto fornecidas por sensores de temperatura e fumaça. Em consequência desse distanciamento entre essas informações de contexto e as tarefas do sistema de estacionamento, exceções contextuais que poderiam ser inferidas a partir dessas informações de contexto não seriam lançadas nas tarefas desse sistema. Isso porque essas condições de contexto não estariam especificadas nas tarefas, logo não teriam como invalidar o seu contexto de execução. Todavia, é possível que no mesmo ambiente do estacionamento, existam sistemas atuando paralelamente para prevenir incêndios. Exceções contextuais levantadas por esses outros sistemas, propagadas no SysSU, podem afetar diretamente a execução de tarefas do sistema de estacionamento ubíquo. Logo, é desejável que esses sistemas ubíquos sejam capazes de lidar com a ocorrência de exceções contextuais globais, visto que elas podem representar eventos possivelmente catastróficos, mesmo que, em um primeiro momento, não estivessem diretamente relacionadas ao propósito do sistema. Exceções dessa categoria tem seu padrão especificado no ExceptionManagerService, que através da utilização do mecanismo de subscrição do SysSU, detecta a ocorrência do padrão e lança exceções globais. No exemplo do incêndio, por se tratar de uma exceção contextual global, crítica para o sistema, o ExceptionManagerService notifica o componente TaskExecutor da ocorrência de uma exceção de incêndio, que por sua vez verifica quais tarefas estão em execução e as notifica. Após as tarefas em execução receberem a notificação de uma exceção global, inicia-se o tratamento da exceção, detalhado na Subseção 4.3.3. 4.3.2 Propagação de Exceções A propagação de exceções contextuais do mecanismo acontece em dois níveis. O primeiro deles abrange a propagação de exceções contextuais entre tarefas e tratadores disponíveis em um mesmo dispositivo. Nesse primeiro nível, as exceções contextuais são propagadas através do mecanismo de propagação nativo da linguagem Java (ORACLE, 2012), com a utilização de blocos de códigos protegidos pelas instruções reservadas try e catch. Na figura 4.2, é ilustrado um exemplo do funcionamento desse primeiro nível de propagação de exceções do mecanismo proposto nesta dissertação. Nessa figura, uma exceção contextual é lançada, após uma avaliação do contexto no método "evaluateContext", com escopo limitado ao componente TaskStep. A exceção lançada em um passo de tarefa inicia uma reação encadeada: (i) a exceção contextual é capturada no componente TaskControlFlow; 65 (ii) o fluxo de execução normal da tarefa é interrompido; e (iii) a exceção é manifestada no componente Task. No segundo nível de propagação das exceções contextuais, tarefas e tratadores que estejam em dispositivos distintos podem ser envolvidos. Nesse nível de propagação, as exceções contextuais são sinalizadas entre dispositivos dispersos no ambiente através do SysSU. Nesse caso, as exceções contextuais são mapeadas e difundidas entre os dispositivos que compõem um sistema ubíquo na forma de tuplas. Nesse segundo nível, a propagação pode ser necessária em dois casos específicos, descritos a seguir. O primeiro caso ocorre quando uma exceção contextual, levantada pela detecção de um contexto excepcional durante a execução de um passo de tarefa qualquer, não pode ser tratada localmente. Ilustrando esse primeiro caso, por exemplo, é possível considerar a ocorrência de uma exceção contextual onde, durante a execução da tarefa ParkingTask, a vaga recomendada para o usuário seja bloqueada. Nessa situação, é possível que o tratamento já esteja especificado nos tratadores disponíveis no mesmo dispositivo onde a tarefa esteja em execução. Entretanto, também é possível que nenhum tratamento para essa exceção esteja especificado localmente, a fim de delegar ao próprio ambiente a responsabilidade de fornecer tratadores adequados, tornando necessária a propagação dessa exceção. Já o segundo caso envolve a detecção de exceções contextuais globais. A figura 4.3 ilustra a propagação de uma exceção global detectada pelo ExceptionManagerService. No fluxo de mensagens apresentado nessa figura é possível perceber que não é imposta nenhuma condição, além da verificação de quais tarefas estão em andamento, para a propagação da exceção global detectada. Em consequência disso, todas as tarefas em execução em um dispositivo sempre receberão exceções globais que tenham sido propagadas. Apesar das tarefas serem sempre notificadas da detecção de exceções contextuais globais, não necessariamente implica no tratamento dessas exceções. A atividade de especificar quais dessas exceções contextuais globais serão ou não tratadas ocorre durante a criação de sistemas através da instanciação do FRonTES. 4.3.3 Tratamento Sensível ao Contexto No mecanismo de tratamento de exceções contextuais proposto nesta dissertação, após a detecção de uma exceção contextual, é iniciado o tratamento em si. Todo o tratamento contextual, nesse caso, tem como ponto de partida comum a interação das tarefas com o componente DefaultContextualExceptionHandlerService. Inicialmente, todas as exceções contextuais a serem tratadas são analisadas por esse serviço, com o propósito de verificar o tipo, a severidade e a disponibilidade de tratamento. Nas figuras 4.4 e 4.5, explicadas nas subseções seguintes, são apresentados os dois possíveis fluxos do tratamento de exceções contextuais. O primeiro fluxo ilustrado está relacionado ao tratamento de exceções contextuais locais, lançadas a partir da invalidação de contexto em tarefas em execução, enquanto o segundo está relacionado ao tratamento de exceções contextuais globais. 66 4.3.3.1 Tratamento de Exceções Contextuais Locais No primeiro fluxo do tratamento, ilustrado na figura 4.4, ao ocorrer a invalidação no contexto de uma tarefa e o lançamento de uma exceção contextual, ocorre a propagação dessa exceção até o DefaultContextualExceptionHandlerService. O serviço, por sua vez, inicia o tratamento da exceção verificando se esta é uma exceção global. Pelo fato da exceção ter sido detectada a partir da invalidação no contexto de uma tarefa em execução, ela não será do tipo global. Em consequência disso, o serviço DefaultContextualExceptionHandlerService, que deve tratar somente exceções globais, mais severas, deve encaminhar essa exceção para um outro tratador local mais apropriado. Logo, ao se especificar e implementar uma determinada tarefa, devem-se atentar, também, para especificação e implementação de tratadores específicos para as exceções contextuais que podem ser lançadas com a detecção de condições indesejadas. Figura 4.4: Diagrama de sequência ilustrando o fluxo de tratamento de uma exceção contextual lançada a partir da detecção de um contexto indesejado. Os tratadores específicos são diretamente ligados às tarefas. No serviço DefaultContextualExceptionHandlerService, ao ser requisitado o tratamento de uma exceção contextual, são informados como parâmetros a exceção contextual e a instância da tarefa. Com essas informações, esse serviço consegue localizar, a partir da referência à instância de tarefa, tratadores específicos para a exceção contextual detectada, supondo que estes tratadores tenham sido devidamente criados. No diagrama de sequência ilustrado na figura 4.4, a interface IPersonalizedContextualExceptionHandler representa o ponto de acesso a um tratador específico de uma tarefa. Todo tratador específico, no mecanismo proposto, deve ser criado a partir do IPersonalizedContextualExceptionHandler. 4.3.3.2 Tratamento de Exceções Contextuais Globais Já o segundo fluxo do tratamento, ilustrado na figura 4.5, é iniciado a partir da detecção de uma exceção contextual global e sua propagação até o serviço DefaultContextualExceptionHandlerService. A análise da exceção detectada, assim como no primeiro fluxo, também será realizada no serviço. No entanto, nesse cenário, a exceção contextual detectada deve ser 67 tratada no próprio DefaultContextualExceptionHandlerService, dado o tipo de exceção que ocorreu. Figura 4.5: Diagrama de sequência ilustrando o fluxo de tratamento de uma exceção contextual global. O mecanismo de tratamento de exceções contextuais proposto adota uma estratégia de recuperação por avanço. Considerando que uma exceção contextual tenha sido detectada durante a execução de uma tarefa, dois fluxos podem ser seguidos dependendo apenas do tipo e severidade desta exceção. Nesses fluxos, a exceção poderá ser tratada tanto pelo DefaultContextualExceptionHandlerService quanto por algum componente que tenha como interface IPersonalizedContextualExceptionHandler. Entretanto, independente de qual seja o componente tratador, a tarefa em execução será interrompida e poderá ter seu fluxo de execução alterado com a adição de novos passos em seu plano de execução. Além dessa estratégia de tratamento, outras tarefas podem ser invocadas pelos tratadores a fim de prover o tratamento necessário para uma exceção contextual. Para que o mecanismo proposto consiga manter certo nível de robustez na tarefas desenvolvidas com o framework FRonTES, as ações necessárias para garantir o funcionamento adequado do sistema perante a ocorrência de exceções contextuais, globais ou não, devem estar devidamente especificadas e implementadas nos componentes tratadores. Apesar do mecanismo proposto oferecer dois fluxos para o tratamento de exceções contextuais, sejam elas detectadas no escopo de uma tarefa ou recebidas através do SysSU (no caso das exceções globais), é possível que, mesmo com a utilização desse mecanismo em um sistema ubíquo, alguma exceção contextual não seja devidamente tratada. Essa afirmativa justifica-se com o fato de a atividade de especificar quais as possíveis exceções contextuais podem ser lançadas em um sistema, e a definição de quais os tratadores devem ser implementados, é atribuída aos engenheiros de software responsáveis pela especificação de robustez do sistema. De uma maneira geral, assim como apresentado na Seção 2.2.3, técnicas de prevenção de faltas podem ser utilizadas em tempo de projeto para evitar a ausência de tratamento para comportamentos excepcionais de um sistema. A verificação formal sobre a especificação das exceções contextuais e seus tratadores representa uma dessas técnicas. Esse aspecto do 68 tratamento de exceções sensível ao contexto para sistemas ubíquos não está no escopo desta dissertação, mas é abordado em (ROCHA; ANDRADE, 2012). No mecanismo proposto, para lidar com o possível cenário onde uma exceção contextual é lançada e o seu tratamento não é fornecido, é utilizada a funcionalidade de propagação de exceções contextuais no SysSU. Nesse caso, as tarefas são interrompidas e a exceção causadora é sinalizada no ambiente. Essa capacidade de propagar exceções contextuais não tratadas pode ser utilizada como forma de sinalizar a necessidade de tratamento no ambiente. Com esse cenário de propagação de exceções contextuais no ambiente, tornase possível a adição de novos agentes capazes de tratar exceções contextuais cujo tratamento estivesse insuficiente, mesmo após a implantação de um sistema ubíquo. Esses agentes podem ser chamados de tratadores de exceções globais, pois não são relacionados exclusivamente a alguma tarefa específica. Os tratadores de exceções globais, apesar de receberem nomenclatura diferenciada, são agentes que adotam a mesma organização arquitetônica, já apresentada na seção 4.2, e adotam o mesmo mecanismo proposto para o tratamento de exceções contextuais. Entretanto, as exceções contextuais cujo tratamento fosse inexistente ou ineficaz em um determinado sistema devem estar previstas nos componentes DefaultContextualExceptionHandlerService e ExceptionManagerService desses agentes. Todos os fluxos de detecção, propagação e tratamento já apresentados nesta seção possuem funcionamento semelhante nestes agentes. 4.4 Conclusão Neste capítulo foi apresentada a arquitetura adotada para implementação do mecanismo proposto. Essa arquitetura, materializada através do framework FRonTES, garante a flexibilidade necessária para a criação de sistemas ubíquos orientado a tarefas com suporte ao tratamento de exceções sensível ao contexto. Além disso, essa estratégia de disponibilização do mecanismo proposto permite a reutilização de componentes prontos, facilitando o desenvolvimento e a utilização do princípio de inversão de controle, evitando que o usuário do mecanismo tenha que se preocupar com o controle do fluxo de execução dos sistemas ubíquos desenvolvidos. Para implementação do framework, um sistema de suporte para computação ubíqua, o SysSU, foi reusado como infraestrutura de software para comunicação dos agentes que compõem os sistema ubíquos desenvolvidos e para propagação de informações de contexto e de exceções contextuais. Além disso foi apresentado o mecanismo de tratamento de exceções sensível ao contexto, que é a principal contribuição deste trabalho. O mecanismo proposto fornece a capacidade de tratar exceções de forma sensível ao contexto através de três funcionalidades: detecção, propagação e tratamento de exceções contextuais. Com a utilização da funcionalidade de detecção de exceções contextuais tornase possível o tratamento de situações indesejadas, caracterizadas por expressões compostas por informações de contexto que são verificadas a cada alteração relevante no estado do contexto. O tratamento dessas exceções contextuais, utilizando o mecanismo, é especificado 69 programaticamente, podendo adaptar-se levando em consideração o tipo de exceção e o contexto que a ativou. O tratamento de uma exceção contextual pode requerer desde a adaptação de uma tarefa, com a mudança no fluxo dos passos que devem ser executados, até o lançamento de outras tarefas. Já a propagação de exceções contextuais possibilita a busca de tratadores para exceções contextuais que não tiveram o seu tratamento especificado em um determinado escopo, ou que o tratamento especificado não foi capaz de lidar de maneira adequada. Por essa dissertação apresentar uma natureza exploratória a respeito do tratamento de exceções sensível ao contexto em sistemas ubíquos orientados a tarefas, não explorados em conjunto anteriormente na literatura revisada, não foi realizada uma análise quantitativa dos benefícios da utilização do mecanismo proposto. Todavia, o objetivo principal desta dissertação é ratificado ao apresentar um mecanismo capaz de suportar o tratamento de exceções sensível ao contexto em sistemas ubíquos, facilitando o desenvolvimento desse tipo de sistema através das abstrações e funcionalidades providas. O próximo capítulo apresenta, como prova de conceito para demonstração do mecanismo proposto, o desenvolvimento de um sistema ubíquo orientado a tarefas o qual apresenta-se propício para avaliação do mecanismo de tratamento de exceções contextuais proposto. 70 5 PROVA DE CONCEITO Neste capítulo é apresentado uma prova de conceito (PoC1 ) sobre a implementação do UbiParking, um sistema de estacionamento ubíquo, cuja tarefa ParkingTask é diversas vezes referenciada em exemplos apresentados nesta dissertação. Na Seção 5.1 é apresentada uma breve comparação entre os conceitos “estudo de caso” e “prova de conceito”. Na Seção 5.2 é descrito o cenário de aplicação do UbiParking e são delineadas algumas funcionalidades desse sistema. Além disso são apresentadas possíveis situações excepcionais que podem afetar o cumprimento dos objetivos dos usuários desse sistema. Na Seção 5.3 é descrito como o UbiParking é instanciado a partir do FRonTES e como ele faz uso do mecanismo de tratamento de exceções proposto nesta dissertação. Finalmente, a Seção 5.4 apresenta as considerações finais deste capítulo. 5.1 Estudo de Caso versus Prova de Conceito Na Engenharia de Software, quando se trata de métodos de investigação empíricos, há certa confusão entre exemplos funcionais2 e estudos de caso (EASTERBROOK et al., 2008). Exemplos funcionais, por vezes apresentados erroneamente em algumas pesquisas como estudos de caso, se assemelham a definição de prova de conceito. Uma prova de conceito, segundo Pressman (2001) é algo que demonstra a viabilidade de uma nova tecnologia. Já o estudo de caso é uma forma de pesquisa empírica que investiga um fenômeno contemporâneo dentro de seu contexto da vida real. Estudos de casos são apropriados para situações onde a separação entre o fenômeno a ser pesquisado e o seu contexto não esteja evidente (YIN, 2002) apud (EASTERBROOK et al., 2008). Badram e Friday em (KRUMM, 2009) sumarizaram algumas das abordagens de avaliação de sistemas ubíquos mais utilizadas, tais como simulação e prova de conceito. Esses autores também definiram uma PoC como uma realização rudimentar e/ou incompleta de algum modelo ou conceito para provar que estes podem realmente ser alcançados ou construídos, demonstrando, ao mesmo tempo, a viabilidade de implementações reais (nesse caso, implementações completas). Badram e Friday identificaram que a utilização de PoCs é a estratégia predominante nas pesquisas relacionadas a computação ubíqua, desde pesquisas pioneiras como a de (WEISER, 1993b) até diversas outras direcionadas a domínios específicos, como (BARDRAM; CHRISTENSEN, 2007)(CHEVERST et al., 2000)(FLECK et al., 2002)(BRUMITT et al., 2000)(ROMAN; CAMPBELL, 2000)(BORCHERS et al., 2002)(STREITZ et al., 1999). Ainda segundo Badram e Friday, através de PoCs é possível constatar que conceitos ou ideias podem ser implementados, todavia essa estratégia de investigação possui um inconveniente. Através dela não é possível se quantificar o quão boa são essas soluções em relação aos objetivos traçados para elas. Nesse caso, uma PoC pode ser submetida a outros métodos de validação mais rigorosos. Apesar dessa estratégia ser considerada, sob um ponto de 1 Do inglês, Proof of Concept. adotada para worked example. 2 Tradução 71 vista científico, como uma fraca abordagem de avaliação ela foi utilizada em diversas pesquisas relacionadas a computação ubíqua (como já foi referenciado anteriormente). Logo, nesta dissertação optou-se por avaliar de forma exploratória o mecanismo proposto através de uma PoC, que é detalhada nas seções seguintes, visando corroborar com as contribuições desta dissertação. A PoC realizada segue uma metodologia composta por seis etapas, que são: 1. Identificação e delimitação de um conjunto de cenários que possam ser beneficiados pelas funcionalidades de um sistema ubíquo específico e que possuam estados de contexto indesejados; 2. Implementação dos serviços ubíquos que compõem o sistema, que no caso do estacionamento ubíquo deverão gerenciar a disponibilidade e alocação de vagas do ambiente; 3. Implementação dos clientes móveis do sistema utilizando o FRonTES, organizando os fluxos de interação desses elementos do sistema com os serviços disponíveis no ambiente através da abstração de tarefa fornecida por este framework; 4. Implementação de uma aplicação capaz de modificar a percepção do estado de contexto do sistema, que servirá para alterar um estado normal do contexto para um estado excepcional para as tarefas implementadas; 5. Execução do sistema em um estado de contexto normal (contexto o qual nenhuma exceção contextual é levantada) para as tarefas implementadas, afim de observar se as tarefas executam os passos que as compõem de forma apropriada e seguindo um fluxo esperado; e 6. Execução do sistema iniciando as tarefas em um estado de contexto normal e, em seguida, alterando esse contexto forçadamente para um estado excepcional, afim de observar se as tarefas conseguem lidar de forma apropriada com as exceções contextuais que devem ser levantadas. São explicados, através de trechos de código do UbiParking, os procedimentos para utilização do mecanismo de tratamento de exceções sensível ao contexto proposto. Além disso, é evidenciada a aplicabilidade do MDBT para o desenvolvimento de sistemas ubíquos. 5.2 Descrição do Cenário Diversos trabalhos direcionaram esforços em torno do conceito de “Cidade Ubíqua”, ou UCity 3 (JANG; SUH, 2010). Esse conceito, de forma simplificada, está relacionado ao provimento de diversos serviços ubíquos, com o propósito de tornar melhor a convivência urbana, sob aspectos como trânsito, serviços de saúde, serviços de atendimento aos cidadãos, dentre outros. Dentre os serviços disponíveis em uma cidade ubíqua, destaca-se neste capítulo o 3 Os prefixos “U” ou “Ubi” são adotados em diversos artigos como menção ao conceito de “Ubíquo”. 72 U-Parking (KNHC, 2007) apud (JANG; SUH, 2010), um serviço ubíquo para o controle de estacionamento. Esse tipo de serviço influenciou na escolha do domínio específico de aplicação a ser explorado por envolver uma série de situações as quais podem ser utilizadas para demonstrar os benefícios do tratamento de exceções sensível ao contexto e da utilização do MDBT. 5.2.1 Aplicação Motivadora Primeiramente, a escolha de sistemas de estacionamento ubíquo como domínio específico para o desenvolvimento de uma prova de conceito deve-se pela utilização das ideias e problemas desses domínio, no decorrer desta pesquisa, como cenário motivador para discussões técnicas e reuniões realizadas entre alunos e pesquisadores do GREat 4 . Diversas situações, apresentadas como exemplos nesta dissertação, foram idealizadas a partir de reflexões iniciadas nessas discussões e reuniões. Além disso, a escolha desse domínio específico deve-se pelo estudo realizado sobre um sistema real chamado SFPark (SFMTA, 2012), que serviu como aplicação motivadora. Esse sistema foi implantado pela Agência Municipal de Transportes de São Francisco, nos Estados Unidos, para controlar a ocupação de vagas de estacionamento em vias públicas em algumas áreas da cidade. As informações coletadas e analisadas sobre o SFPark proporcionaram um melhor entendimento sobre alguns requisitos específicos desse tipo de sistema. O acesso as informações sobre esses tipo de sistema elucidam alguns benefícios do seu uso, que podem ser citados: • A otimização na ocupação de vagas; • A facilidade no acesso a informações de vagas disponíveis; • A viabilidade de uso de outras formas de pagamento (e.g., através do celular, ao invés do uso de tickets); • A possibilidade de utilização de políticas de cobrança auto-adaptáveis, com base na disponibilidade de vagas (e.g., tornando mais barato estacionar em períodos onde a ocupação de vagas é baixa, ou mais caro caso contrário); • Vários outros benefícios indiretos (e.g., melhoria no comércio local em consequência da maior rotatividade nos estacionamentos, por sua vez, promovido pela melhoria na gestão de ocupação de vagas). No SFPark, as informações de vagas disponíveis são acessíveis através de um portal, por aplicações móveis, ou, até mesmo, através da utilização da API 5 disponibilizada ao público (por exemplo, utilizada em sistemas embarcados nos veículos). Na figura 5.1, são apresentadas duas imagens do SFPark. Na imagem 5.1(a), é apresentada uma montagem com uma tela real 4 Grupo 5 Sigla de pesquisa o qual os autores deste trabalho fazem parte. Website: www.great.ufc.br . do inglês para Application Programming Interface. 73 da aplicação móvel do SFPark, exibindo um mapa com marcações indicando a disponibilidade de vagas controladas por esse sistema, e os principais elementos do sistema do ponto do vista do usuário. Na imagem 5.1(b), é apresentada uma fotografia de um dos sensores utilizados nesse sistema. (a) Montagem com ilustração de um usuário estacionando seu veículo e uma tela real da (b) Foto com sensores de estaciona- aplicação móvel do SFPark exibindo a disponibilidade de vagas. mento do SFPark. Figura 5.1: Imagens do sistema SFPark (SFMTA, 2012). 5.2.2 Delimitação do Cenário O desenvolvimento de um sistema de estacionamento oferece um cenário fértil para observação de características onde a utilização da computação ubíqua pode trazer benefícios. Em um estacionamento tradicional qualquer, seja ele limitado a uma área privada ou a um conjunto de vias públicas, podem ser observadas pelo menos duas características comuns: a mobilidade dos usuário/veículos e a possibilidade de bilhetagem. Essa primeira característica de mobilidade dos usuários é observável nos estacionamentos, uma vez que os usuários/veículos estão normalmente em movimento, seja buscando uma vaga para estacionar ou uma rota para algum outro lugar (e.g., saída do estacionamento). A característica de bilhetagem está relacionada a possibilidade de cobrança pelo tempo em que uma vaga de estacionamento ficou ocupada. Ao se considerar a utilização da computação ubíqua como fundação para o desenvolvimento de um sistema de estacionamento, torna-se possível atender aos requisitos chaves já identificados anteriormente de forma mais apropriada, por exemplo levando em consideração informações de contexto dos usuários e do ambiente. Além disso, o desenvolvimento desse tipo de sistema sob uma perspectiva de computação ubíqua permite contemplar uma série de funcionalidades ou serviços adicionais, antes não concebíveis, como, por exemplo, a adoção de uma política de cobrança auto-adaptável (já presente no SFPark). Considerando os possíveis benefícios da utilização da computação ubíqua nesse domínio específico, de sistemas de estacionamentos, é possível especificar de forma mais direta três funcionalidades. Tais funcionalidades foram analisadas e desenvolvidas para compor o UbiParking, e são enumeradas a seguir: 74 1. Pesquisar vagas disponíveis, o sistema deve ser capaz de localizar vagas livres e indicá-las para os usuários; 2. Reservar uma vaga, o sistema deve ser capaz de receber confirmações dos usuários sobre a aceitação de vagas, podendo reservá-las por um período determinado; 3. Registrar o estacionamento, o sistema deve estar apto a registrar estacionamentos efetivados (percebidos através de sensoriamento). Contudo, conforme já explicado nos Capítulos 1 e 2, a utilização da computação ubíqua não trás apenas oportunidades de benefícios para os sistemas desenvolvidos. Ao desenvolver um sistema ubíquo, diversos problemas complexos devem ser enfrentados, como, por exemplo, a especificação do comportamento do sistema para condições de contexto indesejadas. As três funcionalidades enumeradas estabelecem o escopo de desenvolvimento da PoC. Todavia, mesmo parecendo simples, essas funcionalidades podem envolver uma série de situações excepcionais, as quais podem ser contornadas através do uso adequado do mecanismo de tratamento de exceções contextuais proposto nesta dissertação. Antes de detalhar algumas situações excepcionais das funcionalidades enumeradas, é necessário destacar que as três podem ser organizadas para compor, de forma simplificada, a tarefa ParkingTask, já apresentada em exemplos anteriormente. Essa tarefa estaria relacionada com a meta dos usuários desse sistema, que é simplesmente a meta de “estacionar”. Caso essas funcionalidades sejam executadas por um mesmo usuário, seguindo uma sequência adequada, ao final da execução, a meta deve ter sido atingida. Logo, percebe-se que a construção desse sistema é passível de ser realizada através do MDBT. Nesse caso, cada uma das três funcionalidades devem ser mapeadas para passos da tarefa ParkingTask, cada um cumprindo parcialmente a meta dos usuários, através da utilização de um ou mais serviços disponíveis no ambiente. Durante o primeiro passo, ou execução da funcionalidade “Pesquisar vagas disponíveis”, o sistema deve localizar uma vaga disponível e informá-la para o usuário. A busca pela vaga, por sua vez, pode levar em consideração a localização do usuário ou suas preferências durante a escolha. Já no segundo passo, o de reserva de uma vaga, o sistema deve aguardar uma confirmação de aceite do usuário em relação a vaga que lhe foi informada. Após recebimento dessa confirmação, o sistema deverá reservar esta vaga para o usuário, passando, no passo seguinte, a monitorá-la até o motorista efetivamente parar seu veículo no local previsto. Apesar de existirem possíveis situações excepcionais durante a execução desses dois passos, foram, em um primeiro momento, desconsideradas. Já o terceiro passo, o de registro do estacionamento, inicia logo após a aceitação de uma vaga. Este é o passo onde o sistema permanece monitorando uma vaga. Além disso, ele só é finalizado após o usuário conseguir efetivamente ocupar a vaga que lhe foi recomendada. Porém, para este passo da tarefa ParkingTask, foi definido uma situação excepcional. 75 Nesse terceiro passo, após a confirmação de aceitação de uma vaga, o usuário irá dispor de um intervalo de tempo para se dirigir até a vaga reservada. No entanto, por motivos alheios ao funcionamento do sistema, a vaga reservada está sujeita a vários problemas que podem alterar inesperadamente sua disponibilidade. Um exemplo disso pode ser a ocupação da vaga reservada por um outro usuário, de forma concorrente, ignorando as recomendações do sistema, ou, até mesmo, um problema físico na vaga ocasionando a sua interdição. Essa mudança contextual, na disponibilidade da vaga, afeta o funcionamento normal da tarefa ParkingTask, impedindo a sua finalização de forma adequada. Neste caso, o sistema deve ser capaz de lidar com essa situação excepcional, evitando problemas para o usuário que havia “reservado” a vaga. Logo, identifica-se que esse fluxo pode ser investigado na PoC através da utilização do conceito de exceções contextuais locais, do mecanismo proposto nesta dissertação. Além disso, como já foi mencionado, um sistema de estacionamento ubíquo pode possuir integrações com outros sistemas, como, por exemplo, com um sistema de prevenção de incêndio. Por conseguinte, outras situações excepcionais podem ser detectadas, podendo influenciar na execução de uma determinada tarefa do sistema. Como exemplo, pode ser considerado uma situação onde ocorra a detecção de incêndio simultaneamente a execução de instâncias da tarefa ParkingTask. Essa situação de incêndio é considerada na PoC como um cenário a ser tratado através do uso de exceções contextuais globais. 5.2.3 Organização da Prova de Conceito Inspirado na organização dos dispositivos e serviços do SFPark, foram concebidos três tipos de elementos para a PoC, são eles: • os serviços ubíquos, • as interfaces com usuários (nesse caso, representadas pelos dispositivos móveis), • e os dispositivos de sensoriamento. Na figura 5.2, é mostrado uma visão geral da organização desses elementos. A partir dessa visão global, é possível ter um melhor entendimento sobre a forma de interação entre todos esses agentes. Nesse caso, é utilizado o SysSU como base para essas interações. O Ubiparking Service, ilustrado na figura 5.2, representa os serviços ubíquos desenvolvidos para o protótipo do UbiParking. Para o desenvolvimento e implantação desses serviços, foi utilizado um computador com sistema operacional Windows 7 e a plataforma Java v.6 . Nesse mesmo dispositivo foi também implantada uma instância do UbiCentre para possibilitar a comunicação dos elementos do sistema. O UbiParking Client, também mostrado na figura 5.2, representa a interface com os usuários do sistema através de uma aplicação móvel. Esta aplicação foi desenvolvida sob a Plataforma Android, compatível com versões iguais ou superiores a versão 2.1 . Ademais, essa aplicação foi desenvolvida com a instanciação do framework FRonTES. 76 Figura 5.2: Organização dos agentes no protótipo desenvolvido como prova de conceito. Já o papel dos sensores, responsáveis pela detecção de informações de contexto, foi simplificado através do mapeamento do seu comportamento para uma aplicação que simula a detecção e notificação de mudanças no estado do contexto. Tal aplicação permite alterar arbitrariamente a percepção do sistema quanto as informações de contexto. Essa característica é conveniente para investigação do comportamento do mecanismo de tratamento de exceções proposto nesta dissertação, uma vez que permite alterar o contexto e forçar a adaptação no fluxo de execução do sistema para cenários críticos. 5.3 UbiParking: Instanciação Dois aspectos do desenvolvimento do UbiParking Client, através da instanciação do FRonTES, são destacados nesta seção. O primeiro está relacionado a utilização do MDBT, através do reuso das implementações dos conceitos de “tarefa” e “passos de tarefa” fornecidos pelo framework. Já o segundo, demonstra como é realizada a especificação de contextos excepcionais para uma tarefa. Além disso, é detalhado como acontece o tratamento de exceções contextuais globais no mecanismo proposto. Na figura 5.3, é mostrada uma tela do protótipo do UbiParking Client em execução. Nessa imagem, é possível visualizar simultaneamente um registro dos passos, da tarefa ParkingTask, executados no lado “cliente”(figura 5.3(a)) e no lado do serviço UbiParking Service (figura 5.3(b)). 5.3.1 Criação da Tarefa ParkingTask Os trechos de códigos mostrados nos algoritmos 5.1 e 5.2, exemplificam a forma de se implementar o comportamento de passos de uma tarefa. A primeira informação importante em relação a forma de se criar passos de tarefa é notável a partir desses trechos de códigos. A classe abstrata TaskStep deve ser estendida, para que a implementação dos métodos doWhileExecutingStep e getExceptionalContext sejam especificadas. 77 (a) Tela do protótipo desenvolvido (b) Log das ações executadas no UbiParking Service durante a interação com o protótipo. como prova de conceito. Figura 5.3: Imagens do Protótipo do UbiParking. Os nomes dados a esses dois métodos sugerem o seu papel em relação a definição de um passo de tarefa. Todavia, por ora, é importante ater-se somente ao primeiro método, o doWhileExecutingStep. É nesse método onde, para cada passo que componha uma tarefa, deve ser especificado as chamadas aos serviços ubíquos responsáveis por algum “pedaço” de uma tarefa. Logo, é nele que está definido o que será realizado durante a execução. Na linha 11 do algoritmo 5.1, por exemplo, o método postRequestVagaTuple é responsável por fazer a requisição de uma vaga de estacionamento através dos serviços disponíveis no ambiente. Toda comunicação necessária entre o agente cliente, executor desse código, e os serviços são realizadas através do SysSU. Do mesmo modo, na linha 11 do algoritmo 5.2, o método postParkingFinish utiliza-se do SysSU para comunicar aos serviços de controle do UbiParking que a tarefa em execução conseguiu finalizar sua meta com sucesso. Algoritmo 5.1: Trecho de código com a criação do primeiro passo da tarefa ParkingTask. 1 TaskStep requisitarVagaStep = new TaskStep ( " S t e p 1 " ) { 2 @Override 3 p r o t e c t e d Set <? e x t e n d s ContextualException > getExceptionalContext ( ) { return null ; } 4 5 6 7 @Override 8 p r o t e c t e d v o i d doWhileExecutingstep ( ) t h r o w s InterruptedException { try { String vaga = postRequestVagaTuple ( ( String ) getBundle ( ) . get ( " t a s k i d " ) ) ; getBundle ( ) . put ( " v a g a " , vaga ) ; updateEditText ( " Recomendação de v a g a r e c e b i d a : Vaga " + vaga ) ; } c a t c h ( Exception e ) { (...) } 9 10 11 12 13 14 15 16 17 } 18 19 }; 78 Algoritmo 5.2: Trecho de código com a criação do terceiro passo da tarefa ParkingTask. 1 2 3 TaskStep finalizaEstacionamentoStep = new TaskStep ( " S t e p 3 " ) { @Override p r o t e c t e d Set <? e x t e n d s ContextualException > getExceptionalContext ( ) { (...) r e t u r n setExceptionsThatCanBeRaised ; 4 5 } 6 7 @Override 8 p r o t e c t e d v o i d doWhileExecutingstep ( ) t h r o w s InterruptedException { try { postParkingFinish ( ( String ) getBundle ( ) . get ( " t a s k i d " ) ) ; updateEditText ( " E s t a c i o n a m e n t o F i n a l i z a d o com s u c e s s o . " ) ; } c a t c h ( Exception e ) { (...) } } 9 10 11 12 13 14 15 16 17 }; Para a criação de uma tarefa, além da especificação do que deve ser feito, de forma programática, durante a execução de cada passo, é necessário agregá-los dando unidade a tarefa. No algoritmo 5.3, é mostrado um exemplo de como isso pode ser feito. Essa unidade de execução, representada pela classe Task no código exposto, além de prover um conjunto de métodos de controle do estado das tarefas, implica na definição de um fluxo de execução dos passos. Explicando em detalhes o algoritmo 5.3, é criada, na linha 2, uma estrutura de dados que mantém o controle sob a ordem com que os elementos são adicionados. O conteúdo adicionado a essa estrutura servirá como “carga de trabalho” para a tarefa a ser criada adiante. A ordem na qual os passos são adicionados, nesse caso específico, será adotada como especificação do fluxo de execução da tarefa. É exibido, nas linhas 3 e 5, a adição dos passos já apresentados nos algoritmos 5.1 e 5.2 a essa estrutura. No FRonTES, existem outros métodos construtores específicos que podem ser utilizados para a criação de tarefas, nos casos onde o fluxo de execução a ser seguido deve ser diferente da ordem de inserção dos passos. Por fim, na linha 8, é criada a tarefa ParkingTask, propriamente dita. Algoritmo 5.3: Trecho de código com a instanciação da tarefa ParkingTask. 1 2 3 4 5 / / C r i a C a r g a de t r a b a l h o da t a r e f a LinkedHashMap < String , TaskStep > workload = new LinkedHashMap < String , TaskStep > ( ) ; workload . put ( requisitarVagaStep . getName ( ) , requisitarVagaStep ) ; (...) workload . put ( finalizaEstacionamentoStep . getName ( ) , finalizaEstacionamentoStep ) ; 6 7 / / I n s t a n c i a uma t a r e f a a p a r t i r de um c o n j u n t o de p a s s o s 8 Task parkingTask = new Task ( workload ) ; 9 10 11 parkingTask . setUserDefinedContextualExceptionHandler ( new IPersonalizedContextualExceptionHandler ( ) { 12 @Override 13 p u b l i c v o i d handleContextualException ( Task task , ContextualException exception ) { / / Adicionar tratamento } 14 15 16 17 18 } 79 20 ); (...) 21 UUID id = TaskExecutor . getInstance ( ) . submitTask ( estacionarTask ) ; 19 22 (...) 23 Message result = TaskExecutor . getInstance ( ) . getTask ( id ) . get ( ) ; 5.3.2 Definição do Tratamento de Exceções Contextuais Para possibilitar o entendimento minucioso do segundo aspecto da instanciação do UbiParking Client, o de tratamento de exceções sensível ao contexto, é necessário demonstrar exemplos detalhando três particularidades de implementação do mecanismo de tratamento de exceções contextuais proposto, incorporadas no FRonTES. A primeira delas diz respeito a especificação de exceções contextuais que podem afetar a uma determinada tarefa. Conforme já apresentado na Sub-subseção 4.3.1.1, é possível se especificar em cada passo de uma tarefa um conjunto de exceções contextuais, cujos valores atribuídos às informação de contexto serão avaliados como expressões booleanas. As exceções do conjunto atribuído a um passo de tarefa são avaliadas de forma disjunta, caso ocorram alterações de contexto que disparem essa ação. Já os valores das informações de contexto, atribuídos para cada exceção contextual, são interpretados como um contexto de ativação da exceção e são avaliados de forma conjuntiva. Todavia, ao ser detectado a ativação de uma exceção contextual (com um retorno verdadeiro da avaliação de uma expressão), é interrompida a análise do restante do conjunto de exceções atribuído a um passo. Assim, o fluxo de execução dessa tarefa é direcionado para o tratamento excepcional. No algoritmo 5.4 é apresentado um trecho de código com um novo recorte sobre a especificação programática do terceiro passo da tarefa ParkingTask. Nesse trecho de código é destacado a especificação de apenas uma exceção contextual. Na linha 6 deste algoritmo, é definida esta exceção passado como parâmetro a especificação das informações contextuais que a ativam. No caso, apenas a informação representada pela chave “vaga<número da vaga>” e pelo valor “bloqueada”. Algoritmo 5.4: Trecho de código especificando uma exceção contextual para o terceiro passo da tarefa ParkingTask. 1 2 3 4 5 6 7 8 9 10 TaskStep finalizaEstacionamentoStep = new TaskStep ( " S t e p 3 " ) { @Override p r o t e c t e d Set <? e x t e n d s ContextualException > getExceptionalContext ( ) { GeneralContext exceptionalContext = new GeneralContext ( ) ; exceptionalContext . addContextInformation ( new ContextInformation ( " v a g a " + ( String ) ←getBundle ( ) . get ( " v a g a " ) , " b l o q u e a d a " ) ) ; ContextualException c = new ContextualException ( exceptionalContext ) ; HashSet < ContextualException > setExceptionsThatCanBeRaised = new HashSet <←ContextualException > ( ) ; setExceptionsThatCanBeRaised . add ( c ) ; r e t u r n setExceptionsThatCanBeRaised ; } 11 12 13 @Override p r o t e c t e d v o i d doWhileExecutingstep ( ) t h r o w s InterruptedException { 80 (...) 14 } 15 16 }; Hipoteticamente, pode-se considerar o caso onde, para uma instância da tarefa ParkingTask, a vaga 9 de um estacionamento qualquer foi recomendada para um usuário. Enquanto o usuário se dirige até a vaga especificada, pode ocorrer dessa vaga sofrer uma alteração na sua disponibilidade tornando-a “bloqueada”. Desse modo a informação de contexto “vaga 9 = bloqueada”, deverá ativar a exceção contextual. Embora o protótipo desenvolvido conte com exceções contextuais definidas apenas no terceiro passo da tarefa ParkingTask, simplificando a PoC, outras exceções contextuais podem ser lançadas e detectadas durante a execução deste ou dos demais passos da tarefa. Neste caso, as exceções serão as do tipo globais. Como já apresentado na seção 4.2, o componente ExceptionManagerService será o responsável por detectar as exceções desse tipo no ambiente e propagar até as instâncias de tarefa em execução. Como já apresentado na seção 4.2, O tratamento destas exceções deve ser especificado no DefaultContextualExceptionHandler, implementado no FRonTES através da classe DefaultContextualExceptionHandlerService. No algoritmo 5.5, é mostrado um exemplo da utilização desta classe. A partir deste trecho de código, é possível perceber que esta classe implementa uma interface comum para os tratadores, chamada IContextualExceptionHandlerService. Esta interface possui apenas a assinatura do método handleContextualException, recebendo como parâmetro uma instância de tarefa e uma exceção contextual. É neste método onde os tratamentos para as exceções contextuais globais devem ser especificados. Neste caso, o tratamento de uma exceção contextual global pode levar a uma adaptação no fluxo de execução de uma tarefa, como exibido na linha 11 do algoritmo 5.5. Por outro lado, caso a exceção não seja do tipo global, verificado através da instrução da linha 7, deverá ser propagada até a instância da tarefa em questão. Já na tarefa, são buscados tratadores específicos para a exceção detectada, que se presentes serão ativados, caso contrário a exceção é simplesmente ignorada. Os tratadores específicos, por sua vez, podem ser especificados em uma instância de tarefa através do método setUserDefinedContextualExceptionHandler, como mostrado no algoritmo 5.3. Algoritmo 5.5: Trecho de código especificando o tratamento para exceções contextuais globais. 1 p u b l i c c l a s s DefaultContextualExceptionHandlerService i m p l e m e n t s ←IContextualExceptionHandlerService { 2 3 4 5 @Override p u b l i c v o i d handleContextualException ( Task task , ContextualException exception ) { 6 7 8 i f ( exception . getClass ( ) . getSimpleName ( ) . equals ( GlobalContextualException . c l a s s . ←getSimpleName ( ) ) ) { 81 / / D e f i n i r t r a t a m e n t o e x c e p c i o n a l p a r a c a d a t i p o de e x c e ç ã o g l o b a l (...) task . adaptControlFlow ( newFlow ) ; 9 10 11 12 } else { 13 14 (...) / / Propaga exceção para t a r e f a task . propagateExceptionToUserDefinedHandler ( exception ) ; 15 16 17 } 18 19 } 20 21 22 } 5.4 Conclusão Neste capítulo, foi descrito o domínio específico de sistemas de estacionamento ubíquo, como um dos serviços de uma “cidade ubíqua”. Algumas funcionalidades deste domínio foram escolhidas para compor o cenário analisado. Tais funcionalidades foram reunidas para formar o sistema UbiParking, desenvolvido como uma prova de conceito. O desenvolvimento desta PoC teve como principal objetivo validar o mecanismo de tratamento de exceções contextuais proposto nesse trabalho de dissertação. Algumas situações excepcionais da tarefa ParkingTask, principal tarefa do UbiParking e diversas vezes apresentada como exemplo neste trabalho, foram analisadas e implementadas demonstrando o funcionamento do mecanismo proposto. Além disso, foi explicado como este mecanismo pode ser utilizado através do FRonTES e como são implementadas as tarefas. Em razão do caráter exploratório desta pesquisa, uma análise quantitativa dos benefícios providos pela utilização do mecanismo ou do framework propostos não se faz necessária. Ademais, apesar da simplicidade envolvida nos passos de tarefa implementados na PoC, é possível perceber a simplicidade envolvida na especificação das tarefas, seus contextos excepcionais e os seus tratamentos. Essa simplicidade é atribuída de forma empírica, com base na complexidade de implementação dos algoritmos apresentados no capítulo. O próximo capítulo sumariza os resultados alcançados neste trabalho, assim como apresenta possíveis linhas de pesquisa a serem consideradas em trabalhos futuros. 82 6 CONCLUSÃO Esta dissertação propôs um mecanismo para o tratamento de exceções sensível ao contexto para sistemas ubíquos construídos sob um modelo de desenvolvimento baseado em tarefas. Para facilitar a reutilização deste mecanismo de forma flexível foi também desenvolvido o framework FRonTES. Na Seção 6.1 estão reunidos os principais resultados alcançados com a conclusão deste trabalho. E na Seção 6.3 são apontadas algumas perspectivas de trabalhos futuros decorrentes desta pesquisa. 6.1 Resultados Alcançados Diante dos requisitos desafiadores dos sistemas ubíquos, tais como sensibilidade ao contexto, distribuição, autonomicidade, mobilidade e outros, desenvolver sistemas deste tipo torna-se uma atividade complexa. Ao se considerar que sistemas ubíquos podem realizar proativamente tarefas que impactam no cotidiano das pessoas, o requisito de dependabilidade ganha certo destaque durante o ciclo de vida desses sistemas. O tratamento de exceções é amplamente utilizado como uma estratégia para possibilitar a tolerância a falhas em sistemas computacionais, logo, possibilita também obter melhorias relacionadas aos níveis de dependabilidade desses sistemas. Além disso, em sistemas ubíquos não só faltas relacionadas a software ou hardware podem leválos a falhar, mas também condições de contexto excepcionais. Nesse âmbito, esta dissertação propôs um mecanismo de tratamento de exceções sensível ao contexto para sistemas ubíquos construídos sob um modelo de desenvolvimento baseado em tarefas. O mecanismo proposto, através das suas funcionalidades de detecção de exceções contextuais, propagação e tratamento sensível ao contexto, facilita o desenvolvimento de sistemas ubíquos orientados a tarefas capazes de lidar com situações indesejadas ou excepcionais. Com a utilização deste mecanismo no desenvolvimento de sistemas ubíquos torna-se mais simples garantir a capacidade de tolerar falhas e situações de contexto indesejadas. Essas funcionalidades foram delineadas e implementadas com a extensão da arquitetura do SysSU, como apresentado na seção 4.2. A extensão dessa arquitetura permitiu adicionar componentes que colaboram entre si para monitorar o contexto e lançar exceções contextuais, que ocorrem quando o estado de contexto se altera e coincide com algum estado que esteja especificado como excepcional para o sistema, caracterizando a funcionalidade de detecção de exceções contextuais. Já a funcionalidade de tratamento de exceções sensível ao contexto do mecanismo proposto possibilita a adaptação, de acordo com o contexto e o tipo de exceção lançada, do fluxo de execução das tarefas que compõem um determinado sistema. Para lidar com exceções contextuais tanto podem ser realizadas adaptações no fluxo de uma ou várias tarefas quanto podem ser lançadas novas tarefas. É importante também destacar que a funcionalidade de tratamento de exceções sensível ao contexto do mecanismo funciona concomitantemente com o mecanismo de tratamento de exceções tradicional da linguagem Java, adotada na plataforma 83 (Android), a qual foi utilizada para implementação de referência. Por último, a propagação de exceções contextuais propicia que tratadores existentes no ambiente possam atuar sob exceções que não foram devidamente tratadas. Nesse caso, em consequência da reutilização do SysSU, é possível usufruir das propriedades de comunicação síncrona/assíncrona e desacoplada para possibilitar a implantação de tratadores sem interferir no funcionamento do sistema. Além do mecanismo proposto, nesta dissertação foi proposto o framework FRonTES, que através da organização e fornecimento de um conjunto de componentes prontos, torna mais fácil a utilização do mecanismo. Este, por sua vez, foi projetado para facilitar tanto a criação das tarefas que devem compor os sistemas ubíquos instanciados quanto a definição da porção excepcional desses sistemas (relacionada a detecção, propagação e tratamento de exceções contextuais). O framework foi utilizado no desenvolvimento de um protótipo, como prova de conceito, de um sistema ubíquo de controle de estacionamento, dado os cenários de exceções contextuais que podem ser explorados nesse tipo de sistema. Esta prova de conceito permitiu a demonstração das funcionalidades do mecanismo e a forma de utilizá-las, através do framework, aplicadas no tratamento de situações excepcionais. Esta prova de conceito possibilitou ratificar os benefícios e algumas limitações da utilização do mecanismo proposto para o tratamento de exceções contextuais em sistemas ubíquos orientados a tarefas. Para comparar a proposta desta dissertação com os trabalhos relacionados no Capítulo 3, a tabela 3.1 foi revisitada adicionando o mecanismo de tratamento de exceções sensível ao contexto juntamente ao framework FRonTES, propostos nesta dissertação, ao quadro comparativo. Na tabela 6.1 são então sumarizados novamente os requisitos tratados neste trabalho em comparação aos trabalhos relacionados já descritos no Capítulo 3. Tabela 6.1: Comparativo entre os trabalhos relacionados e os principais requisitos explorados nesta dissertação. Requisitos Detecção de Exceções Seleção Sensível ao Propagação de Exceções Tratamento de Exceções Orientação a Tarefas Sensível ao Contexto Contexto de Tratadores Sensível ao Contexto Sensível ao Contexto Soluções Iliasov e Romanovsky (2005) Ranganathan (2005) Damasceno et al. (2006a) Adams et al. (2007) Kulkarni e Tripathi (2010) Cho e Helal (2011) Leite, Rubira e Castor (2011) Rocha e Andrade (2012) Mec. Trat. de Exceções Sen. ao Contexto + FRonTES Possui suporte 6.2 Possui suporte parcial Não possui suporte Limitações Nos capítulos anteriores foram apresentadas características, funcionalidades e benefícios do mecanismo e framework propostos. Entretanto, as limitações deste trabalho, apresentadas de forma dispersa no texto, podem não ter sido percebidas adequadamente. Por 84 isso, com intuito de deixar explícito as restrições desta pesquisa, são listadas a seguir as suas quatro principais limitações. • Apenas duas estratégias de fluxo de execução das tarefas são fornecidas no FRonTES, que são as estratégias de fila e lista encadeada. Essas estratégias podem dificultar, por exemplo, a criação de tarefas que exijam a execução de passos em paralelo. Atualmente, para realizar esse tipo de ação em um único passo devem ser criadas Threads diferentes dentro deste passo, onde todo o controle de fluxo ficará a cargo da implementação. • A resolução de exceções concorrentes no mecanismo é limitada, pois exceções concorrentes e assíncronas (como pode ser o caso das exceções contextuais) podem caracterizar a ocorrência de uma exceção semanticamente mais relevante. Para ilustrar essa limitação pode-se pensar na ocorrência de uma exceção de fumaça e de temperatura elevada no sistema de estacionamento ubíquo. Nessa situação talvez seja mais apropriado tratar essas duas exceções em conjunto com o tratador da exceção de fogo do que tratar isoladamente fumaça e temperatura elevada. No mecanismo proposto, considera-se que o contexto excepcional deve ser especificado e fornecido adequadamente na implementação de cada tarefa de forma que o tratamento adequado seja associado as exceções detectadas pelo sistema. • A implementação do framework em um única plataforma (Java) também é uma limitação relacionada ao mecanismo, pois restringe sua reutilização em alguns tipos de dispositivos. • O fornecimento do mecanismo através de um framework exige uma certa curva de aprendizado antes da utilização. Esta limitação apesar de ter um certo destaque é inerente da utilização de qualquer framework, pois seu funcionamento e arquitetura devem ser conhecidos antes da reutilização. Apesar dessa limitação ser relevante, pode ser mitigada através de uma boa documentação e o fornecimento de implementações de exemplos. Essas limitações são consideradas importantes e mostram pontos de melhoria neste trabalho. Algumas delas são apontadas a seguir como trabalhos a serem investigados pelos autores. 6.3 Trabalhos Futuros Esta dissertação de mestrado aponta como relevante os seguintes trabalhos futuros relacionados a evolução do mecanismo proposto. • A criação de uma linguagem de domínio específico (DSL) que possibilite a especificação das tarefas que compõem os sistemas e dos seus possíveis fluxos de execução. Além disso, a DSL criada poderia permitir a definição das exceções contextuais relevantes para o sistema e seus possíveis tratadores. A utilização de uma abordagem generativa para sua instanciação dos sistemas especificados através da DSL tornaria ainda mais fácil o processo de desenvolvimento. Uma DSL pode ser criada através da utilização 85 de kits de desenvolvimento, como, por exemplo, o Xtext1 , onde a partir de uma gramática fornecida em tempo de projeto são gerados todos os elementos necessários para utilização da linguagem específica criada. • A extensão das estratégias de controle dos fluxos de execução das tarefas, adicionando outros padrões de cadenciamento dos passos a serem executados. Poderiam ser adicionados padrões, por exemplo, que facilitassem a criação de tarefas com fluxos alternativos e concorrentes. Essa extensão das estratégias pode ser obtida através da implementação de outras versões do componente TaskControlFlow, existente na arquitetura do framework. • A modificação da estratégia de resolução das exceções, acrescentando uma estrutura de árvore para permitir tratar de maneira mais rica exceções contextuais que ocorram de forma concorrente. Essa melhoria pode ser obtida através da modificação da forma como o ExceptionManagerService resolve e dispara as exceções contextuais detectadas para as tarefas que estão subscritas a ele. Além disso, o ExceptionManagerService pode se utilizar das funcionalidades de agregação e filtros disponíveis no SysSU para auxiliar na resolução de exceções contextuais de mais alto nível. • A implementação do FRonTES em outras plataformas, como windows phone e iOS. Além desses tópicos de trabalhos futuros, é relevante a realização de estudos de casos com o desenvolvimento de sistemas ubíquos mais complexos em situações de desenvolvimento reais, variando como parâmetros a utilização e a não utilização do mecanismo e do FRonTES. Assim, é possível observar mais precisamente os benefícios de utilização dessas contribuições, sem desconsiderar os elementos de contexto de um ambiente de desenvolvimento real. Por fim, também mostra-se relevante a realização de experimentos que permitam uma análise quantitativa sobre aspectos como a performance e o tempo de resposta do mecanismo com a utilização do SysSU. A partir dessa análise quantitativa é possível obter valores de parâmetros base, que servirão tanto para indicar a adequação ou não do mecanismo a determinados domínios específicos de sistemas ubíquos quanto para permitir analisar o grau de escalabilidade do mecanismo. 1 Disponível em www.eclipse.org/Xtext, acessado em 20/02/2013. 86 REFERÊNCIAS BIBLIOGRÁFICAS AALST, W.; ALDRED, L.; DUMAS, M.; HOFSTEDE, A. Design and implementation of the yawl system. In: PERSSON, A.; STIRNA, J. (Ed.). Advanced Information Systems Engineering. [S.l.]: Springer Berlin Heidelberg, 2004, (Lecture Notes in Computer Science, v. 3084). p. 142–159. ISBN 978-3-540-22151-7. ABOWD, G. D. Software engineering issues for ubiquitous computing. In: Proceedings of the 21st International Conference on Software Engineering. New York, NY, USA: ACM, 1999. (ICSE’99), p. 75–84. ISBN 1-58113-074-0. ADAMS, M.; HOFSTEDE, A. H. M. T.; AALST, W. M. P. V. D.; EDMOND, D. Dynamic, extensible and context-aware exception handling for workflows. In: Proceedings of the 2007 OTM Confederated international conference on On the move to meaningful internet systems: CoopIS, DOA, ODBASE, GADA, and IS - Volume Part I. Berlin, Heidelberg: Springer-Verlag, 2007. (OTM’07), p. 95–112. ISBN 3-540-76846-7, 978-3-540-76846-3. Disponível em: <http://dl.acm.org/citation.cfm?id=1784607.1784619>. ARIEF, B.; ILIASOV, A.; ROMANOVSKY, A. On using the cama framework for developing open mobile fault tolerant agent systems. In: Proceedings of the 2006 international workshop on Software engineering for large-scale multi-agent systems. New York, NY, USA: ACM, 2006. (SELMAS ’06), p. 29–36. ISBN 1-59593-395-6. Disponível em: <http://doi.acm.org/10.1145/1138063.1138070>. AVIZIENIS, A.; LAPRIE, J.-C.; RANDELL, B. Dependability and its threats: A taxonomy. In: JACQUART, R. (Ed.). Building the Information Society. Springer US, 2004, (IFIP International Federation for Information Processing, v. 156). p. 91–120. ISBN 978-1-4020-8156-9. Disponível em: <http://dx.doi.org/10.1007/978-1-4020-8157-6_13>. AVIZIENIS, A.; LAPRIE, J.-C.; RANDELL, B.; LANDWEHR, C. Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on Dependable and Secure Computing, IEEE Computer Society Press, Los Alamitos, CA, USA, v. 1, n. 1, p. 11–33, 2004. ISSN 1545-5971. BADRAM, J.; FRIDAY, A. Ubiquitous computing. In: KRUMM, J. (Ed.). Ubiquitous Computing Fundamentals. Redmond, Washington, USA: Chapman and HallCRC, 2010. p. 37–94. ISBN 978-1420093605. BARDRAM, J. E.; CHRISTENSEN, H. B. Pervasive computing support for hospitals: An overview of the activity-based computing project. IEEE Pervasive Computing, IEEE Educational Activities Department, Piscataway, NJ, USA, v. 6, n. 1, p. 44–51, jan. 2007. ISSN 1536-1268. Disponível em: <http://dx.doi.org/10.1109/MPRV.2007.19>. BEDER, D. M.; ARAúJO, R. B. de. Towards the definition of a context-aware exception handling mechanism. In: Dependable Computing Workshops (LADCW), 2011 Fifth Latin-American Symposium on. [S.l.: s.n.], 2011. p. 25 –28. BORCHERS, J.; RINGEL, M.; TYLER, J.; FOX, A. Stanford interactive workspaces: a framework for physical and graphical user interface prototyping. Wireless Communications, IEEE, v. 9, n. 6, p. 64 – 69, dec. 2002. ISSN 1536-1284. 87 BRITO, P. H. S.; LEMOS, R. D.; RUBIRA, C. M. F.; MARTINS, E. Architecting fault tolerance with exception handling: verification and validation. J. Comput. Sci. Technol., Institute of Computing Technology, Beijing, China, v. 24, n. 2, p. 212–237, mar. 2009. ISSN 1000-9000. Disponível em: <http://dx.doi.org/10.1007/s11390-009-9219-2>. BRUMITT, B.; MEYERS, B.; KRUMM, J.; KERN, A.; SHAFER, S. A. Easyliving: Technologies for intelligent environments. In: Proceedings of the 2nd international symposium on Handheld and Ubiquitous Computing. London, UK, UK: SpringerVerlag, 2000. (HUC ’00), p. 12–29. ISBN 3-540-41093-7. Disponível em: <http://dl.acm.org/citation.cfm?id=647986.743885>. BUTHPITIYA, S.; LUQMAN, F.; GRISS, M.; XING, B.; DEY, A. K. Hermes – a context-aware application development framework and toolkit for the mobile environment. In: Proceedings of the 2012 26th International Conference on Advanced Information Networking and Applications Workshops. Washington, DC, USA: IEEE Computer Society, 2012. (WAINA ’12), p. 663–670. ISBN 978-0-7695-4652-0. Disponível em: <http://dx.doi.org/10.1109/WAINA.2012.43>. CAMPBELL, R. H.; RANDELL, B. Error recovery in asynchronous systems. IEEE Transactions on Software Engineering, IEEE Press, Piscataway, NJ, USA, v. 12, p. 811–826, August 1986. ISSN 0098-5589. CARRIERO, N.; GELERNTER, D. Linda in context. Commun. ACM, ACM, New York, NY, USA, v. 32, n. 4, p. 444–458, abr. 1989. ISSN 0001-0782. Disponível em: <http://doi.acm.org/10.1145/63334.63337>. CHEN, C.; XU, Y.; LI, K.; HELAL, S. Reactive programming optimizations in pervasive computing. In: Applications and the Internet (SAINT), 2010 10th IEEE/IPSJ International Symposium on. [S.l.: s.n.], 2010. p. 96 –104. CHETAN, S.; RANGANATHAN, A.; CAMPBELL, R. Towards fault tolerance pervasive computing. IEEE Technology and Society Magazine, v. 24, n. 1, p. 38–44, March 2005. ISSN 0278-0097. CHEVERST, K.; DAVIES, N.; MITCHELL, K.; FRIDAY, A. Experiences of developing and deploying a context-aware tourist guide: the guide project. In: Proceedings of the 6th annual international conference on Mobile computing and networking. New York, NY, USA: ACM, 2000. (MobiCom ’00), p. 20–31. ISBN 1-58113-197-6. Disponível em: <http://doi.acm.org/10.1145/345910.345916>. CHO, E.-S.; HELAL, S. A situation-based exception detection mechanism for safety in pervasive systems. In: Proceedings of the 2011 IEEE/IPSJ International Symposium on Applications and the Internet. Washington, DC, USA: IEEE Computer Society, 2011. (SAINT ’11), p. 196–201. ISBN 978-0-7695-4423-6. Disponível em: <http://dx.doi.org/10.1109/SAINT.2011.35>. COSTA, C. A. da; YAMIN, A. C.; GEYER, C. F. R. Toward a general software infrastructure for ubiquitous computing. IEEE Pervasive Computing, v. 7, n. 1, p. 64 –73, jan.-march 2008. ISSN 1536-1268. COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T.; BLAIR, G. Distributed Systems: Concepts and Design. 5th. ed. USA: Addison-Wesley Publishing Company, 2011. ISBN 0132143011, 9780132143011. 88 DAMASCENO, K.; CACHO, N.; GARCIA, A.; ROMANOVSKY, A.; LUCENA, C. Context-aware exception handling in mobile agent systems: The moca case. In: Proceedings of the 2006 international workshop on Software Engineering for Large-Scale Multi-Agent Systems. New York, NY, USA: ACM, 2006. (SELMAS ’06), p. 37–44. ISBN 1-59593-395-6. DAMASCENO, K.; CACHO, N.; GARCIA, A.; LUCENA, C. Tratamento de exceções sensível ao contexto. In: XX Simpósio Brasileiro de Engenharia de Software (SBES’2006). [S.l.: s.n.], 2006. p. 49–64. DAMASCENO, K. N. F. Tratamento de Exceções Sensível ao Contexto. Dissertação (Mestrado) — Pontifícia Universidade Católica do Rio de Janeiro - PUC-Rio, 2006. DEY, A. K. Understanding and using context. Personal Ubiquitous Computing, SpringerVerlag, London, UK, v. 5, n. 1, p. 4–7, 2001. ISSN 1617-4909. EASTERBROOK, S.; SINGER, J.; STOREY, M.-A.; DAMIAN, D. Selecting empirical methods for software engineering research. In: SHULL, F.; SINGER, J.; SJOBERG, D. I. K. (Ed.). Guide to Advanced Empirical Software Engineering. [S.l.]: Springer London, 2008. p. 285–311. ISBN 978-1-84800-044-5. EDWARDS, G.; SEO, C.; POPESCU, D.; MALEK, S.; MEDVIDOVIC, N. Self-* software architectures and component middleware in pervasive environments. In: Proceedings of the 5th international workshop on Middleware for pervasive and ad-hoc computing: held at the ACM/IFIP/USENIX 8th International Middleware Conference. New York, NY, USA: ACM, 2007. (MPAC ’07), p. 25–30. ISBN 978-1-59593-930-2. Disponível em: <http://doi.acm.org/10.1145/1376866.1376871>. ENDRES, C.; BUTZ, A.; MACWILLIAMS, A. A survey of software infrastructures and frameworks for ubiquitous computing. Mobile Information Systems, IOS Press, Amsterdam, The Netherlands, The Netherlands, v. 1, p. 41–80, January 2005. ISSN 1574-017X. FAYAD, M. E.; SCHMIDT, D. C.; JOHNSON, R. E. Building application frameworks: object-oriented foundations of framework design. New York, NY, USA: John Wiley & Sons, Inc., 1999. ISBN 0-471-24875-4. FERREIRA, G. G. L.; SILVA, F. L. D.; LIBRELOTTO, G. R.; AUGUSTIN, I.; YAMIN, A. C. Introduzindo o gerenciando de tarefas clínicas em um middleware da computação pervasiva. In: IX Workshop de Informática Médica. Anais do XXIX Congresso da Sociedade Brasileira de Computação (CSBC-2009). [S.l.: s.n.], 2009. p. 2035–2044. FETZER, C.; HöGSTEDT, K. Challenges in making pervasive systems dependable. In: SCHIPER, A.; SHVARTSMAN, A. A.; WEATHERSPOON, H.; ZHAO, B. Y. (Ed.). Future directions in distributed computing. Berlin, Heidelberg: Springer-Verlag, 2003. p. 186–190. ISBN 3-540-00912-4. FLECK, M.; FRID, M.; KINDBERG, T.; O’BRIEN-STRAIN, E.; RAJANI, R.; SPASOJEVIC, M. Rememberer: A tool for capturing museum visits. In: Proceedings of the 4th international conference on Ubiquitous Computing. London, UK, UK: Springer-Verlag, 2002. (UbiComp ’02), p. 48–55. ISBN 3-540-44267-7. Disponível em: <http://dl.acm.org/citation.cfm?id=647988.741492>. 89 GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. M. Design Patterns: Elements of Reusable Object-Oriented Software. 1. ed. [S.l.]: Addison-Wesley, 1995. GARCIA, A. F.; RUBIRA, C. M. F.; ROMANOVSKY, A.; XU, J. A comparative study of exception handling mechanisms for building dependable object-oriented software. Journal of Systems and Software, v. 59, n. 2, p. 197–222, November 2001. ISSN 01641212. GARLAN, D.; SIEWIOREK, D. P.; SMAILAGIC, A.; STEENKISTE, P. Project aura: Toward distraction-free pervasive computing. IEEE Pervasive Computing, v. 1, n. 2, p. 22–31, apr-jun 2002. ISSN 1536-1268. GOODENOUGH, J. B. Exception handling design issues. SIGPLAN Not., ACM, New York, NY, USA, v. 10, n. 7, p. 41–45, jul. 1975. ISSN 0362-1340. Disponível em: <http://doi.acm.org/10.1145/987305.987313>. GOODENOUGH, J. B. Exception handling: Issues and a proposed notation. Communications of the ACM, ACM Press, New York, NY, USA, v. 18, p. 683–696, December 1975. ISSN 0001-0782. GRIMM, R.; DAVIS, J.; LEMAR, E.; MACBETH, A.; SWANSON, S.; ANDERSON, T.; BERSHAD, B.; BORRIELLO, G.; GRIBBLE, S.; WETHERALL, D. System support for pervasive applications. ACM Transactions on Computer Systems, ACM, New York, NY, USA, v. 22, p. 421–486, November 2004. ISSN 0734-2071. HUANG, R.; CAO, Q.; ZHOU, J.; SUN, D.; HUANG, R.; SU, Q. Context-aware active task discovery for pervasive computing. In: Proceedings of the 2008 International Conference on Computer Science and Software Engineering - Volume 01. Washington, DC, USA: IEEE Computer Society, 2008. p. 463–466. ISBN 978-0-7695-3336-0. IBM. 2005. Website atualmente indisponível. Disponível em: <http://www306.ibm.com/software/pervasive/module/index.shtml>. ILIASOV, A.; ROMANOVSKY, E. Cama: Structured coordination space and exception propagation mechanism for mobile agents. In: In: ECOOP Workshop on Exception Handling. [S.l.: s.n.], 2005. JANG, M.; SUH, S.-T. U-city: new trends of urban planning in korea based on pervasive and ubiquitous geotechnology and geoinformation. In: Proceedings of the 2010 international conference on Computational Science and Its Applications - Volume Part I. Berlin, Heidelberg: Springer-Verlag, 2010. (ICCSA ’10), p. 262–270. ISBN 3-642-12155-1, 978-3-642-12155-5. Disponível em: <http://dx.doi.org/10.1007/978-3-642-12156-2_20>. JAROUCHEH, Z.; LIU, X.; SMITH, S. A perspective on middleware-oriented context-aware pervasive systems. In: Proceedings of the 2009 33rd Annual IEEE International Computer Software and Applications Conference - Volume 02. Washington, DC, USA: IEEE Computer Society, 2009. (COMPSAC ’09), p. 249–254. ISBN 978-0-7695-3726-9. Disponível em: <http://dx.doi.org/10.1109/COMPSAC.2009.142>. JEON, N. J.; LEEM, C. S.; KIM, M. H.; SHIN, H. G. A taxonomy of ubiquitous computing applications. Wireless Personal Communications, v. 43, n. 4, p. 1229–1239, 2007. ISSN 09296212. Disponível em: <http://www.springerlink.com/index/10.1007/s11277-007-9297-9>. 90 KAENAMPORNPAN, M.; O’NEILL, E. Modelling context: An activity theory approach. In: In Ambient Intelligence: Second European Symposium, EUSAI 2004. [S.l.]: Springer, 2004. p. 367–374. KAENAMPORNPAN, M.; O’NEILL, E. Integrating history and activity theory in context aware system design. In: 1ST International Workshop on Exploiting Context Histories in Smart Environments. [S.l.: s.n.], 2005. KINDBERG, T.; FOX, A. System software for ubiquitous computing. IEEE Pervasive Computing, IEEE Educational Activities Department, Piscataway, NJ, USA, v. 1, p. 70–81, January 2002. ISSN 1536-1268. KNHC. U-City Business Plan: Korea National Housing Cooperation. 2007. KNIGHT, J. Fundamentals of Dependable Computing for Software Engineers. 1st. ed. [S.l.]: Chapman & Hall/CRC, 2012. ISBN 1439862559, 9781439862551. KRUMM, J. Ubiquitous Computing Fundamentals. 1st. ed. [S.l.]: Chapman & Hall/CRC, 2009. ISBN 1420093606, 9781420093605. KULKARNI, D.; TRIPATHI, A. A framework for programming robust context-aware applications. IEEE Transactions on Software Engineering, IEEE Computer Society, Los Alamitos, CA, USA, v. 36, n. 2, p. 184–197, 2010. ISSN 0098-5589. LAPRIE, J.-C.; AVIZIENIS, A.; KOPETZ, H. (Ed.). Dependability: Basic Concepts and Terminology. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 1992. ISBN 0387822968. LAUESEN, S.; KUHAIL, M. A. Use cases versus task descriptions. In: Proceedings of the 17th international working conference on Requirements engineering: foundation for software quality. Berlin, Heidelberg: Springer-Verlag, 2011. (REFSQ’11), p. 106–120. ISBN 978-3-642-19857-1. Disponível em: <http://dl.acm.org/citation.cfm?id=1987360.1987378>. LEE, P. A.; ANDERSON, T. Fault Tolerance: Principles and Practice. 2nd. ed. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 1990. ISBN 0387820779. LEEM, C. S.; JEON, N. J.; CHOI, J. H.; SHIN, H. G. A business model (bm) development methodology in ubiquitous computing environments. In: Proceedings of the 2005 international conference on Computational Science and Its Applications - Volume Part IV. Berlin, Heidelberg: Springer-Verlag, 2005. (ICCSA’05), p. 86–95. ISBN 3-540-25863-9, 978-3-540-25863-6. Disponível em: <http://dx.doi.org/10.1007/11424925_11>. LEITE, D.; RUBIRA, C.; CASTOR, F. Exception handling for service component architectures. In: Dependable Computing (LADC), 2011 5th Latin-American Symposium on. [S.l.: s.n.], 2011. p. 84 –93. LIMA, F. F.; ROCHA, L. S.; MAIA, P. H.; ANDRADE, R. M. A decoupled and interoperable architecture for coordination in ubiquitous systems. Software Components, Architectures and Reuse (SBCARS), Brazilian Symposium on, IEEE Computer Society, Los Alamitos, CA, USA, v. 0, p. 31–40, 2011. LIMA, F. F. de P. SysSU - Um Sistema de Suporte para Computação Ubíqua. Dissertação (Mestrado) — Universidade Federal do Ceará - UFC, 2011. 91 LOKE, S. W. Building taskable spaces over ubiquitous services. IEEE Pervasive Computing, IEEE Computer Society, Los Alamitos, CA, USA, v. 8, n. 4, p. 72–78, oct.-dec. 2009. ISSN 1536-1268. LOPES, F.; CACHO, N.; BATISTA, T. Utilizando reconfiguração dinâmica e notificação de contextos para o desenvolvimento de software ubíquo. In: XXI Simpósio Brasileiro de Engenharia de Software (SBES’2007). [S.l.: s.n.], 2007. p. 182–198. MAIA, M. E.; ROCHA, L. S.; ANDRADE, R. M. C. Requirements and challenges for building service-oriented pervasive middleware. In: ICPS’09: Proceedings of the 2009 International Conference on Pervasive Services. New York, NY, USA: ACM Press, 2009. p. 93–102. MARGOLIS, B.; SHARPE, J. (Ed.). SOA for the Business Developer - Concepts, BPEL, and SCA. [S.l.]: MC Press, 2007. ISBN 978-1583470657. MASUOKA, R.; PARSIA, B.; LABROU, Y. Task computing - the semantic web meets pervasive computing. In: Proceedings of 2nd International Semantic Web Conference (ISWC2003). [S.l.: s.n.], 2003. p. 866–881. MATTERN, F. The vision and technical foundations of ubiquitous computing. Upgrade, v. 2, n. 5, p. 2–6, oct 2001. Disponível em: <http://www.vs.inf.ethz.ch/publ/papers/up25MatternUbi.pdf>. MEIER, R. State of the Art Review of Distributed Event Models. Dublin, Irlanda, 2000. MILLER, R.; TRIPATHI, A. The guardian model for exception handling in distributed systems. In: Reliable Distributed Systems, 2002. Proceedings. 21st IEEE Symposium on. [S.l.: s.n.], 2002. p. 304 – 313. ISSN 1060-9857. MILLER, R.; TRIPATHI, A. The guardian model and primitives for exception handling in distributed systems. IEEE Transactions on Software Engineering, IEEE Press, Piscataway, NJ, USA, v. 30, p. 1008–1022, December 2004. ISSN 0098-5589. NIEMELä, E.; LATVAKOSKI, J. Survey of requirements and solutions for ubiquitous software. In: MUM’04: Proceedings of the 3rd International Conference on Mobile and Ubiquitous Multimedia. New York, NY, USA: ACM, 2004. p. 71–78. ISBN 1-58113-981-0. ORACLE. The Java Tutorials: Exceptions. 2012. Website. Visitado em 22 de agosto de 2012. Disponível em: <http://docs.oracle.com/javase/tutorial/essential/exceptions/index.html>. PARNAS, D. L.; WüRGES, H. Response to undesired events in software systems. In: Proceedings of the 2nd International Conference on Software Engineering. Los Alamitos, CA, USA: IEEE Computer Society Press, 1976. (ICSE’76), p. 437–446. POSLAD, S. Ubiquitous Computing: Smart Devices, Environments and Interactions. [S.l.]: John Wiley & Sons, Inc., 2009. ISBN 978-0470035603. PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5th. ed. [S.l.]: McGraw-Hill Science, 2001. ISBN 0073655783. RANGANATHAN, A. A Task Execution Framework for Autonomic Ubiquitous Computing. Tese (Doutorado) — Universidade de Illinois, Urbana, Illinois, 2005. 92 RANGANATHAN, A.; CAMPBELL, R. A Middleware to Reduce the Complexity of Developing Ubiquitous Computing Systems. 2005. Online paper. Visitado em 22 de agosto de 2012. Disponível em: <http://gaia.cs.uiuc.edu/papers/new080405/Middleware05_Complexity.pdf>. ROCHA, L.; ANDRADE, R. M. C. Towards a formal model to reason about context-aware exception handling. In: 5th International Workshop on Exception Handling (ICSE’12 Workshop). [S.l.: s.n.], 2012. To be published. ROCHA, L. S.; CASTRO, C. E. P. de L.; MACHADO, J. C.; ANDRADE, R. M. C. Utilizando reconfiguração dinâmica e notificação de contextos para o desenvolvimento de software ubíquo. In: XXI Simpósio Brasileiro de Engenharia de Software (SBES’2007). [S.l.: s.n.], 2007. p. 219–235. ROCHA, L. S.; FILHO, J. B. F.; LIMA, F. F. P.; MAIA, M. E. F.; VIANA, W.; CASTRO, M. F. d.; ANDRADE, R. M. C. Ubiquitous software engineering: Achievements, challenges and beyond. Simpósio Brasileiro de Engenharia de Software (SBES), IEEE Computer Society, v. 0, p. 132–137, 2011. ROMAN, M.; AL-MUHTADI, J.; ZIEBART, B.; CAMPBELL, R.; MICKUNAS, M. D. System support for rapid ubiquitous computing application development and evaluation. In: Workshop on System Support for Ubiquitous Computing (UbiSys03),5th International Conference on Ubiquitous Computing (UbiComp 2003). [S.l.: s.n.], 2003. ROMAN, M.; CAMPBELL, R. H. Gaia: enabling active spaces. In: Proceedings of the 9th workshop on ACM SIGOPS European workshop: beyond the PC: new challenges for the operating system. New York, NY, USA: ACM, 2000. (EW 9), p. 229–234. Disponível em: <http://doi.acm.org/10.1145/566726.566772>. ROMáN, M.; HESS, C.; CERQUEIRA, R.; RANGANATHAN, A.; CAMPBELL, R. H.; NAHRSTEDT, K. A middleware infrastructure for active spaces. IEEE Pervasive Computing, IEEE Educational Activities Department, Piscataway, NJ, USA, v. 1, n. 4, p. 74–83, out. 2002. ISSN 1536-1268. Disponível em: <http://dx.doi.org/10.1109/MPRV.2002.1158281>. SACRAMENTO, V.; ENDLER, M.; RUBINSZTEJN, H. K.; LIMA, L. S.; GONCALVES, K.; NASCIMENTO, F. N.; BUENO, G. A. Moca: A middleware for developing collaborative applications for mobile users. IEEE Distributed Systems Online, IEEE Educational Activities Department, Piscataway, NJ, USA, v. 5, n. 10, p. 2–, out. 2004. ISSN 1541-4922. Disponível em: <http://dx.doi.org/10.1109/MDSO.2004.26>. SAKAMURA, K. The tron project. IEEE Micro, IEEE Computer Society Press, Los Alamitos, CA, USA, v. 7, n. 2, p. 8–14, mar. 1987. ISSN 0272-1732. Disponível em: <http://dx.doi.org/10.1109/MM.1987.304835>. SATYANARAYANAN, M. Pervasive computing: Vision and challenges. IEEE Personal Communications, v. 8, n. 4, p. 10 –17, August 2001. ISSN 1070-9916. SCHMID, H. A. Systematic framework design by generalization. Commun. ACM, ACM, New York, NY, USA, v. 40, n. 10, p. 48–51, out. 1997. ISSN 0001-0782. Disponível em: <http://doi.acm.org/10.1145/262793.262803>. 93 SFMTA. Página do Projeto SFPark. 2012. Website. Visitado em 22 de agosto de 2012. Disponível em: <http://sfpark.org/>. SOUSA, J. P.; GARLAN, D. Aura: an architectural framework for user mobility in ubiquitous computing environments. In: In Proceedings of the 3rd Working IEEE/IFIP Conference on Software Architecture. [S.l.]: Kluwer Academic Publishers, 2002. p. 29–43. SOUSA, J. P.; POLADIAN, V.; GARLAN, D.; SCHMERL, B.; SHAW, M. Task-based adaptation for ubiquitous computing. IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, v. 36, n. 3, p. 328–340, may 2006. ISSN 1094-6977. SOUZA, M. V. B.; AUGUSTIN, I. Inferência de atividades clínicas a partir de propriedades do contexto. In: X Workshop de Informática Médica. Anais do XXX Congresso da Sociedade Brasileira de Computação (CSBC-2010). [S.l.: s.n.], 2010. p. 1717–1726. SPíNOLA, R. O.; MASSOLLAR, J.; TRAVASSOS, G. H. Checklist to characterize ubiquitous software projects. In: XXI Simpósio Brasileiro de Engenharia de Software (SBES’2007). [S.l.: s.n.], 2007. p. 39–55. SPíNOLA, R. O.; TRAVASSOS, G. H. Towards a framework to characterize ubiquitous software projects. Journal Information and Software Technology, Butterworth-Heinemann, Newton, MA, USA, v. 54, n. 7, p. 759–785, jul. 2012. ISSN 0950-5849. Disponível em: <http://dx.doi.org/10.1016/j.infsof.2012.01.009>. STREITZ, N. A.; GEISSLER, J.; HOLMER, T.; KONOMI, S.; MüLLER-TOMFELDE, C.; REISCHL, W.; REXROTH, P.; SEITZ, P.; STEINMETZ, R. i-land: an interactive landscape for creativity and innovation. In: Proceedings of the SIGCHI conference on Human factors in computing systems: the CHI is the limit. New York, NY, USA: ACM, 1999. (CHI ’99), p. 120– 127. ISBN 0-201-48559-1. Disponível em: <http://doi.acm.org/10.1145/302979.303010>. VITERBO, J.; SACRAMENTO, V.; ROCHA, R.; BAPTISTA, G.; MALCHER, M.; ENDLER, M. A middleware architecture for context-aware and location-based mobile applications. In: Proceedings of the 2008 32nd Annual IEEE Software Engineering Workshop. Washington, DC, USA: IEEE Computer Society, 2008. (SEW ’08), p. 52–61. ISBN 978-0-7695-3617-0. Disponível em: <http://dx.doi.org/10.1109/SEW.2008.7>. VO, C.; TORABI, T.; LOKE, S. W. Task-oriented systems for interaction with ubiquitous computing environments. 7th International ICST Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services (Mobiquitous 2010), Sydney, Austrália, 2010. VO, C. C.; LOKE, S. W.; TORABI, T.; NGUYEN, T. Taskrec: a task-based user interface for smart spaces. In: Proceedings of the 9th International Conference on Advances in Mobile Computing and Multimedia. New York, NY, USA: ACM, 2011. (MoMM ’11), p. 223–226. ISBN 978-1-4503-0785-7. Disponível em: <http://doi.acm.org/10.1145/2095697.2095741>. VO, C. C.; TORABI, T.; LOKE, S. W. Towards a task-oriented framework for smart spaces. In: LÓPEZ-CÓZAR, R.; AGHAJAN, H. K.; AUGUSTO, J. C.; COOK, D. J.; O’DONOGHUE, J.; CALLAGHAN, V.; EGERTON, S.; JOHNSON, B. D. (Ed.). Intelligent Environments (Workshops). [S.l.]: IOS Press, 2010. (Ambient Intelligence and Smart Environments, v. 8), p. 101–108. ISBN 978-1-60750-639-3. 94 WANG, Z.; GARLAN, D. Task-Driven Computing. [S.l.], 2000. Disponível em http://repository.cmu.edu/compsci/695/ , acessado em: 29/05/2012. WEISER, M. The computer for the 21st century. Scientific American, v. 265, n. 3, p. 66–75, September 1991. WEISER, M. Hot topics: Ubiquitous computing. Computer, IEEE Computer Society, v. 26, n. 10, p. 71–72, October 1993. ISSN 0018–9162. WEISER, M. Some computer science issues in ubiquitous computing. Communications of the ACM, ACM Press, New York, NY, USA, v. 36, p. 75–84, July 1993. ISSN 0001-0782. WEISER, M.; BROWN, J. S. The coming age of calm technolgy. In: USA: Copernicus, 1997. p. 75–85. ISBN 0-38794932-1. . New York, NY, YIN, R. K. Case Study Research: Design and Methods. [S.l.]: Sage Publications, 2002. ISBN 0761925538. Figura A.1: Diagrama de classes simplificado do FRonTES. APÊNDICE A -- DIAGRAMA DE CLASSES DO FRONTES 95