1. Roteiro de Elaboração de um
Modelo de Casos de Uso
Profa. Dra. Judith Pavón
Relatório Técnico
RT.2012.CCO/SI.01.00
Abril – 2012

2. Índice
1. Objetivo do Documento ..............................................................................................3
2. Conceitos Básicos ........................................................................................................4
3. Diretrizes para Elaborar um Modelo de Casos de Uso ................................................7
4. Diretrizes para Identificar Atores ................................................................................8
5. Diretrizes para Identificar Casos de Uso .....................................................................9
6. Diretrizes para Especificar um Caso de Uso ................................................................9
7. Padrão para Especificar um Caso de Uso ...................................................................10
8. Diretrizes para Revisar a Especificação de um Caso de Uso ......................................11
9. Os Dez Erros Típicos na Elaboração de um Modelo de Casos de Uso ........................12
10. Exemplo ...................................................................................................................15
RT.2012.CCO/SI.01.00 Page 2

3. 1. Objetivo do Documento
Este documento tem por objetivo servir como guia aos alunos dos cursos de Ciência da
Computação e Sistemas de Informação da Universidade Salvador (UNIFACS) para a
elaboração de um modelo de casos de uso.
Existem bons livros disponíveis aqui no Brasil que tratam sobre o tema de elaboração
de modelos de casos de uso. No entanto, uma razão que me levou a escrever este
relatório técnico foi o fato que muitos desses livros acabam dando maior ênfase à
notação que deve ser utilizada no diagrama de casos de uso e não orientam na
elaboração de modelos de casos de uso. Certamente, essa notação é importante para
qualquer projetista, mas, igualmente importante, é entender como aplicar essa
notação na modelagem de um domínio de problema.
Em vista do comentado acima, este relatório não tem como objetivo ser uma
referência completa sobre a notação de modelos de casos de uso, definida pela UML
(Linguagem de Modelagem Unificada), e nem como referência para aprender todos os
conceitos básicos relacionados. Este documento tem como objetivo apresentar
diretrizes que orientem, principalmente a iniciantes da modelagem orientada a
objetos, na elaboração de modelos de casos de uso, mostrando passo a passo, como
aplicar os diferentes conceitos em um caso prático.
O documento consiste das seguintes seções:
• A seção 2 apresenta os conceitos básicos referentes ao contexto de modelos de
casos de uso;
• A seção 3 apresenta as diretrizes essenciais para iniciar a elaboração de um modelo
de casos de uso;
• A seção 4 apresenta diretrizes para identificar os atores;
• A seção 5 apresenta diretrizes para identificar casos de uso;
• A seção 6 apresenta diretrizes para descrever um caso de uso;
• A seção 7 apresenta um padrão para a especificação de um caso de uso;
• A seção 8 apresenta diretrizes para revisar a especificação de um caso de uso;
• A seção 9 apresenta os dez erros típicos na elaboração de um modelo de casos de
uso;
• A seção 10 apresenta um exemplo de especificação de caso de uso.
RT.2012.CCO/SI.01.00 Page 3

