Leitura dos Argumentos/Visualização do Resultado  

Por uma questão de conveniência na apresentação vamos começar por apresentar os Guiões de Interacção que especificam a segunda fase referida, a leitura dos argumentos e invocação de uma operação. A estes Guiões iremos chamar Guiões de Interacção do tipo SYNTH dado que descrevem a síntese de um comando.

Consideremos a operação INSPAL e vejamos como especificar o diálogo necessário à sua correcta invocação. A primeira decisão a tomar é qual o nome a dar ao GI. Chamemos-lhe GInsPal. Para além do seu nome, é necessário também declarar quais os argumentos a ler (neste caso pal e sig) e qual a expressão a calcular depois de terminada a leitura (INSPAL(pal, sig)).

Muitos autores não se preocupam com a especificação da leitura dos argumentos, centrando-se no modo como é feita a selecção da operação a executar e considerando que a leitura é feita de um modo pré-definido (pela ordem em que estão na operação, por qualquer ordem, etc.). No entanto, neste trabalho considera-se que a possibilidade de especificar essa componente do diálogo é tão importante, ou mais até, que a segunda. Consideremos a operação referida: enquanto o argumento sig não está sujeito a qualquer restrição, pal não pode pertencer ao dicionário (cf. a informação semântica dada pela pré-condição de INSPAL). Neste caso, é desejável que pal seja lido primeiro que sig, pois deste modo é mais rapidamente detectada uma possível incorrecção semântica da frase que se está a construir.

Torna-se, então, necessário especificar a ordem pela qual os argumentos devem ser lidos. Dado que se pretendia uma notação simples e compacta, mas que permitisse a especificação de diálogo concorrente, optou-se por uma abordagem baseada numa notação de descrição dos traços possíveis de eventos, do estilo CSP [Hoa85] ou CCS [Wal87]. Consideraram-se os seguintes operadores:

• (sequência) - a.b corresponde a a seguido de b;
• (paralelismo síncrono) - ab, a e b decorrem paralelamente mas devem sincronizar no final (a expressão só termina quando terminarem os dois);
• (paralelismo assíncrono) - a expressão a|b termina quando terminar um dos dois;
• + (alternativa) - a expressão a+b representa que o utilizador terá que decidir entre prosseguir o diálogo segundo a ou segundo b;
• (repetição) - a expressão a* representa que o diálogo segue segundo a, podendo ser repetido.

Para especificar que a ordem de leitura deverá ser pal seguido de sig escrevemos:

input(pal)input(sig)

No entanto, o primeiro argumento tem a restrição semântica de não poder pertencer ao dicionário. É, então, também necessário poder associar a cada evento uma condição de contexto que verifica se ele é válido. Por outro lado, a expressão apresentada especifica apenas o diálogo na direcção utilizador-sistema. Para especificar o diálogo inverso duas possibilidades foram consideradas: utilizar uma abordagem semelhante às Gramáticas Multiparty em que na mesma notação se descrevem as duas linguagens, ou uma abordagem semelhante às normalmente utilizadas em DTE's em que as reacções da aplicação são colocadas nas transições como resposta às acções do utilizador. Dada a natureza predominantemente reactiva das interfaces por comandos (cf. controlo Dialogue Dominant), por um lado, e a complexidade que a especificação em simultâneo de duas linguagens inevitavelmente causaria, por outro, optou-se pela segunda abordagem. Vamos, então, associar também a cada evento uma acção correspondente à resposta do sistema. A notação a utilizar será:

evento: condição acção EXCEP acções de erro

Podemos então escrever a primeira versão de GInsPal.

Como se pode verificar a definição de um Guião de Interacção está dividida em duas partes. Na primeira, são feitas as declarações do tipo do Guião, dos símbolos que o identificam e dos argumentos da operação a invocar. Na segunda, caracteriza-se o comportamento do mesmo.

Tal com está, a especificação obriga, no entanto, a que o utilizador efectue sempre todo o diálogo. Se, em dado momento, ele mudar de ideias e não quiser inserir a palavra não tem possibilidades de voltar para trás! Este problema é resolvido pela introdução de eventos assíncronos, a que chamaremos Comandos, que descrevem características predefinidas do diálogo. Nesta fase, vamos considerar os seguintes Comandos:

• CANCEL - Cancelar o diálogo especificado pelo GI; quando presente, este comando está sempre disponível.
• OK - Quando este comando está presente, a expressão descrita em EXEC não é automaticamente avaliada depois de terminada EVSEQ, sendo necessário primeiro selecciona-lo; só está disponível depois de percorrida toda a expressão EVSEQ.
• RESET - Corresponde a reinicializar o diálogo especificado pelo Guião; sempre disponível.
• APPLY - Equivalente a OK mas o Guião é reinicializado, permitindo assim a repetição do diálogo.

Note-se que outros comandos podem ser considerados, dependendo das características que se pretendem especificar.

É também importante poder atribuir valores iniciais aos argumentos. Para tal é incluída uma cláusula INIT que contém instruções a serem executadas aquando da activação do GI. A especificação do diálogo passa então a ser a apresentada no Guião 2.

