Multimodelado específico del dominio

El DSL de entidad define la estructura de datos en OFBiz . El listado a continuación muestra la definición de la entidad Encuesta, que es el objeto de negocio que representa el concepto de una encuesta. El código en el listado es autoexplicativo: Se define una entidad llamada Encuesta con 10 campos. Cada campo tiene un nombre y un tipo. El campo surveyId se utiliza como clave primaria . Esta definición es cargada por un componente central en OFBiz llamado motor de entidades . El motor de entidades instancia un objeto de negocio correspondiente . El propósito del motor de entidades es administrar las propiedades transaccionales de todos los objetos de negocio e interactuar con varios mecanismos de persistencia como Java Database Connectivity , Enterprise JavaBeans o incluso algún sistema heredado .

<entity entity-name= "Survey" ... title= "Entidad de encuesta" > <field name= "surveyId" type= "id-ne" /> <field name= "surveyName" type= "name" /> <field name= "description" type= "description" /> <field name= "comments" type= "comment" /> <field name= "submitCaption" type= "short-varchar" /> <field name= "responseService" type= "long-varchar" /> <field name= "isAnonymous" type= "indicator" ... /> <field name= "allowMultiple" type= "indicator" ... /> <field name= "allowUpdate" type= "indicator" ... /> <field name= "acroFormContentId" type= "id-ne" ... / > <prim-key field= "surveyId" /> </entity>

El DSL de servicios especifica la interfaz de los servicios en OFBiz . Cada servicio encapsula parte de la lógica de la aplicación. El objetivo de este lenguaje es proporcionar una abstracción uniforme sobre los distintos mecanismos de implementación. Los servicios individuales pueden implementarse en Java, un lenguaje de scripting o mediante un motor de reglas . El listado a continuación muestra la interfaz del servicio createSurvey.

Además del nombre, el elemento de servicio especifica la ubicación y el comando de invocación de la implementación para este servicio. El atributo default-entity-name especifica que este servicio hace referencia a la entidad Survey que se definió en el listado anterior. Esto es una superposición entre los dos lenguajes, específicamente una llamada referencia suave . Un modelo en el DSL de Servicio hace referencia a un modelo en el DSL de Entidad. Esta referencia se utiliza en los dos elementos auto-attributes que se muestran a continuación, los cuales especifican la entrada y la salida del servicio en forma de atributos tipados. Como entrada, el servicio acepta atributos que corresponden a todos los campos que no son clave primaria (nonpk) de la entidad Survey, y estos atributos son opcionales. Como salida, el servicio devuelve atributos que corresponden a los campos de clave primaria (pk) de Survey, es decir, en este caso el campo surveyId, y estos atributos son obligatorios. El propósito de la referencia entre lenguajes es, en este caso, reducir la redundancia. Los atributos del servicio createSurvey corresponden a los campos de la entidad Survey y, por lo tanto, solo es necesario especificarlos una vez.

<service name= "createSurvey" default-entity-name= "Survey" ... location= "org/ofbiz/content/survey/SurveyServices.xml" invoke= "createSurvey" > ... <permission-service service-name= "contentManagerPermission" main-action= "CREATE" /> <auto-attributes include= "nonpk" mode= "IN" optional= "true" /> <auto-attributes include= "pk" mode= "OUT" optional= "false" /> </service>

El DSL de formularios se utiliza para describir el diseño y la apariencia visual de los formularios de entrada en la interfaz de usuario. El lenguaje consta de conceptos de dominio como Formulario y Campo. El listado a continuación muestra la implementación del formulario EditarEncuesta. En este caso, el DSL de formularios se superpone con el DSL de servicios. El atributo target del formulario y los elementos alt-target especifican que la entrada del envío de este formulario debe dirigirse a los servicios updateSurvey o createSurvey. El elemento auto-fields-service especifica que el formulario debe incluir un campo correspondiente a cada uno de los atributos del servicio updateSurvey (que son similares a los atributos del servicio createSurvey). Esto produce un efecto similar al de importar definiciones de otro modelo, como en el caso de los elementos auto-attributes del listado anterior. Más adelante, podemos ver que es posible personalizar la apariencia de estos campos importados , como isAnonymous. Finalmente, se agrega un botón submitButton con un título localizado para que el usuario pueda enviar sus datos al servicio de referencia.

