[1] O documento apresenta uma proposta de arquitetura de software auto-reconfigurável utilizando middleware reflexivo e motor de regras. [2] A arquitetura proposta permite que o sistema reaja ou antecipe situações desfavoráveis de forma pouco invasiva aos componentes de negócio. [3] O documento descreve os fundamentos conceituais, estado da arte, proposta arquitetural e um exemplo de experimento para validar a arquitetura proposta.

1. Arquitetura de software auto-
reconfigurável utilizando
Middleware reflexivo e motor de
regras
João Henrique Victorino
Orientador: Prof. Dr. Julio Arakaki

2. Estrutura de apresentação
• Motivação
• Objetivo
• Resultados esperados e contribuições
• Método de trabalho
• Fundamentos conceituais
• Estado da arte
• Proposta de uma arquitetura auto-adaptativa
• Exemplo de uma arquitetura auto-adaptativa
• Análise dos resultados
• Conclusão

3. Motivação
• Software mais complexo e que exigem maior
conhecimento dos seus administradores
(Garcia, et al., 2011)
• Falhas por erro humano (Neti & Müller, 2007)
• As duas maiores dificuldades, os pontos de
variabilidade do sistema para a reconfiguração
em tempo de execução e a tomada de decisão
que o sistema deve executar sobre as
reconfigurações (CYBENKO, BEHRE, et al.,
2006)

4. Objetivo
• Arquitetura auto-reconfigurável
• Reagir ou até antecipar situações desfavoráveis
• Pouco invasiva aos componentes de negócio
• Implementar a auto-reconfiguração através da
flexibilidade do contêiner de inversão de
dependência, da monitoração facilitada pela
programação orientada a aspectos e da análise e
tomada de decisão suportada por um motor de
regras

5. Resultados esperados e contribuições
• Obtenção de um modelo arquitetural auto-
reconfigurável pouco invasivo aos
componentes
• Evitar comportamento inesperado da
aplicação em virtude da combinação de
componentes em tempo de execução
• Melhorar o tempo de resposta do software a
mudanças no ambiente

6. Método de trabalho

7. Fundamentos conceituais
• Sistemas autônomos e computação
autonômica
• Arquitetura de software
• Requisitos não-funcionais
• Auto-reconfiguração
– Ciclo de controle do processamento
– Monitoração
– Análise e decisão
– Reconfiguração

8. Sistemas autônomos e computação
autonômica
• Sistemas que adaptam-se conforme a
necessidade utilizando um processo para isso,
e contando com pouca ou nenhuma
intervenção humana (Ertle, et al., 2010) e
(Huang, et al., 2004)
• Software autônomo não é algo novo na área
da robótica e IA (Kramer & Magee, 2007)

