Anais da XIII Mostra de Trabalhos em Informática

Transcrição

1

2 UNIVERSIDADE ESTADUAL DE MARINGÁ Departamento de Informática X Fórum de Tecnologia de Informática de Maringá Anais da XIII Mostra de Trabalhos em Informática 10 a 14 de Setembro de 2012 Maringá Pr, Brasil

3 UNIVERSIDADE ESTADUAL DE MARINGÁ X Fórum de Informática de Maringá Comissão Organizadora Prof. Flávio Arnaldo Braga da Silva (presidente) Profª. Heloise Manica Paris Teixeira Profª. Tania Fatima Calvi Tait Prof. Dante Alves Medeiros Filho Prof. Edson A. Oliveira Junior Profª. Sandra Ferrari Adlen Lucas Cachuba (aluno de CC) Kalinka Regina Castelo Branco, ICMC/USP José Remo Ferreira Brega, UNESP Luciana A. F. Martimiano, UEM Marcelo Lobosco, UFJF Márcia Pasin, UFSM Márcio Oyamada, UNIOESTE Márcio Augusto Souza, UEPG Maria Angelica Camargo Brunetto Maria Madalena Dias Marluce Rodrigues Pereira, UFLA XIII Mostra de Trabalhos em Informática Nârdenio A. Martins, UEM Coordenação Prof. Edson A. Oliveira Junior (presidente) Profª. Elisa Hatsue Moriya Huzita Prof. Franklin César Flores Prof. Sérgio Roberto Pereira da Silva Comitê de Programa Ademir A. Constantino, UEM Anderson Faustino da Silva, UEM Aparecido Fabiano Pinatti de Carvalho University of Limerick, Irlanda Avelino F. Zorzo, PUC-RS Cristine Gusmão, Nutes Dante Alves Medeiros Filho, UEM Delano M. Beder, UFSCAR Donizete C. Bruzarosco, UEM Elisa H. M. Huzita, UEM Franklin F. Flores, UEM Gisele Pappa, UFMG Heloise Manica Paris Teixeira, UEM João Ângelo Martini, UEM Jorge Bidarra, UNIOESTE José H. Saito, UFSCAR Josué Ramos, CTI Patrícia Kayser Vargas, UNILASALLE Renato Balancieri, UEM Rogéria C. G. Souza, UNESP Ronaldo A. L. Gonçalves, UEM Sérgio Roberto P. da Silva Sílvia Amélia Bim, UNICENTRO Tânia F. Tait, UEM Valéria D. Feltrim Vitor Santander, UNIOESTE Wagner Igarashi, UEM

4 UNIVERSIDADE ESTADUAL DE MARINGÁ XIII Mostra de trabalhos em Informática Apresentação O Fórum de Informática e Tecnologia de Maringá (FITEM) é um fórum de discussão de temas relevantes da Informática, composto de diversos eventos co-alocados associados à mini-cursos, palestras e mostra de trabalhos, entre outras atividades de caráter tecnológico ou científico. O FITEM é um evento bi-anual de considerável importância, realizado pelo Departamento de Informática da Universidade Estadual de Maringá. O público alvo do FITEM abrange profissionais, professores, pesquisadores, alunos de graduação e pós-graduação da área de Informática. Neste ano, a XIII Mostra de Trabalhos de Informática, evento co-alocado ao X FITEM, promoverá a apresentação de artigos científicos de alta qualidade, selecionados por um Comitê de Programa composto de doutores vinculados a diversas instituições renomadas de ensino superior. Autores interessados em contribuir com a XIII Mostra de Trabalhos de Informática foram convidados a submeter artigos escritos em Português que contribuam com o avanço científico e tecnológico nas diversas áreas da informática. Foram submetidos 25 artigos dos quais 8 foram aceitos como artigos completos e 3 como resumos estendidos. Comissão Organizadora Maringá, de Setembro de 2012

5 UNIVERSIDADE ESTADUAL DE MARINGÁ XIII Mostra de Trabalhos em Informática de Maringá Sumário Arquitetura de Computadores e Compiladores Experimentos preliminares na paralelização da aplicação geocomp no ambiente R 07 Carlos R. Beleti Jr., Ademir A. Constantino, Ronaldo A. L. Gonçalves Análise de desempenho do H.264 na plataforma BeagleBoard 15 Alexandre Augusto Giron, Marcio Seiji Oyamada Filtragem de componentes conexos com o uso da estrutura de dados max-tree 23 Danilo E. Gondolf, Franklin C. Flores, Ronaldo A. de L. Gonçalves Otimização em algoritmo de geração de estimativas iniciais para sistemas 29 iterativos não lineares Robertino Mendes Santiago Jr, Vladmir Ferreira Cabral, Lucio Cardozo Filho, Anderson Faustino da Silva, Ronaldo A. de Lara Gonçalves Engenharia de Software Métodos e técnicas de desenvolvimento de linha de produto de software para 37 sistemas e-commerce: um mapeamento sistemático Joyce M. Mathias, Edson A. Oliveira Junior Desenvolvimento de um sistema Web para análise e processamento de sinais dos 44 dados históricos de instrumentação da Usina Hidrelétrica de Itaipu Alessandra Bussador, Luiz Filipe Rondon de Moraes, Esdras Calemi Rodriguez Nieto, Rafael Ranieri dos Santos IrrRPG Builder: uma ferramenta livre para desenvolvimento de jogos eletrônicos de RPG 52 Andres Jessé Porfirio, Tony Alexander Hild

6 Uma análise da confiabilidade da aplicação de um questionário na equipe de TI de uma instituição de saúde 56 Karina Aparecida da Cruz Pinto, Maria Ludovina Aparecida Quintans Um Parser XMI para modelos UML de variabilidade 60 Leandro A. Lanceloti, Edson A. Oliveira Junior Sistemas Inteligentes e Visão Computacional Proposta de um sistema inteligente para recomendação de news 65 Nathan Siegle Hartmann, Sérgio Roberto Pereira da Silva Uma solução OLAP para empresas de venda de telefonia móvel empresarial 72 Rafael Voltolini, Clodis Boscarioli

7 Arquitetura de Computadores e Compiladores UEM - 10 A 14 DE SETEMBRO

8 Experimentos Preliminares na Paralelização da Aplicação geocomp no Ambiente R Carlos R. Beleti Jr., Ademir A. Constantino, Ronaldo A. L. Gonçalves Universidade Estadual de Maringá - Departamento de Informática Av. Colombo 5790, CEP beleti.junior@gmail.com, {ademir, ronaldo}@din.uem.br Resumo. A programação paralela vem sendo empregada nas mais diversas áreas de conhecimento com o objetivo principal de aumentar o desempenho das aplicações. Áreas como Física, Biologia, Química, Estatística, Geografia, entres outras, possuem aplicações que manipulam grandes quantidades de dados ou realizam operações exaustivas sobre eles, requerendo elevado tempo de processamento, dificultando as pesquisas nas respectivas áreas. Nessas áreas, um dos ambientes de desenvolvimento mais utilizados é o R, que disponibiliza pacotes que implementam diversas técnicas estatísticas e gráficas. Nesse ambiente, a aplicação geocomp foi desenvolvida para estender o uso do modelo geoestatístico bivariado para estruturas de dados composicionais. Sua execução, em determinadas condições, pode levar dias para ser concluída. Nesse contexto, o presente trabalho apresenta uma paralelização preliminar, parcial, desta aplicação e analisa o seu desempenho em experimentos que comprovam o ganho computacional. Palavras-chave: programação paralela, plataforma R, aplicação geocomp I. INTRODUÇÃO Com o avanço das aplicações científicas nas mais diversas áreas, a necessidade de máquinas computacionais com alto poder de processamento é eminente. Aliadas a essas máquinas, ferramentas que forneçam suporte a elas são necessárias. Aplicações complexas (grande quantidade de processamento) podem obter melhor desempenho quando implementadas de forma paralela. Entre outros objetivos, a programação paralela é utilizada para dividir o processamento em partes menores, as quais podem ser executadas em diversas unidades de processamento e os resultados individuais das partes serem agrupados para compor o resultado do processamento como um todo. A programação paralela não pode ser alcançada sem o uso de linguagens de programação (incluindo ferramentas ou bibliotecas) e de plataformas que suportem essa programação [1]. Uma importante decisão durante a paralelização é qual arquitetura utilizar, que permitirá também decidir qual modelo ou linguagem de programação utilizar. O fato de uma aplicação demandar uma grande quantidade de tempo para ser processada não significa que a mesma pode ser paralelizada com resultados satisfatórios. Esta possibilidade precisa ser analisada com cuidado. O ambiente R oferece suporte as mais variadas áreas de pesquisa, tais como Genética, Zoologia, Matemática, Estatística, Biologia, Química e Agronomia, entre outras. Seu código é open-source e, por isso, é amplamente utilizado e facilmente estendido por meio de pacotes (packages), os quais são extensões semelhantes às libraries na linguagem C. Atualmente, existem mais de pacotes disponíveis em sua homepage 1 oficial. Uma das aplicações desenvolvidas sobre o ambiente R, por Martins et al. [2], chamada geocomp, visa predizer em conjunto o padrão espacial de três componentes (areia, silte e argila) em uma área geográfica pré-determinada, por meio de uma aplicação baseada na teoria de dados composicionais. A aplicação utiliza funções que demandam alto tempo de processamento, e, portanto, a sua paralelização pode promover a obtenção de resultados de forma mais ágil mantendo a exatidão dos dados. Assim, o presente trabalho apresenta experimentos preliminares na paralelização da aplicação geocomp no ambiente R, focando no estudo do código sequencial e na proposição de métodos adequados de paralelização. O presente trabalho está organizado conforme segue. A seção II traz uma fundamentação teórica sobre os principais conceitos da programação paralela. A seção III apresenta o ambiente R e suas características principais. A seção IV descreve a proposta para desenvolvimento do trabalho. A seção V mostra os experimentos realizados. A seção VI traz 1 i Projeto apoiado pela Fundação Araucária. UEM - 10 A 14 DE SETEMBRO

9 os trabalhos futuros e as conclusões. Por fim, as referencias bibliográfica. II. FUNDAMENTAÇÃO TEÓRICA A programação paralela surge como uma evolução natural do desenvolvimento da programação ao longo dos anos, na medida em que os processadores se tornam paralelos. Ferramentas, modelos, paradigmas e arquiteturas de programação paralela foram desenvolvidas, possibilitando uma ampla combinação entre essas visando aumentar o desempenho da aplicação. Segundo Flynn [4], as arquiteturas de computadores podem ser classificadas, de acordo com os fluxos de instruções e de dados, em quatro classes: SISD (Single Instruction Single Data) ou fluxo único de instruções e fluxo único de dados, SIMD (Single Instruction Multiple Data) ou fluxo único de instruções e fluxo múltiplo de dados, MISD (Multiple Instruction Single Data) ou fluxo múltiplo de instruções e fluxo único de dados e MIMD (Multiple Instruction Multiple Data) ou fluxo múltiplo de instruções e fluxo múltiplo de dados. Entretanto, tal classificação não é abrangente o suficiente para incluir alguns modelos de computadores, como por exemplo, os processadores vetoriais e máquinas a fluxo de dados. Visando incluir tais computadores, Duncan [5] propôs uma extensão da classificação de Flynn, dividindo as arquiteturas em Síncronas e Assíncronas. Na classe Síncrona aparecem os processadores vetoriais, as arquiteturas sistólicas e as arquiteturas da classe SIMD subdividida em processadores matriciais e memória associativa. Na classe Assíncrona aparece a classe MIMD subdividida em arquiteturas de memória distribuída e de memória compartilhada, e uma nova classe intitulada de Paradigma MIMD, a qual é subdividida nas arquiteturas híbridas, fluxo de dados, redução e frente de onda. As arquiteturas MIMD são compostas por vários processadores independentes, os quais executam diferentes fluxos de instruções e dados. Esses processadores trocam informações usando algum mecanismo que depende do modelo arquitetural e organizacional da memória [6, 7], podendo essa ser compartilhada, distribuída ou compartilhada e distribuída. O modelo de memória compartilhada é aquele em que os processadores comunicam-se por meio da leitura e escrita em uma memória compartilhada que é igualmente acessível por todos os processadores. Um sistema computacional com memória compartilhada consiste basicamente de um conjunto de processadores independentes, um conjunto de módulos de memória e uma rede de interconexão. No modelo de memória distribuída, cada processador possui sua própria memória local, estando fracamente acoplados. Pelo fato de não haver compartilhamento de memória, os processos comunicam-se via troca de mensagens, transferindo explicitamente os dados entre os processadores. A troca de mensagem ocorre geralmente por primitivas de envio e recebimento, tais como aquelas existentes em MPI ou PVM. No modelo de memória compartilhada e distribuída, a memória global pode ser visualizada como sendo um espaço único e global, tendo ainda cada processador sua memória local. A rede de interconexão ainda é o canal que realiza a comunicação entre os diversos processadores. A plataforma de programação a ser utilizada tem fundamental importância na paralelização da aplicação. Existem várias linguagens que oferecem suporte à computação paralela, mas não existe uma que seja de uso geral [1]. III. AMBIENTE R R [8] é um software open-source que fornece uma ampla variedade de técnicas estatísticas e gráficas e é altamente extensível. Seu núcleo é uma linguagem interpretada que permite laços, desvios e funções. Suas principais características são a gratuidade e a sua disponibilidade para diversos sistemas operacionais. Foi escrito principalmente em C, com uma sintaxe semelhante a da linguagem C, mas é de fato uma linguagem de programação funcional com capacidades semelhantes ao Scheme [9]. Sua estrutura de dados e entidade básica é o objeto. Internamente, um objeto R é interpretado como uma estrutura SEXPREC C, cujo nome corresponde a uma expressão-s Lisp. Um objeto pode ser, por exemplo, um valor numérico ou um vetor de caracteres. O ambiente R é composto de três partes básicas: o R-base, os pacotes recomendados e os pacotes distribuídos. O primeiro contém as funções principais disponíveis quando o ambiente é iniciado. O segundo são pacotes que são instalados junto com o R-base, mas não são carregados quando o ambiente é iniciado. E o terceiro são pacotes que não são instalados junto com o R-base. Esses pacotes disponíveis na página do R são pacotes oficiais e fornecem funcionalidades específicas. Para serem utilizados devem ser copiados, instalados e carregados junto ao ambiente. Interfaces C e Fortran podem ser utilizadas junto ao ambiente R. As funções.c e.fortran oferecem uma interface padrão para o código compilado vinculado a R, quer em tempo de compilação ou por meio da função dyn.load. Elas são indicadas principalmente para código compilado C e FORTRAN 77, respectivamente, mas a função.c pode ser utilizada com outras linguagens que gerem interfaces C, por exemplo, C++. A escrita do código em C, usando estruturas de dados internas de R, pode ser feita por meio das UEM - 10 A 14 DE SETEMBRO

