Rastrear una acción por la arquitectura

977. Identidad de la lección

Módulo

3.1 — Arquitectura de runtime

Lección

Rastrear una acción por la arquitectura

Tipo académico

Construcción guiada

Tipo de esquema

Práctica

Orden

2

Tiempo estimado

40–55 minutos, incluida la práctica

Esta lección convierte el mapa de ownership de la Lección 1 del Módulo 3.1 en un rastreo de ejecución. Seguirás una acción del jugador a través del runtime y registrarás quién crea, actualiza, comunica y desmonta cada objeto o responsabilidad relevante.

978. Objetivo de aprendizaje

Al terminar esta lección, podrás rastrear una acción de runtime por sus rutas de creación, actualización, comunicación y teardown, e identificar al menos un límite cuyo owner o cuya responsabilidad de ciclo de vida no estén claros.

979. Por qué importa

Una arquitectura estática puede parecer coherente aunque la ejecución cruce límites ocultos o ambiguos. Rastrear una acción muestra dónde se toma una decisión, dónde cambia el estado y dónde la comunicación depende de un owner supuesto. Así puedes evaluar una arquitectura mediante evidencia, en lugar de juzgarla por los nombres de los componentes, las carpetas o la cantidad de código.

También permite detectar un problema frecuente de integración: un componente parece controlar una responsabilidad durante la ejecución normal, pero ningún componente se ocupa de limpiarla, cancelarla o reemplazarla.

980. Conocimientos previos

Debes haber completado la Lección 1 del Módulo 3.1, De sistemas de juego a owners de runtime. Debes poder distinguir un sistema de juego de un componente de runtime y describir el ownership como autoridad de decisión más responsabilidad sobre el ciclo de vida. No necesitas un motor, un proyecto ni una base de código concretos.

981. Concepto principal

Una acción no es una sola llamada a una función. Es una ruta que atraviesa varias responsabilidades de runtime.

Para una acción, examina cuatro rutas conectadas:

1. Creación: ¿Qué owner crea el objeto, la suscripción, la solicitud o el estado temporal que necesita la acción?
2. Actualización: ¿Qué owner evalúa la acción o hace avanzar el estado resultante?
3. Comunicación: ¿Cómo llega la decisión o el cambio de estado a otro componente?
4. Teardown: ¿Qué owner elimina, desactiva, cancela, anula una suscripción o retira esa responsabilidad?

Un rastreo solo está completo cuando cubre las cuatro rutas. Si algo puede crearse o actualizarse, pero ningún owner puede explicar cómo termina, la arquitectura contiene un límite de ciclo de vida sin owner.

982. Modelo mental: rastreo de acción en cuatro rutas

Representa el rastreo como una cadena, no como una lista de componentes desconectados:

acción del jugador
    -> decisión con autoridad
    -> actualización del estado
    -> comunicación a través de un límite
    -> presentación o sistema dependiente
    -> teardown cuando termina la responsabilidad

Para cada flecha, indica el emisor, receptor, disparador y owner. Si la evidencia disponible no permite justificar alguno de esos elementos, márcalo como no resuelto en lugar de completar el hueco con una suposición.

983. Ejemplo concreto

Considera una acción genérica: el jugador activa una compuerta de acceso temporal.

Los tres primeros pasos pueden parecer funcionales, pero el cuarto revela el riesgo arquitectónico. Si tanto el controlador de interacción como el componente de sesión pueden terminar la sesión, la autoridad está dividida. Si ninguno puede hacerlo, el límite de ciclo de vida no tiene owner. El rastreo no impone una implementación concreta; hace visible la decisión de ownership.

984. Práctica guiada

Crea un rastreo estático de ejecución para esta acción: el jugador solicita un permiso de acceso temporal. No implementes código. Usa una tabla, un diagrama o un documento de texto plano con estas columnas o etiquetas equivalentes:

Paso | Disparador | Emisor | Receptor | Estado u objeto afectado | Owner | Evidencia de ciclo de vida | Pregunta abierta

Paso 1 — Delimita la acción

Escribe una frase que describa la acción y su condición de finalización. Mantenla acotada. Por ejemplo: “El jugador solicita acceso; la solicitud termina cuando el runtime la acepta o la rechaza”. No rastrees una funcionalidad completa ni una sesión de juego entera.

Paso 2 — Rastrea la creación

Identifica qué debe existir para que la acción pueda ejecutarse. Registra quién lo crea, qué activa la creación y si esta ocurre una vez, se repite o depende de una condición. Si la acción reutiliza un objeto existente, márcalo como reutilizado e indica qué owner lo creó.

Paso 3 — Rastrea la actualización

Identifica al owner que evalúa la acción o cambia su estado después de la creación. Registra si la actualización se produce por eventos, por frame, mediante un temporizador o por una solicitud explícita. Nombra el estado que cambia; “el sistema se encarga” no constituye evidencia suficiente.

Paso 4 — Rastrea la comunicación

Dibuja cada cruce de límite. Para cada uno, identifica el emisor, el receptor, el disparador y el mecanismo de comunicación. Si el mecanismo aún no está decidido, escribe sin decidir. No conviertas de forma implícita un límite no resuelto en una referencia directa.

Paso 5 — Rastrea el teardown

Elige dos condiciones de finalización, como completar la acción y cancelarla, descargarla o destruir al owner. Para cada condición, registra quién elimina, desactiva, cancela, anula la suscripción o retira el estado temporal, el temporizador, el objeto o la referencia. Si dos componentes pueden tomar la misma decisión de limpieza, marca el conflicto de autoridad.

Paso 6 — Diagnostica un límite sin owner

Selecciona un límite ambiguo, sin respaldo o dividido entre varios owners. Etiquétalo con uno de estos diagnósticos:

• Owner ausente: ningún componente tiene autoridad explícita.
• Ciclo de vida incompleto: existe creación o actualización, pero el teardown no está asignado.
• Contrato de comunicación poco claro: no se ha especificado el comportamiento esperado entre emisor y receptor.
• Autoridad dividida: varios componentes pueden tomar la misma decisión.

Escribe una pregunta de ownership que deba responderse antes de implementar la arquitectura.

Punto de decisión

Elige al owner del estado temporal o de su teardown. Explica por qué ese owner dispone tanto de autoridad de decisión como de acceso a los eventos necesarios del ciclo de vida. Si la evidencia no es suficiente, aplaza la decisión de forma explícita e indica qué información falta. No inventes un owner solo para que el rastreo parezca completo.

985. Evaluación práctica

Completa el proyecto vinculado Rastreo de una acción de runtime y límite de ownership. Entrega el rastreo, el límite diagnosticado y la decisión de ownership o su aplazamiento justificado. Los criterios del proyecto distinguen una tabla meramente rellenada de un rastreo respaldado por evidencia de ciclo de vida.

986. Evidencia de validación

987. Puntos clave

• Una acción de runtime es una ruta de ciclo de vida, no solo un punto de llamada.
• La creación, la actualización, la comunicación y el teardown deben rastrearse por separado.
• Cada límite resuelto necesita un emisor, un receptor, un disparador y un owner.
• La ausencia de teardown es un problema de ownership, no solo un detalle de limpieza.
• Declarar la incertidumbre es más útil que introducir una suposición arquitectónica sin respaldo.

988. Transición al Módulo 3.2

Conserva tres elementos del rastreo: el estado que cambia, su owner actual y la pregunta de autoridad que quedó sin resolver. En el Módulo 3.2 clasificarás ese estado según su alcance e identificarás quién tiene autoridad para escribirlo. No presupongas que una mayor visibilidad o una ubicación de almacenamiento determinan el ownership.

989. Comprobación