Exceções e Alternativas previstas
Muito se discute acerca do uso adequado de fluxos de exceção em Caso de Uso.
É muito comum os analistas de sistemas generalizarem muitos cenários como fluxos alternativos, considerando que, se uma determinada situação é prevista pelo negócio, então deve ser tratado como regra, nunca na exceção.
Fluxo Alternativo deve ser relacionado à alternativa, literalmente.
Considerando um Caso de Uso acionado por um ator humano, é como se ele pudesse escolher um caminho entre: ir para a direita, ir para a esquerda ou seguir reto.
Como um Caso de Uso possui obrigatoriamente um Fluxo Principal (ou Fluxo Básico, ou Fluxo Ótimo), neste contexto poderia ser a opção de “seguir reto”, e “ir para direita” e “ir para a esquerda” se tornariam fluxos alternativos. Mas não seria uma alternativa para o usuário “cair no buraco”.
“Cair no buraco” seria uma exceção, e não uma alternativa. Mas a possibilidade de “cair no buraco” é prevista pelo negócio, certo? Certo, mas nem por isso é uma alternativa a ser escolhida – é uma possível consequência de uma alternativa escolhida previamente.
/* Para entender melhor o fluxo alternativo veja nosso post Caso de Uso – Fluxo Alternativo. */
/* Para entender melhor o que é um Caso de Uso, veja O que é Caso de Uso. */
As Exceções de verdade
Alguns profissionais de software consideram exceções como bug’s (ou erros, ou defeitos) somente, onde caso ocorra um erro em determinado fluxo de execução do sistema, aí entra o fluxo de exceção.
Sim, este contexto (o erro no sistema) é de fato um fluxo de exceção – que acho importante sempre estar claro no Caso de Uso – é útil para evitar futuros desentendimentos com usuários que podem achar que nunca ocorrerão problemas na execução, e também com desenvolvedores, que podem alegar que “ninguém pediu” para colocar o fluxo dentro de um try/catch [lembrando que tratamento de exceção é default (algo implícito, não precisa ser especificado); salvo raras situações, não vejo necessidade de especificar isso]).
Mas erro não é o único caso de exceção.
A seguir vamos analisar um exemplo didático para entender um pouco melhor como um fluxo de exceção previsto pelo negócio pode ser trabalhado num Caso de Uso.
Exemplificando
No diagrama ao lado temos um contexto de Pagamento,onde existem quatro Casos de Uso, sendo um acessado diretamente pelo ator, e outros três, acessados por um caso de uso.
Isso quer dizer que o “Cliente” pode optar por três formas de pagamento diferentes: Pagar com Cartão de Crédito, Pagar Cartão de Débito ou Pagar com Pagar com Débito em Conta (transferência bancária).
Abaixo o corpo do caso de uso “Realizar Pagamento”:
Vemos que o Fluxo Principal é a realização do pagamento com Cartão de Crédito (que aciona o caso de uso correspondente, veja o link).
Observe que existem dois fluxos alternativos chamados do mesmo passo (step 2) que aciona o caso de uso de pagamento com Cartão de Crédito: pagamento com Cartão de Débito e Débito em Conta.
Temos também dois fluxos de exceção: o FE001 trata a possibilidade de haver algum erro (pensem em exception de software mesmo), e o FE002, trata a possibilidade de haver erro no processamento do pagamento.
Vejamos as exceções previstas para cada um dos Casos de Uso de pagamento.
Em vermelho destaquei os três cenários previstos como exceção. São exceções pelo fato de que o negócio considera estas possibilidades, mas o objetivo de negócio não é executar as exceções, e sim ter êxito no pagamento por Cartão de Crédito.
É como o “cair no buraco” que citei no início do post. Ninguém quer cair no buraco, não é o objetivo, mas como consequência de se ir para um caminho ou para outro, pode acontecer.
A seguir, um exemplo de uma especificação básica (didática) do step FE001 – Número inválido.
Em tempo de modelagem de Caso de Uso, basicamente o nível de detalhe a ser considerado numa exceção pode ser da mensagem que a exceção gerará e o que o fluxo de exceção retornará ao seu chamador.
Quanto ao retorno, num caso de uso que irá direto para construção pode-se descer mais o nível, especificando detalhes de gravação de log, rollback em transações etc.).
Se o número do cartão está inválido, então isso é tratado. O caso de uso chamador (ou o ator, se fosse o caso) recebe o retorno negativo e fim de papo.
O importante é o que o cenário foi previsto, houve o devido cuidado em sua descrição, e a especificação ficou clara.
Abaixo as ilustrações dos outros Casos de Uso e seus fluxos de exceção, apenas para conhecimento.
Sempre haverão Exceções nas Regras de Negócio
Dentro das possibilidades, as exceções devem ser previstas e tratadas.
/* Cito “dentro das possibilidades” pois sabemos que nem sempre conseguiremos prever todas, e nem sempre haverá o tempo que seria suficiente para trabalhar na melhor especificação. */
Um software nunca cobrirá todas as possibilidades de exceção à regras de negócio, mas quanto mais possibilidades forem previstas e tratadas, melhor. Isso aumenta linearmente a qualidade do produto final do projeto.
Saber identificar e especificar corretamente os fluxos de exceção é algo que gera inúmeros benefícios ao projeto e ao analista.
Concluindo
Por uma questão natural, do comportamento humano, temos como costume pensar apenas nos melhores caminhos, nos caminhos mais felizes, na forma que queremos que as coisas aconteçam.
Somos otimistas! Não gostamos de pensar que algo pode dar errado. E isso acontece na mente do Analista de Sistemas, toda hora.
/* Uma forma de perceber isso é buscar cenários de um Caso de Uso especificado (prontos, já escrito), em livros, internet, empresa etc. Facilmente percebe-se que a maioria dos Casos de Uso possui Fluxo Principal e Fluxo Alternativo, e quando há Fluxo de Exceção é raridade. */
Uma vez entendido o que é uma exceção de fato, através da repetição no dia a dia (criando assim o hábito), muito provavelmente o profissional identificará Fluxos de Exceção que jamais pensou existir, e verá que, com essa prática, muito daquilo que poderia se tornar um defeito (bug) com o sistema em produção, foi previsto, tratado corretamente no projeto de software.
Para entender melhor o que é um fluxo principal veja Caso de Uso – Fluxo Principal.
Para entender melhor o que é um fluxo alternativo veja Caso de Uso – Fluxo de Alternativo.
Abraços!