Modelagem de Casos de Uso - slides

Prévia do material em texto

Modelagem de Casos de Uso 
Casos de Uso 
• O modelo de casos de uso é uma 
representação das 
– funcionalidades externamente observáveis do 
sistema 
– e dos elementos externos ao sistema que 
interagem com o mesmo. 
• Esse modelo representa, na UML, os 
requisitos funcionais do sistema. 
 
Utilidade dos Casos de Uso 
• Equipe de clientes (validação) 
– aprovam o que o sistema deverá fazer 
– entendem o que o sistema deverá fazer 
• Equipe de desenvolvedores 
– Ponto de partida para refinar requisitos de software. 
– Podem seguir um desenvolvimento dirigido a casos de 
uso. 
• Designer (projetista): encontrar classes 
• Testadores: usam como base para casos de teste 
 
Composição dos Casos de Uso 
• O modelo de casos de uso de um sistema é 
composto de duas partes: 
– textual, 
– gráfica. 
• O diagrama da UML utilizado na modelagem 
gráfica é o diagrama de casos de uso. 
• Este diagrama permite uma visão global e de alto 
nível do sistema. 
• Componentes: casos de uso, atores, 
relacionamentos entre os elementos anteriores. 
 
Casos de Uso - Definição 
• Um caso de uso é a especificação de uma 
sequência de interações entre um sistema e os 
agentes externos. 
• Define parte da funcionalidade de um sistema, 
sem revelar a estrutura e o comportamento 
internos deste sistema. 
• Cada caso de uso é definido através da 
descrição textual das interações que ocorrem 
entre o(s) elemento(s) externo(s) e o sistema. 
 
 
• Um caso de uso é : 
– um conjunto de cenários amarrados por um 
objetivo comum de usuário. 
• Um cenário: 
– É uma sequência de passos que descreve uma 
interação entre um usuário e um sistema. 
– É uma forma prática de transformar requisitos 
funcionais em casos de uso 
 6 
 
Cenário de caso de uso 
 
 
• Exemplo: em uma loja virtual um dos cenários 
envolvidos em uma “compra de produto” é: 
1. O cliente navega no catálogo de itens e adiciona 
os itens desejados à sua cesta de compras. 
2. Quando o cliente deseja pagar ele descreve o 
endereço de entrega, fornece as informações do 
cartão de crédito e confirma a venda. 
3. O sistema verifica a autorização do cartão de 
crédito, confirma a venda imediatamente e envia 
um email. 
 
 7 
 
Cenário de caso de uso 
 
 
• Exemplo: em uma loja virtual os outros cenários 
envolvidos em uma “compra de produto” : 
– O cliente pode desistir de comprar após o passo 1 
– A autorização do cartão de crédito pode falhar 
– O cliente pode ser um comprador regular e , portanto, 
o sistema conhece as informações de endereço e 
cartão de crédito. 
• Logo não seria necessário informar novamente. 
• Todos os itens anteriores geram cenários 
diferentes que devem ser representados no caso 
de uso. 
 
 8 
 
Cenário de caso de uso 
 
 
 
• Cada caso de uso é representado por uma 
elipse. 
 
• O nome do caso de uso: 
– É posicionado abaixo ou dentro da elipse. 
9 
 
Notação 
 
EfetuarCompra 
Dimensões para descrições textuais 
• Um caso de uso é definido através da 
descrição textual das interações entre o(s) 
elemento(s) externo(s) e o sistema. 
• A UML não define nada acerca de como essa 
descrição textual deve ser construída. 
• Há várias dimensões independentes para a 
descrição textual de um caso de uso: 
– Formato (contínua, tabular, numerado) 
– Grau de detalhamento (sucinta ou expandida) 
 
