2010-04-23 9 views
5

Trabajo para una empresa con aproximadamente 350 empleados y estamos en el proceso de crecimiento. Nuestra base de código actual no está estructurada muy bien y buscamos cómo mejorarla inmediatamente (organizando objetos en espacios de nombres, separar preocupaciones, etc.) y pasar a un enfoque de arquitectura basado en modelos, donde modelamos y diseñamos todo primero con uml , luego genera código de ese modelo. Hemos estado buscando mucho en Sparx Systems Enterprise Architect (EA) (que tiene capacidad para UML 2.0) y también estamos considerando las herramientas en VS 2010. Sé que hay otras herramientas (Rational XDE es una) pero realmente no Creo que podemos gastar $ 1500 + por licencia en este punto.¿Cuáles son los beneficios y riesgos de pasar a un enfoque de Arquitectura dirigida por modelo?

No estoy buscando respuestas sobre qué herramienta es mejor que otra, sino más para experiencias que cambian de un entorno de codificación cowboy (es decir, poca planificación y diseño, solo salto y comienzo de codificación) a una arquitectura basada en modelos. Mirando hacia atrás, ¿fue útil para su organización? ¿Cuáles son los puntos de dolor? ¿Cuáles son los riesgos? ¿Cuales son los beneficios?

+0

¿No es el mayor riesgo que se equivoque con su modelo? Lo más probable es que solo se dé cuenta en un 90% a través de su proyecto de que su modelo estaba equivocado. – Gabe

Respuesta

2

Nuestra base de código actual no está estructurado muy bien y estamos buscando tanto en cómo mejorar inmediatamente [...] y pasar a un enfoque de arquitectura basado en modelo , donde modelamos y diseñamos todo primero con uml, y generamos el código de ese modelo.

En primer lugar, es muy bueno que usted y su empresa se da cuenta de que hay algunas deficiencias en el proceso de desarrollo de software y de que hay una voluntad de mejorar .

Parece que hay mucho trabajo por delante y muchas cosas que mejorar en diferentes direcciones. Mi primer consejo sería no intentar cambiar todo a la vez. En general, las personas son reacias a los cambios y todos necesitan algún tiempo para digerir nuevos cambios. También es muy importante crear un entendimiento común sobre lo que se debe configurar. Esta comprensión común no se creará en un día. Tal cambio requiere un compromiso de medio o largo plazo .

Luego, con respecto a MDA, es importante tener en cuenta que requiere un poco de disciplina. Dependiendo de su equipo, la primera parte podría trabajar en eso primero de una manera para preparar el siguiente paso, que sería introducir MDA. Lo digo porque dices que tienes un proceso de "cowboy", lo que significa que las personas probablemente estén acostumbradas a hacer lo que quieran, es un no-go para MDA.

Luego viene la introducción de MDA. Hay varias formas de hacer MDA (y no ampliaré aquí), pero la forma predominante de hacerlo es la llamada ingeniería de ida y vuelta. El mayor problema entonces es mantener el modelo y la fuente sincronizados.

(Mi opinión es que MDA conduce a un retorno de la inversión positivo solo si el modelo se puede reutilizar para varios proyectos. Esto significa que debe haber identificado las cosas que hace una y otra vez, y tener una visión clara suficiente sobre el problema para poder crear un modelo suficientemente completo y transformaciones que pueda reutilizar a lo largo del proyecto. No creo que MDA funcione si cada proyecto es completamente diferente, el tiempo invertido para obtener el modelo correcto y la transformación, etc. será más grande que trabajar solo con código y documentación.)

Otro enfoque es no hacer MDA por completo, no se genera código del modelo, sino aumentar la conciencia de las personas sobre el problema de diseño y modelado, p.ej con UML. De esta forma, no tendrá problemas de ida y vuelta pero aún así mejorará la madurez de su proceso de desarrollo de software.

+0

Este es un buen consejo, que esencialmente no hay una sola manera correcta de hacer esto. No veo que nos cambiemos a la MDA en su forma purista desde el principio, esta será una adquisición lenta y gradual de todas las partes. Incluso si todos estuvieran listos para subir a bordo hoy, todavía hay una curva de aprendizaje bastante amplia. – Tone

