TCC Pedro germani Ghiorzi Rascunho Relatorio Final

Document Sample
TCC Pedro germani Ghiorzi Rascunho Relatorio Final Powered By Docstoc
					UNIVERSIDADE FEDERAL DE SANTA CATARINA – UFSC

          CENTRO TECNOLÓGICO – CTC

DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA – INE

       CURSO DE CIÊNCIAS DA COMPUTAÇÃO




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

         aplicações hipermídia em Flex




               Pedro Germani Ghiorzi




          Profª. Orientadora: Patrícia Vilain



                           Trabalho de conclusão de curso apresentado

                           como parte dos requisitos para obtenção do

                           grau   de    Bacharel   em   Ciências   da

                           Computação




              FLORIANÓPOLIS, 2008/1
             Pedro Germani Ghiorzi




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

          aplicações hipermídia em Flex




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



    _________________________________
          Orientadora: Patrícia Vilain




              Banca examinadora

     ________________________________
           Leandro José Komosinski


    __________________________________
            Ricardo Pereira e Silva




          Florianópolis, Junho de 2008
DEDICATÓRIA (S) ( opcional ):   folha seguinte
AGRADECIMENTO (S) ( opcional ):folha seguinte
                                                         SUMÁRIO

1      INTRODUÇÃO             .................................................................................... 11

2      HIPERMÍDIA E OOHDM. ........................................................................ 15

    2.1    HIPERMÍDIA ........................................................................................................... 15
    2.2    OOHDM............................................................................................................... 18
    2.3    ETAPAS DO MÉTODO OOHDM ............................................................................... 20
      2.3.1 Análise de requisitos ........................................................................................ 20
      2.3.2 Modelagem conceitual ..................................................................................... 23
      2.3.3 Projeto de navegação ...................................................................................... 25
      2.3.4 Projeto da interface abstrata ............................................................................ 29
      2.3.5 Implementação ................................................................................................ 42

3      FLEX E FLASH             ................................................................................... 44
    3.1    FLEX .................................................................................................................... 44
      3.1.1 Versões lançadas e features associadas ......................................................... 45
      3.1.2 Linguagens de programação. .......................................................................... 47
      3.1.3 Criação de interfaces no Flex .......................................................................... 52
    3.2    FLASH .................................................................................................................. 71

4      A PROPOSTA ..................................................................................... 75

    4.1       EXTENSÃO 1 - ESPECIFICAÇÃO DOS WIDGETS ABSTRATOS ....................................... 77
    4.2       EXTENSÃO 2 - ESPECIFICAÇÃO DOS WIDGETS CONCRETOS MXML .......................... 82
    4.3       EXTENSÃO 3 - ESPECIFICAÇÃO DE ADVS PARA FLEX ............................................... 94
    4.4       EXTENSÃO 4 - ESPECIFICAÇÃO DE VIEW STATES DO FLEX ........................................ 98

5      MODELAGEM DE APLICAÇÃO OOHDM – FLEX ....................................... 105

6      CONSIDERAÇÕES FINAIS ................................................................... 110

    TRABALHOS FUTUROS ..................................................................................................... 112

7      BIBLIOGRAFIA ................................................................................. 113

8      ANEXOS         ......................................................................................... 115
    8.1       CASOS DE USO DA APLICAÇÃO DE EXEMPLO .......................................................... 115
    8.2       DIAGRAMA DE UIDS PARA A APLICAÇÃO DE EXEMPLO ............................................ 118
    8.3       DIAGRAMA DE CLASSES CONCEITUAIS DA APLICAÇÃO DE EXEMPLO ......................... 120
    8.4       REGRAS DE CONSISTÊNCIA ONTOLOGIA DE W IDGETS CONCRETOS ESTENDIDA ....... 121
    8.5       INTERFACE VISUAL DE COMPONENTES MXML ...................................................... 125
LISTA DE FIGURAS

Figura 2.1- UID Pesquisar Rádio .......................................................................................................... 23

Figura 2.2 – Diagrama de Classes Conceituais.................................................................................... 24

Figura 2.3 – Diagrama de Classes Navegacionais ............................................................................... 26

Figura 2.4 - Diagrama de Contextos Navegacionais ............................................................................ 27

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

Figura 2.6 - Diagrama de Classes da Ontologia de Widgets Abstratos ............................................... 32

Figura 2.7 - Regra de consistência de Mapeamento Concreto ............................................................ 40

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

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

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

Figura 3.3 – Exemplo simples de aplicação Flex ................................................................................. 52

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

Figura 3.5 – Tela do Future Splash Animator ....................................................................................... 73

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

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

Figura 4.3 - Classes da Ontologia de Widgets Abstratos extendida .................................................... 80

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

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

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

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

Figura 4.8- Mapeamento de entidades navegacionais para ADVs ...................................................... 96

Figura 4.9 - ADV Programa de rádio .................................................................................................... 97

Figura 4.10 - Diagrama de ADVs ........................................................................................................ 100
LISTA DE CÓDIGOS-FONTE

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

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

Código Fonte 3.3 - Exemplo de implementação de view states .......................................... 54
LISTA DE TABELAS

Tabela 2.1 - Etapas do Processo OOHDM.......................................................................... 19

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

Tabela 4.3 - Definição de widgets concretos MXML a partir dos widgets abstratos ............. 94
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
    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
       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.




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

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


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

trabalho e sugere alguns trabalhos futuros.




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



                                              16
        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

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
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
       A identificação explícita de que existem decisões de projeto (design) que

        precisam ser feitas apenas quando da implementação.



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

   processo de desenvolvimento OOHDM.

                        Tabela 2.1 - Etapas do Processo OOHDM


Etapa            Artefatos             Formalismos            Mecanismos         Considerações
                                                                                 de Projeto

Análise de       Casos de uso,         Cenários, UIDs,        Análise de         Captura dos
Requisitos       Anotações             Padrões de Projeto.    cenários e casos   requisitos do
                                                              de uso,            domínio da
                                                              Entrevistas,       aplicação
                                                              Mapeamento
                                                              UID – modelo
                                                              conceitual

