Aplicaciones Web J2EE y Requerimientos no funcionales

[ Una vista rápida ]

Abril 2009

Ing. Jorge Irey

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

Motivación

“Fuerzas” que afectan a un Puente:Carga muertaCarga VivaCarga DinámicaCarga ambiental

“Fuerzas” que afectan al Software:Requerimientos FuncionalesRequerimientos NO Funcionales

Software

RequerimientosFuncionales

Característicasen tiempo de

ejecución

Restriccionesde Tecnología

Restriccionesdel Negocio

Otras Características

SLA QoS

Motivación (2)

Requerimientos

del Negocio

Documento de Visión y Alcance

Requerimientos

del usuario

Requerimientos

Funcionales

Requerimientos

del Sistema

Atributos de

Calidad

Otros Requerimientos

No funcionales

Restricciones

Documento de Casos de Uso

Especificación de Requerimientos de

SofwareIEEE Std 830-1998

Restricciones: “Solamente podrán votar los

ciudadanos legalmente residentes en el extranjero”

Taxonomia de Requisitos no Funcionales

OPERACION

Visión delUsuario

FACILIDAD DE MANTENIMIENTO ¿ puedo

arreglarlo ?

FACILIDAD DE PRUEBA ¿ puedo

probarlo ?

FLEXIBILIDAD ¿ Puedo modificarlo ?

INTEROPERABILIDAD ¿ podré comunicarlo con otros sistemas ?

PORTABILIDAD ¿ podré utilizarlo en otra máquina ?

REUSABILIDAD ¿ podré reutilizar parte del software ?

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 ?

Modelo de McCall

Taxonomia de Requisitos no Funcionales

Modelo ISO 9126

RNF-001 “Debe tener un diseño amigable e

intutitivo al usuario”

RNF-002 y RNF-020 “El sistema deberá

considerar un arquitectura lógica de 3 capas”

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”

RNF-016 “A cada usuario empadronado se le

asignará un PIN”

RNF-014 “Se debe tener extrema seguridad para

la transferencia de información con respecto a los

votos”

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”

Arquitectura vs. Diseño

Diseño : que sucede cuando un usuario hace “click”

Arquitectura : qué sucede cuando “N” usuarios hacen “click”

Una arquitectura significa crear unainfraestructura de software que soporte los nivelesde servicio (SLA) identificados para el sistema.

CodigoCandidato Votos

C1 5

C2 12

C3 27

EJEMPLO: Votación Electrónica

¿Qué problemas potenciales tiene

la siguiente estructura de BD ?

PK

Tiers vs. Layers

VS.

Layer

Tier

SLA en Internet

1. Performance

2. Escalabilidad

3. Confiabilidad

4. Disponibilidad

5. Extensibilidad

6. Mantenibilidad

7. Manejabilidad

8. Seguridad

Todos estánrelacionados

Algoritmos de balanceo de carga:Round-robinRound-robin con pesosBasados en el tiempo de respuesta

Asignación de clientes a instancias (stickiness)Monitorización de disponibilidad de instanciasReintento de peticiones idempotentesSoporte de balanceadores HW

Replicación de sesiones HTTPCluster de Servidores

Algunas soluciones

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 )

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

Performance

• Tiempo de Respuesta

• TroughtputCPU

Disco

...

1

2

m

X

Peticiones

completadasPeticiones

llegando

¿ k = n ?no

sí

rechazo

k <= n

n

cola

ejecución

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

l

Causas Comunes a los problemas

Base de Datos

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”

Configuración de la JVM, Garbage Collector

Código Java desarrollado no es óptimo

Arquitectura de la aplicación

Mala codificación de las sentencias SQL, se genera FULL SCAN

Mal diseño de transacciones en la Base de Datos, se generan bloqueos

Afinamiento del Sistema Operativo

Afinamiento del Servidor de Aplicaciones

Hay formas de medir la “experiencia” del usuarioHay formas de medir la cantidad de usuarios actuales.Hay que compararlo contra el RNF de la aplicaciónLuego: el trabajo consiste en determinar el MOTIVO de la lentitud

Tema de discusión

BDADSLPDAW

?

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”

Preguntas

¡ Gracias por su atención !