Arquitectura de software y UML
Usted se hace cargo de un software que ha escrito otra persona. Apenas hay documentación, los comentarios están desfasados y quien conocía el código ya no está. Aun así, tiene que corregir errores e incorporar nuevas funciones, y además pronto.
El primer reflejo es leer archivo por archivo. Eso lleva mucho tiempo y aporta sobre todo detalles. Avanzará más rápido con una imagen del conjunto: ¿qué partes hay, cómo se relacionan y qué ocurre en qué orden? Para eso existe precisamente UML, el Unified Modeling Language.
Estática y dinámica: dos puntos de vista sobre el mismo código
UML conoce catorce tipos de diagrama. Para adentrarse en código ajeno bastan unos pocos. Se dividen en dos grupos: los diagramas estáticos muestran el plano de construcción y los dinámicos muestran el desarrollo. Solo ambos juntos dan la visión de conjunto.
| Tipo de diagrama | Punto de vista | Pregunta que responde |
|---|---|---|
| Diagrama de clases | Estática | ¿Qué clases hay y quién conoce a quién, quién posee a quién o quién hereda de quién? |
| Diagrama de paquetes | Estática | ¿Qué componentes, por ejemplo DLL o espacios de nombres, dependen unos de otros? |
| Diagrama de secuencia | Dinámica | ¿Quién llama a quién y en qué orden? |
| Diagrama de estados | Dinámica | ¿En qué estado se encuentra un proceso y qué lo hace avanzar? |
| Diagrama de actividades | Dinámica | ¿Qué actividades se suceden y dónde se ramifica el proceso? |
Cómo proceder
- Buscar los puntos de entrada. ¿Dónde empieza el programa? En el software de escritorio, son comandos, entradas de menú, botones o eventos. Anote los tres a cinco procesos que de verdad importan para su tarea.
- Dibujar la estática. Empiece por una clase que ya conozca y siga sus relaciones. Dibuje solo las clases que pertenecen a sus procesos. Los atributos y los métodos, añádalos solo cuando los necesite.
- Dibujar la dinámica. Recorra cada proceso importante en el depurador y plásmelo en un diagrama de secuencia: una caja por cada objeto participante, una flecha por cada llamada, y el tiempo transcurre de arriba abajo. Si un proceso tiene varios pasos o modos de funcionamiento, ayuda además un diagrama de estados.
- Poner los diagramas uno junto a otro. Ahora ve lo que el código por sí solo no muestra: clases que hacen lo mismo, procesos que calculan varias veces los mismos datos, dependencias que apuntan en la dirección equivocada.
- Hablar con los expertos. Muestre los diagramas a quienes usan o mantienen el software. Cinco cajas en la pizarra aclaran a menudo en minutos lo que en el código lleva días.
Leer diagramas de clases: las líneas son lo decisivo
Una clase es una caja con hasta tres compartimentos: nombre, atributos, métodos. Lo interesante está entre las cajas. Una línea continua significa «conoce». Un rombo vacío significa «tiene»: la parte puede vivir sin el todo, como un árbol sin el bosque. Un rombo relleno significa «se compone de»: la parte vive y muere con el todo, como una rama con su árbol. Un triángulo vacío representa la herencia, es decir, «es un». Una flecha discontinua significa «usa».
Tres reglas ayudan a leer: el rombo va junto al todo, el triángulo junto a la superclase y la punta de flecha junto a lo conocido. En los extremos de una línea figuran las multiplicidades, por ejemplo 1, 0..1 o 0..*.
De la práctica: calibración con 3 pasos en lugar de 5
Un gran fabricante internacional de sensores nos pidió que nos hiciéramos cargo del software de calibración de escáneres láser con rueda de espejos. El proveedor anterior había dejado el trabajo. El código fuente era apenas legible y estaba parcialmente ofuscado. La calibración constaba de cinco pasos que los técnicos de puesta en marcha, los integradores y el soporte realizan en todo el mundo en cada instalación.
Analizamos el código paso a paso y representamos la estructura estática y los procesos dinámicos como modelo UML. Enseguida se vio que varios pasos de calibración se solapaban. En el código apenas se apreciaba; en el diagrama, sí. Después ajustamos de nuevo matemáticamente los pasos entre sí y eliminamos los superfluos. Hoy, la calibración necesita tres pasos en lugar de cinco. Como se realiza con mucha frecuencia en todo el mundo, esto ahorra varios miles de horas de trabajo al año.
Errores típicos
- Todo en un único dibujo. Nadie lee un diagrama con cuarenta cajas. Es mejor tener tres diagramas pequeños, cada uno con una pregunta a la que responde.
- Solo generar. Muchas herramientas generan diagramas de clases a partir del código con solo pulsar un botón. Es un buen punto de partida, pero todavía no es una visión de conjunto. Esta solo surge al seleccionar y omitir.
- Solo la estática. Un diagrama de clases muestra lo que hay, pero no lo que ocurre. El trabajo duplicado en los procesos solo lo encontrará en el diagrama de secuencia o de estados.
- El rombo en el lado equivocado. El rombo va junto al todo. Si está junto a la parte, de repente la hoja posee el árbol.
- Composición donde solo hay una referencia. No toda referencia en el código es posesión. Compruebe quién crea un objeto y quién lo libera.
- Diagramas que se quedan desfasados. Un diagrama que ya no se corresponde con el código es peor que ninguno. Manténgalo pequeño y modifíquelo cuando cambie el proceso.
Cómo le ayudamos
- Analizamos código ajeno o que ha ido creciendo con el tiempo y lo hacemos comprensible con UML: control de calidad y revisión de código.
- Planificamos software nuevo con UML antes de escribir la primera línea: UML en la planificación de software.
- Su equipo aprende a leer diagramas UML y a dibujarlos por sí mismo: formación en UML en la tienda de Cadida.
- ¿Se ha hecho cargo de un código y no sabe por dónde empezar? Concierte una primera conversación.
Fuentes: Ebi F. Eilber, AutoCAD .NET API (libro técnico, publicación prevista para 2027), capítulo «Leer UML»; caso de estudio «Calibración de láseres con rueda de espejos: 3 pasos en lugar de 5», casos de estudio de Cadida.
kununu