<form name= "EditSurvey" type= "single" target= "updateSurvey" title= "" default-map-name= "survey" > <alt-target use-when= "survey==null" target= "createSurvey" /> <auto-fields-service service-name= "updateSurvey" /> <field use-when= "survey!=null" name= "surveyId" ... /> ... <field name= "isAnonymous" > <drop-down no-current-selected-key= "N" allow-empty= "false" > <option key= "Y" /><option key= "N" /> </drop-down> </field> ... <field name= "submitButton" title= "${uiLabelMap.CommonUpdate}" widget-style= "smallSubmit" > <submit button-type= "button" /> </field> </form>

El ejemplo de creación de encuestas , tal como se describe aquí, se implementa utilizando modelos en tres lenguajes diferentes. La implementación completa, de hecho, involucra aún más lenguajes, como un DSL de pantalla para especificar el diseño de la pantalla donde se coloca el formulario, y un DSL de Minilang, un lenguaje de manipulación de datos utilizado para implementar el servicio. Sin embargo, estos tres lenguajes ilustran la idea principal de concretar cada aspecto. El ejemplo también muestra una forma sencilla de reducir la redundancia al permitir que los lenguajes se solapen ligeramente.

Los lenguajes específicos de dominio , como los descritos anteriormente, tienen una expresividad limitada. A menudo es necesario agregar fragmentos de código en un lenguaje de propósito general como Java para implementar funcionalidades especializadas que están fuera del alcance de dichos lenguajes. Este método se denomina personalización multinivel . ^{[ 2 ]} Dado que este método se usa con mucha frecuencia en configuraciones con varios lenguajes, lo ilustraremos con una continuación del ejemplo. Llamemos a este el ejemplo de creación de PDF .

Supongamos que queremos crear un archivo PDF para cada respuesta a las encuestas en línea que los usuarios completan. Crear un archivo PDF está fuera del alcance de nuestros lenguajes, por lo que necesitamos escribir código Java que pueda invocar una biblioteca PDF de terceros para realizar esta funcionalidad especializada. Se requieren dos artefactos:

En primer lugar, se incluye un modelo de servicio adicional, como se muestra a continuación, en el DSL de servicio, que define la interfaz del servicio concreto para que pueda ser accedido a nivel de modelado. El modelo de servicio describe la ubicación de la implementación y cuáles son los atributos de entrada y salida.

<service name= "buildPdfFromSurveyResponse" engine= "java" location= "org.ofbiz.content.survey.PdfSurveyServices" invoke= "buildPdfFromSurveyResponse" > <attribute name= "surveyResponseId" mode= "IN" optional= "false" ... /> <attribute name= "outByteWrapper" mode= "OUT" optional= "false" ... /> </service>

En segundo lugar, necesitamos un fragmento de código, como se muestra a continuación, que contenga la implementación real de este servicio. Un servicio puede tener múltiples entradas y salidas, por lo que la entrada al método Java es un mapa, llamado contexto, que relaciona los nombres de los argumentos con sus valores, y devuelve la salida en forma de otro mapa, llamado resultados.

