El método de modelado Shlaer/Mellor

Hablar de desarrollo de software es hablar en términos de aportes construidos sobre otros aportes. Los conceptos, elementos, formas de trabajar o de pensar que hoy damos por sentados fueron alguna vez ideas novedosas en mentes curiosas.

Hoy me gustaría hablar de un método de modelado que, aunque no alcanzó la popularidad de UML, sí contribuyó a la forma en que entendemos el desarrollo de sistemas: el método de Sally Shlaer y Stephen J. Mellor. Su historia no es solamente la de una notación o de unos diagramas, sino la de una pregunta que todavía conservamos: ¿y si un modelo pudiera ser tan preciso que pudiéramos ejecutarlo y traducirlo a software?

El origen del método de Shlaer/Mellor

Existe una fecha cómoda para comenzar esta historia: 1988. Ese año se publicó Object-Oriented Systems Analysis: Modeling the World in Data, el primer libro de Shlaer y Mellor sobre el tema. Sin embargo, conviene hacer una distinción: 1988 es el año de aquella publicación, no un instante mágico en el que el método apareció terminado. Sus ideas proceden de años de trabajo con sistemas de tiempo real y de la colaboración de sus autores en proyectos anteriores al libro.

Para entender la razón de su existencia hay que recordar el contexto en el que trabajaban. Durante las décadas de 1970 y 1980 muchos sistemas crecían en tamaño y complejidad más rápido que las prácticas empleadas para organizarlos. En proyectos de control y tiempo real era habitual trabajar cerca del hardware, con lenguajes como Fortran o ensamblador, y el código podía acumular decisiones de diseño mezcladas con detalles de implementación. El problema no era simplemente que faltaran buenos programadores: era que resultaba difícil razonar sobre aquellos sistemas, modificarlos y comprobar que seguían haciendo lo esperado.

El análisis estructurado ofrecía herramientas para descomponer problemas en funciones y flujos de datos. Shlaer y Mellor tomaron otra dirección: describir el dominio mediante entidades conceptuales, sus relaciones y su comportamiento. A esto añadieron algo que haría especial a su propuesta: los modelos no debían ser dibujos ambiguos destinados a quedar olvidados en una carpeta, sino especificaciones formales, integradas y suficientemente precisas para verificarlas mediante ejecución.

El proyecto BART

Una de las experiencias que antecedió al método fue el proyecto BART (Bay Area Rapid Transit), el sistema de transporte rápido del área de la bahía de San Francisco. Sally Shlaer se incorporó en 1979 al proyecto Integrated Control System en el Lawrence Berkeley Laboratory, donde trabajó junto a Stephen Mellor. El objetivo era investigar y sustituir software de control que se había vuelto difícil de mantener.

El obituario que Meilir Page-Jones dedicó a Shlaer recoge un ejemplo especialmente conocido de aquel trabajo: el subsistema Electrification, formado por unas 70 000 líneas de Fortran y ensamblador con numerosos problemas, fue reemplazado por aproximadamente 2 000 líneas de código limpio y funcional. Vale la pena precisar que el dato se refiere a ese subsistema, no a todo el software del metro, y que procede del relato retrospectivo de un compañero. No hace falta convertirlo en una leyenda de porcentajes para apreciar su importancia: el cambio fue consecuencia de replantear la estructura y las abstracciones del sistema, no de comprimir líneas mecánicamente.

En BART, Shlaer y Mellor también trabajaron en formas de gestionar proyectos y aplicar rigor al desarrollo de software de tiempo real. Aquella colaboración fue una semilla importante, pero todavía no era el método completo que después conoceríamos. En 1985 ambos fundaron Project Technology, donde continuaron desarrollando y formalizando sus técnicas mediante consultoría, cursos, libros y artículos. Al primer libro de 1988 le siguió Object Lifecycles: Modeling the World in States, dedicado al comportamiento de los objetos, mientras que el diseño recursivo y la traducción de modelos se desarrollaron como otra línea de trabajo durante aquellos años.

Qué era realmente el método

