Aula03-1 - Modelagem de Casos de Uso

Prévia do material em texto

Análise Orientada a 
Objetos 
Modelagem Requisitos 
usando Casos de Uso 
Não diga pouco em muitas palavras, mas sim, 
muito em poucas. 
Pitágoras 
Especificação e Modelagem 
de Requisitos 
 Elicitar Requisitos de Produto 
 Especificar casos de uso e validá-los 
 Especificar requisitos não funcionais 
 Analisar e Validar os requisitos 
Requisitos 
p/ Inspeção 
Plano e 
 Casos de Teste 
Casos de Uso e 
Esp. Suplementar 
Regras de 
 Negócio 
Glossário 
Documento de Visão 
 
Analista de Requisitos 
Análise dos Requisitos 
• Trabalha com requisitos incompletos 
• Se preocupa em descobrir problemas 
• Requisitos são enumerados, por exemplo, 
em uma reunião com stakeholders 
– Quais as inconsistências? 
– Quais os conflitos? 
– Tenho que fazer uma nova reunião? 
 
 
Especificação de Requisitos 
de Produto 
• Desenvolvida como uma consequência 
da fase de análise de requisitos 
–Modelo de Casos de Uso 
– Especificação Suplementar 
• Serve como base para casos de teste 
–Requisitos funcionais e não funcionais 
Modelo de Casos de Uso 
• Representação das funcionalidades 
externamente observáveis do sistema e dos 
elementos externos ao sistema que interagem 
com o mesmo. 
• O modelo de casos de uso modela os 
requisitos funcionais do sistema. 
5 
Modelo de Casos de Uso 
• Direciona diversas das tarefas posteriores do 
ciclo de vida do sistema de software. 
– Análise e Projeto 
– Testes 
– Gerência 
– Etc... 
• Além disso, força o sistema ser moldado pelos 
desenvolvedores de acordo com o usuário. 
6 
Componentes do modelo 
• O modelo de casos de uso de um sistema é 
composto de: 
– Casos de uso 
– Atores 
– Relacionamentos entre os elementos anteriores. 
7 
Cliente
Comprar
Modelo de Casos de Uso 
• Ator: 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 com o sistema, ou um evento acontece 
para que o sistema responda. 
8 
Atores 
• Representam 
– o que interage com o sistema 
– tudo que necessita trocar informação com o sistema 
– estão fora do sistema 
• não são descritos em detalhe 
• Diferentes de usuários: 
– usuário usa o sistema 
– ator representa uma certa regra seguida pelo usuário 
– uma mesma pessoa pode aparecer como instância de 
vários atores 
 
Atores 
• Categorias de atores: 
– pessoas (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.) 
10 
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. 
– Uma pessoa pode representar o papel de 
Funcionário de uma instituição bancária que realiza 
a manutenção de um caixa eletrônico, mas também 
pode ser o Cliente do banco que realiza o saque de 
uma quantia. 
• O nome dado a um ator deve lembrar o seu 
papel, ao invés de lembrar quem o representa. 
11 
Atores primários e 
secundários 
• Um ator pode participar de muitos casos de uso. 
• Um caso de uso pode envolver vários atores, o 
que resulta na classificação dos atores em 
primários ou secundários. 
– Um ator primário é aquele que inicia uma seqüência 
de interações de um caso de uso. 
– Atores secundários supervisionam, operam, mantêm 
ou auxiliam na utilização do sistema. 
• Exemplo: para que o Usuário (ator primário) 
requisite uma página a um Browser (sistema), 
um outro ator (secundário) está envolvido, o 
Servidor Web. 
12 
Modelo de Casos de Uso 
• Uma instância de um Ator efetua diversas 
operações no sistema 
• Quando um usuário usa o sistema, efetua um 
sequência de transações relacionadas em um 
diálogo com o sistema 
• Esta sequência é chamada de Caso de Uso 
• Cada Caso de Uso é uma forma específica de usar 
o sistema 
• Cada execução de um caso de uso pode ser visto 
como uma instância do Caso de Uso 
Casos de uso 
• 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. 
• Um modelo de casos de uso típico é formado 
de vários casos de uso. 
14 
Casos de uso 
15 
Um caso de uso representa quem 
faz o que (interage) com o sistema, 
sem considerar o comportamento 
interno do sistema. 
Relacionamentos 
• A UML define diversos tipos de 
relacionamentos no modelo de casos de 
uso: 
– Comunicação 
– Inclusão 
– Extensão 
– Generalização 
16 
Relacionamento de 
comunicação 
• Casos de uso e atores não existem sozinhos. Podem haver 
relacionamentos entre eles. 
• Representa a informação de quais atores estão 
associados a quais casos de uso. 
• O fato de um ator estar associado a um caso de uso 
significa que esse ator interage (troca informações) com o 
sistema. 
• Um ator pode se relacionar com mais de um caso de uso. 
• É o mais comum dos relacionamentos. 
17 
Modelo de Casos de Uso 
• Casos de Uso capturam os requisitos funcionais 
• O conjunto de todos os Casos de Uso especificam 
a funcionalidade completa do sistema 
• Agrupar funcionalidades e chamá-las de Casos de 
Uso facilita o gerenciamento destes requisitos 
durante ciclo de desenvolvimento 
 
