Fase 7: Integra¸c˜ao dos Componentes do Sistema

componente, no caso de sistemas confi´aveis, onde os tratamentos costumam ser mais complexos; ou (ii) como uma classe, no caso de sistemas sem requisitos cr´ıticos de confiabilidade, que normalmente possuem tratadores simples.

Em rela¸cão aos componentes colaboradores, eles são implementados como wrappers que envolvem os participantes e intermediam o acesso a eles. Numa implementa¸cão con- corrente, cada participante deve ser executado em uma thread distinta dos demais. A execu¸cão dessas threads é coordenada e sincronizada pelo próprio coordenador. A Fi- gura 3.25, que mostra a estrutura¸cão de um wrapper pode ser utilizada para exemplificar uma colabora¸cão, onde os componentes reutilizados assumem o papel de participantes e o wrapper assume o papel de coordenador.

3.8 Fase 7:

Integra¸c˜ao dos Componentes do Sistema

Apesar de nesse ponto do desenvolvimento os componentes da release atual já estarem dispon´ıveis para serem utilizados, esses componentes isoladamente não são capazes de oferecer os seus servi¸cos especificados. Para que isso seja poss´ıvel, é necessário indicar para cada um dos componentes, quem supre as suas dependências. Essa liga¸cão entre as interfaces requeridas de um componente e as respectivas interfaces providas de outro é feita através dos conectores, que conseqüentemente são dependentes dos componentes envolvidos.

O método MDCE+ divide a fase de integra¸cão dos componentes em duas etapas conceitualmente distintas: (i) montar os componentes arquiteturais, onde é realizada a liga¸cão entre os componentes normais e excepcionais; e (ii) materializar a configura¸cão do sistema, onde é realizada a liga¸cão entre os componentes arquiteturais do sistema e a implementa¸cão do programa principal. As se¸cões seguintes detalham cada uma dessas etapas.

3.8.1 Montar os Componentes Arquiteturais (ativ. 7.1)

Como discutido anteriormente, a fase de montagem dos componentes arquiteturais do sistema consiste basicamente na estrutura¸cão dos componentes tolerantes a falhas ideais (Se¸cão 2.3.7). Para isso, para cada componente do sistema que possui alguma dependência excepcional (interface requerida excepcional), o método MDCE+ prevê a cria¸cão de conectores especiais que realizem essa liga¸cão. Devido ao caráter interno desses conectores em rela¸cão ao componente arquitetural do sistema, eles são denominados conectores internos. Do ponto de vista da abordagem de tratamento de exce¸cões intra componente apre- sentada na Se¸cão 2.4.2, os conectores internos materializam os três n´ıveis de tratamento: de fronteira (ProvidedBLE e RequiredBLE) e de aplica¸cão (ALE), uma vez que para o

componente, são eles que oferecem os seus tratadores. Deve ser criado um conector interno para cada n´ıvel de tratamento presente no componente: um conector ProvidedBLE, um RequiredBLE e um conector ALE, onde cada um implementa a sua interface corres- pondente, que foi definida durante a materializa¸cão do componente (Se¸cão 3.7). No caso dos componentes reutilizados, apenas as interfaces BLEs podem estar presentes. Já no caso dos componentes novos, pode existir uma interface ProvidedBLE, uma ALE, uma RequiredBLE ou todas, conforme a natureza de deteçcão da exce¸cão (Se¸cão 2.4.2).

Do ponto de vista pr´atico, cada conector interno ´e implementado como uma classe simples. Essas classes, por sua vez, devem materializar26 _{a sua respectiva interface ex-}

cepcional requerida, de acordo com o n´ıvel de tratamento de exce¸cões que o conector se refere. A Figura 3.27 mostra a estrutura de um componente arquitetural que possui os três n´ıveis de tratamento excepcional. Em seguida, a Figura 3.28 mostra o código rela- tivo a parte da implementa¸cão em Java do conector interno ALE. Nesse código, o trecho sublinhado destaca a implementa¸cão da interface provida. Os atributos das classes, por sua vez, representam as interfaces providas dos componentes excepcionais dos quais o conector depende. << component >> Normal << component >> ExcepcionalA << component >> ExcepcionalB ProvidedBLEConnector ALEConnector IReq IProv ProvBLEReq ALEReq IEAProv IEBProv . <<architectural_component>> RequiredBLEConnector ProvBLEReq

Figura 3.27: Estrutura do Componente Ideal Projetado

1 public c l a s s ALEConnector implements ALEReq {

2 IEAProv t r a t a d o r A ;

3 IEBProv t r a t a d o r B ;

4 . . .

5 }

Figura 3.28: Implementa¸c˜ao do Conector Interno ALE

Após a implementa¸cão dos conectores internos, deve-se proceder a cria¸cão dos componentes tolerantes a falhas ideais. Para isso, é necessário implementar o método do sistema

3.8. Fase 7: Integra¸c˜ao dos Componentes do Sistema 103

que será responsável pela montagem dos componentes arquiteturais. Em resumo, esse método deve instanciar o componente normal, os excepcionais e os conectores internos. Em seguida, deve realizar a liga¸cão desses componentes através dos conectores. Por se tratar de apenas uma classe, a liga¸cão entre os componentes excepcionais e os conectores internos é feita através da passagem das referências ao construtor da própria classe. Em rela¸cão aos componentes do sistema, as dependências são supridas através da execu¸cão da opera¸cão setRequiredInterface(String nome, Object facade), da interface IMana- ger do COSMOS. A Figura 3.29 mostra um exemplo desse procedimento de liga¸cão entre o componente normal CN e o componente excepcional CE, através do conector interno ConInt.

1 . . .

2 CN. s p e c . prov . IManager cn = CN. impl . ComponentFactory . c r e a t e I n s t a n c e ( ) ; 3 CE. s p e c . prov . IManager c e = CE . impl . ComponentFactory . c r e a t e I n s t a n c e ( ) ; 4 ConInt c o n I n t = new ConInt ( c e . g e t P r o v i d e d I n t e r f a c e ( ‘ ‘ IPCE ’ ’ ) ) ;

5 cn . s e t R e q u i r e d I n t e r f a c e ( c o n I n t ) ;

Figura 3.29: Exemplo em Java da Liga¸c˜ao entre dois Componentes

Por apresentar uma visão integrada dos componentes normal e excepcional, a partir desse momento é poss´ıvel realizar testes de unidade relativos aos componentes arquiteturais do sistema, isto é, testar os componentes tolerantes a falhas ideais como unidades de implementa¸cão.

3.8.2 Materializar a Configura¸c˜ao do Sistema (ativ. 7.2)

Apesar das dependências excepcionais terem sido supridas na atividade anterior de montagem dos componentes arquiteturais (Se¸cão 3.8.1), ainda nos falta materializar as conexões entre esses componentes do sistema. Essas conexões são realizadas através de liga¸cões entre as interfaces requeridas normais de um componente e as respectivas interfaces providas de outros. Dessa forma, a materializa¸cão das configura¸cões do sistema consiste de três atividades: (i) finalizar a especifica¸cão dos conectores arquiteturais; (ii) implementar esses conectores; e (iii) implementar o programa principal.

Por representar o elo de comunica¸cão entre componentes arquiteturais, os conectores são os únicos componentes do sistema que possuem o conhecimento dos fluxos interativos entre os componentes. Dessa forma, como discutido no decorrer desse cap´ıtulo, eles são considerados os locais ideais para a implementa¸cão dos requisitos de qualidade do sistema, tais como tolerância a falhas e disponibilidade. Boa parte da especifica¸cão dos conectores foi definida durante a análise do aspecto interativo entre os componentes (Se¸cão 3.6.1), mas dada a sua importância, ele ainda deve ser refinado.

No contexto espec´ıfico do desenvolvimento de sistemas robustos, a especifica¸cão dos conectores deve ser refinada para oferecer o tratamento inter componentes, proposto por Asterio et al. (Se¸cão 2.4.3). Isso é necessário, uma vez que no desenvolvimento desses sistemas, deve-se supor a ocorrência de exce¸cões não previstas na especifica¸cão. Para essas exce¸cões não antecipadas, o desenvolvedor deve seguir as diretrizes de conversões excepcionais mostradas na Tabela 2.4 para definir exce¸cões que representem esses novos pontos de sa´ıda excepcionais.

Além disso, o fato dos data types ficarem dentro do componente e a estrutura de pacotes fazer parte do nome da classe, ainda que dois data types possuam nome e estrutura semelhantes, é necessário definir as conversões entre eles, através da instancia¸cão do tipo exato de cada componente. Finalmente, durante o refinamento de suas especifica¸cões, os conectores devem adequar o seu comportamento à rigorosidade do método em rela¸cão às exce¸cões arquiteturais. Essa rigorosidade, que foi definida na Se¸cão 3.6.1 (ativ. 5.1.4), diz respeito tanto às reconfigura¸cões dos componentes do sistema, quanto à execu¸cão redundante de componentes.

Dessa forma, nos casos de reconfigura¸cão, se houver mais de uma implementa¸cão dispon´ıvel de algum componente, deve-se escolher a ordem de cada uma na reconfigura¸cão. Além disso, a forma como os componentes poderão ser reconfigurados pode variar de acordo com a classifica¸cão da falha da exce¸cão, definida na identifica¸cão de exce¸cões, durante a defini¸cão dos requisitos do sistema (Se¸cão 3.2.4). O método MDCE+ define dois tipos de reconfigura¸cão: (i) permanente; e (ii) temporária.

Nas reconfigura¸cões permanentes, as réplicas assumem o lugar do componente fa- lho de forma definitiva, isto é, nas próximas requisi¸cões desse servi¸co, o conector chamará diretamente a última réplica que funcionou corretamente. Já no caso de uma reconfigura¸cão temporária, as réplicas só desempenham o papel do componente principal durante uma execu¸cão espec´ıfica. Dessa forma, nas próximas requisi¸cões, o conector con- fiará a execu¸cão do servi¸co ao componente principal, independentemente dele ter falhado na tentativa anterior. As Figuras 3.30 e 3.31 mostram respectivamente os diagramas de seqüência relativos aos dois tipos de reconfigura¸cão.

Vale a pena ressaltar o fato de que mesmo que não exista mais de uma implementa¸cão do componente dispon´ıvel, no caso de haver falhas com gravidade alta, o conector deve oferecer o tratamento arquitetural do sistema a partir da re-instancia¸cão do componente seguida de uma nova tentativa de execu¸cão27_.

Outra observa¸cão importante, do ponto de vista do refinamento da especifica¸cão dos conectores é que no caso de sistemas com requisitos cr´ıticos de confiabilidade28_{, a especi-}

fica¸c˜ao dos conectores deve prever a implementa¸c˜ao dos mecanismos de arbitragem, que

do inglˆes Re-try

3.9. Materializa¸c˜ao da Arquitetura Confi´avel Adotada 105

No documento Um metodo para modelagem de exceções em desenvolvimento baseado em componentes (páginas 119-123)