UNIVERSIDADE FEDERAL DE SANTA CATARINA UFSC CENTRO TECNOLGICO CTC DEPARTAMENTO DE INFORMTICA E ESTATSTICA INE CURSO DE CINCIAS DA COMPUTAO

Extenso do mtodo OOHDM para publicao de aplicaes hipermdia em Flex

Pedro Germani Ghiorzi

Prof. Orientadora: Patrcia Vilain

Trabalho de concluso de curso apresentado como parte dos requisitos para obteno do grau de Bacharel em Cincias da

Computao

FLORIANPOLIS, 2008/1

Pedro Germani Ghiorzi

Extenso do mtodo OOHDM para publicao de aplicaes hipermdia em Flex

Trabalho de concluso de curso apresentado como parte dos requisitos para obteno do grau de Bacharel em Cincias da Computao

_________________________________ Orientadora: Patrcia Vilain

Banca examinadora ________________________________ Leandro Jos Komosinski __________________________________ Ricardo Pereira e Silva

Florianpolis, Junho de 2008

DEDICATRIA (S) ( opcional ):

folha seguinte

AGRADECIMENTO (S) ( opcional ): folha seguinte

SUMRIO
1 2 INTRODUO

.................................................................................... 10

HIPERMDIA E OOHDM. ........................................................................ 14 2.1 HIPERMDIA ........................................................................................................... 14 2.2 OOHDM............................................................................................................... 17 2.3 ETAPAS DO MTODO OOHDM ............................................................................... 19 2.3.1 Anlise de requisitos ........................................................................................ 19 2.3.2 Modelagem conceitual ..................................................................................... 22 2.3.3 Projeto de navegao ...................................................................................... 24 2.3.4 Projeto da interface abstrata ............................................................................ 28 2.3.5 Implementao ................................................................................................ 41

FLEX E FLASH

................................................................................... 43

3.1 FLEX .................................................................................................................... 43 3.1.1 Verses lanadas e features associadas ......................................................... 44 3.1.2 Linguagens de programao. .......................................................................... 46 3.1.3 Criao de interfaces no Flex .......................................................................... 51 3.2 FLASH .................................................................................................................. 70 4 A PROPOSTA ..................................................................................... 74 4.1 4.2 4.3 4.4 5 6 EXTENSO 1 - ESPECIFICAO DOS WIDGETS ABSTRATOS ....................................... 76 EXTENSO 2 - ESPECIFICAO DOS WIDGETS CONCRETOS MXML .......................... 81 EXTENSO 3 - ESPECIFICAO DE ADVS PARA FLEX ............................................... 93 EXTENSO 4 - ESPECIFICAO DE VIEW STATES DO FLEX ........................................ 97

MODELAGEM DE APLICAO OOHDM FLEX ....................................... 104 CONSIDERAES FINAIS ................................................................... 109 TRABALHOS FUTUROS..................................................................................................... 111

7 8

BIBLIOGRAFIA ................................................................................. 112 ANEXOS 8.1 8.2 8.3 8.4 8.5

......................................................................................... 114

CASOS DE USO DA APLICAO DE EXEMPLO .......................................................... 114 DIAGRAMA DE UIDS PARA A APLICAO DE EXEMPLO ............................................ 117 DIAGRAMA DE CLASSES CONCEITUAIS DA APLICAO DE EXEMPLO......................... 118 REGRAS DE CONSISTNCIA ONTOLOGIA DE WIDGETS CONCRETOS ESTENDIDA ....... 119 INTERFACE VISUAL DE COMPONENTES MXML ...................................................... 123

LISTA DE FIGURAS
Figura 2.1- UID Pesquisar Rdio .......................................................................................................... 22 Figura 2.2 Diagrama de Classes Conceituais.................................................................................... 23 Figura 2.3 Diagrama de Classes Navegacionais ............................................................................... 25 Figura 2.4 - Diagrama de Contextos Navegacionais ............................................................................ 26 Figura 2.5- Classes "emContexto" do nodo navegacional "Programa de Rdio" ................................ 27 Figura 2.6 - Diagrama de Classes da Ontologia de Widgets Abstratos ............................................... 31 Figura 2.7 - Regra de consistncia de Mapeamento Concreto ............................................................ 39 Figura 2.8 Abstract Data View para Programa de Rdio ................................................................... 41 Figura 3.1 - Esquema de publicao de aplicaes Flex. ................................................................... 46 Figura 3.2 Esquema de publicao de Aplicaes Flex .................................................................... 49 Figura 3.3 Exemplo simples de aplicao Flex ................................................................................. 51 Figura 3.4 - Dois estados de uma aplicao. esquerda, o base state e direta, o estado "Registro" .............................................................................................................................................................. 55 Figura 3.5 Tela do Future Splash Animator ....................................................................................... 72 Figura 4.1 Esquema simplificado do processo do mtodo OOHDM ................................................. 74 Figura 4.2 Esquema do processo OOHDM estendido para criao de sistemas Flex. .................... 75 Figura 4.3 - Classes da Ontologia de Widgets Abstratos extendida .................................................... 79 Figura 4.4 - Exemplo de interface para seleo mltipla em um intervalo finito .................................. 80 Figura 4.5 - Sobreposio das classes de widgets abstratos............................................................... 92 Figura 4.6 Legenda da representao da classe de widgets abstratos nos ADVs ........................... 94 Figura 4.7 - Exemplo Estrutura do cabealho dos ADV Flex ............................................................... 94 Figura 4.8- Mapeamento de entidades navegacionais para ADVs ...................................................... 95 Figura 4.9 - ADV Programa de rdio .................................................................................................... 96 Figura 4.10 - Diagrama de ADVs .......................................................................................................... 99

LISTA DE CDIGOS-FONTE
Cdigo Fonte 3.1 - Exemplo de Aplicao MXML ............................................................... 50 Cdigo Fonte 3.2 - Exemplo de aplicao MXML + ActionScript ......................................... 50 Cdigo Fonte 3.3 - Exemplo de implementao de view states .......................................... 53

LISTA DE TABELAS
Tabela 2.1 - Etapas do Processo OOHDM.......................................................................... 18 Tabela 4.1 Mapeamento de elementos dos UIDs para a Ontologia de Widgets Abstratos . 77 Tabela 4.2- Exemplo de definio de widgets abstratos...................................................... 80 Tabela 4.3 - Definio de widgets concretos MXML a partir dos widgets abstratos ............. 93

1 Introduo
As aplicaes de internet se tornam a cada dia mais avanadas e complexas, aumentando seu alcance na combinao de elementos multimdia e incorporando novas tecnologias rapidamente. O Adobe Flex um ambiente de desenvolvimento de aplicaes ricas de internet (rich internet applications - RIAs) que publica aplicaes que so executadas no Adobe Flash Player, hoje em dia um dos softwares com maior penetrao nos computadores ligados internet (ADOBE, 2008b). Com a criao da linguagem orientada a objetos ActionScript 3.0, as aplicaes Flash1 deixam de ser apenas elementos componentes de um sistema

HTML, por exemplo, e passam a ser poderosas solues para a criao da aplicao como um todo. Apesar de se tornarem mais completas e de serem largamente utilizadas o que se v que atualmente a grande maioria das aplicaes publicadas na plataforma Flash feita de maneira ad hoc e sem nenhum planejamento adequado para prover recursos como reusabilidade e manuteno. Com o intuito de melhorar o desenvolvimento em Flex de sistemas hipermdia, isto , sistemas que trabalham com informaes que so colees de nodos multimdia (textos, vdeos, imagens, animaes vetoriais e outras mdias) interligados atravs de uma estrutura de navegao que permite ao usurio fazer uma incurso no-linear pelo sistema, h a necessidade de um mtodo de modelagem que incorpore, alm dos aspectos normalmente modelados pelos mtodos tradicionais, questes relativas navegao e tambm criao de interfaces complexas e personalizadas. Em estudo no qual faz comparaes dos mtodos hipermdia, Koch, (1999, p. 2) comenta que normalmente os mtodos tradicionais de modelagem no consideram o projeto de navegao como um processo separado do projeto de interfaces com o usurio.

Como sero denominadas as aplicaes que executam no Flash Player criadas no Flex ou no Flash IDE

10

Como mtodo direcionado para o desenvolvimento de sistemas hipermdia, pode-se citar o Object Oriented Hypermedia Design Method (OOHDM) (SCHWABE; ROSSI, 1998). O OOHDM um mtodo que apresenta todas as etapas necessrias para o projeto de um sistema hipermdia permitindo, inclusive, o projeto de interfaces com o usurio de maneira abstrata. Ele um mtodo iterativo composto de 5 etapas principais (Anlise de Requisitos, Modelagem Conceitual, Projeto de Navegao, Projeto de Interface Abstrata e Implementao), cada uma delas executada iterativamente, sempre refinando o resultado a cada nova iterao.

OBJETIVO GERAL Este trabalho tem como objetivo adaptar o mtodo OOHDM para o desenvolvimento de sistemas hipermdia em Flex, permitindo tambm uma flexibilidade na incorporao de novos componentes de programao na medida em que o desenvolvedor utiliza o mtodo.

OBJETIVOS ESPECFICOS 1. Estudo do mtodo OOHDM, a fim de estabelecer uma compreenso aprofundada sobre o mtodo; 2. Estudo sobre o desenvolvimento de interfaces e aplicaes orientadas a objeto no Flex; 3. Proposta de adaptao do mtodo OOHDM para que as etapas de Projeto de Interface Abstrata, e de Implementao sejam direcionadas para o

desenvolvimento de aplicaes hipermdia em Flex; 4. Utilizao do mtodo OOHDM e da adaptao proposta neste trabalho no desenvolvimento de um prottipo implementado em Flex.

11

JUSTIFICATIVA Durante o projeto de uma aplicao hipermdia em Flex preciso descrever o comportamento dos objetos navegacionais e de interface com o usurio de maneira facilitar o mapeamento para o cdigo MXML.Entretanto, adequado que o projeto de navegao e o projeto da interface sejam realizados separadamente, pois o primeiro independente do segundo. Esta separao propcia para diminuir a dificuldade de comunicao entre o desenvolvedor e o desenhista grfico da aplicao, podendo estes se relacionar de maneira a evitar ambigidades no processo de desenvolvimento devido s representaes esquemticas geradas nas etapas do mtodo OOHDM, portanto, existe a necessidade de um mtodo direcionado para o desenvolvimento de aplicaes hipermdia em Flex para tornar este desenvolvimento mais eficiente.

O trabalho est organizado como segue. O segundo captulo do trabalho comenta de maneira introdutria os conceitos de hipermdia, seguidos pela descrio detalhada sobre o mtodo OOHDM, suas etapas e processos envolvidos. O terceiro captulo apresenta o ambiente de desenvolvimento do Flex, suas linguagens e faz uma anlise do comportamento dos componentes de interface MXML encontrados na especificao das classes da linguagem ActionScript 3.0. O quarto captulo apresenta propostas de extenses ao mtodo OOHDM para facilitar a construo de sistemas hipermdia utilizando o Flex como ambiente de programao. Tambm so sugeridas algumas dicas de implementao utilizando algumas tcnicas ou componentes especficos do Flex.

12

O quinto captulo mostra um exemplo de aplicao hipermdia desenvolvido em Flex utilizando o mtodo OOHDM e as extenses propostas neste trabalho. O sexto captulo apresenta as consideraes finais sobre o processo de pesquisa deste trabalho e sugere alguns trabalhos futuros.

13

Hipermdia e OOHDM.

2.1 Hipermdia

Hipermdia 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 prope uma estrutura de dados para especificao de sistemas de gerenciamento de informaes (Xanadu), em que todos os documentos gerados mundialmente fossem concentrados em um sistema de informao, e faz uma anlise das implicaes que sistemas como estes teriam na sociedade na poca. Hoje em dia o termo utilizado como uma extenso do termo hipertexto, significando o tipo de sistema de informao que agrega diferentes tipos de mdia. Neles encontramos textos, imagens, vdeos, sons, ncoras provenientes do hipertexto e outros elementos de navegao e acesso a itens de dados que proporcionam uma interao no-linear do usurio com o sistema. Analisando este contexto, Vilain (2002) constata que:
Atualmente, as aplicaes tradicionais baseadas em sistema de informao, quando implementadas na WWW, tambm incorporam o conceito de navegao entre suas informaes (nodos navegacionais). Entretanto, os mtodos usados durante o desenvolvimento de aplicaes tradicionais no so suficientes para modelar a navegao, principalmente quando a quantidade de nodos nos quais o usurio navega grande. Esses mtodos no abordam todos os aspectos relacionados com a navegao e geralmente no dissociam a navegao da interface com o usurio.

14

Para Zhang (2004, p. 2)

[...] existem 4 regras principais para determinar se um sistema pode ser considerado de hipermdia: 1. Uma grande quantidade de informao organizada em fragmentos

igualmente numerosos; 2. 3. Os fragmentos se inter-relacionam; O usurio precisa de apenas uma pequena parte da informao num

dado momento; 4. A aplicao computer-based.

Segundo Koch (1999) ainda estamos no comeo do aprendizado de como desenvolver grandes sistemas de hipermdia. Ela nos coloca que os sistemas de CD-ROMs ou sistemas WEB esto sendo construdos de maneira ad hoc e, portanto, sem um planejamento adequado, o que faz com que logo se tornem insustentveis no que diz respeito manuteno dos recursos e atualizao de funcionalidades. O desenvolvimento de sistemas de grande porte requer um controle maior por parte dos desenvolvedores, pois so originados em ambientes que envolvem um grande nmero de recursos e pessoas, como: programadores, desenhistas, publicitrios, autores de contedo e assim por diante. Assim como no desenvolvimento de outros tipos de software, existem alguns mtodos propostos especificamente para o projeto de sistemas hipermdia, que se focalizam em questes habituais de um projeto computacional e tambm em como fazer a anlise da navegao do usurio em sua incurso pelo sistema. Entre estes mtodos existe o chamado Hypermedia Design Method (HDM), criado por Schwabe, Garzotto e Paolini. O HDM (Hypermedia Design Method) foi um dos primeiros

15

mtodos que definiu a estrutura e interao nas aplicaes hipermdia. Segundo Garzotto et al. (1993):
Para controlar a potencial exploso no nmero de links, uma aplicao hipermdia na verdade no interconecta tudo, mas sim tenta diretamente interconectar apenas as partes mais importantes e significativas da informao para transmitir o significado global de maneira mais natural.

A partir desta afirmao possvel perceber que a preocupao de projetar sistemas mais complexos estava em como organizar os dados de maneira que a experincia do usurio e o funcionamento do sistema fossem melhores. Por uma melhor experincia do usurio entende-se a capacidade de este se familiarizar com a interao com o sistema a fim de permitir o rpido e preciso acesso s informaes providas e na capacidade do sistema de prover diferentes tipos de informaes, ricas para o usurio. J por um melhor funcionamento do sistema entende-se a possibilidade de este sistema ser de manuteno fcil, e por suportar um volume maior de trfego de informaes dos mais variados tipos sem perder a propriedade de ser altamente confivel. Nos sistemas tradicionais, a navegao no era considerada uma parte integrante da abstrao feita para a construo dos modelos e projeto do sistema, mas sim parte das operaes de interface entre usurio e o sistema. O reconhecimento desta necessidade de se separar a elaborao da navegao da interface surge no incio da dcada de 1990 com os primeiros estudos de modelagem para sistemas Hipermdia. Desde ento, o conceito de navegao em hipermdia est diretamente relacionado com vises do modelo conceitual, especificando de maneira relacional quais elementos de navegao sero percebidos pelo usurio a cada estado do sistema.

16

2.2 OOHDM

O mtodo Object-Oriented Hypermedia Design Method (OOHDM) um mtodo de desenvolvimento de sistemas hipermdia criado por Schwabe e Rossi (1996). Este mtodo utiliza de conceitos da modelagem orientada a objetos como abstrao e composio para prover uma descrio completa, complexa e concisa dos itens de dados ou informaes e a separao entre a modelagem conceitual do sistema da modelagem navegacional, especificando padres de navegao e transformaes da interface.
OOHDM considera o processo de desenvolvimento da aplicao hipermdia como um processo de quatro atividades, Anlise do domnio (Anlise de requisitos e Modelagem Conceitual), Projeto navegacional, Projeto de interface abstrata e Implementao desempenhadas em uma mistura de estilos iterativos e incrementais de desenvolvimento; em cada etapa um modelo construdo ou enriquecido. (Rossi, 1996, p. 13).

