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.
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.
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é.
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.
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.
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
Poner tecnología en el modelo conceptual (tipos SQL, IDs autoincrementales, "Controller").
Usar un atributo donde debería haber una asociación (un idEstacion dentro 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.