Diagrama de Caso de Uso – Como representar loop

Diagrama de Caso de Uso

Eventualmente o Analista de Sistemas se pergunta: “em que nível de detalhe devo descer no caso de uso?”.

Por “default”, na minha opinião, a resposta é: o máximo possível, mas sem perder o bom senso.

Se o profissional for mais voltado a Análise de Requisitos, ele provavelmente produzirá o Caso de Uso com um viés mais funcional. Se for um analista mais voltado para programação, produzirá o Caso de Uso com um viés mais de Codificação.

Tudo isso também será influenciado pelo processo de desenvolvimento adotado na empresa. Se o Caso de Uso for entrada para construção – ou seja, o desenvolvedor utilizar o Caso de Uso como principal insumo para a construção – então o nível de detalhamento deve ser maior (mais detalhado).

Se o processo de desenvolvimento contemplar a disciplina de projeto, quando isso ocorrer antes da construção, e o Caso de Uso for insumo para o projeto, então o nível de detalhe pode ser menor, devendo o projeto ser mais detalhado.

Independente do viés a clareza na especificação é fundamental

Todavia, é importante entender que o Caso de Uso deve ser escrito em linguagem natural, em função do seu propósito.

E havendo ou não a etapa de projeto, para diminuir o gap semântico, e com isso dimunir a chance de defeitos na modelagem, a lógica do Caso de Uso deve representar claramente e totalmente como a funcionalidade deverá se comportar.

Não tem como o programador ou o projetista adivinharem que em determinado fluxo do Caso de Uso deverá ser empregada lógica de repetição, lógica condicional etc.

O analista responsável pela modelagem do Caso de Uso é quem sabe isso, pois é quem define o comportamento da funcionalidade.

O programador ou o projetista podem até deduzir, e talvez alinhar com o profissional que fez o Caso de Uso sobre o escopo a ser construído ou projetado. Mas interpretação sabemos como é, cada um tem a sua.

Diagrama de Caso de Uso - eBook sobre Requisitos de Software

Lógicas de Repetição em Caso de Uso

Diagrama de Caso de Uso - Estrutura de RepetiçãoNa modelagem de casos de uso é muito comum o Analista de Sistemas se deparar com situações onde lógicas envolvendo estruturas de repetição precisam ser utilizadas.

Por estruturas de repetição entenda-se lógicas que usam loop – “for”, “while”, “repeat” etc.

Já vi profissionais alegarem que em casos de uso não deve-se representar lógicas de repetição, e também já vi profissionais abusarem no uso de tais estruturas nos cenários de um Caso de Uso, quase codificando num fluxo principal.

Eu acho muito pertinente representar estruturas de repetição em cenários de um Caso de Uso, acho inclusive fundamental fazê-lo, para dar a clareza necessária ao conteúdo

Mas não podemos esquecer o nível de abstração deste artefato de especificação; não estamos falando de modelo de código fonte, mas sim de uma estória sobre como deverá ser o comportamento de uma funcionalidade do sistema.

Exemplificando

A seguir apresento um exemplo sobre como podemos representar estruturas de repetição num cenário de Caso de Uso, equilibrando um bom nível de detalhamento com o uso de linguagem natural.

Diagrama de Caso de Uso - Cenário

No bloco destacado em vermelho é onde temos a estrutura de repetição representada.

No escopo deste fluxo principal, a partir de uma consulta realizada pelo ator, o sistema obtêm uma lista de cobranças, e para cada cobrança (cada cobrança está atrelada a um CPF) o sistema executará três passos. Os fluxos de exceção pertinentes já foram considerados.

Na construção, essa estrutura de repetição poderá ser um for ou while, isso dependerá do programador, é transparente na modelagem de Caso de Uso. E ainda, cada fluxo de exceção já deixa claro também que deverá haver tratamento de erro para as possíveis exceções.

Concluindo

Estruturas de repetição não podem faltar nos casos de uso quando a funcionalidade demandar este comportamento.

E linguagem natural é diferente de linguagem de programação.

Mas na modelagem de software, ambas tem que representar a mesma coisa. Por uma questão de abstração, a funcionalidade deverá ser representada por cada uma destas linguagens, conforme o artefato que está sendo produzido.

Grande abraço!

Caso de Uso

  • Estava procurando saber sobre isso, ótimo blog obrigado. Já adicionei aos favoritos!

    • Plínio Ventura

      Oi Karol!

      Obrigado pela visita. Que bom que o conteúdo lhe foi útil. Cadastra-se em nossa newsletter, para receber nossos posts periódicos!

      Abraço!
      Plínio Ventura

  • Marcelo Sousa

    Muito bom!

    • Plínio Ventura

      Obrigado, Marcelo! Espero que o conteúdo tenha sido útil!

  • Andre Luiz Oliveira

    Interessante a abordagem, parabéns.
    Só uma dúvida qual o nome da ferramenta do exemplo?

    Grato