A Figura 4.6(a) mostra as interfaces criadas durante a execu¸c˜ao desse est´agio da especifica¸c˜ao. Em seguida, a Figura 4.6(b) mostra os componentes criados para oferecˆe- las. << interface >> IOperacoesVendas +efetuarVenda():void << interface >> IGerenciamentoVendas << interface interface_handler >> ITratamentoVendas +tratarEstoqueBaixo():void (a) << component >> operacoesVendas IOperacoesVendas << component >> gerenciamentoVendas IGerenciamentoVendas << component handler >> tratadorVendas ITratamentoVendas (b)
Figura 4.6: Interfaces Identificadas e Componentes Criados
4.7
Fase 5:
Intera¸c˜ao Entre os Componentes
Devido `a similaridade entre os objetivos das duas atividades, a etapa de intera¸c˜ao entre os componentes do processo adaptado pode se basear no workflow mostrado na Se¸c˜ao 3.6.1 do m´etodo MDCE+. Como pode ser visto a´ı, do ponto de vista da arquitetura do sis- tema, esse est´agio desempenha as atividades necess´arias para o seu refinamento. Isso se deve porque durante as intera¸c˜oes entre os componentes ´e poss´ıvel analisar o fluxo de informa¸c˜ao que flui na arquitetura, seja ele normal ou excepcional. Atrav´es da an´alise desses fluxos, s˜ao identificadas as dependˆencias entre os componentes do sistema. Al´em disso, com uma abordagem sistem´atica de an´alise do fluxo excepcional ´e poss´ıvel identifi- car precocemente a existˆencia de falhas de especifica¸c˜ao. Exemplos comuns dessas falhas podem ser o esquecimento de especificar um tratador, ou a especifica¸c˜ao de tratadores que nunca s˜ao utilizados.
Enquanto no processo UML Components as colabora¸c˜oes s˜ao representadas atrav´es de diagramas de colabora¸c˜ao UML, o m´etodo MDCE+ prop˜oe a representa¸c˜ao atrav´es de diagramas de atividades, que proporcionam uma maior representa¸c˜ao semˆantica da seq¨uˆencia de execu¸c˜ao. Por esse motivo, o processo adaptado sugere a representa¸c˜ao das intera¸c˜oes atrav´es de diagramas de atividades, mas nada impede que essa tarefa continue sendo feita utilizando os outros diagramas dinˆamicos da UML (de seq¨uˆencia ou colabora¸c˜ao). As Figuras 4.7 e 4.8 mostram os diagramas de atividades referentes `as colabora¸c˜oes das opera¸c˜oes relativas aos casos de uso Efetuar Venda e Tratar Estoque Baixo. Atrav´es da an´alise dessas intera¸c˜oes, ´e poss´ıvel refinar quatro aspectos importantes
gerenciamentoVendas operacoesVendas
efetuarVenda(codCli: String, itens: ItemVenda[])
void debitarEstoque (codProduto: String, quant:int)
void emitirNotaFiscal
(cliente: DadosCliente, valor: float)
gerenciamentoCliente
DadosCliente obterCliente (id: String)
Fim
Figura 4.7: Colabora¸c˜ao da opera¸c˜ao Efetuar Venda
tratadorVendas operacoesVendas void reporEstoque (codProduto: String) tratarEstoqueBaixo (e: EstoqueBaixoException) Fim
Figura 4.8: Colabora¸c˜ao da opera¸c˜ao Tratar Estoque Baixo
da especifica¸c˜ao do sistema: (i) as opera¸c˜oes das interfaces da camada de neg´ocio; (ii) o refinamento da assinatura das opera¸c˜oes de sistema, que inclui a defini¸c˜ao das estruturas de dados utilizadas; (iii) a conseq¨uente lista das dependˆencias de cada opera¸c˜ao do sistema; e (iv) a necessidade de se especificar novas funcionalidades requeridas, isto ´e, de se refinar a especifica¸c˜ao dos requisitos.
A Figura 4.9(a) mostra as interfaces de neg´ocio com as opera¸c˜oes identificadas. A mesma figura (b) mostra as interfaces de sistema com as assinaturas das suas opera¸c˜oes j´a refinadas e a lista de dependˆencias de cada uma. Em rela¸c˜ao ao refinamento dos requi- sitos, como pode ser visto na Figura 4.8, o tratamento excepcional especificado necessita executar um servi¸co do sistema que ainda n˜ao foi especificado. Por esse motivo, o processo deve iterar com o intuito de especificar o caso de uso Repor Estoque.
Ap´os a defini¸c˜ao das dependˆencias entre as opera¸c˜oes dos componentes, o m´etodo prossegue com a an´alise do fluxo excepcional entre os componentes. Ap´os essa an´alise, j´a se pode estruturar os componentes arquiteturais do sistema, segundo o modelo do componente tolerante a falhas ideal apresentado na Se¸c˜ao 2.3.7. A Figura 4.10 mostra a estrutura¸c˜ao do componente arquitetural operacoesVendasArq, que como definido no est´agio anterior, pertence `a camada de sistema. Na Figura 4.11, as dependˆencias entre
4.7. Fase 5: Intera¸c˜ao Entre os Componentes 127 << interface >> IOperacoesVendas +void reporEstoque(codProduto:String):void +efetuarVenda(codCli:String,itens:ItemVenda[]):void << interface >> IGerenciamentoVendas +void debitarEstoque(codProduto:String,quant:int):void +void emitirNotaFiscal(cliente:DadosCliente,valor:float):void << interface >> IGerenciamentoCliente +DadosCliente obterCliente(id:String):void
throws EstoqueBaixoException, EstoqueInsuficienteEsception
throws ClienteNaoCadastradoException throws VendaNaoEfetuadaException
(a) (b)
Figura 4.9: Atualiza¸c˜ao das Interfaces (Neg´ocio e Sistema)
as opera¸c˜oes das interfaces s˜ao utilizadas para refinar a representa¸c˜ao da arquitetura do sistema. Note que s´o s˜ao representados os componentes arquiteturais.
<< component architectural >> operacoesVendasArq << component handler >> tratadorVendas << component >> operacoesVendas IExcepcionalReq IOperacoesVendas
Figura 4.10: Estrutura¸c˜ao do Componente Arquitetural Efetuar Venda
Com uma defini¸c˜ao clara das dependˆencias de cada componente, ´e poss´ıvel revisar a lista de entidades cr´ıticas, de acordo com as funcionalidades cr´ıticas especificadas na Se¸c˜ao 4.4. Seguindo as atividades do m´etodo MDCE+, a Figura 4.12 mostra o modelo do neg´ocio com as novas entidades cr´ıticas identificadas. S´o a t´ıtulo de recorda¸c˜ao, a identifica¸c˜ao dessas se d´a a partir dos componentes de neg´ocio dos quais as funcionalidades cr´ıticas dependem.
Ap´os o refinamento das entidades cr´ıticas do sistema, ´e poss´ıvel escolher o n´ıvel de criticidade em que o processo deve se basear para continuar as atividades de especifica¸c˜ao. Por ser um sistema web com requisitos de disponibilidade, suas funcionalidades devem estar dispon´ıveis o maior tempo poss´ıvel. Dessa forma, o sistema foi classificado como cr´ıtico e conforme indicado nas diretrizes da Se¸c˜ao 3.6.1 do m´etodo MDCE+, durante a defini¸c˜ao dos componentes redundantes, ser´a necess´ario ter uma r´eplica do componente de sistema relativo ao caso de uso Efetuar Venda. Essas r´eplicas representar˜ao a execu¸c˜ao do mesmo servi¸co em lojas distintas da empresa.
<< component >> servicosDeSistema << component >> operacoesVendasArq << component >> servicosDeNegocio << component >> gerenciamentoVendasArq << component >> gerenciamentoClienteArq IGerenciamentoVendas IGerenciamentoCliente IOperacoesVendas
Figura 4.11: Arquitetura Refinada do Sistema
Conta −numero:. << critical >> Cliente NotaFiscal −numero:. << critical >> Venda Produto −quantidade:. Preço 1
Figura 4.12: Novas Entidades Cr´ıticas Identificadas
identificar as interfaces requeridas de cada componente. Essa atividade, que n˜ao est´a presente no processo UML Components, tem uma interferˆencia direta na cria¸c˜ao dos co- nectores arquiteturais. Essa cria¸c˜ao s´o acontecer´a na fase de montagem mostrada na Se¸c˜ao 4.10. A Figura 4.13 mostra o componente arquitetural operacoesVendas com as suas duas interfaces requeridas. A interface IReqSistema ´e decorrente da necessidade do tratador excepcional executar servi¸cos da camada de sistema (Figura 4.8). A in- terface IReqNegocio ´e conseq¨uˆencia das opera¸c˜oes requeridas pelo componente normal (Figura 4.7). Por´em, como a opera¸c˜ao requerida pelo tratador faz parte do mesmo com- ponente normal, do ponto de vista externo ao componente arquitetural, essa dependˆencia n˜ao existe.
Devido `a simplicidade do exemplo, n˜ao foi necess´ario simplificar o modelo de falhas do sistema de vendas. Al´em disso, por n˜ao haver necessidade de execu¸c˜ao concorrente,
4.8. Fase 6: Especifica¸c˜ao Final do Sistema 129