Dentro deste tipo de modelos podemos identificar duas classes distintas: modelos que descrevem a estrutura da Interacção Humano-Computador e modelos que descrevem a estrutura do sistema que implementa a Interface. A estes últimos chamaremos Abstracções Arquitecturais. Quer num caso, quer no outro, este tipo de modelos é muito importante, pois são eles que vão servir de referência ao processo de desenho e implementação da Interface. Os modelos actuais estão, geralmente, mais orientados para o diálogo sequencial. Dada a natureza pouco estruturada dos diálogos assíncronos (o utilizador pode fazer tudo, ou quase tudo, sempre, ou quase sempre!), o desenvolvimento de Modelos Estruturais desse tipo de diálogo é mais difícil e encontra-se mais atrasado.
Relativamente à primeira classe de modelos, eles preocupam-se, como foi dito, com a descrição do processo de comunicação entre o utilizador e o sistema, descrevendo de forma genérica a estrutura e o fluxo de controlo da Interacção Humano-Computador. Uma possibilidade, inicialmente apresentada por Foley [HH89], é vermos essa interacção de um ponto de vista linguístico. Foley dividiu a interface em quatro níveis:
Hix e Hartson [HH89] propuseram um modelo linguístico chamado Dialogue Transaction Model, baseado em relações simples entre Linguagens Formais e Máquinas de Transições de Estados e que é o Modelo Estrutural do Sistema Dialogue Management System por eles proposto. Resumidamente, neste modelo estão definidos objectos linguísticos, e objectos construcionais que os processam. Os objectos linguísticos são:
Os Lexemas são processados por objectos construcionais chamados Acções, que fazem corresponder a cada acção do utilizador o correspondente Lexema; os Tokens são processados por Interacções, que fazem corresponder a uma sequência de Lexemas o correspondente Token; as Frases são processadas por Transacções, que agrupam Tokens para as formar. Cada objecto construcional é composto por objectos constituintes: de leitura, de escrita e de computação. A estrutura do diálogo é então representada, por combinação dos objectos descritos, em diagramas semelhantes a Flow Charts.
Têm também sido propostos Modelos Estruturais não linguísticos. As Dialogue Cells, propostas por Borufka [BP81], são constituídas por quatro elementos (ver fig. 3):
Uma célula de diálogo descreve diálogo sequencial. É-lhe fornecido um valor inicial e, depois de executados os quatro elementos pela ordem indicada pelas setas, devolve o resultado da avaliação do símbolo lido. Organizando várias células hierarquicamente podemos descrever uma interacção mais complexa.
O modelo de eventos tem também sido utilizado como base para modelos estruturais. Benbasat e Wand [BW84], por exemplo, propuseram um modelo baseados em Eventos de Interacção compostos por um prompt (análogo ao Prompt das Células de Diálogo), o input (corresponde ao Symbol do modelo anterior) e uma acção de processamento e controlo de fluxo para determinar o próximo evento. Estão também previstas validações de dados, help e um mecanismo de Escape que permite ao utilizador ignorar o pedido de leitura actual.
Um outro modelo não linguístico é o RED-PIES [DR85]. Segundo este modelo, um sistema interactivo é caracterizado (do ponto de vista do utilizador) pelos comandos que aceita e pelos resultados que produz em função destes. Uma sequência válida de comandos define um programa, ao conjunto de todos os programas chamamos P. é o conjunto de todos os efeitos possíveis e a relação entre a sequência de comandos já aceite pelo sistema e o efeito produzido é uma função I. Para permitir distinguir efeitos respeitantes ao produto final de efeitos que fazem parte do processo interactivo, E é mapeado nos espaços R (resultado) e D (display) por result e display respectivamente, dando origem ao esquema da fig. 4.
Figure 5: Modelo RED-PIE com efeitos observáveis
Como, por vezes, o volume de informação que o sistema produz é demasiado elevado para ser todo apresentado de uma única vez, torna-se necessário apresentar apenas parte da informação e fornecer comandos que possibilitem a navegação na totalidade da mesma. Por exemplo, ao fazermos um preview de um dado ficheiro, é-nos apresentada apenas uma página de cada vez e podemos usar comandos para mudar para a página anterior/seguinte. Estes comandos não alteram verdadeiramente o estado da aplicação, mas apenas o da interface.
Para permitir a representação de tais comandos torna-se necessário introduzir o espaço de efeitos observáveis (O). O esquema passa, agora, a ser o da fig. 5. Agora, E é mapeado no espaço O (efeitos observáveis), por observe, e este, por sua vez, é mapeado em D por display, o qual, no fundo, selecciona qual dos efeitos deve ser visualizado.
Com base neste modelo são definidas formalmente propriedades dos sistemas interactivos, tais como: reinicialização, completude ou consistência. Mostra-se ainda que é possível estabelecer uma classificação para os comandos.
Note-se que este não é propriamente um modelo da Interface mas do sistema como um todo, já que inclui também a componente computacional (função result). Ao não modelar o sistema ao nível do comando/evento do utilizador, mas do programa, o modelo aparenta estar mais vocacionado para sistemas do tipo batch.
No campo das Abstracções Arquitecturais, o Modelo de Seeheim [Gre86] é talvez o modelo mais divulgado. Na sua primeira versão (1987), este modelo divide a Interface em três componentes (ver fig. 6):
A separação dos três níveis (léxico, sintáctico e semântico) causa alguns problemas, em particular para diálogos por manipulação directa, pois, sendo necessário completar cada frase antes de ela poder ser avaliada, existe muito pouco feedback semântico por parte da aplicação para a apresentação. Consideremos, por exemplo, uma operação de inserção numa base de dados, mesmo que o código indicado seja inválido, só depois de lida toda a restante informação poderá a aplicação detectar o erro e informar o utilizador; entretanto, este esteve a trabalhar inutilmente. Torna-se, assim, evidente que é necessário aproximar a semântica do nível léxico. Tal é conseguido numa segunda versão do modelo, pela integração da informação semântica no Controlador de Diálogo.
Outro Modelo Estrutural conhecido é o Modelo MVC do Smalltalk [Dig87]. Trata-se de um modelo multi-agente que envolve três agentes (ver fig. 7). O agente Model corresponde à Aplicação, a View (ou Pane) é a representação da aplicação no écran, o Controller (ou Dispatcher) interpreta o input e faz a sua distribuição.
Em [Too91] é proposta a arquitectura UMA como referência para a Manipulação Directa. Inicialmente é defendida a separação da interacção em Interacção de Superfície, aquela que tem a ver apenas com o estado da interface, e Interacção Profunda, aquela que tem a ver com o estado da aplicação (cf. modelo RED-PIE com efeitos observáveis). A arquitectura proposta (ver fig. 8) é composta por três agentes:
"um meio M que interpreta operações como mudanças no display, uma aplicação A que recebe mensagens (input, object) e gera operações no meio e um agente utilizador U que interpreta input no contexto do display actual e ou envia mensagens de input para a aplicação, ou implementa interacção de Superfície enviando, espontaneamente, operações para o meio." [Too91]O agente utilizador em conjunto com o agente meio formam um Meio Activo (Active Medium) ou Superfície, o qual permite o desenrolar de diálogo de forma totalmente transparente em relação à aplicação.
Embora com objectivos diferentes, as duas classes de modelos apresentadas (modelos para descrição da interacção e modelos para a descrição da arquitectura) não são mutuamente exclusivas, podemos até dizer que se completam. Os modelos estruturais da interacção guiam a definição e desenvolvimento da linguagem de interacção, permitindo abstermo-nos de pormenores de implementação dessa mesma linguagem (podemos ter duas interfaces, uma por Manipulação directa e outra com uma Linguagem de Comandos, em que a linguagem é a mesma, apenas o modo disponibilizado ao utilizador para gerar as frases é diferente) e prestar atenção apenas aos aspectos estruturais da mesma. As Abstracções Arquitecturais guiam a implementação da componente interactiva que por sua vez deverá implementar um diálogo estruturalmente de acordo com o definido com os métodos anteriores.
