Caso práctico: gestión de FCT

Este es el caso práctico transversal del módulo de AD - Acceso a datos. A lo largo de las seis unidades didácticas construirás una misma aplicación que evoluciona cambiando su mecanismo de persistencia, sin reescribir la lógica de negocio.

Esta página conserva la guía pedagógica y enlaza las rúbricas. El repositorio maestro privado ad-practica-fct contiene el enunciado técnico, código de trabajo, datos, pruebas y solución consultable. Tu fork privado es la única evidencia de todo el módulo, con un cierre por unidad. Los ejemplos para experimentar están separados en ad-ejemplos. Los enlaces con TU_USUARIO son provisionales.

Objetivo del caso

Gestionar las prácticas en empresas (FCT) de un centro educativo: estudiantes, empresas, tutores, convenios y asignaciones. En cada unidad guardarás los datos con una tecnología distinta, manteniendo siempre el mismo dominio y un componente de persistencia sustituible.

El dominio

El caso trabaja con estas entidades:

  1. Estudiante: identificador interno, nombre ficticio, ciclo y curso.

  2. Empresa: identificador interno, nombre ficticio, localidad y tutores.

  3. Tutor de empresa: identificador, nombre ficticio y empresa.

  4. Oferta: identificador, empresa, capacidad y número de plazas ocupadas.

  5. Asignación: estudiante, oferta, tutor y fechas. Una asignación produce un documento de convenio; el documento no duplica la relación en el dominio.

  6. Documento de seguimiento: identificador, asignación, fecha y observaciones. Para estudiar herencia, usa dos subtipos: Informe y Incidencia.

Es un simulador didáctico de gestión de prácticas. Los nombres y reglas del caso no pretenden reproducir los trámites oficiales de la formación en empresa.

Las relaciones relevantes:

  1. Una empresa puede tener varios tutores (relación uno a muchos); una empresa sin tutores permite comprobar una colección vacía.

  2. Una empresa ofrece plazas; cada oferta puede tener varias asignaciones.

  3. Un estudiante puede tener asignaciones en periodos distintos.

  4. El tutor de una asignación debe pertenecer a la empresa de la oferta.

  5. Una dirección (localidad y código postal) será un valor compuesto sin identidad independiente, para comparar tipos estructurados y objetos.

Reglas que deben conservar las distintas persistencias:

  1. Identificadores únicos: A01, E01, T01, O01, AS01.

  2. Fecha inicial no posterior a la final.

  3. Capacidad positiva; ocupadas entre cero y capacidad.

  4. Asignar una plaza: comprobar disponibilidad, incrementar ocupadas y crear la asignación como una sola operación de negocio.

  5. No eliminar una empresa con asignaciones; devolver un error de dominio.

  6. Buscar un identificador inexistente devuelve ausencia, no una entidad vacía.

Datos de ejemplo

Usa siempre datos ficticios. No emplees datos personales reales de estudiantes ni de empresas. Usa identificadores internos y nombres como Estudiante A o Empresa A; no hacen falta DNI, teléfonos ni firmas.

Datos iniciales: Empresa A (E01), Tutor A (T01), oferta O01 de dos plazas, Estudiante A (A01, DAM) y Estudiante B (A02, DAW). Añade Empresa B sin tutores para probar una colección vacía y el rechazo de una asignación sin tutor.

Entorno y forma de trabajo

  1. Prepara el repositorio con Entorno de trabajo para el caso FCT.

  2. Usa GitHub para código, documentación y cambios; Codespaces para ejecutar las prácticas amplias. En clase bastan los fragmentos pequeños.

  3. Empieza por el ejemplo guiado de Ejemplo guiado: empresas en ficheros. Sus resultados son comprobaciones formativas, no entregas adicionales.

  4. Conserva el mismo cliente de consola y el mismo contrato; cambia el adaptador.

  5. Cada cierre recoge un commit identificable, instrucciones reproducibles, resultados esperados y observados, y autoevaluación con la rúbrica.

  6. La demo puede ser una ejecución comentada o un vídeo breve. Debe mostrar comportamiento observable, no sustituirse por capturas de código.

  7. Una entrega por unidad: reutiliza lo anterior y presenta los cambios de esa fase. La calificación se aplica según la programación vigente.

Completa una vez las prácticas comunes Git y GitHub y Codespaces como entorno de desarrollo. El maestro se amplía conforme se prepara el material; incorpora las novedades con upstream sin abrir otro fork por UD. Registra decisiones y procedencia en la bitácora.

Evolución por unidades

El caso se desarrolla de forma progresiva. En cada unidad sustituyes el mecanismo de persistencia, pero el dominio y el contrato se mantienen:

Unidad

Persistencia

Qué aporta al caso

UD1

Ficheros (JSON, CSV y XML de intercambio)

Primera persistencia, importación y exportación de datos

UD2

Base de datos relacional (conexión y estructura)

Esquema relacional del dominio

UD3

Base de datos relacional (operaciones)

CRUD, consultas y transacciones

UD4

ORM

Mapeo objeto-relacional

UD5

Bases de objetos

Persistencia de objetos estructurados

UD6