Ex. Descrição Contínua 
Ex. Descrição Numerada 
Ex. Descrição tabular 
Atores 
• Elemento externo que interage com o sistema. 
– “externo”: atores não fazem parte do sistema. 
– “interage”: um ator troca informações com o 
sistema. 
• Casos de uso representam uma sequência de 
interações entre o sistema e o ator. 
– no sentido de troca de informações entre eles. 
• Normalmente um agente externo inicia a 
sequência de interações como o sistema. 
 
Atores 
• Categorias de atores: 
– cargos (Empregado, Cliente, Gerente, Almoxarife, 
Vendedor etc.); 
– organizações (Empresa Fornecedora, Agência de 
Impostos, Administradora de Cartões etc.); 
– outros sistemas (Sistema de Cobrança, Sistema de 
Estoque de Produtos etc.); 
– equipamentos (Leitora de Código de Barras, Sensor 
etc.). 
• Essa categorização indica que o conceito de ator 
depende do escopo do sistema. 
 
Atores 
• Um ator corresponde a um papel 
representado em relação ao sistema. 
• O mesmo indivíduo pode ser o Cliente que 
compra mercadorias e o Vendedor que 
processa vendas. 
• O nome dado a um ator deve lembrar o seu 
papel, em vez de lembrar quem o representa. 
 
 
 
• A notação normalmente usada para um ator 
é: 
– A figura de um boneco com o nome do ator 
definido abaixo desta figura. 
 
 
 
 
 
 
 
 
17 
 
Notação 
 
 
• Um ator pode participar de muitos casos de 
uso 
– esta situação é comum de se encontrar na prática. 
• Um caso de uso pode envolver a participação 
de vários atores 
– Um ator primário : 
• É aquele que usa o sistema para atingir um objetivo. 
– Um ator secundário : 
• É aquele necessário pelo sistema para que este consiga 
fazer com que o ator primário alcance seu objetivo. 
• Pode ser uma pessoa ou outro sistema de software 
18 
 
Atores primários e secundários 
 
• Por exemplo: 
– Considere um programa para compras pela 
Internet 
– Para que o Cliente (ator primário) realize compra 
(caso de uso), outro ator está envolvido: a 
operadora do cartão de crédito. 
• Note que: 
– o ator primário Usuário é auxiliado (via sistema) 
pelo ator secundário, a operadora. 
– É através deste último que o primeiro alcança seu objetivo 
(i.e., realizar a compra pela Internet). 
19 
 
Atores primários e secundários 
 
 
• É recomendável definir uma breve descrição 
textual para cada ator identificado. 
 
• Exemplo: 
– Aluno: representa pessoas que fazem um curso dentro da 
universidade. 
 
• Convenções: 
– Nome deve indicar papel do ator ao realizar o caso de uso. 
20 
 
Documentando atores 
Atores vs. Casos de Uso 
• Um ator representa um conjunto coerente de papéis 
que os usuários desempenham quando interagem 
com o sistema 
• Um caso de uso representa o que um ator quer que o 
sistema faça. 
• Atores servem para definir o ambiente do sistema 
• Se comunicam enviando mensagens e/ou recebendo 
mensagens do sistema 
• Ao se definir o que os atores fazem e o que os casos de 
uso fazem, delimita-se, o escopo do sistema. 
 
Diagrama de Casos de Uso 
• Representa graficamente os atores, casos de 
uso e relacionamentos entre os elementos. 
• Ilustra em um nível alto de abstração: 
– elementos externos 
– funcionalidades do sistema. 
• Uma espécie de “diagrama de contexto”. 
– Apresenta os elementos externos de um sistema e 
as maneiras segundo as quais eles as utilizam. 
 
Ex. Diagrama de Casos de Uso 
Ex. Diagrama de Casos de Uso 
Elementos dos Diagramas de Casos de 
Uso 
• Atores e Casos de uso 
• Relacionamentos entre esses elementos: 
– Comunicação 
– Inclusão 
– Extensão 
– Generalização 
• Para cada um desses elementos, a UML define 
uma notação gráfica e uma semântica 
específicas. 
 
Ator, caso de uso, comunicação 
 
