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
Top Related