¿Cuáles son los beneficios de modelar sistemas de software frente a hacerlo todo en código?

20

La mayoría, si no todas las personas de TI que conozco, creen que es beneficioso modelar software con UML u otros tipos de diagramas antes de la codificación. (Mi pregunta no es sobre UML específicamente, podría ser cualquier descripción gráfica o textual del diseño del software).

No estoy tan seguro de eso. La razón principal es: el código no miente. Lo comprueba el compilador o el intérprete. Con suerte, tiene pruebas automatizadas y necesita pasar el análisis de código estático. Si un módulo no interactúa correctamente con otro módulo, generalmente es obvio en el código porque recibe un mensaje de error.

Todo esto no se puede hacer con diagramas y otros documentos. Sí, hay herramientas que comprueban UML, pero todo lo que he visto hasta ahora es muy limitado. Por lo tanto, estos documentos tienden a ser incompletos, inconsistentes o simplemente falsos.

Incluso si los diagramas en sí son consistentes, no puede estar seguro de que el código realmente los implemente. Sí, hay generadores de código, pero nunca generan todo el código.

A veces siento que la obsesión con el modelado resulta de la suposición de que el código inevitablemente tiene que ser un desastre incomprensible con el que los arquitectos, diseñadores u otras personas bien remuneradas que tienen una visión general no deberían tener que lidiar. De lo contrario, sería demasiado caro. Por lo tanto, todas las decisiones de diseño deben alejarse del código. El código en sí debe dejarse a especialistas (monos de código) que pueden escribirlo (y tal vez leerlo) pero no tienen que ocuparse de nada más. Esto probablemente tenía sentido cuando el ensamblador era la única opción, pero los lenguajes modernos le permiten codificar a un nivel muy alto de abstracción. Por lo tanto, ya no veo la necesidad de modelar.

¿Qué argumentos para modelar sistemas de software me estoy perdiendo?

Por cierto, creo que los diagramas son una excelente manera de documentar y comunicar ciertos aspectos del diseño de software, pero eso no significa que debamos basar el diseño de software en ellos.

Aclaración:

La pregunta quedó en suspenso por no estar clara. Por lo tanto, permítanme agregar alguna explicación:

Me pregunto si tiene sentido usar documentos (sin código) que modelen el software como la fuente principal de verdad sobre el diseño de software. No tengo en cuenta el caso en el que una parte significativa del código se genera automáticamente a partir de estos documentos. Si este fuera el caso, consideraría los documentos en sí mismos como código fuente y no como modelo.

Enumeré algunas desventajas de este procedimiento que me hacen preguntarme por qué tanta gente (en mi experiencia) lo considera como la forma preferible de hacer diseño de software.

Frank Puffer
fuente
55
Creo que es una pregunta completamente válida. Si nuestro modelo tiene algún valor, debe coincidir con el código. Entonces, ¿por qué no diseñar el modelo en el mismo lenguaje que luego usaremos para implementarlo? Entonces siempre están sincronizados. Y si prefiere gráficos elegantes, se pueden generar a partir del código.
Ralf Kleberhoff
3
Debería conocer más personas de "TI" entonces. O tal vez debería decir, debería familiarizarse con más comunidades dentro de ese paraguas.
Derek Elkins
@DocBrown: Si bien las respuestas a esa pregunta y especialmente los artículos vinculados en su comentario proporcionan información relevante, la pregunta original es muy diferente.
Frank Puffer
@FrankPuffer: Soy consciente de eso, voté para reabrir. Sin embargo, creo que el núcleo de su pregunta: "qué es el diseño de software" y "el papel del modelado en el diseño de software", es una pregunta muy amplia, tal vez demasiado amplia para responderla aquí de manera sensata.
Doc Brown

Respuestas:

23

El beneficio de los sistemas de software de modelado en comparación con todo en código es: puedo adaptar el modelo a una pizarra.

Soy un gran creyente en la magia de comunicarse en una hoja de papel. Si traté de poner código en la pizarra, cuando enseño nuestro sistema a nuevos codificadores, simplemente no hay ningún código en el nivel de abstracción necesario que encaje en una pizarra.

Conozco la obsesión con el modelaje a la que te refieres. Las personas hacen cosas porque así es como se han hecho antes, sin pensar por qué lo están haciendo. He venido a llamarlo formalismo. Prefiero trabajar informalmente porque es más difícil ocultar tonterías detrás de la tradición.

Eso no significa que no sacaré un boceto UML de vez en cuando. Pero nunca seré el tipo que te exige que entregues un documento UML antes de que puedas codificar. Podría requerir que te tomes 5 minutos y encuentres ALGUNAS formas de explicar lo que estás haciendo porque no puedo soportar la existencia de código que solo una persona entiende.

Fowler identificó diferentes formas en que las personas usan UML que llamó modos UML . Lo peligroso de todos ellos es que pueden usarse para esconderse de hacer un trabajo útil. Si lo está haciendo para codificar con el mouse, bueno, he visto muchos intentos. No he visto a nadie hacer que eso realmente funcione. Si lo haces para comunicarte, será mejor que te asegures de que otros te entiendan. Si lo hace para diseñar, es mejor que encuentre y solucione problemas mientras trabaja. Si todo va bien y se pasa la mayor parte del tiempo haciendo que las flechas se vean bien, déjelo y vuelva al trabajo.

Lo más importante, no produzca diagramas que espere que sean válidos más de un día. Si de alguna manera puedes, has fallado. Porque el software está destinado a ser suave. No pase semanas obteniendo los diagramas a la perfección. Solo dime qué está pasando. Si es necesario, usa una servilleta.

Dicho esto, prefiero codificadores que conozcan su UML y sus patrones de diseño. Son más fáciles de comunicarse. Siempre y cuando sepan que producir diagramas no es un trabajo a tiempo completo.

naranja confitada
fuente
2
"simplemente no hay ningún código en ese nivel de abstracción que encaje en una pizarra" Eso plantea una pregunta interesante. Por qué no? ¿Qué debería ser cierto para que el punto de entrada de un sistema explique a un nivel muy alto lo que hace?
RubberDuck
2
Porque el código debe ser todo para todas las personas (y al menos un compilador). Un modelo puede tener una audiencia enfocada.
candied_orange
Creo que usar la palabra "formalismo" para esto es lamentable. O sobreinfla lo que están haciendo los "modeladores" o degrada el modelado formal real . (Tampoco parece captar realmente su intención de lo que puedo decir aquí. Su preocupación no parece ser el modelado en sí, sino usarlo como una puerta o por razones burocráticas, incluso cuando no está agregando valor).
Derek Elkins
3
Mi problema no es con el modelado. Es con el uso de ceremonias formales como un reemplazo para el pensamiento crítico. Estoy tratando de decir que gran parte de la matanza de modelos ocurre porque gran parte del modelado cayó con esa multitud. El modelado puede ser muy bueno. Pero tiene un lado oscuro.
candied_orange
1
"Puedo ajustar el modelo en una pizarra" es una forma muy concreta (¡excelente!) De decir "Puedo hacer una abstracción de algo que es más complicado para ayudar a comprender o comunicar el aspecto que siento que es importante". Esto es lo que hace un buen modelado en general, ya sea software o cualquier otra cosa compleja.
Fuhrmanator
6

Me pregunto si tiene sentido usar documentos (sin código) que modelen el software como la fuente principal de verdad sobre el diseño de software.

No. Esto nunca tiene sentido. Su código es su documento de diseño principal, es decir, "la fuente principal de verdad sobre el diseño de software". Solo el código describe exactamente lo que hace la aplicación cuando el compilador toma ese diseño y crea la aplicación a partir de él.

Por supuesto, use diagramas como documentos de diseño complementarios, aunque si no se generan automáticamente a partir del código, tenga cuidado de que cuenten una historia diferente al diseño real. Si UML flota su bote, úselo. Si no, usa otra cosa.

Algunas personas encuentran útil esbozar su pensamiento en forma de diagrama antes de comenzar a escribir código. Pero recuerda lo que dijo el tío Bob sobre este asunto:

" Entonces, sí, los diagramas pueden ser inapropiados a veces. ¿Cuándo son inapropiados? Cuando los creas sin código para validarlos y luego intentas seguirlos. No hay nada de malo en dibujar un diagrama para explorar una idea " .

Si usa UML para explorar un diseño, deséchelo cuando comience a codificar. Escriba una prueba, luego escriba un código para que pase. Repetir. De esa manera, terminarás con un diseño validado. UML nunca puede ofrecerle el mismo nivel de validación de su diseño.

David Arno
fuente
Un ejemplo contador (?) :: separación modelo-vista (o cualquier patrón GoF) puede ser fácilmente dibujado como una intención verdad de diseño (anteproyecto) propuesto por un arquitecto. Los desarrolladores que se desvían de esa intención no vuelven inútil el modelo (previsto). Sí, el código es la "verdad" pero no es necesariamente el diseño. La validación no tiene que ser automática con UML o algún modelo. El hecho de que no lo sea no hace que un modelo sea digno de basura.
Fuhrmanator
En cuanto a las pruebas, no estoy seguro de que sea útil validar un diseño. ¿Puede escribir pruebas que muestren que la lógica de dominio no está en la capa de presentación (un problema muy común con implementaciones que se desvían de un diseño previsto)? Mostrar un diagrama de las capas a un desarrollador y explicarle que un actionPerformed()método está en la capa de presentación, y que simplemente debería pasar el control a la capa de dominio, es un aspecto clave de la separación. (Ejemplo trivial, pero se puede aplicar a todo tipo de estrategias de diseño que no son fáciles de mostrar solo en código).
Fuhrmanator
5

