Apresento neste artigo um novo modelo para a especificação de casos de uso. Foram dois os empurrões que me trouxeram para esta nova proposta. Vários participantes de meus treinamentos pediram por um modelo que não tivesse apenas fins didáticos. Algo que eles pudessem adotar em seu dia a dia. Além disso, ideias recentes apresentadas por James Coplien, Gertrud Bjørnvig e Ivar Jacobson me fizeram rever alguns pré-conceitos em relação à ferramenta. Mantive boa parte do desenho original – a preocupação com a estruturação dos requisitos – mas incorporei vários novos elementos. Como ainda não tive muitas oportunidades para testar o novo modelo, contarei com seu retorno.
∞
Antes de mais nada, os créditos. A principal provocação para o novo modelo veio de “Lean Architecture” (Wiley, 2010), de James Coplien e Gertrud Bjørnvig. O casal, por sua vez, cita os trabalhos de Rebecca Wirfs-Brock (“Designing Scenarios” – Smalltalk Report, nov-dez/1993) e Constantine e Lockwood (“Software for Use: A Practical Guide to Models and Methods of Usage-centered Design” – Addison-Wesley, 1999). Me convenceram da utilidade e necessidade do uso de duas colunas nos fluxos. E provam, em seu livro, como as especificações podem ser ágeis e enxutas. Na semana passada o “pai” dos casos de uso, Ivar Jacobson, publicou um artigo sobre Casos de Uso 2.0. Dele ganhei a confirmação de que casos de uso: i) são tão ágeis quanto você; ii) escalam o quanto você precisar; iii) não tratam apenas de requisitos funcionais; iv) não se limitam a projetos de sistemas; e v) nem aos requisitos – valem em todo o ciclo de vida de um projeto. Usei todas as novas sugestões como complementos ao modelo que utilizava anteriormente e que era fortemente baseado no trabalho de Alistair Cockburn, “Escrevendo Casos de Uso Eficazes” (Bookman, 2008).
Aos iniciados, letrados e usuários super-avançados de casos de uso e afins, um aviso: o modelo aqui sugerido segue tendo como principal motivação o uso didático. Por isso, talvez o modelo não tenha nenhuma utilidade para vocês. Pensei nos iniciantes e em todos que precisam rever seus (pré)conceitos sobre a ferramenta. Me preocupei, principalmente, com todos que precisam de um tipo de guia (e de limites) enquanto aperfeiçoam sua técnica. Vamos ao que interessa.
O modelo anterior era muito pequeno (formato A5), o que impedia seu uso em casos ‘de verdade’. O novo modelo foi diagramado em formato A4 paisagem. Frente (acima) e verso (logo mais) podem ser impressos em uma única folha ou em separado, como explicarei mais tarde. A frente condensa todas as informações fundamentais sobre um caso de uso. Vou apresentá-la por partes.
Cabeçalho
Segue a preocupação com a identificação da fonte e respectivo ponto de vista (estratégico, tático, operacional ou técnico). Incorporei um sofisticado “controle de versões”. Ele me ajuda a reforçar um grito: “joga o caso no lixo! (tão logo dele tenha brotado algum derivado)”.
Finalmente me lembrei dos ícones que determinam o nível de detalhamento do caso. 
Não, prezadas fábricas de software (sic), não contemplei o tal nível “pré-sal” que vocês insistem em pedir. Mas a nova versão da ostra, quero crer, não gerará mais dúvidas nem piadinhas.
O campo “processo / atividade” serve para referência cruzada com algum diagrama do negócio, de preferência com o PUCS (Process-Use Case Support) ou um diagrama de atividades.
“Valor”, que talvez ainda seja rebatizado “Benefício”, indica como o cliente ou usuário valoriza o caso em questão. “Custo” é a estimativa de esforço do time de desenvolvimento (expressa em unidades relativas, pontos de casos de uso ou qualquer outra unidade de medida). A possível avaliação benefício/custo pode determinar a “Ordem”, a posição do caso no cronograma (ou, de preferência, no backlog do produto). Daí o espaço “Iteração”, onde deve ser registrado a iteração projetada para o trabalho neste caso. Quem não “itera” pode ignorá-lo, sem problemas.
Contexto, Pré e Pós-Condições
Não se trata de um filler, vulgo “encheção de linguiça”. O Contexto nos ajuda a posicionar o caso de uso no projeto, indicando suas relações com outros elementos. É aberto para possibilitar até mesmo o desenho de um pequeno diagrama de casos de uso. Mesmo que fujas dos temidos (e mal compreendidos) extends e includes da vida, você deve achar alguma utilidade para o espaço. Pré e pós-condições não pedem por maiores explicações. Ah, só preciso dizer que elas são um tipo muito especial de Regras de Negócio. Regra do negócio, e não aquele papo de “o usuário tem que estar logado no sistema (sic)”. Pronto, disse.
Fluxo Principal
A conversa devidamente explicitada. Eu evitava o modelo com duas colunas por morrer de medo daqueles que acham que, para cada intenção do ator o sistema deve, obrigatoriamente, dar uma resposta. Desperdício imperdoável de tempo que culminava em obviedades assim: Ator: Indentificar Cliente / Sistema: Exibir nome do cliente. Terrível! Mas Coplien e Bjørnvig me convenceram de que, apesar dos mestres do óbvio, este modelo é realmente mais eficaz.
Ainda assim, o espaço disponível para descrição dos passos do ‘caminho feliz’ segue exíguo para todos aqueles que não acreditam nos limites sugeridos por Coplien (máximo de 7 passos) ou Cockburn (máximo de 9 passos). Só evitei numerá-lo, como no modelo antigo, para deixar o formulário um pouco menos poluído.
Fluxos Alternativos / Instruções para Testes
Está aqui o trecho que mais me custou mais tempo. O número de fluxos alternativos pode ser muito grande, dependendo do caso de uso. Mas a questão não era só essa. Queria contemplar também um espaço para um tipo de Caso de Testes. Acho que consegui matar os dois coelhos. O trecho acima aparece na parte da frente do modelo e em metade do verso. Por isso eu disse que o verso pode ser impresso de forma independente. Ele também contempla outras regras de negócios e outros tipos de requisitos. Quando o espaço não for suficiente, basta imprimir ou utilizar mais páginas apenas com o verso do modelo. Aos campos.
Indicamos o número do passo afetado e o tipo de registro (fluxo Alternativo o Teste). Na sequência, o motivo para o desvio ou então alguma instrução para a execução de testes. Há ainda uma coluna para comentários e outra para a indicação da iteração que deve contemplar a realização deste fluxo alternativo. Esta ideia combina bem com os slices propostos por Ivar Jacobson no referido artigo. Combina ainda mais com as sugestões apresentadas em “Lean Architecture” (em resumo: em um projeto tocado por um método iterativo, os incrementos são fluxos dos casos de uso. Ex: em uma iteração você entrega o fluxo principal, na seguinte dois fluxos alternativos e assim por diante).
Se a ferramenta é escalável, como confirma Jacobson, o modelinho também deve ser. Daí a diagramação do verso, exibida abaixo.
∞
Utilizarei este modelo nas próximas edições de meus treinamentos. Acho que só depois de duas ou três experiências terei noção das alterações necessárias. Ou seja, novidades sobre o tema só no final de novembro. Enquanto isso, se você quiser brincar um pouco com o modelo, faça o download aqui: bit.ly/UCfinito. Claro que estou contando com seu retorno, experiências, críticas e sugestões. Desde já agradeço. Abraços!
Obs.:
- Nunca antes na história deste blog o nome de uma imagem combinou tanto com o conteúdo. “Extracting Knowledge” é de autoria do HikingArtist e foi legalmente surrupiada no Flickr.
- Depois de meus canhotos rabiscos, todo o trampo artístico e de diagramação foi do mano Gus Vasconcellos, da Opção Artes Gráficas. Não sei o que seriam de meus rabiscos sem a colaboração dele.
