Simbologia do Diagrama de Caso de Uso

Simbologia do Diagrama

1. Atores

Os papéis dos usuários de um sistema são modelados através dos atores. Cada ator representa uma classe de usuários, modelando os papéis, não as pessoas. Pode-se definir atores não humanos, para modelar outros sistemas que devam interagir com o sistema.

Atores genéricos e específicos são ligados por relacionamentos de herança.

2. Casos de Uso

 

Os casos de uso representam funções completas do sistema.

Também nos casos de uso, podemos utilizar generalização.

3. Relacionamentos entre atores e casos de uso

Relacionamentos indicam a existência de comunicação entre atores e casos de uso. Um caso de uso pode estar associado a mais de um ator, quando a sua execução requer a participação de diferentes atores. A comunicação é representada como ligação sem direção. Pode-se utilizar o direcionamento quando a iniciativa da comunicação parte do caso de uso para o ator. 

4. Relacionamentos entre casos de uso 

Notações especiais são utilizadas para facilitar a descrição da funcionalidade mais complexa.

Uma obrigatoriedade indica um tipo de relação <<uses>> / <<include>> 

Uma exceção ou situação inesperada indica um tipo de relação <<extends>>.

Casos de uso podem ter um relacionamento de dependência entre eles.

5. Fluxos dos casos de uso 

São detalhados por meio de descrição textuais. Inclui as pré-condições, fluxo principal, fluxos alternativos e fluxos de exceção.

Documentação dos Casos de Uso

·        Nome

·        Identificador

·        Importância

·        Sumário

·        Ator Primário

·        Ator Secundário

·        Pré-condições

·        Fluxo Principal

·        Fluxos Alternativos

·        Fluxos de exceção

Documentação dos Atores

Contém uma breve descrição do mesmo, cujo nome deve ser escolhido de tal forma a lembrar o papel por ele desempenhado.

Documentação dos casos de uso:

·        Nome: o mesmo nome que aparece no diagrama de casos de uso.

·        Identificador: um código que permite fazer referência cruzada entre diversos documentos relacionados com o caso de uso.

·        Importância: Considera os riscos de desenvolvimento e as prioridades estabelecidas pelo usuário.

1.     Risco alto e prioridade alta – os mais críticos.

2.     Risco alto e prioridade baixa – recomenda-se negociar com o cliente sobre a sua verdadeira necessidade.

3.     Risco baixo e prioridade alta – considere primeiro os com alto risco.

4.     Risco baixo e prioridade baixa – são os primeiros a ser cortados em caso de atraso do sistema.

·        Sumário: pequena descrição do caso de uso.

·        Ator Primário: nome do ator que inicia o caso de uso.

·        Ator Secundário: os nomes dos demais atores participantes do caso de uso, se existirem.

·        Pré-condições: define que hipóteses são assumidas como verdadeiras para que o caso de uso tenha início. Ex.: o cliente deve estar identificado no sistema.

·        Fluxo Principal: descreve o que normalmente acontece quando o caso de uso é realizado. Usa texto descritivo conciso e claro. O modelador deve se ater ao domínio do problema e não à solução. Devem ser escritos do ponto de vista do usuário usando a terminologia deste.

·        Fluxos Alternativos: podem ser utilizados para descrever o que acontece quando o ator faz uma escolha alternativa, diferente da descrita no fluxo principal. Ou para descrever situações de escolhas exclusivas entre si (diversas alternativas, mas só uma deve ser realizada). Ex.: pagamento à vista, cartão crédito, débito ou cheque.

·        Fluxos de exceção: descrevem o que acontece quando algo inesperado ocorre na interação entre ator e caso de uso. Possui algumas características importantes:

1.     Representa um erro de operação durante o fluxo do caso de uso.

2.     Não tem sentido fora do contexto do caso de uso no qual ocorre.

3.     Deve indicar em que passo o caso de uso continua ou, conforme for, indicar explicitamente que o caso de uso termina.

·        Pós-condições: é um estado que o sistema alcança após o caso de uso ter sido realizado. Ex.: O status do quarto passa a reservado após o caso de uso “Reservar” ser realizado.

·        Histórico: pode declarar informação sobre a autoria, alteração e data do caso de uso.

·        Regras de Negócio: pode fazer referência a uma ou mais regras de negócio definidas com o usuário.

Documentação associada ao modelo de casos de uso

Regras do negócio: são políticas, condições ou restrições que devem ser consideradas na execução dos processos existentes em uma organização.

Requisitos de desempenho: define características relacionadas à operação do sistema. Pode-se associar requisitos e casos de uso.

Requisitos de interface: o cliente pode definir restrições específicas com respeito à interface do sistema, que podem ser relacionados a um ou mais casos de uso.

 

EXEMPLO 1

Descrição de Caso de Uso – Saque de Dinheiro

1.     Breve Descrição

Este caso de uso descreve como um Cliente do banco usa um ATM para sacar dinheiro de uma conta bancária.

