Como encontrar os pontos de variação em uma aplicação?

Com certeza é um trabalho de análise a ser realizado antes da codificação. Parece simples, não é? Mas não é o costume.

A lei do menor esforço é o costume e ela tem todo o sentido: menos esforço implica menos gastos que implica em menos custos.

No entanto, quando temos uma aplicação dirigida a vários e diferentes clientes esta regra muda. O custo da customização é enorme e por isto vem a necessidade do uso de técnicas que lidam com variabilidade de antemão.

Uma que acho interessante é a Feature-Oriented Domain Analisys. Ao invés de fazermos uma análise de variação ao nível do modelo de classes ou outro, esta análise se dá ainda antes quando estamos estudando quais são as funcionalidades que uma aplicação deve ter e quais são as sub-funcionalidades que estas, por sua vez, têm. E assim por diante.

Um exemplo:

Um sistema de compras deve ter:

• a entrada do pedido, que por sua vez tem :
  • um pagamento (um de vários formatos, como cartão de crédito, etc);
  • uma taxa;
  • um recibo (impresso ou online)
  • um custo de envio (opcional)
• uma aprovação (opcional);
• uma entrega, que pode ser eletrônica ou não;

Nesta descrição vocês podem perceber que temos itens obrigatórios e opcionais. As conjunções “e” e “ou” (exclusivo ou não) é que nos dão a pista de que teremos obrigatoriedade ou variações.

Com estas variações conhecidas, podemos agora decidir a melhor técnica para implementá-las na nossa aplicação. Algumas implicarão o uso de metadados, outras podem usar Injeção de Dependência. Estas técnicas terão impacto em todo modelo UML, espalhando-se por classes e diagramas de seqüências.

Fazer o caminho inverso, isto é, calcular variações a partir do modelo de classes, é muito mais difícil de seguir.

PS 1.: Valeu a inclusão, Gebara. Bom poder implicar contigo até pela web :-)

PS 2.: Uma boa referência para este assunto é o livro Generative Programming do Krysztof Czarnecki.