Diseño Distribuido de una Arquitectura de Software

Presentación del tema: "Diseño Distribuido de una Arquitectura de Software"— Transcripción de la presentación:

1 Diseño Distribuido de una Arquitectura de Software
Faber Giraldo – Univ. del Quindío Sergio Ochoa – Univ. de Chile Oct. 2010

2 Enunciado Desarrollar un Sistema de Mensajería Seguro (tipo Chat), pero con persistencia. La arquitectura puede ser: Centralizada: Distribuida: … o mezcla de ambas.

3 Enunciado El sistema funcionará en base a sesiones de conversación.
Brindará persistencia de los mensajes. Deberá verificar la identidad de los usuarios. La comunicación entre usuarios del sistema será factible o no dependiendo del rol de los mismos. Ej. de roles: Presidente, ministro, secretario, etc.

4 Enunciado HINT: La lista de roles de usuario y de interacciones válidas debería poder modificarse (fácilmente) en el tiempo. Hay usuarios de nivel superior (por ej. un ministro o el presidente, a través de sus asesores) que pueden autorizar interacciones excepcionales, que no están dentro de la lista de interac. válidas. La lista de interacciones válidas para un usuario depende del rol que éste tenga. El sistema debe tener mecanismos de awareness (Por ej. percepción de qué usuarios están conectados).

5 Enunciado Todas las conversaciones son privadas…
Los usuarios pueden crear una sesión de conversación, solicitar el ingreso a una conversación ya creada, y también de- suscribirse de una sesión. Cuando un usuario ingresa a una sesión de conversación, debe recibir la lista ordenada de mensajes intercambiados en esa conversación. Las conversaciones se mantienen activas hasta que sus miembros deciden darle de baja.

6 Enunciado La baja de una sesión puede ocurrir por diversos motivos:
Se retiró el último usuario suscrito. No hubieron mensajes durante un período de un mes. Todas las conversaciones (aunque estén dadas de baja) deben poder ser accedidas de sólo lectura por los administradores del sistema. Los usuarios pueden entrar y salir del sistema según su necesidad.

7 Enunciado Hay restricciones de performance para el sistema.
El transporte de los mensajes debe ser seguro. Se pueden reutilizar componentes pre-hechos (COTS) como parte de la solución.

8 Tareas Importantes Cada equipo deberá hacer un diseño arq. del sistema que sea: mantenible, seguro, y con buena performance. Hasta el 15 de Oct: Cada alumno debe escoger un Req. de Calidad para trabajar. Hasta el 25 de Oct.: Cada alumno debe entregar un diseño de la arq. considerando sólo uno de los atributos de calidad antes mencionados (tarea individual).

9 Tareas Importantes El diseño arq. debe consistir de:
Un diagrama de componentes, usando cualquier nomenclatura. Una explicación de qué es lo que hace cada componente. Una explicación de cómo funciona el sistema en su conjunto, para manejar los requisitos antes mencionados. Después de esta tarea, cada miembro debe explicarle vía videoconf. al resto de los miembros del equipo, cómo funciona su propuesta.

10 Tareas Importantes Esa y el resto de las sesiones de videoconf. deben grabarse en LiveMeeting.. Carla Vairetti está coordinando eso. El equipo debe negociar y ver cómo integrar las soluciones individuales, para generar una solución integral (por videoconf.). Hasta el 01 de Nov.: Cada equipo debe entregar un diseño que considere los tres req. de de calidad antes mencionados.

11 Videoconferencias Grabación 1: Sesión de conocimiento de los miembros del equipo. (hasta el 15 de Oct.) Grabación 2: Explicación de las soluciones arq. Individuales. (hasta el 25 de Oct.) Grabación 3: Negociación a integración de las soluciones individuales. (hasta el 01 de Nov.)