Modelo de Casos de Uso 
• Caso de Uso 
–determina um ou mais casos de teste 
• Do conjunto de casos de uso é possível 
derivar o Plano de Testes 
–Garantir adequação do software aos 
requisitos funcionais 
 
De posse dos Casos de 
Uso 
• Verifique 
– se não há requisitos faltando 
– que os desenvolvedores entendem os requisitos 
• Vantagem: 
– apelo visual dos requisitos mais relevantes do 
cliente 
ELABORANDO O MODELO DE 
CASOS DE USO 
Identificando 
• Nenhum sistema existe isoladamente 
– interage com atores humanos e/ou autômatos 
– atores esperam que o sistema se comporte de acordo 
com o previsto 
• Um caso de uso 
– especifica o comportamento de um sistema (ou de 
parte deste) 
– é a descrição de um conjunto de sequências de ações 
– inclui variantes realizadas pelo sistema para produzir 
um resultado observável por um ator 
Identificando Atores 
• Quais grupos precisam de ajuda do sistema para 
realizar suas tarefas? 
• Quais grupos são necessários para a execução das 
funções do sistema? 
• Quais grupos interagem com algum hardware 
externo ou outros sistemas? 
• Quais grupos realizam funções secundárias de 
administração e de manutenção? 
• Existem atividades temporais periódicas? 
Identificando Atores 
• Atores Primários 
– necessidades que são supridas pelo sistema 
• Caixa, cliente 
• Atores de suporte 
– provem serviços para o sistema 
• Agente de cartão de crédito 
• Primeiro: encontrar os atores primários 
– enumere as necessidades para cada ator 
Identificando Atores 
Exemplo 
Uma loja de CDs possui discos para venda. Um cliente 
pode comprar uma quantidade ilimitada de discos para 
isto ele deve se dirigir à loja. A loja possui um atendente 
cuja função é atender os clientes durante a venda dos 
discos. A loja também possui um gerente cuja função é 
administrar o estoque para que não faltem discos. Além 
disso é ele quem dá folga ao atendente, ou seja, ele 
também atende os clientes durante a venda dos discos. 
Casos de Uso: 
função – transação/serviço 
• Sequência de ações, 
executada pelo 
sistema, que gera um 
resultado 
– De valor observável 
– E para um ou mais 
atores 
Função 
Procedimento 
computacional 
Identificando Casos de 
Uso 
• Em geral,é difícil decidir entre um ou vários Casos de 
Uso 
• Por exemplo, seria Caso de Uso: 
– Inserir cartão em um Caixa Automático? 
– Digitar a senha? 
– Receber o cartão de volta? 
• Casos de Uso devem ser organizados para evitar 
– Redundância 
– Conflitos 
– Ambiguidades 
Identificando Casos de 
Uso 
• Deve representar valor observável para ator 
• Pode-se determinar 
– Devido a interações Ator x Sistema 
• sequência de ações com o sistema que resultam 
valores para atores 
– Devido a necessidades de um Ator 
• satisfaz um objetivo particular de um ator que o 
sistema deve prover 
Identificando Casos de 
Uso 
• Procedimentos Iniciais 
– Escolha a fronteira do sistema 
– Identifique os atores primários 
• aqueles cujas necessidades serão supridas pelo sistema 
– Defina Casos de Uso que satisfaça as necessidades 
dos atores primários 
• um caso de uso para cada necessidade 
Identificando Casos de 
Uso 
• Traçar fronteira conceitual 
– Identificar o que está fora e o que está dentro do 
sistema 
• Exemplo: ponto de vendas 
– Fora 
• Cliente, Caixa, Agente de Cartão de Crédito 
– Dentro 
• Venda, Emissão Recibo, Estoque, .... 
Identificando Casos de 
Uso 
• O que está dentro do sistema: 
– é responsável por executar seu comportamento 
• O que está fora: 
– o contexto do sistema 
– o ambiente onde o sistema existe 
– determinam as necessidades que o sistema deve 
atender 
 
