TCC Pedro Germani Ghiorzi - Rascunho Relatrio Final

5/10/2018 TCC Pedro Germani Ghiorzi - Rascunho Relatrio Final - slidepdf.com

http://slidepdf.com/reader/full/tcc-pedro-germani-ghiorzi-rascunho-relatrio-final

UNIVERSIDADE FEDERAL DE SANTA CATARINA – UFSC

CENTRO TECNOLÓGICO – CTC

DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA – INE

CURSO DE CIÊNCIAS DA COMPUTAÇÃO

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

aplicações hipermídia em Flex

Pedro Germani Ghiorzi

Profª. Orientadora: Patrícia Vilain

Trabalho de conclusão de curso apresentado

como parte dos requisitos para obtenção do

grau de Bacharel em Ciências da

Computação

FLORIANÓPOLIS, 2008/1



Pedro Germani Ghiorzi

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

aplicações hipermídia em Flex

Trabalho de conclusão de curso apresentado como

parte dos requisitos para obtenção do grau deBacharel em Ciências da Computação

_________________________________ Orientadora: Patrícia Vilain

Banca examinadora

________________________________ Leandro José Komosinski

__________________________________ Ricardo Pereira e Silva

Florianópolis, Junho de 2008



DEDICATÓRIA (S) ( opcional ): folha seguinte



AGRADECIMENTO (S) ( opcional ): folha seguinte



SUMÁRIO

1 INTRODUÇÃO .................................................................................... 10 2 HIPERMÍDIA E OOHDM. ........................................................................ 14

2.1 HIPERMÍDIA........................................................................................................... 14 2.2 OOHDM............................................................................................................... 17 2.3 ETAPAS DO MÉTODO OOHDM ............................................................................... 19

2.3.1 Análise de requisitos ........................................................................................ 19 2.3.2 Modelagem conceitual ..................................................................................... 22 2.3.3 Projeto de navegação ...................................................................................... 24 2.3.4 Projeto da interface abstrata ............................................................................ 28 2.3.5 Implementação ................................................................................................ 41

3 FLEX E FLASH ................................................................................... 43 3.1 FLEX .................................................................................................................... 43

3.1.1 Versões lançadas e features associadas ......................................................... 44 3.1.2 Linguagens de programação. .......................................................................... 46 3.1.3 Criação de interfaces no Flex .......................................................................... 51

3.2 FLASH .................................................................................................................. 70 4 A PROPOSTA..................................................................................... 74

4.1 EXTENSÃO 1 - ESPECIFICAÇÃO DOS WIDGETS ABSTRATOS....................................... 76 4.2 EXTENSÃO 2 - ESPECIFICAÇÃO DOS WIDGETS CONCRETOS MXML .......................... 81 4.3 EXTENSÃO 3 - ESPECIFICAÇÃO DE ADVS PARA FLEX............................................... 93 4.4 EXTENSÃO 4 - ESPECIFICAÇÃO DE VIEW STATES DO FLEX ........................................ 97

5 MODELAGEM DE APLICAÇÃO OOHDM – FLEX ....................................... 104 6 CONSIDERAÇÕES FINAIS................................................................... 109

TRABALHOS FUTUROS..................................................................................................... 111 7 BIBLIOGRAFIA ................................................................................. 112 8 ANEXOS ......................................................................................... 114

8.1 CASOS DE USO DA APLICAÇÃO DE EXEMPLO .......................................................... 114 8.2 DIAGRAMA DE UIDS PARA A APLICAÇÃO DE EXEMPLO ............................................ 117 8.3 DIAGRAMA DE CLASSES CONCEITUAIS DA APLICAÇÃO DE EXEMPLO......................... 118 8.4 REGRAS DE CONSISTÊNCIA ONTOLOGIA DE WIDGETS CONCRETOS ESTENDIDA ....... 119 8.5 INTERFACE VISUAL DE COMPONENTES MXML ...................................................... 123



LISTA DE FIGURAS

Figura 2.1- UID Pesquisar Rádio .......................................................................................................... 22 Figura 2.2 – Diagrama de Classes Conceituais.................................................................................... 23 Figura 2.3 – Diagrama de Classes Navegacionais ............................................................................... 25 Figura 2.4 - Diagrama de Contextos Navegacionais ............................................................................ 26 Figura 2.5- Classes "emContexto" do nodo navegacional "Programa de Rádio" ................................ 27 Figura 2.6 - Diagrama de Classes da Ontologia de Widgets Abstratos ............................................... 31 Figura 2.7 - Regra de consistência de Mapeamento Concreto ............................................................ 39 Figura 2.8 – Abstract Data View para Programa de Rádio ......................................... .......................... 41 Figura 3.1 - Esquema de publicação de aplicações Flex. ......................................... .......................... 46 Figura 3.2 – Esquema de publicação de Aplicações Flex .................................................................... 49 Figura 3.3 – Exemplo simples de aplicação Flex ................................................................................. 51 Figura 3.4 - Dois estados de uma aplicação. À esquerda, o base state e à direta, o estado "Registro".............................................................................................................................................................. 55 Figura 3.5 – Tela do Future Splash Animator ....................................................................................... 72 Figura 4.1 – Esquema simplificado do processo do método OOHDM ................................................. 74 Figura 4.2 – Esquema do processo OOHDM estendido para criação de sistemas Flex. .................... 75

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

Figura 4.4 - Exemplo de interface para seleção múltipla em um intervalo finito .................................. 80 Figura 4.5 - Sobreposição das classes de widgets abstratos ............................................................... 92 Figura 4.6 – Legenda da representação da classe de widgets abstratos nos ADVs ........................... 94 Figura 4.7 - Exemplo Estrutura do cabeçalho dos ADV Flex ............................................................... 94 Figura 4.8- Mapeamento de entidades navegacionais para ADVs ...................................................... 95 Figura 4.9 - ADV Programa de rádio .................................................................................................... 96

Figura 4.10 - Diagrama de ADVs .......................................................................................................... 99



LISTA DE CÓDIGOS-FONTE

Código Fonte 3.1 - Exemplo de Aplicação MXML ............................................................... 50 Código Fonte 3.2 - Exemplo de aplicação MXML + ActionScript ......................................... 50 Código Fonte 3.3 - Exemplo de implementação de view states .......................................... 53



LISTA DE TABELAS

Tabela 2.1 - Etapas do Processo OOHDM .......................................................................... 18 Tabela 4.1 Mapeamento de elementos dos UIDs para a Ontologia de Widgets Abstratos . 77 Tabela 4.2- Exemplo de definição de widgets abstratos ...................................................... 80 Tabela 4.3 - Definição de widgets concretos MXML a partir dos widgets abstratos ............. 93



10

1 Introdução

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

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

tecnologias rapidamente.

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

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

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

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

as “aplicações Flash”1

deixam de ser apenas elementos componentes de um sistema

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

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

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

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

reusabilidade e manutenção.

Com o intuito de melhorar o desenvolvimento em Flex de sistemas hipermídia, isto é,sistemas que trabalham com informações que são coleções de nodos multimídia (textos,

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

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

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

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

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

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

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

projeto de interfaces com o usuário.

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



11

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

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

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

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

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

Modelagem Conceitual, Projeto de Navegação, Projeto de Interface Abstrata e

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

cada nova iteração.

OBJETIVO GERAL

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

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

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

OBJETIVOS ESPECÍFICOS

1. Estudo do método OOHDM, a fim de estabelecer uma compreensão

aprofundada sobre o método;

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

no Flex;

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

Interface Abstrata, e de Implementação sejam direcionadas para odesenvolvimento de aplicações hipermídia em Flex;

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

desenvolvimento de um protótipo implementado em Flex.



12

JUSTIFICATIVA

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

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

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

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

segundo.

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

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

a evitar ambigüidades no processo de desenvolvimento devido às representações

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

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

tornar este desenvolvimento mais eficiente.

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

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

método OOHDM, suas etapas e processos envolvidos.

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

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

especificação das classes da linguagem ActionScript 3.0.

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

construção de sistemas hipermídia utilizando o Flex como ambiente de programação.Também são sugeridas algumas dicas de implementação utilizando algumas técnicas ou

componentes específicos do Flex.



13

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

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

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

trabalho e sugere alguns trabalhos futuros.



14

2 Hipermídia e OOHDM.

2.1 Hipermídia

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

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

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

gerenciamento de informações (Xanadu), em que todos os documentos gerados

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

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

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

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

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

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

sistema.

Analisando este contexto, Vilain (2002) constata que:

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

informação, quando implementadas na WWW, também incorporam o

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

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

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

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

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

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

usuário.



15

Para Zhang (2004, p. 2)

[...] existem 4 regras principais para determinar se um sistema pode ser

considerado de hipermídia:

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

igualmente numerosos;

2. Os fragmentos se inter-relacionam;

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

dado momento;

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

Segundo Koch (1999) ainda estamos no começo do aprendizado de como

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

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

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

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

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

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

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

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

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

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

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

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

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



16

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

et al. (1993):

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

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

interconectar apenas as partes mais importantes e significativas da

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

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

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

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

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

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

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

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

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

sem perder a propriedade de ser altamente confiável.

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

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

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

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

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

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

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

usuário a cada estado do sistema.



17

2.2 OOHDM

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

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

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

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

separação entre a modelagem conceitual do sistema da modelagem navegacional,

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

OOHDM considera o processo de desenvolvimento da aplicação

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

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

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

mistura de estilos iterativos e incrementais de desenvolvimento; em cada

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

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

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

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

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

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

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

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

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

da base de dados, dos objetos conceituais;

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

introdução do conceito de contexto navegacional;

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



18

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

precisam ser feitas apenas quando da implementação.

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

processo de desenvolvimento OOHDM.

Tabela 2.1 - Etapas do Processo OOHDM

Etapa Artefatos Formalismos Mecanismos Consideraçõesde Projeto

Análise deRequisitos

Casos de uso,Anotações

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

Análise decenários e casosde uso,Entrevistas,

MapeamentoUID – modeloconceitual

Captura dosrequisitos dodomínio daaplicação

ModelagemConceitual

Classes,Subsistemas,Relações,Atributos

Modelo Orientado aObjeto, Padrões deprojeto.

Classificação,Agregação,Generalização eEspecialização

Modela asemântica dodomínio daaplicação

ProjetoNavegacional

Nodos, Âncoras,Estruturas deacesso, Contextosnavegacionais,Transformações

navegacionais

Visões Orientadas aobjeto, State charts Orientados a objeto,Classes decontexto, Padrões

de Projeto, Cenárioscentralizados nousuário.

Classificação,Agregação,Generalização eEspecialização

Leva em contaperfil do usuárioe tarefasrelacionadas.Ênfase em

aspectoscognitivos.Constrói aestruturanavegacional daaplicação;

Projeto deInterfaceAbstrata

Objetos deinterface Abstrata,Respostas aeventos externos,Transformaçõesde interface

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

Mapeamentoentre objetosnavegacionais eobjetosperceptíveis

Modela objetosperceptíveis,implementandometáforasescolhidas.Descreveinterface de

objetosnavegacionais.Define o layoutdos objetos deinterface;

Implementação Aplicaçãoexecutável

Os suportados pelo ambiente de desenvolvimento

Os suportados pelo ambiente de desenvolvimento

Performance



19

2.3 Etapas do método OOHDM

2.3.1 Análise de requisitos

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

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

comportamentos do sistema a ser projetado.

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

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

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

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

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

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

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

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

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

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

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

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

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

(VILAIN, 2002).

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

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

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

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

por informações nesta rádio.



20

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

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

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

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

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

Caso de Uso Expandido: Pesquisar a radio

Ações do Ator Resposta do sistema1. O usuário opta por pesquisar a

radio2. O sistema exibe a lista de

programas organizada por data deexibição, são exibidos os atributosdata do programa, nome doprograma e nome do DJ.

3. O usuário escolhe um dosprogramas

4. O sistema exibe nome doprograma, o nome do DJ que crioueste programa, a data de exibiçãoe a lista das musicas que foram

exibidas neste programa.

5. O usuário pode navegar para opróximo programa ou programaanterior por data de exibição.O usuário pode selecionar o DJ oualguma das musicas para visualizaros dados específicos destesobjetos.

6. O usuário pode navegar entre osprogramas e tocar o escolhido.

7.

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

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

Caso de Uso: Pesquisar a radio

Atores: CompradorDescrição: O usuario tem a opção de selecionar o programa de rádio que deseja estarouvindo dentre todos os programas já realizados. Aqui, pode obter informações sobre oprograma atual (ao vivo) e os programas anteriores da radio, como playlist, informações

sobre o DJ, os artistas e as musicas.O usuário pode ver os programas de um determinado DJ, todos os programas por data,todos os programas por nome ou ver informações sobre um DJ.



21

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

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

outros dados ou de opções selecionadas são colocados em estados

distintos;

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

sistema.

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

dependência dos dados

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

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

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

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

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

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

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

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

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

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



22

<1>

<2>

<3>

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

UID ver DJ

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

1 (ver detalhes)

1(ver DJ)

1 (escutar programa)

(escutar programa)

Figura 2.1- UID Pesquisar Rádio

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

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

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

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

2.3.2 Modelagem conceitual

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

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

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

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

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

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

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

descritas de acordo com os modelos UML.



23

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

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

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

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

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

dos textos dos casos de uso

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

(Figura 2.2)

Programa de Rádio

nome: Stringdata: Stringtempo: Stringsom: Audio

Musica

nome: StringArtista: String

DJ

nome: Stringperfil: Textfoto: Imagem

playlist

ordem: Numero

cria

1..*1

Figura 2.2 – Diagrama de Classes Conceituais



24

2.3.3 Projeto de navegação

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

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

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

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

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

e suas tarefas.

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

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

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

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

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

sua incursão pelo sistema.

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

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

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

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

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

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

quadrado vazio no canto superior direito.



25

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

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

apenas ter acesso a determinados atributos nodos independente da modelagem conceitual

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

dos atributos dos programas de rádio.

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

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

informações dos objetos conceituais devem ser processadas e quais as possíveis

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

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

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

processado”.

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

navegacional devem ser definidos:

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

navegacionais);

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

Programa de Rádio

nome: Stringdata: Stringtempo: Stringsom: AudioNomeDJ: nomeDJ de DJ por Programa

idxMusicas: nome, artista de Musica por programa

DJ

nome: Stringperfil: Textfoto: Imagemprogramas: nome, data de Programas por DJ

Figura 2.3 – Diagrama de Classes Navegacionais



