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.
Lógicas de Repetição em Caso de Uso
Na 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.
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!