Projeto da interface abstrata

A modelagem de uma interface abstrata é construída definindo objetos perceptíveis em termos de interface, como por exemplo, uma foto, uma caixa de seleção de valores, um mapa da cidade, entre outros. Estas classes são definidas como agregações de elementos primitivos, como caixas de textos, botões, imagens, e também de maneira recursiva, utilizando outras classes de interface.

Os objetos de interface são mapeados a partir dos objetos navegacionais do projeto de navegação, provendo assim uma aparência perceptível do sistema. O comportamento da interface é declarado especificando como eventos externos ou gerados pelo usuário são tratados, e em como se dá a comunicação entre a interface e os objetos navegacionais.

Diferentemente da modelagem conceitual e do modelo navegacional, que determinam os elementos do domínio da aplicação e a maneira como o usuário completará suas tarefas, a Interface Abstrata existe para determinar os objetos navegacionais e a funcionalidade da aplicação que devem se perceptíveis pelo usuário na interface da aplicação. Mesmo quando a interface é percebida como uma parte externa do domínio da aplicação, em um nível mais abstrato, pode ser considerada como mais uma das informações trocadas entre o usuário e

30

o sistema, portanto a navegação entre os elementos interface se torna mais uma das funcionalidades da aplicação.

Como as tarefas suportadas pela aplicação gerenciam essa troca de informação, é de se esperar que a troca seja menos dependente do ambiente em que está se desenvolvendo esta interface. Isso faz com que possam ser separados os processos da interface (informações que devem ser trocadas) e implementação da mesma (layout, cores), estas últimas dependentes das particulares configurações de hardware e software que estarão rodando estas aplicações. Esta separação nos permite criar modelagens protegidas das evoluções tecnológicas das diversas plataformas e também da necessidade de dar suporte aos vários ambientes de hardware e software utilizados pelos usuários.

Para o desenvolvimento da interface de um sistema baseado em OOHDM, pode-se se fazer o uso de técnicas que descrevem as interações entre o usuário e o sistema levando em conta que tipo de elemento de interação será utilizado na implementação. Uma destas técnicas, que será expandida no Capitulo 4 do presente trabalho, chamada de Ontologias de Widgets de Interface² (MOURA, 2004)descreve classes abstratas de interface que são mapeadas para os elementos de interação usuário-sistema.

O nível mais baixo de abstração é chamado de Interface Abstrata, que foca no tipo de funcionalidade interativa que cada elemento de interface proverá. Ela é descrita por um conjunto de elementos que representam este tipo de interação, considerando as necessidades de trocas de informação entre o usuário e os elementos de navegação.

Posteriormente, estes elementos abstratos, chamados de widgets e definidos pela Ontologia de Widgets Abstratos, são mapeados para uma estrutura de elementos concretos

2 Apesar de a ontologia de interface abstrata ter sido criada para dar suporte a conceitos da Web Semântica e à geração automática de interfaces, este trabalho utiliza apenas parte do conceito geral da ontologia, no que diz respeito criação de uma interface formalizada, em um sistema web.

31

levando em conta os aspectos específicos do ambiente em que será implementada tal interface, definidos pela Ontologia de Widgets Concretos.

2.3.4.1 Ontologia de Widgets Abstratos

Ontologia é a parte da filosofia que estuda o conhecimento do ser (ontos=ser + logoi=conhecimento). Sua questão fundamental é “o que é isto?”, portanto, trata de questões relativas ao mundo do real e não propriamente das representações feitas pelo nosso pensamento. No contexto da computação, a palavra ontologia é utilizada quando se quer fazer uma descrição de um determinado objeto de estudo, neste caso, os widgets de interface. Widget (um termo ainda sem tradução para o português) é um elemento de interface com o qual o usuário pode interagir. Neste caso os widgets são abstratos, ou seja, são descritos modelos de interface especificando como os objetos navegacionais serão apresentados e quais elementos serão perceptíveis para o usuário, sem expressar sua forma ou funcionamento. Posteriormente estes modelos são mapeados para uma ontologia mais próxima da fase do projeto da interface abstrata, que descreve os widgets concretos.

A Ontologia de Widgets Abstratos (MOURA, 2004), foi desenvolvida na linguagem OWL (Onthology Web Language), uma linguagem desenvolvida para ser utilizada em/por aplicações que precisam processar o conteúdo em vez de simplesmente exibi-los ao usuário. De certa maneira, isso significa que uma aplicação não só consegue buscar dados em seu próprio sistema, mas sim “navegar” (analogamente à navegação em browsers na internet) por vários sistemas a fim de colher dados que a permitam inferir novos dados, fazendo uma leitura semântica dos primeiros.