26

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

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

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

dependendo do contexto em que ele está navegando.

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

contextos navegacionais e as estruturas de acesso.

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

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

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

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

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

conjunto de fatores que determinam a navegação.

A

Figura 2.4 exibe uma parte do esquema de contextos navegacionais.

DJ

data

por nomenome

DJ

Radio

busca

Programa de Rádio

por nome

por data

por DJ

por busca

Figura 2.4 - Diagrama de Contextos Navegacionais

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

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

quadros internos os contextos navegacionais.



27

As classes “emContexto” são classes adicionadas ao modelo de classes

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

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

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

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

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

ordem alfabética. Cada um destes contextos inclui todos os atributos da classe

navegacional e adiciona mais alguns conforme o projeto.

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

“Programa de Rádio”:

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

De acordo com Vilain (2002)

As classes em contexto podem ser vistas como decoradores. Elas

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

podem apresentar quando forem acessados dentro de diferentes contextos

Programa de Rádio

nome: Stringdata: String

tempo: Stringsom: AudioNomeDJ: nomeDJ de DJ por Programa

idxMusicas: nome, artista de Musica por programa

Programa de Rádio por DJPrograma de Rádio por DATA Programa de Rádio por NOME

calendario:Calendario

proximo: anchor(programa por DATA)

anterior: anchor(programa por DATA)

idxProgramas: nome, data de

Programas por DJ

proximo: anchor(programa por DJ)anterior: anchor(programa por DJ)

proximo: anchor(programa por NOME)

anterior: anchor(programa por NOME)



28

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

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

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

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

distintas no contexto em questão.

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

projeto de interface abstrata.

2.3.4 Projeto da interface abstrata

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

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

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

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

utilizando outras classes de interface.

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

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

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

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

Diferentemente da modelagem conceitual e do modelo navegacional, que determinam

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

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

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

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

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



29

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

funcionalidades da aplicação.

Como as tarefas suportadas pela aplicação gerenciam essa troca de informação, é de

se esperar que a troca seja menos dependente do ambiente em que está se desenvolvendo

esta interface. Isso faz com que possam ser separados os processos da interface

(informações que devem ser trocadas) e implementação da mesma (layout , cores), estas

últimas dependentes das particulares configurações de hardware e software que estarão

rodando estas aplicações. Esta separação nos permite criar modelagens protegidas das

evoluções tecnológicas das diversas plataformas e também da necessidade de dar suporte

aos vários ambientes de hardware e software utilizados pelos usuários.

Para o desenvolvimento da interface de um sistema baseado em OOHDM, pode-se se fazer

o uso de técnicas que descrevem as interações entre o usuário e o sistema levando em

conta que tipo de elemento de interação será utilizado na implementação. Uma destas

técnicas, que será expandida no Capitulo 4 do presente trabalho, chamada de Ontologias

de Widgets de Interface2 (MOURA, 2004) descreve classes abstratas de interface que são

mapeadas para os elementos de interação usuário-sistema.

O nível mais baixo de abstração é chamado de Interface Abstrata, que foca no tipo de

funcionalidade interativa que cada elemento de interface proverá. Ela é descrita por um

conjunto de elementos que representam este tipo de interação, considerando as

necessidades de trocas de informação entre o usuário e os elementos de navegação.

Posteriormente, estes elementos abstratos, chamados de widgets e definidos pela

Ontologia de Widgets Abstratos, são mapeados para uma estrutura de elementos concretos

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

Semântica e à geração automática de interfaces, este trabalho utiliza apenas parte do conceito geral

da ontologia, no que diz respeito criação de uma interface formalizada, em um sistema web.



30

levando em conta os aspectos específicos do ambiente em que será implementada tal

interface, definidos pela Ontologia de Widgets Concretos.

2.3.4.1 Ontologia de Widgets Abstratos

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

fazendo uma leitura semântica dos primeiros.

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

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

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



31

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

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

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

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

As classes dessa ontologia representam um ou mais elementos abstratos das

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

AbstractInterfaceElement

SimpleActivator ElementExhibitor VariableCapturer

PredefinedVariable IndefiniteVariable

Cont inuousGroup DiscreetGroup Mult ipleChoices SingleChoice

CompositeInterfaceElement

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

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

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

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

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

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

mail, dentre outros

Figura 2.6 - Diagrama de Classes da Ontologia de Widgets Abstratos



32

2. ElementExhibitor: esta classe representa elementos que exibem algum tipo de

conteúdo, como, por exemplo, um texto ou uma imagem;

3. VariableCapturer: esta classe representa os elementos capazes de capturar

um valor, como, exemplo, as “Caixas de textos” e os elementos do tipo

selecionador como: Check Box, RadioButton, entre outros.

Esta classe generaliza duas classes distintas:

• IndefiniteVariable: permite que o usuário insira dados através do uso do

teclado. Pode representar um campo de formulário, ou seja, uma caixa de

texto. O valor a ser capturado por esse elemento é desconhecido a priori.

• PredefinedVariable: permite a seleção de um subconjunto a partir de um

conjunto de valores predefinidos; muitas vezes, esse subconjunto poderá ser

unitário. As especializações dessa classe são:

ContinousGroup: permite a seleção de um único valor de um

intervalo infinito de valores;

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

intervalo finito de valores

MultipleChoices: permite a escolha de um ou mais elementos de

um conjunto enumerável de valores;

SingleChoice: permite a escolha de um único elemento de um

conjunto enumerável de valores.

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

citados acima.



33

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

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

subclasses.

A ontologia também é definida através de propriedades que qualificam os widgets

abstratos, indicando atributos dos elementos de interface, como a qual estrutura de

navegação eles estão relacionados, a qual estrutura da Ontologia de Widgets Concretos

eles estarão sendo mapeados, entre outros. A lista completa de propriedades está

representada abaixo.

I. ObjectProperty :

• hasInterfaceElement : indica os elementos da classe “AbstractInterfaceElement”

que compõem os elementos do tipo “CompositeInterfaceElement” e

“AbstratctInterface”.

Domínio: AbstractInterface ou CompositeInterfaceElement.

• targetInterface : indica qual será a instância da classe “AbstractInterface” a ser

criada quando esse elemento for ativado. Essa instância representa uma interface

abstrata.

• mapsTo : indica o elemento, da Ontologia de Widgets Concretos, que será mapeado

no elemento da ontologia de widgets abstrato. Esta propriedade está presente em

todas as classes da ontologia de Widgets Abstratos.

II. DatatypeProperty

• blockElement : indica as tags HTML (no escopo do presente trabalho MXML) e

classes CSS que serão usadas para a tradução de um elemento específico. Esta



34

propriedade é opcional para todas as subclasses da classe

“AbstractInterfaceElement”.

• isRepeated : é uma propriedade apenas do conceito “CompositeInterfaceElement”,

que indica se os elementos que compõem esse conceito irão ou não se repetir um

número arbitrário de vezes.

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

Esta propriedade pertence à classe “CompositeInterfaceElement”. Ela é utilizada

somente quando a propriedade “isRepeated”, dessa classe, possui como valor true .

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

que se repetem.

• fromAnchor : indica qual é a âncora descrita na ontologia navegacional, a qual a

instância de um elemento abstrato corresponde.

• fromContext : indica qual é o contexto, descrita na ontologia navegacional, o qual a

instância de um elemento abstrato pertence;

• fromIndex : indica qual o índice, descrito na ontologia navegacional, ao qual a

instância de um elemento abstrato se refere;

• fromAttribute : indica qual é o atributo da ontologia navegacional correspondente à

instância de um elemento abstrato;

• fromElement : indica qual é o elemento da ontologia navegacional correspondente à

instância de um elemento abstrato;

• visualizationText : representa um valor que será apresentado pelo elemento

concreto. Esta propriedade é utilizada apenas nos conceitos “ElementExhibitor” e

“IndefiniteVariable”.



35

2.3.4.2 Ontologia de Widgets Concretos

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

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

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

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

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

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

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

desenvolvido o sistema. Para fazer esta descrição, Sabrina Moura (MOURA, 2004) sugere autilização de linguagens como XUL, LASZLO e outras. Estas linguagens estão bem mais

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

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

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

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

apenas um pequeno conjunto das possibilidades existentes. A seguir será exposto esteconjunto. O presente trabalho irá definir mais classes que encontramos em ambientes de

desenvolvimento MXML/ActionScript 3.0 no capítulo 4.

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

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

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

teclado;

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

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

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



36

desse elemento. Muitas vezes são utilizados grupos desse mesmo

elemento, representando uma lista de opções, onde podem ser

selecionados n elementos. Esse elemento é composto de um label e de um

botão (caixa de verificação).

• CheckBoxAction : representa um elemento do tipo form , composto

de dois elementos distintos: um CheckBox (descrito anteriormente) e um

Button (com a ação de submit);

• ComboBox : representa uma lista de itens. Consiste em uma caixa

de entrada de texto e de um menu, a partir do qual o usuário pode

selecionar uma dentre as diversas alternativas (uma lista);

• ComboBoxAction : representa um elemento do tipo form, composto

de dois elementos distintos: um ComboBox (descrito anteriormente) e um


• ComboBoxTarget : representa o elemento ComboBox (descrito

anteriormente), composto de uma lista de elementos, onde cada elemento

representa um link específico, ou seja, quando o usuário realizar a escolha

do elemento e selecioná-lo na lista, automaticamente será executada uma

ação, podendo ser esta a chamada de uma interface abstrata;

• Form : representa um conjunto de elementos de interface. Ele possui

dois atributos: method (get ou post - método http para a submissão do

formulário) e action (contém uma informação, indicando o que vai acontecer

quando o formulário for submetido). O atributo action pode conter um

endereço http, um nome de uma página, um endereço eletrônico, entre

outras informações. Quando o botão de um elemento form é selecionado,

todos os valores dos elementos concretos que o compõem, são submetidos



37

para a URL descrita no atributo action . O código HTML desse elemento é

composto da descrição de um botão com a função de submit ;

• Image : representa elementos concretos que exibem figuras;

• Label : conhecido como rótulo, representa um valor (texto/ string ) que

é exibido na interface;

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

parte:

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

de outro documento (página, arquivo de imagem) da mesma

aplicação hipermídia;

de outro documento, em qualquer computador da rede;

e, evidentemente, para se copiar todos esses arquivos

(download)

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

selecionado ou não selecionado. Seu estado pode ser alterado pelo clique

do mouse ou via teclado na caixa de verificação desse elemento. Na maioria

das vezes são utilizados grupos desse elemento para representar um

conjunto de opções, onde é permitida a seleção de apenas um elemento do

conjunto;

• RadioButtonAction : representa um elemento do tipo form composto

de dois elementos distintos: um RadioButton (descrito anteriormente) e um




38

• RadioButtonTarget : representa o elemento RadioButton (descrito

anteriormente) com um link embutido na definição de cada item da lista

desse elemento;

• TextBox : representa um campo de entrada de informação. Este

campo é composto de apenas uma linha e pode ter n colunas;

• TextArea : representa um campo de entrada de informação. Esse

campo é composto de n linha e n colunas e ele pode conter barras de

rolagem horizontal de vertical, se for o caso;

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

Uma interface é mapeada em um elemento concreto composite , pois ela

representa uma composição de vários elementos de interface. Podem-se

mapear outras composições mais simples de elementos para esse conceito.

O mapeamento se dá seguindo as regras de consistência, a qual define quais

classes abstratas podem ser mapeadas para quais classes concretas. Um exemplo de regra

de consistência, que expressa a quais elementos de interface concreta o elemento de

interface abstrata SimpleActivator pode ser mapeado, se apresenta a seguir (Figura 2.7):



39

Figura 2.7 - Regra de consistência de Mapeamento Concreto

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

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

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

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

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

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

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

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

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

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

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

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

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

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



40

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

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

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

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

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

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

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

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

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

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

interfaces Flex adequadas.

2.3.4.3 Abstract Data Views (ADVs)

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

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

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

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

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

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

1996)

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

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

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

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



41

(marcações), ou seja, transpor um sistema da modelagem de interface abstrata para a

implementação em linguagens de tags se dá de maneira natural.

Quando num determinado ADV existem estados ou outros ADVs que são habilitados

visualmente ou desabilitados, utilizamos a variável perceptionContext para fazer este

controle. Elementos que estão adicionados a esta variável são exibidos na interface, já

elementos retirados da variável deixam de ser percebidos pelo usuário.

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

ADV Programa de Rádio

nome: Stringdata: Stringtempo: String

ADV DJ

nome: String

ADV Musicas

nome: Stringartista: String

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

2.3.5 Implementação

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

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



42

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

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

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

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

STATES do Flex.



43

3 FLEX E FLASH

Neste capitulo serão apresentados dois frameworks de criação e publicação deaplicações Flash, o Flash e o Flex. Ambos são ambientes para desenvolvimento de

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

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

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

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

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

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

3.1 Flex

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

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

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

runtime Adobe AIR.“ (ADOBE, 2008a)

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

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

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

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

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

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



44

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

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

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

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

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

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

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

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

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

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

descreve a lógica da aplicação.

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

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

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

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

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

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

3.1.1 Versões lançadas e features associadas

A. Flex 1.0

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

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

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

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



45

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

linha de comando.

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

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

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

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

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

umas com as outras.

B. Flex 2.0

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

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

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

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

Flex podia ser publicada apenas usando o SDK Flex.

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

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

C. Flex 3.0

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

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

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

entre o sistema ActionScript 3.0, PDF, JavaScript e HTML, o sistema de arquivos ehardwares do usuário. Foi também reformulada e ampliada a integração entre Flex e

os outros softwares de criação da Adobe.



46

3.1.2 Linguagens de programação.

As linguagens Flex agregam dois importantes paradigmas de desenvolvimento de

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

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

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

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

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

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

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

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

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

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

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



47

3.1.2.1 ActionScript 3.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



48

3.1.2.2 MXML

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

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

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

interpretação.

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

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

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

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

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

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

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

PHP, ColdFusion ou JSP, entre outras.

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

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

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

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

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

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

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

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

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

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

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

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



49

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



50

utilizando PHP como arquitetura server-side.

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

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

botão “Copiar”.

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

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

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

3 4 5 <mx:TextInput id="fonte" />

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

7 <mx:TextInput id="destino" />

8 9 </mx:Application>

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

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

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

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

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

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

3 4 <mx:Script>

5 6 function copiar() {

7 destino.text = fonte.text;

8 }

9 10 </mx:Script>

