LAB-8

Logo
Menu

Diagrama de Caso de Uso

1. O que é um Diagrama de Caso de Uso?

Um diagrama de casos de uso é uma representação visual das funcionalidades de um sistema, focando no comportamento externo. Ele é projetado para ser entendido por qualquer pessoa com algum conhecimento sobre o problema, mostrando o sistema do ponto de vista dos usuários.

Importância no Desenvolvimento de Sistemas

  • Início da Modelagem: Usado principalmente nas fases iniciais da modelagem de sistemas, durante a elicitação e análise de requisitos.
  • Visão Geral: Oferece uma visão externa das funções que o sistema deve fornecer, sem detalhar como estas serão implementadas.
  • Documentação e Especificação: Ajuda a especificar e documentar funções e serviços desejados pelos clientes e stakeholders.

Funções Principais

  • Identificação de Usuários e Papéis: Determina quem interagirá com o sistema, quais papéis assumirão e as funções que poderão solicitar.
  • Elicitação de Requisitos: Essencial para identificar e documentar requisitos funcionais do software.
  • Rastreabilidade de Requisitos: Facilita o monitoramento da origem e importância dos requisitos ao longo do projeto.

Durante o Desenvolvimento

Por ser menos formal e apresentar uma visão clara, o diagrama de casos de uso é ideal para:

  • Reuniões com Stakeholders: Ilustra as funcionalidades e comportamento do sistema, auxiliando na comunicação e compreensão.
  • Detecção de Falhas de Especificação: Permite verificar a clareza dos requisitos e garantir que estão bem compreendidos.
  • Complementação com Protótipos: Recomenda-se apresentá-lo junto a protótipos para um entendimento completo.

2. Atores no Diagrama de Casos de Uso

Em um diagrama de casos de uso, dois elementos principais são destacados: atores e casos de uso. Os atores representam os papéis desempenhados por usuários ou sistemas externos que interagem com o software.

Tipos de Atores

  • Usuários: Normalmente, atores são pessoas que utilizam o sistema e desempenham diferentes papéis conforme suas permissões. Por exemplo, um usuário pode agir como cliente, funcionário ou administrador, dependendo do nível de acesso ao sistema.
  • Componentes não humanos: Atores também podem ser hardware ou outros softwares interagindo com o sistema. Exemplo: um medidor de radiação (hardware) ou um sistema integrado (software).

Símbolos Visuais: Atores são representados por “bonecos palitos” no diagrama, com uma descrição breve abaixo do símbolo indicando seu papel.

Estereótipos: Elementos como hardware ou software são, às vezes, acompanhados por um estereótipo, como “<<  >>”, para destacar suas características especiais, diferenciando-os de atores humanos.

Como Identificar os Atores em Diagramas de Casos de Uso

1. Listar Entidades Externas:

Identifique todos os usuários humanos, softwares e hardwares que poderão interagir com o sistema.

2. Agrupar Usuários Semelhantes:

Agrupe usuários com características e níveis de permissão semelhantes em um único ator.

Perguntas Úteis

Para identificar potenciais atores, considere as seguintes questões:

  • Que tipos de usuários poderão utilizar o sistema?
  • Quais usuários estão interessados em funcionalidades e serviços do software?
  • Quem fornecerá e utilizará informações do sistema?
  • Quem poderá alterar ou excluir informações no sistema?
  • Existe algum software ou hardware especial que interagirá com o sistema?

Atribuição de Objetivos

Defina Metas para Atores:

Atribua responsabilidades e objetivos a cada ator identificado. Cada ator deve ter um objetivo claro a ser alcançado ao usar o sistema.

Filtragem de Atores:

Atores sem objetivos claros devem ser reconsiderados, pois podem não ser necessários.

3. Casos de Uso

O que são Casos de Uso?

Casos de uso são componentes essenciais na captura dos requisitos funcionais de um sistema. Eles descrevem as funcionalidades que o software deve oferecer, expressando os comportamentos esperados.

Forma: Casos de uso são representados por elipses com um texto dentro, descrevendo a ação. A descrição geralmente começa com um verbo, indicando a tarefa a ser realizada.