Cada etapa est relacionada com uma determinada questo de projeto, e assim um modelo orientado a objetos construdo contemplando questes como reutilizao e poder de abstrao. De acordo com (LIMA; SCHWABE, 2003, p. 4), enquanto a modelagem conceitual reflete os comportamentos e objetos do domnio da aplicao, o projeto navegacional foca em questes relativas organizao do espao navegacional, e s tarefas e recursos do usurio. Os fundamentos da abordagem OOHDM segundo Schwabe e Rossi (1998, p.3) so: A noo de que os objetos de navegao so vises, analogamente s vises da base de dados, dos objetos conceituais; O uso de abstraes apropriadas para organizar o espao navegacional, com a introduo do conceito de contexto navegacional; A separao de questes de interface e questes de navegao; 17

A identificao explcita de que existem decises de projeto (design) que precisam ser feitas apenas quando da implementao.

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 Consideraes de Projeto Captura dos requisitos do domnio da aplicao

Anlise de Requisitos

Casos de uso, Anotaes

Cenrios, UIDs, Padres de Projeto.

Anlise de cenrios e casos de uso, Entrevistas, Mapeamento UID modelo conceitual Classificao, Agregao, Generalizao e Especializao Classificao, Agregao, Generalizao e Especializao

Modelagem Conceitual

Classes, Subsistemas, Relaes, Atributos Nodos, ncoras, Estruturas de acesso, Contextos navegacionais, Transformaes navegacionais

Modelo Orientado a Objeto, Padres de projeto. Vises Orientadas a objeto, State charts Orientados a objeto, Classes de contexto, Padres de Projeto, Cenrios centralizados no usurio.

Modela a semntica do domnio da aplicao Leva em conta perfil do usurio e tarefas relacionadas. nfase em aspectos cognitivos. Constri a estrutura navegacional da aplicao; Modela objetos perceptveis, implementando metforas escolhidas. Descreve interface de objetos navegacionais. Define o layout dos objetos de interface; Performance

Projeto Navegacional

Projeto de Interface Abstrata

Objetos de interface Abstrata, Respostas a eventos externos, Transformaes de interface

Abstract Data Views, Diagramas de configurao; ADV-Charts; Padres de projeto

Mapeamento entre objetos navegacionais e objetos perceptveis

Implementao

Aplicao executvel

Os suportados pelo ambiente de desenvolvimento

Os suportados pelo ambiente de desenvolvimento

18

2.3 Etapas do mtodo OOHDM

2.3.1 Anlise de requisitos
O primeiro passo para a construo de um sistema, de acordo com o mtodo OOHDM a analise e aquisio dos requisitos que iro determinar as funcionalidades e comportamentos do sistema a ser projetado. Primeiramente, o projetista identifica os atores que iro fazer parte do funcionamento e utilizao do sistema, e as aes que estes atores devem ou podem tomar. Neste processo, criada uma srie de artefatos de projeto. Os casos de uso so artefatos criados a partir da anlise dos requisitos. Seu contedo formado por aes do processo de interao e comunicao entre o usurio e o sistema, como as que o usurio deve ou pode realizar e que resposta o sistema ter que fornecer, porm, so suprimidas questes relativas implementao e interface, delegando estas questes para outras etapas do e centralizando as atenes para o domnio real. Neles, a maneira de representar esta interao est concentrada em descries textuais desenvolvidas a partir de conversas entre pessoas e tambm com e anlise do domnio da aplicao. Em seguida, os cenrios so determinados para cada tarefa de cada ator. Estes cenrios so coletados para se construir os casos de uso, os quais so complementados por diagramas de interao entre o usurio 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 captulos do trabalho) que um sistema de uma Estao de Rdio on-line, na qual acontecem programas de rdio ao vivo periodicamente, mas o usurio tem a opo de pesquisar os programas exibidos anteriormente. O caso de uso a seguir representa a busca por informaes nesta rdio. 19

Caso de Uso: Pesquisar a radio Atores: Comprador Descrio: O usuario tem a opo de selecionar o programa de rdio que deseja estar ouvindo dentre todos os programas j realizados. Aqui, pode obter informaes sobre o programa atual (ao vivo) e os programas anteriores da radio, como playlist, informaes sobre o DJ, os artistas e as musicas. O usurio pode ver os programas de um determinado DJ, todos os programas por data, todos os programas por nome ou ver informaes sobre um DJ.

Os casos de uso podem ser descritos extensivamente para que a obteno dos dados seja mais precisa, especificando informaes relativas diretamente a aes do usurio ou respostas do sistema. So criados os casos de uso expandidos. Caso de Uso Expandido: Pesquisar a radio Aes do Ator 1. O usurio opta por pesquisar a radio Resposta do sistema 2. O sistema exibe a lista de programas organizada por data de exibio, so exibidos os atributos data do programa, nome do programa e nome do DJ. 4. O sistema exibe nome do programa, o nome do DJ que criou este programa, a data de exibio e a lista das musicas que foram exibidas neste programa.

3. O usurio escolhe um dos programas

5. O usurio pode navegar para o prximo programa ou programa anterior por data de exibio. O usurio pode selecionar o DJ ou alguma das musicas para visualizar os dados especficos destes objetos. 6. O usurio pode navegar entre os 7. programas e tocar o escolhido. Nota: 6. Quando o usurio navega entre os programas, no alterado o estado do som, ou seja, o programa que esta tocando no para at que um novo programa seja executado. A partir dos dados descritos nos casos de uso, so construdos os UIDs. Este processo se d em um conjunto de 6 passos (VILAIN et al, 2000, p.5):

20

1. Identificao dos itens de dados trocados entre usurio e sistema; 2. Separao dos dados em estados de interao. Dados que dependem de outros dados ou de opes selecionadas so colocados em estados distintos; 3. Os itens de dados so separados em entre entradas de usurio ou sadas do sistema. 4. Os estados de interao so conectados por transies de acordo com a dependncia dos dados 5. As operaes do usurio so identificadas como opes associadas s transies; 6. So adicionadas notas textuais que especificam requisitos no funcionais. Os UIDs esto baseados em diagramas grficos que exibem claramente que tipo de informao est sendo trocada entre o usurio e o sistema, como por exemplo, quais tipos de entradas de dados do usurio so obrigatrias ou opcionais. Isso faz com que a ambigidade e erros de interpretao sejam diminudos, tornando o emprego dos UIDs um mtodo eficaz no entendimento e tratamento da funcionalidade do sistema a partir do ponto de vista da relao usurio-sistema. Eles validam as interaes entre estas duas entidades criando um ambiente de planejamento mais slido e confivel. O UID da Figura 2.1 representa as informaes do caso de uso pesquisar a Rdio:

21

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

As elipses representam estados de interao, e os elementos internos a ela as estruturas e itens de dados. As setas representam as transies de estado e os textos associados a cardinalidade e as operaes do usurio. Os UIDs ento so validados pelo projetista em conjunto aos atores, e aprimorados se necessrio.

2.3.2 Modelagem conceitual

Durante esta etapa do processo, construdo o artefato diagrama de classes conceituais, mostrando as classes e relaes entre elas de acordo com a anlise do domnio da aplicao. As classes so descritas da mesma maneira como se faz utilizando modelos UML, porm com algumas caractersticas especficas nos atributos: eles podem ser de vrios tipos (no-fortemente-tipados, representando diferentes perspectivas da entidade equivalente no mundo real), e podem ter enumeraes especficas (valores determinados possveis para tal atributo). As relaes entre as classes tambm so descritas de acordo com os modelos UML. 22

A partir dos UIDs possvel se extrair dados para a construo 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 operaes associadas a interaes nos UIDs podem ser mapeadas para operaes nos mtodos destas classes que esto diretamente ligados ao domnio da aplicao a ser construda. Os dados tambm podem ser extrados dos textos dos casos de uso

A seguir exibido um diagrama de classes parcial extrado do UID Pesquisar rdio (Figura 2.2)

Programa de Rdio nome: String data: String tempo: String som: Audio 1 1..*

Musica nome: String Artista: String

cria playlist DJ nome: String perfil: Text foto: Imagem ordem: Numero

Figura 2.2 Diagrama de Classes Conceituais

23

2.3.3 Projeto de navegao

Nesta etapa do OOHDM descrita a estrutura de navegao da aplicao hipermdia o que representa as vises dos objetos conceituais que o usurio ter acesso e as conexes entre os objetos. Esta estrutura organizada em termos de contextos navegacionais, os quais so obtidos a partir de classes de navegao, como nodos, ncoras, ndices e guias. Os contextos navegacionais levam em conta os tipos de usurios e suas tarefas. Os nodos representam vises (views) lgicas das classes conceituais definidas durante a anlise do domnio da aplicao, ou seja, diferentes modelos navegacionais podem ser construdos para um mesmo esquema conceitual, expressando diferentes vises sobre o mesmo domnio. ncoras so derivadas das relaes conceituais definidas no processo de anlise de requisitos e permitem ao usurio transitarem de um n a outro, em sua incurso pelo sistema. A Figura 2.3 representa as classes (nodos) navegacionais Programa de Rdio e DJ. A transio 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 Rdio, pois o nodo musica nunca ser alcanado por usurios j que sempre que este ver os dados sobre as musicas, estar vendo em um contexto maior o programa de rdio que contm estas msicas. As classes navegacionais so representadas com um quadrado vazio no canto superior direito.

24

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

DJ nome: String perfil: Text foto: Imagem programas: nome, data de Programas por DJ

Figura 2.3 Diagrama de Classes Navegacionais