Modelagem        Classes,              Modelo Orientado a     Classificação,     Modela a
Conceitual       Subsistemas,          Objeto, Padrões de     Agregação,         semântica do
                 Relações,             projeto.               Generalização e    domínio da
                 Atributos                                    Especialização     aplicação

Projeto          Nodos, Âncoras,       Visões Orientadas a    Classificação,     Leva em conta
Navegacional     Estruturas de         objeto, State charts   Agregação,         perfil do usuário
                 acesso, Contextos     Orientados a objeto,   Generalização e    e tarefas
                 navegacionais,        Classes de             Especialização     relacionadas.
                 Transformações        contexto, Padrões                         Ênfase em
                 navegacionais         de Projeto, Cenários                      aspectos
                                       centralizados no                          cognitivos.
                                       usuário.                                  Constrói a
                                                                                 estrutura
                                                                                 navegacional da
                                                                                 aplicação;

Projeto de       Objetos de            Abstract Data          Mapeamento         Modela objetos
Interface        interface Abstrata,   Views, Diagramas       entre objetos      perceptíveis,
Abstrata         Respostas a           de configuração;       navegacionais e    implementando
                 eventos externos,     ADV-Charts;            objetos            metáforas
                 Transformações        Padrões de projeto     perceptíveis       escolhidas.
                 de interface                                                    Descreve
                                                                                 interface de
                                                                                 objetos
                                                                                 navegacionais.
                                                                                 Define o layout
                                                                                 dos objetos de
                                                                                 interface;

Implementação    Aplicação             Os suportados pelo     Os suportados      Performance
                 executável            ambiente de            pelo ambiente de
                                       desenvolvimento        desenvolvimento

                                               19
2.3 Etapas do método OOHDM
2.3.1 Análise de requisitos


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

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

comportamentos do sistema a ser projetado.


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

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


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

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

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

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

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

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

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

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


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

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

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

(VILAIN, 2002).


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

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

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

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

por informações nesta rádio.


                                             20
 Caso de Uso: Pesquisar a radio

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




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

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

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


 Caso de Uso Expandido: Pesquisar a radio

 Ações do Ator                               Resposta do sistema
      1. O usuário opta por pesquisar a         2. O sistema exibe a lista de
                     radio                         programas organizada por data de
                                                   exibição, são exibidos os atributos
                                                   data do programa, nome do
                                                   programa e nome do DJ.
     3. O usuário escolhe um dos                4. O sistema exibe nome do
        programas                                  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
           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
                                                                 <1>

                             ...programa de radio (nome, data, DJ(nome))
                                                                                  1 (escutar programa)



                                    1 (ver detalhes)
                                                                  <2>                           (escutar programa)


               programa de radio(nome, data, tempo, som, dj(nome), ...musica(nome, artista))




                                                             1(ver DJ)


                                                                            <3>

                                                               UID ver DJ




                                    Figura 2.1- UID Pesquisar Rádio

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

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

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

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




2.3.2 Modelagem conceitual




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

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

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

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

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

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

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

descritas de acordo com os modelos UML.
                                                        23
       A partir dos UIDs é possível se extrair dados para a construção de um diagrama de

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

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

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

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

dos textos dos casos de uso




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

(Figura 2.2)



                              Programa de Rádio                            Musica

                          nome: String                                   nome: String
                                                  1               1..*
                          data: String                                   Artista: String
                          tempo: String
                          som: Audio




                   cria


                                                      playlist

                 DJ                               ordem: Numero

               nome: String
               perfil: Text
               foto: Imagem




                              Figura 2.2 – Diagrama de Classes Conceituais




                                                         24
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
         Programa de Rádio                                       DJ

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




                           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
          Em qual conjunto de objetos o usuário navegará (os contextos navegacionais);


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


          Quais diferentes conteúdos devem ser apresentados para o usuário,

           dependendo do contexto em que ele está navegando.


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

contextos navegacionais e as estruturas de acesso.


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

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

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

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

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

conjunto de fatores que determinam a navegação.


       A


       Figura 2.4 exibe uma parte do esquema de contextos navegacionais.



                                                 Programa de Rádio   DJ

                                                      por nome            por nome
                                      nome
                                                       por data
                                      data
                                                      por DJ
                     Radio
                                       DJ
                                                      por busca

                                     busca




                             Figura 2.4 - Diagrama de Contextos Navegacionais


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

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

quadros internos os contextos navegacionais.

                                                27
       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                 Programa de Rádio por DJ           Programa de Rádio por NOME

          calendario:Calendario                     idxProgramas: nome, data de         proximo: anchor(programa por NOME)
          proximo: anchor(programa por DATA)                   Programas por DJ         anterior: anchor(programa por NOME)
          anterior: anchor(programa por DATA)       proximo: anchor(programa por DJ)
                                                    anterior: anchor(programa por DJ)




       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
                        de navegação. As informações comuns a todos os objetos de uma classe

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

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

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

                        distintas no contexto em questão.


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

projeto de interface abstrata.




2.3.4 Projeto da interface abstrata


       A modelagem de uma interface abstrata é construída definindo objetos perceptíveis

em termos de interface, como por exemplo, uma foto, uma caixa de seleção de valores, um

mapa da cidade, entre outros. Estas classes são definidas como agregações de elementos

primitivos, como caixas de textos, botões, imagens, e também de maneira recursiva,

utilizando outras classes de interface.


       Os objetos de interface são mapeados a partir dos objetos navegacionais do projeto

de navegação, provendo assim uma aparência perceptível do sistema. O comportamento da

interface é declarado especificando como eventos externos ou gerados pelo usuário são

tratados, e em como se dá a comunicação entre a interface e os objetos navegacionais.


    Diferentemente da modelagem conceitual e do modelo navegacional, que determinam

os elementos do domínio da aplicação e a maneira como o usuário completará suas tarefas,

