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.

Software Architecture in Practice: Parte 1: Introducción

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 1: Introducción

Definición de Arquitectura de Software.

La definición de arquitectura de software que maneja el libro es:

La arquitectura de software de un sistema es un conjunto de estructuras requeridas para razonar o entender acerca del sistema, las cuales comprenden elementos de software, las relaciones entre ellos, y las propiedades de las dos (los elementos y las relaciones).

Estructuras y Vistas.

Para razonar o entender la arquitectura de un sistema de software, se hacen uso de los conceptos de estructuras y vistas.

• Una estructura es el conjunto de elementos de software, las relaciones entre ellos, y las propiedades de las dos (los elementos y las relaciones).

• Una vista es la representación coherente (comprensible) de un conjunto de estructuras de software acorde aun conjunto (o subconjunto) de stakeholders. 

El libro define 3 tipos de estructuras de software, así:

• Estructuras de Módulos: muestran como un sistema esta estructurado en función de un conjunto de unidades de código y/o datos.

• Estructura de Descomposición: Se muestra la descomposición de cada módulo en submódulos.

• Estructura de Uso: Se muestra la relación de uso entre los módulos.

• Estructura por Capas: Aquí los módulos son llamados Capas. Una capa provee de una serie de servicios a través de una interfaz claramente definida. Se muestra la relación de los módulos mediante una estructura por capas.

• Estructura de Generalización/Especialización: Aquí los módulos son llamadas Clases. Se muestra la relación de herencia e implementación entre clases e interfaces.

• Estructura de Datos: Aquí se muestra las estructuras estáticas de los datos en términos de entidades de datos y sus relaciones.

• Estructuras de Componentes y Conectores: muestran como el sistema esta estructurado en función de los elementos que tienen un comportamiento en tiempo de ejecución (componentes) y sus relaciones (conectores).

• Estructura de Servicios:  Aquí los componentes son llamados Servicios. Se muestra la interoperabilidad entre los servicios mediante mecanismos de coreografía y/o orquestación.

• Estructura de Concurrencia: Aquí los conectores son llamados Mecanismos de Comunicación. Se muestra los detalles de procesamiento en paralelo de los componentes y los mecanismos de comunicación entre estos para su coordinación.

• Estructuras de Asignación: muestran como el sistema se relaciona con su ambiente (servidores, redes, equipos de desarrollo, etc). 
• Estructura de Despliegue: Se muestra como los componentes de software están asignados elementos puntuales de hardware de procesamiento y comunicación.

• Estructura de Implementación: Se muestra como los módulos son mapeados a la estructura de archivos (o carpetas) en los ambientes de desarrollo, pruebas y producción.

• Estructura de Asignación de Trabajo: Se muestran la distribución y asignación de trabajo de los módulos al equipo de trabajo.

Patrones de Arquitectura.

Un Elemento de Arquitectura se puede definir como un Modulo o como un Componente o como un Conector, dependiendo del tipo de estructura del que estemos hablando.

Tomando en cuenta esto, se define un Patrón de Arquitectura a un composición puntual de elementos de arquitectura que soluciona un problema en particular y que dicha composición ha resultado ser útil y valida a través del tiempo.

Un Patrón de Arquitectura define los tipos de elementos de arquitectura que se usaran y la forma en que se ínter-relacionaran entre si para resolver el problema que pretender solucionar.

Ejemplos de Patrones para las Estructuras de Módulos:

• Patrón por Capas: En este patrón la relación de uso entre los elementos de arquitectura es estrictamente unidireccional. En una estructura estricta por capas, una capa solo puede hacer uso de los servicios expuestos por la capa inmediatamente inferior. Nunca una capa podrá hacer uso de los servicios expuestos por capas superiores.

Ejemplos de Patrones para las Estructuras de Componentes y Conectores:

• Patrón de Repositorio de Datos: Este patrón contempla componentes y conectores que pueden crear, almacenar y acceder datos persistentes.

• Patrón Cliente Servidor: En este patrón los componentes son los clientes y los servidores; y los conectores son los protocolos de comunicación y mensajes entre estos.

Ejemplos de Patrones para las Estructuras de Asignación:

• Patrón Multinivel: En este patrón se describe como se distribuyen y se asignan los componentes de un sistema en subconjuntos de hardware y software; conectados mediante algún mecanismo de comunicación.

Importancia de la Arquitectura de Software.

La arquitectura de software es importante por una variedad de razones tanto técnicas como no técnicas. Algunas de ellas son:

1. Una Arquitectura habilitara o deshabilitara atributos de calidad específicos para un sistema.
2. Las decisiones realizadas por la Arquitectura permiten que se razone (entender) acerca del sistema y manejar el cambio que este deberá tener en el tiempo.
3. En análisis de una Arquitectura permite la predicción temprana de los atributos de calidad de un sistema.
4. Una Arquitectura documentada mejora la comunicación entre los stakeholders.
5. La Arquitectura se encarga de definir y tomar, de manera temprana, las decisiones de diseño mas difíciles de cambiar en el tiempo.
6. La Arquitectura restringe el diseño y el desarrollo del sistema.
7. La Arquitectura define la organización del equipo de trabajo y viceversa.
8. La Arquitectura provee las bases para el prototipado evolutivo.
9. La Arquitectura provee de los artefactos clave para la definición del costo y cronograma del proyecto.
10. Una Arquitectura puede ser reutilizada de tal forma que se convierte en la base de las lineas de productos.
11. La Arquitectura canaliza y restringe la creatividad de los desarrolladores, y la complejidad del diseño.
12. La Arquitectura es la base para el entrenamiento de nuevos miembros del equipo de desarrollo y del proyecto.

Los Contextos que influencian la Arquitectura de Software.

Acorde al libro los contextos en los que esta enmarcada la Arquitectura de Software son:

• Contexto Técnico: Cual es el rol técnico que juega la Arquitectura en el sistema o sistemas en los que hace parte? El rol técnico que juega la Arquitectura se puede simplificar en:

• La Arquitectura habilitara o deshabilitara atributos de calidad específicos para un sistema.

• La Arquitectura estará limitada por el ambiente técnico que exista en la organización al momento en el cual estará siendo diseñada.

• Contexto del Ciclo de Vida del Proyecto: Como la Arquitectura de Software se relaciona con las fases del ciclo de vida del desarrollo de software, del proyecto y del producto?. Sin importar de la metodología de desarrollo de software que se este usando (Cascada, Iterativo, Agile, Model Driven Development), el Arquitectuoa debe definir:

• La justificación técnica de la Arquitectura del proyecto en base a los requerimientos de negocio.

• Identificar los Requerimientos de Negocio Arquitecturalmente significativos.

• Crear y/o seleccionar la Arquitectura, documentarla y comunicarla.

• Analizar o Evaluar la Arquitectura.

• Implementar y Probar el sistema en base a la Arquitectura.

• Asegurarse que la implementación se adhiera a la Arquitectura.

• Contexto del Negocio: Como la Arquitectura de Software afecta el modelo de negocio y operativo de la organización? El sistema creado por la Arquitectura deberá:

• Satisfacer los objetivos y requerimientos de negocio de los stakeholder.

• Adherirse a la estructura organizacional de la organización.

• Contexto Profesional: Cual es el rol del Arquitecto de Software dentro de la organización y dentro del proyecto? El arquitecto deberá tener las siguientes habilidades desarrolladas para tener éxito:

• Habilidades de Liderazgo y Comunicación: 
• Comunicación: Comunicar efectivamente las ideas, conceptos, problemas y soluciones a los stakeholders.
• Colaboración: Lograr el involucramiento de los stakeholder en el proceso de arquitectura.
• Claridad: Articular la Arquitectura en una manera clara y concisa en los términos mas apropiados para cada tipo de stakeholder.
• Traducción: Lograr traducir los requerimientos de negocio, en requerimientos arquitecturalmente significativos y atributos de calidad.

• Conocimiento Técnico:
• Technical Depth: Aquello que se sabe y se domina.
• Technical Breadth: Aquello que se sabe que existe, pero no se domina.

• Conocimiento del Negocio.
• Mejora la comunicación con las áreas de negocio.
• Permite entender mejor los objetivos, problemas y tendencias del negocio.
• Lograr confianza con las áreas de negocio.
• Diseñar la Arquitectura de una manera que permita manejar futuros cambios.
• Ayuda a determinar de mejor forma los patrones de arquitectura.

• Dominio de las Metodologías y Pensamiento Estratégico (sistemico).
• Proceso de Desarrollo en Cascada (Watefall).
• Proceso de Desarrollo Iterativos e Incremental (RUP).
• Proceso de Desarrollo basados en Extremme Programming (XP).
• Proceso de Desarrollo basados en Agile (Scrum).
• Proceso de Desarrollo basados en Lean Sofrtware Development.
• Practicas de Diseño basados en Test Driven Development (y ATDD y BDD).
• Practicas de Diseño basados en Domain Driven Development (DDD).
• Practicas de Diseño basados en Model Driven Development (MDD).
• Practicas de Diseño basados en Feature Driven Development (FDD).

• Tener la sabiduría para identificar cuando se aplican y cuando no se aplican estos procesos y practicas.