Aumente su productividad con la ingeniería basada en modelos (1ª parte)

Introducción

Cuando nos preguntan por nuestra ocupación, a los desarrolladores no nos faltan las palabras. Podemos describirnos de varias maneras: "Desarrollador de software", "Programador informático", "Informático", "Codificador", "Ingeniero de software" u otras funciones más especializadas, como "Arquitecto de software", "Ingeniero de DevOps", "Defensor del desarrollador", etc. A veces utilizamos estos términos indistintamente o elegimos el que más nos suena. Pero si lo piensas bien, ¿es realmente lo mismo un "Programador Informático" que un "Ingeniero de Software"? En muchos casos, puede serlo. Yo, como muchos, si no la mayoría de los programadores, disfruto profusamente programando. Es sin duda la piedra angular de nuestra profesión y lo que atrajo a muchos de nosotros a esta línea de trabajo.

Sin embargo, es importante reconocer que este campo se basa en abstracciones. A primera vista, el trabajo de un programador informático ha cambiado drásticamente desde sus primeros días de tarjetas perforadas. La mayoría de nosotros no sabemos ensamblador, ni siquiera C, que entonces (y ahora) se consideraba un lenguaje de programación de "alto nivel". La tarea de un programador (o "codificador") es, en última instancia, transmitir instrucciones al hardware subyacente para que realice algunas operaciones. Sin embargo, no es así como la mayoría de nosotros concebimos nuestro trabajo en el día a día. En cambio, pensamos a un nivel de abstracción superior, en términos de soluciones. Así, la programación, por divertida y desafiante que sea, es un medio para alcanzar un fin. De ahí que el término "ingeniero de software" sea un cajón de sastre más inclusivo para todo el proceso de desarrollo. Si la ingeniería de software es como construir una casa, la programación es la parte en la que se ponen los ladrillos.

Por desgracia, la programación no siempre es divertida ni propicia la resolución de problemas. Especialmente en el caso de lenguajes prolijos como Java, suele ser una tarea pesada. Es el resultado de la repetición de código: código repetitivo y tedioso de escribir a mano, pero necesario y útil. Suele ser el aspecto menos productivo de la programación y, casualmente, el más automatizable. Aunque los IDE son buenos generando código repetitivo común, como getters y setters, toString(), equals y hashCode()sólo pueden satisfacer las necesidades genéricas comunes del lenguaje, no del dominio. Si existiera una forma de eliminar el tedioso proceso de escribir a mano la plantilla específica del dominio...

¿Qué es la ingeniería basada en modelos?

La Ingeniería Dirigida por Modelos (MDE) es una disciplina que promueve modelos como artefactos de primera clase en el proceso de ingeniería, elevando el nivel de abstracción. Aplicado a la ingeniería de software, significa que en lugar de código fuente el principal artefacto de interés, nos preocupamos más por el modelo de dominio.

Aunque MDE es a menudo un término y una disciplina académica, ha ganado una atención más generalizada a través del término "bajo-código" - algo que también conocen los académicos. Se puede argumentar que el MDE tiene un alcance más amplio que el movimiento low-code, pero en la práctica, estas diferencias semánticas suelen ser de interés académico -¡perdón por el juego de palabras!

Se preguntará: ¿qué es un modelo? Bueno, es cualquier cosa que describe declarativamente el dominio. Se puede pensar en un modelo como en datos específicos del dominio. Lo importante es que estos datos estén estructurados de forma predecible. En lenguaje MDE, llamamos a esta estructura el metamodelo. El metamodelo es en sí mismo un modelo que describe el "plano" del dominio, de forma similar al plano de un arquitecto que sirve de guía para la construcción de un edificio. Para que esto quede más claro, veamos algunos ejemplos.

Metamodelos

La idea de un metamodelo es restringir lo que puede expresarse cuando se utilizan herramientas y lenguajes de uso general. Algunos ejemplos de tecnologías de metamodelado son Esquema XML (XSD)JSON Schema o cualquier esquema de base de datos. Así es: si alguna vez has trabajado con una base de datos relacional, un documento XML o cualquier tipo de archivo de configuración, ya estás familiarizado con este concepto, aunque puede que no hayas pensado en él en estos términos.

Hay muchos ejemplos disponibles, aunque por brevedad y con fines ilustrativos, no los proporcionaré aquí directamente. Pero cuando empiece a pensar en esquemas como metamodelos y los datos estructurados que se ajustan a esos esquemas como modelospuede tener sentido intuitivamente. Considere el archivo "CustomersOrders.xsd" de este tutorial. Ese archivo está modelando efectivamente los conceptos del dominio y cómo se relacionan entre sí. En "CustomersOrder.xml es una instancia de este modelo que se ajusta al metamodelo "CustomersOrders.xsd". metamodelo. Si está familiarizado con la programación orientada a objetos, puede pensar en los metamodelos como clases y en los modelos como objetos (es decir, instancias de esas clases). En la programación orientada a objetos, una clase define el esquema para instancias concretas (objetos). Otro ejemplo es este esquema JSON mínimo. Define una Persona que tiene tres propiedades: firstName, lastName y age.

