framework e3: uma estrutura para manipular imagens ...€¦ · framework e3: uma estrutura para...

Framework E3: Uma Estrutura Para Manipular Imagens Estáticas via TV Digital

Wollace de Souza Picanço1, Anderson F. Esteves1, Wanderlan Albuquerque1, Ricardo da Silva Barboza1

1 Curso Superior em Licenciatura em Computação – Laureate International Universities (UNINORTE) Manaus – AM – Brasil

[email protected],{wcacarvalho,rsbarbosa,anderson.esteves} @gmail.com

Abstract. Given The technique of limited animation (TAL) is used in several classes and methods for manipulating static images via digital TV. This article aims to suggest a proposed framework for customizing this technique. In this context, we analyzed some classes and methods of applications using the middleware Ginga-J and Multimedia Home Platform (MHP). However, this metric provided a case study aimed at improving the production of these frameworks. From this assumption, it was possible to develop a software architecture and reusable transparent, called "framework E3". Thus, this framework allowed the reduction of the application CarnavalXlet twelve (12) to 03 (three) classes and 36 (thirty-know) to fifteen (15) methods.

Resumo. A técnica da animação limitada (TAL) utiliza-se de várias classes e método para manipular imagens estáticas via TV Digital. Este artigo tem como objetivo sugerir uma proposta de frameworks para customizar esta técnica. Neste contexto, foram analisadas algumas classes e métodos dos aplicativos que utilizam os middlewares Ginga-J e Multimedia Home Platform (MHP). Contudo, esta métrica proporcionou um estudo de caso visando à melhoria na produção desses arcabouços. A partir desse pressuposto, foi possível elaborar uma arquitetura de software reutilizável e transparente, denominado de “framework E3”. Assim, este arcabouço possibilitou a redução do aplicativo CarnavalXlet de 12 (doze) para 03(três) classes e de 36 (trinta e sei) para 15 (quinze) métodos.

1. Introdução Um estudo anual realizado pela empresa CVA Solutions aponta que, nos últimos três anos, 69% dos consumidores do Brasil trocaram de aparelho de televisão em suas casas [DTV 2013]. No Brasil, a TV Digital aberta tem agora interatividade que possibilita a criação de serviços interativos como: buscar um resumo do capítulo de uma novela, responder perguntas de uma pesquisa, consultar informações estatísticas, entre outros serviços.

Nesta perspectiva, analisaram-se através de métricas, alguns aplicativos responsáveis por esses serviços interativos, especificamente, as classes e os métodos executados nos middleware Ginga-J e MHP. Identificou-se que tanto essas classes quanto esses métodos manipulam várias imagens estáticas e multiplicam-se quando há necessidades de executarem mais imagens. Essas multiplicações permitem que nossas percepções vejam movimentos nas imagens estáticas. Contudo, identificaram-se que essas implicações relacionam-se com a técnica da animação limitada. Em virtude disso,

Anais do Encontro Regional de Computa€•o e Sistemas de Informa€•o

Manaus, 25 a 27 de abril de 2013 1 ISSN 2238-5096 (CDR)

como melhorar as redundâncias nessas classes e métodos? Como ganhar tempo nas produções dos mesmos? Assim, foi elaborado um estudo de caso, norteando produção de um framework baseado nessa técnica. Portanto, este artigo tem como objetivo sugerir um framework para manipular o movimento de imagens estáticas via TV. Assim, esta pesquisa foi organizada de acordo com a seguinte hierarquia: seção 1. Introdução; seção 2. Revisão bibliográfica e Trabalhos Relacionados; seção 3. Métrica de Medição de Classes e de Métodos; seção 4. Estudo de Caso (4.1. Proposições do Framework; 4.2. Mapa Conceitual das Classes do Framework; 4.3 Mapa Conceitual dos Métodos das Classes e 4.4. Fusão dos Mapas Conceituais - Conclusão K); seção 5. Validação do “Framework E3” (5.1 Modelagem do Aplicativo CarnavalXlet; 5.2 Modelagem do Aplicativo Nemo; 5.3 Futuras possibilidades nas Dimensões 3D); 6. Avaliação Quantitativa e por fim, a seção 7. São apresentadas as Considerações Finais.

