wiki

ESOF - Aula 26 - 2015/2


Introdução


  • Diagrama de caso de uso é uma ferramenta regimentada pelas normas da UML. Basicamente A linguagem regulamenta uma série de diagramas que vem para facilitar a criação do modelo do projeto, problema inerente das soluções criadas sob o paradigma de orientação ao objeto.
  • Basicamente é um diagrama simples que mostra o sistema pelos olhos do usuário.
  • Dada a sua simplicidade é excelente para intermediar a comunicação entre o projetista do sistema e as demais pessoas que deverão entender o projeto.


  • É importante ressaltar que todos os diagramas são ferramentas para auxiliar na criação de um bom projeto.
  • Quem trabalha ou pelo menos se aventurou em programação sabe que muitos erros de projeto poderiam ser evitados se fosse obedecido o procedimento descrito tanto aqui quanto em toda a normatização UML.
  • Tarefa essa que não é fácil uma vez que normalmente se começa um projeto pela parte que deveria ser a última, a codificação.



Constituição


  • Para que o diagrama cumpra seu propósito de facilitar a comunicação entre diferentes níveis de conhecimento técnico, nada mais justo de ele ter uma estrutura relativamente simples. Há neste tipo de diagrama, alguns elementos básicos, a saber:


  • Ator :

Representa um usuário do sistema. Pode ser uma pessoa, um equipamento ou um outro sistema, desde que esteja fora do sistema em análise.
É mandatório que um ator seja relacionado com componentes , classes ou casos de uso
Salvo a exceção de herança entre atores.


  • Caso de uso :

Nada mais do que a representação de um método vinculado a uma classe.
Trata-se exclusivamente de uma representação de uma ação pretendida, ou uma função executada pelo sistema, como imprimir boleto, executar ação, salvar.
O Diagrama de Casos de Uso mostra o aspecto visual e exige que seja feito um detalhamento a parte dos procedimentos e parämetros de cada caso.

Documentação de Casos de Uso

  • A documentação do caso de uso descreve, de maneira tão simples quando o próprio diagrama, o sistema em questão. Ele detalha:
    • O que cada função faz
    • Como os atores interagem com o os casos
    • Os parâmetros que devem ser fornecidos aos casos
    • Suas restrições e validações.
  • Tem por característica ser um documento de formato flexível por não possuir uma definição fixada pela normatização UML.
  • Essa característica auxilia muito pois o designer pode faze-la da maneira que achar mais adequada para o projeto, podendo até mesmo conter pseudocódigos(portugol, ou o próprio algorítimo do código).
  • A principal necessidade que a documentação deve atender é que ela deve ser escrita em uma linguagem tão simples que tanto o programador quanto o cliente (leia-se leigo em programação) possam interpretar de forma clara.


Diagrama de Casos de Uso



Ator

  • Um ator representa uma entidade (um humano, um dispositivo de hardware ou mesmo outro sistema) que interage com um sistema
  • Por interação entende-se a troca de mensagens entre um ator e o sistema
  • Atores estão fora do sistema, isto é, não são entidades componentes do sistema
  • Atores podem ser conectados aos casos de uso somente por associações
  • Uma associação entre um caso de uso e um ator significa um canal de comunicação entre ambos, onde cada um pode enviar ou receber mensagens, estabelecendo uma interação



Representação





  • O seguinte questionário pode ser usado para identificar os atores do sistema:
  1. Quem usará as funções principais do sistema?
  2. Quem precisará do sistema para executar suas tarefas diárias?
  3. Quem manterá e administrará o sistema?
  4. Quais os equipamentos que o sistema controlará?
  5. Com quais outros sistemas o sistema precisará interagir?
  6. Quem tem interesse nos resultados que o sistema produz?


  • Exemplos:


Generalização de atores



  • Atores em um sistema





  • Caso de Uso



  • Descreve uma seqüência de ações - incluindo suas variantes - que o sistema deve executar com o objetivo de produzir como resultado algo de valor para o atendimento das necessidades de um ator



  • Um caso de uso:
    • Deve ser iniciado por um ator, embora haja exceções
    • Descreve uma funcionalidade completa do sistema conforme percebida por um ator
    • Gera como resultado algo de valor tangível para um ator (usuário)
    • Expressam os requisitos do sistema



  • Nome:
    • Um caso de uso deve ter como nome uma frase representando uma ação (comportamento) significativa para o vocabulário do sistema em processo de modelagem



  • Representação:




Especificando casos de uso



  • Nomeando casos de uso:
    • Enfatize que um caso de uso é um processo: nomeie-o iniciando por um verbo.



  • Descrição:
    • A especificação de um caso de uso pode ser feita através da descrição de seqüências de eventos em formato de texto
    • Descreve como o ator e o caso de uso interagem
    • Concentra-se no comportamento externo do sistema, ignorando os procedimentos a serem executados internamente pelo mesmo através de sua implementação.



  • Deve ser considerado:
    • como e quando o caso de uso inicia e termina
    • quando o caso de uso interage com um ator envolvido
    • a seqüência padrão
    • as seqüências alternativas ou de exceção.


Detalhamento


  • A especificação inclui:
Detalhamento do caso de uso
Identificação do Caso de Uso: Permite fazer referencia a outros documentos relacionados com o modelo de caso de uso. Ex: CS01
Nome do Caso de Uso Nome que aparece no diagrama de caso de uso
Sumário Pequena descrição do caso de uso.
Ator Nome do ator que inicia o caso de uso.
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 ser identificado no sistema"
Pós-condições Estado que o sistema alcança após o caso de uso ter sido realizado.
Seqüência de Eventos Corresponde a sequencia de passos para o fluxo principal, descrevendo o que normalmente acontece quando o caso de uso é realizado.
Ações Numeradas a partir de 1 Coluna Esquerda: ator <----> Coluna da direita: Sistema
Seqüências Alternativas Descreve oque acontece quando o ator faz uma escolha alternativa, diferente da descrita no fluxo principal, para alcançar seu objetivo ou quando algo de inesperado ocorre na interação entre o ator e o caso de uso.
Requisitos Não-Funcionais Situações externas ao sistema que darão suporte à aplicação ou definem métricas de execução



  • Exemplo:





Exemplo: 

Identificação do Caso de Uso: UC1
Nome do Caso de Uso: Sacar dinheiro no caixa eletrônico
Sumário: Este caso permite que o usuáro saque dinheiro no Caixa Eletrônico por meio do cartão magnético
Ator: Cliente
Pré-condições: Cliente possui acesso via cartão, senha atualizada e tem saldo positivo
Pós-condições: Efetuada a transação, é debitado o lançamento no saldo da conta do cliente, Dinheiro é liberado.

Seqüência de Eventos
'                              '


Ação do Ator Resposta do Sistema
1. Cliente insere o cartão do banco no Caixa Eletrônico 2. O sistema lê dados do cartão e valida e pede a senha e libera cartão
3. O Cliente digita a senha 4. O sistema valida a conta corrente e a senha do cliente, autorizando a operação e solicita valor
5. O Cliente digita o valor do saque 6. O sistema autoriza o saque e lança o débito no histórico da CC do Cliente
. 7. O sistema envia comando para o Cx de Cédulas liberar o dinheiro
8. Cx de Cédulas avalia saldo e entrega dinheiro . .
9.Cliente puxa as cédulas 10. O sistema atualiza o saldo do cliente


Seqüências Alternativas


2a. Cliente Inválido
Ação do Ator Ação do Sistema
. 1. O sistema não reconhece a conta corrente e senha do Cliente como válida e retorna msg de erro
, 2. A operação é cancelada


6a. Saldo insuficiente
Ação do Ator Ação do Sistema
. 1. O sistema pesquisa o saldo e verifica que é insuficiente
, 2. A operação é cancelada
2a. Cartão travado
Ação do Ator Ação do Sistema
. 1. A Máquina não consegue liberar o cartão
. 2. Sistema envia msg para Suporte
3. Suporte recebe msg e retorna prazo de atendimento 4. A msg de Suporte a caminho aparece na tela e a operação é cancelada


6a . Fundos Insuficientes
Ação do Ator Ação do Sistema
. 1. O sistema não autoriza o valor solicitado para saque pelo Cliente
. 2. A operação é cancelada


8a. Sem dinheiro
Ação do Ator Ação do Sistema
. 1. A Cx de Cédulas não tem dinheiro suficiente para o saque ou as notas não batem com solicitado. Retorma msg para o sistema
, 2. A operação é cancelada