Definindo a semntica navegacional a partir de nodos e ncoras, possvel modelar a movimentao no espao navegacional, criando a possibilidade de o usurio poder apenas ter acesso a determinados atributos nodos independente da modelagem conceitual (como por exemplo, apenas usurios do tipo DJ podem ter acesso a estruturas de edio dos atributos dos programas de rdio. Levando em considerao a afirmao de que objetos navegacionais so vises (views) dos objetos conceituais, conclui-se que os objetos navegacionais especificam quais informaes dos objetos conceituais devem ser processadas e quais as possveis interaes de navegao entre elas, de acordo com as tarefas do usurio que devem ser suportadas pelo sistema. Durante este passo, definimos os itens de dados que sero manipulados pelo usurio levando em conta o que vai ser processado e no 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 alcanados pelo usurio (nodos ou objetos navegacionais); Que relaes existem entre estes nodos (os links); 25

Em qual conjunto de objetos o usurio navegar (os contextos navegacionais); De que maneira estes dados sero acessados (as estruturas de acesso); Quais diferentes contedos devem ser apresentados para o usurio, dependendo do contexto em que ele est navegando.

As principais primitivas navegacionais OOHDM ento so 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 navegveis do sistema de acordo com vises sobre os objetos conceituais, e o segundo as possveis navegaes entre estes objetos navegveis. O modelo navegacional pode evoluir independentemente do modelo conceitual, simplificando a manuteno do conjunto de fatores que determinam a navegao. A Figura 2.4 exibe uma parte do esquema de contextos navegacionais.

Programa de Rdio nome data Radio DJ por nome por data por DJ por busca

DJ por nome

busca

Figura 2.4 - Diagrama de Contextos Navegacionais

Estes contextos so acessados atravs de ndices representados pelas caixas com bordas pontilhadas. As caixas hachuradas representam as classes navegacionais e os quadros internos os contextos navegacionais. 26

As classes emContexto so classes adicionadas ao modelo de classes navegacionais e que fazem o papel das diferentes vises que aquele determinado nodo ter em relao aos seus contextos. Por exemplo, o nodo Programa de Rdio pode ser navegado em 3 diferentes contextos, por Data, por DJ e por Nome. O primeiro a coleo dos Programas de rdio organizados em ordem de data de exibio, o segundo os programas criados por um determinado DJ, e o terceiro todos os programas de rdio por ordem alfabtica. 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 Rdio:
Programa de Rdio nome: String data: String tempo: String som: Audio NomeDJ: nomeDJ de DJ por Programa idxMusicas: nome, artista de Musica por programa

Programa de Rdio por DATA calendario:Calendario proximo: anchor(programa por DATA) anterior: anchor(programa por DATA)

Programa de Rdio por DJ idxProgramas: nome, data de Programas por DJ proximo: anchor(programa por DJ) anterior: anchor(programa por DJ)

Programa de Rdio por NOME proximo: anchor(programa por NOME) anterior: anchor(programa por NOME)

Figura 2.5- Classes "emContexto" do nodo navegacional "Programa de Rdio"

De acordo com Vilain (2002)

As classes em contexto podem ser vistas como decoradores. Elas so definidas para representar as diferentes informaes que os objetos podem apresentar quando forem acessados dentro de diferentes contextos

27

de navegao. As informaes comuns a todos os objetos de uma classe navegacional, independente dos contextos nos quais eles aparecem, so definidas no esquema de classes navegacionais. Portanto, uma classe em contexto s necessria se o n tem uma aparncia diferente e/ou ncoras distintas no contexto em questo.

Com os diagramas de contextos e classes navegacionais, pode-se dar incio ao projeto de interface abstrata.

2.3.4 Projeto da interface abstrata

A modelagem de uma interface abstrata construda definindo objetos perceptveis em termos de interface, como por exemplo, uma foto, uma caixa de seleo de valores, um mapa da cidade, entre outros. Estas classes so definidas como agregaes de elementos primitivos, como caixas de textos, botes, imagens, e tambm de maneira recursiva, utilizando outras classes de interface. Os objetos de interface so mapeados a partir dos objetos navegacionais do projeto de navegao, provendo assim uma aparncia perceptvel do sistema. O comportamento da interface declarado especificando como eventos externos ou gerados pelo usurio so tratados, e em como se d a comunicao entre a interface e os objetos navegacionais. Diferentemente da modelagem conceitual e do modelo navegacional, que determinam os elementos do domnio da aplicao e a maneira como o usurio completar suas tarefas, a Interface Abstrata existe para determinar os objetos navegacionais e a funcionalidade da aplicao que devem se perceptveis pelo usurio na interface da aplicao. Mesmo quando a interface percebida como uma parte externa do domnio da aplicao, em um nvel mais abstrato, pode ser considerada como mais uma das informaes trocadas entre o usurio e

28

o sistema, portanto a navegao entre os elementos interface se torna mais uma das funcionalidades da aplicao. Como as tarefas suportadas pela aplicao gerenciam essa troca de informao, 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 (informaes que devem ser trocadas) e implementao da mesma (layout, cores), estas ltimas dependentes das particulares configuraes de hardware e software que estaro rodando estas aplicaes. Esta separao nos permite criar modelagens protegidas das evolues tecnolgicas das diversas plataformas e tambm da necessidade de dar suporte aos vrios ambientes de hardware e software utilizados pelos usurios. Para o desenvolvimento da interface de um sistema baseado em OOHDM, pode-se se fazer o uso de tcnicas que descrevem as interaes entre o usurio e o sistema levando em conta que tipo de elemento de interao ser utilizado na implementao. Uma destas tcnicas, que ser expandida no Capitulo 4 do presente trabalho, chamada de Ontologias de Widgets de Interface2 (MOURA, 2004) descreve classes abstratas de interface que so mapeadas para os elementos de interao usurio-sistema. O nvel mais baixo de abstrao 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 interao, considerando as necessidades de trocas de informao entre o usurio e os elementos de navegao. Posteriormente, estes elementos abstratos, chamados de widgets e definidos pela Ontologia de Widgets Abstratos, so mapeados para uma estrutura de elementos concretos

Apesar de a ontologia de interface abstrata ter sido criada para dar suporte a conceitos da Web

Semntica e gerao automtica de interfaces, este trabalho utiliza apenas parte do conceito geral da ontologia, no que diz respeito criao de uma interface formalizada, em um sistema web.

29

levando em conta os aspectos especficos 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 questo fundamental o que isto?, portanto, trata de questes relativas ao mundo do real e no propriamente das representaes feitas pelo nosso pensamento. No contexto da computao, a palavra ontologia utilizada quando se quer fazer uma descrio de um determinado objeto de estudo, neste caso, os widgets de interface. Widget (um termo ainda sem traduo para o portugus) um elemento de interface com o qual o usurio pode interagir. Neste caso os widgets so abstratos, ou seja, so descritos modelos de interface especificando como os objetos navegacionais sero apresentados e quais elementos sero perceptveis para o usurio, sem expressar sua forma ou funcionamento. Posteriormente estes modelos so mapeados para uma ontologia mais prxima 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 aplicaes que precisam processar o contedo em vez de simplesmente exibi-los ao usurio. De certa maneira, isso significa que uma aplicao no s consegue buscar dados em seu prprio sistema, mas sim navegar (analogamente navegao em browsers na internet) por vrios sistemas a fim de colher dados que a permitam inferir novos dados, fazendo uma leitura semntica dos primeiros. A Ontologia de Widgets Abstratos composta de 11 conceitos (ver Figura 2.6), que representam os seus elementos. Estes elementos so comparveis s primitivas dos UIDs, pois oferecem suporte s mesmas interaes realizadas pelo usurio com o sistema, como 30

entradas de dados (itens de dado ou estruturas de itens de dados), sadas do sistema (itens de dado ou estruturas de itens de dados), e operaes realizadas pelo usurio. Acreditase que, atravs dos conceitos definidos nesta ontologia, possvel conseguir a representao de todas as interaes do usurio com o sistema. (MOURA, 2004). As classes dessa ontologia representam um ou mais elementos abstratos das interfaces das aplicaes hipermdia 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 possveis elementos abstratos. Estes elementos representam os possveis tipos de interaes entre o usurio e o sistema. 1. SimpleActivator: esta classe representa qualquer elemento capaz de reagir a eventos externos caso tpico do clicar o mouse que possua um evento associado a ele, tais como ativar um link, um boto de ao, o envio de um email, dentre outros 31

2. ElementExhibitor: esta classe representa elementos que exibem algum tipo de contedo, 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 usurio insira dados atravs do uso do teclado. Pode representar um campo de formulrio, ou seja, uma caixa de texto. O valor a ser capturado por esse elemento desconhecido a priori. PredefinedVariable: permite a seleo de um subconjunto a partir de um conjunto de valores predefinidos; muitas vezes, esse subconjunto poder ser unitrio. As especializaes dessa classe so: ContinousGroup: permite a seleo de um nico valor de um intervalo infinito de valores; DiscreetGroup: permite a seleo de um nico valor de um intervalo finito de valores MultipleChoices: permite a escolha de um ou mais elementos de um conjunto enumervel de valores; SingleChoice: permite a escolha de um nico elemento de um conjunto enumervel de valores. 4. CompositeInterfaceElement: representa uma composio dos elementos abstratos citados acima.

32

Note

que

as

classes

AbstractInterfaceElement,

VariableCapturer

PredefinedVariable no so instanciadas diretamente, mas sim atravs de suas subclasses. A ontologia tambm definida atravs de propriedades que qualificam os widgets abstratos, indicando atributos dos elementos de interface, como a qual estrutura de navegao eles esto relacionados, a qual estrutura da Ontologia de Widgets Concretos eles estaro sendo mapeados, entre outros. A lista completa de propriedades est representada abaixo.

I.

ObjectProperty: hasInterfaceElement: indica os elementos da classe AbstractInterfaceElement que compem os elementos do tipo CompositeInterfaceElement e

AbstratctInterface. Domnio: AbstractInterface ou CompositeInterfaceElement. targetInterface: indica qual ser a instncia da classe AbstractInterface a ser criada quando esse elemento for ativado. Essa instncia 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 sero usadas para a traduo de um elemento especfico. Esta 33

propriedade

opcional

para

todas

as

subclasses

da

classe

AbstractInterfaceElement. isRepeated: uma propriedade apenas do conceito CompositeInterfaceElement, que indica se os elementos que compem esse conceito iro ou no se repetir um nmero arbitrrio 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 funo indicar qual a tag que ir separar os elementos dessa composio, que se repetem. fromAnchor: indica qual a ncora descrita na ontologia navegacional, a qual a instncia de um elemento abstrato corresponde. fromContext: indica qual o contexto, descrita na ontologia navegacional, o qual a instncia de um elemento abstrato pertence; fromIndex: indica qual o ndice, descrito na ontologia navegacional, ao qual a instncia de um elemento abstrato se refere; fromAttribute: indica qual o atributo da ontologia navegacional correspondente instncia de um elemento abstrato; fromElement: indica qual o elemento da ontologia navegacional correspondente instncia de um elemento abstrato; visualizationText: representa um valor que ser apresentado pelo elemento concreto. Esta propriedade utilizada apenas nos conceitos ElementExhibitor e IndefiniteVariable.

34

2.3.4.2

Ontologia de Widgets Concretos

Utilizando-se dos elementos e primitivas da Ontologia de Widgets Abstratos, o processo de criao 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 atravs da linguagem OWL. Depois, com estas descries dos elementos abstratos, gerada outra descrio, desta vez mapeando cada elemento abstrato para um elemento concreto, que possu descries mais prximas das interfaces reais, considerando de maneira ainda rasa questes relativas ao ambiente em que ser desenvolvido o sistema. Para fazer esta descrio, Sabrina Moura (MOURA, 2004) sugere a utilizao de linguagens como XUL, LASZLO e outras. Estas linguagens esto bem mais prximas da interface concreta do que a proposta por Sabrina Moura, pois descrevem com certa preciso regras de consistncia que devem ser consideradas quando da implementao 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 captulo 4. Button: representa os elementos que possuem funes embutidas a

serem realizadas, como: submit e reset por exemplo. Essas funes so executadas quando esse elemento ativado, atravs do mouse ou do teclado; CheckBox: representa um tipo de boto que possui 2 estados:

selecionado ou no selecionado. O usurio pode alterar o estado desse elemento, clicando com o mouse ou via teclado, na caixa de verificao 35

desse elemento. Muitas vezes so utilizados grupos desse mesmo elemento, representando uma lista de opes, onde podem ser

selecionados n elementos. Esse elemento composto de um label e de um boto (caixa de verificao). CheckBoxAction: representa um elemento do tipo form, composto

de dois elementos distintos: um CheckBox (descrito anteriormente) e um Button (com a ao 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 usurio 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 ao de submit); ComboBoxTarget: representa o elemento ComboBox (descrito

anteriormente), composto de uma lista de elementos, onde cada elemento representa um link especfico, ou seja, quando o usurio realizar a escolha do elemento e selecion-lo na lista, automaticamente ser executada uma ao, 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 - mtodo http para a submisso do formulrio) e action (contm uma informao, indicando o que vai acontecer quando o formulrio for submetido). O atributo action pode conter um endereo http, um nome de uma pgina, um endereo eletrnico, entre outras informaes. Quando o boto de um elemento form selecionado, todos os valores dos elementos concretos que o compem, so submetidos 36

para a URL descrita no atributo action. O cdigo HTML desse elemento composto da descrio de um boto com a funo de submit; Image: representa elementos concretos que exibem figuras; Label: conhecido como rtulo, representa um valor (texto/string) que

exibido na interface; Link: representa ligaes pelas quais se pode navegar para outra

parte:

do mesmo documento (outra parte na mesma pgina); de outro documento (pgina, arquivo de imagem) da mesma aplicao hipermdia; de outro documento, em qualquer computador da rede; e, evidentemente, para se copiar todos esses arquivos (download) RadioButton: representa um tipo de boto que possui 2 estados:

selecionado ou no selecionado. Seu estado pode ser alterado pelo clique do mouse ou via teclado na caixa de verificao desse elemento. Na maioria das vezes so utilizados grupos desse elemento para representar um conjunto de opes, onde permitida a seleo 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 ao de submit);

37

RadioButtonTarget: representa o elemento RadioButton (descrito

anteriormente) com um link embutido na definio de cada item da lista desse elemento; TextBox: representa um campo de entrada de informao. Este

campo composto de apenas uma linha e pode ter n colunas; TextArea: representa um campo de entrada de informao. 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 composies de elementos de interface.

Uma interface mapeada em um elemento concreto composite, pois ela representa uma composio de vrios elementos de interface. Podem-se mapear outras composies mais simples de elementos para esse conceito. O mapeamento se d seguindo as regras de consistncia, a qual define quais classes abstratas podem ser mapeadas para quais classes concretas. Um exemplo de regra de consistncia, que expressa a quais elementos de interface concreta o elemento de interface abstrata SimpleActivator pode ser mapeado, se apresenta a seguir (Figura 2.7):

38

Figura 2.7 - Regra de consistncia de Mapeamento Concreto

Esta regra diz que os elementos abstratos SimpleActivator so subclasses da classe AbstractInterfaceElement (como todos os outros), e que esto restringidos a serem mapeados para os elementos Link e Button. Se forem observadas as ontologias previamente descritas, se perceber que so realmente os dois nicos elementos de interface que podem ser considerados como ativadores simples de aes pelo usurio. As outras classes ou so mais complexas, sendo uma composio de elementos incluindo SimpleActivator, ou no tem relao com ativao de aes pelo usurio. Na proposta feita por Moura (2004) depois de ser realizado o mapeado os elementos abstratos para os concretos, ento construdo o projeto do layout (disposio dos elementos) da interface com o usurio. ento aplicado o modelo de caixas do padro CSS, no qual cada elemento de interface concreta enclausurado por uma caixa definida por estilos CSS, provendo atravs da propriedade BlockElement da Ontologia de Widgets Abstratos a informao de qual tipo de caixa que o elemento concreto ser colocado. No caso desta proposta, o sistema seria implementado em HTML, logo, este mapeamento das 39

caixas est diretamente relacionado com as tags da linguagem HTML. Alm disso, nesta propriedade, pode ser definida a classe CSS a qual o elemento estar relacionado, j produzindo diretrizes para como sero exibidos os elementos de interface visual. Esta relao efetivamente construda quando da implementao do sistema. No contexto do presente trabalho, a implementao 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 disposio espacial que podem ser utilizados como valor da propriedade blockElement. Ser feito tambm o mapeamento dos componentes MXML para a Ontologia de Widgets Abstratos, criando modelos de interface adaptados para a configurao de interfaces Flex adequadas.

2.3.4.3

Abstract Data Views (ADVs)

A partir do esquema de classes de navegao e o esquema de contextos navegacionais, so gerados ADVs (Abstract Data Views) correspondentes a cada interface do sistema. Os ADVs representam os elementos da interface e como eles reagiro a eventos (tanto do usurio como do sistema), criando uma viso clara de como se d a experincia do usurio ao navegar pelo sistema. Os ADVs so bastante semelhantes aos Diagramas de Navegao, permitindo que o projeto prossiga de maneira uniforme. (ROSSI, 1996) So extrados ADVs para cada n, ndice, classe navegacional e contexto do projeto de navegao. Os ADVs so compostos por outros ADVs, estados, transies e atributos. ADVs aninhados nos permitem descrever a agregao de elementos de interface, e sua lgica facilmente mapeada para elementos de programao descritos por tags 40

(marcaes), ou seja, transpor um sistema da modelagem de interface abstrata para a implementao em linguagens de tags se d de maneira natural. Quando num determinado ADV existem estados ou outros ADVs que so habilitados visualmente ou desabilitados, utilizamos a varivel perceptionContext para fazer este controle. Elementos que esto adicionados a esta varivel so exibidos na interface, j elementos retirados da varivel deixam de ser percebidos pelo usurio. O ADV da Figura 2.8 representa a classe navegacional Programa de Radio:

ADV Programa de Rdio

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 Rdio

2.3.5 Implementao

A implementao mapeia os objetos da interface abstrata para objetos reais de programao e pode envolver arquiteturas elaboradas de aplicao, como por exemplo, 41

sistemas cliente-servidor, ou questes relativas interface grfica 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 programao do Flex, ainda introduzindo o conceito de STATES do Flex.

42

3 FLEX E FLASH

Neste capitulo sero apresentados dois frameworks de criao e publicao de aplicaes Flash, o Flash e o Flex. Ambos so ambientes para desenvolvimento de softwares que so escritos na linguagem ActionScript, porm, o primeiro com um enfoque maior na criao grfica, com ferramentas de desenho e controle do tempo para animaes e transies atravs de uma timeline e o segundo com enfoque no desenvolvimento de rich internet applications (RIAs). A combinao dos dois ambientes proporciona a criao de aplicaes avanadas e com expressividade visual (UIs, diversos tipos de mdia) bastante superior ao encontrado hoje no campo das aplicaes de internet.

3.1 Flex

Flex um framework open-source para criao de aplicaes altamente interativas, que so publicadas na maioria dos browsers atravs 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 programao que mais se aproximasse das questes relativas ao desenvolvimento de sistemas web, de maneira que fossem de fcil criao, que utilizassem o flash player como base de execuo sem que o desenvolvedor precisasse conhecer das tcnicas de animao do Flash. Com Flex, podemos elaborar aplicaes para web de maneira similar ao cdigo HTML, pois foi desenvolvida uma nova linguagem de programao no paradigma de linguagens de 43

marcao, baseada em XML, chamada de MXML que possibilitou essa analogia. Com as marcaes MXML, possvel criar interfaces de aplicaes mais facilmente do que no ambiente de desenvolvimento (IDE) do Flash, que requer um conhecimento de desenho vetorial e do esquema de criao 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 compilao, as marcaes MXML so 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 composio dos elementos de interface, suas propriedades e eventos associados, enquanto que a segunda descreve a lgica da aplicao. Com o surgimento do Flex, a Macromedia (criadora do sistema) entra para o mundo da criao das chamadas RIAs (Rich Internet Applications). Estas aplicaes podem ser compiladas em tempo de execuo, quando o usurio as requisita no servidor, fazendo com que a interface pudesse ser gerada neste momento em vez de ser totalmente prdeterminada em tempo de implementao. Isso possibilita a concorrncia com sistemas tradicionais de web dinmica, como HTML/JavaScript.

3.1.1 Verses lanadas e features associadas

A. Flex 1.0 Em um primeiro momento, a publicao de aplicaes Flex se dava atravs do Flex Data Services, um servidor que deveria ser instalado para dar suporte s requisies da aplicao. O cdigo era compilado em tempo de execuo atravs do J2EE (Java) e entregava um executvel [.SWF] para o browser do usurio. A criao dos 44

programas se dava atravs de um editor de textos comum, e um compilador em linha de comando. Uma grande caracterstica destes sistemas que o usurio realizava navegao entre elementos do sistema de maneira que este no precisava ser recarregado do servidor a cada requisio, mas sim, analogamente ao que acontece hoje com AJAX (que realiza comunicao assncrona), apenas os dados eram modificados, criando a sensao de que o sistema conciso, e no um conjunto de pginas sem relao umas com as outras. B. Flex 2.0 Esta verso do Flex o primeiro produto Macromedia lanado sob a bandeira da Adobe. A maior mudana feita nesta verso a migrao de uma IDE ultrapassada para uma totalmente nova baseada na plataforma Eclipse. Tambm no se fez mais necessria a utilizao da plataforma Flex Data Services, portanto uma aplicao Flex podia ser publicada apenas usando o SDK Flex. Ao mesmo tempo, a Adobe lana a linguagem ActionScript 3.0, fazendo com que o Flex agora suportasse todas as caractersticas desta nova linguagem. C. Flex 3.0 A ultima verso do Flex foi lanada pela Adobe com o cdigo aberto, apesar da IDE continuar proprietria. Foi lanada tambm pela primeira vez a plataforma Adobe AIR, que trs os sistemas criados em Flex para o desktop, possibilitando a interao entre o sistema ActionScript 3.0, PDF, JavaScript e HTML, o sistema de arquivos e hardwares do usurio. Foi tambm reformulada e ampliada a integrao entre Flex e os outros softwares de criao da Adobe.

45

3.1.2 Linguagens de programao.

