1

Arquitecturas y Calidad de Software: Tactics

Humberto Cervantes MacedaAbril 2008

V1.0

2

Introduciendo las Tácticas

¿ Qué son las tácticas ?Son decisiones de diseño que influencian el control de la respuesta de un atributo de calidad.

Las tácticas buscan controlar respuestas a estímulos

Las tácticas que se presentan a continuación han sido usadas por los arquitectos durante años

Consideraciones adicionalesLas tácticas pueden organizarse de forma jerárquica donde cada táctica refina aquella de la cual se derivaLos patrones arquitectónicos empaquetan a las tácticas.

Un patrón puede empaquetar varias tácticas

3

Disponibilidad

RecordandoDisponibilidad: Se concentra en las fallas del sistema y consecuencias asociadas

VocabularioUn problema (failure) ocurre cuando un sistema deja de entregar un servicio de acuerdo a la especificación. El problema es observable por los usuarios.Una falla (fault) o una combinación de ellas puede causar un problema. No son observables por usuarios.La recuperación o reparación es un aspecto importante en la disponibilidad

Las tácticas que se presentan tratan de evitar que las fallas se vuelvan problemas o bien limitar los efectos de las fallas para facilitar la reparación

4

Tácticas de disponibilidad

Escenarios generales de disponibilidad

Objetivo de tácticas de control de disponibilidad

5

Tácticas de disponibilidad (2)

Detección de fallasPing / echo

Un componente emite un ping y espera recibir un eco en un tiempo definido. Generalmente usado para asegurarse si el canal de comunicación funciona adecuadamente o si distintos participantes de una colaboración están presentes.

Latido (heartbeat)Un componente emite una señal de latido de forma periódica y otro componente la escucha. Si no se recibe el latido, se asume que el componente falló y se notifica a un componente de corrección. El latido puede además cargar datos.

ExcepcionesLas excepciones permiten reconocer fallas

6

Tácticas de disponibilidad (3)

Recuperación de fallasConsisten en prepararse para la recuperación y realizar la reparación del sistema.Voto

Varios procesos que reciben entradas equivalentes realizan un calculo y envían el resultado a un votante. Si el votante detecta un comportamiento erróneo de un proceso, lo declara fallido.

Redundancia activaVarios componentes redundantes responden a eventos de forma paralela, es decir, todos están en el mismo estado. La respuesta de uno de los componentes es usada y las demás desechadas. Si ocurre una falla, el tiempo de recuperación es muy corto.

Es necesario un mecanismo de sincronización para asegurar que los mensajes enviados a uno de los componentes redundantes lleguen a todos

7

Tácticas de disponibilidad (4)

Recuperación de fallas (2)Redundancia pasiva

Un componente (primario) responde a eventos e informa a otros componentes (backups) de actualizaciones que deban realizar en su estado. Si ocurre una falla en el primario, el sistema debe asegurar que el estado del backup sea suficientemente reciente antes de que tome el mando.

La sincronización es responsabilidad del componente primario

RepuestoUna plataforma de repuesto en reposo es configurada para remplazar componentes que fallan. Debe ser rebooteada a la configuración adecuada y el estado debe ser inicializado cuando ocurre una falla.

La realización de checkpoints y el registro en bitácora de los cambios del estado permiten llevar al repuesto al estado correcto.

8

Tácticas de disponibilidad (5)

Recuperación de fallas (3)Operación en “sombra”

Un componente que falló previamente puede ejecutarse en “modo sombra” por un periodo para asegurarse de su buen funcionamiento antes de que se restaure el servicio.

Re-sincronización de estadoLas tácticas de redundancia activa y pasiva requieren que el estado del componente sea restablecido antes de que retome servicio. Existen distintos enfoques, pero es preferible que la restauración se haga con un solo mensaje.

Checkpoint / rollbackUn checkpoint es un registro de un estado consistente creado de forma periódica o en respuesta a eventos específicos. Si un sistema falla de manera inusual con un estado que se puede detectar como inconsistente, se puede restaurar usando un checkpoint y una bitácora de transacciones que ocurrieron a partir de la falla.

9

Tácticas de disponibilidad (6)

Prevención de fallasRetiro de servicio

Esta táctica implica el retiro a nivel de la operación de un componente del sistema para realizar actividades de prevención de fallas. El retiro puede ser automático o manual, y en ambos casos el sistema debe ser diseñado para soportar esto.

TransaccionesUna transacción es la agrupación de varios pasos secuenciales de tal forma que se puedan deshacer de un solo golpe. Se usan para evitar que queden datos afectados si un paso del proceso falla y para evitar colisiones entre hilos simultáneos que acceden recursos compartidos.

