Escolar Documentos
Profissional Documentos
Cultura Documentos
MONTES CLAROS
2008
1
MONTES CLAROS
2008
2
______________________
Profª. Msc. Federico Bida de Oliveira
Departamento de Ciências da Computação
Universidade Estadual de Montes Claros
______________________
Profª. Sônia Beatriz de Oliveira e Silva Maia
Departamento de Ciências da Computação
Universidade Estadual de Montes Claros
MONTES CLAROS
2008
3
RESUMO
LISTA DE FIGURAS
Figura 2.1.1 - Aplicação desenvolvida sem técnica de reuso (SILVA, 2000, p.31) ... 17
Figura 2.1.2 - Aplicação desenvolvida utilizando classes de biblioteca (SILVA, 2000,
p.31) .......................................................................................................................... 18
Figura 2.1.3 - Aplicação desenvolvida utilizando framework (SILVA, 2000, p.32)..... 18
Figura 2.1.4 - Inversão de controle (COELHO, 2002, p.11) ...................................... 19
Figura 2.1.5 - Ciclo de vida de um framework (SILVA, 2000, p.47)........................... 25
Figura 2.1.6 - Projeto Dirigido Por Exemplos (BEUTLER, 2003, p.33) ...................... 27
Figura 2.1.7 - Etapas do Projeto Dirigido Por Exemplos (SILVA, 2000, p.50) ........... 29
Figura 2.1.8 - As etapas do projeto dirigido por Hot spot (SILVA, 2000, p.52) .......... 30
Figura 2.3.1 - Hierarquia de classes do display API (MOOCK, 2007, p.459). ........... 40
Figura 3.1 - Página de introdução do site Metropolitan ............................................. 51
Figura 3.2 - Página home do site Metropolitan .......................................................... 52
Figura 3.3 - Página home mídia de vídeo. ................................................................ 53
Figura 3.4 - Página de candidatura do site Metropolintan ......................................... 54
Figura 3.5 - Página de informações da empresa ....................................................... 55
Figura 3.6 - Seção key dates and history .................................................................. 55
Figura 3.7 - Seção Interview with Michel levaton ..................................................... 56
Figura 3.8 - Página de contatos ................................................................................ 57
Figura 3.10 - Página Home ....................................................................................... 59
Figura 3.11 - Página Recepten.................................................................................. 60
Figura 3.12 - Página Thema`s ................................................................................... 61
Figura 3.13 - Página Nuttige Tips .............................................................................. 61
Figura 3.14 - Página Contact..................................................................................... 62
Figura 3.15 - Página De Sterslager in uw buurt......................................................... 63
Figura 3.16 - página Leden ....................................................................................... 64
Figura 3.17 - Página Administrator ............................................................................ 65
Figura 3.18 - Hierarquia de navegação do site Sterslager ........................................ 66
Figura 3.19 - Página de introdução remmmicom....................................................... 67
Figura 3.20 - Página home ........................................................................................ 67
Figura 3.21 - Página Ons Bedrif ............................................................................... 68
Figura 3.22 - Páginas Productinfo ............................................................................. 68
5
LISTA DE QUADRO
LISTA DE SIGLAS
SUMÁRIO
1 INTRODUÇÃO .................................................................................................... 10
2 REFERENCIAL TEÓRICO .................................................................................. 17
2.1 FRAMEWORK .................................................................................................. 17
2.1.1 Classificações do framework..................................................................... 20
2.1.2 Comparação entre herança e composição ................................................ 22
2.1.3 Análise de domínio .................................................................................... 24
2.1.4 Fatores que influenciam no desenvolvimento de framework..................... 25
2.1.5 Metodologias de desenvolvimento de framework ..................................... 27
2.1.5.1 Projeto Dirigido Por Exemplos ............................................................ 27
2.1.5.2 Projeto dirigido por hot spot ................................................................ 30
2.1.5.3 Metodologia de projeto da empresa Taligent ...................................... 32
2.2 PADRÕES DE PROJETO ................................................................................ 33
2.3 ACTIONSCRIPT 3 ............................................................................................ 36
2.3.1 O display API no actionscript 3 ................................................................. 39
2.3.2 Comunicação com o servidor .................................................................... 43
2.4 MULTIMÍDIA ..................................................................................................... 45
2.4.1 Tipos de produtos multimídias .................................................................. 46
3 FRAMEWORK BUILDERWEB ........................................................................... 48
3.1 API JAVASCRIPT DO FLASH CS3 .................................................................. 49
3.2 ANÁLISE DOS APLICATIVOS DESENVOLVIDOS COM A FERRAMENTA
FLASH UTILIZANDO ACTIONSCRIPT .................................................... 50
3.2.1 Projeto Metropolitan .................................................................................. 50
3.2.2 Projeto Sterslager...................................................................................... 59
3.2.3 Projeto Remmicom .................................................................................... 66
3.2.4 Projeto IEP ................................................................................................ 70
3.3 ANÁLISE DE DOMÍNIO .................................................................................... 73
3.4 ESTRUTURA E PROJETO DE IMPLEMENTAÇÃO DO FRAMEWORK
BUILDERWEB .......................................................................................... 74
3.4.1 Estrutura do painel de controle do BuilderWeb ......................................... 74
3.4.2 Arquitetura do framework builderweb ........................................................ 81
4 ESTUDO DE CASO ............................................................................................ 86
9
5 CONCLUSÕES ................................................................................................... 89
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................... 97
APÊNDICES ........................................................................................................... 99
APÊNDICE A – CÓDIGO FONTE DAS CLASSES DO PAINEL DE CONTROLE 100
APÊNDICE B – CÓDIGO FONTE DO ARQUIVO PROJECT.JSFL...................... 107
APÊNDICE C – CÓDIGO FONTE DO PACOTE CLASSLOADER ....................... 118
APÊNDICE D – CÓDIGO FONTE DO PACOTE PAGES ..................................... 122
APÊNDICE E – CÓDIGO FONTE DO PACOTE CONTROL ................................ 124
APÊNDICE F – CÓDIGO FONTE DO PACOTE DATA ........................................ 129
APÊNDICE G – CÓDIGO FONTE DO PACOTE COMMUNICATION .................. 132
10
1 INTRODUÇÃO
Coelho (2002) realizou um estudo no qual faz uma comparação entre algumas
formas de reuso, que são bem utilizadas pelos desenvolvedores atualmente, no
intuito de esclarecer as características, semelhanças e diferenças entre elas. Os
métodos de reuso utilizadas nessa comparação foram:
12
A terceira etapa, conforme pode ser visto na seção 3.4, se refere à implementação
do framework BuilderWeb , que funciona como uma extensão da ferramenta Flash
CS3 , sendo essa extensão desenvolvida com a API Javascript do Flash.
2 REFERENCIAL TEÓRICO
2.1 FRAMEWORK
Figura 2.1.1 - Aplicação desenvolvida sem técnica de reuso (SILVA, 2000, p.31)
18
Figura 2.1.2 - Aplicação desenvolvida utilizando classes de biblioteca (SILVA, 2000, p.31)
O framework pode ser classificado segundo suas características. Nessa seção serão
descritas duas formas, uma em relação ao domínio que este atua e a outra de
acordo a maneira de instanciação das aplicações a partir dele.
Os horizontais são mais gerais que os verticais e por isso podem ser usados
por mais tipos de aplicações. Toolkits GUI são exemplos de frameworks
horizontais. Eles podem ser usados para construir interfaces de usuário
para uma grande faixa de aplicações. O framework horizontal por ser mais
geral é mais utilizado, em maior quantidade, mas seu usuário deve se
preocupar com a introdução de muitas características não desejadas.(
BEUTLER,2002, p.23)
Existe ainda outro tipo denominado de caixa cinza que representa uma mistura entre
framework de caixa-preta e branca. Segundo Johnson (1992) alguns dos
componentes são reutilizados por herança e outros por composição. Silva (2000)
define caixa-cinza como sendo um framework com a base dirigida a arquitetura e
uma camada dirigida a dados. Com essa abordagem é possível criar aplicações
através da combinação de objetos e também a geração de subclasse.
Como foi visto na seção 2.1.1, a reutilização dos componentes do framework pode
ser feita de duas formas através de herança ou da composição. De acordo com
Gamma (2000) a herança de classes permite ao desenvolvedor definir a
implementação de uma classe em termo da implementação de outra. A reutilização
por meio de subclasses é freqüentemente chamada de reutilização de caixa branca.
Esse nome se dá pelo fato do interior da classe pai ser visível pelas classes filhas.
com vários níveis hierárquicos (uma classe possui uma subclasse e esta estende
outra classe filha e assim sucessivamente) em várias camadas qualquer mudança
que possa ocorrer na classe-mãe (a classe no nível mais alto da hierarquia)
provocará uma mudança em todas as outras que estão em níveis mais baixos. Essa
dependência de implementação pode limitar a flexibilidade ou até mesmo a
reusabilidade. Para Gamma (2000, p.34) uma solução desse problema seria “[...]
herdar somente de classes abstratas, uma vez que elas normalmente fornecem
pouca ou nenhuma implementação”.
Silva (2000) também retrata, como mostra a Figura 2.1.5, a importância que o
desenvolvedor possui na criação do framework. Ele é o reponsável por decidir que
classes comporão a estrutura deste, suas responsabilidades e a flexibilidade provida
aos seus usuários. O desenvolvedor atua não apenas na construção dele, mas
também na sua manutenção.
1 - Análise do domínio:
Assimilar as abstrações já conhecidas;
29
2 - Projetar uma hieraquia de classes que possa ser especializada para abranger
os exemplos (um framework) – nesta etapa o johnson recomenda a
utilização de padrões de projeto.
Figura 2.1.7 - Etapas do Projeto Dirigido Por Exemplos (SILVA, 2000, p.50)
30
Segundo Silva (2000), “[...] os hot spots são as partes flexíveis de um fremawork.
Com isso, a essência dessas metodologias é identificar os hot spot na estrutura de
classes de um domínio, e, a partir disso construir o framework [...]”. Pree (1995)
descreve um conjunto de passos que deve ser tomados para o desenvolvimento de
framework, utilizando essa metodologia, conforme ilustra a Figura 4.8.
Figura 2.1.8 - As etapas do projeto dirigido por Hot spot (SILVA, 2000, p.52)
De acordo com Silva (2000) a metodologia adotada pela empresa Taligent, que
atualmente não existe, consiste no desenvolvimento de um conjunto de frameworks
estruturalmente menores e mais simples, que usados juntamente darão origem as
aplicações. Percebe-se que essa metodologia difere-se das outras descritas nesse
capítulo, devido ao fato de esta adotar um conjunto de frameworks, enquanto que,
as outras adotam um único framework para sanar as necessidades do domínio. Para
Silva (2000) uma justificativa da criação de um conjunto de pequenos frameworks
está no fato deles serem mais flexíveis e possuírem um alto grau de reutilização.
Silva (2000, p.53) ainda afirma um outro aspecto que é relativo a facilidade da
utilização do framework, através da minimização da quantidade de código que o
usuário deve criar, devido ao seguintes fatores:
Disponibilidade de implementações (classes) concretas que possam ser
usadas diretamente;
Minimização do número de classes que devem ser criadas;
Minimização do número de métodos que devem ser sobrepostos.
Implementar o framework:
Implementar as classes principais;
Testar o framework (gerando aplicações);
Solicitar a terceiros o procedimento de teste
Interar para refinar o projeto.
Desdobrar o framework:
Providenciar documentação na forma de diagramas, receitas (como usar o
framework para desenvolver determinada aplicação) e exemplos de
aplicações simples (incluindo o código da implementação, que complementa o
framework);
Manter e atualizar o framework, seguindo as seguintes regras:
Corrigir erros imediatamente;
Adicionar novas características ocasionalmente;
Mudar interfaces tão infreqüentemente quanto possível ("é melhor
adicionar novas classes que alterar a hierarquia de classes existente, bem
como adicionar novos métodos que alterar ou remover métodos existentes").
Gamma (2000) foi o pioneiro a catalogar padrões de projeto em sua tese de Ph.D.
Ele catalogou mais de 24 padrões. Segundo Gamma (2000) um padrão deve
apresentar quatro elementos essenciais:
36
2.3 ACTIONSCRIPT 3
ActionScript 3.0 oferece um modelo de programação robust que seja familiar aos
desenvolvedores com um conhecimento básico de programação orientado a objeto.
Moock (2007), define Algumas das características chaves de ActionScript 3, que
podem ser vistas a seguir:
O Flash display API que é um conjunto de classes para trabalhar com objetos
visuais interativos. Como por exemplo, objetos graficos, bitmaps e conteúdo
vetoriais (MOOCK, 2007).
A ferramenta de autoria Flash que fornece um conjunto de componentes,
uma coleção de ferramentas para interface com usuário (que possibilita
pequeno tamanho de arquivo e menor uso de memória) utilizando assim
menos recursos (MOOCK, 2007).
Legendas:
são declarados nas classes bases e implementados nas classes filhas ) , como
ocorre em linguagens de programação como Java. Portanto, como é demostrado na
Figura 6.1 elas são consideradas como classes Abstract-style que é uma técnica
utilizada pelos desenvolvedores do API pra similar essas características das classes
abstratas (MOOCK, 2007).
Segundo Moock (2007) esta classe é mais do que apenas uma simples classe base,
DisplayObject é a fonte de muitas das capacidades gráficas do display API como :
Verificando interseções entre objetos e pontos utilizando os respectivos
métodos hitTestObject () e hitTestPoint ();
Aplicando filtros, transformação de froma e máscaras;
Capacidade de Promover transformações em escala nos Objetos gráficos.
ela o armazena no próprio sistema, evitando que este faça uma nova requisição em
busca de pequenos trechos de informação, reduzindo assim o processamento no
servidor. Em tecnologias como essa, boa parte do processamento ocorre no cliente
aliviando assim a carga no servidor.
2.4 MULTIMÍDIA
Segundo Pádua Filho (2000), Multimídia pode ser apresentado como programas e
sistemas em que a comunicação entre homens e computadores se dá através de
múltiplos meios de representação de informação, como som e imagem animada,
além da imagem estática já usada em aplicativos gráficos. A utilização do
computador como meio de comunicação se deve segundo as seguintes
características:
Os títulos são produtos que se comportam mais como documentos do que como
programas. A flexibilidade está embutida nos programas visualizadores ou
navegadores, que são os meios de consulta e pesquisa desses documentos digitais
(PÁDUA FILHO, 2000). Os títulos podem ser subdivididos em duas categorias que
são os títulos lineares e títulos hipermídia.
3 FRAMEWORK BUILDERWEB
Este framework foi criado para ser usado em conjunto com a ferramenta Flash CS3
funcionando como uma extensão desta. Isso é possível através da API Javascript,
que possibilita a utilização de recursos contidos nessa ferramenta, como por
exemplo a criação e edição de documento que até então só poderiam ser utilizado
49
O Flash JavaScript API foi projetado para ser utilizado com outros tipos de software
como, o Adobe Dreamweaver e Adobe Fireworks devido ao fato destes serem
concebidos com base no Netscape JavaScript API. O Flash JavaScript API é
baseada em um Document Object Model (DOM), que permite aos documentos
Flash serem acessados usando JavaScript objetos. O Flash JavaScript API inclui
todos Elementos do Netscape JavaScript API, mais o Flash DOM, que consiste em
um conjunto de funções de nível superior. Um das características dessa API é a
possibilidade de criar extensões para a ferramenta de autoria Flash, devido a sua
capacidade de utilizar recursos contidos nessa ferramenta. O uso dessa
característica só é possível através do extension installation file que é um arquivo
XML (com um nome que termina em MXI), que fornece informações sobre a
instalação para Extension Manager. Dentre essas informações está contido o
número da versão, o tipo de extensão, informações sobre cada arquivo incluído na
50
extensão, bem como informações sobre a forma como os usuarios podem utilizar a
extensão de um Aplicação. Após a criação do arquivo MXI o software Extension
Maneger lê as informações desse, criando um arquivo MXP, que é o arquivo de
instalação propriamente dito ( ADOBE, 2008).
O Metropolitan é um web site criado pra uma agência de modelos como intuito de
prover a divulgação da marca, assim como expor suas medelos. Ele pode ser
encontrado no seguinte endereço web http://www.metropolitanmodels.com/. Esse
projeto possibilita que novas modelos se candidatem a fazer parte do conjunto de
modelos que constituem o Metropolitan. Os projetos criados pela empresa X
constituem normalmente de duas aplicações distintas. Sendo que uma delas criada
através da ferramenta Flash juntamente com a linguagem Actionscript e a outra
criada pela linguagem de programação PHP juntamente com banco de dados MySql.
A integração dessas duas aplicações ocorre via XML criado pelo PHP contendo uma
visão bruta dos dados contidos no banco de dados. Essa integração pode ser vista
51
com mais detalhes na seção 2.3.2. As Figuras 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8
apresentarão as telas do site Metropolitan com o intuito de exemplificar com maiores
detalhes as características dessa aplicação.
A Figura 3.1, apresenta uma página de introdução do site. Essa página é mais
comum em aplicações multilinguagem, como pode ser exemplificado com a
miniatura das bandeiras, na qual o usuário escolhe a língua corrente que será
utilizada no site. Esse controle da língua é feita juntamente com o PHP. O arquivo
swf, efetua uma requisição ao arquivo PHP responsável pelo controle da linguagem,
no qual realiza uma pesquisa em banco de dados com o intuito de recuperar os
dados da língua cadastrada no sistema. Após isso, o arquivo PHP responde com um
conjunto de variáveis relativos aos valores de tradução de cada campo de texto que
o site possui. Após a escolha da linguagem o arquivo base,que é responsável por
chamar as diferentes paginas internas do site, é carregado. Este por sua vez
carrega a pagina home.
52
A Figura 3.2 apresenta a página home, que contém uma lista ou galeria de fotos e
nomes das modelos cadastradas em banco de dados. Conforme pode ser visto
nesta figura, devido ao fato do site ser totalmente administrável o conteúdo
apresentado nesta página é proveniente de leitura de XML. Este possui informações
relativas a página como dados das modelos (ver ÁREA 4) e url das fotos. A
aplicação foi desenvolvida de tal forma que ao clicar na foto ou nome da modelo(ver
ÁREA 1 e ÁREA 2) cria–se uma nova galeria contendo as fotos individuais de cada
modelo (ver ÁREA 3). Essa galeria tem a função de realizar uma pré seleção de
fotos de uma determinada modelo, através dos checkBox, com o objetivo de enviar
essas fotos por email ou então imprimi-las. Uma questão importante ao se
desenvolver aplicativos com essas tecnologias é o fato de aliviar a carga de
processamento no servidor, uma vez que as informações relativas ao funcionamento
53
ressaltar que, tanto o título como o texto de descrição da página são totalmente
administráveis.
A Figura 3.8, apresenta a página contato que possui uma lista ou galeria de e-mails
relativos ao setor de comunicação da empresa. Ao se clicar em um desses e-mails
se abre um pop - Up com informações como nome, e-mail e menssagem que será
direcionada para o e-mail no qual foi clicado.
57
Analisando a Figura 3.9 observa-se o swf Preloader. Ele possui uma única função,
realiza um pré carregamento dos recursos fundamentais da aplicação. Dessa forma,
ele vai funcionar como suporte da aplicação, ou seja, vai conter todos os outros
arquivos do site. Como foi visto no início da seção a intro é o primeiro arquivo a ser
chamado, após o usuário realizar a escolha da língua que aparecerá no site o
Preloader realizará uma troca entre o arquivo intro pela base. Conforme é observado
na Figura 3.9, quando vários arquivos possuem o mesmo nível hierárquico significa
que eles vão ser carregados no mesmo arquivo container, que neste caso é o
Preloader. Uma outra característica importante a observar é o arquivo Base, que
possui o menu responsável pelas trocas e gerenciamento das páginas na seção.
59
Nessa seção será analisado o projeto Sterslager que foi um site desenvolvido para
uma empresa belga que possui o mesmo nome do projeto. Sterlager é uma empresa
de venda de produtos alimentícios e comidas prontas. Ele pode ser visto no seguinte
endereço web http://www.sterslager.be. A Figura 3.10 mostra o conteúdo do site. Em
seguida é feita a descrição das funcionalidades de cada página. A estrutura dessa
aplicação é semelhante a apresentada no projeto Metropolitan contendo duas
aplicações distintas integradas via arquivo XML.
Na Figura 3.10 observa - se que o site possui 10 seções, como se pode ver no
menu, A página inicial é a” Wat is een Sterslager”; essa seção possui um título
introdutório que tem o mesmo nome da seção que significa “o que é Sterslager?” e
logo abaixo um texto contendo a descrição da empresa. Nessa mesma pagina são
apresentadas referências sobre outras seções do site como: recepten, Nuttige tips,
De Sterslager in uw buurt, funcionando como uma pré visualização e um atalho para
cada uma dessas seções. É importante ressaltar que, todas as imagens e textos
60
contidos nessa página podem ser alterados pelo administrador do site, através da
aplicação desenvolvida em PHP. Observa-se que esse projeto não possui a seção
de introdução, como ocorria no projeto Metropolitan, devido ao fato dessa aplicação
possuir apenas uma língua de exibição. Analisando este projeto de forma geral as
seções que ele possui são constituídas basicamente de foto, texto e animações. As
Figuras 3.11, 3.12, 3.13, 3.14 apresentam algumas páginas internas do web site
Sterslager.
O web site desenvolvido pra o instituto IEP teve como objetivo a divulgação da
organização assim como, expor os serviços que ela disponibiliza. Ele pode ser
encontrado no seguinte endereço web http://www.institutoiep.org. Esse web site é
constituído por oito seções, sendo elas formadas basicamente por texto, imagens e
animações. O conteúdo desse Web site assim como ocorre em todos os projetos
mencionados nesse trabalho, é administrável e a integração com o aplicativo
servidor ocorre via XML. A seguir serão descritas quatro seções as quais
especificam bem as características gerais do projeto. Figuras 3.26, 3.27, 3.28, 3.24
apresentam respectivamente as seguintes seções, Base ou home, Fotos, cursos e
Faleconosco, sendo essa utima seção é semelhante às páginas contatos visto nos
outros projetos. Nesse projeto percebe-se que seção base é a mesma da home,
diferente do que ocorre nos outros projetos, devido ao fato desta possuir apenas a
função de navegação no site. A seção fotos possui uma listagem de títulos onde
cada título está associado a uma galeria de fotos. Percebe se que a listagem de
conteúdo e galerias e fotos ocorrem em quase todos os projetos .A seção cursos
possui uma listagem de todos os cursos disponibilizados pelo instituto, sendo que
71
Conforme foi visto na seção 2.1.3 um dos passos iniciais para a criação de
framework é realizar uma análise do domínio no qual este irá atuar. Segundo
(PRESSMAN, 2006) o objetivo desta análise é descobrir e identificar padrões de
análise reutilizáveis, classes de análise e informação relacionada que possam ser
74
responsável por escolher o nome e o diretório no qual o projeto vai ser armazenado.
Isso é possível graças ao arquivo project.jsfl, que é um arquivo criado através da API
Javascript do Flash. Este arquivo funciona como uma biblioteca de funções. Quando
o usuário do framework pressiona sobre o botão Criar Novo Projeto é chamado o
método createProject e esse, por sua vez, chama uma função do arquivo project.jsfl
denomina de createProject. Essa função possui o poder de criar pastas e arquivos.
As Figuras 3.34, 3.25 apresentaram as telas utilizadas na criação de um projeto
através do BuilderWeb.
Como pode ser visto na Figura 3.34, ao pressionar o botão criar Novo Projeto
aparecerá um pop-up que solicita em qual diretório o usuário deseja salvar o projeto.
Após a escolha do diretório surge um novo pop-up, como pode ser visto na Figura
3.35, onde o usuário digitará o nome do projeto a ser criado. Depois disso o projeto
será criado no diretório especificado. A Figura 3.36 apresenta a estrutura de
arquivos criada pelo framework BuilderWeb.
A pasta aplication possui todos os arquivos .fla e uma pasta chamada classes que
possui todos os pacotes de classes do framework BuilderWeb. Na seção 3.4.1 será
realizada uma análise mais detalhada das classes que formam a arquitetura do
BuilderWeb. Na pasta execute possui todos os arquivos .swf , Javascript e HTML.
Arquivos esses necessários para que o site execute normalmente em um servidor
web, ou seja, todos os arquivos que serão enviados para mesmo. A Figura 3.37
apresenta a disposição de arquivos da pasta execute.
79
Como pode ser visto na Figura 3.37, esses são os arquivos iniciais que são gerados
pelo framework. O arquivo índex.html é o primeiro a ser chamado quando se entra
no site. Ele está relacionado com o arquivo Preloader.swf, que é o primeiro arquivo
do Flash a ser executado. Isso pode ser visto na seção 3.2 nas hierarquias de
navegação dos projetos analisados. Os arquivos AC_OETags.js e
playProductInstall.swf são arquivos responsáveis pelo controle da versão do Flash
Player corrente na máquina do cliente. Por exemplo, o Actionscript 3 é executado no
Flash Player 9, caso a máquina do cliente não possui Flash player instalado ou uma
versão inferior como, Flash Player 7 ou 8. Esses arquivos promoverão a atualização
do plugin da máquina do cliente para uma versão mais atual.
Conforme pode ser visto na seção 3.2 as páginas de site em Flash obedecem a uma
estrutura de árvore. Dessa forma, uma maneira conveniente de representar essa
estrutura é através do XML que também possui uma estrutura em árvore. O XML de
navegação possui um nó principal que é o aplication. Dentro de aplication existem os
nós pages, sendo que cada um representa uma página da aplicação. Cada nó page
possui um atributo swf, contendo o nome que será atribuido aos arquivos fla e swf
80
que serão criados pelo framework. Percebe-se que as páginas preloader e base já
estão definidas no XML. Isso por que, como pode ser visto na análise das aplicações
exemplos da seção 3.2, todas elas possuem uma página preloader e base nas
respectivas hierarquias de navegação.
A pasta templates possui o arquivo pages.fla que funciona como base para a criação
das outras páginas da aplicação. Isso implica que, qualquer alteração que ocorra
nesse arquivo, antes do projeto ser aberto, será repassado para todas as páginas do
aplicativo. Isso impõe uma característica interessante ao framework, porque ao
invés do desenvolvedor criar várias páginas e depois atribuir características gerais a
cada uma delas, ele pode, com o framework, editar o arquivo pages.fla, atribuindo a
ele características gerais, que posteriormente, ao abrir o projeto, o framework criará
todas as páginas com as funcionalidades que foram descritas nos arquivos pages.fla
inbitudas. Isso torna, o desenvolvimento do aplicativo mais rápido.
Observando a Figura 3.38 observa-se a pasta classes que contém todos os pacotes
relativos a arquitetura do BuilderWeb. Também pode se observar dois arquivos flas,
sendo eles base.fla e preloader.fla(o fato de existir apenas esses dois arquivos .fla
no diretório é por que o projeto ainda não foi editado, ou seja , não foi inserida
nenhuma nova página ao XML de navegação). Existe também um arquivo de projeto
do Flash denominado BuilderProject. A Figura 3.39 revela todos os pacotes que
compõe framework e que estão contidos na pasta classes.
A partir dos requisitos levantados na seção 3.2 pode ser criado a estrutura classes
do framework BuilderWeb. A Figura 3.40 apresenta um diagrama de classes da
estrutura arquitetural do framework.
83
Observando a Figura 3.40 pode se ter uma visão geral do framework BuilderWeb, ou
seja, das classes que constituem a arquitetura básica do mesmo. Toda a base da
aplicação é definida pelo framework. Cabe a ele a geração das classes Preloader,
Base e BaseLoader, que possui a função de mostrar para o usuário final o status de
carregamento da página Base da aplicação. O diagrama apresenta a classe
AbstractLoader que uma é classe que implementa o padrão de projeto Template
Method. Segundo Gamma(2000) o Template Method “[...] define o esqueleto de um
algoritmo em uma operação, postergando a definição de alguns passos para
subclasses [...]”. Dessa forma, a classe AbstractLoader define apenas as
funcionalidades genéricas deixando para suas subclasses a funcionalidade
específica que cada uma deve ter. No caso do framework BuilderWeb a classe
AbstractLoader define apenas que arquivo será carregado deixando para suas
subclasses definirem como será o progresso de carregamento dos objetos e onde
eles irão ser adicionados.
A classe Pages funciona como um modelo de classe, um template, para criação das
páginas do site. Quando o usuário do framework edita o XML de navegação e Abre
o Projeto no qual o XML foi editado, são criadas automaticamente todas as classes
relativas às páginas que foram inseridas no XML. Sendo que cada Página possui
um objeto da classe LoadXML , que possui a função de realizar a leitura de um
possível XML proveniente do servidor.
85
4 ESTUDO DE CASO
Conforme pode ser visto na Figura 4.1, a página home é costituída basicamente por
um texto descritivo e uma foto ilustrativa. A seção de Notícias, como pode ser visto
na Figura 4.2, apresenta uma listagem das notícias cadastradas na aplicação em
php. A Figura 4.3 mostra a página contatos, na qual o usuário pode enviar um email
para o administrador da página. Por fim, a Figura 4.4 apresenta a página fotos, que
é constituída por uma galeria de fotos. A Figura 4.5, mostra o diagrama de classes
da aplicação BuilderWebInfos.
90
5 CONCLUSÕES
REFERÊNCIAS BIBLIOGRÁFICAS
APÊNDICES
100
package system{
import Flash.display.*;
import adobe.utils.*;
import Flash.events.*;
import Flash.external.ExternalInterface;
import fl.transitions.Tween;
import fl.transitions.easing.*;
import fl.transitions.TweenEvent;
URI=MMExecute('fl.browseForFolderURL("Selecione o arquivo")');
infosXMLPages = new InfosXMLPages(URI);
101
var str:String;
str='fl.runScript(fl.configURI+"/bulderWeb/jsfl/project.jsfl","createProject");';
var projeto;
projeto = MMExecute(str);
project_mc.text_txt.text= projeto;
//eventos
====================================================================
package system{
import Flash.events.*;
import adobe.utils.*;
*/
public class InfosXMLPages {
if (XML.children().length()==0) {
if(XML.children().toXMLString()==""){
for(var i:int=(XML.length()-1);i>=0;i--){
addObjInfos(XML,i,objParent);
}
cont=0;
insertPages();
WriteClassDataXMLSystem();
return 0;
}
else{
addObjInfos(XML,(--num),XML[num].@swf);
readXMLData(XML.parent().children(),num,XML[num].@swf);
}
} else {
if (num>1) {
addObjInfos(XML,(--num),objParent);
103
readXMLData(XML,num,objParent);
} else {
addObjInfos(XML,(--num),objParent);
readXMLData(XML.children(),XML.children().length(),XML[num].@swf);
}
}
}
// callJsfl(XML[num].@swf,URI);
infosXML = new Object();
infosXML.name = XML[num].@swf;
infosXML.objParent = XML[num].parent().@swf;
objInfosXML.unshift(infosXML);
cont++;
}
}
str+=" }\\n";
str+=" public function get getObjDataXML(){\\n ";
str+=" return objDataXML;\\n";
str+=" }\\n";
str+=" public function setFlagObjDataXML(flag:int,id:int){\\n";
str+=" objDataXML[id].flag=1;\\n";
str+=" }\\n";
str+=" }\\n";
str+=" }";
var resp =
'fl.runScript(fl.configURI+"/bulderWeb/jsfl/project.jsfl","createClassDataXMLSystem","'+str+'","'+URI+'")
;';
MMExecute(resp);
}
//eventos========================================================
str
='fl.runScript(fl.configURI+"/bulderWeb/jsfl/project.jsfl","executeProject","'+URI+'");';
MMExecute(str);
trace("kkkk");
readXMLData(e.target.dataXML.children(),Number(e.target.dataXML.children().length()),"aplic
ation");
//metodos get
====================================================================
}
}
package system{
import Flash.events.*;
import Flash.net.*;
urlLoader.addEventListener(Event.COMPLETE, completeListener);
}
}
107
if(createTemplate==true){
var originalFileURI=fl.configURI+"/bulderWeb/templates/Page.as";
var newFileURI=folderURI+"/"+projeto+"/templates/Page.as";
FLfile.copy(originalFileURI, newFileURI);
}
/* var originalFileURI=fl.configURI+"/bulderWeb/execute/swfobject.js";
var newFileURI=folderURI+"/"+projeto+"/execute/swfobject.js";
FLfile.copy(originalFileURI, newFileURI);*/
Var originalFileURI=fl.configURI+"/bulderWeb/execute/AC_OETags.js";
var newFileURI=folderURI+"/"+projeto+"/execute/AC_OETags.js";
FLfile.copy(originalFileURI, newFileURI);
var originalFileURI=fl.configURI+"/bulderWeb/execute/playerProductInstall.swf";
var newFileURI=folderURI+"/"+projeto+"/execute/playerProductInstall.swf";
FLfile.copy(originalFileURI, newFileURI);
}
var originalFileURI=fl.configURI+"/bulderWeb/aplication/preload.fla";
var newFileURI=folderURI+"/"+projeto+"/aplication/preloader.fla";
FLfile.copy(originalFileURI, newFileURI);
var originalFileURI=fl.configURI+"/bulderWeb/aplication/classes/pages/Preloader.as";
var newFileURI=folderURI+"/"+projeto+"/aplication/classes/pages/Preloader.as";
FLfile.copy(originalFileURI, newFileURI);
var originalFileURI=fl.configURI+"/bulderWeb/aplication/classes/pages/Base.as";
var newFileURI=folderURI+"/"+projeto+"/aplication/classes/pages/Base.as";
FLfile.copy(originalFileURI, newFileURI);
var originalFileURI=fl.configURI+"/bulderWeb/aplication/Base.fla";
var newFileURI=folderURI+"/"+projeto+"/aplication/base.fla";
var paran =newFileURI;
var baseFla = FLfile.copy(originalFileURI, newFileURI);
if(baseFla==true){
109
createClassBase(paran);
}
var
originalFileURI=fl.configURI+"/bulderWeb/aplication/classes/control/Composite.as";
var newFileURI=folderURI+"/"+projeto+"/aplication/classes/control/Composite.as";
FLfile.copy(originalFileURI, newFileURI);
var originalFileURI=fl.configURI+"/bulderWeb/aplication/classes/control/ItenMenu.as";
var newFileURI=folderURI+"/"+projeto+"/aplication/classes/control/ItenMenu.as";
FLfile.copy(originalFileURI, newFileURI);
var
originalFileURI=fl.configURI+"/bulderWeb/aplication/classes/control/IStructureObj.as";
var newFileURI=folderURI+"/"+projeto+"/aplication/classes/control/IStructureObj.as";
FLfile.copy(originalFileURI, newFileURI);
Var
originalFileURI=fl.configURI+"/bulderWeb/aplication/classes/control/StructureMenu.as";
var newFileURI=folderURI+"/"+projeto+"/aplication/classes/control/StructureMenu.as";
FLfile.copy(originalFileURI, newFileURI);
var
originalFileURI=fl.configURI+"/bulderWeb/aplication/classes/control/StructureMenuUser.as";
var newFileURI=folderURI+"/"+projeto+"/aplication/classes/control/StructureMenuUser.as";
FLfile.copy(originalFileURI, newFileURI);
}
if(classLoader==true){
var
originalFileURI=fl.configURI+"/bulderWeb/aplication/classes/classLoader/AbstractLoader.as";
var newFileURI=folderURI+"/"+projeto+"/aplication/classes/classLoader/AbstractLoader.as";
FLfile.copy(originalFileURI, newFileURI);
var
originalFileURI=fl.configURI+"/bulderWeb/aplication/classes/classLoader/BaseLoader.as";
var newFileURI=folderURI+"/"+projeto+"/aplication/classes/classLoader/BaseLoader.as";
FLfile.copy(originalFileURI, newFileURI);
var
originalFileURI=fl.configURI+"/bulderWeb/aplication/classes/classLoader/PagesLoader.as";
var newFileURI=folderURI+"/"+projeto+"/aplication/classes/classLoader/PagesLoader.as";
FLfile.copy(originalFileURI, newFileURI);
}
if(folderData==true){
var
originalFileURI=fl.configURI+"/bulderWeb/"+"aplication/classes/data/PrivateClass.as";
var newFileURI=folderURI+"/"+projeto+"/aplication/classes/data/PrivateClass.as";
FLfile.copy(originalFileURI, newFileURI);
}
if(folderInstall==true){
var
originalFileURI=fl.configURI+"/bulderWeb/"+"aplication/classes/expressInstallation/playerProductInstal
l.as";
var
newFileURI=folderURI+"/"+projeto+"/aplication/classes/expressInstallation/playerProductInstall.as";
FLfile.copy(originalFileURI, newFileURI);
111
var
originalFileURI=fl.configURI+"/bulderWeb/"+"aplication/classes/expressInstallation/playerProductInstal
lCallback.as";
var
newFileURI=folderURI+"/"+projeto+"/aplication/classes/expressInstallation/playerProductInstallCallbac
k.as";
FLfile.copy(originalFileURI, newFileURI);
}
if(folderCommunication ==true){
var
originalFileURI=fl.configURI+"/bulderWeb/"+"aplication/classes/communication/LoadXML.as";
var newFileURI=folderURI+"/"+projeto+"/aplication/classes/communication/LoadXML.as";
FLfile.copy(originalFileURI, newFileURI);
}
return projeto;
/*
chamado pela classe InfosXMLPages pelo metodo callJsfl
*/
function init(namePage,folderURI){
/*
esetá função cria todas as pastas, classes e arquivos nessecarios para o funcionamento do
framework
*/
112
var myProject;
var nameClass=(VerificaLetras(namePage));
//cria classe Base.as
===============================================================
var URI =
folderURI+"/aplication/classes/pages/"+nameClass+".as";
if(!FLfile.exists(URI) && nameClass!="Base" ){
var page = fl.openDocument(folderURI+"/templates/page.fla");
if(page == fl.getDocumentDOM()){
if (FLfile.write(URI,
createClass(nameClass))) {
myProject = fl.getProject();
myProject.addFile(URI,false);
fl.getDocumentDOM().docClass
="classes.pages."+nameClass;
//var a=
fl.saveDocument(fl.getDocumentDOM(), folderURI+"/projeto/templates/pagessss.fla")
setPublishProfileSettings("fileURI", 3,namePage)
fl.saveDocument(fl.getDocumentDOM(),
folderURI+"/aplication/"+namePage+".fla");
myProject.addFile(folderURI+"/aplication/"+namePage+".fla",false);
fl.closeDocument(fl.getDocumentDOM(),false);
}
else{
fl.trace("classe não foi criada");
}
}
}
function createClass(paran){
/*
esta função cria os códigos das classes relativas a cada pagina criada
113
*/
str+= " public class "+ paran +" extends MovieClip{\n\n ";
function VerificaLetras(ler){
//função que deixa a primeira letra do arquivo de classe UpperCase
var str1;
var str2="";
for(var i=0;i<ler.length;i++){
if(i==0){
str1=ler[i];
}
else{
str2+=ler[i];
}
}
return (str1.toLocaleUpperCase()+str2);
}
function executeProject(folderURI){
var URIProject =folderURI+"/aplication/BuilderProject.flp"
114
if(!FLfile.exists(URIProject)){
myProject = fl.createProject(folderURI+"/aplication/BuilderProject.flp","BuilderProject");
function createClassDataXMLSystem(str,URI){
/*function addProfile(folderURI,namePage){
setPublishProfileSettings(folderURI+"/execute/"+namePage+".swf", 9)
//fl.getDocumentDOM().exportSWF(folderURI+"/execute/"+namePage+".swf",true);
}*/
// make sure package paths look in ./classes, and classes export in frame 1
from = XML.indexOf("<ActionScriptVersion>");
to = XML.indexOf("</ActionScriptVersion>");
delta = XML.substring(from, to);
XML = XML.split(delta).join("<ActionScriptVersion>" + asVersion);
from = XML.indexOf("<PackageExportFrame>");
to = XML.indexOf("</PackageExportFrame>");
delta = XML.substring(from, to);
XML = XML.split(delta).join("<PackageExportFrame>1");
if (asVersion == 2)
{
XML = XML.split(delta).join("<PackagePaths>" + classPath + "classes");
}
else
{
XML = XML.split(delta).join("<AS3PackagePaths>" +classPath +"classes");
}
117
}
118
package classes.classLoader{
import Flash.display.*;
import Flash.events.*;
import Flash.net.*;
loads.contentLoaderInfo.addEventListener(ProgressEvent.PROGRESS,ListenerProgress);
loads.contentLoaderInfo.addEventListener(Event.COMPLETE,ListenerCompleted);
loads.addEventListener(Event.ADDED_TO_STAGE,loadsAddedToStage);
}
//eventos
====================================================================
private function ListenerOpen(e:Event){
animeOpen();
119
//metodos abstratos=============================================
protected function init(){}
protected function animeOpen(){}
protected function animeProgress(bytesLoaded:Number,bytesTotal:Number){}
protected function animeComplete(){}
protected function loadsLoaderAdded(){}
}
}
package classes.classLoader{
import Flash.display.*;
import Flash.events.*;
//event ===================================================
}
}
package classes.classLoader{
import Flash.display.*;
import Flash.events.*;
parent.addChild(loads);
pageCurrent = sName;
this.visible=false;
}
public function set setObjParent(str:String){
objParent = str;
}
}
}
122
package classes.pages{
import Flash.display.MovieClip;
import classes.data.*;
import classes.control.*;
}
public function init() {
createMenuIten();
}
function createMenuIten(){
iStructureObj = new StructureMenu();
addChild(iStructureObj.abstractStyle());
}
}
}
package classes.pages{
import Flash.display.*;
import classes.classLoader.*;
}
}
124
package classes.control{
import Flash.display.*;
import Flash.errors.IllegalOperationError;
// ABSTRACT Class( esta classe não deve ser instaciada, e sim estendida)
public class ComponetContainer extends MovieClip{
}
}
package classes.control{
import Flash.display.*;
import Flash.events.*;
package classes.control{
function abstractStyle():ComponetContainer;
}
}
package classes.control{
126
import Flash.text.*;
import Flash.display.*;
import Flash.events.*;
import classes.classLoader.*;
import classes.pages.*;
import classes.data.DataXMLSystem;
package classes.control{
import classes.data.*;
if (objInfosXML.getObjDataXML[i].name!="base" &&
objInfosXML.getObjDataXML[i].name!="preloader" && objInfosXML.getObjDataXML[i].flag!=1 ) {
if (objInfosXML.getObjDataXML[i].objParent=="base") {
cont++;
var iten = new
ItenMenu(objInfosXML.getObjDataXML[i].name);
iten.x=0;
iten.id=i;
iten.y=(cont)*20;
iten.text_txt.text=
objInfosXML.getObjDataXML[(i)].name;
128
menu.add(iten);
}
}
for (var j:int=0; j<objInfosXML.getObjDataXML.length; j++) {
if
(objInfosXML.getObjDataXML[i].name==objInfosXML.getObjDataXML[j].objParent) {
cont++;
objInfosXML.setFlagObjDataXML(1,j);
var iten = new
ItenMenu(objInfosXML.getObjDataXML[j].name);
iten.x=10;
iten.id = j;
iten.y=(cont)*20;
iten.text_txt.text=
objInfosXML.getObjDataXML[(j)].name;
menu.add(iten);
}
}
}
}
return menu;
}
}
}
package classes.control{
}
}
129
package classes.data{
/*
essa classe possibilita um truque de engenharia para a criação de um construtor privado
*/
class PrivateClass {
public function PrivateClass() {
}
}
}
package classes.data{
}
public function get getObjDataXML(){
return objDataXML;
130
}
public function setFlagObjDataXML(flag:int,id:int){
objDataXML[id].flag=1;
}
}
}
131
package classes.communication{
import flash.events.*;
import flash.net.*;