Adaptação do método OOHDM para publicação de. aplicações hipermídia em Flex

Transcrição

1 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 Adaptaçã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 em Ciências da Computação FLORIANÓPOLIS, 2008/1

2 Pedro Germani Ghiorzi Adaptaçã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

3 Dedico este trabalho aos meus pais, que tiveram tanta paciência nestes anos da minha graduação, e aos amigos Guilherme Bertoni Machado e Thiago Ramos dos Santos que me deram forças para permanecer como computeiro.

4 Agradeço à Teresa Maria Siewerdt, minha companheira querida, à professora Patricia Vilain pela orientação e amizade, e especialmente agradeço ao Leandro dal Bò, que me puxou de volta ao oficio da programação de computadores.

5

6 SUMÁRIO 1 INTRODUÇÃO HIPERMÍDIA E OOHDM HIPERMÍDIA OOHDM ETAPAS DO MÉTODO OOHDM Análise de requisitos Modelagem conceitual Projeto de navegação Projeto da interface abstrata Implementação FLEX E FLASH FLEX Versões lançadas e features associadas Linguagens de programação Criação de interfaces no Flex FLASH A PROPOSTA EXTENSÃO 1 - ESPECIFICAÇÃO DOS WIDGETS ABSTRATOS EXTENSÃO 2 - ESPECIFICAÇÃO DOS WIDGETS CONCRETOS MXML EXTENSÃO 3 - ESPECIFICAÇÃO DE ADVS PARA FLEX EXTENSÃO 4 - ESPECIFICAÇÃO DE VIEW STATES DO FLEX MODELAGEM DE APLICAÇÃO OOHDM FLEX CONSIDERAÇÕES FINAIS TRABALHOS FUTUROS BIBLIOGRAFIA ANEXOS CASOS DE USO DA APLICAÇÃO DE EXEMPLO DIAGRAMA DE UIDS PARA A APLICAÇÃO DE EXEMPLO DIAGRAMA DE CLASSES CONCEITUAIS DA APLICAÇÃO DE EXEMPLO REGRAS DE CONSISTÊNCIA ONTOLOGIA DE WIDGETS CONCRETOS ESTENDIDA INTERFACE VISUAL DE COMPONENTES MXML

7 LISTA DE FIGURAS Figura 2.1- UID Pesquisar Rádio Figura 2.2 Diagrama de Classes Conceituais Figura 2.3 Diagrama de Classes Navegacionais Figura Diagrama de Contextos Navegacionais Figura 2.5- Classes "emcontexto" do nodo navegacional "Programa de Rádio" Figura Diagrama de Classes da Ontologia de Widgets Abstratos Figura Regra de consistência de Mapeamento Concreto Figura 2.8 Abstract Data View para Programa de Rádio Figura Esquema de publicação de aplicações Flex Figura 3.2 Esquema de publicação de Aplicações Flex Figura 3.3 Exemplo simples de aplicação Flex Figura Dois estados de uma aplicação. À esquerda, o base state e à direta, o estado "Registro" Figura 3.5 Tela do Future Splash Animator Figura 4.1 Esquema simplificado do processo do método OOHDM Figura 4.2 Esquema do processo OOHDM adaptado para criação de sistemas Flex Figura Classes da Ontologia de Widgets Abstratos extendida Figura Exemplo de interface para seleção múltipla em um intervalo finito Figura Sobreposição das classes de widgets abstratos Figura 4.6 Legenda da representação da classe de widgets abstratos nos ADVs Figura Exemplo Estrutura do cabeçalho dos ADV Flex Figura 4.8- Mapeamento de entidades navegacionais para ADVs Figura ADV Programa de rádio Figura Diagrama de ADVs

8 LISTA DE CÓDIGOS-FONTE Código Fonte Exemplo de Aplicação MXML Código Fonte Exemplo de aplicação MXML + ActionScript Código Fonte Exemplo de implementação de view states... 54

9 LISTA DE TABELAS Tabela Etapas do Processo OOHDM Tabela 4.1 Mapeamento de elementos dos UIDs para a Ontologia de Widgets Abstratos. 78 Tabela 4.2- Exemplo de definição de widgets abstratos Tabela Definição de widgets concretos MXML a partir dos widgets abstratos... 94

10

11 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 11

12 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, a fim de estabelecer uma compreensão aprofundada sobre o método; 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. 12

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

14 O sexto capítulo apresenta as considerações finais sobre o processo de pesquisa deste trabalho e sugere alguns trabalhos futuros. 14

15 2 Hipermídia e OOHDM. 2.1 Hipermídia 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. 15

16 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 dado momento; 4. A aplicação é computer-based. Segundo 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 16

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

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

19 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 Etapas do Processo OOHDM Etapa Artefatos Formalismos Mecanismos Considerações de Projeto Análise de Requisitos 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 do domínio da aplicação Modelagem Conceitual Classes, Subsistemas, Relações, Atributos Modelo Orientado a Objeto, Padrões de projeto. Classificação, Agregação, Generalização e Especialização Modela a semântica do domínio da aplicação Projeto Navegacional Nodos, Âncoras, Estruturas de acesso, Contextos navegacionais, Transformações navegacionais 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, Agregação, Generalização e Especialização Leva em conta perfil do usuário e tarefas relacionadas. Ênfase em aspectos cognitivos. Constrói a estrutura navegacional da aplicação; Projeto de Interface Abstrata Objetos de interface Abstrata, Respostas a eventos externos, Transformações de interface Abstract Data Views, Diagramas de configuração; ADV-Charts; Padrões de projeto Mapeamento entre objetos navegacionais e objetos perceptíveis Modela objetos perceptíveis, implementando metáforas escolhidas. Descreve interface de objetos navegacionais. Define o layout dos objetos de interface; Implementação Aplicação executável Os suportados pelo ambiente de desenvolvimento Os suportados pelo ambiente de desenvolvimento Performance 19

20 2.3 Etapas do método OOHDM 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. 20

21 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 1. O usuário opta por pesquisar a radio 3. O usuário escolhe um dos programas Resposta do sistema 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. 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. 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): 21

22 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 ou de opções selecionadas são colocados em estados distintos; 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: 22

23 <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) UID ver DJ <3> 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 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. 23

24 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 (Figura 2.2) A seguir é exibido um diagrama de classes parcial extraído do UID Pesquisar rádio Programa de Rádio Musica nome: String data: String tempo: String som: Audio 1 1..* nome: String Artista: String cria playlist DJ ordem: Numero nome: String perfil: Text foto: Imagem Figura 2.2 Diagrama de Classes Conceituais 24

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

26 Programa de Rádio nome: String data: String tempo: String som: Audio NomeDJ: nomedj de DJ por Programa idxmusicas: nome, artista de Musica por programa DJ 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); 26

27 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 nome por nome por nome Radio data DJ por data por DJ por busca busca Figura 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. 27

28 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 nome: String data: String tempo: String som: Audio NomeDJ: nomedj de DJ por Programa idxmusicas: nome, artista de Musica por programa Programa de Rádio por DATA calendario:calendario proximo: anchor(programa por DATA) anterior: anchor(programa por DATA) Programa de Rádio por DJ idxprogramas: nome, data de Programas por DJ proximo: anchor(programa por DJ) anterior: anchor(programa por DJ) Programa de Rádio por NOME 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 28

29 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 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 29

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

31 levando em conta os aspectos específicos do ambiente em que será implementada tal interface, definidos pela Ontologia de Widgets Concretos 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 31

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. Acreditase 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 PredefinedVariable IndefiniteVariable ContinuousGroup DiscreetGroup MultipleChoices SingleChoice Figura 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 32

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

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 34

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

36 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 36

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 37

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

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

40 Figura 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 40

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 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 41

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 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, 42

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

44 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 44

45 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 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 45

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

47 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. Figura Esquema de publicação de aplicações Flex. 47

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

49 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 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, 49

50 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. Figura 3.2 Esquema de publicação de Aplicações Flex utilizando PHP como arquitetura server-side. 50

51 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 Exemplo de Aplicação MXML 1 <?xml version="1.0" encoding="utf-8"?> 2 <mx:application xmlns:mx=" <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 Exemplo de aplicação MXML + ActionScript 1 <?xml version="1.0" encoding="utf-8"?> 2 <mx:application xmlns:mx=" 3 4 <mx:script> 5 6 function copiar() { 7 destino.text = fonte.text; 8 } 9 10 </mx:script> <mx:textinput id="fonte" /> 13 <mx:button label="copiar" click="copiar()" /> 14 <mx:textinput id="destino" /> </mx:application> Ambos os códigos acima geram um programa que é executado em um Flash Player, como pode ser visto na Figura 3.3: 51

52 Figura 3.3 Exemplo simples de aplicação Flex 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 52

53 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 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). 53

54 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 Exemplo de implementação de view states 1 <?xml version="1.0" encoding="utf-8"?> 2 <mx:application xmlns:mx=" 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{ Alert.show("Usuário: "+ u + "\nsenha: "+ s, "Login"); 13 } 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> <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 > 30 <mx:state name="registro" basedon=""> <! Adiciona um componente FormItem ao form. --> <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> <! aplica propriedades no Painel e no botão --> 45 <mx:setproperty target="{loginpanel}" 46 name="title" value="registro"/> <mx:setproperty target="{loginbutton}" 50 name="label" value="registro"/> <mx:seteventhandler target="{loginbutton}" 54

55 53 name="click" 54 handler="registrar(user.text, senha.text, senha2.text);"/> <! remove o LinkButton existente. --> <mx:removechild target="{registerlink}"/> <!-- 62 adiciona um novo Linkbutton para trocar o 63 o view state de volta para o base state > 65 <mx:addchild relativeto="{spacer1}" position="before"> 66 <mx:linkbutton 67 label="retornar para Login" click="currentstate=''"/> 68 </mx:addchild> </mx:state> </mx:states> <mx:panel 75 title="login" id="loginpanel" 76 horizontalscrollpolicy="off" verticalscrollpolicy="off" 77 verticalalign="middle" 78 > <mx:form id="loginform"> 81 <mx:formitem label="usuário:"> 82 <mx:textinput id="user"/> </mx:formitem> 85 <mx:formitem label="senha:"> 86 <mx:textinput id="senha"/> 87 </mx:formitem> 88 </mx:form> <mx:controlbar> 92 <mx:linkbutton 93 label="quer se registrar?" id="registerlink" 94 click="currentstate='registro'" 95 /> <mx:spacer width="100%" id="spacer1"/> 98 <mx:button label="login" id="loginbutton" 99 click="login(user.text,senha.text);"/> </mx:controlbar> </mx:panel> 104 </mx:application> 55

56 Figura 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. Os view states podem ser utilizados 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 view 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 56

57 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 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 Componentes MXML Serão descritos os containers e controles MXML. A listagem com figuras para ilustração encontra-se no anexo

58 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, 58

59 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 59

60 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 é o espaço destinado aos filhos do painel. TabNavigator TabNavigator é uma extensão do container ViewStack, adicionando uma barra de aletas (controle TabBar), que faz o controle de navegação entre as páginas do viewstack. Quando se aciona uma destas aletas, a página correspondente do viewstack associado é exibida, escondendo as demais. Tile 60

61 Exibição de elementos dispostos em mosaico ViewStack Disposição de elementos em múltiplos canvas dos quais apenas um está visível por vez. Enquanto os outros não são acessados, não são carregados na memória pelo programa Controles o Button É um botão tradicional, com aspecto gráfico que indica que pode ser acionado com o mouse ou teclado. Este componente é composto de um retângulo externo, um label e/ou um ícone. Os botões são normalmente utilizados em conjunto com event listeners, que fazem o controle do funcionamento do botão em função das ações do usuário. Quando é acionado, o botão emite um evento do tipo click e um mousedown. Um botão pode ter o comportamento de uma chave liga/desliga, ou seja, ele pode ter dois estados representados pela propriedade toggle, ou ser do tipo mais simples (equivalente a um push-button). o ButtonBar [navbar] Os ButtonBars são conjuntos de botões logicamente relacionados, dispostos de maneira vertical ou horizontal. Os botões são do tipo push-button, ou seja, não memorizam o estado depois de receberem uma ação de ativação. A maneira de adicionar ou remover botões da barra de botões é análoga à manipulação de dados em uma lista, com os métodos additem() e removeitem(), simplificando o gerenciamento da display list ActionScript 3. o CheckBox [button] 61

