Casos de Uso

Análise e Projeto de Sistemas

Os casos de uso descrevem como os usuários interagem com o sistema

(interface do sistema). Eles facilitam a organização dos requisitos e proporcionam
uma visão externa do sistema. O conjunto de casos de uso deve ser capaz de
comunicar a funcionalidade e o comportamento do sistema para o cliente. Os casos
de uso descrevem o que o sistema faz, mas não especificam como isso deve ser
feito.
Os casos de uso devem ser utilizados nas seguintes situações:
1. Antes de iniciar um projeto, para modelar um negócio, de modo que
todos os participantes do projeto compartilhem uma compreensão dos
trabalhadores, dos clientes e das atividades do negócio.
2. Ao coletar requisitos, para capturar os requisitos do sistema e
apresentar a outros o que o sistema deve fazer.
3. Durante as fases de análise e design, para identificar as classes
exigidas pelo sistema.
4. Durante a fase de testes, para identificar testes para o sistema.
Os elementos de um diagrama são: atores, casos de uso, relacionamentos
(associação, generalização ou dependência) e fronteira do sistema.

Atores
Os atores representam os papéis desempenhados por elementos
externos ao sistema, que interagem, de alguma forma, com ele. Exemplos: usuário,
dispositivo de hardware ou outro sistema. A notação utilizada para representar
atores no diagrama é a seguinte:
Casos de Uso
Representa uma funcionalidade do sistema (um requisito funcional). É
iniciado por um ator ou por outro caso de uso. Uma recomendação é nomear os
casos de uso iniciando por um verbo no infinitivo. A notação é a seguinte:

Para elaborar os conceitos dos elementos de casos de uso, vamos

utilizar um exemplo de uma loja de CDs, ela possui as seguintes características:
● 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, o gerente é quem dá a folga ao atendente, ou seja, ele
também atende clientes durante a venda dos discos.
● As vendas podem ser à vista ou a prazo. Em ambos os casos 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%. As vendas a prazo podem
ser pagas no cartão ou no boleto. Para pagamentos 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 à vista.
Identificando os casos de uso desse exemplo:
Relacionamentos

Associação
Indica que há uma interação (comunicação) entre um caso de uso e um ator. Um
ator pode se comunicar com vários casos de uso. As recomendações são para não
utilizar setas nesse tipo de relacionamento. As associações não representam fluxo
de informação. A notação para relacionamentos em casos de uso é a seguinte:

Utilizando o exemplo anterior da Loja de CDs, os relacionamentos de associação

identificados seriam:
Generalização
É um relacionamento utilizado quando dois ou mais atores podem se
comunicar com o mesmo conjunto de casos de uso. Um filho pode se comunicar
com todos os casos de uso que seu pai se comunica.

Com o exemplo anterior da Loja de CDs, um relacionamento de

generalização é identificado entre atendente e gerente.

Na generalização de casos de uso, o caso de uso filho herda o

comportamento e o significado do caso de uso pai, além disso ele pode incluir ou
sobrescrever o comportamento do caso de uso pai. Esse tipo de relacionamento
deve ser aplicado quando uma condição resulta na definição de diversos fluxos
alternativos.
 Notação para generalização de casos de uso.

Generalização de casos de uso do exemplo da Loja de CDs.

Dependência

Extensão
Esse tipo de relacionamento representa uma variação/extensão do
comportamento do caso de uso base. O caso de uso estendido só é executado sob
certas circunstâncias. Ele separa partes obrigatórias de partes opcionais:
● Partes obrigatórias: caso de uso base;
● Partes opcionais: caso de uso estendido.
O objetivo deste tipo de relacionamento é fatorar comportamentos
variantes do sistema (podendo reusar este comportamento em outros casos de
uso). A notação para esse tipo de dependência:
 Identificando relacionamentos de dependência de exclusão no exemplo
loja de CDs:

Inclusão
Esse tipo de relacionamento de dependência evita a repetição ao fatorar
uma atividade comum a dois ou mais casos de uso. Um caso de uso pode incluir
vários casos de uso. Ele é sempre executado. A notação para esse tipo de
dependência é a seguinte:

Identificando um relacionamento de dependência do tipo inclusão no

exemplo da Loja de CDs:
Fronteira do Sistema
É um elemento opcional, mas fundamental para um bom entendimento do
diagrama. Ele serve para definir a área de atuação do sistema e a notação de
fronteira do sistema é a seguinte:

Identificando a fronteira do sistema do exemplo de loja de CDs:

 Descrições de Caso de Uso
As descrições de caso de uso detalham a interação entre atores e o
sistema. Ela contém informações mais detalhadas que o diagrama. A UML não
define um padrão específico e normalmente, elas podem ser classificadas em três
tipos:
● Informal;
● Típica;
● Detalhada.
A escolha dentre os tipos depende da finalidade e do problema que está
sendo abordado. Normalmente, utiliza-se a detalhada, pois é a que tem as
informações necessárias para implementação. As outras abordagens são utilizadas,
normalmente, em metodologias ágeis, onde o cliente sempre presente pode suprir a
falta de informação. A descrição detalhada possui os seguintes elementos:
● Nome;
● Objetivo;
● Atores;
● Pré-condições;
● Pós-condições;
● Fluxo básico;
● Fluxos alternativos;
● Fluxos de exceção;
● Estruturas de dados;
● Regras de negócios;
● Observações.