Exemplo de Tabela de Decisão

Continuando a ideia de tabela de decisão exposta no post anterior,  nesse será exibido um exemplo de uso da tabela de decisão. Vamos a ele:

Suponha que estamos projetando aconselhar uma pessoa, com relação a qual roupa vestir, quando sair. Uma primeira tentativa pode ser a seguinte:

	TABELA-CASACO	R1	R2	R3
C1 C2	chovendo frio	Y Y	Y N	N Y
A1	usar capa forrada	X
A2	usar capa sem forro		X
A3	usar pulover de lã			X

Note que as condições são entendidas como perguntas. No quadrante de ação, três ações possíveis e mutuamente exclusivas estão indicadas: usar capa forrada, usar capa sem forro e usar pulover de lã, simbolizadas pelas linhas A1, A2 e A3, respectivamente. No lado da entrada, três regras são formadas: pode estar chovendo e frio, apenas chovendo ou apenas frio, simbolizadas pelas colunas R1, R2 e R3 respectivamente. Note que para cada regra existe um conjunto de respostas para as perguntas que estão no quadrante de condição (explicitadas na entrada de condição); e a seleção de uma ou mais ações no quadrante de entrada de ação. Este tipo de tabela de decisão é geralmente denominado tabela de decisão de entrada limitada (TDEL) porque as respostas às perguntas são limitadas a apenas dois valores (Y e N) e também porque no quadrante de entrada de ações, as ações estão limitadas a duas possibilidades: faça a ação (X), ou não faça a ação (nada aparece).

Note na tabela anterior que não existe uma regra que tenha todos os valores iguais a N. Para essa regra, somos tentados a adicionar uma quarta ação, A4, que diz "não vista uma capa". Entretanto essa ação A4 seria uma ação redundante. Fisicamente ela realmente não é uma ação, mas sim a ausência de uma ação. Assim, nós simplesmente omitimos a colocação de um X em qualquer das linhas A1, A2 ou A3, ao invés de adicionar uma ação sem sentido. Existem duas 'patologias' comuns associadas com TD - regras que estejam faltando e ações redundantes.

Mesmo com R4 adicionada à TD anterior, essa tabela estaria ainda incompleta. Primeiro se não tivermos qualquer outra ação que não as três originais, o usuário irá ficar o resto do seu dia perto do guarda-roupas, uma vez que a TD não especifica onde o usuário deve ir, após o cumprimento de uma ação. Para completarmos as ações, podemos adicionar A4, "vá à garagem", para todas as 4 regras. Assim, direcionamos o usuário a outra atividade - escolha do carro.

A TD que está sendo construída está ainda inadequada. Ao final de cada regra nós devemos ou incluir uma conecção intermódulo ou o final do programa. Esses comandos de conclusão da TD são chamados exits e alguns projetistas de TD incluem na tabela um quadrante-de-exits e uma entrada de exits, com um outro conjunto de linhas horizontais duplas, para separar as linhas de ação das linhas de exit. Vamos continuar usando quatro quadrantes, mas vamos usar a notação de X para programas ou módulos de exits, deixando uma linha em branco entre a última ação e a primeira exit.

	TABELA-CASACO	R1	R2	R3	R4
C1 C2	chovendo frio	Y Y	Y N	N Y	N N
A1	usar capa forrada	X
A2	usar capa sem forro		X
A3	usar pulover de lã			X
A4	prossiga para a garagem	X	X	X	X
X1	retorne à tabela mestra	X	X	X	X

É importante mencionar que na TD final, não existe um único procedimento para a busca no quadrante de condições, de maneira a determinar o conjunto correto de respostas em um dado módulo de execução. Existe uma implicação que as ações em qualquer regra são executadas sequencialmente na entrada e quadrante de ação. Por exemplo, em R1, A1 é executado primeiro, A2 em segundo e X1 em terceiro. A ação A4 poderia ter sido expressa como "va' para a garagem"- entretanto, o "vá para" é uma palavra chave em TD, que é usada para indicar a saída do módulo. É importante também que se faça uma distinção entre A4 e X1. A4 é claramente uma ação realizada pelo usuário, dentro do módulo. X1, entretanto, diz ao usuário qual tabela consultar para futuras orientações.

Para uma TD ser completa, cada combinação de respostas aos testes deve ser incluída exatamente uma vez, como uma regra. Suponha, por exemplo, que a tabela anterior tivesse os seguintes padrões na entrada de condição:

R1	R2	R3	R4	R5
Y	Y	N	N	Y
Y	N	Y	N	N

Se assim fosse, R5 seria uma regra redundante se contivesse o mesmo conjunto de ações que R2, ambas caracterizando um dia chuvoso que não está frio. Para corrigir isto, ou R2 ou R5 deve ser eliminada. Entretanto, se R5 conduzir a um conjunto de ações diferente daquele de R2, as duas regras estarão em conflito e temos uma contradição. Para uma TD definida assim, o usuário não saberia como se comportar em um dia chuvoso em que não estivesse frio. Este problema é consequência, geralmente, de uma especificação mal feita do problema ou, então, de um erro do projetista da TD.

Para uma Tabela de Decisão de Entrada Limitada (TDEL), o número distinto de regras elementares é: 2^N, onde N é o número de condições. Por exemplo, a árvore de decisão binária associada a uma DTEL com 4 condições é a mostrada a seguir, com 16 (2⁴) possíveis regras. Cada nó da árvore representa um teste de condição: a ramificação à esquerda significa que o resultado do teste é Y(es), o à direita, N(o).

 

Referência:

Hurley, R.B. Decision tables in software engineering, Van Nostrand Reinhold Company, 1983