62 Checkbox é um componente composto de um label e uma caixa de seleção, a qual pode ou não conter uma marca de ativação. Os elementos CheckBox não são mutuamente exclusivos, ou seja, podemos marcar ou desmarcar as várias CheckBox contidas em uma aplicação conforme desejado (em contrapartida, ver RadioButton). o ColorPicker [combobase] É um selecionador de cores, no qual o usuário pode rapidamente escolher uma cor dentre uma gama de cores definidas. o ComboBase ComboBase é a classe mãe de componentes como ComboBox, ColorPicker e DateField. É composta por um campo de texto, e um botão para o acionamento de uma lista na qual pode se escolher a opção que será selecionada. Não é utilizada diretamente como uma marcação MXML, mas serve de base para os componentes ColorPicker e ComboBox. o ComboBox [combobase] O ComboBox é um componente composto de uma lista a qual o usuário seleciona apenas uma opção, uma caixa de texto que contém a opção selecionada, e um botão para exibir esta lista. É um componente análogo ao SELECT do HTML mas com a diferença de que o usuário pode (quando permitido) inserir novas entradas que não estão na lista, a partir da própria caixa de texto do componente. o DataGrid O DataGrid é como uma lista mas que pode mostrar mais de uma coluna de dados, sendo útil para a exibição de elementos que tem varias propriedades. É um componente que tem as seguintes características: 62

63 as colunas podem ser de tamanhos diferentes; as colunas podem ser redimensionadas em tempo de execução pelo usuário; as colunas podem ser reordenadas em tempo de execução pelo usuário; possibilidade de usar um itemrenderer para exibição de dados que não sejam textuais; possibilidade de ordenação das linhas acionando uma das colunas. DataGrid é um componente de interface construído para exibição de dados, e não uma ferramenta de disposição de elementos como as TABLES HTML. Para tal, existem os containers em MXML. o DateChooser Este componente é composto de uma barra de título, mostrando o nome do mês e o ano, e um calendário mostrando os dias daquele mês específico. O usuário pode selecionar uma data, um intervalo de datas ou então datas múltiplas. O controle dispõe de acionadores para modificar o ano/mês e o desenvolvedor pode restringir o intervalo de datas a serem exibidas. o DateField [combobase] O DateField é um controle composto por um campo de texto (TextField) para exibição de uma data, e um botão que aciona um DateChooser para seleção desta data. Quando a data é selecionada, o DateChooser é fechado e a data selecionada preenche o campo de texto. O usuário pode também digitar a data diretamente no campo de texto. o HorizontalList 63

64 Este componente exibe uma lista na qual os elementos são dispostos lado a lado. Caso existam mais elementos do que o número que pode ser exibido ao mesmo tempo dependendo do tamanho desta lista, o componente pode exibir uma barra de rolagem para o acesso a estes itens. o HScrollBar/VScrollBar [scrollbar] É uma barra de rolagem horizontal/vertical para o controle de exibição dos dados quando estes preenchem um espaço maior do que o container onde eles estão inseridos. Apesar de ser um controle independente, podemos associar a barra de rolagem a outros componentes para efetuar o controle de rolagem em seus conteúdos. As barras de rolagem são compostas por quatro elementos: dois botões com setas, um botão de rolagem e um trilho no qual o botão de rolagem percorre. A posição do botão de rolagem e a exibição das setas dependem do estado do controle. o HSlider/VSlider Os controles HSlider e VSlider permitem ao usuário fazer seleção de um ou mais valores dentre um intervalo. Composto de um trilho horizontal/vertical e um ou mais botões de rolagem. A seleção de valores é feita de maneira visual, arrastando os botões pelo trilho, e o valor é definido de acordo com valores máximo e mínimo definidos no trilho. Este conjunto de valores pode ser contínuo, ou ter valores específicos entre o máximo e o mínimo. o Image O controle de exibição de imagens permite importar arquivos JPG, PNG, GIF e SWF. Além disso, provê funções para embarcar estes arquivos no executável final 64

65 em tempo de compilação. Este componente é normalmente utilizado para importação de arquivos estáticos, que não farão parte da lógica do sistema e para criação de ItemRenderers. Para importação de outras aplicações Flex/Flash, é recomendado o uso de outro componente, o SWFLoader. Imagens embarcadas são carregadas imediatamente, pois são parte do código executável, mas em contrapartida fazem o tamanho da aplicação aumentar. Imagens embarcadas também fazem a manutenção da aplicação ser mais complexa, pois temos que recompilar a cada vez que a imagem for alterada. A maneira de contornar este problema, é carregar as imagens em tempo de execução, fazendo um HTTPRequest ou simplesmente carregando um arquivo no servidor onde a aplicação está rodando. Estas imagens ficam independentes da aplicação, então quando as alteramos, não precisamos recompilar todo o sistema. Caso sejam utilizadas imagens no formato PNG ou GIF, podemos utilizar o canal alpha destas para criar fundos ou imagens com transparências, aumentando o grau de qualidade gráfica da aplicação. o Label Os Labels são linhas simples de texto, não são editáveis mas podem ser selecionados caso o desenvolvedor permita. Representam informações textuais que podem ser controladas por folhas de estilos CSS. Labels não possuem bordas ou fundo e não podem receber o foco da aplicação. o LinkButton [button] É um controle Button sem bordas e seu label é aceso (um efeito visual acende o botão) quando o usuário passa o foco da aplicação (com mouse ou teclado) sobre o componente. 65

66 o LinkBar O LinkBar é um conjunto de LinkButtons, dispostos horizontalmente ou verticalmente. Sua aplicação típica é de controlar outros elementos de interface como ViewStacks, ou para criar um conjunto independente de Links. o List É uma lista simples de elementos, na qual uma barra de rolagem pode ser inserida caso o número de itens seja maior do que o número que pode ser exibido neste componente dependendo de seu tamanho. O usuário pode fazer a seleção de um ou mais itens da lista, dependendo do valor da propriedade allowmultipleselection. o Menu [list] O controle Menu cria uma lista pop-up de elementos que podem ser selecionados um a cada vez, similarmente aos menus de aplicações em sistemas operacionais. Estas listas podem ter vários níveis de submenus quanto desejado. Depois de uma destas listas serem abertas, elas se mantém visíveis até que uma das seguintes ações ocorra: Uma chamada à função Menu.hide(); O usuário seleciona um item de menu O usuário clica fora do menu O usuário seleciona outro componente da aplicação. o MenuBar 66

67 A barra de menu é um conjunto de componentes Menu, disposta em uma barra horizontal, geralmente no topo da aplicação, com um botão para cada componente deste conjunto. o NumericStepper Este componente permite ao usuário fazer a seleção de um número dentre um conjunto enumerável, ou um intervalo de números. É composto de uma caixa de texto para informar o número selecionado, e botões para adicionar ou subtrair o número selecionado. o PopUpButton Os PopUpButtons são botões nos quais a ação a ser feita pode ser selecionada da mesma maneira como acontece em ComboBoxes. é composto de dois elementos, o botão em si e outro botão que exibe uma lista de ações. Após a seleção ser feita, a parte do componente que é o botão em si executa aquela o ProgressBar São barras de progresso que indicam o progresso de uma tarefa ao longo do tempo. Estas tarefas incluem consultas a banco de dados, carregamento dinâmico de imagens e arquivos em geral, etc. Elas podem ser classificadas em dois tipos: determinada ou indeterminada. No caso de a tarefa a ser cumprida tenha um tempo fixo para acontecer, usamos o tipo determinado, por exemplo em marcações temporais de um determinado acontecimento. Caso o tempo seja indeterminado, como por exemplo em carregamento de arquivos, onde o tempo depende da velocidade da transferência de dados, utilizamos a forma indeterminada. o RadioButton 67

68 RadioButtons são botões que funcionam como botões comuns, mas o label deste está fora do gráfico que o representa. Este componente é utilizado em conjunto com componentes do mesmo tipo e são enclausurados em grupos, utilizando o componente RadioButtonGroup, o qual faz com que apenas um de seus filhos possam ser selecionados de cada vez. Quando o usuário seleciona um destes botões de um mesmo grupo, os outros tem sua seleção automaticamente removida. o RadioButtonGroup Determina um conjunto de RadioButtons o RichTextEditor É um editor de textos no qual o usuário pode inserir conteúdo e mudar a formatação do texto. É composto de duas partes principais: uma caixa de textos (TextArea) onde o usuário pode digitar texto e um container contendo controles para o usuário especificar as características de formatação do texto inserido. o Spacer Spacer são elementos de disposição de componentes em um container pai, que auxiliam no layout do container. São elementos invisíveis, mas que fazem com que, por exemplo, os elementos fiquem sempre nas laterais do container, mesmo que o tamanho do mesmo seja alterado. o SWFLoader É um componente que permite o carregamento e exibição de animações ou aplicativos Flash/Flex. É um componente poderoso, pois quando carregamos uma aplicação dentro de outra, estamos utilizando conceitos de reusabilidade, já que podemos fazer a comunicação da aplicação base com a carregada. Apesar de este 68

69 componente não receber o foco da aplicação, seus elementos internos o recebem e a interação é completa. o TabBar É um conjunto de botões mutuamente exclusivos em sua seleção, representados de maneira a se parecerem com abas de um arquivo. Geralmente são utilizados em conjunto com ViewStacks, mas podemos utilizá-los como qualquer conjunto de botões que são mutuamente exclusivos (quando um é ativado, todos os outros são desativados). o Text O controle de texto é derivado do Label, mas pode conter mais de uma linha de conteúdo não editável. Este controle não suporta barras de rolagem, podemos utilizar tags HTML para a formatação do conteúdo e decidir se este será ou não selecionável. o TextArea TextArea é um componente composto de uma área de texto, uma borda e barras de rolagem opcionais. Também suporta tags HTML para a formatação do conteúdo. o TextInput Este controle é uma caixa de texto de apenas uma linha, na qual o usuário entra com dados arbitrários. Quando utilizado como filho de um componente Form, podemos utilizar validadores de dados, e também indicar se o campo é de preenchimento obrigatório ou opcional. Estes controles possuem 4 estados distintos: preenchido, selecionado, desligado e erro. Eles despacham eventos quando da 69

70 inserção de conteúdo e quando perdem o foco da aplicação, para ser feita a validação e controle de obrigatoriedade. Este componente é utilizado como subcomponente em vários outros componentes, como o RichTextEditor, NumericStepper, e Comboboxes. Quando associamos uma folha de estilos CSS à classe do componente, deve-se tomar precaução pois todos estes outros componentes pais serão afetados, a não ser que seja explicitamente indicado outro estilo. o TileList Este componente exibe um número de itens dispostos em células. Ele exibe uma barra de rolagens se isso se fizer necessário, vertical ou horizontal. o ToogleButtonBar Este componente é um conjunto de buttons no qual apenas um deles pode ser ativado por vez, e quando isto é feito, ou outros botões são colocados no estado normal. o ToolTip Tooltips são componentes de informação de auxílio ao usuário. Quando este move o mouse sobre um determinado componente gráfico, o ToolTip é exibido com texto informativo sobre aquele componente. Sua funcionalidade pode ser expandida de acordo com o projeto, inserindo novas funcionalidades. o Tree Este elemento possibilita a visualização de dados arranjados em uma estrutura de árvore, com galhos e folhas. Uma folha é um ponto final de uma árvore, que pode 70

