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