En ambos casos, ¿se ha dado cuenta de que el propio metamodelo está escrito en el mismo lenguaje que el modelo? Es decir, un archivo XSD utiliza la misma sintaxis que XML, y un esquema JSON está escrito en JSON. El corolario es que los propios metamodelos son modelos que se ajustan a un metamodelo. Alucinante, ¿verdad? En otras palabras, existe un esquema para el metamodelo. Por suerte, en la mayoría de los casos, este metamodelo de nivel superior suele ser el punto final. Los metamodelos suelen ajustarse a sí mismos. No es broma. hay literalmente un archivo XSD que define el metamodelo para XSDs¡!

Marco de modelización Eclipse

Una vez definidos los principales conceptos de la ingeniería basada en modelos, pasemos ahora a las herramientas. Aunque los esquemas y modelos pueden definirse (y a menudo se definen) utilizando herramientas convencionales y formatos de serialización como JSON y XML, para adoptar realmente la MDE, sería beneficioso estar familiarizado con las herramientas específicas utilizadas por los profesionales de la MDE. Debido a la historia de MDE, con sus raíces fuertemente académicas y empresariales, la Fundación Eclipse está ampliamente considerada como la plataforma de origen de las herramientas MDE más consolidadas. Para ello es fundamental Marco de Modelado Eclipse (EMF). En esencia, el proyecto define un marco para definir metamodelos y herramientas para trabajar con ellos mediante programación en Java. Como habrá adivinado, incluye el metamodelo - llamado Ecore. He aquí un diagrama simplificado de los principales conceptos y la jerarquía de Ecore:

Hay mucho más, por supuesto - aquí tienes un esquema UML más detallado. Pero no te preocupes - no es algo que necesites saber. Son Concepts que te resultarán intuitivos cuando utilices Ecore para definir tu metamodelo. Por supuesto, hay tutoriales en línea para EMFaunque algunos pueden ser bastante anticuados. Siguen siendo relevantes ya que EMF ha sido estable durante mucho tiempo.

Puede definir metamodelos Ecore utilizando el editor de árbol incorporado, lenguajes visuales como UML, o textuales como Emfaticcon el que es mucho más fácil trabajar que con el XML, en el que se basan todos los metamodelos de Ecore. Herramientas empresariales como Papyrus y Sirius se basan en EMF y ofrecen funciones más potentes para trabajar con modelos. Incluso puede definir su metamodelo como una gramática para un lenguaje específico del dominio utilizando Xtext.

Es mucho para asimilar. La idea es ofrecerle una visión general de las herramientas y tecnologías disponibles. Como puede ver, las herramientas MDE y sus principios son bastante ricos, están bien establecidos y son relativamente maduros. Puedes definir tus modelos y metamodelos de forma gráfica o textual y, dado que muchas herramientas se basan en EMF, una vez definido el metamodelo, puedes generar código Java a partir de él y trabajar con él mediante programación si lo deseas.

Gestión de modelos

Ahora que ya conoce el metamodelado y las herramientas que pueden utilizarse para definir (meta)modelos, es posible que se pregunte: ¿y qué? ¿Qué puedo hacer con estos modelos? ¿Por qué dedicar todo este tiempo y esfuerzo a definir un esquema que, en última instancia, limita lo que puedo expresar utilizando un lenguaje general? Pues bien, ahí es donde entra el verdadero valor del MDE. El metamodelo es necesario para poder trabajar con modelos a un nivel abstracto. La gestión de modelos es el proceso de actuar sobre los modelos. Estas tareas incluyen lo siguiente:

• Visualización: Presentación de diferentes vistas y representaciones gráficas de un modelo para diversos fines y públicos.

• Consulta: Obtención de datos a partir del modelo, a menudo mediante expresiones de cálculo intensivo.

• Validación: Los metamodelos no suelen ser lo suficientemente potentes como para expresar todas las restricciones relativas a un modelo de dominio, por lo que se necesita lógica programática adicional para garantizar que los modelos están bien formados.

• Comparación: Comparación de modelos y actuación programática en función de las diferencias.

• Fusión: Tomar varios modelos de entrada y producir un único modelo de salida.

• Migración: Mapeo de un modelo a una versión evolucionada del metamodelo.

• Transformación: Modificación de un modelo o producción de un modelo de salida diferente (que puede ajustarse a un metamodelo diferente).

• Generación de textos: Utilización de modelos para generar resultados textuales, como código fuente y documentación.

