Estando definida a estrutura do diálogo é então necessário especificar exactamente que diálogo pretendemos. As primeiras abordagens ao problemas basearam-se em Gramáticas ou em Diagramas de Transição de Estados (DTE's).
As primeiras abordagens gramaticais à especificação de diálogo utilizaram BNF. Em [LJBS78] é apresentada a aplicação de uma variante do BNF, o TBNF, à especificação da interface de uma consola de controlo de um Sistema de Telecontrolo de uma Rede de Energia. TBNF é basicamente um enriquecimento do BNF com operadores de ocorrência opcional e de repetição, bem como com acções colocadas nas meta-expressões. Utilizando os operadores de repetição, a sequência:
f;f;f;...poderia ser especificada por
seqf ::= DSEQ 'f' ';'em vez de
seqf ::= 'f' seqf1 | NULLCom estes enriquecimentos consegue-se, por um lado, simplificar a especificação de interacções complexas e, por outro, fazer a ligação à componente computacional. Não é possível, todavia, tornar a Interface sensível ao contexto semântico da camada computacional.
seqf1 ::= ';' 'f' seqf1 | NULL
Um dos problemas com este tipo de abordagem prende-se com o facto de no diálogo Humano-Computador, os dois intervenientes não utilizarem a mesma linguagem! A linguagem em que o utilizador "fala" com o sistema e a linguagem em que este lhe responde são diferentes. Em TBNF, por exemplo, este problema é resolvido através das acções, a gramática descreve a linguagem do utilizador e a linguagem que o computador utiliza está implícita nas acções descritas. Deste modo, no entanto, apenas estamos a especificar formalmente uma das linguagens. Para resolver este problema Shneiderman propôs as Multiparty Grammars [Shn82]. Nestas, a cada não terminal da gramática é associada uma etiqueta. Não terminais que descrevam interacção produzida pelo utilizador são etiquetados com um H, não terminais relativos ao computador com um C. Deste modo é possível, numa única gramática, especificar tanto a linguagem do utilizador como do computador, bem como a relação entre elas. A ligação semântica, no entanto, continua a ser apenas ao nível da invocação das operações.
Figure 9: Exemplo de Gramáticas Multiparty
Na fig. 9 é mostrado um extracto de uma linguagem de comandos muito simplificada apresentada em [Shn82]. Na notação utilizada, os não terminais são escritos entre "<" e ">". O não terminal <H: *> reconhece qualquer string e é útil para a detecção de erros. Um não terminal não etiquetado, corresponde a um subdiálogo entre o Humano e o Computador. Os parêntesis rectos em volta de um não terminal indicam que o seu valor é usado para output, neste caso, o nome do ficheiro indicado pelo Humano, no comando OPEN, é utilizado pelo Computador na sua mensagem de confirmação.
Jacob [Jac83] apresenta exemplos de aplicação, tanto de BNF como de DTE's, à especificação da interface de um Sistema Militar de Mensagens. Também aqui são adicionadas acções ao BNF, neste caso é feita a diferenciação entre acções, que têm a ver com a aplicação, e respostas, que têm a ver com a interface. Na notação apresentada é possível ainda introduzir condições nas produções, condições essas que têm de se verificar para que a produção seja reconhecida. Deste modo, é possível introduzir validação semântica ao nível da especificação do diálogo.
A inclusão de acções na gramática levanta, no entanto, um problema. A altura em que elas serão executadas depende de tipo de algoritmo de parsing que for utilizado [Gre86]: se o parsing utilizado for top-down, então as acções são executadas quando as produções a que estão associadas forem usadas, se o parsing for bottom-up, as acções só são executadas quando as produções forem reconhecidas. Esta dualidade pode tornar confusa a utilização de diferentes notações e torna-as dependentes da implementação dos sistemas que as irão interpretar.
No fundo o problema está na não existência do conceito explícito de estado nas gramáticas. Uma interface é muitas vezes vista como uma máquina de estados, com as interacções a provocarem mudanças nesse estado. É natural, então, que se procure utilizar uma notação em que o conceito esteja presente. Uma escolha óbvia serão os Diagramas de Transição de Estado, neste caso não se especifica directamente a linguagem (melhor, as linguagens) de interacção, mas quais os estados pelos quais essa interacção passa e as transições entre eles.
No caso geral, a cada transição do DTE está associada uma acção do utilizador. É o conjunto das transições, então, bem como a sequência em que elas podem ocorrer, que define a linguagem do utilizador. Também neste caso são adicionadas acções ao diagrama para deste modo representar as respostas do sistema e introduzir semântica na especificação. As acções podem ser associadas ao estados ou às transições (ou a ambos), mas em qualquer dos casos o instante em que elas serão executadas é bem definido: quando o estado é atingido ou quando a transição é efectuada, respectivamente.
Um dos problemas com os DTE's é o tamanho e complexidade que facilmente atingem quando se tenta especificar um diálogo minimamente realista. Uma das soluções encontradas foi a sua divisão em subdiagramas, os quais possibilitam dividir a especificação do diálogo em unidades lógicas mais pequenas. A associação de um subdiagrama a uma transição indica que ela se deverá efectuar depois de o subdiagrama ser percorrido. Aos diagramas que se podem invocar recursivamente é dado o nome de DTE's recursivos. Estes possuem naturalmente maior poder expressivo que os DTE's normais. Mais uma extensão ainda foi a inclusão no modelo de um estado e de funções que o manipulam, funções essas que estão associadas às transições e que retornam um valor booleano; se o valor retornado for "verdade" então a transição pode dar-se, se for "falso" a transição não se efectua. A este tipo de diagrama chamou-se Diagrama de Transições de Estado Aumentado. Com este tipo de diagrama é agora possível especificar diálogos sensíveis ao contexto, permitindo ou inibindo determinadas transições em função da sua validade semântica. Os DTE's utilizados em [Jac83] pertencem a esta classe de diagramas.
Figure 10: Diagramas de Transições de Estado USE
Um outro exemplo de utilização de Diagramas de Transição de Estados Aumentados são os diagramas USE [Was85].
Na fig. 10 são apresentados dois exemplos, retirados do artigo referido, de diagramas USE.
Nestes diagramas os estados são utilizados para output, estando definida uma linguagem para descrição do mesmo, as transições são disparadas pelo input do utilizador ou pelo reconhecimento de subdiagramas.
As transições podem ser decoradas com acções ou com subdiagramas.
No caso de acções, elas são executadas quando se dá a transição; se estiver associado um subdiagrama, o diálogo passa a ser controlado por este.
Em qualquer dos casos, o valor retornado, quer pelas acções quer pelos subdiagramas
, é utilizado para decidir o destino final da transição.
Transições que não estejam etiquetadas são utilizadas, como default, caso nenhuma outra seja válida, transições etiquetadas com "+" são automaticamente efectuadas e a etiqueta "!", associada a um caracter, significa que a transição deve ser efectuada mal seja premida a tecla correspondente a esse caracter (por defeito um input é terminado com return).
Está, no entanto, a misturam-se um pouco a definição sintática da linguagem com pormenores de nível léxico!
Na fig. 10(a) é especificado um menu, premindo as teclas "1" a "3" o diálogo passa a ser controlado pelos diagramas deposit a balance, a opção "4" ou "?" provoca a transição para o estado help para o qual estará definida a apresentação de uma mensagem, "5" ou "q" terminam a interacção. Em (b) é apresentado um exemplo em que a transição depende do valor retornado pela operação, é lido um número de conta, a operação associada a 4 é executada e caso o seu resultado seja um é feita a transição para found, caso seja dois é feita a transição para notfound.
Nestes exemplos são apenas mostrados os diagramas; a especificação completa do diálogo incluiria ainda a definição do output de cada estado e as operações.
O principal problema com as gramáticas e os DTE's é a especificação de diálogos assíncronos, em especial se forem concorrentes. De modo semelhante ao que foi dito para aos Modelos Cognitivos (cf. 3.1), a utilização de gramáticas livres de contexto pressupõe um diálogo sequencial. Os DTE's, por seu lado, permitem descrever as sucessivas mudanças de estado em função de um dado traço de diálogo, mas apresentam dificuldades quando passamos a ter vários traços de diálogo em simultâneo.
Têm sido feitas tentativas para adaptar estes formalismos à descrição deste tipo de diálogos. Em [MVM90] é apresentada uma adaptação de DTE's para a especificação de diálogo concorrente. Aos estados, aqui chamados UIP's (User Interaction Point), são associados propriedades que irão influenciar o seu comportamento:
Em consequência destas propriedades é possível termos mais do que um UIP activo em cada instante. Deste modo, os UIP's deixam de ser estados de um DTE, passando a ser algo mais parecido com condições de uma Petri Net.
Outras abordagens têm passado pela procura de formalismos mais poderosos. Em [Gre86] é demonstrado formalmente que o Modelo de Eventos é mais poderoso que as Gramáticas Livres de Contexto ou os DTE's. Um exemplo da utilização do Modelo de Eventos é o do sistema IUICE [Stu90]. Neste, a interface é descrita por um conjunto de métodos (entidades responsáveis pelo processamento de eventos) ligados por event streams, que implementam a comunicação de eventos entre os métodos. Estão definidos três tipos de métodos:
Outras abordagens ao problema utilizam o Paradigma da Programação por Objectos, identificando objectos gráficos no écran e descrevendo de que modo eles estão interligados e comunicam, tanto entre si como com a aplicação e com o utilizador (cf. [Hay90], [Jac86]).
Em [Abo92] é proposta uma metodologia baseada em agentes, sendo o seu comportamento especificado utilizando uma notação baseada em CSP. A definição de um agente é dividida em quatro partes:
A utilização de processos comunicantes para a especificação de diálogo é proposta em [HS90].
Em [MAH90] é proposta a primeira versão de um novo formalismo, Guiões de Interacção, para a descrição do diálogo. Cada GI pode ser visto como um objecto, sendo utilizados DTE's para a descrição do diálogo gerado por cada guião.