Universidade Federal de Pernambuco

Centro de Informática

Programa de Pós-graduação em Ciência da

Computação

Tratamento de Falhas de Alto-Nível em

Sistemas Auto-Configuráveis: a

abordagem FAST

João Henrique Correia Pimentel

DISSERTAÇÃO DE MESTRADO

Recife

Março/2010

Universidade Federal de Pernambuco

Centro de Informática

João Henrique Correia Pimentel

Tratamento de Falhas de Alto-Nível em

Sistemas Auto-Configuráveis: a

abordagem FAST

Dissertação apresentada ao Programa de

Pós-graduação em Ciência da Computação do

Centro de Informática da Universidade Federal de

Pernambuco como requisito parcial para obtenção

do grau de Mestre em Ciência da Computação.

Orientador: Prof. Dr. Jaelson Freire Brelaz de Castro

Recife

Março/2010

Pimentel, João Henrique Correia Tratamento de falhas de alto-nível em sistemas auto-configuráveis: a abordagem FAST / João Henrique Correia

Pimentel. - Recife: O Autor, 2010. xiv, 103 folhas : il., fig., tab. Dissertação (mestrado) – Universidade Federal de Pernambuco. CIN. Ciência da Computação, 2010.

Inclui bibliografia e apêndice. 1. Engenharia de software. 2. Projeto de sistemas. I. Título. 005.1 CDD (22. ed.) MEI2010 – 060

i

Agradecimentos

Agradeço aos meus pais, Mário e Lourdinha, pelo carinho e apoio que sempre foi uma

constante na minha vida. Nunca serei capaz de expressar toda a gratidão que tenho por

vocês.

Aos meus irmãos, Ana e Luís, pelo exemplo de dedicação que sempre me deram.

Mesmo com a distância física aumentando com o passar do tempo, nossos corações sempre

estarão unidos.

À minha namorada, Eline Silva, que vem me alimentando com seu afeto e

compreensão, sendo companheira de risos e lágrimas.

A Jaelson Castro, pela competência e dedicação com que sempre orientou seus

trabalhos, sempre buscando o melhor para seus alunos.

Aos colegas do Laboratório de Engenharia de Requisitos - LER, por todo o

aprendizado e apoio recebido.

A todos os atores da rede social apresentada no Apêndice A.

ii

�The greatest failure is the failure to try.�

� WILLIAM A. WARD

iii

Resumo

A auto-con�guração, que é a habilidade de um sistema se reajustar automaticamente,é uma das características essenciais dos sistemas autonômicos. Em um cenário idealtodas as falhas de um sistema deveriam levar a uma recon�guração, a qual forneceriaum outro meio para se chegar ao resultado desejado. Na prática, observa-se que esseprocesso é computacionalmente custoso quando realizado em larga escala, prejudicandoo desempenho do sistema. Este trabalho apresenta uma abordagem para tratamentode falhas a partir de políticas - a abordagem FAST. Esta abordagem constitui-se dade�nição de uma política de tolerância e de uma política de priorização de compensações,dos mecanismos para avaliar essas políticas e de uma ferramenta para ajudar na criação emanutenção dos arquivos de política. A abordagem FAST é integrada a uma arquiteturade auto-con�guração, que identi�ca as falhas em um sistema e seleciona as estratégiasde recon�guração para compensá-las. Demonstramos a aplicação da abordagem FASTatravés da simulação de execução de sistemas auto-con�guráveis, nos quais pode-se verem ação os cinco tipos de regras de�nidos na política. Com esta abordagem é possívelreduzir o impacto de compensações de falhas no desempenho de um sistema propenso afalhas.

Palavras-chave Políticas para falhas, Tolerância a falhas, Priorização de falhas,Arquitetura de auto-con�guração

iv

Abstract

Self-con�guration, the ability of a system to automatically adjust itself, is one of themajor characteristics of autonomic systems. In the ideal world, all system failuresshould be compensated with a recon�guration. However, this processing is costly,reducing the system performance. This work presents the FAST approach for handlingfailures using policies. This approach consists of the de�nition of a tolerance policy anda compensation priority policy, the mechanisms to evaluate those policies and a tool toaid the creation and maintenance of the policy �les. It is integrated with aself-con�guration architecture, which identi�es the failures in a system and selects arecon�guration strategy to compensate the failures. We demonstrate the use of theFAST approach simulating the execution of a self-con�guring system, in which we couldobserve in action the �ve types of rules de�ned by the policy. With our approach weexpect to reduce the performance overhead that happens when a failure-prone systemtry to compensate all its failures.

Keywords Failure policies, Failure tolerance, Failure prioritization,Self-recon�guration architecture

v

Sumário

Lista de Figuras ix

Lista de Tabelas xi

Lista de Listagens xii

Lista de Algoritmos xiii

Lista de Abreviaturas xiv

1 Introdução 1

1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Modelos de Objetivos, Modelos de Contexto e Políticas 6

2.1 Modelos de Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Modelagem de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Políticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Considerações �nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Arquitetura Auto-Con�gurável 18

3.1 Visão lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Editor dos modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

vi

3.3 Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4 Considerações �nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 A abordagem FAST 36

4.1 De�nição da política . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.1 Política de Tolerância . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1.1.1 Regra de Tolerância Tipo 1 (t.context) . . . . . . . . . . . 39

4.1.1.2 Regra de Tolerância Tipo 2 (t.goal) . . . . . . . . . . . . . 41

4.1.1.3 Regra de Tolerância Tipo 3 (t.limit) . . . . . . . . . . . . 41

4.1.2 Política de Prioridades . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.2.1 Regra de Prioridade Tipo 1 (p.priority) . . . . . . . . . . . 43

4.1.2.2 Regra de Prioridade Tipo 2 (p.limit) . . . . . . . . . . . . 44

4.2 Avaliação das regras da política . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3 Relações entre regras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3.1 Regras t.context com a mesma tarefa . . . . . . . . . . . . . . . . . 52

4.3.2 Regras t.goal com a mesma tarefa . . . . . . . . . . . . . . . . . . . 53

4.3.3 Regras t.limit, p.priority ou p.limit com a mesma tarefa . . . . . . . 53

4.3.4 Regras t.context e t.goal com regras t.limit . . . . . . . . . . . . . . 55

4.3.5 Regras de Tolerância com regras de Prioridades . . . . . . . . . . . 56

4.3.6 Regras p.priority com regras p.limit . . . . . . . . . . . . . . . . . . 57

4.3.7 Regras exatamente iguais . . . . . . . . . . . . . . . . . . . . . . . . 57

4.4 Considerações �nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5 Implementação de um avaliador e ferramenta de suporte 60

5.1 Avaliador da política . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.1.1 Policy Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.1.1.1 Expressões regulares . . . . . . . . . . . . . . . . . . . . . 62

vii

5.1.2 Failure Diagnoser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1.3 Prioritize Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2 Policy Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3 Considerações �nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6 Exemplos de aplicação 73

6.1 Aplicação com regras isoladas . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.1.1 Simulação 1 - Aplicação de regra t.context . . . . . . . . . . . . . . 75

6.1.2 Simulação 2 - Aplicação de regra t.goal . . . . . . . . . . . . . . . . 75

6.1.3 Simulação 3 - Aplicação de regra t.limit . . . . . . . . . . . . . . . . 76

6.1.4 Simulação 4 - Aplicação de regra p.priority . . . . . . . . . . . . . . 77

6.1.5 Simulação 5 - Aplicação de regra p.limit . . . . . . . . . . . . . . . 77

6.2 Aplicação de diversas regras de tolerância - Simulação 6 . . . . . . . . . . . 78

6.3 Aplicação de diversas regras de prioridades - Simulação 7 . . . . . . . . . . 79

6.4 Considerações �nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7 Conclusão e Trabalhos Futuros 84

7.1 Revisão do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.2 Sumário dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.3 Principais contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.4 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Referências 90

Apêndice A -- Rede social envolvida na realização deste trabalho 96

viii

. . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Apêndice B -- Listas de eventos das simulações realizadas 98

B.1 Simulação 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

B.2 Simulação 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

B.3 Simulação 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

B.4 Simulação 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

ix

Lista de Figuras

1 Passos da metodologia utilizada . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Elementos da notação Tropos . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Exemplo da notação para decomposição AND de objetivos concretos . . . . 8

4 Exemplo de relação Meio-Fim . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 Exemplo de relação Meio-Fim . . . . . . . . . . . . . . . . . . . . . . . . . 10

6 Exemplo de relação de dependência . . . . . . . . . . . . . . . . . . . . . . 10

7 Exemplo de modelo Tropos com anotações de contexto . . . . . . . . . . . 13

8 Arquitetura genérica para utilização de políticas. Adaptado de Damianou

(2002) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

9 Diagrama de componentes da arquitetura de auto-recon�guração. Extraído