a Interface Abstrata existe para determinar os objetos navegacionais e a funcionalidade da

aplicação que devem se perceptíveis pelo usuário na interface da aplicação. Mesmo quando

a interface é percebida como uma parte externa do domínio da aplicação, em um nível mais

abstrato, pode ser considerada como mais uma das informações trocadas entre o usuário e



                                               29
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 Interface2 (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
levando em conta os aspectos específicos do ambiente em que será implementada tal

interface, definidos pela Ontologia de Widgets Concretos.




    2.3.4.1   Ontologia de Widgets Abstratos


    Ontologia é a parte da filosofia que estuda o conhecimento do ser (ontos=ser +

logoi=conhecimento). Sua questão fundamental é “o que é isto?”, portanto, trata de

questões relativas ao mundo do real e não propriamente das representações feitas pelo

nosso pensamento. No contexto da computação, a palavra ontologia é utilizada quando se

quer fazer uma descrição de um determinado objeto de estudo, neste caso, os widgets de

interface. Widget (um termo ainda sem tradução para o português) é um elemento de

interface com o qual o usuário pode interagir. Neste caso os widgets são abstratos, ou seja,

são descritos modelos de interface especificando como os objetos navegacionais serão

apresentados e quais elementos serão perceptíveis para o usuário, sem expressar sua

forma ou funcionamento. Posteriormente estes modelos são mapeados para uma ontologia

mais próxima da fase do projeto da interface abstrata, que descreve os widgets concretos.


    A Ontologia de Widgets Abstratos (MOURA, 2004), foi desenvolvida na linguagem OWL

(Onthology Web Language), uma linguagem desenvolvida para ser utilizada em/por

aplicações que precisam processar o conteúdo em vez de simplesmente exibi-los ao

usuário. De certa maneira, isso significa que uma aplicação não só consegue buscar dados

em seu próprio sistema, mas sim “navegar” (analogamente à navegação em browsers na

internet) por vários sistemas a fim de colher dados que a permitam inferir novos dados,

fazendo uma leitura semântica dos primeiros.


    A Ontologia de Widgets Abstratos é composta de 11 conceitos (ver Figura 2.6), que

representam os seus elementos. Estes elementos são comparáveis às primitivas dos UIDs,

pois oferecem suporte às mesmas interações realizadas pelo usuário com o sistema, como

                                            31
entradas de dados (itens de dado ou estruturas de itens de dados), saídas do sistema (itens

de dado ou estruturas de itens de dados), e operações realizadas pelo usuário. “Acredita-

se que, através dos conceitos definidos nesta ontologia, é possível conseguir a

representação de todas as interações do usuário com o sistema.” (MOURA, 2004).


    As classes dessa ontologia representam um ou mais elementos abstratos das

interfaces das aplicações hipermídia como é mostrado na Figura 2.6:


                                         AbstractInterfaceElement




 SimpleActivator      ElementExhibitor           VariableCapturer               CompositeInterfaceElement




                                            PredefinedVariable      IndefiniteVariable




ContinuousGroup       DiscreetGroup          MultipleChoices         SingleChoice


               Figura 2.6 - Diagrama de Classes da Ontologia de Widgets Abstratos




   AbstractInterfaceElement: esta classe é composta por 4 subclasses que definem os

   possíveis elementos abstratos. Estes elementos representam os possíveis tipos de

   interações entre o usuário e o sistema.


       1. SimpleActivator: esta classe representa qualquer elemento capaz de reagir a

            eventos externos – caso típico do clicar o mouse – que possua um evento

            associado a ele, tais como ativar um link, um botão de ação, o envio de um e-

            mail, dentre outros

                                                     32
   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
        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
    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
    2.3.4.2   Ontologia de Widgets Concretos

      Utilizando-se dos elementos e primitivas da Ontologia de Widgets Abstratos, o

processo de criação da interface modelou e mapeou os elementos de interface desejados

para a ontologia abstrata. Cada elemento deve ser associado a uma das classes da

ontologia e ser descrito através da linguagem OWL. Depois, com estas descrições dos

elementos abstratos, é gerada outra descrição, desta vez mapeando cada elemento

abstrato para um elemento concreto, que possuí descrições mais próximas das interfaces

reais, considerando de maneira ainda rasa questões relativas ao ambiente em que será

desenvolvido o sistema. Para fazer esta descrição, Sabrina Moura (MOURA, 2004) sugere a

utilização de linguagens como XUL, LASZLO e outras. Estas linguagens estão bem mais

próximas da interface concreta do que a proposta por Sabrina Moura, pois descrevem com

certa precisão regras de consistência que devem ser consideradas quando da

implementação do sistema e ainda cada tipo de mapeamento que pode ser feito.


      A Ontologia de Widgets Concretos é descrita por algumas classes, que representam

apenas um pequeno conjunto das possibilidades existentes. A seguir será exposto este

conjunto. O presente trabalho irá definir mais classes que encontramos em ambientes de

desenvolvimento MXML/ActionScript 3.0 no capítulo 4.


              Button: representa os elementos que possuem funções embutidas a

      serem realizadas, como: submit e reset por exemplo. Essas funções são

      executadas quando esse elemento é ativado, através do mouse ou do

      teclado;


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

      selecionado ou não selecionado. O usuário pode alterar o estado desse

      elemento, clicando com o mouse ou via teclado, na caixa de verificação


                                          36
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
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
             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
                Figura 2.7 - Regra de consistência de Mapeamento Concreto




       Esta regra diz que os elementos abstratos “SimpleActivator” são subclasses da

classe AbstractInterfaceElement (como todos os outros), e que estão restringidos a serem

mapeados para os elementos “Link” e “Button”. Se forem observadas as ontologias

previamente descritas, se perceberá que são realmente os dois únicos elementos de

interface que podem ser considerados como ativadores simples de ações pelo usuário. As

outras classes ou são mais complexas, sendo uma composição de elementos incluindo

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


       Na proposta feita por Moura (2004) depois de ser realizado o mapeado os elementos

abstratos para os concretos, é então construído o projeto do layout (disposição dos

elementos) da interface com o usuário. É então aplicado o modelo de caixas do padrão

CSS, no qual cada elemento de interface concreta é enclausurado por uma caixa definida

por estilos CSS, provendo através da propriedade “BlockElement” da Ontologia de Widgets

Abstratos a informação de qual tipo de „caixa‟ que o elemento concreto será colocado. No

caso desta proposta, o sistema seria implementado em HTML, logo, este mapeamento das

                                           40
caixas está diretamente relacionado com as tags da linguagem HTML. Além disso, nesta

propriedade, pode ser definida a classe CSS a qual o elemento estará relacionado, já

produzindo diretrizes para como serão exibidos os elementos de interface visual. Esta

relação é efetivamente construída quando da implementação do sistema.


        No contexto do presente trabalho, a implementação feita em Flex permite utilizar

outra gama de containers (Block elements) para o enclausuramento dos elementos de

interface. Da mesma maneira como acontece em HTML, em MXML existem diversos tipos

de elementos de disposição espacial que podem ser utilizados como valor da propriedade

blockElement. Será feito também o mapeamento dos componentes MXML para a Ontologia

de Widgets Abstratos, criando modelos de interface adaptados para a configuração de

interfaces Flex adequadas.




    2.3.4.3   Abstract Data Views (ADVs)




        “A partir do esquema de classes de navegação e o esquema de contextos

navegacionais, são gerados ADVs (Abstract Data Views) correspondentes a cada interface

do sistema. Os ADVs representam os elementos da interface e como eles reagirão a

eventos (tanto do usuário como do sistema), criando uma visão clara de como se dá a

experiência do usuário ao navegar pelo sistema. Os ADVs são bastante semelhantes aos

Diagramas de Navegação, permitindo que o projeto prossiga de maneira uniforme.” (ROSSI,

1996)


        São extraídos ADVs para cada nó, índice, classe navegacional e contexto do projeto

de navegação. Os ADVs são compostos por outros ADVs, estados, transições e atributos.

ADVs aninhados nos permitem descrever a agregação de elementos de interface, e sua

lógica é facilmente mapeada para elementos de programação descritos por tags

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




2.3.5 Implementação




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

programação e pode envolver arquiteturas elaboradas de aplicação, como por exemplo,
                                               42
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
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
marcação, baseada em XML, chamada de MXML que possibilitou essa analogia. Com as

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

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

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


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

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

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

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

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

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

descreve a lógica da aplicação.


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

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

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

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

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

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




3.1.1 Versões lançadas e features associadas




   A. Flex 1.0


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

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

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

       (Java) e entregava um executável [.SWF] para o browser do usuário. A criação dos
                                             45
   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
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 3.1 - Esquema de publicação de aplicações Flex.
                                           47
    3.1.2.1 ActionScript 3.0


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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




                                           48
    3.1.2.2 MXML


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

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

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

interpretação.


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

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

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

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

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

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

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

PHP, ColdFusion ou JSP, entre outras.


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

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

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


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

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

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

que pode conter animações, efeitos de transição, efeitos gráficos, vídeos e sons

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




                  Figura 3.2 – Esquema de publicação de Aplicações Flex
                                           50
                          utilizando PHP como arquitetura server-side.




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

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

botão “Copiar”.


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

1   <?xml version="1.0" encoding="utf-8"?>
2         <mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml">
3
4
5             <mx:TextInput id="fonte" />
6             <mx:Button label="Copiar" click="destino.text = fonte.text"         />
7             <mx:TextInput id="destino" />
8
9          </mx:Application>



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

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

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


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

1 <?xml version="1.0" encoding="utf-8"?>
2       <mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml">
3
4          <mx:Script>
5
6              function copiar() {
7                  destino.text = fonte.text;
8              }
9
10         </mx:Script>
11
12         <mx:TextInput id="fonte" />
13         <mx:Button label="Copiar" click="copiar()" />
14         <mx:TextInput id="destino" />
15
16      </mx:Application>



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

como pode ser visto na

                                              51
       Figura 3.3:




                      Figura 3.3 – Exemplo simples de aplicação Flex




3.1.3 Criação de interfaces no Flex


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

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

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

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

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


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

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

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

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

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

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

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

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

mínimo da tabela seja ultrapassado.


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

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

podemos destacar o TabNavigator, o Accordion e os ViewStacks. Este último é um conjunto
                                         52
de canvas (telas com posicionamento absoluto (x, y) dos objetos filhos) sobrepostos que o

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

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




    3.1.3.1 VIEW STATES Flex


       States    é   uma     nova   classe   agregada   à      linguagem   ActionScript   3.0   e

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

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

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

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


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


               Alteração do valor de atributos dos objetos;


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


               Estilos visuais.


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

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

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

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

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

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

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

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




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

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


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

1    <?xml version="1.0" encoding="utf-8"?>
2    <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
3        verticalAlign="middle"
4        width="340" height="250"
5    >
6        <mx:Script>
7            <![CDATA[
8               import mx.controls.Alert;
9
10                private function login(u:String, s:String):void{
11
12                       Alert.show("Usuário: "+ u + "\nSenha: "+ s, "Login");
13                }
14
15                private function registrar(u:String, s:String, c:String):void{
16                   if(s == c)
17                   Alert.show("Usuário: "+ u + "\nSenha: "+ s, "Registro OK");
18                   else Alert.show("Senha não confere! \n Senha: "+ s +
19                            "\nConfirma: "+ c, "Registro Inválido!!!");
20                }
21           ]]>
22       </mx:Script>
23
24       <mx:states>
25       <!--
26                O estado Registro é baseado no base state.
27                Todos os estados são baseados no base state por default,
28                então deixa-se a propriedade basedOn em branco.
29            -->
30            <mx:State name="Registro" basedOn="">
31
32                 <!—Adiciona um componente FormItem ao form. -->
33
34                 <mx:AddChild
35                     relativeTo="{loginForm}"
36                     position="lastChild"
37                     creationPolicy="all"
38                 >
39                     <mx:FormItem id="confirma" label="Confirme:">
40                         <mx:TextInput id="senha2"/>
41                     </mx:FormItem>
42                 </mx:AddChild>
43
44            <!—aplica propriedades no Painel e no botão -->
45                <mx:SetProperty target="{loginPanel}"
46                name="title" value="Registro"/>
47
48
49                 <mx:SetProperty target="{loginButton}"
50                 name="label" value="Registro"/>
51
52                 <mx:SetEventHandler target="{loginButton}"

                                            54
53              name="click"
54             handler="registrar(user.text, senha.text, senha2.text);"/>
55
56
57              <!—remove o LinkButton existente. -->
58
59              <mx:RemoveChild target="{registerLink}"/>
60
61              <!--
62                   adiciona um novo Linkbutton para trocar o
63                   o view state de volta para o base state.
64              -->
65              <mx:AddChild relativeTo="{spacer1}" position="before">
66                   <mx:LinkButton
67                     label="Retornar para Login" click="currentState=''"/>
68              </mx:AddChild>
69
70          </mx:State>
71
72      </mx:states>
73
74      <mx:Panel
75          title="Login" id="loginPanel"
76          horizontalScrollPolicy="off" verticalScrollPolicy="off"
77        verticalAlign="middle"
78      >
79
80      <mx:Form id="loginForm">
81          <mx:FormItem label="Usuário:">
82              <mx:TextInput id="user"/>
83
84          </mx:FormItem>
85          <mx:FormItem label="Senha:">
86              <mx:TextInput id="senha"/>
87          </mx:FormItem>
88      </mx:Form>
89
90
91      <mx:ControlBar>
92          <mx:LinkButton
93              label="Quer se registrar?" id="registerLink"
94              click="currentState='Registro'"
95          />
96
97          <mx:Spacer width="100%" id="spacer1"/>
98          <mx:Button label="Login" id="loginButton"
99              click="login(user.text,senha.text);"/>
100
101     </mx:ControlBar>
102
103     </mx:Panel>
104 </mx:Application>




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



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

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

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

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


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

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

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

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

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


       “mx:State” pode ser utilizado para implementar estados de componentes

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

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

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

estado é alterado.


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

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


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

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

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

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




    3.1.3.2 Componentes Flash e componentes Flex


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

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

criados novos componentes de interface no Flash que exportados são utilizados

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

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

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

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

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


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

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

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

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

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

dos mais promissores da internet hoje em dia.




    3.1.3.3 Componentes MXML


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

encontra-se no anexo 8.5.


                                           57
3.1.3.3.1   Containers (Agrupadores)


       Accordion


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

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

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

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

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


       ApplicationControlBar


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

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

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

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

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

        qualquer outro componente de interface.


       Box


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

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

        horizontalmente. Portanto, não utilizamos a marcação <mx:Box> mas sim

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


       Canvas


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

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

        item contido. Estes itens podem ter o tamanho associado ao tamanho do canvas,
                                             58
    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
    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
        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.




3.1.3.3.2   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
          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
         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
          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
   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
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
        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
          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
  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
   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
       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
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
                        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
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, anti-

       aliasing 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 stand-

       alone, 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
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 adaptações, extensões e sugestõ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        UIDs
                           dos UIDs


                                            UIDs


                           classes
                         conceituais
        Modelagem
        Conceitual

       1. Modelagem                                classes e contextos
                                                     navegacionais.
       das classes              Projeto de
       conceituais              Navegação

                             1. Modelagem
                             das classes
                                                                     Projeto de           ADVs
                             navegacionais
                                                                 Interface Abstrata
                             2. modelagem
                             dos contextos                 1. Especificação dos widgets
                             navegacionais                 abstratos

                                                           2. Especificação dos widgets
                 classes e contextos                       concretos
                   navegacionais.                                                                Implementação
                                                           3. Especificação de ADVs




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


                                                            75
                        Análise de
                        Requisitos
                     1. Criação dos
                     casos de uso
           UIDs                              UIDs
                     2. Especificação
                     dos UIDs

                                      UIDs


                    classes
                  conceituais
 Modelagem
 Conceitual

 1. Modelagem                                classes e contextos
                                               navegacionais.
 das classes            Projeto de
 conceituais            Navegação

                      1. Modelagem
                      das classes
                      navegacionais                             Projeto de
                                                            Interface Abstrata
                      2. modelagem                                               ADVs Flex
                      dos contextos
                                                     1. Especificação dos
                      navegacionais
                                                     widgets abstratos

                                                     2. Especificação dos
          classes e contextos                        widgets concretos MXML
            navegacionais.
                                                     3. Especificação de
                                                     ADVs para Flex                          Implementação


                                                                                      1. Criação da interface
                                                                                      utilizando <mx:States>




     Figura 4.2 – Esquema do processo OOHDM estendido 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
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
                        Tabela 4.1 Mapeamento de elementos dos UIDs

                para a Ontologia de Widgets Abstratos. (REMÁCULO, 2005, p. 39)


UIDs                                      Widgets Abstratos

Item de dado e Item de dado               ElementExhibitor ou SimpleActivator
personalizado

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

Conjunto, Conjunto com conteúdo           1º passo: mapear o conjunto            para   um
personalizado                             CompositeInterfaceElement.

e Conjunto em disposição diferenciada     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.

Dado opcional                             ElementExhibitor ou VariableCapturer. No caso
                                          de VariableCapturer, o elemento pode ser
                                          mapeado          para:        IndefiniteVariable,
                                          ContinuousGroup,                  DiscreetGroup,
                                          MultipleChoices ou SingleChoices.

Entrada do Usuário                        IndefiniteVariable

Entrada do Usuário Enumerada              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                                     ElementExhibitor

Estado de Interação, Estado Inicial da    CompositeInterfaceElement. Caso o Estado de
Interação e Estados Alternativos da       Interação     seja     um       conjunto   de
Interação.                                CompositeInterfaceElement,    o    estado  de
                                          interação    será     a     associação    dos
                                          CompositeInterfaceElements.


                                             78
Sub-estados de um Estado de               CompositeInterfaceElement
Interação.

Transição com Seleção da Opção X e        SimpleActivator. No caso da opção precisar de
Transição                                 outro elemento para que o estado de interação
                                          destino se torne o foco da interação, a mesma
com Seleção da Opção Restrita X.:         deve ser mapeada para MulipleChoice ou
                                          SingleChoice e atrelada a um SimpleActivator
                                          para que a transição entre Estados de Interação
                                          ocorra.

Transição com Seleção de N                Os conceitos que suportam a seleção de 1 ou
Elementos                                 mais elementos especificados nos UIDs são:
                                          ContinuousGroup*,DiscreetGroup*,
                                          MultipleChoices ou SingleChoices.

Chamada de Outro UID, Chamada a           Não há mapeamento para a ontologia de widgets
partir de Outro UID, Transição com        abstratos.
Condição Y, Pré-Condições, Pós-
Condições e Notas Textuais.




       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
   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 4.3 - 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
        Figura 4.4 - 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            Item de dado                          SimpleActivator

                      transição (escutar programa)

 nomeDJ:String        Item de dado                          SimpleActivator

                      transição (ver DJ)

 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
„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
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 3.1.3.3.2, 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
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
      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
          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
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
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
          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
   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
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
          É 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
                                                                 AbstractInterfaceElement




        SimpleActivator       ElementExhibitor              VariableCapturer                       CompositeInterfaceElement

            Button                 Image                                                                AdvancedDataGrid
                                                                                                            ButtonBar
          LinkButton                Label
                                     Text                                                                    DataGrid

                                VideoDisplay                                                              HorizontalList

                                   ToolTip                                                                   LinkBar

                                ProgressBar                                                                      List
                                                                                                                 Menu

                                                                                                             MenuBar

                                                                                                          PopUpButton
                              IndefiniteVariable                PredefinedVariable                      PopUpMenuButton

                                  TextArea                                                              RadioButtonGroup

                                  TextInput                                                                 SWFLoader
                                                                                                             TabBar
                                                                                                             TileList
                                                                                                         ToggleButtonBar




 ContinuousGroupMultiple   ContinuousGroup         DiscreetGroup Multiple      DiscreetGroup   MultipleChoices          SingleChoice

                                                             HSlider/VSlider

                                                      NumericStepper                                         DateChooser

                                                                                                 CheckBox                DateField

                                                                                                                        ComboBox

                                                                                                                        RadioButton
                                                                                                                        ColorPicker




                     Figura 4.5 - 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 4.2.


                                                                   93
         Tabela 4.3 - 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                  SimpleActivator        mx:LinkButton

                   transição (ver DJ)

idxMusicas         Estrutura                CompositeInterface     mx:VBox
                                            Element




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
                             A     AbstractInteface

                             C     CompositeInterfaceElement

                             @     SimpleActivator

                                   ElementExibitor

                              ?    IndefiniteVariable

                             {N}   ContinuousGroupMultiple

                             {1}   ContinuousGroup

                             [N]   DiscreetGroup Multiple

                             [1]   DiscreetGroup

                              N    MultipleChoices

                              1    SingleChoice




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




                                   ADV Botão
                                   @   mx:LinkButton



             Figura 4.7 - 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 mx:State no


                                             95
momento da implementação do sistema, como explicado na seção 4.1.4. 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                                   esquema de
                                                                            classes „emContexto‟
                                            classe

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


      Como exemplo, o ADV da Figura 2.8 pode ser descrito de acordo com a extensão

conforme a




                                                                 96
         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                        som                       ADV Programa de Rádio por Data
         mx:Label                @       mx:Button         C       mx:Panel

     data
                                                               nome                   som
         mx:Label
                                                                     mx:Label         @         mx:Button
     tempo
                                                               data                   data
         mx:Label
                                                                     mx:Label
                                                                                       1     mx:DateChooser
     nomeDJ                                                    tempo
     @   mx:LinkButton
                                                                     mx:Label

     ADV musicas                                                nomeDJ
     C      mx:VBox                                            @     mx:LinkButton
              isRepeated

                                                                ADV musicas
      nome
                                                                C     mx:VBox
            mx:Label

      artista
                                                               anterior               próximo
            mx:Label
                                                               @    mx:LinkButton     @    mx:LinkButton




                           (a)                                                       (b)



                                       Figura 4.9 - ADV Programa de rádio

                                                      97
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
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
                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 a 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                        som
                                                                   mx:Label               @        mx:Button

                                                               data
                                                                    mx:Label

                                                               tempo
                                                                    mx:Label

                                                               nomeDJ
                                                              @     mx:LinkButton


                                                               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                    ADV Programa de Rádio por DJ                                 ADV Programa de Rádio por Nome
C        mx:Panel                                 C       mx:Panel                                             C       mx:Panel


     data                                             fotoDJ                                                       anterior              próximo
     1      mx:DateChooser                                     mx:DateChooser
                                                                                                                   @     mx:LinkButton   @   mx:LinkButton


    anterior                 próximo                  anterior                        próximo
    @     mx:LinkButton      @   mx:LinkButton        @       mx:LinkButton           @   mx:LinkButton



                                                      ADV idxProgramasDJ
                                                      C       mx:TileList




                                                 Figura 4.10 - 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
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="http://www.adobe.com/2006/mxml">
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="http://www.adobe.com/2006/mxml">
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="http://www.adobe.com/2006/mxml">
 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>
 19
 20       <!--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
 26                         <mx:LinkButton label="próximo"/>
 27                   </mx:AddChild>
 28
 29       <!--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>
 42
 43       <!--Declaração do “base state”: Programa de Rádio-->
 44
 45       <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"/>
 50
 51       <mx:TileList id="musicas_tl" itemRenderer="itemListaMusicas"/>
 52
 53 </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 3.1.3. São

      eles:

              Accordion

              TabNavigator
                                             102
          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
   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
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
                                                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)


                                                                          <3>

                                                            UID ver DJ




                                                          106
                             MODELAGEM CONCEITUAL

  O diagrama de classes conceituais completo está no Anexo 8.2




                                                                   Programa de Rádio

                            DJ
                                                                    nome
                                       1           0..*
                                                                    data
                 perfil                                             tempo
                 foto                      cria                     som




                             PROJETO NAVEGACIONAL



        Programa de Rádio                                     DJ

   nome: String                                            nome: String
   data: String                                            perfil: Text
   tempo: String                                           foto: Imagem
   som: Audio                                              programas: nome, data de Programas por DJ
   NomeDJ: nomeDJ de DJ por Programa




                                           Programa de Rádio                       DJ

                            nome                  por nome                                por nome

