Caso de Uso – Fluxo Principal

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.

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. :)

Caso de Uso - Fluxo Principal - eBook sobre Requisitos de Software

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

Pode 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!

fluxo principal

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

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

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

  • Matteus

    Qual software é esse que você utiliza para montar os casos de uso?

  • Leandro

    Gostaria de sua ajuda para um cenário que não sei qual a melhor solução:
    O sistema poderá ser acessado por dois “Perfis” de usuário: “Administrador da empresa” e “Usuário do Suporte” (de cara já identifiquei dois dos principais atores envolvidos). Porém, preciso criar um Caso de Uso para descrever o Acesso dos usuários à ferramenta. O problema é que esse Caso de Uso irá se comportar da mesma forma, independente do usuário: Vai validar se o usuário e a senha são válidas, vai possibilitar a recuperação da senha, etc. Eu imaginei que os dois atores (“Administrador da Empresa” e “Usuário do Suporte”) poderiam estar associados a esse Caso de Uso, mas me enrosquei ao começar a escrever o cenário: Nesse caso, qual dos dois atores eu cito no meu cenário? Elejo um deles? Outra possibilidade seria utilizar “Generalização” para esses dois atores, criando um novo ator que seria uma generalização dos outros dois, e esse novo ator passaria a estar associado a esse Caso de Uso. Acha que seria uma boa prática, neste caso? Mas mesmo assim, não consegui dar um nome para esse ator (não posso simplesmente dar o nome de “Usuário”).

    • Plínio Ventura

      Oi Leandro, tudo bem?

      Seguem alguns comentários:

      – Há alguma diferença, em termos de regra de negócio, para as permissões de acesso de cada ator? Ou seja, o Analista de Suporte acessa parcialmente as funcionalidades, o Administrador da Empresa todas, ou algo semelhante.

      – Imagino que além dos dois atores citados haverão outros atores no sistema. Estou certo?

      – Existem outras funcionalidades em que somente um dos atores poderá utilizar, em outro contexto?

      – A generalização neste caso, na minha visão, teria sentido apenas semântico, e facilitaria a escrita dos cenários do Caso de Uso. Mas realmente você cai na sinuca de chamar o ator genérico de “Usuário”, o que é um tanto “tosco”. Mas, talvez seja relevante. Pense focando praticidade: qual a diferença, em termos da qualidade do caso de uso, que haverá em ter um usuário genérico (que será uma generalização dos atores especializados)?

      Você pode colocar uma nota explicativa no seu diagrama, para contextualizar quem for utilizá-lo, explicando isso. ***** Mas Existe um problema aí que ***** => alguém, em algum momento, vai usar este ator para outras coisas que deveriam ser utilizadas com atores especializados, e aí pode comprometer a qualidade.

      Aguardo seu retorno para concluir a respeito da sua dúvida.

      Abraço!

  • Filipe

    Muito boas as explicações para os Casos de Uso, parabéns! Gostaria de entender melhor como se ligam os Casos de Uso nos Requisitos de Software (RFs,RNFs e RNs), por exemplo, um caso de uso representa um RF? Na questão da Documentação, ficam documentos diferentes? Também tenho dúvidas de quais outros documentos são gerados (boas práticas), para que, por exemplo, um RF de um relatório chegue até o programador e ele saiba quais tabelas utilizar, quais colunas do relatório, se para cada coluna do relatório tem uma forma de buscar os valores, relacionando tabelas, etc. Onde fica isto tudo escrito? Muito obrigado! O blog tem sido excelente fonte de pesquisa e aplicação!

    • Plínio Ventura

      Oi Filipe,

      Seguem abaixo meus comentários:

      Sobre “ligar” Requisitos a Casos de Uso: para isso, é necessário criar relacionamentos entre os elementos citados, seja manual (através de uma planilha, por exemplo) ou através de diagramas (usando ferramenta Case). Um Caso de Uso realiza 1 ou N Requisitos (aplica-se a RF, RN ou RNF). Após a criação dos relacionamentos, é necessário extrair uma matriz de rastreabilidade para verificar a relação entre os elementos.

      Sobre os “relatórios”: considerando as necessidades que citou, é necessário criar artefatos de projeto (design) ou análise, que possuam um nível de detalhe que dê condições do programador entender todos estes detalhes. Todavia, neste caso, uma excelente opção é usar Diagrama de Sequência (UML), e no escopo de cada método utilizado nas instâncias das classes contidas no diagrama, especificar os dados dos campos/tabelas etc.

      Qualquer dúvida adicional me fale!

      Abraço!

  • Pedro

    Olá Plínio, ótimo artigo! Gostaria de esclarecer uma dúvida que vejo em diversos outros artigos. Vou dar um exemplo para ficar mais claro,… No caso de uso “Consultar” um ator (Médico) pode ou não (Extends) “Prescrever Medicamentos”. Em vários modelos eu vejo o relacionamento do Médico para “Consultar” e do Médico para “Prescrever Medicamentos”, entretanto, qual seria o correto? Não seria apenas o relacionamento do Ator (Médico) para “Consultar”, já que o ato de prescrever somente ocorre dentro de uma consulta? (Nesse modelo de negócios especificado). Obrigado desde já e continue com o excelente trabalho!

    • Plínio Ventura

      Oi Pedro,

      Obrigado. Que bom que o conteúdo tem sido útil a você. Sobre o seu questionamento, vamos lá.

      1 – Entendo que o exemplo citado é “exemplo mesmo”, rs. Mas observe o nome dos Casos de Uso. “Consultar” não é semanticamente bom, é vago, ambíguo. “Realizar Consulta Médica” é mais adequado.

      2 – Entendi que a prescrição de medicamentos pode apenas ocorrer na consulta. Se sim, então não se aplica linkar o Ator “Médico” direto no Caso de Uso “Prescrever Medicamentos”. O adequado seria: Ator Médico -> Consultar -> Prescrever Medicamentos. Se a lógica de prescrição de medicamentos foi considerável, eu colocaria isso em um caso de uso separado, que seria chamado pelo “Consultar”, via Extends. Se for “apenas uma frase” (a grosso modo), colocaria num Fluxo Alternativo dentro do “Consultar”.

      3 – Sintetizando: se a Prescrição ocorre APENAS na consulta, não vejo razão para o médico fazer isso salvo se for na consulta. Obs.: é importante ficar claro que modelar sistemas é espelhar a vida real e materializá-la em software. No fim das contas não existe “sistema”, existe “solução”. E a solução sempre é para um problema da vida real.

      Não sei se ficou claro, qualquer dúvida adicional estamos aí!

      Grande abraço!

      • Pedro

        Perfeito Plínio. Agradeço o retorno rápido e agradeço ainda mais pelos esclarecimentos!!!!! Abraço!!!!!

        • Plínio Ventura

          Estamos aí, Pedro! Abraço!