¿Qué es lo que, por encima de otras características, identifica a todos los lenguajes de programación orientados-a-objetos? ¡Los objetos, naturalmente!, como quiera que en cada caso puedan llamarse. Pero tras éstos sigue una legión de lenguajes que incorporan lo que se denominan “clases”, sean éstas propiamente objetos o no, intentando proporcionar estructuras que encapsulen las comunalidades de conjuntos de objetos. Teniendo en cuenta, por otro lado, que los esquemas de diseño, y más tarde de análisis de sistemas, debieran provenir del estudio de las estructuras linguísticas aplicadas en la implementación real de soluciones software, resultará evidente al lector por qué la mayoría de los métodos de OOA/OOD se basan en el pre-establecimiento de una dicotomía inamovible: clases y objetos. Pero, atención, si se examina brevemente esta aseveración parece que algo falla: ¿todos los sistemas reales se modelarán sólo en base a clases y objetos? ¿Es ésta la solución definitiva? Humm, atendamos a una pequeña disgresión: como el lector sabe, los distintos métodos, técnicas, trucos y conjuros que conforman el grueso de lo que pomposamente se ha dado en llamar Análisis y Diseño en Ingeniería de Software no son sino resoluciones más o menos afortunadas del problema genérico de la traslación de la realidad al dominio software. Tradicionalmente tal correspondencia se ha basado, como antes se expuso, en una inferencia posibilista basada en modelos prácticos de funcionamiento efectivo: esto es, primero se han modelado, más o menos desconexamente, multitud de sistemas, para más tarde extraer de éstos conclusiones genéricas teóricamente aplicables a problemas similares a los modelados. Actualmente, sin embargo, la creciente explosión informativa ha dado en generar un fenómeno harto curioso que yo denominaría “recursión desplazada”. Tomemos, por ejemplo, el “Análisis y Diseño Orientado-a-Objetos”: originariamente bienintencionado y basado en simulaciones reales (lisez aquéllas basadas en Simula, Smalltalk-80, etc.), pronto desembocó en un precipicio involutivo con ribetes atractivamente comerciales (lisez Coad&Yourdon, Booch, etc.), mención aparte de las cualidades reales de cada método (bien escasas, con todo, en su relación con la gestión real de proyectos). Así, como cuando se llevaron conejos a Australia, éstas primeras incursiones se asentaron en un terreno sorprendentemente fértil, e, igual que ocurrió con aquéllos animales, la profusión de métodos devino alarmantemente rápida, ocasionando a la vez similares destrozos (y la mixomatosis no parece ser aquí, tampoco, buena solución). Si a todo esto añadimos la avidez informativa que caracteriza a estos últimos años obtendremos una situación en que las experiencias quedan aplastadas por las inferencias: esto es, cómo no se da tiempo a que se generen experiencias sólidas fiables para cada uno de los métodos publicados, de forma que sobre ellas pudiera basarse una revisión de los mismos, los nuevos métodos han de basarse, por fuerza, en las versiones más recientes de métodos anteriores: o sea, nos elevamos tirándonos de las orejas. De esta manera, finalmente se convierte en incontestable esencialidad lo que fue contingencia primeramente: los nuevos métodos [1] orientados-a-objetos dan, así, por supuesto que la base de su estructura y notación son, a la vez, objetos y clases, usualmente aderezados después con sofisticadas, prolijas, tendenciosas o ridículas consideraciones contextuales y de establecimiento de capas comprehensivas (ya sabe el lector, esas que consiguen hacer mínimamente abordables composiciones de 3.000 clases, 15.000 conexiones, 20.000 flechas, etc.): aparecen, así, subsistemas, entornos de visibilidad, relaciones tipificadas, abstracciones de variación de estados ... y multitud de artefactos intelectuales que intentan suplir las carencias de una elección inicial cuando menos sesgada. Pues si sólo se dan inicialmente clases y objetos, como sólo se dieron Adán y Eva [2], forzosamente ha de construirse inicialmente un modelo estático de relaciones entre entidades (agrupemos la dualidad), para después estimar comportamientos, interacciones y reacciones dinámicas: todo un pastiche gastronómico que podría haberse evitado eligiendo mejor las viandas principales. “Y, claro, lo que faltan son los roles” -apuntará el impaciente lector. ¡Vaya, así es! Y es que he dado muchas pistas. “Pero esto es una afirmación tan gratuita como la que asegura la sola necesidad de clases-objetos” -seguirá el lector crítico- “¿Por qué ésta sí y aquéllos no?” Humm, obviando la importante cuestión que el enfoque de roles que aquí se expondrá incluye al de clases-objetos, y aplazando temporalmente la inmersión en definiciones y procedimientos, intentaré dar satisfacción al lector atacando, antes de entrar en el modelado genérico de roles, distintos aspectos esenciales a la construcción de sistemas software, singularmente basados en la interpretación de la realidad y extraídos, en buena parte, de mi experiencia personal.

