Elija la pregunta del dibujo
Un diagrama necesita responder a una pregunta. La arquitectura muestra partes y relaciones; la secuencia muestra quién hace qué a lo largo del tiempo; un flujo destaca etapas y decisiones; una máquina de estados describe situaciones permitidas y transiciones.
No ponga todos estos objetivos en un solo dibujo. Para explicar una atención, empiece por el flujo de la solicitud. Para investigar una demora, una secuencia entre cliente, aplicación y almacenamiento puede ser más adecuada. La elección determina qué entra y qué queda fuera.
Por qué aprender
Un dibujo bonito con un propósito confuso no ayuda a decidir. Una pregunta clara permite evaluar si el diagrama explicó el problema o solo reorganizó palabras.
✓ Hacer
Mostrar el camino del error.
✗ Evitar
Dibujar componentes solo porque son comunes.
Conceptos clave
Liste solo los elementos confirmados
Antes de dibujar, lista a los participantes, las entradas, las salidas y los lugares donde se guardan los datos. Relaciona cada elemento con una evidencia del proyecto o con una hipótesis identificada. Si todavía no sabes dónde se guarda un archivo, no dibujes una base de datos por costumbre.
Usa nombres que el público reconozca. “Recepción”, “lista de pedidos” y “conferencia” pueden explicar mejor un proceso de negocio que los nombres internos de funciones. Cuando se necesite un nombre técnico, también presenta su función en lenguaje común.
Por qué aprender
La lista evita que el asistente complete la arquitectura con componentes plausibles, pero inexistentes. También establece un vocabulario que se puede revisar antes de ajustar el dibujo.
Un camino para aplicar
- Define la pregunta y lista los elementos confirmados.
- Dibuja las relaciones con verbos y decisiones.
- Recorre dos casos y ajusta la legibilidad.
Conceptos clave
Da significado a las conexiones
Una línea entre cajas puede significar envío, lectura, dependencia u orden. Etiqueta la conexión cuando no sea evidente. Usa la misma convención en todo el dibujo e incluye una leyenda corta cuando haya más de un tipo.
En el ejemplo, “validar” no es lo mismo que “guardar”. La conferencia puede rechazar un pedido antes de que entre a la lista. Mostrar esa decisión evita que el lector entienda que toda entrada se acepta. El camino de error merece tanta claridad como el camino feliz.
Por qué aprender
Las conexiones cargan gran parte del significado. Sin etiquetas y decisiones, el lector puede interpretar causalidad donde solo existe una relación de consulta.
flowchart TD
A[Receber pedido] --> B{Tarefa e contato presentes?}
B -- Sim --> C[Registrar na lista]
B -- Não --> D[Pedir complemento]
D --> A
C --> E[Conferir entrega]
E --> F[Concluir]
Conceptos clave
Mantén una fuente editable
Guarda el diagrama en un formato que permita cambios, además de la imagen de presentación. Una descripción Mermaid, un SVG o el archivo nativo de la herramienta sirven como base de mantenimiento. Un PNG solo es útil para mostrar, pero es más trabajoso para corregir.
Registra la versión del proceso representado. Si una etapa cambia, revisa qué conexiones dejan de tener sentido. No actualices solo el nombre de la caja: el cambio puede requerir un nuevo camino, una validación o un estado intermedio.
Por qué aprender
La fuente editable reduce el costo de mantener la documentación alineada con el sistema. También permite revisar el diagrama como parte de un cambio de código.
✓ Hacer
Guardar el archivo editable junto con la imagen.
✗ Evitar
Usar una flecha sin saber qué significa.
Conceptos clave
Prueba la comprensión de otra persona
Pídele a alguien que recorra un caso normal y otro con error usando solo el dibujo. Observa en qué puntos la persona tiene que adivinar. Una flecha pequeña, un nombre abstracto o una etapa faltante suele aparecer en esa lectura.
Haz también una revisión visual: textos legibles, contraste suficiente y conexiones sin cruces innecesarios. En pantallas pequeñas, prefiere un diagrama más simple a una imagen enorme reducida hasta que las etiquetas ya no se lean.
Por qué aprender
La prueba mide la función comunicativa del mapa. Verificas si el lector entiende el orden y las condiciones, en lugar de evaluar solo la estética.
| Criterio | Evidencia esperada |
|---|---|
| Fidelidad | El dibujo corresponde al enunciado. |
| Excepción | El pedido incompleto tiene un camino explícito. |
| Mantenimiento | Existe una representación editable. |
Conceptos clave
Práctica: dibuja el pedido incompleto
Representa un pedido que llega al taller. Si tiene tarea y contacto, entra en la lista. Si falta alguno de esos datos, vuelve a complementación. Después de la conferencia final, puede marcarse como concluido.
Escribe la descripción del flujo, genera el dibujo en la herramienta de tu elección y compara los caminos con el enunciado. No agregues pago, inteligencia artificial o base de datos si esos elementos no son necesarios para responder a la pregunta del ejercicio.
Por qué aprender
La práctica enseña a acotar el alcance del dibujo y a representar excepciones. El resultado se reutilizará en la documentación de los proyectos finales.
Tu ejercicio
Crea un flujo para el pedido descrito en el apartado. Identifica la decisión, el retorno y la salida. Explica cómo se comporta el dibujo cuando falta el contacto.
Descargar ficha de la prácticaRevisar respuesta comentada
Decisión: ¿tarea y contacto están presentes? Si no, pedir complementación y volver a recepción. Si sí, registrar, verificar la entrega y concluir. La ausencia de contacto impide avanzar hacia registro, sin borrar el pedido recibido. La imagen y su fuente deben mostrar el mismo camino.
Comprueba tu comprensión
No sabes dónde el sistema guarda los datos. ¿Cómo representarlo?
Conceptos clave
Lo que queda de este módulo
Un mapa de flujo editable acompañado de una explicación simple.
- ✓ El dibujo corresponde al enunciado.
- ✓ El pedido incompleto tiene un camino explícito.
- ✓ Existe una representación editable.
El progreso registra tu lectura. La práctica queda concluida cuando revisas la entrega.