Sie sind auf Seite 1von 130

UNIVERSIDADE FEDERAL DE SANTA CATARINA – UFSC CENTRO TECNOLÓGICO – CTC DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA – INE CURSO DE CIÊNCIAS DA COMPUTAÇÃO

Extensão do método OOHDM para publicação de

aplicações hipermídia em Flex

Pedro Germani Ghiorzi

Profª. Orientadora: Patrícia Vilain

Trabalho de conclusão de curso apresentado

como parte dos requisitos para obtenção do

grau

de

Bacharel

Computação

em

FLORIANÓPOLIS, 2008/1

Ciências

da

Pedro Germani Ghiorzi

Extensão do método OOHDM para publicação de

aplicações hipermídia em Flex

Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Ciências da Computação

Orientadora: Patrícia Vilain

Banca examinadora

Leandro José Komosinski

Ricardo Pereira e Silva

Florianópolis, Junho de 2008

DEDICATÓRIA (S) ( opcional ):

folha seguinte

AGRADECIMENTO (S) ( opcional ):folha seguinte

SUMÁRIO

1 INTRODUÇÃO

10

2 HIPERMÍDIA E

14

2.1 HIPERMÍDIA

14

2.2 OOHDM

17

2.3 ETAPAS DO MÉTODO OOHDM

19

2.3.1 Análise de requisitos

19

2.3.2 Modelagem conceitual

22

2.3.3 Projeto de navegação

24

2.3.4 Projeto da interface abstrata

28

2.3.5 Implementação

41

3 FLEX E FLASH

43

3.1

FLEX

43

3.1.1 Versões lançadas e features associadas

44

3.1.2 Linguagens de

46

3.1.3 Criação de interfaces no Flex

51

3.2

FLASH

70

4 A PROPOSTA

74

4.1 EXTENSÃO 1 - ESPECIFICAÇÃO DOS WIDGETS ABSTRATOS

76

4.2 EXTENSÃO 2 - ESPECIFICAÇÃO DOS WIDGETS CONCRETOS MXML

81

4.3 EXTENSÃO 3 - ESPECIFICAÇÃO DE ADVS PARA FLEX

93

4.4 EXTENSÃO 4 - ESPECIFICAÇÃO DE VIEW STATES DO FLEX

97

5 MODELAGEM DE APLICAÇÃO OOHDM – FLEX

104

6 CONSIDERAÇÕES FINAIS

109

TRABALHOS FUTUROS

111

7 BIBLIOGRAFIA

112

8 ANEXOS

114

8.1 CASOS DE USO DA APLICAÇÃO DE EXEMPLO

114

8.2 DIAGRAMA DE UIDS PARA A APLICAÇÃO DE EXEMPLO

117

8.3 DIAGRAMA DE CLASSES CONCEITUAIS DA APLICAÇÃO DE EXEMPLO

118

8.4 REGRAS DE CONSISTÊNCIA ONTOLOGIA DE WIDGETS CONCRETOS ESTENDIDA

119

8.5 INTERFACE VISUAL DE COMPONENTES MXML

123

LISTA DE FIGURAS

Figura

2.1- UID Pesquisar Rádio

22

Figura 2.2 – Diagrama de Classes Conceituais

23

Figura 2.3 – Diagrama de Classes Navegacionais

25

Figura 2.4 - Diagrama de Contextos Navegacionais

26

Figura 2.5- Classes "emContexto" do nodo navegacional "Programa de Rádio"

27

Figura 2.6 - Diagrama de Classes da Ontologia de Widgets Abstratos

31

Figura 2.7 - Regra de consistência de Mapeamento Concreto

39

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

41

Figura 3.1 - Esquema de publicação de aplicações

46

Figura 3.2 – Esquema de publicação de Aplicações Flex

49

Figura 3.3 – Exemplo simples de aplicação Flex

51

Figura 3.4 - Dois estados de uma aplicação. À esquerda, o base state e à direta, o estado "Registro"

 

55

Figura 3.5 – Tela do Future Splash Animator

72

Figura 4.1 – Esquema simplificado do processo do método OOHDM

74

Figura 4.2 – Esquema do processo OOHDM estendido para criação de sistemas

75

Figura 4.3 - Classes da Ontologia de Widgets Abstratos extendida

79

Figura 4.4 - Exemplo de interface para seleção múltipla em um intervalo finito

80

Figura 4.5 - Sobreposição das classes de widgets abstratos

92

Figura 4.6 – Legenda da representação da classe de widgets abstratos nos ADVs

94

Figura 4.7 - Exemplo Estrutura do cabeçalho dos ADV Flex

94

Figura 4.8- Mapeamento de entidades navegacionais para ADVs

95

Figura 4.9 - ADV Programa de rádio

96

Figura 4.10 - Diagrama de ADVs

99

LISTA DE CÓDIGOS-FONTE

Código Fonte 3.1 - Exemplo de Aplicação MXML

50

Código Fonte 3.2 - Exemplo de aplicação MXML + ActionScript

50

Código Fonte 3.3 - Exemplo de implementação de view states

53

LISTA DE TABELAS

Tabela 2.1 - Etapas do Processo OOHDM

18

Tabela 4.1 Mapeamento de elementos dos UIDs para a Ontologia de Widgets Abstratos . 77

Tabela 4.2- Exemplo de definição de widgets abstratos

80

Tabela 4.3 - Definição de widgets concretos MXML a partir dos widgets abstratos

93

1

Introdução

As aplicações de internet se tornam a cada dia mais avançadas e complexas,

aumentando seu alcance na combinação de elementos multimídia e incorporando novas

tecnologias rapidamente.

O Adobe Flex é um ambiente de desenvolvimento de aplicações ricas de internet (rich

internet applications - RIAs) que publica aplicações que são executadas no Adobe Flash

Player, hoje em dia um dos softwares com maior penetração nos computadores ligados à

internet (ADOBE, 2008b). Com a criação da linguagem orientada a objetos ActionScript 3.0,

as “aplicações Flash” 1

deixam de ser apenas elementos componentes de um sistema

HTML, por exemplo, e passam a ser poderosas soluções para a criação da aplicação como

um todo. Apesar de se tornarem mais completas e de serem largamente utilizadas o que se

vê é que atualmente a grande maioria das aplicações publicadas na plataforma Flash é feita

de maneira ad hoc e sem nenhum planejamento adequado para prover recursos como

reusabilidade e manutenção.

Com o intuito de melhorar o desenvolvimento em Flex de sistemas hipermídia, isto é,

sistemas que trabalham com informações que são coleções de nodos multimídia (textos,

vídeos, imagens, animações vetoriais e outras mídias) interligados através de uma estrutura

de

navegação que permite ao usuário fazer uma incursão não-linear pelo sistema, há a

necessidade de um método de modelagem que incorpore, além dos aspectos normalmente

modelados pelos métodos tradicionais, questões relativas à navegação e também à criação

de interfaces complexas e personalizadas. Em estudo no qual faz comparações dos

métodos hipermídia, Koch, (1999, p. 2) comenta que normalmente os métodos tradicionais

de modelagem não consideram o projeto de navegação como um processo separado do

projeto de interfaces com o usuário.

1 Como serão denominadas as aplicações que executam no Flash Player criadas no Flex ou no Flash IDE

10

Como método direcionado para o desenvolvimento de sistemas hipermídia, pode-se

citar o Object Oriented Hypermedia Design Method (OOHDM) (SCHWABE; ROSSI, 1998).

