O que é um diagrama de caso de uso?
Os diagramas de casos de uso UML são a principal forma de requisitos de sistema/software para novos programas de software em desenvolvimento. O propósito de um diagrama de caso de uso é visualizar o que o sistema deve fazer (o quê); nesta fase, não considera como (como) fazê-lo.
Uma vez que um caso de uso é especificado, ele pode ser representado em uma representação textual e visual (ou seja, um diagrama de caso). Um conceito chave da modelagem de casos de uso é que ela nos ajuda a projetar o sistema da perspectiva do usuário final. É uma técnica eficaz para comunicar o comportamento do sistema em termos do usuário, especificando todos os comportamentos do sistema visíveis externamente.
Em outras palavras, o uso do sistema deve ser visto de fora, ou seja, o sistema não deve ser visto de dentro, mas de um nível superior para determinar a funcionalidade que o sistema deve fornecer aos atores externos.
Objetivo dos diagramas de caso de uso
Os diagramas de caso de uso geralmente são desenvolvidos nos estágios iniciais de desenvolvimento, e as pessoas geralmente usam a modelagem de caso de uso para os seguintes propósitos.
- Especificar o contexto de um sistema
- Capturar os requisitos de um sistema
- Validar a arquitetura de um sistema
- Impulsione a implementação e gere casos de teste
- Desenvolva por analistas, especialistas de domínio e usuários finais em conjunto
Uma forma padrão de diagrama de caso de uso é definida na Unified Modeling Language, conforme mostrado no exemplo de diagrama de caso de uso abaixo.
EDITE ESTE EXEMPLO DE DIAGRAMA DE CASO DE USO
Elementos do Diagrama de Caso de Uso
Atores
Cada caso de uso terá pelo menos um ator, que pode ser entendido como pelo menos um participante (papel), que não é necessariamente uma pessoa, mas pode ser outro sistema ou dispositivo. Um ator pode interagir com mais de um caso de uso e um caso de uso pode interagir com mais de um ator.
Os atores não são necessariamente pessoas, ou seja, usuários, mas na verdade podem ser não-pessoas, ou seja, sistemas ou tempo.
Na maioria das vezes, os usuários são pessoas envolvidas no diagrama de casos de uso, como clientes, funcionários, supervisores, etc.
Atores humanos vs não humanos
De tempos em tempos, o sistema é afetado por vários eventos para executar determinadas funções em uma determinada situação. Por exemplo, quando uma auditoria é aprovada, o sistema envia proativamente uma carta para notificar as pessoas; então o envio da carta é feito automaticamente pelo sistema? Este caso de uso é realmente acionado pelo tempo, então o ator é Timer; por exemplo, este caso de uso pode ser visto como “enviar uma carta automaticamente às 5:00 todos os dias”, então o ator que aciona este evento – enviar uma carta – não é o sistema, mas na verdade o Ator Timer
Atores Primários vs Secundários
Um ator primário é um ator que usa o sistema para atingir um objetivo. Os casos de uso documentam as interações entre o sistema e os atores para atingir os objetivos do ator primário. Atores secundários são os atores que o sistema precisa ajudar para atingir os objetivos do ator primário.
- Os atores podem ser primários ou secundários. Os atores primários iniciam interações com o sistema.
- Os atores secundários são normalmente chamados pelo sistema para obter ajuda e um ator secundário nunca inicia o caso de uso.
Observe que: O símbolo de um ator não diferencia entre um ator primário e um ator secundário; a diferença deve ser inferida a partir das descrições de casos de uso (também chamadas de narrativas de casos de uso).
Por exemplo:
Um agente de crédito bancário deseja revisar o pedido de empréstimo de um cliente e parte do processo envolve uma verificação de classificação de crédito em tempo real.
EDITE ESTE EXEMPLO DE DIAGRAMA DE CASO DE USO
- Nome do Caso de Uso. Revise um pedido de empréstimo
- Ator Primário. Diretor de Empréstimo
- Ator Secundário. Sistema de classificação de crédito
Como identificar os atores?
Como um ator não é necessariamente uma pessoa, mas pode ser um sistema externo, um dispositivo ou um temporizador, encontramos um ator mais específico fazendo as seguintes perguntas
- Quem usará o sistema depois de desenvolvido?
- De quem ou de quais outros sistemas o sistema precisará obter dados?
- Para quem ou para quais outros sistemas o sistema fornecerá dados?
- A quais outros sistemas o sistema será associado?
- Quem irá manter e administrar o sistema?
Essas perguntas nos ajudam a abstrair os atores do sistema. Usando caixas eletrônicos como exemplo, responder a essas perguntas nos permite encontrar mais atores, ou seja,
- O operador é responsável pela manutenção e gestão do sistema ATM
- Os caixas eletrônicos também precisam se comunicar com servidores back-end para obter informações sobre contas de usuários.
Caso de uso
Um caso de uso representa uma funcionalidade (geralmente um requisito) que se espera que seja implementada pelo sistema. Os detalhes de um caso de uso, além de seu nome exclusivo, não são representados visualmente no diagrama; esses detalhes são fornecidos na narrativa (descrição textual) do caso de uso.
Um caso de uso é uma lista de ações ou etapas de eventos que normalmente definem as interações entre os papéis dos atores e o sistema para atingir um objetivo. Os casos de uso são uma técnica útil para identificar, esclarecer e organizar os requisitos do sistema. Um caso de uso consiste em um conjunto de sequências de possíveis interações entre o sistema e o usuário que definem a funcionalidade a ser alcançada e as soluções para quaisquer erros que possam ser encontrados.
Como identificar casos de uso?
Uma vez que encontramos os atores, podemos determinar os casos de uso do sistema com base nos atores, principalmente observando quais serviços cada ator precisa do sistema ou como os atores usam o sistema. A identificação dos casos de uso pode começar com as seguintes perguntas (para cada participante).
- Por que os atores usam o sistema?
- O participante cria, modifica, exclui, acessa e armazena dados no sistema? Em caso afirmativo, como o ator realiza essas operações?
- O ator notifica o sistema de certos eventos externos?
- O sistema notifica o ator sobre determinados eventos internos?
Juntando os itens acima, o diagrama de casos de uso do sistema ATM pode ser representado da seguinte forma.
Caso de Uso é apresentado por elipses, de algo estático ou dinâmico, ou de uma tarefa ou sistema.
Limite do sistema
Os limites do sistema descrevem o sistema agrupando os casos de uso em limites retangulares, e os limites do sistema no Visual Paradigm fornecem o comportamento de contenção do caso de uso.
Atores são papéis (atores humanos ou atores não humanos) que interagem com o sistema em desenvolvimento. Portanto, os atores devem ser colocados fora dos limites do sistema e interagir com os casos de uso que são colocados dentro dos limites do sistema.
Observe que:
Um ator é definido pelos limites do sistema. Se o limite do sistema que queremos definir é limitado ao próprio ATM, então o servidor backend é um sistema externo e pode ser abstraído como um ator.
Se o limite do sistema que queremos definir se estende a todo o sistema bancário, onde os caixas eletrônicos e os servidores de back-end fazem parte de todo o sistema bancário, o servidor de back-end não é mais abstraído como um ator.
Relação
Depois de aprender sobre esses três símbolos-chave, continue com o conhecimento de Relacionamentos e desenho de diagramas de caso de uso. Um relacionamento direto entre um participante e um caso de usuário é desenhado, e o relacionamento é usado como uma linha sem setas, indicando um relacionamento bidirecional, chamado de linha de link.
Um caso de uso pode ser dividido em vários casos de uso que são conectados por relacionamentos <<include>>, <<extend>> ou <<generalization>> (descritos posteriormente neste post).
Relação de elo de comunicação
Isso representa uma comunicação bidirecional entre um ator e um caso de uso e, portanto, é uma relação binária.
EDITE ESTE EXEMPLO DE DIAGRAMA DE CASO DE USO
<<Incluir>> Relacionamento
Um relacionamento de inclusão significa que o caso de uso incluirá outros casos de uso. O propósito de Incluir Relacionamento é usar Incluir Relacionamento para reduzir a repetição de descrever o mesmo caso de uso novamente. Se muitos casos compartilham a mesma função de porção, a função pode ser separada e outros casos de uso podem ser incluídos no caso.
Por exemplo, o bibliotecário precisa ler o código para registrar o livro emprestado quando o livro for retirado, e também precisa ler o código para registrar o livro devolvido quando o livro for devolvido, pois ler o código é uma ação repetitiva , ele pode ser transformado em um caso de uso separado e permitir que o livro emprestado e o livro devolvido incluam este caso.
EDITE ESTE EXEMPLO DE DIAGRAMA DE CASO DE USO
Se um caso de uso A inclui outro caso de uso B, então a implementação de A requer a implementação de B para completar sua tarefa. No entanto, B é independente de si mesmo. Ou seja, B não precisa saber nada sobre A. B também pode ser incluído em qualquer outro caso de uso.
<<Estender>> Relacionamento
Se um caso de uso B estender outro caso de uso A, então a implementação de A pode incluir condicionalmente a implementação de B para completar sua tarefa. Ou seja, em alguns casos, A pode completar sua tarefa sem B. No entanto, dependendo das condições descritas, A pode exigir B. Nesse caso, B é dependente de B. No entanto, dependendo das condições descritas, A pode exigir B Neste caso, B é dependente de A e não pode existir sozinho. Por esta razão, B não pode ser estendido para mais de um caso de uso. A narrativa do caso de uso de A incluirá as etapas de execução exigidas de B; este ponto é chamado de ponto de extensão.
EDITE ESTE EXEMPLO DE DIAGRAMA DE CASO DE USO
Vejamos outro exemplo em que o sistema solicita mercadorias automaticamente quando não há estoque para que o gerente não precise executar o pedido diretamente. Veja o diagrama de caso de uso abaixo:
EDITE ESTE EXEMPLO DE DIAGRAMA DE CASO DE USO
Relação de generalização
O relacionamento generalizado é semelhante ao relacionamento generalizado da linguagem orientada a objetos em diagramas de classes e pode ser aplicado à generalização de papéis (atores) e casos de uso.
Por exemplo, no sistema de reservas, existem dois tipos de métodos de reserva: “reservar passagem por telefone” e “reservar passagem por Online”, e o caso de uso base “book ticker”, para que você possa usar a generalização para moldar o caso, e adicione <<essential>> ao caso de uso pai (reserva) para indicar o relacionamento generalizado.
EDITE ESTE EXEMPLO DE DIAGRAMA DE CASO DE USO
Discutir os relacionamentos no diagrama de caso de uso
- Em um diagrama de caso de uso geral, representamos apenas os relacionamentos entre atores e casos de uso, ou seja, as associações de comunicação entre eles.
- Além disso, também podemos descrever a generalização entre participantes e atores e os relacionamentos de inclusão, extensão e generalização entre casos de uso.
- Usamos esses relacionamentos para adaptar o modelo de caso de uso existente e extrair algumas informações comuns para reutilização, tornando o modelo de caso de uso mais fácil de manter.
- No entanto, temos que ter cuidado na escolha dessas relações na aplicação. Geralmente, essas relações aumentam o número de casos de uso e relações, aumentando assim a complexidade do modelo de caso de uso.
- Além disso, o modelo de caso de uso geralmente é ajustado depois de concluído, portanto, não há necessidade de se apressar em abstrair os relacionamentos entre os casos de uso no estágio inicial da modelagem de casos de uso.
Caso de uso – o fluxo de eventos
O diagrama de caso de uso nos dá uma visão geral da funcionalidade do sistema, podemos saber quais participantes irão interagir com o sistema e quais serviços cada ator precisa obter do sistema.
O caso de uso descreve a conversa entre os atores e o sistema, mas os detalhes dessa conversa não são representados no diagrama de caso de uso, portanto, para cada caso de uso, podemos descrever os detalhes dessa conversa em termos de um fluxo de eventos.
Cenários de Caso de Uso e Fluxo de Eventos – Retirada de Dinheiro em ATM
Por exemplo, o caso de “Retirada” em um sistema ATM pode ser representado por um fluxo de eventos da seguinte forma:
Cenário Normal – Retirada de recursos – fluxo básico de eventos:
- O usuário insere o cartão de crédito
- Digite o PIN
- Insira o valor da retirada
- Retira dinheiro
- Saia do sistema e recupere o cartão de crédito
Mas isso apenas descreve o cenário normal do caso de uso de retirada. Como um sistema ATM real, também devemos considerar vários outros cenários que podem ocorrer, como:
- cartões de crédito inválidos,
- senhas erradas,
- saldo de caixa insuficiente na conta do usuário, etc.
Todas essas situações possíveis (normais e anormais) são chamadas de cenários do caso de uso e os cenários também são chamados de instâncias do caso de uso. Os cenários também são chamados de instâncias de casos de uso. Dentre os vários cenários de um caso de uso, o cenário mais comum é descrito pelo processo básico, enquanto os demais cenários são descritos por processos alternativos.
Cenários alternativos
Para o caso de uso “Retirada” em um sistema ATM, podemos obter alguns processos alternativos da seguinte forma.
Retirada – processos alternativos de eventos.
- Cenário alternativo I: O usuário pode optar por sair em qualquer etapa do processo básico e ir para a etapa 5 do processo básico.
- Processo alternativo II: Na etapa 1 do processo básico, o usuário insere um cartão de crédito inválido, o sistema exibe um erro e sai do cartão de crédito e o caso de uso é encerrado.
- Processo alternativo III: Na etapa 2 do processo básico, o usuário digita uma senha incorreta, o sistema apresenta um erro e solicita que o usuário reinsira a senha e retorne à etapa 2 do processo básico; após três entradas de senha incorretas, o cartão de crédito é confiscado pelo sistema e o caso de uso é encerrado.
- …
Combinando o cenário básico e os cenários alternativos, todas as várias situações que podem ocorrer em um caso de uso podem ser claramente descritas. Ao descrever o fluxo de eventos de um caso de uso, queremos descrever todos os cenários possíveis o máximo possível para garantir a integridade dos requisitos.
Modelo de Caso de Uso x Diagramas de Caso de Uso
É importante evitar o equívoco de que um diagrama de caso de uso composto por atores e casos de uso é um modelo de caso de uso, pois um diagrama de caso de uso é apenas uma representação visual dos serviços que o sistema pode fornecer, nos dando uma ideia geral do funcionalidade do sistema.
O modelo de caso de uso consiste em um diagrama de caso de uso e uma descrição detalhada de cada caso de uso, a especificação do caso de uso, que é fornecida como modelo no RUP.
Breve descrição
Uma breve descrição da função e propósito do caso de uso.
Fluxo de Eventos
Fluxo de Eventos deve representar todos os cenários, incluindo cenários básicos e alternativos.
Cenários de Caso de Uso
Inclua cenários de sucesso e cenários de falha, e os cenários são principalmente uma combinação de fluxos básicos e alternativos.
Requisitos Especiais
Descrever os requisitos não funcionais (incluindo desempenho, confiabilidade, disponibilidade, escalabilidade, etc.) e restrições de projeto (sistema operacional, ferramentas de desenvolvimento, etc.) associados ao caso de uso.
Pré-condição
O estado em que o sistema deve estar antes que o caso de uso possa ser executado.
Pós-condições
O conjunto de estados em que o sistema pode estar após a execução do caso de uso.
Uma especificação de caso de uso é essencialmente uma representação textual, com a opção de usar diagramas de estado, diagramas de atividades ou diagramas de sequência para ajudar a descrever o fluxo de eventos com mais clareza. Qualquer representação gráfica de interfaces de usuário e processos, ou outros gráficos, ou seja, wireframes, podem ser anexados ao caso de uso, desde que ajudem a melhorar a clareza da representação.
Por exemplo:
- diagramas de atividades são úteis para descrever processos de decisão complexos,
- diagramas de transição de estado são úteis para descrever o comportamento do sistema relacionado ao estado e
- diagramas de seqüência são apropriados para descrever mensagens baseadas em tempo.
Ferramentas de caso de uso
Versão online
A versão gratuita da ferramenta de desenho Visual Paradigm Online (VP Online) suporta UML, ERD e organogramas. Você pode desenhar diagramas de caso de uso rapidamente com o editor de desenho UML intuitivo. Esta ferramenta UML gratuita não possui anúncios, período de acesso limitado e restrições como número de diagramas, número de formas, etc. Desenhe UML livremente. Desenhe UML livremente. você possui os diagramas que cria para fins pessoais e não comerciais.
Versão para computador
O Visual Paradigm Community Edition , disponível desde 2004, fornece um software UML gratuito apenas para fins não comerciais, apoiando usuários que estão dando seus primeiros passos na modelagem UML, bem como aqueles que precisam de um software de modelagem UML gratuito e multiplataforma para uso pessoal, como aplicar UML em projetos de alunos.
Referências
- O que é o Diagrama de Caso de Uso?
- Tipos de Ator no Modelo de Caso de Uso
- Identifique os requisitos do usuário com diagramas de caso de uso
- O que é Especificação de Caso de Uso?
- História de usuário versus caso de uso para desenvolvimento de software ágil
- Abordagem Orientada a Casos de Uso para Desenvolvimento Ágil
English
简体中文
繁體中文
Deutsch
Español
Français
العربية
Italiano
Português
日本語
Nederlands
Русский