Diagrama de Caso e de Uso

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
*
Modelagem de Sistemas
Prof. Valentino D´Ambrosi Jr.
Seção 5
*
*
Nossas aulas
Seção 1 - 29/01/2015
Seção 2 - 05/02/2015 	
Seção 3 - 12/02/2015 – ED1
Seção 4 - 19/02/2015 - N1
Seção 5 - 26/02/2015
Seção 6 - 05/03/2015 – ED2
Seção 7 - 10/03/2015 
Seção 8 – 12/03/2015 – N2
Seção 9 - 17/03/2015 – ED3
Seção 10 - 26/03/2015 – U2
*
*
DIAGRAMA DE CASOS DE USO
*
*
Introdução
Modelagem de casos de uso foi uma técnica idealizada por Ivar Jacobson.
Técnica criada na década de 70 durante o desenvolvimento de um sistema para a Ericsson.
Em 1992 Jacobson incorporou a técnica a um desenvolvimento de software chamado de Objectory.
Depois junto com Booch e Rumbaugh, Jacobson incorporou a modelagem de casos de uso a UML.
*
*
Introdução
Modelo de casos de uso é muito popular e muito utilizado no processo de modelagem de um sistema.
Razão: possui notação simples e descrição em linguagem natural.
Facilita a comunicação entre a equipe de levantamento de requisitos e o cliente.
*
*
Introdução
Modelo de casos de uso representa todas as funcionalidades de um sistema.
Cada funcionalidade é um caso de uso.
Diagrama de Casos de Uso • é a ferramenta da UML utilizada na modelagem de casos de uso.
Força os desenvolvedores a modelarem o sistema de acordo com as necessidades do cliente.
*
*
Casos de Uso
É a especificação de uma sequência completa de interações entre um sistema e um ou mais agentes externos.
Um caso de uso representa um relato de uma certa funcionalidade do sistema.
Casos de uso não revelam a estrutura e o comportamento interno do sistema.
Modelo de caso de uso é um modelo que apresenta uma perspectiva externa.
*
*
Casos de Uso
Através de um MCU o usuário pode saber quais funcionalidades o sistema irá oferecer.
Usuário não sabe como o sistema age internamente para obter os resultados finais.
Um caso de uso não é um passo em uma funcionalidade e sim a descrição completa de uma funcionalidade.
Um modelo de caso de uso contém vários casos de uso.
*
*
Casos de Uso
Quanto mais complexo o sistema a ser desenvolvido maior a quantidade de casos de uso.
Notação de um caso de uso:
O nome de um caso de uso deve ser um verbo no infinitivo seguido de um substantivo.
*
*
Casos de Uso - Resumo
Um caso de uso representa uma determinada funcionalidade de um sistema conforme é percebida externamente. Representa também os agentes externos que interagem com o sistema. Um caso de uso, entretanto não revela a estrutura e o comportamento interno do sistema.
*
*
Caso de Uso - Descrição
A definição de um caso de uso se da pela descrição narrativa (textual) das interações entre o sistema e o agente externo.
UML não define uma estrutura a ser utilizada na descrição de um caso de uso.
Existem vários estilos de descrição propostos por diferentes autores.
A escolha do estilo fica a cargo da equipe de desenvolvimento ou do cliente.
*
*
Caso de Uso - Descrição
Uma descrição de caso de uso pode variar em 3 dimensões:
Formato
Grau de detalhamento
Grau de abstração
*
*
Descrição - Formato
É a estrutura utilizada para organizar a descrição.
Formatos existentes:
Contínuo
Numerado
Tabular
*
*
Descrição - Formato
Formato contínuo foi introduzido por Ivar Jacobson.
A descrição é feita através de texto livre.
Exemplo: Caso de Uso Realizar Saque
Este caso de uso inicia quando o Cliente chega ao caixa eletrônico e insere seu
cartão. O sistema requisita a senha do Cliente. Após o Cliente fornecer sua
senha e esta ser validada, o sistema exibe as opções de operações possíveis.
O Cliente opta por realizar um saque. Então o sistema requisita o total a ser
sacado. O Cliente fornece o valor da quantidade que deseja sacar. O sistema
fornece a quantia desejada e imprime o recibo para o Cliente. O Cliente retira a
quantia e o recibo, e o caso de uso termina.
*
*
Descrição - Formato
O formato numerado apresenta a descrição através de uma série de passos numerados.
Exemplo: Caso de Uso Realizar Saque
1. Cliente insere o cartão no caixa eletrônico.
2. Sistema apresenta solicitação de senha.
3. Cliente digita a senha.
4. Sistema valida a senha e exibe menu de operações disponíveis.
5. Cliente indica que deseja fazer um saque.
6. Sistema requisita a quantia a ser sacada.
7. Cliente fornece o valor que deseja sacar.
8. Sistema fornece a quantia desejada e imprime o recibo para o
cliente.
9. Cliente retira o recibo e a quantia, e o caso de uso termina.
*
*
Descrição - Formato
Estilo proposto por Rebeca Wirfs-Brock em 1991.
A sequência de interações entre ator e sistema é dividida em duas colunas.
Uma coluna apresenta as ações do ator e a outra as reações do sistema.
A leitura é feita em ziguezague.
*
*
Descrição - Formato
Exemplo: Caso de Uso Realizar Saque
*
*
Descrição - Formato
Importante: Descrição de casos de uso em formatos semelhantes a códigos-fontes não são aconselháveis já que a descrição é um artefato de comunicação com o cliente.
*
*
Descrição – Grau de Detalhamento
Grau de detalhamento pode variar do mais sucinto até a descrição com muitos detalhes.
Sucinto: descreve somente as interações entre atores e sistema.
Expandido: apresenta as interações entre atores e sistema e diversos detalhes.
*
*
Descrição – Grau de Abstração
Grau de abstração é mencionar ou não aspectos relativos à tecnologia na descrição de um caso de uso.
A descrição de um caso de uso pode ser real ou essencial.
A descrição essencial não exibe aspectos relativos à tecnologia utilizada nas interações.
*
*
Descrição – Grau de Abstração
A descrição essencial de um caso de uso pode utilizar qualquer um dos formatos mostrados anteriormente.
Descrição em um grau real se compromete com a solução do projeto.
Para identificar se deve utilizar o grau essencial ou real realizar a regra prática dos 100 anos.
*
*
Descrição - Formato
Exemplo: Caso de Uso Realizar Saque (Essencial)
1. Cliente fornece sua identificação.
2. Sistema identifica o usuário.
3. Sistema fornece opções disponíveis para movimentação da conta.
4. Cliente solicita o saque de determinada quantia.
5. Sistema requisita o valor a ser sacado.
6. Cliente fornece o valor que deseja sacar.
7. Sistema fornece a quantia desejada.
8. Cliente retira a quantia e o caso de uso termina.
*
*
Caso de Uso - Cenários
É a descrição de uma das maneiras pelas quais um caso de uso pode ser utilizado.
É a descrição de um episódio de utilização de alguma funcionalidade do sistema.
Instância de um caso de uso.
Para um mesmo caso de uso podem existir diversos cenários.
*
*
Caso de Uso - Cenários
Uso dos cenários:
Um conjunto de cenários para um caso de uso pode ser utilizado na fase de testes.
Pode ser utilizado também para esclarecer e entender melhor um caso de uso.
No processo de construção de um cenário podemos identificar novos detalhes ou até mesmo novos casos de uso.
Resumo = um cenário é uma utilização específica de um caso de uso pelo ator envolvido.
*
*
Caso de Uso - Cenários
Exemplo: Cenário para o Caso de Uso Comprar pela Internet
• O Cliente seleciona um conjunto de produtos do catálogo da loja.
• Após selecionar os produtos, o cliente indica o desejo de realizar o
pagamento por cartão de crédito.
• O sistema informa que o último pedido escolhido não tem no estoque.
• O cliente pede para que o sistema feche o pedido sem o item que está for
a de estoque.
• O sistema solicita os dados do cliente para realização do pagamento.
• O cliente fornece o número do cartão, a data de expiração e o endereço de
entrega do pedido.
• O sistema apresenta o valor total, a data de entrega e uma identificação do
pedido para rastreamento.
• O sistema também envia uma mensagem eletrônica para o cliente como
confirmação
do pedido de compra.
• O sistema envia os dados do pedido para o sistema de logística da
empresa.
*
*
Atores
Em UML Ator é qualquer elemento externo ao sistema que interage com o mesmo.
Atores não fazem parte do sistema.
Um ator interagir com o sistema é a mesma coisa que dizer que ele troca informações com o sistema.
Um ator pode enviar ou receber informações de um sistema.
*
*
Atores
Atores podem ser usuários, outros sistemas,etc.
Existem as seguintes categorias de atores:
Cargos: Empregado, Cliente, Gerente,Vendedor, Analista, etc.
Organizações ou divisões de uma organização: Empresa fornecedora, Agência de impostos, Administradora de cartões, etc.
Outros sistemas de softwares: Sistema de cobrança, Sistema de estoque de produtos, etc.
Equipamentos: Sensores, Leitora de códigode barras, etc.
*
*
Atores
Normalmente um ator inicia a sequência de interações de um caso de uso.
Possibilidade não muito comum é um evento interno ocorrer e disparar a sequência de interações do caso de uso.
Exemplo: o sistema notificar o usuário de que há novas mensagens de correio ou o sistema avisar o almoxarife de que um produto chegou no estoque mínimo.
*
*
Atores
Ator primário é aquele que inicia uma sequência de interações de um caso de uso.
Ator secundário é aquele que opera, supervisiona, mantém ou auxilia na utilização do sistema pelo ator primário.
Exemplo: Um programa de navegar pela internet (browser), para que um usuário (ator primário) requisite uma página, outro ator está envolvido que é o servidor Web (ator secundário).
*
*
Atores
Um ator pode participar de muitos casos de uso.
Um caso de uso pode ter a participação de vários atores.
Notação de Ator:
O nome de um ator deve remeter ao seu papel.
*
*
Relacionamentos
Função relacionar atores e casos de uso.
Pode existir relacionamentos entre atores e casos de uso, entre casos de uso e entre atores.
UML define os seguintes tipos de relacionamentos para os modelos de casos de uso:
Comunicação
Inclusão
Extensão
Generalização
*
*
Relacionamentos - Comunicação
É a relação entre atores e casos de uso.
É o tipo mais comum de relacionamento.
Quando um ator está relacionado com um caso de uso através de comunicação significa que o ator interage com o caso de uso através de troca de informações.
*
*
Relacionamentos - Comunicação
Exemplo:
Caso de uso Retirar Dinheiro
Ator Cliente
O relacionamento também pode ser representado com um segmento de seta, indicando o sentido das informações.
*
*
Relacionamentos - Inclusão
 Relacionamento que existe somente entre casos de uso.
 Quando dois ou mais casos de uso incluem uma mesma sequência de interações, essa sequência pode ser colocada em outro caso de uso.
 Assim vários casos de uso do sistema podem incluir o comportamento desse caso de uso.
