¿Herramientas (mejores prácticas?) Para el desarrollo dirigido por modelos?

Question

Desarrollo de software basado en modelos.

Según tengo entendido, aumenta el nivel de abstracción del diseño para reflejar mejor el dominio en el que el software intentará ejecutarse. Eso es mucho decir en una sola oración.

La comunicación entre los expertos de dominio (cliente) y los desarrolladores es crucial para que esta metodología funcione. Lo que quiero saber es si hay un conjunto de herramientas o un conjunto de mejores prácticas que ayudarán en el impulso inicial de MDSD. Una vez que se desarrolla el dominio, ¿qué pasa con el mapeo de ese modelo a un ORM (o lo que sea)?

Me estoy sumergiendo en el ámbito de MDSD y DSL, por lo que cualquier idea constructiva o comentario será apreciado.

Answer 1

Si está desarrollando en plataformas Microsoft, es posible que también desee visitar Oslo. Aquí hay una buena descripción general: http: // www.pluralsight.com/community/blogs/aaron/archive/2008/11/03/introducing-quot-oslo-quot.aspx

Aquí hay un montón de enlaces de Chris Sells: http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic= 2197

Todavía no estoy preparado para equiparar el diseño impulsado por dominio con el desarrollo de unidades modelo.

También es posible que desee consultar la Arquitectura controlada por modelo (OMG MDA) para obtener una perspectiva, aunque probablemente no tenga mucho que ver con la suya.

Un gran problema en Model-driven-anything tiene que ver con el origen de la experiencia que deriva las implementaciones de los modelos y en qué nivel de mantenimiento (y depuración) suceden. Mi prueba de los libros disponibles sería cómo hacen que la tubería sea comprensible y qué tan bien uno puede comprender el camino desde el modelado hasta la implementación y viceversa.

Answer 2

si está programando en .net, debería leer "Aplicación de patrones y diseños controlados por dominio". por Jimmy Nielsson. También tiene una sección sobre ORM (NHibernate), SOA e inyección de dependencia.

En cualquier caso, debería echar un vistazo a "Diseño impulsado por dominio" por Eric Evans. Es un clásico donde puede encontrar información invaluable sobre patrones y mejores prácticas para el diseño impulsado por dominio

Answer 3

Descargo de responsabilidad: soy desarrollador de aplicaciones comerciales. La siguiente visión ciertamente está conformada por mis experiencias en trincheras de TI empresarial. Soy consciente de que hay otros dominios de desarrollo de software. Especialmente en el desarrollo de sistemas industriales y / o integrados, el mundo podría verse diferente.

Creo que MDSD todavía está demasiado vinculado a la generación de código.

La generación de código solo es útil cuando su código contiene mucho ruido y / o es muy repetitivo. En otras palabras, cuando su código no puede enfocarse principalmente en la complejidad esencial, sino que está contaminado con una complejidad accidental.

En mi opinión, la tendencia en las plataformas y marcos actuales es exactamente eliminar la complejidad accidental y dejar que el código de la aplicación se centre en la complejidad esencial.

Entonces, estas nuevas plataformas / frameworks quitan mucho viento de las velas del movimiento MDSD.

Las DSL (textuales) son otra tendencia que intenta habilitar el enfoque único en la complejidad esencial. Si bien los DSL pueden usarse como fuente para la generación de código, no están principalmente vinculados a la generación de código. Los DSL (especialmente los DSL internos) básicamente lo dejan abierto para ser interpretado / ejecutado en tiempo de ejecución. [la generación de código de tiempo de ejecución está en algún punto intermedio].

Entonces, incluso si las DSL a menudo se mencionan junto con MDSD, creo que realmente son una alternativa a MDSD. Y dada la exageración actual, también toman el impulso del movimiento MDSD.

Si ha alcanzado el objetivo de eliminar en última instancia la complejidad accidental de su código (sé que esto es ficticio), ha llegado a un modelo textual de su problema comercial. ¡Esto no se puede simplificar aún más!

¡Los bonitos cuadros y diagramas no ofrecen otra simplificación o elevación del nivel de abstracción! Pueden ser buenos para la visualización, pero incluso eso es cuestionable. ¡Una imagen no siempre es la mejor representación para comprender la complejidad!

Además, el estado actual de las herramientas involucradas en MDSD agrega otro nivel de complejidad accidental (piense: sincronización, diferenciación / fusión, refactorización ...) que básicamente anula el objetivo final de la simplificación.

Mire el siguiente modelo de ActiveRecord, como una ilustración de mi teoría:

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

No creo que esto pueda simplificarse más. Además, cualquier representación gráfica con cuadros y líneas no sería una simplificación y no ofrecería más comodidad (piense en el diseño, la refactorización, la búsqueda, la diferencia ...).

Answer 4

MDD puede ser realmente complejo o relativamente simple.

Si desea automatizar la transformación de sus diversos modelos (en UML, por ejemplo) para codificar y realizar ingeniería de ida y vuelta y todo eso, puede obtener algunas herramientas bastante sofisticadas.

O

Puede dibujar los modelos y construir el código más o menos a mano, utilizando una transformación unidireccional (modelo a código).

La idea de construir un modelo primero es una mejor práctica bien establecida. A menudo se llama "diseño". Los problemas surgen cuando las personas combinan diseño con especificación. El modelo de lo que se construirá no es una especificación de programación. Es una abstracción que se puede usar para evaluar la corrección, definir casos de prueba, escribir especificaciones, etc.

No tienes que modelar todo. Puede iniciar MDD teniendo un modelo de datos, independiente de cualquier implementación específica.

1. Dibujas tu modelo usando UML.

2. Transforma el UML en definiciones de clase.

3. Utiliza una capa ORM (u ODBMS) para asignar sus modelos a algún tipo de almacenamiento.

No necesitas mucho más que esto. Lo que debe hacer es concentrarse en obtener el modelo justo antes de abordar otros problemas.

Los problemas generalmente surgen de todo tipo de optimización prematura que ocurre durante el desarrollo de software. Saltos tempranos en el diseño físico RDBMS. Saltos tempranos en el diseño de la página web y su uso para impulsar el modelo de datos. Saltos tempranos para definir la arquitectura del servidor y asignar almacenamiento.

Answer 5

Debe leer este excelente artículo sobre las mejores prácticas de MDSD, de Markus Voelter: http: //www.jot.fm/issues/issue_2009_09/column6.pdf

Con respecto a la opción MDSD / DSL, el ecosistema EMF ( https://www.eclipse.org / modeling / emf / ) proporciona muchos bloques de construcción útiles:

• implementar metamodelos y editores de modelos (EMF)
• implementa editores de modelos (EMF, Sirius, Xtext ...)
• gestionar la colaboración y la escalabilidad (EMF-Transaction, CDO)
• implementar reglas de validación del modelo (Validación EMF)
• implementar generadores de código (Acceleo, Xtend / Xpand, Mwe ...)
• implementar generadores de documentos (pxDoc, m2doc ...)

Una opción interesante para reducir la inversión en herramientas también puede ser el uso de un modelador UML extensible, y definir sus propios perfiles UML y herramientas personalizadas sobre el modelador reutilizado (la lista anterior sigue siendo adecuada si su modelador UML está basado en la implementación de UML2 / EMF).