de Dalpiaz et al. (2009a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

10 Exemplo de uma relação Meio-Fim - para que o objetivo seja satisfeito,

apenas uma das tarefas precisa ser executada . . . . . . . . . . . . . . . . . 21

11 Modelo de contextos na ferramenta de edição . . . . . . . . . . . . . . . . . 23

12 Modelo de objetivos na ferramenta de edição . . . . . . . . . . . . . . . . . 24

13 Propriedades da condição de ativação na ferramenta de edição . . . . . . . 25

14 Propriedades do elemento Contextual Goal Dec . . . . . . . . . . . . . . . 27

15 Representação de objetivos na ferramenta (à esquerda) e com a notação de

Tropos (à direita) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

16 Propriedades de uma Dependência . . . . . . . . . . . . . . . . . . . . . . 28

17 Janela inicial do simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

18 Janela do simulador com o modelo carregado . . . . . . . . . . . . . . . . . 30

19 Janela do simulador exibindo a representação do modelo em Prolog . . . . 30

x

20 Janela do editor de simulação . . . . . . . . . . . . . . . . . . . . . . . . . 32

21 Detalhe da janela do editor de simulação, mostrando a criação de um evento 32

22 Janela do simulador com uma simulação carregada . . . . . . . . . . . . . 33

23 Janela do simulador com uma simulação sendo executada . . . . . . . . . . 33

24 Modelo conceitual da política de falhas . . . . . . . . . . . . . . . . . . . . 37

25 Componentes nos quais é feita a avaliação da política. Adaptado de Dalpiaz

et al. (2009a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

26 Diagrama de classes do Policy Editor . . . . . . . . . . . . . . . . . . . . . 66

27 Janela do Simulador da Arquitetura, mostrando como o Policy Editor é

chamado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

28 Janela principal do Policy Editor . . . . . . . . . . . . . . . . . . . . . . . 67

29 Janela para adicionar uma regra do tipo t.context . . . . . . . . . . . . . . 67

30 Janela para adicionar uma regra do tipo t.goal . . . . . . . . . . . . . . . . 68

31 Janela para adicionar uma regra do tipo p.priority . . . . . . . . . . . . . . 69

32 Janela para adicionar uma regra do tipo t.limit . . . . . . . . . . . . . . . 70

33 Janela para adicionar uma regra do tipo p.limit . . . . . . . . . . . . . . . 70

34 Diagrama em blocos da arquitetura de utilização da política de falhas . . . 71

35 Modelo de objetivos para exemplo do sistema BTW . . . . . . . . . . . . . 78

36 Modelo de objetivos para exemplo de paciente com diabetes . . . . . . . . 81

37 Modelo de contexto para exemplo de paciente com diabetes . . . . . . . . . 81

38 Modelo i* da rede social desta dissertação, usando a notação do i* Guide

(GRAU et al., 2008) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

xi

Lista de Tabelas

1 Resumo das abordagens para adicionar informações de contexto a um

modelo de objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Tipos de regras de tolerância . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3 Comparadores lógicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Tipos de regras de prioridades . . . . . . . . . . . . . . . . . . . . . . . . . 43

5 Tabela de conversão para milisegundos . . . . . . . . . . . . . . . . . . . . 44

6 Tabela de conversão de prioridade para um valor númerico . . . . . . . . . 49

7 Registro de falhas da tarefa downloadEmail, para exempli�car interação

entre regras t.context, t.goal e t.limit . . . . . . . . . . . . . . . . . . . . . 56

8 Resumo dos diferentes tipos de regras da Política de Falhas . . . . . . . . . 58

9 Quantidade de compensações de acordo com as regras utilizadas . . . . . . 80

10 Compensações necessárias - sem aplicação da política de tolerância e com

aplicação política de tolerância . . . . . . . . . . . . . . . . . . . . . . . . . 83

xii

Lista de Listagens

1 Exemplos de regras do tipo t.context . . . . . . . . . . . . . . . . . . . . . 41

2 Exemplos de regras do tipo t.goal . . . . . . . . . . . . . . . . . . . . . . . 41

3 Exemplos de regras do tipo t.limit . . . . . . . . . . . . . . . . . . . . . . . 42

4 Exemplos de regras do tipo p.priority . . . . . . . . . . . . . . . . . . . . . 44

5 Exemplos de regras do tipo p.limit . . . . . . . . . . . . . . . . . . . . . . 45

6 Exemplo de regras t.context com o mesmo elemento . . . . . . . . . . . . . 52

7 Exemplo de regras t.goal com o mesmo elemento . . . . . . . . . . . . . . . 53

8 Exemplo de regras t.limit com o mesmo elemento . . . . . . . . . . . . . . 54

9 Exemplo de regras p.priority com o mesmo elemento . . . . . . . . . . . . 54

10 Exemplo de regras p.limit com o mesmo elemento . . . . . . . . . . . . . . 54

11 Exemplo de política com regras do tipo t.context, t.goal e t.limit . . . . . . 55

12 Exemplo de política com regras de Tolerância e de Prioridades . . . . . . . 57

13 Exemplo de política com regras do tipo p.priority e p.limit . . . . . . . . . 57

14 Cenário da aplicação de regras do tipo t.context . . . . . . . . . . . . . . . 75

15 Cenário da aplicação de regras do tipo t.goal . . . . . . . . . . . . . . . . . 76

16 Contexto utilizado na Simulação 1 . . . . . . . . . . . . . . . . . . . . . . . 99

17 Contexto utilizado na Simulação 2 . . . . . . . . . . . . . . . . . . . . . . . 100

18 Contexto utilizado na Simulação 3 . . . . . . . . . . . . . . . . . . . . . . . 101

19 Contexto utilizado na Simulação 6 . . . . . . . . . . . . . . . . . . . . . . . 102

xiii

Lista de Algoritmos

1 EvaluateTolerancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2 EvaluateContext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3 EvaluateGoals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 EvaluatePriorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

xiv

Lista de Abreviaturas

ACPL � Autonomic Computing Policy Language

AHP � Analytic Hierarchy Process

BDI � Belief - Desire - Intention

BTW � By The Way

CIM � Common Information Model

CIM-SPL � Common Information Model Simpli�ed Policy Language

DMTF � Distributed Management Task Force

FAST � Failure handling for Autonomic Systems

MDC � Monitoramento - Diagnóstico - Compensação

NFR � Non-Functional Requirements

PDL � Policy Description Language

RUP � Rational Uni�ed Process

UML � Uni�ed Modeling Language

1

1 Introdução

Neste Capítulo será apresentada a contextualização do trabalho desta dissertação,

com sua motivação e objetivos. A metodologia utilizada também é apresentada, e por

último é descrita a estrutura deste documento.

2

1.1 Motivação

Em um cenário de crescente complexidade dos sistemas informacionais, surgiu o

termo Computação Autonômica, que abrange os sistemas capazes de se manter em

perfeito funcionamento com o mínimo de intervenção humana, em ambientes dinâmicos

(HORN, 2001). Os sistemas autonômicos possuem quatro características fundamentais:

auto-con�guração, auto-recuperação, auto-proteção e auto-otimização (respectivamente,

do inglês self-con�guring, self-healing, self-protection e self-optimizing) (KEPHART;

CHESS, 2003) (MüLLER et al., 2006).

Auto-con�guração é a capacidade do sistema se ajustar automaticamente, seja

devido a mudanças no ambiente ou para dar suporte a auto-recuperação, auto-proteção

e auto-otimização. Por sua vez, a auto-recuperação é o mecanismo que monitora o

sistema na tentativa de evitar falhas e, quando elas acontecerem, providencia o retorno

ao funcionamento normal. A auto-proteção é a característica de se defender contra

ataques externos, sejam eles acidentais ou maliciosos. Por �m, os sistemas

auto-otimizáveis são aqueles que conseguem identi�car oportunidades para melhorar seu

desempenho e atuar nesta direção.

Dessas quatro características, a auto-con�guração é considerada a principal

(SALEHIE; TAHVILDARI, 2005) (PAREKH et al., 2006), justamente por dar suporte às

demais características. Dada essa importância, já existe na literatura acadêmica algumas

propostas de arquiteturas de referência para sistemas auto-con�guráveis (DALPIAZ et al.,

2009a) (ANTHONY et al., 2008) (OUDA et al., 2008) (SUBRAMANIAN; KATZ, 2000).

Nessas arquiteturas, observa-se que existe um grande espaço para evolução no que se

refere ao tratamento de falhas. Todas as falhas são tratadas igualmente, sem nenhuma

�exibilidade. Em particular na arquitetura de Dalpiaz et al. (2009a), estudos

experimentais têm mostrado que, durante a execução prolongada de um sistema, um

número muito grande de falhas tende a acontecer. Por sua vez, o tratamento de todas

essas falhas tende a provocar uma sobrecarga do sistema. Surge daí a necessidade de

abordagens especí�cas para o tratamento de falhas em sistemas auto-con�guráveis.

Assim como a computação autonômica utilizou o sistema nervoso autônomo para

ilustrar seus conceitos, gostaríamos também de utilizar o corpo humano como metáfora

sobre a �exibilidade no tratamento de falhas. Quando pequenas falhas aparecem no

corpo de uma pessoa, como sardas, espinhas, pêlo encravado, entre outros, normalmente

podemos ignorar essas falhas sem que haja prejuízo signi�cativo ao funcionamento

3

normal do corpo. Outras falhas, ligeiramente mais graves, terão um impacto

diferenciado a depender do contexto em que elas acontecem. Por exemplo, uma leve

in�amação da garganta durante as férias costuma ser menos impactante do que a mesma

in�amação momentos antes de uma importante reunião de trabalho. Por último, as

falhas mais críticas - como câncer - demandam uma intervenção forte e imediata, como a

ingestão de remédios com fortes efeitos colaterais e procedimentos cirúrgicos.

Da mesma forma que no corpo humano, as falhas nos sistemas de software apresentam

diferentes impactos (AVIZIENIS et al., 2004) (HILTUNEN et al., 1999) (RINNER; GRAZ, 2002),

e algumas podem até mesmo ser ignoradas (RINNER; GRAZ, 2002). Esta variação de

impacto corrobora a necessidade de se adicionar �exibilidade ao tratamento de falhas nas

arquiteturas auto-con�guráveis, que atualmente consideram todas as falhas como tendo o

mesmo peso.

Um conceito que tem sido utilizado na Engenharia de Software para adicionar

�exibilidade aos sistemas é o conceito de política. As políticas de software permitem que

o usuário ou o administrador do sistema possua o controle sobre certos aspectos de um

sistema, sem que seja preciso lidar com detalhes de implementação (DAMIANOU et al.,

2002). Em particular, esse conceito tem sido muito usado na área de redes (STRASSNER

et al., 2008) (STONE et al., 2003) (PEDIADITAKIS et al., 2009).

Neste trabalho, os conceitos de políticas serão utilizados para permitir a de�nição

em alto-nível de alguns aspectos do tratamento das falhas de elementos em um sistema

auto-con�gurável.

1.2 Objetivo

O objetivo desta dissertação é de�nir mecanismos para a utilização de políticas no

tratamento de falhas em um sistema auto-con�gurável. Em particular, focamos em

sistemas constuídos com a arquitetura de Dalpiaz et al. (2009a). Este objetivo pode ser

re�nado nos seguintes objetivos especí�cos:

Especi�cação das políticas � De�nir quais os tipos de políticas que serão tratados e

as estruturas das regras dessas políticas;

De�nição da avaliação das políticas � De�nir como se dará a avaliação das regras

das políticas, incluindo-se suas inter-relações e a resolução de con�itos;

4

Implementação de um avaliador das políticas � Realizar a codi�cação de um

programa que realize o processamento das regras das políticas;

Implementação de uma ferramenta de apoio � Desenvolver um aplicativo que

permita a criação e a manutenção de políticas, evitando que o usuário precise

escrever as regras da política manualmente.

Atingindo estes objetivos, esperamos que o presente trabalho contribua

signi�cativamente para o aperfeiçoamento da arquitetura utilizada, e dessa forma evoluir

o estado-da-arte em sistemas auto-con�guráveis.

1.3 Metodologia

Esta pesquisa foi realizada utilizando-se o método de engenharia. Segundo Travassos

et al. (2002), este método tem por base a observação de soluções existentes. A partir

dessa observação são identi�cados os problemas das soluções já existentes, sendo então

proposta uma nova solução visando resolver esses problemas.

A Figura 1 ilustra os passos seguidos neste trabalho. Inicialmente, foram estudadas

as características dos sistemas autonômicos (HORN, 2001) (KEPHART; CHESS, 2003)

(MüLLER et al., 2006) (STERRITT, 2005). Em seguida, focamos na principal característica

dos sistemas autonômicos, que é a auto-con�guração (SALEHIE; TAHVILDARI, 2005)

(PAREKH et al., 2006). Analisando as arquiteturas de referência para sistemas

auto-con�guráveis (DALPIAZ et al., 2009a) (ANTHONY et al., 2008) (OUDA et al., 2008)

(SUBRAMANIAN; KATZ, 2000), detectamos que o tratamento de falhas nessas

arquiteturas é muito pobre, no sentido de não apresentar nenhuma �exibilidade.

Optamos então por focar nossos esforços na melhoria deste aspecto na arquitetura de

Dalpiaz et al. (2009a). Esta arquitetura foi escolhida, principalmente, por ser a

arquitetura que monitora falhas no nível que consideramos mais apropriado: requisitos.

A�nal, são os requisitos que descrevem o que se espera de um sistema.

Revisão

bibliográfica

Análise das

arquiteturas de

referência

Revisão

bibliográfica

Definição da

abordagem

FAST

Avaliação da

abordagem

Figura 1: Passos da metodologia utilizada

Analisando a literatura sobre tolerância a falhas (RANDELL, 1975) (CHETAN;

CAMPBELL, 2004) (ZHANG; JIANG, 2008), identi�camos que o uso de políticas seria a

5

forma mais adequada para realizar o tratamento de falhas que consideramos ideal.

Fundamentando-se nos conceitos de modelagem de objetivos, representação de contexto

e políticas aplicadas a sistemas de software, conforme será explicado nos capítulos

seguintes, desenvolvemos a abordagem FAST - Failure handling for Autonomic Systems.

Esta abordagem é composta por uma política de tratamento de falhas e por mecanismos

para a avaliação e aplicação da política.

Visando avaliar a abordagem FAST, realizamos uma prova de conceito implementando

os mecanismos necessários para utilização da política e aplicando a política em sistemas

simulados.

1.4 Estrutura do documento

Este trabalho está dividido em sete capítulos. Neste primeiro Capítulo é feita uma

introdução sobre o trabalho, descrevendo seu contexto, seus objetivos e a metodologia

utilizada.

No Capítulo 2 são apresentados os principais conceitos utilizados no decorrer desta

dissertação, a partir de uma revisão bibliográ�ca sobre modelagem de objetivos,

modelagem de contexto e políticas de software.

O Capítulo 3 é dedicado a apresentar a arquitetura utilizada como base deste trabalho,

a qual foi incrementada com os mecanismos para tratamento de políticas.

O Capítulo 4 de�ne a abordagem FAST, especi�cando a política de falhas e os

algoritmos utilizados para a avaliação desta política.

O Capítulo 5 apresenta a implementação de um avaliador das políticas, integrado ao

simulador da arquitetura, bem como de uma ferramenta de apoio à criação e manutenção

de políticas.

No Capítulo 6 a utilização das políticas é exempli�cada e discutida, mostrando sua

aplicabilidade.

Por último, o Capítulo 7 apresenta considerações sobre o trabalho realizado e indica

possíveis trabalhos futuros.

6

2 Modelos de Objetivos, Modelos de

Contexto e Políticas

Neste Capítulo serão apresentados os principais conceitos nos quais este trabalho se

baseia. Os modelos de objetivos são utilizados para representar os requisitos dos sistemas,

enquanto as informações de contexto adicionam mais detalhes do domínio ao modelo. Por

último, será apresentada uma revisão bibliográ�ca sobre políticas e sua utilização.

7

2.1 Modelos de Objetivos

Nesta Seção serão apresentados os conceitos básicos dos modelos de objetivos, que

representam os requisitos dos sistemas na arquitetura utilizada (DALPIAZ et al., 2009a).

O entendimento deste tipo de modelo é importante para a compreensão das políticas

de�nidas neste trabalho, uma vez que os elementos desses modelos são utilizados nas

regras das políticas e também no monitoramento das falhas.

Uma questão central na Engenharia de Requisitos é �Por quê um dado software é

necessário?� � uma questão que permite identi�car os objetivos daquele sistema

(LAMSWEERDE, 2001). As representações usuais de requisitos, como requisitos textuais

e casos de uso, descrevem o software em um nível de abstração muito baixo, deixando

uma lacuna entre os objetivos daquele software - por quê ele é desenvolvido - e sua

especi�cação - o que ele faz. Modelos de objetivos podem preencher essa lacuna,

representando não só os objetivos propriamente ditos, como também seus re�namentos e

formas para os realizar.

Em um modelo de objetivos cada funcionalidade do sistema está relacionada a um

objetivo, que justi�ca a existência daquela funcionalidade. Também é possível visualizar

quais são as diferentes formas de se satisfazer os objetivos, permitindo que as alternativas

sejam escolhidas de acordo com o impacto das mesmas nos objetivos do sistema. Essa

escolha pode ser feita em tempo de projeto, pelo engenheiro de requisitos, ou em tempo

de execução, se o software for su�cientemente instrumentado para tal.

Existem diferentes abordagens para Engenharia de Requisitos utilizando modelos de

objetivos, como Kaos (DARDENNE et al., 1991), i* (YU, 1995) e Tropos (CASTRO et al.,

2002). Nesta Seção descreveremos apenas uma variação do Tropos, tal qual usado na

arquitetura de auto-con�guração (DALPIAZ et al., 2009a). Entretanto, os conceitos básicos

de objetivos e de re�namento de objetivos são comuns às demais abordagens.

A Figura 2 mostra os elementos da notação Tropos. Os objetivos são classi�cados

como objetivos concretos (hard goals) e objetivos abstratos (soft goals). Objetivos

concretos são objetivos para os quais existe um critério de satisfação objetivo e preciso,

como �fornecer gerenciamento de orçamento� ou �Vender livros�. Livros são vendidos ou

não, e gerenciamento de orçamento é fornecido ou não.

Por outro lado, a satisfação de objetivos abstratos passa por uma avaliação

subjetiva. Seu critério de satisfação não é preciso, possuindo diferentes níveis de

satisfação. Exemplos de objetivos abstratos são �Baixo custo do produto� e

8

Objetivo concreto Tarefa Fronteira do Ator

Objetivo Abstrato

(a) (b) (c)(d)

Ator

Figura 2: Elementos da notação Tropos

�Disponibilidade de serviço�. Não há um único preço do produto que satisfaça o primeiro

objetivo, da mesma forma que não há uma única medida de disponibilidade que satisfaça

o último objetivo - eles podem ser plenamente satisfeitos, parcialmente satisfeitos, e

assim por diante. De fato, é difícil saber se um objetivo abstrato está realmente

satisfeito. Contudo, podemos analisar se os objetivos abstratos estão su�cientemente

satisfeitos - normalmente nós queremos maximizar ou minimizar essa satisfação.

Sendo assim, o fato de um objetivo ser abstrato (soft goal) não o torna menos

importante que um objetivo concreto (hard goal). Normalmente os objetivos abstratos

são utilizados para representar requisitos de qualidade (ou não-funcionais), enquanto os

objetivos concretos representam requisitos funcionais.

Os objetivos concretos são representados por um retângulo arredondado (Figura 2a).

Um objetivo concreto pode ser decomposto em outro objetivo concreto. A decomposição

é representada por uma reta cortada por uma pequena linha transversal, que indica a

origem da decomposição. As decomposições podem ser tanto do tipo AND (e) como do

tipo OR (ou). Na Figura 3, o objetivo Mostrar Informações é decomposto no objetivo

Mostrar Mapa e no objetivo Mostrar Advices. Ou seja, o objetivo Mostrar Informações

é satisfeito se e somente se ambos os objetivos Mostrar Mapa e Mostrar Advices são

satisfeitos.

Mostrar Mapa

Mostrar Informações

Mostrar Advices

and

Figura 3: Exemplo da notação para decomposição AND de objetivos concretos

Os objetivos abstratos são representados por uma �gura em forma de nuvem (Figura

2b), similar à notação adotada no NFR Framework (CHUNG et al., 1999), representando

a característica subjetiva do objetivo abstrato. Assim como um objetivo concreto, o

9

objetivo abstrato pode sofrer decomposição do tipo AND e do tipo OR.

A decomposição de objetivos ajuda a descrever um objetivo. Existem outros 3 tipos

de relações em um modelo de objetivos do Tropos, que ajudam a compreender como

um objetivo pode ser satisfeito: relações de Meio-Fim (Means-End), de Contribuição

(Contribution) e de Dependência (Dependency).

A relação de Meio-Fim indica que uma tarefa é um possível Meio para se atingir

um certo Fim (objetivo concreto). Essa relação é representada gra�camente por uma

seta apontando do Meio para o Fim. A ponta da seta é um triângulo preenchido, como

ilustrado na Figura 4.

Objetivo concreto A (fim)

Tarefa B (meio) Tarefa C (meio)

Figura 4: Exemplo de relação Meio-Fim

Uma tarefa, que também pode ser chamada de plano, é alguma atividade passível

de ser realizada - seja por um sistema, uma pessoa ou qualquer outro tipo de ator. No

diagrama, uma tarefa é representada por um hexágono (Figura 2c). Exemplos de tarefas

são �Enviar livro por correio eletrônico� e �Exibir relatório�. Na Figura 4, a Tarefa B é um

possível meio para satisfazer o Objetivo A, e a Tarefa C é um outro possível meio para

satisfazer o Objetivo A. Isto é, se desejamos satisfazer o Objetivo A, podemos realizar a

Tarefa B ou a Tarefa C, não sendo necessário realizar ambas.

Relações de contribuição expressam o impacto da realização de uma tarefa em um

objetivo abstrato. Esse impacto pode ser positivo ou negativo, e possui um valor numérico

associado. A representação grá�ca da relação de contribuição é uma seta curva da tarefa

para o objetivo abstrato. A ponta desta seta é um triângulo preenchido, e seu rótulo é

o valor da contribuição. No exemplo da Figura 5, a Tarefa B prejudica a satisfação do

Objetivo abstrato A (contribuição negativa), enquanto a Tarefa C facilita a satisfação

desse objetivo (contribuição positiva). Por sua vez, a contribuição da Tarefa D é maior

que a contribuição da Tarefa C. A utilização de um valor numérico para indicar a força

da contribuição é particularmente diferente da notação usual de Tropos, que usa rótulos

prede�nidos para indicar essa força (GIORGINI et al., 2005).

Um ator é qualquer unidade, de um sistema, que possua intenções. Eventualmente

10

Tarefa B Tarefa C

Objetivo abstrato A

-2 3

Tarefa D

7

Figura 5: Exemplo de relação Meio-Fim

um ator pode não ser capaz de atingir um objetivo por conta própria. Nessas situações um

ator (o depender) depende de um outro ator (o dependee) para alguma coisa (o dependum).

Uma dependência liga um elemento do depender a um elemento do dependee, passando

pelo dependum. Esses elementos podem ser um objetivo concreto ou uma tarefa.

A relação de dependência é representada por uma linha que se origina no elemento do

depender e vai até o dependum, e outra linha que sai do dependum e vai até o elemento do

dependee, com uma seta no meio de cada linha para indicar a direção da dependência. Um

ator é representado por um círculo, e sua fronteira é representada por um círculo maior,

de borda tracejada (Figura 2d). Cada elemento (objetivo ou tarefa) deve estar dentro da

fronteira de um ator, à exceção do dependum. Dessa forma é possível saber qual o ator

que deseja atingir um dado objetivo, e qual o ator que realizará uma dada tarefa.

Na Figura 6 temos uma dependência do Ator A para o Ator B. A satisfação do Objetivo

A depende da satisfação do Objetivo C, o que pode ser conseguido com a satisfação do

Objetivo B. Nesse caso, dizemos que o Ator A depende do Ator B.

Ator A

Objetivo concreto A

Ator B

Objetivo concreto B

Objetivo concreto C

Figura 6: Exemplo de relação de dependência

Um conceito comum a várias notações para modelagem de objetivos, mas que não é

utilizado nesta versão do Tropos adotada, é o conceito de recurso. Um recurso é uma

entidade da qual um ator precisa, seja ela uma entidade física ou informacional.

11

No decorrer deste trabalho iremos nos referir a objetivos concretos (hard goals)

simplesmente como objetivos, enquanto os objetivos abstratos serão chamados de

softgoals.

Os modelos de objetivos são utilizados neste trabalho para especi�car os requisitos

dos sistemas nos quais serão aplicados a política de falhas. Sem esses modelos não

teríamos como de�nir a política de falhas para um sistema, pois é a partir do modelo

que identi�camos as tarefas cujas falhas serão tratadas. Também é a partir desse modelo

que observamos os objetivos relacionados a essas tarefas. No entanto, o modelo de

objetivos por si só não é su�ciente para representar toda a riqueza de informações

presente no domínio. Por esse motivo iremos usar modelos de objetivos enriquecidos

com anotações de contexto, conforme será apresentado na próxima Seção.

2.2 Modelagem de contexto

O crescente poder de processamento dos dispositivos móveis despertou um grande

interesse no desenvolvimento de softwares que se adaptassem ao contexto em que

estivessem inseridos (HENRICKSEN; INDULSKA, 2004). Algumas das variáveis que fazem

parte do contexto são localização, data, hora e recursos de hardware disponíveis.

Os modelos de objetivos não são su�cientes para expressar as informações de

domínio que in�uenciam na satisfação dos objetivos e na realização das tarefas. Existem

várias abordagens para se enriquecer modelos de objetivos com informações de

contextualização. Entre elas destacamos quatro trabalhos: Souza e Mylopoulos (2009),

Dalpiaz et al. (2009a), Ali et al. (2009) e Lapouchnian e Mylopoulos (2009). Essas

abordagens estão resumidas na Tabela 1.

A idéia básica dessas abordagens é modelar o contexto, com suas diversas variáveis,

e inserir anotações no modelo de objetivos, relacionando este modelo com aquele. Dessa

forma, certos elementos ou relações de um modelo de objetivos só serão válidos quando

um dado contexto for verdadeiro.

Nesta dissertação, em virtude da arquitetura de referência que adotamos, iremos

modelar o contexto conforme Dalpiaz et al. (2009a). Esta abordagem possui todos os

conceitos necessários para a auto-con�guração do sistema, e é su�ciente para a criação

das regras de política relacionadas ao contexto.

Na abordagem de Dalpiaz et al. (2009a), as entidades de contexto são representadas

12

Tabela 1: Resumo das abordagens para adicionar informações de contexto a um modelode objetivosAbordagem Objetivo de se

utilizar contextoEstrutura Elementos

anotadosSouza eMylopoulos(2009)

Monitorar se um dadoelemento acionadopode ser acionadodado o contexto

Hierarquiade dimensõesde contexto:sub-dimensõese fórmulasproposicionais(folhas)

Objetivos, softgoals,tarefas e relações decontribuição

Dalpiaz et al.(2009a)

De�nir quaisalternativas devem,podem e não podemser realizadas

Diagrama deobjetos

Decomposições,Relação de Meio-Fim

Ali et al. (2009) De�nir qualalternativa deveser escolhida em ummodelo de objetivose em um modelode realização deobjetivo (diagrama deatividade)

Hierarquia:sentençase fatos;Parametrização

Decomposições,Relações deDependência,Objetivos, Tarefas,Relações de Meio-Fim e relações decontribuição

Lapouchniane Mylopoulos(2009)

Modelar variabilidadedo domínio

Dimensões docontexto ehierarquia depossíveis valores;Herança

Decomposições,objetivos, softgoalse relações decontribuição

como objetos. �Contato�, �Sala� e �Internet� são exemplos de entidades de contexto.

Por sua vez, as características de uma entidade são representadas como atributos do

objeto. Como exemplo, um contato tem um nome, um cargo, uma data de nascimento,

um telefone, uma agenda, entre outros; uma sala pode ter cadeiras, ar-condicionado,

projetor, computadores, etc.

O contexto propriamente dito é uma expressão que associa um valor a alguma

característica de uma entidade. Por exemplo, podemos ter uma expressão dizendo �Data

de nascimento do contato maior que 1 de janeiro de 1992�, ou �Ar-condicionado da sala

igual a ligado�. O contexto é relacionado ao modelo de objetivos através de anotações

nas relações de decomposição ou nas relações de Meio-Fim do modelo de objetivos.

No exemplo da Figura 7 temos um Sistema de Escritório Eletrônico, que possui dois

objetivos: fornecer notícias (G1) e auxiliar o usuário a realizar seu trabalho (G2). O

sistema pode fornecer notícias aos usuários de três formas: fazendo o download dos seus

13

G1: Fornecer Notícias G2: Auxiliar Trabalho

DownloadEmails

Sistema de

Escritório Eletrônico

Fornecer modelo de relatório

DownloadFeeds

DownloadTweets

CONTEXTOS:

C1: Contato.agenda = disponível

Eventos de ativação

G1: Hora.minutos = 0

G2: Hora.hora = 8

Objetivo

Tarefa

Ator

Fronteira do ator

Relação meio-fim

Legenda

Agendar reunião automaticamente

C1

Figura 7: Exemplo de modelo Tropos com anotações de contexto

e-mails, dos seus feeds de notícias ou dos seus tweets. Já para auxiliar o trabalho (G2),

ele pode fornecer um modelo de relatório ou agendar uma reunião automaticamente. a

anotação de contexto C1 impõe uma restrição sobre a escolha das alternativas para G2:

a tarefa �Agendar reunião automaticamente� só poderá ser realizada quando a agenda do

contato (que irá participar da reunião) estiver disponível.

Além do contexto propriamente dito, a abordagem de Dalpiaz et al. (2009a) também

tem o conceito de Evento de Ativação, que é expresso da mesma forma que o contexto.

Esta abordagem assume que os objetivos de um ator não são constantes - isto é, que eles

só são ativos em certas situações, que são os eventos de ativação. No exemplo da Figura

7, a caixa de texto que lista os eventos de ativação indica que o objetivo G1 (fornecer

notícias) só passa a ser um objetivo do sistema quando os minutos da hora forem iguais

a 0 - ou seja, a cada passar de hora. Já o objetivo G2 é ativado no início do expediente,

às 8 horas.

Um ponto fraco desta abordagem, que também não é tratado pelas demais abordagens,

14

se refere à tipagem - especi�cação dos tipos de valores que o atributo poderá apresentar -

e ao sistema de unidades dos atributos das entidades de contexto. Como essas abordagens

não de�nem o tipo nem o sistema de unidades dos atributos, é preciso levar em conta esta

de�ciência durante a fase de projeto de um sistema, tomando-se os devidos cuidados para

que todos os componentes do sistema utilizem a mesma referência.

Independente dessa de�ciência, a modelagem de contexto é relevante para este

trabalho por permitir identi�car e expressar situações nas quais certas falhas podem ser

toleradas, conforme será apresentado no Capítulo 4. Um outro conceito relevante para

este trabalho é o de políticas, cuja revisão bibliográ�ca é apresentada na Seção a seguir.

2.3 Políticas

O suporte a políticas é reconhecidamente uma forma de se aumentar a �exibilidade de

um sistema, permitindo um controle de alto nível sobre algumas características do mesmo

(DAMIANOU et al., 2002) (FIDALGO et al., 2009) (BANDARA et al., 2004).

Uma política pode ser vista como uma agregação de regras de política (STONE et al.,

2003), que são formadas por um conjunto de condições e por um correspondente conjunto

de ações (STONE et al., 2003) (OUDA et al., 2008). Quando as condições forem satisfeitas,

as respectivas ações serão executadas.

Uma de�nição mais ampla é a que vê uma política como qualquer tipo de orientação

formal para um comportamento - isto é, as políticas são uma forma de orientar a

tomada de decisão sobre as ações a serem executadas (KEPHART; WALSH, 2004)

(SEEHUSEN; STØLEN, 2008) (GUPTA, 2005). Essas políticas são classi�cadas de acordo

com seu nível de abstração (KEPHART; WALSH, 2004) (STRASSNER; KEPHART, 2006) em:

Políticas de ação � Indicam que uma certa ação deve ser efetuada sempre que o sistema

estiver em um determinado estado. Normalmente são da forma IF condição THEN

ação. Exemplo: se o desempenho do sistema estiver superior a 80 porcento de sua

capacidade, alocar mais servidores.

Políticas de objetivo � Em vez de de�nir o que fazer em um dado estado, de�ne qual

o estado desejado - o objetivo. O sistema então deverá escolher quais ações efetuar

para chegar ao estado desejado. Exemplo: manter o desempenho do sistema abaixo

de 80 porcento de sua capacidade.

Políticas de Função de Utilidade � Uma função de utilidade é de�nida e usada para

15

calcular um valor numérico para cada possível estado do sistema. O sistema então

irá executar as ações necessárias para se chegar ao estado que apresente o melhor

valor, de acordo com essa função. Usualmente, a função é de�nida de forma que

quanto maior o valor de um estado, melhor o estado. Como exemplo, poderíamos

de�nir uma função que atinja um valor máximo quando a sobrecarga do sistema for

mínima e a quantidade de transações de negócio for máxima.

A de�nição das funções de utilidade, à exceção de alguns domínios em especí�co, ainda

é uma questão de pesquisa em aberto, apesar dos esforços da academia (DEGRANDIS;

VALETTO, 2009) (WALSH et al., 2004). Isto acontece devido à di�culdade de se atribuir

funções precisas a características subjetivas. Já as políticas de objetivo não são relevantes

no nosso contexto, pois essa informação já está presente no modelo de objetivos. O que

queremos tratar é justamente o que acontece quando não é possível alcançar o objetivo.

Por esse motivo, nós nos baseamos nas políticas de ação para de�nir a política deste

trabalho. Dessa forma, iremos de�nir no Capítulo 4 políticas que expressam o que será

feito - qual falha será ignorada - em uma dada condição.

Em Maullo e Calo (1993), a priorização é citada como um possível uso de políticas,

tratando-se da resolução de con�itos entre processos paralelos. Nesse contexto, os

processos menos prioritários receberiam menos recursos ou teriam sua execução adiada.

Por ser, mesmo que indiretamente, uma forma de interação do usuário com o

sistema, é crescente a preocupação com a forma que as políticas são vistas durante o

desenvolvimento de software - quanto mais cedo no ciclo de vida do desenvolvimento as

políticas forem levadas em consideração, melhor (KAVIANI et al., 2008). Como exemplo,

na política de�nida neste trabalho, as entidades de contexto de�nidas no modelo do

sistema irão in�uenciar a riqueza das regras que poderão ser criadas (vide Seção 4.1.1.1).

Existe uma série de linguagens para de�nição de políticas no domínio de redes de

computadores. A linguagem CIM-SPL (CIM Simpli�ed Policy Language) (DMTF, 2007)

(AGRAWAL et al., 2007) é um padrão proposto pela DMTF (Distributed Management

Task Force) (DMTF, 2010) para especi�car políticas nesse domínio. Mais

especi�camente, as políticas dessa linguagem são de�nidas a partir das 1375 classes de

recursos computacionais de�nidas no CIM (Common Information Model) (DMTF, 2009).

Uma outra linguagem para de�nição de políticas é a Rei (KAGAL et al., 2003), baseada

na lógica deôntica (que trata obrigações e permissões) (MEYER; WIERINGA, 1994). Essa

política é formada por objetos da política (representam direitos, obrigações, proibições e

dispensas), meta-políticas (de�nem prioridades entre as políticas) e atos de discurso

16

(permitem a modi�cação dinâmica das políticas). Existem outras linguagens para

políticas, como a Ponder (DAMIANOU et al., 2001), a Autonomic Computing Policy

Language (ACPL) (SCARLETT, 2006) e a Policy Description Language (PDL) (LOBO et

al., 1999). Estas políticas, além de serem voltadas para um domínio especí�co, são muito

mais custosas e complexas do que o necessário para de�nir a política deste trabalho, por

isso elas não foram utilizadas.

Um outro domínio no qual já existe um grande esforço no desenvolvimento de políticas

é o de manutenção de sistemas deterioráveis. A idéia por trás dessas políticas é de�nir

quando os componentes de um sistema devem sofrer manutenção, basicamente de acordo

com a idade, com a taxa de falhas (WANG, 2002) ou com o grau de obsolescência do

componente (CLAVAREAU; LABEAU, 2009). Como exemplo, uma política do segundo tipo

poderia dizer que o componente X deverá sofrer manutenção, ou ser substituído, quando

sua taxa de falhas atingir o limite Y. No entanto, essas políticas não informam se, antes

de atingir o limite estabelecido, as falhas serão completamente ignoradas ou se sofrerão

alguma compensação. Esta informação é fornecida pelas nossas políticas de tolerância

(vide Seção 4.1.1).

Um sistema que utilize políticas precisa ter uma especi�cação da política, uma

arquitetura para o gerenciamento da política e ferramental de apoio (DAMIANOU, 2002).

Esta dissertação compreende essas três partes, nos capítulos quatro (especi�cação) e

cinco (arquitetura e ferramental).

Figura 8: Arquitetura genérica para utilização de políticas. Adaptado de Damianou(2002)

A Figura 8 mostra uma arquitetura genérica para a utilização de políticas (DAMIANOU,

2002). A Ferramenta de Gerenciamento é o software utilizado para criar e editar as

políticas. Essa ferramenta recupera e armazena as políticas no Repositório de Políticas.

17

Durante a execução do sistema, haverá um ou mais Pontos de Decisão, que é o momento

onde se recupera as políticas do repositório e se avalia as regras da política. As decisões

resultantes da avaliação da política são repassadas para um ou mais Pontos de Aplicação,

que irão executar essas decisões.

Em resumo, nesta dissertação utilizaremos como base as políticas de ação, por se

mostrarem as mais adequadas ao nosso objetivo. Para escrever as políticas, utilizaremos

uma linguagem própria, visto que as linguagens existentes não possuem a �exibilidade

necessária. Já a nossa arquitetura para utilização de políticas será de�nida tendo como

base a arquitetura de Damianou (2002) (vide Capítulo 5).

2.4 Considerações �nais

Iniciamos este capítulo apresentando os conceitos básicos de um modelo de objetivos,

com ênfase na notação Tropos (CASTRO et al., 2002). Existem diferentes versões do Tropos,

como as versões utilizadas em Giorgini et al. (2005), Morandini et al. (2008), Silva (2008)

e Dalpiaz et al. (2009a). Nesta dissertação utilizaremos a versão do Tropos utilizada pela

arquitetura de referência (DALPIAZ et al., 2009a), por se mostrar satisfatória para o nosso

trabalho e não demandar nenhuma adaptação do ferramental existente.

Em seguida foram apresentadas abordagens para adicionar informações de contexto

ao modelo de objetivos. De forma similar, existem diferentes abordagens para se fazer

isto, como as de Souza e Mylopoulos (2009), Dalpiaz et al. (2009a), Ali et al. (2009) e

Lapouchnian e Mylopoulos (2009). Escolhemos utilizar a abordagem já utilizada pela

arquitetura de referência (DALPIAZ et al., 2009a), que se mostrou adequada para este

trabalho.

Por último, foi apresentada uma revisão bibliográ�ca sobre políticas, mostrando como

os conceitos já existentes serão utilizados no decorrer desta dissertação. Em particular,

notou-se a necessidade da especi�cação de uma linguagem própria para a de�nição da

nossa política.

No próximo Capítulo iremos apresentar a arquitetura de referência deste trabalho e

seu ferramental. Pretendemos discorrer sobre o ciclo de Monitoramento - Diagnóstico

- Compensação (MDC) da arquitetura, esclarecer em maiores detalhes como é feita a

modelagem de um sistema neste contexto e mostrar o funcionamento do software utilizado

para simular a execução de um sistema desenvolvido com esta arquitetura.

18

3 Arquitetura Auto-Con�gurável

Neste Capítulo será apresentada uma visão geral da arquitetura utilizada neste

projeto e suas ferramentas de apoio. Ao apresentar o editor de modelos e o simulador,

apresentamos também maiores detalhes sobre os modelos utilizados nesta arquitetura.

19

De acordo com o Rational Uni�ed Process (RUP), uma arquitetura de referência é um

�conjunto de padrões arquiteturais instanciados, projetados e provados para uso em um

contexto especí�co, técnico ou de negócios, junto com artefatos de apoio para viabilizar seu

uso� (KRUCHTEN, 2000). Algumas das arquiteturas de referência existentes para sistemas

auto-con�guráveis são as propostas por Dalpiaz et al. (2009a), Anthony et al. (2008),

Ouda et al. (2008) e Subramanian e Katz (2000). Cada uma dessas arquiteturas possui

suas características e peculiaridades. Conforme mencionado no Capítulo 1, escolhemos

utilizar como referência a arquitetura de Dalpiaz et al. (2009a). Esta escolha se deve aos

seguintes fatores:

Monitoramento de alto-nível � Esta arquitetura monitora o sistema a partir do seu

modelo de requisitos, enquanto as demais arquiteturas realizam o monitoramento

com um baixo nível de abstração.

Sistemas sócio-técnicos � Esta arquitetura não se aplica apenas a sistemas técnicos

(software e hardware), abrangendo também elementos da sociedade, como

indivíduos, empresas, leis, governos, entre outros.

Solidez da pesquisa � Esta arquitetura tem como base trabalhos de reconhecido valor

acadêmico, como a Engenharia de Requisitos Orientada a Objetivos e o paradigma

BDI (sigla em inglês para Crença - Desejo - Intenção).

Ferramental de apoio � O ferramental fornecido para esta arquitetura, apesar de ainda

não ser completo, é su�ciente para a elaboração deste trabalho.

Cooperação internacional � Este trabalho faz parte de um projeto de cooperação com

a University of Trento (TRENTO, 2009), instituição da qual se originou a arquitetura

escolhida.

Esta arquitetura é uma evolução da arquitetura Talos (DALPIAZ et al., 2008b). O

principal trabalho sobre esta arquitetura é Dalpiaz et al. (2009a), no entanto outros artigos

fornecem informações complementares (DALPIAZ et al., 2009b) (DALPIAZ et al., 2008a).

Como trabalho em andamento, certos detalhes e mudanças ainda não foram apresentados

em conferências cientí�cas, sendo obtidos através de contato direto com o autor.

No decorrer deste Capítulo, iremos descrever esta arquitetura em maiores detalhes.

Iniciaremos com uma breve apresentação da visão lógica da arquitetura, partindo em

seguida para as ferramentas de apoio. Através das ferramentas de apoio poderemos

discorrer de forma mais concreta sobre o funcionamento da arquitetura.

20

3.1 Visão lógica

A Figura 9 é um diagrama de componentes da arquitetura, modelado em UML. O

componente Self-recon�guration é um componente genérico, que pode ser re-utilizado por

qualquer sistema que se baseie nessa arquitetura. Os demais componentes é que serão

especí�cos para cada sistema.

Figura 9: Diagrama de componentes da arquitetura de auto-recon�guração. Extraído deDalpiaz et al. (2009a)

O componente Self-Recon�guration segue o ciclo de Monitoramento - Diagnóstico -

Compensação (MDC), no qual a compensação é uma recon�guração do sistema. Cada uma

dessas etapas é executada por um sub-componente �Monitor, Diagnoser e Recon�gurator,

respectivamente.

Na etapa de monitoramento o sub-componente Monitor irá receber informações do

Context Sensor, do Monitored System e do Support System. O Context Sensor é quem

21

irá fornecer as informações de contexto, pela interface Events. Essas informações são

necessárias para se saber quais expressões de contexto são verdadeiras a cada momento.

O Monitored System é o sistema propriamente dito, ele irá informar ao componente Self-

recon�guration quais objetivos estão ativos e quais tarefas (do modelo de objetivos) estão

sendo executadas, pela interface Log. Já o Support System, que é qualquer sistema que

interaja com o Monitored System, irá informar se as dependências do Monitored System

estão sendo atendidas, pela interface Interaction Log. Ou seja, se o Monitored System

precisa que o Support System realize uma tarefa, a execução dessa tarefa também será

monitorada, pela interface Interaction Log.

Uma vez que as informações necessárias foram obtidas, o sub-componente Diagnoser

irá veri�car se alguma falha aconteceu. De uma forma geral, uma falha é o que acontece

quando o comportamento percebido pelo usuário desvia do comportamento esperado

(AVIZIENIS et al., 2004). Nesta arquitetura, uma falha pode ser uma tarefa que não foi

executada ou que violou as restrições, uma dependência que não foi atendida ou um

objetivo de alto-nível que não foi satisfeito dentro do seu tempo limite (vide Seção 3.2).

Entre o diagnóstico e a recon�guração, entra em ação o componente Policy

Manager, que irá indicar quais falhas poderão ser toleradas e quais as prioridades para a

compensação das falhas. Até o presente trabalho, nenhuma falha era tolerada e todas as

falhas possuiam a mesma prioridade. A única exceção é derivada da semântica da

relação Meio-Fim - se uma tarefa falhar, mas o objetivo para o qual ela é um meio já

estiver satisfeito, então não será necessário haver uma compensação. No exemplo da

Figura 10, se a Tarefa B não for executada, mas a Tarefa C for executada, então a falha

da Tarefa B será ignorada. Da mesma forma, se a Tarefa C não for executada, mas a

Tarefa B for executada, então a falha da Tarefa C será ignorada. Nos demais capítulos

desta dissertação foram de�nidos políticas e mecanismos para enriquecer o tratamento

dessas falhas.

Objetivo A

Tarefa B Tarefa C

Figura 10: Exemplo de uma relação Meio-Fim - para que o objetivo seja satisfeito, apenasuma das tarefas precisa ser executada

O sub-componente Recon�gurator irá selecionar uma compensação para cada uma

22

dessas falhas, que será a recon�guração propriamente dita. Essa recon�guração pode ser

a alocação de uma tarefa ao Support System (interface Task assignments), uma alteração

na con�guração doMonitored System (interface System pushes) ou uma intervenção direta

no ambiente, utilizando o componente Context Actuator (interface Actuations).

Visto o funcionamento geral da arquitetura e os seus componentes, iremos ver na

próxima Seção mais detalhes sobre os modelos utilizados pelo componente

Self-recon�guration. É através dos modelos que esse componente saberá quando os

objetivos de alto-nível devem ser ativados, quais eventos caracterizam a execução de

uma tarefa e em quais contextos um objetivo ou uma tarefa são válidos, entre outros.

3.2 Editor dos modelos

Conforme apresentado no Capítulo 2, o modelo de objetivos utilizado pela

arquitetura precisa conter anotações de contexto. O contexto, por sua vez, também

precisa ser modelado. Para facilitar a criação desse modelo existe uma ferramenta

baseada no ambiente de desenvolvimento Eclipse (FOUNDATION, 2010), cujo nome é

�Requirements editor for self-recon�guring systems� (Editor de requisitos para sistemas

auto-recon�guráveis).

Nesta arquitetura, o modelo de requisitos do sistema é conceitualmente formado por:

modelo de contexto, modelo de objetivos do sistema e modelo de objetivos dos sistemas

de apoio.

O modelo de contexto é formado pelas entidades de contexto, com seus atributos,

e com os contextos propriamente ditos, ou expressões de contexto. Um caso particular

de atributo é quando ele diz respeito a uma outra entidade de contexto, sendo chamado

de atributo de referência (Reference Attribute). Essa referência pode ser obrigatória -

cardinalidade [1..n] - ou não-obrigatória - cardinalidade [0..n].

A Figura 11 é uma visão parcial do modelo de contexto. Nesse exemplo temos uma

entidade de contexto chamada paciente, que possui diversos atributos:

mãosEstãoLimpas, estáNoBanheiro, estáConsciente, éAutoSu�ciente, nívelDeGlicose,

nívelDeGlicoseAdequado e estáEmCasa. Uma vez que as entidades e seus atributos estão

modeladas, podemos utilizá-las nas expressões de contexto, que representam um

contexto especí�co.

Na porção inferior da Figura 11 vemos as propriedades do contexto cujo nome é c2.

23

Item é o atributo ao qual esse contexto se refere, que no caso é éAutoSu�ciente. A

entidade da qual esse atributo faz parte é implícita, e nesse exemplo é paciente. Name

é o nome do contexto, que é utilizado para fazer a referência no modelo de objetivos. A

propriedade Reference Type indica se o atributo selecionado é um atributo de referência

ou um atributo normal. Neste caso, é um atributo normal, por isso este campo �ca em

branco. A propriedade Value é o valor com qual o valor real do atributo será comparado,

enquanto o Value Operator indica qual é a comparação: maior que, menor que, maior ou

igual a, menor ou igual, igual ou diferente. De forma textual, esse contexto C2 formaria a

seguinte expressão: paciente.éAutoSu�ciente = false. Quando o resultado dessa expressão

for verdadeiro - ou seja, quando o paciente não for auto-su�ciente - esse contexto estará

ativo.

Figura 11: Modelo de contextos na ferramenta de edição

A Figura 12 apresenta uma visão parcial dos objetivos de um sistema. Como se

pode ver, existem alguns elementos que não fazem parte da notação Tropos (CASTRO et

al., 2002), como eventos (event) e objetivos de alto-nível (Tl Goal, de Top Level Goal).

Os objetivos de alto-nível são os objetivos principais do sistema que, por serem tão

importantes, cada um deles possui um limite de tempo no qual deve ser satisfeito

(Commitment Time), a partir do momento em que ele se torna ativo. O objetivo de

alto-nível se torna ativo quando sua condição de ativação se torna verdadeira. A

condição de ativação é muito similar ao contexto, só que em vez de estar relacionada a

uma decomposição ou a uma ligação Meio-Fim, está relacionada ao objetivo de

24

Figura 12: Modelo de objetivos na ferramenta de edição

25

Figura 13: Propriedades da condição de ativação na ferramenta de edição

alto-nível. A Figura 13 mostra a janela de edição das propriedades de uma condição de

ativação. A representação textual do exemplo na Figura 13 seria

paciente.nívelAdequadoDeGlicose = false. Ou seja, o objetivo de alto-nível ao qual essa

condição estaria relacionada seria ativado apenas quando o nível de glicose do paciente

se tornasse inadequado.

Cada entidade de contexto pode apresentar várias instâncias. Por exemplo, considere

a entidade paciente: diversos pacientes podem utilizar o sistema ao mesmo tempo. O

paciente Luís vai ser uma instância de paciente, a paciente Ana vai ser outra instância

de paciente, e assim por diante. Da mesma forma, poderá haver várias instâncias de um

objetivo de alto-nível: quando o nível de glicose de Luís se tornar inadequado o objetivo

receberInjeçãoDeInsulina será ativado para Luís; quando o nível de glicose de Ana se

tornar inadequado o objetivo receberInjeçãoDeInsulina será ativado para Ana, e assim por

diante. A de�nição de quais entidades identi�cam um objetivo de alto-nível é feita através

da atribuição de parâmetros ao objetivo. Dessa forma será possível saber que quando

se aplicou a injeção em Ana não foi Luís que teve o objetivo receberInjeçãoDeInsulina

satisfeito.

O re�namento dos objetivos de alto nível segue a modelagem do Tropos: os

objetivos podem ser decompostos em outros objetivos, e tarefas (planos) podem ser

meios para um �m (um objetivo). No entanto, o caráter contextual foi acrescido a essas

relações, através dos elementos Contextual Goal Dec (Decomposição contextual de

objetivo) e Contextual Means End (Relação Meio-Fim contextual), respectivamente.

Esses elementos nada mais são do que uma anotação de contexto sobre uma relação

(decomposição ou Meio-Fim). No exemplo da Figura 14, o elemento selecionado

(Contextual Goal Dec) indica que a decomposição do objetivo de alto-nível

receberInjeçãoDeInsulina para o objetivo aplicarInjeçãoDeInsulina só é válida quando o

26

contexto chamado c1 está ativo.

No lado esquerdo da Figura 15 é apresentado o modelo de objetivos para um sistema de

acompanhamento de pacientes com diabetes, da forma como é representado na ferramenta

de edição. O lado direito da Figura apresenta o mesmo modelo, dessa vez representado

na notação usual de Tropos, a título de comparação. As setas entre uma representação do

modelo e outra indicam o mapeamento dos seus elementos. Este mapeamento é apenas

ilustrativo, para mostrar como os conceitos de Tropos são expressos na ferramenta de

edição.

As tarefas (planos) do modelo de objetivos são compostas por eventos, que

representam os passos de uma tarefa. Essa noção de eventos foi inserida no modelo para

permitir um monitoramento da execução da tarefa a partir dos dados de contexto. Um

evento possui as mesmas propriedades que um contexto, acrescido de um limite de

tempo para a ocorrência do evento. Quando ocorrerem todos os eventos que compõem

uma tarefa, essa tarefa será considerada executada. Adicionalmente, um evento pode ter

pré-condições, que também são expressões de contexto. Se o evento ocorrer, mas a sua

pré-condição não for verdadeira nesse momento, o evento será tratado como se não

tivesse ocorrido. Por exemplo, se o paciente empurrou o êmbolo da seringa (um evento),

mas a agulha da seringa não estava inserida no braço do paciente (uma pré-condição),

então a tarefa aplicarInjeção não pode ser considerada realizada.

Quando o ator não é capaz de realizar uma tarefa por conta própria, essa tarefa terá

uma dependência com um sistema de apoio. Na hora de se modelar os objetivos do

sistema de apoio será preciso, então, modelar o elemento que resolve aquela

dependência. No exemplo da Figura 16, a realização da tarefa (plano)

chamarServiçoDeProntoAtendimento depende de que o objetivo

aplicarInjeçãoDeInsulinaNoPaciente seja satisfeito. Implicitamente, a ferramenta de

edição de�ne qual o sistema de apoio que possui esse objetivo, que no caso é o

ServiçoDeProntoAtendimento. Sendo assim, no Sistema de Apoio (Support System)

chamado ServiçoDeProntoAtendimento existirá o objetivo

aplicarInjeçãoDeInsulinaNoPaciente, que será também re�nado a partir de

decomposições e de relações Meio-Fim.

Uma vez modelado o contexto, os objetivos do sistema e os objetivos dos sistemas de

apoio, podemos partir para a simulação da execução do sistema. Através do simulador

podemos visualizar como seria o comportamento de um sistema utilizando a arquitetura

auto-con�gurável, em diferentes contextos. Posteriormente esse simulador será estendido

27

Figura 14: Propriedades do elemento Contextual Goal Dec

G1: Receber injeção de insulina

Aplicar injeção de insulina

Solicitar o recebimento de injeção de insulina

Coletar e limpar

suprimentos

Paciente de

diabetes

Chamar o serviço de pronto-atendimento

Serviço de

pronto-atendime

nto

C1C2

Aplicar injeção

or

Aplicar injeção de insulina no paciente

CONTEXTOS:

C1: Paciente.éAutoSuficiente =

verdadeiro

C2: Paciente.éAutoSuficiente =

falso

EVENTOS DE ATIVAÇÃO:

G1:

Paciente.nívelDeGlicoseAdequ

ado = false

Preparar material

Realizar a aplicação

and

Figura 15: Representação de objetivos na ferramenta (à esquerda) e com a notação deTropos (à direita)

28

Figura 16: Propriedades de uma Dependência

para suportar as políticas de�nidas neste trabalho (vide Capítulo 5).

3.3 Simulador

O simulador da arquitetura auto-con�gurável é uma implementação do componente

de auto-con�guração (Figura 9, Seção 3.1) que:

a) Em vez de monitorar o contexto através de sensores, recebe como entrada um arquivo

de simulação, que descreve os eventos que acontecem no decorrer do tempo

b) Em vez de interagir com o sistema e com o ambiente para realizar uma recon�guração,