10 funções.call e.external. A sintaxe para uma chamada da função em R em cada caso é semelhante ao de uma chamada em C, mas as duas funções possuem interfaces C diferentes. A. Pacotes R Pacotes R podem ser distribuídos na forma de código fonte ou já compilados na forma binária. Instalar pacotes a partir de códigos fonte que contenham código C, C++ ou Fortran exige que os compiladores e as ferramentas relacionadas estejam instalados. Os binários são específicos da plataforma e, geralmente, não precisam de ferramentas especiais para instalação, porém cada plataforma tem sua especificação [8]. Características das aplicações que restringem o desempenho, tais como grande quantidade de dados e processamento prolongado de laços, motivam as pesquisas em programação paralela no ambiente R. Diversas aplicações apresentam essas restrições, por isso, pacotes foram criados para oferecer suporte à programação paralela em diversas arquiteturas, tais como clusters, sistemas multi-core e computação em grid,contendo funções especificas para diversas áreas de conhecimento. B. Pacotes para computação paralela em cluster. A maioria dos pacotes desenvolvidos para a programação de alto desempenho no R oferecem suporte a arquitetura de clusters ou memória distribuída. O pacote rpvm [9] fornece uma interface para PVM em que o usuário pode chamar programas executáveis escritos em linguagens compiladas como, por exemplo, chamar tarefas dentro de processos R. O pacote Rmpi [10] tem o objetivo de fornecer uma interface MPI para o ambiente R. Rmpi usa a LAM-MPI, a qual tem a implementação da API mais abrangente do que outras implementações. Em Bjornson et al. [11] foi apresentado o pacote nws que é baseado no conceito de conjunto de vinculações ou ligações. O pacote usa o modelo mestre-escravo e automaticamente realiza o balanceamento de cargas com funções de avaliação R. O pacote snow (Simple Network of Workstations) [12] também utiliza o modelo mestre-escravo. É bem flexível visto que pode realizar a comunicação utilizando sockets, PVM ou MPI. Os pacotes snowft e snowfall [13] são extensões do pacote snow. O primeiro inclui suporte de tolerância a falhas e o segundo adiciona várias funções para tarefas comuns em computação paralela, como por exemplo, carregar pacote e fontes no cluster e manipular variáveis entre os nós do cluster. No pacote biopara [25] a execução dos problemas paralelos sobre múltiplas máquinas pode ser distribuída. Ele usa conexões socket e possui apenas a função biopara(). O pacote taskpr é uma interface que utiliza a implementação LAM-MPI [14]. O pacote foreach [15] permite a iteração sobre elementos em uma coleção sem o uso de um contador explícito. É semelhante a instrução de repetição for com execução paralela. O pacote Rdsm [16] fornece um ambiente de programação baseado threads para R, que pode ser utilizado tanto em uma máquina multicore quanto em uma rede de máquinas distribuídas. Com ele, o programador tem uma visão do modelo de memória compartilhada, mesmo em uma rede com máquinas distribuídas. C. Pacotes para computação paralela em sistemas multi-core. Sistemas multi-core fornecem múltiplos núcleos de execução, tendo cada seqüência de execução ou thread, um ambiente de execução (hardware) próprio [11], o que os torna sistemas adequados suportar programação paralela. Pacotes para esses sistemas também estão disponíveis para a programação paralela no R. Os pacotes pnmath e pnmath0 utilizam as primitivas OpenMP e Pthreads, respectivamente, para fornecer paralelismo implícito no ambiente R [14]. Os pacotes oferecem acesso as funções paralelas, sem alterações no código do usuário. O pacote fork [18] fornece uma interface sobre o gerenciamento de processos Unix por meio de chamadas de API como fork, signal, wait, waitpid, kill e exit, que permitem a construção de programas que utilizam e gerenciam vários processos simultâneos. O rparallel ou pr [19] é considerado um framework de paralelização em tempo de execução. O foco de sua paralelização está basicamente nas operações de chamada de funções e loops. O projeto de sua arquitetura traz um analisador em tempo de execução e um motor de execuções paralelas (engine). O analisador faz o front-end do sistema, para realizar as analises sintática e semântica dos scripts R. O motor de execução faz o back-end do pr e recebe as entradas do analisador, com a responsabilidade de despachar tarefas, coordenar a comunicação entre os trabalhadores, supervisionar o local de processamento e coletar os resultados. O pacote romp [20] é um projeto que foi apresentado na conferência userr 2 em Tem o objetivo de transformar código R em Fortran, inserir diretivas OpenMP e compilar o código Fortran, para então depois utilizar o código compilado no R, tal pacote ainda não possui implementação. O pacote multicore [14] fornece formas de executar computação paralela no R sobre máquinas multicore. O pacote fornece métodos para coleta de resultados e tratamento de erros. 2 UEM - 10 A 14 DE SETEMBRO

11 D. Pacotes para computação paralela em sistemas de computação em grid. A computação em grid fundamentalmente é uma rede de recursos distribuídos que não estão em um mesmo local [21]. R também provê pacotes paralelos para grid. O pacote GridR [22] foi criado inicialmente para dar suporte ao projeto europeu de Ensaios Avançados Clinico-Genômico de Câncer (Advancing Clinico-Genomics Trials on Cancer) sendo utilizado como uma ferramenta para a execução remota de código R em grids. O pacote multir [23] ainda não está disponível, mas sua implementação terá o obejtivo de ser semelhante a dos pacotes snow e gridr. Já foi apresentado na conferência userr O projeto Biocep-R [26] é uma solução Java open-source para a integração e virtualização do acesso a servidores com R. Fornece um framework que permite a conexão dos elementos de um ambiente computacional. O projeto ainda está em desenvolvimento. O pacote RHIPE [24] também é uma solução Java que fornece uma interface que integra o ambiente R ao Hadoop 3 (plataforma Java para computação distribuída). IV. PROPOSTA O ambiente R é amplamente utilizado pelas mais diversas áreas de pesquisa, pois fornece uma grande variedade de métodos estatísticos, diversas funções matemáticas, além de importantes recursos gráficos. Sua ampla utilização trouxe o desafio do desenvolvimento de técnicas e ferramentas de suporte a programação de alto desempenho. A abordagem encontrada para vencer tal desafio foi a computação paralela, a qual oferece suporte para diversas arquiteturas paralelas. Ferramentas e pacotes foram desenvolvidos com o objetivo de otimizar as aplicações R, alguns de propósito geral e outros de propósito específico. A proposta principal deste trabalho é criar métodos de paralelização para a aplicação geocomp, usando pacotes R existentes. Apesar de serem direcionados para uma aplicação específica, pretende-se que tais métodos possam ser aproveitados em outras aplicações similares. Nesse sentido, a aplicação geocomp será um estudo de caso para tais métodos, devendo ser paralelizada sob diferentes versões. Tais versões serão analisadas, comparadas e avaliadas, destacando-se as vantagens e desvantagens em cada versão. A figura 1 ilustra a abordagem de desenvolvimento deste trabalho. Na figura pode-se identificar a aplicação geocomp como estudo de caso inicial e também outras aplicações, o que faz menção a criação de técnicas de paralelização não restritas a 3 Mais informações em: geocomp. Ainda na figura observa-se que são utilizados pacotes paralelos já existentes, que tem atuação sobre o R, definida a arquitetura ou modelo paralelo a ser utilizado. Inicialmente foram investigados os pacotes que atuam sobre o modelo de memória compartilhada. Figura 1 Arquitetura e organização do trabalho O interesse na paralelização da aplicação de Martins et al.[2] surgiu devido ao elevado tempo de processamento gasto em sua execução sob determinadas situações, que prejudica o desenvolvimento das pesquisas para as quais foi proposta. A aplicação apresenta-se na forma de um pacote para o ambiente R. O pacote de nome geocomp possui funções que realizam análises geoestatísticas de dados composicionais. De forma geral, suas funções ajustam um modelo geoestatístico bivariado para dados composicionais com três componentes, tanto pelo método de inferência clássico como por inferência bayesiana. Convém ressaltar que o objetivo do presente trabalho não é o de detalhar a aplicação geocomp. Para maiores informações do geocomp sugerimos o leitor consultar [2]. V. EXPERIMENTOS Para realizar a paralelização da aplicação geocomp, experimentos foram realizados com o pacote multicore [14], pois nos experimentos realizados no inicio da pesquisa, foi o que apresentou melhor desempenho. A aplicação foi executada com o script que obtém os valores preditos utilizando os dados do pivô. O script executado está na figura 2, que mostra uma codificação R contendo o carregamento de pacotes, de dados e chamadas a funções. Tal script possui duas funções que merecem destaque em suas execuções: a volta.quad e a volta.cokri. A primeira converte o vetor de valores esperados e uma matriz de covariância, do sistema de coordenadas cartesianas bidimensional para o espaço UEM - 10 A 14 DE SETEMBRO