Identificação de casos de 
uso 
• A partir da lista (inicial) de atores, deve-se 
passar à identificação dos casos de uso. 
• Nessa identificação, pode-se distinguir 
entre dois tipos de casos de uso 
– Primário: representa os objetivos dos atores. 
– Secundário: aquele que não traz benefício 
direto para os atores, mas que é necessário 
para que sistema funcione adequadamente. 
32 
Casos de uso primários 
• Perguntas úteis: 
– Quais são as necessidades e 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) caso(s) de uso para 
atendê-lo? 
• Outras técnicas de identificação: 
– Caso de uso “oposto”. 
– Caso de uso que precede a outro caso de uso. 
– Caso de uso relacionado a uma condição interna. 
– Caso de uso que sucede a outro caso de uso. 
– Caso de uso temporal. 
33 
Casos de uso secundários 
• Estes se encaixam nas seguintes categorias: 
– Manutenção de cadastros. 
– Manutenção de usuários. 
– Manutenção de informações provenientes de 
outros sistemas. 
• Importante: Um sistema de software não existe 
para cadastrar informações, nem tampouco 
para gerenciar os seus usuários. 
– O objetivo principal é produzir algo de valor para o 
ambiente no qual ele está implantado. 
34 
Identificando Casos de Uso 
Exemplo 
Uma loja de CDs possui discos para venda. Um cliente 
pode comprar uma quantidade ilimitada de discos para 
isto ele deve se dirigir à loja. A loja possui um atendente 
cuja função é atender os clientes durante a venda dos 
discos. A loja também possui um gerente cuja função é 
administrar o estoque para que não faltem discos. Além 
disso é ele quem dá folga ao atendente, ou seja, ele 
também atende os clientes durante a venda dos discos. 
Achando Casos de Uso 
• Que funções o ator requer do sistema? 
O que o ator necessita fazer? 
• O ator tem que ler, criar, destruir, modificar ou 
armazenar algum tipo de informação do sistema? 
• O ator tem que ser notificado sobre eventos do 
sistema, ou o ator necessita notificar o sistema sobre 
alguma coisa? 
– o que estes eventos representam em termos de 
funcionalidade 
 
Achando Casos de Uso 
• Pode o trabalho diário do ator ser simplificado ou 
mais eficiente através da incorporação de novas 
funções? 
• Outras questões 
– Que entradas/saídas o sistema necessita? 
• De onde vem e para onde vão? 
– Quais os maiores problemas com a implementação 
atual (quando existir automática ou a manual) 
 
Definindo os Casos de Uso 
• Nomeie os casos de uso como uma necessidade 
– Registrar venda ( um necessidade do caixa) 
• Descreva cada caso de uso 
– primeiro uma descrição simplificada 
– complete esta descrição 
• analise o conjunto de casos de uso e faça uma organização 
• Não considere a Interface Homem-máquina 
– isto é implementação 
• Foco : o que fazer 
Identificando os 
relacionamentos 
Uma loja de CDs possui discos para venda. Um cliente 
pode comprar uma quantidade ilimitada de discos para 
isto ele deve se dirigir à loja. A loja possui um atendente 
cuja função é atender os clientes durante a venda dos 
discos. A loja também possui um gerente cuja função é 
administrar o estoque para que não faltem discos. Além 
disso é ele quem dá folga ao atendente, ou seja, ele 
também atende os clientes durante a venda dos discos. 
Identificando os 
relacionamentos 
 
Descrições narrativas 
• Cada caso de uso é definido através da 
descrição narrativa das interações que 
ocorrem entre o(s) elemento(s) externo(s) e 
o sistema. 
• Há várias formas de se descrever casos de 
uso. 
– Grau de abstração 
– Formato 
– Grau de detalhamento 
41 
Exemplo de descrição 
contínua 
• 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 Sistema 
fornece a quantia desejada e imprime o 
recibo para o Cliente. 
42 
Exemplo de descrição 
numerada 
1. Cliente insere seu cartão no caixa eletrônico. 
2. Sistema apresenta solicitação de senha. 
3. Cliente digita senha. 
4. Sistema exibe menu de operações 
disponíveis. 
5. Cliente indica que deseja realizar um saque. 
6. Sistema requisita quantia a ser sacada. 
7. Cliente retira a quantia e recibo. 
43 
Exemplo de narrativa 
particionada 
Cliente Sistema 
Insere seu cartão no caixa eletrônico. 
 
Digita senha. 
 
Solicita realização de saque. 
 
 
Retira a quantia e o recibo. 
 
Apresenta solicitação de senha. 
 
Exibe operações disponíveis. 
 
