Casos de Usos

Casos de uso

Um caso de uso representa quem

faz o que (interage) com o sistema,
sem considerar o comportamento
interno do sistema.

2
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

3
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.

4
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 informa quantia a sacar
8. Sistema registra o saque e coloca a quantia de
dinheiro na gaveta, emitindo um recibo.
5
9. O cliente retira a quantia e recibo.
 Exemplo de descrição numerada

Cliente Sistema
Insere seu cartão no caixa
eletrônico. Apresenta solicitação de
senha.
Digita senha.
Exibe operações disponíveis.
Solicita realização de saque.
Requisita quantia a ser
sacada.
Retira a quantia e o recibo.

6
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.

7
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 .

8
 Grau de abstração
◼ Exemplo de descrição essencial (e
numerada):
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.
9
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. 10
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 primeiro item.
• 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.
11
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 seqüê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
seqüência de interações como o sistema, ou um
evento acontece para que o sistema responda.

12
 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.)

13
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. 14
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. 15
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. 16
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. 17
Identificação dos elementos do
modelo de casos de uso
• Os atores e os casos de uso são identificados a
partir de informações coletadas na fase de
levantamento de requisitos do sistema.
• Durante esta fase, os analistas devem identificar
as atividades do negócio relevantes ao sistema
a ser construído.
• Não há uma regra geral que indique quantos
casos de uso são necessários para descrever
completamente um sistema.
• A quantidade de casos de uso a ser utilizada
depende completamente da complexidade do
sistema. 18
Identificação de atores
• Fontes e os destinos das informações a serem processadas
são atores em potencial.
• uma vez que 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.

19
Identificação de atores
• Perguntas úteis:
• Que órgãos, empresas ou pessoas irão utilizar o
sistema?
• Que outros sistemas irão se comunicar com o
sistema a ser construído?
• Alguém deve ser informado de alguma
ocorrência no sistema?
• Quem está interessado em um certo requisito
funcional do sistema?
• O desenvolvedor deve ainda continuar a pensar
sobre atores quando passar para a identificação 20
dos casos de uso.
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.

21
Relacionamentos
• Casos de uso e atores não existem sozinhos. Pode
haver relacionamentos entre.
• A UML define diversos de relacionamentos no
modelo de casos de uso:
• Comunicação
• Inclusão
• Extensão
• Generalização

22
Relacionamento de
comunicação
• Existe somente entre casos de uso.
• Analogia útil: rotina.
• Em uma linguagem de programação, instruções
podem ser agrupadas em uma unidade lógica
chamada rotina.
• Sempre que essas instruções devem ser
executada, a rotina correspondente é chamada.
• Quando dois ou mais casos de uso incluem uma
seqüência de interações comum, esta seqüência
comum pode ser descrita em um outro caso de
uso.
23
Relacionamento de
comunicação
• Este caso de uso comum:
• evita a descrição de uma mesma seqüência de
interações mais de uma vez e
• torna a descrição dos casos de uso mais simples.
• Um exemplo: considere um sistema de controle de
transações bancárias. Alguns casos de uso deste
sistema são Obter Extrato, Realizar Saque e
Realizar Transferência.
• Há uma seqüência de interações em comum: a
seqüência de interações para validar a senha do cliente.

24
Diagrama de casos de uso
(DCU)
• Representa graficamente os atores, casos de uso
e relacionamentos entre os elementos.
• Tem o objetivo de ilustrar em um nível alto de
abstração quais elementos externos interagem
com que 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.

25
Notação
• A notação para um ator em um DCU é a figura de
um boneco
• com o nome do ator definido abaixo desta figura.
• Cada caso de uso é representado por uma elipse.
• O nome do caso de uso é posicionado abaixo ou dentro
da elipse.
• Um relacionamento de comunicação é
representado por um segmento de reta ligando
ator e caso de uso.
• Pode-se também representar a fronteira do
sistema em um diagrama de casos de uso.
26
Exemplo (Notação)

Ator
Caso de uso

Reservar Livro

Usuário
Relacionamento
de comunicação

27
Exemplo (Notação)

Sistema de Vendas de
Livros por Correio

