[Php-avanzado] Bibliotech: SRS v6.4.2 y DER v1.3.1

Vie Ene 17 14:06:42 ART 2014

Hola Pehúen,

El vie, 17-01-2014 a las 12:33 -0300, Fernando Pehuén Borsani escribió:
> Hola Profe, tengo algunas consultas sobre su respuesta:
> 
> LT>ahora que los Empleados son una Funcionalidad, sería tal vez útil
> registrar qué empleado presta un libro y qué empleado lo recibe...
> LT>permitiría hacer un mejor seguimiento de los libros en relación con los
> empleados que los manejan.
> 
> Las RF 24 a 27 terminan con las frases "empleado[22] que recibe la unidad "
> o "empleado[22] que da de baja la unidad " en la versión que le envié.
> ¿Su comentaría significa entonces que debo desdoblarlas en nuevas
> funcionalidades?

	Me lo pasé por alto en los RF.
	Mi comentario era porque no está reflejado esto en el almacenamiento...
Siendo funcionalidades, tenés estos datos como faltantes.

> LT> Creo que hay "estados" de diferentes cosas en este problema, pero hasta
> ahora se muestra todo junto. Fijate en el diccionario las veces que se hace
> referencia a un "estado" y "activo o anulado" que son los estados de un
> préstamo tiene sentido, pero no al lado de "destruida o en mantenimiento",
> que creo que no deberían ser estados válidos de un préstamo...
> 
> Sobre la cuestión de los estados, discusión que ya tuvimos, yo quisiera
> hacerlo de esta manera:
> El préstamo tiene tres estados, que son "activo", "devuelto en fecha" y
> "devuelto vencido". Esta descripción en la SRS implicaría que si se cargan
> mal los datos y se quiere cancelar el tramite el sistema lo permite,
> borrando el registro (el dato del préstamo anulado no tiene valor alguno, a
> diferencia de lo que pasaría con una factura).

	Ok. Podríamos llamar a esto "Estados de Préstamos"
	Sin embargo el borrado, en caso de querer hacer esto, es condicional,
ya que no se debe poder borrar un Préstamo de una unidad que fue
devuelta o que fue a adquisiciones o que fue a mantenimiento.
	Estas condiciones es importante que estén en la SRS.

> Las devoluciones, extravíos y reposiciones no deberían tener estado, porque
> su mera existencia revela el estado en que se encuentran. Lo susodicho sobre
> anulaciones también valdría aquí.

	Ok. No te lo podía afirmar porque los "estados" aparecen mezclados.
	Qué hace este sistema si alguien registra una
devolución/extravío/reposición mal? Entiendo que la biblioteca es ideal,
pero las personas que la usan no, por lo que se equivocarán,
generalmente sin intención y a veces a propósito.

> Mantenimiento tendría tres estados: "activo", "reparado" y "destruido".

	Ok. Podríamos llamar a esto "Estados de Mantenimientos.

	A lo que iba, es que siendo los estados diferentes, no hay en este
problema un solo "estado" sino dos dos entidades que reflejan estados, y
por tanto deben separarse y tener nombres distintos para evitar la
ambigüedad.

	Actualmente aparece un solo "estado" y eso es lo que genera
confusiones...

> Entonces me quedaría una relación así en la SRS:
> 23) El sistema debe registrar el préstamo de unidades[05] a asociados[15]
> con su estado[20] y empleado[22] que entrega la unidad.
> 24) El sistema debe registrar devoluciones de unidades[05] por parte de los
> asociados[15] con el empleado[22] que recibe la unidad.
> 25) El sistema debe registrar extravíos de unidades[05] por parte de los
> asociados[15] con el empleado[22] que da de baja la unidad.
> 26) El sistema debe registrar reposiciones de unidades[05] por parte de los
> asociados[15] con el empleado[22] que recibe la unidad.
> 27) El sistema debe registrar el mantenimiento de unidades[05] con su
> estado[20], empleado[22] que entrega la unidad y empleado[22] que recibe la
> unidad.
> Diccionario:
> Estado: refleja en que parte del proceso se encuentra la unidad entregada a
> un asociado o a mantenimiento. Los estados pueden ser: activo, devuelto en
> fecha, devuelto vencido, reparado, destruido.

	Acá se evidencia el error en la definición. Lo que decís tiene sentido
si el Estado es de la Unidad, pero esto es falso. En tu SRS lo que tiene
Estado es el Préstamo y el Mantenimiento.
	Como el Préstamo y el Mantenimiento no tienen los mismos Estados, ergo
son entidades diferentes.

> Y la relación (resumida) entre tablas quedaría así
> PRESTAMOS: idEstado <-- ESTADOS --> MANTENIMIENTO: idEstado

	Esto viola las formas normales por todo lo expuesto arriba.

> La ventaja más significativa de esta implementación de los estados es la
> practicidad. Por ejemplo: si quiero que el sistema me muestre todos los
> préstamos activos, entonces la query trae todos los préstamos con estado
> "activo".

	Los estados tienen su justificación para existir definida en el
problema, y por tanto al no estar puestos "por practicidad" sino "por
necesidad", la consideración es real pero irrelevante: no podés sacar
los Estados aunque el las querys queden "menos prácticas" porque
entonces el software no refleja el problema que hay que resolver.

> Pienso en esto porque una vez nos contó que no siempre es práctico
> normalizar al 100%.

	Es cierto, pero acá te faltan entidades en la SRS (los diferentes
Estados), y una vez que aparezcan, para guardarlos, no te va a quedar
más alternativa ponerlos en algún lado, y la más práctica va a ser
normalizando.
	Otra vez estoy de acuerdo con vos en que no siempre es práctico
normalizar al 100%, pero todavía estamos ajustando la SRS sacando
Estados de dónde no tienen sentido y poniendo los necesarios para que
seto funcione.

> LT> Antes de que me olvide: cuando terminemos la normalización, te digo los
> RF que te voy a pedir que me entregues.
> Me alegro que mencione esto, porque significa que algún día vamos a terminar
> la normalización ;-)

	Una vez me dijo un profesor: con tiempo infinito todos los trabajos
tienden a 10.
	Además de terminarlo, lo ideal sería terminar todo para el fin de este
curso ;-)
	Tienen además una rara oportunidad: al diferir el fin de curso están
teniendo un mes y medio más que otras comisiones para terminar el
trabajo en fecha.

> Me causó mucha gracia el comentario a Gabriel sobre la manzana lustrada para
> el profesor. Le diría que cuando leo las correcciones a veces pienso "claro,
> tiene sentido", a veces "bueno, si Tadei lo dice", y otras veces "Tadei
> trata a mi biblioteca como si fuera un software de facturación."
> ¡Manzana con gusanito! jajaja

	A mi me causa gracia que te refieras a mi como "Tadei"... me hace
acordar al secundario, cosa que no te beneficia porque en promedio no
fue una experiencia agradable.

	Volviendo a tu biblioteca: hacemos software para registrar y controlar,
sabiendo que funcionará en un entorno lejano a la más tosca
idealización. Si el software no registra (porque permite alteraciones y
borrados) y no controla (porque cambia el pasado o genera
inconsistencias) no sirve para nada... ni para usarlo ni para aprender a
escribir software.
	Mi idea es que aprendan a hacer software que sirva.

	¡Aliento insecticida! jajaja!

-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
Web: http://leonardo.tadei.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key