Requisitos Não-Funcionais


  1. Resposta do sistema deve ocorrer em no máximo 30 seg em 90 % dos casos.
  2. Deve ser colocada uma câmera na parte superior da cabine
  3. O dispositivo de entrega de dinheiro deve conter tinta vermelha em caso de arrombamento e tem que ter sistema especial de abertura
  4. A comunicação do caixa com a Central deve ser feita em link dedicado com redundância
  5. A tela deve ser touchscreen com as seguintes características: Tela 19,5” touch, CPU SDDM MiniPC, ventoinhas e filtro de linha integrados. Frontal em poliestireno, para fácil decoração. Medida do frontal: 1,60 m (A) x 062,8 m (L). Gabinete: em Fibra de Vidro na cor padrão branco. Medidas: 1,60 m (A) x 0,60 m (L) x 0,50 m (C). Peso: 27 kilos. Processador: ATOM 1,8 Dual. Core D2500 . Sistema Operacional: Windows 7. Memória: 2GB . HD: SSD 30GB. Interface de Rede: 10/100/1000 Base-T. Portas Traseiras: 4 portas USB 2.0 | 1 conexão de rede | 1 Saída. Bivolt automático.
  6. O sistema operacional deve ser proprietário
  7. O padrão de letras deve ter tamanho suficiente para leitura visual crítica
  8. Quando o mecanismo entregar o dinheiro deverá enviar aviso para o sistema
  9. Especificações da máquina de cédulas: Contagem de 1.000 a 1.200 cédulas por minuto, Capacidade de até 200 cédulas, lotes programáveis: 5,10,20,50 e 100 cédulas ou unitário. Função ADD : Contagem acumulativa, certificação Européia. Dimensões: 300 x 240 x 200 MM. Alimentação: Bivolt automático. Consumo de força: 60W. Temperatura: 0º C a 40º C. Umidade: 40 - 90% / Peso: 7 Kg. Manual em Português incluso


Revisão do Caso de Uso


Após estas informações, o Diagrama de Casos de Uso continua o mesmo?


  • Inserindo 2 novos atores descobertos no passo-a-passo dos eventos>


  • Diagrama atualizado:


Descobrindo atores e casos de uso


  • Lista Ator-Objetivos



Ator               Objetivos
  • Cliente
    • Sacar dinheiro - Ok
    • Consultar Saldo
    • Fazer depósitos
    • Efetuar Transferências
    • Imprimir Extrato
    • Recarregar Pre-Pago
    • Realizar Pagamentos
    • Solicitar Cheques
    • Contratar Empréstimo
    • Desbloquear Internet Banking
    • Contratar Seguro
    • Mais casos?


  • Caixa de Cédulas
    • Liberar Dinheiro
    • Verificar Saldo de Cédulas
    • Comunicar com Central
    • Travar abertura
    • Mais casos?



  • Suporte:
    • Enviar Mensagem de Suporte


  • Diagrama envolvendo os novos casos:


  • Imprimir Extrato -> Impressora é um ator?
  • Recarregar Pre-Pago -> Operadora Telefönica é ator?
  • Realizar Pagamentos -> Empresa Cedente é ator?



Generalização expressa com modificações





Identificação do Caso de Uso: UC5
Nome do Caso de Uso: Receber pagamento
Ator: Caixa
Pré-condições: O Caixa é identificado e autenticado
Pós-condições:O pagamento recebido é registrado no sistema associado ao Caixa


Seqüência de Eventos
Ação do Ator Ação do Sistema
1. Este caso começa quando o Caixa registra o documento de cobrança a ser pago 2. O sistema valida a aceitação do documento de cobrança a ser pago
3. O Caixa informa a opção desejada
3.1. Se pagamento em dinheiro, ver subseção Receber pagamento em dinheiro
3.2. Se pagamento em cheque, ver subseção Receber pagamento em cheque
. 4. O sistema registra o pagamento
. 5. O sistema imprime o comprovante.


Subseção: Receber pagamento em dinheiro
Ação do Ator Ação do Sistema
1. O Caixa registra o valor em dinheiro recebido 2. Sistema informa troco a ser repassado ao cliente
Subseção: Receber pagamento em cheque
Ação do Ator Ação do Sistema
1. O Caixa recebe o cheque, verifica assinatura e o registra no sistema 2. O sistema valida os dados do cheque


Disponível em “http://3.143.69.156/wiki/index.php?title=ESOF_-_Aula_26_-_2015/2&oldid=39552”