4. 2. Conceitos Básicos
Uma das primeiras etapas dentro do processo de desenvolvimento de software é o
levantamento de requisitos, tanto funcionais como não funcionais. Especificamente, a
etapa de levantamento de requisitos corresponde a buscar junto ao usuário, todas as
informações referentes as funções que o sistema deve executar (requisitos funcionais)
e as restrições sob as quais o sistema deve operar (requisitos não funcionais). Logo
após, o levantamento de requisitos, deve ser realizada a organização destes requisitos
para que possam ser contemplados no desenvolvimento do produto de software.
Grande parte dos requisitos funcionais será organizada como processos de negócio
conhecidos como casos de uso. Os casos de uso referem-se aos serviços ou processos
de negócio que podem ser utilizados de alguma maneira pelos usuários do sistema,
como emitir um relatório ou comprar um produto. Os casos de uso são utilizados para
expressar e documentar o comportamento ou funções do sistema.
Um modelo de casos de uso é composto pelo diagrama de casos de uso e a
documentação dos elementos do modelo, conforme pode ser observado na Figura 1.
Figura 1. Representação de um Modelo de Casos de Uso
O diagrama de casos de uso é composto por casos de uso, atores e os relacionamentos
ou associações. Um caso de uso é uma seqüência de ações que o sistema executa ou
produz um resultado de valor observável para um ator. Os casos de uso capturam e
modelam os requisitos funcionais, servindo como um acordo entre as pessoas
envolvidas no desenvolvimento do sistema (stakeholders), descrevendo seu
comportamento sob diversas condições conforme responde às requisições dos
interessados, denominados atores primários. Os atores não fazem parte do sistema.
Eles representam qualquer pessoa, entidade ou dispositivo que interage com o
sistema. Pode representar um ser humano, uma máquina, outro sistema ou um
RT.2012.CCO/SI.01.00 Page 4

5. departamento de uma empresa. Um ator representa os papéis que o usuário do
sistema pode desempenhar.
O relacionamento entre atores e casos de uso é conhecido como linha de
comunicação, pois representa o canal de comunicação entre um ator e um caso de
uso, conforme pode ser observado na Figura 2.
Figura 2. Linha de comunicação entre ator e caso de uso.
Os relacionamentos básicos entre casos de uso são: inclusão, extensão e
generalização. Ao detalhar ou elaborar a especificação de casos de uso é possível
descobrir novos processos de negócio e estruturar os relacionamentos dos casos de
uso no diagrama.
O relacionamento de inclusão (<<include>>) ocorre quando um caso de uso base exige
um conjunto de atividades necessárias para a sua execução no cenário principal,
porém não é o objetivo do caso de uso base. Há duas situações típicas para casos de
uso de inclusão:
• Quando existe um comportamento comum para vários casos de uso. Neste caso,
esse comportamento pode ser separado e modelado como um caso de uso de inclusão
associado aos vários casos de uso que contêm este comportamento.
• Quando existe um comportamento muito complexo ou extenso no cenário principal
de um caso de uso, mas que não é o centro ou objetivo deste caso de uso. Esse
comportamento poderia ser representado como um caso de uso de inclusão.
O comportamento definido pelo caso de uso de inclusão é explicitamente inserido no
caso de uso base. A representação é uma linha tracejada do caso de uso base para o
caso de uso de inclusão, acrescida do estereótipo <<include>>, como descrito na Figura
3.
RT.2012.CCO/SI.01.00 Page 5

6. Figura 3. Representação de um caso de uso de inclusão.
O relacionamento de extensão (<<extend>>) ocorre quando um caso de uso base tem
um conjunto de ações que devem ser realizadas em um caso de exceção. Casos de uso
de extensão modelam comportamento alternativo do caso de uso. O caso de uso de
extensão é inserido no caso de uso base, somente se a condição de extensão for
verdadeira.
A representação é uma linha tracejada do caso de uso estendido para o caso de uso de
base, acrescida do estereótipo <<extend>>, como descrito na Figura 4.
Figura 4. Representação de um caso de uso de extensão.
O relacionamento de generalização ocorre quando um caso de uso genérico (pai)
possui um cenário principal, onde certos passos são diferentes dos seus casos de uso
específicos (filhos). A representação é uma linha contínua em que os casos de uso
filhos apontam para o caso de uso pai, como pode ser observado na Figura 5.
Figura 5. Representação de um relacionamento de generalização.
RT.2012.CCO/SI.01.00 Page 6