Requisita quantia a ser sacada. 
44 
Detalhamento 
• O grau de detalhamento a ser utilizado na 
descrição de um caso de uso também pode 
variar. 
• Um caso de uso sucinto descreve as 
interações sem muitos detalhes. 
• Um caso de uso expandido descreve as 
interações em detalhes. 
45 
Grau de abstração 
• O grau de abstração de um caso de uso diz 
respeito à existência ou não de menção à 
tecnologia a ser utilizada na descrição 
deste caso de uso. 
• Um caso de uso essencial não faz menção à 
tecnologia a ser utilizada. 
• Um caso de uso real apresenta detalhes da 
tecnologia a ser utilizada na implementação 
deste caso de uso . 
46 
Grau de abstração 
1) Cliente fornece sua identificação. 
2) Sistema identifica o usuário. 
3) Sistema fornece operações disponíveis. 
4) Cliente solicita o saque de uma determinada quantia. 
5) Sistema fornece a quantia desejada da conta do Cliente. 
6) Cliente recebe dinheiro e recibo. 
47 
 Exemplo de descrição essencial (e numerada): 
Cenários 
• Um caso de uso tem diversas maneiras de 
ser realizado. 
• Um cenário é a descrição de uma das 
maneiras pelas quais um caso de um pode 
ser realizado. 
• Um cenário também é chamado de 
instância de um caso de uso. 
• Normalmente há diversos cenários para um 
mesmo um caso de uso. 
• Úteis durante a modelagem de interações. 
48 
Cenários 
 Um Cliente telefona para a empresa. 
 Um Vendedor atende ao telefone. 
 Cliente declara seu desejo de fazer um pedido de compra. 
 Vendedor pergunta a forma de pagamento. 
 Cliente indica que vai pagar com cartão de crédito. 
 Vendedor requisita o número do cartão, a data de expiração e o 
endereço de entrega. 
 Vendedor pede as informações do primeiro item. 
 Cliente fornece o primeiroitem. 
 Vendedor pede as informações do segundo item. 
 Cliente fornece o segundo item 
 Vendedor pede as informações do terceiro item 
 Cliente e informa o terceiro item. 
 Vendedor informa que o terceiro item está fora de estoque. 
 Cliente pede para que O Vendedor feche o pedido somente com os dois 
primeiros itens. 
 Vendedor fornece o valor total, a data de entrega e uma 
identificação do pedido. 
 Cliente agradece e desliga o telefone. 
 Vendedor contata a Transportadora para enviar o pedido de O Cliente. 
49 
Caso de Uso: um exemplo 
• Caso de Uso: Registrar Venda 
• Descrição Breve 
– O Caixa necessita efetuar a venda de um conjunto de itens 
selecionados pelo cliente. Deve atualizar estoque, registrar a 
venda e emitir o recibo 
• Descrição Informal 
– Um cliente chega no caixa com itens a comprar. O Caixa 
registra cada item usando o Sistema. O sistema apresenta o 
total parcial e a descrição de cada item. O cliente entra com a 
informação de pagamento, que o sistema valida e registra. O 
sistema atualiza o estoque. O cliente recebe um recibo e parte 
com os itens adquiridos 
Casos de Uso – Detalhado 
• Ator primário: o que inicia a ocorrência do caso de uso 
– Caixa 
• Interessados :interessados em validar o Caso de Uso 
– Caixa 
– Cliente 
– Gerente 
• Pré-condições: o que deve ser verdade antes de iniciar o 
caso de uso 
– O caixa está identificado e autenticado 
Casos de Uso – Detalhado 
• Pós-condições: o que deve ser verdade após o 
término com sucesso do caso de uso 
– A venda está registrada 
– O estoque foi atualizado 
– Recibo emitido 
– As comissões foram calculadas e armazenadas 
• descrição ainda informal 
 
 
Casos de Uso - Descrição 
Detalhada 
• Fluxo Normal: descreve a história principal de 
sucesso do caso de uso 
– Número sequência. Agente + verbo + complemento 
• Ex: Cadastrar Cliente 
1. O cliente fornece seus dados 
2. O sistema verifica que o cliente não está cadastrado 
3. O sistema adiciona novo cliente 
4. O sistema informa que o cadastro foi efetuado com sucesso 
 
Casos de Uso - Descrição 
Detalhada 
• Fluxos Alternativos ou Extensões: indicam outros 
cenários (tanto de sucesso como de insucesso) 
– Caso <número>: <Descrição do caso alternativo> 
– Número sequência . Agente + verbo + complemento ; 
– Finalizar caso de uso ou retornar ao passo... 
 