*
*
Relacionamentos - Inclusão
Vantagens:
Evita a descrição de um mesmo caso de uso.
Torna a descrição de um caso de uso mais simples.
Torna a manutenção mais fácil.
*
*
Relacionamentos - Inclusão
Exemplo:
*
*
Relacionamentos - Extensão
Utilizado para modelar situações em que diferentes sequências de interações podem ocorrer de forma eventual.
Comportamentos que só ocorrem sob certas condições ou que dependem da escolha do ator.
O caso de uso extensor não é realizado toda vez que o caso de uso extendido for realizado.
*
*
Relacionamentos - Extensão
Exemplo:
*
*
Relacionamentos - Generalização
Pode existir entre casos de uso ou entre atores.
Permite que um caso de uso herde características de outro caso de uso (o mesmo vale para atores).
 A é o caso de uso “mãe” e B é o caso de uso “filho”.
O comportamento de A vale para B.
*
*
Relacionamentos - Generalização
B pode definir novos comportamentos além dos herdados de A.
Todo ator que realizar o caso de uso A pode realizar o caso de uso B também.
O contrário não é verdade.
Entre atores significa que o ator herdeiro possui o mesmo comportamento que o ator do qual ele herda.
*
*
Relacionamentos - Generalização
Exemplo: Generalização entre casos de uso
*
*
Relacionamentos - Generalização
Exemplo: Generalização entre atores - Biblioteca
*
*
Relacionamentos - Resumo
Quando utilizar cada tipo de relacionamento:
 Inclusão quando um mesmo comportamento se repetir em mais de um caso de uso.
