Tratamento de Exceções Sensível a Contexto

Tratamento de Exceções Sensível a Contexto
Karla Nazaré Ferreira Damasceno Orientador: Carlos José Pereira de Lucena Co-orientador: Alessandro Fabricio Garcia PUC-Rio, 22 de outubro de 2005

Agenda Principais Conceitos
Tratamento de Exceções (TE) Sensibilidade ao contexto Descrição do Problema e Proposta de Solução Mecanismos de TE em Sistemas Multi-Agentes (SMAs) TE em Middlewares para aplicações sensíveis ao contexto Mobile Collaboration Architecture (MoCA) Algumas discussões sobre TE utilizando MoCA Referências Bibliográficas Laboratório de Engenharia de Software – PUC-Rio

Defeito, Erro e Falha Existe defeito (observável externamente) quando:
um componente ele deixa de oferecer as funcionalidades previstas ou faz em desacordo com sua especificação. Existe erro (estático e interno) quando: existe de um estado interno em um componente, que sob determinadas entradas é propenso a ocorrência de um defeito. Falha é um evento ou seqüência de eventos que propicia o surgimento de um erro. Falha provoca um erro no estado do sistema, que se propaga até afetar o seu comportamento, resultando num defeito. Laboratório de Engenharia de Software – PUC-Rio

Exceção Em situações de erro, um componente gera exceções.
Exceções podem ser classificadas em: de interface: sinalizada em resposta a uma requisição que não está conforme a interface do componente; de defeito: sinalizada se um componente determina que por alguma razão não pode fornecer o serviço especificado; internas: levantadas pelo componente para chamar sua própria medida interna de tolerância a falhas. Laboratório de Engenharia de Software – PUC-Rio

Componente Ideal Laboratório de Engenharia de Software – PUC-Rio

O que é Tratamento de Exceção?
Capacidade de um software para: reagir apropriadamente diante da ocorrência de exceções continuar ou interromper sua execução, para preservar a máxima integridade de dados possível. O código (detecção e tratamento de exceções) em sistemas confiáveis é numeroso e complexo. Projeto dos mecanismos de tratamento de exceções deve ser simples, fácil de usar e fornecer separação entre código normal e excepcional. Laboratório de Engenharia de Software – PUC-Rio

Taxonomia de Tratamento de Exceções
A1. Representação da Exceção A2. Exceções externas em assinaturas A3. Separação entre exceção externa e interna A4. Localização de Tratadores A5. Associação (Binding) de Tratadores A6. Propagação de Exceção A7. Continuação do Fluxo de Controle A8. Ações de Clean-up A9. Verificações de Confiabilidade A10. Tratamento de Exceções Concorrente Laboratório de Engenharia de Software – PUC-Rio

Contexto Informação que permite que um sistema tenha conhecimento de sua situação atual. De acordo com a definição abstrata de Dey et al “Contexto é qualquer informação que pode ser usada para caracterizar a situação de uma entidade. Uma entidade é uma pessoa, lugar ou objeto que é considerado relevante para a interação entre um usuário e uma aplicação, incluindo o próprio usuário e a aplicação.“ Classificação: Dispositivo, Usuário e Ambiente. Exemplos de contextos: perfil do usuário, localização, altitude, orientação, temperatura, velocidade, memória, bateria do dispositivo, CPU, etc. Contexto (context-aware) x contexto de tratamento de exceções (escopo). Laboratório de Engenharia de Software – PUC-Rio

Sistema Sensível a Contexto
Sistemas DISTRIBUÍDOS e MÓVEIS são caracterizados por: Conexão instável e pouca largura de banda Cenários de execução extremamente dinâmicos Pouco sentido em esconder completamente informações de contexto e os detalhes de implementação Sistema sensível a contexto possui a habilidade para interpretar e usar contexto situacional para servir de base para um comportamento adaptativo baseado em mudanças neste contexto. De acordo com a definição abstrata de Dey et al: “Um sistema é sensível a contexto se ele usa contexto para fornecer informação relevante e /ou serviços para o usuário, onde relevância depende da tarefa do usuário.” Laboratório de Engenharia de Software – PUC-Rio

Middleware Sensível ao Contexto
Sensores: capturam informações do ambiente e transformam em um formato digital para ser processado pelo ambiente computacional. Provedores de informação de contexto: populam o sistema com as informações de contexto, geradas a partir dos dados recebidos pelos sensores ou outras informações de contexto. Brokers ou serviços de contexto: registram os interesses de consumidores e disseminam as informações de contexto. Consumidores: solicitam as informações de contexto. são notificados pelo broker sobre a condição de interesse. podem ser aplicações, serviços ou outros componentes do middleware. Laboratório de Engenharia de Software – PUC-Rio

Provedor de informação
Consumidor Sensor A Broker de Contexto Contexto Consumidor Sensor B Sensor C Consumidor Laboratório de Engenharia de Software – PUC-Rio