El nombre Shlaer/Mellor no designa únicamente una notación para hacer diagramas. Se trata de un enfoque disciplinado que cubre el análisis, el diseño y la implementación. Su documento descriptivo de 1996 lo organiza alrededor de dos grandes piezas:

La meta no era simplemente aplicar la orientación a objetos porque estuviera de moda, sino encontrar una representación del problema que se pudiera mantener independiente de la plataforma. El análisis debía responder qué hace el sistema, mientras que la arquitectura respondería cómo se materializa en una implementación concreta.

Dividir el sistema en dominios

El primer paso consiste en identificar los dominios, es decir, materias o asuntos diferentes que pueden analizarse por separado. Un dominio no es simplemente una carpeta de código ni una agrupación arbitraria de funciones: representa un área de conocimiento con sus propios conceptos y reglas.

El documento de 1996 distingue varios tipos para explicar el proceso. Está el dominio de aplicación, que contiene el problema que interesa al usuario; los dominios de servicio, como una interfaz de usuario o un mecanismo de persistencia; el dominio de arquitectura, que organiza los datos, el control y los algoritmos del sistema; y los dominios de implementación, como el sistema operativo o el lenguaje de programación.

Los dominios se conectan mediante relaciones cliente-servidor llamadas puentes. Un dominio cliente puede asumir que otro le proporcionará cierto servicio sin conocer sus detalles internos. Esas suposiciones se convierten, desde el otro lado, en requisitos para el dominio servidor.

Pensemos en un sistema ferroviario hipotético —solo como ejemplo didáctico, no como una descripción del modelo real de BART—. El control del recorrido de un tren, el accionamiento de las puertas y la interfaz mostrada a un operador son asuntos relacionados, pero no idénticos. Separarlos permite analizar cada uno con sus propias abstracciones y dejar explícito qué espera uno de los otros. Si un dominio es demasiado grande para que un equipo lo analice cómodamente, el método permite dividirlo también en subsistemas.

Esta separación favorece la reutilización: una interfaz, un servicio o una arquitectura pueden servir a más de una aplicación si sus contratos están bien definidos. Y aunque hoy resulte tentador compararlo con cualquier arquitectura distribuida, un dominio de Shlaer/Mellor no equivale automáticamente a un microservicio; es ante todo una separación conceptual del problema.

Tres modelos que forman uno solo

Al analizar un dominio, el método propone tres elementos fundamentales. No son documentos independientes que puedan contradecirse sin consecuencias, sino vistas integradas de una misma especificación:

  1. Modelo de información de objetos. Define los objetos entendidos como entidades conceptuales del dominio, sus atributos y las relaciones entre ellos. Está basado en el modelo relacional de datos, ampliado para que esas abstracciones también puedan tener comportamiento. Un objeto de análisis no debe confundirse sin más con una clase de Java o C++, ni este modelo con el diseño físico de una base de datos.

  2. Modelos de estados. Describen el ciclo de vida y el comportamiento de los objetos: en qué estado se encuentran, qué eventos reciben y qué transiciones producen. En la formulación de 1996 son autómatas finitos deterministas del tipo de máquina de Moore. No todos los objetos necesitan uno; aquellos que no tienen dinámica relevante pueden quedar sin modelo de estados.

  3. Especificaciones de acciones. Formalizan el procesamiento asociado a los estados. Los modelos de información y de estados dicen qué existe y cuándo sucede algo, pero todavía hace falta expresar qué cálculo, consulta o transformación se realiza. En el método original esto podía representarse mediante diagramas de flujo de datos de acciones o mediante un lenguaje de acciones bien definido.

La combinación es importante. Si solo dibujamos entidades y relaciones tenemos una descripción estática; si solo dibujamos estados perdemos la estructura sobre la que actúan; y si escribimos acciones sin reglas precisas volvemos a esconder decisiones esenciales en texto ambiguo. La propuesta de Shlaer/Mellor obliga a hacer explícitos los datos, el comportamiento y el procesamiento.

Ejecutar el análisis para verificarlo

Aquí aparece una de las ideas más interesantes del método: si los modelos son formales y están integrados, podemos comprobarlos antes de producir la implementación final.

