III SEMANA DE INFORMÁTICA

Transcrição

1 ISSN: Universidade Federal de Sergipe - UFS Departamento de Sistemas de Informação - DSI III SEMANA DE INFORMÁTICA Itabaiana, Sergipe, Brasil Novembro de 2013

2 Prefácio SEMINFO/UFSITA 2013 A Semana de Informática da Universidade Federal de Sergipe - Campus Itabaiana é um evento Regional, apoiado pelo Departamento de Sistemas de Informação (DSI) e organizado pela Itatech Jr. (Empresa Júnior do DSI). Através de palestras, minicursos e apresentações de artigos acadêmicos, o evento visa proporcionar aos participantes acesso a novos conhecimentos, conceitos e tecnologias. As palestras e minicursos são ministradas por profissionais referência no mercado de tecnologia regional, proporcionando forte integração entre a comunidade acadêmica e a indústria. A sessão de artigos científicos, inaugurada em 2012, tem recebido submissões de todo o Brasil, criando um novo fórum de discussões para trabalhos científicos, que extrapolou as fronteiras regionais. Sempre colocando temas atuais em foco, em 2013 a Semana de Informática terá o tema Desenvolvimento Móvel e Geoprocessamento: A Nova Tendência. HISTÓRICO A primeira edição do evento ocorreu no período de 24 à 26 de novembro de 2010, na qual foram promovidas discussões sobre diversos temas, com destaque para o seguinte: O Uso de Software Livre nas Instituições Públicas e Privadas, além de minicursos nas áreas de redes e qualidade de software. A segunda edição aconteceu no período de 17 à 19 de outubro de 2012, sob o tema principal: Empreendedorismo e Inovação. Além das palestras e minicursos relacionados ao tema, o evento trouxe diversos casos de sucesso de empresas regionais, com a apresentação de dicas aos futuros empreendedores. Ainda nesse ano foi inaugurada a sessão de artigos científicos, na qual foram submetidos 17 artigos, sendo 11 aprovados. Os anais do evento foram registrados através do ISSN Prof. Msc. Marcos Barbosa Dósea - Coordenação Geral Prof. Msc. Alcides Xavier Benicasa - Coordenador Geral do Comitê de Programa i

3 Comitê Organizador SEMINFO/UFSITA 2013 Coordenação Geral Prof. Msc. Marcos Barbosa Dósea Universidade Federal de Sergipe - UFS Departamento de Sistemas de Informação - Itabaiana - SE Comitê Organizador Dr. Methanias Colaço Rodrigues Júnior - UFS Msc. Alcides Xavier Benicasa - UFS Msc. Andrés Ignácio Martínez Menéndez - UFS Msc. Marcos Barbosa Dósea - UFS Antônio Douglas Oliveira Cruz - UFS Breno Santana Santos - UFS Edmo Felipe Ferreira Ramos dos Santos - UFS Ednilson Messias Castro dos Santos - UFS Éuder de Jesus Costa - UFS Gilmar Carvalho Santana - UFS Guilherme Bruno Viturino Alves - UFS Jalisson Tavares Costa - UFS Luan Lima - UFS Nathan Oliveira Vasconcelos - UFS Tauany Lorene Santana Santos - UFS Thiago da Silva Almeida - UFS Coordenador Geral do Comitê de Programa Prof. Msc. Alcides Xavier Benicasa - UFS Universidade Federal de Sergipe - UFS Departamento de Sistemas de Informação - Itabaiana - SE ii

4 Comitê de Programa SEMINFO/UFSITA 2013 Universidade Federal de Sergipe - UFS Departamento de Sistemas de Informação - Itabaiana - SE Profa. Msc. Mai-Ly Vanessa Almeida S. Faro Prof. Dr. Joseval De Melo Santana Prof. Msc. Aélio Oliveira Prof. Msc. Alcides Xavier Benicasa Prof. Msc. André Luis Meneses Silva Prof. Msc. André Vinicius R.P. Nascimento Prof. Msc. Andrés Ignácio Martínez Menéndez Prof. Msc. Marcos Barbosa Dósea Universidade Federal de Sergipe - UFS Departamento de Computação - São Cristovão - SE Profa. Dra. Adicinéia Oliveira Profa. Dra. Kenia Kodel Cox Prof. Dr. Alberto Costa Neto Prof. Dr. André Britto de Carvalho Prof. Dr. Rogério Patrício Chagas do Nascimento iii

5 Comitê de Programa SEMINFO/UFSITA 2013 Universidade Federal Fluminense - UFF Departamento de Computação - Rio de Janeiro - RJ Prof. Dr. Daniel Paiva Universidade Federal do Amazonas - UFAM Instituto de Ciências Exatas e Tecnologias- Itacoatiara - AM Prof. Dr. Jorge Yoshio Kanda Universidade de São Paulo - USP Instituto de Ciências Matemáticas e de Computação - São Carlos - SP Prof. Dr. Renato Ramos da Silva Instituto Federal de São Paulo - IFSP Instituto Federal de Educação, Ciência e Tecnologia- São Carlos - SP Prof. Ms. Giampaolo Luiz Libralon Instituto Nacional de Pesquisas Espaciais - INPE Instituto de Estudos Avançados - São José dos Campos - SP Prof. Ms. Marcelo Módolo iv

6 Índice SEMINFO/UFSITA 2013 PIAI - Processamento de Imagens aplicado à Apresentação Interativa 1 Thiago Da Silva Almeida, Ed Charles Nascimento Ferreira, Nathanael Oliveira Vasconcelos, Breno Santana Santos e Alcides Xavier Benicasa CodeAnalyzer: uma ferramenta para inspeção automática de código-fonte 5 Israel Antonio Pinto Silva, Wendell Antildes Marcolino Sampaio e Alberto Costa Neto Uma Análise Comparativa de abordagens para lidar com a Evolução e Customização de Sistemas 9 Fernanda Almeida Passos, Raphael Ferreira Santos Barreto, Kleber Tarcísio Oliveira Santos e Alberto Costa Neto Mecanismos de Proteção de Ativos Intelectuais de Tecnologia da Informação existentes no Brasil 14 Pedro Silva Neto e Maria Augusta Silveira Netto Nunes Factory facilitando a disponibilização de novos serviços na nuvem 18 Tássio Augusto Da Cruz Guimarães, Vinícius Castro, Jonas Santos Bezerra e Tarcísio Da Rocha Desenvolvimento de Banco de Dados para Cadastro e Comparação de Moléculas de Plantas do Semiárido Brasileiro - SAM Database 22 Tiago Nery de Oliveira, Bruno Silva Andrade, Alex Ferreira Dos Santos, Wagner Rodrigues de Assis Soares, Géssica Alves Teixeira de Melo, Maicon Vinícius Araújo Santos Silva e Ellison Barros Oliveira Análise de desempenho da paralelização do cálculo da matriz de correlação com tamanho arbitrário, utilizando GPU 25 Chaina Oliveira, Iris Santos e Carlos Montesco Automação de Testes de Unidade em um Ambiente de Data Warehouse 29 Wenderson Pereira, Igor Peterson Santos, Andre Nascimento e Methanias Colaço Júnior Programa DIVERGEN: Aplicativo Estimador da Diversidade Genética em Plantas 33 Elienai Bitencourt Batista, Tiago Nery de Oliveira, George Oliveira Barros, Cláudio Lúcio Fernandes Amaral e Naiara Silva Dos Santos v

7 Índice de Autores SEMINFO/UFSITA 2013 Almeida Passos, Fernanda 9 Almeida, Thiago Da Silva 1 Alves Teixeira de Melo, Géssica 22 Antildes Marcolino Sampaio, Wendell 5 Antonio Pinto Silva, Israel 5 Augusto Da Cruz Guimarães, Tássio 18 Barros Oliveira, Ellison 22 Benicasa, Alcides Xavier 1 Bitencourt Batista, Elienai 33 Castro, Vinícius 18 Colaço Júnior, Methanias 29 Costa Neto, Alberto 5, 9 Da Rocha, Tarcísio 18 Ferreira Dos Santos, Alex 22 Ferreira Santos Barreto, Raphael 9 Ferreira, Ed Charles Nascimento 1 Lúcio Fernandes Amaral, Cláudio 33 Montesco, Carlos 25 Nascimento, Andre 29 Nery de Oliveira, Tiago 22, 33 Oliveira Barros, George 33 Oliveira, Chaina 25 Pereira, Wenderson 29 vi

8 Rodrigues de Assis Soares, Wagner 22 Santos Bezerra, Jonas 18 Santos, Breno Santana 1 Santos, Igor Peterson 29 Santos, Iris 25 Silva Andrade, Bruno 22 Silva Dos Santos, Naiara 33 Silva Neto, Pedro 14 Silveira Netto Nunes, Maria Augusta 14 Tarcísio Oliveira Santos, Kleber 9 Vasconcelos, Nathanael Oliveira 1 Vinícius Araújo Santos Silva, Maicon 22 vii

9 Índice de Palavras-Chave SEMINFO/UFSITA 2013 Automação 18 Banco de dados 22 Bioinformática 22 Comparative Analysis 9 Computação em Nuvem 18 CPU 25 CUDA 25 Data Warehouse 29 Direito Autoral 14 Eclipse plug-in 5 Genética 33 GPU 25 Histograma de Cores 1 Interação Humano-computador 1 Matriz de Correlação 25 Melhoramento de plantas 33 Molécula 22 Patente 14 Processamento de Imagens 1 Projeção de Imagem 1 Propriedade Industrial 14 Propriedade intelectual 14 viii

10 Qualidade de Dados 29 Registro de Software 14 Semi-árido baiano 22 Serviços 18 Software 33 Software Customization 9 Software Livre 14 Software Público 14 Source Code Inspection 5 Static Analyzer 5 Testes de Software 29 Triagem Virtual 22 Variability 9 ix

11 PIAI - Processamento de Imagens aplicado à Apresentação Interativa Thiago da Silva Almeida, Ed Charles Nascimento Ferreira, Nathanael Oliveira Vasconcelos, Breno Santana Santos e Alcides Xavier Benicasa Departamento de Sistemas de Informação - DSI Universidade Federal de Sergipe - UFS Itabaiana-SE, Brasil {breno1005, nathan-vasconcelos}@hotmail.com; {charles.si.ufs, thiago7a}@gmail.com; alcides@ufs.br Resumo A interação intuitiva entre humanos e computadores é um campo de pesquisa que tem sido bastante investigada nos últimos anos. O uso de diferentes tipos de sensores, como por exemplo, sensores de movimento, toque, etc, têm proporcionado grandes avanços nesta área. Entretanto, de acordo com a especificidade de cada sensor, o custo para o desenvolvimento de determinadas aplicações torna-se, muitas vezes, inviável. Sendo assim, este artigo tem como objetivo apresentar técnicas de processamento de imagem como um mecanismo alternativo ao uso de sensores reais, neste caso, sensores de toque. Para validação do mecanismo proposto, foi desenvolvida uma aplicação que torna possível a interação intuitiva entre o usuário e a imagem projetada por um projetor de imagem (datashow). Os resultados obtidos demonstram a efetividade do mecanismo proposto. Keywords-Processamento de imagens, interação humanocomputador, projeção de imagem, histograma de cores; I. INTRODUÇÃO Nos últimos anos os computadores têm se tornado dispositivos comuns ao cotidiano das pessoas, uma vez que sua usabilidade apresenta-se cada vez mais interativa. Diversas aplicações têm sido propostas com o objetivo de aproximar, facilitar ou ainda, tornar possível a interação entre o homem e a máquina, como por exemplo, o processamento da linguagem natural, de forma a ser compreendida automaticamente como texto, o que no passado somente seria possível através de processos mecânicos de digitação. Outro exemplo de interação pertinente, atualmente emergente entre os dispositivos encontrados no mercado, é o uso de gestos como meio de comunicação com diferentes tipos de dispositivos. Sendo assim, considerando o uso de gestos um recurso natural do ser humano se comunicar, a possibilidade de utilizá-los na comunicação com dispositivos computacionais permite com que estes sejam utilizados de modo bastante natural e intuitivo. De acordo com os avanços tecnológicos dos últimos anos, a interação entre o homem e a máquina de forma gestual não pertence mais somente aos filmes de ficção científica, como por exemplo, no filme Minority Report 1, mas sim como um 1 Filme de ficção científica lançado no ano de 2002 e dirigido por Steven Spielberg viés que vem ocupando um importante modo de interação, de modo a ocupar, de forma real, o dia-a-dia de milhares de usuários. Atualmente, diversos consoles, computadores e smartphones apresentam funcionalidades de interatividade baseadas em comandos por voz, gestos, ou ainda, pela captura de movimentos do globo ocular. De acordo com Rusnak [11], os sistemas presentes nestes dispositivos, os quais permitem este tipo de interação, são denominados por sistemas interativos. Ainda de acordo com Rusnak [11], os sistemas interativos são compostos pelos seguintes componentes: subsistema de visualização, camada de comunicação e camada de interação. Dentre estes, destacamos o último componente citado, o qual é o principal ponto de investigação deste trabalho. A camada de interação pode ainda ser dividida em três categorias distintas, sendo: superfície multi-touch, sensoriamento sem toque e dispositivos de apontamento [11]. O primeiro, tem como função permitir ao usuário interagir com aplicações utilizando um ou mais dedos, onde o principal elemento é uma tela sensível a múltiplos toques. O segundo, torna possível a interação do usuário à aplicações, mesmo à distância, através de gestos captados a partir dos movimentos das mãos e, em alguns casos específicos, movimentos do corpo inteiro e comandos de voz. Finalmente, a terceira categoria, que refere-se aos dispositivos de apontamento, possui como característica principal o uso de dispositivos físicos, como por exemplo, a utilização de canetas digitais e smartboards para a interação direta com aplicações, ou ainda, o uso de smartphones, utilizado muitas vezes como um dispositivo de controle para aplicações remotas, por meio de sensores, como exemplo, proximidade e acelerômetro. Nos últimos anos, diversas pesquisas têm sido realizadas na área de sistemas interativos, relacionada às categorias citadas anteriormente. Entretanto, de acordo com os objetos deste trabalho, destacamos aqui alguns trabalhos pertinentes ao sensoriamento sem toque. Nesta linha de pesquisa, Baudel [3] propuseram uma uma aplicação, denominada de CHARADE, que permite ao usuário controlar o computador durante uma apresentação com slides apenas utilizando gestos de mão. Para isto, os autores utilizaram uma luva especial, ligada a um controlador, responsável pela detecção 1

