1. Aplicaciones Web J2EE y
Requerimientos no funcionales
[ Una vista rápida ]
Abril 2009
Ing. Jorge Irey
2. Agenda
1. Taxonomia de Requisitos no
Funcionales
2. Arquitectura vs. Diseño
3. Aplicaciones “n” – Capas: Tiers vs.
Layers
4. Disponibilidad
5. Escalabilidad
6. Performance
7. Causas Comunes a los problemas
3. Motivación
Requerimientos “Fuerzas” que afectan al Software:
Funcionales
Requerimientos Funcionales
Restricciones
Requerimientos NO Funcionales
Características del Negocio
en tiempo de
ejecución
Software
Restricciones
de Tecnología Otras
SLA QoS
Características
“Fuerzas” que afectan a un Puente:
Carga muerta
Carga Viva
Carga Dinámica
Carga ambiental
4. Motivación (2)
Requerimientos
del Negocio
Documento de Visión y Alcance
Restricciones: “Solamente podrán votar los
ciudadanos legalmente residentes en el extranjero”
Requerimientos Atributos de
del usuario Calidad
Otros Requerimientos
Documento de Casos de Uso No funcionales
Requerimientos Requerimientos Restricciones
del Sistema Funcionales
Especificación de Requerimientos de
Sofware
IEEE Std 830-1998
5. Taxonomia de Requisitos no Funcionales
FACILIDAD DE MANTENIMIENTO ¿ puedo INTEROPERABILIDAD ¿ podré comunicarlo con otros sistemas ?
arreglarlo ? PORTABILIDAD ¿ podré utilizarlo en otra máquina ?
FACILIDAD DE PRUEBA ¿ puedo REUSABILIDAD ¿ podré reutilizar parte del software ?
probarlo ?
FLEXIBILIDAD ¿ Puedo modificarlo ?
Visión del
Usuario
Modelo de McCall
OPERACION
CORRECCION ¿ Hace lo que se requiere ?
FIABILIDAD ¿ funciona bien todo el tiempo ?
EFICIENCIA ¿ Funcionará lo mejor posible ?
INTEGRIDAD ¿ es seguro ?
FACILIDAD DE USO ¿ puedo ejecutarlo ?
6. Taxonomia de Requisitos no Funcionales
Modelo ISO 9126
RNF-002 y RNF-020 “El sistema deberá
considerar un arquitectura lógica de 3 capas”
RNF-014 “Se debe tener extrema seguridad para
la transferencia de información con respecto a los
votos”
RNF-016 “A cada usuario empadronado se le
asignará un PIN”
RNF-001 “Debe tener un diseño amigable e
intutitivo al usuario”
RNF-022 “El tiempo de respuesta del sistema para
operaciones de carga de información deberá ser
como máximo 4 segundos con un ancho de banda
de 100 Mbps”
RNF-006: “ Habrá un servidor dedicado”
RNF-009: “ El sistema será desarrollado para
ejecutarse bajo el sistema operativo Windows XP”
RNF-019: “ El sistema usará MySQL ”
RNF-021 : “El servidor dedicado será como
mínimo P4 de 3 Ghz, 1 GB de RAM y disco duro
de 20 MB”
7. Arquitectura vs. Diseño
Una arquitectura significa crear una
infraestructura de software que soporte los niveles
de servicio (SLA) identificados para el sistema.
Diseño : que sucede cuando un usuario hace “click”
Arquitectura : qué sucede cuando “N” usuarios
hacen “click”
EJEMPLO: Votación Electrónica
¿Qué problemas potenciales tiene
la siguiente estructura de BD ?
PK
CodigoCandidato Votos
C1 5
C2 12
C3 27
9. SLA en Internet
1. Performance
2. Escalabilidad
3. Confiabilidad Todos están
relacionados
4. Disponibilidad
5. Extensibilidad Algunas soluciones
6. Mantenibilidad Algoritmos de balanceo de carga:
Round-robin
7. Manejabilidad
Round-robin con pesos
Basados en el tiempo de respuesta
Asignación de clientes a instancias (stickiness)
8. Seguridad
Monitorización de disponibilidad de instancias
Reintento de peticiones idempotentes
Soporte de balanceadores HW
Replicación de sesiones HTTP
Cluster de Servidores
10. Disponibilidad y Confiabilidad
• CONFIABILIDAD medida de la continuidad de
servicios “cumplidos” ( o equivalentemente, mide el
tiempo de fallas )
– MTTF Mean Time to Failure
– FIT Failures in Time = 1/MTTF ( Se mide en mil
millones de horas de operación = 109 )
– MTTR Mean Time to Repair ... Mide la interrupción del
servicio
– MTBF Mean Time Between Failure = MTTF + MTTR
• DISPONIBILIDAD Mide el cumplimiento del servicio
con respecto a la alternancia entre los 2 estados. Para
sistema no redundantes:
– Disponibilidad = MTTF / ( MTTF + MTTR )
11. Escalabilidad
• Comportamiento de una arquitectura cuando
únicamente aumenta la carga del sistema y los
demás parámetros se mantienen constantes.
Escalabilidad vertical: Aumentando el
numero de CPU’s y memoria de los
servidores
Escalabilidad horizontal: Aumentando
el número de servidores
12. Performance
ejecución
1
Tiempo de Respuesta
cola X
•
l no
¿k=n? 2
Peticiones ... Peticiones
llegando sí n m completadas
• Troughtput rechazo
k <= n
CPU
Disco
A queueing Model for a single tier server
MENASCE, Daniel; BARBARÁ, Daniel; DODGE, Ronald. “Preserving QoS of E-commerce sites Throrugh Self-Tunning: A Performance Model Approach”.
ACM, Conferencia de Comercio Electrónico, Florida, USA, 2001. Universidad George Mason
14. Causas Comunes a los problemas
La aplicación desarrollada teóricamente cumple con el RES y el
RDS, pero el usuario típico se queja : “El tiempo de respuesta está
lento”
Hay formas de medir la “experiencia” del usuario
Hay formas de medir la cantidad de usuarios actuales.
Hay que compararlo contra el RNF de la aplicación
Luego: el trabajo consiste en determinar el MOTIVO de la lentitud
Tema de discusión
Configuración de la JVM, Garbage Collector
BD Código Java desarrollado no es óptimo
ADS Arquitectura de la aplicación
LP Mala codificación de las sentencias SQL, se genera FULL SCAN
DAW Mal diseño de transacciones en la Base de Datos, se generan
?
bloqueos
Afinamiento del Sistema Operativo
Afinamiento del Servidor de Aplicaciones
15. Ejemplo
Ejemplo clásico del RES : RNF-022 “el tiempo de respuesta del sistema para operaciones
de carga de información deberá ser como máximo 4 segundos de espera con una ancho de
banda de 100 Mbps”