La verificación tiene una parte estática, que comprueba reglas de sintaxis y consistencia entre los distintos modelos, y una parte dinámica, que ejecuta o simula su comportamiento. Para esta segunda, el procedimiento general consiste en establecer un estado inicial, enviar eventos a los modelos de estados, ejecutar las acciones especificadas y comparar el resultado con el comportamiento esperado.

Esto cambia el papel del análisis. En lugar de considerarlo terminado cuando todas las páginas están escritas, existe un criterio observable: el análisis está completo cuando puede ejecutarse y exhibir el comportamiento requerido. Por supuesto, que una simulación supere unos casos de prueba no demuestra que un sistema esté libre de errores; significa que podemos descubrir ambigüedades, omisiones y contradicciones mucho antes de que queden enterradas en el código.

También cambia la conversación con las personas que conocen el dominio. Ya no se trata únicamente de preguntar si un diagrama «parece correcto», sino de construir escenarios y observar si el modelo responde como debería. En sistemas de tiempo real, donde los eventos y las secuencias importan tanto como los datos, esta posibilidad resulta especialmente valiosa.

Del modelo al código: diseño recursivo

La otra gran aportación es la forma de llegar desde esos modelos hasta una implementación. Shlaer y Mellor distinguen entre elaboración y traducción.

En un enfoque de elaboración, el modelo de análisis se va transformando progresivamente: se añaden detalles de diseño, clases técnicas, estructuras de datos y decisiones de la plataforma hasta obtener el programa. El riesgo es que el modelo inicial y la implementación terminen siendo artefactos diferentes que haya que mantener por separado.

En la traducción, el modelo de análisis permanece centrado en el problema. Las decisiones sobre estructuras de datos, concurrencia, tareas, eventos o lenguaje se concentran en un dominio de arquitectura independiente de la aplicación. Esta arquitectura define mecanismos y reglas para sostener cualquier modelo que respete el formalismo de análisis. Después, componentes llamados arquetipos indican cómo convertir los elementos del modelo en estructuras concretas de software.

Por ejemplo, una regla de traducción podría establecer cómo un objeto con comportamiento se representa en cierto lenguaje, cómo se almacenan sus atributos y cómo se recorre su máquina de estados. El arquetipo contiene la estructura general; un procesador de arquetipos la completa con los nombres, atributos, eventos y acciones del modelo concreto. El resultado puede generarse de nuevo cuando el análisis cambia, en lugar de copiar manualmente cada modificación en varios lugares.

De forma simplificada, el recorrido completo queda así:

graph TB requisitos("Requisitos") requisitos --> dominios("Partición en dominios") dominios --> aplicacion("Análisis del dominio de aplicación") aplicacion --> verificacion("Verificación estática y simulación") verificacion --> servicios("Requisitos y análisis de dominios de servicio") servicios --> arquitectura("Especificación y construcción de la arquitectura") arquitectura --> traduccion("Traducción de los modelos") traduccion --> codigo("Sistema implementado")

El orden no obliga a terminar absolutamente todo un bloque antes de empezar el siguiente. El propio documento del método reconoce solapamientos e iteraciones, aunque procura delimitarlas dentro de cada dominio para mantener el trabajo bajo control.

La automatización puede llegar muy lejos, pero no es magia ni una promesa universal de «código gratis». Hacen falta modelos suficientemente precisos, una arquitectura adecuada, componentes de traducción y herramientas capaces de ejecutar el proceso. Dependiendo de cómo se expresen las acciones y de la tecnología empleada, ciertos algoritmos o componentes pueden requerir trabajo de implementación específico. La diferencia esencial está en dónde se concentra ese trabajo: en cada aplicación por separado o en mecanismos reutilizables.

Esta arquitectura también permite separar dos clases de cambios. Si cambia una regla del negocio, se modifica el modelo del dominio correspondiente. Si cambia la plataforma o una política técnica, se revisa la arquitectura y se propaga la modificación mediante la traducción. El objetivo no es eliminar el diseño, sino evitar que sus decisiones queden mezcladas con el significado de la aplicación.

Sally Shlaer: ingeniería con los pies en los sistemas reales