Vendedor

Realizar Pedido

Cliente

Empresa Transportadora
28
Construção do diagrama de casos de
uso
• Os diagramas de casos de uso devem servir para
dar suporte à parte escrita do modelo,
fornecendo uma visão de alto nível.
• Quanto mais fácil for a leitura do diagrama
representando casos de uso, melhor.
• Se o sistema sendo modelado não for tão
complexo, pode ser criado um único DCU.
• Este diagrama permite dar uma visão global e de
alto nível do sistema.
29
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. 30
Relação de Inclusão
• Usados para dividir partes de um fluxo de
trabalho para o qual o caso de uso base só
depende do resultado, não do método para
alcançar o resultado.
• Faça o particionamento se ele simplificar o
entendimento do caso de uso base (o
comportamento detalhado está "oculto") ou se o
comportamento particionado puder ser
reutilizado em outros casos de uso base.
Relação de Inclusão
Como fazer a inclusão?
• Após descrever o fluxo de trabalho dos casos de
uso de negócios, procure por comportamento
comum a vários fluxos de trabalho ou que não
precisam ser visto em detalhes para entender a
principal finalidade de um caso de uso de negócio
• O fluxo de trabalho inteiro descrito no caso de
uso de negócios incluído é incorporado.
• Um caso de uso de negócios de inclusão é sempre
abstrato e não precisa ter um relacionamento
com um ator de negócios.
Exemplo de Inclusão
Recomendações
• Reconsidere os modelos que têm mais de um
nível de relacionamentos de inclusão. As camadas
desse tipo dificultam o entendimento dos
modelos, mesmo que estejam corretas em todos
os outros aspectos.
• Ocultar casos de uso de inclusão e
relacionamentos de inclusão ao explicar o modelo
com pessoas que têm pouca ou nenhuma
experiência com a técnica de modelagem de
casos de uso.
Relação de Extensão
• Adicionam opcionalmente, ou condicionalmente,
um fluxo a um caso de uso de negócios que já
esteja completo.
• Exemplo,
• A Administração de Bagagem Especial é inserida no
Check-in Individual nos casos em que o passageiro
deve ir ao balcão de bagagem especial.
• A extensão é condicional, o que significa que sua
execução depende do que tiver acontecido
durante a execução do caso de uso base.
Relação de Extensão
Como fazer a Extensão
• Após descrever o fluxo de trabalho de
um caso de uso de negócios, localize o
comportamento condicional ou
opcional.
• Descreva-o em um caso de uso de
negócios separado que é uma extensão
do caso de uso de negócios original.
Recomendações
• Os casos de uso de negócios que estão sendo
estendidos devem ser significativos e completos
por si só, mesmo que o fluxo de trabalho do caso
de uso de negócios adicionado não seja
executado.
• A maioria dos casos de uso de negócios de
extensão não pode ser executada sozinha
Use extensão para modelar...
• o comportamento condicional ou opcional em um
caso de uso de negócios, descrevendo os fluxos de
trabalho em casos de uso diferentes, onde o
comportamento condicional ou opcional seja
diferente do comportamento obrigatório.
• um fluxo de trabalho complexo que ocorre raramente.
• um subfluxo separado que só é executado sob certas
condições.
• vários casos de uso de negócios diferentes que podem
ser inseridos em um determinado ponto (a ordem é
controlada pelo ator de negócios).
Exemplo
Generalização de Atores
• Vários atores de negócios podem desempenhar o
mesmo papel em um caso de uso de negócios
específico.
• O papel compartilhado é modelado como um ator
de negócios, herdado pelos dois atores de
negócios originais.
Generalização de Casos de Uso
• Usadas para mostrar que os fluxos de trabalho
compartilham a estrutura, a finalidade e os
comportamentos.
• Um caso de uso pai pode ser especializado em um ou mais
casos de uso filho que representam formas mais
específicas do pai.
Como usar ?
• Após descrever o fluxo de trabalho de cada CSU de
negócio, encontre as estruturas e o comportamento
comuns a vários CSU de negócios.
• Para evitar a descrição do mesmo fluxo de trabalho
várias vezes, coloque o comportamento comum em
um CSU de negócios próprio.
• Uma instância de CSU que executa um CSU filho
seguirá o fluxo de eventos descritos para o CSU pai,
inserindo um comportamento adicional e
modificando o comportamento da maneira definida
no fluxo de eventos do CSU filho.
Exemplo
Fazer uma Chamada Local Fazer uma Chamada Interurbana
1. O chamador tira o fone do 1. O chamador tira o fone do
gancho. gancho.
2. O sistema apresenta o tom de 2. O sistema apresenta o tom de
discagem. discagem.
3. O chamador disca um dígito. 3. O chamador disca um dígito.
4. O sistema desativa o tom de 4. O sistema desativa o tom de
discagem. discagem.
5. O chamador insere o restante do 5. O chamador insere o restante do
número. número.
6. O sistema analisa o número. 6. O sistema analisa o número.
7. O sistema localiza a parte 7. O sistema envia o número para
correspondente. outro sistema.
8. O sistema estabelece a conexão 8. O sistema estabelece a conexão
das partes. das linhas.
9. Desconexão das partes. 9. Desconexão das partes.
Exemplo
Escrevendo
casos de uso
Escrever casos de uso como
requisitos
• São requisitos:
• Não convertê-los em outra forma de requisitos
comportamentais.
• Se corretamente escritos, especificam exatamente o que
o sistema deve fazer.
• Não são todos requisitos:
• Não especificam interfaces externas, formatos de dados,
regras de negócio e fórmulas complexas.
• Constituem uma fração de todos os requisitos que
precisa coletar.
Estilos de escrita
• Casuais: escrita resumida, mais rápidos. Ex:
• Grupo restrito capturando requisitos
• Grupo maior discutindo futuros requisitos
• Pode ser visto no exemplo 4.
• Inteiramente completos: escritos por times
maiores, com inclinação formal. (1 a 3)
• De negócio: descrevem operações de negócio
Exemplo: Comprar algo (versão
casual)
Exemplo : Comprar algo (versão completa)
Cenários e passos
• Cada caso de uso tem um enredo cruzado que
mostra o sistema alcançando o objetivo ou o
abandonando
• Cada cenário inicia com uma condição de
acionamento que indica quando é executado e
vaii até quando mostra a conclusão ou o
abandono de seu objetivo.
Cenário de sucesso Principal
• Descrição de cima-para baixo de um cenário fácil
de entender, bastante característico, cujo objetivo
do ator principal é alcançado.
• Condição sob a qual o cenário é executado
• Para um cenário de sucesso principal ela é a
pré-condição mais o acionador.
• Para um cenário de extensão, ela é condição de
extensão.
Cenário de sucesso Principal
• Objetivo a alcançar
• Para um cenário de sucesso principal, é o nome
do caso de uso
• Para um cenário de extensão, o objetivo é
completar o caso de uso ou reingressar no
cenário de sucesso principal, após o tratamento
da condição.
• Um conjunto de passos de ação:
• Corpo do cenário e seguem as mesmas regras
de todo o cenário ou fragmento
Cenário de sucesso Principal
• Condição de término
• O objetivo é alcançado no final do cenário de
sucesso principal. Um fragmento de cenário
pode terminar com o objetivo sendo alcançado
ou abandonado.
• Possível conjunto de extensões descritas como
fragmentos de cenário:
• São situadas na seção de extensões do caso de
uso. Extensões de extensões são colocadas em
série, dentro de, ou logo após o, corpo de
extensão
Caso de uso: comprar ações na
internet