11 12 <mx:TextInput id="fonte" />

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

14 <mx:TextInput id="destino" />

15 16 </mx:Application>

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

como pode ser visto na



51

Figura 3.3:

Figura 3.3 – Exemplo simples de aplicação Flex

3.1.3 Criação de interfaces no Flex

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

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

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

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

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

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

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

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

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

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

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

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

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

mínimo da tabela seja ultrapassado.

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

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

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



52

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

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

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

3.1.3.1 VIEW STATES Flex

States é uma nova classe agregada à linguagem ActionScript 3.0 e

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

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

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

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

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

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

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

•

Estilos visuais.

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

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

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

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

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

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

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

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

53

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

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

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

1 <?xml version="1.0" encoding="utf-8"?>2 <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"

3 verticalAlign="middle"

4 width="340" height="250"

5 >

6 <mx:Script>

7 <![CDATA[

8 import mx.controls.Alert;

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

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

13 }

14

15 private function registrar(u:String, s:String, c:String):void{16 if(s == c)

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

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

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

20 }

21 ]]>

22 </mx:Script>

23 24 <mx:states>

25 

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

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

33 34 <mx:AddChild

35 relativeTo="{loginForm}"

36 position="lastChild"

37 creationPolicy="all"

38 >

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

40 <mx:TextInput id="senha2"/>

41 </mx:FormItem>

42 </mx:AddChild>

43 44 <!—aplica propriedades no Painel e no botão --> 45 <mx:SetProperty target="{loginPanel}"

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

47 48 49 <mx:SetProperty target="{loginButton}"

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

51 52 <mx:SetEventHandler target="{loginButton}"

54

53 name="click"

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

55 56 57 <!—remove o LinkButton existente. -->

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

60 61 

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

66 <mx:LinkButton

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

68 </mx:AddChild>

69 70 </mx:State>

71 72 </mx:states>

73 74 <mx:Panel

75 title="Login" id="loginPanel"

76 horizontalScrollPolicy="off" verticalScrollPolicy="off"

77 verticalAlign="middle"

78 >

79 80 <mx:Form id="loginForm">

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

82 <mx:TextInput id="user"/>

83 84 </mx:FormItem>

85 <mx:FormItem label="Senha:">

86 <mx:TextInput id="senha"/>

87 </mx:FormItem>

88 </mx:Form>

89 90 91 <mx:ControlBar>

92 <mx:LinkButton

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

94 click="currentState='Registro'"

95 />

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

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

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

100 101 </mx:ControlBar>

102

103 </mx:Panel> 104 </mx:Application>



55

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

A linha 94 do código representa o evento “click ” do componente LinkButton. Esteevento altera a variável <mx:states> da aplicação (linha 24) e muda o view state atual para

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

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

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

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

<mx:Transitions>. O desenvolvedor pode definir seqüências e paralelismos em umatransição, definindo a ordem e concomitância em que acontecem animações, mudanças de

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

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

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

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

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

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

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



56

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

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

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

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

3.1.3.2 Componentes Flash e componentes Flex

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

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

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

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

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

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

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

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

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

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

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

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

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

dos mais promissores da internet hoje em dia.

3.1.3.3 Componentes MXML

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

encontra-se no anexo 8.5.



57

3.1.3.3.1 Containers (Agrupadores)

• Accordion

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

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

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

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

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

• ApplicationControlBar

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

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

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

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

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

qualquer outro componente de interface.

• Box

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

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

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

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

• Canvas

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

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

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



58

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

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

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

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

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

• ControlBar

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

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

elementos.

• DivideBox

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

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

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

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

• Form

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

enviados ao sistema para que o controle de dados seja efetuado. Neles,

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

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

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

internos a ele.

• FormHeading

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

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



59

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

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

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

folha de estilos distinta.

• FormItem

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

ou mais agrupadores ou controles arranjados verticalmente ou horizontalmente.

• Grid

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

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

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

marcações <mx:GridRow>, e, dentro de cada uma destas, marcações

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

quantos ‘filhos’ forem necessários.

• Panel

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

é o espaço destinado aos ‘filhos’ do painel.

• TabNavigator

TabNavigator é uma extensão do container ViewStack, adicionando uma barra de

aletas (controle TabBar ), que faz o controle de navegação entre as páginas do

viewstack . Quando se aciona uma destas aletas, a página correspondente do

viewstack associado é exibida, escondendo as demais.

• Tile



60

Exibição de elementos dispostos em mosaico

• ViewStack

Disposição de elementos em múltiplos canvas dos quais apenas um está visível por

vez. Enquanto os outros não são acessados, não são carregados na memória pelo

programa.

3.1.3.3.2 Controles

o Button

É um botão tradicional, com aspecto gráfico que indica que pode ser

acionado com o mouse ou teclado. Este componente é composto de um retângulo

externo, um label e/ou um ícone. Os botões são normalmente utilizados em conjunto

com event listeners , que fazem o controle do funcionamento do botão em função das

ações do usuário. Quando é acionado, o botão emite um evento do tipo click e um

mouseDown . Um botão pode ter o comportamento de uma chave liga/desliga, ou

seja, ele pode ter dois estados representados pela propriedade toggle , ou ser do tipomais simples (equivalente a um push-button).

o ButtonBar [navBar]

Os ButtonBars são conjuntos de botões logicamente relacionados, dispostos

de maneira vertical ou horizontal. Os botões são do tipo push-button, ou seja, não

memorizam o estado depois de receberem uma ação de ativação. A maneira de

adicionar ou remover botões da barra de botões é análoga à manipulação de dados

em uma lista, com os métodos addItem() e removeItem(), simplificando o

gerenciamento da display list ActionScript 3.

o CheckBox [button]



61

Checkbox é um componente composto de um label e uma caixa de seleção,

a qual pode ou não conter uma marca de ativação. Os elementos CheckBox não são

mutuamente exclusivos, ou seja, podemos marcar ou desmarcar as várias

CheckBox contidas em uma aplicação conforme desejado (em contrapartida, ver

RadioButton ).

o ColorPicker [combobase]

É um selecionador de cores, no qual o usuário pode rapidamente escolher

uma cor dentre uma gama de cores definidas.

o ComboBase

ComboBase é a classe mãe de componentes como ComboBox, ColorPicker

e DateField . É composta por um campo de texto, e um botão para o acionamento de

uma lista na qual pode se escolher a opção que será selecionada. Não é utilizada

diretamente como uma marcação MXML, mas serve de base para os componentes

ColorPicker e ComboBox.

o ComboBox [combobase]

O ComboBox é um componente composto de uma lista a qual o usuário

seleciona apenas uma opção, uma caixa de texto que contém a opção selecionada,

e um botão para exibir esta lista. É um componente análogo ao SELECT do HTML

mas com a diferença de que o usuário pode (quando permitido) inserir novas

entradas que não estão na lista, a partir da própria caixa de texto do componente.

o DataGrid

O DataGrid é como uma lista mas que pode mostrar mais de uma coluna de

dados, sendo útil para a exibição de elementos que tem varias propriedades. É um

componente que tem as seguintes características:



62

as colunas podem ser de tamanhos diferentes;

as colunas podem ser redimensionadas em tempo de execução pelo usuário;

as colunas podem ser reordenadas em tempo de execução pelo usuário;

possibilidade de usar um itemRenderer para exibição de dados que não

sejam textuais;

possibilidade de ordenação das linhas acionando uma das colunas.

DataGrid é um componente de interface construído para exibição de dados, e

não uma ferramenta de disposição de elementos como as TABLES HTML. Para tal,

existem os containers em MXML.

o DateChooser

Este componente é composto de uma barra de título, mostrando o nome do

mês e o ano, e um calendário mostrando os dias daquele mês específico. O usuário

pode selecionar uma data, um intervalo de datas ou então datas múltiplas. O

controle dispõe de acionadores para modificar o ano/mês e o desenvolvedor pode

restringir o intervalo de datas a serem exibidas.

o DateField [combobase]

O DateField é um controle composto por um campo de texto (TextField ) para

exibição de uma data, e um botão que aciona um DateChooser para seleção desta

data. Quando a data é selecionada, o DateChooser é fechado e a data selecionada

preenche o campo de texto. O usuário pode também digitar a data diretamente no

campo de texto.

o HorizontalList



63

Este componente exibe uma lista na qual os elementos são dispostos lado a

lado. Caso existam mais elementos do que o número que pode ser exibido ao

mesmo tempo dependendo do tamanho desta lista, o componente pode exibir uma

barra de rolagem para o acesso a estes itens.

o HScrollBar /VScrollBar [scrollBar]

É uma barra de rolagem horizontal/vertical para o controle de exibição dos

dados quando estes preenchem um espaço maior do que o container onde eles

estão inseridos. Apesar de ser um controle independente, podemos associar a barra

de rolagem a outros componentes para efetuar o controle de rolagem em seus

conteúdos.

As barras de rolagem são compostas por quatro elementos: dois botões com

setas, um botão de rolagem e um trilho no qual o botão de rolagem percorre. A

posição do botão de rolagem e a exibição das setas dependem do estado do

controle.

o HSlider /VSlider

Os controles HSlider e VSlider permitem ao usuário fazer seleção de um ou

mais valores dentre um intervalo. Composto de um trilho horizontal/vertical e um ou

mais botões de rolagem. A seleção de valores é feita de maneira visual, arrastando

os botões pelo trilho, e o valor é definido de acordo com valores máximo e mínimo

definidos no trilho. Este conjunto de valores pode ser contínuo, ou ter valores

específicos entre o máximo e o mínimo.

o Image

O controle de exibição de imagens permite importar arquivos JPG, PNG, GIF

e SWF. Além disso, provê funções para embarcar estes arquivos no executável final



64

em tempo de compilação. Este componente é normalmente utilizado para

importação de arquivos estáticos, que não farão parte da lógica do sistema e para

criação de ItemRenderers . Para importação de outras aplicações Flex/Flash, é

recomendado o uso de outro componente, o SWFLoader.

Imagens embarcadas são carregadas imediatamente, pois são parte do

código executável, mas em contrapartida fazem o tamanho da aplicação aumentar.

Imagens embarcadas também fazem a manutenção da aplicação ser mais

complexa, pois temos que recompilar a cada vez que a imagem for alterada. A

maneira de contornar este problema, é carregar as imagens em tempo de execução,

fazendo um HTTPRequest ou simplesmente carregando um arquivo no servidor

onde a aplicação está rodando. Estas imagens ficam independentes da aplicação,

então quando as alteramos, não precisamos recompilar todo o sistema.

Caso sejam utilizadas imagens no formato PNG ou GIF, podemos utilizar o

canal alpha destas para criar fundos ou imagens com transparências, aumentando o

grau de qualidade gráfica da aplicação.

o Label

Os Labels são linhas simples de texto, não são editáveis mas podem ser

selecionados caso o desenvolvedor permita. Representam informações textuais que

podem ser controladas por folhas de estilos CSS. Labels não possuem bordas ou

fundo e não podem receber o foco da aplicação.

o LinkButton [button]

É um controle Button sem bordas e seu label é aceso (um efeito visual

“acende” o botão) quando o usuário passa o foco da aplicação (com mouse ou

teclado) sobre o componente.



65

o LinkBar

O LinkBar é um conjunto de LinkButtons, dispostos horizontalmente ou

verticalmente. Sua aplicação típica é de controlar outros elementos de interface

como ViewStacks, ou para criar um conjunto independente de Links.

o List

É uma lista simples de elementos, na qual uma barra de rolagem pode ser

inserida caso o número de itens seja maior do que o número que pode ser exibido

neste componente dependendo de seu tamanho. O usuário pode fazer a seleção de

um ou mais itens da lista, dependendo do valor da propriedade

allowMultipleSelection .

o Menu [list]

O controle Menu cria uma lista pop-up de elementos que podem ser

selecionados um a cada vez, similarmente aos menus de aplicações em sistemas

operacionais. Estas listas podem ter vários níveis de submenus quanto desejado.

Depois de uma destas listas serem abertas, elas se mantém visíveis até que umadas seguintes ações ocorra:

Uma chamada à função Menu.hide();

O usuário seleciona um item de menu

O usuário “clica” fora do menu

O usuário seleciona outro componente da aplicação.

o MenuBar



66

A barra de menu é um conjunto de componentes Menu, disposta em uma

barra horizontal, geralmente no topo da aplicação, com um botão para cada

componente deste conjunto.

o NumericStepper

Este componente permite ao usuário fazer a seleção de um número dentre

um conjunto enumerável, ou um intervalo de números. É composto de uma caixa de

texto para informar o número selecionado, e botões para adicionar ou subtrair o

número selecionado.

o PopUpButton

Os PopUpButtons são botões nos quais a ação a ser feita pode ser

selecionada da mesma maneira como acontece em ComboBoxes . é composto de

dois elementos, o botão em si e outro botão que exibe uma lista de ações. Após a

seleção ser feita, a parte do componente que é o botão em si executa aquela

o ProgressBar

São barras de progresso que indicam o progresso de uma tarefa ao longo do

tempo. Estas tarefas incluem consultas a banco de dados, carregamento dinâmico

de imagens e arquivos em geral, etc. Elas podem ser classificadas em dois tipos:

determinada ou indeterminada. No caso de a tarefa a ser cumprida tenha um tempo

fixo para acontecer, usamos o tipo determinado, por exemplo em marcações

temporais de um determinado acontecimento. Caso o tempo seja indeterminado,

como por exemplo em carregamento de arquivos, onde o tempo depende davelocidade da transferência de dados, utilizamos a forma indeterminada.

o RadioButton



67

RadioButtons são botões que funcionam como botões comuns, mas o label

deste está fora do gráfico que o representa. Este componente é utilizado em

conjunto com componentes do mesmo tipo e são enclausurados em grupos,

utilizando o componente RadioButtonGroup , o qual faz com que apenas um de seus

filhos possam ser selecionados de cada vez. Quando o usuário seleciona um destes

botões de um mesmo grupo, os outros tem sua seleção automaticamente removida.

o RadioButtonGroup

Determina um conjunto de RadioButtons

o RichTextEditor

É um editor de textos no qual o usuário pode inserir conteúdo e mudar a

formatação do texto. É composto de duas partes principais: uma caixa de textos

(TextArea) onde o usuário pode digitar texto e um container contendo controles para

o usuário especificar as características de formatação do texto inserido.

o Spacer

Spacer são elementos de disposição de componentes em um container pai,

que auxiliam no layout do container. São elementos invisíveis, mas que fazem com