As linguagens Flex agregam dois importantes paradigmas de desenvolvimento de software: as linguagens de marcao (markup languages), representadas pela MXML e as linguagens de programao orientadas a objeto, representada pela ActionScript 3.0. Como as linguagens de marcao so inadequadas para prover uma programao lgica para a comunicao entre o usurio e o sistema, utilizada em conjunto em um programa escrito em MXML a linguagem ActionScript, atravs da marcao <mx:Script>, que suporta programao orientada a objetos, e permite a comunicao entre diversos sistemas e gerenciamento de eventos emitidos pelos componentes lgicos ou pelo usurio. Um programa escrito em MXML representa em suas marcaes, instncias das classes ActionScript, ou seja, so linguagens baseadas na mesma API (as classes ActionScript). A Figura 3.1 exibe um esquema de como as aplicaes Flex so construdas.

Figura 3.1 - Esquema de publicao de aplicaes Flex.

46

3.1.2.1 ActionScript 3.0 ActionScript 3.0 uma linguagem de programao orientada a objetos utilizada para publicao de aplicaes Flash. Por aplicaes Flash entende-se todo tipo de aplicao que executada no Flash Player, sendo ela criada no ambiente Flash ou Flex. Os programas escritos nesta linguagem so compilados em programas que so executveis na mquina virtual do Flash Player [extenso .SWF]. ActionScript uma implementao do padro ECMAScript que mantm a mesma sintaxe do JavaScript, mas com um framework de programao diferente e com diferentes bibliotecas de classes. O ActionScript utilizado para criar praticamente todas as interatividades vistas em aplicaes Flash. Como o Flash prov uma compreenso melhor sobre grficos vetoriais do que o navegador, e por proporcionar uma linguagem de script focada na animao grfica, est sendo considerado como uma adio importante nas capacidades do navegador. Esta tecnologia conhecida como Asynchronous Flash and XML comparada com o AJAX (Asynchronous JavaScript and XML), mas com um possvel maior potencial do que o ltimo. Esta linguagem engloba muitos recursos, como por exemplo a verificao de tipos de dados em tempo de compilao e em tempo de execuo; A implementao efetiva de um sistema de herana baseado em classes e no em prottipos; Suporte para package, namespace e expresses regulares; Reviso completa da API do Flash, separado agora em classes; Gerenciamento de eventos feito de acordo com a especificao DOM event handling; Integrao com XML mais eficiente que nas verses anteriores, e conformidade total com o padro ECMAScript Fourth Edition Draft specification (MOOCK,2007).

47

3.1.2.2 MXML As linguagens de marcao se tornaram um padro no desenvolvimento de softwares para internet, e so poderosas quando se quer especificar uma interface com o usurio, de maneira que a disposio dos elementos tratada de maneira adequada e de fcil interpretao. MXML, baseada em XML, composta de vrias marcaes que compe a aplicao, sendo mais completa que HTML, por prover uma gama mais completa e interessante de componentes de programao, como menus e elementos de controle de dados mais complexos que as simples e duras tabelas do HTML. Alm de facilitar a publicao de interfaces, MXML tambm pode ser usado nas camadas lgicas, fora do mbito visual, fazendo, por exemplo, chamadas a funes para controle de bases de dados e integrao com outros sistemas escritos em outras linguagens, como linguagens server-side como PHP, ColdFusion ou JSP, entre outras. Em uma marcao MXML podemos definir os estilos, atributos e eventos do objeto, de maneira que os eventos podem fazer chamadas a funes ActionScript da mesma maneira que HTML faz chamadas a funes JavaScript. A diferena bsica entre a publicao MXML e a publicao HTML, que a primeira renderizada pelo Flash Player, em contrapartida da renderizao pelo browser no HTML. Isso permite uma gama de possibilidades em relao apresentao da interface, que pode conter animaes, efeitos de transio, efeitos grficos, vdeos e sons nativamente, sendo muito mais poderoso e muito mais amigvel ao usurio do que a publicao baseada em pginas do HTML. (COENRAETS, 2003) O sistema de publicao do MXML se assemelha muito com as JavaServer Pages (JSP) quando feita compilao On The Fly. O usurio (cliente) faz a requisio via http para o servidor, que compila em tempo real o cdigo MXML para um executvel (.SWF) e o 48

envia para o cliente. Em JSP o que acontece semelhante, a diferena que o cdigo executado no servidor (Java servlets), em contrapartida o cdigo 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 cdigo executvel compilado, as prximas requisies a um mesmo arquivo no geraro uma compilao, bastando ao servidor determinar qual o arquivo que o cliente precisar executar, o qual j estar em poder do mesmo. Isso traz inmeras vantagens ao que diz respeito ao volume de processamento efetuado pelo servidor e trfego de rede. Tambm possvel publicar o arquivo executvel compilado ([.SWF] para o Flash Player). Quando compilamos um programa escrito em MXML, gerado um cdigo intermedirio em ActionScript 3.0 e s ento esse cdigo traduzido para o executvel (.SWF), ou seja, as marcaes MXML representam classes ou atributos das classes ActionScript, ento, so instanciadas estas classes de acordo com a estrutura de tags quando o programa compilado. A Figura 3.2 representa o esquema de publicao de aplicaes Flex.

Figura 3.2 Esquema de publicao de Aplicaes Flex

49

utilizando PHP como arquitetura server-side.

O programa a seguir (Cdigo Fonte 3.1) exemplifica uma aplicao MXML. Ela copia o texto contido em um campo de texto para outro campo de texto quando se pressiona o boto Copiar.
Cdigo Fonte 3.1 - Exemplo de Aplicao MXML 1 2 3 4 5 6 7 8 9 <?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml">

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

/>

O cdigo acima pode ser expandido, usando a tag <mx:Script> para conter o cdigo ActionScript da funo a ser chamada quando do acionamento do evento Click do boto Copiar, como pode ser visto no (Cdigo Fonte 3.2).
Cdigo Fonte 3.2 - Exemplo de aplicao 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 cdigos acima geram um programa que executado em um Flash Player, como pode ser visto na 50

Figura 3.3:

Figura 3.3 Exemplo simples de aplicao Flex

3.1.3

Criao de interfaces no Flex

As linguagens Flex permitem a criao de vrios tipos de componentes de interface,

alm componentes de controle tradicionais, como caixas de textos, botes, comboboxes, checkboxes e radio buttons, MXML prov controles avanados nativos de manipulao de dados estruturados, como DataGrids e TreeViews, alm disso, existem muitas marcaes de disposio espacial dos elementos e de controle de navegao 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 aplicao) alterando ou no o tamanho dos elementos. Por exemplo, possvel fazer com que elementos sejam dispostos na tela aproveitando o maior espao possvel, sem distorcer imagens ou alterar tamanhos de botes, em compensao, quando existe uma tabela de dados o espao pode ser aproveitado para mostrar maior quantidade de dados ao mesmo tempo sem que o tamanho mnimo da tabela seja ultrapassado. Para o controle de navegao por parte do usurio, existem menus pr-definidos, para organizar claramente as informaes e os processos da aplicao. Entre eles podemos destacar o TabNavigator, o Accordion e os ViewStacks. Este ltimo um conjunto 51

de canvas (telas com posicionamento absoluto (x, y) dos objetos filhos) sobrepostos que o usurio pode escolher visualizar na ordem que achar mais conveniente, atravs de controles de navegao, como Tabs, ou botes.

3.1.3.1 VIEW STATES Flex States uma nova classe agregada linguagem ActionScript 3.0 e

conseqentemente MXML, que nos fornece uma maneira de fazermos o controle de estados da aplicao de acordo com mudanas na interface e propriedades dos objetos. Por meio da marcao <mx:State> cria-se diferentes configuraes para a interface da aplicao e valores de atributos de objetos. So quatro as alteraes possveis: Adio e subtrao de elementos de interface; Alterao do valor de atributos dos objetos; Alterao do comportamento dos objetos (eventos que sero acionados); Estilos visuais.

A seguir uma aplicao que tem uma tela de login com dois campos de texto, um para o usurio e outro para a senha, e um boto de confirmao. Porm, quando um usurio no registrado usa a aplicao ele tem a opo de se cadastrar no sistema, ativando um segundo boto. Este cadastro pode ser feito atravs do mesmo formulrio que um usurio j registrado faria o login, mas, acrescido de um de campo de texto para a confirmao da senha, com o texto exibido no boto modificado de Login para Registrar. A funcionalidade do boto, que no estado inicial chamaria o mtodo login(usurio, senha), no estado Registro chama registrar(usurio, senha, confirma).

52

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

<mx:SetProperty target="{loginButton}" name="label" value="Registro"/> <mx:SetEventHandler target="{loginButton}"

53

53 name="click" 54 handler="registrar(user.text, senha.text, senha2.text);"/> 55 56 57 <!remove o LinkButton existente. --> 58 59 <mx:RemoveChild target="{registerLink}"/> 60 61 <!-62 adiciona um novo Linkbutton para trocar o 63 o view state de volta para o base state. 64 --> 65 <mx:AddChild relativeTo="{spacer1}" position="before"> 66 <mx:LinkButton label="Retornar para Login" click="currentState=''"/> 67 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="Usurio:"> 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" click="currentState='Registro'" 94 95 /> 96 97 <mx:Spacer width="100%" id="spacer1"/> 98 <mx:Button label="Login" id="loginButton" 99 click="login(user.text,senha.text);"/> 100 101 </mx:ControlBar> 102 103 </mx:Panel> 104 </mx:Application>

54

Figura 3.4 - Dois estados de uma aplicao. esquerda, o base state e direta, o estado "Registro"

A linha 94 do cdigo representa o evento click do componente LinkButton. Este evento altera a varivel <mx:states> da aplicao (linha 24) e muda o view state atual para Registro. A troca de funcionalidade do boto de confirmao est nas linhas 99 (declarao inicial) e 54 (alterao do mtodo chamado). A transio de um estado para outro pode ser definida utilizando efeitos visuais para criar uma experincia de usabilidade na troca entre os estados atravs da marcao <mx:Transitions>. O desenvolvedor pode definir seqncias e paralelismos em uma transio, definindo a ordem e concomitncia em que acontecem animaes, mudanas de propriedades dos objetos e retirada ou adio de elementos de interface. mx:State pode ser utilizado para implementar estados de componentes customizados, e no s da aplicao como um todo. O exemplo mais bsico seria um boto que muda de estado a cada evento do mouse, como mouseOver, mouseDown, mouseUp e assim por diante. So descritos estados para cada condio e, a cada evento disparado, o estado alterado. Os mx:States so organizados hierarquicamente, sendo que cada aplicao ou componente sempre tem um estado inicial (base state), e todos os outros estados so 55

filhos dele ou filhos de filhos. No caso da aplicao de exemplo acima, o estado base composto por todo contedo do mx:Panel (loginPanel) e o estado filho representado pelo contedo da marcao mx:state (register). Caso seja declarado um estado vazio, o contedo dele ser idntico ao do pai.

3.1.3.2 Componentes Flash e componentes Flex O poder de customizao e criao de componentes dos ambientes Flex e Flash muito vasto. Como Flex no foi feito para a criao de elementos grficos, podem ser criados novos componentes de interface no Flash que exportados so utilizados nativamente no Flex, onde a estruturao por marcaes facilita o desenvolvimento da aplicao em si. Estas caractersticas proporcionam uma interatividade visual avanada, possibilitando ao usurio uma experincia muito completa, e permitindo equipe de desenvolvimento uma gama muito maior de possibilidades. Note que o inverso no se aplica. Componentes criados no Flex no podem ser utilizados em Flash. Quando da criao 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 ento dar novas funcionalidades ao mesmo, e mais, este novo componente pode se tornar uma nova marcao (tag) MXML. Portanto, a criao de elementos de interface que possam ser facilmente expressos em uma linguagem de marcao torna este ambiente colaborativo um dos mais promissores da internet hoje em dia.

3.1.3.3 Componentes MXML Sero descritos os containers e controles MXML. A listagem com figuras para ilustrao encontra-se no anexo 8.5. 56

3.1.3.3.1

Containers (Agrupadores)

Accordion Accordion um elemento de navegao que contm um conjunto de painis filhos, mas apenas um deles visvel por vez pelo usurio. Alm dos painis filhos, so criados botes para o acesso a cada um deles. Estes botes esto posicionados no agrupador geral, e no em cada painel filho, permitindo uma fcil visualizao de que estamos vendo outro painel quando acionamos os botes. ApplicationControlBar Este um agrupador que serve como espao para componentes de controle que provm controle de navegao e comandos globais da aplicao. Ele pode ser publicado de duas maneiras, a estacionria (dock) e a normal. Na estacionria, a barra de controle posicionada no topo da aplicao, enquanto no modo normal, podemos posicionar a barra de controle em qualquer parte da aplicao como qualquer outro componente de interface. Box O Box funciona como um <div> em HTML, com a diferena que temos que especificar se os elementos internos a ele sero dispostos verticalmente ou horizontalmente. Portanto, no utilizamos a marcao <mx:Box> mas sim <mx:VBox> para uma caixa vertical e <mx:HBox> para uma caixa horizontal. Canvas Canvas um espao no qual a disposio dos elementos (containers e controles) feita de maneira absoluta, especificando-se a posio (x,y) explicitamente para cada item contido. Estes itens podem ter o tamanho associado ao tamanho do canvas, 57

por exemplo definir que um elemento ter 100% da largura do container pai, fazendo com que mesmo que o Canvas mude de tamanho, o elemento sempre toque as bordas laterais do pai. Com este container, podemos fazer com que seus filhos (containers e controles) se sobreponham, diferentemente de outros elementos agrupadores nos quais sempre os elementos sero dispostos em seqncia. ControlBar Barra de controle que serve para ser colocada no rodap de elementos Panel ou TitleWindow. Ele sempre deve ser a ltima marcao colocada dentro destes elementos. DivideBox So caixas divididas, nas quais o usurio pode alterar o tamanho das clulas. Assim como o elemento box, no se usa a marcao <mx:DivideBox>, mas sim <mx:HDivideBox> para uma caixa dividida em clulas dispostas lado a lado e <mx:VDivideBox> para caixa dividida em clulas dispostas uma abaixo da outra. Form Formulrios so containeres que agregam elementos de informao que sero enviados ao sistema para que o controle de dados seja efetuado. Neles, diferentemente dos forms HTML, podemos criar regras para definir quais campos do formulrio so obrigatrios, e quais recebero controles de validao de dados. Tambm podemos utilizar folhas de estilos para definir a aparncia dos controles internos a ele. FormHeading So cabealhos formados por um ttulo, que indicam um subconjunto de itens de controle de dados dentro de um Form. Os subitens deste cabealho ficam alinhados 58

com o mesmo, facilitando ao usurio a compreenso da diferena entre os conjuntos de dados. Apesar disso, todos os subitens de todos os cabealhos dentro de um Form pertencem a este mesmo Form. Cada um destes subconjuntos pode ter uma folha de estilos distinta. FormItem Os itens de formulrios so duplas label-elemento, onde elemento pode ser um ou mais agrupadores ou controles arranjados verticalmente ou horizontalmente. Grid Grids so agrupadores semelhantes as tabelas HTML. Eles podem conter uma ou mais linhas e cada linha pode conter uma ou mais colunas, ou itens. Sua utilizao se d da seguinte maneira: uma marcao <mx:Grid> seguida de uma ou mais marcaes <mx:GridRow>, e, dentro de cada uma destas, marcaes

<mx:GridItem> que representam as colunas da grade. Cada GridItem pode conter quantos filhos forem necessrios. Panel Um painel composto de uma barra de ttulo, um ttulo, uma borda e um canvas que o espao destinado aos filhos do painel. TabNavigator TabNavigator uma extenso do container ViewStack, adicionando uma barra de aletas (controle TabBar), que faz o controle de navegao entre as pginas do viewstack. Quando se aciona uma destas aletas, a pgina correspondente do viewstack associado exibida, escondendo as demais. Tile 59

Exibio de elementos dispostos em mosaico ViewStack Disposio de elementos em mltiplos canvas dos quais apenas um est visvel por vez. Enquanto os outros no so acessados, no so carregados na memria pelo programa.

3.1.3.3.2

Controles

Button um boto tradicional, com aspecto grfico que indica que pode ser acionado com o mouse ou teclado. Este componente composto de um retngulo externo, um label e/ou um cone. Os botes so normalmente utilizados em conjunto com event listeners, que fazem o controle do funcionamento do boto em funo das aes do usurio. Quando acionado, o boto emite um evento do tipo click e um mouseDown. Um boto 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).

