¿Cuál es el estado actual de la orientación-a-objetos en la universidad española? Según mi experiencia, y pese a que algunos profesores están bien impregnados de la tecnología y unos pocos otros del buen hacer industrial, el estado es… ¡de sitio! O sea, pequeños corpúsculos tecnológicos (a los objetos me refiero) se agolpan en los escasos resquicios que la burocracia, la desgana y la estulticia procuran. Resultan así de aquí, por lo usual, informáticos con supuesta formación superior e información claramente inferior. Pero, ¿y la industria? ¿Las previsibles necesidades tecnológicas de las aplicaciones software actuales están forzando a las empresas a adoptar esquemas de formación, uso y mantenimiento de esquemas orientados-a-objetos? La respuesta, de nuevo, es decepcionante: hay un tanto de interés, pero escasa volición, sesgada disposición y, en general, nulo presupuesto. ¿Cómo, entonces, se aplican las técnicas de orientación-a-objetos en los aplicativos y proyectos actuales? Con dolor, intuición, miedo, prevención y atrevida ignorancia. Claro que, si ni la universidad -con sus proyectos curriculares levitantes- ni la industria -con su proyección dineraria asfixiante- aportan la formación necesaria para abordar con perspectivas de éxito proyectos de software distribuido orientado-a-objetos, entonces ¿quién lo hará? ¿Los cursos de James Bart-in? ¿Un rosario de seminarios avanzados? ¿Unas charlas on-site? ¿Un ungüento fabricado con caspa de programadores Java? Oh, yo diría que tan sólo hace falta un esquema de formación que contemple: calidad, tiempo y practicidad. Y, claro, esto suena a... ¡no, no, lector: olvide el sexo ahora! Decía que esto suena a... ¡Master!

OBJETIVOS DE UN MASTER DE SOFTWARE PRUDENTE

Un tal "Master" habría de ser eminentemente práctico, pues se supone que en él se enfatiza la adopción de técnicas de aplicación práctica del bagaje teórico asimilado a lo largo de la carrera, constituyéndose, contemplando toda la casuística, en una forma de asentar conocimientos y establecer vínculos entre la industria y la academia; pero también, precisamente por lo anterior, habría de resultar innegablemente comprometido con la tecnología informática de uso actual y futuro, de forma que no puede formar a los asistentes en base al entorno sectorial que, como su profesión, definen las empresas locales, sino que tiene que formarles para que, pudiendo asumir los trabajos de uso en tales empresas, sean capaces, también, de catapultar a éstas a otros niveles técnicos y de gestión. Se trataría, en definitiva, de formar ingenieros de software en su concepción más sólida, sin perder de vista la característica multi-paradigma que desde siempre ha caracterizado a los implicados en el software. Con un programa como el que aquí se entrevé se conseguirían tres objetivos claros:

1. Atraer a "ingenieros de empresa" con experiencia real en proyectos, a fin de obtener una suerte de "esquema de migración" a las nuevas tecnologías basado en un proyecto "real";
2. Atraer a los "ingenieros postulantes", mayormente con poca o ninguna experiencia, con el reclamo de "conocimiento y uso" de tecnologías avanzadas, de Java, y de su integración con sistemas "heredados", lo que aumentaría notablemente sus posibilidades laborales; y
3. Prestigiar, en el ámbito nacional -e incluso internacional-, un "Master" que se trocaría, a la vez, en "tecnológicamente avanzado", en "alejado de nebulosas teóricas" (dado su resultado, de practicidad irrebatible) y en núcleo de posteriores trabajos, tanto en la academia como en la industria.

MASTER EN INGENIERÍA DEL SOFTWARE (MIS)

La Facultad de Informática (ESIDE) de la Universidad de Deusto comenzó en el curso 1997-98 un ambicioso proyecto de enseñanza especializada de la Tecnología de Objetos para licenciados, inserto en su Master en Ingeniería de Software (MIS), que ha tratado de recoger los criterios y objetivos anteriormente expuestos, a la vez que rellenar un hueco tecnológico desafortunadamente vacío, como conjunto, hasta la fecha. Evidentemente el contenido resulta fundamental aquí, así que, a fin de preparar un programa adecuado, y tras examinar parecidos esquemas de enseñanza en universidades extranjeras, se asumieron ciertas premisas y se adoptaron otras tantas resoluciones:

