Intera¸c˜ao entre os Componentes

Como visto na Se¸c˜ao 4.7, o objetivo deste est´agio da especifica¸c˜ao ´e analisar o fluxo de informa¸c˜ao que flui entre os componentes do sistema, sejam eles normais ou excepcionais. Atrav´es da an´alise desses fluxos, s˜ao identificadas as opera¸c˜oes dos componentes da ca- mada de neg´ocio. Al´em disso, as assinaturas das opera¸c˜oes dos componentes da camada de sistema s˜ao refinadas. De forma complementar, s˜ao especificadas as dependˆencias entre os componentes do sistema. Atrav´es dessas dependˆencias, s˜ao produzidos dois ar- tefatos importantes da fase de especifica¸c˜ao: (i) os componentes arquiteturais, atrav´es das dependˆencias entre os componentes normais e excepcionais; e (ii) a configura¸c˜ao da arquitetura do sistema, atrav´es das dependˆencias entre os componentes normais.

Inicialmente, conforme proposto pelo m´etodo MDCE+, a intera¸c˜ao entre os compo- nentes ´e documentada atrav´es de diagramas de atividades UML. A Figura 5.9 mostra a intera¸c˜ao realizada a partir da simula¸c˜ao da opera¸c˜ao cancelarContrato(), relativa ao caso de uso Cancelar Contrato da Conta. Nessa figura, a detec¸c˜ao das exce¸c˜oes n˜ao est´a representada. A representa¸c˜ao completa da intera¸c˜ao pode ser vista na Figura 5.10.

ITOControleAgencia recuperaAgencia (String codAgencia) void checarAgenciaAberta (ITOControleAgencia ito) ITOConta recuperaConta (ITOContaPK ito) ITOModalidade recuperaModalidade (String codModal) ITOTipoDeposito recuperarTipoDeposito (String tipoDepos) void checarContratoCancelado (ITOContaPK ito) void cancelarContrato (ITODadosCancContrato ito) [return.cadastradoNoDia == true] [return.cadastradoNoDia == false] ISBContaMgrReq ISBControleAgenciaMgrReq

5.4. Execu¸c˜ao do Estudo de Caso 149

ISBControleAgenciaMgrReq

ITOControleAgencia recuperaAgencia (String codAgencia)

TEAgenciaNaoCadastradaException

[return == TEAgenciaNaoCadastradaException]

void checarAgenciaAberta (ITOControleAgencia ito)

TEAgenciaNaoEstaAbertaException

[return == TEAgenciaNaoEstaAbertaException]

ITOConta recuperaConta (ITOContaPK ito)

TEContaNaoCadastradaException [return == TEContaNaoCadastradaException]

ITOModalidade recuperaModalidade (String codModal)

TEModalidadeNaoCadastradaException [return == TEModalidadeNaoCadastradaException]

ITOTipoDeposito recuperarTipoDeposito (String tipoDepos)

TEContratoINEstaCanceladoException [return == TEContratoINEstaCanceladoException]

void checarContratoCancelado (ITOContaPK ito)

TEContratoINEstaCanceladoException [return == TEContratoINEstaCanceladoException]

void cancelarContrato (ITODadosCancContrato ito) [return.cadastradoNoDia == true] [return == TETransacaoNaoFoiConcluidaException] [return.cadastradoNoDia == false] TETransacaoNaoFoiConcluidaException [return == TETransacaoNaoFoiConcluidaException] ISBContaMgrReq ISBControleAgenciaMgrReq TETransacaoNaoFoiConcluidaException