2. Revisão Bibliográfica e Trabalhos Relacionados Conforme [BLAIR 1994] a técnica da animação limitada divide um personagem animado em diferentes partes separadas em camadas que podem ou não serem animadas de forma independente. Permitindo assim a criação de diversas animações através das combinações entre as partes. Observe a [Figura 1], ela demonstra que para cada classe instanciada, há um quadro de imagem associada a uma classe visando à reprodução da imagem final. Assim, a customização dessa técnica foi através de framework.

Figura 1 – Técnica da animação limitada

“Framework é uma estrutura genérica estendida para se criar uma aplicação ou subsistema mais especifico”, [Sommerville 2011].

Concomitantemente, alguns trabalhos relacionados como de [Albuquerque 2012] demonstram que a utilização de framework na manipulação de imagens, possibilitam as criações de aplicativos interativos que podem serem aplicados nos ambientes educativos, a [Figura 2] demonstram a interface principal do framework O-LEARNING TVDi para manipular objetos digitais de aprendizagem relacionados ao ensino da trigonometria.

Figura 2 - Interface do framework O-LEARNING TVDi

Fonte: Adaptado de Albuquerque (2012)



Outros pesquisadores como [Maia 2010] desenvolveu o framework GameTVD para geração de jogos, que consistiu em um conjunto de classes para permitir a criação de novos jogos, apenas sendo necessário ao usuário adicionar objetos e cenários para criação dos jogos, através de uma interface gráfica. Na [Figura 3] é apresentada a interface inicial da composição do jogo Pac-Man. Este trabalho mostrou ser importante para esta pesquisa porque através dele foi possível identificar o módulo das classes responsável pela transparecia do framewok.

Figura 3 - jogo Pac-Man Fonte: Adaptado de Maia (2010)

3. Métrica de Medição de Classes e de Métodos O primeiro aplicativo analisado foi CarnavalXlet do middleware MHP e, identificou-se nessas arquiteturas a existência de classes e métodos semelhantes, observa-se a [Figura 4]. Ela demonstra que o arcabouço é composto por 08 (oito) classes; a classe identificada pelo retângulo verde (CarnavalXlet) representa a interface com o middleware; a classe identificada pelo retângulo amarelo (Imagens) é a base para a impĺementação das imagens estáticas de interatividades; as classes identificadas de 02 (dois) a 07 (sete), permitem as navegações entre diferentes form ou telas, os retângulos roxos identificam os atributos semelhantes e os retângulos vermelhos identificam os métodos em comum.

Figura 4 – Diagrama de classe do aplicativo CarnavalXlet



O segundo aplicativo foi o Nemo do middleware Ginga-J, esse foi representado pela [Figura 5]. Observam-se suas descrições: o arcabouço é composto por 12 (doze) classes; a classe identificada pelo retângulo verde (Nemo) representa a interfaces com o middleware; as classes identificadas pelos retângulos amarelos (Constats/Imagens) são fundamentais para as execuções das imagens estáticas de interatividades; as classes identificadas de 02 (dois) a 10 (dez) permitem as navegações entre diferentes form ou telas, os retângulos roxos identificam os atributos semelhantes e os retângulos vermelhos identificam os métodos em comum.

Figura 5 – Diagrama de classe do aplicativo Nemo

Dessa forma, foi possível identificar os elementos básicos que compõem as arquiteturas dos aplicativos analisados, em virtude disso, a [Figura 6] descreve a suma dos resultados, onde o aplicativo CarnavalXlet contém 08 (oito) classes e 40 (quarenta) métodos. Enquanto o aplicativo Nemo tem 08 (oito) classes e 36 (trinta e seis) métodos. Contudo, os dados preenchidos em vermelho, foram analisados neste artigo.

Nome do Aplicativo Nº de Classes Métodos Middleware Autor

08 40 MHP (GINGA RN, 2010)

12 36 Ginga-J (GINGA CDN, 2009)

