Diagramas de Casos de Uso
Não diga pouco em muitas palavras,
mas sim, muito em poucas.
Pitágoras
Elaine
Casos de uso
• O modelo de casos de uso modela os requisitos
funcionais do sistema.
• É uma técnica de modelagem idealizada por Ivar
Jacobson, na década de 70.
• Mais tarde a notação de casos de uso foi
adicionada à UML.
• O diagrama da UML utilizado na modelagem de
casos de uso é o diagrama de casos de uso.
Elaine
Casos de Uso
• Um caso de uso descreve um conjunto de
funcionalidades do sistema modelando o diálogo
que ocorre entre algo que está fora do sistema,
uma entidade externa chamada de ator e o
sistema.
Elaine
Casos de Uso
• Um caso de uso especifica o comportamento de
um sistema ou parte dele.
• É uma descrição do conjunto de passos que o
sistema executará para desempenhar suas
funções
• Um caso de uso é baseado em um cenário que
descreve como o ator interage com o sistema.
Ele identifica eventos que podem ser solicitados
e descreve a resposta do sistema para esses
eventos
Elaine
Diagrama de Casos de Uso
• O diagrama de casos de uso representa todas as
formas de uso do sistema. Todas as
funcionalidades.
• Casos de uso fornecem uma visão do sistema
focada nas funcionalidade.
• Deixamos claro em que CASOS podemos
USAR o sistema.
Elaine
Diagrama de Casos de Uso
• Além das funcionalidades definimos como o
software interage com o usuário para prover esse
tipo de serviço.
• Podemos definir quem tem acesso ao que no
contexto do sistema.
Elaine
Diagrama de Casos de Uso
• Possibilitam um formato de apresentação
compreensível que pode ser utilizado para
aprimorar a comunicação, especialmente entre
os projetistas da aplicação e os clientes.
• Também são úteis para outras fases, ajudando na
quantificação, identificação de objetos e
desenvolvimento de estratégias de teste
(principalmente pelas descrições dos casos de
uso)
Elaine
Diagrama de Casos de Uso
• Objetivos:
–
–
–
–
–
–
–
–
Delimitação do contexto de um sistema
Documentação e o entendimento dos requisitos
Descrição dos requisitos funcionais
Principal saída da etapa de especificação de
requisitos
Principal entrada da etapa de análise
Facilitam a comunicação entre os stakeholders
São a base para a definição do cronograma
Auxiliam na elaboração dos casos de teste
Elaine
Casos de Uso
• Análise Tradicional
– O que o sistema deve fazer?
• Análise por Casos de Uso
– O que o sistema deve fazer ... E para quem?
Elaine
Atores
• São entidades do meio ambiente (externas ao
sistema) que interagem com o sistema para
solicitar algo ou informar algo.
• Atores podem dar inicio a eventos
ou interagir com o sistema em
decorrência do resultado de
eventos ocorridos.
Elaine
Atores
• Categorias de atores:
– Pessoas (Empregado, cliente, gerente, aluno,
professor);
– Organizações ( Empresa Fornecedora, Administradora
de cartões);
– Outros Sistemas ( Sistema de estoque, Sistema de
cobrança);
– Equipamentos (Leitora de cartões, Sensores, Alarmes);
Elaine
Atores
• Um ator corresponde a um papel representado
em relação ao sistema
– O mesmo indivíduo pode ser o cliente que efetua
compras na loja e pode ser o vendedor que processa
vendas;
– Uma pessoa pode representar o papel de Funcionário
de um banco, mas também pode ser Cliente do
banco.
• O nome dado a um ator deve lembrar o seu
papel.
Elaine
Atores
• Atores se comunicam com o sistema por muitas
razões, incluindo:
– Iniciar um caso de uso. Os casos de uso sempre são
iniciados por atores.
– Pedir alguns dados armazenados no sistema, os quais
então o caso do uso apresenta ao ator.
– Mudar os dados armazenados no sistema por meio de
um dialogo com o sistema.
– Informar que ocorreu algo que o sistema deve estar
ciente.
Elaine
Atores
• Um ator inicia um caso de uso. Entretanto,
depois que o caso de uso começou, ele pode se
comunicar com vários outros atores.
• Considera-se às vezes, erradamente, que a
associação de comunicação representa o fluxo de
dados. Não é isso. A associação de comunicação
representa um diálogo entre o ator e o sistema,
um tipo de canal de comunicação sobre o qual
podem fluir dados em ambas as direções durante
o diálogo.
Elaine
Casos de Uso
• Caso de uso é um requisito que
será automatizado. É usado
para representar as
funcionalidades de um sistema.
• Representa o que o sistema faz
(não como). O “como” está
associado à descrição do caso
de uso. À partir dessa
descrição partimos para as
atividades de projeto.
Elaine
Cadastrar
produto
Casos de Uso
• Casos de uso se comunicam com atores por
muitos motivos:
– Se algo especial aconteceu no sistema, um ator pode
ter de ser informado.
– Um caso de uso pode necessitar da ajuda de um ator
para tomar uma decisão.
– Um caso de uso pode delegar responsabilidade a um
ator.
Elaine
Conectando atores e casos de uso:
• Os atores e os casos de uso com os quais eles interagem
são ligados pela associação de comunicação.
• A seta é opcional, mas, quando usada, ela indica qual
elemento começa a interação.
• Para entender plenamente o papel definido para um
ator, você deve saber em que casos de uso o ator está
envolvido.
• Para entender plenamente o alcance de um caso de uso,
você deve saber os atores com os quais ele se comunica.
Elaine
Diagrama de Casos de Uso
Descrição de um
conjunto de passos
que é o
detalhamento do
caso de uso
Associação entre
ator e caso de uso
Elaine
Exemplo
• Cliente de banco pode usar um caixa automático
para:
– Sacar dinheiro
– Transferir dinheiro
– Consultar saldo
Elaine
Exemplo
Elaine
Relacionamentos
• Os relacionamentos que ocorrem com mais
freqüência quando trabalhamos com casos de
uso são:
– Extend
– Include
Elaine
Extensão
• É um tipo de relacionamento que só pode
ocorrer entre casos de uso. Não existe um
relacionamento de extensão entre um ator e um
caso de uso.
• Define uma extensão de um relacionamento para
um caso de uso a partir de outro caso de uso e
essa extensão é opcional, ou seja é um
comportamento que poderá ou não ser usado
pelo caso de uso de origem.
Elaine
Extensão
• Nesse relacionamento de extensão estou
definindo que ao acessar a funcionalidade
encerrar conta pode ser necessário ou não
sacar dinheiro (Se a conta tem saldo
positivo, vou sacar dinheiro) mas essa
funcionalidade não é obrigatória, caso a
conta tem saldo igual a zero não ocorrerá a
funcionalidade de sacar dinheiro.É opcional.
• De forma semelhante, ao acessar a funcionalidade encerrar conta
pode ser necessário ou não depositar dinheiro (Se a conta tem
saldo negativo vou depositar dinheiro) mas essa funcionalidade
não é obrigatória, caso a conta tem saldo positivo ou igual a zero
não ocorrerá a funcionalidade de depositar dinheiro.
Elaine
Extensão
• Pode ser usada para:
– Simplificar fluxos de eventos complexos
– Representar comportamentos opcionais
– Lidar com exceções
• Por exemplo, em uma descrição de um caso de
uso temos fluxos básicos e fluxos alternativos,
quando um fluxo alternativo é complexo e
opcional podemos modelá-lo como um caso de
uso, ligando-o ao caso de uso de origem por um
relacionamento de extensão.
Elaine
Extensão
• As seguintes situações podem dar margem à
utilização do extend:
– Descrições de características que são opcionais ao
comportamento básico do sistema, por exemplo,
características que podem ser adquiridas ou não.
– Descrições complexas de erros ou tratamentos de
exceções que, de outra forma, iriam obscurecer o
comportamento primário do sistema. Exemplos disso
são fluxos alternativos de tamanho significativo,
especialmente aqueles cujo tamanho é maior do que
o do fluxo principal.
Elaine
Extensão
• Mais situações que podem dar margem à
utilização do extend:
– Customização do modelo de requisitos para atender a
necessidades específicas do usuário. Exemplos disso
são fluxos alternativos que especificam como
usuários específicos tratam diferentes condições que
ocorrem dentro de um mesmo caso de uso.
– Gerência de escopo e versão. Um exemplo disso são
características que não serão introduzidas até as
últimas versões.
Elaine
Extensão
• Podemos concluir então que o relacionamento de
extensão me permite definir relações entre casos
de uso onde existe uma adição de
comportamentos opcionais ao caso de uso que
está sendo estendido.
Elaine
Inclusão
• Também é um tipo de relacionamento que só
pode ocorrer entre casos de uso. Não existe um
relacionamento de inclusão entre um ator e um
caso de uso.
• Defini a inclusão de comportamentos presentes
em outro caso de uso e essa inclusão será
obrigatória. Sempre irá utilizar essas
funcionalidades presentes no caso de uso
incluído ao caso de uso de origem
Elaine
Inclusão
• Identificar usuário é uma funcionalidade que poderia ser
interna de sacar dinheiro e de depositar dinheiro mas
sendo comum a vários casos de uso, é mais interessante
modelar identificar usuário em um caso de uso que
permita o reuso do mesmo.
• Assim, todos os casos de uso
que necessitem identificar
usuário de forma obrigatória é
ligado ao caso de uso
Identificar usuário através do
relacionamento de inclusão.
Elaine
Inclusão
• Pode ser usada para:
– Representar comportamentos reutilizáveis
– Simplificar fluxos de eventos complexos
Quando existe uma dada função dentro do sistema que
aparece em vários casos de uso, ou seja ela é utilizada
por várias funcionalidades, podemos modelar essa
função em um caso de uso uma única vez e ligá-la a
todos os casos de uso que incluem essa função comum,
dizendo que essa função é usada em diferentes partes do
meu software.
Elaine
Especialização
• Um caso de uso pode especializar outro caso de
uso:
– Adicionando o fluxo de eventos original
– Refinando o fluxo de eventos original
• Especialização permite modelar comportamento
diferenciado entre um caso de uso base e casos
de uso filhos.
• Pouco utilizado.
• Pode existir entre atores também
Elaine
Generalização de casos de uso
• Quando o usuário acessar a
funcionalidade consultar
saldo, essa funcionalidade
vai se dar de uma maneira
específica:
– ou consultar saldo na tela
– ou consultar saldo impresso.
Elaine
Relacionamentos
Relação
Função
Notação
Associação
O caminho de comunicação entre um ator e
o(s) caso(s) de uso em que participa
Inclusão
A inserção de um comportamento adicional
em um caso de uso base que explicitamente
descreve a inserção
Generalização
Um relacionamento entre um caso de uso
geral e um mais específico que herda e
adiciona propriedades à aquele
Extensão
A inserção de um comportamento adicional
em um caso de uso base que não sabe sobre
o comportamento adicional
Elaine
Sentido da seta
• Na inclusão partimos do caso de uso base para o
caso de uso que será incluído
Sacar
dinheiro
Elaine
<<include>>
Identificar
usuário
Sentido da seta
• Na extensão parte do caso de uso opcional para
o caso de uso base
Inscrever
Aluno
Secretária
Elaine
<<extend>>
Atualizar
cadastro
Regras
• Não existe ligação entre atores.
– Atores são entidades externas do sistema, portanto a
comunicação entre eles está fora do escopo do
sistema, não devendo ser modelada no diagrama de
caso de uso, um vez que ele modela apenas as
funcionalidades do sistema.
Elaine
Herança de Atores
• Alguns casos de uso são
utilizados por vários atores,
para simplificar o diagrama
e diminuir o número de
associações, cria-se um ator
genérico.
• Além disso alguns casos de
uso são exclusivos de apenas
um ou alguns atores, mas
não de todos.
• Generalização pode
simplificar a representação
gráfica do sistema.
Elaine
Sem Generalização x Com Generalização
Elaine
Exemplo
Elaine
Estudo de Caso
Locadora de Veículos
• O diagrama de caso de uso é criado com base em um
cenário descrito a partir da especificação de requisitos.
• Assim, vamos construir o diagrama de caso de uso para
a locadora de veículos descrita no cenário a seguir.
• É importante ressaltar que a partir de um conjunto de
requisitos definidos podemos ter diferentes diagramas
de casos de uso modelados pois estes diagramas
refletem a solução que cada analista dá para o
problema.
Elaine
Cenário – Locadora de Veículos
• Uma locadora de veículos deseja um sistema para
facilitar o atendimento a seus clientes.
• O processo de aluguel de carros atual é confuso e está
gerando insatisfação entre os clientes.
• A locadora é composta basicamente pelos seus
funcionários e carros para aluguel. Os funcionários
são identificados por cpf, nome, endereço, telefone. Já
os carros estão divididos em diversos tipos: popular,
luxo, utilitário, etc. As informações importantes sobre
os carros a serem armazenadas são: código (placa do
carro), tipo, modelo, ano, cor, chassis, km e valor do
aluguel (diárias e semanais).
Elaine
Cenário – Locadora de Veículos
• Os funcionários serão responsáveis pelo cadastro dos
clientes e dos carros adquiridos pela locadora, por
efetuar o aluguel de um carro para o cliente e dar
baixa no aluguel.
• Existem clientes especiais e clientes comuns. Os especiais
possuem uma taxa de desconto e um quilometragem extra
para seus aluguéis.
• Qualquer cliente é identificado por rg, nome, cpf,
telefone, endereço, cidade.
• Desta forma, o cliente poderá solicitar o aluguel de
carros a um funcionário da locadora.
Elaine
Funcionalidades do Sistema
• Alugar Carro: cliente deve solicitar ao funcionário o aluguel
do carro. O sistema verifica se o carro solicitado pelo cliente
está disponível. Caso esteja, o processo de locação é concluído e
o carro passa a estar indisponível. A data de aluguel deve ser
guardada para calculo do valor do aluguel na devolução.
• Dar Baixa: cliente faz devolução do carro para o
funcionário e solicita nota fiscal (recibo) com a
quilometragem percorrida e o valor do aluguel. O
funcionário coloca o status do carro novamente como
disponível, solicita ao sistema para calcular o valor a ser pago e
emite o recibo para o cliente.
• Cadastrar Cliente: cliente solicita ao funcionário que o cadastre
na locadora. O funcionário recebe os dados e cadastra-o.
• Cadastrar Carro: funcionário cadastra o carro adquirido.
Elaine
Funcionalidades do Sistema
• Na funcionalidade Alugar Carro temos descrito um
conjunto de passos que serão executados no contexto
desta funcionalidade. Essa descrição de passos servirá
para descrever o caso de uso e não gerar outros casos de
uso.
• Assim, solicitar aluguel, verificar disponibilidade do
carro, alterar disponibilidade etc não serão casos de uso,
mas passos que serão executados dentro do caso de uso
Alugar Carro.
• O mesmo ocorre para Dar baixa, Cadastrar Cliente e
Cadastrar Carro
Elaine
Solução - Locadora de Veículos
Elaine
Estudo de Caso II
• Sistema de reserva de passagem aérea
– Para esse estudo de caso trabalharemos com a lista
de requisitos definidos durante a engenharia de
requisitos.
– Importante deixar claro que nem todo requisito
listado será um caso de uso. Ele pode ser
simplesmente um passo interno de algum caso de uso
que represente uma funcionalidade mais abrangente.
Elaine
RF1
Sistema deve permitir o cadastro do usuário
RF2
Sistema deve permitir que o usuário se identifique
RF3
Sistema deve consultar a classe vôo
RF4
Sistema deve consultar o trecho da viagem
RF5
Sistema deve permitir consulta aos aeroportos
RF6
Sistema deve permitir consulta as datas disponíveis de ida e volta
RF7
Sistema deve permitir que usuário consulte as formas de pagamento
RF8
Sistema deve enviar para os usuários cadastrados e-mails promocionais
RF9
Sistema deve permitir que o usuário consulte CEP no sistema dos correios
RF10
Sistema deve permitir que o usuário solicite a reserva on-line
RF11
Sistema deve gerar código de reserva
RF12
Sistema deve emitir e-mail ao usuário confirmando a reserva com dados
RF13
Sistema deve permitir que usuário cancele a reserva
RF14
Sistema deve permitir que administrador emita relatório de reservas confirmadas
RF15
Sistema deve permitir que administrador emita relatório de reservas canceladas
RF16
Sistema deve validar o pagamento junto com a operadora de cartão
RF17
Sistema deve permitir que o administrador emita relatório de usuários cadastrados
RF18
Sistema deve permitir que usuário edite seus dados pessoais
Elaine
RF1
Sistema deve permitir o cadastro do usuário
RF2
Sistema deve permitir que o usuário se identifique
RF3
Sistema deve consultar a classe vôo
RF4
Sistema deve consultar o trecho da viagem
RF5
Sistema deve permitir consulta aos aeroportos
RF6
Sistema deve permitir consulta as datas disponíveis de ida e volta
RF7
Sistema deve permitir que usuário consulte as formas de pagamento
RF8
Sistema deve enviar para os usuários cadastrados e-mails promocionais
O RF1 será modelado como caso de uso.
Importante percebermos que os RF de 2 até o 7 são passos internos
da funcionalidade mais abrangente efetuar reserva, portanto eles
não se tornarão casos de uso. Essas funcionalidades farão parte da
descrição do caso de uso efetuar reserva.
O RF8 será um caso de uso, uma vez que representa uma
funcionalidade específica do sistema .
Elaine
RF1
Sistema deve permitir o cadastro do usuário
RF2
Sistema deve permitir que o usuário se identifique
RF3
Sistema deve consultar a classe vôo
RF4
Sistema deve consultar o trecho da viagem
RF5
Sistema deve permitir consulta aos aeroportos
RF6
Sistema deve permitir consulta as datas disponíveis de ida e volta
RF7
Sistema deve permitir que usuário consulte as formas de pagamento
RF8
Sistema deve enviar para os usuários cadastrados e-mails promocionais
RF9
Sistema deve permitir que o usuário consulte CEP no sistema dos correios
RF10
Sistema deve permitir que o usuário solicite a reserva on-line
RF11
Sistema deve gerar código de reserva
RF12
Sistema deve emitir e-mail ao usuário confirmando a reserva com dados
Os RFs 9, 11 e 12 também são passos internos da funcionalidade
mais abrangente efetuar reserva, portanto eles não se tornarão casos
de uso. Já o RF10 é exatamente a funcionalidade efetuar reserva,
que engloba todos estes outros RFs citados, assim ele será um caso
de uso.
Elaine
RF13
Sistema deve permitir que usuário cancele a reserva
RF14
Sistema deve permitir que administrador emita relatório de reservas confirmadas
RF15
Sistema deve permitir que administrador emita relatório de reservas canceladas
O RF 13 será modelado como um caso de uso, visto que cancelar
reserva é um ato a parte do sistema onde o usuário vai solicitar
cancelamento da reserva, o sistema exibe as reservas desse usuário
para que ele possa selecionar aquela que ele deseja cancelar.
O RF14 e o RF15 serão modelados como um caso de uso emitir
relatório de reservas, já que o que muda é apenas o status da
reserva que será incluída no relatório. Essa diferença pode ser
interna ao caso de uso, detalhada na descrição.
Elaine
RF16
Sistema deve validar o pagamento junto com a operadora de cartão
RF17
Sistema deve permitir que o administrador emita relatório de usuários cadastrados
RF18
Sistema deve permitir que usuário edite seus dados pessoais
O RF 16 também é um passo interno da funcionalidade mais
abrangente efetuar reserva, portanto não se tornará caso de uso.
O RF17 será caso de uso novo pois embora seja um relatório, este é
totalmente diferente dos outros (RF14 e RF15).
O RF18 será modelado como um caso de uso pois a edição dos
dados do usuário será desvinculada do efetuar cadastro. Para edição
ele tem que efetuar o login, abrir sua ficha cadastral já existente
para então fazer a alteração. São ação desvinculadas do ponto de
vista do usuário. Não estamos modelando um manter usuário nesse
sistema on-line.
Elaine
Casos de uso definidos
•
•
•
•
•
•
•
Cadastrar Usuário
Enviar e-mail promocional
Efetuar reserva
Cancelar reserva
Emitir relatório de reservas
Emitir relatório de usuários cadastrados
Atualizar dados pessoais.
Elaine
Definição de Atores
• Os RF14, RF15 e RF17 são efetuados pelo
administrador do sistema.
• Os RF2, 7, 8, 10, 12, 13 e 18 citam um ator usuário
• O RF9 diz que haverá interação com um sistema
externo (Sistema dos correios), como um sistema
externo que troca informação com o sistema é
considerado um ator, teremos o ator Sistema do
Correio.
• Da mesma forma que o RF16 cita interação com a
operadora de cartão, definindo assim o ator Operadora
de Cartão
Elaine
RF1
Sistema deve permitir o cadastro do usuário
RF2
Sistema deve permitir que o usuário se identifique
RF3
Sistema deve consultar a classe vôo
RF4
Sistema deve consultar o trecho da viagem
RF5
Sistema deve permitir consulta aos aeroportos
RF6
Sistema deve permitir consulta as datas disponíveis de ida e volta
RF7
Sistema deve permitir que usuário consulte as formas de pagamento
RF8
Sistema deve enviar para os usuários cadastrados e-mails promocionais
RF9
Sistema deve permitir que o usuário consulte CEP no sistema dos correios
RF10
Sistema deve permitir que o usuário solicite a reserva on-line
RF11
Sistema deve gerar código de reserva
RF12
Sistema deve emitir e-mail ao usuário confirmando a reserva com dados
RF13
Sistema deve permitir que usuário cancele a reserva
RF14
Sistema deve permitir que administrador emita relatório de reservas confirmadas
RF15
Sistema deve permitir que administrador emita relatório de reservas canceladas
RF16
Sistema deve validar o pagamento junto com a operadora de cartão
RF17
Sistema deve permitir que o administrador emita relatório de usuários cadastrados
RF18
Sistema deve permitir que usuário edite seus dados pessoais
Elaine
Funcionalidades do Administrador
Elaine
Funcionalidades do Usuário
• Podemos perceber que o
usuário (internauta) pode
se cadastrar mas que para
Efetuar reserva, Cancelar
reserva e Atualizar dados
pessoais, ele tem que ser
um usuário logado, ou
seja um tipo especial de
usuário que vamos
chamar de cliente.
Elaine
Ator Correio
• O sistema de correios é consultado durante o
cadastro do usuário, para consultar o CEP, assim
esse ator está ligado ao caso de uso Cadastrar
usuário
Elaine
Ator Operadora do Cartão
• A operadora do cartão é um sistema externo que
será acessado durante a validação do pagamento
que ocorre durante o caso de uso Efetuar reserva
Elaine
Diagrama de caso de uso finalizado
Elaine
Módulo de Gestão de Usuário
RF1
O software deve ident. e validar todos os usuários que desejarem acessá-lo, identificando seu perfil
RF2
O software deve disp. ao usuário identificado as func. associadas ao seu perfil e ao seu papel no sist.
(coordenador, bolsista, etc). As func. de acesso restrito e as func. de acesso público.
RF3
O software deve disp. ao usuário não identificado somente as func. Públicas.
RF4
O software deve permitir ao usuário recuperar a sua senha, caso esqueça
RF5
O software deve permitir que o adm. inclua, altere ou exclua usuários
RF6
O software deve permitir que o adm. inclua, altere ou exclua perfis de acesso
RF7
O software deve permitir que o adm. associe as func. disponíveis nos módulos aos perfis cadastrados
ou exclua dos perfis as funcionalidades previamente associadas.
RF8
O software deve permitir que o adm. associe um usuário a um único perfil de acesso
RF9
O software deve permitir ao adm. consultar as funcionalidades associadas a um perfil
RF10 O software deve permitir ao adm. consultar os usuários associados a um determinado perfil
RF11 O software deve permitir ao adm. indicar se um determinado usuário pode administrar seus
substitutos ou não
RF12 O software deve permitir que os usuários devidamente autorizados designem um ou mais substitutos
com os respectivos períodos de substituição (data inicial e final) e selecionem um subconjunto das
suas funcionalidades as quais os substitutos terão acesso.
Elaine
Módulo de Gestão de Usuário
RF13 O software deve permitir que todos os usuários façam a manutenção de seus dados pessoais:email,
localização, senha e telçefones.
RF14 O software deve permitir que os administradores reenviem a senha de qualquer usuário e que os
usuários reenviem a própria senha
RF15 O software deve gerar senhas temporárias, válidas somente no primeiro login, quando as senhas forem
reenviadas pelos administradores ou pelos próprios usuários
RF16 O software deve solicitar a troca de senha, após o login, para todas as senhas que já expiraram
RF17 O software deve, caso o usuário corrente seja um substituto, apresentar a lista de usuários que ele está
substituindo na data corrente.
RF18 O software deve, caso o usuário corrente seja um substituto, permitir que ele selecione o usuário com
o qual vai atuar, caso ele seja substituto de mais de um usuário.
Elaine
Estudando cada RF
• RF1- O software deve identificar e validar todos os usuários que desejarem
acessá-lo, identificando seu perfil
– Caso de Uso: Autenticar Usuário
– Ator: Usuário
• RF2- O software deve disponibilizar ao usuário identificado as
funcionalidades associadas ao seu perfil e ao seu papel no sistema
(coordenador, bolsista, etc). As funcionalidades de acesso restrito e as
funcionalidades de acesso público.
– Passo que ocorre dentro do autenticar usuário
• RF3- O software deve disponibilizar ao usuário não identificado somente as
funcionalidades de acesso público.
– Passo que ocorre dentro de autenticar usuário, podendo ser modelada como um
fluxo alternativo.
• RF4- O software deve permitir ao usuário recuperar a sua senha, caso esqueça
– Se quiséssemos modelar a possibilidade de recuperação de senha a qualquer
momento através de um menu daí seria um caso de uso, mas neste caso vamos
optar por só poder recuperar senha dentro do efetuar login, então essa
funcionalidade será um fluxo alternativo de efetuar login.
Elaine
Estudando cada RF
• RF5- O software deve permitir que o administrador inclua, altere ou exclua
usuários
– Caso de uso: Administrar usuário
– Ator: Administrador
• RF6- O software deve permitir que o administrador inclua, altere ou exclua
perfis de acesso
– Caso de uso: Administrar perfis de acesso
– Ator: Administrador
• RF7- O software deve permitir que o administrador associe as funcionalidades
disponíveis nos módulos aos perfis cadastrados ou exclua dos perfis as
funcionalidades previamente associadas.
– Passo da funcionalidade Administrar perfil de acesso.
• RF8- O software deve permitir que o administrador associe um usuário a um
único perfil de acesso
– Passo da funcionalidade Administrar perfil de acesso.
Elaine
Estudando cada RF
•
•
•
RF9- O software deve permitir ao administrador consultar as funcionalidades
associadas a um perfil
– Passo da funcionalidade Administrar perfil de acesso
RF10- O software deve permitir ao administrador consultar os usuários associados a
um determinado perfil
– Passo da funcionalidade Administrar perfil de acesso
RF11- O software deve permitir ao administrador indicar se um determinado usuário
pode administrar seus substitutos ou não
– Passo da funcionalidade Administrar usuário
• RF12- O software deve permitir que os usuários devidamente autorizados
designem um ou mais substitutos com os respectivos períodos de substituição
(data inicial e final) e selecionem um subconjunto das suas funcionalidades as
quais os substitutos terão acesso.
– Caso de uso: Administrar substitutos
– Ator: usuário autenticado
Elaine
Estudando cada RF
• RF13- O software deve permitir que todos os usuários façam a manutenção de
seus dados pessoais: e-mail, localização, senha e telefones.
– Caso de uso: Manter dados pessoais
– Ator: usuário autenticado
• RF14- O software deve permitir que os administradores reenviem a senha de
qualquer usuário e que os usuários reenviem a própria senha
– Passo presente em administrar usuário e em administrar perfil
• RF15- O software deve gerar senhas temporárias, válidas somente no primeiro
login, quando as senhas forem reenviadas pelos administradores ou pelos
próprios usuários
– Passo presente em casos de uso do sistema
• RF16- O software deve solicitar a troca de senha, após o login, para todas as
senhas que já expiraram
– Regras associadas a autenticar usuário
Elaine
Estudando cada RF
• RF17- O software deve, caso o usuário corrente seja um
substituto, apresentar a lista de usuários que ele está substituindo
na data corrente.
– Regra interna ao autenticar usuário
• RF18- O software deve, caso o usuário corrente seja um
substituto, permitir que ele selecione o usuário com o qual vai
atuar, caso ele seja substituto de mais de um usuário.
– Caso de uso: Selecionar perfil de uso
– Ator: Usuário autenticado
Elaine
Solução - Caso de Uso
Elaine
Descrição Casos de Uso
• UC1 – Nome do Caso de Uso
–
–
–
–
–
–
–
–
–
–
–
–
–
Objetivo: Breve descrição do que o caso de uso deverá fazer
Requisitos: A qual RF do doc de requisitos ele se refere
Atores: Quem acessa esse caso de uso
Prioridade: É prioritário ou não (cliente define)
Pré-condições: quais as condições necessárias antes de disparar o caso de uso
Freqüência de uso: a frequencia me dá idéia de criticalidade (risco)
Criticalidade (risco): importância do caso de uso
Condição de entrada: o que dispara esse caso de uso
Fluxo Principal: descrever ações normais que ocorrem
Fluxo Alternativo: desvios do cenário principal
Extensões: descrevem os extends
Pós Condições: o que deve ser verdade depois de executado o caso de uso
Regras de Negócio: que pode ser definido agora ou em doc à parte.
Elaine
Prioridade e Risco
• Devemos considerar os casos de uso mais importantes
primeiramente. Para identificar os mais importantes verificamos
os parâmetros: risco de desenvolvimento(criticalidade) e
prioridade estabelecidas pelo usuário. Dessa forma, cada caso de
uso se encaixa em uma das categorias a seguir:
– 1. Risco alto e prioridade alta: casos de uso nesta categoria são os mais
críticos. Devem ser considerados o quanto antes.
– 2. Risco alto e prioridade baixa: embora os casos de uso nesta categoria
tenham risco alto, é necessário, antes de começar a considerá-los, negociar
com o cliente em relação a sua verdadeira necessidade.
– 3. Risco baixo e prioridade alta: embora os casos de uso tenham prioridade
alta, é necessário ter em mente que os casos de uso de mais alto risco
devem ser considerados primeiro.
– 4. Risco baixo e prioridade baixa: em situações em que o desenvolvimento
do sistema está atrasado, estes casos de uso são os primeiros a serem
"cortados".
Elaine
Exemplo de descrição
• UC1 – Consultar Clientes
– Objetivo: O sistema deve permitir que o setor de atendimento
ao cliente consulte clientes cadastrados
– Requisitos: RF1
– Atores: Setor de atendimento ao cliente
– Prioridade: – Pré-condições: – Freqüência de uso: diária
– Criticalidade: – Condição de entrada: o ator seleciona a opção consultar
cliente
Elaine
Fluxo Principal:
1. O sistema apresenta tela de busca de clientes contendo as
informações:
- Nome (campo editável)
- Status (lista contendo os itens: Em dia, Inadimplente)
- As opções:
* Buscar
* Cancelar
2. O ator informa dados de busca e seleciona a opção Buscar [A1]
3. O sistema apresenta tela com informações dos Clientes de acordo com
o filtro especificado:
- Nome (somente leitura)
- Status (somente leitura)
- CPF (somente leitura)
- Data de Nascimento (somente leitura)
- A opção Detalhar
4. O sistema apresenta ao final a opção Voltar
Elaine
Fluxo Principal:
5. O ator seleciona a opção Detalhar [A2]
6. O sistema apresenta tela de detalhes para o cliente contendo
as informações:
- Nome (somente leitura)
- CPF (somente leitura)
- Status (somente leitura)
Se o cliente estiver com
- Data de Nascimento (somente leitura)
status em dia não
- Endereço (somente leitura)
aparece, se estiver em
atraso, mostra o motivo
- Motivo [RN1] (somente leitura)
de acordo com regra
- A opção Ok
negócio 1
7. O ator seleciona a opção ok
8. O sistema retorna ao passo 3 do fluxo principal.
Elaine
Fluxo Alternativo:
Fluxo Alternativo:
[A1] O ator selecionou a opção Cancelar
1. Sistema retorna para a tela inicial.
2. O caso de uso é encerrado.
[A2] O ator selecionou a opção Voltar
1. Sistema retorna ao passo 1 do fluxo principal.
Extensões: Pós Condições: Regras de Negócio: [RN1] O campo Motivo será apresentado
apenas se o Status do cliente for inadimplente
Elaine
Descrições independentes de Interface
• Alteração na Interface alteração descrição
– Considere a situação de uma parte da interface estar sendo
continuamente modificada, por alguma razão. O fato da interface
ser modificada possivelmente resultará na modificação da
descrição do caso de uso.
• Assim, casos de uso devem ser independentes do
desenho da interface pelo fato de que os requisitos do
sistema não devem estar associados a detalhes de
interface.
• A atenção deve estar na essência das interações entre
atores e o sistema, em vez de como cada interação é
realizada fisicamente.
• Por exemplo, usar o termo "envia uma requisição" ao invés
de "duplo clique sobre o botão de envio de requisições".
Elaine
Caso de Uso – Incluir Cliente
• UC1 – Incluir Clientes
– Objetivo: O sistema deve permitir que o administrador efetue
o cadastrado de cliente
– Requisitos: RF2
– Atores: Administrador
– Prioridade: – Pré-condições: – Freqüência de uso: – Criticalidade: – Condição de entrada: o ator seleciona a opção incluir cliente
Elaine
Fluxo Principal:
1. O sistema apresenta tela de cadastro de clientes contendo as
informações:
(Dados Pessoais)
- Nome (campo editável)
- CPF(campo editável)
- RG (campo editável)
-Data de Nascimento (campo editável)
-Sexo (lista contendo as opções feminino e masculino)
(Informações de Contato)
- Endereço (campo editável)
- Telefone de contato (campo editável)
- e-mail (campo editável)
- As opções:
* Incluir Cliente
* Cancelar
Elaine
Fluxo Principal:
2. O ator informa os dados do cliente e seleciona a
opção incluir Cliente [A1]
3. O sistema valida os dados informados [RN1]
4. O sistema efetua o cadastro do cliente [RN2]
5. O sistema exibe a mensagem “Cliente cadastrado com
sucesso” com a opção OK no final.
6. O ator seleciona OK
7. O sistema retorna para a tela inicial
8. O caso de uso é encerrado.
Elaine
Fluxo Alternativo
Fluxo Alternativo:
[A1] O ator seleciona a opção Cancelar
1. Sistema retorna para a tela inicial.
2. O caso de uso é encerrado.
[A2] Dados para cadastro do cliente inválidos
1. O sistema exibe mensagem de erro “Existem informações
obrigatórias que não foram preenchidas com a opção OK no final.
2. O ator seleciona a opção
3. O sistema retorna ao passo 1 do fluxo principal.
Extensões: Pós Condições: Regras de Negócio:
[RN1] Todos os campos do cadastro de clientes são obrigatórios.
[RN2] Ao efetuar o cadastro do cliente, um número de matrícula deve
ser gerado para o cliente.
Elaine
Extensão ou Fluxo Alternativo
• Conceitualmente, o mecanismo de extensão é idêntico
aquele dos fluxos alternativos. Um caso de uso de
extensão, assim como um fluxo alternativo, insere a si
próprio no fluxo do caso de uso que ele estende.
Somente o caso de uso de extensão conhece o ponto no
caso de uso base onde o comportamento será inserido.
Em conseqüência, freqüentemente um caso de uso de
extensão começa sua vida como um fluxo alternativo.
Elaine
Extensão ou Fluxo Alternativo
• Nem todo fluxo alternativo deve virar um caso de uso de
extensão. As regras para os fluxos alternativos são mais
frouxas do que aquelas para os casos de uso de extensão.
Devido ao fato de que os fluxos alternativos são parte do
caso de uso, eles podem explorar seu conhecimento do
estado do caso de uso, suas pré-condições, e outros fluxos
de eventos para terminar o caso de uso ou para continuar o
fluxo do caso de uso em pontos de extensão diferentes
daquele onde eles assumiram o controle. Tudo o que os
casos de uso de extensão conhecem a respeito do caso de
uso original é o ponto de extensão onde eles introduziram a
si próprios no fluxo de eventos do caso de uso estendido.
Elaine