Histórico
O conceito de “Caso de Uso” foi criado por Ivar Jacobson (um dos “três
amigos” - como se chama o grupo que formulou a UML e o Processo
Unificado).
Surgiu da necessidade de tentar estabelecer comunicação eficiente entre
o técnico de software e o usuário.
“Alcançar boa comunicação, associada a um bom entendimento do
mundo dos usuários, é a chave para desenvolver um bom software”.
Definições
Um caso de uso é uma técnica de modelagem usada para
descrever o que um novo sistema deve fazer . Ele é construído
através de um processo interativo no qual as discussões entre o
cliente e os desenvolvedores do sistema conduzem a uma
especificação do sistema da qual todos estão de acordo.
Em um momento inicial, os casos de uso deveriam estabelecer
comunicação entre os técnicos de software e os usuários; uma vez
estabelecido acordo quanto ao comportamento esperado, estes
diagramas seriam utilizados também para comunicação entre
técnicos: os casos de uso constituem a referência primária para as
demais abstrações – ou decodificações –dos requisitos nos artefatos
propostos , até se chegar à linguagem de programação.
Identificação
Geralmente, é difícil decidir se um conjunto de interações do
usuário do sistema, ou uma caixa de diálogo, é um ou são vários
casos de uso.
Considere o uso de uma máquina de reciclagem. O cliente
insere itens de depósito como, por exemplo, latas, garrafas e
caixotes na máquina de reciclagem. Ao inserir todos os itens de
depósito, basta pressionar um botão e um recibo é impresso. Esse
recibo pode ser trocado por dinheiro.
Identificação
É um caso de uso para inserir um item de depósito
e outro caso de uso para solicitar o recibo?
Ou trata-se apenas de um caso de uso para os
dois?
Há duas ações, mas uma sem a outra é de pouco
valor para o cliente. Mais exatamente, é o diálogo
completo, com todas as inserções e a obtenção do
recibo, que tem valor para o cliente (e faz sentido para
ele). Portanto, o diálogo completo, desde a inserção do
primeiro item de depósito, até o pressionamento do
botão e a obtenção do recibo, é um caso de uso
completo.
Diagrama
Sob uma perspectiva comunicacional, o diagrama de casos de
uso pode ser descrito como um sistema de símbolos que, por
convenção preestabelecida, se destina a representar e transmitir
uma mensagem entre a fonte e o ponto de destino. A fonte seria o
técnico de software e o ponto de destino um usuário ou um outro
técnico de software.
Diagrama
Ator
Representa qualquer entidade que interage com o sistema
durante sua execução essa interação se dá através de
comunicações (troca de mensagens). Um ator pode ser uma
pessoa (usuário, secretaria, aluno...) .
Objeto caso de uso
Cada objeto caso de uso é representado graficamente com o
símbolo de uma elipse e corresponde a um comportamento do
sistema que produz um resultado de valor mensurável para um ator.
Casos de uso descrevem as coisas que os atores querem que o
sistema faça e deve ser uma tarefa completa, segundo a
perspectiva do ator. O conjunto de todos os casos de uso irá
descrever a funcionalidade completa do sistema sob o ponto de
vista dos usuários.
Relacionamento
A representação gráfica das interações entre os atores
e os casos de uso é convencionada pela UML através de linhas
chamadas associações de comunicação, ou simplesmente
associações. É importante destacar que cada associação entre um
ator e um caso de uso representa todo o diálogo que se dá entre
eles, até que um resultado de valor observável seja alcançado. Com
isso, mesmo que haja várias interações entre o usuário e o sistema,
uma linha entre o ator e o caso de uso é suficiente para representar
todas essas interações. Formalmente, as “associações mostram
com quais atores o caso de uso se comunica.
Exemplo
Suponha que você tenha um almoxarifado de peças onde
clientes façam pedidos e onde um operador receba tarefas do
sistema para buscar peças para os pedidos dos clientes e
distribuir peças do setor de compras para o almoxarifado.
Exemplo
Vamos identificar os atores .
Eles são : Cliente , Operador , Sistema e
Setor de Compras.
Exemplo
Não errado !!! No exemplo Sistema não
pode ser um ator pois ele não se ajusta ao
conceito dado a um ator .
Lembre-se que um ator é um papel que interage
com o sistema mas não faz parte do sistema,
então no lugar de Sistema poderíamos sugerir
um administrador ou gerente.
Então os atores seriam : Cliente , Operador ,
Administrador e Compras.
Exemplo
E os casos de usos , quais seriam ?
- solicita peças (ator Cliente)
- entrega peças (ator Compras)
- buscar pedidos (ator operador)
- distribuir pedidos (ator operador)
- cadastrar Tarefas (administrador)
Exemplo
Errado !!! No caso do ator operador ele não
atua sobre o sistema nos casos de uso buscar
pedidos e distribuir pedidos , ele atua sobre o
sistema realizando Tarefa. Então o correto seria.
- solicita peças (ator Cliente)
- entrega peças (ator Compras)
- realiza Tarefa (ator operador)
- cadastrar Tarefas (administrador)
Diagrama
INCLUSÃO
Se um caso de uso inicia ou inclui o comportamento de
outro , dizemos que ele usa o outro.
Ex: No caso de uso Comprar Item se o pagamento for
feito com dinheiro podemos ter a inclusão
PagarComDinheiro
As propriedades básicas da inclusão são :
 realizar um decomposição funcional
 reduzir a complexidade de um caso de uso
 O caso de uso básico não pode executar sem a
inclusão.
EXEMPLO
Então para o exemplo do cliente com o use case Solicitar Pedidos
de peças teríamos:
INCLUSÃO
EXTENSÃO
• Extensão - Define pontos de extensão que adicionam
comportamento a um caso de uso base descrevendo uma variação
do comportamento normal. O caso de uso base pode ser executado
mesmo sem a extensão.
• Ex: O caso de uso Comprar Produto pode apresentar a extensão
Compra por um Cliente Regular. Abaixo temos o diagrama UML
EXEMPLO
EXTENSÃO
A IMPORTÂNCIA DA COMUNICAÇÃO COM O
USUÁRIO
A notação de casos de uso, assim como a UML, foram
divulgadas e tiveram ampla aceitação mundial pelos membros da
comunidade de software. É importante destacar que para
comunicação entre membros do corpo técnico, os casos de uso
podem gerar comunicação eficiente, mas o que está em análise a
princípio não é a utilidade dos diagramas quando se trata de
comunicação entre técnicos, mas entre técnicos e usuários.
Enquanto a compreensão pelos usuários do produto que será
construído é fundamental, é discutível a pertinência do aprendizado
deste tipo de notação (mesmo que apenas para leitura) por pessoas
que são apenas usuários de produtos de software, e que estão
eventualmente envolvidas em projeto de desenvolvimento de
software como fontes de informação e validação de requisitos, mas
não como construtores de programas.