ButtonBar [navBar] Os ButtonBars so conjuntos de botes logicamente relacionados, dispostos de maneira vertical ou horizontal. Os botes so do tipo push-button, ou seja, no memorizam o estado depois de receberem uma ao de ativao. A maneira de adicionar ou remover botes da barra de botes anloga manipulao de dados em uma lista, com os mtodos addItem() e removeItem(), simplificando o gerenciamento da display list ActionScript 3.

CheckBox [button] 60

Checkbox um componente composto de um label e uma caixa de seleo, a qual pode ou no conter uma marca de ativao. Os elementos CheckBox no so mutuamente exclusivos, ou seja, podemos marcar ou desmarcar as vrias CheckBox contidas em uma aplicao conforme desejado (em contrapartida, ver RadioButton). o ColorPicker [combobase] um selecionador de cores, no qual o usurio pode rapidamente escolher uma cor dentre uma gama de cores definidas. o ComboBase ComboBase a classe me de componentes como ComboBox, ColorPicker e DateField. composta por um campo de texto, e um boto para o acionamento de uma lista na qual pode se escolher a opo que ser selecionada. No utilizada diretamente como uma marcao 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 usurio seleciona apenas uma opo, uma caixa de texto que contm a opo selecionada, e um boto para exibir esta lista. um componente anlogo ao SELECT do HTML mas com a diferena de que o usurio pode (quando permitido) inserir novas entradas que no esto na lista, a partir da prpria 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 exibio de elementos que tem varias propriedades. um componente que tem as seguintes caractersticas: 61

as colunas podem ser de tamanhos diferentes; as colunas podem ser redimensionadas em tempo de execuo pelo usurio; as colunas podem ser reordenadas em tempo de execuo pelo usurio; possibilidade de usar um itemRenderer para exibio de dados que no sejam textuais; possibilidade de ordenao das linhas acionando uma das colunas. DataGrid um componente de interface construdo para exibio de dados, e no uma ferramenta de disposio de elementos como as TABLES HTML. Para tal, existem os containers em MXML. o DateChooser Este componente composto de uma barra de ttulo, mostrando o nome do ms e o ano, e um calendrio mostrando os dias daquele ms especfico. O usurio pode selecionar uma data, um intervalo de datas ou ento datas mltiplas. O controle dispe de acionadores para modificar o ano/ms 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 exibio de uma data, e um boto que aciona um DateChooser para seleo desta data. Quando a data selecionada, o DateChooser fechado e a data selecionada preenche o campo de texto. O usurio pode tambm digitar a data diretamente no campo de texto. o HorizontalList

62

Este componente exibe uma lista na qual os elementos so dispostos lado a lado. Caso existam mais elementos do que o nmero 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 exibio dos dados quando estes preenchem um espao maior do que o container onde eles esto inseridos. Apesar de ser um controle independente, podemos associar a barra de rolagem a outros componentes para efetuar o controle de rolagem em seus contedos. As barras de rolagem so compostas por quatro elementos: dois botes com setas, um boto de rolagem e um trilho no qual o boto de rolagem percorre. A posio do boto de rolagem e a exibio das setas dependem do estado do controle. o HSlider/VSlider Os controles HSlider e VSlider permitem ao usurio fazer seleo de um ou mais valores dentre um intervalo. Composto de um trilho horizontal/vertical e um ou mais botes de rolagem. A seleo de valores feita de maneira visual, arrastando os botes pelo trilho, e o valor definido de acordo com valores mximo e mnimo definidos no trilho. Este conjunto de valores pode ser contnuo, ou ter valores especficos entre o mximo e o mnimo. o Image O controle de exibio de imagens permite importar arquivos JPG, PNG, GIF e SWF. Alm disso, prov funes para embarcar estes arquivos no executvel final 63

em tempo de compilao. Este componente normalmente utilizado para importao de arquivos estticos, que no faro parte da lgica do sistema e para criao de ItemRenderers. Para importao de outras aplicaes Flex/Flash, recomendado o uso de outro componente, o SWFLoader. Imagens embarcadas so carregadas imediatamente, pois so parte do cdigo executvel, mas em contrapartida fazem o tamanho da aplicao aumentar. Imagens embarcadas tambm fazem a manuteno da aplicao 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 execuo, fazendo um HTTPRequest ou simplesmente carregando um arquivo no servidor onde a aplicao est rodando. Estas imagens ficam independentes da aplicao, ento quando as alteramos, no 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 transparncias, aumentando o grau de qualidade grfica da aplicao. o Label Os Labels so linhas simples de texto, no so editveis mas podem ser selecionados caso o desenvolvedor permita. Representam informaes textuais que podem ser controladas por folhas de estilos CSS. Labels no possuem bordas ou fundo e no podem receber o foco da aplicao. o LinkButton [button] um controle Button sem bordas e seu label aceso (um efeito visual acende o boto) quando o usurio passa o foco da aplicao (com mouse ou teclado) sobre o componente.

64

LinkBar O LinkBar um conjunto de LinkButtons, dispostos horizontalmente ou verticalmente. Sua aplicao tpica de controlar outros elementos de interface como ViewStacks, ou para criar um conjunto independente de Links.

List uma lista simples de elementos, na qual uma barra de rolagem pode ser inserida caso o nmero de itens seja maior do que o nmero que pode ser exibido neste componente dependendo de seu tamanho. O usurio pode fazer a seleo 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 aplicaes em sistemas operacionais. Estas listas podem ter vrios nveis de submenus quanto desejado. Depois de uma destas listas serem abertas, elas se mantm visveis at que uma das seguintes aes ocorra: Uma chamada funo Menu.hide(); O usurio seleciona um item de menu O usurio clica fora do menu O usurio seleciona outro componente da aplicao. o MenuBar

65

A barra de menu um conjunto de componentes Menu, disposta em uma barra horizontal, geralmente no topo da aplicao, com um boto para cada componente deste conjunto. o NumericStepper Este componente permite ao usurio fazer a seleo de um nmero dentre um conjunto enumervel, ou um intervalo de nmeros. composto de uma caixa de texto para informar o nmero selecionado, e botes para adicionar ou subtrair o nmero selecionado. o PopUpButton Os PopUpButtons so botes nos quais a ao a ser feita pode ser selecionada da mesma maneira como acontece em ComboBoxes. composto de dois elementos, o boto em si e outro boto que exibe uma lista de aes. Aps a seleo ser feita, a parte do componente que o boto em si executa aquela o ProgressBar So barras de progresso que indicam o progresso de uma tarefa ao longo do tempo. Estas tarefas incluem consultas a banco de dados, carregamento dinmico 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 marcaes temporais de um determinado acontecimento. Caso o tempo seja indeterminado, como por exemplo em carregamento de arquivos, onde o tempo depende da velocidade da transferncia de dados, utilizamos a forma indeterminada. o RadioButton

66

RadioButtons so botes que funcionam como botes comuns, mas o label deste est fora do grfico que o representa. Este componente utilizado em conjunto com componentes do mesmo tipo e so 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 usurio seleciona um destes botes de um mesmo grupo, os outros tem sua seleo automaticamente removida. o RadioButtonGroup Determina um conjunto de RadioButtons o RichTextEditor um editor de textos no qual o usurio pode inserir contedo e mudar a formatao do texto. composto de duas partes principais: uma caixa de textos (TextArea) onde o usurio pode digitar texto e um container contendo controles para o usurio especificar as caractersticas de formatao do texto inserido. o Spacer Spacer so elementos de disposio de componentes em um container pai, que auxiliam no layout do container. So elementos invisveis, 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 exibio de animaes ou aplicativos Flash/Flex. um componente poderoso, pois quando carregamos uma aplicao dentro de outra, estamos utilizando conceitos de reusabilidade, j que podemos fazer a comunicao da aplicao base com a carregada. Apesar de este

67

componente no receber o foco da aplicao, seus elementos internos o recebem e a interao completa. o TabBar um conjunto de botes mutuamente exclusivos em sua seleo, representados de maneira a se parecerem com abas de um arquivo. Geralmente so utilizados em conjunto com ViewStacks, mas podemos utiliz-los como qualquer conjunto de botes que so mutuamente exclusivos (quando um ativado, todos os outros so desativados). o Text O controle de texto derivado do Label, mas pode conter mais de uma linha de contedo no editvel. Este controle no suporta barras de rolagem, podemos utilizar tags HTML para a formatao do contedo e decidir se este ser ou no selecionvel. o TextArea TextArea um componente composto de uma rea de texto, uma borda e barras de rolagem opcionais. Tambm suporta tags HTML para a formatao do contedo. o TextInput Este controle uma caixa de texto de apenas uma linha, na qual o usurio entra com dados arbitrrios. Quando utilizado como filho de um componente Form, podemos utilizar validadores de dados, e tambm indicar se o campo de preenchimento obrigatrio ou opcional. Estes controles possuem 4 estados distintos: preenchido, selecionado, desligado e erro. Eles despacham eventos quando da

68

insero de contedo e quando perdem o foco da aplicao, para ser feita a validao e controle de obrigatoriedade. Este componente utilizado como subcomponente em vrios outros componentes, como o RichTextEditor, NumericStepper, e Comboboxes. Quando associamos uma folha de estilos CSS classe do componente, deve-se tomar precauo pois todos estes outros componentes pais sero afetados, a no ser que seja explicitamente indicado outro estilo. o TileList Este componente exibe um nmero de itens dispostos em clulas. Ele exibe uma barra de rolagens se isso se fizer necessrio, 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 botes so colocados no estado normal.

ToolTip Tooltips so componentes de informao de auxlio ao usurio. Quando este move o mouse sobre um determinado componente grfico, o ToolTip exibido com texto informativo sobre aquele componente. Sua funcionalidade pode ser expandida de acordo com o projeto, inserindo novas funcionalidades.

Tree Este elemento possibilita a visualizao de dados arranjados em uma estrutura de rvore, com galhos e folhas. Uma folha um ponto final de uma rvore, que pode 69

conter inmeras folhas. Um galho um nodo intermedirio que contm outros galhos ou folhas, ou pode estar vazio. o VideoDisplay Este componente permite a exibio de vdeos no formato .FLV. Suporta download progressivo atravs de requisies http, ou streaming a partir de servidores Flash (Flash Media Server, da Adobe, ou o Red5, open-source). Aceita tambm streams de vdeos de cmeras, 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 criao do contedo para o Adobe Engagement Platform. O Adobe Flash Player o cliente universal, que instalado no navegador do usurio ou em verso stand-alone, proporciona, atravs de uma mquina virtual chamada AVM (ActionScript Virtual Machine) a exibio de contedo Flash. Este cliente suporta grficos vetoriais, bitmaps (mapas de bits) e streaming de udio e vdeo entre outros formatos de mdia. Resumindo,o Adobe Flash Professional um ambiente integrado de desenvolvimento (IDE) e o Adobe Flash Player uma mquina 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 mtodos tradicionais de CAD, a construo lgica 70

de elementos de desenho, como por exemplo, uma linha que sempre conecta dois objetos, mesmo que estes sejam modificados, ou um grfico de barras que mudaria de tamanho de acordo com um nmero digitado em uma caixa de texto pelo usurio. "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 verso do Flash) comeou a receber muitas sugestes de usurios para transformar o SmartSketch (sucessor do Intellidraw) em um software de animao grfica. A idia foi muito bem aceita, mas um problema surgia nesta ao. A nica maneira de se publicar animaes na poca era em formatos de vdeo, como VHS ou Betamax, ou ento em CD-ROMs com hipermdia e o mercado de ferramentas de animao era muito pequeno. Nesta mesma poca estava surgindo a world wide web como a conhecemos hoje, e a possibilidade de publicar animaes na internet abriu as portas para a FutureWave software, que comeou ento a projetar um web-player em Java que reproduziria as animaes feitas no SmartSketch, mas esta era lenta e instvel. (Flash Magazine > News, 2000). Logo depois, a Netscape lanou seu pacote de APIs (Application Programming Interface) para a produo de plug-ins, o que fez com que as animaes do SmartSketch pudessem ser reproduzidas no prprio navegador no computador do usurio, 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 verso 1.0 do Macromedia Flash. Durante o tempo em que o Flash permaneceu sob a bandeira da Macromedia, muitas modificaes e aprimoramentos foram feitos. A seguir, a Figura 3.5 mostra uma tela da primeira verso do FutureSplash Animator.

71

Figura 3.5 Tela do Future Splash Animator

Em meados de 2005 a Macromedia adquirida pela Adobe, e ento criada a Adobe Engagement Platform, nome da sute de aplicativos criada pela Adobe resultante da juno 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 aplicaes (Cairngorm), ferramentas de desenvolvimento (Dreamweaver, Flash, Flex), e o Adobe Solutions Network (treinamento e suporte). Desde a sua introduo em 1996, a tecnologia Flash se tornou um padro na adio de animaes e contedo interativo em pginas da internet em um tempo que as pginas eram construdas basicamente com HTML e um uma parcela muito reduzida utilizava mtodos de criao dinmica de pginas. A partir de ento muitos outros softwares, sistemas complexos e dispositivos de hardware so capazes de exibir contedo Flash e at mesmo criar contedo Flash. Geralmente Flash utilizado para criar animaes, pequenos anncios em websites, vrios tipos de componentes de interface para web, para adicionar vdeo em pginas da internet e mais recentemente para criar a aplicao web como um todo. 72

As verses mais recentes do Flash so : Macromedia Flash Professional 8 (13 de Setembro de 2005) Ultimo Flash lanado sob bandeira da Macromedia, esta verso suporta ActionScript 2.0 (no orientado a objetos). Seu maior feito foi ter includo controles de vdeo avanados que fizeram surgir uma verdadeira onda de vdeos na internet publicados na plataforma Flash. Esta verso era focada em expressividade, qualidade, vdeo alm de autorao para dispositivos mveis. Novos recursos incluam Filtros de bitmaps, blend modes, controle de suavidade para animaes, estilos de pincel avanados, desenho baseado em objetos, cache de bitmaps em tempo de execuo, antialiasing avanado para texto, um novo codec de vdeo mais eficiente (On2 VP6), suporte para transparncia (alpha channel) em vdeo, um codificador de vdeo standalone, outras funcionalidades relacionadas a vdeo, e um emulador interativo de dispositivos mveis. Adobe Flash CS3 Professional (verso 9) (16 de Abril de 2007) Esta verso a primeira lanada aps a compra da Macromedia pela Adobe. Ela suporta o ActionScript 3.0 (Orientado a objetos) , permite a converso de animaes feitas nas timelines em cdigo, aumenta a integrao 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 organizao com os softwares da Adobe.

73

4 A PROPOSTA
A fim de aperfeioar a tarefa de mapeamento de um modelo abstrato de interface OOHDM para implementao da interface concreta em um sistema baseado em Flex, este trabalho sugere adaptaes, extenses e sugestes s etapas de Projeto de Interface Abstrata e Implementao do OOHDM A Figura 4.1 nos mostra as etapas do OOHDM e seus passos internos. Os artefatos gerados que so trocados entre as etapas esto representados acompanhando as transies entre as etapas. A Figura 4.2 mostra o mtodo OOHDM com as extenses propostas no presente trabalho.
Anlise de Requisitos 1. Criao dos casos de uso
UIDs

2. Especificao dos UIDs

UIDs classes conceituais

UIDs

Modelagem Conceitual 1. Modelagem das classes conceituais

Projeto de Navegao 1. Modelagem das classes navegacionais 2. modelagem dos contextos navegacionais

classes e contextos navegacionais.

Projeto de Interface Abstrata 1. Especificao dos widgets abstratos 2. Especificao dos widgets concretos 3. Especificao de ADVs

ADVs

classes e contextos navegacionais.

Implementao

Figura 4.1 Esquema simplificado do processo do mtodo OOHDM

74

Anlise de Requisitos 1. Criao dos casos de uso

UIDs UIDs

2. Especificao dos UIDs

UIDs classes conceituais

Modelagem Conceitual 1. Modelagem das classes conceituais

Projeto de Navegao 1. Modelagem das classes navegacionais 2. modelagem dos contextos navegacionais