71 conter inúmeras folhas. Um galho é um nodo intermediário que contém outros galhos ou folhas, ou pode estar vazio. o VideoDisplay Este componente permite a exibição de vídeos no formato.flv. Suporta download progressivo através de requisições http, ou streaming a partir de servidores Flash (Flash Media Server, da Adobe, ou o Red5, open-source). Aceita também streams de vídeos de câmeras, em tempo real. 3.2 Flash A palavra Flash pode ser usada tanto para nos referirmos ao hoje Adobe Flash Professional multimedia authoring program bem como ao Adobe Flash Player. O Adobe Flash Professional é um software utilizado para criação do conteúdo para o Adobe Engagement Platform. O Adobe Flash Player é o cliente universal, que instalado no navegador do usuário ou em versão stand-alone, proporciona, através de uma máquina virtual chamada AVM (ActionScript Virtual Machine) a exibição de conteúdo Flash. Este cliente suporta gráficos vetoriais, bitmaps (mapas de bits) e streaming de áudio e vídeo entre outros formatos de mídia. Resumindo,o Adobe Flash Professional é um ambiente integrado de desenvolvimento (IDE) e o Adobe Flash Player é uma máquina virtual utilizada para executar os programas gerados pelo primeiro. O Flash surgiu em 1996 a partir de aprimoramentos de softwares de CAD (Computer-Aided Design) como o IntelliDraw. O grande diferencial do Intellidraw sobre os softwares concorrentes na época, como o Adobe Illustrator e o Aldus Freehand, era que este permitia, alem de desenhar usando métodos tradicionais de CAD, a construção lógica 71

72 de elementos de desenho, como por exemplo, uma linha que sempre conecta dois objetos, mesmo que estes sejam modificados, ou um gráfico de barras que mudaria de tamanho de acordo com um número digitado em uma caixa de texto pelo usuário. "If you ever think Flash is difficult to use, you should try drawing with a joystick on an Apple II before the concept of undo was invented. That will test your patience." Jonathan Gay, Creator of Flash (GAY, 2008) Em 1995 a FutureWave (empresa criadora da primeira versão do Flash) começou a receber muitas sugestões de usuários para transformar o SmartSketch (sucessor do Intellidraw) em um software de animação gráfica. A idéia foi muito bem aceita, mas um problema surgia nesta ação. A única maneira de se publicar animações na época era em formatos de vídeo, como VHS ou Betamax, ou então em CD-ROMs com hipermídia e o mercado de ferramentas de animação era muito pequeno. Nesta mesma época estava surgindo a world wide web como a conhecemos hoje, e a possibilidade de publicar animações na internet abriu as portas para a FutureWave software, que começou então a projetar um web-player em Java que reproduziria as animações feitas no SmartSketch, mas esta era lenta e instável. (Flash Magazine > News, 2000). Logo depois, a Netscape lançou seu pacote de API s (Application Programming Interface) para a produção de plug-ins, o que fez com que as animações do SmartSketch pudessem ser reproduzidas no próprio navegador no computador do usuário, o que aumentou muito a performance do player. Em dezembro de 1996, a Macromedia adquire a FutureWave Software e o FutureSplash Animator se torna a versão 1.0 do Macromedia Flash. Durante o tempo em que o Flash permaneceu sob a bandeira da Macromedia, muitas modificações e aprimoramentos foram feitos. A seguir, a Figura 3.5 mostra uma tela da primeira versão do FutureSplash Animator. 72

73 Figura 3.5 Tela do Future Splash Animator Em meados de 2005 a Macromedia é adquirida pela Adobe, e então é criada a Adobe Engagement Platform, nome da suíte de aplicativos criada pela Adobe resultante da junção com a Macromedia. Esta linha de produtos é organizada em uma arquitetura de cinco partes: O cliente universal, ou runtime client (Reader, Flash Player), componentes server-side (Flash Media Center), frameworks de desenvolvimento de aplicações (Cairngorm), ferramentas de desenvolvimento (Dreamweaver, Flash, Flex), e o Adobe Solutions Network (treinamento e suporte). Desde a sua introdução em 1996, a tecnologia Flash se tornou um padrão na adição de animações e conteúdo interativo em páginas da internet em um tempo que as páginas eram construídas basicamente com HTML e um uma parcela muito reduzida utilizava métodos de criação dinâmica de páginas. A partir de então muitos outros softwares, sistemas complexos e dispositivos de hardware são capazes de exibir conteúdo Flash e até mesmo criar conteúdo Flash. Geralmente Flash é utilizado para criar animações, pequenos anúncios em websites, vários tipos de componentes de interface para web, para adicionar vídeo em páginas da internet e mais recentemente para criar a aplicação web como um todo. 73

74 As versões mais recentes do Flash são : Macromedia Flash Professional 8 (13 de Setembro de 2005) Ultimo Flash lançado sob bandeira da Macromedia, esta versão suporta ActionScript 2.0 (não orientado a objetos). Seu maior feito foi ter incluído controles de vídeo avançados que fizeram surgir uma verdadeira onda de vídeos na internet publicados na plataforma Flash. Esta versão era focada em expressividade, qualidade, vídeo além de autoração para dispositivos móveis. Novos recursos incluíam Filtros de bitmaps, blend modes, controle de suavidade para animações, estilos de pincel avançados, desenho baseado em objetos, cache de bitmaps em tempo de execução, antialiasing avançado para texto, um novo codec de vídeo mais eficiente (On2 VP6), suporte para transparência (alpha channel) em vídeo, um codificador de vídeo standalone, outras funcionalidades relacionadas a vídeo, e um emulador interativo de dispositivos móveis. Adobe Flash CS3 Professional (versão 9) (16 de Abril de 2007) Esta versão é a primeira lançada após a compra da Macromedia pela Adobe. Ela suporta o ActionScript 3.0 (Orientado a objetos), permite a conversão de animações feitas nas timelines em código, aumenta a integração com outros produtos da Adobe como Photoshop ou Illustrator, aumenta a capacidade de qualidade em desenhos vetoriais, e se torna mais parecido em termos de interface e organização com os softwares da Adobe. 74

75 4 A PROPOSTA A fim de aperfeiçoar a tarefa de mapeamento de um modelo abstrato de interface OOHDM para implementação da interface concreta em um sistema baseado em Flex, este trabalho sugere extensões às etapas de Projeto de Interface Abstrata e Implementação do OOHDM A Figura 4.1 nos mostra as etapas do OOHDM e seus passos internos. Os artefatos gerados que são trocados entre as etapas estão representados acompanhando as transições entre as etapas. A Figura 4.2 mostra o método OOHDM com as extensões propostas no presente trabalho. Análise de Requisitos 1. Criação dos casos de uso UIDs 2. Especificação dos UIDs UIDs UIDs Modelagem Conceitual 1. Modelagem das classes conceituais classes conceituais Projeto de Navegação classes e contextos navegacionais. 1. Modelagem das classes navegacionais 2. modelagem dos contextos navegacionais Projeto de Interface Abstrata 1. Especificação dos widgets abstratos ADVs classes e contextos navegacionais. 2. Especificação dos widgets concretos 3. Especificação de ADVs Implementação Figura 4.1 Esquema simplificado do processo do método OOHDM 75

76 UIDs Análise de Requisitos 1. Criação dos casos de uso 2. Especificação dos UIDs UIDs UIDs Modelagem Conceitual 1. Modelagem das classes conceituais classes conceituais Projeto de Navegação classes e contextos navegacionais. 1. Modelagem das classes navegacionais 2. modelagem dos contextos navegacionais Projeto de Interface Abstrata 1. Especificação dos widgets abstratos ADVs Flex classes e contextos navegacionais. 2. Especificação dos widgets concretos MXML 3. Especificação de ADVs para Flex Implementação 1. Criação da interface utilizando <mx:states> Figura 4.2 Esquema do processo OOHDM adaptado para criação de sistemas Flex. São propostas quatro extensões ao processo OOHDM. A primeira extensão faz parte do Projeto de interface Abstrata e sugere o mapeamento das primitivas de interação usuário-sistema extraídas dos UIDs e atributos das classes navegacionais para elementos da Ontologia de Widgets Abstratos. A segunda extensão consiste em um mapeamento das classes da Ontologia de Widgets Abstratos para um novo conjunto de widgets concretos, baseado em componentes de interface do Flex (componentes MXML), criando novos elementos na Ontologia de Widgets Concretos. Na terceira extensão, os ADVs são adaptados para acomodar a informação das Ontologias Abstrata e Concreta para prover uma descrição detalhada e pronta para o mapeamento em MXML. A quarta extensão é feita entre o Projeto de interface e a Implementação, mas principalmente na última e sugere a 76

77 definição dos estados de interface Flex (View States <mx:state>) de acordo com um conjunto de ADVs pré-determinados para modelarem estes estados. 4.1 Extensão 1 - Especificação dos widgets abstratos Esta extensão ao processo OOHDM utiliza uma proposta sugerida por Remáculo (2005) para mapear os atributos das classes navegacionais e entidades dos UIDs para os elementos da interface abstrata. Este mapeamento indica a qual classe da Ontologia de Widgets Abstratos cada elemento do UID pode ser relacionado. Desta maneira, é utilizado na construção da interface abstrata, na qual são identificados os atributos e métodos das classes navegacionais, e segundo suas origens nos UIDs, são mapeados para determinadas classes da Ontologia de Widgets Abstratos. Um atributo de uma classe navegacional que representa um item de dado exibido pelo sistema num determinado UID, por exemplo, pode ser mapeado para elementexhibitor ou simpleactivator dependendo de sua função. Caso no UID este elemento seja apenas uma exibição de conteúdo, o mapeamento deve ser feito para elementexhibitor, mas, se este elemento seja passível de ativação, como em um texto com âncora, ele deve ser mapeado para a classe simpleactivator. Com este mapeamento, obtém-se o primeiro conjunto de informações para o projeto da interface abstrata identificando que tipo de exibição terá cada atributo da classe navegacional. A Tabela 4.1 apresenta as regras de mapeamento, indicando a classe da Ontologia de Widgets Abstratos que cada elemento do UID está associado. 77

78 Tabela 4.1 Mapeamento de elementos dos UIDs para a Ontologia de Widgets Abstratos. (REMÁCULO, 2005, p. 39) UIDs Item de dado e Item de dado personalizado Estrutura Conjunto, Conjunto com conteúdo personalizado e Conjunto em disposição diferenciada Dado opcional Entrada do Usuário Entrada do Usuário Enumerada Widgets Abstratos ElementExhibitor ou SimpleActivator A estrutura toda pode ser mapeada para um ElementExhibitor ou SimpleActivator, assim como cada elemento da estrutura pode ser mapeado para um ElementExhibitor ou SimpleActivator. Neste caso, 1º deve-se mapear a Estrutura para um CompositeInterfaceElement, para que depois os elementos que compõem a Estrutura sejam mapeados para ElementExhibitor ou SimpleActivator. 1º passo: mapear o conjunto para um CompositeInterfaceElement. 2º passo: mapear cada elemento do conjunto para um ElementExhibitor ou SimpleActivator, conforme o objetivo do item de dado ou estrutura que compõem o conjunto. ElementExhibitor ou VariableCapturer. No caso de VariableCapturer, o elemento pode ser mapeado para: IndefiniteVariable, ContinuousGroup, DiscreetGroup, MultipleChoices ou SingleChoices. IndefiniteVariable SingleChoice, MultipleChoice Saída do Sistema Recebe o mapeamento descrito para os elementos dos UIDs, conforme o tipo de elemento que representa a Saída do Sistema (Item de dado, Item de dado personalizado, Estrutura, Conjunto, Conjunto com conteúdo personalizado, Conjunto em disposição diferenciada, Dado Opcional, Entrada do Usuário e Entrada do Usuário Enumerada). Texto Estado de Interação, Estado Inicial da Interação e Estados Alternativos da Interação. ElementExhibitor CompositeInterfaceElement. Caso o Estado de Interação seja um conjunto de CompositeInterfaceElement, o estado de interação será a associação dos CompositeInterfaceElements. 78

