Tabelas de decisão
Do conhecimento à execução.

• Cobertura: todas as combinações admissíveis possuem regra aplicável? Uma lacuna deve ser tratada explicitamente ou aceita pelo contrato da decisão.
• Sobreposição: duas ou mais regras se aplicam à mesma entrada. Pode ser válida, dependendo da política.
• Conflito de saídas: regras aplicáveis retornam resultados diferentes. É incompatível com a política Any; First resolve pela ordem e Collect reúne resultados.
• Redundância: repetição dispensável em relação à semântica adotada. A mesma saída em regras diferentes não basta para caracterizar erro; em Collect, duplicar regras pode alterar o resultado.
• Ambiguidade: interpretação ou resolução não especificada. Não significa simplesmente “regras diferentes com a mesma ação”.

Para n condições booleanas independentes existem 2ⁿ combinações. Uma tabela reduzida pode cobri-las com menos regras. Restrições de domínio podem tornar parte das combinações impossível.

Sim/Não representam valores booleanos. — aceita ambos; não significa “valor desconhecido”. Uma entrada ausente exige tratamento próprio. Na semântica histórica fornecida pelo autor, uma expressão aritmética diferente de zero corresponde a 1, e igual a zero corresponde a 0. Essa é uma convenção daquela linguagem; o laboratório atual recebe apenas entradas booleanas e não avalia expressões aritméticas.

Uma transição indica qual tabela ou estado será tratado em seguida, quando o modelo inclui controle de rotinas. O laboratório abaixo trata uma decisão isolada, sem implementar transições.

Várias ações não implicam não determinismo: uma regra pode determinar um conjunto fixo de ações, todas obrigatórias. O não determinismo envolve escolhas alternativas admitidas pelo modelo, sem uma única escolha prescrita naquele ponto.

Paralelismo permite execução concorrente segundo a semântica da linguagem. Retornar várias saídas com Collect não significa executá-las em paralelo.

Matriz booleana é uma possível representação de avaliações e associações. Identificadores, descrições de ações e referências de transição também compõem o modelo completo. Não se define toda tabela de decisão como uma matriz exclusivamente booleana.

As afirmações sobre linguagens regulares, livres de contexto e compiladores pertencem à proposta de formalização histórica. A classe formal depende da gramática e da camada analisada. Separar especificações, operações e controle é uma proposta arquitetural; não exige três compiladores independentes em toda implementação.

O material fornecido descreve preparação de regras, conversão de símbolos, associação a ações e verificação. A revisão distingue o registro histórico das correções propostas.

Procedimento revisado: validar as entradas e a estrutura das regras; normalizar símbolos com significado confirmado; avaliar regras aplicáveis; verificar cobertura e sobreposições; resolver resultados pela política; apresentar todos os diagnósticos e o rastro da decisão.

Esta descrição orienta a revisão conceitual. O laboratório implementa o domínio booleano fixo e suas políticas; não implementa um analisador da linguagem histórica nem um executor de ações externas.

Esta gramática foi elaborada para explicar o modelo atual. Não é transcrição da imagem nem gramática das dissertações. Em EBNF, chaves indicam repetição, a barra vertical indica alternativas e aspas delimitam símbolos literais.

tabela  = regra, { regra } ;
regra   = valor, valor, "=>", saida, ";" ;
valor   = "1" | "0" | "-" ;
saida   = identificador ;

O primeiro valor corresponde a C1 e o segundo a C2. identificador designa uma saída definida no domínio; sua formação lexical fica fora desta gramática.

1 1 => presencial ;
1 0 => remoto ;
0 - => solicitar_identificacao ;

Restrições semânticas: cada regra testa exatamente duas entradas; cada saída deve estar definida; a política resolve correspondências múltiplas. O exemplo reduzido cobre as quatro combinações.

O editor opera por campos e importa/exporta JSON. Ele não analisa esse formato textual nem valida a gramática histórica. Uma tabela vazia pode ser explorada no editor para observar ausência total de cobertura, mas não pertence à gramática didática acima.

• Função do asterisco e dos demais separadores no diagrama; o exemplo sugere uma possível separação entre condições e ação.
• Abrangência precisa de “elemento” no diagrama, agora que os anexos distinguem ações e transições; significado de “ação é 1” e “ação é 0” no procedimento original; comportamento da transição vazia e alcance de sua exceção de compatibilidade.
• Regras de formação, repetição e encerramento de cada construção.
• Referência bibliográfica e versão da notação.

Os significados de 1, 0 e condição irrelevante, assim como identificação, ações e transições, já foram fornecidos pelo autor. As pendências acima não impedem o uso do laboratório atual: sua notação e seu comportamento estão definidos separadamente.

A decisão determina uma saída a partir de entradas. O processo organiza atividades e eventos. O software executor realiza ações e trata falhas. Uma tabela isolada não descreve necessariamente o processo inteiro; as linguagens de controle estudadas por Flores ampliam esse escopo com transições.

Referente: o que será decidido. Objetivo e persona: quem usará o resultado e para quê. Entradas: nomes, tipos, origem e ausências. Domínio: combinações possíveis e restrições. Regras: condições, saída e política. Evidências: fontes, responsável, versão e testes. Uso: como interpretar e executar o resultado.

No JSON deste laboratório ficam o identificador do formato, a versão do modelo, as entradas fixas, a política e as regras. O arquivo é didático e não é um documento DMN padronizado. Alterações permanecem na sessão até exportação; não há salvamento automático.