Um guia rápido para modelagem de casos de uso

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.Tipos de atores

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.

O cliente paga a conta

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

Tutorial de diagrama de caso de uso

EDITE ESTE EXEMPLO DE DIAGRAMA DE CASO DE USO ONLINE

9 etapas simples para realizar a análise de caso de uso

  1. Determine quem usará diretamente o sistema. Essas pessoas são os atores.
  2. Escolha um desses atores.
  3. 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.
  4. 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.
  5. Desenhe a versão inicial do caso de uso, não complique demais os relacionamentos do caso de uso neste momento
  6. 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
  7. Para cada caso de uso, decida o processo mais comum que o ator seguirá ao usar o sistema. O que normalmente aconteceria.
  8. Descreva esse processo básico na descrição do caso de uso.
  9. 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 .

Caso de Uso x Especificação de Caso de Uso

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)

Características dos casos de uso

Por exemplo – o cliente paga a conta:

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.

Diagrama de caso de uso UML com pacotes

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

Uma especificação detalhada de 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:
  • O cliente do banco recebeu seu dinheiro (e opcionalmente um recibo)
  • O banco debitou a conta bancária do cliente e registrou os detalhes da transação
Caminho básico:
  1. O cliente insere seu cartão no caixa eletrônico
  2. O caixa eletrônico verifica se o cartão é um cartão bancário válido
  3. O caixa eletrônico solicita um código PIN
  4. O cliente insere seu código PIN
  5. O caixa eletrônico valida o cartão bancário em relação ao código PIN
  6. O ATM apresenta opções de serviço incluindo “Retirar”
  7. O cliente escolhe “Retirar”
  8. O caixa eletrônico apresenta opções de valores
  9. O cliente seleciona um valor ou insere um valor
  10. O caixa eletrônico verifica se tem dinheiro suficiente em seu depósito
  11. O caixa eletrônico verifica se o cliente está abaixo dos limites de saque
  12. O caixa eletrônico verifica fundos suficientes na conta bancária do cliente
  13. O caixa eletrônico debita a conta bancária do cliente
  14. O caixa eletrônico devolve o cartão bancário do cliente
  15. O cliente leva seu cartão bancário
  16. O caixa eletrônico emite o dinheiro do cliente
  17. O cliente leva seu dinheiro
Caminhos alternativos:
  1. 2a. Cartão inválido
  2. 2b. Cartão de cabeça para baixo
  3. 5a. Cartão roubado
  4. 5b. PIN inválido
  5. 10a. Dinheiro insuficiente no funil
  6. 10b. Denominação errada de dinheiro no funil
  7. 11a. Retirada acima dos limites de retirada
  8. 12a. Fundos insuficientes na conta bancária do cliente
  9. 14a. Cartão bancário preso na máquina
  10. 15a. O cliente não aceita o cartão bancário
  11. 16a. Dinheiro preso na máquina
  12. 17a. Cliente não aceita o dinheiro
    • um caixa eletrônico não pode se comunicar com o sistema bancário
    • b O cliente não responde ao prompt do caixa eletrônico
Regras do negócio:
  1. B1: Formato do PIN
  2. B2: Número de tentativas de PIN
  3. B3: Opções de serviço
  4. B4: Opções de valor
  5. B5: Limite de saque
  6. B6: o cartão deve ser retirado antes de dispensar o dinheiro
Requisitos não Funcionais:
  1. NF1: Tempo para transação completa
  2. NF2: Segurança para entrada de PIN
  3. NF3: Tempo para permitir a retirada de cartão e dinheiro
  4. NF4: Suporte a idiomas
  5. NF5: Suporte cego e parcialmente cego

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

Uma lista de ferramentas UML

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

Leave a Reply

O seu endereço de email não será publicado.