Diretriz: Modelo de Caso de Uso
Esta diretriz descreve como desenvolver e evoluir o modelo de caso de uso para capturar os requisitos funcionais para o sistema em desenvolvimento.
Relacionamentos
Descrição Principal

Introdução

A chave para o êxito do desenvolvimento iterativo é garantir que a equipe de desenvolvimento maximize o valor aos stakeholders e minimize os riscos no início do ciclo de vida, minimizando ao mesmo tempo o re-trabalho posterior. Isto impõe algumas restrições sobre a forma como desenvolvemos o modelo de caso de uso.

Num dos extremos existe a abordagem clássica em cascata, que tenta detalhar todos os requisitos antes do design e da implementação. Esta abordagem atrasa a entrega de valor aos Stakeholders e a redução dos riscos desnecessariamente.

No outro extremo está o início do desenvolvimento antes do entendimento do que o sistema deve fazer. Esta abordagem resulta em significativo, e dispendioso, re-trabalho ao final do ciclo de vida.

A melhor abordagem consiste em detalhar apenas os requisitos que serão o foco do desenvolvimento na próxima iteração (ou na seguinte). A seleção destes requisitos é motivada pelo valor e risco, e, portanto, exige no mínimo um entendimento abstrato da visão contextual.

A discussão a seguir irá descrever o método utilizado para evoluir o modelo de caso de uso, para alcançar essas metas.

Como o Modelo de Caso de Uso Evolui

A abordagem recomendada para a evolução do modelo de caso de uso baseia-se no método "respirar antes de mergulhar". Nesta abordagem, alguém identifica os atores e casos de uso e descreve-os rapidamente. Baseado neste conhecimento, pode-se então realizar uma primeira avaliação dos riscos e prioridades e, então, concentrar os esforços de detalhamento dos casos de uso nas áreas certas.

Concepção

O objetivo da Concepção é entender o escopo do sistema. Temos que compreender o principal objetivo do sistema, o que está dentro do escopo do sistema, e o que é externo ao sistema. Devemos nos esforçar para relacionar todos os principais atores e casos de uso, entretanto, não devemos nos dar ao luxo de detalhar todos os requisitos neste momento. Esforce-se no sentido de identificar, pelo nome, aproximadamente 80% dos principais atores e casos de uso e fornecer uma breve descrição (de uma a três linhas) para cada um.

Identifique os Stakeholders

Comece relacionando todos os Stakeholders externos ao sistema. Estas pessoas serão a fonte dos requisitos.

Identifique os Atores

Nomeie e descreva os principais atores. Veja Diretriz: Encontrar e Descrever Atores e Caos de Uso.

Identifique os Casos de Uso

Para cada ator, pergunte: "o que este ator quer conseguir com o sistema"? Isto revelará os principais casos de uso do sistema. Nomeie e descreva cada um dos casos de uso a medida que você for descobrindo-os.

Atualize o Modelo de Caso de Uso

Atualize o modelo de caso de uso para registrar os nomes e as breves descrições dos atores e casos de uso. Capture a relação entre os atores e os casos de uso.

Descreva os Fluxos Básicos

Para os casos de uso considerados de alta prioridade pelos Stakeholders, ou de alto risco pela equipe de desenvolvimento, capture uma descrição passo-a-passo do Fluxo Básico. Não se preocupe com a estruturação do fluxo neste momento. Concentre-se em captar o diálogo entre o ator e o sistema e os requisitos fundamentais para o sistema.

Identifique os Fluxos Alternativos

A medida que estiver trabalhando nos Fluxos Básicos, pergunte: "O que pode dar errado?"; "Que opções estão disponíveis neste momento?"; etc. Estes tipos de pergunta irão revelar os fluxos alternativos. Capture-os, dando-lhes um nome e uma breve descrição. Não detalhe estes fluxos alternativos neste momento.

Refatore o Modelo de Caso de Uso

Baseado nos Fluxos Básicos que você identificou, determine se existem comportamentos comuns que poderiam ser fatorados em casos de uso <<include>>. Refatore o Modelo de Caso de Uso de acordo com o necessário.

Priorize os Casos de Uso

Dada a descrição abstrata que agora você têm dos requisitos, trabalhe com os Stakeholders para priorizar os casos de uso. Esta será a principal entrada para o planejamento da iteração.

Elaboração

A finalidade da elaboração é demonstrar a viabilidade da solução antes de comprometer recursos adicionais. Para ser bem sucedida, alguém deve demonstrar que o valor aos Stakeholders pode ser entregue e que o risco de continuar é aceitável. Devemos nos esforçar em detalhar e implementar aproximadamente 20% dos cenários. Estes cenários devem ser selecionados para alcançar uma boa cobertura da arquitetura (por exemplo, uma fatia vertical através da arquitetura, tocando tantos componentes e interfaces quanto possível, é preferível ao invés de elaborar somente a Interface de Usuário).

Detalhe o Fluxo Básico

Para os Casos de Uso selecionados para a próxima iteração, invista o tempo detalhando o fluxo básico agora. Veja Diretriz: Detalhar Casos de Uso e Cenários.

Detalhe o Fluxo Alternativo

Para os fluxos alternativos selecionados para a próxima iteração, invista o tempo detalhando os fluxos agora.

Atualize o Modelo de Caso de Uso

Atualize o Modelo de Caso de Uso para capturar qualquer aperfeiçoamento que tenha resultado de seu trabalho. Dependendo da complexidade do sistema, você pode agrupar, de forma lógica, os casos de uso em pacotes para simplificar a comunicação, o planejamento da iteração e o desenvolvimento em paralelo.

Construção

A finalidade da construção é entregar gradativamente a funcionalidade (e o valor). Trabalhando com base no plano de iteração, continue detalhando os requisitos restantes. Almeje a conclusão de aproximadamente 90 a 95% dos casos de uso, até o final da construção.

Detalhe os Fluxos Básicos

Para os Casos de Uso selecionados para a próxima iteração, invista o tempo detalhando o fluxo básico agora. Veja Diretriz: Detalhar Casos de Uso e Cenários.

Detalhe os Fluxos Alternativos

Para os fluxos alternativos selecionados para a próxima iteração, invista o tempo detalhando os fluxos agora.

Atualize o Modelo de Caso de Uso

Atualize o Modelo de Caso de Uso para capturar qualquer aperfeiçoamento que tenha resultado de seu trabalho.

Transição

A finalidade da transição é tornar o sistema operacional em seu ambiente alvo. Alguns requisitos ainda não estarão cobertos até este momento, mas se fizemos as coisas certas, eles não devem afetar o design. Os casos de uso restantes, aproximadamente de 5% a 10%, devem ser detalhados e implementados nesta fase.

Evitando a Decomposição Funcional

Uma armadilha comum para os novatos em modelagem de caso de uso é realizar uma decomposição funcional do sistema. Isto resulta em muitos "casos de uso" pequenos, que isoladamente não entregam o "resultado de valor observável" para o ator. Para evitar isso, preste atenção nos seguintes sintomas:

  • Pequenos casos de uso, significando que a descrição do fluxo de eventos tem apenas uma ou poucas sentenças.
  • Muitos casos de uso, significando que a quantidade de casos de uso conta-se as centenas, e não as dezenas.
  • Nomes de casos de uso tais como "executar esta operação nestes determinados dados" ou " executar  esta função com esses dados". Por exemplo, "Entrar com o Número de Identificação Pessoal num Caixa Eletrônico (ATM)" não deve ser modelado como um caso de uso separado para o Caixa Eletrônico (ATM), porque ninguém usará o sistema para fazer somente isso. Um caso de uso é um fluxo de eventos completo que resulta em algo de valor para um ator.

Para evitar a decomposição funcional, certifique-se que o modelo de caso de uso responde à estas perguntas:

  • Qual é o contexto do sistema?
  • Porque você está construindo este sistema?
  • O que o usuário deseja que o sistema faça?
  • Como os usuários se beneficiarão do sistema?

Estruturando o Modelo de Caso de Uso

Existem três razões principais para estruturar o modelo de caso de uso:

  • Para tornar os casos de uso mais fáceis de entender.
  • Para compartilhar o comportamento comum descrito em vários casos de uso.
  • Para tornar o modelo de caso de uso mais fácil de manter.

Entretanto, a estruturação não é a primeira coisa a ser feita. Não existe vantagem em estruturar os casos de uso até que você conheça um pouco mais de seus comportamentos, além de uma descrição de uma-sentença. Você deve ter feito, pelo menos, uma descrição passo-a-passo do fluxo de eventos do caso de uso para ter certeza que suas decisões são baseadas em uma compreensão exata do comportamento.

Existem vários conceitos avançados de modelagem disponíveis na literatura para a estruturação do modelo de caso de uso, entretanto, seguindo o princípio de "simplicidade" o mais útil deles é o relacionamento <<include>>, discutido neste processo. Este relacionamento permite fatorar o comportamento comum em um caso de uso separado que é "incluído" em outros casos de uso. Veja Conceito: Modelo de Caso de Uso para mais detalhes.

Outro aspecto da estruturação do modelo de caso de uso para facilitar a compreensão, é o agrupamento dos casos de uso em pacotes. O modelo de caso de uso pode ser organizado como uma hierarquia de pacotes de casos de uso. Para obter mais informações sobre os pacotes de casos de uso, veja Conceito: Modelo de Caso de Uso.

Relacionamento entre Casos de Uso e Atores

A execução de cada caso de uso inclui a comunicação com um ou mais atores. Uma instância de um caso de uso é sempre iniciada por um ator pedindo ao sistema para fazer algo. Isto implica que cada caso de uso deve ter associações de comunicação com os atores. A razão para esta regra é assegurar que o sistema forneça somente a funcionalidade que os usuários necessitam e nada mais. A existência de casos de uso que ninguém tenha solicitado é um indício de que algo está errado no modelo de caso de uso ou nos requisitos.

Entretanto, existem algumas exceções a esta regra:

  • Um caso de uso <<include>> não pode interagir com um ator, se o caso de uso base o fizer.
  • Um caso de uso pode ser iniciado de acordo com um agendamento (por exemplo, uma vez por semana ou uma vez por dia), o que significa que o relógio do sistema é quem inicia. O relógio do sistema é interno ao sistema; portanto, o caso de uso não é iniciado por um ator, mas por um evento interno do sistema. Se nenhuma interação de outro ator ocorrer no caso de uso, ele não terá qualquer associação com atores. No entanto, por uma questão de clareza, você pode usar o "tempo" como um ator para mostrar como o caso de uso é iniciado nos seus diagramas de caso de uso. ATENÇÃO: se você tiver vários atores "tempo" no seu modelo, questione-os. Talvez você não tenha notado a existência de um ator verdadeiro, tal como um administrador responsável pelo agendamento de relatórios, etc.
Informações Adicionais