A construção do modelo de casos de uso

Através da atribuição de importância segundo a categorização de Cantor, um caso de uso não tão importante não será contemplado nas iterações iniciais. Se o requisito correspondente a esse caso de uso for modificado ou não mais precisar ser considerado, os analistas não terão desperdiçado tempo com ele.

Note também que a descrição expandida de um determinado caso de uso é deixada para a iteração na qual este deve ser implementado. Isso evita que se perca tempo inicialmente no seu detalhamento. Além disso, essa estratégia é mais adaptável aos requisitos voláteis. Se todos os casos de uso forem detalhados inicialmente, e se um ou mais requisitos são modificados durante o desenvolvimento, toda a modelagem correspondente a esses casos de uso sofrerá modificações. Por outro lado, se a descrição detalhada é deixada para a iteração à qual o caso de uso foi alocado, uma eventual mudança dos requisitos associados a esse caso de uso não afetará tão profundamente o desenvolvimento.

______________________________________________________________________________

A construção do modelo de casos de uso deve se adequar ao processo de desenvolvimento sendo utilizado. Os casos de uso mais arriscados devem ser considerados primeiramente.

______________________________________________________________________________

Casos de uso nas atividades de análise e projeto

Alguns desenvolvedores escrevem as descrições iniciais de casos de uso mencionando detalhes de interface gráfica com o usuário (considerando atores humanos). A justificativa é que a narrativa dos casos de uso segundo essa abordagem fornece uma idéia mais concreta de como se apresentará uma determinada funcionalidade do sistema. Contudo, as desvantagens dessa abordagem se sobrepõem às vantagens.

Considere a situação de uma parte da interface estar sendo continuamente modificada, por alguma razão. Nessa situação, a desvantagem de utilização de casos de uso reais (vide Seção 4.1.1.3) se torna nítida, pois o fato de a interface ser modificada possivelmente resultará na modificação da narrativa do caso de uso. Além disso, lembre-se do objetivo principal do modelo de casos de uso, a saber, modelar os requisitos do sistema. Portanto, casos de uso devem ser independentes do desenho da interface pelo fato de que os requisitos do sistema não devem estar associados a detalhes de interface.

Uma melhor abordagem é utilizar inicialmente casos de uso essenciais (vide Seção 4.1.1.3) para não acoplar os detalhes da interface da aplicação na especificação narrativa das interações de um caso de uso. Nessa especificação, a atenção do modelador deve recair sobre a essência das interações entre atores e o sistema, em vez de como cada interação é realizada fisicamente. Especificações de casos de uso feitas dessa forma ficam mais imunes a futuras mudanças na interface com o usuário, além de permitir que o analista de sistemas se concentre no que é realmente importante em uma narrativa de caso de uso: as interações entre ator(es) e sistema. Por exemplo, considere o termo "envia uma requisição" em contraposição com o termo "duplo clique sobre o botão de envio de requisições".

Em resumo, casos de uso que mencionam detalhes de interface gráfica são indesejáveis durante a análise. O mais adequado é utilizar casos de uso essenciais e, posteriormente, na etapa de projeto, transformá-los em casos de uso reais adicionando mais detalhes.

______________________________________________________________________________

Na