Diseño > Persistencia
Información de la versión
| Proyecto: |
Herramienta de Gestión de Expediente |
| Número Interno de Versión: |
0.1.0 |
| Documentos Relacionados: |
LIGAS A ESTÁNDARES RELEVANTES
LIGAS A OTROS DOCUMENTOS
|
Overview
TAREAS: Responda a las preguntas que se encuentran abajo para ayudar a diseñar las características de persistencia necesarias.
Se muestran algunos ejemplos, añada o elimine texto según considere
necesario.
- ¿Cuáles son los hechos más importantes que un desarrollador debería conocer
sobre almacenamiento persistente de información de este sistema?
- PÁRRAFOS O VIÑETAS
- ¿Cuáles son los objetivos categorizados para persistencia en este sistema?
-
- Expresividad
- Facilidad de acceso
- Confiabilidad
- Capacidad de Datos
- Seguridad en los Datos
- Desempeño
- Interoperabilidad
Base de Datos Central
- ¿Cuál es la lógica en el diseño de la base de datos?
- El diseño lógico de la base de datos está descrita en este
modelo UML o en este diagrama ER (entidad/relación).
Las consideraciones lógicas adicionales a la base de datos son:
- Los estudiantes pueden repetir un curso (y obtener así dos registros para
el mismo curso en su boleta) si y solo si tienen una calificación
de "6.5" o menor, o el número del curso es 198, 199, 298 o
299.
- Una calificación mayor de "10" es válida solo para entradas de boletas durante o
después de otoño de 1990. Antes de esta fecha, la calificación másima posible es de
"10".
- CONSIDERACIÓN LOGICA QUE NO PUEDE SER EXPRESADA EN EL DIAGRAMA
- CONSIDERACIÓN LOGICA QUE NO PUEDE SER EXPRESADA EN EL DIAGRAMA
- ¿Cuáles son las tablas físicas y las vistas?
- el diseño de la base de datos física se describe en
este modelo UML o en este
href="LINK-TO-DIAGRAM">diagrama ER.
- ¿Cómo se almacenarán los objetos de la aplicación en la base de datos?
- Utilizaremos una tabla de la base de datos para cada clase, y una fila en la
base de datos para cada instancia persistente de esa clase.
- Utilizaremos una libreria para hacer nuestro
mapeo de objectos-relaciones. (Por ejemplo, torque, castor, JDO, ADO,
hibernate)
- ¿Qué controles de acceso a la base de datos se utilizarán?
- Una cuenta de usuario de la base de datos ha sido creadapara accesar
las tablas necesarias de la aplicación. El nombre del usuario y la contraseña para esta cuenta
se almacenna en un archivo de configuración que lee el servidor de aplicaciones.
La base de datos limita el acceso de ese usuario a solo las direcciones IP
usadas por el servidor de aplicaciones.
- ¿Pueden otras aplicaciones acceder a la base de datos central de la aplicación
?
- Sí. La base de datos es un punto importante de interoperabilidad para nuevas
aplicaciones que pueden ser añadidas más tarde. La misma base de datos provee
soporte para controles de acceso y revisa las consideraciones de validez para que
una aplicación defectuosa no pueda corromper la base de datos.
- No. esta base de datos deberá ser siempre accesada por medio de esta
aplicación. Todas las piezas de información relevante están disponibles
a través de las interfaces de la aplicación. la base de datos en sí no cuenta con
protección contra la corrupción de datos que pudieran causar otras
aplicaciones.
Almacenamiento de Archivos
- ¿Qué información necesita ser almacenada en archivos?
- No se almacena nada en archivos. Todo se encuentra en la base de datos.
- El servidor almacena la mayoría de la información en la base de datos, pero los archivos anexos
a la lista de correo son escritos en archivos en el disco duro del servidor.
- Todos los documentos de los usuarios son almacenados en el disco duro de su computadora.
- ¿Cuáles son las convesiones para la estructura de directorios y el nombrado de archivos?
- N/A
- Los archivos son almacenados en el servidor como
/var/data/attachments/msgNNNN-MMM.dat.
- Lo usuarios almacenan sus archivos en cualquier lugar de su computadora, con el nombre de archivo
y extension .TST.
- ¿Que controles de acceso al sistema de archivos se utilizarán?
- N/A
- Los archivos para mensajes adjuntos solo podrán ser leidos y editados por
el proceso de archivación de la lista de correos que utiliza el usuario del sistema
"archdaemon".
- Los usuarios pueden utilizar cualquier permiso sobre el archivo que deseen.
Almacenamiento Distribuido
- ¿Qué información (si existe) se guadará en los equipos del cliente?
¿Por cuánto tiempo?
- Una cookie se almacenará en el equipo del usuario con propósitos de
identificar una sesión del usuario. Cuando el usuario salga del sistema o cierre su
navegador, la cookie es eliminada. La mayoría de los navegadores ni siquiera
escribirán esta cookie en el disco.
- La cookie se almacena en el equipo del usuario y es equivalente a
su contraseña (pero no su contraseña REAL). Esta
cookie es necesaria para la caracerística de auto-login. La cookie dura un
maximo de 30 días y solo puede ser usada desde la misma dirección
IP.
- Las preferencias de color del usuario son almacenadas en cookies en su
navegador. Esta información no es delicada, así que se almacena indefinidamente.
- Toda la información del usuario es almacenada en archivos en sus
computadoras.
Lista de Pendientes de Mecanismos de Persistencia
- Expresividad: ¿hasta qué punto se ha logrado esto?
- 2-4 ORACIONES
- Facilidad de acceso: ¿hasta qué punto se ha logrado esto?
- 2-4 ORACIONES
- Confiabilidad: ¿hasta qué punto se ha logrado esto?
- 2-4 ORACIONES
- Capacidad: ¿hasta qué punto se ha logrado esto?
- 2-4 ORACIONES
- Seguridad: ¿hasta qué punto se ha logrado esto?
- 2-4 ORACIONES
- Desempeño: ¿hasta qué punto se ha logrado esto?
- 2-4 ORACIONES
- Interoperabilidad: ¿hasta qué punto se ha logrado esto?
- 2-4 ORACIONES