Corrección Entrega 1 - Grupo 5

La entrega se encuentra aprobada.

A continuación se encuenta la lista de observaciones a considerar para futuras entregas (de acuerdo al nivel de severidad)

- Sev 1: No tienen implementados los siguentes casos, y no se ha indicado el porqué en un documento de decisiones de diseño:

- Un usuario puede ver las fotos que haya subido el mismo (Este sí está) o uno de sus amigos (este no está), o las fotos en las que fue etiquetado (no está)

- Etiquetar a un amigo suyo en una foto que puede ver (qué ocurre si no puede ver la foto?)

- Dejar comentarios en cualquier foto que puede ver (qué ocurre si no puede ver la foto?)

- Enviar un mensaje automáticamente cuando se etiqueta un usuario en una foto.

- Sev 1: No se han provisto diagramas estáticos y dinámicos, y tampoco un documento de decisiones de diseño indicando los patrones de diseño y herramientas del paradigma utilizados.

-Sev 2: No deben acoplarse con una implementación de colección en particular. Por ejemplo, en enviarMensaje no necesitan más que Set. Verifiquen sobre todo la implementación de Usuario.

-Sev 2: No deben subir archivos binarios (.class)

-Sev 2: Para los archivos .JAR referenciados, por favor indicar número de versión ó url desde donde los bajaron ó copienlos en un directorio "lib" ó utilicen maven :)

-Sev 2: Para poder etiquetar la solución en SVN, deberían mover todos los archivos a un subdirectorio "trunk" y crear un directorio "tags" en donde crearían un "tag" por cada versión o entrega.

-Sev 2: En CaripelaCuaderno, en el método registrar, no está bien que traguen la excepción ExcepcionRegistro (seguramente quieren realizar lo contrario)

-Sev 2: Deberían haber creado la interfaz por la cual se envía el mail de confirmación (no así la implementación)

-Sev 2: Algunos tests no son claros en el flujo y las validaciones. Por ejemplo, testLeerMensajesNoLeidos

-Sev 3: Si declaran que un método lanza una excepcion, o bien láncenla con la condición adecuada o eliminen la declaración "throws" (ejemplo, método confirmarRegistro)

-Sev 3: Cuando lancen una excepción, provean el mayor detalle posible de la misma, que ayude a detectar las causas. Por ejemplo, al momento de lanzar ExcepcionRegistro en "checkearRegistro" podrían indicar el motivo ("El usuario ya se encuentra registrado"). Esto ocurre sólo en ciertas regiones del código

-Sev 3: Sería más conveniente que la relación entre un grupo y sus usuarios se maneje a través del grupo, ocultando el detalle de implementación de la relación. Por ejemplo, agregarUsuario (clase Grupo) podría agregarse en la lista de grupos del usuario, o directamente podría no haber lista de grupos del usuario (el perteneceA podría estar implementado preguntando por los miembros del grupo)

- Sev 3: testEstrategiaAConfirmar en realidad son 3 tests: 1 que valide que por default no tiene amigos, otro que valide que se agrega a la lista de solicitados y otro que valide que se aceptó bien. Esto puede verse fácilmente por las 3 líneas de asserts. Al momento de correr los tests, teniendo 3 se puede identificar más precisamente el error sin recurrir al stacktrace. Lo mismo ocurre con los demás tests de Amistad.

- Sev 3: Dado que sólo se pueden enviar mensajes a amigos o grupos a los que pertenece, deberían validar que esto así ocurra.

- Sev 3: Intenten no agregar métodos de test si no es esencial, como leerMensajePorID. Existe gran posibilidad de que se pueda acceder al valor de otra manera

- Sev 3: Intenten buscar un nombre más feliz para "seSubioLaFoto"

- Sev 3: Intenten ser homogéneos al momento de elegir nombres de clases para las excepciones.

- Sev 4: al momento de crear los tests, intenten pensar en un nombre, mail o criterio de búsqueda más realista que "pepe"

- Sev 4: Se sugiere utilizar maven para simplificar el despliegue en los distintos ambientes (desarrollo, laboratorio de sistemas, corrector del TP :) )