Tratamento de Exceções em SMAs
Tratamento de exceções é essencial para incorporação e estruturação das atividades de tolerância à falhas em um sistema de software confiável. Falta de suporte para tratamento de exceções em SMAs, duvidoso que possuam a robustez esperada. SMAs confiáveis requerem mecanismos apropriados considerando suas características particulares. Laboratório de Engenharia de Software – PUC-Rio

Mecanismos de TE em SMAs
Maior parte dos sistemas utiliza o mecanismo fornecido pela linguagens, o que não é apropriado para TE em SMAs. Existe a necessidade de integrar o TE com abstrações do paradigma de agentes. Tratamento de Exceções em SMAs: deve envolver problemas de tratamento de exceções da programação seqüencial, concorrente e distribuída, além de novas questões como mobilidade e sensitividade a contexto. Laboratório de Engenharia de Software – PUC-Rio

Características Gerais Problemas Encontrados
Tripathi e Miller Características Gerais Agente especial “guardião” atua como tratador de exceções para um conjunto de agentes. Exceções são classificadas em internas e externas ao agente, as externas são propagadas para o guardião. Principal característica: separação e encapsulamento do TE através do agente guardião. Problemas Encontrados Não existe suporte para TE nas colaborações entre os agentes. Desvantagens do guardião: possibilidade de gerar somente reações gerais para as exceções, devido à impossibilidade de tratadores escritos no contexto da entidade que chamou o serviço; gargalo criado para o sistema inteiro, pela centralização do tratamento de exceções em uma entidade especializada; Não considera as necessidades de aplicações móveis sensíveis a contexto. Laboratório de Engenharia de Software – PUC-Rio

Souchon, Dony, Urtado e Vauttier
Características Gerais Considera que mecanismos de TE para SMAs devem: preservar o paradigma de agentes; considerar a concorrência e a comunicação assíncrona; considerar a organização social de agentes (grupos e papéis). Problemas Encontrados Preocupação quase que exclusiva com localização de tratadores. Não possibilita a associação dinâmica entre tratadores e ocorrências de exceção. Não considera as necessidades de aplicações móveis sensíveis a contexto. Laboratório de Engenharia de Software – PUC-Rio

Características Gerais Problemas Encontrados
Iliasov e Romanovsky Características Gerais Permite recuperação de erros específicos da aplicação, em SMAs baseados em coordenação. Comunicação anônima entre os agentes que lêem tuplas do espaço de tuplas. Separação lógica forte das tuplas normais e excepcionais, usando um espaço de tuplas para exceções. Problemas Encontrados Específico para SMAs com interação baseada em espaços de tuplas. Não considera as necessidades de aplicações móveis sensíveis a contexto. Laboratório de Engenharia de Software – PUC-Rio

Mecanismos de TE em SMAs
Não tratam requisitos de aplicações sensíveis a contexto: especificar explicitamente “contextos excepcionais”; determinar a estratégia de tratamento, considerando contextos do agente e do dispositivo móvel; realizar tratamento de “contextos excepcionais” concorrentes que ocorrem nos agentes e dispositivos móveis; realizar tratamento cooperativo de um “contexto excepcional” que ocorre durante a execução da aplicação móvel. Representação da Exceção É suficiente representar exceções através de objetos? A representação depende da infra-estrutura de comunicação utilizada? Quando exceções devem ser enviadas através da rede, devem ser enviadas como mensagens ou tuplas? Como representar exceções de contexto? Localização de Tratadores Tratadores devem ser associados a novas regiões protegidas, como exemplo, agente, papel, organização, etc. Associação de Tratadores (e ocorrências de exceções) Necessidade de reconfiguração dinâmica: diferentes tratadores para uma mesma exceção. Ex. Quando agentes se movem para novos ambientes, tratadores adicionais podem ser associados ao conjunto de tratadores do agente. novos escopos de TE (ambientes remotos, papéis, organizações, etc.) requerem tratadores diferentes em tempo de execução; Estratégia de associação pode considerar informações de contexto. Propagação de Exceção Para quem um agente deve propagar uma exceção que ele não sabe tratar? Para o agente que fez a requisitou, seu ambiente ou para os membros da organização? Eventualmente exceções tem que ser propagadas para o ambiente remoto do agente! Ex. Se ocorre a morte inesperada de um agente, todos os outros agentes precisam ser avisados! Laboratório de Engenharia de Software – PUC-Rio

TE em Middlewares Sensíveis ao Contexto
Arquiteturas existentes para sistemas sensíveis a contexto não se preocupam com a concepção de mecanismos de tratamento de exceções. Utilização apenas do mecanismo de tratamento de exceções fornecido por linguagens de programação. Laboratório de Engenharia de Software – PUC-Rio