• La Tecnología de Objetos ha impregnado, a veces suave y otras fuertemente, casi todas las áreas y recovecos del sentir informático, de forma que no resulta práctico ni provechoso centrarse en uno o más segmentos restringidos de la tecnología (como Internet/Intranet, Interfaces o Gestión de Proyectos OO), que para los alumnos no habrían de observar nexo común evidente. Se trataría, pues, de impartir un curso en el que se dieran cita buena parte de los aspectos actuales de la Tecnología de Objetos y en el que, a la vez, se proporcionara a los asistentes una guía de desarrollo secuencial, gradual y medida. A tal fin, y siguiendo el ejemplo de textos como "Client/Server Programming with Java and CORBA", se adoptó un proyecto genérico como esqueleto del "Master" entero. De esta manera a cada módulo o grupo de módulos teóricos habría de seguir al menos otro con la aplicación práctica de lo allí aprendido respecto del proyecto común.
  
• El Lenguaje de Programación a escoger (pues los aspectos de implementación se consideraron de extrema importancia) debía reunir ciertas condiciones que abundaran en resaltar los otros aspectos de la tecnología no directamente relacionados con la codificación, así que su sintaxis debería ser suficientemente sencilla e inambigua, a fin de permitir el rápido aprendizaje de su núcleo y poner en práctica lo antes posible lo aprendido en otros módulos.
  
• Los módulos pedagógicos, pese a participar de un proyecto práctico de base común, deberían ser suficientemente independientes como para permitir desviaciones y variaciones, pero también deliberadamente cohesivos para así arrojar una visión coherente de la tecnología. Esto supone que el proyecto de fondo debería ser más bien un núcleo de aplicativos, a la vez que tendría que enfatizar la aplicación de modularidad software inteligente, en el sentido dado por Bertrand Meyer. Y es que, ¿Por qué no aplicar a los esquemas organizativos las mismas técnicas que se suponen irrebatibles para la construcción de sistemas software? Precondiciones y postcondiciones son elementos indispensables para asegurar la robustez, eficacia y fiabilidad de un sistema software. ¿Por qué, pues, no han de serlo para asegurar la robustez, eficacia y fiabilidad de un sistema académico? En todo caso, la aplicación de estas técnicas en el campo académico generará más atención sobre lo que se supone un muy cuidado acercamiento de la realidad a los ingenieros de software que cursen el "Master".
  
• Los resultados del "Master", parciales o no, deberían poseer calidad industrial y "marketable conditions".

LENGUAJE DE PROGRAMACIÓN

Análisis y Diseño Orientados-a-Objetos han de finalizar, forzosamente, con la implementación y validación de la solución software. Además, la experiencia procurada por muchos años de enseñanza de la Tecnología de Objetos muestra que los alumnos necesitan establecer de forma expresa la correspondencia entre modelos y codificación. Por fin, resulta pedagógicamente adecuada la comparación entre el resultado de OOA/OOD y las posibilidades reales del lenguaje elegido. Pero, ¿cuál es éste? O mejor: ¿cuáles han de ser los criterios para su elección? Veámoslos:

• Sintaxis simple: interesa un período corto de aprendizaje y, sobre todo, evitar las prolijas situaciones adscritas a lenguajes como C++.
• Bibliotecas estándar incluidas: interfaces gráficos de usuario, estructuras de datos y algoritmos, tratamiento multimedia, etc.
• Plataforma tecnológica asociada: modelo de eventos, sistema de comunicaciones, etc.
• Transportabilidad multi-plataforma: de forma que no hubiera que lidiar con APIs propietarios, modelos de eventos cautivos o patrones de codificación e identificadores.
• Acceso simple a bases de datos: a ser posible opcionalmente separado de las herramientas de gestión del lenguaje.

Hasta aquí algunos lenguajes, como Smalltalk y Python, cumplirían los requisitos propuestos, pero falta una última condición que los mismos estudiantes impondrían:

• Amplia aceptación comercial e industrial: de manera que las expectativas de trabajo futuro acompañen la aplicación práctico de lo en el curso aprendido.

Y, claro, Java aparece como la solución evidente: independencia de la plataforma a través de su máquina virtual, especificación breve, sólido entorno tecnológico, bibliotecas de clases y, ante todo, impresionante pasmo comercial y mercadotécnico.

PROYECTO TRONCAL

 ¿Qué tipo de proyecto puede resultar, a la vez, eminentemente práctico, de valor comercial, y, a la vez, suficientemente jugoso como para generar un cúmulo de proyectos de valor académico? ¡Una Contabilidad Distribuida en Java (CDJ en adelante)! Y es que los actuales programas y paquetes contables reúnen, en su conjunto, el cúmulo total de despropósitos aplicables a la construcción software dirigida, de forma que, además de ser usados para "la ejemplificación del mal", pueden instar a la reconsideración de esquemas trasnochados o, simplemente, desfasados. CDJ se basa, pues, en esquemas de servidores de interfaces asociados a logins de usuarios, en la distribución de la lógica entre servidores, en la comunicación segura entre thin-clients y servidores, en prácticas de zero-administration, etc. La ventaja, con todo, de CDJ es que permite la asunción en su seno de subproyectos de interés general, sin tener que ser generalizado al típico proyecto CRUD. Así, por ejemplo, la gestión de un simple plan contable implicaría, entre otros, la generación de:

• Modelados de objetos de negocio.
• Interfaces contexto-sensitivos, usualmente basados en disposiciones arbóreas de la capa de negocios, lo que permitiría el uso de diálogos específicos para grupos/nodos de cuentas.
• Enlaces con las bases de datos de sujetos sitas en repositorios comunes.
• Sistema de ubicación genérico, asociado a la normalización europea.

De esta forma distintos subproyectos podrían ir gradualmente acoplándose para formar la contabilidad final. A la vez, y dado el amplio campo de posibilidades (respecto de componentes, que no en la vida real) de una contabilidad (apuntes, asientos, listados, universos de usuarios, enlaces, etc.), se refuerzan los aspectos de independencia de los módulos, permitiendo a distintos equipos asumir subproyectos de acuerdo con su formación y, sobre todo, con sus carencias.

EL PROGRAMA

En lo que sigue se detalla, aun sin estratificación temporal, el currículo secuencial constitutivo del MIS Deusto. A cada módulo sigue un texto explicativo de su intención y objetivos. Los módulos señalados en azul (y en los que aparecen las siglas CDJ: Contabilidad Distribuida en Java) representan la aplicación práctica, inserta en el esquema troncal de un proyecto software real, de lo aprendido en el módulo o módulos anteriores, manteniendo, con todo, un caudal de ejemplos que, si no resultan directamente aplicables al proyecto, al menos generarían la suficiente capacitación práctica para abordar la parte correspondiente del CDJ. Los módulos CDJ son complementarios de los módulos inmediatamente anteriores y se pueden asumir en el mismo contexto que estos: bien secuencialmente bien insertos como la explicación práctica simultánea del esquema teórico en cada caso expuesto. El detalle no quiere ser exhaustivo, sino tan sólo explicativo.

1.Introducción y explicación del esquema del Master

Aquí se trazarán las motivaciones, objetivos y líneas de trabajo del MIS completo, a más de la secuenciación teórico-práctica, el uso de la cadena de valor en la aplicación de resultados y la aplicación del proceso involutivo de creación del software embebido tanto en el MIS como en el proyecto software que lo sustenta.

2. Introducción a la Tecnología de Objetos

En este módulo se impartirán las bases teórico-prácticas que animan la Tecnología de Objetos, haciendo especial hincapié en la "modularidad" como concepto básico, de forma que la sección dé soporte más adelante al "ComponentWare" y a los esquemas de distribución de software. Es muy importante que todos los conceptos y ejemplos se sitúen en un entorno distribuido, aunque no haga falta que se defina por completo tal entorno todavía: se trata de conceptualizar la distribución y el transporte de software por una red.

3.Revisión exploratoria de las especificaciones de CDJ

Este es el momento en que se introducen las especificaciones del problema a modelar, de forma que los asistentes puedan empezar a manejar los conceptos y problemas que se diluirán por todo el MIS. El enfoque es eminentemente exploratorio y de "walkthroughs", pretendiendo únicamente ser un punto de entrada al problema.

4.Introducción intuitiva al OOD: El enfoque Wirf‑Brocks

En este módulo se pretende dotar a los asistentes con heurísticos exploratorios que les permitan abordar el análisis de especificaciones de requerimientos con ánimo modular (orientado-a-objetos). A lo largo de la exposición servirán de ejemplos el diseño de "Una herramienta de Dibujo" y de "Un Cajero Automático", a la vez que se introducirán aspectos de la CDJ que favorezcan el abordaje de la siguiente sección práctica.

5.Análisis O-O de las especificaciones de CDJ