La mayoría, si no todas las personas de TI que conozco, creen que es beneficioso modelar software con UML u otros tipos de diagramas antes de la codificación.

No estoy en desacuerdo con que todas las personas que conoces crean esto, pero no creo que sea necesariamente común en todos los ámbitos. En 1970, Winston Royce sabía que el desarrollo de software tenía cierto nivel de iteración entre las actividades de diseño y código. En 1992, Jack Reeves escribió sobre la codificación como la verdadera actividad de diseño (también discutida en el Wiki de C2 ).

Esto no significa que las personas hayan intentado crear herramientas de desarrollo basadas en modelos. Existen herramientas que intentan generar código a partir de modelos UML (y no solo diagramas de clases, sino que vinculan varios tipos de diagramas y generan código a partir de ellos). Pero esas no son, al menos por lo que he visto, herramientas ampliamente utilizadas.

Esto tampoco significa que deba pasar directamente de los requisitos al código escrito. Hay ciertas decisiones de diseño que son críticas para acertar temprano y cierto nivel de modelado puede ser útil para asegurarse de que todos entiendan las opciones, su impacto y puedan comunicarse. Algunas personas (incluido yo mismo) llaman a esto la "arquitectura de software" .

El código no miente. Lo comprueba el compilador o el intérprete. Con suerte, tiene pruebas automatizadas y necesita pasar el análisis de código estático. Si un módulo no interactúa correctamente con otro módulo, generalmente es obvio en el código porque recibe un mensaje de error.

Este es realmente el corazón de algunos de los aspectos del modelado ágil, especialmente las especificaciones ejecutables y la fuente única de información . No estoy necesariamente de acuerdo con TDD, pero la idea de que su código y las pruebas asociadas (desde la unidad hasta las pruebas de aceptación, preferiblemente capturadas como pruebas automatizadas) sea la única fuente de verdad es una buena idea.

Incluso si los diagramas en sí son consistentes, no puede estar seguro de que el código realmente los implemente. Sí, hay generadores de código, pero nunca generan todo el código.

Creo que, como regla general, pasar de modelo a código es el camino equivocado. En cambio, el código debería generar modelos. Es decir, las herramientas deberían poder examinar el código y generar representaciones gráficas y tabulares que se puedan mejorar aún más a medida que los ingenieros escriben texto a su alrededor. Y esta generación de modelos a partir del código debería ser una parte perfecta de un proceso de compilación y lanzamiento.

Existen herramientas que, en diversos grados, admiten esto para varios idiomas. Dada la naturaleza de los lenguajes y paradigmas, es más fácil para algunos que para otros.

Enumeré algunas desventajas de este procedimiento que me hacen preguntarme por qué tanta gente (en mi experiencia) lo considera como la forma preferible de hacer diseño de software.

No creo que estas personas comprendan necesariamente la ingeniería y el diseño de software. Creo que estas personas están mirando lo que hacen otras disciplinas de ingeniería y asignándolas a cosas que creen que los ingenieros de software deberían hacer. Pero están ignorando una gran diferencia. Otras disciplinas de ingeniería crean modelos y simulaciones primero porque es extremadamente costoso y requiere mucho tiempo construir el producto real. En ingeniería de software, podemos tomar partes de nuestro diseño y producir algo que sea comprobable en un entorno del mundo real en muy poco tiempo y con muy poco costo. La economía es muy diferente.

¿Cuáles son los beneficios de modelar sistemas de software frente a hacerlo todo en código?

Cuando tienes un sistema de software extremadamente complejo, tener modelos significa tener algo que es más fácil de entender. Es un nivel diferente de abstracción, algo para ayudar a las personas a comprender varias facetas de su sistema. Es una de las razones por las que hay tantos lenguajes de modelado diferentes y diferentes tipos de modelos permitidos por cada lenguaje o notación de modelado, para permitir que diferentes partes interesadas entiendan, conceptualmente, el sistema de software de manera rápida y fácil.

Thomas Owens
fuente
5

Me pregunto si tiene sentido usar documentos (sin código) que modelen el software como la fuente principal de verdad sobre el diseño de software. No tengo en cuenta el caso en el que una parte significativa del código se genera automáticamente a partir de estos documentos. Si este fuera el caso, consideraría los documentos en sí mismos como código fuente y no como modelo.

Muchos documentos sin código son útiles como planos . Es decir, la "verdad" del diseño debe seguir esta dirección. Es una forma de modelar elementos que un diseño debe cumplir. Podría llamarlos documentos de requisitos, pero tal vez sea demasiado fuerte en todos los ejemplos que podría dar. He usado PlantUML a través de PlantText.com para producir estos.

  • Los diagramas de casos de uso pueden mostrar las características e interacciones previstas con usuarios o sistemas externos. ingrese la descripción de la imagen aquí

  • Los diagramas de actividad pueden mostrar procesos de negocio que un software necesita soportar. ingrese la descripción de la imagen aquí

  • Los diagramas de estado podrían mostrar la dinámica prevista en un sitio web: ingrese la descripción de la imagen aquí

  • Los patrones de diseño de Gang of Four se presentan como modelos estáticos y dinámicos. Por ejemplo, Memento:
    ingrese la descripción de la imagen aquí
    ingrese la descripción de la imagen aquí

Enumeré algunas desventajas de este procedimiento que me hacen preguntarme por qué tanta gente (en mi experiencia) lo considera como la forma preferible de hacer diseño de software.

Si está interesado en alguna información real sobre el uso de UML fuera de su experiencia, hay algunos estudios que se realizaron (intenté encontrar enlaces a artículos que no son de Paywall):

Fuhrmanator
fuente
0

A los desarrolladores nos encanta usar imágenes para explicar nuestro mundo, así que aquí hay uno con la producción de un automóvil:

  • El automóvil es el resultado de la cadena de producción, lo mismo para el código (agregue el proceso de implementación, por supuesto).
  • El documento de diseño del automóvil es el mismo que el documento de diseño del software.

En nuestros mundos, a menudo sucede que aquellos que conciben y crean el documento de diseño son los mismos que producen el código. Eso no es cierto en los otros campos. Sin embargo, eso no significa que realmente pueda obtener el mismo nivel de calidad al hacerlos todos juntos.

Al hacer esos documentos primero sin codificar (excluyendo cualquier cosa como una prueba de concepto para la facilidad de uso, ...):

  • Seguro que pensará antes de hacerlo, la codificación una vez que sepa lo que tiene que hacer es FÁCIL.
  • Puede enfocar a las personas más experimentadas en la parte más difícil de su software: el diseño, el algoritmo / matemática es cualquiera, excepto para un propósito muy específico (incrustado, en tiempo real, ensamblaje).
  • Puede delegar a las personas menos experimentadas una buena parte del proceso de codificación, mientras que las personas más experimentadas solo se centran en la parte más crítica que necesita el nivel de su habilidad. Esas personas menos experimentadas aprenderán mucho sobre eso.
  • Puede discutir con personas que no son de TI a través de la imagen de su documento de diseño, mientras que si solo tuviera código, tendría que extraer una imagen de lo que hizo, con todo el riesgo de olvidar algo (un oyente olvidado en alguna parte ...). Consulte la respuesta de CandiedOrange para obtener más información sobre la comunicación.
  • Cuando tiene que hacer que su software evolucione, puede anticipar mejor cuál será el impacto.
  • El diseño facilitará la eliminación de parte de su software y el desarrollo simultáneo de parte de su software.
  • Escribir esas malditas pruebas de unidad reberbativa será mucho más fácil cuando no tenga que preocuparse por tener que cubrir todos los casos mientras los codifica, en un enfoque TDD que codifica la prueba antes de que el código sea fácil.
  • ...

Nota: esas afirmaciones suponen que el código es realmente el reflejo del diseño y ambos se mantienen actualizados ...

Walfrat
fuente
Esta respuesta describe un escenario cercano al mejor de los casos. Mencionas una advertencia al final que es bastante grande en sí misma. Hay muchos otros Puede omitir fácilmente los aspectos necesarios, subestimar la complejidad de alguna parte, no tener en cuenta las restricciones que imponen las bibliotecas / marcos que usa, no tener en cuenta los errores en las dependencias, no tener en cuenta el rendimiento u otros requisitos no funcionales, más que el ingeniero, no anticipar los cambios, o simplemente no es tan bueno en el diseño. Es poco probable que este mejor de los casos se materialice incluso en un contexto profesional.
Derek Elkins
Si comienzas considerando solo cada advertencia de todo, no irás a ningún lado. Cualquier método que uses. Y una larga lista de lo que dijiste es perfectamente válida cuando solo haces código.
Walfrat