Inclusão (include) 
Inclusão (include) 
• Use inclusão quando o mesmo comportamento 
se repetir em mais de um caso de uso. 
• Por meio do relacionamento de inclusão esse 
comportamento comum pode ser fatorado em 
um novo caso de uso, o chamado caso de uso 
incluso. 
• Esse comportamento comum está 
necessariamente contido em todos os cenários 
dos casos de uso inclusores, e que estes últimosnão são completos se o comportamento do caso 
de uso não estiver incluso. 
 
• Relacionamento de inclusão: 
– No relacionamento de inclusão, o comportamento 
de B é “enxertado” em A. 
29 
 
Compreendendo o relacionamento de inclusão 
 
 
• Outro exemplo de inclusão: 
– O caso de uso #1: 
• chega ao local no caso de uso base para o qual o 
relacionamento de inclusão está definido e a inclusão é 
realizada. 
– O caso de uso #2: 
• não alcança esta parte e 
a inclusão não é realizada”. 
30 
Compreendendo o relacionamento de inclusão 
Extensão (extend) 
 
• Relacionamento de extensão: 
– Relaciona um caso de uso base a outro cujo 
comportamento é um complemento (extensão) 
do primeiro. Trata-se de um comportamento 
eventual (opcional). 
• O caso de uso base (estendido): 
– É uma descrição completa de uma sequência de 
interações, que tem significado por si mesma. 
– i.e., o caso de uso base já é completo, sem 
considerar as possíveis extensões 
32 
 
Compreendendo o relacionamento de extensão 
 
• O que desencadeia a execução do caso de uso 
extensor é a ocorrência de alguma condição 
(ou a solicitação explícita do ator). 
33 
Compreendendo o relacionamento de extensão 
Generalização 
Generalização 
 
36 
 
Compreendendo o relacionamento de generalização 
 
 
Indica que Professor pode realizar : 
• “Reservar Livro” e 
• “Pesquisar Catálogo ” 
• “Solicitar Compra de Título” 
Indica semelhança conceitual entre 
os dois casos de uso específicos. 
 
• A generalização entre casos de uso: 
– O caso de uso herdeiro apresenta o mesmo 
comportamento, estrutura e relacionamentos do 
seu caso de uso pai 
– Logo: 
• Se alguma parte do pai não fizer sentido para o caso de uso herdeiro, não 
faz sentido utilizar generalização. 
– Portanto : 
• Se apenas algumas partes do caso de uso pai fizerem sentido, considere a 
extensão, em vez de generalização. 
 
 
37 
 
Compreendendo o relacionamento de generalização 
 
Resumo da notação 
 
39 
 
Resumo Relacionamentos 
Elemento Comunicação Extensão Inclusão Generalização 
Caso de uso 
e 
Caso de uso 
X X X 
Ator e Ator X 
Caso de uso 
e 
Ator 
X 
Identificação dos elementos dos casos 
de uso 
• Atores e os casos de uso são identificados a 
partir de informações coletadas no 
levantamento de requisitos. 
• Não há uma regra geral que indique quantos 
casos de uso e atores são necessários para 
descrever um sistema. 
• A quantidade de casos de uso e atores 
depende da complexidade do sistema. 
 
Identificação de atores 
• Fontes e os destinos das informações a serem 
processadas são atores em potencial. 
– uma vez que, por definição, um ator é todo 
elemento externo que interage com o sistema. 
• O analista deve identificar: 
– as áreas da empresa que serão afetadas ou 
utilizarão o sistema. 
– fontes de informações a serem processadas e os 
destinos das informações geradas pelo sistema. 
 
Identificação de Atores 
• Há algumas perguntas úteis cujas respostas 
potencialmente identificam atores. 
– Que órgãos, empresas ou pessoas (cargos) irão 
utilizar o sistema? 
– Que outros sistemas irão se comunicar com o 
sistema? 
– Alguém deve ser informado de alguma ocorrência 
no sistema? 
– Quem está interessado em um certo requisito 
funcional do sistema? 
 