ESCENARIOS Y APREHENSIONES

Imaginen a una gran empresa rediseñando su sistema de facturación y gestión comercial: como se trata de un proyecto crítico para la compañía, no basta un simple redibujado de lo hasta entonces utilizado: hay que replantearse los supuestos básicos en que se apoya el sistema; de hecho hay que volver a “analizar” el problema. Pero ... ¡se trata de un sistema complejo, con demasiadas interacciones para ser asimilado conceptualmente en una sola vista! ¿Solución? “Oh, usemos una herramienta CASE -podría exclamar el impaciente lector”. “Mejor si es OOCASE” -asumirá aquel otro lector, quizás un tanto receloso. “Alegradme el día” -podría anunciar entonces yo, empuñando con soltura una Magnum. Porque, ¿para qué demonios quiero yo traspasar la complejidad del mundo real al plano de los dibujitos inanimados [3]? Lo que aquí hace falta es algún enfoque comprehensiblemente simple que permita reducir la complejidad en el ataque para domar el problema. Naturalmente no nos sirven, y más bien nos perjudican, las composiciones de “tablas”: incontables entidades, con atributos de todos los tipos y colores, que se relacionan mediante una inaprensible maraña de líneas con cardinalidades explícitas (0,n) por doquier, usualmente construidas mediante una herramienta visual que genera los scripts de creación de tablas relacionales para una amplia gama de gestores. Y es que en estos esquemas una entidad (por ejemplo, una Persona) tiene los mismos atributos (columnas) respecto de muchísimas otras entidades, lo cual parece razonable en el contexto del diseño de tablas, pero resulta descorazonador cuando respecto de una entidad concreta, como por ejemplo un Asistente Técnico, únicamente necesita de su dirección. ¿Por qué repetir, pues, todos los atributos en todas las situaciones? Pues porque, simplemente, no se consideran las situaciones en sí, sino sólo las relaciones estáticas entre entes. Oh, las relaciones dinámicas también se estiman en los posteriores diagramas de transición de estados (y técnicas adláteres), pero sólo de manera que se rellenan y cambian algunos atributos del total que reúne la entidad: esto es, cada situación dinámica mantiene un conjunto invariante de atributos, que únicamente se deduce por su omisión del modelo dinámico, de forma que los defectos del presupuesto inicial de diseño de tablas contaminan el proceso entero de análisis/diseño. Además este planteamiento supone una visión conciliadora que pasa por muchas consideraciones, decisiones de diseño y soluciones sesgadas que en absoluto quedan documentadas con el mero diseño de las tablas. Me explico: yo puedo decidir, por ejemplo, que el “Cliente” de este escenario es el mismo “Abonado” de aquel otro, y que ambos son, en el fondo, instancias, quizás con diferentes estados internos, de la entidad/clase “Persona Física”, que fácilmente es una clase derivada de “Persona”, con la que operaré más genéricamente (también las “Personas Jurídicas” son “Clientes” y “Abonados”). Todo esto está muy bien, pero son decisiones que, a lo sumo, se documentarán de forma externa al diseño de marras, pues en éste lo que finalmente aparecerá será una clase/entidad con demasiados atributos/columnas y alguna breve calificación textual. Y es que no podemos abordarlo todo a la vez: según G.I. Miller, la memoria a corto plazo sólo puede asimilar simultáneamente tres bloques conceptuales con un máximo de tres elementos cada uno (una variación de la regla, también suya, del 7 más/menos 2), así que para comprender hay que segmentar: Divide et Impera. Pero, ¿cómo encontrar los subsistemas, escenarios o porciones autónomas sobre las que aplicar nuestra cuestionable inteligencia analítica? Examinemos algunas posibilidades:

• Use Cases (Casos de Uso): Fiamos la delimitación del escenario a nuestra intuición en la adecuada apreciación de los procesos esenciales al sistema a modelar, concretados en razón de los estímulos externos que los generan. Se trata, en breve, de reflejar el flujo secuencial temporal de mensajes/respuestas entre clases/entidades
• Responsibility-Driven Design Walkthroughs (Revisión de Escenarios en Diseño Orientado-a-Responsabilidades): Tras identificar las clases del sistema y las responsabilidades que asumen, basadas en la política contractual de colaboraciones cliente-servidor, el analista se plantea escenarios posibilistas e intenta adaptar, refinar o inferir nuevas interacciones entre entidades.
• Escenarios : Un atractivo término resonante (buzzword) que encierra, como el infierno de don Ramón, más intenciones que realidades. Los escenarios son ubicuos, como se quisiera que fuese dios, pero igualmente difíciles de encontrar e identificar.

Oh, estas opciones suenan distintas pero adolecen de la misma indeterminación primera: ¿Cómo establecer los escenarios de un sistema a modelar sin usar heurísticos cosmogónicos o técnicas dolosamente arbitrarias? Esto es, ¿cómo identificar escenarios que no resulten tan volátiles como para que su cambio no afecte a la arquitectura del sistema? Bueno, la experiencia sirve, sin duda, pero sólo a los expertos [4]. Necesitamos algo más: una suerte de tabula rasa en la que basar nuestra segmentación de la realidad.

TRAS DIVIDIR HAY QUE MULTIPLICAR

Volvamos a nuestro sistema de gestión comercial: ¿no hay ninguna forma de establecer módulos de trabajo a modo de componentes con los que construir, mediante su integración, el sistema final? ¡Naturalmente que sí! Un primer acercamiento incruento (al menos respecto del Jefe de Departamento, usualmente bien pertrechado de arrojadizos laborales) sería intentar modelar procesos (o mejor actividades) a la manera de los casos de uso, controlando los estímulos externos que afecten a la identidad del sistema (no las colaboraciones ni las cadenas de mensaje), también como las repercusiones externas, pero recabando que los roles a que se pueden adscribir las entidades del mismo conforman un modelo conceptual claro y presumiblemente inamovible en ese contexto. O sea, en la práctica se trataría de modelar por separado situaciones en las que en primer lugar no se dé variación del rol asumido por cada entidad, pudiendo integrar después los intercambios de roles en el mismo modelo. Así una bienintencionada primera fase práctica pudiera ser la de reconocimiento de los roles que se juegan en razón de los procesos actuales que se dan en el dominio del problema: existe, por ejemplo, un proceso de “Servicio de Reparación de Averías” en el que se dan los roles de “Abonado con Problemas”, “Mecánico”, “Punto de Servicio”, “Servicio Afectado” y “Material Estropeado”, entre otros. Nuestros punto de control respecto de los límites de esta porción serían los de transición en una entidad de un rol a otro. Así, por ejemplo, si como consecuencia de una avería irreparable el “Abonado” decide rescindir el servicio, o contratar más garantías para el mismo, el rol que juegue habrá dejado de ser el de “Afectado”, pasando a desempeñar el de activo “Contratante”, pero tales nuevas actividades deberían permanecer fuera de nuestro modelo de Servicio Asistencial. Hay que recabar, también, que en esta etapa en absoluto se prejuzga qué tipo de entidad o clase es la que “implementará” (y este calificativo es importante) cada uno de los roles encontrados: de esta manera en cada escenario (o mejor, modelo de roles) se detallan únicamente los atributos que interesan al modelo en estudio. Naturalmente en algún momento habrá que integrar o sintetizar tales atributos para componer la entidad de implementación (“clase” o usualmente “tabla”): para conseguir tal habrá que considerar, más o menos informalmente, cómo la unión de modelos de roles afecta al modelo de roles resultante (pues eso es lo que obtenemos, en buena lógica). Lo que así estamos consiguiendo es estratificar con límites semánticos bien definidos cada una de las porciones de que se compondrá nuestro sistema, y la verdad es que las perspectivas son halagüeñas: si el enfoque funcional se está abandonando en favor del de objetos/entidades, para evitar la volatilidad de los sistemas, ¿por qué no ir un paso más allá y afianzar el diseño en modelos fácilmente comprensibles, reutilizables y componibles en distintos contextos? Ah, estos son los modelos de roles. Pero ¿no suena todo lo expresado un tanto etéreo, como muy dejado a la imaginación del analista? Bien, quizás suene así, como puede sonar a tarareo una ópera de Verdi desde muy lejos, así que habrá que acercarse un tanto: en lo que sigue examinaremos muy muy brevemente los aspectos más importantes de un método, Ooram, analíticamente completo, intelectualmente satisfactorio y con muchos años de experiencia a sus espaldas. Así que lo propio será recaer en el libro en que se explicitan, mejor que aquí, tales ideas.