Casos de Uso – Descrição 
• Cadastrar Cliente - Fluxos Alternativos 
• Caso 1: Cliente já está cadastrado 
2.1 - O sistema verifica que o cliente está cadastrado 
– número da seq. onde se inicia a variante 
2.2 - O sistema informa que já está cadastrado 
2.3 - Finalizar caso de uso 
Casos de Uso - Descrição 
Detalhada 
• Requisitos Especiais: requisitos não 
funcionais, atributos de qualidade ou 
restrições 
– Usar um leitor ótico para o código de barras 
Casos de Uso – Descrição 
• Registrar Venda 
• Fluxo Normal 
1. O cliente chega com os itens selecionados no caixa 
2. O Caixa inicia uma venda 
3. Para cada item (trazido pelo Cliente) 
1. Adicionar Item de venda 
4. O caixa finaliza a venda 
5. O sistema totaliza a compra e informa o total 
6. O cliente efetua o pagamento 
7. O Caixa registra o pagamento 
8. O sistema da baixa no estoque dos itens vendidos 
9. O sistema emite o recibo 
10. ...................... 
 
 
ORGANIZANDO O MODELO 
DE CASOS DE USO 
Organizando 
• Organize os atores semelhantes em uma 
hierarquia de generalização/especialização 
• Especifique as associações de cada ator para os 
Casos de Uso 
Diagrama de Casos de 
Uso 
Pessoa Fisica Pessoa Juridica
Cliente
Realizar transacao com Cartao de 
Credito
Agente de Cartao 
de Credito
Processar Conta do Cliente
Instituicao 
Financeira
Diagramas de Casos de 
Uso 
• São secundários 
• O importante é o texto descrevendo os Casos de 
Uso 
• Apoiam a organização 
– Pacotes de Casos de Uso 
• Agregam casos de uso funcionalmente coesos 
– Visualizam relacionamentos entre 
• casos de uso 
• atores 
Revisando Casos de Uso 
• Todos os atores envolvidos com um Caso de Uso 
– Estão se comunicando? 
– Aparecem na sua descrição? 
– Algum não aparece? 
• Tem ator ou Caso de Uso sem nenhuma associação? 
– Há algo errado... 
• Tem algum requisito funcional conhecido não 
tratado pelos Casos de Uso 
– Está incompleto... 
 
Revisando Casos de Uso 
• Estruturar modelo de Casos de Uso 
• Estabelecer relacionamentos entre Casos de 
Uso 
– Trechos similares em mais de um caso de Uso 
• “Inclusão” 
– A descrição do Caso de Uso está muito complexa 
• “Extensão” 
• “Generalização” 
Inclusão 
• Caso de uso base incorpora explicitamente 
comportamento de outro Caso de Uso em ponto 
específico 
• Representado como uma dependência (seta 
tracejada) para o Caso de Uso incluído 
• Se o Caso de Uso incluído muda o Base, 
necessita ser revisto 
– <<include>> 
 
 
Inclusão 
• Similaridades descritas em mais de um caso de Uso  eliminar 
redundâncias 
 
Caso de uso Base 
Caso de Uso Inclusão 
<<include>> 
Executando uma instância do Caso de uso Base 
Inclusão 
• Caso de Uso: Venda 
• Fluxo Normal 
1. ........ 
2. ......... 
3. Incluir “Pagar” 
4. Finalizar Venda 
Inclusão 
Venda
Pagar
Cliente
<<include>> 
Extensão 
• Um Caso de Uso incorpora implicitamente o 
comportamento de outro caso de uso 
• Apenas em circunstâncias específicas (condição) 
o caso de uso estendido é incorporado ao caso 
de uso base 
• Utilizado para modelar comportamento 
excepcional do sistema 
– Exceções 
Extensão 
• Representado como uma dependência 
– seta tracejada para o Caso de Uso Base 
• Se o Caso de Uso base muda o Caso de Uso 
estendido, necessita ser revisto 
– <<extends>> 
Extensão 
• A descrição do Caso de Uso está muito complexa 
 
Caso de uso Base 
Caso de Uso Extensão 
<<extends>> 
Executando uma instância do Caso de uso Base 
Ponto de 
Extensão 
Extensão 
• Caso de Uso: Efetuar Troca 
• Fluxo Normal 
1. O Cliente chega com produto para troca 
2. O Caixa prepara cupom de troca (devolver dinheiro) 
3. Reportar ao Estoque 
4. Finalizar Operação 
– Ponto de extensão : Devolver dinheiro 
Extensão 
Devolver DinheiroEfetuar Troca
<<extends>> 
Generalização de Atores 
• Quando dois ou mais atores podem se 
comunicar com o mesmo conjunto de 
casos de uso 
• Um filho (herdeiro) pode se comunicar 
com todos os casos de uso que seu pai 
se comunica. 
• Dica: coloque os herdeiros embaixo 
Generalização de Casos 
de Uso 
• Similar a generalização entre Classes 
• O caso de uso filho herda 
– o significado do caso de uso pai 
– o comportamento 
• O comportamento do Caso de Uso filho 
normalmente é redefinido 
• O Caso de Uso filho pode ser usado no lugar do 
pai 
 
Generalização de Casos 
de Uso 
• A descrição do Caso de Uso está muito complexa 
 Executando uma instância do Caso de uso Filho 