A Ontologia de Widgets Abstratos é composta de 11 conceitos (ver Figura 2.6), que representam os seus elementos. Estes elementos são comparáveis às primitivas dos UIDs, pois oferecem suporte às mesmas interações realizadas pelo usuário com o sistema, como

32

entradas de dados (itens de dado ou estruturas de itens de dados), saídas do sistema (itens de dado ou estruturas de itens de dados), e operações realizadas pelo usuário. “Acredita-se que, através dos conceitos definidos nesta ontologia, é possível con“Acredita-seguir a representação de todas as interações do usuário com o sistema.” (MOURA, 2004).

As classes dessa ontologia representam um ou mais elementos abstratos das interfaces das aplicações hipermídia como é mostrado na Figura 2.6:

AbstractInterfaceElement

SimpleActivator ElementExhibitor VariableCapturer

PredefinedVariable IndefiniteVariable

ContinuousGroup DiscreetGroup MultipleChoices SingleChoice

CompositeInterfaceElement

AbstractInterfaceElement: esta classe é composta por 4 subclasses que definem os possíveis elementos abstratos. Estes elementos representam os possíveis tipos de interações entre o usuário e o sistema.

1. SimpleActivator: esta classe representa qualquer elemento capaz de reagir a eventos externos – caso típico do clicar o mouse – que possua um evento associado a ele, tais como ativar um link, um botão de ação, o envio de um e-mail, dentre outros

Figura 2.6 - Diagrama de Classes da Ontologia de Widgets Abstratos

33

2. ElementExhibitor: esta classe representa elementos que exibem algum tipo de conteúdo, como, por exemplo, um texto ou uma imagem;

3. VariableCapturer: esta classe representa os elementos capazes de capturar um valor, como, exemplo, as “Caixas de textos” e os elementos do tipo selecionador como: Check Box, RadioButton, entre outros.

Esta classe generaliza duas classes distintas:

• IndefiniteVariable: permite que o usuário insira dados através do uso do teclado. Pode representar um campo de formulário, ou seja, uma caixa de texto. O valor a ser capturado por esse elemento é desconhecido a priori.

• PredefinedVariable: permite a seleção de um subconjunto a partir de um conjunto de valores predefinidos; muitas vezes, esse subconjunto poderá ser unitário. As especializações dessa classe são:

ContinousGroup: permite a seleção de um único valor de um intervalo infinito de valores;

DiscreetGroup: permite a seleção de um único valor de um intervalo finito de valores

MultipleChoices: permite a escolha de um ou mais elementos de um conjunto enumerável de valores;

SingleChoice: permite a escolha de um único elemento de um conjunto enumerável de valores.

4. CompositeInterfaceElement: representa uma composição dos elementos abstratos citados acima.

34

Note que as classes “AbstractInterfaceElement”, “VariableCapturer” e

“PredefinedVariable” não são instanciadas diretamente, mas sim através de suas subclasses.

A ontologia também é definida através de propriedades que qualificam os widgets abstratos, indicando atributos dos elementos de interface, como a qual estrutura de navegação eles estão relacionados, a qual estrutura da Ontologia de Widgets Concretos eles estarão sendo mapeados, entre outros. A lista completa de propriedades está representada abaixo.

I. ObjectProperty:

• hasInterfaceElement: indica os elementos da classe “AbstractInterfaceElement” que compõem os elementos do tipo “CompositeInterfaceElement” e “AbstratctInterface”.

Domínio: AbstractInterface ou CompositeInterfaceElement.

• targetInterface: indica qual será a instância da classe “AbstractInterface” a ser criada quando esse elemento for ativado. Essa instância representa uma interface abstrata.

• mapsTo: indica o elemento, da Ontologia de Widgets Concretos, que será mapeado no elemento da ontologia de widgets abstrato. Esta propriedade está presente em todas as classes da ontologia de Widgets Abstratos.

II. DatatypeProperty

• blockElement: indica as tags HTML (no escopo do presente trabalho MXML) e classes CSS que serão usadas para a tradução de um elemento específico. Esta

35

propriedade é opcional para todas as subclasses da classe

“AbstractInterfaceElement”.

• isRepeated: é uma propriedade apenas do conceito “CompositeInterfaceElement”, que indica se os elementos que compõem esse conceito irão ou não se repetir um número arbitrário de vezes.

• compositionTag: indica uma tag HTML (no escopo do presente trabalho MXML).

Esta propriedade pertence à classe “CompositeInterfaceElement”. Ela é utilizada somente quando a propriedade “isRepeated”, dessa classe, possui como valor true.

Sua função é indicar qual a tag que irá separar os elementos dessa composição, que se repetem.

• fromAnchor: indica qual é a âncora descrita na ontologia navegacional, a qual a instância de um elemento abstrato corresponde.