Tras operar con el método anterior, los asistentes se encontrarán en disposición de abordar la extracción de clases a partir de las especificaciones textuales del problema CDJ. El análisis se realizará de forma interactiva con la participación del curso completo, pero tras el primer borrador se asignaran grupos de clases o subsistemas a equipos, para su defensa y mantenimiento a largo de esta sección. Con todo, las asignaciones serán rotatorias, permitiendo que los asistentes asuman el trabajo de otros.

6.Gestión de Proyectos Orientados-a-Objetos (OOPM)

La gestión de proyectos es una de las áreas que menos literatura y más interés despierta. OOPM, por su parte, absorbe los problemas del tradicional ciclo de vida en cascada y añade los que se generan a partir de un enfoque involutivo derivado de la espiral de Boehm. Cabe aquí también el estudio del "proceso de desarrollo de software", por su densidad, importancia y sobria independencia de métodos estructurados, orientados-a-objetos o de cualquier otro tipo. Los trabajos de Humphrey, del Software Engineering Institute (SEI), son fundamentales y situarían a los asistentes en posición de asimilar los modelos de madurez del software y las estrategias de aseguramiento de la calidad.

7.La Plataforma Tecnológica Java

Antes de abordar el lenguaje Java en sí, es conveniente revisar qué puede ofrecer Java como plataforma tecnológica. Esto es, hay que imbuir a los asistentes que Java es más que un lenguaje, que el hecho de abordar CDJ con Java es más que una elección de preferencias sintácticas, y que, como tal plataforma, han de tener cuidado en recabar a cada elemento de programación la cooperación inter-plataforma que requiera. La idea de "interacciones desconocidas" J -o sea, las que se suponen en otros segmentos de la plataforma- debe hacer mella en los asistentes, acostumbrados hasta ahora a la "programación libre" con un lenguaje dado.

8.Lenguajes de Programación Orientados-a-Objetos

Antes de mostrar a los asistentes la sintaxis y el uso de un lenguaje concreto (Java, en nuestro caso), es adecuado revisar algunos aspectos comunes a la mayoría de OOPLs. De hecho, ante unos asistentes posiblemente deformados, en distinta medida, por lenguajes "procedimentales" como Pascal ó C, resulta tremendamente interesante usar, con ínfulas pedagógicas, un lenguaje que, al estilo hernancortesiano "queme las naves" impidiendo el uso de lo hasta entonces aprendido y forzando la aplicación del nuevo paradigma de programación. Smalltalk se presenta aquí como un lenguaje de impresionante sencillez y tremenda utilidad práctica: es idóneo para el desarrollo de aplicaciones de gestión. La idea de este módulo es procurar a los asistentes la idea de que "ya" (por "hace mucho tiempo que") existen excelentes lenguajes y entornos de desarrollo basados en una nueva metáfora: objetos y mensajes.

9.El Lenguaje de Programación Java: Paquetes Básicos

Aquí se desarrollará del núcleo del lenguaje Java, sustanciado en los paquetes básicos que lo conforman (lang, util e io), en la sintaxis misma del lenguaje y, sobre todo, en el uso que de las características del lenguaje habría que hacer atendiendo a los objetivos de diseño del mismo. El objetivo de este módulo es dotar a los asistentes del soporte sintáctico mínimo para proceder a la codificación de un "toy-example" de reafirmación de lo aprendido.

10.Codificación en Java del Modelo Básico de clases de CDJ

Se usará aquí el entorno de desarrollo elegido únicamente en su parte "textual", a fin de que opere como soporte para la codificación y ejecución de clases Java. A la vez, los asistentes empezarán a enfrentarse a las peculiaridades de un entorno de programación orientado-a-objetos y a las propias del lenguaje Java. El uso de browsers es importante en este módulo, pero también la asunción del bagaje teórico supuestamente aprendido en el módulo anterior.

11.Arquitectura de Entornos Gráficos

Este módulo servirá para que los asistentes asimilen la evolución y estado actual de los interfaces gráficos (rectangulares J ) que pueblan nuestras máquinas. Pero más allá de la simple descripción histórica, los asistentes han de comprender el funcionamiento básico de la programación orientada-a-eventos y su solapamiento por los mensajes propios de la programación orientada-a-objetos. El sistema WIMP no es específico de MS Windows, pero la extensión comercial de esta plataforma hace aconsejable un estudio, aun somero, de su arquitectura, para seguidamente aportar las bases de la programación multiplataforma en entornos gráficos y mostrar algunas de las implementaciones más extendidas.