Radio                                              por data
                            data
                                                  por DJ
                            DJ




                                             107
                                                                      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)                   fotoDJ: foto de DJ                                 proximo: anchor(programa por NOME)
                         anterior: anchor(programa por DATA)                  idxProgramas: nome, data de                        anterior: anchor(programa por NOME)
                                                                                          Programas por DJ
                                                                              proximo: anchor(programa por DJ)
                                                                              anterior: anchor(programa por DJ)




                                               PROJETO DE INTERFACE ABSTRATA
    ADV Primário


                                              ADV Programa de Rádio                                                          ADV DJ
                                              C       mx:Panel                                                               C     mx:Panel


                                                     nome                         som                                            nome                            foto
                                                         mx:Label                 @          mx:Button                                mx:Label                          mx:Button

                                                     data                                                                         perfil
                                                         mx:Label                                                                     mx:Label

                                                     tempo
                                                                                                                                  ADV idxProgramasDJ
                                                         mx:Label
                                                                                                                                  C    mx:TileList
                                                     nomeDJ
                                                     @   mx:LinkButton




ADVs Secundários




ADV Programa de Rádio por Data                                        ADV Programa de Rádio por DJ                                            ADV Programa de Rádio por Nome
C       mx:Panel                                                      C       mx:Panel                                                        C       mx:Panel


    data                                                                  fotoDJ                                                                     anterior                 próximo
    1      mx:DateChooser                                                        mx:DateChooser                                                   @     mx:LinkButton         @     mx:LinkButton


    anterior                     próximo                                  anterior                       próximo
    @    mx:LinkButton           @   mx:LinkButton                        @    mx:LinkButton             @   mx:LinkButton



                                                                          ADV idxProgramasDJ
                                                                          C    mx:TileList




                                                                                                  108
   ADVs Opcionais




                                                   ADV idxProgramasDJ
                                                   C   mx:TileList
                                                                 isRepeated

                                                        itemListaProgramasDJ
                                                        C       mx:canvas


                                                            nome
                                                            @     mx:Label

                                                            Data
                                                            @     mx:Label




   ADVs Especiais




                    ADV índiceProgramaNome         ADV índiceProgramaData       ADV índiceProgramaDJ
                    C   mx:TileList                C   mx:TileList              C   mx:TileList
                                  isRepeated                     isRepeated                isRepeated


                         itemListaProgramaNome          itemListaProgramaData        itemListaProgramaDJ
                         C       mx:canvas              C       mx:canvas            C    mx:canvas


                             nome                               Data                      nomeDJ
                             @     mx:Label                  @       mx:Label            @        mx:Label


                             Data                               nome                      Data
                                   mx:Label                          mx:Label
                                                                                                  mx:Label

                             nomeDJ                             nomeDJ                    nome
                                   mx:Label                          mx:Label                     mx:Label




                                                 IMPLEMENTAÇÃO.