12 amostral simplex utilizando quadratura gaussiana. A segunda transforma o vetor de valores esperados e matriz de covariância preditos no R 2 para o simplex utilizando simulação. Figura 2 - Script para obtenção dos valores preditos As máquinas utilizadas para as execuções pertencem ao cluster LECAD, cada uma contendo 2 processadores quad-core hyperthreading, 2394 MHz, 8 GB de memória cada, equivalendo-se a 16 núcleos de processamento no total. A paralelização da aplicação está sendo realizada por etapas e as funções objetos de estudo nos experimentos foram selecionadas de acordo com a análise de tempo de execução do script da figura 2. As funções volta.quad e volta.cokri que tiveram atenção especial, demandavam um tempo de processamento considerável na execução do script. De modo geral, as duas funções realizam trechos repetitivos implementados com a estrutura for. Dentro dessa, cada função realizava diversos cálculos numéricos e manipulação de dados. Tal estrutura foi substituída pela função mclapply do pacote multicore, que atribui cada iteração a um processador disponível. Para um melhor detalhamento do funcionamento das dependências dos dados entre iterações distintas no loop mais experimentos são necessários. A aplicação foi desenvolvida na linguagem R, com a utilização de rotinas já existentes em pacotes R. De forma geral, o problema de desempenho das funções está nas operações realizadas com o conjunto de dados que representa a matriz com média e covariância gerados pela execução da volta.cokri. Tal conjunto de dados é formado por um vetor de 5202 posições e uma matriz de 5202 x 5202, onde cada posição da matriz possui 5202 valores numéricos. O algoritmo 1 [2] ilustra parte da função volta.quad, a qual foi simplificada por questões de espaço. O trecho de código que necessita de maior quantidade de processamento foi a estrutura de repetição for (linhas 20 a 25) que realiza um laço com 2601 iterações. O mesmo trecho já modificado com mclapply pode ser visualizado no algoritmo 2. Algoritmo 1 Segmento da função volta.quad 1. volta.quad <- 2. function(med.cov, n.pontos=7, Variancia=FALSE){ 3. mu.ck <- med.cov[[1]] 4. sigma.ck <- med.cov[[2]] 5. desvio.pd <- sqrt(diag(sigma.ck)) 6. ic.mu <- data.frame(mu.ckqnorm(0.975)*desvio.pd, mu.ck+qnorm(0.975)*desvio.pd) 9. names(ic.mu) <- c("l.minimo","l.maximo") 10. g <- function(y,mu,r,pos){ 12. #... # 13. return(resultado[pos]) 14. } 15. quad.gauss.comp <- function(mu,r,func=g,pos,np=n.pontos){ 16. #... # 17. return(soma) 18. } 19. #... # 20. for(i in 1:n.linhas){ 21. sigma.ck <- med.cov[[2]][seq1[i]:seq2[i],seq1[i]:seq2[i]] 22. mu.ck <- med.cov[[1]][seq1[i]:seq2[i]] 23. cp <- quad.gauss.comp(mu=mu.ck,r=chol(sigma.ck),func=g, pos=c(1:3),np=n.pontos) 24. compo.md[i,] <- cp 25. } 26. #... # 27. return(retorna) 28. } Em sua execução sequencial o tempo médio de processamento da função foi de 1250,43 segundos. As execuções paralelas foram realizadas com 1, 2, 4, 8 e 16 núcleos de processamento e seus tempos de execução são exibidos na figura 3. Observa-se que o tempo de processamento paralelo foi maior que o sequencial quando se usa um único processador, o que pode ser justificado pelo overhead causado pela inserção de código que trata da paralelização. Para as demais execuções, os tempos foram reduzidos de acordo com a quantidade de processadores utilizados. A tabela I mostra o speedup e eficiência das execuções. Algoritmo 2 Paralelização da função volta.quad 1. require(multicore) 2. mclapply(1:n, function(i) { 3. sigma.ck <- md.cov.ck[[2]][seq1[i]:seq2[i],seq1[i]:seq2[i]] mu.ck <- md.cov.ck[[1]][seq1[i]:seq2[i]] 4. cp <- quad.gauss.comp(mu=mu.ck,r=chol(sigma.ck),func=g, pos=c(1:3),np=7) 5. compo.md[i,] <- cp 6. } 7. ) UEM - 10 A 14 DE SETEMBRO

13 mat.cokri[[1]],mat.cokri[[2]]) 8. seq1 <- seq(1,nlinhas,by=2) 9. seq2 <- seq(2,nlinhas,by=2) 10. y1 <- g[seq1] 11. y2 <- g[seq2] 12. gerado <- data.frame(y1,y2) 13. compos <- agl(gerado) 14. compos1 <- cbind(compos,compos1) 15. } Figura 3 Número de threads e tempo em segundos Apesar do speedup aumentar com o aumento do número de núcleos de processamento, a eficiência diminuiu, sendo que a maior perda da eficiência ocorreu com 16 núcleos de processamento. Entretanto, ressalta-se que a plataforma de hardware utilizada não contém exatamente 16 cores, mas sim 8 cores dual (hyperthread) o que pode justificar esta desaceleração uma vez que os recursos de hardware são compartilhados entre os processos que executam em hyperthreading. TABELA I SPEEDUP E EFICIÊNCIA DA EXECUÇÃO Processadores Speedup Eficiência 2 1,61 0, ,08 0, ,90 0, ,29 0,580 O segmento de código da segunda função, a volta.cokri, pode ser visualizado no algoritmo 3. Os parâmetros dessa função são a matriz de covariância predita, o vetor correspondente ao número de simulações, um parâmetro lógico e vetor numérico correspondente ao número de confiança. Foi identificado que o maior tempo de processamento se concentra dentro da estrutura de repetição for. Nessa é realizada a chamada a função mvrnorm à qual faz referência a um código objeto Fortran, ou a uma função Fortran compilada. Tal função tem o nome de eigen.o ou (eigen.f). Da mesma forma, a paralelização foi realizada sobre a estrutura for por meio da função mclapply do pacote multicore. Tal paralelização pode ser visualizada no algoritmo 4. Nesse experimento, a execução sequencial resultou em 36392,27 segundos. As execuções paralelas também foram realizadas com 1, 2, 4, 8 e 16 núcleos de processamento. Os tempos de execução podem ser visualizados na figura 4. Algoritmo 3 Segmento da função volta.cokri 1. volta.cokri <- 2. function(mat.cokri, num.simu, retorna.tudo=false, int.conf=0.95){ 3. nlinhas <- dim(mat.cokri[[1]])[1] 4. compos1 <- data.frame(matrix(nrow=nlinhas/2,ncol=3)) 5. compos <- data.frame(matrix(nrow=nlinhas/2,ncol=3)) 16. compos2 <- as.matrix(compos1) 17. dim.vetor <- num.simu*3 18. sy1 <- seq(1,dim.vetor,by=3) 19. sy2 <- seq(2,dim.vetor,by=3) 20. sy3 <- seq(3,dim.vetor,by=3) 21. amostra1 <- as.matrix(compos2[,sy1],ncol=num.simu) 22. amostra2 <- as.matrix(compos2[,sy2],ncol=num.simu) 23. amostra3 <- as.matrix(compos2[,sy3],ncol=num.simu) 24. #... # 25. } Como pode ser visualizado na figura 4, os tempos de execução para 4, 8 e 16 núcleos tiveram um comportamento inesperado em comparação ao resultado da execução da função volta.quad. Tal comportamento levou a um estudo detalhado da função volta.cokri e como já observado anteriormente, acredita-se que um dos motivos desse comportamento deve-se ao fato da função mclapply não conseguir ter um controle total da execução paralela sobre um código externo em Fortran. Além disso, percebe-se que o laço da volta.cokri possui muita dependência de dados entre suas iterações. Certamente, o paralelismo que pode ser obtido em iterações de um laço normalmente é bastante limitado e no máximo se consegue um efeito parecido com o pipeline de software [3]. Algoritmo 4 Paralelização da função volta.cokri 1. require(multicore) 2. mclapply(1:n, function(i) { 3. sigma.ck <- md.cov.ck[[2]][seq1[i]:seq2[i],seq1[i]:seq2[i]] mu.ck <- md.cov.ck[[1]][seq1[i]:seq2[i]] 4. cp <- quad.gauss.comp(mu=mu.ck,r=chol(sigma.ck),func=g, pos=c(1:3),np=7) 5. compo.md[i,] <- cp 6. } 7. ) Figura 4 Número de threads e tempo em segundos 6. for(i in 1:num.simu){ 7. g <- mvrnorm(n=1, UEM - 10 A 14 DE SETEMBRO

14 A tabela II mostra o speedup e eficiência das execuções da função volta.cokri. Na tabela pode-se verificar a ineficiência com 4 e 8 processadores. TABELA II SPEEDUP E EFICIÊNCIA DA EXECUÇÃO Processadores Speedup Eficiência 2 1,72 0,86 4 1,65 0, ,74 0, ,18 0,136 Os tempos apresentados nos experimentos foram coletados com três execuções para cada configuração de processadores, apresentando-se a média entre tais execuções em cada configuração. VI. CONCLUSÕES E TRABALHOS FUTUROS Devido à amplitude de suas funcionalidades por meio dos pacotes desenvolvidos, R é um dos ambientes mais utilizados para o desenvolvimento de aplicações de cunho estatístico. Sua ampla utilização trouxe desafios quanto ao desempenho das aplicações. Tais desafios que podem ser vencidos por meio da computação paralela. Diversos pacotes foram desenvolvidos com essa finalidade, mas alguns sendo tão abstratos que sua utilização se torna uma tarefa dispendiosa. Os resultados dos experimentos realizados mostram os benefícios da paralelização parcial da aplicação geocomp, uma vez que outros segmentos de código ainda precisam ser paralelizados. A paralelização da função volta.cokri, apresentou certa desaceleração em algumas execuções, e estas precisam ser melhor analisadas. A função possui rotinas que fazem chamadas a funções objeto (código compilado) em Fortran, de onde supõe-se o problema de ineficiência. Pretende-se ainda estender os experimentos para o modelo de memória distribuída por meio de pacotes como rpvm, Rmpi ou snow. Após a conclusão de tais experimentos, extrair as técnicas utilizadas na readequação da aplicação geocomp em suas versões paralelas, com o objetivo de criar um conjunto de técnicas para auxiliar o desenvolvimento de aplicações paralelas no R. Com as técnicas estabelecidas realizar testes com outras aplicações R, para comprovar a validade e eficiência de tais técnicas. REFERENCIAS BIBLIOGRÁFICAS [1] Evans, D. J. V., Goscinski, A. M., A Survey of Basic Issues of Parallel Execution on a Distributed System, Technical Report 03/95, School of Computing and Mathematics, Deakin University, Geelong, Victoria, Australia, [2] Martins, A. B. T., Ribeiro JR, P. J., Bonat, W. H., Um modelo geoestatístico bivariado para dados composicionais, Revista Brasileira de Biometria, Vol. 27, No., 2009, p [3] Douillet, A.; Gao, G. R. Software-Pipelining on Multi-Core Architectures. 16th Int. Conference on Parallel Archicteture and Compilation Techniques (PACT 07), IEEE Computer Society, [4] Flynn, M., Very High-speed Computing Systems, Proceedings of the IEEE, Vol. 54, No. 12, December, 1966, pp [5] Duncan, R., A survey of parallel computer architectures, IEEE Computer Society Press, Vol. 23, No. 2, Feb 1990, pp.5-16,. [6] Giloi, W. K., Parallel programming models and their interdependence with parallel architectures, Programming Models for Massively Parallel Computers, Proceedings, Vol., no., Sep 1993, pp.2-11, [7] El-Rewini, H., Abd-El-Barr, M., Advanced computer architecture and parallel processing, Vol. 2, John Wiley & Sons, Inc., Hoboken, New Jersey, Edition 1, February [8] R Development Core Team., R Foundation for Statistical Computing, Vienna, Austria, Version , July [9] Li N. M., Rossini, A. J., RPVM: Cluster Statistical Computing in R, The R News, Vol. 1(3), No., September 2001, p [10] Yu, H., Rmpi: Parallel statistical computing in R, The R News, Vol. 2(2), No., June 2002, p [11] Bjornson, R., Carriero, N., Weston, S, Python NetWorkSpaces and Parallel Programs, Dr. Dobb's Journal, May 2011, 05. [12] Rossini, A. J., Tierney, L., Li, N. M., Simple Parallel Statistical Computing in R, Technical Report 193, UW Biostatistics Working Paper Series, March [13] Binder, H., Knaus, J., Porzelius, C., Schwarzer, G, Easier Parallel Computing in R with snowfall and sfcluster, The R Journal, Vol. 1(1), May 2009, [14] Schmidberger, M., Morgan, M., Eddelbuettel, D., YU, H., Tierney, L., Mansmann, U., State of the Art in Parallel Computing with R, Journal of Statistical Software, Vol. 31, Issue 1, 2009, p [15] Analytics, R., Package foreach, Revolution Analytics, Version 1.3.2, May, [16] Matloff, N., Package Rdsm, Version 1.1.0, February, [17] Akhter, S., Roberts, J., Multi-Core Programming, Increasing Performance through Software Multi-threading, Chapter 1, David J. Clark, Estados Unidos, First printing, April 2006, p [18] Warnes, G. R., Package fork, Version 1.2.2, May [19] Ma, X., Li, J., Samatova, N. F., Automatic Parallelization of Scripting Languages: Toward UEM - 10 A 14 DE SETEMBRO

15 Transparent Desktop Parallel Computing, Parallel and Distributed Processing Symposium, IPDPS IEEE International, Vol., No., March 2007, pp.1-6, [20] Jamitzky, F., ROMP An OpenMP Binding for R, UseR! 2008: the R user conference. Book of Abstracts. Technische Universität Dortmund, Germany. August, 2008, p. [21] Zhang, S., Chen, X., Zhang, S., Huo, X., The comparison between cloud computing and grid computing, Computer Application and System Modeling (ICCASM), 2010 International Conference on, Vol.11, No., Oct. 2010, p.v11-72-v11-75, [22] Wegener, D., Sengstag, T., Sfakianakis, S., Ruping, S., Assi, A., GridR: An R-Based Grid- Enabled Tool for Data Analysis in ACGT Clinico- Genomic Trials, Proceedings of the 3rd International Conference on e-science and Grid Computing (escience 2007). Bangalore, India, 2007, p [23] Grose, D. J., Distributed Computing Using the multir Package, UseR! 2008: the R user conference. Book of Abstracts. Technische Universität Dortmund, Germany, August, 2008, p. [24] Guha, S., rhipe Documentation, Saptarshi Guha, Palo Alto, Release 0.61, August, [25] Lazar, P.; Schoenfeld, D., The biopara package, Version 1.4, July, [26] Chine, K., What the Cloud can do for Computational Life Sciences: Biocep-R's Unified Perspective, Bio IT World, Conference & Expo, Cambridge UK, UEM - 10 A 14 DE SETEMBRO

16 Análise de Desempenho do H.264 na plataforma BeagleBoard Alexandre Augusto Giron Laboratório de Sistemas Computacionais Universidade Estadual do Oeste do Paraná - UNIOESTE Cascavel - PR alexandre.giron@unioeste.br Marcio Seiji Oyamada Laboratório de Sistemas Computacionais Universidade Estadual do Oeste do Paraná - UNIOESTE Cascavel - PR marcio.oyamada@unioeste.br Resumo O desenvolvimento de sistemas embarcados possui requisitos restritos de consumo de potência, desempenho, tempo de projeto entre outros. A decodificação de vídeo é uma aplicação encontrada em vários sistemas embarcados que possui tais requisitos sendo utilizado em smartphones e TV digital. Este trabalho avalia o desempenho e o consumo de potência da decodificação de vídeo no padrão H.264 em uma plataforma embarcada. A arquitetura utilizada é compatível com a OMAP 3530, um MPSoC (multiprocessor system-on-chip) heterogêneo composto por dois processadores: um ARM Cortex A8 e outro DSP C64x+. Palavras-chave: H.264, decodificação de vídeos, arquiteturas MPSoC heterogêneas, OMAP I. INTRODUÇÃO Os sistemas embarcados são encontrados nos mais diversos aparelhos, como aparelhos celulares, automóveis, TV Digital. Dentre as características desses produtos, em muitos casos se sobressai a mobilidade, necessitando da alimentação por baterias do sistema. Um sistema embarcado (SE), segundo Marvedel [1], é um sistema de processamento de informações que é incorporado em um produto maior e, normalmente, não é diretamente visível pelo usuário. A necessidade por melhorias de desempenho e menor consumo de potência, move o mercado dos sistemas embarcados. Diferentemente do desenvolvimento de sistemas para desktop, um sistema embarcado é desenvolvido pela integração otimizada de hardware e software. No projeto tanto a arquitetura quanto os componentes de software devem ser considerados para que os requisitos sejam atendidos. Um exemplo de SE já citado é a TV Digital, que se utiliza de padrões de áudio e de vídeo, visando atender a um nível de qualidade (de som e de imagem) superior ao da TV analógica comum. Para o caso da TV Digital brasileira, o padrão de vídeos utilizado é o H.264 [2]. Desenvolvido com base no padrão MPEG, o H.264 se mostrou eficiente em termos de melhorias em qualidade de imagem e em taxas de compressão altas, obtendo mesma qualidade com aproximadamente a metade da taxa de bits comparado ao padrão MPEG-2 [12]. O Sistema Brasileiro de Televisão Digital SBTVD [3] utiliza o H.264 High Profile nas suas especificações de compressão de vídeo digital. A grande maioria dos sistemas de difusão terrestre de TV digital utiliza o padrão MPEG-2, sobre o qual o H.264 foi desenvolvido, ou seja, o H.264 é uma evolução do padrão MPEG-2 e do MPEG-4. O processo da codificação e posterior decodificação para que o vídeo seja visualizado é composto por diversas operações com custo computacional considerável, principalmente se tratando de vídeos de alta definição. Nesses casos, é necessário alto poder de processamento e memória disponível para obter o desempenho esperado (decodificação em tempo real). Neste caso deve-se considerar o gasto de potência e também custos de hardware. Contudo, outros aspectos devem ser considerados, como por exemplo, o requisito de tolerância a falhas de um SE é de extrema importância, principalmente os sistemas embarcados críticos, como sistemas aviônicos e de controle de usinas nucleares. Somando-se a isso, o tempo de projeto, design e requisitos de tempo real são fatores que tornam o desenvolvimento de sistemas embarcados extremamente complexo [4]. A escolha da arquitetura também merece atenção especial no desenvolvimento desses sistemas. Os componentes devem ser escolhidos visando integrar de maneira otimizada com o software. Para aplicações que visam o desempenho, tamanho e consumo de energia reduzido, podem ser utilizadas plataformas SoC (System-on-Chip) [13]. Em outras situações, podem ser utilizadas plataformas FPGA (Field-Programmable Gate Arrays) [5], nas quais, geralmente, os custos de produção são reduzidos para um volume baixo de unidades [6]. Um exemplo de plataforma SoC multiprocessada é a OMAP 3530 [7], utilizada pela placa de desenvolvimento BeagleBoard [8]. Ela integra, em um único chip, dois processadores, um deles é o ARM Cortex-A8, e o outro é um processador de sinais digitais (DSP) C64x+. Assim, este trabalho visa avaliar a performance do decodificador de vídeos H.264 na placa BeagleBoard-xM, comparando o desempenho com o gasto de potência pela aplicação. A organização deste trabalho se encontra da seguinte maneira: na Seção II são descritas as características e o funcionamento do processo da decodificação de vídeos do padrão H.264. Na Seção III, os componentes e a justificativa da escolha da arquitetura utilizada são apresentados. Por conseguinte, na Seção IV são mostrados os resultados obtidos e na Seção V as conclusões e trabalhos futuros. UEM - 10 A 14 DE SETEMBRO

17 A. Características II. PADRÃO DE VÍDEOS H.264 O padrão H.264 é composto de um codificador e de um decodificador. O codificador tem a função de compactar o vídeo digital, para economizar espaço exigindo assim uma menor largura de banda para transmissão. Esse padrão é dividido em perfis de aplicação, ou seja, ele se adapta ao dispositivo que irá utilizá-lo, permitindo ser executado em diferentes dispositivos, fato que justifica sua popularidade. Eles são descritos a seguir [12]: Perfil Baseline: criado com o foco em dispositivos com recursos limitados. Não suporta a codificação CABAC (Context-Adaptive Binary Arithmetic Coding), partições de frame (slices) tipo B. Perfil Main: destinado a consumidores finais de eletrônicos, servidores de vídeo e broadcast. Suporta vídeos da resolução QCIF (176x144) até Full HD (1920x1080). Perfil Extended: criado para aplicações de streaming de vídeo, ele possui ferramentas para facilitar a troca entre diferentes bit streams. Perfil High: Incluído posteriormente aos perfis anteriores, possui codificação com mais eficiência e praticamente substituiu o perfil Main. Pelo fato de que o H.264 permitir o envio dos dados do vídeo fora de ordem é necessário que ocorra a etapa da Reordenação. Após essa etapa, a Quantização Inversa e a Transformada Inversa são iniciadas, cujas funções são, respectivamente, recuperar os coeficientes truncados durante a codificação e passá-los para o domínio espacial. A Transformada Inversa produz o erro residual. A partir disso, é realizada a Compensação de Movimentos (CM), etapa que compõe a interpredição. Em muitos casos, os quadros próximos de uma sequência possuem características semelhantes (como o fundo imagem), diferindo apenas na movimentação de objetos na cena. Então a função da CM é diminuir as redundâncias de dados entre esses frames, utilizando frames de referência, diminuindo assim a taxa de bits do vídeo comprimido. O processo da codificação de vídeos pode ser resumido na transformação de um vídeo em uma sequência de bits. Já o decodificador faz o processo contrário, que consiste em extrair as informações de um vídeo compactado, recriando a sequência de imagens para serem exibidas na tela de um computador, por exemplo. É na decodificação que se encontra o foco deste estudo. B. Decodificação H.264 Basicamente, a decodificação se trata de extrair as informações de um vídeo compactado, recriando a sequência de imagens, permitindo posteriormente que estas sejam exibidas em tela para visualização. No H.264, a decodificação é dividida em etapas, cada qual com uma função específica sobre a stream de entrada, ou seja, o vídeo compactado. São elas: descompressão (entropy decoder), reordenação, quantização inversa (Q -1 ), transformada inversa (T -1 ), compensação de movimentos (MC), predição Intra e Filtragem [9]. O diagrama das etapas do decodificador H.264 pode ser visto na Figura 1. A primeira etapa consiste em receber os bits comprimidos da stream de entrada, oriundos de meios como cabo, ar ou internet e encapsulados em pacotes de dados via NAL (Network Abstraction Layer). A segunda etapa produz os elementos de sintaxe através desses bits, que podem estar codificados em CAVLC (Context- Adaptive Variable-Length Coding) ou CABAC (Context- Adaptive Binary Aritmetic Coding). Essa etapa é denominada Decodificação de Entropia, ou Entropy Decoding. Figura 1. Etapas da decodificação de um vídeo H.264. Adaptado de [9]. Já na predição Intra, é realizado um processo de predição espacial, que consiste, basicamente, em reduzir as redundâncias a partir de um mesmo quadro. Para isso, esse tipo de predição se utiliza de informações de blocos vizinhos apenas do quadro a ser comprimido. Por fim, é realizada a filtragem, para suavizar as bordas entre os blocos vizinhos de um quadro, e então o resultado disso é o quadro reconstruído, ou seja, decodificado. Os principais tipos de quadros são: I, P, e B-frames. O tipo do quadro define a predição utilizada, sendo que o tipo I é um frame que usa predição Intra, e a sua decodificação é UEM - 10 A 14 DE SETEMBRO

18 independente dos demais. O tipo P usa predição Intra e Inter, sendo que sua decodificação depende de um ou mais frames anteriores, e o tipo B utiliza predição Intra e a sua predição Inter depende de frames anteriores a ele ou posteriores a ele [10]. III. PLACA DE DESENVOLVIMENTO BEAGLEBOARD Neste trabalho, a placa de desenvolvimento utilizada é a BeagleBoard-xM [25], que inclui uma plataforma MPSoC DM3730, compatível com a família de plataformas OMAP 3, composta de dois processadores no mesmo chip. A plataforma DM3730, inclui um processador de propósito geral (ARM Cortex-a8), amplamente utilizado no mercado de embarcados [11], e um DSP (C64x+), possibilitando a execução otimizada de algoritmos de processamento de sinais digitais. Essa placa de desenvolvimento possui interfaces e drivers de vídeo, som, USB e de rede, além das dimensões reduzidas (3 x3 ) e do baixo consumo de potência (em torno de 2W, dependendo da quantidade de periféricos conectados à placa). Além disso, o fato de que a BeagleBoard-xM pode ser adquirida a partir de US$ 149 em lojas dos Estados Unidos [14], mostra que o custo de aquisição é relativamente baixo. O resumo dos componentes da placa pode ser visualizado na Tabela I. TABELA I. Processadores Memória Periféricos e conexões Armazenamento BEAGLEABOARD-XM (CARACTERÍSTICAS E FOTO DA PLACA) [26]. - 1 GHz ARM Cortex-A8 (Arquitetura RISC) - TMS320C64x+ (800MHz) (Arquitetura DSP) - 512MB DDR RAM - HDMI - S-Video - 4 portas USB - Entrada e saída Stereo - Porta RS232 - Connector JTAG - Slot Cartão SD A Beagleboard-xM suporta diversas distribuições do sistema operacional Linux, como Ubuntu, Android, Debian e Angstrom. Isso torna o desenvolvimento mais flexível, pois várias aplicações e projetos em código aberto ou livre para uso estão disponíveis e são compatíveis com essas distribuições. Nesta plataforma, o sistema operacional é armazenado em um cartão SD (Secure Digital). A BeagleBoard-xM agrega dois processadores com conjunto de instruções diferentes. O ARM é voltado para propósito geral, possuindo uma arquitetura RISC de 40 registradores (33 de propósito geral e 7 de estado) [15], o DSP possui instruções otimizadas para processamento de imagens e vídeo, com a execução de até 8 instruções por ciclo de processamento e 64 registradores no total [17][28]. Em um ambiente heterogêneo, o processo de desenvolvimento difere em muitos aspectos do processo em um ambiente homogêneo. Nas arquiteturas multiprocessadas heterogêneas, é necessário se utilizar de um compilador específico para cada tipo de processador que é utilizado, o que quer dizer que o binário executável para um processador DSP será diferente do binário para um processador de arquitetura RISC, por exemplo. Assim, torna o processo de desenvolvimento mais complexo, necessitando tratamentos diferenciados nas etapas de desenvolvimento, principalmente em relação ao particionamento de funcionalidades e mapeamento correto para cada processador. Wolf e Jerraya [13] descrevem as vantagens de MPSoC heterogêneos em relação aos homogêneos. Como vantagem principal os autores mostram que MPSoCs heterogêneos são mais eficientes no requisito de consumo de potência, pois eles se utilizam de diferentes conjuntos de instruções para diferentes processadores, tornando a execução de determinadas tarefas mais eficiente. Um exemplo típico é a utilização de processadores de sinais digitais DSP, para o processamento de aplicações multimídia, os quais tendem a consumir menos energia do que processadores de propósito geral, neste tipo de tarefa. Para o desenvolvimento de aplicações para a Beagleboard pode-se optar pela codificação, compilação e testes de aplicações diretamente na placa. No entanto, devido aos recursos escassos, uma outra solução é a utilização de crosscompilers para o processador ARM, possibilitando utilizar um ambiente de desenvolvimento no desktop. O desenvolvimento dos módulos DSP deve ser realizado em um desktop, pois é necessário um compilador específico, disponibilizado pela Texas Instruments, que é capaz de gerar código para o DSP C64x+. Esse compilador é gratuito, e disponível para os sistemas operacionais Linux e Windows. Após a compilação do código o mesmo deve ser copiado para o armazenamento da placa, para ser executado. A. DM3730 O MPSoC DM3730 pertence a família OMAP3 [16] (Open Media Application Plataform), é destinado a aplicações UEM - 10 A 14 DE SETEMBRO

19 multimídias móveis e portáveis desenvolvida pela Texas Instruments (TI). A Tabela II apresenta alguns produtos que utilizam o MPSoC da família OMAP 3. TABELA II. DISPOSITIVOS QUE CONTÉM A PLATAFORMA OMAP 3 [4] Device Type MPSoC Touch Book Netbook OMAP 3530 Pandora Portable Video Game OMAP 3530 BeagleBoard C4 Evaluation Kit OMAP 3530 BeagleBoard-xM Evaluation Kit DM3730 DevKit8000 Evaluation Kit OMAP 3530 DevKit8500D Evaluation Kit DM 3730 Zoom TM Torpedo Evaluation Kit DM 3730 Motorola Milestone Smartphone OMAP 3430 Nokia N9000 Smartphone OMAP 3430 Samsung i8910 Smartphone OMAP 3430 Galaxy S Smartphone OMAP 3630 Milestone 2 Smartphone OMAP 3630 Droid 2 Smartphone OMAP 3630 InHand Hydra-T3 Tablet DM 3730 Como já descrito anteriormente, essa plataforma possui um processador de propósito geral ARM Cortex-A8, e um processador de sinais digitais, DSP C64x+. Esses dois processadores serão abordados com mais detalhes a seguir. B. Processador ARM ARM (Advanced Risc Machine) é uma arquitetura RISC (Reduced Instruction Set Computer) de 32 bits, com baixo consumo de energia, desenvolvida pela empresa britânica ARM Holdings [18]. Essa arquitetura é usada na grande maioria dos sistemas embarcados atuais. Em 2008, 95% dos aparelhos celulares vendidos possuíam ao menos um processador ARM [31]. A ARM Holdings possui os direitos autorais sobre a arquitetura e a licencia para outras companhias que desejam produzir processadores deste tipo de arquitetura. As licenças são de dois tipos: de implementação e de arquitetura. A licença de implementação provê completa informação requerida para o projeto e produção de circuitos integrados contendo o processador ARM. Já a licença de arquitetura licencia o desenvolvimento do próprio processador compatível com o conjunto de instruções (ISA) ARM. Diversos fatores tornaram o processador ARM diferente de outros processadores de propósito geral. Com seu núcleo RISC e arquitetura simples ele pode ser fabricado usando um menor número de transistores e consequentemente possui uma menor área e um menor custo. Apesar de possuir muitas características da arquitetura RISC, a arquitetura ARM não é inteiramente RISC. Quando os primeiros computadores RISC surgiram, seus objetivos eram diminuir a complexidade das instruções e obter um aumento da frequência e desempenho através do uso de pipeline. Questões como o consumo de energia, tamanho do processador e baixo custo de produção não eram requisitos importantes na época, apesar da arquitetura RISC contribuir em alguns deles por causa de sua simplicidade. Os processadores ARM são destinados a dispositivos embarcados e seus requisitos levam em conta outros requisitos como os já mencionados. Um dispositivo embarcado deve consumir a menor quantidade de energia possível, pois a duração de sua bateria é um fator crítico. O tamanho do dispositivo e o seu custo final também são fatores importantes em um mercado tão competitivo. Processadores RISC tendem a gerar um executável maior, devido a necessidade de um maior número de instruções para representar um mesmo comportamento se comparado com arquiteturas CISC. Com os dispositivos embarcados, onde os requisitos de memória são restritos, algumas alterações foram realizadas no intuito de diminuir a memória ocupada pelo código. Desta forma, algumas instruções não simples foram adicionadas as instruções ARM visando melhorar o desempenho em sistemas embarcados. Uma característica que torna os processadores ARM ideais para sistemas embarcados é a possibilidade de estender o conjunto de instruções através da adição de coprocessadores. Os coprocessadores são processadores de propósito específico, destinados a ampliar as funcionalidades do processador ou melhorar o desempenho para determinados grupos de instruções. O núcleo ARM, por exemplo, não contém instruções para ponto flutuante, sendo necessária a emulação por software destas operações. Porém, é possível adicionar um coprocessador de ponto flutuante à arquitetura melhorando o desempenho em operações que envolvam números reais. Essa possibilidade de expansão de funcionalidade dos processadores ARM torna a arquitetura flexível para grande parte dos sistemas embarcados. Um dispositivo que não necessite de cálculos em ponto flutuante pode usar um processador ARM sem a unidade de processamento de ponto flutuante. Isso diminui o custo final e o tamanho do processador. Por outro lado, um dispositivo que execute um grande número de operações em ponto flutuante pode incluir ao núcleo ARM um processador VFP que executa operações em ponto flutuante, com simples e dupla precisão, seguindo o formato IEEE 754. O processador ARM Cortex-A8 é baseado na arquitetura ARMv7 e sua frequência pode variar de 300MHz até 1GHz, dependendo do modelo do processador. Com instruções que operam sobre vetores de dados de 128 bits, ele acelera o processamento multimídia de áudio e de vídeo, entre outros. C. Processador DSP Em muitas situações, a maioria das informações costuma ser representada por sinais, variações físicas que podem ser mensuradas, como luz e temperatura. Sinais estes que são analógicos por natureza e caracterizados por serem contínuos ao longo do tempo. UEM - 10 A 14 DE SETEMBRO

20 Na medida em que se torna necessário tratar estes sinais analógicos computacionalmente, é necessário representá-los em um formato digital. Um sinal digital, nesse caso, nada mais é do que uma sequência discreta de estados que codifica uma mensagem. Uma imagem JPEG, um vídeo AVI e um pacote TCP/IP são alguns exemplos de sinais digitais. Normalmente, funções de processamento digitais são operações matemáticas em sinais de tempo real, repetitivas e numericamente intensivas [19]. Para tratar essa classe de processamento, surgiram os processadores de sinais digitais. Uma vez que os processadores DSP são projetados para executar com eficiência algoritmos de processamento de sinais digitais, com recursos limitados, sua arquitetura é diferente das encontradas nos processadores de propósito geral, e assim eles possuem vantagens em termos de desempenho, custo e consumo de energia [20, 21]. No OMAP 3530, o processador DSP é o TMS320C64x+, fabricado também pela Texas Instruments. Ele faz parte da família de processadores c64x que possuem um conjunto de instrução (ISA) compatível entre os processadores [22]. As especificações do C64x são apresentadas na Tabela III. TABELA III. Clock Frequency Instructions per second Cache Registers Functional Units Instructions fetched by cycles Operands fetched by cycle Arithmetic ESPECIFICAÇÕES DO PROCESSADOR DSP C64X+. Trabalhando com um relógio de frequência de 800MHz, o C64x+ alcança o desempenho de até 6400 milhões de instruções por segundo (MIPS). Esta taxa de processamento é alcançada através de seus 64 registradores de 32 bits de propósito geral e oitos unidades funcionais. Com a máxima paralelização possível, cada unidade funcional irá executar uma das 8 instruções contidas numa instrução longa VLIW a cada ciclo de relógio, totalizando 8 instruções por ciclo. Com 800 milhões de ciclos por segundo, pode-se alcançar o desempenho de 6400 MIPS. Entretanto, é muito difícil para o programador ou para o compilador paralelizar totalmente um código e utilizar todas as unidades funcionais em um único ciclo, devido às dependências entre dados. IV. 800 MHz Up to 5600 Million (MIPS) L1: 256 Kb L2: 640 Kb 64 General purpose 2 multipliers 6 ULA 8-14 instructions: 256 bytes 4-8 operands: 256 bytes Fixed-point arithmetic RESULTADOS OBTIDOS Para os experimentos realizados neste trabalho, foi utilizado GSTreamer [24] na decodificação de vídeo H.264 para arquitetura ARM, e para DSP. O vídeo utilizado é denominado big_buck_bunny.mov, disponibilizado para download em [29], possui resolução de 854x480, com framerate de 24 fps. O vídeo foi codificado com o número total de 2000 frames (I e P, apenas), através da biblioteca libx264 [26] em conjunto com o software Ffmpeg [27] para o processo de codificação deste vídeo. A execução desse processo de codificação, com a utilização do Ffmpeg, foi realizada a partir da seguinte linha de comando: ffmpeg -i video_h264.mov -vcodec libx264 -vpre baseline -vframes 2000 video_h264_baseline.mov Com esta linha de comando o software ffmpeg utiliza da biblioteca libx264 para codificar a stream de entrada, e com o parâmetro -vpre baseline, o vídeo terá características do perfil baseline, cuja configuração é descrita a seguir: bf = 0 : significa que o vídeo não possuirá nenhum quadro do tipo B. Isso diminui a complexidade da codificação/decodificação. wpredp = 0 : zerando esse fator de predição, diminui o nível de compressão sobre os quadros do tipo P. -dct8x8 : desabilita/habilita a transformação DCT (Discrete Cosine Transform) em blocos de tamanho 8x8. Vale ressaltar que o vídeo foi decodificado para que este ficasse compatível com o perfil Baseline do H.264, pois os decodificadores utilizados suportam apenas este perfil, não possibilitando a decodificação em perfis de maior qualidade. Isto pode ser justificado pelo fato de que o próprio perfil foi implementado já pensando em ser voltado para dispositivos com recursos reduzidos, tanto em desempenho quanto em potência consumida. No caso da decodificação no DSP, foi necessária também a utilização do DSP-Bridge [23], que permite o controle e a comunicação com o processador DSP. Para iniciar qualquer processamento no DSP é necessário o uso de um driver desse tipo. Além disso, foi utilizado o sistema operacional Ubuntu O pipeline para a decodificação, utilizando o Gstreamer, que é composto de elementos e links, foi executado da seguinte forma [30]: gst-launch-0.10 filesrc location=big_buck_bunny _480p_h264_baseline.mov! qtdemux name=d \ d.! queue! ffdec_h264! ffmpegcolorspace! ximagesink \ d. Os componentes do pipeline de execução utilizado são descritos a seguir: gst-lauch-0.10: inicializa a execução do gstreamer; filesrc location: localização do vídeo a ser decodificado; qtdemux: realiza a desmultiplexagem de um arquivo do formato.mov para streams comprimidas (ou não) de áudio e vídeo; queue: fila de dados, com limite padrão de 200 buffers, 10 MB de dados. UEM - 10 A 14 DE SETEMBRO

21 ffdec_h264: é o elemento responsável pela decodificação propriamente dita. É um plugin para o Gstreamer criado a partir do decodificador H.264 do FFmpeg. Ffmpegcolorspace: converte espaço de cores para apresentação na tela. Ximagesink: renderiza o vídeo na tela utilizando o servidor gráfico X. Esse pipeline foi utilizado na decodificação do vídeo realizada exclusivamente pelo processador ARM. Na decodificação com o uso do DSP, basta modificar o elemento ffdec_h264 para dspvdec, elemento responsável pela decodificação de vídeos H.264 com a utilização do DSP. A. Utilização de CPU na decodificação Neste experimento, a análise da utilização de CPU foi realizada a partir da decodificação do vídeo H.264 no processador ARM apenas, e também a decodificação do vídeo com o auxílio do processador DSP. A avaliação foi feita a partir do percentual de utilização do processador ARM, de modo que foi possível comparar a decodificação utilizando apenas o processador ARM, com a decodificação com o DSP. Ao todo, foram realizados 6 conjuntos de testes, utilizando o aplicativo vmstat, onde o percentual de utilização de CPU é dividido em: Percentual de tempo gasto na execução de códigos que não fazem parte do kernel, chamado de user time, ou apenas us; Percentual de tempo gasto na execução de componentes do kernel, chamado de system time, ou sy; Percentual de tempo de ociosidade da CPU. Pode incluir tempo de espera em operações de E/S, se houver, chamado de idle time, ou apenas id. Com relação à decodificação no ARM, pode-se perceber que a utilização da CPU foi de 100% nesse processo, ou seja, em média, não houve tempo ocioso do processador. Mesmo trabalhando na frequência máxima de 800 MHz, houve perda de frames na decodificação, que é justificado pelo atraso na renderização da imagem em tela, e também pela disputa da CPU por outros processos, como o servidor gráfico X. Na decodificação utilizando o processador DSP, pode-se visualizar na Figura 2 que a carga de processamento no ARM diminuiu, para uma média de 83% (us + sy). Estes dados revelam uma vantagem em se utilizar de processadores DSP, deixando o processador ARM livre para a execução de outras tarefas. Essa taxa de utilização se manteve constante mesmo com a repetição dos experimentos. Nos testes, executando-se seis vezes a decodificação do mesmo vídeo, a utilização da CPU teve um desvio padrão de aproximadamente 1%. Figura 2: Gráfico da utilização do processador ARM, na decodificação H.264 efetuada pelo DSP. B. Estimativa do Consumo de Potência Na estimativa do consumo de potência durante a decodificação, foi utilizada a ferramenta i2c-tools, para fazer a leitura de dados, via software, da voltagem em um subsistema de Monitoramento ADC (Analog-to-Digital Converter) da plataforma. Esse subsistema faz parte do dispositivo TPS65950 OMAP [25], que permite o controle e gerenciamento de energia da plataforma. Primeiramente, foi necessário iniciar e configurar o subsistema MADC [25], com a utilização da ferramenta i2c. Na parte da configuração, especificou-se a partir de quais componentes ADC que seriam feitas as leituras, que correspondem ao ADCIN3 e ADCIN5, de acordo com o esquemático do circuito da plataforma, na Figura 3. Figura 3: Esquemático do circuito de medição de consumo de potência da placa BeagleBoard-xM [25]. O ADCIN5 corresponde à tensão de entrada no DM3730 e o ADCIN3 a tensão de saída. Os valores dos ADC s lidos em conjunto com o resistor R13 (ver Figura 3), de 0,1 Ohms, são usados para calcular a perda de tensão sobre R13. Foi necessário também ajustar os valores lidos dos ADC s, pois a resolução do número lido é de 10 bits. Assim, como a resistência R13 é de 0.1 Ohms, para cada 100 ma consumido, uma redução de 0,01 V entre o ADCIN3 e ADCIN5 é detectada. A alimentação do circuito é de 4.2V dado pelo pino UEM - 10 A 14 DE SETEMBRO

22 4 do CI TL1963A, no entanto com o uso dos resistores R48 e R52 de 12K e 10K Ohms respectivamente, a tensão efetiva da alimentação é de 46% do valor de entrada. Isso equivale a uma tensão de aproximadamente 2V que é efetivamente a tensão utilizada pelo DM3730. A potência média consumida na decodificação utilizando somente o ARM, com sucessivas leituras a cada 0,5 segundo, foi de ~2,48W, enquanto que no DSP foi de ~2,65W. Isso mostra que a diferença de consumo de potência foi relativamente pequena, em comparação com o ganho de desempenho na utilização do DSP, liberando o processador ARM para realização de outras tarefas. V. CONCLUSÕES E TRABALHOS FUTUROS Neste trabalho, foram apresentados os principais aspectos que devem ser considerados no desenvolvimento de sistemas embarcados, bem como algumas características da plataforma MPSoC OMAP muito utilizada no âmbito dos sistemas embarcados. Um exemplo de aplicação na qual é necessário realizar um balanço entre desempenho e consumo de potência é o padrão H.264, principalmente quando este for voltado para sistemas embarcados alimentados por bateria. A avaliação de desempenho da decodificação de vídeos H.264 na plataforma DM3730 revelou a vantagem da utilização de processadores DSP, deixando o processador ARM liberado para a execução de outras tarefas, durante esse processo. No caso do consumo de potência, houve aumento no consumo de potência na decodificação com o uso do DSP, em comparação com o uso exclusivo do ARM. Entretanto, esse aumento (6,41%, sobre a média) é relativamente pequeno, comparado aos ganhos de desempenho, pois com o uso apenas do ARM não foi possível decodificar sem ocorrer perdas de frames. Como trabalhos futuros, será avaliada a execução do software ArduPlane [32] na Beagleboard-xM, com o objetivo de verificar a viabilidade de se utilizar esta arquitetura para controle de voo de um VANT (Veículo Aéreo Não Tripulado). Para isso, será utilizada a compilação Software-In-The-Loop do ArduPlane, que permite a simulação dos componentes reais do VANT em software. REFERÊNCIAS [1] P. MARWEDEL, Embedded System Design. Netherland: Springer, [2] T. WIEGAND, G. J. SULLIVAN, G. BJONTEGAARD and A. LUTHRA, Overview of the H.264/AVC Video Coding Standard, IEEE Transactions on Circuits and Systems for Video Technology, vol. A partir disso, foi possível estimar a dissipação de potência 13, No. 7, July por parte do MPSoC apenas, desconsiderando recursos como, [3] Sistema Brasileiro de TV Digital, Recomendações para o Modelo de Referência (SW) Codificador e Decodificador de Vídeo H.264/AVC, por exemplo, o HUB USB integrado na placa, com teclado e Brazil, mouse conectados, na decodificação do vídeo no ARM e no [4] M. S. OYAMADA, A. A. GIRON and J. A. MARTINI, Introduction to DSP. A Fórmula 1 traz o valor da potência (P) consumida na embedded systems and platform-based design, II Critical Embedded placa, através do cálculo da corrente sobre R13, multiplicado Systems School (CES-School). May 21-25, pela voltagem do circuito, correspondente ao valor ADCIN5: [5] D. LANGEN, J. NIEMANN, M. PORRMANN, H. KALTE and U. RUCKERT, Implementation of a RISC Processor Core for SoC Designs FPGA Prototype vs. ASIC Implementation. Heinz Nixdorf P = ADCIN5 * (ADCIN5 ADCIN3) / R13 (1) Institute, University α + β = of χ. Paderborn. (1) Paderborn, (1) Germany. Disponível em: recordoid= &fileoid= Acessado em Junho, [6] L. CARRO and F. WAGNER, Sistemas Computacionais Embarcados. JAI'2003, Cap 2. SBC. [7] OMAP 3530/25 Applications Processor White paper, Texas Instruments Inc., Dallas, TX, [8] Especificação da plataforma OMAP 3530 Beagleboard, Beagleboard.org, disponível em: acessado em Maio [9] E. T. MANOEL, Codificação de Vídeo H Estudo de Codificação Mista de Macroblocos. Universidade Federal de Santa Catarina - UFSC, [10] C. MEENDERINCK, A. AZEVEDO, M. ALVAREZ, B. JUURLINK and A. RAMIREZ, Parallel Scalability of H.264, Delft University of Technology, [11] ARM Cortex-A8 Processor, ARM Holdings Company. Disponível em: Acessado em Março [12] D. MARPE, T. WIEGAND and S. GORDON, H.264/MPEG4-AVC Fidelity Range Extensions: Tools, Profiles, Performance, and Application Areas. IEEE International Conference on In Image Processing, ICIP IEEE International Conference on, Vol. 1 (2005), pp. I [13] W. WOLF, A. A. JERRAYA, G. MARTIN, "Multiprocessor System-on- Chip (MPSoC) Technology". Computer-Aided Design of Integrated Circuits and Systems, IEEE Transactions on, vol.27, no.10, pp , Oct [14] DIGI-KEY Corporation. Kit Dev BeagleBoard Rev C Disponível em: ND/ &WT.z_slp_buy=TI_BeagleBoard. Acessado em Março, [15] Architecture Reference Manual ARM v7-a and ARM v7-r edition. ARM Holdings Company. Disponível em: faculty/yin/teaching/cis700-sp11/arm_architecture_reference_manual_ errata_markup_8_0.pdf. Acessado em Março, [16] OMAP 35x Applications Processor Technical Reference Manual. Texas Instruments Inc., Disponível em: spruf98v/spruf98v.pdf. Acessado em Março, [17] TMS320C64x/C64x+ DSP CPU and Instruction Set Reference Guide. Texas Instruments Inc., Disponível em: /spru732j/spru732j.pdf. Acessado em Março, [18] ARM Holdings Company Profile. Disponível em: about/company-profile/index.php. Acesso em Maio, [19] E. J. TAN and W. B. HEINZELMAN, Dsp architectures: past, present and futures. SIGARCH Comput. Archit. News, ACM, New York, NY, USA, v. 31, p. 6 19, June ISSN Disponível em: Acessado em Maio, [20] J. EYRE and J BIER, The evolution of dsp processors. Signal Processing Magazine, IEEE, v. 17, n. 2, p , mar ISSN UEM - 10 A 14 DE SETEMBRO

23 [21] Y. MOSHE and N. PELEG, Implementations of h.264/avc baseline decoder on different digital signal processors. In: ELMAR, th International Symposium. [S.l.: s.n.], p [22] Fixed-Point Digital Signal Processor Texas Instruments, Inc. Dallas, TX, [23] DSP/BIOS Bridge Integration Document. Texas Instruments, Inc. Dallas, TX, [24] Gstreamer Open Source Multimedia Framework. Disponível em: Acessado em Maio, [25] BeagleBoard-xM Rev C System Reference Manual. BeagleBoard.org, Richardson, TX, [26] X264 Free software library. Disponível em: developers/x264.tml. Acessado em Maio, [27] FFmpeg video and audio converter. Disponível em: download.html. Acessado em Maio, [28] DM3730, DM3725 Digital Media Processors. Texas Instruments Inc. Dallas, TX, August [29] Vídeo Big Buck Bunny. Disponível em: index.php/download/. Acessado em Maio, [30] Gst-launch manual page. Disponível em: Acesso em Junho, [31] Mobile: Increasing value per handset. ARM Holdings Company, Disponível em: Acessado em Junho, [32] ArduPlane-SITL Introduction. Disponível em: google.com/p/ardupilot-mega/wiki/sitl. Acessado em Junho, UEM - 10 A 14 DE SETEMBRO

24 Filtragem de componentes conexos com o uso da estrutura de dados Max-tree Danilo E. Gondolfo UEM Departamento de Informática daniloegea@yahoo.com.br Franklin C. Flores UEM Departamento de Informática fcflores@din.uem.br Ronaldo A. de L. Gonçalves UEM Departamento de Informática ronaldo@din.uem.br Resumo As aplicações em processamento de imagens estão normalmente ligadas a algum processo de filtragem nas imagens. O estudo de técnicas de filtragem é tema atual de pesquisa e desenvolvimento. Nesse contexto, o presente trabalho tem como objetivo apresentar e avaliar a aplicação da estrutura de dados em árvore, conhecida como Max-tree, na filtragem em imagens de componentes conexos por atributo, comparando seu desempenho com o método convencional em termos de tempo de geração da árvore e de realização da operação de filtragem. A análise dos resultados aqui apresentados mostra que a utilização da Max-tree reduz consideravelmente o tempo de processamento quando um número suficiente de operações precisa ser executado sobre a imagem. Palavras-chave; processamento de imagens, Max-tree, filtragem por atributos I. INTRODUÇÃO Este artigo tem como objetivo comparar o desempenho do processo de filtragem de imagens digitais através da estrutura de dados Max-tree e o processo de filtragem convencional. O processamento de imagens digitais tem sido utilizado em muitas áreas da ciência, como por exemplo no tratamento de imagens de satélite, no auxílio de diagnósticos médicos, na contagem de células sanguíneas e controle de qualidade na automação industrial [1]. As aplicações nessas áreas estão normalmente ligadas a algum processo de filtragem nas imagens, cujos principais objetivos são realçar regiões e remover imperfeições. Esses métodos em geral são aplicados sobre imagens em tons de cinza, devido a serem mais simples do que imagens coloridas. Imagens em níveis de cinza podem ser visualizadas como relevos compostos por picos e vales. Nestes relevos, os picos seriam o pixels de maior intensidade de cinza e os vales os de menor intensidade. Essas imagens possuem regiões denominadas componentes conexos. Um componente conexo é uma região da imagem que contém um conjunto de pixels de mesma intensidade de cor, também chamados de zonas flat. A filtragem de componentes conexos é utilizada para remover ou diminuir picos e vales, aumentando a quantidade de componentes conexos, simplificando assim a imagem. O processo de filtragem, em sua forma original, pode consumir um considerável tempo de processamento de máquina, pois depende de repetidas decomposições da imagem em níveis de cinza e sempre que uma nova filtragem se faz necessária o processo de decomposição é executado novamente. Isso se deve ao fato de não haver armazenamento das informações já extraídas da imagem durante as filtragens. A estrutura de dados do tipo árvore pode ser aplicada no processo de filtragem na tentativa de reduzir esse tempo. Essa estrutura é conhecida como Max-tree. A Max-tree é construída através da decomposição da imagem em regiões, onde cada nó armazenará uma região e cada nó subsequente armazenará as regiões contidas na anterior. O processo de filtragem na árvore consiste em podar determinados galhos com base em um atributo. O processo de poda simplificará a imagem, diminuindo seus picos ou aterrando seus vales. O presente trabalho descreve a Max-tree e sua utilização no processamento de imagens digitais, como por exemplo, na simplificação de imagens, remoção de ruídos e segmentação. Este artigo está organizado conforme segue. A Sessão II apresenta a Max-tree. Na Sessão III são resumidos alguns trabalhos relacionados ao presente tema de investigação. A Sessão IV apresenta as principais considerações com relação a proposta do presente trabalho. A Sessão V mostra os resultados de experimentos práticos e compara o processo de filtragem baseado na Max-tree com o processo tradicional. Na Sessão VI aparecem as conclusões e um esboço dos trabalhos futuros. A última sessão mostra as referências bibliográficas. II. MAXTREE NO PROCESSAMENTO DE IMAGENS A filtragem de componentes conexos por atributo é custosa em termos de processamento computacional, pois a imagem deve ser decomposta de níveis de cinza (normalmente 256 níveis) através de um processo conhecido como thresholding. Este processo consiste em transformar a imagem de tons de cinza em binária, onde todos os pixels acima de um limiar são convertidos para branco e todos abaixo para preto. UEM - 10 A 14 DE SETEMBRO

25 O processo de decomposição deve ser executado sempre que uma filtragem com um atributo diferente for necessário. A decomposição e armazenamento da imagem na Max-tree faz com que o processo de thresholding seja necessário uma única vez. Uma vez criada a árvore, filtrar a imagem consiste na travessia e poda de determinados galhos. Note que a poda não altera a árvore necessariamente, mas sim evita que tons de cinza contidos abaixo de um determinado nó sejam armazenados na imagem resultante.. Cada nó da árvore possui uma lista contendo as coordenadas dos pixels daquela região, mas apenas os pixels que possuem o mesmo nível de cinza relativo ao nó. O restante fica armazenado nos nós filhos. Devido ao fato de o número de filhos de um nó ser indeterminado, cada nó possui uma lista que armazena todos os seus descendentes. Como podemos ver no Algoritmo 1, a construção da Max-tree é realizada através de um procedimento recursivo que encontra e insere na árvore todas as regiões conexas da imagem. Uma região é determinada a partir da verificação de todos os pixels com uma relação de vizinhança com o primeiro pixel encontrado. Após encontrada a primeira região do primeiro resultado da decomposição em níveis de cinza, o procedimento é chamado novamente para esta região, utilizando o segundo resultado da decomposição, e será chamado novamente para a primeira região encontrada na segunda chamada e assim sucessivamente. Este processo constrói a árvore em profundidade (pré-ordem) ordem), pois desce até o fim da estrutura ura para cada filho encontrado. Podemos observar o processo de construção da árvore no Algoritmo 1. A variável T armazena o resultado da operação de threshold sobre a imagem com o limiar níveldecinza. Os dois laços para são utilizados para percorrer a imagem T e encontrar todas as áreas brancas, que representam as regiões encontradas. Após a identificação da região, a mesma é inserida na lista de filhos do nó criado na chamada recursiva anterior (nó pai) e o procedimento Maxtree é chamado para este elemento inserido. A filtragem consiste em percorrer a árvore, o que também é feito em pré-ordem, até que se encontre um nó que satisfaça o atributo, por exemplo, ter a área menor que um determinado valor. Ao se encontrar esse nó a descida é interrompida e todos os pixels dos nós abaixo desse ponto são recuperados e gravados na imagem resultado com o tom de cinza do nó anterior ao que interrompeu a busca. Um detalhe importante que influencia diretamente na determinação das regiões é o critério de vizinhança. Geralmente são utilizados os critérios 4 ou 8-vizinhança, o que significa que durante a verificação dos vizinhos de um pixel,, somente são verificados os 4 (cima, baixo, esquerda e direita) ou 8 vizinhos (os mesmos citados mais os vizinhos das diagonais) respectivamente. Na implementação do presente trabalho foi utilizado o critério 8-vizinhança. Reconstituir uma determinada erminada região consiste em descer por todos os nós abaixo do nó que representa a região e gravar, pixel a pixel,, na imagem resultante, todo o conteúdo das listas de pixel.. A tonalidade de cinza de cada pixel será a tonalidade do nó onde o processo de reconstituição se encontra no momento. Algoritmo 1 Construção da Max-tree O nome Max-tree dá-se ao fato da árvore ser orientada para os máximos da imagem, ou seja, na medida em que se aproxima das folhas os valores de cinza se aproximam dos valores máximos s da imagem [2]. A Figura 1 representa a organização final da árvore para a imagem que se encontra no nó raiz. Na Figura 2 pode-se observar a nova imagem após uma filtragem por atributo de área (número de pixels em uma região). Aqui o nó foi removido da árvore e o tom de cinza de seu pai foi atribuído à região removida. Figura 1 Max-tree UEM - 10 A 14 DE SETEMBRO