Identificação de Casos de Uso 
• Perguntas úteis: 
– Quais são as necessidades e objetivos de cada 
ator em relação ao sistema? 
– Que informações o sistema deve produzir? 
– Para cada requisito funcional, existe um (ou mais) 
caso(s) de uso para atendê-lo? 
 
Construção do diagrama de casos de 
uso 
• Os diagramas de casos de uso devem servir 
para dar suporte à parte textual do modelo, 
fornecendo uma visão de alto nível. 
• Se o sistema sendo modelado não for tão 
complexo, pode ser criado um único Diagrama 
de Casos de Uso. 
• É útil e recomendada a utilização do retângulo 
de fronteira para delimitar e separar 
visualmente casos de uso e atores. 
 
Construção do diagrama de casos de 
uso 
• Em sistemas complexos, representar todos os 
casos de uso do sistema em um único diagrama 
talvez o torne um tanto ilegível. 
• Alternativa: criar vários diagramas (de acordo 
com as necessidades de visualização) e agrupá-
los em pacotes. 
– Todos os casos de uso para um ator; 
– Todos os casos de uso a serem implementados em um 
ciclo de desenvolvimento. 
– Todos os casos de uso de uma área (departamento, 
seção) específica da empresa. 
 
Ex. de diagrama de casos de uso 
Documentação dos atores 
• Uma breve descrição para cada ator deve ser 
adicionada. 
• O nome de um ator deve lembrar o papel 
desempenhado pelo mesmo. 
• Exemplo 
– “Aluno: representa pessoas que fazem um curso 
dentro da universidade.” 
 
Documentação dos casos de uso 
• A UML não define um padrão para descrição 
textual dos casos de uso de um sistema. 
• É necessário que a equipe de desenvolvimento 
padronize o seu estilo de descrição. 
• Algumas seções normalmente encontradas: 
– Sumário 
– Atores 
– Fluxo principal 
– Fluxos alternativos 
 
Documentação dos casos de uso 
Fluxo Principal: fluxo básico, o que acontece normalmente quando o UC é utilizado 
Fluxos Alternativos: descrição dos cenários 
Fluxos de Exceção: o que acontece quando algo inesperado ocorre (ex. situações não 
usuais e como o sistema se recupera) 
Pós-condições: estado que o sistema alcança após execução do UC 
Regras do Negócio 
Histórico: modificações, autor, data criação... 
Notas de Implementação: ideias do modelador. Não é a especificação da solução. 
Nome: o mesmo utilizado no diagrama de caso de uso 
Descrição 
Identificador: ID. Ex. UC001, UC002,... 
Importância: risco de desenvolvimento e prioridade 
Sumário: pequena declaração do objetivo do ator ao utilizar o UC. Máx. 2 linhas 
Ator Primário: ator que inicia o caso de uso 
Atores Secundários: demais elementos externos participantes do caso de uso 
Precondições: hipóteses assumidas como verdadeiras para início do UC 
 
• Na descrição de um caso de uso, pode haver 
vários tipos de bifurcações a partir do fluxo 
principal. 
 
Conteúdo dos casos de uso 
 
• Exemplo : em uma loja virtual fluxo principal uma “compra de produto” é: 
1. O Cliente informa que deseja realizar compra 
2. O Sistema lista o nome, a descrição e o valor dos produtos disponíveis para 
compra 
3. O cliente adiciona os itens desejados à sua cesta de compras. 
4. O sistema apresenta o nome, o preço, a quantidade de cada produto na 
cesta de compras e o total a ser pago. 
5. O cliente informa o endereço de entrega e as informações do cartão de 
crédito 
6. O sistema verifica as informações de compra com a operadora de cartão de 
crédito 
7. O cliente conclui a compra 
8. O sistema cria o pedido com os produto da cesta de compras, esvazia a 
mesma, verifica a autorização do cartão de crédito, confirma a venda dos 
produtos imediatamente e envia um email. 
9. Fim do caso de uso 
 
 51 
 