7. O relacionamento de generalização também pode ser definido entre atores, pois eles
podem ter características comuns, sendo representado por um ator genérico, e os
atores com características particulares são representados como atores filhos.
Normalmente, a generalização de atores é modelada em um diagrama separado, onde
estão somente os atores, enquanto apenas o ator generalizado é desenhado nos
diagramas onde aparecem os casos de uso. Esta prática costuma ser realizada para não
poluir o diagrama de casos de uso, pois a idéia principal é que o diagrama seja um
instrumento de comunicação com o cliente e usuários, portanto deve ser simples e
fácil de entender. Na figura 6 é mostrado um exemplo de uma generalização de atores.
Figura 6. Representação de uma generalização de atores.
Nas próximas seções são apresentadas diversas diretrizes para elaborar um modelo de
casos de uso e para documentar os elementos do diagrama de casos de uso.
3. Diretrizes para Elaborar um Modelo de Casos de Uso
Como foi mencionado anteriormente, o modelo de casos de uso é composto pelo
diagrama de casos de uso, e pelas documentações dos atores e casos de uso. Os casos
de uso definem uma promessa ou contrato de como um sistema se comportará.
Os passos essenciais na elaboração de um modelo de casos de uso são:
Estabelecer uma fronteira
• Identificar atores
RT.2012.CCO/SI.01.00 Page 7

8. • Descrever atores
• Identificar casos de uso
• Descrever brevemente o objetivo de cada caso de uso
• Identificar relacionamentos entre atores e casos de uso
• Elaborar diagramas de casos de uso
• Elaborar a descrição passo a passo de cada caso de uso
O primeiro passo a ser realizado é definir a fronteira (alcance do sistema). Uma vez
definida a fronteira, é importante pensar primeiro nos atores. A idéia por trás de casos
de uso é decidir para que o sistema será usado antes de decidir o que o sistema irá
fazer. Se alguém modela o sistema pensando primeiro nos casos de uso e depois nos
atores, está com um problema sério, pois quer dizer que ainda não entendeu a
filosofia de modelo de casos de uso. Vale a pena lembrar que um modelo de casos de
uso deve ser modelado a partir da perspectiva do usuário e não do desenvolvedor.
Portanto, se vamos colocar o usuário no centro de nossas preocupações, então os
atores devem ter prioridade número um nas nossas atividades. Uma vez identificados
os atores, os mesmos precisam ser documentados, isto é, deve ser elaborada uma
breve descrição sobre o que representa cada um deles. Logo após, devem ser
identificados os casos de uso, que são as metas ou serviços do sistema utilizados pelos
usuários. Elabora-se uma descrição sucinta de cada caso de uso, de forma a deixar
claro o objetivo do mesmo. A seguir, são definidas as associações entre atores e casos
de uso e elabora-se o diagrama de casos de uso. Depois deve ser elaborada a descrição
passo a passo de cada caso de uso, considerando os diversos cenários possíveis para
esse processo de negócio, e por último, é realizado um refinamento tanto do diagrama
como da documentação associada.
4. Diretrizes para Identificar Atores
Na identificação de atores podem ser utilizadas algumas perguntas básicas com a
finalidade de obter os principais atores envolvidos no sistema:
a) Que pessoas, órgãos, empresas ou grupos de usuários utilizarão o sistema?
b) Que elementos ou componentes estimularam os casos de uso ou funcionalidades do
sistema, além dos usuários?
c) Que outros sistemas se comunicarão com o sistema a ser construído?
RT.2012.CCO/SI.01.00 Page 8

