Arquitectura de software - Parte 2

¡Hola a todos!

Para continuar con la segunda parte sobre Arquitectura de Software me centraté en el Proceso de definición y los distintos Atributos de calidad de la Arquitectura.

Tiempo de lectura estimado: 5-6 minutos.

Antes de comenzar, me gustaría recordar que en la primer parte sobre Arquitectura de Software vimos como introducción a la temática una definición de arquitectura, su propósito, quienes la influencian y finalmente el rol del arquitecto. Sigamos ahora con el proceso de definición de la arquitectura y sus atributos de calidad.

El Proceso de Definición de la Arquitectura es el proceso en el que deberíamos capturar las necesidades de los stakeholders, diseñar una arquitectura que cumpla con esas necesidades y describirla claramente sin ambigüedades.

Como arquitectos deberíamos resolver qué es significativo para la arquitectura y que no. Podríamos decir que algo es significativo para la arquitectura si tiene un impacto en la estructura del sistema o en las propiedades de calidad más importantes.

Las siguientes actividades deberían ser actividades de soporte del Proceso de definición de la arquitectura:

• Definir el alcance inicial y el contexto: consiste en definir claramente los límites del comportamiento del sistema, sus responsabilidades y el contexto operacional y organizacional
• Identificar e involucrar a los stackeholders: esta actividad se enfoca particularmente en crear una relación de trabajo con ellos, ya que cumplirán un rol importante en la definición de la arquitectura
• Capturar necesidades: consiste en entender las necesidades de cada grupo de stakeholders y las prioridades que estos ponen en cada necesidad. Tener en cuenta que tanto sus necesidades como sus prioridades podrían cambiar durante la definición de la arquitectura
• Definir la arquitectura
• Crear un esqueleto de la arquitectura 

 

Proceso de definición de la Arquitectura

Veamos ahora el proceso y sus actividades...

Consolidar las entradas
Entender, validar y refinar la definición del alcance, la definición del contexto y las necesidades de los stakeholders

Identificar escenarios
Identificar el conjunto de escenarios relevantes a la arquitectura

Identificar estilos de arquitectura relevantes
Identificar uno o más estilos de arquitectura que pueden ser usados como base para la arquitectura

Producir una arquitectura candidata
Producir una primera arquitectura (borrador) para el sistema que puede actuar como base para una evaluación de la arquitectura y posterior refinamiento

Explorar opciones de arquitectura
Explorar distintas posibilidades arquitectónicas para el sistema y escoger la mejor posibilidad 

Evaluar la arquitectura con stakeholders
Evaluar la arquitectura con los stakeholders, capturar los problemas y deficiencias y lograr la aceptación de la arquitectura por parte de los stakeholders

Retrabajar la arquitectura
Retrabajar la arquitectura de forma de atender necesidades que hayan surgido durante la evaluación

Volver a “visitar” los requerimientos
Considerar cualquier cambio en los requerimientos que surja a partir de la evaluación de la arquitectura 

En lo personal, creo que ante cada proyecto es indispensable evaluar el nivel de detalle que deberíamos alcanzar al ejecutar el proceso según el tipo de proyecto al que nos estemos enfrentando. En proyectos complejos y de gran porte seguramente sea muy útil (si no necesario) seguir al detalle un proceso de definición de la arquitectura como este. Sin embargo, ante proyectos de menor porte probablemente algunas actividades se nos solapen, otras desaparezcan o quizás sean menos relevantes.
De todas maneras, tener siempre presente este proceso y las actividades que involucra ayuda a planificar y dimensionar el trabajo que tendremos por delante.

Atributos de calidad

Durante este proceso de definición, la arquitectura se ve influenciada por algunos factores/involucrados como por ejemplo los stakeholders, la organización que desarrolla el sistema, el ambiente tecnológico y la experiencia del arquitecto. Entre otras cosas, estos influenciadores determinan funcionalidades y atributos de calidad que debe soportar la arquitectura.

Las funcionalidades habitualmente son independientes de la estructura y pueden ser logradas con diferentes combinaciones de ella, pero los atributos de calidad son los que restringen la estructura.

De todas maneras, no necesariamente los atributos de calidad aportan información que únicamente involucra a la arquitectura, es por eso que en el siguiente cuadro aparecen algunos atributos de calidad clasificados en distintos tipos de "cualidades".

Cualidades del Negocio	Cualidades de la Arquitectura	Cualidades del Sistema
Time to market Costo y beneficio Ciclo de vida proyectado del sistema Integración con sistemas legados	Integridad Conceptual Corrección y Completitud Viabilidad	Disponibilidad Desempeño Testability Usabilidad Seguridad Interoperabilidad Portabilidad

En la Práctica, un método que se puede seguir para extraer los atributos de calidad es el Quality Attribute Workshops (QAW) y para desarrollar la arquitectura en base a ellos el Attribute-Driven Design (ADD).

QAW es un método que utiliza a los stakeholders para descubrir los atributos de calidad de un sistema de software en base a:

• la presentación de los participantes, del negocio y del plan de arquitectura
• la identificación de los influenciadores de la arquitectura
• la especificación, priorización y refinado de escenarios 

Se espera como resultado de los QAW una lista de influenciadores así como la identificación y definición de escenarios y de su prioridad, con el fin de refinar los requerimeintos, guiar el desarrollo de prototipos e influenciar el orden en que la arquitectura debería ser desarrollada.

ADD es un enfoque para la definición de la arquitectura en donde el proceso de diseño se basa en los atributos de calidad requeridos por el sistema. Sigue un proceso de diseño recursivo que se basa en la descomposición del sistema (o elementos del mismo) aplicando tácticas y patrones para satisfacer sus requerimientos.

Por tácticas, podemos entender que son decisiones de diseño que influencian el control de la respuesta de un atributo de calidad. Para satisfacer un atributo de calidad pueden haber varias tácticas, para ejemplarizar mencionaré algunas tácticas de seguridad:

• Prevenir ataques (colocar cerraduras)
• Detectar ataques (colocar alarmas)
• Recuperarse de los ataques (contratar un seguro)

Si les interesa profundizar en estos métodos, en los links anteriores pueden ver al detalle la especificación/definición que brinda el SEI (Software Engineering Institute - Carnegie Mellon University).

Espero les siga resultando interesante la temática y les siga aportando en algo... como dije en la primera entrega, la idea es compartir, difundir y discutir, así que si tienen opiniones y experiencias para plantear, sería interesante que dejaran un comentario al respecto.

La próxima semana estaré tratando la representación y patrones de Arquitectura.

¡Hasta la próxima!