Base documental XML

Documentos XML y consolidación de componentes

Fase 1 (UD1): persistencia en ficheros

En esta primera fase guardarás los datos en ficheros y podrás intercambiarlos con otros sistemas.

Trabaja con dos estudiantes, dos empresas y sus tutores. Introduce una asignación sencilla con fechas y referencias válidas. Ofertas, ocupación transaccional y documentos de seguimiento se desarrollarán cuando correspondan; no es necesario implementar toda la gestión de prácticas en esta primera versión.

La preparación se hace durante las clases y el laboratorio. El cierre reutiliza esa base funcional para integrar, comprobar y documentar, no para empezar de cero.

Requisitos de la fase

La aplicación Java proporciona el dominio mínimo y el contrato. Completa la persistencia JSON y el intercambio CSV/XML en trabajo/, siguiendo el enunciado técnico de UD1. Los criterios de aceptación se comprueban con las mismas pruebas para trabajo y referencia.

El objetivo es conservar el estado, recuperarlo desde otra instancia, preservar las relaciones al intercambiar datos y gestionar los errores. CSV será una proyección del listado de asignaciones; el XML de esta fase intercambia empresas y tutores, no todo el estado de la aplicación.

Puedes consultar la solución comentada. Explica lo que reutilices y contrasta los resultados. No se crean tres casos independientes ni tres entregas: son comportamientos de una única práctica.

Criterios de calidad

  1. El componente debe gestionar los errores (archivo inexistente, datos inválidos) sin dejar la aplicación en un estado inconsistente.

  2. La escritura debe ser segura: no perder los datos anteriores si algo falla a mitad de proceso.

  3. El componente debe estar probado (casos normal, límite y error) y documentado (contrato, configuración y ejemplo de uso).

Entregable

Al final de la fase 1 debes entregar:

  1. El código del dominio y del componente de persistencia en ficheros.

  2. Un pequeño programa de demostración que ejecute las operaciones del contrato.

  3. Las pruebas que verifican el comportamiento del componente.

  4. La documentación de uso del componente.

Conserva todo en el mismo fork privado y completa el registro de cierre. Identifica el commit o etiqueta de entrega. Pruebas, documentación y demostración no generan notas independientes. Verifica tu trabajo con mvn -Pcontrato clean verify; -Psolucion comprueba la referencia.

Guion de demostración: guardar y cerrar; reabrir y consultar; modificar y releer; exportar CSV; convertir XML ↔ JSON; provocar datos inválidos y comprobar que permanece el fichero válido. Muestra una notificación emitida después del éxito.

Usa Primera versión persistente del caso FCT antes de trabajar y en la autoevaluación.

Nota

Esta fase es la base de todo el módulo. En las unidades siguientes sustituirás la implementación basada en ficheros por otras tecnologías, conservando el dominio y el cliente. Cualquier ampliación del contrato se documentará como parte de la evolución del mismo proyecto.

Fase 2 (UD2): conexión y estructura relacional

En esta fase prepararás el acceso relacional: elegirás el gestor y el conector, establecerás la conexión y crearás el esquema de tablas.

Trabaja a lo largo de las diez clases de Acceso a Bases de Datos; el cierre integra la base ya preparada. El enunciado técnico contiene versiones, comandos, correspondencia con UD1 y criterios de aceptación. La Preparación relacional del caso FCT está disponible antes de realizar la actividad.

Requisitos de la fase

  1. Utilizar dos gestores: SQLite embebido y PostgreSQL independiente como referencia de laboratorio. Ambos son entornos de desarrollo, no producción.

  2. Seleccionar y preparar el conector adecuado para cada gestor.

  3. Establecer la conexión desde la aplicación, con la configuración y las credenciales fuera del código.

  4. Diseñar el esquema relacional del dominio (estudiantes, empresas, tutores y asignaciones), conservando los identificadores de UD1. El convenio es un documento de la asignación, no otra tabla de la misma relación.

  5. Crear el esquema desde la aplicación mediante sentencias DDL.

  6. Preparar un entorno reproducible: un guion que cree y reinicialice la base de datos de pruebas.

  7. Comprobar tablas, columnas, tipos, nulabilidad, PK y FK; contrastar las restricciones con filas ficticias, no solo con una conexión válida.

  8. Preservar las filas al repetir la preparación; la reinicialización requiere un destino de pruebas y confirmación, y conserva tablas ajenas.

Contrato de persistencia

El contrato de la fase 1 se mantiene. En esta fase añades la infraestructura de acceso relacional, sin implementar todavía las operaciones de negocio (eso corresponde a la fase 3).

La preparación relacional es un contrato pequeño de infraestructura, no una implementación incompleta del repositorio de negocio. Completa la fábrica y el esquema de trabajo. Puedes consultar la referencia; identifica lo reutilizado y explica tus comprobaciones.

El devcontainer añade PostgreSQL como servicio del laboratorio al reconstruir Codespaces. Los ejemplos públicos usan un microesquema de dos tablas; la práctica privada conserva las cuatro del dominio actual. Las pequeñas inserciones de las pruebas verifican restricciones, no adelantan los métodos CRUD de la fase siguiente.