9. d) Que pessoas, órgãos, empresas, sistemas ou grupos de usuários receberão
informações do sistema?
e) Que papéis desempenham os usuários ou grupo de usuários que utilizam o sistema?
Observação: existem atores que não iniciam nenhum caso de uso, mas são “tocados”
por casos de uso, isto é, simplesmente recebem informações do sistema.
5. Diretrizes para Identificar Casos de Uso
Podem ser utilizadas algumas perguntas básicas com a finalidade de obter os principais
casos de uso:
a) Quais são as metas de cada ator?
b) Quais são os serviços utilizados pelos atores?
c) O ator precisa ser informado sobre eventos externos ou mudanças no sistema?
d) O ator precisa ser informado sobre certas ocorrências no sistema?
e) Quais são os processos de negócio envolvidos no domínio do problema?
Observação: uma vez identificados os casos de uso, eles devem ser trazidos para
análise da equipe de desenvolvimento, somente depois devem ser especificados
detalhadamente.
6. Diretrizes para Especificar um Caso de Uso
Os casos de uso podem ser descritos com diferentes níveis de detalhamento, isto
depende da metodologia adotada pela equipe de desenvolvimento. Na fase de análise,
quando o objetivo é estudar o sistema para descobrir as necessidades do cliente, usa-
se a descrição essencial de caso de uso, que consiste na definição do nome do caso de
uso, uma breve descrição do objetivo do mesmo e citar os atores primários. No
entanto, na fase de projeto, quando a meta é produzir uma solução implementada de
um sistema para o cliente, deverá ser realizada a descrição detalhada do caso de uso,
também conhecido como caso de uso expandido, onde inclui a especificação dos
diferentes fluxos possíveis dentro desse contexto.
Cada caso de uso deve ser descrito de forma a contemplar todos os cenários possíveis.
Geralmente, estes cenários são organizados em três grupos:
1. Fluxo Principal: é considerado o cenário feliz, isto é, cenário de sucesso do início ao
fim. O fluxo principal deve focar sempre o objetivo principal do processo de negócio.
RT.2012.CCO/SI.01.00 Page 9

10. Quando existir mais de um cenário que possa ser candidato do fluxo básico ou
principal, o analista deve escolher o mais utilizado ou aquele que melhor retrata o caso
de uso, deixando os outros como alternativos.
2. Fluxo Alternativo: corresponde aos cenários opcionais ou caminhos alternativos do
fluxo principal. São as variantes do fluxo principal.
3. Fluxo de Exceção: corresponde aos cenários que tratam os erros ou exceções.
Existem algumas bibliografias que não consideram esta terceira alternativa, colocando
tanto os cenários opcionais como os que tratam os erros nos fluxos alternativos.
Depois de descrever o fluxo principal do caso de uso, deve-se imaginar o que poderia
dar errado em cada um dos passos descritos, gerando assim os fluxos de exceção. Um
fluxo de exceção é um evento capaz de impedir o prosseguimento do caso de uso se
não for devidamente tratado.
Um caso de uso deve descrever o que deve ser feito e quem faz, mas nunca deve ser
descrito o como. Deve-se evitar descrever qualquer processo interno do sistema (ex.
deve-se armazenar os dados do pagamento do empréstimo na tabela Pagamento do
banco de dados).
7. Padrão para Especificar um Caso de Uso
A seguir é apresentado um template que mostra os elementos que conformam o
padrão de especificação de um caso de uso utilizado nos cursos de Ciência da
Computação e Sistemas de Informação da Universidade Salvador (UNIFACS).
O template utilizado para especificar casos de uso é apresentado a seguir:
Caso de Uso: indicar o código e nome do caso de uso.
Finalidade: breve descrição do objetivo do caso de uso.
(opcional) Ator primário: indicar o nome ou nomes de atores que iniciam o caso de
uso.
(opcional) Pré-condição: é uma restrição ou restrições que devem ser verdadeiras
antes de começar o caso de uso.
Fluxo Principal: descrever os passos necessários para alcançar o objetivo do processo
de negócio com sucesso. Enumerar os passos, indicando a interação entre usuário e
sistema.
RT.2012.CCO/SI.01.00 Page 10

