El diagrama de casos de uso muestra **quién puede hacer qué** con el sistema. Se presenta dividido en cuatro subsistemas porque un único diagrama con treinta casos de uso y siete actores resulta ilegible y no ayuda a nadie a entender el producto. En todos los diagramas, el recuadro representa la **frontera del sistema**: lo que queda dentro es responsabilidad de Travia, lo que queda fuera son los actores que lo usan o los servicios de los que depende. ## Actores | Actor | Tipo | Descripción | |---|---|---| | Visitante | Primario, humano | Persona sin sesión iniciada. Puede explorar el catálogo y registrarse, pero no comprar. | | Viajero | Primario, humano | Usuario registrado con rol `viajero`. Compra paquetes, consulta su historial y califica lo que contrató. | | Agencia | Primario, humano | Usuario registrado con rol `agencia`. Publica y administra paquetes, contrata su plan y gestiona su cuenta de dinero. | | Administrador | Primario, humano | Usuario registrado con rol `administrador`. Gestiona usuarios y planes, procesa retiros y consulta las métricas globales. | | Mercado Pago | Secundario, sistema | Pasarela de pago. Recibe la orden y devuelve el resultado del cobro mediante una notificación. | | Nominatim / OSM | Secundario, sistema | Servicio de geocodificación. Convierte una dirección o un destino en coordenadas. | | Firebase Cloud Messaging | Secundario, sistema | Servicio de entrega de notificaciones push a la aplicación móvil. | | Planificador | Secundario, sistema | Proceso programado interno. Dispara la liberación de reservas vencidas y los avisos de vencimiento de suscripción. **Hoy está desplegado en Kubernetes pero no programa ninguna tarea, y en desarrollo no se levanta**: ver la nota debajo de la tabla. | Los tres roles humanos autenticados son exactamente los tres roles definidos en el esquema de identidad, y cada caso de uso se autoriza consultando un permiso concreto de ese rol, nunca preguntando por el nombre del rol. **El Planificador está en el diagrama y no en `compose.yaml`, y conviene decirlo acá antes que descubrirlo comparando.** Los dos casos que dispara —liberar las reservas que vencieron sin pago (`CU21`) y avisar que una suscripción está por vencer (`CU29`)— son disparos por calendario y no por una persona, así que el actor corresponde: modelarlos como iniciados por el viajero o por la agencia sería falso. Lo que todavía no existe es el servicio que los dispare. Cuando lleguen esas historias se resuelve con el planificador de tareas del framework, que corre en el mismo contenedor de PHP y no agrega ningún servicio nuevo a la orquestación. **Declarar el estado real es mejor que dibujar un componente que no existe**, y esta es la única pieza del diagrama que hoy no tiene contraparte en ejecución. **Actualización del 30/09/2026.** Al preparar el despliegue de producción el planificador pasó a existir como proceso, aunque no en `compose.yaml`: en Kubernetes corre como un `Deployment` propio de una sola réplica con `php artisan schedule:work` (ver RNF35 y la sección de despliegue). **Sigue sin programar ninguna tarea**, así que el actor tiene ahora dónde vivir pero todavía nada que disparar; las dos tareas llegan con CU21 y CU29. ## Herencia entre actores Un viajero, una agencia y un administrador son también visitantes: todo lo que un visitante puede hacer sin sesión, ellos lo pueden hacer con sesión iniciada. Esa relación evita repetir los casos de uso del catálogo en cada actor. ```mermaid flowchart BT viajero["Viajero"] --> visitante["Visitante"] agencia["Agencia"] --> visitante admin["Administrador"] --> visitante ``` ## Vista general El diagrama general muestra **todo el sistema de una vez**: la frontera de Travia, los siete actores y los treinta casos de uso agrupados en sus cuatro subsistemas. Cada flecha une un actor con el subsistema en el que participa; qué caso concreto inicia, y qué inclusiones y extensiones hay entre casos, se desarrolla en el diagrama de cada subsistema, más abajo. ```mermaid flowchart LR visitante(["Visitante"]) viajero(["Viajero"]) agencia(["Agencia"]) admin(["Administrador"]) mp(["Mercado Pago"]) osm(["Nominatim / OSM"]) fcm(["Firebase Cloud
Messaging"]) plan(["Planificador"]) subgraph travia["Travia · frontera del sistema"] direction LR subgraph ident["Identidad y acceso"] direction TB g01["CU01 Registrarse como viajero"] g02["CU02 Registrar agencia"] g03["CU03 Iniciar sesión"] g04["CU04 Cerrar sesión"] g05["CU05 Gestionar perfil"] end subgraph cat["Catálogo, búsqueda y compra"] direction TB g06["CU06 Explorar catálogo"] g07["CU07 Buscar y filtrar paquetes"] g08["CU08 Consultar detalle"] g09["CU09 Buscar por cercanía"] g18["CU18 Comprar paquete"] g19["CU19 Pagar la orden"] g20["CU20 Procesar notificación de pago"] g21["CU21 Liberar reservas vencidas"] g22["CU22 Consultar historial de compras"] g23["CU23 Calificar paquete y agencia"] end subgraph ag["Publicación y gestión de la agencia"] direction TB g10["CU10 Publicar paquete"] g11["CU11 Geocodificar destino"] g12["CU12 Consultar sugerencia de precio"] g13["CU13 Modificar paquete"] g14["CU14 Despublicar paquete"] g15["CU15 Contratar o renovar suscripción"] g16["CU16 Consultar panel de métricas"] g17["CU17 Consultar cuenta y solicitar retiro"] g28["CU28 Procesar solicitud de retiro"] end subgraph adm["Administración y transversales"] direction TB g24["CU24 Supervisar estado comercial de las agencias"] g25["CU25 Gestionar usuarios"] g26["CU26 Gestionar planes"] g27["CU27 Consultar dashboard administrativo"] g29["CU29 Notificar al usuario"] g30["CU30 Consultar centro de ayuda"] end end visitante --> ident visitante --> cat visitante --> ag visitante --> adm viajero --> ident viajero --> cat agencia --> ident agencia --> ag admin --> ident admin --> ag admin --> adm mp --- cat plan --- cat plan --- adm osm --- ag fcm --- adm ``` Las flechas de los actores humanos van hacia el sistema porque son ellos los que inician los casos. Las de los servicios externos son líneas sin punta porque la relación va en los dos sentidos: Travia le pide el cobro a Mercado Pago y Mercado Pago le notifica el resultado; Travia le pide coordenadas a Nominatim y le entrega mensajes a Firebase. El visitante llega a los cuatro subsistemas porque la vitrina de planes (CU15) y el centro de ayuda (CU30) son públicos, igual que el catálogo. ## Subsistema de identidad y acceso ```mermaid flowchart LR visitante(["Visitante"]) usuario(["Usuario autenticado"]) subgraph sistema["Travia · Identidad y acceso"] cu01["CU01
Registrarse como viajero"] cu02["CU02
Registrar agencia
· desde el plan elegido ·"] cu03["CU03
Iniciar sesión"] cu04["CU04
Cerrar sesión"] cu05["CU05
Gestionar perfil"] pol["Validar política
de contraseñas"] aud["Auditar intento
de acceso"] evt["Comprobar unicidad
del legajo EVT"] end visitante --> cu01 visitante --> cu02 visitante --> cu03 usuario --> cu04 usuario --> cu05 cu01 -.->|include| pol cu05 -.->|include| pol cu03 -.->|include| aud cu02 -.->|include| evt ``` **`CU24` no está en este subsistema, y el motivo es una decisión de modelo.** Travia es un servicio por suscripción: una agencia se registra, contrata un plan y empieza a usarlo, sin que nadie la habilite. Sin una aprobación de por medio, la administración de agencias no tiene ningún vínculo con la identidad, y `CU24` es **supervisar el estado comercial de las agencias**: una lectura del negocio, que por eso vive en el subsistema de administración. **Lo que esa decisión deja en `CU02` conviene decirlo sin rodeos.** El alta comprueba que el legajo esté presente y que no pertenezca ya a otra agencia; **no valida su formato**, porque el registro de agentes de viajes es secuencial y sigue creciendo y una regla de largo fijo rechazaría agencias legítimas sin impedir que entre un número inventado. La verificación que sí serviría es una persona comparándolo con el registro público, y queda fuera del alcance: el legajo se guarda, se exige único y nadie comprueba que sea auténtico. El diagrama lo muestra tal cual —una sola inclusión, "comprobar unicidad"— en lugar de sugerir que el sistema hace la mitad de un trabajo que nadie hace. **Y esa puerta está antes del alta, no después.** El visitante es actor de `CU15` —la vitrina de planes es pública y no exige sesión—, así que el recorrido de una agencia nueva empieza en el precio: mira los planes, elige uno y desde ahí entra a `CU02` con ese plan ya elegido; creada la cuenta, el alta continúa en el pago sin cambiar de pantalla. Por eso `CU15` tiene dos actores y `CU02` dice de dónde viene. En el servidor el orden es el inverso y no puede no serlo —la suscripción pertenece a una agencia y el cobro necesita a quién cobrarle—, pero lo que viaja entre pantallas es el plan elegido y no una suscripción a medio hacer. Lo que reemplaza a esa puerta es **la suscripción**: `CU15` contrata el plan y `CU10` comprueba que esté vigente antes de publicar. Es una puerta comercial y no administrativa: una agencia se da de alta, contrata, publica, y todo eso queda decidido por su suscripción sin que nadie la autorice a mano en ningún paso. `CU24` **no tiene ninguna acción**: supervisa el estado comercial de las agencias y no modifica nada. Es la consecuencia visible de las dos decisiones que reemplazaron la puerta administrativa por la comercial: nadie aprueba agencias y nadie las suspende a mano. ## Subsistema de catálogo, búsqueda y compra ```mermaid flowchart LR visitante(["Visitante"]) viajero(["Viajero"]) mp(["Mercado Pago"]) plan(["Planificador"]) subgraph sistema["Travia · Catálogo y compra"] cu06["CU06
Explorar catálogo"] cu07["CU07
Buscar y filtrar paquetes"] cu08["CU08
Consultar detalle del paquete"] cu09["CU09
Buscar por cercanía"] cu18["CU18
Comprar paquete"] cu19["CU19
Pagar la orden"] cu20["CU20
Procesar notificación de pago"] cu21["CU21
Liberar reservas vencidas"] cu22["CU22
Consultar historial de compras"] cu23["CU23
Calificar paquete y agencia"] mapa["Mostrar mapa
del destino"] end visitante --> cu06 visitante --> cu07 visitante --> cu08 viajero --> cu09 viajero --> cu18 viajero --> cu22 viajero --> cu23 plan --> cu21 mp --> cu20 cu07 -.->|extend| cu09 cu08 -.->|include| mapa cu18 -.->|include| cu19 cu19 --> mp cu20 -.->|extend| cu18 cu23 -.->|requiere orden confirmada| cu22 ``` `CU21` no tiene actor humano: lo dispara el planificador cuando una reserva supera su tiempo de vencimiento sin pago confirmado. Está en el diagrama porque un caso de uso disparado por el sistema sigue siendo un caso de uso, y sin él la reserva de cupo quedaría retenida para siempre. ## Subsistema de publicación y gestión de la agencia ```mermaid flowchart LR visitante(["Visitante"]) agencia(["Agencia"]) osm(["Nominatim / OSM"]) administrador(["Administrador"]) subgraph sistema["Travia · Agencia"] cu10["CU10
Publicar paquete turístico"] cu11["CU11
Geocodificar destino"] cu12["CU12
Consultar sugerencia de precio"] cu13["CU13
Modificar paquete"] cu14["CU14
Despublicar paquete y deshacer"] cu15["CU15
Contratar o renovar suscripción"] cu16["CU16
Consultar panel de métricas"] cu17["CU17
Consultar cuenta y solicitar retiro"] cu28["CU28
Procesar solicitud de retiro"] limite["Verificar límites
del plan contratado"] end agencia --> cu10 agencia --> cu12 agencia --> cu13 agencia --> cu14 agencia --> cu15 visitante --> cu15 agencia --> cu16 agencia --> cu17 administrador --> cu28 cu10 -.->|include| cu11 cu10 -.->|include| limite cu10 -.->|extend| cu12 cu13 -.->|include| cu11 cu11 --> osm cu17 -.->|inicia| cu28 ``` `CU12` extiende a `CU10`: la agencia puede publicar sin mirar la sugerencia de precio, y también puede consultarla por separado sin estar publicando nada. Los límites del plan, en cambio, se verifican siempre, y por eso son una inclusión. ## Subsistema de administración y servicios transversales ```mermaid flowchart LR administrador(["Administrador"]) cualquiera(["Cualquier usuario"]) fcm(["Firebase Cloud Messaging"]) plan(["Planificador"]) subgraph sistema["Travia · Administración y transversales"] cu24["CU24
Supervisar el estado
comercial de las agencias"] cu25["CU25
Gestionar usuarios"] cu26["CU26
Gestionar planes"] cu27["CU27
Consultar dashboard administrativo"] cu29["CU29
Notificar al usuario"] cu30["CU30
Consultar centro de ayuda"] sit["Derivar la situación
de la suscripción"] end administrador --> cu24 administrador --> cu25 administrador --> cu26 administrador --> cu27 cualquiera --> cu30 plan --> cu29 cu29 --> fcm cu24 -.->|include| sit ``` `CU24` entra con flecha sólida como cualquier otro caso: **no tiene nada de provisorio**. Lo que sí tiene es una naturaleza distinta de la que se le suponía, y la inclusión lo muestra: la situación de cada agencia —activa, por vencer o suspendida por impago— **no se lee de ninguna columna, se deriva** comparando el período pago de su suscripción contra el reloj. Por eso el administrador no aprueba, no suspende y no reactiva: no hay nada que accionar sobre un valor que se calcula. Lo único que puede hacer es mirar, y eso alcanza para saber cómo está el negocio. De ese cálculo se desprende una consecuencia que conviene tener a mano: **la suspensión no la escribe nadie y la reactivación tampoco**. Una agencia que dejó de pagar aparece suspendida al día siguiente sin que corra ningún proceso, y vuelve a aparecer activa en el mismo instante en que contrata de nuevo. ## Resumen de casos de uso | Subsistema | Casos de uso | Cantidad | |---|---|---| | Identidad y acceso | CU01 a CU05 | 5 | | Catálogo, búsqueda y compra | CU06 a CU09, CU18 a CU23 | 10 | | Publicación y gestión de la agencia | CU10 a CU17, CU28 | 9 | | Administración y transversales | CU24 a CU27, CU29, CU30 | 6 | | **Total** | | **30** |