79 Sub-estados de um Estado de Interação. Transição com Seleção da Opção X e Transição com Seleção da Opção Restrita X.: Transição com Seleção de N Elementos Chamada de Outro UID, Chamada a partir de Outro UID, Transição com Condição Y, Pré-Condições, Pós- Condições e Notas Textuais. CompositeInterfaceElement SimpleActivator. No caso da opção precisar de outro elemento para que o estado de interação destino se torne o foco da interação, a mesma deve ser mapeada para MulipleChoice ou SingleChoice e atrelada a um SimpleActivator para que a transição entre Estados de Interação ocorra. Os conceitos que suportam a seleção de 1 ou mais elementos especificados nos UIDs são: ContinuousGroup*,DiscreetGroup*, MultipleChoices ou SingleChoices. Não há mapeamento para a ontologia de widgets abstratos. Durante o processo de pesquisa, principalmente quando da análise dos componentes MXML, detalhada na seção 4.2, foi identificada a necessidade de se descrever elementos de interface que fizessem seleção de intervalos em vez de apenas um único valor a partir de um intervalo de valores. Estendendo a classificação dos widgets abstratos da metodologia OOHDM, as classes da Ontologia de Widgets Abstratos ContinuousGroup e DiscreetGroup podem ter pares de seleção múltipla ContinuousGroupMultiple e DiscreetGroupMultiple, como descrito na Figura 4.3. O mapeamento para estes novos elementos se dá da mesma maneira que se realiza mapeamentos para as classes ContinuousGroup e DiscreetGroup. Recapitulando a descrição das classes da Ontologia de Widgets Abstratos que são subclasses da classe PredefinedVariable e descrevendo as duas novas classes: ContinousGroup: permite a seleção de um único valor de um intervalo infinito de valores; ContinousGroupMultiple: [nova] permite a seleção de um ou mais valores de um intervalo infinito de valores; 79

80 DiscreetGroup: permite a seleção de um único valor de um intervalo finito de valores; DiscreetGroupMultiple: [nova] permite a seleção de um ou mais valores 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. AbstractInterfaceElement SimpleActivator ElementExhibitor VariableCapturer CompositeInterfaceElement PredefinedVariable IndefiniteVariable ContinuousGroupMultiple ContinuousGroup DiscreetGroupMultiple DiscreetGroup MultipleChoices SingleChoice Figura Classes da Ontologia de Widgets Abstratos extendida Esta nova classificação permite ao usuário fazer a seleção de múltiplos valores a partir de um intervalo infinito (ContinuousGroupMultiple) ou finito (DiscreetGroupMultiple) de valores. Naturalmente, elementos concretos que serão mapeados a partir destas classes devem prover mais de um elemento de seleção, como é mostrado na Figura 4.4 a seguir: 80

81 Figura Exemplo de interface para seleção múltipla em um intervalo finito Considerando o UID da Figura 2.1 e o esquema de classes navegacionais da Figura 2.3, a Tabela 4.2 mostra um exemplo de definição de widgets abstratos. Tabela 4.2- Exemplo de definição de widgets abstratos Classe: Programa de Rádio Atributos origem nos UIDs Widgets Abstratos nome:string Item de dado ElementExhibitor data:string Item de dado ElementExhibitor tempo:string Item de dado ElementExhibitor Som:Audio nomedj:string Item de dado transição (escutar programa) Item de dado transição (ver DJ) SimpleActivator SimpleActivator idxmusicas Estrutura CompositeInterfaceElement Note que apesar de os atributos som e nomedj serem itens de dados assim como nome, data e tempo, estes foram mapeados para SimpleActivator em vez de ElementExhibitor, pois, a partir dos UIDs obtêm-se a informação de que estes elementos ativam uma ação, no caso do nomedj, o usuário é direcionado para o UID ver DJ e no caso do som, é executada a operação escutar programa. O elemento idxmusicas é um elemento composto pois está exibindo mais de um atributo de outra classe conceitual, 81

82 nome e artista de Musica, compondo uma estrutura no UID e sendo mapeado para CompositeInterfaceElement. 4.2 Extensão 2 - Especificação dos widgets concretos MXML Esta seção fará um estudo comparativo das premissas da Ontologia de Widgets Abstratos com os componentes de interface MXML, sugerindo uma nova Ontologia de Widgets Concretos específica. Os componentes MXML podem ser utilizados como conteúdo dos atributos mapsto, blockelement, ou compositiontag das classes Ontologia de Widgets Abstratos. Os componentes MXML são classificados em duas subclasses, os containers MXML e os controles MXML. Os containers MXML são elementos que podem ser utilizados como invólucros de componentes de interface, pois especificam o layout de uma interface gráfica com o usuário. Podemos mapear os compositeinterfaceelements para este tipo de componente. Por exemplo, uma interface pode conter 3 botões agrupados que estariam sendo considerados como um compositeinterfaceelement por serem os únicos elementos de um determinado estado do UID. Pode-se utilizar neste caso os containers para agrupar estes botões na interface da maneira desejada pelo desenvolvedor / criador de interfaces. Os containers Accordion, TabNavigator e ViewStack também podem ser aplicados como compositeinterfaceelements que fazem o papel de exibidores de conteúdo por demanda. Eles são compostos de outras composições e apenas uma dela é exibida por vez. Os controls MXML são um conjunto de elementos de interface perceptíveis e utilizáveis pelo usuário, como textos, imagens, botões, caixas de seleção de valores, radiobuttons, e assim por diante. Serão mapeados diretamente das classes da Ontologia 82

83 de Widgets Abstratos, fazendo com que uma interface abstrata modelada com estas classes possa ser traduzida em elementos MXML. Para cada controle MXML, foi realizada uma análise comparando a descrição deste componente com as classes da ontologia e identificado o mapeamento a ser feito. Os componentes de análise mais complexa são os que devem ser mapeados para a classe CompositeInterfaceElement, pois são componentes compostos de outros componentes (de qualquer classe, ex.: DataGrid; ou serem restringidos a elementos de uma única classe, ex.: ButtonBar). Este mapeamento, feito de maneira comparativa entre o funcionamento do componente e o comportamento que devem ter instâncias das classes da ontologia de widgets abstratos, pode também ser realizado para componentes customizados, isto é, componentes criados pelo desenvolvedor. Na grande maioria das vezes, estes novos componentes serão mapeados da classe CompositeInterfaceElement, por conter mais de um elemento em sua composição, mas, o desenvolvedor deve fazer esta análise para cada componente criado, para poder utilizá-lo na descrição dos ADVs estendidos. Suponha que o desenvolvedor crie um novo componente de seleção de valores, com base em um conceito de usabilidade totalmente novo, mas que apenas uma das opções será selecionada por vez pelo usuário. Este componente deve ser mapeado para a classe SingleChoice, fazendo com que possa ser utilizado na descrição de sistemas futuros que utilizem este componente. Sendo assim, a Ontologia de Widgets Concretos proposta nesta seção deve ser sempre atualizada pelo desenvolvedor que a utiliza com seus novos componentes. A seguir é demonstrada a análise, que foi feita relacionando cada componente do Flex apresentado na seção , a uma determinada classe da Ontologia de Widgets Abstratos e depois os organizando de acordo com estas classes. Todos os componentes abaixo devem ser representados na nova ontologia de widgets concretos precedidos do 83

84 sufixo mx:, indicando que fazem parte do pacote do núcleo ActionScript 3.0 do Flex. No caso de um componente customizado, deve-se incluí-lo na ontologia utilizando o sufixo correspondente ao pacote do desenvolvedor (ex.: novoscompos:itemlistamusicas). A) AbstractInterfaceElement observações: Os elementos devem ser mapeados para subclasses desta classe. B) SimpleActivator: observações: Eventos externos de mouse ou teclado. componentes mapeados: B1) mx:button Tipo de ativador mais comum. Deve ser mapeado para esta classe a não ser que se queira utilizá-lo como seletor de opções similarmente aos Radiobuttons. Neste caso a propriedade toggle deve ser alterada para true. B2) mx:linkbutton Tem as mesmas características do Button mas é um componente que se assemelha com Links HTML. Dever ser mapeado para esta classe caso se queira uma interface visual menos carregada que a do Button, pois não possui bordas. C) ElementExhibitor: observações: Exibição de conteúdo visual componentes: C1) mx:image 84

85 Mapeamos os ElementExhibitors para mx:image quando queremos exibir imagens JPG, GIF e PNG, que podem ser carregadas dinamicamente ou estar embarcadas no executável. Todos os atributos das classes navegacionais que tenham seu domínio em imagens ou figuras serão mapeados para esta classe. C2) mx:label Dever ser mapeado para esta classe quando o conteúdo do ElementExhibitor é um texto de uma linha conhecido de antemão, por exibir apenas uma linha de texto não editável. Geralmente é utilizado como rótulo ou título de outro elemento de interface, mas pode exibir também conteúdo dinâmico. C3) mx:progressbar Deve ser mapeado para esta classe elementos que façam o controle de progresso de tarefas. Como sugestão, pode ser utilizado para fazer com que o progresso de um determinado processo de interações entre o usuário e o sistema seja medido em relação às etapas deste processo. A cada etapa cumprida, a barra de progresso avança. Apesar desta sugestão, o componente mx:progressbar normalmente é utilizado para exibir o carregamento da aplicação ou de arquivos carregados dinamicamente no decorrer da navegação, sendo que, desta maneira, não há mapeamento a partir das classes abstratas. C4) mx:text Exibe múltiplas linhas de texto não editável. Análise análoga ao mx:label. C5) mx:tooptip Este componente é utilizado associado com outro componente. Ele exibe um texto popup quando o usuário passa o mouse sobre o componente pai. 85

86 Devem ser mapeados para esta classe elementos que sejam textos alternativos exibidos sob demanda, C6) mx:videodisplay Devem ser mapeados para este componente os elementos da classe ElementExhibitor são do domínio Video. Exibe vídeo no formato [.FLV]. Suporta download progressivo via http e streaming, de arquivos e de câmeras de vídeo. É um elemento que não tem controles de reprodução de vídeo, como play e pause, que devem ser implementados separadamente, mapeados a partir de SimpleActivators. D) IndefiniteVariable: observações: Captura de dados do teclado. componentes mapeados: D1) mx:textarea Para elementos de entrada de dados do usuário no formato de texto sejam eles opcionais ou não e que tenham múltiplas linhas, o mapeamento dever ser feito para este componente D2) mx:textinput Similar ao TextArea mas com apenas uma única linha de texto. 86

87 E) ContinuousGroupMultiple: observações: seleção de um único valor de um conjunto infinito de valores. Para componentes proverem valores infinitos, os valores das propriedades maximum e minimum devem ser alterados conforme o usuário troca o valor escolhido, pois a maioria dos componentes faz a escolha do valor visualmente. componentes mapeados: E1) mx:hslider / VSlider Como é possível instanciar mais de um handle neste componente, podemos determinar um intervalo continuo de valores se forem declarados uma dupla de handles para representarem os valores inicial e final. Para o domínio se tornar um conjunto infinito de valores, os valores de máximo e mínimo do componente devem ser alterados quando o usuário usa os handles. F) ContinuousGroup: observações: seleção de um único valor de um conjunto infinito de valores. Para componentes proverem valores infinitos, os valores das propriedades maximum e minimum devem ser alterados conforme o usuário troca o valor escolhido, pois a maioria dos componentes faz a escolha do valor visualmente. F1) mx:hslider / VSlider Análogo à análise E1, mas com apenas um único handle de seleção. F2) mx:numericstepper Seleção de valores numéricos. 87