que, por exemplo, os elementos fiquem sempre nas laterais do container, mesmo

que o tamanho do mesmo seja alterado.

o SWFLoader

É um componente que permite o carregamento e exibição de animações ou

aplicativos Flash/Flex. É um componente poderoso, pois quando carregamos uma

aplicação dentro de outra, estamos utilizando conceitos de reusabilidade, já que

podemos fazer a comunicação da aplicação base com a carregada. Apesar de este



68

componente não receber o foco da aplicação, seus elementos internos o recebem e

a interação é completa.

o TabBar

É um conjunto de botões mutuamente exclusivos em sua seleção,

representados de maneira a se parecerem com abas de um arquivo. Geralmente

são utilizados em conjunto com ViewStacks, mas podemos utilizá-los como qualquer

conjunto de botões que são mutuamente exclusivos (quando um é ativado, todos os

outros são desativados).

o Text

O controle de texto é derivado do Label, mas pode conter mais de uma linha

de conteúdo não editável. Este controle não suporta barras de rolagem, podemos

utilizar tags HTML para a formatação do conteúdo e decidir se este será ou não

selecionável.

o TextArea

TextArea é um componente composto de uma área de texto, uma borda e

barras de rolagem opcionais. Também suporta tags HTML para a formatação do

conteúdo.

o TextInput

Este controle é uma caixa de texto de apenas uma linha, na qual o usuário

entra com dados arbitrários. Quando utilizado como filho de um componente Form,

podemos utilizar validadores de dados, e também indicar se o campo é de

preenchimento obrigatório ou opcional. Estes controles possuem 4 estados distintos:

preenchido, selecionado, desligado e erro. Eles despacham eventos quando da



69

inserção de conteúdo e quando perdem o foco da aplicação, para ser feita a

validação e controle de obrigatoriedade.

Este componente é utilizado como subcomponente em vários outros

componentes, como o RichTextEditor, NumericStepper, e Comboboxes. Quando

associamos uma folha de estilos CSS à classe do componente, deve-se tomar

precaução pois todos estes outros componentes pais serão afetados, a não ser que

seja explicitamente indicado outro estilo.

o TileList

Este componente exibe um número de itens dispostos em células. Ele exibe uma

barra de rolagens se isso se fizer necessário, vertical ou horizontal.

o ToogleButtonBar

Este componente é um conjunto de buttons no qual apenas um deles pode ser

ativado por vez, e quando isto é feito, ou outros botões são colocados no estado

normal.

o ToolTip

Tooltips são componentes de informação de auxílio ao usuário. Quando este move o

mouse sobre um determinado componente gráfico, o ToolTip é exibido com texto

informativo sobre aquele componente. Sua funcionalidade pode ser expandida de

acordo com o projeto, inserindo novas funcionalidades.

o Tree

Este elemento possibilita a visualização de dados arranjados em uma estrutura de

árvore, com galhos e folhas. Uma folha é um ponto final de uma árvore, que pode



70

conter inúmeras folhas. Um galho é um nodo intermediário que contém outros

galhos ou folhas, ou pode estar vazio.

o VideoDisplay

Este componente permite a exibição de vídeos no formato .FLV. Suporta download

progressivo através de requisições http, ou streaming a partir de servidores Flash

(Flash Media Server, da Adobe, ou o Red5, open-source). Aceita também streams

de vídeos de câmeras, em tempo real.

3.2 Flash

A palavra Flash pode ser usada tanto para nos referirmos ao hoje Adobe Flash

Professional multimedia authoring program bem como ao Adobe Flash Player. O Adobe

Flash Professional é um software utilizado para criação do conteúdo para o Adobe

Engagement Platform. O Adobe Flash Player é o cliente universal, que instalado no

navegador do usuário ou em versão stand-alone , proporciona, através de uma máquina

virtual chamada AVM (ActionScript Virtual Machine) a exibição de conteúdo Flash. Este

cliente suporta gráficos vetoriais, bitmaps (mapas de bits) e streaming de áudio e vídeo

entre outros formatos de mídia. Resumindo,o Adobe Flash Professional é um ambiente

integrado de desenvolvimento (IDE) e o Adobe Flash Player é uma máquina virtual utilizada

para executar os programas gerados pelo primeiro.

O Flash surgiu em 1996 a partir de aprimoramentos de softwares de CAD

(Computer-Aided Design) como o IntelliDraw. O grande diferencial do Intellidraw sobre os

softwares concorrentes na época, como o Adobe Illustrator e o Aldus Freehand, era que

este permitia, alem de desenhar usando métodos tradicionais de CAD, a construção lógica



71

de elementos de desenho, como por exemplo, uma linha que sempre conecta dois objetos,

mesmo que estes sejam modificados, ou um gráfico de barras que mudaria de tamanho de

acordo com um número digitado em uma caixa de texto pelo usuário.

"If you ever think Flash is difficult to use, you should try

drawing with a joystick on an Apple II before the concept of

undo was invented. That will test your patience." Jonathan

Gay, Creator of Flash (GAY, 2008)

“Em 1995 a FutureWave (empresa criadora da primeira versão do Flash) começou a

receber muitas sugestões de usuários para transformar o SmartSketch (sucessor do

Intellidraw ) em um software de animação gráfica. A idéia foi muito bem aceita, mas um

problema surgia nesta ação. A única maneira de se publicar animações na época era em

formatos de vídeo, como VHS ou Betamax , ou então em CD-ROMs com hipermídia e o

mercado de ferramentas de animação era muito pequeno. Nesta mesma época estava

surgindo a world wide web como a conhecemos hoje, e a possibilidade de publicar

animações na internet abriu as portas para a FutureWave software , que começou então a

projetar um web-player em Java que reproduziria as animações feitas no SmartSketch , mas

esta era lenta e instável.” (Flash Magazine > News, 2000). Logo depois, a Netscape lançou

seu pacote de API’s (Application Programming Interface) para a produção de plug-ins, o que

fez com que as animações do SmartSketch pudessem ser reproduzidas no próprio

navegador no computador do usuário, o que aumentou muito a performance do player .

Em dezembro de 1996, a Macromedia adquire a FutureWave Software e o

FutureSplash Animator se torna a versão 1.0 do Macromedia Flash. Durante o tempo em

que o Flash permaneceu sob a bandeira da Macromedia, muitas modificações e

aprimoramentos foram feitos. A seguir, a Figura 3.5 mostra uma tela da primeira versão do

FutureSplash Animator.



72

Figura 3.5 – Tela do Future Splash Animator

Em meados de 2005 a Macromedia é adquirida pela Adobe, e então é criada a

Adobe Engagement Platform, nome da suíte de aplicativos criada pela Adobe resultante da

junção com a Macromedia. Esta linha de produtos é organizada em uma arquitetura de

cinco partes: O cliente universal, ou runtime client (Reader, Flash Player), componentes

server-side (Flash Media Center), frameworks de desenvolvimento de aplicações

(Cairngorm), ferramentas de desenvolvimento (Dreamweaver, Flash, Flex), e o AdobeSolutions Network (treinamento e suporte).

Desde a sua introdução em 1996, a tecnologia Flash se tornou um padrão na adição

de animações e conteúdo interativo em páginas da internet em um tempo que as páginas

eram construídas basicamente com HTML e um uma parcela muito reduzida utilizava

métodos de criação dinâmica de páginas. A partir de então muitos outros softwares,

sistemas complexos e dispositivos de hardware são capazes de exibir conteúdo Flash e atémesmo criar conteúdo Flash. Geralmente Flash é utilizado para criar animações, pequenos

anúncios em websites , vários tipos de componentes de interface para web, para adicionar

vídeo em páginas da internet e mais recentemente para criar a aplicação web como um

todo.



73

As versões mais recentes do Flash são :

• Macromedia Flash Professional 8 (13 de Setembro de 2005) – Ultimo Flash

lançado sob bandeira da Macromedia, esta versão suporta ActionScript 2.0 (não

orientado a objetos). Seu maior feito foi ter incluído controles de vídeo avançados

que fizeram surgir uma verdadeira onda de vídeos na internet publicados na

plataforma Flash. Esta versão era focada em expressividade, qualidade, vídeo além

de autoração para dispositivos móveis. Novos recursos incluíam Filtros de bitmaps ,

blend modes , controle de suavidade para animações, estilos de pincel avançados,

desenho baseado em objetos, cache de bitmaps em tempo de execução, anti-

aliasing avançado para texto, um novo codec de vídeo mais eficiente (On2 VP6),

suporte para transparência (alpha channel ) em vídeo, um codificador de vídeo stand-

alone , outras funcionalidades relacionadas a vídeo, e um emulador interativo de

dispositivos móveis.

• Adobe Flash CS3 Professional (versão 9) (16 de Abril de 2007) – Esta versão é a

primeira lançada após a compra da Macromedia pela Adobe. Ela suporta o

ActionScript 3.0 (Orientado a objetos) , permite a conversão de animações feitas nas

timelines em código, aumenta a integração com outros produtos da Adobe como

Photoshop ou Illustrator, aumenta a capacidade de qualidade em desenhos

vetoriais, e se torna mais parecido em termos de interface e organização com os

softwares da Adobe.



74

4 A PROPOSTA

A fim de aperfeiçoar a tarefa de mapeamento de um modelo abstrato de interface

OOHDM para implementação da interface concreta em um sistema baseado em Flex, este

trabalho sugere adaptações, extensões e sugestões às etapas de Projeto de Interface

Abstrata e Implementação do OOHDM

A Figura 4.1 nos mostra as etapas do OOHDM e seus passos internos. Os artefatos

gerados que são trocados entre as etapas estão representados acompanhando as

transições entre as etapas. A Figura 4.2 mostra o método OOHDM com as extensões

propostas no presente trabalho.

1. Modelagemdas classes

conceituais

Implementação

1. Especificação dos widgetsabstratos

Especificação dos widgetsconcretos2.

3. Especificação de ADVs

UIDs

classesconceituais

classes e contextosnavegacionais.

UIDs

UIDs

ADVs


navegacionais

2. modelagemdos contextosnavegacionais


Projeto deInterface Abstrata

Projeto deNavegação

ModelagemConceitual


1. Criação doscasos de uso

2. Especificaçãodos UIDs

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



75


ModelagemConceitual




conceituais


navegacionais

2. modelagemdos contextosnavegacionais

Implementação

1. Criação doscasos de uso

2. Especificação

dos UIDs

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

1. Especificação dosabstratos

Especificação dosconcretos MXML

Flex

widgets

widgets 2.

3. Especificação deADVs para

UIDs

classesconceituais


UIDs

UIDs

ADVs Flex


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

São propostas quatro extensões ao processo OOHDM. A primeira extensão faz

parte do Projeto de interface Abstrata e sugere o mapeamento das primitivas de interação

usuário-sistema extraídas dos UIDs e atributos das classes navegacionais para elementos

da Ontologia de Widgets Abstratos. A segunda extensão consiste em um mapeamento das

classes da Ontologia de Widgets Abstratos para um novo conjunto de widgets concretos,

baseado em componentes de interface do Flex (componentes MXML), criando novos

elementos na Ontologia de Widgets Concretos. Na terceira extensão, os ADVs são

adaptados para acomodar a informação das Ontologias Abstrata e Concreta para prover

uma descrição detalhada e pronta para o mapeamento em MXML. A quarta extensão é feita

entre o Projeto de interface e a Implementação, mas principalmente na última e sugere a



76

definição dos estados de interface Flex (View States <mx:State>) de acordo com um

conjunto de ADVs pré-determinados para modelarem estes estados.

4.1 Extensão 1 - Especificação dos widgets abstratos

Esta extensão ao processo OOHDM utiliza uma proposta sugerida por Remáculo

(2005) para mapear os atributos das classes navegacionais e entidades dos UIDs para os

elementos da interface abstrata. Este mapeamento indica a qual classe da Ontologia de

Widgets Abstratos cada elemento do UID pode ser relacionado. Desta maneira, é utilizado

na construção da interface abstrata, na qual são identificados os atributos e métodos das

classes navegacionais, e segundo suas “origens” nos UIDs, são mapeados para

determinadas classes da Ontologia de Widgets Abstratos.

Um atributo de uma classe navegacional que representa um item de dado exibido

pelo sistema num determinado UID, por exemplo, pode ser mapeado para

“elementExhibitor ” ou “simpleActivator ” dependendo de sua função. Caso no UID este

elemento seja apenas uma exibição de conteúdo, o mapeamento deve ser feito para

“elementExhibitor ”, mas, se este elemento seja passível de ativação, como em um texto

com âncora, ele deve ser mapeado para a classe “simpleActivator ”.

Com este mapeamento, obtém-se o primeiro conjunto de informações para o projeto

da interface abstrata identificando que tipo de exibição terá cada atributo da classe

navegacional.

A Tabela 4.1 apresenta as regras de mapeamento, indicando a classe da Ontologia

de Widgets Abstratos que cada elemento do UID está associado.



77

Tabela 4.1 Mapeamento de elementos dos UIDs

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

UIDs Widgets Abstratos

Item de dado e Item de dadopersonalizado ElementExhibitor ou SimpleActivator

Estrutura A estrutura toda pode ser mapeada para umElementExhibitor ou SimpleActivator , assim comocada elemento da estrutura pode ser mapeadopara um ElementExhibitor ou SimpleActivator .Neste caso, 1º deve-se mapear a Estrutura paraum CompositeInterfaceElement , para que depoisos elementos que compõem a Estrutura sejammapeados para ElementExhibitor ouSimpleActivator .

Conjunto, Conjunto com conteúdopersonalizado

e Conjunto em disposição diferenciada

1º passo: mapear o conjunto para umCompositeInterfaceElement .

2º passo: mapear cada elemento do conjuntopara um ElementExhibitor ou SimpleActivator ,conforme o objetivo do item de dado ou estruturaque compõem o conjunto.

Dado opcional ElementExhibitor ou VariableCapturer. No casode VariableCapturer , o elemento pode sermapeado para: IndefiniteVariable ,ContinuousGroup , DiscreetGroup,MultipleChoices ou SingleChoices .

Entrada do Usuário IndefiniteVariable

Entrada do Usuário Enumerada SingleChoice, MultipleChoice

Saída do Sistema Recebe o mapeamento descrito para oselementos dos UIDs, conforme o tipo deelemento que representa a Saída do Sistema(Item de dado, Item de dado personalizado,Estrutura, Conjunto, Conjunto com conteúdopersonalizado, Conjunto em disposiçãodiferenciada, Dado Opcional, Entrada do Usuárioe Entrada do Usuário Enumerada).