12 dos movimentos. Recentemente, um dispositivo que tem se destacado na área de sistemas interativos, e que tem sido utilizado em aplicações baseadas em interação através de gestos, é o Kinect 2. De acordo com Microsoft [9], com o Kinect é possível desenvolver aplicações que permitem aos usuários interagir com computadores por gestos ou fala. Contudo, é importante notar que, os custos para o acesso a esta tecnologia ainda não são acessíveis à maioria da população. De acordo com o revendedor oficial do produto no Brasil, Brasoftware [4], o produto tem sido comercializado por 999 reais, possuindo também uma versão acadêmica, comercializada por 150 dólares, porém, disponível em apenas três países, dentre os quais o Brasil não se encontra. Este trabalho possui como principal objetivo propor uma aplicação que, utilizando técnicas de processamento de imagem, torne possível a detecção e interação do usuário com o computador, a partir de informações providas por uma câmera de vídeo, de modo que não seja necessária a utilização de sensores especiais. Na seção seguinte será apresentada a revisão da literatura, onde será discutido o embasamento teórico necessário ao entendimento deste trabalho, além da abordagem breve das técnicas e bibliotecas utilizadas para o desenvolvimento deste trabalho. Na seção de metodologia, descreveremos a aplicação proposta, com ênfase em seu fluxo de funcionamento. Finalmente, apresentamos as conclusões finais deste trabalho. II. REVISÃO DA LITERATURA O uso de câmeras para detecção da interação do usuário com uma aplicação tem sido muito comum em sistemas interativos, em especial nas aplicações baseadas em sensoriamento sem toque, onde, além do uso da câmera, algoritmos de processamento de imagens são utilizadas para o tratamento e obtenção de informações relevantes da cena. Para Gonzalez [7], uma imagem pertencente a uma cena pode ser definida como uma função bidimensional f(x, y), composta por um determinado número de pixels, de modo que cada pixel deva possuir coordenadas de localizações x e y, associadas a um valor específico. É importante notar que o processamento de uma imagem depende diretamente destes valores. De acordo com Gonzalez [7], uma grande variedade de técnicas podem ser utilizadas para o processamento de imagens. De acordo com os objetos deste trabalho, destacamos as seguintes: transformação de imagens coloridas para tons de cinza, processamento de histograma de cores e o processo de limiarização de imagens. Normalmente, uma imagem capturada por uma câmera de vídeo é apresentada em cores, assim, cada pixel da imagem deve ser formado por um conjunto de valores, ou também 2 Sensor de movimentos desenvolvido inicialmente para para o Xbox 360 e Xbox One, junto com a empresa Prime Sense conhecido como canais de cores, geralmente de tamanho três ou quatro, podendo pertencer aos padrões de cores RGB (red, green e blue) ou CMY K (cyan, magenta, yellow e key=black), respectivamente. A combinação dos canais de cores pode representar uma grande variedade de cores, no entanto, muitas vezes essa quantidade de informação pode ser desnecessária para os objetivos de determinadas aplicações, de modo que seu processamento possa levar a desperdício de recurso. Uma forma para a resolução deste problema é a utilização de uma técnica de transformação para tons de cinza, considerado um processo simples sob os canais de cores. Aqui consideramos o padrão RGB, uma vez que este é o padrão de cores utilizado neste trabalho. A Equação 1, apresentada a seguir, descreve a transformação dos canais de um pixel i, pertencente ao padrão RGB, para tons de cinza, como segue: I i = R i + B i + B i 3 onde é calculada a média aritmética dos três canais de cores, R, G, e B do pixel i. I i é o valor do tom de cinza obtido, também conhecido como valor de intensidade, representando o pixel i por um único valor. Outra técnica de processamento de imagem utilizada neste trabalho é o processamento de histograma. De acordo com Marques [8], o histograma de uma imagem é composto por um conjunto de números, indicando o percentual de pixels contidos na imagem, que apresentam um determinado nível de cinza. Estes valores são normalmente representados por um gráfico de barras que fornece, para cada nível de cinza, o número, ou o percentual, de pixels correspondentes na imagem. A informação obtida através do cálculo do histograma de cores de uma imagem pode ser útil para a indicação de sua qualidade quanto ao nível de contraste, brilho médio, ou demais informações a serem utilizadas para fins específicos. De acordo com Gonzalez [7], o cálculo do histograma de cores pode ser descrito como: (1) h(r k ) = n k (2) onde r k é o k-ésimo nível de cinza e n k é o número de pixels da imagem contendo o nível de cinza r k. Na Figura 1 é apresentado um exemplo da aplicação das Equações 1 e 2. Uma outra técnica de processamento de imagens considerada neste trabalho é o de limiarização de imagem. De acordo com Marques [8], o objetivo da limiarização é identificar duas classes distintas na imagem, por meio do uso de um limiar para dividir a imagem em dois conjuntos de pixels. Considerando um limiar T, qualquer ponto x, y na imagem, tal que f(x, y) > T, será chamado de ponto do objeto, caso contrário, o ponto será chamado ponto de fundo [7]. Para Marques [8], esse processo também é conhecido 2

13 por um datashow comum, através de toques em regiões específicas da imagem projetada. A aplicação foi desenvolvida na linguagem Java, e conforme mencionado na seção anterior, foram utilizadas bibliotecas para manipulação de arquivos.ppt, captura de fotos e interface. Na Figura 2 é apresentado o layout da aplicação proposta. Figura 1. Exemplo de transformação para tons de cinza e cálculo do histograma de cores. Imagem Lena (512x512pixels) obtida de Gonzalez [7]. como binarização, pois tem como resultado uma imagem binária, composta por pixels brancos e pretos. O processo de limiarização é descrito como segue: 1 f (x, y) T lim(x, y) = (3) 0 f (x, y) < T Outro ponto importante considerado neste trabalho é a necessidade de comunicação entre os dispositivos físicos utilizados, no que refere-se à projeção e captura dinâmica das imagens. Para isto, foram utilizadas algumas bibliotecas de domínio público consolidadas em suas áreas, descritos brevemente como segue: 3 leitor de arquivo: para a leitura de arquivos.ppt foi utilizada a biblioteca POI-HSLF, que fornece mecanismos para ler, criar ou modificar apresentações elaboradas neste formato, desenvolvida e publicada por Apache [1], com o objetivo de criar e manter APIs Java para manipular arquivos do aplicativo Microsoft Powerpoint; captura de imagens: para a captura de imagens foi utilizada a biblioteca WEBCAM-CAPTURE de Bartosz [2], que permite o acesso a câmeras de vídeo diretamente a partir do código Java, possibilitando a leitura de imagens e detecção de movimentos, oferecendo suporte à diversas plataformas; interface: para o desenvolvimento da interface do aplicativo proposto foi utilizada a biblioteca INFONODE, disponível publicamente em [10], sendo uma API Java Swing, baseado em encaixe de frameworks, permitindo a criação de GUI Swing com considerável redução de código. Outra biblioteca utilizada foi a INSUBSTANTIAL [6], com o objetivo de permitir ao usuário personalizar o layout do aplicativo, de acordo com suas preferências e necessidades. III. M ETODOLOGIA A aplicação proposta neste trabalho possui como principal objetivo a interação do usuário com uma imagem projetada 3 Formato comumente utilizado para a elaboração de slides. Figura 2. Layout do aplicativo proposto. Como pode ser observado na Figura 2, os dispositivos necessários para a utilização do aplicativo proposto são bastante comuns em salas de apresentação, sendo os seguintes: computador, datashow e câmera, que pode ser a própria câmera embutida no computador. A aplicação proposta também possui como objetivo possibilitar ao usuário, tanto a execução normal de uma apresentação utilizando slides, quanto a execução interativa. Entretanto, daremos ênfase à segunda opção. Inicialmente, para permitir a interação do usuário com a imagem projetada foi necessário a inserção de algumas informações adicionais ao slide, ou imagem projetada, de forma que, intuitivamente, saiba-se onde e como a interação deva ocorrer. Para isto, foi criada uma máscara, como pode ser visto na Figura 2, que é incorporada à lateral direita da imagem projetada, composta, neste trabalho, por quatro funções f básicas: voltar, voltar para o início, avançar e ir para o final. De um modo geral, ao iniciar a execução do aplicativo em modo interativo, faz-se necessário definir na projeção onde estão localizadas as opções de navegação interativa, pois o processamento da imagem não ocorre sob toda a imagem projetada, mas sim em regiões específicas, as quais devem ser delimitadas inicialmente. Desta forma, caso a câmera de captura ou projeção mudar de posição, estas posições deverão ser novamente definidas. Uma dos principais pontos deste trabalho está relacionado à identificação do momento no qual uma determinada interação tenha ocorrido, assim como a função de navegação correta a ser executada. Considerando a aplicação do conjunto de técnicas de processamento de imagens apresentadas na seção anterior, foi possível diminuir, consideravelmente, a quantidade de informações a serem tratadas pela aplicação, 3

14 uma vez que a diferença entre os histogramas de cores de cada imagem capturada, seja a principal informação para a identificação da interação. Apesar de parecer uma tarefa trivial, a aplicação proposta neste trabalho, em um ambiente real, pode torna-se instável, uma vez que duas imagens capturadas em um intervalo de segundos, ou até menos do que um segundo, podem apresentar diferenças sutis no histograma, geradas por interferências do ambiente, mesmo que imperceptíveis à visão humana. Sendo assim, para que a comparação entre duas imagens, aparentemente iguais, seja realizada de forma correta, foi necessário definirmos um valor aceitável de diferença entre duas imagens, ou seja, um valor máximo de mudança, tornando possível a diferenciação entre uma interação real e variações naturais do ambiente. O valor de mudança aceitável, denominado aqui por σ, foi definido baseado no cálculo do desvio padrão dos valores dos histogramas para um conjunto de imagens capturadas, sequencialmente, em um intervalo curto de tempo. Inicialmente, o cálculo da média dos valores dos histogramas obtidos para um conjunto de imagens, referentes a uma determinada função, é descrito como segue: m f = 1 n f ( n f i= ) 255 h f i (r k) k=0 onde n f é o número de imagens capturadas referente à função f, k representa os níveis de cinza, h f i é o valor do histograma de cores da imagem i referente à função f e r k, conforme descrito na seção anterior, representa o k-ésimo nível de cinza. De acordo com Correa [5], o cálculo do desvio padrão é a medida mais usada para a comparação de diferenças entre conjuntos de dados, que consiste em determinar a dispersão dos valores em relação à media. Assim, o valor de mudança aceitável é definido como segue: (4) σ f = 1 n f n f (m f i m f ) 2 (5) i=1 Para uma descrição resumido do fluxo da aplicação proposta, após essa o cálculo de σ f, a apresentação é iniciada em modo interativo e, em intervalos de 300ms, uma imagem da apresentação é capturada, transformada em seguida para tons de cinza e limiarizada, calculando-se em seguida a média do histograma referente a cada função. A seguir, a média obtida é comparada à média dos histogramas do conjunto de imagens capturadas inicialmente (Equação 4) somado ao desvio padrão (Equação 5), de forma que, caso o valor da média do histograma obtido seja maior do que m f + σ f, pode-se concluir que houve uma interação, de forma que o comando relacionada à função que tenha apresentado a diferença seja executado. Para o caso de detecção simultânea de interação, nenhuma função deverá ser executada. IV. CONCLUSÕES A aplicação apresentou desempenho excelente em ambiente ideal, de modo que não houveram interpretações de funções erroneamente ou disparo de função na ausência de interação. O ambiente ideal foi definido como uma projeção realizada em superfície de fundo claro, com iluminação ambiente normal, ou ainda, sem iluminação no ambiente, contanto que, não exista incidência direta de luz forte sobre a projeção. Observou-se também que, utilizando um intervalo de 300 à 600ms entre cada imagem capturada, foi possível uma interação natural com a projeção. Intervalos de tempo maiores causaram um atraso entre o tempo de tentativa de interação e a execução da função. Por outro lado, intervalos menores fizeram com o que a função fosse executada diversas vezes. Pode-se concluir que, a aplicação proposta neste trabalho pode ser considerada com um interessante alternativa para o desenvolvimento da interação entre o homem e a máquina, onde, através de técnicas clássicas de processamento de imagens, foi possível dispensar o uso de dispositivos menos acessíveis. Como trabalhos futuros pode ser destacada a identificação automática dos botões da máscara utilizada na projeção, bem como a melhoria do algoritmo de identificação de interação para abranger ambientes diferentes do ambiente ideal, como por exemplo, projeções em superfícies escuras ou com incidência de luz forte sobre a projeção. REFERÊNCIAS [1] Software Foundation Apache. Poi-hslf. disponível em [2] Firyn Bartosz. Java webcam capture. disponível em [3] M. Baudel, T. e Beaudouin-Lafon. Charade. Communications of the ACM, 7:28 35, [4] Corporate Brasoftware. Brasoftware. disponível em [5] M. B. B. C. Correa. Probabilidade de Estatística. 2a Edição. Belo Horizonte: PUC Minas Virtual., [6] Inc GitHub. Github - insubstantial. disponível em [7] R. E. Gonzalez, R. C. e Woods. Processamento Digital de Imagens - 3ł ed. São Paulo: Pearson, [8] H. N. Marques, O. F. e Vieira. Processamento Digital de Imagens. Rio de Janeiro: Brasport, [9] Corporation Microsoft. Kinect for windows. disponível em [10] Technology NNL. Infonode docking windows. disponível em [11] V. Rusnak. Interaction methods for large high-resolution screens. disponível em