Al´em da representa¸c˜ao do comportamento normal dos componentes, durante a in- tera¸c˜ao entre os componentes devem ser modeladas as intera¸c˜oes dos tratadores de exce¸c˜oes. Devido `as exce¸c˜oes identificadas at´e o momento n˜ao possu´ırem um tratamento espec´ıfico, at´e este momento, a representa¸c˜ao dessas intera¸c˜oes n˜ao foi necess´aria. A seguir, na fase de montagem do sistema (Se¸c˜ao 5.4.8), ser´a representada a colabora¸c˜ao relativa ao tratador da exce¸c˜ao TETransacaoNaoFoiConcluidaException, que ser´a identificado adiante.

Com a an´alise das intera¸c˜oes especificadas nesta fase, foi poss´ıvel refinar as interfaces do sistema. Esse refinamento consistiu tanto na descoberta das opera¸c˜oes do neg´ocio, quanto no refinamento das assinaturas das opera¸c˜oes de sistema. As interfaces refinadas s˜ao mostradas na Figura 5.11. Durante esse refinamento, percebeu-se a necessidade de se criar alguns tipos estruturados de dados, que na terminologia do UML Components s˜ao conhecidos como data types. A Figura 5.12 mostra os tipos de dados utilizados nas opera¸c˜oes envolvidas na intera¸c˜ao.

sistema

<< interface >>

ISBCancelaContratoContaMgr

+ cancelarContratoConta (ito :ITOCancContratoDia ):void

negocio

<< interface >>

ISBControleAgenciaMgrReq

+ recuperaAgencia (codAgencia :String ):ITOControleAgencia + checarAgenciaAberta (ito :ITOControleAgencia ):void

<< interface >>

ISBContaMgrReq

+ recuperaConta (ito :ITOContaPK):ITOConta + recuperaModalidade (codModal :String ):ITOModalidade + recuperarTipoDeposito (tipoDepos :String ):ITOTipoDeposito + checarContratoCancelado (ito :ITOContaPK):void + cancelarContrato (ito :ITODadosCancContrato ):void

Figura 5.11: Interfaces Refinadas com a Colabora¸c˜ao

Com as dependˆencias entre os componentes j´a identificadas, ´e chegado o momento de especificar os componentes arquiteturais e a arquitetura do sistema. O componente arquitetural operacoesContaArq ´e mostrado na Figura 5.13. Ap´os isso, s˜ao definidas as interfaces requeridas de cada componente. Seguindo as diretrizes do m´etodo MDCE+, deve ser especificada uma interface para cada camada da arquitetura que o componente interage. A Figura 5.14 mostra as interfaces requeridas pelo componente operacoesConta- Arq. Nessa figura ´e poss´ıvel perceber a contextualiza¸c˜ao do componente na arquitetura, atrav´es dos componentes que oferecem as suas interfaces requeridas. Essas liga¸c˜oes entre os componentes s˜ao representadas atrav´es de dependˆencias UML.

Em rela¸c˜ao `a revis˜ao do modelo de falhas, durante a an´alise das propaga¸c˜oes das exce¸c˜oes, foram identificadas duas exce¸c˜oes novas: (i) TETipoDepositoNaoCadastrado- Exception e (ii) TETaxaInvalidaException. Essas exce¸c˜oes s˜ao conseq¨uˆencia da pro-

5.4. Execu¸c˜ao do Estudo de Caso 151 ITOCancContratoDia + indIsentoTxADP :boolean + indIsentoTxSAQ :boolean + indTxPadADP :boolean + indTxPadSAQ :boolean + taxaPadADP:java.math.BigDecimal + taxaPadSAQ:java.math.BigDecimal + cadastradaNoDia :boolean ITOConta + codModal :String + tipoDepos :int + isTalaoBloqueado :boolean + isSolicitacaoAutomaticaTalao :boolean + status :int + codCliente1 :String + codCliente2 :String + maxTaxaADP :java.math.BigDecimal + maxTaxaSAQ :java.math.BigDecimal ITOControleAgencia + codColigada :String + codAgencia :String ITOTipoDeposito + tipoDepos :int + tipoPessoa :int ITODadosCancContrato + nomeUsuario :String + dataAtu :java.util.Date + codModalOri :String ITOContaPK + codColigada :String + codAgencia :String + nroConta :String ITOModalidade + codModal :String + tipoPessoa :int + especie :String + permiteLimiteAdc :boolean

Figura 5.12: Tipos de Dados Necess´arios

paga¸c˜ao de outras situa¸c˜oes excepcionais que podem ocorrer durante o acesso aos dados, que ´e feito pelos componentes da camada de persistˆencia (Figura 5.4).

Al´em disso, devido ao requisito de disponibilidade da opera¸c˜ao cancelarContrato(), foi especificado um novo tratador para a exce¸c˜ao TETransacaoNaoFoiConcluidaException. Como pode ser visto na especifica¸c˜ao desse tratador, apresentada na Tabela 5.5, esse tratador realiza uma reconfigura¸c˜ao entre os componentes do sistema. Por se tratar de um tratamento realizado na arquitetura de software, esse tratador n˜ao faz parte de nenhum componente excepcional e ser´a implementado no pr´oprio conector arquitetural, durante a montagem do sistema (Se¸c˜ao 5.4.8).

Tabela 5.5: Especifica¸c˜ao do Caso de Uso Tratar Erro de Cancelamento de Contrato

Tratar Erro de Cancelamento de Contrato

Descri¸c˜ao: Ocorre uma tentativa de reconfigurar o sistema para utilizar um com- ponente redundante. Em seguida, tenta-se executar a funcionalidade novamente.

Participantes: Operador. Pr´e-condi¸c˜oes: Nenhuma. Invariantes: Nenhuma. Cen´ario prim´ario:

1- Reconfigurar os componentes do sistema; 2- Tentar a execu¸c˜ao novamente;

3- Se n˜aoconseguiu E n˜ao tem como reconfigurar;

3.1- Propagar exce¸c˜ao TETransacaoNaoFoiConcluidaException. P´os-condi¸c˜oes: O servi¸co foi executado normalmente, isto ´e, de forma transparente

<< component >> operacoesContaArq ITEModalidadeInvalidaException << component >> tratadorCliente << component >> tratadorTransacao ITECodClienteInvalidoException ITETipoPessoaNaoCorrespondeTipoPessoaContaException << component >> tratadorAgencia ITEAgenciaInvalidaException ITEContaInvalidaException ITETransacaoNaoFoiCohcluidaException ITEContratoJaEstaCanceladoException << component >> tratadorConta ITEAgenciaNaoEstaAbertaException << component >> operacoesConta IExcepcionalReq ISBCancelaContratoContaMgr ISBCadLimiteAdcMgr

Figura 5.13: Componente Arquitetural operacoesContaArq

<< component >> operacoesContaArq INegociosReq IUtilReq << component >> operacoesUtil << component >> gerenciamentoConta << component >> gerenciamentoControleAgencia

Figura 5.14: Interfaces Requeridas do Componente operacoesContaArq

Ap´os a an´alise das propaga¸c˜oes das exce¸c˜oes, o pr´oximo passo para o refinamento do modelo ´e a classifica¸c˜ao das exce¸c˜oes em dois grupos: (i) exce¸c˜oes arquiteturais e (ii) exce¸c˜oes n˜ao-arquiteturais. A Tabela 5.6, apresenta a lista completa das exce¸c˜oes com as respectivas classifica¸c˜oes em um desses dois grupos. Como visto nessa tabela, apesar do grande n´umero de exce¸c˜oes identificadas no decorrer da especifica¸c˜ao, do ponto de vista da arquitetura do sistema, existe um n´umero relativamente reduzido de exce¸c˜oes. Isso se deve ao fato da maioria das exce¸c˜oes n˜ao ser tratada em nenhum contexto, sendo utilizadas somente para documentar o modelo de falhas e registrar os erros ocorridos atrav´es do logging de suas informa¸c˜oes contextuais.

5.4. Execu¸c˜ao do Estudo de Caso 153

Tabela 5.6: Classifica¸c˜ao das Exce¸c˜oes de Acordo com a Propaga¸c˜ao

Excec¸˜ao Classificac¸ ˜ao TEAgenciaNaoEstaAbertaException n˜ao-arquitetural TEAgenciaInvalidaException arquitetural TEAgenciaNaoCadastradaException n˜ao-arquitetural TEContaInvalidaException arquitetural TEContaNaoCadastradaException n˜ao-arquitetural TEUsuarioInvalidoException arquitetural TETransacaoNaoFoiConcluidaException arquitetural TEModalidadeNaoCadastradaException n˜ao-arquitetural TETaxaDeveSerMaiorZeroException n˜ao-arquitetural TEModalidadeInvalidaException arquitetural TEModalidadeIgualModalidadeContaException n˜ao-arquitetural TETipoPessoaNaoCorrespondeTipoPessoaContaException n˜ao-arquitetural TEContratoINEstaCanceladoException n˜ao-arquitetural TETipoDepositoNaoCadastradoException n˜ao-arquitetural TETaxaInvalidaException arquitetural