26 Figura 2 Imagem após filtragem por atributo Além da aplicação na simplificação da imagem, observe na Figura 3, que a Max-tree pode ser utilizada para outros propósitos como, por exemplo, na remoção de ruídos e segmentação. A aplicação na remoção de ruídos dá-se através da poda dos nós mais próximos das folhas, pois os pixels de ruído tendem a ficar isolados nas folhas da árvore. Pode-se ver o resultado da filtragem na Figura 4. A segmentação pode ser feita determinando-squais nós da árvore encontra-se a região de interesse. A em qual ou Figura 5 exemplifica uma região específica da imagem que foi encontrada e reconstruída. Figura 3 - Simplificação da imagem Figura 4 - Remoção de ruídos Figura 5 - Segmentação III. TRABALHOS RELACIONADOS Tendo em vista os benefícios oferecidos pela estrutura de dados Max-tree, diversos autores depositaram esforços em pesquisas sobre a utilização e melhoramento dessa estrutura. Alguns desses trabalhos são brevemente descritos a seguir. Em [3] Salembier propõe o uso da Max-tree na filtragem de componentes conexos e mostra como os operadores conexos anti-extensivos atuam implicitamente ao se representar a imagem de maneira estruturada com a árvore. São apresentados três passos básicos para a utilização da Max-tree, como se segue. O primeiro passo é a construção da árvore, que envolve a binarização (threshold) e a definição dos componentes conexos. O segundo passo é a tomada de decisão que define se um componente conexo permanece ou é retirado rado da árvore com base em uma critério. O terceiro passo consiste em recriar a imagem a partir da árvore filtrada. No artigo [4] Marcondes e outros apresentaram um algoritmo de segmentação distribuído baseado na Max-tree. Os autores utilizaram um cluster com 31 estações e a biblioteca MPI para distribuir o processamento entre as máquinas. O algoritmo foi executado em um número variado de máquinas. O ganho obtido com a execução em 3 máquinas foi de 83% e de até 99% com 11. Garrido [5] utilizou a Max-tree no processamento de sequências de imagens com um operador conexo orientado a movimento. Esse operador remove da imagem os componentes que não sofrerem um determinado movimento (com base em um critério de movimento) e preserva o restante. No trabalho desenvolvido vido em [6], Wilkinson propõe uma implementação paralela da Max-tree em ambiente de memória compartilhada. Um bom speed-up é alcançado com as alterações propostas nos testes em uma máquina MIPS com 16 processadores e em uma dual-core com processador Opteron. Os speed-ups alcançados no sistema MIPS variaram entre 7 e 14 e entre 3.6 e 5.7 no sistema Opteron, o que representa um excelente aumento no desempenho. Em [7] os autores propuseram o uso da Max-tree como alternativa a operação de abertura (area opening). Os ganhos obtidos sobre os métodos tradicionais foram de 25%. Em [8] é proposta uma modificação da Max-tree aplicada a filtragem de segunda geração por conectividade e atributos. Este tipo de filtro expande o conceito de relação de vizinhança entre pixels para relações de partições e grupos. Ouzounis [9] apresentou uma estratégia de paralelização da construção da Max-tree modificada para filtros de segunda-geração. geração. Experimentos em imagens 3D apresentaram um speed-up de 4.14 até 4.21 em uma máquina quadcore executando 4 threads da aplicação. O speed-up máximo de 5.12 e 5.99 foi alcançado utilizando-se 32 e 64 threads sobre os mesmos 4 núcleos. UEM - 10 A 14 DE SETEMBRO