15 CodeAnalyzer: uma ferramenta para inspeção automática de código-fonte Israel Antonio Pinto Silva, Wendell Antildes Marcolino Sampaio, Alberto Costa Neto Departamento de Computação Universidade Federal de Sergipe São Cristóvão, Brasil {israelantonio90, Resumo Analisadores estáticos são ferramentas importantes para automatizar a inspeção de código fonte. Apesar disso, os principais analisadores estáticos para a linguagem Java deixam a desejar com relação a flexibilidade, tornando seu uso impraticável em alguns projetos. Além disso, cada um tem um foco diferente, o que leva os desenvolvedores a usar mais de um deles. Este artigo apresenta uma ferramenta nova que integra os principais analizadores para a linguagem Java e provê maior flexibilidade que as ferramentas mencionadas. Keywords-Static Analyzer; Source Code Inspection; Eclipse plug-in. I. INTRODUÇÃO Há algo que é inquestionável entre usuários e desenvolvedores de software: todo sistema deve ter alta qualidade. Para isso, é fundamental eliminar todos os erros, que são problemas que fazem o software parar de funcionar ou não funcionar conforme o esperado. A ocorrência de erros pode resultar em transtornos ao usuário, mas também em prejuízos financeiros e até processos judiciais. Na engenharia de software [1], [2], existem duas técnicas que são bastante utilizadas para eliminar erros: o teste e a revisão. A primeiro consiste em executar o software para verificar se ele funciona conforme o esperado. Já a revisão não envolve a execução do programa. Ela consiste em realizar a leitura de algum artefato de software (por exemplo, o código-fonte) com o objetivo de encontrar erros. Além de erros, outros aspectos podem ser analisados na revisão, como os estilos de programação, que são padrões de formatação para o código-fonte. Existem ferramentas de software que automatizam o processo de revisão. Essas ferramentas são conhecidas como analisadores estáticos automatizados. Atualmente, os três analisadores mais populares para a linguagem de programação Java são: Checkstyle [4], Findbugs [5] e PMD [6]. No entanto, ao tentar utilizar essas ferramentas no Centro de Processamento de Dados da Universidade Federal de Sergipe, algumas dificuldades foram encontradas. Dessa forma, este trabalho tem como objetivo apresentar uma nova ferramenta que integra os três analisadores citados e que soluciona essas dificuldades. Assim, a Seção II descreve brevemente os analisadores estáticos citados. A Seção III destaca as dificuldades encontradas ao utilizar essas ferramentas, enquanto na Seção IV é apresentada a ferramenta proposta que objetiva solucionar esses problemas. Na Seção V são apresentados alguns trabalhos relacionados e, finalmente, a Seção VI traz as conclusões e trabalhos futuros. II. ANALISADORES ESTÁTICOS Os analisadores estáticos automatizados são ferramentas de software que varrem o código-fonte de um programa em busca de erros ou de partes que não atendem aos estilos de programação. Eles podem ser usados para agilizar a técnica de revisão de software, já que podem encontrar milhares de erros em poucos minutos. No entanto, costumam ser frequentemente usados pelos desenvolvedores durante a codificação do programa, para evitar que os erros se propaguem para as próximas etapas do processo de software. Atualmente, três analisadores estáticos para a linguagem Java [3] se destacam: Checkstyle [4], Findbugs [5] e PMD [6]. O foco do Checkstyle é verificar estilos de programação, enquanto o Findbugs é voltado totalmente para a análise de erros. Já o PMD verifica tanto estilos de programação quanto erros, mas não é tão bom quanto os outros dois em cada aspecto. No entanto, ele pode verificar alguns erros e estilos que não podem ser verificados, respectivamente, pelo Findbugs e pelo Checkstyle. Todas essas três ferramentas foram inicialmente desenvolvidas para serem executadas em linha de comando. No entanto, o mais comum é utilizar seus plug-ins desenvolvidos para os Ambientes de Desenvolvimento Integrado (IDE), por causa da facilidade de utilização que esses ambientes oferecem. Os plug-ins dessas ferramentas para o ambiente Eclipse [7] têm uma estrutura semelhante, sendo formados por: uma tela de configuração, onde o usuário escolhe os estilos e os tipos de erros que devem ser procurados no código-fonte; uma tela de relatório, na qual são listados os problemas encontrados e suas respectivas localizações no código-fonte. III. LIMITAÇÕES DAS FERRAMENTAS EXISTENTES O que motivou o presente trabalho foram as dificuldades encontradas para utilizar as três ferramentas citadas na Seção II no Centro de Processamento de Dados da Universidade Federal de Sergipe. Primeiramente, cada ferramenta é focada em diferentes aspectos do código-fonte, o que leva os 5

16 desenvolvedores a utilizar mais de uma dessas ferramentas e, consequentemente, a gastar mais tempo para configurar e examinar o relatório de cada uma separadamente. Além disso, é necessário um cuidado especial na escolha das regras, porque algumas estão presentes em mais de uma ferramenta e isso poderia resultar em resultados duplicados. No entanto, foi num determinado projeto dessa Universidade que problemas mais graves foram encontrados. Esse projeto tem como objetivo implantar o Sistema Integrado de Gestão (SIG) [8], realizando as devidas adaptações para que as funcionalidades desse software atendam aos requisitos da Universidade. No entanto, partes do código-fonte desse sistema não devem ser alteradas, mesmo que venham a contribuir para a melhoria da qualidade do software, porque futuras atualizações feitas pelo fornecedor do SIG não trarão estas melhorias realizadas, demandando um trabalho de reintrodução das mesmas. Os desenvolvedores envolvidos neste projeto desistiram de utilizar os analisadores citados, já que o escopo de análise envolvia todo o sistema, quando o interessante seria restringir este escopo ao das modificações realizadas durante a customização do sistema, o que acabou tornando a utilização destas ferramentas pouco produtiva. IV. FERRAMENTA PROPOSTA CodeAnalyzer é um plug-in para o Eclipse que integra os analisadores estáticos Chescktyle, Findbugs e PMD, de forma a apresentar somente um relatório contendo todos os problemas encontrados por esses três analisadores. Essa ferramenta também é capaz de alertar o usuário sobre as semelhanças entre regras desses analisadores, para evitar que o relatório apresente resultados duplicados. Mais importante ainda, ela permite que o usuário oculte os erros que não podem ser consertados, para que em futuras análises da ferramenta, somente erros que podem ser corrigidos ou que foram introduzidos recentemente sejam exibidos. O CodeAnalyzer é, na verdade, a composição de seis plugins para o Eclipse. Suas funcionalidades foram modularizadas dessa maneira para facilitar a extensão e contribuição por outros desenvolvedores. No entanto, ao utilizá-lo no Eclipse, o usuário terá a impressão de utilizar uma única ferramenta. A arquitetura do CodeAnalyzer pode ser vista na figura 1. Essa imagem ilustra os seis componentes (plug-ins) que compõem a ferramenta e as relações de dependência entre eles. O CodeAnalyzerCore não apresenta uma interface com o usuário, mas é responsável por fornecer informações essenciais para os outros componentes, como a localização de arquivos, tipos de marcadores e tipos de filtros. O componente RuleConfiguration é responsável por integrar as telas de configuração dos analisadores estáticos utilizados. Dessa forma, ele apresenta uma interface (figura 2), na qual o usuário pode marcar quais regras de cada analisador ele deseja utilizar. Ao selecionar uma regra, é exibida sua descrição na parte inferior dessa tela. Nessa Figura 1. Arquitetura da ferramenta CodeAnalyzer descrição, são apresentados nomes de outras regras semelhantes a ela. Além disso, quando duas regras semelhantes estão selecionadas, elas são destacadas em vermelho, para atentar o usuário sobre isso. Figura 2. Tela do componente RuleConfiguration O componente CodeAnalyzer tem como função executar os três analisadores estáticos. Ele é responsável por configurar cada um dos analisadores de acordo com as regras escolhidas pelo usuário no plug-in RuleConfiguration. A única interface que o componente CodeAnalyzer implementa é o menu pop-up da ferramenta, que é acessado ao selecionar um projeto, pacote ou arquivo Java no Eclipse. O componente MarkerViewer possui uma tela onde são apresentados os problemas encontrados no código analisado. Essa tela exibe, de forma unificada, as informações resultantes das análises feitas por Checkstyle, Findbugs e PMD (figura 3). Além disso, é possível exibir nessa tela somente os problemas recentemente introduzidos, ou seja, os novos problemas encontrados em relação à última análise feita pela 6

17 ferramenta. Isso é feito ao selecionar o botão em forma de besouro"no canto superior direito da tela. O MarkerViewer também oferece ao usuário a possibilidade de ignorar um problema encontrado, como pode ser visto na figura 4. Ao fazer isso, o problema é removido da tela do MarkerViewer e impedido de ser mostrado nessa tela numa futura análise da ferramenta. A ferramenta permite que o problema seja ignorado por projeto, arquivo ou linha. Na opção por projeto, serão ignorados todos os problemas encontrados no projeto que possuírem a mesma regra do problema ignorado. Para arquivo e linha, a funcionalidade é semelhante, alterando apenas o escopo. Dessa forma, o desenvolvedor pode ignorar todos os problemas que não são de seu interesse e ter a garantia de que, nas próximas análises, eles não serão exibidos. Para desfazer a ação de ignorar um problema, o usuário deve acessar a interface do IgnoredMarkerViewer (figura 5). Nessa tela, são listados todos os problema ignorados e é possível desfazer a ação de ignorar. Ao fazer isso, o problema voltará a ser exibido na tela do MarkerViewer. Finalmente, o componente ResourceFilter permite que o usuário realize filtragens, ou seja, permite que sejam escolhidos quais os projetos, pacotes ou arquivos Java não devem ser analisados. Também é possível fornecer uma expressão regular válida em Java na filtragem, o que fará com que a ferramenta não analise os arquivos cujos nomes atendam a essa expressão. V. TRABALHOS RELACIONADOS Sonar [9] e Software Quality Environment [10] são ferramentas que utilizam Checkstyle, Findbugs e PMD para realizar a análise. No entanto, nenhuma delas soluciona as dificuldades encontradas ao utilizar esses analisadores na Universidade Federal de Sergipe. Sonar é uma aplicação web que integra Checkstyle, Findbugs, PMD e Cobertura [11]. Sua principal qualidade é a capacidade de armazenar o histórico de análises de um projeto. Isso permite que essa ferramenta exiba gráficos sobre o progresso dos problemas de um projeto, indicando ao usuário se o desenvolvimento está no caminho certo. Por ser uma aplicação web, para utilizá-lo são necessárias diversas configurações, o que dificulta sua utilização. Software Quality Environment é um plug-in para o ambiente de desenvolvimento Netbeans [12] que utiliza os três analisadores citados para verificar código-fonte Java. Ele apresenta apenas uma tela de configuração e uma tela de relatório para cada um dos analisadores, ou seja, não realiza de fato uma integração entre Checkstyle, Findbugs e PMD. ferramenta CodeAnalyzer, cujo objetivo é integrar os três analisadores citados e solucionar essas dificuldades. O CodeAnalyzer é um conjunto de seis plug-ins para o Eclipse. Ele utiliza os analisadores estáticos Checkstyle, Findbugs e PMD para realizar análises e oferece ainda: integração das telas de configuração e das telas de relatório dos três analisadores, destaque dos problemas recentemente introduzidos, possibilidade de ocultar erros e filtros. Como trabalhos futuros, pretende-se aprimorar a tela de configuração da ferramenta desenvolvida, de forma a permitir que o usuário configure as propriedades mais complexas das regras de análise. Além disso, tem-se o objetivo de aprimorar os relatórios, com a exibição de análises gráficas dos problemas encontrados nos projetos. REFERÊNCIAS [1] R. S. Pressman, Engenharia de Software, 6th ed. MCGRAW- Hill, [2] I. Sommerville, Engenharia de Software, 8th ed. Addison- Wesley, [3] Oracle, Java. Em [4] O. Burn, Checkstyle. Em [5] The University of Maryland, FindBugs. Em [6] D. Dixon-Peugh, PMD. Em [7] Eclipse, Eclipse. Em [8] S. Software e Consultoria, Sistema Integrado de Gestão. Em [9] Sonar, Sonar. Em [Online]. Available: [10] SQE, Software Quality Environment. Em [11] Cobertura, Cobertura. Em [12] NetBeans, NetBeans. Em VI. CONCLUSÃO E TRABALHOS FUTUROS Os analisadores estáticos apresentados têm sua utilidade para a melhoria do código de um software. No entanto, as dificuldades encontradas ao utilizá-los impedem suas adoções em alguns projetos. Por isso, foi desenvolvida a 7

18 Figura 3. Resultado da análise Figura 4. Menu de contexto do MarkerViewer Figura 5. Menu de contexto do IgnoredMarkerViewer 8

19 Uma Análise Comparativa de abordagens para lidar com a Evolução e Customização de Sistemas Fernanda Almeida Passos, Raphael Ferreira Santos Barreto, Kleber Tarcísio Oliveira Santos, Alberto Costa Neto Departamento de Computação Universidade Federal de Sergipe São Cristóvão, Brasil fernanda@ufs.br, rfsbarreto@gmail.com, klebertarcisio@yahoo.com.br, alberto@ufs.br Resumo Sistemas de software demandam customização de produtos para cada cliente, frequentemente envolvendo a criação de novos componentes e mudanças nos existentes. Como resultado, desenvolvedores normalmente enfrentam problemas de evolução e manutenção. Um dos maiores desafios é identificar as variações presentes na versão corrente e reaplicá-las nas versões mais novas do sistema. Isto pode demandar retrabalho se estas variações não forem separadas de forma apropriada do código base. Este artigo apresenta uma análise comparativa das abordagens existentes que suportam a implementação das variações e discute sua aplicabilidade. Keywords-Software Customization; Variability; Comparative Analysis. I. INTRODUÇÃO O processo de adaptação e manutenção em sistemas originais adquiridos é uma realidade frequente e ocorre em qualquer sistema customizado por organizações adquirentes ou em empresas fornecedoras de sistemas customizados para atender a clientes específicos. As atividades envolvidas neste processo não são triviais porque as variações nos requisitos para satisfazer os usuários finais são relativamente frequentes. E muitas vezes afetam vários pontos do sistema base, o que torna difícil o gerenciamento das variações de forma modular. Além disso, têm que lidar com as evoluções do sistema base realizadas pelos criadores que normalmente geram impacto sobre as variações desenvolvidas devido a estas serem realizadas diretamente sobre o código base do sistema original fornecido pelos criadores. Consequentemente, o processo de adaptação e manutenção precisa ser aprimorado, necessitando de abordagens que possibilitem: A criação de produtos customizáveis perante as necessidades específicas de cada organização; A modularização das implementações das variações no sistema sem que seja preciso modificar diretamente o código base do sistema original; Gerenciamento das variações realizadas pelas organizações adquirentes no sistema original através da modularização das mesmas; Agilidade no processo de sincronização de versões ao ser disponibilizada uma nova versão pelo fornecedor do sistema original; Diante deste cenário, a utilização de técnicas que lidam com variações em Linhas de Produtos de Software (LPS), através de seus princípios de variabilidade, podem ser capazes de proporcionar uma melhora significativa no processo de adaptação e manutenção em sistemas customizados, já que uma LPS é constituída por um conjunto de aplicações similares de um domínio, que podem ser desenvolvidas a partir de uma arquitetura genérica comum e um conjunto de componentes que povoam a arquitetura. Este artigo apresenta uma comparação das abordagens existentes para lidar com variações em LPS, focando na capacidade de aperfeiçoar o processo de adaptação e manutenção em sistemas originais adquiridos. Estas abordagens são classificadas na seção II e uma análise comparativa é apresentada na seção III. II. ABORDAGENS QUE LIDAM COM VARIAÇÃO A implementação de variabilidades em Linhas de Produtos de Software (LPS) permite construir assets customizáveis e extensíveis para a concepção de diferentes produtos de software derivados de uma LPS. Existem diferentes abordagens para a implementação das variantes em LPS, podendo ser classificadas nas seguintes categorias: anotativa, composicional, modelagem e transformacional. A. Abordagem Anotativa Na abordagem anotativa, os fragmentos de código de features (características) são anotados em uma base de código comum e pode ser usado não somente para configurar variantes estaticamente antes da compilação, mas também para habilitar ou desabilitar features em tempo de execução. As anotações também podem ser realizadas em outros artefatos como em modelos [1]. É utilizado nesta abordagem o préprocessador, um programa automaticamente executado antes do compilador para analisar o código fonte a ser compilado e, de acordo com as anotações adicionadas ao mesmo são executadas alterações antes de repassá-lo ao compilador. 9

20 B. Abordagem Composicional Na abordagem composicional, as features são implementadas separadamente em distintos módulos (arquivos, classes, pacotes, plug-ins e outros) e são gerados instâncias da linha de produto através da composição destes módulos. Para gerar variantes, estes módulos podem ser compostos em diferentes combinações. Os mecanismos de implementação utilizados são: componentes, mixin layers, classes virtuais, aspectos e outros [1]. C. Abordagem de Modelagem de LPS Na abordagem de modelagem de LPS é possível especificar as features que contemplam o escopo de toda a linha de produtos, as dependências, os relacionamentos e as restrições entre as mesmas. E ainda sistematizar o processo de derivação de produtos que envolvem a seleção, composição e customização dos artefatos de código que implementam uma LPS com o objetivo de atender a configuração de features. No entanto, algumas das técnicas realizam a especificação das features, correspondente ao domínio da linha de produto, e a configuração do produto, através de um subconjunto válido de features que satisfazem as restrições presentes no modelo de features especificado para obtenção de um produto específico da LPS, mas não suportam o efetivo processo de derivação de produtos. D. Abordagem Transformacional Na abordagem transformacional, os sistemas de transformação de programa fornecem mecanismos para a realização de modificações arbitrárias e não apenas a composição de módulos, como transformar a linguagem fonte de um programa num novo programa com linguagem diferente (por exemplo, na compilação) ou transformar um programa em um novo programa na mesma linguagem (por exemplo, na refatoração). Os mecanismos de implementação utilizados são: Linguagem Específica de Domínio (Domain Specific Language - DSL 1 ) e meta-programação para definir regras de transformações de programas [1]. III. ANÁLISE COMPARATIVA DAS TÉCNICAS DE LPS Os critérios escolhidos para análise comparativa das técnicas são: (i) Configuração do produto: especificação de um produto LPS a ser gerado pelo processo de derivação de produtos baseado na configuração de features; (ii) Fases do ciclo de vida da LPS: as fases do ciclo de vida do software suportada pela ferramenta no desenvolvimento de LPS; (iii) Abordagem de implementação de LPS: as abordagens adotadas na implementação das variabilidades em LPS; (iv) Seleção dos Componentes Concretos: assets de código concretos (classes, aspectos, arquivos e outros) mapeados as features selecionadas para geração do produto final; (v) 1 A Domain Specific Language (DSL) é uma linguagem textual ou gráfica que proporciona abstrações de primeira classe representando diretamente os conceitos de domínio da aplicação. Geração dos Componentes Flexíveis: adaptações, composições e transformações aos assets reusáveis para contemplar possíveis variações às features selecionadas para geração do produto final; (vi) Granularidade da Variabilidade: o nível de granularidade (grossa ou fina) suportada pela técnica para implementação dos assets reusáveis e de variações aos mesmos. Nível de granularidade grossa possibilita adicionar novas classes, aspectos, métodos e atributos ou estender pontos de variações explícitos. E o nível de granularidade fina permite introduzir trechos de código a métodos existentes, estender expressões ou assinaturas de métodos. As classificações e dados informados na Tabela I foram obtidos da análise de informações disponíveis em documentações e periódicos publicados sobre cada técnica. Na Tabela I, as seguintes abreviações são utilizadas: (i) Fases do Ciclo de Vida: C (Concepção), A (Análise), P (Projeto), I (Implementação) e TD (Todas); (ii) Abordagem de Desenvolvimento: M (Modelagem), A (Anotativa), C (Composicional) e T (Transformacional); e (iii) Granularidade da Variabilidade: G (Grossa) e F (Fina). Técnica Tabela I CLASSIFICANDO AS TÉCNICAS DE LPS. Config. do Produto Fases do Ciclo de Vida Abord. de Desenv. Sel. dos Comp. Concretos Ger. dos Comp. Flex. Granu. da Var. COVAMOF SIM A,P,I M SIM NÃO NÃO DOPLER SIM C,A,P,I M SIM NÃO NÂO FeatureMapper SIM P M NÃO NÃO NÃO FeaturePlugin SIM P M NÃO NÃO NÃO Gears SIM A,P,I M, C, A SIM SIM SIM (G) Holmes NÃO TD M SIM - - Kumbang SIM P M NÃO NÃO NÃO Ménage NÃO P M NÃO NÃO NÃO pure::variants SIM TD M, C, A SIM SIM SIM (G) S2T2 NÃO A, P M NÃO NÃO NÃO S.P.L.O.T. SIM A, P M NÃO NÃO NÃO Stratego/XT SIM I T NÃO SIM SIM(G,F) RequiLine SIM C,A,P M NÃO NÃO NÃO VarMod SIM A, P M NÃO NÃO NÃO V-Manage SIM C,A,P,I M, C SIM SIM SIM (G) FAMA-FW NÃO A, P M NÃO NÃO NÃO GenArch SIM P, I M, A, C SIM SIM SIM (G) PLUSEE SIM A, P M NÃO NÃO NÃO XToF SIM A,P,I M, A NÃO SIM SIM (G) CodeScoping NÃO P M SIM NÃO NÃO POA SIM I C NÃO SIM SIM(G,F) CONSUL SIM A,P,I M, C SIM SIM SIM (G) FeatureIDE SIM A,P,I M, C SIM SIM SIM (G) TXL SIM I T NÃO SIM SIM(G,F) DMS SIM I T NÃO SIM SIM(G,F) MetaJ SIM I T NÃO SIM SIM(G,F) Antenna SIM I A NÃO SIM SIM(G,F) CIDE SIM I A SIM SIM SIM(G,F) XVCL SIM I A NÃO SIM SIM(G,F) JPEL SIM I C NÃO SIM SIM (F) AHEAD SIM I C NÃO SIM SIM(G,F) FeatureHouse SIM I C NÃO SIM SIM(G,F) JaTS SIM I T NÃO SIM SIM(G,F) Segundo a avaliação feita e resumida na Tabela I, algumas técnicas adotam somente uma abordagem de modelagem de LPS para a especificação das features que compõem o es- 10

21 copo de todo o sistema modelando as partes comuns e variáveis entre os diversos produtos de software que formam uma LPS. Algumas destas técnicas, como FeatureMapper [2], FeaturePlugin [3], Ménage [4] e Kumbang [5], somente realizam a modelagem, isto é, define os relacionamentos e as dependências entre as features cobrindo somente a fase de projeto do ciclo de vida da LPS. E outras (por exemplo, COVAMOF [6], DOPLER 2, Holmes [7], CodeScoping [8]), conforme mostra a Tabela I, realizam também o processo efetivo de construção do produto baseado na seleção de componentes concretos através do mapeamento dos assets reusáveis às features selecionadas para compor o produto final. Porém, essa abordagem não permite realizar customizações aos assets que possibilitem a existência de diferentes especificações de código (variações) para uma mesma feature. As técnicas pure::variants, Gears [9], XToF [10], GenArch 3, CONSUL [11] também possuem uma abordagem de modelagem de LPS, mas possuem um recurso adicional que é a geração de componentes flexíveis para efetuar customizações aos assets com granularidade grossa através de transformações e da composição com novos assets para possíveis adaptações às features e a evolução da LPS devido a novos requisitos de domínio. E ainda devido aos mecanismos de implementação adotados para as customizações aos assets, essas técnicas são também categorizadas como anotativas, composicionais ou ambas. No entanto, essas técnicas de abordagens de modelagem de LPS necessitam das especificações das features que compõem o escopo do sistema para que seja possível gerar diferentes configurações de produtos através da seleção, transformação ou combinação dos assets associados às features selecionadas no processo de derivação do produto. Sendo assim, os mecanismos de implementação de variabilidade em LPS proposto por essa abordagem não se alinham com os objetivos deste trabalho, que refere-se à customização do código fonte de sistemas originais desenvolvidos por empresas fornecedoras de software e adquiridos por outras organizações sem a realização de refatorações no código original cobrindo somente a fase de implementação. Consequentemente, não contempla a especificação e a modelagem de features do domínio, as quais seriam necessárias para adoção de uma das técnicas de abordagem de modelagem de LPS (Seção II-C). As abordagens composicional, anotativa e transformacional permitem que sejam efetuadas as customizações necessárias, com granularidade que vai de grossa a fina, no código fonte do sistema para atender as variações existentes nas features e a novos requisitos necessários à evolução dos sistemas. Sendo assim, as técnicas que adotam uma dessas abordagens de implementação de variabilidade de LPS po dem ser candidatas a resolver o problema levantado neste trabalho referente ao processo de adaptação e manutenção em sistemas customizados por organizações adquirentes. No entanto, as técnicas de abordagem anotativa utilizam do mecanismo de anotação explícita com granularidade fina diretamente no código fonte podendo ser textual ou visual. As anotações textuais (como, Antenna 4 e XVCL 5 ), o código fonte é anotado por meio da utilização de diretivas de préprocessamento ou comandos específicos de cada técnica e as visuais (CIDE 6 ) o código é anotado por uma cor de fundo. Esta abordagem permite anotar diretamente trechos específicos do código, o que de certa forma inviabiliza a sua utilização neste trabalho, pois os problemas de manutenção e evolução do sistema continuariam devido à necessidade de reintroduzir as customizações efetuadas ao sistema original a cada nova versão disponibilizada Diferentemente das técnicas anotativas, as composicionais permitem a separação das variabilidades existentes das features do código base do sistema através de módulos distintos, promovendo assim a modularização dos interesses (funcionalidades). As técnicas AHEAD [12] e FeatureHouse 7 permitem granularidade grossa a fina por meio da adição de novos campos e métodos a classes do sistema, ou ainda adicionando comportamento extra no início ou final dos métodos existentes. A Programação Orienta a Aspectos (POA) [13] também provê granularidade grossa a fina através de aspectos e novas classes/interfaces para a modificação da estrutura estática de um sistema adicionando atributos, métodos e construtores a uma classe. Além de poder afetar a estrutura dinâmica de um programa mediante a interceptação de pontos no fluxo de execução do programa, chamados join points, definidos em pointcuts e de um conjunto de advice que podem executar comportamento antes e/ou depois de join points, e até substituir um comportamento existente no programa por outro. O JPEL 8 é limitado a implementar variações de valor, através de arquivos de parametrização para alterar os valores das variáveis locais, ou até mesmo o valor de algumas constantes usadas para calcular uma expressão no sistema apoiando assim a variabilidade de granularidade fina. Porém, com o JPEL não é concebível alterar a estrutura do software e as alterações no comportamento do programa estão limitadas ao valor gerado por cada mudança. E as abordagens somente transformacionais, como os sistemas de transformação de programa Stratego/XT 9, DMS [14] e TXL 10 (mencionados na Tabela I) são técnicas que fornecem mecanismos de codificação de nível mais baixo para a realização de modificações arbitrárias, normal

22 mente, incluindo a remoção ou reestruturação completa da sintaxe concreta da linguagem objeto. No entanto, devido a essa expressividade vem o aumento de complexidade de implementação e, portanto, não são frequentemente adotados na prática para implementar variações em LPS. A MetaJ 11 é uma técnica de transformação semelhante ao JaTs 12 sendo que a linguagem de templates é muito simples e para transformações mais complexas é necessário a definição de métodos, por outro lado as transformações descritas de forma declarativa, como em JaTS, são de certa forma mais simples de serem escritas, devido à linguagem de templates ser próxima da template da linguagem objeto. De acordo com [1], as abordagens transformacionais de certa forma realizam a composição de módulos através do casamento entre os templates (que contemplam a précondição e as variações a serem aplicadas) e o código base a ser transformado, podendo ser consideradas também composicionais. Deste modo, as técnicas de abordagem composicional mencionadas na Tabela I e o JaTS, devido às transformações poderem ser descritas de uma forma muito parecida com a linguagem objeto, são candidatos favoráveis à resolução dos problemas já descritos, pois estas técnicas propiciam a implementação de variações em diferentes níveis de granularidade e de forma modular sem que seja necessário alterar diretamente o código base do sistema original, refletindo-se em uma vantagem durante a evolução do sistema. IV. CONCLUSÕES Este artigo traz uma análise comparativa das abordagens existentes para lidar com variações em sistemas customizados. Foram analisadas várias abordagens que podem ser classificadas como: anotativas, composicionais, modelagem e transformacionais. O foco da análise é na adequação das abordagens para lidar com a evolução de sistemas que são customizados, portanto contendo variações, por organizações independentes da que os desenvolveu. Como trabalho futuro, será realizado um experimento com algumas das abordagens estudadas na implantação de novas versões de módulos do SIG, considerando as variações solicitadas pelos usuários. Espera-se obter como resultado a indicação de uma técnica ou a combinação de mais uma técnica para ser utilizada no processo de adaptação e manutenção em sistemas customizados por organizações ao adquirir sistemas originais desenvolvidos por outras empresas, tendo como principal benefício a implementação das variações de forma modular, facilitando a gestão das variações e tornando o processo de atualização da versão do sistema mais rápida e com menos falhas na reintrodução das variações a nova versão do sistema original REFERÊNCIAS [1] G. Saake, D. Batory, and K. Czarnecki, Virtual separation of concerns: toward preprocessors 2.0, Ph.D. dissertation, Ottovon-Guericke-Universität Magdeburg, Magdeburg, Germany, May [2] F. Heidenreich, J. Kopcsek, and C. Wende, Featuremapper: mapping features to models, in Proceedings of the 30th International Conference on Software Engineering (ICSE). Leipzig, Germany: ACM, 2008, pp [3] M. Antkiewicz and K. Czarnecki, Featureplugin: feature modeling plug-in for eclipse, in Proceedings of the 2004 OOPSLA workshop on eclipse technology exchange. Vancouver, British Columbia, Canada: ACM, 2004, pp [4] A. Garg, M. Critchlow, P. Chen, C. Van der Westhuizen, and A. Van der Hoek, An environment for managing evolving product line architectures, in Proceedings of the 19th International Conference on Software Maintenance (ICSM 2003). Amsterdam, The Netherlands: IEEE, 2003, pp [5] H. Koivu, A tool for modelling software product families user-centred prototype implementation, Master s thesis, Department of Computer Science and Engineering, Helsinki University of Technology, Espoo, Finland, February [6] M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch, Covamof: A framework for modeling variability in software product families, vol Boston, MA, USA: Springer Verlag, August 2004, pp [7] G. Succi, J. Yip, and W. Pedrycz, Holmes: an intelligent system to support software product line development, in Proceedings of the 23rd International Conference on Software Engineering. Toronto, Ontario, Canada: IEEE Computer Society, May 2001, pp [8] T. F. L. Medeiros, E. S. Almeida, and S. R. Lemos Meira, Codescoping: A source code based tool to software product lines scoping, in 38th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA 12). Cesme, Izmir: IEEE, 2012, pp [9] C. W. Krueger, Software mass customization, White paper, BigLever Software Inc., May [10] C. Gauthier, A. Classen, Q. Boucher, P. Heymans, M.-A. Storey, and M. Mendonça, Xtof: A tool for tag-based product line implementation, vol. 10. Linz, Austria: University of Duisburg-Essen, 2010, pp [11] D. Beuche, H. Papajewski, and W. Schröder-Preikschat, Variability management with feature models, Science of Computer Programming, vol. 53, no. 3, pp , December [12] D. Batory, Feature-oriented programming and the ahead tool suite, in Proceedings of the 26th International Conference on Software Engineering (ICSE 04). Scotland, UK: IEEE Computer Society, 2004, pp

