El documento habla sobre requisitos no funcionales para aplicaciones web J2EE. Explica la taxonomía de requisitos no funcionales y conceptos como disponibilidad, escalabilidad y rendimiento. También analiza causas comunes de problemas relacionados con la base de datos, la arquitectura de la aplicación y el código.

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

8. Tiers vs. Layers
Layer
VS.
Tier

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

13. Causas Comunes a los problemas
Base de Datos

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”

16. Preguntas
¡ Gracias por su atención !