04 16 MHP (GINGA RN, 2010)

13 42 Ginga-J (GINGA CDN, 2009)

Figura 6 – Resultado da analise dos aplicativos



Nesta perspectiva, identificou-se que dependendo da proporção de imagens, o número de classes e métodos será proporcional a esta proporção. Assim, a ideia básica para minimizar essa problemática, não foi desenvolver uma solução para uma aplicação específica e sim, capturar o comportamento geral de um domínio de aplicação e montar uma estrutura capaz de controlar e representar de forma transparente essas imagens. Assim, foi necessário elaborar um estudo de caso visando à migração dos elementos básico do framework.

4. Estudo de Caso É relevante lembrar, que o propósito dessa pesquisa é a construção de um framework. Assim, iniciaram-se os procedimentos de confirmação ou refutação do arcabouço.

4.1 Proposições do Framework As classes essenciais dos aplicativos foram substituídas pelas suas respectivas equivalências, norteando melhores perspectivas neste processo: classe 01<=>E¹ (Implementador), Classe 02<=>E² (incrementa ou decrementa) e Classe 03<=>E³ (elemento/imagem). Conseguentimente substituíram-se as equivalências e as conjunções pelas proposições: W¹, W², W³; A unificação das proposições resultou na conclusão K. Estas implicações são identificadas pelos marcadores abaixo:

W¹: E¹ implementa E² e tem a função ƒ(x,y); W²: E² exclui a implementação atual de E² e por um intervalo de tempo

incrementa ou decrementa a função em E¹ e implementa novamente E²; W³: E³ associa-se com E² e tem os fatores (imagens) das implementações e, E²

utiliza-se deste para posiciona-se no eixo x e y; K: Conclusão decorrente de W¹, W², W³.

Assim, utilizaram-se dessas proposições para elaborações dos mapas conceituais. Conforme [Moreira 1990] este pode ser interpretado como diagrama hierárquico que procuram refletir a organização conceitual de um corpo de conhecimento ou de parte dele. Portanto, justifica-se através da facilidade de compreensão e de interoperabilidade entre outras ferramentas, a utilização do mapa conceitual nesse estudo.

4.2 Mapa Conceitual das Classes do Framework Observa-se na [Figura 7], ela representa o mapa conceitual das Classes definidas pelas proposições W¹, W², W³. Embora os retângulos e as conexões deste mapa representem uma abstração essencial das classes, o mesmo não possibilita uma conceituação especifica de interatividades dos métodos e, portanto para esta possibilidade, utilizou-se na próxima seção um mapa conceitual para este caso.

Figura 7 – Mapa conceitual das classes básicas



4.3 Mapa Conceitual dos Métodos das Classes Utilizou-se um mapa conceitual para representar os métodos essenciais deste processo. Observando à [Figura 8], identificam-se os processos de relações entre os métodos. Contudo, utilizaram-se representações de equivalências, para melhor identificá-los na construção do mapa: método 01<=> m1(métodos x e y), método 02<=> m2 (implementação inicial), método 03<=> m3 (implementa coordenadas), método 04<=> m4 (eventos do usuário), método 05<=> m5 (exclusão da implementação inicial), método 06<=> m6 (incrementa ou decrementa e executa nova implementação) e método 07<=> m7 (Carrega imagem).

Figura 8 – Mapa conceitual dos métodos

Assim, definiram-se os mapas conceituais das classes e dos métodos norteando a proposição K. Esta visa à produção do framework.

4.4. Fusão dos Mapas Conceituais – Conclusão: K Partindo do pressuposto, que as proposições W¹,W²,W³ são representadas pelo mapa conceitual das classe e que os métodos foram representados pelas suas equivalências m1,m2,m3,m4,m5,m6 e m7 dizem-se as premissas dos argumentos. Logo se tem as unificações dos mapas conceituais e a substituição pela equivalência da conclusão: K <=> W¹:(m1˄m2), W²:(m3˄m4˄m5˄m6), W³: (m7). Portanto, W¹,W²,W³ ˫—―K é valido se e somente se a condicional: (W¹ ˄ W² ˄ W³) → K é tautologia. Para melhor entendimento, observa-se a [Figura 9], ela, representa o mapa conceitual da conclusão K, ou seja, ela representa a arquitetura do framework, tendo como base as proposições.