88 G) DiscreetGroupMultiple: observações: Seletor de discretos, valores enumeráveis. componentes mapeados: G1) mx:hslider / mx:vslider Se for provido ao usuário uma maneira de inserir duplas de handles à linha de seleção, podemos extrair vários intervalos discretos deste componente. H) DiscreetGroup: observações: Seletor de discretos, valores enumeráveis. componentes mapeados: H1) mx:hslider / mx:vslider Se for provido ao usuário uma maneira de inserir duplas de handles à linha de seleção, podemos extrair vários intervalos discretos deste componente. H2) mx:numericstepper Seleção de valores numéricos. I) MultipleChoices: observações: Seletor de conjunto de valores, valores enumeráveis. componentes mapeados: I1) mx:hslider / VSlider 88

89 Se for provido ao usuário uma maneira de inserir handles à linha de seleção, podemos extrair vários valores discretos deste componente. I2) mx:datechooser Seletor de datas em formato de calendário, este componente permite a seleção de múltiplos dias do mês não adjacentes. I3) mx:checkbox Caixa de seleção liga/desliga. J) SingleChoice: observações: Seletor de um único valor, valores enumeráveis. componentes mapeados: J1) mx:hslider / VSlider Caso seja utilizado apenas um handle neste componente. J2) mx:datechooser Calendário com seleção de apenas uma data. J3) mx:combobox Lista retrátil com apenas uma seleção dentre um conjunto discreto de valores. J4) mx:datefield Campo de texto com um botão para exibição de um calendário para seleção de uma única data. 89

90 J5) mx:radiobutton Conjunto de botões liga/desliga no qual apenas um pode estar ligado por vez. K) CompositeInterfaceElement: observações: Elemento composto. componentes mapeados: K1) mx:buttonbar Composição apenas de elementos da classe Button. Deve ser utilizado quando existe um compositeinterfaceelement composto apenas de elementos da classe abstrata SimpleActivator. (ver LinkBar) K2) mx:datagrid Lista de Elementos organizados em linhas e colunas. Seus elementos internos podem ser construídos a partir de qualquer outro componente, o que o torna instância da classe compositeinterfaceelement. K3) mx:horizontallist Lista de Elementos organizados em uma única linha. Seus elementos internos podem ser construídos a partir de qualquer outro componente, o que o torna instância da classe compositeinterfaceelement. K4) mx:linkbar Composição apenas de elementos da classe LinkButton. Deve ser utilizado quando existe um compositeinterfaceelement composto apenas de elementos da classe abstrata SimpleActivator. (ver ButtonBar) 90

91 K5) mx:list Lista de Elementos organizados em uma única coluna. Seus elementos internos podem ser construídos a partir de qualquer outro componente, o que o torna instância da classe compositeinterfaceelement. K6) mx:menu Composição de SimpleActivators, MultipleChoices e SingleChoice, um menu pode conter elementos dos tipos normal, check e radio organizados em grupos em suas folhas internas. K7) mx:menubar Composição de elementos da classe Menu que e um elemento da classe ButtonBar que faz o controle de exibição dos menus. K8) mx:popupbutton Por ser um elemento de ativação simples, mas com escolha múltipla da sua função, este componente pode ser considerado como um elemento composto de vários SimpleActivators. K9) mx:radiobuttongroup Composição de elementos da classe RadioButton. Deve ser utilizado quando existe um compositeinterfaceelement composto apenas de elementos da classe abstrata SingleChoices. K10) mx:swfloader Componente que carrega outras aplicações Flex. K11) mx:tabbar 91

92 É um componente ButtonBar geralmente associado com elementos de navegação como viewstacks. O componente TabNavigator é uma associação de um TabBar com vários viewstacks, mas com esta classe podemos criar mais de uma TabBar para um mesmo controle de navegação. K12) mx:tilelist Lista de Elementos dispostos em mosaico. Seus elementos internos podem ser construídos a partir de qualquer outro componente, o que o torna instância da classe compositeinterfaceelement. K13) mx:togglebuttonbar Composição apenas de elementos da classe Button com a propriedade toggle=true. Deve ser utilizado quando existe um compositeinterfaceelement composto apenas de elementos da classe abstrata SingleChoice. K14) mx:tree Lista de Elementos dispostos em estrutura hierárquica em árvore, como em um gerenciador de arquivos. É composto de composições ícone-texto, que podem ser galhos ou folhas da árvore. - ~ - Com esta análise completa, podemos definir as regras consistência de mapeamento das classes de widgets abstratos para os componentes MXML que comporão a nova Ontologia de Widgets Concretos. A listagem completa das regras de consistência se encontra nos anexos. A Figura 4.5 nos mostra as classes da ontologia de widgets abstratos com os componentes MXML relacionados. 92

93 AbstractInterfaceElement SimpleActivator ElementExhibitor VariableCapturer CompositeInterfaceElement Button LinkButton Image Label Text VideoDisplay ToolTip ProgressBar AdvancedDataGrid ButtonBar DataGrid HorizontalList LinkBar List Menu MenuBar IndefiniteVariable TextArea TextInput PredefinedVariable PopUpButton PopUpMenuButton RadioButtonGroup SWFLoader TabBar TileList ToggleButtonBar ContinuousGroupMultiple ContinuousGroup DiscreetGroupMultiple DiscreetGroup MultipleChoices SingleChoice HSlider/VSlider NumericStepper DateChooser CheckBox DateField ComboBox RadioButton ColorPicker Figura Sobreposição das classes de widgets abstratos Com esta análise realizada, temos condições de agora em um determinado projeto estender a tabela de definição de widgets abstratos (conforme o exemplo da Tabela 4.2) incluindo os widgets concretos MXML e provendo condições para a aplicação da Extensão 3 proposta neste trabalho. A Tabela 4.3 de definição de widgets concretos MXML é determinada conforme exemplo da Tabela

94 Tabela Definição de widgets concretos MXML a partir dos widgets abstratos Classe: Programa de Rádio Atributos origem nos UIDs Widgets Abstratos Widgets Concretos nome:string Item de dado ElementExhibitor mx:label data:string Item de dado ElementExhibitor mx:label tempo:string Item de dado ElementExhibitor mx:label Som:Audio Item de dado SimpleActivator mx:button transição(escutar programa) nomedj:string Item de dado transição (ver DJ) SimpleActivator mx:linkbutton idxmusicas Estrutura CompositeInterface Element mx:vbox 4.3 Extensão 3 - Especificação de ADVs para Flex Para realizar a construção dos ADVs incluindo o resultado da aplicação dos mapeamentos anteriores, este trabalho apresenta uma simbologia para a representação dos widgets nos ADVs. Cada ADV, ADV aninhado ou atributo é acompanhado de um símbolo que corresponde à classe da ontologia de widgets abstratos e do nome do widget concreto ao qual foi mapeado. A Figura 4.6 nos mostra a legenda correspondente às classes abstratas e a Figura 4.7 é um exemplo da notação estendida de um ADV, o ADV Flex : 94

95 A AbstractInteface CompositeInterfaceElement SimpleActivator ElementExibitor? {N} {1} [N] [1] N 1 IndefiniteVariable ContinuousGroupMultiple ContinuousGroup DiscreetGroup Multiple DiscreetGroup MultipleChoices SingleChoice Figura 4.6 Legenda da representação da classe de widgets abstratos nos ADVs ADV mx:linkbutton Figura Exemplo Estrutura do cabeçalho dos ADV Flex Com a reunião das informações geradas a partir dos diagramas de classes e contextos navegacionais e da aplicação das extensões 1 e 2 propostas neste trabalho, ADVs são gerados para cada nodo e atributo do esquema de classes navegacionais e para cada índice e contexto do diagrama de contextos navegacionais. Os ADVs que representam os nodos (classes) navegacionais serão chamados de ADVs Primários, ou ADVs Base. Os ADVs relacionados contextos das classes navegacionais serão chamados de ADVs Secundários. Os ADVs relacionados a atributos serão considerados os ADVs opcionais. Os Índices do diagrama de contextos navegacionais devem ser descritos por ADVs Especiais, que farão parte do contexto da aplicação e permitirão a navegação para os objetos navegacionais. Esta hierarquia foi criada para acomodar os ADVs em view states no 95

96 momento da implementação do sistema, como explicado na seção A Figura 4.8 exibe um esquema de como devem ser mapeados as entidades do projeto navegacional. esquema de classes navegacionais esquema de contextos navegacionais classe esquema de classes emcontexto índice contexto índice contexto índice contexto Projeto de Navegação Projeto de Interface Abstrata ADVs Especiais ADVs Primários ADVs Secundários ADVs Opcionais ADVs Opcionais ADVs Opcionais Figura 4.8- Mapeamento de entidades navegacionais para ADVs O ADVs Primários e Secundários são mapeados exclusivamente para a classe CompositeInterfaceElement enquanto que seus ADVs internos são mapeados para qualquer classe que pode ser instanciada da Ontologia de Widgets Abstratos. conforme a Como exemplo, o ADV da Figura 2.8 pode ser descrito de acordo com a extensão 96

97 Figura 4.9.a. O mapeamento abstrato é representado pelo símbolo no campo abaixo do nome do ADV e o mapeamento concreto pelo nome do componente MXML ao lado. No caso, o ADV Programa de Rádio foi mapeado a partir da classe navegacional Programa de Rádio, portanto deve ser do tipo compositeinterfaceelement e é considerado um ADV Primário. Os atributos nome, data e tempo foram mapeados para a classe abstrata ElementExhibitor e então para o componente mx:label compondo ADVs opcionais assim como o restante dos ADVs internos. A Figura 4.9.b mostra o ADV secundário correspondente ao contexto Programa de Rádio por Data, com um calendário para seleção de outro programa neste contexto e botões de avanço e retrocesso dentro do contexto. ADV Programa de Rádio C mx:panel nome mx:label mx:button ADV Programa de Rádio por Data C mx:panel data mx:label tempo mx:label mx:linkbutton nome mx:label data mx:label tempo mx:label mx:button data 1 mx:datechooser ADV musicas nomedj C mx:linkbutton isrepeated nome mx:label ADV musicas C mx:vbox artista mx:label mx:linkbutton mx:linkbutton (a) (b) Figura ADV Programa de rádio 97

98 4.4 Extensão 4 - Especificação de view states do Flex Como os view states são organizados de maneira hierárquica, a organização dos ADVs em Primários, secundários e opcionais nos permite um mapeamento direto para os view states do Flex. A criação de uma interface em um ambiente de programação ActionScript é realizada através de uma estrutura de dados que representa uma lista de objetos perceptíveis, chamada de DisplayList. Se algum objeto está presente na interface de exibição ao usuário, então ele está registrado nesta lista, de forma que um objeto instanciado do sistema que não foi adicionado à DisplayList, ou que foi retirado da mesma, é um objeto que apenas não tem interface visual sendo exibida, mas continua ativo. (MOOCK, 2007) Fazendo um paralelo com o OOHDM, no método OOHDM existe a variável contextoperceptivo, uma variável de contexto que tem a mesma função da DisplayList: Uma variável reservada, contextoperceptivo, é usada para indicar modificações no espaço perceptivo (o conjunto de objetos perceptíveis em dado momento). Quando se deseja tornar um objeto perceptível, ele é acrescentado ao contextoperceptivo. Os elementos retirados deste contexto deixam de ser percebidos. (SCHWABE ROSSI, 1996). Uma aplicação Flex pode utilizar destes conceitos fazendo inserções e retiradas de objetos da DisplayList e também alterações nas propriedades e estilos destes objetos de acordo com alterações de estados de interface. Podemos implementar os mx:statede acordo com os ADVs. A partir de um ADV primário, é implementado o base state do componente que representa esta classe. Os ADVs secundários, são implementados como 98

