Casos de uso

  • nunca pense na UI ao fazer os casos de uso, pense de uma forma mais genérica ao invés de dizer: “clica no botão”, “vai na aba x”, etc.;
  • pense em o que é feito, ao invés de como é feito;

Caso de uso caixa preta

  • não descreve o funcionamento do sistema;
  • diz apenas as responsabilidades do sistema (como cadastrar usuário, gerenciar estoque, etc.).

Como identificar casos de uso

1 — escolher fronteiras do sistema;

2 — identificar os atores;

3 — identificar os objetivos de cada ator;

4 — definir os casos para os objetivos.

diagrama representando o escopo do\u00a0projeto

Em um diagrama, um escopo/restrições podem ser vistas quando há um outro agente que auxilia em uma interação, nesse caso o ator software, aqui ele representa um software de terceiro que realiza alguma operação que o nosso sistema não deve fazer.

Isso também pode ser visto quando há uma pré-condição relacionada a ser conectar com algo, estabelecer comunicação com algo, etc.

Escopo

  • conjunto de objetivos dos usuários que serão atendidos.

Objetivo

  • uma pequena frase que descreve o que o usuário faz;
  • geralmente um objetivo se torna um caso de uso;
  • em casos que um objetivo possui o conectivo “e”, haverá mais de um caso de uso para esse;
  • operações de CRUD(criar, selecionar, atualizar e deletar), de vários objetivos, se tornam um único caso de uso, exemplo: criar, selecionar, atualizar e deletar usuário, se torna gerenciar usuário.

Modularidade

  • assim como em uma arquitetura de um sistema, podemos juntar casos de uso por fatores comum, criando módulos;
  • ajuda a gerenciar melhor os casos que temos.

Monolito

  • da mesma forma que em uma arquitetura de software, podemos deixar todos os casos de uso juntos, como um grande monolito.