Vous êtes sur la page 1sur 84

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:
Obrigado pela
atenção de todos(as).

Contato
@ valentino.junior@bilac.com.br