• fromContext: indica qual é o contexto, descrita na ontologia navegacional, o qual a instância de um elemento abstrato pertence;

• fromIndex: indica qual o índice, descrito na ontologia navegacional, ao qual a instância de um elemento abstrato se refere;

• fromAttribute: indica qual é o atributo da ontologia navegacional correspondente à instância de um elemento abstrato;

• fromElement: indica qual é o elemento da ontologia navegacional correspondente à instância de um elemento abstrato;

• visualizationText: representa um valor que será apresentado pelo elemento concreto. Esta propriedade é utilizada apenas nos conceitos “ElementExhibitor” e

“IndefiniteVariable”.

36 2.3.4.2 Ontologia de Widgets Concretos

Utilizando-se dos elementos e primitivas da Ontologia de Widgets Abstratos, o processo de criação da interface modelou e mapeou os elementos de interface desejados para a ontologia abstrata. Cada elemento deve ser associado a uma das classes da ontologia e ser descrito através da linguagem OWL. Depois, com estas descrições dos elementos abstratos, é gerada outra descrição, desta vez mapeando cada elemento abstrato para um elemento concreto, que possuí descrições mais próximas das interfaces reais, considerando de maneira ainda rasa questões relativas ao ambiente em que será desenvolvido o sistema. Para fazer esta descrição, Sabrina Moura (MOURA, 2004) sugere a utilização de linguagens como XUL, LASZLO e outras. Estas linguagens estão bem mais próximas da interface concreta do que a proposta por Sabrina Moura, pois descrevem com certa precisão regras de consistência que devem ser consideradas quando da implementação do sistema e ainda cada tipo de mapeamento que pode ser feito.

A Ontologia de Widgets Concretos é descrita por algumas classes, que representam apenas um pequeno conjunto das possibilidades existentes. A seguir será exposto este conjunto. O presente trabalho irá definir mais classes que encontramos em ambientes de desenvolvimento MXML/ActionScript 3.0 no capítulo 4.

• Button: representa os elementos que possuem funções embutidas a serem realizadas, como: submit e reset por exemplo. Essas funções são executadas quando esse elemento é ativado, através do mouse ou do teclado;

• CheckBox: representa um tipo de botão que possui 2 estados:

selecionado ou não selecionado. O usuário pode alterar o estado desse elemento, clicando com o mouse ou via teclado, na caixa de verificação

37

desse elemento. Muitas vezes são utilizados grupos desse mesmo elemento, representando uma lista de opções, onde podem ser selecionados n elementos. Esse elemento é composto de um label e de um botão (caixa de verificação).

• CheckBoxAction: representa um elemento do tipo form, composto de dois elementos distintos: um CheckBox (descrito anteriormente) e um Button (com a ação de submit);

• ComboBox: representa uma lista de itens. Consiste em uma caixa de entrada de texto e de um menu, a partir do qual o usuário pode selecionar uma dentre as diversas alternativas (uma lista);

• ComboBoxAction: representa um elemento do tipo form, composto de dois elementos distintos: um ComboBox (descrito anteriormente) e um Button (com a ação de submit);

• ComboBoxTarget: representa o elemento ComboBox (descrito anteriormente), composto de uma lista de elementos, onde cada elemento representa um link específico, ou seja, quando o usuário realizar a escolha do elemento e selecioná-lo na lista, automaticamente será executada uma ação, podendo ser esta a chamada de uma interface abstrata;

• Form: representa um conjunto de elementos de interface. Ele possui dois atributos: method (get ou post - método http para a submissão do formulário) e action (contém uma informação, indicando o que vai acontecer quando o formulário for submetido). O atributo action pode conter um endereço http, um nome de uma página, um endereço eletrônico, entre outras informações. Quando o botão de um elemento form é selecionado, todos os valores dos elementos concretos que o compõem, são submetidos

38

para a URL descrita no atributo action. O código HTML desse elemento é composto da descrição de um botão com a função de submit;

• Image: representa elementos concretos que exibem figuras;

• Label: conhecido como rótulo, representa um valor (texto/string) que é exibido na interface;

• Link: representa ligações pelas quais se pode navegar para outra parte:

do mesmo documento (outra parte na mesma página);

de outro documento (página, arquivo de imagem) da mesma aplicação hipermídia;

de outro documento, em qualquer computador da rede;

e, evidentemente, para se copiar todos esses arquivos (download)

• RadioButton: representa um tipo de botão que possui 2 estados:

selecionado ou não selecionado. Seu estado pode ser alterado pelo clique do mouse ou via teclado na caixa de verificação desse elemento. Na maioria das vezes são utilizados grupos desse elemento para representar um conjunto de opções, onde é permitida a seleção de apenas um elemento do conjunto;

