Estoy realmente interesado en escuchar lo que piensas sobre el desarrollo de software basado en modelos para Java y/o .NET.¿Qué opinas sobre Desarrollo de software impulsado por modelos?
¿Ahorra tiempo? ¿Mejora la calidad?
Estoy utilizando MDSD en un proyecto con IBM Rational Rhapsody para C++. El modelo está muy cerca de UML, por lo que realmente no tenemos un dominio específico de idioma. Pero aún reclamo usar MDSD. Desde mi experiencia, hay muchos beneficios con MDSD:
a) El uso de MDSD ayuda a llevar una arquitectura SW a un nivel sofisticado. Siempre trabajas en un nivel muy abstracto, pensando en el panorama general. El software de codificación Cowboy generalmente carece de una buena arquitectura, porque un desarrollador está atascado en los detalles. Con MDSD, veo una tendencia en mi trabajo a resolver problemas con clases de tamaño adecuado, patrones agradables o simplemente un mejor código.
b) La documentación general del SW tiende a ser mejor con MDSD. Por supuesto, hay herramientas que generan automáticamente un diagrama de clases de tu código. Pero estos diagramas constan de 1000 clases y no se ve el aspecto de interés. Con MDSD, usted dibuja específicamente un aspecto del sistema, y el mismo diagrama también se usa para generar una parte de su código.
c) El modelado ayuda a manejar una complejidad inherente del sistema. Yo diría que algunos sistemas son demasiado complejos para ser construidos sin el apoyo de un diseño asistido por computadora. Nadie diseñaría una CPU sin la ayuda de enormes herramientas de SW. Use SW para ayudarlo a escribir SW aún más complejo.
d) El uso de MDSD ayuda a cumplir con las pautas de estilo de codificación. No hay mejor manera de obtener un estilo de código coherente que dejar que el código sea generado por un conjunto de reglas.
Por supuesto, también hay algunas desventajas de MDSD: d) Si tiene un modelo, quiere que cada línea de código provenga de ese modelo. Y puede ser difícil incluir bibliotecas externas en un proyecto. Entonces, o vives con el hecho de que tu sistema se basa en componentes externos o reinventa la rueda para incorporarlo a tu modelo.
e) Las herramientas de modelado pueden sufrir problemas al utilizar las herramientas de control de versiones. El código fuente generalmente es más simple de combinar que un diagrama modelo. Esto obliga a un equipo a pasar de copiar-editar-fusionar a un flujo de trabajo lock-edit-merge.
Seguro suena bien, pero todavía no lo he visto implementado de una manera práctica.
Lo sostengo así: El código es el modelo. De esta manera, su modelo y su código estarán siempre actualizados :-)
MDA es un concepto algo sobrecargado. A veces significa convertir UML u otro tipo de diagramas en código ejecutable. Nunca he visto esto funcionar bien con las herramientas disponibles hoy en día. Por lo general, hace que los proyectos obtengan resultados realmente rápidos y luego causa una pesadilla de mantenimiento porque las herramientas disponibles realmente no son compatibles con los grandes equipos que trabajan en diagramas visuales y porque las personas comienzan a trabajar en los diagramas y en el código generado.
que he visto algo que se parecía mucho a Domain Driven Design se conoce como MDA, si usted quiere decir que yo soy todo para él :-)
Bueno MDA no es igual a MDSD. He visto funcionar codegen a gran escala en grandes proyectos. Pero es su propia profesión. Un generador de código es software. La manipulación del código generado está en el mismo nivel que la manipulación de datos en tablas sobre el uso de las API en el software habitual. –
MDA generalmente hace difícil integrar las reglas de negocio en el interior la capa del lado del servidor, ya que el mapeo de la vista del modelo es manejado por el código generado y los ganchos funcionales se proporcionan como respondedores al evento.
Todavía no he visto una herramienta MDA tan poderosa como Forté (o UDS, ahora muerta) + Express. Imagino que una MDA con las capacidades de Forté y un mejor patrón para lograr una capa de servicio independiente (como ActiveRecord, o patrones de EntityTransactionManager) sería una aplicación arrolladora para cualquier plataforma.
El problema con la aplicación real que apunta al enfoque de tres niveles MDA es que son terriblemente difíciles de configurar y adaptar a requisitos específicos. Solo piense en las tasas de ABAP y SAP
Creo que es preferible. Eso es lo que estaba tratando de insinuar en this question sobre MVC-ARS en lugar de MVC. El ARS (Acción/Representación/Estado) está contenido dentro del modelo por diseño e impide la sobrecarga del controlador o la vista.
Solo para incluir dos libros que encontré útiles para comprender MDA como se indicó anteriormente, es un tema amplio.
No es necesario leer todo el Guttman para obtener la idea ya que los estudios de casos aburren, pero la introducción fue agradable de leer.
Buzz.
Lo que creo, OTOH, es el modelado en tiempo de ejecución. En lugar de generar código, mantenga el modelo activo en tiempo de ejecución y permita que su aplicación sea un intérprete en tiempo de ejecución de estos modelos.
No sé si esto se ha hecho para Java. Para Smalltalk, vea Magritte, que se usa en Seaside.
Estoy de acuerdo, esto es muy poderoso y no se ve mucho con los principales lenguajes principales (aunque no hay nada sobre los idiomas que lo impiden). –
Si no tiene miedo de recurrir a objetos hashtable y la búsqueda de método hashtable, estoy de acuerdo. (Sin embargo, los idiomas que le permiten volver a compilar las clases en el tiempo de ejecución hacen la vida mucho más fácil con respecto a eso). – akuhn
Eso también lo hago mucho. Pero es realmente difícil para modelos complejos. Depurar el código generado es más fácil que encontrar un error en su modelo depurando el intérprete. Se trata de herramientas. –
El desarrollo de software impulsado por modelos no se trata solo de MDA, hay una serie de otros enfoques que incluyen, tal vez más popular, el enfoque de idiomas específicos de dominio.
Claro, el código es un modelo 'a', pero capturar un modelo de nivel superior en una DSL es una forma aún más concisa de expresar el mismo intento. La clave es siempre genere su código del modelo en lugar de permitir la modificación independiente del código generado.
Hay muchas herramientas disponibles y abundante material publicado, incluidos estudios de casos, para contarle cómo construir sus propios generadores si no está contento comprando un generador estándar. Podría decirse que esto le da más control que trabajar con un lenguaje de programación de propósito general.
En el espacio del eclipse se usa bastante. Lo he visto tener éxito en grandes proyectos. –