e buscado mas videos sobre este tema de los diagrams de uml en el canal pero no e tenido exito me podria facilitar la lista o los libros de los cuales obtuvo la informacion. se agredece de antemano.
Me parece, si no entendí mal la información previa, que hay un error al final del diagrama. Ni el Alumno, ni el Curso, almacenan en sus atributos, sus reservas, sino que son los objetos de la clase Reserva, quienes tienen a Alumno y Curso entre sus atributos, y por tanto, es a este objeto a quien se le debe persistir la información y no a Alumno y Curso. Además, sería pecar de redundancia de datos.
La respuesta del autor del vídeo es la siguiente: Creo que hay un error de base y es que en un diagrama de secuencia no se refleja la información de persistencia (para eso está el diagrama de clases). En ningún momento hay esa redundancia indicada, ya que la clase Alumno se relaciona con Curso a través de Reserva y cada clase tiene los atributos que necesita, sin ninguna repetición. Otra cosa distinta es, en el diagrama de interacción, cómo se alcanza una reserva: para acceder a una reserva desconocida habría que hacerlo a través del Alumno o del Curso. Es importante diferenciar entre diagramas UML, pues cada uno tiene su función y utilidad.
Muchas gracias por el video, pero creo que hay un error conceptual, que tiene que ver con la consistencia entre el diagrama de clases y el de secuencias. Básicamente el problema es que los mensajes del diagrama de secuencias deben llegar a una clase que posea una operación capaz de resolver lo que dice el mensaje. En el paradigma de orientación a objetos, son los objetos de las clases los que "saben" ejecutar las operaciones definidas en esas clases. En este caso, lo correcto sería definir en la clase alumno, la operación BuscarAlumno (dado que es una operación que se hace sobre los objetos de esa clase) y por lo tanto son los objetos de tipo Alumno los que saben BuscarAlumno. Lo que equivaldría a tener el método "BuscarAlumno" definido en la clase "Alumno". Como está modelado alli, significa que la operación BuscarAlumno está definida en la clase EscuelaVerano y es muy probable que esta clase no tenga la información necesaria para resolver esa petición de BuscarAlumno.
El profesor comenta: "No termino de entender el error conceptual que apuntas, pues es exactamente lo que indicas: un diagrama de secuencia muestra la interacción o comunicación entre los objetos instanciados a partir del diagrama de clases. Lo que no veo correcto en absoluto es que la clase Alumno tenga un método BuscarAlumno ya que, según la orientación a objetos, el Alumno solo debe hacer lo que puede/sabe resolver. Un Alumno no sabe buscar a otro alumno porque la colección de los mismos está en EscuelaVerano y es precisamente la única aquí que sabe cómo resolver (o implementar) esa petición, independientemente de la clase que invoque dicho método. Por tanto, lo que indicas de definir el método BuscarAlumno en la clase Alumno sí es un error conceptual (y desgraciadamente bastante común). En otras palabras, un Alumno podrá devolver y realizar información sobre dicho alumno, pero no sabrá cómo buscar a otros alumnos".
@@UPV Muchas gracias, por su respuesta. Efectivamente, estamos de acuerdo en la afirmación: "el Alumno solo debe hacer lo que puede/sabe resolver". Es posible que el error sea mio, al pensar que también la operación BuscarAlumno deba estar en la clase Alumno. Podría por favor darme una referencia bibliográfica sería, donde expliquen el error conceptual que tengo. Muchas gracias.
@@pequenin35 pensalo de esta forma: Para buscar a un alumno en concreto, hay que iterar sobre una colección de alumnos. ¿Quién tiene como atributo esa colección? La clase Alumno no almacena una colección de alumnos. Vos sos una instancia de clase Alumno, y me podés responder sobre tus datos personales, pero no te puedo pedir que me des el nombre de otra persona de X DNI porque no es tu responsabilidad persistir esa información en tus atributos.