Exemplos de Middlewares
Modelo Informação de Contexto Principais componentes Moca Baseado em eventos ou Publish/Subscribe Dispositivo (como CPU, memória, energia, conexão, etc.) Localização do dispositivo Possibilidade de registro de interesse em eventos da aplicação Conjunto de API’s: cliente, servidor, comunicação síncrona e assíncrona. Conjunto de serviços: Monitor, Configuration Service (CS), Discovery Service (DS), Context Information Service (CIS), Location Inference Service (LIS), Symbolic Region Manager (SRM). Lime Espaço de Tuplas Não se aplica CARISMA Reflexivo Recursos do Dispositivo (como energia, poder de processamento, tamanho da tela, memória, etc.) Recursos fora do dispositivo (como largura de banda, conexão da rede, hosts próximos, localização, etc.) Recursos definidos pela aplicação (como atividade e humor do usuário, etc.) Core, trata questões como o suporte p/ comunicação assíncrona e a descoberta de serviços; Context Management, interage com sensores físicos e monitora mudanças de contexto; Application Model, define framework padrão para criar e executar aplicações context-aware. Core Services, responsáveis por responder às requisições de qualidade de serviços definidas no nível de aplicação; Laboratório de Engenharia de Software – PUC-Rio

Resumo dos problemas Agentes devem considerar os contextos onde estão atuando e os usuários do sistema onde estão inseridos. Tratamento de exceções deve considerar a variação de tais contextos. Modelos tradicionais de tratamento de exceções negligenciam tais problemas e não fornecem soluções apropriadas. Laboratório de Engenharia de Software – PUC-Rio

Objetivos Levantar as propostas para tratamento de exceções para SMAs existentes na literatura; Definir um modelo geral de tratamento de exceções sensível ao contexto; Implementar o modelo utilizando a arquitetura MoCA; Implementar aplicações como estudo de caso. Laboratório de Engenharia de Software – PUC-Rio

MoCA: Mobile Collaboration Architecture
Middleware para desenvolvimento e execução de aplicações colaborativas sensíveis ao contexto: Estruturado em uma rede wireless (802.11). Usuários com laptops e palmtops. Para aplicações intra-domínio (ex. campus de universidade). Provê meios para coletar, armazenar e processar dados de contexto dos dispositivos móveis. Consiste essencialmente em: serviços centrais que permitem a execução de aplicações sensíveis ao contexto. APIs que facilitam o desenvolvimento das aplicações e o acesso aos serviços fornecidos. framework OO para instanciar os proxies para aplicação. Laboratório de Engenharia de Software – PUC-Rio

Provedor de informação de contexto
Server CIS: Context Information Service Provedor de informação de contexto Sensor A Broker de Contexto Virtual Lines Provedor Broker Sensor B Provedor Broker Sensor C LIS: Location Inference Service Laboratório de Engenharia de Software – PUC-Rio

Serviços Core Services FW Application API API DS CIS LIS CS M Legenda
Server Proxy M Client API FW API In this slides I’m going to show the moca infrastructure 0 – MoCA architecture is composed by core services, monitor, APIs and a Framework. 0.1 - The monitor is executing on each mobile device and it collects the network and device’s context information and periodically send them to the context information service. This is the monitor screenshot. It shows the context information collected that are{CPU Usage, Free Memory,…} 1 – among the core services we have the DS (discovery service), CIS (Context Information Service), LIS (Location Inference Service) and CS (configuration service) 2 – DS is used by the application server and proxy for registering the service that they implement. This way, an application client can locate a server or proxy through the DS 3 – the context information service receives and processes the network and device’s context information sent by the monitors. It also receives requests for notifications from application proxies. This way, it eventually generates and delivers events to a proxy whenever a change in a device’s state is of interest to this proxy 4 – LIS Infers the approximate location of the device in a wireless network 5 – CS stores and manages the configuration of each monitor running on the mobile device 7 – Every application which uses moca’s infrastructure follows the three tiers model composed by: Server, Proxy and client The first two run in the wired network and the last one runs in the wireless network The proxy intermediates all communication between the application servers and the clients. 8 – the proxy processes the client’s request and it could be in charge of several context-dependent adaptations. Legenda DS - Discovery Service CIS - Context Information Service (Provedor de contexto e Broker) LIS - Location Inference Service (Consumidor, Provedor de contexto e Broker) CS - Configuration Service M - Monitor (Sensor) Laboratório de Engenharia de Software – PUC-Rio