classes navegacionais

       ProgramaRadio.as
       ProgramaRadioData.as
       ProgramaRadioNome.as
       ProgramaRadioDJ.as

interfaces

    UIProgramaRadio.mxml
    UIIndicesRadio.mxml

componentes

    ListaProgramaPorDJ.mxml

controladores

    CTRLProgramaRadio.as

banco de dados

    DBProgramaRadio.php


                                                                  109
6 Considerações Finais

    Neste trabalho o método OOHDM foi estendido 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
    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
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 estendido.

     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
7 Bibliografia

COENRAETS, C. An overview of MXML: The Flex markup language. Adobe - Developer
Center. 2003. disponível em <http://www.adobe.com/devnet/flex/articles/paradigm.html>
Acesso em: 03 Abr. 2008.

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, 1993.

GAY, J. Macromedia - Showcase: History of Flash. 2008. disponível                  em
<http://www.adobe.com/macromedia/events/john_gay>. Acesso em: 18 abr. 2008.

KOCH, N. A Comparative Study of Methods for Hypermedia Development. Universidade
Ludwig-Maximilians de Munique, Alemanha, 1999.

LIMA, F; SCHWABE, D. Application Modeling for the Semantic Web. Puc-Rio, Brasil,
2003.

MOOCK, C. Essencial ActionScript 3.0. 2007.