EL LIBRO

Working with Objects: The OOram Software Engineering Method , por Trygve Reenskaug, Per Wold y Odd Arild Lehne, 1996, Manning Publications, 1-884777-10-4 (Prentice Hall 0-13-452930-8).

Atención, lector: a mi entender este es uno de los textos más importantes publicados en los últimos años sobre construcción de sistemas software, de forma que arriesgarse a ignorarlo es comprometerse con la oscuridad. Sepa el lector, de cualquier forma, que no soy fanático: sólo vehemente. Esto es, en el texto se explicitan muchas ideas que a mí me parecen no sólo naturales y adecuadas, sino también inteligentes, efectivas y, finalmente, humanas. Es curioso que sean los trabajos europeos, y sobre todo los del norte, los que enfaticen la primordial importancia del factor humano en la construcción de sistemas software. El libro contiene, además, un importante componente pedagógico, pues evidencia los importantes logros conseguidos mediante el uso prudente de Smalltalk y de la más general Tecnología de Objetos en una empresa (Taskon) a lo largo de más de 25 años. El autor principal, Trygve Reenskaug, es, además de un reputado experto en el campo de la Orientación-a-Objetos, el creador del concepto Modelo-Vista-Controlador (MVC) que seguro todos conocen. En fin, para abordar el contenido del libro intentaré resumir los capítulos más significativos.

IDEAS PRINCIPALES

El método OOram se define como “un marco de referencia para una familia de metodologías orientadas-a-objetos”, tras lo que se muestran las mejoras que el método introduce en las tres dimensiones típicas que componen el grueso de metodologías:

• Tecnología (conceptos, notación, técnicas y herramientas): donde se muestran el poderoso modelado de roles en análisis y su integración posterior -síntesis en Ooram-, junto con los conceptos básicos (roles, puertos -que anuncian la visibilidad de un rol respecto de otro-, etc.) y algunas herramientas. Es interesante resaltar la referencia de distintos conceptos a abstracciones: Objeto es “es”, como rol es “por qué”, mientras que tipo es “qué” y clase es “cómo”.
• Proceso con Entregables (la secuencia de pasos y la documentación que los acompaña): OOram distingue tres distintos procesos: creación del modelo, desarrollo del sistema y construcción de piezas reutilizables.
• Organización (las maneras en que la empresa acoge lo anterior): aquí se explicitan las dificultades de diseñar para reutilizar y las ventajas que supone el uso de cadenas de valor.

MODELADO DE ROLES