Padrão Típico de Interações
Sub/Ev DS CIS LIS CS IP e Porta do Proxy Qual Proxy? registrar Context Device’s location Subscrição Conteúdo da Subscrição: Subject: mac address, Expression: EnergyLevel < 10% and FreeMemory < 15000K Evento de Interesse Requisição do Monitor: Qual endereço do CIS e sua periodicidade? Qual endereço do DS? GetDSAddress? Monitor requisição requisição Server Proxy M Client API resposta FW resposta modificada API Well, in this slide I am going to explain the typical pattern of interactions among the core services and the applications. 2 – Initially, the server and proxy register themselves at the discovery service informing the name, properties and address of the service which they implement, so that the clients can locate them through this service 3 – And the monitor executing on each mobile device collects the network and device’s context information and periodically send them to the context information service. However, the monitor needs to query the configuration service to discover the cis and ds address and the periodicity in which the context information has to be sent. Thereafter, the monitor periodically sends the context information to the CIS. 5 - The DS address received by the monitor is used for the application client to interact with the discovery service. There are some commands available among the monitor and application client. After discovering the desired proxy through the DS the client can start sending requests. 6 – the proxy processes the client’s request and may subscribe itself at the context information service (CIS) as interested in context changes related to the client. In the subscription sent by the proxy there may be an expression of interest to select the event desired. In this example, the proxy is going to be notified only if “EnergyLevel < 10 and Free…” 7 – Applications that require location information register their interest at the LIS, which in turn subscribes to the CIS to receive periodic updates of the device’s RF signals. The LIS uses the signal to inter the device’s location and send the corresponding notification to the application proxy. 8 – After that the proxy forwards the client’s request to the server. In this example the proxy receives a notification about context changes of the client, so the proxy can implement some adaptation on the server’s reply if it is necessary, for example, it could store the server’s reply in a local buffer for a while because the EnergyLevel is below a certain threshold. The adaptation implemented is specific for each application. 9 – Then the proxy sends a modified reply to the client according to its current context. 10 – every moca-based application must use the client and server’s APIs and the proxy framework because they hide from the application developer most details concerning the use of the moca services. temporarily discarded 4 – the context information service receives and processes the network and device’s context information sent by the monitors. It also receives requests for notifications from application proxies. This way, it eventually generates and delivers events to a proxy whenever a change in a device’s state is of interest to this proxy. for example, implementing data compression, among others kind of adaptation that are specifics to each application. If the proxy has been notified that the quality of the wireless link is below a certain limit it could implement some kind of adaptation like store the server’s reply in a local buffer for a while. Moreover, the proxy could use other context information, such as device’s location to determining when and how the data has to be sent to the client. Legenda DS - Discovery Service CIS - Context Information Service (Provedor de contexto e Broker) LIS - Location Inference Service (Consumidor, Provedor de contexto e Broker) CS - Configuration Service M - Monitor (Sensor) Laboratório de Engenharia de Software – PUC-Rio

Cliente e Servidor API Descrição ClientAPI
Facilita programação da aplicação escondendo alguns detalhes referentes a programação de rede e uso da arquitetura MoCA. Inicia automaticamente o monitor, se desejado. ServerAPI Pode ser usada para criar uma aplicação servidor, tal como um novo serviço. Se registra automaticamente no DS. Laboratório de Engenharia de Software – PUC-Rio

Infra-estrutura de Comunicação
API Descrição Communication Protocols (Cm) Implementa protocolos para troca de mensagens síncronas e assíncronas entre objetos Java usando TCP ou UDP. Event Communication Interface (ECI) Implementa comunicação baseada em eventos (Publish/Subscribe). API de propósito geral, usada por alguns serviços MoCA, como LIS. Laboratório de Engenharia de Software – PUC-Rio

Serviços API Descrição Context Information Service (CIS Client)
Implementa interface com CIS para fazer subscrições de expressões de interesse (SQL-like), e receber notificações quando as variáveis de contexto do dispositivo satisfazem uma expressão interesse. Location Inference Service (LIS) Oferece suporte a notificações (assíncronas) e consultas sobre uma localização ou um dispositivo específicos. Symbolic Region Manager (SRM) Armazena informações sobre hierarquias de regiões simbólicas, baseadas no conjunto de regiões atômicas definidas pelo LIS. Discovery Service (DS) Implementa uma interface com DS para armazenas informações, ou fazer consultas sobre qualquer serviço registrado no middleware. Laboratório de Engenharia de Software – PUC-Rio

Dependências entre APIs
Laboratório de Engenharia de Software – PUC-Rio

Aplicação Virtual Lines
Aplicação sensível ao contexto desenvolvida utilizando a arquitetura MoCA que realiza o controle de filas virtuais em parques de diversão; Objetivo: impedir que pessoas passem muito tempo esperando nas filas dos brinquedos e aproveitem melhor as atrações existentes no parque. Ao passar próximo de uma atração um usuário móvel pode coletar um ticket virtual que corresponde a um lugar na fila. O sistema avisa ao usuário sobre a proximidade de sua vez, para que ele retorne a tempo de participar. Quando o usuário não retorna a tempo, o sistema emite um alerta para ele avisando que perdeu sua vez na atração. Laboratório de Engenharia de Software – PUC-Rio

Contexto Excepcional É necessário especificar situações excepcionais para que sejam devidamente consideradas e tratadas. Programador é responsável por especificar tais situações errôneas. São contextos indesejados ou perigosos, associados aos usuários, agentes da aplicação, ou dispositivo móvel. Têm significado especial e requerem ativação de ações de recuperação. Requerem tratamento imediato por parte aplicação na forma de invocação de tratadores. Laboratório de Engenharia de Software – PUC-Rio