Monitor de procesosCuando se detecta una falla en un proceso, un proceso de monitoreo puede retirar el proceso defectuoso y crear una nueva instancia de este a un estado apropiado.

10

Tácticas de disponibilidad (7)

Resumen de tácticas

11

Modificabilidad

RecordandoLa modificabilidad se enfoca en el costo del cambio. Se concentra en

Qué artefacto puede cambiar y cómo puede cambiarCuándo ocurre el cambio y quien lo hace

Escenarios generales de modificabilidad

12

Tácticas de modificabilidad (1)

Objetivo tácticas de modificabilidad

Tacticas organizadas de acuerdo a objetivosLocalizar modificaciones: Reducción de cantidad de módulos afectados por un cambioPrevenir efecto de ondas: Limitar modificaciones a ciertos módulosDeferir tiempo de ligado: Controlar tiempos y costos de implantación

13

Tácticas de modificabilidad (2)

Localización de modificacionesMantener coherencia semántica

Se refiere a relaciones entre responsabilidades de un módulo. El objetivo es que estas responsabilidades trabajen juntas sin depender mucho de otros módulos. Se puede lograr al abstraer servicios comunes (ej. middleware)

Anticipar cambios esperadosLa asignación de responsabilidades de los módulos se puede hacer evaluando los cambios previstos con el fin de evitar modificar demasiados módulos

Generalizar el móduloEl módulo es configurado por parámetros o un lenguaje

Limitar opciones posiblesLas modificaciones pueden afectar muchos módulos. Esto se puede limitar mediante la restricción de posibles opciones. Ej. plugin de navegador.

14

Tácticas de modificabilidad (3)

Prevención de efecto de ondaUn “efecto de onda” es la necesidad de realizar cambios a módulos que no se ven afectados directamente por el cambio.Tipos de dependencias entre módulos

Sintaxis de datos enviados o recibidos y de interfacesSemántica de datos y servicios (interfaces)Secuencia de datos y de controlIdentidad de interfaz (A tiene varias interfaces, B espera una en particular)Emplazamiento. Un módulo espera encontrar a otroCalidad de servicio / datos provistos (ej. precisión)Presencia de AComportamiento con respecto a recursos

15

Tácticas de modificabilidad (4)

Prevención de efecto de onda (2)Encapsulamiento

Responsabilidades públicas disponibles a través de interfaces con el fin de evitar propagación de cambios

Conservación de interfaces existentesSe pueden agregar interfaces, adaptadores, substitutos de interfaz requerida que debe ser borrada

Restringir rutas de comunicaciónMinimizar número de módulos con quien que consumen datos producidos por un modulo

Uso de intermediarioRepositorios (datos), patrones de diseño diversos (fachada, puente, mediador), trader, administrador de recursos

Dependencias entre componentes que no sean semánticas

16

Tácticas de modificabilidad (5)

Retraso de tiempo de ligadoEl retrasar el tiempo de ligado permite satisfacer el momento de implantación del cambio y el hecho de que sea gente que no desarrolla quien los haga

Algunas tácticasRegistro en tiempo de ejecuciónArchivos de configuraciónPolimorfismoRemplazo de componentes en tiempo de cargadoAdherencia a protocolos definidos para ligado en tiempo de ejecución

17

Tácticas de modificabilidad (6)

Resumen de tácticas

18

Desempeño

Escenarios generales de desempeño

19

Tácticas de desempeño

RecordandoEl objetivo de las tácticas de desempeño es generar la respuesta a un evento que llega al sistema dentro de un tiempo definido

La latencia es el tiempo entre la llegada y la generación de la respuesta

Cuando llega un evento, el sistema lo procesa o está bloqueado

Dos contribuyentes básicos al tiempo de respuesta son el demanda de recursos y el tiempo bloqueado

Tres categorías de tácticasDemanda, administración y arbitraje de recursos

20

Tácticas de desempeño (2)

Demanda de recursosSe puede reducir la latencia mediante la reducción de recursos requeridos para procesar los eventosAumento de eficiencia computacional

Mejora de algoritmosReducción de encabezados (overhead)

Ej. Reducción de intermediariosAdministrar cantidad de eventos

Ej. Reducción de tiempo de muestreo de variables produce menos eventos

Control de frecuencia de muestreoEj. Poleo menos frecuente de colas de eventos que han llegado al sistema (para eventos que llegan al sistema)

Limitar tiempos de ejecuciónEj. número de iteraciones de algorítmo

Limitar tamaño de colas

21

Tácticas de desempeño (3)

Administración de recursosAún si demanda de recursos no se puede controlar, su administración puede afectar el tiempo de respuestaIntroducir concurrencia

