Guia PES

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.

Obligatorio · Fag-2 y sprints

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.

Usuarioemail: Stringnombre: StringfechaAlta: FechaTrayectoid: Naturalinicio: FechaHorafin: FechaHorakm: RealEstaciónid: Naturalnombre: Stringubicación: CoordenadabicisLibres: NaturalInsignianombre: Stringdescripción: Stringpuntos: Natural1*hace ▸*1origen*0..1destino**consigue ▾**favoritasRestricciones de integridadRI1. Claves: (Usuario, email), (Estación, id), (Trayecto, id)RI2. fin > inicioRI3. km >= 0RI4. El destino, si existe, es distinto del origenViene de los datos abiertosConcepto nuevo del equipo
Fijaos: solo Estación viene de los datos abiertos. Trayecto e Insignia son conceptos nuevos del equipo, y ahí está el valor del producto.
Restricciones de integridad siempre debajo del diagrama, numeradas: claves y reglas que el diagrama no puede expresar.
Opcional · recomendado

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é.

ServicioEstaciónes- memoria: Estación[*]+ cercanas(p: Posición): Estación[*]+ refresca()«interface»FuenteEstaciónes+ obtenerEstaciónes(): Estación[*]AdaptadorOpenDataBCN+ obtenerEstaciónes(): Estación[*]AdaptadorCSV+ obtenerEstaciónes(): Estación[*]FuenteFalsa+ obtenerEstaciónes(): Estación[*]1Patrón Adapter: el dominio no depende del formato de los datos abiertos. Cambiar de fuente (API, CSV, mock) no toca ServicioEstaciónes.
Obligatorio · Fag-2 y sprints

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.

ClientesServicios externosApp móvilFlutter · Android · iOSWeb de administraciónFlutter WebEquipo Cconsume nuestro servicioGoogle Maps · Sign-InSDK dentro de la appNAT de la FIBnattech.fib.upc.edu:40330 → VM :8080Cloudflare TunnelHTTPS (opcional)HTTP · JSONvirtech · FIBMáquina virtual Ubuntu · OpenNebulaDocker ComposeNginx:8080 · proxy inversoAPI RESTNode.js + Express:3000 · /api/v1 · /docsRediscaché y sesionesPostgreSQL + PostGIS:5432Volumen uploads/imágenes de los usuarios:8080/apiSQLGitHub Actions runner (self-hosted)git pull · docker compose up -ddespliegaSin copias de seguridad: todo se tiene que poder recrear desde GitHubOpen Data BCNBicing (GBFS) · JSONServicio del equipo BREST · lo consumimosFirebase Cloud Messagingnotificaciones pushGETRESTpushnotificación pushGitHubrepos front y back · CIconexión saliente:el runner pide trabajopetición (HTTP, SQL)CI/CD y desplieguenotificación push
Opcional

Diagrama de componentes (UML)

Una visión simplificada de todo el sistema y de las relaciones entre componentes.

«subsystem» App«UI» Mapa«UI» Perfil:ClienteREST«subsystem» API REST:Estaciónes:Trayectos:Autenticación«subsystem» Servicios externos:Open Data BCN:Servicio del equipo B/api/v1
Obligatorio · sprints

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.

usuarioPKemail VARCHARnombre VARCHARfechaAlta DATEtrayectoPKid SERIALFKemail VARCHARFKorigen INTFKdestino INT NULLinicio TIMESTAMPfin TIMESTAMPkm NUMERICestaciónPKid INTnombre VARCHARgeom GEOGRAPHY(Point)bicisLibres INTusuarioinsigniaPKemail VARCHARPKnombre VARCHARfecha DATEinsigniaPKnombre VARCHARdescripción TEXTpuntos INTPKclave primariaFKclave foránea →
El esquema cambiará en cada sprint: gestionad su evolución con ficheros SQL de create y alter o con un framework de migraciones (Liquibase, migraciones de Django o de Laravel, mysql-migrations para Node). Más aspectos técnicos →

Errores típicos en los modelos