Exemplo: “Abrir Conta-Corrente” pode ser um caso de uso.

Classificação

Primários: Casos de uso que envolvem processos principais e requisitos funcionais importantes, como realizar um saque.

Secundários: Processos periféricos, como manutenção de cadastro. Em casos de muitos usos, os secundários podem ser simplificados ou omitidos para manter clareza.

Documentação

A documentação de casos de uso fornece:

  • Instruções gerais: Descreve o funcionamento do caso de uso.
  • Interações: Especifica quais atores usarão o caso e as atividades necessárias.
  • Eventos e Restrições: Detalha eventos que disparam ações e possíveis limitações.

Detalhamento

Nível Geral: A documentação deve ser completa sem entrar em detalhes técnicos.

Complemento por Outros Diagramas: Detalhamentos técnicos são realizados nas fases posteriores com outros diagramas.

  • Estrutura da Documentação

1. Identificação

  • Nome e Código: Cada caso de uso recebe um nome e um código único, como UC01 – Abrir Conta.
  • Ator Principal e Secundários: O ator principal tem a maior interação com o caso, enquanto os secundários têm papéis menores.

2. Descrição

  • Resumo: Explica de forma breve o objetivo do caso de uso.
  • Pré-condições: Condições que devem ser satisfeitas antes de iniciar o caso.
  • Pós-condições: Tarefas que precisam ser realizadas após a conclusão.

3. Cenários

  • Cenário Principal: O fluxo normal de ações, dividido em ações do ator e do sistema. Este é o “caminho feliz” onde tudo ocorre conforme esperado.
  • Cenários Alternativos: Fluxos que ocorrem sob certas condições, como necessidade de atualização de cadastro.
  • Cenários de Exceção: Ações a serem tomadas quando há falhas, como quebrar uma regra de negócio.

4. Restrições e Validações

  • Restrições: Condições obrigatórias, como a necessidade de ser maior de idade para abrir uma conta.
  • Validações: Regras que precisam ser verificadas, como o valor mínimo de depósito.

Exemplo: Sequência de Ações no Caso de Uso: Abrir Conta

1. Nome do Caso de Uso: UC01 – Abrir Conta

2. Ator Principal: Funcionário

3. Atores Secundários: Cliente

4. Resumo: Esse caso de uso descreve as etapas percorridas por um cliente, intermediado por um funcionário, para abrir uma conta-corrente.

5. Pré-condições: O pedido de abertura precisa ter sido previamente aprovado

6. Pós-condições É necessário realizar um depósito inicial

Cenário Principal

Ações do Ator:

1. Funcionário consulta o CPF ou CNPJ do cliente.

3. Cliente informa a senha da conta.

5. Cliente fornece um valor a ser depositado.

Ações do Sistema:

2. Consulta o cliente pelo CPF ou CNPJ.
4. Abre a conta.
6. Executa o caso de uso “Realizar Depósito” para registrar o depósito.
7. Emite o cartão da conta.

Restrições/Validações:

1. Para abrir uma conta-corrente, é preciso ser maior de idade
2. O valor mínimo de depósito é R$ 5,00
3. O cliente precisa fornecer algum comprovante de residência

Cenário Alternativo: Manutenção do Cadastro do Cliente

  • Ação do Sistema: Executa o caso de uso “Gerenciar Clientes” para registrar ou atualizar o cadastro do cliente.

Cenário de Exceção: Cliente menor de idade

  • Ações do Sistema: Informa ao cliente que não atende à idade mínima. Recusa o pedido de abertura de conta.

Como Identificar Casos de Uso

Para construir um modelo de casos de uso eficaz, é essencial identificar as funcionalidades necessárias ao software. Essas funcionalidades correspondem aos requisitos funcionais declarados pelos stakeholders.

Passos para Identificação

1. Verificar Atores:

Liste os atores do sistema e identifique seus objetivos, que geralmente refletem funcionalidades específicas.

2. Eventos Externos:

Considere eventos externos que possam afetar o software, pois eles podem desencadear ou influenciar funcionalidades.

3. Requisitos Funcionais:

Revise os requisitos funcionais definidos com os stakeholders para garantir que cada um possua um caso de uso associado.

Validação dos Casos de Uso

  • Sequência de Ações: Verifique se as funcionalidades têm uma sequência clara de passos. Se não houver, pode não ser um caso de uso real.
  • Comparação de Passos: Se um caso de uso tem poucos passos, ele pode precisar ser adaptado para se integrar a outro caso maior ou ser considerado um cenário alternativo de outro caso.

4. Associações

As associações representam as interações entre atores e casos de uso ou entre diferentes casos de uso em um diagrama. Elas mostram como os atores utilizam as funcionalidades do sistema.

Direção das Informações: Setas indicam o fluxo de informações, quando as associações não tem seta, significa que o fluxo vai em ambas as direções.
As stas também mostram quem inicia a interação.

Tipos de Relacionamentos
Entre Atores e Casos de Uso:

Linhas conectando atores aos casos de uso, indicando que o ator utiliza a funcionalidade.

Exemplo: Associação Cliente e Abrir Conta:

O Cliente utiliza a funcionalidade de abrir conta, e a informação trafega em ambas as direções, o que indica uma interação bidirecional.

Entre Casos de Uso:

Relacionamentos podem ser de inclusão, extensão ou generalização,

5. Generalização/Especialização

Este relacionamento aplica os princípios de herança da orientação a objetos, permitindo que um caso de uso geral seja especializado por outros casos de uso que herdam suas características e associações.

Benefícios

Redução de Repetição: A estrutura e as associações do caso de uso geral são herdadas pelos especializados, eliminando a necessidade de duplicar informações.

Simplificação: Facilita a documentação, já que os detalhes comuns são centralizados no caso de uso geral.

Exemplo Prático

Abertura de Conta:

  • Caso Geral: Abrir Conta Comum.
  • Especializações: Abrir Conta Especial (inclui definição de limite) e Abrir Conta Poupança (sem a necessidade de maioridade).

Aplicação em Atores

Exemplo de Atores:

  • Ator Geral: Pessoa.
  • Especializações: Pessoa Física e Pessoa Jurídica.

Usuário Hierárquico:

  • Usuário Júnior: Pode Ler Arquivo.
  • Usuário Sênior: Herda Ler Arquivo e pode Gravar Arquivo.
  • Administrador: Herda Ler e Gravar Arquivo, e pode Excluir Arquivo.

Considerações

Uso Moderado: Embora útil para evitar repetição, pode complicar a compreensão do diagrama. Use com parcimônia.

6. Inclusão

A inclusão em casos de uso é utilizada quando há uma rotina ou cenário comum a mais de um caso de uso. Isso ajuda a evitar a repetição de sequências de passos, centralizando a documentação em um único caso de uso específico.

Características

  • Obrigatoriedade: Quando um caso de uso inclui outro, a execução do primeiro obriga a execução do segundo.
  • Comparação: Funciona como uma sub-rotina ou função nas linguagens de programação.

Representação Gráfica

Linha Tracejada: Com uma seta apontando para o caso de uso incluído, junto com o estereótipo “<<  >>”.

Exemplos Práticos

1. Sistema Bancário:

  • Caso de Uso Comum: Registrar Movimento.
  • Inclusões: Realizar Depósito e Realizar Saque obrigatoriamente incluem o registro dos movimentos para fins históricos.

2. Livraria Virtual:

  • Caso de Uso Comum: Visualizar Carrinho.
  • Inclusão Necessária: Antes de Concluir Pedido, é obrigatório visualizar o carrinho, garantindo que o cliente revise suas escolhas antes de finalizar.

Vantagens

  • Redução de Repetição: Evita descrever etapas repetidas em vários casos de uso.
  • Facilidade de Manutenção: Simplifica futuras atualizações e modificações nas rotinas compartilhadas. antes de finalizar.

7. Extensão