Figura 9 – Mapa conceitual da conclusão K



Em Virtude disso, finalizaram-se estas atividades e iniciaram-se os processos de validações das provas, visando à construção do objeto de refutação ou confirmação do framework. Assim, este arcabouço foi denominado neste contexto, de “framework E3” (entidade composta por três classes essenciais), este foi elaborado e induzido pelas proposições enunciadas na seção 3.1.

5. Validação do “Framework E3” Utilizaram-se as proposições para balizar as novas estruturas dos aplicativos analisados na seção - 2. No entanto, para validar de fato o “framework E3”, foram elaboradas três subseções: – 4.1, – 4.2, – 4.3.

5.1 Modelagem do Aplicativo CarnavalXlet Utilizou-se o diagrama de classe de implementação para modelar os aplicativos. Conforme [Bezerra, 1999] é uma extensão do modelo de especificação e corresponde a implementação da classe em alguma linguagem de programação. Assim, a [Figura 10], define arquitetura do aplicativo, utilizando o novo conceito de “Framework E3”. Além disso, esse arcabouço permite separar a responsabilidade da seguinte forma:

E¹: interfaces com o middleware's Application Manager para controle do ciclo de vida da Xlet.

E²: o controle principal da aplicação, implementa tela principal da aplicação e permite a navegação entre diferentes Form ou telas.

E³: classe que instancia as imagens visando a impĺementação na tela principal.

Figura 10 – Arcabouço do aplicativo utilizando “Framework E3”

5.2 Modelagem do Aplicativo Nemo Aplicou-se o mesmo procedimento utilizado na primeira subseção – 4.1., o diagrama de classe de implementação do aplicativo Nemo, foi exposto na [Figura 11]. Observa-se que o arcabouço utiliza-se do “framework E3”.



Figura 11 – Diagrama de classe do aplicativo Nemo

5.3 Futuras possibilidades nas Dimensões 3D Outras possibilidades foram e, estão sendo investigadas utilizando o sistema tridimensional e a arquitetura android. Embora, teve-se que customizar o arcabouço do “framework E3” (a [Figura 12] demonstra uma inovação no relacionamento da arquitetura), esta não alterou a base do arcabouço. Portanto, algumas alterações foram efetuadas na proposição W¹: E¹ implementa E² e tem a função ƒ(x,y,z), ou seja, agora o a função ƒ(x,y) tem o eixo “Z” e, define-se como um conjunto de todos os termos ordenados (x,y,z), sendo que a ordem não pode ser mudada sob pena de nos deslocarmos para outro lugar [Andrini, 1984].

Figura 12 – Extensão do “framework E3” no espaço tridimensional



Estudou-se no “framework E3”, a possibilidade de manipular imagens no eixo “Z”. Assim, novos experimentos com esse eixo e com as imagens foram executados. Contudo, esses testes proporcionaram o deslocamento das imagens no eixo “Z” da nova função ƒ(x,y,z), e os resultados foram a maximização ou minimização de seus megapixel. Portanto, utilizando-se o eixo “Z” no “framework E3”; customizam-se as proposições:

W¹: E¹ implementa E² e tem a função ƒ(x,y,z); W²: E² exclui a implementação atual de E² e por um intervalo de tempo

incrementa ou decrementa a função em E¹ e implementa novamente E²; W³: E³ associa-se com E² ou exclusivo herda de E¹ e tem os elementos (imagens)

das implementações, estes fatores, E² utiliza-se para posiciona-se no eixo x, y e z K: Conclusão decorrente de W¹, W², W³.

