Sociedad Peruana de Computación. VII Jornada Peruana de Computación JPC

Transcripción

1 Sociedad Peruana de Computación VII Jornada Peruana de Computación JPC Lima Perú De l0 al 15 de Noviembre del 2008

2 Copyright 2008 por SOCIEDAD PERUANA DE COMPUTACIÓN Proceedings de la VII Jornada Peruana de Computación JPC 2008 Editor: César A. Beltrán Castañón Primera Edición: Noviembre del 2008 SOCIEDAD PERUANA DE COMPUTACIÓN Arequipa Perú Teléfono: Hecho el Depósito Legal en la Biblioteca Nacional del Perú Nº

3 Índice General Prólogo 6 Comité de Programa 7 Migração de Paradigmas e Tecnologias no Desenvolvimento de um Sistema para Estudos Estratégicos de Afundamentos de Tensão. Ciniro A. L. Nametala (CEFET-Bambuí, UNIFEI), Carlos Bernardes Rosa Júnior (CEFET-Bambuí), Alexandre Pimenta (FADOM - Faculdades Integradas do Oeste de Minas), Gabriel da Silva (CEFET-Bambuí), Thiago Oliveira (Universidade Federal de Itajubá). Associations & Rules: a flexible approach to manage aspects conflicts. Sandra Casas (Universidad Nacional de la Patagonia Austral). Niveles de Riesgo de Conflictos en AspectJ: una propuesta basada en el pasaje del contexto. Sandra Casas (Universidad Nacional de la Patagonia Austral). Propuesta del Algoritmo RARM-QF: Minería de Reglas de Asociación Rápida con Factor de Cantidad aplicado a documentos XML de Bases de Datos Relacionales XML-Enabled. Erika Hidalgo (Universidad Católica Santa María), Alvaro Cornejo (universidad catolica santa maria), Karim Guevara (Universidad Católica Santa María). Reconocimiento de expresiones faciales mediante flujo óptico en secuencias de video. Filomen Incahuanaco (Universidad Nacional de San Agustin). Extensão da UML para Representação de Modelagem de Negócios Baseada em Visões. Silvia Ladeira (UNIVEM - Centro Universitário Eurípides de Marília), Rodrigo Jorge (UFGD - Universidade Federal da Grande Dourados), Rosângela Penteado (Universidade Federal de São Carlos), Maria Istela Cagnin (UFGD-Universidade Federal Grande Dourados). Ferramenta Tutora no Desenvolvimento de Jogos Educacionais. Franciele Lewandowski (Centro Universitário Franciscano), Adriana Soares Pereira (Centro Universitário Franciscano). Clasificación de Tejidos Cancerígenos Usando Maquinas de Vectores de Soporte. Shirley Victoria Reynozo Torres (Universidad Católica San Pablo), Juan Carlos Gutierrez Cáceres (Universidad Católica San Pablo). Método para la Aplicación de Esquemas de Clave Pública al Cifrado de Imágenes RGB. Jorge Valverde Rebaza (Universidad Nacional de Trujillo), Pedro Shiguihara Juárez (Universidad Nacional de Trujillo), Juan Grados Vásquez (Universidad Nacional de Trujillo)

4 Aplicando Programação Orientada a Aspectos para Construção da Camada de Persistência em Aplicações Java e Hibernate. Mario Sérgio Torres (Universidade da Amazônia), Leonardo Cruz (Universidade da Amazonia), Leonardo Mezzomo (Universidade da Amazônia), Bruno Moutinho (Universidade da Amazônia). Identificación de problemas en proyectos de mejora de procesos: una experiencia en tres pequeñas empresas desarrolladoras de software en el Perú. Eddy Maidana Cuadros (Pontificia Universidad Católica del Perú), Nohelia Vilchez (Pontificia Universidad Católica del Perú), Carolina Vega (Pontificia Universidad Católica del Perú), Abraham Davila (Pontificia Universidad Católica del Perú). Reconocimiento de Patrones Invariantes a Transformaciones Geométricas. Jorge Perochena (Universidad Catolica San Pablo), Juan Carlos Gutiérrez Cáceres (Universidad Católica San Pablo). A Hierachical Proximity Graph for Similarity Search. Alexander Ocsa (Universidad Nacional de San Agustin), Omar U. Florez (UTA State University, Logan, USA). Smart Cleaning tools: Una plataforma para detección y corrección de datos sucios. Maryluz Martinez Restrepo (Parque Tecnologico de Software), Gelver Vargas Barona (Parque Tecnologico de Software), John Gomez Carvajal (Univalle). Deformaciones Interactivas en GPU. Alvaro Cuno (Universidade Federal do Rio de Janeiro), Claudio Esperança (UFRJ). Mini Chess. Cristian Peñarrieta (Universidad Peruana de Ciencias Aplicadas), Daniel Carranza (Universidad Peruana de Ciencias Aplicadas), Natalia Valdivia (Universidad Peruana de Ciencias Aplicadas). Sieve's Algorithm Modification. Carlos Atencio (National University of San Agustin), Joshimar Cordova (University of San Agustin). Arquitectura JEE5, herramientas libres y metodología en el proceso de desarrollo de Software. Jorge Fabian Chuquitaype Zuñiga (Universidad Nacional de San Agustin), V. Alfonso Phocco Diaz (San Agustin National University), Carlos Herrera Muñoz (Univerdidad Nacional de San Agustin de Arequipa). SEDFE: Un Sistema Experto para el Diagnóstico Fitosanitario del Espárrago usando Redes Bayesianas. Pedro Shiguihara Juárez (Universidad Nacional de Trujillo), Jorge Valverde Rebaza (Universidad Nacional de Trujillo). Reconstrucción de Superficies 3D aplicadas a imágenes médicas. Nils Murrugarra (Universidad Nacional de Trujillo), Leissi Castañeda (Universidad Nacional de Trujillo), Oscar Fernandez (Universidad Nacional de Trujillo)

5 Generación Inteligente de Horarios empleando heurísticas GRASP con Búsqueda Tabú para la Pontifica Universidad Católica del Perú. Joseph Gallart Suarez (Pontificia Universidad Catolica del Peru), Fernando Alva Manchego (Pontificia Universidad Catolica del Peru), Anthony Alama Nole (Pontificia Universidad Catolica del Peru), Gissella Bejarano Nicho (Pontificia Universidad Catolica del Peru). Desenvolvendo Ambientes Inteligentes de Ensino Aplicados à Engenharia de Software. Daniel Abella (Federal University of Paraíba), Rodrigo Fujioka (Federal University of Paraíba), Ryan Ribeiro de Azevedo (Universidade Federal de Pernambuco), César Vasconcelos (Centro Federal de Educação Tecnológica de Urutaí/UNED Morrinhos), José Carvalho Neto (Federal University of Paraíba), Wescley Sousa (Federal University of Campina Grande). Recuperación de imágenes médicas a través de regiones relevantes. Fredy Carranza-Athó (Universidad Nacional de Trujillo), Laura Florian-Cruz (Universidad Nacional de Trujillo) Codificación de huellas dactilares usando grafos invertidos. Christian Wong (SECC). 251 Índice de autores 258 5

6 Prólogo El presente libro corresponde a los Proceedings de la VII JORNADA PERUANA DE COMPUTACIÓN, el mismo que contiene todos los trabajos completos aceptados en el evento, el mismo que se llevó a cabo del 10 al 15 de Noviembre del 2008 en la ciudad de Lima (Perú). En estos tiempos en que la economía viene sufriendo serios problemas, es importante que nuevos sectores productivos sean generados en el país, siendo que la producción de Software es una buena alternativa para constituirse en uno de esos nuevos sectores productivos que permitan cambiar el ingreso per cápita de la población nacional. Pero, la gran dificultad que se tiene actualmente para conseguir ese objetivo, es el escaso recurso humano calificado que se constituya en el equipo que genere el cambio que necesita nuestro país. No es un secreto el hecho que para salir del tercermundismo es necesario invertir en Ciencia y Tecnología, y ello involucra no solamente el aspecto de equipamiento, sino por el contrario la capacitación adecuada de los profesionales. Por otro lado, la Computación se ha constituido en una necesidad en todos los ámbitos de la sociedad, constituyéndose en un conocimiento paralelo a la matemática, física, ingenierías, entre otros. Por ello que el hecho de pensar en términos del uso de la Computación es denominado como el Pensamiento Computacional, ello implica que los profesionales de la Computación estamos ideando algoritmos, soluciones, métodos, etc, que puedan ser desarrollados por las computadoras, aspecto que nos caracteriza y diferencia de las demás profesiones. Es en ese sentido, que los distintos trabajos aceptados en la JPC 2008, guardan un estricto criterio de calidad, por el cual el Comité de Programa se ha encargado de cuidar. Con satisfacción podemos afirmar que el nivel de los trabajos en el evento viene incrementándose año tras año, lo cual se demuestra con el interés de parte de autores extranjeros que en este año fueron más de la mitad de los artículos submetidos. En total se recibieron 65 trabajos, de los cuales fueron aceptados 24, lo cual otorga una tasa de aceptación de 40%. Entre los trabajos aceptados se tienen artículos procedentes de Brasil, Argentina, Colombia y Costa Rica, incluyendo los trabajos peruanos, entre los que destacan trabajos de las ciudades de Trujillo, Lima y Arequipa. Gustaríamos agradecer y otorgar nuestro reconocimiento al Comité de Programa por el trabajo desplegado y la dedicación en su tarea. Del mismo modo nuestro agradecimiento a la Sociedad Brasileña de Computación por el uso del sistema JEMS, al Centro Latinoamericano de Estudios en Informática, a GOOGLE, FINCyT, Concytec y Apesoft por el auspicio otorgado. También nuestro sincero agradecimiento a las autoridades y comunidad universitaria de la Universidad Nacional Mayor de San Marcos, por haber sido la sede de esta versión de nuestras Jornadas, especialmente al Comité Organizador local de la Facultad de Ingeniería de Sistemas e Informática. Finalmente, a todos los autores y participantes de nuestro evento, le agradecemos el habernos honrado con su participación lo que dio mayor prestigio al evento, esperando que hayan tenido una semana académica muy productiva. Dr. César A. Beltrán Castañón Presidente de Comité de Programa. 6

7 Comité de Programa Abraham Dávila (PUCP, Perú) Adenilso Simao (SSC-ICMC-USP, Brasil) Agustín Francisco Gutiérrez Tornés (ITESM- CCM, México) Alberto Pardo (U de la República, Uruguay) Alex J. Cuadros-Vargas (ICMC, Brasil) Alfredo Paz (UNSA, Perú) Ana María Cuadros V. (UCSP, Perú) Andre Santanche (UNIFACS, Brasil) Andrew Pletch (State U of New York, U.S.A) Angel Coca Balta (UENF, Brasil) Angélica Urrutia (UCM, Chile) Arturo Torres-Zenteno (U. de Sevilla, España) Carlos A. Estombelo Montesco (USP, Brasil) Carlos Raymundo (UPAO, Perú) César A. Beltrán Castañón (SPC, Perú) [Chair] Christian Paz-Trillo (USP, Brasil) Cristian López del Alamo (UCSP, Perú) David Mauricio Sanchez (UNMSM, Perú) Daltro José Nunes (UFRGS, Brasil) David Fernández-Baca (Iowa State University, U.S.A) Eduardo Llapa Rodriguez (USP, Brasil) Eduardo Tejada (University of Stuttgart, Alemania) Ernesto Cuadros-Vargas (SPC, Perú) Giovani Rubert Librelotto (UNIFRA, Brasil) Gladys Maquera Sosa (UPeU, Perú) Graciela Meza Lovón (UCSP, Perú) Guillermo Cámara (DCC-UFMG, Brasil) Guina Sotomayor (UFRJ, Brasil) Javier Alexander Montoya-Zegarra (Unicamp, Brasil) Jesús Mena (IME-USP, Brasil) João José Neto (EPUSP, Brasil) Johannes Textor (U of Luebeck, Alemania) Jorge Luna Urquizo (UNSA, Perú) José Herrera Quispe (UNSA, Perú) José Antonio Pow-Sang (PUCP, Perú) José Carlos Maldonado (ICMC-USP, Brasil) Juan Carlos Cáceres Gutierrez (UNSA, Perú) Juan Manuel Gutiérrez Cárdenas (UCSP, Perú) Kathy Garden (AUT, Nueva Zelandia) Leoncio Jimenez (UCM, Chile) Luca Cernuzzi (DEI-UC, Paraguay) Luis Rivera (UIGV, Perú) Marcello Visconti (UTFSM, Chile) Marco A. Alvarez (Utah State U, U.S.A) Maria Rosa Galli (CONICET, UTN-FRSF, Argentina) Markus Mock (Google, U.S.A) Mauricio Solar (USACH, Chile) Omar U. Florez (Utah State University, USA) Oscar Pastor (UPV, España) Paul Pauca (WFU, U.S.A) Percy A. Pari Salas (Bond University, Australia) Philip Sallis (AUT, Nueva Zelandia) Regina Motz (U de la Republica, Uruguay) Renzo Angles (Universidad de Chile, Chile) Ricardo da Silva Torres (Unicamp, Brasil) Roseli A. Francelin Romero (ICMC-USP, Brasil) Sofía Álvarez Cárdenas (USIL, Perú) Waldo Cancino (ICMC-USP, Brasil) Yalmar Ponce Atencio (UFRJ, Brasil) Yván Jesús Túpac (PUC-RIO, Brasil) 7

8 8

9 Migração de Paradigmas e Tecnologias no Desenvolvimento de um Sistema para Estudos Estratégicos de Afundamentos de Tensão Ciniro A. L. Nametala¹, Carlos B. Rosa Júnior¹, Alexandre Pimenta¹, Gabriel da Silva¹, Thiago C. Oliveira² 1 Departamento de Computação Centro Federal de Educação Tecnologica de Bambuí Caixa Postal Bambuí MG Brasil 2 Grupo de Estudos da Qualidade da Energia Elétrica Universidade Federal de Itajubá Caixa Postal Itajubá MG Brasil {ciniro,carlos,alexandre,gabrields}@cefetbambui.edu.br, thiagocle@unifei.edu.br Resumo Com a crescente adoção de cargas sensíveis a variação da energia elétrica em pontos de consumo e os custos envolvidos para adquiri-las e operá-las, surge atualmente à preocupação em gerar e consumir energia elétrica com parâmetros que a definem com ou sem qualidade. Este artigo apresenta o processo de migração de tecnologias, migração de paradigmas e desenvolvimento da segunda versão de um sistema computacional que realiza estudos estratégicos com base em simulações pretéritas e prospectivas, frente ao afundamento de tensão, fenômeno que hoje é a maior causa de paradas em processos industriais contínuos. O SAT Sistema para Análise de Afundamentos de Tensão é resultado de um projeto de pesquisa e desenvolvimento P&D que, fomentado em sua primeira fase pela FUPAI (Fundação de Pesquisa e Apoio a Indústria), a partir do ano de 2003, envolveu em cinco anos de pesquisa a concessionária fluminense Light Serviços de Eletricidade S.A. e as instituições mineiras UNIFEI (Universidade Federal de Itajubá) e CEFET - Bambuí (Centro Federal de Educação Tecnológica de Bambuí). Este sistema tem por objetivo apoiar clientes e concessionárias de energia elétrica na tomada de decisão na elaboração e emprego de métodos mitigadores, visto que, os afundamentos de tensão são inerentes e inevitáveis no sistema elétrico. 1.Introdução Nos últimos anos, em função da crescente utilização de computadores e aparelhos eletrônicos, os setores comercial e residencial passam por um processo de modernização constante. De forma mais ampla, o setor industrial tem aprimorado seus processos de controle de produção com o emprego de equipamentos mais sofisticados do ponto de vista tecnológico. Este atual cenário, caracterizado pela crescente utilização destes equipamentos, sensíveis às variações dos parâmetros que compõe a energia elétrica, faz com que seja constante a necessidade de um sistema elétrico que, acima de tudo, provenha confiabilidade e qualidade de fornecimento. Assim, estudos centrados na Qualidade da Energia Elétrica (QEE) passam a identificar fenômenos nocivos e procurar soluções para clientes e concessionárias que compõem todo o processo de geração, transmissão, distribuição e consumo de energia elétrica. Dentre os fenômenos inseridos no âmbito da QEE, o afundamento de tensão (AMT) é o distúrbio que mais gera prejuízos ao setor industrial, sendo a principal causa de paradas de processos industriais contínuos, ocasionando perdas de produção e insumos, além de, danificar equipamentos e gerar custos como mão-de-obra em reparos [WAGNER 2004]. O AMT é um fenômeno inevitável e inerente ao sistema elétrico e ocorre principalmente em linhas de 9

10 transmissão de energia, constatando-se uma forte correlação com a incidência de descargas atmosféricas [CARVALHO FILHO 2004]. O desenvolvimento de estratégias para mitigação e estudo do AMT é feito com base em monitorações ou através de estudos estatísticos desenvolvidos a partir de histórico de ocorrências. Sendo este fenômeno essencialmente aleatório, sistemas computacionais visando à simulação de ocorrências tornam-se uma alternativa relevante, pois, evitam gastos de tempo e dinheiro com medições em campo [QADER 1999]. O Sistema para Análise dos Afundamentos de Tensão (SAT), dentro deste contexto apresentado, é um software desenvolvido no ano de 2004, num projeto de Pesquisa e Desenvolvimento P&D da Light Serviços de Eletricidade S.A., através de um convênio firmado com a Fundação de Pesquisa e Apoio a Indústria (FUPAI), fundação esta associada à Universidade Federal de Itajubá (UNIFEI). O software em questão, integra metodologias de análises pretéritas e prospectivas na ocorrência de afundamentos de tensão (AMTs), permitindo assim, que consumidores e concessionárias avaliem o impacto desse fenômeno no sistema elétrico. O que gera subsídios para a tomada de decisão na aplicação da melhor metodologia mitigadora, frente a este distúrbio. Este artigo apresenta o segundo estágio deste projeto. Onde, num convênio firmado entre o departamento de Computação do Centro Federal de Educação Tecnológica de Bambuí (CEFET- Bambuí) e o Grupo de Estudos da Qualidade da Energia Elétrica (GQEE) da UNIFEI, o SAT foi inserido em um processo de migração para uma segunda versão. Esta diferindo da primeira, quanto à linguagem, paradigma de programação, arquitetura e banco de dados, mas aprimorando e ampliando funcionalidades. Para a concepção desta nova versão, metodologias de migração foram elaboradas e aplicadas. Nas próximas seções será apresentado o processo de construção deste software e as metodologias empregadas na fase de migração de tecnologias e paradigmas. 2.Caracterização do Problema Atualmente, a forma de transmissão de energia elétrica mais utilizada no mundo e principalmente em território nacional é feita com base na utilização de estruturas compostas por torres e linhas suspensas. Denominadas apenas como, linhas de transmissão aéreas, estas interligam a usina geradora de energia à malha de distribuição que compõe o esquema de fornecimento das cidades. Devido à existência de milhares de quilômetros dessas linhas de transmissão aéreas sujeitas às intempéries naturais, as descargas atmosféricas se evidenciam por estarem relacionadas com distúrbios da QEE em até 95% das vezes em que os mesmos são constatados [OLIVEIRA 2004]. Dentre esses distúrbios, o foco do SAT, sistema de software aqui discutido, são os Afundamentos de Tensão. Conhecido na literatura internacional como Voltage Sag, o AMT é definido pela Norma IEEE [IEEE 1995], que trata da monitoração dos fenômenos da QEE, como uma queda no módulo do parâmetro tensão da energia elétrica em relação a um pré-valor dado como nominal (Ver Figura 1). O afundamento ainda é classificado quanto à duração, que corresponde ao tempo em que o módulo da tensão se mantém abaixo do valor dado como nominal. E a intensidade, que corresponde ao menor valor atingido na queda da tensão em relação ao valor nominal. 10

11 Figura 1. Caracterização de um AMT segundo IEEE (1995) AMTs causam situações indesejáveis no sistema elétrico, visto que, cargas sensíveis às variações da energia elétrica podem ser danificadas ou desligadas, gerando interrupções em processos industriais e consequentemente prejuízos. Estima-se que, por ano, só no Brasil, perdemse dois bilhões de reais com situações decorridas de distúrbios elétricos, como o AMT [CUNHA 2004]. Por este fenômeno ser inevitável, metodologias preventivas são elaboradas com base em estudos de históricos de monitoração, mas por ocorrerem de forma aleatória, estudos feitos através de simulação computacional aliada á matemática estatística, também trazem resultados satisfatórios [QADER 1999]. E é neste tipo de estudo que o sistema SAT se baseia. 3.Proposta do Software Há atualmente alguns softwares que simulam a ocorrência de AMTs e, com base nessas simulações, realizam estudos estratégicos. Mas ainda assim, algumas funcionalidades não são encontradas nestes softwares. O SAT visa contemplar algumas dessas funcionalidades. Sendo este dedicado a: Integrar em um único sistema de software as funcionalidades de análise retrospectiva e prospectiva; Possibilitar a simulação dos AMTs de forma aleatória, como num sistema real; Para análises prospectivas, possibilitar o sorteio de vários parâmetros que permeiam a ocorrência do fenômeno e a partir destes, aplicar métodos de cálculos estocásticos e de curtocircuito deslizante. Executar cálculos e realizar processos iterativos de forma automatizada. Operação que se efetuada manualmente, despenderia muito tempo; Apresentar de forma clara e objetiva, através de gráficos, tabelas e relatórios, os resultados importantes que auxiliam na tomada de decisão. Assim, o SAT opera sobre duas metodologias de estudos de Afundamentos de Tensão, sendo estas: Estudos prospectivos, onde o foco é estimar o comportamento futuro do sistema elétrico. Esta metodologia pode ser dividida em dois outros ramos. O primeiro, trata do método do curto- 11

12 circuito deslizante que busca estimar o comportamento futuro médio de barras do sistema elétrico. Neste caso, todas as barras, ao longo de todas as linhas, são selecionadas para a simulação da falta com base em um passo fixo, previamente determinado. O segundo, trata do método do cálculo estocástico que não considera todos os curtos-circuitos simulados. As características das faltas são sorteadas considerando o período de simulação selecionado pelo usuário, em anos [OLIVEIRA 2004]. Estudos Retrospectivos, onde o foco é analisar o comportamento pretérito do sistema elétrico. É feito com base em um histórico operacional de um determinado período, contendo dados das faltas a serem analisadas. O sistema avalia o desempenho de barras previamente determinadas. Este estudo permite avaliar, por exemplo, a procedência de reclamações de clientes [OLIVEIRA 2004]. Ambas as metodologias são realizadas pelo SAT no padrão ANAFAS [CEPEL 1998]. O ANAFAS é um software que realiza cálculos de curto-circuito. O SAT, na primeira e segunda versão, opera com este sistema em uma interface direta, trocando informações com o mesmo. Essa operação se dá de forma totalmente transparente ao usuário 4.SAT Visão Geral da Versão 1.0 O SAT, em sua primeira versão, possui aproximadamente cinqüenta e cinco mil linhas de código dispostas em quarenta e um módulos. Foi implementado através da ferramenta Microsoft Visual Basic 6 (VB6). Esta ferramenta RAD (Rapid Aplication Development) é composta por linguagem de programação e interface GUI (Graphical User Interface) para programação visual. Com suporte principal à programação orientada a eventos, ela provê o desenvolvimento de softwares focados nos sistemas operacionais Microsoft Windows. Em conjunto com o VB6, utilizou-se também um sistema para a geração automática de formulários e funcionalidades. Através deste, foi criado o sistema de autenticação de usuários e cadastros em banco de dados. A utilização deste tipo de sistema acelera o processo de desenvolvimento, mas diminui a confiabilidade, visto que, o programador não tem controle completo sobre o código gerado. Para armazenamento de informações o SAT 1.0 (SAT Primeira Versão) utiliza-se de arquivos de texto plano com extensões específicas e, principalmente, do sistema gerenciador de banco de dados relacionais (SGBD) Microsoft SQL Server Este SGBD, de licença paga, é responsável por: Manter os relacionamentos entre as informações contidas no banco de dados; Garantir que os dados sejam armazenados corretamente; Garantir que as regras que definem os relacionamentos entre os dados não sejam violadas; Recuperar todos os dados até um ponto de consistência conhecido em caso de falha do sistema. O projeto de construção desta primeira versão durou um ano e envolveu o GQEE e o Grupo de Pesquisa em Engenharia de Sistemas e Computação (GPESC), que como o GQEE, atua também na UNIFEI. O SAT 1.0 foi concluído em novembro de 2004 e passou a ser utilizado nas dependências da concessionária Light Serviços Eletricidade S.A. na cidade do Rio de Janeiro. Desta data em 12

13 diante, novas tecnologias e metodologias para o desenvolvimento de software foram desenvolvidas e popularizadas, ao passo que, foi diminuindo o suporte dado pelas empresas nas tecnologias que o SAT 1.0 foi construído. Aliado a isso, durante o período em que o sistema foi sendo utilizado, alguns problemas foram identificados, como: Necessidade de revisão de algumas funcionalidades; Licença paga do banco de dados utilizado; Não possuir documentação; Não possuir um pacote de instalação; E principalmente, o surgimento de novos requisitos. Devido a estes fatores, surgiu a necessidade de revisão e expansão desta primeira versão do sistema. Assim, foi apresentada, em Setembro de 2006, ao GQEE, uma proposta de migração completa do software, colocando o projeto em uma segunda fase. Nesta, foi sugerido efetuar uma análise do sistema, migrar as tecnologias utilizadas no desenvolvimento do software para outras mais atuais, aplicar processos de engenharia de software para confecção de documentações, adaptar o sistema a um banco de dados gratuito e reconstruir o SAT com foco na arquitetura, migrando assim, os paradigmas de desenvolvimento de estruturado para orientado a objetos. 5.Projeto de Migração O projeto de migração do SAT pode ser definido como a construção de uma segunda versão do sistema. No projeto dessa segunda versão, tinha-se por requisito que todas as funcionalidades do SAT 1.0 estariam presentes e que com base em novos requisitos, uma triagem para definição de novas funcionalidades seria executada. Assim, em nível funcional, projetou-se o SAT 2.0 (segunda versão do sistema) para realizar, não somente os estudos retrospectivos e prospectivos convencionais, contidos no SAT 1.0, mas também para realizar uma nova rotina de simulação com foco na metodologia de estudos estocásticos. Nesse novo estudo pretende-se criar um procedimento com o objetivo de validar resultados de medição de AMTs com base em simulações estocásticas. Esta validação é de grande importância, principalmente quando as medições são realizadas por curtos períodos. De forma a reproduzir precisamente o comportamento de um sistema elétrico real, a incerteza associada a diversas variáveis devem ser levadas em consideração. Adicionalmente às variáveis aleatórias, normalmente consideradas em outras publicações, este novo procedimento inclui os modelos probabilísticos para: taxa de falta de linhas e barramentos, tensão pré-falta, distribuição dos tipos de falta, posição de falta, resistência de falta, falha dos sistemas de proteção e sensibilidade de equipamentos a Afundamentos de Tensão. Através de uma abordagem via Simulações de Monte Carlo, o sorteio de cada uma destas variáveis é realizado. Em seguida, são construídos os intervalos de confiança de alguns indicadores de desempenho do sistema através do método dos percentis. Alguns destes indicadores, em função da quantidade de amostras obtidas na medição, necessitam da aplicação de algumas ferramentas estatísticas, chamadas de testes de hipóteses. Para consolidar a validação dos resultados, estes testes resultam em um valor de probabilidade que, comparado com o nível de significância desejado, permite a avaliação da aderência entre as simulações estocásticas e as medições. Ainda definindo o projeto da segunda versão, o SAT 1.0 foi inserido num processo de análise de código e arquitetura de construção. O objetivo principal dessa análise era o de encontrar 13

14 defeitos no sistema e executar avaliações de interface, usabilidade, legibilidade de código e falhas na arquitetura. Com isso, foi possível identificar pontos onde o SAT 2.0 poderia ser melhorado em relação à primeira versão. Para a melhoria desses aspectos, a análise feita forneceu, também, subsídios para a escolha das tecnologias mais adequadas. 6.Migração de Tecnologias No projeto da segunda versão do sistema, definiu-se a necessidade de uma adaptação do código dentro de um novo projeto de arquitetura, para que ocorresse um melhoramento na disposição do algoritmo, proporcionando assim, uma maior facilidade em futuras manutenções e possíveis expansões do sistema. Para isso, se mostrou necessária a aplicação de uma linguagem que fornecesse suporte ao paradigma de desenvolvimento orientado a objetos. Segundo Sommerville (2003), o termo orientação a objetos significa organizar o mundo real como uma coleção de objetos que incorporam uma estrutura de dados a um conjunto de operações que manipulam estes dados. Sendo assim, Silva (2000) diz, ser a orientação a objetos, a forma mais adequada para a construção de sistemas que visem à organização de código, manutenção e reaproveitamento, por possibilitar a aplicação de técnicas como encapsulamento, herança, abstração e polimorfismo, além da possibilidade de construção e utilização de frameworks e a adoção de padrões no desenvolvimento. Fornecendo suporte a este paradigma e visto que, o SAT 1.0 foi construído através do VB6, optou-se por utilizar no desenvolvimento do SAT 2.0, a plataforma de desenvolvimento Microsoft.NET. Sucessora do Microsoft Visual Studio 6 (no qual está inserido o VB6), essa plataforma consiste, basicamente, em um conjunto de tecnologias que interagem sobre um framework comum, chamado Framework.NET. Essa interação se dá de forma a fornecer suporte completo ao desenvolvimento de sistemas computacionais centrados em vários tipos de ambientes (WEB, Windows, Dispositivos Móveis) e oferece a possibilidade de utilização de qualquer linguagem de programação que possua um compilador para o Framework.NET [CAMPBELL 2005]. No caso do projeto do sistema SAT 2.0 utilizou-se a linguagem VB.NET 2005 por possibilitar um mínimo impacto na migração, visto que, possui uma sintaxe semelhante à do VB6. Como provedor de relatórios optou-se por substituir o Crystal Reports 10, utilizado no desenvolvimento do SAT 1.0, pelo Crystal Reports 11. A versão 11 do Crystal Reports é mais indicada no desenvolvimento, visto que, se integra de forma nativa ao Framework.NET, utilizado no projeto. Para persistência de informações, na segunda versão do software, optou-se por utilizar um SGBD de licença gratuita, o que elimina a necessidade de pagamento de taxas extras para os usuários, empresas e instituições que adquirem o SAT. Entretanto, esse sistema utilizado no SAT 2.0, precisaria ainda ser compatível com o banco de dados utilizado na primeira versão e ter um mínimo de recursos para que não fosse comprometido o desempenho do sistema como um todo. Sendo assim, por atender a esses requisitos, optou-se pela utilização do Microsoft SQL Server 2005 Express Edition. Esta solução de análise e gerenciamento de dados é a versão gratuita e com menos recursos do Microsoft SQL Server No caso de armazenamento de dados em arquivos, foi definido que arquivos antes padronizados no formato de texto plano seriam substituídos por arquivos na linguagem XML. O arquivo de texto plano foi utilizado durante muito tempo para vários fins, mas na atualidade, para armazenamento de dados é mais conveniente a utilização de arquivos escritos em linguagem XML, por ser adaptável a qualquer nível de complexidade, possuir marcações personalizadas, 14

15 facilidade de manutenção, facilidade de manipulação e uma maior portabilidade [THAI 2000]. A seguir, a tabela 1 apresenta um comparativo entre as tecnologias usadas na versão 1.0 e suas correspondentes na versão 2.0 do sistema. Tabela 1. Comparativo de tecnologias utilizadas nas versões do sistema SAT Recurso Antiga Tecnologia Nova Tecnologia Plataforma Windows Runtime e Windows API s Framework.NET 2.0 IDE de Desenvolvimento Microsoft Visual Studio 6.0 Microsoft Visual Studio.NET 2005 Linguagem de Programação Visual Basic 6 Visual Basic.NET 2005 Paradigma Estruturado Orientado a Objetos Arquitetura de Projeto Rotina Modulares com funções MVC (Model-View- Controller) Banco de Dados SQL Server 2000 SQL Server 2005 Express Edition Provedor de Relatórios Crystal Reports 10 Crystal Reports 11 for.net Acesso a Dados ADO 2.8 ADO.NET Aplicação de Padrões de Projeto Para migração executada no desenvolvimento do SAT 2.0 foi necessário efetuar a adaptação de um código antes construído em paradigma estruturado para o paradigma da orientação a objetos, estruturando classes, denominando funções e delegando tarefas aos objetos usados no fluxo do algoritmo. Para a construção dessa estrutura foi aplicada uma forma padronizada de confecção de sistemas: os padrões de projeto. Segundo Shalloway (2004), a programação orientada a objetos apenas, se mostra pouco flexível para a resolução de certos problemas. É necessário então a adaptação da forma de se programar com base em padrões pré-estabelecidos que fornecem soluções ótimas para vários tipos de problemas, independendo da sua regra. Gamma (1995) define padrões de projeto dizendo que: Cada padrão descreve um problema que ocorre repetidamente no nosso ambiente e, portanto, descreve o cerne da solução desse problema, de tal forma que se pode utilizar essa solução um milhão de vezes repetidas, sem nunca fazê-lo duas vezes do mesmo modo. 15

16 A fim de criar um melhor ambiente para o desenvolvimento e organizar o código, foi aplicado como alicerce para a arquitetura do SAT 2.0 o padrão de projeto Model View Controller (MVC). Este padrão representa os dados da aplicação e as regras do negócio que governam o acesso e a modificação dos dados. Dividindo o sistema em camadas lógicas: Modelo, Visão e Controle. Aloca-se na camada Visão, toda a lógica referente à apresentação gráfica. Na camada Modelo, toda a lógica referente ao comportamento do sistema, as chamadas regras de negócios. E na camada Controle, toda a lógica referente às funções que executam acesso a dados oriundos de arquivos, objetos ou bancos de dados. Na primeira versão do SAT, o padrão de projeto MVC não pôde ser aplicado, visto que, pretendia-se criar uma camada lógica para acesso aos dados e outra apenas para as regras de negócio, o que necessitaria de uma estrutura de classes, recurso que o VB6 não fornece, pois não permite a programação orientada a objetos. Observa-se, na Figura 2, que na primeira versão, o encapsulamento das funções é quebrado quando a arquitetura modular do projeto funde as camadas de apresentação com negócios, e negócios com acesso a dados. Estas deveriam estar separadas em três níveis lógicos. Figura 2. Arquitetura utilizada no SAT 1.0 Na segunda versão do sistema, a arquitetura foi remontada com base na orientação a objetos e no padrão de projeto MVC. Toda a lógica referente à apresentação gráfica foi concentrada em uma camada (Visão). Para a parte funcional do sistema e efetuação de rotinas para cálculos, a lógica comportamental foi alocada em outra camada lógica (Modelo). E por fim, alocadas na terceira camada (Controle), todas as rotinas que fazem acesso a dados externos ou internos. Essa separação lógica de rotinas (Ver Figura 3) caracteriza o padrão de projeto discutido. Figura 3. Arquitetura MVC no SAT

17 8.Metodologia de Migração Para a migração de tecnologias e paradigmas de programação no desenvolvimento da segunda versão do SAT, foi elaborada uma metodologia de migração, que, utilizando-se os resultados da análise e do projeto de migração focava a conversão de código construído em VB6 para VB.NET Nesta metodologia foram testados três processos de conversão: Conversão Automatizada, Conversão de Lógica e Tradução de Código. Para os três processos foram obtidos resultados diferentes quanto à eficiência. Sendo cada um destes detalhados a seguir. 8.1.Conversão Automatizada Há na versão 2005 do Microsoft Visual Studio.NET, uma ferramenta que converte projetos desenvolvidos exclusivamente em linguagem VB6 para a linguagem VB.NET 2005, chamada Microsoft Visual Basic Upgrade Wizard. O código do SAT 1.0 foi preparado e submetido à conversão automatizada utilizando-se este software. Os resultados obtidos nessa conversão automatizada evidenciaram a ineficiência da ferramenta quando trabalhando com projetos de grande porte. O Visual Basic Upgrade Wizard é mais adequado a pequenos sistemas, e softwares que fazem acesso à base de dados, pois sua conversão é baseada na substituição de um determinado componente desenvolvido em VB6 para o mais similar em VB.NET 2005 [CAMPBELL 2005]. No caso do SAT, ao final do processo de conversão foi informado, pela própria ferramenta, que no projeto migrado, existiam 3155 erros sem possibilidade de conversão, 1212 passiveis de conversão, 35 problemas relacionados com componentes e 4020 sugestões de atualização do código desenvolvido em VB6. Isto ocorreu porque o SAT 1.0 utiliza-se de muitos recursos exclusivos do VB6 que, ou foram modificados na versão 2005 do Visual Basic, ou que, simplesmente não mais existem. Além disso, a estrutura das linguagens é profundamente diferente. Para a ferramenta proposta não foi possível realocar funcionalidades e criar uma arquitetura focada na migração de paradigmas, originando-se de um projeto estruturado e destinando-se a um projeto orientado a objetos. Assim, foi descartado o uso do Microsoft Visual Basic Upgrade Wizard que se apresentou falho neste tipo de empreitada. 8.2.Conversão Lógica No processo de migração que visa à conversão de lógica é necessário que o comportamento do sistema seja entendido e documentado. Ou seja, em um processo de engenharia reversa, abstraem-se os requisitos do sistema já construído e em seguida esses requisitos são implementados na linguagem e arquitetura de destino [SOMMERVILLE 2003]. No caso do SAT 1.0 a conversão de lógica se apresenta no seguinte diagrama (Figura 4): 17

18 Figura 4. Processo aplicado na conversão de lógica Eficaz, esse processo de migração foi utilizado em algumas partes do sistema. Mas a aplicação deste processo apenas, na migração de todo o sistema, exigiria uma maior demanda de tempo, aumentando o cronograma do projeto. Isto ocorre, porque, para o entendimento da lógica apresentada na camada B da figura 4, exigem-se conhecimentos específicos de QEE, em especial, de AMTs. Assim, visando uma melhor produtividade, nas funcionalidades que não tiveram modificação de comportamento foi aplicado outro processo de migração, a Tradução de Código. 8.3.Tradução de Código-Fonte Neste processo, a tradução de código é feita dividindo-se o sistema em partes menores, e essas partes em outras menores ainda, até que se tenham separadas funções, métodos e variáveis. De posse destas, não se pensa na lógica, ou em como o sistema se comporta. Apenas se traduz o informado em uma linguagem de origem para o equivalente em uma linguagem de destino. É necessário que o conhecimento das linguagens de origem e destino seja alto para que as muitas alternativas no momento da migração prevaleçam [SOMMERVILLE 2003]. 8.4.Migração de Código O SAT 1.0 foi migrado obedecendo ora um processo de tradução linha a linha, ora alterando funcionalidades através dos conhecimentos fornecidos pelos especialistas envolvidos, fazendo assim uma conversão de lógica. Nesta reescrita e melhoramento de código, foi criada uma grande estrutura orientada a objetos, que, de acordo com a proposta de cada classe, aproximou do mundo real as funções e métodos do sistema. 8.5.Migração de Banco de Dados Como requisito para o projeto de migração, foi definido que a estrutura do banco de dados, colunas, tabelas, usuários e nomenclaturas adotadas, não fossem alterados. Assim, o processo de migração do Microsoft SQL Server 2000 para o Microsoft SQL Server 2005 Express Edition ocorreu em dois níveis: Quanto ao SGBD: A migração ocorreu de forma automatizada. O Microsoft SQL Server 2005 Express Edition oferece suporte as bases de dados com extensão *.mdf, oriundas do Microsoft SQL Server O carregamento do banco de dados no novo SGBD não gerou 18

19 nenhum tipo de erro ou incompatibilidade. Quanto à camada de acesso a dados: No SAT 1.0 utiliza-se a tecnologia ADO (Acess Data Object) para acessar informações externas. No SAT 2.0 o código para acesso a dados foi completamente reescrito utilizando-se a tecnologia ADO.NET 2.0. O acesso à base de dados se faz utilizando a biblioteca SqlClient do Framework.NET. Esse acesso foi desenvolvido especialmente para funcionar de forma genérica quanto à conexão com o banco de dados utilizado, para uma facilitar numa possível e futura migração de SGBD. 9.Resultados e Discussões Com a finalização da etapa de desenvolvimento/migração do SAT 2.0 vários pontos denotam ganhos na aplicabilidade e operação do sistema como um todo. Esta segunda versão apresenta um código melhor estruturado e mais legível. A aplicação da orientação a objetos inserida no âmbito dos padrões de projeto, neste caso o MVC, deixa o sistema preparado para futuras manutenções e expansão de funcionalidades, ao mesmo tempo em que, todas as funções e métodos foram encapsulados em classes. Com o suporte de compilação do Framework. NET, um dos resultados dessa arquitetura são os arquivos de extensão *.dll que, podem ser reaproveitados e/ou distribuídos a terceiros que se interessem em utilizar as rotinas desenvolvidas para o SAT 2.0. Como resultado da análise e projeto de migração desenvolvida, alguns problemas detectados foram resolvidos. Além disso, a utilização de tecnologias mais modernas na confecção do sistema agrega valores de robustez, visto que, essas fornecem mais quantidade e diversidade de recursos. No aspecto visual, todo o sistema foi reconstruído. Um estudo quanto à usabilidade foi feito e com base neste, uma reestruturação de design foi concebida. Atalhos foram posicionados para um melhor entendimento e navegabilidade. Algumas características de sistemas WEB foram adotadas. O desenho do sistema como um todo foi refeito e adaptado aos moldes atuais do mercado, com maior número de cores (Ver Figuras 5 e 6). Foram implementadas também algumas características que facilitam a utilização do software, não existentes na primeira versão. Sendo algumas destas apresentadas por Nametala (2007): Inclusão de um sistema de backup em disco. Inclusão de uma documentação de ajuda. Inclusão de um pacote de instalação que executa todos os passos necessários para que o SAT 2.0 aloque-se funcionalmente no sistema operacional, sem exigência de configurações adicionais. Implementação em todos os formulários da função de pesquisa dinâmica, onde, de forma automatizada, a pesquisa identifica o item procurado e o apresenta. Adoção de padrão e filosofia de cores para todo o sistema. Estruturando igualmente a apresentação visual de formulários, seguindo o mesmo estilo de posicionamento para componentes. Uma parcela das rotinas focadas no tratamento de exceções foi desenvolvida para operar na camada de apresentação. No campo onde o usuário informar um dado de forma errada, uma marcação visual e uma janela é apresentada. Adaptação automatizada a resolução de tela utilizada no sistema operacional; Modificação na forma de autenticação de usuário. A nova forma adotada permite que usuários de perfis diferentes cadastrem seus dados na memória para um acesso mais rápido. 19

20 Figura 5. Tela principal no SAT 1.0 Figura 6. Tela principal no SAT 2.0 Além desses ganhos computacionais, o SAT 2.0 agrega todas as funcionalidades contidas na primeira versão do sistema. Além dessas funcionalidades, é disposto um novo formulário que executa cálculos de simulação prospectiva, baseando-se na metodologia do cálculo estocástico. Funcionalidade discutida na seção 5 deste artigo. Tanto para as funcionalidades que já existiam na primeira versão do sistema, quanto para as novas funcionalidades implementadas, o SAT 2.0 se mostra de grande potencial na geração de produtos visuais como gráficos, tabelas e relatórios. Estes fornecem ao usuário uma forma concreta e facilitada de interpretar as informações e resultados estatísticos desempenhados num determinado estudo, o que auxilia o usuário a traçar estratégias visando à mitigação de AMTs, sendo assim, um apoio significativo na tomada de decisão. No SAT 2.0 o usuário pode gerar até oitenta e sete tipos de relatórios diferentes, dentre os quais se destacam: 20

21 Gráfico Tridimensional (Figura 7): Informa de forma volumétrica os parâmetros magnitude, duração e freqüência de ocorrências dos AMTs. Figura 7. Gráfico tridimensional Curvas Iso-Sags (Figura 8): Consiste de um gráfico bi-dimensional que relaciona valores de magnitude e duração com valores de freqüências de ocorrências. Figura 8. Curvas Isso-Sags Contribuição de cada linha nos eventos da barra(figura 9): Escolhendo-se uma intensidade na barra monitorada para defeitos, em uma das linhas analisadas, pode-se visualizar um gráfico que, apresenta o número de ocorrências por ano através de barras coloridas. 10.Conclusão Figura 9. Contribuição de Linhas O AMT é um fenômeno real que ocorre em sistemas elétricos e pode causar problemas em cargas elétricas/eletrônicas sensíveis às variações de tensão e pode levar a desligamentos dessas cargas, causando paradas de produção em consumidores industriais, com significativos prejuízos financeiros para os mesmos. As causas desse fenômeno ocorrem, normalmente, nas linhas de transmissão do sistema elétrico de potência. Os estudos dele provenientes são abordados dentro 21

22 da área de QEE, área de suma importância em dias atuais, pois as cargas são cada vez mais sensíveis, exigindo altos níveis de confiabilidade. Este trabalho tem como base um projeto de P&D celebrado entre a Light Serviços de Eletricidade S.A. e a FUPAI gestora de projetos da UNIFEI. Esse projeto visava o desenvolvimento de um software que, com base em simulações, possibilitasse estudos de AMTs com análise retrospectivas e prospectivas de um dado sistema elétrico. A primeira etapa do projeto foi finalizada em 2004 e todas as funcionalidades previstas no escopo foram contempladas. As tecnologias utilizadas foram VB6, SQL Server 2000 e Crystal Reports 10. O paradigma utilizado para construção da arquitetura do sistema foi a Programação Estruturada. Com uma proposta de atualização de paradigmas e tecnologias foi desenvolvida a versão 2.0 do SAT, objetivo principal deste trabalho. Para o processo de migração, propunha-se a conversão do código de VB6 para VB.NET 2005, linguagem integrante do Visual Studio 2005 (VS2005) plataforma.net da Microsoft. Com considerável número de linhas de código, uma ferramenta disponibilizada pelo VS2005 foi utilizada para conversão automatizada entre as diferentes versões de linguagens. A mesma se mostrou ineficaz em virtude de inúmeros erros apresentados na conversão, bem como pela proposta de mudança de paradigma, uma vez que a migração de Programação Estruturada para Programação Orientada a Objetos é apresentada. O uso de propriedades padrão, índice de vetores, dentre outras incompatibilidades entre as linguagens utilizadas foi fator determinante para a maioria dos erros apresentados na conversão automatizada. O uso da ferramenta, assim, foi descartado. A conversão da lógica não é trivial, uma vez que o sistema é complexo e exige grande conhecimento de AMTs. Assim, a tradução do código foi utilizada, com o apoio de um especialista na área, facilitando a nova implementação, permitindo perfeita migração do código, mantendo todas as funcionalidades antes existentes e o paradigma de orientação a objetos aplicado com o padrão de projeto MVC. Uma das propostas da nova versão, prevista para este trabalho, era a migração do banco de dados de uma versão paga para uma gratuita. Essa migração foi realizada com sucesso. Isso se deve ao fato do novo banco de dados o SQL Server 2005 Express Edition ser compatível com o SQL Server Assim, a migração foi feita de forma imediata. Novas funcionalidades foram adicionadas ao SAT 2.0. Novas simulações foram adicionadas: aleatória permitindo a simulação de faltas como em um sistema real, análises prospectivas possibilitando o sorteio de vários parâmetros que levam ao AMT, aplicando em seguida os métodos já existentes no SAT 1.0. Dentre outros, gráficos que expressem mais claramente os resultados das simulações também foram implementados. Ainda, a substituição do Crystal Reports 10 pelo Crystal 11 foi feita de forma transparente. O Crystal Reports 11 é integrado ao VS2005. De forma geral, o sistema teve toda a interface gráfica melhorada, permitindo uma perfeita integração com o usuário. Como era esperado, a interface construída através do VB.NET 2005 permitiu usabilidade mais apurada. O processo de migração de tecnologias e paradigmas foi realizado com sucesso. Todo o projeto previsto, em princípio, foi atendido. 11.Referências [BOLLEN, 2000] Bollen, M. H. J. (2000) Understanding Power Quality Problems: Voltage Sags and Interruptions. IEEE Press. [CAMPBELL, 2005] Campbell, S.; et al. (2005) Visual Basic 2005: Guia Autorizado 22

23 Microsoft. 5. Ed., Elsevier. [CARVALHO FILHO, 2004] Carvalho Filho, J. M. ; Abreu, José Policarpo Gonçalves de ; Rosa Júnior, C. B. ; Carpinteiro, O. A. S. ; Oliveira, T. C. ; Oliveira, F. A.. (2004) A Software for Voltage Sags Strategic Studies. In: XI International Conference on Harmonics and Quality of Power, 2004, Lake Placid. International Conference on Harmonics and Quality of Power. [CEPEL, 1998] CEPEL. (1998) Programa de Análise de Faltas Simultâneas - ANAFAS Versão 3.0. Manual do Usuário. [CUNHA, 2004] Cunha, C. C. M.; Silva, S. R. (2004) Sensibilidade de Acionamentos a Velocidade Variável a Afundamentos de Tensão. Revista Eletricidade Moderna, n.6, p [GAMMA, 1995] Gamma, E.; et al. (1995) Design Patterns: Elements of Reusable Object- Oriented Software. Reading, Mass: Addison-Wesley. [IEEE, 1995] Institute Of Electric And Electronics Engineers IEEE. (1995) IEEE Recommended Practice for Monitoring Electric Power Quality. IEEE Standard [OLIVEIRA, 2004] Oliveira, T. C. (2004) Desenvolvimento e Aplicação de um Sistema de Software para estudos de afundamentos de tensão. 135p. Dissertação de Mestrado (Mestrado em Engenharia Elétrica) Sistema de Potência e Qualidade da Energia Elétrica, Universidade Federal de Itajubá, Itajubá MG. [NAMETALA, 2007] Nametala, C. A. L. (2007) Implementação de um novo paradigma para análise, conversão e expansão de um sistema de software para estudos da qualidade da energia elétrica, envolvendo afundamentos momentâneos de tensão. 117p. Monografia de Conclusão de Curso (Curso de Tecnológica em Análise e Desenvolvimento de Sistemas), Centro Federal de Educação Tecnológica de Bambuí, Bambuí - MG. [QADER, 1999] Qader, M. R..; et al. (1999) Stochastic Prediction Voltage Sags in a Large Transmission System. IEEE Transaction on Industry Applications, v.35, n.1, Fevereiro de [SILVA, 2000] Silva, R. P. (2000) Suporte ao desenvolvimento e Uso de Frameworks e Componentes. PPGC/UFRGS, Porto Alegre, Tese de Doutorado. [SHALLOWAY, 2004] Shalloway, A.; Trott, J. R. (2004) Explicando padrões de projeto: Uma nova perspectiva para o projeto orientado a objetos. Porto Alegre: Bookman. [SOMMERVILLE, 2003] Sommerville, I. (2003) Engenharia de Software. 6. ed. São Paulo: Addison Wesley. [THAI, 2000] Thai, T.; Lan, H. (2000).NET Framework Essencials. Vol 2, E-Book disponível em: < Acesso em: 8 jul [WAGNER, 1990] Wagner, V. E.; et al. (1990) Power Quality and Factory Automation. IEEE Transaction on Industry Applications, v.26, n.4. 23

24 Associations & Rules: a flexible approach to manage aspects conflicts. Sandra I. Casas 1, J. Baltasar García Perez-Schofield 2, Claudia A. Marcos 3 1 UARG, Universidad Nacional de la Patagonia Austral, Rio Gallegos, Argentina. 2 Departamento de Informática, Universidad devigo, Orense, España. 3 Instituto de Sistemas de Tandil, Universidad Nacional del Centro, Tandil, Argentina. lis@uarg.unpa.edu.ar, jbgarcia@uvigo.es,cmarcos@exa.unicen.edu.ar Abstract. The separation of concerns at implementation level with Aspect- Oriented Programming (AOP) tools raises the conflicts among aspects. The conflicts detection and resolution are critical operations. First the detection of conflicts is a manual task in most of the AOP tools, second the resolution of conflicts is enclosed to order-schemes. The AOP tools structures and mechanisms do not always support them in a flexible way. In this work the shortcomings of AspectJ for the handling of conflicts are identified and overcome with Model of Associations. This approach is based on two main abstractions: associations and rules. Associations are aspectual relationships. The rules work with associations. They can be explicit or symbolic. An explicit rule solves a single conflict while a symbolic rule solves a set of conflicts. The rules can apply a variety of resolution categories. The detection of conflict is an automatic process and it is a fundamental part of the resolutions of conflicts. 1. Introduction The Aspect-Oriented Programming [Kiczales G. et al. 1997] raises the level of Separation of Concerns [Dijkstra E., 1976] [Hursch W. and Lopes C., 1995] within the systems. At the same time it also raises the level of conflicts among aspects. A conflict occurs when two or more aspects compete for its activation. The conventional AOP models are inadequate for the handling of conflicts in several situations. Also, most of the AOP tools do not support automatic conflicts detecting and the resolutions mechanisms are restrictive. This is the case of AspectJ [Kiczales G. et al. 2001] tool. The AspectJ aspects are structured to carry out too many responsibilities, which obstruct the handling of conflicts. However, the handling of conflicts with AspectJ [Kiczales G. et al. 2001] is hard for two reasons: the conflicts detection is a manual process and the conflicts resolution 24

25 is restrictive. In this work, the shortcomings of AspectJ are discussed and the Model of Associations is presented. This approach provides a method with a more suitable handling of conflicts. The Model of Associations is based on two mechanisms: the definition of associations and the rules. These strategies have been implemented in the programming environment MEDIATOR, making this approach highly flexible, effective and powerful. This work is structured as follows: Section 2 is dedicated to the analysis of handling of conflicts with AspectJ; in Sections 3 the Model of Associations is presented; in Section 4 the AspectJ problems are solved with this approach; Section 5 exposes the related works; and section 6 presents the final conclusions. 2. Shortcomings of AspectJ In AspectJ [Kiczales G. et al. 2001], the aspects are units of code that encapsulate the crosscutting concern logic. After the aspects are coded, a weaving process integrates the aspects with the components of basic functionality, generating the final application [13]. An aspect is composed of different constructions such as methods, attributes, introductions, declarations, pointcuts, advice, etc. The pointcuts declare a relationship among aspects and components of basic functionality. This structure has been imposed by AspectJ, which is the most diffused, popular and used AOP tool. The AspectJ structure has also been replicated by many other AOP tools. The programming model of AspectJ confers too many responsibilities to aspects. The assumption is that if an aspect is responsible for: (i) encapsulating the logic and behavior of the crosscutting concerns (advice); (ii) establishing the link with components of basic functionality (pointcuts); and (iii) establishing the execution order (declares precedence), probably some of these responsibilities will not be fulfilled very well. In consequence, more flexible possibilities are restricted or limited. In AspectJ, aspects are programming constructs that crosscut the modularity of the basic functional classes of the application in predetermined ways. The mechanism for conflict resolution, provided by AspectJ consists in a very restricted precedence-based scheme (also known as order or priority). In order to execute aspects code in a certain order, it is necessary to specify it with a statement of precedence declaration: declare precedence: A, B;. The semantics means the advices of aspect A will be executed before the advices of aspect B will be. The declare precedence statement presents limitations in the following sceneries: a) After the aspects are implemented, the developers identify that the aspects outline more than one conflict (Figure 1). aspect A { pointcut A1(): call(void CX.met()); Pointcut A2(): execution(void CY.met()); before(): A1() {... } after(): A2() {... } } aspect B { pointcut B1(): call(void CX.met()); pointcut B2(): execution(void CY.met()); before(): B1() {... } after(): B2() {... } } Figure 1. Two different conflicts among aspects A and B. Each conflict requires different order policies. In this case, it is necessary that the advice associated to the pointcut A1 will be executed before that the advice associated to the pointcut B1. In the other hand, it is necessary that the advice 25

26 associated to the pointcut B2 will be executed before that the advice associated to the pointcut A2. This situation is not possible to solve through the mechanism of precedence declarations, due to it is related to the aspects and not to the advice or pointcuts. In this case, the AspectJ solution consists in dividing one of the aspects (A or B) in two aspects, to apply 2 different declare precedence statements. b) The quantification of join-points cause more than one conflict and each conflict requires different execution orders. For example, in Figure 2, the pointcuts A1 y B1 of A and B aspects respectively provoke more than one conflict (supposing CX class have several set methods). aspect A { pointcut A1(): call(* CX.*(..)); before(): A1() {... } } aspect B { pointcut B1(): call(* CX.set*(..)); before(): B1() {... } } Figure 2. The aspects A and B outline different conflicts. In this case, if it is required to apply different order of execution for each conflict, the precedence declaration is insufficient. As the previous scenery, it cannot be defined two or more different precedence declarations that involve the same aspects. c) After that the aspects implementations are carried out, the developers identify that the conflict is outlined by different pointcuts of the same aspect (Figure 3). The precedence declaration does not have effects for advice of the same aspect, the execution order of advice in conflict is indefinite. aspect A { pointcut A1(): call (void CX.met()); pointcut A2(): call (* CX.*(..)); before(): A1() {... } before (): A2 () {... } } Figure 3. A conflict in the same aspect. In this case, the AspectJ solution consists in dividing the aspect A in two aspects to apply the declaration of precedence statement. d) The order of aspect in conflict depends on a condition of the system or of the context. In Figure 4 it is indicated that the advice of aspect A will be executed before than the advice of aspect B if cond is true. Otherwise, it is executed after the advice of the aspect B. if (cond) declare precedence: A, B; else declare precedence: B, A; Figure 4. Declare precedence with conditions. This situation is impossible to implement in AspectJ. The declarations of precedence cannot be defined to conditions. Different declarations of precedence involving the same aspects also cause a compilation error. e) Two or more aspects in conflict are ordered in a particular way in a deployabled application. If these same aspects are used in another application in which the aspects should be executed in a different order, the previous declare precedence 26

27 statement is not valid. In this situation the aspect that contains the declaration of precedence statement should be modified. f) In a deployabled application the whole source code of the aspects must be examined to determine the execution order of the aspects in conflicts. This is due to a declaration of precedence, which involves several aspects, can be part of any of these aspects source code. For example, if the aspects A, B, C are in conflict, the precedence declaration can be defined in the aspect A or B or C or others. The problems indicated in these sceneries force to re-design and to re-implement the aspects in a different way, and impact negatively in the software reuse and maintenance. Because of these restrictions, it is proposed an alternative approach, denominated Model of Associations. 3 Model of Associations To solve the drawbacks discussed in the previous section, a different model is adopted for crosscutting concerns implementation. This approach assigns the responsibilities to different entities. The entities are: aspects, associations and rules. 3.1 Aspects An aspect is an independent unit composed by a group of methods and attributes and encapsulates specific crosscutting concern logic. For example, the Logging aspect (Figure 5) is formed by the loogedoperations(..) method. Aspects are units of code, that they do not declare any crosscut information such as the join-points, pointcuts or advice. aspect Logging { public static void loogedoperations(..) {// send operation information to file or console } } 3.2 Associations Figure 5. Aspect Logging Associations are entities defined in a separated way, instead of being tied to aspects, they link aspects with classes. That is to say, an association describes a relationship between an aspect and a class. For example, in Figure 6 the LogASB association is defined, relating the Logging aspect with the Account class. It establishes that every time that the debit(float amount) method of Account class is invoke and the parameter of the debit method is greater than 100 (the condition is optional), the loogedoperations() method of Logging aspect is executed immediately. In the last line it has been defined a numeric priority for the association (not for the aspect). This priority will be used later on for the handling of the conflicts. Looging.loogedOperations() can be related to other functional components with another priority. The join-point Account.debit(float) can be related to other aspects, other associations will be defined when needed. An association is always a one-to-one relationship. The wildcards are allowed to denote a set of join-points. An additional mechanism transforms this n-to-one relationship in n associations. 27

28 association LogASB { call void Logging.loogedOperations(); after void Account.debit(float $1); condition = ( $1 > 100) ; priority = 10; } association LogAcc { call void Logging.loogedOperations(); after void Account.*(..); priority = 10; } Figure 6. Associations LogASB and LogAcc This approach allows the aspects to be independent of the systems in which they are used and they can be more reusable. Besides, the approach will facilitate the handling of associations in an isolated particular way. From this mechanism, a conflict only happens when two or more associations define the same relationship type for the same functional component. The handling of conflicts must be applied to associations. 3.3 Rules A conflict happens if two or more associations define the same class member, the same relationship cut and relationship advice. For example, in Figure 7 the LogAcc and StatAcc associations are in conflict. Both associations have defined the same crosscutting relationship and advice (call and after) on the same class member (Account.debit(..)). In the Model of Associations, the conflicts among aspects outline about the associations. association LogAcc { call void Logging.consoleOperation(..); after public void Account.debit(..); priority = 10; } Figure 7. Associations in conflict. association StatAcc { call void Statistic.register(..); after public void Account.debit(..); priority = 15; } A resolution rule of conflicts is an entity that defines a resolution action for n (n 1) conflicts (K) of a program, where each conflict (k) is composed by m associations (m 2). A resolution rule is expressed clearly in two parts (Figure 8). The antecedent identifies the group of conflicts that the rule will solve. And the consequent part specifies a precise action of resolution of the associations in conflict. The rules can be explicit or symbolic. R : K(k 1, k 2,..., k n ) // antecedent => AR (k 1 (a 11,..,a 1m ),.., k n (a n1,..,a nm )) // consequent Figure 8. Resolution Rule. The explicit rules require that the antecedent is specified in concrete way. That is to say, it should be indicated the associations in conflict. In the consequent part, these associations are specified as part of the resolution action (Figure.9). ER : k (a 1, a 2, a 3 ) => AR (a 1, a 2, a 3 ) Figure 9. Explicit Rule. Therefore, an explicit rule solves only one conflict. Using this strategy the developer must specify for each existent conflict an explicit rule. In consequence the process of detection of conflicts must be carried out previously. 28

29 The symbolic rules allow to apply a resolution action to subsets of conflicts. The symbolic rules can be absolutely general or partially general. As much as general is the antecedent of the rule, more conflicts will embrace the action of defined resolution in the consequent one. The more specific is the antecedent, the less amount of conflicts will be affected by the consequent of the rule. The specification of a symbolic rule does not require to know or to define the conflict. The conflict will be known at the moment that the rule is applied (Figure 10). SR : <conflict X exists> => AR (apply resolution Y) Figure 10. Symbolic Rule. Where the expression <conflict X exists> is an expression that involves a set of conditions (general or specific). Here X can be all the conflicts, or only some of them. For example, the conflicts on the class Account. In this case, the rule evaluates the antecedent, such as a boolean condition. The expression <apply resolution Y> is a function that applies a resolution action of the conflicts that satisfies the condition. The consequent will assume concrete values of associations after the detection of conflicts. If none of the conflicts satisfies the condition (antecedent), then the action (consequent) is not applied to any association. Since the specification of symbolic rules implies that it is not required to know the existence of the conflict at the moment of its definition. It is necessary some approach that allows to apply the resolution actions to the associations in conflict. This approach is the priority of the associations. All the associations have a priority defined by the developer that will be used for the resolution of conflicts by means of symbolic rules. In Table 1 some examples of explicit and symbolic rules are shown. Table 1. Examples of explict and symbolic rules. Example Rule: R1 Conflict: {a, b, c} Action: order (b, c, a) Rule: R2 Conflict: {a, b, c} Action: if (cond) order (b, a); excluded (c); else annulled (a, b, c); Rule: R3 Conflicts: {conflict over Account class} Action: OBP (b, a) Rule: R4 Conflicts: {all} Action: OBP (b, a) OBP (b, c) OBP (a, c) Rule - Category Rule: Explicit Category: Simple (Order) Rule: Explicit Category: Combined (Optional Order - Exclusion Nullity) Rule: Symbolic. Sub-category: OBP (order by priority the association in conflicts over Account class) Rule: Symbolic. Sub-category OBP (order by priority the association of all conflicts) The resolution action can be simple category: order, optional, order inverse, exclusion or nullity. A combined category provides a resolution action that applies two or more simple category to solve a conflict. The sub-category resolution are: OBP (order by priority), IOBP (inverse order by priority), ELP (excluded less priority), EGP (excluded 29

30 great priority), OF (order first), OL (order last), ETA (excluded this association), EAA (excluded all associations), ANNULLED. The simple and combined category can be used in explicit rules. The sub-category can be used in symbolic rules. 3.4 Detection of Conflict The detection of conflicts is an automatic process in MEDIATOR. This process is independent of the weaving, the compilation and the execution. The defined associations are analyzed to generate a list of conflicts. If two or more associations have the same crosscutting relationship, the same advice relationship and the same functional component (class and method) a conflict is created in the list. A conflict entity has all information about the conflict. On one hand, the developer can define the explicit rules using the list of conflict. On the other hand, an automatic process verifies the list of conflicts against the symbolic rules in order to identify the conflicts that satisfy the condition. When it is satisfied, the system generates for each symbolic rule a set of validate resolution sentences The Weaving Strategy The weaving process integrates the aspects with the classes to build the final application. The objective is to maintain the associations and the logic of resolution of conflicts as separated and isolated as possible from classes and aspects. The proposed strategy requires classes, associations and resolution rules to weave. The aspects are not necessary because all the necessary information for weaving process is defined in the associations and rules. The weaving process proceeds in two stages. First, a linking class is generated automatically in the compilation phase. The methods of this class are denominated in turn, linking methods. These methods relate functional components to aspects, obtaining the information from their corresponding associations. In Figure 11 the link_met1() linking method is shown, generated from the LogAcc association. The link_met1() method invokes the execution of the Logging.loogedOperations() aspect method, defined in the LogAcc association. association LogAcc { call void Logging.loogedOperations(); after void Account.debit($2); condition = ($2 >100) priority = 10; } class Link_Class { public void static link_met1($2) { if ($2 >100) Logging.loogedOperations(); } } // end linking class Figure 11. Linking method generated from LogAcc association. The previous example is valid for associations free of conflicts. When the associations to weave are in conflict, the process is carried out in a similar way. In the first phase the objects that represent resolution rule are also required. The linking method concentrates the logic of resolution of conflict. For example, if LogAcc and StatAcc associations are in conflict and the action of explicit rule is (order (LogAcc, StatAcc)), then in the compilation phase, both associations are merged in a unique linking method. The method encapsulates the logic of resolution of the conflict. In 30

31 Figure 12, the link_met2() linking method has been automatically generated starting from the action of explicit rule and LogAcc and StatAcc associations. } void static link_met2( ) { Logging.loogedOperations(); Statistic.register(); Figure 12. Linking method of associations in conflict. The second phase proceeds during the execution of the application. In load-time, those classes affected by the associations are linked to the linking methods according to the type of relationship. This process has been implemented by means of the Javassist API [Chiva S., 1998]. Before the weaving process execution, two automatic processes are executed. First, the system checks the existence of rules interferences. The interference between rules happens when an explicit rule and a symbolic rule are applied to the same conflict, and each rule orders different resolution actions to solve the conflict. Then the system solves the interference using previous configurations of the rules mechanism. This configuration is defined by the developer initially. Second, the resolution sentences which are generated by the execution of the symbolic rules, are transformed in explicit rules. For example, if a symbolic rule solves 3 conflicts, then 3 explicit rules are created. The weaving process works with explicit rules. In summary, in the functional components affected by some association are inserted a call to a linking method, according to the type of relationship (before - after) of the associations (on load the bytecode modification is not permanent). The linking method invokes the aspect method directly, or it can include a group of sentences that apply a category of conflict resolution. Therefore, the following advantages are obtained: (i) the classes do not have any knowledge about what aspects crosscut them; (ii) the aspects preserve their original state and they can be associated to any other functional components; (iii) the conflicts resolution is hidden in the linking class, being specific for a certain application, and finally, (iv) if a new association or rule is defined it is only necessary to generate the linking class, it is not necessary to compile the other units (classes and aspects). 4. Solving Problematic Situations. The solutions with Model of Associations to AspectJ restrictions (expressed in Section 2) are presented bellow. a) Two aspects outline more one conflict. Each conflict requires different resolution policies. This situation is easy to solve in Model of Associations, the developer must specify explicit or symbolic rules that apply different resolution actions, over the associations in conflict. In Figure 13, the Logging and Statistic aspects outline two conflicts, (LogAcc, StatAcc) and (LogBor, StatBor). The explicit rule R1 applies a resolution on conflict (LogAcc, StatAcc) and the explicit rule R2 applies different resolution to another conflict (LogBor, StatBor). In this case, it has not been necessary to re-design or re-implement the aspects. Simply different rules are declared to solve the conflicts. 31

32 association LogAcc { call Logging.console(); after void Account.debit(float ); } association LogBor { call Logging.console(); after void Borrow.cancel( ); } Rule: R1 Condition: {LogAcc, StatAcc} Action: order (LogAcc, StatAcc); association StatAcc { call Statistic.register(); after void Account.debit(float); } association StatBor { call Statistic.register(); after void Borrow.cancel(); } Rule: R2 Condition: {LogBor, StatBor} Action: order (StatBor, LogBor); Figure 13. Solving two different conflicts among aspects A and B. b) Two associations provoke more than one conflict because of the use of quantification of join-points and each conflict can be solved in isolation by a rule. In the Model of Associations it is possible; because of the n-to-one associations are automatically converted in n associations. In Figure 14, the Log and Stat associations use quantification, after they are converted in associations Log1, Log2, Stat1 and Stat2. Two conflicts arise from this situation: (Log1, Stat1) and (Log2, Stat2). The developer can define two different rules to solve these conflicts. association Log { call Logging.console(); after * Account.*(..); } association Log1 { call Logging.console(); after int Account.getId(); } association Log2 { call Logging.console(); after String Account.getName(); } association Stat { call Statistic.register(); after * Account.*(..); } association Stat1 { call Statistic.register(); after int Account.getId(); } association Stat2 { call Statistic.register(); after String Account.getName(); } Figure 14. Conflicts and quantification. c) The same aspect outlines a conflict and it is required the application of a specific resolution. This situation is easy to solve in Model of Associations, the developer must specify an explicit or symbolic rule for the associations in conflicts. For example in Figure 15, the Log1 and Log2 associations are in conflict and they make reference to the same aspect (Logging). The rule R5 can be defined to solve this conflict. association Log1 { call void Logging.console(); after int Account.getId(); } Rule: R5 Condition: {Log1, Log2} Action: order (Log2, Log1); association Log2 { call void Logging.File(); after int Account.getId(); } Figure 15. A conflict in the same aspect. 32

33 d) The order of aspects in conflict depends on a condition of the system or of the context. This situation is easy to solve in Model of Associations, the developer has to specify an explicit rule where the action of resolution applies an optional category. For example in Figure 16, the statistic operation only is performed if the parameter of debit method is greater than value 100. association LogAcc { call void Logging.console(); after void Account.debit(float); } Rule: R6 Condition: {LogAcc, StatAcc} Action: if ($2 > 100) order (StatAcc, LogAcc); else excluded (StatAcc); association StatAcc { call void Statistic.register($2); after void Account.debit(float); } Figure. 16. The resolution of conflict depends of a condition. e) The same conflicts require different policies of resolution in each application. This situation is easy to solve in Model of Associations. The developer must specify different rules for each application and it is not necessary to modify the aspects. In Figure 17 the same conflict is solved in different ways for each applications. The developer only has to re-define the rule R5. The developer does not have to re-define the aspects. Rule: R5 Application 1 Application 2 Application 3 Condition: {LogAcc, StatAcc} Action: Order(LogAcc,StatAcc) Rule: R5 Condition:{LogAcc, StatAcc} Action: order(statacc,logacc) Rule: R5 Condition: {LogAcc, StatAcc} Action: excluded(statacc) Figure 17. Different policies of resolution for the same conflict. f) If the developer needs to know the execution order of the aspects in conflict (in a deployabled application) he/she only must edit the rules or the linking class. 5. Related Work Several works have been developed in order to detect and solve conflicting situations among aspects. The first directly related work with the detection and resolution of conflicts seems to be [Douence R. et al. 2002]. The authors hold that the treatment of the conflicts among aspects should be carried out in a separated way from the aspects definition. The programmer solves the interactions using a dedicated composition language. The solution is based on a generic framework for AOP that is characterized by a very expressive language of crosscutting cuts, static conflicts analysis and a linguistic support for the resolution of conflicts. An approach to detect and to analyze the conflicts caused by the capacities of AspectJ is presented in [Storzer M. and Krinkle J., 2003]. This approach provides mechanisms to modify the hierarchical structure of the classes (declaration declares parents) and to introduce new members to the classes (methods and attributes). This 33

34 work is based on traditional techniques of programs analysis and it is only led to the detection of a class of conflicts. An analysis model to detect conflicts among crosscutting concerns is presented in [Tessier F. et al. 2004]. The purpose of the authors is to identify the interactions among aspects during the modelling, and to provide a formal method that allows developers to detect the conflicts by means of successive refinements. The main objective is to achieve the detection of conflicts as soon as possible (early detection of conflicts) and to offer certain level of prediction of the generated impact by the insert of new aspects. This work is restricted to the detection of the conflict, in spite of being carried out in early stages of the development. A precedence model of AspectJ (sequential), used to establish the execution order of advice, when they are associated to the same join-point is improved and optimized in [Yu Y. and Kienzle J., 2004]. The representation of the model in a precedence graph, leads to a model of concurrent precedence. This work tries to improve the conflict resolution mechanism especially for AspectJ. LogicAJ [ROOTS, 2005] provides interferences aspect-aspect analysis for AspectJ that includes capacities for: (a) identifying a well defined interferences class, (b) determining the execution order free of interference, (c) determining the weave algorithm more convenient for a group of given aspects. The analysis of interferences is independent from the base programs to those that the aspects are referred to and independent from the aspect analyzer s additional annotations. Programme Slicing is a technique that aims to the extraction of program elements related to a computation in particular. This approach is proposed to analyze the interactions among aspects, since it can reduce the code parts that are needed to analyze in order to understand the effects of each aspect [Monga M. et al. 2003]. A very interesting work is Reflex [Tanter E. and Noye J., 2005], a tool that facilitates the implementation and composition of different aspect oriented languages. This work proposes a model which provides a high level of abstraction to implement the new aspect languages and to support the detection and resolution of conflicts. Reflex consists basically of a kernel with 3 layers architecture: (1) a layer of transformation in charge of the basic weave with support for the structural modification and of behavior of base programs; (2) a composition layer for the detection and resolution of interactions and (3) a language layer, for the definition of the aspect language modulation. The detection of interactions follows the outline proposed for [Douence R. et al. 2002] and it is a static approach. The interactions are not detected at execution time. There are two ways of solving an interaction: (1) to choose of the interactions the aspect that will be applied in the execution (2) to order and to nest the aspects for the execution. This work advances that an AOP tool should manage conflicts and consequently it provides a specific layer of the kernel for this purpose. A way to validate the orders of precedence formally, (the orders between aspects that share join-points), is presented in [Pawlak R. et al. 2005]. This work introduces a small language, CompAr, in which the user expresses the effect of the advice that is important for aspect interaction, and properties that should be true after the execution of the advice. The CompAr compiler checks a given advice order, that does not invalidate a property of an advice. 34

35 An interaction analysis based on Composition Filters is proposed in [Durr P. et al. 2005]. In this work it is detected when one aspect prevents the execution of another, and can check that a specified trace property is ensured by an aspect. The use of rules as strategy or mechanism for handling of conflicts has been proposed in several recent works. [Kessler B. and Tanter E., 2006] presents a logicbased initial exploration where facts and rules are defined for the detection of interactions in Reflex. In [Nagy I. et al. 2006], it is proposed a constraint-based, declarative approach to specify the composition of aspects which share join-points. The implementation of this model requires the extension of AOP Language in several aspects: join-point constructs, advice constructs, declarations statements, etc. The restrictions of AOP Languages, such as the precedence statement of AspectJ, are not overcome. Because of the resolutions are applied in the body of the aspects. The Model of Interactions [Charfi A. et al. 2006] is similar to the Model of Associations. The authors proposed to represent the aspects such as components and the aspectual relationships in Interaction units. The Interactions are a mixture of associations and explicit rules. An Interaction Specification Language (ILS) is provided. This language provides a set of operators, which defines weaving rules ( merging"). The operators apply different resolutions to the conflicts: conditional execution, mutual exclusion and order, and the sequential or concurrent composition. All the interactions on the shared join-points are mixed in an only interaction (it unifies advice after and before). The interactions are defined in singular form, after an automatic mixture process generates the final interaction. Another similar approach is Aspect-Markup Language (AML) [Lopes C. and Ngo T., 2004]. In AML, an aspect-oriented program consists of three elements: core modules, aspectual modules and aspect bindings. Core and aspectual modules are developed in the base language; these entities are similar to classes and aspects in MEDIATOR. The aspect bindings are specified in AML, and are similar to a set of associations. All aspectual relationship (pointcuts, advice, etc.) related with an aspectual module are encapsulated in an aspect binding. Aspect binding is XML-based binding specification. It is provided binding instructions that determine how core and aspectual modules are unambiguously composed to produce the final behaviour. In general, an aspect binding file contains a mixture of predefined XML elements called core elements and user-defined XML elements called custom elements. The authors do not highlight specific syntactic and semantic mechanisms for handling of conflict. 6. Conclusions and Future Work In this article a novel approach to develop aspect-oriented application has been presented. The Model of Associations is based on following premises: (i) the crosscutting concerns logic is implemented in aspect units; (ii) the mechanics to relate the aspects with functional components (pointcuts, advise, join-point) are defined in associations; (iii) the conflict resolutions are declared in rules. These strategies allow us to improve the handling of conflicts and the aspects reuse. The weaving strategy makes the code of aspects and classes (source and compiled) remain intact. They are contaminated neither by the associations, nor by the conflicts resolution applied. These features make this approach flexible, effective and powerful in order to handle the conflicts. 35

36 In Section 2, it is identified several sceneries in which the AspectJ model presented severe restrictions to handle conflicts. In this work all these problems are solved using Model of Associations. The implementation of Model of Associations supports the use of wildcards and the passing of the context in the associations. The main limitation of the implementation of our approach is that it does not support aspects instances. The future work is addressed to apply the Model of Associations to real dynamic context. Now we are exploring the possibilities on dynamics language. This work was partially supported by the Universidad Nacional de la Patagonia Austral, Santa Cruz, Argentina and Research Project PICT (ANPCYT). References Charfi A., Riveill M., Blay-Fornarino M., Pinna-Dery A. (2006) Transparent and Dynamic Aspect Composition, Workshop on Software Engineering Properties of Languages and Aspects Technologies, VII AOSD Germany Chiva S. (1.998) Javassist A Reflection based Programming Wizard for Java. Proceeding of the ACM OOSPLA. Workshop on Reflective Programming in C++ and Java. Canada. Dijkstra E. W. (1.976) A Discipline of Programming. Prentice Hall. Douence R., Fradet P. and Südholt M. (2.002) Detection and Resolution of Aspect Interactions. TR Nº4435, INRIA, ISSN , France. Durr P., Staijen T., Bergmans L. and Aksit M. (2.005) Reasoning about semantic conflicts between aspects. In K. Gybels, M. D Hondt, I. Nagy, and R. Douence, editors, 2nd European Interactive Workshop on Aspects in Software. Hursch W. and Lopes C. (1.995) Separation of Concern. TR. NU-CCS-95-03, Northeastern University. Kessler B. and. Tanter E. (2.006) Analyzing Interactions of Structural Aspects. Workshop AID in 20th. European Conference on Object-Oriented Programming (ECOOP). France. Kiczales G., Hilsdale E., Hugunin J., Kersten M., Palm J. and Griswold W. (2.001) An Overview of AspectJ. In J. L. Knudsen, editor, Proceedings of the 15th European Conference on Object-Oriented Programming (ECOOP), Num in LNCS, pp , Springer-Verlag. Hungary. Kiczales G., Lamping J., Mendhekar A., Maeda C., Lopes C., Loingtier J. and Irwin J. (1.997) Aspect-Oriented Programming. In Proceedings of the 11th European Conference on Object-Oriented Programming (ECOOP), Finland. Lopes C. and Ngo T. (2004) The Aspect Oriented Markup Language and its Support of Aspect Plugings, Technical Report # UCI-ISR-04-08, Institute for Software Research University of California. 36

37 Monga M., Beltagui F. and Blair L. (2.003) Investigating Feature Interactions by Exploiting Aspect Oriented Programming. TR N comp-002- Lancaster University, England. Nagy I., Bergmans L. and Aksit M. (2.006) Composing Aspects at Shared Join Point. Workshop AID in 20th. European Conference on Object-Oriented Programming (ECOOP). France. Pawlak R., Duchien L., and Seinturier L.(2.005) CompAr: Ensuring safe around advice composition. In FMOODS 2.005, Vol of LNCS, pp Piveta E. and Zancanella L.(2.003) Aspect Weaving Strategies. Journal of Universal Computer Science, Vol.9, Num. 8. Pryor J., Diaz Pace A. and Campo M. (2.002) Reflection on Separation of Concerns. RITA. Vol.9. Num.1 ROOTS (2.005) LogicAJ A Uniformly Generic and Interference-Aware Aspect Language. Storzer M. and Krinkle J. (2.003) Interference Analisys for AspectJ. FOAL: Foundations of Aspect-Oriented Languages, USA. Tanter E. and Noye J. (2.005) A versatile kernel for multi-language AOP. In Proceedings of the 4th ACM SIGPLAN/SIGSOFT Conference on Generative Programming and Component Engineering, Vol of LNCS, pp , Springer-Verlag. Estonia. Tessier F., Badri M. and Badri L. (2.004) A Model-Based Detection of Conflicts Between Crosscutting Concern: Towards a Formal Approach. International Workshop on Aspect Oriented Software Development, China. Yu Y. and Kienzle J. (2.004) Towards an Efficient Aspect Precedence Model. Proceeding of the Dynamic Aspects Workshop, pp , England. This work was partially supported by the Universidad Nacional de la Patagonia Austral, Santa Cruz, Argentina. 37

38 Niveles de Riesgo de Conflictos en AspectJ: una propuesta basada en el pasaje del contexto Sandra I. Casas 1 y Claudia Marcos 2 1 Unidad Académica Río Gallegos, Universidad Nacional de la Patagonia Austral Río Gallegos, Argentina, Instituto de Sistemas de Tandil, Universidad Nacional del Centro Tandil, Argentina, 7000 lis@uarg.unpa.edu.ar, cmarcos@exa.unicen.edu.ar Abstract. En el desarrollo de software orientado a aspectos, dos o más aspectos pueden plantear un conflicto. En ciertos casos esta interacción provoca un comportamiento impredecible e inestable del software. Este trabajo propone un método de detección y estimación de niveles de riesgo de conflictos específica para AspectJ. El pre-procesamiento del código fuente de los aspectos facilita estas operaciones. La estimación de los riesgos esta basado en el uso y modo del contexto en los aspectos. De esta forma los riesgos se clasifican en distintos niveles. 1. Introducción La Programación Orientada a Aspectos [Kiczales et al. 1997] (POA) es un nuevo enfoque para el desarrollo de software que proporciona mecanismos y abstracciones para la implementación de los crosscutting concerns (requerimientos no funcionales y transversales) de manera separa y aislada. La orientación a aspectos, es una técnica que permite aplicar el principio de Separación de Concerns (SoC) [Dijkstra 1976][Hursch and Lopes 1995]. La POA propone la encapsulación de los crosscuting concerns en unidades de código denominadas aspectos. Los aspectos incluyen mecanismos sintácticos y semánticos que permiten su posterior composición con el código de funcionalidad básica. La composición es realizada por un proceso denominado tejido, que puede ser estático o dinámico [Piveta and Zancanela 2003]. Los dispositivos de invocación y extensión aspectual [Hanenberg and Unland 2001] son implícitos, permitiendo que los aspectos se diseminen y mezclen transversalmente en los módulos de funcionalidad básica. Desde esta perspectiva dos o más aspectos pueden cortar transversalmente el mismo módulo de funcionalidad básica. Esta situación se conoce como conflicto entre aspectos, también denominado interacción [Tanter and Noye 2005] o interferencia [Katz and Rashid 2004]. En ciertos casos estas interacciones, pueden provocar un comportamiento impredecible del software. De esta manera, surgen los 38

39 conflictos entre aspectos y la necesidad de construir mecanismos y estrategias para su adecuado tratamiento. El presente trabajo aborda la problemática de conflictos entre aspectos y propone un método de detección y estimación de riesgos de conflictos específica para AspectJ [AspectJ 2008][Kiczales et al. 2001]. El método esta basado en el análisis de la estructura de los pointcuts y las primitivas que permiten capturar el contexto de ejecución de los join-points. La detección de conflictos y la posterior estimación de los niveles de riesgos de los mismos se realizan mediante el pre-procesamiento del código de los aspectos. El presente trabajo se estructura de la siguiente manera: en la Sección 2 se describe brevemente AspectJ y los conflictos entre aspectos en dicha herramienta; en la Sección 3 se explica el método aplicado para la detección de conflictos; en la Sección 4 se expone los niveles de riesgo de conflictos y el procedimiento de cálculo de los mismos; en la Sección 5 se presentan los trabajos relacionados y en la Sección 6 las conclusiones. 2. AspectJ y Conflictos Un aspecto constituye en AspectJ [AspectJ 2008][Kiczales et al. 2001], la unidad modular o constructor que representa un tipo entrecruzado al cortar las clases, interfaces y a otros aspectos mejorando la SoC. Un aspecto es un conjunto de pointcuts, advices, introducciones, métodos y atributos. Para el presente trabajo, interesan en particular los constructores denominados crosscutting dinámicos. Estos modifican el comportamiento de la ejecución de un programa, en AspectJ se denominan pointcuts y advices. AspectJ provee un conjunto de cortes primitivos (call, execution, set, get, handler, etc.) que indican la semántica del corte (captura) del join-point y determinan la estructura de los pointcuts. Los pointcuts se asociacian a los advices que pueden ser: before, after y around. Un pointcut no solo captura la ejecución de un join-point, también puede exponer parte de la ejecución del contexto del join-point. Los valores expuestos por el pointcut pueden ser utilizados en el cuerpo del advice, mediante pasaje de parámetros. Las primitivas para exponer el contexto en AspectJ son: target, this y args. En la Figura 1 se capturan todas las llamadas al método m() de la clase A. La primitiva target permite capturar en la referencia obj, el objeto receptor del mensaje enunciado en el join-point. obj puede ser manipulado como se desee en el cuerpo del advice. La primitiva this permite captura el objeto actual (esto es cuando el join-point comienza su ejecución) y la primitiva args permite capturar los argumentos del join-points. before (A obj) : call (void A.m() && target (obj)); Figura 1. Advice y pointcut en AspectJ. Un conflicto puede ocurrir cuando dos o más aspectos compiten por su activación [Pryor et al. 2002]. Al analizar las potenciales situaciones conflictivas que pueden ocurrir en particular en AspectJ, se establece que existe un potencial conflicto sí dos o más aspectos definen pointcuts, cuyos cortes coinciden en tipo de corte y joinpoints, los cuales además están asociados al mismo tipo de advice. La Figura 2 presenta los aspectos A y B los cuales están en conflicto. 39

40 aspect A { before():call(void A.m()); {... } } aspect B { before():call(void A.m()); {... } } Figura 2. Conflicto de Semejanza Total entre los aspectos A y B. 3. Detección de Conflictos La detección de conflictos tiene por objetivo la identificación de conflictos y la generación de información útil para su análisis y resolución. Este proceso puede ser una tarea sencilla si la aplicación maneja una reducida cantidad de unidades (clases y aspectos), pero la complejidad de la tarea crece en la medida que aumentan las unidades componentes de la aplicación. En estos casos, el desarrollador debe ser informado y poder controlar estas potenciales situaciones para determinar la ejecución deseada de acuerdo al tipo de conflicto y/o el dominio de la aplicación, determinando las prioridades y políticas de activación de los aspectos. En AspectJ la declaración de los pointcuts se estructura en 2 partes: (a) (b) call(void A.m(..)) && target(a) && args(..) Donde: (a) captura del join-point y (b) captura del contexto del join-point. La información de (a) se utiliza para detectar el conflicto y la información de (b) para estimar el nivel de riesgo más adelante. Esta información puede ser obtenida mediante pre-procesamiento del código de los aspectos. Los pointcuts de los aspectos son mapeados en una tabla que contiene la siguiente información: PointcutTable = {(ASPECT, POINTCUT, PRIMITIVE-CUT, JOIN-POINT, ADVICE, this, target, args, R/W)} En la Figura 3 se indica como ejemplo el mapeo del aspecto Asp en la tabla dinámica. aspect Asp { pointcut p1 (int i): call (void A.methodX(int) && args (i)); pointcut p2 (A obj, int i): execution void A.methodY(int) && this(obj) && arg(i)); before(int i) : p1(i) { } void around(a obj, int i) : p2(i) { } after() : set (int A.atributeX()); {. } } Asp p1 call A methodx before false false true R Asp p2 execution A methody around true false true W Asp set A atributex after false false false - Figura 3. Mapeo del aspecto Asp en la tabla de pointcuts. 40

41 En este caso el mapeo crea 3 entradas en la tabla dinámica, uno por cada pointcut (p1, p2 y el pointcut anónimo). Aquí los pointcuts se componen sólo de un corte primitivo (call, execution, set) sobre join-points definidos por extensión (void A.metodoX(), void A.metodoY(), int A.atributoX). Las informacion registrada en las últimas cuatro columnas se genera cuando se mapea el aspecto, pero será empleada para la estimacion del riesgo. La última columna de la tabla describe el uso del contexto en el cuerpo del advice. Este será R (read) si el contexto sólo es leído y será W si el contexto es modificado. En AspectJ un pointcut se puede definir por la composición de varios cortes primitivos (utilizando los constuctores &&, y! ), además los join-points se pueden definir por comprensión, mediante el uso de comodines ( * y.. ). En estos casos, el mapeo de un aspecto no será tan lineal como el ejemplo, es decir un join-point puede producir más de una entrada en la tabla de pointcuts. Previamente al mapeo, cada pointcut es analizado y se determina el conjunto de entradas que produce en la tabla. Luego que todos los pointcuts de todos los aspectos han sido mapeados en la tabla, un algoritmo verifica la existencia de conflictos y a continuación se procede a estimar el nivel de riesgo de cada uno. 4. Niveles de Riesgos de Conflictos Las operaciones de detección y resolución de conflictos adquieren mayor importancia cuando el conflicto produce un comportamiento anómalo del software. Las posibilidades de que un conflicto provoque un comportamiento anómalo aumentan cuando los pointcuts exponen el contexto de los join-points, para que éstos sean manipulados en los advice. Es decir, si los aspectos modifican el estado del contexto de manera no coordinada y/o desordenada durante la ejecución del software, ciertas variables pueden asumir un estado impredecible e inestable durante la ejecución. La información de la tabla generada para la detección de conflictos provee suficiente información para estimar los riesgos asociados a cada conflicto. Como se explicó anteriormente, en AspectJ existen tres formas de exponer el contexto (target, this y args), en principio se mide el uso del contexto por cada elemento que esta en conflicto, de acuerdo a la Tabla 1. Tabla 1. Usos del Contexto. Ejemplo Uso de contexto Descripción pointcut p () : call (A.m(int)); N/C No se usa el contexto pointcut p (A ref) : call (A.m(int)) && Usa una parte del target (ref); Parcial contexto pointcut p (A ref) : execution (A.m(int)) Usa una parte del && this (ref); Parcial contexto pointcut p (int n) : call (A.m(int)) && Usa una parte del args (n); Parcial contexto pointcut p (A ref, int n) : call (A.m(int)) && Total Usa todo el contexto target (ref) && arg (n); pointcut p (A ref, int n) : execution (A.m(int)) && this (ref) && arg (n) ; Total Usa todo el contexto 41

42 Si el uso del contexto es parcial o total, además se requiere conocer el modo de uso. Este será de lectura (R) o escritura (W). Luego, de acuerdo al modo en que se emplee el contexto, los niveles de riesgo de un conflicto pueden ser: nulo, bajo, medio o alto. Las siguientes situaciones determinan el nivel de riesgo de un conflicto entre aspecto en AspectJ: Nivel de Riesgo Nulo: El nivel nulo implica que el conflicto no conlleva ningún riesgo y por ende no requiere una resolución. Este nivel de riesgo se produce cuando al menos uno de los aspectos no usa el contexto. En la Figura 4 se esquematiza al conflicto mediante un árbol and-or, en el cual las ramas representan cada uno de los aspectos y los posibles usos y modos del contexto que conducen a este nivel de riesgo. Nivel de Riesgo Bajo: Un conflicto tiene nivel de riesgo bajo, cuando ambos aspectos usan el contexto para lectura. En la Figura 5 se esquematiza el árbol and-or para esta situación. Este nivel de riesgo denota que a pesar de que la ejecución de los aspectos requiera una secuencialidad sí esta no se respetará no ocasionará un comportamiento inestable del software. Nivel de Riesgo Medio: A un conflicto le corresponde nivel de riesgo medio si uno de los aspectos usa el contexto para lectura y el otro aspecto lo usa para escritura, como se representa en la Figura 6. En este nivel de riesgo, la ejecución de los aspectos requiere una secuencialidad preestablecida que debe ser respetará, en consecuencia el desarrollador debe definir una acción de resolución especifica. Nivel de Riesgo Alto: El nivel de riesgo alto, es el más peligroso y requiere una intervención del desarrollador, ya que en este caso los aspectos en conflicto modifican el contexto, como se grafica en la Figura 7. Dado que diferentes órdenes de ejecución pueden provocar un comportamiento inestable del sistema, este nivel de conflicto requiere resolución explícita. Figura 4. Arbol and-or para conflictos de nivel nulo. Figura 5. Arbol and-or para conflictos de nivel bajo. 42

43 Figura 6. Arbol and-or para conflictos de nivel medio. Figura 7. Arbol and-or para conflictos de nivel alto. Los casos analizados se mapean en una tabla de doble entrada que para dos aspectos en conflicto presenta 25 posibilidades, las cuales se representan en la Tabla 2. Tabla 2. Niveles de riesgos. A 1 N/U PARCIAL TOTAL W R W R N/U NULO NULO NULO NULO NULO PARCIAL R NULO MEDIO BAJO MEDIO BAJO W NULO ALTO MEDIO ALTO MEDIO TOTAL R NULO MEDIO BAJO MEDIO BAJO W NULO ALTO MEDIO ALTO MEDIO A 2 Entonces, luego que se detectan los conflictos, se aplica la Tabla 2 para estimar el nivel de riesgo de los mismos. 4.1 Conflictos N Un conflicto N ocurre cuando n aspectos plantean el conflicto y n > 2. En estos casos la detección de conflictos se realiza de la manera indicada pero el cálculo de riesgos requiere de un proceso de reducción previo. A continuación se describe el algoritmo de reducción: aquí n es la cantidad de aspectos en conflicto. Paso 1: r aspectos del conflicto cuyo uso del contexto es N/C n n - r Si n 1 nivel de riesgo NULO - Fin Si n = 2 nivel de riesgo aplicar Tabla 2- Fin Si n > 2 hacer Paso 2 Paso 2: r aspectos del conflicto cuyo uso del contexto es R n n - r Si n = 0 nivel de riesgo BAJO - Fin Si n = 1 nivel de riesgo MEDIO - Fin Si n > 1 nivel de riesgo ALTO - Fin 43

44 A continuación se presentan dos ejemplos sencillos del proceso de reducción. El primero (Figura 8) presenta un conflicto planteado por tres aspectos en el cual uno de ellos no usa el contexto. Luego de aplicar el paso 1, se aplica la tabla 2 y el conflicto resulta tener un nivel de riesgo MEDIO. Figura 8. Reducción en Conflictos N. El segundo ejemplo (Figura 9), también consiste en tres aspectos, luego de aplicar el paso 1, no encuentra resolución por lo que requiere aplicar el paso 2. Luego resulta que el conflicto corresponde al nivel de riesgo MEDIO. Figura 9. Reducción en Conflictos N. 5. Trabajos Relacionados El trabajo de investigación en cuanto a conflictos entre aspectos, se ha dirigido principalmente en los procesos de detección y resolución de conflictos, menor atención ha recibido la estimación de los mismos. [Duence et al. 2002] proponen una solución basada en un framework genérico para POA, que se caracteriza por un lenguaje de cortes cruzados muy expresivo, análisis de conflictos estáticos y un soporte lingüístico para la resolución de conflictos. LogicAJ [ROOTS 2005] provee análisis de las interferencias aspecto-aspecto para AspectJ que incluye capacidades para: (a) identificar una clase bien definida de interferencias, (b) determinar el orden de ejecución libre de interferencia (c) determinar el algoritmo de tejido más conveniente para un conjunto de aspectos dado. El análisis de interferencias es independiente de los programas base a los que los aspectos se refieren (solo los aspectos son necesarios para el análisis) e independiente de anotaciones especiales del analizador de aspectos. Este trabajo solo enfoque el problema de la detección de conflictos. Astor [Casas et al. 2005] es un prototipo que propone una serie de mecanismos y estrategias para mejorar el tratamiento de conflictos en AspectJ. Los mismos se soportan mediante la adición de un componente Administrador de Conflictos que cumple principalmente con las funciones de detectar automáticamente conflictos y aplicar estrategias de resolución más amplias que las que AspectJ tiene por defecto, en forma semiautomática. La detección de conflictos actúa por una clasificación de los mismos por niveles de semejanza y la resolución se efectúa siguiendo las directrices de una taxonomía que proporciona seis categorías de resolución [Pryor and Marcos 2003]. 44

45 La implementación del prototipo esta basada en el pre-procesamiento de código AspectJ, siendo además éste el único requisito para su uso. Programme Slicing es una técnica que apunta a la extracción de elementos de programa relacionados a una computación en particular. Este enfoque es propuesto para analizar las interacciones entre aspectos, ya que puede reducir las partes de código que se necesitan analizar para entender los efectos de cada aspecto. [Monga et al. 2003] Este trabajo solo da cobertura al problema de la detección. Los Filtros de Composición se utilizan para analizar interacciones en [Durr et al. 2005]. En este trabajo se detecta cuando un aspecto precede la ejecución de otro aspecto, y se chequea que una propiedad especificada de traza sea realizada por un aspecto. En [Kessler and Tanter 2006] se presenta una exploración inicial basada en programación lógica donde los hechos y reglas son definidos para la detección de interacciones en Reflex. Un modelo formal para la detección de conflictos directos y estimación del impacto, en la etapa diseño del desarrollo es presentado en [Tessier et al. 2004]. La identificación de conflictos se realiza a través de información generada a partir del diagrama de clase de UML extendido, que incluye aspectos y sus conexiones con las clases. Información tal como pointcuts, join-points, advice es mapeada en tablas que permiten que un algoritmo identifique todas las posibles relaciones entre las clases y aspectos. A partir del tipo de relación se obtiene una predicción del impacto del conflicto y se genera una recomendación. El propósito de los autores es identificar las interacciones entre aspectos en la fase de modelado, y proporcionar un método formal que mediante refinamientos sucesivos permita detectar los conflictos. El objetivo principal es lograr la detección de conflictos lo antes posible (detección temprana de conflictos) y ofrecer cierto nivel de predicción del impacto generado por la inserción de nuevos aspectos. Las inconvenientes de este trabajo son: (i) la información utilizada para la predicción del impacto es manual, en las tablas se agrega por cada pointcutsadvice el tipo de operación (modificación o acceso), (ii) el modelo genera información redundantes, que para un ejemplo simple no resulta confusa, pero en un caso real complica el análisis del desarrollador y (iii) la información de diseño no es suficiente para la detección y requiere de refinamientos sucesivos que derivan en el análisis estático en la implementación. 6. Conclusiones El presente trabajo propone un método de detección y estimación de niveles riesgos de conflictos entre aspectos, específico para AspectJ. El código fuente de los aspectos es pre-procesado para obtener información de los pointcuts y advice que es empleada para la detección y estimación de riesgo de los conflictos. Los niveles de riesgo de los conflictos se determinan de acuerdo al uso del contexto de los aspectos en conflictos, y estos se clasifican según su estructura en n/c, parcial o total. Se tiene en cuenta además el modo en que el contexto es empleado en los advice, si el mismo es de lectura o escritura. Según esta clasificación los conflictos presentan diferentes niveles de riesgo: nulo, bajo, medio o alto. Esta información ayuda al desarrollador en la resolución de conflictos. 45

46 El presente trabajo fue parcialmente financiado por la Universidad Nacional de la Patagonia Austral, Santa Cruz, Argentina. Referencias AspectJ (2008) Casas, S., Marcos, C., Vanoli, V., Reinaga, H., Saldivia, C., Prior, J. y Sierpe, L. (2005) ASTOR: Un Prototipo para la Administración de Conflictos en AspectJ, XIII Encuentro Chileno de Computación, Jornadas Chilenas de Computación (JCC 05), Chile. Douence, R., Fradet, P., Südholt, M. A Framework for the Detection and Resolution of Aspect Interactions (2002). Proceedings of the ACM SIGPLAN SIGSOFT Conference on GPCE. Dijkstra, E. (1976) A Discipline of Programming, Prentice-Hall. Durr, P., Staijen, T., Bergmans, L., Aksit, M. (2005) Reasoning about semantic conflicts between aspects. In K. Gybels, M. D Hondt, I. Nagy, and R. Douence, editors, 2nd European Interactive Workshop on Aspects in Software. Hanenberg, S., Unland, R. (2001) Concerning AOP and Inheritance. Proceedings of Workshop Aspect-Orientation, Paderborn. Hursch, W., Lopes, C. (1995) Separation of Concern. TR NU-CCS-95-03, Northeastern University. Katz, S., Rashid, A. (2004) From Aspectual Requirements to Proof Obligations for Aspect-Oriented Systems, International Conference on Requirements Engineering (RE), Japon, IEEE Computer Society Press. Pp Kessler, B. and Tanter, E. (2006) Analyzing Interactions of Structural Aspects. Workshop AID in 20th. European Conference on Object-Oriented Programming (ECOOP). France. Kiczales, G., Lamping, L., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J., Irwin, J. (1997) Aspect-Oriented Programming. In Proceedings ECOOP 97 Object- Oriented Programming, 11 th European Conference, Jyväskylä Finland, Springer- Verlang. Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W. (2001) An Overview of AspectJ. ECOOP. Kiczales, G. (2002) AOSD 1st. International Conference on Aspect-Oriented Software Development. (Ed.). ACM Press. The Netherlands. Monga, M., Beltagui, F., Blair, L. (2003) Investigating Feature Interactions by Exploiting Aspect Oriented Programming, TR N comp , Lancaster University, Inglaterra. Piveta, E. and Zancanela, L. (2003) Aspect Weaving Strategies, Journal of Universal Computer Science, vol.9, no. 8. Pryor, J., Diaz Pace, A., Campo, M. (2002) Reflection on Separation of Concerns. RITA. Vol.9. Num.1. 46

47 Pryor, J., Marcos, C. (2003) Solving Conflicts in Aspect-Oriented Applications. Proceedings of the Fourth ASSE. 32 JAIIO. Argentina. ROOTS (2005) LogicAJ A Uniformly Generic and Interference-Aware Aspect Language ; Tanter, E., Noye, J. (2005) A Versatile Kernel for Multi-Language AOP, Proceeding of ACM SIGPLAN/SIGSOFT Conference on Generative Programming and Component Engineering (GPCE 2.005) LNCS, Springer-Verlag, Estonia. Tarr, P., Ossher, H., Harrison W. and Sutton Jr. S.M. (1999) N Degrees of Separation: Multi-Dimensional Separation of Concerns. Proceedings of ICSE 99. pp , IEEE Computer Society Press / ACM Press. Tessier, F., Badri, M., Badri, L. (2004) A Model-Based Detection of Conflicts Between Crosscutting Concern: Towards a Formal Approach, International Workshop on Aspect Oriented Software Development (WAOSD 04), China. 47

48 PROPUESTA DEL ALGORITMO RARM-QF: MINERÍA DE REGLAS DE ASOCIACIÓN RÁPIDA CON FACTOR DE CANTIDAD APLICADO A DOCUMENTOS XML DE BASES DE DATOS RELACIONALES XML-ENABLED Erika Hidalgo Málaga 1 Alvaro Ojeda Cornejo 1 Karim Guevara Puente de la Vega 1 1 Universidad Católica Santa María - Arequipa erikahidalgomalaga@gmail.com, ojedacornejoalvaro@gmail.com, kguevara57@hotmail.com Resumen La minería de reglas de asociación es un área bien investigada, donde muchos algoritmos han sido propuestos. En este trabajo proponemos un algoritmo innovador llamado Minería de Reglas de Asociación Rápida con Factor de Cantidad (RARM-QF), el cual esta basado en el algoritmo RARM, que se caracteriza por ser el más rápido dentro de la familia de los algoritmos de reglas de asociación. La primera contribución de este trabajo es la propuesta de un algoritmo que genere las reglas de asociación con influencia del factor cantidad de ítem para una mejor definición del conjunto de posibles reglas, haciéndolas más informativas, de manera que satisfagan la aceptación del usuario. Para dicho propósito se utiliza la técnica estadística de Análisis de Componentes Principales (PCA). Por ejemplo, una regla a obtener sería: [3-5] Pan ^ [1-2] Leche => [1-2] Mantequilla, que nos indica que los clientes que compran entre 3 a 5 kilos de panes y 1 a 2 botellas de leche, tienden a comprar entre 1 a 2 unidades de mantequilla. La segunda contribución es que esta minería de datos se realiza sobre documentos XML provenientes de Bases de Datos Relacionales XML-Enabled. La razón de la utilización de este tipo de Base de Datos XML es que, desde un punto de vista estructural y semántico, representa un reto más grande minar partiendo de datos XML, que hacer la minería de asociación tradicional. Experimentos sobre documentos XML de una base de datos retail demuestran que las reglas producidas por el algoritmo propuesto son más informativas y precisas ya que se trata de reglas cuantitativas y no booleanas. 1. Introducción La Minería de Datos es el proceso de extraer conocimiento de bases de datos. Su objetivo es descubrir situaciones anómalas y/o interesantes, tendencias, patrones y secuencias en los datos [Molina, 2001]. Las reglas de asociación son una técnica utilizada por la minería de datos, cuyo propósito es extraer correlaciones interesantes, patrones frecuentes, estructuras de asociación entre conjuntos de ítems en las bases de datos de transacciones [Agrawal, 1993]. El trabajo inicial de minería de reglas de asociación hecho por [Agrawal, 1994] y los subsecuentes trabajos sobre bases de datos, propusieron algoritmos para minimizar el tiempo de extracción de estas reglas a través de guardadores de registros inteligentes para evitar pasadas adicionales sobre los conjuntos de datos, a través del paralelismo, etc. Uno de los algoritmos más importantes es el denominado Rapid Association Rule Mining (RARM), cuya característica principal es la rapidez, dado que éste elimina el cuello de botella ocasionado por el algoritmo Apriori [Agrawal, 1994], base de todos los algoritmos de minería de hoy en día. Sin embargo, la cantidad del ítem es un campo que no es tomado en cuenta por estos algoritmos al momento de realizar la minería de datos transaccionales, lo cual brindaría más precisión e información a los resultados. 48

49 Lo que se quiere lograr mediante el algoritmo propuesto en este trabajo es la integración de la cantidad de ítem a la minería, con la aplicación de ésta a datos en formato XML y ya no a datos relacionales tradicionales, para lo cual el dominio de la aplicación estará orientado a documentos XML provenientes de Bases de Datos Relacionales XML-Enabled. El presente artículo esta organizado de la siguiente manera: La Sección 2 trata sobre los trabajos previos. La Sección 3 da una descripción del problema. La Sección 4 expone el método PCA. La Sección 5 introduce al algoritmo propuesto. La sección 6 muestra los experimentos y resultados. La discusión de los experimentos se muestra en la sección 7 y finalmente, las conclusiones y trabajos futuros son mostrados en las secciones 8 y 9, respectivamente. 2. Trabajos Previos Desde la introducción del algoritmo Apriori [Agrawal, 1994], hubo un interés sostenido en desarrollar nuevos algoritmos de minería de reglas de asociación que puedan generar resultados de manera más eficiente. Es así que el algoritmo RARM [Das, 2001] hace uso de una estructura tipo árbol conocida como Support-Ordered Trie Itemset (SOTrieIT) la cual almacena los datos transaccionales pre-procesados. Esto le permite a RARM generar 1-itemsets y 2-itemsets grandes, rápidamente sin escanear la base de datos por segunda vez y sin la generación de 2-itemsets candidatos. Este logra aumentos de velocidad significativos, porque el principal cuello de botella de la minería de reglas de asociación que utiliza la propiedad Apriori es la generación de 2-itemsets candidatos. Las técnicas de descubrimiento de reglas de asociación son básicamente booleanas, debido a que se descartan las cantidades de los ítems comprados y sólo se presta atención a si algo fue comprado o no. Una excepción notable es el trabajo de [Agrawal, 1996], donde se referencia el problema de la minería de reglas de asociación cuantitativas. Su enfoque es particionar cada atributo cuantitativo en un conjunto de intervalos que podrían traslaparse, en consecuencia, se aplican técnicas de minería de reglas de asociación Booleanas. 3. Descripción del Problema Uno de los problemas de las reglas de asociación tiene que ver con los tipos de datos tomados en cuenta al momento de crear las reglas a partir de las transacciones. Una regla de asociación es una implicación de la forma X => Y, donde X, Y son conjuntos de ítems llamados itemsets y X Y = ø; determinando a X como el antecedente y Y el consecuente. Existen dos medidas importantes básicas para las reglas de asociación, el soporte (s) y la confianza (c). Puesto que las bases de datos son inmensas y que a los usuarios solo les interesan aquellos artículos frecuentemente comprados, usualmente se pre-definen umbrales de soporte y confianza, hecho por los usuarios, para eliminar aquellas reglas que no son interesantes o útiles. El soporte (s) de una regla de asociación es definido como el porcentaje sobre la fracción de registros que contiene X U Y del total de número de registros en la base de datos. El contador por cada ítem es incrementado en uno cada vez que el ítem es encontrado en diferentes transacciones T en la base de datos D durante el proceso de escaneado. Esto quiere decir que el contador de soporte no tiene en cuenta la cantidad del ítem. Por ejemplo, en una transacción un cliente compra tres botellas de cerveza pero solamente se incrementa el número del contador de soporte {cerveza} por uno; en otras palabras si una transacción contiene un ítem, entonces, el contador de soporte de ese ítem sólo se incrementa en uno. 49

50 XML (Extensible Markup Language), se está convirtiendo en el formato de datos de elección para una amplia variedad de soluciones de sistemas de información. Entonces, el partir de una Base de Datos Relacional XML-Enabled, nos permitirá trabajar con documentos XML, de tal modo, que la minería propuesta se aplicará a estos documentos, minando estructuras de datos jerárquicas más complejas y ya no datos relacionales. 4. Análisis de Componentes Principales (PCA) El algoritmo propuesto esta basado en el Análisis de Componentes Principales. Según [Smith, 2002], PCA es una técnica estadística, una forma de identificar patrones en los datos y de expresarlos de manera que se realce sus similitudes y diferencias. Puesto que los patrones en datos de alta dimensión pueden ser difíciles de encontrar, donde el lujo de las representaciones gráficas no están disponibles; PCA es una herramienta poderosa para el análisis de estos datos. 4.1 Método La metodología PCA funciona mediante los siguientes pasos, los cuales transformarán nuestros conjuntos de datos en términos de patrones entre los datos, donde los patrones son las líneas que describen más de cerca las relaciones entre los datos. Esto es muy útil porque podremos clasificar nuestros datos (puntos) como una combinación de las contribuciones de cada una de esas líneas. Paso 1: Obtener los datos Se utiliza el ejemplo de la Figura 1. Paso 2: Sustraer la media Para que PCA trabaje apropiadamente, se tiene que sustraer la media de cada una de las dimensiones. La media sustraída es el promedio de cada dimensión; así, a todos los valores χ se les sustrae una (la media de los valores χ de todos los puntos datos) y a todos los valores y se les sustrae una. Esto produce un conjunto de datos cuya media es 0. Figura 1. Ejemplo de datos PCA, los datos originales a la izquierda, los datos con las medias sustraídas a la derecha en (a) y un diagrama de los datos en (b). 50

51 Paso 3: Calcular la matriz de covarianza La matriz de covarianza para el ejemplo de arriba será de 2 x 2. El resultado sería: En vista que los elementos que no están en la diagonal en esta matriz de covarianza son positivos, se espera que ambas variables χ y y se incrementen juntas. Paso 4: Calcular los eigenvectores y eigenvalores de la matriz de covarianza Como la matriz de covarianza es cuadrada, se pueden calcular los eigenvectores y eigenvalores para esta matriz. Estos son muy importantes porque nos facilitan información útil acerca de nuestros datos. Estos son los valores resultantes. Nótese que estos eigenvectores son unitarios, es decir, que sus longitudes son de 1. En la Figura 2 se puede ver que los datos tienen un patrón fuerte. Las dos variables se incrementan juntas. En el tope de los datos se han ubicado los dos eigenvectores que están como líneas punteadas diagonales en el diagrama. Los eigenvectores son perpendiculares entre sí. Pero aún más importante es el hecho de que ellos proveen información acerca de los patrones de los datos. Véase cómo uno de los eigenvectores atraviesa los puntos medios, como dibujando una línea a la cual es mejor ajustarse. Ese eigenvector muestra cómo estos dos conjuntos de datos están relacionados a lo largo de esa línea. El segundo eigenvector nos da el otro patrón de los datos, menos importante, en donde todos los puntos siguen la línea principal, pero donde algunos datos son dejados fuera de la línea principal. Así que por medio de este proceso se puede extraer líneas que caracterizan los datos. El resto de los pasos involucran la transformación de los datos, para que sean expresados en sus propios términos. Figura 2. Diagrama de los datos normalizados (media sustraída) con los eigenvectores de la matriz de covarianza sobrepuestos en el tope. 51

52 Paso 5: Escogiendo los componentes Aquí es donde la noción de compresión de datos y reducción de dimensionalidad viene a darse. Si se mira a los eigenvectores y eigenvalores de la sección anterior, se dará cuenta que los eigenvectores son valores un poco diferentes; de hecho, resulta que el eigenvector con el eigenvalor más alto es el componente principal del conjunto de datos. En el ejemplo anterior sería el siguiente eigenvector por ser el mayor eigenvalor Paso 6: Derivando el nuevo conjunto de datos Este es el paso final en el Análisis de Componentes Principales. Una vez que se han escogido los componentes (eigenvectores) que se desean guardar en los datos, que para el ejemplo anterior se escogieron los dos, se deriva el nuevo conjunto de datos. Ver figura Algoritmo RARM-QF 5.1. Pre-Procesamiento Figura 3. Diagrama del nuevo conjunto de datos. El algoritmo de Pre-Procesamiento muestra los pasos tomados cada vez que llega una transacción. Por cada transacción que llega se extraen 1-itemsets y 2-itemsets. Por cada itemset el SOTrieIT denotado por Y será recorrido para localizar el nodo que almacena su soporte, que es almacenado para los 1-itemsets y 2-itemsets en el primer y segundo nivel, respectivamente, así como la cantidad para cada uno de ellos. 52

53 Algoritmo 1 Pre-Procesamiento Requiere: Y (conjunto de SOTrieITs) para ( k=1; k 2; k++) hacer inicio Obtener todos los k-itemsets de la transacción con sus respectivas cantidades y almacenarlos en C k paracada itemset X Є C k hacer inicio Recorre Y para localizar los nodos a lo largo del camino que representa X si tal conjunto de nodos existen en Y entonces Incrementa el contador de soporte del nodo hoja Ordena el nodo actualizado entre sus hermanos de acuerdo a su nuevo contador de soporte en orden descendente. sino Crea un nuevo conjunto de nodos con contador de soporte de 1 que representa un camino a X. Insértelos en Y de acuerdo al contador de soporte en orden descendente desde la izquierda. fin si fin para fin para Complejidad de Tiempo La cantidad de tiempo para pre-procesar una transacción depende de la cantidad de tiempo para: extraer 1-itemsets y 2-itemsets de la transacción con sus respectivas cantidades, recorrer el SOTrieIT, incrementar los contadores de soporte de los nodos respectivos, y crear nuevos nodos en el SOTrieIT para los ítems que aún no han sido encontrados. Para una transacción de tamaño s y cantidades q, sólo ( + ) itemsets y ( + ) cantidades son pre-procesados, donde q = s. Por consiguiente, su complejidad es de O(s 2 + q 2 ) que es igual a O(s 2 ). Por ejemplo, cuando la transacción {A, [5]; B, [4]; C, [3]; D, [4]} llega, los siguientes diez itemsets son extraídos con sus respectivas cantidades: {A, [5]}, {B, [4]}, {C, [3]}, {D, [4]}, {A,B, [5,4]}, {A,C, [5,3]}, {A,D, [5,4]}, {B,C, [4,3]}, {B,D, [4,4]},{C,D, [3,4]} Según la formulación, esto da un total de 4! + 4! = (4+6) = 3!1! 2!2! 10 itemsets y 10 cantidades, lo cual es correcto. Mientras el SOTrieIT representa sólo 2 niveles de profundidad, le toma a lo mucho dos enlaces para llegar al nodo deseado. Considerando que también toma una unidad de tiempo para moverse sobre un enlace y actualizar/crear el nodo y una unidad de tiempo para extraer un itemset, le tomará un máximo de 2 * [( + ) + ( + )] unidades de tiempo, que es igual a 53

54 2 * [( + )] unidades de tiempo, para mover a todos los nodos requeridos por una transacción de tamaño s. Con esto se demuestra que la complejidad de tiempo no varía cuando se toma en cuenta el factor cantidad de ítem Complejidad de Espacio En una base de datos con N ítems únicos, habrá N nodos de primer nivel en el SOTrieIT. Para cada nodo de primer nivel, ya que el SOTrieIT es creado en forma de árbol, contendrá sólo ítems que son léxico-gráficamente más grandes que sí mismo y sus respectivas cantidades. El nodo de primer nivel que tiene el número más grande de nodos hijos, tendrá N-l nodos hijos. Los nodos de primer nivel posteriores tendrán un nodo hijo menos que el anterior. Por lo tanto, para N ítems únicos, un máximo de sólo nodos, que incluye, tanto los nodos del primer nivel como los de segundo nivel, son necesarios para almacenar todo el pre-procesamiento de la información. Por ende, su complejidad es de O(N 2 ) y la cantidad no afecta la complejidad de espacio producida previamente por RARM Minería de Itemsets Grandes El algoritmo de Minería de Itemsets Grandes muestra los pasos tomados cuando el proceso de minería es iniciado. El SOTrieIT Y es recorrido para descubrir los 1-itemsets y 2-itemsets grandes. El recorrido comienza en el primer nivel de izquierda a derecha y éste para cuando se encuentra un nodo que no satisface el umbral de soporte mínimo. Después de ello se utiliza el algoritmo Apriori para la minería de los demás itemsets. Algoritmo 2 Minería de Itemsets Grandes Requiere: Y (conjunto de SOTrieITs) Sea el q ésimo nodo hijo del nodo padre p Sea NC p el número de nodos hijos bajo el nodo p Sea I n el itemset que almacena el ítem y su respectiva cantidad(es), representado por el nodo n para ( χ = 1; χ NC ROOT ; χ ++ ) hacer inicio Sea X = si σ X D * s% entonces inicio Add I X to L 1 para (y=1; y NC X ; y++) hacer inicio si ( D * s%) entonces Add to L 2 fin para fin si fin para funcionassoc_rules ( L 2 ) Ejecutar Apriori desde su tercera iteración para encontrar el resto de itemsets grandes desde los 3-itemsets hacia delante. 54

55 5.2.1 Complejidad de Tiempo Para comparar la complejidad de tiempo entre el algoritmo propuesto, se verá primero una comparación entre RARM y Apriori, donde el enfoque sólo se dará en el proceso de escaneado para obtener los contadores de soporte de los itemsets. Esto es suficiente para ver la gran mejora de RARM comparado con Apriori. Para cada paso del algoritmo Apriori existe la necesidad de escanear toda la base de datos, independientemente del umbral del soporte deseado. Conjeturando que la base de datos es de tamaño a y el tamaño promedio de cada transacción es b, entonces, Apriori toma O(ab) unidades de tiempo para escanear la base de datos en cada pasada. El algoritmo RARM solamente necesita escanear el SOTrieIT. De acuerdo a la sección Y tiene nodos y, dado que cada nodo sólo tiene un enlace desde su padre, en el peor de los casos, tomará a lo mucho unidades de tiempo para recorrer toda la estructura, donde N «a. Además, el tiempo necesitado también depende del umbral de soporte, el cual reduciría el número de recorridos. En tal sentido, la cantidad total promedio de tiempo de escaneo será mucho menos de O(ab). En el algoritmo propuesto se aplica el mismo proceso y además se almacena la cantidad de los ítems, no afectando en el recorrido, por tanto, también toma unidades de tiempo. 5.3 Algoritmo Apriori más detallado Se ha redefinido el algoritmo Apriori donde ya no se realizarán constantes leídas a la base de datos. Específicamente, en la función recorretransacciones, es en donde las cantidades de los ítems son extraídas y luego, conforme los contadores de los itemsets son incrementados, las cantidades respectivas son puestas dentro del Hash-Tree. Algoritmo 3 Apriori Requiere: vtransacciones mietras(true) inicio ik++ si (crearcandidato(ik) esta vacío) entonces break crearhashtreecandidato(ik) recorretransacciones vlis = crearitemsetgrande(ik) funcionassoc_rules(vlis) fin mientras 5.4 Algoritmo PCA Al momento de generar las reglas se ejecuta el algoritmo PCA, que se encarga de procesar las cantidades de los ítems componentes de las reglas y de construir los intervalos para dichas cantidades. Por otra parte, la covarianza es la medida introducida en el presente artículo, que nos permite evaluar si una regla es válida o no de acuerdo a la correlación de sus elementos. Este indicador mide la fuerza de la relación lineal entre 2 variables 55

56 cuantitativas. Si uno de los valores dentro de la matriz de covarianza calculada, que es necesaria para realizar el Análisis de Componentes Principales, es igual a cero; entonces, esa regla será descartada, puesto que no existirá relación lineal alguna entre las dos variables cuantitativas evaluadas. Algoritmo 4 PCA Requiere: Regla obtenermatrizmedia covarianza = obtenermatrizcovarianza si (!comprobarmatrizcov(covarianza)) entonces break obtenereigenvectores obtenereigenvalores obtenereigenvectormax //Componente Principal obtenerintervalos 6. Importancia de la Minería sobre Documentos XML de Bases de Datos Relacionales XML-Enabled XML se está convirtiendo en el formato de datos de elección para una amplia variedad de soluciones de sistemas de información porque es sencillo de entender su estructura y procesarlo, mejora la compatibilidad entre aplicaciones y por su portabilidad. Aplicaciones comunes que usan XML incluyen transmisión de documentos en sistemas B2B, construcción de formatos de mensajes para integración de aplicaciones de Internet, almacenamiento y obtención de datos y varias actividades de manipulación de datos dentro de aplicaciones. Es por ello que en las empresas de hoy en día resulta cada vez más necesario generar XML a partir de la información que tienen almacenada en sus bases de datos. En vista que la mayoría de las aplicaciones tradicionales de negocios y de las aplicaciones basadas en Internet dependen de bases de datos, que en su mayoría son relacionales, el uso de la infraestructura existente de las bases de datos para la administración de demandas de datos XML parece ser lógico. Actualmente se puede utilizar sistemas de gestión de bases de datos que permiten el almacenamiento y obtención de información en formato XML, tales como: los Sistemas de Gestión de Bases de Datos Relacionales XML-Enabled y los Sistemas de Gestión de Bases de Datos Nativos XML, de los cuales nos basaremos en el primero. Se utiliza este tipo de Base de Datos XML, debido a que desde un punto de vista estructural y de semántica, representa un reto más grande minar partiendo de datos XML que hacer la minería de asociación tradicional, y también, porque las Bases de Datos Relacionales XML-Enabled llevan la madurez de los productos RDBMS (Relational Database Management System) con ellas. Las organizaciones que han estado almacenando sus datos críticos en RDBMS, han crecido confiando sus datos en dichos productos. Entonces, el partir de una Base de Datos Relacional XML-Enabled, nos permitirá trabajar con documentos XML, de tal modo, que la minería propuesta se aplicará a estos documentos, minando estructuras de datos jerárquicas más complejas y ya no datos relacionales. 7. Experimentos y Resultados Condiciones.- El algoritmo propuesto fue desarrollado en Java, en una máquina Pentium IV, con 2G de RAM, con 1.66 GHz de velocidad de procesador y corriendo en la plataforma Windows XP. 56

57 Descripción de Experimentos.- Se ejecutaron los experimentos sobre transacciones y 3000 ítems únicos provenientes de una base de datos de un supermercado Belga anónimo. Se hicieron cuatro experimentos, en donde el parámetro de entrada umbral de soporte mínimo fue la variante para cada experimento, con valores de 2%, 1%, 0.5% y 0.25%; mientras que el umbral de confianza mínima se mantuvo en un 70% para todos los casos. Se realizaron estos experimentos con los propósitos de: Verificar que el volumen de las reglas producidas por el algoritmo RARM, sea mayor o igual para umbrales de soporte pequeños y grandes, respectivamente, a las producidas por el algoritmo RARM-QF, debido al factor de covarianza introducido para el algoritmo propuesto, el cual se verá afectado por los parámetros de entrada (soporte y confianza). Demostrar que las reglas obtenidas son más informativas, puesto que se trata de reglas cuantitativas y no booleanas. Conjunto de Datos.- De acuerdo a [Brijs, 1999], el conjunto de datos con el que se trabajó fue obtenido a lo largo de tres períodos no consecutivos: el primer período va desde mediados de Diciembre de 1999 hasta mediados de Enero del 2000; el segundo período va desde inicios del 2000 hasta inicios de Junio del mismo año y el tercer período va desde fines de Agosto del 2000 hasta fines de Noviembre del El lapso comprendido entre esos períodos, desafortunadamente los datos no estuvieron disponibles. Esto resulta en aproximadamente nueve meses de datos. La cantidad total de recibos recolectados fueron de 88,163. En total 5,133 clientes han comprado como mínimo un producto en el supermercado durante el período de recolección de datos. Se realizó la conversión de los datos a formato XML. Contexto de Minería de Datos.- El Cuadro 1 muestra el contexto de minería de datos para los experimentos realizados. Dominio de Aplicación Análisis de Canasta de Mercados Resultados.- Contexto de Minería de Datos Tipo de Problema de Minería de Aspectos Datos Técnicos Análisis de Reglas de Dependencia Asociación Cuadro 1: Contexto de Minería Herramienta y Técnica Algoritmo RARM-QF Figura 4. Número de Reglas producidas para RARM y RARM-QF 57

58 La figura 4 muestra los resultados obtenidos (Volumen) por los experimentos, en donde: Para un umbral de soporte mínimo del 2% y un umbral de confianza mínima del 70% se obtuvieron 14 reglas booleanas con el algoritmo RARM y con RARM-QF 14 reglas cuantitativas. Para un umbral de soporte mínimo del 1% y un umbral de confianza mínima del 70% se obtuvieron 55 reglas booleanas con el algoritmo RARM y con RARM-QF 52 reglas cuantitativas. Para un umbral de soporte mínimo del 0.5% y un umbral de confianza mínima del 70% se obtuvieron 165 reglas booleanas con el algoritmo RARM y con RARM-QF 150 reglas cuantitativas. Para un umbral de soporte mínimo del 0.25% y un umbral de confianza mínima del 70% se obtuvieron 555 reglas booleanas con el algoritmo RARM y con RARM-QF 498 reglas cuantitativas. En cuanto a las reglas obtenidas, se extrajeron 3 reglas del primer experimento, tanto del algoritmo RARM como del RARM-QF, dándoseles a cada una se dio su interpretación. RARM o Regla #1 Habas J&J ==> Apio J&J De la regla 1 podemos deducir que cuando un cliente compra Habas J&J también compra Apio J&J. o Regla #9 Apio J&J ^ Lentejas J&J ==> Porro J&J De la regla 9 podemos deducir que cuando un cliente compra Apio J&J y Lentejas J&J, también compra Porro J&J. o Regla #13 Lechuga J&J ^ Lentejas J&J ^ Pimentón J&J ==> Porro J&J De la regla 13 podemos deducir que cuando un cliente compra Lechuga J&J, Lentejas J&J y Pimentón J&J, también compra Porro J&J. RARM-QF o Regla #1 [ ] Habas J&J ==> [ ] Apio J&J De la regla 1 podemos deducir que existe una proporción directa incremental entre la cantidad comprada de Habas J&J (kilos) en relación a la cantidad de Apio J&J (kilos). Cov( Habas J&J, Apio J&J ) > 0, indica que los valores altos de Habas J&J están asociados a los valores altos de Apio J&J. o Regla #9 [ ] Apio J&J ^ [ ] Lentejas J&J ==> [ ] Porro J&J De la regla 9 podemos deducir que existe una proporción inversa entre los ítems del antecedente de la regla en relación a la cantidad de Porro J&J (kilos), cuya proporción es incremental. Cov( Apio J&J, Lentejas J&J ) < 0, indica que los valores altos de Apio J&J están asociados a los valores bajos de Lentejas J&J. Cov( Apio J&J, Porro J&J ) > 0, indica que los valores altos de Apio J&J están asociados a los valores altos de Porro J&J. Cov( Lentejas J&J, Porro J&J ) < 0, indica que los valores bajos de Lentejas J&J están asociados a los valores altos de Porro J&J. 58

59 o Regla #13 [ ] Lechuga J&J ^ [ ] Lentejas J&J ^ [ ] Pimentón J&J ==> [ ] Porro J&J De la regla 13 podemos deducir que existe una proporción directa incremental entre los ítems del antecedente de la regla en relación a la cantidad de Porro J&J (kilos), cuya proporción es decremental. Cov( Lechuga J&J, Lentejas J&J ) > 0, indica que los valores altos de Lechuga J&J están asociados a los valores altos de Lentejas J&J. Cov( Lechuga J&J, Pimentón J&J ) > 0, indica que los valores altos de Lechuga J&J están asociados a los valores altos de Pimentón J&J. Cov( Lechuga J&J, Porro J&J ) < 0, indica que los valores altos de Lechuga J&J están asociados a los valores bajos de Porro J&J. Cov( Lentejas J&J, Pimentón J&J ) > 0, indica que los valores altos de Lentejas J&J están asociados a los valores altos de Pimentón J&J. Cov( Lentejas J&J, Porro J&J ) < 0, indica que los valores altos de Lentejas J&J están asociados a los valores bajos de Porro J&J. Cov( Pimentón J&J, Porro J&J ) < 0, indica que los valores altos de Pimentón J&J están asociados a los valores bajos de Porro J&J. 8. Discusión de los Experimentos Como se puede apreciar, el volumen de reglas de asociación producidas por RARM-QF en el punto anterior, se reduce conforme el Umbral de Soporte Mínimo disminuye, en comparación al algoritmo RARM; esto es, porque el volumen esta sujeto a la covarianza encontrada entre los ítems pertenecientes a una regla, que mide la fuerza de la relación lineal entre ellos. Si uno de los valores dentro de la matriz de covarianza calculada es igual a cero, entonces, esa regla será descartada puesto que no existirá relación lineal alguna. Y así, ya no se tendrá un simple conjunto de reglas, sino, un conjunto de reglas donde los ítems estén más correlacionados. La calidad de las reglas de asociación obtenidas por RARM-QF puede ser medida desde dos puntos de vista: la precisión y la información que ellas proveen. La precisión de las reglas producidas se da a conocer mediante los rangos de cantidades obtenidos para cada ítem que compone a una regla determinada. La técnica PCA (Análisis de Componentes Principales) es la que nos asegura que el conjunto de datos obtenidos para las cantidades ha sido escogido de acuerdo a las características del conjunto de datos que contribuyen más, ignorando algunos conjuntos que no son relevantes. La covarianza (cov) nos permitirá medir el tipo de relación entre las cantidades de los ítems de una regla. Estas nuevas reglas son más informativas que las reglas obtenidas por RARM, lo cual es claramente visto en la interpretación dada a cada regla, debido a que para el caso de las reglas producidas por RARM (Reglas Booleanas) sólo se tiene como información la relación que hay entre los ítems de la regla y nada más, mientras que en las reglas producidas por RARM-QF (Reglas Cuantitativas) se brinda una información más precisa porque además de la relación entre ítems, éstas nos proveen la proporción de las cantidades de los ítems de la regla. 9. Conclusiones Se ha propuesto un algoritmo de minería de reglas de asociación basado en el algoritmo de minería de reglas de asociación rápida, que considera el factor de cantidad de ítem y cuyo dominio esta orientado a documentos XML; cuyas reglas resultantes de acuerdo a los experimentos realizados, nos han permitido definir un conjunto de reglas de asociación más informativas y precisas. 59

60 El algoritmo propuesto produce reglas de asociación más informativas y precisas al aplicar la técnica de Análisis de Componentes Principales al factor cantidad de ítem. La covarianza, nueva medida utilizada para determinar la calidad de las soluciones, además del soporte y la confianza, nos permitió obtener reglas más precisas mediante la evaluación de la correlación de los ítems pertenecientes a una regla. La aplicación del algoritmo propuesto a documentos XML nos permitió dar un nuevo enfoque a la minería de reglas de asociación, al minar estructuras de datos jerárquicas más complejas y ya no datos relacionales. El soporte y la confianza ingresados para la minería de reglas de asociación de un conjunto de datos, varían mucho los resultados a obtener, debido a que estos parámetros son subjetivos; el criterio del usuario será el responsable de la cantidad y calidad de reglas obtenidas. 10. Trabajos Futuros Implementar un sistema interactivo para la minería realizada por el algoritmo propuesto, de manera que pueda trabajar con un umbral de soporte dinámico y no se tenga que reiniciar la minería desde cero, cuando se decida cambiar este parámetro en medio proceso. Adecuar el algoritmo propuesto para que realice una minería incremental. Dado que con el correr del tiempo las bases de datos continuarán cambiando y nuevos conjuntos de datos podrán ser introducidos a éstas, las inserciones realizadas conducirán a una repetición del proceso entero. Reconocimiento Agradecemos al Dr. César Beltrán Castañón por sus consejos y por compartir desinteresadamente sus amplios conocimientos y experiencia. 11. Referencias [Agrawal, 1993] Agrawal, R., Imielinski, T., y Swami, A., Mining association rules between sets of items in large databases. In Proceedings of the 1993 ACM SIGMOD International Conference on Management of Data, P. Buneman and S. Jajodia, Eds. Washington, D.C., [Agrawal, 1994] Agrawal, R. y Srikant, R. (1994). Fast algorithms for mining association rules. In Proceeding 20 th International Conference Very Large Data Bases, VLDB, J. B. Bocca, M. Jarke, and C. Zaniolo, Eds. Morgan Kaufmann, [Agrawal, 1996] Agrawal, R. y Srikant, R. (1996). Mining Quantitative Association Rules in Large Relational Tables. In Proceeding of the 1996 ACM SIGMOD Conference, Montreal, Québec, Canada [Brijs, 1999] Brijs T., Swinnen G., Vanhoof K., and Wets G. (1999). The use of association rules for product assortment decisions: a Case Study. In Proceedings of the Fifth International Conference on Knowledge Discovery and Data Mining, San Diego (USA), 15-18, [Molina, 2001] Molina, L., Torturando los Datos Hasta que Confiesen. Departamento de Lenguajes y Sistemas Informáticos, Universidad Politécnica de Cataluña. Barcelona, España. [Das, 2001] Das A., Ng W., Woon Y. (2001). Rapid Association Rule Mining. In Proceeding Conference on Information and Knowledge Management, Atlanta, Georgia. [Smith, 2002] Smith, L. (2002). A Tutorial on Principal Components Analysis. 60

61 Reconocimiento de expresiones faciales mediante flujo óptico en secuencias de video Filomen Incahuanaco Quispe 1 Universidad Nacional de San Agustín, Escuela profesional de Ingenieria de Sistemas Av. Independencia S/N,Arequipa-Perú jincahuanaco@episunsa.edu.pe Resumen La expresión facial es una actividad cotidiana dentro del proceso de comunicación entre seres humanos. Por tanto la cuantificación de las expresiones faciales es un tema abierto en el campo de la visión por computador por su utilidad en la construcción de interfaces de comunicación con el ordenador. También es un tema de interés en otros campos, como el de la animación por computador. En este trabajo se presentan los resultados de la aplicación de técnicas basadas en teoría de movimiento en secuencias de imágenes orientadas al análisis de expresiones faciales para detectar el estado de ánimo de la persona. El primer paso consiste en elegir los puntos característicos del rostro lo que conlleva a formar una malla de puntos; luego se mide el grado del movimiento facial de la expresión. Previo a este paso fue determinante detectar la posición de los ojos, con el objeto de calcular la inclinación o rotación del rostro. En seguida se establece una clasificación de estos grados de movimiento, usando el clasificador K-Support Vector Machine(K-SVM) con el objeto de determinar si la expresión facial representa una de las seis expresiones faciales más relevantes: normal o neutral, miedo, tristeza, enojo, sorpresa, asco, felicidad. El aporte del presente trabajo consiste en que nuestra técnica está centrado en las características morfológicas y topológicas de los elementos del rostro relacionadas con las Unidades de Acción(UA), lo que permite reducir la cantidad de puntos y hacer un mejor seguimiento del movimiento, esto a su vez permite disminuir sustancialmente el costo computacional al momento de realizar el cálculo de flujo óptico. Los resultados son muy auspiciosos puesto que se consiguió detectar las expresiones de alegria, sorpresa, enojo y asco con un alto grado de eficiencia, alrededor del 75 %, en el mejor de los casos, por otro lado, las expresiones de tristeza y miedo son poco perceptible, ello porque la tristeza sufre una transición lenta y el miedo por ser una mezcla de expresiones Introducción El rostro humano provee una fuente de información comunicativa acerca del comportamiento. Las expresiones faciales proporcionan señales que nos permite percibir la respuesta emocional y desempeña un papel importante en la interacción humana y la comunicación no verbal (Arias, 2005). Así mismo las expresiones faciales muestran la emoción (Ekman, 1993), regulan la conducta social, las señales de intención comunicativa, está computacionalmente relacionado a la producción del habla, y puede revelar la función cerebral y patología (Arias, 2005). 1 Material suplementario: 61

62 Por lo tanto, para hacer uso de la información ofrecida por las expresiones faciales es necesario métodos eficaces, confiables y validos para la medición. En psicología se han propuesto seis emociones básicas (Alegria, sorpresa, enojo, tristeza, miedo y asco); cada una incluye cambios de los rasgos faciales en varias regiones del rostro. Estas expresiones básicas, sin embargo, se producen con relativa poca frecuencia en la vida cotidiana. Con mayor frecuencia son los cambios sutiles en uno o varios elementos discretos, como el endurecimiento de los labios que pueden comunicar la ira. Los seres humanos son capaces de producir muchas expresiones que varían en complejidad, intensidad y sentido (Ekman, 1993). Posteriormente se definió un estándar basado en la anatomía del rostro, llamado FACS(Facial Action Coding System)(Ekman and Friesen, 1978; Cohn et al., 2005), para el uso en la codificación de las expresiones faciales. Con FACS, los observadores pueden codificar manualmente todos los posibles movimientos discretos del rostro; se denominan unidades de acción (AUs). Las AUs individualmente o en combinación pueden representar todas las expresiones visiblemente discriminables. En cuanto a la detección automática de expresiones faciales, podemos destacar el de Ira Cohen en (Cohen et al., 2003), quien trabajó en la clasificación de expresiones faciales en secuencias de video, empleando el clasificador Naive Bayes y el cambio de la distribución gaussiana a cauchy. En este trabajo proponen una nueva arquitectura de HMMs(Hidden Markov Models) para dividir y reconocer la expresión automáticamente en segmentos faciales humanos en secuencias de video, usando una arquitectura multi-nivel compuesta de una capa HMM y una del modelo de Markov. También se trataron de clasificar las expresiones faciales mediante técnicas de Inteligencia Artificial(IA) (Chang and Chen, 2001), para ello fue empleando una red Radial Basis Functions Neural(RBFN).El proceso inicia con la detección de los contornos mas relevantes del rostro, así como los puntos que rodean las zonas de cejas, ojos y labios de la imagen del rostro. A partir de ello, Chang define 30 puntos para describir tres características faciales (Chang and Chen, 2001), teniendo como fundamento las UAs propuestas por Ekman y Friesen (Ekman and Friesen, 1978). Los resultado obtenidos en ese trabajo llegaron a un ratio de alrededor de %, sobre las expresiones neutral, enojado y feliz. Una de las grandes dificultades de los trabajos anteriores está relacionado al hecho que trabajan sobre una de las formas de reconocimiento de movimiento (segmentación) lo cual es un proceso pesado según la literatura existente. Por otro lado, una gran parte de los trabajos relacionados al tema (Black et al., 1997; Essa, 1995; Rosenblum et al., 1994; Yacoob and Davis, 1994) sólo discriminan un pequeño conjunto de emociones, los cuales están basados en el trabajo realizado por Charles Darwin. Adicionalmente, las anteriores técnicas no soportan eficazmente las traslaciones del rostro dentro de la secuencia de video Puntos faciales característicos El estudio de la morfología facial y la relación entre sus elementos (Kobayashi and Hara, 1992), nos permite suponer que una vez hallada la relación entre los componentes del rostro podemos seleccionar zonas características más relevantes con el fin de enmallar(marcarlas) para así estimar el grado de movimiento. Kobayashi y Hara en (Kobayashi and Hara, 1992), propone un plano del rostro para la selección de zonas catacerísticas; usando una RBFN logran reconocer expresiones con un ratio del 70 %. Posteriormente 62

63 Chang en (Chang and Chen, 2001), emplea una métrica similar para el reconcimiento de expresiones faciales, dichas métricas son las de la figura 1. Figura 1: Sistema de coordenadas para el sistema propuesto Esta referencia nos permite posicionar la malla sobre el rostro adecuadamente para lograr una correcta estimación del movimiento, sin importar la inclinación Arquitectura de la propuesta La idea principal de este trabajo se centra en clasificar los patrones de movimiento en las secuencias de imágenes del rostro situado frente al ordenador, para ello primero enmallamos el rostro y apartir de ese instante inicia el proceso de clasificación. Figura 2: Esquema de trabajo del reconocedor de expresiones 63

64 2. Reconocimiento de expresiones faciales con flujo óptico Dentro de nuestra propuesta están implicadas varias tecnologías, dentro de las cuales podemos nombrar: Detección de movimiento en secuencias de imágenes, seguimiento de objetos, clasificación de patrones entre los más importantes Detección de movimiento en imágenes Considerando (Izaguirre et al., 2001; Romero, 2002), para detectar objetos en movimiento en secuencias de imágenes existen diferentes tipos de aproximaciones, las cuales se pueden agrupar de la siguiente forma: Diferencia de imágenes Métodos basados en características Flujo óptico Métodos basados en regiones Por medio de la diferencia de imágenes se pueden encontrar los cambios que existen entre una imagen y otra. El costo computacional que se requiere invertir con este tipo de aproximación es reducido, en comparación con métodos donde se ejecuta correlación. Sin embargo, presenta el problema de no poder eliminar el ruido. Así mismo, la operación de diferenciación no proporciona información de cómo se llevó a cabo el movimiento, además detecta cambios de luz y sombra. Los métodos basados en características se apoyan en la elección de un conjunto de primitivas que corresponden a un rasgo distintivo de la escena. Con este método se debe tener conocimiento de la geometría de proyección, la posición tridimensional relativa y el movimiento, los tipos de primitivas usadas son por ejemplo: Líneas, bordes o esquinas. El problema con los métodos basados en características es que dependen de la forma de los objetos, es decir, pequeños cambios en la forma de los objetos implican una modificación del patrón de búsqueda. Las aproximaciones que se realizan por medio de flujo óptico, están basadas en el movimiento aparente de la intensidad de los patrones en la secuencia de imágenes. Este esquema está basado en dos suposiciones importantes: la primera de ellas está fundamentada en la observación, esto significa que aún cuando los objetos cambian de posición en la escena, su brillo debe permanecer constante, es decir, que la iluminación sea constante en el tiempo. Esta suposición es conocida como restricción de constancia de datos. La segunda suposición es conocida como la coherencia espacial, es decir, que los puntos de una superficie tridimensional correspondan a los mismos puntos de un vecindario pequeño de la imagen. Las aproximaciones realizadas por medio del flujo óptico caen dentro de dos grandes categorías: basados en correlación y en gradientes. Los métodos basados en correlación tienen un costo computacional elevado. Por otra parte los métodos que están basados en gradiente pueden ser computacionalmente eficientes, sin embargo, el uso de una ventana de análisis pequeña origina el problema de apertura. El problema se presenta cuando existe una insuficiente variación de los tonos de gris de las regiones consideradas en la imagen, por lo tanto más de un candidato se adapta a los datos de la imagen observada de la misma forma. 64

65 En imágenes de rostros si cumplen las suposiciones anteriores debido a que la forma del objeto es constante y no presenta diferentes intensidades a lo largo del tiempo. Finalmente, existen los métodos basados en regiones donde el problema central es segmentar los objetos en movimiento con respecto al fondo de la imagen. Una forma de estimar el movimiento de objetos por medio de esta técnica es mediante el apareamiento de regiones. Otra forma de realizar la operación de detección es a través de búsquedas de las regiones que definen a los objetos de interés entre un conjunto de cuadros, donde cada una de ellas experimenta un movimiento sencillo entre un par de imágenes consecutivas Clasificador de patrones El Modelo de clasificación elegido es el Support Vector Machine Multi Class(K-SVM), el cual es una implementación libre llamada LIBSVM (Hsu et al., 2008), basada en (Wu et al., 2003). Cabe resaltar que los autores por su experiencia indican que si hay miles de atributos puede ser necesario seleccionar un subconjunto de ellos antes de proporcionar los datos al clasificador SVM. Sin embargo en nuestro trabajo reducimos las muestras a vectores de 216 atributos reales, correspondientes a las zonas que contienen las UAs. 3. Flujo óptico El cálculo del flujo óptico que se usa en este proyecto se basa en el método de los gradientes y la ecuación de restricción del Flujo Óptico, formulada por Horn y Schunck (Horn, 1986): E x u + E y v + E t = 0 Esta ecuación es válida bajo condiciones de patrón de brillo de la imagen constante, y gradiente local de intensidad lineal. Desarrollando a partir de ella llegamos a una solución de tipo iterativa para cada uno de los componentes del flujo óptico: u = ū E x(e x ū + E y v + E t ) λ 2 + Ex 2 + Ey 2 v = v E y(e x ū + E y v + E t ) λ 2 + Ex 2 + Ey 2 (1) (2) Para la obtención de resultados válidos este algoritmo requiere un mínimo de textura en los objetos de la imagen, desplazamientos pequeños entre imágenes y el movimiento continuo de los objetos (Ballard and Brown, 1982), el algoritmo implementado y usado es el de Lucas & Kanade (B.D.Lucas and Kanade, 1981). Otro problema es el cálculo computacional como lo menciona G. Asensio (Asensio et al., 2007), donde indica que los métodos variacionales son especialmente útiles para resolver la ecuación de flujo óptico u(x) f(t, x) + t f(t, x) = 0, por que preservan las discontinuidades y funcionan incluso cuando hay variaciones de iluminación. Sin embargo, tienen alto costo computacional y demuestran que el método multimalla referente al cálculo es mucho mas eficientes. Tal método no es objeto de este trabajo, pero vemos que las tendencias ayudan a presumir una mayor efectividad del modelo propuesto. 65

66 4. Resultados 4.1. Datos empleados Para el entrenamiento del localizador de ojos se empleo la base de datos(fagertun and Stegmann, 2005), el cual cuenta con 240 imágenes de 40 personas sin lentes, de los cuales 33 son hombres y 7 son mujeres, a una resolución de 640x480 en formato JPEG, de los cuales tomamos 480 muestras positivas de ojos, transformadas a una resolución de 20x10 y 5000 negativas de resolución variable. Para la obtención de imágenes se empleo una cámara CIF Single chip, con velocidad de 30 cuadros/seg a una resolución de 352x288pixels. El equipo dónde se realizaron las pruebas es una AMD ATHLON 2000XP+, con 304MB de memoria. Para la etapa de entrenamiento y prueba del clasificador se tomaron muestras de 33 individuos de los cuales 10 son del sexo femenino entre edades de 19 a 23 años, todos ellos estudiantes de pre-grado. las muestras se tomaron durante el día bajo condiciones normales de iluminación, las pruebas también se realizaron bajo las mismas condiciones, pero con individuos que no participaron en el entrenamiento Detección y seguimiento de ojos Antes de estimar el movimiento aparente en la escena, localizamos los ojos del rostro, para ello empleamos las técnicas de detección propuestas por Viola y Jones en (Viola and Jones, 2002). Obteniendo resultados como se muestra en las figuras 3 y 4. Figura 3: Localización de candidatos de ojos Figura 4: Seguimiento del par de ojos con punto medio marcado En la figura 3 se observa escenas con recuadros de color para cada candidato a ojo, empleando umbrales numéricos sobre este resultado logramos reducir solo a dos candidatos, los necesarios para posterimente poder calcular el centro (x 0, y 0 ) del par de ojos. La figura 4 muestra el centro calculado(x 0, y 0 ), basado en el sistema de coordenadas mostrado en la 66

67 figura 1. Cada extremo de la línea representa la posicion de cada ojo detectado. Una de las ventajas de nuestra propuesta frente a los métodos tradicionales de flujo óptico es dar libertad de inclinación hacia ambos extremos sin perturbar los resultados, así se puede observar en la figura Enmallado Denominamos enmallado al proceso de marcar pixeles en las zonas del rostro que contienen las llamadas UAs, estos pixeles marcados se visualizan en forma de puntos en las imágenes a) y b) de la figura 5. Mediante estos pixeles marcados podremos calcular el flujo óptico, es decir el movimiento aparente. Se puede observar el proceso de enmallado de nuestra propuesta en ejecución en la figura 6. En la figura 5 item a) muestra el enmallado tradicional; en forma de cuadrícula y aparentemente estática. En el item b) el enmallado cubre la zona del rostro y existe mayor flexibilidad puesto que nuestra propuesta hace un seguimiento del rostro permitiendo mayor libertad de movimiento, así se observa en la figura 6. Figura 5: Enmallado tradiconal frente a nuestra propuesta. Figura 6: Enmallado de rostro de nuestra propuesta. 67

68 4.4. Cálculo del flujo óptico Marcadas ya las zonas de interés, se inicia el proceso de cálculo de flujo óptico, para lo cual usamos el algoritmo de Lucas & Kande(B.D.Lucas and Kanade, 1981). Mediante el cual, sabremos las nuevas posiciones de nuestros pixels marcados(estimación de movimiento aparente), obteniendo así vectores de 216 atributos, los cuales contienen información en módulo y dirección de nuestros pixels marcados. Estos vectores intercalados y en grupos de 6 por segundo(nuestra cámara adquiere a 30 frames/seg.), son etiquetados y almacenados en un repositorio, para posteriormente entrenar el clasificador (Hsu et al., 2008). Las muestras de cada expresión son las transiciones de la estado facial normal o neutro hacia los demás estados como son alegría, sorpresa, ira, tristeza miedo y asco Clasificación de la expresión facial Entrenado el clasificador (Hsu et al., 2008), con las muestras que constan de grupos de 6 vectores, esta cantidad fue estimada empíricamente, pudiendo observar lo siguiente: La transición de una expresión facial a otra varia en tiempo, se tiene por ejemplo el cambio de neutro a feliz demora mas que de neutro a sorpresa. Se muestra un resumen de las evaluaciones por expresión en la figura 7. Figura 7: Resumen de resultados obtenidos, con nuestra propuesta. Los items Frames y Ratio nos explican el proceso de medición de nuestra propuesta, por ejemplo en el caso de Alegria se tomaron un promedio de 98 frames, de los cuales nuestra propuesta detectó 8 frames en estado Neutro, 74 Alegre, 8 Sorpresa, 3 Enojo, 1 Tristeza, 2 Miedo y 2 Asco, logrando un ratio de %. 68

69 5. Conclusiones La consideración de la geometría facial para enmallar el rostro que contienen la UAs, marcando los pixel candidatos para el cálculo del flujo óptico, permite reducir la dimensión de los vectores característicos de las expresiones faciales. La estimación de expresiones faciales no solo debe considerar el cambio de las zonas que incluyen las UAs, sino también los tiempos de transición de una expresión a otra. Las pruebas realizadas del modelo nos permitieron observar que las expresiones de alegría, sorpresa, enojo y asco, son las más detectables siendo las otras: Tristeza y miedo poco perceptibles, la tristeza por que su transición es lenta y el miedo por ser una mezcla de expresiones. Referencias Arias, M. G. (2005). Valoración del efecto de diferentes fuentes de información sobre el reconocimiento de emociones en un contexto conversacional. PhD thesis, Universidad de Chile, Facultad de Ciencias Sociales. Asensio, G., Gonzalez, P., Platero, C., J.M.Poncela, J.Sanguino, and M.C.Tobar (2007). Métodos multimalla en problemas lineales de flujo óptico. Ballard, D. and Brown, C. (1982). Computer Vision. Prentice-Hall. B.D.Lucas and Kanade, T. (1981). An iterative image registration technique with an application to stereo vision. in Proceedings of Imaging Understanding Workshop, pages Black, M. J., Yacoob, Y., Jepson, A. D., and Fleet, D. J. (1997). Learning parameterized models of image motion. In IEEE Proc. Computer Vision and Pattern Recognition, CVPR-97, pages , Puerto Rico. Chang, J. Y. and Chen, J. L. (2001). Automated facial expression recognition system using neural networks. Journal of the Chinese Institute of Engineers, 24(3): Cohen, I., Sebe, N., Garg, B. A., Chen, C. L. S., and A, T. S. H. (2003). Facial expression recognition from video sequences: Temporal and static modeling. In Computer Vision and Image Understanding, pages Cohn, J. F., Ambadar, Z., and Ekman, P. (2005). Running head: Facial action coding system. University of Pittsburgh and University of California at San Francisco. Observer-Based Measurement of Facial Expression with the Facial Action Coding System. Ekman, P. (1993). Facial expression and emotion. 48(4): Ekman, P. and Friesen, W. (1978). The facial action coding system: A technique for measurement of facial movement. Essa, I. (1995). Analysis, interpretation, and synthesis of facial expressions. Fagertun, J. and Stegmann, M. B. (2005). The imm frontal face database. Informatics and Mathematical Modelling. Horn, B. (1986). Robot Vision. Ed Mc Graw-Hill. Hsu, C. W., Chang, C. C., and Lin, C. J. (2008). A Practical Guide to Support Vector Classification. Departament of Computer Science, National Taiwan University, Taipei 106, Taiwan. 69

70 Izaguirre, A. Z., Gonzales, J. L. M., and Lopez, L. A. (2001). Determinación del movimiento a partir de secuencias de imágenes. Kobayashi, H. and Hara, F. (1992). Recognition of mixed facial expressions by neural network. IEEE International workshop on Robot and Human Communication, pages Romero, I. O. (2002). Detección y seguimiento de objetos en imágenes infrarrojas usando información temporal. Master s thesis, Instituto nacional de astrofisica óptica y electrónica. Rosenblum, M., Yacoob, Y., and Davis, L. S. (1994). Human emotion recognition from motion using a radial basis function network architecture. Technical Report CS-TR Viola, P. and Jones, M. (2002). Robust real-time object detection. International Journal of Computer Vision - to appear. Wu, T. F., Lin, C. J., and Weng, R. C. (2003). Probability estimates for multi-class classification by pairwise coupling. Yacoob, Y. and Davis, L. (1994). Recognizing Human Facial Expressions. Technical Report CS-TR

71 Extensão da UML para Representação de Modelagem de Negócios Baseada em Visões Silvia Angelica Zanco Ladeira 1, Rodrigo Funabashi Jorge 2, Rosângela A. Dellosso Penteado 3, Maria Istela Cagnin 2 1 Centro Universitário Eurípides de Marília (UNIVEM), Programa de Pós-Graduação em Ciência da Computação, Cep Cx. Postal Marília/SP 2 Universidade Federal da Grande Dourados (UFGD) Faculdade de Ciências Exatas e Tecnologia, Caixa Postal 322,CEP Dourados/MS 3 Universidade Federal de São Carlos (UFSCar) Departamento de Computação, Caixa Postal 676, CEP São Carlos/SP silvia@univem.edu.br, {funabashi, istela}@ufgd.edu.br, rosangel@dc.ufscar.br Resumo A modelagem de negócio é uma documentação imprescindível para as empresas uma vez que registra principalmente os processos de negócio, os responsáveis pela execução de tais processos e as regras de negócio neles envolvidas. Tais regras representam as peculiaridades de cada empresa, garantindo a sua competitividade no ramo de negócio em que atua. No entanto, para que todos os interessados possam entender corretamente e efetivamente o negócio é necessário que a técnica de modelagem que está sendo utilizada forneça uma representação simples e de fácil comunicação. Assim, neste artigo é proposta uma notação gráfica, baseada em UML, para a representação da modelagem de negócios em três visões distintas: de papéis, de processos e de regras de negócio. Um exemplo de uso é apresentado para ilustrar a notação gráfica proposta. 1. Introdução A modelagem de negócios é uma técnica da Engenharia de Requisitos que visa, principalmente, apresentar o funcionamento do negócio, considerando tanto os processos quanto as regras de negócios envolvidas, os objetivos que devem ser atingidos pelo negócio, bem como os responsáveis por alcançar tais objetivos. Assim, pode-se afirmar que a modelagem de negócio é a explicitação do conhecimento do negócio que está, na maioria das vezes, incorporado nos interessados (stakeholders) que fazem parte do negócio (ou seja, diretores, funcionários, etc). Sob essa perspectiva, é importante e imprescindível que as empresas tenham documentação do seu negócio a fim de que todos possam compartilhar desse conhecimento. Adicionalmente, essa documentação elimina os riscos que a empresa pode ter quando o responsável e/ou detentor desse conhecimento deixa de fazer parte do quadro de colaboradores da mesma. No entanto, para que essa documentação seja entendida por todos, é necessário que a técnica de modelagem de negócios utilizada considere, entre outras coisas, a simplicidade de representação do negócio e a facilidade de comunicação entre os envolvidos. A modelagem de negócios baseada em visões é tratada por alguns autores [Eriksson e Penker, 2000; Marshall, 2000; Ladeira e Cagnin, 2007] para que os interessados possam obter o conhecimento necessário do negócio sob diferentes perspectivas utilizando uma única técnica. A UML (Unified Modeling Language) [Booch et al., 2005] é uma linguagem de modelagem que oferece um conjunto de artefatos que facilita a elaboração dos modelos de negócios, além de permitir que sejam adaptados mecanismos de extensibilidade, tais como, estereótipos e restrições, para representar claramente conceitos como: processos, objetivos, recursos 1 e regras de negócios 1 Recurso pode ser um material, pessoa, informação, sistema de informação, etc [Eriksson e Penker, 2000]. 71

72 [Eriksson e Penker, 2000; Zrnec et al., 2001; Johnston, 2004], possibilitando maior compreensão dos modelos e, conseqüentemente, do negócio. Diversas notações de modelagem de negócios apoiadas por UML [Eriksson e Penker, 2000; Marshall, 2000; Zrnec, 2001; OMG, 2003; Johnston, 2004; OMG, 2008] foram analisadas, entretanto, notou-se que embora elas atendam perfeitamente a todos os objetivos de modelagem de negócio aos quais se propõem, não possuem em sua notação gráfica todos os elementos necessários para a construção da representação gráfica que possibilite à empresa ver seu negócio de maneira uniforme e simplificada sob as três óticas definidas por Ladeira e Cagnin [2007]. Este artigo apresenta a notação de representação gráfica da técnica de modelagem de negócios proposta por Ladeira e Cagnin [2007] baseada em três visões: a de papéis, a de processos e a de regras de negócios, usando como base os diagramas de objetos e de atividades. Essa representação tem como diferencial o fato de que a empresa pode documentar quais os envolvidos que realizam os processos do domínio do negócio (papéis), quais as atividades que devem ser executadas para alcançar o objetivo de cada processo do negócio e quais as restrições necessárias para a operacionalização do sistema (regras de negócio). Além desta seção introdutória, este artigo está organizado de acordo com a estrutura descrita a seguir. Na Seção 2 são comentados alguns trabalhos relacionados que tratam da notação de modelagem de negócio. Na Seção 3 é apresentada uma visão geral da técnica de modelagem de negócios baseada em visões aqui proposta, com a exemplificação por meio do domínio workflow [Cruz, 2006]. Na Seção 4 é apresentada a proposta da notação gráfica para modelagem de negócios baseada em visões tomando como base a UML. A representação gráfica das visões é exemplificada por meio do domínio workflow apresentado na Seção 4. Na Seção 5 são apresentadas discussões e limitações do trabalho, bem como sugestões de trabalhos futuros. 2. Trabalhos Relacionados De acordo com Eriksson e Penker [2000], a UML tem se firmado como uma linguagem de modelagem padrão para sistemas de informação e tem capacidade para realizar a modelagem de negócios. Os diagramas mais utilizados na fase inicial de modelagem são: diagrama de classes, diagrama de objetos e diagrama de casos de uso. Esses diagramas refletem uma visão específica de cada característica do negócio e podem ser usados com diferentes interesses de representação do negócio por cada autor. Alguns autores [Eriksson e Penker, 2000; Marshall, 2000; Zrnec et al., 2001] têm adaptado mecanismos de extensibilidade tais como estereótipos e restrições, para representar claramente conceitos como: processos, objetivos, recursos e regras de negócios, que são conceitos tratados pela modelagem de negócios e que os diagramas da UML, unicamente, não conseguem representar. Complementando os diagramas e os mecanismos de extensão, há também a recomendação da utilização de OCL (Object Constraint Language) da UML para especificar as regras e restrições na modelagem de negócios [Warmer e Kleppe, 1999]. Eriksson e Penker [2000] propuseram quatro visões distintas para a modelagem do negócio: visão do negócio (objetivos), visão do processo (atividades), visão da estrutura (recursos e organizacional) e visão do comportamento (comportamento individual de cada recurso ou processo). Tais visões são representadas por meio dos diagramas da UML. Na visão do negócio os autores utilizam o diagrama de classes para representar o modelo conceitual do sistema. Esse diagrama mostra os conceitos importantes do negócio e seus relacionamentos, proporcionando maior compreensão do domínio do negócio. Ainda na visão do negócio, Eriksson e Penker utilizam o diagrama de objetivos, baseado no diagrama de objetos, para representar os objetivos do negócio, descrevendo-os como objetos e evidenciando as relações de dependências entre eles. 72

73 Na visão do processo, é utilizado o diagrama ou modelo de processos, baseado no diagrama de atividades e composto por elementos estereotipados, para descrever quais são os processos alocados para alcançar os objetivos da organização. Na visão da estrutura, o diagrama de objetos é usado para representar a estrutura da organização. Na visão do comportamento, é utilizado o diagrama de seqüência para as interações dos processos de negócio e unidades organizacionais. Marshall [2000] salienta que negócios são refletidos por meio de relacionamentos entre entidades e que o diagrama de classes da UML descreve bem esses relacionamentos. O autor adota o diagrama de classes para as visões de negócio, de estrutura e organizacional na fase inicial da modelagem de negócios, considerando que em todas as visões os artefatos (objetivos, papéis) podem ser identificados por entidades e relacionamentos. Na fase de identificação dos processos de negócios, Marshall utiliza o diagrama de casos de uso para captar os requisitos básicos do sistema, por meio da definição de como eles são utilizados pelos atores. As funções executadas pelos atores relatam como os processos de negócios acontecem. O autor utiliza também, na identificação de processos de negócios, o diagrama de atividades como representação formal das dependências entre processos. Zrnec et al [2001] retratam a modelagem de negócios na visão da estrutura organizacional, do fluxo de dados e de processos de negócios. A visão da estrutura organizacional representa a departamentalização de uma organização, semelhante ao que é feito por Eriksson e Penker [2000], utilizando o diagrama de objetos da UML. A visão de fluxo de dados é representada pelo diagrama de casos de uso e ilustra o fluxo de dados de um domínio do negócio. A visão de processos de negócios é representada pelo diagrama de atividades e ilustra os processos de negócios associados a cada papel da organização. Como pôde ser observado, os autores utilizam diagramas e estendem a notação da UML, quando necessário, para apoiar a criação de modelos, adaptando os conceitos dessa linguagem para o contexto de modelagem de negócios, apresentando diferentes visões de uma organização [Eriksson e Penker, 2000; Zrnec et al., 2001; OMG, 2003; Johnston, 2004; OMG, 2008]. Outra iniciativa é a UML profile [OMG, 2003], um exemplo de perfil que descreve como a UML pode ser padronizada para modelagem de negócios. Todos os conceitos tradicionais da UML podem ser adotados para a modelagem de negócios, mas a especificação de estereótipos e a terminologia apropriada para esse tipo de modelagem tornam a especificação do negócio mais clara e precisa. A definição da UML profile para modelagem de negócios traduz claramente a preocupação na criação de artefatos complementares para tratamento específico da modelagem de negócios e é utilizada nessa disciplina do RUP (Rational Unified Process) [Krunchten, 2000]. Ao se observar as propostas de modelagem de negócios de diversos autores [Eriksson e Penker, 2000; Zrnec et al., 2001; OMG, 2003; Johnston, 2004; OMG, 2008], foi observada a importância em identificar uma representação por meio da qual a empresa pudesse ilustrar os envolvidos no processo e as restrições que devem ser consideradas para que o sistema produzido seja de qualidade, e não apenas a visão de processos de negócios. Dessa forma, foi criada a representação da técnica de modelagem proposta por Ladeira e Cagnin [5] em que apenas a visão de processos de negócio dos demais autores se assemelha a essa. As demais visões retratadas pelos outros autores têm enfoque diferente do proposto neste trabalho, como pode ser observado na próxima seção. 3. Modelagem de Negócios baseada em Visões proposta por Ladeira e Cagnin Eriksson e Penker [2000] salientam que um modelo de negócios deve ser composto de visões, sendo que cada visão capta uma ou mais particularidades do negócio e que várias visões são necessárias para apresentar o contexto completo do negócio. 73

74 As visões de papéis, processos de negócios e regras de negócios descritas nesta seção têm como finalidade apresentar o contexto do domínio do negócio, enfatizando as particularidades importantes do negócio [Ladeira e Cagnin, 2007]. A visão de papéis ilustra o papel desempenhado por cada ator para atingir os objetivos organizacionais. Nessa visão são retratados os papéis, os objetivos de negócios, do ponto de vista da responsabilidade de cada papel e de quais são os recursos utilizados ou produzidos. Podem ocorrer entre os papéis os relacionamentos de dependência e herança, que também podem ser ilustrados nessa visão. A visão de regras de negócios apresenta as regras de negócios que controlam a operacionalização do sistema, definindo ou restringindo ações com a finalidade de alcançar os objetivos no domínio do negócio. Nela são ilustrados os objetivos organizacionais, a relação de dependência entre eles e as regras de negócios associadas à obtenção dos objetivos. A visão de processos de negócios apresenta os processos que são compostos por atividades que devem ser executadas de maneira ordenada e controlada para que se possa alcançar um determinado objetivo. O processo do negócio envolve a participação de recursos e relacionamentos. Nessa visão estão representados os papéis, já determinados na visão de papéis, o fluxo de processos de negócios (conjunto de atividades) vinculados a cada papel, os objetivos e os recursos associados a cada um desses processos. Para ilustrar os conceitos representados na modelagem de negócios de cada visão, é utilizado um exemplo mostrando a modelagem de negócios do domínio workflow. Workflow é definido pela Workflow Management Coalition (WfMC) 2 como sendo a automação total ou parcial de processo de negócio, em que documentos, informação ou tarefas são passadas de um participante para outro, em conformidade com as regras de procedimentos [Cruz, 2006]. O domínio workflow abrange principalmente a requisição de atendimento a uma solicitação que dispara a execução de um ou mais processos de negócios, de forma que o fluxo de processos de negócios seja executado com a finalidade de prestar atendimento à solicitação. Na visão de papéis do domínio workflow pode-se observar que existem dois papéis envolvidos no negócio: o de quem faz a solicitação (Usuário Cliente) e o de quem fornece o atendimento (Usuário Fornecedor). Para cada papel obtêm-se quais os objetivos estão sob sua responsabilidade. O Usuário Cliente tem como responsabilidade criar uma solicitação, um objetivo a ser alcançado. Esse objetivo pode ser apoiado por um recurso (material, pessoa, informação, etc) utilizado ou produzido. Por exemplo, a utilização de um documento anexo descrevendo dados da solicitação ou a produção de uma solicitação impressa. O papel do Usuário Fornecedor tem como responsabilidade prestar o atendimento à solicitação e pode ser apoiado pela utilização de um recurso, por exemplo, um documento anexo ou um sistema de informação. Na visão de processos de negócios tem-se o fluxo de processos de negócios vinculado a cada papel, com a finalidade de alcançar os objetivos organizacionais. No domínio workflow, o Usuário Cliente é responsável por iniciar o fluxo de um processo de negócio. Ele cria uma solicitação, podendo ou não anexar um documento. Após a criação, uma notificação é enviada ao Usuário Fornecedor. O Usuário Cliente também pode realizar o acompanhamento da solicitação, caso o atendimento não seja satisfatório, deve devolver a solicitação ao atendente com um parecer informativo. Caso contrário, o usuário finaliza o atendimento encerrando assim o fluxo do processo de negócio. O papel Usuário Fornecedor é responsável por prestar atendimento à solicitação criada pelo Usuário Cliente. Isso pode ser realizado diretamente pelo responsável no atendimento (Usuário Fornecedor) ou pode participar de um sub-fluxo dentro do processo até que

75 o atendimento retorne ao responsável direto e seja encaminhado ao solicitante (Usuário Cliente). O Usuário Fornecedor também pode anexar um documento para auxiliar o atendimento. Quando um atendimento é encerrado, uma notificação é enviada ao solicitante. Na visão de processos de negócios tem-se, portanto, a identificação: dos papéis envolvidos (idênticos a visão de papéis), das atividades executadas por cada papel, dos recursos envolvidos nestas atividades (documento anexo, notificação) e dos objetivos alcançados. Ressalta-se que apenas os objetivos considerados relevantes para a modelagem de negócios são descritos nas visões. Objetivos não relevantes podem ser descritos como aqueles que não possuem importância na modelagem de negócios, pois muitas vezes estão implícitos no processo. Por exemplo, no domínio workflow, o Usuário Cliente executa o processo de monitoramento da solicitação, o qual tem a função de fornecer um acompanhamento do atendimento à solicitação, ou seja, o objetivo é encontrar a solicitação e mostrar os dados do atendimento. Como pode ser observado o objetivo do processo está descrito pela própria função, assim, não existe a necessidade de identificá-lo também na visão de processos de negócios. As regras de negócios que servem para restringir ou acionar algum evento visando alcançar os objetivos da organização são descritas na visão de mesmo nome, estão diretamente associadas aos processos de negócios e podem ser melhor compreendidas por meio deles. Os processos podem ser relacionados às regras de negócios por meio do objetivo em comum entre as duas visões, de processo e de regras de negócio. No domínio workflow para que o objetivo de prestar o atendimento possa ser alcançado, devem ser construídas regras de negócios para controlar como o atendimento é realizado. Considere a regra: quando uma resposta foi definida como encaminhar solicitante, o sistema envia automaticamente uma notificação ao solicitante, que dispara um evento de envio de uma notificação ao Usuário Cliente. A regra é indispensável para o sucesso na obtenção do objetivo. Ressalta-se também que todos os objetivos do domínio do negócio são representados nesta visão, ilustrando-se a relação de dependência existente entre eles. 4. Extensão da UML para Modelagem de Negócios A adoção de uma técnica de modelagem de negócios deve levar em consideração, entre outras coisas, os artefatos disponíveis para construção dos modelos, a simplicidade de notação e a facilidade de comunicação, bem como a compreensão dos interessados. Utilizando algumas notações de modelagem de negócio baseada em UML [Eriksson e Penker, 2000; Zrnec et al., 2001; OMG, 2003; Johnston, 2004; OMG, 2008] como referência, a notação gráfica proposta busca fornecer as características citadas no parágrafo anterior e abrangendo todas as três visões existentes na técnica de Ladeira e Cagnin [2007]. A ferramenta utilizada para a modelagem foi a Rational XDE [IBM, 2002], embora possa ser modelada utilizando qualquer ferramenta que apóie modelagem em UML. No Quadro 1 são apresentados os elementos existentes na notação proposta, sua descrição e os estereótipos (criados ou adaptados) utilizados na representação da modelagem de negócios baseada em visões aqui apresentada. Os diagramas para representação da modelagem de negócios adotados são os de objetos e de atividades. Em cada diagrama são adicionadas adaptações de estereótipos baseados em outros diagramas da UML, para possibilitar melhor compreensão de cada visão. Esses estereótipos são descritos a seguir e o uso dos principais deles em cada visão está resumido no Quadro 2. <<Business Actor>> identifica o papel do ator no domínio do negócio. Ele é ilustrado na visão de papéis com a finalidade de mostrar as responsabilidades do ator. Na visão de processos de negócios, descreve por meio de quem os processos de negócios são executados. 75

76 Elemento Descrição Estereótipo Evento de início Início do processo de negócio. (Start Event) Evento final Fim do processo de negócio. (End Event) Raia (Swinlane) É usada como uma partição que abrange um papel e todos os elementos envolvidos no contexto do papel. Papel (Business Actor) Processo do Negócio (Business Process) Recurso (Resource) Objetivo (Objective) Regra de Negócio (Business Rule) Decisão (Gateway) Anotação (Note) Barra de Sincronização (Synchronization Bar) Transição ou Associação (Transition or Association) Dependência (Dependence) Ligação do recurso (Resource link) Descreve uma abstração (humano ou software) que representa um papel. Descreve um processo de negócio que pode ser formado por uma atividade ou um conjunto de atividades. Identifica um artefato necessário ou produzido no fluxo do processo. Define um objetivo que o processo deve alcançar. Descreve a regra de negócio para a obtenção do objetivo. A decisão é usada para controlar a divergência e a convergência do fluxo. Determina a ramificação, bifurcação ou junção de uma seqüência do fluxo. Usada para acrescentar uma informação. Especifica a bifurcação ou a união de fluxo paralelos. Mostra a transição de uma atividade para outra no fluxo do processo ou uma associação entre um objeto e outro do diagrama. Descreve a dependência entre objetos. Indica se um recurso pode ser utilizado ou produzido em um processo. «BusinessActor». «Business Process» «Resource» «Business Goal» «Business Rule» Ligação do Papel (Role link) Indica a responsabilidade de um papel. Fluxo de Sub- Processos (selftransition) Indica a execução de sub-processos dentro de um processo de negócio Quadro 1: Notação gráfica da modelagem de negócios baseada em visões <<Business Actor>> identifica o papel do ator no domínio do negócio. Ele é ilustrado na visão de papéis com a finalidade de mostrar as responsabilidades do ator. Na visão de processos de negócios, descreve por meio de quem os processos de negócios são executados. <<Business Process>> descreve a execução de uma atividade na visão de processos de negócios. As atividades estão diretamente associadas aos papéis do domínio, bem como também 76

77 podem estar os recursos utilizados ou produzidos na execução de uma atividade e os objetivos alcançados. O estereótipo <<Resource>> identifica na visão de papéis a utilização ou produção de um recurso na obtenção de um objetivo associado a um papel. Já na visão de processos de negócios a identificação do recurso está associada à execução de um processo de negócio, ou seja, o processo de negócio usa ou produz um recurso. <<Business Goal>> identifica um objetivo a ser alcançado no domínio do negócio. Na visão de papéis ele está relacionado à responsabilidade do papel, pois o cumprimento desta responsabilidade passa a ser um objetivo a ser alcançado pelo papel. Na visão de processos de negócios ele descreve o objetivo alcançado no processo. Ressalta-se que todos os objetivos identificados na visão de papéis são os mesmos descritos na visão de processos de negócios. Na visão de regras de negócios <<Business Goal>> identifica todos os objetivos do domínio, bem como a relação de dependência entre eles. <<Business Rule>> é definida na visão de regras de negócios para identificar as regras de negócios que controlam a obtenção do objetivo. Um objetivo pode estar associado a zero ou mais regras, bem como, uma regra pode servir para alcançar um ou mais objetivos. Estereótipo Visão de papéis Visão de processos Visão de regras de negócios <<Business identifica o ator do descreve por quem são - Actor>> domínio do negócio executados os pro-cessos de negócio <<Business - descreve a execução de uma - Process>> <<Resource>> <<Business Goal>> <<Business Rules>> identifica utilização ou produção de um recurso para a obtenção de um objetivo identifica um objetivo a ser alcançado pelo responsável (papel) atividade identifica utilização ou produção de um recurso na execução de um processo identifica um objetivo a ser alcançado pelo processo, que identifica todos os objetivos do domínio, bem como a por sua vez está sob a relação de dependência entre responsabilidade do papel eles - - identifica as regras de negócios que controlam a obtenção do objetivo. Quadro 2: Utilização dos principais estereótipos da notação proposta em cada visão Na modelagem de negócios a interligação dos objetos é feita por meio dos relacionamentos, que identificam, entre outras características, a direção e a semântica entre os objetos. Para essa notação foram definidos alguns relacionamentos com estereótipos padrão (<<uses>>, <<produces>>, etc) a serem utilizados principalmente nas visões de papéis e de processos de negócios. Para os relacionamentos de dependência ou de associação, com exceção dos relacionamentos em que a semântica já está implícita no seu tipo (por exemplo, herança), a notação estabelece que deve ser identificada a semântica de interligação dos objetos, ou seja, a nomeação significativa de relacionamento entre os objetos, de modo a oferecer maior clareza e compreensão dos modelos. Retomando ao exemplo da modelagem de negócios baseada em visões do domínio workflow, apresentado na Seção 3, a notação gráfica para representação da modelagem de negócios baseada em visões, de parte desse domínio, está ilustrada nas Figuras 1, 2 e 3. A visão de papéis (Figura 1) mostra para cada papel o objetivo de sua responsabilidade. Por exemplo, Criação da solicitação usa o recurso Anexo da solicitação e produz o recurso - 77

78 Solicitação; enquanto que Atendimento à solicitação produz os recursos Resposta e Anexo da resposta. Nessa figura foi direcionado para cada papel um objetivo, embora em um domínio possam existir mais de um objetivo para cada papel. A visão apresenta também a relação de herança entre papéis, como ocorre com Usuário Cliente e Usuário Fornecedor que herdam os papéis de Usuário. «uses» «Resource» Anexo da Solicitação «Business Actor» Usuário Cliente - is reponsible for «Business Goal» Criação da Solicitação «produces» «Resource» Solicitação «Business Actor» Usuário «Business Actor» Usuário Fornecedor - is responsible for «Business Goal» Atendimento à Solicitação «produces» «produces» «Resource» Resposta «Resource» Anexo da Resposta Figura 1: Visão de papéis do domínio workflow A visão de regras de negócios (Figura 2) identifica os objetivos construindo a relação de dependência entre eles. A notação estabelece que os relacionamentos sejam nomeados de forma mais significativa para que possam facilitar a compreensão do relacionamento. Por exemplo, temse que o objetivo inicial a ser alcançado é Criação da Solicitação (1) e relacionado a ele tem-se o objetivo Oferecer uma resposta (2). Para que o objetivo 2 seja alcançado, o 1 já deve ter sido previamente realizado. Já os relacionamentos <<supports>> e <<resticts>> indicam que três regras de negócios controlam a obtenção do objetivo 2. «Business Goal» Criação da Solicitação - waits «Business Goal» Oferecer uma resposta supports supports «Business Rule» Resposta em atraso gera notificação via ou sms para superior hierárquico «Business Rule» Quando uma resposta foi definida como "encaminhar solicitante", o sistema envia automaticamente a resposta para o solicitante - allow «Business Goal» Finalizar a Solicitação restricts «Business Rule» Parecer só é permitido para responsáveis definidos no processo Figura 2: Visão de regras de negócios do domínio workflow A visão de processos de negócios (Figura 3) mostra para cada papel, quais são os processos de negócios que executam, apresentando-os de forma ordenada e integrada. Para cada processo pode ser identificado um ou mais recursos. Por exemplo, recursos Anexo, Solicitação impressa e Notificação do processo Criação da solicitação explicitando no relacionamento a 78

79 forma de interação por meio dos estereótipos <<uses>> e <<produces>>. Podem ser identificados também os objetivos organizacionais alcançados pelo processo. Por exemplo, o objetivo Iniciar um processo do processo Criação da solicitação. Nota-se que um processo pode ser composto por subprocessos e isto deve ser indicado no modelo. Como exemplo, tem-se o processo Atendimento à Solicitação, o qual é composto por subprocessos e está representado no modelo pelo elemento selftransition do diagrama de atividades. Para identificar a relação entre as regras e os processos de negócios, é necessário observar os objetivos alcançados por cada processo na visão de processos e as regras de negócios associadas a tais objetivos na visão de regras de negócios. Por exemplo, o objetivo Oferecer uma resposta associado ao processo Atendimento à solicitação na visão de processos (Figura 3) está relacionado às três regras de negócios ilustradas na Figura 2. Observa-se que na representação da visão de processos de negócios é possível obter uma visão geral de todo o negócio, ou seja, está representada a maioria dos elementos de todas as visões, conforme pode ser constatado no Quadro 2, e como eles interagem entre si, fornecendo assim uma representação geral e simplificada de todo o negócio. «Business Actor» (3) Usuário Cliente «Business Actor» (4) Usuário Fornecedor «Business Goal» Iniciar im proces... «Resource» Anexo «uses» «Resource» Solicitação impres... «Resource» Notificação ( /s... «produces» «Business Proces... Criação da Solicitação «produces» /retorna «produces» /dispara «Business Proces... Atendimento à Solicitação «Business Goal» Oferecer uma respos... «produces» «Resource» Anexo «produces» «Resource» Notificação ( /s... «Business Process» Monitoramento da Solicitação /dispara /permi... atendimento satisfatório? «Business Process» Monitoramento de tarefas Ok «Business Process» Encerra Solicitação Figura 3: Visão de processos de negócios do domínio workflow Salienta-se que, dependendo da complexidade do negócio, é possível modularizar sua representação por meio da utilização de pacotes, a fim de não prejudicar a clareza da notação proposta. 79

80 5. Considerações Finais A elaboração de uma notação gráfica simplificada para modelagem de negócios baseada em visões tem como finalidade proporcionar aos interessados maior facilidade na compreensão do domínio do negócio. A notação proposta é composta por um conjunto reduzido de elementos que facilitam a semântica da modelagem de negócios baseada nas visões de papel, de processos e de regras de negócios. A elaboração da notação proposta foi realizada com estudos de casos prospectivos, sendo um deles apresentado parcialmente neste artigo como exemplo de uso de tal notação. A partir dos estudos de caso observou-se que o conjunto de elementos gráficos definidos para a notação da modelagem atendeu satisfatoriamente aos modelos das visões de Ladeira e Cagnin [Ladeira e Cagnin, 2007]. Ressalta-se porém que podem ser adicionados novos elementos (baseados na UML) visando atender às situações não previstas por esta notação de modo a complementá-la. Observa-se que para avaliar a eficiência da notação gráfica, deve-se aplicá-la em domínios de negócios com maior nível de complexidade e maior conjunto de artefatos, tornando possível criar elementos adicionais baseados nas particularidades desses domínios. Completando o trabalho proposto neste artigo, está sendo estudada a definição de um metamodelo que visa construir a representação dos modelos das visões de qualquer domínio, possibilitando o reúso da modelagem de negócios com a finalidade de facilitar a compreensão e o desenvolvimento de software de um domínio específico. Referências [Booch et al., 2005] Booch, G.; Rumbaugh, J.; Jacobson, I. (2005). Unified Modeling Language User Guide. Second edition. Addison-Wesley. [Cruz, 2006] Cruz, T. (2006). Uso e Desuso de Sistemas de Workflow: Porque as organizações não conseguem obter retorno, nem sucesso, com investimentos em projetos de workflow. Rio de Janeiro: E-Papers Serviços Editoriais. [Eriksson e Penker, 2000] Eriksson, H.; Penker, M. (2000). Business Modeling with UML Business Patterns at Work. John Wiley & Sons. [IBM, 2002] IBM Corporation. Rational XDE. (2002). Versão URL: ftp://ftp.software.ibm.com/software/ rational/docs/v2002_r2/xde_readme_sr.htm. Acesso em Outubro/2007. [Johnston, 2004] Johnston, S. (2004). Rational UML Profile for Business Modelling. Rational Sofware. Mar < Acesso em Setembro/2007. [Kruchten, 2000] Kruchten, P. The Rational Unified Process: An Introduction. (2000) Addison- Wesley, second edition. 298 p. [Ladeira e Cagnin, 2007] Ladeira, S. Z.; Cagnin, M.I. (2007) Guidelines for Business Modeling Elaboration based on Views drom Domain Information. In: 10 th Workshop on Requirements Engineering, Toronto-Canada. [Marshall, 2000] Marshall, C. (2000). Enterprise Modeling with UML Designing Successful Software through Business Analysis. Addison Wesley. [OMG, 2003] OMG (2003) Object Management Group - Unified Modeling Language. < Acesso em Setembro/2007. [OMG, 2008] OMG (Object Management Group). (2008). Business Process Modeling Notation (BPMN), Acesso em Agosto/2008. [Warmer e Kleppe, 1999] Warmer, J.B.; Kleppe, A.G. (1999). The Object Constraint Language: Precise Modelling with UML. Addison-Wesley. [Zrnec et al., 2001] Zrnec, A.; Bajec, M.; Krisper, M. (2001). Enterprise modelling with UML. Disponível em: < Acesso em Agosto/

81 Ferramenta Tutora no Desenvolvimento de Jogos Educacionais Franciele da S. Lewandowski 1, Adriana S. Pereira 1 1 Centro Universitário Franciscano (UNIFRA) Rua Dos Andradas, Santa Maria RS Brasil fran.lewski@gmail.com, apereira@unifra.br Resumo As novas tecnologias de informação proporcionam facilidades no meio didático da educação. Este artigo apresenta o desenvolvimento de jogos educacionais, apoiados por um agente que tem capacidade de auxiliar o aluno durante sua interação com o jogo. O agente proposto está baseado no conceito pedagógico, buscando respeitar o desenvolvimento individual e o aprendizado do aluno. Os jogos educacionais são: o Jogo da Senha, que estimula o raciocínio lógico, e o Espaço Matemático, que auxilia no aprendizado básico da matemática. Eles foram desenvolvidos no ambiente de programação Flash, tendo como público alvo crianças de primeira a terceira série do Ensino Fundamental. 1. Introdução A utilização do computador na Educação tem ocasionado grandes mudanças através do avanço das Tecnologias da Informação e Comunicação (TICs) nos métodos de ensino e aprendizagem. O devido fato se dá pelo domínio da informática na vida das pessoas, causando transformações tanto na sociedade, quanto na condição de ensino. Segundo as teorias das inteligências múltiplas de Gardner (1994), as pessoas não são dotadas de um mesmo conjunto de capacidades, sendo assim, nem todas aprendem da mesma forma, e não são dotadas de uma única inteligência e sim um conjunto delas. Através destas inteligências múltiplas o aluno é levado a aprender de forma natural e prazerosa. Com isso, o educador pode fazer uso de meios diversificados para o ensino, como os recursos informatizados. Por meio de jogos, o aprendiz explora as informações que o cerca aperfeiçoando sua capacidade mental, desenvolvendo e enriquecendo sua personalidade. O objetivo deste estudo é desenvolver softwares educacionais, na condição de jogos, que auxiliem o professor a ministrar suas aulas utilizando a tecnologia computacional disponível para ele e que atendam as atividades curriculares para garantir a formação dos indivíduos de forma motivadora para a nova realidade tecnológica, fundamentados em uma estrutura pedagógica utilizando agentes pedagógicos reativos, que guiam a interação e estímulo do aluno. Apresenta-se, neste artigo, o desenvolvimento do Jogo da Senha, que estimula o raciocínio lógico do aprendiz, podendo ser jogado em dupla ou somente com o computador. O outro jogo é o Espaço Matemático, este explora o conteúdo de matemática, visando ao aprendizado de forma mais agradável. São propostos os personagens chamados Dr. Burns e Nani, os quais são os agentes que acompanham cada aluno na sua interação com as atividades, auxiliando-os na tarefa de aprender, chamando atenção, elogiando, sugerindo escolhas, ajudando-os a compreender o jogo. O artigo está organizado nas seguintes seções: a seção 2 aborda uma visão geral do software educacional; na seção 3, descrevem-se, sucintamente, os agentes pedagógicos; a seção 4 expõe o 81

82 ambiente desenvolvido; na seção 5, são mostradas as características e o desenvolvimento do agente; na seção 6, apresentam-se os resultados obtidos e a seção 7 apresenta as considerações finais. 2. Software Educacional A capacidade que o computador tem de ensinar provoca uma revolução na Educação, pois o seu uso fundamenta-se na simples forma de informatização dos meios tradicionais de ensino, como na aplicação de atividades a partir de jogos educacionais. Ele visa a melhorar ambientes de aprendizagem, em que o aluno, agindo mutuamente com os objetos desse ambiente, absorve o conhecimento, e proporcionar aulas com maior relevância e melhoria qualitativa. Segundo Giraffa e Viccari (1998), o software educacional é um programa que, introduzido em uma situação de ensino-aprendizagem, propõe atender às necessidades educacionais com finalidades pedagógicas definidas. Os jogos são como uma ferramenta auxiliar do aluno na construção de seu conhecimento sistematizado. Esta sistematização, através do computador, possibilita melhor acompanhamento do aluno verificando seus erros mais freqüentes, além disso, apresenta recursos multimídia diferentes do modo convencional usado em sala de aula. Desta forma, contribui para o "processo de resgate do interesse do aprendiz, na tentativa de melhorar sua vinculação afetiva com as situações de aprendizagem" [Barbosa, 1998] Classificação O software educacional deve ser avaliado conforme sua função e não pela sua natureza. A classificação dos tipos de software inseridos na Educação podem ser em categorias, dependendo dos objetivos pedagógicos, eles são: tutoriais, exercícios e práticas, jogos, multimídia e Internet, aplicativos e modelagem e simulação. Segundo Taylor (1980 apud Zacharias), podemos classificar o uso educacional dos computadores em: Tutor, Ferramenta e Tutelado. Como Tutor, o computador desempenha o papel de professor, ou seja, o software instrui o aluno. Sendo ele muito utilizado, pois foi desenvolvido sob instrução programada e apresenta-se com o termo CAI (Computer Aidded Instruction), que significa Instrução Assistida por Computador, e possui uma estrutura de transmissão de conhecimento de caráter seqüencial, previamente determinada. Na forma de Tutelado, o software educacional realiza o processo em que o aluno instrui/ensina o computador. Para o software enquanto Ferramenta, os alunos aprendem a fazer uso do computador para manipular e adquirir conhecimento com aplicativos de uso geral. 3. Agentes pedagógicos Segundo Fernandes (2003), a Inteligência Artificial (IA) define-se como o estudo da computação que torna possível perceber, raciocinar e agir. A IA na Educação é uma nova metodologia de aprimoramento do conhecimento utilizada hoje em dia. 82

83 Os agentes são uma entidade, neste caso artificial, e podem ser definidos como qualquer entidade (humana ou artificial) que está imersa ou situada em um ambiente e percebe seu ambiente através de sensores e age sobre ele por meio de atuadores. Um agente executa seus objetivos próprios, explícitos ou implícitos, e seleciona suas ações devido às suas percepções para atingir seus objetivos. Os agentes que desempenham uma função educacional ou pedagógica, que facilitam ou melhoram o aprendizado do aluno, são chamados de agentes pedagógicos. Eles podem apresentar características de agentes reativos, reagindo às mudanças em ambientes nos quais eles são utilizados. Segundo Giraffa (1998 apud Pereira, 1999), podem ser classificados em: Tutores: aqueles destinados ao ensino dirigido ao aluno; Assistentes (Amigo): colaboram com a aprendizagem do aluno; Agente na Web: destinados à aplicação de ensino na Internet; Agentes mistos: aqueles que ensinam e aprendem. Os agentes pedagógicos acompanham os alunos na interação com o ambiente educacional, sendo hábeis de guiá-los à execução de suas atividades para aprender de maneira mais eficiente. A fundamental importância da inclusão de um agente pedagógico, no ensino, se dá pelo fato de ele trazer um feedback interativo e dinâmico entre o ambiente e o aluno e por tornar a comunicação mais persuasiva, exercendo a função de guia para o usuário. 4. Ambiente desenvolvido Para o desenvolvimento desses ambientes educacionais foram utilizadas as seguintes tecnologias: JUDE Professional para a modelagem UML, que descreve a seqüência de atividades com comportamento e paralelo, e o Adobe Flash CS3, que é muito utilizado no desenvolvimento de jogos educacionais devido à sua flexibilidade, oferecendo recursos e funcionalidades que os desenvolvedores necessitam, com um caráter pedagógico ideal. Utilizou-se a linguagem ActionScript que possui recursos e funcionalidades de uma linguagem de programação bem consistente e orientada a objetos. A metodologia de ensino-aprendizagem proposta pelos jogos é a execução de atividades práticas para trazer melhorias nas atividades curriculares Propriedades do Ambiente As novas circunstâncias favoráveis ao sistema educativo ocasionam um fator importante através das experiências da utilização do computador na Educação: o desenvolvimento de ambientes para o aprendizado. A criação de um ambiente que apóie o processo de aprendizagem e que desfrute das TICs necessita de um planejamento aplicado. Os ambientes de tarefas são o lugar, no qual os agentes atuam com suas soluções. O tipo de ambiente afeta diretamente o projeto adequado para o programa do agente. Ao se projetar um agente, na primeira etapa, devem-se individualizar os aspectos por completo do ambiente de tarefa, os quais definem o projeto apropriado do agente e sua aplicabilidade. 83

84 Para a atuação do agente desenvolvido, o ambiente apresenta-se acessível, ou seja, completamente observável, em que os sensores do agente possibilitam acesso ao estado completo do ambiente, detectando aspectos indispensáveis para a seleção de sua ação. O ambiente também é episódico, em que cada episódio de atividades realizadas pelo aluno baseia-se na percepção e na ação do agente. A escolha da ação depende somente do próprio episódio Metodologia A necessidade de pensar em um tema e definir os objetivos a serem alcançados, torna possível o desenvolvimento adequado de jogos educacionais. Para realizar o planejamento e modelagem do ambiente, juntamente com o agente proposto, foi elaborado um questionário com dez questões objetivas e uma dissertativa como sugestão, o qual foi enviado para a coordenação responsável de quatro escolas, as quais foram o alvo para a aplicação deste trabalho, algumas perguntas realizadas foram: Qual seu nível de conhecimento em informática? Que recursos a escola possui para o ensino? Há disponibilidade de uso freqüente do laboratório de informática? Você utiliza recursos de informática para a preparação das aulas? São propostas atividades utilizando o computador? Em qual área se deve dar mais ênfase utilizando os recursos computacionais? E quais séries? As escolas pesquisadas foram: Escola Estadual de Ensino Médio Lilia Guimarães (Uruguaiana RS) Escola Nossa Senhora do Horto (Uruguaiana RS) Instituto Laura Vicuña (Uruguaiana RS) E. M. E. F. CAIC Luizinho De Grandi (Santa Maria RS) A partir das respostas obtidas dos questionários, foram elaborados gráficos para estipular o perfil dos jogos. Percebeu-se que as áreas com maior necessidade de aplicação de recursos computacionais foram: matemática com 73,33% e lógica com 86,66%, para as séries iniciais do Ensino Fundamental. Foram criados os jogos com seus respectivos agentes, já citados anteriormente, de acordo com o público-alvo e suas necessidades. As atividades selecionadas para os jogos tiveram o apoio de professoras que participaram da pesquisa de campo. A aplicação desses jogos é possível, pois se contatou que há disponibilidade dos laboratórios de informática em todas as escolas, e a maioria dos professores possuem conhecimento de informática e já utilizam métodos diferenciados para a elaboração de aulas Modelagem dos jogos e agentes Foi utilizado o diagrama de atividades da UML, que descreve cada passo a ser realizado para a construção de cada um dos jogos e de cada agente, tendo assim uma visão da implementação. As figuras 1 e 2 apresentam as modelagens criadas. 84

85 Figura 1. Modelagem dos jogos Figura 2. Modelagem dos agentes Jogo da Senha O Jogo da Senha faz com que o aluno estimule o seu raciocínio lógico para auxiliar na resolução de problemas. O objetivo é descobrir a senha criada/gerada com até 12 tentativas, seguindo uma tabela de verificação das cores certas no lugar correto ou cores certas no lugar errado com o auxílio do agente. O aluno, nesse jogo, deverá pensar nas possibilidades das tentativas, e na senha pode haver repetição das cores. 85

86 A figura 3 apresenta a tela inicial do jogo, onde é possível criar a senha para outro colega adivinhá-la ou solicitar a geração da senha pelo computador. Na figura 4, apresenta-se a tela de ajuda do jogo, em que o aluno visualiza a explicação do agente. A figura 5 exibe a tela principal, onde se realizam as tentativas clicando nas cores na seqüência desejada, os marcadores, na tabela de verificação, indicam se o aluno acertou ou não a cor e sua ordem, representados pela bola preta, a cor certa no lugar certo, e pela bola cinza, a cor certa no lugar errado. A figura 6 mostra o resultado final e as respectivas quantidades de tentativas feitas, que podem ser analisadas pelo professor. Figura 3. Tela Inicial Figura 4. Tela Ajuda Figura 5. Tela Jogadas Figura 6. Tela Resultado Espaço Matemático O Espaço Matemático apresenta duas atividades básicas de matemática, que são de fundamental importância para as séries iniciais do Ensino Fundamental. O objetivo do jogo é realizar a contagem das estrelas e, na seqüência, a subtração delas, informadas através dos números presentes na tela. Na figura 7, apresenta-se a tela inicial do jogo, na qual se pode informar a quantidade de questões a responder. A figura 8 mostra a tela de ajuda. A figura 9 exibe a tela da primeira parte do jogo onde o aprendiz deve contar as estrelas presentes no espaço e informar a quantidade correta clicando nos números presentes na parte inferior da tela. Na figura 10, está a segunda parte do jogo, onde deve ser informada a quantidade de estrelas que foram embora, sendo que é apresenta na tela somente as estrelas que restaram. A figura 11 indica o resultado das respostas corretas e incorretas. Na figura 12, apresenta-se a possibilidade de impressão do resultado, incluindo a identificação do aluno, a qual pode ser utilizada como uma forma de avaliação para o professor. 86

87 Figura 7. Tela Inicial Figura 8. Tela Ajuda Figura 9. Tela Etapa 1 Figura 10. Tela Etapa 2 Figura 11. Tela Resultado Figura 12. Tela Impressão 5. Agentes desenvolvidos A partir da construção do ambiente, surgiram as idéias para a construção do agente. A modelagem trouxe o estudo para a definição das ações. Os agentes são desenvolvidos dentro do próprio ambiente. Estes agentes, por desempenhar tarefas a favor do usuário, possuem características básicas, em que suas capacidades estão diretamente associadas a elas, dependendo de sua funcionalidade. Os agentes desenvolvidos executam ações periódicas e execução espontânea e são estáticos, ou seja, são fixos em um determinado local Classificação Os agentes desenvolvidos possuem nível de inteligência baixo, desempenham tarefas rotineiras disparadas por eventos externos, executando um conjunto de regras e não se adaptam a mudanças, porém, fazem uso da base de conhecimento para raciocinar sobre eventos monitorados. As tarefas que eles executam são do tipo gopher, ou seja, tarefas simples baseadas em suposições com regras pré-estabelecidas. A aquisição de inteligência é reflexivo/reativo, possuindo um mapeamento de situações e respostas associadas. Sendo assim, são agentes do tipo reativo, pois atuam utilizando um comportamento estímulo/resposta Função do Agente 87

88 O agente pedagógico foi desenvolvido como uma ferramenta tutora durante a estruturação do conhecimento dos alunos no decurso da interação com as atividades do software educacional. Esses agentes possuem um conjunto de regras que determinam as ações a serem realizadas nas atividades de ensino, formando assim as estratégias para serem usadas em ambientes lúdicos (jogos). Desse modo, ele tem o objetivo de auxiliar e conduzir o aprendiz durante suas interações no ambiente e não o de ensinar. O agente pedagógico apresenta as seguintes funções: Capacidade de perceber os erros do aluno e interagir, incentivando-o na especulação das atividades contidas no ambiente; Acompanhar as ações do aluno durante sua interação com o sistema; Assistente pessoal do aluno, desempenhando tarefas a seu favor Arquitetura do Agente Um meio específico para se construir os agentes é basear-se em sua arquitetura. Segundo Russell (2004), a arquitetura apropriada depende de percepções, de ações, de objetivos e do ambiente. Quando um estado do ambiente é alterado, o agente executa uma ação correspondente para satisfazer o novo estado, sendo este o estímulo/resposta. O Módulo Reativo é responsável pela mudança de estado do agente durante sua interação com o aluno. Os meios de interação que trazem o feedback são: Textual: ativação de mensagens por meio de balões. Gestual: gestos na face como: pensativo, alegre e insatisfeito. Na figura 13, apresenta-se a arquitetura do agente. Figura 13. Arquitetura do Agente A base de conhecimento interna do agente é composta por: Base de recursos visuais: formada por elementos que constituem a aparência do agente, como: movimentos, corpo, balões; Base de informação: contém informações sobre o conteúdo das perguntas; Base de mensagens: contém as falas para a interação com o aluno Características visuais Para o estabelecimento das características físicas dos agentes, foram estipuladas as seguintes idéias, como mostram as figuras 14 e 15: 88

89 Ser próximo da realidade, de corpo inteiro e proporcional ao estilo do ambiente, semelhantes aos cartoons; Interagir com o usuário, mudando sutilmente sua postura e face de acordo com as situações e ações; Figura 14. Formas do agente Dr. Burns Figura 15. Formas do agente Nani 6. Resultados A validação proposta neste trabalho foi feita nas próprias escolas que colaboraram com a elaboração do perfil dos jogos, envolvendo os alunos de primeira a terceira séries do Ensino Fundamental. No teste, envolveram-se seis turmas com em média quinze alunos cada, todos os professores receberam um novo questionário, composto por sete questões, para verificar a aceitação e desempenho dos jogos e dos agentes pedagógicos, tais como: Você achou adequado o tipo do jogo? O jogo trouxe melhorias para as atividades curriculares? O aluno demonstrou maior interesse em aprender através do jogo? Você acha que a presença do agente obteve alguma contribuição para a interação do aluno com o jogo? De acordo com as respostas obtidas do questionário, a aplicação dos jogos e dos agentes foi bem sucedida e de total aceitação pelos professores e alunos, eles foram estipulados adequados e trouxeram melhorias para as atividades curriculares, devido à demonstração de interesse e à participação dos alunos. Partindo do objetivo do agente pedagógico, ele tornou o ambiente mais motivador e interativo. Os alunos, durante a validação, prestavam atenção nas mensagens que o agente apresentava, em suas expressões, e executavam as atividades de forma que deixasse o agente contente. No espaço destinado para sugestões no questionário, obtiveram-se os seguintes comentários: Acho que deveria haver contribuição sempre, foi ótimo para o aluno. (E. M. E. F. CAIC Professora), Com jogo é melhor aprender. (Instituto Laura Vicuña Aluno), É importante alternativas diferentes de meios de aprendizagem. (Escola Nossa Senhora do Horto Professora), Trabalho importante e que deve ser continuado, pois enriquece o ambiente. (E. M. E. F CAIC - Professora). Esta proposta foi um diferencial nas escolas, pois algumas Instituições faziam maior uso de jogos para diversão e lazer e não para o ensino em específico. A partir disto, pode-se verificar o desempenho dos alunos durante o teste. Alguns tiveram dificuldades no Jogo da Senha e na segunda etapa do Espaço Matemático, pois não estavam acostumados a utilizar recursos computacionais que exigisse maior necessidade de concentração e raciocínio. 89

90 7. Considerações Finais O desenvolvimento do trabalho considerou as partes de definição dos jogos, modelagem (tanto dos jogos e seu funcionamento, quanto do agente), desenvolvimento do ambiente e criação do personagem animado, que representam o agente que está incorporado no ambiente. Como fase final, foi realizada uma validação destes jogos no ambiente de ensino das escolas que participaram da definição do modelo dos jogos para verificar os benefícios que eles trouxeram e da inclusão do agente, visto que não é comum a utilização de agentes em jogos educacionais e a elaboração de questionários para estipular o perfil adequado dos jogos para as escolas. A partir dos estudos realizados, pôde-se constatar que a introdução das tecnologias de informática na Educação é uma ferramenta rica a ser utilizada como uma nova forma de aprendizagem, como um novo instrumento pedagógico de contribuição para a formação do conhecimento do aluno. Este trabalho contribui com os estudos do emprego da informática em sala de aula e suas capacidades. Outro destaque é a utilização de uma proposta pedagógica para a determinação das atividades e o trabalho que o professor pode realizar com os resultados obtidos da interação do aluno com o software. Referências Barbosa, L. M. S. (1998) Projeto de trabalho: uma forma de atuação psicopedagógica, 2.ed., Curitiba: L. M. S. Fernandes, A. M. R. (2003) Inteligência Artificial: noções gerais, 1. ed., São Paulo: Sarvier, cap.1 e cap.5. Gardner, H. (1994) Estruturas da Mente. A Teoria das Inteligências Múltiplas, Porto Alegre: Artes Médicas Sul. Giraffa, L. M. M., Viccari, R. M. (1998) Intelligent Tutoring Systems Modelled Through Agents Techniques, Revista de Ciência, Educação e Cultura. Canoas - RS - Brasil: La Salle. Pereira, A. S. (1999) Um agente para Seleção de Estratégicas de Ensino em Ambientes Educacionais na Internet. Dissertação de Mestrado, Porto Alegre: PPGCC da UFRGS, 82p. Russell, S.; Norvig, P. (2004) Inteligência Artificial, 2. ed., São Paulo: Campus, cap.2. Santos, C. T.; et al. (2001) DORIS: Um agente de acompanhamento pedagógico em sistemas tutores inteligentes, In: Simpósio Brasileiro de Informática na Educação, Anais, Vitória/ES. Zacharias, V. L. C. F., (2007) O Software Educativo, Abril. 90

91 Clasificación de Tejidos Cancerígenos Usando Máquinas de Vectores de Soporte Shirley Victoria Reynozo Torres 1 and Juan Carlos Gutiérrez Cáceres 2 1 Universidad Católica San Pablo 2 Universidad Nacional San Agustín Arequipa - Perú Resumen La clasificación celular es una operación básica dentro la bioinformática, sirve como base a otros procesos como, por ejemplo la alineamiento de secuencias. Tradicionalmente el problema de clasificación celular está formulado como un problema complejo, pero existen técnicas de clasificación, que están siendo utilizadas para este tipo de problemas. Este trabajo tiene como objetivo aplicar una metodología de clasificación de células cancerígenas utilizando las máquinas de vectores de soporte, la técnica SVM trabajan con un kernel, el cual nos dará un hiperplano, separando las células cancerígenas y normales de una forma óptima, además de presentar el marco teórico de las técnicas usadas para resolver tal problema y nos centraremos en un caso especifico de detección que corresponde al cáncer de ovario. 1. Introduction En la actualidad la medicina molecular y la biotecnología vienen constituyéndose en dos áreas promisorias en el campo de las ciencias médicas, el desarrollo de ambas están estrechamente relacionadas, podemos ver avances en el estudio del genoma humano que busca encontrar conocimiento de la organización esencial de los genes y cromosomas del hombre, así prevenir enfermedades, estudiando los fenómenos bioquímicos básicos que la sustentan [3]. Hoy en día el estudio del genoma humano esta casi completo razón por la cual los científicos trabajan con las diferentes tecnologías de información como herramienta de estudio y análisis matemático. Estos avances han generado gran cantidad de información útil que la comunidad científica se ha visto obligada a automatizar la información y todo el conocimiento relacionado. Como consecuencia de esto surge la bioinformática como el área de las ciencias que une la biología y la informática [3]. Actualmente existe mucha inversión en esta ciencia, creando centros de investigación, así como centros distribuidos en red para el secuenciamiento de genes, microarrays de ADN, ADN chips, etc. La Bioinformática, en coordinación con la red de centros de investigación genómica y proteómica componen el área de Biotecnología [8]. Los resultados de estas investigaciones ayudan al bienestar general de las personas disminuyendo el riesgo de muerte por tales males. Un caso particular es la clasificación de diferentes tejidos cancerígenos, en el cual ya existen técnicas que vienen siendo usadas para su detección en etapas tempranas. Se 91

92 2 Shirley Victoria Reynozo Torres and Juan Carlos Gutiérrez Cáceres tiene información registrada sobre diferentes tipos de tejidos cancerígenos como por ejemplo: cáncer de ovario, leucemia y cáncer de colon [5]. Los datos cancerígenos se encuentras registrados en bases de datos como arrays de expresión, estos pueden ser directamente utilizados para la clasificación de tejidos cancerígenos y no cancerígenos mediante diferentes técnicas de clasificación como por ejemplo: máquinas de vectores de soporte, redes neuronales (como: RBF, SOM, LVQ, ART, MPL), métodos estadísticos entre otros [1]. Máquinas de Vectores de Soporte (e.g. SVM) es un clasificador supervisado, ha sido utilizado dentro de las múltiples áreas de análisis biológico, incluyendo evaluaciones de microarray y expresión de datos, detección de proteínas homológicas etc. SVM ha demostrado su utilidad no solo para separar correctamente las entidades dentro de las clases, sino también identifica casos donde otras técnicas de clasificación no soportan algunos datos. SVM dá buenos resultados cuando se trabaja con datos de dimensiones altas [7] [4]. El problema es clasificar los microarrays de expresión de datos de los tejidos, los cuales pueden ser cancerígenos y no cancerígenos, para luego realizar un diagnostico automático en base a estos microarrays. El objetivo principal de este trabajo es: Proponer una metodología adecuada para detectar los tejidos cancerígenos en sus etapas iniciales, mediante el uso de la técnica de Máquinas de Vectores de Soporte. En la sección 2 se presenta el modelo, en la sección 3 la pruebas y resultados obtenidos serán discutidas finalmente en la sección 4 las conclusiones serán presentadas. 2. Propuesta Las Maquinas de Vectores de Soporte (SVM) tiene varias aplicaciones siendo una de ellas la de clasificación de las células cancerígenas de las células sanas para el problema de Cancer de Ovario, en el cual lo datos son obtenidos mediante un analisis de microarray. Como se puede ver en la figura 1 se muestra un esquema de las diferentes etapas que deben ser consideradas en el modelo propuesto. Figura 1. Etapas de la propuesta 92

93 Title Suppressed Due to Excessive Length 3 Como puede apreciarse en la figura primero se tiene en consideración la base de datos la cual esta compuesta de los casos con los que se trabajaran. Después se encontraran dos etapas de Entrenamiento y Prueba Entrenamiento Mediante Support Vector Machine (SVM) Es una herramienta de clasificación que están siendo ampliamente utilizada hoy en día porque obtienen resultados superiores que los métodos tradicionales en los procesos de clasificación [2]. La SVM fue ideada originalmente para la solución de problemas de clasificación linealmente separables. Estos encuentran hiperplanos de decisión óptimos que clasifique correctamente todas las muestras disponibles, colocando el hiperplano de separación lo mas lejos posible de todas ellas. Las muestras que ayudan a la definición del hiperplano óptimo de separación (las mas próximas al hiperplano) son conocidas como vectores de soporte. Las Máquinas de Vectores de Soporte(SVM) se emplean particularmente, en tareas de clasificación. Sustentadas en el principio de minimización de riesgo estructural [6]. Sin embargo SVM es el principal método basado en la teoría de aprendizaje estadístico, bajo una arquitectura de red neuronal como se puede ver en la figura 2. Figura 2. Estructura de SVM desde el punto de vista de una red neuronal Clasificación Binaria Mediante SVM En este tipo de clasificación se intenta clasificar los elementos en dos clases, estas clases pueden ser problemas linealmente separables o no linealmente separables. SVMs lineales para datos de clases linealmente separables Los SMV lineales son originalmente clasificadores que consiguen discriminar perfectamente los datos de clases linealmente separadas, a través de la construcción de un hiperplano. Según Cristianini [2], un hiperplano es un subespacio de similar dimensión n 1 que divide el espacio n-dimensional en dos mitades óptimas. Si esto se consigue entonces las clases son dichas de linealmente separadas así 93

94 4 Shirley Victoria Reynozo Torres and Juan Carlos Gutiérrez Cáceres como puede ser visto en la figura 3, donde se ilustra en plano bidimensional en el cual son separados dos conjuntos por una línea que en este caso corresponde al hiperplano de clasificación. Figura 3. Conjunto linealmente separado, tenemos el hiperplano separador y la regla de decisión. Si se tiene un conjunto de datos x i R n, i = 1,..., N donde cada punto x i pertenece a una de dos clases y i { 1, +1}, lo que se quiere es maximizar el margen de separación entre dos clases a través de un hiperplano que esta dado por: f(x) = l α i y i x i.x i + b (1) i=1 donde α y b son soluciones del problema de programación cuadrática. En el proceso de clasificación un dato nuevo será calculado tomando el signo que de como resultado de la siguiente ecuación: l i=1 d(x) = α iy i x i.x i + b l i=1 α iy i x i Este signo indicara la proximidad a una de las dos clases establecidas anteriormente. (2) SVMs para problemas no linealmente separables La solución empleada por SVM para este problema es transformar los elementos de su espacio de entrada original x para otro espacio llamado espacio de características z = Φ(x) como puede ser visto en la figura??, en este nuevo espacio si existe un hiperplano de clasificación que se convierte en una función de decisión no lineal en el espacio 94

95 Title Suppressed Due to Excessive Length 5 original. Este nuevo espacio esta sujeto a la restricción del producto interno de < Φ(x).Φ(y) > el cual es llamado de núcleo o kernel de la transformación, lo cual simplifica en gran medida la obtención de funciones de decisión no lineales, este también puede ser escrito como K(x, y), de esta manera la superficie de decisión será f(x) = l α i y i x i.x i + b (3) i=1 hay que observar que f(x) no depende de dimensión del espacio de características. la siguiente figura nos muestra como el conjunto de entradas es llevado al espacio de características donde el problema se transforma en un problema linealmente separable. Figura 4. Figura para transformar el dato de un hiperplano a otro. Problema de clasificación multiple existen varias maneras de realizar el problema de n-clases en SVM, entre ellas tenemos: Comparar una clase contra todos los demás, eso quiere decir que se tendrán n clasificadores uno para reconocer cada clase. Aproximación por pares, donde n(n 1)/2 clasificadores son entrenados, los cuales tienen una estructura tipo árbol donde el conjunto inicial de clases es separado en dos clases, luego de este proceso es repetido hasta que la clase sea identificada en cada nodo del árbol De esta manera este clasificador puede ser usado para poder realizar el reconocimiento varias personas de manera automática. Como se presento anteriormente SVM puede ser usado no solo para problemas de clasificación binaria sino tambien para Multi-Clasificación, lo que hace extendible su uso en diferentes aplicaciones. Para este caso de clasificación de personas sanas de las enfermas de cancer es suficiente usar dicho SVM en clasificación binaria. 95

96 6 Shirley Victoria Reynozo Torres and Juan Carlos Gutiérrez Cáceres 3. Pruebas y Resultados 3.1. Preprocesamiento de Datos Como se mencionó anteriormente la base de datos consta de 253 patrones, los cuales corresponden a dos clases desbalanceadas porque 91 patrones corresponderán a lo que a partir de ahora llamaremos de clase 1 correspondientes a las personas que no tienen cáncer y 162 patrones que corresponden a la clase -1 que son los que si tienen cáncer. Los valores de entrada están normalizados en un rango de valores entre cero y uno. en la figura 5 puede apreciarse un patrón que corresponde a Figura 5. ejemplo de un patrón. Los tipos de errores que pueden ocurrir es que a los patrones sanos los clasifique como enfermos y que a los enfermos los clasifique como sanos, tenemos que tener en cuenta que este segundo tipo de error debe tener una consideración especial dado que decirle a un persona sana que esta enferma lo único que causaría en el peor de los casos es realizarse pruebas más especializadas, cosa que no sucederá cuando a una persona enferma le digan que esta sana ya se descuidará y eso trae como consecuencia cosas peores. En la figura 6 se muestra un ejemplo con dos patrones uno correspondiente a un paciente con cáncer y otro que no tiene Base de Datos La base de datos contiene los dos tipos de células: patrones proteínicos de células normales y patrones proteínicos de células cancerígenas. Los patrones proteínicos se obtuvieron del suero del ovario. Esta base de datos contiene 253 patrones diferentes de los cuales 91 corresponden a personas que tienen los ovarios sanos y los 162 restantes corresponden a las ovarios de personas que tienen cancer. Cada uno de los datos contiene la amplitud relativa de intensidad para 96

97 Title Suppressed Due to Excessive Length 7 Figura 6. ejemplo de un patrón de un paciente sano y uno enfermo. cada masa molecular / carga (M/Z) de su identidad. Son un total de M/Z identidades, los cuales los consideraremos como los valores de los atributos utilizados Entrenamiento Support Vector Machine El método usado para dar a conocer las pruebas y resultados es la llamada validación cruzada. La validación cruzada es el diseño experimental más utilizado entre las diferentes investigaciones de reconocimiento de patrones. En este método, los datos disponibles se dividen aleatoriamente en varios subconjunto, el primero será llamado de entrenamiento y el segundo conjunto será llamado conjunto de prueba. El conjunto de entrenamiento se sub-divide a su vez en dos sub-conjuntos disjuntos los cuales son: el conjunto de estimación, usando para seleccionar el algoritmo. Y el segundo llamado conjunto de validación usado como su nombre los dice para validar los parámetros seleccionados. Para esta tesis los porcentajes correspondientes con respecto a toda la base de datos son los siguientes: el conjunto de entrenamiento consta del 75 % de patrones de la base de datos y es dividido, siendo el de selección correspondiente a un 50 % y el conjunto de validación consta del 25 %, finalmente el conjunto de prueba corresponde a los últimos 25 % de la base de datos, siendo los siguientes pasos los realizados para esta etapa llamada de entrenamiento de la SVM. 1. Entrenar el SVM con el conjunto de entrenamiento obteniendo un error asociado para esta primera parte, los datos elegidos son seleccionados de manera aleatoria; 2. Encontrar el error con los patrones de entrenamiento utilizado 3. Encontrar el error con los datos del conjunto de validación 4. Volver a entrenar ahora incluyendo los valores de validación 5. Encontrar el error con los datos del conjunto de validación después de haber entrenado inclusive con ellos 97

98 8 Shirley Victoria Reynozo Torres and Juan Carlos Gutiérrez Cáceres 6. Encontrar el error con los datos del conjunto de prueba estos pasos realizados nos indican que fueron realizadas siguen una metodología que garantiza la robustes del entrenamiento Consulta SVM En esta etapa de consulta, se utilizara el Support Vector Machine previamente entrenado con el conjunto de selección y de validación, encontrando para tal objetivo el kernel óptimo para poder separar las clases maximizando clasificación del problema, separando las células cancerígenas de las células normales, mediante un hiperplano óptimo de separación que la técnica SVM brinda mediante su kernel. Como se puede apreciar en la figura 1, en a etapa de consulta una persona que quiere saber si tiene o no cáncer, deberá hacer las misma prueba que se hicieron las personas en la etapa de entrenamiento. Con esta prueba también se obtendrá un vector de características de la misma dimensión que los que fueron usados en para el entrenamiento correspondiendo a atributos. Una vez realizada esta etapa el deberá ser clasificada con los valores obtenidos en la etapa de prueba con los vectores de soporte que fueron hallados en el entrenamiento dando como respuesta a nuestro sistema la clases 1 si es que la persona esta sana y dará el valor de -1 si la persona tiene cáncer. Aunque esta etapa seria la parte de puesta en funcionamiento de esta propuesta la pruebas fueron realizadas con el ultimo 25 % de datos que se asignaron al sub-conjunto de prueba. De tal forma que se puede mostrar la robustes del modelo al probar la propuesta con casos con los cuales el sistema nunca fue entrenado, así podremos estimar el posible error que pueda tener la propuesta sin tener que llevar a cabo aun la puesta en marcha Características Claramente algunas cosas pueden apreciarse de esta propuesta: El modelo propuesto puede ser usado no solamente para la detección de cáncer de ovario, podría se usado en cualquier otra aplicación lo que se quiere resaltar es la aplicabilidad de técnicas de computación en medicina principalmente en bioinformática. Esta propuesta muestra una flexibilidad al momento de realizar el entrenamiento dado que el programa desarrollado permite flexiblemente el cambio de parámetros principalmente de kernels, tenemos por ejemplo que pueden ser usados: lineal, polinomial de diferentes grados, funciones de base radial, funciones gaussianas, entre otros. Esto nos permite dar una flexibilidad de mejorar los resultados ante un problema de bioinformática similar al caso resuelto en esta tesis. Además de ser conocida la utilidad de SVM para diferentes problemas de clasificación, esta tesis muestra que también presenta muy buenos resultados para problemas relacionados a medicina, los cuales generalmente son problemas que contienen gran cantidad de información y son difíciles solucionar. 98

99 4. Conclusiones Title Suppressed Due to Excessive Length 9 La técnica SVM demostró un buen desempeño en la clasificación con Base de Datos muy grandes, la buena elección del Kernel favoreció en la clasificación y separación de las clases obteniendo resultados satisfactorios, durante su entrenamiento incrementó el poder computacional de la máquina de aprendizaje lineal. La SVM es una técnica con una arquitectura similar a las redes neuronales, fue comparada con una red neuronal artificial llamada Backpropagations, donde SVM mostró muy buenos resultados y mejor desempeño que la red neuronal artificial, debido que esta no trabaja con base de datos muy grandes. La técnica SVM en la etapa de entrenamiento es muy pesada debido a la dimensionabilidad de los datos, pero en la etapa de pruebas la respuesta es rápida mostrando resultados muy óptimos lo cual la hace útil para aplicaciones reales. Referencias 1. C. Burges. Tutorial on Support Vector Machines for Pattern Recognition. Knowledge Discovery and Data Mining, v. 2, n. 2, pp , N. Cristianini and J. Shawe-Taylor. An Introduction to Support Vector Machines (and other kernel-based learning methods). Cambridge University Press, Cambridge, UK, 1 edition., D. Gershenson. malignant ovarian germ cell tumors. Cancer, 71(4): , R. Henao. Selección de Hiperparámetros en Máquinas de Soporte Vectorial. Universidad Nacional de Colombia, Manizales, E. Segelov. Cisplatin-based chemotherapy for ovarian germ cell malignancies. Australian experience, 12(2): , V. Vapnik. The nature of statistical learning theory. Springer Verlag, V. Vapnik. Transductive Support Vector Machines and Applications in Bioinformatics for Promoter Recognition S. Williams. therapy of ovarian germ cell tumors with cisplatin, etoposide and bleomycin. trial of the Gynecologic Oncology Group, 12(4): ,

100 Método para la Aplicación de Esquemas de Clave Pública al Cifrado de Imágenes RGB Jorge Valverde Rebaza 12 Pedro Shiguihara Juárez 12 Juan Grados Vásquez 12 1 Universidad Nacional de Trujillo 2 Sociedad de Estudiantes de Ciencia de la Computación (SECC) jorge.carlos14@gmail.com, p.shiguihara@gmail.com, juaninf@gmail.com Resumen En el presente trabajo se propone un método de cifrado de imágenes en espacio de colores RGB. El método consta de dos fases, la primera consiste en el cifrado de la imagen mediante el uso de esquemas de cifrado de clave pública de tipo determinísticos como el RSA o probabilísticos como Goldwasser- Micali. La segunda fase consiste en dispersar sobre la imagen ya cifrada, la clave hash obtenida al aplicar una función hash a la clave de seguridad dada por el propietario. Los resultados obtenidos son muy satisfactorios pues se logra la ilegibilidad total de la imagen original, la seguridad de la misma y su recuperación sin pérdida del contraste. 1. Introducción La criptografía es la rama de la matemática que nos permite establecer comunicaciones seguras, a través del arte de ocultar la información relevante dentro de los mensajes cifrados para procurar que llegue un mensaje esencial a su destino sin haber podido ser leído o descifrado por intrusos. Actualmente, debido a la abundante cantidad de información multimedia y a su uso en diversas áreas, se hace necesaria la capacidad de contar con mecanismos que aseguren que dicha información será recibida única y exclusivamente por el destinatario establecido. En este paper se presenta un método para el cifrado de imágenes en el espacio de colores RGB, el cual es usado por la mayoría de dispositivos gráficos como cámaras de video y foto digital para representar las imágenes. El método que proponemos consiste de dos fases: la primera fase consiste en el cifrado de la imagen, codificando cada píxel en función de un algoritmo de clave pública. El cifrado por píxeles permite que el método sea independiente del formato de extensión del archivo de la imagen. La segunda fase se encarga de dispersar, de manera no continua, dentro de la imagen previamente cifrada, la clave hash obtenida al aplicar una determinada función hash a la clave de seguridad del propietario. Esta distribución permite darle una fortaleza extra al proceso de cifrado; además de permitir al usuario definir su propia clave de acceso para recuperar la imagen original. En la sección 2 se mencionan los trabajos previos donde se han usado métodos de cifrado sobre diferentes tipos de imagen, en la sección 3 se presentan las consideraciones a tomar en cuenta para el cifrado de imágenes, en la sección 4 se presenta el método propuesto y las adaptaciones de lo esquemas de clave pública al cifrado de imágenes. En la sección 5 se presenta los experimentos y resultados obtenidos, en la sección 6 se comentan dichos resultados, en la sección 7 se detallan las conclusiones y en la sección 8 se muestran los trabajos futuros a realizarse como alcance posterior a lo planteado. 2. Trabajos Previos (Hernández et al., 2002) presenta un cifrado para imágenes en escala de grises, usando el método de Autómatas Celulares Bidimensionales. (Van Droogenbroeck, 2004) presenta 100

101 un método para el cifrado parcial de imágenes en formato JPEG en el contexto de aplicaciones de tiempo real. (Lung, 2006) propone un esquema de cifrado selectivo eficiente para cifrar imágenes que se encuentren en formato de extensión JPEG 2000; es así como (Lung, 2006) utiliza una función de mapeo para generar una tabla privada que le permite cifrar los codeblocks de la imagen. Este método no puede ser aplicado en imágenes que se encuentren en otro formato de extensión, sin embargo, (Pareek et al., 2006) propone un algoritmo para el cifrado de imágenes basado en funciones caóticas presentando hasta ocho operaciones distintas para el cifrado de los píxeles. 3. Consideraciones para el cifrado de imágenes El trabajo sobre los píxeles de la imagen permitirá que el método de cifrado propuesto sea aplicado a todo tipo de archivo de imagen sin importar su extensión, sin embargo, las imágenes están formadas por 256 diferentes tonos de píxeles, los cuales varían sus intensidades entre 0 y 255, lo que implica que ningún resultado que obtengamos puede estar fuera de éste rango, es decir que, el espacio de trabajo Zn para realizar el cifrado se encuentra reducido a n = 256. Esto significa que el tamaño de la clave pública y privada necesarios en los esquemas de clave pública se verán ampliamente reducidos, por lo que se deben evaluar las características del esquema que se desee adaptar al cifrado de imágenes. Por otro lado, la reducción del espacio de trabajo es un serio problema que ha sido afrontado con éxito mediante el uso de una clave hash obtenida a partir de la clave de seguridad del propietario y su distribución en la imagen cifrada, de modo que ningún intruso que no conozca dicha clave de seguridad pueda obtener la imagen original a partir de la cifrada mediante un ataque por fuerza bruta. 4. Cifrado de imágenes usando esquemas de clave pública Para realizar tanto el cifrado como el descifrado, los parámetros que necesitamos son una imagen y una clave de seguridad. La imagen debe encontrarse en el espacio de colores RGB (imagen RGB) sin importar su formato de extensión. La clave de seguridad debe tener la mayor longitud posible y estar formada por caracteres. En algoritmo 1 se presentan los pasos a seguir para cifrar una imagen. Algoritmo 1 Cifrar imagen Requiere: Imagen: imagen en modelo de color RGB Clave: clave de seguridad Asegurar: CriptoIm: resultado de la cifrar la imagen de entrada 1. Para cada matriz componente de Imagen: R, G y B, fraccionar en f submatrices. Distribuir las f submatrices de R, G y B siguiendo una misma secuencia para las tres y obteniendo así las nuevas matrices R1, G1 y B1, que son las componentes de la nueva imagen ImFrag. 2. Aplicar a la imagen ImFrag un método de cifrado por clave pública adaptado para imágenes. Se obtendrá la imagen CriptoIm. 3. Aplicar a Clave una función hash. Se obtendrá la clave hash ClaveH. 4. Dispersar de modo no continuo ClaveH sobre CriptoIm. 5. Devolver CriptoIm. 101

102 En el algoritmo 1, el paso 1 nos permite evitar acumulaciones de tonos de píxel que tengan la misma intensidad, distribuyéndolos en posiciones diferentes. En la figura 1 se muestra una ilustración de este paso. En imágenes en las que no se tenga grandes acumulaciones de píxeles de la misma intensidad, este paso puede obviarse con el objetivo de ahorrar tiempo de procesamiento, si esto sucede, la entrada del paso 2 sería directamente la imagen original. A01 A02 A03 A04 A05 A06 A07 A08 A09 A10 A11 A12 A13 A14 A15 A16 A17 A18 A19 A20 A21 A22 A23 A24 A25 A26 A27 A28 A29 A30 A31 A32 A33 A34 A35 A36 A05 A06 A27 A28 A03 A04 A11 A12 A33 A34 A09 A10 A29 A30 A25 A26 A13 A14 A35 A36 A31 A32 A19 A20 A17 A18 A01 A02 A15 A16 A23 A24 A07 A08 A21 A22 Figura 1: En la izquierda se observa la representación de una imagen de entrada de tamaño 6 x 6. En la derecha se observa el resultado de la fragmentación de dicha entrada en 9 fragmentos de 2 x 2 cada uno y la distribución de los mismos para formar una nueva imagen. En el paso 2 se debe de aplicar la adaptación de un método de clave pública al cifrado de imágenes. Más adelante se presentan las adaptaciones que proponemos. En el paso 3 aplicamos una función hash a la clave de seguridad del propietario, obtendremos la clave hash, la cual, en el paso 4, será dispersada de un modo no continuo (se hace uso del método de (Murrugarra et al., 2007) el cual se basa en el recorrido de grafos) sobre la imagen cifrada obtenida en el paso 2. Para descifrar una imagen y obtener la original, se debe seguir el algoritmo 2. Algoritmo 2 Descifrar imagen Requiere: CriptoIm: imagen cifrada Clave: clave de seguridad Asegurar: Imagen: resultado de descifrar una imagen 1. Obtener ClaveH que se encuentra dispersa en CriptoIm 2. Aplicar a Clave una función hash. Se obtendrá la clave hash ClaveDH. 3. Si ClaveH = ClaveDH entonces 4. Descifrar CriptoIm. Obtener la imagen descifrada ImagenD 5. Para cada matriz componente de ImagenD: R, G y B, fraccionar en f submatrices. Distribuir las f submatrices de R, G y B siguiendo la secuencia inversa a la realizada en el paso 1 del algoritmo 1, obteniendo así las nuevas matrices R1, G1 y B1, que son las componentes de Imagen. 6. Devolver Imagen. 7. Fin Si En el algoritmo 2, para el paso 1 se debe recuperar la clave hash almacenada en la imagen cifrada, siguiendo el proceso de recuperación de información dispersa en modo no continuo en una imagen, propuesto en (Murrugarra et al., 2007). En el paso 2 se debe de aplicar a la clave ingresada la misma función hash usada en el algoritmo 1. Si las claves obtenidas en los pasos 1 y 2 no son las mismas, entonces no se realiza el descifrado de la imagen, en caso contrario, se descifra la imagen usando el proceso adecuado según lo hecho 102

103 en el paso 2 del algoritmo 1. Finalmente, si en el algoritmo 1 se aplicó el fraccionamiento y distribución de la imagen, entonces se hace necesario realizar el proceso inverso para obtener la imagen original, sino fuese así, el paso 5 del algoritmo 2 ya no sería necesario Adaptación de RSA al cifrado de imágenes RSA es un esquema de cifrado de clave pública propuesto en (Rivest et al., 1978). El nombre RSA se debe a sus creadores R. Rivest, A. Shamir y L. Adleman y basa su seguridad en la intratabilidad del problema de la factorización entera según (Menezes et al., 1996)(Cormen et al., 1990). Debido a la reducción del espacio de trabajo Zn con n = 256 para el tratamiento de imágenes, se deben de buscar números primos p y q diferentes, cuyo producto sea el máximo posible y abarque el mayor rango de los tonos de píxeles, de manera que podamos trabajar sobre un nuevo espacio de trabajo Zn donde n = pq y n n. Teniendo en cuenta estas restricciones podemos usar el algoritmo de generación de claves para RSA propuesto en (Menezes et al., 1996) y obtener las claves pública y privada. Sin embargo, dado que n n existirán r = n - n tonos de píxel que quedarán fuera del espacio Zn y que por lo tanto no serán cifrados. Sabemos que r > 0 dado que no existen números primos p y q diferentes tal que pq = 256, por lo tanto es un hecho que quedarán tonos de píxel sin cifrar. Estos r tonos de píxel serán aquellos que se encuentren entre n y n-1, es decir, serán cercanos al tono 255, lo que significa que estarán formados por tonos claros. Algoritmo 3 Adaptación de RSA para cifrar una imagen Requiere: Imagen: imagen a cifrar n, e: clave publica Asegurar: CriptoIm: resultado de cifrar Imagen 1. Desde i 0 hasta 255 hacer 2. paleta[i] Fin Desde 4. i 0 5. j 0 6. Mientras i < numero de filas de Imagen hacer 7. Mientras j < numero de columnas de Imagen hacer 8. Desde k 0 hasta 2 hacer 9. pos Imagen k [i,j] 10. Si paleta[pos] = -1 entonces 11. Si Imagen k [i,j] Z n' entonces 12. CriptoIm k [i,j] RSA(Imagen k [i,j], e, n) 17. Fin Si 18. Fin Desde 19. Fin Mientras 20. Fin Mientras 21. Devolver CriptoIm 13. Sino CriptoIm k [i,j] Imagen k [i,j] 14. Fin Si 15. paleta[pos] CriptoIm k [i,j] 16. Sino CriptoIm k [i,j] paleta[pos] 103

104 Si una imagen tiene una gran cantidad de píxeles con tonos claros que se encuentran entre n y n-1, entonces todos estos píxeles no serán cifrados. Para afrontar este problema, en el uso de RSA para el cifrado de imágenes, se hace necesaria la utilización del paso 1 del algoritmo 1. En el algoritmo 3 se presenta la adaptación del RSA al cifrado de imágenes. El algoritmo 3 hace uso de un arreglo denominado paleta en el que se almacenan los valores ya computados para su posterior reutilización. A partir del paso 8 hasta el 18 se trabaja con las matrices componentes de la imagen, de manera tal que Imagen 0 corresponde a la matriz R, Imagen 1 a la matriz G, e Imagen 2 a la matriz B. Se sigue la misma correspondencia para CriptoIm. Así mismo, en el paso 12, se hace un llamado al método RSA, que no es otro que el algoritmo de cifrado de RSA presentado en (Menezes et al., 1996) y cuyos parámetros son la intensidad del píxel en una determinada posición de un componente de la imagen y la clave pública respectiva. Para el descifrado se siguen los mismos pasos del algoritmo 3, excepto en el paso 12, en el cual se debe usar el método de descifrado de RSA presentado en (Menezes et al., 1996) y cuyos parámetros son la intensidad del píxel en una determinada posición de un componente de la imagen y la clave privada respectiva Adaptación de Goldwasser-Micali al cifrado de imágenes Goldwasser-Micali (GM) es un esquema de cifrado de clave pública de tipo probabilístico presentado por (Goldwasser y Micali, 1984). GM trabaja con los bits del mensaje a cifrar (Menezes et al., 1996), por lo tanto no importará la intensidad del tono que se desee cifrar. Entonces en el espacio Zn donde n = 256, se debe buscar dos números primos p y q diferentes tal que pq n. Con esta restricción se puede usar el algoritmo de generación de claves para GM propuesto en (Menezes et. al, 1996) y obtener las claves pública y privada. Un parámetro que se puede tomar en cuenta al momento de decidir por los valores de p y q es la denominada distancia de bits d, la cual es definida como la diferencia entre las intensidades de tonos cifrados con GM del bit 1 y el bit 0. Es decir: p, q tq pq n Z n donde : d = GM GM (1) GM (0 ) GM (0 ) (1) si si GM GM (1) > GM (0 ) > GM (0 ) (1) En la figura 2 se muestra el impacto de la evaluación de la distancia de bits d en el cifrado de imágenes con GM. (a) (b) Figura 2: Una distancia de bits d mínima permite el cifrado uniforme de los tonos de una imagen como se aprecia en la figura (b). En la figura (a) se observa que la imagen cifrada presenta dos regiones de tonos de color. Dado a que el cifrado se realizará sobre los bits de los tonos de colores, entonces, primero debemos de binarizarlos. En la figura 3 se muestra la binarización de un tono de color. 104

105 Figura 3: En la izquierda se muestra la binarización del tono con intensidad 5, los ceros de color verde son de relleno para ocupar 8 bits. En la derecha se muestra el resultado de cifrar con GM la binarización del tono con intensidad 5 usando p = 7 y q = 3, los valores 15 de color verde son colocados de relleno con el objetivo de que las intensidades de los tonos no varíen. Como podemos observar en la figura 3, la encriptación con GM del píxel con tono 5 ha generado 8 valores, los cuales deben ser almacenados en la nueva imagen cifrada. Esto significa que el resultado para éste método tiene un factor de expansión (definido en (Hernández et al., 2002)) mayor a la original. Para evitar esto, se propone generar dos imágenes resultantes en las que se distribuyan los valores cifrados para cada píxel. El algoritmo 4 presenta la adaptación de GM al cifrado de imágenes. Algoritmo 4 Adaptación de GM para cifrar una imagen Requiere: Imagen: imagen a cifrar fcrec: factor de expansión n, y: clave publica Asegurar: CriptoImA, CriptoImB: resultado de cifrar Imagen 1. Sea f y c el numero de filas y columnas de Imagen, crear CriptoImA y CriptoImB de tamaño f x (c x fcrec/2) 2. Inicializar CriptoImA y CriptoImB con tonos de intensidad cero 3. Desde i 0 hasta 255 hacer 4. paleta[i] φ 5. Fin Desde 6. Mientras i < f hacer 7. Mientras j < c hacer 8. Desde k 0 hasta 2 hacer 9. pos Imagen k [i,j] 10. Si paleta[pos] = φ entonces 11. cifrado GM(Imagen k [i,j], n, y) 12. paleta[pos] cifrado 13. Copiar la primera mitad de elementos de cifrado en CriptoImA k 14. Copiar la última mitad de elementos de cifrado en CriptoImB k 15. Sino 16. Copiar la primera mitad de elementos de paleta[pos] en CriptoImA k 17. Copiar la última mitad de elementos de paleta[pos] en CriptoImB k 18. Fin Si 19. Fin Desde 20. Fin Mientras 21. Fin Mientras 22. Devolver CriptoImA y CriptoImB 105

106 VII Jornada Peruana de Computación En el algoritmo 4, el arreglo paleta almacena 256 arreglos de 8 elementos. En el paso 4, paleta es inicializado con arreglos vacíos. Al momento de efectuar el cifrado con GM, paleta va actualizando su contenido (ver paso 12) para su posterior utilización. Los pasos 13, 14, 16, 17 consiste en distribuir los elementos del arreglo obtenidos al cifrar un tono de píxel con GM en las dos imágenes de salida. En el caso que se desee obtener una única imagen cifrada, en el paso 1 se debería crear una sola imagen de salida de tamaño f x (cx8) y en los pasos 13, 14, 16, 17 se deben copiar la totalidad de los elementos del arreglo de tonos cifrados en la imagen de salida. En el paso 11 se hace uso del método de cifrado de GM presentado en (Menezes et al., 1996). Para el descifrado se sigue el algoritmo 4 usando en el paso 11 el método de descifrado de GM presentado en (Menezes et al., 1996). La salida del algoritmo 4 son dos imágenes cada una con un factor de expansión de 4 veces el largo de la imagen original, sin embargo, es válido obtener una sola imagen resultante, la misma que tendrá un factor de expansión de 4 veces el largo y 2 veces el alto de la imagen original. Para el descifrado, si se generan dos imágenes cifradas, entonces como parámetro de entrada se necesitará generar una nueva imagen contenedora, la cual se formará a partir de las dos imágenes resultantes del cifrado, en el respectivo orden de generación. 5. Experimentos y Resultados Los experimentos que se presentan se realizaron en una PC Intel Pentium IV con CPU de 3.00GHz y 504 MB de memoria, sobre el sistema operativo Linux en la distribución Ubuntu 7.10, sin embargo también se realizaron los mismos experimentos sobre la misma PC pero en el sistema Operativo Windows XP, obteniéndose el mismo performance. Se realizaron comparaciones de la calidad de imágenes cifradas entre el método de adaptación de RSA para el cifrado de imágenes propuesto (RSA-Im) y el método de cifrado de imágenes basado en funciones caóticas (Caos-Im) propuesto en (Pareek et al., 2006). En la figura 4 y figura 5 se muestran los resultados obtenidos al cifrar imágenes diferentes con el método RSA-Im y con el método Caos-Im. En la figura 6 se muestra el resultado obtenido al usar la adaptación de GM al cifrado de imágenes usando una distancia de bits minima (d = 4) por lo que ambas imágenes resultantes están formadas por tonos oscuros (cercanos al tono 0) y cada una tiene un factor de expansión de 4 veces el largo de la original. (a) (b) (c) Figura 4: En (a) se muestra la imagen de Lena en formato.png (lena.png) y dimensiones de 510 x 511 píxeles. En (b) se muestran el resultado del cifrado con el método RSA-Im, usando como clave pública n = 253, e=137. En (c) se muestra el resultado del cifrado con el método Caos-Im. 106

107 (a) (b) (c) Figura 5: En (a) se muestra la imagen de la Plaza Mayor de Trujillo en formato.jpg (plaza.jpg) y dimensiones de 320 x 487 píxeles. En (b) se muestran el resultado del cifrado con el método de adaptación de RSA-Im, usando como clave pública n = 253, e=179. En (c) se muestra el resultado del cifrado con el método Caos-Im. Figura 6: A la izquierda se presenta la imagen de Lena en formato.png (lena.png) y dimensiones de 510 x 511 píxeles y a su derecha las dos imágenes resultantes al usar GM adaptado al cifrado de imágenes, usando como clave pública n = 21, y = 10 y una distancia de bits d = 4. Para la medición de la calidad del cifrado de imágenes nos hemos basado en tres factores propuestos por (Ziedan et al., 2003), los cuales son: el Factor Medida de la Máxima Desviación (MD), el Factor Medida de Coeficiente de Correlación (CC) y el Factor Medida de la Desviación Irregular (ID). En el cuadro 1 se muestran las comparaciones de los factores de calidad de cifrado entre el método RSA-Im y el método Caos-Im. Medida de Factores de Calidad del Cifrado de Imágenes RSA-Im Caos-Im Imagen clave publica clave privada MD CC ID MD CC ID lena.png n=253, e=97 d= lena.png n=253, e=101 d= lena.png n=253, e=169 d= lena.png n=253, e=137 d= plaza.jpg n=253, e=201 d= plaza.jpg n=253, e=179 d= plaza.jpg n=253, e=61 d= plaza.jpg n=253, e=103 d= Cuadro1: Comparación de los factores de calidad del cifrado entre el método RSA-Im y el método Caos-Im. 107

108 En el cuadro 2 se presentan las comparaciones de la cantidad de píxeles modificados al obtener la imagen original después de descifrar una imagen. Medida de píxeles modificados después del descifrado RSA-Im Caos-Im Imagen Nº píxeles modificados clave propietario Nº píxeles modificados clave propietario lena.png 0 jomijushi2008cifrado 0 jomijushi2 plaza.jpg 0 jomijushi2008cifrado 0 jomijushi2 Cuadro2: Comparación del número de píxeles modificados al descifrar una imagen y el tamaño de las claves de propietario permitidas. 6. Discusión de los Experimentos Según (Ziedan et al., 2003), una imagen cifrada que tenga un alto valor de DD, un valor de CC cercano a -1 y un valor de ID mínimo, tiene una alta calidad de cifrado. De lo dicho, en el cuadro 1 podemos observar que, si tomamos en cuenta el factor DD, para la mayoría de los valores de clave pública (generados aleatoriamente) del método RSA-Im, se logra un mejor cifrado que con Caos-Im. Para los valores de clave pública que no logran un cifrado con mayor valor de DD que el obtenido con Caos-Im, se logra un valor muy cercano a éste. Con respecto al factor CC, Caos-Im obtiene valores más cercanos a -1 que RSA-Im para el cifrado de imágenes propuesto, sin embargo, nuestro método también logra acercarse mucho más a -1 para algunos valores de clave pública. Y con respecto al factor ID, Caos-Im obtiene mayormente valores menores que RSA-Im. Sin embargo, una notable diferencia la encontramos en el tamaño permitido para la clave de propietario. En Caos-Im se permite un tamaño máximo de 10 caracteres, en cambio para RSA-Im (en general, para la adaptación de algún método siguiendo el algoritmo 1) el tamaño puede ser mucho mayor, debido a la distribución no secuencial de la clave de propietario previamente cifrada sobre la misma imagen. (Murrugarra et al., 2007) logra distribuir entre 1500 a 3000 caracteres en una imagen de 361 x 241 píxeles de resolución. El cifrado de imágenes con la adaptación de GM propuesto genera imágenes con un mayor factor de expansión (ver figura 6), lo cual representa una desventaja en términos de capacidad de almacenamiento requerido (y posiblemente de portabilidad de la(s) imagen(es) cifrada(s)), sin embargo su uso puede ser de gran utilidad en alguna aplicación en la que se requiera una total indistinción de una imagen. Solo se realizaron las comparaciones entre la adaptación de RSA al cifrado de imágenes y el método propuesto en (Pareek et al., 2006) debido a que los factores de calidad de cifrado de imágenes de (Ziedan et al., 2003) realiza las mediciones entre imágenes de la misma dimensión (igual factor de expansión). En el cuadro 2 se observa que ningún método incurre en la pérdida de píxeles después del proceso de descifrado con respecto a la imagen original. Esto significa que no existe pérdida de contraste. 7. Conclusiones El método propuesto para el cifrado de imágenes RGB produce resultados efectivos y seguros. La efectividad se refleja tanto en el cifrado, al obtener una imagen ilegible y totalmente distinta a la original, como en el descifrado, al recuperar la imagen original a partir de la cifrada sin pérdida del contraste. La seguridad se fortalece por el hecho de que la clave de seguridad del usuario propietario es convertida en una clave hash al aplicársele una función hash, para luego ser distribuida sobre la imagen cifrada, de manera tal que, si un 108

109 intruso desea obtener la imagen original, primero deberá recuperar la clave hash que se encuentra dispersa sobre la imagen cifrada (obteniendo la posición en la que se inició la distribución con recorrido de grafos de (Murrugarra et al., 2007)), si logra hacerlo, ahora deberá enfrentarse al problema de conocer la función hash usada para generarla.. La desventaja de nuestra propuesta es el tiempo de procesamiento que demanda por el hecho de trabajar sobre cada píxel de la imagen y sobre cada matriz R, G, B componente de la misma. Sin embargo, esta desventaja queda compensada con la efectividad y seguridad que el método provee. La adaptación de RSA al cifrado de imágenes es la que mejor resultados ha brindado debido a que su factor de expansión es de 1, es decir, la imagen cifrada mantiene la resolución que tiene la original. Con las consideraciones para el cifrado de imágenes descrito se puede lograr la generación de las claves pública y privada necesarias para la adaptación de otros métodos de clave pública para el cifrado de imágenes. 8. Trabajos Futuros Como trabajos futuros se considera la implementación de un método para el cifrado de archivos de audio y video. Para lograr esto, el cambio más significativo que se tendrá que realizar es el cambio del espacio de trabajo Zn procurando que el valor de n sea el mayor posible. Referencias Cormen, T.H., Leiserson, C.E., y Rivest R. L. (1990). Introduction to Algorithms. MIT Press. Van Droogenbroeck, M. (2004). Partial Encryption of Images for Real-Time Applications. Institut Montefiore B-28, Department of Electricity, Electronics and Computer Science, Sart Tilman, B-4000 Liège, Belgium. Goldwasser S. y Micali S. (1984). Probabilistic Encryption. Journal of Computer and System Sciences (JCSS), 28(2): Preliminary version in: 14th Annual ACM Symposium on Theory of Computing (STOC). Hernández, L., Martín del Rey, A., y Visus, I. (2002). Cifrado de Imágenes en tonos de gris mediante autómatas celulares. VII Reunión Española sobre Criptología y Seguridad de la Información. Lung Liu, J. (2006). Efficient selective encryption for JPEG 2000 images using private initial table. Department of Electrical Engineering, Chung Cheng Institute of Technology, National Defense University, Taiwan. Menezes, A., Van Oorshot, P., y Vanstone S. (1996). Handbook of Applied Cryptography. CRC Press. Murrugarra, N., Carranza, F., y Vaca, I. (2007). Método Esteganográfico usando Recorrido de Grafos en Imágenes. VI Jornadas Peruanas de Computación, Sociedad Peruana de Computación. Pareek, N.K., Partidar V., y Sud K.K. (2006). Image encryption using chaotic logistic map. Image and Vision Computing 24, Rivest R., Shamir A. y Adleman L. (1978). A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM, Vol. 21 (2), pp Ziedan, I., Fouad M., y Salem D.H. (2003). Application of Data encryption standard to bitmap and JPEG images. In Proceedings Twentieth National Radio Science Conference (NRSC 2003), pp. C16, Egypt. 109

110 Aplicando Programação Orientada a Aspectos para Construção da Camada de Persistência em Aplicações Java e Hibernate Mário Sérgio S. Torres, Leonardo D. Flora Cruz, Leonardo P. Mezzomo, Bruno Martins Moutinho Centro de Ciências Exatas e Tecnologia Universidade da Amazônia (UNAMA) Av. Alcindo Cacela, Belém Pará Brasil {scaramuzzini, leo13.cruz, leopossamai, bruno.moutinho}@gmail.com Abstract This paper presents such as the Aspect-Oriented Programming can be used in the persistence layer of data in order to separate and modulate entire source code of the persistence layer in areas within Java applications using AspectJ. It presents a tool based on this concept that automatically separates the entire source code necessary for the persistence layer of a Java application that uses the framework Hibernate in aspects. Resumo Este artigo apresenta como a Programação Orientada a Aspectos pode ser utilizada na camada de persistência de dados afim de modularizar e separar todo código-fonte da camada de persistência em aspectos dentro de aplicações Java utilizando AspectJ. Apresenta também uma ferramenta baseada nesse conceito que separa automaticamente todo o código-fonte necessário para a camada de persistência de uma aplicação Java que utiliza o framework Hibernate em aspectos. 1. Introdução Com o aumento da complexidade dos sistemas de software surge à necessidade de melhores técnicas de programação, com o objetivo de organizar e apoiar o processo de desenvolvimento de software. A Programação Orientada a Aspectos (POA) é uma tecnologia que ajuda os desenvolvedores a modularizar o software prometendo uma melhor estruturação do código e o desenvolvimento de software. A POA fornece uma maneira sistemática para uma efetiva modularização do sistema identificando os interesses transversais (crosscutting concerns) e evitando que eles fiquem espalhados no código. O principal paradigma utilizado atualmente para desenvolvimento de software é a Programação Orientada a Objetos que não possui mecanismos eficientes para a divisão dos requisitos, fazendo que em algumas situações eles fiquem entrelaçados e espalhados no código do sistema, o que dificulta a manutenção, evolução e reuso do código. A POA surge para tentar resolver esse problema, melhorando a produtividade no desenvolvimento de software, fornecendo suporte à modularização dos sistemas por meio de abstrações que possibilitem a separação e composição dos requisitos na construção de software. 110

111 Os interesses transversais são partes de programa que interferem em outros interesses, eles não são facilmente separados do resto do programa, tanto na estrutura quanto na implementação, isso acaba causando código entrelaçado (tangling), acontece quando a implementação de um pedaço de programa interage simultaneamente com vários interesses, por exemplo persistência; e código espalhado (scattering), acontece quando um interesse é implementado em múltiplos módulos. Sendo assim, a principal atividade dentro da POA é a identificação dos interesses transversais e em que pontos do código eles vão ser utilizados (join points). Tais interesses transversais devem ser identificados desde a primeira etapa na construção de um software, ou seja, a concepção, a partir da identificação dos requisitos de software, que definem os serviços que o sistema fornece e dispõe sobre suas restrições à operação. Os requisitos podem ser classificados em dois tipos, os funcionais que definem as tarefas do sistema e os não-funcionais que definem tarefas em segundo plano ou não obrigatórias. Por exemplo, um sistema de lançamentos de notas tem como requisito funcional calcular a média do aluno e como requisito não funcional a maneira como lidar com as informações da base de dados para o cálculo da média. Outros exemplos de requisitos não funcionais são: manutenibilidade, usabilidade, desempenho, custos, portabilidade, persistência e outras. Neste contexto, este trabalho apresenta uma ferramenta que gera automaticamente com base no arquivo de definição (XML) do framework de persistência Hibernate, aspectos que embutem todo o código-fonte necessário para o funcionamento do framework, não sendo necessária nenhuma alteração de código das classes de negócios. Este artigo está divido da seguinte forma: na seção 2 relatamos o histórico da Programação Orientada a Aspectos POA, conceitos e a linguagem AspectJ. A seção3 mostra o processo de desenvolvimento de software baseado em camadas, frameworks de persistência e Hibernate. Na seção 4 relacionamos a POA com a camada de persistência de um software. Na seção 5, é apresentada a ferramenta proposta (HAJ - Hibernate to AspectJ) e por fim, na seção 6 concluímos este artigo. 2. Programação Orientada a Aspectos A POA foi proposta em [Kiczales et al., 1997] como uma técnica que tem como objetivo melhorar o suporte à modularização dos interesses transversais por meio de abstrações que possibilitem a separação e composição destes interesses na construção dos sistemas de software (aspectos). A POA não tem o intuito de ser um novo paradigma de programação, mas uma nova técnica que deve ser utilizada em conjunto com linguagens de programação para construção de sistemas de software de melhor arquitetura, auxiliando na manutenção dos vários interesses e a compreensão do software. Entretanto, não é um antídoto para um design ruim ou insuficiente [Elrad et al., 2001]. Em um sistema de software os interesses são implementados em blocos de código, que manipulam dados. Os interesses que podem ser encapsulados de forma clara em uma unidade de função são chamados de componentes. Em POO esses interesses são modularizados em objetos, compostos por métodos que contêm a implementação do interesse, e os atributos compostos pelos dados manipulados pelos métodos. Na POA foi introduzido um novo mecanismo para abstração e composição, que facilita a modularização dos interesses transversais: o aspecto (aspect). Desta forma, os sistemas de software são decompostos em componentes e aspectos. Assim, os requisitos funcionais normalmente são 111

112 organizados em componentes através de uma linguagem POO, como Java, e os requisitos não funcionais como aspectos relacionados às propriedades que afetam o comportamento do sistema [Kiczales et al., 1997]. A POA conta com diversas áreas de aplicações e soluções para a área de desenvolvimento de software, geralmente relacionados com interesses transversais, tais como: atividades de log de sistema (logging), depuração em tempo de execução (debugging), técnicas de otimização, segurança e auditoria de sistemas, estabelecimento de contratos, camada de persistência e diversas outras aplicações que necessitem de separação de interesses. Esse trabalho apresenta uma forma de isolar em aspectos todo o código necessário para a camada de persistência utilizando o framework Hibernate Aspectos e AspectJ AspectJ é uma extensão de aspectos para a linguagem de programação Java. É compatível com Java em várias perspectivas: plataforma, desenvolvedor e IDEs. Um programa em AspectJ é executado sobre a JVM (Java Virtual Machine). A programação com AspectJ usa tanto objetos quanto aspectos para a separação de interesses. Existem dois tipos de interesses, os interesses-base que se referem às funcionalidades do sistema, que são implementados por objetos e os interesses transversais que são os requisitos não obrigatórios do sistema, como segurança, desempenho etc., que utilizam unidades independentes chamadas aspectos (aspects). O modo como o aspecto interage com o programa é definido como modelo de join point (JPM) no qual o aspecto é escrito. Os join points podem ser definidos como pontos ao longo da execução do programa onde existe um interesse transversal da aplicação. Eles podem ser localizados em: execuções de métodos, criação de objetos e lançamento de exceções, são dinâmicos e só podem ser descobertos em tempo de execução. Por esta razão, esse modelo é conhecido como modelo de join points dinâmico. O AspectJ tem dois JPMs: Pointcuts: um modo para especificar os join points; e Advice: um meio para alterar o comportamento dos join points. Para compor esses aspectos e torná-los funcionais é necessário um processo chamado weaving, que sugere três alternativas: Modificar a JVM para o reconhecimento de aspectos, Load-time weaving que consiste em modificar o código enquanto é carregado e Compiletime weaving que consiste em inserir o aspecto em tempo de compilação gerando bytecode Java, tendo como resultado final um programa em Java comum capaz de utilizar a JVM comum [Ramnivas, 2003]. O aspecto pode interferir em um programa em tempo de execução alterando o curso natural do programa. Toma uma decisão baseada em algo que esta acontecendo no software, sendo capaz de escolher o que fazer. Cada aspecto deve definir uma funcionalidade transversal e requisitos não funcionais em um software. Um aspecto pode declarar atributos e métodos, trabalhar com herança, interfaces, controle de exceção, além de permitir a definição de aspectos abstratos e concretos. Ele pode alterar uma classe Java, incluindo métodos e atributos relacionando heranças e etc. Exemplo de funcionalidade transversal é a persistência que será tratada nesse trabalho. 112

113 3. Desenvolvimento de Software Baseado em Camadas A Arquitetura em camadas é muito utilizada na Programação Orientada a Objetos para separar responsabilidades em uma aplicação. A separação entre os componentes é o foco de uma arquitetura desse tipo, para melhor organizar e manter componentes, onde é crucial que sejam separados por algum critério. Isolando-os em grupos é possível diminuir o acoplamento entre os componentes. Com isso, mudanças em um módulo não interferem diretamente em outro módulo. A arquitetura mais utilizada atualmente é a arquitetura de três camadas, e tem como principal objetivo "retirar" as regras do negócio da interface com o cliente e centralizá-las em um determinado ponto, que chamamos de camada de negócios. Posteriormente é utilizada outra camada chamada de camada de dados, na qual o acesso é feito exclusivamente através das regras contidas na camada de negócios. Sendo assim, as três camadas deste modelo são: Apresentação, Lógica ou Aplicação e de Dados. A camada de apresentação é a interface do usuário. Esta camada é composta por todas as máquinas clientes, e é nas mesmas que está instalado todo programa, caso o sistema seja Desktop ou caso o sistema seja Web, que possua um browser. Na camada de aplicação ou lógica estão às regras do negócio, as quais determinam de que maneira os dados serão utilizados. Esta camada é implementada em um Servidor de Aplicações. Sendo assim, quando uma regra do negócio for alterada, basta atualizá-la no Servidor de Aplicações. Após a atualização, todos os usuários passarão a ter acesso à nova versão, sem que seja necessário modificar a Camada de Apresentação. Na camada de dados é implementada em um servidor de banco de dados, no qual reside toda a informação necessária para o funcionamento da aplicação. Cabe ressaltar, novamente, que os dados somente são acessados através do servidor de aplicação, e não diretamente pela aplicação cliente. Um exemplo de uma aplicação que utiliza esse conceito são as aplicações JEE tradicionais que utilizam esse modelo em três camadas: Apresentação, Negócios e Dados. Na Camada de Apresentação estão todas as classes e demais artefatos (como páginas JSP) relacionados com a interação entre o usuário e a aplicação. A Camada de Negócios contêm a modelagem do domínio do problema em classes de negócio e a Camada de Dados contém as classes com conhecimento sobre como persistir objetos no banco de dados (por exemplo, DAO s). Da camada de dados surgiu um padrão proposto por [Yorder, Johnson, Wilson, 1998] chamado de camada de persistência para reduzir as diferenças entre a orientação a objetos e a persistência de dados em um banco relacional Frameworks de Persistência Como os modelos orientados a objetos tornaram-se um padrão no desenvolvimento de aplicações, os bancos de dados relacionais tornaram-se um padrão em armazenamento e recuperação de dados. Estas duas tendências motivaram a construção de aplicações orientadas a objetos que acessam bancos de dados relacionais. Dessa forma, as aplicações orientadas a objetos devem salvar seus objetos em uma base de dados relacional, onde nesse contexto é aconselhável o uso de um framework de persistência capaz de popular objetos de dados no código e salvar tais dados em um banco de dados relacionais. 113

114 A figura 1 ilustra a comunicação entre uma arquitetura de três camadas com a atuação de um framework de persistência, na camada de dados entre o servidor e o banco. Figura 1: Aplicações em camadas utilizando framework de persistência. Framework de persistência é uma biblioteca que permite a realização do processo de persistência (isto é, o armazenamento e manutenção do estado de objetos em algum meio não-volátil, como um banco de dados) de forma transparente. Graças à independência entre a camada de persistência e o repositório (banco de dados) utilizado, também é possível gerenciar a persistência de um modelo de objetos em diversos tipos de repositórios, teoricamente com pouco ou nenhum esforço extra. A utilização deste conceito permite ao desenvolvedor trabalhar como se estivesse em um sistema completamente orientado a objetos. O principal objetivo do framework é abstrair do desenvolvedor os detalhes de persistência, reduzindo o esforço de desenvolvimento e manutenção. Este é um caso especial de construção de camadas para nos protegermos de mudanças [Bushmann 1996]. Todos os objetos persistentes usam uma interface inicial do framework de persistência. Se nós quisermos mudar a forma de armazenar os dados no banco, somente esta camada precisa ser alterada, sem afetar o resto do programa. O framework de persistência é responsável por realizar operações básicas definidas pelo acrônimo em inglês: CRUD Create, Retrieve, Update, Delete. Existem alguns padrões de projeto definidos para trabalhar com frameworks de persistência, o Data Access Object DAO ou objeto de acesso a dados é um dos mais utilizado hoje em dia e é baseado na separação da implementação das operações CRUD da camada de negócios, este padrão encapsula o mecanismo de armazenamento de dados. Além do CRUD, existem outros sub-padrões para camada de persistência: gerenciador de tabelas, gerenciador de conexão, objeto persistente, métodos de mapeamento de atributos, descrição de código SQL, conversão de tipos, gerenciador de mudanças, gerenciador de identificadores únicos, gerenciador de transação. Existem vários frameworks de persistência no mercado como: Hibernate, JPA, etc. Nesse trabalho vamos utilizar o Hibernate, por ser um dos frameworks mais utilizados para desenvolvimento de aplicações Java. 114

115 Hibernate O Hibernate é um framework open source de persistência para a linguagem Java que permite persistir os objetos Java (incluindo polimorfismo, herança, composição, etc) com facilidade. O Hibernate tem como pilar de sustentação o Mapeamento Objeto Relacional (ORM), que possibilita realizar o mapeamento das entidades de um banco de dados através de uma coleção de metadados que atua conjuntamente com classes especializadas, conhecidas como POJO (Plain Old Java Objects). O mapeamento de entidades é feito por intermédio da linguagem XML (EXtensible Markup Language). Mapear significa catalogar características de orientação a objetos para características relacionais como cardinalidade, restrições de integridade e até encapsular consultas SQL (Structured Query Language). Ele possui ainda uma linguagem HQL (Hibernate Query Language) que provê uma conexão entre o sistema orientado a objetos e banco de dados relacionais. 4. Programação Orientada a Aspectos e a Camada de Persistência Ao separar um software em módulos, deixamos as camadas mais independentes, com isso, podemos aplicar a POA na camada de persistência de dados de um software para diminuir o espalhamento de código, retirar interesses transversais que ficam entrelaçados com requisitos funcionais de uma camada de persistência, movendo tais interesses para um aspecto, que será responsável especificamente para cada requisito não funcional encontrado. Dentre estes, podemos citar a inclusão de atributos que não fazem necessariamente parte de uma classe, procedimentos específicos de um framework e controle transacional. Sendo assim é possível migrar todo o código fonte necessário para o funcionamento do Hibernate (um interesse transversal) em aspectos, mantendo o código da aplicação intacto. Além disso, essa migração pode ser feita de forma automática através de uma ferramenta que cria os aspectos baseados no XML de definição do Hibernate, tal ferramenta é apresentada na seção Trabalhos relacionados Em [Ramnivas,2003] são tratadas questões de persistência de dados utilizando JDBC e uma implementação de controle transacional. E nos inspirou a controlar essas transações em um único aspecto. [Camargo, 2003] trata um modelo baseado em aspectos para a camada de persistência, definindo aspectos para cada interesse transversal, mas sem utilizar um framework para armazenamento de dados. Mesmo com a utilização de aspectos, o problema da separação da persistência e da preocupação desnecessária com a mesma é discutido em [Al-Mansari, M.; Hanenberg, S.; Unland, R., 2007] e divide-se em três razões: os desenvolvedores responsáveis pelo código principal continuam tendo que preparar objetos para persistência; Ainda tem que se preocupar com interesses de persistência o que quebra o princípio de independência da camada; armazenamento e atualização de objetos persistentes quebram o princípio citado devido à sobreestimada especificação de pointcuts. Então são sugeridos contêineres de persistência responsáveis por alocar objetos persistentes sem quebrar a independência da camada. Nosso artigo propõe algo relacionado, mas sem a necessidade de um contêiner. 115

116 5. Hibernate to AspectJ - HAJ A utilização do Hibernate deixa espalhado dentro das classes códigos específicos do framework e códigos repetitivos dentro de várias classes. O objetivo deste trabalho foi isolar em aspectos todo o código necessário ao funcionamento do framework de forma que o uso do framework fique quase que transparente para o usuário. Sendo assim, foi desenvolvida uma ferramenta para o desenvolvimento da camada de persistência baseada em aspectos realizando um mapeamento de arquivos XML. A intenção é com apenas um clique, seja possível construir uma camada de persistência com aspectos facilmente editáveis melhorando a modularidade e deixando o desenvolvedor com mais tempo para ser aplicado em camadas de negócio sem se preocupar com interesses transversais como a persistência de objetos. A ferramenta propõe uma iniciação em POA ao desenvolvedor que já utiliza o Hibernate. A figura 2 ilustra a interface visual do software HAJ, que tem como finalidade básica localizar o arquivo XML de mapeamento em um diretório de origem e apontar o diretório de destino, onde os arquivos gerados a partir da aplicação serão armazenados. Figura 2: Ferramenta Hibernate to AspectJ O software está preparado para trabalhar com framework de persistência Hibernate versão 2.1 em Java e a configuração do Hibernate feita através de XML. A ferramenta faz a leitura do arquivo XML necessário para a configuração do Hibernate de extensão.hbm.xml, cria os aspectos necessários e as classes em Java de objetos persistentes. Todo o software foi construído em Java com interface visual e possui escalabilidade para aumentar o alcance da aplicação no mundo corporativo, de forma que, pode ser utilizada no mercado profissional adequando a ferramenta a atender mais tags do hibernate ou se desejarmos implantar outros frameworks, já existe uma estrutura prévia que dá suporte ao desenvolvimento de outros módulos. Caso o outro framework também seja baseado em XML, poderá ser utilizado o módulo já existente. Tomamos como exemplo um mapeamento de uma tabela no banco de dados chamada Cliente, a seguir veremos trechos de códigos lidos e gerados pelo HAJ. XML Cliente.hbm.xml Trecho de Código 1 <?xml version="1.0"?> 116

117 <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 2.0//EN" " > <hibernate-mapping> <class name="cliente" table="cliente"> <id name="idcliente" column="idcliente" type="int"> <generator class="increment" /> </id> <property name="nome" column="nome" type="string" /> <property name="cpf" column="cpf" type="string" /> </class> </hibernate-mapping> O trecho de código acima é um documento XML utilizado pelo Hibernate para fazer o mapeamento entre camada de persistência e banco de dados. Este é o documento utilizado para a geração dos aspectos e da classe Java. Java Cliente.java - Trecho de Código 2 public class Cliente { String nome; String cpf; public Cliente(String nome,string cpf) { super(); this.nome = nome; this.cpf = cpf; } public String getnome() { return nome; } public void setnome(string nome) { this.nome = nome; } public String getcpf() { return cpf; } public void setcpf(string cpf) { this.cpf = cpf; } } Como podemos notar, o trecho de código 2, é uma classe Java, gerada a partir do XML. Deve-se notar que a classe não possui o campo idcliente, que aparece no Cliente.hbm.xml. Dessa forma, esta classe não poderia ser persistida utilizando o Hibernate, pois este precisa do atributo citado. AspectJ AspectoCliente.aj - Trecho de Código 3 public aspect AspectoCliente extends AspectoPersistencia { 117

118 private int Cliente.idCliente; public int Cliente.getIdCliente() { return this.idcliente; } public void Cliente.setIdCliente(int idcliente) { this.idcliente = idcliente; } public void Cliente.save() { } public void Cliente.update() { } public void Cliente.delete() { } public List Cliente.query(String query) { return null; } public void Cliente.beginTransaction() { } public void Cliente.closeTransaction() { } pointcut cadastro() : call(* Cliente.save(..)); pointcut atualizacao() : call(* Cliente.update(..)); pointcut remover() : call(* Cliente.delete(..)); pointcut query() : call(* Cliente.query(..)); after(cliente cliente) : cadastro()&& target(cliente) { try { if (!getsession().isconnected()) { begintransaction(); getsession().save(cliente); closetransaction(); } else { getsession().save(cliente); } } catch (Exception e) { e.printstacktrace(); } } } No trecho acima temos um arquivo de extensão.aj, escrito na linguagem AspectJ. No mapeamento realizado pela ferramenta, já são incluídos pelo aspecto os atributos de relacionamento, assim como seus gets and sets. São incluídos métodos herdados de um Aspecto abstrato chamado AspectoPersistencia, em que constam métodos responsáveis por realizar o controle transacional necessário ao uso do framework. São definidos pointcuts, que em qualquer parte do código que chamar os métodos citados da classe Cliente são disparados, acionando um ou mais advices. Como exemplo está exposto o advice de cadastro, que pega o objeto em questão verifica a existência de uma transação e persiste o objeto. 6. Conclusão A Programação Orientada a Aspectos tem crescido e esta sendo utilizada cada vez mais no meio corporativo. Vimos neste artigo algumas definições de camada de persistência e a 118

119 ferramenta Hibernate to AspectJ - HAJ, que tem como idéia principal iniciar o trabalho de quem já usa o hibernate para adaptar o código orientado a objeto, para aspectos, sem necessariamente precisar conhecer a linguagem AspectJ, ganhando assim modularidade na separação de interesses transversais. O software constrói os aspectos possibilitando sua alteração no que houver interesse do desenvolvedor. Por tratar-se de uma ferramenta acadêmica e o Hibernate um software altamente difundido, o HAJ não atende todas as tags do XML, somente as mais utilizadas. O processo de automatização é interessante e temos intenção de extende-lo para outros frameworks de persistência, como o muito utilizado atualmente: Java Persistence API (JPA). Em trabalhos futuros podem ser analisados, após o uso de AspectJ, os ganhos reais de modularidade, independência e códigos entrelaçados. Além de verificar a viabilidade de desenvolvimento de outros módulos do HAJ utilizando diretamente a conexão com o banco de dados, sem precisar de arquivos de configuração, como no Hibernate. Referências [Kiczales et al., 1997] Kiczales, G., Lamping, J., Mendhek a r, A., Maed a, C., Lopes, C.,Loingtier, J.-M., and Irwin, J. (1997). Aspect-Oriented Programming. Proceeding s Europe an Conference on Object-Oriented Programming. [Elrad et al., 2001] Elrad, T., Filman, R. E., and Bader, A. (2001). Aspect oriented programming. Communications of the ACM. [Ramos, Camargo, Penteado, Masiero, 2004]. Ramos, R. A.; Camargo, V. V.; Penteado, R.; Masiero, P. C. (2004). Reuso da Implementação Orientada a Aspectos do Padrão de Projeto Camada de Persistência. The Fourth Latin American Conference on Pattern Languages of Programming - SugarLoafPLoP. [Yorder, Johnson, Wilson, 1998]. Yorder, J. W.; Johnson, R. E.; Wilson, Q. D. (1998). Connecting Business Objects to Relational Databases. Conference on the Pattern Languages of Programs. [Bushmann, 1996]. Bushmann, Frank et al. Pattern-Oriented Software Architecture: A System of Patterns. [Ramnivas, 2003] Ramnivas, Laddad. AspectJ in Action: Practical Aspect-Oriented Programming, Manning Publications Co. [Al-Mansari, M.; Hanenberg, S.; Unland, R., 2007] Al-Mansari, M.; Hanenberg, S.; Unland, R. (2007). Orthogonal Persistence and AOP: a Balancing Act. Vancouver, Canada: ACM Press. 119

120 Identificación de problemas en proyectos de mejora de procesos: una experiencia en tres pequeñas empresas desarrolladoras de software en el Perú Eddy Maidana, Nohelia Vilchez, Juana Vega, Abraham Dávila Grupo de Investigación y Desarrollo en Ingeniería de Software Pontificia Universidad Católica del Perú {eddy.maidana, nohelia.vilchez, jcvega, abraham.davila}@pucp.edu.pe Resumen El proceso de mejora es una actividad cuyo éxito depende de varios factores que se encuentren en condiciones favorables y cuyo fracaso puede ser originado por al menos un factor en condición no favorable. En la bibliografía especializada, se encuentran los diversos factores a través de las lecciones aprendidas y propiamente los factores críticos de éxito de proyectos de mejora de procesos de diversos modelos. Todos estos factores se basan en hechos o situaciones ocurridas en los proyectos y que constituyen la base para definir riesgos en futuros proyectos semejantes, por lo que es necesario recogerlos de manera sistemática. Esta recopilación de problemas, en el contexto peruano, es importante por la influencia cultual que existe en nuestro medio. Este artículo presenta de manera estructurada los problemas encontrados en la implementación de proyectos de mejora de procesos en tres empresas pequeñas desarrolladoras de software en el Perú, dentro del proyecto COMPETISOFT. 1 Introducción En los últimos años, en el Perú, muchas organizaciones han enfocado su atención en la calidad de procesos del desarrollo de Software como elemento capaz de contribuir con la competitividad en el medio nacional. La mejora de procesos o SPI (de sus siglas en inglés de Software Processes Improvement) nace en respuesta a esta necesidad, convirtiéndose en una estrategia muy utilizada [1]. SPI es una alternativa para el logro del objetivo de desarrollar software de calidad y se basa en el hecho que la calidad del producto software está influenciada de la calidad del proceso con que éste es realizado. La mejora involucra conocer el estado actual de los procesos, planificar la mejora respecto a una referencia y hacer que los procesos actuales, con los ajustes debidos, correspondan con ella [9]. SPI involucra muchos modelos de calidad y los más aceptados por la industria de software a nivel mundial son: CMMI, ISO 9001:2000 e ISO/IEC 15504:2004 [1]. Sin embargo, existe dificultad en la aplicación de estos modelos para el caso de las micros, pequeñas y medianas empresas. La dificultad está dada, principalmente, por el alto esfuerzo y la elevada inversión que requieren. Considerando lo anterior, se inició el proyecto COMPETISOFT que busca fomentar la competitividad de la industria de software en Ibero América, constituido en su mayoría por pequeñas y medianas empresas [7]. Según, Layman [15], resulta evidente que el éxito de las iniciativas de mejora de procesos de software en una organización no está garantizado debido a los diversos problemas que se pueden suscitar a lo largo del proyecto de mejora. El conocimiento de estos problemas permitirá la planificación y toma de acciones que eviten que estos ocurran o afrontarlas de una manera adecuada [16] y así contribuir al aseguramiento del éxito de la iniciativa de mejora. 120

121 La implementación de SPI en una organización tiene implícita la incertidumbre de su éxito o fracaso pues el problema no es la falta de modelos que soporten la iniciativa de mejora de procesos sino la falta de una estrategia efectiva de implementación exitosa de los mismos [11], es decir, se reconoce que el problema para el SPI radica en un apropiado estrategia de la mejora [13]. Se ha reconocido que en materia de iniciativas de mejora se precisa de conocimientos basados en la experiencia [18], de modo que al aprender de sus errores va mejorando sus implementaciones [14]. Es así que estos conocimientos pueden llegar a formar una base de: lecciones aprendidas en implementaciones y factores críticos de éxito, los cuáles nos proporcionan una visibilidad de la serie de problemas que se pueden desencadenar. A su vez, el conocimiento de los posibles problemas fomenta una actitud vigilante durante la implementación de mejora de procesos de software y que sumado a una gestión de riesgos se contribuye al éxito de la mejora. Este artículo presenta los problemas encontrados en tres empresas pequeñas desarrolladoras de software durante la ejecución de proyectos de mejora dentro del programa de mejora de procesos COMPETISOFT-PUCP y cubre únicamente el primer ciclo de mejora (concluido) en dichas empresas. El artículo se organiza de la siguiente manera: en la sección 2, se presenta un marco de referencia; en la sección 3, se presenta una taxonomía de problemas encontrados en la implantación de mejora de procesos; en la sección 4, se presenta a las tres empresas participantes; en la sección 5, se muestra los problemas encontrados en los proyectos de mejora; y finalmente, en la sección 6, se presenta una breve discusión y trabajo futuro. 2 Marco de referencia En esta sección se presenta brevemente el concepto de mejora de procesos, se presenta el proyecto COMPETISOFT y la iniciativa en la Pontificia Universidad Católica del Perú (PUCP). 2.1 Mejora de procesos software SPI La demanda de software se ha incrementado de manera significativa por haberse convertido en la principal herramienta de trabajo de muchas organizaciones y usuarios; de igual modo, el proceso de desarrollo de software se ha vuelto más complejo y se manifiesta principalmente por incumplimiento en el costo, el tiempo o el alcance. Conviene señalar que es difícil obtener una mayor calidad en los productos, si no se definen y mejoran continuamente los procesos involucrados en la producción de software [2]. Frente a este escenario surge SPI como una estrategia muy utilizada en la mejora de procesos de Software [1]. SPI es un esfuerzo planeado, gestionado y controlado [3], que busca elevar la calidad y productividad del proceso de desarrollo del software, mejorar tiempos de entrega, reducir costos, defectos y retrabajo [4]. Los modelos utilizados para SPI identifican, organizan y armonizan las mejoras prácticas presentándolas con distintos enfoques pero de manera coherente entre sí; ejemplos de estos modelos son CMMI y ISO 9001:2000 (ISO/IEC 90003), entre otros. Lamentablemente estos modelos han sido pensados para empresas grandes y para realidades diferentes a la nuestra. La industria de software de gran parte del mundo está compuesta principalmente por micros, pequeñas y medianas empresas desarrolladoras de software [5]. Sin embargo, la aplicación de los modelos de calidad antes indicados requiere de mucho esfuerzo y de una fuerte inversión. Ante la dificultad en la implementación de los modelos grandes para las pymes, algunos países han desarrollado sus propios modelos tal es caso de MoProSoft de 121

122 México [6], MR.MPS de Brasil [19], y Agile SPI de Colombia [20]. Una reciente iniciativa la constituye el proyecto COMPETISOFT, un proyecto que busca mejorar la competitividad de las pequeñas y medianas empresas productoras de software de nuestra región [7]. 2.2 El proyecto COMPETISOFT COMPETISOFT es un proyecto que busca incrementar el nivel de competitividad de las pymes Iberoamericanas productoras de Software, a través de un marco metodológico común ajustado a las necesidades y características principales de las pymes (costo, tamaño y personal) del país [7]. Este proyecto presenta los siguientes modelos como parte de su estructura: el Modelo de Referencia de Procesos, el Modelo de Evaluación y el Modelo de Mejora de Procesos, los cuales se explicar a continuación. El modelo de procesos tomado como base para COMPETISFOT, es el modelo mexicano MoProSoft, que fomenta la estandarización de su operación, a través de la adhesión de las mejores prácticas en gestión e ingeniería de software. La adopción del modelo permite mejorar la capacidad de las organizaciones de brindar servicios con calidad y alcanzar niveles internacionales de competitividad [6]. El modelo MoProSoft tiene tres categorías de procesos que reflejan la estructura de una organización: i) Alta Dirección, conformado por el proceso de Gestión de Negocio; ii) Gerencia, compuesta por los procesos de Gestión de Procesos, Gestión de proyectos y Gestión de Recursos; a su vez éste último está constituido por los subprocesos de Recursos Humanos y Ambiente de Trabajo, Bienes, Servicios e Infraestructura y Conocimiento de la Organización; y iii) Operación constituida por los procesos de Administración de Proyectos Específicos y de Desarrollo y Mantenimiento de Software [6]. El modelo de evaluación de procesos tomado como base es el EvalProSoft y que a su vez está basado en la ISO/IEC El modelo EvalProSoft se aplica a las organizaciones dedicadas al desarrollo y/o mantenimiento de Software, en particular a las que han usado como modelo de procesos de referencia a MoProSoft. El propósito de aplicar este modelo es otorgar a la organización solicitante, un perfil del nivel de capacidad de los procesos implantados y un nivel de madurez de capacidades de la organización [8]. El modelo de mejora pmcompetisoft está basado en Agile SPI, el cual es un marco de referencia (framework) creado para la industria del software de Colombia. Es un proceso de mejora de procesos de software que guía la realización de un programa de mejoras y se caracteriza por ser liviano en su aplicación. pmcompetisoft está compuesto de 5 macro-actividades: Instalación, Diagnóstico, Formulación, Mejora y Revisión del Programa [7]. 2.3 Programa de Mejora de Procesos en Perú El programa de proyectos COMPETISOFT PUCP tiene como objetivo llevar a cabo pruebas controladas en distintas pymes desarrolladoras de software. La prueba controlada se entiende como la observación de la ejecución de un ciclo de mejora de procesos en un conjunto de empresas desarrolladoras de software del mercado peruano utilizando los modelos obtenidos del proyecto COMPETISOFT. Estas experiencias permiten conocer como las pymes realizan estas actividades, en especial, se han recopilado los problemas que ocurrieron en los ciclos de mejora de tres empresas. 122

123 3 Taxonomía de problemas en SPI Dada la amplia lista de problemas que se pueden suscitar en proyectos de mejora, es preciso poder reconocerlas u organizarlas bajo una categorización. En el estudio realizado por San Feliu y otros [11] se reportan diversos problemas encontrados en doce experiencias de SPI. Este estudio se basó en casos recientes (ocurridos desde el año 2000) de implementación de SPI que le permitieron recolectar 155 factores críticos de éxito y organizarlos bajo 15 categorías. En la Tabla 1 se presenta las categorías indicadas, la misma que ha sido tomado como referencia para clasificar los problemas encontrados en las pruebas controladas de COMPETISOFT. Categoría Descripción Patrocinio Compromiso de la alta gerencia; su participación activa influye en los demás miembros de la organización. Planeamiento de la Mejora Una guía adecuada para abordar la mejora; se debe enfocar en establecer una mejora contínua y no sólo en obtener un cierto nivel de madurez. Valoración Una visión realista del estado actual de sus procesos, indispensable antes de iniciar la mejora. Despliegue Manejo del despliegue de los procesos definidos adecuadamente. Respaldo Factores que influyen en la mejora: compromiso del personal, rotación del personal, contar con suficientes recursos, presión del tiempo. Asesoría Asesoría externa para llevar a cabo el plan de acción del proyecto de mejora. Habilidades Contar con una base teórica necesaria sobre: mejora de procesos de software, modelo de mejora usado, procesos. Prácticas de Referente al ambiente de trabajo y la percepción de que los procesos definidos harán que los trabajadores Trabajo sean intercambiables Sistema de Hace referencia al establecimiento de incentivos. Recompensas Participación Hace referencia al fomento de participación de los involucrados: influencia de los lídere de mejoras, de personal experimentado en el tema. Comunicación Proporciona un ambiente adecuado para la comunicación entre los participantes e involucrados en la mejora. Manejo del Relacionado a las actividades que soporten el manejo del cambio, como: un esfuerzo conciente y Cambio refuerzo periódico. Aprendizaje La existencia de un ambiente de aprendizaje (acceso a nuevo conocimiento), el cuál debe ser contínuo. Valores Historia Relacionado a las prácticas y pensamientos actuales en la empresa, el ambiente empresarial en cuanto a la apertura al cambio y a adquirir nuevas perspectivas o tendencias. Bagaje de experiencias pasadas. Experiencias de fracaso pasadas que pueden influir en la ejecución de la mejora actual. Tabla 1. Categorías de factores críticos de éxito en SPI adaptado de San Feliu [11] A continuación se presenta una recopilación de problemas: 1. Abordaje de la mejora centrado en procesos [12] [13]. 2. La mejora no se maneja como un proyecto [15] [10] [16] [20]. 3. Falta de participación de la alta gerencia [15] [10] [16] [20]. 4. No se demuestran mejoras a corto plazo [15]. 5. Procesos planteados son difíciles de usar [15] [20]. 6. Los pilotajes de los procesos no cuentan con los recursos necesarios [15]. 7. No hay una cultura de mejora continua de procesos [15] [16] [10]. 8. La mejora (procesos) no se alinea a las metas y necesidades de la organización [15] [10] [16] [20]. 9. El personal no se compromete con la mejora [10] [16]. 10. Falla en el entendimiento de los procesos en la etapa de despliegue [20]. 11. Selección inadecuada de los responsables de la mejora [10] [16]. 12. Falta de comunicación y colaboración [10]. 13. Expectativas irreales respecto a la mejora [10] 14. Resistencia al cambio [10] [16]. 123

124 15. Falta de asesoría externa [16]. 16. Falta de métricas que reflejen el efecto de la mejora [16] [20]. 17. Actitud pesimista ante el marco de trabajo [20]. 18. Demasiado tiempo en el proyecto de mejora [20]. 19. Falta de gestión de los riesgos del proyecto de mejora [20]. 20. Dedicación no exclusiva del equipo responsable de la mejora [20]. Cada uno de los problemas detectados ha sido categorizado en la Tabla 2. Categoria Patrocinio Planeamiento de la Mejora de procesos de software Valoración Despliegue Respaldo Asesoría Habilidades Prácticas de Trabajo Sistema de Recompensas Participación Comunicación Manejo del Cambio Aprendizaje Valores Historia Problema 3. Falta de participación de la alta gerencia. 6. Los pilotajes de los procesos no cuentan con los recursos necesarios 22. Recursos humanos insuficientes. 23. Presupuesto insuficiente. 24. Centralización de funciones. 2. La mejora no se maneja como un proyecto. 4. No se demuestran mejoras a corto plazo. 7. No hay una cultura de mejora contínua de procesos 8. La mejora (procesos) no se alinea a las metas y necesidades de la organización 16. Falta de métricas que reflejen el efecto de la mejora 19. Falta de gestión de los riesgos del proyecto de mejora 10. Falla en el entendimiento de los procesos en la etapa de despliegue. 5. Procesos planteados son difíciles de usar 9. El personal no se compromete con la mejora 1. Abordaje de la mejora centrado en procesos. 15. Falta de asesoría externa. 15. Falta de asesoría externa. 7. No hay una cultura de mejora contínua de procesos 13. Expectativas irreales respecto a la mejora 17. Actitud pesimista ante el marco de trabajo 9. El personal no se compromete con la mejora 11. Selección inadecuada de los responsables de la mejora 17. Actitud pesimista ante el marco de trabajo 20. Dedicación no exclusiva del equipo responsable de la mejora 21. Poca disposición de tiempo para la mejora. 12. Falta de comunicación y colaboración 14. Resistencia al cambio. 15. Falta de asesoría externa. 13. Expectativas irreales respecto a la mejora 17. Actitud pesimista ante el marco de trabajo 18. Demasiado tiempo en el proyecto de mejora Tabla 2. Mapeo de problemas y categorías 4 Empresas Participante Por razones de confidencialidad se presenta a las empresas usando letras griegas como seudónimos. Dseta es una empresa conformada por capitales peruanos que inició sus operaciones comerciales en Está dedicada al desarrollo de sistemas de información con la misión de contribuir a la mejora de las organizaciones brindándoles soluciones de alta tecnología a sus necesidades de negocios. Cuenta para ello con personal calificado y con experiencia exitosa en importantes organizaciones. Dseta ha implementado y mantiene soluciones desarrolladas a la medida en el sector de manufactura textil, comercialización de productos de consumo masivo, gestión integrada de empresas comerciales, gestión logística entre otras, ha desarrollado proyectos especiales de 124

125 computación móvil y tecnología inalámbrica todos ellos con la calidad y respaldo de sus profesionales. Actualmente tienen desarrollado un ERP, que es un producto de software propio, que está ganando prestigio en el mercado nacional. Es una familia de aplicaciones desarrollada para el sector textil y de confecciones que cubre todas las áreas de los procesos productivos y soporte para la gestión de manera integrada. Kappa nace en el año 1999, siendo su objetivo principal el de proveer a sus clientes de sistemas de información que integren y controlen la gestión de sus procesos, de la manera mas eficaz y eficiente posible. Y a la fecha han desarrollado e implementado varios productos en empresas comerciales e industriales de diferentes sectores. Kappa está enfocada en ofrecer un producto acorde a las necesidades de sus clientes, desarrollan un ERP como su producto principal, el cual integra los diversos módulos que una empresa maneja en sus gestiones. La venta de su producto se realiza siguiendo una estrategia que involucra publicidad a través de diversos medios, contacto con los clientes, demostraciones y acuerdos formales en caso de que la venta sea exitosa. El producto y el soporte correspondiente se venden a los clientes cuyas empresas requieren de una solución que incluya la interacción con uno o varios de los módulos implementados. La venta incluye el ajuste del producto a las particularidades de la realidad empresarial del cliente. Gamma es un pyme desarrolladora de software que inicia operaciones en el Dedicada principalmente a proyectos de implantación usando soluciones de software propias. La Empresa no licencia sus soluciones de software, pues ellas poseen una licencia del tipo GPL. En cambio facturan por los servicios de implantación/adaptación de la solución, monitoreo y soporte a la solución, así como, otros servicios asociados. Esto define a GAMMA como una empresa desarrolladora de soluciones de software libre con el objetivo inmediato de proveer servicios asociados al uso de sus soluciones. Sus clientes objetivos pertenecen a los sectores de Educación y Turismo representando el 43% de sus proyectos en los dos últimos años y el 100% de sus proyectos proyectados para el presente año. Ambos sectores además son los que representan el 75% de su facturación en los dos últimos años y además es este 43% de proyectos los que han permitido fortalecer la imagen de la empresa e incrementar sus clientes potenciales en el presente año. 5 Problemas encontrados en los proyectos de SPI Para la recopilación de los problemas se desarrollo un instrumento con lo que se registraron los problemas ocurridos en los tres proyectos de mejora. Uno de los primeros resultados es que se lograron identificar problemas adicionales que se resumen en la Tabla 3; problemas que tienen la peculiaridad de que se dan debido a la condición de ser pequeña empresa. Tabla 3. Problemas adicionales Problema 21. Poca disposición de tiempo para la mejora. 22. Recursos humanos insuficientes. 23. Presupuesto insuficiente. 24. Centralización de funciones. En las Tablas 4 y 5 se consolidan los problemas encontrados durante la implementación de la mejora de procesos en las tres pymes desarrolladoras de software. En especial la Tabla 4 muestra la ocurrencia de dichos problemas a lo largo de las fases de los ciclos de mejora; considerando que en algunas empresas se realizaron varios 125

126 pilotajes (por cada proceso que se consideró en el plan de mejora), los resultados obtenidos por las tres empresas en la matriz Problemas-Macro-actividades, indican que las fases críticas en implantaciones de Mejora de Procesos son: Formulación y Mejora, siendo ésta última la macro-actividad que reporta mayor cantidad de problemas. Este resultado es correspondiente a la realidad, dado que se encontraron diversos factores de retraso en el pilotaje y posteriormente en el despliegue de los procesos. Prob I D F M R Total Tot Fase Tabla 4: Problemas según fase del proceso de mejora. Categoria Id. Total por Problema problema Total por Categoría Patrocinio Planeamiento 2 28 de la Mejora de 4 9 procesos de 7 18 software Valoración 0 Despliegue Respaldo 9 0 Asesoría Habilidades 15 0 Prácticas de 7 18 Trabajo Sistema de Recompensas 9 0 Participación Comunicación Manejo del 0 Cambio 14 Aprendizaje 15 0 Valores Historia 18 0 Tabla 5: Problemas por categoría La Tabla 5 presenta los resultados por categorías de problemas, resultados que presentan a la categoría Patrocinio como la más crítica en una implementación de mejora de procesos. Este resultado es congruente con el valor obtenido en la Tabla 4 respecto al problema que más incidencia tuvo, que es el problema 3: Falta de participación real de la alta gerencia; pues los gerentes dicen que sí al proceso de 126

127 mejora, pero ello no se concreta en los hechos y de manera correspondiente se nota que las dos empresas que tenían menor compromiso real tuvieron un menor avance el proyecto de mejora de procesos de Software. A continuación se presenta un análisis cualitativo de cada empresa. Entre los problemas más notables para la empresa DSeta se encuentran: No se entiende a la Mejora de Procesos como un proyecto capaz de brindar competitividad a la organización sino como un servicio mas ofrecido por una profesional en la resolución de sus problemas puntuales. La gerencia tiene expectativas irreales respecto a la mejora ya que denota una falta de entendimiento de la magnitud, el esfuerzo y la envergadura que puede conllevar una Mejora de Procesos Falta de participación de la alta gerencia en el proyecto de mejora. No existen mejoras a corto plazo por la resistencia al cambio que muestran los participantes o por la tardía aplicación de éstos. No se realizó una selección adecuada del responsable de la mejora por parte de la organización. Carencia de métricas que muestren el efecto de la mejora. Esto se da por la tardía aplicación de los cambios o por la resistencia a éstos. Falta de gestión de los riesgos, lo que no permitió manejar planes de contingencia que contrarrestaran los efectos de los problemas. Entre los problemas más notables para la empresa Kappa se encuentran: Dos problemas presentados en KAPPA van de la mano ya que si bien se denota una falta de participación de la gerencia, ésta va asociada a la poca disposición de tiempo debido a que al no disponer de muchos recursos humanos, el tiempo de los involucrados se tuvo que compartir entre el tiempo para sus actividades cotidianas que de por sí ya estaban ajustadas con el tiempo para la mejora. Se denota también que los involucrados tienen expectativas irreales respecto a la mejora de procesos ya que no tienen claro el esfuerzo que requiere una iniciativa de mejora de procesos. También se suscitó que en un primer momento los procesos planteados se apegaron demasiado al modelo de referencia y no tanto a las necesidades de la organización. Lo que en un momento ocasionó la resistencia al cambio y la no colaboración en el pilotaje de los procesos al percibir los procesos como un mero flujo de documentos que no tenían utilidad. Entre los problemas más notables para la empresa Gamma se encuentran: Se observa que existe buena disposición del personal para el proyecto de la mejora. Pero este entusiasmo no se refleja en acciones concretas que permitan llevar a cabo la mejora. La perdida de prioridad es porque la gerencia ve la mejora como un tema de etéreo y de mercado exclusivamente; y porque le da menos prioridad respecto a otros proyectos. No se ve el proyecto de mejora como algo que beneficie el trabajo diario. Por ello el esfuerzo de la mejora dentro de la planificación del día a día tiene menor prioridad respecto a otros proyectos. Otro problema importante es que existe una marcada centralización de funciones en una persona y además está persona cuenta con tiempo limitado para realizar 127

128 este trabajo. Y por último una visión informal en términos de proyectos del proceso de mejora. Existe dificultad para establecer métricas que permitan demostrar que la mejora afecta de manera positiva el trabajo en la empresa 6 Discusión Final y Trabajo Futuro En el primer ciclo de mejora en las tres empresas se notó una marcada resistencia al cambio y en algunos casos, la percepción de los nuevos procesos como una mera burocracia de documentos que ocasionarían pérdidas de tiempo. En la etapa inicial, se trato de alinear los procesos de la empresa a los del modelo de referencia dando la impresión que las necesidades o metas inmediatas de la organización eran postergadas. Sin embargo, se aplicaron medidas de contingencia para reordenar el trabajo e introducir un nuevo esquema, enfocándose en la resolución de problemas de la organización con el objetivo de demostrar mejoras a corto plazo. Este nuevo enfoque permitió reafirmar en alguna medida el compromiso de la alta gerencia y de los involucrados en el proyecto de mejora. A pesar del cambio de enfoque y que las empresas lograron concluir el primer ciclo de mejora, ocurrieron diversos problemas que están asociadas al hecho que las pymes tienen que sobrevivir en un mercado complejo y por el que un proyecto de mejora pasa a un segundo plano. Al finalizar el primer ciclo de mejora se han consolidado los problemas presentados y se tiene previsto a futuro consolidar y sistematizar todas las soluciones aplicadas y los resultados conseguidos. A su vez, es recomendable recopilar y analizar factores críticos en la implantación de mejoras de procesos de experiencias previas, de modo que proporcionen la base de las acciones de mitigación y contingencia a considerarse en la gestión de un proyecto de mejora de procesos. Agradecimientos El presente trabajo está enmarcado dentro del proyecto 506AC0287 COMPETISOFT (Mejora de Procesos Para Fomentar la Competitividad de la Pequeña y Mediana Industria de Software de Iberoamérica) del programa CYTED (Ciencia y Tecnología para el Desarrollo) y apoyado parcialmente por la Dirección Académica de Investigación y el Departamento de Ingeniería de la Pontificia Universidad Católica del Perú. Referencias [1] Carmen J. Sánchez, Maria E. Solís, Francisco J. Pino, Julio A. Hurtado: Modelo Liviano de Calidad para la Mejora de Procesos de Desarrollo De Software. [2] Manuel de la Villa, Mercedes Ruiz, Isabel Ramos: Modelos de Evaluación y Mejora de Procesos: Análisis Comparativo [3] Francisco J. Pino, Manuel Serrano, Félix García, Mario Piattini, Hanna Oktaba: Medidas para estimar el rendimiento y capacidad de los procesos Software de conformidad con ISO/IEC Julio 2006 [4] Aileen P Cater-Steel: Low-rigour, Rapid Software Process Assessments for Small Software Development Firms [5] Revista Española de Innovación, Calidad e Ingeniería del Software. Volumen 2, No. 1, abril,

129 [6] Modelo de Procesos para la Industria de Software: MoProSoft, v1.3, México 2005 [7] COMPETISOFT: Proyecto de Mejora de procesos para fomentar la competitividad de la pequeña y mediana industria del software de Iberoamérica, V0.2, Diciembre 2006 [8] Método de Evaluación de procesos para la industria de software: EvalProSoft, v 1.1, México 2004 [9] Doo-Hwan Bae. Panel: Software Process Improvement for Small Organizations. CS Division, EECS Department KAIST, Gusongdong, Yusonggu, Daejon, Korea [10] Stelzer, Dirk and Mellis, Werner. Success Factors of Organizational Change in Software Process Improvement [11] San Feliu, Tomas, García, Suzanne and Graettinger Caroline. Critical Success Factors (CSF) in SPI Bibliography, Proceedings of the First International Research Workshop for Process Improvement in Small Settings, [12] Sakry, Mary and Potter, Neil. Goal-Problem Approach for Scoping an Improvement Program [13] Sakry, Mary and Potter, Neil. Developing a Software process improvement plan. Capítulo extraido del libro Making Process Improvement Work: A Concise Action Guide for Software Managers and Practitioners Disponible en: Página visitada el [14] Niazi, Mahmood, Wilson, David and Zowghi, Didar. A model for the Implementation of software process Improvement: A pilot study [15] Layman, Beth. Implementing an Organizational Software Process Improvement Program. [16] Hardgrave, Bill and Armstrong, Deborah. Software Process Improvement: It s a Journey, Not a Destination [17] Dybá, Tore. Factors of Software Process Improvement Success in Small and Large Organizations: An Empirical Study in the Scandinavian Context. [18] Jalote, P. Lessons learned in framework-based software process improvement. Software Engineering Conference, Ninth Asia-Pacific 4-6 Dec Page(s): [19] SOFTEX. MPS.BR Mejora de Proceso del Software Brasileño, Octubre [20] Hurtado J. El Modelo integral de mejoramiento Agile SPI. Universidad del Cauca,

130 Reconocimiento de Patrones Invariantes a Transformaciones Geométricas Jorge Arturo Perochena Caro and Juan Carlos Gutiérrez Cáceres Universidad Católica San Pablo, Facultad de Ingeniería Informática, Arequipa, Peru perochenajorge@gmail.com, jcgutierrezc@gmail.com Abstract. El reconocimiento de patrones requiere de técnicas o modelos que permitan su identificación a pesar de sufrir variaciones de rotación, traslación o escalamiento. El modelo de Reconocimiento de Patrones Invariantes a Transformaciones Geométricas (RPIT) parte de tomar un patrón y primeramente binarizarlo para posteriormente transformarlo a coordenadas polares (τ,φ), para lo cual tomamos como punto de partida el centro de masa del patrón, luego aplicamos la Transformada de Fourier a los ángulos φ y la Transformada de Wavelet a los radios τ, finalmente empleamos la estructura de datos métrica Slimtree como medio de almacenamiento y consulta de patrones. Este modelo nos permite reconocer imágenes a pesar de sus transformaciones geométricas como: rotación, traslación y escalamiento. Como muestras hemos empleado una base de datos con 396 imágenes, los resultados logrados muestran que las características de los descriptores de Fourier y Wavelet extraidos son útiles para el reconocimiento de imágenes invariantes a transformaciones geométricas. Key words: Reconocimiento de patrón invariante a transformación geométrica, Patrón de reconocimiento, Descriptor, Transformada de Fourier, Transformada Wavelet, Slimtree. 1 Introducción Al trabajar con imágenes se identifican dos problemas principales, el almacenamiento y la recuperación de dichas imágenes de manera rápida, eficiente, eficaz [1] y sobre todo precisa [2]. El tratamiento de imágenes realizado por el algoritmo propuesto denominado RPIT se inicia con un proceso de binarización para continuar con una de las etapas más importantes, la extracción de características, la cual nos permitirá generar vectores de características para poder realizar una adecuada indexación en alguna estructura de datos agilizando su búsqueda y recuperación [3]. Una característica es un atributo de la imagen, el cual es producto de funciones de una o mas medidas, calculadas de manera que cuantifique alguna propiedad de un objeto [2]. El proceso de extracción de características genera un 130

131 2 Jorge Arturo Perochena Caro and Juan Carlos Gutiérrez Cáceres conjunto de n valores numéricos que juntos constituyen el vector característico de la imagen, el cual puede ser representado como si fuese un punto en el espacio de características, dicho vector es almacenado en una base de datos, que no es mas que una estructura de datos, que nos permitirá almacenar y recuperar rápidamente las imágenes ante ciertas consultas. La recuperación de imágenes a sido desde los años 70 un campo de activa investigación, gracias al empuje de dos áreas de la computación: Gestión de Base de Datos y Visión por Computador, estas dos áreas investigan la recuperación de imágenes desde distintos ángulos: Basadas en texto y basadas en contenido[4]. Para poder hablar de la indexación y consecuente recuperación de las imágenes debemos de hablar de su representación, la cual esta determinada por los puntos más significativos, los que fueron establecidos en el proceso de extracción de características. La organización de información es efectuado por los sistemas de gerenciamiento de base de datos, mediante las llamadas estructuras de indexación (o estructuras de datos de almacenamiento y recuperación), las cuales son herramientas fundamentales que dotan a los sistemas gerenciadores de información de métodos de almacenamiento y recuperación de un gran volumen de datos [2]. En cuanto a las estructuras existen diversidad, aquellas que poseen un método de acceso espacial (Spatial Access Methods - SAM) [5], concepto que fue introducida por Kriegel [15], las cuales emplean la dimensión como método de indexación, las mismas que dieron lugar a investigaciones como las desarrolladas sobre los R-trees [6]. Sin embargo hoy en día existen otros tipos de estructuras las cuales no solo indexan espacios euclidianos sino que también indexan espacios métricos. Cuando hablamos de espacios métricos nos estamos refiriendo a vectores de características sobre imágenes, impresiones digitales, diccionarios de palabras [3], etc. Algunas de las principales estructuras son : BK-Tree [13] como una de las primeras sugerencias para espacios métricos discretos, posteriormente una mejora es lograda con el Fixed Query Tree [7] mediante el almacenamiento de algunas comparaciones entre las consultas y un nodo Pivot, a continuación surgen las estructuras VP-Tree [8] y MVP-Tree [9] las mismas que basandose en un criterio de varios puntos Pivot lograron una mejora significativa, sin embargo aún existía el problema del dinamismo en la construcción de las estructuras, el mismo que fue superado por las estructuras M-Tree [10], Slim-Tree [11] entre otras actualmente utilizadas. La actual problemática con las imágenes nos plantea entonces la necesidad cada día mayor por manejar y administrar adecuadamente la información contenida en ellas, las cuales han incrementado su tamaño [3] y utilidad. Las cuales deben poseer y revelar la mayor cantidad posible de datos, para poder ser identificados bajo cualquier circunstancia. Razón por la cual el objetivo de este trabajo de investigación es almacenar y recuperar una imágenes a pesar de que esta tengan transformaciones geométricas, específicamente traslación, rotación y escala. Éste artículo esta organizado en 5 secciones, donde la primer sección consiste en la introducción la cual describe los tema vinculados de manera di- 131

132 Reconocimiento de Patrones Invariantes a Transformaciones Geométricas 3 recta e indirecta en el tema de reconocimiento de patrones, la segunda sección es reconocimiento de imágenes invariantes a trasnformaciones geométricas la cual consiste en describir información sobre el proceso de extracción de características y de las técnicas que permiten lograr la invarianza a las transformaciones geométricas,la tercer sección es almacenamiento y recuperación de información la misma que consiste en el trabajo desempeñado por las estructuras métricas como medio de almacenamiento y consulta por similaridad, la cuarta sección es dedicada a la muestra de las pruebas y resultados y finalmente la quinta sección la dedicamos a las conclusiones de este trabajo. 2 Reconocimiento de imágenes invariantes a transformaciones geométricas El proceso para el reconocimiento de imágenes invariantes a transformaciones geométricas puede ser dividido en dos etapas una que es la extracción de características y otra que es el almacenamiento y recuperación para el proceso de extracción de características se debe seguir los siguientes pasos como puede ser visto en la figura: Fig. 1. Descripción gráfica del proceso del RPIT El proceso de extracción de características consiste de cuatro etapas: La primer etapa consiste en la conversión a coordenadas polares, la segunda etapa es la binarización, la tercer etapa es la aplicación de la trasformada de Fourier, y la cuarta etapa es la aplicación de la transformada de Wavelets. 2.1 Binarización La invarianza a traslación puede ser alcanzada encontrando el centroide de la imagen (x c,y c ), siendo éste el origen de las coordenadas polares. x px y px x c =, y c = Np Np (1) 132

133 4 Jorge Arturo Perochena Caro and Juan Carlos Gutiérrez Cáceres Fig. 2. centroide de x y y 2.2 Coordenadas Polares Las coordenadas polares bidimensionales son coordenadas constituidas por ρ(coordenada radial) y θ(coordenada angular). Como se muestra éstas están definidas en términos de las coordenadas cartesianas. x = ρcosθ, y = ρsenθ (2) donde ρ es la distancia radial desde el origen, y θ es el ángulo en sentido antihorario desde el eje x. En términos de x y y. ρ = x 2 + y 2, θ = tan 1 y/x (3) El calculo de coordenadas polares requiere el diseño de N círculos concéntricos imaginarios centralizados en (x c, y c ), con un radio r i, i = 1, 2,...N. Así como también requiere la generación de N vectores equidistantes en el ángulo θ partiendo desde (x c, y c ) con ángulos de 2π/N. En la figura (a) se muestra los círculos ya diseñados sobre la imagen, cada punto definido por el radio ρ y el ángulo θ será mapeado para poder encontrar el valor correspondiente en coordenadas polares, en (b) tenemos la imagen diseñada en coordenadas polares. 2.3 Transformada de Fourier: Una de las técnicas más populares en el procesamiento de señales es la transformada de Fourier, que tiene como objetivo transformar una señal (función) del dominio de espacio al dominio de frecuencia [16]. La función responsable de la transformación está dada por: F [u] = f[t]e i2πut dt (4) Una de las propiedades de la Transformada de Fourier es la invarianza al desplazamiento. Un caso particular de esta propiedad consiste en mover el origen 133

134 Reconocimiento de Patrones Invariantes a Transformaciones Geométricas 5 Fig. 3. (a) círculos concéntricos diseñados en la imagen, (b) imagen transformada en coordenadas polares. de la transformada de Fourier de f(x, y) al centro de la matriz N X N que le corresponda, es decir al punto (N/2,N/2). Para ello, podemos hacer uso de: donde se hace corresponder con: f(x, y)( 1) x+y (5) F (u n/2, v N/2) (6) Un desplazamiento en la función f(x, y), no provocará un cambio en la magnitud de su transformada de Fourier: F (u, v)e j2π(ux0+vy0)/n = F (u, v) (7) Como la imagen ha sido transformada en coordenadas polares, cualquier rotación en la imagen en el universo polar se tratara unicamente de un simple desplazamiento como se puede observar en la siguiente figura, y si a ésta imagen le aplicamos la Transformada de Fourier 1D con respecto al angulo ángulo θ, entonces los resultados de la imagen serán invariantes ante cualquier rotación. 2.4 Transformada Wavelets: Después de la transformada por ventanas de Fourier, la utilización de Wavelets es el paso lógico siguiente: se puede interpretar como una técnica por ventanas con regiones de dimensiones variables, donde las wavelets, diferentemente de Fourier, que tienen como base una función de duración limitada, esto es, de soporte compacto, que es una propiedad en la cual su dominio es diferente de cero, en una extensión finita es igual a cero en todo el resto. Ésto torna interesante la utilización de las wavelets en el caso especifico del análisis de imágenes, pues las variaciones de regiones o bordes pueden ser detectadas fácilmente. La definición de una transformada de Wavelets considerando una señal continua es dada por : 134

135 6 Jorge Arturo Perochena Caro and Juan Carlos Gutiérrez Cáceres Fig. 4. Coordenadas Polares de imagen original y transformada. F (a, b) = f(t)ψ a,b (t)dt, a, b R (8) donde las funciones ψ a,b son denominadas wavelets y definidas de la siguiente forma: ψ a,b (t) = 1 a ψ( t b a ) (9) La transformada de wavelets para señales discretas es definida como: F m,n (a, b) = a m/2 0 f(t)ψ(a m 0 t nb 0 ) (10) donde a y b representan la dilatación (escala) y traslación (tiempo), respectivamente. La función ψ recibe el nombre de wavelets madre. En ambos casos, esa wavelets madre, debe satisfacer la propiedad: ψ(t)dt = 0 (11) Las transformadas discretas de wavelets escogen un conjunto de escalas y localizaciones sobre las cuales los cálculos serán hechos, reduciendo así la cantidad de cálculos [18]. Existen dos contenidos dentro de la transformada discreta de wavelet: sistemas redundantes discretos (frames) y el ortonormal (y otras bases de wavelets). El segundo contenido considera la estrategia de análisis de multiresolución, desarrollada por Mallat, el cual permite obtener algunas propiedades que son útiles en ciertas aplicaciones. Transformada de Wavelets Haar: El análisis con Wavelets puede estar basado en el enfoque desarrollado por Haar. Haar describe una base ortonormal 135

136 Reconocimiento de Patrones Invariantes a Transformaciones Geométricas 7 de wavelets definida sobre el dominio [0,1], o sea h 0 (x), h 1 (x),..., h n (x), otras bases además de la de Fourier, tal que para cualquier función continua f(x) sobre el intervalo [0,1], la serie. < f, h j > h j (x) (12) j=1 Converge a f(x) de forma uniforme sobre [0,1]. Aquí < υ, ν > denota el producto interno de υ y ν. < υ, ν >= 1 0 υ(x)ν(x)dx (13) donde ν es un conjugado complejo de ν el cual es igual a ν si la función es real. Una versión de construcción de Haar es la siguiente: 1, x [0, 0.5) h(x) := -1, x [0.5, 1) (14) 0, caso contrario h n (x) = 2 j/2 h(2 j x k) (15) donde n = 2 j + k, k [0, 2 j ), x [2k j,(k+1)2 1 ) Ahora nuestra imagen es invariante a la rotación, para el caso de la escala usaremos la Transformada de Haar Wavelets 1D para trasnformar nuestra imagen, pero ahora con respecto al radio, luego se obtendra la desviación estandar de los diferentes coeficientes resultantes de aplicar de la transformada Haar Wavelets, ahora los resultados logrados serán invariantes a variación por tamaño. 3 Almacenamiento y Recuperación Los vectores obtenidos se almacenarán en estructuras de datos adecuadas, y por ser vectores multidimencionales podremos utilizar estructuras de acceso métrico. 3.1 Métodos de Acceso Métrico: Existen muchos casos donde los objetos a ser indexados no poseen coordenadas, por lo tanto no pueden ser tratados por Métodos de acceso espacial. Un caso típico es el conjunto de palabras de un diccionario. Para este tipo de datos existen los métodos de acceso métrico (MAM). Esta técnica también puede ser útil para ingresar datos vectoriales, pues el espacio vectorial es apenas un caso particular del espacio métrico. La mayor dificultad que presentaban algunas estructuras de datos radicaba en el dinamismo, pero como respuesta a esta dificultad surgen soluciones como el Slim-Tree, la cual es una estructura balanceada y dinámica, que permite inserciones posteriores a la creación del árbol. 136

137 8 Jorge Arturo Perochena Caro and Juan Carlos Gutiérrez Cáceres 3.2 Slimtree El Slimtree fue propuesto por Traina [11]. Su funcionamiento es similar al M- tree, pero el costo computacional del algoritmo de particionamiento es menor, sin perjudicar el desempeño de las consultas. La principal contribución del Slim-tree fue que representa un criterio para evaluar el grado de sobreposición entre los nodos del árbol, llamado fact-factor. El problema representado en el caso de espacios métricos es que no es posible calcular ese volumen. Ése criterio da origen a un algoritmo de reorganización de los nodos, llamado Slim-Down. El objetivo de ese algoritmo es lograr reducir el grado de sobreposición entre las subáreas. La diferencia de desempeño en relación al M-tree se debe a la utilización del algoritmo Minimal Spanning Tree (MST) durante la partición de un nodo. En esta fase es generado un MST incluyendo todos los elementos de la página a ser dividida y la mayor conexión es eliminada, éste algoritmo permite mejorar el costo MinMax, utilizado por el M tree, de O(n 3 ) para O(n 2 logn). 4 Pruebas y resultados: Para la evaluación del algoritmo RPIT se emplearon 126 imágenes, las mismas que tienen un tamaño de 256 X 256 pixeles, las cuales fueron binarizadas y polarizadas. En el espectro 1D para la transformada de Fourier son simétricas, sin embargo nosotros empleamos solamente la mitad de los coeficientes de Fourier. Por lo tanto el tamaño de G (τ,φ) es de 256 x 128 pixeles, por lo que el coeficiente Wavelet sera W F (τ,φ). A cada una de la imágenes originales se le aplicaron variantes de rotación por 30, 60 y 90, así como escalamientos por 50%, 80% y 120%. Los resultados logrados para variaciones conjuntas de rotación y escalamiento es de 89% sin errores y un 16% de errores. La siguiente figura muestra las imágenes empleadas como figuras base. A pesar de la similaridad existente entre imágenes, como por ejemplo las correspondientes a la imagen A2 con A4, A3 con A5, A7 con A9 y N6 con N9 el algoritmo RPIT mostro un alto grado de eficiencia. La siguiente tabla muestra el resumen de la matriz de confusión de los aciertos y errores que se lograron con el algoritmo RPIT. Total de Aciertos Total de Errores % 11% El proceso de evaluación consistió en la consulta por las 7 imágenes más parecidas al patrón correspondiente, dando como resultados los valores que a continuación se muestra en la matriz de confusión. 137

138 Reconocimiento de Patrones Invariantes a Transformaciones Geométricas 9 Fig. 5. Imágenes patrón Nombre de Imagen Número de Aciertos Número de Errores A1 7 1 A2 6 1 A3 6 0 A4 7 0 A5 6 1 A6 7 3 A7 7 0 A8 7 0 A9 5 3 N1 7 0 N2 7 0 N3 7 0 N4 7 0 N5 5 1 N6 5 2 N7 6 1 N8 7 0 N Conclusiones El algoritmo RPIT propuesto en el presente trabajo representa una herramienta computacional muy útil para el reconocimiento de patrones, dado el alto indice de eficiencia logrado ante las variaciones en los diferentes ángulos de rotación y los diversos rangos de escalamiento. A pesar que nuestras pruebas fueron realizadas con imágenes de dígitos y de aviones, el RPIT puede ser aplicado a otro tipo de imágenes como placas tomográficas, resonancias magnéticas, caracteres 138

139 10 Jorge Arturo Perochena Caro and Juan Carlos Gutiérrez Cáceres alfabéticos, etc. Futuros trabajos pueden ser realizados para identificación temprana de patologías clínicas en placas tomográficas y resonancias magnéticas. References 1. Garcia, J. (2001). Recuperación de Imágenes Utilizando Atributos Difusos. PhD thesis, Escuela Técnica Superior de Ingeniería Informatica, Malaga España. 2. Bueno, J. (2001). Soporte de Recuperación de Imágenes Médicas Basadas en el Contenido a Través de Histogramas Metricos. PhD thesis, ICMC-USP, USP-SAO CARLOS. 3. Beltrán, C. (2003). Recuperación de Imagenes por Contenido a Través de Análisis Multiresolución. PhD thesis, ICMC-USP. 4. Vargas-Machuca, J. E.-G. (2003). Recuperación de imágenes usando atributos difusos. In Escuela Técnica Superior de Ingeniería Informatica, pages Gaede, V. and Gunther, O. (1998). Multidimensional acess methods. In ACM Computing Survey, pages Guttman, A. (1984). R - trees: A dynamic index structure for spatial searching. In Proceeding of the International Conference on Data Management ACM, Boston, pages Baeza-Yates, R., Cunto, W., and Manber, U. (1994). Proximity matching using fixed-queries trees. In Proceedings of the 5th Annual Symposium on Combinatorial Pattern Matching, pages Chiueh, T. (1994). Content-based image indexing. In International Conference on Very Large Database-Santiago, Chile, pages Bozcaya, T. and Ozsoyoglu, Z. (1999). Indexing large metric spaces for similarity search queries. In ACM Transactions on Database System, pages Ciaccia, P., Patella, M., and Zezula, P. (1997). M-tree: Efficient access method for similarity search in metric spaces. In International Conference on Very Large Database-Athens, Greece, pages Traina, C., Traina, A., and Seeger, B. (1997). Slim-trees: High performance metric trees minimizing overlap between nodes. In International Conference on Extending Database Technology-Konstanz, Germany, pages Chavez, G. (2002). Sistema celular evolutivo para reconocimiento del patron de invarianza. Universidad Sao Paulo. 13. Burkhard, W. and Keller, R. (1973). Some approuches to best match file searching. In CACM, pages Yianilos, P. (1993). Data structures and algorithms for nearest neighbor search in general metric spaces. In ACM SIGACT SIAM Symposium on Discrete Algorithms. 15. N. Beckman,HP. Kriegel, R. Schneider, B. Seeger (1990). R*-tree: An Efficient and Robust Access Method for Points and Rectangles. In In ACM Int l Conference on Data Management (SIGMOD), proceeding pp Gonzales, R. and Woods, R. (1993). Digital image processing. In Addison Wesley. 17. Berthold K. P. Horn. (1987) Closed-form solution of absolute orientation using unit quaternions. In Journal of the Optical Society of America, pages Daubechies I. (1992) Ten Lectures on Wavelets.. In Society for Industry and Applied Mathematics, page

140 A Hierachical Proximity Graph for Similarity Search Alexander Ocsa 1,2, Omar U. Florez 3 1 Departamento de Informática Universidad Nacional de San Agustín Arequipa, Perú 2 Sociedad de Estudiantes en Ciencias de la Computación, Perú 3 Computer Science Department Utah State University Logan, USA aocsa@ieee.org, omarflorez19@gmail.com Abstract. Proximity graphs have been widely used in the area of computational geometry; through a vicinity concept these graphs establish relations of similarity between elements of a set. In this paper proposes a new dynamic data structure called Hypherspherical Region Graph (HRG) to efficiently index a large volume of data objects as a graph for similarity search in metric spaces. HRG encodes the given dataset in a smaller number of vertices than the known graph index, and groups in clusters objects that are near to the specific vertex. An empirical analysis performed on construction and search time HRG, however, outperforms tree-based indices in range search when the data dimensionality is not so high. 1. Introduction Searching plays an important role in many daily activities of modern societies and indexing is the preferred technique to speed-up search operations in databases. Hence, many data structures have been proposed to index vectorial representations of objects in the n-dimensional Euclidean space. However, since the metric space is more general than the Euclidean one, we can index any type of objects in a metric space with the only condition of defining a suitable distance function between objects. Examples of these objects come from multimedia (images, video, CAD drawings), internet (XML), Biology (DNA sequences), data mining (time series) and also include multidimensional vectors. However, many of these objects are imprecise by definition, e.g., the probability of obtaining two identical fingerprint patterns is very low, even if they belong to the same person. Hence, many researchers have put much effort into developing imprecise search or similarity queries into these metric data structures. In an especial manner, high dimensional datasets have always been one of the most difficult cases when testing similarity queries in metric data structures, mainly because: Ű Distance functions for high dimensional vectors are expensive. Ű When the dimension increases, search spaces tend to be more uniform in terms of density. Thus, they are also more difficult to prune during search time. Since the distance function can have a high computational cost, it is assumed that the performance of Metric Access Methods (MAM) depends mainly on the Number of Distance Calculations (NDC) performed during construction and search processes. Working with large datasets (i.e. multimedia data) the 140

141 access to secondary memory must also be considered. Some of the most popular metric indexing structures are those based on fixed-size regions such as: M- tree [Ciaccia et al. 1997], Slim-tree [Caetano Traina et al. 2000], and DBM-Tree [Marcos R. Viera and Traina 2004]. The popularity of this type of indices relies on the direct implementation of each region as a page in secondary storage. However, the above problems associated with high dimensional datasets are specially warned in this type of indices. This is because, regions become so close to each other that produce overlap between regions. Within computational geometry, graph-based methods build proximity graphs, also called neighborhood graphs, on a set of points, creating edges among these points based on a neighborhood criterion. This approach produced excellent results on clustering tasks and on applications of computational vision and pattern recognition, visual perception, biology, geography and cartography. Neighborhood can be defined in terms of geometric attributes such as coordinates, distance, density or forms. In proximity graphs, Relative Neighborhood Graph (RNG) is a prominent representative [Jaromczyk and Toussaint 1992a]. The paper is organized as follows: Section 2 presents a review of previous work. Section 3 describes the proposed technique. Section 4 shows the experimental results. Finally, Section 5 presents the conclusions of the paper. 2. Previous work A common characteristic in applications of similarity information retrieval is the existence of a universe of objects U and a function d : U U R that measures the distance between two objects of U. Working in metric spaces, we define S U as a finite set of data that can be preprocessed, where the function d() measures the dissimilarity among objects and satisfies the following conditions, x, y, z U: 1. d(x, y) 0 positivity 2. d(x, y) = d(y, x) symmetry 3. d(x, y) = 0 x = y reflexibility 4. d(x, y) d(x, z) + d(y, z) triangle inequality Triangle inequality is the most important property because it gives bounds on a distance we may not have computed, leading to similarity search algorithms significantly faster i.e. if we have the distances d(x, z) and d(y, z), the bounds for the unknown distance d(x, y) are d(x, z) d(y, z) d(x, y) d(x, z) + d(y, z) [Clarkson 2006]. That is to say, it is possible to discard regions which do not overlap the query region, as it can be seen in Figure 1. Given a query object q U, in order to recover similar objects to q, the following basic types of queries are defined: Range queryrq(q, r): Which finds all elements that are within the query radius r. Rq(q, r) = {u U d(u, q) r}. k-nearest neighbor query knn(q, k): Which finds the k nearest neighbors of q. Finds a set A U so that A = k and u A, v U A, d(q, u) d(q, v). Nearest neighbor query NN(q): Which finds the nearest neighbor of q. NN(q) = knn(q, 1). 141

142 Figure 1. Unified model for searching in metric spaces [Chávez et al. 2001]. Metric Access Methods (MAM) organize a dataset using a similarity criterion. MAMs are structures that work over metric spaces, organizing data for an efficient answer to similarity queries. Good surveys on MAMs can be found in [Chávez et al. 2001], [Hjaltason and Samet 2003], and [Clarkson 2006]. According to [Zezula et al. 2006], MAMs can be classified as: Ball-partitioning methods: Fixed Queries Tree, Vantage Point Tree. Hyper-plane partitioning methods: Generalized Hyper-plane Tree. Precomputed distances: Approximating Eliminating Search Algorithm (AESA). Hybrid methods: Multi Vantage Point Tree, GNAT, Spacial Approximation Tree (SAT). Others: M-Tree, D-Index. In [Chávez et al. 2001] M-Tree [Ciaccia et al. 1997] is classified as a method based on covering radius. Thus, Slim-Tree [Caetano Traina et al. 2000] and DBM- Tree [Marcos R. Viera and Traina 2004] could be also considered under this classification since they work in a similar way. The M-Tree [Ciaccia et al. 1997] based techniques, grow bottom-up from leaves to rootfrom leaves to the root organizing the objects in a hierarchical structure using a representative as the center of each region which covers the objects in a sub-tree. The Slim-Tree [Caetano Traina et al. 2000] introduces new split and insertion algorithms as well as the Slim-down algorithm and an overlapping measure called Fat-factor to build faster trees. The split algorithm is based on the Minimum Spanning Tree (MST). The Slim-down algorithm is presented to reduce the degree of overlap, making the metric tree tighter thus improving query and building performance. The DBM-Tree [Marcos R. Viera and Traina 2004] operates in a similar way to Slim-Tree. This MAM proposes to relax the height of the tree in regions with high density of data in order to minimize the overlap of nodes. This approach reduces the number of distance computations without affecting the number of disk accesses. 142

143 The effort of reducing the overlap makes these techniques to work well in low and medium dimensionality, but working with high dimensional data, the overlapping among regions could be so high that the idea of data representation with a hyper-spherical regions hierarchy deteriorates the results compared with a sequential search [Böhm et al. 2001]. On the other hand, in the field of computational geometry, a graph is defined by G(V, E) where V is a set of points in R n and E : V V a set of edges. In proximity graphs a property P (neighborhood criterion) is defined, and each pair of points (p, q) V V is connected by an edge e E with weight d(p, q) if and only if they fulfill P ; then p is neighbor of q and vice versa. Furthermore, proximity graphs connect spatially near points, reflecting the proximity between them. In order to define the some proximity graphs we must consider: d : V V R a distance function defined in some metric, and B(x, r) a sphere with center in x V and radio r, i.e. B(x, r) = y : d(x, y) < r. Considering these definitions, some proximity graphs include: Delaunay Triangulation (DT): For each triangulation T in V, the circumcircle C(T ) does not contain points of V. Gabriel Graph (GG): (x, y) E : B( x+y, d(x,y) ) V =. 2 2 Relative Neighborhood Graph (RNG): (x, y) E : (B(x, d(x, y)) B(y, d(x, y))) V =. Figure 2 shows the intersection of the two spheres. That is, two points x, y V are neighbors if d(x, y) max{d(x, z), d(y, z)} z V z x, y. MST: In a weighted graph, MST is the minimum-weight tree which contains all of the graph s vertices. Figure 2. The inner circle shows the exclusion area applied in GG. The gray area shows the exclusion area applied in RNG. In order to connect x and y, there are no other points of V inside the exclusion area. In [Toussaint 1980] the hierarchy relation MST RNG DT was demonstrated. In [Toussaint 1980] two construction algorithms for RNG with costs O(n 3 ) and O(n 2 ) were also presented. [Supowit 1983] showed construction algorithms with cost O(nlogn). Most of these algorithms work over Euclidean spaces because they are based on the Delaunay Triangulation (DT). Since RNG is defined purely in terms of the metric distance, a construction algorithm not based on DT could be developed using a divide-and-conquer approach, therefore applicable to any metric space. 143

144 3. Hyperspherical Region Graph As introduced in section, our strategy in finding a solution to the similarity search problem in a large metric space is to design a graph data structure. We prefer a graph-based approach mainly because additional edges in a graph allow us to traverse the data structure without backtracking to upper vertices which is required in a tree [Paolo Ciaccia and Zezula 1997] [C. Traina et al. 2002] [Marcos R. Viera and Traina 2004] [Navarro 2002]. In addition, the constraint on the root node as a starting point in a tree is relaxed in a graph because any vertex can be a starting point. Note that the flexibility in graph traversal is enabled at the expense of additional edge insertions. Subsequently, an efficient management of edge insertion must be addressed in order to make a graph practical as an alternative to a tree data structure in similarity search. We now present the graph structure proposed in this paper, called hyperspherical region graph (HRG) The graph The proposed hyperspherical region graph is a type of the relative neighborhood graph (RNG) [Jaromczyk and Toussaint 1992b] defined as follows: Given a graph G = (V, E), let H(v i, v j ), for any pair of vertices (v i, v j ) V 2, be the hypersphere of radius d(v i, v j ), for some distance function d : V V R +, with v i as the center of the hypersphere. Then, G is a relative neighborhood graph if any edge (v i, v j ) E satisfies the neighborhood relationship constraint: (H(v i, v j ) H(v j, v i )) V = where H(v i, v j ) H(v j, v i ) returns the inner volume of the lune formed by the intersection of the two hyperspheres excluding the lune s surface. In other words, two connected vertices are neighbors in RNG. Intuitively, RNG reduces redundant neighborhood relationships by excluding the edge between adjacent vertices v 1 and v 2 if any vertex v 3 is found in the lune formed by the intersection of the hyperspheres centered at v 1 and v 2, i.e., if the distance from v 3 to either v 1 or v 2 is smaller than the distance between v 1 and v 2. The reason for using RNG instead of other types of graphs such as Delaunay triangulation is that RNG is defined based only on distances between vertices. This characteristic makes RNG a suitable option to perform similarity search not only in Euclidean spaces but also in arbitrary metric spaces. HRG extends the idea of RNG to represent the structure of a metric space using representative vertices of hyperspherical regions as follows: A hyperspherical region H = (v, c, O) in a metric space is a hypersphere of objects {v, O = {o 1, o 2,..., o n }}, where (1) v is the center object of H, (2) c is the capacity of H, i.e., the maximum number of objects that can be included in H, and (3) O is the set of member objects that are currently contained in H (with the exclusion of v). Furthermore, the distance between v and the farthest object in H is called the radius of H. From now on, H(v) will be used as a shorthand notation for H(v, c, O) as long as c and O are clear in the context. Furthermore, c H(v) denotes c of H(v), and 144

145 H(v) = O +1. Given a set of hyperspherical regions {H(v 1 ),..., H(v n )}, the hyperspherical region graph G H = (V, E) is a relative neighborhood graph where V = {v 1,..., v n }, i.e., the center objects of the regions, and E is the set of edges between neighboring vertices. Furthermore, c H(v1 ) =... = c H(vn) Since a hyperspherical region graph G H is consisted of only the vertices that are centers of hyperspherical regions, not of all the data objects, the number of vertices in G H is generally smaller than that of the RNG of the same dataset, which enables us to construct G H by a less number of edge insertions. We now continue to discuss on the construction of a hyperspherical region graph. In HRG construction, our goal is to minimize the update (either insertion or deletion) of the existing edges whenever we add a new object into the graph. The realization of this goal involves identifying the regions affected by vertex insertions, and hence we present the search technique used first Similarity search in HRG: Range Search A range search is defined by the set of objects which are at most at the distance r from the query object x. Given a universe U of data objects, RangeSearch (x, r) = {s U d(x, s) r}. To reduce the search space in range search, the search is performed at two different levels in our approach: (1) the graph level, and (2) the region level. Graph-level reduction For the graph-level search space reduction, being a the starting vertex chosen randomly, the distance between x and each of the neighboring vertices of a, denoted N(a), including a, is computed first. Then, a search space reduction technique, inspired by the spatial approximation method [Navarro 2002], is applied to visit only the vertices which are close enough to x among the vertices in {a} N(a) based on the distances. Closeness is defined as follows: Given a set of vertices V and the query object x, v V is a close-enough vertex to x if d(x, v) min dist + 2r where min dist = min w V d(x, w) and r denotes the given distance tolerance to x from v. This search space reduction technique is applied recursively through all the neighboring nodes that are close enough to x as long as such neighbors are found and have not been visited yet. All the visited vertices with no close-enough neighbors other than the originating neighbor are identified as candidate vertices. Let {v 1,..., v k } be the set of candidate vertices of x. Then, any region H(v i ) (1 i k) which intersects that of x, i.e., H(x) is returned as a candidate region because they have a higher likelihood of containing the target objects of the range search than the non-intersecting regions. Region-level reduction The objective of this step is to find the range search result by the given query object x and radius r. The result consists of the objects that are selected from the member objects of the candidate regions by checking if 145

146 (a) SA-tree (b) HRG Figure 3. Edge exploration by SA-tree and HRG. Thicker edges denote visited edges. A fewer edges are visited in HRG than in SA-tree. they belong to the range search region centered at x with radius r. In this process, a search space reduction is achieved by using the triangular inequality to avoid computing the distance between each member object o and x, i.e., d(x, o). Note that the distance between the center object v and o is already known. The distance between x and v has been already calculated also. Hence, we can approximate our decision that o belongs to RangeSearch(x, r) if the condition d(v, x) d(v, o) r holds. Note that it is guaranteed that for any pair of vertices v 1, v 2 in a Delaunay triangulation graph, there exists one or more paths from v 1 to v 2. Since HRG is an extension of RNG and RNG is a subgraph of Delaunay triangulation, the path of minimum length between v 1 and v 2 exists. Using both search space reduction techniques, we were able to visit 30% less edges in our approach than in SA-tree. Figure 3 contrasts the area explored by our approach and SA-tree when performing a Range Search around the object x. The range search process is summarized in the Algorithm 1, it is first invoked as RangeSearch(a, queryobject, range, ), a is a random vertex in G H. Algorithm 1 RangeSearch (Vertex a, Object x, Range r, Distance min dist 1: if a has not been visited yet then 2: if d(a, x) r radiusregion(a) d(a, x) + r radiusregion(a) then 3: for each object o in H(a) do 4: if d(a, x) d(o, a) r then 5: if calculatedistance(o, x) r then 6: Insert a to query Result 7: end if 8: end if 9: end for 10: end if 11: min dist := min{{min dist} {d(b, x) : b N(a)}}; 12: for b N(a) do 13: if d(b, x) min dist + 2r then 14: mark b as VISITED; 146

147 end 15: RangeSearch(b, x, r, min dist); 16: end if 17: end for 18: end if 3.3. Construction of HRG HRG is a dynamic structure that allows to insert new objects at any time. Before inserting a new object x into G H = (V, E), we search a vertex a V which is closer to x than any other vertex, starting at vertex b V. This search is known as Nearest Neighbor Search and intuitively includes the following steps: 1. Start with a random vertex b in G H. 2. Compute the distance between the new object x and each vertex in N(a). 3. Traverse to the smallest vertex a i N(a), and repeat from Step 2 as long as a vertex with a shorter distance is found. As soon as such nearest vertex a is found, x is inserted into H(a) rather than being inserted as a new vertex in G H. In such a case, we check the cardinality, H(a), of the updated H(a). If H(a) is less than or equal to the capacity of H(a), c, the insertion operation of x is completed. If H(a) is already saturated to its capacity, H(a) is divided into two regions H (a) and H(y) such that one of the farthest objects y of H(a) becomes a new vertex in G H, and all other objects in H(a) are retained in H (a). Subsequently, a new region H(y) = (y, c H(a), {}) is generated. Note that the capacity of H(y) is set to the same capacity of H(a). This process is summarized recursively in Algorithm 2. Note that the addition of a new vertex in G H, subsequently the addition of the corresponding new region, requires the update of the neighborhood relationships among the vertices because the relationships may change according to the neighborhood constraint of RNG. This can be as simple as inserting an edge between the new vertex x and the existing vertex from which x was born. However, x may change the existing neighborhood relationships. We now compare the constructions of a hyperspherical region graph G H of capacity 2 and a relative neighborhood graph G R step by step in the following example using Figure 4. In the example, η(a, b) denotes the neighborhood relationship between vertices a and b. HRG minimizes the insertion of edges between vertices by storing non-vertex objects in regions without creating edges. For example, after the six objects are inserted in Figure 4, HRG with capacity of 2 modifies only 5 edges (4 insertions and 1 deletion) whereas RNG modifies 11 edges (8 insertions and 3 deletions), leading to 55% less edge update in HRG. Insertion of a new vertex into G H may have an impact on the neighborhood relationships in G H since G H is a type of RNG. Clearly, we want to avoid to reevaluate the entire neighborhood relationships each time we add a vertex, but update only the neighborhood relationships affected by the new vertex. This strategy is called LocalInsert in our algorithm. 147

148 (a) (b) (c) (d) (e) Figure 4. Step-by-step comparison in the construction of our HRG and the RNG. The left graph of each figure is the HRG while the right graph is the RNG. After five insertions HRG reduce in 44% the number of edges modified, this percentage is proporcional to the capacity of hyperspheres. LocalInsert Given the new vertex x which is the center of the region having no member objects yet, LocalInsert() first identifies the vertices which are located within certain distance r from x. The distance r is determined based on the distance from the new vertex x to the center of the closest region H(a), i.e., d(a, x), and another distance to the farthest object f in H(a), i.e., d(f, x). We want to scale this distance by a tolerance parameter ɛ. If ɛ is set to a larger value, we can obtain a more global solution with the price of high edge update cost. On the other hand, with a smaller ɛ, we can achieve more cost effective edge update with potentially less optimal graph structure. Practically, a real number in the range [0 1] is chosen for ɛ. By using the range query with the distance r as the radius, we obtain existing vertices in the graph which are potentially neighbors to the new vertex x. For this set of vertices, actual neighborhood relationships are updated. By employing this strategy, we are able to achieve a better performance than Incremental-RNG [Hacid and Yoshida 2007]. The process of inserting a new vertex in G H is summarized in Algorithm 3. Algorithm 2 Insert (Vertex b, Object x) // b: starting location, x: new object 1: a := the vertex of the region where the nearest neighbor to x is placed; 2: if H(a) < c then 3: H(a) := H(a) {x}; // x becomes a member object of H(a) 4: save distance d(a, x); 5: else if d(a, x) > regionradius(h(a)) then 6: LocalInsert(a, x); // insert x as a new vertex 148

149 end 7: else 8: H(a) := H(a) {x}; // x becomes a member object of H(a) 9: x := f arthestobject(h(a)); // x: farthest object in H(a) 10: H(a) := H(a) {x}; 11: LocalInsert(a, x); 12: end if Algorithm 3 LocalInsert (Vertex a, Vertex x) 1: f := f arthestobject(h(a)); 2: r := (d(a, x) + d(f, x)) (1 + ɛ); 3: result := RangeSearch(x, r); // result: set of vertices 4: buildrn G(result {x}); // x becomes a new vertex; update neighborhood end 4. Experimental Results We tested the proposed HRG in terms of construction and similarity search operations using two real and two synthetic datasets. 1. ECG-18: This is a real dataset consisted of dimensional objects processed from electrocardiograms (ECG) of arrhythmias found in the UC Irvine Machine Learning Repository GrayLevelHistogram-256: This is a real dataset consisted of dimensional gray level histograms found in the Amsterdam Library of Object Images (ALOI) Synthetic-2: This synthetic dataset contains 1,000 2-dimensional vectors normally distributed in 10 clusters with overall standard deviation of 0.1 over a rectangle with a minimum and maximum value of 0 and 1 on each dimension respectively. 4. Synthetic-16: This synthetic dataset contains 1, dimensional vectors normally distributed in 10 clusters with overall standard deviation of 0.1 over a hypercube with a minimum and maximum value of 0 and 1 on each dimension respectively. The performance of HRG was then compared to those of the two most well known tree structures M-tree [Paolo Ciaccia and Zezula 1997] and SA-tree[Navarro 2002], and a graph data structure Incremental-RNG [Hacid and Yoshida 2007] in terms of the number of distance computations, total response time, and memory usage. The Euclidean distance (L 2 ) was used as the distance function in our experiments Similarity search performance NDC In this test, the data structures in comparison were tested with different range search radii, ranging from 10% to 100% of the maximum distance between the

150 (a) Range query: Synthetic-2 (b) Range query: Synthetic-16 (c) Range query: ECG-18 (d) Range query: GrayLevelHistogram-256 Figure 5. Comparison of HRG by number of distance computations in range search. Note that the scale of y-axis is different from one figure to another. two farthest objects in the dataset. HRG performed better than all other structures with Synthetic-2, Synthetic-16 and ECG-18, as shown in Figures 5(a), 5(b) and 5(c). With GrayLevelHistogram-256, HRG outperformed Incremental-RNG with a comparable performance with M-tree (see Figure 5(d)). In case of GrayLevelHistogram- 256, potentially high overlap among the regions in HGR offsets the anticipated benefit of HRG. In case of such high dimensional data, we observed that SA-tree is the best out of the structures in comparison. Response time This test was conducted in a similar way to the above to measure the total evaluation time of range searches. All the test dataset was fit into the main memory. The performance of HRG in this test was congruent with the result of NDC, which was anticipated because the main cost during running time is the computation of distances between objects, as the result is shown in Figure Conclusions This paper introduced a graph-based indexing algorithm and discussed its performance for the similarity search problem in metric spaces. The proposed algorithm, which uses a small representation of the search space, can be classified as a compact partitioning algorithm. The notion of neighborhood present in the spatial approximation search technique [Navarro 2002] is fully exploited in the graph. Moreover, 150

151 (a) Range query: Synthetic-2 (b) Range query: Synthetic-16 (c) Range query: ECG-18 (d) Range query: GrayLevelHistogram-256 Figure 6. Comparison of HRG by total range query evaluation time at various radii. since each vertex is the center of a hyperspherical region, our approach only visits the neighbors which are close enough to the query object, thus saving the evaluation of distances between the query object and other objects. The experimental results showed that the proposed method performs better than other tree and graph-based approaches in similarity search with datasets of moderate dimensionality. In case of a high dimensional dataset, we observed overlap between regions, which offsets the benefits of the proposed structure. Clearly, the region overlaps observed in a high dimensional dataset needs to be addressed in the future work. More complex objects also need to be considered in order to further validate the benefits of using the proposed graph structure. References Böhm, C., Berchtold, S., and Keim, D. A. (2001). Searching in high-dimensional spaces: Index structures for improving the performance of multimedia databases. ACM Comput. Surv., 33(3): C. Traina, J., Traina, A., Faloutsos, C., and Seeger, B. (2002). Fast indexing and visualization of metric data sets using slim-trees. Caetano Traina, J., Traina, A. J. M., Seeger, B., and Faloutsos, C. (2000). Slimtrees: High performance metric trees minimizing overlap between nodes. In Proc. of the 7th International Conference on Extending Database Technology EDBT00, pages 51 65, London, UK. Springer-Verlag. 151

152 Chávez, E., Navarro, G., Baeza-Yates, R., and Marroquín, J. L. (2001). Searching in metric spaces. ACM Press. Ciaccia, P., Patella, M., and Zezula, P. (1997). M-tree: An efficient access method for similarity search in metric spaces. In The VLDB Journal, pages Clarkson, K. L. (2006). Nearest-neighbor searching and metric space dimensions. In Shakhnarovich, G., Darrell, T., and Indyk, P., editors, Nearest-Neighbor Methods for Learning and Vision: Theory and Practice, pages MIT Press. Hacid, H. and Yoshida, T. (2007). Incremental neighborhood graphs construction for multidimensional databases indexing. In Advances in Artificial Intelligence, pages Hjaltason, G. R. and Samet, H. (2003). Index-driven similarity search in metric spaces. ACM Trans. Database Syst., 28(4): Jaromczyk, J. and Toussaint, G. (1992a). Relative neighborhood graphs and their relatives. P-IEEE, 80: Jaromczyk, J. and Toussaint, G. (1992b). Relative neighborhood graphs and their relatives. Proceedings of IEEE, 80: Marcos R. Viera, Caetano Traina Fr., F. J. T. C. and Traina, A. J. (2004). DBMtree: A dynamic metric access method sensitive to local density data. Brazilian Symposium on Databases. Marcos R. Viera, Caetano Traina Fr., F. J. T. C. and Traina, A. J. (2004). DBMtree: A dynamic metric access method sensitive to local density data. Brazilian Symposium on Databases. Navarro, G. (2002). Searching in metric spaces by spatial approximation. The VLDB Journal, 11(1): Paolo Ciaccia, M. P. and Zezula, P. (1997). M-tree: An efficient access method for similarity search in metric spaces. In Proceedings of International Conference on Very Large Data Bases (VLDB). Supowit, K. J. (1983). The relative neighborhood graph, with an application to minimum spanning trees. J. ACM, 30(3): Toussaint, G. T. (1980). The relative neighborhood graph of a finite planar set. Pattern Recognition, 12: Zezula, P., Amato, G., Dohnal, V., and Batko, M. (2006). Similarity Search - The Metric Space Approach. Springer. 152

153 Smart Cleaning tools: Una plataforma para detección y corrección de datos sucios. Maryluz Martinez R. 1, Gelver Vargas Barona 1, John Gomez C. 2, 1 Fundación Parque Tecnologico del Software. Parquesoft 2. Universidad del Valle. Cali Colombia mmartinez@parquesoft.com, gvargas@parquesoft.com, jhgomez@univalle.edu.co Resumen. Con el advenimiento de tecnologías de generación masiva de datos y el significativo avance en técnicas y herramientas para realizar análisis de información y obtener conocimiento importante a partir de ella; se ha acrecentado también la necesidad de tener datos limpios y confiables sobre los cuales basar tales análisis. Las posibles soluciones a esta problemática se están abordando a través del uso de herramientas comerciales dirigidas a tal fin y con la generación de técnicas y algoritmos inteligentes publicados por diferentes investigadores. Este documento presenta una solución completa e innovadora para esta necesidad, representada en la implementación de una plataforma dirigida exclusivamente a la automatización del proceso de limpieza de datos; esta integra los procesos de detección y corrección de 3 tipos de datos sucios: datos fuera de rango, datos faltantes y registros duplicados haciendo uso de técnicas estadísticas y de minería de datos para lograrlo. 1 INTRODUCCIÓN La calidad de los datos en el mundo real depende de varios factores distintos, siendo crucial la manera en cómo estos son capturados. La captura de los datos inherentemente conlleva errores algunas veces simples y otras veces más complejos. Inclusive una organización que tome medidas extremas para evitar estas fallas de captura, tiene una taza de error de alrededor del 5% o más [1]. En un estudio de PriceWaterhouseCoopers en 2004 a una muestra de CIOs (Chief Information Officer), Directores de TI (Information Technology) y ejecutivos equivalentes en 600 compañías en Estados Unidos, Australia y el Reino Unido, el 75% de los encuestados reportó grandes problemas como resultado de datos defectuosos [2]. En este sentido, Gartner, Inc. sostiene que "Hacia el año 2005, las empresas de la lista FORTUNE 1000 perdieron más dinero por ineficacia operativa, debido a los problemas de calidad de datos, del que podrían gastar en datawarehouses y proyectos CRM (Customer Relationship Management)"; en el caso de las bodegas de datos o datawarehouses, las fuentes de datos constituyen el punto crítico; en el ambiente académico diferentes campos de investigación como la bioinformatica y el descubrimiento de 153

154 conocimiento en bases de datos: KDD (Knowledge discovery databases), necesitan de datos limpios y confiables para generar resultados exitosos. La limpieza de datos es más que el simple hecho de actualizar registros por otros buenos ; involucra procesos de descomposición y re-ensamblaje de datos; generalmente, primero es necesario explorar el conjunto de datos para detectar los errores y luego corregirlos. Existen diferentes tipos de errores que pueden presentarse en un conjunto de datos dado, entre los que están: datos fuera de rango, datos inexistentes, registros duplicados, errores en la integridad del conjunto de datos como tal, errores léxicos e inconsistencias entre columnas dependientes; el proceso de detectarlos y corregirlos es computacionalmente costoso por lo que regularmente se lleva a cabo de forma manual, haciendo uso de herramientas disponibles que asisten el proceso basadas en rutinas SQL o dirigidas a solucionar un solo tipo de problema; cuando el experto desea usar técnicas avanzadas como las de minería de datos se ve obligado a hacer uso de herramientas de minería que a pesar de contar con los algoritmos necesarios no están dirigidas al proceso de limpieza de datos como tal, por lo que su adaptación es complicada. El propósito de este documento es presentar una plataforma de limpieza de datos sucios que hace uso de técnicas estadísticas y de minería de datos para asistir y automatizar los procesos de: detección de outliers de tipo cualitativo o cuantitativo; un outlier o dato fuera de rango en un conjunto de datos es un elemento significativamente diferente a los otros datos de la colección, o inconsistente con los demás datos de la misma variable. [3] Detección de datos faltantes: campos en los cuales no se ingreso información. Detección de registros duplicados; Corrección de estos tipos de errores en grandes conjuntos de datos sin importar la lógica de negocio que estos representan. La descripción completa de la propuesta se encuentra en la sección 3 de este documento; en la sección 4 se presentan los detalles técnicos de la implementación de la propuesta incluyendo arquitectura, pruebas y resultados obtenidos; en la sección 5 se hace un recuento de las conclusiones obtenidas y finalmente en la sección 6 se muestra el trabajo futuro propuesto. Antes en la sección 2 se hace referencia a antecedentes y trabajos previos tendientes a solucionar la misma problemática abordada en este artículo. 2 TRABAJOS PREVIOS Actualmente se pueden hallar soluciones que detectan ciertos tipos de errores en los datos y ayudan a corregirlos, en la mayor parte de los casos estas soluciones van dirigidas a corregir datos de un temario específico como listas de o clientes, y los errores detectados son principalmente registros duplicados y formatos inconsistentes en nombres y direcciones ó errores de inconsistencia que surgen a partir de la integración de diferentes fuentes; existen también herramientas que buscan reglas o patrones de comportamiento en los datos para luego generar una lista de posibles datos sucios a partir de aquellos registros que no cumplen con las reglas halladas; sin embargo ninguna integra en una sola plataforma los procesos de detección y corrección de datos faltantes, datos fuera de rango y registros duplicados a través de técnicas estadísticas y de minería de datos. 154

155 Se presentan entonces a continuación herramientas de limpieza de datos que se encuentran disponibles en el mercado y publicaciones de interés para el desarrollo de la propuesta realizadas en el área de data cleaning (Limpieza de datos). 2.1 Herramientas comerciales: Data Quality: Innovative system Inc. es la compañía Comercializadora de Data Quality, una herramienta que funciona como componente de una plataforma más grande llamada i/lytics que además de procesar los datos de nombre y domicilio en listas de clientes, puede analizar, corregir, y reformatear números telefónicos, usuario de correo electrónico y relaciones cliente/cuenta; distingue registros organizacionales de registros individuales y estandariza elementos tales como títulos, conjunciones y tipos de calle para que sean consistentes a través de la base de datos. [4] PowerCenter de Informática. La herramienta de limpieza de esta compañía valida y corrige datos de nombre y dirección de la base de datos de clientes. Permite a los usuarios convertir los datos a distintos formatos y estructuras para que las empresas puedan estandarizar su información y mejorar la precisión de las tareas de integración de datos [5] AJAX: Es una plataforma cuyo objetivo principal es facilitar la especificación y ejecución de rutinas de limpieza y transformación de datos. Propone un framework donde la lógica de las rutinas de limpieza de datos es modelada a través de un grafo dirigido de transformaciones sobre los datos que inicia en la fuente de datos. Provee también un lenguaje declarativo para la especificación de rutinas de limpieza de datos, el cual consiste en sentencias SQL enriquecidas con un conjunto de primitivas para expresar estas transformaciones y cuenta con una interfaz grafica que le permite al usuario interactuar con la ejecución de una rutina de limpieza de datos para manejo de casos especiales e inspección de resultados intermedios. [6] Enterprise/Integrator: De Apertus Technologies, esta herramienta permite transformar, limpiar, mezclar y sincronizar datos de diferentes fuentes; maneja un enfoque en el que el usuario propone las reglas para limpiar los datos [7] Integrity Data Reengineering: Esta herramienta de la compañía Vality technology analiza los datos carácter por carácter y automáticamente emergen los modelos y las reglas del negocio. Toma en cuenta las relaciones comerciales que no son obvias a partir de los datos, tales como fusiones y adquisiciones que han tenido lugar desde que fueron creados los datos. [8] Trillium Software System: De Harte Hanks, este es un producto que sirve para limpiar direcciones y nombres reformateando, estandarizando y verificando datos de este tipo. Consiste de 4 componentes: Un convertidor, un analizador, un tercer componente denominado geocoder y un matcher. [9] WizRule. Creado por WizSoft, es un generador de reglas que busca a través de cada registro en una tabla y determina las reglas que están asociadas a él. El usuario puede determinar que campos son examinados. La herramienta identifica registros que se desvían de reglas establecidas. Soporta archivos ASCII y cualquier base de datos compatible con ODBC. [10] 155

156 2.2 Publicaciones: Utilizando reglas de asociación para identificación de errores en los datos: El artículo analiza la utilización de reglas de asociación para la identificación automática de errores en conjuntos de datos. [11] Eliminating fuzzy duplicates in warehouses: Se propone un algoritmo llamado Delphi para la eliminación de registros duplicados en tablas multidimensionales como las de un datawarehouse, las cuales regularmente están asociadas con jerarquías. [12] Algoritmos eficientes para la detección de datos fuera de rango en grandes conjuntos de datos: Se propone una nueva formulación para la detección de datos fuera de rango basada en la distancia de un punto a su k-esimo vecino más cercano. Se desarrollo un algoritmo altamente eficiente basado en particiones para encontrar datos fuera de rango. [13] FP-Outlier: Frequent Pattern Based Outlier Detection: En este artículo se propone un método para detectar datos fuera de rango basado en el descubrimiento de patrones frecuentes en los datos. [16] Computing LTS Regression for Large Data Sets: El grupo investigador propone un método para detectar datos fuera de rango basado en una técnica estadística denominada estimación robusta enfocada en el método LTS (Least Trimmed Square) el cual hace un ajuste de un modelo lineal usando minimos cuadrados sobre un subconjunto h del total de la población. [15] 3 PROPUESTA La propuesta sustentada a través de este documento consiste en presentar a la comunidad científica una plataforma dirigida exclusivamente a apoyar el proceso de limpieza de datos sucios haciendo uso de técnicas estadísticas y de minería de datos para integrar los procesos de detección de datos fuera de rango, detección de datos faltantes, detección de registros duplicados y la corrección de los errores hallados. La plataforma no provee mecanismos para detectar o corregir errores provocados por inconsistencias de integridad en la base de datos ni errores de formato como los producidos por integración de diferentes fuentes. Específicamente la plataforma de limpieza provee las siguientes funcionalidades: 1. Detección de datos fuera de rango en un conjunto de datos, a través de 3 técnicas: detección robusta de outliers, reglas de asociación y clustering. 2. Detección de datos faltantes en un conjunto de datos a través de sentencias SQL. 3. Detección de registros duplicados en un conjunto de datos utilizando algoritmos de clustering. 4. Corrección de datos fuera de rango y datos faltantes a través de la generación de patrones de comportamiento con reglas de asociación. 5. Eliminación de registros duplicados. La plataforma provee una interfaz de usuario que le permite a este interactuar con todos los módulos creados, de modo que pueda decidir con cuál técnica de las ofrecidas desea realizar la 156

157 detección de registros duplicados, de datos fuera de rango o de datos faltantes y si desea que los errores encontrados sean corregidos. El usuario de la herramienta participará de manera activa en la selección de la mejor forma de limpiar sus datos sin que esto implique que deba llevar a cabo el proceso de forma manual. Por sus características la plataforma permite obtener resultados comparativos entre diferentes técnicas para detectar o corregir el mismo tipo de dato sucio, buscando que investigadores de las áreas de gestión de conocimiento y data cleaning puedan realizar diversos análisis y mejoren la propuesta a través de la inclusión de nuevas técnicas en la plataforma o de la comparación de técnicas ya incluidas con otras propuestas. Si bien existen herramientas de limpieza como las mencionadas en la sección 2 vale la pena resaltar que ninguna cumple con las características de la plataforma presentada. 3.1 Algoritmos propuestos para detección de outliers: Para la detección de datos outliers se implementaron 3 algoritmos descritos a continuación: Detección de robusta de outliers: Se implementó un algoritmo de regresión basado en estimadores robustos. La idea principal de este algoritmo es hallar un modelo que se ajuste a los datos de tal manera que no lo afecte la presencia de datos fuera de rango. Un modelo simple como el de los mínimos cuadrados falla en presencia de estos datos. Mientras que, un modelo basado en estimadores robustos mantiene su tendencia. Se utilizó el algoritmo de Rousseeuw y Driessen llamado FAST-LTS [15]. El FAST-LTS calcula el modelo de regresión basado en un subconjunto de datos de tamaño h=(n+p+1)/2, donde n es la cantidad total de datos y p es la cantidad de atributos de los datos. En este sentido, el objetivo principal del algoritmo consiste en encontrar los h elementos que mejor representan la población. Mediante un proceso iterativo se selecciona aleatoriamente un subconjunto de tamaño p, al cual se le calcula el estimador de regresión por mínimos cuadrados, luego, con este estimador se calculan los residuos de todos los datos y se seleccionan los h elementos que tengan los menores residuos. Lo siguiente es aplicar dos pasos de concentración paso-c para obtener un estimador más preciso del subconjunto h. Los pasos anteriores se repiten t veces (t es controlado por el usuario), de las cuales se seleccionan los mejores 10 estimadores y con ellos se forma el subconjunto h final, del cual se calcula el estimador solución. Para el caso de datos univariados (p=1) se aplica el algoritmo LTS exacto propuesto en [20]. Detección de outlier con reglas de asociación: Se implemento un algoritmo basado en la generación de conjuntos de ítems frecuentes propuesta por Agrawal et al en el algoritmo Apriori usado para hallar de reglas de asociación [16]. En el algoritmo implementado forma primero se generan los conjuntos de ítem frecuentes y después se calcula una medida llamada FPOF (Frequent Pattern Outlier Factor) la cual indica que porcentaje de patrones frecuentes involucra una determinada transacción, si esta medida es menor que un límite definido por el usuario se califica la transacción como outlier. Se utilizo el algoritmo FindFPOF propuesto por Zengyou et al [14]. Detección de outlier con clustering. Las técnicas de clustering apuntan a agrupar instancias de acuerdo a su similitud, medida comúnmente con la distancia Euclidiana. K-means es una técnica simple de clustering que, mediante un algoritmo iterativo, encuentra el punto central de cada clúster el cual se conoce como centroide. Cada instancia se asigna al centroide más cercano, y cada colección de instancias asignadas a un centroide es un clúster. En este sentido, se consideran outliers a las 157

158 instancias más lejanas a un centroide dentro de un mismo clúster. La implementación de este algoritmo se basa en ORC (Outlier Removal Clustering) [17]. Las entradas requeridas al usuario son el valor de corte, y el número de iteraciones deseadas y la forma de determinar que instancias son lejanas, es utilizar la distancia máxima centroide-instancia dmax en cada cluster como indicador de lejanía. Luego, utilizando un valor de corte t (que va desde 0 hasta 1), se marcan las instancias que tengan una distancia mayor a t veces dmax. Por ejemplo, si dmax = 0,8 y t = 0,99, entonces se marcarían como outliers las instancias que tengan una distancia centroide-instancia mayor que 0,792. El proceso anterior se realiza iterativamente, las veces que el usuario considere necesarias. En cada iteración, el algoritmo encuentra por lo menos un outlier. 3.2 Algoritmo propuesto para detección de registros duplicados: Se propone un algoritmo que llamamos DUPLA, el cual se basa en el algoritmo de clustering DBSCAN [18] con algunas modificaciones en el cálculo de la distancia entre instancias. DBSCAN es un algoritmo basado en densidad el cual localiza regiones densas separadas de otras por regiones de baja densidad en el espacio Euclidiano. La densidad de una instancia c se determina con la cantidad de instancias que están dentro de un radio con centro en c. Si la instancia c posee por lo menos mpts instancias vecinas, c se convierte en un punto central. y mpts son parámetros de entrada del algoritmo. Adicionalmente, las instancias vecinas de c pueden ser vecinos de otros puntos centrales, los cuales se les conoce como puntos de frontera. Si una instancia no es punto central ni de frontera, entonces se considera como ruido. Sin embargo, la métrica que usa DBSCAN para determinar la cercanía se basa en distancias euclidianas, las cuales no soportan la variedad de tipo de datos (ordinal, nominal, real e intervalo) presentes en las bases de datos. En este sentido, la métrica utilizada por DUPLA es una combinación de las métricas adecuadas para cada tipo de datos. El parámetro de entrada del algoritmo propuesto es la similitud mínima esperada entre las instancias. Este valor debe estar en el intervalo [0,1]. Donde, los valores cercanos a uno indican un alto grado de similitud. 3.3 Técnica usada para detectar datos faltantes: En esta versión de la plataforma para detectar datos faltantes, es decir campos vacios en la base de datos se hace uso de una rutina de SQL que los extrae. 3.4 Algoritmos para corrección de errores hallados: Al momento se tiene implementada una técnica para la corrección de datos sucios hallados; cabe anotar sin embargo que el equipo investigador se encuentra actualmente trabajando en la implementación de dos más. Corrección usando reglas de asociación: Se implemento un algoritmo de imputación de datos erróneos (Faltantes o fuera de rango) basado en la generación de reglas de asociación. El algoritmo se basa en el hecho de que una regla de asociación es una implicación de la forma AB donde A y B son conjuntos de atributos denominados antecedente y consecuente respectivamente, que se generan basados en dos medidas: soporte y confianza. Se tiene un dato erróneo e que pertenece al dominio B, y se tiene una regla ab donde a pertenece al dominio A y b pertenece al dominio B entonces podemos reemplazar a e por b con un confianza igual al grado de confianza de la regla. 158

159 4 IMPLEMENTACION DE LA PROPUESTA La implementación de la propuesta descrita en la sección anterior se realizo atendiendo prácticas de ingeniería de software para la construcción de aplicaciones de escritorio, haciendo uso de UML como lenguaje de modelación [19] y de Java como lenguaje de programación. 4.1 Arquitectura de la solución La arquitectura de la plataforma fue diseñada siguiendo como directriz, el permitir la inclusión de nuevas técnicas de detección y/o de corrección de los tipos de datos sucios que hasta ahora contempla. La figura 1 contiene la vista de la arquitectura que soporta la implementación de la plataforma de limpieza de datos sucios. La interfaz gráfica de usuario esta creada con la librería swing de java; el acceso al conjunto de datos a limpiar se hace a través de un componente denominado Data source y la capa lógica se encuentra organizada en 5 paquetes y un kernel que los gestiona; Fig. 1. Arquitectura de la plataforma de limpieza de datos sucios Algoritnm: Se hallan todos los algoritmos implementados. Outliers: Se hallan las clases necesarias para ejecutar el proceso de detección de un outlier. Duplicates: Se hallan las clases necesarias para ejecutar el proceso de detección de registros duplicados. 159

160 Missing: Se hallan las clases necesarias para ejecutar el proceso de detección de datos faltantes. Repair: Se hallan las clases necesarias para ejecutar el proceso de corrección de los errores hallados. 4.4 Experimentos y resultados: Para realizar el piloto de la herramienta se instalaron todos sus componentes en un servidor de pruebas configurado para dar soporte a java Versión 6 y al motor de base de datos MySql Versión 5. Las pruebas de detección y corrección de datos sucios fueron ejecutadas sobre una base de datos llamada pruebas compuesta por 2 tablas. Una denominada Wdbc que contiene datos de diagnósticos de cáncer y que cuenta con 31 columnas: 30 con datos numéricos o cualitativos ordinales y 1 columna de tipo cualitativo y 490 registros [21]; la segunda denominada empleos recoge el detalle de las características de todos los empleos de una población de 3863 jóvenes encuestados en España, dicha tabla tiene 34 columnas 24 de ellas de tipo cualitativo y 10 de tipo cuantitativo [22]. Primero fueron probadas las técnicas de detección de outliers, para hacerlo el conjunto de datos inicial fue ensuciado de forma controlada seleccionando una columna al azar (de tipo cualitativo para la técnica de detección con reglas de asociación y de tipo cuantitativo para la técnica de detección robusta) y se reemplazaron datos consistentes por datos fuera de rango; una vez hecho este proceso se corrieron las rutinas de detección para verificar si los datos fuera de rango ingresados de forma intencional eran hallados por cada una de las técnicas mencionadas. En una segunda etapa se probo la técnica de detección de registros duplicados siguiendo la metodología anterior, es decir, al conjunto de datos inicial se agregaron clones de registros existentes; se procedió luego a correr la rutina de detección para verificar cuantos de esto clones eran detectados. Los datos hallados en la etapa 1 sirvieron como base para probar la técnica de corrección con reglas de asociación. Con el ensuciamiento controlado de los datos, el equipo de prueba conoce de antemano el dato correcto que la técnica debía arrojar. En la tabla 1 se encuentran los resultados obtenidos Tabla 1. Resultados obtenidos en pruebas Tecnica Base de datos Datos sucios % ingresados Datos sucios % detectados Falsos o Datos Sucios corregidos detectados Detección de Outliers LTS wdbc % 10% ORC wdbc % 25% FPOF empleos % 25% Detección de Duplicados DBSCAN wdbc % 5% Reemplazo de Datos Sucios Reglas de Asociación empleos 50 92% 160

161 5 CONCLUSIONES Las tareas de limpieza de datos sucios, comúnmente llevadas a cabo de forma manual, a través de técnicas muy simples o forzando plataformas de minería de datos existentes para que se ajusten a los requerimientos de este proceso, pueden ser ahora realizadas de forma sencilla y rápida con el uso de la plataforma propuesta en este documento. Para quienes realizan labores de mantenimiento en datos esta herramienta puede convertirse en un aliado esencial. Gracias a la inclusión de varias técnicas de detección para el mismo tipo de dato sucio, es posible obtener marcaciones diferentes del dato a corregir, lo que permite ejecutar las labores de detección y corrección de forma acertada. Como resultado colateral en este proyecto, el grupo investigador amplio su conocimiento a través de la búsqueda de técnicas y algoritmos adecuados para su implementación en cada modulo. 6 TRABAJO FUTURO Actualmente el grupo investigador se encuentra trabajando en la implementación de 2 técnicas más para el modulo de corrección de errores, para tener un total de 3 técnicas para corrección implementadas para septiembre de Estas 2 técnicas adicionales consisten en predecir el valor aproximado del outlier o del dato faltante haciendo uso de un algoritmo de clasificación y de un algoritmo de predicción que utilice regresión lineal. Se propone como trabajo futuro además de la inclusión de estas 2 nuevas técnicas, sacar provecho de la flexibilidad de la arquitectura implementada para el enriquecimiento de ambos módulos (detección y corrección) con otras técnicas que permitan detectar y corregir los tipos de datos sucios que al momento maneja la plataforma. Como trabajo futuro, el grupo sugiere también extender los tipos de datos sucios que la herramienta contempla, incluyendo por ejemplo la detección de errores lexicográficos y la detección de inconsistencias en reglas de negocio que indican dependencia entre columnas. Por último para el grupo investigador es prioritario trabajar en la implementación de una interfaz web para el acceso a la plataforma de limpieza de datos sucios. 161

162 REFERENCIAS 1. Orr K. Data Quality and Systems Theory, CACM, vol. 41, no. 2, pp (1998). 2. Oski Goldfryd. La base del negocio está en la calidad de los datos, Innovative System Informatica AJAX, 7. Apertus 8. Vality, 9. Trillium Software, Wizsoft, Andrian Marcus, Jonathan I. Maletic. Utilizing Association Rules for the Identification of Errors in Data. 12. Rohit Ananthakrishna, Surajit Chaudhuri, Venkatesh Ganti. Eliminating Fuzzy Duplicates in Data Warehouses, Sridhar Ramaswamy, Rajeev Rastogi, Kyuseok Shim. Efficienth algorithms for mining outliers from large data sets, laboratorios bell, 14. Zengyou He, Xiaofei Xu, Joshua Zhexue Huang, Shengchun Deng; FP-Outlier: Frequent Pattern Based Outlier Detection; ComSIS Vol.2, No.1, (Junio 2005). 15. Peter J. Rousseuw, Katrien Van Driessen; Computing LTS Regression for Large Data Sets, Springer Link (2006) 16. R. Agrawal, R. Srikant. Fast Algorithms for Mining Association Rules. In: Proc of VLDB 94, pp , (1994). 17. Ville Hautamäki, Svetlana Cherednichenko, Ismo Kärkkäinen, Tomi Kinnunen, and Pasi Fränti; Improving K- Means by Outlier Removal; H. Kalviainen et al. (Eds.): SCIA 2005, LNCS 3540, pp , (2005). 18. Ester, M., Kriegel, H.P., Sander, J., Xu, X.: A density-based algorithm for discovering clusters in large spatial databases with noise. In: 2nd International Conference on Knowledge Discovery and Data Mining. (1996) Craig Larman UMl y patrones, introducción al análisis y diseño orientado a objetos. Prentice Hall (1999). 20. Rousseeuw, P.J. and Leroy. Robust Regression and Outlier Detection, A.M. (1987). 21. Instituto Valenciano de investigaciones económicas Wisconsin Diagnostic Breast Cancer 162

163 Deformaciones Interactivas en GPU Alvaro Cuno, Claudio Esperança 1 Universidad Federal de Rio de Janeiro - PESC/COPPE (a) (b) (c) Figura 1: Comparación de resultados. (a) Modelo inicial y puntos de control. (b) Modelo deformado en CPU. (c) Modelo deformado con la implementación en GPU. Resumen Este trabajo muestra como usufructuar la potencia del hardware gráfico moderno en la deformación de modelos de superficie 3D. Se muestra como deformaciones calculadas vía optimización por mínimos cuadrados móviles posibilitan implementaciones altamente paralelizables. Fueron realizados varios experimentos que comparan la eficiencia de implementaciones realizadas en CPU y GPU, para los cuales fueron usados modelos digitales de objetos reales y masas de datos generadas aleatoriamente. Los tiempos de deformación sugieren que el desempeño de una implementación en GPU puede ser 100 veces superior al desempeño de una implementación tradicional. 1. Introducción Uno de los principales factores que explica la necesidad de procesamiento paralelo es la búsqueda por mayor desempeño. Las diversas áreas de aplicación (geología, ingeniería, medicina, biología, economía, etc.) requieren cada vez mayor poder computacional debido, principalmente, al tamaño creciente de la masa de datos a ser procesada. Además, muchas aplicaciones son inherentemente paralelas, sin embargo, se pierde desempeño debido al uso habitual de paradigmas de programación secuencial. Estos paradigmas, bien establecidos y ampliamente usados, no aprovechan la potencia y capacidad del hardware moderno que esta presente, inclusive, en computadoras de escritorio (PCs). A pesar que las arquitecturas paralelas fueron introducidas hace décadas, su precio aún las restringe a ser usadas solamente por universidades y grandes compañías. Recientemente, arquitecturas paralelas de bajo costo se están transformando en alternativas atractivas ya que, además de ofrecer un alto poder computacional, pueden ser adquiridas por un público mas amplio. Por ejemplo, entre las alternativas con mayor popularidad están: las GPUs (Graphics Processing Units), las CPUs de múltiplos núcleos de processamento (multi-core CPUs) y CELL (STI Cell Broadband Engine). Varias propuestas, vea por ejemplo (Owens et al., 2008), han 163

164 demostrado que el uso adecuado de estas tecnologías permite incrementar el desempeño de algoritmos en mas de un orden de grandeza. Este hecho, origina la necesidad de organizar el procesamiento computacional, mapeando, cuando fuese posible, algoritmos secuenciales en versiones paralelas de los mismos. Tradicionalmente, técnicas de mínimos cuadrados (Least Squares) son utilizadas para resolver problemas de optimización. Sin embargo, casi siempre, requieren la construcción de sistemas lineales de grandes dimensiones como ocurre con las técnicas de deformación basadas en optimización global (Botsch and Sorkine, 2008). Además, la necesidad de usar bibliotecas de álgebra lineal para resolver los sistemas dificulta implementaciones en plataformas múltiples o en hardware no convencional, por ejemplo GPUs. Por otro lado, técnicas de optimización basadas en mínimos cuadrados móviles (Moving Least Squares - MLS) calculan una solución diferente para cada punto del dominio y, en general, la solución en un punto no depende de sus vecinos. Por lo tanto, cada solución puede ser calculada independientemente de las otras. Eso origina que las técnicas MLS (Levin, 1998) sean excelentes candidatas a ser implementadas dentro de un paradigma de procesamiento paralelo. Recientemente, (Schaefer et al., 2006) et al. introdujeron una técnica de deformación de imágenes 2D. La propuesta consistía en encontrar una transformación óptima para cada elemento de la imagen usando optimización vía MLS. En contraste con otras técnicas, en esta propuesta, no se requiere triangular las imágenes, no es necesario especificar esqueletos y el uso de bibliotecas externas es totalmente evitado. Además, ofrece resultados atractivos y es simple de implementar. Una extensión para el caso 3D fue propuesta en (Cuno et al., 2007), que introduce una formulación cerrada para calcular, de forma eficiente, la componente rígida de la solución. En este trabajo se muestra como aprovechar el poder de cómputo de las GPUs para efectuar deformaciones interactivas usando el algoritmo propuesto en (Cuno et al., 2007). Son efectuadas tres alternativas de implementación en GPU y son realizados una serie de experimentos que demuestran un desempeño superior (mas de 35 veces en el peor caso) cuando comparadas con una implementación tradicional. Además, se verifica que la precisión de las deformaciones es semejante, habiendo apenas un error absoluto de aproximadamente 1.0e-8 entre los resultados de las diferentes implementaciones. 2. Deformación vía Mínimos Cuadrados Móviles Definición del problema. Sea x = [x y z] una posición en R 3 y {p i } un conjunto de posiciones en el espacio. Después de definir nuevas posiciones {q i }, el problema consiste en encontrar la transformación rígida T, que minimice w i T x (p i ) q i 2, i donde w i es una función de peso definida como w i (x) = p i x 2 y denota la norma Euclidiana. Puede ser demostrado que una solución MLS óptima es dada por T x (x) = R(x p*) + q*, donde R es una rotación en 3D y i p* = w i p i i i w, q* = w i q i i i w. (1) i 164

165 Adicionalmente, puede ser demostrado que, la rotación óptima a ser aplicada sobre un vector v es dada por 2((u v) u (u v)) R(v) = v, (2) 1 + u 2 donde u es un vector de rotación dado por la solución del sistema lineal: (M + M T λi) u T = V T, (3) que define M como la matriz M = i w iˆq T i ˆp i, (4) V = i w iˆp i ˆq i, ˆq i = q i q* y ˆp i = p i p*. Finalmente, λ = r + E, donde r es la mayor raíz real de la ecuación de cuarto grado y 4 2 M 2 y 2 8 det(m) y E 4 +2 M 2 E 2 8 det(m)e+det(n)(2e VN 1 V T ) = 0. (5) El operador denota la norma de Frobenius y E = trace(m) Algoritmo Una sesión de deformación recibe como entrada un modelo de superficie 3D representado por una malla de triángulos de n vértices, y los conjuntos {p i } y {q i } los cuales denotan las posiciones iniciales y deformadas de los puntos de control (Control Points - CP). La deformación del modelo ocurre cuando el usuario modifica la posición de los elementos de {q i }. La interfaz de la aplicación ofrece un mecanismo para que el usuario los arrastre usando un mouse 2D. Simultaneo al arrastre, la superficie del modelo se deforma de manera suave y controlada. Para la construcción del modelo deformado M d, a partir del modelo inicial M o, la aplicación invoca el siguiente algoritmo n veces. Algoritmo 1: Calcular la posición deformada de un vértice Input: v: posición del vértice, {p i }: posiciones iniciales de los puntos de control, {q i }: nuevas posiciones de los puntos de control Output: v : posición deformada del vértice p WeightedCentroid(v, {p i }); q WeightedCentroid(v, {q i }); M CorrelationMatrix(v, {p i }, {q i }, p, q ); λ MaximumRootOfP(M) + Trace(M) ; u RotationVector(M, λ); v q + Rotate(v p, u); return v ; // autovalor En el Algoritmo 1, la rutina WeightedCentroid calcula los centros ponderados p e q relativos al vértice procesado, utilizando la Ecuación (1). La rutina CorrelationMatrix implementa la Ecuación (4) para calcular la matriz de correlación M y, de la misma forma que 165

166 la rutina anterior, depende del número de puntos de control k. La rutina MaximumRootOfP calcula la mayor raíz real de la Ecuación de cuarto grado (5). En seguida, la rutina Rotation- Vector es responsable por calcular el vector de rotación u resolviendo el sistema 3 3 de la Equación (3). Finalmente, la posición deformada v del vértice v es calculada por la rutina Rotate, la cual es definida por la Ecuación (2). 3. Unidad de Procesamiento Gráfico - GPU La potencia, el bajo costo y la alta flexibilidad de las GPUs modernas, las convierte en una alternativa potencial para resolver problemas que efectúan un elevado volumen de operaciones aritméticas. Una GPU es un procesador de múltiples núcleos que puede ser usado como un coprocesador, ya que tiene su propio espacio de memoria y ejecuta paralelamente un gran número de threads. Típicamente, el desarrollo de aplicaciones es realizado por medio de la codificación de shaders 1 usando APIs gráficas (OpenGL o DirectX). Los shaders pueden actuar en tres partes del pipeline gráfico 2 : en el procesamiento de vértices, de geometría o de fragmentos. Dependiendo del lugar de actuación son llamados: shaders de vértices, shaders de geometría o shaders de fragmentos. La memoria de la placa gráfica, también llamada de memoria de textura, se puede acceder con cualquiera de los tres shaders. Sin embargo, el acceso está restringido a solamente operaciones de lectura o escritura e incurre en una latencia mayor que el acceso a la memoria RAM efectuado por la CPU. Esto sucede porque la arquitectura de la placa gráfica fue diseñada para maximizar el desempeño en la realización de cálculos aritméticos en detrimento del acceso eficiente a memoria (Pharr and Fernando, 2005). Por este motivo, las aplicaciones necesitan maximizar su intensidad aritmética 3 con la finalidad de maximizar el desempeño de las GPUs. A pesar que varios lenguajes de programación de alto nivel hayan sido desarrollados (Cg, HLSL, GLSL, etc.), la adaptación de un problema arbitrario a un contexto gráfico no permite una adopción masiva de esta tecnología. Las primeras propuestas que buscaban desvincular la programación de GPUs de definiciones usadas en computación gráfica fueron: BrookGPU (Buck et al., 2004), Sh (McCool et al., 2004) y Accelerator (Tarditi et al., 2006). Recientemente, otras propuestas que permiten menor experiencia en computación gráfica y que procuran el desarrollo de software comercial han aparecido: RapidMind (McCool and D Amora, 2006), PeakStream (Papakipos, 2007), además de CTM y CUDA de las compañias AMD y NVIDIA, respectivamente. A fines del 2006, la empresa NVIDIA introdujo CUDA (NVIDIA Corporation, 2007) (Compute Unified Device Architecture), la cual es una tecnología para programación en GPU que ofrece una plataforma que hace uso eficiente de los recursos de la placa gráfica y permite implementaciones independientes del pipeline gráfico. En CUDA las implementaciones son efectuadas a través de la codificación de kernels 4, los cuales son ejecutados por múltiples threads. Las threads son agrupadas en bloques, donde comparten los multiprocesadores de la GPU. Cada multiprocesador posee una arquitectura SIMD (Single Instruction Multiple Data) que ejecuta las mismas instrucciones del kernel, aunque en datos diferentes. 1 Shader se refiere a programa de computador en el contexto de programación en placa gráfica usando GLSL. 2 Para mayores detalles sobre el pipeline gráfico consulte el manual de OpenGL (Shreiner et al., 2005). 3 Intensidad Aritmética es la razón: número de operaciones aritméticas / número de accesos a memoria. 4 Kernel se refiere a programa de computador en el contexto de programación en placa gráfica usando CUDA. 166

167 4. Deformaciones MLS en CPU La implementación tradicional (single-core) en CPU es trivial, en el sentido que requiere, simplemente, la codificación de las rutinas del Algoritmo 1. Fue efectuada en C++ y no se requirió el uso de bibliotecas externas. Las figuras 2 y 3 muestran tiempos de deformación obtenidos con esta implementación. Otra alternativa sugiere el uso de la capacidad multi-core de los procesadores modernos. Para la implementación en múltiples núcleos fue utilizada la biblioteca Pthreads (Lawrence Livermore National Laboratory, 1995), debido a su conocida popularidad. La implementación es semejante a la versión en CPU. Sin embargo, la división del trabajo es explícitamente establecida para ser efectuada por dos threads cada una procesando la mitad de los vértices. Tal configuración fue escogida después de efectuar experimentos con un número variable de threads. El menor tiempo de procesamiento obtenido con dos threads frente al obtenido usando un mayor número de las mismas puede ser atribuido a que el procesador donde los experimentos fueron ejecutados posee dos núcleos. Los valores de las frecuencias de renderización 5 (Frames per Second - FPS) mostrados en la Figura 2 sugieren una ganancia en desempeño de 100 % frente a la implementación single-core. 5. Deformaciones MLS en GPU Para demostrar la adaptabilidad de la deformación MLS en el modelo de programación en GPU fueron efectuadas tres implementaciones, las cuales son descritas a continuación Implementación en el procesador de vértices. La implementación fue efectuada usando el lenguaje GLSL (OpenGL Shading Language) y la biblioteca OpenGL. La estrategia consiste en hacer que la geometría del modelo, enviada para la memoria de la placa gráfica, sea modificada antes de ser renderizada. De esa forma, después de especificadas las posiciones de los puntos de control ({p i }, {q i }) y la geometría del modelo, el shader de deformación K vs calcula, en cada frame, una transformación óptima para cada vértice y modifica su posición. El shader K vs es invocado, de forma transparente por la API gráfica, y procesa los vértices del modelo en forma paralela. Observe que, a pesar de ser posible, ninguna pre-computación fue realizada. Esto se debe a que la naturaleza del hardware hace que operaciones de lectura de la memoria de la GPU sean mas costosas que el cálculo repetitivo de operaciones aritméticas. Es importante destacar que la implementación en el procesador de vértices no necesita de operaciones explícitas de transferencia de datos entre la memoria principal del sistema y la memoria de la placa gráfica. Esa operación es efectuada de forma transparente por la API gráfica Implementación en el procesador de fragmentos Otro enfoque puede ser adoptado para la implementación del algoritmo de deformación. La estrategia consiste en usar la GPU como un coprocesador de propósito general. En este 5 La palabra renderización es un extranjerismo derivado del verbo en ingles render, que significa dibujar. 167

168 # de CP CPU MC VS/FS CUDA Figura 2: Comparación de los FPS de la implementación tradicional (CPU) del Algoritmo 1, frente a implementaciones multi-core (MC), procesador de fragmentos (FS), procesador de vértices (VS) y CUDA. El modelo deformado consta de 115,154 vértices. La deformación usó un número variable de puntos de control (# de CP). caso, la implementación busca explotar la generación y el procesamiento paralelo de fragmentos realizado por la API gráfica. Además, la memoria de textura es usada explícitamente como repositorio para la entrada y salida de datos. De esa forma, cada vértice es asociado a un fragmento y cada fragmento es procesado por el shader K fs, que calcula una transformación óptima conforme el Algoritmo 1. La codificación de K fs es similar al código de K vs con la diferencia que el shader de fragmentos lee las posiciones de los vértices de la memoria de textura y escribe la posición deformada en otra textura que, posteriormente, es transferida para la memoria principal del sistema. A pesar que existe el requerimiento de transferencia explícita de vértices entre la memoria RAM y la memoria de la placa gráfica, fueron obtenidos desempeños similares con los de la implementación en el procesador de vértices y superiores cuando comparados con la implementación secuencial en CPU (observe la Figura 2). En placas NVidia modernas (a partir de la serie 8) los recursos usados por el procesador de vértices y por el procesador de fragmentos son los mismos. Eso no sucedía en hardware antiguo, donde los recursos de los procesadores de fragmentos eran mas potentes y la cantidad de procesadores de vértices era menor a la cantidad de procesadores de fragmentos Implementación usando CUDA La implementación en CUDA se reduce a codificar un único kernel que implementa el algoritmo de deformación MLS. En la fase de inicialización son establecidos dos parámetros de entrada, los cuales son enviados para la GPU a través de texturas 2D y 1D, respectivamente: las posiciones iniciales de los vértices y las posiciones de los puntos de control. Después de especificadas las posiciones modificadas de los puntos de control, el kernel es invocado para calcular las posiciones deformadas de los vértices. Varios experimentos fueron realizados para determinar el tamaño ideal para los bloques y la grid de cómputo. Bloques de y una grid de n/8 n/8 1 resultaron en una configuración óptima. En la Figura 2 se puede observar que, a pesar que el mismo hardware este siendo usado, el desempeño de la implementación en CUDA es superior a las implementaciones en los shaders. En el mejor caso, la implementación en CUDA es dos veces superior. Sin embargo, si mas puntos de control son utilizados (lo que implica un mayor número de operaciones aritméticas) el desempeño converge para los tiempos utilizados por los shaders. 168

169 PC CPU MC FS CUDA (a) 512x512 vértices PC CPU MC FS CUDA (c) 2048x2048 vértices PC CPU MC FS CUDA (b) 1024x1024 vértices PC CPU MC FS CUDA (d) 4096x4096 vértices Cuadro 1: Tiempos gastados (en segundos) por diferentes implementaciones del Algoritmo 1. Cada cuadro representa un experimento de deformación donde fue establecida una cantidad fija de vértices y un número variable de puntos de control (CP), ambos generados aleatoriamente. Los acrónimos CPU, MC, FS, CUDA se refieren a las implementaciones serial en CPU, múltiples núcleos en CPU, procesador de fragmentos y CUDA. 6. Experimentos y Resultados Fueron realizados tres grupos de experimentos diseñados para: (1) verificar la correcta funcionalidad, (2) analizar el desempeño y (3) medir la precisión de las diferentes implementaciones del Algoritmo 1. Para la ejecución de los experimentos fue usado un computador personal equipado con: un procesador Pentium-IV dual-core de 2.4 GHz, 1GB de memoria RAM, una placa gráfica GeForce 8800GTS y sistema operativo Linux-Fedora 6.0. Fue utilizada la representación punto flotante de simple precisión para realizar todas las operaciones aritméticas. El primer grupo de experimentos permitió verificar visualmente la correcta implementación de las diferentes alternativas. Para lo cual, un modelo compuesto de 115,154 vértices fue deformado (con cada una de las implementaciones) usando 8 puntos de control. En seguida, fue realizado el mismo experimento pero modificando el número de puntos de controle para 16, 32, 64, 96, 128 y 160. Se observó que todas las implementaciones generaban deformaciones visualmente semejantes, por lo tanto, fueron calificadas como correctas. Además, fue contabilizado los FPS de las implementaciones, los cuales están graficados en la Figura 2. Los valores de la tabla permiten verificar la alta interactividad presentada por las implementaciones en GPU. Se puede observar que, en el peor caso, el desempeño es 20 (procesador de vértices) y 37 (CUDA) veces superior al de la implementación secuencial en CPU. Observe, también, que cuanto mas puntos de control mayor la diferencia. Esto se debe a que un mayor número de puntos de control implica mas operaciones aritméticas, lo que a su vez implica mayor intensidad aritmética. Para efectuar un análisis de desempeño mas riguroso, fue medido el tiempo usado por cada 169

170 (a) 512x512 vértices (b) 1024x1024 vértices (c) 2048x2048 vértices (d) 4096x4096 vértices Figura 3: Gráficos correspondientes a los valores del Cuadro 1. implementación en la deformación de una masa de datos de tamaño variable. Es importante mencionar que en este grupo de experimentos, a diferencia del anterior, la deformación es realizada una única vez y no es producida ninguna salida visual. Observe que en el anterior caso se midieron FPS, lo que es diferente a la medida (en segundos) usada para este grupo de experimentos. Fueron utilizados vértices y puntos de control generados por un procedimiento aleatorio, que fue restringido a generar puntos dentro del cubo unitario. Para el primer grupo de experimentos fue generado vértices y 2 i puntos de control, donde i = El Cuadro 1(a) muestra los tiempos de procesamiento usados en la deformación de estos datos. De forma similar, fueron realizados experimentos con , y vértices. El Cuadro 1 muestra los tiempos correspondientes y la Figura 3 muestra los gráficos de estas mediciones. Es posible observar que la implementación en GPU usando CUDA, en el mejor de los casos, es 110 veces más rápida que una implementación tradicional. De la misma forma, la implementación en el procesador de fragmentos muestra una desempeño 74 veces superior. Para analizar la precisión numérica de las diferentes implementaciones fueron seleccionados cuatro modelos de geometría diferente (primera columna de las figuras 1 y 4). A través de una interfaz de usuario (GUI) fueron seleccionados algunos puntos de control posicionados sobre la superficie de los modelos. Después de especificar sus posiciones deformadas, fueron aplicadas las diferentes implementaciones del algoritmo de deformación. Se coleccionaron todos los modelos deformados y se midió las diferencias entre: los resultados en CPU frente a los resultados en el FS, los resultados en CPU frente a los resultados en CUDA y los resultados en CUDA frente a los resultados en el FS. La Tabla 2 muestra la lista de los mayores valores 170

171 Modelos Vértices Implementaciones Error Absoluto Error Relativo CPU-FS e e-08 Dino CPU-CUDA e e-08 CUDA-FS e e-08 CPU-FS e e-08 Dragon CPU-CUDA e e-08 CUDA-FS e e-08 CPU-FS e e-08 Girl 9912 CPU-CUDA e e-08 CUDA-FS e e-08 CPU-FS e e-08 Horse CPU-CUDA e e-08 CUDA-FS e e-08 Cuadro 2: Precisión de las implementaciones. Cada modelo fue deformado por tres implementaciones (CPU, CUDA y FS), en seguida, fue medida la diferencia entre los resultados. La columna Error Absoluto denota la mayor diferencia entre vértices correspondientes de dos modelos deformados. Por otro lado, el Error Relativo se refiere a la razón entre el error absoluto y el tamaño de la diagonal del cubo envolvente de los modelos. obtenidos, donde el error absoluto se refiere a la mayor distancia entre todos los vértices y sus correspondientes. A pesar que no existe diferencia visual entre los modelos deformados (ver Figura 4), es posible notar una pequeña diferencia numérica entre sus coordenadas. Se observa que el mayor error absoluto no es mas que 1e-07 y que el mayor error relativo está alrededor de 1e-08. Estas diferencias pueden ser atribuidas al hecho que las operaciones aritméticas no son necesariamente aplicadas en el mismo orden y a que las GPUs no implementan fielmente el estándar de aritmética de punto flotante IEEE 754 (NVIDIA Corporation, 2007). 7. Conclusiones Fue demostrado que el algoritmo de deformación usando MLS es altamente paralelizable. Una implementación simple usando threads permite duplicar el desempeño de una implementación secuencial. Sin embargo, los experimentos muestran que la implementación en hardware gráfico puede ser 100 veces mas eficiente que implementaciones tradicionales del algoritmo. Visualmente, los resultados obtenidos por las diferentes implementaciones son semejantes, a pesar de existir una diferencia numérica mínima. References Botsch, M. and Sorkine, O. (2008). On linear variational surface deformation methods. IEEE Transactions on Visualization and Computer Graphics, 14(1): Buck, I., Foley, T., Horn, D., Sugerman, J., Fatahalian, K., Houston, M., and Hanrahan, P. (2004). Brook for gpus: stream computing on graphics hardware. ACM Trans. Graph., 23(3): Cuno, A., Esperança, C., Oliveira, A., and Cavalcanti, P. R. (2007). 3D as-rigid-as-possible deformations using MLS. In Proceedings of the 27th Computer Graphics International Conference, pages , Petropolis, RJ, Brazil. 171

172 VII Jornada Peruana de Computación (a) (b) (c) Figura 4: Ejemplos de deformacio n. (a) Modelos iniciales y puntos de control. (b) Deformacio n calculada por la implementacio n en CPU. (c) Deformacio n calculada usando CUDA. Lawrence Livermore National Laboratory (1995). POSIX Threads Programming. https: //computing.llnl.gov/tutorials/pthreads/. Levin, D. (1998). The approximation power of moving least-squares. Math. Comput., 67(224): McCool, M., Toit, S. D., Popa, T., Chan, B., and Moule, K. (2004). Shader algebra. ACM Trans. Graph., 23(3): McCool, M. D. and D Amora, B. (2006). Programming using rapidmind on the cell be. In Proceedings of the ACM/IEEE conference on Supercomputing, page 222, NY, USA. ACM. NVIDIA Corporation (2007). CUDA Environment - Compute Unified Device Architecture. Owens, J. D., Houston, M., Luebke, D., Green, S., Stone, J. E., and Phillips, J. C. (2008). Gpu computing. Proceedings of the IEEE, 96(5): Papakipos, M. (2007). The peakstream platform: High-productivity software development for gpus. In Proceedings of LCI Conference on High-Performance Clustered Computing. Pharr, M. and Fernando, R. (2005). GPUGems 2: Programming Techniques for HighPerformance Graphics and General-Purpose Computation. Addison-Wesley, USA. Schaefer, S., McPhail, T., and Warren, J. (2006). Image deformation using moving least squares. ACM Trans. Graph., 25(3): Shreiner, D., Woo, M., Neider, J., and Davis, T. (2005). OpenGL Programming Guide: The Official Guide to Learning OpenGL, Version 2.0. Addison-Wesley Professional, MA, USA. Tarditi, D., Puri, S., and Oglesby, J. (2006). Accelerator: using data parallelism to program gpus for general-purpose uses. In XII ASPLOS, pages , New York, NY, USA. ACM. 172

173 Juego Humano-Máquina Minichess Daniel Carranza 1, Cristian Peñarrieta 1, Natalia Valdivia 1, David Mauricio 1, 2 1 Facultad de Ingeniería Universidad Peruana de Ciencias Aplicadas u310281@upc.edu.pe, u410585@upc.edu.pe, u310508@upc.edu.pe 2 FISI Universidad Nacional Mayor de San Marcos dms_research@yahoo.com Resumen En el presente trabajo se desarrolla una variante del juego Ajedrez, que denominamos MiniChess. Para el desarrollo del juego inteligente se usó la técnica de búsqueda en un espacio de estado y se implementó un algoritmo humano máquina con tres niveles de dificultad: principiante, normal y experto; para las cuales se usó respectivamente las siguientes estrategias: no determinístico, primero el mejor y mejor diferencia de utilidades. Además, se muestran las pruebas numéricas, que confirman la inteligencia del sistema de acuerdo al nivel de dificultad. 1. Introducción El verdadero origen del juego del Ajedrez no se conoce exactamente, ya que existen varias leyendas. Según [3], una de ellas dice que fue el Rey Salomón quien lo inventó, otras dicen que fue el Dios Griego Hermes y otras dicen que fue el Mandarin Chino Hansing. También dice que lo más probable es que se haya originado en la India alrededor del siglo 6 o 7 A.C. A partir de ahí, el juego se expandió a Persia (ahora Irán) y después a Europa. Además, se cree que el nombre del Ajedrez se deriva de la palabra Persa "Shah" que significa "Rey" y la palabra "Jaque Mate" del "shah mat", que quiere decir "el Rey está muerto." MiniChess A partir del Ajedrez convencional se pensó en hacer un juego parecido. El problema consiste en un tablero de ajedrez de 5 x 8 como se muestra en la figura 1. A diferencia del ajedrez convencional en este juego solo se utilizarán para cada jugador: 5 peones, un rey, dos torres y dos caballos. Figura 1: Tablero de Minichess 173

174 A continuación se describe los movimientos que posee cada ficha. Peón.- Se puede mover una casilla de las siguientes formas: hacia delante, en diagonal. Sólo en el primer movimiento de cada peón, podrá moverse hacia delante dos casillas. Además, puede capturar una pieza adversaria que se encuentre en una de las dos casillas situadas en diagonal delante de él, es decir, en las dos columnas adyacentes en dirección al adversario. Caballo.- Es la única pieza que puede saltar; es decir, que puede ir de la casilla de inicio a la de destino sin que se lo pueda impedir ninguna pieza interpuesta, ni del contrario ni propia, la condición es que el casillero destino debe estar vacía ó tiene una ficha del adversario, en este caso esta será capturada. El caballo se desplaza como una 'L': adelanta dos casillas horizontales o verticales, y luego una casilla perpendicularmente a las anteriores. Figura 2: Movimiento del Caballo y Peón Torre.- La torre se puede mover horizontal o verticalmente solo hasta tres casillas. No puede saltar por encima de ninguna otra pieza, ni propia ni contraria. Rey.- El rey se puede mover a cualquiera de las ocho casillas que rodean la casilla en que se encuentra. Figura 3: Movimiento de la Rey y Torre 174

175 2. Problema de Búsqueda Un Problema de búsqueda es definido como un problema de búsqueda en un espacio de estado cuando se definen por lo menos las siguientes características: estado, estado inicial, estado meta y las reglas. A seguir se define el MiniChess como un problema de búsqueda en un espacio de estado Objetos Los Objetos considerados en este juego son el tablero, las fichas y el turno. El tablero es representada por una matriz M de dimensión 5x8. Las fichas torre negra, caballo negro, peón negro, rey negro, torre blanca, caballo blanco, peón blanco, rey blanco son denotadas respectivamente por TN, CN, PN, RN, TB, CB, PB, RB. Los turnos T son denotados por N, B donde: N = Negras y B = Blancas Estado El estado para este problema es dado por la ubicación de las fichas en el tablero y el turno en un momento dado; y es representado por: (M, T), en donde M {PN, CN, PN, RN, TB, CB, PB, RB, φ} 5x8, y T {B, N} Estado Inicial Es dado por el tablero con las fichas ordenas de acuerdo a los mostrado en la figura 4. En el se muestra a las fichas negras en las filas correspondientes a las filas 0 y 1, a las fichas blancas en las fichas 6 y 7, y los demás casilleros se encuentras vacíos. Figura 4: Estado Inicial 2.4. Estado Final En consideración que pueden existir un número grande de posibles estados metas, definiremos una condición necesaria y suficiente para un estado meta. Cuando el rey está en jaque y en cualquier movimiento que haga el rey continúa en jaque Reglas MoverP(C, X I, Y I, X F, Y F ). - Mueve un peón desde la posición (X I, Y I ) hasta (X F, Y F ). El peón puede moverse en el eje de las X solo una casilla hacia la izquierda o derecha o no moverse. En el caso del eje Y se debe mover solo 175

176 una casilla hacia delante pero podrá avanzar dos casillas en caso sea el primer movimiento del peón. La posición final no puede estar fuera del tablero. MoverT(C, X I, Y I, X F, Y F ). - Mueve una torre desde la posición (X I, Y I ) hasta (X F, Y F ). La torre puede moverte vertical u horizontalmente como un máximo de 3 casillas. La posición final no puede estar fuera del tablero. MoverC(C, X I, Y I, X F, Y F ). - Mueve un caballo desde la posición (X I, Y I ) hasta (X F, Y F ). El caballo solo tiene puede moverse en L, es decir, 2 casilla en cualquier dirección y luego 1 casilla perpendicularmente. La posición final no puede estar fuera del tablero. MoverR(C, X I, Y I, X F, Y F ). - Mueve un rey desde la posición (X I, Y I ) hasta (X F, Y F ). El rey solo puede moverse una casilla en cualquier dirección. La posición final no puede estar fuera del tablero. Coronar(C, X I, Y I, X F, Y F, F).- Mueve un peón de color C de posición (X I, Y I ) hasta (X F, Y F ) y lo cambia por una ficha F. Cuando el peón llega a la última casilla, entonces puede obtener una ficha de su elección. En la siguiente tabla se muestran el conjunto de reglas con sus respectivas condiciones y estados finales. En todos los casos, el estado final corresponde al cambio de turno y al cambio de la ficha en la posición final por el de la ficha en la posición inicial. Estado Regla Condición Nuevo Estado Actual M, T MoverP(C, X I, Y I, X F, Y F ) T = C X I -1<= X F <= X I +1 1<= X F <=5 Si C=N 3<= Y F <=8 Y F = Y I +1 Si Y I =2 Y I +1<=Y F <= Y I +2 Si Y I - Y F =2 X I = X F Si C=B 1<= Y F <=6 Y F = Y I -1 Si Y I =7 Y I +1<=Y F <= Y I +2 Si Y F - Y I =2 X I = X F T=!C M(X F, Y F ) = M(X I, Y I ) M(X I, Y I ) = φ 176

177 M, T MoverT(C, X I, Y I, X F, Y F ) M, T MoverC(C, X I, Y I, X F, Y F ) M, T MoverR(C, X I, Y I, X F, Y F ) M, T Coronar(C, X I, Y I, X F, Y F, F) T=C 1<= Y F <=8 1<= X F <=5 Si X I = X F Y F -Y I <=3 Desde (i= Y I, Y F - 1) M(X I, Y I +1) = φ Si Y I = Y F X F -X I <=3 Desde (i= X I, X F - 1) M(X I +1, Y I ) = φ 1<= Y F <=8 1<= X F <=5 1 <= X F - X I <= 2 Si X F - X I = 2 Y F - Y I = 1 Si X F - X I = 1 Y F - Y I = 2 Y F - Y I!= X F - X I 1<= Y F <=8 1<= X F <=5 X I -1<=X F <= X I +1 Y I -1<=Y F <= Y I +1 Si X F = Y F X I!=Y I Si X I =Y I X F!= Y F M(X I, Y I ) = PC 1<= X F <=5 X I -1<=X F <= X I +1 Si C=B entonces Y I =2 Y F =1 Si C=N entonces Y I =7 Y F =8 T=!C M(X F, Y F ) = M(X I, Y I ) M(X I, Y I ) = φ T=!C M(X F, Y F ) = M(X I, Y I ) M(X I, Y I ) = φ T=!C M(X F, Y F ) = M(X I, Y I ) M(X I, Y I ) = φ T=!C M(X F, Y F ) = M(X I, Y I ) M(X I, Y I ) = φ Tabla 1: Reglas para el MiniChess. Por razones de espacio explicaremos solo la regla MoverR (Mover Rey). Las condiciones para MoverR son cinco. Primero, se verifica que la posición (X F, Y F ) a la cual se desea mover el rey se encuentre dentro del rango del tablero de 5x8. Segundo, se verifica que la variable X F se encuentre una posición a la izquierda de la variable X I o una posición a la derecha de la variable X I. Tercero, se verifica que la variable Y F se encuentre una posición arriba de la variable Y I o una posición debajo de la variable Y I. Cuarto, se verifica que las posiciones 177

178 finales sean desiguales a las posiciones iníciales. Por último, se verifica si es que en la posición a la que se desea mover exista una ficha del color contrario. El estado resultante de la regla MoverR se describe a continuación. El nuevo turno será ahora el turno opuesto al turno actual. El valor de la matriz de la nueva posición será igual al valor de la matriz de la posición actual y el valor de la matriz en la posición actual quedara como vacio. 3. Algoritmo Humano-Maquina El algoritmo que se utilizara pretende determinar una secuencia de estados (reglas) que inicie en un estado inicial (e 1 ) y termine en un estado final (F). Infelizmente, el tamaño del espacio de estados para este problema de inteligencia artificial es inconmensurable. Por esta razón no es posible utilizar algoritmos de camino mínimo para resolver este problema. La alternativa es determinar el camino de e 1 a F sin conocer todo el grafo para ello utilizaremos los llamados métodos de búsqueda. Según [4], los métodos de búsqueda se dividen en dos categorías, métodos de búsqueda ciega y métodos de búsqueda con información. Los métodos de búsqueda ciega son aquellos que no tienen en cuenta el coste de la solución en la búsqueda. Los métodos de búsqueda con información son aquellos que utilizan una estimación del coste de la solución para guiar la búsqueda. Ambas categorías incluyen distintos tipos de métodos. A continuación presentamos las dos categorías de métodos e búsqueda con sus respectivos métodos. Figura 5: Clasificación de los Métodos de búsqueda. En el presente trabajo utilizaremos el método ciego (no determinístico) y los métodos con información (Primero el mejor y Diferencia de utilidades). Cada tipo de método corresponde a una estrategia de selección, las cuales corresponden a los niveles de dificultad del juego. 178

179 A continuación presentamos el algoritmo Humano-Maquina en el siguiente flujo grama: I ei Test ei = em? Si Gana Humano o Gana Maquina o Empate F No Turno = Humano? Si Juega Humano, se genera estado e No Juega Maquina, se genera estado e ei e Figura 5: Flujo grama del algoritmo Humano-Maquina El algoritmo comienza en un estado inicial descrito anteriormente en el cual se configura el nivel del juego (principiante, intermedio o experto), el color a utilizar por el humano y se inicializan los objetos (Tablero, Fichas y turno). Luego se verifica si el estado del juego se encuentra en el estado meta, si es igual al estado meta, se define quien ganó la partida y termina el juego, de lo contrario se verifica si el humano le toca jugar. Si es turno del humano, se espera la jugada y cuando la realiza se genera el nuevo estado, de lo contrario, se genera el estado para la máquina siguiendo el flujo mostrado en la Figura

180 Figura 6: Flujo grama de la generación de estados para la maquina Para el desarrollo del algoritmo humano-máquina del juego Minichess, se han considerado tres estrategias de selección de la jugada para la máquina, las cuales corresponden a los niveles de dificultad del juego. En la siguiente tabla se muestra las estrategias y niveles del juego Minichess. Nótese que cada estrategia corresponde a un método se búsqueda. Nivel Estrategia Descripción Principiante No determinística La máquina revisa las posibles jugadas y selecciona una al azar. Normal Experto Primero el mejor (Glotón) Mejor diferencia de utilidades La máquina revisa todas las posibles jugadas y, de acuerdo a la función evaluadora, se elige la que tenga mayor valor. La máquina revisa las posibles jugadas de la máquina y las evalúa con la función evaluadora. Luego, evalúa las posibles jugadas del humano con la función evaluadora. Finalmente, la máquina selecciona la jugada que presenta mayor diferencia de utilidades; es decir, elige la mayor resta de la jugada de la máquina menos la mejor jugada del humano. Tabla 2: Estrategias de juego para el MiniChess. Para este fin se han considerado diversos criterios que hacen posible que la máquina pueda realizar las jugadas. Entre los criterios tomados en cuenta por el algoritmo se encuentran: La distancia al rey oponente, el valor de las fichas, el valor de las posiciones defendidas por las fichas propias, el valor de la fichas atacas según el movimiento, entre otras. Además, se definieron pesos a dichos criterios, es por esa razón que en la función 180

181 evaluadora algunas variables tiene un factor. Estos criterios han sido plasmados en la siguiente función evaluadora: Donde: F = -20D + C1 + C2 - PC1 + PC2 + 10PA + J D: Distancia de la ficha al rey oponente. C1: Valor que indica si la ficha puede comer una ficha oponente sin que puedan comerlo en la siguiente jugada. Se define de la siguiente manera: Si come y no está en peligro: C1 = 4*(valor de la ficha + Dif) Si come y está en peligro: C1 = 2*(valor de la ficha + Dif) Dif: Valor Ficha a comer Valor Ficha de la jugada C2: Valor que indica si la ficha puede ser comida en la jugada. Se define de la siguiente manera: Si lo comen: C2 = -4* Valor Ficha de la jugada Si no lo comen: C2 = Valor Ficha de la judaga PC1: Suma del valor de las ficha que podrían ser comidas por el oponente. PC2: Suma del valor de las fichas a comer. PA: Valor que indica el número de puntos donde las fichas pueden atacar J: Valor que indica si la ficha realizará Jaque. Se define de la siguiente manera: Si es Jaque y M>1: J = *M Si es Jaque y M<1: J = Si es Jaque Mate: J = M: número de movimientos que el rey oponente puede realizar. Los valores asignados para cada ficha son los siguientes: Vacío = 0 Peón = 200 Caballo = 500 Torre = 1000 Rey = Implementación El juego Minichess se implementó usando el lenguaje C# en plataforma.net, usando la programación orientada a objetos. La pantalla principal de la primera versión de Minichess cuenta con el tablero de juego y dos secciones donde se muestran las fichas que el humano y la máquina van comiendo del oponente (vea la Figura 7). Además, la pantalla cuenta con un menú con el cual se puede iniciar un nuevo juego y elegir el nivel de dificultad del mismo (Ver Figura 4.2). Asimismo, se ha considerado que el jugador humano juegue con las fichas blancas y, por consiguiente, comience el juego. 181

182 Submenú para iniciar un nuevo juego Submenú para elegir el nivel del juego Submenú para llamar a la pantalla de instrucciones 5. Pruebas Figura 7: Pantalla principal de Minichess y menú El software desarrollado fue sometido a prueba con 10 personas mayores de 18 años para cada uno de los niveles de dificultad. Las personas que colaboraron con nosotros para el desarrollo de las pruebas son alumnos de la Universidad Peruana de Ciencias Aplicadas (UPC) y, cabe resaltar, no son profesionales ni expertos en el ajedrez pero tienen algún conocimiento del juego tradicional. La elección de las personas a utilizar fue al azar teniendo como único condicional el conocimiento de las reglas del ajedrez convencional. Antes de iniciar una partida del juego a cada una de las 10 personas se le explicó detalladamente las reglas y modificaciones que tiene el MiniChess con respecto al ajedrez tradicional y se le otorgó una partida de prueba para poder adaptarse al cambio de las reglas. Luego de la partida de prueba, se empezó jugando el nivel principiante. De ganar, jugaba el nivel intermedio y de ganar el nivel intermedio jugaba el nivel experto. De perder en algún nivel no se asumirá como pérdida en los niveles sucesivos y se continuará jugando en los siguientes niveles sea cual fuere el resultado. Los resultados para la máquina se describen a continuación: Nivel Partidas Ganadas Partidas Empatadas Partidas Perdidas Principiante Intermedio Experto Tabla 3: Resultados de las Pruebas. Según los resultados de la tabla podemos concluir que se confirmó que el nivel de dificultad del juego varía de acuerdo al algoritmo utilizado para encontrar la jugada por parte de la máquina. Conforme el algoritmo es más complejo, el grado de dificultad del juego es mayor. 182

183 6. Conclusiones Hasta el momento no existen partidas perdidas por la máquina en el nivel experto. La máquina presenta mayor ventaja en el nivel experto, ya que al utilizar el algoritmo de mejor diferencia de utilidades, la máquina es capaz de prever dos jugadas adelantadas (Máquina y humano). Si se usara un nivel más en la diferencia de utilidades, es decir, dos niveles, el nivel de dificultad sería mucho mayor. Para que el algoritmo de primero el mejor y diferencia de utilidades, es muy importante tener una función evaluadora bien definida ya que depende de dicha función. Se confirmó que el nivel de dificultad del juego varía de acuerdo al algoritmo utilizado para encontrar la jugada por parte de la máquina. Conforme el algoritmo es más complejo, el grado de dificultad del juego es mayor. 7. Bibliografía [1] Nils J. Nilsson. Inteligencia artificial, una nueva síntesis. McGraw Hill. (2001) [2] John B. Ahlquist. Game Artificial Intelligence. Delmar Cengage Learning. (2006) [3] [4] Stuart Russel, Peter Norvig. Inteligencia artificial, un enfoque moderno. Prentice Hall. (1996) 183

184 Sieve s Algorithm Modification for Counting Prime Divisors Carlos Eduardo Atencio Torres 1 Joshimar Córdova Monroy 1 1 National University of San Agustin caratos@gmail.com, jcmonroy9@gmail.com Resumen Clever uses and modifications of the Sieve algorithm exist. This paper presents a sieve-based algorithm for finding the number of prime divisors of a given integer p > 1(counted with multiplicity) for 1 p n in O(n lg lg n) time and O(n) space. 1. Introduction Formally, given N = i p k i i the problem we deal with in this paper is to correctly compute bigomega(n) = i k i. For example, if we have n = 24 = then bigomega(n) = 4. One correct and direct approach would be to factorize the given number so we get the exponents in the prime factorization of n, and then simply return their sum. However, if we need to calculate the values of the function over a wide range of integers, this approach is no longer efficient. Since bigomega(n) = bigomega(p) + bigomega(q), with n = p q our algorithm explodes information of integers less than n in order to calculate bigomega(n) together with the sieve approach. The proposed algorithm is presented in section 2 of this paper together with a basic Eratosthenes algorithm. On section 3 we provide a formal proof of the correctness of this algorithm, in section 4 its time complexity is analyzed. Finally on section 5 we present an interesting application of the algorithm for finding the number of prime divisors (counted with multiplicity) of n! 2. The Sieve s Algorithm Modification We start this section presenting the Sieve of Eratosthenes Algorithm which is an algorithm for finding the prime numbers up to n [Graham et al., 1994]. This algorithm has several modifications to increase its speed but basically the algorithm looks like the algorithm 1: We see in algorithm 1 that at the moment of visiting every position in the array, if we meet a zero value, it means that it was not previously visited so we are dealing with a prime number. In this case we mark all the multiples of this prime number as visited, i.e. with

185 Algorithm 1 Sieve of Eratosthenes Algorithm Require: array val of length N for i = 2 to N do if val[i] = 0 then for j = i i TO N BY i do val[j] 1 end for end if end for We can conclude that for each prime number, all of its multiples are marked as no primes. Now one key idea to modify the Sieve of Eratosthenes Algorithm in order to obtain the number of prime divisors is by storing them in each position of the array, so that val[i] contains all the prime divisors of i. This is done by the algorithm 2. Algorithm 2 Sieve s Algorithm Modification Require: val as an array of N sets for i = 2 to N/2 do if val[i] size = 0 then val[i] AddElement( i ) for j = i 2 to N BY i do val[j] AddElement( i ) end for end if end for The Sieve s Algorithm Modification showed in the algorithm 2 gives an alternative solution for the problem of finding the set of distinct prime divisors of n but not for the number of prime divisors of n. Note that the new nested for loop starts in j = i 2 instead of j = i i as in the original Sieve of Eratosthenes algorithm. This is because we don t want to avoid values less than i i. This change also changed the outer for loop that now runs until N/2 and not until N. The answer of the algorithm 2 give us for example the set = {2, 3} for the element 12. However, the answer we are looking for is the sum of the exponents of each element of this set of prime factors. The last modification is based on the equation presented at the beginning of this paper, that is: bigomega(n) = bigomega(p) + bigomega(q), with n = p q If we take p to be a prime number this equation reduces to: bigomega(n) = 1 + bigomega(n/p) As this equation suggests, information about integers less than n is very valuable at the moment of calculating the correct value for n, this makes dynamic programming applicable for solving the problem. The final modification is shown in algorithm

186 Algorithm 3 Our Sieve s Modification Require: val as an array of integers initialized in 0 and length N 1: val[1] 1 2: for i = 2 to N do 3: if val[i] < 1 then 4: val[i] 1 5: for j = i 2 to N BY i do 6: val[j] 1 + val[j/i] 7: end for 8: end if 9: end for 3. Correctness Proof Before we start on proving the correctness of the algorithm previously presented, we need to realize about some key facts. First, notice that the inner for loop executes only if i is a prime number. Second, in the inner for loop, variable j takes the form j = ik with 2 k N i. Unique Factorization Theorem states that a given number N can be represented uniquely as N = p k 1 1 p k , p k i i where the p i are prime numbers. Without any loss of generality, we can assume that p 1 < p 2 <... < p 1 i, and N can be rewritten as N = p 1 p k p k , p k i i. If we use s[n] to represent the number of prime factors of n(counted with multiplicity), then it follows trivially that s[n] = 1 + s[ n p 1 ] and s[n] = 1, if and only if n is a prime number. The last equation is the basis for the algorithm presented in the previous section. The loop invariant for the outer for loop is: For each iteration i of the for loop of lines 2 9, val[k] equals s[k] for 2 k < i At the first iteration of the for loop (i = 2), this invariant is trivially satisfied, since the interval [2, i 1] is empty. Now, assume that the loop invariant is true for 2 k < i, and consider the i th iteration. We have two cases, if i is prime, then we enter the loop, setting val[i] = 1 (which is the correct value of s[i], since i is prime) and the for loop of lines 4 6 loops on index j = ik with 2i j N (notice that j is composite). Then we have 2 k < i or i k N. i In the first case val[k] equals s[k], so that line 5 correctly computes s[j], with j composite; however, if on the contrary, i k N, then val[k] does not equal s[k], but line 5 ensures that i val[j] > 0. On the other hand, if i is composite, then it can be decomposed as i = p q, p < i, q < i, q < p, p prime. Then, as discussed on the previous paragraph, the inner for loop have already computed the correct value of s[i], i.e. val[i] = s[i]. In either case(i prime or composite) we have that at the end of the i th iteration val[i] equals s[i], which restores the invariant for the next iteration. At the end of the loop we have that val[i] = s[i], with 1 i N. 1 Notice that because of the way we visit the primes in the outer for, this assumption makes sense. 186

187 4. Complexity When in line 5: r 0 : j = 2, the number of runs of this loop is (N 2)/2 r 1 : j = 3, the number of runs of this loop is (N 3)/3 r 2 : j = 5, the number of runs of this loop is (N 5)/5 r 3 : j = 7, the number of runs of this loop is (N 7)/7 r 4 : j = 11, the number of runs of this loop is (N 11)/11... The total of runnings of the line 5, will be the sum of runs X 1 r i, that is: Total = (N 2)/2 + (N 3)/3 + (N 5)/5 + (N 7)/7 + (N 11)/ Time According to the Chebyshev Theorem [Shoup, 2005], this serie has π(n) sums. Total Time = N (1/2+1/3+1/5+1/7+1/11+...) by Merten s Theorem [Shoup, 2005], this summation is equal to lg lg n + O(1) - (2/2 + 3/3 + 5/5 + 7/7 + 11/ ) This is the sum of 1 π(n) times Total Time = n lg lg n + O(n) θ(n/ lg n) We want to put an asymptotic order here, so, we guess: Total = n lg lg n + O(n) θ(n/ lg n) = O(n lg lg n) Time c n lg lg n Let us suppose that this relation is not true, so it means: Total Time = n lg lg n + O(n) θ(n/ lg n) > c n lg lg n Applying the definition of ω notation: lím n inf (n lg lg n) + n n/ lg n)/(n lg lg n) should have the value of infinite. But we obtain a constant, so, by contradiction, we have: Total Time = O(n lg lg n) 5. Sum of exponents in prime-power factorization of n! This problem was published by Karen E. Wandel in [Wandel, ]. The purpose is to find the number of prime divisors of n!. For this problem, we might think in obtainning first the exact value of the factorial of n and then, the number of prime factors. 187

188 Using the concept of bigomega and the algorithm previously presented, our approach is to define the problem like: bigomega(n!) = bigomega( n) bigomega(n!) = bigomega(1) + bigomega(2) + bigomega(3) +...bigomega(n) This implies that we only need one for loop at the end of algorithm 3 which accumulates the sum described in the previous equation. As we can see, there is no reason of calculate the factorial of n, saving us a much more problems dealing with the factorial of a big number. 6. Conclusion We have presented an algorithm that runs in O(n lg lg n), which calculates the number of prime divisors(counted with multiplicity) for all integers up to n. We attacked the problem adding dynamic programming in the Sieve s Algorithm, having at the end a useful modification. Referencias VII Jornada Peruana de Computación [Graham et al., 1994] Graham, R. L., Knuth, D. E., and Patashnik, O. (1994). Concrete Mathematics: A Foundation for Computer Science. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. [Shoup, 2005] Shoup, V. (2005). A computational introduction to number theory and algebra. Cambridge University Press, New York, NY, USA. [Wandel, ] Wandel, K. E. Sum of exponents in prime-power factorization of n!. njas/sequences/a

189 Caso de estudio: Desarrollo de aplicaciones empresariales con una arquitectura JEE5, tecnología y herramientas libres Jorge Fabián Chuquitype Zúñiga 1,2 Calos Herrera Muñoz 1,2 Alfoso Victoriano Phocco Diaz 1,2 1 Universidad Nacional de San Agustín De Arequipa 2 Sociedad de Estudiantes en Ciencia de la Computación {jf.chuquitaype, cherrera, vphocco}@episunsa.edu.pe Resumen Actualmente existen diversas tecnologías para el desarrollo de aplicaciones empresariales, de las que destacan claramente.net y Java EE, siendo ésta última la que propugna un desarrollo con software libre, sin embargo la versión mas utilizada es J2EE, cuya dificultad radica en un pesado desarrollo, centrado principalmente en el uso de la especificación EJB2.x para la realización de lógica de negocio y también la persistencia, lo que conllevó al desarrollo de varias herramientas y frameworks que salven las dificultades como Spring, Struts, Hibernate, etc. El presente trabajo muestra el desarrollo de una sistema financiero que utiliza una arquitectura basada en JEE5, nueva versión de Java EE que supera las dificultades de J2EE, y uso de buenas practicas de las herramientas y frameworks existentes, logrando un desarrollo mas limpio y mejor dirigido a la concentración del dominio del problema, inmersos en una metodología, herramientas y frameworks de desarrollo libre. 1. Introducción JEE5 [JEE5,2008] ha sido utilizado para realizar aplicaciones empresariales, tanto Web como Desktop(o de escritorio), utilizando arquitecturas de N capas según sean las necesidades del problema en el entorno del negocio, además de poder usar las especificaciones mencionadas anteriormente cada una especifica para cada capa, como por ejemplo las especificaciones usadas en la capa de presentación son: JSP, Servlets, Struts y JSF(ésta ultima es la mas utilizada y es el patrón MVC, y usa como base JSP y Servlets), para la capa de Negocio se utiliza la especificación de EJB's, para la capa de persistencia se utiliza JPA, pero hay especificaciones utilizadas en varias capas, como JNDI, JTA, incluso las hay las que sirven para integrar e interoperar con otros sistemas tales como JAX (para servicios Web), JCA, etc. Existe además una gran cantidad de frameworks, librerías, API's que trabajan con la especificación JEE total o parcialmente, los frameworks se enfocan en guiar a un desarrollo mas rápido y con las mejores practicas, además que promueve la reutilización de componentes y aplicación a una gran cantidad de problemas, también conlleva a tomar buenas prácticas de desarrollo (análisis, diseño y programación). Las Tecnologías mas renuentes en el mundo de las aplicaciones también son tomadas en cuenta en las especificaciones, frameworks, librerías y demás; por ejemplo existen varios frameworks, plugins(que utilizan algún framework) que permiten el desarrollo de aplicaciones Web de manera rápida como Exalead para Eclipse, y el actualmente conocido Visual Web Pack para Netbeans, también existen los que soportan AJAX, tales como Ajax4jsf, IceFaces, RichFaces, Dojo, JMaki, éste ultimo destaca por ser una reunión de varios frameworks conocidos, tales como GWT, Componentes de YAHOO, Dojo, Scriptaculus, etc. 189

190 Además de frameworks, librerías, API's, existen herramientas que permiten un desarrollo mas rápido y guiado, tales como Netbeans, Eclipse, Java Studio Creator, la Suite de desarrollo de Oracle entre la que se cuenta el JDeveloper y DAF. Incluso están diseminadas un conjunto herramientas y utilidades que agilizan la creación y generación especifica pero rápida de aplicaciones tales como JBoss-Seam[JBossSeam], OpenXava[OpenXava] (catalogada como una herramienta de generación de código activa), entre otros. La famosa herramienta de generación de aplicaciones empresariales denominada GeneXus ya cumple con muchas especificaciones de Java EE, las nuevas funcionalidades incluidas en la última versión de GeneXus llevan la compatibilidad con J2EE [GenexusJEE] a un nuevo nivel. GeneXus Yi, incluye importantes nuevas funcionalidades respecto al soporte para la plataforma J2EE: EJB (Enterprise Java Beans), EAR Deployment Wizard, JTA (Java Transaction API); aunque no se ha anunciado la compatibilidad completa con JEE5 El Modelo de desarrollo de Software también se ve influenciado, es así que ya existe el modelado pensado para el desarrollo de aplicaciones empresariales con arquitecturas de varias capas y estructuras entre las mas principales se encuentra la metodología MDA(Model Driven Architecture) y existe una herramienta generadora de código denominada AndroMDA [Herrera, 2007]. Hemos mencionado las bondades que brinda esta plataforma, sin embargo ya que hace uso del Lenguaje de Programación Java, sus posibilidades se amplían a gran nivel ya que éste lenguaje es catalogado especialmente para desarrollo, así lo demuestran el sin fin de herramientas que existen basadas en él, dando un vistazo a los sistemas de reportes profesionales tenemos a JasperReports, de la que se derivan el IReport, Jasper Assistant, OpenReport, JReports, Dinamyc Jasper, incluso el conocido Crystal Reports tiene versiones compatibles con Java e Integración con aplicaciones JEE. Las aplicaciones a las que nos referimos se dan mas comúnmente como aplicaciones Web, para las diversas aplicaciones que se dan en ésta como el Comercio Electrónico B2B o B2C, sistemas de reservaciones en línea, sistemas de aprendizaje a distancia, Sistemas de entidades financieras como los bancos, etc. En éste trabajo mostramos la experiencia de aplicar una arquitectura basada en JEE5, estándar que supera mucha de las desventajas de J2EE, también mostramos la metodología y herramientas libres de desarrollo aplicadas y propuestas en una aplicación financiera para una cooperativa de ahorro y crédito. El resto de éste paper se divide en las siguiente secciones, en la sección 2 se explican algunas tecnologías de solución, incluida JEE5, en la sección 3, se trata la arquitectura realizada basada en JEE5, la metodología y herramientas de desarrrollo libres utilizadas. 2. Tecnologías de Solución Las empresas cuando empiezan a crecer, también requieren cambiar los sistemas y utilizar Tecnologías de Información que soporten su crecimiento y que les permita innovar y ser competentes. Generalmente se hace uso de aplicaciones Web debido a que ofrece [Colque, 2006]: accesibilidad ubicua, con pocos requerimientos técnicos, datos centralizados y facilidad de integración con otras fuentes, multiplataforma, diversidad en dispositivos clientes, se puede utilizar los servicios en Internet para beneficio de la aplicación, fácil distribución, entre otras. Y las tecnologías más utilizadas en primera instancia para realizar aplicaciones Web son: PHP, 190

191 PERL, Python, y últimamente Ruby [Angel, 2006]. Sin embargo también una plataforma de desarrollo empresarial debe ofrecer una serie de servicios a los arquitectos y desarrolladores para facilitarles el desarrollo de aplicaciones empresariales, al tiempo que ofrece la mayor cantidad posible de funcionalidades a los usuarios. Normalmente una plataforma de desarrollo empresarial tiene los siguientes requisitos [Colque, 2006]: Escalabilidad: Ha de ofrecer una buena escalabilidad tanto horizontal como vertical de modo que si aumenta la carga del sistema podamos añadir servidores o ampliar los existentes sin que sea necesario realizar modificaciones. Mantenibilidad: Ha de permitir añadir modificar los componentes existentes sin que se modifique el comportamiento del sistema. Fiabilidad: Certeza en que el funcionamiento se realiza de manera correcta, con datos y procesamiento íntegros. Disponibilidad: Se debe tener el soporte de arquitecturas tolerantes a fallos, sistemas de redundancia, etc., que nos aseguren que nuestro sistema estará siempre disponible. Extensibilidad: Da la posibilidad de añadir nuevos componentes y capacidades al sistema sin que se vean afectados el resto de componentes. Manejabilidad: Los sistemas han de ser fácilmente manejables y configurables. Seguridad: Hemos de tener buenos sistemas de seguridad tanto a nivel de autenticación, como de autorización y como de transporte. Rendimiento: Se ha de ofrecer automáticamente soporte de clustering, balanceo de carga, pools de objetos, pools de conexiones, cachés, y en general mecanismos que permitan aumentar el rendimiento de manera transparente al usuario. La importancia de una plataforma empresarial es referida a que todos estos componentes son ofrecidos de modo que los desarrolladores son mucho más productivos. La diferencia entre utilizar una plataforma de desarrollo empresarial y no utilizarla radica en que en el segundo caso nuestros desarrolladores perderán mucho tiempo realizando sistemas de bajo nivel, no pudiéndose centrar en el desarrollo de aplicaciones y por consiguiente disminuyendo considerablemente la productividad de los mismos. Por tal motivo, las tecnologías mencionadas inicialmente no satisfacen de la mejor manera las características mencionadas, que generalmente se refieren en la mantenibilidad, extensibilidad y seguridad del software, y esto debido principalmente a que las tecnologías mencionadas están basadas en scripts[piñeiro, 2006] y no soportan un enfoque orientado a objetos integro, a excepción como puede ser Ruby que sin embargo tiene la ventaja de un desarrollo rápido pero con un desempeño de eficiencia menor que las demás[solano, 2007]. PHP y Perl son utilizados en lo que comúnmente se denomina aplicaciones LAMP (Linux, Apache, Mysql y Php o Perl) si nos referimos a utilizar solo software libre. En las aplicaciones que utilizan lenguajes basados en script se caracterizan porque mezclan la lógica de negocio, la presentación y el acceso a datos por lo que dificulta la mantenibilidad y extensibilidad, debido a esto surgieron frameworks y herramientas que ayuden a separar éstas tres componentes, tales como Smarty, Ruby on Rails [Solano,2007], entre los más conocidos. Otra dificultad hallada en aplicaciones Web esta relacionada al grado de interactividad, que es mucho menor comparado con las aplicaciones de escritorio, ante esto existe la tecnología AJAX y diferentes herramientas para auxiliar su uso en las aplicaciones Web. Debido a las desventajas mencionadas de PHP, ASP, Perl, etc, se utiliza Java EE[JEE5, 2008] y.net. Debido a que son tecnologías que cumplen la realización de las características que 191

192 posee una aplicación empresarial, más el añadido de que promueven la utilización de una arquitectura de N-capas y soportan el concepto de sistema distribuido y balanceo de carga. Además que las aplicaciones empresariales, no todas son Web sino que también son aplicaciones de escritorio, como por ejemplo las aplicaciones que necesariamente son utilizadas de manera centralizada como la contabilidad, lo que no nos permitían los lenguajes de script: Además tanto JavaEE y.net nos dan el soporte desde la presentación, lógica de negocios brindado objetos distribuidos y hasta la Persistencia. En el cuadro 2. se muestra una comparación entre aplicaciones utilizando LAMP, ASP y J2EE, del estudio realizado en [ Sillogistic, 2007]. Entre las Tecnologías.Net y JavaEE se han realizado varias comparaciones, en el cuadro 1. se muestran ambas tecnologías y sus principales componentes según varios criterios descritos en [ Angel.2006]. Cuadro 1: Comparación entre.net y Java EE Elegimos Java básicamente por su madurez teniendo muchos ejemplos en su espalda, es decir existe una comunidad de desarrolladores que han probado dicha tecnología con éxito, además por ser portable y gratuito. La tecnología.net podría considerarse una respuesta de Microsoft al creciente mercado de los negocios en entornos Web, como competencia a la plataforma Java de Sun Microsystems, es por ello que se tomo en cuenta para hacer la segunda Comparación, además de ser junto con JavaEE las tecnologías más importantes para el desarrollo de aplicaciones empresariales. 192

193 Area LAMP ASP J2EE Costo de Licencia No Muy caro No Costos y opciones de soporte Vía Comunidad, Soporte con pago también disponible Vía Comunidad, Soporte con pago también disponible Vía Comunidad, Soporte con pago también disponible Plataforma Múltiple Sólo Windows Múltiple Costos de Hardware Servidores económicos Requiere servidores medianamente caros Requiere servidores caros Personal Contratado Hosting Externo Razonablemente fácil encontrar personas calificadas Altamente disponible y económico Muy fácil de encontrar personas calificadas Altamente disponible, pero más caro Seguridad Buena Frecuentemente se requiere más Muy buena Desempeño Muy bueno A menudo requiere hardware más caro para desempeñarse bien Escalabilidad Buena con restricciones Puede ser difícil escalar Administración Configuración: Fácil de usar Difícil: A menudo requiere leer documentación y edición de archivos de texto. Puede ser difícil de configurar apropiadamente Fácil: A menudo puede ser realizado con una interfaz bien intuitiva. Fácil de Configurar Algo difícil encontrar personas calificadas No ampliamente disponible A menudo requiere configuración sustancial y hardware más caro Muy buena, configurada apropiadamente Moderado: A veces realizado visualmente Moderadamente difícil de configurar Configuración: Flexibilidad Extremadamente flexible No muy flexible Moderadamente flexible Frameworks Varios disponibles: a menudo difícil de elegir Un framework estandarizado Un framewrok estandarizado Componentes Altamente disponible Altamente disponible Altamente disponible Compatibilidad Muy buena: Nuevas versiones son compatibles con las anteriores Moderado:Nuevas versiones a menudo quiebran funcionalidad Moderada: con el estandar JEE5 esto va disminuyendo Cuadro 2: Comparación entre LAMP(Linux, Apache, Mysql y PHP-Perl), ASP y Java EE. 3. Propuesta de desarrollo 3.1 Metodología y Herramientas La propuesta de desarrollo esta basada en la Metodología de desarrollo RUP(Rational Unified Process), bajo la cual fue dirigida nuestra experiencia en el desarrollo de software empresarial con tecnología JEE5. Una de las consignas iniciales fue la utilización de herramientas libres durante todo el proceso de desarrollo, así que la primera actividad nuestra fue la evaluación de las herramientas que nos servirían en cada actividad dentro de las fases de RUP. A continuación mostramos la tabla con las herramientas evaluadas y las cuales fueron consideradas para su utilización, ver Cuadro 3: Actividades Gestión de Proyecto Modelamiento del negocio Requerimientos Análisis Herramientas Gantt Project, DotProject OpenOfficeDraw, StarUML REM, StarUML, DBDesigner, QT Designer, Qanta. Diseño StarUML, DBDesigner4, 193

194 Implementación Pruebas Netbeans, Eclipse, VisualWeb, RichFaces, JasperReports, IReport, Glassfish, Subversión PostgresSQL, Notepad++ JUnit, JWebUnit Cuadro 3: Actividades y Herramientas Libres La planificación del proyecto se hizo con GanntProject[GanttProject], Para el modelamiento y el diseño se utilizó StartUML5.0[StartUML] el cual es un proyecto OpenSurce en SourceForge, El IDE para la implementación fue NetBeans debido a la integración que tiene con los frameworks JEE5, la implantación de las intefaces utilizamos RichFaces2.0[RichFaces] una librería de componentes para JSF(Java Server Faces) integrado con capacidades de AJAX. Para la generación de los reportes se utilizo JasperReport1.2.7[JaspeReport] con su herramienta de diseño de reportes IReport1.2.7 El servidor de aplicaciones utilizado fue GlassFishV1 [GlassFich] debido al soporte que tiene para el desarrollo de aplicaciones JEE5. Considerando que las aplicaciones empresariales requieren de mayores capacidades de gestión de almacenamiento se opto por el Sistema Gestor de Base de Datos PostgreSQL8.2. Las pruebas unitarias para la capa de negocio fue hecha con JUnit que viene integrada con NetBeans5.0. El desarrollo de software con calidad requiere del cumplimiento de algunos estándares es por ello que elaboramos una lista de ellos correspondiendo con las actividades RUP, ver cuadro 4: Actividades Gestión de Proyecto Requerimientos Análisis Diseño Implementación Estándares IEEE Std : IEEE Standard for Software Project Management Plans IEEE Std : IEEE Standard for Software Quality Assurance Plans IEEE Std : IEEE Recommended Practice for Software Requirements Specifications IEEE Std : IEEE Standard Glossary of Software Engineering Terminology IEEE Std : IEEE Recommended Practice for Software Design Descriptions. IEEE Std : IEEE Recommended Practice for Architectural Description of Software Systems. IEEE Std : IEEE Standard for Software Verification and Validation 194

195 Pruebas IEEE Std : IEEE Standard for Software Unit Testing Cuadro 4: Actividades y Estándares 3.2 Módulos y arquitectura Nuestra propuesta se centra en una arquitectura multicapa utilizando clientes ligeros dado que se trata de una aplicación web. Logramos separación entre capas con el uso de patrones de programación como por ejemplo el patrón fachada [GOF94] o service locator [MARIN01]; asi mismo por cada capa implementamos patrones como MVC y DTOs, los cuales nos ayudan a tener una mejor estructura por cada capa. Las capas identificadas son: Cliente: Esta capa se encarga de mostrar al cliente la aplicación en si, en nuestro caso la capa cliente esta conformada por el navegador web. Presentación: Como su nombre indica, se limita a la navegabilidad y a gestionar todos aquellos aspectos relacionados con la lógica de presentación de la aplicación, como comprobación de datos de entrada, formatos de salida, internacionalización de la aplicación, etc. Negocio o Domino: El resultado del análisis funcional de la aplicación viene a ser la identificación del conjunto de reglas de negocio que abstraen el problema real a tratar. Estás son las que realmente suponen el motor del sistema, dado que se basan en el funcionamiento del modelo real. En un caso hipotético de un programa de gestión cualquiera, estaríamos hablando, por ejemplo, del conjunto de operaciones que dan el servicio de negocio como emisión de factura. Acceso a datos: Esta capa es la encargada de persistir las entidades que se manejan en negocio, el acceso a los datos almacenados, la actualización, etc, aunque puede ofrecer servicios relacionados con la persistencia o recuperación de información más complejos. Base de Datos: Se encarga de almacenar los datos para una posterior recuperación. En la Figura 1. Podemos observar el diagrama de componentes que conforma un Modulo básico el cual muestra la distribución de capas, mencionaremos también que en la implementación se desarrollo el Módulo Ventanilla con funcionalidad para atención al publico y registro de las transacciones, Módulo Créditos modulo encargado de la gestión de la aprobación y el seguimiento de los créditos, Modulo Plataforma con funcionalidades para atención en informes e inscripción de nuevos socios, Módulo de Contabilidad y Caja que implementa la contabilidad financiera con todos los reportes y gestión de asientos conforme lo requiere la SUNAT(Superintendencia Nacional de Administración Tributaria): 195

196 Figura 1: Diagrama de componentes para un modulo. También en la Cuadro 5 presentamos las tecnologías, estándares y herramientas que utilizamos para implementar esta arquitectura. Capas Cliente Presentación Negocio Acceso a Datos Base de Datos Aplicación HTML, CSS, Paginas JSP, Stanless session POJOS Modelo (Tecnologías) Java Script POJOS, AJAX Beans, POJOS Relacional Plataforma Virtual (Estandares) HTML4.0, Java Script 1.6 JavaEE: JSF1.2, AJAX(Rich Faces) JavaEE: EJB3.0 JavaEE: POJOS JDBC(PropuestaJPA) SQL Plataforma Superior (Herramientas) Firefox 2.0 o superior, I. Explorer 6 o Superior SJSAS9.0 PostgreSQL8.2 Plataforma Operativa (Sistema Operativo Plataforma Hardware Windows XP, Linux(Ubuntu, OpenSuse, etc.) PC Pentiun III o superior 256 MB RAM - Impresoras Linux Ubuntu Server 8.04 Servidor Procesador Intel Xeron Dual 3.2GHz, 2GB RAM Cuadro 5: Tecnologías y Herramientas por capas. Las ventajas de esta arquitectura radican en la mantenibilidad donde es muy fácil identificar y aislar la parte donde se desea realizar el mantenimiento. La escalabilidad que es la capacidad para extender el sistema, puede ser tanto: Horizontal: cuando literalmente clonamos el sistema en otra máquina (u otras máquinas) de características similares y balanceamos la carga de trabajo mediante un dispositivo externo. 196

197 Vertical: Habitualmente, la separación lógica en capas se implementa de tal forma que se permita una separación física de las mismas. Interponiendo elementos conectores que actúen de middlewares (por ejemplo, EJBs), es posible distribuir la aplicación de forma vertical (una máquina por cada capa del sistema), e incluso si esto no fuera suficiente, distribuyendo los elementos de una misma capa entre distintas máquinas servidoras como ocurre cuando utilizamos tomcat y apache. La mayor seguridad que presenta frente a otras soluciones, son los niveles de seguridad en cada capa. Otro punto no menos importante es la portabilidad que brindan las tecnologías con las que se implementa la solución, y también los bajos costes que estas implican dado que están basadas enteramente en software libre. Algunas de las desventajas que presenta esta arquitectura es que tiene una curva de aprendizaje alta dado que cada capa implica una especificación y por lo tanto diferentes componentes de desarrollo. Otra desventaja significativa se encuentra en los recursos de hardware que se necesitan tanto para la etapa de desarrollo como para la implantación y despliegue. 4. Conclusiones y recomendaciones - JEE5 provee una plataforma que es de las mas optimas para realizar aplicaciones con necesidades mas exigentes, generalmente en el contexto de los negocios, las aplicaciones pueden ser de tipo escritorio o Web, y al tratarse de especificaciones y no un producto lo hace mas diverso, con la ventaja añadida de la estandarización. - Las experiencias con las versiones de J2EE, las herramientas y frameworks que surgieron para aminorar sus deficiencias han servido mucho para que JEE5 sea una de las plataformas con las mayores ventajas en su género, haciendo más fácil el desarrollo en ésta. - La desventaja mas significativa de JEE5 es la de usar un solo lenguaje de programación, sin embargo Java permite operar con otros lenguajes, y también el añadido de que JEE5 es integrable e interoperable. - Para que el rendimiento no se vea menoscabado en una aplicación JEE5, se debe contar con un hardware de buenas características, tanto desde el desarrollo, como en donde residirán el servidor de Aplicaciones y la aplicación en si; sin embargo actualmente existe software que cumple esas características sin que esto aqueje muchos los costos, teniendo en cuenta la dimensión de la aplicación. 5. Referencias [JEE5, 2008] Java Sun (2008). Java Platform, Enterprise Edition 5 (Java EE 5). [JBossSeam] JBoss JBoss Enterprise Application Platform. [OpenXava] OpenXava Aplicaciones Java de gestión desde el modelo

198 [GenexusJEE] Genexus J2EE (2008). Generador de Aplicaciones". [GanttProject] Sitio Web GanttProject [StartUML] Sitio Web StartUML [RichFaces] Sitio Web de la librería RichFaces [JaspeReport] Sitio Web [GlassFich] Sitio Web [GOF94] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (The Gang of Four). Design Patterns. Addison Wesley Professional Computing Series, ISBN [MARIN01] Floyd Marinescu, EJB Design Patterns: Advanced Patterns, Processes, and Idioms. John Wiley & Sons, ISBN [Herrera, 2007] J. C. Herrera, A. Matteo, I. Díaz., Una Caracterización de Herramientas MDA de Código Abierto. Universidad Central de Venezuela, Facultad de Ciencias - Escuela de Computación,2007. [Colque, 2006] David Colque, R. Valdivia. Integración de Tecnologías en una plataforma J2EE dirigida por modelos. Universidad de Tarapacá, Escuela Universitaria de Ingeniería Industrial, Informática y de Sistemas, [Piñeiro, 2006] Juan M. Piñeiro, A. Figueras. Hacia una arquitectura con Java Server Faces, Spring, HIbernate y otros Frameworks. Tecnimap Conference, Mayo [Solano, 2007] Roberto Solano, Eduardo Coles. Ruby on Rails, una forma rápida de hacer aplicaciones Web. Universidad de Costa Rica, Escuela de Ciencias de la Computación e Informática, Febrero [ Angel.2006]Miguel A. Garrido P., Evaluación Comparativa de aplicaciones Web entre J2EE y Microsoft.NET, Tesis de Grado, Universidad Católica de Temuco, [ Sillogistic, 2007] Jason M. Hanley, B. Math, Web Development: A Comparison of Three 198

199 SEDFE: Un Sistema Experto para el Diagnóstico Fitosanitario del Espárrago usando Redes Bayesianas Pedro Shiguihara Juárez 12 Jorge Valverde Rebaza 12 1 Universidad Nacional de Trujillo 2 Sociedad de Estudiantes de Ciencia de la Computación (SECC) p.shiguihara@gmail.com, jorge.carlos14@gmail.com Resumen Este trabajo propone un sistema experto basado en el modelo probabilístico de Redes Bayesianas para el diagnóstico de las plagas y enfermedades del espárrago. Usamos la técnica de propagación de certeza basada en el algoritmo de paso de mensajes de Kim y Pearl (Kim y Pearl, 1983), que permite la actualización de nodos dentro de la red, alcanzando resultados con un margen de diferencia de centésimas con respecto al cálculo exacto de la Tabla de Distribución Conjunta Completa usando un algoritmo de Enumeración. Además hemos podido lograr establecer resultados coherentes de acuerdo a los patrones convencionales de cada germen patógeno y sus manifestaciones. Palabras claves Grafo acíclico, Tabla Distribución Conjunta, Probabilidad condicional 1. Introducción Los Sistemas Expertos fueron concebidos desde su creación como una manera de aplicar las técnicas de la Inteligencia Artificial a problemas reales (Benítez y Pérez, 2003). Su plataforma basada inicialmente en la lógica de primer orden se ha ido potenciando al punto de contar con diversas técnicas para lograr conclusiones adecuadas tanto para los sistemas de tipo deterministas como para los de tipo estocástico. Según (Castillo, 1997), aquellos Sistemas Expertos de tipo estocástico, según que utilizan la probabilidad como medida de incertidumbre son llamados sistemas expertos probabilísticos y la estrategia de razonamiento que usan se conoce como razonamiento probabilístico o inferencia probabilística. Actualmente, existen muchos modelos probabilísticos empleados en muchas áreas de trabajo y disciplinas de estudio, los cuales contribuyen grandemente a solucionar problemas dentro de nuestra sociedad. Con respecto al espárrago no se han encontrado muchos trabajos, a pesar de la gran importancia socioeconómica que esta hortaliza significa para el país (O Brien y Díaz, 2004) y por constituirse como uno de los principales productos de agro-exportación (Dirección General de Información Agraria, 2007), (O Brien y Díaz, 2004). Sin embargo, a pesar de la excelente condición climática presente en el Perú para la cosecha del espárrago y de las buenas prácticas agrícolas implementadas, uno de los principales problemas identificados es la escasa atención fitosanitaria que termina por encarecer los costos y disminuir el rendimiento de producción (O Brien y Díaz, 2004), (Intesa, 2003). En este contexto, presentamos un sistema experto probabilístico, el cual modela la realidad patogénica del espárrago otorgando el diagnóstico respectivo. El modelado consiste en la construcción de una Red Bayesiana compuesta por un conjunto de variables, de manera que hay m variables que representan la presencia o ausencia de varias enfermedades y n variables que representan la presencia o ausencia de determinados 199

200 síntomas (Susi, 2007), las cuales mantienen una relación causa-efecto. Todos los nodos que forman parte de la red contienen una tabla de probabilidades condicionadas a priori. A partir de esto realizamos la inferencia usando el algoritmo de paso de mensajes de Kim y Pearl (Kim y Pearl, 1983), el cual tiene la ventaja de ir actualizando todos los nodos de la Red Bayesiana conforme vayan apareciendo nodos de los que ya se tiene un conocimiento a priori. El resto del documento se organiza de la siguiente manera. En la sección 2 se muestra una descripción de trabajos previos. En la sección 3 se describe una descripción acerca de nuestra red y el fundamento teórico que lo enmarca, luego en la sección 4 se explican los experimentos realizados, mientras que en la sección 5 se presenta una discusión de los resultados obtenidos y en la sección 6 se presentan nuestras conclusiones. 2. Trabajos Previos Como se mencionó en la sección anterior, no se han encontrado muchos trabajos en este tópico. En (Gonzalez, 1990) se describen algunos sistemas expertos limitados a la identificación y manejo integrado de plagas de algunos vegetales como el trigo, manzano, soja, entre otros. Con respecto al espárrago, en el año 2004, estudiantes graduados de la Universidad César Vallejo de Trujillo, realizaron el Sistema Experto Agrícola Consultor, aplicado al proceso de control y diagnóstico de plagas y enfermedades en el cultivo del espárrago para la costa Liberteña. Dentro del sistema, ellos emplearon la técnica de árboles de decisión para realizar la inferencia. Luego, en el año 2007, nosotros presentamos el Sistema Experto para Diagnóstico Fitosanitario del Espárrago SEDFE, basado en la técnica de inferencia de árboles de decisión. Los resultados obtenidos en la primera versión de SEDFE eran muy limitados debido a la complejidad que se requería para adaptar la inferencia a distintos campos de cultivo, lo que obligaba a plantear decenas de reglas que permitan darle mayor flexibilidad para el diagnóstico, a coste del mantenimiento. 3. Fundamento Teórico 3.1 Red Bayesiana La red bayesiana de tipo causal o red de diagnóstico (Korb y Nicholson, 2004) es la que hemos establecido para la estructura de datos de nuestro sistema experto. Nuestra red a su vez, es una red binaria, ya que cada variable contiene sólo dos posibles valores: Presencia (representado por 1) y Ausencia (representado por 0) (Susi, 2007). La construcción de la red, requiere de un estudio estadístico previo, para determinar las enfermedades y síntomas relacionados, que están presentes en el ambiente a implantarse, esto implica, lograr estimaciones de qué enfermedades están presentes en dicho entorno, y qué síntomas están asociados a cada una de ellas y en qué porcentaje. Obviamente los síntomas con alto grado de sensibilidad y especificidad con respecto a una enfermedad, serán considerados como síntomas verdaderos de dicha enfermedad. La sensibilidad es la probabilidad que indica una correlación entre la aparición de la enfermedad y la aparición del síntoma. Mientras que la especificidad es la probabilidad de no tener el síntoma, cuando no está la enfermedad presente. Es decir, cuando se sabe que la presencia de un síntoma X es prácticamente un hecho, la presencia de la variable X es 100%, esto expresado en probabilidad sería P(X=1) = 1.0, como se expresa en la tabla 1. Así mismo cuando se tiene la información de que el síntoma X está descartado, su probabilidad es P(X=0) =

201 Representación Presencia de X Evidencia Ausencia de X Presencia de síntoma X P(X=1) P(X=1) = 1.0 P(X=1) = 0.0 Ausencia de síntoma X P(x=0) P(X=0) = 0.0 P(X=0) = 1.0 Tabla 1: Representación de los posibles valores que puede tomar una variable de la red y la probabilidad que adquieren al ser evidenciadas o instanciadas. Este tipo de red contiene una arista dirigida que parte del nodo padre (enfermedad) hacia un nodo hijo (síntoma) (Korb y Nicholson, 2004). En la figura 1 podemos observar una red de tipo causal, en donde la evidencia proviene normalmente de los nodos síntomas, y se pretende determinar qué nodos enfermedades representan mejor a los síntomas aparecidos. Figura 1: Ejemplo de una Red Bayesiana de diagnóstico, donde los nodos sombreados representan la evidencia y cada uno tiene una tabla de probabilidad condicional (CPT). En la figura 1 podemos tomar que el nodo R representa a la enfermedad del espárrago conocida como Roya, mientras que el nodo síntoma TS y TPR representan a los síntomas de Tallo Seco y Tallo con Pústulas Rojizas respectivamente. Tanto TS como TPR han sido evidenciadas, confirmando la presencia de Tallo Seco y la ausencia de Tallo con Pústulas Rojizas. Ahora podemos estimar la probabilidad de que aparezca Roya dada las dos evidencias anteriores, como se expresa en la consulta: P(R=1 TS=1, TPR=0). La notación que presentamos en este paper acerca de las variables o nodos, como en la figura 1 y tabla 1, se basan en las referencias de (Russell y Norving, 2003), (Korb y Nicholson, 2004) y (Susi, 2007) Tabla de Distribución Conjunta Completa (TDCC) Esta forma de distribución se asemeja a una tabla lógica de verdad, recordemos que nuestra red es binaria. Es decir, si tuviéramos cuatro variables presentes en la red, habría 2 4 combinaciones de probabilidades, permutando las ausencias y presencias de las variables. Entonces, la probabilidad conjunta de una sola entrada de la tabla está dada por (Russell y Norving, 2003): P( a1, a2,..., an ) = P( an an 1, K, a1) P( an 1 an 2, K, a1) KP( a2 a1 ) P( a1) (1) Para la combinación de valores P a, a,..., a ). Luego, queda resumido en: ( 1 2 n n P( a1, a2,..., an ) = P( xi xi 1, K, x1) i= 1 (2) 201

202 Teniendo la TDCC, es posible estimar la probabilidad de cualquier variable, sin embargo el costo del algoritmo es exponencial, en función de la cantidad de variables: n O ( n2 ) (Russell y Norving, 2003) Independencia condicional La independencia condicional es muy importante dado que la tabla distribución de probabilidades nos indica que es necesario calcular todas las probabilidades en su conjunto para poder inferir algo. Con la independencia condicional podemos redefinir el cálculo de las probabilidades, sin necesidad de involucrar a todas las variables, sino, únicamente a los síntomas y enfermedades implicadas, reduciéndose de esta manera, el costo de cálculo de probabilidades. (Russell y Norving, 2003) y (Korb y Nicholson, 2004), tratan este tema con detalle Teorema de Bayes El teorema es ampliamente usado en la teoría de la probabilidad, según (Russell y Norving, 2003) subyace a todos los sistemas modernos de inferencia probabilística. El teorema es derivado de la fórmula de probabilidad condicional y permite establecer la probabilidad a posteriori de una variable Y, dado un conjunto de eventos X. P( X Y ) P( Y ) P *( Y ) = P( Y X ) = (3) P( X ) Definición de Red Bayesiana Según (Susi, 2007) y (Castillo, 1997) una Red Bayesiana es un par ( D, P), donde D es un grafo acíclico dirigido (GAD) tal que los nodos representan las variables del problema X = { X1, X 2,..., X n} y los arcos representan las dependencias probabilísticas, y P = { p( x1 pa( X1)),..., p( xn pa( X n ))} es un conjunto de n distribuciones de probabilidad condicionada, una para cada variable, siendo pa ( X i ) el conjunto de padres del nodo X i en el grafo D. Donde además el cálculo de la probabilidad conjunta del problema se obtiene mediante el producto de los elementos de P, tal que: n P( x) = p( x pa( )) (4) i= 1 i X i 3.2. Tipos de Razonamiento Según (Korb y Nicholson, 2004), en una Red Bayesiana se pueden efectuar distintos tipos de razonamiento dependiendo de la dirección con la que se realice la inferencia. El Razonamiento predictivo, es aquel en el que las evidencias son las causas y se busca obtener información acerca de los efectos, éste tipo de razonamiento sigue la dirección de las aristas de la red. El Razonamiento de diagnóstico es el que a partir de los síntomas busca obtener la causa, éste tipo de razonamiento sigue la dirección opuesta a las aristas de la red. El Razonamiento intercausal implica el razonamiento acerca de causas mutuas para un efecto común mientras que el Razonamiento combinado es el que resulta de la combinación de los razonamientos descritos. En el sistema que presentamos, hacemos uso de un razonamiento de diagnóstico, puesto que las evidencias que necesitamos conocer son los síntomas que una planta de espárrago presenta para poder determinar que enfermedad la está causando. En la figura 2 se muestra una Red Bayesiana de diagnóstico de enfermedades del espárrago. En la figura 2, la ocurrencia de síntomas como tallo seco, raíces secas y hojas marchitadas influirá en el cambio de los valores de la probabilidad condicional de sus nodos padre: Roya, Estemfiliosis y Fusariosis. 202

203 Figura 2: Red Bayesiana de diagnóstico de enfermedades del espárrago. Los nodos del nivel superior (nodos color amarillo) representan las enfermedades (causa), y los nodos de nivel inferior representan los síntomas (efecto). La evidencia de ciertos síntomas (nodos color naranja) determina un paso de mensajes en sentido opuesto a la dirección de las aristas de la red (flechas de color rojo) Inferencia de la Red Bayesiana Como hemos mencionado, el proceso de inferencia será basado en el algoritmo de paso de mensajes de Kim y Pearl (Kim y Pearl, 1983), explicado también en (Korb y Nicholson, 2004), el cual, es similar al de inferencia por enumeración, sin embargo considera la comunicación bidireccional, es decir de padres a hijos y viceversa, lo que permite establecer razonamiento de diagnóstico como de predicción. Por otro lado, el algoritmo almacena valores parciales en base a los mensajes π y λ, recibidos de los nodos padres e hijos respectivamente (Korb y Nicholson, 2004). Esto permite tener un precálculo de probabilidades que ahorra tiempo para la siguiente vez. A continuación describiremos los valores usados en el algoritmo de inferencia, considerando que un nodo actual X tiene un conjunto de padres U y un conjunto de hijos Y Probabilidad λ Es el valor que se usa para realizar un diagnóstico. Se obtiene a través de la contribución de cada enlace saliente del nodo actual, es decir por el conjunto de nodos hijos. Donde E Y j / X λ ( X ) = P( E X ) (5) Y j Yj / X es toda la evidencia conectada a Y j a través de sus padres, excepto X Probabilidad π Es el valor que da soporte a la inferencia predictiva, y es la contribución de cada enlace entrante a X, es decir, los padres de X. Donde π U ) = P( U E ) (6) X ( i i Ui / X E U i / X son todas las evidencias conectadas a i U con excepción, a través de X Mensaje λ El nodo actual X calcula nuevos mensajes para enviarlos a cada uno de sus padres. En este caso la propagación del mensaje se realiza de abajo hacia arriba. λx ( ui ) = λ( xi ) P( x 1,, ) ( ) uk ui i u K un π X uk (7) Mensaje π El nodo X calcula los nuevos mensajes para enviarlos a sus hijos, como se muestra en la figura 8. Esto mantiene actualizado a sus nodos padres con respecto a la propagación de evidencia vía X. k i π Y ( x ) = j i α [ k j 1 si valor evidencia x entró 0 si evidencia es para otro valor x j αbel( xi ) λy ( xi )] P( x 1,..., ) i X ( i ) = u1,..., u i u un π u k n λ ( x ) 203 i Y j i (8)

204 4. Selección de síntomas para enfermedades y plagas del espárrago El espárrago presenta muchas enfermedades y plagas, estos a su vez presentan muchos síntomas. Modelar esto como una Red Bayesiana implicaría la construcción de un grafo muy grande y complejo. Esto significa que, en el peor caso, todos los nodos se actualizarían haciendo complejo el cálculo de probabilidades, sin embargo creemos que esto no es necesario si tomamos en cuenta ciertos criterios para modelar la red. Estos son: Si una enfermedad presenta n síntomas, será necesario sólo considerar aquellos que tienen un alto nivel de sensibilidad y especificidad para dicha enfermedad RS TPN TCP PC Sensibiilidad Especificidad Figura 3: Niveles de sensibilidad y especificidad de los síntomas de la Estemfiliosis que veremos en la sección de pruebas. 4. Experimentos y Resultados Para la realización de pruebas, nos hemos basado en (Dirección General de Información Agraria, 2007) y las características usuales (síntomas) de las enfermedades del espárrago. Aquí exponemos el análisis de una enfermedad: la estemfiliosis y cómo el sistema logra inferir las consultas expuestas a continuación. Los datos fueron elegidos de acuerdo a nuestro criterio, basándonos en las características más comunes de cada enfermedad. De esta manera, para el entorno A se modeló la Red Bayesiana que se muestra en la figura 4. Figura 4: Red Bayesiana de diagnóstico modelada para el entorno A En la tabla 2 se resume la información obtenida para la Estemfiliosis (E). En las tablas 3, 4, 5 y 6 se presentan los resultados obtenidos al realizar consultas acerca de la enfermedad Estemfiliosis sobre la Red Bayesiana implementada para el muestreo tomado al entorno A. Los resultados que obtenemos son comparados con los obtenidos por el método de inferencia exacta por enumeración presentado en (Rusell y Norving, 2003). Los síntomas de la red, serán presentados con abreviaciones (ver figura 4), tales como: Pérdida de cladiodos (PC), Tallo pálido (TCP), Raíces secas (RS), etc. 204

205 P(E=1) = P(E=0) = P(PC=1 E=1) = P(PC=0 E=1) = P(PC=1 E=0) = P(PC=0 E=0) = P(TCP=1 E=1)=0.802 P(TCP=0 E=1)= P(TCP=1 E=0)=0.069 P(TCP=0 E=0)= P(RS=1 E=1) = P(RS=0 E=1) = P(RS=1 E=0) = P(RS=0 E=0) = P(TPN=1 E=1) = P(TPN=0 E=1) = P(TPN=1 E=0) = P(TPN=0 E=0) = Tabla 2: Probabilidades a priori para la enfermedad Estemfiliosis (E). Consultas RB (%) Enum.(%) P( E=1 RS=1) P( E=1 TPN=1) P( E=1 TCP=1) P( E=1 PC=1) P( E=0 RS=0) P( E=0 TPN=0) P( E=0 TCP=0) P( E=0 PC=0) Tabla 3: Valoración de la presencia (E=1) y ausencia (E=0) de enfermedad con el método de propagación y el de Enumeración, dado un síntoma en la consulta (RS, TPN, TCP ó PC). Consultas RB(%) Enum.(%) P( E=1 RS=1, TPN=1) P( E=1 RS=1, TCP=1) P( E=1 RS=1, PC=1) P( E=1 TPN=1, TCP=1) P( E=1 TPN=1, PC=1) P( E=1 PC=1, TCP=1) Tabla 4: Valoración de la presencia (E=1) de enfermedad con el método de propagación y el de Enumeración, dado dos síntomas en la consulta. Consultas RB(%) Enum.(%) P( E=1 RS=0, TPN=1, TCP=0, PC=0) P( E=1 RS=1, TPN=1, TCP=0, PC=0) P( E=1 RS=1, TPN=0, TCP=1, PC=0) P( E=1 RS=1, TPN=0, TCP=1, PC=1) P( E=1 RS=1, TPN=1, TCP=1, PC=0) P( E=1 RS=1, TPN=1, TCP=1, PC=1) Tabla 5. Valoración de la presencia (E=1) de enfermedad con el método de propagación y el de Enumeración, dado todos los síntomas en la consulta. 205

206 Consultas RS TPN TCP PC P( E=1 RS=1, TPN=1) P( E=1 RS=1, TCP=1) P( E=1 RS=1, PC=1) P( E=1 TPN=1, TCP=1) P( E=1 TPN=1, PC=1) P( E=1 PC=1, TCP=1) P( E=1 RS=0, TPN=1, TCP=0, PC=0) P( E=1 RS=1, TPN=1, TCP=0, PC=0) P( E=1 RS=1, TPN=0, TCP=1, PC=0) P( E=1 RS=1, TPN=0, TCP=1, PC=1) P( E=1 RS=1, TPN=1, TCP=1, PC=0) P( E=1 RS=1, TPN=1, TCP=1, PC=1) Tabla 6: Valoración de todos los síntomas de la Estemfiliosis, aplicando el método de propagación, con las consultas de la tabla 4 y 5. En las figuras 5 y 6 se muestran los resultados de las consultas mostradas en la tabla 3. En las figuras 7 y 8 se muestran las comparaciones de los resultados normalizados de las consultas mostradas en las tablas 4 y 5 respectivamente PC RS TPN TCP Sensibiilidad P(E=1 X) PC=0 RS=0 TPN=0 TCP=0 PC=0 RS=0 TPN=0 TCP=0 Especificidad P(E=0 X) Figura 5. Resultados de las consultas de la tabla 3 donde hay correlación de la probabilidad de presencia de la Estemfiliosis dada la presencia de un síntoma: PC, RS, TPN ó TCP. Figura 6: Resultados de las consultas de la tabla 3 donde hay correlación de la probabilidad de ausencia de la Estemfiliosis dada la ausencia de un síntoma: PC, RS, TPN ó TCP RS=1, PC=1 TPN=1, PC=1 RS=1, TPN=1 PC=1,TC P=1 RS=1, TCP=1 TPN=1, TCP=1 RB (%) Enum (%) Figura 7: Comparaciones de resultados normalizados de las consultas mostradas en la tabla RS=0, TPN=1, TCP=0, PC=0 RS=1, TPN=1, TCP=0, PC=0 RS=1, TPN=0, TCP=1, PC=0 RS=1, TPN=0, TCP=1, PC=1 RS=1, TPN=1, TCP=1, PC=0 RS=1, TPN=1, TCP=1, PC=1 RB (%) Enum (%) Figura 8: Comparaciones de resultados normalizados de las consultas mostradas en la tabla

207 RS=1, PC=1 TPN=1, PC=1 RS=1, TPN=1 PC=1,TCP =1 RS=1, TCP=1 TPN=1, TCP=1 RS TPN TCP PC RB (%) RS=0, RS=1, TPN=1, RS=1, RS=1, RS=1, TPN=1, RS=1, TPN=1, TPN=1, TCP=0, TPN=0, TPN=0, TCP=1, PC=0 TCP=1, PC=1 TCP=0, PC=0 TCP=1, PC=0 TCP=1, PC=1 RS TPN TCP PC E= Figura 9: Comparaciones de resultados usando el método de propagación para las consultas de la tabla 6 para dos síntomas. Figura 10: Comparaciones de resultados usando el método de propagación para las consultas de la tabla 6 para tres síntomas. 5. Discusión de los Experimentos En la figura 5 podemos observar en general, que la muestra de sensibilidad es inversamente proporcional a la aparición de la enfermedad sólo y cuando el síntoma es el único síntoma visible (o instanciado). Esto es lógico, los demás síntomas tienen poca sensibilidad y su contribución de probabilidad no asegura que la enfermedad pueda aparecer. Por otro lado, la enfermedad con más baja sensibilidad como el Tallo pálido (TCP) genera que la enfermedad tome su máxima probabilidad de aparición dentro de la figura 5., esto se debe a que hay altas probabilidades que los demás síntomas aparezcan ya que todos tienen altas sensibilidades y por tanto brindan una alta contribución a que pueda aparecer. En la figura 6 pasa lo mismo pero en el sentido inverso, es decir, cuando se estima la probabilidad de ausencia de enfermedad, cuando tampoco aparecen los síntomas. Cabe destacar que si el síntoma que tiene alta sensibilidad, también tuviera alta especificidad el valor de aparición de la enfermedad sería más alto ya que también es parte de la contribución para la aparición. Siempre es recomendable seleccionar los síntomas con alta sensibilidad y especificidad para una enfermedad. En las figuras 7 y 8 mostramos los resultados obtenidos por el método de propagación Kim y Pearl (Kim y Pearl, 1983) usado en nuestro sistema de inferencia, y el algoritmo de distribución conjunta completa de Enumeración. Los resultados son muy similares, sólo diferenciados por centésimas y en algunos resultados por milésimas. Esto da la seguridad de que el algoritmo usado logra tiempos similares con la ventaja de que los resultados parciales siempre son guardados, gracias al paso de mensajes; a comparación del algoritmo de Enumeración donde toda la probabilidad es calculada de nuevo. En la figura 9 podemos observar el mismo comportamiento que en le figura 5, es decir cuando los síntomas visibles son los que tienen más alta sensibilidad (y en nuestro caso también, más baja especificidad correspondiente) implica que las contribuciones de los síntomas restantes no podrían ayudar a que la probabilidad de aparición de la enfermedad se de acabo. Al contrario cuando los síntomas de más baja sensibilidad (TPN y TCP) aparecen, la probabilidad de que haya Estemfiliosis es casi un hecho y esto se debe también a que los demás síntomas tienen altas probabilidades de aparecer (a comparación de TPN y TCP) dentro del ambiente por su alta sensibilidad detectada en el entorno del experimento. 207

208 6. Conclusiones Los síntomas con baja especificidad y sensibilidad, cuando no son visibles, permiten establecer mucha más duda de que la enfermedad pueda aparecer, aún teniendo síntomas con altas sensibilidades visibles, por ello es recomendable usar siempre síntomas que traten de caracterizar en lo mejor posible a una enfermedad, teniendo altas sensibilidades y especificidades para tener mucha más precisión a la hora de responder una consulta. Ello requiere que los estudios estadísticos, acerca del entorno donde se va a implantar el sistema, tengan mucha confiabilidad en los datos, acerca de experiencias pasadas, entre las relaciones de los síntomas y la enfermedad (o enfermedades). El método a base de mensajes resulta tener casi los mismos resultados a comparación de métodos como el de Enumeración que es más exacto pero más costoso, ya que en vez de actualizar los datos, como lo hace el método de Kim y Pearl (Kim y Pearl, 1983), a través de mensajes, realiza un cálculo completo siempre. Por último, el sistema es totalmente adaptable a cualquier entorno, con el estudio estadístico de síntomas y enfermedades dentro de dicho entorno, como información a priori para el sistema experto. Debido a que las condiciones climáticas varían según el lugar, también varía el nivel de incidencia de ciertas enfermedades, y sus síntomas. Por tanto el sistema experto sólo requiere la información a priori adecuada para poder efectuar los diagnósticos acertados. Referencias Benítez Rochel R. y Pérez de la Cruz J.L. (2003). Presente y Futuro de los sistemas Expertos: Una perspectiva Cognitiva. Dpto. de Lenguajes y Ciencias de la Computación, Universidad de Málaga. Castillo E., Gutiérrez J.M. y Hadi A.S. (1997). Expert Systems and Probabilistic Network Models. Springer-Verlag, New York. Dirección General de Información Agraria. (2007). Informe de Producción Agropecuaria Febrero Ministerio de Agricultura del Perú. Gonzalez Andujar J.L. (1990). Utilización de los Sistemas Expertos en Entomología. Bol. San. Veg. Plagas, 16 (1): Intesa (2003). Espárragos: Busca consolidarse como el primer exportador mundial. Reporte Sectorial, Departamento de Estudios Económicos, Banco Wiese Sudameris. Kim J. y Pearl J. (1983). A computational model for causal and diagnostic reasoning in inference systems. In Proceedings of the Eighth International Joint Conference on Artificial Intelligence (IJCAI), pp Korb K.B. y Nicholson A.E. (2004). Bayesian Artificial Intelligence. Chapman & Hall/CRC computer science and data analysis. O Brien T.M. y Díaz Rodríguez A. (2004). Mejorando la competitividad y el acceso a los mercados de exportaciones agrícolas por medio del desarrollo y normas de inocuidad y calidad: El Ejemplo del Espárrago Peruano. Reporte del Programa de Sanidad Agropecuaria e Inocuidad de Alimentos del Instituto Interamericano de Cooperación para la Agricultura (IICA). Pearl J. (1986). Fusion, propagation and structuring in belief networks. Artificial Intelligence, 29, Russell, S. y Norving P. (2003). Artificial Intelligence: A modern Approach, 2da. Edición, Prentice Hall, pp Susi García R. (2007). Análisis de Sensibilidad en Redes Bayesianas Gaussianas. Memoria presentada para optar al grado de Doctor, Departamento de Estadística e Investigación Operativa, Facultad de Ciencias Matemáticas, Universidad Complutense de Madrid. 208

209 Reconstrucción de Superficies 3D aplicadas a imágenes médicas Leissi Margarita Castañeda León 2 Oscar Enrique Fernández Asunción 2 Nils Ever Murrugarra Llerena 1, 2 1 Sociedad de Estudiantes de Ciencia de la Computación 2 Universidad Nacional de Trujillo leissi.lcl@gmail.com,osciest@gmail.com,nineil.cs@gmail.com Resumen El presente artículo propone desarrollar un algoritmo para realizar reconstrucción de superficies en 3 dimensiones usando imágenes médicas en 2 dimensiones. Nos hemos basado en la detección de contornos utilizando FB4(Following Border 4) para obtener los contornos de las imágenes médicas respectivas y éstos serán usados para la posterior reconstrucción en 3 dimensiones para lo cual hemos empleado triangulación de superficies. 1. Introducción En el área de la medicina cada día aparecen enfermedades más nocivas para la salud actualmente lo que esta de novedad son los tumores que aparecen en nuestro organismo y que no se ha determinado una causa dada. Ante este problema qué podemos aportar computacionalmente para solucionarlo mejor dicho tratar de minimizarlo?. Sería muy bueno dar al médico una mejor vista del problema a solucionar, algo como tener un programa que nos permita reconstruir en 3 dimensiones el órgano o parte del organismo en evaluación. Una idea similar básicamente relacionado con la terapia de raciación a células cancerígenas fue lo que llevó a [Keppel, 1975] a crear un algoritmo de reconstrucción de superficies y que es en el cual nos basamos. El presente artículo entonces tratará sobre la reconstrucción en 3 dimensiones a partir de imágenes en 2 dimensiones, obtenidas mediante tomografías o resonancias magnéticas, pero que representen a un órgano en especial (Por ejemplo: corazón, estómago, cabeza, etc.) pero que se encuentre tal que se vea como si se hubiesen hecho cortes seguidos al mismo. Por ejemplo nosotros hemos utilizado imágenes de sólo la parte de la cabeza y fueron extraídas de videos en [Center for Human Simulation, 1995]. Lo que aquí presentamos es que dado las imágenes médicas ya definidas, obtengamos de ellas los bordes o contorno de la superficie de cada corte del órgano representado. Para ello es bueno considerar un buen detector de bordes, para ello es necesario tener algunas nociones básicas acerca de Procesamiento Gráfico de Imágenes o Procesamiento Digital de Imágenes. Ya luego cada borde obtenido será representado en el espacio 3D, donde escogiendo cada ciertos puntos, se procederá al proceso de reconstrucción mediante una triangulación. Para esta parte la mayoría de métodos propuestos por diferentes autores, consideran la realización de una triangulación de Delaunay, por otro lado nosotros hemos considerado otro criterio, como ya se mencionó anteriormente, el presentado por [Keppel, 1975] basado en áreas y no en volumen, un método sencillo y muy útil que será más adelante definido. 209

210 El artículo está estructurado entonces de la siguiente manera, en la sección siguiente se presentan trabajos previos; prosiguiendo la sección tres comenta sobre el proceso de reconstrucción 2D-3D y nuestro algoritmo implementado. La sección cuatro contiene cuadros e imágenes reportando resultados. La sección cinco muestra la discusión de experimentos y por último en la sección seis nuestras conclusiones. 2. Trabajos Previos Por los años 1994 un cadáver fue cortado por completo en pequeñas franjas consecutivamente, las cuales fueron fotografiadas y digitalizadas para crear un modelo en 3 dimensiones completo de un ser humano, el que fue usado para estudio y aplicaciones de anatomía, el presente trabajo actualmente puede ser visto en el National Museum of Health and Medicine in Washington, DC y se le denomino : Visible Human Project [Center for Human Simulation, 1995]. Tenemos muchos trabajos realizados en lo concerniente a Reconstrucción, tenemos a los basados en Volúmen y a los basado en Superficies, dentro de los cuales podemos mencionar al paper [Galin and Akkouche, 1998], donde presentan un eficiente método de reconstrucción de superficies dado un conjunto de contornos, y donde La superficie reconstruída se define como una superficie implícita. Crean una estratificación de los contornos poligonales en cada sección (o corte, que representa una forma poligonal sin intersecciones y que consiste de uno o varios contornos poligonales cerrados) en trapezoides para acelerar la clasificación de los puntos involucrado en el cómputo de la potencial función de campo y evitar la creación de un esqueleto geométrico. Tenemos en [Keppel, 1975] y en [H Fuchs and Uselton, 1977], que utilizan la triangulación para la reconstrucción de superficies, y se basan en la teoría de grafos como será descrito más adelante. Tambien en [OlaÑilsson, 2005], toman las rebanadas de las imágenes medicas pues a partir de ahí se plantean 3 problemas fundamentales en la reconstrucción de superficies como son tales como: 1. Problema de la correspondencia. 2. El problema del suelo de baldosas. 3. El problema de ramificación. El primer problema se centra en la correspondencia de la correcta conexión entre contornos, el segundo problema se centra en que las rebanadas triangulares deben estar acorde con la franja situada entre las dos rebanadas de triángulos adyacentes, y el tercer problema se produce cuando un contorno en un tramo puede corresponder a más de uno un contorno en el tramo adyacente para solucionar estos problemas plantean una serie de reglas que les permiten optimizar estos problemas. Otra antecedente importante es [Chandrajit L. Bajaj, 2005], el cual tiene cuatro grandes etapas. En la primera etapa se calcula el contorno de cada entrada (imagen), los contornos también pueden ser suavizados antes de esta etapa; la segunda etapa está dado por el Cálculo de la distancia más cercana a transformar, la tercera es Estimación de las distancias a los contornos de entrada y como ultimo paso Derivar la función de la velocidad de buen polinomio que se ajusta a los valores de la distancia, utilizando métodos como Lagrange y formulación Euleriana. 210

211 En el paper [Christiansen and Sederberg, 1978] podemos notar un algoritmo para formar una superficie en 3 dimensiones a partir de cortes en 2 dimensiones continuos, algunas de los items interesantes que comenta son: que las superficies 2D tienen que ser similares en tamaño y forma, los puntos a ser tomadas deben estar en el sentido antihorario u horario y muestra una solución para cuando en una superficie 2D tiene más de un contorno en ella usando un punto intermedio para realizar la triangulación. En [Desheng Wang and Weatherill, 2005] trata sobre un método eficiente para reconstrucción de superficies a partir de cortes seccionales, basandose en una triangulación delaunay limitada en 2 dimensiones; entre algunos de los puntos que tiene en cuenta el trabajo son: el problema de reconstrucción se divide en subproblemas llegando a pares de contornos adyacentes, solución al problema de correspondencia el cual envuelve encontrar las correctas conecciones entre los contornos de secciones adyacentes y el problema que ocurre cuando una sección corresponde a más de un contorno en la sección adyacente. Un trabajo interesante es [Benavides, 2004], donde comentan el problema de evitar errores en el transplante de un órgano que posee algun mal en el momento de la operación. En el trabajo usan 2 videocámaras, una para capturar la vista de frente y la otra una vista de perfil. Con tales videos el proceso que realizan es el siguiente: puntos 2D que viene a ser la proyección de cada vista, vértices y polígonos en 3D, bordes y coordenadas de textura en 3D, detección de caras lateral, frente y perfil en 3D las cuales nos ayudaran a formar el objeto en 3D. Un gran aporte es InVesalius es software libre que permite reconstruir partes del cuerpo a 3 dimensiones a partir de tomografías, este programa nos permite apreciar la parte reconstruida y además permite tener varios niveles de visión del órgano, asi podemos apreciar los músculos o huesos en caso de estar presentes. 3. Reconstrucción 2D-3D Tenemos un conjunto de imágenes con las características de que sean imágenes de un mismo órgano (para nuestro caso lo hemos aplicado a parte específicamente la cabeza, ya que no consideramos huecos en la imagen), que sean o representen cortes seccionales (no tan separados) hechos mediante tomografías o resonancias magnéticas, con los cuales se procederá a trabajar. Ahora para iniciar la reconstrucción en 3 dimensiones debemos primero extraer los contornos de las imágenes de 2 dimensiones. A continuación mostraremos los pasos generales para calcular las Coordenadas del Borde. Aplicaremos el filtro de la mediana (con radio de 7, tanto en x como en y) a la imagen para la eliminación de ruido. Bordear la imagen (para asegurar esté dentro los contornos de la imagen deseada) Binarizar la imagen Calcular centro de masa que viene a ser nuestro punto de inicio. Calcular el BF4 (Border Folowing 4) para obtener el contorno de la imagen dado el punto de inicio. 211

212 Figura 1: Una Imagen Médica, su binarización y su Contorno Debemos aclarar que en nuestra implementación no hemos considerado la existencia de huecos, y tampoco imágenes con más de 2 objetos. Por ejemplo ver Figura 1, donde se puede observar la presencia se dos contornos, sin embargo dado el punto de inicio, sólo se obtuvo uno de ellos, que por conveniencia tiene que ser el de mayor tamaño (que es calculado mediante el centro de masa de la imagen binarizada). Continuando, tenemos que el Algoritmo FB4 el cual nos permite encontrar el contorno de cierto objeto dado el punto de inicio hallado, para ello calculamos el punto de borde el cual es el punto de más a la izquierda del punto de inicio y que pertence al objeto y a la vez calculamos el punto blanco en esa misma dirección, el tener éstos dos puntos nos permitirá calcular otros 2 adyacentes a ellos y siguientes en el contorno, este paso se realizará hasta llegar a éstos dos puntos tomados como iniciales. Para información más a detalle ver [Chang and Saavedra, 2001].En el Algoritmo 1 se detalla este proceso. Algoritmo 1 Calcular el BF4(I,x,y) Requiere: La matriz I de la imagen, el punto (x,y) parte del interior del objeto. Asegurar: Dos vectores: bordex, bordey, que contendrán los puntos del borde (px, py) Buscar el punto más a la izquierda desde el punto central y que colinda con un punto blanco. b 1 P 0 p Q 0 punto de la izquierda de P 0 Añadir a los arreglos del borde (bordex, bordey) el punto P 0. Mientras b == 1 hacer [vx,vy,qx,qy] Determinar-Borde-Contorno(px,py,qx,qy,I) Si (p 0 x == vx y p 0 y = vy) ó (p 0 x == vx y p 0 y = vy 1) ó (p 0 x == vx y p 0 y = vy +1) entonces b 0 Si no añadir vx a bordex añadir vy a bordey px vx py vy Fin Si Fin Mientras Devolver(bordeX,bordeY) Continuando veamos el punto de triangulación para lo que debemos tener en cuenta, dados dos contornos P i = (p 1, p 2,..., p n )yq i = (q 1, q 2,..., q n ) se desea generar una triángulación de 212

213 Algoritmo 2 Determinar-Borde-Contorno(cx, cy, qx, qy, I) Requiere: La matriz I de la imagen,punto central c:(cx,cy) y q:(qx, qy) para empezar a bordear. Asegurar: punto borde (vx, vy) y q:(qx, qy) actualizado. b 1 i 1 v Determinar N o vecino(cx, cy, qx, qy) sv Determinar la secuencia de Vecinos de v (vx,vy) Determinar vecino dado cx, cy, sv(i)(secuencia). Mientras b == 1 e i <= 7 hacer Si I(vx, vy) == Blanco entonces i i+1 (vx,vy) Determinar vecino dado cx, cy, sv(i)(secuencia). Si no M vecindad del punto (cx,cy) Si es4conexo(m,cx,cy,vx,vy) entonces b 0 Si no i i+1 (vx,vy) Determinar vecino dado cx, cy, sv(i)(secuencia). Fin Si Fin Si Fin Mientras Si i == 8 entonces qx -1 qy -1 cx -1 cy -1 Si no (vx,vy) Determinar vecino dado cx, cy, sv(i)(secuencia). Fin Si Devolver(vx,vy,qx,qy) 213

214 Algoritmo 3 Es 4 Conexo(I,p i x, p i y, p f x, p f y) Requiere: Imagen I de 3 x 3, puntos central p i :(p i x,p i y), punto p f :(p f x, p f y) punto vecino de p i. Asegurar: valor entero igual a 1 si es 4 conexo, caso contrario 0. b 0 Si (p f x p i x) + (p f y p i y) == 1 entonces b 1 Si (p f x p i x) == 1 y (p f y p i y) == 1 entonces Si I(1, 2) == 0 y I(2, 1) == 0 entonces b 1 Fin Si Fin Si Si (p f x p i x) == 1 y (p f y p i y) == 1 entonces Si I(1, 2) == 0 y I(2, 3) == 0 entonces b 1 Fin Si Fin Si Si (p f x p i x) == 1 y (p f y p i y) == 1 entonces Si I(3, 2) == 0 y I(2, 3) == 0 entonces b 1 Fin Si Fin Si Si (p f x p i x) == 1 y (p f y p i y) == 1 entonces Si I(3, 2) == 0 y I(2, 1) == 0 entonces b 1 Fin Si Fin Si Fin Si Devolver(b) 214

215 Figura 2: Formación de Triángulos entre 2 contornos Figura 3: Triángulos Superpuestos la forma P i, P i+1, Q j ó Q i, Q i+1, P j entre todos los puntos de los contornos P y Q (ver Figura 2), la principal restricción es que los triángulos que se generen no se superpongan entre ellos[h Fuchs and Uselton, 1977] por ejemplo ver Figura 3. Para evitar esta situación se debe crear un grafo dirigido G-< V, A > (ver Figura 4), en el cuál los vértices corresponden a un conjunto de posibles arcos entre los puntos de P y Q, los arcos corresponden a un conjunto de posibles triángulos. Es decir: V=v ij /i=0,1,...,m-1; j=0,1,... n-1 y v ij corresponde al arco P i Q j. Entonces dado que es definido mediante un problema de grafos, nosotros para obtener una buena triangulación necesitamos obtener el camino de menor costo, donde el costo es respecto a cada triángulo(el costo esta dado por el valor del área de dicho triangulo, donde el triángulo en el grafo viene a ser arcos). Entonces dado los 2 contornos, nosotros podemos formar un grafo con un costo mínimo con respecto a las áreas de los triángulos generados en el grafo (ver Figura 5). Otro punto importante en la triangulación es que el punto P 0 y Q 0 tengan la menor distancia entre ellos para hacer un buen recorrido en la triangulación. El grafo anterior puede expresarse de la siguiente manera en la Figura 6. Por último en el algoritmo 4 se plasma nuestra idea. Figura 4: Representación de triangulación mediante un grafo 215

216 Figura 5: Camino de menor costo Figura 6: Camino de menor costo mejorado Algoritmo 4 triangular Requiere: v1 y v2 representan a los contornos P y Q respectivamente Asegurar: Vector de Triangulos p 1 q 1 crear vectort Mientras p < tamanho(p ) y q < tamanho(q) hacer t1 Formar Triangulo P p P p+1 Q q t2 Formar Triangulo Q q Q q+1 P p a1 area(t1) a2 area(t2) Si a1 < a2 entonces agregar a vectort t1 p p+1 Si no agregar a vectort t2 q q+1 Fin Si Fin Mientras Devolver(vectorT) 216

217 4. Experimentos y Resultados Para la realización de experimentos de nuestro algoritmo implementado hemos tomado como muestra un total de 256 fotos de 320 * 240 píxeles considerando 4 objetos en total. Cada 1 o, 2 o,3 o y 4 o objeto estan representados por 109,66,47 y 34 imágenes respectivamente. Realizamos experimentos variando nuestros 3 parámetros de entrada: n o de imágenes, distancia en z(distancia entre cada corte), y np(significa cada cuántos puntos seleccionaremos uno para la triangulación). Para medir nuestros resultados calculamos el tiempo de reconstrucción del objeto a 3D dado la variación de estos parámetros, los resultados se muestran en los cuadros del 1 al 5, a la vez también puede observar el número de triángulos generados para cada caso. Se debe además considerar que los experimentos fueron ejecutados en un Intel Pentium 4, CPU de 3.20 GHz, y 512MB de RAM. Tambien veamos un ejemplo de la aplicación, dado los cortes de la Figura 7, obtendremos el resultado de la Figura Discusión de los Experimentos De los experimentos realizados podemos apreciar que mientras aumente nuestro parámetro de entrada np, el tiempo de reconstrucción 3D disminuye. Por otro lado notamos que el parámetro dz, no es influyente en el tiempo de reconstrucción ya que en los resultados los tiempos fueron muy parecidos, pero genera una imagen un poco más alargada mientras sea mayor. Por ultimo dado un mayor número de imagenes el tiempo de reconstrucción es mayor pero la calidad de detalles de la imagen es más apreciable. 217

218 Figura 7: Cortes desde arriba hacia abajo en la cabeza Figura 8: Resultado obtenido dado las entradas de Figura 7 218

219 6. Conclusiones Como conclusión obtenida del trabajo realizado podemos aseverar que el método mientras más imagenes reciba proporcionará objetos en 3 dimensiones con más detalle. El algoritmo de triangulación usado es simple y facil de implementar y con una complejidad computacional lineal en comparación con la triangulación de Delaunay en 3D que nos da una complejidad computacional de O(nlog n), además brinda resultados buenos, sin embargo Delaunay nos daría muchos mejores resultados respecto a la visualización. Una de las desventajas que presenta el método es el coste computacional, ya que dado un mayor n o de imagenes demorara más tiempo en crear el objeto 3D, pero esto es compensado por los detalles obtenidos en el objeto. Se llegó a ésto dado los resultados mostrados en los cuadros Otra desventaja es que no tenemos niveles de visión en el objeto, solo podemos apreciar la parte más externa. Como cuestión futura se considera implementar un algoritmo que nos permita tener varios niveles de visión como el presentado por Invesalius. 219

220 Referencias [Benavides, 2004] Benavides, J. (2004). Reconstruction of medical images (organs) of 2d to 3d during the transplant or organ surgeries with a certain type of cancer, since a medical movie using filters of wavelet and neural networks and its visualisation with opengl. Universidad Nacional de San Agustín. [Center for Human Simulation, 1995] Center for Human Simulation (1995). Center for human simulation. [Chandrajit L. Bajaj, 2005] Chandrajit L. Bajaj, Edward J. Coyle, K.-N. L. (2005). Surface reconstruction via contour metamorphosis: An eulerian approach with lagrangian particle tracking. LinkAoping University. [Chang and Saavedra, 2001] Chang, V. and Saavedra, J. (2001). Métodos alternativos para el mejoramiento automático del contraste de imágenes. Escuela Académico Profesional de Informática, Universidad Nacional de Trujillo. [Christiansen and Sederberg, 1978] Christiansen, H.Ñ. and Sederberg, T. W. (1978). Conversion of complex contour line definitions into polygonal element mosaics. Brigham Young University Provo, Utah. [Desheng Wang and Weatherill, 2005] Desheng Wang, Oubay Hassan, K. M. and Weatherill, N. (2005). Efficient surface reconstruction from contours based on two-dimensional delaunay triangulation. Civil and Computational Engineering Centre, School of Engineering, University of Wales Swansea, Singleton Park, Swansea SA2 8PP, U.K. [Galin and Akkouche, 1998] Galin, E. and Akkouche, S. (1998). Fast surface reconstruction from contours using implicit surfaces. Laboratoire d Informatique Graphique Image et Modélisation, Ecole Centrale de Lyon. [H Fuchs and Uselton, 1977] H Fuchs, M. K. and Uselton, P. (1977). Optimal surface reconstruction from planar contours. University of Texas,Dallas. [Keppel, 1975] Keppel, E. (1975). Approximating complex surfaces by triangulation of contour lines. IBM J. RES. Develop. [OlaÑilsson, 2005] OlaÑilsson, David Breen, K. M. (2005). Arbitrary topology shape reconstruction from planar cross sections. Department of Computer Science, Purdue University. 220

221 Generación Inteligente de Horarios empleando heurísticas GRASP con Búsqueda Tabú para la Pontifica Universidad Católica del Perú Joseph Gallart Suárez 1 Fernando Alva Manchego 1 Anthony Alama Nole 1 Gissella Bejarano Nicho 1 1 Pontificia Universidad Católica del Perú jgallart@pucp.edu.pe, f.alva@pucp.edu.pe, a.alama@pucp.edu.pe, gissella.bejarano@pucp.edu.pe Resumen El problema de la generación de horarios consiste en la asignación de horas, profesores y aulas para el dictado de las clases, teniendo en consideración diferentes factores como son: disponibilidad de profesores, disponibilidad de aulas, planes de estudio para los diferentes semestres académicos, cruces de horas de dictado entre los diferentes cursos, entre otros. Existe una gran variedad de algoritmos que permiten resolver esta clase de problema. Por las características que presenta la generación de horarios de la Pontificia Universidad Católica del Perú, se decidió emplear algoritmos heurísticos en su solución. El objetivo de este documento es comparar los resultados obtenidos luego de emplear la heurística GRASP y la mejora del mismo con la Búsqueda Tabú. Para la prueba de los mismos, se diseñó el sistema SchedulePowerSoft, que provee una interfaz para el ingreso de los datos requeridos por los algoritmos y la visualización de los resultados generados. 1. Introducción En una institución educativa como lo es la Pontificia Universidad Católica del Perú existirá siempre el problema de la asignación de horarios de clase. Esta labor resulta ardua si se hace manualmente porque requiere prestar mucha atención a la gran cantidad de variables que se toma en cuenta y optimizar su distribución. Estas variables son: la cantidad de aulas disponibles, la capacidad que tiene cada una de ellas, cursos de un mismo ciclo, entre otros. Este tipo de problema es conocido en la optimización combinatoria como un Problema de Asignación de Clases (Course TimeTabling Problem). Debido a la cantidad exponencial de posibles soluciones, tener una solución exacta es computacionalmente improbable, por ello se justifica usar como solución algoritmos metaheuristicos cuyo objetivo es encontrar una solución suficientemente buena para este tipo de problema. A continuación se definen los términos que se utilizan a lo largo de este documento, de tal manera que se logre un completo entendimiento del problema. - Ciclo: conjunto de meses donde se dictan los cursos. En el caso de la PUCP 1 por lo general el ciclo dura 4 meses y medio aproximadamente (el ciclo de verano dura 1 mes y medio) - Curso: es una asignatura que requiere de 2 a 4 horas semanales de dictado. - Horario: grupo de cursos que se dictan en un determinado ciclo que no poseen problemas de cruces entre sí. - Sesiones de clase: conjunto continuo de horas en las que se dictan las clases. Un curso puede tener 1 o 2 sesiones a la semana. - Aula: lugar en donde se dictan los cursos. 1 Pontificia Universidad Católica del Perú 221

222 - Pabellón: es una estructura física que contiene un conjunto de aulas. - Turno: rango de horas en cierto momento del día. Existen 2 turnos: mañana (8-2 pm) y tarde (2-10 pm). - Hueco: espacio de una hora entre dos clases consecutivas programadas en un mismo salón en un mismo día en el cual no se haya programado ninguna clase. 2. Trabajos Previos Existe una gran variedad de algoritmos que resuelve este tipo de problemas, como es el caso de los algoritmos genéticos [6], que obtienen una solución aceptable. Otro algoritmo muy usado es el heurístico recocido simulado [7], o también los algoritmos basados en la colonia de hormigas [8], que obtienen también soluciones aceptables. Por las características particulares del problema que se desea resolver y de acuerdo a la serie de investigaciones realizadas, se optó por utilizar el algoritmo de Búsqueda Tabú (Tabu Search), el cual es ampliamente usado en este tipo de problemas (TimeTabling Problem) como se puede ver en [2] y [5]. Sin embargo, este algoritmo funciona en realidad como un optimizador, ya que requiere de una solución inicial como entrada. Mientras mejor sea la solución inicial, mejor serán los resultados que proporcionará la Búsqueda Tabú. Es por ello que se decidió emplear un algoritmo GRASP [1] para poder obtener la solución inicial necesaria. Esta combinación GRASP- Tabú ya ha sido utilizada con éxito en problemas similares (School TimeTabling Problem como en [4] y [9]). 3. Algoritmos Empleados 3.1 GRASP GRASP son las siglas para Greedy Randomized Adaptive Search Procedures. Es un algoritmo metaheurístico introducido por Feo y Resende que consiste básicamente de dos fases: construcción y mejora. [1] La fase de construcción se encarga de encontrar una solución factible a través de un procedimiento voraz. Este procedimiento consiste en encontrar, en cada iteración, un elemento del universo y agregarlo a la solución de acuerdo al valor de la función de mérito. Sin embargo, el algoritmo no selecciona el mejor elemento (el que posea el mejor valor de la función de mérito) de todos los posibles sino que emplea una lista restringida de candidatos (LRC). Esto se realiza con el objetivo de reducir el efecto de la miopía en los algoritmos voraces. Para poder formar la LRC se debe tener en consideración tres valores: α (constante de relajación, cuyo valor varía entre 0 y 1), β (mejor valor de la función de mérito) y τ (peor valor de la función de mérito). Luego, la LRC se forma con aquellos elementos que cumplan con la siguiente condición: LRC = { Si E : β c( Si ) β + α( τ β )} Figura 1 : Lista Restringida de Candidatos Donde: E: conjunto de los elementos. S i : un elemento del conjunto. c: función de mérito. 222

223 La función de mérito c debe ser tal que permita determinar cuánto beneficia determinado elemento del conjunto a la solución que actualmente se posee. Dependiendo del tipo de problema que se desee resolver, se plantea qué característica o características de los elementos y de la solución se desea fortalecer (maximizar) o debilitar (minimizar). Teniendo en cuenta esos criterios, se plantea una función de mérito adecuada. Si se observa detenidamente la fórmula presentada en la Figura 1, podemos ver que la función de la constante α es limitar la cantidad de elementos que formarán parte de la LRC. Si se posee un valor muy bajo de α (muy cercano a 0), la lista se volvería muy pequeña, limitando su cantidad de elementos casi a 1. De contar con un único elemento, este poseería a β como valor de función de mérito; lo que causaría que el algoritmo se volviese miope (característica que se desea limitar). Por otro lado, si el valor de α es muy grande (muy cercano a 1), se tendrá en la LRC a casi todos los elementos del conjunto E, lo cual haría que el algoritmo obtenga soluciones completamente aleatorias. Debido a esta característica, encontrar el valor más apropiado para la constante α resulta de vital importancia. La segunda fase de GRASP consiste en mejorar la solución brindada por la primera parte del algoritmo. Para ello se emplean algoritmos de búsqueda local como es el caso de la Búsqueda Tabú, la cual se explicará en la siguiente sección. 3.2 Búsqueda Tabú Como se menciona en [3], la Búsqueda Tabú (Tabú Search - TS) es un procedimiento metaheurístico cuya característica distintiva es el uso de memoria adaptativa y de estrategias especiales de resolución de problemas. Como todo algoritmo de búsqueda, TS se basa en la repetición de un determinado proceso hasta que se cumpla una condición de parada. Para cada iteración del algoritmo, se posee una solución inicial que es la que se desea optimizar. Para esta solución, se genera el vecindario correspondiente, conformado por todas las posibles soluciones resultantes de realizar todos los posibles movimientos predeterminados. Un movimiento viene a ser un cambio en la solución actual que permite obtener una solución diferente a la que se posee. En el contexto del problema que se desea resolver, un movimiento puede ser un intercambio o una inserción de algún elemento del problema en una posición diferente. Más adelante se proporcionará mayor detalle en relación a los movimientos definidos para el diseño del algoritmo. De este vecindario resultante, se escoge la mejor solución (óptimo local) dependiendo del valor de una función de mérito que determine cuán buena es cada una de las soluciones miembro del vecindario. Este vecino seleccionado servirá como solución inicial para la próxima iteración. Sin embargo, la búsqueda tabú emplea estrategias adicionales para poder obtener una mejor solución en cada iteración. Estas estrategias adicionales consisten en el empleo de una memoria a corto plazo y una memoria a largo plazo. Cada una de estas persigue un objetivo en particular que permite lograr que el resultado brindado finalmente por el algoritmo sea el mejor posible. La memoria a corto plazo se implementa a través de la denominada lista tabú. En esta lista se almacenan los mejores movimientos que fueron realizados en las diferentes iteraciones, con el objetivo de no volver a repetirlos y caer en un círculo vicioso. Estos movimientos almacenados son denominados elementos tabú. Cabe mencionar que la lista tabú posee un tamaño determinado y, por tanto, los movimientos en ella almacenados no permanecen en ese estado por siempre. Es así que escoger el tamaño adecuado de lista tabú es un factor determinante para la calidad de la 223

224 solución. Sin embargo, existe otro mecanismo a través del cual un elemento tabú puede ser empleado y son los llamados: criterios de aspiración. Los criterios de aspiración se definen para permitir que un elemento de la lista tabú, que permite obtener una muy buen solución, pueda ser empleado y así lograr una mejor que las que se poseen actualmente como parte del vecindario. Por otro lado, la memoria a largo plazo está formada por una estructura que permite almacenar la frecuencia en que los distintos movimientos se han ido realizando a lo largo de la ejecución del algoritmo. Adicionalmente, la búsqueda tabú emplea dos estrategias que, basadas en las memorias de corto y largo plazo anteriormente descritas, permiten obtener una solución final de calidad. Estas estrategias son la intensificación y la diversificación. La intensificación consiste en explorar a profundidad aquellos vecinos que han brindado una significativa mejoría con respecto a la solución inicial que se poseía en dicha iteración. Esta estrategia emplea la memoria corto plazo para poder lograr su objetivo. La diversificación, por otro lado, consiste en extender la búsqueda a zonas no visitadas con el objetivo de así encontrar una mejor solución a la que ya se posee. Para ello, esta estrategia emplea la memoria a largo plazo, realizando aquellos movimientos que posean una menor frecuencia de uso. Finalmente, lo que falta establecer es la condición de parada para la ejecución del algoritmo. En realidad, este factor depende de la forma como se desee diseñarlo, pero entre las condiciones más frecuentes se tienen: número determinado de iteraciones totales, número determinado de iteraciones sin mejora, valor específico de la función de mérito que evalúa la calidad de la solución, entre otros. 4. Diseño de la solución 4.1 Restricciones Principales Se consideran restricciones principales aquellas que el sistema debe cumplir obligatoriamente y son las siguientes: - No permitir traslapes entre cursos en una determinada hora en una misma aula. - Respetar los jueves culturales 2 de la PUCP. - Para asignar una clase a un salón el número de alumnos de un horario no debe exceder la capacidad del salón. - Verificar la disponibilidad del profesor. 4.2 Restricciones Secundarias Las restricciones secundarias son restricciones que el sistema debería tratar de cumplir, ya que son ellas las que determinan la calidad de la respuesta. Estas restricciones representan las características particulares de la generación de horarios de la PUCP. Son las siguientes: - Tratar que los cursos que se dictan en los primeros ciclos de facultad (quinto, sexto, séptimo) sean en el turno mañana. (8-2 PM) - Tratar que los cursos que se dictan en los últimos ciclos de facultad (octavo, noveno, décimo) sea en turno tarde.(2-10 PM) 2 Jueves cultural es un periodo de tres horas (Jueves 12-3PM) durante el cual lo alumnos no reciben dictado de clases. 224

225 - Tratar de no asignar clases a la hora de almuerzo. (12-2 PM) - Evitar huecos, maximizando el uso de las horas disponibles del salón. 4.3 Modelo de costos El modelo de costos a utilizar servirá para darle un peso, un valor de calidad al cumplimiento de las condiciones secundarias, que permita elegir entre realizar un cambio, definidos los movimientos, o mantener una clase en el salón/tiempo en el que se encuentra. Dado que se plantean dos algoritmos, GRASP como generador de la solución inicial y Búsqueda Tabú como optimizador de la misma, se plantean dos modelos de costos, uno para cada algoritmo. Finalmente, se emplea un último modelo de costos asociado a la totalidad del horario formado para conocer la bondad del nuevo horario generado en relación a las anteriores soluciones generadas. El objetivo en el algoritmo GRASP para este caso es el de minimizar f(x), función que representa el desperdicio. Está dada por la Figura 2: f(x)= CapacidadSalon CantidadAlumnos Figura 2: Función de mérito de GRASP Donde: - CapacidadSalon: máximo número de alumnos que se permite ingresar en el salón sobre el que se ejecuta la función. - CantidadAlumnos: número de vacantes que el curso tiene asignado. El algoritmo Búsqueda Tabú valida el resto de condiciones secundarias explicadas anteriormente. El modelo se representa en las Figuras 3 y 4: F = (CI1/CS2+ Cl2/CS1)- (CI1/CS1+ Cl2/CS2) Figura 3: Función que mide la calidad de un cambio en función a la cantidad de vacantes ((HI(i) + HF(i)) *ciclo(i) *turno(i) *Factor(i) ) G(i) = (1+ HA(i)) Figura 4: Función que mide la calidad de un cambio en base a las restricciones secundarias. Función Tabú: T= F- (G(2)-G(1)) Figura 5: Función Tabú empleada. Donde: - i: es el índice de clase que deseamos cambiar: 1 clase a cambiar, 2 mejor clase. - CI(i): Cantidad de inscritos de la clase i - CS(i): Capacidad de salón del salón i - HA(i): Cantidad de horas de cruce de almuerzo de la clase i. - Factor: Factor que aumenta el peso de la función en caso el curso este en su turno respectivo. 225

226 - HI(i): Hora de inicio de la clase i. - HF(i): hora fin de la clase i. - Ciclo(i): ciclo al que pertenece la clase i. - Turno(i): Turno al que pertenece la clase i La función F busca conocer la calidad de un cambio en relación a la cantidad de alumnos en los salones y la cantidad de vacantes asignadas a las clases que se pretende cambiar. La función G mide la calidad de la asignación de la clase en el salón/tiempo en que se desea programar, dependiendo del peso de las condiciones secundarias. La función T, función de mérito del algoritmo Búsqueda Tabú, es la función que se busca maximizar. Se realiza una resta que indica el efecto del cambio con respecto a no realizarlo entre dos clases. De obtenerse T > 0 significa que se obtuvo una mejoría y se procede al cambio; en caso contrario se mantienen las clases en las mismas posiciones. Los factores (constantes) que se utilizan para aumentar el peso de cada solución fueron calibrados utilizando experimentación numérica. Los modelos mencionados anteriormente permiten definir si un movimiento entre clases debe llevarse acabo. El último modelo a representar indica la calidad del horario. Para esto utilizamos un esquema de puntajes. Se recorre la estructura salón por salón, día por día; en cada salón se buscan las clases asignadas y se otorgan los siguientes puntajes. - Si la clase está en su turno se le asigna 10 ptos. - Si la asignación respeta la hora de almuerzo se le asigna 5 ptos. - Si la programación de clases en un salón contiene huecos entre clases se le restara 5 pts. 5. Representación de datos Para la representación de datos se usó un arreglo de cuatro dimensiones como se muestra en la figura: Figura 6: Arreglo de cuatro dimensiones La primera dimensión del arreglo representa los días de la semana, la segunda dimensión 226

227 representa el tipo de aula, la tercera dimensión representa las aulas de los pabellones, y por último la cuarta dimensión representa las horas de dictado. 6. Componentes del algoritmo 6.1 Construcción de la solución inicial Para la solución inicial se uso el algoritmo metaheurístico GRASP, el cual construye una solución inicial en base a la capacidad del salón y a la cantidad de alumnos de un curso determinado, tratando de minimizar el desperdicio del aula. 6.2 Mejoramiento de la solución Luego de obtener la solución inicial se procede a mejorarla utilizando el algoritmo de Búsqueda Tabú Definición de movimientos Los movimientos considerados para la implementación del algoritmo Tabú son los siguientes: -Bloque de 2 horas ocupado de una sola clase con bloque de 2 horas ocupado.de una sola clase. -Bloque de 2 horas ocupado con bloque de 2 horas libre. -Bloque de 3 horas ocupado de una sola clase con bloque de 3 horas ocupado de una sola clase. -Bloque de 3 horas ocupado de una sola clase con bloque de 3 horas libres. Para cada movimiento que se ejecute se debe verificar siempre que se cumplan las restricciones primarias establecidas Lista Tabú La lista tabú está conformada por los intercambios entre aulas hechos en la ejecución del algoritmo, teniendo la lista un tamaño ingresado como parámetro Memoria Para la implementación del algoritmo utilizamos la memoria a corto plazo, en ella utilizamos la lista tabú Intensificación y Diversificación Se definen los siguientes movimientos de diversificación: Movimiento 1: Mismo día Misma hora Diferente aula Movimiento 2: Mismo día Diferente hora Misma aula Movimiento 3: Mismo día Diferente hora Diferente aula Movimiento 4: Diferente día Misma hora Misma aula Movimiento 5: Diferente día Misma hora Movimiento 6: Diferente día Diferente hora Movimiento 7: Diferente día Diferente hora 227

228 Diferente aula Misma aula Diferente aula Tabla 1: Movimientos de diversificación del algoritmo Tabú. Por cada movimiento establecido en la diversificación se intensifica la búsqueda una cierta cantidad de iteraciones dada como parámetro Condición de parada El algoritmo terminará luego de haber ejecutado los siete movimientos de diversificación un determinado número de veces que es ingresado como parámetro. 7. Experimentación Numérica En este caso se compara el algoritmo GRASP con el algoritmo GRASP-TABU. 7.1 Determinación de hipótesis El criterio que evaluamos es el esquema de puntajes descrito en la sección 6.1 La hipótesis planteada es la siguiente: H 0 : ē grasp-tabu > ē grasp H A : ē grasp ē grasp-tabu Figura 8: Hipótesis planteadas. Donde: - H 0 : hipótesis nula, plantea que el algoritmo GRASP-Tabú da mejores resultados que el algoritmo GRASP - H A : hipótesis alternativa, plantea que el algoritmo GRASP da mejores resultados que el algoritmo GRASP-Tabú - ē x : media de los puntajes obtenidos por los algoritmos. Se espera comprobar que la hipótesis nula es válida. Nuestra fuente para la realización de este análisis la obtenemos a partir de la ejecución del sistema SchedulePowerSoft que fue desarrollado en JAVA (JDK 1.6) y el conjunto de datos reales de los cursos de la especialidad de Ingeniería Informática de la PUCP. 7.2 Ejecución de pruebas y resultados Las pruebas se ejecutaron en una computadora Intel Core 2 Duo 2.0 Hz, 2 GB RAM y con sistema operativo Windows XP SP2. Para la ejecución de las pruebas se tomaron los siguientes parámetros: - Número de salones (10 y 30). - Número de profesores (10, 15, 20, 25). 228

229 - Número de cursos (20, 25, 30, 35, 40, 45, 50) - Tamaño de la lista Tabú (5, 15 y 25). Los números que se indican al lado de los parámetros corresponden a las cantidades empleadas de los mismos en las pruebas. En la tabla 2 se muestran los resultados obtenidos por el algoritmo GRASP y por el algoritmo GRASP - Tabú. La información empleada para las pruebas fue proporcionada por personal docente encargado de elaborar los horarios en semestres anteriores. Se generaron 12 combinaciones de los parámetros y por cada una de estas combinaciones se probó cada algoritmo 3 veces para la respectiva comparación del tamaño de la lista Tabú. Cada combinación está compuesta por valores de datos para número de salones, número de profesores y número de cursos. Los resultados obtenidos comprueban la hipótesis planteada. La media de los puntajes obtenidos por el GRASP-Tabú es mayor a la media de los puntajes obtenidos por el GRASP. Esto se puede explicar por la naturaleza metaheurística que utiliza GRASP-Tabú frente a la naturaleza voraz del GRASP. Tabla 2: puntajes obtenidos por los algoritmos GRASP y GRASP-Tabú. Media: ē grasp = Figura 9: Media obtenida con el algoritmo GRASP. 229

230 ē grasp-tabu = Figura 10: Media obtenida con el algoritmo GRASP- Tabú Luego de la experimentación numérica se comprueba la hipótesis planteada, es decir: 8. Conclusiones H 0 : ē grasp-tabu > ē grasp Según la experimentación numérica se ha comprobado que un algoritmo GRASP con optimización de Búsqueda Tabú obtiene mejores soluciones que un algoritmo GRASP. Esto se debe a que el método aplicado por GRASP se basa solamente en búsquedas de máximos locales, mientras que en el caso de Búsqueda Tabú, el empleo de la diversificación evita que la búsqueda se restrinja a máximos relativos, tratando siempre de ubicar máximos globales. Además, se comprueba que los algoritmos metaheurísticos, si bien no proveen una solución exacta, brindan soluciones lo suficientemente buenas para satisfacer las restricciones del problema y necesidades del usuario. Finalmente, se puede inferir que utilizar un sistema inteligente que genere automáticamente horarios para una universidad permitirá ahorrar recursos (horas hombre) considerablemente. 9. Referencias bibliográficas [1] Mauricio G.C. Resende, José Luis González Velarde. GRASP: Greedy Randomized Adaptive Search Procedures. Inteligencia Artificial, Revista Iberoamericana de Inteligencia Artificial. No.19 (2003), pp [2] Marco Gil Tallavó, Amadís Antonio Martínez, Algoritmo basado en Tabu Search para el problema de asignación de horarios clases. [3] Belén Melián Batista, Fred Glover, Introducción a la Búsqueda Tabú. Procedimientos Metaheurísticos en Economía y Empresa (E. Crespo, R. Martí y J. Pacheco, coordinadores), Monografías de Rect@, vol. 3, 2007 [4] Marcone Jamilson Freitas Souza, Nelson Maculan, Luiz Satoru Ochi, A GRASP-Tabu Search Algorithm to Solve a School Timetabling Problem. MIC 2001 Proceedings, Porto,Portugal, Julio 2001 pp [5] A Hertz, É. D. Taillard, D. de Werra, Tabu Search, in : E. Aarts and J. K. Lenstra, Local search in combinatorial optimization, 1997, J. Wiley & Sons Ltd., [6] Alberto Colorni, Marco Dorigo, Vittorio Maniezzo, A Genetic Algorithm to solve the timetable problem, Computational Optimization and Applications. [7] Ruibin Bai, Edmund K. Burke, Graham Kendall, Barry McCullum, A Simulated Annealing Hyper-heuristic for University Course Timetabling Problem, PATAT [8] Krzysztof Socha, Michael Sampels, and Max Manfrin, Ant Algorithms for the University Course Timetabling Problem with Regard to the State-of-the-Art Third European Workshop on Evolutionary Computation in Combinatorial Optimization [9] Souza, M. J., Maculan, N., and Ochi, L. S A GRASP-tabu search algorithm for solving school timetabling problems. In Metaheuristics: Computer Decision-Making, M. G. Resende, J. P. de Sousa, and A. Viana, Eds. Applied Optimization, vol. 86. Kluwer Academic Publishers, Norwell, MA,

231 Desenvolvendo Ambientes Inteligentes de Ensino Aplicados à Engenharia de Software Daniel Abella C. M. de Souza 1, Rodrigo C. Fujioka 1, Ryan R. de Azevedo 2, César R. Vasconcelos 3, José T. de Carvalho Neto 1, Wescley Paoli de Sousa 1, Marcelo Perin Borba 4. 1 Departamento de Informática Universidade Federal da Paraíba 2 Centro de Informática Universidade Federal da Pernambuco 3 Coordenação de Informática Aplicada Cefet Urutaí 4 Departamento de Exatas Centro Universitário de João Pessoa {daniel.abella,rodrigo.fujioka}@ppgi.di.ufpb.br, rra2@cin.ufpe.br, cesar@cefeturutai.edu.br,{jtneto,wescley.paoli,marcelo.pborba}@gmail.com Resumo Para contribuição no processo de aprendizado, cenários tridimensionais construídos com uso de técnicas de realidade virtual estão sendo associados a sistemas de e -learning. Este artigo apresenta uma ferramenta para o ensino de Engenharia de Software, onde o processo de aprendizado ocorre durante a interação do usuário em ambientes tridimensionais. Para monitoração da interação dos usuários com estes ambientes, agentes inteligentes são designados, de maneira a identificar deficiências e habilidades dos alunos. 1. Introdução Em resposta a crescente demanda por novos métodos de aprendizagem, surge o e-learning, como um aliado promissor ao ensino presencial tradicional, eliminando as fronteiras físicas para o aprendizado [Holmberg, 1989], possibilitando assim, a disseminação do conhecimento, entendimento e desenvolvimento de habilidades através da Internet. Ambientes de ensino a distância têm ganhado notoriedade não somente em empresas, como uma forma de capacitar profissionalmente seus funcionários, mas, sobretudo, no meio acadêmico, onde o aluno pode compreender melhor os assuntos apresentados em sala de aula. Além disso, ambientes de e-learning são importantes ferramentas de incentivo a pesquisa, onde as pessoas podem adquirir outros conhecimentos além daqueles apresentados em salas de aula tradicionais. Resultado do avanço da computação, interface s mais realistas e intuitivas para os usuários estão sendo desenvolvidas com foco educativo, sendo associadas a ambientes de ensino a distância, criando a idéia de imersão do usuário, onde o conhecimento do espaço do ambiente e o sentimento participação n este ambiente [Raja et al., 2004] são notórios. De maneira geral, estes ambientes virtuais tridimensionais permitem ao usuário uma navegação em cenários ricos, compostos de objetos, onde o nível de aprendizado está diretamente relacionado à capacidade de lidar com esses objetos e relacioná-los aos conceitos do mundo real. Entretanto, torna-se necessário o gerenciamento destes ambientes [Aquino et al., 2007], de forma a acompanhar as interações dos usuários e identificação das dificuldades dos alunos no aprendizado. A proposta deste artigo é o desenvolvimento de uma ferramenta de e-learning para a área de Engenharia de Software que, para potencializar o processo de aprendizado, faz uso de técnicas de realidade virtual (RV), amparada por uma sociedade de agentes, que permitem o gerenciamento da interação do usuário com a ferramenta. 231

232 O restante do artigo está organizado da seguinte maneira. A seção 2 discute trabalhos relacionados. A seção 3 detalha a arquitetura do sistema. A seção 4 apresenta um experimento da aplicação, enquanto a seção 5 conclui o trabalho. 2. Trabalhos Anteriores Para o desenvolvimento de sistemas de e-learning, diversos métodos de ensino são empregados, porém poucos conseguem superar as expectativas, despertando uma carência por métodos que possibilitem despertar o interesse do aluno [Litto, 2000]. Neste aspecto, ambientes de RV podem ser empregados de maneira a contribuir no processo de ensino/aprendizagem. Em ambientes de realidade virtual, cenários tridimensionais são usados, permitindo que várias de suas características sejam alteradas de acordo com as atividades desempenhadas pelo aluno. Diversas iniciativas propõem a associação de ambientes de realidade virtual a sistemas de e- Learning, como por exemplo, o MEDICATE [Soupla et al., 2005], voltado para a área médica e o Contruct3D [Kaufmann, Schmalstieg e Wagner, 2000], que é para o ensino na área de matemática e geometria. Entretanto, nenhuma ferramenta dispõe de um ambiente de aprendizado voltado para a área de Engenharia de Software. Atuando neste sentido, a ferramenta apresentada neste artigo dispõe de um ambiente completo para o aprendizado em Engenharia de Software, incluindo ambientes de realidade virtual e outros recursos auxiliares de ensino, que para possibilitar a extensibilidade da ferramenta, podem ser desenvolvidos e vinculados em tempo de distribuição. A escolha desta área deve-se ao fato que, como o aprendizado nesta área trabalha em um contexto teórico e prático, tínhamos a necessidade de criar um ambiente onde estas habilidades pudessem ser trabalhadas. Na seção seguinte detalharemos os módulos que compõem a arquitetura do sistema, de forma a introduzir conceitos fundamentais sobre o sistema. 3. Arquitetura do Sistema Na arquitetura do sistema, tipicamente cliente-servidor, que é apresentada na Figura 1, tem-se um browser sendo executado no cliente. Este browser, que é apresentado em detalhes na seção 3.1 a seguir, atua no lado cliente visando prover a interação do usuário com os ambientes tridimensionais. No servidor, por outro lado, têm-se a disposição dos serviços primários que possibilitam o funcionamento do sistema, que são os seguintes: - Sistema Multi-Agente (SMA): atua na monitoração da interação do usuário com o sistema, medição no nível de satisfação dos usuários e controle dos recursos associados a execução do sistema ; - Sistema Gerenciador de Banco de Dados (SGBD): persistência de todos os ambientes que são apresentados aos usuários e dados cadastrais destes usuários. 232

233 VII Jornada Peruana de Computación Figura 1: Arquitetura do Sistema Desenvolvido O detalhamento de cada um dos componentes da arquitetura descritos anteriormente é realizado na seqüência. 3.1 Browser A interação do usuário com o sistema, conforme dito anteriormente, é feita através de um browser, que foi desenvolvido para o sistema com o uso do framework Xj3d [XJ3D, 2007], toolkit open source para manipulação de ambientes 3d. Os ambientes apresentados são descritos através da linguagem Extensible 3d (X3D) [X3D, 2007], que possui recursos avançados de áudio, vídeo, navegação e interação com o usuário, que facilitaram a sua adoção. Buscando auxiliar a interação do usuário com os ambientes tridimensionais, o browser, que é apresentado na figura 2, dispõe de uma série de utilitários, dispostos horizontalmente em sua parte inferior. Figura 2: Ambiente Tridimensional Exibido no Browser Desenvolvido 233

234 3.1 Sistema Multi Agente Assim como quaisquer ferramentas para este propósito é necessário medir o progresso de seus usuários, para que interferências possam ser realizadas, objetivando melhores resultados. Entretanto, para o desenvolvimento desta característica, especialmente em nossa aplicação, novas técnicas tiveram de ser introduzidas, para que fosse possível a atuação em ambientes de realidade virtual. Para este propósito, agentes inteligentes foram usados, de maneira a constituir um sistema multi-agentes (SMA), em que, para a realização de determinada tarefa, estas entidades inteligentes se comunicam, atuando de maneira colaborativa. Este SMA foi desenvolvido através do framework open -source Java Agent Development Framework (JADE) [JADE, 2007], que possibilita o desenvolvimento de aplicações baseadas em agentes, conforme as especificações da Foundation for Intelligent Physical Agents (FIPA). São apresentados na Figura 3 os dois agentes associados ao SMA da aplicação, que são o Agente Coordenador e o Agente Ambiente. Estes agentes utilizam mecanismo de coordenação mestre-escravo [Aridor e Lange, 1998], onde o Agente Ambiente é o escravo, atuando junto ao usuário na obtenção de dados que possibilitem a identificação do progresso do usuário pelo Agente Coordenador, enquanto este último, que é o mestre, apenas atua na designação das tarefas e aguarda por resultados. 234

235 Figura 3: Sistema Multi Agente Desenvolvido. Quando informações emitidas pelo Agente Ambiente indicam progresso na interação do usuário em determinado assunto, este agente entregará estas informações ao Agente Coordenador. Este agente atualizará as estatísticas que são apresentadas ao tutor do ambiente, que retratam as deficiências ou habilidades sobre determinado tema, contribuindo assim para o aprimoramento do processo de aprendizado. O conjunto de ambientes que são apresentados ao usuário, é o resultado de uma ação desempenhada pelo Agente Coordenador, que indicou ao Agente Ambiente a inserção de um ambiente para o usuário. Porém o Agente Ambiente, responsável pela inserção dos ambientes, não detém nenhum ambiente, pois assim ele impossibilitaria a atualização dos ambientes, ou até mesmo a inserção de novos ambientes, causando a limitação do sistema. 3.1 Sistema Gerenciador de Banco de Dados De maneira a permitir a inserção de novos ambientes ou atualização de algum ambiente, estes últimos deverão ser mantidos em um banco de dados, para que possam ser sempre acessados pelo Agente Ambiente. Porém, para esta finalidade, podemos utilizar um banco de dados objetorelacional, desde que este tenha suporte a XML, devido os ambientes do sistema que são descritos através da linguagem X3D, que por sua vez é baseada em XML Para facilitar o manuseio dos ambientes, foi utilizado um Sistema Gerenciador de Banco de Dados (SGBD que aderisse as necessidades do sistema, permitindo o uso de consultas XPath [XPATH, 2007] e/ou XQuery [XQUERY, 2007]. Com o uso de consultas XPath e/ou XQuery, torna-se então possível a obtenção de trechos específicos dentro de um arquivo XML (ou baseados neste formado). Na aplicação, estas consultas são utilizadas para obter, de acordo com a necessidade, apenas os ambientes que são visitados pelo usuário, evitando que grandes quantidades de dados desnecessários sejam trafegadas pela rede. 235

236 4. Ambientes Aplicados ao Ensino de Engenharia de Software: Um Experimento Segundo Pressman, a área de Engenharia de Software se preocupa com todos os aspectos para o desenvolvimento de software, desde o seu planejamento até estágios mais avançados, como a implantação do software [Pressman, 2001]. Para o desenvolvimento de softwares de qualidade, o ensino de Engenharia de Software tornase necessário, buscando o balanceamento de assuntos práticos e teóricos, permitindo assim, a capacitação dos profissionais na área. Nesta seção é apresentado um experimento em que a ferramenta apresentada é utilizada para o ensino da metodologia de desenvolvimento de software Extreme Programming (XP) [Beck, 2000], que possibilita criação de sistemas de melhor qualidade, em tempo e custos inferiores aos habituais. Para isto, esta metodologia é amparada por uma série de práticas, princípios e valores. Após a autenticação no sistema, o usuário terá acesso à página apresentada na Figura 4, em que todos os recursos de aprendizado estão organiza dos em abas, que são: Presentation: para realização de apresentações, em situações onde a ferramenta também é utilizada durante aulas do ensino presencial tradicional; Enviroment: execução do browser, apresentado na seção 3.1; Files: disponibilização de arquivos úteis aos alunos durante o manuseio a ferramenta; Home: informações sobre o módulo de e-learning que está sendo executado no momento; Figura 4: Página Inicial do Sistema A metodologia de desenvolvimento XP possui diversas práticas, como o Test-Driven Development (TDD), que busca a identificação e correção de falhas e Pair Programming, que é uma prática bastant e conhecida, em que toda a codificação é feita em par, tendo o teclado sendo 236

237 revezado constantemente. Buscando o entendimento de cada uma destas práticas, um corredor com diversas portas é apresentado ao usuário quando o browser é iniciado, conforme apresentado na Figura 5. Em cada uma destas portas, é garantido o acesso a uma sala em que das práticas da metodologia XP é apresentada. Figura 5: Parte inicial do ambiente Cada uma destas salas é composta por objetos e atores. Os atores realizam atividades com o intuito de fornecer ao usuário, o entendimento de alguma prática da metodologia XP, enquanto os objetos representam algum conceito sobre a metodologia. É apresentada na Figura 6, uma das práticas da metodologia XP, chamada Stand up meeting. Esta prática se refere a uma breve reunião diária, em pé, entre a equipe de desenvolvimento com o objetivo de compartilhar informações sobre o projeto. Quando o usuário entra na sala em que esta prática é apresentada, os atores deste cenário se movimentam com o objetivo de transmitir a sensação em que uma reunião está em andamento. As cadeiras que são apresentadas estão propositalmente desocupadas para que o usuário compreenda que as reuniões da prática Stand up meeting são realizadas em pé. 237

238 VII Jornada Peruana de Computación Figura 6: Ensino da Prática Stand Up Meeting De maneira a garantir que outros experimentos possam ser incluídos, inclusive em outras áreas do conhecimento, esta ferramenta possui uma seção de administração, em que os tutores podem adicionar novos ambientes e identificar quais são os recursos de aprendizado devem estar disponíveis para aquela seção. 5. Conclusões e Trabalhos Futuros Devido à dificuldade inerente à construção de sistemas na área de realidade virtual, poucos sistemas já foram concebidos, possuindo resultados limitados à natureza técnica, sem grandes experimentos que demonstrassem a sua aplicabilidade em ambientes não simulados. Neste trabalho apresentamos uma ferramenta que alia técnicas de realidade virtual com ambientes de e-learning, com aplicabilidade na área de engenharia de software. Na comparação com a abordagem descrita neste artigo, as soluções encontradas para o desenvolvimento desta ferramenta não estão limitadas à área de Engenharia de Software, podendo ainda ser utilizada s em outras áreas do conhecimento. Como trabalho futuro, sugere-se a implementação de uma infra-estrutura que permita a compartilhamento de ambientes virtuais produzidos, de maneira a alcançar resultados maiores resultados, uma vez que soluções bem sucedi das possam ser divulgas e reutilizadas. Referê ncias [Holmberg, 1989] Holmberg B (1989), Theory and Practice of Distance Education, Routledge, London. [Raja et al., 2004] D. Raja et al. (2004), "Exploring the Benefits of Immersion in Abstract Information Visualization", Proc. Immersive Projection Technology Workshop, 2004; December. 238

239 [Aquino et al., 2007] Aquino, M. S.; Souza, F. F.; Frery, A. C.; Souza, D. A. C. M.; Fujioka, R. C. (2007), Supporting Adaptive Virtual Environments with Intelligent Agents.7th International Conference on Intelligent Systems Design and Applications 2007, October. [Litto, 2000] Litto, Frederic M. (2000), Os Grandes Desafios da Educação para o novo Século. Revista Impressão Pe dagógica, Curitiba, Ano IX, n.21, p.4-8. [Soupla et al., 2005] G Soula, R Pagesy, R Giorgi, D Fieschi, J Gouvernet, L Daniel, M Fieschi (2005), An adaptive medical e-learning environment: the MEDIDACTE project. [Kaufmann et al., 2000] KAUFMANN, H.; SCHMALSTIEG, D.; WAGNER, M (2000), Construct3D: a virtual reality application for mathematics and geometry education. Education and Information Technologies, v.5, n.4, p [XJ3D, 2007] XJ3D, (2007). Xj3D Java-based X3D Toolkit & Browser. Ultimo acesso em julho de 2007 [X3D, 2007] X3D, (2007). Extensible 3D (X3D). Ultimo acesso em agosto de 2007 [JADE, 2007] JADE, (2007). Java Agent Development Framework (JADE). jade.tilab.com/. Ultimo acesso em agosto de 2007 [Aridor e Lange, 1998] Aridor, Y; Lange, D. B. (1998), Agent Design Patterns: Elements of Agent Application Design, Proceedings of the Second International Conference on Autonomous Agents, p [Pressman, 2001] Pressman, Roger S (2001), Software Engineering - A practitioner's Approach. 5 th Edition, McGraw-Hill. [Beck, 2000] Beck, K. (2000) Extreme Programming explained: Embrace change, Boston, Addison-Wesley. 239

240 Recuperación de imágenes médicas a través de regiones relevantes Fredy Carranza-Athó 1 2 Laura Florian-Cruz 1 1 Universidad Nacional de Trujillo 2 Sociedad de Estudiantes de Ciencia de la Computación ed.ededc@gmail.com, laurely.fc@gmail.com Resumen El presente trabajo propone una nueva forma de extraer características discriminantes para la recuperación de imágenes médicas por contenido. El método utiliza la información rescatada por la familia de filtros de Gabor y establece a través de su combinación las regiones que deben considerarse como un patrón característico. Dicho patrón se conformará por medidas estadísticas de las regiones relevantes considerando su vecindario más cercano. El proceso de comparación de las firmas extraídas buscará el mejor emparejamiento entre las regiones relevantes, que no siempre serán en la misma proporción en todas las imágenes. La técnica es contrastada con otros métodos, mostrando superioridad en su desempeño incluso mostrando una ventaja de rendimiento frente a los cálculos tradicionales por operaciones de filtrado. 1. Introducción En el campo médico, el diagnóstico basado en imágenes necesita la producción de múltiples series de tomografías, radiografías, resonancias magnéticas, etc. Estas imágenes, en los últimos años han tenido un aumento considerable generando múltiples necesidades debido al gran volumen de datos que representan. Por ejemplo, en el Hospital Víctor Lazarte - Trujillo un sólo tomógrafo produce alrededor de imágenes mensuales. Este dato, no es para nada excepcional considerando que el Hospital de la Universidad de Génova produce imágenes en un solo día[muller et al., 2004]. El manejo de toda esa cantidad abrumadora de información conlleva a pensar en una correcta administración del contenido semántico de cada una de las imágenes. Por lo general, las imágenes médicas están asociadas a un historial de tratamiento, sin embargo por la diversidad de casos y según subjetividad del médico, dichos historiales son distintos a pesar de tener una imagen similar. Así pues, lo más eficiente es trabajar directamente con las imágenes que con diagnósticos asociados. El poder recuperar imágenes similares, entonces implica hablar sobre la Recuperación de imágenes por contenido (CBIR). Dentro de CBIR existen múltiples técnicas y por lo general se clasifican de acuerdo a la característica de bajo nivel que rescatan, color, forma o textura[long et al., 2003]. De acuerdo a las características propias de las imágenes médicas (en nuestro caso particular tomografías) no es posible aplicar extractores de forma directamente y mucho menos el color. La característica mejor discriminante y más manejable para la extracción sería el de la textura[guld et al., 2004]. En el caso de textura existen múltiples propuestas, siendo los filtro de Gabor uno de los extractores más usados[kruizinga et al., 1999]. El resultado de la extracción arroja las regiones más relevantes a la visión de un mamífero y representan un bosquejo burdo de la imagen original a distintas escalas y orientaciones. Gracias a ello es que se pueden establecer representaciones numéricas permitiendo discernir entre una imagen de consulta e imágenes almacenadas previamente. 240

241 El presente trabajo se estructura de la siguiente manera, en la primera sección se establece como se representarán la familia de filtros de Gabor, continuando con la extracción de características aplicando los filtros mencionados. En la tercera sección se explica el modo en que las regiones relevantes son extraídas y representadas en un vector de características para luego en la siguiente sección explicar las pruebas y resultados obtenidos. Finalmente se presentan las conclusiones a las que se arribó así como las referencias bibliográficas. 2. Trabajos Previos Un aporte interesante en este campo es el proyecto IRMA[Lehmann et al., 2004], donde se concibe toda una infraestructura para la implementación de un sistema PACS Picture Archiving and Communicaton System. En el caso de particular de la extracción de características este es realizado a través de la detección de blobs(regiones con comportamientos homogéneos), identificándo al objeto no sólo por las ubicaciones espaciales, sino construyendo varios niveles de blobs para un emparejamiento más eficiente. Los blobs son construidos para la simplificación de la forma complicada de las imágenes médicas; sin embargo, el coste de construirlos píxel a píxel es alto. Existen también trabajos que permiten la clasficiación de acuerdo a la clase de imagen. Estos trabajos permiten dividir clases enteras dentro de una base de datos donde las imágenes estén totalmente mezcladas. Claro es el ejemplo de Rosa[Rosa, 2001], Bueno[Bueno, 2001] quienes utilizan histogramas métricos para lograr su cometido; por otro lado, Beltrán[Beltrán, 2003] a través de descomposición wavelet puede extraer características discriminantes, así mismo, se puede comprobar la efectividad del filtro de Gabor frente a otros extractores. La utilidad de los filtros de Gabor, es puesta en evidencia en el trabajo realizado por Muller [Muller et al., 2004] donde se logra determinar un desempeño adecuado utilizando esta técnica en la recuperación de imágenes médicas por contenido. Una desventaja de su aplicación es que solamente se considera la extracción de información de textura, pudiendo en muchos casos llegar a errores. Una propuesta interesante es la de Howarth[Howarth et al., 2005] donde se realiza una combinación de técnicas basadas en características de bajo nivel para un resultado aceptable. 3. Representación de un banco de filtros Gabor Una función de Gabor es un complejo sinusoidal modulado por una envoltura Gaussiana. Para el caso de dos dimensiones una función compleja de Gabor queda anclada a una malla rectangular, la cual es equivalente a una máscara, kernel o filtro que es más familiar en el procesamiento de imágenes [Osadebey, 2006]. Existen múltiples propuestas para la representación de esta función, muchas veces dejando de lado componentes de fase. Manjunath y Ma [Manjunath and Ma, 1996] proponen la siguiente expresión para representar la función de Gabor y su correspondiente transformada de Fourier. g(x, y) = 1 2πσ x σ y exp G(u, v) = exp [ 1 2 { 1 2 ( )] x 2 σ + y2 2 x σ + 2πjU 2 hx y [ ]} (u Uh ) 2 + v2 σu 2 σv 2 (1) (2) 241

242 Donde σ x y σ y caracterizan la extensión espacial y el ancho de banda de la frecuencia del filtro de Gabor, σ u = 1 2πσ x, σ v = 1 2πσ y, U h es la frecuencia central más alta y U l es la frecuencia central más baja. Se define a g mn (x, y) como el conjunto de funciones de Gabor generada por rotación m y escalamiento n de g(x, y) ó g 00 (x, y). G mn (u, v) es la frecuencia de respuesta de g mn (x, y) g mn (x, y) = a m g(x, y ) (3) Donde x = a m (xcosθ n + ysenθ n ), y = a m ( xsenθ n + ycosθ n ), θ n = nπ K, m = 0, 1, 2,..., S 1, n = 0, 1, 2,..., K 1 (K es el número de orientaciones y S el número de escalas) y a > 1 ( a m es para que la energía sea independiente de m). La ecuación 3 puede ser considerada una ecuación generatriz, a través de la cual se puede establecer la cantidad de filtros para la extracción de características en las imágenes. Esta familia de filtros modela cierto comportamiento de células de la corteza visual [Daugman, 1988]. Lo interesante es que la mayoría de células sencillas corticales mamíferas tiene descripciones 2- D en el campo receptivo éstas pueden ser adecuadamente representadas por miembros de la familia de 2-D Gabor [Jones and Palmer, 1987]. La propuesta anterior es mejorada a través de una proceso de ortogonalización de los filtros de Gabor[Manjunath and Ma, 1996]. Estos filtros, en el espacio de frecuencia presentan un comportamiento elíptico sobrelapado. Este sobrelapamiento hace que la información que los filtros recuperan sea redundante y no permita la correcta discriminación. La estrategia propuesta para reducir redundancia está enmarcada en definir Ul y Uh. Sea K el número de orientaciones y S el número de escalas en una descomposición multiresolución, entonces; lo siguiente es asegurar que el soporte de magnitud de medio pico de dos filtros de respuesta en el espectro de frecuencia se toquen unos a otros, como se indica en la Figura 1. Figura 1: Los contornos elípticos adyacentes uno a otro indican las respuestas de mitad de pico en la familia de filtros de Gabor. El origen (u, v) = (0, 0, ) está al centro del arreglo de imágenes. Los parámetros usados fueron U l = 0,05, U h = 0,38, K = 6 y S = 4. [Han and Ma, 2007] El proceso anterior va a determinar que los parámetros de frecuencia central alta y baja sean calculados dependientes uno de otros, como se muestra a continuación. [Manjunath and Ma, 1996] a = ( Uh U l ) 1 S 1 σu = U h(a 1) 2ln2(a + 1) σ v = tanθ 1 U 2 h 2ln2 + σ2 u (4) 242

243 4. Extracción de información relevante 4.1. Aplicación de los filtros Una vez obtenida la familia de filtros de Gabor a distintas orientaciones y escalas, queda solamente realizar un proceso de convolución de modo tal que las características más relevantes sean rescatadas. Así pues, dada una imagen I(x, y), la aplicación de un determinado filtro está definida como: W mn (x, y) = I (x 1, y 1 ) (g mn ) (x x 1, y y 1 ) dx 1 dy 1 (5) La información obtenida por este proceso, reportará un conjunto de matrices de cantidad igual al número de filtros admitidos. En la Figura 2, apreciamos el resultado de esta operación, en particular a una tomografía abdominal. Los filtros al ir cambiando de escala, rescatarán en primer lugar las características más gruesas y notables de la imagen; mientras que la última escala capatará detalles en sí, dejando de lado un bosquejo general. En el caso del cambio de orientación, la información recuperada es la perteneciente a cierto ángulo. Figura 2: Resultado de la aplicación de un banco de filtros a un corte de una tomografía abdominal con 4 orientaciones y 2 escalas 4.2. Selección de regiones Manjunath y Ma[Manjunath and Ma, 1996] proponen la confomación de un patrón basado en el promedio y desviación estándar del resultado de la aplicación de cada filtro. El promedio de los valores de una imagen completa es un dato muy grosero para poder identificarla, si bien es cierto que la desviación estándar ayuda a indicar la proporción de distribución de los datos en una imagen, aun así cabe la posibilidad de que imágenes totalmente distintas tengan el promedio y desviación muy similares. La propuesta que sostenemos es poder caracterizar una imagen utilizando algo similar a lo que propone el método SIFT (Scale Invariant Feature Transform) [Lowe, 2003]. SIFT detecta puntos característicos invariantes de una imagen a través de la aplicación de filtros Gaussianos a distintas resoluciones de la imagen y diferentes tamaños de filtro. El aplicar esta transformada, directamente a las imágenes médicas resultaría poco apropiado debido a que los puntos invariantes que detectaría, no se manendrían para dos muestras no totalmente idénticas. Es claro que dos imágenes tomográficas de un mismo paciente no tienen una conformación idéntica sino 243

244 similar, es por ello que proponemos la detección regiones relevantes a través de los bosquejos que los filtros de Gabor. El primer paso que se propone es realizar una suma de los resultados de la aplicación de los bancos de filtros de Gabor de diversas orientaciones a una misma escala, con el objetivo de identificar a la imagen a través de sus características más relevantes a ese nivel. Esta serie de imágenes, como las obtenidas en la Figura 3 d1) d2) d3) determinarán las zonas de mayor relevancia y que la corteza visual detecta para poder identificar lo que percibe. Una vez obtenida la información más relevante a cada nivel de escala considerado por los filtros de Gabor, es necesario discenir ciertas partes que no manifiestan permanencia en todos los niveles, para ello simplemente se realiza una intersección, como se aprecia en la Figura 3 c). De modo que para una imagen cualquiera I finalmente el conjunto RR(I) de las regiones relevantes estará conformada por la información marcada por las ubicaciones que determine el resultado de la intersección mencionada. Figura 3: Proceso de identificación de las regiones relevantes después del filtrado. a) Imagen Original b) Regiones relevantes identificadas c) Resultado de la intersección de d1, d2, d3, que son los resultados de sumar las matrices resultantes a distintas escalas Conformación de patrones El caracterizar las regiones más relevantes en una imagen permitirán que se obtengan como factores discriminantes aquellas zonas que son significativamente más importantes al formar las representaciones de la realidad dentro de la corteza visual. Estos patrones característicos pueden ser afrontados de modos distintos, así entonces pueden ser relacionados en función de su color, forma, espacio, textura, entre otros. Dentro de este abanico de posibilidades consideramos relevante al color, forma y espacio. El color es un atributo presente dentro de las áreas marcadas como relevantes y que almacenan información útil si es correctamente ordenada y extraída. En el caso de la forma, esta es una característica de bajo nivel que brinda resultados muy buenos; sin embargo, el cálculo correcto de un descriptor es costoso. La ventaja radica entonces, en una vez obtenidas las regiones relevantes, extraer solamente de ellas la información de color o forma. El caso espacial, se asocia particularmente por el tipo de imagen que se manejará. Debido a que las imágenes médicas presentan cierta forma estándar de ser tomadas, las imágenes de dos estudios a dos personas distintas de una misma parte del cuerpo estarán posicionadas de modo muy similar. Se descarta el uso de la textura en las regiones relevantes, debido a que el cálculo de esta en regiones pequeñas, a parte de ser costoso, sería ineficiente debido a que al considerar poca cantidad de información, pueda que en muchos casos la textura extraída sea solo parte de una más grande o fácilmente ruido. La conformación del patrón es dada a través de la forma que presenta la imagen en base a sus regiones relevantes previamente identificadas. Comenzamos, definiendo al conjunto RR (I) 244