• Extensão
Corpo do cenário
• Sequencia de ações para atingir o objetivo.
• Podem não ser sequenciais (paralelas)
• Em ordens diferentes,
• Repetições ou
• Opcionais
• Qualquer passo descreverá:
• Uma interação entre dois atores (Cliente informa endereço)
• Um passo de validação para proteger um interesse do stakeholder
(Sistemas valida senha)
• Uma mudança interna para satisfazer um interesse do stakeholder
(Sistemas deduz quantia do saldo)/
Exemplo
Passos de uma ação
• Compõem um caso de uso bem escrito e estão
em uma forma gramatical simples na qual o ator
realiza uma ação ou passa uma informação a
outro ator.
Diretrizes para escrever passos
• Use gramática simples:
• Sujeito.. Verbo ... Objeto direto... Frase
preposicional
• Ex: O sistema... deduz... a quantia... do saldo da
conta.
• Mostre claramente “quem está com a bola”
• O ator sujeito da sentença deverá ser a primeira
ou segunda palavra na senteça.
• O ator com a bola pode fazer:
• Conduzir a bola
• Passar para outro
Diretrizes para escrever passos
• Escreva com uma visão geral
Diretrizes para escrever passos
• Mostre o processo avançado
• A quantidade de progresso feita em um passo
está relacionada como quão alto ou baixo é o
objetivo de um caso de uso.
• Em um UC resumo, o passo provavelmente avaná um
objetivo inteiro
• Em um UC subfunção, tem um incremento muito
menor
• Passos muito pequenos atrapalham . Pergunte por
que faz isso ?
• Nro de passo < 9
• Ex: Usuário pressiona TAB (Por que?)
Diretrizes para escrever passos
• Mostre a intenção dos atores, não os movimentos
• Descrever movimentos do usuário operando a
interface é um dos erros mais comuns e graves
na escrita de casos de uso (nível muito baixo).
Documentação dos casos de
uso
• Identificador • Atores Secundários
• Nome • Pré-condições
• Descrição • Fluxo Principal
• Importância (apenas 1) • Fluxos Alternativos
• Essencial • Fluxos de Exceção
• Importante ou
• Desejável • Pós-condições
• Ator Primário • Regras do Negócio
Exemplo 1: Compras na internet
Exemplo 2 : recebendo por um acidente
de carro
Exemplo 3: Registrar chegada de um
caixa
 Como