11. Fluxos alternativos: colocar um título para cada fluxo alternativo. Enumerar os passos,
indicar o número do passo do fluxo principal ou outro fluxo do qual é derivada e
especificar onde continua, se retorna ao fluxo principal ou se o caso de uso é
encerrado.
Fluxos de exceção: colocar um título para cada fluxo de exceção. Enumerar os passos,
indicar o número do passo do fluxo principal ou outro fluxo do qual é derivada e
especificar onde continua, se retorna ao fluxo principal, alternativo ou se o caso de uso
é encerrado.
(opcional) Pós-condição: refere-se ao estado do sistema quando o caso de uso
termina. Pode conter variantes.
Extensões: citar os casos de uso que estendem o caso de uso que está sendo
especificado.
Inclusões: citar os casos de uso que são incluídos pelo caso de uso que está sendo
especificado.
Regras de Negócio: citar as regras de negócio usadas no caso de uso.
8. Diretrizes para Revisar a Especificação de um Caso de Uso
Revisar a especificação de um caso de uso não é uma tarefa trivial, pois requer de um
certo esforço e de muita concentração. Um aspecto importante a ressaltar é que duas
pessoas que descrevem um caso de uso do mesmo processo de negócio,
provavelmente especificarão uma seqüência de passos diferentes, pois cada pessoa
tem a sua própria lógica. Porém, todo caso de uso tem passos obrigatórios. Esses
passos envolvem as informações que de alguma forma passam dos atores para o
sistema, e do sistema para os atores, sem os quais o caso de uso não faz sentido ou
não pode prosseguir. Esses passos devem constar em qualquer caso de uso expandido
(descrição detalhada do caso de uso), e a falta deles faz com que o caso de uso esteja
incorretamente descrito.
Outro aspecto a revisar é a linguagem utilizada para a especificação do caso de uso,
pois deve ser feita sob a perspectiva do usuário do sistema, portanto, devem ser
evitados os termos técnicos ou características de implementação na descrição de um
caso de uso.
Os casos de uso devem ser descritos de forma simples o bastante para que os usuários
entendam e verifiquem, mas preciso o bastante para que os analistas e projetistas
possam utilizar como modelo base para a construção do sistema.
RT.2012.CCO/SI.01.00 Page 11

12. Em relação à revisão da consistência da especificação de um caso de uso, recomenda-
se realizar as seguintes perguntas:
• O objetivo do caso de uso é claro e preciso?
 A descrição do caso de uso atinge o objetivo pré-definido quando termina a
execução do fluxo principal?
• Existe ambigüidade em relação à seqüência de passos do caso de uso utilizado para
atingir ao objetivo especificado?
• O caso de uso especifica a informação que o ator precisa saber para atingir seu
objetivo?
• O caso de uso especifica a informação que o sistema precisa possuir para atender o
objetivo da solicitação do ator?
• O caso de uso identifica as ações externamente relevantes que o sistema deve
realizar para satisfazer as solicitações do ator?
• O caso de uso especifica as interações entre o sistema e atores de acordo com as
suas responsabilidades?
• Todos os passos da especificação de Caso de Uso estão de acordo com a realidade,
isto é, de acordo com o que o usuário deseja durante a operação do sistema?
• As situações de falha e sucesso são especificadas claramente no caso de uso?
• As pré-condições e pós-condições estão claramente identificadas?
• Foram referenciados na especificação do caso de uso os nomes dos casos de uso
relacionados (inclusões ou extensões)?
• A especificação do caso de uso (considerando todos os fluxos) apresenta uma visão
completa do comportamento do sistema referente ao processo de negócio modelado?
9. Os Dez Erros Típicos na Elaboração de um Modelo de Casos de Uso
Esta seção tem como objetivo apresentar os dez erros mais comuns que
costumam acontecer nos modelos de casos de uso de pessoas iniciantes na
modelagem orientada a objetos. Acredito que esta seção pode ser muito útil para
sanar aquelas dúvidas que ficam pendentes depois de ter lido todas as diretrizes
apresentadas acima. A seguir são descritos estes erros:
 ERRO 10: Cada requisito funcional sempre corresponde a UM caso de uso.