Procesamiento paralelo de peticiones puede permitir reducción de tiempo bloqueado. Concurrencia se puede complementar con balanceo de carga.

Mantener copias múltiples de datos o cálculosEj. realizar cálculos en clientes pesados, caches (pero hay que tener cuidado con sincronización)

Aumentar recursos disponiblesProcesadores más veloces, más memoria, redes más rápidas... Se debe sin embargo hacer una evaluación del costo incurrido.

22

Tácticas de desempeño (4)

Arbitraje de recursosEn el momento en que hay competencia por un recurso, este debe ser calendarizado. El arquitecto debe escoger una estrategia de calendarización apropiada.Una política de calendarización se compone de dos partes: asignación de prioridad y despacho.

La asignación puede ser tan simple como FIFO o bien estar atada a la petición o su significado semántico

Políticas de calendarizaciónFIFOCalendarización con prioridad fijaCalendarización con prioridad dinámicaPrioridad estática

23

Tácticas de desempeño (5)

Resumen de tácticas

24

Seguridad

Escenarios generales de seguridad

25

Tácticas de seguridad

Categorías de tácticas de seguridadResistencia a los ataquesDetección de ataquesRecuperación de ataques

Objetivo de las tácticas de seguridad

26

Tácticas de seguridad (2)

Resistencia a los ataquesAutentificación de usuarios

Passwords, certificados digitales, etc...Autorización de usuarios

Significa asegurar que un usuario autentificado tiene derechos de acceso y modificación a datos y servicios

Patrones de control de accesoMantenimiento de confidencialidad de datos

Aplicación de encriptamiento a lazos de comunicaciónMantenimiento de integridad

Información redundante, checksums...Limitar exposición

Limitar servicios asignados a cada hostLimitar acceso

Ej. Firewalls

27

Tácticas de seguridad (3)

Detección de ataquesDetección de intrusos

Sistema de detección de intrusos.

Recuperación de ataquesRestauración de estado

Tácticas se empalman con las de disponibilidad

Identificación de ataquesMantenimiento de traza para auditorías. La traza contiene una lista de transacciones junto con identificación de información.

28

Tácticas de seguridad (4)

Resumen de tácticas

29

Facilidad de prueba

Escenarios generales de facilidad de prueba

30

Tácticas de facilidad de prueba

El objetivo de las tácticas de facilidad de prueba es facilitar las pruebas cuando un incremento en el desarrollo es completado

Categorías de las tácticasProveer entradas y salidasMonitoreo interno

31

Tácticas de facilidad de prueba (2)

Administración de entradas y salidas para pruebasGrabación / reproducción

Captura de información que cruza una interfaz que se usa como entrada para una prueba

Separación de interfaz e implementaciónFacilita la substitución de implmentaciones para fines de pruebas. En particular reemplazo por stubs

Interfaces de prueba especializadasInterfaces distintas a las interfaces funcionales de los componentes que facilitan la realización de pruebas

32

Tácticas de facilidad de prueba (3)

Monitoreo internoMonitores incorporados

Se pueden introducir interfaces de monitoreoEj: JMX

Resumen de tácticas de facilidad de prueba

33

Usabilidad

Escenarios generales de usabilidad

34

Tácticas de usabilidad

La usabilidad se enfoca en que tan sencillo es para el usuario realizara una tarea deseada y el tipo de soporte que el sistema le provee al usuario

Dos tipos de tácticas soportan usabilidadTácticas de tiempo de ejecuciónTácticas de tiempo de diseño

35

Tácticas de usabilidad (2)

Tácticas de tiempo de ejecuciónLa usabilidad se ve mejorada al dar retroalimentación al usuario sobre lo que hace el sistema y al permitirle realizar operaciones tales como cancelar, deshacer, etc..La iniciativa de la interacción entre humano y máquina la puede tomar el usuario, el sistema o ambos

Ej. Botón “Cancel” es inciativa de usuario. Mensaje de “Cancelling” es del sistema, es entonces iniciativa mixta

Cuando el sistema toma la iniciativa, necesita de un modelo que puede ser

Modelo del usuario (conocimiento, comportamiento)Modelo de la tarea (ej. asistente word)Modelo del estado del sistema (ej. tiempo para copiar archivos en windows)

36

Tácticas de usabilidad (3)

Tácticas de tiempo de diseñoSeparación de la interfaz de usuario del resto de la aplicación

Es un refinamiento de la táctica de coherencia semántica dentro de la modificabilidad ya que se localizan los cambios esperadosSe implementa con patrones tales como Model View Controller

Resumen de tácticas