As associações de extensão descrevem cenários opcionais que acontecem apenas em condições específicas. Eles acrescentam passos extras a um caso de uso quando certas condições são atendidas.

Características

  • Opcionalidade: Não ocorrem sempre, mas são ativadas sob circunstâncias específicas.
  • Condições: Requerem a verificação de condições antes de serem executadas.

Representação Gráfica

  • Linha Tracejada: Com uma seta apontando para o caso de uso que ativa o caso de uso estendido, e o estereótipo “<<  >>”.

Exemplos Práticos

1. Formulário de Login:

  • Caso Base: Realizar Login.
  • Extensão: Autorregistrar. Ativado se o cliente não estiver cadastrado.

2. Encerramento de Conta:

  • Caso Base: Encerrar Conta.
  • Extensões:
    • Realizar Saque (se saldo positivo).
    • Realizar Depósito (se saldo negativo).
  • Apenas um dos casos de uso estendidos será acionado, dependendo do saldo da conta.

Vantagens

  • Flexibilidade: Permite adicionar funcionalidade sem complicar o fluxo principal.
  • Clareza: Mantém o diagrama organizado, separando cenários comuns de opcionais.

Restrições em Associações de Extensão

O que são Restrições?

Restrições são regras definidas em texto entre chaves ({}) usadas para validar e garantir consistências em componentes ou situações específicas. Elas ajudam a determinar quando e como certas ações ou casos de uso podem ser executados.

Uso de Restrições em Extensões

Em extensões, pode ser difícil entender quando um caso de uso estendido deve acontecer. Para isso, utilizamos restrições que são adicionadas através de notas explicativas. Essas notas descrevem as condições necessárias para que o caso de uso seja ativado.

Exemplo 1: Registro Automático

  • Condição: O caso de uso “Autorregistrar” é executado apenas se o cliente ainda não estiver registrado.
  • Nota Explicativa: Usada para comentar ou colocar restrições, conectada ao componente por uma seta tracejada chamada âncora.

Exemplo 2: Realizar Transações 

  • Condição para Saque: O saldo da conta a ser encerrada deve ser positivo.
  • Condição para Depósito: O saldo da conta deve ser negativo.
  • Essas condições representam regras de negócios para o encerramento de conta.

Importância das Restrições

As restrições são fundamentais para garantir que o sistema se comporte conforme planejado, respeitando as regras de negócio e evitando erros de execução. Elas servem como guias claras para desenvolvedores e usuários do sistema sobre quando e como as operações podem ser realizadas.

Documentação do Caso de Uso “Encerrar Conta” (UC10).

Exemplo: Sequência de Ações no Caso de Uso: Encerrar Conta

1. Nome do Caso de Uso: UC10 – Encerrar Conta

2. Ator Principal: Funcionário

3. Atores Secundários: Clientes

4. Resumo: Este caso de uso descreve as etapas necessárias para que um cliente encerre uma conta.

5. Pré-condições: É necessário existir uma conta ativa

6. Pós-condições:

Cenário Principal

Ações do Ator:

1.O cliente solicita o encerramento da conta fornecendo o número da conta em questão

2.O funcionário solicita a emissão do saldo da conta
Ações do Sistema:

3.Executar caso de uso Emitir Saldo
4.Encerrar a conta

Restrições/Validações:

1. A conta só pode ser encerrada pelo titular

2. A conta só pode ser encerrada se o seu saldo estiver zerado

Cenário Alternativo-I: Saldo Positivo

  • Executar Caso de Uso Realizar Saque

Cenário Alternativo-II: Saldo Negativo

  • Executar Caso de Uso Realizar Depósito

Cenário Alternativo-III: Manutenção do Cadastro do Cliente

  • Se for a única conta do cliente, será preciso atualizar seu cadastro, tornando-o inativo – Executar Caso de Uso Gerenciar Clientes

8. Fronteira do Sistema

A fronteira de sistema é uma ferramenta usada para identificar e delimitar um conjunto de casos de uso dentro de um sistema ou subsistema. Ela ajuda a destacar o que faz parte do sistema e o que está fora dele.