Exemplos de contextos excepcionais
<Tempo de espera muito longo> ou <muitas pessoas na fila> aconselhar que novas pessoas não entrem na fila, oferecer outras atrações próximas. Quando dispositivo entra em uma fila pode informar o horário que irá deixar o parque (escalonamento preferencial) e se eu não fizer de acordo com indicado pode receber uma exceção. <Chuva>, algumas pessoas vão desejar sair da fila. Laboratório de Engenharia de Software – PUC-Rio

Tratamento Proativo A colaboração é fundamental para que exista proatividade no tratamento de exceções. Utiliza a infra-estrutura de colaboração entre os dispositivos móveis na presença de contextos excepcionais. Parceiros constroem um corpo de conhecimento sobre as exceções conhecidas. Exceções são dinamicamente “descobertas” com base nos interesses registrados pelos parceiros da colaboração. Proativo: uma exceção desconhecida por um agente pode ser detectada com base nos parceiros na colaboração. Laboratório de Engenharia de Software – PUC-Rio

Localização de Tratadores
Agente ou dispositivo móvel: <Cliente perdeu a vez na fila>, <PDA de um cliente está desligado ou bateria está baixa> Serviço de colaboração: <Chuva>, <Alarme de fogo em uma atração>. Todos os usuários e serviços de um servidor MoCA: <Alarme de fogo no parque>, <Servidor MoCA fora>. Localização (tratador referente uma região)? <Nova atração aberta> ou <alarme de fogo em uma atração>. Laboratório de Engenharia de Software – PUC-Rio

Associação (Binding) de Tratadores
Reconfiguração dinâmica de tratadores de acordo com as informações de contexto. <Cliente perdeu a vez>, possíveis tratamentos: oferecer troca com alguém da fila que deseje, permitir que volte mais tarde se as pessoas na fila concordarem, (Se perdeu porque estava em outra atração) informar ao próximo da fila e deixar que ele use a atração em seguida. Além disso, poderia considerar informações como: “em quantas filas ele já está aguardando sua vez”; “há quanto tempo ele não participa de nenhuma atração”, etc. <Atração temporariamente fora>, possíveis tratamentos: notificar a situação, alocar em fila de outra atração, ou manter na fila. Laboratório de Engenharia de Software – PUC-Rio

Propagação de Exceção Diferentes estratégias:
classificar exceções de acordo com sua gravidade a fim de entender para qual nível ela deve ser propagada. Quando <dispositivo não cumpriu com as restrições ou acordos realizados>, pode receber exceções. <PDA de um cliente com bateria baixa> notificado para os serviços em que ele está colaborando. <Alarme de fogo em uma atração> pode ser propagado para todos os usuários colaborando no serviço. <Alarme de fogo no parque> propagado para todos os usuários e serviços do servidor MoCA do parque. Laboratório de Engenharia de Software – PUC-Rio

Contextos Excepcionais Concorrentes
Suporte a contextos excepcionais concorrentes é um requisito fundamental para aplicações sensíveis ao contexto. É importante que exista: mecanismo de ação atômica entre os participantes de uma colaboração, para recuperação colaborativa do sistema; conceito de resolução de exceções concorrentes. Ocorrência de vários contextos excepcionais: decisão sobre qual é mais relevante para ser tratado. Laboratório de Engenharia de Software – PUC-Rio

Representação de Contextos no MoCA
A representação de contextos excepcionais pode ser similar a representação de contextos normais. Como é representado um contexto no MoCA? CIS Novos serviços definidos para aplicações MoCA LIS Existem algumas diferenças na representação destas informações de contexto para estes serviços! Laboratório de Engenharia de Software – PUC-Rio

Representação de Contexto no CIS
Formato da subscrição de interesse para o CIS: ID do dispositivo (endereço mac) + expressão lógica (representa o contexto de interesse sobre do dispositivo). Exemplos de expressões: "(CPU > 90)“ "((OnLine = False) and (DeltaT > 10000)) Laboratório de Engenharia de Software – PUC-Rio

Comunicação no CIS CIS oferece suporte para: comunicação baseada em eventos (ECI) e comunicação síncrona (communication protocol). Na comunicação síncrona, responde todas as requisições com a última informação de contexto conhecida sobre o dispositivo. não fornece suporte para processamento de expressões. Na comunicação assíncrona, registra os interesses para um dispositivo específico e, sempre que o matching entre a notificação recebida do monitor e a expressão de interesse do cliente é verdadeiro, publica um evento para este cliente. Laboratório de Engenharia de Software – PUC-Rio

Exemplo: Cliente Síncrono CIS
request = new Request(“00:02:2D:A5:06:46”); tcpClient = new TCPConnection(); tcpClient.open(serverAddr); tcpClient.send(request); reply = (Reply) tcpClient.nonBlockingReceive(TIMEOUT); if (reply == null) return; if (reply instanceof ContextInformation) { ctx = (ContextInformation) reply; printOutDeviceContext(ctx); } else // if(reply instanceof ErrorMessage) { errorMsg = (ErrorMessage) reply; printOutErrorMessage(errorMsg); } Laboratório de Engenharia de Software – PUC-Rio

