Diretrizes: Caso de Uso
Caso de Uso
Uma instância de casos de uso é uma seqüência de ações realizadas por um sistema, que gera um resultado
observável de valor para um determinado ator.
Um caso de uso define um conjunto de instâncias de casos de uso.
Tópicos
Explicação
Como Identificar Casos de Uso Como um Caso de Uso Evolui
Todos os Casos de Uso São Descritos Detalhadamente? O Escopo de um Caso de Uso
Como os Casos de Uso são Realizados
Um Caso de Uso Tem Muitas Instâncias Possíveis Concorrência de Instâncias de Casos de Uso Nome
Breve Descrição
Fluxo de Eventos - Conteúdo Fluxo de Eventos - Estrutura Fluxo de Eventos - Estilo Fluxo de Eventos - Exemplo Requisitos Especiais
Precondições e Pós-condições Pontos de Extensão
Diagramas de Casos de Uso
Explicação
Há várias palavras-chave nessa definição:
Instância de casos de uso. A seqüência citada na definição é realmente um fluxo de
eventos específico do sistema ou uma instância. Muitos fluxos de eventos são possíveis e muitos podem ser bem parecidos. Para tornar um modelo de casos de uso compreensível, você deve agrupar os fluxos de eventos semelhantes em um caso de uso. Identificar e descrever um caso de uso realmente significa identificar e descrever um grupo de fluxos de eventos relacionados.
Realizadas por um sistema. Isso significa que o sistema fornece o caso de uso. Um
ator se comunica com a instância de casos de uso do sistema.
Um resultado observável de valor. Você pode atribuir um valor a um caso de uso
executado com sucesso. Um caso de uso deve verificar se um ator pode realizar uma tarefa que tem um valor identificável. Isso é muito importante na determinação do nível correto ou da granularidade de um caso de uso. Nível correto significa alcançar
os casos de uso que não são muito pequenos. Em determinadas circunstâncias, você pode usar um caso de uso como uma unidade de planejamento em uma organização que contém indivíduos que são atores no sistema.
Ações. Uma ação é um procedimento computacional ou algorítmico. Ela é disparada
quando o ator fornece um sinal ao sistema ou quando o sistema obtém um evento de tempo. Uma ação pode implicar transmissões de sinais para o ator chamado ou outros atores. Uma ação é atômica, o que significa que é realizada integralmente ou não.
Um determinado ator. O ator é importante para encontrar o caso de uso correto,
especialmente porque ele ajuda você a evitar casos de uso muito grandes. Como exemplo, considere uma ferramenta de modelagem visual. Há dois atores nesse aplicativo: um desenvolvedor - alguém que desenvolve sistemas usando a ferramenta como suporte e um administrador do sistema - alguém que gerencia a ferramenta. Cada um desses atores tem suas próprias demandas no sistema e, portanto, precisa do seu próprio conjunto de casos de uso.
A funcionalidade de um sistema é definida por casos de uso diferentes, onde cada um
representa um fluxo de eventos específico. A descrição de um caso de uso define o que ocorre no sistema quando o caso de uso é executado.
Em um caixa eletrônico, o cliente pode, por exemplo, retirar dinheiro de uma conta, transferir dinheiro para uma conta ou verificar o saldo de uma conta. Essas funções
correspondem a fluxos que você pode representar com casos de uso.
Cada caso de uso tem uma tarefa própria para realizar. Os casos de uso coletados constituem todas as maneiras possíveis de usar o sistema. Você pode obter uma idéia de uma tarefa de casos de uso simplesmente observando o seu nome.
Como Identificar Casos de Uso
Segue, abaixo, um conjunto de perguntas úteis para identificar os casos de uso:
Para cada ator identificado, quais são as tarefas nas quais o sistema estaria envolvido? O ator precisa estar informado sobre certas ocorrências no sistema?
O ator precisa informar o sistema sobre mudanças externas repentinas? O sistema fornece ao negócio o comportamento correto?
Todos as características podem ser realizadas pelos casos de uso identificados? Que casos de uso suportarão e manterão o sistema?
Casos de uso que às vezes são omitidos, uma vez que eles não representam aquelas que geralmente são as funções primárias do sistema, podem ser dos seguintes tipos:
Início e fim do sistema.
Manutenção do sistema. Por exemplo, adicionar novos usuários e configurar os perfis de usuário.
Manutenção dos dados armazenados no sistema. Por exemplo, o sistema é criado para trabalhar junto com um sistema legado, e os dados precisam ser sincronizados entre os dois.
Funcionalidade necessária para modificar o comportamento no sistema. Um exemplo seria a funcionalidade para criar novos relatórios.
Se você desenvolveu um modelo de casos de uso do negócio e um modelo de objetos do negócio, consulte tambémDiretrizes: Transição de Modelos de Negócios para Sistemas.
Como um Caso de Uso Evolui
Nas iterações iniciais da elaboração, apenas alguns casos de uso (os que são considerados significativos para a arquitetura) são descritos detalhadamente além da breve descrição. Você sempre deve desenvolver primeiro um esquema do caso de uso (no formato passo a passo) antes de se aprofundar nos detalhes. Esse esquema passo a passo deve ser a primeira tentativa de definir a estrutura do fluxo de eventos do caso de uso (consulteFluxo de Eventos
-Estruturaabaixo). Sempre comece com o fluxo básico do caso de uso. Depois que houver algum acordo sobre o esquema do fluxo básico, você pode adicionar o que os fluxos alternativos devem ser em relação ao fluxo básico.
Em direção ao fim da elaboração, todos os casos de uso planejados para serem descritos detalhadamente devem ser concluídos.
Todos os Casos de Uso São Descritos Detalhadamente?
Geralmente, há casos de uso tão simples no modelo que não precisam de uma descrição detalhada do fluxo de eventos, um esquema passo a passo é suficiente. Os critérios para tomar essa decisão são: que você não perceba inconsistência entre os usuários leitores sobre a que o caso de uso se refere e que os designers e os testadores estejam confortáveis com o nível de detalhe fornecido pelo formato passo a passo. Os exemplos são casos de uso que descrevem a entrada simples ou a recuperação de alguns dados do sistema.
O Escopo de um Caso de Uso
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.
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, um caso de uso.
Além disso, você deseja manter as duas ações juntas, para poder verificá-las ao mesmo tempo, modificá-las e testá-las juntas, escrever manuais para elas e gerenciá-las como uma unidade. Esse procedimento torna-se bem óbvio em sistemas maiores.
Como os Casos de Uso são Realizados
Um caso de uso descreve o que ocorre no sistema quando um ator interage com o sistema para executar o caso de uso. O caso de uso não define como o sistema executa internamente suas tarefas em termos de objetos de colaboração. Mostrar esse procedimento é tarefa das realizações de casos de uso.
Exemplo:
No exemplo do telefone, o caso de uso indica, entre outros pontos, que o sistema emite um sinal quando o fone é retirado do gancho e que o sistema recebe os dígitos, encontra a parte receptora, toca o telefone, conecta a chamada, transmite a fala etc. Em um sistema em execução, uma instância de um caso de uso não corresponde a qualquer objeto específico no modelo da implementação (por exemplo, uma instância de uma classe no código). Em vez disso, corresponde a um fluxo específico de eventos que é disparado por um ator e executado como uma seqüência de eventos entre um conjunto de objetos. Em outras palavras, as instâncias de casos de uso correspondem a instâncias de comunicação dos objetos implementados. Esse processo é denominado realização do caso de uso. Geralmente, os mesmos objetos participam das realizações de mais de um caso de uso. Por exemplo, os casos de uso Depósito e Retirada em um sistema bancário podem usar um determinado objeto de conta na sua realização. Isso não significa que os dois casos de uso se comunicam, apenas que usam o mesmo objeto na sua realização.
Você pode visualizar um fluxo de eventos composto por vários subfluxos, que juntos compõem o fluxo total dos eventos. É possível reutilizar a descrição de um subfluxo em fluxos de eventos de outros casos de uso. Os subfluxos, na descrição de um fluxo de eventos do caso de uso, podem ser comuns aos de outros casos de uso. No design, você deve ter os mesmos objetos com esse comportamento comum para todos os casos de uso relevantes, ou seja, apenas um conjunto de objetos deve ter esse comportamento, independentemente do caso de uso que esteja executando.
Exemplo:
Em um sistema de caixa eletrônico, o subfluxo inicial é o mesmo no fluxo de eventos dos casos de uso Retirar Dinheiro e Verificar Saldo. O fluxo de eventos dos dois casos de uso começa verificando a identidade do cartão e o código de acesso pessoal do cliente.
Um Caso de Uso Tem Muitas Instâncias Possíveis
Uma instância de casos de uso pode seguir um número de caminhos quase ilimitado, mas enumerável. Esses caminhos representam as opções abertas para a instância de casos de uso na descrição do fluxo de eventos. O caminho escolhido depende dos eventos. Os tipos de eventos incluem:
Entrada de um ator. Por exemplo, um ator por decidir, dentre várias opções, o que fazer em seguida.
Exemplo:
No caso de uso Reciclar Itens, no Sistema da Máquina de Reciclagem, o cliente tem sempre duas opções: entregar outro item de depósito ou obter o recibo de itens devolvidos.
Uma verificação de valores ou de tipos de um objeto ou atributo interno. Por exemplo, o fluxo de eventos pode ser diferente se um valor for maior ou menor do que um determinado valor.
Exemplo:
No caso de uso Retirar Dinheiro em um sistema de caixa eletrônico, o fluxo de eventos será diferente, se o Cliente solicitar mais dinheiro do que ele tem na conta. Portanto, a instância de casos de uso seguirá caminhos diferentes.
Concorrência de Instâncias de Casos de Uso
Instâncias de vários casos de uso e várias instâncias do mesmo caso de uso funcionam ao mesmo tempo, se o sistema permitir isso. Na modelagem de casos de uso, você pode assumir que as instâncias de casos de uso podem estar ativas ao mesmo tempo sem conflito. Espera-se que o modelo do design resolva esse problema, porque a modelagem de casos de uso não descreve como eles funcionam. Uma maneira de visualizar isso é assumir que apenas uma instância de casos de uso está ativa no momento e que executar essa instância é uma ação atômica. Na modelagem de casos de uso, a "máquina interpretadora" é considerada infinitamente rápida, para que a serialização das instâncias do caso de uso não seja um problema.
Nome
Cada caso de uso deve ter um nome que indica o que é alcançado pela interação com o ator. Talvez o nome precise ter várias palavras para ser entendido. Dois casos de uso não podem ter o mesmo nome.
Exemplo:
Estes são exemplos de variações do nome do caso de uso Reciclar Itens no exemplo da Máquina de Reciclagem:
Receber Itens de Depósito
Recebimento de Itens de Depósito Devolver Itens de Depósito Itens de Depósito
Breve Descrição
A breve descrição do caso de uso deve refletir sua finalidade. Ao escrever a descrição, faça referência aos atores envolvidos no caso de uso, ao glossário e, se precisar, defina novos conceitos.
Exemplo:
Segue, abaixo, amostras de breves descrições dos casos de uso Reciclar Itens e Adicionar Novo Tipo de Garrafa no Sistema da Máquina de Reciclagem:
Reciclar Itens: O usuário usa essa máquina para contar automaticamente todos os
itens devolvidos (garrafas, latas e caixotes) e receber um recibo. O recibo deve ser pago em uma caixa registradora (máquina).
Adicionar Novo Tipo de Garrafa: Novos tipos de garrafas podem ser adicionados à
máquina, iniciando-a no 'modo de aprendizagem' e inserindo 5 amostras, como na devolução de itens. Assim, a máquina pode medir as garrafas e aprender a
identificá-las. O gerente especifica o valor do reembolso para o novo tipo de garrafa.
Fluxo de Eventos - Conteúdo
O Fluxo de Eventos de um caso de uso contém as informações mais importantes derivadas da modelagem de casos de uso. Ele deve descrever o fluxo de eventos do caso de uso claramente, para que alguém de fora o entenda facilmente. Lembre-se de que o fluxo de eventos deve apresentar o que o sistema faz, e não como é o design do sistema para realizar o
comportamento exigido.
As diretrizes para o conteúdo do fluxo de eventos são: Descreva como o caso de uso começa e termina
Descreva os dados que são trocados entre o ator e o caso de uso
Não descreva os detalhes da interface do usuário, a menos que seja necessário entender o comportamento do sistema. Por exemplo, freqüentemente é bom usar um conjunto limitado de terminologia específica da web quando se sabe antecipadamente que o aplicativo será baseado em web. Caso contrário, você corre o risco de o texto dos casos de uso ficar muito abstrato. As palavras a serem incluídas na terminologia poderiam ser "navegar", "procurar", "hyperlink" "página", "enviar" e "navegador". Entretanto, não é aconselhável incluir as referências a "frames" ou "páginas de web" de tal maneira que você esteja fazendo suposições sobre as fronteiras entre elas - essa é uma decisão importante do design.
cada ação com "Quando o ator... "
Descreva somente os eventos que pertencem ao caso de uso e não o que ocorre em outros casos de uso ou fora do sistema
Evite terminologia vaga, como "por exemplo", "etc. " e "informações"
Detalhe o fluxo de eventos - todos os"o quê" devem ser respondidos. Lembre-se de que os designers do teste devem usar esse texto para identificar os casos de teste. Se você usou determinados termos em outros casos de uso, verifique se usou exatamente os mesmos termos neste caso de uso e se o significado pretendido é o mesmo. Para gerenciar os termos comuns, coloque-os em um glossário.
Fluxo de Eventos - Estrutura
As duas principais partes do fluxo de eventos são o fluxo de eventos básico e o fluxos de
eventos alternativos. O fluxo de eventos básico deve abordar o que "geralmente" ocorre
quando o caso de uso é executado. Os fluxos de eventos alternativos abordam o
comportamento de caráter opcional ou excepcional em relação ao comportamento normal e também as variações do comportamento normal. Você pode pensar nos fluxos de eventos alternativos como "desvios" do fluxo de eventos básico, alguns dos quais voltarão ao fluxo de eventos básico e alguns finalizarão a execução do caso de uso.
A estrutura típica do fluxo de eventos. A seta reta representa o fluxo de eventos básico e as setas curvas representam os caminhos alternativos em relação ao normal. Alguns caminhos alternativos voltam ao fluxo de eventos básico, enquanto outros finalizam o
caso de uso.
Tanto o fluxo de eventos básico quanto os fluxos de eventos alternativos devem ser
estruturados em passos e subfluxos. Com isso, a principal meta deve ser a legibilidade do texto (consulte também a seçãoFluxo de Eventos - Estiloabaixo). Uma maneira prática de proceder é a seguinte: um subfluxo deve ser um segmento de comportamento no caso de uso que tem uma finalidade clara, e ser "atômico" no sentido de que você realiza todas ou nenhuma das ações descritas. Você pode precisar de vários níveis de subfluxos mas evite, se puder, pois isso torna o texto mais complexo e difícil de entender. É possível ilustrar a estrutura do fluxo de eventos com um diagrama de atividades, consulteDiretrizes: Diagrama de Atividades no Caso de Uso.
natureza do texto, que há uma seqüência entre os subfluxos. Para evitar mal-entendidos, você sempre deve indicar se a ordem dos subfluxos é fixa ou não. As considerações desse tipo freqüentemente se relacionam a:
Regras de negócios. Por exemplo, o usuário deve ser autorizado para que o sistema possa disponibilizar certos dados.
Design da interface do usuário. Por exemplo, o sistema não deve impor uma determinada seqüência de comportamentos que pode ser intuitiva para alguns, mas não para outros usuários.
Para esclarecer onde um fluxo de eventos alternativo se encaixa na estrutura, é necessário descrever o seguinte para cada "desvio" no fluxo de eventos básico:
Onde o comportamento alternativo pode ser inserido no fluxo de eventos básico. A condição que precisa ser atendida para que o comportamento alternativo comece. Como e onde o fluxo de eventos básico é retomado, ou como o caso de uso termina. Exemplo:
Este é um subfluxo alternativo no caso de uso Devolver Itens no Sistema da Máquina de Reciclagem.
2.1. Garrafa Emperrada
Se na seção 1.5, Inserir Itens de Depósito, uma garrafa ficar emperrada na porta, os sensores em torno da porta e a porta da medição detectarão esse problema. A esteira transportadora é parada e a máquina emite um alarme para chamar o operador. A máquina aguardará o operador indicar que o problema foi resolvido. A máquina continua na seção 1.9 do fluxo básico.
No exemplo acima, o fluxo de eventos alternativo é inserido em um local específico no fluxo de eventos básico. Há também um fluxo de eventos alternativo que pode ser inserido em mais de um local, alguns até podem ser inseridos em qualquer local do fluxo de eventos básico.
Exemplo:
Este é um subfluxo alternativo no caso de uso Devolver Itens no Sistema da Máquina de Reciclagem.
2.2. Painel Frontal Removido
Se alguém remover o painel frontal da Máquina de Reciclagem, a compactação das latas é desativada. Não será possível iniciar a compactação das latas com o painel frontal desativado. A remoção também ativará um alarme para o operador. Quando o painel frontal estiver fechado novamente, a máquina continuará a operação a partir do local em que parou no fluxo de eventos básico.
Se o fluxo de eventos alternativo for muito simples, pode ser tentador descrevê-lo apenas na seção do fluxo de eventos básico (usando algum construção informal "if-then-else"). Isso deve ser evitado. Muitas alternativas dificultarão o exame do comportamento normal. Além disso, incluir caminhos alternativos na seção do fluxo de eventos básico tornará o texto mais
"parecido com pseudocódigo" e mais difícil de ler.
Em geral, a extração de partes do fluxo de eventos e a descrição dessas partes separadamente podem aumentar a legibilidade do fluxo de eventos básico e melhorar a estrutura do caso de uso e do modelo de casos de uso. Você pode modelar as partes extraídas como:
Um fluxo de eventos alternativo no caso de uso base, se for uma variante simples, uma opção ou uma exceção no fluxo de eventos básico.
Uma inclusão explícita no caso de uso base (consulteDiretrizes: Relacionamento de Inclusão) se for algo que você deseje encapsular para que possa ser reutilizado por outros casos de uso.
Uma inclusão implícita no caso de uso base (consulteDiretrizes: Relacionamento de Extensão), se o fluxo de eventos básico do caso de uso base estiver completo, ou seja, se tiver um início e um fim definidos. A natureza do fluxo de extensão deve ser da maneira que você preferir ocultá-lo na descrição do caso de uso base para que fique menos complexo.
Um subfluxo no fluxo de eventos básico, possivelmente como outra opção, se nenhuma das alternativas acima se aplica. Por exemplo, em um caso de uso Manter Informações do Funcionário, podem existir subfluxos separados para adicionar, excluir e modificar as informações do funcionário.
Fluxo de Eventos - Estilo
Você pode descrever os casos de uso de várias maneiras. Como exemplo, será apresentado o fluxo de eventos básico do caso de uso Administrar Ordem descrito em três estilos diferentes, variando principalmente na formalidade. O primeiro estilo, mostrado noexemplo 1abaixo, é recomendado porque é fácil de entender, e a ordem em que tudo acontece é claramente evidente. O texto é dividido em subseções numeradas e identificadas. Os números servem para facilitar a referência a uma subseção. Os nomes das subseções permitirão que o leitor obtenha uma visão geral rápida do fluxo de eventos, navegando pelo texto e lendo apenas os títulos. Noexemplo 2abaixo, a descrição do fluxo de eventos falha ao esclarecer a ordem em que tudo acontece. Se escrever neste estilo, você e os outros podem perder informações importantes referentes ao sistema.
OExemplo 3abaixo mostra um outro estilo, que pode ser útil, caso você ache difícil expressar a seqüência de eventos claramente. Esse estilo de pseudocódigo é mais preciso, mas o texto é de difícil leitura e absorção por uma pessoa que não seja técnica, especialmente se você deseja compreender o fluxo de eventos rapidamente.
Exemplo 1:
1.1. Início do Caso de Uso
Este caso de uso começa quando o ator Operador configura o sistema para criar uma ordem de medição. O sistema recuperará todos os atores
Elemento da Rede, seus objetos de medição e as funções de medição correspondentes que estiverem disponíveis para esse Operador específico.
Os Elementos de Rede disponíveis são aqueles que estão em operação e os que o Operador tem permissão para acessar. A disponibilidade das funções de medição depende do que foi configurado para um determinado tipo de objeto de medição.
1.2. Configurar Ordem de Medição
O sistema permite que o ator Operador selecione os Elementos da Rede que serão medidos e, em seguida, mostre os objetos de medição que estão disponíveis para os Elementos de Rede selecionados. O sistema permite que o Operador selecione a partir dos objetos de medição e, em seguida, selecione as funções de medição que serão configuradas para cada objeto de medição.
O sistema permite que o Operador insira um comentário textual na ordem de medição.
O Operador configura o sistema para completar a ordem de medição. O sistema responderá gerando um nome exclusivo para a ordem de medição e configurando os valores padrão para quando, com que freqüência e por quanto tempo a medição deve ser feita. Os valores padrão são exclusivos para cada Operador. O sistema permite, em seguida, que o Operador edite esses valores padrão.
1.3. Inicializar Ordem
O Operador configura o sistema para inicializar a ordem de medição. O sistema registrará a identidade do Operador, a data da criação e o status "Programada" da ordem de medição.
1.4. Fim do Caso de Uso
O sistema confirma a inicialização da ordem de medição para o Operador, e a ordem de medição fica disponível para que os outros atores possam ver.
Descrição de um caso de uso. Neste estilo, é fácil ler o texto e acompanhar o fluxo de eventos. Tenha este estilo como meta nas suas descrições.
Exemplo 2:
Os ordenadores podem criar Ordens para coletar os dados da medição dos Elementos da Rede.
O sistema atribuirá à Ordem um nome exclusivo, bem como valores padrão que indicam o comprimento e o tempo da medição, além da freqüência em que é repetida. O Ordenador poderá editar esses valores. Ele deve especificar mais a função da medição, o elemento de rede e os
objetos de medição que se aplicam. O Ordenador também pode adicionar um comentário pessoal à ordem.
Quando as informações necessárias foram definidas, uma nova Ordem foi criada e inicializada com os atributos definidos, o nome do criador e a data de criação. O status da ordem será definido como "programada". (Os possíveis valores do status são: Programada, Em Execução, Concluída, Cancelada e Errada.)
A interface do usuário é notificada de que uma nova Ordem foi criada e recebe uma referência para a nova Ordem para que ela possa ser exibida.
Descrição de um caso de uso: este estilo é legível, mas não há um fluxo de eventos claro.
Exemplo 3:
'Administrate order' (User identity) REPEAT
<='Show administer order menu'
IF (=> 'Creating an Order' (Measurement function, network element, measurement object)) THEN
The system finds a unique name, default values for when and how long the measurement should be executed.
<= 'Show order' (Default attributes) REPEAT
=> 'Edit order' (Attribute to change, New value of attribute) <= 'Update screen' (New attributes)
UNTIL (All attributes are defined) REPEAT
IF (=> 'Edit order' (Attribute to change, New value of attribute)) THEN <= 'Update screen' (New attributes)
ELSIF (=> 'Save order' (Order identity, Attributes)) THEN The order is created and initialized in the system with the defined attributes, the name of the creator, date of creation and the status 'scheduled'. <= 'New order created' (The order)
ENDIF UNTIL (=> 'Quit') ENDIF
UNTIL 'Quit administer order'
Descrição de um caso de uso: aqui, o escritor escolheu um estilo formal usando pseudocódigo. Este estilo dificulta a compreensão rápida dos passos do processo,
mas pode ser útil, se o fluxo de eventos for difícil de capturar com exatidão.
Fluxo de Eventos - Exemplo
A descrição completa do fluxo de eventos do caso de uso Administrar Ordem, incluindo os fluxos alternativos, pode ser semelhante a:
1. Fluxo de Eventos Básico 1.1. Início do Caso de Uso
Este caso de uso começa quando o ator Operador configura o sistema para criar uma ordem de medição. O sistema recuperará todos os atores Elemento da Rede, seus objetos de medição e as funções de medição correspondentes que estiverem disponíveis para esse Operador específico.
Os Elementos de Rede disponíveis são aqueles que estão em operação e os que o Operador tem permissão para acessar. A disponibilidade das funções de medição depende do que foi
configurado para um determinado tipo de objeto de medição.
1.2. Configurar Ordem de Medição
O sistema permite que o ator Operador selecione os Elementos da Rede que serão medidos e, em seguida, mostre os objetos de medição que estão disponíveis para os Elementos de Rede selecionados. O sistema permite que o ator Operador selecione a partir desses objetos de medição e, em seguida, selecione as funções de medição a serem configuradas para cada objeto de medição.
O sistema permite que o Operador insira um comentário textual na ordem de medição. O Operador configura o sistema para completar a ordem de medição. O sistema responderá gerando um nome exclusivo para a ordem de medição e configurando os valores padrão para quando, com que freqüência e por quanto tempo a medição deve ser feita. Os valores padrão são exclusivos para cada Operador. O sistema permite, em seguida, que o Operador edite esses valores padrão.
1.3. Inicializar Ordem
O Operador configura o sistema para inicializar a ordem de medição. O sistema registrará a identidade do Operador, a data da criação e o status "Programada" da ordem de medição.
1.4. Fim do Caso de Uso
O sistema confirma a inicialização da ordem de medição para o Operador, e a ordem de medição fica disponível para que os outros atores possam ver.
2. Fluxos de Eventos Alternativos
2.1. Nenhum Elemento de Rede Disponível
Se em 1.1, Início do Caso de Uso, nenhum Elemento da Rede estiver disponível para ser medido por esse Operador, o sistema informará ao Operador. O caso de uso está concluído.
2.2. Nenhuma Função de Medição Disponível
Se em 1.2, Configurar Ordem de Medição, nenhuma função de medição estiver disponível para os Elementos da Rede selecionados, o sistema informará ao Operador e permitirá que o
Operador selecione outros elementos de Rede.
2.3. Cancelar Ordem de Medição
O sistema permitirá que o Operador cancele todas as ações a qualquer momento durante a execução do caso de uso. O sistema voltará ao estado em que estava antes do início do caso de uso, e o caso de uso será concluído.
Nos Requisitos Especiais de um caso de uso, você descreve todos os requisitos no caso de uso que não são abordados pelo fluxo de eventos. Esses requisitos não funcionais influenciarão o modelo do design. Consulte também a discussão sobre requisitos não funcionais emDiretrizes: Modelo de Casos de Uso. Você pode organizar esses requisitos em categorias como
Usabilidade, Confiabilidade, Desempenho e Capacidade de Substituição, mas geralmente há tão poucos deles que esses agrupamentos não são particularmente úteis.
Exemplo:
No Sistema da Máquina de Reciclagem, um requisito especial do caso de uso Devolver Itens de Depósito poderia ser:
A máquina deve ser capaz de reconhecer os itens de depósito com uma confiabilidade de mais de 95%.
Precondições e Pós-condições
Pode ser útil usar a noção de precondição e pós-condição para esclarecer como o fluxo de eventos começa e termina. Entretanto, só use isso se for agregar valor ao público do caso de uso.
Uma precondição é o estado do sistema e da sua vizinhança, que é exigido antes do início do caso de uso. Uma pós-condição é o estado que o sistema pode apresentar
após o término do caso de uso.
Considere o seguinte:
Os estados descritos pelas precondições e pós-condições devem ser estados que o usuário pode observar. "O usuário fez login no sistema" ou "O usuário abriu o documento" são exemplos de estados observáveis.
Uma precondição é uma restrição sobre quando um caso de uso pode começar. Não é o evento que inicia o caso de uso.
A precondição de um caso de uso não é apenas para um subfluxo, apesar de ser possível definir precondições e pós-condições no nível do subfluxo.
A pós-condição de um caso de uso deve ser verdadeira independentemente dos fluxos alternativos que foram executados; não deve ser verdadeira apenas para o fluxo principal. Se houver possibilidade de falha, você abordará isso na pós-condição informando que "A ação está concluída. E se ocorrer alguma falha, a ação não será realizada", em vez de apenas "A ação está concluída".
Quando você usa pós-condições junto com os relacionamentos de extensão, deve tomar cuidado para que o caso de uso estendido não introduza um subfluxo que viole a pós-condição no caso de uso base.
Pós-condições podem ser uma ferramenta poderosa para descrever casos de uso. Você define primeiro o caso de uso que pretende alcançar a pós-condição. É possível descrever como alcançar essa condição (o fluxo de eventos necessário).
Exemplo:
Uma precondição para o caso de uso Retirada em Dinheiro no caixa eletrônico: O cliente tem um cartão distribuído pessoalmente que se encaixa na leitora de cartões, recebeu um número PIN e está registrado com o sistema bancário.
Uma pós-condição para o caso de uso Retirada em Dinheiro no caixa eletrônico: No fim do caso de uso, todos os registros da conta e da transação são verificados, a comunicação com o sistema bancário é reinicializada e o cliente recebe o cartão de volta.
Pontos de Extensão
Um ponto de extensão abre o caso de uso para a possibilidade de uma extensão. Ele tem um nome e uma lista de referências para um ou mais locais no fluxo de eventos do caso de uso. Um ponto de extensão pode fazer referência a um único local entre dois passos do comportamento no caso de uso. Também pode fazer referência a um conjunto de locais diferentes.
Usar os pontos de extensão com nome ajuda a separar a especificação do comportamento do caso de uso estendido dos detalhes internos do caso de uso base. O caso de uso base pode ser modificado ou reorganizado, contanto que os nomes dos pontos de extensão permaneçam os mesmos e isso não afete o caso de uso estendido. Ao mesmo tempo, você não está carregando o texto que descreve o fluxo de eventos do caso de uso base com os detalhes do local em que o comportamento pode ser estendido. Consulte tambémDiretrizes: Relacionamento de Extensão.
Exemplo:
Em um sistema telefônico, o caso de uso Fazer Chamada pode ser estendido pelo
caso de uso abstratoMostrar Identidade do Chamador. Trata-se de um serviço opcional, também conhecido como "ID do Chamador", que pode ou não ter sido solicitado pelo receptor. Uma descrição do ponto de extensão no caso de uso Fazer Chamada pode ser semelhante a:
Local: Após a seção 1.9 Tocar Telefone da Parte Receptora.
Diagramas de Casos de Uso
Você pode optar por ilustrar como um caso de uso se relaciona com os atores e com outros casos de uso em um diagrama de casos de uso (raramente, em mais de um diagrama), pertencente ao caso de uso. Esse procedimento é útil se o caso de uso estiver envolvido com muitos atores ou se tiver relacionamentos com muitos outros casos de uso. Um diagrama desse tipo é de caráter "local", já que mostra o modelo de casos de uso do ponto de vista de um caso de uso apenas e não pretende explicar qualquer fato geral sobre o todo o modelo de casos de uso. Consulte tambémDiretrizes: Diagrama de Casos de Uso.
Copyright (c) 1987 - 2001 Rational Software Corporation