“El modelo de roles es una abstracción del modelo de objetos donde reconocemos un patrón de objetos y lo describimos como un corespondiente patrón de roles”. Y es que la clase se apoya en las capacidades (funcionalidad absoluta) de los objetos, mientras que el rol se apoya en la posición y responsabilidades de un objeto respecto de una estructura de otros tantos, que es precisamente lo que percibimos cuando examinamos un conjunto de entidades/objetos en colaboración. Pero el modelo de roles no representa la descripción de la estructura entera de objetos observada, sino más bien de porciones de la misma, segmentadas temporalmente, denominadas “áreas de interés” (areas of concern), y que muestran fenómenos colaborativos de interés. Resulta, así, que un modelo de roles es un modelo orientado-a-objetos de una estructura de objetos.

En OOram las técnicas de identificación de roles no resultan muy lejanas a aquéllas expuestas en el libro de Wirfs-Brock con la ayuda de fichas CRC, de forma que tras haber encontrado el modelo de interacción, mediante la separación en Áreas de Interés, para su visualización comprehensiva OOram plantea tres distintas perspectivas: contextual, externa e interna, y provee diferentes “vistas” aplicables según mejor convenga, siguiendo la acertada idea de que no hay que usar todos los recursos para describir un modelo, y que determinadas vistas, reunidas en un subconjunto concreto, tornan el modelo más comprensible que otras. Así OOram provee las siguientes vistas: Vista del Area de Interés, Vista del Estímulo-Respuesta, Vista de la Lista de Roles, Vista Semántica, Vista de Colaboraciones, Vista de Escenario, Vista de Interfaces, Vista de Procesos, Vista de Diagramas de Estado y Vista de Especificación de Métodos, cada una de ellas con su propia notación, enlazada empero respecto de un objetivo global de modelado.

SÍNTESIS DE MODELOS DE ROLES

Se trata aquí de integrar en un modelo más general (o modelo derivado de roles) los diferentes modelos de áreas de interés, de manera que un sistema se configura finalmente como síntesis, que no mera agregación las más de las veces, de las partes que lo componen. La síntesis puede darse, así, bien por superposición (los mensajes de estímulo en el modelo básico siguen siendo mensajes de estímulo en el modelo derivado), o por agregación (un modelo de base se integra como una caja negra o subrutina en el modelo derivado), que se califican de técnicas seguras de síntesis, bien por lo que se conoce como síntesis insegura, cuya aplicación necesita de una personal y cuidadosa atención.

En la síntesis de roles aparece nuevas vistas: Vista de Síntesis, Vista de Colaboración por Herencia, Tabla de Herencia y el Lenguaje OOram de Especificación de Herencia. Se muestran, a la vez, las perspectivas de aplicación del proceso de síntesis respecto de cada una de las vistas correspondientes al modelo de roles.

PUENTE A LA IMPLEMENTACIÓN

En esta sección aparecen las especificidades añadidas a las vistas de colaboración inter-roles en relación a los aspectos de implementación de los roles, además de hacer corresponder los conceptos en OOram con los equivalentes de implementación en C++ y Smalltalk, aplicables por tanto a otros lenguajes con facilidades de orientación-a-objetos. Hay que tener en cuenta que el entorno de trabajo desarrollado por Taskon se ha basado grandemente en Smalltalk, de forma que los aspectos de uso de herencia múltiple y mixins en C++ se tratan con alguna ligereza. Lo que aquí se abordan son los aspectos iterativos de desarrollo en el proceso de implementación y las cuitas de elección del lenguaje de programación

CREACIÓN DE COMPONENTES REUTILIZABLES

Aquí se muestra la idea básica de que para reutilizar es necesario utilizar antes, de manera que la llave del éxito es la comunicación efectiva entre el proveedor y los consumidores. OOram distingue entre reutilización por herencia (mediante patrones y frameworks) y reutilización por encapsulación.

El reúso por herencia se basa en patrones (que respecto de OOram son paquetes de formato fijo contenedores de un modelo de roles junto con documentación que describe cómo y cuándo debe éste ser usado) y en frameworks (entornos-marco), que representan un modelo de roles junto con un conjunto de clases base que definen direcciones y restricciones de extensibilidad.

