Estructura notificaciones

[Jere1203]

Hola buenos días, teníamos una en la parte de los requisitos que pide el tech leader para las notificaciones, ya que en el mismo se detallan atributos de las notificaciones que no están contemplados en el diagrama de clases (por ejemplo cuando se realiza una reserva se le debe notificar al anfitrión quién realizó la reserva, la fecha de reserva y cuántos días reservó además del alojamiento mientras que, si nos basamos en la clase Notificación, los únicos atributos que se tiene de la misma son mensaje, usuario, fechaAlta, leida y fechaLeida). Con mi grupo estábamos pensando en detallar lo mencionado en el requisito como parte del mensaje para respetar la estructura de la clase que se detalla en el UML pero no estamos seguros que sea una solución válida.

Adjunto imágen con los requisitos mencionados:

Adjunto imágen con la interfaz de la clase Notificación:

[Jere1203]

Buenas, ahí a mi compañero le contestaron sobre el atributo fechaAlta por lo que esa duda ya estaría resuelta. Nos queda todavía la duda si es una solución válida que los datos de la notificación que nos indica el Teach Leader vayan dentro del mensaje (String) ya que hay datos que no son considerados en la clase de Notificación.
Muchas gracias y buena semana.

[flbulgarelli]

Hola! El diagrama de clases provisto es orientativo. Pueden faltar atributos o métodos, o convenirles modificar firmas e interfaces de sus objetos de dominio. Ajusten el modelo como sea necesario.

Dicho eso, no me termina de quedar claro como se vería el modelo luego de tales cambios. ¿Ustedes están buscando incorporar esos datos (nombre de la persona que reservó, fecha de reserva, etc) cómo atributos individuales de la notificación y no cómo información desestructurada dentro del contenido del mensaje? ¿Que ventajas obtendrían con eso? ¿Que sucedería si el día de mañana necesitamos otros tipos de notificaciones? ¿Que debería ocurrir si luego de enviada la notificación, la persona modifica sus datos personales?

[zBlooDy]

Buenas! Nuestra idea en realidad era que, cuando se crea la notificacion, que esos datos se metan directamente en el mensaje (string), para no tenerlos todos como un atributo de la notificacion en si. Igualmente, esto trae el problema de que si el usuario tiene la posibilidad de cambiar de nombre, el contenido de esa notificacion quedaria "desactualizado" (La notificacion tendria el nombre anterior).

• Posible solucion para que no quede desactualizado: Que la notificacion, el atributo "mensaje" en vez de ser un string, sea instancia de una clase que conozca el usuario y el contenido del mensaje, entonces siempre que se le pida va a tener al usuario actualizado.

[smalirat]

Hola, en nuestro grupo no nos queda claro a que corresponde el atributo fecha alta. Corresponde al la fecha que se acepta una reserva, o a la fecha que se crea el mensaje?

[zBlooDy]

Buenas!, aca esta la respuesta por el profesor: #2