UNIVERSIDADE FEDERAL DE PERNAMBUCO
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
CENTRO DE INFORMÁTICA
Oberdan Alves de Almeida Junior
Engenharia de Requisitos para Sistemas AutoAdaptativos
Recife
2013
2
Oberdan Alves de Almeida Junior
Engenharia de Requisitos para Sistemas AutoAdaptativos
Monografia apresentada ao curso de
Pós-Graduação em Ciência da
Computação do Centro de Informática
da UFPE.
Orientador: Prof. Dr. Jaelson Castro.
Recife
2013
3
Resumo
Como consequência da continua evolução dos softwares é exigido que eles
sejam mais versáteis, resilientes, robustos, recuperáveis, customizáveis,
configuráveis e ainda auto-adaptáveis para se adequarem as mudanças de contexto,
ambiente ou características do próprio sistema. Portanto, um sistema que é capaz
de adaptar seu comportamento em resposta a alterações do ambiente e do próprio
sistema tem se tornado um importante tópico de pesquisa na Engenharia de
Requisitos.
Este trabalho tem por objetivo fornecer ao leitor um panorama atual sobre
algumas abordagens propostas por pesquisadores para a especificação e
modelagem dos sistemas auto-adaptativos que estão sendo atualmente trabalhados
no Brasil e no mundo.
Palavras-chave: Sistemas auto-adaptativos, Monitoramento de requisitos,
Engenharia de Requisitos.
4
Abstract
As a result of the continuous evolution of the software is required for them to
be more versatile, resilient, robust, recoverable, customizable, configurable and even
self-adaptable to suit the changing context, environment or characteristics of the
system itself. Therefore, a system that is able to adapt their behavior in response to
changes in the environment and the system itself has become an important research
topic in Requirements Engineering.
This work aims to provide to the reader with a current overview of some
approaches proposed by researchers for specifying and modeling self-adaptive
systems that are currently being worked in Brazil and worldwide.
Keywords: Self-adaptive systems, Requirements monitoring, Requirements
Engineering.
5
Índice
1.
Introdução .................................................................................... 7
1.1
Estrutura do trabalho...................................................................8
2.
Sistemas Auto-Adaptativos............................................................... 9
3.
Linha Base para o Desenvolvimento de Sistemas Auto-Adaptativos ........ 12
3.1
3.2
3.3
3.4
3.5
3.6
4.
Engenharia de Requisitos Orientada a Objetivos – GORE .................... 12
Feedback Control Loop .............................................................. 14
Awareness Requirements ........................................................... 17
3.3.1
Padrões e Representação Gráfica ...................................... 22
Uncertainty ............................................................................ 23
Self-Explanations ..................................................................... 25
RELAX ................................................................................. 28
3.6.1
RELAX Vocabulary ........................................................ 29
Modelos para o Desenvolvimento de Sistemas Auto-Adaptativos ............ 32
4.1
4.2
4.3
Modelos Orientados a Requisitos.................................................. 32
4.1.1
Zanshin ...................................................................... 32
Modelos Orientados a Arquitetura ................................................. 34
4.2.1
Rainbow ..................................................................... 34
Derivação de Modelos ............................................................... 36
4.3.1
Derivação de Statecharts................................................. 37
5.
Considerações Finais .................................................................... 39
6.
Referências ................................................................................. 40
6
Índice de Figuras
Figura 1: Exemplo modelo orientado a objetivos usando a abordagem i* (i-star).
....................................................................................................... 14
Figura 2: Controle do processo humano, exemplo de feedback loop. ............... 15
Figura 3: Modelo MAPE-Loop. ..................................................................... 16
Figura 4: Estados assumidos pelos requisitos. .............................................. 17
Figura 5: Exemplo de um sistema de Despacho de Ambulância. ..................... 18
Figura 6: Representação gráfica dos AwReqs................................................ 23
Figura 7: Exemplo de um modelo utilizando os AwReqs. ................................ 23
Figura 8: Modelo em i* (i-estrela) para um robô aspirador de pó. ................... 26
Figura 9: inclusão de uma claim “No Tripping Hazard" para quebrar o impasse
entre os softgoals. ............................................................................. 26
Figura 10: Modelo de refinamento (CRM) para o robô aspirador de pó. ............ 27
Figura 11: Visão Geral da abordagem Zanshin.............................................. 33
Figura 12: Componentes do Framework Rainbow. ......................................... 35
Figura 13: Passos necessários para derivação do statechart. .......................... 38
Índice de Tabelas
Tabela 1: Os diferentes tipos de AwReqs. .................................................... 19
Tabela 2: Operadores da Linguagem RELAX. ................................................ 30
7
1. Introdução
Sistemas adaptativos são sistemas capazes de alterar o seu comportamento
em resposta a mudanças de contexto, ambiente e em características do próprio
sistema com o objetivo de cumprir a tarefa para qual foi designado. Esses sistemas
conseguem mudar o seu comportamento em tempo de execução com o mínimo ou
sem nenhuma intervenção humana, mesmo em ambientes dinâmicos. Os objetivos
do sistema são monitorados e as falhas são tratadas com compensações ou
atividades de recuperação. O sistema deve manter um conjunto de objetivos de alto
nível que será satisfeito de acordo com o que foi definido pelas partes interessadas
(stakeholders), os objetivos definidos deve, claro, respeitar as condições do
ambiente em execução. Alguns objetivos não críticos podem ser “relaxados”, assim
permitindo ao sistema um certo grau de flexibilidade durante ou após a adaptação
[1].
Os requisitos para softwares auto-adaptativos devem refletir a incerteza sobre
as condições do ambiente onde o software será implementado e também sobre a
variabilidade do contexto operacional e as necessidades dos usuários. Os requisitos
adaptativos envolvem a noção de variabilidade associada às funcionalidades ou
restrição de qualidade do sistema [3].
A engenharia de requisitos para sistema auto-adaptativos é preocupada com
o que um sistema deve fazer e dentro de que condições ele deve fazer o que se
propõe, portanto a engenharia de requisitos deve endereçar que adaptações são
possíveis e em que condições tais adaptações são percebidas. Algumas questões
podem ser endereçadas pela engenharia de requisitos, como: Que aspectos do
ambiente são importantes para adaptação? Quais requisitos são permitidos variar ou
ser envolvidos em tempo de execução e quais devem ser mantidos? Em resumo, a
engenharia de requisitos para sistemas auto-adaptativos deve estar preparada para
enfrentar as incertezas, porque as informações sobre a futura execução no ambiente
8
estão incompletas e, portanto, os requisitos para o comportamento do sistema pode
ser alterado em resposta as mudanças do ambiente.
Várias abordagens foram e estão sendo propostas por pesquisadores da área
de Engenharia de Software para o desenvolvimento de sistemas auto-adaptativos.
Neste trabalho discutiremos algumas destas abordagens dando um foco na
especificação e modelagem destes sistemas.
1.1 Estrutura do trabalho
Este trabalho está dividido em seis capítulos. O primeiro é capítulo
introdutório sobre sistema auto-adaptativo.
No capítulo 2 definiremos o que é um sistema auto-adaptativo e discutiremos
um pouco sobre o porquê e como desenvolver este tipo de sistema.
No capítulo 3 abordaremos sobre a linha base para o desenvolvimento de
sistemas auto-adaptativos, neste capítulo discutiremos os aspectos mais comuns e
comentados sobre os sistemas auto-adaptativos aqui no Brasil e no mundo.
No capítulo 4 abordaremos sobre os modelos orientados a requisitos e a
arquitetura para auxiliar o desenvolvimento dos sistemas auto-adaptativos e como
derivar os modelos (de requisitos para o de arquitetura), em seguida discutiremos o
modelo de derivação de statecharts.
No capítulo 5 apresentaremos as considerações finais e para finalizar, no
capítulo 6 as referências bibliográficas deste trabalho.
9
2. Sistemas Auto-Adaptativos
Um dos motivadores para o surgimento de uma nova abordagem da
computação é o avanço tecnológico. Diferentes plataformas de hardware,
dispositivos móveis e ambientes operacionais fizeram com o que os softwares se
tornassem mais versáteis e pudessem reconhecer estas diferentes plataformas e
ambientes. Os softwares tiveram que desenvolver as chamadas propriedades “auto*”, ou seja, auto-configuração, auto-recuperação, auto-otimização, auto-proteção e
auto-gestão. Uma propriedade que é considerada transversal a estas é a autoadaptação. O sistema deve manter ainda a maior parte de sua complexidade
escondida do usuário e administrador [3].
Uma decisão importante a ser tomada no momento da concepção de um
software é se ele possui ou não características adaptativas, se estas características
não forem detectadas, indicam fortemente que um sistema convencional e estático
proverá uma solução mais adequada. A adaptação é uma estratégia que deve ser
adotada pelo analista quando ele reconhece que seu modelo do ambiente não está
totalmente “completo”, e isto pode não acontecer pela falta de conhecimento do
ambiente onde o software será usado, e sim por causa da grande variabilidade
encontrada no ambiente. Por exemplo, o desenvolvimento de um software para
dispositivos móveis, inúmeros modelos de celular poderiam fazer uso do software
sem que o analista precisasse conhecer todos os modelos.
Algumas perguntas podem ajudar o analista a identificar os requisitos a ser
implantado no sistema, como por exemplo: O quê (What) o sistema deve fazer e
Como (How) deve ser feito. Por que (Why) o usuário precisa disso? E por que deste
modo? Estas perguntas ajudam o analista a identificar os requisitos funcionais do
sistema, as restrições de qualidade e as preferências, mas para desenvolver um
software auto-adaptativo é preciso explicitar as alternativas na realização do
objetivo, ou seja, a variabilidade em “O quê” e “Como”, o que pode ser reforçada
10
também por “Onde” (Where) e “Quando” (When) devido às características do
ambiente operacional [3].
Existem duas classes não exclusivas de ambiente que ajuda o analista a
identificar que o software tem características de um sistema auto-adaptativo. A
primeira classe é onde os requisitos são uma consequência das mudanças do
ambiente. Como por exemplo, um dispositivo móvel necessita de habilidade para
adaptar de uma forma que consiga vantagens de novos serviços à medida que eles
ficam disponíveis. A segunda classe é quando “as perdas e ganhos” (trade-offs)
entre os requisitos não-funcionais (NFRs) variam de acordo com o contexto. A
hipótese é que a segunda classe seja mais comum, mas também mais repentina e
difícil de reconhecer. Por exemplo, no caso de dispositivo móvel, a escolha do
serviço a ser utilizado pode ser minimizada pela preferência por certos provedores
que talvez não estejam sempre disponíveis. Os trade-offs entre NFRs é uma chave
importante que pode significar que a adaptação é necessária [11].
Um dos principais desafios que um sistema auto-adaptativo enfrenta é que
quando desenhado não podemos assumir que todas as adaptações são conhecidas
até o momento, e isto é difícil de antecipar, os requisitos para todo conjunto possível
das condições do ambiente e sua respectiva especificação de adaptação. Como
exemplo uma especificação pra prevenir cyber attacks, sempre estão especificando
novos tipos de ataques e seria impossível prever todas as possibilidades [1].
Já Berry et al. [21] defende que um software que deve lidar com ambientes
totalmente desconhecidos são o extremo na abordagem de sistemas autoadaptativos. O mais comum é a situação onde o ambiente é volátil, mas conhecido
suficientemente bem para permitir que o analista possa antecipar como ele irá mudar
(tarefa esta não muito trivial). Aqui, a abordagem defendida é para caracterizar o
ambiente como um conjunto de domínios onde os objetivos do software podem
transitar entre esses domínios. O trabalho do analista é então especificar cada alvo
do sistema e a adaptação para cada cenário.
Pimentel et al. em [15] discute os métodos de previsão propostos por vários
autores, entre eles está o “Futures Wheel” que é um método de previsão que fornece
11
um modelo do futuro com base nas consequências de um evento ou uma tendência.
É um método subjetivo e qualitativo, este método conta com a experiência e o
conhecimento dos participantes. O método em si é constituído por duas etapas, o
primeiro passo é identificar as tendências ou eventos que possam vir a ocorrer em
um futuro próximo e que estejam relacionados com o domínio do problema. A
tendência é algo que já começou e está cada vez mais forte, como "Uso de carro
elétrico" ou "fluxo de vídeos ao vivo na Internet". Um evento futuro é simplesmente
algo que se espera que aconteça - por exemplo, "Toda a população do País X terá
acesso à Internet". O segundo passo é refinar o evento, acrescentando as suas
consequências. Para cada evento, vamos perguntar: "Quais são os impactos ou
consequências do evento?”. Então, para cada consequência devemos identificar as
consequências secundárias, ou seja, as consequências das consequências, em
seguida as consequências terciárias, e assim por diante.
Sistemas auto-adaptativos é um tema muito pesquisado e provê vários
benefícios, como por exemplo: redução de custo pela menor quantidade de
manutenções; requer menos intervenção humana, pois de acordo com o que foi
especificado o software pode alterar automaticamente seu comportamento;
transparência em seu funcionamento, já que a sua complexidade é escondida para o
usuário. Algumas características estão mais consolidadas e outras estão sendo
propostas pela comunidade da Engenharia de Software, a seguir veremos algumas
delas.
12
3. Linha Base para o Desenvolvimento de Sistemas AutoAdaptativos
Existem alguns conceitos propostos ou defendidos pela comunidade da
engenharia de requisitos que podemos ver comumente em vários artigos científicos
[1] [3] [7] [8] [16] [18] escritos para sistemas auto-adaptativos.
Vários desses conceitos formam a base para algumas das abordagens dos
sistemas auto-adaptativos que estão sendo fortemente difundidas. Algumas destas
abordagens já são bem consolidadas, como é o caso do GORE (a abordagem
GORE não foi criada para sistemas auto-adaptativos, porém foi adotada pela
comunidade por que ela oferece recursos importantes para o desenvolvimento de
qualquer software) e do Feedback Control Loop, existem outras que estão sendo
discutidas, como é o caso do Self-Explanation.
Discutiremos a seguir algumas dessas abordagens.
3.1 Engenharia de Requisitos Orientada a Objetivos – GORE
Engenharia de Requisitos Orientada a Objetivos (Goal-Oriented Requirements
Engineering - GORE). GORE foi proposta e sua popularidade cresceu devido à
inadequação das abordagens anteriores ao lidar com sistemas muito complexos.
Estas abordagens não capturavam a lógica por trás dos requisitos que estavam
sendo modelados, tornando-os, assim, difíceis para entender no que diz respeito às
características de alto nível no domínio do problema [19] [22]. A maioria das técnicas
se concentrava apenas na modelagem e especificação do software. Portanto, elas
não tinham o suporte para a lógica sobre a composição do sistema, que
compreende o sistema a ser construído e o seu ambiente. No entanto, suposições
incorretas sobre o ambiente de um sistema são conhecidas por ser responsáveis por
muitos erros nas especificações dos requisitos. Os requisitos não-funcionais também
são, em geral, deixado de fora das especificações de um software. Além disso,
13
técnicas de modelagem e análise tradicionais não permitem configurações
alternativas do sistema.
É importante notar que o processo de elaboração de requisitos orientado a
objetivos termina onde a maioria das técnicas de especificação tradicionais
começaria. Em geral, GORE é focado nas atividades que antecedem a formulação
de requisitos do sistema. As seguintes atividades principais estão normalmente
presentes na abordagem GORE: elicitação de objetivo, refinamento de objetivos e
vários tipos de análise de objetivos, e a atribuição de responsabilidade dos objetivos
para os agentes.
Um modelo de organização humana que vê os seres humanos e as
organizações como entidades em busca do objetivo pode ser visto como a base
para a modelagem de objetivo.
Há várias definições de Objetivos na literatura da Engenharia de Requisitos.
Por exemplo, Anton afirma que os “objetivos” são metas de alto nível da empresa,
organização ou sistema; eles capturam as razões pelas quais é necessário um
sistema e guia as decisões por vários níveis dentro da empresa [22].
Um aspecto importante da engenharia de requisitos é a análise de requisitos
(qualidade) não-funcionais (NFRs). NFRs geralmente são representados em
modelos da engenharia de requisitos por softgoals. Não há nenhuma condição de
satisfação clara para um softgoal. Softgoals estão relacionados com a noção de
satisfação, ao contrário de objetivos comuns, softgoals raramente podem ser ditos
como realizáveis ou satisfeitos, para os softgoals é preciso encontrar soluções que
sejam “suficientemente boas". Requisitos não-funcionais de alto nível são
abundantes nas organizações e com bastante frequência o sucesso dos sistemas
depende da satisfação destes requisitos. Os softgoals possuem links de contribuição
qualitativos que pode ser de satisfação ou negação e possui quatro níveis de
contribuição: quebra “break” (--), fere “hurt” (-), ajuda “help” (+) e faz “make” (++).
14
Engenharia de requisitos orientada a objetivos vê o sistema a ser construído e
o seu ambiente como um conjunto de componentes ativos chamados agentes.
Figura 1: Exemplo modelo orientado a objetivos usando a
abordagem i* (i-star).
3.2 Feedback Control Loop
Feedback control loop (iremos traduzir como ciclo de controle de retorno)
considera os aspectos dinâmicos de um sistema, ele verifica a saída do sistema
controlado e permite ajustar as operações de acordo com as diferenças entre os
resultados reais e a saída desejada. Em outras palavras feedback control loops são
entidades que observam o sistema e iniciam a adaptação, portanto, os especialistas
de pesquisa atuais afirmam que feedback loops são essenciais para a compreensão
de todos os tipos de sistemas adaptativos.
Como feedback loop desempenha um papel importante quando descreve o
comportamento dinâmico de sistemas auto-adaptativo, eles precisam se tornar
visível e ser tratado como uma entidade de primeira classe durante a fase de design.
Por exemplo, múltiplos feedback loops com objetivos contrários podem interferir uns
aos outros de uma forma negativa ao interagir no mesmo ambiente. Este e outros
15
problemas devem se tornar visível o mais cedo possível para serem tratados de
forma apropriada.
Várias abordagens atuais de desenvolvimento de software tendem a
concentrar-se na estrutura estática em vez dos aspectos dinâmicos quando
constroem softwares auto-adaptativos. Para tratar feedback loop como uma entidade
de primeira classe é necessário entender os conceitos e os problemas associados
que podem aparecer durante o tempo de execução de sistemas.
Como mostrado na figura 2 as características do feedback loops podem ser
explicadas imaginando uma pessoa enchendo um copo de água a partir de uma
torneira. Visando encher o copo até determinado nível, uma pessoa abre a torneira
até uma certa posição (Faucet Position) (amarelo). Isto impacta o fluxo de água
(Water Flow), resultando em um controle da força e do nível de água correspondente
que está sendo observado (vermelho). Será feita uma análise (azul) para constatar a
força, fluxo e o nível de água dentro do copo (Current Water Level), uma decisão
deverá ser tomada a fim de fechar ou ajustar a torneira ou deixá-la como está
quando o nível de água desejado (Desired Water Level) em mente for comparado
com o nível de água real (Perceived Gap) (verde). Então, o ajuste da posição da
torneira depois da observação do fluxo de água corrente e a tomada de uma
determinada decisão podem ser visto como um feedback loop.
Figura 2: Controle do processo humano, exemplo de feedback loop.
16
De um ponto de vista técnico, a pessoa pode ser vista como um sistema autoadaptativo que está interagindo com o ambiente (torneira) para alcançar um
determinado objetivo (nível de água desejado). Alguns componentes (os olhos
humanos) capturam o estado atual do meio ambiente (nível e fluxo de água) e
passam as informações para um gerenciador autônomo (o cérebro). Esta unidade
central é responsável por coletar/monitorar as informações, analisar, tomar decisões
e controlar alguns componentes do sistema (a mão), a fim de interagir com o meio
ambiente de uma maneira adequada (abrir ou fechar a torneira). Portanto, coletar
informações, analisar, decidir e agir leva a um modelo de feedback loop mais
genérico, conforme apresentado na figura 3 e definido melhor a seguir.
Figura 3: Modelo MAPE-Loop.
Um Monitor computacional reúne informações do sistema gerenciado e,
possivelmente, do ambiente, a fim de atualizar um conjunto de modelos relevantes,
fornecendo os cálculos subsequentes ao control loop com os dados necessários. Um
Analisador computacional examina os dados anteriormente recolhidos pelo monitor,
e com base nos objetivos de adaptação, tira conclusões sobre que medidas devem
ser tomadas pelo sistema auto-adaptativo. Um Plano reúne uma série de ações de
adaptação para resolver o problema identificado pela análise. Esse conjunto de
ações para o sistema gerenciado é então executado por uma Execução
computacional. Uma sequência simples destas quatro ações computacionais –
Monitorar – Analisar – Planejar – Executar (Monitor-Analisar-Plan-Executar - MAPE)
é a maneira mais óbvia de formar o control loop em um sistema auto-adaptativo [24].
17
3.3 Awareness Requirements
Awareness Requirements (traduzido como “Requisitos de “Percepção” em [6])
são requisitos que atestam sobre o sucesso ou o fracasso de outros requisitos.
Geralmente, Awareness Requirements (AwReqs) atesta sobre os estados que os
requisitos podem assumir em tempo de execução. A figura 4 mostra esses estados
que, no contexto da estrutura de modelagem desenvolvida no exemplo do Despacho
de Ambulância que veremos mais a frente, podem ser assumidos por objetivos,
tarefas, suposições de domínios (Domains Assumptions – DAs), restrições de
qualidade (Quality Constraint – QCs) e os próprios AwReqs.
Quando um ator começa a buscar um requisito seu resultado ainda não está
decidido. Eventualmente, o requisito terá sucesso ou falha. Para objetivos e tarefas
também há um estado cancelado.
Figura 4: Estados assumidos pelos requisitos.
Restrições de Qualidade (QCs) são derivações feitas dos softgoals de uma
forma que possam ser traduzidas em entidades perceptíveis e mensuráveis.
Suposições de Domínio (DAs) indicam os estados do mundo que assumimos
ser verdade, a fim de que o sistema funcione. Por exemplo, vamos supor que as
redes de comunicação (telefone, internet, etc.) são fornecidas e funcionam
corretamente. Se isso não for verdade, eventualmente não poderemos realizar
ligações telefônicas.
Para facilitar o entendimento sobre os AwReqs, iremos utilizar o exemplo do
Despacho de Ambulância usado em [18]. A figura 5 mostra o modelo que foi feito
18
para o sistema Despacho de Ambulância utilizando uma abordagem orientada a
objetivos (GORE).
O objetivo principal do sistema é apoiar o despacho de ambulância. Os
objetivos do sistema foram decomposto em refinamentos E / OU. Por exemplo, para
receber uma “chamada de emergência” (Receive emergency call), devemos dar
“entrada na informação” (Input emergency information), determinar a sua unicidade
(Determine uniqueness of call) (pode ter havido outras chamadas para o mesmo
caso de emergência), e em seguida enviar uma mensagem para os despachantes
(Send to Despatchers), tudo partindo do pressuposto que "as redes de comunicação
estão funcionando” (Communication networks working). Por outro lado, a atualização
periódica do status de uma ambulância pode ser feita automaticamente ou
manualmente. Os objetivos são decompostos até atingirem um nível de
granularidade onde existam apenas tarefas que um ator (sistema ou humano) possa
realizar. Na figura 5, os objetivos são representados como círculos ovais e as tarefas
como hexágonos.
Figura 5: Exemplo de um sistema de Despacho de Ambulância.
Os softgoals (oriundos da abordagem GORE) são tipos especiais de objetivos
que não têm critérios de satisfação claros. No exemplo, os stakeholders gostariam
que: O despacho das ambulâncias fosse rápido, as chamadas fossem priorizadas e
não ambíguas, e a seleção das ambulâncias fosse pela proximidade do local da
19
emergência. A realização de um softgoal pode ser estimada por meio de links de
contribuição qualitativos. Por exemplo, a atualização de status da ambulância
usando o sistema de software contribui positivamente (+) para a proximidade da
ambulância ao local da emergência, porém utilizar a opção manual, ao invés da
automática, contribui negativamente (-) para o mesmo critério. Contribuições podem
existir entre quaisquer dois objetivos.
A tabela 1 mostra alguns dos AwReqs que foram elicitados durante a análise
do Sistema de Despacho de Ambulâncias. Estes exemplos são apresentados para
ilustrar os diferentes tipos de AwReqs que são discutidos nos parágrafos seguintes e
também alguns padrões que podem facilitar o seu levantamento.
Tabela 1: Os diferentes tipos de AwReqs.
AwReq
AR1
Descrição
“Entrada de Informações de Emergência”
Tipo
Padrão
Regular
NuncaFalhar(T-InputInfo)
Aggregate
TaxaSucesso(D-
Nunca devem falhar.
AR2
A “rede de comunicação” deve ter 99% de
taxa de sucesso.
AR3
“Buscar a chamada no banco de dados”
CommNetsWork, 99%)
Aggregate
deve ter uma taxa de sucesso de 95% em
TaxaSucesso(GSearchCallDB, 95%, 7d)
relação ao período de uma semana.
AR4
“O despacho de ambulância” deve falhar no
Aggregate
máximo uma vez por semana.
AR5
“Chegada da ambulância” em 10 minutos
7d)
Aggregate
@daily SuccessRate(Q-
deve ter sucesso em 60%, enquanto a
Amb10min,60%) and
chegada da ambulância em 15 minutos deve
SuccessRate(Q-Amb15min,
ter 80% de sucesso, medido diariamente.
AR6
MaxFailure(G-DispatchAmb, 1,
“Atualização das tarefas automaticamente”
80%)
Aggregate
deve ter 100 vezes mais sucesso do que
ComparableSuccess(TUpdAuto,T-UpdManual, 100)
manualmente.
AR7
A taxa de sucesso de “Nenhuma Ambulância
Trend
Extra Necessária” para o mês não deve
not TrendDecrease(QNoExtraAmb,30d, 2)
diminuir, comparado com o mês anterior,
duas vezes consequentemente.
AR8
“Atualização da chegada ao local” deve ser
Delta
ComparableDelta(T-
executada com sucesso dentro de 10
UpdArrSite,T-InformDriver,
minutos da execução de sucesso da tarefa
time, 10m)
20
“Informar ao Motorista” para a mesma
chamada de emergência.
AR9
Marcar como único ou duplicado deve ser
Delta
decidido em 5 minutos.
AR10
AR3 deve ter 75% de taxa de sucesso no
StateDelta(T-MarkUnique,
Undecided, *, 5m)
Meta
SuccessRate(AR3, 75%, 30d)
Meta
NeverFail(AR5)
período de um mês.
AR11
AR5 nunca deve falhar.
Podemos identificar uma série de tipos de AwReq. AR1 mostra a forma mais
simples de AwReq: o requisito a que se refere nunca deve falhar. Considerando um
sistema de controle, a entrada de referência é satisfazer o requisito. Se a saída real
está nos dizendo que o requisito falhou, então o sistema de controle deve agir
(compensar, reconciliar), a fim de trazer o sistema de volta a um estado aceitável.
AR1 considera todas as instâncias do requisito referido. Uma instância de uma tarefa
é criada toda vez que ela é executada e a restrição “nunca falhar” é então verificada
para cada uma das instâncias. Da mesma forma, existem instâncias de um objetivo
sempre que o objetivo precisa ser executado, enquanto os DAs e QCs são criados
sempre que a sua verdade / falsidade precisam ser verificados no contexto da
realização de um objetivo.
Um AwReq agregado (aggregate) se refere a instância de outro requisito e
impõe restrições em suas taxas de sucessos/falhas. Isto é, AR2 é o AwReq
agregado mais simples: Ele solicita que o referido DA seja verdadeiro 99% do tempo
que o objetivo “Receber Chamada de Emergência” é tentado ser realizado. AwReq
agregado pode também especificar o período de tempo para considerar quando está
agregando instâncias de requisitos (exemplo AR3). A frequência com que o requisito
deve ser verificado é um parâmetro opcional para AwReqs. AR5 é um exemplo de
um AwReq com especificação de intervalo de verificação.
Outro padrão para agregação AwReq é a especificação do mínimo/máximo e
sucesso/falha que um requisito é permitido ter (exemplo AR4). AwReq pode
combinar diferentes requisitos, como AR5, que integra dois QCs com diferentes
taxas. Um pode até mesmo comparar a contagem de sucesso de dois requisitos
21
(AR6). Isto captura uma propriedade desejada de um procedimento de seleção
alternativo quando decidido em tempo de execução como realizar um objetivo.
AR7 é um exemplo de uma tendência (trend) que compara a taxa de sucesso
sobre um período.
A tendência de um AwReq pode ser usada para marcar
problemas de como a taxa de sucesso/falha é avaliada sobre o tempo.
Delta
AwReqs, por outro lado, pode ser usado para especificar um limite aceitável para o
cumprimento dos requisitos, como o tempo de realização. AR8 especifica que a
tarefa “Atualização da chegada ao local” (Update arrival at site) deve ser executada
(execução finalizada completamente com sucesso) dentro de 10 minutos da
execução da tarefa “Informar ao motorista” (Inform Driver). Isto significa que uma vez
que o despachante tem informado onde é a emergência para o motorista da
ambulância ela deverá chegar dentro de 10 minutos.
Outro Delta AwReq, AR9, mostra como não podemos falar somente sobre
sucesso ou falha dos requisitos, mas também sobre mudanças dos estados. Na
realidade, quando dizemos que um requisito “deve ter sucesso ou não (falha)”
queremos dizer que ele “não deve transitar entre a indecisão de sucesso ou falha”.
AR9 ilustra ainda outro caso: a tarefa “Marcar como único ou duplicado” (Mark as
unique or duplicate) deve ser decidida, isto é, deve abandonar o estado de indecisão
dentro de 5 minutos. Em outras palavras, independentemente se eles tiveram
sucesso ou falha, os operadores devem não desperdiçar mais de 5 minutos
decidindo se uma chamada é ambígua ou não.
Finalmente, AR10 e AR11 são exemplos de meta-AwReqs: AwReqs que se
referem a outros AwReqs. Uma motivação para meta-AwReqs é a aplicação de uma
gradual ação de reconciliação/compensação. Este é o caso do AR10: Se AR3 falhar,
AR10 deve marcar a chamada como “possivelmente ambígua” (reconciliando AR3),
mas se a taxa de sucesso de AR3 considerando todo o mês for menor que 75%,
uma profunda analise de procura de problemas no Banco de dados deve ser
executada para verificar se o banco está em ordem (reconciliando AR10).
Outro caso útil para meta-AwReqs é evitar a execução de ações específicas
de reconciliação / compensação muitas vezes. Por exemplo, AR5 afirma que 60%
22
das ambulâncias deve chegar em até 10 minutos e 80% em até 15 minutos e para
reconciliar devemos acionar mensagens para todos os usuários dos sistema. Para
evitar o envio de mensagens repetidas em caso de falha novamente, AR11 monitora
AR5 com a afirmação de que ela nunca deve falhar e, no caso de isso acontecer,
sua reconciliação diminui os percentuais da AR5 por 10% (50% e 70%,
respectivamente), o que significa que uma nova mensagem será enviada somente
se o desempenho de resposta de emergência for pior. Se o envio da mensagem for
evitado duas vezes por mês, a reconciliação da AR11 poderia ser, por exemplo, a
desativação AR5 para o mês corrente.
3.3.1 Padrões e Representação Gráfica
Formalizar AwReqs não é uma tarefa trivial. Por esta razão, foram propostos
padrões AwReq para facilitar a sua elicitação e análise e uma representação gráfica
que nos permita incluí-las no modelo de objetivo, melhorando a comunicação entre
os analistas de sistemas e designers.
A última coluna da tabela 1 mostra os padrões para cada um dos AwReqs
considerados em nosso exemplo. A lista dos padrões mostrados na tabela não está
de forma exaustiva e cada organização é livre para definir seus próprios padrões. Ao
usar tais padrões criamos um vocabulário comum para os analistas e ferramentas de
geração de código poderiam ser fornecidas para escrever automaticamente AwReqs
na língua escolhida.
Para o exemplo que trabalhamos a notação é exibida na figura 6 e 7. AwReqs
são representados por círculos espessos com setas apontando para o elemento
para o qual eles se referem e o padrão AwReq além dele.
23
Figura 6: Representação gráfica dos AwReqs.
Figura 7: Exemplo de um modelo utilizando os AwReqs.
3.4 Uncertainty
Em geral, no campo da engenharia de software, a incerteza (uncertainty) é
considerada como um conceito de segunda ordem. Um equívoco comum é que, por
um conjunto de práticas o efeito da incerteza pode ser removido para permitir focar
no comportamento "normal". Embora, em geral, isso seja verdade, mais informações
diminui a quantidade de incerteza, é tipicamente impossível eliminar completamente
a incerteza uma vez que não é prático nem desejável coletar todas as informações
sobre um sistema. A Engenharia de software auto-adaptativo não é exceção,
enquanto o nível de incerteza pode variar, raramente é o caso de um sistema de
software auto-adaptativo ser completamente livre de incerteza [25].
24
A incerteza pode ser observada em todos os aspectos da adaptação, embora
em graus variáveis. Por exemplo, uma das razões por trás da incerteza é o fato de
que, o usuário, a lógica de adaptação e a lógica de negócios do sistema são
fracamente acoplados, introduzindo inúmeras fontes de incerteza. Considere que os
usuários muitas vezes tem dificuldade em expressar com precisão as suas
preferências de qualidade. Acreditamos que, considerando a incerteza como um
conceito de primeira classe melhora a qualidade ou, às vezes, até mesmo corrige as
decisões de adaptação.
Apesar do fato de que a incerteza está predominante em sistemas de
software auto-adaptativo, muitas vezes ela é considerada de forma ad hoc (criada
especificamente para cada caso). Uma razão para isso é que o termo incerteza é um
conceito vagamente entendido na comunidade acadêmica, pois há muitas fontes de
incerteza e nem todas as fontes têm características semelhantes.
Algumas fontes de incerteza são externas, enquanto outras são internas.
Incerteza externa surge a partir do ambiente ou domínio no qual o software é
implantado. Por exemplo, a incerteza externa para um sistema de software
implementado em um veículo não tripulado pode incluir a possibilidade de
determinadas condições meteorológicas que ocorrem. Software auto-adaptativo é
uma abordagem para lidar com efeitos da incerteza externa, por exemplo, em uma
tempestade de neve o componente de navegação de um veículo pode ser alterado
para navegar de uma forma mais conservadora para evitar uma colisão. Por outro
lado, a incerteza interna está enraizada na dificuldade de determinar o impacto da
adaptação sobre os objetivos de qualidade do sistema, por exemplo, determinar o
impacto da substituição de um componente de software na capacidade de resposta
do sistema, o uso da bateria, etc.
Além disso, nem todas as fontes de incerteza têm características
semelhantes. Às vezes, a incerteza é devido à falta de conhecimento, enquanto
outras vezes é devido à variação em um parâmetro que afeta as decisões de
adaptação (adaptação de parâmetros). As técnicas utilizadas para atenuar um tipo
de incerteza podem ser diferentes de outras técnicas utilizadas para atenuar outros
tipos.
25
A incerteza na natureza do meio ambiente operacional pode fazer com que o
comportamento dos sistemas auto-adaptativos não seja previsto com precisão. Um
sistema cujo comportamento não pode ser previsto com precisão pode trazer sérios
problemas em termos de segurança e aceitação.
O comportamento de um sistema auto-adaptativo é melhor explicado em
termos de satisfação dos seus requisitos.
3.5 Self-Explanations
Self-Explanations (Auto-Explicações) pode ser considerado um aspecto
desejado em um sistema, ele fornece ao sistema a capacidade de registrar e
explicar determinados comportamentos adotados.
Self-Explanation compreensíveis são difíceis de produzir, com vários desafios
para os desenvolvedores criarem facilmente tais funcionalidades:
Em primeiro lugar, a habilidade de explicar o comportamento depende de uma
capacidade de monitoramento, introspecção e de raciocínio sobre o
comportamento atual e passado do sistema.
Em segundo lugar, as explicações precisam ser criadas em um nível
suficientemente elevado para ser compreensível pelos stakeholders.
Em terceiro lugar, self-explanations para ser confiável, um sistema autoadaptativo deve ser capaz de rastrear a partir dos objetivos até o código para
manter um link sincronizado entre requisitos e a arquitetura durante a
execução.
E por último, um sistema auto-adaptativo deve ser capaz de reproduzir a
história de rastreamento das adaptações que tem sido realizada de uma
maneira que seja clara para apoiar self-explanations.
Considere o exemplo de um robô aspirador de pó que é utilizado para limpar
apartamentos domésticos (Clean Apartment). O robô utiliza a auto-adaptação para
equilibrar os requisitos não-funcionais conflitantes: “evitar causar acidente” (Avoid
Tripping Hazard) para as pessoas dentro do apartamento e ser “econômico no
consumo de energia” (Minimise Energy Costs). O robô suporta dois modos de
26
operação: “limpar durante a noite” (Clean at Night) e “limpar quando vazio” (Clean
when Empty).
Para ilustrar os requisitos não-funcionais é utilizada a abordagem i* (i-estrela).
Figura 8: Modelo em i* (i-estrela) para um robô aspirador de pó.
Como podemos notar na figura 8 há um impasse na realização dos objetivos
“Clean at Night” e “Clean when Empty”, ambos contribuem negativamente (Hurt) e
positivamente (Help) para a realização dos requisitos não-funcionais “Avoid Tripping
Hazard” e “Minimise Energy Costs”.
Para acabar com o impasse é feita uma
suposição (claim) de que “não há risco de acidente” (No Tripping Hazard) como
mostrado na figura 9.
Figura 9: inclusão de uma claim “No Tripping Hazard" para quebrar o
impasse entre os softgoals.
27
Embora admitindo que o risco de tropeço representa um risco real, a ação é
uma maneira conveniente em quebrar o impasse no modelo de objetivos, a
suposição é uma mera conjectura e seria difícil de verificar na fase de design. Assim,
é fornecido para o robô um meio de verificar a suposição em tempo de execução
usando monitoramento. A ampla natureza da suposição “No tripping hazard" torna
difícil um mecanismo de acompanhamento adequado, por isso é utilizado um modelo
de refinamento (Claim Refinement Model – CRM) para decompor a suposição
hierarquicamente
em
suposições
subjacentes.
Há
quatro
sub-suposições
organizadas em dois ramos com AND (“E”) (claims também podem ser OR - “OU”).
Juntos, os ramos ilustram a razão por que a alegação raiz deve permanecer. Neste
caso, "No tripping hazard" permanece verdadeira se “não há ninguém na sala”
(empty room) em que o robô aspirador de pó estiver funcionando e “nenhum impacto
externo” (no foot impact).
Figura 10: Modelo de refinamento (CRM) para o robô
aspirador de pó.
As demais suposições do modelo CRM, “nível de luz constante" (light level
constant) e "nenhum choque detectado" (no shock detected) devem ser diretamente
monitorados via eventos ou dados estatísticos recolhidos pelo sistema. Se uma das
suposições se tornar falsa, por exemplo, se o sensor do robô detectar um choque
externo, então, a falsidade da suposição se propagaria em direção à suposição raiz
(neste modelo CRM seria a suposição “sem risco de tropeço” - no tripping hazard),
então a suposição se tornaria falsa. Do mesmo modo, um aumento repentino no
nível de luz indica que uma luz foi acesa por um ocupante.
28
Com um meio de verificação em tempo de execução para a hipótese “No
tripping hazard" ter sido satisfeita, o robô aspirador de pó pode usar a estratégia
limpar durante a noite, a menos que um choque seja detectado ou uma luz é ligada,
neste caso o robô deve auto-adaptar e usar a estratégia limpar quando estiver vazio.
No entanto, depois de ter estado em funcionamento há algum tempo, os donos do
robô notaram que ele está consumindo mais do que o esperado. A capacidade de
self-explanation significaria que o aspirador de pó poderia explicar que foi necessário
limpar durante o dia, porque os ocupantes frequentemente acordavam e acendiam
as luzes durante a noite.
Os donos entenderam a razão pela qual o robô tomou certa decisão, mas
estão insatisfeitos porque o custo ficou muito alto. Então eles enviaram uma
solicitação de mudança para o desenvolvedor para que o robô fosse alterado para
que ele só adotasse a estratégia de limpar quando estiver vazio se a tentativa de
limpeza de duas noites consecutivas fosse interrompida. Isoladamente, o pedido de
mudança pode parecer sem importância para os desenvolvedores, especialmente se
o pedido de alteração foi escasso de explicações. Para contextualizar o pedido, eles
questionaram o aspirador de pó para determinar seu histórico de operação, com
especial atenção à sua história de auto-adaptação
A auto-explicação é importante porque fornece um meio para aumentar a
confiança e resolver questões sobre o comportamento de um sistema autoadaptativo por seus usuários. A auto-explicação também pode ajudar os
desenvolvedores no entendimento do comportamento de um sistema autoadaptativo, realizando um rastreamento do comportamento observado em tempo de
execução para as suposições feitas em tempo de design [7].
3.6 RELAX
RELAX é uma linguagem natural estruturada que inclui operadores projetados
especificamente para capturar a incerteza. O foco em RELAX é sobre os requisitos
estruturados em linguagem natural. Normalmente, os requisitos textuais prescrevem
o comportamento usando um verbo modal, como “SHALL” ou “Will” (deve) que
define ações ou funcionalidades que um sistema deve sempre proporcionar. Para os
29
sistemas auto-adaptativos, no entanto, a incerteza do ambiente pode significar que
nem sempre é possível atingir todas as declarações SHALL ou as incertezas
comportamentais pode permitir trocas entre declarações SHALL para “relaxar”
declarações não-críticas em favor de outras mais críticas. Os operadores RELAX
são projetados para permitir que os engenheiros de requisitos possam identificar
explicitamente os requisitos que nunca deve mudar (invariantes), bem como os
requisitos que um sistema pode relaxar temporariamente sob certas condições.
RELAX também pode ser usado para especificar restrições sobre a forma como
esses requisitos podem ser relaxados.
3.6.1 RELAX Vocabulary
A tabela 2 traz o conjunto de operadores RELAX, organizados em modal,
temporal, operador ordinal e fatores de incerteza. Note que RELAX inclui operadores
padrões da lógica temporal, como, “Eventualmente” (Eventually), e “Até” (Until).
Cada um dos operadores RELAX definem restrições sobre como um requisito
pode ser “relaxado” em tempo de execução. Além disso, é importante indicar que
fatores de incerteza garante um abrandamento destas exigências, requerendo,
assim, um comportamento adaptativo. Esta informação é especificada usando as
palavras chaves: MON - Monitor (monitor), ENV - Environment (ambiente), REL Relationship (relacionamento) e DEP - Dependency (dependência). As propriedades
do ambiente capturam o "estado do mundo", ou seja, as características do contexto
de operação do sistema. Muitas vezes, no entanto, as propriedades ambientais não
podem ser monitoradas diretamente porque elas não são observáveis. A palavra
chave “MON” é usada para definir as propriedades que são diretamente observáveis
e que podem contribuir para a informação no sentido de determinar o estado do
ambiente. RELAX é utilizado na fase de requisitos do software, uma vez que as
restrições de hardware já foram definidas. Em particular, os sensores físicos
(denotados por MON) são assumidos como conhecido.
30
Tabela 2: Operadores da Linguagem RELAX.
Operadores RELAX
Descrição
Operadores Modais
SHALL
Um requisito deve permanecer ativo
MAY ... OR
Um requisito especifica uma ou mais alternativas
Operadores Temporais
Eventually
Um requisito deve permanecer eventualmente
Until
Um requisito deve permanecer até uma futura posição
Um requisito deve permanecer antes ou após um evento
Before, After
particular
Um requisito deve permanecer durante um particular intervalo
In
de tempo
Um requisito especifica algo que deve permanecer o mais rápido
As Early, Late as Possible
possível ou deve ser atrasado tanto quanto possível
As Close as Possible to Um requisito especifica algo que acontece repetidamente, mas a
[frequência]
frequência pode ser relaxada
Operadores Ordinais
As Close as Possible to Um requisito especifica uma quantidade contável, mas o
[quantidade]
número exato pode ser relaxado
Um requisito especifica uma quantidade contável, mas o
As Many, Few as Possible
número exato pode ser relaxado
Fatores de Incertezas
Define um conjunto de propriedades que explicam o ambiente
ENV
do sistema
Define um conjunto de propriedades que podem ser
MON
monitorados pelo sistema
REL
Define a relação entre as propriedades ENV e MON
Identifica as dependências entre os requisitos (relaxados e
DEP
invariantes)
A palavra chave “REL” é usada para especificar de que forma “os dados
observáveis” (fornecidos pelo MON) podem ser utilizados para obter informações
31
sobre o ambiente (fornecidos por ENV). A distinção entre ENV e MON é explicado
pela Teoria de controle na qual os parâmetros a serem estimados podem não
necessariamente ser observados diretamente. “REL” é usado para definir a forma de
calcular a posição das medições de distância. Finalmente requisitos
de
dependências são delimitados por “DEP”, pois são importantes para avaliar o
impacto sobre os requisitos dependentes após o “relaxamento” de um determinado
requisito.
32
4. Modelos para o Desenvolvimento de Sistemas AutoAdaptativos
Entre
as
muitas
propostas
destinadas
a
orientar
os
analistas
e
desenvolvedores na construção de sistemas auto-adaptativos, algumas focam em
modelos arquiteturais que capturam variabilidade da arquitetura e apoiam as
reconfigurações arquiteturais propagando os efeitos para o sistema real em resposta
a determinadas situações. Em vez disso, outras abordagens, defendem o uso de
modelos de requisitos para capturar a variabilidade e o suporte de adaptação [16].
4.1 Modelos Orientados a Requisitos
Modelos baseados em requisitos estendem as técnicas da engenharia de
requisitos, a fim de representar os requisitos de adaptação e/ou a incerteza inerente
ao ambiente em que o sistema opera. Estas abordagens podem ou não incluir
mecanismos de percepção (awareness), de tempo de execução e os frameworks
que operacionalizam os requisitos de adaptação, uma vez que eles se concentram
em capturar e analisar o problema em vez da implementação de soluções.
4.1.1 Zanshin
Zanshin é um método e um framework baseado em Engenharia de Requisitos
para a construção de sistemas que explora conceitos da Teoria de Controle (Control
Theory) para projetar sistemas de software adaptativos. Uma visão geral da
abordagem é mostrada na figura 11.
33
Figura 11: Visão Geral da abordagem Zanshin.
A abordagem é dividida em duas etapas principais que estendem "Vanilla" a
Engenharia de Requisitos Orientada a Objetivos (Goal-Oriented Requirements
Engineering - GORE) com técnicas de Engenharia de Requisitos (ER) que são
designadas especificamente com os requisitos de adaptação. Inspirado pela Teoria
de Controle, Zanshin suporta Sistema de Identificação (System Identification) para o
sistema de destino, a fim de identificar: (a) indicadores importantes e os respectivos
valores que o sistema deve se esforçar para manter, (b) os parâmetros que podem
ser ajustados em tempo de execução para mudar o comportamento do sistema; e (c)
como a alteração de parâmetros afeta o valor dos indicadores [13].
Indicadores
são
limitados
por
requisitos
de
percepção
(Awareness
Requirements – AwReqs. AwReqs representam situações em que os stakeholders
gostariam que o sistema se adaptasse. Dessa forma, eles constituem os requisitos
para o componente de monitoramento (feedback loop) que implementa as
capacidades adaptativas do sistema. Os parâmetros podem assumir dois estados:
Pontos de Variação (Variation Points), que são refinamentos OU (OR) já presentes
nos modelos orientados a objetivos, e Variáveis de Controle (Control Variables) que
são abstrações sobre os refinamentos OU que são muito complexos ou entediantes
para modelar.
A Especificação da Estratégia (Strategy Specification) concentra-se na parte
de adaptação do feedback loop. Seu objetivo é associar uma ou mais estratégias de
34
adaptação (por exemplo, "repetir / delegar uma tarefa", "relaxe um requisito", etc.) a
cada AwReq, a fim de tê-los executados em caso de uma falha em tempo de
execução. Estas estratégias devem também ser obtidas a partir dos stakeholders e
são representados pela Evolução de Requisitos (Evolution Requirements EvoReqs). EvoReqs prescrevem como outros requisitos do modelo deve evoluir em
resposta a uma falha AwReq, e são especificados usando um conjunto de
operações primitivas, em que cada uma está associada a ações de aplicações
específicas a serem implementadas no sistema. Uma estratégia em particular, a
Estratégia de Reconfiguração (Reconfiguration Strategy) utiliza as informações
solicitadas durante a Identificação do Sistema para reconfigurar o sistema,
permitindo também que os designers especifiquem diferentes algoritmos de
reconfiguração, dependendo da quantidade de informação disponível.
4.2 Modelos Orientados a Arquitetura
Modelos baseados em arquitetura concentram-se em ajudar os designers a
construir arquiteturas que suportam a adaptação. Eles costumam propor a utilização
de um modelo de arquitetura que mostram os componentes do sistema e como eles
se comunicam entre si através de conectores. Essas propostas incluem geralmente
a infraestrutura do software em tempo de execução sobre a qual é construído o
sistema adaptativo, com atenção nas regras de adaptação e como evoluir os
modelos.
4.2.1 Rainbow
O framework Rainbow é uma abordagem baseada em arquitetura para a
construção de sistemas adaptativos. De acordo com a proposta, as regras de
adaptação são usadas para monitorar as condições operacionais do sistema e
definir ações a serem tomadas se as condições forem desfavoráveis. Por exemplo,
dado um site de notícias, se os tempos de respostas medidos são muito altos, ações
como ativar mais servidores ou mudar do modo multimídia para o modo textual pode
ser executado para tentar melhorar o tempo de resposta. A figura 12 mostra
elementos que compõe o framework Rainbow.
35
Figura 12: Componentes do Framework Rainbow.
O monitoramento é feito com um conjunto de sondas (Probes) implantadas no
sistema de destino (Target System), que enviam observações para os medidores
(Gauges) que interpretam as medições das sondas em termos de modelos de alto
nível. O Gerenciador de Modelo (Model Manager) é responsável por rastrear as
mudanças dos estados do modelo e mantê-lo consistente com o sistema. Além
disso, outros componentes consultam o gerenciador para obter informações sobre o
estado atual do modelo.
Outro componente é o Avaliador de Arquitetura (Architecture Evaluator) que
detecta alterações das propriedades da arquitetura do sistema e do ambiente,
validando tais modificações no que diz respeito às restrições indicadas no modelo.
No caso de uma violação, ele aciona o Gerenciador de Adaptação (Adaptation
Manager) para que ele possa selecionar a estratégia mais adequada, utilizando
Teoria da Utilidade (Utility Theory) para a decisão. Finalmente, o Executor de
Estratégia (Strategy Executor) coordena o processo de execução, decidindo quais os
operadores devem ser aplicados através dos “Efetores” (Effectors) na camada do
sistema (System Layer).
36
Para a parte final do ciclo de adaptação, Rainbow usa uma linguagem
chamada Stitch, que captura o conhecimento da rotina de adaptação humana como
políticas de adaptação explícitas. A linguagem permite que os designers especifique
o quê, quando e como adaptar, automatizando assim o processo de adaptação.
4.3 Derivação de Modelos
Através da realização de um estudo comparativo, os autores em [9]
concluíram que as abordagens baseadas em requisitos e arquitetura para softwares
adaptativos compartilham elementos comuns, tais como o uso de feedback loops e
de mecanismos de controle. No entanto, existem diferenças que revelam vantagens
e desvantagens das duas abordagens.
Os autores propõe uma metodologia de orientação para derivar modelos de
arquitetura a partir do modelo de requisitos. Este esforço resultaria em uma
especificação mais apropriada para um sistema de software adaptativo, uma vez que
todo o espectro da sua variabilidade operacional seria representado, portanto, o
sistema teria a máxima variedade de alternativas quando tem que lidar com falhas
ou alterações do ambiente.
Derivação Arquitetural está preocupada com a geração de modelos de
arquitetura, que podem incluir: componentes e modelos de conectores para
descrever a estrutura do sistema; statecharts (diagramas de estados) para descrever
o comportamento do sistema; modelo de features (características) para expressar a
variabilidade do sistema, e assim por diante. Estes diferentes modelos são
complementares, cada um captura uma visão particular do sistema que está sendo
projetado. Assim, diferentes abordagens são requeridas a fim de derivar os
diferentes modelos.
Quando se considera a derivação de arquitetura e suas decisões de design
para o caso particular de sistemas adaptativos, há três preocupações que devem ser
consideradas:
a)
Variabilidade adicional - pode haver diferentes alternativas para
realizar uma determinada tarefa. Por exemplo, algoritmos diferentes podem
37
ser utilizados para marcar uma reunião automaticamente, cada um com as
suas diferentes vantagens e desvantagens. As alternativas identificadas
durante a derivação da arquitetura irá expandir o espaço de possibilidades de
adaptação.
b)
Elementos de controle adicionais - além de se referir aos
conceitos de requisitos, elementos Zanshin (como AwReqs e Variáveis de
controle) também podem referir-se e influenciar as elementos da arquitetura.
Por exemplo, o intervalo de tempo cronometrado para uma transição pode ser
definido como uma variável de controle, em vez de um pré-definido intervalo
estático.
c)
Os recursos adicionais para apoiar a adaptação - o apoio da
auto-adaptação pode exigir a inclusão de novas funcionalidades no sistema.
Este é o caso, por exemplo, quando o sistema requer algum tipo de
instrumentação de forma a monitorar a satisfação dos AwReqs.
4.3.1 Derivação de Statecharts
O processo para derivar statecharts (gráfico de estados) de modelos de
requisitos compreende seis passos, ilustrados na figura 13. O primeiro passo,
“Delegar tarefas” (Delegate tasks), consiste em atribuir as tarefas que não serão
executadas nem suportadas pelo sistema adequadamente - por exemplo, as tarefas
que serão executadas por um agente externo (humanos ou não). Uma vez que estas
funções não são realizadas pelo próprio sistema de software, elas não devem ser
consideradas durante o restante do processo. No passo seguinte, “Definir fluxo
básico” (Define basic flow), o arquiteto analisa todos os refinamentos do modelo de
objetivos e define uma expressão de fluxo para cada um. Estas expressões de fluxo
serão usadas no próximo passo, “Gerar base do statechart” (Generate base
statechart), para criar um esqueleto. Uma vez que estas expressões não são tão
significativas quanto statecharts (embora rico o suficiente para definir o fluxo básico),
e podem ser incluídas como anotações em um modelo objetivo, elas são uma
abstração intermediária útil entre os modelos de requisitos e statecharts.
38
Figura 13: Passos necessários para derivação do
statechart.
Nos passos restantes do statechart será refinado como se segue. Primeiro,
durante o passo “Especificar transições” (Specify transitions) o arquiteto define os
eventos e condições das transições derivadas. Em seguida, o statechart é
“enriquecido para descrever o comportamento de adaptabilidade do sistema”
(Improve requirements), incluindo a interação com um componente externo que
fornece funcionalidade relacionada à adaptação. Isto ocorre durante a fase
“Especificar o comportamento adaptativo” (Specify adaptive behavior). Como último
passo, a fase “Realizar mais refinamentos” (Perform further refinements) permite ao
arquiteto expandir o modelo para incluir detalhes técnicos e outros aspectos que
podem não ter sido tratados anteriormente, explorando o conceito de sub-estados.
39
5. Considerações Finais
A ideia e a necessidade de um sistema auto-adaptativo não é nova [12]. A
grande diversidade de hardware e software dentro ou fora de uma empresa em que
um sistema tem de interagir é enorme. Cada vez que um sistema se deparava com
um cenário diferente (hardware de diferentes plataformas, software em diversas
linguagens) os desenvolvedores tinham que customiza-lo para que ele pudesse
funcionar naquele ambiente. Isso trazia e ainda traz grande custo para as empresas.
A incerteza parece ser a chave principal da abordagem de sistemas autoadaptativos. O profissional que deseja desenvolver um sistema auto-adaptativo
precisa trabalhar com a incerteza do ambiente no qual o software será implantado,
desta forma ele pensará nos elementos que o software deve ter pra tentar atender
um ambiente não completamente conhecido.
A fase atual da abordagem de sistemas auto-adaptativo está bem avançada,
mas ainda é preciso padronizar alguns aspectos e comprovar a eficácia de outros
para que assim a abordagem seja utilizada por todos os profissionais que tenham a
necessidade de um sistema com características auto-adaptativas.
Neste trabalho discutimos sobre os sistemas auto-adaptativos, definimos o
que seria um sistema auto-adaptativo e o porquê desenvolver este tipo de sistema.
Em seguida abordamos os principais aspectos que foram e estão sendo amplamente
discutidos e preconizados pela comunidade de Engenharia de Software aqui no
Brasil e no mundo, entre estes aspectos podemos citar: feedback control loop,
awareness requirement, uncertainty e etc. Outro importante tópico abordado foram
os modelos de requisitos e de arquitetura que estão sendo propostos para auxiliar o
desenvolvimento dos sistemas auto-adaptativos, discutimos sobre o Zanshin
(modelo orientado a requisitos) e o Rainbow (modelo orientado a arquitetura). Para
finalizar abordamos como realizar a derivação destes modelos através dos trabalhos
propostos por pesquisadores da área [16] [17].
40
6. Referências
[1] B. H. C. Cheng et al., “Software Engineering for Self-Adaptive Systems: A Research
Roadmap,” in Software Engineering for Self-Adaptive Systems, ser. Lecture Notes in
Computer Science, B. H. C. Cheng, R. de Lemos, H. Giese,P. Inverardi, and J. Magee, Eds.
Springer, 2009, vol. 5525,pp. 1–26.
[2] Lemos, R.d., Giese, H., Muller, H.A., Shaw, M., Andersson, J., Baresi, L., Becker, B.,
Bencomo, N., Brun, Y., Cikic, B., Desmarais, R., Dustdar, S., Engels, G., Geihs, K.,
Goeschka, K.M., Gorla, A., Grassi, V., Inverardi, P., Karsai, G., Kramer, J., Litoiu, M., Lopes,
A., Magee, J., Malek, S., Mankovskii, S., Mirandola, R., Mylopoulos, J., Nierstrasz, O., Pezze,
M., Prehofer, C., Schafer, W., Schlichting, W., Schmerl, B., Smith, D.B., Sousa, J.P., Tamura,
G., Tahvildari, L., Villegas, N.M., Vogel, T., Weyns, D., Wong, K., Wuttke, J.: “Software
engineering for Self-Adpaptive systems: A second research roadmap”. In Lemos, R.d., Giese,
H., Muller, H., Shaw, M., eds.: Software Engineering for Self-Adaptive Systems, Dagstuhl,
Germany (2011).
[3] Nauman A. Qureshi, Anna Perini: “Engineering adaptive requirements”. SEAMS 2009: 126131.
[4] V. Silva Souza. “A requirements-based approach for the design of adaptive systems”. In
34th International Conference on Software Engineering. - ICSE, 1635–1637, 2012.
[5] Silvia Ingolfo, Vítor Estêvão Silva Souza: “Law and adaptivity in requirements
engineering.”,, In: Proc. of the 8th International Symposium on Software Engineering for
Adaptive and Self-Managing Systems. (2013) 163-168.
[6] Vítor Estêvão Silva Souza, Renata S. S. Guizzardi: “Usando Modelos de Requisito em
Tempo de Execução: Potencial e Desafios.”, In 21st IEEE International Requirements
Engineering Conference. ER@BR (2013).
[7] Nelly Bencomo, Kristopher Welsh, Pete Sawyer, Jon Whittle: “Self-Explanation in Adaptive
Systems.”, In 17th IEEE International Conference on Engineering of Complex Computer
Systems ICECCS 2012: 157-166.
[8] Kristopher Welsh, Peter Sawyer: “Understanding the Scope of Uncertainty in Dynamically
Adaptive Systems.”, In The 16th International Working Conference on Requirements
Engineering. REFSQ 2010: 2-16.
41
[9] João Pimentel, Jaelson Castro, Emanuel Santos, Monique Soares, Jéssyka Vilela,
Gabriela Guedes: “Requirements and Architectures for Adaptive Systems.”, In 21st IEEE
International Requirements Engineering Conference. ER@BR (2013).
[10] João Pimentel, Konstantinos Angelopoulos, Vítor Estêvão Silva Souza, John Mylopoulos,
Jaelson Castro, “From Requirements to Architectures for Better Adaptive Software Systems.”,
iStar 2013: 91-96
[11] K. Welsh and P. Sawyer, “When to adapt? identification of problem domains for adaptive
systems.”, In Requirements Engineering Foundations for Software Quality (REFSQ), 2008.
[12] Markus Luckey, Gregor Engels: “High-quality specification of self-adaptive software
systems.”, In: Proc. of the 8th International Symposium on Software Engineering for Adaptive
and Self-Managing Systems. (2013) 143-152.
[13] Peng, Qian., “Issues in Specifying Requirements for Adaptive Software Systems.”,
Studente thesis of Växjö University. (2009).
[14] J. Pimentel, J. Castro, X. Franch, “Specification of Failure-Handling Requirements as
Policy Rules on Self-Adaptive Systems,” Proceedings of the 14th Workshop on Requirements
Engineering (WER 2011),Brazil, 2011, in press.
[15] Pimentel, J., Castro, J., Perrelli, H., Santos, E., Franch, X.: “Towards anticipating
requirements changes through studies of the future.”, In: 5th International Conference on
Research Challenges in Information Science, IEEE (May 2011) 1-11.
[16] Tallabaci, G., Souza, V.E.S.: “Engineering Adaptation with Zanshin: an Experience
Report.”, In: Proc. of the 8th International Symposium on Software Engineering for Adaptive
and Self-Managing Systems. (2013).
[17] Angelopoulos, K., Souza, V.E.S., Pimentel, J., “Requirements and Architectural
Approaches to Adaptive Software Systems: A Comparative Study.”, In: Proc. of the 8th
International Symposium on Software Engineering for Adaptive and Self-Managing Systems.
(2013)
[18] V. E. S. Souza, A. Lapouchnian, W. N. Robinson, and J. Mylopoulos, “Awareness
Requirements for Adaptive Systems,” in Proc. of the 6th International Symposium on Software
Engineering for Adaptive and Self-Managing Systems. ACM, 2011, pp. 60–69.
[19] N. A. Qureshi and A. Perini, “Engineering Adaptive Requirements,” in Proc. of the 2009
ICSE Workshop on Software Engineering for Adaptive and Self-Managing Systems. IEEE,
2009, pp. 126–131.
[20] J. Whittle, P. Sawyer, N. Bencomo, B. H. C. Cheng, and J.-M. Bruel, “RELAX:
Incorporating Uncertainty into the Specification of Self-Adaptive Systems,” in Proc. of the 17th
IEEE International Requirements Engineering Conference. IEEE, 2009, pp. 79–88.
42
[21] D. Berry, B. Cheng, and J. Zhang, “The four levels of requirements engineering for and in
dynamic adaptive systems,” in 11th International Workshop on Requirements Engineering:
Foundation for Software Quality (REFSQ’05), Porto, Portugal, 2005.
[22] Lapouchnian, Alexei, "Goal-Oriented Requirements Engineering: An Overview of the
Current Research", University Of Toronto. (2005).
[23] Thanos, Christian, "Control Loops Current Trends for Self-* Systems", University of
Paderborn.
[24] Vromant, P., Weyns, D., Malek, S., Andersson, J., "On Interacting Control Loops in SelfAdaptive Systems", SEAMS (2011).
[25] Esfahani, N., Malek, S., "Uncertainty in Self-Adaptive Software Systems", Software
Engineering for Self-Adaptive Systems II (2013). 214-238.