Texto ElementExhibitor Estado de Interação, Estado Inicial daInteração e Estados Alternativos daInteração.

CompositeInterfaceElement . Caso o Estado deInteração seja um conjunto deCompositeInterfaceElement , o estado deinteração será a associação dosCompositeInterfaceElements .



78

Sub-estados de um Estado deInteração.


Transição com Seleção da Opção X eTransição

com Seleção da Opção Restrita X.:

SimpleActivator . No caso da opção precisar deoutro elemento para que o estado de interaçãodestino se torne o foco da interação, a mesmadeve ser mapeada para MulipleChoice ouSingleChoice e atrelada a um SimpleActivator para que a transição entre Estados de Interaçãoocorra.

Transição com Seleção de NElementos

Os conceitos que suportam a seleção de 1 oumais elementos especificados nos UIDs são:ContinuousGroup*,DiscreetGroup*,MultipleChoices ou SingleChoices .

Chamada de Outro UID, Chamada apartir de Outro UID, Transição comCondição Y, Pré-Condições, Pós-Condições e Notas Textuais.

Não há mapeamento para a ontologia de widgets abstratos.

Durante o processo de pesquisa, principalmente quando da análise dos

componentes MXML, detalhada na seção 4.2, foi identificada a necessidade de se

descrever elementos de interface que fizessem seleção de intervalos em vez de apenas um

único valor a partir de um intervalo de valores. Estendendo a classificação dos widgets

abstratos da metodologia OOHDM, as classes da Ontologia de Widgets Abstratos

ContinuousGroup e DiscreetGroup podem ter pares de seleção múltipla

ContinuousGroupMultiple e DiscreetGroupMultiple, como descrito na Figura 4.3. O

mapeamento para estes novos elementos se dá da mesma maneira que se realiza

mapeamentos para as classes ContinuousGroup e DiscreetGroup.

Recapitulando a descrição das classes da Ontologia de Widgets Abstratos que são

subclasses da classe “PredefinedVariable ” e descrevendo as duas novas classes:

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

• ContinousGroupMultiple: [nova]permite a seleção de um ou mais valores de um intervalo infinito de valores;



79

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

• DiscreetGroupMultiple: [nova]permite a seleção de um ou mais valores de um intervalo finito de valores;

•

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

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



PredefinedVariable IndefiniteVariable

ContinuousGroup Discree tGroup Mu lt ip leChoices SingleChoice


ContinuousGroupMultiple DiscreetGroupMultiple

Figura 4.3 - Classes da Ontologia de Widgets Abstratos extendida

Esta nova classificação permite ao usuário fazer a seleção de múltiplos valores a

partir de um intervalo infinito (ContinuousGroupMultiple ) ou finito (DiscreetGroupMultiple ) de

valores. Naturalmente, elementos concretos que serão mapeados a partir destas classes

devem prover mais de um elemento de seleção, como é mostrado na Figura 4.4 a seguir:



80

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

Considerando o UID da Figura 2.1 e o esquema de classes navegacionais da Figura

2.3, a Tabela 4.2 mostra um exemplo de definição de widgets abstratos.

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

Classe: Programa de Rádio

Atributos origem nos UIDs Widgets Abstratos

nome:String Item de dado ElementExhibitor

data:String Item de dado ElementExhibitor

tempo:String Item de dado ElementExhibitor

Som:Audio Item de dado

transição (escutar programa)

SimpleActivator

nomeDJ:String Item de dado

transição (ver DJ)

SimpleActivator

idxMusicas Estrutura CompositeInterfaceElement

Note que apesar de os atributos “som” e “nomeDJ” serem itens de dados assim

como “nome”, “data” e “tempo”, estes foram mapeados para SimpleActivator em vez de

ElementExhibitor, pois, a partir dos UIDs obtêm-se a informação de que estes elementos

ativam uma ação, no caso do “nomeDJ”, o usuário é direcionado para o “UID ver DJ” e no

caso do “som”, é executada a operação “escutar programa”. O elemento idxMusicas é um

elemento composto pois está exibindo mais de um atributo de outra classe conceitual,



81

‘nome’ e ‘artista’ de ‘Musica’, compondo uma estrutura no UID e sendo mapeado para

CompositeInterfaceElement .

4.2 Extensão 2 - Especificação dos widgets concretos MXML

Esta seção fará um estudo comparativo das premissas da Ontologia de Widgets

Abstratos com os componentes de interface MXML, sugerindo uma nova Ontologia de

Widgets Concretos específica. Os componentes MXML podem ser utilizados como

conteúdo dos atributos “mapsTo”, “blockElement”, ou “compositionTag” das classes

Ontologia de Widgets Abstratos. Os componentes MXML são classificados em duas

subclasses, os containers MXML e os controles MXML.

Os containers MXML são elementos que podem ser utilizados como invólucros de

componentes de interface, pois especificam o layout de uma interface gráfica com o

usuário. Podemos mapear os compositeInterfaceElements para este tipo de componente.

Por exemplo, uma interface pode conter 3 botões agrupados que estariam sendo

considerados como um compositeInterfaceElement por serem os únicos elementos de um

determinado estado do UID. Pode-se utilizar neste caso os containers para agrupar estes

botões na interface da maneira desejada pelo desenvolvedor / criador de interfaces. Os

containers Accordion , TabNavigator e ViewStack também podem ser aplicados como

compositeInterfaceElements que fazem o papel de exibidores de conteúdo por demanda.

Eles são compostos de outras composições e apenas uma dela é exibida por vez.

Os controls MXML são um conjunto de elementos de interface perceptíveis e

utilizáveis pelo usuário, como textos, imagens, botões, caixas de seleção de valores,

radiobuttons , e assim por diante. Serão mapeados diretamente das classes da Ontologia



82

de Widgets Abstratos, fazendo com que uma interface abstrata modelada com estas

classes possa ser traduzida em elementos MXML.

Para cada controle MXML, foi realizada uma análise comparando a descrição deste

componente com as classes da ontologia e identificado o mapeamento a ser feito. Os

componentes de análise mais complexa são os que devem ser mapeados para a classe

CompositeInterfaceElement, pois são componentes compostos de outros componentes (de

qualquer classe, ex.: DataGrid; ou serem restringidos a elementos de uma única classe, ex.:

ButtonBar).

Este mapeamento, feito de maneira comparativa entre o funcionamento do

componente e o comportamento que devem ter instâncias das classes da ontologia de

widgets abstratos , pode também ser realizado para componentes customizados, isto é,

componentes criados pelo desenvolvedor. Na grande maioria das vezes, estes novos

componentes serão mapeados da classe CompositeInterfaceElement , por conter mais de

um elemento em sua composição, mas, o desenvolvedor deve fazer esta análise para cada

componente criado, para poder utilizá-lo na descrição dos ADVs estendidos.

Suponha que o desenvolvedor crie um novo componente de seleção de valores, com

base em um conceito de usabilidade totalmente novo, mas que apenas uma das opções

será selecionada por vez pelo usuário. Este componente deve ser mapeado para a classe

“SingleChoice ”, fazendo com que possa ser utilizado na descrição de sistemas futuros que

utilizem este componente. Sendo assim, a Ontologia de Widgets Concretos proposta nesta

seção deve ser sempre atualizada pelo desenvolvedor que a utiliza com seus novos

componentes.

A seguir é demonstrada a análise, que foi feita relacionando cada componente do

Flex apresentado na seção 3.1.3.3.2, a uma determinada classe da Ontologia de Widgets

Abstratos e depois os organizando de acordo com estas classes. Todos os componentes

abaixo devem ser representados na nova ontologia de widgets concretos precedidos do



83

sufixo “mx:”, indicando que fazem parte do pacote do núcleo ActionScript 3.0 do Flex. No

caso de um componente customizado, deve-se incluí-lo na ontologia utilizando o sufixo

correspondente ao pacote do desenvolvedor (ex.: novosCompos:ItemListaMusicas).

A) AbstractInterfaceElement

observações: Os elementos devem ser mapeados para subclasses desta classe.

B) SimpleActivator:

observações: Eventos externos de mouse ou teclado.

componentes mapeados:

B1) mx:Button

Tipo de ativador mais comum. Deve ser mapeado para esta classe a não ser que

se queira utilizá-lo como seletor de opções similarmente aos Radiobuttons.

Neste caso a propriedade “toggle” deve ser alterada para “true”.

B2) mx:LinkButton

Tem as mesmas características do Button mas é um componente que se

assemelha com Links HTML. Dever ser mapeado para esta classe caso se

queira uma interface visual menos carregada que a do Button, pois não possui

bordas.

C) ElementExhibitor:

observações: Exibição de conteúdo visual

componentes:

C1) mx:Image



84

Mapeamos os ElementExhibitors para mx:Image quando queremos exibir

imagens JPG, GIF e PNG, que podem ser carregadas dinamicamente ou estar

embarcadas no executável. Todos os atributos das classes navegacionais que

tenham seu domínio em imagens ou figuras serão mapeados para esta classe.

C2) mx:Label

Dever ser mapeado para esta classe quando o conteúdo do ElementExhibitor é

um texto de uma linha conhecido de antemão, por exibir apenas uma linha de

texto não editável. Geralmente é utilizado como rótulo ou título de outro elemento

de interface, mas pode exibir também conteúdo dinâmico.

C3) mx:ProgressBar

Deve ser mapeado para esta classe elementos que façam o controle de

progresso de tarefas. Como sugestão, pode ser utilizado para fazer com que o

progresso de um determinado processo de interações entre o usuário e o

sistema seja “medido” em relação às etapas deste processo. A cada etapa

cumprida, a barra de progresso avança.

Apesar desta sugestão, o componente mx:ProgressBar normalmente é utilizado

para exibir o carregamento da aplicação ou de arquivos carregados

dinamicamente no decorrer da navegação, sendo que, desta maneira, não há

mapeamento a partir das classes abstratas.

C4) mx:Text

Exibe múltiplas linhas de texto não editável. Análise análoga ao mx:Label.

C5) mx:ToopTip

Este componente é utilizado associado com outro componente. Ele exibe um

texto “popUp ”quando o usuário “passa” o mouse sobre o componente pai.



85

Devem ser mapeados para esta classe elementos que sejam textos alternativos

exibidos sob demanda,

C6) mx:VideoDisplay

Devem ser mapeados para este componente os elementos da classe

ElementExhibitor são do domínio Video. Exibe vídeo no formato [.FLV]. Suporta

download progressivo via http e streaming, de arquivos e de câmeras de vídeo.

É um elemento que não tem controles de reprodução de vídeo, como “play” e

“pause”, que devem ser implementados separadamente, mapeados a partir de

SimpleActivators.

D) IndefiniteVariable:

observações: Captura de dados do teclado.


D1) mx:TextArea

Para elementos de entrada de dados do usuário no formato de texto sejam eles

opcionais ou não e que tenham múltiplas linhas, o mapeamento dever ser feito

para este componente

D2) mx:TextInput

Similar ao TextArea mas com apenas uma única linha de texto.



86

E) ContinuousGroupMultiple:

observações: seleção de um único valor de um conjunto infinito de valores. Para

componentes proverem valores infinitos, os valores das propriedades maximum e

minimum devem ser alterados conforme o usuário troca o valor escolhido, pois a maioria

dos componentes faz a escolha do valor visualmente.


E1) mx:HSlider / VSlider

Como é possível instanciar mais de um handle neste componente, podemos

determinar um intervalo continuo de valores se forem declarados uma dupla dehandles para representarem os valores inicial e final. Para o domínio se tornar

um conjunto infinito de valores, os valores de máximo e mínimo do componente

devem ser alterados quando o usuário usa os handles.

F) ContinuousGroup:

observações: seleção de um único valor de um conjunto infinito de valores. Para

componentes proverem valores infinitos, os valores das propriedades maximum e

minimum devem ser alterados conforme o usuário troca o valor escolhido, pois a maioria

dos componentes faz a escolha do valor visualmente.

F1) mx:HSlider / VSlider

Análogo à análise E1, mas com apenas um único handle de seleção.

F2) mx:NumericStepper

Seleção de valores numéricos.



87

G) DiscreetGroupMultiple:

observações: Seletor de discretos, valores enumeráveis.


G1) mx:HSlider / mx:VSlider

Se for provido ao usuário uma maneira de inserir duplas de handles à linha de

seleção, podemos extrair vários intervalos discretos deste componente.

H) DiscreetGroup:

observações: Seletor de discretos, valores enumeráveis.


H1) mx:HSlider / mx:VSlider

Se for provido ao usuário uma maneira de inserir duplas de handles à linha de

seleção, podemos extrair vários intervalos discretos deste componente.

H2) mx:NumericStepper

Seleção de valores numéricos.

I) MultipleChoices:

observações: Seletor de conjunto de valores, valores enumeráveis.


I1) mx:HSlider / VSlider



88

Se for provido ao usuário uma maneira de inserir handles à linha de seleção,

podemos extrair vários valores discretos deste componente.

I2) mx:DateChooser

Seletor de datas em formato de calendário, este componente permite a seleção

de múltiplos dias do mês não adjacentes.

I3) mx:CheckBox

Caixa de seleção “liga/desliga”.

J) SingleChoice:

observações: Seletor de um único valor, valores enumeráveis.


J1) mx:HSlider / VSlider

Caso seja utilizado apenas um handle neste componente.

J2) mx:DateChooser

Calendário com seleção de apenas uma data.

J3) mx:ComboBox

Lista “retrátil” com apenas uma seleção dentre um conjunto discreto de valores.

J4) mx:DateField

Campo de texto com um botão para exibição de um calendário para seleção de

uma única data.



89

J5) mx:RadioButton

Conjunto de botões “liga/desliga” no qual apenas um pode estar ligado por vez.

K) CompositeInterfaceElement:

observações: Elemento composto.


K1) mx:ButtonBar

Composição apenas de elementos da classe Button. Deve ser utilizado quando

existe um compositeInterfaceElement composto apenas de elementos da classe

abstrata SimpleActivator. (ver LinkBar )

K2) mx:DataGrid

Lista de Elementos organizados em linhas e colunas. Seus elementos internos

podem ser construídos a partir de qualquer outro componente, o que o torna

instância da classe compositeInterfaceElement.

K3) mx:HorizontalList

Lista de Elementos organizados em uma única linha. Seus elementos internos



K4) mx:LinkBar

Composição apenas de elementos da classe LinkButton. Deve ser utilizado

