Un artículo publicado en Stack Overflow Blog invita a reconsiderar el concepto de programación orientada a modelos (Model Oriented Programming), como una tendencia capaz de separar los requisitos del sistema de su diseño de software y, después, utilizar el propio modelo para ayudar a crear y mantener el sistema. El autor se basa en una experiencia anterior durante la cual desarrolló, hace 13 años, un lenguaje y un entorno de desarrollo llamados Mo+, y afirmó que los utilizó en proyectos empresariales, aunque la idea no se difundió ampliamente.
El material no es un anuncio de un lenguaje disponible ni un nuevo proyecto de investigación, sino una tesis que invita a investigar y desarrollar más este campo, especialmente en un contexto en el que aumentan la importancia de la inteligencia artificial y la complejidad de los sistemas de software.
El modelo como estructura y datos
El autor propone definir el modelo mediante dos elementos: una estructura que determina las reglas o el esquema, y datos que cumplen esa estructura. La estructura es jerárquica: comienza con un nodo raíz y se ramifica en nodos y propiedades, con la posibilidad de que una propiedad haga referencia a otro nodo cuando sea necesario. Desde esta perspectiva, el esquema de una base de datos relacional puede representarse de forma jerárquica mediante nodos como la base de datos, la tabla, la columna y la clave, aunque los datos en sí estén distribuidos en filas y relaciones.
El artículo utiliza un escenario simplificado de restaurantes para explicar la idea, con restaurantes, clientes, empleados, elementos del menú y las relaciones entre ellos. Presenta más de una estructura posible para representar el mismo escenario y señala que la elección de la estructura influye en la facilidad para recorrer el modelo y en la forma de escribir los programas que dependen de él.
Cuatro formas de desarrollo orientado a modelos
- Modelado informal: modelos en la mente, sobre papel o en diagramas que no son utilizados directamente por herramientas de software.
- Modelado integrado: un modelo dentro del código, como en marcos ORM como Entity Framework y NHibernate, o en marcos de interfaces de usuario como Angular y React.
- Modelado acoplado: un modelo externo, normalmente mediante UML, estrechamente vinculado a los elementos del código y a las herramientas que los gestionan.
- Modelado separado: un modelo centrado en los requisitos, los datos y el flujo de trabajo, dejando el diseño detallado al código, de modo que cada elemento del modelo no esté vinculado a un componente de software específico.
El autor considera que las mayores posibilidades se encuentran en el modelado acoplado y el separado, especialmente en este último, porque sitúa los requisitos en el modelo y el diseño en el código. Según afirma, su experiencia personal hizo que el proceso de modelado y programación fuera más fluido.
Del modelo al sistema
El artículo divide el uso de la programación orientada a modelos en tres ámbitos. En el patrón de transición, el programa interpreta el modelo y produce código fuente, archivos de configuración o documentación que pueden desarrollarse posteriormente. En el patrón de modelado de modelos, el lenguaje ayuda a crear y mantener la estructura y los datos del modelo. En cuanto al patrón de destino, utiliza directamente el lenguaje para construir y gestionar el entorno del sistema, lo que requiere un lenguaje más completo.
Características del lenguaje propuesto
Una de las propuestas principales es hacer que la estructura del modelo forme parte de las reglas del lenguaje, de modo que sea posible trabajar directamente con nodos como Entity, Property y Relationship, en lugar de crear clases y objetos específicos para representarlos. El autor también propone un contexto orientado al modelo que dependa de la ubicación del programa dentro del árbol de datos, con una pila que permita subir a los nodos padre o bajar a los elementos secundarios y buscar entre ellos.
Otra idea aparece en las «propiedades orientadas a modelos»: partes independientes del código vinculadas a un tipo concreto de nodo que pueden evaluarse sobre varias instancias. Estas propiedades pueden componerse para producir código, como crear la definición de una clase o sus propiedades, o utilizarse en operaciones de búsqueda y filtrado. En el patrón de transición, la propiedad puede incluir una operación put para guardar el resultado en un archivo o en un entorno de destino.
El autor propone también reglas dinámicas mediante las cuales el intérprete añade los nodos y las propiedades del modelo a las reglas del lenguaje al iniciar una sesión de programación. Esto resulta útil cuando el modelo estándar no contiene información suficiente o cuando el modelo es específico de una organización o un ámbito determinado. Asimismo, plantea reglas contextuales que limitan las operaciones permitidas dentro de distintas partes del programa, con el fin de reducir los efectos secundarios y separar las responsabilidades de lectura y escritura.
¿Por qué importa este planteamiento?
El valor práctico de la idea reside en el intento de hacer que el modelo sea ejecutable, y no solo un documento de diseño separado del ciclo de desarrollo. Si fuera posible vincular los requisitos, los datos y el flujo de trabajo con mecanismos de generación y mantenimiento reutilizables, podría reducirse la duplicación entre el modelo y el código. Sin embargo, el artículo no presenta un lenguaje estandarizado, herramientas disponibles ni resultados comparativos que demuestren la superioridad de este enfoque frente a los marcos actuales de modelado y generación de código.
Siguen abiertas preguntas importantes: ¿cómo se gestionan los modelos grandes y cambiantes? ¿Cómo se prueba el código generado? ¿Y cuáles son los límites de las reglas dinámicas en términos de legibilidad, seguridad e integración con las herramientas de desarrollo? Por ello, el material parece más una invitación de valor investigador para desarrolladores de lenguajes y académicos que una solución lista para su uso inmediato.