apenas avisa ao usuário que uma recon�guração deveria ser feita para compensar

uma dada falha

Assim como o editor de modelos, este simulador foi desenvolvido pelos mesmos

pesquisadores que elaboraram a arquitetura de referência (DALPIAZ et al., 2009a).

Durante sua execução, o simulador apresenta uma árvore na qual é apresentada a

situação dos objetivos do sistema - se eles estão satisfeitos, ativos ou se falharam. Além

disso, o simulador mostra, para cada tarefa, se ela foi iniciada, realizada ou se falhou.

Quando uma tarefa falha, ele indica também qual compensação deverá ser feita para

aquela falha.

A Figura 17 mostra a janela inicial do simulador. O primeiro passo é carregar o

modelo que foi gerado no editor de requisitos, através da opção Load Model do menu

Model, que na Figura 17 se encontra expandido.

Ao carregar o modelo de requisitos, a conexão com o banco de dados será inicializada

(Figura 18). Os ícones ao lado direito de Current model, Database e Simulation �le

29

Figura 17: Janela inicial do simulador

indicam, respectivamente, se o modelo de requisitos foi carregado corretamente, se a

conexão com o banco de dados foi bem sucedida e se o arquivo de simulação foi

carregado com sucesso. Um ícone em formato de �V� estilizado indica o sucesso da