MOURA, S. Desenvolvimento de Interfaces Governadas por Ontologias para web
Semântica. PUC-Rio, Brasil, 2004.

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. 2005 disponível em
<http://www.tecweb.inf.puc-rio.br/oohdm/space/summary+of+OOHDM>. Acesso em: 25
mar. 2008.

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. 207-225, 1998.

VILAIN, P. Modelagem da Interação com o Usuário em Aplicações Hipermídia.
Tese de Doutorado. PUC-Rio, Brasil, 2002.

VILAIN, P.; SCHWABE, D.; de SOUZA, C.S. A Diagrammatic Tool for Representing User
Interaction in UML Puc-Rio, 2000.

ADOBE. Adobe - Flex 3 - Overview. 2008a. disponível em
<http://www.adobe.com/products/flex/overview/> . Acesso em: 15 mai. 2008.



                                          113
ADOBE. Adobe – Flash Player: PC Penetration. 2008b. disponível em
<http://www.adobe.com/products/player_census/flashplayer/PC.html/> . Acesso em: 5 jun.
2008.

Flash Magazine1 > News. Flash Magazine. 2000. disponível em
<http://www.flashmagazine.com/news/detail/the_flash_history/> . Acesso em: 20 mar. 2008.




                                          114
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 email de confirmação do prazo de entrega das camisetas.




                                           115
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 email 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
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
                                                                                      Diagrana de UIDs
             UID
          Fazer Login




                                                                                                            opções
                                                                                                        de administração
                                                                                                                                                                               inserir/
                                                             fazer                                                                                                       apagar/editar modelo
                                                           cadastro


                                                                                                                                                                                inserir/
       opções do sistema                                                                                                                                                 apagar/editar estampa

                                                                                                                                           administrar camisetas


                                                                                                                                                                           administrar vitrine
                                                      montar camisetas




                                        ver vitrine
                                                                                                                                             administrar rádio

                                                              ver                                                                                                                inserir/
                                                                                                                                                                         apagar/editar programa




