[MÚSICA] [MÚSICA] [MÚSICA] [MÚSICA] ¿Cuántos préstamos puede hacer un usuario? >> Un usuario puede tomar prestado de acuerdo al perfil que tenga en su carnet. Si es un estudiante, puede tomar 20 libros por siete días si es un estudiante de pregrado, si es un estudiante de doctorado también por 30 días, 20 libros y eso depende del perfil que tenga el estudiante en ese momento. >> ¿Un usuario puede sacar un recurso por préstamo? >> Si claro, cada recurso es un préstamo, un recurso uno por uno se presta y ese es un préstamo individual que se hace cada recurso. >> ¿Cómo se identifican los diferentes recursos de la biblioteca? >> Bueno los recursos se identifican, nosotros tenemos un sistema de clasificación que se llama clasificación Dewey. Ese sistema de clasificación permite identificar los recursos a través de unos números de, que el sistema nos permite colocar para, de acuerdo a la temática del libro se clasifican, así en términos generales y también se coloca el número de identificación del autor, por unos números que nos permite una tabla que se llama, una tabla que permite identificar los números del autor. >> ¿Es importante guardar la historia de las multas? >> Sí, es muy importante para nosotros guardar la historia de las multas que generan, porque nos permite llevar un histórico sobre el, lo que se realizado en cuanto a multas de la persona, qué ha tenido, qué tipo de multas ha tenido y todo eso y también nos sirve como un back up para en caso de un reclamo o alguna cosa pues se tiene todo eso, ese historial. >> Bueno creo que esto resuelve las dudas que teníamos. >> Así es. Primero sabemos ahora que los recursos tienen el código Dewey y además de un código propio y yo creo que podemos modelarlos así solamente. Entonces un código Dewey que se puede cambiar internamente y un código según el tipo de recurso, que puede ser el ISDN, ISSN, el INDB y así sucesivamente. >> Esto será del tipo String porqué son letras y números. >> Exactamente, tanto el código Dewey como el código propio por esta razón. >> También podemos definir la cardinalidad entre préstamo y recurso. Entonces ahora sabemos con certeza que un préstamo sólo puede tener un recurso. Y un recurso puede estar asociado con varios préstamos. Pero fíjate que ahora que lo pienso, ¿será que es importante saber la copia exacta del préstamo? Creo que eso tendremos que volver con Alberto a precisarlo. >> Es cierto y adicional a esto hemos aclarado que lo mejor podría ser no tener una asociación compuesta entre usuario, biblioteca y préstamo. Al final de cuentas, el historial es importante y basta con una asociación simple, así que desde el préstamo podemos guardar la información adicional. >> Además la cardinalidad la podemos dejar como cero a muchas, you que habrá un número variable por tipo de usuario y podemos modelarla de esa forma. La lógica de la implementación queda completamente separada. >> Tienes razón y creo que a pesar de las diferentes preguntas que podamos tener todavía, en este punto podemos dar por terminado el ejercicio. Nuestro diagrama sólo puede ser leido de una única manera y este ejercicio de validar nuestro entendimiento con el cliente es muy común en este tipo de procesos de modelado. No siempre podemos suponer un respuesta y para ser precisos y abstraer correctamente la realidad, va a ser necesario acudir a nuestro cliente. >> Es posible entonces que si queremos detallar más elementos tengamos que volver con Alberto ha hacerle más preguntas. Pero esto es un buen final del ejercicio. >> A partir de aquí podemos empezar con otros ejercicios más complejos, pero en este punto you debes ser capaz de comprender y construir diagramas de complejidad variable y poder usar tus habilidades de abstraer y representar una realidad para ayudarte a modelar problemas en el contexto de desarrollo de software. >> Recuerda que los diagramas de clase de UML son una herramienta para modelar el entendimiento de un problema o para expresar el diseño de una solución. En este caso los hemos utilizado para lo primero. >> Si bien no hemos hecho un ejercicio completo de análisis de requisitos, hemos entrevistado a un representante del cliente y con base en sus respuestas, hemos construido un modelo, que validamos y completamos con él. Esta habilidad de abstraer y representar requiere de mucha práctica. >> Así que te invitamos a continuar con los ejercicios, practica mucho y hasta la próxima. [MÚSICA] [MÚSICA] [MÚSICA] [MÚSICA] [MÚSICA] [AUDIO_EN_BLANCO] [AUDIO_EN_BLANCO] [MÚSICA] [MÚSICA]