DOCUMENTAR
68
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.

69
Documentação dos casos de
uso
◼ A descrição do modelo deve ser mantida
no nível mais simples possível...

70
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.

71
Documentação dos casos de
uso
• O modelo de casos de uso força o desenvolvedor
a pensar em como os agentes externos interagem
como 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.

72
Documentação dos
casos de uso
• Nome
• Descrição
• Identificador ◼ Fluxo Principal
• Importância ◼ Fluxos Alternativos
• Sumário ◼ Fluxos de Exceção
• Ator Primário ◼ Pós-condições
• Atores Secundários ◼ Regras do Negócio
• Pré-condições ◼ Histórico
◼ Notas de Implementação
73
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.
74
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. 75
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.

76
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

77
Requisitos de desempenho
• Conexão de casos de uso a requisitos de
desempenho.
Identificador Freqüência Tempo ...
do caso de da utilização máximo
uso 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 segundos ...
10 dias
seguidos. 78
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.
79
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.
80
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
81
4) Risco baixo e prioridade baixa
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. 82
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.
• No projeto

83
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 84
iterações iniciais.
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.

85
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 86
construídos com base nos casos de uso.
Diagrama de Casos
de Uso de Negócio
Modelo de Casos de Uso de
Negócio
• Finalidade: descrever como o negócio é usado por
seus clientes e parceiros.
• As atividades que se referem diretamente ao
cliente ou parceiro, bem como as tarefas de
suporte ou gerenciais que se referem
indiretamente à parte externa, podem ser
apresentadas.
• Descreve o negócio em termos de casos de uso de
negócios, o que corresponde ao que geralmente é
denominado "processos".
Categorias de CSU Negócio
1. Atividades importantes comercialmente, denominadas
processos de negócios.
2. Atividades que não são importantes comercialmente,
mas que devem ser realizadas de qualquer maneira para
que o negócio funcione.:
• Administração de sistemas, limpeza e segurança são
exemplos típicos.
• Os casos de uso de negócios têm a característica de
suporte.
3. Trabalho de gerenciamento. Os casos de uso de
negócios de gerenciamento mostram o tipo de trabalho
que afeta a maneira como os outros casos de uso de
negócios são gerenciados e os relacionamentos do
negócio com seus proprietários.
Exemplo

Suporte