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

14

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 design-the-noun es una entidad diferente al artefacto en sí.

Una actividad clave en el negocio de software (de hecho, en cualquier negocio donde el artefacto del producto resultante deba mejorarse) es entender el "diseño (el nombre)". Sin embargo, parece que, como comunidad, somos bastante fracasos completos en su registro, como lo demuestra la cantidad de esfuerzo que las personas ponen en redescubrir hechos sobre su código base. Pídale a alguien que le muestre el diseño de su código y vea qué 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 lo tienen)
  • Una explicación de cómo cada parte del código sirve para lograr la especificación (por ejemplo, una relación entre los fragmentos de especificaciones y los fragmentos de código)
  • Una justificación de por qué el código es como es (por ejemplo, por qué una opción particular en lugar de otra)

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

¿Por qué es que después de más de 50 años de crear software, por qué no tenemos formas regulares de expresar esto? (¡Siéntase libre de contradecirme con ejemplos explícitos!)

Incluso si lo hacemos, la mayoría de la comunidad parece tan enfocada en obtener el "código" que, de todos modos, se pierde el diseño del sustantivo. (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 solucionar esto).

¿Qué has visto como medios 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 ideas propias que completan el punto de vista anterior, pero estoy interesado en las respuestas de otras personas ... y es difícil de implementar mi esquema [[y quizás ese sea el problema real: -]]]

EDIT 2011/1/3: Uno de los hilos de respuestas sugiere que la "documentación" (presumiblemente textual, en particular no formal) podría ser adecuada. Supongo 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 dibujó; mientras que las herramientas fueron discutiblemente exitosas comercialmente, realmente no fueron muy útiles. Una idea clave fue que si los artefactos de "diseño" adicionales no son interpretables formalmente, no se puede obtener ninguna ayuda seria. Creo que la misma perspectiva se aplica a cualquier forma útil de captura de diseño a largo plazo: si no tiene una estructura formal, no será de ninguna utilidad real. Los documentos de texto casi no pasan esta prueba.

    
pregunta Ira Baxter 31.12.2010 - 14:09

5 respuestas

8

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, 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 de cascada donde primero tiene un arquitecto que dice cómo debería funcionar y verse el software, y luego hace que la gente elabore diagramas de cómo debería construirse y, por último, el código mono que implementa estos bonitos flujos de trabajo / UML a esta especificación. ahora ampliamente ridiculizado. Así que, de hecho, toda la industria estuvo ladrando el camino equivocado durante 40 años.

  2. Las herramientas que utilizamos cambian y mejoran constantemente. La programación es un rompecabezas lógico, y se nos ocurren mejores ideas y técnicas para resumir ese rompecabezas y hacerlo comprensible. La forma en que modelamos esto debe evolucionar a la misma velocidad, pero se queda atrás. 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 límites 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 forma de abstraer el software, también podemos incluir 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 más. 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. ¿Qué clase de producto hace? todo el esfuerzo es inútil, lo que a su vez corrobora el punto 1 anterior: modelar el software es mucho menos útil de lo que se pensaba anteriormente. En su lugar, es mejor extraer datos sobre el software del código. Crear un modelo UML a partir de la apariencia real del código es mucho más esclarecedor que crear un modelo UML y tratar de implementar ese modelo teórico.

respondido por el Lennart Regebro 31.12.2010 - 15:08
5

Es posible que esté interesado en revisar la documentación de trazabilidad del software. En ningún orden en particular:

  • CUBRANIC, D., MURPHY, G. C., SINGER, J., and BOOTH KELLOGG, S. Hipikat: una memoria de proyecto para el desarrollo de software. Transactions on Software Engineering 31, 6 (2005), 446–65.
  • TANG, A., BABAR, M. A., GORTON, I., y HAN, J. Una encuesta sobre el uso y la documentación de las razones de diseño de la arquitectura. En proceso de la 5ª 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 Requirements Engineering (York, 1995).
  • HORNER, J., AND ATWOOD, M. E. Fundamento del diseño: la justificación y las barreras. En Proc de la 4ª Conferencia nórdica sobre la interacción hombre-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, R. N. Una herramienta de trazabilidad de software industrial de extremo a extremo. En el proceso de la 6ª Reunión Conjunta de la Confederación Europea de Software 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 aparte, mi propio trabajo en Arcum fue un medio para que los programadores expresen al IDE el uso de modismos de diseño transversales. Una vez expresado, los programadores podrían transformar su código fuente para usar implementaciones alternativas:

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

    
respondido por el Macneil 01.01.2011 - 01:27
2

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

Ahora, tampoco estoy de acuerdo con su observación de que no puede derivar el código de UML. Usted 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, encontré siguiente artículo interesante (lo encontré en un contexto diferente cuando estaba buscando un software gráfico, pero sin embargo ...). El enfoque gráfico para describir un diseño tenía sentido para mí, aunque, una vez más, en mi opinión, esto es solo una parte del diseño. 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:

Hay muchos otros enfoques para describir (parte de) el diseño, como diseño estructurado ( HIPO Charts) o diseño del programa integrado , patrones de diseño , ...

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

    
respondido por el Joris Meys 31.12.2010 - 15:04
2

Desde mi propia experiencia personal, diría que somos buenos para capturar el diseño del 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 quizás sea única. Aquí hay algunas cosas para pensar sin embargo.

Cada persona de 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 currículum.

Creo que hay muchos de los 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 estoy diciendo que todas las carreras de CS sean malas en diseño, pero apostaría a que la mayoría no tiene una 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 una formación en ingeniería, no es realmente sorprendente que muchos proyectos de software no tengan un equipo que sea bueno en la captura de diseño.

    
respondido por el Pemdas 31.12.2010 - 23:49
2

Veo dos problemas.

Lo primero es que es muy difícil mantener el código y la documentación sincronizados. Si están separados, divergirán y la documentación se volverá inútil. Los programadores han intentado 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 causó más daño que beneficio. Una de las ideas clave del diseño basado en dominios (Evans, 2004) es que un buen diseño es realmente difícil, por lo que para obtener algo, debes:

  • elija el área más pequeña posible de su programa donde un buen diseño proporcionará grandes beneficios, el denominado dominio central
  • trabaje realmente duro para obtener un buen diseño en forma de un lenguaje ubicuo que todos los miembros del equipo usan 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 con fugas no se prestan para derivar 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 gran medida.

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áticas en la 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, 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 As, Bs y C se pueden agregar de forma trivial en diferentes ubicaciones, sus resultados se recopilan y resumen en ningún momento.

Map-reduce es una idea ridículamente simple. Puede ser descrito en una hoja de papel. Si puede suponer que el lector tiene un firme conocimiento del concepto de asociatividad, si cabe en un pedazo de papel bastante pequeño. Ahora intente explicar la reducción de mapas a alguien sin usar el término asociatividad o referirse a él de manera indirecta. Te atrevo.

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

Tal vez 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 tenían poca utilidad para ella, pero aparentemente las categorías, que son abstractas más allá del reconocimiento, parecen ser lo suficientemente abstractas para describir la estructura del software. Lo averiguaremos. Lentamente.

    
respondido por el Waquo 03.01.2011 - 16:40

Lea otras preguntas en las etiquetas