A modelagem de casos de uso é uma ferramenta útil para capturar requisitos. Ele fornece uma representação gráfica dos requisitos de um sistema de software.
Com a publicação do livro Object-Oriented Software Engineering, A Use-Case-Driven Approach , de Ivar Jacobson (1991) , a modelagem de casos de uso tornou-se efetivamente uma técnica de análise prática. Hoje, Jacobson continua a promover essa abordagem de análise de sistemas e a atualizou para o Caso de Uso 2.0, que é oficialmente um dos 14 tipos de diagramas UML .
Como o modelo de caso de uso é simples em conceito e aparência, é relativamente fácil discutir sua correção com pessoal não técnico (como clientes).
Um caso de uso não é um procedimento, processo ou função.
Os elementos do diagrama de casos de uso
Os elementos de um diagrama de caso de uso são os atores (entidades externas) e o próprio caso de uso. Em termos gerais, um caso de uso é uma unidade funcional (requisito) ou serviço em um sistema.
Ator
Um ator é qualquer entidade externa ao sistema de design, seja uma pessoa ou outra entidade não humana. Um usuário de um sistema é um exemplo típico de um ator. Outros tipos de atores incluem sistemas de software que estão sendo integrados ao sistema atual (por exemplo, um sistema de banco de dados), hardware externo, como um sensor e assim por diante.
Existem duas notações na especificação UML :
Usar stickman para atores é mais expressivo, mas pode gerar confusão se o ator não for realmente uma pessoa, mas uma máquina ou dispositivo externo. O símbolo do retângulo é a notação UML padrão para uma classe .
Um ator é um papel em vez de uma pessoa real
Um ator representa o papel da entidade que interage com o sistema atual, não uma instância. A notação de ator indica que a entidade é uma classe em vez de uma instância de leitura (ou seja, um usuário real John ou Mary). A razão pela qual um ator é um tipo de classe é que não é o próprio ator, mas o papel que ele desempenha.
Por exemplo, um ator pode representar os clientes de um banco, em vez de especificar um ator separado para cada cliente. Da mesma forma, pode haver outro ator representando o gerente do banco. Curiosamente, no mundo real, o gerente de um banco também pode ser um cliente do mesmo banco. Em outras palavras, a mesma pessoa desempenha o papel de cliente e gerente.
Atores Primários vs Secundários
O ator primário de um caso de uso é o stakeholder que requer que o sistema forneça seus serviços. Tem um objetivo associado ao sistema – um objetivo que pode ser satisfeito pela operação do sistema. O ator primário é geralmente, mas nem sempre, o ator que aciona o caso de uso.
O Ator Secundário é usado pelo sistema, mas eles não interagem com o sistema por conta própria. Em outras palavras, os atores secundários não iniciam nenhum caso de uso.
Os casos de uso geralmente são iniciados pelos atores primários. O sistema usa um ator secundário, como um banco de dados, por meio de um conjunto de casos de uso. A associação entre casos de uso e participantes representa uma comunicação bidirecional.
Assim, para cada caso de uso iniciado por um ator primário, o caso de uso conectado deve ser respondido. Da mesma forma, para cada associação entre um ator secundário e um caso de uso, a comunicação começa com o caso de uso e o ator secundário deve responder à iniciação.
Caso de uso
Os casos de uso representam as funções (geralmente requisitos) que devem ser implementadas pelo sistema. Os detalhes do caso de uso, exceto seu nome exclusivo, não são expressos intuitivamente no diagrama; Esses detalhes são fornecidos na descrição do caso de uso.
Os casos de uso geralmente são iniciados por atores-chave. O sistema utiliza banco de dados e outros participantes auxiliares por meio de um conjunto de casos de uso.
A associação entre casos de uso e atores representa uma comunicação bidirecional. Portanto, para cada caso de uso iniciado pelo ator principal, o último deve ser respondido. Da mesma forma, para cada associação entre o ator secundário e o caso de uso, a comunicação começa com o caso de uso e o ator secundário deve responder à iniciação.
Limite do sistema
A fronteira do sistema define o sistema de interesse em relação ao mundo ao seu redor.
Exemplo de diagrama de caso de uso: sistema de reservas de companhias aéreas
Os casos de uso definem interações entre atores externos e o sistema para atingir objetivos específicos. Um diagrama de caso de uso contém quatro componentes principais
No diagrama de casos de uso de um sistema de reserva de passagens, o sistema é representado por caixas contendo muitos casos de uso diferentes. O ator primário é o cliente e o ator secundário é o administrador. O cliente inicia os casos de uso, como reservar, navegar e cancelar voos, enquanto o administrador inicia os casos de uso, como atualizar registros de voo, mas é considerado um ator secundário no caso de uso cancelar voo, pois está apenas ajudando a concluir os casos de uso iniciados pelo cliente.
EDITE ESTE EXEMPLO DE DIAGRAMA DE CASO DE USO UML
Estruturando casos de uso
De acordo com o campo da aplicação e a escolha do designer, um caso de uso pode ser dividido em vários casos de uso, que são conectados por meio de relacionamentos < < include > > ou < < extend > >.
O link de associação representa uma comunicação bidirecional entre um ator e um caso de uso e, portanto, é um relacionamento binário. Como é uma comunicação bidirecional, para cada caso de uso iniciado por um ator primário, esse ator deve obter uma resposta do caso de uso.
Da mesma forma, para cada comunicação entre um caso de uso e um ator secundário (iniciado pelo caso de uso), o ator secundário deve enviar uma resposta de volta ao caso de uso.
Generalização
A generalização representa a relação entre
- papéis ou
- casos de uso.
EDITE ESTE MODELO DE DIAGRAMA DE CASO DE USO UML
Se dois atores estão conectados por esse relacionamento, então o ator (ou caso de uso) no final da seta (conectado à parte inferior do triângulo) é uma versão especializada do ator (ou caso de uso) na outra ponta.
Normalmente, o ator (ou caso de uso) na extremidade inferior (conectado à parte inferior do triângulo) é referido como a versão especializada do ator (ou caso de uso) na outra extremidade.
A generalização significa que a versão especializada tem todos os recursos da versão geral e possivelmente mais.
Incluir é um tipo especial de relacionamento entre dois casos 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.
EDITE ESTE EXEMPLO DE DIAGRAMA DE CASO DE USO
Estender é outro tipo especial de relacionamento entre dois casos de uso. 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. Porém, dependendo das condições descritas.
EDITE ESTE EXEMPLO DE DIAGRAMA DE CASO DE USO
Notações do diagrama de casos de uso
EDITE ESTE EXEMPLO DE DIAGRAMA DE CASO DE USO ONLINE
9 etapas simples para realizar a análise de caso de uso
- Determine quem usará diretamente o sistema. Essas pessoas são os atores.
- Escolha um desses atores.
- Defina o que esse ator quer fazer com o sistema. Cada coisa que o ator quer fazer com o sistema torna-se um caso de uso.
- Repita as etapas 2 a 3 para todos os outros casos de uso
Identifique as funções secundárias e o suporte a funções não humanas para os casos de uso que você identificou. - Desenhe a versão inicial do caso de uso, não complique demais os relacionamentos do caso de uso neste momento
- Discuta e revise com os usuários para validar os objetivos de cada caso de uso (benefícios da funcionalidade proposta) Após as modificações, você pode continuar detalhando os casos de uso nas etapas 8 a 10
- Para cada caso de uso, decida o processo mais comum que o ator seguirá ao usar o sistema. O que normalmente aconteceria.
- Descreva esse processo básico na descrição do caso de uso.
- Quando estiver satisfeito com o processo básico, considere cenários alternativos e adicione-os como casos de uso estendidos.
Modelo e Especificação de Caso de Uso
Não basta apenas mostrar o diagrama de casos de uso em notação UML. Cada caso de uso é acompanhado por um texto que explica o propósito do caso de uso e a funcionalidade que é realizada quando o caso de uso é executado.
Um caso de uso descreve uma tarefa executada por um ator que produz um resultado de valor de negócios para a empresa. Um caso de uso pode ser visualizado como um diagrama de caso de uso e/ou em um formato de especificação de texto estruturado .
Cenários de casos de uso
Um caso de uso consiste em vários cenários, cada um representando uma instância específica do caso de uso, correspondendo a entradas específicas do ator ou condições específicas no ambiente. Cada cenário descreve uma forma alternativa de comportamento do sistema, ou pode descrever falhas ou exceções.
Um caso de uso tem:
- Apenas um objetivo
- Um único ponto de partida
- Um único ponto final
- Vários caminhos para ir do início ao fim
- ou seja, especificar o comportamento para uma variedade de condições possíveis
- Cada condição pode exigir ação(ões) específica(s)
Por exemplo – o cliente paga a conta:
Existem vários caminhos para atingir o objetivo :
- Pagamento por telefone
- Por carta
- Em pessoa
- por cheque
- em dinheiro, etc
Um caminho que não leva ao objetivo:
- O cartão de crédito é recusado
Agrupando casos de uso com pacotes
Você também pode: Desenhar pacotes para categorização lógica de casos de uso em subsistemas relacionados.
EDITE ESTE EXEMPLO DE DIAGRAMA DE CASO DE USO
Especificação detalhada do caso de uso
Um caso de uso detalhado é uma representação textual que descreve um fluxo de eventos e outras informações de caso de uso relacionadas em um formato específico. Um modelo de caso de uso padrão é frequentemente usado para documentar os detalhes de um caso de uso
O que é uma descrição de caso de uso
Uma descrição de caso de uso é uma descrição escrita da sequência de etapas que um analista executa para concluir uma transação completa do sistema. Ele é iniciado por um ator, fornece valor a esse ator e é o objetivo dos atores que trabalham no sistema.
Ator – Qualquer pessoa ou sistema externo ao sistema que usa ou interage com o sistema para atingir um objetivo. Cada ator recebe um papel para representar sua interação com a solução. Os atores de pessoas devem ser nomeados na forma de papéis e não devem receber nomes reais. Os atores são geralmente categorizados como primários, secundários ou interessados.
Ator primário – O ator que inicia o caso de uso.
Ator secundário – O ator que reage ou responde às ações realizadas pelo ator primário.
Stakeholders – atores fora do palco que não interagem diretamente com o caso de uso, mas têm interesse no resultado do caso de uso.
Fluxo de fluxo de eventos (caminho) – a sequência de etapas que atores e soluções devem seguir para executar um caso de uso. Em geral, um caso de uso consiste em um caminho de sucesso primário (também chamado de básico ou primário), um caminho alternativo e um caminho de exceção.
O caminho Normal – a entrada do ator e a resposta do sistema – representa o caminho de sucesso mais comum para atingir os objetivos do ator.
Caminhos alternativos – entradas do ator e respostas do sistema, representando os outros caminhos menos comuns para atingir o objetivo do ator
Caminhos excepcionais – entradas do ator e resposta do sistema, representando caminhos malsucedidos quando o objetivo do ator não pode ser alcançado.
Descrição do caso de uso | |
---|---|
Nome do caso de uso: | Retirar o dinheiro |
Atores: | Cliente (primário), Sistema Bancário (secundário) |
Descrição do sumário: | Permite que qualquer cliente bancário retire dinheiro de sua conta bancária. |
Prioridade: | Deve ter |
Status: | Nível médio de detalhes |
Condição prévia: | O cliente do banco tem um cartão para inserir no caixa eletrônico O caixa eletrônico está online corretamente |
Pós-condições: |
|
Caminho básico: |
|
Caminhos alternativos: |
|
Regras do negócio: |
|
Requisitos não Funcionais: |
|
Links Relacionados
O que é Linguagem de Modelagem Unificada?
Slide de Caso de Uso / Notas de Aula
O Papel dos Casos de Uso na Modelagem de Requisitos e Análise
Experimente o Visual Paradigm GRÁTIS
Caso de Uso – Notas para Curso de Treinamento
Como escrever casos de uso eficazes?
Capítulo de Livro – PDF – Modelo de Caso de Uso: Escrevendo Requisitos no Contexto