O OOHDM é um método que apresenta todas as etapas necessárias para o projeto de um

sistema hipermídia permitindo, inclusive, o projeto de interfaces com o usuário de maneira

abstrata. Ele é um método iterativo composto de 5 etapas principais (Análise de Requisitos,

Modelagem

Conceitual,

Projeto

de

Navegação,

Projeto

de

Interface

Abstrata

e

Implementação), cada uma delas executada iterativamente, sempre refinando o resultado a

cada nova iteração.

OBJETIVO GERAL

Este trabalho tem como objetivo adaptar o método OOHDM para o desenvolvimento

de sistemas hipermídia em Flex, permitindo também uma flexibilidade na incorporação de

novos componentes de programação na medida em que o desenvolvedor utiliza o método.

OBJETIVOS ESPECÍFICOS

1. Estudo

do

método

OOHDM,

aprofundada sobre o método;

a

fim

de

estabelecer

uma

compreensão

2. Estudo sobre o desenvolvimento de interfaces e aplicações orientadas a objeto

no Flex;

3. Proposta de adaptação do método OOHDM para que as etapas de Projeto de

Interface

Abstrata,

e

de

Implementação

sejam

direcionadas

para

o

desenvolvimento de aplicações hipermídia em Flex;

4. Utilização do método OOHDM e da adaptação proposta neste trabalho no

desenvolvimento de um protótipo implementado em Flex.

11

JUSTIFICATIVA

Durante o projeto de uma aplicação hipermídia em Flex é preciso descrever o

comportamento dos objetos navegacionais e de interface com o usuário de maneira facilitar

o

mapeamento para o código MXML.Entretanto, é adequado que o projeto de navegação e

o

projeto da interface sejam realizados separadamente, pois o primeiro é independente do

segundo.

Esta separação é propícia para diminuir a dificuldade de comunicação entre o

desenvolvedor e o desenhista gráfico da aplicação, podendo estes se relacionar de maneira

a

evitar

ambigüidades

no

processo

de

desenvolvimento

devido

às

representações

esquemáticas geradas nas etapas do método OOHDM, portanto, existe a necessidade de

um método direcionado para o desenvolvimento de aplicações hipermídia em Flex para

tornar este desenvolvimento mais eficiente.

O trabalho está organizado como segue. O segundo capítulo do trabalho comenta de

maneira introdutória os conceitos de hipermídia, seguidos pela descrição detalhada sobre o

método OOHDM, suas etapas e processos envolvidos.

O terceiro capítulo apresenta o ambiente de desenvolvimento do Flex, suas linguagens

e faz uma análise do comportamento dos componentes de interface MXML encontrados na

especificação das classes da linguagem ActionScript 3.0.

O quarto capítulo apresenta propostas de extensões ao método OOHDM para facilitar a

construção de sistemas hipermídia utilizando o Flex como ambiente de programação.

Também são sugeridas algumas dicas de implementação utilizando algumas técnicas ou

componentes específicos do Flex.

12

O quinto capítulo mostra um exemplo de aplicação hipermídia desenvolvido em Flex

utilizando o método OOHDM e as extensões propostas neste trabalho.

O sexto capítulo apresenta as considerações finais sobre o processo de pesquisa deste

trabalho e sugere alguns trabalhos futuros.

13

Hipermídia e OOHDM. 2.1 Hipermídia

2

Hipermídia é um termo criado por Ted Nelson em um artigo chamado “Complex

information processing: a file structure for the complex, the changing and the indeterminate

(1965)”. Neste artigo, ele propõe uma estrutura de dados para especificação de sistemas de

gerenciamento

de

informações

(Xanadu),

em

que

todos

os

documentos

gerados

mundialmente fossem concentrados em um sistema de informação, e faz uma análise das

implicações que sistemas como estes teriam na sociedade na época. Hoje em dia o termo é

utilizado como uma extensão do termo “hipertexto”, significando o tipo de sistema de

informação que agrega diferentes tipos de mídia. Neles encontramos textos, imagens,

vídeos, sons, âncoras provenientes do hipertexto e outros elementos de navegação e

acesso a itens de dados que proporcionam uma interação não-linear do usuário com o

sistema.

Analisando este contexto, Vilain (2002) constata que:

Atualmente, as aplicações tradicionais baseadas em sistema de

informação,

quando

implementadas

na

WWW,

também

incorporam

o

conceito de navegação entre suas informações (nodos navegacionais).

Entretanto, os métodos usados durante o desenvolvimento de aplicações

tradicionais não são suficientes para modelar a navegação, principalmente

quando a quantidade de nodos nos quais o usuário navega é grande.

Esses métodos não abordam todos os aspectos relacionados com a

navegação e geralmente não dissociam a navegação da interface com o

usuário.

14

