Caso de Uso – Fluxo de Exceção

Compartilhe!

Caso de Uso - Fluxo de Exceção

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

Caso de Uso - Fluxo de Exceção - Diagrama de Caso de Uso

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”:

Caso de Uso - Fluxo de Exceção - Cenário

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.

Caso de Uso - Fluxo de Exceção - Cenário

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.

Caso de Uso - Fluxo de Exceção - Cenário

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.

Caso de Uso - Fluxo de Exceção - Cenário

Caso de Uso - Fluxo de Exceção - Cenário

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.

curso casos de uso na real

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!

caso de uso

  • Alline

    Está ótimo, parabéns!

  • Valeria

    É possível se colocar um extend como fluxo de exceção?

    FP
    O sistema valida os dados informados [FE1]

    FE1
    O sistema verifica que o dado não está cadastrado
    O sistema extend o caso de uso Cadastrar_Dado.
    O sistema retorna ao FP.

    Isso está correto?

  • Plínio Ventura

    Oi Valéria,

    Sobre um fluxo de exceção desviar para um outro caso de uso através de extensão (extends), não vejo problemas. Obs.: nunca aplicaria-se inclusão (include), pois exceção não é regra (óbvio, eu sei); se ocorresse sempre, a lógica estaria no fluxo principal.

    Imagine por exemplo um sistema onde há um requisito complexo de gravação de log para cada tentativa mal sucedida de compra de produto, e um determinado caso de uso detalhasse o comportamento da gravação de tal log. O tratamento para a tentativa mal sucedida estaria num fluxo de exceção de um caso de uso “Realizar Compra”, por exemplo, e este fluxo de exceção acionaria o caso de uso “Gravar log de compra mal sucedida” (sempre via extensão, como dito anteriormente).

    Considerando as explicações anteriores, não vejo problemas. No seu exemplo uma coisa chamou-se a atenção: ao fim do fluxo de exceção tem um “retorna ao FP”. Apenas sugiro tomar cuidado com este tipo de “link” entre FE e FP, pois pode gerar “loop infinito” no seu caso de uso, o que pode ser prejudicial ao seu modelo e sua aplicação.

  • Juliano Granadeiro

    No enterprise architect como você está fazendo para representar que em um fluxo alternativo pode acontecer um fluxo de exceção dentro de um mesmo use case.

    • Plínio Ventura

      Juliano, tudo bem? Está se referindo a linkar um fluxo alternativo num fluxo de exceção, no EA? Se for isso, infelizmente não é possível no EA, a ferramenta barra esta possibilidade. Suponho que esta trava existe para não haverem “referências circulares” entre fluxos de um mesmo caso de uso. O que faço nestes casos é linkar o fluxo de exceção no passo do fluxo principal que também linka o fluxo de exceção. Quer que eu apresente um exemplo?

  • Alethea

    Oi Plinio, tudo bem?
    Bem interessante o modo como vc escreveu. Mas tenho algumas considerações (bom… perfil de analista, sabe como é!):

    – eu cheguei no seu post pois estou fazendo uma especificação de consulta, e a equipe de qualidade está questionando por que não criei um FE para quando o sistema não encontrou registros; meu entendimento inicial era que essa situação seria um FA (apenas para exibir a mensagem), com o pensamento de que exceção seria erro. De acordo com seu texto, é uma situação prevista no sistema porém não alternativa, então seria um FE mesmo, certo?

    – vc criou o UC004 como include, mas como é opcional, deveria ser um extend… não?

    – sobre a dúvida do Juliano, aqui na empresa criaram um “padrão” no EA onde os passos do UC ficam na tab “Descrição” para poder colocar links de qualquer fluxo para qualquer fluxo

    – sobre a dúvida da Valéria: eu também nunca tinha pensado em usar chamadas em fluxos de exceção e até há um tempo atrás, sempre encerrava o caso de uso se caísse em um FE, mas nesses que tenho especificado, estou usando retornos (não gosto muito pq vira um loop, mas enfim…). Já participei de um sistema onde havia a possibilidade de criar um item caso ele não existisse na pesquisa, mas fazíamos como FA, já que era requisito criar se não existisse.

    Adorei seu blog.

    Ale

    • Plínio Ventura

      Oi Ale! Obrigado pela participação e comentários! 🙂

      A seguir minhas observações:

      Sobre a consulta, como você mesmo disse não é uma “alternativa” para o usuário. Alternativa pode ser o uso de critérios para a consulta, trazer um máximo de X registros, ordenar resultado etc. Mas não trazer registro é exceção, devendo ser tratada como tal. Penso que o questionamento do seu departamento de qualidade é pertinente.

      Sobre o UC004 como include, o fiz assim pois no fluxo principal do UC003 a forma de pagamento é com cartão de crédito. “(…)Vemos que o fluxo principal utiliza o pagamento com cartão de crédito (chamando o caso de uso correspondente, que está linkado). Mas observem que existem dois fluxos alternativos chamados do mesmo passo (step) 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 (transferência bancária)(…)”. Mas considerando que no comércio do Brasil praticamente “sempre” a forma de pagamento é selecionável, acredito que teria sido melhor eu colocar todas estas em fluxos alternativos do UC003, seria mais coerente com a nossa realidade. Mas respondendo, considerando o exemplo está correto o include, mas o exemplo não ficou bom e se fosse fazer um novo exemplo utilizaria extends.

      Sobre a dúvida do Juliano, eu já vi isto que você falou numa empresa que trabalhei alguns meses como terceiro. Eu não achei legal, é como usar o Word só para digitar ao invés de utilizar seus recursos de produtividade e formatação. Uma sugestão: tente imprimir o descritivo de casos de uso nos dois cenários (o que tem tudo na descrição e o que tem os passos estruturados) – imprimir utilizando o F8 do EA – e observe as diferenças.

      Sobre a dúvida da Valéria: penso que o uso de retornos (a fluxos alternativos ou ao principal) é válido, mas se utilizado com bom senso. O importante é verificar se realmente isso é pertinente, se realmente é de um fluxo de exceção que se irá para um fluxo alternativo ou principal.

      Que bom que gostou do blog, se animar assine nosso feed (parte superior direita da página), tem publicação de conteúdo novo toda terça e quinta.

      Abraço!

    • Juliano Granadeiro

      Alethea,
      Obrigado pela dica. Pensei nisso, mas ai acabaria perdendo o recurso da ferramenta, o qual refazer a numeração quando incluímos ou alteremos um passo. Até uma determinada versão da ferramenta, (creio que a 7.5) era possível fazer isso, agora não sei qual foi a base para incluir essa restrição.

      Quanto a sua observação do include no diagrama, compartilho da sua visão. Ali deveria ser um extend, pois o próprio passo que foi realizada a escolha pelo pagamento com o cartão de crédito.

  • Pingback: UML – Caso de Uso – Fluxo Alternativo | Até o Momento()

  • Robson Galvão

    Obrigado pelo artigo!
    Esclarecedor e objetivo!

    Mudando de assunto: acredito que o subtítulo da página está ERRADO:
    Pensando a repensando a Engenharia de Software [e relacionados]

    Não seria: “Pensando E repensando …”

    • Plínio Ventura

      Oi Robson!

      Eu quem agradeço sua visita e comentário. O subtítulo realmente estava errado, corrigi agora. Muito obrigado pelo aviso. Se tiver interesse cadastre em nosso feed, periodicamente temos novos posts no blog que podem ser úteis à você.

      Abraço!

  • Murilo

    Legal o conteúdo! Qual o nome desse software mostrado na imagem?

    • Plínio Ventura

      Oi Murilo!

      O software que utilizo para os exemplos do blog é o Enterprise Architect (http://www.sparxsystems.com.au/products/ea/). Na minha opinião, não tem ferramenta case melhor.

      Se animar cadastra-se na newsletter do blog (basta incluir seu e-mail na caixa que tem na parte superior desta página, rs). Periodicamente temos posts bem legais sobre Engenharia de Software.

      Abraço!

      Att.
      Plínio Ventura

  • Irina Eliandra

    muito legal esse post me ajudou a esclarecer até duvidas esquecidas estou fazendo um sistema pela primeira vez o conteúdo ficou muito legal parabéns

    • Plínio Ventura

      Que bom que foi útil, Irina. Cadastra-se no blog (na parte superior tem um formulário na parte superior do site), sempre temos posts bacanas.

      Qualquer dúvida sobre o assunto estamos à disposição!

  • Pingback: O que é Caso de Uso | Até o Momento – Muito conteúdo de qualidade sobre Engenharia de Software()

  • Pingback: Caso de Uso – Fluxo Principal | Até o Momento – Muito conteúdo de qualidade sobre Engenharia de Software()

  • Fabíola Moreira

    Boa tarde!

    Parabéns, muito útil esse post.
    Pode me falar qual o componente que você presentou as mensagens?

    • Plínio Ventura

      Oi Fabíola! Obrigado!

      O elemento utilizado para representar as mensagens no diagrama foi um object (de um diagrama de objetos).

      É isso mesmo que queria saber?

      • Fabíola Moreira

        Sim, era isso mesmo. Só não consegui colocar com a mesma aparência que você colocou.

        Obrigada pelo esclarecimento.

        • Plínio Ventura

          Ok, Fabíola. Se quiser pode me chamar no Facebook (plinio.ventura) que lhe explico como fazer. Por aqui fica ruim de dar um “passo a passo”, vai ficar muito extenso.

  • Priscila Tomé de Souza

    Olá Plínio…gostei do seu post e vi que você usa o EA e hoje minha maior dificuldade é que a versão atual do EA não permite que um FA seja chamado de outro FA, assim como um FE não pode ser chamado de outro FE ou FA.

    Qual sugestão você da? Tenho um caso de uso especificado no word e estou jogando para ferramenta e nele tenho um FE que pode ser chamado em “n” fluxos…não sei o que fazer!

    • Plínio Ventura

      Oi Priscila, tudo bem?

      Para eu lhe dar uma opinião mais próxima do que pode precisar, o ideal é você falar um pouco do seu cenário, mas veja se lhe ajuda.

      Quando temos um artefato/elemento em algum modelo de software (inclusive modelo de Caso de Uso) que possui algum recurso que várias partes do sistema precisam acessar, a boa prática é especializar isso, separando num único artefato que possua apenas essa responsabilidade (você pode ver mais sobre isso neste post: http://www.ateomomento.com.br/acoplamento-e-coesao/). Assim o reuso pode ser feito sem problemas.

      No seu contexto, talvez você pode especializar esse fluxo num único caso de uso, colocando como Fluxo Principal (se for aderente), e todos os Casos de Uso que precisarem utilizá-lo fazem os respectivos includes/extends.

      Mas é importante analisar se sua necessidade realmente é pertinente, pois não é boa prática, em termos de Modelagem de Casos de Uso, que um FE seja “compartilhado”. Até porque, é importante analisar se essa “exceção”, por ser usada em maior escala no sistema, na realidade não é uma “regra”.

      Fique à vontade para colocar mais informações, entendendo melhor seu cenário talvez eu possa ser mais útil.

      Abraço, obrigado pela leitura do post! 🙂