Inicio Make Text BiggerMake Text SmallerReset Text Size
Preguntas sobre el diseño E-mail
Valoración del artículo: / 13
MaloBueno 
23.05.2005
Un ingeniero puede concebir el diseño de un sistema, de un componente o de una clase sentado en un sofá mirando al techo, o analizando y descomponiendo el problema con la ayuda de diagramas UML o tarjetas CRC.
Hay quien emplea herramientas CAD y quien trabaja con libreta y papel.

La documentación del diseño, o los diagramas que lo representan, NO SON EL DISEÑO. Son herramientas que pueden resultar útiles para concebirlo y para comunicarlo.
El diseño es una actividad intelectual.

No se produce a través de procesos que emplean diagramas UML o programas de representación. El diseño lo produce el talento de su creador o de sus creadores. (...) Por esta razón, los modelos de calidad que cubren procesos de diseño, pueden garantizar que éste se documenta de determinada manera, que se comunica a las personas implicadas, que se mantiene actualizado durante el ciclo de vida del sistema, y que se verifica la adecuación del código al diseño. Pero no pueden garantizar que éste sea bueno.

Al desarrollar software no hay que perder nunca de vista que el fin último es aportar soluciones a las necesidades o limitaciones de un sistema. Y como los problemas nunca tienen una única solución, dar con la más conveniente es la finalidad del buen diseño.

El diseño es la estrategia de la solución, y la codificación la táctica.

Por eso, dar respuesta a la pregunta de cómo identificar un mal diseño, que apunta un comentario del artículo Comprobación de la arquitectura no es fácil.

Afirmaciones como la que en alguna ocasión he oido, del tipo "Ha realizado un análisis magnífico: más de 500 folios", son resultado de confundir los medios por el fin.
Sin duda un trabajo extenso puede calificarse de magnífico, pero sólo por lo de "magno".
Es posible que además sea una documentación rigurosa, y fiel en su organización y contenidos a normas y estándares. Pero ¿la estrategia de solución que propone es la más adecuada?.

Al ser el diseño un plan de solución, sin realidad física, y el resultado del talento de su creador, no resulta posible establecer pautas absolutas que a modo de lista de comprobación permitan evaluar y "poner nota" a la calidad de un diseño. En este aspecto, el criterio definitivo para determinarla es observando el comportamiento de la solución.

Evaluar el diseño del sistema estudiando su funcionamiento, es un un método de análisis dinámico cuya práctica analiza con dos casos de estudio el trabajo comentado en el artículo anterior.

De todas formas, aunque no resulta posible determinar unos criterios objetivos, que con rigor científico puedan evaluar a través del análisis estático de la documentación del diseño y del código producido la calidad de la arquitectura, sí que la experiencia y el sentido común pueden establecer criterios útiles a modo de "alertas" para identificar las probabilidades y los riesgos de encontrarnos ante un mal diseño; y por su puesto para poder "calar" con un primer vistazo errores de bulto.

El análisis estático y predictivo de la solvencia de un diseño es más una cuestión más de intuición y de juicio experto, y en esta línea es recomendable la comparación con el "olfato" que hace Robert C. Martin en su libro Agile Software Development, al definir 7 características para identificar lo que él denomina "software podrido":

1.- Rigidez.
Dificultad para modificar el software. Incluso con cambios pequeños. Un diseño es rígido si un cambio simple genera una cascada de modificaciones sucesivas en módulos dependientes. Cuantos más módulos deben cambiarse, más rígido resulta el diseño.

2.- Fragilidad
Tendencia del sistema a romperse en sitios diferentes al implementar un cambio. A menudo los nuevos problemas surgen en áreas que no tienen una relación conceptual con la que se ha cambiado; y al solucionarlos se generan otros nuevos, haciendo que el equipo de programación termine por parecerse a un perro que persigue su propia cola.

3.- Inmovilidad
Un diseño es inamovible si contiene partes que aunque podrían resultar útiles en otros sistemas, el coste y los riesgos de su extracción y migración son tan elevados que no compensan.

4.- Viscosidad
La viscosidad puede presentarse en el software y en el entorno.
Normalmente una modificación puede implementarse de varias formas posibles. Algunas preservando el diseño original, y otras no (introduciendo parches). Cuando las formas que mantienen el diseño son más costosas que las que lo degradan, se trata de un diseño "viscoso".

Entornos viscosos son los que hacen lento e ineficiente el desarrollo. Si los cambios requieren largos procesos de re-compilación, o implican horas de comprobación o bloqueo sobre otros ficheros para mantener el control del código fuente, los programadores tenderán a realizar modificaciones que no requieran tanto trabajo, aunque con ellas no se respete el diseño.

5.- Complejidad innecesaria
Un diseño contiene complejidad innecesaria si las soluciones que plantea resultan complicadas o laberínticas. El talento y oficio del diseñador es el factor fundamental para evitarlo, pero en muchas ocasiones la complejidad innecesaria se produce por anticiparse a posibles cambios futuros de requisitos, implementando características en el software que teóricamente las facilitarán.
Desafortunadamente el efecto suele ser el contrario, y el diseño acaba incorporando construcciones que nunca se emplearán y que puede implicar peso complejidad que harán un software más complejo y difícil de comprender.

6.- Repeticiones innecesarias.
La técnica de "copy-paste" es útil para la edición de textos, pero puede resultar nefasta en la edición de código. Con demasiada frecuencia los sistemas de software se construyen repitiendo docenas o cientos de veces fragmentos de código idénticos.

7.- Opacidad
O grado de incomprensibilidad del código, que puede producirse ya en la codificación inicial, o a través de la evolución a través de las sucesivas modificaciones.
Para evitarla, los desarrolladores deben ponerse en el papel de un futuro "lector", y las tareas de modificación cubrir la refactorización del código siempre que sea necesario.


Esta lista de posibles "sospechosos" o "culpables" del mal diseño, refleja también la idea que Jack Reeves expuso en 1992 en su artículo What is Software Design?, y que sigue manteniendo en 2005: el diseño es el código.

En realidad la idea subyacente a la afirmación de Reeves no es que el código sea el diseño, sino que es en el código donde éste queda plasmado y a través del que produce los resultados esperados.
Por esta razón para identificar un mal diseño no hay que detener el análisis en su concepción inicial, y es necesario extenderlo hasta el resultado final. Problemas como la opacidad, repeticiones o complejidad innecesaria, viscosidad, etc. pueden introducirse en las fases de codificación y mantenimiento.

A modo de conclusión, para dar respuesta a las preguntas de ¿qué es el diseño?, ¿cómo se evalúa su calidad?, ¿es el código?, ¿son los diagramas?, etc. propongo las siguientes conclusiones:

  • El diseño es la estrategia de solución.
  • Las tareas de codificación, integración y mantenimiento del sistema son la táctica.
  • La estrategia debe ser adecuada a las necesidades de los usuarios (requisitos y atributos de calidad esperados).
  • No surge de procesos, herramientas o lenguajes de modelado.
  • Surge del talento de su creador.
  • Los procesos, las herramientas y los lenguajes de modelado pueden resultar útiles como ayuda para descomponer la complejidad, y para comunicar el diseño a los participantes del proyecto.
  • El talento de algunos profesionales les puede permitir manejar niveles de complejidad elevados sin necesitar apoyo de procesos, herramientas o lenguajes de modelado.
  • A través del código es posible ver el diseño y la arquitectura del sistema.
  • La documentación del código resulta útil para comunicar su diseño a través del espacio en sistemas en los que intervienen muchos desarrolladores, y del tiempo para facilitar su mantenimiento.
  • Al emplear documentación para la comunicación del diseño es necesario trabajar con procesos suficientes para garantizar su integridad y actualidad a través de los cambios.
  • El diseño no cumple su finalidad hasta que no queda plasmado en el código.
  • El resultado del diseño puede fallar tanto errores en su estrategia como por distorsiones introducidas en la codificación, integración y mantenimiento.
Comentarios (1)Add Comment
LISSOLETT
escrito por Invitado, November 16, 2005
ME PARECE Q LA PAGINA ES MUY BUENA POR Q APARECE TODO SOBRE LO Q UNO BUSCA Y JUSTAMENTE LO Q UNO DECEA
Informar de comentario inadecuado
voto negativo
voto positivo
Votes: +0

Escribir comentario
quote
bold
italicize
underline
strike
url
image
quote
quote
smile
wink
laugh
grin
angry
sad
shocked
cool
tongue
kiss
cry
reducir | aumentar

busy
 
< Anterior   Siguiente >

En Navegapolis
En Internet

Advertisement

Amigos de Navegápolis

Área de descargas

(c) Navegapolis