Agora, pal e sig são inicializadas a string vazia e são incluídos os Comandos OK e CANCEL. Foi também alterada a condição de contexto de pal, passando a testar se a palavra recebida não é a string vazia. As acções de excepção passaram então a ser uma lista guardada, executando-se as acções correspondentes à guarda que se verificar.

Consideremos, agora, o GI GRemPal para especificar o diálogo referente à operação REMPAL. Neste caso, a pré-condição não tem a ver só com os argumentos mas também com o estado do sistema. Não faz sentido invocar a remoção se o dicionário estiver vazio. Torna-se, então, necessário especificar que o comando (e consequentemente o Guião) só pode ser utilizado se não se verificar essa condição. Tal é conseguido pela cláusula CONTEXT (ver Guião 3).

É aqui introduzida a utilização de variáveis que não são argumentos da operação. Trata-se, neste caso, de uma variável declarada como sendo do Modelo da Apresentação (VAR-UI) e que é utilizada para apresentar o significado da palavra seleccionada para remoção (ver acção na cláusula TRANS). Para além dos argumentos, existem outros três tipos de variáveis num Guião:

• Variáveis da Apresentação (STATE-UI) - são variáveis que pertencem à apresentação e a que o GI acede para alteração dos seus valores;
• Variáveis Locais (STATE-CTRL) - são variáveis locais ao Guião;
• Variáveis da Aplicação (STATE-APL) - são variáveis da aplicação a que o GI acede apenas para consulta.

Na cláusula STATE-CTRL pode ser utilizada a forma de declaração:

var1 var2

Embora o GI utilize mais do que uma operação para a sua definição (EMPTYDIC em CONTEXT, EXISTPAL em TRANS e REMPAL em EXEC), é muito importante notar que apenas a operação colocada em EXEC deverá poder alterar o estado da aplicação. Doutro modo, as condições de contexto necessárias para a validade semântica da operação poderiam deixar de se verificar.

Para uma caracterização mais rigorosa dos Guiões recorremos à especificação por modelos. A informação até agora descrita pode ser modelada formalmente como o tuplo que de seguida se apresenta:

  GIDescr ::  SYNOMS:  GISym-set 
              VARS:    VarId -> VarDecl 
              CONTEXT: BoolExp 
              INIT:    Code 
              EVSEQ:   ExprComp 
              TRANS:   TransId -> TransDescr 
              EXEC:    NIL | ExecDescr;

Em VARS são agrupadas todas as variáveis, a definição da classe a que pertencem é feita em VarDecl:

  VarDecl == VarUI | VarAPL | VarAPLcopy | VarCTRL;
  VarUI :: DREF: TypeId;             
  VarAPL :: TYP:    TypeId;
  VarAPLcopy :: TYP:    TypeId
                APLVAR: OpcVarId;
  VarCTRL :: DREF: TypeId;

As transições são tuplos com a guarda, a acção a executar e a lista de acções de excepção e respectivas guardas. A expressão a executar consiste no nome da operação e respectiva lista de argumentos.

  TransDescr :: COND:   BoolExp
                ACTION: Code
                EXCEP:  ExcepDescr-list;
  ExcepDescr :: COND:   BoolExp
                ACTION: Code;
  ExecDescr :: OP:   STR
               ARGS: VarId-list;

Consideremos, agora, que pretendíamos especificar o diálogo necessário à consulta do significado de uma palavra. A utilização pura e simples de um Guião SYNTH não resolve o problema pois este não prevê o tratamento do resultado da operação. A solução está em ter dois GI's; um, que especifica a invocação da operação e prevê a devolução do seu resultado a quem o activou e outro, que o utiliza para especificar a apresentação do resultado e que poderá ser do tipo SYNTH. Supondo que o primeiro Guião referido se chama DoConsPal o segundo será o Guião ViewConsPal.

Note-se que este GI não tem cláusula EXEC já que não é utilizado para sintetizar um comando mas apenas para permitir a visualização da variável sig. A sequência de eventos possíveis é apenas a execução do GI DoConsPal cujo resultado é colocado em sig.

É introduzida, aqui, a cláusula SUBGI que indica estar a ser utilizado um outro GI para a definição da sequência de eventos deste. GI esse que é definido localmente, aparecendo assim também a componente de declaração de subGI's. Se DoConsPal fosse definido fora de ViewConsPal, deveria ser declarado não nesta cláusula mas na EXTERNAL. Ao ser subguião, DoConsPal herda as variáveis de ViewConsPal.

Aos GI's, anteriormente referidos, que permitem a invocação de uma operação da aplicação para cálculo de um valor, vamos chamar VALSYNTH. Eles são semelhantes aos SYNTH tendo apenas que declarar o tipo do resultado que produzem (que será o tipo da operação referida em EXEC) e a restrição de não poderem referir operações que provoquem alterações no estado da aplicação.

O Guião DoConsPal será:

GIDescr é então redefinido para passar a ser:

  GIDescr :: SYNOMS:  GISym-set
             TYP:     NIL | Type
             EXTERN:  GISym-set
             SUBGI:   GISym-set
             VARS:    VarId -> VarDecl
             CONTEXT: BoolExp
             INIT:    Code
             EVSEQ:   ExprComp
             TRANS:   TransId -> TransDescr
             EXEC:    OpcExecDescr;