Reunión #5 — Diseño UML + Figma

01 Objetivos de la sesión

Puntos que se revisaron y acordaron durante la reunión con el director.

Revisar los diseños UML elaborados: diagrama de casos de uso (administrador / operario) y diagramas de secuencia de entrada y salida de inventario.
Revisar el modelo de datos: diferenciar el diagrama relacional del entidad-relación y definir cuál se conserva como evidencia.
Revisar los prototipos de interfaz: la preview generada en Google AI Studio (React + TypeScript + Tailwind) y los mockups de Figma.
Definir cómo documentar la especificación de requisitos en el formato IEEE 830 dentro del documento técnico.
Organizar el documento técnico de evidencias que centraliza el contenido del proyecto hacia el documento final.

02 Decisiones y acuerdos

Acuerdos tomados durante la sesión. Cada punto refleja lo que se revisó o definió con el director.

1. Diseño UML — casos de uso (administrador / operario)

Se revisó el diagrama de casos de uso modelado en UML. El administrador concentra todas las operaciones —autenticarse, consultar el stock actual, registrar entrada de lote, registrar salida de material y consultar los vencimientos bajo FEFO (primero en entrar, primero en salir)— y, a diferencia del operario, además administra usuarios. Se acordó que por ahora un único diagrama de casos de uso es suficiente y que estos se dejan al final; si se requiere, se ampliarán más adelante.

2. Diagramas de secuencia — entrada y salida de inventario

Se revisó el diagrama de secuencia de entrada de datos: se ingresa por la interfaz, se envía la solicitud de registro y, cuando los datos son inválidos, se devuelve un error de validación, se notifica al sistema y se muestra el mensaje de error. Se definió que el diagrama de salida contempla más condiciones y dos alertas distintas (datos inválidos y stock insuficiente), mientras que la entrada solo deriva en error por datos inválidos.

3. Modelo de datos — relacional vs. entidad-relación

Se revisaron dos versiones del modelo de datos generadas con Mermaid. Se aclaró que el diagrama producido corresponde a un modelo relacional (físico), distinto del entidad-relación. Se acordó conservar el más claro y dejar explícito ante el evaluador qué es cada uno, priorizando que el diagrama sirva como evidencia válida del diseño de la base de datos.

4. Prototipos de UI — baja vs. alta fidelidad

Se revisó la preview generada en Google AI Studio a partir de fragmentos del proyecto: una UI avanzada hecha en React + TypeScript + Tailwind CSS, aún no funcional (los controles de cerrar y de añadir ítems no operan todavía). Se acordó titularla como "Wireframes de baja fidelidad" y reservar el rótulo de "Wireframes / mockups de alta fidelidad" para los diseños de Figma. Se definió que el prototipo puede migrarse posteriormente a PHP.

5. Especificación de requisitos — formato IEEE 830

Se definió incorporar los requerimientos en el formato IEEE 830 dentro de la sección correspondiente del documento técnico, junto con las explicaciones de los diagramas UML y de secuencia que por ahora estaban solo descritas verbalmente.

6. Documento técnico de evidencias

Se acordó mantener un documento estructurado (plantilla de almacenaje de contenido técnico) como repositorio único de los diagramas, requisitos y evidencias del proyecto, de modo que sirva de base para consolidar el documento final.

03 Evidencias

Archivos reales del repositorio que respaldan el diseño revisado en la reunión.

Archivo	Descripción
`docs/DIAGRAMAS_UML.md`	Diagrama de casos de uso (administrador / operario) y diagramas de secuencia de entrada y salida, en Mermaid.
`docs/CASOS_DE_USO.md`	Detalle de los casos de uso del sistema y sus actores.
`docs/MER_ACTUALIZADO.md`	Modelo entidad-relación del inventario (entidades, atributos y relaciones).
`docs/DIAGRAMA_RELACIONAL.md`	Diagrama relacional (modelo físico) diferenciado del entidad-relación.
`docs/DATA_DICTIONARY.md`	Diccionario de datos que acompaña al modelo.
`docs/ARCHITECTURE.md`	Documento de arquitectura del sistema.
`docs/REFERENCIAS.md`	Referencias del proyecto (base para la especificación IEEE 830).
`database/migrations/2026_01_02_000000_create_materials_table.php`	Entidad Materiales del modelo de datos.
`database/migrations/2026_01_03_000000_create_lotes_table.php`	Entidad Lotes — soporte del control FEFO por vencimiento.
`database/migrations/2026_04_16_000001_create_bodegas_table.php`	Entidad Bodegas — relación lote ↔ bodega.
`database/migrations/2026_04_16_000003_create_movimientos_table.php`	Entidad Movimientos — entradas / salidas de inventario.
`app/Models/Material.php` · `Lote.php` · `Bodega.php`	Modelos Eloquent con relaciones — reflejan las entidades del modelo de datos.
`app/Models/Movimiento.php`	Modelo que representa el flujo de entrada/salida del inventario.
`docs/screenshots/figma-settings-model-cards.png`	Mockup de alta fidelidad en Figma de la pantalla de configuración.
`docs/screenshots/pruebas/01-login.png` · `02-registro.png`	Pantallas de login y registro derivadas de los mockups de Figma.

Prototipo de baja fidelidad generado en Google AI Studio (React + TypeScript + Tailwind CSS) a partir de fragmentos del repositorio de GitHub.

04 Tareas asignadas

Tareas acordadas para la siguiente semana sobre la fase de diseño.

#	Tarea	Estado
1	Pasar a texto las explicaciones de los diagramas (casos de uso y secuencia) dentro del documento técnico.	Asignada
2	Agregar los requerimientos en formato IEEE 830 en la sección correspondiente del documento.	Asignada
3	Titular los prototipos: "Wireframes de baja fidelidad" (Google AI Studio) y "Wireframes / mockups de alta fidelidad" (Figma).	Definida
4	Consolidar el diagrama relacional / entidad-relación definitivo y dejarlo etiquetado como evidencia.	Asignada
5	(Opcional) Ampliar los casos de uso si el evaluador lo requiere más adelante.	Opcional

Notas de la sesión

Se trabajó en vivo sobre el repositorio de GitHub mostrando los diagramas ya diseñados. Se revisó la preview generada en Google AI Studio, que parte de fragmentos del proyecto y produce una UI muy avanzada en React + TypeScript + Tailwind CSS, aunque todavía no es funcional. Se acordó incorporar al documento técnico, además de los diagramas, la especificación de requisitos en formato IEEE 830, y conservar la plantilla de evidencias generada con Gemini como repositorio del contenido técnico hacia el documento final.

← Reunión #4 Índice Reunión #6 →