quando existe um compositeInterfaceElement composto apenas de elementos

da classe abstrata SimpleActivator. (ver ButtonBar )



90

K5) mx:List

Lista de Elementos organizados em uma única coluna. Seus elementos internos



K6) mx:Menu

Composição de SimpleActivators, MultipleChoices e SingleChoice, u m menu

pode conter elementos dos tipos “normal ”, “check” e “radio” organizados em

grupos em suas folhas internas.

K7) mx:MenuBar

Composição de elementos da classe Menu que e um elemento da classe

ButtonBar que faz o controle de exibição dos menus.

K8) mx:PopUpButton

Por ser um elemento de ativação simples, mas com escolha múltipla da sua

função, este componente pode ser considerado como um elemento composto de

vários SimpleActivators.

K9) mx:RadioButtonGroup

Composição de elementos da classe RadioButton. Deve ser utilizado quando

existe um compositeInterfaceElement composto apenas de elementos da classe

abstrata SingleChoices.

K10) mx:SWFLoader

Componente que carrega outras aplicações Flex.

K11) mx:TabBar



91

É um componente ButtonBar geralmente associado com elementos de

navegação como viewstacks. O componente TabNavigator é uma associação de

um TabBar com vários viewstacks, mas com esta classe podemos criar mais de

uma TabBar para um mesmo controle de navegação.

K12) mx:TileList

Lista de Elementos dispostos em mosaico. Seus elementos internos podem ser

construídos a partir de qualquer outro componente, o que o torna instância da

classe compositeInterfaceElement.

K13) mx:ToggleButtonBar

Composição apenas de elementos da classe Button com a propriedade

“toggle=true”. Deve ser utilizado quando existe um compositeInterfaceElement

composto apenas de elementos da classe abstrata SingleChoice.

K14) mx:Tree

Lista de Elementos dispostos em estrutura hierárquica em árvore, como em um

gerenciador de arquivos. É composto de composições ícone-texto, que podem

ser galhos ou folhas da árvore.

- ~ -

Com esta análise completa, podemos definir as regras consistência de mapeamento

das classes de widgets abstratos para os componentes MXML que comporão a nova

Ontologia de Widgets Concretos.

A listagem completa das regras de consistência se encontra nos anexos. A Figura

4.5 nos mostra as classes da ontologia de widgets abstratos com os componentes MXML

relacionados.



92

ContinuousGroup DiscreetGroup MultipleChoices SingleChoiceContinuo usG roupMu ltiple Discre etG roup Mu ltiple


DateChooser

ComboBox

ColorPicker

CheckBox DateField

RadioButton


AdvancedDataGrid

ButtonBar

DataGrid

HorizontalList

LinkBar

List

Menu

MenuBar

PopUpButton

PopUpMenuButton

RadioButtonGroup

SWFLoader

TabBar

TileList

ToggleButtonBar

PredefinedVariableIndefiniteVariable

TextArea

TextInput


Button

LinkButton

Image

Label

Text

VideoDisplay

NumericStepper

ToolTip

ProgressBar

HSlider/VSlider

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

Com esta análise realizada, temos condições de agora em um determinado projeto

estender a tabela de definição de widgets abstratos (conforme o exemplo da Tabela 4.2)

incluindo os widgets concretos MXML e provendo condições para a aplicação da Extensão

3 proposta neste trabalho.

A Tabela 4.3 de definição de widgets concretos MXML é determinada conforme

exemplo da Tabela 4.2.



93

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

Classe: Programa de Rádio

Atributos origem nos UIDs Widgets Abstratos Widgets Concretos

nome:String Item de dado ElementExhibitor mx:Label

data:String Item de dado ElementExhibitor mx:Label

tempo:String Item de dado ElementExhibitor mx:Label

Som:Audio Item de dado

transição(escutarprograma)

SimpleActivator mx:Button

nomeDJ:String Item de dado

transição (ver DJ)

SimpleActivator mx:LinkButton

idxMusicas Estrutura CompositeInterface

Element

mx:VBox

4.3 Extensão 3 - Especificação de ADVs para Flex

Para realizar a construção dos ADVs incluindo o resultado da aplicação dos

mapeamentos anteriores, este trabalho apresenta uma simbologia para a representação

dos widgets nos ADVs. Cada ADV, ADV aninhado ou atributo é acompanhado de um

símbolo que corresponde à classe da ontologia de widgets abstratos e do nome do widget

concreto ao qual foi mapeado. A Figura 4.6 nos mostra a legenda correspondente às

classes abstratas e a Figura 4.7 é um exemplo da notação estendida de um ADV, o “ADV

Flex”:



94

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

ADV Botão

mx:LinkButton@

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

Com a reunião das informações geradas a partir dos diagramas de classes e

contextos navegacionais e da aplicação das extensões 1 e 2 propostas neste trabalho,

ADVs são gerados para cada nodo e atributo do esquema de classes navegacionais e para

cada índice e contexto do diagrama de contextos navegacionais. Os ADVs que representam

os nodos (classes) navegacionais serão chamados de ‘ADVs Primários’, ou ‘ADVs Base’.

Os ADVs relacionados contextos das classes navegacionais serão chamados de ‘ADVs

Secundários’. Os ADVs relacionados a atributos serão considerados os ‘ADVs opcionais’.

Os Índices do diagrama de contextos navegacionais devem ser descritos por ADVs

Especiais, que farão parte do contexto da aplicação e permitirão a navegação para os

objetos navegacionais. Esta hierarquia foi criada para acomodar os ADVs em mx:State no

AbstractInteface

SimpleActivator

ElementExibitor

IndefiniteVariable

ContinuousGroup

DiscreetGroup

MultipleChoices

SingleChoice


Multiple

ContinuousGroup

Multiple

DiscreetGroup

A

C

?

N

{N}

1

@

[1]

[N]

{1}



95

momento da implementação do sistema, como explicado na seção 4.1.4. A Figura 4.8 exibe

um esquema de como devem ser mapeados as entidades do projeto navegacional.

esquema declasses navegacionais

ADVs Primários ADVs Secundários

ADVs Opcionais ADVs Opcionais

contexto

contexto

contexto

classe

esquema decontextos navegacionais

esquema declasses ‘emContexto’

ADVs Especiais

ADVs Opcionais

índice

índice

índice



Figura 4.8- Mapeamento de entidades navegacionais para ADVs

O ADVs Primários e Secundários são mapeados exclusivamente para a classe

CompositeInterfaceElement enquanto que seus ADVs internos são mapeados para

qualquer classe que pode ser instanciada da Ontologia de Widgets Abstratos.

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

conforme a



96

Figura 4.9.a. O mapeamento abstrato é representado pelo símbolo no campo abaixo

do nome do ADV e o mapeamento concreto pelo nome do componente MXML ao lado.

No caso, o “ADV Programa de Rádio” foi mapeado a partir da classe navegacional

“Programa de Rádio”, portanto deve ser do tipo “compositeinterfaceElement” e é

considerado um ADV Primário. Os atributos “nome, data e tempo” foram mapeados para a

classe abstrata “ElementExhibitor” e então para o componente mx:Label compondo ADVs

opcionais assim como o restante dos ADVs internos. A

Figura 4.9.b mostra o ADV secundário correspondente ao contexto Programa de

Rádio por Data, com um calendário para seleção de outro programa neste contexto e

botões de avanço e retrocesso dentro do contexto.

(a) (b)

ADV musicas

C mx:VBox


nome

mx:Label

C mx:Panel

data

mx:Label

tempo

mx:Label

nomeDJ

mx:LinkButton@

som

@ mx:Button

ADV musicas

C mx:VBox

isRepeated

nome

mx:Label

artista

mx:Label

ADV Programa de Rádio por Data

nome

mx:Label

C mx:Panel

data

mx:Label

tempo

mx:Label

nomeDJ

mx:LinkButton@

som

@ mx:Button

data

mx:DateChooser1

próximo

mx:LinkButton@

anterior

mx:LinkButton@

Figura 4.9 - ADV Programa de rádio



97

4.4 Extensão 4 - Especificação de view states do Flex

Como os view states são organizados de maneira hierárquica, a organização dos

ADVs em Primários, secundários e opcionais nos permite um mapeamento direto para os

view states do Flex.

A criação de uma interface em um ambiente de programação ActionScript é

realizada através de uma estrutura de dados que representa uma lista de

objetos perceptíveis, chamada de DisplayList. Se algum objeto está

presente na interface de exibição ao usuário, então ele está registrado

nesta lista, de forma que um objeto instanciado do sistema que não foi

adicionado à DisplayList, ou que foi retirado da mesma, é um objeto que

apenas não tem interface visual sendo exibida, mas continua ativo.

(MOOCK, 2007)

Fazendo um paralelo com o OOHDM, no método OOHDM existe a variável

“contextoPerceptivo”, uma variável de contexto que tem a mesma função da DisplayList:

“Uma variável reservada, “contextoPerceptivo”, é usada para indicar

modificações no espaço perceptivo (o conjunto de objetos perceptíveis em

dado momento). Quando se deseja tornar um objeto perceptível, ele é

acrescentado ao “contextoPerceptivo”. Os elementos retirados deste

contexto deixam de ser percebidos.” (SCHWABE ROSSI, 1996).

Uma aplicação Flex pode utilizar destes conceitos fazendo inserções e retiradas de

objetos da DisplayList e também alterações nas propriedades e estilos destes objetos de

acordo com alterações de estados de interface. Podemos implementar os mx:Statede

acordo com os ADVs. A partir de um ADV primário, é implementado o ‘base state ’ do

componente que representa esta classe. Os ADVs secundários, são implementados como



98

estados ‘filhos’ do ‘base state’ . Os estados secundários podem também ter mais de um

estado de interface, que continuam sendo considerados “secundários”.

Os mx:State compreendem não só estados de interface relativos a uma aplicação ou

ADV, mas também a de um simples componente ou estado de um ADV, extraídos dos

ADVs opcionais. No exemplo de modelagem, o atributo “som” foi mapeado para um

elemento mx:Button , pois será um botão que aciona a exibição do programa de rádio

determinado. Suponha que o botão possa estar desabilitado quando é exatamente o

progrma de rádio que está sendo pesquisado o que está sendo exibido, então, este botão

será um componente com dois estados, um ‘ativo’ e um ‘inativo’. No estado ‘ativo’, o botão

seria da cor verde com o texto “OUVIR”, e no inativo da cor vermelha com o texto “NO AR”.

Este componente poderia ser implementado utilizando mx:State para definir os diferentes

estados da interface. Seu view state poderia ser definido pela aplicação, assim, se este

botão estiver presente em mais de um view state da aplicação, seu estado será mantido

quando da troca de view state ocorrer.

Este modelo de implementação permite a descrição de elementos da interface, desde

os mais primitivos aos mais complexos, provendo recursos para especificação de cada um

dos elementos de maneira independente, relacionando os eventos que ocorrem entre um e

outro.

Os aspectos dinâmicos da interface lidam tanto com transformações de

interface dentro de um ADV como com transformações de interface

envolvendo navegação. Em ambos os casos, a natureza orientada a

eventos dos ADVs e o poder expressivo de seu modelo de transição de

estados permite a implementação destas transformações em um estilo

simples, de baixo para cima. Começando-se com ADVs de mais baixo

nível, definimos “scripts” para cada evento significativo com que o objeto

pode lidar. (ROSSI, 1996).



99

Esta afirmação é válida também para a implementação dos mx:States, que podem

ser realizados em vários níveis desde cada objeto até a aplicação como um todo.

Aprimorando a o exemplo de modelagem de aplicação, será apresentado agora parte

do diagrama de classes navegacionais, o diagrama de ADVs, e o código MXML

correspondente que fazem parte do exemplo de como realizar o mapeamento para os view

states.

C mx:Panel

data

1

anterior

mx:LinkButton@

mx:LinkButton

ADV Primário

ADVs Secundários


nome

mx:Label

C mx:Panel

data

mx:Label

tempo

mx:Label

nomeDJ

mx:LinkButton@

som

@ mx:Button

ADV musicas

C mx:TileList

isRepeated

nome

mx:Label

artista

mx:Label


mx:DateChooser

próximo

mx:LinkButton@

ADV Programa de Rádio por DJ

C mx:Panel

fotoDJ

mx:DateChooser

próximo

mx:LinkButton@

anterior

mx:LinkButton@

ADV Programa de Rádio por Nome

C mx:Panel

próximo

@

anterior

mx:LinkButton@

ADV idxProgramasDJ

mx:TileListC

Figura 4.10 - Diagrama de ADVs

A partir deste diagrama de ADVs, a interface pode começar a ser construída.

Implementa-se primeiro o ADV Primário correspondente ao nodo navegacional Programa de

100

Rádio, de maneira que ele seja o base state do componente MXML escolhido para

representa-lo. No exemplo foi escolhido o componente mx:Panel portanto a definição crua

deste componente em MXML que está declarado no arquivo UIProgramaRadio.mxml é :

1 <mx:Panel xmlns:mx="http://www.adobe.com/2006/mxml">2 </mx:Panel>

Cada elemento interno do ADV Programa de Rádio é implementado no base state

de acordo com o mapeamento, resultando em:

1 <mx:Panel xmlns:mx="http://www.adobe.com/2006/mxml">

2 3 <mx:Label id="nome_lbl" text="Nome" />

4 <mx:Label id="data_lbl" text="Data"/>

5 <mx:Label id="tempo_lbl" text="Tempo"/>

6 <mx:LinkButton id="dj_lbtn" label="DJ"/>

7 <mx:Button id="som_btn" label="Som"/>

8 <mx:TileList id="musicas_tl" itemRenderer="itemListaMusicas"/>

9 10 <mx:Panel>

Em seguida podemos definir os outros view states mapeando cada ADV Secundário

para um mx:State como no exemplo a seguir:

1 <mx:Panel xmlns:mx="http://www.adobe.com/2006/mxml">

2 3 

5 <mx:states>

6 7 

8 <mx:State name="porData">

9 <mx:AddChild position="lastChild">

10 <mx:DateChooser id="calendario"/>

11 </mx:AddChild>


13 <mx:LinkButton label="anterior"/>

14 </mx:AddChild>


16 <mx:LinkButton label="próximo"/> 17 </mx:AddChild>

18 </mx:State>

19 20 

21 <mx:State name="porNome">



24 </mx:AddChild>

101

26 <mx:LinkButton label="próximo"/>

27 </mx:AddChild>

28 29 

30 <mx:State name="porDJ">


