Software Architecture in Practice: Parte 2-1: Atributos de Calidad

Esta entrada nace como un aproximación a la asignatura de Arquitectura de Software de la Especialización en Procesos de Software que estoy cursando en la Universidad San Buenaventura en Santiago de Cali, Colombia.

El objetivo de esta entrada dar a conocer apartes, síntesis y opiniones acerca del libro Software Architecture in Practice.

Parte 2-1: Atributos de Calidad

La Arquitectura y los Requerimientos.

Sin importar la fuente, todos los requerimientos se pueden tipificar en:

• Requerimientos Funcionales: Definen lo que el sistema debe hacer; y como debe comportarse o reaccionar ante estímulos durante el tiempo de ejecución.

• Atributos de Calidad: Son el nivel de calidad (medible o testeable) que debe presentar un requerimiento funcional.

• Restricciones: Son decisiones de diseño con ningún grado de libertad. Es una decisión de diseño que ya ha sido tomada.

La Arquitectura responde a cada uno de estos tipos de requerimientos así:

• Requerimientos Funcionales: La Arquitectura satisface estos requerimientos al asignar las responsabilidades apropiadas a cada elemento de arquitectura.

• Atributos de Calidad: La Arquitectura satisface estos requerimientos diseñar las diferentes estructuras, comportamientos y elementos de arquitectura.

• Restricciones: La Arquitectura satisface estos requerimientos al aceptar las decisiones de diseño ya tomadas; e incorporarlas al diseño y asignación de responsabilidades de las diferentes estructuras, comportamientos y elementos de dicha arquitectura.

Definición de Atributos de Calidad.

Un Atributo de Calidad es una propiedad medible o testeable de un sistema, que es usado para indicar el nivel de satisfacción que el sistema tiene, respecto a las necesidades de los stakeholders.

Los atributos de calidad se pueden dividir en aquellos que describen una propiedad del sistema en tiempo de ejecución (desempeño, disponibilidad, etc) y aquellos que describen una propiedad del desarrollo de dicho sistema (modificabilidad y testeabilidad).

Escenarios de Calidad.

Los atributos de calidad se especifican mediante Escenarios de Calidad (o Escenarios de Atributos de Calidad). Un escenario de calidad consta de 6 partes:

• Fuente del Estimulo: Entidad que genera el estimulo. Ej: Un Usuario o Un Sistema de Información.

• Estimulo: Condición que requiere de una respuesta cuando este llega al sistema.

• Ambiente: Contexto (u condiciones) bajo los cuales ocurren los estímulos. Ej: Sistema sobrecargado u operación normal, etc.

• Artefacto: Componente o componentes, que son afectados por el estimulo.

• Respuesta: Actividad que nace como resultado del estimulo llega al sistema.

• Medida de la Respuesta: Medida contra la cual se evaluara y testeara la respuesta al estimulo.

Tácticas de Arquitectura.

Una Táctica de Arquitectura es una decisión de diseño que afecta la respuesta de un atributo de calidad. Una táctica se focaliza en una única respuesta de atributo de calidad.

Un Patrón de Arquitectura puede ser considerado como un conjunto de Tácticas de Arquitectura que afectan las respuestas de diferentes Atributos de Calidad.

Las tácticas de arquitectura de puede clasificar así:

• Tácticas de Asignación de Responsabilidades. Por ejemplo:
• Identificar las responsabilidades mas importantes.

• Determinar como estas responsabilidades serán asignadas a elementos en tiempo de ejecución (módulos, componentes, conectores, etc); y cuales serán asignadas a elementos de infraestructura (servidores, bases de datos, etc).

• Tácticas de Coordinación de Elementos. Por ejemplo:
• Identificar los elementos de arquitectura que deberán coordinarse; y cuales no deberán coordinarse.

• Determinar las características de la coordinación: Concurrencia, tiempos, consistencia, etc.

• Tácticas de Modelado de Datos. Por ejemplo:
• Selección de las abstracciones para los datos mas relevantes; sus operaciones y propiedades. Se debe determinar como los datos serán creados, inicializados, accedidos, almacenados, actualizados, transformados y eliminados.

• Definición de la metadata necesaria para la correcta interpretación de los datos.

• Organización de los datos en una base de datos relacional, no relacional y/o sistema de archivos.

• Tácticas de Gestión de Recursos. Por ejemplo:
• Identificar los recursos (CPU, RAM, Disco Duro, Pool de Conexiones, Pool de Hilos, etc) que deben ser gestionados; y determinar los limites de cada uno.

• Determinar que elementos del sistema gestionara cada recurso.

• Determinar como los recursos serán compartidos.

• Determinar el impacto en el sistema cuando los recursos estén saturados.

• Tácticas de Mapeado de los Elementos de Arquitectura. Por ejemplo:
• Mapear los módulos y los componentes (y conectores) entre si. Es decir, determinar que componentes son creados en que modulo.

• Mapear los componentes (y conectores) al hardware que los procesara.

• Mapear los datos y el modelo de datos, a lo repositorios de almacenamiento de datos.

• Mapear los módulos y componentes (y conectores) a las unidades de despliegue.

• Tácticas de Asignación de Atributos*. Por ejemplo: [Pendiente].

• Tácticas de Selección de Tecnologías. Por ejemplo:
• Determinar que tecnologías están disponibles para satisfaces las decisiones tomadas en las otras tácticas.

• Determinar si que herramientas están disponibles para soportar las tecnologías seleccionadas.

• Determinar los efectos secundarios de las tecnologías seleccionadas.

• Determinar si las tecnologías seleccionadas son compatibles entre si y con las restricciones de diseño.