23 [13] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. V. Lopes, J.-M. Loingtier, and J. Irwin, Aspect-Oriented Programming, in Proceedings of the 11th European Conference on Object-Oriented Programming (ECOOP 97). Finland: Springer-Verlag, [14] I. D. Baxter, C. Pidgeon, and M. Mehlich, Dms R : Program transformations for practical scalable software evolution, in Proceedings of the 26th International Conference on Software Engineering (ICSE 04). Scotland, UK: IEEE Computer Society, 2004, pp

24 Mecanismos de Proteção de Ativos Intelectuais de Tecnologia da Informação existentes no Brasil Pedro Silva Neto Programa de Pós-Graduação em Ciência da Propriedade Intelectual (PPGPI) Universidade Federal de Sergipe - UFS São Cristóvão, Sergipe, Brasil pedro@pyxistec.com.br Abstract O presente trabalho tem como objetivo apresentar uma pesquisa documental/bibliográfica abordando os mecanismos existentes no território brasileiro para proteção intelectual de ativos produzidos na área de Tecnologia da Informação. Buscou-se apresentar principalmente as modalidades de proteção ao software, com suas implicações práticas e legais, além também de outras matérias de proteção relacionadas ao segmento de Tecnologia da Informação. Keywords: propriedade intelectual; patente; registro de software; software público; software livre; direito autoral; propriedade industrial. I. INTRODUÇÃO A Propriedade Intelectual sempre teve seu papel de importância nos meios acadêmico e empresarial nos países desenvolvidos tecnologicamente. Porém, no Brasil, um problema vem sendo detectado no segmento de Tecnologia da Informação - TI que abrange tanto as produções científicas provenientes do setor acadêmico assim como as tecnologias oriundas do mercado. Este problema remete à grande resistência que a maioria dos profissionais, estudantes e empresas brasileiros de TI, produtores de software e outras matérias, possuem quanto à oficialização dos registros de seus ativos intelectuais. Nessa discussão, é importante lembrar-se da pequena representatividade tecnológica que o Brasil possui mundialmente frente à sua produção acadêmico-científica. O Brasil recebe concessões de apenas 0,1% dos produtos no mundo enquanto está na 13 posição no ranking de produção de artigos, representando 2,7% da produção acadêmico-científica mundial [1]. Como questão norteadora deste trabalho, pretende-se apresentar os conceitos necessários que permitam ao leitor conhecer a legislação brasileira para oficializar a Propriedade Intelectual de seus ativos, materializando-a em produção tecnológica oficial brasileira, mesmo se distribuída publicamente/livremente. Esse trabalho está organizado da seguinte forma: na seção II é abordado o conceito de Propriedade Intelectual, na seção III, o Registro de Programa de Computador, na seção IV, o Software Livre, na V, o Software Público Brasileiro, na VI, a Patente com Software Embarcado, na VII, outras matérias de proteção em TI, seguidas pelas conclusões e referências bibliográficas. Maria Augusta Silveira Netto Nunes Programa de Pós-Graduação em Ciência da Computação (PROCC) / Programa de Pós-Graduação em Ciência da Propriedade Intelectual (PPGPI) Universidade Federal de Sergipe - UFS São Cristóvão, Sergipe, Brasil gutanunes@gmail.com II. PROPRIEDADE INTELECTUAL A Propriedade Intelectual - PI se mostra ainda um conceito novo para muitas pessoas no Brasil. O reflexo disso se dá nos números apresentados na introdução deste trabalho. A PI, no cenário mercadológico, é um dos fatores mais importantes de competitividade. Aliada do processo de Inovação Tecnológica, ela se torna peça-chave para garantia dos direitos de exclusividade que a empresa terá sobre seus produtos. Segundo o World Intellectual Property Organization - WIPO, a PI refere-se a criações da mente como: invenções, obras literárias e artísticas, símbolos, nomes, imagens, desenhos e modelos utilizados no mercado. A PI está dividida em duas categorias: (1) Propriedade Industrial, que inclui invenções (patentes), marcas, desenhos industriais e indicações geográficas de origem; e (2) Direitos Autorais, que inclui obras literárias e artísticas, tais como romances, poemas e peças de teatro, filmes, obras musicais, trabalhos artísticos, como desenhos, pinturas, fotografias e esculturas e projetos arquitetônicos e a principal matéria abordada neste trabalho: o Programa de Computador [2]. III. REGISTRO DE PROGRAMA DE COMPUTADOR O Registro de Software, ou Registro de Programa de Computador, é uma das formas disponíveis no nosso país para conceder a autoria e, conseqüentemente, garantir a exclusividade na produção, uso e comercialização de um software [3]. Este registro está estabelecido no regime jurídico do Direito Autoral, protegendo assim o ativo intelectual do desenvolvedor. Oficialmente, no Brasil, o Registro de Programa de Computador é competência do Instituto Nacional de Propriedade Industrial - INPI [4]. As normas/leis para oficializar o Registro de Programa de Computador no INPI foram atribuídas pelo Decreto 2.556/98, de 20 de abril de 1998; pela Lei nº 9.609/98, de 19 de fevereiro de 1998, conhecida como Lei do Software; e pela Lei nº 9.610/98, de 19 de fevereiro de 1998, a Lei de Direito de Autor. [3]. A Lei do Direito do Autor -LEI Nº 9.610, de 19 de fevereiro de 1998 [5] altera, atualiza e consolida a legislação sobre direitos autorais e aborda questões relacionadas. Um programa de computador é protegido como obra literária, isto é, o objeto de proteção é o seu código fonte. Isto significa que ao registrar um programa de computador, o código implementado é que está sendo protegido. Já as 14

25 funcionalidades e finalidades do mesmo, por suas naturezas intangíveis, não podem ser matérias de proteção no Brasil. Quanto à territorialidade, diferentemente do que acontece com Marcas e Patentes, o direito conferido ao titular do Registro de Programa de Computador é reconhecido internacionalmente pelos países que assinaram o Agreement on Trade-Related Aspects of Intellectual Property Rights TRIPS [6], desde que seja cumprida a legislação nacional. Esse reconhecimento é também bilateral, ou seja, programas nacionais registrados no INPI estão protegidos em outros países assim como programas estrangeiros têm o mesmo tratamento aqui no Brasil. O pedido de registro realizado junto ao INPI é composto por [4]: Documentação Formal: relativa à auditoria e à titularidade do programa e; Documentação Técnica: que constitui a documentação do programa em si. Os passos para realização do depósito do pedido são [4]: a) Geração e pagamento da Guia de Recolhimento da União GRU; b) Preparação da Documentação Formal; c) Preparação da Documentação Técnica; d) Apresentação do pedido junto ao INPI; e) Acompanhamento do processo. De posse da documentação (formal e técnica) o depositante poderá efetuar o depósito do pedido de registro na sede do INPI (conforme endereço fornecido no site) ou em escritório do órgão em seu estado (conforme lista de endereços das representações fornecida no site). Ou ainda o depósito pode ser realizado por via postal, com aviso de recebimento - AR. Por fim, como acontece em todos os trâmites de pedidos no INPI, o depositante pode acompanhar o processo através da Revista Eletrônica de Propriedade Industrial - RPI, disponível no site do órgão. IV. SOFTWARE LIVRE LICENÇA GNU/GPL O Software Livre figura como uma corrente que se ampara em um idealismo pragmático [7] e tem um teor filosófico ao abordar questões como valores e objetivos pautados em ajuda mútua e principalmente na liberdade. E essa liberdade é evidenciada para os usuários em lugar dos ganhos monetários [8]. Uma das justificativas defendidas pelos seguidores do Software Livre, onde um programa de computador não pode ser proprietário, é de que o mesmo é imaterial, se difere de objetos tangíveis, pode ser copiado e modificado mais facilmente por se tratar de uma informação digital, garantindo-lhe uma utilidade ímpar [8]. Porém, devemos salientar que o Software Livre também é passível de Registro, pois é considerado Programa de Computador convencional e, dessa forma, aqui no Brasil, é protegido pela lei do Direito Autoral. Para que um programa de computador possa ser considerado Software Livre, a Free Foundation Software - FSF coloca que os usuários desta modalidade precisam possuir quatro liberdades essenciais [8]: A liberdade de executar o programa, para qualquer propósito (liberdade 0); A liberdade de estudar como o programa funciona, e adaptá-lo às suas necessidades (liberdade 1). Para tanto, acesso ao código-fonte é um pré-requisito; A liberdade de redistribuir cópias de modo que você possa ajudar ao próximo (liberdade 2) e; A liberdade de distribuir cópias de suas versões modificadas a outros (liberdade 3). Desta forma, você pode dar a toda comunidade a chance de beneficiar de suas mudanças. Para tanto, acesso ao código-fonte é um pré-requisito. No sentido de garantir essa proposta de liberdade, a comunidade do Software Livre utiliza comumente a licença pública geral do GNU - GNU GPL [7], utilizando um método chamado Copyleft, que exige que as derivações do programa também sejam Software Livre. O Copyleft é um termo genérico que vai de encontro ao conceito do Copyright propositalmente e garante a liberdade dos usuários, ou seja, assumem as quatro liberdades que norteiam este conceito. Para criar um Software Livre, basta tornar seu código fonte disponível para toda a comunidade, deixando-o sobre domínio público. Deve-se acrescentar nos cabeçalhos dos arquivos dos códigos fonte as diretivas de licenciamento escolhida, a exemplo da GNU/GPL. Quanto ao registro do mesmo, como já falamos, ele pode ser feito sim, pois o fato de estar registrado, não impede seu(s) autor(es) e titular(es) de torná-lo livre, apesar de ser algo não tão bem aceito pela comunidade deste segmento. Por outro lado, o registro é uma garantia legal, neste caso, dos Direitos Morais estabelecidos através do Direito Autoral, e legalmente, em nosso território, o software é enquadrado neste cenário. V. SOFTWARE PÚBLICO BRASILEIRO O Software Público Brasileiro - SPB [9] é definido pela instrução normativa Nº 01, de 17 de janeiro de 2011, através da Secretaria de Logística e Tecnologia da Informação do Ministério do Planejamento e Gestão - SLTI/MP. Conforme descrito no Portal do Software Público Brasileiro, disponível na Internet [10], o SPB adota um modelo de licença livre para o código-fonte aliado à proteção da identidade original entre o seu nome, marca, código-fonte, documentação e outros artefatos relacionados. Isto é garantido por meio do modelo de Licença Pública de Marca LPM [9]. A LPM é a formalização de um instrumento que libera o programa de computador e elementos correlacionados nas diretrizes do Software Livre e garante os direitos de autoria na forma do Registro. Para disponibilização do SPB no portal, alguns requisitos técnicos e jurídicos precisam estar contemplados. Entre os mais importantes estão: Versão do software com instalação e uso estáveis; Manual; Código fonte; Scripts e bibliotecas requeridas; 15

26 Especificação no cabeçalho dos arquivos-fonte da Licença Pública Geral - GPL; Uso da LPM; Registro do software no INPI; Existência de responsáveis (coordenadores) do projeto. As figuras 1 e 2 mostram respectivamente os fluxos de oferta e solicitação do SPB, interagindo com o Sistema de Administração dos Recursos de Informação e Informática da Administração Pública Federal - SISP [10]: Figura 1. Fluxograma de oferta do SPB [10]. Figura 2. Fluxograma de solicitação do SPB [10]. O Portal do Software Público Brasileiro na internet funciona como o canal de comunicação por onde qualquer pessoa, física ou jurídica, pode ofertar ou obter um SPB. Para ofertar, ou seja, colocar um programa como um SPB, antes de tudo, é aconselhável, para não dizer imprescindível, que o ofertante tenha conhecimento sobre a Instrução Normativa 01/2011 e também sobre o Manual do Ofertante, ambos disponíveis no site para download. Neste documento estão especificados todos os detalhes necessários à oferta do software. Até aqui foram mostrados três mecanismos exclusivos de proteção ao Software. É notado que o SPB tenta unir o melhor dos dois restantes: Registro e Software Livre, permitindo de certa forma uma garantia legal aos fornecedores e usuários de software. VI. PATENTE COM SOFTWARE EMBARCADO Segundo a Webopedia [11], um sistema embarcado ou embutido pode ser definido como um sistema computacional especializado que faz parte de uma máquina ou sistema maior. Geralmente um sistema embarcado está vinculado a Hardware microprocessado. O Hardware, assim como o Software, são partes componentes de um sistema computacional. Por sua característica tangível e de reprodução industrial, o mesmo constitui uma matéria patenteável. Entretanto, como não existe a Patente de Software no Brasil, assunto este cercado de polêmicas, somente o Registro de Programa de Computador é o mecanismo existente para fins de proteção do mesmo. Porém, quando temos um dispositivo de hardware como um conjunto que abrange o software, este passa a ser protegido como Propriedade Industrial, e constitui um sistema computacional que possui uma aplicação específica. É importante salientar que a Patente quando envolve o Software Embarcado não é literalmente uma Patente de Software, o que na prática não protege seguramente a propriedade intelectual sobre o software de maneira isolada. O processo de depósito de Patente envolvendo Software Embarcado segue praticamente o mesmo trâmite de qualquer processo de patente junto ao INPI. Para mais detalhes, o órgão disponibiliza o Guia de Tramitação de Patentes [12] em seu site. VII. OUTRAS MATÉRIAS DE PROTEÇÃO Com o aparecimento de novos ativos intelectuais, tem-se ampliado as modalidades de proteção no sentido de contemplar estas novas matérias. O INPI, em seu Guia de Depósito de Patentes [13] elenca algumas modalidades sob a denominação de Proteções Sui generis. Estes novos mecanismos compreendem figuras jurídicas intermediárias entre a Propriedade Industrial e o Direito Autoral. Uma destas proteções Sui Generis, ligada ao segmento de eletrônica, e porque não dizer também ao de Tecnologia da Informação, é a Topografia de Circuitos Integrados. A. Topografia de Circuitos Integrados A Lei de 2007 [14], em seu art. 26, define que a Topografia de Circuitos Integrados é uma série de imagens 16

27 relacionadas que representa a configuração tridimensional das camadas que compõem um circuito integrado. O processo de depósito do pedido de registro para a Topografia de Circuitos Integrados é muito semelhante ao que vimos no Registro de Programa de Computador e Patentes. É necessário preparar uma documentação e dar entrada no escritório central do INPI no Rio de Janeiro ou em um escritório estadual do órgão. Os documentos necessários são [14]: Descrição da Topografia do Circuito Integrado e de sua função; Desenhos/fotos da Topografia do Circuito Integrado; Circuito integrado relativo à topografia requerida; Declaração de exploração anterior, se existir; Documento comprobatório de titularidade ou documento de cessão; Autorização do titular de topografia original protegida, caso necessária; Tradução pública juramentada de documentos em língua estrangeira; GRU com pagamento autenticado. Procuração, caso necessária. B. Proriedade Intelectual na Internet Não é concebível que a Internet seja tratada como um território sem lei. Freqüentemente tomamos conhecimento de casos de pessoas que têm suas vidas expostas e não conseguem, mesmo que por meios legais, se livrarem deste problema. Com os direitos que envolvem a Propriedade Intelectual não é diferente. Informações digitais podem ser copiadas inúmeras vezes, sem restrições. E aqui temos uma dicotomia, pois o que ao mesmo tempo constitui um dos pilares do Software Livre, enaltecendo uma vantagem, por outro lado acarreta prejuízos morais e patrimoniais aos autores e titulares de criações intelectuais reproduzidas sem as devidas autorizações. O que pode e deve ser protegido quando resolvemos publicar conteúdos na Internet? Para termos uma resposta, antes devemos considerar que tudo que está presente na internet, teve sua origem no mundo real e conseqüentemente deve ser protegido em ambiente virtual. Tomemos como exemplo um site de conteúdo multimídia com vídeos, músicas, entre outros elementos. Nele poderemos encontrar diversas matérias passíveis de proteção. Comecemos pelo nome domínio na web, que apesar de não se formalizar como um ativo de propriedade intelectual, o mesmo está diretamente relacionado à marca, assumindo muitas vezes o papel dela. No âmbito da Propriedade Industrial, poderemos encontrar a Marca em suas diversas variações: mista, nominativa e figurativa. Porém, o maior número de matérias certamente será evidenciado no segmento do Direito Autoral: vídeos, músicas, fotografias, textos, imagens e software, inclusive o próprio site, que segundo a Fundação Biblioteca Nacional FBN [16], a mesma diz que embora ainda não haja um consenso e uma legislação específica quanto à sua proteção, o site lógico (software) está protegido pela Lei n. º 9.609/98, neste caso prevalece o Registro de Programa de Computador como mecanismo legal de proteção. VIII. CONCLUSÕES A proposta deste trabalho foi fornecer ao estudante e/ou profissional de Tecnologia da Informação um elenco de mecanismos existentes no Brasil sobre Propriedade Intelectual, em especial as matérias relacionadas ao software. O que deve ser levado em consideração é que a consciência sobre a importância de se proteger intelectualmente os ativos tecnológicos nacionais se faz mais do que necessária para o nosso país, preservando e contrabalançando a produção acadêmico-cientifica nacional aos números de produção tecnológica. REFERÊNCIAS [1] NUNES, M. A. S. N. ; CAZELLA, S. C. ; PIRES, E. A. ; RUSSO, S. L.. Discussões Sobre Produção Acadêmico-Científica & Produção Tecnológica: Mudando Paradigmas. GEINTEC - Gestão, Inovação e Tecnologias, v. 3, p , [2] WIPO, What s intellectual property?, Diponível em < [3] RUSSO, S. L. ; SILVA, G. F. ; OLIVEIRA, L. B. ; SANTOS, M. M. A. ; NUNES, M. A. S. N. ; VASCONCELOS, J. S.. Propriedade Intelectual. In: Russo, S.L.;Silva, G.F.; Nunes, M.A.S.N... Capacitação em inovação tecnológica para empresários - Edição 2. 2ed.s: Editora UFS, 2012, v., p [4] INPI, Registro de Software. INSTRUÇÃO NORMATIVA Nº 11/2013, Normas do INPI. Disponível em < toria_final_15_3_2013_c.pdf> [5] LDA, Lei do Direito do Autor -LEI Nº 9.610, DE 19 DE FEVEREIRO DE Disponível em < > [6] TRIPS, Acordo TRIPS, Disponível em < [7] STALLMAN, Richard, Copyleft: Um Idealismo Pragmático, Disponível em < [8] FSF, Free Software Fundation. Licença CreativeCommons GNU GPL Disponível em < [9] SPB, Software Público Brasileiro. Instruções Normativas Nº 01, DE 17 DE JANEIRO DE Disponível em < f>. [10] SPB, Software Público Brasileiro: Perspectiva Sistêmica. Centro de Tecnologia da Informação Renato Archer Disponível em < istemica>. [11] WEBOPEDIA, Embedded System, Disponível em < [12] INPI, Guia de Tramitação de Patentes, Disponível em < _de_tramitacao.pdf>. [13] INPI, Guia de Depósito de Patentes, Disponível em < de_deposito_de_patentes.pdf>. [14] INPI, Topografia de Circuitos Integrados Guia Básico, Disponível em < uitos_integrados>. [15] FNB, Fundação Biblioteca Nacional, Dúvidas Frequentes, Disponível em < 17

28 14Factory Facilitando a disponibilização de novos serviços na nuvem Tássio Augusto da C. Guimarães; Vinícius Castro SWX Softwares Aracaju-SE, Brasil tassio@swx.com.br; vinicius@swx.com.br Jonas Santos Bezerra; Tarcísio da Rocha Universidade Federal de Sergipe Departamento de Computação São Cristóvão-SE, Brasil jonassantosbezerra@gmail.com; tarcisio@dcomp.ufs.br Resumo A computação em nuvem visa possibilitar a utilização dos mais diversos serviços por meio da internet de forma ubíqua, transparente e sob demanda. Atualmente há diversos tipos de serviços da nuvem disponibilizados por vários provedores como Google, Amazon e Microsoft. O objetivo deste trabalho é a criação de uma ferramenta denominada 14Factory, módulo do Projeto 14BIS, que fornece uma API de requisições HTTP para abstrair o processo de criação de instâncias de aplicações na nuvem, possibilitando a seleção do provedor de nuvem a ser utilizado. Palavras-chave: Computação em Nuvem, Automação, Serviços. I. INTRODUÇÃO Atualmente, grande parte do sucesso de um negócio está relacionada à habilidade de adaptar-se rapidamente a ambientes econômicos que sofrem modificações constantes; políticas governamentais, novos competidores, novas tecnologias, ampliação ou retração do público consumidor são apenas alguns exemplos de fenômenos que podem afetar significativamente, um determinado negócio. Desse modo, tem-se procurado nos últimos anos por novos meios e tecnologias que favoreçam essa adaptabilidade, como os estudos nas áreas de Linha de Produtos de Software, Serviços de Business Process Management e Computação em Nuvem. Dentre estas, a Computação em Nuvem tem-se destacado por possuir um modelo econômico e de negócio que pode ser aplicado a pequenas empresas ou a negócios em fase inicial com relativa simplicidade e a baixo custo. A grande vantagem da Computação em Nuvem reside na sua capacidade de fornecer como um serviço praticamente qualquer recurso computacional infraestruturas de computação, softwares, plataformas para seus usuários, a qualquer momento e independente de onde ele se encontra ou de qual a plataforma computacional ele utiliza para acessar esses serviços, além de o acesso a estes ser de tal modo facilitado que o usuário final pode possuir a impressão de que os serviços estão instalados no seu dispositivo[1]. Grandes empresas como Amazon, Google, Microsoft, IBM e outras tem investido em soluções computacionais em nuvem, disponibilizando hoje uma vasta gama de serviços. No entanto, por ser uma área de estudo relativamente nova, a Computação em Nuvem carece de uma padronização de APIs, dada a já citada variedade de uso que esta possui, fazendo-se então necessário fornecer meios para que seus usuários possam vincular os serviços que utilizam com maior facilidade, sem que seja preciso nenhum tipo de programação a baixo nível nos serviços para que eles sejam customizados, sobretudo em relação aos usuários finais [2]. O 14Factory é parte do Projeto 14BIS, iniciativa da SWX Softwares, que visa a criação de um novo tipo de loja de aplicativos baseados na nuvem, a 14Store, permitindo assim que empresas fornecedoras de software possam vender seus produtos sem que seja necessário montar ou manter a infraestrutura subjacente da maneira tradicional, dadas as vantagens de se utilizar a nuvem, diminuindo assim os custos e tempo de produção, e ainda assim possam lidar com uma quantidade maior de clientes. Os clientes, por sua vez, poderão encontrar de forma simples e rápida bem como mais barata e segura produtos que atendam suas necessidades e possam utilizá-los poucos instantes depois da aquisição. O 14Factory é o módulo do 14BIS que trata da automação da criação e gerência de instâncias de Softwares como Serviços na nuvem a serem disponibilizados pelas organizações que desejarem utilizar os serviços do 14BIS e da Nuvem. II. COMPUTAÇÃO EM NUVEM De acordo com a definição do National Institute of Standards and Technology, a Computação em Nuvem é um modelo para permitir o acesso ubíquo e sob demanda a um conjunto compartilhado de recursos de computação que possam ser rapidamente provisionados e liberados com o mínimo de esforço de gerenciamento ou interação com o provedor de serviços [3]. A nuvem é uma metáfora para a internet, e está relacionada a dois conceitos essenciais desse modelo de computação, a abstração a Computação em Nuvem abstrai os detalhes de implementação do sistema, ocultando-os dos usuários, empresas e até mesmo dos desenvolvedores e a virtualização a Computação em Nuvem virtualiza sistemas inteiros ao gerenciar e compartilhar recursos [4]. Segundo [1], a Computação em Nuvem tem por objetivo permitir a utilização das mais variadas aplicações via internet, em qualquer lugar e independente da plataforma (dispositivos e/ou sistemas operacionais) com tal facilidade que os usuários tenham a impressão de que essas mesmas aplicações estão instaladas localmente em seus computadores e dispositivos pessoais. Assim, a Computação em Nuvem trata das aplicações, infraestruturas e hardware que são disponibilizadas como 18