Caso de uso Pai 
Caso de Uso Filho 
Generalização de Casos 
de Uso 
Pagar a Dinheiro
Pagar com Cartão
Cliente Pagar
base 
derivado 
Generalização de Casos 
de Uso 
• Ator: Cliente 
• Fluxo Normal 
1. Esse caso de Uso começa quando o cliente deseja efetuar pagamento 
2. O Cliente registra o documento de cobrança 
3. O Cliente informa a opção desejada 
1. Se pagto a dinheiro – executar subseção Pagar a dinheiro 
2. Se pagto com cartão de crédito- executar subseção Pagar com Cartão 
4. O sistema registra o pagamento 
5. O sistema emite o recibo 
Subseção – Pagar a Dinheiro 
1. O Cliente coloca o dinheiro em um envelope e lacra 
2. O Cliente informa o numero do envelope ao sistema 
3. O cliente deposita o envelope 
4. ....... 
 
 
Identificando 
Generalização de Atores 
Uma loja de CDs possui discos para venda. Um cliente 
pode comprar uma quantidade ilimitada de discos para 
isto ele deve se dirigir à loja. A loja possui um atendente 
cuja função é atender os clientes durante a venda dos 
discos. A loja também possui um gerente cuja funçãoé 
administrar o estoque para que não faltem discos. Além 
disso é ele quem dá folga ao atendente, ou seja, ele 
também atende os clientes durante a venda dos discos. 
Identificando 
Generalização de Atores 
Identificando Generalização 
de Casos de Uso 
• Novos requisitos: 
– Vendas podem ser à vista ou a prazo. Em ambos, o estoque é 
atualizado e uma nota fiscal, entregue ao consumidor. 
– No caso de uma venda à vista, clientes cadastrados na loja e que 
compram mais de 5 CDs de uma só vez ganham um desconto de 1% 
para cada ano de cadastro. 
– No caso de uma venda a prazo, ela pode ser parcelada em 2 
pagamentos com um acréscimo de 20%. Vendas a prazo podem ser 
pagas no cartão ou no boleto. Para pagamento com boleto, são gerados 
boletos bancários que são entregues ao cliente e armazenados no 
sistema para lançamento posterior no caixa. Para pagamento com 
cartão, os clientes com mais de 10 anos de cadastro na loja ganham o 
mesmo desconto das compras a vista. 
Identificando Generalização 
de Casos de Uso 
 
Identificando Generalização 
de Casos de Uso 
• Novos requisitos: 
– Vendas podem ser à vista ou a prazo. Em ambos, o estoque é 
atualizado e uma nota fiscal, entregue ao consumidor. 
– No caso de uma venda à vista, clientes cadastrados na loja e que 
compram mais de 5 CDs de uma só vez ganham um desconto de 1% 
para cada ano de cadastro. 
– No caso de uma venda a prazo, ela pode ser parcelada em 2 
pagamentos com um acréscimo de 20%. Vendas a prazo podem ser 
pagas no cartão ou no boleto. Para pagamento com boleto, são gerados 
boletos bancários que são entregues ao cliente e armazenados no 
sistema para lançamento posterior no caixa. Para pagamento com 
cartão, os clientes com mais de 10 anos de cadastro na loja ganham o 
mesmo desconto das compras a vista. 
Identificando Generalização 
de Casos de Uso 
 
Identificando 
dependência: extensão 
 
• Novos requisitos: 
– No caso de uma venda à vista, clientes 
cadastrados na loja e que compram mais de 5 
CDs de uma só vez ganham um desconto de 1% 
para cada ano de cadastro. 
– No caso de uma venda a prazo... 
– ...Para pagamento com cartão, os clientes com 
mais de 10 anos de cadastro na loja ganham o 
mesmo desconto das compras à vista. 
Identificando 
dependência: extensão 
 
 
Identificando 
dependência: inclusão 
• Novos requisitos: 
–Para efetuar vendas ou administrar 
estoque, atendentes e gerentes terão 
que validar suas respectivas senhas de 
acesso ao sistema. 
Identificando 
dependência: inclusão 
 
Elemento Opcional: 
Fronteira 
• Serve para definir a área de atuação do sistema 
Fronteira 
do sistema 
Descrição dos Casos de 
Uso 
Descrição dos Casos de 
Uso 
Descrição dos Casos de 
Uso 
Descrição dos Casos de 
Uso 
Descrição dos Casos de 
Uso 
Descrição dos Casos de 
Uso 
CONSTRUÇÃO DO MODELO 
DE CASOS DE USO 
 
