PROGRAMACIÓN ORIENTADA A OBJETOS EDUCATIVA EN UNA MÁQUINA VIRTUAL BASADA EN PROTOTIPOS J.

Transcripción

1 PROGRAMACIÓN ORIENTADA A OBJETOS EDUCATIVA EN UNA MÁQUINA VIRTUAL BASADA EN PROTOTIPOS J. Baltasar García Perez-Schofield 1, Emilio García Roselló 1, David Martínez Torres 2, Manuel Perez Cota 1 1 Departamento de Informática, Edif. Fundición, s/n, Campus As Lagoas-Marcosende, Vigo, España. {jbgarcia mpcota erosello}@uvigo.es 2 Mixteca. Huajuapan de León Oaxaca - México. dtorres@mixteco.utm.mx La programación orientada a objetos es una las especialidades más importantes a estudiar dentro del campo de las ciencias computacionales. El paradigma de orientación a objetos está ya absolutamente asentado en nuestros planes de estudio, de manera que hoy en día se enseña antes incluso que el paradigma estructurado. De una manera generalizada, el lenguaje que se está adoptando para la enseñanza es Java. Si bien este lenguaje es perfectamente válido, existen otros lenguajes, que siguen otros modelos de orientación a objetos que podrían también ser aplicables e incluso presentar algunas ventajas. En este artículo, se presenta precisamente una máquina virtual diseñada con el objetivo de servir especialmente para la enseñanza, que presenta una naturaleza distinta a la de aquellos lenguajes basados en clases (C++, Java), y con sus propias ventajas para la enseñanza. 1. Introducción A lo largo de los últimos años, ha habido varios intentos de crear plataformas de aprendizaje para la correcta asimilación de los conceptos de programación. Uno de los más llamativos y con más éxito, es probablemente, BlueJ (Kölling et al., 2003). Si bien BlueJ hace más énfasis en un entorno de programación que en un lenguaje de programación, este proyecto supuso en el pasado el desarrollo, efectivamente, de un lenguaje que aportara buena parte de las características que presenta Java (si bien Java es descartado en un principio, aunque favorablemente evaluado en (Kölling, 1999a)). Este lenguaje era Blue (Kölling, 1999b). El proyecto Blue supuso en su momento un estudio de varias características que un lenguaje de programación debería tener para ser considerado adecuado para educación (Kölling, 1999a). Es obvio que este estudio está motivado respecto al aprendizaje temprano (primeros cursos) del paradigma de programación orientada a objetos. Si bien los autores encuentran muy razonables algunas de las características pedidas por Kölling y su equipo para un lenguaje orientado a objetos educativo (por ejemplo "pequeño y simple", "alto nivel", "sintaxis legible", "no redundancia de conceptos", "pureza"...), con uno especialmente los autores de este trabajo muestran su desacuerdo: "seguridad respecto al tipo". Con este último, los autores del proyecto BLUE tratan de proporcionar mayores ventajas al programador novato. Si bien la corrección estática y el fuerte tipado (aplicables a los lenguajes que pueden considerarse estáticos, como C++ (Stroustrup, 1991) y Java (Naughton, 1996)) pueden ser características deseables, y tener importantes ventajas, la dinamicidad (cuando las comprobaciones se hacen VII Congresso Iberoamericano de Informática Educativa 1347

2 tiempo de ejecución, como en Self, por ejemplo) puede tener también interesantes características. Los lenguajes dinámicos comienzan su andadura con Smalltalk (Goldberg & Robson, 1989). Pero todavía más relacionado con el sistema presentado aquí es Self (Smith & Ungar, 1987). Presentaba un modelo de orientación a objetos realmente nuevo en aquel momento: el denominado basado en prototipos. Su característica más destacada era la ausencia de clases. En realidad, este modelo estaba diseñado como un superconjunto del modelo de orientación a objetos basado en clases, mediante la definición de objetos prototípicos, que actuarían como modelos para la creación de nuevos objetos, mediante su clonación. Desgraciadamente, los lenguajes que implementan este modelo no son fácilmente accesibles. Algunos de ellos son dependientes de plataforma (como el mismo Self, de Sun); Smalltalk y también Self presentan una sintaxis que no es sencilla para muchos programadores (novatos y con experiencia, Kölling, 1999a); de hecho, el aprendizaje de este estilo de sintaxis es un tema merecedor de artículos dedicados. como (LaLonde, 2000). Otros lenguajes, como Kevo (que supone una curiosa mezcla entre un lenguaje basado en prototipos (dinámico por naturaleza), y un lenguaje estático, Tailvaisaari, 1992), han sido abandonados. Además de la simplicidad y la dinamicidad, los autores han identificado un tercer punto importante, como es el soporte de persistencia. El interés en esta característica, todavía no soportado totalmente en la máquina, se justifica en que suaviza muchísimo la curva de aprendizaje del paradigma de pogramación orientada a objetos, al no precisar que el programador distinga entre memoria secundaria y primaria (Kölling, 1999a), consistiendo en una capacidad natural de los objetos (como se perfila en García Perez-Schofield & Pérez Cota, 1998). De hecho, en este artículo se presenta una máquina virtual pequeña y simple (lo cual redunda en beneficios para la educación (Smith & Ungar, 1987)), sin soporte para tipos, orientada a objetos pura y basada en prototipos, llamada Zero 1. Si bien los autores no pueden todavía presentar un lenguaje de programación de alto nivel sobre esta máquina, hay ya disponible un macroensamblador, correcto, gracias al alto nivel de abstracción inherente de la máquina, para programación de proyectos de tamaño medio. 2. Programación de la máquina virtual 2.1. Arquitectura de la máquina virtual Las características básicas de esta máquina virtual son las siguientes: 1Disponible en con sus manuales correspondientes. VII Congresso Iberoamericano de Informática Educativa 1348

3 herencia simple, dinámica (implementada mediante delegación) creación y clonación de objetos (y prototipos, indistinguibles de los primeros) paso de mensajes manejo de excepciones persistencia (no implementada todavía). La máquina virtual está basada en registros (que guardan referencias a objetos), estructurándose en dos grandes grupos: el acumulador ( acc), que guarda la referencia resultado de la instrucción anterior, el registro que guarda el objeto que está ejecutando el método, conocido como self en Java ( this), y el registro que guarda la excepción que se haya producido ( exc); y en un segundo grupo los registros generales que pueden ser utilizado para cualquier propósito ( gpn) Compilación de objetos y paso de mensajes Los objetos se crean empleando object y endobject para marcar el comienzo y el fín del objeto, pudiendo crear en su interior atributos (attribute) y métodos (definidos entre method y ). Los mensajes a métodos se realizan, básicamente, utilizando el mismo formato que Java, <nombreobjeto>.<nombremétodo>. Es posible (de hecho, muy habitual) que entre el nombre del objeto y el nombre del método se sitúen varios nombres de atributos, que devuelven una referencia a un nuevo objeto, como en System.console.write(), donde console es un atributo de System. Un listado del típico programa (objeto) HolaMundo, que muestra por consola la cadena " Hola, Mundo!", se muestra a continuación. El objeto HolaMundo envía un mensaje (write()) al objeto de consola (_Zero_Console, accesible desde System) para enviar una cadena a la consola del sistema. object HolaMundo : ConsoleApplication method + doit() parent.prepare()! Preparar la e/s System.console.write(" Hola, Mundo!") System.console.lf() endobject El programa macroensamblador (zm, al que se le pasaría un listado como el anterior), traduce código fuente en macro enamblador para la máquina virtual Zero en su propio bytecode. La máquina virtual (zvm) ejecuta objetos que pueden, como en este caso, residir en un archivo con extensión ".zbj". VII Congresso Iberoamericano de Informática Educativa 1349

4 2.3. Encapsulación y creación de objetos No existe una división especial entre objetos y prototipos. Normalmente, si bien no tiene por qué ser así, los prototipos son objetos definidos en tiempo de compilación, mientras que los objetos son aquellos que se crean mediante la clonación de los primeros, en tiempo de ejecución. Sin embargo, existen otras posibilidades en tiempo de compilación, como clonar un objeto, eliminar o añadir atributos y métodos y emplearlo como prototipo, o incluso, existe la alternativa de crear un objeto vacío (sin métodos ni atributos), heredando de uno dado, pasandole el mensaje createchild(), y añadiendo los métodos y atributos necesarios. Los métodos y atributos, que se marcan con las palabras clave method y attribute, respectivamente, llevan un signo '+', si son públicos, o un signo '-' si son privados. En el caso concreto de los atributos, ni siquiera en el caso de ser públicos, estos pueden ser modificados desde un objeto que no sea el mismo que los posee. El clonado se realiza pasando el mensaje copy() a un objeto. Este mensaje conlleva un argumento que es el nombre del nuevo objeto, si bien puede pasarse una cadena vacío, delegando en el sistema la creación de un nombre para él. En un método pueden existir referencias locales a ese método (frente a las referencias que son locales a un objeto, los atributos), que se crean mediante la palabra clave reference. Las apariciones de enteros, flotantes y cadenas en el código fuente son convertidas, mediante el compilador, a objetos, clonados de LiteralInt, LiteralFloat y LiteralString, respectivamente. La creación del prototipo Punto, su clonado, y la manera de indicar la encapsulación se muestran a continuación: object Punto! Nótese que el prototipo Punto ya es un objeto, por lo! que es necesario dar valores a sus atributos. attribute + x = 0 attribute + y = 0 method + poncoordenadas(a, b) x = a y = b method + tostring() reference toret = "(" toret = toret.concat(x.tostring()) toret = toret.concat(", ") VII Congresso Iberoamericano de Informática Educativa 1350

5 toret = toret.concat(y.tostring()) toret = toret.concat(")") toret endobject object PruebaPunto : ConsoleAplication method + doit()! Crea un objeto reference mipunto = Punto.copy("") mipunto.poncoordenadas(100, 150)! Muéstralo por pantalla this.prepare()! Preparar la e/s System.console.write(miPunto) System.console.lf() endobject La compilación y ejecución de PruebaPunto mostraría por pantalla: (100, 150) 2.4. Herencia La herencia soportada, es, como se ha visto, del tipo simple. Concretamente, existe un atributo especial (todos los objetos lo poseen, denominándose parent) que es aquel que denota al objeto padre de un objeto dado. Así, en el ejemplo anterior, PruebaPunto hereda de ConsoleApplication, lo que le provee automáticamente de la inicialización y el acceso a la consola, por ejemplo. Todos los objetos derivan del objeto Object, la raíz de la jerarquía de herencia. Este objeto provee de las operaciones básicas al resto de objetos, como son, por ejemplo, copy(), createchild(), isthesameas(), getname(),... y otros Polimorfismo La propia naturaleza del lenguaje hace que cualquier paso de mensajes sea necesariamente polimórfico. Concretamente, la herencia se implementa mediante delegación (Smith & Ungar, 1987), y, así, cuando un objeto es incapaz de satisfacer un mensaje, lo reenvía a (delega en) su padre. Mientras un programador de Java lo encontraría natural (si bien en Java la herencia no se implementa mediante delegación), el programador de C++ encontrará que no es necesario indicar virtual delante de cada método que podría ser VII Congresso Iberoamericano de Informática Educativa 1351

6 necesario que soportara una llamada polimórfica Herencia dinámica La herencia dinámica es una ventaja que viene dada gratis por la propia simplicidad y naturaleza dinámica del sistema. Como ya se ha explicado, la herencia viene marcada por un atributo parent. Este atributo, como cualquier otro, puede ser cambiado por el propio objeto. La modificación controlada de este atributo proporciona la característica conocida como "herencia dinámica". En el siguiente ejemplo, un objeto contenedor (concretamente, un vector asociativo) cambia su padre según se cumpla una condición. El primero de ellos es el prototipo EmptyMap, empleado cuando no contiene elementos. Existe, así, el prototipo NonEmptyMap (no mostrado), que es el padre cuando se introducen elementos en el mismo. Este cambio de padre permite simplificar enormemente los métodos lookup(), add() y delete() del objeto (respectivamente, buscar, añadir y borrar), puesto que no es necesario comprobar si existen elementos o no. object EmptyMap : Map method + lookup(name) throw EObjectNotFound method + delete(name) throw EObjectNotFound method + add(name, obj)! Lanzar un mensaje al padre, como "super" en Java this.^add(name, obj) parent = NonEmptyMap endobject Esta técnica no está exenta de problemas. La modificación, sin control, del atributo parent, puede llevar a un programa caótico. En el diseño del lenguaje de alto nivel, se contempla la creación de un mecanismo que permita controlar estas modificaciones. 3. Trabajo relacionado La particularidad que más desmarca a este sistema de programación de los demás es su futuro soporte de persistencia. Un sistema que presenta esta característica de una forma similar a la VII Congresso Iberoamericano de Informática Educativa 1352

7 deseada es PJama (Persistent Java) (Atkinson & Jordan, 2000). Sin embargo, este sistema implementa persistencia ortogonal (Atkinson & Morrison, 1995), mientras que, como se explica a continuación, la diseñada para Zero es sólo un subconjunto de esta última. De hecho, será implementada siguiendo el modelo de persistencia basado en contenedores (García Perez-Schofield et al., 2001), tal y como se empleó en Barbados (García Perez- Schofield, 2002a). Este modelo es vagamente parecido al que presenta el middleware PerDis (Shapiro et al., 1997). Se trata, básicamente, de un particionamiento del almacenamiento persistente visible por el usuario, de manera que puede elegir en qué cluster desea guardar sus objetos. Por supuesto, ésto se recubre con una pequeña capa de abstracción, como un sistema de directorios en el caso de Barbados (García Perez-Schofield, 2002b). El resto de sistemas símplemente no poseen esta capacidad (como BlueJ, que empla Java), o su soporte de persistencia es muy primitivo, como en Self, que directamente guarda una imagen (el fichero es denominado image) de la memoria que permite que los objetos persistan en el entorno de trabajo (workspace) actual entre una ejecución y otra. Será necesario cambiar el fichero de imagen desde fuera de Self para disponer de varios workspaces o realizar todas las aplicaciones en un solo worksapce. Self (Smith & Ungar, 1987), es el sistema, en cuanto a dinamicidad, en el que se inspira Zero. Sin embargo, tanto el macro ensamblador como el lenguaje que se implemente en un futuro cercano no seguirán la sintaxis empleada por Self. Sí es posible que a más largo plazo se realice un compilador de Self como prueba del sistema. En términos de sistema orientado al aprendizaje, los sistemas más parecidos son el lenguaje de programación Blue, con su entorno, de mismo nombre (Kölling, 1999b), y BlueJ, sistema posterior, basado en Java pero de muy similares características (Kölling, 2003). La mayor diferencia entre Zero y este sistema, reside en la natural dinamicidad de Zero (basado en prototipos) en contra de la rigidez estática de Java y Blue (ambos basados en clases), como ya se ha comentado. Cada una tiene sus ventajas e inconvenientes, pero los autores defendemos que la dinamicidad puede presentar características muy positivas. Por otra parte, el sistema presentado aquí no posee ningún entorno integrado de programación que refuerce los aspectos educativos, al contrario que Blue y BlueJ. Su entorno es considerado por los autores de este artículo como ideal para el aprendizaje, y en el futuro se considerará la implementación de uno similar. Oviedo3 (Ortín Soler et al., 2000), es una máquina virtual parecida también a Zero, puesto que, a su vez, está inspirada parcialmente en Self. Sin embargo, Oviedo3 está basada en clases, como Smalltalk, lo cuál no cumple con los objetivos planteados por nosotros los autores. VII Congresso Iberoamericano de Informática Educativa 1353

8 4. Conclusiones Zero es una máquina virtual orientada a objetos pura, multiplataforma, basada en prototipos, y, por tanto, especialmente diseñada para soportar lenguajes dinámicos. El sistema presenta una manera de programar clara, con una sintaxis (incluso empleando un macro esamblador) simple, y soportando de manera sencilla los conceptos de programación orientada a objetos. Su modelo de orientación a objetos es también simple y muy sencillo de entender y aprender, ya que el número de elementos a tratar es muy pequeño 2. No soporta tipos de forma natural (si bien sería posible crear un lenguaje de programación que sea un subconjunto de Java o C++ que sí lo haga, puesto que se engloba el modelo basado en clases), pero esto los autores lo defienden como una ventaja, y no como un inconveniente. Pese a estar en un momento de desarrollo bastante inicial, el sistema ya ha sido empleado con éxito en un curso de doctorado, y en una asignatura de la carrera de Ingeniería en Informática. Gracias al empleo de encuestas, se ha obtenido bastante información que esperamos poder procesar y publicar en breve. Sí está claro, al menos, por parte de los usuarios del sistema, que ven como punto de desarrollo futuro más importante la implementación de un lenguaje de alto nivel, lo cuál será la más alta prioridad de los autores. 5. Trabajo futuro El soporte de persistencia es uno de los puntos más importantes del proyecto, ya implementada parcialmente. De hecho, sólo es necesario proveer a Zero de un almacenamiento persistente (persistent store, Balch et al., 1989). Otros proyectos incluídos en el futuro inmediato de Zero son la creación de un lenguaje de alto nivel y de un entorno integrado, como ya se ha comentado. 6. Bibliografía Atkinson M.P., Morrison R. (1995). "Orthogonality Persistent Object System", VLDB Journal 4(3), , ISSN: Atkinson, M., Jordan, M. (2000). A Review of the Rationale and Architectures of Pjama: A Durable, Flexible, Evolvable, and Scalable Orthogonaly Persistent Programming Platform. Sun Microsystems Technical Report SMLI TR Balch, P., Cockshott, W.P., Foulk, P.W. (1989). Layered Implementations of persistent object stores. Software Engineering Journal, 4(2), De ahí su nombre, Zero, como cero, lo más pequeño y mínimo. VII Congresso Iberoamericano de Informática Educativa 1354

9 Black A. (2003). Post Javaism. Proceedings of the First Workshop on Object-Oriented Language Engineering for the Post-Java Era: Back to Dynamicity. European Conference on Object-Oriented Programming. García Perez-Schofield, B., Pérez Cota, M. (1998). Problemática del uso de ficheros en C++: un enfoque educativo. Revista de Enseñanza y Tecnología. 1(12), García Perez-Schofield B., Cooper, T.B., Pérez Cota, M., García Roselló E. (2001). Extending Containers to Address the Main Problems of Persistent Object Oriented Operating Systems: Clustering, Memory Protection and Schema Evolution. Proceedings of the Fourth Workshop on Object-Orientation and Operating Systems. European Conference on Object- Oriented Programming. García Perez-Schofield, J., Cooper, T., Roselló, E., Pérez Cota, M. (2002a). Persistencia, evolución del esquema y rendimiento en los sistemas basados en contenedores. Tesis Doctoral. Departamento de Informática. Universidad de Vigo. García Perez-Schofield B., Cooper, T.B., Pérez Cota, M., García Roselló E. (2002b). First Impressions about Executing Real Applications in Barbados. Proceedings of the Fifth Workshop on Object-Orientation and Operating Systems. European Conference on Object- Oriented Programming Goldberg A., Robson D. (1989). Smalltalk-80: The Language. Addison Wesley. ISBN Kölling, M., Quig, B., Patterson, A., Rosenberg, J. (2003). The BlueJ System and its Pedagogy. Journal of Computer Science Education, v13(4). Kölling, M. (1999a). The problem of teaching Object-Oriented Programming. Journal of Object Oriented Programming, v11(8). Kölling, M. (1999b). The Blue Language. Journal of Object Oriented Programming, v11(10). LaLonde, W. (2000). I can read C++ and Java, but I can't read Smalltalk. Journal of Object- Oriented Programming. February, Martínez A., Álvarez García F., Ortín Soler F., Cueva Lovelle J. (2000). An OODBMS developed over the Oviedo3 Operating System. Proceedings of the Simposio Español de Informática Distribuida (SEID'2000). Naughton P. (1996). The Java Handbook. McGraw-Hill Ungar, D., Smith, R. S. (1987). "Self: The Power of Simplicity". In Proceedings of VII Congresso Iberoamericano de Informática Educativa 1355

10 OOPSLA'87, Orlando, FL, pp Shapiro, M., Kloosterman, S., Riccardi, F. (1997). "PerDis. A Persistent Distributed Store for Persistent Applications", Proceedings of the 3rd Capernet Plenary Workshop. Stroustrup B. (1991). The C++ Programming Language. Addison-Wesley Taivalsaari A. (1992). Kevo: A prototype-based object-oriented language based on concatenation and module operartions. Technical Report DCS R, University of Victoria, Victoria, British Columbia, Canada. VII Congresso Iberoamericano de Informática Educativa 1356