9. Níveis de autonomia
Evolução da autonomia em sistemas
Adaptado de (MULLER, O'BRIEN, et al., 2006)

10. Sistemas autônomos e computação
autonômica
Modelo técnico da computação autonômica
Fonte: (Huang, et al., 2004)

11. Arquitetura de software
• Uma estrutura, decomposta em partes, na
relação entre elas e nas propriedades visíveis
externamente que essas partes apresentam
(Bass, et al., 2003)
• É a junção de todos os componentes, que fazem
parte da arquitetura, que determinam se um
sistema atende a um determinado requisito
(BRAT, DENNEY, et al., 2006).
• Os atributos de qualidade da arquitetura são
alcançados através das táticas arquiteturais, que
são as decisões de modelagem da arquitetura
(Bass, et al., 2003)

12. Requisitos não-funcionais
• RNF e RF são definidores e validadores da
arquitetura de software (Bass, et al., 2003)
• Decisões arquiteturais impactam diretamente
na autonomia do software (Fuad &
Oudshoorn, 2007)
• Software autônomo necessita de alguns RNFs
que outros softwares não necessitam, pois são
mais dinâmicos (Neti & Müller, 2007)

13. Requisitos não-funcionais
• O atributo de qualidade mais importante para
um sistema auto-reconfigurável é a facilidade
de alteração, que está subdividido na
capacidade do sistemas em ser extendido e
em ser modificado, pois estes sistemas
precisam estar componentizados em
pequenas partes em virtude da necessidade
de dinamismo (NETI e MÜLLER, 2007)

14. Ciclo de controle do processamento
Ciclo de controle em sistemas autonômicos
Fonte: (Brun, et al., 2009)

15. Ciclo de controle do processamento
Ciclo MAPE
Fonte: elaborado pelo autor

16. Monitoração
• Qual informação é mais relevante para o
comportamento que deseja-se obter do
software? (Vassev & Hinchey, 2010)
• A monitoração deve ser simples e rápida para
que não afete a modelagem e o desempenho
do software, também deve prover informação
atualizada (Zheng, 2010)
• Requisito transversal

17. Monitoração
Requisitos transversais
Fonte: (Ju & Bo, 2007)

18. Monitoração
AOP (Aspect Oriented Programming) é uma
técnica capaz se separar os requisitos
transversais dos outros módulos, de modo
que o código fique modularizado e permite
que cada funcionalidade fique concentrada
onde deve e não espalhada pelo software (Ju
& Bo, 2007)

19. Análise e decisão
• Para alguns softwares a maior dificuldade é
saber qual é o estado desejado, e caso este
estado seja claro, saber quais modificações na
arquitetura são necessárias para que o
software deixe do estado atual e para o
estado desejado (Kramer & Magee, 2007)
• Este tipo de controle pode ser implementado
por regras (Vassev & Hinchey, 2010)

20. Análise e decisão
IF (TempoResposta > 2 seg) THEN (Aumentar CPU em 5%)

21. Análise e decisão
Motor de regras:
• É uma DSL (Domain Specific Language) própria
para regras e extensível
• Pode ser modelada por uma ferramenta visual
• A idéia de motor de regras é externalizar a
lógica de negócio, o motor de regras pode ser
visto como um sofisticado interpretador de
declarações IF-THEN (CHEN, XU-PENG e
ZHENG-QIU, 2010).

22. Análise e decisão
Elementos de um motor de regras
Adaptado de (CHENG, LEMOS, et al., 2009)

23. Reconfiguração
Tipos:
• Sistêmica ou infraestrutura
• Aplicacional
– Parametrização
– Componentização
– Arquitetural

24. Reconfiguração
Componentização:
• Implementação passiva de um conjunto de
funcionalidades com uma interface específica,
e que passa a ter algum tipo atividade quando
um processo o executa, sendo um processo
uma representação dos recursos físicos de
CPU (Central Process Unit) e memória (Bellur
& Narendra, 2006)

25. Reconfiguração
• Contêiner de injeção de dependência
– Controle a execução dos componentes;
– Mapeamento dos componentes;
– Mantém o estado da aplicação consistente pois
varia entre diferentes tipos de árvores de objetos;

26. Reconfiguração
Árvore de componentes de uma arquitetura
Fonte: Elaborado pelo autor

27. Middleware reflexivo
Middleware Reflexivo é a união das habilidades
da computação distribuída e a capacidade de
reconfiguração, em tempo de execução, que a
reflexão proporciona (Garcia, et al., 2011)

28. Middleware reflexivo
Modelo técnico da computação reflexiva
Fonte: (Huang, et al., 2004)

29. Estado da arte
• Meehan, Prasad e Mcginnity, 2007. ADAF
Framework que trouxe mais complexidade,
pois os componentes podem ser trocados
dinamicamente e isoladamente.
• Bellur e Narendra, 2006. Uma arquitetura que
consegue carregar componentes de um
repositório.
• Zhang, Qu e Liu, 2006.
• Palma, Popov et al., 2009. Arquitetura de
reconfiguração na infraestrutura e não na
solução.

30. Estado da arte
• Calinescu, 2007. Utiliza MDA, onde na
modelagem são definidos os requisitos de
reconfiguração, porém não fica claro se poderá
ser feita uma reconfiguração em tempo de
execução.
• Ju e Bo, 2007. Arquitetura de serviços
reconfiguráveis com IoC e AOP, porém as
reconfigurações não são feitas em tempo de
execução.
• Wu, Wu et al., 2010. Framework Fractal, onde o
sistema legado precisou ser refatorado para
alcançar maior autonomia.

31. Arquitetura de software reconfigurável
• Requisitos funcionais, não funcionais e
técnicos que definem uma solução
arquitetural (CORDEIRO MARTINS, 2010)
• A auto-reconfiguração é um estilo
arquitetural, e como tal, deve vir a partir das
necessidades de negócio.
• ISO 9126 (lista de atributos de qualidade para
produtos e serviços)
• Manutenibilidade (Modificabilidade e
gerenciabilidade (PARASHAR e HARIRI, 2007))

32. Arquitetura de software reconfigurável
• Maior benefício é durante a operação do
software, devido as alterações de
comportamento do mesmo, conforme o
ambiente e sem supervisão.
• Reconfiguração funcional e arquitetural
(PARASHAR e HARIRI, 2007)
• Requisitos não funcionais devem ser levados em
consideração em virtude da reconfiguração,
como, transação, concorrência, segurança, entre
outros.
• Extensibilidade em tempo de execução e
naturalmente em tempo de modelagem.

33. Pontos de variabilidade
• Um ponto de variabilidade é uma conexão ou a
dependência entre componentes em uma sequência
de execução onde a reconfiguração pode ser acionada
(BELLUR e NARENDRA, 2006).
• Os pontos de variabilidade dependerão de quais
requisitos funcionais e não funcionais serão alterados
durante a reconfiguração, pois alguns requisitos podem
ser atingidos apenas alterando o pool de threads do
servidor web, ou poderá ser necessária a substituição
de um componente da aplicação, estes tipos de
reconfiguração podem ser feitas no nível de sistema,
como uma parametrização de infraestrutura, ou no
nível aplicacional como a parametrização ou
substituição de um componente da aplicação (ZHANG,
QU e LIU, 2006).

34. Pontos de variabilidade
• Linguagens, padrões, frameworks e arquiteturas foram
desenvolvidos para facilitar a reconfiguração, entretanto
estas técnicas necessitam que o sistema seja modelado já
pensando nos pontos de variabilidade que terá, pois o
sistema não conseguirá lidar com isso dinamicamente
(BELLUR e NARENDRA, 2006).
• O uso de interfaces da programação orientada a objetos,
permite que diferentes componentes implementem a
mesma interface, desta forma os componentes são do
mesmo tipo, e existe um contrato de comunicação com
eles, definido pela interface, sendo assim ambos os
componentes podem ter comportamentos diferentes e
ainda sim serem facilmente substituídos, um pelo outro
(BELLUR e NARENDRA, 2006).

35. Granularidade de componentes
• A granularidade e a forma de modelagem dos
componentes afetam diretamente a
capacidade da arquitetura em se reconfigurar
• As estruturas baseadas em componentes
permitem uma reconfiguração dinâmica
altamente granular, sendo que este recurso
pode ser melhorado utilizando meta dados
(PALMA, POPOV, et al., 2009)

36. Granularidade de componentes
• A abstração permitirá que diferentes
implementações de componentes
comuniquem entre si, devendo apenas
respeitar a abstração, que no caso de uma
linguagem orientada a objetos podem ser as
interfaces (BELLUR e NARENDRA, 2006).
• Padrões de projeto e princípios de modelagem
como SOLID podem auxiliar na modelagem
componentizada tornar-se altamente granular.

37. SOLID
• Single-responsability principle (Princípio da
responsabilidade única)
• Open/closed principle (Princípio aberto/fechado)
• Liskov substituition principle (Princípio de
substituição de Liskov)
• Interface segregation principle (Princípio da
segregação de interfaces)
• Dependency inversion principle (Princípio da
inversão de dependência)

38. Desempenho X Reconfiguração
• Em uma arquitetura auto-reconfigurável, certos
requisitos não funcionais são trazidos com esta decisão,
como a facilidade de modificação que naturalmente
implica na maior complexidade no desenvolvimento do
software.
• O ciclo de processamento de monitoração, análise e
execução requer certo processamento e para minimizar
seus impactos no sistema que está sendo gerenciado,
este ciclo pode ser feito de forma assíncrona e paralela.
• As desvantagens da reconfiguração devem se pagar pelas
vantagens de aumento de escalabilidade e
disponibilidade.

39. Experimento
• Interpolador das curvas de risco e contábeis
da tesouraria do banco

40. Experimento
• As curvas são consumidas por inúmeros sistemas
do banco, desde traders até a área contábil,
sendo que os traders, ou seja as curvas de risco
de mercado tem prioridade nas requisições da
manhã, das 9h às 11h, e da noite, das 19h às 23h,
devido a abertura e fechamento do mercado;
• O serviço precisa ter alta disponibilidade e
responder as solicitações de interpolação em até
10 segundos para curvas de até 10 anos e que
sejam de risco de mercado, mesmo em situações
de sobrecarga de requisições, ou seja, até 150
requisições no mesmo minuto;

41. Experimento
• Os horários de pico podem solicitar até 400
requisições de interpolação em 5 minutos;
• Sistema atual está respondendo em cerca de
20 segundos a interpolação de curvas de 10
anos, em sobrecarga de requisições, ou seja,
até 150 requisições simultâneas no mesmo
minuto, sendo que não faz distinção entre os
tipos de curvas a serem interpoladas.

42. Experimento

43. Requisitos não funcionais
• Disponibilidade – o serviço deverá priorizar requisições
de risco de mercado ao invés de requisições de outras
áreas, e se manter disponível nos momentos de pico da
manhã, das 9h às 11h, e da noite, das 19h às 23h.
• Modificabilidade – o serviço deve suportar até 150
requisições no mesmo minuto e ainda interpolar uma
curva de 10 anos em no máximo 10 segundos, para
atingir o requisito de disponibilidade pode ser
necessário “desabilitar” a interpolação para outras
áreas e deixar apenas a interpolação disponível para a
área de risco de mercado.
• Desempenho – o serviço deve efetuar o cálculo em até
10 segundos para curvas de até 10 anos.

44. Táticas arquiteturais
• O serviço de cálculo não guardará estado entre
uma interpolação e outra, ou seja, não existe
compartilhamento de dados entre as
interpolações, seja do mesmo cliente ou de
outros clientes.
• Como não haverá compartilhamento dos dados,
o serviço poderá processar as requisições de
interpolação de forma paralelizada.
• O serviço poderá iniciar uma transação no
momento que a requisição chegar ao servidor e
finaliza-la quando a interpolação estiver completa
e a resposta for enviada ao cliente.

45. Táticas arquiteturais
• O serviço será monitorado a cada 2 segundos para
definir se o mesmo se encontra em uma situação de
sobrecarga, ou aumento gradativo de requisições, para
que uma ação de degeneração seja acionada.
• Para descobrir se o serviço está em uma situação de
alta demanda, podemos utilizar a quantidade de
requisições recebidas no último minuto e o tempo
máximo que o serviço está gastando para responder as
interpolações no último minuto.
• Em alta demanda as requisições da área de risco de
mercado devem ser privilegiadas e as outras
requisições podem ser desabilitadas, colocando a
aplicação em um estado de degeneração parcial com o
intuito de atender as requisições prioritárias.

46. Táticas arquiteturais
• Para que não haja perdas, é interessante que a
arquitetura consiga inferir que haverá um aumento de
demanda e degradar seu comportamento, antes que o
serviço falhe, ou o mais rápido possível assim que
detectado um aumento de demanda considerável.
• Quando iniciar a diminuição da demanda o serviço
deve voltar ao estado normal e atender a todas as
requisições igualmente, pois a degeneração fará com
que o software perca parte de sua qualidade, em
virtude dos requisitos não funcionais e funcionais que
não estarão disponíveis.

47. Projeto

48. Projeto (Configuração em baixa demanda)

49. Projeto (Configuração em alta demanda)

50. Implementação

51. Ambiente de infraestrutura do
experimento
• Ambiente Microsoft:
– Windows Server 2008 (Servidor)
– Windows 7 (Cliente)
– SQL Server 2012 (Banco de dados)
– IIS 7.5 (Servidor de aplicação)
– .Net Framework 4.0 (Máquina virtual)
– Visual Studio 2010 (Ambiente de desenvolvimento)

52. Frameworks de desenvolvimento .Net
• Microsoft Enterprise Library 5.0
– Unity (IoC)
– Unity Interception (AOP)
• WCF 4.0 (Windows Communication
Foundation)
• WF 4.0 (Workflow Foundation)
• Visual Studio 2010 Test Tools

53. Base de dados da arquitetura
• Garantia da entrega do pedido de
processamento
• Facilidade de reproduzir as chamadas, se
necessário
• Auditoria e segurança

54. Base de dados da arquitetura
* Foi utilizado o banco de dados SQL Server 2012 com a
configuração In-Memory OLTP

55. Unity Configuração

56. Unity Configuração

57. Regra em alta demanda

58. Regra em baixa demanda

59. Análise resultados em alta demanda

60. Análise resultados em alta demanda

61. Análise resultados em alta demanda

62. Análise resultados em baixa demanda

63. Análise resultados em baixa demanda

64. Análise resultados em baixa demanda

65. Conclusão
• Auto-reconfiguração e degradação
• Arquitetura e modelo para auto-
reconfiguração
• Inclusão gradual da auto-reconfiguração
• Melhora no desempenho, privilégio a um tipo
de requisição e aumento da disponibilidade
• Retorno ao estado normal na baixa demanda

66. Trabalhos futuros
• Única notação para reconfiguração e decisão
• Interface visual de manutenção e depuração
• Outras plataformas além da Microsoft
• Vantagens e desvantagens no uso em Cloud
• Uso em outras áreas de negócio
• Uso de IA no módulo de decisão

67. Experimento
http://selfadaptmiddleware.codeplex.com/
Versão atual do código fonte disponível em: