WISS

V WORKSHOP INNOVACIÓN EN SISTEMAS DE SOFTWARE - WISS -

XIX Congreso Argentino de Ciencias de la Computación - CACIC 2013 : Octubre 2013, Mar del Plata, Argentina : organizadores : Red de Universidades con Carreras en Informática RedUNCI, Universidad CAECE / Armando De Giusti ... [et.al.] ; compilado por Jorge Finochietto ; ilustrado por María Florencia Scolari. - 1a ed. - Mar del Plata : Fundación de Altos Estudios en Ciencias Exactas, 2013.

E-Book.

ISBN 978-987-23963-1-2 1. Ciencias de la Computación. I. De Giusti, Armando II. Finochietto, Jorge, comp. III. Scolari, María Florencia, ilus.

CDD 005.3 Fecha de catalogación: 03/10/2013

AUTORIDADES DE LA REDUNCI Coordinador Titular De Giusti Armando (UNLP) 2012-2014 Coordinador Alterno Simari Guillermo (UNS) 2012-2014 Junta Directiva Feierherd Guillermo (UNTF) 2012-2014 Padovani Hugo (UM) 2012-2014 Estayno Marcelo (UNLZ) 2012-2014 Esquivel Susana (UNSL) 2012-2014 Alfonso Hugo (UNLaPampa) 2012-2013 Acosta Nelson (UNCPBA) 2012-2013 Finochietto, Jorge (UCAECE) 2012-2013 Kuna Horacio (UNMisiones) 2012-2013 Secretarias Secretaría Administrativa: Ardenghi Jorge (UNS) Secretaría Académica: Spositto Osvaldo (UNLaMatanza) Secretaría de Congresos, Publicaciones y Difusión: Pesado Patricia (UNLP) Secretaría de Asuntos Reglamentarios: Bursztyn Andrés (UTN)

AUTORIDADES DE LA UNIVERSIDAD CAECE Rector Dr. Edgardo Bosch Vicerrector Académico Dr. Carlos A. Lac Prugent Vicerrector de Gestión y Desarrollo Educativo Dr. Leonardo Gargiulo Vicerrector de Gestión Administrativa Mg. Fernando del Campo Vicerrectora de la Subsede Mar del Plata: Mg. Lic. María Alejandra Cormons Secretaria Académica: Lic. Mariana A. Ortega Secretario Académico de la Subsede Mar del Plata Esp. Lic. Jorge Finochietto Director de Gestión Institucional de la Subsede Mar del Plata Esp. Lic. Gustavo Bacigalupo Coordinador de Carreras de Lic. e Ing. en Sistemas Esp. Lic. Jorge Finochietto

COMITÉ ORGANIZADOR LOCAL Presidente Esp. Lic. Jorge Finochietto Miembros Esp. Lic. Gustavo Bacigalupo Mg. Lic. Lucia Malbernat Lic. Analía Varela Lic. Florencia Scolari C.C. María Isabel Meijome CP Mayra Fullana Lic. Cecilia Pellerini Lic. Juan Pablo Vives Lic. Luciano Wehrli

Escuela Internacional de Informática (EII) Directora Dra. Alicia Mon Coordinación CC. María Isabel Meijome

comité académico Universidad

Representante

Universidad de Buenos Aires

Echeverria, Adriana (Ingeniería) – Fernández

Universidad Nacional de La Plata

Slezak, Diego (Cs. Exactas)

Universidad Nacional del Sur

De Giusti, Armando

Universidad Nacional de San Luis

Simari, Guillermo

Universidad Nacional del Centro de la

Esquivel, Susana

Provincia de Buenos Aires

Acosta, Nelson

Universidad Nacional del Comahue

Vaucheret, Claudio

Universidad Nacional de La Matanza

Spositto, Osvaldo

Universidad Nacional de La Pampa

Alfonso, Hugo

Universidad Nacional Lomas de Zamora

Estayno, Marcelo

Universidad Nacional de Tierra del Fuego

Feierherd, Guillermo

Universidad Nacional de Salta

Gil, Gustavo

Universidad Nacional Patagonia Austral

Márquez, María Eugenia

Universidad Tecnológica Nacional

Leone, Horacio

Universidad Nacional de San Juan

Otazú, Alejandra

Universidad Autónoma de Entre Ríos

Aranguren, Silvia

Universidad Nacional Patagonia San Juan

Buckle, Carlos

Bosco Universidad Nacional de Entre Ríos

Tugnarelli, Mónica

Universidad Nacional del Nordeste

Dapozo, Gladys

Universidad Nacional de Rosario

Kantor, Raúl

Universidad Nacional de Misiones

Kuna, Horacio

Universidad Nacional del Noroeste de la

Russo, Claudia

Provincia de Buenos Aires Universidad Nacional de Chilecito

Carmona, Fernanda

Universidad Nacional de Lanús

García Martínez, Ramón

comité académico Universidad

Representante

Universidad Nacional de Santiago del Estero

Durán, Elena

Escuela Superior del Ejército

Castro Lechstaler Antonio

Universidad Nacional del Litoral

Loyarte, Horacio

Universidad Nacional de Rio Cuarto

Arroyo, Marcelo

Universidad Nacional de Córdoba

Brandán Briones, Laura

Universidad Nacional de Jujuy

Paganini, José

Universidad Nacional de Río Negro

Vivas, Luis

Universidad Nacional de Villa María

Prato, Laura

Universidad Nacional de Luján

Scucimarri, Jorge

Universidad Nacional de Catamarca

Barrera, María Alejandra

Universidad Nacional de La Rioja

Nadal, Claudio

Universidad Nacional de Tres de Febrero

Cataldi, Zulma

Universidad Nacional de Tucumán

Luccioni, Griselda

Universidad Nacional Arturo Jauretche

Morales, Martín

Universidad Nacional del Chaco Austral

Zachman, Patricia

Universidad de Morón

Padovani, Hugo René

Universidad Abierta Interamericana

De Vincenzi, Marcelo

Universidad de Belgrano

Guerci, Alberto

Universidad Kennedy

Foti, Antonio

Universidad Adventista del Plata

Bournissen, Juan

Universidad CAECE

Finochietto, Jorge

Universidad de Palermo

Ditada, Esteban

Universidad Católica Argentina - Rosario

Grieco, Sebastián

Universidad del Salvador

Zanitti, Marcelo

Universidad del Aconcagua

Gimenez, Rosana

Universidad Gastón Dachary

Belloni, Edgardo

Universidad del CEMA

Guglianone, Ariadna

Universidad Austral

Robiolo, Gabriela

comité científico Coordinación Armando De Giusti (UNLP) - Guillermo Simari (UNS) Abásolo, María José (Argentina) Acosta, Nelson (Argentina) Aguirre Jorge Ramió (España) Alfonso, Hugo (Argentina) Ardenghi, Jorge (Argentina) Baldasarri Sandra (España) Balladini, Javier (Argentina) Bertone, Rodolfo (Argentina) Bría, Oscar (Argentina) Brisaboa, Nieves (España) Bursztyn, Andrés (Argentina) Cañas, Alberto (EE.UU) Casali, Ana (Argentina) Castro Lechtaller, Antonio (Argentina) Castro, Silvia (Argentina) Cechich, Alejandra (Argentina) Coello Coello, Carlos (México) Constantini, Roberto (Argentina) Dapozo, Gladys (Argentina) De Vicenzi, Marcelo (Argentina) Deco, Claudia (Argentina) Depetris, Beatriz (Argentina) Diaz, Javier (Argentina) Dix, Juerguen (Alemania) Doallo, Ramón (España) Docampo, Domingo Echaiz, Javier (Argentina) Esquivel, Susana (Argentina) Estayno, Marcelo (Argentina) Estevez, Elsa (Naciones Unidas) Falappa, Marcelo (Argentina) Feierherd, Guillermo (Argentina) Ferreti, Edgardo (Argentina) Fillottrani, Pablo (Argentina) Fleischman, William (EEUU) García Garino, Carlos (Argentina) García Villalba, Javier (España) Género, Marcela (España) Giacomantone, Javier (Argentina) Gómez, Sergio (Argentina) Guerrero, Roberto (Argentina) Henning Gabriela (Argentina)

Janowski, Tomasz (Naciones Unidas) Kantor, Raul (Argentina) Kuna, Horacio (Argentina) Lanzarini, Laura (Argentina) Leguizamón, Guillermo (Argentina) Loui, Ronald Prescott (EEUU) Luque, Emilio (España) Madoz, Cristina (Argentina) Malbran, Maria (Argentina) Malverti, Alejandra (Argentina) Manresa-Yee, Cristina (España) Marín, Mauricio (Chile) Motz, Regina (Uruguay) Naiouf, Marcelo (Argentina) Navarro Martín, Antonio (España) Olivas Varela, José Ángel (España) Orozco Javier (Argentina) Padovani, Hugo (Argentina) Pardo, Álvaro (Uruguay) Pesado, Patricia (Argentina) Piattini, Mario (España) Piccoli, María Fabiana (Argentina) Printista, Marcela (Argentina) Ramón, Hugo (Argentina) Reyes, Nora (Argentina) Riesco, Daniel (Argentina) Rodríguez, Ricardo (Argentina) Roig Vila, Rosabel (España) Rossi, Gustavo (Argentina) Rosso, Paolo (España) Rueda, Sonia (Argentina) Sanz, Cecilia (Argentina) Spositto, Osvaldo (Argentina) Steinmetz, Ralf (Alemania) Suppi, Remo (España) Tarouco, Liane (Brasil) Tirado, Francisco (España) Vendrell, Eduardo (España) Vénere, Marcelo (Argentina) Villagarcia Wanza, Horacio (Arg.) Zamarro, José Miguel (España)

V Workshop Innovación en Sistemas de Software - WISS -

ID

Trabajo

Autores

5673

Gestión del Conocimiento: Un enfoque aplicado en la Administración Pública

Sebastián Pardo (HTC-GBA), Juan Enrique Coronel (HTC-GBA), Rodolfo Bertone (UNLP), Pablo Thomas (UNLP)

5735

Aplicación de los condicionales DHD en la herramienta del foro de Sakai

Alejandro Sartorio (CIFASIS), Marcelo Vaquero (UAI), Guillermo Rodriguez (CIFASIS), Daniel Tedini (UAI)

5736

Framework para Interfase Cerebro Computadora implementado para el control de artefactos en el contexto de la domótica

Jorge Ierache (UM), Gustavo Pereira (UM), Juan Iribarren (UM), Enrique Calot (UBA)

5761

Una aplicación de la Wikimedia Semántica

Marcela Vegetti (UTN), Horacio Leone (UTN)

5772

Applying EDON Methodology and SBVR2OWL Mappings for Building an Ontology-Aware Software

Cecilia Gaspoz (UTN-FRSF), Valeria Bertossi (UTN-FRSF), Emiliano Reynares (UTNFRSF), María Laura Caliusco (UTNFRSF)

5778

Propuesta de tecnología móvil para la administración de información vinculada a la gestión de espacios áulicos

Martín S. Martínez (UNNE), Sonia Mariño (UNNE), Pedro Luis Alfonzo (UNNE), María V. Godoy (UNNE)

5827

Desarrollo de aplicaciones colaborativas para Cloud Computing

María Antonia Murazzo (UNSJ), Nelson R. Rodriguez (UNSJ), Daniela A. Villafañe (UNSJ), Daniel Gallardo (UNSJ)

5794

“ASLX”: Semantic Analyzer for programming languages based on XML

Yanel Buffa (UNRC), Franco Gaston Pellegrini (UNRC)

V Workshop Innovación en Sistemas de Software - WISS -

ID

Trabajo

Autores

5808

Sistema Guía para Personas con Deficiencia Visual

Pablo Richard (UNCa), Daniel Richard (UNCa), Marcos Aranda (UNCa)

5812

Automatización en la Captura de Datos para el Modelado de Flujo Vehicular

Julio Monetti (UTN-FRM), Mariana Brachetta (UTN-FRM), Oscar León (UTNFRM)

5887

Planeamiento Estratégico para Compartir Información en la Administración Pública

Ignacio Marcovecchio (UNS), Elsa Estevez (UNN), Pablo Rubén Fillottrani (UNS)

5824

Ciber-adicciones: Estudio del Comportamiento Poblacional por Simulación

L. Montesano (UTN-FRBA), Maria Florencia Pollo Cattaneo (UTN-FRBA), Ramon Garcia Martinez (UNLA)

5846

Software e innovación: desarrollando productos con hardware y software flexible

Daniel Díaz (UNSJ), Sandra Oviedo (UNSJ), Leandro Muñoz (UNSJ), Francisco Ibáñez (UNSJ)

5848

Un Marco de Trabajo para la Integración de Arquitecturas de Software con Metodologías Ágiles de Desarrollo

Luis Vivas (UNRN), Mauro Cambarieri (UNRN), Marcelo Petroff (UNRN), Horacio Muñoz Abbate (UNRN), Nicolás García Martinez (UNRN)

5888

Herramienta de gestión de trazabilidad de requerimientos en proyectos de software</td>

Alfredo Villafañe (UNNE), María de los Ángeles Ferraro (UNNE), Yanina Medina (UNNE), Cristina Greiner (UNNE), Gladys N. Dapozo (UNNE), Marcelo Estayno (UNLZ)

Gestión del Conocimiento: Un enfoque aplicado en la Administración Pública Sebastián Pardo1, Juan Enrique Coronel1, Rodolfo Bertone2, Pablo Thomas2 1

Honorable Tribunal de Cuentas de la Provincia de Buenos Aires – Argentina 2

Instituto de Investigación en Informática LIDI - Facultad de Informática Universidad Nacional de La Plata - Argentina {spardo, jcoronel} @htc.gba.gov.ar {pbertone, pthomas}@lidi.info.unlp.edu.ar

Abstract. La Gestión del Conocimiento abarca al conjunto de actividades realizadas con el fin de utilizar, compartir y desarrollar el conocimiento de una organización y de los individuos que en ella trabajan, encaminándolos a la mejor consecución de sus objetivos. En este trabajo se presenta un enfoque de estudio de Gestión del Conocimiento y se efectúa, a su vez, un análisis de la Gestión del Conocimiento aplicada en diferentes ámbitos de la Administración Pública. A modo práctico, se ha desarrollado una herramienta de software que promueve la Gestión del Conocimiento, la cual se implantó de manera concreta en un Organismo Público, el Honorable Tribunal de Cuentas de la Provincia de Buenos Aires (HTC). Aplicar las teorías de Gestión del Conocimiento permitir visualizar, compartir y utilizar de diversas maneras los recursos no tangibles existentes, en pos del progreso y modernización de las Organizaciones Públicas.

Keywords: Gestión del Conocimiento - Unidad de Información - Honorable Tribunal Cuentas Provincia Buenos Aires - Gobierno Electrónico.

1 Introducción Conocimiento es aquello que permite tomar decisiones y actuar [1]. Puede definirse la Gestión del Conocimiento como el conjunto de actividades realizadas con el fin de utilizar, compartir y desarrollar el conocimiento de una organización y de los individuos que en ella trabajan, encaminándolos a la mejor consecución de sus objetivos [2].

La Gestión del Conocimiento genera recursos para las organizaciones, el denominado capital intelectual, como elemento intangible y perdurable para una gestión eficiente y sostenible en el tiempo. Mediante la Gestión del Conocimiento las organizaciones favorecen que el individuo se desarrolle en su trabajo aportando ideas, y al mismo tiempo se evita la fuga de conocimiento cuando las personas abandonan la organización. Este concepto de retención del conocimiento tácito o inconsciente representa una innovación en el campo de la administración y se hace imprescindible en la actualidad.

1162

Es necesario enfocarse en la necesidad de Estados inteligentes y eficientes: relacionar y unificar criterios, descubriendo que en la administración pública hay consumidores de servicios (ciudadanos), competencias y proveedores, como así también regionalizaciones y necesidades de integración entre todos esos componentes.

El objetivo propuesto en este trabajo es el desarrollo de una plataforma informática colaborativa, que permita la gestión sistematizada de Unidades de Información en el Honorable Tribunal de Cuentas de la Provincia de Buenos Aires.

La innovación de la plataforma consistirá en incorporar en el diseño los conceptos de participación y Gestión del Conocimiento a través de la interrelación de las Unidades de Información, como así también permitir al usuario la ponderación de cada Unidad de Información, la generación de comentarios relacionados con la unidad en cuestión, enlaces a sitios web y referencias bibliográficas.

A continuación se presenta un enfoque conceptual de la Gestión del Conocimiento, posteriormente se describe la Gestión del Conocimiento en la administración pública, y luego se presenta el sistema de software desarrollado para el HTC. Finalmente se detallan resultados obtenidos, conclusiones y trabajo futuro.

2 Gestión del Conocimiento: un enfoque conceptual

2.1 El Conocimiento y las Organizaciones Davenport y Prusak establecieron una distinción entre tres conceptos: dato, información y conocimiento [6]. Los datos son la mínima unidad semántica, y se corresponden con elementos primarios de información que por sí solos son irrelevantes como apoyo a la toma de decisiones.. La información se puede definir como un conjunto de datos procesados y que tienen un significado (relevancia, propósito y contexto), y que por lo tanto son de utilidad para quién debe tomar decisiones, al disminuir su incertidumbre. El conocimiento es una mezcla de experiencia, valores, información y know-how que sirve como marco para la incorporación de nuevas experiencias e información, y es útil para la acción. Se origina y aplica en la mente de los conocedores [3].

Desde la perspectiva de la Gestión del Conocimiento, uno de los aspectos de la epistemología de mayor relevancia es el del proceso de generación y adquisición de conocimiento.

Davenport y Prusak definen al conocimiento como una mezcla fluida de la experiencia acumulada, los valores, la información contextualizada y la intuición del experto que crea un marco de referencia para la evaluación, y la incorporación de nuevos aprendizajes y de información. Dentro de las organizaciones, el conocimiento se encuentra inmerso en los repositorios, pero también en los procesos organizacionales de rutina, en sus prácticas y en sus normas [4].

Nonaka y Takeuchi generaron un desarrollo conceptual donde el conocimiento se crea realmente cuando los tipos de conocimiento se convierten entre sí y de uno a otro, a través de los niveles organizacionales, comenzando en el individuo y

1163

ascendiendo al ámbito grupal, organizacional e ínter organizacional, creándose una espiral que produce la innovación no sólo en productos y tecnologías, sino también en procesos y estrategias organizativas [5]. Este enfoque configura el pensamiento dominante sobre el tema en la actualidad.

2.3 Metas, Objetivos y Pilares para la Gestión del Conocimiento La meta primaria de la Gestión del Conocimiento se define como la mejora de las prestaciones organizativas por la captación de los individuos para obtener, compartir y aplicar conocimiento colectivo para tomar decisiones óptimas en tiempo real, entendiéndose este último como el tiempo disponible para tomar la decisión y ejecutar la acción que afectará materialmente el resultado.

En cuanto a los objetivos, pueden enumerarse los siguientes: 1. Hacer que las instituciones en general y empresas en particular actúen tan inteligentemente como sea posible para asegurar su viabilidad y éxito global.

2. En otro caso, darse cuenta del mejor valor de sus activos de conocimiento.

Para alcanzar estas metas, las organizaciones construyen, transforman, organizan, despliegan y suman efectivamente activos de conocimiento [6].

Un sistema de Gestión del Conocimiento debe conjugar tres pilares fundamentales para la gestión:  El personal y la cultura.  La gestión institucional.  La tecnología. (portales, Groupware, herramientas de comunicación electrónica, almacenes de datos y minería de datos, y la infraestructura de soporte).

3 Gestión del Conocimiento en la administración pública Resulta útil distinguir los conceptos de sociedad de la información y del conocimiento. La sociedad de la información hace referencia a la creciente capacidad tecnológica para almacenar más información y hacerla circular cada vez más rápidamente y con mayor capacidad de difusión. La sociedad del conocimiento se refiere a la apropiación crítica y selectiva de la información protagonizada por ciudadanos que saben cómo aprovechar la información [7]. Sobre la base de estas sociedades se cimientan las instituciones públicas.

Puede afirmarse que las instituciones públicas son grandes productores y consumidores de conocimiento. Al contrario de lo que ocurre con la empresa privada, la administración no tiene que preocuparse de la rentabilidad sino que debe prestar especial atención a dos aspectos esenciales [1]: • Ser altamente eficiente en recaudar y gastar adecuadamente los recursos.

• Mejorar la calidad de vida de sus ciudadanos mediante los servicios especializados que prestan.

Sin embargo, para lograr dichos objetivos, las instituciones públicas tienen a su vez graves problemas para abordar otros dos aspectos:

1164

1. Precisar con detalle los resultados que prometen obtener, y más en concreto, los indicadores de gestión que dan cuenta de su cumplimiento.

2. Determinar cuál es el conocimiento crítico que mayor impacto tiene en el logro de dichos resultados.

Además existen los factores políticos tales como: • Problemas internos: autoritarismo, corrupción, desigualdades sociales, ineficiencia, insuficiente organización de las instituciones públicas, entre otros.

• Problemas externos: centralización institucional de los Gobiernos, leyes y regulaciones que limitan los municipios y estados, cuestiones políticopartidarias relacionadas a aspectos presupuestarios, entre otros.

Las organizaciones públicas son básicamente organizaciones del conocimiento y para cumplir con su rol, la materia prima con la que trabajan es básicamente información, y el servicio que entregan al cliente es conocimiento depurado. Puede afirmarse que en la actualidad la inmensa mayoría de organizaciones carecen de una estrategia definida para gestionar su activo primordial [8].

4 Sistema de Software para la Gestión del Conocimiento en el ámbito de la Administración Pública de la Pcia. de Bs. As.

4.1 Contexto de Aplicación El Honorable Tribunal de Cuentas de la Provincia de Buenos Aires (HTC) es un Organismo Constitucional. Sus atribuciones, tipificadas en la ley provincial N° 10869 (Orgánica del Tribunal de Cuentas), son [9]: 1) Examinar las cuentas de percepción e inversión de las rentas públicas, tanto provinciales como municipales, aprobarlas o desaprobarlas y en este último caso, indicar el funcionario o funcionarios responsables, como así también el monto y la causa de los alcances respectivos.

2) Inspeccionar las oficinas públicas provinciales o municipales que administren fondos públicos, y tomar las medidas necesarias para prevenir cualquier irregularidad en la forma y con arreglo al procedimiento que determine la Ley. 4.2 Génesis del Proyecto El HTC contaba con distintos sistemas descentralizados para el tratamiento de Doctrinas, Jurisprudencias y Fallos, temas específicos que son atendidos por las Secretarías Jurídica, de Consultas y General respectivamente, dependientes de la Presidencia del Organismo. Estos sistemas se encontraban implementados en lenguajes de programación obsoletos, con motores de bases de datos de distintas tecnologías, cuyos ciclos de vida tecnológicos ya habían finalizado. Por ejemplo, existían tres implementaciones desarrolladas en Visual Basic 6, cuyo soporte finalizó

1165

en 2005 y fue extendido hasta 2008. En cuanto a las bases de datos, se presentaban implementaciones en Microsoft Sql Server 7 y Microsoft Access.

Estas implementaciones requerían un constante mantenimiento correctivo, como así también se presentaban nuevos requerimientos funcionales acordes a las necesidades tecnológicas actuales, como por ejemplo la centralización y catalogación de publicaciones, agilidad en la carga y estadísticas.

Los requerimientos e inquietudes de los usuarios comenzaron a surgir con fuerza, sumándose a la necesidad de cambio propia de la dinámica de un área de sistemas.

Esto motivó un relevamiento inicial y una tormenta de ideas, contemplándose dos alternativas de solución: 1. Solución Convencional: generar un nuevo sistema o módulo para cada secretaría, según prioridades a analizar. Esta solución continuaría con el paradigma descentralizado de la información del organismo.

2. Solución basada en Gestión del Conocimiento: generar un sistema que, a partir de relevar específicamente los requerimientos de las secretarías, presente una solución integrada para una gestión sistematizada de todas las publicaciones, basándose en los principios de la Gestión del Conocimiento. Esta solución requiere atender un análisis integral de las secretarías, su funcionamiento, flujo de información, necesidades y propuestas, así como también un relevamiento y análisis de fortalezas, oportunidades, debilidades y amenazas de los sistemas ya implementados, con el fin de receptar y aprovechar las experiencias anteriores.

Técnicamente, implementar un sistema de este tipo demanda un grado de demora mayor para la puesta en producción, debido a las dificultades naturalmente derivadas de la unificación de criterios y requisitos, mayores tiempos de análisis, y dificultades para la implementación de sistemas genéricos.

En ambos casos se debe migrar toda la información posible desde los sistemas obsoletos hacia las nuevas implementaciones.

A partir de un análisis final, se resolvió implementar la segunda solución, atendiéndose los costos que demanda una solución integral.

4.3 Summun: solución integral y basada en Gestión del Conocimiento Summun, el producto de software desarrollado, se define como una herramienta de construcción participativa, transversal, escalable y fundacional de una estrategia de inteligencia y aprendizaje organizacional [10]. Para el desarrollo se utilizó tecnología "Symfony 2", como un framework basado en software libre y diseñado para optimizar el desarrollo de las aplicaciones web basado en el patrón MVC (Modelo, Vista, Controlador).

Para la base de datos se definió un modelo de datos orientado a objetos, y se utilizó el DBMS MySql, a través del ORM de Doctrine, el cual permite asociar objetos a una base de datos relacional [12].

4.4 Fases de Desarrollo Se definieron 3 fases de desarrollo:

1166

Fase I: "Gestión Individual de Unidades de Información" Esta fase define lo que se denomina “Unidad de Información” (UI) que consiste en el componente básico o primario de Información a gestionar por el sistema. La gestión abarca las Altas, Bajas, Modificaciones, Búsquedas Simples y Avanzadas, Manejo de Estados(Borrador, Cargado, Visado, Acceso Interno, Acceso Público), Palabras Claves, Sectorización de Usuarios (carga y visado) y Trazabilidad de Doctrinas, Jurisprudencias, Fallos Judiciales, Fallos del Tribunal de Cuentas y Normativas. Las Unidades con estado “´Acceso Público” deben ser posibles de ser accedidas por el público en general a través del sitio web del organismo.

Fase II: "Gestión Participativa y Construcción de Conocimiento" En esta fase se hacen explícitos los conceptos de Gestión del Conocimiento. Se incluyen elementos como [10]: • Relaciones: permiten vincular unidades de diversos modos.

• Enlaces Externos: permiten vincular una unidad con uno o más hipervínculos.

• Referencias bibliográficas: consisten en citar de la manera más detallada posible referencias en libros, manuales, tratados, cartillas o cualquier otro tipo de compendio físico que se halle disponible en el organismo.

• Comentarios: se trata de un campo texto, en el que cualquier usuario registrado puede dejar comentarios, que permitan acrecentar el valor de la unidad.

Fase III: “Gestión Integrada” La tercera fase eleva el nivel de complejidad y planea generar “digestos” que integren diferentes UI para fines específicos. Pueden darse implementaciones vinculadas con la gestión de calidad del Honorable Tribunal de Cuentas.

4.5 Implementación de Summun En la página de inicio, presentada en la figura 1, se visualiza un panel de control donde se muestran datos estadísticos y, asimismo, información concerniente a las UI más recientemente utilizadas. La “Unidad de Información” consiste en el componente básico o primario de información a gestionar por el sistema. La gestión de las UI representa el alimento de datos de este software, la fuente de información que luego proveerá a los futuros sistemas para la toma de decisiones, soportados en Summun.

El Panel de Control introduce una innovación en el campo de los Sistemas informáticos del HTC. Se incorpora este concepto al desarrollo del software, el cual consiste en concentrar en una sola página y en tiempo real todos los aspectos que se consideran importantes en la gestión. Se presenta como una herramienta ejecutiva y de gestión que muestra información importante de manera centralizada.

Puede encontrase elementos tales como: Últimas unidades cargadas, Gráfico comparativo de cantidades, Ranking de Unidades más Visitadas, Unidades Creadas, Ranking de Usuarios Creadores y Listado de Marcadores.

Summun presenta en su menú de UI un listado con las distintas unidades a gestionar, a saber: Jurisprudencia, Doctrina de Consultas, Doctrina de Jurídicas, Fallos del HTC y Normativas.

1167

Figura 1: Pantalla inicial de Summun El estilo de diseño de todos los tipos de UI respeta el mismo concepto, y es el de presentar una pantalla con todas las unidades de información correspondiente al tipo de unidad en cuestión, y un conjunto de funcionalidades representadas en la figura 2:

Figura 2: Módulo de ABM de Doctrina de Consultas Para el ejemplo, se cuenta con una página principal organizada de modo tal de mostrar en forma de grilla las unidades de información disponibles y sus características, como así también el agrupamiento de un conjunto de acciones para cada unidad. Además se dispone de accesos para efectuar búsquedas.

Summun incorpora en su diseño de conceptos de “Participación” y “Gestión del Conocimiento”. Esto último se logra a partir de interrelacionar las UI y permitir operatoria vinculada con la definición de Gestión del Conocimiento tal como lo son las ponderaciones, comentarios, relaciones y referencias.

Esta combinación de carga de datos, relaciones, comentarios y referencias, logran un círculo virtuoso para la Gestión del Conocimiento del Honorable Tribunal de Cuentas que se soporta en el sistema informático presentado, respetando la definición.

Cada Unidad de Información posee características propias relacionadas con la Gestión del Conocimiento.

1168

La funcionalidad de Gestión del Conocimiento permite acceder a una interfaz de consulta de todo lo inherente a la Gestión del Conocimiento vinculado a la Unidad. A modo de integración, se presenta en las figuras 3 y 4 la funcionalidad de Gestión del Conocimiento asociada a una unidad.

Figura 3: Enlaces y Relaciones de una UI

Figura 4: Comentarios, Referencias y Ponderación de una UI En las figuras pueden visualizarse los enlaces, relaciones, comentarios y referencias bibliográficas, aspectos ligados al menú de Gestión del Conocimiento.

Este concepto está implementado dentro del contexto de la etapa 2 de Summun. Se subdivide en cuatro funcionalidades, cada una de las cuales construye la idea de relaciones, comentarios, enlaces y referencias, como principios claves para la Gestión del Conocimiento en el Honorable Tribunal de Cuentas.

Además se permite ponderar a la Unidad de Información según su utilidad, confiabilidad y completitud. La ponderación es un concepto inspirado en las evaluaciones de Wikipedia, y permite a futuro generar un panel de control donde puedan incluirse rankings con las “mejores” unidades de información de acuerdo a cada criterio.

1169

5 Resultados Obtenidos A partir del desarrollo de un módulo especial, se migraron unidades documentales y archivos físicos con una efectividad cercana al 100%; exactamente 14.504 Unidades de Información obtenidas de sistemas de gestión de bases de datos PostgreSQL, SQL Server y MySql. En 6 meses de utilización del sistema se cargaron aproximandamente 800 Unidades, lo que resalta la importancia de la migración en cuanto a volumen de datos.

Al 3 de Julio de 2013, se registraron 14756 visitas públicas y 1087 de uso interno, lo que refleja el alto grado de participación por parte de la sociedad.

El HTC posee la certificación ISO 9001:2008, la cual contempla la implementación de “No Conformidades” como instrumento para que los usuarios puedan evidenciar incumplimientos de requisitos. Al 3 de Julio de 2013 no existen No Conformidades vinculadas al Sistema Summun.

Asimismo la Dirección de Sistemas posee un software de soporte para que los usuarios envíen sus problemas técnicos, necesidades, requerimientos u opiniones. A partir del gestor IT y los registros de asistencia telefónica al usuario, en la figura 5 se presenta las solicitudes y su distribución, al 12 de Marzo del 2012:

Figura 5: Distribución de Solicitudes al 12 de Marzo de 2012

6 Conclusiones La Gestión del Conocimiento es una disciplina, no una tecnología que se pueda comprar y vender. Es una interacción que se produce entre procesos, personas y organizaciones, con la ayuda de la tecnología que le brinda soporte. Que esto resulte exitoso en una organización requiere de una cultura organizacional moderna, impulsada desde la dirección, que favorezca un ambiente estimulante para la colaboración, y a su vez brinde los métodos y herramientas para que sus miembros puedan compartir de manera eficiente su conocimiento explícito.

Para este trabajo, el enfoque está dado en el estudio de la Gestión del Conocimiento en la administración pública. Al respecto, se concluye que si bien las organizaciones públicas no deben preocuparse por su rentabilidad, sí deben hacerlo

1170

por ajustarse a presupuestos y recaudaciones, y por sobre todo en superar problemas relacionados con factores del entorno y políticos.

Como caso práctico, se expuso el desarrollo de la Herramienta “Summun”, sobre la cual se concluye que es un proyecto ambicioso pero a la vez realista y práctico, con metas que se fueron cumpliendo y resultaron en un sistema informático de carácter transversal al HTC. Se introdujo un concepto innovador: Gestión del Conocimiento; destacándose y difundiéndose sus ventajas a través de la capacitación; y llevado a modo práctico a través de Summun.

Para finalizar, puede afirmarse que la Gestión del Conocimiento debe implementarse como política de estado, entendiendo la importancia de la innovación tecnológica y conceptual, como la base indispensable sobre la que deben sustentarse las políticas públicas, fomentando la eficacia, equidad y transparencia en la gestión.

7 Trabajo futuro La experiencia de los usuarios derivó en la necesidad de poseer un buscador integral que se abstraiga de la UI. Es decir, el buscador debe localizar palabras claves indistintamente del tipo de unidad, y mostrar todos los datos en una misma pantalla.

Se contempla el análisis y desarrollo de la etapa 3, planificando la generación de “digestos” que integren diferentes unidades para fines específicos. También vincular Summun con aspectos relacionados directamente con la gestión de calidad del Honorable Tribunal de Cuentas.

Finalmente se pretende lograr recomendaciones para el usuario, sustentadas en algoritmos del tipo “Acercamiento al vecino más cercano”, actualmente aplicado en sitios como Amazon, Netflix, Reddit, entre otros [11].

Referencias 1. Catenaria, http://www.catenaria.cl/img/pdf/conocimiento.pdf 2. BusteloRuesta, Amarilla, Iglesias:Gestión del Conocimiento y Gestión de la Información.

INFORAREA S.L., año VIII, n. 34. 2001 3. Seminario USAC, http://seminario1usac.wordpress.com/2011/05/08/business-intelligence/ 4. Moore, Bresó Bolinches: El desarrollo de un sistema de gestión del conocimiento para los institutos tecnológicos.Revista Espacios, Vol.22. 2001 5. Lopez,Cabrales,Schmal: Gestión del Conocimiento: Una Revisión Teórica y su Asociación con la Universidad.Universidad de Talca, Chile.2005 6. Del Moral Bueno, Anselmo y otros: Gestión del Conocimiento. Paraninfo.2007 7.

Wikipedia, Sociedad de la Información y del Conocimiento, http://es.wikipedia.org/wiki/Sociedad_de_la_informaci%C3%B3n_y_del_conocimiento 8. Rabinovitch, Jonas: Gestión del Conocimiento y Gobierno Electrónico: Mitos y Realidades.

Departamento de Asuntos Económicos y Sociales (ONU), UNDESA, Noviembre 2009 9. Gob Prov. De Bs. As., http://www.gob.gba.gov.ar/legislacion/legislacion/l-10869.html 10. Flores,Coronel,Pardo, Groizard: “Summun. Conocimiento Organizacional”. Presentación en Honorable Tribunal de Cuentas de La Provincia de Buenos Aires.2012 11. Wikipedia, Sistema Recomendador, http://es.wikipedia.org/wiki/Sistema_recomendador 12. Databases and Doctrine, http://symfony.com/doc/current/book/doctrine.html

1171

Aplicación de los condicionales DHD en la herramienta del foro de Sakai Alejandro R. Sartorio 1,2 Marcelo A. Vaquero 2 Guillermo Rodriguez 1,2 Daniel Tedini 2 1

Centro Internacional Franco Argentino de Ciencias de la Información y de Sistemas, CIFASIS (CONICET-UNR-UPCAM), Bv. 27 de febrero 210 bis, 2000 Rosario, Argentina 2 Centro de Altos Estudios en Tecnología Informática, CAETI, Universidad Abierta Interamericana, Sede Rosario, Ov. Lagos 944, 2000 Rosario, Argentina {Sartorio, Guille}@fceia.unr.edu.ar, {Marcelo.Vaquero, Daniel.Tedini}@uai.edu.ar Resumen. En este trabajo se brinda la información necesaria de la aplicación de un modelo de condicionales de la infraestructura de los contratos sensibles al contexto para el Dispositivo Hipermedial Dinámico (DHD). Partiendo de la implementación tecnológica en el entorno colaborativo SAKAI se muestra una forma de adaptar los servicios de la herramienta foro a la información de contexto de los usuarios. De esta manera, se describen un diseño general de integración para ser utilizado en implementaciones de cualquier tipo de condicionales para los DHD. Palabras Clave: Coordinación de Contratos – Sistemas sensibles al contexto – Dispositivo Hipermedial Dinámico – TIC.

1 Introducción El actual contexto físico-virtual que se construye a partir de la utilización de las Tecnologías de la Información y Comunicación (TIC) posibilita a los sujetos ser partícipes de redes sociotécnicas conformadas por una multiplicidad de componentes y relaciones, que se configuran y reconfiguran por las diversas interacciones en función de una gran diversidad de requerimientos. En este sentido, el Programa interdisciplinario de I+D “Dispositivos Hipermediales Dinámicos” [1], radicado en CIFASIS (CONICET-UNR-UPCAM), estudia la complejidad evidente de las mencionadas redes, integrando aportes de diversas disciplinas como informática, educación, ingeniería y psicología, entre otras.

Se conceptualiza como Dispositivo Hipermedial Dinámico (DHD) [2] a la red heterogénea conformada por la conjunción de tecnologías y aspectos sociales que

1172

posibilitan a los sujetos realizar acciones en interacción responsable con el otro para investigar, aprender, dialogar, confrontar, componer, evaluar, bajo la modalidad de taller físico-virtual, utilizando la potencialidad comunicacional, transformadora y abierta de lo hipermedial, regulados según el caso, por una “coordinación de contratos” [3].

Funcionalmente, el DHD es conceptualizado como sistema complejo [4], en el cual los participantes realizan acciones de participación mediadas por diversas tecnologías. Estas interacciones se efectúan por medio de servicios provistos por herramientas específicas agrupadas según el espacio colaborativo utilizado. Además, se busca que los efectos de dichas acciones estén condicionados por la información de contexto de los participantes que la involucran.

Para esto, tecnológicamente el DHD está provisto por el agregado de una pieza de software diseñada para la inyección de propiedades de coordinación de contratos sensibles al contexto [5]. Esta propiedad se logra a través de la implementación de contratos [6] con mecanismos de coordinación y componentes de sistemas sensibles al contexto [7].

La utilización de reglas es parte esencial en la implementación de las acciones que contienen los contratos y las tareas de coordinación. A su vez, las estructuras de las reglas contienen condicionales donde se establece parte de la lógica de adaptación a los requerimientos funcionales del los DHD. En este trabajo se retoman los tres tipos de condicionales lógicos diseñados con el propósito de representar valores de verdad que dependan de la información de contexto de usuarios [19]. De esta manera se pretende diseñar una estructura conceptual que permita implementar estos condicionales en el marco tecnológico del DHD. Tras esta introducción, en la sección 2 se identifican los elementos tecnológicos del DHD teniendo en cuenta su relación con los condicionales. Luego, en la sección 3, se presentan los tres tipos de condicionales con sus principales características y modelos de integración dentro del framework SAKAI (http://www.sakaiproject.org) [8]. En la sección 4 se describe un modelo conceptual genérico de condicionales junto a un ejemplo de integración. Por último, en la sección 5 se presentan las principales conclusiones generales.

2. El uso de contratos en el DHD El uso de contratos en el DHD parte de la noción de Programación por Contrato (Programming by Contract) de Meyer [6] basada en la metáfora de que un elemento de un sistema de software colabora con otro, manteniendo obligaciones y beneficios mutuos. En nuestro dominio de aplicación consideraremos que un objeto cliente y un objeto servidor “acuerdan” a través de un contrato, representado con un nuevo objeto, que el objeto servidor satisfaga el pedido del cliente, y al mismo tiempo el cliente cumpla con las condiciones impuestas por el proveedor. De esta manera, las decisiones de comportamiento de los servicios se verán influenciadas por el valor de verdad de las instancias de los condicionales que integren al contrato.

1173

Como ejemplo de la aplicación de la idea de Meyer [9] en nuestro dominio de tecnologías de la información y comunicación planteamos el escenario en que: un usuario (cliente) utiliza un servicio de edición de mensajes (servidor) a través de un contrato que garantizará las siguientes condiciones: el usuario debe poder editar aquellos mensajes que tiene autorización según su perfil (obligación del proveedor y beneficio del cliente); el proveedor debe tener acceso a la información del perfil del usuario (obligación del cliente y beneficio del proveedor).

A partir de la conceptualización de contratos se propone una extensión por medio del agregado de nuevas componentes para instrumentar mecanismos que permitan ejecutar acciones dependiendo del contexto. En aplicaciones sensibles al contexto, el contexto (o información de contexto) es definido como la información que puede ser usada para caracterizar la situación de una entidad más allá de los atributos que la definen. En nuestro caso, una entidad es un usuario (participantes, coordinadores, etc.), lugar (casa, universidad, parque, etc.), recurso (impresora, fax, etc.), u objeto (archivos de texto, fotos, videos digitales, etc.) que se comunica con otra entidad a través del contrato.

En [9] se propone una especificación del concepto de contexto partiendo de las consideraciones de Dourish [10] y adaptadas al dominio de las tecnologías de la información y comunicación, que será el punto de partida del actual trabajo. Contexto es todo tipo de información que pueda ser censada y procesada, a través de una aplicación, que caracteriza a un usuario o entorno, por ejemplo: intervenciones en foros, participaciones en wikis, habilidades, niveles de conocimientos, direcciones ip conectadas, cantidad de usuarios conectados, fechas y horarios, etc.

En términos generales, la coordinación de contratos es una conexión establecida entre un grupo de objetos influidas por condicionales que representan parte de la lógica de adaptación. Cuando un objeto cliente efectúa una llamada a un objeto servidor, el contrato “intercepta” la llamada y establece una nueva relación teniendo en cuenta el contexto del objeto cliente, el del objeto servidor, e información relevante adquirida y representada como contexto del entorno. Los condicionales de las reglas representarán diferente tipo de información de contexto con distinto grado de representación y abstracción, donde se requieren mecanismos de inferencias basados en la recolección, representación y simulación.

A través de un diagrama UML se definen las clases utilizadas en la implementación de los condicionales dentro de las reglas de los contratos. La Figura 1 describe los elementos y relaciones relevantes en la compocisión de condicionales.

1174

Fig.1. Elementos y relaciones relevantes en la creación de condicionales.

Dentro del mecanismo de configuración de condicionales, el contrato presenta en su interfaz métodos para la ordenación de acciones y reglas; además de las que cubren las propiedades inherentes a la definición original de contrato sobre la configuración de pre-condiciones, post-condiciones e invariantes. De esta manera se representa a las reglas anteriormente mencionadas como una clase de agregación del contrato. Así se determina una nueva clase para la representación de los condicionales. Las reglas contienen referencias a las acciones de los contratos por medio de la interfaz acciones.

Se decide representar a los condicionales como objetos de primera clase con el propósito de establecer un nuevo grado de abstracción que permitirá conectar a los contratos a subsistemas externos que le proporcionen nuevos mecanismos de adaptabilidad, dinamismo e interpretación.

De esta manera, teniendo en cuenta las experiencias de diseño e implementación del uso de condicionales [11] [12] [13] se extienden al objeto condicional en tres tipos diferentes. Cada uno de ellos hereda la interfaz Condicional, encargada de establecer las presentaciones para el tipo de dato necesario en las reglas.

El primer paso, es lograr la construcción de las reglas del contrato y que los condicionales representen criterios de decisiones sobre aspectos relevantes de los procesos didácticos, investigativos, de producción y/o de gestión mediatizados por un DHD; por ejemplo: un participante puede adquirir un servicio determinado de una herramienta a partir de la evaluación de una condición representada como condicional de una regla.

En general, a estas reglas debemos diseñarlas con el cuidado de no incorporar redundancias, ambigüedades o incoherencias; tanto entre las propias reglas de un contrato como con otras reglas implícitas que se desprenden de los servicios.

Entonces, definimos a las Reglas del contrato como un conjunto de condiciones, acciones y prioridades. La condición es un expresión booleana sobre relaciones (mayor, menor, igual, distinto, etc.) entre parámetros y valores concretos. Las acciones conforman un conjunto de asignaciones de valor a otros parámetros también definidos por el tipo de regla. Algunos de los parámetros de las acciones deben ser “métodos de cálculo” que permiten cambios en el comportamiento de los servicios en los cuales estas reglas son aplicadas. La prioridad permite simplificar la cantidad de reglas que se deben escribir: en lugar de la escritura de una regla para cada

1175

combinación de posibilidades de los valores de los parámetros, se asegura que dos reglas no puedan ser ejecutadas simultáneamente. Por ejemplo: el usuario podría escribir una prioridad baja para todas las reglas y luego con prioridades altas ir identificando las excepciones para el caso configurado inicialmente. En síntesis, las reglas son ejecutadas mediante un orden de prioridades.

Entonces, las reglas forman parte de un mecanismo de agregación encargado de la composición de diferentes tipos de condicionales: Mcondicional, MDcondicional y DEVScondicional, que se comportan de manera similar teniendo en cuenta diversos modelos de integración que explicitaremos en las secciones siguientes.

A continuación, se analizarán las estructuras de tres tipos de condicionales con el propósito de abstraer características de su conformación. En particular se identificarán tipos de elementos, patrones, sub-estructuras y relaciones que sean necesarias para la composición con los contratos.

3. Los tipos de condicionales Retomando la sección anterior y de manera general a través de los elementos utilizados en el diseño de la Figura 1 para la creación de condicionales, se identifica como la primer característica de diseño, a la estructura que define los diferentes tipos de condicionales para el DHD [16,17,18.19].

Luego, partiendo de las necesidades adaptativas de los contratos y ante determinados casos de uso, se diseñaron diferentes implementaciones de condicionales. Estas diferencias tienen que ver con cuestiones de diseño en los que algunos aspectos pueden ser generalizados, posibilitando una representación más genérica de los condicionales.

Partiendo de los avances para la implementación del modelo conceptual de [19] se propone una método de inyección del modelo en la herramienta foro del framework Sakai. De esta manera, en la Figura 2 se representa un diagrama de las principales clases que integran la herramienta original del foro. En este caso, se toma la clase BaseDiscussionMessage, que extiende las operaciones de BdDiscussionService, para reimplementar el método addDiscussionMessage() encargado de ingresar el texto de una entrada de usuario al foro. A su vez, addDiscussionMessage() usa dos operaciones de DiscussionMessageEdit que utilizan servicios bases colaborativos extendiendo la infraestructura provista por las clases Message y Edit.

1176

Fig. 2. Representación del los elementos de diseño de condicionales.

4. Inyección de los condicionalesDHD En esta sección se presenta un diseño conceptual e información necesaria para la inyección de condicionales en una herrramienta del DHD. En este caso, se propone un diseño de integración para conectar un subsistema de configuración (Calculo) para la instanciación de los condicionales de las reglas de contratos.

La Figura 3 establece el diseño propuesto para la implementación de condicionales. Se define un módulo para efectuar los cálculos finales que determinan el valor de verdad del condicional (Calculo). Otro módulo es el encargado de la recolección y toma de datos (TomarDatos), extendiéndose para los casos particulares donde es necesario contar con estructuras de datos (Estructuras) conteniendo métodos que implementan cada una de ellas.

Fig. 3. Modelo de diseño conceptual de condicionales para contratos sensibles al contexto.

Además, un módulo aparte se configura para describir todas las restricciones que

1177

debe cumplir el condicional (Restricciones), teniendo en cuenta su utilización dentro de las reglas de los contratos, con el propósito de no incurrir en contradicciones o inconsistencias en relación a las precondiciones, poscondiciones e invariantes.

Las conexiones con otros subsistemas, por ejemplo, el subsistema sensible al contexto representado, se encuentran encapsuladas en otro módulo de conexión (Conexion). De esta manera, se implementa un “callback” del método perteneciente a la interfaz de un subsistema externo.

4.1 Ejemplo En la Figura 4 se muestra un ejemplo reducido de laboratorio para sistemas web colaborativo sensibles al contexto. Para esto exponemos un diagrama de secuencia que interpreta la ejecución de una regla del contrato que utiliza uno de los tipos de condicionales respetando el diseño original a través del objeto BdDiscussionService, y el modelo conceptual de integración a través de los objetos Condicional, Metodo y TipoMetrica [19]. De esta manera queda evidenciada la ventaja de contar con un modelo de diseño que facilite la manipulación de las reglas de los contratos sensibles al contexto.

Fig. 4. Secuencia de invocación de los valores de verdad.

Luego, usaremos como referencias un fragmento de código descripto en el caso de estudio de la sección 5 de [5] para ejemplificar el impacto de esta propuesta. En este caso, se muestra que es necesario influir solamente sobre los conectores de la infraestructura de coordinación propuesta. La forma correcta de hacerlo es caracterizar la siguiente porción de código como una interfaz de conexión:

1178

public CrdPartnerRules messageEdit_rules(string texto,Student c) throws DiscussionException, CrdExFailure {return new CrdPartnerRules (this);}

Entonces, se debe agregar a esta función las siguientes lineas de códigos que posibilitarán cambiar las referencias de los condicionales de las reglas de los contratos: Integrador unIntegrador = (Integrador) nuevoItegrador(); ... unValorCondicional = unIntegrador.resultado(unDato, unCalculo); Conexion unConexion=(Conexion) generarConexion (unValorCondicional);...

InterfazConexion unInterfazConexion = (InterfazConexion) nueva;... unConexion.setConexion(unaInterfazConexion.metodoConexion());..

De esta manera se debe agregar estas líneas dentro del código fuente de la operación addDiscussionMessage() del la clase DiscussionMessage. Para este ejemplo particular, se reemplaza la línea 5. Este procedimientos se denomina inyección de condicionalesDHD y se puede aplicar en reemplazo de cualquier porción de código que representa la invocación de un servicio base [13,20] de las herramientas del framework Sakai. public DiscussionMessage addDiscussionMessage(String category, String subject, boolean draft, String replyTo,List attachments, String body) throws PermissionException { 1.

DiscussionMessageEdit edit=(DiscussionMessageEdit) addMessage(); ...

2. edit.setBody(body); 3. header.replaceAttachments(attachments); ...

4. commitMessage(edit); 5. return edit; 6. } // addDiscussionMessage

5. Conclusiones Partiendo de los avances de diseño e implementación de una infraestructura para la integración de condicionales para los contratos sensibles al contexto del DHD, se brindaron información necesaria para la inyección en el servicio base de edición que implementa la herramienta foro del framework Sakai.

Como principal aporte de este trabajo se incorpora una extensión de las propiedades de los contratos sensibles al contexto para su adaptación en la capa de servicio de un framework web colaborativo particular.

1179

Referencias 1. Programa I+D “Dispositivos Hipermediales Dinámicos”, radicado en el Centro Internacional Franco Argentino de Ciencias de la Información y Sistemas (CIFASIS: CONICET-UNR-UPCAM). http://www.mesadearena.edu.ar. Directora: Dra. Patricia San Martín.

2. San Martin, P.: Hacia un dispositivo hipermedial dinámico. Educación e investigación para el campo audiovisual interactivo. Bernal: Universidad Nacional de Quilmes Editorial.

2008.

3. Sartorio, A. y Cristiá, M.: Primera aproximación al diseño e implementación de los DHD. XXXIV Congreso Latinoamericano de Informática, CLEI 2008. 2008.

4. Gell-Mann, M.: El quark y el jaguar. Aventuras en lo simple y lo complejo. Barcelona: Tusquets. 1995.

5. Sartorio, A. and Cristiá, M.: First Approximation to DHD Design and Implementation. Clei electronic journal, Vol.12, Nº 1. 2009.

6. Meyer, B.: Applying Design by Contract. IEEE Computer Society Press, Volume 25 Issue 10. pp. 40-51. 1992.

7. Dey, A.K., Salber, D. and Abowd, G.: A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications, anchor article of a special issue on Context-Aware Computing. Human-Computer Interaction (HCI) Journal, Vol. 16 (2-4). pp. 97-166. 2001.

8. Sartorio, A.: Un modelo comprensivo para el diseño de procesos en una Aplicación ELearning. XIII Congreso Argentino de Ciencias de la Computación. CACIC 2007. 2007.

9. Sartorio, A. y San Martín, P.: Sistemas Context-Aware en dispositivos hipermediales dinámicos para educación e investigación, en San Martin, P.: Hacia un dispositivo hipermedial dinámico. Educación e investigación para el campo audiovisual interactivo.

Bernal: Universidad Nacional de Quilmes Editorial. 2008.

10. Dourish, P.: What we talk about when we talk about context. Personal and Ubiquitous Computing, Vol. 8, Nº 1. pp. 19-30. 2004.

11. Sartorio, A., Rodríguez, G. y Vaquero, M.: Condicionales DEVS en la coordinación de contratos sensibles al contexto para los DHD. XVI Congreso Argentino de Ciencias de la Computación, CACIC 2010. 2010.

12. Sartorio, A.: Los contratos context-aware en aplicaciones para educación e investigación, en San Martin, P.: Hacia un dispositivo hipermedial dinámico. Educación e investigación para el campo audiovisual interactivo. Bernal: Universidad Nacional de Quilmes Editorial.

2008.

13. Sartorio, A., Rodríguez, G. y Vaquero, M.: Investigación en el diseño y desarrollo para el enriquecimiento de un framework colaborativo web sensible al contexto. XIII Workshop de Investigadores en Ciencias de la Computación, WICC 2011. 2011.

14. Rivera, M.B., Molina, H. y Olsina, L.: Sistema Colaborativo de Revisión para el soporte de información de contexto en el marco C-INCAMI. XIII Congreso Argentino de Ciencias de la Computación, CACIC 2007. 2007.

15. Olsina, L. and Rossi, G.: Measuring Web Application Quality with WebQEM. IEEE Multimedia, 9(4). pp. 20-29. 2002.

16. Rodríguez, G.: Desarrollo e implementación de métricas para el análisis de las interacciones del Dispositivo Hipermedial Dinámico. Jornadas Argentinas de Informátic, JAIIO 2010. 2010.

17. PowerDEVS 2.0 Integrated Tool for Edition and Simulation of Discrete Event Systems.

Desarrollado por: Esteban Pagliero, Marcelo Lapadula, Federico Bergero. Dirigido por

1180

Ernesto Kofman. Disponible en: http://www.fceia.unr.edu.ar/lsd/powerdevs/index.html 18. Rodríguez, G.: SEPI-DHD: Herramienta integrada para el Seguimiento y Evaluación de los Procesos de Interactividad del DHD, en: San Martín, P. y Traversa, O.: El Dispositivo Hipermedial Dinámico Pantallas críticas: I+D+I para la Formación Superior en Crítica y Difusión de las Artes. Ciudad Autónoma de Buenos Aires: Santiago Arcos. 2011.

19. Sartorio, A., Rodriuez, G., Vaquero, M.: Hacia un diseño general de integración de condicionales para los contratos sensible al contexto del DHD. CACIC 2012. 2012 20. Dagger, D., O'Connor, A., Lawless, S., Walsh, E., Wade, V.P.: Service-Oriented E-Learning Platforms: From Monolithic Systems to Flexible Services. Internet Computing, IEEE (Volume:11 , Issue: 3 ). Page(s): 28 – 35. 2007

1181

Framework for Brain Computer Interface implemented to control devices in the context of home automation Jorge Ierache1,2, Gustavo Pereira1 , Enrique Calot2 , Juan Iribarren1 Instituto de Sistemas Inteligentes y Enseñanza Experimental de la Robótica (ISIER)1 Laboratorio de Sistemas de Información Avanzados Facultad de Ingeniería Universidad de Buenos Aires2 ISIER, Facultad de Informática Ciencias de la Comunicación y Técnicas Especiales Universidad de Morón, Cabildo 134, (B1708JPD) Morón, Buenos Aires, Argentina 54 11 5627 200 int 189 jierache@yahoo.com.ar

Abstract. This paper presents the device controlling using brain machine interface (BMI), through the development of a Framework implemented for the acquisition, configuration and control in the context of home automation.

Key words.

Domotic, Brain Machine Interface, Bio-Electrical Signal, Human

Machine Interfaces, Neuroengineering

1. Introduction In the field of emerging interfaces presents Brain Computer Interface (BMI, also known as BCI for its acronym in English), it facilitates communication between mental or cognitive functions created from the brain of a person, capturing the electrical signals to be processed, classified, and communicated with specific devices or applications. It is very interesting how applications employing BMI interfaces have increased during the last two decades [1], from controlling the lights on and off, using wheelchairs, computer control [2], movements in space [3], to video games [4]. In science the initial interest in using BMI presented since 1973 [1], among the first publication in the field of research in BMI were conducted in the nineties 1990 [5] and 1991 [6]. The application of controlling by biosignals systems, robots, applications, games and other devices, presents a new approach to open the doors for interaction between humans and computers in a new dimension, which specifically exploit electrical biopotential registered user through: the electro-myogram, the EEG and electro-oculogram, which are electrical biosignal patterns generated by muscle activity, the welcome and the user's eyes.

Researching of BMI interfaces is developed in a multidisciplinary scientific field due to their medical, electrical and electronic signal processing components, neuroscience and applications like computing, home automation to robotics and Entertainment [7]. Several papers were presented: first, they used intracranial electrodes implanted in the motor cortex of primates [8], [9]. The noninvasive’s human works used electroencephalography signals (EEG) applied to mental exercises commands, such as moving a computer cursor [10 ] , [11] based on the use of Brain- Machine Interface ( BMI ) . Millan et. al. [12] demonstrates how two people can move a robot using a simple electroencephalogram based on three recognizing mental states, which are associated with the robot command. The work Saulnier et. al. [13] focused on controlling the speed of a robot to extend its application to infer the user's stress level , and from this influence the social behavior of domestic robots , in this case a robot vacuum cleaner. The seminal work of Millan et. al. [12], used as an unique biosignal the EEG, based on two people working to give support in robot navigation , unlike the latter, our paper presents the preliminary result using a BMI of low cost, used in works like Saulnier et . al. [13] which includes the biosignals for the electroencephalogram, electro-oculogram and electromyogram. Unlike Saulnier’s et. al. [13] work , which

1182

implements a speed control based on electromyogram and infers the state of stress of the user through the electroencephalogram , our initial work focused on executing commands using a NIA BMI [14] to navigate of a robot [15] and is currently in the control of artifacts in the context of home automation. [16]. Control devices , moving robots or facilitate the implementation of devices for disabled without applying manual controls and gain control only through mental activity fascinated researchers, while achieving a plasticity with a BMI of time required by the user, on our experiences to facilitate employment to a user with minimal training was developed for auto focus control [15] in order that the Lego NXT robot [17] is guided by the use of a BMI-NIA, to accomplish a navigation pattern, improving mental control times, slightly surpassing the manual control, in performance tests of the same navigation pattern [18] , [19] . In 2011 researchs we experience the remote controlling of a Lego NXT robot [20] via the Internet with the implementation of biosignals with NIA BMI [14]. In subsequent works [21], [22] navigation control using Emotiv's BMI navigation was developed. [23], which is detailed in the next section.

2. Non-invasive brain machine interface On biosignals, EEG is the registry of the electrical activity generated by the neurons within the brain which is obtained through the skull by the use of electrodes placed on the surface of the head. Neuronal electrical activity is composed of slow waves which originate in synaptic activity of cortical neurons. Obtaining bioelectric signals is performed on the scalp using surface electrodes, which give the name of electroencephalogram (EEG). As to the surface electrode types are distinguished the ones attached, that consist of small metal discs which are fixed with a conductive paste giving very low contact resistance. Contact also exists, consisting of small tubes of chloridized silver threaded plastic holder containing at its end a pad wetted with saline is attached to the skull with elastic bands which are connected via alligator clips. Finally we have a mesh helmet composed by electrodes attached to a elastic helmet which are more comfortable for use and have a high positioning accuracy. The Emotiv Epoc’s electrodes [23] are subject to a malleable plastic arms that ensure the proper location and have a pad soaked in a salt solution into each contact to allow conduction.

Figure Nº 1 “Electrode system 10-20”

1183

The international 10-20 electrode arrangement (Figure N º 1) is the most used and developed one in order to ensure standardization for an individual studies. The system consists of letters and numbers to identify contact points. The letters identify the lobe and the number, the location within the hemisphere. The letters F, T, C, P and O stand for frontal, temporal, central, parietal and occipital respectively, (the letter C is used to identify the central horizontal line does not refer to any lobe). Even numbers correspond to the electrodes of the right hemisphere and left odd. Z subscripts are used to identify the vertical center line of electrodes. The arrangement of the electrodes on the Emotiv Epoc helmet, fit the 10-20 system, but only fourteen contact positions are used (Figure N ° 2a) plus a pair of reference (Common Mode Sense-CMS-and Driven Right Leg-DRL-) on each side, behind the ear or above it. In addition to the electrodes, the Emotiv Epoc helmet (Figure N º 2b) contains a gyroscope consisting of two accelerometers that provide information on the movements that user performs with his head and a wireless transmitter by which links with the USB receiver connected to the computer, all powered by a rechargeable battery via USB.

Figure Nº 2a. “EMOTIV EPOC helmet electrodes”

Figure Nº 2b. “EMOTIV EPOC helmet”

From the API and the software included in the development kit, the level of contact of the electrodes, the motion of the gyroscope, the wireless signal strength and battery charge can be monitored. Emotiv Development Kit has a set of libraries that allow communication with the helmet, the API for developers and the Emotiv engine. The Emotiv engine is the base component for the detection and interpretation of the signals from the electrodes that are located in the helmet and information captured by the EEG. It is also responsible for monitoring the battery state, the intensity of the wireless signal, the record of the connection time and to train recognition algorithms for expressive and cognitive modes, subsequently applying optimizations to each of them.

1184

The Emotiv EPOC BMI (Brain Machine Interface), articulated with its SDK (Figure N ยบ 3) consists of a control panel to create the user and log the profile, it also helps to visualize the connection status of the sensors and represents different record patterns (expressive, affective and cognitive). The expressive pattern can be viewed through an avatar in which signs of facial expression (blink, wink left, wink right, look left, look right, brows move up, move eyebrows down, smile, grit your teeth) can be trained. The affective pattern verifies different moods that are happening in a certain time (concentration, instant arousal, excitement among others). The cognitive pattern allows the training of an action on the basis of a thought, on which you can train up to thirteen actions, six of which are directional movements (push, pull forward, left, right, up and down), six rotational (rotation in the direction of clockwise, counter-rotating in the direction of clockwise, rotate left, rotate right, forward, backward) and an imaginary one that is disappearing. Other tool on the SDK is the Emokey (figure Nยบ 4), which allows Emotiv to link an action with any key and thus to function as an interface to any application.

Figure Nยบ 3 SDK-Emotiv

1185

Figure NÂş 4 â&#x20AC;&#x153;Emokeyâ&#x20AC;?

3. Framework to control artifacts in the context of home automation The framework to control artifacts was implemented to allow control of devices through BMI-Emotiv [23]. Functional restrictions were raised as to implement the control with the least amount of commands to facilitate learning and control by users, in this order only two commands are used to control devices, one is dedicated to action selection (change the tv channel, change the volume, turn on or off, change the temperature, mode of air conditioning, etc.) and another is dedicated to their execution. For the integration of communications to replace the IR remote control USB-UIRT IR transceiver is used [24], which was also applied to capture the command to be incorporated into the Framework that will execute the using the BMI. In sum, through the transceiver commands will be captured from any IR home device remote control (TV, DVD player, air conditioning, etc.) then the UI allows distribution of the buttons in a more comfortable way for the user and using a friendly interface and iconography to simplify identification. Figure No. 5 shows conceptually the control application in the context of the automation.

1186

Figure N º 5 “Application automation with Emotiv/USB-UIRT”

Developed Framework will facilitate disabled persons to control devices, as well as the interaction and control of such users with remote devices on site. Over these facilities a simple profile is determined for managing a device, and in first place characterize and associates the control to selecting a command based on the detection of muscle signals, in this case through a slight movement of the eyelids. Second, executing high level commands to a device, in this case worked using alpha brainwaves. The framework was developed in C#. Class diagram is presented in Figure No. 6, it consists of two sections, the first one is configuring the layout of commands where you learn (catcher) and set the IR codes of the remote control device chosen (Class Configuration) and the second one where the user interacts with the devices (Class MainForm) by USB-UIRT API Managed Wrapper [25].

Figure N º 6 “Framework class diagram”

Figure Nº 7 shows the diagram of components that make the application of the Framework, interaction with USB-UIRT interface is observed, through the MainForm class

1187

with which it develops control devices and their interaction with the Emotiv transparently controlling through biosignals. using Emokey. Finally, Serial Class converts into a plain text acquired through its Serialize method using the command to control a device that corresponds to a hexadecimal value. To execute the command applies the Deserialize method that allows recovering from the plaintext in hexadecimal command to the USBUIRT IR transmitted via the device.

Figure N º 7 “Component diagram”

In the Configuration section the user selects the button that performs the action with the possibility of building an specific layout distribution, places the button name, choose an icon that matches and then copies the hex value of the command on the remote control using the Learn button and with USB-UIRT device connected. Once finished the layout configuration, it is stored in a disk file to be recovered in future runs of the application (Figure N º 8).

1188

Figure Nº 8 “Mapping controls configuration”

The second section (MainForm) is the simplified layout display was configured in the above mentioned section and it interacts with the end user of the application. By two command executions assigned in the Emokey (move right and run) the user will select the controls and runs according to your needs (Figure Nº 9), the layout are presents only the configurated buttons, also allowing to visually distribute commands for user comfort.

Figure Nº 9 “Command Execution”

4. Conclusions and future lines of research Framework development, on the initial basis of robot control and its extension to control devices, with the ability to facilitate the capture and configuration of commands on the

1189

devices demonstrated during tests [22] a stable behavior in the devices integrated control over Emotiv BMI. Future lines of research will be implemented over extended control features as artifacts both robots infrared remote control (air conditioning, TV, and other devices), targeting both local devices and those located in remote sites by an unique cross-platform framework that integrates libraries for a lot of known devices, command profiles import and export and an assistant for training and familiarization with the Emotiv user.

5. References [1]Hamadicharef, “Brain Computer Interface (BCI) Literature- A bibliometric study”, in 10th International Conference on Information Science, Signal Processing and their Applications, Kuala Lumpur, 2010, pp. 626-629.

[2] P. R. Kennedy, R. Bakay, M. M. Moore, K. Adams, and 1. Goldwaithe, "Direct control of a computer from the human central nervous system," IEEE Transactions on Rehabilitation Engineering, vol. 8, no. 2, pp. 198-202, June 2000 [3] J. R. Wolpaw and D. J. McFarland, "Control of a two-dimensional movement signal by a noninvasive brain-computer interface in humans," Proceedings 629 of the National Academy of Sciences (PNAS), vol. 101, no. 51, pp. 17 849-17 854, December 2004.

[4] http://edugamesresearch.com/blog/tag/bci/, 2013.

[5] J. R. Wolpaw, D. J. McFarland, and G. W. Neat, "Development of an Electroencephalogrambased Brain-Computer Interface," Annals of Neurology, vol. 28, no. 2, pp. 250-251, August 1990.

[6] J. R. Wolpaw, D. McFarland, G. Neat, and C. Forneris, "An EEG-based brain-computer interface for cursor control," Electroencephalography and clinical Neurophysiology, vol. 78, no. 3, pp. 252259, March 1991.

[7] M. A. Lebedev and M. A. L. Nicolelis, "Brainmachine interfaces: Past, present and future," Trends in Neurosciences, vol. 29, no. 9, pp. 536-546, September 2006.

[8]. J. Wessberg, C. R. Stambaugh, J. D. Kralik, P. D. Beck, M. Laubach, J. K., “Real-time prediction of hand trajectory by ensembles of cortical neurons in primates,” Nature, vol. 408, pp. 361–365, 2000.

[9].M. A. L. Nicolelis, “Brain-machine interfaces to restore motor function and probe neural circuits,” Nature Rev.Neurosci., vol. 4, pp. 417–422, 2003.

[10] R. Wolpaw, D. J. McFarland, and T. M. Vaughan, “Brain-computer interface research at the Wadsworth center,” IEEE Trans. Rehab. Eng., vol. 8, pp. 222–226, 2000.

[11] J. del R Millán, “Brain-computer interfaces,” in Handbook of Brain Theory and Neural Networks, 2nd ed, M.A. Arbib, Ed. Cambridge, MA: MIT Press, 2002.

1190

[12] José Millán, Frédéric Renkensb, Josep Mouriñoc, and Wulfram Gerstnerb. Non-Invasive BrainActuated Control of a Mobile Robot by Human EEG. IEEE Trans. on Biomedical Engineering, Vol 51, June 2004.

[13] Paul Saulnier, Ehud Sharlin, and Saul Greenberg. Using Bio-electrical Signals to Influence the Social Behaviours of Domesticated Robots. HRI’09, 2009, USA.ACM 978-1-60558-404-1/09/03.

[14] http://www.ocztechnology.com/products/ocz_peripherals/nia-neural_impulse_actuator vigente julio 2013 [15] Ierache Jorge, Pereira Gustavo, Iribarren Juan, Sattolo Iris, “Robot Control on the Basis of Bioelectrical Signals” : “International Conference on Robot Intelligence Technology and Applications” (RiTA 2012) Gwangju, Korea on December 16-18, 2012. Series Advances in Intelligent and Soft Computing of Springer.

[16] Ierache., J, Pereira.,G, Sattolo., J, Iribarren Aplicación de interfases lectoras de bioseñales en el contexto de la domótica XV Workshop de Investigadores en Ciencias de la Computación 2013 Facultad de Ciencia y Tecnología Universidad Auto noma de Entre Ríos (UADER), ISBN: 9789872817961.

[17] http://mindstorms.lego.com/eng/Overview/default.aspx nxt vigente Julio 2013.

[18] Ierache, J., Dittler M., Pereira G., García Martínez R.,(2009) “Robot Control on the basis of Bioelectrical signals” XV Congreso Argentino de Ciencias de la Computación 2009, Universidad Nacional de Jujuy, Facultad de Ingeniería, ISBN 978-897-24068-3-9 ,pag 30.

[19].Ierache, J., Dittler, M. García-Martínez, R., “Control de Robots con Basado en Bioseñales”. XII Workshop de Investigadores en Ciencias de la Computación WICC 2010: Universidad Nacional de la Patagonia San Juan Bosco, Calafate, Santa Cruz, Argentina. 2010, ISBN 978-950-34-06526, pag 641 [20] Ierache., J, Pereira.,G, Sattolo.,I , Guerrero., A, D’Altto J, Iribarren,. J. Control vía Internet de un Robot ubicado en un sitio remoto aplicando una Interfase Cerebro-Máquina". XVII Congreso Argentino de Ciencias de la Computación 2011, Universidad Nacional de La Plata, Facultad de Informática, ISBN 978-950-34-0756-1, paginas 1373-1382.

[21] Ierache Jorge, Pereira Gustavo, Iribarren Juan del articulo “Demostración de los resultados en la integración de Interfases Lectoras de Bioseñales aplicadas al Control de un Robot” VII Congreso Educación en Tecnología y Tecnología en Educación 2012 Universidad Nacional del Noroeste de la Provincia de Buenos Aires. UNNOBA, 2012, demos educativas. ISBN 978-987-28186-3-0.

[22] www.facebook/isierum [23] http://www.emotiv.com/ vigente julio 2013.

[24].USB-UIRT: <http://www.usbuirt.com/> vigente Julio 2013.

[25] Jordan Zaerr USB-UIRT Managed Wrapper <https://github.com/JordanZaerr/Usb-Uirt-managedwrapper>

1191

Una aplicación de la Wikimedia Semántica Marcela Vegetti, Horacio Leone INGAR (CONICET - UTN), Avellaneda 3657, Santa Fe, Argentina {mvegetti, hleone}@santafe-conicet.gov.ar

Abstract. Ontolog es una comunidad abierta virtual que trabaja colaborativamente para impulsar avances en el campo de la ingeniería ontológica y las tecnologías semánticas. Se encuentra alojada en una plataforma wiki que no posee las características necesarias para realizar búsquedas dentro de este cuerpo de conocimientos. Asimismo, la cantidad de información almacenada y la organización de la misma dificulta el acceso por parte de personas no familiarizadas con la estructura del contenido. Este artículo presenta una propuesta que incorpora semántica a las páginas de la wiki Ontolog y, además, provee una capa que permite el fácil acceso a la información relevante, reutilizando la información almacenada.

Keywords: ICOM; wikimedia semántica; ontolog

1

Introduction

El foro ontolog1 es una comunidad abierta virtual dedicada a impulsar avances en el campo de la ingeniería ontológica y las tecnologías semánticas. Una plataforma wiki archiva las contribuciones de los miembros de la comunidad sirviendo de repositorio de conocimiento para la misma.

Una de las actividades impulsada por el foro Ontolog es la cumbre de ontologías, una serie anual de eventos que involucra a representantes de la comunidad de ontologías así como de las comunidades relacionadas con el tema elegido para la cumbre de cada año. Al igual que el resto de los proyectos del foro Ontolog, toda la información sobre las diferentes actividades que son llevadas a cabo durante cada cumbre anual son mantenidas en la infraestructura colaborativa de Ontolog.

La cantidad de información, y la forma en que está organizada, dificulta el acceso rápido a las partes más importantes de la misma para aquellas personas no familiarizadas con la estructura del repositorio. Es por esto que el comité organizador de la edición 2012 decidió que a partir de ese año debería existir, además de la información en la plataforma wiki, un sitio web que resuma la información más importante. En 2012, este desarrollo ha implicado la reescritura de parte del contenido, duplicando la información con el esfuerzo e inconvenientes que eso implica.

1 http://ontolog.cim3.net/

1192

Marcela Vegetti, Horacio Leone

2

Para evitar este inconveniente y teniendo en cuenta el objetivo que tiene Ontolog de impulsar la utilización de las tecnologías semánticas en las aplicaciones, surge la necesidad de implementar una plataforma que facilite el acceso, el reuso y la incorporación de semántica al contenido del foro Ontolog.

Para atender estos requerimientos, este trabajo presenta una propuesta, que se está implementando en una plataforma wikimedia semántica, denominada Ontolog PSMW. La ontología ICOM (Integrated Collaboration Object Model for Interoperable Collaboration Services)2 es utilizada para definir la semántica del cuerpo de conocimiento y una capa de presentación sirve de máscara a la información almacenada, proveyendo un fácil acceso a la información relevante. El resto de este artículo se organiza como sigue. La sección 2 presenta una breve descripción de la organización de la serie de cumbres de ontologías y de su contenido, así como de la tecnología de la plataforma en la que está contenida. La sección 3 describe las características de la propuesta e ilustra cómo se ha aplicado al cuerpo de conocimiento de la cumbre de ontologías 2013. Finalmente, en la sección 4 se presentan las conclusiones y trabajos futuros .

2

Cumbres de ontología. Descripción y plataforma de soporte

La serie de cumbres de ontologías se viene desarrollando como iniciativa del foro Ontolog y el NIST (US National Institute of Standards and Technology) desde el año 2006. Cada año se selecciona un tema que es discutido durante una serie de eventos que se extienden alrededor de tres meses, desde enero a abril. Estos eventos incluyen teleconferencias semanales, discusiones en línea sobre el tema elegido, así como otras actividades particulares a cada año. Cada cumbre finaliza con un simposio presencial en el que se resumen los resultados de las diferentes actividades. Además, cada año se presenta en un comunicado el mensaje de los participantes de la cumbre para la comunidad de ontologías.

El tema elegido cada año es abordado desde diferentes facetas, que son analizadas y estudiadas en distintos espacios de discusión, denominados "Tracks". Cada uno de éstos está a cargo de uno o dos coordinadores responsables. Cada track debe organizar una o más conferencias virtuales, las cuales comprenden entre 3 y 6 presentaciones cortas sobre temas dentro del alcance del mismo, seguida de una sesión de preguntas y respuestas entre participantes y panelistas invitados. Estas reuniones virtuales están soportadas por una audio conferencia y una sala de chat. Todo el proceso de la cumbre es coordinado por un comité organizador integrado por los responsables de las diferentes actividades y dos coordinadores generales.

Cada track produce como resultado una página wiki que sintetiza la discusión. Los coordinadores del track son los responsables de crear y mantener dicha página en base a: i) las discusiones por mail que se promueven en la lista [ontology-summitlist], ii) las contribuciones que los participantes hacen en una página destinada a tal fin (Track community input), iii) las presentaciones en las conferencias virtuales que

2

https://wiki.oasis-open.org/icom

1193

Una aplicación de la Wikimedia Semántica

3

el Track organiza y iv) los resultados de actividades específicas propuestas por los coordinadores del track.

La cumbre de este año ha puesto el foco en "La evaluación de las ontologías a lo largo de su ciclo de vida" y ha sido organizada en cuatro tracks: i) Aspectos intrínsecos de la evaluación de ontologías, ii) Aspectos extrínsecos de la evaluación de ontologías, iii) Construcción de Ontologías para cumplir con criterios de evaluación, y iv) Entornos de software para la evaluación de ontologías.

Como se mencionara en la sección previa, el repositorio del foro Ontolog se encuentra alojado en una plataforma wiki. La misma permite, a través de los denominados "purple numbers" (números púrpura), referenciar a párrafos específicos dentro de una página utilizando un código alfanumérico único dentro de la página.

Desde otras páginas es posible referenciar a estos nodos utilizando el identificador del nodo, denominado nid ("node identifier") o número púrpura, en el URL de la página.

Esta plataforma wiki se constituye en un importante repositorio del conocimiento que se genera colaborativamente en las cumbres de ontología. Sin embargo, a pesar de su utilidad, la información allí contenida no es fácilmente utilizable por herramientas externas. No es sencillo recolectar información que se encuentra distribuida en diferentes páginas, como por ejemplo, cuáles son las conferencias virtuales en las cuales ha participado alguna persona. A pesar de que la información en una wiki se encuentra estructurada (cada conferencia tiene su página con links a miembros que participaron en ella), su significado no es claro para una computadora, ya que no se encuentra representado de manera procesable por máquina. Por lo cual, este contenido no puede ser consultado utilizando las nuevas tecnologías de la Web Semántica.

Asimismo, el cuerpo de conocimiento almacenado en la wiki Ontolog es muy voluminoso y posee una organización que impide que personas no familiarizadas con su estructura puedan acceder fácilmente al mismo. Si tomamos, por ejemplo la página de alguna conferencia virtual, la misma contiene bastante información sobre ella: el tema a tratar, quienes son los coordinadores, los panelistas, una pequeña reseña de cada uno de ellos y el enlace a sus trasparencias, también se muestra la transcripción del chat (una vez que fue realizada la conferencia) e incluso las instrucciones para poder conectarse para participar de la misma (información que no es importante una vez finalizada).

3

Incorporación de Semántica y Reorganización del Contenido

Como se mencionara en la sección previa, el contenido alojado en la wiki Ontolog está siendo migrado a una plataforma wikimedia que incorpora características semánticas. Sin embargo, la sola migración a esta nueva plataforma no agrega semántica al contenido, así como tampoco implica la reorganización del mismo. A fin de cubrir estas necesidades se presenta una propuesta que incorpora semántica al contenido a través de la ontología ICOM y una capa que provee acceso al repositorio de información mediante una vista reorganizada de la misma. La Fig. 1 muestra los componentes principales de esta propuesta, los cuales serán introducidos a continuación.

1194

4

Marcela Vegetti, Horacio Leone

PSMW (Purple Semantic Media Wiki) es una plataforma que, mediante las extensiones SMW (Semantic Media Wiki) [1] y PMWX (Purple mediawiki) [2], permite agregar semántica y acceso de "grano fino" al contenido de páginas wiki. El contenido del foro Ontolog está siendo migrado a esta nueva plataforma, creando el foro Ontolog PSMW, que posibilitará la incorporación de semántica al contenido.

Fig. 1. Componentes de la propuesta

A través de la extensión SMW es posible hacer explícita la información acerca de las relaciones existentes entre las páginas wiki. En la mediawiki estas relaciones se establecen con los links entre las páginas. Cada enlace establece cierta relación entre dos páginas, sin explicitar qué tipo de relación se trata. SMW permite caracterizar estos links mediante la definición de propiedades, de manera que el destino de un link se convierte en el valor de una propiedad definida para la página en la que está el enlace. De esta manera, es posible formular consultas semánticas sobre el contenido de las páginas. Para conseguir esto se requiere la definición de 4 tipos de páginas diferentes: propiedades, plantillas, formularios y categorías, en sus correspondientes espacios de nombre: Property, Template, Form y Category.

Las propiedades, junto con los tipos, son las formas básicas de introducir datos semánticos en la wikimedia semántica. Una propiedad se utiliza para anotar una porción de información en una página. Como ejemplo, considere la Fig. 2 en la cual se muestra el código utilizado en la wiki original y en Ontolog PSMW para mostrar una porción de texto en una página wiki. En el segundo caso, se puede observar que, los enlaces de las páginas a los organizadores de Ontolog han sido anotados con la propiedad hasOrganizer.

Fig. 2. Ejemplo de código para anotar texto en PSMW

Las plantillas son páginas wiki en el espacio de nombres Template cuyo contenido puede ser insertado en otra página. Una plantilla posibilita establecer la visualización

1195

Una aplicación de la Wikimedia Semántica

5

de los datos de una página y, además, permite convertir los datos en información semántica real ya que en ella es posible definir las propiedades de las páginas que la utilizan.

Los formularios permiten a los usuarios crear o editar páginas fácilmente. Se define un formulario por cada categoría y se asocia a una o más plantillas, las cuales permiten clasificar las páginas, que el formulario crea, bajo una Categoría. Las categorías son usadas como etiquetas para las páginas wiki e indican que una página pertenece a un tipo particular de página. Éstas son una característica de la wikimedia que permite el indexado automático de las páginas. Cada categoría establece un tipo de página diferente que se vincula con una plantilla y un formulario que permite la creación de sus correspondientes páginas.

Por su parte, la ontología ICOM, utilizada para definir la semántica de Ontolog PSMW, define un marco para la representación e integración de las actividades que se llevan a cabo en un entorno de colaboración [3]. Este vocabulario integra una amplia gama de actividades de colaboración, incluyendo y adaptando una serie de modelos que forman parte de normas y tecnologías existentes. ICOM posee una estructura modular para permitir la extensibilidad, a través del agregado de nuevos módulos. Los conceptos fundamentales y sus relaciones se incluyen en el núcleo (icom_core), mientras que los conceptos y las relaciones específicas para cada área de actividades de colaboración se definen en los módulos de extensión separados (icom_conf, por ejemplo). El subconjunto de los conceptos ICOM que son relevantes para la propuesta presentada en este artículo se muestran en la Fig. 3.

Fig. 3. Conceptos de ICOM utilizados en la propuesta

Una Entidad (Entity) es un objeto identificable que puede ser almacenado. Entity es la superclase de todas las otras clases definidas en ICOM (la relación superclasesubclase de Entity con los otros conceptos se ha omitido de la Fig. 3 para favorecer la claridad de la misma).

Un Grupo (Group) es una colección de individuos que comúnmente está asociado a un espacio de trabajo pero puede estar relacionado con más de uno (asociación space en la Fig. 3) y con cero o más subgrupos (relación memberGroup en la Fig. 3). Los individuos, Persona, (Person), miembros de un grupo, se vinculan a éste a través de la relación. memberActor.

Un Espacio (Space) es un ámbito que define un marco para que los actores trabajen o colaboren. Espacio la representación concreta de un área de trabajo para una colaboración y puede estar vinculado con un grupo y con otros espacios subsidiarios.

1196

6

Marcela Vegetti, Horacio Leone

El concepto Persona (Person) representa a un individuo que participan en una colaboración. Una persona puede ser miembro de un grupo así como tener su propio espacio de trabajo.

El resultado de las diferentes actividades colaborativas llevadas a cabo en los distintos espacios se representa como un Artefacto (Artifact) que se vincula a un espacio a través de la asociación container. Un artefacto puede representar un documento o un conjunto de documentos relacionados que pueden estar incluidos en alguna página o almacenados en un repositorio.

Otro de los conceptos propuesto por ICOM es el de Conferencia (Conference), el cual representa una reunión que se lleva a cabo, de manera virtual o presencial, entre individuos. Una conferencia tiene un organizador, que puede ser un grupo o una persona, un conjunto de participantes, así como fechas de inicio y finalización tanto planificadas como reales.

La aplicación de estos conceptos al cuerpo de conocimiento relacionado con la cumbre de ontologías 2013 se muestra parcialmente en las Fig. 4 y 5. En particular, en la Fig. 4 se observa que la cumbre de ontologías del año 2013 se representa como un espacio de trabajo (OntologySummit2013Space) que está relacionado con el grupo (OS2013Team) que impulsa el desarrollo de las actividades de la cumbre. Este grupo, tiene a los coordinadores generales como miembros actores (relación memberActor) y a su vez, está relacionado (relación memberGroup) con los subgrupos que representan a los comités organizador (OS2013OrgCommittee) y asesor (OS2013AdvCommittee), a los patrocinadores (OS2013Sponsors) y a las instituciones organizadoras de la cumbre (OS2013CoOrganizer).

Por otra parte, la responsabilidad del espacio OntologySummit2013 en la organización del simposio presencial, así como de las reuniones virtuales que no son específicas de un track, está representada también en la Fig. 4 mediante la relación organizer que se establece entre el espacio y las conferencias en cuestión. En la figura sólo se muestran dos de estas conferencias: Phase2PhaseSymposium y ConferenceCall_2013_04_25. Asimismo, el comité organizador, tiene asociado un espacio de trabajo (OS2013OrgCommittee) y lleva adelante reuniones virtuales entres sus miembros, las cuales son representadas como conferencias (por ejemplo, OrganizingCommitte meeting n.07-Fri 2013.03.15).

Como se mencionó anteriormente, en la cumbre de ontologías se llevan adelante diferentes tipos de actividades, las cuales pueden clasificarse en espacios de discusión denominados tracks y espacios transversales de trabajo, en los que se busca la realización de un trabajo concreto que, preferentemente, involucre aspectos discutidos en todos los tracks. Este año, por ejemplo, se concretaron el desarrollo de una encuesta, la redacción del comunicado, la organización de la biblioteca digital, el desarrollo del sitio web, además de la organización de conferencias tipo hackathon.

En todos los casos, las actividades, son representadas como un espacio (icom_core_Space) subsidiario de OS2013Activities. En la Fig. 4 se muestran los espacios creados para representar las actividades de este año: SurveyDevelopment, Hackathon&Clinics, CommuniqueDevelopment, WebsiteDevelopment y CommunityLibraryDevelopment. Como puede observarse en la Fig. 4 para Hackathon&Clinics y CommuniqueDevelopment, cada actividad: i) tiene un grupo

1197

Una aplicación de la Wikimedia Semántica

7

que la soporta, ii) puede proponer subactividades y iii) puede producir uno o más artefactos.

Fig. 4. Aplicación de los conceptos ICOM al contenido de la cumbre de ontologías de un año

Los espacios de discusión o tracks son un tipo particular de actividad que tiene como objetivo el estudio, análisis y discusión del estado del arte en un tema específico dentro del tema general de una cumbre particular. Cada uno de los tracks es representado como un espacio subsidiarios del espacio OS2013Tracks que se muestra en la Fig.4.

En la Fig. 5 cada Track, independientemente del tema en particular que aborde, está relacionado con: i) un grupo compuesto por sus coordinadores y sus panelistas, ii) un conjunto de conferencias virtuales, organizadas por el track y que abordan la temática bajo discusión desde la óptica de dicho track, iii) dos subespacios: uno en el que los participantes de la cumbre pueden hacer sus aportes a la discusión del track (OS2013TrackBCommunityInput) y otro, en el cual los coordinadores del track realizan la síntesis de la discusión llevada a cabo en el track (OS2013TrackBSynthesis).

Además, la Fig. 5 muestra el grupo asociado al espacio OS2013TrackB, con sus miembros que son los coordinadores (ToddS y TerryL) y los panelistas (HansP, MaryB, MeganK, JoaoPauloA, AmandaV, KeithS) que realizaron su presentación en alguna de las conferencias organizadas por el track (ConferenceCall_2013_01_24 , ConferenceCall_2013_02_28). Este espacio no tiene otros espacios subsidiarios.

En las dos conferencias ilustradas en la Fig. 5, así como en todas las conferencias semanales de cada cumbre, los panelistas realizan sus presentaciones y quedan como resultado de las mismas los siguientes productos o artefactos: i) las trasparencias de cada presentación, ii) la transcripción (en bruto y editada) de la sesión de chat y iii) la

1198

8

Marcela Vegetti, Horacio Leone

grabación del audio de la conferencia. Todos estos artefactos son almacenados en un repositorio al que los participantes de la cumbre y cualquier interesado tienen acceso.

Los conceptos ICOM que se presentaron en la Fig. 3 se mapearon a PSMW para poder ser utilizados para anotar las páginas wiki de Ontolog. En este mapeo se crearon: i) propiedades para representar las relaciones y los atributos, ii) plantillas y categorías para representar los conceptos ICOM, y iii) formularios que permiten la creación de las páginas. En las diferentes plantillas se incorporaron consultas acerca de las propiedades definidas en las páginas.

Fig. 5. Representación del Track B: Extrinsic Aspect of Ontology Evaluation

Para abordar el inconveniente de la complejidad del contenido y de la dificultad del acceso al mismo por parte de personas no familiarizadas con la estructura del repositorio, se propone incluir una capa de presentación sobre las páginas wiki que permita acceder a través de consultas y de sentencias de transclusión (incluir en una página wiki parte del contenido de otra página) al contenido que se pretende mostrar.

En principio la tarea se focalizó solamente en el cuerpo de conocimiento asociado a la cumbre de ontologías de este año 2013. Sin embargo, la propuesta puede ser extendida sin mucho esfuerzo a cumbres de otros años y a otros eventos de Ontolog.

Siguiendo la estrategia utilizada para el desarrollo del sitio web de la cumbre del año pasado, la propuesta divide el contenido de la cumbre en tres espacios: Actividades, Recursos y Entregables.

El espacio de Actividades presenta información sobre las diferentes actividades propuestas y posibilita el acceso a los respectivos espacios de trabajo. Los otros dos espacios, permiten a los usuarios acceder a la lista de las conferencias virtuales, la biblioteca digital, el archivo de la lista de discusión, en el espacio Recursos y a todos los artefactos que son resultado de las diferentes actividades que se llevan a cabo durante los tres meses de la cumbre en el espacio Entregables.

Las páginas que forman parte de esta capa no han sido migradas desde la vieja plataforma sino que se crearon utilizando las propiedades, plantillas, categorías y formularios definidos al mapear los conceptos de ICOM a PSMW. Además, con el fin de reutilizar el contenido existente en las páginas migradas, se hace uso de las

1199

Una aplicación de la Wikimedia Semántica

9

consultas que provee la extensión SMW y de la capacidad de transclusión provista por la wikimedia. El objetivo de la transclusión es obtener los últimos datos referenciales.

En otras palabras, si se cambia la página de referencia, a continuación, la información incluida se actualizará automáticamente. PSMW soporta actualmente transclusión de toda una página, o de una sección de la página (a través de los números púrpura).

Con esta propuesta se ha incorporado semántica al cuerpo de conocimiento relacionado con la cumbres de ontologías 2013, lo cual permite realizar consultas como la planteada al final de la sección 2 de ese artículo: ¿Cuáles son las conferencias virtuales en las cuales ha participado una determinada persona? La misma puede realizarse con la siguiente función #ask, en la cual se consulta por las conferencias en las que ha participado Marcela Vegetti: {{#ask:[[Category:Icom conf Conference]] [[icom core participant::MarcelaVegetti]] |?Icom core organizer |?Icom core Description |format=table }} Esta consulta, podría ser incluida en el template icom core Person de manera que para cada página de esta categoría se muestre la lista de conferencias de las que participó. Para ello es necesario cambiar el nombre de la persona por la variable {{PAGENAME}} que almacena el nombre de la página donde la consulta está incluida. Sin embargo, también es posible ejecutarla desde [Special:Ask]. Esta página, cuya funcionalidad está implementada por la extensión SMW, permite realizar consultas definidas por los usuarios, más allá de las incluidas en las páginas wiki. En la Fig. 6 se muestra los resultados obtenidos al ejecutar la consulta mostrada desde esta página especial.

Fig. 6. Resultados de la consulta acerca de conferencias a las que asistió una persona dada

Es importante resaltar, que una vez creados los datos en una wikimedia semántica, éstos no necesitan mantenerse dentro de la wiki; pueden ser fácilmente exportados a otros formatos como archivos separados por comas, JSON y RDF. Esto posibilita que una wiki semántica sirva como fuente de datos de otras aplicaciones. En particular, utilizando la página especial ontolog-02. cim3.net/wiki/Special:ExportRDF es posible

1200

10

Marcela Vegetti, Horacio Leone

exportar los datos de una o varias página como tripletas RDF, con lo cual el contenido de la cumbre de ontologías 2013 es ahora legible y descubrible por máquinas.

Impulsando con esto el movimento del contenido de ontolog PSMW hacia la obtención de las 5 estrellas que según Berners-Lee deben tener los datos para pertenecer a LinkedData [4].

4

Conclusiones y Trabajos Futuros

Ontolog es una comunidad abierta virtual que busca impulsar avances en el campo de la ingeniería ontológica y las tecnologías semánticas. Todas las contribuciones realizadas por los miembros de esta comunidad en las diferentes actividades que se proponen son almacenadas en una plataforma wiki que no tiene implementadas ninguna de las tecnologías semánticas que este foro trata de promover.

Otra de las actividades que se llevan a cabo en el marco de Ontolog, es el desarrollo de la plataforma PSMW, a la cual se está migrando el repositorio de Ontolog. El cambio de plataforma, sólo provee la capacidad de añadir semántica, lo cual debe ser complementado con la implementación de una ontología en la plataforma PSMW, para incorporar efectivamente semántica. En este artículo se propone la utilización de la ontología ICOM para representar la estructura y el contenido de la cumbre de ontologías 2013 y capturar el contenido de acuerdo a este vocabulario común. Adicionalmente, se propone la reorganización del contenido de las cumbre de manera que fomente y facilite el acceso y la reutilización del material generado.

La implementación se está llevando a cabo a nivel de prototipo. Una vez validados los resultados de esta propuesta, se procederá a extender la aplicación de la ontología para la representación de otras actividades de Ontolog.

Agradecimientos Este trabajo ha sido financiado en forma conjunta por CONICET, la ANPCyT (PAE-PICT2315 y PIP 112-200801-02754) y la Universidad Tecnológica Nacional (PID 25/O156 y PID 25/O144). La comunidad Ontolog ha brindado su infraestructura para permitir la realización de este trabajo. Se agradece el apoyo brindado por estas instituciones, así como la colaboración de Tejas Parikh, Ken Baclawski, Ali Hashemi, Peter Yim y Soledad Sonzini para llevar adelante esta propuesta.

Referencias [1] [2] [3]

[4]

Krötzsch, M., D. Vrandečić, M. Völkel, H. Haller, R. Studer (2007). Semantic Wikipedia. Web Semantics,5, Baclawski,K., V.Gupta, T. Parikh, P. Yim, J. Cheyer. (2008). Purple MediaWiki: Fine-Grained Addressability of Wiki Content. Available at: http://project.cim3.net/wiki/PMWX_White_Paper_2008 OASIS ICOM. (2013). Integrated Collaboration Object Model (ICOM) for Interoperable Collaboration Services Version 1.0. 31. OASIS Committee Specification 01. Disponible on-line en: http://docs.oasis-open.org/icom/icom-ics/v1.0/cs01/icom-ics-v1.0-cs01.html Tim Berners-Lee. (2009).

Linked Data.

Disponible en línea en: http://www.w3.org/DesignIssues/LinkedData.html

1201

Applying EDON Methodology and SBVR2OWL Mappings for Building an Ontology-Aware Software Cecilia Gaspoz, Valeria Bertossi, Emiliano Reynares,Ma. Laura Caliusco CIDISIResearch Center – UTN – FRSF – Lavaise 610 – Santa Fe – Argentina ceciliagaspoz@gmail.com, valeriabertossi@live.com.ar, {reynares,mcaliusc}@frsf.utn.edu.ar

Abstract.In Ontology-Aware Software, ontologies are use at run time to, for example, use their content in operations of information searching or as database substitutes for information storage. In order to integrate the software development and ontology building processes, involved in building ontologyaware information system a methodology called EDONhave defined. The main disadvantage of this methodology is that the heuristic to generate an implemented ontology from the requirement elicitation is not complete enough.

On the other hand, recently, the Object Management Group (OMG) has standardized a language called Semantics of Business Vocabulary and Rules (SBVR) and different approaches have been proposed to map SBVR expressions into the OWL ontology language. In this paper, we report our experience in developing an ontology-aware information system by using an adaptation of the EDON methodology including the SBVR2OWL mappings.

Keywords: Ontology-Aware Information System, SBVR2OWL Mappings

1

Introduction

Since the latter part of the 20th century there has been a growing interest in applying the ontology in the context of software engineering due to the advent of the Semantic Web and the technologies for its realization. In the software engineering context, an ontology can be used at run time in two different ways: (1) as Architectural Artifacts (Ontology-Driven Software), ontologies are used as central elements of the proposed software architecture, and (2) as Information Resources (Ontology-Aware Software), ontologies are used at run time in order to, for example, use their content in operations of information searching or as database substitutes, for information storage [3].

In the context of ontology-aware software, developers have to face the problem of how to integrate software development and ontology building methodologies assuring the project success. The development of methodological approaches for building an ontology as software artifact is still an open research area. There are many languages, techniques and tools for the representation, design and construction of ontologies [5].

But the great majority of these have been created for and by the knowledge

1202

2Cecilia Gaspoz, Valeria Bertossi, Emiliano Reynares,Ma. Laura Caliusco

engineering community. Because of this, the use of ontologies by Software Engineering professionals and researchers can be seen as an additional learning experience, and in some cases, of considerably great effort [3]. Moreover, a survey [14] showed that approximately 50 % of its participants did not use any ontology engineering methodology in large-scale projects.

In order to avoid this problem, Reynareset. al. [13]have defined a methodology called EDON to build an ontology-aware system. This methodology proposes to develop an ontology that fulfills the requirements of the development cycle to which it belongs. From requirements, through CQs and LELs, you get the necessary information about the domain which is then captured as objects, relationships and properties in the implemented ontology. With regard to CQs, they can lead to create objects, relations or properties that are not relevant to the system, but they are for the environment in which the system is embedded. This happened to us in our development and is mainly due to those who are not familiar with the development of ontologies think in terms of the system. With regards to LELs, the heuristics used to build the ontology from them is not complete enough [1]. Then, although the ontology conceptualization by using CQ and LELs has proven to be useful to facilitate the communication among the DEs, SEs and KEs, a more powerful formalism will improve the way complex business rules are expressed.

Recently, the Object Management Group (OMG) has standardized another language called Semantics of Business Vocabulary and Rules (SBVR) [10]. SBVR has been conceptualized for business people and designed to be used for business purposes independent of information systems designs. The linguistic approach adopted by the proposal enables the expression of business knowledge through statements rather than diagrams. That is rooted in the insight that diagrams are helpful for depicting structural organization of concepts but they are impractical as a primary means of defining vocabularies and expressing business rules. Different approaches have been proposed to map SBVR expressions into OWL language [12].

The objective of this paper is to report our experience in developing an ontologyaware information system by using an adaptation of the EDON methodology including the SBVR2OWL mappings defined by Reynares et al. [12]. To this aim, the paper is organized as follows. Section 2 defines the concepts necessary to understand the content of this paper. Section 3 describes the development the Ontology-Aware Information System. Finally, Section 4 is devoted to discussion and lessons learned.

2 2.1

Conceptual Foundations Evolutionary Development of ONtologies (EDON)

EDON [13] is an approach for building from scratch an ontology intended to be used as a structural conceptual model of an information system, encoding business rules in a declarative way. EDON adopts a requirement driven, iterative, and incremental approach and it is composed by the processes described next.

1203

Applying EDON Methodology and SBVR2OWL Mappings for Building an Ontology-Aware Software 3

Requirements Selection Process.This process is composed by three activities: (1) identification of the functional requirements that involves business rules in their meeting, (2) identification and prioritization of the domain entities involved in the meeting of the requirements identified before, and (3) requirements grouping and selection according to the importance of the entities involved.

Ontology Development Process.This process involves Development Activities that allows evolving from an abstract model toward a computable ontology, and Support Activities are carried out along the whole development process. The Development Activities are: specification, conceptualization, formalization, refinement, implementation and alignment. The Support Activities are: knowledge elicitation and evaluation. The techniques to carry out them are based on the different methodologies and good practices for building ontologies developed since mid-1990 [5]. EDON considers the performing of the refinement activity with the aim of extending the ontology by focusing on the declarative formulation of business rules.

Ontology Alignment Process.Each application of EDON produces an ontology that supports a disjoint set of functional requirements, i.e., those selected on the specification activity of the iteration. Therefore, the alignment of current and previous version of the ontology is needed as a way to support both set of requirements.

Ontology alignment is the process of determining the different types of (interontology) relationships among their terms [11]. As a result, a new ontology composed by sub-ontologies is created.

2.2

SBVR2OWL Mappings.

SBVR.SBVR [10] defines the vocabulary and rules for documenting the semantics of business vocabularies, business facts, and business rules; which allows their verbalization in a controlled vocabulary readily understandable by business people.

The fact-oriented approach of SBVR stems from the Business Rules Manifesto [2], stating that rules builds on facts, and facts build on concepts as expressed by terms.

Therefore, terms express business concepts, facts make assertions about these concepts, and rules constrain and support these facts. SBVR supports such approach by providing noun concepts and verb concepts respectively corresponding to the notions of terms and facts.

As early stated, SBVR adopts a linguistic approach that allows to define vocabularies and express operative rules. According to this insight, SBVR defines a Controlled Natural Language (CNL) and describes the way to mechanically mapping such CNL expressions to SBVR formal concepts.

OWL.The OWL 2 Web Ontology Language (OWL 2) is the latest version of an ontology language proposed by the World Wide Web Consortium (W3C) [16]. OWL 2 ontologies provide classes, properties, individuals, and data values, and are stored as Semantic Web documents. An OWL 2 ontology is a formal description of a domain of interest rooted in three syntactic categories that are interpreted under a standardized semantics, which allows useful inferences to be drawn.

1204

4Cecilia Gaspoz, Valeria Bertossi, Emiliano Reynares,Ma. Laura Caliusco

─ Entities, such as classes, properties, and individuals. They are the basic elements of an ontology and are identified by Internationalized Resource Identifiers (IRIs) [7]. ─ Expressions, representing complex notions in the domain being described. ─ Axioms, which are statements asserted to be true in the domain being described.

OWL 2 ontology language defines several concrete syntaxes that can be used to serialize and exchange ontologies. Among them, the functional style syntax is defined in the OWL 2 structural specification [7] with the aim to state the semantics of OWL 2 constructors and allow a compact writing of ontologies.

Mappings.Mappings defined by Reynareset. al. [12] allow the automatable generation of an OWL2 ontology from the SBVR specifications of a business domain.

Transformations are rooted on the structural specification of both standards and are depicted in subsections below by grouping and sequencing them according to the inherent logical order of the subject matter itself. In addition to their theoretical expression, the mappings are illustrated by building an ontology that reflects the business knowledge exposed by a case study. Some of these mappings are shown in Table 1.

Table 1. An excerpt of the Mappings defined by Reynares et.al.[12] 1. Each object type ot is mapped to Declaration(Class(a:ot)) 2. exactly-n Quantification, where “n” is a non-negative integer: ─ If the logical formulation scopes over a unary fact type, the expression is mapped to DataExactCardinality(n a:DataPropertyOne a:DataRangeOne)

─ If the logical formulation scopes over a binary fact type, the expression is mapped to ObjectExactCardinality(n a:ObjectPropertyOne a:ClassOne)

3

Applying EDON and SBVR to OWL2 Mappings for developing an ontology-based system.

The methodology applied in the development of the fellow recommender system is based on EDON methodology[13], which was adapted, in the experience describe in the following subsections, to include the SBVR to OWL Mappings[12].

3.1

Requirements Selection.

Requirements were classified in two classes: those requirements that will be supported by the ontology and those which will not. Some requirements of the first class were selected to implement in a first iteration of the development process. A storyboard exposing a functional requirement belonging to the selected subset is:“The

1205

Applying EDON Methodology and SBVR2OWL Mappings for Building an Ontology-Aware Software 5

system should evaluate the indicators involved in the point assignment process for each one of the candidates and the order of those candidates based the general indicator. The ranking should be display on screen.”

Alumno (Student), Materia (Subject), Universidad (University), Facultad, Carrera (Career), PlanDesarrolloAcadémico (AcademicDevelopmentPlan), Beca (Fellowship), SituaciónAcadémica (AcademicSituation), SituaciónEconómica (EconomicSituation) were identified as the core entities involved in the meeting of the requirements identified before.

3.2

OntologyDevelopment.

Specification.Based on the core entities identified before and the general knowledge of the problem, Competency Questions (CQs) were proposed. An excerpt of them is showed in Table 2. From the CQs, a list of the domain entities needed for answering them was identified.Some of these domain entities are:Postulante (Applicant - student enrolled in a fellowship), Candidato (Candidate – applicant who meets every requirement), Becario (Fellow – Candidate to whom the fellowship has been granted).

Table 2. An excerpt of the Competency Questions ─ Are every applicant to the university fellowship registered during the registration period? ─ Are all candidates regular students? ─ Which are the aspects related with the academic situation of the candidate that impact in the ranking process? ─ Is the list of the candidates order by decreasingly based in the general indicator? ─ Has every candidate approved at least 5 subjects during the last school year? Those who not, ¿are those new students?

Conceptualization.In this activity, the knowledge about the domain entities was collected from the information sources: the university’s fellowship regulations and a fellowship management report. The business rules extracted from these resources were written in natural language, in order to represent them independently of the modeling paradigm and the implementation language of the target ontology.

Formalization.The business rules identified were translated from the natural language to SBVR. This activity includes: Recognize the noun concepts, the fact types and keywords; differentiate noun concepts belonging to complex concepts from noun concepts belonging to datatypes, re-elaborate the fact type according to the fact being represented, build the business rules by applying restrictions on the statements.

Then, the business vocabulary was organized by means of vocabulary entries, as shown in Table 3.

1206

6Cecilia Gaspoz, Valeria Bertossi, Emiliano Reynares,Ma. Laura Caliusco Table 3.SBVR specification of “Beca” (Fellowship) concept.

Beca Definitions: General Concept: Concept Type: Object Type Necesity: ─ each becatieneciclo exactly one ciclobeca ─ eachbeca tiene plazo inscripción exactlyoneplazo inscripción ─ eachbeca tiene valor canasta familiar exactlyonecanasta familiar • Posibility:

• • • •

Ref: tieneciclo: has school year - ciclobeca: school year of the fellowship - plazo de inscripción: registration period - canasta familiar: basic market basket indicator.

Ontology Implementation.In order to create the ontology implementation, the SBVR2OWL transformations, defined by Reynareset. al.[12], were apply to the SBVR model of the business vocabulary created in the previous activity. An example of this process is showed in Table 4. The ontology was implemented using the free ontology editor called Protégé and the Pellet inference engine that provides soundand-complete OWL-DL reasoning services. The ontology was written in OWL-DL 2.0 ontology language and serialized in OWL/RDF format.

Table 4. OWL specification of “Beca” concept.

Declaration(Class(BecaUTN:Beca)) SubClassOf(BecaUTN:Beca ObjectMinCardinality(1 BecaUTN:tieneCicloBecaUTN:CicloBeca))) SubClassOf(BecaUTN:BecaObjectMinCardinality(1 BecaUTN:tienePlazoInscripcionBecaUTN:PlazoInscripcion))) SubClassOf(BecaUTN:Beca DataExactCardinality(1 BecaUTN:CanastaFamiliarxsd:float))

Refinement.The resulting ontology represents the main concepts of the problem domain. The refinement activity consists in further extending the ontology by focusing on the formulation of rules, which are obtained from the knowledge and information sources identified in the specification activity. The rules allow implementing the algorithm for making the fellows’ ranking, and several classifications, e.g. each instance of Alumno (Student) can be classified in Postulante (Applicant) and/or Candidato (Candidate); each instance of Examen (Test) is classified in ExamenAprobado (ApprovedTest) and ExamenNoAprobado (FailedTest), etc.

The rules were implemented in the Semantic Web Rule Language (SWRL), which provides the ability to express Horn-like rules in terms of OWL concepts [9]. Table 5 shows some of the rules implemented in the study case.

1207

Applying EDON Methodology and SBVR2OWL Mappings for Building an Ontology-Aware Software 7 Table 5. An excerpt of the rules implemented in SWRL ─ Examen (?examen), calificacionExamen(?examen,?calificacion), greaterOrEqual(?calificacion, “4”^^UnsignedShort) ExamenAprobado(?examen) ─ Examen (?examen), calificacionExamen(?examen,?calificacion), lessThan(?calificacion, “4”^^UnsignedShort) ExamenNoAprobado(?examen) ─ Alumno(?alumno), esIngresante(?alumno, true) AlumnoRegular(?Alumno) ─ Alumno(?alumno), esIngresante(?alumno, false), rinde(?alumno,?exam1), rinde(?alumno,?exam2), ExamenAprobadoCicloAnterior(?exam1), ExamenAprobadoCicloAnterior(?exam2), DifferentFron(?exam1, ?exam2), AlumnoRegular(?Alumno)

3.3

Ontology Evaluation.

Quality evaluation task was performed by means of OQuaRE [4], a framework conceived for that purpose and based on the SQuaRE standard for software quality evaluation [6]. OQuaRe defines a quality model which is divided into a series of characteristics organized into subcharacteristics which are evaluated by applying a set of automatable metrics. OQuaRE defines the criteria to transform the quantitative scores of each metric into a 1-5 range and establishes that 1 means not acceptable, 3 is minimally acceptable and 5 exceeds the requirements. After such transformation, score for each subcharacteristic is the mean of its associated metrics while the score of each characteristic is the mean of its sub-characteristics. The set of characteristics scores is the quality assessment result, enabling the identification of strengths and flaws of the ontologies rather than simply pointing out a “best ontology". Dimensions evaluated, shown in Figure 1, are defined as follows:

Fig.1.Characteristics scores of the ontology developed • Structural dimension involves formal and semantic properties that are important when evaluating ontologies since it accounts for quality factors such as consistency, formalization, redundancy or tangledness.

• Functional adequacy dimension refers to the appropriateness of the ontology for its intended purpose, according to the categories identified by [15].

1208

8Cecilia Gaspoz, Valeria Bertossi, Emiliano Reynares,Ma. Laura Caliusco

• Maintainability dimension is related to the capability of the ontologies to be modified for changes in the environment, in requirements or in functional specifications.

• Compatibility dimension refers to the ability of two or more ontologies to exchange information and/or to perform their required functions while sharing the same hardware or software environments. The compatibility dimension can be evaluated over a single ontology - although intuitively it involves properties about more than one ontology - given that it is quantitatively assessed by means of a set of metrics applied to each ontology separately.

• Transferability dimension is the degree to which the ontology can be transferred from one environment (e.g., operating system) to another.

• Operability dimension refers to the effort needed to use the ontology and, in the individual assessment of such use, by a stated or implied set of users.

• Reliability dimension is the capability of the ontology to maintain its level of performance under stated conditions for a given period of time.

A quickly recognizable outcome is the level of quality shown by the ontology: according to the meaning assigned for OQuaRE to the values of the 1-5 ranking system, it largely outperform the minimally acceptable quality in all considered dimensions. Moreover, the global quality score - which is equal to 4.60 and it is calculated as the mean of all the scores - is very close to the maximal quality value.

3.4

Ontology Alignment.

The alignment activity consists in determining the different types of (interontology) relationships among their terms [8] [15].As a result, a new ontology composed by sub-ontologies is created. The first version of the ontology does not involve the performing of alignment activities. As single iteration of this EDON adaptation was performed, this activity was not required.

3.5

FellowRecommender System Implementation.

After the ontology evaluation, the Fellow Recommender System was implemented in Java by using the JENA framework. This Software includes inscription, academic plan’s punctuation and fellow’s ranking functions, as shown in Figure 2.With regards the software quality, the functionality, efficiency, reliability and maintainability are closed related with those measured by the ontology since it is the core of the system.

The usability was evaluated by a domain expert who gives a useful feedback to improve our system in a further work.

1209

Applying EDON Methodology and SBVR2OWL Mappings for Building an Ontology-Aware Software 9

4

Discussion And Lessons Learned

In this paper we have reported our experience and showed the satisfactory results in developing an ontology-aware Fellow Recommender Systems using the EDON Method adapted to includeSBVR language to write business rules, in the formalization activity of the ontology development process, and SBVR to OWL2 Mappings, to be used during implementation activity.

Business Rules are usually embedded in the procedural part of the application.

Using Ontologies to encapsulate them, made easier the modification and adaptation processes, allowing to use these system in others environments, such as other universities, without making a lot of changes. This is because, in order to adapt the system to other universities, the set of Business Rules defined in the ontology, is the only thing that have to be modified.

Related with EDON some advantages can be mentioned that we identified form this experience. The use of CQs can lead you to identify objects, relations or properties, that are part of the domain of the problem that is attach by using an ontology-aware system, as well as restrictions, which can guide you in the ontology testing process.

On the other hand EDON proposed to align the ontologies that are developed throughout the history of the system, allowing and providing the system to grow. This is an important feature to get extensible systems, which could adapt to new requirements, e.g. handling a new type of fellowship.

Finally, Adding SBVR and SBVR2OWL Mappings to EDON Methodology, made the ontology development process of this system easier and fluid, making the transition from the business rules to the implemented ontology, natural, simple and intuitive, focusing in the conceptualization and formalization process and without taking great efforts during the implementation process.

1210

10Cecilia Gaspoz, Valeria Bertossi, Emiliano Reynares,Ma. Laura Caliusco

Fig. 2. The ontology – aware system implemented

5 1.

2.

3.

4.

5.

6.

7.

8.

9.

References.

Ayub, C.; Cian, A.;Reynares, E., Caliusco, Ma. L. "An Experience Report on using the EDON Method for Building a Team Recommender System". 42° Jornadas Argentinas de Informática - Simposio Argentino de Ingeniería de Software. Córdoba (Córdoba Argentina) Septiembre 2013. En prensa.

Business Rules Group: Business Rules Manifesto. Version 2.0. Accessible in: http://www.businessrulesgroup.org/brmanifesto.htm (2003) Calero, C. and Ruiz, F. and Piattini, M., eds.: Ontologies for Software Engineering and Software Technology. Springer. (2006) Duque-Ramos, A. and Lopez, U. and Fernandez-Breis, J. T. and Stevens, R. and Aussenac-Gilles, N.: OQuaRE: a SQuaRE-based approach for evaluating the quality of ontologies. Journal of Research and Practice in Information Technology, 43, 159- 173.

Gómez-Pérez, A. and Fernández-López, M. and Corcho, O.: Ontological Engineering.

Springer/Heidelberg. (2004).

International Organization for Standardization (ISO) ISO/IEC 25000 2500, Software Engineering - Software Product Quality Requirements and Evaluation (SQuaRE) Internet Engineering Task Force (IETF): RFC 3987: Internationalized Resource Identifiers (IRIs). Accessible in: http://www.ietf.org/rfc/rfc3987.txt (2005) Liu, P. and Dew, P.: Using semantic web technologies to improve expertise matching within academia. In Proc.: I-KNOW ’04, pages 370–378, (2004) O’Connor, M. Knublauch, H., Tu, S. &Musen M.: Writing rules for the semantic web using SWRL and Jess. In: Proc. 8th Int. Protégé Conference, Protégé with rules, (2005).

1211

Applying EDON Methodology and SBVR2OWL Mappings for Building an Ontology-Aware Software 11 10. Object Management Group (OMG): Semantics of Business Vocabulary and Business Rules (SBVR).

Version 1.0: Formal Specification.

Accessible in: http://www.omg.org/spec/SBVR/1.0/ (2008) 11. Pavel, S and Euzenat, J.: Ontology Matching: State of the Art and Future Challenges. In IEEE Transactions on Knowledge and Data Engineering, PP-99 (2011).

12. Reynares, E. and Caliusco M. A. and Galli, M. R.: An Automatable Approach for SBVR to OWL2 Mappings. In Proc. XVI Ibero-American Conference on Software Engineering (CIbSE 2013) Montevideo, Uruguay. (2013) 13. Reynares, E. and Caliusco M. A. and Galli, M. R.: EDON: A Method for Building an Ontology as Software Artefact. In Proc. 41st Argentine Conference on Informatics - 13th Argentine Symposium on Software Engineering (JAIIO - ASSE 2012) La Plata, Buenos Aires, Argentina. (2012) 14. Simperl, E., Mochol, M, and BĂźrger, T: Achieving Maturity: the State of Practice in Ontology Engineering in 2009. International Journal of Computer Science and Applications, 7(1):45 â&#x20AC;&#x201C; 65, 2010.

15. Stevens, R. and Wroe, C. and Gobel, C. and Lord, P.: Application of ontologies in bioinformatics. In Handbook of Ontologies in Informations Systems. Staab, S. and Studer, R. (eds). pp 635-658. Springer. (2008).

16. World Wide Web Consortium (W3C): OWL 2 Web Ontology Language. Structural Specification and Functional-Style Syntax.

Accessible in: http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/ (2009).

1212

Propuesta de tecnología móvil para la administración de información vinculada a la gestión de espacios áulicos Martín S. Martinez, Sonia I. Mariño, Pedro L. Alfonzo, Maria V. Godoy Departamento de Informática. Facultad de Ciencias Exactas y Naturales y Agrimensura. Universidad Nacional del Nordeste. Corrientes. Argentina. seba_martinezz@hotmail.com; plalfonzo@hotmail.com, simarinio@yahoo.com

Abstract. El avance de la informatización en las actividades humanas es un hecho, en las últimas décadas se ha incrementado la cantidad de software producido reflejándose en cambios en diversos aspectos de la sociedad del conocimiento. El ámbito educativo no escapa a esta realidad. Por lo expuesto, en este trabajo se presenta una segunda versión de un sistema web para la administración de espacios áulicos; incorporándose como tecnología emergente el acceso a información desde dispositivos móviles. El prototipo fue modelizado a partir de la gestión de espacios físicos de la Facultad de Ciencias Exactas y Naturales y Agrimensura (FaCENA) – Sede 9 de Julio, de la Universidad Nacional del Nordeste (UNNE), con miras a adecuarse a otras instituciones de Educación Superior.

Keywords: Educación Superior, Ingeniería web, sistemas de gestión web, administración automatizada de espacios físicos.

1 Introducción En los últimos años el crecimiento exponencial de la tecnología ha producido grandes avances en la informatización de las actividades. El bajo costo es cada vez mayor, los productos en la actualidad se encuentran muy cercanos al alcance de todos y las acciones de alfabetización e informatización están en ascenso. Lo expuesto se refleja en una sociedad cada vez más informatizada que requiere al mismo tiempo de diversas soluciones de software para el máximo aprovechamiento de la información.

Se coincide con [1] en que el surgimiento de la cuarta generación (4G) de celulares, conocidos como teléfonos inteligentes (smartphone), permitió una revolución en el desarrollo de software. La demanda está en constante aumento (Fig. 1). Años atrás lo más común era el desarrollo para máquinas de escritorio, el avance de la tecnología permitió crear dispositivos potentes y del tamaño para caber en la palma de una mano.

En los ámbitos de la educación superior, surgen diversos requerimientos tecnológicos, la mayor orientación ha sido informatizar el proceso de enseñanza y aprendizaje mediante la introducción de modalidades identificadas como e-learning, b-learning y m-learning, entre otras. Además, en la administración y gestión de los procesos desarrollados en el sector educativo existen numerosas soluciones mediadas

1213

por las Tecnologías de la Información y Comunicación, Sin embargo aquellas orientadas a gestionar la asignación de espacios físicos como son los laboratorios, salas de conferencias y aulas, rige generalmente bajo la responsabilidad de los “bedeles”, quienes administran los espacios contemplando datos referentes a horarios de inicio y finalización de clases o eventos académicos, profesor designado, materia o evento asignado, entre otras variables.

En [2], se detalla el desarrollo del sistema informático bajo un enfoque para consultas de “escritorio”, orientado a computadoras de tipo Notebook, Netbooks, PC. A partir de una etapa de validación con los potenciales usuarios “bedeles”, quienes utilizaron el software y con miras a mejorar o incorporar otras funcionalidades a partir de información de realimentación obtenida, en este trabajo se describe la incorporación de una tecnología emergente como es la consulta desde dispositivos móviles.

Cabe aclarar que el sistema informático se modeló considerando como contexto de implementación la Facultad de Ciencias Exactas y Naturales y Agrimensura (FaCENA), sede 9 de Julio, de la Universidad Nacional del Nordeste (UNNE), situada en Corrientes, Argentina. En su especificación primó proporcionar una solución fiable y acorde con las necesidades y requerimientos edilicios demandados por las distintas carreras dictadas en el mismo.

Fig. 1. Crecimiento de la demanda de aplicaciones móviles – Argentina. Fuente: Google Trends.

2 Metodología En [2] se detalló la metodología aplicada en la construcción del sistema informático para la gestión de espacios físicos, su desarrollo se fundamentó en el modelo de prototipos incrementales o evolutivos como ciclos de vida [3], [4]. [5], [6]. Es así como se consideró que al comienzo del proyecto, hay partes del sistema que no están del todo claras y generalmente el usuario final no especifica todos los requerimientos al inicio del mismo, completándose a fin de ajustar a lo largo del diseño y desarrollo.

A continuación se describen las etapas abordadas en esta segunda versión:

1214

ETAPA 1. La presentación de una versión preliminar descripta en [2] constituyó un medio de obtener datos para refinar el sistema, en este caso se detectó la necesidad del acceso a consultas desde dispositivos móviles.

• Análisis de un sistema informático para la gestión de espacios físicos. Se revisó el diseño preliminar, desarrollándose una segunda versión de prototipo a fin de integrar tecnología móvil. Cabe aclarar que se continuó aplicando modelado UML (Unified Markup Language) para redefinir las funciones a partir de los nuevos requerimientos utilizándose: i) Casos de usos ii) Conversaciones de los casos de uso para comprender que debería hacer cada uno, y iii) Diagramas de secuencia para identificar los diferentes flujos de información necesarios.

• Perfiles de usuarios. En cuanto al acceso de la información se aclara que se continuó trabajando con los dos perfiles mencionados en [2], “invitados” y “usuarios”. El último está compuesto por: bedeles y administrador.

ETAPA 2. Diseño del sistema informático, en esta segunda versión del prototipo, se abordaron las siguientes actividades: • Diseño de interfaces. Orientadas a las nuevas funcionalidades incorporadas, considerando los diversos perfiles de usuarios previstos.

• Diseño de la base de datos. Se rediseñó la base de datos y sus posibles relaciones con otras fuentes de datos (Fig. 2).

ETAPA 3. Desarrollo del sistema información.

• Selección de herramientas: para el desarrollo de esta nueva versión se continuó utilizando HTML (Hyper Text Markup Language) [7]. CSS - Hojas de Estilo en Cascada [8]. jQuery [9]. JavaScript [10]. PHP (Hypertext Preprocessor) [11]. WampServer (acrónimo formado por Windows, Apache, MySQL y PHP) [12]. DOMPDF [13]. MySQL Workbench [14]. Notepad++ [15]. En la generación de la solución móvil se optó por Phonegap [16] y Android Studio [17].

• Codificación de un nuevo módulo, para establecer el enlace entre la aplicación nativa de los móviles y la base de datos de sistema. Inicialmente se desarrolló para smartphones y tablets.

ETAPA 4. Puesta en funcionamiento o implementación. Las pruebas con los potenciales usuarios y destinatarios de la solución en desarrollo, brindan información de realimentación a fin de asegurar su implementación.

1215

Fig. 2. Estructura de la Base de Datos y sus relaciones.

3 Resultados En esta sección, se describe una segunda versión de un sistema informático parametrizable, orientado a la gestión de espacios físicos bajo el enfoque de soluciones móviles.

En la Fig. 3 se detalla la arquitectura de esta versión del sistema informático diseñado para la gestión de espacios áulicos. Donde las líneas azules indican las solicitudes o peticiones al servicio y las líneas rojas las consultas generadas y entregadas a las interfaces accesibles por los usuarios.

Como se especificó en [2], para acceder al sistema, se debe ingresar desde algún explorador Web. Los diferentes módulos que lo componen están dispuestos mediante la barra de “menú”.

Se coincide con [18] en que el “m-learning promueve experiencias contextuadas y colaborativas” en estos tiempos es recomendable incluir soluciones móviles desde los espacios de Educación Superior siendo tanto las orientadas a los procesos de enseñanza y aprendizaje como también las de índole administrativa, este ultimo tipo abordada en el presente trabajo. Por ello, como tecnología emergente incorporada se resume una aplicación para la consulta de aulas mediante tecnología móvil accesible desde smartphones y tablets. En una primera etapa se destinará la solución a aquellos usuarios con acceso a la red mediante conexión Wifi, 2G, 3G y 4G. Con soporte para interfaz web y Java. Esta aplicación permite la consulta de “bolsillo” para visualizar información de horarios específicos mediante el acceso a la base de datos del sistema.

(Fig. 4). En la Fig. 5 se ilustra una consulta desde la web y la misma desde una Tablet. Se proyecta, para próximas versiones de la aplicación desarrollar las consultas

1216

no siempre de forma remota, sino de prever una sincronización diaria o semanal, para realizarlas de modo “offline”. Cabe aclarar que temporalmente, la segunda versión del sistema que se describe sólo se aplica a consultas, es decir, no es viable establecer una administración de los datos desde dispositivo móvil.

Fig. 3. Arquitectura del sistema informático de gestión de aulas

Fig. 4. Aplicación móvil para consultas.

1217

Fig. 5. Consulta desde la web y desde una Tablet

4 Conclusión A partir de una solución tecnológica previamente desarrollada, destinada a la administración de espacios físicos de la Facultad de Ciencias Exactas y Naturales y Agrimensura – Sede 9 de Julio, de la Universidad Nacional del Nordeste (UNNE).

Corrientes – Argentina diseñada para mejorar la calidad de los procesos administrativos y de logística que sirven de apoyo para las actividades de la institución, se incorporó una funcionalidad accesible desde dispositivos móviles orientada a ampliar los servicios de información sin restricciones espacio-temporales.

Se prevé su conexión desde cualquier punto a través de las redes móviles como 2G, 3G, 4G y Wifi, brindando a los potenciales usuarios información siempre actualizada.

Por otra parte, se analiza la viabilidad de integrarlo al sistema SIU, tecnología informática disponible en las universidades Argentinas, y de este modo lograr interoperabilidad con otras soluciones disponibles en la unidad académica.

1218

Agradecimiento El tema de investigación, se encuentra incluido en una de las líneas del proyecto denominado "Sistemas de información y TIC: métodos y herramientas”. El mismo fue aprobado por la Secretaria General de Ciencia y Técnica (SGCyT) de la Universidad Nacional del Nordeste, Código Nº FO13-2011, y acreditado por Resolución Nº 142/12 C.S. de la UNNE.

Referencias 1. Fantasia, J.; Ferrochio, D.; Maldonado, C.; Martinez, E.;Trujillo, H.. Desarrollo de una metodología utilizable en la construcción de tecnología móvil. VIII Workshop de Investigadores en Ciencias de la Computación (WICC), XVII Congreso Argentino de Ciencias de la Computación.Smith, (2006).

2. Martinez, M. S.; Alfonzo, P; Mariño, S. I.; Godoy, M. V. Sistema informático para la gestión de espacios físicos. Una aproximación para la FaCENA (UNNE). Revista Internacional de Tecnologia, Conocimiento y Sociedad, http://ijtes.cgpublisher.com, Aceptado para su publicación (2013).

3. Boehm, B.: A Spiral Model of Software Development and Enhancement. IEEE. 61-72pp.

(1998).

4. Mariño, S.; Godoy, V.: Sistemas de información y TIC: métodos y herramientas. PI f013-11 Acreditado por la SGCyT. UNNE. Resol. 142/12 5. Pressmann R.: Ingeniería de Software: Un Enfoque Práctico. Ed. Pearson Education, S.A., Madrid. Edition 7º. (2007), 6. Sommerville, I.: Ingeniería del Software. Ed. Prentice Hall. (2005).

7. HTML, http://es.html.net 8. CSS, http://www.w3c.es 9. Jquery, http://www.javascriptya.com.ar/jquery 10. JavaScript, http://www.w3schools.com/js 11. Php, http://www.php.net 12. WampServer, http://www.wampserver.com 13. Dompdf, http://code.google.com/p/dompdf 14. Workbench, http://www.mysql.com/downloads/workbench 15. Notepad++, http://notepad-plus-plus.org 16. PhoneGap, http://www.phonegapspain.com 17. Android Studio, http://developer.android.com/sdk/installing/studio.html 18. Herrera, S I. y Fennema, M C. Tecnologías móviles aplicadas a la educación superior, IX Workshop Tecnología Informática aplicada en Educación (WTIAE), XVII Congreso Argentino de Ciencias de la Computación, (2011).

1219

Desarrollo de aplicaciones colaborativas para Cloud Computing María Murazzo1*, Nelson Rodríguez2*, Daniela Villafañe3*, Daniel Gallardo4# 1

marite@unsj-cuim.edu.ar, 2nelson@iinfo.unsj.edu.ar, 3villafañe.unsj@gmail.com, 4 dim_daniel87@hotmail.com

* Docentes e Investigadores, Departamento e Instituto de Informática – FCEFyN – UNSJ # Alumno Becario de la Carrera Licenciatura en Sistemas de Informacion

Abstract. En los últimos años se ha producido una masificación de las TIC (Tecnologías de la Información y las comunicaciones) como Internet, Social Medias, Cloud Computing, etc. Esto ha provocado en los usuarios un aumento de la interacción haciendo necesario contar con aplicaciones que le brinden la capacidad de intercambiar contenidos y colaborar en la realización de tareas conjuntas.

El objetivo de este trabajo es presentar una propuesta para el desarrollo de una aplicación colaborativa con herramientas propias de cloud computing y que será almacenada en el cloud y accedida mediante una interface de usuario ubicua y transparente al usuario.

Keywords: Aplicaciones Colaborativas, Cloud Computing, GAE

1

Justificación

Las nuevas tecnologías introducen diferentes formas de entender el trabajo, incrementando la colaboración del grupo para alcanzar metas comunes, tendientes a lograr una mayor productividad y rendimiento. Así, el usuario es parte de una comunidad conectada por medio de una red, ampliando los horizontes en investigación hacia la Interacción Persona – Computadora - Persona con tecnología basada en sistemas distribuidos de computación. El objetivo no es sólo mejorar la comunicación, sino generar un nuevo entorno que se comparte con otras personas pudiendo llevar a cabo actividades conjuntas bajo el paradigma de denominado Trabajo Cooperativo.

Esta colaboración, implica que el entorno de trabajo debe ser capaz de brindar a los usuarios la posibilidad de acceder a la información desde cualquier lugar, en cualquier momento y desde cualquier tipo de dispositivos. Estas características, exigen que las aplicaciones sean del tipo anywhere, cuya principal característica es la ubicuidad que les brinda a los usuarios.

En la actualidad, la ubicuidad y la colaboración solo pueden imaginarse de la mano de la omnipresencia tanto de los usuarios como de los contenidos generados por ellos.

1220

En este sentido un concepto capaz de soportar esta omnipresencia es el Cloud Computing.

Según el NIST (National Institute of Standards and Technology), se define Cloud Computing como un modelo de servicios escalables bajo demanda para la asignación y el consumo de recursos de cómputo. Esta definición, implica ver a los recursos como infraestructura, almacenamiento, ancho de banda, etc., como una utility más capaz de ser virtualizada para permitir a los usuarios generar contenidos consumidos por otros en forma colaborativa y ubicua.

La convergencia de Internet, la Web 2.0, el Social Media, el BigData y el Cloud Computing, han generado un ámbito propicio para el desarrollo de aplicaciones que permita a los usuarios no solo interactuar con sus aplicaciones sino convertirse en un generador activo de contenidos que serán virtualizados en una plataforma agnóstica.

En función de lo analizado, el presente proyecto de beca pretende abordar la problemática del desarrollo de aplicaciones que permitan fomentar la interacción de los usuarios, mediante el intercambio de contenidos virtualizables en el Cloud Computing.

2

Introducción

En los últimos años se ha visto evolucionar tecnologías vitales para el mundo organizacional en lo que a TIC’s se refiere, tales como los servicios de telefonía, las telecomunicaciones, los datacenter, etc.

Las organizaciones están preocupadas por brindar nuevos servicios reduciendo costos, Cloud Computing ofrece la posibilidad de dinamizar el abastecimiento de capacidades informáticas, en función de la demanda cambiante. Eficiencia y eficacia son conceptos que este modelo promueve a poyándose en la ubicuidad de Internet para ayudar a las empresas a extender su cobertura, llevando los recursos de TI a cualquier parte. Cloud Computing plantea un cambio de paradigma donde lo que antes era una propiedad, se convierte en un servicio, cambiando no solo la gestión de TI sino también la organización.

En este trabajo se realiza una integración entre un SaaS, un PaaS y un IaaS. El SaaS que se utiliza es el Google Apps que es una plataforma donde se realizan dominios para la empresa que lo utilizan. El SaaS Google Apps es una plataforma de comunicación y colaboración, ya que tiene múltiples funciones, no sólo proporciona correo electrónico sino que posibilita que los equipos de trabajo compartan calendarios (Google Calendar), documentación (Google Docs), o videos (YouTube) entre otros servicios (Google Sites, Gtalk, etc.). El PaaS / IaaS es Google App Engine, que es una plataforma que permite desarrollar, almacenar y ejecutar una aplicación web, en la gestión de centros de datos de Google. Todo esto programado con el lenguaje Python que permite a integración de la APIs de Google App en una aplicación desarrollada en Google App Engine [1].

1221

3

Cloud Computing

Es un modelo que permite a las diferentes empresas adquirir el uso de servicios y la entrega de recursos, que hace referencia a estar siempre conectado en el cloud (la nube o Internet) para recibirlos. Se podría decir que esto ya venía sucediendo, pero no en cuanto a un concepto integral y definido.

Así que la pregunta es, ¿por qué no conectarse a Internet y que alguien suministre todos los servicios de computación que la organización necesita de manera simple y se facture mensualmente por ello?, de esta forma todo lo que sea computación se convierta en una utility más.

Esta idea no es nueva, se viene trabajando en este concepto desde hace algunos años, ya que es la convergencia de modelos precursores como son Utility Computing, On Demand Computing, Elastic Computing o grid computing [2].

Internet usualmente se visualiza y conceptualiza como una gran nube donde todo está conectado y donde al conectarse se suministran todos los servicios requeridos. A este esquema de trabajo se lo denomina Cloud Computing, la cual es similar a todos los esquemas antes nombrados, pero potenciada con las tecnologías de virtualización [3].

El concepto de Cloud Computing tiene como principal característica, la transformación de los modos tradicionales de cómo las organizaciones utilizan y adquieren los recursos de Tecnología de la Información (TI).

Cloud Computing, representa un nuevo tipo de valor de la computación en red.

Entrega mayor eficiencia, escalabilidad masiva y más rápido y fácil desarrollo de software. Los nuevos modelos de programación y la nueva infraestructura de TI permitirán que surjan nuevos modelos de negocios.

La Cloud Computing es un modelo de aprovisionamiento de recursos TI que potencia la prestación de servicios TI y servicios de negocio, facilitando la operativa del usuario final y del prestador del servicio.

Una de las principales ventajas para las organizaciones que deciden incorporar a sus actividades servicios prestados a través de Internet es la posibilidad de reducir sus gastos de personal técnico, instalaciones, software y, sobre todo, de tareas de mantenimiento; de esta manera el retorno de la inversión es inmediato, ya que no es necesaria preinstalación ni configuración alguna.

Todo ello se realiza de manera fiable y segura, con una escalabilidad elástica, que es capaz de atender fuertes cambios en la demanda no previsibles a priori, sin que esto suponga un incremento en los costos de gestión.

La característica básica de este modelo es que los recursos y servicios informáticos, tales como infraestructura, plataforma y aplicaciones, son ofrecidos y consumidos como servicios a través de Internet sin que los usuarios tengan que tener ningún conocimiento de lo que sucede detrás.

La consultora Gartner, Inc. ha destacado las 10 principales tecnologías y tendencias que serán estratégicas para las organizaciones en 2013. Para Gartner una

1222

tecnología es estratégica cuando tiene el potencial para un impacto significativo en la organización en los próximos tres años. Los factores que indican un impacto significativo incluyen un alto potencial para la interrupción de TI o el negocio, la necesidad de una inversión importante, o el riesgo de llegar tarde a adoptar estos cambios.

Una tecnología estratégica puede ser una tecnología existente que ha madurado y/o adquiera la aptitud de una gama más amplia de usos. También puede ser una tecnología emergente que ofrece una oportunidad para la ventaja estratégica de negocios para los primeros adoptantes o con potencial de alteración en el mercado en los próximos cinco años. Estas tecnologías tienen un impacto tangible en la organización a largo plazo, planes, programas e iniciativas [4].

Dentro de estas 10 tecnologías, Cloud Computing ocupa el tercer lugar y predice que de a poco desplazara a la PC como entorno para que los usuarios guarden su información personal. Esto, se puede corroborar con la cantidad de contenidos que se suben a Internet o más precisamente al cloud, en la actualidad. Por ejemplo, cada minuto se suben 72 minutos de videos a YouTube, se envían 100.000 mail, se envían 277.000 tweets, se procesan 2 millones de búsqueda en google, se realizan 250.000 llamadas via Skype [5].

Cloud Computing es un esquema del tipo aaS o as a Service y que a veces se expresa como XaaS o EaaS para significar Everything as a Service. En general cualquier cosa como un servicio.

Se puede dividir al Cloud Computing en las siguientes capas: Software como Servicio (SaaS), Plataforma como Servicio (PaaS) y Infraestructura como Servicio (IaaS).

De esta forma cualquier organización que desee servicios de TICs podrá implementar un esquema XaaS y eliminar todos sus requerimientos internos y contratar sus necesidades en estas áreas externamente a cambio de un pago mensual, sin inversiones de capital [6].

4

Aplicaciones Colaborativas en el Cloud

Si bien el concepto de Aplicaciones Colaborativas no es nuevo, ha convergido para fusionarse con otras tecnologías como el Cloud Computing. De esta manera el usuario podrá acceder a aplicaciones que permitan la colaboración y el intercambio de contenidos de forma transparente, sin preocuparse de la heterogeneidad de formatos y la disponibilidad de recursos.

Estas características son muy importante considerando que las exigencias y requerimientos de los usuarios tanto a nivel profesional como social han cambiado y se han ampliado. Las principales características que requieren de las aplicaciones son ubicuidad, disponibilidad, omnipresencia, localización, inmediatez y personalización debido a estas exigencias, se hace necesario depender de la cloud para la distribución de los servicios.

1223

En este contexto, la convergencia del Cloud Computing y el Social Media ha provocado la necesidad de desarrollar aplicaciones que permitan la colaboración de usuarios los cuales trabajan en un ambiente de red distribuido. Además, será necesaria la interoperabilidad con aplicaciones de otros usuarios o con aplicaciones comerciales como GoogleDoc, Picasa, Facebook, etc., esto exige que las aplicaciones realicen el control de concurrencia y acceso a los recursos compartidos, con el objeto de salvaguardar la integridad y la consistencia de los contenidos.

En función de lo antes expresado, los usuarios necesitan aplicaciones que les permitan tener un ambiente de colaboración sin que se deban preocupar por detalles de diseño ni mantenimiento [7].

Además, y desde el punto de vista del desarrollador, esta forma de trabajo que plantea el Cloud Computing es interesante, pues tienen la posibilidad de realizar aplicaciones al estilo web service, los cuales podrán ser consumidos por cualquier otra aplicación. Estas aplicaciones podrán ser desarrolladas mediantes plataformas PaaS que permitan trabajar en un ambiente de recursos e infraestructura heterogéneos.

5

Selección de la Herramienta de desarrollo

Dada la relevancia que ha adquirido el paradigma “cloud computing” en los últimos años y el prometedor futuro que se le presupone por delante, son muchas las empresas y organizaciones que se han posicionado o intentan hacerlo sobre las demás ofreciendo este tipo de servicios. Entre ellas, destacan Google App Engine (GAE) [8], Amazon EC2 [9] y Windows Azure [10], que proveen aplicaciones comunes en línea accesibles desde un navegador web, mientras el software y los datos se almacenan en los servidores. Todas ellas se basan en el mismo paradigma, pese a que cada una posee sus particularidades y en algunos casos existen diferencias notables entre ellas.

En este trabajo, se ha decidido usar con la plataforma GAE debido a la posibilidad de manipular en forma nativa las API de Google.

6

Google App Engine (GAE)

GAE es una plataforma concebida para desarrollar, alojar y ejecutar aplicaciones web sobre la infraestructura Google. La plataforma hace uso del paradigma cloud computing, mediante la virtualización de aplicaciones a través los numerosos servidores de los centros de datos de Google, dispersos geográficamente.

La infraestructura Google es totalmente transparente para el cliente de los servicios cloud computing, quien se despreocupa de la gestión de los recursos utilizados, mientras que el usuario desarrollador por su parte es capaz de crear, mantener y actualizar sus aplicaciones. Se entiende como usuario desarrollador al programador de aplicaciones sobre la plataforma GAE, para que más tarde éstas sean ejecutadas por los clientes de los servicios. Al contrario que plataformas como Amazon EC2, que virtualizan a nivel de imágenes de máquinas virtuales, GAE ofrece su infraestructura para contener aplicaciones exclusivamente.

1224

7

Prototipo de la Aplicación

La aplicación que se decidió construir es un ambiente colaborativo de trabajo para las cátedras Redes de la LCC y Redes y Sistemas Distribuidos de la LSI, ambas pertenecientes al Departamento de Informática de la FCEFy N de la UNSJ. Para dicha aplicación se utilizo el framework Webapp y el lenguaje de programación Python. En la figura 1 se muestra un prototipo de la pantalla principal de la aplicación, en donde se marcan cada una de las secciones. menú

Figura 1: Pantalla principal del prototipo

A continuación se explica la funcionalidad de cada modulo: 1.

2.

3.

4.

5.

6.

7.

Panel de novedades donde se muestran todos los eventos y actividades que realizan los usuarios, como recomendaciones, resultados de evaluaciones y publicación de archivos.

Calendario que muestra gráficamente cualquier evento del usuario Panel que notifica los próximos 4 eventos del calendario Usuarios actualmente conectados Chat Panel con distintos elementos favoritos del usuario Búsqueda rápida en Google académico

Con respecto al menú, cada una de sus opciones se detalla a continuación: • Archivos: los usuarios tendrán la posibilidad de ver, descargar y subir archivos de tipo: Audio y videos, Documentos, Planillas de cálculo, Presentaciones, Formularios, Imágenes y dibujo. Además, tanto los documentos, planillas de cálculo, presentaciones, formularios y dibujos podrán ser visualizados y editados de forma simultánea por un conjunto definido de usuarios.

• Libros: el usuario podrá buscar, leer y compartir libros de Google Books.

1225

• Foros: contendrá un conjunto de foros categorizado por tema.

• Clases: se podrá acceder a un conjunto de clases presenciales grabadas en video o audio. La búsqueda se realizara por fecha.

• Eventos: Ver, crear y eliminar eventos para grupos de usuario tales como fechas de parciales, prácticos, resultados, etc.

• Evaluaciones: Se podrán crear evaluaciones escritas, prácticos, encuestas, etc para que realicen los usuarios, como así también ver los resultados obtenidos, un resumen y publicar los resultados.

• Grupos: Se podrán administrar grupos de trabajo, pudiendo asignar distintos privilegios, eventos y evaluaciones a cada grupo.

• Brainstorming: se permitirá generar distintas sesiones de brainstorming en el que podrán participar un conjunto de usuarios en tiempo real. Los resultados podrán ser guardados y vistos en cualquier momento.

Cabe destacar, la importancia del ambiente colaborativo, sobre todo en lo que ha manejo de recursos se refiere. En este caso se ha tratado de emular la forma en la que maneja el control de concurrencia DropBox, de esta manera no solo se podrán compartir documentos, sino también trabajar concurrentemente, sin preocuparse por la consistencia de los contenidos.

8

Conclusiones

Al igual que otros avances tecnológicos en el pasado, el cloud computing aporta nuevos retos y oportunidades a las organizaciones de TI y negocios. Si bien algunas de estas cuestiones son de carácter técnico (por ejemplo, rendimiento), otros son más organizacional (por ejemplo, ubicación de los datos). ¿Qué tan bien y qué tan pronto estas cuestiones se resuelven determinará si Cloud con el tiempo se consolida y puede cumplir lo que sus defensores prometen.

Este paradigma ha cambiado el centro de gravedad de la computación y tanto el ambiente académico como la industria, pero a pesar de los considerables esfuerzos e inversión existen varios problemas críticosque aun no han sido resueltos, como: portabilidad, protección de datos en ambientes Cloud, control de distribución de datos y latencia, sistemas de comunicación asíncronos en Cloud, paralelización, usabilidad de las interfaces, entre otros.

Aun a pesar de estas dificultades, el desarrollo de aplicaciones pensadas para que sean desplegadas en el cloud es auspicioso. No se puede dejar de lado la masificación de las actuales tecnologías que rodean a internet, como el cloud computing, la cual brinda la posibilidad de independizarse de la infraestructura de almacenamiento para centrarse en los contenidos, más que en el cómo hacer para que estos, estén disponible en todo momento para los usuarios.

1226

9

Bibliografía

[1] Rodriguez, Villafañe, Murazzo, Gallardo. “GAE, una estrategia para complementar SaaS y PaaS a través de la web”. 2° SABTIC. Tres de Maio, Brasil.

Agosto 2012 [2] Marston, Li, Bandyopadhyay, Zhang, Ghalsasi. “Cloud computing — The business perspective”. Decision Support Systems 51 (2011) 176-180. Elsevier. 2011.

[3] Lu, Hai-shan, Ting-ting.”Research on Hadoop Cloud Computing Model and its Applications”.2012. Third International Conference on Networking and Distributed Computing.

[4] Gartner. “Gartner Identifies the Top 10 Strategic Technology Trends for 2013”.

URL: http://www.gartner.com/newsroom/id/2209615.

[5] Murazzo, Rodríguez, Villafañe, González. “Análisis de grandes volúmenes de datos en el Cloud”. I Jornadas de Cloud Computing. La Plata, 17 al 19 de junio de 2013.

[6] Srinivasa Rao, Nageswara Rao, Kusuma Kumari, “Cloud Computing: An Overview”. Queue 7, 5 (Jun. 2009), 3-4.

[7] Murazzo, Rodríguez, Segura, Villafañe. “Desarrollo de aplicaciones para Cloud Computing”. CACIC 2010. Morón. Oct. 2010.

[8] Google, Inc. “Google App Engine (GAE)”. http://code.google.com/intl/esES/appengine.

[9] Amazon.com, Inc. “Amazon EC2”. http://aws.amazon.com/ec2.

[10] Microsoft Corporation.

“Windows Azure”. http://www.microsoft.com/windowsazure.

1227

“ASLX”: Semantic Analyzer for programming languages based on XML

Gabriela Yanel.Buffa, Franco Gaston.Pellegrini Licenciatura en Ciencias de la Computación Universidad Nacional de Río Cuarto

Abstract. XML (Extensible Markup Language) is a language used to structure information in a document or any file containing text. An XML document is "well formed" if respects their basic syntactic structure, that is composed of elements, attributes, and specified as XML comments. Some ways to verify that an XML file is either formed is by: Document Type Definition (DTD) and XML Schemas. But these types of verification not include relevant aspects, such as, the semantic relationship between content attributes and tags, declarations of fields and check the scope of variables, among others. This raises the need for a tool for verifying programming languages based on XML in the semantic aspect. In addition to analyzing the scope and usability of the tool was used as a case study the NCL declarative language.

Acknowledgements Mainly, we want to thank our families, who gave us the opportunity to study, to be where we are, who supported us from day one, whether in our achievements, failures and mainly because without their help it would have been impossible to reach these instances.

Also, thank you to those who helped us during this hard work, our Director Mg. Marcelo Arroyo, for proposing to address the issue, and our Director Dr. Francisco Bavera, being both present in each stage, mainly in every mistake, and without whom this work could not have been carrying out.

For my part (Yanel) I want to thank the angel that I have in heaven, "My Grandmother" or rather my second Mom, which helped me at the time to be here today and then from somewhere nursed and gave me strength each day to fulfill this achievement.

1228

1 Introduction This work aims to develop a solution to validate semantically languages programming or the like based on XML. In XML (Extensible Markup Language), XML files are text files where symbols "greater than" and "less than" are used to delimit the brands that give structure to document. Each brand has a name, let's see an example: The brand <figure>, may have one or more attributes: file="foto1.jpg" <figure tipo="jpeg"> In this case you have two attributes, "file" and "type".

The attributes have values that have to be in quotes or apostrophes, the marks cannot be left open, i.e., for each brand, for each brand, <figure> for example, there should be a mark </ figure> indicating where it ends for the content of the brand. That a document is "well formed" only refers to its basic syntactic structure is say, which is composed of elements, attributes and XML comments as specified to be written. Now, each XML application, i.e., each language defined with this technology, need to specify what exactly the relationship which must hold between items present in the document.

Some ways to verify that an XML file is well formed, is by: 1.

2.

Document Type Definition or DTD: Defines the types of elements, attributes and entities permitted, and can express some limitations to combine. XML documents that conform to your DTD are called valid.

XML Schemas: A Schema is similar to DTD defines which may contain elements XML document, how they are organized, what attributes and what type may have their elements.

Between the two types of verification, there are several fields that are not covered, and they are very useful for verify programming languages based on XML: 1. Semantic relationship between content attributes and tags.

2. Importing variables (and type) of another file.

3. Semantic verification of file formats to variables.

4. Statements Scopes and variable scope verification.

5. Conditional checks the contents of an attribute.

Some of these can be done in a very basic way using regular expressions in XML Schemas, but the problem is limited to a particular attribute and not the relationship between several.

This raises, the need for a tool for verifying programming languages based in XML or similar in the semantic aspect. In short, to develop an application that can extend verification of validity that provides XML with the above points and more.

To apply our tool to a real problem, it was decided to use it to validate semantically source code of declarative language NCL.1. Create NCL applications is not very difficult for people in the field of programming, requires prior learning which is difficult because such language has only one basic data type ("String") which is used to reference to any basic entity or media item (video, image, etc.), and interpretation tools Ginga-NCL do not provide basic facilities of a modern compiler for relevant reports to the user from their errors.

1

Gomes Soares, Luis Fernando: “Programando em NCL”: Desenvolvimento de aplicações para middleware Ginga, TV digital e Web. (2009).

1229

In this way and as previously mentioned, according to our knowledge, "ASLX" is the first semantics tool for the NCL language and one of the few semantic tools for XML-based languages or similar.

1.1 Development Objectives: Considering that: â&#x20AC;˘ â&#x20AC;˘ â&#x20AC;˘

It is very complex to find errors in a program if the compiler does not help.

Find and correct errors confusing error outputs watching is very productive.

That does not even cover all aspects of verification to verify if a file XML is well formed.

Main objectives are proposed, creating a semantic validator detected in the lower long as possible the different semantic errors and / or syntactic language can have a programming based on XML. The tool can display a detailed report of the errors, thus this tool can be of great help to many developers at the time to correct their applications, since providing a detailed analysis may go directly to the point of failure and fix it. Another feature that should have the program, is to be used as a library (so that for example an IDE can leverage the speed and advantages of this solution).

Moreover, considering that Ginga-NCL does not verify semantics, such language was used as a case study and test, to thereby verify the semantic concepts (like well as in the syntax) that verifies GingaNCL alone.

1.2 Using a Scripting Language A scripting language is a type of programming language that is generally interpreted (as opposed to compile). A script can be seen as a program that can accompany a document HTML or contained inside. The scripts remain in its original form (your source code Text) and are interpreted command by command whenever running.

Scripting language features: 1.

2.

3.

4.

5.

Scripts are usually written more easily, but at a cost of its execution.

Usually implemented with interpreters rather than compilers.

They have strong communication with components written in other languages.

The scripts are usually stored as plain text.

The codes are usually smaller than the equivalent in the language of compiled programming.

In developing this tool, the Scripting language to create semantic rules are designed with the aim of providing comprehensive solutions to different problems that only verify semantics of a single language (eg Ginga-NCL). Through this mechanism, it can be adapted our program to verify semantics of programming languages based on XML.2 A Script begins with a tag called "semanticParser" which has reference to the schema script. Must also be specified using the attribute "fileFormat" a list (separated by commas) of extensions this script supports to validate.

Then, within the tag "rules" specifies all the rules. For this example we want to set a set of rules that should be applied only to tags labeled with the name "media". With this objective stated in the "name" attribute on the tag "tag" value "medium".

2

For more information on scripting languages and their use in this tool, refer to Chapter II of the full report of the developed tool "ASLX".

1230

2 Design 2.1. General Design The development process is centered on a defined architectural with rules developed in a script based in XML. First developed an XML schema "ScriptParserSchema.xsd", in the defined a language for creating scripts with the semantic rules to check.

Given the complexity, it was decided to design incrementally. Our program takes the script and a code based on XML as a parameter, follow the rules defined in the script and try to validate the XML code reporting errors or warnings.

Subsequently, we studied the specific failures of Ginga-NCL for rules and / or tools needed to incorporate.3 In the case of Ginga-NCL designed a script, "semanticCheck.xml" with all the rules semantics of the same so that by giving one or more files with NCL code, the program can verify and create a report. This is defined by regular expressions and rules (applied to "Tags") the conditions to be met by any program NCL to be a valid application free the semantic errors.

The program was divided two sections: “Parser” and “Validator”. If no syntax errors, the Parser interprets the rules defined in the script and generates a Validator results. This Validator is used to check the rules on one or more files with the format specified in the script.

The basic set of rules that recognizes Parser is: 1.

2.

3.

4.

5.

6.

7.

8.

Existence of an attribute with a given name.

Right contents of an attribute or content right relationship between various attributes.

Check existence of local or external files.

Creating objects / variables referenceable.

Type checking (for references to objects / variables created).

Include code from other files.

Check text content of an XML node.

Conditional validation rules.

2.2 Structure and Course of an XML file The design for parsing XML files based on the use of API "SAX" and "DOM". These APIs are two tools used to analyze XML and define the structure of a document, although there are many others.

2.2.1 Using DOM and SAX in the design Because SAX is more complete for information storage, and DOM is simpler to use since there is no need to implement a tree like structure data, we decided to combine both.

By SAX modify the XML file parsed nodes and we add location (for which line of code is the node). Using DOM created the tree data structure to tour files easily without having to implement anything. Also used SAX to validate XML files as one XML Schema, useful to verify that the script and files to be verified with a base stable.

3

Gomes Soares, Luis Fernando. “Programando em NCL”: Desenvolvimento de aplicações para middleware Ginga, TV digital e Web. 2009.

Associacao Brasileira de Normas Técnicas. “ABNT NBR 15606-2”: Televisão digitalterrestre – Codificação de dados e especificações de transmissão para radiodifusão digital.

1231

3 Implementation 3.1 Introduction As programming language Java 7 was chosen only by two important features: 1.

2.

3.

Write software on one platform and run it on virtually any other platform.

Simple to produce code quantity and quality (productivity).

SAX and DOM are included in the standard library.

For technical implementation details, refer to the technical documentation of the code (Javadoc or code).

In this section we discuss only general details of the source code.

3.2 Implementation Details The entire project was created under the IDE NetBeans4, which facilitates file "build.xml" to compile your code without the need to install this IDE. Using Apache ant5 can run the file "build.xml" and automatically generate Javadoc documentation and executable JAR extension.

Since the design is very simple because it uses DOM and SAX to parse the scripts and validate files, only discussed in this section general details of the most important classes of program. For details, refer to the technical report or the source code.

3.2.1 Parser (ScriptParser.java) You cover all valid nodes recursively with the defined rules (script) using an algorithm.6 Whenever the node name matches the name of a reserved word of the script, it acts according to the meaning of it by creating rules, ER-Ex (patterns) or containers of rules associated with a tag (TagValidator.java). To facilitate the implementation and script writing, all white characters of ER-Ex will be ignored. If needed them, using suitable escapes characters.

To solve the macros of the ER-Ex, the parser tries to do the translation of the macro only one time, and stores the results. Since a macro always comes down to the same ER, is efficient only calculate this reduction only once. This allows more efficient management of memory and speed parsing. Also added is a limit to the calculation of the macros, as solving recursively ill-defined macro can stop the program in a state of infinite calculation. After obtaining the ER and rules, this returns a Validator

3.2.2 Container Rules (TagValidator.java) and Validator (Validator.java) Represents a set of rules only applicable to a particular tag. They are stored rules created by the script ready, for easy retrieval. It all nodes recursively valid XML file being checked by the algorithm, and if the name of some of the nodes are in the container list of rules (TagValidator) apply all the rules contained therein to validate that node / tag.nodes in the container list of rules (TagValidator) apply all the rules that thiscontains to validate that node / tag.

4

http://netbeans.org http://ant.apache.org 6 Algorithm described in the section "General Program Design", Chapter II of the full report of the developed tool "ASLX".

5

1232

4. Testing 4.1 Introduction The tests performed to verify the correct operation of the program, were of “Black Box”. JUnit was used to design a set of test cases and found as it implemented would program the outputs are exactly as expected. The most complete test case is the demonstration of the script with validation rules semantics for Ginga-NCL language which uses most of the functionality of the program in a real case. All tests are described next to the source code and technical reports.

4.2 Optimizations The first tests performed were of optimization. The evaluation was specifically related to the response time of the main data structures and management of ER-Ex. We implemented five versions of the program, which were evaluated with 4 different scenarios.

The 5 versions had the following characteristics: Version

Characteristics

1

No optimizations

2

The ER equal solved only 1 time

3

The ER-EX Macros are solved only 1 time

4

Macros and ER are stored in HashMap instead of SortedMap (TreeMap)

5

HashMap across data structure that requires searchesin Validator and Parser

Each version has included optimizations of the previous version.

All performance measures were obtained on a Notebook with an Intel ® Core ™ i7-2630QM CPU@2.00GHz × 8 and 4Gb DDR3 RAM under Ubuntu 10.04 64bit (Linux kernel 3.2.0-25-generic).

The results were: Version 1 Stage

The average time (ms)

ER created

ER reused

Macros analyzed

Macros reused

1 2 3 4

13 938 2477 17202

4 5000 5000 20

0 0 0 0

7 0 0 2334634

0 0 0 0

Three versions were made with the same number of stages, which will be omitted in this report.7

7

For more details refer to Chapter V of the full report of the developed tool "ASLX".

1233

The following shows in detail the latest version and optimizations with respect to the first:

Version 5 Stage

The average time (ms)

ER created

ER reused

Macros analyzed

Macros reused

1 2 3 4

6 700 166 2717

4 5000 100 10

0 0 4900 10

4 0 3 104

3 0 5049 2

This version besides being faster (in some cases) use less RAM than other versions, reason why it was chosen as the implementation.

4.3 JUnit and Test Scenarios of Script Language For proper implementation incrementally, we chose to go to implement the program validating it through the JUnit8 framework. JUnit return to class method successfully passed the test, if the expected value is different from that returned during the execution method, JUnit failure to return a corresponding method. JUnit is also a means of controlling regression testing, necessary when part of the code has been modified and you want to see the new code meets the above requirements and has not altered its functionality after the new amendment.

4.4 "Testing Case 4.4.1 Syntax Errors in XML Schema of Ginga-NCL. For the testing phase, extracted oficial book9, a total of 33 Ginga XML schemas-NCL. A Below is a detail of the scheme that had errors, the page which can be found in oficial book, a detail of the errors and possible solutions that could be implemented, taking into tool has developed "ASLX" to thus be valid applications.

"CausalConnector.xsd": The scheme is located on page number 48 of the official book.

Code where the error (line 40): <complexType name="nclType"> <complexContent> <restriction base="structure:nclPrototype"> <sequence> <element ref="structure:head" minOccurs="0" maxOccurs="1"/> <element ref="structure:body" minOccurs="0" maxOccurs="0"/> </sequence> </restriction> </complexContent> </complexType>

8

http://www.junit.org// Gomes Soares, Luis Fernando. “Programando em NCL”: Desenvolvimento de aplicações para middleware Ginga, TV digital e Web. 2009.

9

1234

Error type: cos-particle-restrict.2: Forbidden particle restriction: 'choice:all,sequence,elt'.

Solution Defining the maximum of occurrences (maxOccurs) body structure is 1 instead of 0.

4.4.4 Syntactic errors in examples official Ginga-NCL. We extracted all the code examples from the book mentioned above for official to use them as evidence. In this way we obtained a total of 20 examples which first syntactic errors were corrected.

Beyond that the tool developed to detect syntax errors to achieve fully valid applications, as the main objective is the semantic, are omitted in this report10.

4.4.5 Semantic errors in examples official Ginga-NCL. Were detected errors in the following examples Ginga-NCL. These errors were found by the validator semantic created. As noted, various examples were no syntax errors, if they have them in the semantic aspect. In the absence of the tool created, these examples would be considered valid when in fact they are not.

“Example 1”: This example is the initial release of the NCL document "O Primeiro João". This example can be seen on page number 51 of the official book.

Code where the error (line 36): file:Ejemplo1.ncl: line:36: not declared in this scope. file:Ejemplo1.ncl: line:45: declared in this scope. file:Ejemplo1.ncl: line:49: declared in this scope. file:Ejemplo1.ncl: line:53: declared in this scope.

The symbol "conEx#onBeginStartDelay" is The symbol "conEx#onBeginStart" is not The symbol "conEx#onBeginStart" is not The symbol "conEx#onEndStop" is not

Solution CausalConnBase.ncl Define a new file, which contains each of the connectors for compiling the examples present in Ginga-NCL. In this case specifically defined in the file, the connectors "onBeginStartDelay", "onBeginStart" and "onEndStop".

10

For more details refer to Chapter V of the full report of the developed tool "ASLX".

1235

Below is a table show examples present in the official book of GINGA_NCL possessing semantic errors: Example

Description

Error line

Error type

Solution

Example 3.15 (Page 56)

Application to sync by interaction Application to Reuse

41-50-54-58-6367-77

Elements are not declared In this scope.

43-47-57-6473-77-81

Elements are not declared In this scope.

Application to channel interactive Application with content adaptation Applicationcontrolled interactive ads.

47-51-62-69- 78

Elements are not declared in this scope.

60-64-75-8291- 95-99

Elements are not declared in this scope.

53-60-66-7098-100-103-114121-130- 134138

Elements are not declared in this scope.

Invalid value in attribute "role".

Define the file causalConnBase.ncl the connectors.

Define the file causalConnBase.ncl the connectors.

Define the file causalConnBase.ncl the connectors.

Define the file causalConnBase.ncl the connectors.

Define the file causalConnBase.ncl the connectors.

Give a valid value to the attribute "interface" and to attribute "role".

Example 3.37 (Page 85)

Application purposes animations and transitions

60-67-77-80-85 90-120- 127136-140

Elements are not declared in this scope.

Invalid value in attribute "interface".

Define the file causalConnBase.ncl the connectors.

Give a valid value to the attribute "interface"

Example 3.45 (Page 95)

Application menu with navigation keys

Elements are not declared in this scope.

Define the file causalConnBase.ncl the connectors.

Example 3.52 (Page 105)

Application in order NCLua

72-79-89-117122-133-139167-174-185194-198-207213 60-74-81-91120-122-125136-142-156175-185-199208-212-221229

Invalid value in attribute “end” y “role”.

Elements are not declared in this scope.

Give a valid value to the attribute "interface" and attribute “role” Define the file causalConnBase.ncl the connectors

Example 7.1 (Page 144)

Example showing the interactivity of a "button" for a fixed time

18

The symbol "dTVtelaInteira" is not declared in this scope <even forward>.

Writing the shape descriptor correct.

Example 3.19 (Page 63) Example 3.22 (Page 67) Example 3.27 (Page 73) Example 3.32 (Page 79)

Developed tool also found errors in the examples: "10.12" (page 199), "10.14" (page 202), "12.4" (page 234), "14.4" (page 259), "14.6" (page 268), "15.3" (page 272) "15.6" (page 274).

In case you want to see in detail this type of error, refer to Chapter V of the full report tool developed "ASLX".

1236

References 1.

2.

3.

4.

5.

6.

Gomes Soares, Luis Fernando: “Programando em NCL”: Desenvolvimento de aplicações para middleware Ginga, TV digital e Web, (2009).

Associacao Brasileira de Normas Técnicas: “ABNT NBR 15606-2”: Televisão digitalterrestre – Codificação de dados e especificações de transmissão para radiodifusão digital.

Parte 2: Ginga-NCL para receptores fixos e móveis – Linguagem de aplicação XML para codificação de aplicações (2007).

Gomes Soares, Luis Fernando and Ferreira Rodrigues, Rogerio: “Nested Context Language 3.0 , NCL Digital TV Profiles” (2006).

Soares, Luiz Fernando Fernando Gomes: “Construindo Promgramas Audiovisuais Interativos Utilzando a NCL 3.0 e a la Ferramentea Composer” (2007).

Zambrano, Arturo: “Introducción a la TV Digital Interactiva y Ginga.ar”- Universidad Nacional de La Plata. La Plata – Argentina.

Balaguer Federico & Isasmendi, Leonardo: “Desarrollo de Aplicaciones para Televisión Digital”. Universidad Nacional de Río Cuarto. Rio Cuarto - Argentina (2011).

1237

Sistema Guía para Personas con Deficiencia Visual Pablo Richard, Daniel Richard, Marcos Aranda

Universidad Nacional de Catamarca {pablorichard885, danielrichard86, marcos_dario_1}@hotmail.com

Resumen. En este artículo se presenta un sistema guía para personas con deficiencia visual basado en la construcción de un dispositivo electrónico de sensado, una aplicación móvil cliente y la comunicación y sincronización entre las partes. Este producto ayudará a las personas que padecen esta patología a desenvolverse independientemente en su entorno, ya que detecta la presencia de objetos que obstaculizan el desplazamiento. La aplicación corre en un dispositivo móvil y se adapta a las necesidades de cada usuario. El sistema incluye la construcción de un dispositivo con sensores ultrasónicos de distancia desarrollado con tecnología PIC, el cual se comunica con una aplicación móvil desarrollada en Java para Android que se ejecuta en un teléfono celular. Se utiliza el paradigma de programación orientado a objetos para el desarrollo de la aplicación debido a que permite la reutilización y extensión del código. De acuerdo a las pruebas funcionales realizadas, es factible la implementación exitosa del sistema.

Palabras Claves. Aplicación móvil, sistema guía para deficiencia visual, PIC, sensores ultrasónicos de distancia, distanciómetro, orientación a objetos.

1. Introducción Los problemas de visión acarrean a las personas que los padecen una serie de obstáculos que, para ellos, se transforman en grandes retos a superar. Esto se pronuncia aún más en una sociedad muy dependiente de los estímulos visuales en la vida cotidiana (letreros, televisión, imagen social, computadoras, etc.). Es necesario diferenciar a las personas que sufren estos padecimientos en algún momento de su vida en forma aguda, de aquellas que lo padecen de nacimiento o de muy temprana edad; para los primeros es mucho más difícil porque tienen que adaptarse a un nuevo estilo de vida.

Los avances tecnológicos y la evolución de la computación brindan recursos para poder desarrollar herramientas que ayuden a estas personas con algunos de sus problemas cotidianos.

El desarrollo de este proyecto tiene como objetivo brindar un sistema que le ayude a las personas con deficiencia visual a desenvolverse de una mejor manera en su entorno. Para ello se realizó la construcción de un dispositivo electrónico con microcontroladores y sensores, que es capaz de capturar y manejar información del medio (hardware del sistema), que se relaciona con la aplicación (software del

1238

2

Pablo Richard, Daniel Richard, Marcos Aranda

sistema) para que la misma haga uso de esta información, lo cual dio el soporte necesario para poder obtener los datos suficientes del entorno donde se mueven.

La conexión entre el dispositivo electrónico y la aplicación se realizó mediante Bluetooth lo que permite la comunicación y sincronización de las partes del sistema, para ello se implementaron librerías para manejo de la tecnología anteriormente mencionada y se estableció un protocolo de comunicación para su uso.

La aplicación reconoce el medio o el entorno fijo y también es transportable, permitiendo el desplazamiento del usuario.

Actualmente, los dispositivos móviles (celulares, tablets, laptops, etc.) son capaces de correr aplicaciones que son de uso cotidiano en la vida de cualquier persona. Esto es lo que motivó a desarrollar software ejecutable sobre estos dispositivos.

El sistema detecta la ubicación de los objetos alrededor de personas con deficiencia visual y los guía en decisiones referidas a su movilidad. Está compuesto por: una aplicación móvil y un dispositivo de sensado ultrasónico de distancia. La aplicación corre en un dispositivo móvil (celular, notebook, etc.) que tenga sistemas operativo Android con versión 2.5 en adelante, e indispensablemente una conexión Bluetooth, ya que se conecta al dispositivo de sensado a través de Bluetooth. El dispositivo se desarrolló utilizando microcontroladores PIC.

2. Desarrollo del sistema El sistema abarca la construcción del dispositivo electrónico, del desarrollo de la aplicación móvil y la comunicación entre el dispositivo y la aplicación.

Para el desarrollo de este sistema se emplearon diversas tecnologías para las diferentes partes que componen el sistema.

El dispositivo electrónico está compuesto por un microcontrolador PIC 18F4550 que es la unidad central del mismo, un sensor ultrasónico Parallax, un display LCD y un módulo bluetooth para establecer la comunicación con la aplicación del dispositivo móvil. Para la implementación de la aplicación, se utilizó un dispositivo móvil LG L7, pero puede utlizarse cualquier dispositivo móvil que posea Android desde la versión 2.2 en adelante y una comunicación bluetooth.

A continuación se describe la construcción del dispositivo electrónico y de la aplicación.

2.1. Diseño y construcción del dispositivo electrónico En este apartado se describirán toda la ingeniería que se aplicó para diseñar y construir el dispositivo electrónico distanciómetro encargado de medir la distancia entre el usuario y el objeto.

Diseño general del sistema de medición de distancias por ultrasonido: En la figura 1 se presenta un diagrama en bloques, el cual describe en forma general los elementos principales del distanciómetro.

1239

Sistema Guía para Personas con Deficiencia Visual

• •

•

•

3

Oscilador: El cuál es el encargado de entregar al sistema la onda cuadrada, cuya frecuencia es ultrasónica de 40 KHz. Modulador: Tiene la función de generar ráfagas de ondas ultrasónicas, o sea, funciona como una llave electrónica que deja pasar una cantidad de pulsos limitados provenientes del oscilador.

Amplificador: Ésta etapa adapta las ráfagas ultrasónicas a niveles de tensión adecuados para el trabajo del transductor transmisor. En el caso del receptor, se amplifica la señal para que pueda ser procesada adecuadamente por el sistema de control, dado que la misma llega disminuida al receptor.

Sistema de control: es el cerebro del sistema, sobre el cual corre el programa que controla todos los bloques.

Figura 1. Diagrama de bloques de un distanciómetro ultrasónico.

Circuitos para transmisión y recepción de ultrasonidos para la medición de distancias: En el circuito transmisor, se generan ráfagas de 40 KHz con duración de 200 microsegundos, cada 65 microsegundos, al detectar la onda reflejada se genera una interrupción la cual detiene un temporizador (timer) de 16 bits del microcontrolador.

Transmisor ultrasónico: El transductor utilizado para la transmisión es el piezoeléctrico N1076, controlado por el microcontrolador PIC12C508, el cual se encarga de enviar el tren de pulsos de 40KHz para que el cristal emita la frecuencia de ultrasonido deseada. Dado que el transmisor empleado soporta una tensión de entrada de hasta 20 Vrms, se incluye el acoplamiento con el componente ST232 entre el microcontrolador y transductor el cual permitirá una tensión de entrada al emisor de aproximadamente 16 V [1].

Como se mencionó, el microcontrolador es el “cerebro” de la operación. En él corre el programa que permite la generación de las ráfagas ultrasónicas.

En la figura 2 se muestra el esquema del transmisor, representado mediante la utilización del software de diseño y simulación electrónica MULTISIM:

1240

4

Pablo Richard, Daniel Richard, Marcos Aranda

Figura 2. Diagrama de conexión del circuito emisor ultrasónico. Fuente: www.uhu.es/antonio_peregrin/iaic_abierto/SRF04.PDF.

Receptor ultrasónico El receptor se compone de dos circuitos amplificadores de señal y un circuito de detección.

La señal es recibida por el sensor receptor y amplificada 576 veces en dos pasos por 2 amplificadores por 24. En esta etapa se hace uso de los circuitos integrados LM1458 cuyo ancho de banda es 1 MHz, cuya máxima ganancia corresponde a la frecuencia de 40 KHz.

Figura 3. Diagrama de conexión del circuito receptor ultrasónico. Fuente: www.uhu.es/antonio_peregrin/iaic_abierto/SRF04.PDF.

Como puede verse en la figura 3, en la salida de las etapas amplificadoras hay un comparador (LM311), el cual tiene como entradas la señal proveniente del receptor (entrada positiva) y la señal del transmisor (señal negativa). Se agrega además una realimentación positiva por medio de la resistencia de 62 KΩ para agregar histéresis, dando estabilidad a la salida del comparador.

Por último, el resultado de la comparación es procesado por el microcontrolador PIC 12C508, el cuál detiene el conteo del temporizador cuando ésta señal llega.

Funcionamiento

1241

Sistema Guía para Personas con Deficiencia Visual

5

Tal y como se muestra en el diagrama de tiempos de la figura 45, el funcionamiento es descrito, por parte del usuario y por medio del microcontrolador PIC 18F4550, un pulso de disparo o “trigger” de 2 microsegundos que inicia la secuencia. Por medio del transductor Tx se transmite un tren de pulsos o “burst” (ráfaga) de 200 microsegundos a 40KHz. En ese momento, el microcontrolador PIC18F4550 debe cambiar su condición de salida a entrada para esperar por el mismo pin la señal de “eco”, por lo tanto en este momento se envía al PIC 18F4550 un “1” lógico. Cuando la cápsula receptora recibe la señal transmitida como consecuencia de haber rebotado en un objeto (eco), se envía al PIC18F4550 de nuevo un “0” lógico. En este microcontrolador se realiza la medición de la duración del pulso de ésta señal, es decir, el tiempo en que la señal recibida anteriormente se mantiene a “1” [2].

Con objeto de que el sensor se estabilice, se deja un pequeño intervalo de tiempo de 10ms como mínimo entre el momento en que la señal de eco pasa a “0” y un nuevo pulso de disparo que inicie el siguiente ciclo o nueva medida.

Figura 4. Diagrama de tiempos del funcionamiento del sensor ultrasónico. Fuente: www.parallax.com/dl/docs/prod/acc/28015-PING-v1.3.pdf

Como muestra el gráfico, existen 2 límites de tiempo: el tiempo mínimo de 115 microsegundos, es el fijado por el software y corresponde a la medida de 3 cm aproximadamente, puesto que medidas por debajo de los 3 cm provocan una serie de errores derivados del acoplamiento entre las propias cápsulas emisor-receptor del módulo, por lo que es muy difícil distinguir si la señal recibida es consecuencia de dicho acoplamiento o del eco recibido [3].

Por otra parte el tiempo máximo es de 18.5 milisegundos, el cual corresponde a una distancia aproximada de 3 m. Este límite también impuesto por el programa + 10 milisegundos de resguardo, es el tiempo que se debe esperar para que el PIC18F4550 conmute nuevamente su pin a entrada para generar un nuevo disparo de activación de secuencia.

1242

6

Pablo Richard, Daniel Richard, Marcos Aranda

Para mayores distancias nos podemos encontrar con problemas derivados de la dispersión del haz ultrasónico o de múltiples rebotes que pudieran generarse.

Funcionamiento PIC 18F4550 El programa que corre en el PIC, comienza con la generación y envió del pulso de disparo de inicio de secuencia de 10 microsegundos de ancho a través del pin 20, para que se genere el burst. Inmediatamente el pin 20 conmuta su configuración convirtiéndose en entrada y se prepara para recibir el pulso de eco, cuyo ancho varía dependiendo de la distancia en la que se encuentre el objeto. Durante ese tiempo se activa un temporizador interno (timer), que lleva el conteo de la duración del pulso de eco. A continuación esta cuenta es almacenada por el PIC, donde se produce la multiplicación por factores de escala con el fin de llevar esa medición a centímetros.

Luego este dato es mostrado en el display LCD. Por último el programa retorna a la rutina de generación del disparo para iniciar una nueva secuencia de medición produciendo un bucle constante.

A continuación se muestra una simulación del dispositivo electrónico en el software ISIS Proteus que nos permite no solo plasmar nuestro diseño, si no cargar el programa en el PIC y simular su funcionamiento.

Figura 5. Simulación, lectura de distancia en display LCD.

Montaje en placa experimental Como se observa en la figura 5, la simulación de la funcionalidad principal del dispositivo electrónico, calcular la distancia entre el usuario y el objeto, trabaja de forma correcta entonces plasmamos nuestro diseño en una placa de prueba obteniendo un resultado físico del mismo. Esto se puede apreciar en la figura 6.

1243

Sistema Guía para Personas con Deficiencia Visual

7

Figura 6. Imagen del prototipo.

Construcción del dispositivo segmento para la comunicación Lograda la función principal del distanciómetro, adaptaremos el módulo Bluetooth RN-42 al prototipo para establecer la comunicación inalámbrica con la aplicación.

Este es un módulo de clase 2 que permite la comunicación inalámbrica por enlace bluetooth con un alcance de hasta 20 mts posee un protocolo de saltos de frecuencia que le permite actuar en ambientes con interferencias, un protocolo de control de errores para la comunicación por bits de paridad y para la transferencia de datos utiliza la conmutación de paquetes y circuitos.

En la figura 7 se puede ver el dispositivo electrónico terminado montado en una placa fija.

Figura 7. Dispositivo en placa fija.

1244

8

Pablo Richard, Daniel Richard, Marcos Aranda

2.2. Comunicación entre el dispositivo y la aplicación En este apartado se describirán las librerías utilizadas, tanto a nivel software como firmware para realizar la comunicación entre el dispositivo electrónico denominado distanciómetro y la aplicación.

Por parte del dispositivo electrónico se utilizaron librerías para la comunicación serial asincrónica ya que el modulo bluetooth RN-42 se conecta por los pines del PIC de comunicación serial y actúa como un adaptador para la transmisión por aire.

Por parte de la aplicación se implementaron las librería que proporciona el api de google para comunicación bluetooth con android que disponen un conjunto de clases numerosas que permite manejar los recursos para llevar a cabo un enlace bluetooth con el dispositivo móvil. [5,15].

2.3. Desarrollo de la aplicación La aplicación trabaja con la información recibida del Distanciometro; por lo tanto cuando éste inicia se debe conectar con el mismo. El distanciómetro a través del modulo bluetooth RN 42 le envía el dato de la distancia que se encuentra el mismo ante un objeto, el programa que corre en el dispositivo móvil recibe el dato por en el enlace bluetooth que establece con el distanciometro y analiza este valor, emitiendo un sonido o una vibración, indicándole al usuario en la situación que se encuentra para que decida como actuara respecto a la misma.

Para esto se contemplaron 3 posibles casos: • Sonido 1 o vibración 1: esta situación se dispara cuando el valor de la distancia recibida entre el distanciómetro y el objeto no representa peligro alguno para el mismo.

• Sonido 2 o vibración 2: esta situación se dispara cuando el valor de la distancia mencionada representa un cierto grado de peligro para el mismo.

• Sonido 3 o vibración 3: esta situación se dispara cuando el valor de la distancia mencionada representa peligro para el mismo.

El programa realiza esta acción cada un segundo mientras el usuario no se desconecte del dispositivo o cierre la aplicación, esto se lleva a cabo mediante un timer.

La aplicación permite la configuración de los parámetros de distancia que se ajustarán a los casos de decisión posible adaptándose a las necesidades de cada usuario a la hora de transportarse.

En cuanto al desarrollo de la aplicación, se siguió un método orientado a objetos.

En la figura 8 se presenta un diagrama de las clases relevantes que intervienen en el sistema, que definen el contexto del mismo. En la figura 9 se presenta un diagrama de secuencia que demuestra la forma que interactúan los procesos y los actores que intervienen en el sistema.

En la figura 10 se muestran la interfaces del sistema, que consta de 3 pantallas sencillas e intuitivas.

1245

Sistema Guía para Personas con Deficiencia Visual

9

Figura 8. Diagrama de clases del sistema.

Figura 9. Diagrama de interacción.

La primera pantalla de la figura 10, es la de inicio del sistema que está dispuesta por un menú, “Comenzar” nos envía al sistema de guía con valores predeterminados, “Configuración” nos permite configurar los parámetros de distancia y alertas con el que correrá el sistema de guía y “Salir” permitirá cerrar la aplicación y liberar recursos del dispositivo móvil. La Segunda pantalla es la de Configuración del sistema acá se puede configurar los valores de distancia que se adaptaran de acuerdo a la necesidades del usuario es decir a sus patrones de movimiento. La tercera pantalla es la Principal dispone un sistema de guía intuitivo, compara los valores que son enviados por el distanciometro con los que configuro al usuario y emite un sonido o vibración que indica al usuario la situación en que se encuentra.

1246

10

Pablo Richard, Daniel Richard, Marcos Aranda

Figura 10. Pantallas de inicio, de configuración y de uso del sistema.

3. Conclusiones Se concluye que, con la utilización de nuevas tecnologías y la evolución de la computación, se obtuvieron los recursos necesarios para desarrollar una aplicación para dispositivos móviles con sistema operativo Android y construir un dispositivo electrónico seguro y robusto, que actuando en forma conjunta conforman un sistema de guía que resuelve la problemática de poder transportarse de forma independiente y segura que padecen las personas con deficiencia visual.

El diseño del sistema no solo cumple con los objetivos del proyecto si no también brinda una solución simple, ya que los dispositivos móviles son un elemento común en la vida cotidiana de cualquier persona, además este diseño le permite al sistema crecer potencialmente teniendo en cuenta todas las funcionalidades que proporciona un dispositivo móvil. De esta manera, se podrá satisfacer otras demandas o necesidades del usuario a futuro.

4. Referencias 1.

2.

3.

4.

Angulo J., Microcontroladores PIC: Diseño Práctico de Aplicaciones. 3ª Ed. Madrid -España: McGray-Hill, (2003).

Corrales S., Electronica Práctica con Microcontroladores PIC. Quito-Ecuador: Imprenta Grafica, (2006).

Daniel Benchimol, Microcontroladores. Buenos Aires: Fox Andina, (2011).

Donn Felker y Joshua Dobbs (2011), Android application development for dummies. Indiana: Wiley Publishing, Inc.

1247

Automatización en la Captura de Datos para el Modelado de Flujo Vehicular Julio Monetti, Mariana Brachetta y Oscar León Universidad Tecnológica Nacional – Facultad Regional Mendoza Rodriguez 273- Mendoza - Argentina {jmonetti,mbrachetta,oleon}frm.utn.edu.ar

Resumen. El trabajo presenta experiencias en el modelado de datos sobre la dinámica vehicular en zonas urbanas. A partir de la investigación sobre software que permita realizar modelos de tránsito, surge luego la propuesta de crear nuevas estructuras de datos, modelos para simulación y un software que permita adecuarse a las necesidades particulares de investigación. Se pretende a través del presente estudio proponer metodologías para la captura y procesamiento de datos, no solo proveyendo formato sobre los datos obtenidos del modelado y posteriores simulaciones, sino que el aporte se realice a la luz de una experiencia de la computación aplicada al análisis y diseño de productos y datos útiles para la ingeniería de tránsito. La aplicación de sistemas GPS proporciona la automatización requerida para la obtención de datos masiva.

Complementa el trabajo el modelado de datos para un adecuado almacenamiento.

Palabras Clave: Flujo Vehicular, Modelos de Tránsito, Congestión Vehicular.

1 Introducción El proyecto en el cual se encuadra el trabajo tiene como objeto describir las características de la dinámica del flujo vehicular en ambientes urbanos, para la elaboración de una metodología estándar que automatice la captura, procesamiento y almacenamiento de datos, identificando las variables que determinan situaciones particulares, como por ejemplo la congestión vehicular [1]. Se busca reemplazar metodologías clásicas de aforo vehicular, donde generalmente se utilizan hojas de datos para asentar mediciones sobre velocidad, densidad, etc. La utilización de técnicas alternativas, como por ejemplo la del auto flotante [2], representa un esfuerzo para explicar inestabilidades del tránsito en función de la respuesta del conductor. Al utilizar un vehículo testigo circulando por las áreas de estudio, es posible obtener mediciones directamente desde el mismo. Tales mediciones

1248

corresponden a la obtención de velocidades puntuales, que son utilizadas en etapas posteriores para establecer condiciones de congestión vehicular.

En la sección 2 se mencionan estudios preliminares que se encuadran en el tema de estudio. La sección 3 describe el diseño físico de la arquitectura computacional utilizada para el almacenamiento y cómputo de los datos recolectados: sus bases de datos, y una descripción de los algoritmos utilizados. En la sección 4 se menciona el modelo de datos propuesto, donde las características estructurales de las tablas de datos resultan de suma importancia para mantener un rápido acceso a los mismos. La sección 5 hace referencia a uno de los productos considerados por el grupo de trabajo: algoritmos para establecer rutas más cortas.

Finalmente se presentan las conclusiones sobre el análisis, diseño, desarrollo y uso del sistema de información planteado.

2 Estado del Arte 2.1 Productos para la Asistencia al Modelado de Tránsito Los estudios sobre tránsito y transporte [3][4], requieren del modelado y simulación de escenarios de circulación; lo cual requiere una correcta determinación de aquellos indicadores que permitan describir en forma clara y precisa situaciones y proyecciones de la dinámica vehicular. Se apunta a ofrecer soluciones alternativas sobre el procesamiento de datos provenientes de dispositivos GPS, atendiendo a la estructura de datos y algoritmos considerados para el planteo de escenarios particulares de flujo vehicular, determinación de indicadores de congestión, etc. Se indagó sobre el mercado de software destinado al modelado vehicular [5], encontrando que existen variadas metodologías para muestreo vehicular (por ejemplo, el método del auto flotante entre otros), y las correspondientes herramientas para simulación de escenarios de tránsito. Se han analizado distintas perspectivas que presentan estos productos para el análisis a través de la generación de micro y macro modelos. Dentro de las herramientas que se encuentran disponibles actualmente en el mercado, se destaca el software AIMSUN [6], el cual ha sido tomado como modelo debido al grado de generalidad que presenta. Las capacidades provistas por el software se centran principalmente en la realización de micro y macro modelos de una red de tránsito, como así también la simulación de maniobras reales. No obstante ello, el software no ha permitido avanzar sobre puntos de estudio u observación claves dentro de situaciones planteadas, por ejemplo: determinación de la congestión vehicular a través de datos históricos. Este estudio resulta sumamente conveniente para establecer políticas de circulación o diseño de obras civiles.

2.2 Estudios de Campo En primer lugar se han utilizado hojas de datos para la recolección de datos sobre velocidades y densidad vehicular, los cuales permiten en una primera instancia analizar las posibilidades de automatización de las muestras, el análisis de

1249

dispositivos de captura, etc. La experiencia resulta de utilidad para observar tanto las principales variables de medición (por ejemplo: velocidad media por tramo), como así también situaciones de circulación irregulares o anómalas. A partir de los estudios mencionados, se decide la implementación de herramientas propias para el almacenamiento, procesamiento y generación de información sobre los diferentes escenarios modelados.

3 Arquitectura Computacional de la Solución Propuesta 3.1 El dispositivo de Captura de Datos Para la obtención de trazas se utiliza un dispositivo GPS GARMIN Etrex Vista HCx [7], el cual resulta adecuado para obtener datos que se ajusten tanto a las variables de medición requeridas para el posterior modelado, como así también al tiempo mínimo requerido entre registros (por ejemplo: cada un segundo). Por otro lado se analizó la aplicación de SmartPhones para la adquisición masiva de datos, ya que por su popularidad, es posible distribuir la toma de datos a lo largo de mayor cantidad de vehículos de prueba. Se considera por otro lado que estos dispositivos son extremadamente dependientes del software que poseen, no encontrando estándares que permitan una obtención de datos homogéneamente confiables en el corto plazo.

3.2 Diseño de la Aplicación Si bien el sistema de información planteado no cuenta con las características de un sistema de procesamiento en tiempo de real, se pretende automatizar la captura del tren de datos provenientes del dispositivo GPS, de tal forma que resulte conveniente para la generación de información estadística. La figura 1 muestra en forma esquemática los diferentes subsistemas considerados para la obtención de información estadística.

Fig. 1. El sistema de información propuesto tiene por objeto el almacenamiento, procesamiento de datos y la posterior generación estadística sobre los escenarios modelados.

En primer lugar se cuenta con un conjunto de funciones que permiten el reconocimiento de diferentes tipos de trazas (Parser). Luego, a partir de la depuración de las trazas capturadas por los dispositivos, los datos son filtrados, eliminando aquellas muestras que no son útiles para el posterior procesamiento

1250

(Filtros y Conversion). A continuación se trabaja sobre algoritmos que procesan los datos filtrados para ser almacenados en base de datos. Finalmente, se requiere del procesamiento de la información para la generación de escenarios posibles de circulación. Esto plantea el problema de tener que procesar grandes volúmenes de datos. El producto obtenido consiste en un conjunto de algoritmos, bases de datos normalizada y metodologías de procesamiento, que sirve como insumo para ser utilizado en futuros proyectos de modelado numérico de situaciones reales de tránsito.

En resumen: el aporte esperado es la confección de una metodología de procesamiento masivo de datos de la dinámica vehicular, lo cual permita obtener información útil para crear nuevos modelos urbanos. Un avance del trabajo realizado se menciona en la sección 4.

3.3 Producción de la Información La capa de Producción (figura 1) corresponde a un conjunto de algoritmos que establecen a priori información útil para la circulación de un vehículo sobre el área de estudio. Los algoritmos se orientan a la sumarización, ordenamiento, agrupamiento, etc, de conjuntos de datos provenientes de las trazas, y de acuerdo a metodologías estándares de muestreo establecidas por la Ingeniería de Tránsito. Las muestras correspondientes a los conjuntos de datos en bruto, provenientes de numerosas muestras obtenidas a través de los dispositivos de georeferenciación, son sistematizadas a fin de generar información para elaborar escenarios de dinámica vehicular. El procesamiento principal corresponde a la obtención de caminos más cortos entre dos puntos específicos del área de estudio, contando con información estadística sobre la circulación del vehículo de prueba sobre dicha área.

3.4 Almacenamiento y Clasificación El almacenamiento principal se encuentra en una primera instancia sobre un conjunto de archivos de texto obtenidos del dispositivo. Se ha propuesto una metodología estándar de clasificación de tales ficheros para mantener un orden de acuerdo al vehículo testigo que toma la muestra, y otras variables que permiten describir el entorno en el cual se tomo la muestra, por ej: Característica del Vehículo Testigo, Día de la Semana / Fecha, Hora, Datos climáticos, etc.

Cada fichero representa una circulación particular del vehículo de prueba; luego, el conjunto de ficheros es introducido en la base de datos con el objeto de generar un único dominio de datos del cual poder generar información estadística. Dado la necesidad de almacenamiento masiva, y con el objeto de mantener almacenadas la totalidad de las muestras obtenidas del conteo vehicular, se requiere el desarrollo de un modelo de datos eficiente, para ser implementado con un motor de base de datos que resulte adecuado para la gestión de los datos. La confección de la base de datos consta de dos etapas: 1.

Información Estática. Comprende la georeferenciación de puntos de interés a lo largo de las zonas de estudio. Estos puntos luego conforman una malla

1251

interconectada. La información estática está conformada por tablas que contienen básicamente la información sobre esquinas, tramos de calles (por ejemplo, en la figura 2 se muestra un tramo en azul, cuyos datos representan las coordenada entre las cuales está comprendido, su nombre, etc.) y zonas de estudio; sus nombres y datos principales para identificarlas.

Fig. 2. La base de datos estática contiene información sobre coordenadas de puntos de interés e información sobre tramos.

2.

Información Dinámica. Corresponde a la información obtenida a través de la captura permanente de datos. Está compuesta por velocidades promedio, máximas, mínimas por tramo, conjunto de tramos etc. La contrastación de esta información con la malla obtenida en la etapa 1 permite generar información estadística sobre la dinámica vehicular, observar zonas de congestión, etc.

Fig. 3. La base de datos dinámica contiene información sobre recorridos de los vehículos testigos (velocidades y características de circulación).

Como se especifica en la sección 4, los datos almacenados en la base de datos son útiles para generar en tiempo de ejecución información útil para representar diferentes escenarios de circulación, por ejemplo a través de la constitución de matrices de adyacencia que expongan el paso entre diferentes puntos de la malla. El recorrido continuo del vehículo por la zona de prueba (ver figura 3) permite establecer el sentido de circulación entre diferentes tramos.

1252

0 0 0 0 0 1 (a)

1 0 0 1 0 0

0 1 0 0 1 0

0 0 0 0 0 0

0 0 0 0 0 0

0 0 0 0 0 0

(b)

Fig. 4. El sentido de circulación de cada tramo permite establecer un grafo dirigido (a), y a continuación una matriz de adyacencia que lo contenga (b).

Para el ejemplo de la figura 4 se han tomado solamente 6 tramos de estudio (fig. 4a), lo que deriva en una matriz de adyacencia (fig. 4b) de 36 coeficientes con solamente 5 elementos no nulos. Esta información es generada por el vehículo testigo en forma dinámica a medida que circula a través de los puntos (esquinas) almacenados previamente en la base de datos estática.

3.5 Algoritmos de Filtrado de Datos Se desarrollan algoritmos para ajustar los datos de acuerdo a las necesidades de información, como por ejemplo la existencia de situaciones de circulación vehicular anómalas, fallas del dispositivo de captura de datos, etc. Por ejemplo, en una captura de datos es común encontrar numerosas muestras con vel=0 (velocidad igual a cero, o auto detenido), o la captura de datos donde el vehículo testigo realiza diferentes maniobras. Estos eventos resultan inútiles para establecer información de interés, como por ejemplo la velocidad de marcha.

3.6 Reconocimiento de trazas heterogéneas Estos algoritmos están destinados a la conversión de unidades (por ej. coordenadas con diferente formato) y eliminación de datos inútiles. A partir de los diferentes formatos obtenidos, resulta útil establecer una metodología de reconocimiento. Para ello se genera un compilador capaz de reconocer diferentes formatos de traza, proveniente de diferentes dispositivos. La figura 5 ejemplifica un formato básico de traza donde se observan entre otros datos, la coordenada y la velocidad puntual.

1253

…

75 05/07/2013 18:30:49 0 m 0:00:01 76 05/07/2013 18:30:50 0 m 0:00:01 77 05/07/2013 18:30:51 8 m 0:00:01 78 05/07/2013 18:30:52 1 m 0:00:01 79 05/07/2013 18:30:53 2 m 0:00:01 80 05/07/2013 18:30:54 2 m 0:00:01 81 05/07/2013 18:30:55 2 m 0:00:01 82 05/07/2013 18:30:56 3 m 0:00:01 83 05/07/2013 18:30:57 3 m 0:00:01 84 05/07/2013 18:30:58 3 m 0:00:01 85 05/07/2013 18:30:59 3 m 0:00:01 86 05/07/2013 18:31:00 3 m 0:00:01 87 05/07/2013 18:31:01 3 m 0:00:01 …

0 km/h 0 km/h 29 km/h 5 km/h 6 km/h 6 km/h 8 km/h 10 km/h 12 km/h 12 km/h 11 km/h 10 km/h 10 km/h

S32.89669 W68.85365 S32.89669 W68.85365 S32.89669 W68.85365 S32.89662 W68.85364 S32.89661 W68.85364 S32.89659 W68.85364 S32.89658 W68.85363 S32.89656 W68.85363 S32.89653 W68.85363 S32.89650 W68.85362 S32.89647 W68.85362 S32.89645 W68.85361 S32.89642 W68.85361

Fig. 5. Ejemplo de una traza de datos. Cada línea representa un registro obtenido por el dispositivo de captura de datos.

El compilador de trazas [8], es desarrollado a través de las herramientas Flex y Bison [9] [10], y comprende las siguientes tareas: 1) Incorporación y lectura del fichero de trazas, 2) Determinación de errores en las mediciones y 3) Compilación de la traza hacia un formato estandarizado.

La consolidación de datos a partir de trazas heterogéneas permite luego obtener una mayor cantidad de muestras, contando con una base de datos con trazas provenientes de diferentes dispositivos o diferentes modalidades de captura.

4 Modelo de Datos 4.1 Adquisición de Datos para la base de Datos Estática Se han realizado algoritmos que permiten a través de los datos obtenidos en crudo, establecer la existencia de esquinas (o puntos de interés), con lo cual es posible alimentar la base de datos en forma continua, y tras la circulación permanente del vehículo de prueba por zonas de estudio.

4.2 Adquisición de Datos para la base de Datos Dinámica La base de datos con información dinámica contiene información recolectada a través de la técnica del auto flotante. La información obtenida se puede caracterizar en base a: 1) Información sobre el paso de un tramo a otro, 2) Información sobre la velocidad puntual en coordenadas específicas.

Se obtienen permanentemente datos a través del dispositivo GPS, los cuales alimentan la base de datos de esquinas y tramos. En la figura 6 se observa que a medida que se obtienen más trazas a través de la circulación libre del vehículo a través de la ciudad, se registran más datos paso(tramo1,tramo2). A simple vista se observa mayor densidad en la matriz de adyacencia.

1254

(a)

(b)

Fig. 6. La L Matriz de Adyacencia A pressenta coeficientees que determinnan el paso de uun tramo paso(fila,ccolumna). (a) y (b) son dos moomentos diferen ntes del estado de d la base de daatos, donde la seggunda matriz prresenta mayor cantidad c de entrradas.

q la densidaad de la matrizz se centra a lo largo de Se pueede visualizar en la figura que la diagonnal principal, situación s ventaajosa al trabajar la matriz numéricamentee.

4.3 Form mato de Reprresentación de d la matriz de d adyacenciaa A partir del modelado de datos se s cuenta con n una matriz binaria de 81.000.000 mna) determinna el paso coeficienntes, donde unna entrada differente de 0 en (fila,colum entre (traamox,tramoy) donde tramoox=fila y tram moy=columnaa del coeficiente. Esta metodoloogía permite describir d un grrafo dirigido, donde los noodos representtan a cada tramo de estudio, y las aristas el sentido de circulaación vehiculaar entre dichos tramos. macenar la maatriz completaa en memoriaa RAM se requieren 9.0000*9.000*2 Al alm =154,49552Mb (para un u coeficientte que ocupaa 2 bytes enn memoria), siendo el porcentaje ocupación del d 4,74e-4 %. s especifica en e la siguiente sección) Al opeerar con la maatriz de adyaccencia (como se se torna necesario diisponer de arrreglos auxiliiares, con loo cual, las m magnitudes expresadaas crecen conssiderablementte.

Se debbe diferenciarr el almacenam miento tempo oral de la mattriz en memooria RAM, con la reepresentación de la misma en disco. En n este último se almacenaa la matriz completaa con el objeeto de manteener una mejor reutilización de datos entre los programaas que utilizaan tales ficherros. Por otro o lado, se buusca una repreesentación adecuadaa de la matrizz en memoriaa RAM, tenien ndo en cuentta las caracterrísticas de dispersiónn de la mismaa. La represenntación de tipo coordenadaa , como un tiipo básico para la representación r n de una mattriz rala [11] lleva a alm macenar únicam mente los elementos no nulos junnto con datos que determin nan su ubicaciión (fila,colum mna). Este c de esspacio en mem moria principaal a menos almacenaamiento permiite reducir la cantidad de 3Kb para p la matriz del ejemplo. Por otro lad do, la complejidad algorítm mica de los métodos numéricos que q operan soobre ella aum menta al requuerir el mappeo de un n estructuura de datos diiferente a un arreglo a bidimeensional. coeficiennte sobre una nueva

1255

5 Algoritmos para Encontrar Trayectorias.

5.1 Algoritmos para encontrar rutas Muchos estudios dentro de las ciencias de la computación hacen referencia al esquema de computación planteado, conociéndose en la literatura como el problema APSP (All Pairs Shortest Path) aquel que tiende a encontrar caminos más cortos (o favorables) entre dos puntos en un grafo. A partir de la matriz de adyacencia es factible plantear la solución a problemas de este tipo. En este trabajo se destaca una situación especial al presentarse una matriz de adyacencia de grandes dimensiones.

Luego, dicho problema, que en la comunidad de ciencias de la computación presenta un constante desafío de resolución al intentar minimizar tiempos de resolución, se incrementa al contar con un grafo dirigido con una cantidad de componentes considerable.

Se propone en primer lugar una solución que lista y aisla desde la base de datos aquellas relaciones que permiten establecer el camino entre dos puntos particulares en la zona de estudio, podando el resto del grafo dirigido.

La potenciación de la matriz de adyacencia representa algunos de los cálculos más complejos desde el punto de vista computacional al consumir considerables recursos y tiempo de ejecución. Este cómputo es realizado una considerable cantidad de veces al describir el camino más ventajoso entre dos puntos. Se realiza la potenciación de la matriz como una sucesión de productos, donde P=A2=A*A.

(1)

representa la matriz de adyacencia para pasos de longitud 2 entre dos puntos de interés. Se recuerda que la complejidad algorítmica de dicho producto es O(n3) para n cantidad de coeficientes. De acuerdo a la cantidad de coeficientes, para un almacenamiento convencional como el descrito en la sección 4.3 se prevé que la carga computacional es considerablemente alta para el cálculo de (1).

5.2 Procesamiento Paralelo de la Información Con el objeto de paliar los altos tiempos de cómputo mencionados en 5.1, se propone la paralelización del proceso principal. Se procede a la paralelización del algoritmo de multiplicación sucesiva de matrices y se proponen dos algoritmos de multiplicación. En primer lugar, un algoritmo basado en memoria distribuida y paso de mensajes entre nodos para ser ejecutado en un cluster de computadoras. Esta solución se materializa a través de la utilización de la librería MPI [12].

Luego se propone un algoritmo con memoria compartida para ser ejecutado en una arquitectura superescalar multinúcleo, a través de la paralelización de hilos Posix [13].

En ambos casos se consigue obtener un speedup considerable frente a la solución secuencial.

1256

Conclusiones y Trabajo Futuro El trabajo permitió establecer un sistema de información que abarca desde la captura de datos, hasta la generación de estadísticas en torno a información real de circulación de vehículos testigo. Dicha información revela situaciones particulares, que son difíciles de obtener a través del aforo vehicular clásico.

Se facilita a investigadores e ingenieros relacionados con el tránsito y transporte el modelado de escenarios de flujo vehicular, proveyendo una estructura y conjunto de datos de fácil almacenamiento, acceso y manipulación; posibilitando a los mismos acceder a datos procesados o en crudo: condiciones no prevista en la mayoría de los software de modelado de tráfico vehicular de mayor incidencia en el mercado.

Para aquellos procesos que demandan mayor cantidad de tiempo de cálculo se proveyó de algoritmos paralelos, con los cuales se consiguieren considerables mejoras en los tiempos de ejecución.

Como trabajo futuro, el grupo analizará tecnologías para el procesamiento en tiempo real del tren de datos como resulta el GPRS. También se prevé como trabajo futuro la cuantificación y documentación de la ganancia en tiempo de ejecución experimentada con las nuevas arquitecturas de procesamiento paralela.

Referencias 1.

Thompson I., Bull, A.: La Congestión del Tránsito Urbano: Causas y Consecuencias Económicas y Sociales. CEPAL (Naciones Unidas, División de Recursos Naturales e Infraestructura, Unidad de Transporte). Serie Recursos Naturales e Infraestructura (25).

Chile, (2001). ISBN: 92-1-321865-6 2. Hall R.W.: Handbook of Transportation Science. 2º Edition. Edited by Randolph W. Hall, University of Southern California. Kluwer’s Internation Series. USA, (2003). ISBN: 14020-7246-5.

3. Cal, R., Reyes, M.: Ingeniería de Tránsito. Fundamentos y Aplicaciones 7ª Edición.

Alfaomega. (1995). ISBN: 970-15-0109-8.

4. Schöbel, A.: Optimization in Public Transportation: Stop Location, Delay Management and Tariff Design in a Public Transportation Network. Georg-August University (GöttingenAlemania). Springer. USA, (2006). ISBN: 978-0-387-32896-6.

5. Software para el Modelado de Tránsito.

Julio Monetti. Disponible en http://grid2.frm.utn.edu.ar/proyectotransito.

6. TSS. AIMSUN. Disponible en http://www.mctsoft.com/html/fr_mct.htm.

7. GARMIN. https://buy.garmin.com/en-GB/GB/prod8703.html 8. Compilador de Ficheros de Trazas. J. Monetti. http://grid2.frm.utn.edu.ar/proyecto.

9. Aaby, A.: Compiler Construction using Flex and Bison.. Walla Walla College. (2005).

Disponible en aabyan@wwc.edu.

10. Levine, J.: flex & bison 1º Edición. O'Reilly Media. USA, (2009). ISBN: 978-0596155971 11. Tewarson R.: Sparse Matrices.. Department of Applied Mathematics and Statistics.

Academic Press Inc. USA, (1973). ISBN: 9780126856507.

12. Gropp, W., Lusk E. Thakur, R.: Using MPI-2. Advanced Features of the Message-Passing Interface. The MIT Press. Cambridge – Massachusetts. London, England. (1999). IBN: 0262-057133-1.

13. Butenhof, D.: Programming with Posix Threads. Addison Wesley Longman Inc. USA, (1997). ISBN: 0-201-63392-2.

1257

Planeamiento Estratégico para Compartir Información en la Administración Pública1 Ignacio Marcovecchio1, Elsa Estevez2, Pablo Fillottrani1,3, 1

Departamento de Ciencias e Ingeniería de la Computación, Universidad Nacional del Sur, Av. Alem 1253 – Bahía Blanca, Argentina 2 United Nations University – IIST, Center for Electronic Governance, P.O. Box 3058, Macao SAR, China 3 Comisión de Investigaciones Científicas de la Provincia de Buenos Aires, Argentina ignaciomarcovecchio@gmail.com, elsa@iist.unu.edu, prf@cs.uns.edu.ar

Abstract. Poder compartir información es fundamental para el funcionamiento efectivo y eficiente de la administración pública, y en especial, para iniciativas de gobierno electrónico. Tal es su importancia que el nivel de madurez más alto en gobierno electrónico se alcanza cuando las agencias de gobierno son capaces de compartir información. Sin embargo, la implementación de iniciativas basadas en compartir información (CI) resulta difícil como consecuencia de las barreras que suelen existir. Para poder atacar una problemática tan amplia y compleja, todas las iniciativas deben estar coordinadas y deben contribuir a alcanzar los mismos objetivos. Por este motivo, es necesario que el gobierno cuente con una estrategia para encarar organizadamente las acciones relacionadas con CI. En este trabajo se presenta un proceso que tiene por objetivo asistir a los responsables de gobierno en la definición de planes estratégicos para compartir información en el sector público. El proceso consta de ocho pasos que guían el desarrollo de la planificación estratégica que apuntan a facilitar la planificación y lograr buenos resultados al CI. Keywords: Compartir Información; Planeamiento Information Officer (CIO) de Gobierno (GCIO)

Estratégico;

Chief

1 Introducción Compartir información en el ámbito de gobierno se define como el conjunto de todas las actividades que tienen por objetivo obtener, mantener, usar y proteger información en el sector público [1]. Poder compartir información – tanto dentro de una agencia de gobierno, como entre agencias o entre gobiernos – es fundamental para el funcionamiento de la administración pública, y en especial, para iniciativas de gobierno electrónico. Tal es su importancia que el nivel de madurez más alto en gobierno electrónico se alcanza cuando las agencias de gobierno son capaces de 1

Este trabajo de investigación fue financiado parcialmente por la Fundación Macao, Macao SAR, mediante la ejecución de uno de los proyecto del Programa e-Macao.

1258

compartir información. Sin embargo, y pese a su importancia, la implementación de iniciativas de CI suele resultar difícil de conseguir como consecuencia de las barreras que suelen existir: barreras tecnológicas, culturales, organizacionales, políticas, etc.

Debido a su importancia y a su naturaleza transversal – ya que incluye a distintas entidades del gobierno – las iniciativas de CI requieren un alto grado de coordinación, y son usualmente asignadas como responsabilidad de la oficina del Chief Information Officer de Gobierno (GCIO). Como responsable del liderazgo y la coordinación de todas las iniciativas del gobierno en materia de tecnología de la información y las comunicaciones (TICs), el GCIO juega un rol central y tiene un especial interés en maximizar el compartimiento de la información.

Para poder atacar una problemática tan amplia y compleja como la de CI, las iniciativas deben estar coordinadas y deben contribuir a alcanzar los mismos objetivos. Por este motivo, es necesario que el gobierno cuente con una estrategia para encarar organizadamente las acciones relacionadas con CI. Los GCIOs disponen de herramientas para la definición de estrategias; una de estas herramientas es el planeamiento estratégico [13]. Como la elaboración de planes estratégicos es una tarea compleja y que involucra a muchos actores, existen procesos que guían el desarrollo de los mismos. Estos procesos, sin embargo, no son específicos para cada problemática, sino que se adaptan a cualquier tipo de organización y se utilizan para planificar estrategias de distintos dominios. Para asistir a los GCIOs en la definición de planes estratégicos para CI, en este trabajo se seleccionó un proceso para el planeamiento estratégico de cuestiones relacionadas con TICs y se lo ajustó y personalizó para el dominio específico de CI. Con esta herramienta, los gobiernos no tendrán que repetir estas acciones cuando decidan planificar sus estrategias de CI, sino que podrán utilizar y perfeccionar el proceso existente.

El presente trabajo tiene por objetivo asistir a los líderes de tecnología del sector público en la planificación estratégica para la implementación y el fortalecimiento del uso compartido de la información en la administración pública. Para lograr este objetivo se propone esencialmente una herramienta – un proceso para la definición de los planes estratégicos para CI; que sirve para guiar a las partes involucradas durante el proceso de planificación de iniciativas dedicadas a CI. El resto del trabajo está organizado de la siguiente manera: la Sección 2 presenta y describe el proceso de planeamiento estratégico, ajustado para el dominio de CI; la Sección 3 presenta trabajos relacionados. Finalmente, la Sección 4 presenta las conclusiones obtenidas y las líneas de investigación planeadas a futuro.

2 Proceso para Realizar un Plan Estratégico para CI

El proceso que se define a continuación para la definición de un plan estratégico de CI se basa en el proceso de planeamiento estratégico para gobernanza electrónica descripto en [2]. Este proceso se compone de ocho pasos (ver Fig. 1), los cuales se ajustaron con las modificaciones necesarias para su utilización en el contexto de CI para gobierno electrónico. A continuación se describen en detalle cada uno de los pasos del proceso resultante.

1259

Evaluación del estado de la preparación Elaboración de la visión Formulación de las metas estratégicas Determinación de las intervenciones requeridas Definición de los objetivos estratégicos Identificación de prioridades Establecimiento de mecanismos para participación de interesados Provisión de un modelo de negocios

Fig. 1. Pasos del proceso para planeamiento estratégico para CI. 2.1 Evaluación del Estado de Preparación El objetivo de evaluar el estado de preparación de la administración pública para compartir información es obtener la información necesaria para la definición del plan estratégico. Una acertada evaluación del estado de preparación es fundamental para la correcta definición de los elementos del plan. Además, la información obtenida en este paso resulta de gran utilidad para medir los resultados del plan.

El estado de preparación del gobierno con respecto a la capacidad para CI se puede determinar siguiendo metodologías como las presentadas en [3] y [4]. Esta metodología se basa en obtener el conocimiento sobre el estado general del arte de la administración pública, la situación actual con respecto al uso de la información y las percepciones de los principales interesados con respecto a las prácticas para compartir información. La metodología está conformada por cuatro componentes: i) un proceso para guiar el ejercicio de evaluación, ii) un modelo conceptual que ayuda en la definición de las áreas a tener en cuenta en la evaluación, iii) los instrumentos a utilizar para la evaluación y, iv) guías prácticas para la ejecución de cada una de las actividades.

Algunas de las áreas a considerar en una evaluación que ofrezca una visión completa del estado de preparación son: o Preparación Política – mejorar el uso de información requiere fuerte compromiso por parte de los líderes políticos. Para esto debe existir compromiso político para mejorar el uso de la información, conocimiento de la importancia y los beneficios de mejorar el uso y la forma en la que se comparte la información, y liderazgo capaz de administrar los cambios necesarios. Todos estos aspectos deben ser relevados, junto con las percepciones de los referentes del nivel político. o Preparación Regulatoria – un marco regulatorio bien definido es necesario para asegurar que se comparta información tanto dentro del gobierno, como así también entre el gobierno, los ciudadanos y las organizaciones. Este marco es además

1260

o

o

o

o

o

necesario para garantizar las condiciones económicas para el acceso a la infraestructura tecnológica, a los servicios y al equipamiento necesario. Por lo tanto, se debe estudiar la legislación existente con respecto a privacidad, utilización de estándares, el grado de liberalización de la industria de las telecomunicaciones y el ambiente fiscal para la adquisición de equipamiento de TICs. Preparación Organizacional – la implementación o la mejora de la forma en la que se comparte información suele requerir e implicar cambios organizacionales en la estructura del gobierno. Para justificar estas transformaciones es necesario disponer de información sobre los flujos de información existentes, los procesos que se llevan a cabo para ofrecer servicios, los datos solicitados por cada agencia del gobierno, las relaciones entre los distintos organismos del gobierno, los niveles de autoridad y control entre estos organismos, las experiencias de colaboración en el pasado, la existencia de unidades centrales de coordinación, etc.

Preparación Cultural – los aspectos culturales suelen generar resistencia a los cambios. Cuanto más se sepa sobre estos aspectos culturales, mejor se pueden planificar las estrategias para afrontar aquellos que puedan resultar negativos. Entre los aspectos a considerar se encuentran los niveles de educación, la actitud hacia los cambios, la cultura para compartir información y conocimiento, el nivel de educación en tecnología de la información y las comunicaciones, la cultura organizacional en la administración pública, la orientación de servicio hacia los clientes por parte de los servidores públicos, etc.

Preparación Económica – los costos para poner en marcha un sistema de intercambio de información suelen ser altos. Por este motivo, se debe tener una noción precisa de los recursos disponibles en la administración pública para poder realizar una planificación adecuada de su utilización. Además, se deben estudiar los posibles mecanismos de financiamiento para hacer frente no sólo a la puesta en marcha sino también al sostenimiento en el tiempo del sistema. Algunos de los aspectos que se deben estudiar en esta área son los recursos financieros disponibles, la estructura de ingresos del gobierno y el acceso a mecanismos de financiamiento alternativos, la posibilidad de cooperación con el sector privado, el acceso a los mercados de capitales, etc.

Preparación en Infraestructura – una infraestructura tecnológica deficiente representa un obstáculo para implementar y sostener un sistema para el intercambio de información. Por este motivo se deben relevar los recursos tecnológicos existentes y se deben evaluar los factores que puedan resultar problemáticos, para poder planificar la forma de superarlos. Fundamentalmente se debe conocer la disponibilidad de recursos de hardware, software y sistemas de telecomunicaciones, así como también la existencia de sistemas legados y las condiciones demográficas y geográficas que pueden afectar la distribución económica, y por lo tanto, influir en la disponibilidad de infraestructura (tanto pública como privada).

Preparación de Datos e Información – para lograr que la información pueda ser compartida electrónicamente deben existir sistemas de información, bases de datos y procesos de trabajo que soporten el funcionamiento del gobierno. Los datos a considerar cuando se evalúa esta área incluyen la disponibilidad y accesibilidad a los datos, los procedimientos para la captura y la estandarización de datos e información, la calidad de los datos y los mecanismos de seguridad para su acceso, la capacidad para analizar los datos y utilizar la información, entre otros aspectos.

1261

2.2 Elaboración de la Visión En este paso se busca definir un futuro estado que el gobierno desea alcanzar a largo plazo en materia de CI. El instrumento que se utiliza para plantear estas ideas se llama visión y su declaración sirve de guía general para la implementación del proceso.

Debido a su importancia, existen procesos para la construcción de la visión. Un ejemplo es el proceso presentado en [2], que involucra cinco pasos. A continuación se presentan estos pasos y se los explica en el contexto de IS. 1) Identificar y consultar a los interesados – lograr consenso y apoyo en las iniciativas requiere involucrar y contar con el apoyo de los sectores involucrados.

2) Permitir a los interesados presentar y explicar sus propias visiones – para fomentar la participación y el sentido de pertenencia, además de contemplar intereses y preocupaciones de las partes involucradas, se deben contemplar mecanismos para que los interesados puedan exponer sus propias visiones.

3) Desarrollar una versión preliminar de la visión – esta propuesta se debe desarrollar en base a las visiones de los interesados.

4) Alinear la visión con las necesidades y oportunidades generales – la visión de CI en el gobierno tiene que estar alineada con la visión general del gobierno con respecto a las TICs. Debido a la naturaleza transversal de CI, es conveniente que la visión sea definida por el más alto nivel de administración pública (i.e. nacional).

5) Consolidar y consensuar una versión final de la visión – para ser efectiva, la versión final debe respetar las siguientes características: i) debe ser clara, intuitiva y simple; ii) debe establecer claramente el alcance (establecer qué será hecho y qué no será hecho); iii) debe considerar necesidades y oportunidades; iv) debe contar con el consenso de los interesados; y v) debe estar alineada con la estrategia nacional de TICs. 2.3 Formulación de las metas estratégicas Las metas estratégicas son declaraciones que establecen la dirección de CI y que se basan en lo postulado por la visión. Su objetivo es definir los logros que se pretenden alcanzar a largo plazo. Las metas cumplen tres funciones principales: 1) establecen el estado futuro deseado que la organización quiere alcanzar en materia de CI, por lo que constituyen principios generales que deben ser seguidos por los miembros de la organización; 2) proporcionan una lógica o razón fundamental para la existencia de las iniciativas de CI; 3) proporcionan un conjunto de estándares con los que se puede contrastar el rendimiento de las acciones tomadas.

Algunos temas que las metas consideran incluyen: 1) efectos sociales y económicos provocados por el desarrollo de CI; 2) ofrecimiento de servicios públicos de calidad; 3) impacto a partir de la posibilidad de realizar mejores controles, las mejoras en la eficiencia y la efectividad, y la reducción de costos; 4) impacto en la gobernabilidad favorecido por las mejoras en los procesos de toma de decisiones.

Una vez definidas tanto la visión como las metas estratégicas es recomendable identificar cuáles son los mayores desafíos y barreras para concretarlas. Tener estos

1262

aspectos presentes durante la implementación del proceso contribuye a prevenir y a reaccionar de mejor manera ante los obstáculos que se puedan presentar.

2.4 Determinación de las intervenciones requeridas Este paso consiste en identificar los aspectos necesarios para la creación de un ambiente que favorezca el desarrollo de iniciativas de CI. La información de entrada al proceso incluye los resultados del estudio del estado de preparación (sección 2.1), la visión estratégica (sección 2.2) y las metas estratégicas (sección 2.3). Las intervenciones requeridas pueden considerar, entre otras, las siguientes dimensiones: o Intervenciones legales – nuevas leyes y normas pueden ser necesarias para la adopción de CI. Algunos cuestiones legales a considerar incluyen: la integración y el intercambio de datos entre agencias públicas; el uso de la información pública por terceras partes, preservando la privacidad y la seguridad; el intercambio y las transacciones digitales entre agencias de gobierno, ciudadanos y empresas; el reconocimiento de los intercambios digitales de información y las transacciones digitales; etc. Ejemplos de medidas regulatorias tomadas por gobiernos líderes en gobierno electrónico son la Ley de Protección de Datos del Reino Unido [5] que “protege la privacidad personal y permite el libre flujo de datos personales por armonización”, la ley de Libertad de Información Electrónica de los Estados Unidos [6] que, entre otras cosas, “instruye a todas las agencias federales a usar tecnologías de información electrónica para fomentar la disponibilidad pública de documentos electrónicos” y además “le otorga a los individuos el derecho de acceder a los registros que se encuentran en posesión del gobierno federal”, y la ley de Firma Electrónica de la Unión Europea [7] que “reconoce las firmas electrónicas dentro de la Unión Europea y que pueden ser usadas como evidencia en procedimientos legales”. o Intervenciones organizacionales – una buena práctica consiste en la definición de una entidad central de coordinación. La coordinación puede ser realizada por una agencia, un equipo dentro de un ministerio o un equipo creado específicamente para tal fin. La principal responsabilidad de esta entidad consiste en coordinar la implementación de la estrategia de CI. Adicionalmente, es responsable de realizar revisiones periódicas sobre el estado de preparación, coordinar campañas de concientización, asistir en las posibles relaciones con el sector privado, etc.

Adicionalmente, una de las responsabilidades esenciales a este equipo es la de monitorear, evaluar y reportar el avance logrado en materia de CI. o Intervenciones en recursos humanos – todos los interesados deben ser preparados con los conocimientos necesarios para desenvolverse en un contexto de CI. El tipo de capacitación y la forma de impartirla deben planificarse y ofrecerse de acuerdo a las necesidades y características particulares de cada sector. o Intervenciones en comunicación – comunicar los objetivos y los logros obtenidos contribuye a crear conciencia y fomentar la participación de los interesados. Las estrategias de comunicación tienen que tener por objetivo crear interés y generar expectativas sobre los beneficios de CI. Los destinatarios principales de las

1263

campañas de comunicación deben incluir a políticos, tomadores de decisiones, empleados de la administración pública, empresas privadas y ciudadanos. o Intervenciones en tecnología – la infraestructura tecnológica es fundamental para el desarrollo de cualquier iniciativa de gobierno electrónico, en particular, para todas aquellas relacionadas con CI. Las intervenciones que debe realizar el gobierno en materia tecnológica deben apuntar a contar con una red de telecomunicaciones confiable y con costos accesibles, desarrollar políticas nacionales de TICs, asociarse con el sector privado para resolver cuestiones técnicas, y tener acceso a mejores prácticas internacionales para superar las limitaciones tecnológicas.

2.5 Definición de los objetivos estratégicos Los objetivos estratégicos son declaraciones específicas y medibles sobre las metas estratégicas. Estos objetivos deben cubrir las acciones específicas a llevar a cabo y una definición de tiempos para su cumplimiento. Según [8], los objetivos se encuentran bien definidos si respetan las siguientes premisas: 1) son alcanzables, 2) son compresibles, 3) están ubicados en un horizonte temporal, 4) se derivan de las metas estratégicas de la organización, 5) se pueden transformar en tareas específicas, 6) posibilitan la concentración de recursos y esfuerzos, 7) no incluyen abstracciones, y 8) deben poder ser cuantificados o expresados en cifras. Los objetivos se materializan en la práctica a través de la implementación de programas y proyectos.

2.6 Identificación de prioridades La cultura de compartir información no se logra a través de una única iniciativa, sino que se debe lograr a través de pasos concretos sobre los cuales se pueda construir credibilidad y sirvan para acercarse a las metas definidas. No existe una única regla que establezca cómo priorizar los objetivos, pero existen distintos criterios que pueden tenerse en cuenta al momento de establecer prioridades. Algunos de estos criterios a considerar incluyen: i) los recursos disponibles, ii) la sostenibilidad, y iii) la factibilidad de concretarlos – tanto desde el punto de vista tecnológico como institucional. La recomendación es no utilizar estos criterios de manera aislada, sino buscar formas de combinarlos, ponderando su importancia de acuerdo al contexto, a lo establecido por la visión y las metas estratégicas. La Fig. 2 propone una forma organizada para priorizar objetivos de acuerdo a criterios definidos.

Fig. 2. Matriz de prioridades.

1264

El principio general para la priorización propone que se deben tener presentes los objetivos a largo plazo, pero que se deben concretar y consolidar los objetivos de corto plazo. Los criterios utilizados para la priorización deben combinarse con el impacto que producirán. El impacto se puede evaluar en distintas dimensiones, como por ejemplo: 1) Impacto social – nuevas oportunidades de empleo, mayor utilización de servicios, facilidad de operación, reducción de tiempos de resolución, mayor inclusión, etc.; 2) Impacto económico – reducción de costos, nuevas oportunidades de negocios, mejoras en los tiempos, etc.; y 3) Impacto en la gobernabilidad – mayor transparencia, combatir la corrupción, seguridad, privacidad, control, etc.

2.7 Establecimiento de mecanismos para participación de interesados Existen diversos mecanismos para fomentar la participación de los interesados. Una forma de involucrarlos en el proceso de CI puede ser, por ejemplo, a través de un proceso de consulta pública. Un caso exitoso de inclusión de interesados es el resultado de la Política de Compromiso de los Interesados llevada adelante por el Departamento de Gobierno Local, Deportes y Recreación del gobierno de Queensland, Australia [9]. En ella se definieron seis principios para la participación de los interesados: inclusión, acercamiento, respeto mutuo, integridad, afirmar la diversidad y agregar valor.

Para poder determinar y asignar responsabilidades es necesario identificar a los interesados. Una posible clasificación de los roles de los interesados involucrados en las problemáticas de CI se presenta a continuación: 1) Equipo – personas van a trabajar directamente en los proyectos de CI; 2) Proveedores – proveedores de tecnologías, recursos y experiencias; 3) Operadores – empleados de las agencias que van a operar los sistemas de CI; 4) Campeones – entidades que conducen y buscan justificación para los proyectos; 5) Patrocinadores – entidades a cargo de los gastos de los proyectos; 6) Propietario – agencia que va poseer y usar los sistemas; y 7) Otros – recursos involucrados que tienen influencia significativa en el proyecto.

2.8 Provisión de un modelo de negocio El modelo de negocio es un plan para asegurar la sostenibilidad de CI desde el punto de vista de su adopción y de los recursos necesarios. El modelo de negocio debe determinar cómo se van a desarrollar las soluciones de CI, las posibles opciones de financiamiento, los mecanismos para atraer la participación del sector privado, etc.

La disponibilidad de fondos determina el tipo de proyectos que se pueden llevar a cabo. Siendo CI una de las disciplinas principales para lograr el desarrollo de gobierno electrónico, un porcentaje de los fondos para CI puede provenir de los presupuestos definidos para tal propósito. Mientras que el financiamiento para los proyectos de CI puede provenir de los presupuestos de las agencias involucradas, una práctica que ha resultado exitosa para promover la colaboración entre distintos organismos de gobierno es la de disponer de presupuestos adicionales sólo para proyectos en los que participen colaborativamente más de un organismo. Otras estrategias de financiamiento incluyen variantes de las asociaciones publico-privadas.

1265

3 Trabajos Relacionados En la literatura existen varios trabajos relacionados con planeamiento estratégico de TI (PE) y con CI en gobierno. Con respecto a PE, [14] propone un plan para aplicar gobernanza de TI en el sector público basado en teorías de gerenciamiento participativo, planeamiento estratégico de TI, gobernanza de TI y administración pública. [15] presenta un modelo para evaluar el nivel de madurez de planeamiento estratégico de TI en organizaciones públicas de Brasil. En [16], se explica un enfoque, incluyendo un proceso para el planeamiento estratégico de TI para librerías e instituciones de educación superior. El proceso define las siguientes tareas: 1) definición del plan de proyecto con la alta gerencia, 2) realización de un análisis FODA (fortalezas, oportunidades, debilidades y amenazas), 3) evaluación del entorno y uso actual de TI en la librería, 4) evaluación de las TI disponibles en el mercado, 5) revisión del plan de acción con los interesados, 6) conducción de entrevistas con los principales interesados, 7) conducción de evaluaciones, 8) definición de un plan estratégico que incluye identificación, priorización y estimación de presupuesto para las iniciativas, 8) revisión del plan por parte del comité designado, 9) comunicación del plan y 10) revisiones periódicas del plan. Comparando las contribuciones de estos trabajos con los resultados presentados en este artículo, la más similar es [16]. La mayor diferencia es que ambos definen distintos niveles de granularidad para las tareas – el proceso propuesto para CI define tareas separadas para la definición de la visión, metas, intervenciones, objetivos y prioridades; mientras que el proceso para las librerías engloba todas estas tareas en una sola actividad (la número 8).

Adicionalmente, el proceso aquí propuesto es específico para CI en el sector público.

Con respecto a trabajos relacionados con CI, existen varios que definen perspectivas de CI, los más relevantes incluyen [11] [12] [17]. Estos trabajos se utilizaron para definir las dimensiones de la evaluación de la preparación y los tipos de intervenciones requeridas.

4 Conclusiones El nivel de madurez más alto en gobierno electrónico se alcanza cuando las agencias de gobierno son capaces de compartir información. Esto refleja la importancia que tiene y la complejidad que reviste lograr la administración eficiente de la información dentro de la administración pública.

Este trabajo propuso la utilización de herramientas del análisis estratégico como soporte para el análisis y la planificación de las acciones que deben llevar adelante los gobiernos para implementar y fomentar el uso compartido de la información en el ámbito de la administración pública. El proceso de planificación estratégica de CI apunta a servir de guía para que las decisiones y acciones que impactan en la información del sector público estén alineadas con los objetivos de utilizar y compartir la información de manera eficiente y eficaz, eliminado duplicidad y contribuyendo a lograr una mejor gobernabilidad.

La contribución de este trabajo es la definición de un proceso para la planificación estratégica de CI. El proceso cubre todo el ciclo de vida del ejercicio de planeamiento

1266

estratégico y para cada una de las actividades se describen sus objetivos, la forma de llevarlos a cabo y los resultados esperados, acompañados de ejemplos reales.

Las líneas de trabajo futuro incluyen la validación del proceso propuesto mediante su instanciación en administraciones públicas de distintos niveles de gobierno (nacional, provincial y municipal), la definición de marcos de trabajo para la implementación de iniciativas de CI, y la construcción de herramientas automáticas que faciliten el proceso de planeamiento e implementación de tales iniciativas.

Bibliografía 1. Estevez, E., Fillottrani, P., Janowski, T., Ojo, A. Government Information Sharing – A Framework for Policy Formulation. In: Chen, Y.-C. and Chu, P.-Y. (eds.) E-Governance and Cross-boundary Collaboration: Innovations and Advancing Tools. IGI Global (2011).

2. Ojo, A., Estevez, E., Janowski, T., Estrategic Planning for Electronic Governance – Process, UNU-IIST Center for Electronic Governance, UNeGov.net School on Electronic Governance, Cucuta, Colombia, 4 al 6 de Septiembre de 2008.

3. Estevez, E., Janowski, T., Government Information Sharing in Macao SAR, UNU-IIST Center for Electronic Governance. (2010).

4. Estevez, E., Janowski, T., Marcovecchio, I., Ojo, A., Establishing Government Chief Information Officer Systems - Readiness Assessment. In: Bertot, J.C., Nahon, K., Chun, S.A., Luna-Reyes, L.F., and Atluri, V. (eds.) Proceedings of the 12th Annual International Conference on Digital Government Research (dg.o 2011), USA. pp. 292–301, (2011).

5. Reino Unido, Ley de Protección de Datos, https://www.gov.uk/data-protection/the-dataprotection-act.

6. Estados Unidos, Ley de Libertad de Información, http://www.foia.gov/.

7. Unión Europea, Framework de la Comunidad para las Firmas Electrónicas, http://europa.eu/legislation_summaries/information_society/other_policies/l24118_en.htm.

8. Rodriguez Pottella, M., Manual de Planificación Estratégica para Instituciones Universitarias, FEDUPEL (1997).

9. Australia (Queensland Government, Department of Local Government, Sport and Recreation), Stakeholder Engagement Policy, http://www.docstoc.com/docs/34203478/ StakeholderEngagement-Policy--.

10. De Kluyver, C.A, Pensamiento Estratégico: Una Perspectiva para Los Ejecutivos. Pearson Educación (2001).

11. Dawes, S. (1996), Interagency Information Sharing: Expected Benefits, Manageable Risks, Journal of Policy Analysis and Management, Vol. 15, No. 3, pp. 377-394, JSTOR. 12. Pardo, T., Cresswell, A., Dawes, S., and Burke, B. (2004), Modeling the Social & Technical Processes of Interorganizational Information Integration, Proceedings of the 37th Hawaii International Conference on System Sciences, dg.o, vol. 62, ACM Portal.

13.Bryson, J. Strategic Planning for Public and Nonprofit Organizations: A Guide to Strengthening and Sustaining Organizational Achievement, John Wiley & Sons, Inc., 2011.

14.Bermejo, P.H.D.S, and Tonelli, A.O., Planning and implementing IT governance in Brazilian public organizations, 44th Hawaii International Conference on System Sciences, HICSS-44 2010; Koloa, Kauai, HI; United States; 4-7 Enero 2011, pp. 1-10.

15.De Almeida Teixeira Filho, J.G, and De Moura, H.P., MMPE-SI/TI (Gov) - Model to assess the maturity level of the IS/IT strategic planning of Brazilian governmental organizations, Proceedings de PICMET: Portland International Center for Management of Engineering and Technology, USA, 31 Julio-4 Agosto 2011.

16.McGee, R. Information Technology (IT) Strategic Planning for Libraries, Library Management, vol, 27, issue 6-7, 2006, pp. 470-485.

17.Landsbergen, D., and Wolken, G. (2001), Realizing the Promise: Government Information Systems and the Fourth Generation of Information Technology, Public Administration Review, Vol. 61, Issue 2, April 2001, Wiley, InterScience.

1267

Ciber-adicciones: Estudio del Comportamiento Poblacional por Simulación Montesano, L.1, Pollo Cattaneo, F.1, Garcia-Martinez, R.2 1. Programa de Maestría en Administración de Negocios. UTN-FRBA 2. Laboratorio de Investigación y Desarrollo en Arquitecturas Complejas Grupo de Investigación en Sistemas de Información. Universidad Nacional de Lanús. lmontesano@arnapsis.com.ar, rgm1960@yahoo.com

Resumen. La actual revolución digitalizadora de Internet podría actuar como medio de trasporte de productos y servicios de consumo inagotable hasta generaciones jóvenes, permeables a tecnologías donde la exposición desmedida podría estar gestando, en silencio, un conjunto de personas ciber-adictas. Este trabajo busca formular herramientas que permitan encontrar perfiles comunes, sobre aquellos usuarios de Internet, que consuman productos y servicios digitalizados, de modo que si experimentan algún patrón de conducta compulsiva al hacerlo, puedan minimizarse las consecuencias humanas e individuales en base a la investigación de las causas.

Palabras Clave: productos digitales, modelos de consumo, ciber-adicciones.

1. Introducción Actualmente entre el 25% y 30% de los habitantes del planeta disponen de acceso a la Internet. Es un espacio perfecto para las ideas que da entrada a millones de personas que suben y bajan contenidos intentando democratizar el conocimiento humano [Krotoski, 2010]. Se presentan dos mundos, no excluyentes sino complementarios: uno real de recursos que se pueden ver y tocar y otro virtual en el que los bienes y servicios adoptan la forma digital [Rayport y Sviokla, 1995].

En medios de soporte electrónico pueden alojarse; libros, imágenes, videos, música, programas informáticos y otros entretenimientos, que son solicitados, entregados y comerciados por vía de ciber-mercados [Kotler y Keller, 2006], apuntalando al comercio electrónico. El consumidor aumenta su capacidad de acceso, obtiene mayor información y compara características, reduciendo e incluso eliminando a los intermediarios [Amit y Zott, 2001].

Este beneficio se debe en parte a la transacción de bienes y servicios digitalizados, donde la infinitud de stock, devenida en ceros y unos, los predispone como nuevas posibilidades que amplían las innovaciones de comercio. La “Ley de los activos digitales” establece, que a diferencia del mundo físico, no se agotan con su consumo [López Sánchez y Sandulli, 2002].

Los emprendimientos que tratan con productos y servicios digitalizados comercializables por Internet constituyen un campo de investigación de creciente

1268

interés en el área de administración de negocios de base tecnológica [Andrade, 2000; van Hooft y Stegwee, 2001; Menascé, 2002; Young y Johnston, 2003; Janita Muñoz, 2005; Barua et al., 2007; Howson, 2008; Nascarella, 2009, Young-Ei y Jung-Wan, 2010, Ruíz y Palací, 2011; Elaluf-Calderwood et al., 2011].

La característica de extraterritorialidad de la red y la falta de normativa específica para sus contenidos, sea por televisión digital interactiva o telefonía móvil debe reconsiderarse. La identificación del ámbito espacial es irrelevante para estas nuevas tecnologías [KPMG, 2000].

Algunos países de condiciones fiscales paradisíacas comenzaron a alojar productos y servicios digitalizados controversiales [Acta de Comercio Libre y Zona Procesada, 1994]. Mientras otros de mayor desarrollo iniciaron los primeros debates sobre el tema [Acta de Prohibición del Juego en Línea, 1997]. Las pujas legales trasnacionales sobre estas metodologías de distribución continúan.

2. Delimitación del Problema Considerando que se trata de una modalidad comercial novedosa [Kotler y Keller, 2006], que acciona sobre empresas y consumidores influenciados por la actividad publicitaría [Krotoski, 2010], la situación económica, ambiental y social, la disposición de tecnología, los servicios de comunicaciones y datos [ElalufCalderwood et al., 2011] en el marco de una gestión gubernamental [Aspis et al., 2006] podría ser necesario entender las consecuencias del consumo masivo de productos y servicios digitalizados.

Todo aspecto de la vida parece ser remodelado por Internet, creando riqueza única: conocimiento. Es un espacio de perpetua innovación donde los contenidos digitalizados en productos y servicios son la materia prima y la vez; la creación [Krotoski, 2010]. Algunos estudios indican que aquellos usuarios de la red enfrentan potencialmente una serie de nuevos conflictos inherentes al comportamiento.

Compulsividad y trastornos de la personalidad son devenidos del consumo exagerado de contenidos en Internet, experimentando un tipo de ciber-adicción [Llinares Pellicer y Lloret Boronat, 2008]. Siguiendo a los autores citados se reconocen cinco categorías de ciber-adicción. La primera refiera a la desmedida búsqueda de información de todo tipo, le sigue el exceso de contacto en entornos (o redes) sociales, la adicción a los juegos (de apuestas o no), compras compulsivas y finalmente ciber-sexo [Llinares Pellicer y Lloret Boronat, 2008]. Algunos individuos como los niños, adolescentes y adultos vulnerables se encuentran en mayor grado de exposición que otros [Araya Dujisin, 2005].

La generación “Y” comprende a las personas nacidas entre los años 1981 y 2000.

Esta generación se distingue por una actitud desafiante y retadora. Lo cuestionan todo, no quieren leer y sus destrezas de escritura son pésimas. Educados y técnicamente hábiles en el uso de nuevas tecnologías, son independientes, multiculturales y disponen de mayor tolerancia a las diferencias entre personas.

Abiertos a temas polémicos y a familias no tradicionales [Fonseca, 2003] son propensos al consumo en masa.

1269

Para estimar un segmento poblacional de generación “Y” se puede considerar la evolución demográfica de La Argentina. Las personas nacidas entre los años 1981 y 2001 son 8.310.650 millones de habitantes. Aquellos con plena capacidad de derecho, mayores de edad (21 años para la Ley Civil de La Argentina) los aproxima a la cantidad de 4.666.048 millones de habitantes [INDEC, 2010].

La actual revolución digitalizadora de Internet [Krotoski, 2010] podría actuar como medio de trasporte de productos y servicios de consumo inagotable [López Sánchez y Sandulli, 2002] hasta generaciones jóvenes, permeables a tecnologías [Fonseca, 2003] donde la exposición desmedida podría estar gestando, en silencio, un conjunto de personas ciber-adictas [Llinares Pellicer y Lloret Boronat, 2008]. Debe considerarse que con poco más que diez años de comercio electrónico, algunos de los productos digitalizados como libros, música, películas y aplicaciones móviles; constituyen ejemplos de negocios de alto crecimiento en el planeta [Wasserman, 2010].

El problema que se presenta es encontrar perfiles comunes, sobre aquellos usuarios de Internet, que consuman productos y servicios digitalizados, de modo que si experimentan algún patrón de conducta compulsiva al hacerlo, puedan minimizarse las consecuencias humanas e individuales en base a la investigación de las causas.

3. Solución Propuesta Los nuevos mercados de información o ciber mercados [Kotler y Keller, 2006] son lo suficientemente grandes y representativos, más precisos que otras técnicas para la extracción de información difusa, como las encuestas y sondeos de opinión [Asur y Huberman, 2010]. Los flujos de producción, modificación, intercambio y remixación de información responden a lógicas propias de entes colectivos [García y Gertrudix, 2011]. Los servicios abiertos están configurando un modelo revolucionario de intercambio y producción de información en la red. [Glez, 2006].

En los últimos años es común aprovechar la potencia informática para predecir resultados de comportamiento social [Asur y Huberman, 2010]. Apoyados en teorías matemáticas podrían resolverse dilemas de carácter social dentro del marco de la teoría de juegos [Glance y Huberman, 1994]. La información correctamente procesada podría aportar una forma de sabiduría colectiva para predecir resultados del mundo real [Asur y Huberman, 2010]. Puede utilizarse la potencia computacional para desarrollar un conjunto de datos para estudiar algo específico, constituyendo una fuente primaria, dado que la recopilación es propia [Ander-Egg, 2003].

Al estudiar datos estimados de sobre una posible realidad podría considerarse que se tiene una muestra simulada [Tarifa, 2001], obtenida a través de un proceso que incluye diseñar un modelo sobre un sistema real para llevar a cabo experiencias con él, a fin de aprender sobre su comportamiento [Shannon, 1988].

El método de simulación de Montecarlo es una técnica que combina conceptos estadísticos de muestreo aleatorio con la capacidad que tienen las computadoras para generar números pseudo-aleatorios y automatizar cálculos [Kalos y Whitlock, 1986; Peña Sánchez de Rivera, 2001]. Al agregar información acerca del comportamiento de una muestra representativa, podría disponerse saltos incrementales en la calidad de los datos y ser considerados confiables para obtener posibles conclusiones. La

1270

evaluación de los resultados de una simulación podría dar entendimiento sobre el conjunto de consecuencias provocadas por un hecho o actuación afectada [Shannon, 1988].

La solución propuesta, al problema descrito en esta tesis, consiste en simular el consumo de bienes y servicios digitalizados por Internet, generando una muestra representativa de perfiles de usuario, apuntalado sus datos individuales con información de fuentes fidedignas sobre la sociedad contemporánea de La Argentina y otros típicos de usuarios de La Internet.

Para formular los aspectos relevantes del sistema de estudio se desarrollará un modelo matemático-informático que analice el modo de satisfacer las necesidades del presente, sin comprometer a las generaciones futuras para satisfacer las suyas, integrando los aspectos económicos, ecológicos y sociales, que son dinámicos e interactúan entre si, influenciándose el uno con los otros dos y, además, enlaza el corto plazo con el largo plazo [Gardetti, 2003b].

El apoyar el paradigma conceptual en criterios de sustentabilidad podría colaborar con un crecimiento humano justo, conectado, prudente y seguro [Gardetti, 2003a] donde la innovación y el cambio tecnológico posiblemente permitan alcanzar un desarrollo sustentable, colaborando con usuarios, empresas oferentes y estados fiscalizadores.

4. Experimentos Los datos creados en el Simulador de Ciber-adicciones, por el método de Montecarlo-sociabilizado con información contemporánea de La Argentina [INDEC, 2001; INDEC, 2009; INDEC, 2011; INDEC, 2012; Samuelson et al., 2003] y otros comunes a los usuarios de Internet [Adigital, 2012; Muñoz-Ramos Mas, 2012] podrían ser interpretados con diferentes técnicas estadísticas u otras avanzadas sobre explotación de información.

En este trabajo se presentan los resultados e interpretaciones sobre el comportamiento simulado de perfiles de usuario de Internet en base a una adaptación de los criterios de referencia sobre desordenes mentales en ludopatía [APA, 1995]. Se divide el impacto en los ejes: económico, ambiental y social que podría producir en la masa de usuarios las ciber-adicciones a Internet (IAT), a los juegos de apuestas por Internet (DSM), a las compras compulsivas por Internet (CBMS) y las redes sociales por Internet (BFAS).

4.1. Análisis sobre el Eje Económico En términos de impacto sobre el eje económico, como se muestra en la Figura 1 “Curva de valor de impacto por ahogo financiero y comisión de actos ilegales”, el ahogo financiero (AF) se presenta creciente para el conjunto de perfiles de usuario, pudiendo colaborar al efecto los medios de pago y las posibilidades crediticias brindadas por el sistema bancario. Esto podría sostener una hipótesis referida al aumento sobre el consumo, hasta el ahogo, debido a las posibilidades crediticias y el dinero virtual. La comisión de actos ilegales (CAI) se presenta, para la media de

1271

perfiles de usuario, con bajo impacto. Sobre el final, la curva se eleva y podría indicar que los pocos perfiles de usuario que llegan hasta el extremo de cometer actos delictivos, afrontan un fuerte impacto económico por el consumo de bienes y servicios digitalizados por Internet.

4.2. Análisis sobre el Eje Ambiental Al analizar el criterio de preocupación recurrente (PR) por el consumo de bienes y servicios digitalizados por Internet, según la Figura 2 “Curvas de impacto aportado por compras compulsivas, uso de redes sociales, uso de juegos de apuesta y uso de Internet” se podría argumentar que la curva sobre aspectos ambientales de compras compulsivas (CBMS) supera en términos de impacto a las demás y podría ser el principal aportante a la preocupación recurrente. Siguen las gráficas sobre el uso de Internet (IAT), conexión a las redes sociales (BFAS) y uso de juegos de apuestas (DSM) que podrían generar un pensamiento continuo sobre el consumo y alterar algunas esferas del perfil de usuario relacionadas con la ansiedad.

180

250 200 150 100 50 0

160 140 120 100 80 60 40 20 0 1

3

5

7

9

11

13

15

17

19

AF: Ahogo Financiero CAI: Comisión de Actos Ilegales

Fig. 1. Curva de valor de impacto por ahogo financiero y valor de impacto por comisión de actos ilegales. (Promedio de a 500 perfiles de usuario, valor de impacto)

1 3 5 7 9 11 13 15 17 19 CBMS: Sobre Compra Compulsiva BFAS: Sobre las Redes Sociales DSM: Sobre los Juegos de Apuesta IAT: Sobre el Uso de Internet

Fig. 2. Curvas de valor de impacto aportado por compras compulsivas, uso de redes sociales, uso de juegos de apuesta y uso de Internet (Promedio de a 500 perfiles de usuario, valor de impacto)

Las curvas de las variables independientes que se comparan en la Figura 3 “Curvas de impacto aportado por compras compulsivas, uso de redes sociales, uso de juegos de apuesta y uso de Internet” refieren al criterio de progresión del incremento (PI), pudiéndose argumentar que lo referido al uso de Internet (IAT) supera en términos de impacto y muestra un salto creciente y pronunciado para un grupo de perfiles de usuario. Esto podría indicar la necesidad de encontrarse conectado a Internet durante cada vez más tiempo para sentir confort. La progresión del incremento en las operaciones de compra (CBMS) crece en mayor medida que la participación de redes sociales (BFAS) y el uso de juegos de apuesta (DSM). Estas condiciones podrían relacionarse con la voluntad que presenta cada perfil de usuario para acotar estos consumos.

La Figura 4 “Curvas de impacto aportado por compras compulsivas, uso de redes sociales y uso de juegos de apuesta” analiza el comportamiento de las variables independientes sobre la intensión de retiro (IR) al consumir bienes y servicios digitalizados. Se podría argumentar que la curva para el uso de las redes sociales

1272

(BFAS) presenta un pico de impacto por encima de las demás e indicaría un contenido difícil de abandonar para un algún grupo de perfiles de usuario. Para la media se presenta de bajo impacto. Al analizar la gráfica de los aportes sobre las operaciones de comercio en los portales de compra (CBMS) podría interpretarse alguna dificultad para retirarse y terminar la sesión, tal vez no tanto como con el uso de las redes sociales (BFAS). La curva sobre el uso de juegos de apuesta (DSM) se presenta de bajo impacto, pero un grupo de perfiles de usuario se muestra con dificultades para retirarse del contenido. Podría ser importante considerar si los excesos de tiempo para consumo de bienes y servicios digitalizados ocurren esporádicamente.

120

250 200 150 100 50 0

90 60 30

1 3 5 7 9 11 13 15 17 19 CBMS: Sobre Compra Compulsiva BFAS: Sobre las Redes Sociales DSM: Sobre los Juegos de Apuesta IAT: Sobre el Uso de Internet Fig. 3. Curvas de valor de impacto aportado por compras compulsivas, uso de redes sociales, uso de juegos de apuesta y uso de Internet (Promedio de a 500 perfiles de usuario, valor de impacto)

0 1 3 5 7 9 11 13 15 17 19 CBMS: Sobre Compra Compulsiva BFAS: Sobre las Redes Sociales DSM: Sobre los Juegos de Apuesta Fig. 4. Curvas de valor de impacto aportado por compras compulsivas, uso de redes sociales y uso de juegos de apuesta (Promedio de a 500 perfiles de usuario, valor de impacto)

Al analizar las curvas de las variables independientes según la Figura 5 “Curvas de impacto aportado por compras compulsivas, uso de juegos de apuesta y uso de Internet” respecto del criterio de tendencia a la repetición (TR) se podría argumentar que la curva sobre aspectos ambientales por compras (CBMS) se muestra por encima de las demás y podría indicar que la actividad comercial se repite fuertemente para un grupo de perfiles de usuario. Para la media se presenta de bajo impacto. Al analizar la gráfica de los aportes sobre el uso de Internet (IAT) podría interpretarse alguna dificultad para no reiterar la actividad, tal vez no tanto como con las compras (CBMS). La curva sobre el uso de juegos de apuesta (DSM) se presenta de bajo impacto, pero un grupo de perfiles de usuario se muestra con dificultades para controlar el uso reiterado de los juegos.

4.3. Análisis sobre el Eje Social La Figura 6 “Curvas de impacto aportado por compras compulsivas, uso de redes sociales, uso de juegos de apuesta y uso de Internet” presenta a las curvas de las variables independientes sobre el criterio de perdida de control (PR) y podría argumentarse que la curva sobre aspectos sociales de compras compulsivas (CBMS) supera en términos de impacto a las demás siendo el principal aportante a la pérdida

1273

de control. Siguen las gráficas sobre el uso de Internet (IAT), conexión a las redes sociales (BFAS) y uso de juegos de apuestas (DSM) que podrían generar un pensamiento continuo sobre el tema para olvidar temporalmente otros aspectos de la realidad.

100

200

75

150

50

100 50

25

0

0 1 3 5 7 9 11 13 15 17 19 CBMS: Sobre Compra Compulsiva DSM: Sobre los Juegos de Apuesta IAT: Sobre el Uso de Internet Fig. 5. Curvas de valor de impacto aportado por compras compulsivas, uso de juegos de apuesta y uso de Internet (Promedio de a 500 perfiles de usuario, valor de impacto)

1 3 5 7 9 11 13 15 17 19 CBMS: Sobre Compra Compulsiva BFAS: Sobre las Redes Sociales DSM: Sobre los Juegos de Apuesta IAT: Sobre el Uso de Internet Fig. 6. Curvas de valor de impacto aportado por compras compulsivas, uso de redes sociales, uso de juegos de apuesta y uso de Internet (Promedio de a 500 perfiles de usuario, valor de impacto)

Al analizar las curvas de las variables independientes sobre el criterio de escape de la vida (EV) de la Figura 7 “Curvas de impacto aportado por compras compulsivas, uso de redes sociales, uso de juegos de apuesta y uso de Internet” se podría argumentar que la curva sobre aspectos sociales por el uso de Internet (IAT) supera en términos de impacto a las demás y podría ser el principal aportante al escape de la vida. Siguen las gráficas de conexión a las redes sociales (BFAS), compras compulsivas (CBMS) y uso de juegos de apuestas (DSM) que podrían presentar una serie de actividades que permitan al perfil de usuario olvidar sus obligaciones cotidianas y no afrontar los aspectos reales de la vida, pudiendo ser una actividad personal y secreta. La tendencia al ocultamiento (TO) sobre el consumo de bienes y servicios digitalizados se analiza en la Figura 8 “Curvas de impacto aportado por compras compulsivas, uso de juegos de apuesta y uso de Internet”. Las variables independientes podrían argumentar que la curva sobre aspectos sociales por el uso de Internet (IAT) se muestra por encima de las demás y es acompañada por la curva sobre compras (CBMS) pudiendo indicar que son actividades que tienden a ser ocultadas. La curva sobre el uso de juegos de apuesta (DSM) se presenta de bajo impacto, pero un grupo de perfiles de usuario se muestra con dificultades para controlar la actividad cayendo en el ocultamiento, incluso ante otros relacionados por sentimientos afectivos.

5. Conclusiones Sobre los ejes económico, ambiental y social, se han presentado varios aspectos y criterios de estudio con dos posibles grupos de impacto: bajo y alto, lo que podría

1274

sostener la hipótesis de que algunos perfiles de usuario no presentan atracción hacia el consumo masivo de bienes y servicios digitalizados por Internet o mantienen un buen nivel de control de consumo. Otros podrían presentar mayores dificultades.

La información obtenida en los experimentos podría ser procesada con otras técnicas de explotación de la información a fin de descubrir nuevas reglas e inferencias y complementar las gráficas e interpretaciones sobre las variables del modelo conceptual de impacto de consumo. Profundizar en esta linea de trabajo, permitirá obtener patrones de conductas de grupos que permitan a las empresas de Internet mitigar el posible impacto del consumo masivo de productos y servicios digitalizados en pos de mejorar la licencia para operar [Debeljuh, 2010] y desarrollar la perpetuidad de sus negocios.

200

300 150

200 100

100

50

0 1 3 5 7 9 11 13 15 17 19 CBMS: Sobre Compra Compulsiva BFAS: Sobre las Redes Sociales DSM: Sobre los Juegos de Apuesta IAT: Sobre el Uso de Internet Fig. 7. Curvas de valor de impacto aportado por compras compulsivas, uso de redes sociales, uso de juegos de apuesta y uso de Internet (Promedio de a 500 perfiles de usuario, valor de impacto)

0 1 3 5 7 9 11 13 15 17 19 BFAS: Sobre las Redes Sociales DSM: Sobre los Juegos de Apuesta IAT: Sobre el Uso de Internet Fig. 8. Curvas de valor de impacto aportado por el uso de redes sociales, uso de juegos de apuesta y uso de Internet (Promedio de a 500 perfiles de usuario, valor de impacto)

6. Financiamiento Las investigaciones que se reportan en este artículo han sido financiadas parcialmente por el Proyecto de Investigación 33B112 de la Secretaria de Ciencia y Técnica de la Universidad Nacional de Lanús (Argentina).

7. Referencias Acta de Comercio Libre y Zona Procesada, 1994. “Free trade and processing zone act”, por el gobierno de Antigua Barbuda. http://www.antiguagaming.gov.ag/files/Antigua_and_Barbuda_Gaming_RegulationsFinal.pdf (Última visita al sitio expuesto: 13 de julio de 2012).

Acta de Prohibición del Juego en Línea, 1997. “The Internet gambling prohibition act of 1997. 105th Cong.

Hearing on H.R. 4777 Before the H. Comm. on the Judiciary and the Subcomm. on Crime, Terrpros, amd Homeland Security., 109th Cong. (2006) [hereinafter Ohr Statement] (statement of Bruce G. Ohr, Chief of Organized Crime and Racketeering Section, U.S. Dept. of Justice”.

1275

http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=109_cong_bills&docid=f:h4777ih.txt.pdf (Última visita al sitio expuesto: 13 de julio de 2012).

Adigital. 2012. Libro blanco de comercio electrónico. Guía práctica de comercio electrónico para PYMES. Asociación Española de la Economía Digital y Ministerio de Industria, Energía y Turismo de España. http://libroblanco.adigital.org//descarga.html (última visita al sitio expuesto: 15 de octubre de 2012) Amit, R. y Zott, C. 2001. Value Creation in E-Business. Strategic Management Journal 22: 493–520. ISSN 1097-0266.

Ander-Egg, E. 2003. Métodos y técnicas de investigación: Técnica para recogida de datos e información social I. Grupo Editorial Lumen. ISBN 987-00-0301-X Andrade, J. 2000. Formación de precios de los productos de información en redes digitales. Revista Venezolana de Gerencia.

Universidad de Zulia.

Venezuela.

ISSN 1315-9984. http://revistas.luz.edu.ve/index.php/rvg/article/view/7881/7547 (Última visita 13/07/2012).

APA. 1995. Manual diagnóstico estadístico de los trastornos mentales. Asociación Americana de Psiquiatría. Versione española. ISBN: 84-458-0297-6. http://www.mdp.edu.ar/psicologia/ cendoc/archivos/Dsm-IV.Castellano.1995.pdf (Última visita al sitio expuesto: 8 de julio de 2013).

Araya Dujisin, R. 2005. Internet, política y ciudadanía. 195: 56-71. ISSN 0251-3552.

Aspis, A., Pertusi, I., Nieva, H. 2006. Comercio Electrónico: e-commerce. Régimen contractual del comercio electrónico. Aspectos tributarios del comercio electrónico. Nuevas bases para gravar el ecommerce. Editorial Errepar. Bs. As. Argentina. ISBN-13 978-987-01-0570-1.

Asur, S. y Huberman, B. 2010. Predicting the future with social media. Social Computing Lab. HP Lab. http://arxiv.org/abs/1003.5699 (Última visita al sitio expuesto: 8 de julio de 2013).

Barua, A., Whinston, A., Konana, P. 2007. Assessing Internet Enabled Business Value: An Exploratory Investigation. Task Report. Center for Research in Electronic Commerce. Department of MSIS. McCombs School of Business. University of Texas at Austin. http://en.scientificcommons.org/ 43217363 (Última visita al sitio expuesto: 13 de julio de 2012).

Debeljuh, P. 2010. Ética empresarial en el núcleo de la estrategia corporativa. Editorial Cengage Learning.

ISBN:978-987-1486-13-7.

Elaluf-Calderwood, S., Sorensen, C., Eaton B. 2011. Digital Innovation on Mobile Platforms: A Business Model Analysis. London School of Economics and Political Science. London. WC2A 2AE. UK. ACM 1-58113-000-0/00/0010. http://de2011.computing.dundee.ac.uk/ wp-content/uploads/2011/10/DigitalInnovation-on-Mobile-Platforms-A-Business-Model-Analysis.pdf (Última visita 13/07/2012).

Fonseca, J. 2003. Conociendo a la generación Y. Ponencia presentada en la 9na. Conferencia Anual del College Board. Universidad del Sagrado Corazón. Puerto Rico. http://www.collegeboard.com/ptorico/ academia/diciembre03/conociendo.html (Última visita 13/07/2012) García F. y Gertrudix, M. 2011, Naturaleza y características de los servicios y los contenidos digitales abiertos. Cuadernos de información y comunicación, ISSN: 1135-7991.

Gardetti, M. 2003a. Creando valor sustentable. Instituto de Estudios para la sustentabilidad corporativa.

Buenos Aires. Argentina. Registro de propiedad intelectual Nro.: 274369. Copyright 2003.

Gardetti, M. 2003b. Desarrollo sustentable, sustentabilidad y sustentabilidad corporativa. Instituto de Estudios para la sustentabilidad corporativa. Buenos Aires. Argentina. Registro de propiedad intelectual Nro.: 274369. Copyright 2003.

Glance, N y Huberman, B. 1994. The dynamics of the social dilemmas. Scientific American. http://www.casos.cs.cmu.edu/education/phd/classpapers/Glance_Dynamics_1994.pdf (Última visita 8/07/2012) Glez F., 2006. La Web 2.0: características, implicancias en el entorno educativo y algunas de sus herramientas”, Departamento de Matemática, Universidad de Leon, España. http://www.iesevevirtual. edu.ar/virtualeduca/ponencias2006/La%20Web20_Santamaria.pdf (Última visita 10/03/2012) Howson C. 2008. Business Intelligence. Estrategias para una implementación exitosa. Editorial McGrawHill Interamericana S.A. de C.V. Edición en Español. ISBN13 978-970-10-6759-8. http://www.econ.unicen.edu.ar/attachments/1051_TecnicasIISimulacion.pdf (Última visita 8/07/2013) INDEC. 2001. Censo Nacional de Población, hogares y viviendas. Definiciones de la base de datos.http://www.indec.gov.ar/redatam/CPV2001ARG/docs/Definiciones%20CD%20Base%20CNPHV 2001_d.pdf (última visita al sitio expuesto: 15 de octubre de 2012) INDEC, 2010. Evolución de la población argentina a través de los censos, Los censos de la población Argentina, Instituto Nacional de Estadísticas y Censo. http://www.censo 2010.indec.gov.ar/escuela.asp (Última visita al sitio expuesto: 13 de julio de 2012) INDEC. 2009. Encuesta permanente de hogares. Diseño de registro y estructura para las bases de micro datos.

Individual y Hogar.

Instituto Nacional de Estadística y Censo.

1276

http://www.santafe.gov.ar/index.php/web/content/download/80497/388465/file/EPH_disenoreg_09.pdf (última visita al sitio expuesto: 15 de octubre de 2012) INDEC. 2011. Indec Informa. Instituto Nacional de Estadística y Censo. Año: 16. Nro.: 7. ISSN 0328-5804 INDEC. 2012. Censo nacional de población, hogares y viviendas 2010: censo del Bicentenario. Instituto Nacional de Estadística y Censo. Resultados definitivos. Se B No 2. – 1ra ed. ISBN 978-950-896-421-2 Janita Muñoz, M. 2005. Los e-mercados, un nuevo modelo de mercado electrónico B2B. Departamento de economía aplicada y organización de empresas. Universidad de Extremadura. España. http://www.asepelt.org/ficheros/File/Anales/2005%20-%20Badajoz/comunicaciones/los%20e-mercados .pdf (Última visita al sitio expuesto: 13 de julio de 2012).

Kalos, M. y Whitlock P. 1986. Monte Carlo Methods. Vol I .Basics. John Wiley & Sons. New York.

Kotler, P. y Keller, K. 2006. Dirección de marketing. Duodécima Edición. Editorial Prentice Hall INC. ISBN 970-26-0763-9.

KPMG, 2000. The Economic Value and Public Perceptions of Gambling in the UK. Report for Business in Sport and Leisure. London: KPMG. Krotoski, A. 2010. La revolución virtual. Open University on the BBC. The Open University.

UK.http://www.open.edu/openlearn/science-maths-technology/engineering-and-technology/ technology/frontier-thinking/ou-on-the-bbc-the-virtual-revolution (Última visita 13/07/2012).

Llinares Pellicer, M. y Lloret Boronat, M. 2008. Ciber adicción: Los riesgos de Internet. Revista de Análisis Transaccional y Psicología Humanista, Nº 59. Vol: XXVI, Madrid. España. ISSN: 0212-9876 López Sánchez, J. y Sandulli, F. 2002. Evolución de los modelos de negocio en Internet: Situación actual en España de la economía digital. Universidad Complutense de Madrid. España. http://www.ucm.es/info/business/Documentos/articulos/030703.pdf (Última visita al sitio 13/07/2012).

Menascé, D. 2002. TPC-W: A Benchmark for E-Commerce. IEEE Internet Computing, 6(3): 83-87. ISSN 1089-7801.

Muñoz-Ramos Mas, M. 2012. Implicaciones socioeconómicas de las redes sociales en el mundo global.

Tesina para Licenciatura en Publicidad y Relaciones Públicas. Facultad de Ciencias Sociales.

Universitat Abat Oliba CEU. Nascarella, M. 2009. Modelo de Agregación de Demandas Individuales con Reputación. Tesis de Magister en Ingeniería de Sistemas de Información. Escuela de Posgrado. Facultad Regional Buenos Aires.

Universidad Tecnológica Nacional. http://posgrado.frba.utn. edu.ar/investigacion/tesis/MIS-2009Nascarella.pdf (Última visita al sitio expuesto: 13 de julio de 2012).

Peña Sánchez de Rivera, D. 2001. Deducción de distribuciones: el método de Montecarlo. Fundamentos de Estadística. Madrid: Alianza Editorial. ISBN: 84-206-8696-4.

Rayport, J. y Sviokla, J. 1995. Exploiting the virtual value chain. Harvard Business Review. http://hbr.org/product/exploiting-the-virtual-value-chain/an/95610-PDF-ENG (Última visita al sitio expuesto: 13 de julio de 2012) Ruíz, M. y Palací, F. 2011. Variables cognitivas y psicología del consumidor. El modelo de la confirmación de expectativas en la actualidad. Boletín de Psicología, No. 103, 61-73. Departamento de Psicología Social y de las Organizaciones. Facultad de Psicología. Universidad Nacional de Educación a Distancia. http:// www.uv.es/seoane/boletin/ previos/N103-4.pdf (Última visita 3/04/2012).

Samuelson, P., Nordhaus W., Enrri D. 2003. Economía. McGraw –Hill, ISBN-13: 978-987-1112-02-9.

Shannon, R. 1988. Simulación de Sistemas. Diseño, desarrollo e implementación. Editorial Trillas. México.

ISBN: 978-968-2426-73-5.

Tarifa, E. 2001. Teoría de modelos y simulación. Facultad de ingeniería. Universidad Nacional de Jujuy van Hooft, F. y Stegwee, R. 2001. E-business strategy: how to benefit from a hype. Logistics Information Management, 14 (1/2): 44-53. ISSN 0957-6053.

Wasserman, A. 2010. Ciclo Conversando con los Líderes de los Negocios por Internet. Ponencia presentada en la conferencia nacional “E-Comerce Day”, 24 de septiembre de 2010. .Buenos Aires. Argentina. http://www.ecommerceday.org.ar/material/Wasserman.pdf (Última visita 27/04/2011).

Young, L. y Johnston, R. 2003. The role of the internet in business-to-business network transformations: a novel case and theoretical analysis. Information Systems and E-Business Management, 1(1): 73-91.

ISSN 1617-9846.

Young-Ei, K. y Jung-Wan, L. 2010. Critical factors in promoting customer acceptance of and loyalty to online business management negree programs. African Journal of Business Management Vol. 5(1), pp.

203-211. Academic Journals. ISSN 1993-8233. http://www.academicjournals.org/ajbm/pdf/ pdf2011/ 4Jan/Kim%20and%20%20Lee.pdf (Última visita al sitio expuesto: 13 de julio de 2012).

1277

Software e innovación: desarrollando productos con hardware y software flexible Daniel Díaz, Sandra Oviedo, Leandro Muñoz, Francisco Ibañez, Universidad Nacional de San Juan, Facultad de Ciencias Exactas Físicas y Naturales, Instituto de Informática y Departamento Informática {ddiaz, soviedo, lmuñoz, fibannez}@iinfo.unsj.edu.ar

Resumen. Desde hace un tiempo la innovación se ha transformado en la fuente más importante de generación de valor y competitividad. En este contexto el software ha dejado de ser una tecnología de soporte oculta e invisible a los clientes para transformarse en el eje conductor del proceso creador de valor.

Como consecuencia la ingeniería de software y la ingeniería de innovación tienen el desafío de integrarse y complementarse para adecuarse a los desafíos actuales. Este trabajo expone la importancia de la relación software e innovación y relata una experiencia académica que las vincula con el objeto de motivar el espíritu innovador de los alumnos, la misma se enfoca en el desarrollo de productos que tienen como base al software y hardware flexible.

Palabras claves: Software e Innovación, Software Flexible, Desarrollo de Productos Basados en Software

1 Introducción Desde el surgimiento de la era de la computación, software, hardware e industria han vivido una sinergia. Cada cambio importante en el hardware y software ha sido influenciado por la industria y a su vez las nuevas tecnologías impulsadas por los cambios en el hardware y software han producido cambios en la industria.

Disponer de Software Flexible ha sido un anhelo desde el surgimiento del MRP (planificación de requerimientos de material) en los 1960 hasta la Cloud Manufacturing del 2010. Sin embargo el término software flexible ó software flexibilidad no tiene una definición concreta, esta depende de la perspectiva que se enfoque. Por ejemplo, desde una perspectiva sistémica Zhao [1] ha propuesto dos conceptos relacionados con la flexibilidad del software: la adaptabilidad del sistema y la versatilidad del sistema. Nelson y otros [2] definen a la flexibilidad de la tecnología como las características de la tecnología que permiten habilitar ajustes u otros cambios a los procesos de negocio. Desde la perspectiva del desarrollo de software la flexibilidad es una temática actual. Una gran cantidad de técnicas y métodos tiene a la flexibilidad como objetivo. Por ejemplo, el desarrollo dirigido por modelos, las líneas de productos de software, la programación generativa son paradigmas que intentan construir fábricas de software que permitan generar software a partir de solo describir un modelo que la fábrica de software interpreta para generar

1278

una aplicación o software [3]. Esto es claramente un proceso de desarrollo flexible que permite modelar rápidamente los cambios que se producen en el ambiente y generar el código ejecutable que satisface a las nuevas necesidades.

Por otro lado, el Hardware flexible o hardware flexibilidad ha sido uno de los pilares que ha guiado la constante evolución del hardware. Desde el surgimiento de los circuitos integrados se ha buscado dispositivos electrónicos altamente customizables, adaptables a diversos usos, de interface sencilla, e interoperables.

Todas estas características que definen un hardware flexible. Solo basta analizar la evolución de los microprocesadores para observar como estos han incrementado notoriamente su flexibilidad.

Hoy en día un nuevo movimiento denominado Hardware de Código Abierto ó Open Source Hardware está revolucionando la forma en la cual los productos serán diseñados, construidos y comercializados en un futuro. El Hardware de Código Abierto combina hardware y software flexible en una plataforma. Físicamente, este tipo de plataformas consiste en una placa basada en un microcontrolador que tiene entradas y salidas programables más un entorno de desarrollo de software. Es el software que permite transformar este hardware en un producto concreto. Este movimiento está facilitando el acceso a nuevas tecnologías de vanguardia a pequeños emprendedores quienes pueden desarrollar sus ideas tecnológicas con una muy baja inversión. Esto ha revalorizado aun más la creatividad y el poder innovador de una persona y está contribuyendo notablemente a establecer una nueva era, la era de la innovación.

Este artículo tiene por un objeto mostrar mediante el uso de una plataforma de hardware de código abierto cómo software e innovación es un mix interesante que puede ser utilizado para concretar ideas con alto contenido tecnológico utilizando un presupuesto de bajo costo.

2

Software e Innovación

Cada vez más la economía está pasando de una economía basada en el conocimiento a una economía basada en la creatividad y la innovación [4-6]. Un estudio realizado por Siemens pone de manifiesto que hoy en día hasta el 70% de los ingresos de una empresa es generado por productos o características que no existían hace cinco años [7]. Además de esto, el 90% de los gerentes de empresas en sectores como la aviación, del automóvil, el farmacéutico, y las telecomunicaciones consideran la innovación como algo esencial para alcanzar sus objetivos estratégicos [4]. "El dilema del innovador" [8] ya no es, en muchos casos, un dilema para las empresas que desarrollan productos, la innovación se ha convertido en una necesidad absoluta para hacer frente a los desafíos globales y las tendencias del futuro.

Una observación importante a realizar en este contexto es que el software es incrementalmente usado como el instrumento para hacer innovación: “el software es el motor de la innovación”. Esta tendencia no sólo es válida dentro de los nichos de mercado específicos, sino que el software es un elemento relevante en una amplia gama de sectores. Software ya no es una tecnología de apoyo, sino que este toma un papel esencial en el proceso de creación de valor.

1279

Ser "el primero" es importante si se quiere ser innovador. Por eso, muchas empresas están compitiendo en una carrera por hacer punta en el mercado. El ciclo de vida del producto se está reduciendo a un ritmo constante, hoy en día, pocos son los productos con un ciclo de vida de un año o más.

2.1 Desarrollo Flexible y desarrollo de software flexible La necesidad de ser el primero, la carrera por la punta del mercado, y el dilema de la innovación conducen a una necesidad de obtener flexibilidad. Desarrollo flexible es la capacidad de responder rápidamente a las nuevas necesidades del mercado y las peticiones del cliente. Se trata de aumentar la velocidad a la que las innovaciones y las ideas son llevadas al mercado. Las empresas sienten la necesidad creciente de ofrecer productos a tiempo. En este contexto y desde la perspectiva del desarrollo de software es necesario introducir el concepto y las técnicas necesarias para llevar a cabo el desarrollo flexible. Desde este punto de vista se puede definir al desarrollo de software flexible como el proceso que permite el desarrollo flexible.

2.2 Innovación y Software Flexible Como se ha mencionado en algunos párrafos anteriores, la innovación se ha convertido en una necesidad absoluta para hacer frente a los desafíos globales y las tendencias del futuro. De esta necesidad surge el software flexible que es uno de los elementos necesario tanto para hacer frente a los cambios que producen la innovación como así también para ser innovadores.

3

Ingeniería de la Innovación e Ingeniería de Software

El principal desafío de la industria del software siempre ha sido entregar productos de software a tiempo, adecuados a presupuestos pre-establecidos y con una calidad aceptable, esta ha sido y es la tarea de la Ingeniería del Software. En este campo importantes logros se han alcanzado, mediante un conjunto de herramientas muy bien logradas en áreas tales como desarrollo de software, gestión de recursos tecnológicos, arquitectura de software, análisis de requerimientos, calidad de software, testing automático, entre otras.

A lo largo de la historia de la industria diversas estrategias y tácticas han sido planteadas para generar valor. Desde hace un tiempo se perfila la innovación como la más importante fuente de generación de valor y competitividad [9], es decir que para ser competitivas, las compañías deberán ser innovadoras. En un vasto sector industrial la innovación está dejando de ser una palabra para transformarse en una acción. Las empresas están llevando a la práctica la innovación mediante lo que se conoce como gestión de la innovación, esta encierra a un conjunto de prácticas tales como la generación de las ideas, gestión de las mejoras de productos, gestión del ciclo de vida de productos, etc. Desde la academia estas prácticas se han ordenado formando un proceso que se conoce como Ingeniería de la Innovación. Por ejemplo, en [10] se

1280

describen ampliamente 16 prácticas que realizan las empresas mas innovantes, el autor las denomina prácticas de ingeniería de la innovación.

Un cambio importante en lo que respecta al software y la generación del valor está ocurriendo hoy en día y es que el software ha dejado de ser una tecnología de soporte oculta e invisible a los clientes para transformarse en el eje conductor del proceso creador de valor.

Como consecuencia la ingeniería de software y la ingeniería de la innovación tienen el desafío de integrarse y complementarse para adecuarse a los desafíos actuales. Desde la perspectiva de la ingeniería de la innovación existe la necesidad de conocer más acerca del software y sus procesos. Mientras que desde la ingeniería del software es necesario aprender más sobre el proceso innovador para aprovechar las nuevas oportunidades que está ofreciendo el software en la generación del valor a través de la creación de nuevos productos y servicios.

4

Plataformas de hardware abiertas

La OSHWA (Open Source Hardware Association) [11], o asociación de hardware de código abierto en su declaración de principios establece que “el hardware de código abierto es el hardware cuyo diseño se hace disponible públicamente para que cualquiera pueda estudiarlo, modificarlo, distribuirlo, hacer y vender el diseño o hardware basado en ese diseño. El código fuente del hardware, el diseño a partir del cual está hecho, está disponible en el formato preferido para realizar modificaciones en él ". Téngase en cuenta que el hardware de código abierto se refiere específicamente a compartir los archivos de diseño digital de objetos físicos; si bien se apoyan otras formas de compartir, creemos que es importante tener claro el significado de hardware de código abierto.

A pesar que el movimiento de código abierto es muy reciente hay una amplia comunidad de empresas, individuos y grupos que están diseñando y haciendo hardware de código abierto. El ejemplo más conocido es la plataforma de hardware y software flexible “Arduino”, que es objeto de estudio de este artículo. La mayoría de las impresoras 3D que están apareciendo en el mercado son open source hardware (RepRap, MakerBot, Tantilus). Recientemente, una plataforma de juegos denominada OUYA está por ser lanzanda al mercado este año [12]. En estos tres ejemplos presentados no solo el hardware es open source sino el software que permite que los dispositivos cobren vida también es open source. Una cuestión importante a tener en cuenta es que el open source es un fenómeno multiplicador de producto innovantes.

Por ejemplo OUYA abrirá nuevas fronteras en el mercado de los videos juegos, de la televisión de alta definición vía internet, nuevos e innovadores productos surgirán a partir de OUYA. Este camino ya está demostrado con la plataforma Arduino. Hoy en día existe un numeroso conjunto de accesorios que se pueden adjuntar a un Arduino transformando a este en artefacto especializado. Así es posible transformar un Arduino en robot, en una alarma domiciliaria, en un control de riego. Estas plataformas son excelentes medios para explotar la creatividad y transformar ideas en producto innovantes.

1281

5

Arduino

Arduino es un plataforma de hardware abierta basada en una tarjeta electrónica que posee entradas y salidas más un ambiente de desarrollo basado en el lenguaje Processing. Se puede usar para desarrollar objetos interactivos de funcionamiento independiente u objetos que se conectan a una computadora y que pueden interactuar con ella. Por ser un hardware open source la tarjeta puede ser construida por uno mismo o se puede comprar preensamblada. El ambiente de desarrollo o IDE (Integrated Development Environment) se puede descargar desde www.arduino.cc.

Existen diferentes modelos de Arduino, en Fig. 1 se puede observar el Arduino Diecimila. Se pueden ver las entradas y salidas, la conexión USB que permite conectarlo a la computadora para su programación, la conexión a fuente de alimentación y la descripción de la ubicación de cada uno del circuitos integrados.

El costo de un Arduino Duemilanove Atmega328 "hecho en China" es alrededor de los 25 dólares. En Argentina, el Arduino original "made in Italy" se puede conseguir por 200 pesos. El diseño de la placa de Arduino permite agregar "módulos" llamados "shields" concatenándolos, que expanden la conectividad y aplicaciones del sistema y/o reducen la carga computacional del microcontrolador. Los módulos más comunes son de GPS, tarjeta SD, ethernet, Xbee (wireless), bluetooth, touchshield, leds e I/O expandidos, entre otras.

El microcontrolador por defecto no posee sistema operativo (lo cual es lógico). Tan solo existe un bootloader que carga el programa y lo inicializa.

Fig. 1 Arduino diecimila. Imagen tomada de SparkFun.

En Fig. 2 se muestra el aspecto del ambiente de trabajo que permite programar la tarjeta Arduino.

1282

Fig. 2 Ambiente de desarrollo de software de Arduino

El proceso de generación de un producto con Arduino simplificado se inicia con una idea, la cual se plasmara en un prototipo. Se conecta el Arduino a la computadora que se utilizara para desarrollar el programa que transforma al Arduino en el producto deseado. Utilizando el IDE de Arduino compilamos el programa, si no existen errores se procede a desplegar el programa que está en la computadora al Arduino. A partir de este punto se puede comenzar con las pruebas correspondientes o testing. En Fig. 3 se muestra el proceso de construcción de un producto con Arduino.

Fig. 3 Proceso de construcción de un producto con Arduino

En realidad el proceso de desarrollo es iterativo basado en prototipación, es decir, que se arriba al producto final mediante la prototipación incremental.

Arduino está siendo ampliamente utilizado para el desarrollo de productos a nivel prototipo. Es importante mencionar que Arduino favorece a la innovación, o a motivar el espíritu innovador, pero de ninguna manera el sólo hecho de usarlo asegura que se conseguirá un producto innovador.

6

Experiencias académicas. Innovación y software en las aulas.

En este apartado relatamos dos experiencias que relacionan software e innovación, que tuvieron por objetivo motivar el espíritu innovador utilizando la plataforma de hardware abierta Arduino.

La primera experiencia estuvo focalizada en el software con intención de ser utilizarlo en innovación, la segunda, se enfocó en temas de innovación utilizando el software como un camino para innovar. En oras palabras, en la primera experiencia

1283

no se trabajo en la concepción de las ideas, éstas estaban preconcebidas, en la segunda experiencia se trabajo en la generación de ideas para prototipar con Arduino.

Se desarrollaron dos experiencias, en la modalidad de taller:  Taller introducción a la programación de Arduino  Taller de creatividad e innovación. incorporando hardware y software flexibles en la concepción de nuevos productos.

6.1 Taller introducción a la programación de Arduino El objetivo del taller fue introducir a los alumnos en el conocimiento de la plataforma Arduino, diseño de prototipos básicos y programación con lenguaje Arduino para el diseño de sistemas y/o productos interactivos. El taller estuvo dirigido a alumnos de las carreras de informática e ingeniería.

Unos 20 estudiantes asistieron a este taller pertenecientes a las carreras de informática, ingeniería electrónica e ingeniería industrial. Para desarrollo de prácticas, se plantearon desafíos en los cuales se debía desarrollar tanto el componente de hardware como el componente de software, a fin de prototipar la solución. Los alumnos trabajaron en grupos de hasta 5 personas y tuvieron una semana para desarrollar su prototipo. A cada grupo se le proveyó de un kit de equipamiento básico y materiales para el desarrollo que constaba de: 1 tester, 1 plataforma Arduino, 1 experimentor, potenciómetro, juego de llaves, leds, resistencias, displays, etc.

Los desafíos fueron los siguientes: Free Drink. A un innovador barman se le ocurrió la siguiente idea para incrementar las ventas en su bar: Presentar un escala visual de 5 luces de la más débil a la más intensa, conforme avanzan las ventas hay un algoritmo que enciende la siguiente luz en la escala (caso simple: cada $1000), así hasta llegar a la última.

Cuando llega al color más intenso, se declara una vuelta de bebidas gratis y la escala vuelve al punto más débil.

Ecualizador de luces. En una obra de teatro para crear distintos ambientes se necesita que la iluminación cambie de amarillo a rojo, luego de rojo a azul y por último de azul a blanco de manera incremental y lenta. Es decir que en un determinado momento pueden existir dos colores con distinta intensidad.

Pedido de Peatonal. Se necesita programar dos semáforos para un paso peatonal en una ruta. Caso autopista: Este semáforo se activará solo cuando el peatón solicite la pasada apretando el botón ubicado en un pilar al costado de la ruta. Caso Urbano: Aquí cuando un peatón presiona el botón hay un algoritmo que determina cuándo darle luz verde al peatón, este tiempo va a depender del tráfico y del estado de los semáforos de la esquina.

Reloj de Leds. Con 6 leds diseñar un reloj de arena para un juego que marque 2 minutos. Podrías proponer otro modelo de reloj?

Temporizador programable. Dada una luz intensa, se desea que la luz se desvanezca en un cierto periodo de tiempo, este período debe ser regulado por el potenciómetro, tal como podría hacerlo un alumbrado exterior, cuando aclara la luz natural se apaga el alumbrado.

1284

6.2 Taller de creatividad e innovación. Incorporando Hardware y Software Flexibles en la concepción de nuevos productos.

Se planteó como una continuación del taller anterior, ya que se trabajó considerando que los asistentes estaban iniciados en la tecnología de Arduino. Como el taller estaba abierto a todos los estudiantes se hizo una breve introducción a este tema, y se mostraron los prototipos resultantes del taller anterior a fin de poner a todos los asistentes en conocimiento.

El objetivo de este taller fue introducir conceptos de gestión de la innovación y técnicas de creatividad. Teniendo en cuenta que los participantes ya conocían la tecnología de Arduino, se propuso este taller para la generación de ideas a desarrollar con Arduino.

Con una convocatoria más amplia, hubo presencia de estudiantes de las carreras de informática, ingeniería electrónica, ingeniería industrial y diseño industrial. El taller se realizó con 18 estudiantes. Para el desarrollo de prácticas se propuso como eje temático el desarrollo de juguetes tecnológicos y se hicieron dos sesiones de creatividad aplicando dos de las técnicas presentadas.

6.3 Evaluación de las experiencias Para los asistentes a los talleres, se pudo observar que las tecnologías de hardware abierto fueron una revelación, en el taller de Arduino, se lograron resultados sorprendentes para todos, se plantearon los desafíos y las soluciones fueron más allá de estos. Se establecieron vínculos y se valoró el trabajo multidisciplinario, todos fuimos testigos de cómo los unos enseñaban a los otros, cada uno explotando sus capacidades. Puede decirse que se formó una pequeña comunidad con vistas a seguir trabajando en las ideas de proyectos surgidas en las sesiones de creatividad.

Ambas experiencias fueron muy positivas, para docentes y alumnos. Desde el punto de vista de los docentes, entre otras cosas, permitieron conocer lo que podríamos llamar la apertura mental de los estudiantes, es decir, se pudo tener una noción de cuán abiertos mentalmente están los alumnos para proponer o aceptar nuevas ideas. Donde encontramos dificultades para previsualizar los productos en su completitud, solo se enfocaban en las áreas más pertinentes a su formación, los estudiantes informáticos ansiosos por resolver el tema relacionado al software y los estudiantes de ingeniería preocupados por la solución de hardware.

Esto se acentuó más en las sesiones de creatividad al punto que en algunos casos, para expresar una idea, en la instancia de pensamiento divergente, empezaban explicando la solución tecnológica para desarrollarla. Fue muy difícil lograr un pensamiento claramente divergente. Asimismo, se concibieron más de veinte ideas factibles técnicamente y muy novedosas.

También fue muy enriquecedora la experiencia para los docentes en otros aspectos, ya que fue la primera. Se ganó experiencia en dinámica de grupos, debiendo reconocer que fue muy difícil lograr la atmosfera adecuada en la sesión de creatividad, lo cual dejó la enseñanza que para esta actividad es mejor una localización que no sea en el mismo ámbito de la facultad, en un ambiente más propocio. En cuanto a lo institucional cuando se propuso la iniciativa, siendo totalmente extra curricular, hubo opiniones encontradas, apoyos y rechazos en los

1285

colegas. En cuanto al vínculo logrado con los estudiantes, la experiencia fue muy buena, sirvió para ponernos a todos, docentes y estudiantes, en conocimiento del gran potencial que puede tener las personas cuando trabajan motivas, en conjunto, integradas con otras personas de otras especialidades.

7

Conclusiones

Se ha intentado poner de manifiesto la importancia de la relación software e innovación desde una perspectiva actual de la industria. La necesidad que existe que la ingeniería de software y la ingeniería de innovación se integren y complementen en pos de generar valor. Se ha expuesto en qué consiste una plataforma de hardware abierta y como esta se pueden transformar en un medio para explotar la creatividad y transformar ideas en producto innovantes. Enfocándonos en Arduino, una plataforma de hardware abierta se ha descripto una experiencia académica que vincula al software y a la innovación. El objetivo de la experiencia fue motivar el espíritu innovador de los alumnos enfocándonos en el desarrollo de productos que tienen como base al software y hardware flexible. Al evaluar las experiencias hemos denotado los aspectos más notables de las mismas.

8

Trabajos Futuros

Como trabajos futuros se propone el desarrollo de talleres que traten sobre herramientas de gestión de la innovación con el objetivo de seguir instalando la cultura de la innovación en la comunidad universitaria, el cual creemos que es el medio más propicio para la proliferación de nuevas ideas y generación de productos innovadores que se apoyan en el trabajo multidisciplinario.

Referencias 1 2 3 4

5

6 7

Zhao, J.L., Intelligent Agents for Flexible Workflow Systems. AIS Americas.

Conference on Information Systems, Baltimore. Maryland, 1998.

Nelson, K.M., H.J. Nelson, and M. Ghods, Technology flexibility: conceptualization, validation, and measurement. HICSS97- Maui-Hawaii, 1997.

Greenfield, J. and K. Short, Software Factories: Assembling Applications with Patterns, Models, Framworks, and Tools.Wiley. 2004 Dehoff, K. and D. Neely, Innovation and product development: Clearing the new performance bar. , in Booz Allen Hamilton. 2004: http://www.boozallen.com/media/file/138077.pdf.

Nussbaum, B., R. Berner, and D. Brady, Get creative! How to build innovative companies., in Business Week. 2005: http://www.businessweek.com/magazine/content/05_31/b3945401.htm.

Leadbeater, C., We-think: Mass innovation, not mass production. 2008, London: Profile Books.

Rubner, J., Tuned in to today’s megatrends, in Siemens’s Pictures of the future. 2005.: http://w1.siemens.com/innovation/pool/en/publikationen/publications_pof/pof_fall_2005

1286

8 9

10 11 12

/corporate_technology/interview_with_claus_weyrich/pof205_editorial_1326165.pdf. p.

90-91.

Christensen, C.M., The innovatorâ&#x20AC;&#x2122;s dilemma: When new technologies cause great firms to fail. . 1997, Boston: Harvard Business School Press.

Weil, T., Open innovation and the management of innovation. Global open innovation networks, OECD Mines Paristech, CERNA Innovation. , 2009 (http://www.oecd.org/sti/inno/42053837.pdf).

Boly, V., Ingènierie de l'innovation. Lavoisier - Hermes Science. Paris, France, 2008.

ISBN 978-2-7462-1798-0.

Oshwa, Open Source Hardware Association. http://www.oshwa.org/, 2013.

OUYA, OUYA the console game. http://www.ouya.tv/, 2013.

1287

Un Marco de Trabajo para la Integración de Arquitecturas de Software con Metodologías Ágiles de Desarrollo Luis Vivas, Mauro Cambarieri, Nicolás García Martínez, Marcelo Petroff, Horacio Muñoz Abbate.

Laboratorio de Informática Aplicada - Universidad Nacional de Río Negro {lvivas, mcambarieri, ngarciam, mpetroff ,hmunoz}@unrn.edu.ar

Abstract. La construcción de software dentro de un marco metodológico ágil ofrece la posibilidad de contar con procesos livianos y simples, aplicando técnicas de programación que permiten expresar el concepto de agilidad, garantizando código de calidad desde el inicio del proceso de desarrollo.

Algunas técnicas que han sido probadas en metodologías tradicionales de desarrollo de software son usualmente utilizadas en metodologías ágiles, como por ejemplo las pruebas de unidad. En este trabajo proponemos un marco de trabajo basado en una arquitectura en capas, permitiendo guiar el desarrollo de software por medio de una técnica de programación centrada en pruebas de unidad, la cual fue formalizada en una metodología ágil de desarrollo eXtreme Programming. La contribución es un marco de trabajo que permite la integración de una arquitectura de software con la técnica de programación guiada por pruebas de unidad, y la identificación de tecnologías a utilizar para cada una de las capas de la arquitectura. El marco de trabajo propuesto se valida mediante un caso de estudio.

Keywords: Metodologías ágiles; eXtreme Programming (XP); Test Unitarios; Arquitectura de Software; Desarrollo Guiado por Pruebas

1 Introducción Realizar un desarrollo de software con éxito y de calidad depende de varios factores como, por ejemplo, las personas seleccionadas, las herramientas y tecnologías a utilizar, la arquitectura de software y la metodología que guiará el proceso. Su correcta elección es un factor crítico de éxito.

La arquitectura de software brinda una visión abstracta de alto nivel, permitiendo plantear la reutilización y la evolución del código. Por otro lado, las metodologías ágiles permiten generar productos de calidad, basándose en la adaptabilidad del proceso de desarrollo de software para aumentar sus posibilidades de éxito por la flexibilidad y eficacia sobre las metodologías tradicionales.

Este trabajo explora como adaptar la arquitectura de software con la práctica del desarrollo guiado por pruebas (Test Driven Development - TDD) dentro de metodologías ágiles de desarrollo de software. En particular, considera la arquitectura de software en capas y la metodología de desarrollo ágil eXtreme Programming [1].

1288

La contribución del mismo es mostrar la factibilidad del enfoque, presentando un marco de trabajo que incluye la selección de tecnologías que permiten su implementación. El marco propuesto se valida mediante un caso de estudio.

El trabajo está estructurado de la siguiente manera: La Sección 2 presenta los conceptos relacionados, incluyendo eXtreme Programming, arquitectura de software, desarrollo dirigido por pruebas (Test Driven Development - TDD) y pruebas unitarias. La Sección 3 explica el marco de trabajo propuesto y las tecnologías seleccionadas. A continuación, la Sección 4 valida el marco de trabajo propuesto a través de un caso de estudio y muestra como aplica TDD en el desarrollo de una de las capas de la arquitectura. La Sección 5 presenta otros aportes científicos en esta línea de investigación y discute la contribución de este trabajo. Por último, la Sección 6 brinda conclusiones y explica los trabajos futuros.

2 Conceptos Utilizados Las siguientes secciones presentan los conceptos básicos utilizados en este trabajo, incluyendo: eXtreme Programming (Sección 2.1), arquitectura de software (Sección 2.2), test driven development (Sección 2.3) y pruebas unitarias (Sección 2.4).

2.1 eXtreme Programming eXtreme Programming (XP) es una metodología ágil, descrita por Kent Beck [2], que centra sus prioridades en las personas y no en los procesos, alentando a los desarrolladores a responder a requerimientos cambiantes de los usuarios, aún en fases tardías del ciclo de vida del desarrollo. Se basa principalmente en la comunicación e interacción permanente con el usuario y en la programación de a pares (técnica de programación por parejas donde uno de los programadores escribe el código y el otro lo prueba, y luego se intercambian los roles). De esta forma, desde el principio, el código se prueba en base a requerimientos funcionales.

El proceso consiste de tres etapas: 1) Interacción con el Cliente - el cliente está disponible durante todo el proyecto para interactuar con el equipo de trabajo. De esta manera, se elimina la fase inicial de recolección de requerimientos, y éstos se van incorporando ordenadamente a lo largo del desarrollo; 2) Planificación del Proyecto – se basa en un diálogo continuo entre las partes involucradas en el proyecto, siendo el equipo el que estima el esfuerzo requerido para la implementación de cada funcionalidad; 3) Diseño y Desarrollo de Pruebas – el desarrollo guiado por pruebas es un enfoque ágil, donde para cada funcionalidad que se desea implementar, primero se escriben las pruebas y luego el código necesario para que la prueba sea exitosa.

Una vez que el código cumple el test exitosamente, se amplía y continúa. De este modo, se realiza una integración continua, evitando un proceso más complejo al finalizar el proyecto [1]. El desarrollo guiado por pruebas formalizado en XP se conoce como Test Driven Development (TDD) [3].

1289

2.2 Arquitectura de Software La arquitectura de software conforma la columna vertebral de cualquier sistema y constituye uno de sus principales atributos de calidad [4]. El documento de IEEE Std 1471-2000 [5] define: “La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución”.

En particular, una arquitectura comúnmente usada es la definida en capas. En el caso de una aplicación empresarial puede dividirse en tres capas lógicas bien definidas [6]: 1) la capa de presentación, 2) la capa de negocio y 3) la capa de persistencia. El principio para la separación en capas es que cada una esconde su lógica al resto y solo brinda puntos de acceso a dicha lógica.

En la capa de presentación los objetos trabajan directamente con las interfaces de de negocios, implementando el patrón arquitectónico Model-View-Controller [6]. En este, el modelo (Model) es modificable por las funciones de negocio, siendo estas solicitadas por el usuario, mediante el uso de un conjunto de vistas (View) que solicitan dichas funciones de negocio a través de un controlador (Controller), que es quien recibe las peticiones de las vistas y las procesa.

La capa de negocio está formada por servicios implementados por objetos de negocio. Estos delegan gran parte de su lógica en los modelos del dominio que se intercambian entre todas las capas.

Finalmente, la capa de persistencia facilita el acceso a los datos y su almacenamiento en una base de datos.

2.3 Test Driven Development (TDD) TDD es una técnica de programación que consiste en guiar el diseño de una aplicación, por medio de pruebas unitarias. Esta, cambia el orden tradicionalmente establecido, de manera que en primero se definen las pruebas y a partir de estas se va desarrollando la funcionalidad, repitiendo el ciclo, de acuerdo a lo que se espera que haga el software, por medio de integraciones y refactorizaciones – (una refactorización consiste en realizar modificaciones en el código con el objetivo de mejorar su estructura interna, sin alterar su comportamiento externo [7]) - continúas del desarrollo en los casos en que las pruebas no cumplan con el requerimiento.

Con esta técnica las pruebas constituyen la documentación del software que se está desarrollando.

2.4 Pruebas Unitarias En los últimos años, los test unitarios han ido tomando cada vez más fuerza en el proceso de desarrollo de software y se integraron de una forma altamente productiva [8]. El desarrollo y ejecución de pruebas es una actividad fundamental en los proyectos de desarrollo de software, los cuales permiten mantener código de calidad durante el ciclo de vida del proyecto. Fundamentalmente, las pruebas unitarias

1290

representan una alternativa para encontrar y corregir la mayoría de los errores de codificación [8].

Las pruebas unitarias como primer paso en el proceso de desarrollo son la base de la filosofía TDD, ya que resulta la mejor manera de producir código rápidamente y de calidad, permitiendo conducir el diseño, mediante la codificación de las citadas pruebas, antes de codificar interfaces o implementaciones [9].

3 Arquitectura de Software y Entornos de Trabajo (Framework) Aplicando los conceptos explicados anteriormente, en esta sección presentamos un marco de trabajo que integra distintas tecnologías y frameworks disponibles en el mercado para la implementación de una arquitectura en capas, dirigida por pruebas unitarias en XP. Para la implementación de la capa de presentación se propone el framework JSF [10], basado en el patrón MVC, el cual permite desarrollar rápidamente aplicaciones dinámicas creando páginas (vistas) y manejadores de vista (ManagedBean) de manera sencilla, simplificando el diseño de interfaces de usuarios. Una ventaja de esta elección es su capacidad de extensión para definir nuevos componentes e incorporar librerías existentes, como PrimeFaces[11] entre otras.

Para la implementación de la capa de negocio se propone la utilización de Spring Framework [12]. Un entorno de trabajo de código abierto, utilizado para la simplificación en el desarrollo de Aplicaciones Java Empresariales (JEE). Spring provee de un contenedor de objetos quien se encarga de administrar el ciclo de vida de los mismos, implementa los objetos de dominio como POJOs (Plain Old Java Object - sigla creada por Martin Fowler, Rebecca Parsons y Josh MacKenzie [13]) y representa objetos que son parametrizables a través de sus propiedades o constructores por medio de archivos de configuración u anotaciones. El contenedor maneja dos conceptos muy importantes para administrar las instancias de los objetos (POJOs): la Inversión de Control (IoC: Inversion of Control) y la Inyección de Dependencias (DI: Dependency Injection). El principio de Inversión de Control consiste en que el control de la construcción de los objetos no recae directamente en el desarrollador, sino que es otra clase o conjunto de clases las que se encargan de construir los objetos que se necesitan.[14].

Finalmente, para la capa de persistencia diseñada con el patrón DAO (Data Access Object) [15] se propone la utilización del Framework de código abierto Hibernate [16] como ORM (Mapeo Objeto Relacional). A través de Hibernate se realiza el mapeo del modelo de objetos (POJOS) a la base de datos relacional, mediante archivos declarativos o anotaciones en los objetos POJOS que permiten establecer estas relaciones. Hibernate está diseñado para ser flexible en cuanto al esquema de tablas utilizado, para poder adaptarse a su uso sobre una base de datos ya existente.

El marco de trabajo propuesto se ilustra en la Figura 1.

1291

Figura 1. Arquitectura en Capas

4 Caso de Estudio Una de las herramientas fundamentales para la realización de las pruebas de unidad más difundida en proyectos de software es conocida como JUnit [17]. Siendo una herramienta de prueba de código y el estándar para la técnica de TDD [9].

A continuación se presenta el caso de estudio mediante dos ejemplos, uno que se centra en depositar una suma de dinero en una cuenta bancaria y, el otro, que ejecuta una transferencia de un monto de dinero entre cuentas bancarias, guiados por TDD. Para el primer ejemplo, la prueba de unidad permite probar la funcionalidad para el requerimiento “depositar dinero en la Cuenta”. Una alternativa es la siguiente: public void testDepositarEnCuenta() { // 1: Creamos un contexto de prueba Cuenta cuenta = new Cuenta(); // 2: Ejecutamos el código bajo prueba. cuenta.depositar(100); // 3: Comprobamos el resultado. assertEquals(100, cuenta.getMonto(), 0.001);} Prueba 1: Depositar Dinero en la Cuenta

Luego de la prueba de unidad se avanza en el diseño de la aplicación, por lo que se crea la clase “Cuenta” con su constructor y se implementa el método “depositar”, el cual recibe un valor dado, para ello se modifica la estructura de la clase (el diseño) agregando el atributo “monto” que representa el valor.

El siguiente caso de prueba de unidad, permite comprobar la funcionalidad para el requerimiento “transferencia de dinero entre cuentas”. public void testTransferenciaEntreCuentas() { Cuenta cuenta1 = new Cuenta(100d); Cuenta cuenta2 = new Cuenta(100d); TransferenciaService transfService = new TransferenciaService(); transfService.transferir(cuenta1, cuenta2, monto);} Prueba 2: Transferencia de Dinero entre Cuentas

1292

En este caso de prueba, se identifica un nuevo objeto de negocio, “TransferenciaService” que transfiere monto entre cuentas. Este implementa el método “transferir”. La operación incluye a un nuevo objeto de negocio “CuentaService” que permite la actualización de las cuentas. public void transferir(Cuenta cuenta1, Cuenta cuenta2, Double monto) { cuenta1.extraer(monto); cuenta2.depositar(monto); cuentaService.guardar(cuenta1); cuentaService.guardar(cuenta2);} Implementación 1: Método Transferir de TransferenciaService

Siguiendo con la definición de la arquitectura propuesta, los objetos diseñados “CuentaService” y “TransferenciaService” se implementan en la capa de Negocio.

De acuerdo al método “transferir” surge la necesidad de persistir los objetos “Cuenta”, para ello se define el siguiente caso de prueba: public void testGuardarCuenta() { CuentaService cuentaService = new CuentaService(); Cuenta cuenta = new Cuenta(); cuenta.setMonto(100); cuentaService.guardar(cuenta);} Prueba 3: Guardar los Cambios de Cuenta

De la implementación del método cuentaService.guardar(cuenta), citado, surge la necesidad de diseñar un nuevo objeto, llamado “CuentaDao”, que se encarga de almacenar la “cuenta” en una fuente de datos. Este nuevo objeto se implementa en la capa de persistencia de la arquitectura. public void guardar(Cuenta cuenta) { cuentaDao.guardar(cuenta);} Implementación 2: Método Guardar de CuentaService

De los casos de prueba anteriores se realiza el diseño, de acuerdo al proceso de la técnica TDD, donde los requerimientos se traducen en pruebas. Es necesario, en ciertas oportunidades, que los objetos diseñados se comuniquen con otros para cumplir con su objetivo (función), para lo cual es importante simular la interacción entre ellos, sin llegar a construir el objeto real, de esta manera se logra que las mismas se realicen de forma independiente en cada una de las capas.

Las secciones a continuación explican, en detalle, la herramienta de pruebas para simular los objetos en la capa de negocio y las diferentes estrategias para aplicar pruebas unitarias en cada capa de la arquitectura.

4.1 Capa de Presentación Esta capa contiene los manejadores (“ManagedBean”), que interactúan con otros objetos para colaborar con las acciones llevadas a cabo en la vista. La comunicación que existe con la capa subyacente es a través de la implementación de los objetos

1293

Mocks (falsos) de la capa de Negocio utilizando la herramienta JMock. La Figura 2 muestra la implementación de las pruebas de unidad con JMock en la capa de presentación (ManagedBean).

Capa de Presentación JUnit Test

Controlador JSF

Unit Test

Managed Bean

JMock Servicio Mock

Figura 2. Implementación de las Pruebas en la Capa de Presentación

4.2 Capa de Negocio A fin de realizar los test en la capa de negocios, se plantea la técnica denominada Mock Test. La utilización de esta técnica permite que las pruebas sean unitarias en lugar de que sean pruebas de integración (utiliza todos los componentes reales de los que depende). El desarrollo de pruebas unitarias en esta capa propone aislarla de los objetos de acceso a datos (DAO) y simular la implementación de los mismos con objetos Mocks (falsos).

Existen múltiples herramientas que permiten la creación de Objetos Mocks, como por ejemplo: MockObjects [18], jMock:[19], Mockito [20], EasyMock [21]. El diseño guiado en esta capa se realiza con la herramienta jMock, la guía de pasos para utilizar esta herramienta incluye: 1) declarar un contexto para la prueba, 2) crear los mocks dentro del contexto, 3) crear las expectativas (el comportamiento que se espera de los mocks), 4) ejecutar el código bajo prueba, y 5) comprobar si se han cumplido todas las expectativas.

A continuación, se describe el caso de prueba utilizando la herramienta JMock, siguiendo los pasos arriba descriptos: //0. Crear un contexto.

Mockery context = new Mockery(); //1. Crear los mocks dentro del contexto a partir de las interfaces.

CuentaService cuentaService = context.mock(CuentaService.class); TransferenciaService transfService = context.mock(TransferService.class); public void testTransferirMontoEntreCuentas() { final Cuenta cuenta1 = new Cuenta(100); final Cuenta cuenta2 = new Cuenta(100); //2. Definir las llamadas que esperan los mocks y los valores devueltos. context.checking(new Expectations() { { oneOf(cuentaService).guardar(cuenta1); oneOf(cuentaService).guardar(cuenta2); } }); //3. Crear el objeto de la clase e invocar el método bajo prueba. transfService.transferir(cuenta1,cuenta2,50);

1294

//4. Verificar que el comportamiento indicado en context se haya cumplido context.assertIsSatisfied();} Prueba 4: Descripción del Caso de Prueba en JMock

Seguidamente se asegura la persistencia de la transferencia que se realiza utilizando objetos Mocks en el objeto CuentaService. public void testGuardarCuenta() { final Cuenta cuenta = new Cuenta(); final CuentaDao dao = context.mock(CuentaDao.class); context.checking(new Expectations() {{oneOf(dao).guardar(cuenta);} }); cuentaService.setDao(dao); mockery.assertIsSatisfied();} Prueba 5: Guardar en Cuenta utilizando JMock

La Figura 3 muestra como se implementan las pruebas de unidad con JMock en la Capa de Negocios.

Capa de Negocios JMock

JUnit Test Unit Test

Servicio

DAO Mock

Figura 3. Implementación de Pruebas de Unidad en la Capa de Negocios

4.3 Capa de Persistencia La implementación de la capa lógica de persistencia, DAO (Data Access Object), se guía por pruebas, interactuando con un elemento externo (Base de datos). La utilización de DbUnit, como una extensión de JUnit, permite interactuar con un conjunto de datos de prueba y, también, dejar la base de datos en un estado conocido antes y después de cada ciclo de prueba, esto con el fin de prevenir que datos corruptos queden en la base de datos ocasionando problemas a los ciclos siguientes.

Básicamente DbUnit usa archivos XML para cargar datos en la base de datos (dataset). [9]. La Figura 4 ilustra cómo se implementan las pruebas de unidad con DBUnit en la capa de persistencia (Dao).

Capa de Persistencia DBUnit Test Unit Test

BD DAO

ORM

Figura 4. Implementación de Pruebas de Unidad en la Capa de Persistencia

1295

5 Trabajos Relacionados Este trabajo está basado en tareas de investigación que analizaron los aportes científicos que se encuentran en esta misma línea. En particular, se investigaron trabajos relacionados con la integración de las metodologías ágiles con arquitecturas de software que pudieran brindar un marco de calidad con un enfoque riguroso que resultara en mejoras de los procesos de diseño y de desarrollo de aplicaciones.

Algunos de los trabajos más importantes se discuten a continuación.

Urquiza Yllescas, et al [22] plantea actividades de desarrollo que integran tácticas y estrategias de diseño de la arquitectura de software en metodologías agiles, desde una perspectiva general. Breivold y sus colegas [23] realizan una meta-investigación sobre publicaciones científicas que relacionan el desarrollo ágil y la arquitectura de software, concluyendo en la falta de evidencia científica para muchas afirmaciones sobre agilidad y arquitectura, resaltando la necesidad de estudios empíricos para demostrar ventajas y desventajas de aplicar un método ágil. En [24], se analizan dos casos de estudios adoptando patrones de diseños arquitectónicos en el desarrollo ágil de software para aplicaciones móviles. Resaltando la utilidad de una arquitectura basada en patrones y soluciones probadas. Finalmente, [25] presenta un arquitectura dirigida por modelos (MDA) y el proceso de XP, analizando los argumentos a favor y en contra, proponiendo una nueva arquitectura que supere las limitaciones identificadas.

Comparando el estado del arte con los resultados de este trabajo, nuestra tarea consistió en desarrollar, con el enfoque de TDD, una nueva perspectiva de aplicación ágil relacionándola con una determinada arquitectura e identificando un conjunto de tecnologías para su implementación, aportando, a nuestro criterio, evidencia práctica para su aplicación. De este modo, aportamos contribución empírica para demostrar las ventajas de combinar metodologías agiles con arquitecturas de software, como lo requerían las conclusiones de trabajos relacionados [22].

6 Conclusiones y Trabajos Futuros Este trabajo presentó un marco de trabajo para el desarrollo de aplicaciones basado en una arquitectura en capas, aplicando la técnica de TDD para el diseño y desarrollo de cada una de las capas. La ventaja radica en producir capas de software altamente cohesivas, donde un nuevo requerimiento no impacta en el comportamiento entre cada una de ellas. La técnica aplicada sobre la arquitectura implica un cambio de mentalidad en el desarrollo de software, lo que permite implementar el código necesario para resolver cada caso de prueba concreto. Este enfoque permite reducir los típicos bloques de código que usualmente se agregan “por las dudas”, característica que habitualmente ocurre con metodologías de desarrollo tradicional.

Trabajos a futuro incluyen extender el marco de trabajo aplicando otras técnicas de desarrollo ágil como BDD (Behaviour Driven Development) y ATDD (Acceptance Test Driven Development) que permitirán diferentes posibilidades de integración dentro de nuestro ciclo de pruebas.

1296

Referencias [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25]

Mendes Calo, K, Estevez, E. and Fillottrani, P. “Un Framework para Evaluación de Metodologías Agiles” http://sedici.unlp.edu.ar/handle/10915/21086.

Beck, K. “Extreme Programming Explained. Embrace Change”, (1999).

Wells, D., “Extreme Programming Unit Tests”, disponible en: http://www.extreme programming.org/rules/unittests.html (accedido 01/06/2013).

Clements, P., et al, “Software Architecture in Practice”, Pearson Education, (2003).

IEEE Standards Association, “1471-2000 - IEEE Recommended Practice for Architectural Description for Software-Intensive Systems”, available at: http://standards.ieee.org/findstds/standard/1471-2000.html.

Fowler, M. “Patterns of Enterprise Application Architecture”, Addison-Wesley, (2002).

Fowler, M., “Refactoring: Improving the Design of Existing Code”, Addison-Wesley Longman, Inc., (1999).

Johnson, R. and Hoeller, J., “Expert One-on-One J2EE Development without EJB”, Wiley Publishing, (2004).

Sam-Bodden, B., “Beginning Pojos – From Novice to Professional”, APress, (2006).

Oracle, “Java Server Faces”, disponible en: http://java.sun.com/j2ee/javaserverfaces/ (accedido 02/07/2013).

Prime Faces, “PrimeFaces Ultimate JSF Component Suite”, disponible en: http://primefaces.org (accedido 13/03/2013).

GoPIvotal, Inc., “Spring Framework”, http://www.springframework.org/ (accedido 21/05/2013).

Fowler, M., “Plain Old Java Object (POJO)”, disponible en: http://www.martin fowler.com/bliki/POJO.html (accedido 07/06/2013).

Johnson, R., et al, “Professional Java Development with the Spring Framework”, Wiley Publishing Inc, (2005).

Oracle, “Data Access Object (DAO)”, disponible en: http://java.sun.com/blueprints/ corej2eepatterns/Patterns/DataAccessObject.html (accedido 21/03/2013).

JBoss Community, “Hibernate”, http://www.hibernate.org/ (accedido 22/03/2013).

GitHub, “JUnit”, www.junit.org/ (accedido 06/05/2013).

Mock Blog, “Mock Objects”, http://www.mockobjects.com (accedido 02/06/2013).

GitHub, “JMock”, http://www.jmock.org (accedido 16/06/2013).

“Mockito”, https://code.google.com/p/mockito/ (accedido 02/05/2013).

Freese, T. and Tremblay, H. “Easy Mock”, http://www.easymock.org (accedido 28/05/2013).

Urquiza Yllescas, J.F., et al, “Las Metodologías Agiles y las Arquitecturas de Software”. Coloquio Nacional de Investigación en Ingeniería de Software y Vinculación Academia-Industria 2010, 29-Setiembre al 1-Octubre 2010, León, Guanajuato, Mexico.

Breivold,H.P., Sundmark, D., Wallin, P. and Larsson, S., “What Does Research Say about Agile and Architecture?” , en Proceedings of the 2010 Fifth International Conference on Software Engineering Advances (ICSEA), USA, (2010).

Ihme, T. and Abrahamsson, P., “The Use of Architectural Patterns in the Agile Software Development of Mobile Applications”, en Proceedings of International Conference on Agility. Helsinki, Finland, (2005).

Guha, P., et al, “Incorporating Agile with MDA Case Study: Online Polling System”, International Journal of Software Engineering & Applications (IJSEA), Vol.2, No.4, pp.

83-96, (Oct. 2011).

1297

Herramienta de gestión de trazabilidad de requerimientos en proyectos de software Alfredo Villafañe1, María de los A. Ferraro1, Yanina Medina1, Cristina Greiner1, Gladys Dapozo1, Marcelo Estayno2 1

Departamento de Informática. Facultad de Ciencias Exactas y Naturales y Agrimensura.

Universidad Nacional del Nordeste. Corrientes. Argentina afv0185@hotmail.com, mafferraro@hotmail.com, {yanina, cgreiner, gndapozo}@exa.unne.edu.ar 2 Departamento de Informática. Facultad de Ingeniería. Universidad Nacional de Lomas de Zamora. Buenos Aires, Argentina mestayno@gmail.com

Abstract. La trazabilidad en la Ingeniería de Software es una práctica de control que contribuye a la construcción de un producto en el dominio de la solución lo más fiable y ajustado a las necesidades expresadas por el cliente. Se presenta una herramienta que permite administrar proyectos de software y realizar el seguimiento de los requerimientos en cada una de las fases de desarrollo, destacando la jerarquía que presentan sus relaciones. Además permite obtener documentación del proyecto que cumple con el estándar IEEE 830 e integra la metodología NDT. Como fortalezas de la herramienta se destacan la capacidad de seguir el ciclo de vida de un requerimiento, desde el origen de la especificación hasta la prueba del mismo, la capacidad de descubrir dependencias y conflictos entre requerimientos, y la capacidad de mejorar la comprensión del sistema en su totalidad, características que contribuyen a facilitar el desarrollo y mantenimiento del mismo.

Keywords: Ingeniería de Requerimientos. Gestión de proyectos de software.

Trazabilidad de requerimientos.

1 Introducción La Ingeniería de Requerimientos cumple un papel primordial en el proceso de desarrollo de software, ya que se centra en la definición del comportamiento del sistema. Su objetivo es la definición clara, consistente y compacta de las especificaciones correctas que definen el comportamiento del sistema con el fin de minimizar los problemas que se presentan en el desarrollo de software y que afectan a la calidad del producto final. La captura correcta de los requerimientos contribuye a la calidad del software dado que permite definir con precisión las condiciones que éste debe cumplir.

La trazabilidad en la Ingeniería de Software es una práctica de control que ayuda a obtener el producto en el dominio de la solución lo más exacto y fiable posible a las necesidades expresadas por el cliente en el dominio del problema. La trazabilidad está condicionada por los cambios y las validaciones que los participantes del proyecto hagan al sistema durante el proceso de desarrollo [1]. Según el estándar IEEE 8301998, la trazabilidad es la habilidad para seguir la vida de un requerimiento en ambos

1298

sentidos, hacia sus orígenes o hacia su implementación a través de las especificaciones generadas durante el proceso de desarrollo. Es un factor de calidad.

En el desarrollo de aplicaciones web, el requerimiento está inmerso en un proceso de ingeniería más amplio y detallado. La existencia de una importante estructura de navegación obliga a un desarrollo preciso de este aspecto que garantice que el usuario no se “pierda en el espacio navegacional del sistema” [2]. Estas características particulares requieren atención en la fase de especificación de requerimientos [3].

NDT (Navigational Development Techniques) [4][5] es una técnica para especificar, analizar y diseñar el aspecto de la navegación en aplicaciones web.

Comienza con la captura de requerimientos y estudio del entorno, luego se definen los objetivos del sistema y en base a ellos se definen los requerimientos que el sistema debe cumplir para cubrir los objetivos marcados. Finalmente se desarrolla una matriz de trazabilidad que permite evaluar si todos los objetivos han sido cubiertos en la especificación.

Debido a la heterogeneidad de los usuarios de una aplicación web, es necesario considerar las necesidades de los diferentes actores implicados en la misma para determinar las características que la aplicación debe cumplir para satisfacerlas [6].

Aunque en la actualidad existen propuestas para la especificación de requerimientos web [7][8], la mayoría sólo proponen un conjunto de guías de diseño informales para la derivación manual de modelos conceptuales a partir de los requerimientos [9].

La trazabilidad es clave para conseguir una exitosa gestión de requerimientos, sin embargo no hay un consenso respecto de las prácticas con el que el proceso de trazabilidad debe llevarse a cabo [10].No existen estándares asociados al proceso de trazabilidad que ayuden a determinar qué tipos de artefactos y de enlaces considerar.

Se considera como una medida de la calidad del software y es tenida en cuenta en modelos como CMMI (Capability Maturity Model Integration) [11].

De acuerdo al INTECO (Instituto Nacional de Tecnologías de la Comunicación) en su guía de Gestión de Requisitos, un requerimiento es trazable si se pueden identificar todas las partes del producto existente relacionadas con ese requisito [12].

Todos los requisitos deberían ser trazables para mantener consistencia entre los distintos documentos de un proyecto.

Es importante conocer aspectos de los requisitos tales como:  Su origen (Quién los propuso)  Necesidad (Por qué existe)  Relación con otros requisitos (Dependencias)  Relación con otros elementos (Dependencias) Para aportar a una mayor sistematización en el desarrollo web, este grupo de investigación elaboró una propuesta metodológica para la especificación de requerimientos de aplicaciones web, basada principalmente en una plantilla que considera lo estipulado por el estándar IEEE 830-1998 e incluye las características particulares de los requerimientos web basados en NDT, y elementos trazables para facilitar el rastreo de los requerimientos y el impacto de los cambios [13].

Como continuación del trabajo anterior, se propuso elaborar una aplicación que implemente la propuesta metodológica y permita facilitar la evaluación del impacto de los cambios introducidos, minimizando las incoherencias producidas por el incorrecto control de cambios, y favorecer la comunicación entre los stakeholders en el desarrollo y mantenimiento del software.

1299

2 Metodología En [13] se propuso una plantilla para especificación de requerimientos, cuyos componentes pueden observarse en la figura 1. Presenta características del estándar IEEE 830 combinadas con la metodología NDT, reforzando además la trazabilidad de los componentes críticos, a través del uso de matrices. Cuenta con información concreta y precisa para asegurar calidad desde la trazabilidad, sin perder de vista componentes hoy casi imprescindibles en el desarrollo web, como los provistos por NDT.

Fig. 1: Plantilla reformulada del estándar IEEE 830

Como soporte tecnológico de esta plantilla se diseñó una aplicación cuyo modelo se especifica en la figura 2 mediante el diagrama de casos de uso de la aplicación.

Se consideró la arquitectura cliente servidor, dado que las tecnologías de hardware, software, base de datos y redes contribuyen a arquitecturas de computadoras distribuidas y cooperativas.

La figura 3 muestra el modelo de datos que presenta dos esquemas de información, lo que permite ampliar cada uno de ellos e incluso su reutilización en otros proyectos.

Por un lado, se presenta el esquema correspondiente a Seguridad, para el tratamiento de perfiles, roles, usuarios, y administración de auditorías de información en general.

Este esquema es el que permite poner disponible la capa de aplicación al usuario. Por otro lado se presenta el modelo propio del dominio del problema. Entre algunas de las virtudes que presenta se encuentran, la reutilización de arquitectura en distintos proyectos, múltiples matrices por proyectos y la posibilidad de contar con diversos planes de pruebas ejecutados sobre un mismo requerimiento.

1300

Analistas

System

Controlar Acciones Agregar Perfil Administrar E. Análisis

Administrar Proyectos/SRS

Generar Backup Eliminar Perfil

<<extend>>

<<extend>>

<<extend>>

Administrar Casos Usos

Editar Perfil Administrar Modulos

<<extend>>

<<extend>> Adminisrtrar req.

Generar reporte

<<extend>>

Asignar Perfil <<extend>>

<<extend>> <<extend>>

Administrar E.Prueba

Agregar Usuario

Administrar Usuarios

Administrar Caso de Prueba

<<extend>> Editar Usuario

Administrador <<extend>>

Tester

Eliminar Usuario

Ver Trazabilidad

<<extend>> Administrar Perfiles

<<extend>>

Asociar modulo

<<extend>> <<extend>>

Programador

Agregar Perfil administrar Arquitectura

Administrar E. Implementación

Eliminar Perfil <<extend>> Editar Perfil

Admnistrar E. Diseño

<<extend>>

Admnistrar Codigo Fuente

Diseñador

Fig. 2: Diagrama de Casos de uso de la aplicación

Fig. 3: Modelo de datos

1301

2.1 Descripción de la herramienta Pensada para gestionar trazabilidad, la herramienta permite incorporar información correspondiente a solicitudes de usuarios desde la primera etapa de un proyecto, como así también realizar la gestión de cambios y configuraciones de manera ordenada contribuyendo a la liberación de productos con un alto grado de control sobre las diferentes versiones de software, siguiendo las recomendación de buenas prácticas en Administración de Servicios de TI (ITIL Versión3).

Contempla todas las etapas del ciclo de desarrollo y contribuye a la comunicación entre el equipo de desarrollo y clientes, desde la posibilidad de contar con una visualización explícita de las solicitudes realizadas y posteriormente materializadas como funcionalidad en un producto.

Permite establecer las relaciones entre los componentes del software, como por ejemplo: cuál es el origen de una especificación de análisis, diagramas construidos en cualquier herramienta CASE o similar, casos de pruebas, objetos de código fuente (compilado construidos, etc.), de manera que se pueda seguir la vida de un requerimiento en ambas direcciones, hacia delante y hacia atrás, es decir, desde su origen y especificación hasta su implementación.

La aplicación se desarrolló utilizando herramientas open source, tales como, JavaScript, jQuery,PHP,WAMP, CSS, Aptana Studio 3 (herramienta profesional para desarrollo de código abierto para la web), HTML 5, Canvas (nuevo componente de HTML 5, que permite dibujar por medio de un API), Firebug y MySQL Workbench.

La figura 4 muestra la interfaz inicial de la aplicación y las distintas opciones del menú principal.

Fig. 4: Interfaz inicial

El menú de la figura 5 muestra las distintas opciones que ofrece la aplicación.

1302

1

1. Configuración: Permite configurar los módulos que conforman las distintas opciones del menú.

2

2. Soporte: Permite administrar usuarios, perfiles, carpetas de copias y recuperación de información.

3

4 5 6 7 8

3. Proyectos - SRS-Elementos IEEE 8301998/NDT: Comprende las opciones que presentan diferentes aspectos de la información generada en el proyecto: 3.1. SRS-Elementos IEEE 830-1998/NDT: Se completan los distintos ítems de la plantilla IEEE 830-1998/NDT. 3.2. Tabla de revisión histórica: Permite obtener información de auditoría sobre las interacciones que han realizado los distintos usuarios.

3.3. Matriz Solicitud de usuario – Funciones del Producto: Permite conocer el origen de las funcionalidades del proyecto.

Fig. 5: Opciones de la aplicación

Dentro de la opción 3, SRS-Elementos IEEE 830-1998/NDT, al incorporar un proyecto, se ingresan todos los ítems establecidos en la plantilla IEEE reformulada para su adecuación a desarrollo de aplicaciones web. La figura 6 muestra la interfaz prevista para esta opción.

Fig. 6: SRS-Elementos IEEE 830-1998/NDT

Una vez seleccionado el proyecto, se completan los datos requeridos (ver figura 7).

1303

Fig. 7: SRS-Elementos IEEE 830-1998/NDT

A continuaci贸n, se describen los otros componentes del men煤 principal:

1304

4. Etapa de análisis: permite la incorporación de diagramas y descripciones sobre documentación de análisis, provenientes de distintas fuentes y formatos. Las opciones ofrecidas se observan en la figura 8, cada una genera datos necesarios para la trazabilidad.

Fig. 8: Etapa de análisis

La figura 9 muestra las solicitudes iniciadas y la opción de agregar una solicitud.

Fig. 9: Administración de requerimientos en la etapa de análisis

También es posible ver los distintos casos de uso, que incluyen una breve descripción, facilitando su comprensión (figura 10).

Fig. 10: Casos de uso en la etapa de análisis

1305

5. Etapa de diseño: permite la incorporación de documentación relacionada a la arquitectura del proyecto.

6. Etapa de implementación: permite importar objetos construidos para soportar la funcionalidad, por ejemplo, asociar un componente compilado o incorporar el código.

7. Etapa de testing: corresponde a la vinculación de todo elemento construido para la verificación y/o validación de un componente de software, en cada una de sus etapas.

8. Ver trazas: presenta la información de las relaciones generadas en la vida de un requerimiento.

Por ejemplo, para el requerimiento Agregar Alumno, los mecanismos de trazabilidad previstos permiten visualizar toda la información relacionada (figura 11).

Fig. 11. Información relacionada al requerimiento Agregar Alumno

1306

3 Conclusiones Se construyó una aplicación web que permite administrar proyectos de software y realizar el seguimiento de los requerimientos en cada una de las fases del desarrollo, brindando información sobre el origen de cada cambio que ha sufrido una versión del software.

Como fortalezas de la herramienta se destacan la capacidad de seguir el ciclo de vida de un requerimiento, desde el origen de la especificación hasta la prueba del mismo, lo cual permite estimar el impacto de un cambio de requerimiento, la capacidad de descubrir dependencias y conflictos entre requerimientos, y la capacidad de mejorar la comprensión del sistema en su totalidad, características que contribuyen a facilitar el desarrollo y mantenimiento del mismo.

Como trabajo futuro se plantea validar la herramienta en ambientes de producción reales, tales como áreas de Sistemas de las organizaciones o empresas de software, para obtener una retroalimentación que permita mejorar la solución que se propone.

Referencias 1. Anaya R., Tabares M. S., Arango F.; “Una revisión de modelos y semánticas para la trazabilidad de requerimientos”; Revista EIA, ISSN 1794-1237 Nº 6, p. 33-42. 2006 2. Olsina, L. “Metodología cualitativa para la evaluación y comparación de la calidad de sitios web”. Ph. Tesis.Facultad de Ciencias Exactas. Universidad de La Pampa. Argentina. 1999.

3. Escalona, M.J. “Metodología para el desarrollo de sistemas de información global: análisis comparativo y propuesta”. Universidad de Sevilla. 2002.

4. Escalona, M.J., Mejías, M., Torres, J. “Methodologies to develop web information systems and comparative analysis”. UPGRADE.TVol. III, No. 3, Junio 2002.

5. Escalona, M.J., Torres, J., Mejías, M. “Requirements capture workflow in Global Information Systems”. Proceedings of OOIS.Springer-Verlag. Montpellier, France. 2002.

6. Escalona, M. and Koch, N., Requirements engineering for Web Applications: a comparative study. Journal of Web Engineering, 2004. 2: p. 193-212.

7. Escalona, M. J. and Koch, N. “Metamodeling the Requirements of Web Systems”. In Proceedings of the Web Information Systems and Technologies (Setubal, Portugal, 2006).

8. Molina, F., Pardillo, J. and Toval, A., “Modelling web-based systems requirements using WRM”. Web Information Systems Engineering–WISE 2008 Workshops, 2008. p. 122-131.

9. Aguilar, J. A., Garrigos, I., Mazon, J.-N. and Trujillo, J. “Web Engineering Approaches For Requirement Analysis - A Systematic Literature Review”. 6th Web Information Systems and Technologies (WEBIST). 2010. Valencia, Spain.

10. Ramesh B. “Factors influencing requirements traceability practice”. Communication of the ACM. Vol. 41, No. 12, pp. 37-44, December 1998.

11. Nicolás, J. and Toval, A., “On the generation of requirements specifications from software engineering models: A systematic literature review”. Information and Software Technologies, 2009. 51(9): p. 1291-1307 12. INTECO, “Guía práctica de gestión de requisitos”, [página web en línea]. Disponible en Internet http://www.inteco.es/file/NRDmviQoTbI_jZcyjTYRlw. Consulta: 19/07/2013.

13. Ferraro, M.; Medina, Y.; Dapozo, G.; Estayno, M. “Especificación y trazabilidad de requerimientos en el desarrollo de aplicaciones web”. II Jornadas de Investigación en Ingeniería del NEA y Países Limítrofes. Facultad Regional Resistencia. Universidad Tecnológica Nacional. ISBN: 978–950–42–0142–7. Resistencia. Chaco. 2012.

1307

Declarado de InterĂŠs Municipal por el Honorable Concejo Deliberante del Partido de General Pueyrredon