27 Em [10] Huang propôs uma maneira eficiente de se armazenar as informações da Max-tree utilizando listas ligadas e tabelas hash para o acesso direto aos nós da árvore. Com isso eles mostraram que o uso de memória necessário para o armazenamento da árvore se torna o mínimo possível. IV. PROPOSIÇÃO Os processos de filtragem através de métodos convencionais, ou seja, que não usam a Max-tree, podem demandar um tempo de processamento consideravelmente alto. Isso se deve ao fato de eles normalmente dependerem de repetidas operações sobre a imagem sempre que se faz necessária a realização de uma filtragem com um novo critério. Na Max-tree, a partir do momento em que a árvore está construída, filtrá-la torna-se um processo muito rápido. No Algoritmo 2 podemos ver o processo de filtragem convencional. Este procedimento é semelhante ao algoritmo de construção da árvore, mas este não armazena os resultados encontrados em cada operação de threshold, sendo necessárias novas limiarizações sempre que uma filtragem com critério diferente for necessária. Aqui não é possível separar os tempos de construção e filtragem, já que esses dois passos se encontram unidos no algoritmo. coordenadas dos pixels do nó e dos nós abaixo dele são recuperados e gravados na imagem resultado com o valor de cinza do nó imediatamente acima. Caso contrário o procedimento continua descendo a árvore. Embora a operação de filtragem sobre a árvore seja muito eficiente, o processo de construção da mesma ainda pode demandar um tempo considerável. Assim a utilização da árvore só é justificada se um número suficiente de operações for realizada sobre a mesma, compensando assim o tempo gasto com a sua criação. No Gráfico 5 estão representados os tempos para se realizar um número variável de operações sobre uma imagem de dimensões 2048x2048. Pode-se ver que a partir de 2 operações o uso da árvore já é justificado. Algoritmo 3 Processo de filtragem por área Os tempos de criação e filtragem da árvore não dependem somente das dimensões da imagem, mas também na natureza dos pixels. Duas imagens de mesma resolução mas diferentes em complexidade (uma com pouco agrupamento de pixels de mesma intensidade e outra com mais agrupamento) podem levar tempos diferentes para serem decompostas na Max-tree. As árvores geradas podem também ter quantidades de nós diferentes. Algoritmo 2 Processo de filtragem convencional A filtragem dos componentes é realizada com base em um determinado critério, que pode ser área, volume, movimento ou algum outro critério que se faça necessário. No presente trabalho o critério de área é utilizado, o que significa que o processo que determina se um componente permanece ou não na imagem é a quantidade de pixel da região. No Algoritmo 3 podemos ver como é feita a filtragem com critério de área. No momento em que um nó com área inferior ao critério é encontrado, todas as V. EXPERIMENTAÇÕES As aplicações usadas nos experimentos foram desenvolvidas com o uso da biblioteca de processamento de imagens OpenCV versão 2.4 e em linguagens C e C++. O compilador GCC foi utilizado para a compilação dos aplicativos com otimizações no nível O3. O equipamento utilizado nos testes foi uma máquina com 2 processadores Intel Xeon E5620 de 2.4Ghz com 8GB de memória executando o CentOS Linux versão 5.3. Nos testes foram utilizadas imagens concatenadas baseadas na Figura 3. As dimensões utilizadas foram de 256x256, 512x512, 1024x1024 e 2048x2048. No Gráfico 1 podemos ver o tempo de filtragem das imagens com a Maxtree. Foi utilizado um critério de área de 1000 pixels. UEM - 10 A 14 DE SETEMBRO

28 Conforme já mencionado,, a construção da árvore é um processo dispendioso se a sua implementação não for otimizada. A implementação da construção utilizada nesse trabalho não é a mais otimizada se comparada às implementações encontradas na literatura, muito embora já nos tenha servido como meio de implementar o processo de filtragem. A otimização deste processo será foco de trabalhos futuros. No Gráfico 2 podemos ver a relação do tempo de construção da árvore com a dimensão de cada imagem. No Gráfico 3 podemos ver a relação entre a dimensão das imagens e o tempo gasto no processamento com a aplicação que não utiliza a Max-tree no processo de filtragem. Com base nesses dados podemos perceber que o tempo do processo de filtragem através da Max-tree é muito menor, o que a torna uma solução viável para esses tipos de problemas. 0,1 0,09 0,08 0,07 0,06 0,05 0,04 0,03 0,02 0,01 0 0, , , x x x1024 Gráfico 1 Tempo de filtragem na Max-tree No Gráfico 4 pode-se ver a relação entre a quantidade de nós na árvore e a dimensão das imagens. Vale lembrar que o número de nós está relacionado com a estratégia de relação de vizinhança. Se a relação 4-vizinhança fosse utilizada provavelmente um número maior de nós seriam encontrados , , , x x x1024 0, x , x2048 Gráfico 2 Tempo de construção da Max-tree 30 26, , , , x x x x2048 Gráfico 3 Tempo na filtragem convencional No Gráfico 6 observa-se que o tempo médio que um determinado número de operações leva para ser executado. À medida que o número de operações efetuadas sobre a imagem é aumentado, o tempo médio por operação na Maxtree se aproxima de zero, enquanto no processo convencional o tempo se mantém constante x x x x2048 Gráfico 4 Quantidade de regiões da imagem Maxtree Convencional Gráfico 5 Tempo para realizar uma determinada quantidade de filtragens UEM - 10 A 14 DE SETEMBRO

29 Maxtree Convencional Gráfico 6 - Tempo médio por número de operações VI. CONCLUSÕES E TRABALHOS FUTUROS Com este trabalho concluímos que a utilização da Maxtree na filtragem de componentes conexos apresenta uma grande vantagem sobre os métodos que antecedem a sua criação. A diferença no tempo de processamento aumenta conforme aumentamos as dimensões da imagem. Por outro lado, o processo de criação da árvore se torna mais dispendioso. Assim, a utilização da Max-tree, em sua forma original, para processos de filtragem de imagens digitais só é justificado se um número suficiente de operações sobre a estrutura for necessário. Embora o processo de filtragem sobre a árvore tenha se mostrado eficiente, o processo de construção implementado neste trabalho demanda um alto tempo de processamento. A paralelização da construção da Max-tree pode ser aplicada na tentativa de reduzir o tempo de criação da estrutura. A otimização e também a implementação paralela deste processo será foco de trabalhos futuros. [5] Garrido, L.; Salembier, P.; Oliveras, A. Anti-extensive Connected Operators with Application to Image Sequences. A: VII SimposiumNacional de Reconocimiento de Formas y Análisis de Imágenes. "Proceedings of the VII SNPRIA", 1997, p [6] Wilkinson, H. F. Michael, Hesselink, H. Wim, Meijster, Arnold, et al. Concurrent Computation of Attribute Filters on Shared Memory Parallel Machines. IEEE Trans. Pattern Anal. Mach. Intell. Vol 30, No. 10, [7] Huang, Xiaoqiang. Fisher, Mark. Zhu, Yanong, et al. An efficient strategy for implementing iterative area openings using the max tree. In: Proceedings of the 8th Australian and New Zealand Intelligent Information Systems Conference, 2003, Sydney, Australia. [8] Ouzounis, K. Georgios, Wilkinson, H. F. Michael. Mask-based second-generation connectivity and attribute filters, IEEE Trans. Pattern Anal. Mach. Intell. 29 (2007), [9] Ouzounis, K. Georgios, Wilkinson, H. F. Michael. A parallel implementation of the dual-input Max-Tree algorithm for attribute filtering, Proceedings of the 8th International Symposium on Mathematical Morphology, Rio de Janeiro, Brazil, 2007, MCT/INPE, v. 1, p [10] Huang, Xiaoqiang. Fisher, Mark. Smith, Dan. An Efficient Implementation of Max Tree with Linked List and Hash Table. In: Proc. VIIth Digital Image Computing: Techniques and Applications, 2003, Sydney, Australia. VII. REFERÊNCIAS [1] Filho, O. M. e Neto, H. V., Processamento Digital de Imagens, Brasport, Rio de Ja- neiro, [2] Garrido, O. Luis, Hierarchical region based processing of image and video sequences: application to filtering, segmentation and information retrieval. PhD thesis, Department of Signal Theory and Communications, Universitat Politecnica de Catalunya, Barcelona, Spain, 2002 [3] P. Salembier, A. Oliveras, and L. Garrido, Anti- Extensive Connected Operators for Image and Sequence Processing, IEEE Trans. Image Processing, vol. 7, pp , [4] Marcondes, H. S. Anderson, Pillon, A. Maurício, Silva, G. Alexandre. Algoritmo de Detecção de Formas de Interesse em imagens digitais para uma plataforma distribuída. Revista Hífen, Vol. 32, No.. 63, UEM - 10 A 14 DE SETEMBRO

30 Otimização em algoritmo de geração de estimativas iniciais para sistemas iterativos não lineares Robertino Mendes Santiago Jr Informática Empresarial Faculdade Intermunicipal do Noroeste do Paraná Loanda, Paraná, Brasil Vladmir Ferreira Cabral, Lucio Cardozo Filho Departamento de Engenharia Química Universidade Estadual de Maringá Maringá, Paraná, Brasil Anderson Faustino da Silva, Ronaldo A. de Lara Gonçalves Departamento de Informática Universidade Estadual de Maringá Maringá, Paraná, Brasil Resumo Solucionar sistemas iterativos de equações não lineares é um dos problemas conhecidos que demandam grande esforço computacional. Além disto, a convergência da solução desses sistemas depende das estimativas iniciais para suas variáveis. Nesse sentido, o algoritmo denominado SubDivNL, utilizado na área da Engenharia Química, foi proposto para gerar estas estimativas iniciais. Em sua versão original, o algoritmo constrói uma estrutura de dados em árvore, durante um processo iterativo de subdivisão que segue a abordagem de busca em largura, para armazenar todas as estimativas avaliadas. Como consequência, isto gera um aplicação que acessa intensamente a memória e não pode ser aplicada em sistemas com uma quantidade excessiva de variáveis ou que requerem diversas subdivisões. Para minimizar este problema, este artigo propõe uma otimização do algoritmo original no qual a construção da árvore passou a seguir a abordagem de busca em profundidade. Os experimentos realizados com as versões original e otimizada demonstram que, apesar dos tempos de execução de ambas serem semelhantes, a versão otimizada possibilita alcançar um número maior de subdivisões sem produzir estouro de memória. Palavras-chave: sistemas iterativos; algoritmo de subdivisão; otimização de código; percurso em árvore. I. INTRODUÇÃO Em diversas áreas científicas existem experimentos que são muito difíceis de serem realizados, devido ao fato de serem caros financeiramente e/ou até perigosos, requerendo equipamentos especiais e procedimentos rígidos para evitar acidentes. Com o uso de simulação computacional, é possível estimar resultados e comportamentos desses experimentos evitando desta forma danos e gastos desnecessários. Engenharia química é uma das áreas científicas que requer mecanismos para avaliar de forma segura e precisa as novas abordagens propostas pelos pesquisadores. Um exemplo de sistema desta área do conhecimento que necessita de uma devida atenção é a produção de ésteres de ácidos graxos (biodiesel). A simulação de biodiesel em colunas de destilação reativa, a qual utiliza um modelo matemático baseado em um sistema iterativo de equações não lineares [1], demanda grande quantidade de poder computacional. Neste contexto, o nível de exigência do poder de processamento aumenta em função do tamanho dos sistemas não lineares envolvidos. Sabe-se que a convergência da solução de sistemas iterativos de equações não lineares depende das estimativas iniciais para as suas variáveis, o que demanda um grande esforço computacional, seja em quantidade de recursos quanto em tempo de execução. Esse conjunto de estimativas iniciais pode ser gerado pelo algoritmo de subdivisão denominado SubDivNL [2]. Porém, a geração de estimativas iniciais pelo referido algoritmo é um processo que consome demasiada quantidade de armazenamento para sistemas que requerem muitas subdivisões, justificando assim que esforços sejam realizados para otimizá-lo e torná-lo mais eficiente. Nesse sentido, o objetivo de artigo é apresentar uma versão otimizada do algoritmo SubDivNL, cujo objetivo é reduzir o esforço computacional necessário pela versão original. Tal versão otimizada foi implementada e então comparada com a versão original. Os resultados demonstram que a versão otimizada possibilita aplicar um número maior de subdivisões nos problemas sem que ocorram erros de violação de memória. O presente artigo está organizado conforme segue. A Seção II relata trabalhos relacionados a este estudo. Na Seção III é descrito o funcionamento do algoritmo original. Na Seção IV são apresentadas as otimizações realizadas no algoritmo original e ilustrado o funcionamento do algoritmo otimizado. Os resultados são apresentados na Seção V. E por fim, a Seção VI apresenta as conclusões e os trabalhos futuros. II. TRABALHOS RELACIONADOS Li e Zeng apresentaram um algoritmo de rede neural [3] para resolver um conjunto de equações não lineares. O algoritmo utiliza cálculos baseados na regra do método do gradiente descendente com número variável de passos. O método do gradiente descendente baseia-se na propriedade do gradiente determinar a direção de máximo crescimento da função. Nos experimentos realizados, o algoritmo proposto resolveu rapidamente o sistema de equações não lineares testado e demonstrou possuir uma precisão maior que o método tradicional. Projeto apoiado pela Fundação Araucária. UEM - 10 A 14 DE SETEMBRO

31 Um algoritmo híbrido de otimização por enxame de partículas para resolver problemas de equações não lineares foi proposto por Ouyang e Luo [4]. O algoritmo combina as vantagens do método simplex de Nelder-Mead e o algoritmo de otimização por enxame de partículas. O algoritmo de otimização por exame de partículas é uma ferramenta de otimização com base na população de soluções aleatórias que é utilizada para inicializar o sistema. O algoritmo híbrido apresentou nos experimentos realizados uma rápida convergência, aumento da capacidade de busca global e maior precisão da pesquisa. No trabalho apresentado por Yanbin, Bin e Tianshun [5] foi proposto um novo método para a solução de sistemas de equações não lineares, O sistema de equações não lineares utilizado é a matriz fundamental utilizada na geometria epipolar. A geometria epipolar é a geometria relacionada a duas imagens de uma cena 3D capturada de duas câmeras estenopeicas em posições distintas. Uma matriz fundamental é uma matriz 3x3 que representa a restrição epipolar existente entre duas visões da mesma cena 3D. O método apresentado permitiu reduzir um sistema de equações não lineares de múltiplas variáveis em um sistema com uma única variável, o que torna mais fácil a resolução. Em experimentos comparativos com o método tradicional baseado no método de iteração Newton-Raphson, o método apresentado foi mais rápido. No estudo realizado por Yin, Qi e Xiao [6] foi proposto um método baseado em evolução diferencial utilizado para a solução de equações não lineares. Para resolver as equações, o método transforma o problema de detecção de raízes em problemas de otimização correspondente com uma técnica de função de deflexão. Em simulações de diferentes métodos para equações com coeficientes complexos e equações transcendentais o método proposto demonstrou ser robusto, eficiente e preciso. III. ALGORITMO ORIGINAL DE SUBDIVISÃO SUBDIVNL Em 2001, Michael W. Smiley e Changbum Chun apresentaram um algoritmo [9] que por meio de subdivisões sucessivas poderia localizar as raízes de sistemas de equações algébricas não lineares, a partir de determinados intervalos de variáveis (intervalo na reta real no qual o valor de uma variável pode ser encontrado). Por exemplo, o intervalo real [1,5] é um intervalo de variável para uma variável de valor 2. Com base nas ideias de Smiley, Corazza desenvolveu o algoritmo de subdivisão denominado SubDivNL [2]. O referido algoritmo processa um sistema de equações não lineares e refina estimativas por meio de subdivisões sucessivas. Uma estimativa, também conhecida como retângulo, é um conjunto de intervalos de variáveis contendo um intervalo para cada variável do sistema. Partindo de uma estimativa pré-definida, o algoritmo subdivide cada intervalo de variável em dois subintervalos de mesmo tamanho (congruentes), os quais são submetidos a um teste de aprovação para verificar se os mesmos continuam sendo intervalos de variáveis, ou seja, se ainda podem conter a solução para a respectiva variável. As combinações entre os subintervalos aprovados formam novos sub-retângulos. O subintervalo submetido ao teste de aprovação é mantido (armazenado na memória) para ser novamente subdividido somente se o teste retornar um resultado positivo (aprovado), caso contrário, é descartado (reprovado). Com a execução de um número finito de subdivisões, definido pelo usuário, os subintervalos mantidos serão mais justos e se aproximarão das raízes das respectivas variáveis. O processo de subdivisão poderá ser repetido tantas vezes for o número de iterações também definido pelo usuário. Entre cada iteração é feito um teste de cobertura e após a execução de todas as iterações é realizado um teste de convergência para saber quais subintervalos comporão o conjunto solução, ou seja, o conjunto de estimativas iniciais para o respectivo sistema de equações não lineares. A implementação do algoritmo SubDivNL [2], usada no presente trabalho, foi escrita em linguagem C, a partir da decodificação do código original escrito em Fortran, pelo fato desta linguagem ser mais usada pelo pessoal da computação e este fato facilitar manutenções futuras no código. Ela é capaz de encontrar estimativas iniciais para qualquer sistema de equações lineares e não lineares. Este algoritmo utiliza o método de Newton-Raphson para resolver um sistema fortemente não linear, como no caso da coluna de destilação reativa que, para convergência do método, depende de um grande número de estimativas iniciais. Este algoritmo pode ser observado na Figura 1. SubDivNL inicialmente faz a leitura de um arquivo de configurações e inicializa as variáveis associadas. A variável icov controla a quantidade de vezes que o teste de cobertura é aplicado Entrada: Arquivo de configuração contendo o intervalo inicial e a quantidade de subdivisões Saída: Estimativas que convergiram Inicializa M; para l 1 até icov faça para i 1 até maxsub faça Inicializa m; para j 1 até M * 2 d faça Obtém coordenadas; Obtém números aleatórios; Aplica f(x); Avalia retângulo; se retângulo aprovado então Retêm retângulo; Incrementa m; senão Descarta retângulo; fim fim M m; fim Avalia retângulos adjacentes; Redefine M; fim Aplica o método de Newton; Verifica soluções encontradas; Exibe soluções; Figura 1. Algoritmo de subdivisão original UEM - 10 A 14 DE SETEMBRO