32 <mx:Image/>

33 </mx:AddChild> 34 <mx:AddChild position="lastChild">


36 </mx:AddChild>


38 <mx:LinkButton label="próximo"/>

39 </mx:AddChild>

40 </mx:State>

41 </mx:states>

42 43 

44 45 <mx:Label id="nome_lbl" text="Nome" />

46 <mx:Label id="data_lbl" text="Data"/>

47 <mx:Label id="tempo_lbl" text="Tempo"/>

48 <mx:LinkButton id="dj_lbtn" label="DJ"/>

49 <mx:Button id="som_btn" label="Som"/>

50 51 <mx:TileList id="musicas_tl" itemRenderer="itemListaMusicas"/>

52 53 </mx:Panel>

Com a interface definida são determinados os valores dos atributos dos

componentes baseados nos atributos dos objetos navegacionais os quais devem ser

implementados naturalmente como classes ActionScript. São também atribuídos os eventos

aos componentes, por exemplo determinando o método a ser chamado caso o usuário

aperte o botão do mouse sobre o componente. A troca de estado é feita através da

mudança da variável pública currentState:String e deve ser realizada antes que se

referencie os objetos adicionados a displayList .

A seguir são sugeridas algumas dicas e de modelagem de ADVs e uso do MXML

1. Alguns dos componentes são classificados como “navegadores”, pois realizam atarefa de exibir conteúdo sob demanda como comentado ao final da seção 3.1.3. São

eles:

• Accordion

• TabNavigator



102

• ViewStacks

Em uma composição de ADVs agrupados em “XOR”, ou seja, que representam

estados exclusivos da interface e não são percebidos simultaneamente pelo usuário, o

ADV que representa a classe compositeInterfaceElement que é pai destes ADVs em

“XOR” pode ser mapeada para os componentes acima.

Como exemplo, O “ADV Programa de rádio” do contexto “Programa de Rádio por

DJ” pode conter além do “ADV Musicas” que é uma lista de músicas que fazem parte

daquele programa de rádio, uma lista de outros programas daquele determinado DJ que

criou o programa que está sendo exibido. Estes dois ADVs, o “ADV Musicas” e o “ADV

Programas do DJ” podem ser ADVs que compõe um ADV pai chamado de “ADV

Informações” que é mapeado para um dos componentes sugeridos, em vez de se criar

view states para cada situação (um mostrando as músicas e outro os programas do DJ).

2. A maioria dos componentes MXML (todos que sejam instâncias da classe

mx:UIComponent ) tem as propriedades visible e enabled , podendo ser estas

utilizadas em vez de se criar view states para o determinado componente. Desta

maneira, podemos fazer o controle de visibilidade do componente ou da capacidade

de ativação pelo usuário sem que haja a necessidade de trocar de view state , sendo

que sua criação deve se reavaliada dependendo da complexidade da alteração da

interface.

3. Elementos que são do tipo compositeInterfaceElement que tem a propriedade

“isRepeated = verdadeiro” são elementos que repetem um deteminado conjunto de

dados de acordo com uma regra de exibição de elementos. Eles podem ser

mapeados para os componentes que representam listas de itens. Estes controles

permitem ao usuário da aplicação “rolar” a lista de itens e selecionar um ou mais

itens desta lista. Todos os componentes de lista do Flex são especializaçõoes da



103

classe mx:ListBase , incluindo mx:DataGrid, mx:HorizontalList, mx:List, mx:Menu,

mx:TileList, e mx:Tree.

No exemplo do Programa de Rádio, a lista de músicas pode ser uma lista ordinária

com linhas e colunas, ou pode ter um layout totalmente diferente, de acordo com a

linguagem do site ou sistema que está sendo implementado. Os componentes do tipo

lista do Flex utilizam uma classe propriedade chamada itemRenderer que aponta

para o componente que fará a composição visual do elemento da lista. Este

componente será o valor da propriedade compositionTag da ontologia de widgets

abstratos

4. As classes mx:Alert e mx:PopupManager são classes que permitem a exibição de

janelas independentes. O primeiro é uma janela modal geralmente utilizada para

exibir mensagens ao usuário e obter confirmações do mesmo. O segundo pode

carregar em uma janela separada qualquer aplicação ou componente Flex. A

definição original dos ADVs considera a modelagem de interfaces do tipo pop-up,

então, quando forem descritas interfaces deste tipo, podemos mapear o ADV para

estas classes.

5. As transições MXML são eventos relacionados a efeitos de mudanças de

propriedades, como dimensões, canal alpha, efeitos visuais e visibilidade. As

trasições são indicadas para cada objeto e na mudança de um view state para outro

são consideradas, realizando os passos indicados em ordem. Por exemplo, podemos

fazer uma mudança de view state na qual um componente sai da tela com umaanimação para a esquerda, e outro aparece esmaecendo em seguida. As transições

podem ser indicadas nos diagramas de ADVs entre um estado e outro de um

determinado ADV, ou entre ADVs secundários, quando há troca de contexto

navegacional.



104

5 Modelagem de Aplicação OOHDM – Flex

A aplicação de exemplo utilizada neste trabalho é um conjunto de pequenas aplicações

desenvolvidas para um artista gráfico. Este artista é produtor de desenhos que são

estampados em camisetas, e o sistema é uma loja na qual o usuário pode montar sua

própria camiseta de acordo com modelos, estampas e cores diferentes. Juntamente com

esta loja de camisetas, existe uma loja de produtos comuns (tradicional), que não

necessitam de personalização com a camiseta. Também há uma rádio virtual, na qual

acontecem programas ao vivo semanalmente, que será automaticamente exibido quando o

usuário adentra no sistema. Além da rádio ao vivo, o usuário tem a opção de fazer uma

pesquisa nos programas de rádio que foram exibidos anteriormente, obtendo informações

sobre o programa de rádio e o DJ que criou este programa.

Na primeira iteração, foi extraído o conjunto geral de informações do domínio,

procurando atingir todos os pontos do sistema. Foram conceitualizados a maioria dos

requisitos, porém a partir da etapa de projeto navegacional, apenas os objetos relacionados

à Rádio on-line foram contempladas.

Na segunda iteração foi aprimorado o modelo relativo à Rádio on-line e modelada a loja

comum. Esta base da loja será utilizada no sistema de camisetas pela herança da classe

“camisetaPersonalizada” em relação a “produto”.

A terceira iteração é a sugestão de modelagem do sistema de montagem de camisetas.



105

ITERAÇÃO 1

ANALISE DE REQUISITOS

O conjunto completo de casos de uso gerados nesta fase está no Anexo 8.1.

Caso de Uso: Pesquisar a radioAtores: usuário, sistemaTipo: Descrição: O usuário escolhe pesquisar os programas de rádio da emissora. O sistemaexibe uma lista de programas de rádio, exibindo o nome a data e o nome do DJ. O usuáriopode escutar um dos programas, ou ver os detalhes de um dos programas. Se for escolhidover os detalhes, o sistema exibe o programa de rádio, mostrando o nome, a data deexibição, o tempo total do programa, o nome do DJ que criou este programa a lista demusicas que fazem parte deste programa, incluindo o nome da música e o nome dointérprete. O usuário pode escolher escutar o programa corrente ou ver os detalhes do DJ

em questão.

UID: Pesquisar a rádio

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

UID ver DJ

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

1 (ver detalhes)

1(ver DJ)

1 (escutar programa)

(escutar programa)

<1>

<2>

<3>



106

MODELAGEM CONCEITUAL

O diagrama de classes conceituais completo está no Anexo 8.2

DJ

Programa de Rádio

0..*1

criaperfilfoto

nomedatatemposom

PROJETO NAVEGACIONAL

Programa de Rádio


DJ

nome: Stringperfil: Textfoto: Imagemprogramas: nome, data de Programas por DJ

DJ

data

por nomenome

DJ

Radio

Programa de Rádio

por nome

por data

por DJ



107

proximo: anchor(programa por DATA)

anterior: anchor(programa por DATA)

fotoDJ: foto de DJ

idxProgramas: nome, data de

Programas por DJproximo: anchor(programa por DJ)anterior: anchor(programa por DJ)

proximo: anchor(programa por NOME)

anterior: anchor(programa por NOME)

Programa de Rádio


Programa de Rádio por DJPrograma de Rádio por DATA Programa de Rádio por NOME

PROJETO DE INTERFACE ABSTRATA


nome

mx:Label

C mx:Panel

data

mx:Label

tempo

mx:Label

nomeDJ

mx:LinkButton@

som

@ mx:Button


C mx:Panel

data

mx:DateChooser1

próximo

mx:LinkButton@

anterior

mx:LinkButton@

ADV Programa de Rádio por DJ

C mx:Panel

fotoDJ

mx:DateChooser

próximo

mx:LinkButton@

anterior

mx:LinkButton@

ADV Programa de Rádio por Nome

C mx:Panel

próximo

mx:LinkButton@

anterior

mx:LinkButton@

ADV idxProgramasDJ

mx:TileListC

ADV Primário

ADVs Secundários

ADV DJ

nome

mx:Label

C mx:Panel

perfil

mx:Label

foto

mx:Button

ADV idxProgramasDJ

C mx:TileList



108

ADVs Opcionais

ADV idxProgramasDJ

C mx:TileList

isRepeated

nome

mx:Label

Data

mx:Label

itemListaProgramasDJ

mx:canvasC

@

@

ADVs Especiais

ADV índiceProgramaData

C mx:TileList

isRepeated

nome

mx:Label

Data

mx:Label

itemListaProgramaData

mx:canvasC

@

ADV índiceProgramaNome

C mx:TileList

isRepeated

nome

mx:Label

Data

mx:Label

itemListaProgramaNome

mx:canvasC

@

ADV índiceProgramaDJ

C mx:TileList

isRepeated

nome

mx:Label

Datamx:Label

itemListaProgramaDJ

mx:canvasC

nomeDJ

mx:Label

nomeDJ

mx:Label

nomeDJ

mx:Label@

IMPLEMENTAÇÃO.

classes navegacionais

• ProgramaRadio.as• ProgramaRadioData.as• ProgramaRadioNome.as• ProgramaRadioDJ.as

interfaces

• UIProgramaRadio.mxml• UIIndicesRadio.mxml

componentes

• ListaProgramaPorDJ.mxml

controladores• CTRLProgramaRadio.as

banco de dados

• DBProgramaRadio.php



109

6 Considerações Finais

Neste trabalho o método OOHDM foi estendido para ser utilizado na publicação de

aplicações construídas no ambiente Flex. Quando da análise do método, a característica

em comum mais evidente na relação entre OOHDM e Flex foi a criação de interfaces com o

usuário, de maneira que se estabeleceu o paralelo entre o Projeto de Interfaces Abstratas

do OOHDM e os view states do Flex.

A utilização das extensões propostas neste trabalho faz com que o projeto da interface

com o usuário seja feito de acordo com as capacidades e características dos componentes

MXML. A partir das ontologias de widgets de interface foi possível criar elementos de

projeto que funcionam como estruturas para realizar o mapeamento direto do projeto de

interface abstrata para a implementação do sistema, extraindo dos ADVs estendidos para

Flex informações para a construção do código MXML que compõe parte da estrutura de

uma aplicação Flex.

Perante a enorme quantidade de sistemas sendo construídos na atualidade, a

utilização de um método para a construção de sistemas implementados para a internet se

faz cada vez mais importante e presente. O Projeto de Navegação, a reusabilidade de

componentes e objetos conceituais, a rastreabilidade entre os elementos abstratos de

projeto e os concretos de implementação e a capacidade de gerir grandes quantidades de

dados fazem do método OOHDM um expoente no campo dos estudos de sistemas

hipermídia.

Atualmente o Flex é considerado um dos ambientes mais completos para o

desenvolvimento de aplicações hipermídia. Isso se deve pela sua integração com o Flash

para publicação de conteúdo interativo com interfaces gráficas avançadas, por sua

integração com serviços web através de “server-side scripts” e por ser publicado em uma

máquina virtual (Flash Player ) multi-plataforma.



110

A integração destas duas esferas - OOHDM e Flex- provê recursos para a construção

de sistemas hipermídia os quais tem poderosos aliados para a exibição de conteúdo para o

usuário, o Flex e o Flash. O Flex implementa a interface com o usuário, o controle da lógica

do sistema, o acesso ao sistema de informações, as requisições HTTP; enquanto o Flash

gera gráficos e componentes de programação inovadores no que diz respeito a usabilidade

e apresentação visual. Com as descrições providas pelo método OOHDM, a construção de

sistemas hipermídia em Flex se torna organizada e claramente descrita.

Apesar deste trabalho ter seu enfoque em aplicações feitas em Flex, as extensões

sugeridas (principalmente as extensões 1, 2 e 3) podem ser aplicadas em outras linguagens

de programação. Neste caso, os elementos descritos nos ADVs podem se manter

expandidos, contendo a informação da classe de widget abstrata da qual ele foi mapeado,

como proposto neste trabalho, mas em vez de componentes MXML o campo de

mapeamento concreto deve conter os componentes ou objetos da nova linguagem utilizada.

Na construção do estudo de caso foram constatadas algumas deficiências em relação à

integração das etapas do OOHDM quando se buscava a modelagem do sistema para a

implementação em Flex, problemas os quais as extensões 1 e 3 propostas neste trabalho

tentam resolver. Também foram encontrados modelos de implementação em Flex (os view

states) que não tinham correspondência direta com alguma primitiva do OOHDM, sendo

necessária a construção de um modelo abstrato hierárquico dos ADVs para suportar este

modelo.

Devido ao fato de a aplicação modelada no estudo de caso ser de pequenas

proporções no que diz respeito ao número de classes navegacionais, não se fez necessária

a utilização dos cartões de navegação (OOHDM) e mesmo assim não se perdeu informação

para a construção do sistema. Apesar disso, as extensões propostas não excluem os

cartões de navegação e estes podem ser utilizados sempre que o volume de classes

navegacionais no sistema não for facilmente gerenciável.



111

Trabalhos Futuros

A seguir são enumerados alguns trabalhos futuros

• Implementação das classes OOHDM em ActionScript para construção de uma

ferramenta de geração automática de interfaces concretas similar à ferramenta

idealizada por Sabrina Moura (Moura 2004). Neste trabalho, a obtenção de

dados das classes navegacionais persistidas no banco de dados seria feita

através de comandos OOHDM quando da requisição HTTP da aplicação, o que

geraria uma compilação on-the-fly que construiria a interface de acordo comdados dinâmicos.

