Rendimiento Capitulo 8

Redimiento o Performance es sobre la administración de los recursos de un sistema frente a tipos particulares de demanda para lograr un comportamiento aceptable en el tiempo. 

El rendimiento puede ser medido en términos de caudal y latencia para sistemas de tiempo real interactivos y embebidos, aunque el caudal es más importante en un sistema interactivo y la latencia es más importante en sistemas embebidos.

Los eventos pueden arribar en patrones predecibles, distribuciones matemáticas o ser inpredecibles.

Eventos de arribo periodico son aquellos que arriban a nuestro sistema en intervalos regulares de tiempo. Por ejemplo un evento podría llegar cada 10 milisegundos. Los eventos de arribo periodico son los más vistos en sistemas de tiempo real.

Arribo Estocastico significa que los eventos llegan de acuerdo a alguna distribución probabilistica.

Eventos de arribo esporadico, es de acuerdo a un patrón que no es ni periodico ni estocástico. Incluso estos, en ciertas circunstancias pueden ser caracterizados. Por ejemplo, podriamos saber que tendrá lugar algo así como 600 eventos en un minuto, o que habrá al menos 200 milisegundos entre el de arribo de dos eventos cualesquiera. (Esto podría describir un sistema en el que los eventos corresponden a tecleos de un usuario).

Escenario general de Rendimiento.

Origen del Estimulo: El estimulo llega ya sea de un origen (posiblemente multiple) externo o un origen interno.
Estimulo:  El estimulo son eventos llegando. El patrón de arribo puede ser periódico, estocástico, o esporádico,  caracterizado por parametros numericos.
Artefacto: El artefacto es el sistema, uno o más de sus componentes.
Ambiente: El sistema puede estar en varios modos operacionales, como ser, normal, emergencia, carga máxima, o sobrecarga.
Respuesta: El sistema debe procesar los eventos que llegan. Estos puede causar un cambio en el ambiente del sistema ( de modo normal a modo de sobrecarga.)
Medida de respuesta: Son el tiempo que toma el procesamiento de un evento que llega al sistema (latencia o un tiempo de entrega máximo), la variación en este tiempo (jitter), la cantidad de eventos que puede ser procesados en un intervalo de tiempo particular (caudal) o una caracterización de los eventos que no pueden ser procesados (tasa de fallos).

El rendimiento puede ser mejorado reduciendo la demanda o administrando los recursos de manera más apropiada. Reduciendo la demanda tendrá el efecto colateral de reducir la fidelidad o denegar el servicio a algún pedido. Administrar los recursos más apropiadamente se puede hacer mediante la programación/agendado, replicación, o simplemente incrementando los recursos disponibles.

Modificabilidad Capitulo 7

La modificabildad se trata del cambio y el costo en tiempo o dinero de hacer un cambio, incluyendo el grado en que esta modificación afecta otras funciones o atributos de calidad.

Los cambios puede ser realizados por desarrolladores, instaladores o usuarios finales, y estos cambios necesitan estar preparados para esto. Hay un costo de preparación para el cambio así como también hay un costo para hacer el cambio. Las tácticas de modificabilidad son diseñadas para prepararse para los cambios posteriores.

Las tacticas reducen el costo de generar un cambio incluyendo hacer modulos más pequeños, incrementando la cohesion, y reduciendo el emparejamiento.

Reducir el emparejamiento es una categoria estandar de tácticas que incluyen encapsulación, uso de un intermediario, restricción de dependencias, ubicación conjunta de responsabilidades relacionadas, refactorización, y abstracción de servicios comunes.

Incrementar la cohesión es otra táctica estandar que involucra a la separación de responsabilidades que no sirven al mismo proposito.

Defer binding es una categoria de tácticas que afecta el tiempo de construcción, tiempo de carga, tiempo de inicialización o tiempo de ejecución!

Tácticas de disponibilidad - Recuperación de fallas - Capitulo 5

Las tacticas de recuperación de fallas son refinadas en tácticas de preparación y reparación y tácticas de reintroducción.

Las tácticas de preparación y reparación están basadas en una variedad de combinaciones de reintentos computacionales o introducción de redundancia. Estos incluyen los siguientes.

Redundancia Activa (Hot Spare). Esta refiera a una configuración donde todo los nodos (activos o redundantes extras ) en un grupo de protección [0] reciben y procesan entradas identicas en paralelo, permitiendo la redundancia extra al mantener un estado sincronico con los nodos activos. Por que el redundante de respuesto posee un estado identica a el procesador activo, este puede asumir el rol de activo ante una falla en cuestión de milisegundos.

Redundancia pasiva (warm spare) Esto refiere a una configuración donde solo los miembros activos del grupo de protección procesan el trafico de entrada. una de sus funciones es la de proveer a los respuestos redundantes de las actualizaciones de estado periodicas. Por que el estado mantenido por los servicios redundantes está menos emparejado que el de los nodos activos en el grupo de protección.

Spare (cold spare) Cold Sparing refiera a una configuración donde el servicio redundante de un grupo de protección se mantiene fuera de servicio hasta que un intercambio por error (fail-over) ocurr, momento en el que un procedimiento de prendido y reinicio es iniciado en el servicio redundante antes de ser puesto en servicio.

Manejo de excepciones Una vez que una excepción ha sido detectada, el sistema deberia manejarla de algún modo. La cosa más sencilla, es dejar caer el sistema, pero por supuesto que es una idea terrible desde el punto de vista de la disponibilidad, usabilidad, capacidad de prueba, etc. El mecanismo utilizado para el manejo de la excepción depende largamente del ambiente de programación empleado, desde una simple función que devuelve un código de error a el uso de clases de excepción que contienen información de ayuda en relación a la falla, tal como el nombre, el origen y la causa que lanza la excepción.