29 serviços na internet [5]. No contexto da Computação em Nuvem, serviços são componentes reutilizáveis e multi-alocáveis que podem ser fornecidos pela nuvem, havendo hoje uma ampla variedade destes. A Computação em Nuvem possui cinco características básicas que a diferenciam da Computação com a qual estamos acostumados, a saber [3]. 1. Serviço sob demanda O usuário adquire os recursos de que necessita de forma transparente, somente no momento em que necessita deles e sem que seja necessária nenhuma forma de interação direta com o provedor da nuvem no sentido de fazer requisições destes recursos. 2. Amplo acesso à rede: O acesso aos recursos da nuvem é disponibilizado através da rede, utilizando as tecnologias, padronizações e protocolos já existentes da internet, de forma a permitir que o acesso seja independente da plataforma de hardware ou software que o cliente utilize para acessar os recursos. 3. Pooling de Recursos: O provedor da nuvem deve distribuir e organizar seus recursos de maneira que seja possível atender as necessidades de múltiplos usuários, com alocação de sistemas físicos ou virtuais feita de forma dinâmica, e ainda encapsulando do usuário informações relativas à localização real dos recursos. 4. Elasticidade Rápida: O provedor deve assegurar a elasticidade dos recursos que fornece tanto alocando mais recursos quando houver demanda quanto liberando-os quando seu uso não se fizer mais necessário. Além disso, é obrigatório que, do ponto de vista do cliente, os recursos sejam aparentemente infinitos e disponíveis a qualquer momento. 5. Serviço Medido: O uso dos recursos da nuvem deve ser medido e apresentado ao consumidor com base em um sistema métrico pré-definido como a quantidade de ciclos do processador ou o uso da banda de rede. Os custos que serão cobrados devem ser então baseados nessas medidas. Tudo na nuvem é disponibilizado no formato de serviços: componentes reutilizáveis e multi-alocáveis que podem ser fornecidos pela nuvem. Há 3 tipos de básicos de serviços: 1. Infraestrutura como Serviço (IaaS): Disponibilização máquinas virtuais, armazenamento virtual, infraestrutura e hardware em geral, nos quais o cliente tem total liberdade de uso. Enquanto o provedor de IaaS gerencia a infraestrutura física, o cliente torna-se responsável pelo gerenciamento dos sistemas e implantação/manutenção dos aplicativos. 2 Plataforma como Serviço (PaaS): Fornecimento de recursos para a construção e implantação de aplicativos e serviços, esses recursos podem incluir Sistemas Operacionais executando em máquinas virtuais, frameworks e ferramentas de programação para linguagens de programação específicas, sistemas de gerenciamento de banco de dados, dentre outros. Nesse caso, o cliente utiliza os serviços fornecidos para a criação e instalação, mas toda a carga de gerenciamento e manutenção das ferramentas fica a cargo do provedor dos serviços. 3. Software como Serviço (Software as a Service SaaS): Disponibilização de aplicativos ou conjuntos de aplicativos finais que o usuário acessa através de alguma interface de cliente magro, a responsabilidade do usuário se dá apenas ao utilizar os dados por meio da interação com o aplicativo, todo o resto é de responsabilidade do provedor do serviço. Por ser ainda recente, a Computação em Nuvem carece de padronização de APIs que facilitem a comunicação entre os diversos serviços que a nuvem oferece, sobretudo, para serviços de provedores diferentes. Segundo o Open Cloud Manifesto [7], essa carência demonstra-se, sobretudo, em questões de interoperabilidade, portabilidade, integração, gerenciamento, métricas e segurança na nuvem. III. FERRAMENTAS DE AUTOMATIZAÇÃO DE SERVIÇOS As características da Computação em Nuvem, explicadas na seção anterior, mudam drasticamente a maneira de gerenciar o ambiente e os recursos de infraestrutura e das aplicações que são utilizadas, sobretudo por conta da migração de responsabilidades. Assim, foram criadas algumas ferramentas para facilitar a automação da criação e gerência de serviços na nuvem. A. BitNami Cloud O BitNami é um projeto open source criado para facilitar a aquisição de aplicações web de alta qualidade, open source e disponíveis gratuitamente. O projeto tem por objetivo permitir que qualquer pessoa ou organização possa encontrar facilmente aplicações do tipo Sistemas de Gerenciamento de Conteúdo (CMS), wikis, plataformas para blogs e afins, oferecendo a possibilidade de instalá-las e utilizá-las sem que tenham de se preocupar com detalhes de implementação ou implantação [9]. O BitNami Cloud tem seu foco no usuário final e em permitir que este possa encontrar e utilizar facilmente aplicações open source que foram previamente disponibilizadas B. Puppet O puppet é uma ferramenta open source construída em ruby para configurar sistemas operacionais, tendo como uma de suas aplicações mais comuns a gerência de IaaS na nuvem. Segundo a comunidade do Puppet [10], o mesmo foi feito por administradores de sistema para administradores de sistema, contribuindo para a centralização das configurações de diversos servidores na nuvem em único ponto e assim facilitar a gerência e configuração, a automação da instalação de pacotes e implantação de normas de auditoria. C. Chef O Chef é um framework open source mantido pela Opscode que fornece uma API e um conjunto de ferramentas para auxiliar administradores de sistemas e desenvolvedores a construir e gerenciar infraestruturas de larga escala. O chef é baseado no pressuposto de que a infraestrutura pode ser representada como código e, portanto, pode se tornar testável, versionável e replicável [6][8]. IV. O 14FACTORY O principal problema das ferramentas de automação de serviços da nuvem existentes atualmente tem seu foco voltado, geralmente, para apenas um dos tipos de serviços 19

30 que podem ser fornecidos pela nuvem, dando pouca atenção ou até mesmo negligenciado os demais. Dessa forma, nota-se a necessidade de uma forma de integrar melhor a automatização das três camadas de serviço da nuvem, facilitando de uma só vez a criação de novos softwares por parte dos desenvolvedores, a manutenção e gerência da infraestrutura na qual esses softwares são implantados e a disponibilização desses softwares para os usuários finais, agilizando assim o processo de desenvolvimento e oferta de novos serviços e ampliando o potencial da computação em nuvem. O 14Factory trata da automação da criação e gerência de instâncias de Softwares como Serviços na nuvem por meio de matrizes de aplicação, que servem de base para a criação de aplicações específicas, disponibilizadas por organizações que desejarem utilizar os serviços do 14BIS e da Nuvem. Uma matriz de aplicação funciona de maneira semelhante a uma classe na orientação a objetos no sentindo em que agrupa os recursos necessários para instanciar aplicações de um determinado tipo. Tais recursos incluem a descrição de hardware (memória, processador, disco), sistema operacional, plataformas de software (banco de dados, frameworks, servidor web, bibliotecas) necessárias à execução da aplicação, bem como o próprio código-fonte da aplicação que se deseja instanciar. A ideia do 14BIS é que o fornecedor cadastre na 14Store o software que desenvolveu, selecionando os recursos necessários para que a sua aplicação seja executada, disponibilizando o código-fonte. A 14Store é então responsável por requisitar a criação da matriz ao 14Factory, repassando aquilo que foi cadastrado pelo fornecedor. O 14Factory deve lançar um nó de teste para que o fornecedor do software verifique a instanciação e o funcionamento da aplicação através da matriz que foi especificada. A partir disso, o fornecedor poderá aprovar a matriz caso a aplicação funcione como desejado, ou alterar suas especificações em caso contrário. Uma vez aprovada a matriz, o aplicativo é disponibilizado no catálogo de produtos da 14Store, onde os clientes poderão comprá-lo. No ato da compra, o 14Store requisita ao 14Factory a criação de uma nova instância daquela aplicação e repassa para o cliente a forma de acesso (url, login, senha inicial). O 14Factory foi implementado como uma ferramenta web desenvolvida em ruby on rails e que utiliza o framework Chef. Tendo em vista ser uma ferramenta independente do provedor de nuvem, ele possibilita que se configure qual será o provedor utilizado. O 14Factory disponibiliza uma API própria, de modo que ele possa suas funcionalidades sejam utilizadas por meio de requisições HTTP. Recursos da API direcionados para as empresas fornecedoras de software podem ser vistos na Tabela I. Num fluxo padrão de utilização, o fornecedor consulta os recursos disponíveis em termos de hardware, software e sistema operacional, e seleciona quais deles serão necessários para criar a plataforma sobre a qual sua aplicação irá executar, submetendo-os numa requisição de criação da matriz de aplicação, informando também o nome da aplicação e o endereço do repositório do código-fonte. As possíveis operações sobre as matrizes de aplicação podem ser vista na Tabela II. Em um segundo momento, o cliente poderá visualizar todas as aplicações que foram cadastradas e realizar outras operações, utilizando a API que se encontra na Tabela III. TABLE I. Recurso RECURSOS DE INFRAESTRUTURA Descrição GET /api/softwares Retorna a lista de softwares disponíveis GET /api/hardwares Retorna a lista de hardwares disponíveis GET /api/operational_systems TABLE II. Recurso POST /api/applications GET /api/applications/:id DELETE /api/applications/:id TABLE III. Recurso GET /api/applications POST /api/instances GET /api/instances/:id GET /api/instances/:id/node DELETE /api/instances/:id Retorna a lista de sistemas operacionais disponíveis MANTER MATRIZES DE APLICAÇÃO Descrição Cria a matriz de aplicação. Deve-se especificar o nome da aplicação e o endereço do repositório onde o código-fonte se encontra. Além disso, deve-se especificar os recursos de hardware, software e sistema operacional que serão utilizados pela aplicação. Retorna os atributos da matriz de aplicação que possui o id igual ao especificado pelo parâmetro ID. Destrói a matriz de aplicação especificado pelo parâmetro ID. MANTER INSTÂNCIAS Descrição Retorna a lista de aplicações cadastradas. Cria uma instância da aplicação especificada como parâmetro da requisição. Retorna os atributos da instância que possui o id igual ao especificado pelo parâmetro ID. Retorna o status (pending, creating, created, error), o IP público e o node_id (referencia ao nó no provedor de nuvem) do nó associado à instância que possui o id igual ao especificado pelo parâmetro ID. Destrói a instância que possui o id igual ao especificado pelo parâmetro ID, juntamente com o nó ao qual está associado. V. CONCLUSÃO O 14Factory é uma ferramenta capaz de realizar a instanciação automática de aplicações em nuvem e facilitar o 20

31 processo de disponibilização das matrizes dessas aplicações por parte dos fornecedores de software. A ferramenta faz parte do projeto 14BIS, que visa a redução de custos e facilidade de aquisição de softwares corporativos, e recebeu o nome de 14Factory por ser o módulo que trata da automação do processo de instanciação de Softwares como Serviço. O trabalho foi desenvolvido como pesquisa de TCC em uma parceria da SWX, idealizadora do projeto 14BIS, com o Departamento de Computação da Universidade Federal de Sergipe. O 14Factory foi implementado e testado com sucesso para a arquitetura da Amazon Web Services e as aplicações criadas pela SWX, notadamente o EletroCommerce, mostrando ser capaz de agrupar os recursos de um provedor da nuvem, facilitar a oferta de novas aplicações por fornecedores de software e de abstrair e automatizar o processo de criação de novas instâncias dessas aplicações no momento da solicitação por um cliente. REFERÊNCIAS [1] A. T. Velte; T. J. Velte; R. Elsenpeter. Computação em Nuvem: Uma abordagem prática. Alta Books Editora, [2] J. Hurwitz; R. Bloor; M. Kaufman; F. Halper. Cloud Computing for Dummies. Wiley Publishing, Inc, [3] Mell, Peter; Grance, Timothy. "The NIST Definition for Cloud Computing. In Recommmendations of the National Institute of Standards and Technology. Information Technology Laboratory, September [4] B. Sosinsky. Cloud Computing Bible. Wiley Publishing Inc, [5] M. Armbrust; A. Fox; R. Griffith; A. D. Joseph; R. Katz; A. Konwinski; G. Lee; D. Petterson; A. Rabkin; I. Stoica; M. Zaharia. A View of Cloud Computing. In Communications of the ACM. Vol. 53, nº 4. Abril de [6] S. Nelson-Smith. Test-Driven Infrastructure With Chef: Bring Behavior-Driven Development To Infrastructure As Code. 1st ed. O'Reilly, [7] Open Cloud Manifesto. Open Cloud Manifesto: dedicated to teh belief that the cloud should be open. Disponível em < Acesso em: Abril de [8] Opscode. Chef. Disponível em < Acesso em Janeiro de [9] BitNami Wiki. Disponível em < Acesso em: Fevereiro de 2013 [10] Puppet Brasil. Puppet é uma ferramenta de gerenciamento open source para centralização e automação de configuração. Disponível em < Acesso em: Fevereiro de

32 Desenvolvimento de Banco de Dados para Cadastro e Comparação de Moléculas de Plantas do Semiárido Brasileiro SAM Database Tiago Nery de Oliveira 1, Géssica Alves Teixeira Melo 2, Alex Ferreira dos Santos 3, Ellison Barros Oliveira 4, Maicon Vinícius Araújo Silva 5, Wagner Rodrigues de Assis Soares 6, Bruno Silva Andrade Departamento de Química e Exatas (DQE) 6 Departamento de Saúde (DS) 7 Departamento de Ciências Biológicas (DCB) Universidade Estadual do Sudoeste da Bahia (UESB) Jequié, Brasil. Contato: 7 bandrade@uesb.edu.br Os métodos computacionais (in silico) têm sido largamente aplicados para o desenvolvimento e orientação de uma diversidade de ensaios biológicos (in vivo e in vitro), bem como para a construção de hipóteses farmacológicas acerca do mecanismo de ação de determinado fármacos. Estes métodos in silico incluem, dentre outros, a construção e gerenciamentos de banco de dados, a quantificação da relação estrutura-atividade (QSAR) e pesquisa de similaridade de moléculas (triagem virtual). A utilização de bancos de dados de moléculas tem se tornado uma grande ferramenta para os pesquisadores que trabalham no desenvolvimento de fármacos, pois eles disponibilizam acesso a informações sobre os mais variados tipos de estruturas químicas, o que se torna fundamental na bioprospecção (High Throuput Screening) de moléculas com potencial farmacológico. O intuito deste trabalho foi desenvolver um banco de dados (SAM Database) no qual permitisse o armazenamento de informações (compostos químicos) e comparação de moléculas obtidas de plantas do semiárido brasileiro, sendo um bioma com grande diversidade de espécies vegetais ainda pouco estudadas, as quais podem conter compostos inovadores com potencial para o desenvolvimento de medicamentos utilizados na terapêutica em seres humanos. Palavras-chave: Banco de dados; Bioinformática; Triagem Virtual; Moléculas; Semi-árido brasileiro. I. INTRODUÇÃO Várias plantas do semiárido brasileiro vêm sendo estudadas nos últimos anos, na tentativa de encontrar novos alvos terapêuticos para uma diversidade de patologias. No entanto, apesar de vários esforços pouco ainda se sabe quanto ao respectivo mecanismo de ação dos seus princípios ativos, ou seja, pouco se conhece onde os compostos naturais atuam no organismo e de que forma eles ocasionam seus terapêuticos efeitos colaterais, adversos e tóxicos. A Bioinformática e a química computacional (ou quimioinformática) estão entre as áreas de maior crescimento dentro dos processos de descoberta de medicamentos[1]. Essas ferramentas são utilizadas para triagem de moléculas in silico e tornaram-se componentes cruciais para a descoberta de muitas drogas. A seleção das melhores moléculas candidata a interagir com seus respectivos alvos proteicos (receptores farmacológicos), ocorre de acordo com um padrão de pontuações (Hits) que obedecem a uma série de características para um encaixe perfeito do ligantereceptor[2]. A disponibilização de bancos de dados gratuitos, na internet, como o ZINC [3] e o SEA (Keiser et al. 2007) facilitam a comparação entre estruturas recém descobertas em bancada com outras semelhantes que já possuem alguma atividade [4]. A criação de um banco de dados específico para o cadastro e comparação de estruturas de moléculas isoladas de plantas do semiárido brasileiro é uma forma de organizar esses compostos em grupos, de acordo com o seu provável uso medicinal e seus alvos moleculares, facilitando o desenvolvimento de novos fármacos para o tratamento de diversos tipos de doenças. Além disso, esse é o primeiro banco de dados destinado especificamente ao uso de moléculas isoladas de plantas brasileiras obtidas da biodiversidade de um de seus biomas. II. METODOLOGIA A iniciativa partiu de uma proposta interdisciplinar na qual a participação de docentes e discentes dos cursos de Sistemas de informação, Biologia e Farmácia, da Universidade Estadual do Sudoeste da Bahia (UESB) foram cruciais. A equipe agregou os conhecimentos, na idealização e construção de um software para armazenamento e comparação de moléculas isoladas de plantas do semiárido brasileiro, servindo de ferramenta para pesquisas e seleção de compostos químicos candidatos, no tratamento de patologias humanas. A primeira versão do software contém o cadastro e cálculo de semelhança das moléculas. Na segunda versão do software pretende-se utilizar algumas bases de dados de moléculas disponibilizados na internet, como o Chembl [8] e o Pubchen [9], dois dos mais conhecidos banco de dados de moléculas do mundo. Desta forma, o usuário não somente poderá comparar suas moléculas com a base de dados do software, como também com outras bases de dados existentes, outro objetivo e tornar o software acessível através da internet, para ser acessado por qualquer usuário que tenha interesse consultar o banco de dados para suas pesquisas. Para o desenvolvimento deste software, foi escolhida a linguagem de programação Java em seu padrão EE (EnterpriseEdition). Á tecnologia Java é utilizada para 22

