UML no siempre se usa para detallar el 100% de detalles de una futura implementación

Hace ya sus años, en el 94, Steve Cook y John Daniels, unos señores apenas conocidos hoy en el mundillo del desarrollo y la ingeniería del software, escribieron un libro muy interesante, el Designing Object Systems, que, entre otros, pretendía aclarar cómo usar correctamente los diagramas típicamente usados en diseño.
Aquel libro sería aún más desconocido de lo que es sino fuese porque Fowler, que, digamos, es un autor mucho más popular, lo utilizó como base para argumentar en su popular libro, UML Distilled, para mí, el mejor libro de UML, que los diagramas UML son una buena práctica… siempre que no te pases documentado, porque al final la mayoría de esa documentación, en exceso, no se utilizará, y nadie la implementará.
Para exponerlo, Steve Cook y John Daniels hacían referencia a tres perspectivas, las tres maneras en las que se puede usar un diagrama UML, y que no son siempre detallando al máximo cada detalle de lo que supuestamente luego se implementará.
Esas tres perspectivas son:
– Una la conceptual. Diagramas con conceptos del dominio (del negocio) y que son independientes del lenguaje. Muy útiles para que todo el equipo unifique ideas.
– Otra la de especificación. Diferente a la anterior, más detalle, pero sólo observamos las interfaces del software (esa importante diferencia en el mundo OO entre interfaz y su implementación), no su implementación.
– Y, por último, y diferenciado de los anteriores, la de Implementación que muestra al detalle la implementación.
Lo curioso es que por muchos años que han pasado desde aquel libro, hasta el presente parecen solo haber llegado, mayoritariamente, dos maneras de aplicar UML:
1 – No utilizándolo para nada, porque suena a papeleo.
2 – Utilizándolo para documentar hasta el mínimo detalle de una futura implementación, con las consabidas desviaciones entre teoría y práctica.
Otro ejemplo más del típico blanco o negro en el que se suele mover esta nuestra profesión.

Javier Garzás

0 comentarios en “UML no siempre se usa para detallar el 100% de detalles de una futura implementación”

  1. Pingback: Bitacoras.com

  2. Como siempre gran aporte Javier. Un análisis certero de la realidad del uso de UML. Mi opinión es que siempre es bueno tener diagramas al menos de alto nivel sobre la parte estática del diseño del SW, y sobre la parte dinámica lo mismo , pero para ello se requiere de un buen arquitecto que sepa sacarle partido, y que no se convierta en generar unos diagramas a posteriori de la construcción que nadie utlizará para nada en su vida. Creo que hay muchos arquitectos que lo que son es muy buenos programadores y entusiastas de la tecnología, pero el diseño es una disciplina propia a la que no se presta demasiada atención

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba