Caso de Uso – Fluxo Principal

Compartilhe este conteúdo!

Como já vimos no post sobre O que é Caso de Uso, no escopo de um caso de uso podemos ter três tipos de fluxos (ou cenários): Fluxo Principal, Fluxo Alternativo e Fluxo de Exceção.

Sempre teremos somente um Fluxo Principal, e poderemos ter zero ou mais fluxos alternativos, e zero ou mais fluxos de exceção.

Entendo o Fluxo Principal

O Fluxo Principal, culturalmente também é chamado de Caminho Feliz, Fluxo Básico, Fluxo Ótimo, ou Fluxo de Sucesso.

/* Poucos profissionais sabem, mas o fluxo principal tem, culturalmente, o apelido de “caminho feliz” pois acredita-se que este fluxo é feito para não dar erro. Entende-se que se o usuário seguir todo o fluxo principal vai dar tudo certo no uso da funcionalidade, mas se o usuário alterar um parâmetro sequer, aí tudo pode mudar… */

fluxo-principal-caso-de-uso

O Fluxo Principal é a maneira “default” que o ator utilizará a funcionalidade, ou seja, é o que ele tentará fazer primariamente sempre que utilizar a funcionalidade.

Este fluxo Contém o passo a passo da execução da funcionalidade de maneira bem sucedida, detalhando o que deverá ser percorrido para que se atinja o objetivo primário do uso da funcionalidade.

Podemos entender também como o objetivo principal do uso da funcionalidade.

Quando na especificação de um caso de uso, geralmente surgem dúvidas sobre como eleger o fluxo principal em meio às possibilidades de utilização da funcionalidade pelo usuário.

Realmente é um pouco abstrato isso, mas quando acostumamos fica mais tranquilo de identificar qual fluxo será o principal. Basta pensar no objetivo principal da funcionalidade que a resposta aparece.
Engenharia de Software e UML - Unified Modeling Language - Curso Online

Exemplos na vida real

O Sr. Paulo quer ir rápido para o Aeroporto. Esse é o objetivo principal do Sr. Paulo. O Sr. Paulo tem três opções de transporte para chegar até o Aeroporto: Carro, Ônibus ou Bicicleta.

Se o Sr. Paulo quer chegar rápido, então ele deve utilizar o Carro como sua principal forma de transporte (no mundo do Sr. Paulo não há congestionamento de veículos), e ter como alternativas o Ônibus e a Bicicleta.

Mas no caminho ao Aeroporto o carro pode estragar e atrapalhar a ida do Sr. Paulo ao Aeroporto, mas isso é uma exceção à regra (a regra é que o Sr. Paulo chegará no aeroporto sem ter problemas no Carro).

No contexto acima, ir de Carro é o Fluxo Principal, ir de Ônibus e ir Bicicleta são Fluxos Alternativos. E o Carro estragar, caso isso corra, é um Fluxo de Exceção.

O objetivo principal da funcionalidade deve ser analisado para se entender qual é o fluxo principal. Estou repetindo isso, mas essa é a intenção. 🙂

Vamos a outro exemplo: imaginemos uma empresa que fará pagamento de fornecedores através do seu novo sistema.

Concluiu-se durante o projeto que a empresa terá uma funcionalidade específica com o objetivo de fazer estes pagamentos. Ainda, identificou-se que a forma principal de pagar os fornecedores é via transferência eletrônica de dinheiro (é a forma mais utilizada porque 80% dos pagamentos da empresa são feitos desta forma), mas existem outras duas alternativas: pode-se pagar com cartão de crédito e boleto bancário.

Eventualmente o banco utilizado pela empresa para a realização dos pagamentos para pagamento através desta funcionalidade fica com seu sistema fora do ar, impossibilitando o pagamento; mas isso é uma exceção à regra (a regra é que o pagamento ocorra sem ocorrer problemas com a disponibilidade do sistema do banco).

No contexto acima, pagar o fornecedor com Transferência Eletrônica de Dinheiro é o Fluxo Principal, pagar o fornecedor com Cartão de Crédito e pagar fornecedor com Boleto Bancário são Fluxos Alternativos, e o pagamento não ser possível devido a problemas com o sistema do banco utilizado no pagamento é um Fluxo de Exceção.

Como isso acontece na especificação do sistema?

Vejamos o diagrama de caso de uso abaixo:

post-caso-de-uso-fluxo-principal

Ao lado temo um diagrama, onde um ator com o papel de Analista de Departamento Pessoal pode executar dois casos de uso (UC003 e UC004).

O UC004 possui como objetivo consultar férias de um empregado.

Vejamos o conteúdo deste Caso de Uso, mostrando os detalhes do seu Fluxo Principal

fluxo-principal-caso-de-uso-consultar-ferias-empregado

No UC004 temos quatro fluxos, e o Fluxo Principal é o FP01 – Consultar férias agendadas e não consumidas pelo empregado”.

No contexto deste Caso de Uso, este Fluxo Principal foi eleito como principal pois no departamento pessoal da empresa onde o sistema é utilizado, a maioria das consultas por férias na funcionalidade pertinente é de férias agendadas e ainda não consumidas pelo profissional.

A funcionalidade também contempla outras possibilidades, através dos outros fluxos, mas essas possibilidades, estes objetivos, ficaram como secundários por não se tratar do objetivo principal, do comportamento “default” da funcionalidade.

Concluindo

Engenharia de Software e UML - Unified Modeling Language - Curso OnlinePode parecer um pouco subjetivo conceituar o Fluxo Principal, é relativamente sutil a diferença entre um fluxo principal e um fluxo alternativo.

Mas a partir da prática no no dia a dia fica mais claro como eleger este fluxo.

O ideal é sempre pensar no objetivo da funcionalidade, pensar em qual o propósito da funcionalidade no dia a dia da empresa, e ficará menos subjetivo perceber qual é o objetivo principal.

Para entender melhor o que é um fluxo alternativo veja Caso de Uso – Fluxo Alternativo.

Para entender melhor o que é um fluxo de exceção veja Caso de Uso – Fluxo de Exceção.

Grande abraço!