118
                                                       detalhes camiseta
                                                                                                                                                                                de rádio

                                                                                     ver
                           usar loja comum                                  carrinho de compras                                                                                  inserir/
                                                                                                                                                                         apagar/editar programa
                                                              ver                                                                                                               de rádio
                                                       detalhes produto

                                                                                                                                                                                inserir/
                                                                                                                                                                          apagar/editar usuário

                      Pesquisar Rádio
                                                          ver                                                                  administrar usuários
                                                  detalhes Programa
                                                                                                                                                                                                  8.2 Diagrama de UIDs para a aplicação de exemplo




                                                       de Rádio
                                                                                                                                                                                inserir/
                                                                                                                                                                          apagar/editar usuário
              ver
      galeria multimídia
                                                                  ver
                                                              detalhes DJ
                                                                                                                     administrar loja                        pesquisar compras


                                                                                              administrar galeria
                                                                                                 multimídia
119
                                                                                                Diagrama de Classes Conceituais



                                        CamisetaPersonalizada                                                               Comprador                                    Compra                                Produto         0..*

                                        código                         0..*              monta                    0..1   tipo                                                                             nome
                                 0..*                                                                                                         1          0..*        data             0..*     1..*
                                                                                                                         cpf/cnpj                                    valor Total                          preço
                                                                                                                         rg                                                                                                    0..*
                                                                                                                         sexo                     faz                                 inclúi
                                                                                                                         data nascimento                                                                                       relaciona com
                                                                                                                         endereço
                                                                                                                         CEP
      contém                                  1..*                                                                       cidade
                                                                                                                         estado
                                                     contém                                                              país
                                                                                                                         telefone
                1                                1                                                                                                                                                         ProdutoComum
           Modelo                             Estampa
                                                                                     Artista Gráfico                                                                                                      descrição
                                         desenho                                                                              Usuário                                 Administrador                       estoque
      tipo                                                      0..*            1                                                                                                                         foto
      imagem                             número de cores
      preço                              cores padrão                               descrição
                                         categoria de preço              cria       homepage                              nome
                                                                                    foto                                  sobrenome
                                                                                                                          email
                                                                                                                          senha

                                             0..*




