Domain Specific Modeling - Introducción

Domain Specific Modeling - Introducción

Rate This
  • Comments 2

El Modelado Específico de Dominio (Domain Specific Modeling) es una metodología que permite describir sistemas complejos mediante modelos abstractos que expresan los conceptos fundamentales del dominio del problema a resolver. Estos modelos abstractos dan origen a modelos más concretos hasta llegar a los componentes más esenciales de un sistema, como son: código fuente, scripts, archivos de configuración y recursos, entre otros.

La idea de poder diseñar e implementar un sistema usando herramientas de este tipo es bastante atractiva ya que el modelo es nuestro sistema. Se imaginan una herramienta que permita modelar procesos de negocios complejos y que con tan solo modelarlos ya tengamos el sistema­­, es decir: los ejecutables necesarios, los scripts de despliegue, el modelo de salud de nuestro sistema y todos los artefactos que requerimos hoy en día y que hacemos de forma manual? Esto sería fantástico, pero como sabemos, esta tarea no es tan simple, pues para poder llegar a ese nivel de sofisticación se requiere, en muchas ocasiones, de un esfuerzo muy grande y de un nivel de madurez importante en cuanto al uso de buenas prácticas y arquitecturas se refiere.

Si bien el esfuerzo es bastante grande a la hora de desarrollar una herramienta DSM, dependiendo del dominio del problema a resolver, la idea no es descabellada. Para ello deberíamos contar con tres elementos fundamentales, como son: un lenguaje específico de dominio y su editor, un generador de código y una arquitectura de referencia específica. Si bien estos tres elementos son necesarios, en ocasiones llegar a niveles de generación de código automático de todo nuestro sistema es bastante complejo y costoso, por lo que debemos dejar espacio para la intervención de programadores que completen los elementos que no son generados por las herramientas. Por lo tanto, en estas ocasiones, debemos incorporar herramientas de verificación de modelos que permitan garantizar que aquella funcionalidad que no ha sido generada de forma automática siga cumpliendo con los requisitos definidos en nuestro modelo del sistema.

Esta última práctica es mucho más factible que poder llegar a desarrollar una herramienta DSM completa, ya que ofrece la posibilidad de dejar al desarrollador que cree los componentes o lógica de negocio necesarios, que son muy costosos de generar de forma automática. Eso sí, en estos casos cobran vital importancia los verificadores de modelo, ya que deben garantizar que se cumplan las especificaciones recogidas en nuestro modelo del sistema.

Veamos con un ejemplo los conceptos que anteriormente hemos explicado. Supongamos que nuestro modelo especifica que el sistema deberá implementar un servicio web que, a su vez, deberá realizar un acceso a una base de datos y notificar ciertas condiciones de performance, como se ilustra en la siguiente figura.

clip_image002[8]

Fig. Modelo del Sistema

En este ejemplo nuestra herramienta de DSM podría generar de forma automática los siguientes artefactos: esqueleto de la solución o proyecto, API de acceso a datos, API para el incremento de los contadores de performance, scripts de despliegue, paquetes de salud del sistema, entre otros y dejar que el desarrollador implemente la lógica de negocios del servicio web. Por otra parte, nuestra herramienta debería poder verificar que en la implementación que ha hecho el desarrollador se estén invocando de forma correcta las APIs antes generadas de forma automática.

En Resumen, el uso de estas técnicas de desarrollo de soluciones basadas en modelos específicos de dominio nos permite alcanzar un grado de sofisticación importante en el desarrollo de aplicaciones garantizando una alta calidad y una considerable disminución en los tiempos de desarrollo.

En próximos posts estaremos abundando, mediante un ejemplo concreto de DSM, como resolver la problemática de integración de sistemas usando Biztalk Server. En este ejemplo explicaremos cómo dimos solución a las principales dificultades que nos encontramos y cómo utilizando herramientas aisladas existentes pudimos conjugarlas para obtener el resultado deseado.

Leave a Comment
  • Please add 4 and 2 and type the answer here:
  • Post
  • (Excuse my lack of Spanish!)

    Nice to see you blogging on this topic, Mario!

    Looking at Figure 1, I wonder how things would look if you built several systems like this - Figures 2, 3 etc. That is often a good way to see how to develop the language further. You will often find that some elements repeat in most or all such models, or the information they hold could be figured out from the context, and in that case you can probably change your language to omit those items - at least for the default cases. This is similar to the principle of "convention over configuration", as found in Ruby on Rails.

    In your language the IIS, OrdersWS, OrdersDB and SQLServer objects might all be candidates for that. The main information content of the model would be "Orders" (the name of the DB, from which we will also form the name of the WS), "Order Processed" and "Orders x Sec". Unless you say otherwise in the model, your generators will assume the IIS, SQL Server and other information currently in the model. You can thus model at least the common cases a lot faster - 1 object rather than 6 objects and 5 relationships.

    Obviously we would need more information about the actual domain and process to make the final decision, but I thought it might be a useful pointer for you for further development. There's also an article based on the collected experiences from 76 DSM cases: http://www.metacase.com/papers/WorstPracticesForDomain-SpecificModeling.html, and of course http://DSMbook.com/.

    All the best, and keep posting!

    Steve

  • Hi Steve,

    I agree with your comments and that is a feature that we will introduce depending of the final user feedback. In this particular case we are modeling an very complex EAI scenario where the defaults values are hidden for us. We are planning to delivery our first release very soon and we expect to have feedback in order to introduce new changes like this one that your are proposing.

    In next posts I'll be explaing the complete system (by parts) so you can get more detailed  information about the system and the desicions that we take. Of course your feeback always is welcome and I´ll try to write my next post in english so you can understand what I´m trying to say.

    Best regards, and many thank's for your comments

    marior

Page 1 of 1 (2 items)