2.     Diagrama de Casos de Uso

1.     Pré-condições

Ø  O Cliente do Banco deve possuir um cartão;

Ø  A conexão de rede com o Sistema Bancário deve estar ativa;

Ø  O sistema deve possuir pelo menos algum numerário que possa ser entregue;

Ø  A Opção de Serviço de Saque deve estar disponível.

2.     Fluxo Básico

{Inserir Cartão}

1. O caso de uso começa quando o ator Cliente insere um cartão de banco na leitora de cartões do ATM;
2. O sistema aloca um identificador de sessão ATM para permitir o rastreamento de erros e sincronização entre o ATM e o Sistema Bancário;

{Ler Cartão}

3. O sistema lê as informações do cartão de banco a partir do cartão;

{Autenticar Cliente}

4. Inclui o caso de uso Autenticar Cliente para autenticar a utilização do cartão de banco pelo indivíduo que está usando a máquina;

{Selecionar Saque}

5. O sistema mostra as diferentes opções de serviço que estão atualmente disponíveis na máquina;
6. O Cliente opta por sacar dinheiro;

{Selecionar Quantia}

7. O sistema apresenta a lista de valores padrão de saque e solicita que o valor seja informado;
8. O Cliente seleciona uma quantia a ser sacada;

{Confirmar Saque}

9. Executa Verificar Fundos Disponíveis;
10. Executa Realizar Transação;

{Ejetar Cartão}

11. O sistema libera o cartão de banco do Cliente;
12. O Cliente retira o cartão de banco da máquina;

{Liberar Numerário}

13. O sistema libera a quantidade de numerário solicitada pelo Cliente;
14. O sistema registra uma entrada de log da transação referente ao saque;

{Finalizar Caso de Uso}

15. O caso de uso é encerrado.

3.     Fluxos Alternativos

5.1 Facilidade de Saque com Valor Diferenciado

5.1.1 Gerenciar Valor não Padrão de Saque

Em {Selecionar Quantia}, se o Cliente necessitar de um valor não padrão,

1. O sistema solicita que o Cliente informe o valor desejado, indicando que a quantia deve ser múltipla de um conjunto de notas disponíveis, deve ser menor que o valor do limite de saque do ATM e o limite atualmente disponível no ATM;
2. O Cliente informa o valor desejado;
3. O caso de uso retorna ao fluxo básico em {Confirmar Saque}.

5.2 Gerenciamento de Cartão

5.2.1 Gerenciamento de Cartão Emperrado

Em {Inserir Cartão}, ou {Ejetar Cartão}, se o cartão de banco ficar preso na leitora de cartões,

{Ejeção de Emergência}

1. O sistema tenta ejetar o cartão;
2. Se a ejeção do cartão tiver sucesso o sistema informa o Cliente que:
1. O cartão deve estar com problemas;
2. O Cliente deve contatar o Banco para substituição do cartão;
3. O Cliente deve retirar o cartão de banco da máquina;
3. O caso de uso retorna ao fluxo básico em {Finalizar Caso de Uso}.

{Recolhimento de Emergência}

4. Se a ejeção de emergência não funcionar, o sistema tenta recolher o cartão, adicionando-o aos cartões confiscados;
5. Se o recolhimento do cartão tiver sucesso, o sistema:
1. Captura um vídeo de 10 segundos do Cliente;
2. Cria uma entrada no log de eventos para registrar o fato de que o cartão foi recolhido porque ficou preso na leitora de cartões. A entrada no log de eventos inclui o vídeo e as informações do cartão de banco (Exceto o PIN se estiver disponível);
3. Envia a entrada do log de eventos para o Sistema Bancário e para o Administrador do Serviço, para informá-los que o cartão foi recolhido porque ficou preso na leitora de cartões;
4. Informa o Cliente que o cartão não poderá ser devolvido por causa de um problema técnico e que ele deve contatar a empresa responsável pelo serviço para que o cartão seja devolvido.

{Cartão Emperrado}

6. Se o cartão não puder ser ejetado nem recolhido, o sistema,
1. Captura um vídeo de 10 segundos do Cliente;
2. Cria uma entrada no log de eventos para registrar o fato de que o cartão está emperrado na leitora de cartões. A entrada no log de eventos inclui o vídeo e as informações do cartão de banco (Exceto o PIN se estiver disponível);
3. Envia a entrada do log de eventos para o Sistema Bancário e para o Administrador do Serviço, para informá-los que o cartão ficou emperrado na leitora de cartões do ATM;
4. Informa o Cliente que o cartão não poderá ser devolvido por causa de um problema técnico e que ele deve contatar a empresa responsável pelo serviço para que o cartão seja devolvido.
7. Se o cartão continuar emperrado o sistema executa o desligamento do serviço para encerrar todas as opções de serviço e finalizar o caso de uso.

5.2.2 Gerenciamento de Cartão de Banco com Problema de Leitura

