Diagrama de Caso de Uso

Diagrama de Caso de Uso

O ponto de partida é saber quem ou o que interage dentro da aplicação a ser construída. Não deve considerar o comportamento interno do sistema. Deve prever todas as operações que vier a disponibilizar.

Caso de Uso é utilizado para identificar as regras de negócio e servem para entender o ponto de vista do usuário. São aplicados para capturar os requisitos solicitados pelo cliente.

Um Diagrama de Caso de Uso não deve ter todos os detalhes de implementação. Representa uma função, manipulada por uma entidade do sistema: o Ator. Não devem ser utilizados para realizar a decomposição funcional do sistema. O importante é o objetivo do ator.

Passos:

·        Definir o sistema e entendimento macro de seus objetivos;

·        Identificar os atores: identificar quais as fontes de informações a serem processadas e quais são os destinos das informações geradas pelo sistema.

·        Identificar ações das quais o ator participaria, ou seja, identificar os Casos de Uso. Representam os objetivos dos atores.

·        Agrupar tais ações, de forma que tenha um nome em comum representativo.

·        Detalhar várias situações de funcionalidade para os casos de uso.

·        Checar o modelo com usuários e clientes.

Quando mais de um ator participa de uma parte do Caso de Uso, então deve-se desmembrá-lo.

Cada Caso de Uso deve ser definido através da descrição narrativa das interações entre os atores e o sistema. Pode ser descrição contínua, descrição numerada e descrição particionada. Pode ou não mencionar a tecnologia a ser utilizada.

Atores podem dar origem a classes, sendo assim, podem ter os mesmos relacionamentos existentes entre elas. Nos diagramas de casos de uso, usa-se apenas a generalização para descrever um comportamento comum entre os atores.

Um caso de uso deve ser analisado sob a ótica de vários cenários, o que permitirá avaliar sua completude de funcionalidade. As atividades realizadas pelas pessoas são o foco dos cenários a serem criados, possibilitando uma perspectiva ampla quanto aos problemas atuais.

Um caso de uso é uma atividade composta por uma sequência de ações que o sistema executa, revela um padrão de comportamento, acionado por um ator ou outro caso de uso e produz um resultado que contribui para os objetivos do sistema.

·        Um caso de uso modela a interação entre os atores e o sistema, ou mesmo entre casos de uso.

·        Um caso de uso é ativado por um ator ou por um outro caso de uso para acionar uma certa função do sistema.

·        Um caso de uso é um fluxo de eventos completo e consistente.

·        Todos os casos de uso juntos representam todas as situações possíveis de utilização do sistema e mostram a funcionalidade existente disponível neste.

Para identificá-los, pode-se seguir o seguinte roteiro:

·        O software precisa ter quais funções para satisfazer as necessidades de um ator? O que o ator precisa fazer?

·        Um ator precisará ter acesso  ou informar dados ao software? O ator precisa ser notificado sobre os eventos no sistema ou é o ator quem precisa notificar o sistema sobre algo?

·        É possível simplificar ou melhorar o trabalho do ator mediante a inclusão de novas funções ao sistema, principalmente funções não automatizadas?

Para identificar atores ainda não conhecidos, pode-se utilizar as seguintes questões:

·        De que entradas ou saídas o sistema precisa? De onde elas vêm e para onde vão?

·        Quais são os principais problemas com a implementação já existente do sistema?

Para que um diagrama de caso de uso seja rigorosamente avaliado, emprega-se o conceito de cenário. As atividades realizadas pelas pessoas são o foco dos cenários a serem criados, uma vez que tal procedimento possibilita uma perspectiva ampla quanto a visualização dos problemas atuais do domínio descrito.

Identificando os casos de uso:

Casos de Uso Primários: São aqueles que representam os objetivos dos atores. Para identificá-los deve-se responder às seguintes questões:

·        Quais são as necessidades e objetivos de cada ator em relação ao sistema?

·        Que informações o sistema deve produzir?

·        O sistema deve realizar alguma ação que ocorre regularmente no tempo?

