Tratamento de Exceções Sensível a Contexto

1. Tratamento de ExceçõesSensível a Contexto Karla Nazaré Ferreira Damasceno karla@inf.puc-rio.br Orientador: Carlos José Pereira de Lucena Co-orientador: Alessandro Fabricio Garcia PUC-Rio, 22 de outubro de 2005

2. 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

3. 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

4. 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

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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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. Tripathi e Miller Laboratório de Engenharia de Software – PUC-Rio

16. 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. Souchon, Dony, Urtado e Vauttier Laboratório de Engenharia de Software – PUC-Rio

17. 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. Iliasov e Romanovsky Laboratório de Engenharia de Software – PUC-Rio

18. 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. Laboratório de Engenharia de Software – PUC-Rio

19. 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

20. Exemplos de Middlewares Laboratório de Engenharia de Software – PUC-Rio

21. 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

22. 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

23. 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

24. 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

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

26. Core Services API FW API Application M Serviços DS CS CIS LIS Proxy Client Server • 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

27. Sub/Ev Requisição do Monitor: Qual endereço do CIS e sua periodicidade? Qual endereço do DS? Qual Proxy? IP e Porta do Proxy Context registrar Device’s location Evento de Interesse registrar Monitor Subscrição GetDSAddress? API FW API requisição requisição Conteúdo da Subscrição: Subject: mac address, Expression: EnergyLevel < 10% and FreeMemory < 15000K resposta resposta modificada M Padrão Típico de Interações DS CS CIS LIS Proxy Client Server • 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

28. Cliente e Servidor Laboratório de Engenharia de Software – PUC-Rio

29. Infra-estrutura de Comunicação Laboratório de Engenharia de Software – PUC-Rio

30. Serviços Laboratório de Engenharia de Software – PUC-Rio

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

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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

47. 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

48. 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

49. Exemplo: Cliente LIS privateclass DeviceListen implements DeviceListener { publicvoidonRegionChanged(String deviceId, String areaId) { System.out.println(deviceId + "->" + areaId); } } privateclass RegionListen implements RegionListener { publicvoidonDeviceEntered(String regionId, String deviceId) { System.out.println("Device entered: " + regionId + " -> " + deviceId); } publicvoidonDeviceExited(String regionId, String deviceId) { System.out.println("Device exited: " + regionId + " -> " + deviceId); } } Laboratório de Engenharia de Software – PUC-Rio

50. 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. 259-272, Laxenburg, Austria, IFIP. September 1996. • CAPRA, L. Reflective Mobile Middleware for Context-Aware Applications. October 2003. (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 2001. 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 2003. pp. 929-945. • 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, 2002. pp. 484-489. Laboratório de Engenharia de Software – PUC-Rio