Exemplo: Cliente Assíncrono CIS
cis = new CisSubscriber(protocol,CISAddr,localAddr); ... //Subscribe to subject with a specific expression topic1 = cis.subscribe("00:02:2D:A5:06:47","(CPU > 90)"); //Adding listener for the topic listener1 = new MyEventListener(); cis.addListener(listener1,topic1); class MyEventListener implements EventListener { public void onReceiveData(Event event) { DeviceContext dvcContext = (DeviceContext) event.getData(); DeviceCtxManagement.printOutDeviceContext(dvcContext); } Laboratório de Engenharia de Software – PUC-Rio

Representação de Contextos Excepcionais
Utilização de uma Tag Especial “Exception”: sql = “Exception(EnergyLevel < 30 and FreeMemory < 7500)"; topic = cis.subscribe("00:02:2D:A5:06:45", sql); Aspecto deve interceptar subscrições: Verificar se é uma expressão de contexto excepcional, caso afirmativo, armazenar esta informação internamente; Alterar expressão para retirar a tag “Exception”; Realizar normalmente a subscrição no MoCA com a nova expressão; Aspecto deve interceptar os eventos recebidos: Verificar se o evento é referente a expressão de contexto excepcional; Se for contexto excepcional, chamar o tratador apropriado. Pode-se pensar em uma expressão de contexto excepcional que está associada a um grupo de dispositivos; Laboratório de Engenharia de Software – PUC-Rio

Representação de Contexto no LIS
Formato da subscrição de interesse para o LIS: ID do dispositivo + DeviceListener Nome da região + RegionListener Não existe expressão de interesse. Existem listeners para recebimento de eventos específicos; Laboratório de Engenharia de Software – PUC-Rio

Exemplo: Cliente LIS // connect to lis
lis = new LocationInferenceService(server, 55021, 55020); //subscribe to device listen DeviceListen deviceListen = new DeviceListen(); lis.subscribe(device, deviceListen); //subscribe to region listen Region[] regions = lis.getAtomicRegions(); RegionListen regionListen = new RegionListen(); for (int i = 0; i < regions.length; i++) { // subscribe for each region to receive an event when a device come in or out of it. lis.subscribe(regions[i].getName(), regionListen); } Laboratório de Engenharia de Software – PUC-Rio