Extensão quando um comportamento eventual de um caso de uso tiver de ser descrito.
Generalização entre casos de uso quando for identificado dois ou mais casos de uso com comportamentos semelhantes.
Generalização entre atores quando precisar definir um ator que desempenhe um papel que já é desempenhado por outro ator.
*
*
Relacionamentos - Resumo
Possibilidades de relacionamentos entre os elementos do modelo de casos de uso:
*
*
Diagrama de Casos de Uso
Diagrama que representa graficamente atores, casos de uso e seus relacionamentos.
Objetivo ilustrar em um nível alto de abstração quais elementos externos interagem com quais funcionalidades do sistema.
Largamente utilizado na comunicação com o cliente.
*
*
Diagrama de Casos de Uso
Exemplo 1:
*
*
Diagrama de Casos de Uso
Pode-se representar a fronteira do sistema em um diagrama de caso de uso.
A fronteira é representada por um retângulo.
Os atores ficam fora da linha da fronteira.
*
*
Diagrama de Casos de Uso
Exemplo 2:
*
*
Diagrama de Casos de Uso
Exemplo 3:
*
*
Diagrama de Casos de Uso
Exemplo 4:
*
*
Modelagem
Primeiro passo: identificar os atores
Segundo passo: identificar os casos de uso
Casos de uso primários
Casos de uso secundários
*
*
Modelagem - Atores
Identificar as fontes de informações a serem processadas.
Identificar o destino das informações geradas pelo sistema.
Identificar as áreas que serão afetadas ou que vão utilizar o sistema a ser desenvolvido.
*
*
Modelagem - Atores
Perguntas para identificação dos atores:
Quais órgãos, empresas ou pessoas vão utilizar o sistema?
Quais sistemas ou equipamentos irão se comunicar com o sistema a ser construído?
Alguém deve ser informado de alguma ocorrência no sistema?
Quem está interessado em certo requisito funcional do sistema?
*
*
Modelagem – Casos de Uso
Em um diagrama de casos de uso temos casos de uso primários e secundários.
Casos de Uso Primários representam objetivos dos atores.
Representam processos do sistema que serão automatizados.
*
*
Modelagem – Casos de Uso
Perguntas para identificar casos de uso:
Quais são as necessidades e os 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 um ou mais casos de uso para atendê-lo?
*
*
Modelagem – Casos de Uso
Outra técnica para identificação dos casos de uso é considerar algumas situações:
Caso de Uso Oposto é aquele cuja realização desfaz o resultado da realização de outro caso de uso.
Devemos, para todo caso de uso, perguntar se as ações realizadas pelo caso de uso podem ser desfeitas?
Se a resposta for SIM, teremos um caso de uso cancelar para cada um desses casos de uso.
*
*
Modelagem – Casos de Uso
Caso de Uso que Precede Outro Caso de Uso é aquele caso de uso que seu conjunto de interações devem ser realizadas antes de outro caso de uso.
Devemos perguntar, para todo caso de uso, o que pode ocorrer antes da realização deste caso de uso?
A resposta, se houver, será um novo caso de uso.
*
*
Modelagem – Casos de Uso
Caso de Uso que Sucede outro Caso de Uso é o caso de uso formado pelo conjunto de interações que foram consequência da execução de um outro caso de uso.
Para todo caso de uso devemos perguntar o que pode acontecer após a execução deste
caso de uso?
A resposta, se houver, será um novo caso de uso.
*
*
Modelagem – Casos de Uso
Caso de Uso Temporal São aqueles que representam funcionalidades que não são iniciadas por um ator. Exemplo: tarefas que são realizadas de tempo em tempo.
Devemos perguntar se existe alguma tarefa que o sistema deve executar automaticamente?
Se a resposta for SIM, então temos um novo caso de uso.
*
*
Modelagem – Casos de Uso
Caso de Uso Relacionado a Alguma Condição Interna Não é um ator que dispara o caso de uso e sim um evento interno. Exemplo: sistema notifica o usuário que há novas mensagens de correio.
Devemos perguntar se existe alguma funcionalidade no sistema que é disparada por algum evento interno.
Se a resposta for SIM, teremos um caso de uso pertencente a esta situação.
*
*
Modelagem – Casos de Uso
Casos de Uso Secundários não trazem benefícios diretos aos atores.
Não representam o objetivo principal do sistema a ser modelado.
O objetivo principal de um sistema é produzir algo de valor para o ambiente onde ele será implantado.
*
*
Modelagem – Casos de Uso
Casos de Uso Secundários podem ser divididos em 3 categorias:
Manutenção de Cadastros São os casos de uso para gerenciar toda a parte de cadastros do sistema.
Podemos ter apenas um caso de uso Cadastrar ou ele pode estar dividido em incluir, excluir e alterar.
Dividimos este caso de uso em vários quando ele é realizado por diferentes atores.
*
*
Modelagem – Casos de Uso
Manutenção de Usuários e Perfis - Casos de uso adicionar usuários, gerenciar direitos de acesso, configurar perfis de usuários, etc.
Manutenção de Informações Provenientes de Outros Sistemas - Casos de uso em que o sistema deve ser capaz de se cominucar com outros sistemas.
*
*
Modelo de Caso de Uso - MCU
Um MCU é composto por duas partes: gráfica e textual.
Parte gráfica = diagrama de casos de uso
Parte textual = documentação dos atores e casos de uso.
*
*
Modelagem – Diagrama de Caso de Uso
Diagrama de Caso de Uso ou DCU
DCU deve ser fácil de ler
DCU deve ser claro
Sistemas complexos torna-se difícil manter a clareza no DCU.
*
*
Modelagem – Diagrama de Caso de Uso
Em situações de sistemas complexos o modelador pode dividir os casos de uso em grupos menores.
Os casos de uso de um grupo menor tem que ser relacionados.
O modelador cria vários diagramas de casos de uso.
*
*
Modelagem – Diagrama de Caso de Uso
Critérios que podem ser adotados para subdividir os casos de uso em diversos diagramas:
Diagrama que exibe um caso de uso e todos os seus relacionamentos.
Diagrama que exibe todos os casos de uso para um determinado ator.
Diagrama que exibe todos os casos de uso a serem implementados em uma determinada versão do produto.
Diagrama que exibe todos os casos de uso de uma divisão específica da organização.
*
*
Modelagem – Diagrama de Caso de Uso
No caso de subdividirmos os casos de uso em diagramas, criamos um diagrama de casos de uso geral, que exibe os grupos de casos de uso.
Nesse diagrama de casos de uso geral podemos utilizar pacotes também.
*
*
Modelagem – Diagrama de Caso de Uso
Exemplo com pacotes:
*
*
Modelagem – Diagrama de Caso de Uso
Exemplo com casos de uso:
*
*
Exercício
Uma loja de CDs possui discos para venda e locação. Um cliente pode comprar ou locar uma quantidade ilimitada de discos.
Para locar é obrigatório que o cliente esteja cadastrado na loja, ou seja, tenha preenchido uma ficha de cadastro que deve ser renovada a cada 6 meses. As vendas de CDs podem ser efetuadas a vista com 10% de desconto, ou sem desconto através de cheque pré-datado, descontado 30 dias após a compra.
As locações só podem ser pagas a vista, no ato da devolução dos discos, que tem que acontecer 2 dias após a locação.
O valor da locação de cada disco é 1 real. A loja possui um funcionário cuja função é atender os clientes durante a venda e locação dos discos. Suas principais tarefas são: receber e conferir o pagamento efetuado pelos clientes; emitir recibo de venda e locação; anotar em uma caderneta o valor de cada venda, assim como também o nome do disco vendido; conferir o estado dos CDs devolvidos (caixa, disco, encarte).
*
*
Documentação de Atores
Breve descrição para cada um dos atores.
Não é um recurso obrigatório.
A equipe de desenvolvimento e modelagem deve definir se é relevante para o escopo do projeto.
*
*
Documentação de Casos de Uso
São oferecidos diversos itens para documentação dos casos de uso.
Somente alguns são obrigatórios.
A equipe de modelagem • deve definir quais serão utilizados.
Os itens adotados devem estar presentes na documentação de todos os casos de uso.
*
*
Documentação de Casos de Uso
Itens existentes e que podem ser utilizados:
Nome: nome do caso de uso, deve ser exatamente o mesmo nome presente no DCU. Este campo é obrigatório.
Identificador: código único para cada caso de uso e que pode ser utilizado para fazer referência cruzada (citar um caso de uso em outro caso de uso).
*
*
Documentação de Casos de Uso
Itens existentes e que podem ser utilizados:
Importância: define o grau de urgência que um caso de uso deve ser implementado.
Risco alto e prioridade alta são criticos e devem ser implementados primeiro.
Risco alto e prioridade baixa são críticos e possuem baixa prioridade na hora da implementação.
Risco baixo e prioridade alta Não são criticos, mas possuem muita prioridade na implementação.
Risco baixo e prioridade baixa Quando o projeto está atrasado são os primeiros a serem cortados.
*
*
Documentação de Casos de Uso
Itens existentes e que podem ser utilizados:
Sumário: breve descrição do objetivo do ator ao utilizar o caso de uso.
Ator Primário: nome do ator que inicia o caso de uso. No caso de um caso de uso que não é iniciado por um ator, colocamos o nome do ator que recebe o resultado do caso de uso.
*
*
Documentação de Casos de Uso
Itens existentes e que podem ser utilizados:
Atores Secundários: nome dos outros atores que estão relacionados com o caso de uso.
Atores: Nome de todos os atores que estão relacionados com o caso de uso.
Precondição: descrever as condições que devem ser verdadeiras (se existirem) para um caso de uso poder ser executado.
*
*
Documentação de Casos de Uso
Itens existentes e que podem ser utilizados:
Fluxo Principal: descreve de forma livre o fluxo principal de um caso de uso. Descrição do que ocorre normalmente em um caso de uso. Deve descrever o problema e não a solução. Este item é obrigatório.
Fluxo Alternativo: deve descrever o que acontece quando o ator opta por utilizar o caso de uso de uma forma alternativa (mas não errada). É um fluxo que substitui o fluxo principal.
*
*
Documentação de Casos de Uso
Itens existentes e que podem ser utilizados:
Fluxo Principal: descreve de forma livre o fluxo principal de um caso de uso. Descrição do que ocorre normalmente em um caso de uso. Deve descrever o problema e não a solução. Este item é obrigatório.
Fluxo Alternativo: deve descrever o que acontece quando o ator opta por utilizar o caso de uso de uma forma alternativa (mas não errada). É um fluxo que substitui o fluxo principal.
*
*
Documentação de Casos de Uso
Itens existentes e que podem ser utilizados:
Fluxo de Exceção: deve descrever o que acontece quando o ator opta por utilizar o caso de uso de uma forma errada. Deve indicar em que passo o caso de uso retorna ou se este é encerrado.
Pós-condições: descreve o estado que o sistema chega após o caso de uso ter sido executado.
*
*
Documentação de Casos de Uso-Modelo
<Nome do Caso de Uso>
Sumário: <breve descrição>
Atores: <nomes dos atores envolvidos>
Précondições: <condições que devem ser verificadas para
o caso de uso ter inicio>
Fluxo Principal: <descrição dos passos normais do caso
de uso>
Fluxos Alternativos: <descrição do uso laternativo do
caso de uso>
Fluxo de Exceção: <descrição do resultado do uso errado
do caso de uso>
*
*
Exemplo
Visualizar avaliações e Frequências
Sumário: Aluno visualiza avaliação que recebeu (notas e frequências) nas turmas de um semestre letivo.
Atores: Aluno
Précondições: O aluno está identificado pelo sistema.
Fluxo Principal:
1. O Aluno solicita a visualização das avaliações para as ofertas de disciplina em que participou.
2. O sistema exibe os semestres letivos nos quais o aluno se inscreveu em pelo menos uma oferta de disciplina.
3. O aluno seleciona os semestres letivos cujas avaliações deseja visualizar.
4. O sistema exibe uma lista de avaliações agrupadas por semestres letivos selecionados e por turma.
5. O aluno visualiza as avaliações e o caso de uso termina.
Fluxo de Exceção (2): Aluno sem inscrição em disciplinas.
a. Não há semestre letivo no qual o aluno tenha participado de alguma oferta de disciplina. O sistema reporta o fato para o aluno e o caso de uso termina.
*
*
Documentação de Casos de Uso
Seguindo o modelo de documentação de caso de uso apresentado faça a documentação para o seguinte caso de uso:
*
*
Contato
valentino.junior@bilac.com.br	
Obrigado pela 
atenção de todos(as).
@
*
*
*
*
*
*
*
*