A definição de Kruchten (2001) pode ser desmembrada na definição dos seus principais termos:
• Ator é “algo ou alguém que não faz parte, mas interage com o sistema” (IEEE, 2005). Normalmente, descreve usuários ou outros sistemas, com os quais o sistema se integra.
• Ação é “procedimento computacional ou algorítmico que é invocado quando um ator dá um sinal para o sistema” (KRUCHTEN, 2001) e pode levar a transmissão de informação ou para o ator gerador do sinal ou outros atores.
• A seqüência de ações refere-se a um fluxo de eventos que ocorrem no sistema. Diferentes fluxos são possíveis, em um mesmo caso de uso (KRUCHTEN, 2001). • Por “que o sistema executa”, entenda-se aquilo que o sistema faz para realizar a
seqüência de ações. O principal objetivo é descrever claramente as responsabilidades do sistema, trançando uma fronteira com o que está fora dele (KRUCHTEN, 2001).
• É importante notar que o caso de uso leva ao resultado de valor observável, e que, portanto, o ator não deve ter de passar por vários casos de uso para obter algo útil do seu ponto de vista. Essa proximidade com a visão dos atores deve permitir maior entendimento e envolvimento dos clientes/usuários e melhorar a capacidade
de análise o impacto de mudanças que sejam requeridas por eles (KRUCHTEN, 2001).
A parte mais importante de uma especificação do caso de uso é o seu fluxo de eventos. O fluxo de eventos descreve a seqüência de ações entre o sistema e o(s) ator(es). Ele deve ser escrito em linguagem natural, de modo simples e utilizando termos precisos, preferencialmente baseados em um glossário (Cockbrun, 1999). A Figura 3 traz o exemplo do que poderia ser o caso de uso “Realizar Saque” um sistema de caixa-eletrônico. O fluxo de eventos é dividido em fluxo básico e fluxos alternativos. O fluxo básico descreve os passos através dos quais o ator que invoca o caso de uso obtém o resultado esperado da forma mais direta possível e também é conhecido como “caminho feliz”. Os fluxos alternativos descrevem o que ocorre em casos de exceção na execução do fluxo básico, tal como erros, outras formas de se obter o resultado, situações específicas (IEEE, 2005).
Caso de Uso: Realizar Saque Atores: Correntista (humano),
Sistema de Controle de Conta Corrente (sistema)
Descrição: Este caso de uso descreve o processo pelo qual o cliente realiza um saque. Os fluxos alternativos tratam situações de falta de saldo, senha incorreta ou desistência.
Fb Fluxo Básico
a1 O caso de uso se inicia quando o correntista passa o cartão no leitor do caixa eletrônico.
a2 O sistema lê e armazena as informações do cartão (tipo do cartão, agência e número da conta corrente)
a3 O sistema apresenta para o correntista a tela com as opções de operação para a escolha
a4 O correntista seleciona a opção de saque
a5 O sistema apresenta a tela para entrada do valor do saque a6 O correntista informa o valor desejado
a7 O sistema apresenta a tela para entrada da senha a8 O correntista informa sua senha
a9 O sistema acessa o Sistema de Controle de Conta Corrente e checa se a senha é válida e se há saldo para o saque
A10 Se há saldo e a senha está correta o sistema libera o valor para o correntista e encerra a operação (volta para a tela inicial)
Fa1 Fluxo Alternativo: Senha incorreta
A11 Se no passo a8 a senha informada está incorreta o sistema apresenta uma tela com uma mensagem de erro “Senha incorreta” e opções para cancelar a operação ou introduzir nova senha
A12 Se o correntista deseja entrar nova senha o sistema volta para o passo a7, caso contrário encerra a operação e volta para a tela inicial
Fa2 Fluxo Alternativo: Saldo insuficiente
A13 Se, no passo a9, o correntista não possui saldo suficiente o sistema apresenta uma tela com mensagem de erro “Senha incorreta” e opções para cancelar a operação ou introduzir um novo valor para o saque A14 Se o correntista deseja tentar com um outro valor, o sistema volta
para o passo a6, caso contrário encerra a operação e volta para a tela inicial
Fa3 Fluxo Alternativo: Sem dinheiro disponível
A15 Se, no passo 6, a máquina não possui dinheiro suficiente para realizar o saque desejado pelo correntista, não aceita o valor e apresenta mensagem “Caixa sem dinheiro suficiente: favor entrar um valor mais baixo”.
Figura 3 – Exemplo de uma especificação do fluxo de eventos
Os cenários são instâncias de um caso de uso. São combinações possíveis dos fluxos de eventos, que levam o ator a obter o resultado de valor observável de diferentes maneiras; ou mesmo não permitem que ele o consiga, em caso de erros, por exemplo. O mais importante em relação aos cenários, é que eles são seqüências distintas de eventos, dentre as muitas possíveis descritas em um caso de uso. Assim sendo, a partir dos cenários podem-se definir casos de teste que descrevem como o sistema deve ser usado para que determinados comportamentos sejam testados, ou neste caso, redocumentados.
Os casos de uso podem ser organizados em um Modelo de Casos de Uso (RUP, 2007). O Modelo de Casos de Uso contém os casos de uso e os atores e pode ainda agregar pacotes de caso de uso para o seu agrupamento, relacionamentos entre os elementos do modelo e diagramas. A UML® prevê a representação de casos de uso em diagramas de casos de uso. Mas outros artefatos como diagramas de seqüência e diagramas de atividade podem ser usados para modelar os cenários de casos de uso e tornar mais clara a especificação.
Uma questão importante que envolve os casos de uso é que, respeitados os elementos citados acima, não existe uma forma de apresentação do documento de especificação que seja definitiva. Diferentes autores apresentaram suas versões de como o documento pode ser; Cockburn (2000) catalogou em seu livro algumas destas opções.