Construção do diagrama de 
casos de uso 
• Em sistemas complexos, representar todos os casos de 
uso do sistema em um único DCU talvez o torne um 
tanto ilegível. 
• Alternativa: criar vários diagramas, de acordo com as 
necessidades de visualização. 
– Diagrama exibindo um caso de uso e seus relacionamentos; 
– Diagrama exibindo todos os casos de uso para um ator; 
– Diagrama exibindo todos os casos de uso a serem 
implementados em um ciclo de desenvolvimento. 
96 
Documentação dos atores 
• Uma breve descrição para cada ator deve 
ser adicionada ao modelo de casos de uso. 
• O nome de um ator deve lembrar o papel 
desempenhado pelo mesmo no sistema. 
97 
Documentação dos casos 
de uso 
• UML não define uma estruturação específica a 
ser utilizada na descrição do formato expandido 
de um caso de uso. 
• A seguir, é apresentada uma sugestão de 
descrição. 
– A equipe de desenvolvimento deve utilizar o 
formato de descrição que lhe for realmente útil. 
98 
Documentação dos casos 
de uso 
• Nome 
• Descrição 
• Identificador 
• Importância 
• Sumário 
• Ator Primário 
• Atores Secundários 
• Pré-condições 
• Fluxo Principal 
• Fluxos Alternativos 
• Fluxos de Exceção 
• Pós-condições 
• Regras do Negócio 
• Histórico 
• Notas de 
Implementação 
 
99 
Documentação dos casos 
de uso 
100 
 A descrição do modelo deve ser mantida no 
nível mais simples possível... 
DOCUMENTAÇÃO ASSOCIADA 
AO MODELO DE CASOS DE 
USO 
 
Documentação dos casos 
de uso 
• O modelo de casos de uso força o 
desenvolvedor a pensar em como os agentes 
externos interagem com o 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 fazem parte do documento de 
requisitos. 
102 
Regras do negócio 
• São políticas, condições ou restrições que devem 
ser consideradas na execução dos processos 
existentes em uma organização. 
• Descrevem a maneira pela qual a organização 
funciona. 
• Estas regras são identificadas e documentadas no 
chamado modelo de regras do negócio. 
• A descrição do modelo de regras do negócio 
pode ser feita utilizando-se texto informal, ou 
alguma forma de estruturação. 
103 
Regras do negócio 
• Alguns exemplos de regras do 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 do banco não pode retirar mais de 
R$ 1.000 por dia de sua conta. 
– Os pedidos para um cliente não especial devem 
ser pagos antecipadamente. 
104 
Regras do negócio 
• Regras do negócio normalmente têm 
influência sobre um ou mais casos de uso. 
• Os identificadores das regras do negócio 
devem ser adicionados à descrição do caso 
de uso. 
– Utilizando a seção “regras do negócio” da 
descrição do caso de uso. 
105 
Regras do negócio 
• Possível formato para documentação de 
uma regra de 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 
106 
Requisitos de desempenho 
• Conexão de casos de uso a requisitos de 
desempenho. 
Identificador 
do caso de uso 
Freqüência 
da utilização 
Tempo 
máximo esperado 
... 
CSU01 5/mês Interativo … 
CSU02 15/dia 1 segundo … 
CSU03 60/dia Interativo … 
CSU04 180/dia 3 segundos … 
CSU05 600/mês 10 segundos … 
CSU07 500/dia durante 
10 dias seguidos. 
10 segundos ... 
107 
MODELO DE CASOS DE 
USO NO PROCESSO DE 
DESENVOLVIMENTO 
 
