Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DE SANTA CATARINA – UFSC
CENTRO TECNOLÓGICO – CTC
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA – INE
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
Adaptação do método OOHDM para publicação de
aplicações hipermídia em Flex
Pedro Germani Ghiorzi
Profª. Orientadora: Patrícia Vilain
Trabalho de conclusão de curso apresentado
como parte dos requisitos para obtenção do
grau de Bacharel em Ciências da
Computação
FLORIANÓPOLIS, 2008/1
Pedro Germani Ghiorzi
Adaptação do método OOHDM para publicação de
aplicações hipermídia em Flex
Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de
Bacharel em Ciências da Computação
_________________________________ Orientadora: Patrícia Vilain
Banca examinadora
________________________________ Leandro José Komosinski
__________________________________ Ricardo Pereira e Silva
Florianópolis, Junho de 2008
Dedico este trabalho aos meus pais, que tiveram
tanta paciência nestes anos da minha graduação, e aos
amigos Guilherme Bertoni Machado e Thiago Ramos dos
Santos que me deram forças para permanecer como
computeiro.
Agradeço à Teresa Maria Siewerdt, minha
companheira querida, à professora Patricia Vilain pela
orientação e amizade, e especialmente agradeço ao
Leandro dal Bò, que me puxou de volta ao oficio da
programação de computadores.
SUMÁRIO
1 INTRODUÇÃO .................................................................................... 11
2 HIPERMÍDIA E OOHDM. ........................................................................ 15
2.1 HIPERMÍDIA ........................................................................................................... 15
2.2 OOHDM ............................................................................................................... 18
2.3 ETAPAS DO MÉTODO OOHDM ............................................................................... 20
2.3.1 Análise de requisitos ........................................................................................ 20
2.3.2 Modelagem conceitual ..................................................................................... 23
2.3.3 Projeto de navegação ...................................................................................... 25
2.3.4 Projeto da interface abstrata ............................................................................ 29
2.3.5 Implementação ................................................................................................ 42
3 FLEX E FLASH ................................................................................... 44
3.1 FLEX .................................................................................................................... 44
3.1.1 Versões lançadas e features associadas ......................................................... 45
3.1.2 Linguagens de programação. .......................................................................... 47
3.1.3 Criação de interfaces no Flex .......................................................................... 52
3.2 FLASH .................................................................................................................. 71
4 A PROPOSTA ..................................................................................... 75
4.1 EXTENSÃO 1 - ESPECIFICAÇÃO DOS WIDGETS ABSTRATOS ....................................... 77
4.2 EXTENSÃO 2 - ESPECIFICAÇÃO DOS WIDGETS CONCRETOS MXML .......................... 82
4.3 EXTENSÃO 3 - ESPECIFICAÇÃO DE ADVS PARA FLEX ............................................... 94
4.4 EXTENSÃO 4 - ESPECIFICAÇÃO DE VIEW STATES DO FLEX ........................................ 98
5 MODELAGEM DE APLICAÇÃO OOHDM – FLEX ....................................... 105
6 CONSIDERAÇÕES FINAIS ................................................................... 110
TRABALHOS FUTUROS ..................................................................................................... 112
7 BIBLIOGRAFIA ................................................................................. 113
8 ANEXOS ......................................................................................... 115
8.1 CASOS DE USO DA APLICAÇÃO DE EXEMPLO .......................................................... 115
8.2 DIAGRAMA DE UIDS PARA A APLICAÇÃO DE EXEMPLO ............................................ 118
8.3 DIAGRAMA DE CLASSES CONCEITUAIS DA APLICAÇÃO DE EXEMPLO ......................... 120
8.4 REGRAS DE CONSISTÊNCIA ONTOLOGIA DE WIDGETS CONCRETOS ESTENDIDA ....... 121
8.5 INTERFACE VISUAL DE COMPONENTES MXML ...................................................... 126
LISTA DE FIGURAS
Figura 2.1- UID Pesquisar Rádio .......................................................................................................... 23
Figura 2.2 – Diagrama de Classes Conceituais.................................................................................... 24
Figura 2.3 – Diagrama de Classes Navegacionais ............................................................................... 26
Figura 2.4 - Diagrama de Contextos Navegacionais ............................................................................ 27
Figura 2.5- Classes "emContexto" do nodo navegacional "Programa de Rádio" ................................ 28
Figura 2.6 - Diagrama de Classes da Ontologia de Widgets Abstratos ............................................... 32
Figura 2.7 - Regra de consistência de Mapeamento Concreto ............................................................ 40
Figura 2.8 – Abstract Data View para Programa de Rádio ................................................................... 42
Figura 3.1 - Esquema de publicação de aplicações Flex. ................................................................... 47
Figura 3.2 – Esquema de publicação de Aplicações Flex .................................................................... 50
Figura 3.3 – Exemplo simples de aplicação Flex ................................................................................. 52
Figura 3.4 - Dois estados de uma aplicação. À esquerda, o base state e à direta, o estado "Registro" .............................................................................................................................................................. 56
Figura 3.5 – Tela do Future Splash Animator ....................................................................................... 73
Figura 4.1 – Esquema simplificado do processo do método OOHDM ................................................. 75
Figura 4.2 – Esquema do processo OOHDM adaptado para criação de sistemas Flex. ..................... 76
Figura 4.3 - Classes da Ontologia de Widgets Abstratos extendida .................................................... 80
Figura 4.4 - Exemplo de interface para seleção múltipla em um intervalo finito .................................. 81
Figura 4.5 - Sobreposição das classes de widgets abstratos ............................................................... 93
Figura 4.6 – Legenda da representação da classe de widgets abstratos nos ADVs ........................... 95
Figura 4.7 - Exemplo Estrutura do cabeçalho dos ADV Flex ............................................................... 95
Figura 4.8- Mapeamento de entidades navegacionais para ADVs ...................................................... 96
Figura 4.9 - ADV Programa de rádio .................................................................................................... 97
Figura 4.10 - Diagrama de ADVs ........................................................................................................ 100
LISTA DE CÓDIGOS-FONTE
Código Fonte 3.1 - Exemplo de Aplicação MXML ............................................................... 51
Código Fonte 3.2 - Exemplo de aplicação MXML + ActionScript ......................................... 51
Código Fonte 3.3 - Exemplo de implementação de view states .......................................... 54
LISTA DE TABELAS
Tabela 2.1 - Etapas do Processo OOHDM .......................................................................... 19
Tabela 4.1 Mapeamento de elementos dos UIDs para a Ontologia de Widgets Abstratos . 78
Tabela 4.2- Exemplo de definição de widgets abstratos ...................................................... 81
Tabela 4.3 - Definição de widgets concretos MXML a partir dos widgets abstratos ............. 94
11
1 Introdução
As aplicações de internet se tornam a cada dia mais avançadas e complexas,
aumentando seu alcance na combinação de elementos multimídia e incorporando novas
tecnologias rapidamente.
O Adobe Flex é um ambiente de desenvolvimento de aplicações ricas de internet (rich
internet applications - RIAs) que publica aplicações que são executadas no Adobe Flash
Player, hoje em dia um dos softwares com maior penetração nos computadores ligados à
internet (ADOBE, 2008b). Com a criação da linguagem orientada a objetos ActionScript 3.0,
as “aplicações Flash”1 deixam de ser apenas elementos componentes de um sistema
HTML, por exemplo, e passam a ser poderosas soluções para a criação da aplicação como
um todo. Apesar de se tornarem mais completas e de serem largamente utilizadas o que se
vê é que atualmente a grande maioria das aplicações publicadas na plataforma Flash é feita
de maneira ad hoc e sem nenhum planejamento adequado para prover recursos como
reusabilidade e manutenção.
Com o intuito de melhorar o desenvolvimento em Flex de sistemas hipermídia, isto é,
sistemas que trabalham com informações que são coleções de nodos multimídia (textos,
vídeos, imagens, animações vetoriais e outras mídias) interligados através de uma estrutura
de navegação que permite ao usuário fazer uma incursão não-linear pelo sistema, há a
necessidade de um método de modelagem que incorpore, além dos aspectos normalmente
modelados pelos métodos tradicionais, questões relativas à navegação e também à criação
de interfaces complexas e personalizadas. Em estudo no qual faz comparações dos
métodos hipermídia, Koch, (1999, p. 2) comenta que normalmente os métodos tradicionais
de modelagem não consideram o projeto de navegação como um processo separado do
projeto de interfaces com o usuário.
1Como serão denominadas as aplicações que executam no Flash Player criadas no Flex ou no Flash IDE
12
Como método direcionado para o desenvolvimento de sistemas hipermídia, pode-se
citar o Object Oriented Hypermedia Design Method (OOHDM) (SCHWABE; ROSSI, 1998).
O OOHDM é um método que apresenta todas as etapas necessárias para o projeto de um
sistema hipermídia permitindo, inclusive, o projeto de interfaces com o usuário de maneira
abstrata. Ele é um método iterativo composto de 5 etapas principais (Análise de Requisitos,
Modelagem Conceitual, Projeto de Navegação, Projeto de Interface Abstrata e
Implementação), cada uma delas executada iterativamente, sempre refinando o resultado a
cada nova iteração.
OBJETIVO GERAL
Este trabalho tem como objetivo adaptar o método OOHDM para o desenvolvimento
de sistemas hipermídia em Flex, permitindo também uma flexibilidade na incorporação de
novos componentes de programação na medida em que o desenvolvedor utiliza o método.
OBJETIVOS ESPECÍFICOS
1. Estudo do método OOHDM, a fim de estabelecer uma compreensão
aprofundada sobre o método;
2. Estudo sobre o desenvolvimento de interfaces e aplicações orientadas a objeto
no Flex;
3. Proposta de adaptação do método OOHDM para que as etapas de Projeto de
Interface Abstrata, e de Implementação sejam direcionadas para o
desenvolvimento de aplicações hipermídia em Flex;
4. Utilização do método OOHDM e da adaptação proposta neste trabalho no
desenvolvimento de um protótipo implementado em Flex.
13
JUSTIFICATIVA
Durante o projeto de uma aplicação hipermídia em Flex é preciso descrever o
comportamento dos objetos navegacionais e de interface com o usuário de maneira facilitar
o mapeamento para o código MXML.Entretanto, é adequado que o projeto de navegação e
o projeto da interface sejam realizados separadamente, pois o primeiro é independente do
segundo.
Esta separação é propícia para diminuir a dificuldade de comunicação entre o
desenvolvedor e o desenhista gráfico da aplicação, podendo estes se relacionar de maneira
a evitar ambigüidades no processo de desenvolvimento devido às representações
esquemáticas geradas nas etapas do método OOHDM, portanto, existe a necessidade de
um método direcionado para o desenvolvimento de aplicações hipermídia em Flex para
tornar este desenvolvimento mais eficiente.
O trabalho está organizado como segue. O segundo capítulo do trabalho comenta de
maneira introdutória os conceitos de hipermídia, seguidos pela descrição detalhada sobre o
método OOHDM, suas etapas e processos envolvidos.
O terceiro capítulo apresenta o ambiente de desenvolvimento do Flex, suas linguagens
e faz uma análise do comportamento dos componentes de interface MXML encontrados na
especificação das classes da linguagem ActionScript 3.0.
O quarto capítulo apresenta propostas de extensões ao método OOHDM para facilitar a
construção de sistemas hipermídia utilizando o Flex como ambiente de programação.
Também são sugeridas algumas dicas de implementação utilizando algumas técnicas ou
componentes específicos do Flex.
O quinto capítulo mostra um exemplo de aplicação hipermídia desenvolvido em Flex
utilizando o método OOHDM e as extensões propostas neste trabalho.
14
O sexto capítulo apresenta as considerações finais sobre o processo de pesquisa deste
trabalho e sugere alguns trabalhos futuros.
15
2 Hipermídia e OOHDM.
2.1 Hipermídia
Hipermídia é um termo criado por Ted Nelson em um artigo chamado “Complex
information processing: a file structure for the complex, the changing and the indeterminate
(1965)”. Neste artigo, ele propõe uma estrutura de dados para especificação de sistemas de
gerenciamento de informações (Xanadu), em que todos os documentos gerados
mundialmente fossem concentrados em um sistema de informação, e faz uma análise das
implicações que sistemas como estes teriam na sociedade na época. Hoje em dia o termo é
utilizado como uma extensão do termo “hipertexto”, significando o tipo de sistema de
informação que agrega diferentes tipos de mídia. Neles encontramos textos, imagens,
vídeos, sons, âncoras provenientes do hipertexto e outros elementos de navegação e
acesso a itens de dados que proporcionam uma interação não-linear do usuário com o
sistema.
Analisando este contexto, Vilain (2002) constata que:
Atualmente, as aplicações tradicionais baseadas em sistema de
informação, quando implementadas na WWW, também incorporam o
conceito de navegação entre suas informações (nodos navegacionais).
Entretanto, os métodos usados durante o desenvolvimento de aplicações
tradicionais não são suficientes para modelar a navegação, principalmente
quando a quantidade de nodos nos quais o usuário navega é grande.
Esses métodos não abordam todos os aspectos relacionados com a
navegação e geralmente não dissociam a navegação da interface com o
usuário.
16
Para Zhang (2004, p. 2)
[...] existem 4 regras principais para determinar se um sistema pode ser
considerado de hipermídia:
1. Uma grande quantidade de informação é organizada em fragmentos
igualmente numerosos;
2. Os fragmentos se inter-relacionam;
3. O usuário precisa de apenas uma pequena parte da informação num
dado momento;
4. A aplicação é ‘computer-based’.
Segundo Koch (1999) ainda estamos no começo do aprendizado de como
desenvolver grandes sistemas de hipermídia. Ela nos coloca que os sistemas de CD-ROMs
ou sistemas WEB estão sendo construídos de maneira ad hoc e, portanto, sem um
planejamento adequado, o que faz com que logo se tornem insustentáveis no que diz
respeito à manutenção dos recursos e atualização de funcionalidades.
O desenvolvimento de sistemas de grande porte requer um controle maior por parte
dos desenvolvedores, pois são originados em ambientes que envolvem um grande número
de recursos e pessoas, como: programadores, desenhistas, publicitários, autores de
conteúdo e assim por diante. Assim como no desenvolvimento de outros tipos de software,
existem alguns métodos propostos especificamente para o projeto de sistemas hipermídia,
que se focalizam em questões habituais de um projeto computacional e também em como
fazer a análise da navegação do usuário em sua incursão pelo sistema.
Entre estes métodos existe o chamado Hypermedia Design Method (HDM), criado
por Schwabe, Garzotto e Paolini. O HDM (Hypermedia Design Method) foi um dos primeiros
17
métodos que definiu a estrutura e interação nas aplicações hipermídia. Segundo Garzotto
et al. (1993):
Para controlar a potencial explosão no número de links, uma aplicação
hipermídia na verdade não interconecta tudo, mas sim tenta diretamente
interconectar apenas as partes mais importantes e significativas da
informação para transmitir o significado global de maneira mais natural.
A partir desta afirmação é possível perceber que a preocupação de projetar sistemas
mais complexos estava em como organizar os dados de maneira que a experiência do
usuário e o funcionamento do sistema fossem melhores. Por uma melhor experiência do
usuário entende-se a capacidade de este se familiarizar com a interação com o sistema a
fim de permitir o rápido e preciso acesso às informações providas e na capacidade do
sistema de prover diferentes tipos de informações, ricas para o usuário. Já por um melhor
funcionamento do sistema entende-se a possibilidade de este sistema ser de manutenção
fácil, e por suportar um volume maior de tráfego de informações dos mais variados tipos
sem perder a propriedade de ser altamente confiável.
Nos sistemas tradicionais, a navegação não era considerada uma parte integrante da
abstração feita para a construção dos modelos e projeto do sistema, mas sim parte das
operações de interface entre usuário e o sistema. O reconhecimento desta necessidade de
se separar a elaboração da navegação da interface surge no início da década de 1990 com
os primeiros estudos de modelagem para sistemas Hipermídia. Desde então, o conceito de
navegação em hipermídia está diretamente relacionado com visões do modelo conceitual,
especificando de maneira relacional quais elementos de navegação serão percebidos pelo
usuário a cada estado do sistema.
18
2.2 OOHDM
O método Object-Oriented Hypermedia Design Method (OOHDM) é um método de
desenvolvimento de sistemas hipermídia criado por Schwabe e Rossi (1996). Este método
utiliza de conceitos da modelagem orientada a objetos como abstração e composição para
prover uma descrição completa, complexa e concisa dos itens de dados ou informações e a
separação entre a modelagem conceitual do sistema da modelagem navegacional,
especificando padrões de navegação e transformações da interface.
OOHDM considera o processo de desenvolvimento da aplicação
hipermídia como um processo de quatro atividades, – Análise do domínio
(Análise de requisitos e Modelagem Conceitual), Projeto navegacional,
Projeto de interface abstrata e Implementação – desempenhadas em uma
mistura de estilos iterativos e incrementais de desenvolvimento; em cada
etapa um modelo é construído ou enriquecido. (Rossi, 1996, p. 13).
Cada etapa está relacionada com uma determinada questão de projeto, e assim um
modelo orientado a objetos é construído contemplando questões como reutilização e poder
de abstração. De acordo com (LIMA; SCHWABE, 2003, p. 4), “enquanto a modelagem
conceitual reflete os comportamentos e objetos do domínio da aplicação, o projeto
navegacional foca em questões relativas à organização do espaço navegacional, e às
tarefas e recursos do usuário.” Os fundamentos da abordagem OOHDM segundo Schwabe
e Rossi (1998, p.3) são:
• A noção de que os objetos de navegação são visões, analogamente às visões
da base de dados, dos objetos conceituais;
• O uso de abstrações apropriadas para organizar o espaço navegacional, com a
introdução do conceito de contexto navegacional;
• A separação de questões de interface e questões de navegação;
19
• A identificação explícita de que existem decisões de projeto (design) que
precisam ser feitas apenas quando da implementação.
A Tabela 2.1 (SCHWABE, 2005) nos mostra as etapas e artefatos gerados no
processo de desenvolvimento OOHDM.
Tabela 2.1 - Etapas do Processo OOHDM
Etapa Artefatos Formalismos Mecanismos Considerações de Projeto
Análise de Requisitos
Casos de uso, Anotações
Cenários, UIDs, Padrões de Projeto.
Análise de cenários e casos de uso, Entrevistas, Mapeamento UID – modelo conceitual
Captura dos requisitos do domínio da aplicação
Modelagem Conceitual
Classes, Subsistemas, Relações, Atributos
Modelo Orientado a Objeto, Padrões de projeto.
Classificação, Agregação, Generalização e Especialização
Modela a semântica do domínio da aplicação
Projeto Navegacional
Nodos, Âncoras, Estruturas de acesso, Contextos navegacionais, Transformações navegacionais
Visões Orientadas a objeto, State charts Orientados a objeto, Classes de contexto, Padrões de Projeto, Cenários centralizados no usuário.
Classificação, Agregação, Generalização e Especialização
Leva em conta perfil do usuário e tarefas relacionadas. Ênfase em aspectos cognitivos. Constrói a estrutura navegacional da aplicação;
Projeto de Interface Abstrata
Objetos de interface Abstrata, Respostas a eventos externos, Transformações de interface
Abstract Data Views, Diagramas de configuração; ADV-Charts; Padrões de projeto
Mapeamento entre objetos navegacionais e objetos perceptíveis
Modela objetos perceptíveis, implementando metáforas escolhidas. Descreve interface de objetos navegacionais. Define o layout dos objetos de interface;
Implementação Aplicação executável
Os suportados pelo ambiente de desenvolvimento
Os suportados pelo ambiente de desenvolvimento
Performance
20
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.
21
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 sistema 1. O usuário opta por pesquisar a
radio 2. O sistema exibe a lista de
programas organizada por data de exibição, são exibidos os atributos data do programa, nome do programa e nome do DJ.
3. O usuário escolhe um dos programas
4. O sistema exibe nome do programa, o nome do DJ que criou este programa, a data de exibição e a lista das musicas que foram exibidas neste programa.
5. O usuário pode navegar para o
próximo programa ou programa anterior por data de exibição. O usuário pode selecionar o DJ ou alguma das musicas para visualizar os dados específicos destes objetos.
6. O usuário pode navegar entre os programas 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 seja executado.
Caso de Uso: Pesquisar a radio
Atores: Comprador Descrição: O usuario tem a opção de selecionar o programa de rádio que deseja estar ouvindo dentre todos os programas já realizados. Aqui, pode obter informações sobre o programa atual (ao vivo) e os programas anteriores da radio, como playlist, informações sobre o DJ, os artistas e as musicas. O usuário pode ver os programas de um determinado DJ, todos os programas por data, todos os programas por nome ou ver informações sobre um DJ.
22
1. Identificação dos itens de dados trocados entre usuário e sistema;
2. Separação dos dados em estados de interação. Dados que dependem de
outros dados ou de opções selecionadas são colocados em estados
distintos;
3. Os itens de dados são separados em entre entradas de usuário ou saídas do
sistema.
4. Os estados de interação são conectados por transições de acordo com a
dependência dos dados
5. As operações do usuário são identificadas como opções associadas às
transições;
6. São adicionadas notas textuais que especificam requisitos não funcionais.
Os UIDs estão baseados em diagramas gráficos que exibem claramente que tipo de
informação está sendo trocada entre o usuário e o sistema, como por exemplo, quais tipos
de entradas de dados do usuário são obrigatórias ou opcionais. Isso faz com que a
ambigüidade e erros de interpretação sejam diminuídos, tornando o emprego dos UIDs um
método eficaz no entendimento e tratamento da funcionalidade do sistema a partir do ponto
de vista da relação usuário-sistema. Eles validam as interações entre estas duas entidades
criando um ambiente de planejamento mais sólido e confiável.
O UID da Figura 2.1 representa as informações do caso de uso pesquisar a Rádio:
23
<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.
24
A partir dos UIDs é possível se extrair dados para a construção de um diagrama de
classes do desenvolvimento orientado a objetos, mapeando as estruturas de dados nas
classes e os itens de dados em atributos. As operações associadas a interações nos UIDs
podem ser mapeadas para operações nos métodos destas classes que estão diretamente
ligados ao domínio da aplicação a ser construída. Os dados também podem ser extraídos
dos textos dos casos de uso
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
25
2.3.3 Projeto de navegação
Nesta etapa do OOHDM é descrita a estrutura de navegação da aplicação
hipermídia o que representa as visões dos objetos conceituais que o usuário terá acesso e
as conexões entre os objetos. Esta estrutura é organizada em termos de contextos
navegacionais, os quais são obtidos a partir de classes de navegação, como nodos,
âncoras, índices e guias. Os contextos navegacionais levam em conta os tipos de usuários
e suas tarefas.
Os nodos representam visões (views) lógicas das classes conceituais definidas
durante a análise do domínio da aplicação, ou seja, diferentes modelos navegacionais
podem ser construídos para um mesmo esquema conceitual, expressando diferentes visões
sobre o mesmo domínio. Âncoras são derivadas das relações conceituais definidas no
processo de análise de requisitos e permitem ao usuário transitarem de um nó a outro, em
sua incursão pelo sistema.
A Figura 2.3 representa as classes (nodos) navegacionais “Programa de Rádio” e
“DJ”. A transição entre elas representa uma âncora entre os elementos (link). Note que em
contrapartida ao modelo conceitual, a classe musica se tornou agora um atributo da classe
Programa de Rádio, pois o nodo musica nunca será alcançado por usuários já que sempre
que este ver os dados sobre as musicas, estará vendo em um contexto maior o programa
de rádio que contém estas músicas. As classes navegacionais são representadas com um
quadrado vazio no canto superior direito.
26
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 ProgramaidxMusicas: nome, artista de Musica por programa
DJ
nome: Stringperfil: Textfoto: Imagemprogramas: nome, data de Programas por DJ
Figura 2.3 – Diagrama de Classes Navegacionais
27
• Em qual conjunto de objetos o usuário navegará (os contextos navegacionais);
• De que maneira estes dados serão acessados (as estruturas de acesso);
• Quais diferentes conteúdos devem ser apresentados para o usuário,
dependendo do contexto em que ele está navegando.
As principais primitivas navegacionais OOHDM então são os objetos navegacionais, os
contextos navegacionais e as estruturas de acesso.
A modelagem navegacional gera dois importantes artefatos: o esquema de classes
navegacionais, e o esquema de contextos navegacionais. O primeiro define todos os
objetos navegáveis do sistema de acordo com visões sobre os objetos conceituais, e o
segundo as possíveis navegações entre estes objetos navegáveis. O modelo navegacional
pode evoluir independentemente do modelo conceitual, simplificando a manutenção do
conjunto de fatores que determinam a navegação.
A
Figura 2.4 exibe uma parte do esquema de contextos navegacionais.
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.
28
As classes “emContexto” são classes adicionadas ao modelo de classes
navegacionais e que fazem o papel das diferentes visões que aquele determinado nodo terá
em relação aos seus contextos. Por exemplo, o nodo “Programa de Rádio” pode ser
navegado em 3 diferentes contextos, “por Data”, “por DJ” e “por Nome”. O primeiro é a
coleção dos Programas de rádio organizados em ordem de data de exibição, o segundo os
programas criados por um determinado DJ, e o terceiro todos os programas de rádio por
ordem alfabética. Cada um destes contextos inclui todos os atributos da classe
navegacional e adiciona mais alguns conforme o projeto.
A Figura 2.5 a seguir nos mostra as classes “emContexto” do nodo navegacional
“Programa de Rádio”:
Programa de Rádio
nome: Stringdata: Stringtempo: Stringsom: AudioNomeDJ: nomeDJ de DJ por ProgramaidxMusicas: nome, artista de Musica por programa
Programa de Rádio por DJPrograma de Rádio por DATA Programa de Rádio por NOME
calendario:Calendarioproximo: anchor(programa por DATA)anterior: anchor(programa por DATA)
idxProgramas: nome, data de Programas por DJ
proximo: anchor(programa por DJ)anterior: anchor(programa por DJ)
proximo: anchor(programa por NOME)anterior: anchor(programa por NOME)
Figura 2.5- Classes "emContexto" do nodo navegacional "Programa de Rádio"
De acordo com Vilain (2002)
As classes em contexto podem ser vistas como decoradores. Elas
são definidas para representar as diferentes informações que os objetos
podem apresentar quando forem acessados dentro de diferentes contextos
29
de navegação. As informações comuns a todos os objetos de uma classe
navegacional, independente dos contextos nos quais eles aparecem, são
definidas no esquema de classes navegacionais. Portanto, uma classe em
contexto só é necessária se o nó tem uma aparência diferente e/ou âncoras
distintas no contexto em questão.
Com os diagramas de contextos e classes navegacionais, pode-se dar início ao
projeto de interface abstrata.
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
30
o sistema, portanto a navegação entre os elementos interface se torna mais uma das
funcionalidades da aplicação.
Como as tarefas suportadas pela aplicação gerenciam essa troca de informação, é de
se esperar que a troca seja menos dependente do ambiente em que está se desenvolvendo
esta interface. Isso faz com que possam ser separados os processos da interface
(informações que devem ser trocadas) e implementação da mesma (layout, cores), estas
últimas dependentes das particulares configurações de hardware e software que estarão
rodando estas aplicações. Esta separação nos permite criar modelagens protegidas das
evoluções tecnológicas das diversas plataformas e também da necessidade de dar suporte
aos vários ambientes de hardware e software utilizados pelos usuários.
Para o desenvolvimento da interface de um sistema baseado em OOHDM, pode-se se fazer
o uso de técnicas que descrevem as interações entre o usuário e o sistema levando em
conta que tipo de elemento de interação será utilizado na implementação. Uma destas
técnicas, que será expandida no Capitulo 4 do presente trabalho, chamada de Ontologias
de Widgets de 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.
31
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
32
entradas de dados (itens de dado ou estruturas de itens de dados), saídas do sistema (itens
de dado ou estruturas de itens de dados), e operações realizadas pelo usuário. “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
ContinuousGroup DiscreetGroup MultipleChoices 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
33
2. ElementExhibitor: esta classe representa elementos que exibem algum tipo de
conteúdo, como, por exemplo, um texto ou uma imagem;
3. VariableCapturer: esta classe representa os elementos capazes de capturar
um valor, como, exemplo, as “Caixas de textos” e os elementos do tipo
selecionador como: Check Box, RadioButton, entre outros.
Esta classe generaliza duas classes distintas:
• IndefiniteVariable: permite que o usuário insira dados através do uso do
teclado. Pode representar um campo de formulário, ou seja, uma caixa de
texto. O valor a ser capturado por esse elemento é desconhecido a priori.
• PredefinedVariable: permite a seleção de um subconjunto a partir de um
conjunto de valores predefinidos; muitas vezes, esse subconjunto poderá ser
unitário. As especializações dessa classe são:
� ContinousGroup: permite a seleção de um único valor de um
intervalo infinito de valores;
� DiscreetGroup: permite a seleção de um único valor de um
intervalo finito de valores
� MultipleChoices: permite a escolha de um ou mais elementos de
um conjunto enumerável de valores;
� SingleChoice: permite a escolha de um único elemento de um
conjunto enumerável de valores.
4. CompositeInterfaceElement: representa uma composição dos elementos abstratos
citados acima.
34
Note que as classes “AbstractInterfaceElement”, “VariableCapturer” e
“PredefinedVariable” não são instanciadas diretamente, mas sim através de suas
subclasses.
A ontologia também é definida através de propriedades que qualificam os widgets
abstratos, indicando atributos dos elementos de interface, como a qual estrutura de
navegação eles estão relacionados, a qual estrutura da Ontologia de Widgets Concretos
eles estarão sendo mapeados, entre outros. A lista completa de propriedades está
representada abaixo.
I. ObjectProperty:
• hasInterfaceElement: indica os elementos da classe “AbstractInterfaceElement” que
compõem os elementos do tipo “CompositeInterfaceElement” e “AbstratctInterface”.
� Domínio: AbstractInterface ou CompositeInterfaceElement.
• targetInterface: indica qual será a instância da classe “AbstractInterface” a ser
criada quando esse elemento for ativado. Essa instância representa uma interface
abstrata.
• mapsTo: indica o elemento, da Ontologia de Widgets Concretos, que será mapeado
no elemento da ontologia de widgets abstrato. Esta propriedade está presente em
todas as classes da ontologia de Widgets Abstratos.
II. DatatypeProperty
• blockElement: indica as tags HTML (no escopo do presente trabalho MXML) e
classes CSS que serão usadas para a tradução de um elemento específico. Esta
35
propriedade é opcional para todas as subclasses da classe
“AbstractInterfaceElement”.
• isRepeated: é uma propriedade apenas do conceito “CompositeInterfaceElement”,
que indica se os elementos que compõem esse conceito irão ou não se repetir um
número arbitrário de vezes.
• compositionTag: indica uma tag HTML (no escopo do presente trabalho MXML).
Esta propriedade pertence à classe “CompositeInterfaceElement”. Ela é utilizada
somente quando a propriedade “isRepeated”, dessa classe, possui como valor true.
Sua função é indicar qual a tag que irá separar os elementos dessa composição,
que se repetem.
• fromAnchor: indica qual é a âncora descrita na ontologia navegacional, a qual a
instância de um elemento abstrato corresponde.
• fromContext: indica qual é o contexto, descrita na ontologia navegacional, o qual a
instância de um elemento abstrato pertence;
• fromIndex: indica qual o índice, descrito na ontologia navegacional, ao qual a
instância de um elemento abstrato se refere;
• fromAttribute: indica qual é o atributo da ontologia navegacional correspondente à
instância de um elemento abstrato;
• fromElement: indica qual é o elemento da ontologia navegacional correspondente à
instância de um elemento abstrato;
• visualizationText: representa um valor que será apresentado pelo elemento
concreto. Esta propriedade é utilizada apenas nos conceitos “ElementExhibitor” e
“IndefiniteVariable”.
36
2.3.4.2 Ontologia de Widgets Concretos
Utilizando-se dos elementos e primitivas da Ontologia de Widgets Abstratos, o
processo de criação da interface modelou e mapeou os elementos de interface desejados
para a ontologia abstrata. Cada elemento deve ser associado a uma das classes da
ontologia e ser descrito através da linguagem OWL. Depois, com estas descrições dos
elementos abstratos, é gerada outra descrição, desta vez mapeando cada elemento
abstrato para um elemento concreto, que possuí descrições mais próximas das interfaces
reais, considerando de maneira ainda rasa questões relativas ao ambiente em que será
desenvolvido o sistema. Para fazer esta descrição, Sabrina Moura (MOURA, 2004) sugere a
utilização de linguagens como XUL, LASZLO e outras. Estas linguagens estão bem mais
próximas da interface concreta do que a proposta por Sabrina Moura, pois descrevem com
certa precisão regras de consistência que devem ser consideradas quando da
implementação do sistema e ainda cada tipo de mapeamento que pode ser feito.
A Ontologia de Widgets Concretos é descrita por algumas classes, que representam
apenas um pequeno conjunto das possibilidades existentes. A seguir será exposto este
conjunto. O presente trabalho irá definir mais classes que encontramos em ambientes de
desenvolvimento MXML/ActionScript 3.0 no capítulo 4.
• Button: representa os elementos que possuem funções embutidas a
serem realizadas, como: submit e reset por exemplo. Essas funções são
executadas quando esse elemento é ativado, através do mouse ou do
teclado;
• CheckBox: representa um tipo de botão que possui 2 estados:
selecionado ou não selecionado. O usuário pode alterar o estado desse
elemento, clicando com o mouse ou via teclado, na caixa de verificação
37
desse elemento. Muitas vezes são utilizados grupos desse mesmo
elemento, representando uma lista de opções, onde podem ser
selecionados n elementos. Esse elemento é composto de um label e de um
botão (caixa de verificação).
• CheckBoxAction: representa um elemento do tipo form, composto
de dois elementos distintos: um CheckBox (descrito anteriormente) e um
Button (com a ação de submit);
• ComboBox: representa uma lista de itens. Consiste em uma caixa
de entrada de texto e de um menu, a partir do qual o usuário pode
selecionar uma dentre as diversas alternativas (uma lista);
• ComboBoxAction: representa um elemento do tipo form, composto
de dois elementos distintos: um ComboBox (descrito anteriormente) e um
Button (com a ação de submit);
• ComboBoxTarget: representa o elemento ComboBox (descrito
anteriormente), composto de uma lista de elementos, onde cada elemento
representa um link específico, ou seja, quando o usuário realizar a escolha
do elemento e selecioná-lo na lista, automaticamente será executada uma
ação, podendo ser esta a chamada de uma interface abstrata;
• Form: representa um conjunto de elementos de interface. Ele possui
dois atributos: method (get ou post - método http para a submissão do
formulário) e action (contém uma informação, indicando o que vai acontecer
quando o formulário for submetido). O atributo action pode conter um
endereço http, um nome de uma página, um endereço eletrônico, entre
outras informações. Quando o botão de um elemento form é selecionado,
todos os valores dos elementos concretos que o compõem, são submetidos
38
para a URL descrita no atributo action. O código HTML desse elemento é
composto da descrição de um botão com a função de submit;
• Image: representa elementos concretos que exibem figuras;
• Label: conhecido como rótulo, representa um valor (texto/string) que
é exibido na interface;
• Link: representa ligações pelas quais se pode navegar para outra
parte:
� do mesmo documento (outra parte na mesma página);
� de outro documento (página, arquivo de imagem) da mesma
aplicação hipermídia;
� de outro documento, em qualquer computador da rede;
� e, evidentemente, para se copiar todos esses arquivos
(download)
• RadioButton: representa um tipo de botão que possui 2 estados:
selecionado ou não selecionado. Seu estado pode ser alterado pelo clique
do mouse ou via teclado na caixa de verificação desse elemento. Na maioria
das vezes são utilizados grupos desse elemento para representar um
conjunto de opções, onde é permitida a seleção de apenas um elemento do
conjunto;
• RadioButtonAction: representa um elemento do tipo form composto
de dois elementos distintos: um RadioButton (descrito anteriormente) e um
Button (com a ação de submit);
39
• RadioButtonTarget: representa o elemento RadioButton (descrito
anteriormente) com um link embutido na definição de cada item da lista
desse elemento;
• TextBox: representa um campo de entrada de informação. Este
campo é composto de apenas uma linha e pode ter n colunas;
• TextArea: representa um campo de entrada de informação. Esse
campo é composto de n linha e n colunas e ele pode conter barras de
rolagem horizontal de vertical, se for o caso;
• Composite: representa composições de elementos de interface.
Uma interface é mapeada em um elemento concreto composite, pois ela
representa uma composição de vários elementos de interface. Podem-se
mapear outras composições mais simples de elementos para esse conceito.
O mapeamento se dá seguindo as regras de consistência, a qual define quais
classes abstratas podem ser mapeadas para quais classes concretas. Um exemplo de regra
de consistência, que expressa a quais elementos de interface concreta o elemento de
interface abstrata SimpleActivator pode ser mapeado, se apresenta a seguir (Figura 2.7):
40
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
41
caixas está diretamente relacionado com as tags da linguagem HTML. Além disso, nesta
propriedade, pode ser definida a classe CSS a qual o elemento estará relacionado, já
produzindo diretrizes para como serão exibidos os elementos de interface visual. Esta
relação é efetivamente construída quando da implementação do sistema.
No contexto do presente trabalho, a implementação feita em Flex permite utilizar
outra gama de containers (Block elements) para o enclausuramento dos elementos de
interface. Da mesma maneira como acontece em HTML, em MXML existem diversos tipos
de elementos de disposição espacial que podem ser utilizados como valor da propriedade
blockElement. Será feito também o mapeamento dos componentes MXML para a Ontologia
de Widgets Abstratos, criando modelos de interface adaptados para a configuração de
interfaces Flex adequadas.
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
42
(marcações), ou seja, transpor um sistema da modelagem de interface abstrata para a
implementação em linguagens de tags se dá de maneira natural.
Quando num determinado ADV existem estados ou outros ADVs que são habilitados
visualmente ou desabilitados, utilizamos a variável perceptionContext para fazer este
controle. Elementos que estão adicionados a esta variável são exibidos na interface, já
elementos retirados da variável deixam de ser percebidos pelo usuário.
O ADV da Figura 2.8 representa a classe navegacional Programa de Radio:
ADV Programa de Rádio
nome: 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,
43
sistemas cliente-servidor, ou questões relativas à interface gráfica complexa. O presente
trabalho focará em como implementar a interface de um sistema OOHDM utilizando
ActionScript 3/Flex, e em como transpor as premissas de interface abstrata para uma
interface concreta no ambiente de programação do Flex, ainda introduzindo o conceito de
STATES do Flex.
44
3 FLEX E FLASH
Neste capitulo serão apresentados dois frameworks de criação e publicação de
aplicações Flash, o Flash e o Flex. Ambos são ambientes para desenvolvimento de
softwares que são escritos na linguagem ActionScript, porém, o primeiro com um enfoque
maior na criação gráfica, com ferramentas de desenho e controle do tempo para animações
e transições através de uma timeline e o segundo com enfoque no desenvolvimento de rich
internet applications (RIAs). A combinação dos dois ambientes proporciona a criação de
aplicações avançadas e com expressividade visual (UIs, diversos tipos de mídia) bastante
superior ao encontrado hoje no campo das aplicações de internet.
3.1 Flex
“Flex é um framework open-source para criação de aplicações altamente interativas,
que são publicadas na maioria dos browsers através do Flash Player ou até mesmo no
desktop (em diferentes sistemas operacionais: Linux, MacOS e Windows) utilizando o
runtime Adobe AIR.“ (ADOBE, 2008a)
Flex nasceu da necessidade de se ter um ambiente de programação que mais se
aproximasse das questões relativas ao desenvolvimento de sistemas web, de maneira que
fossem de fácil criação, que utilizassem o flash player como base de execução sem que o
desenvolvedor precisasse conhecer das técnicas de animação do Flash. Com Flex,
podemos elaborar aplicações para web de maneira similar ao código HTML, pois foi
desenvolvida uma nova linguagem de programação no paradigma de linguagens de
45
marcação, baseada em XML, chamada de MXML que possibilitou essa analogia. Com as
marcações MXML, é possível criar interfaces de aplicações mais facilmente do que no
ambiente de desenvolvimento (IDE) do Flash, que requer um conhecimento de desenho
vetorial e do esquema de criação de componentes.
Apesar desta nova linguagem, MXML está baseado em classes ActionScript 3.0, ou
seja, utiliza-se da mesma estrutura do Flash, mas com a possibilidade de o programa ser
escrito de outra forma. No tempo de compilação, as marcações MXML são transformadas
em instancias das classes ActionScript 3.0, isto é, o programa pode ser escrito utilizando de
maneira hibrida MXML e ActionScript. Normalmente, a primeira faz a composição dos
elementos de interface, suas propriedades e eventos associados, enquanto que a segunda
descreve a lógica da aplicação.
Com o surgimento do Flex, a Macromedia (criadora do sistema) entra para o mundo
da criação das chamadas RIAs (Rich Internet Applications). Estas aplicações podem ser
compiladas em tempo de execução, quando o usuário as requisita no servidor, fazendo com
que a interface pudesse ser gerada neste momento em vez de ser totalmente pré-
determinada em tempo de implementação. Isso possibilita a “concorrência” com sistemas
tradicionais de web dinâmica, como HTML/JavaScript.
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
46
programas se dava através de um editor de textos comum, e um compilador em
linha de comando.
Uma grande característica destes sistemas é que o usuário realizava navegação
entre elementos do sistema de maneira que este não precisava ser recarregado do
servidor a cada requisição, mas sim, analogamente ao que acontece hoje com AJAX
(que realiza comunicação assíncrona), apenas os dados eram modificados, criando
a sensação de que o sistema é conciso, e não um conjunto de páginas sem relação
umas com as outras.
B. Flex 2.0
Esta versão do Flex é o primeiro produto Macromedia lançado sob a bandeira da
Adobe. A maior mudança feita nesta versão é a migração de uma IDE ultrapassada
para uma totalmente nova baseada na plataforma Eclipse. Também não se fez mais
necessária a utilização da plataforma Flex Data Services, portanto uma aplicação
Flex podia ser publicada apenas usando o SDK Flex.
Ao mesmo tempo, a Adobe lança a linguagem ActionScript 3.0, fazendo com que o
Flex agora suportasse todas as características desta nova linguagem.
C. Flex 3.0
A ultima versão do Flex foi lançada pela Adobe com o código aberto, apesar da IDE
continuar proprietária. Foi lançada também pela primeira vez a plataforma Adobe
AIR, que trás os sistemas criados em Flex para o desktop, possibilitando a interação
entre o sistema ActionScript 3.0, PDF, JavaScript e HTML, o sistema de arquivos e
hardwares do usuário. Foi também reformulada e ampliada a integração entre Flex e
os outros softwares de criação da Adobe.
47
3.1.2 Linguagens de programação.
As linguagens Flex agregam dois importantes paradigmas de desenvolvimento de
software: as linguagens de marcação (markup languages), representadas pela MXML e as
linguagens de programação orientadas a objeto, representada pela ActionScript 3.0.
Como as linguagens de marcação são inadequadas para prover uma programação
lógica para a comunicação entre o usuário e o sistema, é utilizada em conjunto em um
programa escrito em MXML a linguagem ActionScript, através da marcação <mx:Script>,
que suporta programação orientada a objetos, e permite a comunicação entre diversos
sistemas e gerenciamento de eventos emitidos pelos componentes lógicos ou pelo usuário.
Um programa escrito em MXML representa em suas marcações, instâncias das
classes ActionScript, ou seja, são linguagens baseadas na mesma API (as classes
ActionScript). A Figura 3.1 exibe um esquema de como as aplicações Flex são construídas.
Figura 3.1 - Esquema de publicação de aplicações Flex.
48
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).
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
49
maneira que a disposição dos elementos é tratada de maneira adequada e de fácil
interpretação.
MXML, baseada em XML, é composta de várias marcações que compõe a aplicação,
sendo mais completa que HTML, por prover uma gama mais completa e interessante de
componentes de programação, como menus e elementos de controle de dados mais
complexos que as simples e ‘duras’ tabelas do HTML. Além de facilitar a publicação de
interfaces, MXML também pode ser usado nas camadas lógicas, fora do âmbito visual,
fazendo, por exemplo, chamadas a funções para controle de bases de dados e integração
com outros sistemas escritos em outras linguagens, como linguagens server-side como
PHP, ColdFusion ou JSP, entre outras.
Em uma marcação MXML podemos definir os estilos, atributos e eventos do objeto,
de maneira que os eventos podem fazer chamadas a funções ActionScript da mesma
maneira que HTML faz chamadas a funções JavaScript.
“A diferença básica entre a publicação MXML e a publicação HTML, é que a primeira
é “renderizada” pelo Flash Player, em contrapartida da “renderização” pelo browser no
HTML. Isso permite uma gama de possibilidades em relação à apresentação da interface,
que pode conter animações, efeitos de transição, efeitos gráficos, vídeos e sons
nativamente, sendo muito mais poderoso e muito mais amigável ao usuário do que a
publicação baseada em páginas do HTML.” (COENRAETS, 2003)
O sistema de publicação do MXML se assemelha muito com as JavaServer Pages
(JSP) quando é feita compilação “On The Fly”. O usuário (cliente) faz a requisição via http
para o servidor, que compila em tempo real o código MXML para um executável (.SWF) e o
envia para o cliente. Em JSP o que acontece é semelhante, a diferença é que o código é
executado no servidor (Java servlets), em contrapartida o código do ambiente MXML é
executado no cliente, proporcionando uma menor sobrecarga do servidor e distribuindo o
processamento. A partir do momento que um cliente recebe o código executável compilado,
50
as próximas requisições a um mesmo arquivo não gerarão uma compilação, bastando ao
servidor determinar qual é o arquivo que o cliente precisará executar, o qual já estará em
poder do mesmo. Isso traz inúmeras vantagens ao que diz respeito ao volume de
processamento efetuado pelo servidor e tráfego de rede. Também é possível publicar o
arquivo executável compilado ([.SWF] para o Flash Player). Quando compilamos um
programa escrito em MXML, é gerado um código intermediário em ActionScript 3.0 e só
então esse código é traduzido para o executável (.SWF), ou seja, as marcações MXML
representam classes ou atributos das classes ActionScript, então, são instanciadas estas
classes de acordo com a estrutura de tags quando o programa é compilado. A Figura 3.2
representa o esquema de publicação de aplicações Flex.
Figura 3.2 – Esquema de publicação de Aplicações Flex
utilizando PHP como arquitetura server-side.
51
O programa a seguir (Código Fonte 3.1) exemplifica uma aplicação MXML. Ela copia
o texto contido em um campo de texto para outro campo de texto quando se pressiona o
botão “Copiar”.
Código Fonte 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
Figura 3.3:
52
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
53
de canvas (telas com posicionamento absoluto (x, y) dos objetos filhos) sobrepostos que o
usuário pode escolher visualizar na ordem que achar mais conveniente, através de
controles de navegação, como Tabs, ou botões.
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)”.
54
Esta aplicação pode ser implementada conforme o Código Fonte 3.3 que produzirá
uma aplicação de acordo com a Figura 3.4.
Código Fonte 3.3 - Exemplo de implementação de view states
1 <?xml version="1.0" encoding="utf-8"?> 2 <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" 3 verticalAlign="middle" 4 width="340" height="250" 5 > 6 <mx:Script> 7 <![CDATA[ 8 import mx.controls.Alert;
9 10 private function login(u:String, s:String):void{
11
12 Alert.show("Usuário: "+ u + "\nSenha: "+ s, "Login");
13 }
14
15 private function registrar(u:String, s:String, c:String):void{
16 if(s == c)
17 Alert.show("Usuário: "+ u + "\nSenha: "+ s, "Registro OK");
18 else Alert.show("Senha não confere! \n Senha: "+ s +
19 "\nConfirma: "+ c, "Registro Inválido!!!");
20 }
21 ]]> 22 </mx:Script> 23 24 <mx:states> 25 <!-- 26 O estado Registro é baseado no base state. 27 Todos os estados são baseados no base state por default, 28 então deixa-se a propriedade basedOn em branco. 29 --> 30 <mx:State name="Registro" basedOn=""> 31 32 <!—Adiciona um componente FormItem ao form. --> 33 34 <mx:AddChild 35 relativeTo="{loginForm}" 36 position="lastChild" 37 creationPolicy="all" 38 > 39 <mx:FormItem id="confirma" label="Confirme:"> 40 <mx:TextInput id="senha2"/> 41 </mx:FormItem> 42 </mx:AddChild> 43 44 <!—aplica propriedades no Painel e no botão --> 45 <mx:SetProperty target="{loginPanel}" 46 name="title" value="Registro"/> 47 48 49 <mx:SetProperty target="{loginButton}" 50 name="label" value="Registro"/> 51 52 <mx:SetEventHandler target="{loginButton}"
55
53 name="click" 54 handler="registrar(user.text, senha.text, senha2.text);"/> 55 56
57 <!—remove o LinkButton existente. --> 58 59 <mx:RemoveChild target="{registerLink}"/> 60 61 <!-- 62 adiciona um novo Linkbutton para trocar o 63 o view state de volta para o base state. 64 --> 65 <mx:AddChild relativeTo="{spacer1}" position="before"> 66 <mx:LinkButton 67 label="Retornar para Login" click="currentState=''"/> 68 </mx:AddChild> 69 70 </mx:State> 71 72 </mx:states> 73 74 <mx:Panel 75 title="Login" id="loginPanel" 76 horizontalScrollPolicy="off" verticalScrollPolicy="off" 77 verticalAlign="middle"
78 > 79 80 <mx:Form id="loginForm"> 81 <mx:FormItem label="Usuário:"> 82 <mx:TextInput id="user"/> 83 84 </mx:FormItem> 85 <mx:FormItem label="Senha:"> 86 <mx:TextInput id="senha"/> 87 </mx:FormItem> 88 </mx:Form> 89 90 91 <mx:ControlBar> 92 <mx:LinkButton 93 label="Quer se registrar?" id="registerLink" 94 click="currentState='Registro'" 95 /> 96 97 <mx:Spacer width="100%" id="spacer1"/> 98 <mx:Button label="Login" id="loginButton" 99 click="login(user.text,senha.text);"/> 100
101 </mx:ControlBar>
102
103 </mx:Panel>
104 </mx:Application>
56
Figura 3.4 - Dois estados de uma aplicação. À esquerda, o base state e à direta, o estado "Registro"
A linha 94 do código representa o evento “click” do componente LinkButton. Este
evento altera a variável <mx:states> da aplicação (linha 24) e muda o view state atual para
“Registro”. A troca de funcionalidade do botão de confirmação está nas linhas 99
(declaração inicial) e 54 (alteração do método chamado).
A transição de um estado para outro pode ser definida utilizando efeitos visuais para
criar uma experiência de usabilidade na troca entre os estados através da marcação
<mx:Transitions>. O desenvolvedor pode definir seqüências e paralelismos em uma
transição, definindo a ordem e concomitância em que acontecem animações, mudanças de
propriedades dos objetos e retirada ou adição de elementos de interface.
Os view states podem ser utilizados para implementar estados de componentes
customizados, e não só da aplicação como um todo. O exemplo mais básico seria um botão
que muda de estado a cada evento do mouse, como mouseOver, mouseDown, mouseUp e
assim por diante. São descritos estados para cada condição e, a cada evento disparado, o
estado é alterado.
Os view states são organizados hierarquicamente, sendo que cada aplicação ou
componente sempre tem um estado inicial (“base state”), e todos os outros estados são
57
filhos dele ou filhos de filhos. No caso da aplicação de exemplo acima, o estado base é
composto por todo conteúdo do mx:Panel (“loginPanel”) e o estado filho representado pelo
conteúdo da marcação mx:state (“register”). Caso seja declarado um estado vazio, o
conteúdo dele será idêntico ao do pai.
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.
58
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,
59
por exemplo definir que um elemento terá 100% da largura do container pai, fazendo
com que mesmo que o Canvas mude de tamanho, o elemento sempre toque as
bordas laterais do ‘pai’. Com este container, podemos fazer com que seus filhos
(containers e controles) se sobreponham, diferentemente de outros elementos
agrupadores nos quais sempre os elementos serão dispostos em seqüência.
• ControlBar
Barra de controle que serve para ser colocada no rodapé de elementos Panel ou
TitleWindow. Ele sempre deve ser a última marcação colocada dentro destes
elementos.
• DivideBox
São caixas divididas, nas quais o usuário pode alterar o tamanho das células. Assim
como o elemento “box”, não se usa a marcação <mx:DivideBox>, mas sim
<mx:HDivideBox> para uma caixa dividida em células dispostas lado a lado e
<mx:VDivideBox> para caixa dividida em células dispostas uma abaixo da outra.
• Form
Formulários são containeres que agregam elementos de informação que serão
enviados ao sistema para que o controle de dados seja efetuado. Neles,
diferentemente dos forms HTML, podemos criar regras para definir quais campos do
formulário são obrigatórios, e quais receberão controles de validação de dados.
Também podemos utilizar folhas de estilos para definir a aparência dos controles
internos a ele.
• FormHeading
São cabeçalhos formados por um título, que indicam um subconjunto de itens de
controle de dados dentro de um Form. Os subitens deste cabeçalho ficam alinhados
60
com o mesmo, facilitando ao usuário a compreensão da diferença entre os conjuntos
de dados. Apesar disso, todos os subitens de todos os cabeçalhos dentro de um
Form pertencem a este mesmo Form. Cada um destes subconjuntos pode ter uma
folha de estilos distinta.
• FormItem
Os itens de formulários são duplas “label”-“elemento”, onde elemento pode ser um
ou mais agrupadores ou controles arranjados verticalmente ou horizontalmente.
• Grid
Grids são agrupadores semelhantes as tabelas HTML. Eles podem conter uma ou
mais linhas e cada linha pode conter uma ou mais colunas, ou itens. Sua utilização
se dá da seguinte maneira: uma marcação <mx:Grid> seguida de uma ou mais
marcações <mx:GridRow>, e, dentro de cada uma destas, marcações
<mx:GridItem> que representam as colunas da grade. Cada GridItem pode conter
quantos ‘filhos’ forem necessários.
• Panel
Um painel é composto de uma barra de título, um título, uma borda e um canvas que
é o espaço destinado aos ‘filhos’ do painel.
• TabNavigator
TabNavigator é uma extensão do container ViewStack, adicionando uma barra de
aletas (controle TabBar), que faz o controle de navegação entre as páginas do
viewstack. Quando se aciona uma destas aletas, a página correspondente do
viewstack associado é exibida, escondendo as demais.
• Tile
61
Exibição de elementos dispostos em mosaico
• ViewStack
Disposição de elementos em múltiplos canvas dos quais apenas um está visível por
vez. Enquanto os outros não são acessados, não são carregados na memória pelo
programa.
3.1.3.3.2 Controles
o Button
É um botão tradicional, com aspecto gráfico que indica que pode ser
acionado com o mouse ou teclado. Este componente é composto de um retângulo
externo, um label e/ou um ícone. Os botões são normalmente utilizados em conjunto
com event listeners, que fazem o controle do funcionamento do botão em função das
ações do usuário. Quando é acionado, o botão emite um evento do tipo click e um
mouseDown. Um botão pode ter o comportamento de uma chave liga/desliga, ou
seja, ele pode ter dois estados representados pela propriedade toggle, ou ser do tipo
mais simples (equivalente a um push-button).
o ButtonBar [navBar]
Os ButtonBars são conjuntos de botões logicamente relacionados, dispostos
de maneira vertical ou horizontal. Os botões são do tipo push-button, ou seja, não
memorizam o estado depois de receberem uma ação de ativação. A maneira de
adicionar ou remover botões da barra de botões é análoga à manipulação de dados
em uma lista, com os métodos addItem() e removeItem(), simplificando o
gerenciamento da display list ActionScript 3.
o CheckBox [button]
62
Checkbox é um componente composto de um label e uma caixa de seleção,
a qual pode ou não conter uma marca de ativação. Os elementos CheckBox não são
mutuamente exclusivos, ou seja, podemos marcar ou desmarcar as várias
CheckBox contidas em uma aplicação conforme desejado (em contrapartida, ver
RadioButton).
o ColorPicker [combobase]
É um selecionador de cores, no qual o usuário pode rapidamente escolher
uma cor dentre uma gama de cores definidas.
o ComboBase
ComboBase é a classe mãe de componentes como ComboBox, ColorPicker
e DateField. É composta por um campo de texto, e um botão para o acionamento de
uma lista na qual pode se escolher a opção que será selecionada. Não é utilizada
diretamente como uma marcação MXML, mas serve de base para os componentes
ColorPicker e ComboBox.
o ComboBox [combobase]
O ComboBox é um componente composto de uma lista a qual o usuário
seleciona apenas uma opção, uma caixa de texto que contém a opção selecionada,
e um botão para exibir esta lista. É um componente análogo ao SELECT do HTML
mas com a diferença de que o usuário pode (quando permitido) inserir novas
entradas que não estão na lista, a partir da própria caixa de texto do componente.
o DataGrid
O DataGrid é como uma lista mas que pode mostrar mais de uma coluna de
dados, sendo útil para a exibição de elementos que tem varias propriedades. É um
componente que tem as seguintes características:
63
� as colunas podem ser de tamanhos diferentes;
� as colunas podem ser redimensionadas em tempo de execução pelo usuário;
� as colunas podem ser reordenadas em tempo de execução pelo usuário;
� possibilidade de usar um itemRenderer para exibição de dados que não
sejam textuais;
� possibilidade de ordenação das linhas acionando uma das colunas.
DataGrid é um componente de interface construído para exibição de dados, e
não uma ferramenta de disposição de elementos como as TABLES HTML. Para tal,
existem os containers em MXML.
o DateChooser
Este componente é composto de uma barra de título, mostrando o nome do
mês e o ano, e um calendário mostrando os dias daquele mês específico. O usuário
pode selecionar uma data, um intervalo de datas ou então datas múltiplas. O
controle dispõe de acionadores para modificar o ano/mês e o desenvolvedor pode
restringir o intervalo de datas a serem exibidas.
o DateField [combobase]
O DateField é um controle composto por um campo de texto (TextField) para
exibição de uma data, e um botão que aciona um DateChooser para seleção desta
data. Quando a data é selecionada, o DateChooser é fechado e a data selecionada
preenche o campo de texto. O usuário pode também digitar a data diretamente no
campo de texto.
o HorizontalList
64
Este componente exibe uma lista na qual os elementos são dispostos lado a
lado. Caso existam mais elementos do que o número que pode ser exibido ao
mesmo tempo dependendo do tamanho desta lista, o componente pode exibir uma
barra de rolagem para o acesso a estes itens.
o HScrollBar/VScrollBar [scrollBar]
É uma barra de rolagem horizontal/vertical para o controle de exibição dos
dados quando estes preenchem um espaço maior do que o container onde eles
estão inseridos. Apesar de ser um controle independente, podemos associar a barra
de rolagem a outros componentes para efetuar o controle de rolagem em seus
conteúdos.
As barras de rolagem são compostas por quatro elementos: dois botões com
setas, um botão de rolagem e um trilho no qual o botão de rolagem percorre. A
posição do botão de rolagem e a exibição das setas dependem do estado do
controle.
o HSlider/VSlider
Os controles HSlider e VSlider permitem ao usuário fazer seleção de um ou
mais valores dentre um intervalo. Composto de um trilho horizontal/vertical e um ou
mais botões de rolagem. A seleção de valores é feita de maneira visual, arrastando
os botões pelo trilho, e o valor é definido de acordo com valores máximo e mínimo
definidos no trilho. Este conjunto de valores pode ser contínuo, ou ter valores
específicos entre o máximo e o mínimo.
o Image
O controle de exibição de imagens permite importar arquivos JPG, PNG, GIF
e SWF. Além disso, provê funções para embarcar estes arquivos no executável final
65
em tempo de compilação. Este componente é normalmente utilizado para
importação de arquivos estáticos, que não farão parte da lógica do sistema e para
criação de ItemRenderers. Para importação de outras aplicações Flex/Flash, é
recomendado o uso de outro componente, o SWFLoader.
Imagens embarcadas são carregadas imediatamente, pois são parte do
código executável, mas em contrapartida fazem o tamanho da aplicação aumentar.
Imagens embarcadas também fazem a manutenção da aplicação ser mais
complexa, pois temos que recompilar a cada vez que a imagem for alterada. A
maneira de contornar este problema, é carregar as imagens em tempo de execução,
fazendo um HTTPRequest ou simplesmente carregando um arquivo no servidor
onde a aplicação está rodando. Estas imagens ficam independentes da aplicação,
então quando as alteramos, não precisamos recompilar todo o sistema.
Caso sejam utilizadas imagens no formato PNG ou GIF, podemos utilizar o
canal alpha destas para criar fundos ou imagens com transparências, aumentando o
grau de qualidade gráfica da aplicação.
o Label
Os Labels são linhas simples de texto, não são editáveis mas podem ser
selecionados caso o desenvolvedor permita. Representam informações textuais que
podem ser controladas por folhas de estilos CSS. Labels não possuem bordas ou
fundo e não podem receber o foco da aplicação.
o LinkButton [button]
É um controle Button sem bordas e seu label é aceso (um efeito visual
“acende” o botão) quando o usuário passa o foco da aplicação (com mouse ou
teclado) sobre o componente.
66
o LinkBar
O LinkBar é um conjunto de LinkButtons, dispostos horizontalmente ou
verticalmente. Sua aplicação típica é de controlar outros elementos de interface
como ViewStacks, ou para criar um conjunto independente de Links.
o List
É uma lista simples de elementos, na qual uma barra de rolagem pode ser
inserida caso o número de itens seja maior do que o número que pode ser exibido
neste componente dependendo de seu tamanho. O usuário pode fazer a seleção de
um ou mais itens da lista, dependendo do valor da propriedade
allowMultipleSelection.
o Menu [list]
O controle Menu cria uma lista pop-up de elementos que podem ser
selecionados um a cada vez, similarmente aos menus de aplicações em sistemas
operacionais. Estas listas podem ter vários níveis de submenus quanto desejado.
Depois de uma destas listas serem abertas, elas se mantém visíveis até que uma
das seguintes ações ocorra:
� Uma chamada à função Menu.hide();
� O usuário seleciona um item de menu
� O usuário “clica” fora do menu
� O usuário seleciona outro componente da aplicação.
o MenuBar
67
A barra de menu é um conjunto de componentes Menu, disposta em uma
barra horizontal, geralmente no topo da aplicação, com um botão para cada
componente deste conjunto.
o NumericStepper
Este componente permite ao usuário fazer a seleção de um número dentre
um conjunto enumerável, ou um intervalo de números. É composto de uma caixa de
texto para informar o número selecionado, e botões para adicionar ou subtrair o
número selecionado.
o PopUpButton
Os PopUpButtons são botões nos quais a ação a ser feita pode ser
selecionada da mesma maneira como acontece em ComboBoxes. é composto de
dois elementos, o botão em si e outro botão que exibe uma lista de ações. Após a
seleção ser feita, a parte do componente que é o botão em si executa aquela
o ProgressBar
São barras de progresso que indicam o progresso de uma tarefa ao longo do
tempo. Estas tarefas incluem consultas a banco de dados, carregamento dinâmico
de imagens e arquivos em geral, etc. Elas podem ser classificadas em dois tipos:
determinada ou indeterminada. No caso de a tarefa a ser cumprida tenha um tempo
fixo para acontecer, usamos o tipo determinado, por exemplo em marcações
temporais de um determinado acontecimento. Caso o tempo seja indeterminado,
como por exemplo em carregamento de arquivos, onde o tempo depende da
velocidade da transferência de dados, utilizamos a forma indeterminada.
o RadioButton
68
RadioButtons são botões que funcionam como botões comuns, mas o label
deste está fora do gráfico que o representa. Este componente é utilizado em
conjunto com componentes do mesmo tipo e são enclausurados em grupos,
utilizando o componente RadioButtonGroup, o qual faz com que apenas um de seus
filhos possam ser selecionados de cada vez. Quando o usuário seleciona um destes
botões de um mesmo grupo, os outros tem sua seleção automaticamente removida.
o RadioButtonGroup
Determina um conjunto de RadioButtons
o RichTextEditor
É um editor de textos no qual o usuário pode inserir conteúdo e mudar a
formatação do texto. É composto de duas partes principais: uma caixa de textos
(TextArea) onde o usuário pode digitar texto e um container contendo controles para
o usuário especificar as características de formatação do texto inserido.
o Spacer
Spacer são elementos de disposição de componentes em um container pai,
que auxiliam no layout do container. São elementos invisíveis, mas que fazem com
que, por exemplo, os elementos fiquem sempre nas laterais do container, mesmo
que o tamanho do mesmo seja alterado.
o SWFLoader
É um componente que permite o carregamento e exibição de animações ou
aplicativos Flash/Flex. É um componente poderoso, pois quando carregamos uma
aplicação dentro de outra, estamos utilizando conceitos de reusabilidade, já que
podemos fazer a comunicação da aplicação base com a carregada. Apesar de este
69
componente não receber o foco da aplicação, seus elementos internos o recebem e
a interação é completa.
o TabBar
É um conjunto de botões mutuamente exclusivos em sua seleção,
representados de maneira a se parecerem com abas de um arquivo. Geralmente
são utilizados em conjunto com ViewStacks, mas podemos utilizá-los como qualquer
conjunto de botões que são mutuamente exclusivos (quando um é ativado, todos os
outros são desativados).
o Text
O controle de texto é derivado do Label, mas pode conter mais de uma linha
de conteúdo não editável. Este controle não suporta barras de rolagem, podemos
utilizar tags HTML para a formatação do conteúdo e decidir se este será ou não
selecionável.
o TextArea
TextArea é um componente composto de uma área de texto, uma borda e
barras de rolagem opcionais. Também suporta tags HTML para a formatação do
conteúdo.
o TextInput
Este controle é uma caixa de texto de apenas uma linha, na qual o usuário
entra com dados arbitrários. Quando utilizado como filho de um componente Form,
podemos utilizar validadores de dados, e também indicar se o campo é de
preenchimento obrigatório ou opcional. Estes controles possuem 4 estados distintos:
preenchido, selecionado, desligado e erro. Eles despacham eventos quando da
70
inserção de conteúdo e quando perdem o foco da aplicação, para ser feita a
validação e controle de obrigatoriedade.
Este componente é utilizado como subcomponente em vários outros
componentes, como o RichTextEditor, NumericStepper, e Comboboxes. Quando
associamos uma folha de estilos CSS à classe do componente, deve-se tomar
precaução pois todos estes outros componentes pais serão afetados, a não ser que
seja explicitamente indicado outro estilo.
o TileList
Este componente exibe um número de itens dispostos em células. Ele exibe uma
barra de rolagens se isso se fizer necessário, vertical ou horizontal.
o ToogleButtonBar
Este componente é um conjunto de buttons no qual apenas um deles pode ser
ativado por vez, e quando isto é feito, ou outros botões são colocados no estado
normal.
o ToolTip
Tooltips são componentes de informação de auxílio ao usuário. Quando este move o
mouse sobre um determinado componente gráfico, o ToolTip é exibido com texto
informativo sobre aquele componente. Sua funcionalidade pode ser expandida de
acordo com o projeto, inserindo novas funcionalidades.
o Tree
Este elemento possibilita a visualização de dados arranjados em uma estrutura de
árvore, com galhos e folhas. Uma folha é um ponto final de uma árvore, que pode
71
conter inúmeras folhas. Um galho é um nodo intermediário que contém outros
galhos ou folhas, ou pode estar vazio.
o VideoDisplay
Este componente permite a exibição de vídeos no formato .FLV. Suporta download
progressivo através de requisições http, ou streaming a partir de servidores Flash
(Flash Media Server, da Adobe, ou o Red5, open-source). Aceita também streams
de vídeos de câmeras, em tempo real.
3.2 Flash
A palavra Flash pode ser usada tanto para nos referirmos ao hoje Adobe Flash
Professional multimedia authoring program bem como ao Adobe Flash Player. O Adobe
Flash Professional é um software utilizado para criação do conteúdo para o Adobe
Engagement Platform. O Adobe Flash Player é o cliente universal, que instalado no
navegador do usuário ou em versão stand-alone, proporciona, através de uma máquina
virtual chamada AVM (ActionScript Virtual Machine) a exibição de conteúdo Flash. Este
cliente suporta gráficos vetoriais, bitmaps (mapas de bits) e streaming de áudio e vídeo
entre outros formatos de mídia. Resumindo,o Adobe Flash Professional é um ambiente
integrado de desenvolvimento (IDE) e o Adobe Flash Player é uma máquina virtual utilizada
para executar os programas gerados pelo primeiro.
O Flash surgiu em 1996 a partir de aprimoramentos de softwares de CAD
(Computer-Aided Design) como o IntelliDraw. O grande diferencial do Intellidraw sobre os
softwares concorrentes na época, como o Adobe Illustrator e o Aldus Freehand, era que
este permitia, alem de desenhar usando métodos tradicionais de CAD, a construção lógica
72
de elementos de desenho, como por exemplo, uma linha que sempre conecta dois objetos,
mesmo que estes sejam modificados, ou um gráfico de barras que mudaria de tamanho de
acordo com um número digitado em uma caixa de texto pelo usuário.
"If you ever think Flash is difficult to use, you should try
drawing with a joystick on an Apple II before the concept of
undo was invented. That will test your patience." Jonathan
Gay, Creator of Flash (GAY, 2008)
“Em 1995 a FutureWave (empresa criadora da primeira versão do Flash) começou a
receber muitas sugestões de usuários para transformar o SmartSketch (sucessor do
Intellidraw) em um software de animação gráfica. A idéia foi muito bem aceita, mas um
problema surgia nesta ação. A única maneira de se publicar animações na época era em
formatos de vídeo, como VHS ou Betamax, ou então em CD-ROMs com hipermídia e o
mercado de ferramentas de animação era muito pequeno. Nesta mesma época estava
surgindo a world wide web como a conhecemos hoje, e a possibilidade de publicar
animações na internet abriu as portas para a FutureWave software, que começou então a
projetar um web-player em Java que reproduziria as animações feitas no SmartSketch, mas
esta era lenta e instável.” (Flash Magazine > News, 2000). Logo depois, a Netscape lançou
seu pacote de API’s (Application Programming Interface) para a produção de plug-ins, o que
fez com que as animações do SmartSketch pudessem ser reproduzidas no próprio
navegador no computador do usuário, o que aumentou muito a performance do player.
Em dezembro de 1996, a Macromedia adquire a FutureWave Software e o
FutureSplash Animator se torna a versão 1.0 do Macromedia Flash. Durante o tempo em
que o Flash permaneceu sob a bandeira da Macromedia, muitas modificações e
aprimoramentos foram feitos. A seguir, a Figura 3.5 mostra uma tela da primeira versão do
FutureSplash Animator.
73
Figura 3.5 – Tela do Future Splash Animator
Em meados de 2005 a Macromedia é adquirida pela Adobe, e então é criada a
Adobe Engagement Platform, nome da suíte de aplicativos criada pela Adobe resultante da
junção com a Macromedia. Esta linha de produtos é organizada em uma arquitetura de
cinco partes: O cliente universal, ou runtime client (Reader, Flash Player), componentes
server-side (Flash Media Center), frameworks de desenvolvimento de aplicações
(Cairngorm), ferramentas de desenvolvimento (Dreamweaver, Flash, Flex), e o Adobe
Solutions Network (treinamento e suporte).
Desde a sua introdução em 1996, a tecnologia Flash se tornou um padrão na adição
de animações e conteúdo interativo em páginas da internet em um tempo que as páginas
eram construídas basicamente com HTML e um uma parcela muito reduzida utilizava
métodos de criação dinâmica de páginas. A partir de então muitos outros softwares,
sistemas complexos e dispositivos de hardware são capazes de exibir conteúdo Flash e até
mesmo criar conteúdo Flash. Geralmente Flash é utilizado para criar animações, pequenos
anúncios em websites, vários tipos de componentes de interface para web, para adicionar
vídeo em páginas da internet e mais recentemente para criar a aplicação web como um
todo.
74
As versões mais recentes do Flash são :
• Macromedia Flash Professional 8 (13 de Setembro de 2005) – Ultimo Flash
lançado sob bandeira da Macromedia, esta versão suporta ActionScript 2.0 (não
orientado a objetos). Seu maior feito foi ter incluído controles de vídeo avançados
que fizeram surgir uma verdadeira onda de vídeos na internet publicados na
plataforma Flash. Esta versão era focada em expressividade, qualidade, vídeo além
de autoração para dispositivos móveis. Novos recursos incluíam Filtros de bitmaps,
blend modes, controle de suavidade para animações, estilos de pincel avançados,
desenho baseado em objetos, cache de bitmaps em tempo de execução, 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.
75
4 A PROPOSTA
A fim de aperfeiçoar a tarefa de mapeamento de um modelo abstrato de interface
OOHDM para implementação da interface concreta em um sistema baseado em Flex, este
trabalho sugere extensões às etapas de Projeto de Interface Abstrata e Implementação do
OOHDM
A Figura 4.1 nos mostra as etapas do OOHDM e seus passos internos. Os artefatos
gerados que são trocados entre as etapas estão representados acompanhando as
transições entre as etapas. A Figura 4.2 mostra o método OOHDM com as extensões
propostas no presente trabalho.
1. Modelagem das classes conceituais
Implementação
1. Especificação dos widgets abstratos
Especificação dos widgets concretos 2.
3. Especificação de ADVs
UIDs
classes conceituais
classes e contextos navegacionais.
UIDs
UIDs
ADVs
1. Modelagem das classes navegacionais
2. modelagem dos contextos navegacionais
classes e contextos navegacionais.
Projeto deInterface Abstrata
Projeto deNavegação
ModelagemConceitual
Análise deRequisitos
1. Criação dos casos de uso
2. Especificação dos UIDs
Figura 4.1 – Esquema simplificado do processo do método OOHDM
76
Análise deRequisitos
ModelagemConceitual
Projeto deNavegação
Projeto deInterface Abstrata
1. Modelagem das classes conceituais
1. Modelagem das classes navegacionais
2. modelagem dos contextos navegacionais
Implementação
1. Criação dos casos de uso
2. Especificação dos UIDs
1. Criação da interface utilizando <mx:States>
1. Especificação dos abstratos
Especificação dos concretos MXML
Flex
widgets
widgets2.
3. Especificação de ADVs para
UIDs
classes conceituais
classes e contextos navegacionais.
UIDs
UIDs
ADVs Flex
classes e contextos navegacionais.
Figura 4.2 – Esquema do processo OOHDM adaptado para criação de sistemas Flex.
São propostas quatro extensões ao processo OOHDM. A primeira extensão faz
parte do Projeto de interface Abstrata e sugere o mapeamento das primitivas de interação
usuário-sistema extraídas dos UIDs e atributos das classes navegacionais para elementos
da Ontologia de Widgets Abstratos. A segunda extensão consiste em um mapeamento das
classes da Ontologia de Widgets Abstratos para um novo conjunto de widgets concretos,
baseado em componentes de interface do Flex (componentes MXML), criando novos
elementos na Ontologia de Widgets Concretos. Na terceira extensão, os ADVs são
adaptados para acomodar a informação das Ontologias Abstrata e Concreta para prover
uma descrição detalhada e pronta para o mapeamento em MXML. A quarta extensão é feita
entre o Projeto de interface e a Implementação, mas principalmente na última e sugere a
77
definição dos estados de interface Flex (View States <mx:State>) de acordo com um
conjunto de ADVs pré-determinados para modelarem estes estados.
4.1 Extensão 1 - Especificação dos widgets abstratos
Esta extensão ao processo OOHDM utiliza uma proposta sugerida por Remáculo
(2005) para mapear os atributos das classes navegacionais e entidades dos UIDs para os
elementos da interface abstrata. Este mapeamento indica a qual classe da Ontologia de
Widgets Abstratos cada elemento do UID pode ser relacionado. Desta maneira, é utilizado
na construção da interface abstrata, na qual são identificados os atributos e métodos das
classes navegacionais, e segundo suas “origens” nos UIDs, são mapeados para
determinadas classes da Ontologia de Widgets Abstratos.
Um atributo de uma classe navegacional que representa um item de dado exibido
pelo sistema num determinado UID, por exemplo, pode ser mapeado para
“elementExhibitor” ou “simpleActivator” dependendo de sua função. Caso no UID este
elemento seja apenas uma exibição de conteúdo, o mapeamento deve ser feito para
“elementExhibitor”, mas, se este elemento seja passível de ativação, como em um texto
com âncora, ele deve ser mapeado para a classe “simpleActivator”.
Com este mapeamento, obtém-se o primeiro conjunto de informações para o projeto
da interface abstrata identificando que tipo de exibição terá cada atributo da classe
navegacional.
A Tabela 4.1 apresenta as regras de mapeamento, indicando a classe da Ontologia
de Widgets Abstratos que cada elemento do UID está associado.
78
Tabela 4.1 Mapeamento de elementos dos UIDs
para a Ontologia de Widgets Abstratos. (REMÁCULO, 2005, p. 39)
UIDs Widgets Abstratos
Item de dado e Item de dado personalizado
ElementExhibitor ou SimpleActivator
Estrutura A estrutura toda pode ser mapeada para um ElementExhibitor ou SimpleActivator, assim como cada elemento da estrutura pode ser mapeado para um ElementExhibitor ou SimpleActivator. Neste caso, 1º deve-se mapear a Estrutura para um CompositeInterfaceElement, para que depois os elementos que compõem a Estrutura sejam mapeados para ElementExhibitor ou SimpleActivator.
Conjunto, Conjunto com conteúdo personalizado
e Conjunto em disposição diferenciada
1º passo: mapear o conjunto para um CompositeInterfaceElement.
2º passo: mapear cada elemento do conjunto para um ElementExhibitor ou SimpleActivator, conforme o objetivo do item de dado ou estrutura que compõem o conjunto.
Dado opcional ElementExhibitor ou VariableCapturer. No caso de VariableCapturer, o elemento pode ser mapeado para: IndefiniteVariable, ContinuousGroup, DiscreetGroup, MultipleChoices ou SingleChoices.
Entrada do Usuário IndefiniteVariable
Entrada do Usuário Enumerada SingleChoice, MultipleChoice
Saída do Sistema Recebe o mapeamento descrito para os elementos dos UIDs, conforme o tipo de elemento que representa a Saída do Sistema (Item de dado, Item de dado personalizado, Estrutura, Conjunto, Conjunto com conteúdo personalizado, Conjunto em disposição diferenciada, Dado Opcional, Entrada do Usuário e Entrada do Usuário Enumerada).
Texto ElementExhibitor
Estado de Interação, Estado Inicial da Interação e Estados Alternativos da Interação.
CompositeInterfaceElement. Caso o Estado de Interação seja um conjunto de CompositeInterfaceElement, o estado de interação será a associação dos CompositeInterfaceElements.
79
Sub-estados de um Estado de Interação.
CompositeInterfaceElement
Transição com Seleção da Opção X e Transição
com Seleção da Opção Restrita X.:
SimpleActivator. No caso da opção precisar de outro elemento para que o estado de interação destino se torne o foco da interação, a mesma deve ser mapeada para MulipleChoice ou SingleChoice e atrelada a um SimpleActivator para que a transição entre Estados de Interação ocorra.
Transição com Seleção de N Elementos
Os conceitos que suportam a seleção de 1 ou mais elementos especificados nos UIDs são: ContinuousGroup*,DiscreetGroup*, MultipleChoices ou SingleChoices.
Chamada de Outro UID, Chamada a partir de Outro UID, Transição com Condição Y, Pré-Condições, Pós-Condições e Notas Textuais.
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;
80
• DiscreetGroup: permite a seleção de um único valor de um intervalo finito de valores;
• DiscreetGroupMultiple: [nova] permite a seleção de um ou mais valores de um intervalo finito de valores;
• MultipleChoices: permite a escolha de um ou mais elementos de um conjunto enumerável de valores;
• SingleChoice: permite a escolha de um único elemento de um conjunto enumerável de valores.
AbstractInterfaceElement
SimpleActivator ElementExhibitor VariableCapturer
PredefinedVariable IndefiniteVariable
ContinuousGroup DiscreetGroup MultipleChoices SingleChoice
CompositeInterfaceElement
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:
81
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,
82
‘nome’ e ‘artista’ de ‘Musica’, compondo uma estrutura no UID e sendo mapeado para
CompositeInterfaceElement.
4.2 Extensão 2 - Especificação dos widgets concretos MXML
Esta seção fará um estudo comparativo das premissas da Ontologia de Widgets
Abstratos com os componentes de interface MXML, sugerindo uma nova Ontologia de
Widgets Concretos específica. Os componentes MXML podem ser utilizados como
conteúdo dos atributos “mapsTo”, “blockElement”, ou “compositionTag” das classes
Ontologia de Widgets Abstratos. Os componentes MXML são classificados em duas
subclasses, os containers MXML e os controles MXML.
Os containers MXML são elementos que podem ser utilizados como invólucros de
componentes de interface, pois especificam o layout de uma interface gráfica com o
usuário. Podemos mapear os compositeInterfaceElements para este tipo de componente.
Por exemplo, uma interface pode conter 3 botões agrupados que estariam sendo
considerados como um compositeInterfaceElement por serem os únicos elementos de um
determinado estado do UID. Pode-se utilizar neste caso os containers para agrupar estes
botões na interface da maneira desejada pelo desenvolvedor / criador de interfaces. Os
containers Accordion, TabNavigator e ViewStack também podem ser aplicados como
compositeInterfaceElements que fazem o papel de exibidores de conteúdo por demanda.
Eles são compostos de outras composições e apenas uma dela é exibida por vez.
Os controls MXML são um conjunto de elementos de interface perceptíveis e
utilizáveis pelo usuário, como textos, imagens, botões, caixas de seleção de valores,
radiobuttons, e assim por diante. Serão mapeados diretamente das classes da Ontologia
83
de Widgets Abstratos, fazendo com que uma interface abstrata modelada com estas
classes possa ser traduzida em elementos MXML.
Para cada controle MXML, foi realizada uma análise comparando a descrição deste
componente com as classes da ontologia e identificado o mapeamento a ser feito. Os
componentes de análise mais complexa são os que devem ser mapeados para a classe
CompositeInterfaceElement, pois são componentes compostos de outros componentes (de
qualquer classe, ex.: DataGrid; ou serem restringidos a elementos de uma única classe, ex.:
ButtonBar).
Este mapeamento, feito de maneira comparativa entre o funcionamento do
componente e o comportamento que devem ter instâncias das classes da ontologia de
widgets abstratos, pode também ser realizado para componentes customizados, isto é,
componentes criados pelo desenvolvedor. Na grande maioria das vezes, estes novos
componentes serão mapeados da classe CompositeInterfaceElement, por conter mais de
um elemento em sua composição, mas, o desenvolvedor deve fazer esta análise para cada
componente criado, para poder utilizá-lo na descrição dos ADVs estendidos.
Suponha que o desenvolvedor crie um novo componente de seleção de valores, com
base em um conceito de usabilidade totalmente novo, mas que apenas uma das opções
será selecionada por vez pelo usuário. Este componente deve ser mapeado para a classe
“SingleChoice”, fazendo com que possa ser utilizado na descrição de sistemas futuros que
utilizem este componente. Sendo assim, a Ontologia de Widgets Concretos proposta nesta
seção deve ser sempre atualizada pelo desenvolvedor que a utiliza com seus novos
componentes.
A seguir é demonstrada a análise, que foi feita relacionando cada componente do
Flex apresentado na seção 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
84
sufixo “mx:”, indicando que fazem parte do pacote do núcleo ActionScript 3.0 do Flex. No
caso de um componente customizado, deve-se incluí-lo na ontologia utilizando o sufixo
correspondente ao pacote do desenvolvedor (ex.: novosCompos:ItemListaMusicas).
A) AbstractInterfaceElement
observações: Os elementos devem ser mapeados para subclasses desta classe.
B) SimpleActivator:
observações: Eventos externos de mouse ou teclado.
componentes mapeados:
B1) mx:Button
Tipo de ativador mais comum. Deve ser mapeado para esta classe a não ser que
se queira utilizá-lo como seletor de opções similarmente aos Radiobuttons.
Neste caso a propriedade “toggle” deve ser alterada para “true”.
B2) mx:LinkButton
Tem as mesmas características do Button mas é um componente que se
assemelha com Links HTML. Dever ser mapeado para esta classe caso se
queira uma interface visual menos carregada que a do Button, pois não possui
bordas.
C) ElementExhibitor:
observações: Exibição de conteúdo visual
componentes:
C1) mx:Image
85
Mapeamos os ElementExhibitors para mx:Image quando queremos exibir
imagens JPG, GIF e PNG, que podem ser carregadas dinamicamente ou estar
embarcadas no executável. Todos os atributos das classes navegacionais que
tenham seu domínio em imagens ou figuras serão mapeados para esta classe.
C2) mx:Label
Dever ser mapeado para esta classe quando o conteúdo do ElementExhibitor é
um texto de uma linha conhecido de antemão, por exibir apenas uma linha de
texto não editável. Geralmente é utilizado como rótulo ou título de outro elemento
de interface, mas pode exibir também conteúdo dinâmico.
C3) mx:ProgressBar
Deve ser mapeado para esta classe elementos que façam o controle de
progresso de tarefas. Como sugestão, pode ser utilizado para fazer com que o
progresso de um determinado processo de interações entre o usuário e o
sistema seja “medido” em relação às etapas deste processo. A cada etapa
cumprida, a barra de progresso avança.
Apesar desta sugestão, o componente mx:ProgressBar normalmente é utilizado
para exibir o carregamento da aplicação ou de arquivos carregados
dinamicamente no decorrer da navegação, sendo que, desta maneira, não há
mapeamento a partir das classes abstratas.
C4) mx:Text
Exibe múltiplas linhas de texto não editável. Análise análoga ao mx:Label.
C5) mx:ToopTip
Este componente é utilizado associado com outro componente. Ele exibe um
texto “popUp”quando o usuário “passa” o mouse sobre o componente pai.
86
Devem ser mapeados para esta classe elementos que sejam textos alternativos
exibidos sob demanda,
C6) mx:VideoDisplay
Devem ser mapeados para este componente os elementos da classe
ElementExhibitor são do domínio Video. Exibe vídeo no formato [.FLV]. Suporta
download progressivo via http e streaming, de arquivos e de câmeras de vídeo.
É um elemento que não tem controles de reprodução de vídeo, como “play” e
“pause”, que devem ser implementados separadamente, mapeados a partir de
SimpleActivators.
D) IndefiniteVariable:
observações: Captura de dados do teclado.
componentes mapeados:
D1) mx:TextArea
Para elementos de entrada de dados do usuário no formato de texto sejam eles
opcionais ou não e que tenham múltiplas linhas, o mapeamento dever ser feito
para este componente
D2) mx:TextInput
Similar ao TextArea mas com apenas uma única linha de texto.
87
E) ContinuousGroupMultiple:
observações: seleção de um único valor de um conjunto infinito de valores. Para
componentes proverem valores infinitos, os valores das propriedades maximum e
minimum devem ser alterados conforme o usuário troca o valor escolhido, pois a maioria
dos componentes faz a escolha do valor visualmente.
componentes mapeados:
E1) mx:HSlider / VSlider
Como é possível instanciar mais de um handle neste componente, podemos
determinar um intervalo continuo de valores se forem declarados uma dupla de
handles para representarem os valores inicial e final. Para o domínio se tornar
um conjunto infinito de valores, os valores de máximo e mínimo do componente
devem ser alterados quando o usuário usa os handles.
F) ContinuousGroup:
observações: seleção de um único valor de um conjunto infinito de valores. Para
componentes proverem valores infinitos, os valores das propriedades maximum e
minimum devem ser alterados conforme o usuário troca o valor escolhido, pois a maioria
dos componentes faz a escolha do valor visualmente.
F1) mx:HSlider / VSlider
Análogo à análise E1, mas com apenas um único handle de seleção.
F2) mx:NumericStepper
Seleção de valores numéricos.
88
G) DiscreetGroupMultiple:
observações: Seletor de discretos, valores enumeráveis.
componentes mapeados:
G1) mx:HSlider / mx:VSlider
Se for provido ao usuário uma maneira de inserir duplas de handles à linha de
seleção, podemos extrair vários intervalos discretos deste componente.
H) DiscreetGroup:
observações: Seletor de discretos, valores enumeráveis.
componentes mapeados:
H1) mx:HSlider / mx:VSlider
Se for provido ao usuário uma maneira de inserir duplas de handles à linha de
seleção, podemos extrair vários intervalos discretos deste componente.
H2) mx:NumericStepper
Seleção de valores numéricos.
I) MultipleChoices:
observações: Seletor de conjunto de valores, valores enumeráveis.
componentes mapeados:
I1) mx:HSlider / VSlider
89
Se for provido ao usuário uma maneira de inserir handles à linha de seleção,
podemos extrair vários valores discretos deste componente.
I2) mx:DateChooser
Seletor de datas em formato de calendário, este componente permite a seleção
de múltiplos dias do mês não adjacentes.
I3) mx:CheckBox
Caixa de seleção “liga/desliga”.
J) SingleChoice:
observações: Seletor de um único valor, valores enumeráveis.
componentes mapeados:
J1) mx:HSlider / VSlider
Caso seja utilizado apenas um handle neste componente.
J2) mx:DateChooser
Calendário com seleção de apenas uma data.
J3) mx:ComboBox
Lista “retrátil” com apenas uma seleção dentre um conjunto discreto de valores.
J4) mx:DateField
Campo de texto com um botão para exibição de um calendário para seleção de
uma única data.
90
J5) mx:RadioButton
Conjunto de botões “liga/desliga” no qual apenas um pode estar ligado por vez.
K) CompositeInterfaceElement:
observações: Elemento composto.
componentes mapeados:
K1) mx:ButtonBar
Composição apenas de elementos da classe Button. Deve ser utilizado quando
existe um compositeInterfaceElement composto apenas de elementos da classe
abstrata SimpleActivator. (ver LinkBar)
K2) mx:DataGrid
Lista de Elementos organizados em linhas e colunas. Seus elementos internos
podem ser construídos a partir de qualquer outro componente, o que o torna
instância da classe compositeInterfaceElement.
K3) mx:HorizontalList
Lista de Elementos organizados em uma única linha. Seus elementos internos
podem ser construídos a partir de qualquer outro componente, o que o torna
instância da classe compositeInterfaceElement.
K4) mx:LinkBar
Composição apenas de elementos da classe LinkButton. Deve ser utilizado
quando existe um compositeInterfaceElement composto apenas de elementos
da classe abstrata SimpleActivator. (ver ButtonBar)
91
K5) mx:List
Lista de Elementos organizados em uma única coluna. Seus elementos internos
podem ser construídos a partir de qualquer outro componente, o que o torna
instância da classe compositeInterfaceElement.
K6) mx:Menu
Composição de SimpleActivators, MultipleChoices e SingleChoice, um menu
pode conter elementos dos tipos “normal”, “check” e “radio” organizados em
grupos em suas folhas internas.
K7) mx:MenuBar
Composição de elementos da classe Menu que e um elemento da classe
ButtonBar que faz o controle de exibição dos menus.
K8) mx:PopUpButton
Por ser um elemento de ativação simples, mas com escolha múltipla da sua
função, este componente pode ser considerado como um elemento composto de
vários SimpleActivators.
K9) mx:RadioButtonGroup
Composição de elementos da classe RadioButton. Deve ser utilizado quando
existe um compositeInterfaceElement composto apenas de elementos da classe
abstrata SingleChoices.
K10) mx:SWFLoader
Componente que carrega outras aplicações Flex.
K11) mx:TabBar
92
É um componente ButtonBar geralmente associado com elementos de
navegação como viewstacks. O componente TabNavigator é uma associação de
um TabBar com vários viewstacks, mas com esta classe podemos criar mais de
uma TabBar para um mesmo controle de navegação.
K12) mx:TileList
Lista de Elementos dispostos em mosaico. Seus elementos internos podem ser
construídos a partir de qualquer outro componente, o que o torna instância da
classe compositeInterfaceElement.
K13) mx:ToggleButtonBar
Composição apenas de elementos da classe Button com a propriedade
“toggle=true”. Deve ser utilizado quando existe um compositeInterfaceElement
composto apenas de elementos da classe abstrata SingleChoice.
K14) mx:Tree
Lista de Elementos dispostos em estrutura hierárquica em árvore, como em um
gerenciador de arquivos. É composto de composições ícone-texto, que podem
ser galhos ou folhas da árvore.
- ~ -
Com esta análise completa, podemos definir as regras consistência de mapeamento
das classes de widgets abstratos para os componentes MXML que comporão a nova
Ontologia de Widgets Concretos.
A listagem completa das regras de consistência se encontra nos anexos. A Figura
4.5 nos mostra as classes da ontologia de widgets abstratos com os componentes MXML
relacionados.
93
ContinuousGroup DiscreetGroup MultipleChoices SingleChoiceContinuousGroupMultiple DiscreetGroupMultiple
AbstractInterfaceElement
DateChooser
ComboBox
ColorPicker
CheckBox DateField
RadioButton
CompositeInterfaceElement
AdvancedDataGrid
ButtonBar
DataGrid
HorizontalList
LinkBar
List
Menu
MenuBar
PopUpButton
PopUpMenuButton
RadioButtonGroup
SWFLoader
TabBar
TileList
ToggleButtonBar
PredefinedVariableIndefiniteVariable
TextArea
TextInput
SimpleActivator ElementExhibitor VariableCapturer
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.
94
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(escutar programa)
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”:
95
AbstractInteface
SimpleActivator
ElementExibitor
IndefiniteVariable
ContinuousGroup
DiscreetGroup
MultipleChoices
SingleChoice
CompositeInterfaceElement
Multiple
ContinuousGroup
Multiple
DiscreetGroup
A
C
?
N
{N}
1
@
[1]
[N]
{1}
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 view states no
96
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 de
classes ‘emContexto’
ADVs Especiais
ADVs Opcionais
índice
índice
índice
Projeto deNavegação
Projeto deInterface Abstrata
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
97
Figura 4.9.a. O mapeamento abstrato é representado pelo símbolo no campo abaixo
do nome do ADV e o mapeamento concreto pelo nome do componente MXML ao lado.
No caso, o “ADV Programa de Rádio” foi mapeado a partir da classe navegacional
“Programa de Rádio”, portanto deve ser do tipo “compositeinterfaceElement” e é
considerado um ADV Primário. Os atributos “nome, data e tempo” foram mapeados para a
classe abstrata “ElementExhibitor” e então para o componente mx:Label compondo ADVs
opcionais assim como o restante dos ADVs internos. A
Figura 4.9.b mostra o ADV secundário correspondente ao contexto Programa de
Rádio por Data, com um calendário para seleção de outro programa neste contexto e
botões de avanço e retrocesso dentro do contexto.
(a) (b)
ADV musicas
C mx:VBox
ADV Programa de Rádio
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
98
4.4 Extensão 4 - Especificação de view states do Flex
Como os view states são organizados de maneira hierárquica, a organização dos
ADVs em Primários, secundários e opcionais nos permite um mapeamento direto para os
view states do Flex.
A criação de uma interface em um ambiente de programação ActionScript é
realizada através de uma estrutura de dados que representa uma lista de
objetos perceptíveis, chamada de DisplayList. Se algum objeto está
presente na interface de exibição ao usuário, então ele está registrado
nesta lista, de forma que um objeto instanciado do sistema que não foi
adicionado à DisplayList, ou que foi retirado da mesma, é um objeto que
apenas não tem interface visual sendo exibida, mas continua ativo.
(MOOCK, 2007)
Fazendo um paralelo com o OOHDM, no método OOHDM existe a variável
“contextoPerceptivo”, uma variável de contexto que tem a mesma função da DisplayList:
“Uma variável reservada, “contextoPerceptivo”, é usada para indicar
modificações no espaço perceptivo (o conjunto de objetos perceptíveis em
dado momento). Quando se deseja tornar um objeto perceptível, ele é
acrescentado ao “contextoPerceptivo”. Os elementos retirados deste
contexto deixam de ser percebidos.” (SCHWABE ROSSI, 1996).
Uma aplicação Flex pode utilizar destes conceitos fazendo inserções e retiradas de
objetos da DisplayList e também alterações nas propriedades e estilos destes objetos de
acordo com alterações de estados de interface. Podemos implementar os mx:Statede
acordo com os ADVs. A partir de um ADV primário, é implementado o ‘base state’ do
componente que representa esta classe. Os ADVs secundários, são implementados como
99
estados ‘filhos’ do ‘base state’. Os estados secundários podem também ter mais de um
estado de interface, que continuam sendo considerados “secundários”.
Os mx:State compreendem não só estados de interface relativos a uma aplicação ou
ADV, mas também a de um simples componente ou estado de um ADV, extraídos dos
ADVs opcionais. No exemplo de modelagem, o atributo “som” foi mapeado para um
elemento mx:Button, pois será um botão que aciona a exibição do programa de rádio
determinado. Suponha que o botão possa estar desabilitado quando é exatamente o
progrma de rádio que está sendo pesquisado o que está sendo exibido, então, este botão
será um componente com dois estados, um ‘ativo’ e um ‘inativo’. No estado ‘ativo’, o botão
seria da cor verde com o texto “OUVIR”, e no inativo da cor vermelha com o texto “NO AR”.
Este componente poderia ser implementado utilizando mx:State para definir os diferentes
estados da interface. Seu view state poderia ser definido pela aplicação, assim, se este
botão estiver presente em mais de um view state da aplicação, seu estado será mantido
quando da troca de view state ocorrer.
Este modelo de implementação permite a descrição de elementos da interface, desde
os mais primitivos aos mais complexos, provendo recursos para especificação de cada um
dos elementos de maneira independente, relacionando os eventos que ocorrem entre um e
outro.
Os aspectos dinâmicos da interface lidam tanto com transformações de
interface dentro de um ADV como com transformações de interface
envolvendo navegação. Em ambos os casos, a natureza orientada a
eventos dos ADVs e o poder expressivo de seu modelo de transição de
estados permite a implementação destas transformações em um estilo
simples, de baixo para cima. Começando-se com ADVs de mais baixo
nível, definimos “scripts” para cada evento significativo com que o objeto
pode lidar. (ROSSI, 1996).
100
Esta afirmação é válida também para a implementação dos mx:States, que podem
ser realizados em vários níveis desde cada objeto até a aplicação como um todo.
Aprimorando o exemplo de modelagem de aplicação, será apresentado agora parte
do diagrama de classes navegacionais, o diagrama de ADVs, e o código MXML
correspondente que fazem parte do exemplo de como realizar o mapeamento para os view
states.
C mx:Panel
data
1
anterior
mx:LinkButton@
mx:LinkButton
ADV Primário
ADVs Secundários
ADV Programa de Rádio
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
ADV Programa de Rádio por Data
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
101
Rádio, de maneira que ele seja o base state do componente MXML escolhido para
representa-lo. No exemplo foi escolhido o componente mx:Panel portanto a definição crua
deste componente em MXML que está declarado no arquivo UIProgramaRadio.mxml é:
1 <mx:Panel xmlns:mx="http://www.adobe.com/2006/mxml"> 2 </mx:Panel>
Cada elemento interno do ADV Programa de Rádio é implementado no base state
de acordo com o mapeamento, resultando em:
1 <mx:Panel xmlns:mx="http://www.adobe.com/2006/mxml">
2
3 <mx:Label id="nome_lbl" text="Nome" />
4 <mx:Label id="data_lbl" text="Data"/>
5 <mx:Label id="tempo_lbl" text="Tempo"/>
6 <mx:LinkButton id="dj_lbtn" label="DJ"/>
7 <mx:Button id="som_btn" label="Som"/>
8 <mx:TileList id="musicas_tl" itemRenderer="itemListaMusicas"/>
9
10 <mx:Panel>
Em seguida podemos definir os outros view states mapeando cada ADV Secundário
para um mx:State como no exemplo a seguir:
1 <mx:Panel xmlns:mx="http://www.adobe.com/2006/mxml">
2
3 <!-- Declaração da variável states,
4 que indica que este mx:Panel terá mais de um estado -->
5 <mx:states>
6
7 <!--Declaração do primeiro estado: Programa de Rádio por Data-->
8 <mx:State name="porData">
9 <mx:AddChild position="lastChild">
10 <mx:DateChooser id="calendario"/>
11 </mx:AddChild>
12 <mx:AddChild position="lastChild">
13 <mx:LinkButton label="anterior"/>
14 </mx:AddChild>
15 <mx:AddChild position="lastChild">
16 <mx:LinkButton label="próximo"/>
17 </mx:AddChild>
18 </mx:State>
19
20 <!--Declaração do segundo estado: Programa de Rádio por Nome-->
21 <mx:State name="porNome">
22 <mx:AddChild position="lastChild">
23 <mx:LinkButton label="anterior"/>
24 </mx:AddChild>
25 <mx:AddChild position="lastChild">
102
26 <mx:LinkButton label="próximo"/>
27 </mx:AddChild>
28
29 <!--Declaração do terceiro estado: Programa de Rádio por DJ-->
30 <mx:State name="porDJ">
31 <mx:AddChild position="lastChild">
32 <mx:Image/>
33 </mx:AddChild>
34 <mx:AddChild position="lastChild">
35 <mx:LinkButton label="anterior"/>
36 </mx:AddChild>
37 <mx:AddChild position="lastChild">
38 <mx:LinkButton label="próximo"/>
39 </mx:AddChild>
40 </mx:State>
41 </mx:states>
42
43 <!--Declaração do “base state”: Programa de Rádio-->
44
45 <mx:Label id="nome_lbl" text="Nome" />
46 <mx:Label id="data_lbl" text="Data"/>
47 <mx:Label id="tempo_lbl" text="Tempo"/>
48 <mx:LinkButton id="dj_lbtn" label="DJ"/>
49 <mx:Button id="som_btn" label="Som"/>
50
51 <mx:TileList id="musicas_tl" itemRenderer="itemListaMusicas"/>
52
53 </mx:Panel>
Com a interface definida são determinados os valores dos atributos dos
componentes baseados nos atributos dos objetos navegacionais os quais devem ser
implementados naturalmente como classes ActionScript. São também atribuídos os eventos
aos componentes, por exemplo determinando o método a ser chamado caso o usuário
aperte o botão do mouse sobre o componente. A troca de estado é feita através da
mudança da variável pública currentState:String e deve ser realizada antes que se
referencie os objetos adicionados a displayList.
A seguir são sugeridas algumas dicas e de modelagem de ADVs e uso do MXML
1. Alguns dos componentes são classificados como “navegadores”, pois realizam a
tarefa de exibir conteúdo sob demanda como comentado ao final da seção 3.1.3. São
eles:
• Accordion
• TabNavigator
103
• ViewStacks
Em uma composição de ADVs agrupados em “XOR”, ou seja, que representam
estados exclusivos da interface e não são percebidos simultaneamente pelo usuário, o
ADV que representa a classe compositeInterfaceElement que é pai destes ADVs em
“XOR” pode ser mapeada para os componentes acima.
Como exemplo, O “ADV Programa de rádio” do contexto “Programa de Rádio por
DJ” pode conter além do “ADV Musicas” que é uma lista de músicas que fazem parte
daquele programa de rádio, uma lista de outros programas daquele determinado DJ que
criou o programa que está sendo exibido. Estes dois ADVs, o “ADV Musicas” e o “ADV
Programas do DJ” podem ser ADVs que compõe um ADV pai chamado de “ADV
Informações” que é mapeado para um dos componentes sugeridos, em vez de se criar
view states para cada situação (um mostrando as músicas e outro os programas do DJ).
2. A maioria dos componentes MXML (todos que sejam instâncias da classe
mx:UIComponent) tem as propriedades visible e enabled, podendo ser estas
utilizadas em vez de se criar view states para o determinado componente. Desta
maneira, podemos fazer o controle de visibilidade do componente ou da capacidade
de ativação pelo usuário sem que haja a necessidade de trocar de view state, sendo
que sua criação deve se reavaliada dependendo da complexidade da alteração da
interface.
3. Elementos que são do tipo compositeInterfaceElement que tem a propriedade
“isRepeated = verdadeiro” são elementos que repetem um deteminado conjunto de
dados de acordo com uma regra de exibição de elementos. Eles podem ser
mapeados para os componentes que representam listas de itens. Estes controles
permitem ao usuário da aplicação “rolar” a lista de itens e selecionar um ou mais
itens desta lista. Todos os componentes de lista do Flex são especializaçõoes da
104
classe mx:ListBase, incluindo mx:DataGrid, mx:HorizontalList, mx:List, mx:Menu,
mx:TileList, e mx:Tree.
No exemplo do Programa de Rádio, a lista de músicas pode ser uma lista ordinária
com linhas e colunas, ou pode ter um layout totalmente diferente, de acordo com a
linguagem do site ou sistema que está sendo implementado. Os componentes do tipo
lista do Flex utilizam uma classe propriedade chamada itemRenderer que aponta
para o componente que fará a composição visual do elemento da lista. Este
componente será o valor da propriedade compositionTag da ontologia de widgets
abstratos
4. As classes mx:Alert e mx:PopupManager são classes que permitem a exibição de
janelas independentes. O primeiro é uma janela modal geralmente utilizada para
exibir mensagens ao usuário e obter confirmações do mesmo. O segundo pode
carregar em uma janela separada qualquer aplicação ou componente Flex. A
definição original dos ADVs considera a modelagem de interfaces do tipo pop-up,
então, quando forem descritas interfaces deste tipo, podemos mapear o ADV para
estas classes.
5. As transições MXML são eventos relacionados a efeitos de mudanças de
propriedades, como dimensões, canal alpha, efeitos visuais e visibilidade. As
trasições são indicadas para cada objeto e na mudança de um view state para outro
são consideradas, realizando os passos indicados em ordem. Por exemplo, podemos
fazer uma mudança de view state na qual um componente sai da tela com uma
animação para a esquerda, e outro aparece esmaecendo em seguida. As transições
podem ser indicadas nos diagramas de ADVs entre um estado e outro de um
determinado ADV, ou entre ADVs secundários, quando há troca de contexto
navegacional.
105
5 Modelagem de Aplicação OOHDM – Flex
A aplicação de exemplo utilizada neste trabalho é um conjunto de pequenas aplicações
desenvolvidas para um artista gráfico. Este artista é produtor de desenhos que são
estampados em camisetas, e o sistema é uma loja na qual o usuário pode montar sua
própria camiseta de acordo com modelos, estampas e cores diferentes. Juntamente com
esta loja de camisetas, existe uma loja de produtos comuns (tradicional), que não
necessitam de personalização com a camiseta. Também há uma rádio virtual, na qual
acontecem programas ao vivo semanalmente, que será automaticamente exibido quando o
usuário adentra no sistema. Além da rádio ao vivo, o usuário tem a opção de fazer uma
pesquisa nos programas de rádio que foram exibidos anteriormente, obtendo informações
sobre o programa de rádio e o DJ que criou este programa.
Na primeira iteração, foi extraído o conjunto geral de informações do domínio,
procurando atingir todos os pontos do sistema. Foram conceitualizados a maioria dos
requisitos, porém a partir da etapa de projeto navegacional, apenas os objetos relacionados
à Rádio on-line foram contempladas.
Na segunda iteração foi aprimorado o modelo relativo à Rádio on-line e modelada a loja
comum. Esta base da loja será utilizada no sistema de camisetas pela herança da classe
“camisetaPersonalizada” em relação a “produto”.
A terceira iteração é a sugestão de modelagem do sistema de montagem de camisetas.
106
ITERAÇÃO 1
ANALISE DE REQUISITOS
O conjunto completo de casos de uso gerados nesta fase está no Anexo 8.1.
Caso de Uso: Pesquisar a radio Atores: usuário, sistema Tipo: Descrição: O usuário escolhe pesquisar os programas de rádio da emissora. O sistema exibe uma lista de programas de rádio, exibindo o nome a data e o nome do DJ. O usuário pode escutar um dos programas, ou ver os detalhes de um dos programas. Se for escolhido ver os detalhes, o sistema exibe o programa de rádio, mostrando o nome, a data de exibição, o tempo total do programa, o nome do DJ que criou este programa a lista de musicas que fazem parte deste programa, incluindo o nome da música e o nome do intérprete. O usuário pode escolher escutar o programa corrente ou ver os detalhes do DJ em questão.
UID: Pesquisar a rádio
... (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>
107
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
nome: Stringdata: Stringtempo: Stringsom: AudioNomeDJ: nomeDJ de DJ por Programa
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
108
proximo: anchor(programa por DATA)anterior: anchor(programa por DATA)
fotoDJ: foto de DJidxProgramas: 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
nome: Stringdata: Stringtempo: Stringsom: AudioNomeDJ: nomeDJ de DJ por Programa
Programa de Rádio por DJPrograma de Rádio por DATA Programa de Rádio por NOME
PROJETO DE INTERFACE ABSTRATA
ADV Programa de Rádio
nome
mx:Label
C mx:Panel
data
mx:Label
tempo
mx:Label
nomeDJ
mx:LinkButton@
som
@ mx:Button
ADV Programa de Rádio por Data
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
109
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
Data
mx: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
110
6 Considerações Finais
Neste trabalho o método OOHDM foi adaptado para ser utilizado na publicação de
aplicações construídas no ambiente Flex. Quando da análise do método, a característica
em comum mais evidente na relação entre OOHDM e Flex foi a criação de interfaces com o
usuário, de maneira que se estabeleceu o paralelo entre o Projeto de Interfaces Abstratas
do OOHDM e os view states do Flex.
A utilização das extensões propostas neste trabalho faz com que o projeto da interface
com o usuário seja feito de acordo com as capacidades e características dos componentes
MXML. A partir das ontologias de widgets de interface foi possível criar elementos de
projeto que funcionam como estruturas para realizar o mapeamento direto do projeto de
interface abstrata para a implementação do sistema, extraindo dos ADVs estendidos para
Flex informações para a construção do código MXML que compõe parte da estrutura de
uma aplicação Flex.
Perante a enorme quantidade de sistemas sendo construídos na atualidade, a
utilização de um método para a construção de sistemas implementados para a internet se
faz cada vez mais importante e presente. O Projeto de Navegação, a reusabilidade de
componentes e objetos conceituais, a rastreabilidade entre os elementos abstratos de
projeto e os concretos de implementação e a capacidade de gerir grandes quantidades de
dados fazem do método OOHDM um expoente no campo dos estudos de sistemas
hipermídia.
Atualmente o Flex é considerado um dos ambientes mais completos para o
desenvolvimento de aplicações hipermídia. Isso se deve pela sua integração com o Flash
para publicação de conteúdo interativo com interfaces gráficas avançadas, por sua
integração com serviços web através de “server-side scripts” e por ser publicado em uma
máquina virtual (Flash Player) multi-plataforma.
111
A integração destas duas esferas - OOHDM e Flex- provê recursos para a construção
de sistemas hipermídia os quais tem poderosos aliados para a exibição de conteúdo para o
usuário, o Flex e o Flash. O Flex implementa a interface com o usuário, o controle da lógica
do sistema, o acesso ao sistema de informações, as requisições HTTP; enquanto o Flash
gera gráficos e componentes de programação inovadores no que diz respeito a usabilidade
e apresentação visual. Com as descrições providas pelo método OOHDM, a construção de
sistemas hipermídia em Flex se torna organizada e claramente descrita.
Apesar deste trabalho ter seu enfoque em aplicações feitas em Flex, as extensões
sugeridas (principalmente as extensões 1, 2 e 3) podem ser aplicadas em outras linguagens
de programação. Neste caso, os elementos descritos nos ADVs podem se manter
expandidos, contendo a informação da classe de widget abstrata da qual ele foi mapeado,
como proposto neste trabalho, mas em vez de componentes MXML o campo de
mapeamento concreto deve conter os componentes ou objetos da nova linguagem utilizada.
Na construção do estudo de caso foram constatadas algumas deficiências em relação à
integração das etapas do OOHDM quando se buscava a modelagem do sistema para a
implementação em Flex, problemas os quais as extensões 1 e 3 propostas neste trabalho
tentam resolver. Também foram encontrados modelos de implementação em Flex (os view
states) que não tinham correspondência direta com alguma primitiva do OOHDM, sendo
necessária a construção de um modelo abstrato hierárquico dos ADVs para suportar este
modelo.
Devido ao fato de a aplicação modelada no estudo de caso ser de pequenas
proporções no que diz respeito ao número de classes navegacionais, não se fez necessária
a utilização dos cartões de navegação (OOHDM) e mesmo assim não se perdeu informação
para a construção do sistema. Apesar disso, as extensões propostas não excluem os
cartões de navegação e estes podem ser utilizados sempre que o volume de classes
navegacionais no sistema não for facilmente gerenciável.
112
Trabalhos Futuros
A seguir são enumerados alguns trabalhos futuros
• Implementação das classes OOHDM em ActionScript para construção de uma
ferramenta de geração automática de interfaces concretas similar à ferramenta
idealizada por Sabrina Moura (MOURA,2004). Neste trabalho, a obtenção de
dados das classes navegacionais persistidas no banco de dados seria feita
através de comandos OOHDM quando da requisição HTTP da aplicação, o que
geraria uma compilação on-the-fly que construiria a interface de acordo com
dados dinâmicos.
• Utilização das extensões propostas no desenvolvimento de outras aplicações,
para efeitos de validação. Estas aplicações deveriam incluir diversos tipos de
widgets de interface, a fim de experimentar ao máximo os recursos do método
OOHDM adaptado.
• Continuação do desenvolvimento dos ADVs Flex para que contenham
informações de transições entre os view states (mx:Transitions), ativações de
UIs (e outras características relevantes à implementação em Flex.
113
7 Bibliografia
COENRAETS, C. An overview of MXML: The Flex markup language. Adobe - Developer
Center. 2003. disponível em <http://www.adobe.com/devnet/flex/articles/paradigm.html> Acesso em: 03 Abr. 2008.
GARZOTTO, F. ; SCHWABE, D. ; PAOLINI, P. . HDM - A Model Based Approach To Hypermedia Application Design. ACM Transactions on Information Systems, New York, EUA, v. 11, n. 1, p. 1-26, 1993.
GAY, J. Macromedia - Showcase: History of Flash. 2008. disponível em <http://www.adobe.com/macromedia/events/john_gay>. Acesso em: 18 abr. 2008.
KOCH, N. A Comparative Study of Methods for Hypermedia Development. Universidade Ludwig-Maximilians de Munique, Alemanha, 1999.
LIMA, F; SCHWABE, D. Application Modeling for the Semantic Web. Puc-Rio, Brasil, 2003.
MOOCK, C. Essencial ActionScript 3.0. Sebastopol, CA, EUA:O’Reilly, 2007.
MOURA, S. Desenvolvimento de Interfaces Governadas por Ontologias para web Semântica. PUC-Rio, Brasil, 2004.
REMÁCULO, L. R. Personalização de Diagramas de Interação do Usuário e Mapeamento para a Ontologia de Widgets Abstratos, Trabalho de conclusão de curso, UFSC, Brasil, 2005 ROSSI, G. Um método orientado a objetos para o projeto de aplicações hipermídia. Tese de Doutorado, Puc-Rio, Brasil, 1996
SCHWABE, D. OOHDM Wiki :: Summary of OOHDM. 2005 disponível em <http://www.tecweb.inf.puc-rio.br/oohdm/space/summary+of+OOHDM>. Acesso em: 25 mar. 2008. SCHWABE, D.; ROSSI, G. V. . An Object Oriented Approach To Web-Based Application Design. Theory and Practice of Object Systems, New York, v. 4, n. 4, p. 207-225, 1998.
VILAIN, P. Modelagem da Interação com o Usuário em Aplicações Hipermídia. Tese de Doutorado. PUC-Rio, Brasil, 2002. VILAIN, P.; SCHWABE, D.; de SOUZA, C.S. A Diagrammatic Tool for Representing User Interaction in UML Puc-Rio, 2000. ADOBE. Adobe - Flex 3 - Overview. 2008a. disponível em <http://www.adobe.com/products/flex/overview/> . Acesso em: 15 mai. 2008.
114
ADOBE. Adobe – Flash Player: PC Penetration. 2008b. disponível em <http://www.adobe.com/products/player_census/flashplayer/PC.html/> . Acesso em: 5 jun. 2008.
Flash Magazine1 > News. Flash Magazine. 2000. disponível em <http://www.flashmagazine.com/news/detail/the_flash_history/> . Acesso em: 20 mar. 2008.
115
8 Anexos
8.1 Casos de uso da aplicação de exemplo Caso de Uso: Montar camiseta Atores: Comprador Tipo: Descrição: Um comprador (usuário cadastrado) escolhe a opção de montar uma nova camiseta. Ele escolhe a cor, a estampa, dentre as que podem ser aplicadas nesta cor, e as cores que podem ser aplicadas nesta estampa nesta cor de camiseta. Com a camiseta montada ele tem a opção de armazenar esta camiseta montada, adicioná-la ao carrinho de compras, começar novamente a montagem de uma nova camiseta ou voltar à vitrine. Caso de Uso: Escolher camiseta da vitrine Atores: Comprador Tipo: Descrição: Um comprador (usuário) percorre por uma galeria de camisetas previamente montadas pelo VIME (vitrine) e pode, selecionando uma delas, ou ser direcionado para o sistema de montagens de camisetas com esta camiseta carregada para ser modificada ou enviá-la para o carrinho de compras. Caso de Uso: Escolher produto da loja simples Atores: Comprador Tipo: Descrição: Um comprador percorre a lista da loja de produtos simples (que não requerem personalização como DVDs e Carteiras) e pode escolher quais quer adicionar ao carrinho de compras. O comprador pode selecionar um dos produtos e ver seus detalhes. Quando visualizando os detalhes de algum produto, aparecerá uma lista de produtos relacionados, que o comprador pode enviar diretamente para o carrinho de compras ou ver seus detalhes Caso de Uso: Comprar Camisetas e outros produtos (utilizar carrinho de compras). Atores: Comprador, Vime Tipo: Descrição: Um comprador (usuário cadastrado) após ter montado uma ou mais camisetas decide por comprá-las. Ele seleciona dentre as camisetas enviadas ao carrinho de compras as que quer comprar efetivamente, as quantidades de cada tamanho para cada camiseta que deseja, a quantidade dos produtos comuns. O sistema atualiza as informações de quantidade e preço ao passo que o usuário define novos e passa para o passo seguinte, a confirmação do pedido. Com o pedido e preço total revisado e confirmado, ele escolhe uma dentre as formas de pagamento e passa para o seguinte passo, a inserção de dados (endereço de entrega, numero do cartão) para ser gerado o pedido. Com o pedido gerado o comprador passa então para o passo de recebimento de um comprovante de pedido. A partir daqui o comprador pode escohler continuar navegando no VIME ou comprar mais camisetas. O VIME recebe o pedido e dá entrada ao processo de confecção física das camisetas para o envio, e depois de confirmado com o fornecedor, envia um email de confirmação do prazo de entrega das camisetas.
116
Caso de Uso: Escutar rádio (é um use case?) Atores: Comprador Tipo: Descrição: Enquanto usa o sistema, o comprador estará escutando musicas ao durante duas horas a cada duas semanas em um programa ao vivo. Fora deste horário, o programa a ser exibido será o último realizado. Caso de Uso: Pesquisar a radio Atores: usuário, sistema Tipo: Descrição: O usuário escolhe pesquisar os programas de rádio da emissora. O sistema exibe uma lista de programas de rádio, exibindo o nome a data e o nome do DJ. O usuário pode escutar um dos programas, ou ver os detalhes de um dos programas. Se for escolhido ver os detalhes, o sistema exibe o programa de rádio, mostrando o nome, a data de exibição, o tempo total do programa, o nome do DJ que criou este programa a lista de musicas que fazem parte deste programa, incluindo o nome da música e o nome do intérprete. O usuário pode escolher escutar o programa corrente ou ver os detalhes do DJ em questão. Caso de Uso: Ver galeria de fotos/video Atores: Comprador Tipo: Descrição: O comprador pode ver fotos e videos procurando em uma galeria visual através de miniaturas dos mesmos e então obter mais informações selecionando um deles. Nestas informações estão incluidos o conteúdo original, e dados extras como autor, descição, data e links externos. Caso de Uso: Fazer Cadastro de Usuario Atores: Usuário comum Tipo: Descrição: O usuário quer fazer seu registro no sistema e fornece dados cadastrais. a partir deste ponto, o usuário recebe status de comprador e pode fazer o checkout no sistema de montagem de camisetas. (mail de confirmação?) Caso de Uso: Fazer conexão (login) Atores: Usuário comum Tipo: Descrição: O usuário entra com seu email e senha previamente cadastrados e habita a navegação do comprador (pode utilizar o carrinho de compras, etc). Caso de Uso: inserir novas camisetas Atores: administrador Tipo: Descrição: O administrador seleciona a camiseta a ser inserida no sistema e fornece a informação da cor desta camiseta. A partir da cor da camiseta, será possível escolher um determinado conjunto de cores para as estampas.
117
Caso de Uso: inserir novas estampas Atores: administrador Tipo: Descrição: O administrador seleciona a estampa a ser inserida no sistema e fornece a informação de quantas cores tem a estampa e as cores iniciais. O sistema então exibe todas as camisetas cadastradas no sistema e o administrador seleciona quais camisetas poderão receber a estampa a ser inserida. Caso de Uso: inserir novos produtos simples Atores: administrador Tipo: Descrição: O administrador seleciona a imagem do produto, e insere os dados e descrição, preço do produto. Caso de Uso: administrar usuários Atores: administrador Tipo: Descrição: O administrador pode inserir, editar dados cadastrais e apagar usuários do sistema. Os dados de cartão de crédito devem ser criptografados. Caso de Uso: administrar rádio Atores: administrador Tipo: Descrição: O administrador faz o upload do programa de radio (arquivo de som) e preenche informações das musicas e do dj em questão.
118
8.2 Diagrama de UIDs para a aplicação de exemplo D
iagr
ana
de U
IDs
UID
Faz
er L
ogi
n
opçõ
es d
o si
stem
a
Pes
quis
ar R
ádi
o
usar
loja
com
um
ver
carr
inh
o d
e co
mpr
as
ver
deta
lhes
Pro
gram
a d
e R
ádi
o
mon
tar
cam
ise
tas
ver
vitr
ine
ver
gale
ria
mul
timíd
ia
faze
r ca
das
tro
ver
det
alhe
s ca
mis
eta
ver
det
alh
es
prod
uto
ver
deta
lhes
DJ
opç
ões
de
adm
inis
tra
ção
pesq
uis
ar c
ompr
as
adm
inis
trar
usu
ário
s
adm
inis
trar
rád
io
adm
inis
tra
r ca
mis
eta
s
adm
inis
trar
ga
leria
m
ultim
ídia
inse
rir/
apag
ar/
edita
r p
rogr
ama
de r
ádio
adm
inis
trar
loja
inse
rir/
apa
gar
/ed
itar
mod
elo
inse
rir/
apa
gar/
edi
tar
esta
mpa
adm
inis
tra
r vi
trin
e
inse
rir/
apa
gar/
edi
tar
usuá
rio
inse
rir/
apag
ar/e
dita
r pr
ogra
ma
de
rád
io
inse
rir/
apag
ar/e
dita
r us
uári
o
119
120
8.3 Diagrama de Classes conceituais da aplicação de exemplo
Pro
duto
Pro
duto
Co
mu
m
Usu
ário
Ad
min
istr
ado
r
DJ
Mú
sica
Pro
gra
ma
de
Rá
dio
Inté
rpre
te
Art
ista
Grá
fico
Est
amp
a
Co
r T
inta
Co
r
Cor
Tec
ido
Mod
elo
Pla
ylis
t
0..*
0..*
0..*
0..*
0..*
0..*
0..*
0..*
1..*
1..*
1 1
1
1
1..4
1
1
cria
exec
uta
dapo
r
con
tém
cria
é ti
ngi
dod
e
rela
cion
a c
om
cont
ém
con
tém
tipo
imag
empr
eço
núm
ero
com
erci
al
dese
nho
núm
ero
de
core
sco
res
padr
ão
cate
gor
ia d
e p
reço
núm
ero
CM
YK
nom
eva
lor
RG
B
desc
rição
hom
epa
gefo
tono
me
sobr
eno
me
ema
ilse
nha
perf
ilfo
to
nom
eda
tate
mpo
som
nom
e
ord
em
nom
e
nom
epr
eço
desc
rição
esto
que
foto
Dia
gram
a de
Cla
sses
Con
ceitu
ais
Co
mp
rad
orC
ompr
aC
amis
eta
Per
son
aliz
ada
0..*
0..*
0..*
1..*
mon
ta1
..*1
0..1
cont
ém
faz
incl
úi
cód
igo
tipo
cpf/c
npj
rg sexo
data
nas
cim
ent
oen
der
eço
CE
Pci
dad
ees
tad
opa
íste
lefo
ne
data
valo
r To
tal
121
8.4 Regras de consistência Ontologia de Widgets Concretos estendida
:SimpleActivator
a owl:Class;
rdfs:subClassOf awo:AbstractInterfaceElement;
rdfs:subClassOf
[a owl restriction;
owl:allValuesFrom
[a owl:Class;
owl:oneOf (cwo:Button cwo:LinkButton)
];
owl:onProperty awo: MapsTo
].
cwo:Button
a cwo:ConcreteInterfaceElement.
cwo:LinkButton
a cwo:ConcreteInterfaceElement.
//------------------------------------------------------------------------
:ElementExhibitor
a owl:Class;
rdfs:subClassOf awo:AbstractInterfaceElement;
rdfs:subClassOf
[a owl restriction;
owl:allValuesFrom
[a owl:Class;
owl:oneOf (cwo:Image cwo:Label cwo:Progressbar
cwo:Text cwo: ToolTip cwo:VideoDisplay)
];
owl:onProperty awo: MapsTo
].
cwo:Image
a cwo:ConcreteInterfaceElement.
cwo:Label
a cwo:ConcreteInterfaceElement.
cwo:ProgressBar
a cwo:ConcreteInterfaceElement.
cwo:Text
a cwo:ConcreteInterfaceElement.
cwo:ToolTip
a cwo:ConcreteInterfaceElement.
cwo:videoDisplay
a cwo:ConcreteInterfaceElement.
//------------------------------------------------------------------------
:IndefiniteVariable
122
a owl:Class;
rdfs:subClassOf awo:VariableCapturer;
rdfs:subClassOf
[a owl restriction;
owl:allValuesFrom
[a owl:Class;
owl:oneOf (cwo:TextArea cwo:TextInput)
];
owl:onProperty awo: MapsTo
].
cwo:TextArea
a cwo:ConcreteInterfaceElement.
cwo:TextInput
a cwo:ConcreteInterfaceElement.
//------------------------------------------------------------------------
:ContinuousGroupMultiple
a owl:Class;
rdfs:subClassOf awo:Predefinedvariable;
rdfs:subClassOf
[a owl restriction;
owl:allValuesFrom
[a owl:Class;
owl:oneOf (cwo:HSlider cwo:VSlider)
];
owl:onProperty awo: MapsTo
].
cwo:Hslider
a cwo:ConcreteInterfaceElement.
cwo:VSlider
a cwo:ConcreteInterfaceElement.
//------------------------------------------------------------------------
:ContinuousGroup
a owl:Class;
rdfs:subClassOf awo:Predefinedvariable;
rdfs:subClassOf
[a owl restriction;
owl:allValuesFrom
[a owl:Class;
owl:oneOf (cwo:HSlider cwo:VSlider cwo:NumericStepper)
];
owl:onProperty awo: MapsTo
].
cwo:Hslider
a cwo:ConcreteInterfaceElement.
cwo:VSlider
a cwo:ConcreteInterfaceElement.
cwo:NumericStepper
a cwo:ConcreteInterfaceElement.
//------------------------------------------------------------------------
123
:DiscreetGroupMultiple
a owl:Class;
rdfs:subClassOf awo:Predefinedvariable;
rdfs:subClassOf
[a owl restriction;
owl:allValuesFrom
[a owl:Class;
owl:oneOf (cwo:HSlider cwo:VSlider)
];
owl:onProperty awo: MapsTo
].
cwo:Hslider
a cwo:ConcreteInterfaceElement.
cwo:VSlider
a cwo:ConcreteInterfaceElement.
//------------------------------------------------------------------------
:DiscreetGroup
a owl:Class;
rdfs:subClassOf awo:Predefinedvariable;
rdfs:subClassOf
[a owl restriction;
owl:allValuesFrom
[a owl:Class;
owl:oneOf (cwo:HSlider cwo:VSlider cwo:DateChooser)
];
owl:onProperty awo: MapsTo
].
cwo:Hslider
a cwo:ConcreteInterfaceElement.
cwo:VSlider
a cwo:ConcreteInterfaceElement.
cwo:NumericStepper
a cwo:ConcreteInterfaceElement.
//------------------------------------------------------------------------
:MultipleChoices
a owl:Class;
rdfs:subClassOf awo:Predefinedvariable;
rdfs:subClassOf
[a owl restriction;
owl:allValuesFrom
[a owl:Class;
owl:oneOf (cwo:HSlider cwo:VSlider
cwo:DateChooser cwo:CheckBox)
];
owl:onProperty awo: MapsTo
].
cwo:Hslider
a cwo:ConcreteInterfaceElement.
cwo:VSlider
124
a cwo:ConcreteInterfaceElement.
cwo:Datechooser
a cwo:ConcreteInterfaceElement.
cwo:CheckBox
a cwo:ConcreteInterfaceElement.
//------------------------------------------------------------------------
:SingleChoice
a owl:Class;
rdfs:subClassOf awo:Predefinedvariable;
rdfs:subClassOf
[a owl restriction;
owl:allValuesFrom
[a owl:Class;
owl:oneOf (cwo:HSlider cwo:VSlider cwo:DateChooser
cwo:ComboBoxcwo:DateField cwo:NumericStepper
cwo:RadioButton)
];
owl:onProperty awo: MapsTo
].
cwo:Hslider
a cwo:ConcreteInterfaceElement.
cwo:VSlider
a cwo:ConcreteInterfaceElement.
cwo:Datechooser
a cwo:ConcreteInterfaceElement.
cwo:ComboBox
a cwo:ConcreteInterfaceElement.
cwo:DateField
a cwo:ConcreteInterfaceElement.
cwo:NumericStepper
a cwo:ConcreteInterfaceElement.
cwo:RadioButton
a cwo:ConcreteInterfaceElement.
//------------------------------------------------------------------------
:CompositeInterfaceElement
a owl:Class;
rdfs:subClassOf awo:AbstractInterfaceElement;
rdfs:subClassOf
[a owl restriction;
owl:allValuesFrom
[a owl:Class;
owl:oneOf (cwo:ButtonBar cwo:DataGrid cwo:HorizontalList
cwo:LinkBar cwo:List cwo:Menu cwo:MenuBar cwo:Tree
cwo:PopUpButton cwo:RadioButtonGroup cwo:SWFLoader
125
cwo:TabBar cwo:TileList cwo:ToggleButtonBar
cwo:composite)
];
owl:onProperty awo: MapsTo
].
cwo:ButtonBar
a cwo:ConcreteInterfaceElement.
cwo:DataGrid
a cwo:ConcreteInterfaceElement.
cwo:HorizontalList
a cwo:ConcreteInterfaceElement.
cwo:LinkBar
a cwo:ConcreteInterfaceElement.
cwo:List
a cwo:ConcreteInterfaceElement.
cwo:Menu
a cwo:ConcreteInterfaceElement.
cwo:Tree
a cwo:ConcreteInterfaceElement.
cwo:PopUpButton
a cwo:ConcreteInterfaceElement.
cwo:RadioButtonGroup
a cwo:ConcreteInterfaceElement.
cwo:SWFLoader
a cwo:ConcreteInterfaceElement.
cwo:TabBar
a cwo:ConcreteInterfaceElement.
cwo:TileList
a cwo:ConcreteInterfaceElement.
cwo:ToggleButtonBar
a cwo:ConcreteInterfaceElement.
cwo:Composition
a cwo:ConcreteInterfaceElement.
//------------------------------------------------------------------
126
8.5 Interface Visual de Componentes MXML
Container MXML Apresentação Visual
Accordion
ApplicationControlBar
HBox
Canvas
127
ControlBar
Form
Grid
Panel
128
TabNavigator
ViewStack
Control MXML
Apresentação visual
Button
ButtonBar
CheckBox
ColorPicker
ComboBox
129
DataGrid
DateChooser
DateField
HorizontalList
HSlider / VSlider
Image imagem (jpg, gif ou png)
130
Label
Label
LinkBar
LinkButton
List
Menu
MenuBar
131
NumericStepper
PopUpButton
PopUpMenuButton
ProgressBar
RadioButton
RadioButtonGroup
TabBar
Text
132
TextArea
TextInput
TileList
ToggleButtonBar
ToolTip
Tree
