implementação de framework para desenvolvimento de aplicativos web em actionscript 3
TRANSCRIPT
UNIVERSIDADE ESTADUAL DE MONTES CLAROS – UNIMONTES
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGICAS – CCET
DEPARTAMENTO DE CIÊNCIAS DA COMPUTAÇÃO – DCC
CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO
HENRIQUE RODRIGUES LUZ
IMPLEMENTAÇÃO DE FRAMEWORK PARA DESENVOLVIMENTO DE APLICATIVOS WEB EM ACTIONSCRIPT 3
MONTES CLAROS
2008
1
HENRIQUE RODRIGUES LUZ
IMPLEMENTAÇÃO DE FRAMEWORK PARA DESENVOLVIMENTO DE APLICATIVOS WEB EM ACTIONSCRIPT 3
Projeto Orientado de Conclusão de Curso apresentado ao Departamento de Ciências da Computação da Universidade Estadual de Montes Claros, como requisito parcial para a conclusão do curso de Sistemas de Informação, orientado pelo professor Dr. Nilton Alves Maia.
MONTES CLAROS 2008
2
HENRIQUE RODRIGUES LUZ
IMPLEMENTAÇÃO DE FRAMEWORK PARA DESENVOLVIMENTO DE APLICATIVOS WEB EM ACTIONSCRIPT 3
Aprovada em .... de ....... de 2008. ______________________
Prof. Dr. Nilton Alves Maia - Orientador Departamento de Ciências da Computação Universidade Estadual de Montes Claros ______________________ 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
Atualmente no cenário do desenvolvimento web nota-se que a necessidade de criar aplicativos, para esse ambiente, mais específicos, mais intuitivos e de menor custo representa um grande desafio. Uma vez que, os prazos para o desenvolvimento desses aplicativos são muito curtos. Visando isso a reutilização de uma arquitetura pré-elaborada vem contribuir para a criação de tais aplicativos. Deste modo, este trabalho apresenta a análise, projeto e desenvolvimento do BuilderWeb, que é um Framework orientado a objeto voltado para a criação de aplicativos web em Actionscript 3. O BuilderWeb possibilita a criação de sites web dinâmicos e interativos. Permitindo a interação do Actionscript com linguagem que são executadas do lado do servidor. Como por exemplo, PHP, ASP e Java. O objetivo desse Framework é promover a reutilização tanto de projeto como de código desses aplicativos. A metodologia utilizada pra desenvolvimento deste foi Projeto Dirigido por Exemplos. Palavras-chave: Framework Orientado a Objeto, Reuso de Software, Actionscript 3, Padrões de Projeto, Web
4
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
Figura 3.23 - Página de contact ................................................................................ 69
Figura 3.24 - Página Personaliseer doos .................................................................. 69
Figura 3.25 - Hierarquia de navegação do site remmicom ........................................ 70
Figura 3.26 - Página base ......................................................................................... 71
Figura 3.27 - Página de Fotos ................................................................................... 72
Figura 3.28 - Página de Cursos ................................................................................. 72
Figura 3.29 - Página Faleconosco ............................................................................. 73
Figura 3.30 - Hierarquia de navegação do site Intituto IEP ....................................... 73
Figura 3.31 - Diagrama de casos de uso do framework BuilderWeb ........................ 75
Figura 3.32 - Diagrama de classes do painel de controle BuilderWeb ...................... 75
Figura 3.33 - Painel de controle do framework BuilderWeb ...................................... 76
Figura 3.34 - Escolha do diretório para Criar um Projeto com o BuilderWeb ............ 77
Figura 3.35 - Atribuindo um nome ao projeto ............................................................ 78
Figura 3.36 - estrutura de arquivos do fremawork BuilderWeb ................................. 78
Figura 3.37 - Disposição dos arquivos da pasta execute .......................................... 79
Figura 3.38 - Arquivos que constituem a pasta aplication ......................................... 81
Figura 3.39 - Pacotes de classes do framework BuilderWeb .................................... 81
Figura 3.40 - Diagrama de classes do framework BuilderWeb.................................. 83
Figura 4.1 - Páginas Home ....................................................................................... 87
Figura 4.2 - Página de Notícias ................................................................................. 87
Figura 4.3 - Página de Contato ................................................................................. 88
Figura 4.4 - Página de Fotos ..................................................................................... 88
Figura 4.5 - Diagrama de classes da aplicação BuilderWebInfos ............................. 90
Figura 4.6 - Página de login ...................................................................................... 91
Figura 4.7 - Painel de controle .................................................................................. 92
Figura 4.8 - Gerenciamento da Página Home ........................................................... 92
Figura 4.9 - Gerenciamento da Página Contato ........................................................ 93
6
LISTA DE QUADRO
Quadro 1 - Comparação Entre Frameworks, Componentes e Biblioteca de Classes
(Coelho, 2002, P.24) ................................................................................ 13
7
LISTA DE SIGLAS
API Application Programming Interface - Interface de Programação de Aplicativos
AVM Actionscript Virtual Machine – Máquina Virtual Actionscript
CSS Cascading Style Sheets - Folhas de Estilo Encadeadas
DOM Document Object Model - Modelo de Objetos de Documentos
ECMA European Computer Manufacturers Association
E4X ECMAScript For XML - ECMAScript para XML
PHP Hypertext Preprocessor - Linguagem de Programação Para Gerar Hipertexto
HTML Hypertext Markup Language - Linguagem de Marcação de Hipertexto
SGML Standard Generalize Markup - linguagem de marcação generalizada padrão
URL Universal Resource Locator – Localizador Universal de Recursos
XML Extensible Markup Languagem - Linguagem Extensível de Marcação
WWW World Wide Web - Rede Mundial de Computadores
8
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
Devido ao crescimento da web, a Internet se tornou um dos maiores meios de
comunicação, tendo milhões de pessoas acessando-a todos os dias. Com isso,
houve a necessidade cada vez maior de criar aplicativos web. Nos primeiros dias da
web (entre 1990 e 1995), os sites eram formados por alguns arquivos hipertextos
ligados que apresentavam informações usando textos e um pouco de gráficos
(PRESSMAN, 2006). Neste contexto percebe-se que os sites eram criados de forma
totalmente estática, ou seja, o conteúdo deles não poderia ser alterado pelos
usuários. Hoje em dia, os sistemas Web evoluíram para ferramentas computacionais
sofisticadas, que não fornecem somente funções isoladas para o usuário final, mas
também são integradas com banco de dados coorporativos e aplicações de negócio
(PRESSMAN, 2006). Dentre essas ferramentas o software Flash é uma delas. Essa
ferramenta possibilita ao desenvolvedor a criação de produtos multimídia para Web,
ou seja, a manipulação de mídias como textos, imagens, sons, vídeos e criação de
animações. Para isso, ela utiliza como linguagem proprietária o ActionScript , que a
partir de 2007 foi criada uma nova versão, o ActionScript 3, que é uma linguagem de
script que possibilita a criação e montagem de animações, sites dinâmicos e também
a utilização dos recursos da orientação a objeto, como herança, polimorfismo,
interface, dentre outros. O ActionScript 3 possibilita aos programadores e designers
a montagem de layout , animações , exposição de dados gravados em banco de
dados através do XML, manipulação de streams utilizando o Flash mídia server,
apresentação e controle de vídeos e sons e etc.
No desenvolvimento de aplicativos dinâmicos Web, utilizando ActionScript 3, no
ambiente de trabalho da empresa X, observa-se os seguintes problemas: o número
de linhas de códigos escritos e o tempo gasto são grandes e isso acarreta prejuízo
para tal empresa, uma vez que, os prazos e cronogramas quase sempre são
excedidos acarretando em atrasos nos projetos e esses atrasos comprometem até
mesmo a empresa de realizar novos trabalhos, uma vez que os clientes exigem um
tempo de entrega muito curto. Um dos grandes problemas de se desenvolver
sistemas web é o prazo de entrega que são extremamente curtos comparando-se
com outras categorias de software. Isso é relatado por Pressman (2006) quando
11
afirma que os aplicativos web freqüentemente exibem um prazo de colocação no
mercado que pode ser questão de alguns dias ou semanas. Neste contexto, como é
possível desenvolver aplicativos web em ActionScript 3 com menos tempo de forma
a diminuir os custos? Uma possível resposta para essa pergunta pode está na
utilização de técnicas de reuso, uma vez que, as características destas técnicas são
promover redução de custo na produção de software.
No processo de desenvolvimento de sites em ActionScript pela empresa X,
percebe-se que a programação dos aplicativos são feitos de forma estruturada com
pouca ou quase nenhuma técnica de reuso, sendo que, os mesmos códigos são
reescritos em diferentes projetos sem contar com o problema da manutenção que se
torna muito complicada no momento que os diversos programadores utilizam de
técnicas e formas de programação muito distintas. Diante do cenário exposto,
observa-se que a utilização de técnicas de reuso orientado a objeto poderia provocar
uma melhora acentuada no desenvolvimento de sites dessa empresa. Segundo
Martin (1995), a utilização de técnicas de reuso na criação de software induz em um
desenvolvimento mais rápido e barato e numa qualidade mais elevada. Essas
características são reforçadas também por Sommerville (2003), segundo ele, o
software deve ser considerado um ativo e o reuso desses ativos é de fundamental
importância para aumentar o retorno de seus custos de desenvolvimento. O
paradigma da reutilização consiste na ideia de “não reiventar a roda”, ou seja, utilizar
o máximo de aterfatos de software que já existem ou que foram produzidos por
outros. Dessa forma, a reutilização desses artefatos provoca não só a diminuição do
tempo de desenvolvimento, mas também de possíveis erros que poderiam ocorrer
no software, devido ao fato desses aterfatos já terem sidos testados e utilizados
várias vezes. Existem várias técnicas de reuso como framework, componentes,
blibliotecas de classes (tokis), famílias de aplicativos, geradores de códigos, entre
outros.
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
Framework, que corresponde a um projeto de alto nível consistindo de classes
abstratas e concretas que especificam uma arquitetura para aplicações e fornece
uma granularidade de alto nível (COELHO, 2002).
Componentes de software, que são unidades vindas da composição funcional do
sistema, que possui interfaces e funcionalidades bem definidas, abstraindo um
conjunto de classes, fornecendo reutilização de baixa granularidade (COELHO,
2002).
Biblioteca de classes, que são apenas um conjunto de classes não necessariamente
relacionadas, que fornece um conjunto de serviços disponibilizado através de
interfaces públicas de suas classes, fornecendo uma reutilização de mínima
granularidade (COELHO, 2002).
O Quadro 1 expressa os resultados obtidos através desse estudo comparatvo.
13
QUADRO 1 - COMPARAÇÃO ENTRE FRAMEWORKS, COMPONENTES E BIBLIOTECA DE
CLASSES (COELHO, 2002, P.24)
Frameworks Componentes
De software
Biblioteca de
classes
Nível de abstração Funcionalidades bem
definidas
Funcionalidade bem
definidas
Não tem
funcionalidade bem
definida
Tamanho Geralmente é maior
que um componente e
é sempre maior que
uma classe
Geralmente é menor
que um framework e
maior ou igual a uma
classe
É menor que um
framework e
geralmente menor que
um componente
Grau de
especialização
É específico de um
domínio de aplicação
É específico de um
domínio de aplicação
Não é específico de
um domínio de
aplicação
Nível de
Implementação
Implementa uma
aplicação completa ou
semi-completa
Implementa parte de
uma aplicação
Geralmente
implementa parte de
uma aplicação menor
do que a utilizada por
um componente
Reuso Reusa análise, prejeto
e código
Reusa análise, projeto
e código
Reusa código
Auxílo a geração Não se aplica Pode ser usado na
geração de
frameworks
Pode ser usado na
geração de
frameworks e
componentes
Interação entre
objetos pré-definidos
Sim Sim Não
Comportamento
default
Sim Sim Não
Inversão de controle Sim Não Não
Através da análise do Quadro 1 observa-se que o framework é a técnica que
apresenta um maior grau de granularidade e possibilita ao usuário desse, uma
aplicação semi-completa no âmbito do domínio tratado por ele. Segundo Gamma
(2000, p.43) “Os frameworks estão se tornando cada vez mais comuns e
14
importantes. Eles são a maneira pela qual os sistemas orientados a objetos
conseguem a maior reutilização [...]”.
Entre tantas técnicas, fremework é a mais enquadra no problema descrito devido ao
fato de ser uma técnica que realiza a reutilização tanto de códigos como de projetos.
Segundo Silva (2000) um framework é uma estrutura de classes interrelacionadas,
que corresponde a uma implementação incompleta para um conjunto de aplicações
de um determinado domínio. Esta estrutura de classes deve ser adaptada para a
geração de aplicações específicas. Dessa forma, podem-se criar vários aplicativos
diferentes utilizando framework sendo que, esses aplicativos tenham um mesmo
domínio específico. A utilização de arterfatos de software como framework acarreta
a diminuição de custo da manutenção e aumento na produtividade, uma vez que, o
mesmo expressa um molde único de aplicativo diminuindo assim o tempo de
desenvolvimento de sites. A utilização do actionscript 3 juntamente com ferramenta
Flash para o desenvolvimento desse trabalho é justicado pelo fato, dessa ser a
ferramenta utilizada pela empresa X e também pela característica desta, de ser uma
ferramenta que possibilita a criação de produtos multimídia e de fácil utilização.
De acordo os fatos expostos anteriormente o tema deste trabalho situa-se na área
de Engenharia de software, onde são estudadas técnicas de reuso de software.
Sendo que esse tema visa a abordagem da utilização de frameworks orientados a
objetos na criação de aplicativos web em Actionscript 3.0 utilizando a ferramenta
Flash.
Este trabalho tem como objetivo geral o desenvolvimento de um framework em
Actionscript 3.0. Os objetivos específicos são:
Estudar a ferramenta Flash e a linguagem Actionscript 3.
Realizar um estudo sobre metodologias de desenvolvimento de framework.
Realizar um estudo sobre a utilização de padrões de projetos na construção
da arquitetura do framework.
Estudar as características dos sistemas multimídia.
A metodologia usada para o desenvolvimento desse trabalho consistiu em um
primeiro momento no levantamento dos materiais teóricos estudados nas disciplinas
15
de análise e projeto de softwares, assim como o conteúdo visto em técnicas de
programação , engenharia de software, arquitetura cliente e servidor e sistemas
multimídia, mais especificamente nos seguintes conceitos:
Programação orientada a objeto;
Análise e modelagem de sistemas;
Técnicas de reuso de software;
Frameworks orientados a objeto;
Padrões de projeto;
Características dos sistemas multimídias;
Arquitetura de sistemas;
Arquitetura de sistemas cliente servidor voltado para o ambiente Web;
Além do estudo de livros e documentos relacionados a ferramenta Flash e a
linguagem de programação Actionscript 3. Após a etapa de levantamento do
referencial teórico foi realizado a segunda etapa, que é análise do domínio relativo
às aplicações Web desenvolvidas em Actionscript. Esta etapa, que possui como
objetivo prover recurso para o levantamento dos requisitos necessários para o
desenvolvimento do framework, foi realizada utilizando várias aplicações
desenvolvidas com essa tecnologia. Este estudo pode ser visto na seção 3.2.
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.
A quarta etapa está relacionada com o teste do Framework BuilderWeb, que
consiste no desenvolvimento de uma aplicação, através dele com o intuito de
verificar a viabilidade do mesmo. Por fim, foi elaborada a conclusão.
O presente trabalho é constituído por cinco capítulos, os quais estão estruturados da
seguinte forma.
O capitulo 2 apresenta todo referencial teórico necessário pra o desenvolvimento
deste trabalho. Nesse capítulo podem ser encontrados conceitos e teorias sobre
16
framework, metodologia de desenvolvimento de framework, padrões de projeto, a
ferramenta Flash, a linguagem Actionscript e multimídia.
No capitulo 3 apresenta informações relativas à criação do framework BuilderWeb.
Neste capítulo é exposta a metodologia e as tecnologias utilizadas para o
desenvolvimento deste. Assim como, os requisitos levantados, o projeto de
implementação e arquitetura do framework.
O capitulo 4 trata de um estudo de caso, no qual se testa a aplicabilidade do
framework no desenvolvimento de uma aplicação.
O capitulo 5 é apresentado os resultados obtidos com o presente projeto. Revelando
as dificuldades encontradas, os futuros trabalhos e linha de pesquisa utilizando os
resultados obtido com a realização do trabalho.
O capitulo seguinte apresenta o referencial teórico.
17
2 REFERENCIAL TEÓRICO
2.1 FRAMEWORK
O framework pode ser entedido como uma aplicação genérica de um domínio
específico. Pressman (2006, p.203) define framework como “[...] uma mini-
arquitetura reusável que fornece a estrutura e o comportamento genérico para uma
família de abstrações de software, dentro de um contexto [...]”. Para Gamma (2000,
p.41) “[...] um framework é um conjunto de classes cooperantes que constroem um
projeto reutilizável para uma determinada categoria de software [...]”.
Geralmente costuma se confundir framework com blibliotecas de classes, mas há
grandes direfenças entre as duas técnicas de reuso. Gamma (2000, p.41) define
uma bliblioteca de classes como “[...] um conjunto de classes relacionadas e
reutilizáveis, projetadas para fornecer uma funcionalidade últil e de finalidade geral
[...]”. Esta técnica de reuso fornece uma reutilização em baixa granularidade, ou
seja, o desenvolvedor da aplicação utiliza apenas algumas classes isoladas de
acordo com a necessidade da aplicação (BEUTLER, 2003). Esse tipo de técnica
possibilita apenas a reutilização de código. Enquanto que o framework provê uma
reutilização em alta granularidade, por que além de possibilitar a reutilização de
código ele também disponibiliza a reutilização de projeto (BEUTLER, 2003). Os
frameworks também possibilitam uma reutilização de classe em maior escala do que
as bibliotecas. A Figura 2.1.1 mostra um diagrama de classes de uma aplicação
desenvolvida sem a utilização de técnica de reuso.
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)
A Figura 2.1.2 demostra um diagrama de classe de uma aplicação que utiliza
biblioteca de classe no seu desenvolvimento. Observa - se que na Figura 2.1.2
houve uma economia de códigos em relação à Figura 2.1.1, devido ao fato da
utilização de classes prontas contidas na biblioteca de classes, que são
representadas na Figura pela área pontilhada.
Figura 2.1.3 - Aplicação desenvolvida utilizando framework (SILVA, 2000, p.32)
A Figura 2.1.3 mostra um diagrama de classes de uma aplicação que utiliza
framework, sendo a arquitetura deste destacado pela área pontilhada, como método
de reuso. Percebe - se que esta Figura também faz reuso de códigos como na
Figura 2.1.2. Mas, no entanto, essa técnica além de possibilitar o reuso de códigos
19
ela proporciona um reuso de projeto, ou seja, as classes que a compõem o fluxo de
controle e o esqueleto da aplicação para um domínio especifico.
Uma característica importante que difere o framework de outro método de reuso, é o
fato de este inverter a ordem tradicional da reutilização de classe, da abordagem
bottom-up para top-down. O framework „chama‟ não é „chamado‟, ele fornece o fluxo
de controle da aplicação. Assim, em tempo de execução as instâncias das classes
desenvolvidas esperam ser chamadas pelas instâncias das classes do framework
(SILVA, 2000). O resultado disso é um projeto genérico que pode ser instanciado
para a construção de uma aplicação. A Figura 2.1.4 mostra a diferença entre a ótica
de reutilização de um framework em relação a uma aplicação tradicional que utiliza
biblioteca de rotinas. Observa-se que na aplicação que utiliza biblioteca de rotinas o
desenvolvedor cria toda a base, arquitetura e o fluxo de controle da aplicação
reutilizando apenas algumas rotinas específicas. Enquanto que na aplicação que
utiliza o framework, este já disponibiliza ao desenvolvedor a arquitetura e o fluxo de
controle cabendo a ele apenas a criação das rotinas específicas da aplicação
(COELHO, 2002).
Figura 2.1.4 - Inversão de controle (COELHO, 2002, p.11)
20
A criação de aplicativos através de framework traz os seguintes benefícios: a
modularidade, a reusabilidade, a extensibilidade e a inversão de controle,
fornecendo um alto nível de reutilização para aplicações de um domínio específico.
E como desvantagem um enorme esforço de desenvolvimento. O custo de
desenvolvimento de um framework é significativamente alto se comparado com de
uma aplicação específica (COELHO, 2002).
2.1.1 Classificações do framework
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 frameworks podem ser classificados segundo a abrangência de seus domínios
que pode ser de dois tipos: vertical e horizontal (BEUTLER, 2002).
Os horizontais atuam em um domínio de aplicação maior, a seguir serão citadas
algumas características desse tipo.
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)
Os verticais atuam em um domínio menor, no entanto possuem mais funcionalidade. Os verticais são mais específicos para um domínio particular. Por exemplo, um framework para executar análise estatística de dados econômicos é específico para aplicações financeiras. Um framework vertical é menos geral, mas usualmente é mais bem utilizado e provê uma solução mais completa. (BEUTLER,2002, p.23).
Existe outra maneira de se classificar um framework que é a forma na qual se
instancia aplicações a partir dele. Para Silva (2000), existem dois tipos: dirigido à
arquitetura ou dirigido a dados. Porém Johnson (1998) usa denominação caixa-
branca para framework dirigido à arquitetura e caixa preta para dirigido a dados.
21
Os frameworks caixa-branca ou também chamados de dirigidos à arquitetura são aqueles em que a aplicação é gerada a partir da criação de subclasses das classes do framework. Eles são mais difíceis de usar, pois exigem profundo conhecimento do framework e um certo esforço no desenvolvimento de código. Em resumo, o framework é reutilizado através da especialização de seus componentes. Essa forma de reutilização dos componentes do framework é chamada de reutilização baseada em herança. Os frameworks caixa-preta ou dirigidos a dados são aqueles em que as aplicações são geradas a partir de diferentes combinações de objetos, instâncias das classes do framework. Sua customização é feita através da disponibilização de um conjunto de componentes que fornecem o comportamento de aplicações específicas. Cada um desses precisa entender um protocolo particular. Todos, ou a maioria deles, são fornecidos por uma biblioteca de componentes. A interface entre os componentes pode ser definida por um protocolo, logo o usuário só precisa entender a interface externa dos mesmos. Assim, o framework é reutilizado através da instanciação de seus componentes. São mais fáceis de usar. Essa forma de reutilização dos componentes do framework é chamada de reutilização baseada em composição (BEUTLER, 02, p.25).
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.
Para Sommerville (2003, p.266 ) os frameworks podem ser classificados de três
formas distintas:
Frameworks de infra-estrutura de sistema esse frameworks são
compatíveis com o desenvolvimento das infra-estruturas de sistemas, como
comunicação, interfaces comunicação, interfaces com o usuário e
compiladores.
Frameworks de integração com middleware consistem em um conjunto
de classes de objetos-padrão e associados, que aceitam a comunicação de
componentes e a troca de informação. Entre os exemplos desse tipo de
framework estão CORBA, COM e DCOM, da Microsoft, e Java Beans.
22
Frameworks de aplicação corporativos eles se ocupam de domínios
específicos de aplicações, como telecomunicação ou sistemas financeiros.
Eles incluem o conhecimento de domínio de aplicações e são compatíveis
com o desenvolvimento de aplicações para o usuário final.
2.1.2 Comparação entre herança e composição
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.
Enquanto que a composição ocorre quando um objeto instancia um novo objeto no
intuito de obter uma funcionalidade mais complexa (GAMMA, 2000). É necessário
que esses objetos gerados pela composição possuam uma interface bem definida,
pelo fato de suas implementações não serem invisíveis para outras classes. Devido
a isso, esse método é chamado de caixa preta.
A herança e a composição possuem cada uma, características distintas. A herança
de classe é definida estaticamente em tempo de compilação. Ela também torna mais
fácil modificar a implementação que está sendo utilizada (GAMMA, 2000). Isso
ocorre devido à capacidade da classe filha poder modificar métodos da sua classe
base.
Gamma (2000), também descreve algumas desvantagens na utilização de herança
como é exposto a seguir: a herança não pode mudar as implementações herdadas
em tempo de execução, porque ela é definida em tempo de compilação. As classes
bases, freqüentemente, definem pelo menos parte da representação física das suas
subclasses. Devido a isso, a herança expõe para uma subclasse a implementação
de sua ancestral, essa capacidade é de certa forma uma desvantagem por que viola
o encapsulamento. Em alguns casos quando se possui uma estrutura de classes
23
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”.
Entretanto, “A composição de objetos é definida dinamicamente em tempo de
execução pela obtenção de referências a outros objetos através de um determinado
objeto [...]” (GAMMA, 2000, p.34).
Gamma (2000, p.34) descreve várias características que ressaltam as vantagens da
utilização de composição.
[...] A composição requer que os objetos respeitem as interfaces uns dos outros, o que por sua vez exige interfaces cuidadosamente projetadas, que não impessam você de usar um objeto com muitos outros. Porém, existe um ganho. Como os objetos são acessados exclusivamente através de suas interfaces, não ocorre a violação do encapsulamento. Qualquer objeto pode ser substituído por outro em tempo de execução, contanto que tenha o mesmo tipo. Além do mais, como a implementação de um objeto será escrito em termos de interfaces de objetos, existirão substancialmente menos dependências de implementação.
No desenvolvimento de aplicativos utilizando métodos de reutilização o ideal seria
que o programador não criasse novos componentes reutilizáveis. Deveria ser capaz
de conseguir toda a funcionalidade de que necessita simplesmente montando
componentes existentes através da composição de objetos. Mas este raramente é o
caso, porque o conjunto de componentes disponíveis nunca é exatamente rico o
bastante na prática. A reutilização por herança torna mais fácil criar novos
componentes que podem ser obtidos pela composição de componentes existentes.
Assim, a herança e a composição de objetos trabalham juntas (GAMMA, 2000).
24
2.1.3 Análise de domínio
A elaboração do projeto e a criação do framework não é uma tarefa trivial. O
desenvolvedor que o projeta precisa ter uma boa experiência e um grande
conhecimento do domínio de aplicação a qual esse atua. Para a criação de um
projeto de framework é necessário que o analista realize a análise do domínio no
qual este irá atuar. A meta dessa análise é encontrar ou criar as classes de análise
e/ou as funções e características que são amplamente aplicáveis, de modo que
possam ser reutilizadas (PRESSMAN, 2006). Segundo Silva (2000), A especificação
de um domínio de aplicação é a meta de sua reutilização no desenvolvimento de
aplicativos para este domínio, possibilita o aumento da produtividade da atividade de
desenvolvimento de software.
Pressman (2006, p.147), descreve a análise de domínio da seguinte forma:
A análise de domínio de software é a identificação, análise e especificação dos requisitos comuns de um domínio de aplicação específico tipicamente para reuso em vários projetos dentro daquele domínio de aplicação. Analise de domínio orientado a objeto é a identificação, análise e especificação de capacidades comuns, reusáveis dentro de um domínio de aplicacão específico, em termo de objetos, classes, submontagens e arcabouço comuns.
Para Arango (1991), análise de domínio é o processo de identificação e organização
de conhecimento a respeito de uma classe de problema – domínio de aplicação –
para suporte a descrição e solução desse problema.
Essa análise tem como objetivo descobrir e identificar padrões de análise
reutilizáveis, classes de análise e informação relacionada que possam ser usadas
por várias pessoas trabalhando em diversas aplicações, com características
semelhantes, mas não necessariamente as mesmas (PRESSMAN, 2006).
Silva (2000) descreve que a análise de domínio se baseia em duas premissas:
Informações reutilizáveis são específicas de um domínio. Assim a análise de
domínio recomenda que o esforço para produção de artefatos de software
reutilizáveis se concentra em domínios específicos.
25
Descrição de domínio apresenta mais estabilidade que os requisitos e
especificações de aplicações específicas.
A análise de domínio é muito importante no desenvolvimento de técnicas de reuso
como o framework porque ela é fundamental na criação de artefatos de software
reutilizáveis, devido ao fato de capturarem a funcionalidade essencial requerida por
um domínio (SILVA, 2000).
2.1.4 Fatores que influenciam no desenvolvimento de framework
Segundo Silva (2000) vários artefatos software influenciam na criação da estrutura
de classes e no ciclo de vida de um framework. Artefatos como produtos de software
existentes, produto de software produzidos a partir do framework e a experiência do
desenvolvedor do framework. A Figura 2.1.5 ilustra a participação de cada artefato
na criação da arquitetura de um framework.
Figura 2.1.5 - Ciclo de vida de um framework (SILVA, 2000, p.47)
26
Na Figura 2.1.5 as setas representam o fluxo de informações que levam à produção
da estrutura de classes do framework, bem como de aplicações sob o framework.
Percebe-se que conforme foi exposto nesta Figura 2.1.5, um framework é criado
com base em um conjunto de aplicações de um domínio específico. Esse
comentário é reforçado por Silva (2000) que descreve que um framework constitui
um modelo de um domínio de aplicações. Assim, pode ser desenvolvido a partir de
um conjunto de aplicações do domínio, que atuam como fontes de informação deste
domínio. Silva (2000) ainda afirma que a influência de um conjunto de aplicações de
um mesmo domínio possibilita que o framework produzido funcione como
generalizado de diferentes estruturas.
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.
No texto apresentado a seguir, conforme pode se observar na Figura 2.1.5, Silva
(2000, p.49) relata como se coleta mais informações sobre um domínio de atuação
de um framework através da análise das aplicações desenvolvidas por este.
A construção de um framework é sempre precedida por um procedimento de análise de domínio em que são buscadas informações do domínio tratado. Como uma abstração de uma realidade tratada, é inevitável que o framework seja incapaz de conter todas as informações do domínio. De fato, um framework consegue ser uma descrição aproximada do domínio, construída a partir das informações até então disponíveis. Idealmente a construção de aplicações sob frameworks consiste em completar ou alterar procedimentos e estruturas de dados presentes no framework. Sob esta ótica, uma aplicação gerada sob um framework não deveria incluir classes que não fossem subclasses de classes do framework. Porém, como um framework nunca é uma descrição completa de um domínio, é possível que a construção de aplicações sob um framework leve à obtenção de novos conhecimentos do domínio tratado,ver Figura 2.1.5, indisponíveis durante a construção do framework. Estas novas informações podem levar à necessidade de alterar o framework.
O ciclo de vida de um framework é diferente do ciclo de vida de aplicação
convencional devido ao fato, desse sofre várias influências de artefatos diferentes
de acordo pode ser visto na Figura 2.1.5.
27
2.1.5 Metodologias de desenvolvimento de framework
Silva (2000) descreve três metodologias de desenvolvimento de framework que são:
Projeto Dirigido Por Exemplos, Projeto dirigido por Hot Spot e a metodologia de
desenvolvimento da empresa Taligent.
2.1.5.1 Projeto Dirigido Por Exemplos
Segundo Johnson(1996) o desenvolvimento de framework para um domínio
específico é decorrente de um processo de aprendizado relativo a este, que se dá
através do estudo de aplicações já desenvolvidas anteriormente. Beutler (2002)
descreve que o processo de criação e evolução é gradativo e tenta adaptar o
framework a todas as necessidades das aplicações exemplo escolhidas. A Figura
2.1.6 ilustra como exemplos de aplicações existentes contribuem para a criação de
um framework.
Figura 2.1.6 - Projeto Dirigido Por Exemplos (BEUTLER, 2003, p.33)
Conforme se observa na Figura 2.1.6 o framework é obtido a partir da generalização
das aplicações de uma forma bottom-up, a partir do exame de exemplos concretos
(SILVA, 2000).
28
Segundo Beutler (2002, p.33), o processo de generalização visto na Figura 2.1.6
consiste na fatoração dos componentes dos exemplos em três etapas distintas
conforme é exposta a seguir:
Identificação e criação de classes abstratas: consiste em identificar o
comportamento genérico dos exemplos envolvidos e criar classes abstratas
que representem este comportamento geral, deixando para subclasses a
definição do comportamento específico.
Criação de subclasses para eliminar condicionais: O objetivo é mover
para subclasses códigos que tratam diferentes casos específicos. Assim, as
classes são fatoradas em novas subclasses (uma para cada caso
específico), eliminando as sentenças condicionais correspondentes na
classe origem.
Identificação de agregações e criação de componentes: Em muitos casos
o relacionamento de herança é usado quando na realidade se tem uma
relação de agregação, ou composição, entre os objetos. Isso resulta nas
hierarquias de classes não serem organizadas em função dos conceitos, ou
da semântica que as classes representam, dificultando tanto a compreensão
do projeto quanto a reutilização de código, o qual poderia ser encapsulado
em outros componentes.
Johnson (apud, SILVA, 2000, p.50) descreve que o processo de desenvolvimento
segundo Projeto Dirigido Por Exemplos, utiliza as etapas de análise, projeto e teste.
A forma tida como ideal para desenvolver um framework é avaliar um número
considerado de exemplo, no mínimo quatro, essas etapas são ilustradas na Figura
2.1.7:
1 - Análise do domínio:
Assimilar as abstrações já conhecidas;
29
Coletar exemplos de programas que poderiam ser desenvolvidos a partir
do framework (no mínimo, quatro);
Avaliar a adequação de cada exemplo.
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.
3 - Testar o framework usando–o para desenvolver os exemplos (implementar,
testar e avaliar cada exemplo usando na primeira etapa, utilizando para isto ,
o framework desenvolvido).
A Figura 2.1.7 apresenta as etapas do Projeto Dirigido Por Exemplos.
Figura 2.1.7 - Etapas do Projeto Dirigido Por Exemplos (SILVA, 2000, p.50)
30
2.1.5.2 Projeto dirigido por hot spot
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 a Figura 2.1.8 na etapa de identificação de classes, semelhante ao
que é feito no desenvolvimento de uma aplicação orientada a objetos, é procedida a
identificação de quais classes o framework irá possuir. O desenvolvedor do
framework, ocorre a partir das informações de especialistas do domínio, que
definem uma estrutura de classes compatível ao domínio tratado (SILVA, 2000).
Na segunda etapa que é a identificação de host spots, também com o auxílio de
especialistas do domínio, são identificados os hot spots. É preciso identificar que
31
aspectos diferem de aplicação para aplicação, e definir o grau de flexibilidade que
deve ser mantido em cada caso. Quando os aspectos que diferem entre aplicações
são os dados, a conseqüência é que classes abstratas agruparão os dados
(atributos) comuns e classes concretas, específicas para aplicações, agruparão os
dados específicos. Quando os aspectos que diferem entre aplicações são as
funções, a conseqüência é a presença nas classes além dos métodos base
(métodos completamente definidos), de métodos abstratos (em classes abstratas)
que definem apenas o protocolo do método, métodos template, que chamam outros
métodos (hook) para completar seu processamento e métodos hook, que flexibilizam
o comportamento dos métodos template (SILVA, 2000).
A terceira etapa, o projeto do framework (ou a reelaboração do projeto), ocorre após
a identificação dos hot spots. Consiste em modificar a estrutura de classes
inicialmente definida, de modo a comportar a flexibilidade requerida. Nesta etapa se
definirá o que o usuário do framework deve fazer para gerar uma aplicação – que
subclasses devem definir e a que classes deve fornecer parâmetros para a criação
de objetos, quais as combinações de objetos possíveis (SILVA, 2000).
A etapa de adaptação do framework consiste num refinamento da estrutura do
framework a partir de novas intervenções de especialistas do domínio. Se após isto
o framework for avaliado como satisfatório, estará concluída uma versão do
framework (a questão é: os hot spots definidos dão ao framework o grau de
flexibilidade necessário para gerar as aplicações requeridas?), caso contrário,
retorna-se à etapa de identificação de hot spots (SILVA, 2000).
Segundo Pree, na etapa de projeto o desenvolvimento do framework é centrado em
design patterns, o qual será analisado na seção 2.2, cuja aplicação é fundamental
para garantir flexibilidade ao framework (SILVA, 2000).
32
2.1.5.3 Metodologia de projeto da empresa Taligent
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.
Segundo Silva (2000, p.53) a metodologia de desenvolvimento de framework da
empresa Taligent consiste em quatro passos que serão descritos a seguir:
Identificar e caracterizar o domínio do problema:
Analisar o domínio e identificar os frameworks necessários (para o
desenvolvimento de aplicações), o que pode incluir frameworks
desenvolvidos e a desenvolver;
Examinar soluções existentes;
Identificar as abstrações principais;
Identificar o limite de responsabilidades do framework em
desenvolvimento(considerando que esse esteja no processo de
desenvolvimento de um framework específico);
Validar estas informações com especialistas do domínio.
Definir a arquitetura e o projeto:
33
Refinar a estrutura de classes obtida no passo anterior, centrando atenção
em como os usuários interagem com o framework:
Que classes o usuário instancia?
Que classes o usuário produz (e que métodos sobrepõe)?
Que métodos o usuário chama?
Aperfeiçoar o projeto com o uso de design patterns;
Validar estas informações com especialistas do domínio.
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").
2.2 PADRÕES DE PROJETO
Os padrões de projeto (design patterns) surgiram da observação de que diferentes
partes dos frameworks possuíam estrutura de classes semelhantes. Um padrão de
projeto corresponde a uma microarquitetura, em que são definidas as classes
envolvidas, suas responsabilidades e a forma como cooperam. “O uso de padrão de
projeto consiste em incluir a microarquitetura escolhida no sistema em
34
desenvolvimento de modo a incorporar ao sistema a funcionalidade desejada [...]”
(SILVA, 2000). “[...] Em geral, padrões de projeto auxiliam a reduzir a complexidade
em muitas situações da vida real [...] ” (PREE, 1995). Também os frameworks bem
desenvolvidos, usualmente, utilizam diversos padrões de projeto. Os padrões de
projeto, diferentemente dos frameworks que são implementados em uma linguagem
de programação, são experiências de projetos que descrevem como realizar certas
tarefas de desenvolvimento de software. Essas experiências de projeto (hierarquia
de classes, protocolos e distribuição de responsabilidades às classes) foram
observadas durante o projeto de aplicações, sendo amadurecidas com o tempo
(JOHNSON, 1996). A definição de Gamma (2000) é que os padrões de projeto são
organizações de hierarquia de classes, protocolos e distribuição de
responsabilidades entre classes, que caracterizam construções elementares de
projeto orientado a objetos. Projetistas experientes em orientação a objetos
catalogaram padrões de projeto. Isto representa um recurso valioso, pois conhecer
estes exemplos é muito útil para o desenvolvimento de frameworks. “Bons projetistas
conhecem vários padrões” (JOHNSON, 1996). No desenvolvimento de software os
programadores tendem criar programas imitando partes de programas escritos por
outros desenvolvedores. Essa imitação envolve a percepção de um padrão dentro
de um programa que pode ser adaptado. Segundo Gama(2000) A utilização de
padrões de projeto apresenta as seguintes vantagens.
Os padrões formam um vocabulário padrão, possibilitando aos projetistas se
comunicarem e documentarem projeto (GAMMA, 2000).
Reduzem a complexidade do sistema, pois identificam abstrações que estão
a um nível de abstração acima das classes e instâncias (GAMMA, 2000).
Permitem larga reutilização de arquitetura de software, mesmo que a
reutilização de algoritmos, implementações, interfaces ou projetos detalhados
não seja permitida (GAMMA, 2000).
São uma base de experiência reutilizável para a construção de software.
Fornecem um modo de reutilizar o conhecimento de projetistas experientes, e
com isso facilitam o treinamento de novos desenvolvedores (GAMMA, 2000).
35
Reduzem o tempo de aprendizado de biblioteca de classes e frameworks.
Uma vez que um usuário tenha aprendido uma biblioteca, ele poderá reutilizar
esta experiência para aprender novas bibliotecas (GAMMA, 2000).
Atuam como “blocos de construção” que podem ser utilizados para criar
aplicações mais complexas. As seguintes notações ou combinações são
aplicadas para abordagens de padrões de projeto (GAMMA, 2000).
Notação textual informal – uma descrição. Por exemplo, um resumo de
situações onde o padrão pode ser aplicado (GAMMA, 2000).
Notação textual formal, isto é, utilizando um formalismo ou uma linguagem de
programação (GAMMA, 2000).
Notação gráfica – utiliza diagramas classe/objeto e complementa as outras
notações (GAMMA, 2000).
Gamma (2000) apresenta um esquema de classificação que agrupa os padrões em
categorias que facilitam a compreensão e utilização. Este sistema divide o conjunto
de padrões em dois grupos, descritos abaixo:
Escopo – é o domínio sobre o qual o padrão pode ser aplicado. Os padrões
cujo escopo é classe, tratam sobre relacionamentos entre classes e
subclasses. O escopo objeto trata relacionamentos entre objetos individuais,
enquanto o escopo composto abrange as estruturas de objetos recursivos
(GAMMA, 2000).
Caracterização – identifica a função do padrão. Os criacionais envolvem o
processo de criação de objetos, os estruturais tratam sobre a forma em que
classes e objetos são compostos para formar estruturas de nível superior. Os
comportamentais caracterizam a forma em que classes e objetos interagem e
distribuem responsabilidades.
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
1) O nome do padrão: usado para descrever um problema, sua solução e suas
conseqüências. Assim, o vocabulário dos projetistas é ampliado, facilitando o
desenvolvimento de software.
2) O problema: descreve quando aplicar o padrão. Explica o problema em questão e
o contexto. Geralmente, pelo menos dois exemplos são apresentados para cada
padrão.
3) A solução: descreve os elementos que formam o padrão, seus relacionamentos,
responsabilidades e documentação. A solução é apresentada para um problema
genérico e uma estrutura geral.
4) As conseqüências: são os resultados e decisões que a utilização de um padrão
acarreta. A descrição dessas conseqüências é vital para a avaliação dos custos e
benefícios de um padrão e, com isso, auxiliar na decisão sobre sua utilização. As
conseqüências de um padrão incluem seu impacto sobre a flexibilidade,
portabilidade e expansibilidade do sistema.
Todas as metodologias de desenvolvimento de frameworks recomendam o uso de
padrões no desenvolvimento de frameworks, pois os mesmos têm a capacidade de
identificar, classificar e descrever soluções existentes, possibilitando o reuso destas
soluções. Através do uso de soluções semiprontas, o desenvolvedor geralmente
ganha agilidade no seu desenvolvimento, apesar do tempo necessário para o
mesmo conhecer esses padrões na medida em que se tornam disponíveis
(BEUTLER, 2002).
2.3 ACTIONSCRIPT 3
ActionScript 3 é uma linguagem de programação poderosa, orientada a objeto que
foi criada pra atender as necessidades de criação de aplicações ricas na internet.
Ela é uma linguagem que é executada na máquina do cliente, em uma arquitetura
cliente-servidor, e possibilita um excelente desempenho e facilidade de
37
desenvolvimento. O ActionScript 3.0 implementa vários conceitos e palavras-chave
orientados a objeto, como class, interface e packages, que parecerão familiares aos
programadores Java (MOOCK, 2007). É baseado na proposta ECMAScript (ECMA-
262) , que é uma linguagem de programação baseada em scripts, padronizada pela
ECMA International na especificação ECMA-262. A ECMA é o acrônimo para
European Computer Manufacturers Association. Trata-se de uma associação
fundada em 1961 dedicada à padronização de sistemas de informação. Desde 1994
passou a se denominar ECMA Internacional para refletir suas atividades
internacionais.
O Flash Player, que é constituído pela Maquina Virtual Actionscript(AVM), é o plugin
do Flash que é responsável pela portabilidade dos aplicativos desenvolvidos por
essa tecnologia em diversas plataformas como celulares e sistemas
operacionais(Windows, Macintosh e Linux) . Atualmente existem duas versões da
AVM, a primeira é denominada de AMV1 que suporta as linguagem Actionscript 1.0
e 2.0 e a segunda se chama AMV2 que suporta a linguagem Actionscript 3.0
(MOOCK, 2007).
Ao desenvolver um programa em ActionScript, antes dele ser executado pelo Flash
Player, deve ser convertido de um conjunto de linhas de código em ActionScript 3,0
para um condensado formato binário, conhecido como ActionScript bytecode, no
qual é armazenado em um recipiente binário chamado arquivo swf, ele armazena os
bytecodes e qualquer mídia embutida ou aditivos exigidos pelo programa. O
processo de conversão de um programa para ActionScript Bytecode é conhecido
como compilar o programa e é realizado pelo compilador Actionscript . O processo
de gerar um arquivo swf é conhecido como compilar o swf e é realizado pelo
compilador SWF (MOOCK, 2007).
Quando um programa desenvolvido em ActionScript, é executado, o Flash Player lê
o ActionScript Bytecode e transforma-o em códigos-máquina que são executados
pelo hardware específico em que o programa está sendo executado. Assim como
converter códigos ActionScript 3,0 para bytecode é chamado compilação, o
processo de traduzir bytecode para código-máquina para posterior execução é, de
igual modo, conhecido como compilação. Neste contexto o código ActionScript sofre
38
dois níveis de compilação. O primeiro no qual o código legível para o homem é
compilado em um formato compreensível pelo Flash Player (ActionScript bytecode).
Em seguida, o Flash Player automaticamente compila o bytecode para um formato
compreensível pelo hardware no qual está sendo executado o programa (código-
máquina) (MOOCK, 2007).
A linguagem ActionScript cresceu e desenvolveu-se desde sua introdução, há vários
anos. Em nova versão do Flash, mais palavras-chave, objetos, métodos e outros
elementos foram adicionados à linguagem. A seguir serão apresentadas algumas
funcionalidades importantes utilizados em aplicativos Flash.
Leitura de XML gerado por uma linguagem servidora.
Possibilita a Comunicação com diversas linguagens diferentes como PHP,
ASP, Java e ColdFunsion.
Suporte a um conjunto de marcas HTML.
Possibilita a utilização de estilo CSS.
Permite a criação e a manipulação de imagens de bitmap
Possibilita trabalhar com recursos multimídia através do Flash mídia Server.
Suporta a comunicação usando o ActionScript com o recipiente do Flash
Player (o sistema que contém o aplicativo Flash, como um navegador com
JavaScript, ou o aplicativo desktop).
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:
Um novo ActionScript Virtual Machine, denominada AVM2, que utiliza uma
nova instrução bytecode , fornecendo assim, melhoras significativas no
desempenho.
Um compilador moderno que se adeque melhor a linguagem ECMAScript
(ECMA 262) do que as outras versões. Uma API XML baseado no
ECMAScript para XML (E4X) especificação (ECMA-357 edition 2). E4X é uma
39
extensão à linguagem ECMAScript que acrescenta XML como um dados
nativo para linguagem.
Um evento modelo baseado no Document Object Model (DOM).
2.3.1 O display API no actionscript 3
Quando se desenvolve aplicativos usando a ferramenta Flash e a linguagem
ActionScript 3 é de fundamental importância que o programador conheça a forma
como os objetos visuais são exposto na tela assim como, as classes que
possibilitam essa visualização. No intuito de promover a criação de aplicativos
interativos e visualmente agradáveis para o usuário final a plataforma Flash fornece
uma ampla gama de ferramentas para criação. E manipulação de conteúdo gráfica.
Esta ferramenta pode ser quebrada em duas categorias gerais:
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).
O display API é projetado para produzir interfaces altamente personalizadas para o
usuário final, este método é mais utilizado quando se pretende desenvolver recursos
gráficos através de linhas de código utilizando o ActionScript 3. Enquanto que a
ferramenta de autoria Flash é projetada para desenvolver aplicativos utilizam o
conjunto de ferramentas gráficas que o software disponibiliza (MOOCK, 2007).
No ActionScript, todo conteúdo gráfico é criado e manipulado usando as classes do
display API , até mesmo aqueles criados pela ferramenta de autoria Flash. Cada
classe do API representa um tipo específico de conteúdo gráfico, por exemplo, a
classe Bitmap representa bitmaps gráficos, a classe Sprite representa gráficos
40
interativos e a classe TextField representa texto formatado. A Figura 2.3.1
apresenta a hierarquia de classes do display API.
Legendas:
Figura 2.3.1 - Hierarquia de classes do display API (MOOCK, 2007, p.459).
Na hierarquia de classes do display API do Actionscript 3 é importante destacar três
classes centrais que fornecem funcionalidades importantes para display, conforme
exposto na Figura 2.3.1, são elas: DisplayObject, responsável pela exibição dos
objetos na tela, InteractiveObject, que possibilita a capacidade de adicionar eventos
aos Objetos e DisplayObjectContainer, que permite um objeto conter outro Objeto.
Essas classes não podem ser instanciadas e possibilita uma funcionalidade abstrata
para suas subclasses. No entanto, apesar destas classes possuírem características
de classes abstratas, o ActionScript 3 não suporta classes abstratas verdadeiras(
que são classes que possuem métodos abstratos ou virtuais puros, esses métodos
41
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).
O DisplayObject é a raiz da hierarquia de classes do display, e representa o primeiro
nível de funcionalidades gráficas de exibição na tela. Todas as classes que herdam
o DisplayObject ganham um conjunto de características e atributos gráficos
fundamentais. Por exemplo, cada descendente do DisplayObject possui a
capacidade de ser posicionado, alterar o tamanho e rotacionar utilizando os
respectivas atributos x, y, width, height e rotation (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.
As subclasses de DisplayObject são Vídeo, Bitmap, Shape, MorphShape e
StaticText. Elas representam as formas mais simples de Objetos gráficos expostos
na tela. Essas classes não suportam objetos visuais aninhados e nem eventos. A
classe vídeo é responsável por apresentar streaming de vídeo. A classe BitmapData
permite criar imagens bitmap opacas ou transparentes. A classe Shape fornece
simples e leves desenhos vetoriais, As classes MorphShape e StaticText não podem
ser instanciadas pelo ActionScript elas são de uso exclusivo da ferramenta de
autoria Flash ( MOOCK, 2007).
InteractiveObject também é filha se DisplayObject e estabelece uma segunda fase
de funcionalidade no display API que é a interatividade. Todas as classes que
herdam de InteractiveObject ganham a capacidade de responder a eventos de
entrada do usuário, mouse ou teclado. A classe TextField representa uma área para
exibir e receber texto formatado, baseado em informações fornecidas pelo usuário. A
42
classe SimpleButton representa símbolos Button criados na ferramenta de autoria
Flash e também pode ser criado rapidamente utilizando código, através de uma
instancia de classe SimplesButton ( MOOCK, 2007).
DisplayObjectContainer é subclasse de InteractiveObject e forma a terceira e ultima
fase funcional do display API que tem como característica a contenção, ou seja,
todas as classes que herdam de DispalyObjectContainer tem a capacidade de conter
fisicamente qualquer outro objeto gráfico. As classe que herdam de
DisplayObjectConteiner são normalmente chamadas de containers que são
utilizados para agrupar vários objetos visuais para que eles Possam ser manipulados
como se fosse um. Por exemplo, quando um container é movido ou rotacionado ou
transformado todos os objetos que ele contém também são. Além disso, os
containers podem ser aninhados dentro de outros recipientes para criar hierarquias
de exibição de objetos (MOOCK, 2007).
A classe DisplayObjecyConteiner possui as seguintes subclasses: Sprite, MovieClip,
Stage e Loader. Cada uma Fornece um único tipo vazio de estrutura de container, à
espera de ser preenchido com o conteúdo. A classe Sprite é a peça central das
classes recipientes. Como um descendente das classes InteractiveObject e
DisplayObjectContainer, ela é perfeita para a construção de interface a partir do
zero, ou seja , a construção de interfaces através de códigos sem a utilização das
ferramentas gráficas contidas no software Flash. A classe MovieClip É um reforço
para classe Sprite, a classes MovieClip representa os conteúdos animados criados
na ferramenta de autoria Flash, ela é considerada como um Sprite com Timeline. A
classe Stage representa a área visível quando se executa um aplicativo Flash, ou
seja, é a região visível dentro das fronteiras da janela do Navegador. A classe
Loader é utilizada para carrega conteúdos gráficos externos , como fotos e arquivos
swf ( MOOCK, 2007).
O conjunto de classes que formam o display API é de fundamental relevância para o
desenvolvimento deste trabalho uma vez que, essas classe são peças importantes
para o desenvolvimento do framework BuilderWeb.
43
2.3.2 Comunicação com o servidor
No desenvolvimento de sites com conteúdo dinâmico e interativos em ActionScript
é necessário que os usuários possam alterar os conteúdos e os dados contidos nos
aplicativos web. No entanto o ActionScript não possui recursos que possibilitem o
acesso direto ao banco, porque o Flash é carregado e executado dentro da máquina
do cliente. Dessa forma, não é possível uma aplicação que execute na máquina do
cliente acessar diretamente uma base de dados hospedada em um servidor. Para
que o Flash possa alterar e ter acesso as informações de banco de dados é
necessário que ele comunique com uma linguagem que é executada no lado do
servidor, essa linguagem pode ser, por exemplo, o PHP, ASP ou Java, elas
possuem a capacidade de manipular e alterar a base de dados hospedada no
servidor.
O ActionScript 3 pode se comunicar com o servidor das seguintes formas:
Através de um conjunto de variáveis do tipo String enviados pelo servidor.
Através de XML, essa técnica consiste em disponibilizar os dados em formato
de texto em uma estrutura de árvore.
Através do Flash Remoting, consiste em colocar o servidor a disponibilizar
objetos, que são consumidos e convertidos automaticamente para a
linguagem do lado do cliente. Por exemplo, o ActionScript pode utilizar um
recurso de um objeto PHP apenas fazendo uma chamada a esse objeto.
Dentre esses métodos de comunicação citados acima o utilizado pela empresa X é
o XML, método pelo qual o estudo desse trabalho será dirigido. O XML - Extensible
Markup languagem (linguagem de marcação extensível) “[...] é uma linguagem de
marcação da web para intercambio de dados e baseia-se na especificacão descrita
pela Word Wide Web consortiun (W3C) [...]” (PITTS-MOULTIS, 2000, p.28). Ela é
derivada do SGML – Standard Generalize Markup Language (linguagem de
marcação generalizada padrão), linguagens como essas vão além de uma simples
linguagem de formatação, a seguir serão citadas as principais características que o
XML possui:
44
“O conteúdo é separado da formatação. A formatação é normalmente
tratada por meio de folhas de estilo que são instruções distintas que
descrevem como várias seções do documento devem ser formatadas [...]”
(PITTS-MOULTIS, 2000, p.6).
As linguagens de marcação descrevem a estrutura do texto dentro do
documento. Regras explícitas criam uma estrutura bem-definida, quase uma
estrutura em forma de árvore ou delineada a partir da qual as folhas de
estilo funcionam para exibir as informações (PITTS-MOULTIS, 2000).
“Assim que um determinado elemento for identificado, as mudanças de
formatação afetam todas as ocorrências desse elemento [...]” ( PITTS-
MOULTIS, 2000, p.6).
“O XML oferece compatibilidade de plataforma entre sistemas, navegador e
aplicativos externos [...]” (PITTS-MOULTIS, 2000, p.76).
“Os documentos XML podem ser usados em outros lugares que não sejam
apenas a web e podem ser lidos dentro de ambientes SGML existentes [...]”
(PITTS-MOULTIS, 2000, p.76).
“Os documentos XML descarregam informações para o cliente, reduzindo
conseqüentemente a carga nos servidores [...]” (PITTS-MOULTIS, 2000,
p.76).
“O XML se baseia em regras de sintaxe rígidas, forçando os documentos a
ser mais legível e a seguir detreminados padrões de projeto. Há poucos
caminhos alternativos [...]” (PITTS-MOULTIS, 2000, p.76).
O XML é utilizado pra prover essa comunicação entre diferentes linguagens de
programação em um ambiente web, porque ele especifica uma maneira padrão de
representar dados, possibilita uma incrivelmente flexível e grande portabilidade,
provendo que diferentes tipos de software trabalhem em conjunto, via intermédio
dele.
A utilização do XML em conjunto com linguagem que executam no cliente como
ActionScript possibilita a criação de páginas interativas em tempo de execução.
Devido ao fato que, quando a máquina do cliente baixa o arquivo XML do servidor
45
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:
O acesso não-linear: a informação é rapidamente acessível de forma não-
linear, ou seja, usuário não fica preso a uma seqüência de tempo, como o
leitor de um livro, o ouvinte de uma palestra ou o espectador de um filme.
A interatividade: a situação de usuário diante do computador pode não ser a
de espectador passivo, mas de participante de uma atividade.
A integração com programas aplicativos: dependendo do caso, o
computador pode executar cálculos, pesquisas em base de dados e outras
tarefas normais de qualquer programa aplicativo (PÁDUA FILHO, 2000, p.3 ).
O uso do computador contribui para o usuário extrair um maior potencial dos
recursos multimídia. Possibilitando a este uma interação de forma mais profunda do
que, por exemplo, apertar um botão de um aparelho de som ou vídeo. Os programas
que permitem a interação do computador com o usuário são chamados de produtos
multimídias (PÁDUA FILHO, 2000). Eles possibilitam diferentes graus de interação,
tais como:
Percorrer material audiovisual de forma não-linear (PÁDUA FILHO, 2000).
Consultar, pesquisar e atualizar material armazenado em base de dados
audiovisual (PÁDUA FILHO, 2000).
46
Gerar o material audiovisual em tempo real, seja a partir de suas solicitações
e respostas , seja a partir de dados recebidos de instrumentos físicos (PÁDUA
FILHO, 2000).
Efetuar simulações de sistemas físicos, como maior grau de realismo (PÁDUA
FILHO, 2000).
2.4.1 Tipos de produtos multimídias
Segundo Pádua Filho (2000) a classificação dos produtos multimídia ocorre de
acordo com o grau de interatividade, podendo dessa forma distinguir as seguintes
categorias:
Título;
Aplicativos;
Sítios ou sites.
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.
Os títulos lineares, a apresentação do material segue ordem predeterminada e seqüencial, de forma semelhante a dos reprodutores de vídeo e áudio. O usuário final tem alguns poucos controles, semelhante aos dos equipamentos analógicos, tais como avanço, retrocesso, avanço rápido etc. Os títulos lineares concorrem com as apresentações com as apresentações em “audiovisual”, para seqüências de imagens estáticas, e com os vídeos, para apresentações com animações. No entanto, os títulos hipermídia a ordem de visualização é determinada pelo usuário final, que disporá de controle para navegação não seqüencial. Estes controles são indicações visuais, geralmente representadas por sinais gráficos, como texto sublinhado ou imitações de botões, que permitem seguir referências, pesquisarem assuntos e utilizar índices, além de se abrir mão dos controles lineares normais (PÁDUA FILHO, 2000, p. 7).
Os aplicativos multimídia processam o próprio material de multimídia, geralmente em
tempo real. A multimídia deixa de ser apenas um recurso de interface, para ser o
objeto central do próprio aplicativo (PÁDUA FILHO, 2000).
47
São exemplos dessa categoria de multimídia:
Ferramentas de multimídia, utilizadas para a produção dos diversos tipos
de material de multimídia;
Sistemas de visualização técnica e científica, usados em aplicações
como arquitetura e de engenharia (maquetes eletrônicos), imagens médicas
e representação visual de fenômenos complexos;
Simuladores de tempo real, como, por exemplo, simuladores de
automóveis, aviões, processos industrial etc (PÁDUA FILHO, 2000, p. 11).
Para Pádua Filho (2000), sítio ou site é um título de hipermídia colocado em um
servidor da WWW e visualizado remotamente, em uma máquina cliente, através de
um programa navegador (browser), como o Microsoft Internet Explorer ou Nestscape
Communicator. Os sítios são compostos de páginas, escritas na linguagem HTML;
em geral existe uma página inicial, através da qual os usuários entram normalmente
no sitio. As páginas de sítio possuem um conjunto de material multimídia como
imagens, sons, animações, modelos tridimensionais etc.
A maioria dos navegadores foram produzidos de forma a aceitarem extensões
chamadas plug-ins que podem ser baixados facilmente nos sites das empresas
responsáveis, através deles é possível a exposição de conteúdos multimídias
produzidos por diversas ferramentas como, por exemplo, Flash e Flex , que é um
software desenvolvido pela a Abode similar ao Flash.
O capitulo seguinte apresenta a descrição do framework BuilderWeb.
48
3 FRAMEWORK BUILDERWEB
O BuilderWeb é um framework orientado a objeto projetado para auxiliar e facilitar o
desenvolvimento de aplicativos web que utilizam a ferramenta Flash e a linguagem
Actionsctipt 3. Ele tem Como objetivo a redução de custos no desenvolvimento de
aplicativos. Isso implica na redução do tempo de criação, número de linhas de
código criadas pelo programador e facilidade na manutenção dos aplicativos.
A metodologia utilizada para o desenvolvimento do framework BuilderWeb, conforme
pode ser visto na seção 2.1.5.1, foi o Projeto Dirigido Por Exemplos. Essa
metodologia consiste na criação de framework através de um estudo de aplicações
que já foram desenvolvidas anteriormente. A seção 3.2 revela o estudos de algumas
aplicações que serviram de base para a implementação do framework BuilderWeb
(BEUTLER, 2003).
Para a construção do framework BuilderWeb foi necessário os seguintes recursos de
sofware:
A ferramenta de autoria Flash CS3;
A linguagem de programação ActionScript 3;
API Javascript do Flash CS3;
XML;
A linguagem de marcação de texto HTML;
A linguagem Javascript;
A ferramenta Dreaweaver CS3;
Flash Player 9;
O software Extension Manager
A ferramenta case Jude.
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
com ferramenta de autoria Flash. Na seção 3.1 será descritas algumas
características e recursos da API Javascript.
3.1 API JAVASCRIPT DO FLASH CS3
Os desenvolvedores Flash são acostumados a trabalhar com aplicações que utilizam
o ActionScript, que permite ao usuário criar scripts que executam em tempo de
execução no Flash Player. O Flash JavaScript Application Programming Interface
(API JavaScript) descritas neste documento é um recurso Complementar que
permite ao usuário criar scripts que são executados no Ambiente de autoria da
ferramenta Flash. No entanto, esta funcionalidade é diferente da linguagem
ActionScript, que permite ao usuário escrever scripts para executar ações no Flash
Player (isto é, enquanto um arquivo SWF está sendo executado). Esta
funcionalidade também é diferente dos comandos JavaScript que pode-se usar em
páginas exibidas em um navegador web. Usando o Javascript API, o usuário pode
escrever scripts de aplicação Flash para ajudar a automatizar funcionalidades
utilizadas pela ferramenta de autoria Flash. Por exemplo, como ocorre no próprio
framework BiulderWeb que possibilita a criação automática de arquivos “.fla “,”.as” e
de arquivos de projetos Flash ( ADOBE, 2008).
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).
3.2 ANÁLISE DOS APLICATIVOS DESENVOLVIDOS COM A
FERRAMENTA FLASH UTILIZANDO ACTIONSCRIPT
Nesta seção será feita uma análise de algumas aplicacões desenvolvidas na
empresa X utilizando a ferramenta Flash e a linguagem Actionscript, com o intuito
de prover o levantamento dos requisitos comuns dessas, que serviram de requisitos
para a criação do framework BiulderWeb. Segundo JOHNSON (1996) uma das
etapas para se desenvolver um framework consiste em coletar exemplos de
programas, ou seja, no caso deste trabalho serão usados exemplos de sites. A
explicação para analisar quatro aplicações é decorrente da metodologia seguida
para o desenvolvimnto do framework que é Projeto Dirigido Por Exemplos. De
acordo com essa metodologia, para que se possa construir um framework é
necessário ser analisado no mínimo quatro aplicações distintas. A seguir serão
analisadas quatro aplicações desenvolvidas com a ferramentra Flash e a linguagem
Actionscipt.
3.2.1 Projeto Metropolitan
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.
Figura 3.1 - Página de introdução do site Metropolitan
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
Figura 3.2 - Página home do site Metropolitan
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
da aplicação são requisitadas uma única vez e sendo processadas na própria
máquina do cliente. Como por exemplo as letras que aparecem na ÁREA 2: ao se
clicar em uma delas é realizada uma pesquisa no XML na própria máquina do cliente
retornado as modelos que iniciam com esse letra. Ainda é atribuída uma mídia de
vídeo a cada modelo conforme é apresentado na Figura 3.3.
Figura 3.3 - Página home mídia de vídeo.
A Figura 3.4, apresenta a página da candidatura em que novos usuários podem se
solicitar fazer parte da equipe Metropolitan. Ela funciona da seguinte forma: os
usuários cadastram os dados pessoais, incluindo fotos, para serem avaliados pela
equipe. Os dados no formato texto são enviados via POST para o arquivo PHP,
enquanto que as imagens são envidas de forma diferente através da classe nativa
da linguagem Actionscript, denominada FileReference. Ela fornece um meio para
fazer upload e download de arquivos entre o cliente e servidor. Um sistema
operacional de caixa de diálogo solicita ao usuário selecionar um arquivo para fazer
upload ou um local para download. Cada objeto FileReference, refere-se a um único
arquivo no disco rígido do usuário e possui propriedades como informações sobre o
tamanho do arquivo, tipo, nome, data de criação, data de modificação. É bom
54
ressaltar que, tanto o título como o texto de descrição da página são totalmente
administráveis.
Figura 3.4 - Página de candidatura do site Metropolintan
A Figura 3.5, representa a página relativa às informações da empresa sendo
constituída basicamente de título e texto possuindo o conteúdo totalmente
administrável. Essas páginas possuem subseções, são elas: Presentation, Key dates
and history e Interview with Michel levaton. A seção presentation possui uma
descrição sobre a intenção da empresa como pode ser observado na Figura 3.5. A
seção Key dates and history apresenta a história da empresa Metropolitan ao longo
dos anos. Por fim, a seção Interview with mechel levaton que é uma seção
constituída de título e texto, observe Figura 3.7.
55
Figura 3.5 - Página de informações da empresa
Figura 3.6 - Seção key dates and history
56
Figura 3.7 - Seção Interview with Michel levaton
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
Figura 3.8 - Página de contatos
É importante ressaltar que, os aplicativos criados em Flash possuem a característica
de serem animados dando um ar de sofisticação e modernidade aos web sites. Essa
é uma questão que se deve levar em conta ao se criar aplicativos em Flash devido a
facilidade que essa ferramenta proporciona na criação e gerenciamento de
animações. Uma outra característica importante da ferramenta é que ela consegue
integrar de forma simples tanto o trabalho do profissional de design quanto o do
programador.
A Figura 3.9 apresentará a hierarquia de navegação dos arquivos swf do site
Metropolitan.
58
Figura 3.9 - A hierarquia de navegação dos arquivos swf do site Metropolitan
Como pode ser observado na Figura 3.9 é apresentada a hierarquia de navegação
do web site Metropolitan. Em um aplicativo desenvolvido em Flash o carregamento
das paginas assim como a troca delas é feita de uma forma hierárquica onde
arquivos swf vão sendo englobados em outros arquivos construindo, dessa forma,
uma estrutura de árvore, como se observa na figura 3.9. Onde cada objeto swf
representa uma página da aplicação Metropolitan. Para se obter mais informações
sobre a disposição dos objetos gráficos da ferramenta Flash, consulte a seção 2.3.1.
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
3.2.2 Projeto Sterslager
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.
Figura 3.10 - Página Home
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.
Figura 3.11 - Página Recepten
61
Figura 3.12 - Página Thema`s
Figura 3.13 - Página Nuttige Tips
62
Figura 3.14 - Página Contact
Analisando estas páginas percebe-se que todas possuem um título seguido de um
texto contendo uma descrição de cada seção. A estrutura desse site é semelhante a
do Metropolitan. Tendo o Preloader.swf como arquivo primordial responsável pelo
pré carregamento da página. Chamando inicialmente o arquivo Base, no qual possui
o menu responsável pela navegação do mesmo. A seção Recepten é constituída por
um texto descritivo e uma galeria de receitas construída através de dados recebidos
do banco XML. Nessa galeria o usuário pode realizar um download de receita ou
então pesquisa algum prato específico. Essa pesquisa ocorre em conjunto com PHP
que retorna um XML de resposta para o Flash. A seção Thema`s é constituída
basicamente de texto, foto e animações. Ela expõe alguns pratos de uma
determinada data festiva. A seção Contact é formada por um formulário que tem
como função enviar email para o proprietário do site.
Esse projeto além de possuir uma aplicação em PHP no qual o administrador do
site pode promover a manutenção do conteúdo deste, ele possui uma área restrita
aos clientes do Sterslager possui. O usuário pode visualizar todos os clientes que o
63
Sterslager, na seção de Sterlager in uw buurt, conforme pode ser visualizada na
Figura 3.15.
Figura 3.15 - Página De Sterslager in uw buurt
Na página de Sterlager in uw buurt são apresentados os dados da empresa cliente
do Sterslager, além de algumas fotos que o cliente pode fazer upload para divulgar
a empresa. Para que o cliente tenha acesso a essa área restrita é necessário que o
administrador do site crie uma conta para ele, através da aplicação em PHP. Após
isso, o cliente receberá por email o login e a senha. O cliente pode acessar sua
conta digitando o login e a senha na página leden, conforme mostra a Figura 3.16.
64
Figura 3.16 - página Leden
Se o login e senha estiverem corretos, a aplicação carregará a página Administrator,
apresentada na Figura 3.18. Nessa página o cliente pode alterar todos os dados
relativos à sua conta, como por exemplo, alterar as fotos da sua empresa, texto de
descrição, entederço, e-mail e etc.
65
Figura 3.17 - Página Administrator
A Figura 3.18 apresenta a hierarquia de navegação dos arquivos swf do site
Sterslager. Semelhante ao que ocorre na figura 3.9, em que é representada a
hierarquia de navegação do site Metropolitan. Cada arquivo swf representa uma
página da aplicação. O Preloader e Base possuem funcionalidades idênticas aos
arquivos de mesmo nome encontrados no site Metropolitan. Os arquivos que se
encontram no terceiro nível hierárquico representam as diferentes páginas que serão
carregadas e contidas no arquivo Base.swf.
66
Figura 3.18 - Hierarquia de navegação do site Sterslager
3.2.3 Projeto Remmicom
Remmicom Packaging é uma empresa especializada em venda de caixas
personalizadas e pode ser encontrado no seguinte endereço web
http://www.remmicom.com. O web site desenvolvido para essa empresa é
constituído por cinco seções que são: Home, Ons Bedrif, Productinfo, contact,
Personaliseer doos. Todas as seções, exceto a Personaliseer doos, são constituídas
basicamente de texto, imagens, objetos gráficos e animações. A seção
Personaliseer doos propicia ao usuário uma experiência mais interativa. Neta seção
é possível personalizar uma caixa e enviá-la para o email da empresa Remmicom.
O conteúdo desse site é administrável e pode ser alterado através da aplicação
desenvolvida em PHP. As Figuras 3.19, 3.20, 3.21, 3.22, 3.23 e 3.24 apresentam as
páginas desse site. Como ocorre no projeto Metropolitan a página intro ( ver Figura
3.19) é a seção em que se escolhe a língua que aparecerá no site. Na Figura 3.22,
apresenta a seção Productinfo, na qual possui uma galeria de fotos, comum em
todos os projetos analisados nesse trabalho, bem como, a seção de contato que
contém um formulário para envio de e-mail. A Figura 3.24, mostra a página
Personaliseer doos na qual possui uma caixa 3d e ferramentas de edição. Através
delas é possível inserir textos, imagens, e alterar a cor da caixa. Dessa maneira o
usuário possui diversas possibilidades de personalizar a caixa.
67
Figura 3.19 - Página de introdução remmmicom
Figura 3.20 - Página home
68
Figura 3.21 - Página Ons Bedrif
Figura 3.22 - Páginas Productinfo
69
Figura 3.23 - Página de contact
Figura 3.24 - Página Personaliseer doos
70
A Figura 3.25 apresenta a hierarquia de navegação dos arquivos swf do site
Remmicom.
Figura 3.25 - Hierarquia de navegação do site remmicom
3.2.4 Projeto IEP
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
cada curso está associado a um pop-up, que contém informações relativas ao
mesmo. A seção Faleconosco é constituída por um formulário que envia informações
para o email do instituto.
A hierarquia de navegação deste projeto é apresentada na Figura 3.30. Percebe-se
que ela possui os arquivos Preloader e base como todos os outros projetos descritos
nessa seção. Observa se também que todas as oito seções possuem o mesmo nível
hierárquico, sendo dessa forma, todas carregadas e contidas no arquivo base.
Figura 3.26 - Página base
72
Figura 3.27 - Página de Fotos
Figura 3.28 - Página de Cursos
73
Figura 3.29 - Página Faleconosco
Figura 3.30 - Hierarquia de navegação do site Intituto IEP
3.3 ANÁLISE DE DOMÍNIO
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
usadas por várias pessoas trabalhando em aplicações semelhantes, mas não
necessariamente as mesmas.
A partir da análise das aplicações apresentadas na seção 3.2 houve um
levantamento dos requisitos comuns entre elas. Na qual serviram como requisitos
base para a construção do framework BuilderWeb. A seguir serão apresentados os
principais requisitos que deveriam ser atendidos.
O framework deve possibilitar a criação de uma hierarquia de navegação de
forma fácil é rápida.
Possibilita leitura e manuseio de dados provenientes do servidor através dos
arquivos XML.
Agilizar a criação e gerenciamento de animações.
Deve ser possível a inserção de diferentes tipos de mídias nos objetos, tais
como texto, sons e vídeos.
3.4 ESTRUTURA E PROJETO DE IMPLEMENTAÇÃO DO
FRAMEWORK BUILDERWEB
Nesta seção será apresentada toda a estrutura e como foi implementado o
framework BuilderWeb.
3.4.1 Estrutura do painel de controle do BuilderWeb
O framework BuilderWeb, conforme foi descrito anteriormente, é composto por um
painel de controle, que foi desenvolvido utilizando Actionscript 3 e a API Javascript
do Flash. Através desse painel de controle, o usuário do framework pode criar um
novo projeto, executar ou abrir um projeto já existente. Tomando como base os
requisitos levantados na seção 3.3 a Figura 3.31 apresenta o diagrama de caso de
uso do framework. No qual apresenta de forma geral a interação do desenvolvedor
com o framework
75
Figura 3.31 - Diagrama de casos de uso do framework BuilderWeb
A partir do estudo e análise do diagrama de caso pode ser criado o diagrama de
classes do painel de controle do framework BuilderWeb. Conforme pode ser visto na
Figura 3.32.
Figura 3.32 - Diagrama de classes do painel de controle BuilderWeb
76
Essas três classes apresentadas na Figura 3.32 são responsáveis pelo
gerenciamento do framework. A classe ControllPanel é a representação visual do
painel de controle. Ela estende a classe Sprite que é uma classe nativa do
Actionscript 3. Sendo que esta classe possui a capacidade de exibir objetos na tela,
adicionar eventos e conter outros objetos. Para maiores informações sobre a classe
Sprite ver seção 2.3.1. A classe ControllPanel é a representação visual do painel,
devido a capacidade que a ferramenta Flash possui de adicionar uma classe ao
arquivo fla, sendo que, essa classe herde de Sprite ou de alguma de suas classes
filhas. A Figura 3.33 revela o layout do painel de controle BuilderWeb e também
mostra como uma classe pode está diretamente relacionada com um arquivo fla.
Figura 3.33 - Painel de controle do framework BuilderWeb
A classe ControllPanel possui três métodos de fundamental importância, sendo eles:
opens, createProject e executes. O método createProject é responsável por criar
toda a estrutura de pastas e arquivos do framework BuilderWeb, sendo o usuário o
77
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.
Figura 3.34 - Escolha do diretório para Criar um Projeto com o BuilderWeb
78
Figura 3.35 - Atribuindo um nome ao projeto
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.
Figura 3.36 - estrutura de arquivos do fremawork 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
Figura 3.37 - Disposição dos arquivos da pasta execute
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.
Na pasta navigate possui um arquivo XML, no qual é responsável pela criação da
hierarquia de navegação do site. O arquivo XML possui a seguinte estrutura:
<?XML version="1.0" encoding="utf-8"?>
<aplication>
<page swf="preloader" >
<page swf="base">
</page>
</page>
</aplication>
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.
Prosseguindo com a análise da classe ControllPanel, o método opens é acionado
quando o botão Abrir Projeto é pressionado. Este método abre um pop-up
semelhante ao da Figura 3.34 no qual o usuário escolhe qual projeto ele que abrir.
Feito isso, é instanciado um objeto da classe InfosXMLPages. Essa classe possui
como principal função a leitura do XML de navegação e através dessa leitura é
criado todos os arquivos .flas e .as(os arquivos .as são as classes do Flash) relativos
a cada página e adicionando-os em um arquivo de projeto do Flash. Além disso,
essa classe cria outra classe em tempo execução que faz parte da arquitetura de
classes do framework. Essa classe é criada através do método
WriteClassDataXMLSystem que cria a classe DataXMLSystem. Esta classe possui
informações a respeito do arquivo XML de navegação como o nome das páginas,
dos arquivos swf e do relacionamento de pai e filho entre as páginas. Os arquivos
.fla e .as são criados através dos métodos callJsfl que realiza uma chamada a
função init, pertencente ao arquivo project.jsfl. Antes que um objeto da classe
InfosXMLPage leia um arquivo XML é necessário que este arquivo seja carregado e
isso é feito pela classe LoadXML. Essa classe tem como única função a leitura de
arquivo XML externo. Ela possui um evento que é disparado logo após um arquivo
XML ser totalmente carregado e nome desse evento é LOAD_COMPLETE e ele
atribui o XML já carregado atributo da própria classe denominado de dataXML.
81
O método execute da classe ControllPanel é responsável por compilar todo projeto
gerando assim todos os arquivos swf do mesmo direcionando os para a pasta
executes.
3.4.2 Arquitetura do framework builderweb
Como foi visto anteriormente todas as classes e pacotes que constituem a
arquitetura do framework BuilderWeb está localizada na pasta aplication. A Figura
3.38 apresenta os arquivos que constituem essa pasta.
Figura 3.38 - Arquivos que constituem a pasta aplication
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.
Figura 3.39 - Pacotes de classes do framework BuilderWeb
A primeira versão do framework BuilderWeb é constituído de seis pacotes , sendo
que em cada um desses as classes são agrupadas de acordo com suas
características e funcionalidades. O pacote classLoader é responsável por
armazenar todas as classes que carregam arquivos externos como imagens e
arquivos swf. O Pacote communication possui classes relativas a comunicação com
o servidor, como por exemplo classe que realiza leitura de XML e classe que enviam
82
e recebem dados do servidor. O pacote data possui a classe DataXMLSystem que
é uma classe que armazena todos os dados a respeito do XML de navegação e
também, neste pacote possui a classe PrivateClass. O pacote expressInstallation
contém arquivos .as os quais possuem a função de atualizar o Flash player para
uma versão que suporte aplicativos desenvolvidos em Actionscript 3. O pacote
pages contém todas as classes relativas às páginas que site possui, ou seja, todas
as páginas que foram criadas no XML de navegação as suas respectivas classes
serão armazenadas neste pacote. O pacote control possui todos os objetos visuais
que realizam um controle de ações. Como por exemplo, a classe de menu, classe
que define um comportamento de uma determinada animação e controle de
execução do timeline.
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
Figura 3.40 - Diagrama de classes do framework BuilderWeb
84
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 DataXMLSystem possui todas as informações contidas no XML de
navegação. Devido ao fato dos dados contidos nesse XML serem únicos e globais
para todas a aplicação, não há necessidade alguma de existir mais de um objeto
dessa classe. Devido a isso, a classe DataXMLSystem implementa o padrão de
projeto Singleton. Segundo Gamma (2000) esse padrão “[...] garante que uma
classe tenha somente uma instância e fornece um ponto global de acesso para ela
[...]”. O Actionscript 3 não suporta construtores privados. Dessa forma, para que o
padrão Singleton seja implementado foi necessário criar a classe PrivateClasse.
Essa classe funcionará como um método privado independendo que outras classes
instanciem um objeto da classe DataXMLSystem (SANDERS,2007).
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
A arquitetura do BuilderWeb possui Interface denominada de IStructureObj que
juntamente com a classe StructureMenu são responsável por criar e definir a
estrutura visual do menu de navegação da classe Base. Essa duas classes
combinadas com StructureMenuUser implementam o padrão de projeto Strategy.
Segundo Gamma(2000) esse padrão “[...] define uma família de algoritmos,
encapsular cada um deles e fazê-los intercambiáveis. O Strategy permite que
algoritmos varie independente dos clientes que utilizam [...]”. A classe Base delega a
funcionalidade de criação do menu para um objeto do tipo IStructureObj que pode
ser tanto StructureMenu , que define um estrutura de menu padrão para o aplicativo ,
ou uma StructureMenuUser que específica uma estrutura definida pelo usuário do
framework. Esse padrão pode ser utilizado tanto para criação de estrutura visual
para o Menu como para criação de estruturas de galerias e listagem de conteúdo.
Na arquitetura do framework existem mais três classes que possibilitam a criação e
o arranjo dos objetos visuais em uma hierarquia de árvore. São elas:
ComponetContainer, CompositeContainer e ItenContainer. Essa três classes
implementam o padrão de projeto Composite . Esse padrão segundo Gamma (2000)
“[...] Compõe objetos em estrutura de árvore para representar hierarquia do tipo todo
parte. O Composite permite que os clientes tratem objetos individuais e composições
de objetos de maneira uniforme [...]”. Ele é responsável por definir a estrutura de
todo e parte do menu de navegação, onde se tem o container menu que possui
vários itensMenu. Esse padrão pode ser usado na criação de galerias em geral e
listagens de conteúdo.
86
4 ESTUDO DE CASO
Este capítulo apresenta uma aplicação desenvolvida através do framework
Builderweb, denominada BuilderWebInfos. O desenvolvimento dessa aplicação tem
como objetivo apresentar as funcionalidades e recurso que o framework possui.
Dessa forma, essa aplicação é constituída por quatro seções sendo elas: home,
fotos, notícias e contatos. De forma que, o conteúdo apresentado nessas seções, é
gerenciado por uma aplicação desenvolvida em php. Após se criar um projeto com o
framework, um dos primeiros passos que o desenvolvedor deve realizar é editar o
XML de navegação. Através dele todas as páginas que o site possui serão criadas.
A seguir será exposto o XML de navegação do aplicativo descrito neste capítulo.
<?XML version="1.0" encoding="utf-8"?>
<aplication>
<page swf="preloader" >
<page swf="base">
<page swf="Home"/>
<page swf="Fotos"/>
<page swf="Notícias"/>
<page swf="contato"/>
</page>
</page>
</aplication>
Através da análise do XML pode-se definir a quantidade e quais serão as páginas
que a aplicação pussui. Antes de abrir o projeto o usuário pode determinar algumas
características genéricas para as páginas. Isso é possível através do arquivo
page.fla contido na pasta templates. Com isso, qualquer alteração ocorrida nesse
arquivo antes do projeto ser aberto acarretará em uma alteração em todas as
páginas desse aplicativo. As Figuras 4.1, 4.2, 4.3 e 4.4 representam as telas Home,
Notícias, Contatos e Fotos respectivamente.
87
Figura 4.1 - Páginas Home
Figura 4.2 - Página de Notícias
88
Figura 4.3 - Página de Contato
Figura 4.4 - Página de Fotos
89
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
Figura 4.5 - Diagrama de classes da aplicação BuilderWebInfos
91
Nota-se que, a estrutura de classes da aplicação BuilderWebInfos é semelhante à
estrutura de classes apresentada na Figura 3.40 . Porém, a estrutura de classes da
Figura 4.5 possui um número de classes maior, sendo que essas classes a mais são
desenvolvidas pelo usuário do framework. As classes a mais criadas pelo
desenvolvedor do aplicativo são: ItenNoticia, ImagemThumb, FotoGrande e
ImagemIntro. A classe ItenNoticia representa cada item da listagem das notícias da
Página de Notícias. A classe ImagemThumb representa cada miniatura da galeria de
fotos exposta na seção fotos. A classe FotoGrande representa a foto que será
carregada em uma escala maior, ao clicar na miniatura da mesma. A classe
ImagemIntro representa a foto ilustrativa que será carregada na página Home.
Observa-se que, para essa aplicação, o framework promoveu um bom nível de
reutilização, devido ao fato, do desenvolvedor ter criado poucas classes e utilizado
grande parte das classes do framework para construir a aplicação. A seguir as
Figuras 4.6, 4.7, 4.8 e 4.9 apresentaram as telas da aplicação desenvolvida em php
que promove o gerenciamento do conteúdo. É importante salientar que, detalhes
sobre a aplicação em php não fazem parte do escopo desse trabalho e todas as
informações relativas a essa aplicação terão apenas um caráter ilustrativo.
Figura 4.6 - Página de login
92
Figura 4.7 - Painel de controle
Figura 4.8 - Gerenciamento da Página Home
93
Figura 4.9 - Gerenciamento da Página Contato
Observa-se que, para o usuário realizar o gerenciamento do conteúdo é necessário
que ele seja autenticado. Isso ocorre através de um login e senha (ver Figura 4.6).
Após o usuário realizar o login é carregada a página Painel de controle (Figura 4.7),
na qual o usuário tem uma visão de todas as seções que o site possui. Nessa
Página o usuário pode escolher qual seção da aplicação em flash ele quer alterar.
As Figuras 4.8 e 4.9 apresentam exemplos de como é feito o gerenciamento do
conteúdo através da aplicação em php. Essas Figuras representam as páginas de
gerenciamento das seções Home e Contatos respectivamente. Através dessas
páginas o usuário pode alterar os textos e trocar as imagens, ou seja, pode
gerenciar todo o conteúdo do site.
O capitulo seguinte apresenta as conclusões do trabalho.
94
5 CONCLUSÕES
Através do estudo realizado, da análise, do projeto e da implementação do primeiro
protótipo do framework BuilderWeb, como pode ser visto no capítulo 3, pode ser dito
que objetivo traçado para esse trabalho foi alcançado. Apesar da primeira versão do
BuilderWeb possuir poucos recursos e representar apenas uma parte do domínio
tratado na análise das aplicações exemplo, que pode ser visto na seção 3.2. No
entanto, a sua estrutura de classes, mesmo sendo simples, provê uma infra-
estrutura para o desenvolvimento de aplicativos em Flash que utilizam a linguagem
Acrtionscript 3, provendo uma certa redução de custos no desemento deste,
conforme pode ser visto no estudo de caso do capitulo 4. O projeto de
desenvolvimento desse framework consistiu na abordagem de Projeto Dirigido Por
Exemplos Johnson(1996) em conjunto com a utilização de padrões de projeto
Gamma (2000).
Os principais resultados obtidos por esse projeto foram:
A disponibilização de um projeto estrutural de um framework orientado a objeto que
pode ser utilizado para a criação de aplicativos web, como pode ser visto no capítulo
4. Sendo que este framework promove o controle do fluxo de execução e
colaboração entre as classes, possibilitando a reutilização das classes através de
especialização ou composição, sendo que estas são chamadas pelas classes do
framework.
A disponibilização de um protótipo do BuilderWeb na linguagem Actionscript 3, o
qual programadores com conhecimento nessa linguagem possam usufruir dos
recursos oferecidos por essa ferramenta. Estes programadores poderão não apenas
fazer o reuso de código, mas de projeto também. Na implementação foram utilizadas
classes da própria linguagem Actionscript 3, no intuito de minimizar o esforço no
entendimento do framework.
O uso do BuilderWeb para a criação de aplicativos web permite que os
desenvolvedores não produzam aplicativos “do zero”, facilitando dessa forma, o
95
desenvolvimento de tais aplicações. Uma vez que esse já disponibiliza uma
arquitetura que funciona como base para implementação desses aplicativos.
Ao longo do desenvolvimento do framework BuilderWeb observou-se algumas
limitações que serão descritas a seguir:
Falta de uma avaliação efetiva do framework, uma vez que, o BuilderWeb
ainda não foi devidamente avaliado para verificar se ele é completamente
adequado ao desenvolvimento de aplicativos web em Actionscript 3, já que o
mesmo foi reutilizado para produzir apenas um aplicativo (ver capítulo 4).
Falta de uma avaliação sobre decisão de projeto tomada durante o
desenvolvimento do BuilderWeb. Durante o projeto foram tomadas algumas
decisões para que sua implementação fosse concluída. Por exemlo, foi
utilizado o padrão de projeto Strategy para definir a estrutura visual do menu
de navegação. Será que essa foi a melhor abordagem para se definir uma
estrutura do menu ? Essa questão só poderá ser respondida a partir da
observação do uso desse recurso em várias aplicações distintas.
Durante o desenvolvimento do presente trabalho encontrou-se algumas dificudades
como, por exemplo, a criação de um mini-sistema que possibilitasse a utilização do
framework juntamente com a ferramenta Flash. Esse problema foi sanado graças à
utilização da API Javascript do Flash. Outra dificudade encontrada na elaboração do
framework foi adaptar as teorias de padrões de projetos levantadas por
Gamma(2000) para a linguagem Actionscript 3.
No intuito de melhorar o framework descrito neste trabalho, a seguir serão descritos
alguns pontos para trabalhos futuros.
Aumentar o domínio de atuação do framework englobando a ele
funcionalidades como web serviço, manipulação de Servidor de Stream.
Criação de um documeto contendo informações de como usar o BuilderWeb.
Criação de um web site com o intuito de divugar o BuilderWeb.
96
Realização de um estudo comparativo, com o intuito de levantar dados a
respeito do custo de desenvolvimento entre duas aplicações, uma
desenvolvida com BuilderWeb e outra sem a utilização deste.
97
REFERÊNCIAS BIBLIOGRÁFICAS
ADOBE. Extending Flash. Disponível em: <http://livedocs.adobe.com/Flash/9.0/main/Flash_CS3_extending.pdf>. Acesso em 28 Março. 2008. ARANGO, G.; PRIETO-DÍAZ, R. Domain analysis concepts and research directions, In: PRIETO-DIAZ, R.; ARANGO,G. Domain analysis and software modeling. Los Alamitos: IEEE Computer Society Press,1991 BEUTLER, Dário Lissandro. Um framework para a criação de ferramentas de auditoria para documentos multimídia. Porto Alegre: Instituto de Informática da UFGS, 2003. Dissertação de Mestrado. BUSCHMANN, F., R. Meunier, H. Rohnert, P. Sommerlad and M. Stal. Patterns Oriented Software Architecture: ASystem of Patterns. John Wiley & Sons Ltd, Chichester, Uk, second edition, 1996 CAMPO, Marcelo Ricardo. Compreensão Visual de Framework através de INtrospeção de Exemplos. PhD thesis. Porto Alegre: UFRGS/II/GPGCC. Março de 1997. COAD, Peter. Object-Oriented Patterns. Communications of the ACM, V.35, nº9, p. 152-159, 1992. COELHO , Federico de Miranda. Uso de componentes de software no desenvolvimento de frameworks orientado a objeto. Campinas: Instituto de computação da UNICAMP, 2002. Dissertação de Mestrado. GAMMA, E. et al. Padrões de projeto: soluções reutilizáveis de software orientado a objetos; trad. Luiz A. Meirelles Salgado. Porto Alegre: Bookman, 2000. JOHNSON, R.E. Documenting framework using patterns. SIGPLAN Notices, New York, v.27,n.10, Oct 1992 trabalho apresentado na OOPSLA, 1992. JOHNSON, R.E. how to develop framework. Tutorial Notes of ECCOP 96.Linz, Austria: July, 1996. JOHNSON, Ralph E.; Woolf, B. Type Object. In: “Martin,R.C.; Riehle,D.;Buschmann, F. Pattern Languages of Program Design 3. Reading-MA, Addison-Wesley, 1998”, p. 47-65. MARTIN, James. Análise e projetos orientados a objetos; tradução José Carlos Barbosa dos Santos. 1. ed. São Paulo : Makron Books, 1995. MOOCK, Colin. Essential ActionScript 3.0. Sebastopol: O‟Reilly, 2007.
98
Pádua FILHO, Wilson. Multimídia: Conceitos e Aplicações. Rio de Janeiro: LTC, 2000. PREE, Wolfgang. Design patterns for object-oriented software developmment. Reading: Addison-Wesley, 1995. PITTS-MOULTIS, Natanya. XML Black Book; tradução Ariovaldo Griesi.1.ed.São Paulo: Makron Books, 2000. PRESSMAN, Roger S. Engenharia de Software; tradução Rosâgela Delloso Penteado. 6. ed. São Paulo: McGraw-Hill, 2006. SANDERS, Willian. ActionScript 3.0 Design Patterns. Sebastopol: O‟Reilly, 2007. SILVA, Ricardo Pereira e. Suporte ao Desenvolvimento e uso de Framework e Componentes. Porto Alegre: Instituto de Informática da UFGS, 2000. Tese de Doutorado. SOMMERVILLE, Ian. Engenharia de software; tradução Andre Maúricio de Andrade Ribeiro. 6. ed. São Palo: Addison Wesley, 2003.
99
APÊNDICES
100
APÊNDICE A – CÓDIGO FONTE DAS CLASSES DO PAINEL DE
CONTROLE
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;
/* classe control responsável pelo gerenciamento do painel
de controle*/
public class ControllPanel extends Sprite {
private var URI:String;
private var infosXMLPages;
public function ControllPanel() {
import Flash.text.TextFormat;
var tf:TextFormat = new TextFormat();
tf.font = "Tahoma";
project_mc.checkMenu.setStyle("textFormat", tf);
stage.align=StageAlign.TOP_LEFT;
//stage.align = StageAlign.TOP;
project_mc.butProjeto.addEventListener(MouseEvent.CLICK,Press);
project_mc.butAbrir.addEventListener(MouseEvent.CLICK,openAs);
}
private function opens():void {
URI=MMExecute('fl.browseForFolderURL("Selecione o arquivo")');
infosXMLPages = new InfosXMLPages(URI);
101
}
private function executes():void{
}
private function CreateProject():void {
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
====================================================================
private function Press(e:MouseEvent):void {
CreateProject();
}
private function openAs(e:MouseEvent):void {
opens();
}
private function onExecute(e:MouseEvent):void{
}
}
}
package system{
import Flash.events.*;
import adobe.utils.*;
/*classe responsável pela leitura do XML
de navegação
102
*/
public class InfosXMLPages {
private var infosXML:Object;
private var objInfosXML:Array;
private var XML;
private var cont=0;
private var URI:String;
private const config = "../execute/";
public function InfosXMLPages(URI:String):void {
this.URI = URI;
var XML = new LoadXML("C:\XML.XML");
XML.addEventListener(LoadXML.LOAD_COMPLETE,completes);
objInfosXML = new Array();
}
private function readXMLData(XML:XMLList,num:int,objParent:String) {
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);
}
}
}
private function addObjInfos(XML:XMLList,num:int,objParent:String){
// callJsfl(XML[num].@swf,URI);
infosXML = new Object();
infosXML.name = XML[num].@swf;
infosXML.objParent = XML[num].parent().@swf;
objInfosXML.unshift(infosXML);
cont++;
}
private function insertPages(){
for(var i:int=0;i<objInfosXML.length; i++){
callJsfl(objInfosXML[i].name,URI)
}
}
private function WriteClassDataXMLSystem():void{
var str:String ="package classes.data{\\n\\n";
str+=" public class DataXMLSystem{\\n\\n";
str+=" private static var instance:DataXMLSystem\\n"
str+=" private var objDataXML:Array;\\n\\n";
str+=" public function DataXMLSystem(prt:PrivateClass){\\n";
str+=" objDataXML = new Array();\\n";
str+=" createObjData()\\n";
str+=" }\\n";
str+=" public static function getInstance(){\\n"
str+=" if (instance == null) {\\n"
str+=" DataXMLSystem.instance = new DataXMLSystem(new PrivateClass());\\n"
str+=" }\\n"
104
str+=" return DataXMLSystem.instance;\\n"
str+=" }\\n\\n";
str+=" private function createObjData(){\\n";
for(var i=0;i<objInfosXML.length;i++){
str+=" var obj = new Object();\\n";
str+=" obj.name ='"+objInfosXML[i].name+"' ;\\n";
str+=" obj.swf ='"+config+objInfosXML[i].name+".swf' ;\\n";
str+=" obj.objParent='"+objInfosXML[i].objParent+"';\\n";
str+=" obj.flag=0;\\n";
str+=" objDataXML["+i+"] =obj;\\n\\n";
}
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);
}
private function callJsfl(paran:String,URI:String):void {
var str:String;
str
='fl.runScript(fl.configURI+"/bulderWeb/jsfl/project.jsfl","init","'+paran+'","'+URI+'");';
MMExecute(str);
}
//eventos========================================================
private function completes(e:Event):void {
var str:String;
105
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
====================================================================
public function get getObjInfosXML():Array{
return objInfosXML;
}
}
}
package system{
import Flash.events.*;
import Flash.net.*;
public class LoadXML extends EventDispatcher{
public var dataXML:XML;
private var urlLoader:URLLoader;
private var urlRequest:URLRequest;
public static const LOAD_COMPLETE:String="loadComplete";
public function LoadXML(urlXML:String):void{
urlRequest = new URLRequest(urlXML);
urlLoader = new URLLoader();
urlLoader.load(urlRequest);
106
urlLoader.addEventListener(Event.COMPLETE, completeListener);
}
private function completeListener(e:Event):void {
dataXML = new XML(urlLoader.data);
//dataXML.ignoreWhitespace = true;
dispatchEvent(new Event(LoadXML.LOAD_COMPLETE));
}
}
}
107
APÊNDICE B – CÓDIGO FONTE DO ARQUIVO PROJECT.JSFL
/* arquivo criado atraves da API Javascript do Flash */
function createProject(){
var folderURI = fl.browseForFolderURL("Selecione o arquivo");
var projeto = prompt("Digite o nome do projeto:", "");
var createExecutes = FLfile.createFolder(folderURI+"/"+projeto+"/execute");
var createTemplate = FLfile.createFolder(folderURI+"/"+projeto+"/templates");
var createNavigate = FLfile.createFolder(folderURI+"/"+projeto+"/navigate");
var aplication = FLfile.createFolder(folderURI+"/"+projeto+"/aplication/classes/pages");
var control = FLfile.createFolder(folderURI+"/"+projeto+"/aplication/classes/control");
var classLoader = FLfile.createFolder(folderURI+"/"+projeto+"/aplication/classes/classLoader");
var folderData = FLfile.createFolder(folderURI+"/"+projeto+"/aplication/classes/data");
var folderInstall = FLfile.createFolder(folderURI+"/"+projeto+"/aplication/classes/expressInstallation");
var folderCommunication =
FLfile.createFolder(folderURI+"/"+projeto+"/aplication/classes/communication");
if(createTemplate==true){
//cria arquivo /projeto/templates/page.fla
var originalFileURI=fl.configURI+"/bulderWeb/templates/page.fla";
var newFileURI=folderURI+"/"+projeto+"/templates/page.fla";
FLfile.copy(originalFileURI, newFileURI);
//cria arquivo /projeto/templates/Page.as
var originalFileURI=fl.configURI+"/bulderWeb/templates/Page.as";
var newFileURI=folderURI+"/"+projeto+"/templates/Page.as";
FLfile.copy(originalFileURI, newFileURI);
}
//cria arquivo /projeto/execute/index.html
if(createExecutes==true){
var originalFileURI=fl.configURI+"/bulderWeb/execute/index.html";
var newFileURI=folderURI+"/"+projeto+"/execute/index.html";
FLfile.copy(originalFileURI, newFileURI);
//cria arquivo /projeto/execute/swfobject.js
108
/* 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);
}
//cria arquivo /projeto/aplication/classes/pages/Base.as
if(aplication==true){
var originalFileURI=fl.configURI+"/bulderWeb/aplication/preload.fla";
var newFileURI=folderURI+"/"+projeto+"/aplication/preloader.fla";
FLfile.copy(originalFileURI, newFileURI);
//cria arquivo /projeto/aplication/classes/pages/Preloader.as
var originalFileURI=fl.configURI+"/bulderWeb/aplication/classes/pages/Preloader.as";
var newFileURI=folderURI+"/"+projeto+"/aplication/classes/pages/Preloader.as";
FLfile.copy(originalFileURI, newFileURI);
//cria arquivo /projeto/aplication/Base.fla
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);
}
}
//cria arquivos /projeto/aplication/control
if(control==true){
var
originalFileURI=fl.configURI+"/bulderWeb/aplication/classes/control/ComponetContainer.as";
var newFileURI=folderURI+"/"+projeto+"/aplication/classes/control/ComponetContainer.as";
FLfile.copy(originalFileURI, newFileURI);
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);
}
//cria arquivo /projeto/aplication/classLoader
110
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);
}
//cria arquivo /projeto/navigate/XML.XML
if(createNavigate==true){
var originalFileURI=fl.configURI+"/bulderWeb/navigate/XML.XML";
var newFileURI=folderURI+"/"+projeto+"/navigate/XML.XML";
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);
}
if(createNavigate==true && aplication==true && createExecutes==true &&
createTemplate==true && classLoader==true && control==true && folderData==true &&
folderCommunication ==true ){
alert("Projeto Criado");
}
else{
alert("Projeto não Criado");
}
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
*/
var str = "package classes.pages{\n\n";
str+= " import Flash.display.MovieClip;\n\n";
//var Name = VerificaLetras(paran);
//alert(paran[0])
str+= " public class "+ paran +" extends MovieClip{\n\n ";
str+= " public function "+ paran +"() {\n";
str+= " stop()";
str+= " }\n";
str+= " }\n";
str+= "}\n";
return str;
}
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);
}
/*cria um arquivo de projeto Flash para a aplicação criada*/
function executeProject(folderURI){
var URIProject =folderURI+"/aplication/BuilderProject.flp"
114
if(!FLfile.exists(URIProject)){
myProject = fl.createProject(folderURI+"/aplication/BuilderProject.flp","BuilderProject");
// add os flas preloader e base
===============================================================
var URI = folderURI+"/aplication/preloader.fla";
myProject.addFile(URI,false);
URI = myProject.findProjectItem(folderURI+"/aplication/preloader.fla")
myProject.defaultItem = URI;
var URI =folderURI+"/aplication/base.fla";
myProject.addFile(URI,false);
}
else{
myProject = fl.openProject(URIProject);
URI = myProject.findProjectItem(folderURI+"/aplication/preloader.fla");
myProject.defaultItem = URI;
}
}
//função cria a classe base
===============================================================
function createClassDataXMLSystem(str,URI){
var uri = URI+"/aplication/classes/data/DataXMLSystem.as"
var as = FLfile.write(uri, str);
}
/*function addProfile(folderURI,namePage){
setPublishProfileSettings(folderURI+"/execute/"+namePage+".swf", 9)
//fl.getDocumentDOM().exportSWF(folderURI+"/execute/"+namePage+".swf",true);
}*/
function setPublishProfileSettings(fileURI, asVersion,pageName)
{
// does Flash file exist
115
var XML, from, to, delta;
var pPath = fl.configURI + "Publish Profiles/hen3.XML";
fl.getDocumentDOM().exportPublishProfile(pPath);
XML = FLfile.read(pPath);
// override default names to 0
from = XML.indexOf("<defaultNames>");
to = XML.indexOf("</defaultNames>");
delta = XML.substring(from, to);
XML = XML.split(delta).join("<defaultNames>0");
// override Flash default name to 0
from = XML.indexOf("<FlashDefaultName>");
to = XML.indexOf("</FlashDefaultName>");
delta = XML.substring(from, to);
XML = XML.split(delta).join("<FlashDefaultName>0");
// replace the publish path for swf
from = XML.indexOf("<FlashFileName>");
to = XML.indexOf("</FlashFileName>");
delta = XML.substring(from, to);
var parentPath = "../";
XML = XML.split(delta).join("<FlashFileName>" + parentPath + "execute/" + pageName +
".swf");
// and the rest
var types = {};
types.generatorFileName = "swt";
types.projectorWinFileName = "exe";
types.projectorMacFileName = "hqx";
types.htmlFileName = "html";
types.gifFileName = "gif";
types.jpegFileName = "jpg";
types.pngFileName = "png";
types.qtFileName = "mov";
types.rnwkFileName = "smil";
for (var n in types) {
116
from = XML.indexOf("<" + n + ">");
to = XML.indexOf("</" + n + ">");
delta = XML.substring(from, to);
XML = XML.split(delta).join("<" + n + ">" +pageName + "." + types[n]);
}
// 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");
// set package paths based on AS version
if (asVersion == 2)
{
from = XML.indexOf("<PackagePaths>");
to = XML.indexOf("</PackagePaths>");
}
else
{
from = XML.indexOf("<AS3PackagePaths>");
to = XML.indexOf("</AS3PackagePaths>");
}
delta = XML.substring(from, to);
var classPath = "./";
if (asVersion == 2)
{
XML = XML.split(delta).join("<PackagePaths>" + classPath + "classes");
}
else
{
XML = XML.split(delta).join("<AS3PackagePaths>" +classPath +"classes");
}
117
// write the modified profile and import it
FLfile.write(pPath, XML);
var flag=fl.getDocumentDOM().importPublishProfile(pPath);
}
118
APÊNDICE C – CÓDIGO FONTE DO PACOTE CLASSLOADER
package classes.classLoader{
import Flash.display.*;
import Flash.events.*;
import Flash.net.*;
public class AbstractLoader extends MovieClip{
private var url:URLRequest;
protected var loads:Loader;
protected var Url;
protected var sName;
public function AbstractLoader (Url:String,sName:String){
this.Url = Url;
this.sName = sName;
addEventListener(Event.ADDED_TO_STAGE,thisAddedToStage);
}
protected function loader(str:String,Name:String){
url = new URLRequest(str);
loads = new Loader();
loads.load(url);
loads.name=Name;
loads.contentLoaderInfo.addEventListener(Event.OPEN,ListenerOpen);
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
}
private function ListenerProgress(e:ProgressEvent ){
animeProgress(e.bytesLoaded,e.bytesTotal);
}
private function ListenerCompleted(e:Event){
animeComplete();
}
private function loadsAddedToStage(e:Event){
loadsLoaderAdded();
}
private function thisAddedToStage(e:Event){
init();
}
//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.*;
public class BaseLoader extends AbstractLoader{
private var preloader;
120
public function BaseLoader(Url:String,sName:String){
super(Url,sName);
}
override protected function init(){
this.x=stage.stageWidth/2-(this.width/2);
this.y=stage.stageHeight/2-(this.height/2);
preloader= parent as MovieClip;
loader(Url,sName);
}
//event ===================================================
override protected function animeOpen(){
this.visible=true;
}
override protected function animeProgress(bytesLoaded:Number,bytesTotal:Number){
//trace(bytesLoaded/bytesTotal);
this.barra_mc.scaleX = (bytesLoaded/bytesTotal);
}
override protected function animeComplete(){
preloader.addChild(loads);
this.visible=false;
}
}
}
package classes.classLoader{
import Flash.display.*;
import Flash.events.*;
public class PagesLoader extends AbstractLoader{
121
private var objParent:String;
static var pageCurrent:String;
public function PagesLoader(Url:String,sName:String){
super(Url,sName);
}
override protected function init(){
this.x=stage.stageWidth/2-(this.width/2);
this.y=stage.stageHeight/2-(this.height/2);
loader(Url,sName);
}
override protected function animeOpen(){
this.visible=true;
}
override protected function animeProgress(bytesLoaded:Number,bytesTotal:Number){
//trace(bytesLoaded/bytesTotal);
this.barra_mc.scaleX = (bytesLoaded/bytesTotal);
}
override protected function animeComplete(){
trace("parent: "+objParent);
if(pageCurrent!=null &&pageCurrent!= objParent ){
parent.removeChild(parent.getChildByName(pageCurrent));
}
parent.addChild(loads);
pageCurrent = sName;
this.visible=false;
}
public function set setObjParent(str:String){
objParent = str;
}
}
}
122
APÊNDICE D – CÓDIGO FONTE DO PACOTE PAGES
package classes.pages{
import Flash.display.MovieClip;
import classes.data.*;
import classes.control.*;
public class Base extends MovieClip {
private const constObjXML:int=2;
private var iStructureObj:IStructureObj;
public function Base() {
init();
}
public function init() {
createMenuIten();
}
function createMenuIten(){
iStructureObj = new StructureMenu();
addChild(iStructureObj.abstractStyle());
}
}
}
package classes.pages{
import Flash.display.*;
import classes.classLoader.*;
public class Preloader extends MovieClip{
123
private var objLoader;
public function Preloader(){
init();
}
public function init(){
objLoader = new BaseLoader("base.swf","base");
this.addChild(objLoader);
}
}
}
124
APÊNDICE E – CÓDIGO FONTE DO PACOTE CONTROL
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{
public function add(c:ComponetContainer):void {
throw new IllegalOperationError("não suporta a operação add");
}
public function remove(c:ComponetContainer):void {
throw new IllegalOperationError("não suporta a operação removenão");
}
public function getChild(n:int):ComponetContainer {
throw new IllegalOperationError("não suporta a operação getChild");
return null;
}
// ABSTRACT Method (deve ser reimplementado)
public function operations():void {
}
}
}
package classes.control{
import Flash.display.*;
import Flash.events.*;
public class Composite extends ComponetContainer {
125
private var sName:String;
private var aChildren:Array;
public function Composite(sName:String) {
this.sName=sName;
aChildren=new Array();
addEventListener(Event.ADDED_TO_STAGE,addComposite)
}
override public function add(c:ComponetContainer):void {
aChildren.push(c);
addChild(c);
}
override public function operations():void {
for each (var c:ComponetContainer in aChildren)
{
c.operations();
}
}
private function addComposite(e:Event){
this.operations();
}
}
}
package classes.control{
public interface IStructureObj{
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;
public class ItenMenu extends ComponetContainer {
private var sName:String;
private var pageLoader:PagesLoader;
private var base:Base;
private var objInfosXML:DataXMLSystem;
public var id:int;
public function ItenMenu(sName:String){
this.buttonMode=true;
this.sName=sName;
objInfosXML = DataXMLSystem.getInstance();
this.text_txt.autoSize=TextFieldAutoSize.LEFT;
addEventListener(Event.ADDED_TO_STAGE,addItenMenu)
}
override public function operations():void {
addEventListener(MouseEvent.CLICK,onClick);
}
private function onClick(e:MouseEvent){
trace(objInfosXML.getObjDataXML[id].swf);
pageLoader = new
PagesLoader(objInfosXML.getObjDataXML[id].swf,sName);
base.addChild(pageLoader);
}
private function addItenMenu(e:Event){
this.hit_mc.width=text_txt.textWidth+10;
127
base = parent.parent as Base;
}
}
}
package classes.control{
import classes.data.*;
public class StructureMenu implements IStructureObj {
private var objInfosXML:DataXMLSystem;
private var menu:ComponetContainer;
public function StructureMenu() {
}
public function abstractStyle():ComponetContainer {
var cont = -1;
menu = new Composite("menu");
objInfosXML = DataXMLSystem.getInstance();
menu.x=18;
menu.y=25;
//varre todo o objeto
objInfosXML===================================
for (var i=0; i<objInfosXML.getObjDataXML.length; i++) {
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{
public class StructureMenuUser implements IStructureObj{
public function StructureMenuUser(){
}
public function abstractStyle()ComponetContainer{
}
}
}
129
APÊNDICE F – CÓDIGO FONTE DO PACOTE DATA
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 class DataXMLSystem{
private static var instance:DataXMLSystem
private var objDataXML:Array;
public function DataXMLSystem(prt:PrivateClass){
objDataXML = new Array();
createObjData()
}
public static function getInstance(){
if (instance == null) {
DataXMLSystem.instance = new DataXMLSystem(new PrivateClass());
}
return DataXMLSystem.instance;
}
private function createObjData{
}
public function get getObjDataXML(){
return objDataXML;
130
}
public function setFlagObjDataXML(flag:int,id:int){
objDataXML[id].flag=1;
}
}
}
131
APÊNDICE G – CÓDIGO FONTE DO PACOTE COMMUNICATION
package classes.communication{
import flash.events.*;
import flash.net.*;
public class LoadXml extends EventDispatcher{
public var dataXml:XML;
private var urlLoader:URLLoader;
private var urlRequest:URLRequest;
public static const LOAD_COMPLETE:String="loadComplete";
public function LoadXml(urlXml:String){
urlRequest = new URLRequest(urlXml);
urlLoader = new URLLoader();
urlLoader.load(urlRequest);
urlLoader.addEventListener(Event.COMPLETE, completeListener);
}
private function completeListener(e:Event):void {
dataXml = new XML(urlLoader.data);
//dataXml.ignoreWhitespace = true;
dispatchEvent(new Event(LoadXml.LOAD_COMPLETE));
}
}
}