Representação

  • Forma Gráfica: Representada por um retângulo envolvendo os casos de uso relevantes.
  • Título: O retângulo possui um título que descreve o sistema ou subsistema.

Função

  • Delimitação: Define claramente o que está incluído no sistema.
  • Clareza Visual: Facilita a compreensão de quais componentes pertencem ao sistema e como eles se relacionam com os atores externos.

9. Exemplo: Sistema de Controle Bancário

Diagrama de Casos de Uso: Representa um sistema de controle bancário.

Funcionalidades: Clientes podem abrir e encerrar contas, realizar depósitos e saques, emitir saldos e extratos.

Interação com Funcionários: Abrir ou encerrar conta requer interação com um funcionário do banco.

Fronteira do Sistema: Separação entre atores (clientes e funcionários) e funcionalidades internas.

Tipos de Conta: Contas comuns, especiais e poupança, com abertura especializada.

Associações de Casos de Uso:

  • Extensão: “Abrir Conta Comum” e “Gerenciar Clientes” para registro ou atualização de dados.
  • Inclusão: Obrigatoriedade de depósito ao abrir conta.

Encerramento de Conta:

  • Verificação de saldo obrigatória.
  • Realização de saque ou depósito dependendo do saldo.
  • Extensão com “Gerenciar Cliente” para clientes sem contas ativas.

Serviços Diretos no Caixa Eletrônico: “Emitir Saldo” e “Emitir Extrato”, sendo realizados pelo cliente.

Registro de Movimentos:

  • Obrigatório em depósitos e saques.
  • Associação de inclusão com “Registrar Movimento”.

Complexidade: Uso de diferentes associações para demonstrar recursos no diagrama.

Documentação:

Atores que Interagem com o Sistema

  • Cliente – Este ator representa as pessoas físicas ou jurídicas que mantêm ou mantiveram contas na instituição bancária, com direito a utilizar serviços como saque, depósito, saldo ou extrato enquanto mantiveram(em) contas
  • Funcionário – Este ator representa os funcionários contratados para atender presencialmente os clientes da instituição. São basicamente os caixas do banco.

UC01 – Abrir Conta

  • Ator Principal: Funcionário
  • Atores Secundários: Cliente
  • Resumo: Esse caso de uso descreve as etapas percorridas por um cliente, intermediado por um funcionário, para abrir uma conta-corrente.
  • Pré-condições: O pedido de abertura precisa ter sido previamente aprovado
  • Pós-condições É necessário realizar um depósito inicial

UC02 – Abrir Conta Especial

  • Caso de Uso Geral: Abrir Conta Comum
  • Ator Principal: Funcionário
  • Atores Secundários: Clientes
  • Resumo: Este caso de uso descreve as etapas para um cliente abrir uma conta-corrente especial com a intermediação de um funcionário.
  • Pré-condições: O pedido de abertura precisa ser aprovado.
  • Pós-condições: É necessário realizar um depósito inicial.

UC03 – Abrir Conta Poupança

  • Caso de Uso Geral: Abrir Conta Comum
  • Ator Principal: Funcionário
  • Atores Secundários: Clientes
  • Resumo: Este caso de uso descreve as etapas percorridas por um cliente para abrir uma conta poupança com intermediação de um funcionário.
  • Pré-condições: Idênticas às do caso de uso Abrir Conta Comum.
  • Pós-condições: Não é obrigatória a realização de um depósito inicial.

UC04 – Gerenciar Clientes

  • Ator Principal: Funcionário
  • Atores Secundários: Nenhum
  • Resumo: Descreve as atividades de manutenção do cadastro de clientes, permitindo incluir, alterar ou consultar clientes. Um cliente não pode ser excluído, apenas tornar-se inativo.
  • Pré-condições: Nenhuma específica.
  • Pós-condições: Nenhuma específica.

UC05 – Realizar Depósito

  • Ator Principal: Funcionário
  • Atores Secundários: Clientes
  • Resumo: Descreve os passos necessários para um cliente depositar algum valor em uma determinada conta.
  • Pré-condições: A conta precisa existir e estar ativa.
  • Pós-condições: O valor é adicionado ao saldo da conta.