classes e contextos navegacionais.

Projeto de Interface Abstrata ADVs Flex 1. Especificao dos widgets abstratos

classes e contextos navegacionais.

widgets concretos MXML

3. Especificao de ADVs para Flex Implementao 1. Criao da interface utilizando <mx:States>

2. Especificao dos

Figura 4.2 Esquema do processo OOHDM estendido para criao de sistemas Flex.

So propostas quatro extenses ao processo OOHDM. A primeira extenso faz parte do Projeto de interface Abstrata e sugere o mapeamento das primitivas de interao usurio-sistema extradas dos UIDs e atributos das classes navegacionais para elementos da Ontologia de Widgets Abstratos. A segunda extenso 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 extenso, os ADVs so adaptados para acomodar a informao das Ontologias Abstrata e Concreta para prover uma descrio detalhada e pronta para o mapeamento em MXML. A quarta extenso feita entre o Projeto de interface e a Implementao, mas principalmente na ltima e sugere a 75

definio dos estados de interface Flex (View States <mx:State>) de acordo com um conjunto de ADVs pr-determinados para modelarem estes estados.

4.1 Extenso 1 - Especificao dos widgets abstratos

Esta extenso ao processo OOHDM utiliza uma proposta sugerida por Remculo (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 construo da interface abstrata, na qual so identificados os atributos e mtodos das classes navegacionais, e segundo suas origens nos UIDs, so 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 funo. Caso no UID este elemento seja apenas uma exibio de contedo, o mapeamento deve ser feito para elementExhibitor, mas, se este elemento seja passvel de ativao, como em um texto com ncora, ele deve ser mapeado para a classe simpleActivator. Com este mapeamento, obtm-se o primeiro conjunto de informaes para o projeto da interface abstrata identificando que tipo de exibio 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.

76

Tabela 4.1 Mapeamento de elementos dos UIDs para a Ontologia de Widgets Abstratos. (REMCULO, 2005, p. 39)

UIDs Item de dado e Item de dado personalizado Estrutura

Widgets Abstratos ElementExhibitor ou SimpleActivator A estrutura toda pode ser mapeada para um ElementExhibitor ou SimpleActivator, assim como cada elemento da estrutura pode ser mapeado para um ElementExhibitor ou SimpleActivator. Neste caso, 1 deve-se mapear a Estrutura para um CompositeInterfaceElement, para que depois os elementos que compem a Estrutura sejam mapeados para ElementExhibitor ou SimpleActivator. 1 passo: mapear o conjunto CompositeInterfaceElement. para um

Conjunto, Conjunto com contedo personalizado e Conjunto em disposio diferenciada

2 passo: mapear cada elemento do conjunto para um ElementExhibitor ou SimpleActivator, conforme o objetivo do item de dado ou estrutura que compem o conjunto. ElementExhibitor ou VariableCapturer. No caso de VariableCapturer, o elemento pode ser mapeado para: IndefiniteVariable, ContinuousGroup, DiscreetGroup, MultipleChoices ou SingleChoices. IndefiniteVariable SingleChoice, MultipleChoice Recebe o mapeamento descrito para os elementos dos UIDs, conforme o tipo de elemento que representa a Sada do Sistema (Item de dado, Item de dado personalizado, Estrutura, Conjunto, Conjunto com contedo personalizado, Conjunto em disposio diferenciada, Dado Opcional, Entrada do Usurio e Entrada do Usurio Enumerada). ElementExhibitor CompositeInterfaceElement. Caso o Estado de Interao seja um conjunto de CompositeInterfaceElement, o estado de interao ser a associao dos CompositeInterfaceElements.

Dado opcional

Entrada do Usurio Entrada do Usurio Enumerada Sada do Sistema

Texto Estado de Interao, Estado Inicial da Interao e Estados Alternativos da Interao.

77

Sub-estados de um Estado de Interao. Transio com Seleo da Opo X e Transio com Seleo da Opo Restrita X.:

CompositeInterfaceElement SimpleActivator. No caso da opo precisar de outro elemento para que o estado de interao destino se torne o foco da interao, a mesma deve ser mapeada para MulipleChoice ou SingleChoice e atrelada a um SimpleActivator para que a transio entre Estados de Interao ocorra. Os conceitos que suportam a seleo de 1 ou mais elementos especificados nos UIDs so: ContinuousGroup*,DiscreetGroup*, MultipleChoices ou SingleChoices. No h mapeamento para a ontologia de widgets abstratos.

Transio com Seleo de N Elementos

Chamada de Outro UID, Chamada a partir de Outro UID, Transio com Condio Y, Pr-Condies, PsCondies e Notas Textuais.

Durante o processo de pesquisa, principalmente quando da anlise dos componentes MXML, detalhada na seo 4.2, foi identificada a necessidade de se descrever elementos de interface que fizessem seleo de intervalos em vez de apenas um nico valor a partir de um intervalo de valores. Estendendo a classificao dos widgets abstratos da metodologia OOHDM, as classes da Ontologia de Widgets Abstratos ContinuousGroup e DiscreetGroup podem ter pares de seleo mltipla

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 descrio das classes da Ontologia de Widgets Abstratos que so subclasses da classe PredefinedVariable e descrevendo as duas novas classes: ContinousGroup: permite a seleo de um nico valor de um intervalo infinito de valores; ContinousGroupMultiple: [nova] permite a seleo de um ou mais valores de um intervalo infinito de valores; 78

DiscreetGroup: permite a seleo de um nico valor de um intervalo finito de valores; DiscreetGroupMultiple: [nova] permite a seleo de um ou mais valores de um intervalo finito de valores; MultipleChoices: permite a escolha de um ou mais elementos de um conjunto enumervel de valores; SingleChoice: permite a escolha de um nico elemento de um conjunto enumervel 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 classificao permite ao usurio fazer a seleo de mltiplos valores a partir de um intervalo infinito (ContinuousGroupMultiple) ou finito (DiscreetGroupMultiple) de valores. Naturalmente, elementos concretos que sero mapeados a partir destas classes devem prover mais de um elemento de seleo, como mostrado na Figura 4.4 a seguir:

79

Figura 4.4 - Exemplo de interface para seleo mltipla 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 definio de widgets abstratos.
Tabela 4.2- Exemplo de definio de widgets abstratos

Classe: Programa de Rdio Atributos nome:String data:String tempo:String Som:Audio origem nos UIDs Item de dado Item de dado Item de dado Item de dado transio (escutar programa) nomeDJ:String Item de dado transio (ver DJ) idxMusicas Estrutura CompositeInterfaceElement SimpleActivator Widgets Abstratos ElementExhibitor ElementExhibitor ElementExhibitor SimpleActivator

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 obtm-se a informao de que estes elementos ativam uma ao, no caso do nomeDJ, o usurio direcionado para o UID ver DJ e no caso do som, executada a operao escutar programa. O elemento idxMusicas um elemento composto pois est exibindo mais de um atributo de outra classe conceitual, 80

nome e artista de Musica, compondo uma estrutura no UID e sendo mapeado para CompositeInterfaceElement.

4.2 Extenso 2 - Especificao dos widgets concretos MXML

Esta seo far um estudo comparativo das premissas da Ontologia de Widgets Abstratos com os componentes de interface MXML, sugerindo uma nova Ontologia de Widgets Concretos especfica. Os componentes MXML podem ser utilizados como contedo dos atributos mapsTo, blockElement, ou compositionTag das classes Ontologia de Widgets Abstratos. Os componentes MXML so classificados em duas subclasses, os containers MXML e os controles MXML. Os containers MXML so elementos que podem ser utilizados como invlucros de componentes de interface, pois especificam o layout de uma interface grfica com o usurio. Podemos mapear os compositeInterfaceElements para este tipo de componente. Por exemplo, uma interface pode conter 3 botes 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 botes na interface da maneira desejada pelo desenvolvedor / criador de interfaces. Os containers Accordion, TabNavigator e ViewStack tambm podem ser aplicados como

compositeInterfaceElements que fazem o papel de exibidores de contedo por demanda. Eles so compostos de outras composies e apenas uma dela exibida por vez. Os controls MXML so um conjunto de elementos de interface perceptveis e utilizveis pelo usurio, como textos, imagens, botes, caixas de seleo de valores, radiobuttons, e assim por diante. Sero mapeados diretamente das classes da Ontologia

81

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 anlise comparando a descrio deste componente com as classes da ontologia e identificado o mapeamento a ser feito. Os componentes de anlise mais complexa so os que devem ser mapeados para a classe CompositeInterfaceElement, pois so 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 instncias das classes da ontologia de widgets abstratos, pode tambm ser realizado para componentes customizados, isto , componentes criados pelo desenvolvedor. Na grande maioria das vezes, estes novos componentes sero mapeados da classe CompositeInterfaceElement, por conter mais de um elemento em sua composio, mas, o desenvolvedor deve fazer esta anlise para cada componente criado, para poder utiliz-lo na descrio dos ADVs estendidos. Suponha que o desenvolvedor crie um novo componente de seleo de valores, com base em um conceito de usabilidade totalmente novo, mas que apenas uma das opes ser selecionada por vez pelo usurio. Este componente deve ser mapeado para a classe SingleChoice, fazendo com que possa ser utilizado na descrio de sistemas futuros que utilizem este componente. Sendo assim, a Ontologia de Widgets Concretos proposta nesta seo deve ser sempre atualizada pelo desenvolvedor que a utiliza com seus novos componentes. A seguir demonstrada a anlise, que foi feita relacionando cada componente do Flex apresentado na seo 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 82

sufixo mx:, indicando que fazem parte do pacote do ncleo 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 observaes: Os elementos devem ser mapeados para subclasses desta classe. B) SimpleActivator: observaes: Eventos externos de mouse ou teclado. componentes mapeados:
B1)

mx:Button Tipo de ativador mais comum. Deve ser mapeado para esta classe a no ser que se queira utiliz-lo como seletor de opes similarmente aos Radiobuttons. Neste caso a propriedade toggle deve ser alterada para true.

B2)

mx:LinkButton Tem as mesmas caractersticas 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 no possui bordas.

C) ElementExhibitor: observaes: Exibio de contedo visual componentes:

C1)

mx:Image 83

Mapeamos os ElementExhibitors para mx:Image quando queremos exibir imagens JPG, GIF e PNG, que podem ser carregadas dinamicamente ou estar embarcadas no executvel. Todos os atributos das classes navegacionais que tenham seu domnio em imagens ou figuras sero mapeados para esta classe.
C2)

mx:Label Dever ser mapeado para esta classe quando o contedo do ElementExhibitor um texto de uma linha conhecido de antemo, por exibir apenas uma linha de texto no editvel. Geralmente utilizado como rtulo ou ttulo de outro elemento de interface, mas pode exibir tambm contedo dinmico.

C3)

mx:ProgressBar Deve ser mapeado para esta classe elementos que faam o controle de progresso de tarefas. Como sugesto, pode ser utilizado para fazer com que o progresso de um determinado processo de interaes entre o usurio e o sistema seja medido em relao s etapas deste processo. A cada etapa cumprida, a barra de progresso avana. Apesar desta sugesto, o componente mx:ProgressBar normalmente utilizado para exibir o carregamento da aplicao ou de arquivos carregados dinamicamente no decorrer da navegao, sendo que, desta maneira, no h mapeamento a partir das classes abstratas.

C4)

mx:Text Exibe mltiplas linhas de texto no editvel. Anlise anloga ao mx:Label.

C5)

mx:ToopTip Este componente utilizado associado com outro componente. Ele exibe um texto popUpquando o usurio passa o mouse sobre o componente pai. 84

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 so do domnio Video. Exibe vdeo no formato [.FLV]. Suporta download progressivo via http e streaming, de arquivos e de cmeras de vdeo. um elemento que no tem controles de reproduo de vdeo, como play e pause, que devem ser implementados separadamente, mapeados a partir de SimpleActivators.

D) IndefiniteVariable: observaes: Captura de dados do teclado. componentes mapeados:

D1)

mx:TextArea Para elementos de entrada de dados do usurio no formato de texto sejam eles opcionais ou no e que tenham mltiplas linhas, o mapeamento dever ser feito para este componente

D2)

mx:TextInput Similar ao TextArea mas com apenas uma nica linha de texto.

85

E) ContinuousGroupMultiple: observaes: seleo 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 usurio troca o valor escolhido, pois a maioria dos componentes faz a escolha do valor visualmente. componentes mapeados:
E1)

mx:HSlider / VSlider Como possvel 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 domnio se tornar um conjunto infinito de valores, os valores de mximo e mnimo do componente devem ser alterados quando o usurio usa os handles.

F) ContinuousGroup: observaes: seleo 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 usurio troca o valor escolhido, pois a maioria dos componentes faz a escolha do valor visualmente.
F1)

mx:HSlider / VSlider Anlogo anlise E1, mas com apenas um nico handle de seleo.

F2)

mx:NumericStepper Seleo de valores numricos.

86

G) DiscreetGroupMultiple: observaes: Seletor de discretos, valores enumerveis. componentes mapeados:

G1)

mx:HSlider / mx:VSlider Se for provido ao usurio uma maneira de inserir duplas de handles linha de seleo, podemos extrair vrios intervalos discretos deste componente.

H) DiscreetGroup: observaes: Seletor de discretos, valores enumerveis. componentes mapeados:

H1)

mx:HSlider / mx:VSlider Se for provido ao usurio uma maneira de inserir duplas de handles linha de seleo, podemos extrair vrios intervalos discretos deste componente.

H2)

mx:NumericStepper Seleo de valores numricos.

I)

MultipleChoices: observaes: Seletor de conjunto de valores, valores enumerveis. componentes mapeados:

I1)

mx:HSlider / VSlider

87

Se for provido ao usurio uma maneira de inserir handles linha de seleo, podemos extrair vrios valores discretos deste componente.
I2)

mx:DateChooser Seletor de datas em formato de calendrio, este componente permite a seleo de mltiplos dias do ms no adjacentes.

I3)

mx:CheckBox Caixa de seleo liga/desliga.

J) SingleChoice: observaes: Seletor de um nico valor, valores enumerveis. componentes mapeados:

J1)

mx:HSlider / VSlider Caso seja utilizado apenas um handle neste componente.

J2)

mx:DateChooser Calendrio com seleo de apenas uma data.

J3)

mx:ComboBox Lista retrtil com apenas uma seleo dentre um conjunto discreto de valores.

J4)

mx:DateField Campo de texto com um boto para exibio de um calendrio para seleo de uma nica data.

88

J5)

mx:RadioButton Conjunto de botes liga/desliga no qual apenas um pode estar ligado por vez.

K) CompositeInterfaceElement: observaes: Elemento composto. componentes mapeados:

K1)

mx:ButtonBar Composio 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 construdos a partir de qualquer outro componente, o que o torna instncia da classe compositeInterfaceElement.

K3)

mx:HorizontalList Lista de Elementos organizados em uma nica linha. Seus elementos internos podem ser construdos a partir de qualquer outro componente, o que o torna instncia da classe compositeInterfaceElement.

K4)

mx:LinkBar Composio apenas de elementos da classe LinkButton. Deve ser utilizado quando existe um compositeInterfaceElement composto apenas de elementos da classe abstrata SimpleActivator. (ver ButtonBar) 89

K5)

mx:List Lista de Elementos organizados em uma nica coluna. Seus elementos internos podem ser construdos a partir de qualquer outro componente, o que o torna instncia da classe compositeInterfaceElement.

K6)

mx:Menu Composio 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 Composio de elementos da classe Menu que e um elemento da classe ButtonBar que faz o controle de exibio dos menus.

K8)

mx:PopUpButton Por ser um elemento de ativao simples, mas com escolha mltipla da sua funo, este componente pode ser considerado como um elemento composto de vrios SimpleActivators.

K9)

mx:RadioButtonGroup Composio 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 aplicaes Flex.

K11)

mx:TabBar 90

 um componente ButtonBar geralmente associado com elementos de navegao como viewstacks. O componente TabNavigator uma associao de um TabBar com vrios viewstacks, mas com esta classe podemos criar mais de uma TabBar para um mesmo controle de navegao.
K12)

