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

Tabelas de decisão

No post sobre cenários de teste, citei que uma das formas de derivá-los é utilizando tabelas de decisão. Vejamos detalhes sobre a técnica.

As tabelas de decisão são utilizadas para testar a interação entre as combinações de condições. As tabelas de decisão são um método claro para verificar a realização de testes com todas as combinações de condições pertinentes e para garantir que todas as possíveis combinações sejam tratadas pelo software em teste.

Uma tabela de decisão é composta de:

1. Condições: cada condição é descrita numa linha da Tabela de Decisão e deve ter seus possíveis valores conhecidos e descritos.

2. Ações: as ações também são descritas nas linhas da Tabela de Decisão e indicam declarações do que é realizado no processo.

3. Regras ou normas: as regras são as combinações dos valores das condições atreladas da Tabela de Decisão. Cada regra consiste em um conjunto de valores possíveis das condições, envolvendo um único valor para cada condição. As regras devem esgotar todas as possibilidades de combinações de valores resultantes das condições da Tabela de Decisão. Cada regra é representada em uma coluna da Tabela de Decisão.

O projeto de uma Tabela de Decisão implica em formar uma tabela com quatro quadrantes, sendo um para a exposição das condições, outro para a exposição das ações, outro para a descrição das regras e o último para relacionar as ações que são executadas para cada regra. A Figura abaixo mostra a disposição dos quadrantes na tabela.

A tabela pode ser construída seguindo os seguintes princípios:

1. Todas as condições devem ser identificadas e descritas no primeiro quadrante da tabela (cada condição deve ser descrita em uma linha).

2. Para condição, deve ser identificado o número de valores possíveis para ela e estes valores devem ser descritos na frente da variável da condição no primeiro quadrante.

3. Todas as ações possíveis para o processo devem ser identificadas e descritas no terceiro quadrante (cada ação deve ser descrita em uma linha). As ações devem ser descritas por sentenças que iniciam com verbo no infinitivo ou por fórmulas.

4. O número de regras deve ser calculado, sendo o resultante do número possível de combinações que podem ser feitas com os valores de cada condição. O cálculo do número de regras é feito multiplicando-se os números de valores possíveis das condições.

Por exemplo, se todas as condições forem binárias, ou seja, puderem assumir apenas dois valores

(por exemplo: verdadeiro ou falso; sim ou não; 0 ou 1; etc), o número de regras será 2N, onde o número 2 representa o fato das condições serem binárias e N representa o número de condições. Se houver uma Tabela de Decisões onde há três condições com dois valores possíveis e uma

condição com três valores possíveis, o número de regras é obtido pela multiplicação de 23

(que representa as três condições binárias) por 3 (ou 31, que representa uma condição ternária). Neste caso, o número de regras será 24.

5. Para cada regra, uma coluna deve ser desenhada no segundo quadrante, sendo numerada na extremidade superior para identificar cada regra.

6. As linhas do primeiro quadrante (condições) devem ser prolongadas até o final do segundo quadrante

7. O cruzamento entre linhas e colunas do segundo quadrante deve ser preenchido por todas as combinações de valores possíveis das condições que formam cada regra. Uma forma de evitar se perder neste preenchimento, quando há um grande número de regras, é começar pela última condição preenchendo, na sequência, cada valor possível em uma coluna e repetindo este procedimento até o final da linha. Em seguida utiliza-se o mesmo procedimento para a penúltima condição, mas ao invés de repetir uma vez cada valor, ele é repetido seqüencialmente tantas vezes quanto for o número de valores possíveis da condição já representada na tabela. Depois, repete-se o

procedimento para a antepenúltima condição, repetindo o mesmo valor da condição tantas vezes quanto for o resultado da multiplicação entre o número de valores possíveis das condições já expressas na tabela. E assim sucessivamente, até completar a linha da primeira condição.

8. As colunas do segundo quadrante devem ser prolongadas até o final do quarto quadrante.

9. Para cada regra, deve(m) ser identificada(s) a(s) ação(ões) que são executadas no caso da combinação respectiva de valores das condições ocorrer. As combinações impossíveis de acontecer ensejam a marcação de toda a coluna, no quarto quadrante, do símbolo “–“.

10. As omissões, contradições e ambiguidades devem ser identificadas e discutidas com o usuário para o aperfeiçoamento da especificação. Uma omissão ocorre quando não há ação definida para uma regra possível. Uma contradição ocorre quando duas ações contraditórias são executadas para uma mesma regra. E uma ambiguidade ocorre quando há muitas regras diferentes definindo a execução das mesmas ações.