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

Documentos relacionados