99 estados filhos do base state. Os estados secundários podem também ter mais de um estado de interface, que continuam sendo considerados secundários. Os mx:state compreendem não só estados de interface relativos a uma aplicação ou ADV, mas também a de um simples componente ou estado de um ADV, extraídos dos ADVs opcionais. No exemplo de modelagem, o atributo som foi mapeado para um elemento mx:button, pois será um botão que aciona a exibição do programa de rádio determinado. Suponha que o botão possa estar desabilitado quando é exatamente o progrma de rádio que está sendo pesquisado o que está sendo exibido, então, este botão será um componente com dois estados, um ativo e um inativo. No estado ativo, o botão seria da cor verde com o texto OUVIR, e no inativo da cor vermelha com o texto NO AR. Este componente poderia ser implementado utilizando mx:state para definir os diferentes estados da interface. Seu view state poderia ser definido pela aplicação, assim, se este botão estiver presente em mais de um view state da aplicação, seu estado será mantido quando da troca de view state ocorrer. Este modelo de implementação permite a descrição de elementos da interface, desde os mais primitivos aos mais complexos, provendo recursos para especificação de cada um dos elementos de maneira independente, relacionando os eventos que ocorrem entre um e outro. Os aspectos dinâmicos da interface lidam tanto com transformações de interface dentro de um ADV como com transformações de interface envolvendo navegação. Em ambos os casos, a natureza orientada a eventos dos ADVs e o poder expressivo de seu modelo de transição de estados permite a implementação destas transformações em um estilo simples, de baixo para cima. Começando-se com ADVs de mais baixo nível, definimos scripts para cada evento significativo com que o objeto pode lidar. (ROSSI, 1996). 99

100 Esta afirmação é válida também para a implementação dos mx:states, que podem ser realizados em vários níveis desde cada objeto até a aplicação como um todo. Aprimorando o exemplo de modelagem de aplicação, será apresentado agora parte do diagrama de classes navegacionais, o diagrama de ADVs, e o código MXML correspondente que fazem parte do exemplo de como realizar o mapeamento para os view states. ADV Programa de Rádio C mx:panel nome mx:label data mx:label tempo mx:label mx:linkbutton mx:button ADV musicas C mx:tilelist isrepeated nome mx:label artista mx:label ADV Primário ADVs Secundários ADV Programa de Rádio por Data C mx:panel ADV Programa de Rádio por DJ C mx:panel ADV Programa de Rádio por Nome C mx:panel data 1 mx:datechooser fotodj mx:datechooser mx:linkbutton mx:linkbutton anterior próximo anterior mx:linkbutton ADV idxprogramasdj C mx:tilelist Figura Diagrama de ADVs A partir deste diagrama de ADVs, a interface pode começar a ser construída. Implementa-se primeiro o ADV Primário correspondente ao nodo navegacional Programa de 100

101 Rádio, de maneira que ele seja o base state do componente MXML escolhido para representa-lo. No exemplo foi escolhido o componente mx:panel portanto a definição crua deste componente em MXML que está declarado no arquivo UIProgramaRadio.mxml é: 1 <mx:panel xmlns:mx=" 2 </mx:panel> Cada elemento interno do ADV Programa de Rádio é implementado no base state de acordo com o mapeamento, resultando em: 1 <mx:panel xmlns:mx=" 2 3 <mx:label id="nome_lbl" text="nome" /> 4 <mx:label id="data_lbl" text="data"/> 5 <mx:label id="tempo_lbl" text="tempo"/> 6 <mx:linkbutton id="dj_lbtn" label="dj"/> 7 <mx:button id="som_btn" label="som"/> 8 <mx:tilelist id="musicas_tl" itemrenderer="itemlistamusicas"/> 9 10 <mx:panel> Em seguida podemos definir os outros view states mapeando cada ADV Secundário para um mx:state como no exemplo a seguir: 1 <mx:panel xmlns:mx=" 2 3 <!-- Declaração da variável states, 4 que indica que este mx:panel terá mais de um estado --> 5 <mx:states> 6 7 <!--Declaração do primeiro estado: Programa de Rádio por Data--> 8 <mx:state name="pordata"> 9 <mx:addchild position="lastchild"> 10 <mx:datechooser id="calendario"/> 11 </mx:addchild> 12 <mx:addchild position="lastchild"> 13 <mx:linkbutton label="anterior"/> 14 </mx:addchild> 15 <mx:addchild position="lastchild"> 16 <mx:linkbutton label="próximo"/> 17 </mx:addchild> 18 </mx:state> <!--Declaração do segundo estado: Programa de Rádio por Nome--> 21 <mx:state name="pornome"> 22 <mx:addchild position="lastchild"> 23 <mx:linkbutton label="anterior"/> 24 </mx:addchild> 25 <mx:addchild position="lastchild"> 101

102 26 <mx:linkbutton label="próximo"/> 27 </mx:addchild> <!--Declaração do terceiro estado: Programa de Rádio por DJ--> 30 <mx:state name="pordj"> 31 <mx:addchild position="lastchild"> 32 <mx:image/> 33 </mx:addchild> 34 <mx:addchild position="lastchild"> 35 <mx:linkbutton label="anterior"/> 36 </mx:addchild> 37 <mx:addchild position="lastchild"> 38 <mx:linkbutton label="próximo"/> 39 </mx:addchild> 40 </mx:state> 41 </mx:states> <!--Declaração do base state : Programa de Rádio--> <mx:label id="nome_lbl" text="nome" /> 46 <mx:label id="data_lbl" text="data"/> 47 <mx:label id="tempo_lbl" text="tempo"/> 48 <mx:linkbutton id="dj_lbtn" label="dj"/> 49 <mx:button id="som_btn" label="som"/> <mx:tilelist id="musicas_tl" itemrenderer="itemlistamusicas"/> </mx:panel> Com a interface definida são determinados os valores dos atributos dos componentes baseados nos atributos dos objetos navegacionais os quais devem ser implementados naturalmente como classes ActionScript. São também atribuídos os eventos aos componentes, por exemplo determinando o método a ser chamado caso o usuário aperte o botão do mouse sobre o componente. A troca de estado é feita através da mudança da variável pública currentstate:string e deve ser realizada antes que se referencie os objetos adicionados a displaylist. A seguir são sugeridas algumas dicas e de modelagem de ADVs e uso do MXML 1. Alguns dos componentes são classificados como navegadores, pois realizam a tarefa de exibir conteúdo sob demanda como comentado ao final da seção São eles: Accordion TabNavigator 102

103 ViewStacks Em uma composição de ADVs agrupados em XOR, ou seja, que representam estados exclusivos da interface e não são percebidos simultaneamente pelo usuário, o ADV que representa a classe compositeinterfaceelement que é pai destes ADVs em XOR pode ser mapeada para os componentes acima. Como exemplo, O ADV Programa de rádio do contexto Programa de Rádio por DJ pode conter além do ADV Musicas que é uma lista de músicas que fazem parte daquele programa de rádio, uma lista de outros programas daquele determinado DJ que criou o programa que está sendo exibido. Estes dois ADVs, o ADV Musicas e o ADV Programas do DJ podem ser ADVs que compõe um ADV pai chamado de ADV Informações que é mapeado para um dos componentes sugeridos, em vez de se criar view states para cada situação (um mostrando as músicas e outro os programas do DJ). 2. A maioria dos componentes MXML (todos que sejam instâncias da classe mx:uicomponent) tem as propriedades visible e enabled, podendo ser estas utilizadas em vez de se criar view states para o determinado componente. Desta maneira, podemos fazer o controle de visibilidade do componente ou da capacidade de ativação pelo usuário sem que haja a necessidade de trocar de view state, sendo que sua criação deve se reavaliada dependendo da complexidade da alteração da interface. 3. Elementos que são do tipo compositeinterfaceelement que tem a propriedade isrepeated = verdadeiro são elementos que repetem um deteminado conjunto de dados de acordo com uma regra de exibição de elementos. Eles podem ser mapeados para os componentes que representam listas de itens. Estes controles permitem ao usuário da aplicação rolar a lista de itens e selecionar um ou mais itens desta lista. Todos os componentes de lista do Flex são especializaçõoes da 103

104 classe mx:listbase, incluindo mx:datagrid, mx:horizontallist, mx:list, mx:menu, mx:tilelist, e mx:tree. No exemplo do Programa de Rádio, a lista de músicas pode ser uma lista ordinária com linhas e colunas, ou pode ter um layout totalmente diferente, de acordo com a linguagem do site ou sistema que está sendo implementado. Os componentes do tipo lista do Flex utilizam uma classe propriedade chamada itemrenderer que aponta para o componente que fará a composição visual do elemento da lista. Este componente será o valor da propriedade compositiontag da ontologia de widgets abstratos 4. As classes mx:alert e mx:popupmanager são classes que permitem a exibição de janelas independentes. O primeiro é uma janela modal geralmente utilizada para exibir mensagens ao usuário e obter confirmações do mesmo. O segundo pode carregar em uma janela separada qualquer aplicação ou componente Flex. A definição original dos ADVs considera a modelagem de interfaces do tipo pop-up, então, quando forem descritas interfaces deste tipo, podemos mapear o ADV para estas classes. 5. As transições MXML são eventos relacionados a efeitos de mudanças de propriedades, como dimensões, canal alpha, efeitos visuais e visibilidade. As trasições são indicadas para cada objeto e na mudança de um view state para outro são consideradas, realizando os passos indicados em ordem. Por exemplo, podemos fazer uma mudança de view state na qual um componente sai da tela com uma animação para a esquerda, e outro aparece esmaecendo em seguida. As transições podem ser indicadas nos diagramas de ADVs entre um estado e outro de um determinado ADV, ou entre ADVs secundários, quando há troca de contexto navegacional. 104

105 5 Modelagem de Aplicação OOHDM Flex A aplicação de exemplo utilizada neste trabalho é um conjunto de pequenas aplicações desenvolvidas para um artista gráfico. Este artista é produtor de desenhos que são estampados em camisetas, e o sistema é uma loja na qual o usuário pode montar sua própria camiseta de acordo com modelos, estampas e cores diferentes. Juntamente com esta loja de camisetas, existe uma loja de produtos comuns (tradicional), que não necessitam de personalização com a camiseta. Também há uma rádio virtual, na qual acontecem programas ao vivo semanalmente, que será automaticamente exibido quando o usuário adentra no sistema. Além da rádio ao vivo, o usuário tem a opção de fazer uma pesquisa nos programas de rádio que foram exibidos anteriormente, obtendo informações sobre o programa de rádio e o DJ que criou este programa. Na primeira iteração, foi extraído o conjunto geral de informações do domínio, procurando atingir todos os pontos do sistema. Foram conceitualizados a maioria dos requisitos, porém a partir da etapa de projeto navegacional, apenas os objetos relacionados à Rádio on-line foram contempladas. Na segunda iteração foi aprimorado o modelo relativo à Rádio on-line e modelada a loja comum. Esta base da loja será utilizada no sistema de camisetas pela herança da classe camisetapersonalizada em relação a produto. A terceira iteração é a sugestão de modelagem do sistema de montagem de camisetas. 105

106 ITERAÇÃO 1 ANALISE DE REQUISITOS O conjunto completo de casos de uso gerados nesta fase está no Anexo 8.1. Caso de Uso: Pesquisar a radio Atores: usuário, sistema Tipo: Descrição: O usuário escolhe pesquisar os programas de rádio da emissora. O sistema exibe uma lista de programas de rádio, exibindo o nome a data e o nome do DJ. O usuário pode escutar um dos programas, ou ver os detalhes de um dos programas. Se for escolhido ver os detalhes, o sistema exibe o programa de rádio, mostrando o nome, a data de exibição, o tempo total do programa, o nome do DJ que criou este programa a lista de musicas que fazem parte deste programa, incluindo o nome da música e o nome do intérprete. O usuário pode escolher escutar o programa corrente ou ver os detalhes do DJ em questão. UID: Pesquisar a rádio <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) UID ver DJ <3> 106