UC06 – Emitir Saldo

  • Ator Principal: Cliente
  • Atores Secundários: Nenhum
  • Resumo: Descreve os passos necessários para um cliente obter o saldo referente a uma determinada conta.
  • Pré-condições: A conta precisa existir e estar ativa, e a senha precisa estar correta.
  • Pós-condições: O saldo da conta é fornecido ao cliente.

U07 – Emitir Extrato

  • Ator Principal: Cliente
    Atores Secundários: Nenhum
    Resumo: Descreve os passos para o cliente obter o extrato de uma conta em um dado período.
    Pré-condições: A conta deve existir e estar ativa.
    Pós-condições: O extrato é emitido dentro do período solicitado.

UC08 – Realizar Saque

  • Ator Principal: Cliente
  • Atores Secundários: Nenhum
  • Resumo: Descreve os passos para um cliente sacar algum valor de uma determinada conta.
  • Pré-condições: A conta deve existir, estar ativa, e a senha precisa estar correta.
  • Pós-condições: O saldo é atualizado descontando o valor sacado.

U09 – Registrar Movimento

  • Ator Principal: Cliente
  • Atores Secundários: Nenhum
  • Resumo: Descreve os passos necessários para registrar um movimento referente a uma conta.
  • Pré-condições: Nenhuma específica.
  • Pós-condições: O movimento é registrado no sistema.

UC10 – Encerrar Conta

  • Ator Principal: Funcionário
  • Atores Secundários: Clientes
  • Resumo: Este caso de uso descreve as etapas necessárias para que um cliente encerre uma conta.
  • Pré-condições: É necessário existir uma conta ativa
  • Pós-condições:

10. Exercício

Sistema de Biblioteca 

Neste exercício, elaboraremos um diagrama de casos de uso para um sistema de biblioteca. Esse sistema é projetado para gerenciar múltiplos exemplares de livros, abrangendo diversos gêneros literários. Para isso, será necessário incluir módulos específicos para a manutenção de cadastros de livros, gêneros e autores. Além disso, o sistema exigirá um módulo dedicado ao cadastro de sócios, uma vez que apenas sócios registrados podem locar livros.

O centro do sistema é o processo de locação de exemplares. Nele, o sócio se identifica e informa os exemplares que deseja emprestar. Essa locação só é permitida se o sócio não tiver empréstimos em atraso e ainda estiver dentro do limite de exemplares que pode manter emprestado.

Além da locação, outros processos essenciais incluem a devolução, onde o sócio retorna livros, a renovação, permitindo estender o prazo de empréstimo, e a reserva de exemplares, para futuros empréstimos assim que os livros desejados forem devolvidos.

Em termos gerenciais, o sistema possibilita a emissão de relatórios que destacam os livros e autores mais locados, proporcionando insights valiosos sobre as preferências dos sócios.

No diagrama, cada processo de manutenção de cadastro é representado como um caso de uso, especificamente chamado de Gerenciar Sócios ou Gerenciar Livros. Esses casos são considerados secundários, dando suporte aos casos de uso primários: Locar Exemplares, Devolver Exemplares, Renovar Exemplares e Reservar Exemplares. Tais casos capturam as interações de locação e as ações subsequentes como devoluções e renovações.

A visualização clara e concisa dos casos de uso é fundamental para evitar complexidade excessiva nos diagramas. Assim, para casos de uso secundários menos complexos, é recomendado generalizá-los em agrupamentos como “Gerenciar Cadastros” ou “Emitir Relatórios.”

No sistema, o ator Sócio interage principalmente com os processos de locação, devolução, renovação e reserva, enquanto o funcionário acessa demais funcionalidades administrativas e gerenciais, incluindo a manutenção de cadastros.

Toda verificação sobre o status de registro do sócio ou locações pendentes ocorre internamente no caso de uso de locação. Isso elimina a necessidade de casos de uso separados para essas validações, simplificando o diagrama e mantendo a documentação clara e focada.