Se seguimos um processo iterativo, como é recomendado pelo Rational Unified Process (RUP), no final da fase de arranque do projecto a equipa e os clientes têm que estar de acordo quanto à definição da abrangência e quanto às estimativas de custo e de calendarização. Depois será necessário tomar a decisão de avançar com o projecto, ou de o cancelar. Exceptuando alguns casos de uso críticos identificados no final da fase de arranque do projecto (fase de início), a única informação disponível nessa altura sobre os actores e os casos de uso identificados tem a ver com os respectivos nomes.
Conjuntamente com características específicas e outros requisitos de sistema, os nomes serão suficientes para que todos os stakeholders tenham uma compreensão suficientemente clara da funcionalidade do sistema, a fim de decidirem pela continuidade ou cancelamento do projecto. No entanto, tudo isto será muito mais fácil se seguirmos algumas orientações claras e consistentes quando atribuímos nomes aos casos de uso. Frequentemente, nas iterações iniciais da fase de elaboração são descritos poucos casos de uso com um detalhe superior a uma breve descrição. Esses poucos costumam ser aqueles que são considerados significativos em termos arquitecturais.
Regra básica: olhe para o diagrama
Uma regra básica que devemos seguir aquando da atribuição de nomes aos casos de uso é que alguém (pelo menos alguém familiarizado com o problema) possa ser capaz de olhar para um diagrama de casos de usos - anotando o actor e os nomes dos casos de uso, bem como as suas associações - e ficar com uma boa ideia do valor ou objectivo a ser alcançado com cada caso de uso. Para se conseguir isso, é muito importante escolher os nomes de todos os actores e casos de uso com este objectivo em mente.
Regra de ouro nos nomes dos casos de uso: indique o valor ou objectivo
Nas orientações para os casos de uso, o RUP refere que "cada caso de uso deve ter um nome que indique qual o valor (ou objectivo) alcançado pela interacção do actor com o sistema (se tudo correr como esperado)". Apresentamos a seguir algumas boas questões para ajudarem a garantir a conformidade com esta regra de ouro.
Orientação: utilize a forma activa
A indicação do valor ou objectivo pretendido será melhor conseguida se tivermos nomes de caso de uso que comecem com um verbo (forma activa). Isto também ajuda a manter a consistência ao longo de todos os nomes de casos de uso num projecto - que podem ser escritos por diferentes membros da equipa - além de ajudar a evitar ambiguidades.
Imagine uma lista de coisas a fazer
Quando se atribuem nomes aos casos de uso, uma boa forma de proceder será imaginarmos os itens que poderemos escrever numa lista de coisas a fazer. Por exemplo, se quisermos deslocar-nos a um sistema ATM e quisermos fazer uma lista de coisas a fazer para aquilo que esperamos alcançar nessa visita ao sistema ATM, poderemos escrever tais itens como "Levantar Dinheiro", "Transferir Fundos", "Manter ATM", "Depositar Fundos", em vez de "Levantamento de Dinheiro", "Transferência de Fundos", "Manutenção de ATM", "Depósito de Fundos", e por aí adiante.
No entanto, convém ter em conta que esta orientação para a atribuição de nomes não é obrigatória. Podem-se utilizar as palavras que melhor promovam a comunicação com o cliente.
Especifique convenções de projecto nas orientações para a modelação dos casos de uso
Para evitar confusões e ambiguidades será melhor especificar orientações de projecto, de modo a que toda a equipa atribua nomes de forma consistente a todos os casos de uso do projecto. Depois de se chegar a acordo quanto a esta decisão, o artefacto Orientações de Modelação de Casos de Uso do projecto é um bom local para reafirmar a regra de ouro referida atrás (para indicar o valor ou objectivo pretendido), conjuntamente com outras preferências que gostaríamos de ver aplicadas - por exemplo, a orientação de se iniciar o nome de cada caso de uso com um verbo.
Isto é especialmente importante quando se está a contactar com alguém para efectuar o trabalho e não queremos envolver-nos na atribuição inicial de nomes aos casos de uso. Poderá assim poupar-se muita argumentação sobre nomes individuais de casos de uso e ajudar a garantir que os casos de uso são definidos a um nível adequado de abstracção. No entanto, será necessário ter cuidado para não cair na armadilha da "decomposição funcional" dos casos de uso.
Baseado num texto de Leslee Probasco com o título "What Makes a Good Use-Case Name?".