107 MODELAGEM CONCEITUAL O diagrama de classes conceituais completo está no Anexo 8.2 Programa de Rádio perfil foto DJ 1 cria 0..* nome data tempo som PROJETO NAVEGACIONAL Programa de Rádio nome: String data: String tempo: String som: Audio NomeDJ: nomedj de DJ por Programa DJ nome: String perfil: Text foto: Imagem programas: nome, data de Programas por DJ Programa de Rádio DJ nome por nome por nome Radio data DJ por data por DJ 107

108 Programa de Rádio nome: String data: String tempo: String som: Audio NomeDJ: nomedj de DJ por Programa Programa de Rádio por DATA Programa de Rádio por DJ Programa de Rádio por NOME proximo: anchor(programa por DATA) anterior: anchor(programa por DATA) fotodj: foto de DJ 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) PROJETO DE INTERFACE ABSTRATA ADV Primário ADV Programa de Rádio ADV DJ C mx:panel C mx:panel nome mx:label mx:button nome mx:label foto mx:button data perfil mx:label mx:label tempo mx:label nomedj ADV idxprogramasdj C mx:linkbutton ADVs Secundários ADV Programa de Rádio por Data C mx:panel ADV Programa de Rádio por DJ C mx:panel ADV Programa de Rádio por Nome C mx:panel data 1 mx:datechooser fotodj mx:datechooser mx:linkbutton mx:linkbutton anterior próximo anterior mx:linkbutton ADV idxprogramasdj C mx:tilelist 108

109 ADVs Opcionais ADV idxprogramasdj C mx:tilelist isrepeated itemlistaprogramasdj C mx:canvas mx:label mx:label ADVs Especiais ADV índiceprogramanome C mx:tilelist isrepeated itemlistaprogramanome C mx:canvas mx:label Data mx:label nomedj mx:label ADV índiceprogramadata C mx:tilelist isrepeated itemlistaprogramadata C mx:canvas mx:label nome mx:label nomedj mx:label ADV índiceprogramadj C mx:tilelist isrepeated itemlistaprogramadj C mx:canvas mx:label Data mx:label nome mx:label classes navegacionais ProgramaRadio.as ProgramaRadioData.as ProgramaRadioNome.as ProgramaRadioDJ.as interfaces UIProgramaRadio.mxml UIIndicesRadio.mxml componentes IMPLEMENTAÇÃO. ListaProgramaPorDJ.mxml controladores CTRLProgramaRadio.as banco de dados DBProgramaRadio.php 109

110 6 Considerações Finais Neste trabalho o método OOHDM foi adaptado para ser utilizado na publicação de aplicações construídas no ambiente Flex. Quando da análise do método, a característica em comum mais evidente na relação entre OOHDM e Flex foi a criação de interfaces com o usuário, de maneira que se estabeleceu o paralelo entre o Projeto de Interfaces Abstratas do OOHDM e os view states do Flex. A utilização das extensões propostas neste trabalho faz com que o projeto da interface com o usuário seja feito de acordo com as capacidades e características dos componentes MXML. A partir das ontologias de widgets de interface foi possível criar elementos de projeto que funcionam como estruturas para realizar o mapeamento direto do projeto de interface abstrata para a implementação do sistema, extraindo dos ADVs estendidos para Flex informações para a construção do código MXML que compõe parte da estrutura de uma aplicação Flex. Perante a enorme quantidade de sistemas sendo construídos na atualidade, a utilização de um método para a construção de sistemas implementados para a internet se faz cada vez mais importante e presente. O Projeto de Navegação, a reusabilidade de componentes e objetos conceituais, a rastreabilidade entre os elementos abstratos de projeto e os concretos de implementação e a capacidade de gerir grandes quantidades de dados fazem do método OOHDM um expoente no campo dos estudos de sistemas hipermídia. Atualmente o Flex é considerado um dos ambientes mais completos para o desenvolvimento de aplicações hipermídia. Isso se deve pela sua integração com o Flash para publicação de conteúdo interativo com interfaces gráficas avançadas, por sua integração com serviços web através de server-side scripts e por ser publicado em uma máquina virtual (Flash Player) multi-plataforma. 110

111 A integração destas duas esferas - OOHDM e Flex- provê recursos para a construção de sistemas hipermídia os quais tem poderosos aliados para a exibição de conteúdo para o usuário, o Flex e o Flash. O Flex implementa a interface com o usuário, o controle da lógica do sistema, o acesso ao sistema de informações, as requisições HTTP; enquanto o Flash gera gráficos e componentes de programação inovadores no que diz respeito a usabilidade e apresentação visual. Com as descrições providas pelo método OOHDM, a construção de sistemas hipermídia em Flex se torna organizada e claramente descrita. Apesar deste trabalho ter seu enfoque em aplicações feitas em Flex, as extensões sugeridas (principalmente as extensões 1, 2 e 3) podem ser aplicadas em outras linguagens de programação. Neste caso, os elementos descritos nos ADVs podem se manter expandidos, contendo a informação da classe de widget abstrata da qual ele foi mapeado, como proposto neste trabalho, mas em vez de componentes MXML o campo de mapeamento concreto deve conter os componentes ou objetos da nova linguagem utilizada. Na construção do estudo de caso foram constatadas algumas deficiências em relação à integração das etapas do OOHDM quando se buscava a modelagem do sistema para a implementação em Flex, problemas os quais as extensões 1 e 3 propostas neste trabalho tentam resolver. Também foram encontrados modelos de implementação em Flex (os view states) que não tinham correspondência direta com alguma primitiva do OOHDM, sendo necessária a construção de um modelo abstrato hierárquico dos ADVs para suportar este modelo. Devido ao fato de a aplicação modelada no estudo de caso ser de pequenas proporções no que diz respeito ao número de classes navegacionais, não se fez necessária a utilização dos cartões de navegação (OOHDM) e mesmo assim não se perdeu informação para a construção do sistema. Apesar disso, as extensões propostas não excluem os cartões de navegação e estes podem ser utilizados sempre que o volume de classes navegacionais no sistema não for facilmente gerenciável. 111

