Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GearSolid GearSolid
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3
    • Issues 3
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GuerreroDIM46
  • GearSolidGearSolid
  • Wiki
    • Documentacion
  • Diagramas de clases y modelo de datos

Last edited by Rodrigo de Dios García Apr 17, 2024
Page history
This is an old version of this page. You can view the most recent version or browse the history.

Diagramas de clases y modelo de datos

Diagrama de clases:

Diagrama de clases

  • Existen dos tipos de objetos usuario, que heredan de la clase Usuario. Las instancias de la clase UsuarioBaja se crearán desde el método bajaUsuario de Usuario. Este método elimina el UsuarioAlta correspondiente y genera un UsuarioBaja, además actualiza la instancia unidad familiar vinculada al Usuario cambiando su estado a baja. Por otra parte por ley de protección de datos se eliminan todos los datos personales del Usuario (en el futuro esto podría depurarse para permitir mantener algunos datos a efectos de cumplimiento de deber legal pero queda fuera del alcance del proyecto)
  • La generación en el front de una unidad familiar implica su asignación inmediata al usuario correspondiente. Esto evita que existan unidades familiares vacías. La unidad familiar sólo se puede crear desde el método set UnidadFamiliar de Usuario. Este método debe asegurarse de crear la unidad familiar si no existe y de asignarla al Usuario desde la que se está creando ( esto supone que inicialmente la unidad familiar de un Usuario puede estar vacía.). El método setUnidadFamiliar también permite modificar la unidad familiar. En este caso si la unidad anterior se queda sin miembros este método debe eliminar la instancia.
  • Los estado de unidad familiar pueden ser Alta o Baja.
  • El estado de un compromiso puede ser pendiente asiste o no asiste.

Modelo de datos:

Modelo de datos

 


Volver arriba

home

Clone repository

GearSolid


Fase de concepto (Presentación)

1. Estudio de Viabilidad del Sistema (EVS)

  • Análisis del problema
  • Mind Map
  • Impact Map
  • Requisitos
  • Alternativas
  • Matriz de Cumplimiento de Requisitos
  • Matriz de decisión

2. Especificación de Requisitos de Software (ERS)

  • Planificación General
  • Diagrama de Clases y Modelo de Datos
  • Interfaz de Usuario

3. Producto Mínimo Viable (MVP)

  • Definición del MVP

Preproducción

1. Sprint 1

2. Sprint 2