RT.2012.CCO/SI.01.00 Page 12

13. Esta afirmação costuma ser o erro mais freqüente entre os profissionais iniciantes na
modelagem de casos de uso. Um requisito funcional nem sempre corresponde a um
caso de uso. Acontece que um caso de uso representa um processo de negócio, isto é,
um conjunto de ações com início, meio e fim. Porém, um requisito funcional nem
sempre se refere a um processo de negócio, muitas vezes o requisito funcional é
simplesmente uma única ação. A seguir são especificados dois requisitos funcionais
referentes à compra de passagens pela Internet:
- Requisito 1: O sistema deve permitir realizar ao usuário a compra de passagens
aéreas pela Internet.
- Requisito 2: O sistema deve permitir que o usuário possa selecionar o vôo desejado.
Note que no primeiro exemplo (“Comprar passagem”), o requisito funcional
corresponde a um caso de uso, pois o mesmo corresponde a um processo de negócio,
onde devem ser realizados vários passos para atingir o objetivo de comprar a
passagem. No entanto, no segundo exemplo (“Selecionar Vôo”), o requisito funcional
corresponde simplesmente a um passo dentro de um caso de uso, pois selecionar o
vôo desejado implica simplesmente uma ação. Não existe a possibilidade de definir um
conjunto de passos para o fluxo principal do segundo exemplo, e como conseqüência,
não é um caso de uso.
 ERRO 9: Na especificação do caso de uso somente devem ser especificadas as ações
realizadas pelo usuário para interagir com o sistema.
A descrição detalhada de um caso de uso deve especificar a interação entre o usuário e
o sistema. A ausência dos passos de interação que registrem essa troca de informações
deixa o caso de uso sem sentido. Portanto, um caso de uso está incorretamente
descrito quando somente são especificadas as ações do usuário, como se pode
observar no exemplo abaixo.
Caso de Uso: Comprar passagens aéreas
Fluxo Principal:
1. Cliente informa os dados da passagem.
2. Cliente confirma os dados da passagem.
3. Cliente informa os dados do pagamento da passagem.
4. Cliente confirma a compra da passagem.
RT.2012.CCO/SI.01.00 Page 13

14.  ERRO 8: Na especificação de um caso de uso deve ser detalhado o processamento
interno do sistema.
Os casos de uso devem mostrar o que é feito e por quem é feito, mas nunca o como.
Um erro freqüente é especificar detalhes de implementação na especificação de um
caso de uso (ex. citar o nome do banco de dados ou da tabela onde serão
armazenados os dados referentes ao processo de negócio modelado). O projetista
deve-se lembrar que a descrição ou especificação de um caso de uso não deve mudar
quando mudam os detalhes de implementação, pois o caso de uso representa o
processo de negócio, portanto, ele somente pode mudar quando existe alguma
alteração ou mudança no próprio processo de negócio.
 ERRO 7: As associações <<include>> e <<extend>> representadas no diagrama de
casos de uso devem ser utilizadas o máximo possível, com a finalidade de deixar
mais claro o domínio do problema.
Geralmente quando o projetista exagera com o uso das associações ou
relacionamentos <<include>> e <<extend>> gera um diagrama de casos de uso
poluído, deixando o modelo mais complexo e difícil de entender. Para este tipo de
situação, recomenda-se analisar caso a caso a relevância de cada associação. Na seção
2 são descritas as situações nas quais se recomenda utilizar estas associações, caso
contrário evite a sua utilização.
 ERRO 6: A especificação de um caso de uso deve referenciar aos elementos da
