Modelos
Los diagramas que se piden, con un ejemplo completo
Lo ágil no gira alrededor de los modelos, pero algunos aportan mucho y forman parte de la documentación. Todos los ejemplos son de una misma app inventada que complementa el Bicing con datos de Open Data BCN.
Modelo conceptual (diagrama de clases UML)
Los conceptos principales del problema, independientes de la arquitectura y de la tecnología. Se valora que haya conceptos creativos y propios, no solo los del conjunto de datos abiertos.
UML: Usuario, Trayecto, Estación, Insignia: Usuario; email: String; nombre: String; fechaAlta: Fecha; Trayecto; id: Natural; inicio: FechaHora; fin: FechaHora; km: Real; Estación; ubicación: Coordenada; bicisLibres: Natural; Insignia; descripción: String; puntos: Natural; 1; *; hace ▸; origen; 0..1; destino; consigue ▾; favoritas; Restricciones de integridad; RI1. Claves: (Usuario, email), (Estación, id), (Trayecto, id); RI2. fin > inicio; RI3. km >= 0; RI4. El destino, si existe, es distinto del origen; Viene de los datos abiertos; Concepto nuevo del equipo.
Diagrama de clases de la capa de dominio
La lógica de la solución dentro de una arquitectura en tres capas, ya con patrones de diseño aplicados y operaciones. Explicad qué patrones usáis y por qué.
UML: Adapter: ServicioEstaciones; - memoria: Estación[*]; + cercanas(p: Posición): Estación[*]; + refresca(); «interface»; FuenteEstaciones; + obtenerEstaciones(): Estación[*]; AdaptadorOpenDataBCN; AdaptadorCSV; FuenteFalsa; 1; Patrón Adapter: el dominio no depende del formato de los datos abiertos. Cambiar de fuente (API, CSV, mock) no toca ServicioEstaciones.
Diagrama físico (arquitectura)
Los nodos y subsistemas del sistema: app, servidor, base de datos, servicios externos y el servicio que hacéis para otro equipo. Un esbozo en la incepción que vais refinando en cada sprint.
Physical architecture: Flutter clients and team B through the FIB NAT, virtech VM with Docker (Nginx, Node.js, PostgreSQL, Redis), Open Data BCN, team C service, Firebase, GitHub Actions: Clientes; Servicios externos; App móvil; Flutter · Android · iOS; Web de administración; Flutter Web; Equipo B; consume nuestro servicio; Google Maps · Sign-In; SDK dentro de la app; NAT de la FIB; nattech.fib.upc.edu; :40330 → VM :8080; Cloudflare Tunnel; HTTPS (opcional); virtech · FIB; Máquina virtual Ubuntu · OpenNebula; Docker Compose; Nginx; :8080 · proxy inverso; API REST; Node.js + Express; :3000 · /api/v1 · /docs; Redis; caché y sesiones; PostgreSQL + PostGIS; :5432; Volumen uploads/; imágenes de los usuarios; GitHub Actions runner (self-hosted); git pull · docker compose up -d; Sin copias de seguridad: todo se tiene que poder recrear desde GitHub; Open Data BCN; Bicing (GBFS) · JSON; Servicio del equipo C; REST · lo consumimos; Firebase Cloud Messaging; notificaciones push; GitHub; repos front y back · CI; HTTP · JSON; SDK; :8080; /api; SQL; despliega; GET; REST; push; notificación push; conexión saliente:; el runner pide trabajo; petición (HTTP, SQL); CI/CD y despliegue; Cada flecha va de quien hace la petición a quien la recibe.
Diagrama de componentes (UML)
Una visión simplificada de todo el sistema y de las relaciones entre componentes.
UML component diagram: «subsystem» App; «UI» Mapa; «UI» Perfil; :ClienteREST; «subsystem» API REST; :Estaciones; :Trayectos; :Autenticación; «subsystem» Servicios externos; :Open Data BCN; :Servicio del equipo C; /api/v1.
Esquema de la base de datos
Un diagrama de clases que describe el esquema. En relacional, la clave primaria subrayada y las foráneas entre paréntesis (FK). En NoSQL, usad composición para los documentos incrustados y asociación para las referencias.
Relational schema (PostgreSQL): usuario; PK; email VARCHAR; nombre VARCHAR; fechaAlta DATE; trayecto; id SERIAL; FK; origen INT; destino INT NULL; inicio TIMESTAMP; fin TIMESTAMP; km NUMERIC; estación; id INT; geom GEOGRAPHY(Point); bicisLibres INT; usuarioinsignia; fecha DATE; insignia; descripción TEXT; puntos INT; clave primaria; clave foránea →.
Errores típicos en los modelos
- Poner tecnología en el modelo conceptual (tipos SQL, IDs autoincrementales, "Controller").
- Usar un atributo donde debería haber una asociación (un
idEstaciondentro de Trayecto). - Olvidar las multiplicidades o las restricciones de integridad textuales.
- Un modelo que es una copia de las columnas del conjunto de datos abiertos.
- Diagramas que no se actualizan cuando cambia el código: forma parte de la definición de hecho.
- Capturas borrosas: exportad en SVG o PNG con buena resolución.