Entregable

Al final de la fase 2 debes entregar:

  1. La documentación de la decisión sobre gestores y conectores.

  2. La configuración de conexión (externa, sin credenciales en el código).

  3. El esquema relacional creado y comprobado en ambos gestores.

  4. El guion de preparación y reinicialización del entorno de pruebas.

Conserva código, configuración de ejemplo, pruebas y documentación en el mismo fork privado. Completa el registro común en docs/entregas/ud02.md y usa el commit con ud02-entrega para identificar la evidencia. Pruebas, demostración y autoevaluación no generan notas separadas.

Guion de demostración: crear y comprobar en SQLite; cerrar y reabrir; repetir en PostgreSQL; provocar una credencial inválida y corregirla; comprobar restricciones; detectar una preparación incompleta; reinicializar solo las tablas del caso y verificar que una tabla ajena permanece. Documenta resultado esperado, observado y corrección sin mostrar credenciales.

Usa mvn -Pcontrato-ud02 clean verify para SQLite y mvn -Pcontrato-ud02,postgresql clean verify para ambos gestores sobre tu trabajo. La aceptación de UD1 sigue disponible con -Pcontrato; completar UD2 no altera la evidencia de ficheros ya cerrada. -Psolucion comprueba la referencia.

Fase 3 (UD3): operaciones, consultas y transacciones

En esta fase completarás el acceso relacional con las operaciones de negocio.

Requisitos de la fase

  1. Implementar las operaciones del contrato (alta, consulta, modificación y eliminación) usando sentencias parametrizadas.

  2. Representar los resultados con objetos del dominio, sin acoplar la aplicación al conector.

  3. Gestionar el ciclo de vida de los recursos (conexiones, sentencias, resultados) también ante errores.

  4. Implementar transacciones para las operaciones que afectan a varios elementos: reservar una plaza en O01 y crear AS01. Provoca un error entre ambos cambios y verifica que no se conserva ninguno.

  5. Ejecutar un procedimiento almacenado sencillo desde la aplicación.

Entregable

Al final de la fase 3 debes entregar:

  1. El componente relacional completo, integrado y probado.

  2. La demostración de una transacción (confirmación y reversión).

  3. La documentación de uso del componente relacional.

Fase 4 (UD4): persistencia con ORM

En esta fase sustituirás el acceso directo por una herramienta de mapeo objeto-relacional, manteniendo el contrato y las garantías.

Requisitos de la fase

  1. Instalar y configurar una herramienta ORM con su conector.

  2. Definir el mapeo de las entidades (estudiantes, empresas, tutores y convenios), incluyendo al menos un fichero de mapeo explícito.

  3. Mapear relaciones y colecciones (empresa → tutores) y la jerarquía mínima DocumentoSeguimiento → Informe / Incidencia.

  4. Implementar las operaciones del contrato usando el ORM.

  5. Ejecutar consultas con el lenguaje del ORM y con SQL explícito.

  6. Gestionar transacciones con objetos persistentes.

  7. Encapsular el ORM en un componente que sustituya al de acceso directo.

Entregable

Al final de la fase 4 debes entregar:

  1. El componente basado en ORM, integrado y probado.

  2. La comparación razonada entre el acceso directo y el ORM.

  3. La documentación del mapeo y del componente.

Fase 5 (UD5): persistencia con objetos

En esta fase explorarás dos formas de almacenar objetos: un gestor objeto-relacional y una base orientada a objetos.

Requisitos de la fase

  1. Preparar dos entornos: un gestor objeto-relacional y una base orientada a objetos.

  2. Conectar y cerrar en ambos modelos.

  3. Persistir objetos simples y estructurados (p. ej. una empresa con su dirección y su lista de tutores).

  4. Consultar objetos en ambos modelos.

  5. Modificar y eliminar objetos, comprobando las referencias.

  6. Gestionar transacciones en los dos gestores.

  7. Encapsular el acceso en un componente con adaptadores para cada gestor.

Entregable

Al final de la fase 5 debes entregar:

  1. El componente de objetos, probado en ambos modelos.

  2. La comparación razonada de las dos soluciones.

  3. La documentación de uso del componente.

Fase 6 (UD6): persistencia documental e integración

En esta fase gestionarás los documentos del caso en una base documental nativa XML y consolidarás la integración de todos los componentes del módulo.

Requisitos de la fase

  1. Instalar y preparar un gestor de base de datos nativa XML.

  2. Conectar desde la aplicación.

  3. Organizar los documentos en colecciones (p. ej. convenios, informes).

  4. Crear y eliminar colecciones.

  5. Incorporar, modificar y eliminar documentos XML.

  6. Consultar documentos y nodos.

  7. Probar y documentar todos los componentes del módulo.

  8. Integrar y sustituir las persistencias sin reescribir el dominio.

Entregable

Al final de la fase 6 debes entregar:

  1. El componente documental, integrado y probado.

  2. La batería común de pruebas ejecutada sobre todos los componentes.

  3. La demostración de sustitución de persistencias con el mismo cliente.

  4. La documentación consolidada de todos los componentes del módulo.