arquitectura de softwareisis2503/... · 2010-10-13 · arquitectura de software punto de vista de...

DEPARTAMENTO DE SISTEMAS

Arquitectura de Software

Punto de Vista de Concurrencia


Agenda

•  Introducción

•  Punto de vista de Concurrencia

•  Desempeño y Escalabilidad


Introducción

•  Este punto de vista se utiliza para describir la concurrencia del sistema

•  Se busca hacer una asociación entre los elementos funcionales y las unidades de concurrencia

o  Identificar partes del sistema que se pueden ejecutar concurrentemente

o  Coordinación y control de las unidades de ejecución


Agenda





Punto de Vista Concurrencia

•  Concerns o  Cómo sacar provecho de la concurrencia en el sistema

o  Asociación entre elementos funcionales y tareas   Cuáles elementos funcionales deben estar aislados (diferentes

procesos)

  Cuáles elementos funcionales deben ejecutarse en un mismo proceso

o  Interprocess Communication (IPC)

o  Sincronización e Integridad

o  Inicio y finalización del sistema

o  Falla de las tareas

o  Reentrada



•  Modelos o  Modelo de concurrencia del sistema

  Asocia elementos funcionales con entidades de ejecución

  Procesos

  Grupos de procesos

  Threads

  IPC   Llamado a Procedimientos

  Coordinación por señales

  Datos compartidos



Tomado de [1] pagina 278



•  Actividades a desarrollar

o  Asociar elementos funcionales a tareas de procesamiento

o  Determinar el diseño de la multitarea

o  Políticas de uso en recursos compartidos

o  Priorización de tareas y procesos

o  Analizar situaciones de abrazos mortales

o  Analizar condiciones de carrera



•  Modelos de Estado

o  Utilizado para describir el conjunto de estados de los elementos del sistema en ejecución

  Estados

  Transiciones

  Eventos

  Acciones


Agenda





Desempeño y Escalabilidad

•  Calidad Deseada o  Habilidad del sistema para ejecutarse de forma

predecible dentro de los requerimientos de desempeño establecidos y manejar incrementos en los volumenes de procesamiento

•  Aplicación o  Sistemas con requerimientos de desempeño

complejos

o  Sistemas cuyas arquitecturas incluyen elementos con desempeño desconocido

o  Sistemas con requerimientos significativos de expansion



Vista Aplicabilidad

Funcional Revela la necesidad de cambios y compromisos con la estructura funcional

Información Ayuda a identificar recursos compartidos y requerimientos de transaccionalidad. Identifica obstaculos para desempeño y escalabilidad

Concurrencia Los modelos de este punto de vista cobran importancia bajo esta perspectiva

Desarrollo Se generan guias para favorecer el desempeño y escalabilidad durante el desarrollo

Despliegue Directamente relacionado con la escalabilidad y el desempeño. Estos modelos pueden verse afectados

Operacional Requerimientos de monitoreo



•  Concerns o  Tiempo de respuesta

  Cantidad de tiempo que le toma al sistema completar una interacción   Receptividad (Responsiveness)

  Actualizar una cuenta: 10 segundos   Cambio (Turnaround)

  Reporte de ventas (100 registros mensuales: 1 hora)

o  Rendimiento   Cantidad de trabajo que el sistema es capaz de hacer por

unidad de tiempo   Con 550 usuarios concurrentes 1 transacción 5 segundos

o  Escalabilidad   Habilidad del sistema para manejar incrementos de trabajo

  Número de requerimientos / tiempo   Incremento en la complejidad



•  Concerns o  Predictibilidad o  Requerimientos de Hardware o  Comportamiento bajo carga




•  Capturar los requerimientos de desempeño

o  Especificar los tiempos de respuesta requeridos

o  Especificar los requerimientos de rendimiento

o  Especificar los requerimientos de escalabilidad

•  Crear los modelos de desempeño

o  Identificar la estructura de desempeño crítica (procesos, nodos, enlaces, almacenamiento)

o  Identificar las métricas claves de desempeño

o  Estimar las métricas de desempeño



•  Analizar los modelos de desempeño o  Caracterizar las cargas de trabajo

o  Estimar el rendimiento

•  Llevar a cabo pruebas prácticas o  Estimar las métricas de desempeño

o  Llevar a cabo las pruebas

•  Evaluar contra los requerimientos o  Identificar los riesgos

o  Revisar los requerimientos

•  Iterar sobre la arquitectura



•  Tácticas Arquitecturales o  Optimizar el procesamiento repetitivo

  80% de las operaciones usan 20% de la aplicación

o  Reducir la competencia mediante la replicación

o  Priorizar el procesamiento

o  Consolidar cargas de trabajo relacionadas

o  Distribuir el procesamiento en el tiempo

o  Minimizar el uso de recursos compartidos

o  Particionar y paralelizar

o  Usar procesamiento asincrónico



•  Problemas

o  Objetivos imprecisos de desempeño

o  Modelos no realistas

o  Uso de medidas simplistar

o  Particiones inapropiadas

o  Suposiciones incorrectas sobre el ambiente y las plataformas de ejecución

o  Demasiados recursos compartidos / competencia


Disponibilidad

•  Tiempo planeado fuera de servicio •  Tiempo no planeado fuera de servicio •  Tiempo de reparación •  Recuperación de desastres


Disponibilidad

•  Capturar requerimientos de disponibilidad

o  Tipos de servicios ofrecidos

o  Definir niveles de servicios

o  Producir una agenda de disponibilidad

o  Crear el modelo de disponibilidad del sistema


Disponibilidad

Disponibilidad = Tiempo disponible del sistema / tiempo transcurrido

Ejemplo: Un sistema disponible de lunes a viernes de 9am a 5pm

Disponibilidad = 40 horas / 168 horas = 24%


Disponibilidad

Mean Time Between Failures (MTBF)

MTBF = Tiempo transcurrido / Numero de fallas

Mean Time to Repair (MTTR)

MTTR = Tiempo promedio para reparar una falla

Disponibilidad de Hardware = MTBF / (MTBF + MTTR)


Disponibilidad

•  Tácticas Arquitecturales o  Seleccionar hardware tolerante a fallas o  Seleccionar software tolerante a fallas o  Usar clustering o  Backups o  Definir planes de recuperación de desastres


29

Referencias

[1] Rozanski N, Woods E. “Software Systems Architecture” Addison-Wesley. 2005

arquitectura de softwareisis2503/... · 2010-10-13 · arquitectura de software punto de vista de...

Documents