El reúso por encapsulación se refiere en OOram a tres técnicas denominadas OOCS (Sistema de Composición de OOram), Configuración en Tiempo de Ejecución y Duplicación de la Estructura de Objetos. El Sistema de Coomposición OOCS se basa en que dado un objeto-semilla, el esquema OOCS especifica los tipos de objetos que pueden ser asimilados al mismo. El OOCS es, en esencia, una cadena de valor con cuatro capas: Usuario final, Creador del Esquema OOCS, Implementador de Tipo OOCS y Creador de Infraestructura.

LEA, LECTOR: LEA

Como el lector puede apreciar en base a lo hasta ahora expuesto, no se trata aquí de un simple método que postula elegantes y frecuentemente hueras descripciones étereas de sistemas, sino más bien un verdadero marco referencial muy denso en conceptos, notaciones y esquemas formales, pero donde el factor organizativo y humano juega un papel primordial. La extrema densidad de lo que en el texto se expone troca casi en imposible su sola enumeración comprehensiva aquí, así que emplazo de nuevo al lector a que lea.

OOram es, según sus creadores, un método adecuado de tratar con lo que se denomina programming-in-the-large. Pues bien, aparte de lo expuesto, en el mismo texto podrán encontrar cuatro casos bien desarrollados como ejemplos: el desarrollo de un sistema de información negocial, el análisis y diseño de un sistema de tiempo-real, la creación de un entorno-marco (framework) y los servicios inteligentes de red organizados como cadena de valor.

REFERENCIAS

Ciertamente no hay demasiado escrito, así que rompiendo mi propia norma de referenciar exclusivamente lo por mí leído, a continuación detallo las referencias que a este respecto me pasó Carl Petter Swensson, a la postre uno de los revisores del texto sobre Ooram, y que incluyen libros, artículos, tesis doctorales y escarceos con lenguajes de programación, conceptos e ideas similares en otros ámbitos:

• Ivar Jacobson, Object Oriented Software Engineering (Libro).
• Richardson and P. Schwarz, Aspects: Extending objects to support multiple, independent roles, Proceedings of the 1991 ACM SIGMOD International Conference on the Management of Data, pp. 298-307, 1991.
• P. Gilbert and L. Bic, An object-oriented data model for Semantic Relativism, ECOOP 1989.
• Lynn Andrea Stein and Stanley B. Zdonik, Clovers: the dynamic behavior of types ans instances, Brown University, Technical Report CS-89-42, noviembre, 1989.
• Trygve Reenskaug et al., OORASS: seamless support for the creation and maintenance of object oriented systems, Journal of Object-Oriented Programming, 5 (6), octubre, 1992, pp. 27-41.
• Los conceptos del protocolo de meta-objetos dentro de la comunidad LISP.
• Egil P. Anderson and Trygve Reenskaug, System Design by Composing Structures of Interacting Objects, Proc. of ECOOP 92, Springer-Verlag LNCS 615, junio/julio 1992, pp. 133-152.
• Barbara Pernici, Object with Roles, Proc. of the Conference on Office Information Systems (COIS), Cambridge, Massachusetts, 1990.
• Constantin Arapis, Specifying Object Lifecycles, D. Tsichritzis (ed.), Object Management, Universite de Geneve, 1990.
• Constantin Arapis, Specifying Object Interaction, D. Tsichritzis (ed.), Object Composition, Universite de Geneve, 1991.
• Constantin Arapis, Object Behaviour Composition, D. Tsichritzis (ed.), Object Frameworks, Universite de Geneve, 1992.
• P. Papazoglou, Roles: A Methodology for Representing MMultifaceted Objects, Proc. of Conf. Database and Expert Systems Applications - DEXA 91, 1991, pp. 7-12.
• Lynn Andrea Stein, Compound Type Expressions: Flexible Typing in Object Oriented Programming, Proc. of Conf. on Object-Oriented Systems, Languages and Applications (OOPSLA), 1988, pp. 360-361, Position Paper.
• Constantin Arapis, Type Conversion and Enhancement in Object-Oriented Systems, D. Tsichritzis (ed.), Object Oriented Development, Universite de Geneve, 1989, pp. 191-205.
• David McAllester and Ramin Zabih, Boolean Classes, Proc. of Conf. on Object-Oriented Systems, Languages and Applications (OOPSLA), 1986, pp. 417-423.
• Hendler, Enhancement for Multiple-Inheritance, SIGPLAN, V. 21, N. 10, October, 1986.
• Edward Sciore, Object Specialization, ACM Transaction on Information Systems, V. 7, N. 2, April, 103-122, 1989.
• Mohamed E. El-Sharkawi and Yahiko Kambayashi, Object Migration Mechanisms to Support Updates in Object Oriented Databases, N. Rishe, S. Navathe and D. Tal (eds.), Databases: Theory, Design and Application, A postconference proceedings based upon the proceedings of PARBASE-90 Florida March 6-9, 1990, IEEE Computer Society Press, 1991, pp. 73-109.
• Jianwen Su, Dynamic Constraints and Object Migration, Proceedings of the Sixteenth International Conference on Very Large Databases, Barcelona, Spain, VLDB 91, 1991, pp. 233-242.
• El lenguaje denominado LOOM, desarrollado en ISI, California. Para más información, contactar a David Brill (brill@isi.edu) o copiar el Manual de Usuario mediante ftp de isi.edu:/pub/loom.
• Craig Chambers, Predicate Classes, ECOOP 93 proceedings.
• Robert Strom et al., Hermes A Language for Distributed Processing, Prentice Hall, 1991.
• La característica CHANGE-CLASS del lenguaje CLOS, que permite convertir un objeto de una clase a otra.
• Papel sobre roles implementados en Smalltalk: roles.ps via ftp anónimo de 140.78.58.1
• La tesis doctoral sobre Redes Semánticas escrita por Nicholas Roussopoulos en 1977 en alguna universidad canadiense.
• El modelo de datos funcional permite que los tipos sean asociados dinámicamente con objetos surrogados, y esto significa que la identidad de un objeto permanece invariante durante sus transformaciones de tipo. IRIS ú OPEN-DB, de HP.
• Berard Software Enggineering, Inc., A Complete Object-Oriented Design Example.
• J. Wieringa, Algebraic Foundations for Dynamic Conceptual Models, Department of Mathematics, Vrije Universiteit, Amsterdam, May, 1990, Ph.D. Thesis.
• Wirfs-Brock, Johnson, Surveying Current Research in Object-Oriented Design, Communications of the ACM, 33 (9), September, 1990, pp. 113-116. Este artículo incluye una sección sobre modelado de roles.
• T. Hawryszkiewycz, Database Analysis and Design (Libro).

[1] Observe el lector que conscientemente evito el vocablo “metodología” en un vano propósito, sin duda, de resaltar con la repetición en la omisión cierta intención irónica, cuando no despectiva.

[2] Oh, Adán y Eva se dieron entre sí de manera que vocablos como “conocimiento” y “congreso” adquirieron su sentido exacto. Y es que seguro que a estas alturas el lector ya habrá asimilado la subrepticia comparación entre la dicotomía “clase-objeto” y el Concilio de Trento. Claro que, ¿se equiparará OOram al Concilio Vaticano II? ¡Demonios, espero que no!

[3] Las neurosis de Walt Disney, a pesar de la animación, construyeron una realidad comercial asexuada y muy cercana a los sueños infantiles del Estrangulador de Boston: muñecos que no hablan y que siempre enseñan ambas manos, y ... ¡Pero bueno! ¿Qué clase de bicho es Goofy? ¡El sueño de un psicólogo rogeriano!

[4] El lector deberá perdonarme el refrito de la infatigable verdad “El dinero llama al dinero”. Yo mismo habré también de perdonarme, pues ciertamente aborrezco la incontinente vulgaridad de la franqueza social de la que los refranes son odioso reflejo.