32 No teste de cobertura (Figura 2), os retângulos que possuem as mesmas coordenadas (adjacentes) em pelo menos uma dimensão (Figura 2(a)) são usados para definir um novo retângulo após a aplicação do teste (Figura 2(b)). A variável maxsub controla a quantidade de subdivisões. A cada subdivisão, o contador de retângulos aprovados na subdivisão atual (m) é inicializado. Cada retângulo pode gerar até 2 d subretângulos, sendo d o número de variáveis (dimensão). Desta forma, na linha 7 é feito um laço de repetição com base no produto da quantidade de retângulos aprovados nas subdivisões até o momento pela quantidade de sub-retângulos que cada retângulo pode gerar. Entre as linhas 8 e 18 são obtidas as coordenadas de cada novo sub-retângulo e é aplicado a função do sistema de equações não lineares no ponto central de cada sub-retângulo. Cada sub-retângulo então é avaliado pelo teste de aprovação com o auxílio dos números aleatórios, que realizam ajustes nos valores do ponto central do sub-retângulo para prever a próxima iteração. O sub-retângulo aprovado no teste é mantido e o contador de retângulos aprovados é incrementado na atual subdivisão, caso contrário, o sub-retângulo é descartado. O exemplo ilustrado na Figura 3 demonstra como ocorre o processo de subdivisão de um retângulo. Para este exemplo, consideramos um problema com duas dimensões em que são aplicadas duas subdivisões. No nível 0 são obtidas as coordenadas dos sub-retângulos a partir do retângulo inicial, sendo cada sub-retângulo aplicado à função do sistema de equações e submetido ao teste de aprovação. (a) Retângulos mantidos após i subdivisões Figura 2. Teste de cobertura [2] (b) Retângulos apresentados em (a) após o teste de cobertura ser aplicado Neste exemplo, todos os primeiros sub-retângulos são aprovados e mantidos e então, o algoritmo continua o processamento na próxima subdivisão. No nível 1 o processo de subdivisão ocorre novamente, entretanto, somente os subretângulos etiquetados com os valores 3 e 4 são mantidos. No nível 2 os sub-retângulos descartados no nível anterior, representado pelas áreas escuras maiores, não são utilizados na continuidade do algoritmo. As áreas escuras menores são os sub-retângulos descartados na subdivisão do nível 2. Após avaliar todas as possibilidades (linha 19) o contador da quantidade total de retângulos aprovados é atualizado. Após o máximo de subdivisões ser atingido, é aplicado um teste de cobertura, caso tenha sido definido, para verificar a existência de retângulos adjacentes. Após ter sido estimado todos os subretângulos possíveis do retângulo inicial, é aplicado o método de Newton nos retângulos mantidos para verificar a existência de raízes (convergência). Qualquer convergência de algum retângulo é exibida na tela. Figura 3. Representação gráfica do processo de subdivisão do retângulo inicial de duas dimensões após duas subdivisões Uma estrutura em árvore, denominada aqui de árvore de estimativas, é construída para manter os sub-retângulos gerados, sendo que o nó raiz da árvore representa o retângulo inicial e cada nó filho da árvore representa um sub-retângulo aprovado. Para encontrar os retângulos que serão mantidos, a árvore de estimativas é construída iterativamente segundo uma abordagem de busca em largura (Breadth First 1 ). IV. ALGORITMO OTIMIZADO DE SUBDIVISÃO SUBDIVNL Conforme visto na seção anterior, o algoritmo original utiliza uma abordagem de busca em largura para construir a árvore de estimativas. Utilizando esta abordagem, todos os retângulos aprovados são armazenados em cada nível da árvore, para serem subdivididos no próximo nível descido, pois no final, após a execução de todas as subdivisões pré-definidas e a consequente finalização da árvore, quando a última subdivisão da última iteração for alcançada, todos os retângulos terminais serão submetidos aos critérios de seleção e convergência. Com isso, a utilização de memória aumenta com o crescimento da árvore e o avanço das subdivisões, intensificando a ocorrência de swap. Para sistemas maiores do que aqueles aqui utilizados, em vários experimentos realizados, quase sempre a execução foi abortada devido ao estouro da capacidade de armazenamento em disco. O tempo de processamento também cresce demasiadamente com essa abordagem original, mas a partir de uma quantidade de dimensões não se pode nem sequer mensurar o tempo, devido à execução ser abortada. 1 Breadth First: visita todos os nós adjacentes (irmãos) de cada nó visitado antes de visitar os seus sucessores. UEM - 10 A 14 DE SETEMBRO

33 Assim, para otimizar o uso da memória, a abordagem da construção da árvore de estimativas foi alterada para busca em profundidade (Depth First 2 ) para não precisar armazenar todos os retângulos observados. Com essa nova abordagem, o algoritmo atinge mais rapidamente o final da árvore, por várias vezes subsequentes, e somente armazena os retângulos observados em cada caminho de descida e sempre que um retângulo folha é encontrado, o mesmo já é submetido ao critério de seleção e convergência e, se for o caso, já é descartado. Durante o retorno de um caminho descido, em busca de um próximo caminho a descer, os retângulos intermediários que não serão mais descidos (subdivididos) também já são descartados. Dessa forma, somente os retângulos aprovados no teste de convergência final permanecem armazenados até o final. A maior vantagem é que a cada descida/subida na árvore, os retângulos intermediários já são descartados antes de analisar os retângulos da próxima descida/subida e assim sucessivamente, economizando armazenamento. Em função da troca da abordagem de construção da árvore de estimativas, uma preocupação que surgiu foi quanto ao tratamento da semente de geração aleatória usada pelo algoritmo. Nesse contexto, em ambos os algoritmos (original e otimizado), todos os retângulos são etiquetados com um valor inteiro, que os identifica individualmente dentro da árvore de estimativas, conforme pode ser observado na Figura 4. Esses valores são utilizados como sementes na geração de números aleatórios a cada sub-retângulo que surge e visam garantir o mesmo padrão de geração aleatória para as duas abordagens algorítmicas. O algoritmo otimizado pode ser observado na Figura 5. parâmetro para a chamada recursiva da função SubdivideRecursivo( ), caso contrário, será descartado. Quando a avaliação de retângulos adjacentes é definida no arquivo de configuração, ao atingir o último nível de subdivisão, os retângulos aprovados são alocados em uma estrutura de dados para posteriormente serem avaliados. O processo recursivo encerra somente quando a variável subdivisaoatual atingir o valor 1 (um). Neste momento, o sub-retângulo é submetido ao método de Newton para verificar a existência de raiz e, caso haja convergência, é armazenado Entrada: Arquivo de configuração contendo o intervalo inicial e a quantidade de subdivisões Saída: Estimativas que convergiram Lê arquivo de configuração e aloca estruturas; SubdivideRecursivo(maximoSubdivisao, maximoiteracoes, retângulo inicial, etiqueta, icov); se icov < maximoiteracoes então Avalia retângulos adjacentes; fim enquanto icov!= 0 E icov <= maximoiteracoes faça para i 0 até quantidade retângulos retidos faça SubdivideRecursivo(maximoSubdivisao, maximoiteracoes, retângulo inicial, etiqueta, icov); se icov >= maximoiteracoes então encerra para; fim Avalia retângulos adjacentes; fim Aplica o método de Newton; Verifica soluções encontradas; Exibe soluções; Figura 4. Árvore de estimativas com elementos enumerados A abordagem de busca em profundidade foi usada de forma recursiva durante a geração dos sub-retângulos. A função recursiva desenvolvida, denominada SubdivideRecursivo( ), pode ser observada na Figura 6. Na linha 1 é iniciado o laço de repetição que controla a navegabilidade dentro da árvore. Cada sub-retângulo recebe um identificador, calculado com base no valor do retângulo pai. Esse identificador é utilizado como semente para a geração de números aleatórios. O ponto central da estimativa armazenada em cada novo sub-retângulo é submetido à função do sistema de equações não lineares. Esse sub-retângulo então é avaliado e se for aprovado pelo critério de seleção, será utilizado como 2 Depth First: visita os sucessores de cada nó antes de visitar os seus nós irmãos Figura 5. Algoritmo da subdivisão otimizado para l 0 até 2 d faça Calcula a etiqueta do retângulo; Obtém coordenadas; Obtém números aleatórios; Aplica f(x); Avalia retângulo; se retângulo aprovado então se subdivisaoatual == 1 então se icov == maximoiteracoes então Aplica o método de Newton; Verifica solução encontrada; senão Retêm retângulo fim senão SubdivideRecursivo(subDivisaoAtual -1, maximoiteracoes, retângulo, Etiqueta, icov); fim fim fim Figura 6. Função SubdivideRecursivo( ) UEM - 10 A 14 DE SETEMBRO

34 V. RESULTADOS E DISCUSSÃO Para avaliar o algoritmo proposto vários experimentos foram realizados em um computador Intel Xeon E Ghz, 8 Gb de memória RAM. A versão utilizada do compilador C GCC foi O objetivo destes experimentos foi comparar o algoritmo proposto com a versão original. Nos experimentos realizados, os tempos coletados foram contabilizados do início ao fim da execução de cada implementação. Dados de casos reais conhecidos pertencentes a três sistemas de equações não-lineares, com 3, 5 e 7 dimensões, disponíveis na biblioteca de problemas teste da Polymath Software [8], juntamente com suas respectivas soluções, foram utilizados como entrada nas execuções. Para o sistema com 3 dimensões, foram aplicados 7 níveis de subdivisões, para 5 dimensões foram aplicadas 5 níveis de subdivisões, e para 7 dimensões foram aplicadas 3 níveis de subdivisões. Para a obtenção dos tempos de execução, foram realizadas 10 execuções para cada versão e a partir destes dados foram calculados a média aritmética, bem como o desvio padrão. Os gráficos das médias dos tempos de execução obtidos podem ser observados nas Figuras 7, 8 e 9 para 3, 5 e 7 dimensões, respectivamente. semelhante. O desvio padrão indica que os tempos não variaram consideravelmente dentro de cada conjunto de execuções. Para o problema com 3 dimensões, o tempo total de execução foi igual para os dois algoritmos executados. Utilizando o problema com 5 dimensões, o tempo total de execução da implementação do algoritmo original foi ligeiramente inferior a otimizada. Entretanto utilizando o problema com 7 dimensões, esta situação se inverte. Tempo (em minutos) ,8 4,6 Original 497,3 Figura 9. Tempo de execução do problema com 7 dimensões (em minutos) 2,9 Otimizado Tempo Desvio Padrão Tempo (em segundos) Figura 7. Tempo de execução do problema com 3 dimensões (em segundos) Tempo (em segundos) ,3 211,1 0,42 Original 1,14 Original 7,3 222,2 Figura 8. Tempo de execução do problema com 5 dimensões (em segundos) De forma geral, é possível observar nos gráficos que o tempo total de execução das duas implementações foi 0,42 Otimizado 1,28 Otimizado Tempo Desvio Padrão Tempo Desvio Padrão Devemos considerar que os valores experimentados para a dimensão e o número de subdivisões são pequenos e insuficientes para causar diferenças maiores no tempo de execução, mesmo porque a implementação do algoritmo original não permite explorar situações mais agressivas pelo fato de ser abortada pelo consumo exagerado de memória. Por exemplo, aplicando 6 subdivisões no problema de 5 dimensões o algoritmo original finalizou sua execução com erros de memória (segmentation fault). O mesmo ocorreu com o problema de 7 dimensões sendo aplicadas 4 subdivisões. Utilizando o algoritmo otimizado, o consumo de memória se manteve estável, executando os problemas de 5 e 7 dimensões com 6 e 4 subdivisões respectivamente. Nas Tabelas 1, 2 e 3 são apresentados os valores das soluções conhecidas disponíveis na literatura e os valores obtidos por meio da execução das versões original e otimizada para os problemas com 3, 5 e 7 dimensões, respectivamente, afim de validar a qualidade numérica dos resultados obtidos. Esses resultados são as estimativas iniciais utilizadas como entrada no sistema utilizado na simulação de biodiesel em colunas de destilação reativa. Analisando as tabelas é possível ver que os algoritmos produziram resultados muito próximos aos conhecidos na literatura. Devido ao fato dos algoritmos original e otimizado utilizarem a mesma semente para geração de números aleatórios, ambos proveram exatamente os mesmos resultados. As Figuras 10, 11 e 12 ilustram o consumo de memória nos algoritmos original e otimizado para sistemas com 3, 5 e 7 dimensões, respectivamente. A métrica utilizada foi o parâmetro do sistema operacional linux VmSize, a qual indica a quantidade total de memória utilizada por um processo. É possível observar que o consumo de memória do algoritmo UEM - 10 A 14 DE SETEMBRO

35 Tabela I. Solução Solução 1 Solução 2 Solução 3 Solução 4 Solução 5 Tabela II. VALORES DAS SOLUÇÕES CONHECIDAS E OBTIDAS PARA O PROBLEMA COM 3 DIMENSÕES Solução conhecida E E Solução Algoritmo Original Solução Algoritmo Otimizado VALORES DAS SOLUÇÕES CONHECIDAS E OBTIDAS PARA O PROBLEMA COM 5 DIMENSÕES original possui forte ascendência com o passar do tempo. Esse fato ocorre devido à necessidade de armazenar todos os retângulos testados. Utilizado o algoritmo otimizado, o consumo de memória se manteve estável em patamares bem inferiores, consumindo quantidades de memória equivalentes para todos os cenários testados. Observe que o sistema de 7 dimensões demorou 498 minutos (8 horas e 18 minutos). Memória (Kb) Tempo (segundos) Original Otimizado Solução Solução 1 Tabela III. Solução Solução 1 Solução 2 Solução 3 Solução 4 Solução conhecida Solução Algoritmo Original Solução Algoritmo Otimizado VALORES DAS SOLUÇÕES CONHECIDAS E OBTIDAS PARA O PROBLEMA COM 7 DIMENSÕES Solução conhecida Solução Algoritmo Original Solução Algoritmo Otimizado Figura 10. Consumo de memória do problema com 3 dimensões Memória (Kb) Tempo (segundos) Original 200 Otimizado Figura 11. Consumo de memória do problema com 5 dimensões Memória (Kb) Tempo (minutos) Original Otimizado Figura 12. Consumo de memória do problema com 7 dimensões Todos os experimentos associados aos resultados destes gráficos executaram até o final e não foram abortados, mas servem para mostrar o porquê muitos experimentos são abortados durante a sua execução na versão original. Observe UEM - 10 A 14 DE SETEMBRO

36 que a memória consumida com 5 variáveis foi maior que aquela consumida com 7 variáveis. A justificativa para tal ocorrência é que o primeiro caso usou mais subdivisões (5) que no segundo caso (3). VI. CONCLUSÕES E TRABALHOS FUTUROS O presente artigo apresenta uma versão otimizada do algoritmo de subdivisão SubDivNL utilizado na geração de estimativas iniciais para sistemas de equações não-lineares que simulam o problema da coluna de destilação reativa. Visando garantir o mesmo comportamento para todas as execuções, a definição da semente utilizada na geração de números aleatórios a cada sub-retângulo gerado foi baseada no identificador de cada sub-retângulo. Para otimizar o uso de memória, o algoritmo original foi alterado de forma que a abordagem de criação da árvore de estimativas foi alterada de busca em largura para busca em profundidade. Essa modificação foi necessária devido ao fato da implementação do algoritmo original produzir estouro de memória quando o número de dimensões do sistema de equações não lineares e a quantidade de subdivisões aplicadas ao retângulo inicial, devido ao crescimento acelerado do número de retângulos observados, consumiam toda a capacidade de armazenamento. Dados obtidos em três casos reais conhecidos foram utilizados para a realização dos experimentos, com 3, 5 e 7 dimensões. Os resultados gerados pelos algoritmos aqui implementados foram comparados com os valores reais, validando a geração das estimativas produzidas pelos algoritmos. A partir dos resultados obtidos, observou-se que os tempos de execução dos algoritmos são semelhantes, com pouca variação. Entretanto, a versão otimizada possibilita aplicar um número maior de subdivisões nos problemas sem que ocorram erros de violação de memória. Como trabalhos futuros, objetiva-se experimentar sistemas com maior número de variáveis, aumentando também o número de iterações e subdivisões. Além disso, pretende-se paralelizar a aplicação aqui otimizada com o propósito de agilizar a sua execução e viabilizar a obtenção de soluções para sistemas mais complexos. Tal paralelização deverá tratar diferentes formas para quebrar a árvore de estimativas e distribuí-las entre os processadores, levando em considerações questões de balanceamento. REFERÊNCIAS [1] Machado, G. D. Produção de biodiesel por esterificação em coluna de destilação reativa: modelagem matemática. Dissertação de Mestrado, Universidade Estadual de Maringá, Maringá - PR, [2] Corazza, F. C.; Oliveira, J. V.; Corazza, M. L. Application of a subdivision algorithm for solving nonlinear algebraic systems. Acta Scientiarum, v. 30, n. 1, [3] Li, G.; Zeng, Z. A Neural-Network Algorithm for Solving Nonlinear Equation Systems, International Conference on Computational Intelligence and Security, [4] Ouyang, A., Luo, Q. Hybrid particle swarm optimization algorithm for solving systems of nonlinear equations. International Conference on Granular Computing, [5] Yuanbin, W., Bin, Z. Tianshun, Y. A Fast Method for Solving System of Nonlinear Equations in Fundamental Matrix Estimation. Second International Symposium on Electronic Commerce and Security, ISECS '09. Vol. 2. Pages , [6] Yin, Q.; Qi, Y.; Xiao, J. Detecting Roots of Nonlinear Equations through a Novel Differential Evolution Algorithm. 2nd International Conference on Information Engineering and Computer Science (ICIECS), [7] Tenenbaum, A. A.; Langsam, Y.; Augenstein, M. J. Estruturas de dados usando C. Makron Books, [8] Polymath-Software Numerical library problems involving simultaneous nonlinear equations. Disponível em: Acesso em: 20/01/2011, [9] Smiley, M.W.; Chun, C. Na algorithm for finding all solutions of a nonlinear system. Journal of Computational and Applied Mathematics - J COMPUT APPL MATH, vol. 137, no. 2, pp , 2001 UEM - 10 A 14 DE SETEMBRO