mx:TileList Lista de Elementos dispostos em mosaico. Seus elementos internos podem ser construdos a partir de qualquer outro componente, o que o torna instncia da classe compositeInterfaceElement.

K13)

mx:ToggleButtonBar Composio 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 hierrquica em rvore, como em um gerenciador de arquivos. composto de composies cone-texto, que podem ser galhos ou folhas da rvore. -~-

Com esta anlise completa, podemos definir as regras consistncia de mapeamento das classes de widgets abstratos para os componentes MXML que comporo a nova Ontologia de Widgets Concretos. A listagem completa das regras de consistncia se encontra nos anexos. A Figura 4.5 nos mostra as classes da ontologia de widgets abstratos com os componentes MXML relacionados. 91

AbstractInterfaceElement

SimpleActivator Button LinkButton

ElementExhibitor Image Label Text VideoDisplay ToolTip ProgressBar

VariableCapturer

CompositeInterfaceElement AdvancedDataGrid ButtonBar DataGrid HorizontalList LinkBar List Menu MenuBar PopUpButton

IndefiniteVariable TextArea TextInput

PredefinedVariable

PopUpMenuButton RadioButtonGroup SWFLoader TabBar TileList ToggleButtonBar

ContinuousGroupMultiple

ContinuousGroup

DiscreetGroup Multiple HSlider/VSlider NumericStepper

DiscreetGroup

MultipleChoices

SingleChoice

DateChooser CheckBox DateField ComboBox RadioButton ColorPicker

Figura 4.5 - Sobreposio das classes de widgets abstratos Com esta anlise realizada, temos condies de agora em um determinado projeto estender a tabela de definio de widgets abstratos (conforme o exemplo da Tabela 4.2) incluindo os widgets concretos MXML e provendo condies para a aplicao da Extenso 3 proposta neste trabalho. A Tabela 4.3 de definio de widgets concretos MXML determinada conforme exemplo da Tabela 4.2. 92

Tabela 4.3 - Definio de widgets concretos MXML a partir dos widgets abstratos

Classe: Programa de Rdio Atributos nome:String data:String tempo:String Som:Audio origem nos UIDs Item de dado Item de dado Item de dado Item de dado transio(escutar programa) nomeDJ:String Item de dado transio (ver DJ) idxMusicas Estrutura CompositeInterface Element mx:VBox SimpleActivator mx:LinkButton Widgets Abstratos ElementExhibitor ElementExhibitor ElementExhibitor SimpleActivator Widgets Concretos mx:Label mx:Label mx:Label mx:Button

4.3 Extenso 3 - Especificao de ADVs para Flex

Para realizar a construo dos ADVs incluindo o resultado da aplicao dos mapeamentos anteriores, este trabalho apresenta uma simbologia para a representao dos widgets nos ADVs. Cada ADV, ADV aninhado ou atributo acompanhado de um smbolo 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 notao estendida de um ADV, o ADV Flex:

93

A C
@

AbstractInteface CompositeInterfaceElement SimpleActivator ElementExibitor

?
{N} {1} [N] [1] N 1

IndefiniteVariable ContinuousGroupMultiple ContinuousGroup DiscreetGroup Multiple DiscreetGroup MultipleChoices SingleChoice

Figura 4.6 Legenda da representao da classe de widgets abstratos nos ADVs

ADV Boto
@ mx:LinkButton

Figura 4.7 - Exemplo Estrutura do cabealho dos ADV Flex Com a reunio das informaes geradas a partir dos diagramas de classes e contextos navegacionais e da aplicao das extenses 1 e 2 propostas neste trabalho, ADVs so 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 sero chamados de ADVs Primrios, ou ADVs Base. Os ADVs relacionados contextos das classes navegacionais sero chamados de ADVs Secundrios. Os ADVs relacionados a atributos sero considerados os ADVs opcionais. Os ndices do diagrama de contextos navegacionais devem ser descritos por ADVs Especiais, que faro parte do contexto da aplicao e permitiro a navegao para os objetos navegacionais. Esta hierarquia foi criada para acomodar os ADVs em mx:State no 94

momento da implementao do sistema, como explicado na seo 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

classe ndice contexto

esquema de classes emContexto

ndice

contexto

ndice

contexto

Projeto de Navegao Projeto de Interface Abstrata

ADVs Especiais

ADVs Primrios

ADVs Secundrios

ADVs Opcionais

ADVs Opcionais

ADVs Opcionais

Figura 4.8- Mapeamento de entidades navegacionais para ADVs

O ADVs Primrios e Secundrios so mapeados exclusivamente para a classe CompositeInterfaceElement enquanto que seus ADVs internos so 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 extenso conforme a

95

Figura 4.9.a. O mapeamento abstrato representado pelo smbolo no campo abaixo do nome do ADV e o mapeamento concreto pelo nome do componente MXML ao lado. No caso, o ADV Programa de Rdio foi mapeado a partir da classe navegacional Programa de Rdio, portanto deve ser do tipo compositeinterfaceElement e considerado um ADV Primrio. Os atributos nome, data e tempo foram mapeados para a classe abstrata ElementExhibitor e ento para o componente mx:Label compondo ADVs opcionais assim como o restante dos ADVs internos. A Figura 4.9.b mostra o ADV secundrio correspondente ao contexto Programa de Rdio por Data, com um calendrio para seleo de outro programa neste contexto e botes de avano e retrocesso dentro do contexto.
ADV Programa de Rdio C
mx:Panel

nome
mx:Label

som
@ mx:Button

ADV Programa de Rdio por Data C

mx:Panel

data
mx:Label

nome
mx:Label

som
@ mx:Button

tempo
mx:Label

data
mx:Label

data 1
mx:DateChooser

nomeDJ
@ mx:LinkButton

tempo
mx:Label

ADV musicas C
mx:VBox isRepeated

nomeDJ
@ mx:LinkButton

nome
mx:Label

ADV musicas C
mx:VBox

artista
mx:Label

anterior
@ mx:LinkButton

prximo
@ mx:LinkButton

(a)

(b)

Figura 4.9 - ADV Programa de rdio

96

4.4 Extenso 4 - Especificao de view states do Flex

Como os view states so organizados de maneira hierrquica, a organizao dos ADVs em Primrios, secundrios e opcionais nos permite um mapeamento direto para os view states do Flex.
A criao de uma interface em um ambiente de programao ActionScript realizada atravs de uma estrutura de dados que representa uma lista de objetos perceptveis, chamada de DisplayList. Se algum objeto est presente na interface de exibio ao usurio, ento ele est registrado nesta lista, de forma que um objeto instanciado do sistema que no foi adicionado DisplayList, ou que foi retirado da mesma, um objeto que apenas no tem interface visual sendo exibida, mas continua ativo. (MOOCK, 2007)

Fazendo um paralelo com o OOHDM, no mtodo OOHDM existe a varivel contextoPerceptivo, uma varivel de contexto que tem a mesma funo da DisplayList:
Uma varivel reservada, contextoPerceptivo, usada para indicar modificaes no espao perceptivo (o conjunto de objetos perceptveis em dado momento). Quando se deseja tornar um objeto perceptvel, ele acrescentado ao contextoPerceptivo. Os elementos retirados deste contexto deixam de ser percebidos. (SCHWABE ROSSI, 1996).

Uma aplicao Flex pode utilizar destes conceitos fazendo inseres e retiradas de objetos da DisplayList e tambm alteraes nas propriedades e estilos destes objetos de acordo com alteraes de estados de interface. Podemos implementar os mx:Statede acordo com os ADVs. A partir de um ADV primrio, implementado o base state do componente que representa esta classe. Os ADVs secundrios, so implementados como

97

estados filhos do base state. Os estados secundrios podem tambm ter mais de um estado de interface, que continuam sendo considerados secundrios. Os mx:State compreendem no s estados de interface relativos a uma aplicao ou ADV, mas tambm a de um simples componente ou estado de um ADV, extrados dos ADVs opcionais. No exemplo de modelagem, o atributo som foi mapeado para um elemento mx:Button, pois ser um boto que aciona a exibio do programa de rdio determinado. Suponha que o boto possa estar desabilitado quando exatamente o progrma de rdio que est sendo pesquisado o que est sendo exibido, ento, este boto ser um componente com dois estados, um ativo e um inativo. No estado ativo, o boto 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 aplicao, assim, se este boto estiver presente em mais de um view state da aplicao, seu estado ser mantido quando da troca de view state ocorrer. Este modelo de implementao permite a descrio de elementos da interface, desde os mais primitivos aos mais complexos, provendo recursos para especificao de cada um dos elementos de maneira independente, relacionando os eventos que ocorrem entre um e outro.
Os aspectos dinmicos da interface lidam tanto com transformaes de interface dentro de um ADV como com transformaes de interface envolvendo navegao. Em ambos os casos, a natureza orientada a eventos dos ADVs e o poder expressivo de seu modelo de transio de estados permite a implementao destas transformaes em um estilo simples, de baixo para cima. Comeando-se com ADVs de mais baixo nvel, definimos scripts para cada evento significativo com que o objeto pode lidar. (ROSSI, 1996).

98

Esta afirmao vlida tambm para a implementao dos mx:States, que podem ser realizados em vrios nveis desde cada objeto at a aplicao como um todo. Aprimorando a o exemplo de modelagem de aplicao, ser apresentado agora parte do diagrama de classes navegacionais, o diagrama de ADVs, e o cdigo MXML correspondente que fazem parte do exemplo de como realizar o mapeamento para os view states.

ADV Programa de Rdio C

mx:Panel

nom e
mx:Label

som
@ mx:Button

data
mx:Label

tem po
mx:Label

nomeDJ
@ mx:LinkButton

ADV m usicas C
mx:TileList isRepeated

nome
mx:Label

artista
mx:Label

ADV Primrio ADVs Secundrios

ADV Programa de Rdio por Data C

mx:Panel

ADV Programa de Rdio por DJ C

mx:Panel

ADV Program a de Rdio por Nome C

mx:Panel

data 1
mx:DateChooser

fotoDJ
mx:DateChooser

anterior
@ mx:LinkButton

prximo
@ mx:LinkButton

anterior
@ mx:LinkButton

prxim o
@ mx:LinkButton

anterior
@ mx:LinkButton

prxim o
@ mx:LinkButton

ADV idxProgramasDJ
C mx:TileList

Figura 4.10 - Diagrama de ADVs

A partir deste diagrama de ADVs, a interface pode comear a ser construda. Implementa-se primeiro o ADV Primrio correspondente ao nodo navegacional Programa de 99

Rdio, 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 definio crua deste componente em MXML que est declarado no arquivo UIProgramaRadio.mxml :
1 2 <mx:Panel xmlns:mx="http://www.adobe.com/2006/mxml"> </mx:Panel>

Cada elemento interno do ADV Programa de Rdio 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 Secundrio para um mx:State como no exemplo a seguir:
1 <mx:Panel xmlns:mx="http://www.adobe.com/2006/mxml"> 2 3 <!-- Declarao da varivel states, 4 que indica que este mx:Panel ter mais de um estado --> 5 <mx:states> 6 7 <!--Declarao do primeiro estado: Programa de Rdio 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="prximo"/> 17 </mx:AddChild> 18 </mx:State> 19 20 <!--Declarao do segundo estado: Programa de Rdio 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">

100

26 <mx:LinkButton label="prximo"/> 27 </mx:AddChild> 28 29 <!--Declarao do terceiro estado: Programa de Rdio 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="prximo"/> 39 </mx:AddChild> 40 </mx:State> 41 </mx:states> 42 43 <!--Declarao do base state: Programa de Rdio--> 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 so determinados os valores dos atributos dos componentes baseados nos atributos dos objetos navegacionais os quais devem ser implementados naturalmente como classes ActionScript. So tambm atribudos os eventos aos componentes, por exemplo determinando o mtodo a ser chamado caso o usurio aperte o boto do mouse sobre o componente. A troca de estado feita atravs da mudana da varivel pblica currentState:String e deve ser realizada antes que se referencie os objetos adicionados a displayList. A seguir so sugeridas algumas dicas e de modelagem de ADVs e uso do MXML

1. Alguns dos componentes so classificados como navegadores, pois realizam a tarefa de exibir contedo sob demanda como comentado ao final da seo 3.1.3. So eles: Accordion TabNavigator 101

ViewStacks