12.El Lenguaje de Programación Java: Programación Gráfica

Aquí se detallará el núcleo gráfico del lenguaje, incluyendo applets, la biblioteca AWT, gráficos, animación, hebras, un vistazo a la JFC y a las perspectivas de futuro. El objetivo de este módulo es que los asistentes sean capaces de diseñar y codificar applets y aplicaciones usando marcos, diálogos, botones, menúes y gráficos simples; manipular y presentar imágenes, crear applets y aplicaciones que usen hebras Java para presentar animaciones y cargar y ejecutar audio-clips en applets.

13.Modelos de Componentes

El objeto de este módulo es imbuir a los asistentes en la necesidad del uso de componentes en el software actual, enfatizada por la evidencia de la exigencia de la transportabilidad inter-plataforma. Naturalmente, tras un breve repaso de la situación actual, comercialmente dominada por Microsoft (COM/DCOM), se impone la explicación del modelo de componentes de Java (JavaBeans) para, al final, explicar las conexiones con los otros modelos y, en particular, con el de Microsoft. El núcleo de CDJ se basa en JavaBeans, por lo que este módulo es crucial y presupone la aprehensión sólida de los anteriores.

14.Creación de un prototipo "exploratorio" de CDJ

Creación de un primer prototipo del aplicativo, en el que se pondrá a prueba lo aprendido respecto del entorno de desarrollo (VAJE), del lenguaje de programación (Java) y del Modelo de Componentes (JavaBeans). No se aplicarán reglas estrictas respecto de la codificación del GUI (que se verán en los módulos siguientes), sino que más bien en esta fase se generará el tipo de conocimiento práctico que permitirá más adelante la codificación con "calidad" de los interfaces reales.

15.Diseño de Interfaces Gráficos de Usuario

Tras enfrentarse a los problemas de un prototipo exploratorio, los asistentes estarán en disposición de mejor comprender la importancia de los esquemas de interacción hombre-máquina, de manera que en este módulo podrán aprender los patrones básicos de diseño de GUIs.

16. Creación de un "Libro de Estilo de IGU" para CDJ

Se trata aquí de aplicar las normas genéricas aprendidas en el módulo anterior, de forma que, a la vez que se discuten alternativas y se adoptan criterios en relación a un aplicativo concreto (CDJ), los asistentes asimilarán el esquema constructor de un libro de estilo corporativo para programación bajo entornos gráficos. El fin principal de este módulo es el de establecer criterios de selección entre los diferentes esquemas, paradigmas, metáforas y arquitecturas visitadas anteriormente.

17. Patrones de Diseño Software (DPs)

Los patrones de diseño, desde la aparición del GOF book (Gamma et al.), han supuesto una revolución en los procedimientos de transmisión de la experiencia en análisis y diseños software, normalizando (usualmente mediante "pattern mining") la exposición de problemas bien conocidos, de forma que su discusión y posibles soluciones puedan ser expuestas para su aplicación matizada por ingenieros de software noveles. La revisión teórica de ciertos problemas "patronizados" permitirá su tratamiento práctico en la aplicación CDJ en el siguiente módulo.

18.Implementación de Patrones en CDJ

Aplicando lo asimilado en el módulo anterior, se solucionarán aquí distintos y bien conocidos problemas relacionados con la gestión de copias temporales en entornos gráficos, con la particularización de interfaces gráficos, con la cadena de comandos en acciones, etc. El objetivo de esta sección es insertar los resultados en la arquitectura del aplicativo.

19.Ingeniería Convergente

A la hora de enfrentarse al modelado software de una organización industrial, surgen problemas relacionados con el planteamiento genérico: ¿procesos de negocio? ¿esquemas organizativos estáticos? ¿sistemas de control, captación y consumo de recursos?. El Dr. David Taylor, primoroso consultor empresarial de éxito y uno de los apóstoles de la orientación-a-objetos en el entorno industrial, expone en su método que esquemas organizativos, recursos y procesos industriales han de converger hacia un enfoque industrial unificado que permita modelar efectivamente la empresa y los cambios que en ella pudieran acometerse.

20.Repositorios para los objetos CDJ