public static Map buildPdfFromSurveyResponse ( DispatchContext dctx , Map context ) { String id = ( String ) context . get ( "surveyResponseId" ); Map results = new HashMap (); try { // ...la respuesta se recupera de la base de datos... // ...se crea un PDF a partir de la respuesta... // ...el PDF se serializa como un array de bytes... ByteWrapper outByteWrapper = ...; results . put ( "outByteWrapper" , outByteWrapper ); } catch ( Exception e ) {} return results ; }

Este método de personalización multinivel utiliza referencias flexibles similares al ejemplo de creación de encuestas . La principal diferencia radica en que la referencia se establece entre modelo y código, en lugar de entre modelos. La ventaja, en este caso, es que se puede aprovechar una biblioteca Java de terceros para la creación de archivos PDF. Otra aplicación típica consiste en utilizar fragmentos de código Java para invocar servicios web externos e importar los resultados en un formato adecuado.

El primer problema que encuentran los desarrolladores al comenzar a desarrollar con múltiples lenguajes es la cacofonía lingüística . Aprender los diferentes lenguajes y comprender su interacción es necesario para dar sentido a la compleja composición de los artefactos. El marco OFBiz , por ejemplo, tiene diecisiete lenguajes diferentes y más de 200 000 líneas de código de lenguaje específico del dominio, ¡por lo que la complejidad puede ser bastante abrumadora! Actualmente no existe un método establecido para caracterizar los diferentes lenguajes de manera que los desarrolladores puedan alcanzar rápidamente una comprensión operativa. Las herramientas son importantes aquí como mecanismo ad hoc para el aprendizaje y la exploración, ya que los desarrolladores suelen utilizarlas para aprender mediante experimentos. Hay tres áreas en particular donde las herramientas para modelos específicos del dominio son útiles:

1. Comprender un idioma
2. Comprender las interacciones lingüísticas
3. Comprender cómo usar los idiomas

En primer lugar, comprender un lenguaje puede ser difícil, y en el caso de los lenguajes específicos de dominio basados ​​en XML, una objeción frecuente e intuitiva es la de que la sintaxis importa . Este argumento se puede formular de la siguiente manera: «Los diferentes lenguajes son difíciles de entender y solo aumentan la confusión porque su sintaxis basada en XML es particularmente verbosa e ininteligible. Sería mejor usar un único lenguaje de propósito general como Java, ya que así los desarrolladores podrían confiar en una sintaxis que ya conocen». Si bien esta objeción es sin duda importante, omite un punto central. XML o un formato de representación similar puede no ser la sintaxis con la que los desarrolladores trabajan realmente. Una de las ventajas de usar lenguajes específicos de dominio basados ​​en XML es que podemos proporcionar editores específicos de dominio. La siguiente figura muestra cómo podría ser un editor hipotético para el DSL de Entidad. Este editor presenta el dominio de una manera simple y visualmente atractiva, pero bien podría usar la representación XML (y quizás una configuración de diseño) subyacente.

Así como podríamos quejarnos de que XML es una mala elección, también podríamos objetar que un lenguaje de propósito general como Java es una mala elección para ciertas tareas. Además, los desarrolladores podrían sentirse menos intimidados por el editor de la figura que por los listados de código en XML o Java. Si aceptamos que la sintaxis importa, entonces el uso de diferentes lenguajes con editores personalizados se convierte en una estrategia razonable. La simplicidad del editor hace que el lenguaje sea más fácil de entender y, por lo tanto, más fácil de usar. En otras palabras, la objeción de que la sintaxis importa podría ser la razón por la que exploramos el campo de los lenguajes específicos de dominio .

En segundo lugar, las interacciones lingüísticas revelan relaciones entre lenguajes. Los desarrolladores deberían poder saltar entre elementos relacionados en diferentes artefactos. La facilidad de navegación entre distintos artefactos de software es un criterio importante para las herramientas en entornos de desarrollo tradicionales. Aunque no hemos realizado estudios empíricos en este ámbito, planteamos la hipótesis de que unas herramientas de navegación adecuadas aumentan la productividad. Esta afirmación se ve respaldada por la observación de que todos los principales entornos de desarrollo actuales ofrecen herramientas de navegación bastante sofisticadas, como un explorador de jerarquía de tipos o la capacidad de localizar y saltar rápidamente a referencias a la definición de un método. Los entornos de desarrollo pueden proporcionar estas herramientas de navegación porque mantienen un modelo de los archivos fuente que se actualiza continuamente en forma de un árbol de sintaxis abstracta .

En un entorno de desarrollo con múltiples lenguajes, la navegación resulta mucho más compleja. Los entornos existentes no están diseñados para analizar y representar modelos DSL como árboles de sintaxis abstracta para lenguajes arbitrarios, e incluso específicos de la aplicación, como los del ejemplo anterior. Además, sin esta representación interna, los entornos existentes no pueden resolver referencias intra- ni inter-lenguaje para dichos lenguajes y, por lo tanto, no pueden proporcionar una navegación útil. Esto implica que los desarrolladores deben mantener un modelo conceptual de cómo se relacionan las partes de su sistema. Por otro lado, las nuevas herramientas con funciones de navegación adaptadas a múltiples lenguajes serían de gran ayuda para comprender las relaciones entre ellos. En el ejemplo de creación de encuestas, dichas herramientas deberían mostrar las relaciones entre los tres lenguajes utilizando las referencias suaves como puntos de navegación.

En tercer lugar, para comprender el uso del lenguaje, debemos ser capaces de distinguir las operaciones de edición correctas de las incorrectas en nuestro entorno de desarrollo. Los entornos de desarrollo tradicionales han proporcionado orientación durante mucho tiempo durante la escritura de un programa. La compilación incremental permite que el entorno ofrezca sugerencias detalladas al desarrollador, como por ejemplo, cómo completar una instrucción. También existen tipos de orientación más intrusivos, como los editores orientados a la sintaxis, donde solo se puede introducir texto que se ajuste a la gramática. Los editores de texto genéricos que se pueden parametrizar con la gramática de un lenguaje existen desde hace mucho tiempo. ^{[ 3 ]}

Los editores actuales no tienen en cuenta las relaciones de coherencia entre lenguajes al proporcionar orientación. En el ejemplo anterior, un editor ideal debería, por ejemplo, sugerir el servicio `createSurvey` como un valor válido cuando el desarrollador edita el atributo de destino en la definición del formulario. Un entorno que pudiera razonar sobre artefactos de diferentes lenguajes también podría ayudar al desarrollador a identificar estados del programa donde existiera coherencia local, pero no global. Esta situación puede surgir cuando un modelo está bien formado y, por lo tanto, es localmente coherente, pero al mismo tiempo viola una restricción entre lenguajes. La orientación o la asistencia inteligente en forma de propuestas sobre cómo completar un modelo sería útil para configuraciones con múltiples lenguajes y restricciones de coherencia complejas. Las operaciones de edición sugeridas por la herramienta podrían facilitar al desarrollador el inicio del proceso de aprendizaje del uso de los lenguajes.

El aspecto técnico del problema de coordinación radica esencialmente en garantizar la coherencia. ¿Cómo podemos detectar inconsistencias entre modelos de distintos lenguajes durante la fase de modelado? Para comprender plenamente la complejidad de los requisitos de coherencia de un sistema basado en múltiples lenguajes, resulta útil refinar nuestro concepto de coherencia.

La consistencia puede ser intra- o inter-. La consistencia intra- se refiere a la coherencia de los elementos dentro de un mismo modelo. En este caso, el modelo debe ajustarse a su metamodelo, es decir, debe tener una sintaxis correcta. En el ejemplo de creación de encuestas, el modelo de entidad debe ajustarse al esquema XSD del DSL de entidad. Este esquema es el metamodelo del DSL de entidad y especifica cómo se pueden componer los elementos y cuáles son, en cierta medida, los dominios válidos de los atributos.

La interconsistencia se logra cuando se pueden resolver las referencias entre diferentes lenguajes. Este tipo de consistencia se puede subdividir en (1) consistencia entre modelos y (2) consistencia entre modelos y código. La consistencia entre modelos se refiere a la integridad referencial , así como a las restricciones de alto nivel del sistema. En el ejemplo de creación de encuestas , el atributo default-entity-name del listado de Servicios hace referencia al atributo name del listado de Entidades. Si modificamos uno de estos valores sin actualizar el otro, se rompe la referencia. También existen restricciones de consistencia de alto nivel entre diferentes modelos, como se explicará más adelante. Un proyecto puede tener ciertos patrones o convenciones para nombrar y relacionar los elementos del modelo. Los entornos de desarrollo actuales deben adaptarse a lenguajes específicos mediante complementos escritos a mano o mecanismos similares para garantizar la consistencia entre lenguajes como los del ejemplo anterior.

La coherencia entre modelo y código es un requisito esencial en la personalización multinivel. Cuando los modelos se complementan con fragmentos de código, como en el ejemplo de generación de PDF , es necesario verificar que modelos y código coincidan . Esto implica, en parte, asegurar que las referencias implícitas entre modelos y código no se rompan, de forma similar a la integridad referencial en la coherencia entre modelos. Pero también implica garantizar que el código no infrinja las expectativas establecidas en el modelo. En el ejemplo de generación de PDF , el modelo especifica que `outByteWrapper` siempre formará parte de la salida; es decir, la clave `outByteWrapper` se incluye en el mapa de resultados. Un análisis del código muestra que `outByteWrapper` solo formará parte de la salida si no se generan excepciones antes de la línea 10. En otras palabras, algunas posibles ejecuciones del código infringirán una especificación a nivel de modelado. En términos más generales, podemos afirmar que la personalización multinivel impone restricciones muy precisas a los modelos y fragmentos de código involucrados.

El problema de coordinación surge del hecho de que se utilizan múltiples idiomas en un mismo sistema. Las dos subsecciones anteriores ilustran que este problema tiene tanto un aspecto conceptual como un aspecto técnico de bajo nivel. Los desafíos que hemos descrito son reales, no hipotéticos. Específicamente, hemos enfrentado estos desafíos en dos estudios de caso concretos y representativos: un sistema de planificación de recursos empresariales, OFBiz , y un sistema de atención médica , el Sistema de Información de Salud del Distrito ( DHIS ). Ambos casos son sistemas de tamaño mediano que se utilizan en la industria. Nuestra solución a los problemas prácticos que hemos encontrado durante nuestro trabajo con estos sistemas es un conjunto de directrices y prototipos. A continuación, presentaremos un marco conceptual general que incorpora las directrices y los prototipos en un método coherente: el método de coordinación .

El objetivo de la etapa de identificación es detectar solapamientos entre lenguajes. Como se describe en el ejemplo, un solapamiento es un área donde coinciden las funcionalidades de dos lenguajes. Las referencias indirectas de Form DSL a Service DSL y de Service DSL a Entity DSL en el caso de uso de creación de encuestas son ejemplos de dichos solapamientos. Otro ejemplo es el caso en el que se utiliza un fragmento de código personalizado para extender un modelo. Estos solapamientos son frecuentes cuando se necesita la expresividad de los lenguajes de propósito general para implementar requisitos especializados que están fuera del alcance del modelo. La etapa de identificación puede ser un proceso manual o automático, según la complejidad de los solapamientos. Una vez identificados y explicitados los solapamientos, esta información se utiliza como entrada para la segunda etapa del método: la etapa de especificación.

El objetivo de la etapa de especificación es crear un modelo de coordinación que defina cómo interactúan los lenguajes. Las referencias entre diferentes lenguajes en un sistema constituyen el modelo de coordinación para dicho sistema. Este se crea mapeando los principales artefactos de software a una representación común. También se puede codificar información adicional, como restricciones específicas del dominio o de la aplicación, para proporcionar una representación más completa. El modelo de coordinación se basa en información genérica, como gramáticas y restricciones de lenguaje, así como en información específica de la aplicación, como modelos concretos y restricciones propias de la aplicación. Esto significa que, aunque se utilicen los mismos lenguajes en varios productos, cada producto tiene la especificación de su propio modelo de coordinación. El modelo de coordinación sirve de base para diversos razonamientos en la etapa final del método: la etapa de aplicación.

El objetivo del paso de aplicación es aprovechar el modelo de coordinación. Este modelo permite que las herramientas obtengan tres capas de información útil. En primer lugar, el modelo de coordinación se puede utilizar para garantizar la coherencia entre varios lenguajes. El modelo de coordinación especifica relaciones de coherencia, como la forma en que los elementos de diferentes lenguajes pueden referirse entre sí. Las herramientas pueden garantizar la integridad referencial y realizar comprobaciones estáticas del sistema final antes de su implementación. En segundo lugar, las relaciones de coherencia se utilizan para navegar, visualizar y mapear la red de diferentes lenguajes en un entorno de desarrollo. Esta información se utiliza para vincular y relacionar rápidamente elementos de diferentes lenguajes y para proporcionar trazabilidad entre diferentes modelos. En tercer lugar, basándose en las relaciones de coherencia y la información de navegación sobre cómo se relacionan los elementos, las herramientas pueden proporcionar orientación, específicamente autocompletado o asistencia. El autocompletado del modelo se puede proporcionar, por ejemplo, de forma genérica en herramientas específicas de dominio.

El método de coordinación ^{[ 1 ]} puede considerarse un marco conceptual que prescribe un flujo de trabajo específico para trabajar con múltiples lenguajes. Los tres pasos sucesivos que componen este flujo de trabajo no cuentan con el soporte de un entorno de desarrollo o plataforma de trabajo integrado. El enfoque se centra en extender los entornos existentes del desarrollador para añadir soporte para (1) identificación, (2) especificación y (3) aplicación. La principal ventaja de este enfoque radica en que los desarrolladores han probado nuestro trabajo y nos han proporcionado retroalimentación. Este tipo de evaluación del método es valiosa, ya que reduce el riesgo de resolver un problema puramente hipotético. Diversos artículos presentan los diferentes pasos del método de coordinación, informan sobre esta evaluación y profundizan en los aspectos técnicos de cada experimento. En general, los resultados han sido prometedores: se ha detectado un número significativo de errores en sistemas de producción, lo que ha propiciado un diálogo constructivo con los desarrolladores sobre los requisitos de las herramientas futuras. Un proceso de desarrollo basado en estas directrices y con el apoyo de herramientas constituye un intento serio de resolver el problema de la coordinación y convertir el multimodelado específico del dominio en una propuesta práctica.