37 Engenharia de Software UEM - 10 A 14 DE SETEMBRO

38 Métodos e Técnicas de Desenvolvimento de Linha de Produto de Software para Sistemas E-Commerce: um Mapeamento Sistemático Joyce M. Mathias Universidade Estadual de Maringá (UEM) Departamento de Informática (DIN) joycemln7@gmail.com Edson A. Oliveira Junior Universidade Estadual de Maringá (UEM) Departamento de Informática (DIN) edson@din.uem.br Resumo A abordagem de Linha de Produto de Software (LPS) tem como objetivo promover a geração de produtos específicos com base na reutilização de um núcleo de artefatos. Esse núcleo contem elementos similares bem como características que variam de acordo com produtos específicos. Este artigo apresenta o estado da arte sobre o desenvolvimento de LPS para sistemas e- commerce já que esse é um domínio interessante do ponto de vista de variabilidade. Palavras-chave: Gerenciamento de Variabilidade, Sistemas E-Commerce, Linha de Produto de Software, UML. I. INTRODUÇÃO O crescente aumento do comércio eletrônico por meio de sistemas de software acessados por uma rede, internet ou intranet, vem motivando o desenvolvimento de novas tecnologias e padrões. Metodologias e técnicas de desenvolvimento de sistemas de software para e-commerce têm sido propostas pela literatura e aplicadas na prática por empresas de grande porte como IBM, Google e Microsoft [2]. Sistemas e-commerce se caracterizam por fornecer serviços, muitas vezes distribuídos fisicamente em diferentes computadores [2]. Esses serviços vão desde o armazenamento e a recuperação de dados dos clientes e suas compras até movimentação financeira. Tais serviços caracterizam grande parte dos sistemas e-commerce, formando uma infraestrutura comum de serviços. Com base nisso, entende-se que seja possível gerenciar tais serviços, similaridades ou variabilidades, por meio da abordagem de Linha de Produto de Software (LPS). Assim, vários sistemas podem ser desenvolvidos por meio da instanciação de tal infraestrutura comum para o domínio de sistemas e- commerce. Nos últimos anos a abordagem de LPS vem se destacando com uma forma sistemática de reutilização de software, sendo aplicados por meio de técnicas similares a partir de um conjunto de especificações de softwares comuns a determinado domínio, assim tornando-se um meio de se atingir a customização em massa [5]. Uma LPS é um conjunto de sistemas de software que compartilham funcionalidades em comum e gerenciáveis que satisfazem as necessidades específicas de um determinado segmento do mercado [5]. Esse conjunto de sistemas também é chamado de família de produtos e seus membros são desenvolvidos especificamente a partir de uma infraestrutura comum de LPS, o núcleo de artefatos. O núcleo de artefatos forma a base de uma LPS e, normalmente, inclui a arquitetura de LPS, componentes reutilizáveis, modelos de domínios, requisitos da LPS, planos de teste e modelos de características e de variabilidades [6]. Este artigo apresenta um mapeamento sistemático com o objetivo de apresentar o estado da arte sobre metodologias e técnicas de desenvolvimento de LPS para sistemas e- commerce. Para tanto, foram abordadas as seguintes questões: (i) identificação de quais são os métodos específicos utilizados no desenvolvimento de LPS para sistemas e-commerce; e (ii) identificação de técnicas específicas aplicadas à abordagem de LPS desenvolvimento de sistemas e-commerce. Este artigo está organizado da seguinte forma: a Seção 2 apresenta os procedimentos de coleta dos dados e resultados, incluindo o planejamento e a condução do mapeamento sistemático; a Seção 3 apresenta uma análise e discussão sobre os resultados obtidos com o mapeamento sistemático em termos de técnicas e métodos para o desenvolvimento de sistemas e-commerce; a Seção 4 apresenta uma síntese dos trabalhos selecionados para leitura na íntegra e que efetivamente contribuem com o estado da arte sobre o tema abordado; e a Seção 5 apresenta a conclusão e possíveis trabalhos futuros. II. COLETA DE DADOS Um mapeamento sistemático é uma abordagem rigorosa e bem definida para identificar, avaliar e interpretar todas as pesquisas disponíveis com relação a um tema específico de interesse [3]. Os elementos que fornecem evidências de pesquisa sobre um tema especifico são classificados como estudos primários. Na realização deste mapeamento sistemático foram focados dois pontos principais: (i) identificar quais os métodos específicos utilizados no desenvolvimento de uma LPS para UEM - 10 A 14 DE SETEMBRO

39 sistemas e-commerce; e (ii) identificar técnicas específicas aplicadas à LPS para sistemas e-commerce. Com base nesses pontos, foi possível definir uma questão de pesquisa primária (QP1) e uma questão secundária (QP2), sendo elas: QP1 estudos que relacionam a abordagem de LPS com o desenvolvimento de sistemas e-commerce; e QP2 - estudos que apresentam metodologias e/ou técnicas específicas de desenvolvimento de sistemas e-commerce com base na abordagem de LPS. Tais questões de pesquisa norteiam a definição de uma string de busca que é fundamental para a realização de um mapeamento sistemático. Essa definição depende essencialmente da experiência dos pesquisadores envolvidos no processo de mapeamento sistemático para permitir que a string englobe o maior número possível de estudos relacionados ao tema em questão. Para tanto, foi definida uma string de busca com base em dois termos principais e suas variações - software product line e e-commerce: Software AND ("product-line" OR product line" OR "system family" OR "family of products" OR "family of systems" OR "production line") AND ("ecommerce" OR electronic commerce" OR "B2C" OR "business to consumer" OR "B2B" OR "business to business") AND (method OR approach OR methodology OR process OR principle OR technique) As fontes de dados eletrônicas indexadas selecionadas para o levantamento dos dados foram: IEEE, ACM, ScienceDirect e Compendex. As máquinas de busca eletrônica Scirus (Elsevier) e Google Scholar também foram consideradas. Além da definição da string de busca e das fontes de dados, critérios de inclusão e exclusão são extremamente importantes, pois guiam a leitura na íntegra dos trabalhos mais relevantes. Assim, os critérios de inclusão estabelecidos para atender a cada uma das questões de pesquisa são: estudos que relacionam desenvolvimentos de produtos e-commerce com LPS; estudos que apresentam princípios, metodologias e técnicas utilizadas para o desenvolvimento de LPS para sistemas e-commerce. Já os critérios de exclusão definidos foram: estudos que não relacionam de forma alguma desenvolvimento de sistemas e-commerce com LPS; estudos que não apresentam princípios, metodologias e técnicas relacionadas ao desenvolvimento de sistemas e-commerce por meio da abordagem de LPS; estudos que não estejam publicados em língua inglesa; estudos recuperados de meios eletrônicos que não estejam no formato PDF (Portable Document Format), DOC (Processador de Texto Microsoft Word) ou ODT (Processador de Texto do Open Office), sendo esses os meios mais comuns de divulgação de estudos; estudos duplicados, encontrados anteriormente em outra(s) fonte(s); estudos que não puderam ser recuperados (nãodisponíveis). Uma vez recuperados os estudos por meio da aplicação da string de busca às fontes de dados selecionadas, deve-se realizar um processo de seleção preliminar por meio da verificação dos critérios de inclusão e exclusão definidos, bem como da leitura dos títulos e dos resumos de cada estudo recuperado. Dessa forma, eliminam-se trabalhos que não satisfazem tais critérios de inclusão e exclusão. Se algum critério de exclusão referente à QP1 for identificado, o trabalho será descartado para leitura na íntegra. Se houver falta de consenso entre os revisores, esse trabalho é colocado em espera, e sua inclusão ou exclusão é definida em reuniões posteriores entre os revisores. Os trabalhos remanescentes da seleção preliminar são lidos por pelo menos um dos revisores, responsável por elaborar um resumo, destacando a abordagem apresentada e os conceitos envolvidos no trabalho. No decorrer do processo todos os passos realizados no levantamento de dados são documentados, a fim de permitir auditabilidade e replicabilidade, que são dois requisitos básicos para mapeamento sistemático. III. ANÁLISE DOS RESULTADOS E DISCUSSÃO O mapeamento sistemático foi conduzido por um período de cinco meses (Junho/2011 a Novembro/2011). Na IEEE a string de busca foi aplicada com o parâmetro Metadata Only, onde indica a busca em todos os campos possíveis dos trabalhos publicados na IEEE. Foram obtidos 08 artigos relacionados, todos eles disponíveis no formato PDF, representando 7% do total de trabalhos recuperados. Na ACM a busca foi realizada no resumo (abstract) dos trabalhos, as demais opções ficaram preenchidas com o padrão (default) do mecanismo de busca. Foram obtidos 32 artigos relacionados, todos eles disponíveis no formato PDF, representando 30% do total de trabalhos recuperados. Na ScienceDirect foi possível realizar a busca por expressões booleanas e ano da publicação. Foi obtido 01 artigo relacionado todo ele disponíveis no formato PDF, representando 1% do total de trabalhos recuperados. UEM - 10 A 14 DE SETEMBRO

40 Na Scirus foi possível realizar a busca de trabalhos disponíveis na íntegra. Além disso, é foi possível definir em que local do trabalho a sequência de consulta será avaliada como, por exemplo, o ano de publicação e o formato dos trabalhos (pdf, html, doc ou qualquer formato). Foram obtidos 26 artigos relacionados todos eles disponíveis no formato PDF, representando 24% do total de trabalhos recuperados. Na Scirus foi possível realizar a busca de trabalhos disponíveis na íntegra. Além disso, foi possível realizar a definição do local no trabalho onde a sequência de consulta será aplicada, como por exemplo, ano de publicação e o formato dos trabalhos (pdf, html, doc ou qualquer formato). Foram obtidos 26 artigos relacionados, todos eles disponíveis no formato PDF, representando 24% do total de trabalhos recuperados. A busca em Google Scholar foi possível realizar a busca de trabalhos disponíveis na íntegra, onde foi possível definir em que local do trabalho a string será avaliada como, por exemplo, o título ou a URL dos trabalhos. Foram obtidos 26 artigos relacionados todos eles disponíveis no formato PDF, representando 24% do total de trabalhos recuperados. A busca na Compedex foi realizada por meio da aplicação da string de consulta onde permitiu fazer a busca por expressões booleanas e ano da publicação. Foram obtidos no total 15 trabalhos. Pode-se notar o número reduzido de trabalhos relevantes a este artigo. Acredita-se que isso se deve ao fato de o domínio de sistemas e-commerce possuir um número grande de variabilidades, além da diversificação de tecnologias e padrões existentes para o desenvolvimento de produtos para tal domínio. Tal justificativa pode ser explorada com o objetivo de utilizar sistemas e-commerce para a validação experimental de abordagens existentes de gerenciamento de variabilidade. IV. SÍNTESE DOS TRABALHOS SELECIONADOS Nesta seção são apresentados os estudos efetivamente selecionados durante o mapeamento sistemático, ressaltando as técnicas e métodos aplicados em cada um. O título das subseções é o título do artigo para melhor identificação dos estudos. TABLE I. ESTUDOS PRÉ-SELECIONADOS. Ref. Título Autor(es) Ano 1 A Template based Approach for Xiyong Zhu Mass Customization of Serviceoriented E-business Applications Xingwang heng Best Practices of RUP in Software F. Ahmed Product Line Development L. F. Capretz A Software Product Line Approach M. A. Laguna for E-Commerce Systems C. Hernández E-commerce and Supply Chain Management: Fitting the Pieces Together E-business cases assessment: from business value to system feasibility Activity-Based Management for Electronic Commerce: A Structured Implementation Procedure Towards Automatic Derivation of a Product Performance Model from a UML Software Product Line Model Seamless Development of Software Product Lines Feature Models to UML Traceability A Framework for Handling Variants of Software Models Survey of Product-Line Verification and Validation Techniques Product Model Derivation by Model Transformation in Software Product Lines E-commerce and Supply Chain Management: Fitting the Pieces Together A customizable Approach to full Lifecycle Variability Management Kwanwoo Lee Kyo C. Kang Jaejoon Lee Ziv aida,; Hans de Bruin,; Jaap Gordijn Narcyz oztocki 2010 R. Tawhid D. C. Petriu Miguel A. Laguna Bruno González- Baixauli Christian Pichler 2010 Robyn Lutz 2007 Rasha Tawhid Dorina C. Petriu 2011 Toral Mehta 2008 Klaus Schmid Isabel John 2003 Figura 1: Número total de trabalhos obtidos por fonte de busca. Para a realização da seleção preliminar foram lidos os títulos e os resumos de todos os 108 estudos recuperados. Desse total, 13 estudos foram selecionados para a leitura na íntegra (Tabela 1). Após a leitura completas dos 13 estudos selecionados, foi possível avaliar a qualidade efetiva de cada um deles com relação aos critérios de inclusão e exclusão. Sendo assim, dos 13 estudos lidos na íntegra, 10 foram rejeitados por não estarem de acordo com as expectativas e objetivos em questão, enquanto 03 trabalhos foram considerados, sendo eles os de número 02, 03 e 07 (Tabela 1) BEST PRACTICES OF RUP IN SOFTWARE PRODUCT LINE DEVELOPMENTS [1] discutem o Rational Unified Process (RUP) em que são apresentadas as seis melhores práticas para o desenvolvimento de LPS para obter melhores projetos em termos de reutilização, qualidade, custo e cronograma. Tais melhores práticas de LPS com base no RUP são (Figura 2): Desenvolver iterativamente LPS de forma que o esforço seja reduzido para a produção de produtos similares; UEM - 10 A 14 DE SETEMBRO

41 Arquitetura baseada em componentes é essencial do ponto de vista da arquitetura de LPS e o reuso de componentes pré-existentes; Verificar qualidade é uma prática já realizada no RUP em estágios iniciais e que contribui com a abordagem de LPS no que tange a verificação dos artefatos que formam a infraestrutura central de uma LPS. A qualidade de tais artefatos reflete na qualidade dos produtos específicos gerados a partir de tal infraestrutura; Mudança ou alteração de controle as flechas dos círculos rotacionais da Figura 2 indicam que as atividades essenciais de LPS fornecem e recebem artefatos de outras atividades. Mudanças em requisitos existentes de uma LPS devem ser controladas e refletem diretamente no plano de produção dos produtos da LPS; Gerenciar os requisitos é uma prática extremamente importante, pois uma LPS tende a evoluir com o passar do tempo e novos requisitos são introduzidos. Tal mudança exige um rastreamento intenso das variabilidades de uma LPS, bem como dos artefatos onde ocorrem tais variações; Modelagem visual permite facilitar a construção e fornecer representação visual dos produtos que estão sendo gerados a partir da LPS. principais ativos da infraestrutura e das chances de reutilização A Software Product Line Approach for E-Commerce Systems [4] apresentam uma abordagem de desenvolvimento de LPS para sistemas e-commerce. Com base em tal abordagem, o modelo de arquitetura da LPS é construído a partir de um pacote base que reúne os aspectos comuns de uma LPS. Cada variabilidade é mapeada no modelo original como um pacote, conectados por meio de uma dependência com o estereótipo <<merge>>. A ferramenta Feature Modeling Tool (FMT), Figura 3, permite a modelagem de características de uma LPS, além de poder ser integrada ao Visual Studio e gerar a estrutura de pacotes para uma LPS. Uma vez modelada a LPS e os seus produtos específicos, a FMT gera automaticamente todos os pacotes que representam os produtos específicos. Esse processo pode ser visto na Figura 4. Figura 3: Modelagem de Características de LPS com a FMT [4]. Figura 2: RUP e as suas Melhores Práticas de LPS [1]. Assim, as melhores práticas do RUP aliadas à abordagem de LPS permitem desempenhar um papel considerável no sentido de reforçar o processo de desenvolvimento de produtos a partir de uma LPS. Práticas de alterações de controle podem fornecer uma forma sistemática para acomodar as mudanças necessárias na LPS. Gerenciar os requisitos pode aumentar a produtividade da infraestrutura central da LPS e o gerenciamento de variabilidades. A modelagem visual contribui na identificação de possíveis produtos a serem gerados a partir da LPS. A arquitetura baseada em componentes pode resultar em aumento dos Figura 4: Funções Manuais e Automatizadas da FMT para LPS [4]. UEM - 10 A 14 DE SETEMBRO