Tras operar con las capas del modelo y la vista, es necesario dotar de persistencia a ciertos objetos, así que en este módulo se determinarán los criterios de generación de estructuras persistentes (tablas relacionales u objetos en OODBMSs) y de objetos de inicialización y personalización. El hecho de situar este "mapping" en una etapa tardía del proceso de desarrollo del aplicativo habrá de forzar a los asistentes a pensar en modelar primero e implementar después, solucionando las cuitas de eficacia, efectividad e idoneidad en la fase de diseño de implementación.

21.Procesamiento Transaccional C/S

Tras estudiar repositorios de datos y niveles básicos de acceso y gestión, se impone el estudio de las categorías de aplicaciones cliente/servidor orientadas a bases de datos, de forma que se vería primero la posibilidad de inserción de tales repositorios en esquemas de procesamiento para ayuda en la toma de decisiones negociales (data warehousing), para después estudiar sistemas OLTP, comparar ambos y avanzar, así, los conceptos del módulo siguiente. Este módulo quiere insuflar, en resumen, a los estudiantes de los aspectos prácticos del procesamiento transaccional en aplicaciones de negocios, pues como consecuencia de la necesidad de conversión de la actual infraestructura de aplicaciones estáticas en arquitecturas escalables de procesamiento transaccional, se impone la traslación de OLTP a la computación heterogénea en red.

22.Java Networking

Todos los conceptos modulares aplicados en los módulos anteriores encontrarán aquí arquitecturas, esquemas de transporte, estrategias de comunicación y procedimientos de interconexión. No se pretende, con todo, ilustrar teóricamente en profundidad cada uno de los apartados previstos, sino más bien explicitar su núcleo teórico para inmediatamente revestirlo de la plataforma Java para que se adecue a los fines del MIS. El objetivo del módulo es dotar a los asistentes de criterios para discernir entre las distintas estrategias planteadas.

23.Codificación de CDJ con distribución centralizada

Los esquemas revisados en el módulo dedicado a Procesamiento Transaccional se aplicarán ahora para procurar comunicación entre porciones software ejecutándose en máquinas virtuales Java distintas. La elección de método de comunicación dependerán, en gran medida, de la funcionalidad requerida y de la capacitación de los asistentes al Master.

24.CORBA

Es imposible obviar lo que CORBA supone en el software actual, tanto por su presencia real como por su repercusión futura. Parece francamente difícil que una única plataforma (lisez MS Windows o Sun's Java) domine la totalidad del mercado, de forma que surge evidente la necesidad de interoperar con objetos codificados en distintos lenguajes y albergados en plataformas heterogéneas.

25.Uso de un ORB en CDJ

En este módulo se revisarán las implementaciones Java de ORB comercialmente más extendidas, tras lo cual se procederá a la implantación de una colaboración cliente/servidor. A la vez se abordará la creación de un servidor de interfaces para la parte cliente que accedan a métodos de objetos de negocio en la parte servidora. En fin: un ejemplo muy completo para probar la eficacia logística y de mantenimiento de una solución distribuida.

26.Tecnología Internet

Este módulo puede servir de soporte para situar claramente "el estado actual del arte" en lo relativo a la aplicación de Internet a sistemas de información. En este apartado se puede desarrollar explícitamente la problemática del software distribuído, la evolución de la arquitectura cliente/servidor, el Object Web, arquitecturas n-tier, etc.

27. Principios de Desarrollo de Software

Este módulo, inspirado directamente en el texto del Dr. Alan M. Davis y con el ánimo de conferencia magistral, trataría de inculcar en los asistentes la idea de que el desarrollo de software está regido por principios generales y mayormente inamovibles. Al mismo tiempo procuraría esa suerte de mezcla de recetario y manual tan apreciado por los estudiantes, de forma que serviría de perfecto colofón al Master .

CONCLUSIONES

Un programa de la densidad del expuesto -y con una duración de un curso académico- requiere un particular esfuerzo por parte de los asistentes, una cuidada selección bibliográfica y un excepcional plantel de profesores. La Universidad de Deusto (ESIDE) ha procurado todo esto, así que habrá que esperar a su conclusión para notar apreciaciones, consejos o críticas.

[1] Los cursos extremadamente apocopados de gurus constituyen la exégesis de lo que yo denomino "aprendizaje tecnológico por ósmosis": es decir, se intenta tocar al maestro, y en el flujo de satisfacción que esto genera se incluyen emociones, olores, fluidos corporales y algunas pequeñas piezas de seguridad tecnológica. No se sabe más, pero uno adquiere más confianza y seguridad a partir de este insignificante hecho.