Jogo das Equações

O "Jogo das Equações" (JEQ) serve como contexto para a modelagem de software por "responsabilidades de objetos". Ele faz parte de uma série de ensaios realizados ao longo da disciplina de programação do curso de Ciência da Computação. A ideia é que o jogador informe os coeficientes "a" e "b" de uma equação de 2o grau e solicite o cálculo das suas raízes. Se elas forem reais e maiores do que zero, o jogador ganha a partida; perdendo, em caso contrário. O coeficiente "c" será aleatoriamente gerado no intervalo de 1 a 1000, inclusive. Quais são os requisitos de uma aplicação para esse jogo? Qual a sua arquitetura? Quais as classes dos objetos da aplicação?

Requisitos do JEQ

A Técnica ICA (Interface Com o Ambiente) ajuda na etapa de identificação de requisitos de negócio. Para o JEQ, 12 requisitos de negócio podem ser identificados, sendo o RF1 ("Calcular o resultado da jogada a partir dos coeficientes 'a' e 'b'") aquele que caracteriza a essência do JEQ.

Requisitos e Alocação de Responsabilidades

Para cada requisito (promessa feita pela aplicação para o usuário), deverá existir um objeto (simples ou complexo) com a responsabilidade de ajudar a aplicação no seu cumprimento. Assim, no caso do RF1, deverá existir um objeto responsável por ajudar a aplicação a calcular o resultado da jogada. Qual seria a classe de tal objeto? O "Princípio do Napoleão" é uma técnica útil nesse ponto. A pergunta: "Qual objeto deve ser responsável por calcular o resultado da jogada do JEQ?" Resposta: um objeto da classe JEQ!

Mas, para que seja possível realizar o cálculo, é preciso que tal objeto conheça os valores dos coeficientes "a", "b" e "c". Os dois primeiros são informados pelo jogador. O valor de "c", entretanto, deve ser gerado aleatoriamente. Ou seja, deverá existir uma classe de objetos com a responsabilidade de gerar o valor do coeficiente "c". Qual objeto deve ser responsável por gerar o coeficiente de uma equação para o JEQ?

Requisitos como Promessas da Aplicação

Ajuda pensar em requisitos no sentido de "promessas que uma aplicação" faz para o usuário? Tenho experimentado isso nas aulas (grad e pós) e o efeito tem sido muito positivo. Ao forçar a leitura como "a aplicação promete fazer isso para o usuário", o modelador tende a identificar um requisito funcional mais claramente. Da mesma forma, ao forçar a leitura "a aplicação promete fazer isso obedecendo aquilo para o usuário", um novo requisito regulatório (não-funcional) é identificado.

Além disso, a palavra "promessa" também sugere a possiblidade de não ser cumprida: o modelador conseguirá chegar em uma arquitetura que cumpra todas as promessas feitas pela aplicação para o usuário? Eventualmente, algumas promessas poderão ser cumpridas (alocando-se responsabilidades aos objetos) e outras não, as quais sofrerão um processo de negociação conjunta com o usuário.

Em relação às promessas regulatórias, uma classificação adicional pode auxiliar na identificação de requisitos:

• promessas de negócio (regras e leis de negócio)
• promessas de produto (URPS)
• promessas de metodologia (processo de desenvolvimento, ferramentas, técnicas, práticas e linguagens)... P(Ftp)L