Em {Ler Cartão}, se o sistema não puder ler todas as informações do cartão de banco,

1. O sistema captura um vídeo de 10 segundos do Cliente;
2. O sistema cria uma entrada no log de eventos para registrar o fato de que o cartão não pôde ser lido. A entrada no log de eventos inclui o vídeo e as informações do cartão de banco (Exceto o PIN se estiver disponível);
3. Informa o Cliente que o cartão não pôde ser lido e que ele deve contatar o banco para verificação do cartão.

{Ejetar Cartão}

4. O sistema ejeta o cartão de banco do Cliente;
5. O Cliente retira o cartão de banco da máquina;
6. O caso de uso retorna ao fluxo básico em {Finalizar Caso de Uso}.

5.2.3 Gerenciamento de Cartão Inválido

Em {Ler Cartão}, se o sistema não suportar a instituição financeira associada ao cartão ou não puder identificar a instituição financeira associada ao cartão,

1. O sistema captura um vídeo de 10 segundos do Cliente;
2. O sistema cria uma entrada no log de eventos para registrar o fato de que uma tentativa de uso do ATM foi realizada usando um cartão inválido. A entrada no log de eventos inclui o vídeo e as informações do cartão de banco (Exceto o PIN se estiver disponível);
3. Informa o Cliente que o cartão não pode ser usado neste ATM;

{Ejetar Cartão}

4. O sistema ejeta o cartão de banco do Cliente;
5. O Cliente retira o cartão de banco da máquina;
6. O caso de uso retorna ao fluxo básico em {Finalizar Caso de Uso}.

5.2.4 Gerenciamento de Cartão Esquecido pelo Cliente

Em {Ejetar Cartão}, ou em {Ejeção de Emergência}, se o cartão de banco não for removido do ATM em 30 segundos,

1. O sistema emite um sinal sonoro para alertar o Cliente;
2. Se o cartão inda não tiver sido retirado após um minuto do alerta sonoro, então o sistema,

{Recolher Cartão}

1. Recolhe o cartão e o adiciona aos cartões confiscados;

{Ajustar Saldo da Conta}

2. Se ainda houver fundos a serem liberados, então o sistema executa Gerencia Transação de Ajuste para por o dinheiro de volta na conta, pois não será mais liberado;

{Registrar Evento}

3. O sistema cria uma entrada no log de eventos para registrar o fato de que o cartão foi esquecido no ATM. A entrada no log de eventos inclui as informações do cartão de banco (Exceto o PIN se estiver disponível);
4. O sistema envia a entrada no log do evento para o Sistema Bancário para informar que o cartão foi deixado no ATM;
5. O sistema desliga o alerta sonoro.
2. O caso de uso retorna ao fluxo básico em {Finalizar Caso de Uso}.

4.     Sub-Fluxos

6.1 Verificar Fundos Disponíveis

1. O sistema determina se possui fundos suficientes no ATM  para atender a requisição de um determinado valor.
1. O sistema verifica se a quantia total requisitada é maior é maior do que a quantia atualmente disponível no ATM;
2. O sistema verifica se a quantia requisitada pode ser atendida com uma composição de notas atualmente disponíveis no ATM. Veja que é possível ter fundos suficientes no total, porém ainda não ser possível atender a quantia requisitada. Considere a situação onde o cliente requisitou R$35,00,  o sistema possui no total R$40,00, porém em duas notas de R$20,00.
2. Se não houver fundos suficientes no ATM, o sistema,
1. Informa ao Cliente que a quantia solicitada não está disponível no ATM;
2. Oferece ao cliente escolhas dentro das quantias disponíveis, que sejam mais próximas da quantia requisitada. Se a quantia originalmente requisitada foi rejeitada devido a composição de notas disponíveis, então o sistema  oferece escolhas contemplado os valores imediatamente superiores e inferiores ao valor requisitado. Se a quantia originalmente requisitada foi rejeitada devido a insuficiência de fundos, então o sistema oferece a maior quantia possível, inferior ao valor requisitado.
3. O Cliente seleciona uma quantia a ser sacada;
4. O fluxo de eventos continua no próximo passo.

5.     Pós-Condições

Ø  O ATM devolveu o cartão e liberou o dinheiro para o Cliente e o saque foi registrado na conta corrente do Cliente;

Ø  O ATM devolveu o cartão e liberou o dinheiro para o Cliente e nenhum saque foi registrado na conta corrente do Cliente;

Ø  O ATM devolveu o cartão, mas não liberou a quantidade registrada como saque na conta corrente do Cliente. A discrepância foi registrada no log do ATM;

Ø  O ATM ficou com o cartão, nenhum saque foi registrado na conta corrente do Cliente e o Cliente foi informado sobre onde poderá obter maiores informações.

6.     Pontos de Extensão Públicos

Nenhum

7.     Requisitos Especiais

9.1 Liberação de Dinheiro Confiável

O ATM deve liberar a quantia correta solicitada, em pelo menos 99% das operações de saque.