4

Lo hicimos una vez con un sistema de planificador de logística de 3 mloc, y funcionó bien. Sin embargo, nos dimos cuenta desde el principio que UML no sería suficiente. Simplemente era demasiado obtuso capturar el nivel de detalle necesario para la especificación. La mejor manera era utilizar un pseudocódigo (¡todos lo usaban de todos modos para comunicar ideas)! Así es como se realizó la realización. Usar UML se sintió como un paso más allá de la claridad.

Cuando las ideas comenzaron a reducirse a una solución, se utilizó un sistema de control de versiones para rastrear los cambios del pseudocódigo (y casos de uso, etc.). Entonces, todos en el grupo siguieron los cambios. Poco a poco, las partes se tradujeron en códigos reales junto con documentación y referencias a motivaciones y discusiones.

Al final, la transición del modelo al código fue muy suave. La parte realmente buena fue, en mi humilde opinión, el uso de vcs que te permitía ver incluso el pseudocódigo original sin cambiar el entorno.

+0

Solo quiero sugerir que lo que describió es exactamente de lo que se tratan los lenguajes específicos de los dominios externos y usar herramientas como Eclipse TMF Xtext o Jebtrains MPS podría ayudar bastante. –

2

Escribí mi tesis de licenciatura sobre Model Driven Software Development y solo quiero advertirle que es realmente importante utilizar un buen enfoque para hacer lo que su empresa pretende. Hay muchas cosas que pueden salir mal, como p. editar el código generado directamente, pudiendo generar solo una vez, ya que el código editado manualmente se borrará después de la generación, tienes que hacer un análisis de dominio para crear un buen metamodelo y usar un buen marco de generación de código ... Por favor, no me entiendas mal, creo que MDSD es genial, pero solo ten cuidado de cómo lo harás. La MDA original y los libros sobre ella sugieren aplicaciones realmente malas, que son demasiado costosas y frágiles. Le sugiero que busque en el sitio web voelter.de, donde puede encontrar documentos, presentaciones y podcasts de Markus Voelter, que es un consultor con mucha experiencia en esa área.

+0

El sitio web al que hace referencia parece tener muy buena información. También encontré este podcast de ese sitio que parece tener un gran contenido en torno a MDA y MDSD. http://www.se-radio.net/ – Tone

+0

Sí, es realmente un gran podcast. También puede consultar esos episodios desde diferentes podcasts: http://www.heise.de/developer/artikel/Episode-10-Modellierung-im-Softwarearchitekturumfeld-Teil-1-353335.html http: // www .heise.de/developer/artikel/Episode-11-Modellierung-im-Softwarearchitekturumfeld-Teil-2-353355.html http://www.heise.de/developer/artikel/Episode-20-Architektur-als-Sprache -972531.html http://herdingcode.com/?p=206 Hay mucho más :) –

+1

... Recordé un artículo que encontré con un capítulo entero sobre los desafíos de los enfoques impulsados ​​por modelos: http: // www. vtt.fi/inf/pdf/workingpapers/2009/W114.pdf –

2

Para mí, el aspecto clave es ser pragmático a veces. El modelado no debe ser una actividad booleana (no modelamos o no modelamos). Deberíamos ser capaces de adaptar el nivel/precisión de modelado a las características del proyecto (ver, por ejemplo, lo que hacen las personas que trabajan en modelado ágil) y la empresa. Muy poco o demasiado modelado puede ser problemático (con muy poco puede no ver los beneficios, demasiado puede ser demasiado para su empresa, especialmente si está empezando la transición o no tiene las herramientas necesarias)

En mi portal/blog (http://modeling-languages.com) a menudo discutimos sobre los beneficios del modelado o cómo se debe usar el modelado. Puede que le resulte interesante

+0

Ciertamente estoy de acuerdo con sus declaraciones. Gracias por el enlace! – Tone

Cuestiones relacionadas