Detrás del rigor formal del método hubo una persona con una trayectoria muy práctica. Sally Shlaer nació en Cleveland, Ohio, el 3 de diciembre de 1938 y pasó parte de su infancia en Phoenix. En 1960 obtuvo una licenciatura en Matemáticas por la Universidad de Stanford, donde escribió sus primeros programas en Fortran y ensamblador para reducir el volumen de datos procedentes de experimentos de física.

Después cursó estudios de posgrado en la Universidad Nacional de Australia. De vuelta en Estados Unidos, comenzó en 1965 su trabajo en Los Alamos. Allí diseñó e implementó en ensamblador para una computadora SEL 810A un sistema operativo multitarea, basado en disco y de tiempo real para un acelerador de electrones. A comienzos de los años setenta también fue responsable del software de monitorización y control de la línea de haz de una instalación de tratamiento biomédico.

Estos detalles importan porque explican el carácter de su posterior trabajo metodológico. Shlaer no llegó al análisis de sistemas desde una discusión puramente terminológica: venía de construir software que debía responder a acontecimientos físicos y cuyo comportamiento importaba en tiempo real. La necesidad de comprender datos, estados y acciones no era abstracta para ella.

En 1977 pasó al Lawrence Berkeley Laboratory y dos años después asumió el liderazgo de software en el proyecto BART antes mencionado. Allí conoció a Mellor. Tras fundar juntos Project Technology en 1985, Shlaer ejerció como presidenta y trabajó por convertir el desarrollo de software en un proceso de ingeniería más racional, controlable y predecible, sin perder de vista la creación de un entorno donde las personas pudieran hacer bien su trabajo.

Page-Jones la recuerda además como una anfitriona que reunía a colegas, amigos y familiares alrededor de la mesa de su casa en Berkeley. Entre conversaciones cotidianas aparecían debates sobre análisis, diseño y arquitectura. Es una imagen útil porque devuelve algo humano a una historia que podría quedarse solo en autómatas y notaciones: aquellas ideas también se discutían, se probaban y se defendían en conversaciones entre colegas.

Shlaer continuó investigando sobre diseño recursivo durante sus últimos años, pese a una enfermedad crónica. Murió el 12 de noviembre de 1998, a los 59 años. Su nombre quizá no sea tan conocido como el de otras figuras de la orientación a objetos, pero su trabajo está en el centro de una visión muy actual: tratar los modelos como artefactos ejecutables y no como documentación decorativa.

Stephen J. Mellor: de los sistemas de tiempo real a los modelos ejecutables

Stephen J. Mellor se graduó en Ciencias de la Computación por la Universidad de Essex en 1974. Después trabajó en el CERN, donde escribió generadores de código para BCPL, un lenguaje anterior a C, y software de soporte para el entorno de investigación. En 1977 se incorporó al Lawrence Berkeley Laboratory y hacia 1979 llegó a liderar su grupo de sistemas de tiempo real.

Antes de formular Shlaer/Mellor, Mellor ya había acumulado otra experiencia metodológica relevante. En 1982 se unió a Yourdon y colaboró con Paul Ward en la adaptación de técnicas estructuradas al desarrollo de sistemas de tiempo real. El resultado se conoció como método Ward/Mellor y quedó recogido en la serie Structured Development for Real-Time Systems, publicada en 1985 y 1986. Esta trayectoria ayuda a entender que el método posterior no nació en el vacío ni como una negación absoluta de todo lo estructurado, sino dentro de una evolución de ideas y necesidades.

En Project Technology, Shlaer y Mellor convirtieron aquellas experiencias en un cuerpo de trabajo reconocible: modelado de información y estados, separación por dominios, diseño recursivo y traducción. En 1995 la empresa adquirió BridgePoint y durante aquel período también desarrolló un compilador de modelos, herramientas orientadas a editar, ejecutar y traducir modelos que acercaron la propuesta a la práctica industrial.

Cuando UML se convirtió en estándar del OMG en 1997, su notación ganó una posición dominante. Mellor ha contado con franqueza que no participar en aquel esfuerzo de unificación fue una decisión de la que luego se arrepintió profesionalmente. Project Technology terminó adoptando la notación UML y Mellor orientó buena parte de su trabajo posterior a dotarla de semántica de acciones y capacidades de ejecución.