33 aplicações corporativas que podem estar na Internet ou não [5]. Algumas funcionalidades, como criação da imagem da estrutura das moléculas, calculo da similaridade entre moléculas e geração do arquivo mol, são proveniente da biblioteca Open Source indigo desenvolvida pela empresa GGA Softwares Services [6]. Os dados gerados são armazenados em um banco de dados relacional, utilizando-se como Sistema Gerenciador de Banco de Dados (SGBD) o MYSQL Server [7]. Figure 1. Formulário de Cadastro de Moléculas III. RESULTADOS E DISCUSSÕES O software foi desenvolvido com intuito de proporcionar aos pesquisadores o armazenamento das informações das moléculas do semiárido brasileiro, podendo assim consultalas para fins acadêmicos e científicos, além de proporcionar a capacidade de comparações de moléculas na qual o pesquisador pode inserir sua molécula recém-descoberta ou em estudo e comparar com as existentes no banco de dados permitindo que encontre a similaridade entre elas. Desta forma, a estratégia é descobrir possíveis finalidades para o uso desta molécula com base nas suas similares que já possuem atividade. A Figura 1 ilustra o formulário de cadastro de moléculas. Este formulário permite ao usuário inserir os dados básicos da molécula como nome, a planta da qual foi isolada, seu composto, publicações relacionadas entre outras informações. O software permite através da inserção do canonical smile gerar uma imagem da estrutura da molécula e um arquivo mol que podem ser consultados na Figura 2. Figure 2. Tela de Consulta das Moléculas Cadastradas As Figuras 3 e 4 ilustram as comparações entre as moléculas, onde o usuário pode selecionar o tipo de pesquisa, pelo nome, no caso de comparar alguma molécula cadastrada com as demais, ou pelo canonical smile de uma molécula que não está cadastrada, para verificar se existe alguma similar a ela no banco de dados, o resultado deve ser 0,0 se as moléculas não são de todo semelhante e 1,0 se elas são completamente compatíveis. Uma tarefa comum na bioinformática é encontrar estruturas alvo num conjunto de dados, que são semelhantes à estrutura de consulta e para realizar este tipo de tarefa existem conjuntos de ferramentas ou bibliotecas Open Source que utilizam diferentes tipos de métodos para esta tarefa, para realização deste trabalho optamos em escolher a biblioteca indigo desenvolvida pela empresa GGA Softwares Services [6] que foi citada na metodologia, com a qual conseguimos obter os resultados descritos, o método utilizado por esta biblioteca é o coeficiente de similaridade de Roger Tanimoto o qual permite calcular o grau de similaridade entre duas moléculas. Figure 3. Tela de comparação de moléculas. 23

34 descoberta e desenvolvimento de novos compostos com poder terapêutico. Sendo assim a ferramenta SAM Database que pode vir a ser de grande auxilio aos pesquisadores que desejam direcionar suas pesquisas em compostos químicos encontrados no semiárido brasileiro, criando uma network para transmissão de conhecimento dentro da química medicinal e farmacologia de produtos naturais. AGRADECIMENTOS Expressamos nossa gratidão a Universidade Estadual do Sudoeste da Bahia (UESB) a qual tem nos oferecido todo suporte para realização da seguinte pesquisa, fornecendo todas as ferramentas necessários para o desenvolvimento do projeto, assim como também aos professores dos Departamentos de Química e Exatas, Ciências Biológicas, Saúde e em especial ao Centro de Pesquisa e Desenvolvimento de Software (CPDS), pertencente ao curso de Sistemas de Informação, onde o projeto surgiu e está sendo desenvolvido. REFERÊNCIAS Figure 4. Resultado da comparação IV.CONCLUSÃO O crescimento dos bancos de dados informacionais tais como: ZINC [3] e SEA (Keiser et al. 2007) tem impulsionado o desenvolvimento de ferramentas computacionais,com aplicabilidade no direcionamento de ensaios biológicos in vivo e in vitro (novas moléculas isoladas e caracterizadas), desta forma a integração destas áreas leva a uma maior agilidade da busca por compostos com potencial farmacológico. A metodologia empregada destaca-se como um mecanismo de triagem virtual em larga escala, na qual é possível visualizar de forma mais rápida novas oportunidades no que se refere à prospecção in silico de moléculas com ação terapêutica. Percebe-se, que o avanço na incidência e prevalência de doenças, não caminha na mesma velocidade da descoberta e desenvolvimento de novos medicamentos. Apesar da vasta biodiversidade dos biomas brasileiros, a quantidade de estudos para alguns compostos promissores ainda é escassa, portanto a bioinformática pode tornar mais eficiente, o processo de [1] K. H. Bleicher, H. J. Bohm, et al.. "Hit and lead generation: beyond high-throughput screening." Nat Rev Drug Discov 2(5): , [2] D. B. Kitchen, H. Decornez, et al.. "Docking and scoring in virtual screening for drug discovery: methods and applications." Nat Rev Drug Discov 3(11): , [3] J. J. Irwin and B. K. Shoichet. "ZINC--a free database of commercially available compounds for virtual screening." J Chem Inf Model 45(1): , [4] M. J. Keiser et al. "Relating protein pharmacology by ligand chemistry." Nat Biotechnol 25(2): , [5] Pamplona VF. Tutorial Java: O que é Java? [internet]. JavaFree; 2009 Out 10 [acesso em 2013 Set 26]. Disponível em: Java.html. [6] GGA Softwares Services. Indigo Tolkit [internet] 2013 [acesso em 2013 Set 26]. Disponível em: [7] Oracle Corporation. MySQL 5.5 Reference Manual [internet]. c [acesso em 2013 Set 26]. Disponível em: mysql.com/doc/relnotes/ mysql/5.5/en/index.html [8] EMBL-EBI. ChEMBL [internet] [acesso em 2013 out 2013].Disponivel em : [9] PubChem. PubChem Compound [internet] [acesso em 2013 out 2013].Disponivel em: 24

35 Análise de desempenho da paralelização do cálculo da matriz de correlação com tamanho arbitrário, utilizando GPU Chaina Santos Oliveira Departamento de Computação Universidade Federal de Sergipe São Cristóvão, Brasil Íris Andrade dos Santos Departamento de Computação Universidade Federal de Sergipe São Cristóvão, Brasil Carlos Alberto Estombelo- Montesco Departamento de Computação Universidade Federal de Sergipe São Cristóvão, Brasil Resumo- O cálculo da matriz de correlação é utilizado para encontrar a associação entre variáveis. Esta operação pode ser executada mais rapidamente se feita em GPUs, ao invés de executada em CPUs. Diante deste cenário, o presente artigo apresenta a descrição e os resultados do estudo feito acerca do potencial de paralelismo de placas gráficas, GPUs, e da arquitetura CUDA. De forma a mostrar, ainda, a análise do desempenho, em tempos de execução (em uma GPU) do algoritmo paralelizado, em relação ao algoritmo sequencial (em uma CPU) da matriz de correlação. Palavras-chave- GPU; CUDA; Matriz de Correlação; CPU I. INTRODUÇÃO Na atualidade o mundo científico encontra-se em um momento em que as CPUs (Central Processing Unit) já não conseguem lidar com o crescimento exponencial de dados a nível mundial. Além disso, cada vez mais, as quantidades destes dados tendem a aumentar, em consequência pesquisadores estão sempre a procurar novas formas de processamento, isto é, meios que nos permitam tratar grande volume de dados em áreas como Inteligência Artificial, Física e outras [4]. Por exemplo, se considerarmos as aplicações que precisam lidar com tais aumentos na quantidade de dados, seja por exemplo, na modelagem de redes bayesianas [8] ou em aplicações utilizando o método PCA (Principal Component Analysis), que por sua vez é utilizado em processamento de imagens e de forma geral na análise de dados multivariados [Araujo 2009]. Para todos esses casos existe um tipo de operação em comum, o cálculo de matriz de correlação. Essa matriz de correlação é uma matriz simétrica que é utilizada quando há a necessidade de obter o grau de associação das variáveis [Vicini 2005], como é o caso do cálculo da transformada de Karhunen-Loève (KLT) que diagonaliza sua matriz de correlação [9]. Outros trabalhos relacionados temos, aqueles que propõem o cálculo da referenciada matriz de forma mais rápida [2], [3]. Para abordar o problema do processamento multivariado mostrado acima, uma alternativa é a utilização de computação paralela em placas GPUs (Graphics Processing Unit) [4]. A ideia principal é que existirão várias operações processadas paralelamente distribuídas nas dezenas de núcleos das GPUs ao contrário dos quatro ou oito núcleos que uma CPU possui em média. Assim, a GPU processa mais dados em várias linhas de processamento ao mesmo tempo, melhorando o desempenho de um determinado processo, o que pela CPU seria possível, porém com a limitação de ter apenas oito núcleos, levando assim um tempo maior para chegar ao mesmo resultado. Dessa forma, esse trabalho tem por objetivo mostrar qual o valor desse incremento no desempenho da GPU em relação à CPU quando se realiza uma transformação matemática com múltiplas variáveis. Para alcançar esse objetivo é implementado o cálculo da Matriz de Correlação em uma arquitetura paralela que será descrita nesse trabalho. Essa implementação paralela, juntamente com outra implementação sequencial permitirá comparar os períodos de tempo necessários para a execução de cada função envolta no cálculo, bem como analisar a diferença entre o somatório dos tempos de processamento dessas funções. II. GPU (Graphics Processing Unit) CUDA (Compute Unified Device Architecture) é uma plataforma de computação paralela e um modelo de programação inventado pela NVidia [6]. Ela permite aumentos significativos de performance computacional ao aproveitar a potência da unidade de processamento gráfico (GPU). Para entendermos melhor o funcionamento da programação em GPU é preciso primeiro entender algumas terminologias utilizadas. Para tudo aquilo que se refere a recursos da CPU dá-se o nome de host, analogamente, para tudo que se refere a recursos da GPU damos o nome de device. Além disso, as funções são chamadas na GPU de kernels, podendo ser global ou device. Um kernel global é executado na GPU e deve ser chamado na CPU. Assim como o kernel global, o kernel device é executada na GPU, porém deve ser chamada dentro de um kernel global. É necessário também entender a definição de threads, blocos e grids. A principio nas threads fica todo o potencial de paralelismo, cada operação 25

36 paralelizada é feita em uma thread diferente, o bloco é uma organização de threads que tem uma memória compartilhada entre todas as threads do mesmo e o grid é uma organização de vários blocos [7]. A forma de acesso baseado na memória compartilhada, juntamente com a técnica de redução [7], serão de grande utilidade para resolver o problema de dependência, por exemplo, na soma de todos os elementos de um vetor, utilizado posteriormente para calcular a média. A técnica de redução [7] consiste em fazer somas independentes. No caso de um vetor de n elementos, são realizadas somas entre elementos distintos, com. Desta forma, todas as operações serão feitas em paralelo. Para fazer a próxima rodada de somas paralelas é necessário que todas as threads possam ver os resultados obtidos, nesse ponto é importante observar que é ai onde entra a memória compartilhada, estes resultados, assim como o vetor inicial são guardados nesta para que todas as threads do mesmo bloco possam visualizar os resultados. Rodadas da redução são executadas até que o resultado seja apenas um elemento. Com os fundamentos anteriormente descritos abordaremos na próxima seção a descrição do método matemático, a matriz de correlação, utilizado como objeto de estudo para a geração de dados e posterior análise dos mesmos. III. MATRIZ DE CORRELAÇÃO Análise de Componentes Principais ou PCA é um método estatístico multivariado que tem como uma de suas finalidades a de promover uma redução dimensional, eliminando a parte redundante da informação [5]. Como esta operação é bastante utilizado no meio científico e em diversas técnicas como mencionadas na introdução, resolvemos implementar inicialmente uma parte do mesmo, nesse caso o cálculo da matriz de correlação, para a comparação CPU vs. GPU. Baseando-se no artigo de Marques, [5], são necessários os seguintes passos para encontrarmos a matriz de correlação: Padronização das Variáveis, cálculo da matriz diferença e cálculo da matriz de correlação. No primeiro passo para padronizar as variáveis é preciso aplicar sobre cada elemento da matriz de entrada a fórmula 3.1. (3.1) Depois, no segundo passo (o cálculo da matriz diferença) aplicamos a fórmula 3.2: (3.2) Para finalizar, com a matriz resultante do passo 2,, é feito o seguinte processo: Retira-se linha por linha da matriz diferença, separando-as em diferentes matrizes onde os elementos das linhas serão dispostos na vertical formando matrizes. Se seleciona cada uma dessas matrizes, e multiplica-as por sua transposta, formando assim matrizes. Por último, somam-se essas matrizes e divide todos os elementos por formando uma só matriz resultante, a matriz de correlação. Onde em todos os passos é o elemento da linha e da coluna, é a média dos elementos da coluna, é o desvio padrão dos elementos da coluna e é o número de linhas e o número de colunas. Observando que a matriz somente é considerada de correlação se os dados de entrada foram antes padronizados, se não fossem, a mesma seria denominada matriz de covariância [1]. Depois de mostrar o embasamento matemático da operação a considerar no presente trabalho, passamos a descrever no tópico 4 como foi codificada a matriz de correlação em CUDA. IV. IMPLEMENTAÇÃO DA MATRIZ DE CORRELAÇÃO EM CUDA Percebendo-se que os passos necessários para o cálculo da matriz de correlação são paralelizáveis e levando em consideração que a quantidade de dados de entrada almejada é uma matriz tridimensional, por exemplo, de, seria plausível utilizar o potencial computacional da GPU para implementar os mesmos (passos), buscando menor tempo de execução em comparação à CPU. Para isso, utilizaram-se funções em CUDA, de forma que todas as matrizes mencionadas no PCA fossem tratadas como vetores, como é mostrado na Figura 4.1 a), que exibe uma matriz e suas posições, e a Figura 4.1 b) que mostra a matriz, e seus elementos decompostos em um vetor. Figura 4.1 a) Exemplo da matriz e suas posições; b) Elementos da matriz a decompostos em um vetor A ordem de chamada às funções implementadas em CUDA para se chegar à matriz de correlação, foi feitas sequencialmente, uma em relação à outra. Enquanto, em cada kernel (função) foram utilizadas técnicas de computação paralela ou alternadamente computação paralela e sequencial. Isso acontece para que seja possível tirar, de cada kernel, o maior proveito possível do desempenho computacional disponível. Isto porque nem sempre é possível paralelizar totalmente um 26

