Atividades Comuns (reutiliza¸c˜ao ou implementa¸c˜ao)

Independente da forma como os componentes ser˜ao materializados, os contratos estabele- cidos entre eles durante a especifica¸c˜ao do sistema devem ser mantidos. Essa necessidade de se satisfazer os contratos torna obrigat´oria a especifica¸c˜ao dos tipos de dados22 _dos

parˆametros e do retorno, presentes na assinatura especificada durante a an´alise intera- tiva entre os componentes (Se¸c˜ao 3.6.1). Al´em disso, devem ser definidas as classes das exce¸c˜oes arquiteturais, que podem fluir entre componentes distintos do sistema. Conforme

21

do inglˆes System availability

22

definido na an´alise das propaga¸c˜oes excepcionais (Se¸c˜ao 3.6.1), essas exce¸c˜oes devem ser explicitadas nas assinaturas dos m´etodos. A Figura 3.22 mostra as atividades executadas nessa etapa.

Início

6.1: Criar os data types

6.2: Criar as classes de exceções

6.3: Posicionar as exceções na hierarquia proposta

Fim

Figura 3.22: Atividades Comuns (reutiliza¸c˜ao e implementa¸c˜ao)

A cria¸c˜ao dos tipos de dados utilizados pelo componente consiste de um procedimento simples. Para isso, deve-se analisar a assinatura de cada um dos servi¸cos oferecidos pelo componente. Em seguida, para cada tipo de dado utilizado, deve-se analisar a possi- bilidade de cria¸c˜ao ou atualiza¸c˜ao da sua classe correspondente. Essa atualiza¸c˜ao pode ser necess´aria no contexto de refinamentos feitos em itera¸c˜oes posteriores do desenvolvi- mento. A classe que representa a estrutura de dados deve possuir os atributos relativos aos seus campos especificados. Com o intuito de conciliar a facilidade de implementa¸c˜ao e o encapsulamento da informa¸c˜ao, caso a linguagem ofere¸ca esse recurso, a visibilidade dos atributos dos data types deve ser definida como p´ublicas para leitura, mas na ausˆencia desse tipo, deve ser considerada p´ublica. Esse “relaxamento” visa facilitar a implementa¸c˜ao dos conectores, que realizam convers˜oes de tipos constantemente. Em rela¸c˜ao `a visibilidade da classe, ela deve ser definida como visibilidade de pacote, uma vez que a sua instancia¸c˜ao deve ocorrer por interm´edio da classe DatatypeFactory, que por sua vez deve ser vis´ıvel publicamente.

Da mesma forma que aconteceu com os tipos de dados, mesmo que um componente seja reutilizado, ´e necess´ario especificar as classes das exce¸c˜oes que cada um dos servi¸cos do componente pode propagar. Deve-se atentar `a necessidade de se implementar os atributos relativos `as informa¸c˜oes contextuais de cada exce¸c˜ao, conforme especificado durante o

3.7. Fase 6: Materializa¸c˜ao dos Componentes 95

processamento das exce¸c˜oes agendadas (Se¸c˜ao 3.5.1) e refinado durante a an´alise das propaga¸c˜oes excepcionais, feita na Se¸c˜ao 3.6.1. Diferentemente do caso dos data types, esses atributos n˜ao podem possuir visibilidade de pacote, uma vez que essas classes ter˜ao seus atributos consultados constantemente pelos seus tratadores, que s˜ao implementados fora do componente. Assim, na impossibilidade de se especificar a visibilidade como sendo p´ublica para leitura, ela deve ser considerada p´ublica.

Em rela¸c˜ao ao procedimento de atualiza¸c˜ao do contexto, normalmente ele ´e efetuado no momento do lan¸camento da exce¸c˜ao e nos conectores arquiteturais, que fazem o ma- peamento entre os diferentes modelos de falhas dos sub-sistemas (Se¸c˜ao 3.8.2). Com essa abordagem adotada pelo m´etodo, as informa¸c˜oes contextuais acompanham os pr´oprios objetos das exce¸c˜oes. Assim, elas podem ser acessadas e atualizadas atrav´es da interface p´ublica dessas classes.

Independentemente da visibilidade de seus atributos, as classes de exce¸c˜oes devem possuir visibilidade de pacote. Isso acontece porque elas s˜ao posicionadas em um pacote excep, interno ao pacote impl do COSMOS (Figura 3.23). Da mesma forma como acon- tece com as classes de implementa¸c˜ao, o acesso `as exce¸c˜oes deve acontecer atrav´es de um factory, denominado ExceptionFactory.

a a.impl Manager ComponentFactory << instanciate >> . << use >> . << instanciate >> . FacadeI1 << use >> . << use >> . ObjectFactory ClassA << instanciate >> . << instanciate >>. a.spec a.spec.prov I1 IManager dataTypes excep ExceptionFactory ExceptionA << use >> . << instanciate >> . DatatypeFactory << instanciate >> . << use >> . Datatype1 a.spec.req I2 excep IE1 << use >> . << use >> . . I2 I1 << component >> A .

Figura 3.23: Novo Modelo de Implementa¸c˜ao do COSMOS

Ap´os a cria¸c˜ao da classe e a atualiza¸c˜ao da ExceptionFactory, cada exce¸c˜ao deve ser posicionada na hierarquia adotada pelo m´etodo MDCE+. Para possibilitar a estrutura¸c˜ao de exce¸c˜oes simples e compostas, o m´etodo MDCE+ prop˜oe uma hierarquia excepcional.

RootException DeclaredException UndeclaredException RejectedRequestException FailureException RecoveredFailureException UnrecoveredFailureException Single Composed Single Composed

Single Composed Single Composed

Figura 3.24: Modelagem de Classes de Exce¸c˜oes Simples e Compostas

Essa hierarquia, mostrada na Figura 3.24, concilia a sistem´atica de classifica¸c˜ao dos ti- pos excepcionais apresentada na Se¸c˜ao 2.4.1, com a possibilidade de declarar exce¸c˜oes compostas atrav´es do padr˜ao de projeto Composite [GHJV95].

Os principais benef´ıcios decorrentes da utiliza¸c˜ao da hierarquia excepcional sugerida s˜ao:

• Uniformidade. Gra¸cas `a estrutura¸c˜ao mostrada na Figura 3.24, as exce¸c˜oes simples e compostas s˜ao especificadas de maneira uniforme.

• Simplicidade. Os grafos de resolu¸c˜ao s˜ao definidas mais facilmente.

• Reusabilidade e Extensibilidade. A representa¸c˜ao de exce¸c˜oes simples e com- postas na forma de classes proporcionam a reutiliza¸c˜ao dos grafos de resolu¸c˜ao em v´arias colabora¸c˜oes e/ou conectores.

• Legibilidade e Manutenibilidade. A representa¸c˜ao de exce¸c˜oes atrav´es de ob- jetos ´e mais f´acil de entender. Principalmente quando comparados com outras re- presenta¸c˜oes, como por exemplo a representa¸c˜ao atrav´es de f lags, onde o valor de retorno pode representar um significado normal ou excepcional [GRRX01].