¿Por qué no podemos capturar el diseño de software de manera más efectiva? [cerrado]

Como ingenieros, todos "diseñamos" artefactos (edificios, programas, circuitos, moléculas ...). Esa es una actividad (design-the-verb) que produce algún tipo de resultado (design-the-noun).

Creo que todos estamos de acuerdo en que designar el sustantivo es una entidad diferente al artefacto en sí.

Una actividad clave en el negocio del software (de hecho, en cualquier negocio donde el artefacto del producto resultante necesita ser mejorado) es comprender el "diseño (el sustantivo)". Sin embargo, parece que, como comunidad, tenemos fallas bastante completas al grabarlo, como lo demuestra la cantidad de esfuerzo que las personas ponen en redescubrir hechos sobre su base de código. Pídale a alguien que le muestre el diseño de su código y vea lo que obtiene.

Pienso en un diseño para software que tiene:

• Una especificación explícita de lo que se supone que debe hacer el software y qué tan bien lo hace.
• Una versión explícita del código (esta parte es fácil, todos la tienen)
• Una explicación de cómo cada parte del código sirve para lograr la especificación (por ejemplo, una relación entre fragmentos de especificación y fragmentos de código)
• Una justificación de por qué el código es como es (por ejemplo, por qué una elección particular en lugar de otra)

Lo que NO es un diseño es una perspectiva particular del código. Por ejemplo, [no elegir específicamente] los diagramas UML no son diseños. Más bien, son propiedades que puede derivar del código, o posiblemente, propiedades que desearía poder derivar del código. Pero como regla general, no puede derivar el código de UML.

¿Por qué después de más de 50 años de desarrollo de software, por qué no tenemos formas regulares de expresar esto? (¡No dudes en contradecirme con ejemplos explícitos!)

Incluso si lo hacemos, la mayoría de la comunidad parece estar tan enfocada en obtener "código" que el diseño del sustantivo se pierde de todos modos. (En mi humilde opinión, hasta que el diseño se convierta en el propósito de la ingeniería, con el artefacto extraído del diseño, no vamos a evitar esto).

¿Qué ha visto como medio para grabar diseños (en el sentido que lo he descrito)? Las referencias explícitas a los documentos serían buenas. ¿Por qué crees que los medios específicos y generales no han tenido éxito? ¿Cómo podemos cambiar esto?

[Tengo mis propias ideas que desarrollan el punto de vista con viñetas anterior, pero estoy interesado en las respuestas de otras personas ... y es difícil implementar mi esquema [[y tal vez ese es el verdadero problema: -]]]

EDITAR 2011/1/3: Uno de los hilos de respuesta insinúa que la "documentación" (presumiblemente textual, en particular no formal) podría ser adecuada. Creo que debería aclarar que no creo esto. Las herramientas CASE aparecieron en la escena a partir de los años 80, pero las primeras herramientas en su mayoría solo capturaron píxeles para los diagramas de lo que dibujaste; Si bien las herramientas fueron comercialmente exitosas, realmente no fueron muy útiles. Una idea clave fue que si los artefactos adicionales de "diseño" no son formalmente interpretables, no puede obtener ninguna ayuda seria de la herramienta. Creo que la misma idea se aplica a cualquier forma útil de captura de diseño a largo plazo: si no tiene una estructura formal, no será de ningún uso real. Los documentos de texto prácticamente no pasan esta prueba.

Creo que hay varias razones por las que todavía no somos buenos en esto.

1. Las personas durante mucho tiempo, aunque el software era como las casas, y utilizaban procesos e ideas de la construcción. "Arquitecto de software" era un título que todos los programadores querían. Durante los últimos diez años, el arquitecto de software casi se ha extinguido. La idea de los procesos en cascada donde primero tiene un arquitecto que le dice cómo debería funcionar y verse el software, y luego hacer que la gente haga diagramas de cómo debería construirse y, por último, hacer que Code Monkey implemente estos agradables diagramas de flujo de trabajo / UML para especificar, esta idea es ahora ampliamente ridiculizado. De hecho, toda la industria estuvo tomando el camino equivocado durante 40 años.

2. Las herramientas que utilizamos cambian y mejoran constantemente. La programación es un acertijo lógico, y se nos ocurren mejores ideas y técnicas para abstraer ese acertijo y hacerlo comprensible. La forma en que modelamos esto debe evolucionar a la misma velocidad, pero va a la zaga. Las técnicas mejoradas para abstraer el rompecabezas de la programación también significa que podemos aumentar la complejidad. Y así lo hacemos. La programación siempre se encuentra en los bordes de la complejidad que nosotros, como programadores, podemos manejar.

3. Hacer formas de describir el programa es una especie de abstracción. Si podemos encontrar una buena manera de abstraer el software, también podemos poner esa abstracción directamente en las herramientas de desarrollo y, por lo tanto, agregar otra abstracción / simplificación a la programación. Esto ha sucedido muchas veces. Ejemplos de tales abstracciones son funciones, clases y bibliotecas.

4. Por lo tanto; Si tiene un modelo exitoso y preciso del software, ese modelo será equivalente al software. Lo que hace que todo el esfuerzo no tenga sentido, lo que a su vez corrobora el punto 1 anterior: modelar el software es mucho menos útil de lo que se pensaba anteriormente. En cambio, es mejor extraer datos sobre el software del código. Crear un modelo UML a partir de cómo se ve realmente el código es mucho más esclarecedor que crear un modelo UML e intentar implementar ese modelo teórico.

Quizás le interese revisar la literatura de trazabilidad del software. En ningún orden en particular:

• CUBRANIC, D., MURPHY, GC, SINGER, J., Y BOOTH KELLOGG, S. Hipikat: una memoria de proyecto para el desarrollo de software. Transacciones sobre ingeniería de software 31, 6 (2005), 446–65.
• TANG, A., BABAR, MA, GORTON, I., Y HAN, J. Una encuesta sobre el uso y la documentación de la lógica del diseño de la arquitectura. En proceso de la 5ta Conferencia de Trabajo IEEE / IFIP sobre Arquitectura de Software (2005).
• RAMESH, B., POWERS, T., STUBBS, C. y EDWARDS, M. Implementación de la trazabilidad de los requisitos: un estudio de caso. En Proc of the Int'l Symp on Requisitos de Ingeniería (York, 1995).
• HORNER, J., Y ATWOOD, ME Justificación del diseño: la justificación y las barreras. En Proc de la 4ta Conferencia Nórdica sobre Interacción Humano-Computadora: Roles cambiantes (Oslo, Noruega, 2006).
• CLELAND-HUANG, J., SETTIMI, R., ROMANOVA, E., BERENBACH, B., Y CLARK, S. Mejores prácticas para la trazabilidad automatizada. Computer 40, 6 (junio de 2007), 27–35.
• ASUNCION, H., FRANÇOIS, F. y TAYLOR, RN Una herramienta de trazabilidad de software industrial de extremo a extremo. En el proceso de la sexta reunión conjunta de European Software Eng Conf y ACM SIGSOFT Int'l Symp sobre los fundamentos de la ingeniería de software (ESEC / FSE) (Dubrovnik, 2007).

Tenga en cuenta que esto es solo la punta del iceberg, y estoy seguro de que he omitido algunos documentos clave.

En una nota separada, mi propio trabajo en Arcum fue un medio para que los programadores expresaran al IDE el uso de modismos de diseño transversales. Una vez expresados, los programadores podrían transformar su código fuente para usar implementaciones alternativas:

• Macneil Shonle, William G. Griswold y Sorin Lerner. Más allá de la refactorización: un marco para el mantenimiento modular de modismos de diseño transversales . En las actas de la sexta reunión conjunta de la Conferencia Europea de Ingeniería de Software y el Simposio SIGSOFT de ACM sobre los fundamentos de la ingeniería de software (ESEC-FSE '07; 3-7 de septiembre de 2007). 175-184.

Por cierto, Arcum también está relacionado con su trabajo DMS.

UML es para un programa cuáles son los planes para un edificio en mi humilde opinión. Los planes por sí solos no son un diseño fuera de curso, necesita especificaciones de materiales (herramientas de código usadas) para eso, una vista general del edificio (alguna representación esquemática de todo el software, incluidos los diseños de GUI), cómo se planta el edificio en los alrededores (un esquema claro de cómo el software interactúa con otros / se planta dentro del sistema operativo), cómo se enfrenta al clima y al suelo (interacción con el hardware), ... Muchos libros sobre diseño intentan definirlo, pero al igual que con En muchas cosas de la ciencia, cada científico tiene un poco su propia definición.

Ahora, tampoco estoy de acuerdo con su observación de que no puede derivar el código de UML. Puede, si tiene la información adicional mencionada. Pero el código real ya no es el diseño, ese es el artefacto. Tampoco puede extraer las piedras y el concreto reales de un plan, pero necesita el plan para colocar las piedras y el concreto reales en la forma correcta y en el lugar correcto.

En ese sentido, el siguiente artículo me pareció interesante (lo encontré en un contexto diferente cuando estaba buscando software de gráficos, pero de todos modos ...). El enfoque gráfico para describir un diseño tenía sentido para mí, aunque, de nuevo, esto es solo una parte del diseño en mi opinión. Lo interesante es que este enfoque proporciona un marco para comprender y refactorizar los diseños (en lugar de refactorizar el software), como se indica en los siguientes documentos:

• Wermelinger y Fiadeiro

• Tsantalis et al.

Hay muchos otros enfoques para describir (parte del) diseño, como el diseño estructurado (Gráficos HIPO) o el diseño de programas integrados , patrones de diseño , ...

Aún así, mientras no haya un conjunto de estándares de la industria, es poco probable que obtenga una forma "regular" de expresar esto. Incluso después de más de 50 años. Y sea honesto, si su empresa encuentra una buena manera de expresar un diseño, ¿lo compartiría con el mundo?

Desde mi propia experiencia personal, diría que somos buenos para capturar el diseño de software. Tenemos una base de datos de requisitos y documentos de diseño para cada característica que hemos implementado en nuestra plataforma. Supongo que mi circunstancia puede ser única. Aquí hay algunas cosas para pensar sin embargo.

Cada persona en mi equipo tiene un título de ingeniería ... principalmente EE o CE. La ingeniería te enseña a diseñar como parte del plan de estudios.

Creo que hay muchos llamados ingenieros de software que provienen de entornos CS. El diseño de software no es una parte integral de la mayoría de los programas de CS. No digo que todas las especialidades de CS sean malas para el diseño, pero apostaría a que la mayoría no tiene educación formal que les enseñe. Creo que mucha gente asume que si puede programar, puede diseñar software, lo cual no es cierto. Dado que muchos programadores no tienen experiencia en ingeniería, no es realmente sorprendente que muchos proyectos de software no tengan un equipo que sea bueno para capturar el diseño.

Veo dos problemas

La primera es que es muy difícil mantener sincronizados el código y la documentación. Si están separados, divergirán y la documentación se volverá inútil. Los programadores han tratado de usar herramientas para hacer el trabajo de mantenerlos sincronizados (como las herramientas CASE), pero estas herramientas se interpusieron entre los programadores y su código, lo que hizo más daño que bien. Una de las ideas clave del diseño impulsado por dominio (Evans, 2004) es que un buen diseño es realmente difícil, por lo que para sacar algo de él, debe:

• elija el área más pequeña posible de su programa donde un buen diseño producirá grandes beneficios, el llamado dominio central
• trabajar muy duro para obtener un buen diseño en forma de un lenguaje ubicuo que todos los miembros del equipo usen todo el tiempo
• tanto como sea posible, haga que el diseño sea parte del código

El otro gran problema con la forma en que diseñamos es que nuestros métodos de diseño no son lo suficientemente matemáticos. Las abstracciones permeables no se prestan para sacar conclusiones sólidas de ellas, y el mundo de la lógica estrictamente aplicada y la verdad clara se llama matemática, que los programadores evitan en su mayoría.

Las pocas herramientas matemáticas que tenemos, como los métodos formales, son muy difíciles de manejar.

Map-reduce es un buen ejemplo de matemática en programación. La idea central es esta: cuando tiene una operación binaria asociativa, puede distribuir su ejecución muy fácilmente. Una operación binaria es una función con dos parámetros, la asociatividad implica que (a + b) + c = a + (b + c)

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99 es

(a1 + a2 + ... + a99) + (b1 + b2 + ... + b99) + (c1 + c2 + ... + c99) donde los As, Bs y Cs pueden agregarse trivialmente en diferentes ubicaciones, sus resultados recopilados y resumido en muy poco tiempo.

Map-reduce es una idea ridículamente simple. Se puede describir en una hoja de papel. Si puede suponer que el lector tiene una comprensión firme del concepto de asociatividad, si cabe en un pedazo de papel bastante pequeño. Ahora trate de explicar map-reduce a alguien sin usar el término asociatividad o referirse indirectamente a él. Yo Te reto.

El diseño de software sin abstracciones matemáticas es como tratar de hacer arquitectura sin molestarse en aprender geometría.

Quizás Haskell pueda arreglar esto con el tiempo. El uso de conceptos de la teoría de categorías para describir programas me parece prometedor. La teoría de categorías es tan abstracta que incluso los matemáticos la utilizaron poco, pero aparentemente las categorías, que son abstractas más allá del reconocimiento, parecen ser lo suficientemente abstractas como para describir la estructura del software. Lo descubriremos Despacio.