[MÚSICA] [MÚSICA] Hola y bienvenidos. Recordemos que, a partir de la información de la entrevista, vamos a construir un modelo del mundo del problema. No estamos diseñando el sistema de información, lo que queremos es validar nuestro entendimiento del problema, y, eventualmente, identificar vacíos que debemos aclarar. >> Empecemos discutiendo los diferentes elementos que debemos identificar y que serán nuestras clases del mundo. En primer lugar, los recursos. Alberto, el coordinar de servicios de la biblioteca, menciona varias veces la palabra recurso, e incluso dentro de los objetivos de la biblioteca está, justamente, el no perderlos, y que sus usuarios tengan oportuno acceso a ellos. Así que, lógicamente, esta será nuestra primera clase. >> En segundo lugar, pues están los prestamos. Los prestamos es cómo los usuarios acceden a los recursos. Un usuario pide un préstamo para sacar recursos. you sean libros, vídeos, etcétera. >> Creo que aquí es claro, que otro de los conceptos sería los usuarios de la biblioteca. Es una muy buena práctica llamarlo usuario biblioteca para no tener confusiones con la palabra usuario, que puede ser bastante común en este tipo de contexto de desarrollo. >> Me parece muy bien. Finalmente, tenemos el concepto de la multa. La información de las multas le sirve a la biblioteca, y para mí, es claro que debemos guardar esta información. >> Bien, con esto, tenemos nuestras cuatro clases y ahora vamos a revisar los diferentes atributos. Bien, pues miremos los recursos, normalmente estos vienen identificado. Creo que uno es el ISBN que se usa para los libros, ¿no? >> Sí, pero el ISBN es solo para los libros. Es un identificador internacional, pero ¿y lo otros recursos? Las películas, los juegos, los vídeos. >> Hum, eso parecía algo que deberíamos preguntarle a Alberto. Es una información sobre la que necesitamos más claridad, para poder modelar los recursos de manera más precisa. Entonces, ¿De qué manera se identifican los recursos en la biblioteca? >> Tenemos más atributos. Tenemos el nombre de recurso, las copias que tiene disponibles y, además, debemos crear los métodos para retornar esos valores. >> Viene ahora algo importante. Según lo que dijo Alberto, podemos tener recursos electrónicos, impresos y audiovisuales. Yo obviaría los electrónicos, porque no se prestan para llevar, y por lo tanto, están fuera del contexto del sistema de préstamos de la biblioteca, pero me pregunto, si sería valido modelar los otros tipos de recursos como subclases y hacer que recursos sea una super clase abstracta. >> Podría ser, pero en realidad, no me parece muy útil, porque no es claro de que manera estas subclases especializarán la clase de recursos. Hay información que es general a los recursos, independientemente de su tipo, y es posible, que para este sistema esto sea suficiente. ¿No será mejor una enumeración? >> Me parece bien. Creamos, entonces, una enumeración para el tipo de recurso y, ahora, dos literales. Impreso y audiovisual, y además, tenemos que crear un método para retornar el tipo de recurso. Tampoco creo que sea lógico crear un método que cambie el tipo. Un recurso impreso, después de todo, siempre será impreso y uno audiovisual siempre será audiovisual. Con esto, creo que podemos pasar a los atributos del préstamo. >> Bueno, es obvio que necesitamos para el préstamo saber, ¿cuándo comenzó?, es decir, la fecha de inicio, y la fecha cuándo el usuario biblioteca devuelve el préstamo, es decir, la fecha de devolución. >> Necesitamos también un método que calcule la fecha de vencimiento del préstamo, o la fecha máxima, a la cual, se puede hacer una devolución sin incurrir en una multa. Y un método que retorne, justamente, los valores de la fecha de inicio y la fecha de devolución. >> Sí, sí. Y creo que no hay mucho más. >> Miremos, entonces, ahora las multas. Los atributos de las multas serían un valor y dos métodos. Uno para retornar ese valor y otro para cambiarlo. >> Según cómo se cobre, ese valor va a cambiar, claro está. >> Exactamente. Vamos, entonces, a mirar el usuario de la biblioteca. Basados en la descripción, necesitariamos un carnet, asumiendo que se tiene una serie de números como identificación. Necesitamos también un método para verificar que le usuario es valido y puede hacer préstamos. Es probable, que este método requiera acceder al sistema de autenticación de la universidad. >> Aquí podemos de plantearnos la pregunta de si ¿vale la pena crear una jerarquía sobre los tipos de usuarios? Creo que bajo la misma lógica de recurso, tiene poco utilidad. Porque un usuario you sea estudiante de pregrado, egresado, profesor, empleado o externo, si tiene un carnet válido, se le presta el recursos. >> Entonces, ¿sería una enumeración? >> Sí, para tipo, usuario y you. Son muchos literales, claro está, pero más allá de la clasificación no hay nada que especialice a las clases para el contexto de nuestro problema. Ahora, esto lo podemos modelar como un atributo de tipo enumeración y agregar un método para dar el tipo y otro para cambiarlo. Cosa que puede pasar y que es una razón adicional para no modelar esto como una herencia. >> De acuerdo. Entonces, los métodos retornan los valores y, además, algo que nos indique si se puede hacer un préstamo. >> Así es. Ahora algo que tenemos que mirar con cuidado. Alberto habló de préstamos de reserva y, también, préstamos a domicilios, como dos modalidades distintas, ¿será otra enumeración? >> No, mira que aquí si hay un interés en modelar esto de otra forma, porque el vencimiento de los préstamos de reserva tiene otra manera de calcularse y los préstamos a domicilio van a tener unos costos asociados que tienen ver con los envíos y que tenemos que modelarlos como atributos. Así que te propongo que usemos aquí una herencia. >> Sí, claramente estos tipos de préstamos si tienen información y métodos adicionales El préstamo de domicilio tiene información de la dirección, y el costos de los envíos y, también, de la devolución. >> Adicionalmente, el préstamo reserva tendrá que reimplementar el método calcular fecha vencimiento, debido a las reglas que se proponen. Entonces, como consecuencia, tenemos que cambiar la visibilidad del atributo fecha inicio y fecha devolución de privados a protegidos. >> La fecha de vencimiento del préstamo depende del tipo de usuario. ¿Será entonces que debemos especializar a los usuarios? you lo veremos. [MÚSICA] >> Hablemos de la asociación entre préstamo y recurso. Con un préstamo se pueden sacar varios recursos. >> ¿Sí? ¿Te parece que es así? A mí me parece que por un préstamo hay un solo recurso asociado. Una copia, un préstamo. Y el número de préstamos es limitado para el usuario. >> Hum, no lo sé. En realidad, creo que podría ser de ambas maneras, pero eso cambiaría la cardinalidad de las asociaciones, y creo que esta sería, además, compartida. >> ¿Pero por qué compartida? >> Porque los recursos son parte de un préstamo, pero no están ligados a ellos directamente. Y sin un recurso los préstamos tampoco tendrán mucho sentido. En cualquier caso, creo que deberíamos preguntarle a Alberto si por cada préstamo se saca un recurso o varios recursos. Por ahora, creo que es prudente que dejemos lar cardinalidades como cero a muchas de ambos lados. >> Lo que significa que un recurso puede estar en varios préstamos y por cada préstamo puedo sacar varios recursos. Tenemos que completar con los métodos correspondientes de cada clase para retornar los préstamos asociados y los recursos préstados, y un método para prestar un recurso que reciba un número de recursos a prestar. >> De acuerdo. Y con relación al tipo de asociación, yo diría, que podemos aplicar la misma lógica para usuario biblioteca y préstamo. Dentro de nuestro sistema, los préstamos son parte del usuario. Obviamente, un préstamo solo pertenece a un usuario y no tiene sentido que no estén ligados de alguna manera. >> Suena como a una composición. >> En realida, sí, una composición. Del lado del usuario hay cardinalidad uno y del lado de préstamos cero a muchos. >> ¿A muchos infinitos? ¿O a muchos tiene un límite por tipo de usuario?, es decir, dado el tipo de usuario, ¿hay una limitante de cuántas veces puede hacer préstamos? >> Creo que eso deberíamos preguntárselo a Alberto. ¿Tiene un usuario un límite de préstamos que puede hacer según su perfil? Ahora que lo pienso me pregunto, ¿es importante guardar historiales de los préstamos porque si eliminamos un usuario de nuestro sistema perderíamos la información de los préstamos? >> Es un buen punto, a lo mejor no sea una asociación compuesta después de todo. Por ahora, dejémoslo así y pongámonos métodos también para préstamos de un usuario y dar desde la clase préstamo el usuario al cual están asociados. >> Ahora miremos algo. Creemos un método para hacer un préstamo en la clase usuario biblioteca. Es claro que necesitamos asociar un recurso para él. Para no crear la clasificación de los usuarios, la lógica de la fecha de vencimiento tendrá que estar en el préstamo. ¿Quién debe conocer quién es el usuario o cuál es el tipo de usuario? >> Entonces tenemos una asociación de dependencia y tiene sentido hacerlo así. >> Finalmente hablemos de la relación entre préstamo y multa. Yo veo otra asociación compuesta. ¿Las multas son parte del préstamo? ¿Están ligadas al préstamos? ¿Una multa solo puede estar asociada a un préstamo? ¿Y un préstamo solo puede tener una multa? >> ¿Por qué no compartida? Bueno, porque las multas en realidad le pertenecen al préstamo y el préstamo solo es a un usuario. No tiene sentido algo como una multa asociada a múltiples préstamos. Entonces, una multa asociada a un solo préstamo y con esto agregamos los métodos correspondientes para retornar los diferentes valores. >> Esta discusión nos lleva a cuestionarnos el tipo de asociación que debemos definir entre usuario, biblioteca y préstamos. Dijimos que era compuesta, sin embargo, si borramos un usuario, si eliminamos un usuario del sistema, se eliminan los préstamos y a su vez las multas, lo cual no parece tan práctico porque si queremos guardar el historial pues no podemos eliminar toda esta información. Por eso debemos preguntar si es importante guardar esta historia. >> Es cierto. Creo además que hace falta un asociación, una asociación entre usuario y multa y definirla como que un usuario tiene varias multas asociadas. >> ¿Varias? >> Varias por varios préstamos, ¿o tal vez una sola? Bueno, el punto es que debe existir para poder calcular cosas como si puede hacer préstamos, o sea si tiene o no multas, o incluso consultar qué multas tiene en un momento dado. Y estos métodos, obviamente, tenemos que agregarlos en cada una de la clases de cada lado de la asociación. >> Entiendo. Bueno, creo que en este punto podemos hacer una pausa y volver con Alberto para hacerle nuestras preguntas. Recapitulémonos. [MÚSICA] ¿Es posible hacer varios préstamos por recurso o un préstamo corresponde a un solo recurso? ¿Cuál es el límite de préstamos de un usuario? ¿Es importante tener el histórico de multas? ¿Cómo se identifican los diferentes recursos en la biblioteca? >> Bien, ahora con estas preguntas acompáñanos a validarlas con Alberto en el siguiente video. Te esperamos. [MÚSICA] [MÚSICA] [MÚSICA] [MÚSICA] [AUDIO_EN_BLANCO] [AUDIO_EN_BLANCO] [AUDIO_EN_BLANCO] [AUDIO_EN_BLANCO] [AUDIO_EN_BLANCO] [AUDIO_EN_BLANCO] [AUDIO_EN_BLANCO] [AUDIO_EN_BLANCO] [AUDIO_EN_BLANCO] [AUDIO_EN_BLANCO]