Conteúdo de caso de uso 
 
 
• Exemplos de fluxos alternativos : 
– FA1 : Remover produto da cesta de compras 
Este fluxo inicia no passo 5 do fluxo principal, quando o 
cliente informa que deseja remover um produto da sua 
cesta de compras. 
1. o sistema remove produto da cesta 
2. Voltar para passo 4 do fluxo principal 
 
 
 52 
 
Cenários no caso de uso 
 
 
• Exemplo : em uma loja virtual fluxo principal 
uma “compra de produto” é: 
1. O Cliente informa que deseja realizar compra 
2. O Sistema lista o nome, a descrição e o valor dosprodutos disponíveis para compra 
3. O cliente adiciona os itens desejados à sua cesta 
de compras. 
4. O sistema apresenta o nome, o preço, a 
quantidade de cada produto na cesta de compras 
e o total a ser pago. 
 
 53 
 
Conteúdo de caso de uso 
 
 
• Exemplo : em uma loja virtual fluxo principal uma “compra 
de produto” é: 
1. O Cliente informa que deseja realizar compra 
2. O Sistema lista o nome, a descrição e o valor dos produtos 
disponíveis para compra 
3. O cliente adiciona os itens desejados à sua cesta de compras. 
4. O sistema apresenta o nome, o preço, a quantidade de cada 
produto na cesta de compras e o total a ser pago. 
 
 
 
 
 
 
 
5. O cliente informa o endereço de entrega e as informações do 
cartão de crédito 
 
 54 
 
Conteúdo de caso de uso 
 
–FA1 : Remover produto da cesta de compras 
Este fluxo inicia no passo 5 do fluxo principal, 
quando o cliente informa que deseja remover um 
produto da sua cesta de compras. 
1. o sistema remove produto da cesta 
2.Voltar para passo 4 do fluxo principal 
 
 
• Outros exemplos de fluxos alternativos : 
– FA2 : Alterar quantidade de um produto da cesta de compras 
Este fluxo inicia no passo 5 do fluxo principal, quando o cliente informa 
que deseja alterar a quantidade de um produto da sua cesta de 
compras. 
1. o sistema atualiza a quantidade do produto na cesta 
2. Voltar para passo 4 do fluxo principal 
 
– FA3 : Cartão de crédito inválido 
Este fluxo inicia no passo 6 do fluxo principal, quando o cliente informa 
que deseja alterar a quantidade de um produto da sua cesta de 
compras. 
1. o sistema informa que o cartão de crédito informado é 
inválido 
2. Voltar para passo 4 do fluxo principal 
 
 55 
 
Cenários no caso de uso 
 
 
• Outros exemplos de fluxos alternativos : 
 
– FA4 : Comprador regular 
Este fluxo inicia no passo 5 do fluxo principal, e o sistema 
já apresenta as informações de entrega e de cartão de 
crédito. 
1. O usuário confirma se as informações estão 
corretas 
2. Ir para passo 7 do fluxo principal 
 
 
 
 56 
 
Cenários no caso de uso 
 
 
 
• O modelo de casos de uso: 
– força o desenvolvedor a pensar em como os agentes externos 
interagem com o sistema. 
 
• No entanto, este modelo corresponde somente aos requisitos 
funcionais. 
– Outros tipos de requisitos (desempenho, interface, segurança, regras 
do negócio, etc.) também devem ser identificados e modelados. 
 
• Esses outros requisitos fazem parte da documentação associada ao 
MCU. 
– Dois itens importantes dessa documentação associada são: 
• o modelo de regras do negócio e 
• os requisitos de desempenho (não funcionais). 
Documentação associada 
 
