Sistema de Notificación de Emergencias para Móviles
Transcripción
Sistema de Notificación de Emergencias para Móviles
Sistema de Notificación de Emergencias para Móviles Método ATAM ID______ Paso 1. Presentar el Método ATAM En la documentación adjunta, en el anexo IV, se encuentra la guía de aplicación de ATAM en el que se pueden consultar los detalles durante la realización del presente ejercicio. Paso 2. Presentar los Objetivos de Negocio El objetivo de negocio que motiva el esfuerzo de desarrollo es la construcción de sistemas de notificaciones con alta fiabilidad y prestaciones. Por lo tanto la arquitectura software que soporta dicho sistema deberá tener altos niveles de fiabilidad y rendimiento. Paso 3. Presentar la Arquitectura El sistema RescueME es una aplicación para gestionar notificaciones en casos de emergencia (como atracos, raptos etc.). En una situación de riesgo un usuario puede enviar notificaciones a sus contactos. La aplicación envía los datos de posición al servidor para que los contactos que reciben la notificación puedan rastrear la posición del usuario y notificar la emergencia, si lo creen conveniente, a las autoridades competentes. La Figura 1 muestra los principales componentes de la arquitectura inicial de la aplicación, la cual tiene una estructura cliente/servidor básica. Esta formada por un servidor que recibe las notificaciones y los datos de posición y que aloja la web a la que se conectan los contactos que reciben una notificación de emergencia para realizar el seguimiento. El servidor web tiene acceso a la base de datos, alojada en el servidor de base de datos, donde se almacenan todos los datos. La aplicación tiene dos tipos de clientes: • Cliente Móvil: es una aplicación móvil que cuando el usuario activa la opción RescueME! envía las alertas a todos sus contactos (vía SMS y/o email) y comienza a enviar los datos de posición al servidor cada 5 segundos. • Aplicación Web: los contactos que reciben las notificaciones de alerta pueden conectarse a la aplicación web de RescueMe para consultar el estado y la ubicación del usuario que le envió la notificación de alerta. En este tipo de aplicaciones en que el intercambio de mensajes entre las aplicaciones cliente y el servidor es crítica (sobre todo en el caso del cliente móvil) es importante asegurar la fiabilidad y el rendimiento del sistema. Figura 1. Arquitectura Inicial de la Aplicación La Tabla 1 muestra el tiempo medio entre fallos (MTBF), el tiempo medio de reparación (MTTR) y el máximo numero de peticiones que puede servir para los distintos componentes de la arquitectura y sus posibles variantes Tabla 1 MTBF,MTTRy Número Máximo de Peticiones Servidas de los componentes de la arquitectura Componente MTBF MTTR Máximo Nº Peticiones Servidor 75 h 0,5 h 600 peticiones Servidor BBDD 100 h 1,5 h 1500 peticiones Servidor Backup 75 h 0,5 h 600 peticiones Servidor Backup (Reducido) 30 h 0,5 h 300 peticiones 1 Anote la hora de inicio (hh:mm): Paso 4. Identificar los Enfoques Arquitectónicos Para el dominio de los sistemas de gestión de notificaciones para casos de emergencia, los expertos del dominio han identificado una lista de patrones arquitectónicos que se haya descrita en el anexo III. Vaya al Anexo III y lea y comprenda cada uno de los patrones. Conteste a las siguientes preguntas siguientes indicando la opción correcta El objetivo del patrón Balanceador de Carga es: a) Mejora la fiabilidad del sistema y el número de peticiones que el servidor de aplicaciones puede gestionar al disponer de dos servidores sirviendo peticiones de concurrentemente. b) El número de peticiones que el sistema es capaz de servir no se ve incrementado puesto que solo hay un servidor sirviendo peticiones de manera simultánea. c) Aumenta la fiabilidad del sistema, dado que en caso de fallo en el servidor principal el servidor de backup entra en servicio permitiendo que el sistema continúe sirviendo peticiones. El patrón Clúster Simétrico: a) En el peor de los casos el número de peticiones que el servidor de aplicaciones puede gestionar puede verse reducido dado que el servidor de backup tiene menos capacidad que el principal. b) Aumenta el número de peticiones que el servidor de aplicaciones puede gestionar al disponer de dos servidores que son capaces de servir peticiones de manera concurrente. c) Aumenta la fiabilidad del sistema, dado que en caso de fallo en el servidor principal el servidor de backup entra en servicio permitiendo que el sistema continúe sirviendo peticiones. El patrón Clúster Asimétrico: a) En el peor de los casos el número de peticiones que el servidor de aplicaciones puede gestionar puede verse reducido dado que el servidor de backup tiene menos capacidad que el principal. b) Aumenta el número de peticiones que el servidor de aplicaciones puede gestionar al disponer de dos servidores que son capaces de servir peticiones de manera concurrente. c) La fiabilidad del sistema no va a verse modificada al no haber nunca dos servidores trabajando en paralelo. El patrón Failover Clúster: d) Aumenta la fiabilidad del sistema y el número de peticiones que el servidor de bases de datos puede gestionar al disponer de dos servidores de bases de datos que son capaces de servir peticiones de manera concurrente. e) El número de peticiones que el sistema es capaz de servir no se ve incrementado puesto que solo hay un servidor sirviendo peticiones de manera simultánea. f) Aumenta la fiabilidad del sistema, dado que en caso de fallo en el servidor principal el servidor de backup entra en servicio permitiendo que el sistema continúe sirviendo peticiones. Paso 5. Generar el árbol de utilidad Los factores de calidad en los que se descompone la “utilidad” de la arquitectura han sido identificados y especificados hasta el nivel de escenarios en el árbol de utilidad que se detalla en la Figura 2, compuesto por los escenarios de fiabilidad, en el que se especifica el Porcentaje de Tiempo en Servicio (UpTime) y de rendimiento, en el que se especifica Carga Máxima que el sistema ha de ser capaz de servir (LoadSize). En el nivel 1 se puede observar los atributos de calidad fiabilidad y rendimiento, en el nivel 2 los dos requisitos y finalmente en el nivel 3 los escenarios que describen los requisitos. Figura 2. Árbol de Utilidad de la Arquitectura Anote la hora de fin (hh:mm): 2 Tarea 1: Evaluación de la Arquitectura Anote la hora de inicio (hh:mm): Determinar el cumplimiento de los escenarios descritos en el árbol de utilidad de la Figura 2: Verifique el cumplimiento del requisito de rendimiento R1 para la Arquitectura original que se muestra en la Figura 1. Para ello aplique el cálculo de carga máxima del sistema. No ha de hacer los cálculos manualmente, estos van a ser automatizados mediante una hoja de cálculo. Vaya a la página 1 del Anexo I (Métricas para la evaluación de arquitecturas software), lea y comprenda el funcionamiento de la métrica carga máxima del sistema y conteste a las siguientes preguntas. 1) Acerca de la métrica carga máxima, ¿cuál de las siguientes afirmaciones es cierta?: a) b) c) 2) Cuando hay dos servidores actuando en serie, se sumarán de las capacidades de los mismos. Cuando hay dos servidores en paralelo para un mismo servicio se sumarán las capacidades de los mismos. Ninguna de las anteriores afirmaciones es cierta. El resultado de la medición, ¿cuál de las siguientes afirmaciones es cierta?: a) b) c) Cuanto mayor es el valor medido, mas carga es capaz de soportar el sistema. Cuanto menor es el valor medido, mas carga es capaz de soportar el sistema. Es un porcentaje que nos indica cuan bueno es el rendimiento del sistema, cuanto más cercano a 100 mejor. Abra el archivo Calculo de Métricas RescueME Original.xls que automatiza los cálculos. Vaya a la pestaña CARGA MAXIMA. Rellene la Tabla Numero Máximo de Peticiones Servidas con los datos de máximo número de peticiones que aparecen en la Tabla 1 • • Anote la carga máxima obtenida: Peticiones ¿Cumple el umbral mínimo definido en el árbol de utilidad? Si/No Verifique el cumplimiento del requisito de fiabilidad R2 para la arquitectura original que se muestra en la Figura 1. Para ello aplique el cálculo del porcentaje de tiempo en servicio. No ha de hacer los cálculos manualmente, estos van a ser automatizados mediante una hoja de cálculo. Vaya a la página 2 del Anexo I (Métricas para la evaluación de arquitecturas software), lea y comprenda el funcionamiento de la métrica porcentaje de tiempo en servicio y conteste a las siguientes preguntas. 3) Acerca de la métrica porcentaje de tiempo en servicio, ¿cuál de las siguientes afirmaciones es cierta?: a) b) c) 4) Es una métrica que se calcula a partir del tiempo medio entre fallos y el tiempo medio de reparación de los componentes del sistema Cuando se combinan varios servidores se calcula la probabilidad de fallo de cada uno de ellos, que es función de su tiempo medio entre fallos Las dos afirmaciones anteriores son ciertas. El resultado de la medición, ¿cuál de las siguientes afirmaciones es cierta?: a) b) c) Cuanto mayor es el valor medido, mayor es la fiabilidad del sistema. Cuanto menor es el valor medido, mayor es la fiabilidad del sistema. Es un porcentaje que nos indica cuan bueno es el rendimiento del sistema, cuanto más cercano a 100 mejor. Abra el archivo Excel Calculo de Métricas RescueME Original.xls que automatiza los cálculos. • • Vaya a la pestaña PORCENTAJE TIEMPO EN SERVICIO Rellene la Tabla MTBF y MTTR con los datos que aparecen en la Tabla 1 Anote el porcentaje de tiempo en servicio obtenido % ¿Cumple el umbral mínimo definido en el árbol de utilidad? Si/No Anote la hora de fin (hh:mm): 3 Anote la hora de inicio (hh:mm): Tarea2: Análisis de enfoques y Priorización de Escenarios Paso 6. Analizar los enfoques arquitectónicos En caso que la arquitectura no cumpla los requisitos no funcionales expresados en el árbol de utilidad definido de la Figura 2, se deberán analizar los patrones arquitectónicos en relación estos requisitos no funcionales. Al analizar los patrones hay que tener en cuenta los posibles puntos débiles de la arquitectura y puntos de mejora de la misma, para ver como estos patrones pueden mejorar la actual arquitectura. Si el requisito de rendimiento R1 no se cumple, consulte el Anexo III y anote la lista de todos los patrones que a su juicio podrían ayudar a cumplir dicho requisito. Si el requisito de fiabilidad R2 no se cumple, consulte el Anexo III y anote la lista de todos los patrones que a su juicio podrían ayudar a cumplir dicho requisito. Paso 7. Brainstorming y Priorización de escenarios En base a los escenarios, escriba la prioridad que aparece en el árbol de utilidad para cada uno de los escenarios como Alto (A), Medio (M) o Bajo (B): Prioridad del Requisito de rendimiento R1: Carga máxima del sistema Prioridad del Requisito de fiabilidad R2: Porcentaje de Tiempo en Servicio Paso 8. Analizar los enfoques arquitectónicos Se repite el 0 en base a los escenarios prioritarios establecidos en el 0. De entre el conjunto de patrones preseleccionado en el 0, seleccione un patrón arquitectónico a aplicar a la arquitectura original descrita en la Figura 1 para que esta cumpla con dichos escenarios prioritarios. . No es necesario que intente predecir el valor de las métricas, sino tomar la decisión en base a los requisitos de calidad del árbol de utilidad y su conocimiento del problema. Anotar el nombre del patrón seleccionado: El resultado de la aplicación del patrón seleccionado se encuentra descrito en el punto correspondiente del Anexo II (Arquitecturas de la aplicación RescueME! tras la aplicación de patrones). Anote la hora de fin (hh:mm): 4 Tarea 3: Medición de la Arquitectura (Resultante) Anote la hora de inicio (hh:mm): Determinar el cumplimiento de los escenarios descritos en el árbol de utilidad de la Figura 2: Verifique el cumplimiento del requisito de rendimiento R1 para la arquitectura modificada. Para ello aplique el cálculo de carga máxima del sistema que se describe en la Página 1 del Anexo I. No ha de hacer los cálculos manualmente, para asistirle en el proceso de medición cuenta con el archivo Excel Calculo de Metricas RescueME.xls que automatiza los cálculos. • • • Vaya a la pestaña CARGA MAXIMA Rellene la Tabla Numero Máximo de Peticiones Servidas con los datos de máximo numero de peticiones que aparecen en la Tabla 1. Seleccione en el desplegable Arquitectura a Evaluar el nombre del patrón que seleccionó en el Paso 8. Anote la carga máxima obtenida: Peticiones ¿Cumple el umbral mínimo definido en el árbol de utilidad? Si/No Verifique el cumplimiento del requisito de fiabilidad R2 para la arquitectura modificada. Para ello aplique el cálculo del porcentaje de tiempo en servicio, tal como se describe en la Página 2 del Anexo I. No ha de hacer los cálculos manualmente, para asistirle en el proceso de medición cuenta con el archivo Excel Calculo de Metricas RescueME.xls que automatiza los cálculos. • • • Vaya a la pestaña PORCENTAJE TIEMPO EN SERVICIO Rellene la Tabla MTBF y MTTR con los datos que aparecen en la Tabla 1. Seleccione en el desplegable Arquitectura a Evaluar el nombre del patrón que seleccionó en el Paso 8. Anote el porcentaje de tiempo en servicio obtenido % ¿Cumple el umbral mínimo definido en el árbol de utilidad? Si/No Anote la hora de fin (hh:mm): 5