Os sistemas tradicionais, ao preocuparem-se apenas com a validade sintáctica das frases, necessitam apenas de informação relativa às assinaturas das operações para a especificação do Controlador de Diálogo (cf. MIKE). Ao estender a noção de validade até ao nível semântico, os Guiões de Interacção integram também informação presente na especificação das mesmas operações. Tentaremos agora ver até que ponto uma especificação CAMILA proporciona a informação necessária para a geração automática dos Guiões.
Podemos separar a informação necessária para uma especificação com GI's em dois níveis. Um, a informação mais ligada ao nível sintáctico da linguagem a especificar a qual é necessária para definir o modo como os Guiões DECISION deverão agrupar as operações em grupos lógicos e, relativamente a cada operação, qual a melhor ordem de leitura dos seus argumentos. Outro, a informação semântica para definir as cláusulas de contexto de cada Guião (CONTEXT) e as condições a que cada argumento deve estar sujeito (TRANS).
A obtenção de um critério aceitável para a definição de grupos de operações aparenta ser impossível. Por um lado, critérios simplistas como, por exemplo, o agrupamento com base no tipo do resultado produzido, não são satisfatórios; critérios mais elaborados envolvem, necessariamente, uma análise das pós-condições das operações, o que não se apresenta como tarefa fácil. Por outro lado, este tipo de critério é sempre subjectivo, sendo portanto pouco dado a automatizações. A solução deverá então passar pela utilização, numa primeira fase, de um critério simples para a geração de uma primeira versão, seguindo-se a edição da especificação gerada para a obtenção da estrutura final.
Já no que diz respeito à definição da ordem de leitura dos argumentos, será mais fácil obter uma primeira versão aceitável através da análise das pré-condições. Como vimos na secção 5.2, é desejável que os argumentos com maiores restrições semânticas sejam lidos em primeiro lugar. Assim, analisando a pré-condição de uma dada operação pode definir-se uma hierarquia para os seus argumentos que depois deverão ser lidos por essa ordem. Tal estratégia não elimina, no entanto, a necessidade de posterior edição para "afinação".
No que diz respeito às cláusulas CONTEXT e TRANS, a informação para elas necessária será retirada também das pré-condições. Em CONTEXT deverão ser colocadas todas as condições que sejam decidíveis apenas com informação relativa ao estado; em TRANS, as condições que necessitem de informação relativa a cada um dos argumentos. Assim, na operação
CONSPAL(pal) = { sigma!=[] && pal in dom(sigma) => ...teremos que em CONTEXT ficaria
sigma != []e em TRANS
input(pal): pal in dom(sigma) => ...
Note-se que embora a pré-condição seja redundante
, defini-la deste modo não é despropositado se pensarmos na sua posterior utilização para geração da interface.
A presença da primeira condição possibilita a geração da cláusula CONTEXT passando o GI a não ser sequer seleccionável se não existirem palavras no dicionário.
Infelizmente, está a pedir-se a quem desenvolve a camada computacional que pense também na componente interactiva.
Uma forma de evitar esta situação será incorporar no sistema de geração automática um conjunto de regras que cubram estas situações.
Não é difícil deduzir que se pal deve pertencer ao domínio de sigma, então, à partida sigma não pode ser vazio!
Finalmente, é necessário dar atenção às condições em que estejam envolvidos mais do que um argumento. Neste caso, elas deverão ser colocadas em TRANS de tal modo que só sejam testadas quando todos os argumentos tiverem sido lidos, por exemplo associadas a um argumento que é obrigatoriamente lido depois deles, ou ao comando OK.