Modelo de casos de uso no 
processo de 
desenvolvimento 
• A identificação da maioria dos atores e casos 
de uso é feita na fase de concepção. 
• A descrição dos casos de uso considerados 
mais críticos começa já nesta fase, que termina 
com 10% a 20% do modelo de casos de uso 
completo. 
• Ao final da fase de elaboração 80% do modelo 
de casos de uso está construído. 
– descrição feita até em um nível de abstração 
essencial. 
109 
Modelo de casos de uso no 
processo de 
desenvolvimento 
• Na fase de construção, casos de uso formam 
uma base natural através da qual podem-se 
realizar as iterações do 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. 
110 
Modelo de casos de uso no 
processo de 
desenvolvimento 
• Este tipo de desenvolvimento é chamado de 
desenvolvimento dirigido a casos de uso. 
• Deve-se considerar os casos de uso mais importantes 
primeiramente. 
• Cantor propõe uma classificação em função do risco de 
desenvolvimento e das prioridades estabelecidas pelo 
usuário. 
1) Risco alto e prioridade alta 
2)Risco alto e prioridade baixa 
3) Risco baixo e prioridade alta 
4) Risco baixo e prioridade baixa 
111 
Modelo de casos de uso no 
processo de 
desenvolvimento 
• Considerando-se essa categorização, um caso 
de uso não tão importante não será 
contemplado nas iterações iniciais. 
– Atacar o risco maior mais cedo... 
• A descrição expandida de um caso de uso pode 
ser deixada para a iteração na qual este deve 
ser implementado. 
– evita perda de tempo inicial no detalhamento. 
– estratégia mais adaptável aos requisitos voláteis. 
112 
Casos de uso nas atividades 
de análise e projeto 
• Na fase de análise, descrições de casos de 
uso devem capturar os requisitos funcionais 
do sistema e ignorar aspectos de projeto, 
como a interface gráfica com o usuário 
(essenciais). 
• No projeto, adicionando mais detalhes 
(reais) 
113 
Procedimento 
1) Identifique os atores e casos de uso na fase de 
concepção. 
2) Na fase de elaboração: 
– desenhe o(s) diagrama(s) de casos de uso; 
– escreva os casos de uso em um formato de alto 
nível e essencial. 
– ordene a lista de casos de uso de acordo com 
prioridade e risco. 
3) Associe cada grupo de casos de uso a uma 
iteração da fase de construção. 
– grupos mais prioritários e arriscados nas iterações 
iniciais. 
114 
Procedimento 
4) Na i-ésima iteração da fase de construção: 
– Detalhe os casos de uso do grupo associado a 
esta iteração (nível de abstração real). 
5) Implemente estes casos de uso. 
115 
Casos de uso e outras 
atividades do 
desenvolvimento 
• 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. 
• Documentação do usuário 
– manuais e guias do usuário podem ser construídos 
com base nos casos de uso. 
116 
PONTOS PRINCIPAIS..... 
Dicas/Sugestões 
• Todos os Casos de Uso deverão representar algum 
comportamento distinto e identificável 
• Nomeie um comportamento que seja único, identificável 
e razoavelmente atômico 
• Faça a fatoração de comportamento comum, obtendo-se 
este comportamento de outros casos de uso (inclusão) 
• Faça a fatoração de variantes, aplicando esse 
comportamento a outros casos de uso que o estendem 
(extensão) 
• Descreva o fluxo de eventos de maneira suficientemente 
clara para que alguém de fora seja capaz de compreendê-
lo com facilidade 
– Especifique um conjunto mínimo de cenários explicitando a 
semântica normal e variante do Caso de Uso 
 
Dicas e Sugestões 
• Aos clientes, mostre somente 
–Casos de Uso importantes para a 
compreensão do comportamento do sistema 
(ou da parte sendo modelada) 
– Somente os atores relacionados com esses 
Casos de Uso 
Exercício: o Blog 
• Um blog tem um título e uma data de criação e 
além disso é um conjunto de conteúdos. 
• Estes conteúdos (mensagens) podem ser notas 
ou comentários sobre as notas. Tanto notas 
quanto comentários têm características comuns 
como o texto e a data de sua criação. 
• Todo usuário possui: 
– E-mail (deve ser único, ou seja, não há mais de um 
usuário com o mesmo e-mail) 
O Blog deve... 
• Permitir a criação de blogs 
• Permitir a utilização de blogs 
– Qualquer usuário pode ler conteúdos 
– Somente o dono do blog pode criar notas 
– Qualquer usuário pode criar comentários. Para criar 
um comentário o usuários precisa ler as notas. 
– Somente o dono do blog pode remover conteúdos. 
Para remover um conteúdo ele precisará ler o 
conteúdo. Caso ele remova um comentário, o autor 
do comentário deve ser notificado por e-mail. 
Exercício 
• Elaborar o Modelo de Casos de Uso para um site de 
Vendas Online (Diagrama e a especificação do UC) 
– Usuário se cadastra no sistema 
– Usuário pesquisa produtos no site 
– Usuário seleciona produtos incluindo no “carrinho de compras”. 
– Usuário visualiza produtos no carrinho, podendo excluir algum 
– Usuário finaliza a venda (precisa estar logado) 
• Usuário deve informar endereço entrega 
• Usuário pode pagar com boleto bancário ou cartão 
– Usuário faz login no sistema 
123 
O Blog deve... 
• Permitir a criação de blogs 
• Permitir a utilização de blogs 
– Qualquer usuário pode ler 
conteúdos 
– Só o dono do blog pode criar notas 
– Qualquer usuário pode criar 
comentários. 
• Para criar um comentário o 
usuários precisa ler as notas. 
– Somente o dono do blog pode 
remover conteúdos. 
• Para remover um conteúdo ele 
precisará ler o conteúdo. 
• Caso ele remova um comentário, o 
autor do comentário deve ser 
notificado por e-mail. 
1. Usuário cria Blog (conteúdo) 
2. Usuário lê conteúdo (nota/ 
comentário) 
3. Usuário criar comentário 
(precisa ler ) 
4. Dono cria notas 
5. Dono remove conteúdo 
(nota/comentário). 
– Precisa ler. 
– Remoção de comentário 
comunica usuário