6. Avaliação Quantitativa A [Figura 13] demonstra o quadro - 1. Esta demonstra as aplicações da “TAL” nos aplicativos CarnavalXlet e Nemo com seus respectivos números de classes e de métodos. Observando o quadro - 2, ele demonstra os aplicativos CarnavalXlet e o Nemo utilizando o “framework E3” com seus respectivos números de classes e de métodos. Visualizando-se o quadro - 3, temos as comparações entre essas técnicas, especificamente nas classes e nos métodos, este quadro visa demonstra a eficiência do “framework E3” em relação a “TAL”. Portanto, na coluna subtração de classes do quadro - 3, temos 3 (três) classes do aplicativo CarnavalXlet que utiliza como técnica o “framework E3”, subtraiu-se -8 (menos oito) classes do aplicativo CarnavalXlet que utiliza a “TAL” e o resultado disso foi a redução de -5 (menos cinco) classes quando utiliza-se o “framework E3”. Assim, nos demais casos, as reduções se tornaram características do “framework E3”, pois além de reduzir as classes e os métodos, o framework proporcionou ganho de tempo, transparência e reuso nos desenvolvimentos de aplicativos que utilizam implementações de imagens estáticas.

Figura 13 – Quadros de resultados



7. Considerações Finais Apresentou-se neste artigo, uma proposta de framework para melhorar a eficiência dos aplicativos que utilizam a “TAL” via TV Digital. Estas sugestões surgiram-se com as necessidades de desenvolverem aplicativos dinâmicos que fizessem as simplificações dos processos, padronizações entre outros. Neste contexto, foram testados dois tipos de protótipos, onde o primeiro visava às melhorias nos arcabouços desses aplicativos, especificamente, as redundâncias de classes e métodos. Contudo, desenvolveram-se alguns processos e entre estes, analisaram-se as arquiteturas dos aplicativos. Por isso, migrou-se um estudo de caso visando às definições das proposições e as construções dos arcabouços por meio de mapas conceituais. Assim, essas atividades possibilitaram o surgimento do “framework E3”, este possibilita as reduções de classes, métodos e de sua reutilização. É relevante lembrar que o “framework E3” é eficiente especificamente para aplicativos que manipulam imagens. Entretanto, muitas considerações sobre aplicabilidade do “framework E3” migram-se neste contexto como nas arquiteturas dos aplicativos Smart TV, Ginga-J, MHP, Android, entre outros. Portanto, o “framework E3” é uma estrutura considerada Enterprise application frameworks (são os frameworks voltados para domínio de aplicação), pois, o mesmo é voltado para implementação de imagens estáticas e foi fundamentada na Técnica da Animação Limitada.

Referências Albuquerque, Wanderlan C., 2012. O-Learning Tvdi :Um Framework De Tv Digital

Interativa Para Manipular Objetos Digitais De Aprendizagem Relacionados Ao Ensino Da Trigonometria. Dissertação de Mestrado. Universidade Federal do Amazonas – Programa De Pós-Graduação Em Engenharia Elétrica. Manaus, Amazonas. Brasil.

Bezerra, Eduardo. Principio de Analise e Projeto de Sistema com UML. Editora Campos, 3ª Tiragem. 1999.

Blair, Preston. 1994. Cartoon Animation. Laguna Hills: Walter Fosteer, 1994.

DTV,Site Oficial da TV Digital Brasileira.São Paulo,2013. Disponível em: < http://www.dtv.org.br/index.php/sobre-a-tv-digital/vantagens-da-tv-digital/>[Acesso em 04 de jan 2013].

Ginga RN, TV Digital Interativa. 2010. Disponível em: < http://gingarn.wikidot.com/gingaj > [Acesso em 03 de jul 2012]

MAIA, Lady Daiana de Oliveira. GameTVD: uma proposta de arquitetura para framework de jogos 2D para TV digital. Dissertação (Mestrado em Informática), Universidade Federal do Amazonas, Manaus, 2010.

Moreira, Marco A. Um mapa conceitual para interações fundamentais. Enseñanza de lãs Ciencias, Barcelona,8(2): 133-139, 1990.

Sommerville, Ian. Engenharia de Software. 9º Ed. São Paulo: Pearson Prentice Hall, 2011.



framework e3: uma estrutura para manipular imagens ...€¦ · framework e3: uma estrutura para...

Documents