Rollback Esta táctica permite al sistema revertir a un estado previo que estaba funcionando correctamente. después de la detección de una falla. Una vez que un buen estado es alcanzado, entonces la ejecución puede continuar. Esta táctica es a veces combinada con la táctica de redundancia activo o pasivo por lo que una vez que un rollback ocurre, una versión "en espera" del componente fallado es promovida al estado activo. El rollback depende de la copia de que un buen estado previo (un punto de chequeo) esté disponible del componente que está haciendo rollback.

Actualización de Software, es otra táctica de preparación y reparación que tiene como objetivo lograr una actualización "en servicio" de las imagenes de código executables de una manera que no afecte al servicio. Esto debe ser realizado como una función "parche" o una clase "parche" o una actualización de software "en-servicio" de poco impacto.

Reintento, La táctica de reintento asume que la falla es causada por una falla transitoria y el reintento de la operación debería resolverla. Esta táctica es usada en redes y en granjas de servidores donde las fallas son esperables y comunes.

Ignorar el comportamiento defectuoso esta táctica llama a ignorar los mensajes enviados de un origen particular cuando nosotros determinamos que esos mensajes son espurios.

La táctica de Degradación mantiene las funciones criticas del sistema en la presencia de fallas de componentes, dejando caer las funciones menos criticas. Esto se hace en circunstancias donde un componente falla "bonitamente" (licencia bestialistica del autor del Blog)

Reconfiguración intenta recuperar la falla de un componente reasignando responsabilidades a los recursos que dejaron de funcionar mientras mantiene alguna funcionalidad como sea posible.

[0] Un grupo de protección es un grupo de nodos procesando donde uno o más nodos son "activos", con los nodos restantes  en el grupo de protección sirviendo como un servicio redundante.

Los muchos contextos de la Arquitectura de Software Capitulo 3

La arquitectura reside en cuatro contextos deferentes:

1. Técnico. El contexto técnico incluye el logro de los requerimientos de atributos de calidad. También incluye la tecnología actual.
2. El ciclo de vida del proyecto. Independientemente de la metodología de desarrollo de software que utilices, deberías hacer un análisis de rentabilidad para el sistema. comprendiendo los requerimientos de gran importancia en la arquitectura, analizar o evaluar la arquitectura, implementar y probar el sistema basado en la arquitectura, y asegurar que la implementación  se ajusta a la arquitectura.
3. Negocio. El sistema creado desde la arquitectura debe satisfacer los objetivos de negocio de una amplia variedad de las partes interesadas, cada uno de los cuales tiene diferentes expectativas para el sistema. La arquitectura es también influenciada por e influye la estructura de desarrollo de la organización.
4. Profesional. Usted debe tener ciertas habilidades y conocimientos para ser un arquitecto, y hay ciertas obligaciones que debe realizar como un arquitecto. Estas son influenciadas no solo por el curso y lectura sino también por tus experiencias.

Los StakeHolders o Partes Interesadas.

Una arquitectura tiene algunas influencias que conducen a su creación, y su existencia tiene un impacto en el arquitecto, la organización y potencialmente, la industria. Nosotros llamaremos a estos ciclo el Ciclo de Influencia de la Arquitectura (Arquitecture Influence Cycle).

Gracias por leer mi traducción que vengo haciendo de los resumenes de cada cápitulo del Libro Software Architecture in Practice. Espero que sepan disculpar algunas debilidades de mi traducción (y/o del Google Translate en varias ocasiones) que no es la mejor pero mi objetivo es dejar algún tipo de aporte de un libro que me parece interesante. 

En el Proximo Post arranca la Parte 2 con los Atributos de Calidad con el Capitulo 4 Entendiendo los Atributos de Calidad.

Por que la arquitectura de software es importante Capitulo 2

La arquitectura de software es importante por una amplia variedad de razones técnicas y no técnicas.
Nuestra lista incluye las siguientes:

1. Una arquitectura inhibirá o habilitará en un sistema el manejo de los atributos de calidad.
2. Las decisiones tomadas en una arquitectura te permitirá pensar y administrar los cambios mientras el sistema evolucione.
3. El análisis de una arquitectura permite predecir tempranamente las cualidades de un sistema.
4. Una arquitectura documentada mejora la comunicación entre las partes interesadas.
5. La arquitectura es el portador de las más tempranas y por lo tanto más fundamentales decisiones de diseño más-difíciles-de-cambiar.
6. Una arquitectura define un conjunto de restricciones y su posterior implementación.
7. La arquitectura dicta la estructura de una organización, o vice versa.
8. Una arquitectura puede proveer la base del prototipado evolutivo. [0]
9. Una arquitectura es el artefacto clave que permite al arquitecto y al administrador del proyecto razonar acerca del costo y de las estimaciones de tiempo.
10. Una arquitectura puede ser creada como un modelo transferible, reusable que forma el corazón de una linea de producto.
11. El desarrollo basado-en-arquitectura enfoca la atención en el ensamblado de componentes, más que en la simple creación.
12. Una arquitectura canaliza la creatividad de los desarrolladores, reduciendo la complejidad  y diseño del sistema.
13. Una arquitectura puede ser la base para el entrenamiento de los nuevos miembros del equipo.

[0] Cabe aclarar que en este sentido se dice que la arquitectura puede ser analizada y prototipada como un sistema esquelético. Que como tal puede ser la base para la creación de otros sistemas similares. 

Parte 1 Capitulo 2

Software Architecture in Practice.

La proxima en Capitulo 3 es Los contextos de la arquitectura de software.

Capitulo que me resulto pesado de leer o que no lei con mucha atención así que me ayudará a repasar.