• RadioButtonAction: representa um elemento do tipo form composto de dois elementos distintos: um RadioButton (descrito anteriormente) e um Button (com a ação de submit);

39

• RadioButtonTarget: representa o elemento RadioButton (descrito anteriormente) com um link embutido na definição de cada item da lista desse elemento;

• TextBox: representa um campo de entrada de informação. Este campo é composto de apenas uma linha e pode ter n colunas;

• TextArea: representa um campo de entrada de informação. Esse campo é composto de n linha e n colunas e ele pode conter barras de rolagem horizontal de vertical, se for o caso;

• Composite: representa composições de elementos de interface.

Uma interface é mapeada em um elemento concreto composite, pois ela representa uma composição de vários elementos de interface. Podem-se mapear outras composições mais simples de elementos para esse conceito.

O mapeamento se dá seguindo as regras de consistência, a qual define quais classes abstratas podem ser mapeadas para quais classes concretas. Um exemplo de regra de consistência, que expressa a quais elementos de interface concreta o elemento de interface abstrata SimpleActivator pode ser mapeado, se apresenta a seguir (Figura 2.7):

40

Figura 2.7 - Regra de consistência de Mapeamento Concreto

Esta regra diz que os elementos abstratos “SimpleActivator” são subclasses da classe AbstractInterfaceElement (como todos os outros), e que estão restringidos a serem mapeados para os elementos “Link” e “Button”. Se forem observadas as ontologias previamente descritas, se perceberá que são realmente os dois únicos elementos de interface que podem ser considerados como ativadores simples de ações pelo usuário. As outras classes ou são mais complexas, sendo uma composição de elementos incluindo

“SimpleActivator”, ou não tem relação com ativação de ações pelo usuário.

Na proposta feita por Moura (2004) depois de ser realizado o mapeado os elementos abstratos para os concretos, é então construído o projeto do layout (disposição dos elementos) da interface com o usuário. É então aplicado o modelo de caixas do padrão CSS, no qual cada elemento de interface concreta é enclausurado por uma caixa definida por estilos CSS, provendo através da propriedade “BlockElement” da Ontologia de Widgets Abstratos a informação de qual tipo de ‘caixa’ que o elemento concreto será colocado. No caso desta proposta, o sistema seria implementado em HTML, logo, este mapeamento das

41

caixas está diretamente relacionado com as tags da linguagem HTML. Além disso, nesta propriedade, pode ser definida a classe CSS a qual o elemento estará relacionado, já produzindo diretrizes para como serão exibidos os elementos de interface visual. Esta relação é efetivamente construída quando da implementação do sistema.

No contexto do presente trabalho, a implementação feita em Flex permite utilizar outra gama de containers (Block elements) para o enclausuramento dos elementos de interface. Da mesma maneira como acontece em HTML, em MXML existem diversos tipos de elementos de disposição espacial que podem ser utilizados como valor da propriedade blockElement. Será feito também o mapeamento dos componentes MXML para a Ontologia de Widgets Abstratos, criando modelos de interface adaptados para a configuração de interfaces Flex adequadas.

2.3.4.3 Abstract Data Views (ADVs)

“A partir do esquema de classes de navegação e o esquema de contextos navegacionais, são gerados ADVs (Abstract Data Views) correspondentes a cada interface do sistema. Os ADVs representam os elementos da interface e como eles reagirão a eventos (tanto do usuário como do sistema), criando uma visão clara de como se dá a experiência do usuário ao navegar pelo sistema. Os ADVs são bastante semelhantes aos Diagramas de Navegação, permitindo que o projeto prossiga de maneira uniforme.” (ROSSI, 1996)

São extraídos ADVs para cada nó, índice, classe navegacional e contexto do projeto de navegação. Os ADVs são compostos por outros ADVs, estados, transições e atributos.

ADVs aninhados nos permitem descrever a agregação de elementos de interface, e sua lógica é facilmente mapeada para elementos de programação descritos por tags

42

(marcações), ou seja, transpor um sistema da modelagem de interface abstrata para a implementação em linguagens de tags se dá de maneira natural.

Quando num determinado ADV existem estados ou outros ADVs que são habilitados visualmente ou desabilitados, utilizamos a variável perceptionContext para fazer este controle. Elementos que estão adicionados a esta variável são exibidos na interface, já elementos retirados da variável deixam de ser percebidos pelo usuário.

O ADV da Figura 2.8 representa a classe navegacional Programa de Radio:

ADV Programa de Rádio

nome: String data: String tempo: String

ADV DJ nome: String

ADV Musicas

nome: String artista: String

Figura 2.8 – Abstract Data View para Programa de Rádio