Para Zhang (2004, p. 2)

] [

existem 4 regras principais para determinar se um sistema pode ser

considerado de hipermídia:

1. Uma grande quantidade de informação é organizada em fragmentos

igualmente numerosos;

2. Os fragmentos se inter-relacionam;

3. O usuário precisa de apenas uma pequena parte da informação num

Segundo

dado momento;

4. A aplicação é ‘computer-based’.

Koch

(1999)

ainda

estamos

no

começo

do

aprendizado

de

como

desenvolver grandes sistemas de hipermídia. Ela nos coloca que os sistemas de CD-ROMs

ou sistemas WEB estão sendo construídos de maneira ad hoc e, portanto, sem um

planejamento adequado, o que faz com que logo se tornem insustentáveis no que diz

respeito à manutenção dos recursos e atualização de funcionalidades.

O desenvolvimento de sistemas de grande porte requer um controle maior por parte

dos desenvolvedores, pois são originados em ambientes que envolvem um grande número

de recursos e pessoas, como: programadores, desenhistas, publicitários, autores de

conteúdo e assim por diante. Assim como no desenvolvimento de outros tipos de software,

existem alguns métodos propostos especificamente para o projeto de sistemas hipermídia,

que se focalizam em questões habituais de um projeto computacional e também em como

fazer a análise da navegação do usuário em sua incursão pelo sistema.

Entre estes métodos existe o chamado Hypermedia Design Method (HDM), criado

por Schwabe, Garzotto e Paolini. O HDM (Hypermedia Design Method) foi um dos primeiros

15

métodos que definiu a estrutura e interação nas aplicações hipermídia. Segundo Garzotto

et al. (1993):

Para controlar a potencial explosão no número de links, uma aplicação

hipermídia na verdade não interconecta tudo, mas sim tenta diretamente

interconectar

apenas

as

partes

mais

importantes

e

significativas

da

informação para transmitir o significado global de maneira mais natural.

A partir desta afirmação é possível perceber que a preocupação de projetar sistemas

mais complexos estava em como organizar os dados de maneira que a experiência do

usuário e o funcionamento do sistema fossem melhores. Por uma melhor experiência do

usuário entende-se a capacidade de este se familiarizar com a interação com o sistema a

fim de permitir o rápido e preciso acesso às informações providas e na capacidade do

sistema de prover diferentes tipos de informações, ricas para o usuário. Já por um melhor

funcionamento do sistema entende-se a possibilidade de este sistema ser de manutenção

fácil, e por suportar um volume maior de tráfego de informações dos mais variados tipos

sem perder a propriedade de ser altamente confiável.

Nos sistemas tradicionais, a navegação não era considerada uma parte integrante da

abstração feita para a construção dos modelos e projeto do sistema, mas sim parte das

operações de interface entre usuário e o sistema. O reconhecimento desta necessidade de

se separar a elaboração da navegação da interface surge no início da década de 1990 com

os primeiros estudos de modelagem para sistemas Hipermídia. Desde então, o conceito de

navegação em hipermídia está diretamente relacionado com visões do modelo conceitual,

especificando de maneira relacional quais elementos de navegação serão percebidos pelo

usuário a cada estado do sistema.

16

2.2 OOHDM

O método Object-Oriented Hypermedia Design Method (OOHDM) é um método de

desenvolvimento de sistemas hipermídia criado por Schwabe e Rossi (1996). Este método

utiliza de conceitos da modelagem orientada a objetos como abstração e composição para

prover uma descrição completa, complexa e concisa dos itens de dados ou informações e a

separação

entre

a

modelagem

conceitual

do

sistema

da

modelagem

navegacional,

especificando padrões de navegação e transformações da interface.

OOHDM considera o processo de desenvolvimento da aplicação

hipermídia como um processo de quatro atividades, – Análise do domínio

(Análise de requisitos e Modelagem Conceitual), Projeto navegacional,

Projeto de interface abstrata e Implementação – desempenhadas em uma

mistura de estilos iterativos e incrementais de desenvolvimento; em cada

etapa um modelo é construído ou enriquecido. (Rossi, 1996, p. 13).

Cada etapa está relacionada com uma determinada questão de projeto, e assim um

modelo orientado a objetos é construído contemplando questões como reutilização e poder

de abstração. De acordo com (LIMA; SCHWABE, 2003, p. 4), “enquanto a modelagem

conceitual reflete os comportamentos e objetos do domínio da aplicação, o projeto

navegacional foca em questões relativas à organização do espaço navegacional, e às

tarefas e recursos do usuário.” Os fundamentos da abordagem OOHDM segundo Schwabe

e Rossi (1998, p.3) são:

A noção de que os objetos de navegação são visões, analogamente às visões

da base de dados, dos objetos conceituais;

O uso de abstrações apropriadas para organizar o espaço navegacional, com a

introdução do conceito de contexto navegacional;

A separação de questões de interface e questões de navegação;

17

A identificação explícita de que existem decisões de projeto (design) que

precisam ser feitas apenas quando da implementação.

A Tabela 2.1 (SCHWABE, 2005) nos mostra as etapas e artefatos gerados no

processo de desenvolvimento OOHDM.

Tabela 2.1 - Etapas do Processo OOHDM

Etapa

Artefatos

Formalismos

Mecanismos

Considerações

de Projeto

Análise de

Casos de uso, Anotações

Cenários, UIDs, Padrões de Projeto.

Análise de cenários e casos de uso, Entrevistas, Mapeamento UID – modelo conceitual

Captura dos

Requisitos

requisitos do

   

domínio da

aplicação

Modelagem

Classes,

Modelo Orientado a Objeto, Padrões de projeto.

Classificação,

Modela a

Conceitual

Subsistemas,

Agregação,

semântica do

Relações,

Generalização e

domínio da

Atributos

 

Especialização

aplicação

Projeto

Nodos, Âncoras,

Visões Orientadas a objeto, State charts Orientados a objeto, Classes de contexto, Padrões de Projeto, Cenários centralizados no usuário.

Classificação,

Leva em conta perfil do usuário e tarefas relacionadas. Ênfase em aspectos cognitivos. Constrói a estrutura navegacional da aplicação;

Navegacional

Estruturas de

Agregação,

acesso, Contextos

Generalização e

navegacionais,

Especialização

Transformações

navegacionais

Projeto de

Objetos de

Abstract Data Views, Diagramas de configuração; ADV-Charts; Padrões de projeto

Mapeamento

Modela objetos perceptíveis, implementando metáforas escolhidas. Descreve interface de objetos navegacionais. Define o layout dos objetos de interface;

Interface

interface Abstrata,

entre objetos

Abstrata

Respostas a

navegacionais e

eventos externos,

objetos

Transformações

perceptíveis

de interface

 

Implementação

Aplicação

Os suportados pelo ambiente de desenvolvimento

Os suportados pelo ambiente de desenvolvimento

Performance

executável

18

2.3

Etapas do método OOHDM

2.3.1 Análise de requisitos

O primeiro passo para a construção de um sistema, de acordo com o método

OOHDM é a analise e aquisição dos requisitos que irão determinar as funcionalidades e

comportamentos do sistema a ser projetado.

Primeiramente, o projetista identifica os atores que irão fazer parte do funcionamento

e utilização do sistema, e as ações que estes atores devem ou podem tomar.

Neste processo, é criada uma série de artefatos de projeto. Os casos de uso são

artefatos criados a partir da análise dos requisitos. Seu conteúdo é formado por ações do

processo de interação e comunicação entre o usuário e o sistema, como as que o usuário

deve ou pode realizar e que resposta o sistema terá que fornecer, porém, são suprimidas

questões relativas à implementação e interface, delegando estas questões para outras

etapas do e centralizando as atenções para o domínio real. Neles, a maneira de representar

esta interação está concentrada em descrições textuais desenvolvidas a partir de conversas

entre pessoas e também com e análise do domínio da aplicação.

Em seguida, os cenários são determinados para cada tarefa de cada ator. Estes

cenários são coletados para se construir os casos de uso, os quais são complementados

por “diagramas de interação entre o usuário e o sistema” (User Interaction Diagram - UID)

(VILAIN, 2002).

A seguir um exemplo de caso de uso de um sistema (que será utilizado em todos os

capítulos do trabalho) que é um sistema de uma Estação de Rádio on-line, na qual

acontecem programas de rádio ao vivo periodicamente, mas o usuário tem a opção de

pesquisar os programas exibidos anteriormente. O caso de uso a seguir representa a busca

por informações nesta rádio.

19

Caso de Uso: Pesquisar a radio

Atores: Comprador Descrição: O usuario tem a opção de selecionar o programa de rádio que deseja estar ouvindo dentre todos os programas já realizados. Aqui, pode obter informações sobre o programa atual (ao vivo) e os programas anteriores da radio, como playlist, informações sobre o DJ, os artistas e as musicas. O usuário pode ver os programas de um determinado DJ, todos os programas por data, todos os programas por nome ou ver informações sobre um DJ.

Os casos de uso podem ser descritos extensivamente para que a obtenção dos

dados seja mais precisa, especificando informações relativas diretamente a ações do

usuário ou respostas do sistema. São criados os casos de uso expandidos.

Caso de Uso Expandido: Pesquisar a radio

 

Ações do Ator

Resposta do sistema

 

1.

O usuário opta por pesquisar a radio

2.

O sistema exibe a lista de programas organizada por data de exibição, são exibidos os atributos data do programa, nome do programa e nome do DJ.

3.

O

usuário escolhe um dos

4.

O sistema exibe nome do programa, o nome do DJ que criou este programa, a data de exibição e a lista das musicas que foram exibidas neste programa.

programas

5.

O

usuário pode navegar para o

 

próximo programa ou programa

anterior por data de exibição.

O

usuário pode selecionar o DJ ou

alguma das musicas para visualizar

os dados específicos destes objetos.

6.

O

usuário pode navegar entre os

7.

programas e tocar o escolhido.

Nota:

6. Quando o usuário navega entre os programas, não é alterado o estado do

som, ou seja, o programa que esta tocando não para até que um novo programa seja executado.

A partir dos dados descritos nos casos de uso, são construídos os UIDs. Este

processo se dá em um conjunto de 6 passos (VILAIN et al, 2000, p.5):

20

1. Identificação dos itens de dados trocados entre usuário e sistema;

2. Separação dos dados em estados de interação. Dados que dependem de

outros

dados

distintos;

ou

de

opções

selecionadas

são

colocados

em

estados

3. Os itens de dados são separados em entre entradas de usuário ou saídas do

sistema.

4. Os estados de interação são conectados por transições de acordo com a

dependência dos dados

5. As operações do usuário são identificadas como opções associadas às

transições;

6. São adicionadas notas textuais que especificam requisitos não funcionais.

Os UIDs estão baseados em diagramas gráficos que exibem claramente que tipo de

informação está sendo trocada entre o usuário e o sistema, como por exemplo, quais tipos

de entradas de dados do usuário são obrigatórias ou opcionais. Isso faz com que a

ambigüidade e erros de interpretação sejam diminuídos, tornando o emprego dos UIDs um

método eficaz no entendimento e tratamento da funcionalidade do sistema a partir do ponto

de vista da relação usuário-sistema. Eles validam as interações entre estas duas entidades

criando um ambiente de planejamento mais sólido e confiável.

O UID da Figura 2.1 representa as informações do caso de uso pesquisar a Rádio:

21

<1> programa de radio (nome, data, DJ(nome)) 1 (escutar programa) 1 (ver detalhes) <2> (escutar
<1>
programa
de radio (nome, data, DJ(nome))
1 (escutar programa)
1 (ver detalhes)
<2>
(escutar programa)
programa de radio(nome, data, tempo, som, dj(nome),
musica(nome,
artista))
1(ver DJ)
<3>
UID ver DJ

Figura 2.1- UID Pesquisar Rádio

As elipses representam estados de interação, e os elementos internos a ela as

estruturas e itens de dados. As setas representam as transições de estado e os textos

associados a cardinalidade e as operações do usuário. Os UIDs então são validados pelo

projetista em conjunto aos atores, e aprimorados se necessário.

2.3.2 Modelagem conceitual

Durante esta etapa do processo, é construído o artefato “diagrama de classes

conceituais”, mostrando as classes e relações entre elas de acordo com a análise do

domínio da aplicação. As classes são descritas da mesma maneira como se faz utilizando

modelos UML, porém com algumas características específicas nos atributos: eles podem

ser de vários tipos (não-fortemente-tipados, representando diferentes perspectivas da

entidade equivalente no mundo real), e podem ter enumerações específicas (valores

determinados possíveis para tal atributo). As relações entre as classes também são

descritas de acordo com os modelos UML.

22

A partir dos UIDs é possível se extrair dados para a construção de um diagrama de

classes do desenvolvimento orientado a objetos, mapeando as estruturas de dados nas

classes e os itens de dados em atributos. As operações associadas a interações nos UIDs

podem ser mapeadas para operações nos métodos destas classes que estão diretamente

ligados ao domínio da aplicação a ser construída. Os dados também podem ser extraídos

dos textos dos casos de uso

A seguir é exibido um diagrama de classes parcial extraído do UID Pesquisar rádio

(Figura 2.2)

Programa de Rádio Musica nome: String nome: String 1 1 * data: String Artista: String
Programa de Rádio
Musica
nome: String
nome: String
1 1
*
data: String
Artista: String
tempo: String
som: Audio
playlist
ordem: Numero

cria

DJ nome: String perfil: Text foto: Imagem
DJ
nome: String
perfil: Text
foto: Imagem

Figura 2.2 – Diagrama de Classes Conceituais

23

2.3.3

Projeto de navegação

Nesta etapa do OOHDM é descrita a estrutura de navegação da aplicação

hipermídia o que representa as visões dos objetos conceituais que o usuário terá acesso e

as conexões entre os objetos. Esta estrutura é organizada em termos de contextos

navegacionais, os quais são obtidos a partir de classes de navegação, como nodos,

âncoras, índices e guias. Os contextos navegacionais levam em conta os tipos de usuários

e suas tarefas.

Os nodos representam visões (views) lógicas das classes conceituais definidas

durante a análise do domínio da aplicação, ou seja, diferentes modelos navegacionais

podem ser construídos para um mesmo esquema conceitual, expressando diferentes visões

sobre o mesmo domínio. Âncoras são derivadas das relações conceituais definidas no

processo de análise de requisitos e permitem ao usuário transitarem de um nó a outro, em

sua incursão pelo sistema.

A Figura 2.3 representa as classes (nodos) navegacionais “Programa de Rádio” e

“DJ”. A transição entre elas representa uma âncora entre os elementos (link). Note que em

contrapartida ao modelo conceitual, a classe musica se tornou agora um atributo da classe

Programa de Rádio, pois o nodo musica nunca será alcançado por usuários já que sempre

que este ver os dados sobre as musicas, estará vendo em um contexto maior o programa

de rádio que contém estas músicas. As classes navegacionais são representadas com um

quadrado vazio no canto superior direito.

24

Programa de Rádio DJ nome: String data: String tempo: String som: Audio NomeDJ: nomeDJ de
Programa de Rádio
DJ
nome: String
data: String
tempo: String
som: Audio
NomeDJ: nomeDJ de DJ por Programa
idxMusicas: nome, artista de Musica por programa
nome: String
perfil: Text
foto: Imagem
programas: nome, data de Programas por DJ

Figura 2.3 – Diagrama de Classes Navegacionais

Definindo a semântica navegacional a partir de nodos e âncoras, é possível modelar

a movimentação no espaço navegacional, criando a possibilidade de o usuário poder

apenas ter acesso a determinados atributos nodos independente da modelagem conceitual

(como por exemplo, apenas usuários do tipo DJ podem ter acesso a estruturas de edição

dos atributos dos programas de rádio.

Levando em consideração a afirmação de que objetos navegacionais são visões

(views) dos objetos conceituais, conclui-se que os objetos navegacionais especificam quais

informações

dos

objetos

conceituais

devem

ser

processadas

e

quais

as

possíveis

interações de navegação entre elas, de acordo com as tarefas do usuário que devem ser

suportadas pelo sistema. Durante este passo, definimos os itens de dados que serão

manipulados pelo usuário levando em conta “o que vai ser processado” e não “como vai ser

processado”.

Segundo Schwabe e Rossi (1998, p. 9) durante este processo da modelagem

navegacional devem ser definidos:

Quais os objetos que podem ser alcançados pelo usuário (nodos ou objetos

navegacionais);

Que relações existem entre estes nodos (os links);

25

Em qual conjunto de objetos o usuário navegará (os contextos navegacionais);

De que maneira estes dados serão acessados (as estruturas de acesso);

Quais

diferentes

conteúdos

devem

ser

apresentados

para

o

usuário,

dependendo do contexto em que ele está navegando.

As principais primitivas navegacionais OOHDM então são os objetos navegacionais, os

contextos navegacionais e as estruturas de acesso.

A modelagem navegacional gera dois importantes artefatos: o esquema de classes

navegacionais, e o esquema de contextos navegacionais. O primeiro define todos os

objetos navegáveis do sistema de acordo com visões sobre os objetos conceituais, e o

segundo as possíveis navegações entre estes objetos navegáveis. O modelo navegacional

pode evoluir independentemente do modelo conceitual, simplificando a manutenção do

conjunto de fatores que determinam a navegação.

A

Figura 2.4 exibe uma parte do esquema de contextos navegacionais.

Programa de Rádio DJ por nome por nome nome por data data por DJ Radio
Programa de Rádio
DJ
por nome
por nome
nome
por data
data
por DJ
Radio
DJ
por busca
busca

Figura 2.4 - Diagrama de Contextos Navegacionais

Estes contextos são acessados através de índices representados pelas caixas com

bordas pontilhadas. As caixas hachuradas representam as classes navegacionais e os

quadros internos os contextos navegacionais.

26

As

classes

“emContexto”

são

classes

adicionadas

ao

modelo

de

classes

navegacionais e que fazem o papel das diferentes visões que aquele determinado nodo terá

em relação aos seus contextos. Por exemplo, o nodo “Programa de Rádio” pode ser

navegado em 3 diferentes contextos, “por Data”, “por DJ” e “por Nome”. O primeiro é a

coleção dos Programas de rádio organizados em ordem de data de exibição, o segundo os

programas criados por um determinado DJ, e o terceiro todos os programas de rádio por

ordem

alfabética.

Cada

um

destes

contextos

inclui

todos

os

atributos

da

classe

navegacional e adiciona mais alguns conforme o projeto.

A Figura 2.5 a seguir nos mostra as classes “emContexto” do nodo navegacional

“Programa de Rádio”:

Programa de Rádio

Programa de Rádio nome: String data: String tempo: String som: Audio NomeDJ: nomeDJ de DJ por
nome: String data: String tempo: String som: Audio NomeDJ: nomeDJ de DJ por Programa idxMusicas:

nome: String data: String tempo: String som: Audio NomeDJ: nomeDJ de DJ por Programa idxMusicas: nome, artista de Musica por programa

Programa idxMusicas: nome, artista de Musica por programa Programa de Rádio por DATA Programa de Rádio
Programa de Rádio por DATA Programa de Rádio por DJ Programa de Rádio por NOME
Programa de Rádio por DATA
Programa de Rádio por DJ
Programa de Rádio por NOME
calendario:Calendario
proximo: anchor(programa por DATA)
anterior: anchor(programa por DATA)
idxProgramas: nome, data de
Programas por DJ
proximo: anchor(programa por DJ)
anterior: anchor(programa por DJ)
proximo: anchor(programa por NOME)
anterior: anchor(programa por NOME)

Figura 2.5- Classes "emContexto" do nodo navegacional "Programa de Rádio"

De acordo com Vilain (2002)

As classes em contexto podem ser vistas como decoradores. Elas

são definidas para representar as diferentes informações que os objetos

podem apresentar quando forem acessados dentro de diferentes contextos

27

de navegação. As informações comuns a todos os objetos de uma classe

navegacional, independente dos contextos nos quais eles aparecem, são

definidas no esquema de classes navegacionais. Portanto, uma classe em

contexto só é necessária se o nó tem uma aparência diferente e/ou âncoras

distintas no contexto em questão.

Com os diagramas de contextos e classes navegacionais, pode-se dar início ao

projeto de interface abstrata.

2.3.4 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

28

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 2 (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.

29

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

30

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

conseguir

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 CompositeInterfaceElement
AbstractInterfaceElement
SimpleActivator
ElementExhibitor
VariableCapturer
CompositeInterfaceElement
PredefinedVariable
IndefiniteVariable
ContinuousGroup
DiscreetGroup
MultipleChoices
SingleChoice

Figura 2.6 - Diagrama de Classes da Ontologia de Widgets Abstratos

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

31

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.

32

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

33

propriedade

é

opcional

“AbstractInterfaceElement”.

para

todas

as

subclasses

da

classe

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”.

34

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

35

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

36

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);

37

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):

38

Figura 2.7 - Regra de consistência de Mapeamento Concreto Esta regra diz que os elementos

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

39

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

40

de

programação

descritos

por

tags

(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

ADV Programa de Rádio nome: String data: String tempo: String ADV DJ nome: String ADV Musicas
nome: String data: String tempo: String ADV DJ nome: String ADV Musicas nome: String artista:
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

2.3.5

Implementação

A implementação mapeia os objetos da interface abstrata para objetos reais de

programação e pode envolver arquiteturas elaboradas de aplicação, como por exemplo,

41

sistemas cliente-servidor, ou questões relativas à interface gráfica complexa. O presente

trabalho focará em como implementar a interface de um sistema OOHDM utilizando

ActionScript 3/Flex, e em como transpor as premissas de interface abstrata para uma

interface concreta no ambiente de programação do Flex, ainda introduzindo o conceito de

STATES do Flex.

42

3

FLEX E FLASH

Neste capitulo serão apresentados dois frameworks de criação e publicação de

aplicações Flash, o Flash e o Flex. Ambos são ambientes para desenvolvimento de

softwares que são escritos na linguagem ActionScript, porém, o primeiro com um enfoque

maior na criação gráfica, com ferramentas de desenho e controle do tempo para animações

e transições através de uma timeline e o segundo com enfoque no desenvolvimento de rich

internet applications (RIAs). A combinação dos dois ambientes proporciona a criação de

aplicações avançadas e com expressividade visual (UIs, diversos tipos de mídia) bastante

superior ao encontrado hoje no campo das aplicações de internet.

3.1 Flex

“Flex é um framework open-source para criação de aplicações altamente interativas,

que são publicadas na maioria dos browsers através do Flash Player ou até mesmo no

desktop (em diferentes sistemas operacionais: Linux, MacOS e Windows) utilizando o

runtime Adobe AIR.“ (ADOBE, 2008a)

Flex nasceu da necessidade de se ter um ambiente de programação que mais se

aproximasse das questões relativas ao desenvolvimento de sistemas web, de maneira que

fossem de fácil criação, que utilizassem o flash player como base de execução sem que o

desenvolvedor precisasse conhecer das técnicas de animação do Flash. Com Flex,

podemos elaborar aplicações para web de maneira similar ao código HTML, pois foi

desenvolvida uma nova linguagem de programação no paradigma de linguagens de

43

marcação, baseada em XML, chamada de MXML que possibilitou essa analogia. Com as

marcações MXML, é possível criar interfaces de aplicações mais facilmente do que no

ambiente de desenvolvimento (IDE) do Flash, que requer um conhecimento de desenho

vetorial e do esquema de criação de componentes.

Apesar desta nova linguagem, MXML está baseado em classes ActionScript 3.0, ou

seja, utiliza-se da mesma estrutura do Flash, mas com a possibilidade de o programa ser

escrito de outra forma. No tempo de compilação, as marcações MXML são transformadas

em instancias das classes ActionScript 3.0, isto é, o programa pode ser escrito utilizando de

maneira hibrida MXML e ActionScript. Normalmente, a primeira faz a composição dos

elementos de interface, suas propriedades e eventos associados, enquanto que a segunda

descreve a lógica da aplicação.

Com o surgimento do Flex, a Macromedia (criadora do sistema) entra para o mundo

da criação das chamadas RIAs (Rich Internet Applications). Estas aplicações podem ser

compiladas em tempo de execução, quando o usuário as requisita no servidor, fazendo com

que a interface pudesse ser gerada neste momento em vez de ser totalmente pré-

determinada em tempo de implementação. Isso possibilita a “concorrência” com sistemas

tradicionais de web dinâmica, como HTML/JavaScript.

3.1.1 Versões lançadas e features associadas

A. Flex 1.0

Em um primeiro momento, a publicação de aplicações Flex se dava através do Flex

Data Services, um servidor que deveria ser instalado para dar suporte às requisições

da aplicação. O código era compilado em tempo de execução através do J2EE

(Java) e entregava um executável [.SWF] para o browser do usuário. A criação dos

44

programas se dava através de um editor de textos comum, e um compilador em

linha de comando.

Uma grande característica destes sistemas é que o usuário realizava navegação

entre elementos do sistema de maneira que este não precisava ser recarregado do

servidor a cada requisição, mas sim, analogamente ao que acontece hoje com AJAX

(que realiza comunicação assíncrona), apenas os dados eram modificados, criando

a sensação de que o sistema é conciso, e não um conjunto de páginas sem relação

umas com as outras.

B. Flex 2.0

Esta versão do Flex é o primeiro produto Macromedia lançado sob a bandeira da

Adobe. A maior mudança feita nesta versão é a migração de uma IDE ultrapassada

para uma totalmente nova baseada na plataforma Eclipse. Também não se fez mais

necessária a utilização da plataforma Flex Data Services, portanto uma aplicação

Flex podia ser publicada apenas usando o SDK Flex.

Ao mesmo tempo, a Adobe lança a linguagem ActionScript 3.0, fazendo com que o

Flex agora suportasse todas as características desta nova linguagem.

C. Flex 3.0

A ultima versão do Flex foi lançada pela Adobe com o código aberto, apesar da IDE

continuar proprietária. Foi lançada também pela primeira vez a plataforma Adobe

AIR, que trás os sistemas criados em Flex para o desktop, possibilitando a interação

entre o sistema ActionScript 3.0, PDF, JavaScript e HTML, o sistema de arquivos e

hardwares do usuário. Foi também reformulada e ampliada a integração entre Flex e

os outros softwares de criação da Adobe.

45

3.1.2

Linguagens de programação.

As linguagens Flex agregam dois importantes paradigmas de desenvolvimento de

software: as linguagens de marcação (markup languages), representadas pela MXML e as

linguagens de programação orientadas a objeto, representada pela ActionScript 3.0.

Como as linguagens de marcação são inadequadas para prover uma programação

lógica para a comunicação entre o usuário e o sistema, é utilizada em conjunto em um

programa escrito em MXML a linguagem ActionScript, através da marcação <mx:Script>,

que suporta programação orientada a objetos, e permite a comunicação entre diversos

sistemas e gerenciamento de eventos emitidos pelos componentes lógicos ou pelo usuário.

Um programa escrito em MXML representa em suas marcações, instâncias das

classes ActionScript, ou seja, são linguagens baseadas na mesma API (as classes

ActionScript). A Figura 3.1 exibe um esquema de como as aplicações Flex são construídas.

um esquema de como as aplicações Flex são construídas. Figura 3.1 - Esquema de publicação de

Figura 3.1 - Esquema de publicação de aplicações Flex.

46

3.1.2.1

ActionScript 3.0

ActionScript 3.0 é uma linguagem de programação orientada a objetos utilizada para

publicação de aplicações Flash. Por aplicações Flash entende-se todo tipo de aplicação que

é executada no Flash Player, sendo ela criada no ambiente Flash ou Flex. Os programas

escritos nesta linguagem são compilados em programas que são executáveis na máquina

virtual do Flash Player [extensão .SWF]. ActionScript é uma implementação do padrão

ECMAScript que mantém a mesma sintaxe do JavaScript, mas com um framework de

programação diferente e com diferentes bibliotecas de classes. O ActionScript é utilizado

para criar praticamente todas as interatividades vistas em aplicações Flash. Como o Flash

provê uma compreensão melhor sobre gráficos vetoriais do que o navegador, e por

proporcionar uma linguagem de script focada na animação gráfica, está sendo considerado

como uma adição importante nas capacidades do navegador. Esta tecnologia conhecida

como Asynchronous Flash and XML é comparada com o AJAX (Asynchronous JavaScript

and XML), mas com um possível maior potencial do que o último.

Esta linguagem engloba muitos recursos, como por exemplo a verificação de tipos

de dados em tempo de compilação e em tempo de execução; A implementação efetiva de

um sistema de herança baseado em classes e não em protótipos; Suporte para “package”,

“namespace” e expressões regulares; Revisão completa da API do Flash, separado agora

em classes; Gerenciamento de eventos feito de acordo com a especificação “DOM event

handling”; Integração com XML mais eficiente que nas versões anteriores, e conformidade

total com o padrão “ECMAScript Fourth Edition Draft specification” (MOOCK,2007).

47

3.1.2.2

MXML

As linguagens de marcação se tornaram um padrão no desenvolvimento de softwares

para internet, e são poderosas quando se quer especificar uma interface com o usuário, de

maneira que a disposição dos elementos é tratada de maneira adequada e de fácil

interpretação.

MXML, baseada em XML, é composta de várias marcações que compõe a aplicação,

sendo mais completa que HTML, por prover uma gama mais completa e interessante de

componentes de programação, como menus e elementos de controle de dados mais

complexos que as simples e ‘duras’ tabelas do HTML. Além de facilitar a publicação de

interfaces, MXML também pode ser usado nas camadas lógicas, fora do âmbito visual,

fazendo, por exemplo, chamadas a funções para controle de bases de dados e integração

com outros sistemas escritos em outras linguagens, como linguagens server-side como

PHP, ColdFusion ou JSP, entre outras.

Em uma marcação MXML podemos definir os estilos, atributos e eventos do objeto,

de maneira que os eventos podem fazer chamadas a funções ActionScript da mesma

maneira que HTML faz chamadas a funções JavaScript.

“A diferença básica entre a publicação MXML e a publicação HTML, é que a primeira

é “renderizada” pelo Flash Player, em contrapartida da “renderização” pelo browser no

HTML. Isso permite uma gama de possibilidades em relação à apresentação da interface,

que

pode

conter

animações,

efeitos

de

transição,

efeitos

gráficos,

vídeos

e

sons

nativamente, sendo muito mais poderoso e muito mais amigável ao usuário do que a

publicação baseada em páginas do HTML.” (COENRAETS, 2003)

O sistema de publicação do MXML se assemelha muito com as JavaServer Pages

(JSP) quando é feita compilação “On The Fly”. O usuário (cliente) faz a requisição via http

para o servidor, que compila em tempo real o código MXML para um executável (.SWF) e o

48

envia para o cliente. Em JSP o que acontece é semelhante, a diferença é que o código é

executado no servidor (Java servlets), em contrapartida o código do ambiente MXML é

executado no cliente, proporcionando uma menor sobrecarga do servidor e distribuindo o

processamento. A partir do momento que um cliente recebe o código executável compilado,

as próximas requisições a um mesmo arquivo não gerarão uma compilação, bastando ao

servidor determinar qual é o arquivo que o cliente precisará executar, o qual já estará em

poder do mesmo. Isso traz inúmeras vantagens ao que diz respeito ao volume de

processamento efetuado pelo servidor e tráfego de rede. Também é possível publicar o

arquivo executável compilado ([.SWF] para o Flash Player). Quando compilamos um

programa escrito em MXML, é gerado um código intermediário em ActionScript 3.0 e só

então esse código é traduzido para o executável (.SWF), ou seja, as marcações MXML

representam classes ou atributos das classes ActionScript, então, são instanciadas estas

classes de acordo com a estrutura de tags quando o programa é compilado. A Figura 3.2

representa o esquema de publicação de aplicações Flex.

representa o esquema de publicação de aplicações Flex. Figura 3.2 – Esquema de publicação de Aplicações

Figura 3.2 – Esquema de publicação de Aplicações Flex

49

utilizando PHP como arquitetura server-side.

O programa a seguir (Código Fonte 3.1) exemplifica uma aplicação MXML. Ela copia

o texto contido em um campo de texto para outro campo de texto quando se pressiona o

botão “Copiar”.

Código Fonte 3.1 - Exemplo de Aplicação MXML

1

<?xml version="1.0" encoding="utf-8"?>

2

<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml">

3

4

5

<mx:TextInput id="fonte" />

6

<mx:Button label="Copiar" click="destino.text = fonte.text" />

7

<mx:TextInput id="destino" />

8

9

</mx:Application>

O código acima pode ser expandido, usando a tag <mx:Script> para conter o código

ActionScript da função a ser chamada quando do acionamento do evento “Click” do botão

“Copiar”, como pode ser visto no (Código Fonte 3.2).

Código Fonte 3.2 - Exemplo de aplicação MXML + ActionScript

1

<?xml version="1.0" encoding="utf-8"?>

2

<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml">

3

4

<mx:Script>

5

6

function copiar() {

7

destino.text = fonte.text;

8

}

9

10

</mx:Script>

11

12

<mx:TextInput id="fonte" />

13

<mx:Button label="Copiar" click="copiar()" />

14

<mx:TextInput id="destino" />

15

16

</mx:Application>

Ambos os códigos acima geram um programa que é executado em um Flash Player,

como pode ser visto na

50

Figura 3.3:

Figura 3.3 : Figura 3.3 – Exemplo simples de aplicação Flex 3.1.3 Criação de interfaces no

Figura 3.3 – Exemplo simples de aplicação Flex

3.1.3 Criação de interfaces no Flex

As linguagens Flex permitem a criação de vários tipos de componentes de interface,

além componentes de controle tradicionais, como caixas de textos, botões, comboboxes,

checkboxes e radio buttons, MXML provê controles avançados nativos de manipulação de

dados estruturados, como DataGrids e TreeViews, além disso, existem muitas marcações

de disposição espacial dos elementos e de controle de navegação pré-definidos.

Para o controle espacial, existem elementos como caixas de ajuste vertical e

horizontal, grades e telas (canvas), que permitem ao desenvolvedor dispor os elementos de

interface de maneira intuitiva, e que acompanhem o dimensionamento da tela (tamanho do

monitor e/ou do browser onde está sendo executada a aplicação) alterando ou não o

tamanho dos elementos. Por exemplo, é possível fazer com que elementos sejam dispostos

na tela aproveitando o maior espaço possível, sem distorcer imagens ou alterar tamanhos

de botões, em compensação, quando existe uma tabela de dados o espaço pode ser

aproveitado para mostrar maior quantidade de dados ao mesmo tempo sem que o tamanho

mínimo da tabela seja ultrapassado.

Para o controle de navegação por parte do usuário, existem menus pré-definidos,

para organizar claramente as informações e os processos da aplicação. Entre eles

podemos destacar o TabNavigator, o Accordion e os ViewStacks. Este último é um conjunto

51

de canvas (telas com posicionamento absoluto (x, y) dos objetos filhos) sobrepostos que o

usuário pode escolher visualizar na ordem que achar mais conveniente, através de

controles de navegação, como Tabs, ou botões.

3.1.3.1 VIEW STATES Flex

States

é

uma

nova

classe

agregada

à

linguagem

ActionScript

3.0

e

conseqüentemente MXML, que nos fornece uma maneira de fazermos o controle de

estados da aplicação de acordo com mudanças na interface e propriedades dos objetos.

Por meio da marcação <mx:State> cria-se diferentes configurações para a interface da

aplicação e valores de atributos de objetos. São quatro as alterações possíveis:

Adição e subtração de elementos de interface;

Alteração do valor de atributos dos objetos;

Alteração do comportamento dos objetos (eventos que serão acionados);

Estilos visuais.

A seguir uma aplicação que tem uma tela de login com dois campos de texto, um

para o usuário e outro para a senha, e um botão de confirmação. Porém, quando um

usuário não registrado usa a aplicação ele tem a opção de se cadastrar no sistema,

ativando um segundo botão. Este cadastro pode ser feito através do mesmo formulário que

um usuário já registrado faria o login, mas, acrescido de um de campo de texto para a

confirmação da senha, com o texto exibido no botão modificado de “Login” para “Registrar”.

A funcionalidade do botão, que no estado inicial chamaria o método “login(usuário, senha)”,

no estado “Registro” chama “registrar(usuário, senha, confirma)”.

52

Esta aplicação pode ser implementada conforme o Código Fonte 3.3 que produzirá

uma aplicação de acordo com a Figura 3.4.

Código Fonte 3.3 - Exemplo de implementação de view states

1

<?xml version="1.0" encoding="utf-8"?>

2

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"

3

verticalAlign="middle"

4

width="340" height="250"

5

>

6

<mx:Script>

7

<![CDATA[

8

import mx.controls.Alert;

9

10

private function login(u:String, s:String):void{

11

12

Alert.show("Usuário: "+ u + "\nSenha: "+ s, "Login");

13

}

14

15

private function registrar(u:String, s:String, c:String):void{

16

if(s == c)

17

Alert.show("Usuário: "+ u + "\nSenha: "+ s, "Registro OK");

18

else Alert.show("Senha não confere! \n Senha: "+ s +

19

"\nConfirma: "+ c, "Registro Inválido!!!");

20

}

21

]]>

22

</mx:Script>

23

24

<mx:states>

25

<!--

26

O estado Registro é baseado no base state.

27

Todos os estados são baseados no base state por default,

28

então deixa-se a propriedade basedOn em branco.

29

-->

30

<mx:State name="Registro" basedOn="">

31

32

<!—Adiciona um componente FormItem ao form. -->

33

34

<mx:AddChild

35

relativeTo="{loginForm}"

36

position="lastChild"

37

creationPolicy="all"

38

>

39

<mx:FormItem id="confirma" label="Confirme:">

40

<mx:TextInput id="senha2"/>

41

</mx:FormItem>

42

</mx:AddChild>

43

44

<!—aplica propriedades no Painel e no botão -->

45

<mx:SetProperty target="{loginPanel}"

46

name="title" value="Registro"/>

47

48

 

49

<mx:SetProperty target="{loginButton}"

50

name="label" value="Registro"/>

51

52

<mx:SetEventHandler target="{loginButton}"

53

53

name="click"

54

handler="registrar(user.text, senha.text, senha2.text);"/>

55

56

 

57

<!—remove o LinkButton existente. -->

58

59

<mx:RemoveChild target="{registerLink}"/>

60

61

<!--

62

adiciona um novo Linkbutton para trocar o

63

o view state de volta para o base state.

64

-->

65

<mx:AddChild relativeTo="{spacer1}" position="before">

66

<mx:LinkButton

67

label="Retornar para Login" click="currentState=''"/>

68

</mx:AddChild>

69

70

</mx:State>

71

72

</mx:states>

73

74

<mx:Panel title="Login" id="loginPanel" horizontalScrollPolicy="off" verticalScrollPolicy="off" verticalAlign="middle"

75

76

77

78

>

79

80

<mx:Form id="loginForm">

81

<mx:FormItem label="Usuário:">

82

<mx:TextInput id="user"/>

83

84

</mx:FormItem>

85

<mx:FormItem label="Senha:">

86

<mx:TextInput id="senha"/>

87

</mx:FormItem>

88

</mx:Form>

89

90

 

91

<mx:ControlBar>

92

<mx:LinkButton

93

label="Quer se registrar?" id="registerLink"

94

click="currentState='Registro'"

95

/>

96

97

<mx:Spacer width="100%" id="spacer1"/>

98

<mx:Button label="Login" id="loginButton"

99

click="login(user.text,senha.text);"/>

100

101

</mx:ControlBar>

102

103

</mx:Panel>

104

</mx:Application>

54

Figura 3.4 - Dois estados de uma aplicação. À esquerda, o base state e à

Figura 3.4 - Dois estados de uma aplicação. À esquerda, o base state e à direta, o estado "Registro"

A linha 94 do código representa o evento “click” do componente LinkButton. Este

evento altera a variável <mx:states> da aplicação (linha 24) e muda o view state atual para

“Registro”. A troca de funcionalidade do botão de confirmação está nas

linhas 99

(declaração inicial) e 54 (alteração do método chamado).

A transição de um estado para outro pode ser definida utilizando efeitos visuais para

criar uma experiência de usabilidade na troca entre os estados através da marcação

<mx:Transitions>. O desenvolvedor pode definir seqüências e paralelismos em uma

transição, definindo a ordem e concomitância em que acontecem animações, mudanças de

propriedades dos objetos e retirada ou adição de elementos de interface.

“mx:State”

pode

ser

utilizado

para

implementar

estados

de

componentes

customizados, e não só da aplicação como um todo. O exemplo mais básico seria um botão

que muda de estado a cada evento do mouse, como mouseOver, mouseDown, mouseUp e

assim por diante. São descritos estados para cada condição e, a cada evento disparado, o

estado é alterado.

Os mx:States são organizados hierarquicamente, sendo que cada aplicação ou

componente sempre tem um estado inicial (“base state”), e todos os outros estados são

55

filhos dele ou filhos de filhos. No caso da aplicação de exemplo acima, o estado base é

composto por todo conteúdo do mx:Panel (“loginPanel”) e o estado filho representado pelo

conteúdo da marcação mx:state (“register”). Caso seja declarado um estado vazio, o

conteúdo dele será idêntico ao do pai.

3.1.3.2 Componentes Flash e componentes Flex

O poder de customização e criação de componentes dos ambientes Flex e Flash é

muito vasto. Como Flex não foi feito para a criação de elementos gráficos, podem ser

criados

novos

componentes

de

interface

no

Flash

que

exportados

são

utilizados

nativamente no Flex, onde a estruturação por marcações facilita o desenvolvimento da

aplicação em si. Estas características proporcionam uma interatividade visual avançada,

possibilitando ao usuário uma experiência muito completa, e permitindo à equipe de

desenvolvimento uma gama muito maior de possibilidades. Note que o inverso não se

aplica. Componentes criados no Flex não podem ser utilizados em Flash.

Quando da criação de um novo componente de interface, seja ele feito no Flash ou

em Flex, podemos estender a classe de um componente nativo da linguagem e então dar

novas funcionalidades ao mesmo, e mais, este novo componente pode se tornar uma nova

marcação (tag) MXML. Portanto, a criação de elementos de interface que possam ser

facilmente expressos em uma linguagem de marcação torna este ambiente colaborativo um

dos mais promissores da internet hoje em dia.

3.1.3.3 Componentes MXML

Serão descritos os containers e controles MXML. A listagem com figuras para ilustração

encontra-se no anexo 8.5.

56

3.1.3.3.1

Containers (Agrupadores)

Accordion

Accordion é um elemento de navegação que contém um conjunto de painéis filhos,

mas apenas um deles é visível por vez pelo usuário. Além dos painéis filhos, são

criados botões para o acesso a cada um deles. Estes botões estão posicionados no

agrupador geral, e não em cada painel filho, permitindo uma fácil visualização de

que estamos vendo outro painel quando acionamos os botões.

ApplicationControlBar

Este é um agrupador que serve como espaço para componentes de controle que

provêm controle de navegação e comandos globais da aplicação. Ele pode ser

publicado de duas maneiras, a estacionária (dock) e a normal. Na estacionária, a

barra de controle é posicionada no topo da aplicação, enquanto no modo normal,

podemos posicionar a barra de controle em qualquer parte da aplicação como

qualquer outro componente de interface.

Box

O Box funciona como um <div> em HTML, com a diferença que temos que

especificar se os elementos internos a ele serão dispostos verticalmente ou

horizontalmente.

Portanto,

não

utilizamos

a

marcação

<mx:Box>

mas

sim

<mx:VBox> para uma caixa vertical e <mx:HBox> para uma caixa horizontal.

Canvas

Canvas é um espaço no qual a disposição dos elementos (containers e controles) é

feita de maneira absoluta, especificando-se a posição (x,y) explicitamente para cada

item contido. Estes itens podem ter o tamanho associado ao tamanho do canvas,

57

por exemplo definir que um elemento terá 100% da largura do container pai, fazendo

com que mesmo que o Canvas mude de tamanho, o elemento sempre toque as

bordas laterais do ‘pai’. Com este container, podemos fazer com que seus filhos

(containers e controles) se sobreponham, diferentemente de outros elementos

agrupadores nos quais sempre os elementos serão dispostos em seqüência.

ControlBar

Barra de controle que serve para ser colocada no rodapé de elementos Panel ou

TitleWindow. Ele sempre deve ser a última marcação colocada dentro destes

elementos.

DivideBox

São caixas divididas, nas quais o usuário pode alterar o tamanho das células. Assim

como o elemento “box”, não se usa a marcação <mx:DivideBox>, mas sim

<mx:HDivideBox> para uma caixa dividida em células dispostas lado a lado e

<mx:VDivideBox> para caixa dividida em células dispostas uma abaixo da outra.

Form

Formulários são containeres que agregam elementos de informação que serão

enviados

ao

sistema

para

que

o

controle

de

dados

seja

efetuado.

Neles,

diferentemente dos forms HTML, podemos criar regras para definir quais campos do

formulário são obrigatórios, e quais receberão controles de validação de dados.

Também podemos utilizar folhas de estilos para definir a aparência dos controles

internos a ele.

FormHeading

São cabeçalhos formados por um título, que indicam um subconjunto de itens de

controle de dados dentro de um Form. Os subitens deste cabeçalho ficam alinhados

58

com o mesmo, facilitando ao usuário a compreensão da diferença entre os conjuntos

de dados. Apesar disso, todos os subitens de todos os cabeçalhos dentro de um

Form pertencem a este mesmo Form. Cada um destes subconjuntos pode ter uma

folha de estilos distinta.

FormItem

Os itens de formulários são duplas “label”-“elemento”, onde elemento pode ser um

ou mais agrupadores ou controles arranjados verticalmente ou horizontalmente.

Grid

Grids são agrupadores semelhantes as tabelas HTML. Eles podem conter uma ou

mais linhas e cada linha pode conter uma ou mais colunas, ou itens. Sua utilização

se dá da seguinte maneira: uma marcação <mx:Grid> seguida de uma ou mais

marcações

<mx:GridRow>,

e,

dentro

de

cada

uma

destas,

marcações

<mx:GridItem> que representam as colunas da grade. Cada GridItem pode conter

quantos ‘filhos’ forem necessários.

Panel

Um painel é composto de uma barra de título, um título, uma borda e um canvas que