En 2002 publicó junto a Marc J. Balcer Executable UML: A Foundation for Model-Driven Architecture. El libro no presenta UML como un simple lenguaje para dibujar la estructura del código, sino como un medio para especificar soluciones abstractas que puedan ejecutarse y compilarse hacia distintas plataformas. La continuidad con las preguntas de Shlaer/Mellor es evidente, aunque Executable UML también introduce cambios y abandona algunas convenciones de las raíces relacionales del método original.

Otra aparición quizá inesperada de Mellor en la historia del software es su presencia entre los firmantes del Manifiesto Ágil de 2001. Su participación recuerda que modelar y ser ágil no tienen por qué ser actividades opuestas. Si un modelo es ejecutable, puede proporcionar retroalimentación temprana y producir software funcionando; deja de ser aquella documentación pesada contra la que reaccionaban muchas propuestas ágiles.

El legado de Shlaer/Mellor

La primera precisión al hablar del legado es evitar una confusión histórica: Shlaer/Mellor no fue uno de los métodos que se unificaron para crear UML. UML nació principalmente del trabajo de Grady Booch, James Rumbaugh e Ivar Jacobson alrededor de Booch, OMT y OOSE. La relación de Shlaer/Mellor con UML llegó después, mediante correspondencias de notación, perfiles y el desarrollo de UML ejecutable.

Eso no reduce su influencia. El método había defendido desde sus inicios varias ideas que continúan siendo relevantes:

Estas ideas conectan con el desarrollo dirigido por modelos y con la distinción posterior de MDA entre modelos independientes y específicos de una plataforma. No sería riguroso atribuir todo MDA a una sola pareja o afirmar que Shlaer/Mellor inventó por separado cada uno de estos conceptos. Su aportación fue integrarlos en un camino coherente y practicable desde el análisis hasta la implementación.

Su linaje tampoco desapareció con los libros. Executable UML llevó la ejecución y la traducción a la notación UML, y BridgePoint continuó esa línea tecnológica. El editor de BridgePoint pasó a ser de código abierto en 2013 y el resto del conjunto, incluidos el verificador y los compiladores de modelos, en 2014. La comunidad xtUML mantiene documentación y herramientas para editar, ejecutar y traducir modelos, por lo que esta historia todavía tiene una presencia práctica y no únicamente museística.

El método también tenía límites. Exigía aprender reglas y abstracciones que no siempre resultaban sencillas, y durante años no existió un lenguaje de acciones estándar compartido por todas las herramientas. Los distintos proveedores desarrollaron lenguajes propietarios, cada uno con su propia sintaxis y reglas. Además, la posibilidad de generar una gran parte del sistema no eliminaba la necesidad de construir una buena arquitectura ni de comprender profundamente el dominio.

Quizá por eso su legado no debe medirse solo por cuántas personas utilizan hoy el nombre Shlaer/Mellor. Una idea puede sobrevivir adoptando otro vocabulario. Cada vez que hablamos de modelos ejecutables, compiladores de modelos, arquitecturas independientes de la aplicación o validación temprana del comportamiento, estamos conversando con problemas que Shlaer y Mellor ayudaron a formular con notable claridad.

Conclusión

Shlaer/Mellor fue mucho más que una notación anterior a UML: fue una propuesta para dividir los problemas en dominios, integrar datos, estados y acciones, verificar modelos mediante ejecución y traducirlos mediante arquitecturas reutilizables. Sally Shlaer aportó una experiencia profunda en sistemas reales y una visión rigurosa de la ingeniería; Stephen Mellor ayudó a llevar esa visión desde el tiempo real hasta UML ejecutable y el desarrollo dirigido por modelos. Su nombre no alcanzó la difusión de UML, pero muchas de sus preguntas siguen presentes cada vez que esperamos que un modelo no solo describa software, sino que también podamos ejecutarlo y convertirlo en un sistema funcionando.

Fuentes

← Volver al blog