• Utilização das extensões propostas no desenvolvimento de outras aplicações,

para efeitos de validação. Estas aplicações deveriam incluir diversos tipos de

widgets de interface, a fim de experimentar ao máximo os recursos do método

OOHDM estendido.

• Continuação do desenvolvimento dos ADVs Flex para que contenham

informações de transições entre os view states (mx:Transitions), ativações de

UIs (e outras características relevantes à implementação em Flex.



112

7 Bibliografia

COENRAETS, C. An overview of MXML: The Flex markup language. Adobe - Developer

Center. 2003. disponível em <http://www.adobe.com/devnet/flex/articles/paradigm.html>Acesso em: 03 Abr. 2008.

GARZOTTO, F. ; SCHWABE, D. ; PAOLINI, P. . HDM - A Model Based Approach ToHypermedia Application Design. ACM Transactions on Information Systems, New York,EUA, v. 11, n. 1, p. 1-26, 1993.

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

KOCH, N. A Comparative Study of Methods for Hypermedia Development. UniversidadeLudwig-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 webSemântica. PUC-Rio, Brasil, 2004.

REMÁCULO, L. R. Personalização de Diagramas de Interação do Usuário eMapeamento para a Ontologia de Widgets Abstratos, Trabalho de conclusão de curso,UFSC, Brasil, 2005

ROSSI, G. Um método orientado a objetos para o projeto de aplicações hipermídia.Tese de Doutorado, Puc-Rio, Brasil, 1996

SCHWABE, D. OOHDM Wiki :: Summary of OOHDM. 2005 disponível em<http://www.tecweb.inf.puc-rio.br/oohdm/space/summary+of+OOHDM>. Acesso em: 25mar. 2008.

SCHWABE, D.; ROSSI, G. V. . An Object Oriented Approach To Web-Based ApplicationDesign. Theory and Practice of Object Systems, New York, v. 4, n. 4, p. 207-225, 1998.

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

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

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

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



113

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



114

8 Anexos

8.1 Casos de uso da aplicação de exemplo

Caso de Uso: Montar camisetaAtores: CompradorTipo:Descrição: Um comprador (usuário cadastrado) escolhe a opção de montar uma novacamiseta. Ele escolhe a cor, a estampa, dentre as que podem ser aplicadas nesta cor, e ascores que podem ser aplicadas nesta estampa nesta cor de camiseta. Com a camisetamontada ele tem a opção de armazenar esta camiseta montada, adicioná-la ao carrinho decompras, começar novamente a montagem de uma nova camiseta ou voltar à vitrine.

Caso de Uso: Escolher camiseta da vitrineAtores: CompradorTipo:Descrição: Um comprador (usuário) percorre por uma galeria de camisetas previamente

montadas pelo VIME (vitrine) e pode, selecionando uma delas, ou ser direcionado para osistema de montagens de camisetas com esta camiseta carregada para ser modificada ouenviá-la para o carrinho de compras.

Caso de Uso: Escolher produto da loja simplesAtores: CompradorTipo:Descrição: Um comprador percorre a lista da loja de produtos simples (que não requerempersonalização como DVDs e Carteiras) e pode escolher quais quer adicionar ao carrinhode compras. O comprador pode selecionar um dos produtos e ver seus detalhes. Quandovisualizando 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, VimeTipo: Descrição: Um comprador (usuário cadastrado) após ter montado uma ou mais camisetasdecide por comprá-las. Ele seleciona dentre as camisetas enviadas ao carrinho decompras as que quer comprar efetivamente, as quantidades de cada tamanho para cadacamiseta que deseja, a quantidade dos produtos comuns. O sistema atualiza asinformações de quantidade e preço ao passo que o usuário define novos e passa para opasso seguinte, a confirmação do pedido. Com o pedido e preço total revisado econfirmado, ele escolhe uma dentre as formas de pagamento e passa para o seguintepasso, a inserção de dados (endereço de entrega, numero do cartão) para ser gerado opedido. Com o pedido gerado o comprador passa então para o passo de recebimento de

um comprovante de pedido. A partir daqui o comprador pode escohler continuarnavegando no VIME ou comprar mais camisetas. O VIME recebe o pedido e dá entrada aoprocesso de confecção física das camisetas para o envio, e depois de confirmado com ofornecedor, envia um email de confirmação do prazo de entrega das camisetas.



115

Caso de Uso: Escutar rádio (é um use case?)Atores: CompradorTipo: Descrição: Enquanto usa o sistema, o comprador estará escutando musicas ao duranteduas horas a cada duas semanas em um programa ao vivo. Fora deste horário, oprograma a ser exibido será o último realizado.

Caso de Uso: Pesquisar a radioAtores: usuário, sistemaTipo: Descrição: O usuário escolhe pesquisar os programas de rádio da emissora. O sistemaexibe uma lista de programas de rádio, exibindo o nome a data e o nome do DJ. O usuáriopode escutar um dos programas, ou ver os detalhes de um dos programas. Se forescolhido ver os detalhes, o sistema exibe o programa de rádio, mostrando o nome, a datade exibição, o tempo total do programa, o nome do DJ que criou este programa a lista demusicas que fazem parte deste programa, incluindo o nome da música e o nome dointérprete. O usuário pode escolher escutar o programa corrente ou ver os detalhes do DJem questão.

Caso de Uso: Ver galeria de fotos/videoAtores: CompradorTipo: Descrição: O comprador pode ver fotos e videos procurando em uma galeria visualatravés de miniaturas dos mesmos e então obter mais informações selecionando um deles.Nestas informações estão incluidos o conteúdo original, e dados extras como autor,descição, data e links externos.

Caso de Uso: Fazer Cadastro de UsuarioAtores: Usuário comumTipo: Descrição: O usuário quer fazer seu registro no sistema e fornece dados cadastrais. apartir deste ponto, o usuário recebe status de comprador e pode fazer o checkout no

sistema de montagem de camisetas. (mail de confirmação?)

Caso de Uso: Fazer conexão (login)Atores: Usuário comumTipo: Descrição: O usuário entra com seu email e senha previamente cadastrados e habita anavegação do comprador (pode utilizar o carrinho de compras, etc).

Caso de Uso: inserir novas camisetasAtores: administradorTipo: Descrição: O administrador seleciona a camiseta a ser inserida no sistema e fornece ainformação da cor desta camiseta. A partir da cor da camiseta, será possível escolher um

determinado conjunto de cores para as estampas.



116

Caso de Uso: inserir novas estampasAtores: administradorTipo: Descrição: O administrador seleciona a estampa a ser inserida no sistema e fornece ainformação de quantas cores tem a estampa e as cores iniciais. O sistema então exibetodas as camisetas cadastradas no sistema e o administrador seleciona quais camisetaspoderão receber a estampa a ser inserida.

Caso de Uso: inserir novos produtos simplesAtores: administradorTipo: Descrição: O administrador seleciona a imagem do produto, e insere os dados edescrição, preço do produto.

Caso de Uso: administrar usuáriosAtores: administradorTipo: Descrição: O administrador pode inserir, editar dados cadastrais e apagar usuários dosistema. Os dados de cartão de crédito devem ser criptografados.

Caso de Uso: administrar rádioAtores: administradorTipo: Descrição: O administrador faz o upload do programa de radio (arquivo de som) epreenche informações das musicas e do dj em questão.



117

8.2 Diagrama de UIDs para a aplicação de exemplo

D i a g r a n a d e U I D s

U I D

F a z e r L o g i n

o p ç õ e s d o

s i s t e m a

P e s q u i s a r R á d i o

u s a r l o j a c o m u m

v e r

c a r r i n h o d e c o m p r a s

v e r

d e t a l h e s P r o g r a m a

d e R á d i o

m o n t a r c a m i s e t a s

v e r v i t r i n e

v e r

g a l e r i a m u l t i m í d i a

f a z e r

c a d a s t r o

v e r

d e t a l h e s c a m i s e t a

v e r

d e t a l h e s p r o d u t o

v e r

d e t a l h e s D J

o p ç õ e s

d e a d m i n i s t r a ç ã o

p e s q u i s a r c o m p r a s

a d m i n i s t r a r u s u á r i o s

a d m i n i s t r a r r á d i o

a d m i n i s t r a r c a m i s e t a s

a d m i n i s t r a r g a l e r i a

m u l t i m í d i a

i n s e r i r /

a p a g a r / e d i t a r p r o g r a m a

d e r á d i o

a d m i n i s t r a r l o j a

i n s e r i r /

a p a g

a r / e d i t a r m o d e l o

i n s e r i r /

a p a g a r / e d i t a r e s t a m p a

a d m

i n i s t r a r v i t r i n e

i n s e r i r /

a p a g

a r / e d i t a r u s u á r i o

i n s e r i r /

a p a g a r / e d i t a r p r o g r a m a

d e r á d i o

i n s e r i r /

a p a g

a r / e d i t a r u s u á r i o



118

8.3 Diagrama de Classes conceituais da aplicação de exemplo

P r o d u t o

P r o d u t o C o m u m

U s u á r i o

A d m i n i s t r a d o r

D

J

M ú s i c a

P r o g r a m a d e R á d i o

I n t é r p r e t e

A r t i s t a G r á f i c o

E s t a m p a

C o r T i n t a

C o r

C o r T e c i d o

M o d e l o

P l a y l i s t

0 . . *

0 . . *

0 . . *

0 . . *

0 . . *

0 . . *

0 . . *

0 . . *

1 . . *

1

. . *

1 1

1

1

1 . . 4

1

1

c r i a

e x e c u t a d a

p o r

c o n t é m

c r i a

é t i n g i d o

d e

r e l a c i o n a c o m

c o n t é m

c o n t é m

t i p o

i m a g e m

p r e ç o

n ú m e r o c o m e r c i a l

d e s e n h o

n ú m e r o d e c o r e s

c o r e s p a d r ã o

c a t e g o r i a d e p r e ç o

n ú m e r o C M Y K

n o m e

v a l o r R G B

d e s c r i ç ã o

h o m e p a g e

f o t o

n o m e

s o b r e n o m e

e m a i l

s e n h a

p e r f i l

f o t o

n o m e

d a t a

t e m p o

s o m

n o m e

o r d e m

n o m e

n o m e

p r e ç o

d e s c r i ç ã o

e s t o q u e

f o t o

D

i a g r a m a d e C l a s s e s C o n c e i t u a i s

C o m p r a d o r

C o m p r a

C a m i s e t a P e r s o n a l i z a d a

0 . . *

0 . . *

0 . . *

1 . . *

m o n t a

1 . . *

1

0 . . 1

c o n t é m

f a z

i n c l ú i

c ó d i g o

t i p o

c p f / c n p j

r g s e x o

d a t a n a s c i m e n t o

e n d e r e ç o

C E P

c i d a d e

e s t a d o

p a í s

t e l e f o n e

d a t a

v a l o r T o t a l



119

8.4 Regras de consistência Ontologia de Widgets Concretosestendida

: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


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

: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


cwo:Label


cwo:ProgressBar


cwo:Text


cwo:ToolTip


cwo:videoDisplay


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

:IndefiniteVariable



120

a owl:Class;

rdfs:subClassOf awo:VariableCapturer;

rdfs:subClassOf

[a owl restriction;

owl:allValuesFrom

[a owl:Class;

owl:oneOf (cwo:TextArea cwo:TextInput)

];


].

cwo:TextArea


cwo:TextInput


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

:ContinuousGroupMultiple

a owl:Class;

rdfs:subClassOf awo:Predefinedvariable;

rdfs:subClassOf

[a owl restriction;owl:allValuesFrom

[a owl:Class;

owl:oneOf (cwo:HSlider cwo:VSlider)

];


].

cwo:Hslider


cwo:VSlider


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

:ContinuousGroup

a owl:Class;


rdfs:subClassOf

[a owl restriction;

owl:allValuesFrom

[a owl:Class;

owl:oneOf (cwo:HSlider cwo:VSlider cwo:NumericStepper)

];


].

cwo:Hslider


cwo:VSlider


cwo:NumericStepper


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



121

:DiscreetGroupMultiple

a owl:Class;


rdfs:subClassOf

[a owl restriction;

owl:allValuesFrom

[a owl:Class;

owl:oneOf (cwo:HSlider cwo:VSlider)

];


].

cwo:Hslider


cwo:VSlider


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

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

];


].

cwo:Hslider


cwo:VSlider


cwo:NumericStepper


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

:MultipleChoices

a owl:Class;


rdfs:subClassOf

[a owl restriction;

owl:allValuesFrom

[a owl:Class;

owl:oneOf (cwo:HSlider cwo:VSlidercwo:DateChooser cwo:CheckBox)

];


].

cwo:Hslider


cwo:VSlider



122


cwo:Datechooser


cwo:CheckBox


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

:SingleChoice

a owl:Class;


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)

];


].

cwo:Hslider


cwo:VSlider


cwo:Datechooser


cwo:ComboBox


cwo:DateFielda cwo:ConcreteInterfaceElement.

cwo:NumericStepper


cwo:RadioButton


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

: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



123

cwo:TabBar cwo:TileList cwo:ToggleButtonBar

cwo:composite)

];


].

cwo:ButtonBar


cwo:DataGrid


cwo:HorizontalList


cwo:LinkBar


cwo:List


cwo:Menu


cwo:Tree


cwo:PopUpButton


cwo:RadioButtonGroup


cwo:SWFLoader


cwo:TabBara cwo:ConcreteInterfaceElement.

cwo:TileList


cwo:ToggleButtonBar


cwo:Composition


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

8.5 Interface Visual de Componentes MXML

Container MXML Apresentação Visual



124

Accordion

ApplicationControlBar

HBox

Canvas



125

ControlBar

Form

Grid

Panel



126

TabNavigator

ViewStack

Control MXML Apresentação visual

Button

ButtonBar

CheckBox

ColorPicker

ComboBox



127

DataGrid

DateChooser

DateField

HorizontalList

HSlider / VSlider

Image imagem (jpg, gif ou png)



128

Label Label

LinkBar

LinkButton

List

Menu

MenuBar



129

NumericStepper

PopUpButton

PopUpMenuButton

ProgressBar

RadioButton

RadioButtonGroup

TabBar

Text



130

TextArea

TextInput

TileList

ToggleButtonBar

ToolTip

Tree

TCC Pedro Germani Ghiorzi - Rascunho Relatrio Final

Documents

Transcript of TCC Pedro Germani Ghiorzi - Rascunho Relatrio Final