operação, enquanto um �X� indica a ocorrência de um erro. Neste momento também

ocorre a conversão do modelo de requisitos para um representação na linguagem de

programação lógica Prolog (CLOCKSIN; MELLISH, 2003), que pode ser visualizada na aba

Model (Figura 19). Essa representação em Prolog é utilizada para identi�car as falhas

do sistema durante sua execução, através de chamadas a um compilador de Prolog.

Após carregar o modelo de requisitos, é preciso carregar também o arquivo de

simulação, que pode ser criado no próprio simulador, pelo menu Simulation. A Figura

20 mostra a janela de edição do simulador. Cada coluna da Tabela Context entities

(instances) representa uma entidade de contexto, e cada célula da coluna representa

uma instância daquela entidade. As entidades de contexto são de�nidas

automaticamente ao se carregar o modelo de requisitos, mas as instâncias são de�nidas

manualmente pelo usuário do simulador.

30

Figura 18: Janela do simulador com o modelo carregado

Figura 19: Janela do simulador exibindo a representação do modelo em Prolog

31

Initial timestep é um valor inicial para o contador de ciclos MDC do simulador, o que

permite o início de uma simulação a partir de um ponto especí�co.

Os eventos (Events) representam mudanças no contexto, com a seguinte sintaxe:

happens(atributo,instância,valor,ciclo). A semântica de um evento é que no