• Regras de negócio: 
– São políticas, condições ou restrições que devem 
ser consideradas na execução dos processos de 
uma organização. 
– Descrevem a maneira pela qual a organização 
funciona. 
• Modelo de Regras do Negócio (MRN): 
– Identifica e documenta as regras de negócio 
58 
Regras do negócio 
 
• Exemplos de regras de negócio: 
– O valor total de um pedido é igual à soma dos totais 
dos itens do pedido acrescido de 10% de taxa de 
entrega. 
– Um professor só pode estar lecionando disciplinas 
para as quais esteja habilitado. 
– Um cliente de uma das agências do banco não pode 
retirar mais do que R$ 1.000 por dia de sua conta. 
Após as 18h00, esse limite cai para R$ 100,00. 
– Os pedidos para um cliente não especial devem ser 
pagos antecipadamente. 
59 
Exemplos de regras do negócio 
 
• A descrição do modelo de regras do negócio: 
– pode ser feita utilizando-se texto informal, ou através de alguma 
forma de estruturação. 
• Possível formato para documentação de uma 
regra de negócio no MRN. 
 
Regras do negócio 
Nome Quantidade de inscrições possíveis (RN01) 
Descrição Um aluno não pode ser inscrever em mais de seis 
disciplinas por semestre letivo. 
Fonte Coordenador da escola de informática 
Histórico Data de identificação: 12/07/2002 
 
• Regras do negócio: 
– normalmente influenciam o comportamento de 
determinados casos de uso. 
– Quando isso ocorre: 
• Os identificadores das regras do negócio devem ser adicionados à 
descrição dos casos de uso em questão. 
• Uso da seção “regras do negócio” da descrição do caso de uso. 
Regras do negócio 
 
• No exemplo da loja virtual : 
1. O Cliente informa que deseja realizar compra 
2. O sistema lista o nome, a descrição e o valor dos produtos disponíveis para 
compra 
3. O cliente adiciona os itens desejados à sua cesta de compras. 
4. O sistema apresenta o nome, o preço, a quantidade de cada produto na 
cesta de compras e o total a ser pago(de acordo com a RN1). 
5. O cliente informa o endereço de entrega e as informações do cartão de 
crédito 
6. O sistema verifica as informações de compra com a operadora de cartão de 
crédito 
7. O cliente conclui a compra 
8. O sistema cria o pedido com os produto da cesta de compras, esvazia a 
mesma, verifica a autorização do cartão de crédito, confirma a venda dos 
produtos imediatamente e envia um email. 
9. Fim do caso de uso 
 
 62 
 
Regras de negócio 
 
Nome Valor total de um pedido (RN01) 
Descrição O valor total de um pedido é igual à soma dos valores dos itens do pedido acrescido 
de 10% de taxa de entrega. 
Fonte Chefe de vendas 
Histórico Data de identificação: 12/07/2002 
 
• Quando usar inclusão: 
– Quando o mesmo comportamento se repete em 
mais de um caso de uso. 
– Através de inclusão esse comportamento comum 
pode ser fatorado. 
• Note duas coisas: 
– Esse comportamento comum não necessariamente está contido em 
todos os cenários dos casos de uso inclusores, 
– O caso de uso base não é completo sem o comportamento do caso de 
uso incluso. 
63 
 
Construção do DCU 
 
• Como referenciar o caso de uso incluso no 
caso de uso inclusor? 
– Consenso: na descrição do caso de uso inclusor, 
deve ser feita uma referência para o caso de uso 
incluso. 
– Uma possível sintaxe para referência na descrição 
do caso de uso inclusor: 
Include(nome do caso de uso incluso) 
64 
 
Construção do DCU 
 
 
• No relacionamento de inclusão, o 
comportamento de B é “enxertado” em A. 
65 
Construção do DCU 
 