interface do sistema.
Recomenda-se elaborar um esboço da interface para ter uma noção da interação do
usuário com o sistema. Porém, isso não implica que devem ser mencionados os
elementos da interface do sistema na especificação do caso de uso. O caso de uso
representa o processo de negócio independente da interface utilizada no sistema.
Portanto, se a interface muda não tem porque mudar a especificação do caso de uso.
Exemplo: “Usuário pressiona o botão CONFIRMAR”. Esta frase indica que
necessariamente deverá existir um botão com o rótulo “Confirmar”, o que implica
amarrar a descrição do caso de uso a uma interface específica.
 ERRO 5: Na especificação de um caso de uso devem ser incluídos os detalhes
referentes a mecanismos de segurança.
Aspectos relacionados com mecanismos de segurança geralmente não são detalhados
nas especificações de casos de uso. Exemplo: “Operação de login do usuário no
sistema”. O que pode ser especificado no sistema é que o usuário será autenticado no
RT.2012.CCO/SI.01.00 Page 14

15. sistema, mas não como será feita esta autenticação, pois amanhã ou depois esta
autenticação pode mudar (ex. reconhecimento de voz), mas o caso de uso não deve
mudar por causa desta alteração. A autenticação no sistema ou identificação do
usuário no sistema geralmente recomenda-se colocar como uma pré-condição do caso
de uso.
 ERRO 4: As pré-condições devem ser verificadas dentro do caso de uso.
Uma pré-condição é uma restrição que precisa ser verdadeira ANTES que inicie o caso
de uso. Portanto, a mesma não deve ser verificada dentro da especificação do caso de
uso.
 ERRO 3: Um caso de uso é uma rotina do sistema.
Geralmente os desenvolvedores assumem que um caso de uso constitui uma rotina do
sistema, mas esta afirmação não é verdadeira. Isto costuma ser muito comum quando
o projetista precisa elaborar modelos de casos de uso tendo como base o código de
um sistema legado. Porém, nem sempre uma rotina do sistema representa um
processo de negócio. A pergunta que deve ser realizada é: -“Quais são os processos de
negócio deste sistema?” e não considerar que cada rotina corresponderá a um caso de
uso específico.
 ERRO 2: Um caso de uso de extensão ou de inclusão não precisam ser referenciados
no caso de uso base.
Todo caso de uso de extensão ou inclusão que é representado no diagrama de casos
de uso deve ser referenciado na especificação do caso de uso base correspondente. O
caso de uso de inclusão geralmente é referenciado no fluxo principal do caso de uso
base, e o caso de uso de extensão em algum fluxo alternativo ou de exceção do caso
de uso base.
 ERRO 1: Na descrição dos fluxos alternativos ou de exceção não precisa conter um
passo que indique como o caso de uso continua.
Para cada fluxo alternativo ou fluxo de exceção deve ser especificado como esse fluxo
começa (indicar o passo do fluxo principal ou de outro fluxo da onde vem), quais ações
são tomadas e como o caso de uso continua.
10. Exemplo
A seguir é mostrado um exemplo de especificação de caso de uso, utilizando o
template apresentado acima. O exemplo refere-se ao caso de uso “Verificar
RT.2012.CCO/SI.01.00 Page 15

16. disponibilidade de passagens”, dentro do contexto de um Sistema de Compras de
Passagens Aéreas via Web. Na Figura 7, apresenta-se o diagrama de casos de uso
correspondente.
Figura 7. Extração de uma parte do Diagrama de Casos de Uso do Sistema de Compras
de Passagens Aéreas.
Caso de Uso: UC1 - Verificar Disponibilidade de Passagens
Finalidade: Pesquisar as passagens disponíveis, indicando os aeroportos de origem e
de destino, quantidade e tipo de passageiros (adultos e crianças), bem como a data da
viagem.
Ator primário: Cliente
Pré-condição: Cliente devidamente autenticado no sistema.
Fluxo Principal:
1. Sistema solicita os dados referentes a passagem (dados de origem e destino,
indicação se é uma passagem somente de ida ou ida e volta, data e quantidade de
passageiros)
2.Cliente informa os dados referentes à passagem:
- ida e volta (ou somente ida);
- aeroportos de origem e de destino;
- data de ida e volta (ou somente ida);
- quantidade de adultos;
- quantidade de crianças.
3. Sistema valida os dados do critério de busca (RN01, RN02).
RT.2012.CCO/SI.01.00 Page 16

