O Diagrama de Caso de Uso é uma visualização usada para descrever funções do sistema composta por Atores, Casos de Uso e o relacionamento entre eles. É observável por usuários externos, denominado diagrama de modelo de atores da funcionalidade do sistema. Os diagramas de casos de uso são frequentemente usados durante a fase de análise de requisitos.
Antes de desenvolver um sistema, a tarefa mais importante é obter as necessidades do usuário, e a mais importante entre as necessidades do usuário são os requisitos funcionais do sistema propostos pelos usuários. Podemos usar diagramas de casos de uso para expressar visualmente as necessidades do usuário.
Diagrama visual de caso de uso
Os principais elementos em um diagrama de casos de uso incluem atores, casos de uso e relacionamentos entre elementos. Além disso, os diagramas de casos de uso também podem conter anotações e restrições.
1. Conceito de participantes
Atores são entidades externas que interagem com o sistema principal. Os participantes podem ser pessoas, subsistemas, outros sistemas, etc., fora do sistema.
Cada ator é na verdade um conjunto de papéis. Na UML, um ator é representado graficamente usando uma forma humana e recebe um nome. Conforme mostra a figura abaixo, o “leitor” é participante do sistema de empréstimo da biblioteca.
atores do diagrama de caso de uso
Os intervenientes devem estar fora dos limites do sistema e não fazer parte do sistema.
2. Como identificar os participantes
Ao fazer a modelagem de casos de uso, identificar os atores é a primeira etapa na modelagem do diagrama de casos de uso. Então, como determinar os participantes do sistema ? Podemos pensar nisso a partir das seguintes ideias:
(1) Os objetos de serviço do sistema – como leitores no sistema de empréstimo de biblioteca;
(2) Pessoas que prestam apoio para concluir o trabalho - como funcionários da biblioteca no sistema de empréstimo da biblioteca, que precisam usar o sistema para ajudar os leitores a concluir empréstimos, devolver livros e lembretes;
(3) Mantenedor do sistema: a pessoa responsável pela instalação, manutenção e gerenciamento do sistema. Neste caso, o sistema precisa fornecer funções relevantes para ajudar esse pessoal a concluir o trabalho de instalação, manutenção e gerenciamento;
(4) Dispositivos externos: necessidade de transmitir ou ler informações de dispositivos externos, como leitores de cartões;
(5) Outros sistemas ou subsistemas: tais como o sistema financeiro no sistema de empréstimos O sistema financeiro não é uma função do sistema de empréstimos, mas o sistema de empréstimos precisa de lhe transmitir informações para concluir o excelente trabalho atrasado;
(6) Hora: Em um momento programado, um evento específico ocorre automaticamente, como backup automático, lembrete regular, etc.;
(7) Eventos específicos: Por exemplo, o recebimento automático de pedidos no sistema de entrega é impulsionado por eventos de geração de pedidos.
Ao identificar os participantes , tenha em mente o seguinte:
(1) Os participantes estão localizados fora do sistema, não fazem parte do sistema;
(2) Os participantes interagem com o sistema através dos limites do sistema;
(3) Embora os ícones dos participantes sejam representados por ícones em forma humana, os participantes não são necessariamente pessoas, podendo também ser outros subsistemas, outros sistemas, tempo, temperatura e outros fatores.
3. Relacionamento entre participantes
A principal relação entre os participantes é a generalização. A generalização é representada por uma seta triangular sólida e aberta que aponta para participantes mais gerais e termina no participante “específico”. Uma relação de generalização é uma relação entre o geral e o particular (concreto). Numa relação de generalização, uma descrição abstrata de um participante pode ser compartilhada por um ou mais participantes concretos. A figura a seguir descreve as relações generalizadas entre os participantes de um sistema de empréstimo de biblioteca:
Relação de generalização entre participantes do sistema de empréstimo de bibliotecas
aposentados , etc. abaixo do leitor são participantes “específicos”. A generalização do participante pode ser entendida como: um participante “específico” é um participante “geral”, como um docente que é uma espécie de leitor. Na generalização de atores, os casos de uso executáveis por um ator “geral” são representados como executáveis por um ator “concreto” (“especial”).
1. O conceito de casos de uso
Um caso de uso é um serviço de sistema ou unidade funcional que pode ser experimentado pelos participantes. Ele define uma meta que o sistema deve alcançar. Um caso de uso apenas define o comportamento do sistema, mas não revela a estrutura interna do sistema.
A maior vantagem dos casos de uso é que eles descrevem as funções do sistema da perspectiva do usuário. Graficamente, um caso de uso é representado por uma elipse sólida com o nome do caso de uso dentro ou abaixo da elipse:
Caso de uso de empréstimo de livros
2. Identifique casos de uso
Os casos de uso podem ser identificados através dos seguintes pontos:
(1) Quais funções o participante precisa do sistema para apoiar seu trabalho?
(2) Os participantes precisam consultar alguma informação no sistema?
(3) Os participantes precisam alterar algumas informações no sistema, como criar, modificar e excluir operações?
(4) Os participantes precisam ser notificados sobre eventos específicos ou mudanças no status do sistema?
(5) Que eventos externos no sistema farão com que o sistema execute funções relevantes em resposta?
(6) O sistema fornece funções relevantes para ajudar o pessoal de manutenção a manter o sistema?
3. Principais pontos de identificação do caso de uso
(1) Os casos de uso identificados devem refletir os objetivos do sistema, ou seja, “o que fazer” em vez de “como fazer”, o que significa que os casos de uso não são detalhes da implementação do sistema;
(2) Definir casos de uso a partir da perspectiva dos participantes (usuários) e não da perspectiva do sistema;
(3) Os casos de uso devem fornecer resultados valiosos aos participantes, em vez de uma coleção de ações;
(4) Evite cair na decomposição funcional e na decomposição em etapas;
(5) Cada participante deve ter um caso de uso executável e cada caso de uso deve estar associado a pelo menos um participante.
4. Nomeando casos de uso
Depois de determinar os casos de uso do sistema, é necessário nomear cada caso de uso. A nomenclatura dos casos de uso precisa descrever os objetivos alcançados pelos participantes da perspectiva do usuário. Os seguintes métodos de nomenclatura podem ser usados:
verbo + objeto
Ou seja, o nome do caso de uso deve estar na forma de uma frase verbo-objeto. Como escolher cursos, emprestar livros, encomendar produtos e pagar com cartão de crédito.
5. Granularidade do caso de uso
A granularidade do caso de uso refere-se ao grau em que um caso de uso refina ou integra funções do sistema. Também pode ser considerado o número de serviços do sistema ou unidades funcionais incluídas em um caso de uso. Se a granularidade do caso de uso for muito grosseira ou muito grande, o caso de uso conterá mais funções do sistema e vice-versa. Se a granularidade dos casos de uso for muito grosseira, será difícil entender o sistema. Se a granularidade for muito fina, o modelo de casos de uso será muito grande, o que trará dificuldades ao design. Se o caso de uso for muito refinado, ele poderá cair em decomposição funcional, como:
Use granularidade de caso inicial
Na verdade, muitas empresas no sistema incluem operações de adição, exclusão, modificação e verificação. Isso não pode fornecer nenhum objetivo significativo para os usuários, mas ignorará o propósito real dos usuários.
O acima “adicionar, excluir, modificar e verificar” nada mais é do que gerenciamento de usuários, que é o real propósito dos participantes. Talvez seja melhor lidar com o caso de uso acima da seguinte maneira:
Redução da granularidade do caso de uso
O caso de uso Gerenciar Usuários representa uma meta ou tarefa para administradores de sistema. Se você precisar adicionar acréscimos, exclusões, modificações e consultas, seria melhor expressá-lo da seguinte maneira.
Após a otimização da granularidade do caso de uso
Outro erro frequentemente cometido na modelagem de casos de uso é tratar as etapas como casos de uso. Por exemplo, o seguinte parece perfeito, mas é óbvio que as etapas da operação são consideradas casos de uso:
Etapas de operação como exemplos de erros de casos de uso
Os passos acima nada mais são do que cumprir o objetivo do usuário como participante: o cadastro. Portanto, deve ser alterado para o seguinte:
Após a otimização do caso de uso
Na modelagem de casos de uso, o terceiro erro comum é tratar as atividades do sistema como casos de uso. No diagrama de caso de uso abaixo, estabelecer objetos de conexão, criar objetos de comando e executar instruções SQL são atividades dentro do sistema que não podem ser percebidas pelo usuário. Portanto, este diagrama de caso de uso é impreciso:
Exemplo de erro de caso de uso de atividade do sistema
O quarto erro comum na modelagem de casos de uso é nomear os casos de uso usando uma perspectiva de sistema.
Use a perspectiva do sistema para nomear exemplos de erros de casos de uso
Dos dois diagramas de casos de uso acima, qual é o melhor? Obviamente, o da direita é melhor que o da esquerda, porque o caso de uso à direita é nomeado da perspectiva do usuário, enquanto o caso de uso da esquerda é nomeado da perspectiva do sistema, e os usuários se sentirão confusos depois vendo isso.
6. Especificação do caso de uso
O diagrama de caso de uso geralmente descreve os requisitos funcionais do usuário (funções ou serviços fornecidos pelo sistema), mas cada caso de uso deve ser descrito em detalhes para que as pessoas saibam o que o caso de uso deve fazer especificamente. Em outras palavras, o modelo de casos de uso consiste essencialmente em um diagrama de casos de uso e uma descrição detalhada de cada caso de uso (especificação de caso de uso).
Uma especificação de caso de uso deve conter o seguinte conteúdo:
(1) A identificação e o nome do caso de uso;
(2) Participantes envolvidos no caso de uso;
(3) Uma breve descrição do caso de uso;
(4) Outros casos de uso relacionados;
(5) Pré-condições para execução de casos de uso
(6) Fluxo básico de eventos;
(7) Fluxo de eventos alternativo;
(8) Pós-condições para execução de casos de uso;
(9) Outras informações, como requisitos não funcionais, restrições de projeto, status de revisão de caso de uso, preparador, registros de modificação, etc.
As relações entre casos de uso incluem principalmente três tipos: generalização, inclusão e expansão.
Quando vários casos de uso têm atributos ou comportamentos semelhantes, podemos abstrair seus pontos em comum em um caso de uso pai e outros casos de uso como casos de uso filhos de um relacionamento de generalização. Os casos de uso filhos herdam os atributos e comportamentos do caso de uso pai. A relação de generalização de casos de uso pode ser entendida como diferentes caminhos de implementação para o mesmo propósito de negócio.
O relacionamento de generalização é representado graficamente por uma implementação com uma seta triangular vazia apontando do caso de uso filho para o caso de uso pai.
Use o relacionamento de generalização do diagrama de caso
No exemplo acima, " Método de Pagamento 1 " e " Método de Pagamento 2 " são casos de subuso de "Pagamento". O caso de uso pai "Pagamento" não fornece métodos de pagamento específicos, mas apenas fornece os atributos e interfaces necessários para o pagamento e implementa funções de pagamento específicas em seus casos de uso filho.
Durante o processo de modelagem do sistema, algumas funções precisam ser utilizadas repetidamente em diferentes cenários de negócios. Essas funções usadas repetidamente podem ser separadas para formar um caso de uso separado e, ao executar funções relacionadas, as funções públicas separadas podem ser incluídas no processo principal. A relação de inclusão de casos de uso pode descrever esta situação. Além disso, se um caso de uso básico tiver muitas funções, ele também poderá ser dividido em vários casos de uso pequenos. Os casos de uso contidos são chamados de casos de uso de provedor, e os casos de uso que contêm outros casos de uso são chamados de casos de uso de cliente.
Na UML, o relacionamento de inclusão é representado por uma seta pontilhada com o estereótipo <<include>>. A seta aponta do caso de uso básico (incluindo caso de uso/caso de uso do cliente) para o caso de uso incluído (caso de uso do provedor).
O diagrama de caso de uso contém relacionamentos
A seguir está um exemplo específico. Neste exemplo, o leitor deseja pré-emprestar livros. Ele precisa executar o caso de uso do livro de consulta antes de poder pré-emprestar o livro. Caso de uso de livro pré-emprestado Ao mesmo tempo, o leitor precisa Ao pré-emprestar livros, ele deve estar conectado ao sistema e o sistema salvou seu status de login antes que ele possa realizar a operação de pré-emprestado. o caso de uso de verificação de identidade também será incluído no caso de uso de pré-empréstimo de livro. Consultar livros não é apenas uma função básica exigida por um leitor, mas também um processo operacional necessário para outras funções. A verificação de identidade não é usada apenas no pré-empréstimo de livros, mas também na execução de funções como consulta de registros de empréstimos e pagamento de multas. É mais apropriado propor a verificação de identidade separadamente para formar um caso de uso:
Relação de inclusão de livro de empréstimo antecipado do leitor
Os casos de uso básicos fornecem pontos de extensão, nos quais novos comportamentos podem ser adicionados. Os casos de uso de extensão fornecem um conjunto de fragmentos de inserção que podem ser inseridos nos pontos de extensão do caso de uso básico.
· O caso de uso base fornece apenas pontos de extensão sem conhecer quaisquer detalhes do caso de uso de extensão.
· Um caso de uso base está completo mesmo sem um caso de uso estendido, diferentemente de um relacionamento de inclusão.
· Um caso de uso pode fornecer vários pontos de extensão, e cada ponto de extensão pode aparecer diversas vezes.
· Em circunstâncias normais, a execução do caso de uso básico não envolverá o caso de uso estendido. As funções do caso de uso estendido só serão executadas quando ocorrerem condições ou eventos específicos.
Na UML, um relacionamento de extensão é representado por uma seta tracejada com o estereótipo <<estender>>. As setas apontam de casos de uso estendidos para casos de uso básicos.
Use o relacionamento de extensão do diagrama de caso
O exemplo a seguir é um fragmento de diagrama de caso de uso em um sistema de empréstimo de biblioteca:
Leitores pagam multas para ampliar relacionamentos
Neste exemplo, pagar uma multa é um caso de uso básico para o leitor e um caso de uso estendido para devolver o livro. “Pagar multa”, como caso de uso estendido de “Devolução de livros”, só será executado nas seguintes condições:
(1) Os livros do leitor estão vencidos ou apresentam multas por outros motivos e não foram pagos integralmente;
(2) O leitor opta por pagar a multa no mesmo momento após a devolução do livro.
O texto acima é o conteúdo relevante sobre diagramas de casos de uso UML. Todos os casos de diagramas de casos de uso acima são desenhados usando ProcessOn.
Mapa Mental e Fluxograma Colaborativo Online Gratuito Uso Gratuito 
![[Compartilhando informações úteis] Domine 14 tipos de diagramas UML em 10 minutos](https://cdn.processon.io/admin/knowledge/article_thumb_img/66d15a76990fed148692bdda.png)