Como habrás adivinado, también existen herramientas para todas estas tareas. El lenguaje de facto utilizado para validar modelos que superan las capacidades de Ecore es el lenguaje de restricciones de objetos (OCL). Puede aprender más sobre él en un tutorial introductoriopor lo que no me detendré aquí en los detalles. Sin embargo, es útil saber que muchos otros lenguajes de gestión de modelos se basan o se inspiran en las expresiones, la sintaxis y la semántica de OCL. La bibliografía sobre transformaciones de modelo a modelo es amplia y a menudo bastante compleja, ya que es el área central de investigación en el ámbito académico para MDE. Existen, por supuesto, lenguajes para transformaciones de modelos, como ATL y QVTpero no nos detendremos en ellos.

Como desarrollador, ¿qué es lo que realmente realmente? La productividad, ¿verdad? Esa es la premisa de todo el debate. Dado que gran parte de nuestro día a día se dedica a escribir documentación y código repetitivo, lo que queremos es autogenerar la mayor parte posible para poder centrarnos en las cosas divertidas y en las partes que requieren más atención o conocimientos de ingeniería. Aquí es donde la transformación de modelo a texto puede ayudar. Existen estándares como MOF M2T y herramientas que se ajustan a ellos, como Acceleopero es posible que esté familiarizado con herramientas más convencionales como Páginas de servidor Jakarta (JSP). Aunque Java en la web parece una reliquia de principios de la década de 2000, el principio en el que se basa sigue siendo válido. Al fin y al cabo, el lenguaje lenguaje PHP significa literalmente "Preprocesador de Hipertexto" y sigue siendo ampliamente utilizado. Pero, ¿qué tienen que ver JSP y PHP con la generación de código y la ingeniería basada en modelos? Lo retomaremos en la segunda parte de este artículo. Antes de eso, vamos a echar un vistazo a una herramienta que se utilizará para demostrar esto.

Epsilon

Hemos tratado brevemente los principales Concepts de MDE y algunas herramientas, pero ¿cómo encaja todo? Disponemos de diferentes tecnologías de metamodelado, por lo que los modelos pueden estar en varios formatos, aunque la mayoría de las herramientas que he mencionado hasta ahora se basan en EMF. Además, como cada tarea de gestión de modelos tiene su propia herramienta, con sintaxis y semántica variables para definir la lógica de consulta/transformación, puede parecer que MDE es demasiado complejo y pesado, dada la pronunciada curva de aprendizaje. Sin embargo, existe un proyecto (basado en Eclipse, naturalmente) que pretende unificar las distintas tecnologías de modelización y las tareas de gestión de modelos: Epsilon. He contribuido ampliamente a Epsilon durante mi doctorado, así que, por supuesto, voy a ser un poco parcial.

No voy a dedicar mucho tiempo a explicar Epsilon y su arquitectura. la documentaciónaunque haré una breve introducción. Básicamente, Epsilon proporciona una familia de lenguajes de gestión de modelos específicos para cada tarea, construidos sobre un lenguaje de consulta común llamado EOL. Está inspirado en la sintaxis de OCL, pero se comporta mucho más como Java, ya que está implementado en Java y hace un uso intensivo de las capacidades de reflexión de Java. Incluso se puede llamar a código Java nativo desde EOL, por lo que, en esencia, EOL es un lenguaje de programación completo con todas las construcciones de programación imperativas habituales, así como operaciones declarativas para trabajar con colecciones.

Además, Epsilon es compatible con múltiples tecnologías de modelado y no está vinculado a EMF. Aunque es muy compatible con los modelos de EMF y se integra con otras herramientas de EMF, su capa de conectividad de modelos significa que los lenguajes están desacoplados del formato de persistencia del modelo subyacente, por lo que se puede utilizar con varios tipos de modelos, como XML, CSV y otros formatos de hojas de cálculo, bases de datos compatibles con JDBC. Simulink y más. Así, Epsilon proporciona una solución todo en uno para la gestión de modelos sin tener que trabajar con diferentes herramientas basadas en la tecnología de modelado. Incluso puede combinar varios modelos de distintos tipos dentro del mismo programa y trabajar con ellos de manera uniforme.

Eso es todo por ahora...

Uf, ¡hay mucho que asimilar! Pero prometo que en la próxima parte, todo se unirá a través de un ejemplo práctico. Específicamente, demostraré cómo usé Epsilon para automatizar efectivamente la escritura de una gran cantidad de código para el SDK Java de Vonage.

Si tiene algún comentario o sugerencia, no dude en ponerse en contacto con nosotros en X, antes conocido como Twitter o pásate por nuestro Slack de la comunidad. Espero que este artículo haya sido útil y agradezco cualquier opinión. Si te ha gustado, echa un vistazo a mis otros artículos sobre artículos sobre Java.