Relaciona um caso de uso base e 
um caso de uso cujo comportamento é compartilhado. 
 
 
• Exemplo : Cliente efetuando transferência em 
banco online 
• Pré-condição: O cliente apresentar uma conta 
identificada no sistema 
1. O cliente informa o valor, o banco, o número de 
conta e agência que deseja transferir. 
2. O Sistema verifica se são válidos o banco, a conta e a 
agência informada. 
3. Include <EfetuarSaque> 
4. Include <EfetuarDeposito> 
5. Fim do caso de uso 
 66 
Construção do DCU 
 
• Quando usar extensão: 
– Quando um comportamento eventual em um caso 
de uso tiver de ser descrito. 
• O caso de uso estendido pode não utilizar esse comportamento eventual, 
posto que o mesmo é opcional. 
– Quando precisamos estender o comportamento 
de um caso de uso preexistente sem modificar sua 
descrição original. 
• Importante, principalmente em um processo de desenvolvimento iterativo e 
incremental. 
67 
 
Construção do DCU 
 
 
• Extensão: 
– Relaciona um caso de uso base a outro cujo 
comportamento é um complemento(extensão) do 
primeiro. 
 
 
 
 
 
68 
Construção do DCU 
O caso de uso base já é completo, sem 
considerar as possíveis extensões. 
 
• Caso de uso “PostarEncomenda”: 
1. O cliente informa a altura, largura, profundidade e o peso 
da encomenda.Também informa a origem e o destino da 
encomenda 
2. O sistema calcula o valor do frete e o tempo de entrega 
de acordo com a distância, o volume e o peso da 
encomenda (RN X) e apresenta o valor a ser pago e uma 
lista de datas e horários de coleta disponíveis. 
3. O Cliente informa a data e a hora de coleta. 
4. Include <efetuar pagamento> 
5. O sistema cria o pedido de coleta e.. 
6. Fim do caso de uso 
 69 
Construção do DCU 
 
• Caso de uso : PostarEncomendaExpressa 
Este caso de uso inicia no passo 3 do caso de uso 
“PostarEncomenda” quando, após informar a data e a hora de 
coleta, o cliente informa que deseja postar a encomenda de forma 
expressa. 
1. O sistema lista as opções de encomenda expressa : 10 horas 
do dia seguinte da coleta ou 24 horas após coleta. 
2. O cliente seleciona uma das opções de encomenda expressa 
3. O sistema recalcula o valor a ser pago (RNY) e apresenta para o 
cliente 
4. O cliente confirma a alteração de valor a ser pago 
5. Ir para o passo 4 do fluxo principal de “PostarEncomenda” 
 70 
Construção do DCU 
 
 
• Quando usar generalização entre atores: 
– Quando for preciso definir um ator: 
• Que desempenhe um papel que já é desempenhado por 
outro ator em relação ao sistema 
– Quando o novo ator possui comportamento 
particular e/ou adicional. 
• Por exemplo no Caso de uso: PostarEncomenda 
– Um cliente pode ser também funcionário 
– No caso anterior : 
• É comum existir uma Regra de negócio que dê desconto para 
funcionários 
 
71 
Construção do DCU 
 
 
• Quando usar generalização entre casos de 
uso: 
– Quando dois ou mais casos de uso possuem 
comportamentos semelhantes: 
• Cria-se um caso de uso genérico 
• Relaciona-se o caso de uso criado aos casos de uso 
semelhantes. 
72 
Construção do DCU 
 
• Caso de uso “EfetuarPagamento”: 
1. O Cliente informa que deseja efetuar o pagamento 
2. O Sistema apresenta o valor a ser pago 
3. O Cliente informa a forma de pagamento 
4. O Sistema verifica se é possível efetuar o pagamento 
com a operadora do cartão 
5. O Cliente confirma o pagamento 
6. O sistema emite um comprovante sobre o valor 
pago. 
7. Fim do caso de uso 
 73 
Construção do DCU 
 
