Um Método Lúdico: diagrama Mickey Mouse

Na maior parte dos casos de uso, o fundamental pode ser reduzido a três questões:

1. De onde vêm os dados?
2. O que se deve fazer com eles?
3. Onde devem ser gravados?

A maior parte dos analistas sabe disso de forma intuitiva, mas como nunca lhes foi apresentado de forma clara, o tratam com descaso.

Já vi casos de uso com enunciados como este:

Ao preço, somam-se a margem de lucro e os impostos.

Parece simples, mas onde é que eu encontro o preço? E a margem e os impostos? Como é feito o cálculo? E o que eu faço com o resultado?

Neste exemplo em particular, para dificultar, a base de dados tinha tabelas e colunas com nomes do tipo CSX0023. O resultado é que o programador acaba tendo que fazer a análise novamente.

Então, para resolver esta questão, Um Método Lúdico apresenta o diagrama Mickey Mouse:
Também é chamado de diagrama do alumbramento.

A idéia é simples:

1. No círculo da esquerda, descreve-se a origem dos dados (o nome das tabelas, dos arquivos, etc.);
2. No círculo do meio, descreve-se o que fazer com os dados;
3. No da direita, indica-se onde gravar os resultados.

O analista deve entregar o diagrama com um sorriso nos lábios e um pirulito na mão esquerda.

Um Método Lúdico: casos de uso

O UML é restrito no sentido de que ele pressupõe que o analista e o cliente sejam completamente lúcidos e racionais. Todos nós sabemos que isso nunca acontece.

O cliente não sabe o que é importante para seu negócio, principalmente porque, na maioria das vezes, o cliente do analista não é o dono do negócio. Ele pode até ser um bom funcionário, leal ao seu chefe e tudo mais, mas ele nunca pensa como o dono do negócio. Logo, os sistemas saem com algumas deficiências.

Um tipo de caso de uso muito comum é o descaso de uso. O descaso de uso é um elemento inútil do sistema, mas que, mesmo assim, é o mais popular entre os usuários. Por exemplo, numa intranet, invariavelmente, as páginas mais usadas são: a lista de aniversariantes do mês e o cardápio da cafeteria.

O descaso de uso é como o pato de borracha na banheira. Água, sabonetes e toalhas são essenciais para o banho, mas o pato de borracha é o que o torna realmente divertido (ouvi dizer, pelo menos). Então, o descaso de uso é representado dessa maneira:
O caso de uso pato de borracha (descaso de uso para os mais formais) é proximamente relacionado ao caso de desuso. Ambos são inúteis para o negócio, mas o caso de desuso ainda é pior, porque não serve para nada mesmo. Em geral, o caso de desuso toma a forma de um relatório obscuro, difícil de interpretar e que ninguém lembra quem pediu.

Por exemplo, um gerente num surto psicótico pode solicitar um relatório de vendas realizadas por funcionários com filhos de menos de 10 anos. Ou de notas emitidas para cidades do noroeste catarinense, exceto por aquelas de colonização alemã. O analista logo vê a inutilidade da criatura, mas não consegue convencer o cliente a tentar algo mais abrangente (e útil), como um relatório por região ou uma ferramenta de Data Warehouse, para que o gerente possa brincar sem perturbar sua equipe.

O caso de desuso é representado por uma teia de aranha:
Finalmente, temos o frankencaso. É o caso de uso com múltiplas personalidades. Ele provavelmente reflete a personalidade do cliente que o solicitou. Ou sua taxa de glicose. Um relatório de vendas que, quando disparado na segunda-feira antes das 10h, dispara um workflow que atualiza a tabela de comissões é um ótimo exemplo de frankencaso. Os usuários acabarão aprendendo a disparar o relatório quando quiserem atualizar suas comissões, numa reação pavloviana, mas nunca serão capazes de explicar aos novatos por que a coisa funciona dessa maneira.

O frankencaso é representado assim:
No exemplo que segue, vê-se um ator paranóico usando a página de aniversários para descobrir se não esqueceu de dar um tapinha nas costas do chefe.


Um Método Lúdico leva a ánalise de sistemas a um novo patamar de realismo, aproximando o analista ao cliente e eliminando formalismos bestas.

Um Método Lúdico

O UML é limitado demais para representar o dia-a-dia do analista de sistemas. Então, resolvi criar meu próprio método, começando pela análise psicológica dos atores. A palavra "ator" foi sabiamente escolhida, porque alguns usuários realmente merecem um Kikito.


Certos usuários, os nervosos, têm medo de apertar qualquer tecla e não hesitam em ligar para o suporte e perguntar: o micro está perguntando se eu quero realmente apagar o arquivo, eu aperto "sim" ou "cancelar"?

Já notaram, no shopping, como o operador que valida o cartão do estacionamento aperta o botão até a pobre máquina cuspir o recibo? Aposto que o manual diz: aperte o botão 20 vezes para gerar o recibo.

Finalmente, tem atores que não dão a mínima para o sistema. Nem na fase de especificação e menos ainda para usá-lo. Afinal, os analistas de sistemas já nascem sabendo todas as regras de negócio. E se precisarem de um relatório, basta ligar para o suporte e pedir, oras.

Um Método Lúdico© faz piada de tudo o que o UML não resolve, embora também não resolva coisa alguma.