112 Trabalhos Futuros A seguir são enumerados alguns trabalhos futuros Implementação das classes OOHDM em ActionScript para construção de uma ferramenta de geração automática de interfaces concretas similar à ferramenta idealizada por Sabrina Moura (MOURA,2004). Neste trabalho, a obtenção de dados das classes navegacionais persistidas no banco de dados seria feita através de comandos OOHDM quando da requisição HTTP da aplicação, o que geraria uma compilação on-the-fly que construiria a interface de acordo com dados dinâmicos. Utilização das extensões propostas no desenvolvimento de outras aplicações, para efeitos de validação. Estas aplicações deveriam incluir diversos tipos de widgets de interface, a fim de experimentar ao máximo os recursos do método OOHDM adaptado. Continuação do desenvolvimento dos ADVs Flex para que contenham informações de transições entre os view states (mx:transitions), ativações de UIs (e outras características relevantes à implementação em Flex. 112

113 7 Bibliografia COENRAETS, C. An overview of MXML: The Flex markup language. Adobe - Developer Center disponível em < Acesso em: 03 Abr GARZOTTO, F. ; SCHWABE, D. ; PAOLINI, P.. HDM - A Model Based Approach To Hypermedia Application Design. ACM Transactions on Information Systems, New York, EUA, v. 11, n. 1, p. 1-26, GAY, J. Macromedia - Showcase: History of Flash disponível em < Acesso em: 18 abr KOCH, N. A Comparative Study of Methods for Hypermedia Development. Universidade Ludwig-Maximilians de Munique, Alemanha, LIMA, F; SCHWABE, D. Application Modeling for the Semantic Web. Puc-Rio, Brasil, MOOCK, C. Essencial ActionScript 3.0. Sebastopol, CA, EUA:O Reilly, MOURA, S. Desenvolvimento de Interfaces Governadas por Ontologias para web Semântica. PUC-Rio, Brasil, REMÁCULO, L. R. Personalização de Diagramas de Interação do Usuário e Mapeamento para a Ontologia de Widgets Abstratos, Trabalho de conclusão de curso, UFSC, Brasil, 2005 ROSSI, G. Um método orientado a objetos para o projeto de aplicações hipermídia. Tese de Doutorado, Puc-Rio, Brasil, 1996 SCHWABE, D. OOHDM Wiki :: Summary of OOHDM disponível em < Acesso em: 25 mar SCHWABE, D.; ROSSI, G. V.. An Object Oriented Approach To Web-Based Application Design. Theory and Practice of Object Systems, New York, v. 4, n. 4, p , VILAIN, P. Modelagem da Interação com o Usuário em Aplicações Hipermídia. Tese de Doutorado. PUC-Rio, Brasil, VILAIN, P.; SCHWABE, D.; de SOUZA, C.S. A Diagrammatic Tool for Representing User Interaction in UML Puc-Rio, ADOBE. Adobe - Flex 3 - Overview. 2008a. disponível em < Acesso em: 15 mai

114 ADOBE. Adobe Flash Player: PC Penetration. 2008b. disponível em < Acesso em: 5 jun Flash Magazine1 > News. Flash Magazine disponível em < Acesso em: 20 mar

115 8 Anexos 8.1 Casos de uso da aplicação de exemplo Caso de Uso: Montar camiseta Atores: Comprador Tipo: Descrição: Um comprador (usuário cadastrado) escolhe a opção de montar uma nova camiseta. Ele escolhe a cor, a estampa, dentre as que podem ser aplicadas nesta cor, e as cores que podem ser aplicadas nesta estampa nesta cor de camiseta. Com a camiseta montada ele tem a opção de armazenar esta camiseta montada, adicioná-la ao carrinho de compras, começar novamente a montagem de uma nova camiseta ou voltar à vitrine. Caso de Uso: Escolher camiseta da vitrine Atores: Comprador Tipo: Descrição: Um comprador (usuário) percorre por uma galeria de camisetas previamente montadas pelo VIME (vitrine) e pode, selecionando uma delas, ou ser direcionado para o sistema de montagens de camisetas com esta camiseta carregada para ser modificada ou enviá-la para o carrinho de compras. Caso de Uso: Escolher produto da loja simples Atores: Comprador Tipo: Descrição: Um comprador percorre a lista da loja de produtos simples (que não requerem personalização como DVDs e Carteiras) e pode escolher quais quer adicionar ao carrinho de compras. O comprador pode selecionar um dos produtos e ver seus detalhes. Quando visualizando os detalhes de algum produto, aparecerá uma lista de produtos relacionados, que o comprador pode enviar diretamente para o carrinho de compras ou ver seus detalhes Caso de Uso: Comprar Camisetas e outros produtos (utilizar carrinho de compras). Atores: Comprador, Vime Tipo: Descrição: Um comprador (usuário cadastrado) após ter montado uma ou mais camisetas decide por comprá-las. Ele seleciona dentre as camisetas enviadas ao carrinho de compras as que quer comprar efetivamente, as quantidades de cada tamanho para cada camiseta que deseja, a quantidade dos produtos comuns. O sistema atualiza as informações de quantidade e preço ao passo que o usuário define novos e passa para o passo seguinte, a confirmação do pedido. Com o pedido e preço total revisado e confirmado, ele escolhe uma dentre as formas de pagamento e passa para o seguinte passo, a inserção de dados (endereço de entrega, numero do cartão) para ser gerado o pedido. Com o pedido gerado o comprador passa então para o passo de recebimento de um comprovante de pedido. A partir daqui o comprador pode escohler continuar navegando no VIME ou comprar mais camisetas. O VIME recebe o pedido e dá entrada ao processo de confecção física das camisetas para o envio, e depois de confirmado com o fornecedor, envia um de confirmação do prazo de entrega das camisetas. 115

116 Caso de Uso: Escutar rádio (é um use case?) Atores: Comprador Tipo: Descrição: Enquanto usa o sistema, o comprador estará escutando musicas ao durante duas horas a cada duas semanas em um programa ao vivo. Fora deste horário, o programa a ser exibido será o último realizado. Caso de Uso: Pesquisar a radio Atores: usuário, sistema Tipo: Descrição: O usuário escolhe pesquisar os programas de rádio da emissora. O sistema exibe uma lista de programas de rádio, exibindo o nome a data e o nome do DJ. O usuário pode escutar um dos programas, ou ver os detalhes de um dos programas. Se for escolhido ver os detalhes, o sistema exibe o programa de rádio, mostrando o nome, a data de exibição, o tempo total do programa, o nome do DJ que criou este programa a lista de musicas que fazem parte deste programa, incluindo o nome da música e o nome do intérprete. O usuário pode escolher escutar o programa corrente ou ver os detalhes do DJ em questão. Caso de Uso: Ver galeria de fotos/video Atores: Comprador Tipo: Descrição: O comprador pode ver fotos e videos procurando em uma galeria visual através de miniaturas dos mesmos e então obter mais informações selecionando um deles. Nestas informações estão incluidos o conteúdo original, e dados extras como autor, descição, data e links externos. Caso de Uso: Fazer Cadastro de Usuario Atores: Usuário comum Tipo: Descrição: O usuário quer fazer seu registro no sistema e fornece dados cadastrais. a partir deste ponto, o usuário recebe status de comprador e pode fazer o checkout no sistema de montagem de camisetas. (mail de confirmação?) Caso de Uso: Fazer conexão (login) Atores: Usuário comum Tipo: Descrição: O usuário entra com seu e senha previamente cadastrados e habita a navegação do comprador (pode utilizar o carrinho de compras, etc). Caso de Uso: inserir novas camisetas Atores: administrador Tipo: Descrição: O administrador seleciona a camiseta a ser inserida no sistema e fornece a informação da cor desta camiseta. A partir da cor da camiseta, será possível escolher um determinado conjunto de cores para as estampas. 116

117 Caso de Uso: inserir novas estampas Atores: administrador Tipo: Descrição: O administrador seleciona a estampa a ser inserida no sistema e fornece a informação de quantas cores tem a estampa e as cores iniciais. O sistema então exibe todas as camisetas cadastradas no sistema e o administrador seleciona quais camisetas poderão receber a estampa a ser inserida. Caso de Uso: inserir novos produtos simples Atores: administrador Tipo: Descrição: O administrador seleciona a imagem do produto, e insere os dados e descrição, preço do produto. Caso de Uso: administrar usuários Atores: administrador Tipo: Descrição: O administrador pode inserir, editar dados cadastrais e apagar usuários do sistema. Os dados de cartão de crédito devem ser criptografados. Caso de Uso: administrar rádio Atores: administrador Tipo: Descrição: O administrador faz o upload do programa de radio (arquivo de som) e preenche informações das musicas e do dj em questão. 117

118 8.2 Diagrama de UIDs para a aplicação de exemplo UID Fazer Login opções do sistema ver vitrine usar loja comum Pesquisar Rádio ver galeria multimídia fazer cadastro montar camisetas ver detalhes camiseta ver detalhes produto ver detalhes Programa de Rádio ver detalhes DJ Diagrana de UIDs opções de administração inserir/ apagar/editar modelo inserir/ apagar/editar estampa administrar camisetas administrar vitrine administrar rádio inserir/ apagar/editar programa de rádio ver carrinho de compras inserir/ apagar/editar programa de rádio inserir/ apagar/editar usuário administrar usuários inserir/ apagar/editar usuário administrar loja pesquisar compras administrar galeria multimídia 118

119 119

120 8.3 Diagrama de Classes conceituais da aplicação de exemplo Diagrama de Classes Conceituais CamisetaPersonalizada Comprador Compra contém 0..* código 0..* monta 0..1 tipo 1..* contém cpf/cnpj rg sexo data nascimento endereço CEP cidade estado país telefone 1 faz 0..* data valor Total 0..* inclúi 1..* 1 1 tipo imagem preço Modelo Estampa desenho número de cores cores padrão categoria de preço 0..* cria 1 Artista Gráfico descrição homepage foto Usuário Administrador nome sobrenome senha 0..* 0..* é tingido de contém Cor Tecido Cor Tinta número comercial número CMYK Programa de Rádio DJ contém Música 1 perfil foto 1 nome data tempo som 0..* 0..* 1..* 1..* cria nome executada por Cor nome valor RGB Playlist ordem Produto nome preço ProdutoComum descrição estoque foto Intérprete nome 0..* 0..* relaciona com 120

121 8.4 Regras de consistência Ontologia de Widgets Concretos estendida :SimpleActivator a owl:class; rdfs:subclassof awo:abstractinterfaceelement; rdfs:subclassof [a owl restriction; owl:allvaluesfrom [a owl:class; owl:oneof (cwo:button cwo:linkbutton) ]; owl:onproperty awo: MapsTo ]. cwo:button a cwo:concreteinterfaceelement. cwo:linkbutton a cwo:concreteinterfaceelement. // :ElementExhibitor a owl:class; rdfs:subclassof awo:abstractinterfaceelement; rdfs:subclassof [a owl restriction; owl:allvaluesfrom [a owl:class; owl:oneof (cwo:image cwo:label cwo:progressbar cwo:text cwo: ToolTip cwo:videodisplay) ]; owl:onproperty awo: MapsTo ]. cwo:image a cwo:label a cwo:concreteinterfaceelement. cwo:concreteinterfaceelement. cwo:progressbar a cwo:concreteinterfaceelement. cwo:text a cwo:tooltip a cwo:concreteinterfaceelement. cwo:concreteinterfaceelement. cwo:videodisplay a cwo:concreteinterfaceelement. // :IndefiniteVariable 121

122 a owl:class; rdfs:subclassof awo:variablecapturer; rdfs:subclassof [a owl restriction; owl:allvaluesfrom [a owl:class; owl:oneof (cwo:textarea cwo:textinput) ]; owl:onproperty awo: MapsTo ]. cwo:textarea a cwo:concreteinterfaceelement. cwo:textinput a cwo:concreteinterfaceelement. // :ContinuousGroupMultiple a owl:class; rdfs:subclassof awo:predefinedvariable; rdfs:subclassof [a owl restriction; owl:allvaluesfrom [a owl:class; owl:oneof (cwo:hslider cwo:vslider) ]; owl:onproperty awo: MapsTo ]. cwo:hslider a cwo:concreteinterfaceelement. cwo:vslider a cwo:concreteinterfaceelement. // :ContinuousGroup a owl:class; rdfs:subclassof awo:predefinedvariable; rdfs:subclassof [a owl restriction; owl:allvaluesfrom [a owl:class; owl:oneof (cwo:hslider cwo:vslider cwo:numericstepper) ]; owl:onproperty awo: MapsTo ]. cwo:hslider a cwo:vslider a cwo:concreteinterfaceelement. cwo:concreteinterfaceelement. cwo:numericstepper a cwo:concreteinterfaceelement. //

123 :DiscreetGroupMultiple a owl:class; rdfs:subclassof awo:predefinedvariable; rdfs:subclassof [a owl restriction; owl:allvaluesfrom [a owl:class; owl:oneof (cwo:hslider cwo:vslider) ]; owl:onproperty awo: MapsTo ]. cwo:hslider a cwo:vslider a cwo:concreteinterfaceelement. cwo:concreteinterfaceelement. // :DiscreetGroup a owl:class; rdfs:subclassof awo:predefinedvariable; rdfs:subclassof [a owl restriction; owl:allvaluesfrom [a owl:class; owl:oneof (cwo:hslider cwo:vslider cwo:datechooser) ]; owl:onproperty awo: MapsTo ]. cwo:hslider a cwo:vslider a cwo:concreteinterfaceelement. cwo:concreteinterfaceelement. cwo:numericstepper a cwo:concreteinterfaceelement. // :MultipleChoices a owl:class; rdfs:subclassof awo:predefinedvariable; rdfs:subclassof [a owl restriction; owl:allvaluesfrom [a owl:class; owl:oneof (cwo:hslider cwo:vslider cwo:datechooser cwo:checkbox) ]; owl:onproperty awo: MapsTo ]. cwo:hslider a cwo:vslider cwo:concreteinterfaceelement. 123

124 a cwo:concreteinterfaceelement. cwo:datechooser a cwo:concreteinterfaceelement. cwo:checkbox a cwo:concreteinterfaceelement. // :SingleChoice a owl:class; rdfs:subclassof awo:predefinedvariable; rdfs:subclassof [a owl restriction; owl:allvaluesfrom [a owl:class; owl:oneof (cwo:hslider cwo:vslider cwo:datechooser cwo:comboboxcwo:datefield cwo:numericstepper cwo:radiobutton) ]; owl:onproperty awo: MapsTo ]. cwo:hslider a cwo:vslider a cwo:concreteinterfaceelement. cwo:concreteinterfaceelement. cwo:datechooser a cwo:concreteinterfaceelement. cwo:combobox a cwo:concreteinterfaceelement. cwo:datefield a cwo:concreteinterfaceelement. cwo:numericstepper a cwo:concreteinterfaceelement. cwo:radiobutton a cwo:concreteinterfaceelement. // :CompositeInterfaceElement a owl:class; rdfs:subclassof awo:abstractinterfaceelement; rdfs:subclassof [a owl restriction; owl:allvaluesfrom [a owl:class; owl:oneof (cwo:buttonbar cwo:datagrid cwo:horizontallist cwo:linkbar cwo:list cwo:menu cwo:menubar cwo:tree cwo:popupbutton cwo:radiobuttongroup cwo:swfloader 124

125 125 cwo:tabbar cwo:tilelist cwo:togglebuttonbar cwo:composite) ]; owl:onproperty awo: MapsTo ]. cwo:buttonbar a cwo:concreteinterfaceelement. cwo:datagrid a cwo:concreteinterfaceelement. cwo:horizontallist a cwo:concreteinterfaceelement. cwo:linkbar a cwo:concreteinterfaceelement. cwo:list a cwo:concreteinterfaceelement. cwo:menu a cwo:concreteinterfaceelement. cwo:tree a cwo:concreteinterfaceelement. cwo:popupbutton a cwo:concreteinterfaceelement. cwo:radiobuttongroup a cwo:concreteinterfaceelement. cwo:swfloader a cwo:concreteinterfaceelement. cwo:tabbar a cwo:concreteinterfaceelement. cwo:tilelist a cwo:concreteinterfaceelement. cwo:togglebuttonbar a cwo:concreteinterfaceelement. cwo:composition a cwo:concreteinterfaceelement. //

126 8.5 Interface Visual de Componentes MXML Container MXML Apresentação Visual Accordion ApplicationControlBar HBox Canvas 126

127 ControlBar Form Grid Panel 127

128 TabNavigator ViewStack Control MXML Apresentação visual Button ButtonBar CheckBox ColorPicker ComboBox 128

129 DataGrid DateChooser DateField HorizontalList HSlider / VSlider Image imagem (jpg, gif ou png) 129

130 Label Label LinkBar LinkButton List Menu MenuBar 130

131 NumericStepper PopUpButton PopUpMenuButton ProgressBar RadioButton RadioButtonGroup TabBar Text 131

132 TextArea TextInput TileList ToggleButtonBar ToolTip Tree 132