Exemplo: Cliente LIS private class DeviceListen implements DeviceListener { public void onRegionChanged(String deviceId, String areaId) { System.out.println(deviceId + "->" + areaId); } private class RegionListen implements RegionListener { public void onDeviceEntered(String regionId, String deviceId) { System.out.println("Device entered: " + regionId + " -> " + deviceId); public void onDeviceExited(String regionId, String deviceId) { System.out.println("Device exited: " + regionId + " -> " + deviceId); Laboratório de Engenharia de Software – PUC-Rio

Referências Bibliográficas
BROWN, P. J. The Stick-e Document: A Framework For Creating Context-aware Applications. In the Proceedings of the Electronic Publishing, pp , Laxenburg, Austria, IFIP. September 1996. CAPRA, L. Reflective Mobile Middleware for Context-Aware Applications. October (Ph.D. Thesis), Department of Computer Science, University College London, London. CAPRA, L.; EMMERICH, W. and MASCOLO, C. Exploiting Reflection and Metadata to build Mobile Computing Middleware. In Proc. of Workshop on Middleware for Mobile Computing. Co-located with Middleware Heidelberg, Germany. November 2001. CAPRA, L; EMMERICH, W. and MASCOLO, C. CARISMA: Context-Aware Reflexive mIddleware System for Mobile Applications. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, Vol. 29, Issue 10, October pp CHAN, A. and CHUANG, S. MobiPADS: a reflective middleware for context-aware mobile computing. IEEE Transactions on Software Engineering, 29(12):1072{1085, Dec 2003. CHO, S. Y. Framework for the Composition and Interoperation of the Home Appliances based on Heterogeneous Middleware in Residential Networks. IEEE Trans. Consumer Electronics. Vol. 48 – Issue 3, pp Laboratório de Engenharia de Software – PUC-Rio

COUTAZ, J. et al. Context is Key. Communications of the ACM, Special Issue on the Disappearing Computer. March 2005, Vol. 48, Issue 3. pp CUGOLA, G.; NITTO, E. and FUGGETTA, A. The JEDI Event-Based Infrastructure and its Applications to the Development of the OPSS WFMS. IEEE Transactions on Software Engineering, 27(9): 827–850, Sept DAVIES, N.; MITCHELL, K.; CHEVERST, K. and BLAIR, G. S. Developing a Context Sensitive Tourist Guide. Proc First Workshop on Human Computer Interaction for Mobile Devices, Glasgow. March 1998. DEY, A.K., and ABOWD, G.D. Towards A Better Understanding of Context and Context-Awareness. In the Workshop on the What, Who, Where, When and How of Context-Awareness. ACM Conference on Human Factors in Computer Systems (CHI 2000), The Hague, Netherlands. April 1-6, 2000. DIX, A., RODDEN, T., DAVIES, N., TREVOR, J., FRIDAY A. and PALFREYMAN, P. Exploiting Space and Location as a Design Framework for Interactive Mobile Systems. ACM Transactions on Computer-Human Interaction (TOCHI) FAHY, P.; CLARKE, S. CASS: Middleware for Mobile Context-Aware Applications. MobiSys 2004 Workshop on Context Awareness, Boston, Massachusetts, USA, June 2004. Laboratório de Engenharia de Software – PUC-Rio

FERBER, J. Multi-Agent Systems: An Introduction to Distributed Artificial Intelligence. Addison Wesley Longman, 1999. GADDAH, A. and KUNZ, T. A Survey of Middleware Paradigms for Mobile Computing. July Carleton University Systems and Computing Engineering Technical Report. Ottawa, Ontario, Canada. GARCIA, A. F. et al. A Comparative Study of Exception Handling Mechanisms for Building Dependable Object-Oriented Software. Journal of Systems and Software, Elsevier, Vol. 59, Issue 2, November 2001, pp GARCIA, A. F.; BEDER, D. M.; RUBIRA, C. An Exception Handling Software Architecture for Developing Fault-Tolerant Software. 5th IEEE High Assurance Systems Engineering Symposium (HASE'2000), Albuquerque, New Mexico, USA, November 2000. GARCIA, A. F.; RUBIRA, C. Exception Handling in Concurrent Object-Oriented Systems. 14th Brazilian Contest on Dissertations and Thesis, CTD'2001, SBC, August Best Dissertation Award (In Portuguese) GARCIA, A. From Objects to Agents: An Aspect-Oriented Approach. Rio de Janeiro, p. Thesis (Doctoral Thesis) - Computer Science Department, Pontifical Catholic University of Rio de Janeiro. Laboratório de Engenharia de Software – PUC-Rio

GARCIA, A., CHOREN, R., LUCENA, C., ROMANOVSKY, A., WEYNS, D., GIESE, H. Software Engineering for Large-Scale Multi-Agent Systems. SELMAS (Post-Workshop Report) ACM Software Engineering Notes, Vol. 30, (To Appear). GARCIA, A; RUBIRA C. Um Mecanismo Orientado a Objetos para Tratamento de Exceções em Software Concorrente Tolerante a Falha. Proceedings of the 8th Brazilian Symposion on Fault-Tolerant Computing, SBC, Campinas, SP, Brazil, June 1999. HOHPE, G. Your Coffee Shop Doesn’t Use Two-Phase Commit. IEEE SOFTWARE, March - April 2005, vol. 22, n. 2, pp HULL, R.; NEAVES, P. and BEDFORD-ROBERTS, J. Towards Situated Computing. In the Proceedings of the 1st International Symposium on Wearable Computers (ISWC'97), pp , Cambridge, MA, IEEE. October 13-14, 1997. ILIASOV, A. & ROMANOVSKY, A. Exception Handling in Coordination-based Mobile Environments. In Proceedings 29th Annual International Computer Software and Applications Conference (COMPSAC), Edinburgh, Scotland, July IEEE CS Press. K¨ONIG-RIES, B. et al. On building an infrastructure for mobile and wireless systems: report on the nsf workshop on an infrastructure for mobile and wireless systems, oct. 15, SIGMOD Rec., 31(2):73–79, 2002. Laboratório de Engenharia de Software – PUC-Rio

KON, F. et al. Monitoring, Security, and Dynamic Configuration with the dynamicTAO Reflective ORB. In Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms and Open Distributed Processing, pages 121–143, New York, April Springer-Verlag. LAC (Laboratory for Advanced Collaboration). MoCA: Mobile Collaboration Arquiteture. URL: LAMMING, M. and FLYNN, M. Forget-me-not: Intimate computing in support of human memory. In the Proceedings of the FRIEND 21: International Symposium on Next Generation Human Interfaces, pp , Meguro Gajoen, Japan LEDOUX, T. OpenCorba: a Reective Open Broker. In Reflection’99, Volume 1616 of LNCS (Saint-Malo, France, July 1999), pp Springer-LEE, P.; ANDERSON, T. Fault Tolerance: Principles and Practice. Springer-Verlag, 2nd edition, Wien, Austria, January 1990. LEMOS, R.; ROMANOVSKY, A. Exception handling in the software lifecycle. International Journal of Computer Systems Science & Engineering, CRL Publishing, Vol. 16, Issue 2, March 2001, p LIPPERT, M.; LOPES, C. V. A Study on Exception Detection and Handling Using Aspect-Oriented Programming. In Proceedings of the 22nd International Conference of Software Engineering (ICSE’2000), Limmerick, Ireland, June 2000, pp Laboratório de Engenharia de Software – PUC-Rio

LYU, M. R.; CHEN, X.; WONG, T. -Y. Design and Evaluation of a Fault-Tolerant Mobile-Agent System. Intelligent Systems, Special Issue on Dependable Agent Systems, Vol. 19, Issue 5, September - October 2004, pp MEIER, R. and CAHILL, V. STEAM: Event-Based Middleware for Wireless Ad Hoc Networks. In Proceedings of the International Workshop on Distributed Event-Based Systems (ICDCS/DEBS'02). Vienna, Austria, 2002. MITCHELL, K. A Survey of Context-Aware Computing. Internal Technical Report, March 2002. MITCHELL, K. Supporting the Development of Mobile Context-Aware Computing. January (Ph.D. Thesis), Computing Department, Lancaster University, England, U.K. MURPHY, A. L.; PICCO, G. P.; ROMAN, G. -C. LIME: A Coordination Middleware Supporting Mobility of Hosts and Agents. Technical Report 2004, Washington University, Department of Computer Science, St. Louis, Missouri. PASCOE, J. Adding Generic Contextual Capabilities to Wearable Computers. In the Proceedings of the 2nd IEEE International Symposium on Wearable Computers (ISWC'98), pp , Pittsburgh, PA, IEEE. October 19-20, 1998. Laboratório de Engenharia de Software – PUC-Rio

PIETZUCH, P. and BACON, J. Hermes: A Distributed Event-Based Middleware Architecture. Submitted to the Workshop on Distributed Event-Based Systems (DEBS), 2002. PROJETO ASPECTJ, Programming Guide. Disponível em: < Acesso em: 15 ago ROMANOVSKY, A.; KIENZLE, J. Action-Oriented Exception Handling in Cooperative and Competitive Concurrent Object-Oriented Systems. ECOOP Workshop 2000: Advances in Exception Handling Techniques. pp. 147–164. RUBINSZTEJN, H. K. et al. Support for Context-Aware Collaboration. In Proceedings of the First International Workshop on Mobility Aware Technologies and Applications (MATA 2004), Florianópolis, Brasil, September 2004. SACRAMENTO, V. et al. MoCA: A Middleware for Developing Collaborative Aplications for Mobile Users. IEEE Distributed Systems Online, Vol.5, Issue 10, October 2004. SANTANGELO, G. et al. AJEFW: Um framework orientado a aspectos para tratamento de exceções. Primeiro Workshop Brasileiro de Desenvolvimento de Software Orientado a Aspectos (WASP'04), Brasília, Brasil, Outubro 2004. SCHILIT, B. N. and THEIMER, M. Disseminating Active Map Information to Mobile Hosts. IEEE Networks, pages 22-32, October 1994. Laboratório de Engenharia de Software – PUC-Rio

SCHILIT, B. N., Adams, N. I. and Want, R., Context-aware Computing Applications. In the Proceedings of the 1st International Workshop on Mobile Computing Systems and Applications, pp , Santa Cruz, CA, IEEE. December 8-9, 1994. SCHMIDT, A., Beigl, M. and Gellersen, H. W. There is More to Context than Location. In Interactive Applications of Mobile Computing, Rostock, Germany, pp , November 1998. SERUGENDO, G. Di Marzo; ROMANOVSKY, A. Using Exception Handling for Fault-Tolerance in Mobile Coordination Based Environments in EHOOS’03: Proceedings of the ECOOP 2003 Workshop on Exception Handling in Object-Oriented Systems. TR Department of Computer Science, University of Minnesota, Minneapolis, MN SOUCHON, F. et al. A proposition for exception handling in multi-agent systems. In Proceedings of SELMAS'03: 2nd International Workshop on Software Engineering for Large-Scale Multi-Agent Systems at ICSE’03, Portland, Oregon, May 2003, pp SOUCHON, F. et al. Improving exception handling in multi-agent systems. In Software engineering for multi-agent systems II, Research issues and practical applications, C. Lucena, A. Garcia, A. Romanovsky, J. Castro and P. Alencar Editors, Springer-Verlag, LNCS 2940, February 2004. Laboratório de Engenharia de Software – PUC-Rio

SOUCHON, F.; DONY, C.; URTADO, C; VAUTTIER, S. Handling exceptions in multi-agent systems: an application to the MADKit plataform. TRIPATHI, A.; MILLER, R. Exception Handling in Agent-Oriented Systems. In Romanovsky, A., Dony, C.,Knudsen, J.L., Tripathi, A., eds.: Advances in Exception Handling Techniques. LNCS (Lecture Notes in Computer Science) 2022, Springer-Verlag (2000). VARSHNEY, U. and VETTER, R. Emerging mobile and wireless networks. Commun. ACM, Vol. 43, Issue 6. pp.73–81, 2000. WEISS, G. (Editor). Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence. The MIT Press, 1999. WOOLDRIDGE, M. An Introduction to Multiagent Systems, John Wiley & Sons, New York 2002. Laboratório de Engenharia de Software – PUC-Rio

Tratamento de Exceções Sensível a Contexto

Apresentações semelhantes

Apresentação em tema: "Tratamento de Exceções Sensível a Contexto"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Tratamento de Exceções Sensível a Contexto

Apresentações semelhantes

Apresentação em tema: "Tratamento de Exceções Sensível a Contexto"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback