Instanciação e avaliação de um framework para a geração dinâmica de processos

Departmento de Informática e Matemática Aplicada Programa de Pós-Graduação em Sistemas e Computação

Mestrado Acadêmico em Sistemas e Computação

Instanciação e Avaliação de um Framework

para a Geração Dinâmica de Processos

Fernando Helton Linhares Soares

Instanciação e Avaliação de um Framework para a

Geração Dinâmica de Processos

Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas e Computação do Departamento de Informá-tica e MatemáInformá-tica Aplicada da Universidade Federal do Rio Grande do Norte como re-quisito parcial para a obtenção do grau de Mestre em Sistemas e Computação.

Linha de pesquisa:

Sistemas Integrados e Distribuídos

Orientador

Prof. Dr. Adilson Barboza Lopes

Co-orientador

Prof. Dr. Carlos Eduardo da Silva

PPgSC – Programa de Pós-Graduação em Sistemas e Computação DIMAp – Departamento de Informática e Matemática Aplicada

CCET – Centro de Ciências Exatas e da Terra UFRN – Universidade Federal do Rio Grande do Norte

Natal-RN

Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial Centro de Ciências Exatas e da Terra – CCET.

Soares, Fernando Helton Linhares.

Instanciação e avaliação de um framework para a geração dinâmica de processos / Fernando Helton Linhares Soares. - Natal, 2013.

95 f.: il.

Orientador: Prof. Dr. Adilson Barbosa Lopes. Co-orientador: Prof. Dr. Carlos Eduardo da Silva.

Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Programa de Pós-Graduação em Sistemas e Computação.

1. Sistemas distribuídos – Dissertação. 2. Sistemas autoadaptativos – Dissertação. 3. Geração dinâmica de processos – Dissertação. 4. Ambiente OSGi – Dissertação. I. Lopes, Adilson Barbosa. II. Silva, Carlos Eduardo da. III. Título.

Instanciação e Avaliação de um Fnamewonk pana a

Genação Dinâmica de Pnocessos

Esta Dissentação foi julgada adequada pana a obtenção do título de mestne em Sistemas e Computação e apnovado em sua fonma final pelo Pnognama de Pós-Gnadua-ção em Sistemas e ComputaPós-Gnadua-ção do Depantamento de Infonmática e Matemática Aplica-da Aplica-da UnivensiAplica-dade Fedenal do Fio Gnande do Nonte.

__________________________________________________________ Pnof. Dn. Adilson Banboza Lopes – UFFN

Onientadon

__________________________________________________________ Pnof. Dn. Mantin Alejandno Musicante – UFFN

Coondenadon do Pnognama

Banca Examinadora

___________________________________________________________ Pnof. Dn. Adilson Banboza Lopes – UFFN

Pnesidente

____________________________________________________________ Pnof. Dn. Canlos Eduando da Silva – UFFN

___________________________________________________________ Pnof. Dna. _{Thais Vasconcelos Batista – UFFN}

____________________________________________________________ Pnof. Dn. Faimundo José de Anaújo Macêdo – UFBA

Primeiramente a Deus, meu refúgio e força, que nunca me deixou desanimar diante das dificuldades. Mesmo em momentos de desespero, tem me dado calma e paciência para superar os desafios.

À minha esposa, Donátila, pelo apoio durante todo esse tempo. Por nunca me deixar sozinho, por me escutar e por brigar comigo quando foi preciso.

À minha Mãe, que apesar da distância nunca deixou de se mostrar presente. E à toda a minha família pelo apoio incondicional.

À Severino e família, por ter nos recebido em sua casa de braços abertos e nos tornar parte da sua família. E também à Francisco e sua família por todo apoio que vocês nos deram.

Aos meus orientadores, professores Adilson e Carlos Eduardo. Ao Adilson por ter me aceitado como aluno mesmo antes de me conhecer pessoalmente. Pelos conselhos e apoio durante todo este tempo. Ao Carlos Eduardo por todo o trabalho que teve comigo, todas as correções, sugestões e pelos "carões" dados na hora certa.

Ao meu amigãozão Adriano, pelo seu companheirismo desde o tempo da graduação. E também a Aline, pelas boas tardes de café e conversa quando o estresse do trabalho chegou a níveis muito altos.

mais sorte eu tenho."

Geração Dinâmica de Processos

Autor: Fernando Helton Linhares Soares Orientador: Prof. Dr. Adilson Barboza Lopes Co-orientador: Prof. Dr. Carlos Eduardo da Silva

Resumo

Uma forma de lidar com a elevada complexidade dos sistemas de software atuais é através de sistemas autoadaptativos. Sistema autoadaptativos devem ser capazes de monitorar a si mesmos e ao seu ambiente, analisar os dados monitorados para determinar a necessidade de adaptação, decidir como a adaptação será realizada e, por fim, realizar as adaptações necessárias. Uma das maneiras de realizar a adaptação de um sistema é gerar, em tempo de execução, o processo que irá executar a adaptação. Uma vantagem dessa abordagem é a possibilidade de levar em consideração características que só podem ser avaliadas em tempo de execução, como por exemplo, o surgimento de novos componentes que possibi-litem novos arranjos arquiteturais que não foram previstos em tempo de projeto. Neste trabalho, temos como principal objetivo a utilização de um framework de geração dinâ-mica de processos para gerar planos de adaptação arquiteturais sobre o ambiente OSGi. Nosso principal interesse consiste em verificar como esse framework de geração dinâmica de processos se comporta em novos ambientes.

Dynamic Process Generation

Author: Fernando Helton Linhares Soares Supervisor: Prof. Dr. Adilson Barboza Lopes Co-supervisor: Prof. Dr. Carlos Eduardo da Silva

Abstract

One way to deal with the high complexity of current software systems is through self-adaptive systems. Self-self-adaptive system must be able to monitor themselves and their environment, analyzing the monitored data to determine the need for adaptation, decide how the adaptation will be performed, and finally, make the necessary adjustments. One way to perform the adaptation of a system is generating, at runtime, the process that will perform the adaptation. One advantage of this approach is the possibility to take into account features that can only be evaluated at runtime, such as the emergence of new components that allow new architectural arrangements which were not foreseen at design time. In this work we have as main objective the use of a framework for dynamic generation of processes to generate architectural adaptation plans on OSGi environment. Our main interest is evaluate how this framework for dynamic generation of processes behave in new environments.

1 Feedback Control Loop (DOBSON et al._{, 2006)} . . . p. 16

2 Visão geral do processo de geração de processos (SILVA_{, 2011)} . . . p. 24

3 Fase Estratégica (SILVA, 2011) . . . p. 25

4 Fase tática (SILVA, 2011) . . . p. 26

5 Fase Operacional (SILVA, 2011) . . . p. 27

6 Camadas do Framework OSGi (ALLIANCE, 2009) . . . p. 30

7 Diagrama e Estados do Bundles (ALLIANCE, 2009) . . . p. 32

8 Metamodelo Específico de Domínio . . . p. 38

9 Implementação do template de tarefa Connect utilizando um diagrama YAWL p. 47

10 Arquitetura da Solução . . . p. 49

11 Configuração Abstrata do Comanche . . . p. 53

12 Exemplo de um Workflow Abstrato para Estabelecer a Configuração Abstrata

Apresentada na Figura 11 . . . p. 58

13 Exemplo de Configuração Concreta para a Configuração Abstrata da Figura 11 p. 59

14 Exemplo de um Workflow Concreto . . . p. 60

15 Exemplo de um Workflow de Recuperação Gerado para Experimentos com

Recuperação na Fase Tática . . . p. 61

16 Exemplo de Configuração Concreta para a Configuração Abstrata da

Fi-gura 11 com Scheduler MultiThread. . . p. 62

17 Exemplo de um novo Workflow Concreto . . . p. 63

18 Mecanismo de Execução de Adaptações (FONSECA; BENEDITTO; WERNER_,

2012) . . . p. 67

2.1 Arquivo MANIFEST.MF . . . p. 31

2.2 Exemplo de BundleActivator . . . p. 33

2.3 Registrando um Serviço . . . p. 34

2.4 Recuperando um Serviço . . . p. 34

3.1 Representação XMI do Modelo de Domínio PDDL . . . p. 39

3.2 Modelo de Domínio PDDL. . . p. 40

3.3 Regras de Transformação . . . p. 43

3.4 XMI da especificação do template de tarefa Connect . . . p. 45

3.5 PDDL da tarefa Connect . . . p. 46

3.6 Modelo de template de tarefa Connect . . . p. 46

4.1 Especificação de Problema PDDL . . . p. 55

4.2 Plano de Adaptação Gerado . . . p. 57

A.1 Regras para transformar modelos arquiteturais em problemas de

planeja-mento PDDL . . . p. 79

B.1 XMI da configuração abstrata do Comanche . . . p. 85

C.1 XMI da configuração concreta do Comanche com Scheduler sequencial . . p. 88

Trabalho publicados em Workshops:

• Soares, F. H. L., Lopes, A.B. and Da Silva, C. E. Instanciação de um Framework

1 Introdução p. 15

1.1 Contexto . . . p. 16

1.2 Objetivos . . . p. 18

1.3 Estrutura do trabalho . . . p. 19

2 Fundamentação Teórica p. 20

2.1 Sistemas Autoadaptativos . . . p. 20

2.2 Framework de Geração Dinâmica de Processos . . . p. 22

2.2.1 Processo de Referência . . . p. 24

2.2.1.1 Fase Estratégica . . . p. 25

2.2.1.2 Fase Tática . . . p. 26

2.2.1.3 Fase Operacional . . . p. 27

2.2.2 Metodologia de Instanciação . . . p. 28

2.3 OSGi . . . p. 29

2.3.1 Bundles . . . p. 31

2.3.2 Serviços . . . p. 34

2.4 Sumário do Capítulo . . . p. 34

3 Instanciação do Framework de Geração de Processos p. 36

3.1 Metamodelo Específico de Domínio . . . p. 37

3.2 Modelo de Domínio PDDL . . . p. 39

3.5 Integrando o Framework de Geração de Processos com o ambiente OSGi p. 48

3.6 Sumário do Capítulo . . . p. 51

4 Prova de Conceito p. 52

4.1 Aplicação de Estudo de Caso Comanche . . . p. 52

4.2 Demostração do Processo de Reconfiguração . . . p. 54

4.2.1 Demonstração sem Exceção . . . p. 55

4.2.2 Demostração com Exceção - Recuperação na Fase Tática . . . . p. 61

4.3 Discussão . . . p. 64

4.4 Sumário do Capítulo . . . p. 65

5 Trabalhos Relacionados p. 66

6 Considerações finais p. 71

6.1 Contribuições . . . p. 72

6.2 Limitações . . . p. 73

6.3 Trabalho Futuros . . . p. 73

Referências p. 75

Apêndice A -- Regras de transformação p. 79

Apêndice B -- Configuração Abstrata do Comanche p. 85

Apêndice C -- Configuração Concreta do Comanche com Scheduler

Se-quencial p. 88

Apêndice D -- Configuração Concreta do Comanche com Scheduler

1

Introdução

Os sistemas de software atuais têm se tornado cada vez mais complexos. Segundo (CHENG; LEMOS; AL., 2009), isso se deve à contínua evolução de sistemas de software, que

estão cada vez mais pervasivos e distribuídos, e são integrados de diversas maneiras (p. ex., Internet e Web). Além disso, os sistemas de software atuais precisam lidar com incer-tezas e variabilidades em seu ambiente de execução, de maneira que precisam responder em tempo de execução a falhas, mudanças em seus requisitos e em seu ambiente. Uma forma de lidar com a elevada complexidade dos sistemas de software atuais é através de sistemas autoadaptativos (SALEHIE; TAHVILDARI, 2009). Sistemas autoadaptativos devem

ser capazes de alterar seu comportamento ou sua estrutura em repostas a mudanças nos requisitos, no ambiente em que estão implantados e em si próprio, para que continuem a prover seus serviços da forma que é esperada (SILVA; LEMOS, 2011b). Segundo (OREIZY

et al., 1999), eles devem ser capazes de monitorar a si mesmos e ao seu ambiente, analisar

os dados monitorados a fim de identificar a necessidade da adaptação, decidir como a adaptação será realizada e por fim realizar as adaptações necessárias.

Essas atividades formam um ciclo contínuo que é conhecido na literatura comofeedback control loop (CHENG; LEMOS; AL., 2009; BRUN et al., 2009) e, como mostra a Figura 1, é

organizado em quatro fases: coletar (collect), onde o ambiente e o próprio sistema são monitorados; analisar (analyse), onde a necessidade da adaptação é identificada com base nos dados coletados na fase anterior; decidir (decide), que decide o que fazer para adaptar o sistema e como a adaptação será realizada; e agir (act), onde as adaptações são de fato executadas.

Comparados a sistemas de software tradicionais, uma das características de sistemas autoadaptativos é que a tradicional separação entre tempo de projeto e tempo de execu-ção se confunde (BARESI; GHEZZI, 2010), e algumas decisões de projeto são movidas para

Figura 1: Feedback Control Loop (DOBSON et al., 2006)

conduzidos em tempo de projeto em um ambiente controlado, agora precisam ser execu-tados também em tempo de desenvolvimento, em um ambiente distribuído e dinâmico, e sem nenhuma intervenção humana (SILVA, 2011).

Processos que gerenciam sistemas de software autoadaptativos devem estar aptos a li-dar em tempo de execução com mudanças imprevisíveis que possam ocorrer nos requisitos do sistema, em seu ambiente, ou no software em si, tais como mudanças na variabilidade de recursos, e falhas. Dessa forma, esses processos dependem de vários fatores que po-dem mudar durante o ciclo de vida operacional do sistemas, e assim, deveria também se adaptar dependendo das mudanças que possam ocorrer. Nesse contexto, é esperado que sistemas de software autoadaptativos possam gerar dinamicamente processos para geren-ciar a autoadaptação do software em tempo de execução. Esses processos devem levar em consideração o estado atual do sistema e seu ambiente, a fim de lidar de forma eficaz com a variabilidade e a incerteza envolvida na autoadaptação de um sistema de software (SILVA, 2011).

1.1

Contexto

sistema.

Algumas abordagens tratam as questões de tomada de decisão em sistemas auto-adaptativos com políticas de adaptação definidas em tempo de projeto (DAMIANOU et

al., 2001; LOPES, 2006; BENCOMO et al., 2008; PINTO, 2011). De forma simples, políticas

de adaptação são um conjunto de regras evento-condição-ação, onde, quando um evento ocorre, e uma determinada condição é satisfeita, uma plano de adaptação correspondente é executado sobre o sistema. Como essas políticas são normalmente definidas em tempo de projeto, novas possibilidades de adaptação que podem surgir em tempo de execução não são consideradas. Por exemplo, o surgimento de novos componentes no ambiente em que a aplicação está executando, pode possibilitar novos arranjos arquiteturais que não foram considerados nas políticas de adaptação.

Uma outra forma de adaptação é gerar, em tempo de execução, os passos necessários para adaptar a aplicação. Técnicas de geração dinâmica de processos tem sido usadas em diversos domínios de aplicação, tais como: composição de serviços Web (DUSTDAR;

SCHREINER, 2005); grades computacionais (DEELMAN et al., 2003); e gerenciamento de

software (ANDRZEJAK; HERMANN; SAHAI, 2005). Utilizar técnicas de geração dinâmica

de processos para gerar planos de adaptação, permite que sejam levadas em considera-ção características do ambiente que só podem ser avaliadas em tempo de execuconsidera-ção, tal como a possibilidade de novos arranjos arquiteturais em função do surgimento de novos componentes.

Em (SILVA; LEMOS, 2009, 2011b, 2011a;SILVA, 2011), Da Silva propõe uma abordagem

genérica para a geração dinâmica de processos que pode ser utilizada em vários domínios de aplicação. Essa abordagem consiste em umframework para a geração dinâmica de pro-cessos que fornece mecanismos comuns para a geração de propro-cessos, e possui pontos de customização bem definidos para prover capacidades de geração de processos a diferentes domínios de aplicação. A abordagem de Da Silva é baseada em três tecnologias: transfor-mação de modelos, onde modelos específicos de domínio são traduzidos para problemas de planejamento; planejamento baseado em inteligência artificial, utilizado para a geração de planos; e gerenciamento de workflows, utilizado para representar e executar os planos gerados. Além disso, o framework de geração dinâmica de processos possui um processo de referência e uma infraestrutura de suporte que são customizados de acordo com uma metodologia de instanciação do framework.

instanciações. Particularmente na instanciação para o domínio de reconfiguração arquite-tural, os experimentos exploraram: a viabilidade da abordagem; uma avaliação quantita-tiva da abordagem, comparando o seu desempenho e escalabilidade com outras aborda-gens; e o impacto de diferentes características arquiteturais (por exemplo, quiescência e transferência de estados entre componentes) ao se instanciar o processo de reconfiguração.

De maneira a avaliar a viabilidade do framework de geração dinâmica de processos, além de confirmar o grau de generalidade atribuído ao mesmo, faz-se necessário realizar sua instanciação em um novo ambiente de execução baseado em modelos de componentes bem conhecidos, tais como FRACTAL (BRUNETON et al., 2006), OpenCOM (COULSON et

al., 2008) e OSGi1.

1.2

Objetivos

O objetivo principal deste trabalho é instanciar o gerador dinâmico de processos no domínio de reconfigurações arquiteturais sobre o ambiente de execução OSGi. Essa ins-tanciação será então utilizada no intuito de avaliar a sua aplicabilidade no cenário de um novo ambiente de execução, e verificar a viabilidade da abordagem proposta por Da Silva (SILVA, 2011).

A nossa escolha pelo ambiente OSGi deve-se a atenção cada vez maior que este ambi-ente vem recebendo da industria de desenvolvimento de software2_{. O conjunto de}

especifi-cações OSGi definem uma arquitetura orientada a serviços com unidades de modularização bem definidas. As aplicações OSGi surgem da interação de suas diversas unidades de mo-dularização e se beneficiam das facilidades que o ambiente provê ao possibilitar a troca dessas unidades de modularização sem a necessidade de parar a aplicação inteira. Dito isto, apontamos os seguintes objetivos para o nosso trabalho:

• Instanciar o framework proposto por Da Silva para gerar dinamicamente planos

de adaptação arquitetural sobre o ambiente OSGi. Como parte da metodologia de instanciação doframework, faz-se necessário definir um metamodelo de componentes de acordo com o ambiente OSGi, uma arquitetura para integração doframework com o ambiente, além de diversos artefatos (modelos e regras de transformação) que são utilizados pelo framework.

1

http://www.osgi.org/

2

• Realizar uma prova de conceito sobre a instanciação do framework de geração

dinâ-mica de processos com uma aplicação de estudo de caso. Através dessa aplicação de estudo de caso pretendemos demonstrar o processo de reconfiguração utilizado pela instanciação do framework de geração dinâmica de processos durante a geração do plano de adaptação. Utilizaremos o Comanche3 _{como aplicação de estudo de caso}

devido a sua utilização para validação de alguns trabalhos diretamente relacionados ao nosso (BENEDITTO; WERNER, 2012;FONSECA; BENEDITTO; WERNER, 2012).

• Fazer uma discussão sobre a integração do framework de geração dinâmica de

pro-cessos com o ambiente OSGi e sobre o aprendizado dos diversos conceitos necessários para realizar a instanciação do framework de geração dinâmica de processos no ce-nário de um novo ambiente de execução.

1.3

Estrutura do trabalho

O restante do trabalho está organizado da seguinte forma. Discutimos no Capítulo 2 a base teórica que fundamenta o nosso trabalho. No Capítulo 3, mostramos como a instanciação do framework de geração de processos foi realizada sobre o ambiente OSGi, destacando os pontos de customização oferecidos pelo framework. Apresentamos uma prova de conceito da instanciação do framework de geração dinâmica de processos no Capítulo 4, bem como realizamos uma discussão sobre a integração do framework de geração dinâmica de processos com o ambiente OSGi. O Capítulo 5 apresenta os trabalhos que estão diretamente relacionados ao nosso. Por fim, no Capítulo 6, pontuamos nossas considerações finais e discutimos a realização de trabalhos futuros.

3

2

Fundamentação Teórica

Antes de apresentar como foi realizado nosso principal objetivo, que é instanciar o fra-mework de geração dinâmica de processos sobre o ambiente OSGi, é necessário apresentar a base teórica que fundamenta o nosso trabalho. Para isso, neste Capítulo, apresentamos os principais conceitos explorados para alcançar nossos objetivos. Uma breve discussão sobre sistemas autoadaptativos é apresentada na Seção 2.1. Apresentamos, na Seção 2.2, o framework para geração dinâmica de processos proposto por Da Silva, detalhando as tecnologias utilizadas por ele, o seu processo de referência, e a metodologia necessária para sua instanciação. E finalmente, na Seção 2.3, apresentamos os conceitos relacionados com o ambiente OSGi, no qual oframework de geração dinâmica de processos será instanciado.

2.1

Sistemas Autoadaptativos

Como dito anteriormente, sistemas autoadaptativos devem ser capazes de alterar o seu comportamento ou sua estrutura, de forma que seus serviços continuem a serem providos como esperado, em reposta a mudanças que venham a ocorrer no ambiente em que estão implantados ou em seus requisitos (SILVA; LEMOS, 2011b). Para isso, sistemas

autoadap-tativos devem ter a capacidade de monitorar a si mesmos e ao seu ambiente, analisar os dados monitorados a fim de identificar a necessidade da adaptação, decidir como a adapta-ção será realizada e por fim realizar as adaptações necessárias (OREIZY et al., 1999). Nesta

Seção, nós discutimos algumas das caracterizações de sistemas autoadaptativos presente na literatura.

Uma das caracterizações mais comuns para classificar sistemas autoadaptativos está relacionada a como o sistema está organizado para que a adaptação seja alcançada, e pode ser dividida em duas categorias (SILVA, 2011;BRUN et al., 2009;CHENG; LEMOS; AL.,

2009; SALEHIE; TAHVILDARI, 2009). A primeira categoria compreende uma abordagem

referenciada como auto-organização, que é caracterizada pela descentralização do controle, onde vários componentes interagem localmente sem conhecimento do sistema como um todo, e o comportamento global do sistema surge dessas interações.

Quanto ao tipo, uma adaptação pode ser classificada como paramétrica ou estrutural (também conhecida como composicional) (MCKINLEY et al., 2004). Na adaptação

paramé-trica, as modificações são realizadas sobre os parâmetros (variáveis) dos componentes que determinam o comportamento do programa. Uma desvantagem com relação a adaptações paramétricas é que as possíveis adaptações são limitadas aos comportamentos definidos durante o desenvolvimento do sistema que são modificáveis através de parâmetros (SILVA,

2011). Já as adaptações estruturais modificam a estrutura do sistema em si, seja substi-tuindo, adicionando ou removendo componentes da sua estrutura. Os dois tipos também podem ser usados de forma conjunta, como é mostrado em (CHENG et al., 2004).

Diversos trabalhos na literatura têm definido abordagens para lidar com reconfigura-ções arquiteturais (KRAMER; MAGEE, 2007). Em (SILVA, 2011), Da Silva também realizou

uma instanciação do framework de geração dinâmica de processos no domínio de reconfi-gurações arquiteturais. Uma pesquisa mais detalhada sobre esse tópico é apresentada por Bradbury em (BRADBURY et al., 2004).

O processo de tomada de decisão em sistemas autoadaptativos encaixa-se em um espectro que varia de estático a dinâmico. De um lado desse espectro, temos um processo de tomada de decisão totalmente estático, o qual é vinculado ao código-fonte do sistema em tempo de desenvolvimento, caminhando em direção a um processo de tomada de decisão dinâmico envolvendo adaptações que são definidas automaticamente pelo sistema em tempo de execução, levando em consideração o atual estado do sistema e o seu ambiente (OREIZY et al., 1999).

De maneira semelhante à tomada de decisão estática e dinâmica, há na literatura (JOOLIA et al., 2005) também os conceitos de reconfiguração programada e

reconfigura-ção ad-hoc. A reconfigurareconfigura-ção programada diz respeito as operações de reconfigurareconfigura-ção que foram previstas em tempo de projeto, enquanto que reconfiguração ad-hoc envolve mu-danças não previstas em tempo de projeto. Dessa forma, podemos considerar que reconfi-guração programada está do lado mais estático do espectro definido por Oreizy, enquanto reconfiguração ad-hoc está do lado mais dinâmico desse espectro.

entidade centralizada. Como nosso objetivo é utilizar oframework de geração dinâmica de processos para gerar planos de adaptação arquitetural em tempo de execução, podemos dizer que o nosso processo de tomada de decisão tende ao extremo mais dinâmico do espectro definido por Oreizy e alcança reconfigurações ad-hoc, com foco em adaptação estrutural. Levando em consideração as fases do feedback control loops apresentados na introdução deste trabalho (Figura 1), destacamos que o escopo do nosso trabalho se encontra apenas na fasedecide.

2.2

Framework de Geração Dinâmica de Processos

Uma vez que nosso objetivo é instanciar o framework proposto por Da Silva (SILVA;

LEMOS, 2009, 2011a, 2011b; SILVA, 2011), esta Seção apresenta em detalhes os conceitos

e tecnologias utilizados no framework. Para esta seção, nos baseamos no texto presente em (SILVA, 2011), onde o framework é apresentado e sua metodologia de instanciação é definida.

Oframework para a geração dinâmica de processos fornece mecanismos comuns para a geração de processos com pontos de customização bem definidos para prover capacidades de geração de processos a diferentes domínios de aplicação. Oframework consiste em um processo de referência para controlar a geração e execução de planos de adaptação, uma infraestrutura reutilizável que suporta o processo de referência, e uma metodologia para sua instanciação em diferentes domínios de aplicação. Neste trabalho, o framework será utilizado para gerar planos de adaptação para sistemas autoadaptativos sobre o ambiente OSGi. Os principais detalhes desta abordagem são apresentados a seguir.

A abordagem é baseada em vários conceitos e técnicas, explorando planejamento ba-seado em inteligência artificial (IA), engenharia dirigida por modelos (MDE), feedback control loops e tolerância a falhas. Técnicas MDE são implantadas para traduzir modelos específicos de domínio em problemas de planejamento, que são utilizados como entrada em um planejador baseado em IA. Os planos gerados são representados através de work-flows, que são constituídos por um conjunto de tarefas que podem ser executadas sobre o ambiente no qual oframework está instanciado. A geração é estruturada em termos de feedback control loops, enquanto conceitos de tolerância a falhas são utilizados como me-canismos estruturais a fim de prover os meios para lidar com exceções durante a execução dos workflows gerados.

domínio e uma representação do problema. A representação do domínio inclui os predi-cados disponíveis para descrever o estado do mundo, os possíveis tipos para os objetos existentes, e as ações disponíveis no mundo. Ações são especificadas com suas pré e pós-condições associadas, que são expressas em termos de predicados identificados no domínio. Uma representação de problema inclui os objetos envolvidos no problema, uma descrição do estado inicial, e uma descrição do objetivo desejado. Para representar o domínio e o problema de planejamento, oframework utiliza uma sintaxe padrão denominadaPlanning Domain Definition Language (PDDL) (FOX; LONG, 2003; GEREVINI; LONG, 2006). Uma

vantagem da utilização de PDDL é que ela tem sido utilizada por diversos planejadores ba-seados em IA, permitindo alterar o planejador utilizado na instanciação doframework de geração dinâmica de processos com pouco ou nenhuma impacto sobre os outros elementos doframework (SILVA, 2011).

A geração e a execução de workflows são divididas em três fases: estratégica, tática e operacional. Essa divisão permite melhorar o desempenho e a escalabilidade da geração de processos, provendo uma maneira efetiva de lidar com a variabilidade de recursos. A execução do workflow gerado pode terminar com uma exceção, indicando que este workflow não pode ser executado sobre o ambiente. O framework de geração dinâmica de processos utiliza a linguagem YAWL (AALST; HOFSTEDE, 2005) para representar os

workflows gerados, e para gerenciar a execução dessesworkflows, o framework utiliza um sistema de gerenciamento de workflows de mesmo nome (YAWL) (AALST et al., 2004).

Além disso, os workflows são divididos em dois tipos:workflows abstratos e workflows concretos. Um workflow abstrato descreve um conjunto de tarefas e as dependências de dados entre essas tarefas, sem se referir aos recursos disponíveis no sistema. Já em workflows concretos as tarefas referem-se a recursos concretos do sistema. Dessa forma um workflow abstrato pode ser mapeado em vários workflows concretos utilizando diferentes combinações de recursos. Os recursos são descritos por um nome lógico e um tipo em um workflow abstrato, o que deve ser suficiente para identificar os recursos disponíveis durante a fase tática.

Figura 2: Visão geral do processo de geração de processos (SILVA, 2011)

para a fase estratégica para que um novo workflow abstrato seja gerado. Finalmente, a atividade Execute Concrete Workflow representa a fase operacional, onde o workflow concreto gerado na fase tática é então executado. No caso de ocorrer algum erro durante a execução do workflow, o processo é direcionado para a atividade Recovery, onde são desfeitas as modificações realizadas antes da exceção ocorrer, e logo após, volta para a fase anterior, onde um novoworkflow concreto é gerado. Se oworkflow foi executado com sucesso, então o processo finaliza com uma saída de sucesso.

No restante dessa Seção, detalharemos o processo de referência e a metodologia de instanciação do framework de geração dinâmica de processos. A infra-estrutura que dá suporte ao processo de referência será apresentada na Seção 3.5, onde definiremos nossa solução para integrar o framework de geração dinâmica de processos ao ambiente OSGi.

2.2.1

Processo de Referência

O framework para geração dinâmica de processos define um processo de referência onde são organizadas as atividades associadas com a geração e execução dos workflows. Este processo de referência é dividido em três partes como foi mencionado anteriormente: fase estratégica; fase tática; e fase operacional. Cada fase é composta por um conjunto de atividades que podem ser dependentes ou independentes do domínio no qual oframework está sendo instanciado.

2.2.1.1 Fase Estratégica

A Figura 3 apresenta as atividades que estão envolvidas na geração de workflows abs-tratos durante a fase estratégica. As atividades representadas na figura por retângulos sem preenchimento são atividades específicas do domínio onde oframework está sendo instan-ciado, e portanto, são definidas durante a instanciação do framework. Já as atividades representadas por retângulos com preenchimento cinza são atividades que independem do domínio, e portanto podem ser reusadas através de diferentes domínios de aplicação.

Figura 3: Fase Estratégica (SILVA, 2011)

A atividade Obtain Current Configuration é responsável por obter um modelo arqui-tetural, representado através do metamodelo específico de domínio, que descreva a confi-guração atual do sistema, representando o estado inicial do sistema. A atividade Obtain Abstract Configuration é responsável por obter o objetivo do workflow, que corresponde a seleção de uma nova configuração arquitetural abstrata para o sistema. Uma configu-ração abstrata descreve a configuconfigu-ração do sistema em termos de propriedades requiridas e desejadas dos seus elementos arquiteturais, abstraindo das instâncias dos componentes, enquanto que configurações concretas, descrevem configurações em termos das instâncias atuais dos componentes e suas propriedades. Na possibilidade de não haver um nova con-figuração arquitetural que satisfaça os objetivos da aplicação, o processo finaliza com uma saída de exceção. É importante ressaltar que apesar da geração do plano de adaptação peloframework de Da Silva necessitar saber qual será a configuração que o sistema deve alcançar, neste trabalho nós não está interessado em definir mecanismos para seleção ar-quitetural. Existem várias abordagens na literatura que tratam esse problema (SYKES et

al., 2008; MORIN et al., 2008; SILVA et al., 2012).

passando como parâmetro a especificação do domínio PDDL, que contém as possíveis tarefas que podem ser utilizadas para compor o plano a ser gerado, e a especificação do problema PDDL, que captura as pré e pós condições expressas em um modelo PDDL. No caso de não ser possível encontrar um plano para as pré e pós condições fornecidas, a atividade finaliza com uma exceção e o processo volta para a atividade Obtain Current Configuration novamente.

Após o plano ser gerado a próxima atividade éTranslate Into Workflows, que traduz o plano gerado em umworkflow abstrato. Oworkflow abstrato gerado é então passado para a fase tática onde será transformado em um workflow concreto. Caso uma exceção seja gerada pela fase tática, o processo volta para a atividade Obtain Current Configuration.

2.2.1.2 Fase Tática

Na fase tática, o workflow abstrato gerado na fase estratégica é mapeado em um workflow concreto. Para isso é necessário identificar os recursos presentes no sistema que são necessários para a execução do workflow. A Figura 4 mostra as atividades envolvidas nesta fase. A primeira atividade da fase tática,Extract Abstract Tasks, consiste em extrair as tarefas abstratas que compõe o workflow abstrato recebido da fase estratégica. Isto é feito consultando otemplate de tarefa de cada tarefa que compõe o workflow abstrato.

Figura 4: Fase tática (SILVA, 2011)

A atividade Obtain Concrete Configuration é responsável por encontrar um confi-guração concreta para o sistema, baseada na conficonfi-guração abstrata identificada na fase estratégica. Se durante esta atividade, o processo não conseguir encontrar nenhuma con-figuração concreta que satisfaça a concon-figuração abstrata, o processo retorna para a fase estratégica onde uma nova configuração abstrata será selecionada.

Finalmente, a atividade Associate Concrete Tasks substitui as tarefas abstratas pelas tarefas concretas identificadas, resultando em um workflow concreto. O workflow resul-tante é então passado para a fase operacional, onde será executado. Caso alguma exceção seja retornada da fase operacional, o processo volta para a fase Extract Abstract Tasks e uma nova configuração concreta é selecionada.

2.2.1.3 Fase Operacional

A última fase do processo de referência do framework de geração de processos é res-ponsável por controlar a execução dosworkflows concretos gerados, e por gerar e executar workflows de recuperação no caso de erros ocorridos durante a execução dos workflows concretos. A Figura 5 ilustra as atividades presentes nesta fase. Antes e após cada tarefa doworkflow concreto ser executada, suas pré e pós condições são respectivamente verifi-cadas, e no caso de haver alguma violação em alguma das pré ou pós condições ou algum erro ocorrer durante a execução da tarefa, umworkflow que desfaça os efeitos das tarefas que já foram executadas é gerado para levar o sistema ao seu estado inicial.

Figura 5:Fase Operacional (SILVA, 2011)

workflow de recuperação é executado na atividade Execute Recovery Workflow e o pro-cesso volta para a fase tática onde deve ser gerado um novoworkflow.

2.2.2

Metodologia de Instanciação

O framework de geração dinâmica de processos também define uma metodologia que deve ser utilizada durante a sua instanciação. Nesta Seção apresentamos quais artefatos devem ser gerados para que o framework possa gerar e executar processos no domínio em que está sendo instanciado, identificando os pontos de customização presentes na abordagem.

Para ajustar oframework de geração dinâmica de processos ao domínio de aplicação no qual ele será instanciado, é necessário definir alguns artefatos específicos de domínio. Estes artefatos representam os pontos de customização doframework, que são: um metamodelo específico de domínio, usado para definir modelos específicos de domínio; um modelo de domínio PDDL, que captura as características de domínio que serão consideradas durante o planejamento; um conjunto de regras de transformação específicas de domínio, para traduzir modelos específicos de domínio em uma especificação de problema PDDL; e os templates de tarefas, que podem ser usados para gerar workflows.

O metamodelo específico de domínio deve ser baseado no ambiente de execução em que o framework será aplicado e deve ser representado usando modelos EMFs1_{. Este}

me-tamodelo deve capturar as informações necessárias para definir os objetivos em termos de modelos específicos de domínio. Ele pode ser baseado em um metamodelo já estabe-lecido no domínio de aplicação, ou pode ser definido especificamente para um domínio particular. O metamodelo específico de domínio é utilizado como base para estabelecer o modelo de domínio PDDL, onde os elementos que compõem o metamodelo específico de domínio são especificados em termos de predicados e tipos PDDL. O modelo de domínio PDDL identifica as informações do domínio de aplicação que são consideradas durante o planejamento.

Após os tipos, predicados e características PDDL terem sido definidos, é necessário prover as regras de transformações e ostemplates de tarefas. As regras de transformação são utilizadas para se traduzir modelos específicos de domínio em modelos de problema PDDL. O framework define a linguagem de transformação Atlas (ATL) (JOUAULT et al.,

2008) para se especificar essas regras de transformação.

1

Ostemplates de tarefas são definidos baseando-se no metamodelo específico de domí-nio, no ambiente de execução, e no modelo de domínio PDDL. Para cada tarefa disponível no domínio de aplicação, é necessário definir um modelo detemplate de tarefa, uma especi-ficação detemplate de tarefa, e uma implementação dotemplate de tarefa. Um modelo de template de tarefa é usado para representar um template de tarefa dentro do framework. Uma especificação de template de tarefa corresponde à especificação PDDL dessa tarefa, e a implementação dotemplate de uma tarefa corresponde a tarefa no formato usado pelo ambiente de execução deworkflows.

Além dostemplates de tarefa disponíveis no domínio da aplicação, é necessário definir templates de tarefa que capturem as pré- e pós-condições dos workflows gerados. Esses templates de tarefa são baseados nos modelos específicos de domínio que representam o estado inicial e os objetivos, e são usados para checar se o workflow gerado pode ser executado (pré-condições) e se sua execução teve uma saída de sucesso (pós-condições).

Após instanciados os artefatos de domínio, eles podem ser modificados desde que as suas dependências sejam respeitadas. Por exemplo, uma mudança em um template de tarefa pode ser realizada sem afetar outros artefatos de domínio. Por outro lado, alterar o modelo de domínio PDDL(por exemplo, considerar mais informações sobre ometamodelo específico de domínio) pode requerer mudanças em outros artefatos (como incluir novos predicados a serem considerados pelas regras de transformações dostemplates de tarefas).

Como parte da instanciação doframework, o processo de referência necessita ser ajus-tado de acordo com o domínio de aplicação. A instanciação do processo de referência envolve a associação das atividades aos seus respectivos componentes, prover atividades específicas de domínio, e ajustar o fluxo excepcional. Além do processo de referência, al-guns componentes que fazem parte da infra-estrutura de suporte do framework também devem ser customizados de acordo com os artefatos gerados.

2.3

OSGi

A especificação OSGi é mantida pela OSGi Alliance2_{, fundada em 1999 com o objetivo}

de prover uma arquitetura aberta que permita a provedores de serviços, desenvolvedores e vendedores de dispositivos desenvolver, implantar e gerenciar serviços de maneira co-ordenada. A tecnologia OSGi é formada por um conjunto de especificações que facilita a componentização de módulos de software e aplicações, e assegura o gerenciamento remoto

2

e a interoperabilidade de aplicações e serviços em uma ampla variedade de dispositivos.

Vários frameworks que implementam a especificação OSGi estão disponíveis na co-munidade de software livre, entre elas estão: Apache Felix3_{; Equinox}4_{; e Knopflerfish}5_.

Atualmente a especificação OSGi está na sua versão 5 (ALLIANCE, 2012), porém devido a

maioria da implementações disponíveis implementarem apenas a versão 4.2 (ALLIANCE,

2009), neste trabalho, estamos considerando esta versão da especificação OSGi.

OSGi define um modelo de componentes dinâmicos para Java, permitindo uma abor-dagem de desenvolvimento onde aplicações são compostas dinamicamente por diferentes componentes reusáveis. Uma unidade modular em OSGi é chamada bundle, e possui in-formações suficientes para que o ambiente OSGi seja capaz de gerenciá-la.

As funcionalidades do framework OSGi são divididas em várias camadas como é mos-trado na Figura 6: camada deSegurança; camada deModularização; camada deCiclo de Vida; e camada de Serviços.

Figura 6: Camadas do Framework OSGi(ALLIANCE, 2009)

A camada de Segurança (Security) é baseada na camada de segurança do Java 2, porém adiciona um série de restrições e preenche alguns vazios deixados pelo Java. Ela define um formato seguro de empacotamento, assim como interage com a camada de segurança do Java 2 em tempo de execução.

A camada deModularização (Module) define um modelo de modularização para Java. Esta camada trata algumas das deficiências do modelo de implantação Java e possui regras rígidas onde é possível definir quais pacotes serão compartilhados com outros bundles e quais serão escondidos. Além do mais, sua utilização é independente das camadas deCiclo

3

http://felix.apache.org/

4

http://eclipse.org/equinox/

5

de Vida (Life Cycle) e de Serviços (Service).

Na camada deCiclo de Vidauma API é definida para o gerenciamento do ciclo de vida dosbundle doframework OSGi. Esta API provê um modelo em tempo de execução para os bundles e define como eles são iniciados, parados, instalados, atualizados e desinstalados noframework. Adicionalmente, esta camada provê uma API de eventos que permite que bundles de gerenciamento controlem operações doframework OSGi. Esta camada permite ainda que o framework possa ser gerenciado remotamente. Esta camada permite realizar as adaptações no sistema através do gerenciamento do ciclo de vida dosbundles que estão presentes no framework. A camada de Ciclo de Vida requer a camada de Modularização, mas é independente da camada de Serviços.

Por fim, a camada de Serviços do framework OSGi provê um modelo de programa-ção consistente, conciso e dinâmico, simplificando o desenvolvimento e a implantaprograma-ção de bundles de serviço através desacoplamento da especificação de serviços (interface Java) da sua implementação. Esse modelo permite que desenvolvedores vinculem serviços utili-zando apenas as interfaces. A seleção de uma implementação específica pode ser realizada em tempo de execução.

2.3.1

Bundles

Como mencionado anteriormente, na especificação OSGi, umbundleé uma unidade de modularização. Uma aplicação OSGi surge da interação entre os diversosbundles que estão instalados no ambiente. Umbundleé um arquivo.jar que contém os recursos (classes Java, páginas HTML, arquivos de ajuda, etc.) necessários para prover alguma funcionalidade. O arquivo manifest.mf de um bundle deve conter as informações necessárias para que o ambiente OSGi possa instalá-lo e gerenciá-lo corretamente. Qualquer informação contida no arquivo manifest.mf que não esteja na especificação OSGi são desconsideradas pelo ambiente.

1 Bundle−SymbolicName : HelloWorld

2 Bundle−Name : HelloWorld

3 Bundle−V e r s i o n : 0 . 0 . 0

4 Bundle−A c t i v a t o r : f e r n a n d o . examples . h e l l o w o r l d . H e l l o W o r l d A c t i v a t o r

5 Import−Package : o r g . o s g i . framework

6 P r i v a t e−Package : f e r n a n d o . examples . h e l l o w o r l d

A Listagem 2.1 mostra um exemplo de um arquivo manifest.mf com atributos defi-nidos pela especificação OSGi. O único atributo que é obrigatório para que o ambiente reconheça o bundle é o Bundle-SymbolicName, que identifica unicamente um bundle no ambiente. Na prática, é possível ter dois ou mais bundles com o mesmo valor para o atributo Bundle-SymbolicName, desde que eles se diferenciem pela versão do bundle, que é definida pelo atributoBundle-Version.

As dependências entre os bundles também são definidas no arquivo manifest.mf. O atributo Import-package define quais os pacotes necessários para que o bundle possa prover sua funcionalidade. Da mesma forma, o atributo Export-package define quais pacotes contidos nobundle podem ser utilizados por outrosbundles. É através desses atri-butos que o ambiente OSGi consegue resolver as dependências entre osbundles que estão instalados. Diversas outras restrições podem ser definidas também no arquivomanifest.mf de um bundle. Um exemplo é o atributo Bundle-RequiredExecutionEnvironment, onde é possível definir qual versão da maquina virtual Java é necessária para que obundle seja executado corretamente.

Como mostrado na Figura 7, um bundle possui um ciclo de vida dentro do ambiente. Ao ser instalado no ambiente, o primeiro estado assumido pelo bundle é o estado INS-TALLED. Após ser instalado, um bundle pode ser ativado. Antes de ir para o estado ACTIVE, umbundle deve primeiramente passar pelo estadoRESOLVED. Quando um bundle está no estadoRESOLVED, significa que todas as suas dependências e restrições já foram checadas e ele está pronto para ser ativado.

Figura 7: Diagrama e Estados do Bundles (ALLIANCE, 2009)

ativa-ção tardia para um determinadobundle através do atributoBundle-ActivationPolicy. Dessa forma, o bundle não será devidamente iniciado até que um outro bundle necessite dele.

Após um bundle ser parado, ele volta para o estado RESOLVED. Um bundle tam-bém pode ser desinstalado doframework. Apesar da Figura 7 mostrar um estado UNINS-TALLED, ao ser desinstalado, umbundle é completamente removido do ambiente e não mais aparece na lista de bundles instalados.

Para que seja devidamente ativado no ambiente, o bundle em questão deve forne-cer uma implementação da interface BundleActivator, que é identificada no manifest.mf através do atributo Bundle-Activator. Esta interface define dois métodos que são exe-cutados pelo ambiente. O método start é chamado quando o bundle é ativado, enquanto que o método stop é chamado quando o bundle é desativado. A Listagem 2.2 mostra o exemplo de implementação da interfaceBundleActivator. No métodostart é onde devemos adicionar as atividades necessárias para que o bundle forneça sua funcionalidade, como por exemplo iniciarthreads, e no caso da figura, imprimir uma mensagem. O método stop dá oportunidade aobundle terminar as threads e/ou limpar arquivos que tenha criado.

1 package o s g i . example . u s i n g o p e r a t i o n ; 2

3 import o r g . o s g i . framework . B u n d l e A c t i v a t o r ; 4 import o r g . o s g i . framework . BundleContext ; 5

6 public c l a s s H e l l o W o r l d A c t i v a t o r implements B u n d l e A c t i v a t o r { 7

8 @Override

9 public void s t a r t ( BundleContext c o n t e x t ) throws E x c e p t i o n { 10 System . out . p r i n t l n ( "O bundle f o i i n i c i a d o ! Olá Mundo ! " ) ; 11 }

12

13 @Override

14 public void s t o p ( BundleContext c o n t e x t ) throws E x c e p t i o n { 15 System . out . p r i n t l n ( "O bundle f o i parado ! Tchau Mundo ! " ) ; 16 }

17 }

Listagem 2.2: Exemplo de BundleActivator

SystemBundle é uma representação do próprio ambiente OSGi como um bundle.

2.3.2

Serviços

Serviços podem ser facilmente registrados no ambiente. A Listagem 2.3 mostra um exemplo de registro de um serviço no ambiente. Para registrar serviços, o objeto Bun-dleContext fornece um método chamado registerService, que recebe três objetos como parâmetro. O primeiro parâmetro a ser passado é o nome sob o qual o serviço será regis-trado, neste caso utilizamos o nome da própria interface do serviço. O segundo parâmetro é a implementação do serviço, e o último parâmetro recebe um lista de propriedades (opcional) sobre o serviço.

1 @Override

2 public void s t a r t ( BundleContext c o n t e x t ) throws E x c e p t i o n { 3 Soma s e r v i c e = new SomaImpl ( ) ;

4 c o n t e x t . r e g i s t e r S e r v i c e ( Soma .c l a s s. getName ( ) , s e r v i c e , n u l l) ; 5 }

Listagem 2.3:Registrando um Serviço

Para recuperar um serviço que esteja registrado no ambiente é necessário primeiro recuperar um objeto de referência para este serviço (ServiceReference) através do método getServiceReference doBundleContext. Após recuperar a referência para o serviço, o ser-viço em si pode ser recuperado através do método getService. A Listagem 2.4 apresenta a recuperação e utilização de um serviço que realiza a soma de dois termos.

1 @Override

2 public void s t a r t ( BundleContext c o n t e x t ) throws E x c e p t i o n {

3 S e r v i c e R e f e r e n c e r e f = c o n t e x t . g e t S e r v i c e R e f e r e n c e ( Soma .c l a s s. getName ( ) ) ; 4 Soma soma = ( Soma ) c o n t e x t . g e t S e r v i c e ( r e f ) ;

5 System . out . p r i n t l n ( " 2 + 2 = " + soma . e x e c u t a r ( 2 , 2 ) ) ; 6 }

Listagem 2.4:Recuperando um Serviço

2.4

Sumário do Capítulo

3

Instanciação do Framework de

Geração de Processos

Como dito anteriormente, o principal objetivo deste trabalho é instanciar o framework de geração dinâmica de processos, proposto por Da Silva (SILVA, 2011), em um novo

ambiente de execução no contexto de reconfiguração arquitetural. Este framework visa fornecer mecanismos para geração de processos em diferentes domínios de aplicação, e para isso provê pontos de customização bem definidos, os quais foram apresentados no Capítulo 2. Para customizar o framework, Da Silva também propõe uma metodologia de instanciação que deve ser seguida. Neste capítulo, apresentamos como cada um dos pontos de customização, oferecidos pelo framework de geração dinâmica de processos, foram customizados para gerar planos de reconfiguração arquitetural sobre o ambiente OSGi.

O primeiro passo da metodologia de instanciação é a definição dos modelos necessários. Um metamodelo específico de domínio, apresentado na Seção 3.1, é necessário para definir modelos específicos de domínio que são transformados em problemas de planejamento. Um modelo de domínio PDDL (Seção 3.2) captura as informações do domínio que são utilizadas para o planejamento. Para transformar os modelos específicos de domínio em problemas de planejamento, é preciso definir um conjunto de regras de transformação, que são apresentadas na Seção 3.3. Também é necessário definir um conjunto de tarefas (Seção 3.4) que serão utilizadas peloframework para compor os planos gerados. O processo de referência, caso seja necessário, também deve ser customizado de acordo com o domínio. Na nossa instanciação, utilizamos o mesmo processo, definido por Da Silva em (SILVA,

3.1

Metamodelo Específico de Domínio

O metamodelo específico de domínio é utilizado para representar o domínio para o qual os processos serão gerados. No nosso trabalho o metamodelo específico de domínio é um metamodelo arquitetural que deve capturar os conceitos e propriedades associadas com os elementos arquiteturais. Esse metamodelo arquitetural deve expressar as características do ambiente de execução, as suposições feitas sobre os elementos arquiteturais, e meta-informações relacionadas à propriedades não-funcionais.

O metamodelo arquitetural criado neste trabalho é uma extensão da linguagem de de-finição arquitetural xADL, e é representado através de um modeloEclipse Modeling Fra-mework1 _{(EMF). A escolha pela linguagem xADL deve-se ao fato dela suportar, de forma}

semelhante a divisão entre workflows abstratos e concretos, a definição de configurações arquiteturais abstratas e concretas. Configurações abstratas, descrevem a configuração do sistema em termos de propriedades requeridas e desejadas dos seus elementos arquitetu-rais, abstraindo das instâncias dos componentes, enquanto que configurações concretas, descrevem configurações em termos das instâncias atuais dos componentes e suas proprie-dades. Dessa forma, uma configuração abstrata pode ser mapeada em varias configurações concretas, de acordo com as instâncias de componentes disponíveis. Além disso, xADL já foi utilizada em outras instanciações do framework de geração de processos (SILVA;

LEMOS, 2009, 2011a, 2011b;SILVA, 2011), o que facilita a nossa instanciação.

A Figura 8 contém uma representação do nosso metamodelo arquitetural, onde os elementos com preenchimento claro são elementos da linguagem xADL, e os elementos com preenchimento escuro foram introduzidos para representar as características do ambiente OSGi. No nosso metamodelo arquitetural, consideramos umbundlecomo um componente. Um serviço provido por um bundle é mapeado em uma interface provida, e um serviço requerido é mapeado em uma interface requerida.

O elemento MyPrescribedComponentInstance foi introduzido para representar uma instância de um componente OSGi (um bundle). As propriedades do bundle conti-das no arquivo manifest.mf podem ser expressas através do elemento Properties, além disso, através deste elemento também há a possibilidade de representar propriedades não funcionais, que podem ser utilizadas, por exemplo, para o monitoramento da aplicação.

1

O elemento ComponentLifeCycle representa o ciclo de vida de um bundle. Um mapeamento dos estados possíveis no metamodelo específico de domínio e o ciclo de vida dos bundles (apresentado na Seção 2.3.1) é definido na Tabela 1.

Tabela 1: Mapeamento do Ciclo de Vida dos Bundles ComponentLifeCycle Bundle Life Cycle

Started Starting Active

Stopped Stopping

Resolved Installed Installed Uninstalled Uninstalled

O estado Started do elemento ComponentLifeCycle corresponde aos estados Star-ting e Active do ciclo de vida dos bundles no ambiente OSGi. O estado Started do nosso metamodelo é mapeado em dois estados no ciclo de vida dos bundles porque o estado Starting é utilizado pelo ambiente para realizar ativação tardia. Neste estado os bundles estão prontos para serem utilizados e assim que são requisitados por outros bundles eles passam para o estado Active. O estado Stopped corresponde aos estados Stopping, que é um estado de transição utilizado pelo ambiente OSGi para parar um bundle, e Resolved, que é quando obundle está parado e todas as suas dependências estão resolvidas. Por fim, os estadosInstalled eUninstalled do elementoComponentLifeCyclecorrespondem aos estados de mesmo nome no ciclo de vida dos bundles.

3.2

Modelo de Domínio PDDL

O modelo de domínio PDDL captura os conceitos e características de domínio que são consideradas durante a fase de planejamento, e é criado com base no metamodelo específico de domínio. Este modelo de domínio PDDL é utilizado pelo planejador para gerar os planos de adaptação.

1 <?xml v e r s i o n ="1.0" e n c o d i n g="UTF−8"?>

2 <pddlmodel : DomainModel xmi : v e r s i o n ="2.0" xmlns : xmi="h t t p : / /www. omg . o r g /XMI" 3 xmlns : pddlmodel="h t t p : / / pddlmodel " domain="R e c o n f i g u r a t i o n D o m a i n">

4 <r e q u i r e m e n t s v a l u e="a d l "/> 5 <t y p e s v a l u e="component"/>

6 <t y p e s v a l u e=" r e q u i r e d I n t e r f a c e "/> 7 <t y p e s v a l u e=" p r o v i d e d I n t e r f a c e "/>

8 <p r e d i c a t e s v a l u e ="( s t a r t e d ?C − component ) "/>

9 <p r e d i c a t e s v a l u e ="( i n s t a l l e d ?C − component ) "/>

11 ?C2 − component ? P I n t f − p r o v i d e d I n t e r f a c e ) "/>

12 <p r e d i c a t e s v a l u e ="(bound ?C− component ? R I n t f − r e q u i r e d I n t e r f a c e ) "/>

13 <p r e d i c a t e s v a l u e ="( r e q u i r e s ?C − component ? R i n t f − r e q u i r e d I n t e r f a c e ) "/>

14 <p r e d i c a t e s v a l u e ="( p r o v i d e s ?C − component ? P I n t f − p r o v i d e d I n t e r f a c e ) "/>

15 </pddlmodel : DomainModel>

Listagem 3.1:Representação XMI do Modelo de Domínio PDDL

A Listagem 3.1 apresenta o XMI, criado através da plataforma EMF, do nosso mo-delo de domínio PDDL. Na parte superior da figura podemos ver a definição dos tipos considerados durante o planejamento (linhas 5-7), que são: Component, que representa um componente; requiredInterface, representando uma interface requerida; e providedIn-terface, representando uma interface provida. Os predicados servem para representar di-ferentes informações sobre os tipos que são considerados. Os predicados (started ?C -component)(linha 8) e(installed ?C - component)(linha 9) representam, respectiva-mente, os estados Started e Installed do elemento Component Life Cycle do metamodelo de domínio, enquanto que a negação desses predicados representam os estadosStopped e Uninstalled. O predicado(connected ?C1 - component ?RIntf - requiredInterface ?C2 - component ?PIntf - providedInterface) (linha 10-11) representa a conexão entre dois componentes. O predicado (bound ?C - component ?RIntf - require-dInterface) (linha 12) representa que uma interface requerida de um componente está vinculada. Por fim, os predicados(requires C? - component ?RIntf - requiredInter-face)(linha 13) e(provides C? - component ?PIntf - providedInterface)(linha 14) representam, respectivamente, uma interface requerida ou provida por um componente.

O XMI apresentado na Listagem 3.1 gera o PDDL equivalente que é apresentado no Listagem 3.2, onde podemos notar a definição dos tipos nas linhas 5-9 (equivalente as linhas 5-7 da Listagem 3.1) e os predicados nas linhas 10-18 (equivalente as linhas 8-14 da Listagem 3.1). É importante salientar que essa especificação PDDL é gerada automaticamente pelo framework baseado no modelo apresentado anteriormente.

1 ( d e f i n e ( domain R e c o n f i g u r a t i o n D o m a i n ) 2 ( : r e q u i r e m e n t s

3 : a d l 4 ) 5 ( : t y p e s 6 component

7 r e q u i r e d I n t e r f a c e 8 p r o v i d e d I n t e r f a c e 9 )

10 ( : p r e d i c a t e s

11 ( s t a r t e d ?C − component )

13 ( c o n n e c t e d ?C1 − component ? R I n t f − r e q u i r e d I n t e r f a c e

14 ?C2 − component ? P I n t f − p r o v i d e d I n t e r f a c e )

15 ( bound ?C − component ? R I n t f − r e q u i r e d I n t e r f a c e )

16 ( r e q u i r e s ?C − component ? R i n t f − r e q u i r e d I n t e r f a c e )

17 ( p r o v i d e s ?C − component ? P I n t f − p r o v i d e d I n t e r f a c e )

18 ) 19 )

Listagem 3.2:Modelo de Domínio PDDL

3.3

Criação das Regras de Transformação

O framework de geração de processos recebe como entrada modelos contendo a con-figuração atual da aplicação e a concon-figuração que o sistema deseja alcançar. Para realizar o planejamento, esses modelos precisam ser transformados em uma especificação de pro-blema de planejamento. Para isso, precisamos definir regras de transformação que são utilizadas para gerar, de forma automatizada, uma especificação de problema de planeja-mento a partir do estado inicial do sistema (representado pela configuração atual), e do objetivo a ser alcançado (representado pela configuração a ser alcançada). Estas regras são definidas com base nometamodelo específico de domínio e no modelo de domínio PDDL.

Um problema de planejamento contém os objetos que estão envolvidos no problema, o estado inicial do problema, e o objetivo a ser alcançado. Abaixo, mostramos informalmente a definição das nossas regras de transformação dividas em três grupos. O primeiro grupo considera as regras necessárias para definir os objetos que estão envolvidos no problema de planejamento, o segundo grupo considera as regras que definem o estado inicial, e o terceiro grupo considera as regras que definem o objetivo a ser alcançado.

Para definir os objetos que estão envolvidos no problema de planejamento, temos as seguintes regras:

• Objects01: Para todo componenteC envolvido na reconfiguração (ou seja, os

compo-nentes presentes na configuração inicial mais os compocompo-nentes presentes na configu-ração desejada), é criado um predicado na especificação do problema representando que C é um componente.

• Objects02: Para toda interface requeridaRIntf envolvida na reconfiguração, é criado

• Objects03: Para toda interface provida PIntf envolvida na reconfiguração, é criado

um predicado na especificação do problema representando quePIntf é uma interface provida.

As regras envolvidas com a definição do estado inicial, são informalmente descritas abaixo:

• Init01: Para cada componente pertencente a configuração inicial (componentes

exis-tentes), são criados predicados para representar o estado atual do componente (ou seja, installed e started).

• Init02: Para cada componente que esteja na configuração desejada mas não esteja

na configuração inicial (ou seja, componentes que serão adicionados a configuração do sistema), são criados predicados para representar o estado atual do componente (ou seja, not installed e not started).

• Init03: Para cada conexão entre componentes pertencentes à configuração inicial,

são criados predicados para representar as conexões como estabelecidas.

• Init04: Para cada conexão entre componentes pertencentes à configuração desejada

que não estão na configuração inicial (ou seja, novas conexões), são criados predi-cados para representar as conexões como não estabelecidas.

Por fim, para representar os objetivos do problema de planejamento, apresentamos as seguintes regras:

• Goal01: Para cada componente pertencente à configuração desejada, são criados

predicados para representar o estado que o componente deve alcançar (installed e started).

• Goal02: Para cada componente pertencente à configuração inicial que não esteja na

configuração desejada (componentes removidos), são criados predicados indicando o estado dos componentes (not installed e not started).

• Goal03: Para cada conexão entre componentes pertencentes à configuração desejada,

são criados predicados indicando a conexão como estabelecida.

• Goal04: Para cada conexão entre componentes pertencentes à configuração inicial,

A Listagem 3.3 mostra parte das regras de transformação criadas (as regras completas podem ser vistas no Apêndice A). Para definir as regras de transformação utilizamos a linguagem de transformação Atlas (ATL) (JOUAULT et al., 2008), a linguagem utilizada

peloframework. O móduloOSGi2PDDLtransforma os modelos da configuração inicial e da configuração desejada em um problema de planejamento PDDL. As entradasINeIN2 representam respectivamente a configuração inicial e a configuração desejada, enquanto que a entrada IN3 representa o modelo de domínio PDDL definido na Seção 3.2. A saída OUT representa a especificação de problema PDDL resultante da execução da transformação.

1 module OSGi2PDDL ;

2 c r e a t e OUT : PDDL from IN : OSGiMetamodel , IN2 : OSGiMetamodel , IN3 : PDDL; 3 r u l e DomainReferences {

4 from

5 a r c h 1 : OSGiMetamodel ! MyArchStructure i n IN , 6 a r c h 2 : OSGiMetamodel ! MyArchStructure i n IN2 , 7 d : PDDL! DomainModel i n IN3

8 t o

9 t : PDDL! ProblemModel ( 10 problem <− ’ OSGiProblem ’ ,

11 domain <− d ,

12 o b j e c t s <− Sequence { t h i s M o d u l e . c o m p o n e n t C o l l e c t i o n ( )−> c o l l e c t ( e |

13 t h i s M o d u l e . component2PddlObject ( e ) ) , . . . } , 14 i n i t <− Sequence { a r c h 1 . component −> c o l l e c t ( c |

15 t h i s M o d u l e . processCurrentComponentPre ( c ) ) , . . . } , 16 g o a l <− Sequence { a r c h 2 . l i n k −> c o l l e c t ( l i n k |

17 t h i s M o d u l e . linkToConnected ( l i n k ) ) , . . . } 18 )

19 } 20

21 l a z y r u l e component2PddlObject { 22 from s : CosmosMetamodel ! Component 23 t o p : PDDL! ProblemObject ( 24 name <− s . id ,

25 ty p e <− t h i s M o d u l e . recoverComponentType ( )

26 ) 27 }

Listagem 3.3: Regras de Transformação

A regra DomainReferences(linha 3) representa a regra principal da nossa transfor-mação. Esta regra é ativada quando os modelos são recebidos como entrada. As variáveis arch1earch2(linhas 5-6) recebem respectivamente os modelos da configuração inicial e da configuração desejada, enquanto que a variáveld (linha 7) recebe o modelo de domínio PDDL. O atributo objects (linha 12) consiste de todos os componentes e interfaces de ambas as configurações recebidas como entrada, que são obtidos através de regras auxili-ares, como por exemplo, a regra component2PddlObject (linhas 21-27), que cria um objeto do problema a partir de um componente.

existe uma regra auxiliar para preencher o estado inicial, na Listagem 3.3 podemos ver a regraprocessCurrentComponentPre (linha 15) que corresponde a regra Init01. De forma similar, também são utilizadas regras auxiliares para preencher os objetivos do problema. A regralinkToConnected (linha 17) é utilizada para atender a regraGoal03.

3.4

Templates

de Tarefa

Para gerar o plano de adaptação, o framework de geração dinâmica de processos necessita saber quais tarefas podem ser utilizadas no plano de adaptação. Os templates de tarefa representam as ações que podem ser executadas sobre o ambiente em que o framework de geração de processos está instanciado, que no nosso trabalho é o ambiente OSGi. Nós consideramos seis tarefas que podem ser executadas sobre o ambiente OSGi:

• Install: refere-se a instalação de um componente em um container OSGi.

• Uninstall: refere-se a desinstalação de um componente em um container OSGi.

• Start: responsável por iniciar a execução de um componente.

• Stop: responsável por parar a execução de um componente.

• Connect: responsável por conectar uma interface provida de um componente com

uma interface requerida de outro componente.

• Disconnect: responsável por desconectar uma interface provida de um componente

de uma interface requerida de outro componente.

Para cada uma das tarefas disponíveis são definidas pré e pós-condições para que elas possam ser utilizadas. As tarefas install, uninstall, start e stop envolvem apenas um componente, enquanto que as tarefas connect e disconnect envolvem dois componentes, uma interface provida e uma interface requerida. Para componentes com múltiplas inter-faces requeridas, a tarefa connect deve ser executada para cada uma das suas interfaces requeridas.

condições das tarefas connect e disconnect estão dispostas de forma a garantir a ordem de execução dos componentes envolvidos na reconfiguração. Isso se faz necessário para garantir que um bundle que requer um serviço seja iniciado somente se o bundle que provê esse serviço já esteja iniciado.

1 <?xml v e r s i o n ="1.0" e n c o d i n g="UTF−8"?>

2 <pddlmodel : A c t i o n xmi : v e r s i o n ="2.0" xmlns : xmi="h t t p : / /www. omg . o r g /XMI" xmlns : pddlmodel=" h t t p : / / pddlmodel " name="c o n n e c t">

3 <p a r a m e t e r s name="?C1">

4 <t y pe h r e f ="R e c o n f i g u r a t i o n D o m a i n . pddlmodel#//@types .0"/ > 5 </pa r am e te r s >

6 <p a r a m e t e r s name="? R I n t f">

7 <t y pe h r e f ="R e c o n f i g u r a t i o n D o m a i n . pddlmodel#//@types .1"/ > 8 </pa r am e te r s >

9 <p a r a m e t e r s name="?C2">

10 <t y pe h r e f ="R e c o n f i g u r a t i o n D o m a i n . pddlmodel#//@types .0"/ > 11 </pa r am e te r s >

12 <p a r a m e t e r s name="? P I n t f ">

13 <t y pe h r e f ="R e c o n f i g u r a t i o n D o m a i n . pddlmodel#//@types .2"/ > 14 </pa r am e te r s >

15 <p r e c o n d i t i o n v a l u e ="( i n s t a l l e d ?C1 ) "/> 16 <p r e c o n d i t i o n v a l u e ="( i n s t a l l e d ?C2 ) "/> 17 <p r e c o n d i t i o n v a l u e ="( p r o v i d e s ?C2 ? P I n t f ) "/> 18 <p r e c o n d i t i o n v a l u e ="( r e q u i r e s ?C1 ? R I n t f ) "/> 19 <p r e c o n d i t i o n v a l u e ="( not ( bound ?C1 ? R I n t f ) ) "/>

20 <p r e c o n d i t i o n v a l u e ="( not ( c o n n e c t e d ?C1 ? R I n t f ?C2 ? P I n t f ) ) "/> 21 <p r e c o n d i t i o n v a l u e ="( not ( s t a r t e d ?C1 ) ) "/>

22 <p r e c o n d i t i o n v a l u e ="( s t a r t e d ?C2 ) "/> 23 < e f f e c t v a l u e ="(bound ?C1 ? R I n t f ) "/>

24 < e f f e c t v a l u e ="( c o n n e c t e d ?C1 ? R I n t f ?C2 ? P I n t f ) "/> 25 </pddlmodel : Action>

Listagem 3.4: XMI da especificação dotemplate de tarefa Connect