Integrantes:
Luis Alejandro
Rodriguez Torres. Codigo:
624727. larodriguez27@ucatolica.edu.co
Wilmer David Oidor
Bolaños. Codigo: 624708. woidor08@ucatolica.edu.co
·
Descripción:
El punto de vista
de concurrencia presentado, busca analizar y describir la concurrencia del
sistema, identificando las partes
componentes que pueden ejecutarse de manera simultánea y la forma en que
se sincronizan las unidades de ejecución. Se analizará el sistema centralizado de
procesos académicos de colegios en la ciudad de Bogotá.
·
Concerns:
El sistema debe
contar las siguientes características:
-
Un actor del sistema (Estudiante, Docente,
Coordinador de Area) debe recibir y
transmitir de forma segura al repositorio central, la información que
corresponda a cada perfil.
-
El repositorio siempre debe estar disponible
para recibir la información de las aplicaciones y/o trasmitir la informacion, de tal manera
que no se afecte el desempeño del sistema.
-
Los registros generados por cada aplicación de
determinado colegio, deben estar claramente identificados, con fecha, hora,
tipo, aplicación, consecutivo y usuario.
-
Los tiempos de escritura de eventos no deben
generar represamientos en el registro central de los registros.
-
El repositorio central dispondrá de un servicio
de recepción de las transacciones enviadas por cada colegio, de tal manera que
este sea el único autorizado para escribir en la base de datos centralizada.
-
Si la conexión entre la aplicación de un colegio
y el servidor central falla, las
aplicaciones de manera transparente deberán continuar registrando los registros
de manera local hasta que la conexión sea restaurada, momento en el
cual se deben enviar los registros que no hayan sido transmitidos.
-
Se debe contar con mecanismos para verificar que
la información enviada por una aplicación fue recibida de manera correcta y completa
al servidor central.
-
Garantizar
que los registros de un evento enviados desde una aplicación con un perfil de
usuario determinado no sean alterados durante su transporte y que sean originados por la aplicación
y perfil de usuario respectivo.
·
Stakeholders del Sistema.
-
Estudiantes.
-
Docentes.
-
Coordinadores de área.
-
Padres de familia.
-
Ministerio de Educacion.
·
Modelo de
Concurrencia del sistema
El sistema
centralizado de proceso académicos , es una parte importante para analizar en este punto de vista arquitectónico, ya que
todos los colegios manejan fechas similares en el proceso de notas. Dado que se tienen muchos
procesos, aplicaciones y servicios los cuales deben utilizar las funcionalidades
de publicar,actualizar y consultar notas, se debe sincronizar el acceso a dicho
recurso; además, múltiples usuarios (Docentes,
Coordinadores de area de todos los colegios del distrito) deben publicar todos sus registros en el
servidor central academico. Estas operaciones no pueden afectar el desempeño del sistema, y
deben contar con mecanismos de recuperación y alta disponibilidad.
-
Estrategias
en el diseño de la multitarea
El acceso a un recurso debe considerarse como un
punto crucial concurrente, por tanto su acceso debe sincronizarse. La estrategia se sugiere
es usar un mecanismo de exclusiones mutuas (Mutex).
La publicación de los registros de eventos no
deben afectar el desempeño, se debe asegurar la entrega y debe contar con un mecanismo de
recuperación. Se plantea el uso de colas
de mensajes, tipo publicador/subscriptor con validación de aceptación,
tolerancia a fallas, reintentos y serialización local
-
Priorización
de acceso
Dados los requerimientos del sistema, todo
trámite, proceso y acción realizada en las aplicaciones debe ser registrada en el repositorio central de
procesos academicos. El acceso a los recursos compartidos para realizar estas labores ofrecerá un
esquema de igual prioridad a las aplicaciones que consuman estos servicios
-
Abrazos
mortales
Para evitar posibles escenarios de abrazos
mortales, se optó por el mecanismo de colas de mensajes para la publicación en
el repositorio central, y en los instrumentos de exclusión mutua (Mutex) en las
aplicaciones de cada colegio, se evitará el uso de recursos comunes que puedan
ocasionar una condición de carrera entre
las aplicaciones.
Los componentes funcionales de
Ingresar, Modificar y Consultar Notas, usarán un Mutex (Exclusión mutua), para
registrar los eventos. Este además utilizará un servicio de colas de mensajes
publicador / subscriptor para enviar los registros al repositorio central. Dado
que la cola de mensajes es asíncrona y no transaccional el desempeño general de
la aplicación no se verá afectada.
Bibliografia:
Rozanski Nick, Eoin woods. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (2nd Edition). Addison-Wesley Professional; 2 edition (November 4, 2011). Capítulo 18.
No hay comentarios:
Publicar un comentario