ciclo de número ciclo o valor do atributo atributo de instância passará a ser

valor. Por exemplo, o primeiro evento da Figura 20 diz que, no ciclo de número zero, o

valor do atributo estaVencida de garrafa - que é uma instância da entidade Garrafa de

Insulina - será false - ou seja, no ciclo de número zero a garrafa não estará com sua

validade vencida.

Os botões na porção superior da Figura 21 são utilizados, respectivamente, para criar

um novo evento, para apagar o evento selecionado e para editar o evento selecionado. A

criação e a edição de um evento se dá pelos campos mostrados na parte inferior da Figura

21. Primeiro se escolhe uma instância, em seguida um atributo daquela instância, o valor

que esse atributo receberá e o número do ciclo em que esse evento irá acontecer. No

exemplo dessa Figura, o nível de glicose de Pedro passará a ser 180, no ciclo de número

dois.

Ao se de�nir o arquivo de simulação, retorna-se para a janela inicial do simulador,

onde é acrescentada a aba Simulation (Figura 22). Através dessa aba é que será possível

visualizar os resultados da simulação. No lado esquerdo dessa aba podemos visualizar

os eventos do arquivo de simulação (Simulation trace, bem como rede�nir o número do

ciclo inicial (Time). Durante a execução da simulação, o número em Time indica qual o

número do ciclo atual. O botão com um 'V' estilizado é o botão que inicia a simulação.

A Figura 23 mostra uma simulação em andamento. Ao se iniciar a simulação, a

caixa branca no centro dessa janela exibirá a árvore de re�namento de um objetivo de

alto nível que tenha sido ativado. À direita do nome dos objetivos se encontra o tipo

de re�namento: [AND] - decomposição AND; [OR] - decomposição OR; [ME] - relação

Meio-Fim. À direita dessa caixa está a legenda dos símbolos utilizados na árvore.

No exemplo da Figura 23, o tempo limite (Commitment Time) para a satisfação

do objetivo de alto-nível receberInjeçãoDeInsulina foi ultrapassado. Por esse motivo ele

está com o símbolo de Timeout (círculo vermelho com relógio). As outras instâncias de

objetivos de alto-nível ativos ou que, em algum momento, estiveram ativos, podem ser

acessadas pelo botão na parte superior da aba Goal Model.

32

Figura 20: Janela do editor de simulação

Figura 21: Detalhe da janela do editor de simulação, mostrando a criação de um evento

33

Figura 22: Janela do simulador com uma simulação carregada

Figura 23: Janela do simulador com uma simulação sendo executada

34

3.4 Considerações �nais

Neste Capítulo foi apresentada a arquitetura de auto-con�guração utilizada neste

trabalho, bem como seu ferramental de apoio: o Editor de requisitos para sistemas

auto-recon�guráveis e o Simulador. Apesar do desenvolvimento dessas feerramentas não

fazer parte do presente trabalho, a apresentação dessas ferramentas constitui-se uma

contribuição, ao facilitar a adoção das mesmas pela comunidade cientí�ca. Este é o

primeiro trabalho acadêmico no qual essas ferramentas são apresentadas e explicadas.

Ambas as ferramentas ainda estão em desenvolvimento, pelos pesquisadores que

elaboraram a arquitetura (DALPIAZ et al., 2009a). Mesmo ainda não sendo a versão �nal,

o estado atual das ferramentas foi su�ciente para permitir a realização deste trabalho.

Ao apresentar a ferramenta de edição de requisitos, descrevemos em maiores

detalhes o modelo de requisitos do sistema. Este modelo é de fundamental importância

nesta arquitetura, pois é nele que se baseia o raciocínio feito pelo componente

Self-Recon�guration. Através dessa ferramenta, se modela o contexto do sistema, o

modelo de objetivos do sistema e também o modelo de objetivos dos sistemas de apoio.

Dessa forma, poupa-se o trabalho de escrever manualmente os elementos dos modelos,

além de diminuir a probabilidade de ocorrência de erros. No entanto, observa-se que a

visualização dos modelos não é tão amigável e de fácil compreensão quanto em outras

ferramentas que permitem a edição de modelos de objetivos, como o OME3 (YU; YU,

2000) e o iStarTool (SANTOS; JUNIOR, 2009). Um outro ponto fraco dessa ferramenta é

que ela não evita completamente a ocorrência de erros no modelo.

Uma vez apresentada a ferramenta de edição, partimos para o Simulador. No

Simulador é possível criar um arquivo de simulação, que irá representar o contexto no

qual o sistema será executado. Em uma aplicação real, essa informação seria fornecida

em tempo de execução pelos sensores de contexto. No Simulador, a própria ferramenta

permite a criação desse arquivo de simulação. Com o modelo de requisitos do sistema e

o arquivo de simulação, é possível iniciar a simulação propriamente dita. Durante a

simulação são apresentadas todas as instâncias dos objetivos de alto-nível, com suas

respectivas árvores, e o estado de cada elemento das árvores. Dessa forma, pode-se

acompanhar o comportamento do sistema durante sua execução. No entanto, esse

acompanhamento se dá apenas em tempo real, o que não se mostra viável para sistemas

complexos. Dessa forma, um desenvolvimento interessante seria permitir a visualização

do comportamento do sistema em uma linha do tempo, ou em forma de histórico.

35

O Simulador, apesar de ser capaz de mostrar como seria o comportamento da

arquitetura de um ponto de vista funcional, não permite que se tenha uma noção real do

desempenho da arquitetura. Sendo assim, essa variável permanece uma incógnita.

Como visto neste Capítulo, o tratamento de falhas nesta arquitetura é simplista,

uma vez que não apresenta qualquer �exibilidade e considera todas as falhas como tendo

o mesmo impacto. Neste trabalho estamos extendendo esta arquitetura, permitindo um

tratamento de falhas mais elaborado. Esse tratamento será realizado através da

abordagem FAST, apresentada no Capítulo 4.

36

4 A abordagem FAST

Neste Capítulo será apresentada a abordagem FAST, composta pela de�nição de uma

política para tratamento de falhas em uma arquitetura auto-con�gurável, bem como pelos

algoritmos para avaliação das regras da política.

37

A abordagem FAST - Failure handling for Autonomic Systems é formada por uma

política de falhas e por mecanismos para a aplicação da política. A de�nição de políticas

de tratamento de falhas permite que a arquitetura apresentada anteriormente, apesar

de genérica, possa ser adaptada às necessidades de um sistema, de um ambiente ou de

um conjunto de usuários em particular. Isto é feito sem que os envolvidos precisem

se preocupar com detalhes de baixo nível. Sendo assim, as políticas aqui apresentadas

têm como objetivo permitir que o usuário, ou administrador do sistema, personalize o

tratamento de falhas no seu sistema, em tempo de implantação ou de execução.

Inicialmente, apresentaremos a política de falhas, com suas sub-políticas e regras. Em

seguida, na Seção 4.2, descreveremos como deve ser realizada a avaliação das políticas.

Na Seção 4.3 são apresentados casos particulares em que uma regra pode interferir em

outra regra, esclarecendo como cada um desses casos deve ser resolvido. Por último, a

Seção 4.4 apresenta algumas considerações sobre a abordagem aqui apresentada.

4.1 De�nição da política

O modelo conceitual da política de falhas é mostrado na Figura 24. Ela é formada

por duas sub-políticas: Política de Tolerância e Política de Prioridades.

Figura 24: Modelo conceitual da política de falhas

Um sistema pode exibir um comportamento correto, incorreto mas aceitável ou

incorreto inaceitável (VOAS, 1996). Quando o comportamento correto é exibido, então

não há falhas a serem tratadas. Quando o comportamento é incorreto, as falhas existem.

Se uma falha leva o sistema a exibir um comportamento incorreto mas aceitável, então

38

essa falha pode ser ignorada. Para esses casos foi de�nida a Política de Tolerância. Já

quando uma falha leva o sistema a um comportamento incorreto e inaceitável, torna-se

importante que haja uma compensação para essa falha. Mesmo nesses casos, certas

falhas podem se mostrar mais críticas que outras. Para de�nir a criticalidade dessas

falhas, foi criada a Política de Prioridades. Estes dois tipos de políticas foram previstos

na versão original da arquitetura de referência (DALPIAZ et al., 2009a), apesar de não

terem sido devidamente de�nidos.

Ainda de acordo com a Figura 24, cada sub-política possui zero, uma ou diversas

regras. Essas regras compartilham a seguinte estrutura básica:

subject ruleTypeIdentifier predicate

Essa estrutura é baseada na gramática dos idiomas ocidentais, na qual um sujeito

(subject) é modi�cado por um predicado (predicate). O nosso sujeito é formado por uma

ou mais tarefas, do modelo de objetivos. O predicado irá variar de acordo com o tipo de

regra, assim como o ruleTypeIdentifier. O ruleTypeIdentifier é uma cadeia

de caracteres que identi�ca o tipo de regra, colaborando também para a legibilidade das

regras. A de�nição formal da sintaxe das regras só será apresentada na Seção 5.1.1.1,

através de expressões regulares.

Na Seção 4.1.1 iremos de�nir a Política de Tolerância. Em seguida, na Seção 4.1.2,

apresentaremos a Política de Prioridades. Para cada uma dessas políticas iremos

especi�car a sintaxe e a semântica dos diferentes tipos de regras que elas possuem,

ilustrando a utilização das regras através de exemplos. Os tipos de regras foram

de�nidos a partir da análise de cenários de utilização de sistemas.

4.1.1 Política de Tolerância

A política de tolerância se preocupa em de�nir quais falhas de tarefas do sistema

podem ser ignoradas. Por padrão, todas as falhas de tarefa devem ser compensadas,

exceto o caso no qual o objetivo para o qual a tarefa é um �m já tenha sido satisfeito

por outra tarefa (vide Seção 3.1). Para os demais casos, apenas as tarefas explicitamente

expressas na política é que terão as falhas ignoradas.

Foram especi�cados três tipos de regras para esta política, apresentadas na Tabela 2.

O pre�xo `t' no nome da regra indica que ela é uma regra da política de tolerância.

39

Tabela 2: Tipos de regras de tolerânciaTipo Descrição

t.context Expressa que a falha de um conjunto de elementos deveser ignorada em um determinado contexto

t.goal Expressa que a falha de um conjunto de elementos deveser ignorada, condicionada à satisfação de um certoobjetivo

t.limit Expressa um limite máximo de vezes que falhasconsecutivas de um conjunto de elementos devem serignoradas

Conforme explanado no Capítulo 1, estamos assumindo que certas falhas podem ser

ignoradas em condições especí�cas. Nós classi�camos essas condições como sendo

relacionadas ao ambiente no qual o sistema está inserido (o contexto) e como sendo

relacionadas ao sistema propriamente dito. A primeira classe de condição foi mapeada

naturalmente para as regras t.context. Já para a segunda classe, foi preciso decidir quais

elementos do sistema seriam levados em consideração. Para tomar esta decisão nos

baseamos na semântica do modelo de objetivos, na qual os objetivos são a razão para a

existência de um sistema. Sendo assim, consideramos que certas falhas podem ser

ignoradas de acordo com a situação dos objetivos do sistema - satisfeitos ou

não-satisfeitos. Isto é expresso pelas regras do tipo t.goal.

Por último, o tipo t.limi