• Caso de uso “EfetuarPagDebito”: 
Este caso de uso inicia no passo 3 do caso de uso “Efetuar pagamento” 
1. O Cliente informa que deseja efetuar o pagamento em débito 
2. O Sistema apresenta a lista de bancos disponíveis para a operação 
3. O Cliente informa o banco, o número da agência, da conta e a senha. 
4. Ir para o passo 4 do caso de uso “Efetuar pagamento” 
– FA1 : agencia, conta ou senha inválidos 
Este fluxo inicia no passo 4 do fluxo principal do caso de uso “EfetuarPagamento” 
e a operadora informa que as informações da conta não estão corretas. 
1. O Sistema informa que as informações da conta não estão corretas 
2. Voltar para o passo 3 do fluxo principal deste caso de uso. 
 
 
 74 
Construção do DCU 
 
• Caso de uso “EfetuarPagCredito”: 
Este caso de uso inicia no passo 3 do caso de uso “Efetuar pagamento” 
1. O Cliente informa que deseja efetuar o pagamento em crédito 
2. O Sistema apresenta a lista de bandeiras disponíveis para a operação 
e o número de parcelas, com e sem juros, em que o pagamento pode 
ser efetuado ( de acordo com a RNZ). 
3. O Cliente informa o número de parcelas, a bandeira, o número do 
cartão, o dígito verificador e a senha 
4. Ir para o passo 4 do caso de uso “Efetuar pagamento” 
– FA1 : Crédito indisponível 
Este fluxo inicia no passo 4 do fluxo principal do caso de uso “EfetuarPagamento” 
e a operadora informa que o valor ou o número de parcela não estão disponíveis 
para o cartão informado. 
1. O Sistema informa que as informações a indisponibilidade de 
crédito 
2. Voltar para o passo 3 do fluxo principal deste caso de uso. 
 
 75 
Construção do DCU 
Documentação de casos de uso – boas 
práticas 
• Comece o nome do caso de uso com um verbo no 
infinitivo (para indicar um processo ou ação). 
• Não descrever como o sistema realiza 
internamente um passo de um caso de uso. 
• Tente dar nomes a casos de uso seguindo 
perspectiva do ator primário. 
• Ex.: Registrar Pedido, Abrir Ordem de Produção, 
Manter Referência, Alugar Filme, etc. 
 
Documentação de casos de uso – boas 
práticas 
• Não se preocupar com a interface gráfica 
durante a escrita 
• Não se preocupar com detalhes técnicos, a 
serem preenchidos posteriormente 
• Manter a descrição de cada caso de uso no 
nível mais simples possível. 
 
Exemplos de Escrita 
O administrador identifica-se vs. O administrador insere seu ID e 
senha. 
 
O sistema registra a venda. Vs O sistema grava a venda no banco 
de dados usando o comando SQL insert into ... 
 
Casos de uso e outras atividades 
• Validação 
– Clientes e usuários devem entender o modelo 
(validação) e usá-lo para comunicar suas necessidades 
de forma consistente e não redundante. 
• Planejamento e gerenciamento do projeto 
– Uma ferramenta fundamental para o gerente de um 
projeto no planejamento e controle de um processo 
de desenvolvimento incremental e iterativo 
• Testes do sistema 
– Os casos de uso e seus cenários oferecem casos de 
teste. 
 
Casos de uso e outras atividades 
• Documentação do sistema para os usuários 
– Manuais e guias do usuário podem ser construídos 
com base nos casos de uso. 
• Realização de uma iteração 
– Os casos de uso podem se alocados entre os 
membros de equipe de desenvolvimento 
• Essa estratégia de utilizar o MCU como ponto de 
partida para outras atividades é denominada 
Desenvolvimento Dirigido por Casos de Uso 
– Use Case Driven Development 
 
Casos de uso no processo de 
desenvolvimento 
• Um grupo de casos é alocado a cada iteração. 
– Em cada iteração, o grupo de casos de uso é 
detalhado e desenvolvido. 
• O processo continua até que todos os casos 
de uso tenham sido desenvolvidos e o 
sistema esteja completamente construído.