·        Para cada requisito funcional, existe pelo menos um caso de uso para atendê-lo?

Outras técnicas de identificação possíveis:

·        Caso de uso oposto : é aquele que desfaz o resultado da realização de um outro caso de uso. Exemplo: Cancelar Reserva.

·        Caso de uso que precede outro caso de uso: responde a pergunta “O que pode ocorrer antes da realização deste caso de uso?” Exemplo: Só pode ser feito o registro do pagamento, depois que for feito o registro de saída (Hotel).

·        Caso de uso que sucede a outro caso de uso: estratégia de identificação é pensar nas conseqüências da realização de um caso de uso. Ex.: Registrada a saída do hotel, deve ser feito o registro do pagamento.

·        Caso de uso temporal: pode haver funcionalidades realizadas pelo sistema que não são iniciadas por um ator.  Responde a pergunta:” Há alguma tarefa que o sistema deva realizar automaticamente?” Ex.: O sistema deve gerar um relatório mensal de ocupação dos quartos.

·        Caso de uso relacionado a alguma condição interna: também não tem um ator diretamente ligado a ela. Nesta situação, o sistema deve realizar alguma funcionalidade de acordo com a ocorrência de algum evento interno. Ex.: O sistema deve notificar o usuário quando tiver promoção para o período da reserva.

Casos de uso secundários: Não trazem benefícios diretos para os atores, mas são necessários para o funcionamento adequado do sistema.

·        Manutenção de cadastros: Ex.: cadastro de clientes.

·        Manutenção de usuário: adição de novos usuários, atribuição de direitos de acesso, configuração de perfis de usuário, etc.

·        Manutenção de informações provenientes de outros sistemas: no caso de comunicação entre sistemas. Ex.: Para registrar o consumo do cliente no hotel, comunica-se com o sistema do restaurante.

Extensões e Mecanismos

São complementos utilizados em diagramas de UML para dar mais clareza ao modelo.

Estereótipos: Podem ser utilizados para indicar um comportamento que se espera de um determinado componente. Ex.: <<uses>>, <<extends>>,<<abstracts>>. Os estereótipos definidos pela equipe devem ser documentados de maneira que a semântica seja bem entendida e possa ser utilizado em toda a modelagem.

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

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

Relacionamentos

Relacionamento de Comunicação:

Representa a associação de um ator a um Caso de Uso, a interação do ator com o sistema.

Relacionamento de Inclusão: A interação entre vários Casos de Uso e um Caso de Uso que seja comum a todos eles pode ser feita através de um relacionamento de inclusão.

Relacionamento de extensão: É utilizado para modelar um Caso de Uso que representa um comportamento opcional, que só ocorre sob certas condições ou que depende da escolha de um ator.

Relacionamento de generalizações:

·        Generalização entre Casos de Uso

Usado quando se identifica dois Caso de Uso com comportamento semelhantes e um deles for uma forma especial de outro.

·        Generalização entre atores

Usado quando se precisa definir um ator que possui o mesmo comportamento de um ator preexistente, só que com algumas características especiais.

Relacionamentos entre os elementos do modelo de Caso de Uso 

	Comunicação	Extensão	Inclusão	Herança
Caso de Uso e Caso de Uso		X	X	X
Ator e Ator				X
Caso de Uso e Ator	X

Construção do Modelo de Caso de Uso

O modelo de Caso de Uso é composto  do diagrama de Caso de Uso, da documentação dos atores e da documentação dos Casos de Uso.

 

Construção do Diagrama

Procedimentos a serem seguidos na construção de Casos de Uso em um processo de desenvolvimento incremental:

1.     Identifique os atores e Caso de Uso na fase de concepção.

2.     Na fase de elaboração:

§  Desenhe os diagramas de Caso de Uso;

§  Escreva os Casos de Uso em um formato de alto nível e essencial;

§  Ordene a lista de Casos de Uso de acordo com prioridade e risco.

3.     Associe cada grupo de Casos de Uso a uma Interação da fase de construção.

4.     Em cada Interação, detalhe os Casos de Uso do grupo associado a ela, e os implemente.

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.