WIEI by CACIC2013

II WORKSHOP DE INNOVACIÓN EN EDUCACIÓN EN INFORMÁTICA - WIEI -

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)

II Workshop de Innovación en Educación en Informática - WIEI -

Trabajo

Autores

5672

Experiencia de utilización de Herramientas Colaborativas para la enseñanza y el aprendizaje de la Programación de Computadoras

Edith Lovos (UNRN), Alejandro Gonzalez (UNLP), Rodolfo Bertone (UNLP)

5840

Enseñanza de técnicas de elicitación de requerimientos

Alejandro Oliveros (UADE), Javier Zuñiga (UADE), Sergio Corbo (UADE), Patricia Forradellas (UADE), Sandra Martínez (UADE)

5709

Generando Entornos de Investigación y Desarrollo utilizando Redes Inalámbricas de Sensores (WSN)

Eduardo Omar Sosa (UNaM), Diego Alberto Godoy (UGD), Edgardo Belloni (UGD)

5732

El desarrollo de la comprensión lectora en las carreras de Informática

Sonia V. Rueda (UNS)

5737

Extensión del Lenguaje y Modelo Simplesem con Soporte para Paralelismo

Lucas L. Diez de Medina (UNC), Gustavo Wolfmann (UNC), Orlando Micolini (UNC)

5740

Conformando repositorios de datos de la comunidad educativa en la Universidad Nacional de La Plata Un caso de estudio

Javier Diaz (UNLP), Maria Alejandra Osorio (UNLP), Ana Paola Amadeo (UNLP)

5748

Expiriences with educational robotic

Anibal Lopes Guedes (uffs), Fernanda Lopes Guedes (IF-SUL)

5687

Desafíos y herramientas para la enseñanza temprana de Concurrencia y Paralelismo

Laura De Giusti (UNLP), Fabiana Leibovich (UNLP), Mariano Sanchez (UNLP), Franco Chichizola (UNLP), Marcelo Naiouf (UNLP), Armando E. De Giusti (UNLP)

II Workshop de Innovación en Educación en Informática - WIEI -

Trabajo

Autores

5838

Una propuesta para la incorporación de Cloud Computing a la currícula de Grado

Nelson R. Rodriguez (UNSJ), María Antonia Murazzo (UNSJ), Daniela Villafañe (UNSJ), Francisca Adriana Valenzuela (UNSJ), Adriana Martin (UNSJ), Susana Beatriz Chavez (UNSJ)

5782

Propuesta de una metodología para una rápida enseñanza de circuitos lógicos y de su integración en una UCP en carreras de Informática

Mario Carlos Ginzburg (UAI)

5857

FUN: una herramienta didáctica para la derivación de programas funcionales

Araceli Acosta (UNRC), Renato Cherini (UNC), Alejandro Gadea (UNC), Emmanuel Gunther (UNC), Leticia Losano (UNC), Miguel Pagano (UNC)

5883

Metodología innovadora para el Estudio y Programación de Microprocesadores en Arquitectura de Computadoras

Jorge R. Osio (UNAJ), Daniel Alonso (UNAJ), Eduardo Kunysz (UNAJ), Martín Morales (UNAJ)

5889

Usando NDT como soporte a la enseñanza de programación web

Yanina Medina (UNNE), Gabriel Osmar Pedrozo Petrazzini (UNNE), Cristina Greiner (UNNE), Gladys N. Dapozo (UNNE)

Experiencia de utilización de Herramientas Colaborativas para la enseñanza y el aprendizaje de la Programación de Computadoras Lovos, Edith1, Alejandro Gonzalez2, Rodolfo Bertone2 1 Universidad

Nacional de Río Negro, Sede Atlántica {elovos}@unrn.edu.ar 2 Instituto de Investigación en Informática III-LIDI. Facultad de Informática, Universidad Nacional de La Plata alejandro.gonzalez@presi.unlp.edu.ar, pbertone@lidi.info.unlp.edu.ar

Abstract. En este trabajo se presentan algunos resultados y conclusiones preliminares sobre una experiencia de trabajo colaborativo apoyado en recursos tecnológicos provistos y/o compatibles con el EVEA Moodle. Las experiencias se aplicaron a un curso introductorio de enseñanza y aprendizaje de programación en la Lic. en Sistemas de la Universidad Nacional de Río Negro (UNRN) - Sede Atlántica. Se exponen algunas referencias teóricas que sostiene la propuesta y se realiza una descripción del contexto de aplicación. Finalmente se presentan los resultados de la implementación y conclusiones obtenidas. Keywords: trabajo colaborativo, enseñanza, programación,

1 Enseñar y Aprender en colectivo Maldonado Pérez [1] expresa la importancia de reconocer el carácter social que implica el enseñar y aprender en estos tiempos, donde el esquema convencional que posiciona al docente en el rol de enseñante y al alumno en su rol de aprendiz en forma exclusiva, ya no tiene lugar. Para la autora, el aprendizaje es un proceso social, construido a través de la interacción no solo del docente con los alumnos, sino entre alumnos y teniendo en cuenta el contexto y el significado que cada uno le asigna a lo que aprende. Esta forma de aprendizaje, responde a los postulados del psicólogo Jean Piaget, quien sostenía que el aprendizaje consiste en la generación de estructuras cognoscitivas que se crean a través de la modificación de los reflejos iniciales del recién nacido y que se van enriqueciendo a través de la interacción del individuo con el medio. A través de estas estructuras, el individuo adquiere información, usando los procesos de asimilación y acomodamiento de la misma. De esta forma, el proceso de aprendizaje no se basa en la memorización de la información, sino en asimilar o incorporar información a esquemas que poseen una información previa. El enfoque de Piaget se ve complementado, desde la perspectiva teórica de Vygotsky [2], que hacía énfasis en la interacción social como factor clave para el aprendizaje y la transmisión de cultura [1]. Según Johnson et al; [3], Vygotsky sostenía el carácter social del conocimiento y su construcción a partir de los esfuerzos cooperativos por

1517

aprender, entender y resolver problemas. Un concepto clave, definido por Vygostky [2], es el de la zona de desarrollo próximo, entendiéndola como aquella zona situada entre lo que un estudiante puede hacer solo y lo que puede lograr si trabaja guiado por un instructor o en colaboración con otros pares más avanzados. Así, la enseñanza y como consecuencia el aprendizaje, sólo tiene lugar en la zona en la que el sujeto puede desarrollar una actividad en colaboración con otro [2]. En este sentido, Johnson [3], sostiene que a menos que los alumnos trabajen de manera cooperativa, no crecerán intelectualmente; por lo tanto, debe reducirse al mínimo el tiempo que los alumnos pasan trabajando solos en las actividades académicas. Maldonado Pérez [1], basándose en la teoría de Vygostky afirma que los procesos que desarrolla un grupo en interacción serán internalizados por cada uno de sus miembros, formando de esta manera parte de su propio aparato cognoscitivo. Por otra parte, destaca el espacio fundamental que ocupan los lenguajes y los procesos de comunicación en esta interacción. En cuanto al docente, la misma autora [1] señala que es su responsabilidad alentar, promover y crear el espacio adecuado que permita la construcción del conocimiento. En este sentido, se organizará la enseñanza y el uso de estrategias y metodologías apropiadas, que permitan la creación de nuevos espacios de interacción humana y tecnológica.

2 Ambientes Colaborativos & Enseñanza y Aprendizaje de la Programación En las carreras vinculadas a la Informática, la enseñanza de la programación es una base fundamental y uno de los primeros cursos que deben tomar los alumnos ingresantes [4]. La enseñanza y aprendizaje de programación es una actividad intelectual compleja y dificultosa, tanto para los alumnos como para quienes llevan adelante la enseñanza; más aún cuando su impacto es muy importante en la mayoría de las asignaturas sucesivas y en el campo profesional del futuro egresado [5,6]. En el ámbito educativo, las actividades de aprendizaje colaborativas buscan desarrollar en los alumnos un conjunto de habilidades que se relacionan en forma directa con el objetivo que persigue la educación moderna, la formación en competencias que le permiten al alumno integrarse en una esta nueva sociedad mediada por tecnologías digitales, donde el docente desde su lugar debe ser, dinamizador, orientador y asesor de todo el proceso de enseñanza y aprendizaje [7]. En este sentido, Estévez [8], sostiene que los ambientes colaborativos pueden ofrecer un importante soporte a los alumnos durante las actividades aprendizaje de la programación. Y agrega que la resolución de problemas a través de la colaboración promueve la reflexión, un mecanismo que estimula el proceso de aprendizaje. Para el desarrollo de una actividad grupal los alumnos necesitan comunicarse, discutir y emitir opiniones a otros miembros del grupo, alentando de esta forma una actitud de reflexión que conduce al aprendizaje. En cuanto a las características de una herramienta que esté orientada tanto para el aprendizaje como para el desarrollo colaborativo del software, algunos autores [9] señalan que deben estar incluidas: las actividades comunes, el entorno compartido y el espacio/tiempo. Por actividades comunes se entiende a aquellas tareas comunes que los participantes del grupo llevan a cabo; el entorno compartido brinda la posibilidad

1518

de tener informado a cada miembro del proyecto sobre el estado de éste, lo que cada miembro está trabajando, etc.; y el espacio/tiempo soporta que la interacción del grupo de trabajo se produzca en el mismo lugar y momento. En cuanto a la interacción es posible encontrar dos tipos: síncrona o asíncrona, que a su vez puede ser distribuida o centralizada. A continuación se describen las herramientas digitales que se utilizan en la experiencia que relata el artículo.

2.1 Virtual Programming Lab (VPL) VPL es un producto de software de código abierto creado por el Departamento de Informática y Sistemas, de la Universidad de Las Palmas de Gran Canaria; que permite la gestión de prácticas de programación sobre el entorno virtual de enseñanza-aprendizaje (EVEA) Moodle[18], incorporando el ambiente de desarrollo de software al aula virtual de las materias donde se utiliza. Su arquitectura está compuesta de un módulo Moodle, un applet editor de código fuente y un demonio Linux que permite la ejecución remota de programas de forma segura. VPL tiene como propósitos el ahorro de tiempo y mejorar la gestión general de este tipo de actividades, tanto en los cursos de programación que se dictan en forma online como usando B-Learning, además de permitir la realización de las prácticas utilizando solo un navegador. La intención de la herramienta es facilitar el seguimiento y la orientación personalizada y continua del proceso de aprendizaje del alumno, contribuyendo de esta forma a tratar las dificultades a las que se enfrenta éste en la realización de las actividades de programación [11]. A nivel profesional, las herramientas comerciales que se utilizan para el desarrollo del software, presentan una amplia cantidad de opciones y de información que los alumnos que recién se inician en la práctica de la programación, no pueden comprender tan fácilmente porque aún no tienen los conceptos necesarios para manipularlas [10]. Así, VPL busca proveer a los alumnos novatos de un entorno de desarrollo que sea simple. Sus características más destacadas son: la posibilidad de editar el código fuente y ejecutar las prácticas de forma interactiva desde el navegador, ejecutar pruebas que revisen las prácticas y analizar la similitud entre prácticas para el control del plagio para algunos lenguajes de programación soportados [11]. La versión 2.0 de VPL incorpora características que permiten el trabajo en grupo. Así, cada grupo dispone de un repositorio compartido de entregas, donde cualquier integrante puede agregar una nueva versión del programa que están realizando y el resto del grupo recibirá el resultado de la evaluación.

2.2 Herramientas de Moodle: Foros y Wiki Moodle dispone de una serie de herramientas que permite la colaboración dentro del aula virtual entre ellas los foros y wiki. A través de los foros, Moodle da lugar al planteo de debates y discusiones, posibilitando además la comunicación asincrónica. Los foros pueden estructurarse de diferentes maneras, y cada mensaje puede ser

1519

evaluado por los participantes. Existen diferentes formas de visualizar los mensajes y los mismos permiten la inclusión de imágenes y adjuntar archivos. Cuando los participantes de un curso, se suscriben a un foro, recibirán copias de cada mensaje en su bandeja de correo. El participante con rol de profesor puede forzar la suscripción a todos los participantes. En Moodle hay dos categorías de foros: Foro general (Se encuentra en la sección 0 del curso) y Foro de aprendizaje (Son foros de alguna sección específica del curso). Una wiki es un espacio web colaborativo que puede ser editado por varios participantes, es decir todos pueden crear, modificar o eliminar contenido de forma interactiva; permitiendo así la escritura colaborativa [13] en [12] Moodle dispone de la herramienta wiki, la cual se puede configurar al momento de crearla de un determinado tipo. Este tipo determina el ámbito de la misma y quien puede escribir y editar los cambios. Los tres tipos de wiki son: estudiante, grupo y profesor. La wiki puede funcionar en modo: sin grupos, grupos separados o grupos visibles al igual que los foros [14].

3 Actividades Prácticas Colaborativas Se describe la implementación de la propuesta de enseñanza y de aprendizaje destinada a los alumnos ingresantes a la Licenciatura en Sistemas de la UNRN que tomen el curso de Programación I. Programación I, es una materia perteneciente al área Algoritmos y Lenguajes de Programación; que se dicta en forma presencial en el primer cuatrimestre del primer año con un total de 96 horas. Tiene como objetivos generales que los alumnos puedan analizar problemas resolubles con computadora, poniendo énfasis en la modelización, la abstracción de funciones y en la descomposición funcional de los mismos, a partir de un paradigma procedural/ imperativo. Se realiza una introducción de las nociones de estructuras de datos, tipos de datos y abstracción de datos. En cuanto a los alumnos, en su mayoría son ingresantes a la universidad, egresados recientemente del nivel medio, cuyas edades oscilan entre los 17 y 21 años, y que toman contacto por primera vez con la actividad de programación. Son varios los alumnos que llegan al curso con netbooks. Esto hace suponer que tienen cierto manejo de recursos tecnológicos como navegadores de internet y redes sociales tipo facebook entre otros. Por otra parte, es común verlos con sus teléfonos celulares navegando, escuchando música o mirando videos, aún dentro del espacio presencial de las clases. El curso está dividido en clases teóricas y prácticas. En las primeras se desarrollan los conceptos teóricos previstos en el plan de estudio (resolución de problemas, estructuras de control, modularización, estructuras de datos) haciendo uso de ejemplos prácticos que permitan la aplicación de los conceptos analizados. Respecto a las clases prácticas, las mismas tienen como objetivo la aplicación de los conceptos trabajados en las clases de teoría, en la resolución de problemas computacionales, a través del diseño algoritmos. En un paso siguiente estas soluciones serán implementadas en un lenguaje de programación de alto nivel tipo Pascal. El énfasis

1520

de la asignatura está puesto en la parte práctica, ya que para desarrollar la habilidad de resolver problemas usando algoritmos es fundamental el entrenamiento. Con este objetivo se diseñan actividades prácticas que enfrentan a los alumnos con situaciones problemáticas en las que tienen que decidir sobre la naturaleza del problema, seleccionar una representación que ayude a resolverlo (modelo) y, monitorear sus propios pensamientos (metacognición) y estrategias de solución [15]. El programa consta de seis unidades didácticas, cada una con su correspondiente trabajo práctico y tres Actividades Prácticas Entregables (APE) integradoras, las cuales deben ser entregadas y evaluadas para poder acceder al examen parcial. Las fechas de publicación de la APE, están establecidas en el cronograma de actividades de la materia. Las APE consisten en la resolución colaborativa en equipos de trabajo, de problemas de mediana complejidad, cuya solución es un programa computacional que se implementará en el lenguaje de programación elegido por la cátedra. En el caso de Programación I, se utiliza el lenguaje Pascal. La consigna de trabajo que se proponen a través de la APE, incluye la definición del problema, formas de entrega, consistente en un cronograma de actividades, fechas de previstas para cada etapa del proceso de resolución y recursos que se proponen para su desarrollo, información sobre pruebas, es decir se definen o se proporcionan los datos con los que serán puestos a prueba los programas y consideraciones especiales. El desarrollo de las APE se propone que se realice combinando la forma de trabajo colaborativo y herramientas TIC, promoviendo de esta forma, la participación de los alumnos y el desarrollo de competencias transversales tales como el razonamiento crítico, la capacidad de análisis, el trabajo en equipo, la autorregulación y la comunicación. Teniendo en cuenta que los alumnos de Programación I son jóvenes que tienen cierto manejo de la tecnología, la intención de las APE es también que ellos las apropien como un recurso útil para construir y enriquecer su aprendizaje. Haciendo uso de las funcionalidades provistas por el entorno Moodle (Foro, Wiki, mensajería) y del laboratorio virtual de programación (VPL); se posibilita el desarrollo colaborativo del análisis y diseño de la solución y de la implementación del programa computacional que resuelve el problema propuesto en la APE. Las tres herramientas TIC se configuran de manera tal que cada grupo disponga de una instancia de las misma, de manera que los participantes solo puedan ver y editar las asociadas a su equipo. Las consignas de las APE se presentan a través del aula virtual (archivo en formato .pdf), a la vez que se habilitan los espacios de Foro y Wiki y se indica el tutor asignado al grupo. El tutor es responsable de hacer el seguimiento del grupo y puede ser un docente de la teoría o de la práctica de la materia. A continuación se describen las cinco etapas involucradas en el desarrollo de las APE; a saber: Debate inicial: En la clase presencial siguiente a la presentación de la consigna en el aula virtual, se reserva una hora de la misma para que los grupos junto a los tutores asignados puedan debatir acerca del problema. Así, se busca atender dudas y

1521

consultas sobre la consigna. Entre la fecha que se habilita la consigna de la APE sobre la plataforma y la fecha prevista para el debate, los estudiantes disponen de al menos 3 días para realizar una lectura crítica del problema en forma personal y grupal de manera de llevar a la clase de debate inicial dudas y consultas sobre la consigna propuesta. Análisis y Diseño: en esta etapa se modela la solución al problema, el diseño modular y las estructuras de datos. Se propone utilizar una wiki y un foro ambas herramientas provistas por el entorno Moodle. Implementación: en esta fase se propone continuar usando la wiki y el foro. Y se suma el laboratorio virtual VPL, con la opción de trabajo en grupo. A través de VPL, es posible que los grupos editen, compilen y ejecuten sus programas. Cada grupo tiene un repositorio compartido de entregas, y cualquier integrante del grupo puede entregar una nueva versión y todos los miembros de un grupo recibirán la misma devolución. Presentación y defensa: en esta fase se propone la elaboración de una presentación que resume la solución al problema. La misma pueden subirla a la wiki de cada grupo y su exposición se desarrollará en una clase presencial de manera de poder compartir y debatir con el resto de los grupos las producciones realizadas; propiciando así la capacidad de comunicación. Evaluación: La evaluación de las APE se desarrolla en tres partes: una evaluación del programa computacional a través del entorno virtual usando VPL, otra evaluación en forma presencial a modo de exposición y defensa de la solución propuesta y una tercera evaluación en forma de encuesta que permite que los alumnos evalúen el proceso de desarrollo de la APE, evaluando su propio desempeño, el del grupo y el del tutor asignado. De esta forma se propone evaluar la experiencia tomando en cuenta no sólo el resultado final de las APE - el programa computacional que resuelve el problema-, sino también el proceso de aprendizaje a nivel grupal e individual que dan lugar al mismo. Este proceso esta soportado a través del aula virtual de la materia y de las herramientas wiki, foros y VPL entre otras. Las evaluaciones de las APE servirán de información para los docentes y de orientación para el alumno. La evaluación que hacen los alumnos de sus compañeros de grupos, se apoya en la idea de un grupo de investigadores del Departamento de Informática y Sistemas Universidad de Las Palmas de Gran Canaria, España que entienden este tipo de evaluación como un complemento valioso que permite integrar al alumno en el proceso de evaluación del aprendizaje. De esta esta forma los alumnos pueden evaluar las competencias desarrolladas por sus pares durante el desarrollo de la actividad educativa. Los investigadores señalan que este tipo de evaluación requiere del alumno una mayor responsabilidad y el desarrollo de habilidades que le permitan valorar el trabajo de sus compañeros de equipo [16]. Respecto a la organización de los grupos de trabajo, en función de la complejidad que presentan las APE y teniendo en cuenta que desde los inicios de la carrera, en el año 2009, los alumnos inscriptos en el curso no supera los 50 en promedio, se propone que los equipos de trabajo no superen los 4 alumnos. En cuanto a su conformación, en esta experiencia se propuso para la APE1 que los alumnos decidan como

1522

agruparse, luego en las siguientes APE los equipos fueron re-armados por el equipo docente de acuerdo al seguimiento realizado.

4 Resultados El programa de la materia contempla el desarrollo de tres APE durante la cursada. Esta experiencia se inició con un grupo de 40 alumnos. De los cuales, para la APE1 se dividieron en 13 grupos de los cual completaron todas las etapas de la actividad 12 grupos. Para la APE2 se formaron 14 grupos y completaron la actividad 6 grupos. Para la APE3 se formaron 11 grupos y completaron la actividad 4 grupos. Respecto al desgranamiento que se observa, está asociado en parte con el hecho que muchos alumnos a medida que cursan las materias del primer año de la carrera, están también cursando las asignaturas introductorias de “Razonamiento y resolución de problemas” (RRP) e “Introducción a la lectura y escritura académica” (ILEA) que la UNRN ha dispuesto como un recorrido previo de ingreso universitario. De esta forma quienes no aprobaron estas materias antes del inicio del primer cuatrimestre, pueden cursarlas durante el mismo y/o rendirlas en forma libre en las fechas establecidas por el calendario académico. Cómo se indicó anteriormente, al finalizar la fecha de entrega de cada APE los alumnos respondieron a una encuesta anónima, que permitió evaluar su propio desempeño, el de su grupo y el del tutor asignado. A continuación se exponen algunos resultados de las mismas. En cuanto a la autoevaluación los gráficos 1, 2 y 3, muestran el análisis de datos realizados hasta el momento. El gráfico 1 permite observar que los alumnos indicaron que su nivel de participación aumentó en cada APE. Solo para la primer APE, un poco más del 10% manifestó una participación nula. Cuando se les consultó a los alumnos acerca de porque no habían participado, algunos indicaron que por falta de coordinación y de organización. Otros manifestaron que no podían encontrarle utilidad al uso de la wiki o el foro, que preferían reunirse en forma personal.

APE2

APE3

APE1

20 0 Casi Siempre Nunca Siempre Alguna Vez

Gráfico 1 – Autoevaluación: nivel de participación en las e-actividades

Porcentaje

APE1

APE2

APE3

20 0 Casi Siempre Nunca Siempre Alguna Vez

Gráfico 2 – Autoevaluación: dominio de los temas tratados

1523

El gráfico 2, presenta el resultado de la autoevaluación que hicieron los estudiantes respecto a si tenían dominio (conocimiento y manejo) de la información que se discutía en cada APE. Se puede observar que en cada APE se produjo un incremento del mismo. En este sentido vale destacar que cada APE era integradora de los conceptos vistos en las unidades involucradas más los analizados en la APE anterior. Así por ejemplo para la APE2 el 53% manifiesta haber tenido siempre dominio de los temas tratados. El gráfico 3, muestra las percepciones de los alumnos respecto a si el desarrollo de las APE les permitió una mejor comprensión de los conceptos involucrados. Se observa que más del 50% consideran que las APE contribuyeron en forma normal en las dos primeras actividades y en la última se observa que la contribución superó el 70%. Esta APE resultó una experiencia de investigación para los grupos, ya que la resolución del problema planteado requirió de conceptos no analizados en clase ( Pilas y Colas). Luego de finalizada la entrega de la APE 3 y tomado el examen parcial de la materia, se consultó a los alumnos acerca de si esta propuesta de trabajo les había permitido prepararse mejor para rendir el examen, aquí casi el 80% de los alumnos respondió positivamente, aún entre quienes indicaron no haber aprobado el examen.

APE2

APE3

Porcentaje

100 50 0 Poco Nada

Mucho Normal

Gráfico 3 – Autoevaluación: comprensión de los conceptos

APE1

Porcentaje

APE1

APE2

APE3

60 40 20 0 Si, con algunos Si, con todos No

Gráfico 4 - Evaluación del grupo de trabajo

En cuanto a las evaluaciones que los alumnos realizaron sobre el grupo, en el gráfico 4 se observa que consultados acerca de si volverían trabajar con ese equipo, para las tres APE más del 40% respondió afirmativamente. Sólo en aquellos casos donde se observó a través del aula virtual y/o de la encuesta, que sus miembros no deseaban seguir trabajando juntos y/o que los alumnos lo manifestaron en forma personal equipo al docente, se hicieron cambios para la siguiente APE. Ante la pregunta: ¿qué fue lo mejor y lo peor de trabajar en este grupo?, en general las respuestas coinciden y señalan la falta de dominio sobre los temas tratados. Esta situación ponía a los alumnos en distintos niveles, la despreocupación y la negativa de algunos integrantes a utilizar las herramientas TIC propuestas. En cuanto a lo mejor resaltaron el debate, la puesta en común de las posibles soluciones y el respeto hacia las opiniones de los demás. En la etapa de presentación y defensa de las APE, resulta importante destacar cómo evolucionaron las presentaciones digitales que realizaron los grupos y como los mismos interactuaron no solo con los docentes sino con los demás grupos, en la defensa oral de las actividades.

1524

5 Conclusiones Se presentó una propuesta de enseñanza de programación de computadoras basada en actividades prácticas colaborativas usando herramientas compatibles con Moodle. Para la primera implementación se puede observar que: ● Resultó difícil que los alumnos adoptarán el uso de foros y wiki, como un recurso para el desarrollo de las actividades didácticas específicas del área de programación, no así el uso del laboratorio virtual VPL. Para la mayoría de los alumnos ingresantes esta forma de trabajo y algunas de las herramientas TIC que la soportan, representan una experiencia novedosa. Así acordamos con otras investigaciones [17] que resaltan la necesidad de un tiempo de maduración de la misma por parte de los alumnos. Donde el mismo, debe estar en todo momento acompañado por la participación activa del tutor. En este sentido se propone a futuro el desarrollo de un curso pre-ingreso que trabaje sobre el uso de las mismas aplicadas al área específica de estudio. ● Hubo una evolución en el desarrollo de las presentaciones digitales y la calidad de las exposiciones a medida que avanzaban en la cursada. ● Desde los inicios de la Lic. en Sistemas en la UNRN Sede Atlántica en el año 2009, se puede observar que en las materias de programación de primer año el desgranamiento es muy alto de esta forma los alumnos que logran llegar al final del curso son muy pocos en relación a la cantidad de inscriptos. En este sentido la propuesta presentada, puede re-pensarse de manera que pueda convertirse en una herramienta que permita sostener a los alumnos a lo largo de la cursada. El desarrollo de actividades colaborativas en programación favorece el futuro desarrollo profesional de los estudiantes, se les presenta situaciones similares a las que van a tener que desarrollar. Para la próxima implementación se trabajará en el ajuste de la propuesta teniendo en cuenta las observaciones de los estudiantes y docentes de la cátedra. Como trabajo futuro se analizarán los tipos de problemas a resolver y su adecuación para el desarrollo de actividades colaborativas de programación.

Referencias 1. Maldonado Pérez, Marisel. El trabajo colaborativo en el aula universitaria. Revista Laurus, vol.13 nro. 23. Universidad Pedagógica Experimental Libertador. Caracas Venezuela. ISSN 1315-883X. (2007) 2. Vygotski, Lev. S. El Desarrollo de los procesos psicológicos superior. Barcelona . Grupo Editorial Grijalbo . (1978) 3. Johnson, David W., Johnson, Frank P. Learning Together and Alone: Cooperative, Competitive, and Individualistic Learning. Needham Heights, MA: Allyn & Bacon. (1999) 4. Matthíasdóttir, Á. How to teach programming languages to novice students? Lecturing or not?, Proceedings of the International Conference on Computer Systems and Technologies, June 15-16, University of Veliko Tarnovo, Bulgaria (2006). 5. Costelloe, E. Teaching Programming. The State of the Art. Department of Computing, Institute of Technology Tallaght, Dublin 24. CRITE Technical Report, 2004a. (2001)

1525

https://www.scss.tcd.ie/disciplines/information_systems/crite/crite_web/publications/source s/programmingv1.pdf Abril 2012 6. Lahtinen E, Ala-Mutka K, et al. A Study of the Difficulties of Novice Programmers. 10Th annual SIGCSE conference on Innovation an technology in computer science education ItiCSE '05Linder, et al, (2001) “Facilitating Active Learning With Inexpensive Mobile Robots”. Journal of Computing in Small Colleges,16, 4. (2005) http://delivery.acm.org/10.1145/380000/378656/p21-linder.pdf? key1=378656&key2=7062133701&coll=guide&dl=acm&cfid=15363060&cftoken=163643 68 . Junio 2012 7. Filippi, J. L, Lafuente, J., Bertone, R. .Diseño de un Ambiente de Aprendizaje Colaborativo. En actas del V Congreso de Tecnología en Educación y Educación en Tecnología. Universidad Nacional de la Patagonia Austral. Calafate. (2010) . 8. Esteves M., Morgado L., Martins P., Fonseca B. “The use of Collaborative Virtual Environments to provide student’s contextualisation in programming”. En: Proceedigns of m-ICTE 2006. (2006) 9. González de Rivera Fuentes, M., Paredes Velasco, M. Aprendizaje con programación Colaborativa. Número 2008-02. Serie de Informes Técnicos DLSI1-URJC. ISSN 19888074. Departamento de Lenguajes y Sistemas Informáticos I Universidad Rey Juan Carlos (2008). 10.Pérez Pérez, J. R., Paule Ruiz, J.M., Del Puerto M., Cueva Lovelle J. M. Capítulo 3. Sistemas orientados a la mejora de la calidad del software. En congreso IV International Conference on Multimedia and Information & Communication Technologies in Education (m-ICTE2006). (2006). 11.Rodriıguez del Pino, J.C., Royo Rubio E., Hernandez Figueroa. VPL: Laboratorio virtual de programación para Moodle. En Actas de las XVI Jornadas de Enseñanza Universitaria de Informática, Jenui 2010, pags. 429–435, Santiago de Compostela, Julio 2010. http://www.di.uniovi.es/~juanrp/investigacion/tesis/2%20Tesis_SICODE_Estado_del_arte.p df Junio 2012 12.Salinas Silvia. Software para trabajo colaborativo y bibliotecas. E-LIS. E-prints in Library and Information Science; 8 2008 http://eprints.rclis.org/14721/1/Software_para_Trabajo_Colaborativo_y_Bibliotecas1.pdf 13.Neri, C. Fernández Salazar, D. Telarañas de Conocimiento. Educando en tiempos de la web 2.0. ISBN 978-987-1426-01-0. (2008). 14.Moodle 1.9. WIKI. Unitat de Suport Tecnicopedagògic - CAMPUS EXTENS Universitat de les Illes Balears. Edifici Aulari. (Illes Balears) (2010). http://campusextens.uib.es/_doc/bonespract/proyec-manuales/castellano/wiki.pdf 15.García, Juan Carlos. Solución de Problemas mediante la programación. Portal Eduteka . http://www.eduteka.org/modulos.php?catx=9&idSubX=298 Junio 2013 16.Diaz Roca, M. Rodriguez del Pino, j.C., Hernández Figuero, Z., Vicente, C. M. El Gestor de Coevaluacion Orientado Grupos. Una herramienta de apoyo a la participación del alumno en el proceso de evaluación. 7ª Conferencia Ibérica de Sistemas y Tecnologías de Información. CISTI 2012, Madrid. (2012) http://www2.dis.ulpgc.es/~mdiaz/GestorCoevaluacionOrientadoGrupos. 17.Lillo Zuñiga, Felix Revista de Psicología Universidad Viña del Mar (2013) Vol. 2, Nº 4 109 – 142. ISSN http://sitios.uvm.cl/revistapsicologia/revistadetalle.php/4/25/contenido/aprendizaje-colaborativo-en-la-formacion-universitaria-depregrado 18.Moodle. https://moodle.org/

1526

Enseñanza de técnicas de elicitación de requerimientos Alejandro Oliveros, Javier Zuñiga, Sergio Corbo, Patricia Forradellas, Sandra Martínez {aoliveros,sjzuniga,samartinez}@uade.edu.ar, sergio.corbo@gmail.com,psforrade@hotmail.com INTEC – UADE, Lima 775, CABA, Argentina

Abstract. La enseñanza de las técnicas de elicitación de requerimientos posee especiales dificultades por la imposibilidad de generar un contexto equiparable al mundo real. La observación constituye una poderosa herramienta de aprendizaje que se propone utilizar para enseñar a estudiantes de un primer curso de Ingeniería de Requerimientos las técnicas de entrevistas. En esta comunicación se informa un experimento desarrollado para evaluar la calidad y organización de las preguntas en una entrevista con usuario para obtención de requerimientos. Keywords: Elicitación de requerimientos, entrevistas, observación, enseñanza

Introducción

El presente artículo continua con la experiencia reportada en [1] y [2] en los que se encuentran desarrollados los fundamentos del presente experimentos 1.1

Las entrevistas como técnicas de elicitación

En [2] se encuentran los detalles y fundamentos acerca de las entrevistas. El resultado del proceso de elicitación de requerimientos es el conocimiento necesario para producir el modelo de requerimientos de un dominio de problema dado [3]. La más sencilla forma de interacción es la “open-ended interview” [4]. Estás técnicas requieren habilidades especiales del analista [3], [4]. Este tipo de entrevistas proviene de prácticas previas de la Ingeniería de Software y Sistemas de Información.[5] Las entrevistas no estructuradas son ventajosas en cuanto a efectividad y completitud del output [6]. Con el objetivo de mejorar la enseñanza de las técnicas de entrevistas se desarrollaron varias experiencias en un curso de grado. La pregunta que guió esta

1527

Alejandro Oliveros, Javier Zuñiga, Sergio Corbo, Patricia Forradellas, Sandra Martínez

experiencia fue: ¿resulta de utilidad la observación como técnica para la enseñanza de entrevistas? 1.2

El problema de enseñar técnicas de elicitación de requerimientos

Existen varios problemas para la enseñanza en las aulas de las técnicas de entrevista[2]: 1. dificultad de ejecutar una práctica real: 2. subestimación por parte de personas de formación tecnológica de las técnicas “blandas” que requiere la elicitación de requerimientos. La multiplicidad de abordajes que existen para enfrentar este problema pone de manifiesto que está lejos de su solución [2]. Nuestro abordaje intenta utilizar la observación como técnica de aprendizaje través del uso de una “cámara Gesell” (Gesell dome en inglés), más detalles en [2] Este trabajo está organizado de la siguiente forma. En el punto 2 se resumen algunos puntos clave del enfoque de aprendizaje propuesto, en el punto 3 se reproduce el contexto de la experiencia. El punto 4 describe la experiencia con detalle. En el punto 5 se evalúa comparativamente los resultados obtenidos en los dos casos de estudio. Por último se plantean algunas conclusiones y trabajos futuros.

La observación como método de aprendizaje

Sumariamente, el enfoque propuesto se basa en que el aprendizaje se propone conseguir un cambio permanente en la conducta del individuo atribuible a una experiencia [7]. El aprendizaje concluye en un cambio en la conducta [8] “En términos generales, por aprendizaje cognoscitivo se entiende el conocimiento, el saber, el anticipar o utilizar en otra forma los procesos mentales superiores ricos en información. El aprendizaje cognoscitivo va más allá del condicionamiento básico, pues abarca la memoria, el pensamiento, la resolución de problemas y el lenguaje.” [7] Las investigaciones de Albert Bandura en el campo de las teorías de la personalidad contribuyeron a la constitución del campo del “Social Learning” como un desarrollo de las teorías cognitivas del aprendizaje [9] y han conformado una de las principales corrientes de las teorías del aprendizaje [10], [11]. El aprendizaje por observación se produce al exhibir comportamientos derivados de la exposición a conductas modeladas. Este aprendizaje consta de cuatro pasos [11], [12]: atención, retención, reproducción y motivación.

El contexto de la experiencia desarrollada

La materia Ingeniería de Requerimientos integra los planes de estudio de dos carreras, Ingeniería en Informática y Licenciatura en Informática, ambas de cinco años de duración. El curso se dicta en el primer cuatrimestre del segundo año. En el primer año de estudios hay un curso de Análisis Estructurado, aunque no es una exigencia

1528

Enseñanza de elicitación de requerimientos

haberlo aprobado para cursar Ingeniería de Requerimientos. El libro de texto es el de Wiegers [13] y además se utiliza material de Procees Impact [14]. Más detalles sobre la materia se encuentran en [2]

4 4.1

Descripción de la experiencia Ideas básicas del proyecto

La investigación se desarrolló siguiendo los estándares de la investigación experimental, ´para ello se elaboró un documento con el detalle de las actividades a realizar en el proyecto y una descripción de los productos a obtener y el registro de los pasos datos. El esquema básico del proyecto es que equipos de 3 a 4 alumnos observan a otro equipo de similar tamaño que realiza una entrevista a un usuario en una Sala Gesell. La entrevista al usuario se hizo en la Sala Gesell para que puedan observar su desarrollo los restantes equipos. Observaron dos entrevistas con usuarios pertenecientes a diferentes dominios de aplicación La entrevista forma parte del trabajo final de la materia, vale decir: los alumnos utilizan los requerimientos obtenidos como insumo para elaborar la especificación de un sistema. Con este enfoque se trató de conseguir mayor motivación de los alumnos por la actividad. La experiencia se hizo en el curso del turno mañana del primer cuatrimestre de 2013. Se conformaron equipos de 4 a 5 alumnos y un grupo hizo la entrevista personal dentro de la Sala Gesell. Las entrevistas dentro de la sala se filmaron para que los investigadores (toda la cátedra de la asignatura) puedan evaluarlas y así cotejar sus evaluaciones con las de los alumnos. A fin de homogeneizar el desempeño de los alumnos, todas las consignas se trasmitieron sobre la base de documentos escritos especialmente para este proyecto indicándose a los alumnos que debían ser seguidos por todos los equipos. Los alumnos ejecutaron las entrevistas y evaluaciones sobre la base de ese material elaborado especialmente sobre el tema entrevistas. Previstamente a ejecutar cada una de las entrevistas los alumnos establecieron el alcance de los requerimientos a identificar (alcance del sistema) El contexto general del trabajo de los equipos entrevistadores fue que en la entrevista debería obtenerse conocimiento a volcar en una lista de requerimientos elaborado según las pautas de la cátedra. Para ello los estudiantes recibieron indicaciones acerca de registrar objetivos, necesidades, expectativas y requerimientos que surjan de las entrevistas. Con este objetivo los estudiantes deberían formular las preguntas adecuadas. En el presente artículo se informa la evolución de la calidad de las preguntas y el comportamiento de los alumnos durante la entrevista en sí misma.

1529

Alejandro Oliveros, Javier Zuñiga, Sergio Corbo, Patricia Forradellas, Sandra Martínez

4.2

Descripción del primer caso: sistema de becas

La experiencia se desarrolló en los meses de marzo y junio de 2013 (desde el 27 de marzo). En lo que sigue se describe siguiendo la secuencia de las clases en las que se desarrollaron las actividades Clase de 27 de Marzo. Los docentes del curso presentan a los alumnos la iniciativa de realizar un trabajo de investigación acerca de la enseñanza de requerimientos asociad con el desarrollo del curso. Se explica la dinámica de organización del proyecto y el papel de los grupos. La iniciativa tiene buena aceptación por parte de los alumnos, se organizan 9 equipos de trabajo cada uno de ellos compuesto por 4 a 5 alumnos. Clase 3 de Abril. Se desarrollan actividades indicando la importancia de comprender el dominio en el proceso de elicitación. Hacen un ejercicio en clase de describir un dominio. Se presenta el LEL (Léxico Extendido del Lenguaje) como una herramienta de comprensión del vocabulario del dominio, se trasmiten algunas sugerencias sobre cómo aplicarlos en las actividades prácticas relacionadas con proyecto. El LEL se presenta como una herramienta para ayudar a entender el dominio en el contexto del proceso de elicitación. Se introduce el marco a la primera actividad práctica del proyecto en la clase siguiente (asistencia a la clase de un usuario del Dpto. de Becas de UADE, quien dará las primeras visiones acerca del alcance de una problemática de negocios). Clase 10 de Abril. Se desarrolla una clase teórica sobre Técnicas de Entrevistas de acuerdo con el contenido del material disponible por los alumnos, se hace foco en aquellas técnicas que podrán ser de utilidad en la primera entrevista a un usuario del Dpto. de Becas de UADE. Se hace hincapié en la importancia de poder elaborar y fijar una primera versión del alcance de la necesidad que planteara el usuario, como entregable de la primera entrevista. El sistema en consideración es el Sistema de Legajos del Depto. de Becas de la Universidad. Se realiza la 1er entrevista con un usuario del Dpto. de Becas de UADE, quien asiste invitada a la clase, en la misma todos los alumnos formulan preguntas cuyos principales objetivos eran: 1. comprender el dominio en el que se desarrolla la necesidad 2. lograr una primera versión del alcance de la necesidad planteada La duración de la entrevista en el curso se desarrolla en aproximadamente 1 hora y comienza con la presentación del entrevistado a los fines de la experiencia corresponde mencionar que se trata de la Jefe del Depto. Becas, que posee formación en el área de informática y que posee una amplia experiencia en el dominio. Al finalizar la clase se les trasmite la consigna de elaborar por equipos las preguntas que deberían hacerse al usuario en la siguiente entrevista (por un grupo y en la Sala Gesell). La observación directa por parte de los docentes presentes en el curso (tres) concluyó en varias observaciones. • Si bien el foco era el alcance y límites del sistema, destinaron muchas preguntas a detalles. Ejemplo: “¿existen cupos para las becas?, ¿cuántos?, ¿de qué tipo? (que parece reflejar más un interés personal que profesional).

1530

Enseñanza de elicitación de requerimientos

•

Los docentes debieron intervenir en dos oportunidades para orientar hacia el foco. Ejemplo: “¿Por qué motivos se puede consultar un legajo archivado?”. • Preguntas con múltiples interrogantes. Ejemplo: ¿Cómo está conformado el legajo de becas?, ¿Se lleva un historial del mismo?, ¿Durante cuánto tiempo se archiva?” • En algunos casos se observó un comportamiento agresivo hacia el entrevistado. Ejemplo: interrogando sobre afirmaciones en apariencia contradictorias entre si Clase del 17 de Abril. Los alumnos entregan a los docentes las preguntas elaboradas por los equipos, se separan todas las preguntas y se agrupan por tema. En forma conjunta se seleccionan las preguntas que se utilizaran en la Sala Gesell para la entrevista. Los docentes indicaron que las preguntas sobre el proceso global las hicieran el principio, el resto lo ordenaron los entrevistadores. Sobre la base de la calidad de las preguntas presentadas, los docentes seleccionan a los entrevistadores. Luego se dirigen a la Sala Gesell y el grupo de alumnos seleccionados realiza las entrevistas siguiendo la selección de preguntas hecha previamente, la entrevista es filmada. Los restantes alumnos observan fuera de la sala. La observación de los docentes (tres) de la entrevista concluyó: • Las preguntas son formuladas correctamente. • Varias preguntas fueron muy genéricas, evitaron hacer preguntas más puntuales y específicas (puede ser una reacción a acotaciones hechas en clase). • Cuando el usuario repreguntaba, formulaban las preguntas en los mismos términos que la primera vez, no permitiendo aclara mucho. 4.3

Descripción del segundo caso: UADE Arts

Esta caso está descripto con detalle en [2]. Clase del 19 de junio. Los estudiantes se reúnen en la sede del UADE Art. La reunión tiene el mismo formato que la del 10 de Abril con la responsable de becas. El usuario es muy ordenado y preciso en sus respuestas. La conclusión de la observación directa por parte de los docentes es que las preguntas carecen de las deficiencias que se observaron en el caso anterior. Clase del 26 de junio. Igual formato que la clase del 17 de abril. Para hacer de entrevistadores se seleccionan alumnos distintos de la primera vez. A los entrevistadores, se les sugiere que previamente a la entrevista hagan una reunión de coordinación de la dinámica de la reunión. Sobre esta entrevista los docentes concluyeron: • Realizan bien las preguntas. • Cuando el usuario no comprende la pregunta la reformulan de otra manera. • Se observa una buena coordinación entre los entrevistadores. • El flujo de la entrevista es adecuado

1531

Alejandro Oliveros, Javier Zuñiga, Sergio Corbo, Patricia Forradellas, Sandra Martínez

Evaluaciones

Disponemos de varias evaluaciones de las entrevistas en la Sala Gesell. La primera por los tres docentes del curso de los que fuimos reflejando a lo largo de la descripción de la experiencia y que fue formulada inmediatamente de producida la entrevista. Esas conclusiones se pueden resumir en: erradicación de las preguntas genéricas, flujo adecuado, correcta reformulación de las preguntas. La segunda fuente de evaluaciones es la entrevista sostenida por al primer autor del presente (que no es docente del curso) con dos de los tres docentes. De ella se concluyó que en la segunda experiencia: • mejoró la forma de preguntar (no hay múltiples interrogantes) • lenguaje más cercano al usuario • la coordinación entre los entrevistadores hubo que inducirla por los docentes • valorizaron la secuencia que fue sugerida por los docentes: “primero entender el proceso general y luego los detalles” • mejora de las repreguntas En comparación con otras experiencias [2] la discusión en conjunto y depuración de las preguntas ayudo mucho a la mejora de la calidad de las preguntas. La tercera fuente de evaluaciones consistió en que dos docentes de la cátedra, que no pertenecían al curso del experimento, observaron los videos de las entrevistas en la Sala Gesell y realizaron una comparación entre ambas. El análisis realizado se resume en el Cuadro 1. Cuadro 1. Comparativo de entrevistas Entrevista Becas

Entrevista UADE Art

Al inicio de la entrevista se revisa vagamente el alcance del sistema.

Al inicio de la entrevista se revisa y confirma el alcance y límites del sistema

Entrevistadores con escaso conocimiento del dominio

Entrevistadores con un buen conocimiento del dominio

Preguntas no muy claras

Preguntas claras y concretas

Preguntas generales del proceso

Preguntas generales y de detalle

Secuencia de preguntas desordenada

Secuencia de lo general a lo particular

Preguntas con tecnicismos

En general sin tecnicismos

Sin referencias a la primera entrevista

Referencia a la primer entrevista

Preguntas con supuestos (incluso incorrectos)

Las preguntas no incluyen supuestos

No se valida que forma parte del sistema y que no

Preguntas que validan que se va a incluir en el sistema

En el final no se valida lo relevado

En todo momento se valida lo relevado

Adecuado uso del tiempo

Los tres entrevistadores utilizan el “Usted”.

No todos utilizan el “Usted”

Presionados por las preguntas escritas

1532

Enseñanza de elicitación de requerimientos

El Cuadro 1 resulta auto explicativo, pero cabe mencionar con un elemento a revisar es el atarse exclusivamente al libreto de las preguntas escritas. Al final de las entrevistas se consultó a los alumnos y esta cuarta fuente consideró a la experiencia como muy real, incluso por aquellos alumnos que ya trabajan en informática, además le resultó muy motivador utilizar un recurso como la Sala Gesell.

Conclusiones y trabajos futuros

Sobre la base de un esquema conceptual de aprendizaje presentado en [2], se continuó el desarrollo de la experiencia de aprendizaje de técnicas de entrevistas. Estas tienen varias componentes, uno de ellas la forman sus preguntas y la dinámica de su desarrollo. Sobre la base de una experiencia realizada en un curso de Ingeniería de Requerimientos de 2do año de la carrera de Ingeniería Informática se investigó la forma de enseñar a desarrollar entrevistas. La efectividad de ese enfoque de aprendizaje estará dada por la capacidad los alumnos para ejecutar una entrevista adecuada. En este trabajo formulamos la idea de adecuación de la entrevista en términos de evaluaciones que se pueden hacer sobre su ejecución y comparando la calidad de las preguntas formuladas. La conclusión general, más allá de las que fueron detallándose en el texto, es que visualizar las entrevistas realizadas por sus compañeros resulta motivador para los alumnos y un elemento disparador de mejoras. La evolución entre la primera y la segunda experiencia así lo demuestra. Pero el criterio de calidad definitivo de una entrevista son sus resultados, en nuestro caso esos resultados son los requerimientos. El experimento realizado incluye disponer de los requerimientos obtenidos y justamente esa evaluación de los requerimientos obtenidos en términos de completitud de los términos tratados con relación al sistema en construcción.

Referencias

[1]

A. Oliveros, J. Zuñiga, R. Wehbe, S. Rojo, y S. Martinez, «Enseñanza de elicitación de requerimientos», presented at the WICC 2012 - XIV Workshop de Investigadores en Ciencias de la Computación, Posadas - Misiones, 2012. A. Oliveros, J. Zuñiga, R. Wehbe, S. Rojo, y F. Sardi, «Enseñanza de elicitación de requerimientos», presented at the Congreso Argentino de Ciencias de la Computación (CACIC), Bahía Blanca, 2012. P. Loucopoulos y V. Karakostas, Systems Requirements Engineering. McGraw-Hill, 1995. J. A. Goguen y C. Linde, «Techniques for requirements elicitation», in Requirements Engineering, 1993., Proceedings of IEEE International Symposium on, San Diego, CA , USA, 1993, pp. 152 - 154.

[2]

[3] [4]

1533

[5]

[6]

[7] [8]

[9] [10] [11] [12] [13] [14]

Alejandro Oliveros, Javier Zuñiga, Sergio Corbo, Patricia Forradellas, Sandra Martínez

B. Nuseibeh y S. Easterbrook, «Requirements Engineering: A Roadmap», in ICSE ’00 Proceedings of the Conference on The Future of Software Engineering, Limerick, Ireland, 2000, pp. 35 - 46. O. Dieste y N. Juristo, «Systematic Review and Aggregation of Empirical Studies on Elicitation Techniques», IEEE Transactions on Software Engineering, vol. 37, n.o 2, pp. 283-304, abr. 2011. D. Con, Psicología. México: International Thomson Editores, 2005. F. Rojas Velásquez, «Enfoque sobre el aprendizaje humano», Departamento de Ciencia y Tecnología del Comportamiento. Universidad Simón Bolívar, jun. 2001. A. Bandura, Social Learning theory. Englewood Cliffs, N.J.: Prentice Hall, 1977. F. Ashworth, G. Brennan, K. Egan, R. Hamilton, y O. Sáenz, «Learning Theories and Higher Education», Level3, vol. 2, jun. 2004. D. H. Schunk, Teorías del aprendizaje, 2da edición. México: Prentice-Hall, 1997. C. G. Boeree, «Personality Theories», Boeree Home Page. [Online]. Available: http://webspace.ship.edu/cgboer/perscontents.html. [Accessed: 26-dic-2011]. K. Wiegers, Software Requirements, 2nd ed. Microsoft Press, 2003. «Process Impact». [Online]. Available: http://www.processimpact.com/.

1534

Generando Entornos de Investigación y Desarrollo utilizando Redes Inalámbricas de Sensores (WSN) Eduardo O. Sosa1, Diego A. Godoy2, Edgardo A. Belloni2 1

Facultad de Ciencias Exactas, Químicas y Naturales - Universidad Nacional de Misiones. Félix de Azara 1552. N3300LQH. Posadas, Argentina. 2 Departamento de Ingeniería y Ciencias de la Producción - Universidad Gastón Dachary, Av. López y Planes 6519, N3301BOL. Posadas, Argentina

eososa@unam.edu.ar,{diegodoy,ebelloni}@ugd.edu.ar

Resumen. Las Redes Inalámbricas de Sensores (WSN) jugarán un papel preponderante tanto en las actividades académicas y como en el desarrollo en nuestro país. En este artículo se reportan actividades desarrolladas en dos universidades argentinas, utilizando a la tecnología WSN como disparador de actividades de investigación, desarrollo. La aplicación de ésta tecnología de última generación se enmarcan en el dominio de “Internet de las Cosas” y “Ciudades Inteligentes”. Las actividades teórico-prácticas desarrolladas introdujeron a un número cada vez mayor de interesados en la experimentación, hacia el desarrollo de soluciones frente a situaciones de la vida cotidiana, buscando soluciones utilizando WSN. Se presentan resultados de proyectos de la vida real, por lo que amerita considerar la implementación del estudio de las WSN en las curriculas de las carreras con contenido de las Tecnologías de la Información y Comunicación. Palabras clave: Sensores inalámbricos; Redes ad hoc; Internet del Futuro; Internet de las Cosas.

Introducción y Propósitos

Las redes ad-hoc son sistemas sumamente complejos. En ellos conviven y participan muchos conceptos, protocolos, tecnologías, algoritmos, y elementos que deben ineludiblemente trabajar conjuntamente. La aplicación de las redes móviles ad hoc (MANET) y las WSN es sumamente diversa, yendo desde pequeñas redes estáticas limitadas en su existencia por la necesidad de disponibilidad de energía, a redes a gran escala con gran dinámica y mucha movilidad. Si bien los nodos sensores han sido utilizados desde hace décadas, el desarrollo de la tecnología ha sido exponencial a partir de 1998, con el proyecto SmartDust. Las redes de sensores inalámbricos, proveen una tecnología que permite operar de forma autónoma a cada uno de los nodos, sin depender de infraestructura alguna. Son parte de aquellos objetos cooperantes, que residiendo en el dominio de la computación ubicua; permite desarrollar una gran variedad de aplicaciones prácticas. La

1535

computación ubicua es un modelo de interacción de personas y equipos, en los cuales el procesamiento ha sido asimilado invariablemente a los elementos y actividades del día a día. Cada uno de los objetos con los cuales interactuamos, tienden a ser integrados con sensores de alguna naturaleza. Son redes auto-configurables de pequeños nodos desplegados en cantidades suficientes de tal manera de interaccionar con el mundo. Es posible mencionar casos de éxito como el monitoreo de hábitats naturales de aves, control de las migración de animales, vulcanología, contralor de parámetros en viñedos, calidad de vida de los internos en residencias geriátricas, eventos deportivos multitudinarios, y diversos otros dominios y entornos. La solución implementada en cada caso ha sido más competitiva que las existentes, ya que se puede implementar como red fija o móvil. Computación ubicua es un modelo posterior de la interacción personacomputadora de escritorio, y es un término ya utilizado por Mark Weiser en los años 1990’s [1]. Hoy las WSN forman la columna vertebral de una nueva Internet, principalmente ubicua, como parte indivisible de "Internet de las cosas (IoT)" [2], dominio en el cual cada “cosa” existente en el mundo físico también puede convertirse en un elemento que está conectado a Internet. Las “cosas” se pueden caracterizar como pequeños dispositivos capaces de diferentes tareas “inteligentemente”. Si a la brecha digital se la define como la diferencia entre los que tienen acceso regular y eficaz de las tecnologías digitales y los que no, entonces la brecha científica se puede definir como la brecha entre quienes tienen acceso a los datos científicos y los que no. Estamos persuadidos que el uso de WSN en los países en vías de desarrollo puede ayudar a llenar este vacío en el estado del arte y de la técnica. Abogamos por la utilización de WSN para el desarrollo en el dominio de las ICT4D (ICT for Development) ya que se convierte, aplicándose a diversos escenarios [3], en una herramienta válida para reducir la brecha científica y tecnológica existente. La implementación de las WSN aporta nuevas fortalezas al diseño curricular de carreras en Informática, agregando valor actualizado para los propósitos educativos en aquellas instituciones académicas que avancen sobre el tema. En nuestro país existen hoy 2,9 investigadores, tecnólogos y becarios por cada 1.000 personas de la población económicamente activa. Se espera aumentar a 4,6 en 2020, según el escenario más pesimista [4], logrando duplicar la cantidad de científicos en 7 años. Uno de los ejes principales del plan es la “focalización” en sectores que se consideran estratégicos, la agroindustria, el ambiente y el desarrollo sustentable, el desarrollo social, las energías, la industria, y la salud. En todos esos ambientes es esperable que las WSN jueguen un rol sumamente importante. La capacidad de realizar mediciones directas y determinar las estrategias de reconocimiento y caracterizar patrones; conjuntamente con una acertada explotación de los recursos computacionales disponibles en la tecnología; representan retos ingenieriles muy interesantes de abordar en el ámbito científico académico. Para validar la tecnología se hace necesario un amplio portafolio de aplicaciones como una prueba del concepto. Para ello las redes desplegadas deben adecuarse al medio bajo estudio e investigación, debiendo considerarse no solo el impacto científico potencial, sino también el impacto en la sociedad. Las bondades y potenciales aplicaciones de las

1536

WSN, coadyuvará en la adhesión de mayor cantidad de voluntades, siendo fundamentales aquellas que se encuentren relacionadas con actividades de desarrollo de hardware.

Génesis y Contexto

La Facultad de Ciencias Exactas, Químicas y Naturales (FCEQyN) de la Universidad de Misiones (UNaM), el Centro de Investigación en Tecnologías de la Información y Comunicaciones (CITIC) de la Universidad Gastón Dachary (UGD), y el Parque Tecnológico Misiones (PTMi) han trabajado activamente en la difusión y promoción de actividades centradas en tecnologías de bajo costo y alto impacto en la industri y la sociedad, siendo uno de los objetivos la formación de personas que puedan convertirse en propagadores de los conocimientos y las capacitaciones recibidas. Por convenios con la Universidad de Lübeck (Alemania), el LINTI –Laboratorio de Investigación de Nuevas Tecnologías Informáticas de la Universidad Nacional de La Plata y la FCEQyN se ha desarrollado el Proyecto “Hacia una Red Global de Sensores Interconectados. Un ensayo experimental Argentino-Alemán”, aprobado en el marco del Programa de Cooperación Científico-Tecnológico entre el Ministerio de Ciencia, Tecnología e Innovación Productiva de la República Argentina (MinCyT) y el Bundesministerium für Bildung und Forschung (BMBF) de Alemania. La meta principal del proyecto ha sido obtener resultados valederos tanto desde el punto de vista práctico como desde lo teórico y académico, promoviendo cursos y actividades a nivel de grado y postgrado, los que no son tan comunes en las actuales curriculas de las universidades argentinas. El carácter multidisciplinario de la actividad involucrada en el proyecto ha logrado aportes significativos al estudio y modelización de tráfico en las redes ad-hoc, como así también lo concerniente a encaminamiento en las citadas redes. En éste marco se realizaron capacitaciones sobre WSN en la UNLP y la UNaM impartidas por científicos y académicos alemanes. De la actividad participaron 10 estudiantes de postgrado de la UNLP, otorgando 3 créditos válidos para Maestrías y Doctorados. En la UNaM tomaron dicho curso 12 personas de las carreras de Informática e Ingeniería Electrónica de la UNaM. Como corolario de la actividad, se ha defendido una tesis de Doctorado en Ciencias Informáticas en la UNLP [5] en el año 2011. De la sinergia establecida entre grupos de investigación en la UNaM y la UGD, se han implementado charlas orientadas a docentes y alumnos de la carrera Ingeniería en Informática denominándoselas “Internet de las Cosas e Inteligencia Ambiental”. En ese contexto se concretaron los talleres “Programación de WSN” y “Hacia la Internet del Futuro, Programando WSNs” y “Redes de Sensores Inalámbricos e Internet del Futuro”. Estas actividades incluyeron importante carga horaria en actividades prácticas, que ha sido posible abordar por disponer un Laboratorio desplegado con una WSN de 15 nodos.

1537

Talleres Desarrollados

Los objetivos, dinámica, contenidos, práctica, tecnologías utilizadas, y algunas consideraciones relativas a la evaluación de los talleres se indican a continuación. 3.1

Objetivos

Objetivo General. 

Concientizar sobre el potencial de la tecnología WSN, insistiendo en el hecho consisten en dispositivos de bajo costo; resultando apropiada fundamentalmente para aplicaciones en el medio ambiente.

Objetivos Particulares.        

3.2

Proporcionar comprensión general sobre ésta nueva tecnología y el nuevo paradigma de las redes data-céntricas. Apreciar de la naturaleza interdisciplinaria de WSN revelando sus potenciales aplicaciones para la región. Inculcar habilidades prácticas a través de la auto-motivación, la formación práctica no rutinaria, y de actividades de diseño en equipo, utilizando pensamiento crítico, trabajo en equipo y habilidades de comunicación. Desarrollar una estructura sostenible generando la infraestructura necesaria para formar a una futura generación de capacitadores, capaces de interactuar a nivel local, para así coadyuvar al desarrollo tecnológico. Fomentar con un enfoque regional, el desarrollo de un sentido de comunidad entre los participantes, despertando el interés por la aplicación de la tecnología WSN como una herramienta válida para resolver problemas locales. Promover la conformación de un grupo de trabajo sobre WSN en la UNaM y la UGD integrado por investigadores, profesionales y estudiantes. Elaborar documentos técnicos sobre dispositivos sensores Dictar charlas y conferencias de sociabilización en distintos estamentos de nuestra comunidad. Dinámica y Contenidos Tratados

Los talleres comprendían sesiones de desarrollo de contenidos teóricos, como prácticas llevadas a cabo sobre los nodos disponibles. Los participantes han estado en contacto desde el primer momento con los nodos sensores, lo cual potenció aún más el rendimiento de las actividades. El curso se basado en la aplicación de algoritmos de complejidad creciente, los que se esclarecían a medida que se incorporaban nuevos conceptos y normas de programación de los nodos. Al final de cada una de las sesiones se realizaba una puesta en común de las actividades, logros y dificultades, las que se atendían clarificaban en el próximo encuentro. En la tabla 1 se resumen las sesio-

1538

nes planificadas, temas tratados y objetivos perseguidos con el abordaje teórico; así como también las actividades prácticas establecidas. Tabla 1. - Contenidos desarrollados en Capacitaciones Sesión 1: Introducción Teoría: Disparadores de WSN. Principio de funcionamiento de WSN. Aplicaciones. Práctica: Programación C++, Estructuras básicas para nodos iSense. Herramienta iShell. Sesión 2: Arquitecturas WSN T: Nodos WSN. Optimización. Caracterización. Principios de diseño. Redes data céntricas. P: Despliegues, sinks, intermedios y leaf, Códigos Sesión 3: Hardware T: Componentes. Diferencias. Criterios de selección. Factores limitantes. Costos P: Configuración diferentes módulos Sesión 4: Aplicaciones y Firmware para nodos T: Programación, Capacidades de SO. Jerarquía de Clases. P: Instalación del iSense SDK. Instalaciones en nodo sensor. Sesión 5: Sistemas Operativos T: SO en WSN. Funcionalidades básicas. Control de eventos. Soluciones. P: Ciclos en el S.O. Arranque, eventos y tareas. Temporizadores. Manejo de Memoria. Sesión 6: Encaminamiento T: Ruteo. Convergencia. Métodos. Multisalto P: Algoritmos de enrutamiento, Flooding and hop-based. Tree Routing. Sesión 7: Sincronización T: Necesidad. Limitaciones. Interacciones usuario, inter WSN, Mundo real. Desafíos. P: pruebas de protocolos. Pruebas de algoritmos (LTS, TPSN and HRTS), Sesión 8: Simulación T: Fundamentos. 802.15.4a. Simulaciones: factores a considerar. P: Simuladores en WSN. Instalación y ejecución.

3.3

Actividades de Formación Práctica

Se ha pretendido que la formación práctica representara un distintivo de calidad de los talleres sin descuidar la profundidad y rigurosidad de la fundamentación teórica y la reflexión, como componentes del aprendizaje Estas tareas en todos los casos han sido ejecutadas con éxito por los participantes. Se listan a continuación algunos de los prototipos actualmente en evolución como parte de proyectos de I+D del grupo de trabajo constituido: A) Simulación de Redes de Sensores inalámbricos mediante interfaz Web. La simulación por computadora ha permitido a los científicos e ingenieros experimentar fácilmente con ambientes virtuales, alcanzando un nuevo nivel de detalle el análisis de las aplicaciones naturales y artificiales; que fuera desconocido en las primeras etapas del desarrollo científico. Se sabe que modelar analíticamente a las WSN es una tarea complicada, dado que se tiende a realizar análisis simplificados. Toda simulación requiere de un modelo apropiado basado en fundamentos teóricos y sobre todo, de fácil implementación práctica [6], dado que los resultados de la simulación se extrapolan del escenario particular de análisis, con determinadas presunciones, que ciertas veces no encierran al comportamiento real, comprometiendo seriamente con ello la credibilidad de las simulaciones.

1539

En éste proyecto se pretende: a) avanzar en el estado del arte en cuanto simulación WSN, b)Analizar propiedades y eventos necesarios para reproducir el comportamiento de una Red; c) Diseñar la interfaz web de obtención de parámetros, incorporación de los archivos particulares del proyecto y visualización de resultados de simulación; d) Diseñar una solución del lado del servidor Web para procesamiento de datos colectados y generación de resultados de simulación; e) Desarrollar un prototipo de interfaz de simulación de WSN basado en la Web que a través de una interfaz pueda obtener parámetros de simulación, incorporar archivos particulares del proyecto, procesar los datos ingresados y generar los resultados de la simulación; f) Realizar pruebas para comprobar el funcionamiento correcto del sistema. Se pretende integrar el potencial de la herramienta de simulación Shawn [7] con todas las ventajas de los sistemas basados en la Web. Se plantea incrementar la capacidad del servidor utilizado en las simulaciones por medio de procesamiento distribuido. B) Sistema Basado en Redes de Sensores Inalámbricos para la Optimización de Recolección de Residuos Domiciliarios en Ciudades Inteligentes. Sabido es que más de la mitad de la población mundial vive hoy en ciudades, y Naciones Unidas estima que el 70% de la población habitarán en centros urbanos en el año 2050. Es primordial por ello, mantener la armonía entre los aspectos espacial, social y ambiental de las localidades, así como entre sus habitantes. En este nuevo escenario sociológico y demográfico, con claros efectos económicos, políticos y medioambientales, cobra fuerza el concepto de ciudad inteligente. El fin de éste proyecto es diseñar un prototipo de sistema, que utilice los datos generados por WSNs, para determinar que contenedores de residuos urbanos [8] ameritan ser recogidos; calculando con ello una ruta óptima de recolección, pretendiendo resolver problemas de gestión con implementaciones inteligentes. Aquí se estudian antecedentes sobre Ciudades Inteligentes, Internet del Futuro, y WSN; pretendiendo caracterizar el funcionamiento del sistema de recolección de residuos de la ciudad de Posadas; definir componentes de hardware y software a utilizar en el proyecto, desarrollar software para los nodos sensores, que permita detectar el nivel de llenado de un contenedor; desarrollar un prototipo para captura de datos desde la Red de Sensores Inalámbricos para el cálculo de ruta óptima, y la visualización de la ruta en un mapa; realizar pruebas de laboratorio verificando el funcionamiento completo del sistema. C) Plataforma para la publicación de datos de Redes de Sensores Inalámbricos, orientada a la visión de la Internet de las Cosas. Se pretende concebir una plataforma para la captura, almacenamiento y publicación de datos de Redes de Sensores Inalámbricos, persiguiendo específicamente: estudiar las tecnologías WSN; evaluar las alternativas existentes para la publicación de datos de WSN útiles para la visión de la IoT; diseñar un prototipo de plataforma que permita la captura, almacenamiento y publicación de los datos obtenidos de la WSN; probar el prototipo en un escenario donde se verifiquen las posibilidades de aplicación práctica como una solución valedera a problemas existentes en diferentes ámbitos.

1540

3.4

Tecnologías Utilizadas

Como plataforma base para los proyectos descriptos se han utilizado equipos con un módulo principal iSense. El hardware iSense se proporciona junto a un firmware operativo y de red modular, permitiendo la generación de aplicaciones pequeñas pero completas; proveyendo una base sólida para el desarrollo rápido de aplicaciones. Brinda una API C++ para el nodo hardware, funcionalidades de sistema operativo y una amplia variedad de protocolos de red.

Ilustración 1. Nodo sensor iSense

En los equipos de desarrollo se utilizó una plataforma PC+Linux en sus distribuciones Ubuntu y Debian. Se instalaron los paquetes make, cmake and gcc++. La plataforma iSense, que incluye al microprocesador Jennic, precisa para el desarrollo de aplicaciones el compilador ba-elf-g++, que asegura la integración perfecta de las librerías. 3.5

Evaluación

Para evaluar el éxito/fracaso de los talleres realizados, se consideraron los siguientes parámetros: Características multidisciplinarias de los participantes capacitados; Cantidad de participantes rechazados por elevada cantidad de postulantes; Calidad de los participantes, expresando el número de participantes con un alto potencial de propagar la capacitación recibida; y la retroalimentación de los participantes. Los resultados de los diferentes talleres organizados han revelado: interés en el tema WSN; exceso de candidatos a participar en los talleres; buen nivel de los participantes, quienes han aplicado lo aprendido para resolver un problema de la vida real específico. Como seguimiento de las actividades de formación propuestas, se ha mantenido contacto con todos los participantes, de los cuales el 60% se encuentra actualmente involucrado en diferentes proyectos referidos a las WSN.

1541

Por otra parte, se han identificado como principales debilidades y amenazas al costo de equipos; desconocimiento de tecnología a nivel de decisión y a la infraestructura de soporte en los lugares de implementación.

Impactos

4.1

Incorporación de WSN a la Currícula en Carreras de Informática

En el contexto descripto, al observarse el interés de los estudiantes por las competencias prácticas adquiridas en las sesiones de capacitación, y habiendo identificando también una genuina motivación por parte de los alumnos en volcar estas competencias en la producción de sus propias tesinas de grado, la UGD decidió incorporar al nuevo plan de estudios de su carrera Ingeniería en Informática en el área de Tecnologías Aplicadas, una nueva asignatura electiva referida a la Tecnología WSN e Internet de las Cosas. La decisión tiene que ver con la evolución que se propone actualmente a nivel internacional desde la Joint Task Force on Computing Curricula (ACM & IEEE-CS) [9], como también en los ámbitos de debate sostenidos en nuestro país promovidos por la RedUNCI y la RIISIC para la estandarización de contenidos básicos e intensidad de formación práctica de las carreras en Informática. La asignatura tiene relación directa con Redes y Comunicaciones siguiendo un enfoque bottom-up, construyendo la comprensión de las redes desde sus niveles más bajos o físicos hacia los más altos en los modelos de referencia, con una modalidad organizativa del tipo taller, basada en el Aprendizaje Basado en Problemas (ABP) [10]. Las metas a alcanzar son: Comprender y aplicar conocimientos inherentes a las WSN, en función de los desafíos presentados por la tecnología, a saber: Eficiencia Energética, Capacidad limitada de procesamiento, ancho de banda y almacenamiento, altos niveles de error, escalabilidad y robustez. Por otra parte, los contenidos sintéticos definidos incluyen: Motivación para el estudio de las WSN. Sensores. Génesis de WSN. Desafíos. Aplicaciones. Arquitectura de nodos. Sistemas Operativos. Modelo de Referencia. Capa física. Control de acceso al medio. Capa de red. Gestión de energía. Sincronización. Localización. Seguridad y Programación en WSN. En todos los casos se prioriza la realización de actividades de resolución de problemas abiertos, de proyecto y diseño, en la búsqueda de inculcar un espíritu de investigación tendiente a producir descubrimientos que permitan nuevos desarrollos, articulándose perfectamente con el Taller de Tesis de Grado/Trabajo Final de carrera vigente en la universidad. 4.2

Radicación de Nuevos Proyectos de I+D

El desarrollo de los talleres de WSN ha consolidado la conformación de un grupo de investigación y desarrollo, integrado por docentes e investigadores de la UNaM y UGD, habiéndose planteado varias (6) tesinas de grado en el contexto [11], incluyendo algunas con relación directa con la industria [12] .

1542

La UGD ha asignado recursos para que varios alumnos en etapa de preparación de su tesis de grado sean asimilados como becarios en el mencionado proyecto, recursos estos que son solventados con fondos propios de la universidad, logrando con ello involucrar a estudiantes de grado en proyectos de investigación, desarrollo e innovación tecnológica con beneficios reales y concretos para su formación, exponiendo a los estudiantes a interesantes proyectos en su contexto regional socio-productivo y al proceso reflexivo crítico involucrado en la investigación científico-tecnológica.

Conclusiones y Trabajos Futuros

Se considera que los talleres de implementación de WSN descriptos en este trabajo han resultado exitosos, ya que han promovido la conformación de un grupo de I+D, en cuyo contexto se desarrollan diferentes tesinas de grado y proyectos fomentado el desarrollo local de soluciones que buscan resolver problemas del entorno regional. Los talleres han resultado la fuente de actualización curricular de una de las carreras en Informática que ofrecen las universidades involucradas en la experiencia reportada. El objetivo último ha sido siempre conducir a cada uno de los participantes a la obtención de una solución para la problemática particular propia, descartando en todo momento las actividades conductoras a un único tipo determinado de proyecto, tendiendo a la co-creación del conocimiento [13]. En este mismo sentido, se ha desarrollado una Wiki, con documentación construida de forma cooperativa en los talleres de capacitación ofrecidos y en la que se proveen además guías prácticas para la instalación del entorno de desarrollo SDK de iSense y la instalación del simulador Shawn. Finalmente, es destacable mencionar que en los próximos talleres a desarrollar se prevé enfocarse en IPv6 y seguridad en WSN, con la certeza que la demanda de este tipo de capacitación es creciente, estando persuadidos acerca de que la red IPng será soporte indefectible de todas las redes de sensores, alentando el advenimiento de Internet de las cosas.

Bibliografía [1]

M. Weiser, "The computer for the 21st century," SIGMOBILE Mob. Comput. Commun. Rev., vol. 3, no. 3, 1999.

[2]

ITU, "ITU Internet Reports 2005: The Internet of Things," 2005.

[3]

D. Dickson, "Buenas y malas noticias sobre la ‘brecha científica’," SciDev.Net, 2009. [Online]. Available: http://tiny.cc/00jtww.

[4]

MINCyT, "PLAN NACIONAL DE CIENCIA,TECNOLOGÍA E INNOVACIÓN: Lineamientos estratégicos 2012-2015," Buenos Aires, 2012.

[5]

E. Sosa, "Tesis Doctoral: Contribuciones al Establecimiento de una Red Global de Sensores Inalambricos Interconectados," Universidad de La Plata, 2011.

[6]

E. Egea-López and e. al., "Simulation Tools for Wireless Sensor Networks," in

1543

Summer Simulation Multiconference - SPECTS 2005, 2005. [7]

S. Fekete, A. Kroller, S. Fischer and D. Pfisterer, "Shawn: The fast, highly customizable sensor network simulator," Braunschweig, 2007.

[8]

S. Longhi, D. Marzioni, E. Alidori, G. Di Buo, M. Prist, M. Grisostomi and M. Pirro, "Solid Waste Management Architecture Using Wireless Sensor Network Technology," in 5th International Conference on New Technologies, Mobility and Security (NTMS), 2012.

[9]

The Joint Task Force on Computing Curricula, "Computer Science Curricula 2013," Association for Computing Machinery & IEEE-Computer Society, February 2013.

[10] L. V. Morales P., "Aprendizaje basado en problemas," Theoria, vol. 13, no. 1, pp. 145-157, 2004. [11] E. Sosa, D. Godoy, R. Neis, G. Motta, R. Luft, D. Sosa, H. Bareiro and P. Quiñones, "Internet del Futuro y Ciudades Inteligentes," in XV Workshop de Investigadores en Ciencias de la Computación 2013, Paraná, 2013. [12] A. Quiñones, D. Godoy and E. Sosa, "Redes Inalámbricas de Sensores: Una experiencia en la Industria del Té," in 5º Congreso Argentino de AgroInformática(en prensa), Córdoba, 2013. [13] B. Regeer and J. Bunders, "Knowledge co-creation: Interaction between science and society. A Transdisciplinary Approach to Complex Societal Issues," Advisory Council for Research on Spatial Planning, Nature and the Environment/Consultat, La Haya, 2009.

1544

El desarrollo de la comprensión lectora en las carreras de Informática Sonia Rueda

Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur

Abstract. El desarrollo de las competencias comunicativas involucra entre otras capacidades la comprensión lectora. En las carreras de Informática las materias iniciales demandan cierto nivel de desarrollo de esta capacidad pero también brindan la oportunidad de reforzarla. En estas asignaturas se utiliza lenguaje natural y distintos lenguajes artificiales. Este trabajo describe los diferentes modelos de textos y de lenguajes a través de los cuáles se fortalece la comprensión lectora, en cada una de las materias de Programación de las carreras ofrecidas por el Departamento de Ciencias e Ingeniería de la Computación de la UNS. Keywords: Diseño curricular basado en competencias. Comprensión Lectora. Lenguaje natural y lenguaje artificial.

1 Introduction La formación de un profesional en Informática requiere, entre otros aspectos, el desarrollo del razonamiento lógico, la argumentación, la organización de la información y la apropiación del lenguaje de la ciencia y la tecnología. Todas estas capacidades demandan a su vez de competencias comunicativas que permitan elaborar e interpretar actos del habla. Cada nivel educativo presupone cierto nivel de desarrollo en las competencias comunicativas y asume la responsabilidad de reforzarlo. Sin embargo, en el ámbito universitario es poco frecuente que se establezca con precisión lo que se asume adquirido, lo que se espera desarrollar y las acciones y actividades concretas que se realizan para alcanzar este desarrollo. La comprensión lectora es una capacidad básica fundamental para la competencia comunicativa de un alumno que comienza a cursar una carrera en el nivel superior. Es también imprescindible para un graduado de una carrera universitaria. Ahora bien, ¿qué nivel de comprensión lectora se espera de un ingresante? ¿cuál debería ser el nivel de desarrollo de esta capacidad en un graduado? El objetivo de este trabajo es analizar y describir los diferentes modelos de textos, elementos discursivos y lenguajes con los cuales se fortalece la comprensión lectora en las materias de Programación de las carreras ofrecidas por el Departamento de Ciencias e Ingeniería de la Computación (DCIC) de la Universidad Nacional del Sur (UNS). Los programas de estas materias incluyen a los contenidos básicos

1545

establecidos para el trayecto Algoritmos y Lenguajes en la resolución ME 786/09. La siguiente sección presenta el marco conceptual del trabajo. A continuación se describe brevemente la metodología de enseñanza adoptada en el las materias de Programación. Luego se vincula esta metodología con el desarrollo de la comprensión lectora, indicando los modelos de textos y lenguajes que se utilizan en estas asignaturas. Por último, se ofrecen algunas conclusiones y lineamientos para el trabajo futuro.

2 Marco Conceptual Sobre finales de los ´90 comienza en Europa la Reforma Universitaria a partir de una declaración conjunta que dio inicio a un proceso de convergencia educativa. Los principales objetivos de este proceso, que continúa vigente, son promover la cooperación para garantizar la calidad educativa, facilitar la movilidad de alumnos, docentes e investigadores y establecer un sistema internacional de créditos que permita comparar titulaciones [1]. Dada la diversidad de los sistemas educativos europeos, la expectativa no es uniformar los planes de estudio, sino adoptar un modelo curricular basado en competencias. El modelo busca disminuir la brecha entre la formación académica acreditada y las oportunidades para obtener un puesto de trabajo; propone establecer lo que un graduado debe saber, saber hacer y saber ser para poder insertarse eficazmente en el sistema productivo. Este enfoque tiene antecedentes previos al proceso de convergencia europeo, pero es a partir de esta declaración que ha tomado relevancia en el ámbito universitario. Desde entonces el término competencia ha sido definido de maneras diferentes [2]. Algunos autores lo consideran equivalente a capacidad. Otros le asignan al término capacidad un significado estático, vinculado a una aptitud potencial, mientras que una competencia sería una capacidad puesta en acción, esto es, aplicada a una situación concreta de modo que puede evaluarse la eficacia. Bajo otro criterio el concepto de capacidad se refiere a la integración de conocimientos, aptitudes y habilidades que se adquieren en el ámbito formativo, mientras que las competencias son capacidades aplicadas al desempeño profesional. En este trabajo definimos competencia como “un conjunto de conocimientos, capacidades y actitudes que se articulan y aplican eficazmente para resolver una situación o problema concreto en un contexto académico o laboral”. Definimos capacidad como una “aptitud o habilidad que se desarrolla a partir de la integración y acumulación de aprendizajes significativos”. Las competencias requeridas en el sistema productivo coinciden parcialmente con las demandadas en el ámbito universitario. En las empresas esperan que los profesionales de Informática sean competitivos, proactivos, asuman riesgos, puedan liderar equipos de trabajo, enfrenten desafíos, etc. Claramente no todos los puestos de trabajo de una empresa demandan estas características, pero el crecimiento de un profesional con frecuencia está tan ligado a estas cualidades, como a su formación académica. En general los contenidos, metodologías de enseñanza y mecanismos de evaluación del plan de estudios de una carrera, no están específicamente orientados al desarrollo o valoración de estas cualidades. Las diferencias entre las expectativas de uno y otro ámbito y la responsabilidad de la Universidad con relación al desarrollo de competencias laborales, ha sido tema de

1546

debate en la última década. Más allá de estas diferencias, la habilidad social, el trabajo en equipo y en particular la competencia comunicativa son reconocidas y valoradas tanto en la etapa formativa, como durante el desempeño profesional. Consideramos que la competencia comunicativa es un conjunto de conocimientos, capacidades y actitudes articulados y aplicados eficazmente para comprender y elaborar actos del habla. Un acto del habla es una acción que transmite un mensaje desde un emisor hacia un receptor o destinatario en un lenguaje compartido. Esta competencia requiere reconocer no solo el significado explícito o literal de un mensaje, lo que se dice, sino también las implicaciones, el sentido explícito o intencional, lo que el emisor quiere decir o lo que el destinatario quiere entender. Este trabajo se refiere específicamente en la comprensión lectora, considerando que se trata de una de las capacidades fundamentales para la competencia comunicativa, tanto en el ámbito académico como profesional. Restringimos el análisis a las materias de Programación de las carreras ofrecidas por el DCIC. 2.1 La comprensión lectora La lectura es un proceso de interacción entre el pensamiento y el lenguaje. Este proceso requiere reconocer los símbolos del lenguaje y las reglas que estructuran el uso de estos símbolos, pero también comprender el significado de lo leído. La comprensión permite elaborar un significado para el texto. El lector elabora un significado a partir de conceptos que a su vez tienen significado para él y de sus estrategias para la comprensión lectora [3]. Este trabajo se concentra en la comprensión de dos tipos de textos: expositivos y descriptivos. Estos tipos de texto aparecen en diferentes modelos como: apuntes de cátedra, trabajos prácticos, libros, manuales, tutoriales, instructivos, artículos científicos, páginas web, presentaciones de diapositivas, etc. El formato puede ser impreso o digital. Este último puede incluir recursos como sonido, animación e hipervínculos que permiten una lectura no lineal. Cada modelo de texto puede incluir diferentes modos discursivos, como definiciones, comparaciones, enumeraciones, ejemplificaciones, síntesis, etc. Cada modelo de texto y cada modo discursivo se distingue por su forma y sobre todo por su intencionalidad. El nivel de comprensión depende de la complejidad del texto y también de la formació en el tema y la intencionalidad del lector respecto a la profundidad de la lectura. Una lectura primaria o literal puede ser suficiente para reconocer entidades, conceptos, sucesos, acciones y relaciones explícitas. La lectura inferencial permite identificar causas-efectos y explicitar información o asociaciones, que están señaladas implícitamente. El reconocimiento de metáforas y analogías implica un nivel comprensión aun mayor. También se requiere un nivel de lectura comprensiva más elevado cuando una actividad exige emitir juicios o comparar entidades fundamentando la valoración. La lectura crítica tiene entonces un carácter evaluativo donde interviene el criterio del lector y su conocimiento acerca de lo leído [8]. 2.2 La metodología de enseñanza basada en la resolución de problemas Desde la década del ’80 se han desarrollado metodologías de enseñanza basadas en la resolución de problemas con enfoques diferentes:

1547

• Aprender desde la resolución de problemas implica abordar los contenidos conceptuales de una asignatura específica a partir de problemas. • Aprender sobre la resolución de problemas se refiere a aprender acerca de los procesos y estrategias cognoscitivas que aplicamos cuando resolvemos problemas, para controlarlos en forma consciente y deliberada. • Aprender a resolver problemas se orienta a que los alumnos adquieran destreza en la resolución de problemas generales, reconociendo la importancia de cada etapa del proceso de resolución. Estos enfoques no son alternativos sino que pueden complementarse y son consistentes con la práctica reflexiva, el trabajo en equipo y por proyectos, el aprendizaje autónomo y comprometido. Demandan docentes capaces de trabajar con grupos heterogéneos, generar y gestionar situaciones de aprendizaje, entre otras competencias docentes. Las situaciones de aprendizaje deben constituir un desafío, pero al mismo tiempo deben ser una meta alcanzable [6][7]. Las metodologías de enseñanza basadas en la resolución de problemas resultan particularmente valiosas para el diseño curricular basado en competencias, dado que la resolución de problemas es una competencia fundamental tanto en el ámbito académico como laboral. Es también una metodología útil para el desarrollo de la competencia comunicativa ya que la interpretación del problema demanda capacidad para la comprensión lectora y por lo general la construcción de la solución exige habilidades para la producción escrita.

3. Las materias de Programación de las carreras del DCIC Este trabajo analiza y describe la capacidad de comprensión lectora que se asume alcanzada y que se aspira a desarrollar en cuatro materias del área Programación: Resolución de Problemas y Algoritmos (RPA), Introducción a la Programación Orientada a Objetos (IPOO), Estructuras de Datos (EdD) y Tecnología de Programación (TdP). Estas asignaturas forman parte de los planes de estudio de las carreras ofrecidas por DCIC de la UNS. Todas adoptan una metodología de enseñanza basada en la resolución de problemas. Bajo esta concepción, el desarrollo de un programa puede pensarse como la construcción de una solución para un problema real, la solución es un modelo escrito en un lenguaje de programación [4]. Antes de comenzar a cursar RPA, los alumnos deben haber aprobado el curso de nivelación Análisis y Comprensión de Problemas, uno de cuyos principales objetivos es justamente reforzar la comprensión lectora aplicada específicamente a la resolución de problemas [5]. Durante este curso se refuerzan las estrategias para la comprensión lectora, en particular la inferencia. Se plantean problemas que permiten reconocer la importancia de interpretar adecuadamente un enunciado para identificar la incógnita, los datos explícitos e implícitos y las restricciones. Los enunciados y las soluciones incluyen textos en distintos lenguajes gráficos. En RPA se asume que los alumnos pueden interpretar adecuadamente el enunciado de un problema como parte del proceso de resolución, son capaces de aplicar estrategias básicas para la comprensión lectora de distintos modelos de textos y reconocen diferentes modos discursivos. Al completar el cursado de TdP la expectativa es que

1548

hayan reforzado las estrategias de lectura sobre un conjunto más amplio de modelos de textos, puedan comprender diferentes lenguajes artificiales y decidir el nivel de lectura que se requiere para comprender un texto, considerando la intencionalidad.

4 Lenguajes naturales y artificiales Un lenguaje natural es un lenguaje con propósito general, generado espontáneamente y usado por humanos para comunicarse. Aunque existen reglas sintácticas que restringen la forma de combinar los símbolos del lenguaje, todo lenguaje natural admite cierto nivel de ambigüedad y permite que algunas expresiones tengan un significado literal diferente al sentido figurado. En la secuencia de materias de Programación es importante que los docentes planifiquen la progresión de aprendizajes [7], consideren y decidan premeditadamente cuál es el nivel de lectura que va a requerir cada texto, qué modos discursivos y modelos de textos se proponen y diseñen actividades considerando las habilidades que asumen adquiridas para la compresión lectora y las que aspiran profundizar, en cada etapa de la secuencia. Un lenguaje artificial es una notación con un propósito específico y puede estar definido formalmente, en este caso tiene una sintaxis estricta y una semántica precisa. Como otras ciencias, la Matemática posee un lenguaje artificial que simplifica y clarifica la comunicación, designando de una manera exacta sus contenidos a través de términos y símbolos específicos. La comunicación se simplifica y clarifica si los alumnos pueden interpretar estos términos y símbolos, como así también el modo de estructurarlos. Si por el contrario, desconocen el lenguaje utilizado, la comprensión del contenido se dificulta, por más exacta y precisa que sea una expresión. De hecho, una de las dificultades de los alumnos que ingresan a una carrera universitaria se relaciona justamente con la interpretaciones de textos escritos en una notación formal como la que brinda la Matemática. Las materias de Programación ofrecen múltiples oportunidades de aplicar notaciones formales, en particular el lenguaje Matemático aprendido en el Nivel Polimodal y profundizado en las asignaturas de Ciencias Básicas. Es importante que se reflexione explícitamente acerca de los beneficios de utilizar una notación rigurosa y se generen actividades que incluyan entre sus objetivos la “lectura” de textos escritos usando esta notación. Una especificación como Sea S una secuencia de la forma s1 s2 … sm-1 sm tal que si ≤ si+1 con 1 ≤ i < m.va a requerir que el docente describa la notación al comenzar el cursado de RPA y ayude a interpretarla tanto en las clases teóricas como prácticas, manteniendo por supuesto la uniformidad en el lenguaje. Al completar esta asignatura la lectura de este tipo de expresiones debería ser fluida. Así, la semántica de las operaciones que los alumnos deben implementar comienza a describirse combinando lenguaje natural y una notación formal desde la primera materia de Programación. La definición recursiva de factorial, el algoritmo para computar el máximo común divisor entre dos números naturales, las propiedades de secuencias de elementos, la especificación formal de las operaciones del tipo de dato abstracto Pila, son algunos de los ejemplos con los cuáles se aprenden a usar notaciones formales para establecer la semántica de las operaciones.

1549

La interpretación de cada una de estas especificaciones se puede complementar con algunos ejemplos significativos, que luego pueden ser usados como casos de prueba en la verificación. Es importante que los alumnos entiendan que la solución tiene que ser general, no solo funcionar correctamente para los casos de prueba específicos. 4.1 Lenguaje natural En las cuatro materias de Programación en las clases teóricas se utilizan presentaciones de diapositivas. Cada docente aplica diferentes criterios y estilos para armar sus presentaciones y combinarlas con otros recursos, como por ejemplo el pizarrón, el ambiente de programación o animaciones para ilustrar la ejecución de algunos programas. Cualquiera sea el criterio y estilo, las presentaciones siempre incluyen y destacan el vocabulario técnico que se va introduciendo junto con los contenidos conceptuales propios de cada materia. Así, el lenguaje natural conocido por los alumnos, aumenta con nuevas palabras, propias de la disciplina. Aunque asumimos que los alumnos pueden reconocer diferentes modos discursivos, en general resulta valioso detenerse para resaltar las características de cada uno de ellos con respecto a la forma y sobre todo la intencionalidad. Asimismo es pertinente remarcar antes de una evaluación, que cuando se pida la definición de un concepto, no se considerará válida una respuesta que sólo aporte algunos ejemplos, aunque se refieran a ese concepto; del mismo modo, si una consigna requiere una comparación entre dos recursos, es probable que dos descripciones independientes no se consideren válidas como respuesta, excepto que ambas describan a los conceptos en términos de los mismos atributos y la comparación sea evidente, aunque no esté explícita. La lectura de manuales y tutoriales es una actividad en la cual los alumnos tienen que ir adquiriendo destreza progresivamente. Es importante que se incluyan actividades que requieran interpretar textos de temas no desarrollados en clase, pero que al mismo tiempo tengan una complejidad adecuada para ser comprendidos de manera autónoma. Cuando los manuales o tutoriales están disponibles en versión digital es posible estimular la lectura no lineal proponiendo actividades que requieran navegar a través de hipervínculos. En RPA los contenidos conceptuales y el lenguaje de programación utilizado se presentan en detalle en las clases teóricas a través de la resolución de problemas. El lenguaje natural aparece entonces en las descripciones, definiciones, comparaciones y enunciados. Los enunciados incluidos en trabajos prácticos y evaluaciones, con frecuencia se complementan con textos escritos en lenguajes artificiales, por ejemplo algoritmos, expresiones matemáticas, diagramas. Es importante que el docente reflexione cuando produce una actividad, cuál va a ser nivel de lectura que demanda. Más allá de la dificultad que pueda entrañar el problema, si los datos, la incógnita y las restricciones están formulados explícitamente, la comprensión de texto no demandará mayor esfuerzo. Si en cambio la interpretación del enunciado requiere un proceso de abstracción para reconocer los datos relevantes o un proceso de inferencia que permita identificar datos que están implícitos, la capacidad de comprensión toma un rol más importante para la resolución. En las dos primeras materias de Programación, como así también en el curso de nivelación, se incluyen problemas equivalentes en complejidad respecto a las estrategias de resolución, pero con diferentes requerimientos respecto al nivel de

1550

comprensión lectora. La expectativa es justamente identificar las dificultades para poder superarlas. En IPOO los elementos básicos del lenguaje de programación se describen brevemente en las clases prácticas y se asume cierta autonomía por parte de los alumnos para profundizar los temas presentados y evacuar dudas consultando manuales, tutoriales y por supuesto a los docentes. Algunos paquetes y clases provistas por el lenguaje se describen parcialmente y se propone como actividad investigar acerca de otros los servicios. En ningún momento la expectativa es que los alumnos los memoricen. Los recursos provistos por el lenguaje para soportar los conceptos centrales de la programación orientada a objetos, se presentan en teoría, se aplican en la práctica y se refuerzan a través de la lectura de bibliografía. En EdD y TdP la lectura profunda de la bibliografía propuesta es indispensable para las evaluaciones finales y la realización de proyectos. Una de las cuestiones que afecta a la adaptación de los alumnos al ámbito universitario es justamente el nivel de profundidad con el que leen y nivel de lectura con que se espera que lean. Una lectura superficial de un texto puede ser muy adecuada entre una clase y otra, de modo que el docente pueda profundizar en un tema o incluso presentar uno nuevo, asumiendo que los alumnos comprendieron las nociones básicas del contenido presentado previamente. El mismo nivel de lectura no va a ser adecuado cuando se espera que comprendan en profundidad un tema, por ejemplo para aplicar los contenidos para la resolución de un problema o la realización de un proyecto. En cada materia es importante estimula la reflexión acerca de cuándo es suficiente realizar una lectura primaria y cuándo se espera que alcancen un nivel de comprensión más profundo a través de una lectura inferencial o más aun, crítica. Un aspecto a remarcar es que la lectura de un resumen de un texto puede ser más compleja que la del texto original, porque en el resumen suelen quedar implícitas asociaciones y se eliminan aclaraciones, observaciones, analogías y ejemplos que favorecen la comprensión. Este hecho no siempre es evidente para los alumnos y con ejemplos adecuados puede ilustrarse claramente. Este tipo de actividades, que en principio no son parte de los objetivos de estas asignaturas, pueden resultar fundamentales para favorecer capacidades como la comprensión lectora. En cada una de las tres primeras materias de Programación se utiliza un entorno de desarrollo diferente. Desde el punto de vista de la comprensión lectora un ambiente de desarrollo demanda interpretar las opciones provistas por los distintos tipos de menúes, los mensajes de error del compilador y la información que nos brinda el depurador. Actualmente los alumnos están habituados a interactuar con diferentes interfaces gráficas de usuarios y en general se adaptan rápidamente a explorar y utilizar una aplicación de software. También es común que la instalación de una aplicación no implique una dificultad. Aun así, es conveniente proponer alguna actividad que implique leer un instructivo como por ejemplo para instalar un entorno de desarrollo, crear un paquete o un ejecutable. 4.2 Lenguajes Artificiales Uno de los objetivos de las materias de Programación es que los alumnos interpreten textos escritos y construyan soluciones usando diferentes lenguajes. Algunos de estos lenguajes tienen una especificación formal como los lenguajes de programación, lenguajes de modelado, lenguajes gráficos de especificación sintáctica, notaciones

1551

matemáticas, etc. Otros lenguajes artificiales no tienen reglas formales que los definan como por ejemplo los lenguajes de diseño de algoritmos y los lenguajes para modelar la evolución de la memoria. En cada materia es necesario planificar la presentación de los lenguajes en las clases teóricas respecto a cómo se utilizan y combinan en los enunciados de problemas y proyectos en las clases prácticas y en las evaluaciones parciales y globales. Un objetivo más importante aun, es que los alumnos aprendan a aprender lenguajes artificiales. El enfoque basado en resolución de problemas es fundamental en este sentido porque cada lenguaje se aprende usándolo. Así, más allá de describir los aspectos sintácticos y semánticos, es necesario centrarse especialmente de las cuestiones pragmáticas de cada notación. El uso de distintas notaciones artificiales contribuye a desarrollar la autonomía en el aprendizaje. Es muy importante articular la secuencia de acuerdo a la cual se presentan y utilizan cada una de estas notaciones en cada asignatura, para que los alumnos puedan desarrollar gradualmente la capacidad de comprender y producir textos escritos utilizando distintos lenguajes. En RPA se propone un lenguaje de diseño de algoritmos que, con una sintaxis menos rigurosa que el lenguaje de programación, favorece la construcción de un modelo para la resolución de cada problema planteado. El objetivo de esta etapa es identificar las estructuras de control requeridas para la resolución. El lenguaje de diseño resulta útil cuando el problema puede ser dividido en subproblemas o la resolución implica combinar al menos dos estructuras de control. Si el problema es muy simple, no se destaca la ventaja de diseñar un algoritmo antes de comenzar a escribir código en el lenguaje de programación. También en RPA se introduce un lenguaje para modelar la evolución de memoria, que permite construir diagramas que muestran una traza de la ejecución de un programa o subprograma. Aunque existen diferentes formas de construir estos diagramas, es importante acordar una notación uniforme dentro de una misma asignatura. En IPOO se usan diagramas de evolución de referencias que modelan la memoria, pero en este caso en el paradigma orientado a objetos. Los lenguajes gráficos de especificación sintáctica se utilizan en las cuatro materias descriptas en este trabajo. La sintaxis de cada mecanismo provisto por los lenguajes de programación usados, se especifica a través de diagramas sintácticos. En RPA la aparición de un diagrama requiere detenerse en explicar la notación, más allá del objeto mismo que se está describiendo. En general no se destina una clase específica a describirla, sino que se presenta en forma transversal a otros contenidos. Es muy importante articular las materias y acordar en qué momento se espera que los alumnos tengan autonomía para la lectura de este tipo de diagrama. En IPOO los alumnos interpretan diagramas sintácticos, reconocimiento especificaciones condicionales, iterativas y recursivas. La “lectura” de un diagrama sintáctico permite reconocer instrucciones y expresiones válidas, distinguir aspectos sintácticos y semánticos de un lenguaje de programación y comprender la necesidad de que un lenguaje de programación tenga una sintaxis rigurosa. Los diagramas sintácticos se utilizan también para especificar la forma de una secuencia de elementos que deben ser procesados. La resolución del problema requiere interpretar la especificación y luego diseñar el algoritmo para procesar la secuencia e implementarlo en un lenguaje de programación. Si los alumnos están

1552

familiarizados con este tipo de diagrama, la formalización es una ayuda porque permite descubrir las estructuras de control adecuadas y facilita el diseño del algoritmo. En caso contrario, la “lectura” del diagrama puede representar una dificultad adicional al problema propiamente dicho. En IPOO se introducen los elementos básicos de un lenguaje de modelado para construir diagramas de clases y en las materias que siguen se presentan otro tipo de recursos para elaborar distintos tipos de diagramas. En IPOO muchos de los enunciados incluyen un diagrama de clases en donde se especifican las decisiones de diseño de cada clase y las relaciones que las vinculan. La interpretación del diagrama, incluyendo las responsabilidades de cada clase, es una de las capacidades que se aspira desarrollar en esta asignatura. En las materias que siguen no solo se interpretan modelos escritos en UML sino que muchos problemas requieren producir diseños usando este lenguaje. La comprensión lectora de textos producidos usando los lenguajes artificiales mencionados, es una capacidad que las materias de las áreas Ingeniería de Software y Sistemas, asumen adquiridas previamente. El desarrollo de esta capacidad se alcanza como tanto en las materias de Programación como en las asignaturas del área Fundamentos de Ciencias de la Computación.

Conclusiones y trabajo futuro Las competencias comunicativas son reconocidas y valoradas tanto en el ámbito académico como en el sistema productivo. Los planes de estudio de las carreras ofrecidas por el DCIC de la UNS no incluyen asignaturas orientadas específicamente al desarrollo de la comprensión lectora, la producción escrita y la oralidad. Estas capacidades se consideran transversales, de modo que el diseño curricular de las asignaturas se realiza asumiendo cierto nivel adquirido de cada una de ellas y se compromete a reforzarlas. En las materias del área Programación de estas carreras se adoptó hace más de 20 años una metodología de enseñanza basada en la resolución de problemas. El objetivo principal de aprendizaje está vinculado evidentemente con el desarrollo de programas, para lo cual se presentan varios lenguajes de programación. La comprensión del lenguaje natural se enriquece con la lectura de diferentes modelos de textos. Es importante que los docentes hagan notar a los alumnos las particularidades de cada modelo, especialmente en lo que se refiere a la comunicación, e indiquen también el nivel de lectura que se espera que realicen de cada uno, en cada momento. La caracterización de tres niveles de lectura puede ser suficiente en este sentido: primaria, inferencial y crítica. Cualquiera sea el modelos de texto puede incluir diferentes modos discursivos. Estos modos son conocidos previamente por los alumnos pero la reflexión explícita acerca de las características y sobre todo la intencionalidad de cada uno, contribuye a fortalecer las competencias comunicativas. En particular, las definiciones aumentan el vocabulario incorporando términos propios de la disciplina y enriqueciendo el lenguaje natural. La introducción progresiva de diferentes lenguajes artificiales, con distintos grados de rigurosidad sintáctica y semántica, contribuye a desarrollar la competencia

1553

comunicativa. Es importante articular adecuadamente la presentación y aplicación de cada nueva notación, de modo que cada una constituya una ayuda y no un obstáculo. Algunos lenguajes van a ser descriptos en detalle, siempre aplicados a situaciones concretas, en otros se va a requerir mayor autonomía de aprendizaje por parte de los alumnos. En cada caso debe reflexionarse y establecerse explícitamente las competencias previas que se asumen adquiridas. Este trabajo se concentra específicamente en la comprensión lectora abordada desde cuatro asignaturas de una misma área. Una extensión natural es considerar la producción escrita y la oralidad. El trabajo puede extenderse también para abordar el desarrollo de la competencia comunicativa en otras áreas de la disciplina. Una vez que se haya avanzado en estos dos sentidos la expectativa es analizar otras competencias reconocidas tanto en el sistema educativo como productivo.

Referencias [1] Declaración de Bolonia. Declaración conjunta de los Ministros Europeos de Educación. Bolonia (1999) http://www.ond.vlaanderen.be/hogeronderwijs/bologna/ [2] Mastache, Anahí: Formar personas competentes. Desarrollo de competencias tecnológicas y psicosociales. Novedades Educativas.ISBN:978-987-538-199-5 (2007). [3] Castro Fox Guillermina, González Nora, Monti Carla, Palmucci Daniela: Estrategias para la Lectura Comprensiva. Un abordaje al discurso científicopedagógico. Universidad Nacional del Sur. (2005) [4] Rueda Sonia, García Alejandro: Análisis y Comprensión de Problemas: Fundamentos, Problemas Resueltos y Problemas Propuestos. Notas del curso de nivelación. Universidad Nacional del Sur. Argentina Págs.: 90. (2004) [5] Rueda Sonia, Señas Perla: Un enfoque basado en la resolución de problemas para la enseñanza de la Programación Orientada a Objetos Bahía Blanca III Congreso en Tecnología en Educación & Educación en Tecnología (Teyet) (2008) [6] Perrenoud Philippe: Diez nuevas competencias para enseñar. Editorial Graó. ISBN 978-84-7827-321-8 (2004) [7] Whimbey Arthur, Lochhead Jack, Narode Ronald: Problem Solving & Comprehension Wearset Ltd. Boldon ISBN 978-0-415-50221-4 (2013) [8] Alonso Tapia, Jesús: Leer, comprender y pensar: Desarrollo de estrategias y técnicas de evaluación. MEyC. CIDE. Madrid. ISBN: 84-369-2270-0 (1992)

1554

Extensi´ on del Lenguaje y Modelo Simplesem con Soporte para Paralelismo Lucas L. Diez de Medina, Gustavo Wolfmann y Orlando Micolini Facultad de Ciencias Exactas, F´ısicas y Naturales. Universidad Nacional de C´ ordoba Av. Velez Sarsfield 1611 - C´ ordoba – Argentina lucaslt89@gmail.com gwolfmann@gmail.com omicolini@compuar.com

Resumen El modelo de ejecuci´ on planteado por Carlo Ghezzi y Mehdi Jazayeri, conocido como Simplesem, no contempla lenguajes con instrucciones de ejecuci´ on paralela. El objectivo es extender esta herramienta educativa incorporando al modelo la existencia de m´ ultiples procesadores primitivas de lenguaje que permitan expresar conceptos b´ asicos de paralelismo. Para ello, se desarroll´ o una herramienta que permite analizar de manera gr´ afica y sencilla el impacto de programas multihilo sobre instrucciones de bajo nivel, que operan directamente sobre la memoria compartida de una m´ aquina virtual. Esta extensi´ on permite representar la sem´ antica operacional de lenguajes paralelos que requieren procesadores multihilo, comunes en la actualidad.

Introducci´ on

Las dificultades a las que se enfrenta un alumno al estudiar el proceso que atraviesa un programa escrito en un lenguaje de alto nivel, hasta poder ser ejecutado por el procesador. Principalmente esto se debe a dos motivos: La complejidad de los lenguajes de programación de alto nivel existentes, y la del hardware sobre el cual se ejecutan. En su libro “Programming Language Concepts”, Carlo Ghezzi y Mehdi Jazayeri [1] propusieron una alternativa para solucionar estos problemas. En primer lugar, propusieron un modelo de ejecución que consiste en una máquina formada por un procesador simple, una memoria de código y una memoria de datos. El procesador es capaz de ejecutar cuatro instrucciones elementales que conforman las primitivas del modelo Simplesem. En segundo lugar, definieron una serie de lenguajes de programaci´ on de alto nivel, de complejidad creciente, que coinciden con diversas categorizaciones de lenguajes. A partir de estas dos propuestas, lograron simplificar el proceso de aprendizaje de la relación entre los lenguajes de programaci´ on, y los recursos de la computadora. Las memorias de datos y de código de la máquina Simplesem están formadas por celdas. En la memoria de código, las celdas almacenan instrucciones, y se utiliza un puntero para seleccionar la celda que contiene la siguiente instrucción a ejecutar. En la memoria de datos se almacena un valor por cada celda. Las

1555

operaciones se realizan directamente sobre la memoria de datos (no hay registros intermedios). Existen algunas celdas en las que se almacenan valores espec´ıficos utilizados para el funcionamiento de la máquina. Con respecto a las instrucciones, el modelo Simplesem consta de tres instrucciones compuestas (set, jump y jumpt), y una instrucción especial para indicar la finalizaci´ on del programa (halt). Por instrucciones compuestas se entiende aquellas instrucciones que pueden contener expresiones, y el resultado de dichas expresiones ser´ a lo que se utilice como operandos de la instrucción. Las primitivas del modelo Simplesem permiten implementar la semántica operacional de un conjunto de lenguajes de alto nivel. Ghezzi y Jazayeri definieron lenguajes de alto nivel para demostrar el funcionamiento del modelo Simplesem. El primer lenguaje, conocido como C1, sólo posee tipos de datos simples, e instrucciones simples (no tiene soporte para funciones). Sólo pueden utilizarse tipos de datos que permitan determinar los requerimientos de memoria de manera est´ atica, como enteros, arreglos de tama˜ no fijo y estructuras. El segundo lenguaje, conocido como C2, incorpora la posibilidad declarar rutinas en el programa, que pueden contar a su vez con variables locales. Las rutinas no soportan llamadas recursivas, no pueden recibir parámetros, ni devolver valores de retorno. El tercer lenguaje, C3, agrega la posibilidad de que las rutinas devuelvan un valor, y pueden ser llamadas recursivamente. El lenguaje de alto nivel utilizado en este trabajo es una extensión del lenguaje C3, en la cual se incorporan primitivas de ejecución paralela, y se demuestra c´ omo puede implementarse la semántica operacional de este nuevo lenguaje, con primitivas del modelo Simplesem.

Contribuci´ on: El presente trabajo se basó en extender el modelo de Ghezzi y Jazayeri (que s´ olo estudiaba lenguajes monohilo), para abarcar también lenguajes con primitivas de ejecución paralela. La principal motivación fue la predominancia de los procesadores multicore, y la importancia que ha adquirido la programaci´ on concurrente actualmente. La propuesta consiste en la definición de un nuevo lenguaje de alto nivel, y la extensión del conjunto de instrucciones Simplesem para implementar la semántica operacional de dicho lenguaje. La ejecuci´ on paso a paso de un programa en un modelo multiprocesador es compleja, por lo que la heramienta cuenta con una interfaz gráfica de la máquina Simplesem, que permite seguir y controlar la ejecución de de las instrucciones de manera interactiva. El proceso de desarrollo constó de tres etapas. La primera consistió en la extensi´ on del modelo b´ asico monohilo, a un modelo multihilo. En la segunda etapa se definieron las instrucciones básicas simplesem que permiten la ejecución de programas paralelos. Finalmente, se definió la gramática de un lenguaje de alto nivel, con primitivas de paralelismo, cuya semántica operacional puede ser implementada con la extensión del modelo Simplesem.

1556

Importancia: Con la herramienta lograda al finalizar este proyecto, se ampliar´ a el campo de estudio del modelo Simplesem a lenguajes multihilo de ejecuci´ on paralela, de manera tal que aprovechando la simplicidad del modelo, podr´an estudiarse conceptos m´ as complejos inherentes a la programaci´on concurrente.

Desarrollo e Implementaci´ on

La utilizaci´ on del modelo Simplesem en el ámbito educativo ha demostrado tener buenos resultados en el proceso de aprendizaje de los lenguajes de programaci´ on de alto nivel. Sin embargo, dicha propuesta se limita sólo a lenguajes secuenciales, con un u ńico hilo de ejecución. Proponemos ahora una extensión del modelo para aplicarlo a la ense˜ nanza de lenguajes multihilo. 2.1.

Procesador multihilo

La primera extensi´ on se realiza sobre el dise˜ no del procesador de la máquina Simplesem. Podr´ an crearse hasta cuatro hilos paralelos. Las memorias de código de todos los hilos contendr´ an las mismas instrucciones, por lo que el comportamiento espec´ıfico deber´ a determinarse de acuerdo al identificador de cada hilo, de manera tal que cada uno ejecute sólo las instrucciones que le corresponden. La memoria de datos ser´ a compartida por todos los hilos. Cada hilo tendrá su propio puntero a instrucci´ on. 2.2.

Nuevas Instrucciones Simplesem

Para realizar una extensión a lenguajes paralelos, se agregaron nuevas primitivas al modelo Simplesem. processors n. Esta instrucción provoca que se creen n hilos, cada uno con su propio IP, y con una memoria de código independiente del resto. Al momento de su creaci´ on, todos los hilos estarán formados por las mismas instrucciones, y ser´ a el programador quien deba dotar de un comportamiento distinto a cada hilo. barrier. Cada vez que el procesador deba ejecutar la instrucción barrier de un hilo, deber´ a verificar si todos los otros hilos están en la misma instrucción. De no ser as´ı, la ejecuci´ on deberá bloquearse hasta que todos los hilos estén en la misma instrucci´ on. wait n. esta instrucci´ on es utilizada para lograr la implementación de semáforos a través de instrucciones Simplesem. Cada vez que una instrucción wait se ejecuta sobre la celda n de la memoria de datos, si el valor almacenado en la celda n es 0 la ejecuci´ on del hilo se bloquea. De no ser as´ı, se decrementa el valor de n en 1, y se continua con la ejecución.

1557

Esto podr´ıa hacerse a través de m´ ultiples, instrucciones Simplesem, pero la modificaci´ on de los permisos de un semáforo debe ser una operación atómica, por lo que se necesita una u ńica instrucción para tal fin.

numHilo. El indicador numHilo se utiliza como palabra clave dentro de las instrucciones Simplesem para referirnos al hilo que actualmente se est´a ejecutando. Cada hilo posee un identificador (de 0 a 3) que se utilizar´a para generar un offset de una posici´ on en la memoria de datos, para acceder a los datos que corresponden a cada hilo.

2.3.

Lenguaje C3P – Extensi´ on del Lenguaje C3

El enfoque abordado consiste en utilizar una variable paralela, que ser´a distinta para cada hilo que se ejecute. El resto de las variables, tanto globales como locales, son compartidas por todos los hilos. A continuaci´ on se presentan las incorporaciones que se hicieron al lenguaje C3, para generar un nuevo lenguaje al que llamamos C3P, con primitivas de ejecuci´ on en paralelo.

Sentencia par for. Suponiendo que i es la variable paralela (distinta en todos los hilos), la estructura de esta sentencia es: par_for 4 (i = 0; i < 8; i++){ suma = suma + i; } end_par_for; El n´ umero 4 representa la cantidad de hilos que quieren crearse. El l´ımite del ciclo for (en este caso 8) debe ser un n´ umero divisible por N (4), de manera tal que cada hilo procesar´ a 8 / 4 = 2 valores de i y los sumar´a al resultado final. Las instrucciones que se encuentren dentro del bloque par for ser´an ejecutadas por los cuatro hilos.

Sentencia barrier. Dentro de un bloque par for, necesitamos un mecanismo para sincronizar todos los hilos. Cada vez que un hilo encuentra una sentencia barrier, este se bloquea hasta que todos los otros hilos lleguen a la misma sentencia. En ese momento todos los hilos se desbloquean y pueden continuar su ejecuci´ on. Si colocamos una sentencia barrier debajo de la sentencia de suma del ejemplo anterior, todos los hilos terminar´an de procesar el primer valor de i antes de poder procesar el segundo valor.

1558

Sentencia wait. Para abordar problemas t´ıpicos de concurrencia (en los cuales se utilizan m´ ultiples hilos), debemos contar con construcciones como semáforos o monitores. Para ello, se incorporó la sentencia wait al lenguaje C3P. Esta sentencia se ejecuta sobre una variable, por ejemplo wait(i). Si el valor de la variable es mayor que cero, se disminuye en uno su valor y se incrementa en uno el contador de programa del hilo que ejecutó la instrucción wait. Si el valor de la variable es 0, el contador de programa no se modifica. Sentencia notify. La sintaxis de esta sentencia es notify(variable). Fue incorporada debido a que habitualmente se utiliza para incrementar en uno los permisos de un sem´ aforo. El efecto de la sentencia notify(i) es el mismo que el de la sentencia i++. Si alg´ un hilo se encontraba bloqueado por una instrucción wait sobre la variable i, al haberse incrementado el valor de esta u ´ltima, dicho hilo se desbloquear´ a. Funciones con par´ ametros. Otra de las funcionalidades con las que no contaba el lenguaje C3, eran funciones que recibieran parámetros. El lenguaje C3P incorpora la posibilidad de declarar funciones que reciban m´ ultiples par´ ametros. Los parámetros se guardan en el registro de activación al llamar a una funci´ on, antes de las variables locales de la misma. Los parámetros pueden utilizarse dentro de una función como si fueran variables locales. Restricciones del Lenguaje C3P: Para simplificar el proceso de compilación del lenguaje C3P, se realizaron dos simplificaciones respecto al lenguaje C3. En primer lugar, todas las variables son de tipo entero, ya que soportar otros tipos de datos implicaba que el compilador realizara una detección del tipo de datos, para realizar la reserva de memoria en función de esto. La segunda simplificaci´ on fue con respecto a las funciones. El lenguaje C3P s´ olo soporta la declaraci´ on y utilización de una u ńica función. Esto se debe a que incorporar m´ as de una funci´ on implica realizar un manejo de la tabla de s´ımbolos del compilador, para conocer la ubicación en memoria de las instrucciones y el tama˜ no del registro de activación de cada función. 2.4.

Implementaci´ on

La herramienta desarrollada se llevó a cabo en tres etapas: un proceso de formalizaci´ on del lenguaje C3P, la implementación del compilador y la implementaci´ on de la m´ aquina de ejecución abstracta (intérprete) de las instrucciones Simplesem. 2.5.

Formalizaci´ on del Lenguaje C3P

La primera etapa consiste en extender el lenguaje de alto nivel agregando sentencias a la gram´ atica del lenguaje C3. Las nuevas reglas de producci´on del lenguaje C3P se muestran a continuaci´on1 1

La gram´ atica completa del lenguaje C3P puede encontrarse en[3]

1559

assign ";" "read" "(" iden ")" ";" "write" "(" expr ")" ";" iterate condition "return" expr ";" "wait" "(" iden ")" ";" "notify" "(" iden ")" ";" call ";" parallel_statement comment

parallel_statement : parallel_for | "barrier" ";" parallel_for : parallel_for_beginning statement_block parallel_for_end parallel_for_beginning : "par_for" numbers for_definition parallel_for_end : "end_par_for" ";" 2.6.

Implementaci´ on del Compilador

Para la implementaci´ on del compilador, se utilizó lenguaje PERL, junto con el m´ odulo Parse::RecDescent [4], que permite implementar un parser descendente recursivo. Este m´ odulo provee una sintaxis para describir formalmente la gram´ atica de un lenguaje de programación. El compilador tiene como objetivo generar las instrucciones Simplesem que implementen la semántica operacional de un programa escrito en lenguaje C3P. Para tal fin, hace uso de un parser descendente recursivo que analiza el código fuente escrito en lenguaje C3P, genera elementos representables por instrucciones Simplesem, y finalmente obtiene dichas instrucciones. El parser recibe como entrada un programa escrito en lenguaje C3P y la gram´ atica del lenguaje. A medida que se van encontrando coincidencias del código fuente con las reglas de producci´ on del lenguaje C3P, se van generando las instrucciones Simplesem correspondientes. Cada producci´ on permite incorporar acciones, en las cuales tendremos acceso a los valores encontrados (es decir a los elementos de la sentencia que coincidi´ o con la regla en cuestión). Con el uso de estas acciones, se generan las instrucciones Simplesem en función de cada sentencia espec´ıfica. 2.7.

Implementaci´ on del Int´ erprete

Para la elaboraci´ on del int´erprete se utiliz´o lenguaje C++, junto con la biblioteca de clases Qt.

1560

El intérprete consiste de un editor de texto integrado, donde puede escribirse c´ odigo fuente, compilarlo y obtener las instrucciones Simplesem en una tabla que representa la memoria de instrucciones y la memoria de datos. Cuenta con controles que permiten realizar distintos modos de ejecución. Podemos procesar una instrucción de un hilo espec´ıfico, una instrucción de todos los hilos a la vez, o realizar una ejecución continua hasta que el intérprete encuentre una instrucci´ on halt. La Figura 1 muestra c´ omo se ve la interfaz gráfica del intérprete.

Figura 1. Interprete Simplesem con cuatro hilos ejecut´ andose en paralelo

Uso de la herramienta

El int´erprete cuenta con 6 ejemplos integrados que utilizan todas las primitivas del lenguaje C3P. Dichos ejemplos pueden ser cargados, modificados y compilados a instrucciones Simplesem desde la misma herramienta. Tanto el c´odigo

1561

fuente como versiones distribuidas para Windows, Linux y Mac OS pueden ser descargados desde el repositorio de la herramienta2 . El siguiente ejemplo muestra la implementación del problema de los filósofos (Dijkstra, 1965) en lenguaje C3P, para cuatro filósofos, cada uno de los cuales est´ a representado por un hilo.

var: tenedor range 1..4, filosofo range 1..4, j; program{ //Inicializacion de los semaforos (tenedores). for(j=0;j <= 3; j++){ tenedor[j] = 1; } par_for 4 (filosofo = 0;filosofo <= 3; filosofo++){ while(1 > 0){ if(filosofo == 3){ write(filosofo*10+1); //Pensando wait(tenedor[0]); //Toma los recursos wait(tenedor[3]); write(filosofo*10+0); //Comiendo notify(tenedor[3]); //Libera los recursos notify(tenedor[0]); } else{ write(filosofo*10+1); //Pensando wait(tenedor[filosofo]); //Toma los recursos wait(tenedor[filosofo+1]); write(filosofo*10+0); //Comiendo notify(tenedor[filosofo+1]); //Libera los recursos notify(tenedor[filosofo]); } } } end_par_for; }

Las instrucciones Simplesem del bloque paralelo de este ejemplo se muestran en la Figura 2.

https://github.com/lucaslt89/SimplesemExtension

1562

Figura 2. Instrucciones Simplesem del bloque paralelo en el problema de los fil´ osofos.

En el estado actual de ejecución, el filósofo 0 posee los dos recursos (tenedores); el fil´ osofo 1 se encuentra bloqueado esperando a que se libere un recurso; el fil´ osofo 2 tom´ o un recurso, y puede tomar el siguiente sin bloquearse; y el fil´ osofo 3 est´ a bloqueado esperando un recurso que adquirió el filósofo 1. Si bien todos los hilos poseen las mismas instrucciones, los hilos 0, 1 y 2 ejecutarán las instrucciones entre las celdas 20 y 25, y el hilo 3 las instrucciones entre las celdas 13 y 18. Esto se debe a que tres filósofos deben tomar los recursos en el mismo orden, y el cuarto los deber´ a tomar en orden inverso para evitar interbloqueos.

Conclusi´ on

El modelo de ejecuci´ on presentado por Carlo Ghezzi y Mehdi Jazayeri brindó una herramienta de gran riqueza educativa, simplificando la ense˜ nanza y el aprendizaje de conceptos fundamentales de los lenguajes de programación. Con el trabajo aqu´ı presentado, se logró extender el modelo para incorporar lenguajes paralelos, adem´ as de brindarse una herramienta que engloba de manera pr´ actica, todos los conceptos planteados teóricamente, desde la definición de un lenguaje hasta la ejecuci´ on de un programa escrito en dicho lenguaje sobre una m´ aquina Simplesem. El lenguaje de alto nivel planteado, el parser/compilador desarrollado, y la interfaz gr´ afica del modelo de ejecución, conforman una herramienta completa, que permite estudiar todas las etapas por las que atraviesa un programa escrito en un determinado lenguaje, desde que comienza a compilarse, hasta que finaliza su ejecuci´ on.

1563

La ejecuci´ on paso a paso de un programa paralelo en una interfaz gráfica, a través de la cual se puede interactuar con la máquina Simplesem, ayuda a la comprensi´ on de conceptos como el interbloqueo o la inhanición. Permite además analizar el impacto del acceso concurrente a la memoria de datos, y la manera en que los hilos de un programa paralelo deberán sincronizarse para ejecutar un programa de la manera esperada. En este trabajo, no se realizó un estudio sobre los beneficios a nivel educativo que la herramienta brinda, dejando esta tarea sujeta a una futura investigación. Si bien existen muchas mejoras posibles a la extensión planteada, consideramos que el trabajo realizado es de gran utilidad en el ámbito educativo, ya que brinda una manera pr´ actica de abordar el estudio de los lenguajes de programaci´ on y la relaci´ on que estos tienen con los recursos de la computadora.

Referencias 1. Carlo Ghezzi y Mehdi Jazayeri, Programming Language Concepts, Tercera edici´ on, 1996. Publicado el 23 de junio de 1997 por John Wiley & Sons. 448 P´ aginas. ISBN: 0471104264. 2. Sitio web oficial de Perl: www.perl.org Consultado en diciembre de 2012. 3. Lucas Leandro Diez de Medina Quintar. Extensi´ on del Modelo Simplesem a un Lenguaje Paralelo. Tesis de Grado disponible en http://goo.gl/9QwTJp – Publicada en Julio de 2013. 4. Parse::RecDescent Documentation. Disponible en: http://search.cpan.org/perldoc?Parse::RecDescent Consultado en diciembre de 2012.

1564

Conformando repositorios de datos de la comunidad educativa en la Universidad Nacional de La Plata Un caso de estudio. Javier Díaz1, María Alejandra Osorio2, Ana Paola Amadeo3 Laboratorio de Investigación en Nuevas Tecnologías Informáticas, Facultad de Informática, Universidad Nacional de La Plata Calle 50 y 120, 1900 La Plata, Buenos Aires. Argentina jdiaz@unlp.edu.ar, 2aosorio@cespi.unlp.edu.ar, 3pamadeo@linti.unlp.edu.ar

Abstract. Este artículo presenta las iniciativas llevadas a cabo por el CeSPI, el Centro Superior para el Procesamiento de la Información de la Universidad Nacional La Plata, respecto a análisis de información e integración de sistemas desarrollados ad-hoc para atender la complejidad y diversidad de las distintas realidades de la UNLP, o a través de implementaciones propuestas por el Ministerio de Educación de la Nación para la gestión universitaria. La construcción de repositorios consolidados de datos de alumnos, docentes y no docentes ha presentando nuevos desafíos relacionados con la confiabilidad de los datos y mecanismos de actualización, que han fomentado la revisión de procedimientos, el análisis de herramientas de big data y han traído aparejado beneficios en distintos niveles. Las redes sociales y los intentos de integración y análisis sobre ellas también son contemplados en este artículo.

Palabras Clave: análisis de información, integración de servicios, redes sociales, SAML, UNLP, Argentina

1 Introducción La Universidad Nacional de La Plata es una institución de educación superior pública, 3° en el país en cantidad de alumnos, según el Anuario Estadístico del año 2010.Está ubicada en la ciudad de La Plata, capital de la provincia de Buenos Aires, Argentina. Desde su fundación en 1905, es pionera en estudios y desarrollos culturales, artísticos y científicos de avanzada La docencia, la investigación y la extensión configuran los pilares básicos de esta Universidad. Agrupa a 17 Facultades de las ramas más diversas del saber, donde estudian más de 100 mil alumnos. En los últimos años se registra un promedio de inscripciones cercano a los 23.000 aspirantes, de los cuales se trasforman en alumnos alrededor de 18.500. De sus aulas egresan anualmente alrededor de 5.800 estudiantes. La oferta académica de la UNLP incluye 111 carreras de grado -157 títulos- y 170 de posgrado (el 85% están acreditadas o en trámite, por la Comisión

1565

Nacional de Evaluación y Acreditación Universitaria –CONEAU-), además de unos 500 cursos de posgrado. Además cuenta con 49 cátedras libres dependientes de la Presidencia, que se suman a las muchas que funcionan en las Facultades. En el pregrado, la oferta académica incluye cinco Colegios Preuniversitarios con una matrícula cercana a los 5 mil alumnos [1] El Centro Superior para el Procesamiento de la Información, de aquí en adelante CeSPI, es el centro de servicios informáticos de la UNLP. Su misión es Propiciar el uso y apropiación de las Tecnologías de la Información y Comunicación y los cambios sociales necesarios para su aprovechamiento, que contribuyan a mejorar las funciones de educación, investigación científica y tecnológica y extensión universitaria que desarrolla la Universidad Nacional de La Plata; aportando a una sociedad sostenible social y ambientalmente [2] Creado en 1959, su función es colocar a la tecnología al servicio de la Institución. En el Centro se realizan las tareas relacionadas con los distintos sistemas que brindan servicios a la Universidad. Estos sistemas comprenden la liquidación de sueldos de los empleados, el manejo curricular de los alumnos de las respectivas unidades académicas y la tarea que sostiene éstas actividades: la administración y el soporte técnico de la red de datos, los servicios de Internet y la propia infraestructura del Centro. En el año 2009 los procesos de Gestión de Requerimientos de Servicios e Información de Sistemas Académicos, y los Servicios de Auditoría y Consultoría Tecnológica, tuvieron reconocimiento internacional al certificar la norma de calidad ISO 9001:2008. Las certificaciones fueron concedidas por la organización especializada TÜV Rheinland Argentina S.A[3] dependiente de la alemana TÜV Rheinland Group tras haber verificado que el diseño y la implementación del sistema de gestión es el adecuado para la ejecución de los procesos y cumple con las exigencias de la norma. En el año 2010 y 2011 se han superado tanto las auditorías internas a cargo de un profesional calificado, como las externas de certificación y seguimiento por parte del organismo TÜV, con resultados altamente satisfactorios. En el año 2012, el alcance de la certificación comprendió a los procesos de Gestión de Requerimientos de Sistemas Académicos, de Seguridad de la Información, de Minería, Análisis de Datos y de Servicios de Auditoría y Consultoría Tecnológica. Cabe recordar que los procesos de Gestión de Requerimientos de Servicios e Información de Sistemas Académicos son los que actualmente utilizan todas las Unidades Académicas de la Universidad Nacional de La Plata. En el CeSPI se han desarrollado aplicaciones en respuesta a las crecientes demandas de una institución pública compleja, con un volumen importante de usuarios que generan numerosos requerimientos. Además de los alumnos, que según el último informe de indicadores del año 2012[4] suman 108.934 personas, se incluyen 12.056 docentes y 2.969 personal administrativo. En este contexto, es función del CeSPI garantizar la interconexión a través de las redes de datos hasta las aplicaciones que se utilizan para la operatoria diaria de la Universidad. En la figura 1 se presentan las distintas aplicaciones que da soporte actualmente, algunos por directivas del Ministerio de Educación y otros desarrollos propios. De estos últimos, la mayoría utilizan un mecanismo de autenticación Single Sign On implementado a través de SAML, que se detalla en el apartado 3 de éste artículo. Por otra parte, a través de la Dirección de Sistemas Académicos se trabaja en la implantación de software de código abierto como la plataforma virtual Moodle, el sistema de bibliotecas Koha-

1566

Meran así como también de otras soluciones implementadas por el Ministerio de Educación de la Nación, como el sistema de gestión académica SIU Guaraní y SIU Mapuche.

...

Fig. 1 – Integración de sistemas, desarrollados y/o mantenidos por el CeSPI, utilizando web services (flechas naranjas) o intercambio de archivos (flechas violetas). Todos estos sistemas generan información que se consolida en distintos repositorios: Guaraní Total para alumnos y Personas UNLP para alumnos, docentes y no docentes. Se relacionan también con las redes sociales en un límite difuso que se está desvaneciendo. 1567

La interrelación entre todos los sistemas facilita y promueve iniciativas para el análisis de la información en forma integrada, confiable y concreta para la toma de decisiones.

2 Análisis de la Información La Dirección de Sistemas Académicos del CeSPI incluye el área de Análisis de la Información. Surge a partir de la creciente demanda de analistas de información que permitan generar conocimiento a partir de los sistemas de gestión operativa que se utilizan hoy en día en toda organización, con distintos fines. Como mencionamos previamente, esta área ha certificado ISO 9001:2008 para la gestión de requerimientos de los usuarios en el último año. La ampliación del alcance de la certificación para incluir Minería y Análisis de Datos obedeció a la creciente demanda por parte de las entidades de gestión de las facultades y el propio Rectorado, de datos confiables, íntegros y consolidados para la toma de decisiones fundamentadas en cada unidad académica y la implementación de planes y políticas que afectan directamente a la comunidad educativa de estudiantes, docentes y personal administrativo. Además, la información recolectada por el área de Análisis de Información de Sistemas Académicos del CeSPI realiza informes periódicos al Ministerio de Educación a través del sistema SIU Araucano. Desde sus inicios, el CeSPI ha sido el responsable de almacenar y resguardar en forma adecuada la información gestionada por los sistemas de gestión operativa de la universidad, siendo responsable de los reportes emitidos sobre los mismos a partir de solicitudes realizadas por agentes internos o externos, como el Ministerio de Educación de la Nación o el Poder Judicial para verificación de datos. La evolución de los distintos sistemas de información, la diversificación de los mismos, personas usuarias de distintas aplicaciones y las necesidades de información, por parte de los altos mandos directivos que permitan realizar análisis multidimensionales para la toma de decisiones, ha hecho imprescindible trabajar en un repositorio consolidado de datos del mismo sujeto, el estudiante, almacenados en los sistemas de gestión operativa de uso diario en la universidad. En particular, en la UNLP se utiliza el sistema SIU Guaraní desde el año 2002, en 15 de las 18 facultades, en 3 direcciones de postgrado y capacitación no docente. El SIU Guaraní es un sistema desarrollado por Consorcio SIU de Universidades, que desarrolla soluciones informáticas para el Sistema Universitario Nacional y organismo del gobierno. Su objetivo es colaborar, a través de los sistemas de información confiables y seguros, con el mejoramiento continuo de la gestión: optimizar los procesos, la calidad de los datos y facilitar la toma de decisiones contando con una sólida base de información. [5] El SIU Guaraní es una de las soluciones ofrecidas para gestionar todas las actividades académicas de las universidades nacionales, desde que los alumnos aspiran a formar parte de la universidad hasta que egresan con su diploma, contemplando la complejidad y heterogeneidad del sistema universitario nacional [6]. Actualmente se encuentra implementado en más de 200 unidades académicas de todo el país. La implementación del Guaraní implica un proceso de depuración datos analizando los repositorios académicos históricos (dependiendo de las Facultades tienen en línea información de los últimos 20 y hasta 50 años). Durante los meses de febrero y marzo

1568

se registran las actividades más intensivas, a través de las inscripciones a los cursos de dictado regular del ciclo lectivo. Durante los meses de febrero y marzo de este año a través del sistema se registraron más de 311318 inscripciones. El SIU Guaraní se integra en forma natural con otros sistemas desarrollados por el SIU como el SIU Araucano, SIU Data Warehouse y SIU Kolla. Además de estas soluciones propias, en distintas unidades académicas se utiliza el sistema de código abierto Moodle [7] para la gestión de cursos virtuales, en general como complemento de la actividad presencial. Este sistema está integrado con el sistema SIU Guaraní a través de una interfaz común, que facilita la gestión de las inscripciones a trabajos prácticos entre ambos sistemas. El sistema Moodle se utiliza en la Facultad de Informática desde el año 2005, incluyendo más de 310 cursos y más de 14000 usuarios. Puede consultarse a través de http://catedras.info.unlp.edu.ar, http://cursos.linti.unlp.edu.ar y http://postgrado.linti.unlp.edu.ar La información almacenada en este sistema involucra entregas de tareas, participación en los foros, acceso a los diferentes recursos y demás registros los cuales, al cruzarlos con el desenvolvimiento académico pueden resultar en datos significativos para la toma de decisiones de los directivos de la Facultad. Otras unidades académicas como la Facultad de Ingeniería, de Ciencias Veterinarias, de Ciencias Económicas y Ciencias Médicas también utilizan Moodle como plataforma virtual en sus cursos presenciales. Por otra parte, para la gestión de la biblioteca se utiliza el sistema de software libre Meran[8], desarrollado por el equipo de desarrollo del CeSPI a partir de Koha [9], el sistema de SL para la gestión de bibliotecas implementado en distintas facultades de la UNLP a partir del año 2003. Este sistema permite gestionar los procesos bibliotecarios y los servicios a los usuarios, como estantes virtuales para las cátedras, la posibilidad de votar un libro o dar recomendaciones. Todo esto integrado también al sistema SIU Guaraní. La UNLP y muchas de sus unidades académicas están haciendo uso de las redes sociales para poder llegar a los distintos sectores de la sociedad que están vinculados con ella y de esta manera realizar una mejor difusión de las actividades que se llevan a cabo. En el caso de la UNLP, dispone de un perfil en Facebook, Universidad.Nacional.La.Plata, con más de 5800 seguidores. La Facultad de Informática posee también cuentas en FB y Twitter para difusión académica como @InformaticaUNLP con más de 1100 seguidores, @infounlp con más de 500 seguidores entre otras. Además, ciertas cátedras utilizan estos canales para comunicarse con sus estudiantes, como la cátedra de Algoritmos y Estructuras de Datos @ayed_fi, Introducción a los Sistemas Operativos @iso_info_unlp con más de 100 seguidores, Sistemas Operativos, entre otros. Como se puede observar, se cuentan con distintas fuentes de información relacionadas con el mismo sujeto, el estudiante, que consolidadas en único repositorio permitirá realizar análisis transversales, que sirvan de insumo a grupos interdisciplinarios con distintos perfiles. Esta realidad hace imprescindible aplicar distintas metodologías para la constitución de un Data Warehouse que soporte las distintas estrategias y técnicas para obtener conocimiento a partir de los datos almacenados en distintos sistemas. La construcción de un DW involucra una serie de actividades relacionadas con distintas técnicas para la Extracción, Transformación y Carga soportadas por distintas herramientas como Kettle de Pentaho BI[10], Spago BI[11], Talend BI[12], entre otras. La naturaleza del negocio determina los requerimientos de los usuarios

1569

que en este caso están relacionados con rendimiento académico, comportamiento en entornos virtuales y redes sociales. Respecto al primer punto, rendimiento académico, se está trabajando en los cubos de análisis de información provistos por el SIU. La información base se toma del sistema SIU Guaraní. En el inicio de la implementación de los cubos de análisis de información, se utilizaba la herramienta O3[13]. Los datos eran tomados directamente de las bases de datos productivas en los momentos en que se registraba menor actividad, en general los fines de semana. A medida que el tamaño de las bases de datos aumentaba y el sistema se comenzó a utilizar en un régimen de 7x24 a través de las interfaces Web, se hizo necesario contar con una instancia replicada, imagen de las bases de datos productivas al primer sábado de cada mes, para generar los cubos de análisis estadísticos y reportes ad-hoc. Para reportes concretos en línea, se continuaba tomando los datos de las BD productivas. La integración con otros sistemas y la necesidad del desarrollo de nuevos data marts que integren los datos de todas las unidades académicas hizo imprescindible la construcción de un Data Warehouse. Para esto se utilizó la metodología propuesta por Kimball[14] basada en la construcción de pequeños data marts específicos para las distintas áreas de la organización. Es así como hoy se cuenta con un repositorio de información académica que centraliza los datos de todos los alumnos de la universidad, en la figura 1 SIU Guaraní Total, que interactúa con el Sistema Integrador, en la figura 1 Personas UNLP, para proveer información de egresados, situación académica y actividad en general. Además permite obtener reportes ad-hoc en forma rápida y eficiente [15] [16] Mantener actualizado el Data Warehouse fue otro punto de análisis y debate. El análisis y discriminación de la información que debía estar actualizada en forma diaria y cual no fue el primer paso. En un primer momento el Data Warehouse se actualizaba cada semana. El costo de esta actualización era muy elevado en cuanto a tiempo de procesamiento y calidad de la información obtenida. Es así como se comienza a analizar herramientas para optimizar el proceso de ETL. Pentaho BI, herramienta de software libre para BI es la seleccionada por el MEN para su grupo de trabajo y es adoptada por el equipo de Sistemas Académicos. Es así como se utiliza Kettle para contar con una vista centralizada de estudiantes, carreras y planes de estudio y egresados actualizada en forma diaria. El análisis de las variables a mantener en el Data Warehouse y el grado de actualización de cada una de ellas, evidenció la necesidad de modificar los sistemas de gestión para poder trasladar al DW sólo los últimos cambios realizados, día a día. Uno de los problemas detectados en la puesta en producción de esta etapa fue el alto índice de correcciones de datos residentes en los sistemas de gestión. Esto es producto de la visualización de la información por parte de los estudiantes a través de la Web y la integración con otros sistemas que requieren de datos confiables y de calidad. Esta realidad llevó al equipo a planificar actividades específicas relacionadas con calidad de datos. Por otro lado, la aplicación de técnicas de minería de datos permitirá identificar los diferentes perfiles de los estudiantes y egresados, ayudando a comprender mejor su comportamiento en las plataformas virtuales y las redes sociales, para implementar distintas propuestas educativas, por ejemplo aquellas que los asistan para completar sus estudios como es el caso de la Facultad de Informática [17]. El estudio sistemático de los estudiantes desde diferentes perspectivas se puede encontrar en numerosos

1570

trabajos llevados a cabo en el país y en el mundo [18] y [19] Sin embargo es interesante complementar estos análisis incorporando idiosincrasias propias de la universidad local y de una Facultad en particular. Los primeros avances en esta línea se están llevando a cabo utilizando Weka Waikato Environment for Knowledge Analysis[20], es una herramienta visual de libre distribución (licencia GNU) desarrollada por un equipo de investigadores de la universidad de Waikato (Nueva Zelanda). La información utilizada en el proyecto de minería que se está llevando a cabo actualmente toma de los datos almacenados en la plataforma virtual y el sistema de bibliotecas, y distintas vistas del DW y utiliza Weka para aplicar las técnicas de minería que permitan obtener conocimiento de estos mares de información. El grado de aprovechamiento de la información minada por parte del usuario final depende en gran medida de una correcta visualización y una interfaz amigable de interacción. Por este motivo se prevé el desarrollo de aplicaciones ad hoc para facilitar las consultas de los usuarios finales. Asimismo, la tendencia en el avance de la tecnología que ha abierto las puertas hacia un nuevo enfoque de entendimiento y toma de decisiones, la cual es utilizada para describir enormes cantidades de datos (estructurados, no estructurados y semi estructurados) que tomaría demasiado tiempo y sería muy costoso cargarlos a un base de datos relacional para su análisis. De tal manera que, el concepto de Big Data aplica para toda aquella información que no puede ser procesada o analizada utilizando procesos o herramientas tradicionales. Esta tecnología se encuentra en pleno desarrollo, encontrando soluciones open source que es necesario estudiar e investigar en forma sistemática para obtener resultados comparativos que sean de utilidad. Podemos mencionar aquí herramientas que realizan analytics en memoria, por ejemplo el streaming processing que realizan empresas como Linkedin, Groupon a través de aplicaciones como Storm[21] y Kafk[22]; o Drill[23] y Dramel[24] para la exploración de datos. D3[25] es otra aplicación muy poderosa para crear tableros interactivos en forma rápida y eficaz visualmente. El volumen de información gestionado actualmente en los distintos sistemas de gestión académica, sumado al estudio del comportamiento de los alumnos en las redes sociales y las plataformas virtuales, hacen imprescindible encaminar investigaciones en esta dirección. Además permitirán extender el análisis a datos de toda la universidad y facilitar la integración las bases de datos abiertas de organismos públicos aplicando las técnicas y herramientas analizadas sobre esta temática.

3 Integración de Sistemas En TICAL 2012[26] se hizo referencia a las soluciones desarrolladas ad-hoc para la gestión operativa de la Universidad. Por ejemplo el CMS Choique de código abierto con licencia GNU liberado en el año 2012, el sistema de gestión de Licencias Médicas, de Expedientes y de Becas entre otros , cada uno de ellos con su usuario y clave de registro que se validan contra un determinado dominio. Los empleados de la UNLP pueden tener distintos roles, y para cada rol acceder a distintos sistemas. Por ejemplo un docente puede acceder a la plataforma virtual que utiliza su facultad así como también al sistema de gestión de alumnos y consultar su recibo de sueldo, solo

1571

por citar algunas aplicaciones. A su vez esté docente puede desempeñarse en alguna oficina de la unidad académica y acceder a un sistema para realizar su trabajo, también con usuario y clave. Es así como los roles de una persona se diversifican así como también la cantidad de usuarios y claves que debe recordar. Es así como se hizo imprescindible implementar un mecanismo de control de acceso centralizado o Single Sign On, a un conjunto de aplicaciones relacionadas pero independientes, que dialogan entre ellas a través de Internet, más allá de las tecnologías subyacentes propietarias o no. Un usuario se registra en una de las aplicaciones y gana acceso a todas las demás aplicaciones relacionadas. En el ultimo año se trabajó en migrar el registro de estas aplicaciones para soportar la autenticación centralizada basada en SSO. Como mecanismo se adoptó SAML Security Assertion Markup Language, protocolo estándar para la comunicación de identidades a través de Internet. Es un mecanismo de Single Sign On basado en XML, para comunicar autenticación o identidad, derechos o permisos y atributos de un usuario entre distintas entidades. [27] La versión 2 de este protocolo, liberada en el año 2005, es un conjunción entre distintas iniciativas de OASIS Organization for the Advancement of Structured Information Standards y Liberty Alliance Federation Framework. SimpleSAML[28] es una implementación del protocolo, que se ocupa de la autenticación, escrita en PHP Como proveedor de identidad se implementa el Sistema Integrador de Datos de la UNLP, en la figura 1 Personas UNLP. Este sistema permite centralizar la información de alumnos, docentes, no docentes y autoridades mediante la integración de datos que provienen de los siguientes sistemas: SIU-Guaraní, Sistema Integrado de Registro de Alumnos y Sistema de Personal (liquidación de sueldos). Esta base de datos es utilizada para alimentar a otros sistemas desarrollados por el CeSPI que tienden a facilitar la administración de los recursos humanos de la Universidad Nacional de La Plata. El Sistema Integrador de Datos busca reunir toda la información de la comunidad universitaria para normalizarla, articularla y hacerla accesible. El sistema responde a los problemas de administración de recursos humanos que están teniendo todas las organizaciones. Con este desarrollo se intenta consolidar la información para evitar errores y repeticiones. Actualmente la información es utilizada por otros sistemas desarrollados en el CeSPI : • Sistemas de salud universitaria: que se compone de dos aplicativos destinados al área de salud y a los profesionales médicos de la UNLP. • Sistema de Libretas Universitarias: se encarga de la digitalización de las libretas sanitarias estudiantiles y el seguimiento sanitario e historias clínicas de los alumnos. • Sistema de Carpetas Médicas y Controles Periódicos: facilita la gestión de solicitudes de carpetas médicas del personal docente y no docente de la UNLP. Las carpetas médicas se solicitan a través de Internet posibilitando que esta actividad tome un carácter centralizado. El médico recibe una planilla con todos los datos del paciente y un plano, realizado a través de Google Maps, para que ubique fácilmente el domicilio pertinente. Finalmente, este sistema permite llevar un registro de los controles periódicos. • Sistema de inscripción a Becas: Este sistema, desarrollado para la convocatoria a becas de noviembre de 2010, fue el primero en integrarse al

1572

•

Sistema Integrador de Datos. El mismo facilita la asignación de las becas que otorga la Dirección de Asuntos Estudiantiles de la UNLP a los estudiantes que las requieran. Incluye al sistema de Albergue estudiantil gestiona el ingreso y egreso de los estudiantes al Albergue Estudiantil de la Universidad Nacional de La Plata. Sistema de recibo de sueldos

Actualmente, se están estudiando distintas estrategias y herramientas para garantizar la calidad y disponibilidad del Sistema Integrador de Datos, por ejemplo técnicas de Big Data y herramientas de ETL alternativas a Kettle de Pentaho BI Además, se amplían los servicios ofrecidos a través de la API Rest que consulta los sistemas de gestión académica SIU Guaraní. La primera experiencia de integración con el sistema de gestión de Títulos ha abierto la puerta a la integración con otros sistemas como las Libretas Sanitarias y la inscripción a cursos de postgrado de la Especialización en Docencia Universitaria. Como mencionamos anteriormente, las redes sociales constituyen una realidad que no es ajena a la comunidad universitaria. En la Facultad de Informática se ha desarrollado el módulo TAM, Twitter Activity Module https://github.com/mcharnelli/moodle-module_twitter que permite relacionar un curso de Moodle con una cuenta de Twitter y a su vez con una cuenta de Facebook, utilizando el protocolo OAuth[29] Asimismo, el CMS Choique permite incluir bloques de Twitter como parte de los portales que administra. Es interesante entonces estudiar estos bordes y la información que fluye hacia y desde las redes sociales utilizando herramientas como HootSuite[31] y TweetDeck[32] a fin de obtener y generar información significativa para la gestión.

4 Conclusiones Las ventajas de la interoperabilidad y la potencia/versatilidad de las herramientas de extracción para construir repositorios intermedios son dos de los ejes que permiten expandir los horizontes de los sistemas de la UNLP y crear nuevas funcionalidades como describe el artículo. En particular se favorece la interacción entre los distintos sistemas de la propia universidad, así como interactuar con los sistemas del SIU que consolidan información a nivel Ministerial y respetar los estándares de interoperatividad de las principales redes sociales como Google+, Facebook y Twitter. La generación de repositorios intermedios permite proveer nuevos servicios gerenciales y de servicio de consulta sin afectar la performance de aplicaciones masivas como el sistema de alumnos. La interconexión de los sistemas por otra parte simplifica procesos administrativos, ahorra papel y genera una auditoria automática en procesos críticos de la Universidad como emisión de diplomas La evolución de la tecnología ofrece potencialidades que cuando se incorporan a los sistemas en uso (legacy) los agiornan y permiten no solo incorporar nuevas funcionalidades sino también simplfiicar accesos, cantidad de pasos e interfaces.

1573

Referencias [1] Portal de la Universidad Nacional de La Plata. http://www.unlp.edu.ar/institucional Última visita 28 de abril 2013 [2] http://cespi.unlp.edu.ar Última visita 27 de abril 2013 [3] http://www.tuv.com/es/argentina/home.jsp Última visita 20 de abril 2013 [4] http://unlp.edu.ar/articulo/2011/11/17/anuario_de_indicadores_2012 Última visita 20 de abril 2013 [5] http://siu.edu.ar Última visita 22 de abril 2013 [6] http://www.siu.edu.ar/nuestras-soluciones/gestion-academica-2/siu-guarani-2 Última visita 27 de abril 2013 [7]http:// moodle.org Última visita 25 de abril 2013 [8] http://www.cespi.unlp.edu.ar/meran Última visita 27 de abril 2013 [9] www.koha.org Última visita 26 de abril 2013 [10] http://www.pentaho.com/ Última visita 28 de abril 2013 [11] www.spagobi.org/ Última visita 28 de abril 2013 [12] http://www.talentanalytics.com Última visita 27 de abril 2013 [13] http://www.ideasoft.biz/ Última visita 26 de abril 2013 [14] The Data Warehouse Lifecycle Toolkit, 2nd Edition: Practical Techniques for Building Data Warehouse and Business Intelligence Systems. John Wiley & Sons, 2008 [15]http://www.ing.unlp.edu.ar/institucional/difusion/2012/ingreso_retencion Última visita 10 de marzo 2013 [16] http://www.econo.unlp.edu.ar/caracterizacion_aspirantes Última visita 10 de marzo 2013 [17] http://www.info.unlp.edu.ar/articulo/2010/7/19/info_secretaria_academica Última visita 12 de marzo 2013 [18] http://www.datapr/ix.com/blogs/gpautsch/resumen-mi-tesis-miner-datos-aplicadalisisdeserci-n-carrera-analista-sistemas-compu Última visita 12 de abril 2013 [19] www.utim.edu.mx/~svalero/docs/MineriaDesercion.pdf Última visita 19 de marzo 2013 [20] http://www.cs.waikato.ac.nz/ml/weka/ Última visita 29 de abril de 2013 [21] storm-project.net Última visita 27 de abril de 2013 [22] http://kafka.apache.org/design.html Última visita 27 de abril de 2013 http://www.ibm.com/developerworks/ssa/local/im/queesbig-data/index.html Última visita 25 de abril de 2013 [22] http://kafka.apache.org/design.html Última visita 25 de abril de 2013 [23] http://gigaom.com/cloud/for-fast-interactivehadoopqueries-drill-may-be-the-answer/ Última visita 25 de abril de 2013 [24]http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/e n/us/pubs/archive/36632.pdf Última visita 25 de abril de 2013 [25] http://d3js.org Última visita 25 de abril de 2013 [26] http://tical_2012.redclara.net/es/presentaciones.html Ultima visita 25 de abril de 2013 [27] http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language Última visita 25 de abril de 2013 [28] http://php.net/manual/es/book.simplexml.php Última visita 25 de abril de 2013 [29] https://github.com/mcharnelli/moodle-module_twitter Última visita 25 de abril de 2013 [30] http://oauth.net/ Última visita 20 de abril de 2013 [31] http://hootsuite.com/ Última visita 25 de abril de 2013 [32] http://tweetdeck.com/ Última visita 26 de abril de 2013

1574

EXPIRIENCES WITH EDUCATIONAL ROBOTIC Anibal Lopes Guedes1, Fernanda Lopes Guedes2 1

Professor at Univerisidade Federal da Fronteira Sul â&#x20AC;&#x201C; UFFS. Master in Computer Science. 1 Professor at Instituto Federal Sul-Rio-Grandense â&#x20AC;&#x201C; ISUL. Master in Computer Science. {anibalguedes, fernandalguedes}@gmail.com

Abstract. Educational Robotics has come to prominence in recent years because it allows to articulate a more playful and interactive teaching. It works the abstract in concrete basis, and this way stands as a new methodology of teaching and learning. Therefore, this article seeks to present educational initiatives that use robotics in elementary schools, located in western Santa Catarina and northern Rio Grande do Sul. For that, we used the Lego Mindstorms NXT robotic kit. As result, it was found that the technology enables the insertion, integration, interaction, discussion and cooperation between students, teachers and employees, which somehow permeates individual and collective development, providing opportunities for improvements in the educational processes. Keywords: Educational Robotics. Constructionism. Robotic. Automation. Lego Mindstorms NXT.

1 INTRODUCTION Education leads us to a series of situations, practices and policies that bind the area itself [2]. In this perspective, it is possible to highlight the importance of transformational technologies that offer educational processes, serving as support for the proposals developed, contributing to changes in the social and cultural dynamics of individuals. In this sense, [3, 4, 5] is stated that it is up to the task of the educators to plan and introduce such technologies in school life. The computer is not only to perform human tasks such as to add, process and teach, but also to require the development of cognitive and meta-cognitive skills of each individual through learning situations that enable a better understanding of the world in which we live in[6]. The author states that technologies have a transformative approach, since: They alter the structure of interests of each individual; Change the thinking of each individual; Alter the nature of the community.

1575

Corroborating this proposal, [7] he states that technology should promote the development of basic skills and cognitive abilities of their users, explore learning in an interactive and playful way, allowing people to new educational processes, new experiences, new discoveries and new ways of learning. Thus, the robot is attractive as a means [8], “invites teachers and students to teach / learn / discover / invent in collective processes, capable of connecting abstraction and concrete world.” Through them, you can explore the area of robotics in an educational manner, coming to join efforts to make school life more challenging, creative and focused on the processes of teaching and learning. The use of robotics in the classroom, according to [9], provides that "teachers escape the blackboard and that lessons become more dynamic thereby arousing the curiosity of students," setting up what could be called technological literacy. In Brazil, projects conducted by the Educational Robotics, are yet isolated initiatives. There is still a look that directs efforts to robots that can support the school setting as a means to include the Computer within other disciplines such as Mathematics, Physics, Biology, Portuguese and others [5]. From their research on the use of educational robotics, [8] it pointed out that: “Countries such as the Netherlands and Germany have already robotics [...] 100% of public schools. England, Italy, Spain, Canada and the United States go in the same direction. Some Latin American countries have adopted their first strategies nationwide. This is the case, for example of Mexico and Peru.” [10] claim that the university is a place of production significant social and technological initiatives that are carried out in this case study on Robotics in Education, in order to: Knowing closely the social reality of the public attended in order to modify it; Provide the qualification of the citizen; democratize access to knowledge gained to improve the quality of life of citizens; Encourage scientific research; Promoting citizenship and democratic values to the different social actors who are involved directly and indirectly in the shares. Thus Robotics Education opens unexplored possibilities for the field of education and to the field of research, transforming educational settings. So, this paper aims to present considerations of Robotics, Robotics Education, present the Lego Mindstorms NXT robotic kit, and show initiatives in education level and extent applied with students of the initial series. Finally, the text helps to diversify the work done by the teacher, and this will have available a means versatile, able to cause a modification of traditional culture and organization of the school, contributing the learning of their students.

2 ROBOTICS An easy way to comply with the conference paper formatting requirements is to use this document as a template and simply type your text into it. Robotics is a branch of technology that includes mechanics, electricity, electronics and computing, which deals with systems composed of mechanical parts and machines: automatic and controlled by integrated circuits, making mechanical motorized, controlled manually or automatically by electrical circuits [11].

1576

The term robotics was created by science fiction writer Isaac Asimov in his novel "I, Robot", 1948 [11]. The word “robot” was first used in 1921, a play that was titled RUR - Russum's Universal Robots, Czechoslovakia, written by Karel Capek. In Czech, the word “robota” means work and was used in the sense of a robot machine to replace human labor. The difference between a computer and a robot is districted by its power to interact with the world. The computer does not start without human operation. Thus, robot is considered an intelligent mechanism that works autonomously [11]. From the 80, the Robotics is advancing at great speed and, among numerous projects, ASIMO, initiated in 1986 by the Honda Motor Company, to get highlighted. Contrary to what it may seem, his name was not created in homage to the science fiction writer Isaac Asimov, but is derived from Advanced Step in Innovative Mobility. Just like ASIMO, the Qrio, Sony, and Robonaut robot created by NASA to assist astronauts on the International Space Station performing extra vehicular activities, are also quite relevant. The three are cited as humanoid robots designed to interact with humans [12, 13]. Besides these, [14] presents the home robot NAO, which can recognize the face of a person and interact in conversation. RI-MAN and RIBA II are other examples of robots that provide assistance to a person’s body. Something that caught our attention is that “the Internet has proved valuable in providing access to similar lines of research, sharing open source materials and facilitated exchange of opinions and resources, which benefits the improvement of technologies.” [14, 15]. Thus, the next section presents considerations regarding one of the areas that benefit most from the Robotics, in this case, Education.

3 EDUCATIONAL ROBOTIC The technologies are important tools for studying and research in the learning process, as they provide conditions to both teachers and students working from themes, projects and extracurricular activities. [16] states that the computer is a medium that develops attention, perception and creativity. Corroborating this idea [17] states that the computer is like “a machine [...] that allows to test ideas or hypotheses, leading to the creation of a world abstract and symbolic that at the same time allows you to enter different forms of operation and interaction between people.” This is a device that is increasingly diverse in functions, contributing significantly to an increase in productivity, cost reduction and optimization of product quality and services. For this reason that the school should support projects where the computer presents real situations to students in order to make your learning fun and engaging, the example cited is Educational Robotics. The Robotics Education and teaching, named, “[...] encourages creativity students due to its dynamic nature, interactive and even playful besides serving as a motivator to stimulate students' interest in traditional teaching.” [18].

1577

It is characterized as an environment in which students can “program” and “build” your robot. “The ease of installation and programming of robots, articulated piece sets and intuitive programming interfaces can be identified as factors that [...] put in a field of robotics accessible to educational purposes.” [19]. The advantages of Educational Robotics are very significant. Among the benefits are: interdisciplinary, the expansion of content already worked in the classroom and, what is more important, the learning achieved through group work, since the study phase. Principles of teamwork and cooperation, which are required in professional practice, skills are developed in students from the Robotics projects [20]. In this way, we use the cognitive model of the Theory of Multiple Intelligences (MI), proposed by Gardner [21] which describes for the coexistence of multiple intelligences. Thus, relating the theory of IM with Educational Robotics have: • linguistic intelligence - students can express themselves through words as a robotic experiment passed or that was developed; • logical-mathematical intelligence - students can reason about how to solve the problem by means of the robot and how to program it; • spatial intelligence - the student can understand how the pieces fit the robot to assemble the robotic structure (visual perception); • kinesthetic intelligence - the student can, by means of somatic sensations obtained through sensors, articulate his/her robot to obtain elements for analysis; • musical intelligence - the student can, through rhythms and melodies, listening posts, sounds and music via robot; • inter-personal intelligence - work as a team with the involvement of the group, assembling, programming and the use of the robot; • intra-personal intelligence - the ability to act adaptively meets the challenge presented; • naturalist intelligence - the ability of interaction between the student and the environment, in this case, using recyclable artifacts. Projects addressing the theme of Educational Robotics develop in several segments, geared mostly to high school and vocational education. [21] states that there are few projects articulated with the elementary school. The author states that there are few institutions in fundamental level that include content related to technology education into their curricula. Among the projects using robotics as learning environment IN Brazil: • Technological Education - it's a project that allows experience knowledge in areas such as Physics, Biology, Mathematics and Language, through the assembly and programming of robotic kits. The project is carried out in primary and secondary schools in Feira de Santana, Bahia [23]; • Educational Robotics in High School - its experiments are performed between the disciplines of Geography, Mathematics and Programming by robots. Project developed in Blumenau - Santa Catarina [24]; • Educational Robotics in UCA - the project aims to analyze “technical activity as symbolic and creativity from the field of possibilities of modeling and programming in the context of design prototypes UCA.” [25]. The project took place in Porto Alegre (Rio Grande do Sul) with public and private schools from elementary and high school.

1578

At the level of the technological resources available in the market to work with robots, there are free solutions and cost as the Arduino, the GoGoBoard the xBot, among others. Already in level sets (kits) and manufactured commercial, there is the Lego Mindstorms NXT, the Fischertechnik, Parallax, among others. [20] points out that the basic difference between commercial complexes in relation to free ones, are: number of parts (gears, motors, etc.). In this aspect of low cost kits contain a limitation on the number of its parts; Collection of alternative materials. In this aspect both kits cost as commercial or manufacturing allow the customization of parts; Technical knowledge of electronic and mechanical modelling. In this aspect kits that require low cost to learn a specific programming in accordance with the kit purchased. Based on the questions listed by [20], in the next section, we present some considerations about the commercial kit Lego Mindstorms NXT. The kit was chosen because it contains a simple programming interface and iconic, many examples available on the website http://www.nxtprograms.com plus numerous parts such as gears, motors and sensors support [26].

4. PROPOSALS DEVELOPED WITH EDUCATION AND ELEMENTARY SCHOOL

CHILDHOOD

As the authors [28], the school is one of the most important social institutions, because it is the link that mediates the interaction between the individual and society, allowing that the child can take ownership of values and social models, with direct repercussions on their autonomy. Therefore, the technology is part of this link, as it allows them to adopt actions that facilitate the educational process. In this sense, the Educational Robotics in schools aims to provide students with the awakening of logical reasoning, creativity, autonomy in learning, understanding concepts and improve coexistence group, treating cooperation, planning activities and tasks [29]. Thus, in Section III set out examples in Brazil's level of technological use of robotics in the classroom. Obviously, corroborating [8] the area is still shy and lacking in trained professionals at both technological as teaching. However, it is at this time showing initiatives experienced by researchers in level of education and outreach. The proposals are summarized here from the work: [30, 31, 32]. In both projects we used as instruments to direct observation of school and classroom intervention, a second time. The observation has the advantage of identifying the facts directly, without any intermediary, as indicated by [33], it is a simple methodology and systematic. Thus, the first step involved the analysis of impactual technologies, especially robotics in schools. Therefore, there was an informal contact with representatives of schools, these included teachers and principals in order to realize their positions through technologies. This contact allows us to understand how the robot can interfere with the educational process, since, according to statements summarized, â&#x20AC;&#x153;[...] it is a mechanism to aid the teacher, it enhances the process of child development, is

1579

attractive, is a motivating tool that arouses interest, changes the dynamics of teaching and learning, motor elaborates on the student, a different way to share their knowledge with students and can open many doors for these children who are starting school life.” The next step in the study provided the Lego Mindstorms NXT robotic kit in order to analyse and understand their use, operation and programming. The robot was chosen because it is a line of Lego toys released by the company, focused on technology education, and for being a technology widely used in the process of teaching and learning in schools. [27] posits that humans learn best when they are engaged in building something that he can show to other people and that is meaningful to him. These computing environments, especially Robotics, contribute to this way of thinking constructionist, because students engage and interact with the development of projects. The study on the Mindstorms Lego NXT kit is considered with step observation of classes in schools - presented in the sequence, where the idea is: a) to investigate the teaching practice, directly observing how the activities are developed, explored and its relevance to students; b) analyse the relationship between student and teacher in the classroom. From the analysis of reality and the school plan for each school, went to trial activities in technological level. For this, we used the flowchart first proposed by [30]. In this case, the flowchart is composed: Name - name of the experiment; Objective(s) - highlight the educational purposes; Discipline(s) - experiment (s) intended; Materials used - detailed description of physical materials for the experiment; Description of the stages - description of the step by step to the realization of the activity. From the structure of the experimental projects using the Lego Mindstorms NXT robotic kit, went up to the stage of intervention in school. The intervention process has the intention to facilitate the “problematic at collective practices of training and enhancing the production of a new think / do education.” [34]. The intervention included the formation of teachers and other legal representatives of schools, through workshops, so that they can meet the robotic kit and check usability. After that, it went to the training and validation of the project with the students. Finally, the initiatives have great concern for the educational processes of human development. Following considerations and presenting peculiarities of each initiative indicated with the results obtained. 4.1 Iniciative Kerber The initiative [30] was applied in Ambial Project, Escola de de Educação Básica São Lourenço, in the municipality of Iporã do Oeste-SC. The project aims to promote the inclusion of pedagogical actions socio-environmental, mitigating the problem of hunger, education and sustainability of the students. [30] applied his work against the shift of student activities. As the study areas, highlight Sciences, Mathematics and History. Among the experiments developed and applied:

1580

• Interactive Game - the idea of the game is to interact with the Lego Mindstorms NXT robot. In the game there is a specific symbol that appears in the central controller. Thus, the student is invited to interact selecting between the buttons contained in the controller in order to ascertain where the symbol is showing up randomly; • Commanding the vehicle by remote control - vehicle was developed, similar to the transport of the pieces of Lego Mindstorms, which moves around on two wheels, which are located in front of the application and the lower end of which was affixed a wheel lowest, responsible for the direction of the vehicle; • Distance in centimeters from one point to another in a straight line - it's an application which calculates the distance in centimeters from one point to another in a given line segment, displaying them in real time on the display of the central controller; • Hieroglyphics - with parts and programming Lego together in the shape of a vehicle, it is the representation of some symbols (hieroglyphics), so that students can understand this writing in a fun and interactive way, using the History and Mathematics to encourage logical reasoning; • Calculation of area and volume - application which calculates the area and volume of objects that the students will choose, displaying them in real time on the display controller; • Representation of the solar system - development of a framework for a rotary level, with the parts and programming Lego set, which makes movements similar to the solar system. The proposed design allows three variations on an experimental level. The first would be the Earth revolving around the Sun, and the second would be the planets rotating around the Sun, the Moon would be the third turning on the Earth. 4.2 Initiative Tosini and Holz The initiative [31] was applied at the Escola Estadual Catharina Seger, located in the municipality of Palma Sola-SC, with students in the class multi-seriate the first and second years. The initiative [31] considered the use of Bluetooth technology in parallel to the use of Lego Mindstorms NXT robotic kit. The Bluetooth allows communication via radio signals from high frequency between computers, smartphones, cell phones, mice, keyboards, headsets, printers and other devices. To make this possible, it took two robotic kits. The first, called the master is the device that creates the connection, while the other, called the slave performs the action. The project was carried out taking into account the areas of: • Mathematics - with understanding the geometric shapes, basic arithmetic operations of addition and subtraction, colors; • Sciences - healthy eating habits through educational activities that inform and motivate individual choices.

1581

At the trial there was a special student with a mild mental retardation. The child that contained aggressive behavior with the teacher and classmates, the experiments performed satisfactorily and felt motivated to help their classmates. At work there was not a closer study on the use of technology in special education. 4.3 Initiative Zarpelon, Tortelli and Bieniek The initiative extension was applied to three schools, two located in the municipality of Erechim-RS (Escola Estadual de Ensino Médio Irany Jaime Farina and Escola Municipal de Educação Infantil Dom João Aloisio Hoffmann) and the other in Passo Fundo-RS (Escola Municipal de Ensino Fundamental Georgina Rosado). Participated in the project students from kindergarten and first grade of elementary school. In the phase of experimentation, was developed a board game. [15] believes that a play can develop play behavior, anticipating the behavior of the child, adult and old. “[...] The game is working well, the duty, the ideal life.” That is, pervades the individual's independence. In the case of the project, the game involves environmental issues, since it is one of the crosscutting themes of education and research focused in schools. The goal is to develop logical thinking through differentiation of geometric figures, as well as its dimensions, color differentiation, the interaction with the world technological and environmental awareness, all these issues will appear in the course of the board. It should be noted that the board game involving environmental issues is just one of the indications to be used in the process. From the results obtained it can be seen that the enormous interest on the part of students and teachers, who also supported the project, the integration of robotics in the school learning environment. Students showed greater attention, concentration and pledged to develop the proposed activities on the board.

5. CONCLUSIONS From the results obtained with the Lego Mindstorms technology, the researchers realized the advantage of the kit in the learning of both students and teachers; it provides creating imaginative concrete structures, ranging from humanoid replicas of animals, vehicles, among others. In contrast to this, it is clear also that the robotic kit is still expensive in Brazil and that it can be a complicating factor, since public schools depend on state and local budgets. In order to meet the social reality of the public attended, schools attended were visited, to see how the students are in the classroom, what activities are developed by teachers, the main difficulties faced by students in their learning process, if there are initiatives in schools with the use of technologies. It was found that, lacking training processes that encourage the use of computers in school, particularly robots, with "small" (personal lines of teachers consulted).

1582

[30] highlights the need for an overhaul of the school curriculum, teacher training and school representatives so that they can work properly interdisciplinarity that technology can provide. The initiative also influenced the relationship between the groups, allowing greater communication between students and teachers, which in a way, was distant. Now [31, 32] highlight the involvement of staff (students and teachers) in the process of experimentation. They also indicate that the curriculum reform and the training of teachers, raised by [30], as necessary, relevant and urgent in school. When asked about how they imagined a robot for some robot were only those with humanoid forms, or had other idea would be a robot. And when asked about the proposed activities, the students would like other activities that were proposed [30, 31, 32]. Therefore, the university has the main role to change the reality pointed out by researchers, either with incorporating technological, scientific, educational process, professional skills in order to create a more just society that promotes the development of individuals who make it part.

REFERENCES 01. BRANDÃO. Carlos R. O que é educação. 33. ed. São Paulo, SP: Brasiliense, 1995. 02. CHARLOT, Bernard. A pesquisa educacional entre conhecimentos, políticas e práticas: especificidades e desafios de uma área. Revista Brasileira de educação. v. 11, n. 31, p. 7-18. jan./abr. 2006. 03. OLIVEIRA, Ramon de. Informática Educativa. Campinas, SP: Papirus, 1997. 176 p. 04.PEIXOTO, Joana. Metáforas e imagens dos formadores de professores na área da informática aplicada à educação. 2007. Educ. Socio., v. 28, n.101, p. 1479-1500. Disponível em: <http://dx.doi.org/10.1590/S0101-73302007000400011>. Acesso em: 22 abr. 2012. 05.CRUZ, M. E. J. K.; et. al. Formação prática do licenciado em Computação para trabalho com Robótica Educativa. In: XVIII Workshop em Informática na Educação (SBIE), São Paulo, SP, 2007. 06.SANCHO, Juana Maria. De Tecnologias da Informação e Comunicação a Recursos Educativos. In: SANCHO, Juana Maria. et. al. Tecnologias para transformar a Educação. Porto Alegre, RS: Artmed, 2006. p. 15-40. 07.CORREIA, Secundino. Inteligência Emocional e Robótica na Educação. Revista Perspectiva, 2008. Disponível em: <http://bica.imagina.pt/2008/inteligencia-emocional-erobotica-na-educacao/>. Acesso em: 07 abr. 2013. 08.QUINTANILHA, Leandro. Irresistível robô. Revista ARede, ed. 34, mar. 2008. Disponível em: <http://www.arede.inf.br/edicao-n-34-marco-2008/3920-irresistivel-robo>. Acesso em: 07 abr. 2013. 09.PRADO, José Pacheco de Almeida. Robôs estarão disponíveis para estudantes brasileiros. 2008. Disponível em: <http://www.acessasp.sp.gov.br/2008/02/robos-estarao-disponiveispara-estudantes-brasileiros/>. Acesso em: 11 ago. 2012. 10.TREVISOL, J. V.; CORDEIRO, M. H.; HASS, M. (Org.). Construindo agendas e definindo rumos. Chapecó, SC: UFFS, 2011. 11.MURPHY, R. R. Introduction to a robotics. Cambridge: The Mit Press, 2000. 12.AYRES, Marcelo. Conheça a história dos robôs. Disponível em: <http://tecnologia.uol.com.br/ultnot/2007/10/01/ult4213u150.jhtm>. Acesso em: 11 abr. 2013. 13.ROBOLIVRE. História da Robótica. Disponível em: <http://robolivre.org/conteudo/historiada-robotica>. Acesso em: 11 abr. 2013.

1583

14.BAKER, James. Robótica de Última Geração. Como Funciona, São Paulo, n. 10, a. 1, p.4447, 2013. 15.CHATEAU, Jean. O jogo e a criança. São Paulo: Summus, 1987. 16.LIANO, José Gregorio de; ADRIÁN, Mariella. Formação Pedagógica: A informática Educativa na escola. São Paulo, SP: Loyola, 2006. 17. GONÇALVES, Maria de Jesus. Linguagem e tecnologia. In: DELIBERATO, Debóra. Comunicação alternativa: teoria e prática. São Paulo, SP: Memnon Edições Científicas, 2009. 18.ROCHA, Sinara Socorro Duarte. O uso do Computador na Educação: a Informática Educativa. Revista Espaço Acadêmico, n. 85, jun. 2008. Disponível em: <http://www.espacoacademico.com.br/085/85rocha.htm>. Acesso em: 06 abr. 2013. 19.GOMES, Marcelo Carboni. Reciclagem Cibernética e Inclusão Digital: Uma Experiência em Informática na Educação. In: LAGO, Clênio (Org.). Reescrevendo a Educação. Chapecó, SC: Sinproeste, 2007. 202 p. 20.LOPES, Daniel Queiroz. Brincando com robôs: desenhando problemas e inventando porquês. Santa Cruz do Sul, RS: EDIUNISC, 2010. 21.GROCHOCKI, Luiz Rodrigo; SILVA, Rodrigo Barbosa e. Robótica Educacional. Guarapuava, PR: Roboticaeducacional.com.br, 2009. 22.ARMSTRONG, Thomas. Inteligências Múltiplas na sala de aula. Porto Alegre, RS: Artmed, 2001. 23.GUIMARÃES, Gleidson Carneiro. Robótica: Espaço interdisciplinar de estímulo às inteligências múltiplas. Revista do Professor, a. 24, n. 96, out./dez. 2008. Porto Alegre, RS. 24.BENITTI, Fabiane Barreto Vavassori .; et. al Experimentação com Robótica Educativa no Ensino Médio: ambiente, atividades e resultados. In: XV Workshop sobre Informática na Escola (WIE), Bento Gonçalves, RSl, 2009. 25.LOPES, Daniel Queiroz; FAGUNDES, Léa da Cruz; BIAZUS, Maria Cristina V .Robótica Educacional: técnica e criatividade no contexto do Projeto Um Computador por Aluno. In: XIX Simpósio Brasileiro de Informática na Educação (SBIE 2008), Fortaleza, CE, 2008. 26.FORD JR., Jerry Lee. Lego Mindstorms NXT 2.0 for Teens. Boston, MA: Cengage Learning, 2011. 27.PAPERT, Seymour. A máquina das crianças: repensando a escola na era da informática. Porto Algre: Artes Médicas, 1994. 28.BOCK, A. M. B.; FURTADO, O.; TEIXEIRA, M. L. T. Psicologias: Uma introdução ao estudo da Psicologia. 14. ed. São Paulo: Saraiva, 2008. 29.PIO, J. L. de S.; CASTRO,T. H. C.; CASTRO JUNIOR, A. N. A Robótica Móvel como instrumento de apoio à Aprendizagem de Computação. In: XVII Simpósio Brasileiro de Informática na Educação - SBIE, Brasília-DF, 2006. 30.KERBER, Fábio Matias. Usando a Robótica como meio Educativo. Trabalho de Conclusão de Curso - Curso de Sistemas de Informação, Universidade do Oeste de Santa Catarina, 2009. 86 p. 31.TOSINI, Juliana; HOLZ, Franciane de Cassia. O emprego da tecnologia Bluetooth e robô Lego Mindstorms no Aprendizado de crianças. Trabalho de Conclusão de Curso - Curso de Sistemas de Informação, Universidade do Oeste de Santa Catarina, 2010. 63p. 32.ZARPELON, Mirian Cátia; TORTELLI, Luana; BIENIEK, Gregori Betiato. O uso da Robótica nos processos educativos de alunos da Educação Infantil e Ensino Fundamental. Projeto de Extensão, Universidade Federal da Fronteira Sul, 2013. 33. GIL, Antonio Carlos. Métodos e técnicas de pesquisa social. 4. ed. São Paulo: Atlas, 1994. 34.ROCHA, Marisa Lopes da; AGUIAR, Katia Faria de. Pesquisa-intervenção e a produção de novas análises. Psic. cienc. prof., Brasília, v. 23, n. 4, dez. 2003.

1584

Desafíos y herramientas para la enseñanza temprana de Concurrencia y Paralelismo Laura De Giusti1, Fabiana Leibovich1, Mariano Sánchez1, Franco Chichizola1, Marcelo Naiouf1, Armando De Giusti1,2 1

Instituto de Investigación en Informática LIDI (III-LIDI) – Facultad de Informática –UNLP 2 Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) Argentina {ldgiusti, fleibovich, msanchez, francoch, mnaiouf, degiusti}@lidi.info.unlp.edu.ar

Abstract. Se analiza la introducción temprana de los temas básicos de concurrencia y paralelismo, de acuerdo a las tendencias curriculares impulsadas por el cambio tecnológico. El artículo analiza la problemática a partir de la introducción de los procesadores de múltiples núcleos y las nuevas arquitecturas asociadas con Cluster, Multicluster y Clouds basados en arquitecturas multicore / GPGPU. Se presenta una herramienta que combina un entorno visual interactivo para la programación concurrente, con el empleo de robots de demostración, especialmente para los temas de comunicación y sincronización. Por último se analizan aplicaciones que extienden el alcance del entorno desarrollado, su aplicación en diferentes cursos y las líneas de I/D futuras en el tema. Keywords: Concurrencia, Paralelismo, Algoritmos Concurrentes y Paralelos.

Currícula,

Entorno,

Multirobot,

Introducción

La Concurrencia ha sido un tema central en el desarrollo de la Informática y los mecanismos de expresión de procesos concurrentes que cooperan y compiten por recursos ha estado en el núcleo curricular de los estudios de Informática desde la década del 70, en particular a partir de los trabajos fundacionales de Hoare, Dijkstra y Hansen [HOA78][HOA85][DIJ65][DIJ78][HAN77]. Estos conceptos se enseñaron tradicionalmente partiendo de la disponibilidad de un único procesador central, que podía explotar parcialmente la concurrencia de un dado algoritmo, en función de la arquitectura física disponible (incluso con hardware específico como los coprocesadores, los controladores de periféricos o esquemas vectoriales que replicaban las unidades de cómputo aritmético-lógico). El paralelismo, entendido como “concurrencia real” en la que múltiples procesadores pueden operar simultáneamente sobre múltiples threads o hilos de control en el mismo instante de tiempo, resultó durante muchos años una posibilidad limitada por la tecnología de hardware disponible [HWA84][HWA93][DAS89].

1585

En las currículas informáticas clásicas [ACM68][ACM78][ACM99] aparecían los conceptos de concurrencia en diferentes áreas (Lenguajes, Paradigmas, Sistemas Operativos) y se omitía casi totalmente el tratamiento del paralelismo, salvo al plantear los conceptos de sistemas distribuidos. La aparición del lenguaje ADA [OLS83] a mediados de los 80 marca un hito en la evolución del tema, ya que especifica claramente en un lenguaje real los diferentes mecanismos de expresión de la concurrencia y al mismo tiempo deja clara la posibilidad de asociar los procesos (“tasks” en ADA) a diferentes procesadores físicos. Las nuevas arquitecturas de los procesadores, que integran múltiples “cores” o núcleos en un procesador físico [GEP06][MCC08][GPG] han producido un notorio impacto en el desarrollo de la Informática, obligando a replantear el “modelo base” de un procesador. Esto ha llevado a reemplazar el formato de “máquina de Von Neuman” [GOL72] con un solo hilo de control, por un esquema como el de la Figura 1 que integra múltiples “cores” cada uno con uno o más hilos de control y varios niveles de memoria accesible en forma diferenciada [AMD09].

Fig. 1

Esquema de un procesador básico actual.

Al mismo tiempo, los cambios tecnológicos han producido una evolución de los temas de mayor interés en Informática, fundamentalmente por las nuevas aplicaciones que se desarrollan a partir de disponer de arquitecturas y redes de comunicación de mayor potencia y menor costo [DEG13][HOO13]. Esto ha llevado a que las recomendaciones curriculares internacionales [ACM04] [ACM08][ACM13] mencionen la necesidad de tratar los temas de concurrencia y paralelismo en etapas tempranas de la formación del alumno, dado que todas las arquitecturas y sistemas reales con los que trabajará son esencialmente paralelos. Sin embargo, aquí aparece uno de los problemas importantes, ya que la programación paralela (y los conceptos fundamentales de concurrencia) resulta más compleja para un alumno en las etapas iniciales de su formación. Es necesario contar con nuevas herramientas que permitan abordar tempranamente el tema [CAR03][DEG12a].

1586

Objetivos del entorno multirrobot en desarrollo

En este trabajo se presenta el entorno CMRE (Concurrent Multi Robot Environment) como una herramienta destinada a introducir los conceptos de concurrencia y paralelismo, con un enfoque visual e interactivo combinado con el empleo de robots físicos para la demostración de los conceptos y ejemplos de desarrollo. 2.1

Entorno visual en Concurrencia y Paralelismo

Se ha partido del trabajo desarrollado en el III-LIDI [DEG12b][DEG12c] para la enseñanza de conceptos de concurrencia en un curso CS1 buscando extender el mismo en los siguientes ejes:  Poder declarar “procesadores” o robots virtuales que representan los “cores” de una arquitectura multiprocesador real. Estos robots virtuales pueden tener un reloj propio y diferentes tiempos para la ejecución de sus tareas específicas.  Tener la capacidad de declarar recursos compartidos o exclusivos, incluyendo la posibilidad de tener exclusión mutua selectiva.  Establecer objetos virtuales que representen datos básicos que se pueden contar y manipular en forma simple mediante primitivas de los robots virtuales.  Disponer de primitivas de comunicación por mensajes sincrónicos y/o asincrónicos.  Disponer de primitivas de sincronización por memoria compartida. 2.2

Incorporación de robots físicos al entorno visual

A los puntos anteriores se le incorpora la comunicación en tiempo real con robots físicos de la línea Lego Mindstorms EV3 [LEGa][LEGb] de modo de poder ejecutar algoritmos paralelos en el entorno, con efecto directo en los robots físicos que replican sobre el terreno el comportamiento definido por los algoritmos. Este modelo de demostración facilita la comprensión de determinados problemas por parte del alumno, tales como los conceptos de fairness, deadlock o inanición [AND00].

Arquitectura y Primitivas de Concurrencia/Paralelismo en CMRE. Ejemplos

El entorno CMRE surge como una evolución del entorno Visual da Vinci cuyo objetivo principal fue resolver problemas donde se especifica el comportamiento de un único robot, el cual puede moverse en una ciudad compuesta por 100 avenidas (verticales) y 100 calles (horizontales) y es capaz de distinguir objetos (flores y papeles) y realizar operaciones con los mismos (juntarlos y/o depositarlos). Asimismo el robot puede “contar” e “informar” resultados. En la Tabla 1 se sintetiza la metáfora buscada con el nuevo entorno.

1587

Tabla 1. Analogía entre el entorno CMRE y los conceptos de Concurrencia y Paralelismo

Conceptos de Concurrencia y Paralelismo Múltiples procesadores / cores Memoria compartida Memoria distribuida Memoria compartida y distribuida Comunicación entre procesos por mensajes Exclusión mutua sobre recursos compartidos Exclusión mutua selectiva Modelo de ejecución sincrónico Arquitecturas heterogéneas Datos locales o globales

Entorno CMRE Múltiples robots (implementado con un proceso por robot) Áreas compartidas de la ciudad Áreas exclusivas por robot Áreas parcialmente compartidas Envío y recepción de mensajes entre robots. Bloqueo de esquinas de la ciudad. Acceso a áreas parcialmente compartidas. Reloj virtual sincrónico. Asignar tiempos específicos a las operaciones de cada robot. Objetos numerables en la ciudad (flores/papeles).

En la Figura 2, a modo ilustrativo se define la estructura general de un programa en el entorno CMRE, en función del cual se especificarán sus primitivas. programa areas1 areas {defino la estructura de la ciudad} nombreArea1: tipoArea(Coordenada0, Coordenada1, Coordenada2, Coordenada3) nombreArea2: tipoArea(Coordenada0, Coordenada1, Coordenada2, Coordenada3) robots {defino el comportamiento de cada tipo de robot} robot tipo1 comenzar {cuerpo} fin robot tipo2 comenzar {cuerpo} fin variables {creo los robots} nombreVariableRobot1: tipo1 nombreVariableRobot2: tipo2 comenzar {Asigno areas privadas a cada robot} AsignarArea(nombreVariableRobot1, nombreArea1) AsignarArea(nombreVariableRobot2, nombreArea2) iniciar(nombreVariableRobot1, PosAv, PosCa) iniciar(nombreVariableRobot1, PosAv, PosCa) fin Fig. 2. Estructura general de un programa en el entorno CMRE.

1588

Tal como se mencionó anteriormente pueden resumirs las capacidades del ambiente CMRE de la siguiente manera:  Existen múltiples procesadores (robots) que realizan tareas y que pueden cooperar y/o competir.  El modelo de ambiente (“ciudad”) en la que desarrollan sus tareas admite áreas privadas, parcialmente compartidas y totalmente compartidas. En un área privada sólo puede moverse un único robot, en un área parcialmente compartida se especifica el conjunto de robots que pueden moverse en ella y en un área totalmente compartida todos los robots definidos en el programa pueden moverse dentro de ella.  Si se instancia un sólo robot en un área que abarque toda la ciudad, se repite el esquema del Visual Da Vinci.  Cuando dos o más robots están en un área compartida (parcial o totalmente), compiten por el acceso a las esquinas del recorrido y a los recursos que allí existan. Para esto deben sincronizar.  Cuando dos o más robots (en un área común o no) desean intercambiar información (datos o control) deben hacerlo por mensajes explícitos.  La sincronización se da por un mecanismo equivalente a un semáforo binario.  La exclusión mutua puede generarse con la declaración de las áreas alcanzadas por cada robot. Acceder a otras áreas de la ciudad, así como salir de ellas no está permitido.  Todo el modelo de ejecución es sincrónico y permite la existencia de un reloj virtual de ciclos, que a su vez permite asignar tiempos específicos a las operaciones, simulando la existencia de una arquitectura heterogénea.  El entorno permite ejecutar el programa de manera tradicional, o paso a paso por instrucciones, dando al usuario un control detallado sobre la ejecución del programa, de manera de poder controlar situaciones típicas de concurrencia tales como conflictos (colisiones) o deadlocks.  En la ejecución paso a paso, el efecto de las operaciones se puede reflejar en los robots físicos, comunicados vía WI-FI.  En el entorno, cada robot tiene asociado un estado, en el que muestra el contenido de su bolsa (cantidad de flores y papeles en el modelo), esquina donde se encuentra situado, estado actual: si se encuentra ejecutando, esperando la llegada de un mensaje, o esperando por la liberación de una esquina. 3.1

Declaración de áreas

La declaración de áreas comienza con la palabra clave areas y termina donde se encuentra la palabra clave robots. Un área de la ciudad es un subconjunto rectangular de esquinas de la ciudad por la que los robots pueden circular. Estas pueden ser de tres tipos:  Área compartida (areaC): es el tipo de área por defecto y corresponde a una región de la ciudad de libre acceso, es decir, cualquier robot puede circular por ella.  Área privada (areaP): una región de este tipo sólo permite que haya un robot en ella. El intento de un robot de ingresar en un área privada de otro, genera un error en tiempo de ejecución. Notar que las áreas privadas permiten un mecanismo de

1589

exclusión mutua implícita entre robots. Área parcialmente compartida (areaPC): este tipo de regiones permiten el acceso de uno o varios robots, con la restricción de que deben haber sido autorizados previamente. Notar que las áreas parcialmente compartidas permiten un mecanismo de exclusión mutua selectiva entre robots. Cada declaración de área comienza con un nombre, seguido de dos puntos y la palabra clave areaC, areaP o areaPC (para indicar su tipo) más cuatro parámetros. Éstos representan las coordenadas inferior izquierda y superior derecha que ocupará el área dentro de la ciudad. Cada tipo de área tiene asociado un color, tal como muestra en la Figura 3. 

Fig. 3. Esquema de la ciudad con las definiciones de las distintas áreas.

El alcance y la visibilidad de las áreas corresponden a todo el programa, y deben ser asignadas a los robots sobre los que se quiera permitir su acceso antes de comenzar la ejecución de los mismos. 3.2

Declaración de robots

La declaración de robots comienza con la palabra clave robots y termina donde se encuentra la palabra clave comenzar. Los robots tienen una estructura casi idéntica a la del programa principal o subprocesos, incluyendo encabezado, declaraciones y cuerpo. El encabezado comienza con la palabra clave robot seguido de un nombre. Las declaraciones de procesos y variables locales siguen las mismas reglas que las declaraciones del programa principal, con la salvedad que no pueden declararse nuevas áreas o robots. De esta manera, la creación de robots siempre es explicita. Una característica a destacar es que aun cuando se quiera utilizar el entorno para simular un ambiente como el del Visual Da Vinci, será necesario crear el único robot desde el programa principal. El cuerpo de un robot es una secuencia de sentencias, delimitada por las palabras clave comenzar y fin. Estas sentencias se corresponden con las de Visual Da Vinci, y sirven para definir el comportamiento del robot en la ciudad. La posibilidad de definir tipos de robots permite reutilizar el código para diferentes

1590

robots que llevan a cabo el mismo comportamiento, teniendo en cuenta que se debe tener cuidado principalmente con el uso de ubicaciones absolutas, dado que los robots puede que compartan o no un área de la ciudad. 3.3

Cuerpo del programa principal

Desde el programa principal es necesario asignar los robots a la áreas que pertenecen y luego “arrancar” cada uno ellos mediante la directiva Iniciar, que requiere del nombre del robot y su ubicación inicial. Esta sentencia requiere de comprobaciones en tiempos de compilación para que dos o más robots no intenten ocupar la misma esquina, teniendo en cuenta también a qué tipo de área pertenece la esquina involucrada. Para dar un ejemplo, un robot no puede ocupar una esquina que pertenece a un área exclusiva de otro robot. A estas sentencias se agrega un nuevo subconjunto, denominado sentencias de concurrencia. 3.4

Manejo de colisiones

Conceptualmente los “recursos compartidos” en este modelo de entorno se pueden reducir al acceso a una esquina, donde puede haber objetos. Evitar las “colisiones” en las esquinas es el problema básico de sincronización en el entorno CMRE. Para esto el lenguaje cuenta con directivas que permiten bloquear y liberar el recurso:  bloquearEsquina (BE): indica que el robot pide exclusión para la ocupación de una esquina (lo que a su vez le permite recoger o depositar objetos).  liberarEsquina (LE): indica que el robot deja el recurso libre (la esquina ocupada). 3.5

Comunicación / Sincronización

Tal como se mencionó anteriormente, hay múltiples robots que trabajan en la ciudad. En muchos casos, deberán colaborar en la resolución de algún problema. Esto requiere comunicación y sincronización. Se adopta un mecanismo explícito de pasaje de mensajes asincrónicos con dos directivas:  enviarMensaje (EM): permite que un robot envíe un mensaje a otro (identificados por su nombre). Al enviar el mensaje, según el modelo asincrónico, el robot continúa con la siguiente instrucción secuencialmente sin esperar la recepción.  recibirMensaje (RM): indica que un robot se quedará esperando hasta sincronizar con el envío de mensaje de otro. En la recepción se indica el nombre del robot del cual se espera el mensaje. Para finalizar se eligieron dos problemas ampliamente utilizados en la enseñanza de los conceptos de programación concurrente y paralela. En la Figura 4 se muestra el código correspondiente a un problema “master/worker” que utiliza Pasaje de Mensajes. Para esto se declaran 4 aéreas privadas junto a 4 robots (1,2,3 workers ,4 master) donde cada uno interactúa en su área privada juntado todas las flores que existen en ella, y al finalizar los robots 1, 2 y 3 envían sus resultados al 4 para que este los totalice e informe dicho total.

1591

programa ejemplo1 procesos proceso avenida(ES f:numero) comenzar repetir 49 {recorre la avenida y junta las flores acumulando en el parámetro f} fin areas {definición de áreas} area1: areaP(1, 1, 50, 50) area2: areaP(1, 51, 50, 100) area3: areaP(51, 1, 100, 50) area4: areaP(51, 51, 100, 100) robots {comportamiento de c/tipo de robot} robot worker variables f:numero comenzar f:=0 repetir 49 avenida(f) Pos(PosAv+1,PosCa-49) avenida(f) enviarMensaje(f, robot4) fin

robot master variables f:numero total:numero comenzar f:=0 repetir 49 avenida(f) Pos(PosAv+1,PosCa-49) avenida(f) total:=f recibirMensaje(f, robot1) total:=total+f recibirMensaje(f, robot2) total:=total+f recibirMensaje(f, robot3) total:=total+f informar(total) fin variables {creación variables robots} robot1: worker robot2: worker robot3: worker robot4: master comenzar {Asignación de áreas a cada robot} AsignarArea(robot1, area1) AsignarArea(robot2, area2) AsignarArea(robot3, area3) AsignarArea(robot4, area4) iniciar(robot1, 1, 1) iniciar(robot2, 1, 51) iniciar(robot1, 51, 1) iniciar(robot2, 51, 51) fin

Fig. 4. Ejemplo de programa con Pasaje de Mensajes.

En la Figura 5 se muestra el código correspondiente a un problema que utiliza Memoria Compartida. Para esto se declara que toda la ciudad es compartida por 2 robots (1 y 2) donde deben coordinarse para trasladar de a una las flores de la esquina (1,1) hasta que la misma queda vacía. Esta coordinación debe darse para garantizar que los robots no estén en la misma esquina simultáneamente, y por consiguiente no tomen la misma flor. Cada vez que un proceso toma una flor la traslada a la esquina siguiente (diferente para cada robot).

1592

programa ejemplo2 procesos proceso girar(E cant:numero) comenzar repetir cant derecha fin proceso depositarUnaFlor comenzar mover liberarEsquina(1,1) depositarFlor fin areas {definición de áreas} area1: areaC(100, 100, 100, 100) robots {comportamiento de c/tipo de robot} robot tipo1 variables seguir:boolean comenzar seguir:=V girar(2) bloquearEsquina(1,1) mover si ~(HayFlorEnLaEsquina) seguir:=F mientras(seguir) tomarFlor girar(2) depositarUnaFlor girar(2) bloquearEsquina(1,1) mover si ~(HayFlorEnLaEsquina) seguir:=F girar(2) mover liberarEsquina(1,1) fin

robot tipo2 variables seguir:boolean comenzar seguir:=V girar(3) bloquearEsquina(1,1) mover si ~(HayFlorEnLaEsquina) seguir:=F mientras(seguir) tomarFlor girar(2) depositarUnaFlor girar(2) bloquearEsquina(1,1) mover si ~(HayFlorEnLaEsquina) seguir:=F girar(2) mover liberarEsquina(1,1) fin variables {creación variables robots} robot1: tipo1 robot2: tipo2 comenzar {Asignación de áreas a cada robot} AsignarArea(robot1, area1) AsignarArea(robot2, area1) iniciar(robot1, 1, 2) iniciar(robot2, 2, 1) fin

Fig. 5. Ejemplo de programa en Memoria Compartida.

3.6

Estado del desarrollo actual

El entorno CMRE está totalmente desarrollado en Java y se está utilizando experimentalmente en la UNLP. Los robots físicos están en proceso de compra, aunque no introducen (en el estado actual del desarrollo) una complejidad adicional.

1593

Las características elegidas de los robots físicos se relacionan con nuevas posibilidades que se abren para el entorno, tal como se indica en las líneas de trabajo futuras.

Conclusiones y Líneas de Trabajo Futuro

Se ha presentado un entorno para la enseñanza temprana de los conceptos de concurrencia y paralelismo, asociados con el empleo de robots virtuales y físicos en un entorno de programación interactivo y flexible. Actualmente se está estudiando la generalización del empleo del CMRE en aplicaciones en las cuales los robots adquieren información en tiempo real y los algoritmos definidos en el entorno toman decisiones dinámicamente. Esto es de particular importancia para asignaturas relacionadas con Sistemas de Tiempo Real e incluso con Sistemas Inteligentes.

Bibliografía

[ACM04] ACM/IEEE-CS Joint Task Force on Computing Curricula. “Computer Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Computer Engineering”. Report in the Computing Curricula Series. 2004. [ACM08] ACM/IEEE-CS Joint Interim Review Task Force. “Computer Science Curriculum 2008: An Interim Revision of CS 2001”. Report from the Interim Review Task Force. 2008. [ACM13] ACM/IEEE-CS Joint Task Force on Computing Curricula. “Computer Science Curricula 2013”. Report from the Task Force. 2013. [ACM68] ACM Curriculum Committee on Computer Science. “Curriculum „68: Recommendations for the undergraduate program in computer science”. Communications of the ACM, 11(3):151-197. 1968. [ACM78] ACM Curriculum Committee on Computer Science. “Curriculum „78: Recommendations for the undergraduate program in computer science”. Communications of the ACM, 22(3):147-166. 1979. [ACM99] ACM Two-Year College Education Committee. “Guidelines for associate-degree and certificate programs to support computing in a networked environment”. New York: The Association for Computing Machinery. 1999. [AMD09] AMD. “Evolución de la tecnología de múltiple núcleo”. http://multicore.amd.com/es-ES/AMD-Multi-Core/resources/Technology-Evolution. 2009. [AND00] Andrews G. “Foundations of Multithreaded, Parallel, and Distributed Programming”. Addison Wrsley, 2000. [CAR03] Carr S., Mayo J., Shene C. “Threadmentor: a pedagogical tool for multithreaded programming”. ACM Journal of Educational Resources, 3:1–30, 2003. [DAS89] Dasgupta S. “Computer Architecture. A Moder Synthesis. Volume 2: Advanced Topics”. Jhon Wilet & Sons. 1989. [DEG12a] De Giusti A. E., Frati F. E., Leibovich F., Sánchez M., De Giusti L. C., Madoz M. C. “Concurrencia y Paralelismo en CS1: la utilización de un Lenguaje Visual orientado”. Proceeding del VII Congreso de Tecnología en Educación y Educación en Tecnología. 2012 [DEG12b] De Giusti L. C., Frati F. E., Leibovich F., Sánchez M., Madoz M. C. “LMRE: Un entorno multiprocesador para la enseñanza de conceptos de concurrencia en un curso CS1”.

1594

Revista Iberoamericana de Tecnología en Educación y Educación en Tecnología. Págs. 7 - 15. 2012. [DEG12c] De Giusti A. E., Frati F. E., Sánchez M., De Giusti L. C. “LIDI Multi Robot Environment: Support software for concurrency learning in CS1”. Proceeding of IEEE International Conference on Collaboration Technologies and Systems. Pág. 294-298. 2012. [DEG13] De Giusti A. E. “El cambio tecnológico como motor de la Investigación en Informática”. Conferencia inaugural del Workshop de Investigadores en Ciencia de la Computación (WICC2013). 2013. [DIJ65] Dijkstra E. W. “Solution of a problem in concurrent programming control”. Communications of the ACM, 8(9):569, 1965. [DIJ78] Dijkstra E. W. “Finding the Correctness Proof of a Concurrent Program”. In Program Construction, International Summer Schoo, Friedrich L. Bauer and Manfred Broy (Eds.). Springer-Verlag, 24-34, 1978. [GEP06] Gepner P., Kowalik M.F. “Multi-Core Processors: New Way to Achieve High System Performance”. In: Proceeding of International Symposium on Parallel Computing in Electrical Engineering 2006 (PAR ELEC 2006). Pags. 9-13. 2006. [GOL72] Goldstine H. H. “The Computer”. Princeton University Press, 1972. [GPG] GPGPU. “General-Purpose Computation on Graphics Processing Units”. http://gpgpu.org. [HAN77] Hansen P. B. “The Architecture of Concurrent Processes”. Prentice Hall, 1977. [HOA78] Hoare C. “Communicating Sequential Processes”. Communications of the ACM, 21(8): 666-677, 1978. [HOA85] Hoare C. “Communicating Sequential Processes”. Prentice Hall, 1985. [HOO13] Hoonlor A., Szymanski B. K., Zaki M. J., Thompson J. “An Evolution of Computer Science Research”. Communications of the ACM. 2013. [HWA84] Hwang K., Briggs F. A. “Computer Architecture and Parallel Processing”. McGraw Hill, 1984. [HWA93] Hwang K. “Advanced Computer Architecture: Parallelism, Scalability, Programmability”. McGraw Hill, 1993. [LEGO] "Lego Education". http://www.legoeducation.us/eng/characteristics/ProductLine~LEGO%20MINDSTORMS%20 Education%20EV3. [LEGOb]Lego. "LEGO Mindstorms EV3 Announced". http://brickextra.com/2013/01/10/legomindstorms-ev3-announced/ [MCC08] McCool M. “Scalable Programming Models for Massively Parallel Multicores”. Proceedings of the IEEE, 96(5): 816–831, 2008. [OLS83] Olsen E. W., Whitehill S. B. “Ada for Programmers”. Prentice Hall, 1983.

1595

Una propuesta para la incorporación de Cloud Computing en la currícula de Grado Nelson Rodríguez1, María Murazzo2, Daniela Villafañe3, Adriana Valenzuela4, Adriana Martin5, Susana Chavez6 Departamento e Instituto de Informática, Universidad Nacional de San Juan, Complejo Universitario Islas Malvinas, Rivadavia, San Juan, Argentina nelson@iinfo.unsj.edu.ar1, maritemurazzo@gmail.com2, villafane.unsj@hotmail.com3, franciscaadriana.valenzuela@gmail.com4, arianamartinsj@gmail.com5,schavez@iinfo.unsj.edu.ar6

Abstract. Cloud Computing es un modelo de provisión de recursos que está transformando los modos tradicionales de cómo las empresas utilizan y adquieren los recursos de Tecnología de la Información. La expansión de Cloud ha determinado la necesidad de formación de recursos humanos especializados. La mayoría de las universidades han resuelto este problema con especializaciones, maestrias o cursos ad-hoc. Pero ninguna ha revisado sus planes de estudio, para incluir adecuadamente los conocimientos básicos de Cloud en el grado si afectar considerablemente la currìcula. Este trabajo sugiere cuales son estos temas fundamentales asociados a Cloud Computing y propone la profundidad con que deben ser abordados para cualquiera de las carreras cuyo contenidos curriculares son aprobados por la resolución 786/2009.

Keywords: Cloud Computing. Curricula Informatics, Cloud Computing Curricula, Computer and Information Science Education, Curriculum

1 Introduction Cloud Computing (CC) es un paradigma que está cambiando en gran parte la forma en que se hacen los negocios por Internet. Sin embargo existen distintas interpretaciones y enfoques de que es y no es Cloud Computing. Al existir tantas definiciones y algunas diferentes entre sí, utilizar el término puede resultar engañoso. Algunos usuarios creen que con solo utilizar algún servicio como e.mail en Internet es suficiente para decir que están en Cloud, otros especialistas son más puristas y consideran que si no están soportando los servicios en una verdadera plataforma Cloud son servicios provistos a través de Internet, pero no Cloud Computing. Con el objetivo de consensuar el concepto en la industria, la revista Cloud Computing Journal reunión a 20 expertos [1] y publicó las distintas definiciones las cuales presentaban coincidencias y diferencias.

1596

El nuevo modelo de negocio y prestación de servicios actual, es el Cloud Computing. Los recursos que provee Cloud responden a las necesidades de las empresas u organizaciones que quieran dar uso a las mismas. Los servicios que ofrece Cloud se pueden agrupar en las categorías. Así, Cloud Computing permite “alquilar” infraestructura hardware en la red (IaaS, infraestructura como servicio), utilizar plataformas colaborativas y herramientas de desarrollo disponibles en Cloud (PaaS, plataforma como servicio) o directamente consumir aplicaciones de software ofrecidas por el proveedor de servicios o pertenecientes a la propia empresa que permitirán mejorar su organización interna y ofrecer servicios online avanzados a sus clientes (SaaS, Software como servicio). Desde el punto de vista académico se han realizado varias iniciativas, ya sea por medio de cursos específicos como: el curso CS309A, Cloud Computing de la universidad de Stanford[2]; o CS5412: Cloud Computing (Spring 2012) Universidad de Cornell[3], entre otros. Algunas empresas además ofrecen certificaciones y otros varios cursos sobre tecnologías específicas para Cloud [4]. Además se pueden encontrar especializaciones y maestrías, las cuales por supuesto incluyen 2 o más cursos como la maestría en Cloud Computing de la Universidad de Newcastle [5]. También se debe destacar las primeras jornadas de Cloud Computing realizadas en Argentina, llevadas a cabo en la Facultad de Informática de la UNLP [6] y también el curso de Postgrado dictado en la misma facultad por Dr. Xoan Pardo [7]. En todos los casos los esfuerzos son válidos, pero no resuelve el problema de que los contenidos básicos sean trasmitidos en el grado. Teniendo en cuenta que la informática y en particular Cloud Computing sufre una constante evolución, es necesario revisar los planes de estudio periódicamente para incorporar estos nuevos contenidos y plantear los objetivos actitudinales. Cuando se incorporaron alumnos a los proyectos de investigación, se comprobó que muchos conceptos de Cloud Computing no eran conceptualizados por los alumnos debido a que no formaban parte de los contenidos de las materias obligatorias (en algunos casos se impartían a un nivel muy introductorio en materias optativas), y por ende no formaban parte de los conocimientos que tiene un egresado. A partir de ahí surgió el interés de discutir cuales eran los temas considerados más importantes, además ya se había realizado un trabajo anterior pero solo sobre los temas de Arquitectura Sistemas Operativos y Redes que fue publicado en TE&ET [8]. Los planes de estudios vigentes en las carreras de nuestra universidad se basan en lo propuesto por la red UNCI. Por ello, el punto de referencia para analizar cuales contenidos la industria propone como necesarios deberían ser aquellos no presentes en la resolución 786/2009 [9]. Dicha resolución define los contenidos curriculares básicos, carga horaria mínima, criterios de intensidad de la formación práctica y estándares de acreditación referidos a la carreras de Licenciatura en Ciencias de la Computación, Licenciatura en Sistemas/Sistemas de Información/Análisis de Sistemas, Licenciatura en informática, Ingeniería en Computación e Ingeniería en Sistemas de Información/Informática, Para llegar a una propuesta válida, se debería analizar a todas las entidades o personas interesadas en producir modificaciones a los planes de estudio. La industria necesita especialistas en determinadas áreas, los organismos como la IEEE y ACM, Red UNCI proponen currículas, las universidades proponen cursos y

1597

los egresados a través de su experiencia profesional aportan lo suyo. Es evidente que un análisis pormenorizado de lo que han documentado todos los interesados. Por lo tanto el punto de partida es la resolución 786, se tuvieron en cuenta los temarios de cursos de la industria y las universidades. También se ha tenido en cuenta las sugerencias que están expresadas en los borradores de la futura propuesta CS 2013 (que modifica las áreas de conocimiento de las carreras) [10].

2 Cloud Computing Los avances en IT han permitido que supercomputadoras y clusters soporten millones de operaciones concurrentes. El paralelismo está soportado por la comunicación y coordinación, estas dos actividades han sido transformadas dramáticamente. Además las comunicaciones de alta velocidad quasi-ubicuas no solo posibilitan que los data centers sean reubicados sino también que las computaciones sean movidas a facilidades centralizadas que ejecutan economía de escala y permite que enormes cantidades de datos sean agrupados y organizados para soportar tareas de decisión de usuarios por todo el mundo. Los gobiernos, laboratorios de investigación y empresas necesitan simular fenómenos complejos, similarmente Google, Facebook, Microsoft y otras CSP (Proveedoras de Servicio de Cloud) necesitan procesar grandes cantidades de datos operados en masivos datacenters “cloud”. El paralelismo masivo, la comunicación ultraràpida y la centralización masiva serán fundamentales para la toma de decisión humana. Las computaciones que serán usadas para predecir el tiempo, indexar la Web, recomendar películas, restoranes y hoteles, sugerir conexiones sociales y más, son distribuidas sobre cientos de procesadores y dependen de colecciones de datos, a veces de millones de fuentes repartidas por todo el mundo [11]. La importancia de Cloud Computing puede verse reflejada en varias estadísticas publicadas sobre inversión y sus perspectivas. Por ejemplo en un estudio realizado por Gartner, predicen el tamaño del mercado de Cloud Computing podría alcanzar los 150 mil millones de dólares en 2013. Por otro lado Mimecast realizó un estudio estadístico y encontró que 7 de cada 10 empresas que utilizan servicios Cloud moverá nuevas aplicaciones al mismo. Sólo es el 70%, porque varias respondieron que no quieren “poner todos los huevos en una sola canasta". Esto significa que algunas empresas todavía se muestran escépticas acerca de mudarse completamente a Cloud. Gartner también predijo que el 60% de las cargas de trabajo de servidor se virtualizarán en 2014, debido a la cantidad de beneficios que obtiene a cambio, como es reducir la compra de hardware, la huella de carbono y los costos de energía. Esta es una gran manera de ahorrar dinero en el largo plazo [12]. El National Institute of Standards and Technology ha presentado una de las definiciones de Cloud más clara y comprensible. La define como un modelo que habilita acceso a red ubicuo, conveniente, bajo demanda para compartir un conjunto de recursos configurable, que pueden ser rápidamente provistos y liberados con mínimo esfuerzo o interacción del proveedor de servicios. Distingue las

1598

características de Cloud, el modelo de entrega y los métodos de desarrollo. Resalta así, los cinco (5) aspectos claves de cloud computing: auto servicio bajo demanda, acceso a la red ubicua, un conjunto de recursos independiente de la ubicación, rápida elasticidad y servicio a la medida [13]. Cloud Computing no es un desarrollo revolucionario reciente, sino es el resultado de la evolución de varias tecnologías. Conceptos precursores son: utility computing, computación bajo demanda, computación elástica o grid computing [14]. Se puede pensar a Cloud Computing como un modelo de aprovisionamiento de recursos IT que potencia la prestación de servicios IT y servicios de negocio, facilitando la operativa del usuario final y del prestador del servicio. 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 la Internet sin que los usuarios tengan que tener ningún conocimiento de lo que sucede detrás. Cloud Computing es un esquema que a veces se expresa como XaaS o EaaS, para significar Everything as a Service. Usualmente se divide a Cloud Computing en las siguientes capas: Software como Servicio (SaaS), Plataforma como Servicio (PaaS) e Infraestructura como Servicio (IaaS). Investigaciones recientes de IDC muestra los ingresos públicos en todo el mundo de TI, donde los servicios de Cloud superaron los $ 16 mil millones en 2009 y se prevé llegar a 55,5 mil millones dólares en 2014, lo que representa una tasa compuesta de crecimiento anual del 27,4%. Esta rápida tasa de crecimiento es más de cinco veces el crecimiento previsto para los productos tradicionales de TI (5%). Frank Gens, Senior VP y Analista jefe en IDC dice: “Un reciente estudio entre Ejecutivos de IT, CIOs y los colegas en las líneas de negocio muestra que la Cloud Computing está ‘cruzando el abismo’ y entrando en un período de amplía adopción. Más aún, la crisis económica amplificará la adopción de Cloud. Este modelo ofrece una manera más barata para que el negocio use y adquiera tecnología. Esta ventaja es verdaderamente importante para los pequeños y medianos negocios, un sector que será clave en cualquier plan de recuperación [15]. Esta fuerte presencia de Cloud Computing en el mercado está cambiando el perfil del profesional de IT. Al respecto la Debra Littlejohn Shinder, comenta que aspectos que eran complementarios ahora son centrales, a tal fin describe las 10 áreas claves para especialistas de IT en los próximos años, donde figura Cloud Computing en primer lugar [16]. Cloud Computing generará una década de investigación en virtualización, computación distribuida, utility computing, redes, servicios de software y servicios Web. Implica una arquitectura orientada a servicio, de gran flexibilidad con reducido costo de propiedad, con servicios bajo demanda y muchas otras cosas [17]. Además se cita en varias predicciones que hacen algunas consultoras como Garnet, que en octubre de 2012 expuso que entre las 10 principales tecnologías consideradas clave por la consultora están: Personal Cloud, The Internet of Things, Hybrid IT and Cloud Computing [18].

1599

3 Qué contenidos involucra Cloud Computing Se puede considerar a Cloud Computing como “la multidisciplinariedad dentro de la disciplina”, porque si se tiene en cuenta la informática, Cloud Computing involucra conceptos de Sistemas Distribuidos, conectividad y Sistemas Operativos (ARSO), bases de datos NSQL, metodologías de desarrollo específicas para Cloud y lenguajes de programación también específicos, inclusive en la actualidad se están utilizando servicios de Cloud para aplicaciones para HPC. Según Charles Border "Cloud Computing es una nueva palabra de moda para un grupo de viejas tecnologías que han sido integradas para crear un sistema que es más que la suma de todas las partes” [19]. Por lo tanto, surge como un desafío determinar cuáles son estos contenidos mínimos y cómo poder incluirlos en la curricula con el menor impacto posible. Vale la pena resaltar, que el objetivo de este trabajo es el expuesto en el párrafo anterior, y no en sugerir una carrera de especialista en Cloud, que es ese caso debería incluir varios contenidos adicionales, o sea, cuales son los contenidos para un Licenciado en Sistemas o en Ciencias de la Computación o en Informática o en alguna de las otras terminales que deben impartirse y que establezcan las bases para el conocimiento de Cloud Computing a nivel de grado. Teniendo en cuenta cursos, capacitaciones de empresas y publicaciones, se pueden determinar que Cloud involucra grandes temas, los cuales son: virtualización, arquitectura cloud (IaaS, PaaS, SaaS y sus variantes), Data Centers, Big Data, Seguridad. Cada una de las áreas que abarca o se relaciona con CC presenta muchos contenidos para desarrollar por ejemplo XaaS, o sea cualquier cosa como servicio y cuando se definió los temas a incluir se tuvo en cuenta también las tecnologías que hacen posible CC. Estas tecnologías son necesarias que sean estudiadas antes de tratar CC porque en ellas se fundamenta el paradigma, y si no se han tratado con suficiente profundidad es posible que el crédito horario de la presente propuesta deba ser ampliado. En la Resol.786 figuran los siguientes tópicos como base para CC: algoritmos concurrentes, distribuidos y paralelos, algoritmos y lenguajes, concurrencia y paralelismo, Concepto de arquitectura basadas en servicios, Seguridad en Sistemas Distribuidos, Arquitecturas de Multicomputadoras y Computación orientada a Redes. Pero además se deben tener en cuenta las tecnologías habilitantes son: tecnologías de multicomputadoras y multithreading, Computación HPC, Redes, Datacenter, Virtualizaciòn, SOA, Modelos de Programación Distribuida y paralela. La importancia de todas las tecnologías de base para CC se puede justificar en el hecho de que las CS2013 agregar como nueva área a la Computación Paralela y Distribuida (al ser un área incluye más de una materia) [10], y también muchas empresas además de las tradicionales en CC han comenzado a ofrecer servicios de Cloud como las Telco, que han evolucionado desde servicios de conectividad, luego ISP y ahora se han transformado en CSP.

1600

4 Antecedentes Aunque mucho se ha escrito acerca de integrar nuevas tecnologías en la curricula, muy poco ha sido escrito acerca de la integración de Cloud Computing en los planes de estudio. Un año antes del inició un proyecto de investigación sobre CC (en 2019) se comenzaron a realizar investigaciones y publicaciones sobre este paradigma, se hicieron presentaciones en la WICC [21,22,23,24,25], CACIC [26], COMTEL (Perù) [27], RUEDA [28], SABTIC[29,30] y JCC [31,32]. En una encuesta realizada a egresados de carreras de informática, se determinó que entre los temas sugeridos como importantes aparecen virtualización y Cloud Computing, temas que están incluidos en todos los cursos de CC [8]. En dicha encuesta, se valoró de la siguiente forma: 5 – Muy necesario 4Necesario 3-Necesite a veces conocerlo 2- Pocas veces necesite conocerlo 1-No me hizo falta nunca. Como resultado arrojó que CC llegó a una ponderación de 2,75, programación de alta performance 2,80, programación paralela 2,45, Cluster 2,5 y virtualización 3,4 sobre 5 puntos. Por otro lado se toma en cuenta la resolución 786 que es la que está vigente para las curriculas de carreras ligadas a la informática. La propuesta de este trabajo no es la de generar una materia nueva o un grupo de materias sobre Cloud Computing, sino de como agregar los mínimos contenidos sin modificar considerablemente la currícula. Si bien miembros de la red UNCI están trabajando en modificaciones a los planes de estudio y muchos de los contenidos de CC se han incorporado a estas modificaciones a partir de lo que se conoce como la iniciativa informático 2020, estos cambios pueden verse reflejados en el mejor de los casos en un par de años y solo para los alumnos ingresantes. En la materia Sistemas Distribuidos, correspondiente al 5to año de la Licenciatura en Ciencias de la Computación el la UNSJ. Se realizaron durante 2012 y 2013 experiencias educativas al incorporar una introducción a CC en 2012 y se profundizaron algunos temas y se incorporó una práctica sencilla sobre un PaaS en 2013. Esto permitió junto con otras experiencias como Conferencias y Tutoriales expuestos en distintos ámbitos, calcular el tiempo necesario para incorporar estos contenidos a la currícula [33,34,35]. Para la parte práctica se decidió trabajar con Google App Engine, porque se presentaban algunas dificultades administrativas para el uso de Amazon Web Service y Azure en el Cloud. Por otro lado es conveniente realizar las mismas en el ambiente que demande menor tiempo en conocerse (ya sea por el ambiente o el lenguaje), teniendo en cuenta el plan de estudios o conocimientos previos de los estudiantes, por ejemplo puede ser que se conozca mejor Python, Java o C#, y por lo tanto se elegirá el ambiente más adecuado. Aunque la experiencia resultó exitosa, teniendo en cuenta que los alumnos comprendieron la temática, quedan temas para profundizar que deberían impartirse en otras materias a lo largo del plan de estudios, como por ejemplo virtualización en sistemas operativos y Big Data en base de datos o materias relacionadas. Para elaborar la propuesta se tuvo en cuenta demás dos trabajos realizados que tratan la problemática de incluir CC en la currìcula, como son el presentado por Charles Border en el SIGSE’13 [19] y el de James Lawler en el EDSIG 2011 [36]. El

1601

primer trabajo trata sobre los Fundamentos y tecnologías que hacen posible CC, mientras que el segundo desarrolla una propuesta similar a la presente pero tomando en cuenta curriculas IS 2009 publicada por la IEEE y ACM, pero generada a partir de BMP (Business Process Management), o sea con un enfoque a Sistemas e IS, y no general para las diferentes carreras. CC va a tener un impacto similar o inclusive superior al de seguridad como fue expuesto en la propuesta de curricula 2013 [10], debido a que el impacto de CC es sobre todo el plan de estudios y por lo tanto no es conveniente agregar una materia sobre Cloud sino distribuir los contenidos en las distintas materias relacionadas.

5 La Propuesta El objetivo de la propuesta es introducir las bases del paradigma emergente de Cloud Computing para que sean dictados en las materias de grado sin modificar sustancialmente los créditos horarios de las asignaturas. El alumno debería conocer: Los fundamentos de Cloud Computing Las tecnologías de apoyo Entender las limitaciones, ventajas y desventajas, Técnicas de creación y uso del Cloud Los fundamentos de MapReduce como modelo de programación Es conveniente que la mayoría de los conceptos se impartan en los años superiores (4to y 5to año), debido a que el tiempo necesario para las distintas actividades (teorías y prácticas) se puedan realizar en el menor tiempo posible y no se incremente el crédito horario de las materias, aunque la incorporación de contenido nuevo siempre obliga a realizar determinados ajustes. Los contenidos propuestos son: Conceptos introductorios (1 hora) Clasificación de servicios: SaaS, PaaS, IaaS (1 hora) Modelos de despliegue: público, privado e híbrido (1 hora) Virtualización y Data Centers (2 horas) Clusters y Arquitecturas de HPC ( 2 o 3 horas) Base de Datos NoSQL y Big Data (1, 2 o 3 horas, no se contempla práctica) MapReduce (1 hora) Programación del Cloud y Ambientes de Software (1 hora, si se pone énfasis en un solo ambiente, sino puede ser hasta 3 horas) Ambientes de Software Emergentes: Open Source, Eucalyptus y Nimbus (1 hora) Ciclo de vida y Metodología para Cloud Computing (2 horas) Prácticas que pueden ser sobre PaaS o SaaS (4 horas o más) Aspectos Legales de Cloud Computing, fundamentalmente SLA para Cloud (Service Level Agreement) (1 hora, que debe ser impartido en el espacio de materias del área Aspectos Profesionales y Sociales)

1602

En el mejor de los casos son solo 18 horas que pueden ser reubicadas en distintas materias, pero en el peor de los casos serán 23 horas. Cabe hacer notar que virtualización es un tema que se encuentra dentro de la resolución 786, por lo que dicho tema se está impartiendo en las carreras que abarca dicha resolución, pero la hora que se agrega es para enseñar los contenidos de virtualización de middleware e hipervisores. Quedan además varios temas por profundizar o conceptualizar, que serían objeto de un curso específico (o más de un curso) y no como parte de la currícula para un alumno de grado como son: Eficiencia en energía para centro de datos, métricas de performance y escalabilidad, métricas de tolerancia a falla y disponibilidad, Hadoop a un nivel avanzado, HPC sobre Cloud, Seguridad específica en Cloud, otros casos de servicios Cloud como Desktop como servicio, o Database como servicio, Monitoreo como Servicio, Por otro lado CC puede ser considerado como un modelo de entrega de SaaS, PaaS e IaaS, pero además Database como servicio, Información como servicio, Integración como servicio, Administración como servicio, Plataforma como servicio, Proceso como servicio, Seguridad como servicio, Almacenamiento como servicio y Testing como Servicio.

6 Conclusiones Cloud Computing no solo es una buzzword, es el modelo de cómo se construirán gran parte de las aplicaciones del futuro. La inversiones que están realizando las empresas en Cloud son millonarias y los planes de estudio deben reflejar lo que está pasando en la industria, porque nuestro alumnos se insertarán en ese mercado laboral, por supuesto sin descuidar los fundamentos y la formación que debe tener un profesional universitario. Para cada una de las carreras de las distintas terminales: Licenciatura en Ciencias de la Computación, Licenciatura en Sistemas de Información, Licenciatura en informática, Ingeniería en Computación e Ingeniería en Sistemas de Información, se deberán plantear los contenidos específicos de CC, por lo tanto queda a partir de este trabajo mucho para discutir. La propuesta no incluye un crédito horario razonable para los conocimientos básicos de CC y no demanda grandes adecuaciones para llevarlo a cabo. Desde el punto de vista educativo CC favorece la integración de diversos contenidos como paradigmas de computación (Web Services, data Centers, Utility Computing, Grid Computing, P2P e Internet de las Cosas), Modelos de Programación Distribuida y Paralela, y atributos y capacidades deseadas (Ubicuidad, Confiabilidad, Escalabilidad, QoS, SLA y Aspectos legales y consideraciones Sociales), lo que impactará fuertemente en la formación del alumno. Cloud Computing irá cambiando conforme aparezcan nuevas investigaciones y desarrollos, y por supuesto estos cambios también impactarán en la curricula.

1603

References 1.

Cloud Computing Journal: Twenty-One Experts Define Cloud Computing. http://cloudcomputing.sys-con.com (2008) 2. Chou T.: CS309A Cloud Computing. Universidad de Stanford http://scpd.stanford.edu/search/publicCourseSearchDetails.do?method=load&courseId=118 15 3. Birman K. CS5412 Cloud Computing. Universidad de Cornell. http://www.cs.cornell.edu/courses/cs5412/2012sp/ 4. Private Cloud certification Solutions Expert, Microsoft, http://www.microsoft.com/learning/en-us/private-cloud-certification.aspx 5. MSc Cloud Computing, Universidad de Newcastle, http://www.ncl.ac.uk/computing/study/postgrad/taught/5056/ 6. I Jornadas de Cloud Computing, III-LIDI, Facultad de Informática, UNLP, http://jcc2013.info.unlp.edu.ar/ 7. Pardo X. (UDC): Cloud Computing, Curso de Postgrado Doctorado en Ciencias Informáticas, http://postgrado.info.unlp.edu.ar/Cursos/Cursos_2013/062013_Cloud_Computing.pdf 8. Rodríguez N., Murazzo M., Villafañe D.: Cuáles son los conocimientos de ARSO (Arquitectura, Redes y Sistemas Operativos) que la industria considera importantes, VII Congreso TEyET 2012. 9. Ministerio de Educación: Resolución 786/2009, 26/5/2009, disponible en: http://redunci.info.unlp.edu.ar/docs/BoletinOficial_Resolucion_786-2009.pdf 10. The Joint Task Force on Computing Curricula Association for Computing Machinery IEEE-Computer Society: Computer Science Curricula 2013,Ironman Draft (Version 1.0) February 2013, http://redunci.info.unlp.edu.ar/docs/cs2013-ironman-v1.0.pdf. 11. 13. Hwang K., Fox G., Dongarra J.: Distributed and Cloud Computing from Parallel Processing to the Internet of Things (eds.) Morgan Kauffmann (2012) 12. Williams N., Marketing Coordinator, WebSan Solutions Inc., a Canadian Certified Microsoft Partner: 3 Interesting Cloud Computing Statistics, Junio 2013, http://www.erpsoftwareblog.com/2013/06/3-interesting-cloud-computing-statistics/ 13. Mell P., Grance T.: NIST: Definition of Cloud Computing, Special Publication 800-145, (2011) 14. Zhu J., Fang X., Guo Z., Hua Niu M., Cao F., Yue S., Liu Q.: IBM Cloud Computing Powering a Smarter Planet, Libro Cloud Computing, Volumen 5931/2009, Páginas 621625.(2009) 15. IDC :IDC Finds Cloud Computing. Entering Period of Accelerating Adoption and Poised to Capture IT Spending Growth Over the Next Five Years, http://www.idc.com/getdoc.jsp?containerId=prUS21480708 16. Littlejohn Shinder D. MVP,: 10 hot areas of expertise for IT specialists, TechRepublic, Feb (2011). 17. Youk M..:Cloud Computing – Issues,Research and Implementations, Journal of Computing and Information Technology, CIT 16, 2008, 4, 235–246. doi:10.2498/cit.1001391. 18. Gartner Identifies the Top 10 Strategic Technology Trends for 2013. Analysts Examine Top Industry Trends at Gartner Symposium/ITxpo, October 21-25 in Orlando, Press Release, http://www.gartner.com/newsroom/id/2209615 (2012). 19. Border C.: Cloud Computing in the Curriculum: Fundamental and Enabling Technologies. SIGCSE’13 ACM (2013). 20.Murazzo M., Rodríguez N.: Mobile Cloud Computing, XII WICC 2010, Calafate, (2010). 21. Rodríguez N., Chávez S., Martín A., Murazzo M., Valenzuela A.: Interoperabilidad en Cloud Computing. XIII WICC, Rosario ( 2011).

1604

22. Chávez S., Martin A., Rodríguez N., Murazzo M., Valenzuela A.: Metodología AGIL para el desarrollo SaaS, XIV WICC, Mayo 2012. Posadas, Misiones (2012). 23. Rodríguez N., Valenzuela A., Chavez S., Martin A., Murazzo M., Villafañe D.: Ambiente de desarrollo para lengua de señas basado en cloud, XIV WICC, Mayo 2012. Posadas, Misiones (2012). 24. Martín A., Chávez S., Rodríguez N., Valenzuela A., Murazzo M.: Bases de Datos NoSql en Cloud Computing, XV WICC Abril 2013.Paranà Entre Ríos (2013). 25. Rodríguez N., Murazzo M., Villafañe D., Alves M., Medel D.: Integración de Computación Heterogénea con Hadoop para Cloud Computing, XV WICC Abril 2013.Paranà Entre Rìos (2013). 26. Murazzo Maria, Millán Flavia, Rodríguez Nelson, Segura Daniela, Villafañe Daniela (Oct. 2010).”Desarrollo de aplicaciones para cloud computing”. CACIC 2010. Morón. ( 2010). 27.Murazzo María, Rodríguez Nelson: Una propuesta para el desarrollo de aplicaciones para mobile cloud computing. Congreso Internacional de Computación y Telecomunicaciones – COMTEL 2010, Lima, Perú. Oct. (2010). 28.Millán F., Murazzo M., Rodríguez N. (2010): Plataformas educativas implementadas con mobile cloud computing, V Seminario Internacional “De legados y Horizontes para el Siglo XXI”, organizado por RUEDA, Tandil. Sep. (2010). 29. Rodrìguez N., Murazzo M., di Sciacio C. : Integración de Computación móvil con Cloud Computing, 1º Seminario Argentina Brasil de Tecnologías de la Información y la Computación, Rosario noviembre (2011). 30. Rodrìguez N., Villafañe D., Murazzo M., Gallardo D., Tarrachano G.: Integración de las capas SaaS / Paas del Cloud en la tecnología Google, 2º Seminario Argentina Brasil de Tecnologías de la Información y la Computación – Tres de Maio Brasil (2012). 31. Rodríguez N., Murazzo M., Chávez S., Valenzuela A., Martín A., Villafañe D.: Aspectos claves para el desarrollo de aplicaciones para Mobile Cloud Computing, JCC 2013. La Plata (2013) 32. Murazzo M., Rodríguez N., Villafañe D., González F.: Perspectivas en el análisis de grandes volúmenes de datos en el Cloud. JCC 2013. La Plata (2013) 33. Rodríguez, Murazzo, Ene: Cloud Computing, Workshop de investigadores en Ciencias de la Computación y Sistemas de Información. San Juan. Nov. (2009). 34. Murazzo M. Segura D., Villafañe D.: Cloud Computing con Windows Azure, 2° Jornadas de Actualización Informatica. San Juan junio, (2010). 35. Rodríguez N., Villafañe D.: Cloud Computing (conferencia invitada). 2da Jornadas organizadas por CASETIC (Cámara de Empresas de Software). San Juan. Oct. (2010). 36. Lawler J. :Cloud Computing in the Curricula of Schools of Computer Science and Information Systems, Information Systems Education Journal (ISEDJ) (2011).

1605

Propuesta de una metodología para una rápida enseñanza de circuitos lógicos y de su integración en una UCP en carreras de Informática Mario Carlos Ginzburg Profesor Titular de "Sistemas de Computación I y II" en la Universidad Abierta Interamericana mario.ginzburg@uai.edu.ar

Resumen. Los programas de Arquitectura de Computadoras y similares de carreras de Informática son extensos, y en general presentan una sola unidad dedicada a circuitos lógicos, debiéndose formar en limitadas clases a los alumnos en los conocimientos básicos. Esta problemática trae aparejado un debate acerca de los contenidos mínimos a enseñar acorde con la formación buscada, que en esta propuesta se plantean y desarrollan. Opcionalmente, conforme al perfil y nivel de cada carrera, los circuitos de la UCP tratados aisladamente pueden integrarse en un modelo de UCP didáctico, también desarrollable en pocas clases. Esta plataforma no requiere conocimientos de electrónica, y también puede emplearse en estudios terciarios de Informática y en carreras de Electrónica como introducción a los circuitos digitales. La presente metodología didáctica se ha concretado con excelentes resultados en ingenierías informáticas de la FIBA (3er. año) y Facultad de Tecnología de la UAI (1er. año) desde el 2002 al presente. Palabras claves: circuitos lógicos, enseñanza didáctica rápida

1. Introducción Cuando alumnos de carreras de Informática de distintas partes del país solicitan equivalencias de estudios, se observa al leer los programas de Arquitectura de Computadoras o asignatura similares, que en general se dispone de pocas clases para desarrollar desde “cero” los contenidos dedicados a los circuitos básicos que conforman la UCP (compuertas, decodificadores, UAL, multiplexores, flip flops, registros y buses). Estos circuitos en general se enseñan desconectados entre sí, sin conformar una UCP. En las carreras de Electrónica se tiene una asignatura como Técnicas Digitales dedicada por completo a los circuitos combinacionales y secuenciales. Por las limitaciones de tiempo señaladas se requiere que la enseñanza de esos circuitos sea sintética y conceptual, a la par que didáctica. Para lograr esto es necesario discutir primero qué contenidos son propios de Informática, como se plantea en el ítem 2 de este trabajo Si además, por el perfil y exigencias del nivel de estudios de una carrera de Informática, dichos circuitos digitales deben integrarse en un modelo didáctico simple de UCP, su tiempo de enseñanza se vuelve doblemente crítico si se quiere desarrollar normalmente los restantes contenidos de Arquitectura de Computadoras. Tal modelo de UCP construido con compuertas y flip flops que forman parte de sus bloques funcionales, debe permitir, sin usar electrónica, visualizar y comprender en profundidad en cada ciclo del pedido y ejecución de instrucciones, entre otras cosas, el papel temporal y circuital de los MHz y de las líneas de control sobre: los registros, la UAL, la memoria y los caminos de datos (“data paths”). Asimismo debe poder ilustrar acerca de cómo interactúan hardware y software, y cómo es que en la decodificación el código de operación de una instrucción determina el valor que tendrán las líneas de control para que el hardware la ejecute y pida la siguiente. Además debe ser factible en dicho modelo ejecutar instrucciones de salto en las que intervienen los flags, para comprender cómo la máquina decide entre dos alternativas, y poner en claro que la UCP no tiene inteligencia propia para concretar en cada ciclo sus acciones. Igualmente debe ser útil para establecer diferencias entre CISC y RISC. A fin de poder desarrollar con rapidez este modelo, es indispensable que previamente los alumnos hayan sistematizado en un modelo sin circuitos lógicos, sólo con “cajas negras” de la UC, la UAL y los registros interconectadas por buses, los movimientos y cambios que ocurren en un computador cuando se piden y ejecutan las instrucciones. De esta forma se sigue el orden de lo general a lo particular, para luego volver a lo general.

2. Problemática abordada Conforme al objetivo buscado de que en las carreras de Informática la enseñanza de los circuitos lógicos sea sintética, conceptual, didáctica, y sean mínimos sus tiempos de enseñanza, primero es indispensable definir qué aspectos de la enseñanza de circuitos son necesarios y suficientes en estas carreras, para luego desarrollar un proceso de enseñanzaaprendizaje apropiado y didáctico que cualquier docente puede aplicar.

1606

La presente metodología es fruto de sucesivos perfeccionamientos didácticos practicados durante más de diez años de enseñanza de los contenidos aquí planteados. En tal sentido, el autor como director de cátedras, llevó a cabo observaciones empíricas siguiendo la evolución en el aprendizaje a través de cuestionarios, exámenes parciales y finales de centenares de alumnos de las asignaturas “Estructura del Computador “, de 3er. año de Ingeniería Informática de la FIBA (2000-2006), y Sistemas de Computación II de 1er. año la Facultad de Tecnología Informática de la UAI (del 2004 al presente). Debe consignarse que la mayoría de los alumnos provienen de establecimientos secundarios no técnicos, sin conocimientos de electrónica o electricidad. A fin de no perder tiempo en dibujos por parte del docente o de los alumnos, esta metodología requiere proyectar imágenes, que pueden formar parte de un texto, o un apunte con un atlas de figuras, al cual los alumnos pueden remitirse para sistematizar y repasar todos los temas tratados en clase. 2.1

Enseñanza tradicional con aspectos relacionados con carreras de electrónica

Habitualmente, en parte por que los primeros profesores de materias del tipo Arquitectura de Computadoras en facultades de Informática fueron ingenieros electrónicos, el aprendizaje de los circuitos lógicos en general ha sido muy semejante al que tiene lugar en los primeros tramos de la asignatura Técnicas Digitales de las carreras de Ingeniería Electrónica. Un objetivo propio en estas carreras es que el futuro ingeniero esté capacitado para proyectar subsistemas electrónicos digitales. Asimismo, aún hoy, con la influencia de Técnicas Digitales, además de métodos algebraicos de minimización y transformaciones circuitales, se enseñan detalladamente un conjunto de flip flops asincrónicos y sincrónicos, en sus distintos funcionamientos (R-S, J-K, T, etc.), siendo que, como se desarrolla en el ítem 3, es factible a partir de un multiplexor de 2 entradas construir de manera simple un flip flop “D” sincrónico, con el cual se pueden implementar los registros y secuenciadores que necesita un modelo simple de UCP. Esta concepción en la enseñanza de los temas básicos también se apoya en la bibliografía clásica para Arquitectura de Computadoras, con textos que contemplan tanto el funcionamiento como el diseño de computadores, objetivo que en principio no está presente en el perfil del ingeniero en Informática o Sistemas. En Stallings [1] se enseñan los temas antes mencionados, y además se agrega simplificación por el método de QuineMc Cluskey y contadores sincrónicos. En Tanenbaum [2] si bien aparece la enseñanza tradicional de este tema, no se dan métodos de simplificación. En Murdocca - Heuring [3], en Hamacher - Vranesic - Zaky [4], y en Alcalde - Portillo García Merayo [5], por citar algunos, contienen bien detalladas metodologías apropiadas para carreras de ingeniería electrónica. Inclusive en algunos textos aparecen transistores y hojas con datos eléctricos de compuertas. Una limitación que presenta en general esta enseñanza, es que si bien los alumnos tienen un primer conocimiento del funcionamiento de circuitos lógicos tratados aisladamente, no ven su funcionalidad formando parte de una UCP.

2.2 Objetivos propios, planteo didáctico y herramientas para la enseñanza de circuitos lógicos en carreras de Informática En la formación del ingeniero en Informática es secundario el proyecto de circuitos lógicos, ya sea con mínima cantidad de compuertas, o con compuertas de un solo tipo, o para integrarlos en un chip de un computador. Esto es propio de un ingeniero electrónico, que necesita una enseñanza intensa del álgebra de Boole y de la síntesis con chips de muy alta integración circuital, amén de conocimientos profundos sobre física electrónica, electricidad y electrónica. En las carreras de informática interesa en primer lugar el funcionamiento de los circuitos citados en el item 1 que componen una UCP, y si se pretende un nivel de enseñanza superior, dichos circuitos pueden interconectarse a fin de conformar una UCP, sin apelar a la electrónica. El Álgebra de Boole debe ser una herramienta formativa en Informática, en el sentido de que los alumnos en primer lugar puedan entrever isomorfismos entre las funciones Or, And y negación y estructuras lógicas del lenguaje Assembler y de lenguajes de alto nivel. Así, existen a nivel de máquina instrucciones en bajo nivel que ordenan operaciones And, Or, negación, X-Or usadas en programas; e inversamente, mediante una estructura IF puede describirse la tabla de funcionamiento de una compuerta. Didácticamente la enseñanza se simplifica, es más comprensible y se reducen tiempos, si los circuitos se construyen sólo con compuertas And, Or e inversores, como ocurre en la metodología planteada. Además es necesario conocer los símbolos de la lógica clásica para comprender formalmente las operaciones lógicas que realiza la UAL, o escribir en forma compacta mediante sumas de productos un comportamiento circuital And-Or, con el que puede expresarse verbalmente cualquier tabla de funcionamiento mediante las conectivas “o” e “y”. Resulta así un correlato conceptual y didáctico entre el álgebra de Boole y el álgebra de proposiciones. Esto es la base para que los alumnos de Informática puedan construir un circuito And-Or suma de minitérminos a partir de una tabla de funcionamiento que debe cumplir, desarrollando de esta forma en ellos aptitudes generales para

1607

proyectar. Así, a partir de la tabla de un sumador completo, se sintetiza un circuito que cumpla con ella, para poder construir luego con 4 u 8 de éstos el sumador/restador de una UAL y los flags que ella genera. Si bien una expresión booleana tiene la relevancia cognitiva y formativa de expresar formalmente con pocos símbolos una tabla o un comportamiento circuital, didácticamente es discutible si al inicio de la enseñanza de los circuitos lógicos se deben desarrollar forzosamente métodos algebraicos para simplificar usando Karnaugh, o para pasar de un circuito a otro equivalente mediante De Morgan. Estos desarrollos producen discontinuidades didácticas en el proceso de enseñanza-aprendizaje del funcionamiento de los circuitos lógicos. Esto se manifiesta en que al abordar el tema de la UAL, o siguientes, muchas veces los alumnos, por el tiempo transcurrido, no tienen presentes temas básicos vistos al comienzo, por lo que hay que volver a repasarlos. Por otra parte, una enseñanza analítica de circuitos basada exclusivamente en expresiones booleanas puede tornarse demasiado abstracta o árida para muchos alumnos. En este sentido, si se quiere verificar algebraicamente que una expresión booleana se corresponde con una tabla, el alumno debe reemplazar en forma abstracta valores binarios en esa expresión. Este procedimiento puede volverse algo mecánico y atemporal, alejando al alumno de una primera apreciación empírica y directa del funcionamiento de un circuito And-Or corriente. En cambio, como se ejemplificará, una simple inspección visual inmediata de cada And con inversores que conforma dicho circuito And-Or, determinará directamente qué combinación binaria hace valer uno la salida de la And, y en consecuencia también la salida de la Or. De este modo se va construyendo conceptualmente la tabla buscada. Si en lugar de una expresión booleana, se parte de una tabla de funcionamiento, siempre se tiene una visión totalizante del comportamiento que debe proveer cualquier implementación circuital que se deduzca de ella, y de hecho proporciona más información que un plano con compuertas que simboliza un circuito digital que cumple con esa tabla, o que la expresión algebraica que sintetiza su respuesta. Consecuentemente, a los fines didácticos, en la metodología presentada se dará más preeminencia a las tablas que a sus expresiones algebraicas. Por otra parte en la asignatura Matemática Discreta de la carrera de Informática es corriente enseñar el álgebra de Boole, incluidas las formas normales y la minimización, ocurriendo a veces superposiciones en la enseñanza de temas. En relación con la enseñanza de flip flops, no es imprescindible partir de los asincrónicos, y es suficiente desarrollar el “D” sincrónico, con sus dos estados fácilmente recordables: uno cuando la salida copia la entrada (con Ck=1) y el otro cuando retiene (con Ck=0). Con este flip flop se construirán los registros de la UCP y las celdas de memoria. De esta forma, si con cuidado se prescinde de contenidos propios de Ingeniería Electrónica, es factible reducir las horas de clases que ello implica, y se pueden desarrollar en un par de clases los circuitos de la UCP y memoria. En el corto tiempo que insume este aprendizaje tipo “mecano”, se van construyendo uno tras otro, circuitos combinacionales y secuenciales de complejidad progresiva, usando sólo compuertas And, Or e inversores. Ello redunda en que sin saltos temáticos los alumnos puedan integrar y sistematizar más fácilmente los aspectos comunes y diferentes del funcionamiento de los mismos. A posteriori es factible integrar estos circuitos para conformar una UCP básica completa, que también puede desarrollarse en un reducido número de clases.

3. Esquema con aspectos básicos de la plataforma propuesta En el inicio del proceso de enseñanza-aprendizaje presentado se procura que el alumno pueda establecer correspondencias y equivalencias conceptuales y visuales de significados simbólicos entre una tabla, un circuito And-Or que la verifica y una suma de productos minitérminos que lo expresa. Al respecto, a partir de las tablas de las compuertas And y Or se verifica y pone de relieve que su denominación está relacionada con el hecho de que la relación entre entradas y salida se puede enunciar con proposiciones lógicas con las conectivas “o” e “y”, a la par que se definen la simbología circuital de cada compuerta y su expresión algebraica, poniendo de relieve que son tres formas distintas de simbolizar lo mismo. A continuación en cada una de las entradas de una And se conecta o no un inversor (conexión que abreviaremos Inv-And), se determina la tabla de este conjunto y se verifica visualmente en el conexionado que la salida de la And vale 1 para una sola combinación presente en las entradas del conjunto Inv-And. Didácticamente conviene poner de relieve por simple examen visual, que para un conjunto Inv-And existe una única combinación que puede hacer que todas las entradas de la And valgan 1 para que su salida valga 1. Como ilustra el Inv-And más alto de la figura 1 su salida vale 1 sólo si en sus entradas se tiene Ai = 0 “y” Bi =1 “y” Ci-1 =1 que producirán 1 “y” 1 “y” 1 en las entradas de la And. Los alumnos así internalizan la correspondencia: combinación binaria <==> Inv-And que la detecta unívocamente. En lo que sigue, didácticamente usaremos en forma modular y visual conjuntos Inv-And para detectar combinaciones con dos usos complementarios: a) dado un Inv-And construido, determinar visualmente qué combinación da valor 1 a su

1608

salida; y b) dada una combinación a detectar, construir por simple inspección visual un Inv-And que la identifique mediante el valor 1 de su salida.

Tabla 1 Ai

Ci-1

0 0 0 0 1 1 1 1

0 0 1 1 0 0 1 1

0 1 0 1 0 1 0 1

0 0 0 1 0 1 1 1

0 1 1 0 1 0 0 1

figura 1 Luego de las verificaciones con Inv-And, en las que fundamentalmente interviene la vista, ya pueden desarrollarse circuitos decodificadores de 2 y 3 entradas, basados en estos módulos Inv-And detectores de combinaciones, lo cual también sirve para que los alumnos afiancen conocimientos. Para el decodificador de 3 entradas los alumnos deberán construir 8 módulos Inv-And para identificar del 000 al 111, y hacer el cableado necesario para que todos reciban juntos la combinación presente en las entradas del decodificador. Además verificarán que sólo tendrá valor 1 la salida del decodificador correspondiente al Inv-And construido para detectar la combinación presente en las entradas del decodificador. En Informática es importante vincular el funcionamiento de un decodificador con el carácter random de cualquier memoria electrónica, planteando que en éstas el número binario de n bits que recibe el decodificador es la dirección de la celda a acceder, y que cada una de sus 2n salidas termina en una celda, para permitir el acceso a ella cuando es direccionada. Seguidamente puede analizarse un circuito Inv-And-Or de 3 entradas, en el que varios Inv-And de igual número de entradas concurren a una Or como en la figura 1 con el objeto de hallar por inspección visual la tabla que el circuito verifica, supuesta desconocida. A tal fin primero los alumnos deben reconocer que algunos de los Inv-And son los mismos que se han tratado en el decodificador. O sea que los 4 Inv-And del circuito dado conforman un decodificador que no detecta 8 sino sólo 4 combinaciones distintas (011, 101, 110, 111), determinables visualmente por la ubicación de los inversores en cada Inv-And. La salida de la Or toma valor 1 si cualquier salida de un Inv-And vale 1. Ello ocurrirá si la salida del Inv-And superior detecta, como muestra la figura 1 (por la ubicación de su inversor) que en las entradas del circuito se ha recibido 011 (Ai=0 “y” Bi=1 “y” Ci-1=1); “o” si el Inv-And siguiente detecta que se ha recibido 101 (Ai=1 “y” Bi=0 “y” Ci-1=1); “o” si el anteúltimo Inv-And detecta que se ha recibido 110; “o” si el último Inv-And detecta que se ha recibido 111. Así se obtienen las 4 combinaciones 011, 101, 110 y 111 a las que les corresponden los 4 “unos” de la tabla 1. Como cada una de las restantes combinaciones no puede generar salida 1 en ninguno de los 4 Inv-And, ellas producirán 4 ceros en las entradas de la Or, o sea salida cero en ella. Con esta técnica, partiendo de un circuito Inv-And-Or, con igual número de entradas en cada And, con sólo examinarlo visualmente, se puede determinar la tabla que cumple. A cualquier circuito Inv-And-Or como el analizado se le puede hacer corresponder un enunciado del álgebra proposicional como el anterior usando las conectivas “o” e “y”, lo cual permite al alumno tener una comprensión más clara de su funcionamiento lógico. Este tipo de enunciados se pueden formalizar en el álgebra de Boole mediante sumas de productos minitérminos, que se corresponden circuitalmente a estructura Inv-And-Or con compuertas And de igual número de entradas. Si se quiere también puede hallarse la suma de productos minitérminos propia del circuito con las correspondencias simbólicas “+” y “.” para las conectivas “o” e “y” respectivamente, y con las convenciones simbólicas que se aplican para escribir minitérminos. Así el funcionamiento anterior puede expresarse: _ _ _ Ci = Ai.Bi.Ci-1 + Ai.Bi.Ci-1 + Ai.Bi.Ci-1 + Ai.Bi.Ci-1 . No es obligatorio tratar este tema al comienzo de la enseñanza. Tampoco se plantea hallar la tabla buscada reemplazando en esa suma de minitérminos cada combinación, de 000 a 111 en este caso, siendo que ella se ha obtenido concretamente observando directa y simplemente las entradas de los Inv-And, para así determinar las combinaciones (tantas como InvAnd distintos existan) para las cuales la columna de salida de la tabla vale 1. 1609

Habiendo los alumnos asimilado la metodología visual de análisis del comportamiento de un circuito, puede plantearse el procedimiento inverso: a partir de una tabla como la tabla 1 (que en este ejemplo debe cumplir la salida Ci de un semisumador), construir paso a paso el circuito Inv-And-Or (suma de minitérminos) que la verifica, el cual aparece terminado en la figura 1. El tipo de circuito buscado ya fue analizado por los alumnos, y al igual que cualquiera a sintetizar, será del tipo Inv-AndOr, de estructura y funcionamiento lógico que se corresponde con un enunciado que emplea las conectivas “o” e “y”. Procediendo de forma inversa al análisis, a partir de la tabla se determina que en este caso son 4 la cantidad de combinaciones a detectar que deben generar el valor 1 en la salida de la Or final. Este número también establece que serán necesarios 4 módulos detectores Inv-And, cuyas salidas irán a una Or que así tendrá 4 entradas (figura 1). La ubicación de los inversores en cada uno de los 4 Inv-And sigue la misma técnica usada en la construcción del decodificador, o sea depende de la posición de los ceros de cada combinación a detectar que debe hacer valer 1 a la salida. Así se llega al circuito de la figura 1, y luego con 4 semisumadores se puede construir un sumador/restador de 4 bits, que forma parte de una UAL. Empleando esta metodología de síntesis, a partir de la tabla de funcionamiento de que se trate, los alumnos están capacitados para construir el correspondiente circuito combinacional Inv-And-Or. Con la presente propuesta, desde el inicio de la enseñanza de circuitos lógicos es factible ahorrar muchas horas de clase sin desviar la atención del alumno en temas como métodos algebraicos de simplificación de funciones, transformación de expresiones booleanas en Nand-Nand, u otros. La enseñanza de flip flops parte de un circuito selector (multiplexor) de 2 entradas (figura 2) cuya entrada de selección S oficiará de reloj (Ck) en el flip flop sincrónico “D” que resulta simplemente de realimentar la salida Q en la entrada inferior del selector (figura 3). Los alumnos comprenden en primer lugar que de este modo el cable de realimentación obliga a que el valor que tiene la salida Q del selector sea siempre el mismo que presenta la entrada inferior, o sea que el propio circuito da valor a una de sus entradas, por lo que así ésta no recibe valor 0/1 del exterior.

Figura 2

figura 3

Los alumnos comprenden en primer lugar que de este modo el cable de realimentación obliga a que el valor que tiene la salida Q del selector sea siempre el mismo que presenta la entrada inferior, o sea que el propio circuito da valor a una de sus entradas, por lo que así ella no recibe valor 0/1 del exterior. A continuación resulta claro, con los valores indicados (figura 4), que mientras sea Ck = 1 se selecciona la entrada D vinculada al exterior, por lo que la salida Q “copiará” el valor 0/1 que D recibe: si D mantiene su valor así lo hará Q, pero si D cambia también lo hará Q, tantas veces como lo haga D, sin posibilidad de mantener su valor. Esta situación (como ilustra el dibujo superior de la figura 4) se simboliza con fines didácticos y mnemónicos con la caja del flip flop en la cual un cable virtual une la salida Q con la entrada D, siendo que en un cable conductor un extremo tiene el mismo valor (voltaje) que el otro.

figura 4

figura 5

figura 6

Si luego se hace Ck = 0 (figuras 5 y 6) se selecciona la entrada inferior, que continuamente tiene el valor 0/1 de la salida, por estar conectadas ambas por el cable que las une. Entonces, el valor que tenga Q en el instante en que es Ck = 0 (que es 1610

el mismo que tenía la entrada D en ese momento), será el de la entrada inferior. Conforme al funcionamiento del selector este valor debe aparecer en la salida Q, por lo que el valor que tenía Q en el instante en que Ck = 0 no podrá modificarse mientras sea Ck = 0, dado que en la entrada inferior permanentemente está ese mismo valor de Q (figuras 5 y 6). Así el valor de Q se autorepite, se automantiene, quedando retenido, memorizado, aunque el valor de la entrada D cambie al valor contrario, dado que por no estar D seleccionada, su valor no puede cambiar la salida Q. Como ilustran los dibujos superiores de las figuras 5 y 6 se simboliza mnemónicamente en cada caso esta situación de retención de un cero o uno mientras sea Ck = 0, con la salida Q autoinyectándose el valor que tiene, y la entrada D aislada de la salida, sin poder intervenir en el valor de Q. Para cambiar el valor que mantiene la salida Q, se debe hacer Ck = 1, con lo cual se volverá a seleccionar la entrada D para que su valor pase a la salida, al mismo tiempo que se deja de seleccionar la otra entrada, para que la salida no se copie a sí misma. Si bien el valor realimentado de la salida Q está siempre presente en la entrada inferior debido al cable que las une, sólo se repite en Q cuando esta entrada está seleccionada por ser Ck = 0. Con este tipo de flip flop sincrónico resulta más sencillo de entender a los alumnos cómo un circuito puede retener un bit. Asimismo es el único que necesitan conocer en la presente plataforma de enseñanza. Su funcionamiento se fija y sistematiza mediante los diagramas temporales correspondientes. No es imprescindible desarrollar los flip flops asincrónicos como el R-S, ni partir de éste para enseñar flip flops. Mediante flip flops “D” sincrónicos puede conformarse un registro, como se indica en la figura 7. Conforme a la experiencia docente acumulada al respecto, puede estimarse que los temas hasta acá planteados pueden desarrollarse en 2 clases de 5 hs. cátedra.

4. Aplicación del método propuesto a la enseñanza de una porción de la UCP El ejemplo siguiente apunta por un lado a poner de manifiesto las ventajas didácticas en la enseñanza que resultan de visualizar los flips flops (M-E) que conforman los registros mediante los mnemónicos de sus 2 estados, con Ck = 1 y Ck = 0 antes simbolizados. Por otro lado permite apreciar cómo los alumnos pueden comenzar a incursionar progresivamente en un modelo de UCP, para ver de qué forma concreta los MHz generados por un cristal actúan en el hardware configurando ciclos, y cómo las líneas de control de la UC determinan el ciclo en que un registro debe cambiar. Si bien el ejemplo de la figura 7 ilustra una porción limitada de una UCP, con la presente metodología didáctica puede construirse una UCP básica completa, que contenga: la UC con líneas de control cuyos valores ella genera en cada ciclo, la UAL, los caminos de datos (“data paths”), los registros básicos, el decodificador y una matriz de conexionado. Un modelo pedagógico de esta UCP que data del año 2007 se desarrolla en un cuadernillo del autor [6] destinado a los alumnos, que debe actualizarse en función de nuevos planteos didácticos planteados en este trabajo. El registro típico de la figura 7 está conformado por flip flops sincrónicos D “maestro-esclavo” cuyos instantes de cambio están sincronizados por los pulsos (designados Ck) recibidos por todos los flip flops simultáneamente, siendo que estos pulsos llegan sin invertir a las entradas Ck de todos los esclavos (E), e invertidos a las entradas Ck de los maestros (M). En el conjunto dibujado el registro es representativo del Puntero de Instrucciones de la UCP, al cual en uno de los ciclos de los MHz al valor (0110) que contienen sus E se le quiere sumar 0010, para que en ese ciclo los E pasen a guardar la dirección (1000) de la próxima instrucción a localizar en memoria. La estructura y comportamiento de este registro son iguales a los de cualquier otro registro de la UCP vinculado a los caminos de datos (“data paths”). En el inicio del ciclo que corresponda se debe poder aportar una copia del contenido del registro involucrado a donde ordene la instrucción en curso, y si es necesario, en ese mismo ciclo se debe poder reemplazar dicho contenido por otro nuevo, cuando el cristal genera el pulso con que termina ese ciclo. Esto sólo es factible si los flip flops “D” sincrónicos son “maestro-esclavo” (M-E), o sea compuestos por dos de estos flip flops simples. Como aparece en la figura 7, en un ciclo determinado una compuerta And genera un pulso reloj que permitirá, en su flanco ascendente, que los M retengan el nuevo contenido (1000), que será copiado por los E, que lo guardarán en el otro flanco. Para ello una entrada de dicha And recibe continuamente los pulsos de los MHz que genera un cristal, y la otra está conectada a una línea de control (LC) de la UC, cuya circuitería hace que esta LC tenga valor 1 durante todo este ciclo en que supuestamente debe cambiar el presente registro. Por lo tanto durante ese ciclo la salida de la And generará una réplica de la forma de onda que produce el cristal de los MHz, la cual así llegará a los flip flops del registro como señal Ck. Durante los ciclos en que la LC tenga valor 0, la salida de la And valdrá 0, por lo que también será Ck = 0 en los E, que así estarán en estado de retención, permitiendo que el registro almacene. Más en detalle, en el inicio del ciclo en que LC = 1 y hasta el flanco ascendente del pulso de ese ciclo, como el cristal de los MHz genera 0 volts, la salida de la And valdrá 0, lo cual determina que en los E sea Ck=0, y en los M sea /Ck=1. Entonces, conforme al funcionamiento de estos flip flops, en ese lapso los E seguirán reteniendo el contenido (0110) que tenían, como en sus cajas simboliza cada salida reinyectando su valor, y estos cables transmitirán 0110 al sumador, que le suma 0010 resultando 1000 en sus salidas. Éstas van a las entradas D de los maestros, que por recibir Ck=1 se comportan como cables que copian 1000 a sus salidas Q que llegan a las entradas D de los esclavos.

1611

Esta situación persiste hasta que la salida de la And valga 1 por ser LC=1 y por generar valor 1 el cristal de los MHz. Entonces, en los M será /Ck=0, por lo que pasarán a retener 1000 que era el último valor que tenían sus salidas Q en ese instante, como se simboliza ahora con sus salidas reinyectando su valor. Dado que los E reciben Ck=1, se comportarán como cables cuyas salidas Q copian el valor 1000 que reciben de las salidas de los M que están reteniendo. Por lo tanto, las salidas de los E, que son las salidas del registro, enviarán al sumador el valor 1000 que si bien no está retenido en los E, permanece invariable mientras los E retengan. El sumador adicionará 0010 y generará 1010, pero este nuevo valor no pasará a las salidas del registro, pues los M están reteniendo 1000, por lo que no permiten que 1010 pase a los E. Al inicio del siguiente ciclo y en los sucesivos se supone que LC=0, por lo que la salida de la And será 0 y nuevamente en los E será Ck=0 y /Ck=1 en los M, repitiéndose la situación esquematizada en la figura 7 superior. Por lo tanto en dicho inicio los E pasarán a retener 1000, que era el último valor que tenían sus salidas Q en ese instante del inicio del siguiente ciclo. A su vez en los E será /Ck=1, por lo que sus salidas copiarán nuevamente el nuevo valor 1010 de las salidas del sumador, que ahora no puede pasar a los E dado que están en estado de retención hasta que no sea otra vez LC=1.

figura 7

1612

De esta forma los alumnos, con la ayuda de los dos esquemas mnemónicos de los dos estados del flip flop, pueden visualizar más claramente este proceso que ocurre en un solo ciclo en el cual el registro primero aportó 0110 al sumador, y luego pasó a almacenar el nuevo valor 1000 que el sumador generó en un primer tramo del ciclo. Si bien en lo que resta del ciclo los E transmiten 1000 al sumador, el nuevo valor 1010 que pasa a generar el sumador no puede llegar a los E pues en ese lapso los M retienen 1000. Este ejemplo también sirve para que los alumnos entiendan la necesidad de que cada flip flop sea M-E. De no existir los maestros que al retener 1000 no “dejan pasar” el 1010, el sumador volvería a sumar 0010 n veces mientras sea Ck = 1.

5. Implementación de la metodología propuesta y del modelo Como se indicó, el presente desarrollo didáctico ha sido puesto en práctica con excelentes resultados y perfeccionado continuamente en las asignaturas “Estructura del Computador“, de 3er. año de Ingeniería Informática de la FIBA (20002006), y Sistemas de Computación II de 1er. año la Facultad de Tecnología Informática de la UAI (de 2004 al presente). También ha sido implementado sin problemas por los profesores adjuntos de Sistemas de Computación II, Ing. Enrique Douce e Ing. Ricardo Martín, del 2010 al presente. Alumnos provenientes de escuelas comerciales manifestaron que nunca pensaron que podrían comprender tan en profundidad el funcionamiento de un procesador. También ha permitido avanzar más rápidamente en el dictado de otros temas como control microprogramado, RISC y CISC y el lenguaje Assembler. Asimismo los alumnos en los exámenes finales mostraron una comprensión más cabal del tema.

6. Conclusiones Es factible en 2 clases de 5 hs. cátedra desarrollar con la metodología propuesta la enseñanza del funcionamiento de los circuitos lógicos básicos, y en 3 clases adicionales construir con ellos un modelo didáctico simple de UCP de características RISC. Para los circuitos se parte de la capacidad de establecer correspondencias visuales sencillas e intuitivas entre combinaciones binarias y compuertas And con inversores en sus entradas, de modo que la salida de cada And valga 1 sólo para la combinación que se desea detectar con ella. En forma didácticamente gradual, cada nuevo nivel alcanzado engloba los anteriores y permite pasar al siguiente, hasta llegar a los circuitos concretos básicos de una UCP. El modelo simple de UCP permite que el alumno deje de tener una comprensión abstracta acerca de muchos detalles importantes que interesan, especialmente en relación con la temporización de las señales internas de la CPU durante la ejecución de las instrucciones, dado que el modelo le proporciona una forma concreta de visualizar en el espacio y tiempo el interior de una UCP. Como todos los modelos de este tipo ayuda entre otras cosas: a entender por qué una máquina no piensa; cómo una instrucción se ejecuta en pasos que ya están predeterminados por el hardware (construido por el hombre) en función del código de operación; a comprender el papel de los pulsos reloj y el de las señales de control en el manejo de los caminos de datos (“data path”); a visualizar los movimientos internos que tienen que ocurrir en dichos pasos; a constatar cómo los circuitos combinacionales transforman el código de operación en señales de control. De este modo, el alumno se sentirá capacitado para abordar, analizar y comparar modelos con pipe line y modelos de CPU reales.

7 Bibliografia 1. 2. 3. 4. 5. 6.

Stallings, W.: Computer Organization and Architecture. 9/E, Prentice Hall (2013). Tanenbaum, A.: Structural Computer Organitation, 6/E, Prentice Hall (2012) Murdocca M., Heuring V.; Principios de Arquitectura de Computadoras. Prentice Hall –Pearson Education (2002) Alcalde E., Portillo J., Garcia Merayo F.: Arquitectura de Ordenadores, McGraw-Hill (1999) Hamacher V, Vranesic Z, Zaky S. Computer Organization, McGraw-Hill (1996) Ginzburg M.: De la Compuerta al Computador (2007), Biblioteca Técnica Superior (2007)

1613

FUN : una herramienta did´ actica para la derivaci´ on de programas funcionales Araceli Acosta1 , Renato Cherini1 , Alejandro Gadea1 , Emmanuel Gunther1 , Leticia Losano2 , and Miguel Pagano2 1 FaMAF - Univ. Nacional de C´ ordoba {aacosta,cherini,gadea,gunther}@famaf.unc.edu.ar 2 FaMAF y CONICET {losano,pagano}@famaf.unc.edu.ar

Introducci´ on

Existen diversas razones que nos llevan a reflexionar sobre las problemáticas del aprendizaje de la programación en contextos universitarios y de la formación universitaria de los profesionales de la programaci´ on. Por un lado, en el presente contexto donde el sector TIC tiene una incidencia cada vez mayor sobre el PBI nos debemos preguntar sobre las capacidades de la industria del software para brindar soluciones de calidad y proveer garant´ıas de la corrección de los productos; en particular teniendo en cuenta la creciente importancia de métodos formales en la industria [6]. En este sentido es importante reflexionar sobre cómo la curr´ıcula de las carreras de computación ayuda a desarrollar las habilidades necesarias que permitan a sus estudiantes y egresados comprender las bases te´ oricas y utilizar las herramientas pr´ acticas que permiten producir software confiable. Por otro lado, la obligatoriedad de la educación secundaria da lugar a una población de ingresantes a las carreras de computación más heterogénea que en otras épocas, con distintos recorridos escolares, en particular en lo que respecta a las habilidades lógico-matemáticas. Esto nos presenta el desaf´ıo de lograr una mayor permanencia de los estudiantes en las carreras manteniendo el nivel de excelencia y calidad. La incorporación de tecnolog´ıas de la información a la ense˜ nanza de los conceptos básicos de lógica y programación puede ser de gran utilidad para este prop´ osito. En este trabajo se describe la utilización de una herramienta desarrollada para la ense˜ nanza de lógica y programaci´ on. En la sección 2 se presentan el contexto de utilizaci´ on de la herramienta y se aborda la perspectiva didáctica; en la sección 3 se describen los conceptos b´ asicos a ense˜ nar con esta herramienta. En la sección 4 se describe la utilización de la herramienta con ejemplos. En la secci´ on 5 cerramos con las conclusiones de nuestro trabajo.

Una perspectiva para ense˜ nar programaci´ on

El primer curso de programaci´ on en la carrera de la Lic. en Cs. de la Computaci´on de Fa.M.A.F es “Introducci´on a los algoritmos” y se dicta en el primer

1614

Araceli Acosta et al.

semestre de primer a˜ no. El objetivo de este curso es introducir la programaci´ on en peque˜ na escala como la transformaci´ on de especificaciones formales en programas ejecutables; las habilidades que se espera los estudiantes adquieran son la capacidad de modelar problemas formalmente, el uso de la lógica como herramienta para razonar sobre y probar la corrección de programas. El dictado de este curso tiene una interesante experiencia acumulada durante diez a˜ nos y fruto de ello es el libro [2], utilizado como material principal durante el semestre. Esta experiencia también se traduce en ciertas miradas reflexivas sobre el curso. Desde 2007 algunos investigadores han desarrollado investigaciones focalizadas en este curso [5, 3] que permitieron comprender mejor los procesos de aprendizaje involucrados en el mismo y delinear algunas de las dificultades experimentadas por los estudiantes. A partir de entrevistas a estudiantes, en [3] se rescatan algunas percepciones de los estudiantes: (i) una importante discontinuidad entre los contenidos y las formas de estudio propias de la escuela secundaria y las de la universidad, en particular este curso; (ii) dificultades, particularmente en los primeros meses, para mantener el ritmo de estudio; (iii) frecuentes impedimentos para avanzar en la resolución de los ejercicios debidas a la falta de conocimiento de los detalles del lenguaje de programación. En [5] se analizó cómo los alumnos iban construyendo demostraciones formales, qué estrategias empleaban y qué recursos utilizaban; develando que “la construcci´ on de una prueba no sigue el car´ acter lineal que posee una prueba una vez finalizada”. Para los estudiantes elaborar una demostraci´ on era un proceso con idas y vueltas donde se recurr´ıa a compa˜ neros y profesores y se utilizaban artefactos, principalmente el listado de axiomas del cálculo. El proceso implicaba realizar cálculos auxiliares, probar distintos caminos –algunos infructuosos– y la discusi´ on con los colegas del curso. Teniendo en cuenta estas dificultades, se inició el proyecto Theona [1] con el objetivo de desarrollar material pedag´ ogico y herramientas didácticas informáticas que faciliten los procesos de aprendizaje de los alumnos en el curso. En estos dos a˜ nos se desarrolló, financiados parcialmente por Fonsoft, el material de texto y cuatro herramientas did´ acticas: Equ permite realizar demostraciones, automáticamente verificadas, de fórmulas ecuacionales. Sat ayuda a comprender el significado de f´ ormulas lógicas de primer orden que involucren cuantificadores a través la adecuación de mundos de objetos geométricos y propiedades de dichos modelos expresados en fórmulas lógicas. Fun permite derivar programas funcionales a partir de especificaciones formales; y también verificar la corrección de programas. Hal es un asistente de construcción de programas imperativos con el uso de sistemas asercionales. 2.1.

Introducci´ on a la programaci´ on funcional

La curricula a abordar con la herramienta consta de dos unidades temáticas: introducción a elementos de lógica y especificaciones y derivación de programas

1615

FUN : una herramienta did´ actica para la derivaci´ on de programas funcionales

funcionales. El motivo de esta elección es que el proceso de desarrollo de software en la peque˜ na escala puede basarse en la especificación del problema en una f´ ormula l´ ogica (complicada, por cierto) y que a partir de esa fórmula se pueden realizar manipulaciones simb´ olicas para obtener otra expresión formal: el programa que resuelve en forma algor´ıtmica el problema especificado en la fórmula. Otra perspectiva que admite este curso es la verificación de programas: dada una especificación y un programa (digamos programado por otro estudiante), cómo podemos convencernos que el mismo satisface su especificación. Para ello, podemos utilizar la misma maquinaria l´ ogica para demostrar que el programa efectivamente hace lo que la especificación prescribe. L´ ogica para especificaciones La primera unidad temática está dedicada a los elementos de la lógica necesarios para poder escribir especificaciones. El énfasis está puesto en los elementos que componen un lenguaje formal, primero a través de la introducción de un lenguaje de expresiones aritméticas, para pasar luego a un lenguaje de f´ ormulas y el sistema de pruebas de esta lógica. Notemos que en este contexto el estudiante se enfrenta por primera vez a ciertos elementos que son comunes a cualquier lenguaje de programación: constantes, operadores y su aridad, variables, un elemental sistema de tipos y una gramática que definen las frases v´ alidas del lenguaje. Pensamos que esta primera aproximación a los fenómenos sintácticos en una lógica proposicional tiene la ventaja de no lidiar directamente con un lenguaje de programaci´ on. La elección del lenguaje de expresiones aritméticas tiene como ventaja que uno puede explicar informalmente la semántica de las expresiones (y de las fórmulas) sin necesidad de introducir nociones de modelos; la noci´ on de pruebas es, básicamente, una secuencia de ecuaciones justificadas por proposiciones (ya sean axiomas, teoremas o hip´ otesis), donde cada paso ecuacional es correcto si los términos de la ecuación coinciden sintácticamente con la justificación. También en este momento se discuten las nociones de satisfacción y validez, nuevamente pensando en la sem´ antica natural de las expresiones aritméticas. En una segunda etapa se extiende la lógica proposicional a lógica de predicados tipada; ésta incluye cuantificadores lógicos y aritméticos, tales como la sumatoria, la productoria y el conteo. En este pasaje aparecen nuevos conceptos sintácticos que también son comunes a lenguajes de programaci´ on, en particular la noción de ocurrencias libres y ligadas de variables, renombre de variables ligadas, sustitución. Con las expresiones cuantificadas se introducen las especificaciones de funciones que, a través de razonamientos ecuacionales, serán transformados en expresiones del lenguaje de programación funcional. Programaci´ on funcional El lenguaje de programaci´ on, descrito en la sec. 3.1, permite la declaraci´ on de funciones a través de constantes, operadores, patternmatching y recursi´ on mutua. La noción de computación en este tipo de lenguajes se basa en la reducción de expresiones hasta llegar a los valores, o formas can´ onicas. Este paradigma de programación tiene la ventaja de ser cercano a la práctica matemática que se tiene habitualmente, en tanto el orden de las reducciones no afecta el valor final de la computación, puesto que no hay una manipulaci´ on

1616

Araceli Acosta et al.

de un estado. Otra buena raz´on, a nuestro entender, para utilizar lenguajes de programaci´ on funcionales para introducir las nociones elementales es la ausencia de variables de estado, en este sentido las variables son realmente variables matem´ aticas cuyo valor no var´ıa temporalmente.

Conceptos b´ asicos

En esta secci´ on daremos un descripci´ on general de los conceptos a abordar mediante la utilizaci´on de la herramienta. Estos conceptos se fundamentan en lo descripto en la secci´ on anterior.

3.1.

Lenguaje de programaci´ on

El lenguaje de programación que utilizaremos es un lenguaje funcional que una sintaxis similar a Haskell. Este lenguaje incluye expresiones aritméticas y expresiones booleanas proposicionales. Por ejemplo, se puede definir la función de elevar al cuadrado de la siguiente manera cuadrado : Int → Int cuadrado.x = x ∗ x La programaci´ on funcional se funda, sobre todo, en la definición de funciones sobre tipos inductivos; para lo cual se utilizan las definiciones recursivas. Los tipos inductivos que incluye el lenguaje son los naturales y las listas. El lenguaje, al igual que Haskell, permite definiciones utilizando patrones (pattern matching). Por ejemplo para sumar todos los elementos de una lista y teniendo en cuenta que las listas son tipos inductivos, definidos a partir de un caso base y un caso inductivo, la funci´ on sum puede ser definida utilizando esa estructura. sum : [Int] → Int sum.[] = 0 sum.x . xs = x + sumar.xs Existen una serie de operadores predefinidos para las expresiones aritméticas, booleanas y para operar sobre listas. Ejemplos de operadores sobre listas son concatenar dos listas (+ + ), calcular la cantidad de elementos de una lista (#), etc. A cada definición que hemos dado, la acompa˜ nan expresiones que determinan el tipo de la función. La utilización de un sistema con chequeo estático de tipos ayuda a detectar errores, pero a la vez ayuda a la legibilidad de la funci´ on. Por otro lado, desde el punto de vista didáctico, el tipado de expresiones y funciones es una herramienta importante con la que cuentan los estudiantes para la elaboraci´ on de nuevas funciones.

1617

FUN : una herramienta did´ actica para la derivaci´ on de programas funcionales

3.2.

Sistema formal

El objetivo de un sistema formal es explicitar un lenguaje en el cual se realizarán demostraciones y las reglas para construirlas. Esto permite tener una noción muy precisa de lo que es una demostración, as´ı también como la posibilidad de hablar con precisión de la sintaxis y la semántica de las expresiones y fórmulas del lenguaje. En una materia introductoria a la programaci´ on estos conceptos son importantes, dado que un lenguaje de programación es un sistema formal. El dise˜ no de este sistema formal permite, por un lado, demostrar la corrección de programas y derivar programas a partir de su especificación, ya que el lenguaje de programación est´ a incluido en el mismo; y por otro lado, nos permitió desarrollar una herramienta autom´ atica de verificación de demostraciones y derivaciones de los programas. Además de las expresiones aritméticas, booleanas proposicionales y sobre listas incluidas en el lenguaje de programación, se agregan las expresiones cuantificadas; que son de mucha utilidad para la especificaci´ L on de programas y propiedades. Una expresión cuantificada tiene la forma h x : R.x : T.xi que se entiende como T.x0 ⊕ T.x1 ⊕ T.x2 ⊕ . . . donde xi satisface el predicado R. Los P cuantificadores que utilizados son el para todo (∀), el existe (∃), la sumatoria ( ), la productoria Q ( ) y el contador (N ). Para especificar, por ejemplo, la función sum que se definió recursivamente en la secci´ on anterior, se puede describir de la siguiente manera X sum.xs = h i : 0 6 i < #.xs : xs.ii 3.3.

Reglas de inferencia y demostraciones

Para completar el sistema formal se definen una serie de axiomas y teoremas básicos, demostrados a partir de los axiomas, y un sistema deductivo basado en la lógica ecuacional al estilo de Dijkstra, que utiliza la transitividad y la regla de Leibniz como reglas de inferencia, y se introduce el método inductivo cuando est´ an implicados tipos inductivos. Los axiomas sobre los que se trabaja son un conjunto de f´ ormulas para la lógica proposicional y para la lógica de cuantificadores. Para la aritmética se axiomatizan algunas propiedades sobre los n´ umeros naturales, necesarias a veces para demostraciones inductivas sobre naturales, y otras propiedades se dejan a criterio del estudiante, es decir, se pueden utilizar como paso en una demostración, pero no se verifican formalmente. Una demostraci´ on dentro del sistema formal consiste en probar la validez de una fórmula mediante una serie de pasos justificados con axiomas y teoremas ya demostrados. A continuaci´ on se muestra un ejemplo particular de la aritmética: (x > 0) ∨ (x 6 0) ≡ { Aritmética } (x > 0) ∨ ¬(x > 0) ≡ { Tercero excluido (P ∨ ¬P ≡ T rue) } True

1618

3.4.

Araceli Acosta et al.

El proceso de construcci´ on de programas

En la actualidad es ampliamente aceptado que el proceso de construcción de programas debe dividirse en al menos dos etapas: la etapa de especificaci´ on del problema y la etapa de desarrollo del programa o de programaci´ on. El resultado de la primera etapa es una especificaci´ on formal del problema, la cual sigue siendo abstracta (poco detallada) pero est´ a escrita formalmente. La segunda etapa da como resultado un programa y una demostración de que el programa es correcto respecto de la especificaci´ on dada. A esta demostración se la llama verifiaci´ on. Por ejemplo, a continuación se muestra la demostración de la correcci´ on de la función sum cuya especificación y definición recursiva se introdujo anteriormente. La demostración consiste en una prueba que, para cualquier lista xs, la función sum satisface la especificación. Esta demostración se puede hacer a partir de los axiomas y teoremas básicos del formalismo y utilizando el principio de inducción. El caso base P supone que on la especificación se P la lista es vac´ıa. En esta situaci´ convierte en .[ ] = h i : 0 6 i < #[ ] : [ ]!ii que se demuestra trivialmente. Para el caso inductivo la especificación toma la forma: X sum.(x . xs) = h i : 0 6 i < #(x . xs) : (x . xs)!ii que se demuestra a continuación P h i : 0 6 i < #(x . xs) : (x . xs)!ii = { Definici´ P on de # } h i : 0 6 i < 1 + #xs) : (x . xs)!ii = { Teorema separaci´ P on del primer término } (x . xs)!0 + h i : 0 6 i < #xs : (x . xs)!(i + 1)i = { Definici´ Pon de ! } x + h i : 0 6 i < #xs : xs!ii = { Hip´ otesis inductiva } x + sum.xs = { Definici´ on de sum } sum.(x . xs) 3.5.

Derivaci´ on de programas

Hasta aqu´ı se desarrollaron tres etapas para la construcción de un programa. En primer lugar, elaborar una especificación formal para el mismo. En segundo lugar, construir el programa. En tercer lugar, dar una demostración de que dicho programa satisface la especificación. A la construcción en simultáneo del programa y de su verificación se la llama derivaci´ on. En este proceso se parte de una especificación formal de una función y a través de transformaciones de la expresión se encuentra la definición de la función. Esta metodolog´ıa fue desarrollada a partir de los trabajos de E. W. Dijkstra. En la sección 4 se describe un ejemplo de derivación utilizando la herramienta.

1619

FUN : una herramienta did´ actica para la derivaci´ on de programas funcionales

FUN : una herramienta did´ actica

FUN es una herramienta que consiste en un IDE (entorno de desarrollo integrado) para escribir en un lenguaje de programación y de demostraciones matemáticas. Este lenguaje permite definir progamas funcionales, especificaciones de programas, realizar pruebas matemáticas utilizando lógica proposicional y de predicados, y realizar derivaciones de programas de acuerdo con los conceptos introducidos en la secci´ on anterior.

Figura 1: La pantalla principal de FUN

En la sección central de la pantalla se muestra un editor de textos, a la derecha está la lista de axiomas disponibles para utilizar como justificación en las pruebas, en la secci´ on de abajo se ve una consola de informaci´ on y otra de evaluaci´ on, y m´ as abajo botones para poder ingresar caracteres unicode fácilmente. El programa permite escribir y chequear pruebas del cálculo proposicional y de predicados. Las pruebas se realizan mediante la declaraci´ on de teoremas. Por ejemplo consideremos el teorema de doble negación ¬¬p ≡ p, ver la Fig. 2b. Para realizar la prueba de ¬¬p ≡ p se utiliza un teorema auxiliar teo1, Fig. 2a. Para justificar los pasos de la prueba, el usuario puede utilizar una cantidad de axiomas seleccionándolos mediante la interfaz o escribiendo literalmente sus nombres, puede utilizar teoremas ya probados previamente o hipótesis, y también puede utilizar definiciones de funciones. Una vez que se escribe un módulo (un archivo que contiene definiciones de funciones, demostraciones y/o especificaciones) el usuario puede chequear que el

1620

Araceli Acosta et al.

(a) Teorema auxiliar

(b) Doble negaci´ on

Figura 2: Demostraciones de teoremas

mismo sea correcto y la herramienta mostrará la lista de todas las declaraciones indicando con una tilde si la misma es correcta, Fig. 3a o con una cruz cuando no lo es, Fig. 3b. Si alguna declaración tiene un error, cuando se hace click sobre la misma en el panel izquierdo, en la consola de informaci´ on se muestra un mensaje de la raz´ on por la cual la misma no es correcta, Fig. 3c. La derivación de funciones en el entorno FUN sigue el mismo proceso que se explic´ o en la secci´ on anterior; en las Figs. 4a y 4b se muestran respectivamente los casos bases e inductivos de la derivaci´ on de la sumatoria de una lista. Como se puede ver, en ambos casos la expresi´ on final no contiene cuantificadores y por lo tanto es un programa evaluable. El lenguaje funcional subyacente a FUN fue definido y estudiado formalmente en [4]; utilizando la semántica operacional all´ı definida se implement´ o el evaluador integrado en el entorno. El usuario puede evaluar una expresión paso-a-paso hasta la expresi´ on can´ onica.

Conclusiones y trabajos futuros

En el art´ıculo hemos presentado una metodolog´ıa para la ense˜ nanza de programación enfatizando la importancia de contar con una especificación formal. El aporte más novedoso de este art´ıculo es la herramienta FUN , que permite al estudiante realizar la derivación, programación y verificación en un u ńico entorno. La herramienta le brinda al estudiante la posibilidad de corregir sus propias derivaciones sin necesidad de la supervisión de un docente. En el próximo a˜ no se espera utilizar el material de estudio producido y las herramientas informáticas en el dictado del curso “Introducción a los algoritmos”.

1621

FUN : una herramienta did´ actica para la derivaci´ on de programas funcionales

(a)

(b)

(c)

Figura 3: M´odulos y sus definiciones

(a)

(b)

Figura 4: Derivaci´on de sum

1622

REFERENCIAS

A partir del uso intensivo de las herramientas se contará con un importante feedback para mejorarlas, tanto en funcionalidades como en interfaz. En otras l´ıneas de trabajo se est´ an desarrollando herramientas que complementan estos contenidos curriculares. En particular, se está desarrollando una herramienta, Hal, que persigue los mismos objetivos que FUN pero orientada a la programación imperativa; esto implica un cambio completo de paradigma. Esta herramienta permitirá completar con los contenidos conceptuales de un curso introductorio de programación desde la perspectiva formal.

Referencias [1] Araceli Acosta y col. Proyecto Theona. http : / / www . theona . com . ar/. Mayo de 2013. alculo de Programas. [2] Javier Blanco, Silvina Smith y Damián Barsotti. C´ Universidad Nacional de Córdoba, 2009. isbn: 978-950-33-0642-0. [3] Javier Blanco y col. “An introductory course on programming based on formal specification and program calculation”. En: SIGCSE Bull. 41.2 (jun. de 2009), p´ ags. 31-37. issn: 0097-8418. doi: 10.1145/1595453.1595459. [4] Emmanuel Gunther. “Entorno para la Derivacion de Programas”. Tesis de lic. Universidad Nacional de Córdoba - Facultad de Matemática, Astronom´ıa y F´ısica, jul. de 2013. [5] Leticia Losano. “Procesos situados de aprendizaje en cursos básicos deprogramación: volverse miembro de una comunidad”. Tesis doct. Universidad Nacional de C´ ordoba - Facultad de Filosof´ıa y Humanidades, abr. de 2012. [6] Mariëlle Stoelinga y Ralf Pinger, eds. Formal Methods for Industrial Critical Systems. Vol. 7437. Berlin, Heidelberg: Springer Berlin Heidelberg, 2012. isbn: 978-3-642-32468-0. doi: 10.1007/978-3-642-32469-7.

1623

Metodología innovadora para el Estudio y Programación de Microprocesadores en Arquitectura de Computadoras. Jorge R Osio, Daniel Alonso, Eduardo Kunysz, Martín Morales Universidad Nacional Arturo Jauretche Instituto de Ingeniería – Ingeniería Informática Av. Clachaquí 6200, Florencio Varela, Argentina josio@unaj.edu.ar, martinmorales@unaj.edu.ar

Abstract. Este Trabajo presenta una Metodología de enseñanza de Microprocesadores, con una etapa de programación en Assembler, la cual facilita la comprensión en el funcionamiento interno de un microprocesador y el rol que tienen los registros en el mismo. Adicionalmente, se plantea una etapa de aplicación de los Microprocesadores en el Diseño de Sistemas Digitales mediante Programación de software para sistemas embebidos. Dicha metodología se está implementando en la Asignatura de Organización y Arquitectura de Computadoras. La propuesta se encuadra dentro del Método inductivo básico a través de Simulación con kits e instrumental de diseño de Sistemas Embebidos. Este método se considera apropiado, teniendo en cuenta el contenido a enseñar y la necesidad de incluir la enseñanza de Programación de Sistemas Embebidos basado en sistemas Procesadores en las carreras de Informática. La Programación de Software embebido en sistemas Microprocesadores, se presenta como un Trabajo de Laboratorio que se va desarrollando a lo largo de toda la materia. Keywords: Organización y Arquitectura de Computadoras, Microprocesadores, Sistemas Embebidos, Metodologías innovadoras, Estrategias Educativas.

Introducción

Para una mejor descripción de la metodología de enseñanza, se comienza por realizar una descripción del área dentro de la especialidad en donde se encuentran incluida la materia. Luego de esto, se describe la metodología en sí misma, acompañada de los contenidos de la materia. El área de enseñanza se denomina ARSO y abarca las materias de Arquitectura, Redes y Sistemas Operativos, las cuales están fuertemente vinculadas al Hardware dentro de las Ciencias Informáticas. Entre los Objetivos y Contenidos se busca describir la importancia de introducir al alumno en el funcionamiento y constitución del Microprocesador y mediante la programación del mismo a bajo nivel, acompañando los fundamentos teóricos con una fuerte parte práctica que permite a los alumnos desarrollar y ejercitar la capacidad de diseño de un programa y la resolución de problemas. Por otro lado se pretende introducir el concepto de software embebido mediante la realización de un Laboratorio a lo largo de toda la cursada, mediante un kit de desarrollo basado en un sistema microprocesador Cortex M3, que permite potenciar la programación de microprocesadores en alto nivel para aplicaciones complejas que involucran la implementación de Sistemas Operativos de Tiempo Real (RTOS) y Aplicaciones con interfaces Ethernet, para potenciar los conceptos adquiridos en redes. La metodología presentada pretende demostrar cuan eficiente es aplicándola en el área ARSO mediante el respaldo de un grupo docente fuertemente capacitado para dar soporte y ayudar al alumno a desarrollar la capacidad de razonamiento sobre los temas en cuestión. Dicha Metodología se está aplicando actualmente en la material Organización y Arquitectura de Computadores del Instituto de Ingeniería de la UNAJ.

2 Descripción del Área Las materias básicas del Área, son “Organización y Arquitectura de Computadoras” y “Sistemas Operativos I” dictadas en el tercer semestre de la carrera, luego “Redes de Computadora I” se dicta en el cuarto semestre, el resto de las materias del área se ubican en tercer y cuarto año de Ing. Informática. La aplicación de la metodología se centra en Organización y Arquitectura de Computadoras, en donde se contempla la descripción de un microprocesador y sus aplicaciones, además se presentan conceptos de programación de un sistema procesador en lenguaje de alto nivel con

1624

aplicaciones relacionadas a las demás materias del área, todo esto mediante un Laboratorio obligatorio a realizarse durante toda la materia. Cabe aclarar que con las aplicaciones no se pretende explicar temas que serán impartidos en otras Materias, pero se abre una puerta para profundizar sobre estos temas de manera práctica y aplicada.

3 Objetivos y Contenidos Los objetivos en relación a los contenidos de la materia “Organización y Arquitectura de Computadoras” son los siguientes: 

Matemática Discreta - Sistemas de Numeración - Algebra de Boole - Sistemas lógico y compuertas

 Comprensión del funcionamiento de un procesador. Estudio desde el punto de vista físico y lógico de los microprocesadores: - Diagrama de bloques. Buses. Registros. Instrucciones. Modos de direccionamiento. Estructura algorítmica. (CPU) - Periféricos de entrada/salida. Proceso de interrupción. Temporizadores. Comparadores y capturadotes.(MCU) 

Tipos y Selección de procesadores genéricos - Estado del arte y criterios comparativos de procesadores



Utilización de procesadores genéricos: - Programación en Assembler mediante un Microrpocesador básico  Caso de Estudio HC08 de Freescale (facilita la comprensión de funcionamiento)  Aplicaciones de algoritmos matemáticos y planteo con Diagrama de Flujos - Programación en C, Realización de experiencias concretas con elementos de entrada/salida  Caso de estudio Microprocesador Cortex M3  Aplicaciones con periféricos.



Descripción de las Distintas Arquitecturas de Computadores - Evolución y Performance de las Computadoras



Memorias - Memoria Cache - Memoria Interna - Memoria Externa



Entradas / Salidas



Soporte para Sistemas Operativos



Estudio de Arquitecturas de Microprocesadores populares - Arquitecturas X86 - Arquitectura ARM para Sistemas Embebidos

4 Materiales de Estudio y Herramientas de trabajo Para la implementación de esta metodología es estrictamente necesario lograr una estrecha relación entre los materiales de estudio y las herramientas de trabajo. Es por eso que en cada Trabajo práctico siempre se agrega la información necesaria para que el mismo pueda ser resuelto sin problemas. Por otro lado el hecho de usar herramientas específicas de HW, hace necesario proveer materiales específicos para cada herramienta, ya sea, mediante apuntes de cátedra o mediante manuales o notas de aplicación relacionadas con las herramientas.

1625

4.1 Materiales de Estudio -

Bibliografía básica [1 - 8] Apuntes de cátedra [9] Manuales Técnicos y notas de aplicación del microcontrolador HC908 y del kit de Desarrollo LPC1769 [10 14] Bibliografía de aplicaciones [15] y [16]

4.2 Herramientas de Trabajo Dentro de las herramientas de trabajo se deben incluir la Computadora, como una herramienta indispensable para realizar toda la parte práctica. 4.2.1. Herramientas de Trabajo Las herramientas de trabajo indispensables para llevar a cabo la metodología son: -

Kit de Desarrollo LPC1768, (ver fig. 1) Placa Base con los siguientes componentes: o Componentes para implementación de diferentes protocolos (serial, SPI, I 2C,PWM, USB, Ethernet) o Componentes básicos (leds, potenciómetros, dimmers, joystick) o Micrófono y parlantes para aplicaciones de audio o Memoria Flash externa o Interfaz con display gráfico o Interfaz USB (HOST y HID) o Interfaz Ethernet o Puertos de E/S

Software para diagramas de Flujo. Software de compilación y simulación en circuito (Win IDE, ver Fig. 2) Software IDE LPCxpresso, Permite crear proyectos en C para Microcontroladores de 32 Bits basado en Microprocesadores ARM de la Firma NXP, (ver Fig. 3). Integra un conjuntos de Herramientas que permiten compilar y hacer debugging en circuito, también permite crear proyectos a compilar con el software Mingw.

5 Características de la Cursada 5.1 Contenidos Teóricos de la Cursada En Principio se describen los componentes de una Computadora y se presenta la evolución y desempeño de las mismas. Se detallan cada una de las partes Principales que la conforman como las distintas memorias (memoria cache, Memoria interna y Memoria externa) y se describen las entradas y salidas. También se explica el soporte para Sistemas operativos. También, se dictan los detalles del Procesamiento, Como la Aritmética Computacional, Características del Set de Instrucciones, Modos de direccionamiento y la Unidad de Control. Esto último tanto para la Arquitectura HC08 de Freescale, luego se comparan características de X86 de Intel y de la Arquitectura ARM. Luego se describen los Registros, Modos de Direccionamiento, Bifurcaciones, Saltos y subrutinas e Interrupciones del Microprocesador HC08 de Freescale con Registros que manejan datos de 8 bits, para la programación en Assembler. En una segunda Etapa se describen los Módulo de Entrada/Salida, Módulo de temporización, Comunicaciones Serie (SPI, SCI, I2C, Ethernet, USB, entre otros). 5.1 Contenidos Prácticos de la Cursada    

TP1. Rendimiento de Computador TP2. Sistemas de Numeración TP3. Algebra de boole TP4. Circuitos Lógicos y Partes de Microprocesador. Concepto de Procesamiento de Instrucción

1626

   

TP5: Ejercicios sobre Modos de direccionamiento y set de instrucciones basados en el HC08. TP6: Programación de operaciones basadas en los principales sistemas de numeración y algoritmos matemáticos con simulación en Assembler. (Realización de Diagramas de Flujo) sobre el HC08. TP7: Memoria externa. Discos Rígidos. RAID. I/O. Manejo de Memoria y paginado Laboratorio Obligatorio de Programación de Interfaces de e/s sobre una Arquitectura ARM en C. Este laboratorio consiste en la explicación de las interfaces que se enumeran a continuación y culmina con una aplicación que involucra las distintas interfaces sobre la placa LPC 1769. - En este Laboratorio se utiliza el kit de programación junto con una Placa Base, permitiendo implementar una comunicación RS-232, USB y Ethernet. - Aplicaciones con Display Gráfico - Realización el control de un sistema calefactor – refrigerante mediante el sensado de temperatura y el accionamiento de una resistencia calefactora o un ventilador según el valor de temperatura sensado. Realizar aplicaciones de almacenamiento de datos mediante una memoria externa mediante la interfaz SPI - Realizar aplicaciones de procesamiento digital de audio.

Fig. 1. El KIT de desarrollo LPCxpresso LPC1114 está formado por el LPC-Link, el cual es un programador que permite programar toda la Familia de Microcontroladores de NXP y hacer debugging en Circuito. Adicionalmente viene acompañado por un Target que contiene un Microcontrolador LPC1114 con un Microprocesador ARM Cortex M0 para Aplicaciones.

Metodología de Enseñanza

La metodología de enseñanza tiene en cuenta cuatro factores principales para la instrucción del Alumno:   



El primer factor consiste en hilvanar los temas vistos en materias anteriores. Esto se logra, integrando los conocimientos vistos anteriormente en un Trabajo Práctico, mediante ejercicios que involucran operaciones y algoritmos matemáticos. De la misma manera se integran los Contenidos de “Organización y Arquitectura de Computadores” con “Sistemas Operativos I”, Aprovechando la implementación de un Sistema Operativo de Tiempo real en el Laboratorio, aplicando en la Práctica los conceptos adquiridos en dicha materia. Los dos Factores principales están muy estrechamente ligados y coordinados para lograr instruir al alumno de manera que pueda fijar los conocimientos teóricos mediante la aplicación práctica de los mismos. Por un lado, la programación en Assembler de un microprocesador básico fortalece los conceptos de funcionamiento de un procesador y las posibles aplicaciones de sus registros. Por otro lado, involucra la aplicación de las reglas del buen programador mediante la planificación del código mediante el Diagrama de Flujos correspondiente. Por último, se puede considerar como factor complementario el hecho de incluir dentro del Laboratorio, aplicaciones que involucran temas y elementos específicos de otras materias de Informática, mediante la Programación en Lenguaje de Alto nivel de código para Sistemas embebidos, la realización de aplicaciones que contienen elementos de materias del área ARSO, etc.

6.1 Metodología de Teoría

1627

Las clases teóricas se dictan mediante filminas ilustrativas que permiten al alumno apreciar detalles de Imágenes y gráficos de manera interactiva. Los temas teóricos están diagramados de tal manera que los alumnos puedan fijarlos mediante la correspondiente clase práctica, de manera casi simultánea. 6.2 Metodología Práctica La metodología práctica está diagramada en dos módulos, como se detalla en la sección 5. En el primer Módulo se presenta una práctica que consiste en determinar mediante diferentes técnicas la eficiencia y rendimiento en sistemas Computadores. Introducir al alumno en los sistemas de numeración, especialmente los utilizados en sistemas digitales. Enseñar al alumno a representar las distintas partes de un microprocesador mediante compuertas lógicas y por último, introducción al alumno al funcionamiento de un Computador, mediante la descripción de la composición y funcionamiento de un Microprocesador, de las jerarquías de memoria y de los periféricos I/O. Los Trabajos Prácticos 5, 6 y el laboratorio se realizan en Computadora con diferentes herramientas de software. En cada clase los alumnos tienen una introducción a las prácticas dictada por el Profesor a cargo del Curso y luego los alumnos realizan parte de los ejercicios correspondientes al Trabajo práctico en cuestión. La primera parte del segundo módulo consiste en programar código assembler profundizando sobre las características y funcionamiento de un microprocesador (en cuanto a registros, set de instrucciones, códigos de operación y modos de direccionamiento). En esta instancia el alumno comienza a utilizar el software WINIDE, de la Fig. 2, mediante la compilación y la simulación de código. Luego sigue una Práctica que consiste en la programación y simulación en assembler de ejercicios que requieren el manejo de datos, la conversión entre sistemas de numeración, implementación de operaciones matemáticas y de algoritmos matemáticos y de comunicaciones. Cabe aclarar que previo a cada programa se deben realizar el diagrama de flujo describiendo el funcionamiento que deberá realizar el programa. Este tipo de ejercicios hace que el alumno desarrolle la capacidad de programar de manera ordenada y de resolver problemas.

Fig. 2. Compilador y Simulador en Circuito WINIDE.

Es importante destacar que los alumnos forman comisiones de tres integrantes para realizar El Laboratorio, lo cual fortalece el trabajo en grupo, en donde además de la aplicación a implementar, deben realizar un informe y presentarlo en una clase al resto del curso. El Laboratorio, consiste básicamente en la programación en Lenguaje C de los módulos periféricos E/S que permiten la interfaz entre el microprocesador y otros dispositivos. De esta manera se realiza el control de un Display gráfico, de varios módulos externos como memorias flash mediante interfaz I2C, interfaz USB, interfaz Ethernet, Free RTOS y procesamento de audio mediante PWM, etc. Para la programación del Microcoprocesador Cortex M3 se utiliza el software LPC xpresso que se muestra en la Fig. 3.

1628

Fig. 3. Entorno de Desarrollo Integrado LPCxpresso, que permite Programación en C y debugging en circuito para Microcontroladores de NXP basados en Microprocesadores ARM Cortex.

Finalmente, con el Laboratorio se introduce al Alumno a la programación de Software para sistemas Embebidos, se presentan aplicaciones relacionadas con Sistemas operativos de tiempo real y Ethernet, permitiendo aplicar los conceptos profundizados en las demás materias del área. Se implementa el envío de datos a una memoria externa, aplicando los conceptos de jerarquía de memoria. Por último, se realizan aplicaciones con periféricos I/O, lo cual permite comprender la idea de interfaz E/S en un Computador y buses y se exploran las distintas posibilidades que ofrece un Sistema procesador ARM. Se debe aclarar que cada curso se compone de un profesor a cargo y un máximo de 30 alumnos, es por eso que se puede llevar a cabo esta modalidad tan demandante.

7 Resultados Obtenidos Entre los resultados obtenidos se puede destacar que la programación en Assembler de un microprocesador de 8 bits con registros básicos favorece la comprensión del funcionamiento del mismo y las posibles funciones que pueden cumplir los registros. De un total de 120 alumnos repartidos en 4 cursos de 30, se presentaron a los exámenes 104 alumnos, sobre los cuales se obtuvieron los resultados de la Tabla 1, en donde se muestran los resultados luego de las evaluaciones correspondientes a los temas relacionados con el microprocesador, tales como modos de direccionamiento, registros, set de instrucciones y ejecución de instrucciones, programación en Assembler. Tabla 1. Resultados de las evaluaciones del Segundo módulo referentes al microprocesador y su funcionamiento. Tema evaluado Descripción teórica de ejecución de instrucciones en un microprocesador Realización de diagramas de flujo Programación en Assembler Modos de direccionamientos y set de instrucciones Utilización de registros y memoria

Sin Respuesta 4% 40% 15% 2% 15%

Respuesta correcta 90% 45% 60% 90% 65%

Respuesta incorrecta 6% 15% 25% 8% 20%

En la Tabla 2 se puede observar como influyeron los conceptos aplicados mediante la programación de un microprocesador en Assembler, en los alumnos que tuvieron que rendir en la última fecha flotante de la materia el módulo 1. Tabla 2. Comparativa de los temas relacionados con el microprocesador evaluados en el primer módulo antes y después de programar en Assembler y explorar las características del microprocesador . Evaluación de conceptos sobre microprocesadores en el primer módulo Examen del primer módulo sobre un total de 115 alumnos

Sin Respuesta 10%

Respuesta correcta 60%

Examen flotante del primer módulo sobre un total de 20 alumnos

95%

Respuesta incorrecta 30% 0%

1629

8 Conclusiones Como conclusión se puede decir que esta metodología ayuda al alumno a familiarizarse con todas las herramientas digitales disponibles en el diseño y Programación de Sistemas Embebidos y le provee una buena preparación para desempeñarse como profesional en esta área. Entre las Herramientas presentadas y utilizadas en la Cátedra se presentan las diferentes Familias de Microprocesadores que son usados en una amplia gama de aplicaciones para Sistemas Embebidos y Sistemas Computacionales. Por un lado se realizan aplicaciones sobre un microcontrolador de 8 bits de baja gama como es el HC08, en donde se pueden visualizar y utilizar los principales registros de un procesador, mediante la programación en bajo nivel de aplicaciones que requieren poco procesamiento y poca memoria. Entre los resultados, se pudo demostrar que esta metodología favorece a la comprensión del funcionamiento del microprocesador y de cada una de sus partes. También se logró fomentar la planificación de un programa mediante diagramas de flujo y la resolución de problemas. Aunque el Laboratorio de software embebidos sobre el kit LPCxpresso aun no nos permite sacar conclusiones por su reciente implementación, es muy evidente que fortalecerá la programación de sistemas embebidos y por otro lado formalizar los conocimientos sobre jerarquías de memorias y Periféricos I/O.

Referencias. 1. Cazares Juan, Haro Diego, Hueso Jaime, Muriel Eduardo, Puebla Luis: Microcontroladores Motorola - Freescale Programación Familias y Sus Distintas Aplicaciones en La Industria, Ed. Alfaomega 2008. 2. Programación de Sistemas Embebidos en C, Gustavo Galeano, Ed Alfaomega, 2009 3. Spasov Ed. Prentice Hall (5th Edition) 2004 4. D. A. Patterson, J. L. Hennessy: Embedded Microcomputer Systems Real Time Interfacing. Ed Thomson 2da Edition 2002 5. D. A. Patterson, J. L. Hennessy: Estructura y diseño de computadores. Ed. Reverté, 2000 6. Computer Organization and Architecture Designing for Performance (8th Edition) –William Stallings 7. Computer Organization and Architecture, (9th Edition) - William Stallings 8. Organización Diseño de Computadores. La interfaz hardware/software, Patterson, David A. – Henessy, John L., Mc Graw-Hill, 1995 9. Jorge R. Osio, Daniel Alonso, Eduardo Kunysz ” Decripción de un Microprocesador– CPU”, Instituto de Ingeniería, UNAJ, 2013 10. Data sheet: MC68HC908QY4 Microcontrolers, Rev. 5, 07/2005 11. Reference Manual: CPU Central Processor Unit Microprocesador, CPU08RM, Rev. 4, 02/2006. 12. The definitive guide to the ARM-Cortex M3, Joseph Yiu, Elsevier Inc, 2010 13. Getting Started with NXP LPCXpresso, Revisión 11.1, Diciembre de 2011 14. LPC111x/LPC11Cxx User manual, revisión 6, Agosto 2011 15. Douglas H. Summerville: Embedded Systems Interfacing for Engineers using the Freescale HCS08 Microcontroller II: Digital and Analog Hardware Interfacing‖, State University of New York at Binghamton, Morgan y Claypool Publishers, 2009. 16. Mark Martinets: Interrupt Handling Considerations When Modifying EEPROM on HC08 Microcontrollers‖, Nota de aplicación, Motorola, agosto de 2002.

1630

Usando NDT como soporte a la enseñanza de programación web Yanina Medina, Gabriel Pedrozo Petrazzini, Cristina Greiner, Gladys Dapozo Departamento de Informática. Facultad de Ciencias Exactas y Naturales y Agrimensura. Universidad Nacional del Nordeste. Corrientes. Argentina {gndapozo, cgreiner, yanina}@exa.unne.edu.ar, gabriel.pedrozopetrazzini@gmail.com Abstract. Se presentan los resultados de la implementación de una metodología de enseñanza de programación para la plataforma web que utiliza la metodología NDT, llevada a cabo en una asignatura de tercer año de la carrera Licenciatura en Sistemas de Información de la Universidad Nacional del Nordeste (UNNE). Esta estrategia surge con el objetivo de afianzar en los alumnos el valor de las buenas prácticas que exige la Ingeniería del Software para lograr desarrollos y soluciones cada vez más completas y robustas. El proceso de aseguramiento de calidad tiene como misión principal garantizar todos los requisitos de calidad establecidos. Para ello, los controles de calidad no deben aplicarse únicamente al código generado, sino que además deben recorrer elementos como los requerimientos, tanto funcionales como no funcionales, que contribuyen a generar conciencia de la importancia que tiene la documentación en el desarrollo de software. Keywords: Enseñanza universitaria, programación web, NDT, documentación.

1 Introducción A pesar de los esfuerzos orientados a la creación de metodologías de desarrollo para la web, el uso sistemático de estas técnicas para la especificación y el diseño de estas aplicaciones no ha resuelto el problema de la producción. Por este motivo, los expertos en tecnologías web han realizado diferentes propuestas para mejorar la calidad de los sitios y aplicaciones web, en forma de metodologías, marcos de calidad, modelos de estimación, guías de estilos y métricas [1]. Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar un producto software. Un caso particular, lo constituyen las metodologías orientadas al desarrollo web. Por sus características, estas requieren una mayor atención en la definición de los requerimientos funcionales y no funcionales, y dentro de estos últimos, a los requerimientos de almacenamiento y de navegabilidad. En un estudio previo [2], se realizó una comparación de metodologías web, analizando en particular el grado de cobertura de las distintas etapas de desarrollo. De las metodologías estudiadas, únicamente NDT cuenta con soporte para todas las etapas del ciclo de vida. Por este motivo, se eligió esta metodología de desarrollo de aplicaciones web, para ser utilizada en la enseñanza de la programación de aplicaciones web, con el objetivo de afianzar en los alumnos el valor de las buenas prácticas que exige la Ingeniería del Software para lograr desarrollos y soluciones cada vez más completas y robustas.

1631

2 NDT NDT (Navigational Development Techniques) es una metodología para especificar, analizar y diseñar el aspecto de la navegación en aplicaciones web [3][4]. El flujo de especificación de requerimientos de NDT comienza con la fase de captura de requerimientos y estudio del entorno, y luego se definen los objetivos del sistema. En base a estos objetivos, el proceso continúa definiendo los requerimientos que el sistema debe cumplir para cubrir los objetivos marcados. Finalmente, se realiza la revisión del catálogo de requerimientos y el desarrollo de una matriz de trazabilidad que permite evaluar si todos los objetivos han sido cubiertos en la especificación. En la Fig. 1 se muestra una descripción general de las actividades de NDT.

Figura 1. Descripción general de las actividades de NDT

2.1 Modelo de Requisitos NDT es un enfoque específicamente creado para el manejo de requisitos de aplicaciones web [6]. Propone el uso de diagramas de casos de usos y varios tipos de plantillas de formato (patrones). Clasifica los requisitos en los siguientes tipos: de información de almacenamiento, de actores, funcionales, de interacción y requisitos no funcionales. Para cada tipo, se define una plantilla especial, consistente en una tabla con campos de texto específicos que son completados por el equipo de desarrollo en la fase de elicitación de requisitos. 2.2 Descripción de la herramienta: NDT-SUITE NDT-Tools, el soporte de herramientas de la metodología NDT, ha tenido que evolucionar para ser una propuesta útil en proyectos reales, dado que sólo cubría las fases de ingeniería de requisitos y análisis [7] [8]. Estas razones impulsaron al Grupo de Investigación Ingeniería Web y Testing Temprano [5] a elaborar NDT-Suite. Esta nueva herramienta soporta las fases de requisitos, análisis, diseño, construcción e

1632

implantación, pruebas y mantenimiento. NDT-Suite está integrada por los diversos componentes, entre ellos, NDT-Profile, NDT-Quality y NDT-Driver. NDT-Profile es una herramienta diseñada sobre un perfil definido, en base a los metamodelos de NDT, sobre la herramienta Enterprise Architect. El profile (perfil) sobre Enterprise ofrece una serie de herramientas y definición de artefactos propios para trabajar con la metodología NDT permitiendo una sencilla gestión de documentación. Las fases de desarrollo incluidas en el proyecto se identifican por las siguientes siglas: - EVS: documento del estudio de viabilidad del sistema. - DRS: documento de requisitos del sistema. - DAS: documento de análisis de sistema. - DDS: documento de diseño del sistema. - DPS: documento de plan de pruebas del sistema. - DMS: documento de mantenimiento del sistema. Además, se introduce una serie información adicional sobre el proyecto: Participantes: se describen las empresas y personas que participarán en el proyecto, Control de Versiones: se describen las diferentes líneas bases, y Objetivos del Proyecto: se describen los objetivos a cumplir en el proyecto.

3 Metodología 3.1 Descripción La asignatura Taller de Programación I, de la carrera Licenciatura en Sistemas de Información, tiene como objetivo profundizar el estudio de herramientas de desarrollo de software orientadas a la plataforma web mediante la programación de aplicaciones. Busca ofrecer al alumno una visión amplia de las tecnologías utilizadas en el desarrollo de aplicaciones web, partiendo desde el diseño de páginas estáticas y de las tecnologías orientadas a la presentación (CSS, JavaScript), repasando tecnologías de cliente para mostrar luego tecnologías de programación para servidores, completando el recorrido con una visión general de acceso a base de datos. En este proceso se pretende consolidar en el alumno las competencias requeridas para un analista programador, tales como el modelado y los métodos y herramientas para la especificación, diseño, implementación y evaluación de aplicaciones informáticas. Esta asignatura contribuye específicamente a la formación del Analista Programador Universitario, título intermedio de la carrera, cuyo perfil comprende el desarrollo, modificación y mantenimiento de aplicaciones informáticas, mediante la utilización de herramientas de desarrollo de uso generalizado en el mercado laboral. Por tanto, se espera que el alumno adquiera destrezas en programación mediante una intensa tarea de desarrollo siguiendo todas las etapas conceptuales de un proyecto de software, desde su especificación hasta su verificación y validación, incorporando además las buenas prácticas que exige la Ingeniería del Software para lograr desarrollos y soluciones cada vez más completas y robustas, haciendo énfasis en la documentación. Para cumplir con este objetivo, se planteó la utilización de la metodología NDT enmarcada en el paradigma de Ingeniería Web guiada por modelos [7].

1633

El eje del trabajo de la asignatura lo constituye el desarrollo individual de una aplicación web sencilla pero completa, que incluya todos los componentes necesarios: modelado de la aplicación, diseño gráfico y de contenidos, gestor de base de datos, tecnologías de programación en cliente y en servidor. Cabe aclarar que, paralelamente al dictado de esta asignatura, los alumnos cursan la asignatura Ingeniería de Software I, con la cual se articulan conceptos, entre ellos, las técnicas de elicitación de requerimientos. Para lograr los objetivos propuestos se realizaron las siguientes actividades: 1. Repaso de las técnicas de elicitación de requerimientos. Estas técnicas que se muestran en la Tabla 1, forman parte de los contenidos de la asignatura Ingeniería de Software I por tanto el repaso consistió en una breve reseña de las principales características de cada una de ellas para que los alumnos las tuvieran en cuenta para al especificar los requerimientos de su aplicación. Tabla 1. Detalle de técnicas de elicitación de requerimientos Fases

Actividades

Ingeniería de Requisitos

Obtener información sobre el entorno y definir objetivos

Identificar y definir los requisitos de almacenamiento de información

Identificar y definir los actores

Identificar y definir los requisitos funcionales Identificar y definir los requisitos de interacción Identificar y definir los requisitos no funcionales

Técnicas Entrevistas JAD Brainstorming Revisiones y búsqueda de información Cuestionarios Concept mapping Patrón para la definición de objetivos Patrón para la definición de requisitos de almacenamiento de información. Patrón para la definición de las nuevas naturalezas Patrón para la definición de actores básicos Diagramas de representación de actores generalizados Matriz para la definición de incompatibilidad de actores Matriz para la definición de actores generalizados Diagramas de casos de uso Patrón para la definición de los requisitos funcionales Patrón para la definición de frases Patrón para la definición de prototipos de visualización Patrón para la definición de requisitos no funcionales

2. Capacitación en la metodología NDT. Se presentó a los alumnos la metodología de desarrollo NDT y se les instruyó en el uso de la herramienta NDT SUITE, que implementa dicha metodología. 3. Consignas para el desarrollo de una aplicación web. Se propuso a los alumnos el desarrollo de una aplicación web con la mayor cantidad de funcionalidades posibles. En primer lugar debían realizar la especificación de requerimientos de su

1634

4. 5.

6. 7. 8.

aplicación web utilizando los patrones aportados por la metodología NDT o el estándar IEEE 830-1998. Definición de la primera instancia evaluativa: Esta consistió en la elaboración y entrega de la especificación de requerimientos de la aplicación a desarrollar. Definición de la segunda instancia evaluativa: Consistió en completar el desarrollo de la aplicación, incorporando el acceso a una base de datos, entregando el producto final junto con su documentación. La utilización de la herramienta NDT Suite, se propuso en forma optativa. Análisis de los trabajos presentados por los alumnos. Se analizaron 17 trabajos de los alumnos que utilizaron la metodología NDT, con el objetivo de evaluar el grado de aplicación de la metodología. Encuesta de satisfacción a los alumnos. Se realizó una encuesta on line con la herramienta GoogleDocs, destinado a recabar la percepción de los alumnos respecto a la metodología de desarrollo propuesta. Elaboración de Conclusiones

3.2 Análisis de los trabajos De la primera instancia evaluativa se analizó el uso de las técnicas de elicitación utilizadas, cuya frecuencia de uso se muestra en la Tabla 2. Tabla 2. Frecuencia de uso de técnicas de elicitación de requerimientos Fases

Actividades

Ingeniería de Requisitos

Obtener información sobre el entorno y definir objetivos Identificar y definir los requisitos de almacenamiento de información

Identificar y definir los actores

Identificar y definir los requisitos funcionales Identificar y definir los requisitos de interacción Identificar y definir los requisitos no funcionales

Técnicas

Nº de casos

11,76%

Revisiones y búsqueda de información anterior Patrón para la definición de objetivos

88,23%

Patrón para la definición de requisitos de almacenamiento de información

70,58%

Patrón para la definición de las nuevas naturalezas

23,5%

Patrón para la definición de actores básicos Diagramas de representación de actores generalizados Diagramas de casos de uso

4 13 13

23,5% 76,47% 76,47%

Patrón para la definición de los requisitos funcionales

41,17%

Patrón para la definición de frases

17,64%

Patrón para la definición de requisitos no funcionales

11,76%

Se observó la utilización de: - Patrones de definición de objetivos: la mayoría (88%) de los alumnos utilizó esta técnica, la cual resulta especialmente útil para la comunicación con el usuario.

1635

Patrón para la definición de requisitos de almacenamiento de información: el 70,58 % de los alumnos lo utilizó, permitiendo la correcta definición de la estructura de la base de datos, que facilita la implementación. - Diagramas de casos de uso y diagramas de representación de actores: 76,47 % Las demás características proporcionadas por la herramienta no fueron aprovechadas. En esta primera instancia de evaluación se pudo observar que la mayoría de los alumnos utilizó las características básicas de la herramienta. Desde la percepción de los docentes de la asignatura el cumplimiento de la consigna no implicó mayor dificultad para los alumnos. En la segunda etapa evaluativa, de acuerdo a los productos entregados y sus respectivas documentaciones generadas por la herramienta NDT-SUITE, se analizaron diferentes aspectos de la metodología: -

a) Tipos de requerimientos: la Tabla 3 muestra los tipos de requerimientos especificados en cada uno de los trabajos. Tabla 3. Tipos de requerimientos especificados Tipos de Requerimientos Almacenamiento de datos De actores Funcionales

Trabajos de los alumnos 7 8 9 10 11

De interacción ND I ND ND ND ND ND ND ND ND D ND D ND ND ND ND No funcionales ND ND ND ND ND ND ND ND ND D ND ND ND ND D ND D D Definidos ND No Definidos I Incompletos

Se observa que la mayoría pudo definir los requerimientos de almacenamiento, de actores y los funcionales. Muy pocos definieron los requerimientos de interacción, como así también, muy pocos especificaron los requerimientos no funcionales. b) Información adicional sobre el proyecto. En la Tabla 4 se muestran los distintos ítems de información adicional que fueron utilizados por los alumnos. Tabla 4. Información adicional del proyecto. Información adicional

Participantes

Control de Versiones Objetivos del proyecto

N D

1 0 N D

1 1

1 2

1 3

1 4

1 5

1 6

1 7

N D

De este punto de análisis se desprende que la mayoría de los alumnos pudieron definir los participantes involucrados en el desarrollo del proyecto, pero la mayoría no

1636

registró los cambios en el Control de Versiones, aun cuando presentaron más de una versión del producto. En cuanto a los Objetivos del proyecto, se observa que algunos alumnos tuvieron dificultades para definir los objetivos del proyecto. c) Análisis de la especificación de los requerimientos en NDT. En la Tabla 5 se observan los distintos ítems analizados en las especificaciones De los valores mostrados en la tabla 5, se desprende que no hubo dificultad en los alumnos en definir con claridad los objetivos de la aplicación web. Tabla 5.Análisis de especificación de requerimientos en NDT

Casos

Claridad en la definición de los objetivos

Coherencia en la definición de los datos de almacenamiento

Completitud en los casos de uso

Consistencia entre los términos utilizados en las diferentes descripciones

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

B MB MB MB MB B B MB MB MB B MB B MB B MB MB

MB B MB R MB MB B B MB B MB MB MB MB B R MB

B B MB R MB B MB MB MB R MB MB B MB MB MB MB

B B MB R MB B MB MB MB B MB MB B MB MB MB MB

Consistencia con el problema (se documenta correctamente con el Caso de Uso) MB B MB R MB B MB MB MB B B MB B MB B MB MB

Completar los casos de uso no representó dificultades en las especificaciones, como tampoco se observó inconsistencias en documentarlos correctamente y en el uso de términos distintos a lo largo del trabajo. Los alumnos tienen muy presentes esos conceptos porque se encuentran cursando la asignatura Ingeniería de Software I. En el análisis de los productos finales se pudo comprobar que, si bien algunos alumnos describieron requerimientos de datos que luego no utilizaron, o viceversa, la herramienta les sirvió para detectar esta situación. 3.3 Análisis de satisfacción de los alumnos Para evaluar el grado de satisfacción de los alumnos respecto a la metodología de enseñanza, se diseñó un cuestionario on-line que se envió a los alumnos. Dado que el cursado ya había finalizado, solamente 7 alumnos aportaron sus opiniones, que se consideran ilustrativas de la situación. Las cuestiones abordadas fueron las siguientes: 1. Simplicidad de la herramienta 2. Claridad de los distintos módulos de la herramienta

1637

3. 4. 5. 6. 7.

Utilidad del manual de usuario ¿La herramienta facilitó el desarrollo de la aplicación? Importancia de la documentación en el desarrollo de software ¿La herramienta contribuyó a la documentación de la aplicación desarrollada? ¿Volvería a utilizar la herramienta en el desarrollo de una nueva aplicación?

Los resultados se presentan gráficamente en las figuras 2 a 7.

Figura 2. Simplicidad de la herramienta

Figura 3. Claridad de los módulos

Figura 4. Utilidad del manual de usuario

Figura 5. Desarrollo de la aplicación

Figura 6. Importancia de la documentación

Figura 7. Contribución a la herramienta a la documentación

En cuanto a la consulta de si volverían a utilizar la herramienta en el desarrollo de una nueva aplicación, la totalidad de los alumnos contestó en forma positiva.

1638

Analizados los resultados obtenidos, se observa que en cuanto a la facilidad de uso de la herramienta y de la comprensión de los distintos módulos (Fig. 2 y 3), la valoración fue mayoritariamente entre 3 y 4 para una escala de 1 a 5, donde 1 es más difícil y 5 más fácil, lo que significa que la comprensión fue de una dificultad media, En cuanto a la utilidad del manual de la herramienta (Fig. 4), el 43% dice que lo utilizó permanentemente, un 28% lo leyó pero no lo necesitó y un 29% opinó que el manual no era muy claro. Vinculado con la herramienta, se les consultó también si su utilización facilitó el desarrollo de la aplicación (Fig. 5), la mayoría (72%) contestó que sí, pero que no fue imprescindible su uso. Respecto de la importancia de la documentación en el desarrollo y de si la herramienta NDT contribuyó a la documentación de la aplicación desarrollada (Fig. 6 y 7), mayoritariamente (57% en ambos casos), opinaron favorablemente. De las respuestas de los alumnos se puede inferir que apreciaron la herramienta por su aporte a la documentación pero, en esta etapa formativa, no les resultó imprescindible. Esta devolución servirá para revisar las consignas dadas en esta estrategia de enseñanza, buscando una mayor integración del modelado de la aplicación, utilizando la herramienta NDT-Suite, y el desarrollo de la misma.

4 Conclusiones Este trabajo presenta los resultados de una estrategia de enseñanza que incorpora la herramienta NDT-Suite para el desarrollo de aplicaciones web. La aplicación de NDT a proyectos reales resultó enriquecedora. En este caso, ha sido especialmente interesante porque los alumnos comprobaron que siguiendo las buenas prácticas en el desarrollo de software proporcionadas por la herramienta NDT Suite se obtiene un producto de calidad. Tanto de los trabajos realizados por los alumnos como de las opiniones de los mismos se desprende que son conscientes de la importancia de seguir una metodología de desarrollo de software para obtener un producto de calidad. La herramienta contribuyó a la valoración de la documentación en los proyectos de software. Al ser una herramienta muy completa, los alumnos podrán seguir avanzando en la utilización de los demás componentes, como por ejemplo el NDT Quality, que comprueba criterios de calidad. Como trabajos futuros, además de resaltar las futuras aplicaciones pero ya en otros perfiles del NDT-Suite, se pretende ampliar la estrategia incorporando la utilización de la herramienta en otras asignaturas vinculadas con la Ingeniería del Software.

Referencias 1.

Abrahão S.M., Poels G., Pastor O., “Evaluating a Functional Size Measurement Method for Web Applications: An Empirical Analysis”, in Proceedings of Tenth International Software Metrics Symposium (METRICS’04), Chicago, Illinois, USA, pp. 358-369, 2004. Pedrozo Petrazzini, Osmar G., Medina, Yanina, Dapozo, Gladys Noemí. “Análisis Comparativo de Metodologías Web”. XIX Reunión de Comunicaciones Científicas y Tecnológicas. Edición 2013. Universidad Nacional del Nordeste. Resistencia. Chaco. Disponible en: http://www.unne.edu.ar/trabajando/com2013/exactas.php

1639

3. 4. 5. 6.

7. 8.

Escalona, M. J. and Koch, N. 2007. Metamodelling the requirements of Web systems. Lecture Notes in Bussiness Information Process, vol. 1, Springer Verlag, 267–288. Escalona, M.J., Mejías, M., Torres, J. “Methodologies to develop web information systems and comparative analysis”. UPGRADE.TVol. III, No. 3, Junio 2002. NDT (Navigational Development Techniques). Metodología desarrollada por el Grupo de Investigación Ingeniería Web y Testing Temprano (IWT2). Universidad de Sevilla. Disponible en: http://www.iwt2.org/web/opencms/IWT2/inicio/?locale=es Escalona, M.J., Torres, J., Mejías, M. (2002). “Requirements capture workflow in Global Information Systems”. Proceedings of OOIS. Springer-Verlag. Montpellier, France. Escalona, M.J.,Gutierrez J.J., Ortega J.A., Aragón G., Pérez Pérez M., Ponce J., “NDT-Suite, una solución práctica para el uso de NDT”. Escalona, M.J., Aragón. G.“NDT. A model-driven approach for web requirements”. IEEE Transaction on Software Engineering. Vol. 34. Nº3. Mayo/junio 2008. IEEE Computer Society.

1640

Declarado de InterĂŠs Municipal por el Honorable Concejo Deliberante del Partido de General Pueyrredon

1641