17. 4. Sistema seleciona os voos disponíveis correspondentes ao critério de busca (RN03).
5. Sistema calcula valor da passagem dos voos disponíveis que satisfazem os dados
informados .
6. Sistema exibe voos disponíveis (data e número do vôo, hora de saída e chegada,
escalas e/ou conexões, preço e taxas de embarque);
7. Cliente seleciona voo de ida ou voos de ida/volta de interesse.
8. Sistema exibe os detalhes do voo selecionado e o contrato.
9. Cliente escolhe sair do sistema.
10. O caso de uso é encerrado.
Fluxos alternativos:
A1. Cliente decide comprar a passagem
A1.1. No passo 9 do fluxo principal o Cliente seleciona "Comprar Passagem"
A1.2. Ir para UC9 – Comprar Passagem
A1.3. Retorna ao passo 9 do fluxo principal.
A2. Cliente decide realizar nova busca.
A2.1. No passo 9 do fluxo principal o Cliente seleciona "Nova Busca"
A2.2. Retorna ao passo 1 do fluxo principal.
Fluxo de exceção:
E1. Aeroporto de origem igual ao de destino
E1.1. No passo 3 do fluxo principal o sistema identifica que o aeroporto de
origem é o mesmo que o de saída.
E1.2. O Sistema mostra a seguinte mensagem "Os aeroportos de origem e de
destino devem ser diferentes"
E1.3.- Retorna ao passo 1 do fluxo principal.
RT.2012.CCO/SI.01.00 Page 17

18. E2. Data de ida maior à data atual
E2.1. No passo 3 do fluxo principal o sistema identifica que a data de ida é
maior à data atual.
E2.2. O Sistema mostra a seguinte mensagem "A data de ida deve ser maior à
data atual"
E2.3. Retorna ao passo 1 do fluxo principal.
E3. Não encontra voos disponíveis
E3.1. No passo 5 do fluxo principal o sistema identifica que não existem voos
diponíveis para o critério de busca informado pelo cliente.
E3.2. O Sistema mostra a seguinte mensagem "Não existem voos disponíveis
para o período informado. Informe outro período de datas."
E3.3.- Retorna ao passo 1 do fluxo principal.
Extensões: UC9 - Comprar Passagem
Inclusões: Nenhuma
Regras de Negócio: RN01, RN02, RN03
RN01 – O aeroporto de origem deve ser diferente ao aeroporto de destino.
RN02 – A data de ida deve ser igual ou maior à data atual.
RN03 – Um voo disponível é um um voo com pelo menos um assento disponível.
BIBLIOGRAFIA RECOMENDADA
BEZERRA, Eduardo, Princípios de Análise e Projeto de Sistemas com UML. 2ª. ed. Rio de
Janeiro: Campus, 2006.
COCKBURN, A. Escrevendo Casos de Uso Eficazes: Um guia prático para
desenvolvedores de software. Bookman. 2005.
DOUG, R.; KENDALL S. Applying Use Case Driven Object Modeling with UML. Addison-
Wesley. 2001.
RT.2012.CCO/SI.01.00 Page 18

19. GEDES, G. TA. A. UML: Uma Abordagem Prática. Novatec. 2004
PENDER, T. UML a Bíblia. Campus. 2004.
PRESSMAN, R. Engenharia de Software. 7a ed., Artmed. 2011.
SOMMERVILLE, Ian. Engenharia de Software. 9a ed., Pearson. 2011.
WASLALICK, R.S. Análise e Projeto de Sistemas de Informação Orientados a Objetos.
Rio de Janeiro: Elsevier. 2004.
RT.2012.CCO/SI.01.00 Page 19