37 cálculo (é o caso do cálculo da soma), ou mesmo sendo possível a placa possui um limite de blocos ou threads que impõe, ao programador, dividir o processamento de um determinado código em várias etapas. No próximo tópico são mostrados os resultados encontrados nos testes da implementação descritos aqui. V. RESULTADOS OBTIDOS Para fazer os testes e comparações, utilizou-se, além do código em CUDA, a codificação sequencial da matriz de correlação para a execução na CPU. Para gerar os resultados da GPU e CPU, bem como para a comparação dos dados as seguintes ferramentas foram usadas: o processador I tel Core QM 2.20GHz, o ambiente de programação Visual Studio 2010: Ultimate, o sistema operacional Windows 7 Home Premium x64, com memória RAM de 6GB e uma GPU GTX 525M, com clock rate de 1200 Mhz, com dimensão máxima de blocos de 1024x1024x64 e de grids de 65535x65535x65535 e CUDA Drive Version 5.0. Utilizou-se uma matriz de entrada de ordem 1024 x 256 (1024 linhas e 256 colunas), resultando em elementos float, números reais na programação CUDA e na linguagem C, que equivalem a 1Mb de dados. Onde, este foi o limite alcançado ate o momento da elaboração desse trabalho que foi utilizado na GPU com as características acima mostradas. Foi executado o código em C com os mesmos dados de entrada e o tempo de execução geral, em média, considerando todas as funções na CPU foi de 7689 milissegundos, enquanto na GPU foi de milissegundos. Isso é possível em virtude da capacidade de paralelismo da placa gráfica. Pode-se observar esta diferença na Fig. 5.1, que mostra o cálculo da matriz de correlação em C e em CUDA ms 5000 ms Cálculo da Matriz de Correlação 0 ms C CUDA Cálculo da Matriz de Correlação Figura 5.1 Tempos de execução da matriz de correlação na CPU e GPU com dados. Para obter estes e outros resultados, foram feitos testes com uma base de dados que consiste de características de manuscritos de numerais de 0 a 9, extraídas de uma coleção de mapas de utilidades holandeses [10]. Os resultados dos outros testes podem ser observados na Fig. 5.2, a imagem mostra a comparação feita considerando o número de linhas indo de 2 a 1024 e de colunas de 2 a 256, lembrando que o limite encontrado para a execução deste código na presente placa foi de 1024 linhas por 256 colunas. Nota-se, analisando os resultados, que o processamento de matrizes de tamanhos 2x2 até 128x4 tiveram tempos de execução semelhantes às de 128x8, tanto em C, como em CUDA, tempos estes que não passavam da terceira casa decimal depois do zero. Entretanto, no momento em que o número de linhas aumenta para valores iguais ou acima de 128 e ao mesmo tempo assumisse quantidades maiores que 32 para o número de colunas, é observado que a diferença entre os tempos de execução da CPU pelo da GPU começa a aumentar de forma exponencial. Com o aumento do tamanho da matriz é esperado que o comportamento do tempo da execução da GPU também cresça, mas diferente da CPU, possivelmente o aumento de tempo de execução seja mais lento o que levaria a um bom ganho de desempenho. Isto aconteceria porque apesar de o clock da CPU ser maior, a GPU pode realizar centenas de operações simultâneas enquanto a CPU fez uma ou duas operações [6]. Apesar de neste gráfico não ficar explicito, uma das preocupações detectadas na utilização da GPU é o gargalo que é formado na transição de dados da memória da CPU para a memória da GPU ou o inverso, pois mesmo tendo um bom fluxo de dados na GPU os dados devem antes passar pelo barramento da CPU. Isto acontece porque nas GPUs mais recentes o barramento é maior que o barramento na placa mãe, com isso quando é preciso transferir dados entre GPU e CPU há um afunilamento do fluxo de dados no barramento da CPU. Com tais resultados e análises feitas, é possível então pensar no estudo sobre um contexto geral e em novos objetivos para o mesmo. As novas metas e as conclusões retiradas desse estudo se encontram descritas no tópico abaixo. VI. CONCLUSÃO E TRABALHOS FUTUROS Este artigo mostra uma análise de desempenho gerado pela utilização da arquitetura CUDA para a paralelização do cálculo da matriz de correlação. Desta análise, podemos concluir que para problemas em que não há uma forte dependência entre as operações necessárias, podemos utilizar a GPU como uma ferramenta para aumentar o desempenho gerado pelo paralelismo que ela oferece. Uma das principais qualidades de se programar em CUDA é a facilidade que a linguagem oferece, já que para programar não é necessário um vasto conhecimento da arquitetura, transformando em algo mais acessível uma ferramenta que há pouco tempo 27

38 atrás era exigida muita especialização para fazer até tarefas de renderização. Os próximos passos almejados para este trabalho são: Conseguir manipular matrizes com tamanhos reais de imagens de ressonância magnética, ou seja, aprimorar o algoritmo para que a placa GPU em questão consiga processar matrizes de float com elementos (4Mb) quadruplicando o limite tido até o momento de (1Mb). Adicionar mais funcionalidades ao código, para que além da matriz de correlação tenhamos também todas as outras etapas que compõem o PCA, como o cálculo dos autovetores e autovalores [1]. Desenvolver uma API (Application Programming Interface) ou Interface de Programação de Aplicativos, com funcionalidades suficientes para que programadores possam paralelizar mais facilmente os seus códigos e possivelmente tenham um ganho de desempenho. Finalmente, espera-se que com os resultados obtidos até aqui e com os esperados para as próximas etapas seja possível fazer processamento de imagens e/ou sinais com o PCA utilizando as funções disponibilizadas pela API, que servem para tornar mais acessível a outros programadores os passos do PCA, e todo o potencial de processamento disponível na GPU. REFERÊNCIAS [1] Araujo, W. O, Análise de Componentes Principais (PCA), Centro Universitário de Anápolis, [2] Kijsipongse E.; U-Ruekolan S.; Ngamphiw C.; Tongsima S, Efficient Large Pearson Correlation Matrix Computing using Hybr d MPI/CUDA, National Electronics and Computer Technology Center Pathumthani, National Center for Genetic Engineering and Biotechnology Pathumthani. Thailand, [3] Logoglu K. B.; Ates T. K. Pe rso İl t K ts yısı Hes pl sı ı Gr f k İsle c B r ler Üzer de Hızl dırıl sı Speed g-up Pearson Correlation Coefficient Calculation on Graphical Processing Units, Orta Dogu Teknik Üniversitesi, [4] Manami, A. Soluções aproximadas para algoritmos escaláveis de mineração de dados em domínios de dados complexos usando GPGPU, dissertação (Mestrado em Ciências de Computação e Matemática Computacional) Universidade de São Paulo. São Carlos, [5] Marques, G, Análise em Componentes Principais: Process e to Est tíst co de S s, [6] NVidia CUDA, CUDA: Progr ção p r lel s fác l, disponível em: Acesso em 24 de fev. de [7] Sanders, Jason; Kandrot, Edwad, CUDA by Example, United States: NVIDIA Corporation, [8] Grubisic, Viviane; Ogliari, André, Uso de Matrizes de Correlação na Modelagem das Redes Bayesianas para Análise de R scos o Pro eto do Produto, disponível em: Acesso em: 24 de fev. de [9] Torun, M. U.; Yilmaz, O.; Akansu, A. N, Novel GPU Implementation of Jacobi Algorithm for Karhunen-Loève Tranform of Dense Matrices, [10] Duin, Robert P.W, Multiple Features Data Set, disponível em: Acesso em 03 de mar. de Figura 5.2 Tempos de execução da matriz de correlação na CPU e GPU, com o número de linhas indo de 2 a 1024 e de colunas de 2 a

39 Automação de Testes de Unidade em um Ambiente de Data Warehouse Wenderson Campos Pereira, Igor Peterson Oliveira Santos, André Vinicius Rodrigues Passos Nascimento, Methanias Colaço Rodrigues Júnior Departamento de Sistemas de Informação Universidade Federal de Sergipe Itabaiana-SE, Brasil {wenderson_se, igorp.ita, Resumo A qualidade de um produto de software está diretamente relacionada com os testes empregados durante o seu desenvolvimento. Embora os processos de testes para softwares aplicativos e sistemas transacionais já apresentem um alto grau de maturidade, o mesmo não pode ser afirmado para os processos de testes no ambiente de Data Warehouse. As diferenças desse ambiente em relação aos demais tipos de sistemas fazem com que os processos e ferramentas de testes existentes precisem ser ajustados a uma nova realidade. No processo de Data Warehousing, a fase de povoamento merece atenção especial por englobar procedimentos críticos em relação à qualidade. Nesse trabalho, propomos a utilização de um framework de testes de unidade com a abordagem blackbox para rotinas de povoamento em um ambiente de Data Warehouse. O framework proposto, com base em metadados sobre as rotinas de povoamento, fará a execução automática de casos de testes através da geração de estados iniciais, execução das rotinas, e análise dos estados finais. O framework, com base no comportamento das rotinas, também será responsável pela seleção dos casos de testes a serem aplicados. Acreditamos que a utilização dessa abordagem pode melhorar a qualidade das rotinas de povoamento e reduzir o tempo empregado no processo de teste. Keywords: Data Warehouse; Testes de Software; Qualidade de Dados I. INTRODUÇÃO O principal objetivo de um ambiente de Data Warehouse (DW), independente da atividade fim da organização que o emprega, é fornecer informações para o efetivo suporte à tomada de decisões [1,7,4]. A continuidade da utilização desse ambiente, que mede o sucesso ou fracasso do projeto, está diretamente relacionada com a qualidade dos dados finais apresentados ao usuário [2, 3]. As principais causas que contribuem para a má qualidade de dados em um ambiente de DW foram classificadas em [5] de acordo com cada fase do processo de Data Warehousing. Nessa classificação, a fase conhecida como ETL (Extract, Transform and Load) [8,12,13] responsável pela extração, limpeza, integração e povoamento dos dados provenientes das fontes de dados operacionais ou externas, é apontada como o estágio mais crucial de todo o processo. Nesse estágio, são muitas as causas que podem contribuir para a má qualidade dos dados. Dentre essas causas, podemos destacar aquelas ligadas à fase de povoamento, e que afetam diretamente as visões dos usuários: a) Implementações incorretas ou a má interpretação das estratégias de armazenamento de histórico nas dimensões; b) Falta de tratamento em valores nulos; c) Tratamento incorreto de colunas de auditoria; d) Perda de dados (dados rejeitados) durante o processo de povoamento. A falta de disponibilidade de testes de unidade automáticos em ferramentas ETL, que também é apontada em [5] como causa para a má qualidade de dados, contribui para os problemas da fase de povoamento. Na verdade, o processo de testes no ambiente de Data Warehouse como um todo, não somente na fase de povoamento, tem sido negligenciado [6]. A pouca utilização de processos de testes no ambiente de DW é creditada às diferenças entre a arquitetura desse ambiente e as arquiteturas dos sistemas Aplicativos e sistemas Transacionais. Conforme apontado por vários autores [6, 14, 15], essas diferenças fazem com que as técnicas de testes utilizadas por estes últimos precisem ser ajustadas para um ambiente de DW. O objetivo desse trabalho é propor a utilização de um framework de testes de unidade para rotinas de povoamento em um ambiente de Data Warehouse. Utilizando uma abordagem black-box e tratando as rotinas sob o ponto de vista de aplicação, o framework irá gerar estados iniciais e finais do banco de dados em função de casos de testes previamente especificados. O comportamento esperado das rotinas, a seleção dos casos de testes e os estados do banco de dados a serem utilizados serão determinados por metadados utilizados pelo framework. Os testes iniciais com a utilização do framework apresentam evidências de que a abordagem utilizada pode melhorar a qualidade das rotinas de povoamento e reduzir o tempo empregado no processo de teste. O restante do trabalho está estruturado como segue. A Seção II descreve a arquitetura de um DW e as rotinas de povoamento. A Seção III apresenta resumidamente as principais técnicas utilizadas para testes de software e discute a aplicação de testes no ambiente de DW. Na Seção IV é apresentado o framework proposto e os detalhes de sua implementação. Na Seção V são apresentados os trabalhos relacionados. As Seções VI e VII apresentam, respectivamente, as conclusões e os trabalhos futuros. 29

40 II. DW E ROTINAS DE POVOAMENTO Conforme apresentado na Fig. 1, a arquitetura genérica de um ambiente de DW apresenta três principais componentes: o ambiente OLTP, a área de Staging e o Data Warehouse. Esses três componentes fazem parte do caminho percorrido pelos dados da organização desde a sua origem até as estruturas finais utilizadas pelos tomadores de decisão. O ambiente OLTP (Online Transaction Processing) é formado pelos sistemas envolvidos nos processos diários das organizações. Os dados tratados por esses sistemas também são conhecidos como dados operacionais. Esses dados, que podem ser provenientes de estruturas internas ou externas à organização, representam as fontes de informações para o Data Warehouse. O Data Warehouse, que pode ser conceituado como um banco de dados histórico e integrado [1,3,7], é a fonte direta de dados utilizados por ferramentas de relatórios, sistemas gerenciais, ferramentas OLAP e algoritmos de mineração de dados durante o processo de suporte à decisão. A estrutura interna desse repositório é geralmente formada por esquemas de dados modelados através de uma técnica de projeto lógico conhecida como Modelagem Dimensional [2]. Nessa técnica, os esquemas produzidos, conhecidos genericamente com esquemas em estrela, apresentam duas principais estruturas básicas de armazenamento: as tabelas de Fato e as Dimensões. As tabelas de Fato são responsáveis por registrar as transações, ocorrências ou fatos de um processo de negócio. As Dimensões representam os elementos que irão contextualizar os fatos registrados. Antes de serem carregados para os esquemas em estrela e disponibilizados para os tomadores de decisões, os dados operacionais precisam passar por um processo conhecido como ETL (Extract, Transform, Load), responsável pelas atividades de extração, limpeza, integração e povoamento. Esse processo ocorre em uma área intermediária conhecida como área de Staging [2]. A fase final do processo de ETL, o povoamento, consiste em povoar os esquemas de dados do Data Warehouse. Em outras palavras, é a fase responsável pela atualização das tabelas de Fatos e das Dimensões. Figura 1. Arquitetura genérica de um DW. As rotinas de povoamento, em particular as voltadas para as dimensões, também são responsáveis pelas implementações das estratégias de armazenamento de histórico. Os tipos de comportamento dos atributos das dimensões: tipo 1, tipo 2, tipo 3; e os tipos híbridos: 4 e 6 determinam como o histórico será armazenado [2, 7, 9]. É na fase de povoamento que ocorrem os processos mais críticos em relação à qualidade de dados [5]: a) Geração e gerenciamento de Surrogate Keys; b) Manutenção das estratégias de armazenamento de histórico nas Dimensões; c) Carregamento de registros para a tabela de Fatos; d) Carregamento de registros para as Dimensões; e) Manutenção de hierarquias; f) Carregamento e manutenção de Agregados. Explicações detalhadas sobre cada um desses processos podem ser encontradas em [2, 7]. Cada um dos processos mencionados da fase de povoamento são implementados através de rotinas de povoamento, construídas manualmente ou com o auxílio de ferramentas. As últimas, geralmente proprietárias, são conhecidas como ferramentas ETL. Quando construídas manualmente, os códigos das rotinas estão disponíveis para serem inspecionados, revisados e testados. As ferramentas ETL, por sua vez, geram, normalmente, programas ou pacotes executáveis. Nesses casos, somente as interfaces de chamadas das rotinas estão disponíveis. III. TESTES DE SOFTWARE A qualidade de um produto de software, seja ele um sistema aplicativo, um sistema transacional ou um ambiente de Data Warehouse, está diretamente relacionada com os processos de testes empregados durante o desenvolvimento desses produtos. Os testes de software podem ser divididos em duas grandes categorias [16]: a) Não apoiados por computador; b) Apoiados por computador. Na primeira categoria estão as técnicas de testes empregadas de forma manual como a inspeção de código, a varredura e as revisões. Na segunda categoria encontramos as técnicas mais tradicionais como o teste de caixa branca (white-box) e o teste de caixa-preta (black-box). Um bom processo de testes não deve se apoiar em uma única categoria e em uma única técnica, mas deve combinar as categorias e técnicas existentes a fim de cobrir o maior número de casos de testes possível. Os testes de software devem ser empregados de acordo com uma estratégia ou processo. Diversas abordagens podem ser encontradas na literatura [16,17,18]. Apesar das variações existentes, todas concordam que a estratégia de testes deve começar pelo nível de componente, no qual as unidades de código são testadas, e avançar até o nível de sistema, no qual o software e outros elementos de sistemas são testados em conjunto. A automação de testes também representa um ponto crucial no processo adotado. Os casos de testes utilizados não devem ser descartados, pois o processo de teste é muito oneroso. Reinventar casos de testes para componentes ou módulos já testados não tem se mostrado uma atividade com muita disciplina. Desse modo, é importante que os casos de testes sejam guardados para serem executados 30