Em uma composio de ADVs agrupados em XOR, ou seja, que representam estados exclusivos da interface e no so percebidos simultaneamente pelo usurio, 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 rdio do contexto Programa de Rdio por DJ pode conter alm do ADV Musicas que uma lista de msicas que fazem parte daquele programa de rdio, 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 compe um ADV pai chamado de ADV Informaes que mapeado para um dos componentes sugeridos, em vez de se criar view states para cada situao (um mostrando as msicas e outro os programas do DJ). 2. A maioria dos componentes MXML (todos que sejam instncias 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 ativao pelo usurio sem que haja a necessidade de trocar de view state, sendo que sua criao deve se reavaliada dependendo da complexidade da alterao da interface.

3. Elementos que so do tipo compositeInterfaceElement

que tem a propriedade

isRepeated = verdadeiro so elementos que repetem um deteminado conjunto de dados de acordo com uma regra de exibio de elementos. Eles podem ser mapeados para os componentes que representam listas de itens. Estes controles permitem ao usurio da aplicao rolar a lista de itens e selecionar um ou mais itens desta lista. Todos os componentes de lista do Flex so especializaoes da 102

classe mx:ListBase, incluindo mx:DataGrid, mx:HorizontalList, mx:List, mx:Menu, mx:TileList, e mx:Tree.

No exemplo do Programa de Rdio, a lista de msicas pode ser uma lista ordinria 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 composio 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 so classes que permitem a exibio de janelas independentes. O primeiro uma janela modal geralmente utilizada para exibir mensagens ao usurio e obter confirmaes do mesmo. O segundo pode carregar em uma janela separada qualquer aplicao ou componente Flex. A definio original dos ADVs considera a modelagem de interfaces do tipo pop-up, ento, quando forem descritas interfaces deste tipo, podemos mapear o ADV para estas classes.

5. As transies MXML so eventos relacionados a efeitos de mudanas de propriedades, como dimenses, canal alpha, efeitos visuais e visibilidade. As trasies so indicadas para cada objeto e na mudana de um view state para outro so consideradas, realizando os passos indicados em ordem. Por exemplo, podemos fazer uma mudana de view state na qual um componente sai da tela com uma animao para a esquerda, e outro aparece esmaecendo em seguida. As transies podem ser indicadas nos diagramas de ADVs entre um estado e outro de um determinado ADV, ou entre ADVs secundrios, quando h troca de contexto navegacional. 103

5 Modelagem de Aplicao OOHDM Flex

A aplicao de exemplo utilizada neste trabalho um conjunto de pequenas aplicaes desenvolvidas para um artista grfico. Este artista produtor de desenhos que so estampados em camisetas, e o sistema uma loja na qual o usurio pode montar sua prpria camiseta de acordo com modelos, estampas e cores diferentes. Juntamente com esta loja de camisetas, existe uma loja de produtos comuns (tradicional), que no necessitam de personalizao com a camiseta. Tambm h uma rdio virtual, na qual acontecem programas ao vivo semanalmente, que ser automaticamente exibido quando o usurio adentra no sistema. Alm da rdio ao vivo, o usurio tem a opo de fazer uma pesquisa nos programas de rdio que foram exibidos anteriormente, obtendo informaes sobre o programa de rdio e o DJ que criou este programa. Na primeira iterao, foi extrado o conjunto geral de informaes do domnio, procurando atingir todos os pontos do sistema. Foram conceitualizados a maioria dos requisitos, porm a partir da etapa de projeto navegacional, apenas os objetos relacionados Rdio on-line foram contempladas. Na segunda iterao foi aprimorado o modelo relativo Rdio on-line e modelada a loja comum. Esta base da loja ser utilizada no sistema de camisetas pela herana da classe camisetaPersonalizada em relao a produto. A terceira iterao a sugesto de modelagem do sistema de montagem de camisetas.

104

ITERAO 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: usurio, sistema Tipo: Descrio: O usurio escolhe pesquisar os programas de rdio da emissora. O sistema exibe uma lista de programas de rdio, exibindo o nome a data e o nome do DJ. O usurio 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 rdio, mostrando o nome, a data de exibio, 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 msica e o nome do intrprete. O usurio pode escolher escutar o programa corrente ou ver os detalhes do DJ em questo.

UID: Pesquisar a rdio

<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

105

MODELAGEM CONCEITUAL
O diagrama de classes conceituais completo est no Anexo 8.2

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

PROJETO NAVEGACIONAL

Programa de Rdio nome: String data: String tempo: String som: Audio NomeDJ: nomeDJ de DJ por Programa

DJ nome: String perfil: Text foto: Imagem programas: nome, data de Programas por DJ

Programa de Rdio nome Radio data DJ por nome por data por DJ

DJ por nome

106

Programa de Rdio nome: String data: String tempo: String som: Audio NomeDJ: nomeDJ de DJ por Programa

Programa de Rdio por DATA proximo: anchor(programa por DATA) anterior: anchor(programa por DATA)

Programa de Rdio por DJ fotoDJ: foto de DJ idxProgramas: nome, data de Programas por DJ proximo: anchor(programa por DJ) anterior: anchor(programa por DJ)

Programa de Rdio por NOME proximo: anchor(programa por NOME) anterior: anchor(programa por NOME)

PROJETO DE INTERFACE ABSTRATA

ADV Primrio

ADV Programa de Rdio C

mx:Panel

ADV DJ C som
@ mx:Button mx:Panel

nom e
mx:Label

nom e
mx:Label

foto
mx:Button

data
mx:Label

perfil
mx:Label

tempo
mx:Label

ADV idxProgram asDJ C

mx:TileList

nomeDJ
@ mx:LinkButton

ADVs Secundrios

ADV Programa de Rdio por Data C

mx:Panel

ADV Programa de Rdio por DJ C

mx:Panel

ADV Programa de Rdio por Nome C

mx:Panel

data 1
mx:DateChooser

fotoDJ
mx:DateChooser

anterior
@ mx:LinkButton

prximo
@ mx:LinkButton

anterior
@ mx:LinkButton

prximo
@ mx:LinkButton

anterior
@ mx:LinkButton

prximo
@ mx:LinkButton

ADV idxProgramasDJ
C mx:TileList

107

ADVs Opcionais

ADV idxProgramasDJ C
mx:TileList isRepeated

itemListaProgramasDJ C
mx:canvas

nome
@ mx:Label

Data
@ mx:Label

ADVs Especiais

ADV ndiceProgramaNome C
mx:TileList isRepeated

ADV ndiceProgramaData C
mx:TileList isRepeated

ADV ndiceProgramaDJ C
mx:TileList isRepeated

itemListaProgramaNome C
mx:canvas

itemListaProgramaData C
mx:canvas

itemListaProgramaDJ C
mx:canvas

nome
@ mx:Label

Data
@ mx:Label

nomeDJ
@ mx:Label

Data
mx:Label

nome
mx:Label

Data
mx:Label

nomeDJ
mx:Label

nomeDJ
mx:Label

nome
mx:Label

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

108

6 Consideraes Finais
Neste trabalho o mtodo OOHDM foi estendido para ser utilizado na publicao de aplicaes construdas no ambiente Flex. Quando da anlise do mtodo, a caracterstica em comum mais evidente na relao entre OOHDM e Flex foi a criao de interfaces com o usurio, de maneira que se estabeleceu o paralelo entre o Projeto de Interfaces Abstratas do OOHDM e os view states do Flex. A utilizao das extenses propostas neste trabalho faz com que o projeto da interface com o usurio seja feito de acordo com as capacidades e caractersticas dos componentes MXML. A partir das ontologias de widgets de interface foi possvel criar elementos de projeto que funcionam como estruturas para realizar o mapeamento direto do projeto de interface abstrata para a implementao do sistema, extraindo dos ADVs estendidos para Flex informaes para a construo do cdigo MXML que compe parte da estrutura de uma aplicao Flex. Perante a enorme quantidade de sistemas sendo construdos na atualidade, a utilizao de um mtodo para a construo de sistemas implementados para a internet se faz cada vez mais importante e presente. O Projeto de Navegao, a reusabilidade de componentes e objetos conceituais, a rastreabilidade entre os elementos abstratos de projeto e os concretos de implementao e a capacidade de gerir grandes quantidades de dados fazem do mtodo OOHDM um expoente no campo dos estudos de sistemas hipermdia. Atualmente o Flex considerado um dos ambientes mais completos para o desenvolvimento de aplicaes hipermdia. Isso se deve pela sua integrao com o Flash para publicao de contedo interativo com interfaces grficas avanadas, por sua integrao com servios web atravs de server-side scripts e por ser publicado em uma mquina virtual (Flash Player) multi-plataforma. 109

A integrao destas duas esferas - OOHDM e Flex- prov recursos para a construo de sistemas hipermdia os quais tem poderosos aliados para a exibio de contedo para o usurio, o Flex e o Flash. O Flex implementa a interface com o usurio, o controle da lgica do sistema, o acesso ao sistema de informaes, as requisies HTTP; enquanto o Flash gera grficos e componentes de programao inovadores no que diz respeito a usabilidade e apresentao visual. Com as descries providas pelo mtodo OOHDM, a construo de sistemas hipermdia em Flex se torna organizada e claramente descrita. Apesar deste trabalho ter seu enfoque em aplicaes feitas em Flex, as extenses sugeridas (principalmente as extenses 1, 2 e 3) podem ser aplicadas em outras linguagens de programao. Neste caso, os elementos descritos nos ADVs podem se manter expandidos, contendo a informao 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 construo do estudo de caso foram constatadas algumas deficincias em relao integrao das etapas do OOHDM quando se buscava a modelagem do sistema para a implementao em Flex, problemas os quais as extenses 1 e 3 propostas neste trabalho tentam resolver. Tambm foram encontrados modelos de implementao em Flex (os view states) que no tinham correspondncia direta com alguma primitiva do OOHDM, sendo necessria a construo de um modelo abstrato hierrquico dos ADVs para suportar este modelo. Devido ao fato de a aplicao modelada no estudo de caso ser de pequenas propores no que diz respeito ao nmero de classes navegacionais, no se fez necessria a utilizao dos cartes de navegao (OOHDM) e mesmo assim no se perdeu informao para a construo do sistema. Apesar disso, as extenses propostas no excluem os cartes de navegao e estes podem ser utilizados sempre que o volume de classes navegacionais no sistema no for facilmente gerencivel. 110

Trabalhos Futuros
A seguir so enumerados alguns trabalhos futuros

Implementao das classes OOHDM em ActionScript para construo de uma ferramenta de gerao automtica de interfaces concretas similar ferramenta idealizada por Sabrina Moura (Moura 2004). Neste trabalho, a obteno de dados das classes navegacionais persistidas no banco de dados seria feita atravs de comandos OOHDM quando da requisio HTTP da aplicao, o que geraria uma compilao on-the-fly que construiria a interface de acordo com dados dinmicos.

Utilizao das extenses propostas no desenvolvimento de outras aplicaes, para efeitos de validao. Estas aplicaes deveriam incluir diversos tipos de widgets de interface, a fim de experimentar ao mximo os recursos do mtodo OOHDM estendido.

Continuao do desenvolvimento dos ADVs Flex para que contenham informaes de transies entre os view states (mx:Transitions), ativaes de UIs (e outras caractersticas relevantes implementao em Flex.

111

7 Bibliografia
COENRAETS, C. An overview of MXML: The Flex markup language. Adobe - Developer Center. 2003. disponvel 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. disponvel <http://www.adobe.com/macromedia/events/john_gay>. Acesso em: 18 abr. 2008. em

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 Semntica. PUC-Rio, Brasil, 2004. REMCULO, L. R. Personalizao de Diagramas de Interao do Usurio e Mapeamento para a Ontologia de Widgets Abstratos, Trabalho de concluso de curso, UFSC, Brasil, 2005 ROSSI, G. Um mtodo orientado a objetos para o projeto de aplicaes hipermdia. Tese de Doutorado, Puc-Rio, Brasil, 1996 SCHWABE, D. OOHDM Wiki :: Summary of OOHDM. 2005 disponvel 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 Interao com o Usurio em Aplicaes Hipermdia. 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. disponvel em <http://www.adobe.com/products/flex/overview/> . Acesso em: 15 mai. 2008. ADOBE. Adobe Flash Player: PC Penetration. 2008b. disponvel em <http://www.adobe.com/products/player_census/flashplayer/PC.html/> . Acesso em: 5 jun. 2008. 112

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

113

8 Anexos 8.1 Casos de uso da aplicao de exemplo

Caso de Uso: Montar camiseta Atores: Comprador Tipo: Descrio: Um comprador (usurio cadastrado) escolhe a opo 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 opo de armazenar esta camiseta montada, adicion-la ao carrinho de compras, comear novamente a montagem de uma nova camiseta ou voltar vitrine. Caso de Uso: Escolher camiseta da vitrine Atores: Comprador Tipo: Descrio: Um comprador (usurio) 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: Descrio: Um comprador percorre a lista da loja de produtos simples (que no requerem personalizao 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: Descrio: Um comprador (usurio cadastrado) aps 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 informaes de quantidade e preo ao passo que o usurio define novos e passa para o passo seguinte, a confirmao do pedido. Com o pedido e preo total revisado e confirmado, ele escolhe uma dentre as formas de pagamento e passa para o seguinte passo, a insero de dados (endereo de entrega, numero do carto) para ser gerado o pedido. Com o pedido gerado o comprador passa ento 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 confeco fsica das camisetas para o envio, e depois de confirmado com o fornecedor, envia um email de confirmao do prazo de entrega das camisetas.

114

Caso de Uso: Escutar rdio ( um use case?) Atores: Comprador Tipo: Descrio: Enquanto usa o sistema, o comprador estar escutando musicas ao durante duas horas a cada duas semanas em um programa ao vivo. Fora deste horrio, o programa a ser exibido ser o ltimo realizado. Caso de Uso: Pesquisar a radio Atores: usurio, sistema Tipo: Descrio: O usurio escolhe pesquisar os programas de rdio da emissora. O sistema exibe uma lista de programas de rdio, exibindo o nome a data e o nome do DJ. O usurio 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 rdio, mostrando o nome, a data de exibio, 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 msica e o nome do intrprete. O usurio pode escolher escutar o programa corrente ou ver os detalhes do DJ em questo. Caso de Uso: Ver galeria de fotos/video Atores: Comprador Tipo: Descrio: O comprador pode ver fotos e videos procurando em uma galeria visual atravs de miniaturas dos mesmos e ento obter mais informaes selecionando um deles. Nestas informaes esto incluidos o contedo original, e dados extras como autor, descio, data e links externos. Caso de Uso: Fazer Cadastro de Usuario Atores: Usurio comum Tipo: Descrio: O usurio quer fazer seu registro no sistema e fornece dados cadastrais. a partir deste ponto, o usurio recebe status de comprador e pode fazer o checkout no sistema de montagem de camisetas. (mail de confirmao?) Caso de Uso: Fazer conexo (login) Atores: Usurio comum Tipo: Descrio: O usurio entra com seu email e senha previamente cadastrados e habita a navegao do comprador (pode utilizar o carrinho de compras, etc). Caso de Uso: inserir novas camisetas Atores: administrador Tipo: Descrio: O administrador seleciona a camiseta a ser inserida no sistema e fornece a informao da cor desta camiseta. A partir da cor da camiseta, ser possvel escolher um determinado conjunto de cores para as estampas.

115

Caso de Uso: inserir novas estampas Atores: administrador Tipo: Descrio: O administrador seleciona a estampa a ser inserida no sistema e fornece a informao de quantas cores tem a estampa e as cores iniciais. O sistema ento exibe todas as camisetas cadastradas no sistema e o administrador seleciona quais camisetas podero receber a estampa a ser inserida. Caso de Uso: inserir novos produtos simples Atores: administrador Tipo: Descrio: O administrador seleciona a imagem do produto, e insere os dados e descrio, preo do produto. Caso de Uso: administrar usurios Atores: administrador Tipo: Descrio: O administrador pode inserir, editar dados cadastrais e apagar usurios do sistema. Os dados de carto de crdito devem ser criptografados. Caso de Uso: administrar rdio Atores: administrador Tipo: Descrio: O administrador faz o upload do programa de radio (arquivo de som) e preenche informaes das musicas e do dj em questo.

116

Diagrana de UIDs

UID Fazer Login

opes de administrao fazer cadastro

inserir/ apagar/editar modelo

opes do sistema administrar camisetas

inserir/ apagar/editar estampa

montar camisetas

administrar vitrine

ver vitrine administrar rdio ver detalhes camiseta usar loja comum ver detalhes produto ver carrinho de compras inserir/ apagar/editar programa de rdio inserir/ apagar/editar programa de rdio inserir/ apagar/editar usurio Pesquisar Rdio ver detalhes Programa de Rdio administrar usurios inserir/ apagar/editar usurio

8.2 Diagrama de UIDs para a aplicao de exemplo

117
ver detalhes DJ administrar galeria multimdia

ver galeria multimdia

administrar loja

pesquisar compras

Diagrama de Classes Conceituais

CamisetaPersonalizada Comprador 0..* 0..1 1 faz incli 0..* data valor Total 0..* 1..* monta nome preo Compra Produto 0..* cdigo

0..*

0..* relaciona com

contm contm 1 Estampa Artista Grfico 0..* cria nome sobrenome email senha descrio homepage foto 1 Usurio desenho nmero de cores cores padro categoria de preo Administrador

1..*

tipo cpf/cnpj rg sexo data nascimento endereo CEP cidade estado pas telefone

ProdutoComum descrio estoque foto

Modelo

tipo imagem preo

8.3 Diagrama de Classes conceituais da aplicao de exemplo

118
0..* contm 1..4 Cor Tinta nmero CMYK DJ 1 perfil foto cria 0..* Programa de Rdio contm 0..* 1..* nome data tempo som Cor Playlist ordem

0..*

tingido de

Cor Tecido

nmero comercial

Msica 1..* nome 1 executada por

Intrprete nome

nome valor RGB

8.4 Regras de consistncia Ontologia de Widgets Concretos estendida

:SimpleActivator a owl:Class; rdfs:subClassOf awo:AbstractInterfaceElement; rdfs:subClassOf [a owl restriction; owl:allValuesFrom [a owl:Class; owl:oneOf (cwo:Button cwo:LinkButton) ]; owl:onProperty awo: MapsTo ]. cwo:Button a

cwo:ConcreteInterfaceElement.

cwo:LinkButton a cwo:ConcreteInterfaceElement. //------------------------------------------------------------------------

:ElementExhibitor a owl:Class; rdfs:subClassOf awo:AbstractInterfaceElement; rdfs:subClassOf [a owl restriction; owl:allValuesFrom [a owl:Class; owl:oneOf (cwo:Image cwo:Label cwo:Progressbar cwo:Text cwo: ToolTip cwo:VideoDisplay) ]; owl:onProperty awo: MapsTo ]. cwo:Image a cwo:Label a

cwo:ConcreteInterfaceElement.

cwo:ConcreteInterfaceElement.

cwo:ProgressBar a cwo:ConcreteInterfaceElement. cwo:Text a

cwo:ConcreteInterfaceElement.

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

:IndefiniteVariable

119

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

120

: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

121

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

122

cwo:TabBar 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:Menu a cwo:Tree a

cwo:TileList

cwo:ToggleButtonBar

cwo:ConcreteInterfaceElement.

cwo:ConcreteInterfaceElement.

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 Apresentao Visual

123

Accordion

ApplicationControlBar

HBox

Canvas

124

ControlBar

Form

Grid

Panel

125

TabNavigator

ViewStack

Control MXML Button

Apresentao visual

ButtonBar

CheckBox

ColorPicker

ComboBox

126

DataGrid

DateChooser

DateField

HorizontalList

HSlider / VSlider

Image

imagem (jpg, gif ou png)

127

Label LinkBar

Label

LinkButton

List

Menu

MenuBar

128

NumericStepper

PopUpButton

PopUpMenuButton

ProgressBar

RadioButton RadioButtonGroup

TabBar

Text

129

TextArea

TextInput

TileList

ToggleButtonBar

ToolTip

Tree

130