120
         0..*


      é tingido                                      contém
      de

            1                                1..4

          Cor Tecido                         Cor Tinta

      número comercial                   número CMYK
                                                                                                                         Programa de Rádio

                                                                                                DJ                                                contém                    Música                                Intérprete
                                                                                                                          nome
                                                                                                       1          0..*                        0..*            1..*                      1..*          1
                                                                                                                          data
                                                                                       perfil                             tempo                                                                             nome
                                                                                       foto                cria                                                        nome             executada
                                                                                                                          som
                                                                                                                                                                                        por


                               Cor

                         nome                                                                                                                      Playlist
                         valor RGB

                                                                                                                                             ordem
                                                                                                                                                                                                                                               8.3 Diagrama de Classes conceituais da aplicação de exemplo
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:ConcreteInterfaceElement.

cwo:Label
      a      cwo:ConcreteInterfaceElement.

cwo:ProgressBar
      a     cwo:ConcreteInterfaceElement.

cwo:Text
      a      cwo:ConcreteInterfaceElement.

cwo:ToolTip
      a     cwo:ConcreteInterfaceElement.

cwo:videoDisplay
      a     cwo:ConcreteInterfaceElement.
//------------------------------------------------------------------------


:IndefiniteVariable
                                     121
      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:ConcreteInterfaceElement.

cwo:VSlider
      a     cwo:ConcreteInterfaceElement.

cwo:NumericStepper
      a     cwo:ConcreteInterfaceElement.

//------------------------------------------------------------------------


                                    122
: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:ConcreteInterfaceElement.

cwo:VSlider
      a     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:ConcreteInterfaceElement.

cwo:VSlider
      a     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:ConcreteInterfaceElement.

cwo:VSlider
                                     123
      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:ConcreteInterfaceElement.

cwo:VSlider
      a     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
                             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.


//------------------------------------------------------------------



8.5 Interface Visual de Componentes MXML
Container MXML      Apresentação Visual




                                      125
Accordion




ApplicationControlBar



HBox




Canvas




                        126
ControlBar




Form




Grid




Panel




             127
TabNavigator




ViewStack




     Control MXML         Apresentação visual


Button




ButtonBar


CheckBox



ColorPicker




ComboBox




                    128
DataGrid




DateChooser




DateField




HorizontalList




HSlider / VSlider




Image               imagem (jpg, gif ou png)



                                   129
Label        Label


LinkBar




LinkButton




List




Menu




MenuBar




                     130
NumericStepper




PopUpButton




PopUpMenuButton




ProgressBar




RadioButton


RadioButtonGroup




TabBar



Text




                   131
TextArea




TextInput



TileList




ToggleButtonBar


ToolTip




Tree




                  132

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:71
posted:12/13/2011
language:Portuguese
pages:132