Evaluación de la Arquitectura de Software

ENTENDIENDO Y CUESTIONANDO EL DISEÑO ARQUITECTÓNICO

A lo largo de las últimas entregas de ésta serie de artículos, nos hemos enfocado en tres categorías de actividades relacionadas con el desarrollo de la arquitectura de software y que (idealmente) ocurren como parte del desarrollo de cualquier sistema de software. Estas categorías de actividades han cubierto aspectos de requerimientos que influyen en el diseño arquitectónico (los drivers arquitecturales), el diseño de la arquitectura en si mismo y la documentación del diseño a través de diversas vistas. El cuidar estos aspectos como parte del desarrollo es una tarea clave que aumenta las probabilidades de tener un sistema de calidad que satisfaga requerimientos que influyen a la arquitectura. La arquitectura es, sin embargo, un aspecto tan importante dentro del desarrollo que es conveniente realizar actividades de verificación de la misma de forma temprana, con el fin de identificar problemas que podría resultar muy costoso eliminar posteriormente. La evaluación de la arquitectura de software permite justamente realizar la verificación del diseño y es la cuarta categoría de actividades que, junto con las tres categorías mencionadas previamente, cubren el conjunto de aspectos relacionados con el desarrollo de arquitectura de software.

Conceptos

Recordemos que los atributos de calidad son aquellas características medibles, tales como el desempeño o disponibilidad, que permiten expresar la calidad del sistema de un punto de vista del cliente y de la organización de desarrollo. Como se vio en columnas anteriores, un buen diseño arquitectónico es clave para poder satisfacer este tipo de requerimientos. Imaginemos, por ejemplo, que se tienen escenarios de atributos de calidad de desempeño y escalabilidad como los siguientes:

• DES-1: Un usuario arranca de forma manual el proceso de validación de facturas. El sistema realiza el proceso sobre 2’000’000 de facturas en un tiempo no mayor a 8 horas.
• MOD-1: Un ingeniero agrega un componente para soportar un nuevo protocolo de comunicación al sistema en tiempo de desarrollo. El componente es agregado de forma exitosa sin que esto requiera de modificar ningún componente previo del sistema.

Al terminar de realizar el diseño de una arquitectura, quisiéramos estar seguros que el diseño arquitectural propuesto satisface realmente requerimientos como los anteriores. El riesgo de no tener seguridad al respecto de ello de forma temprana en el desarrollo puede tener consecuencias muy serias en etapas posteriores del desarrollo y muy particularmente, si se descubren problemas relacionados con la arquitectura en etapas tardías tales como la implantación del sistema.
La evaluación de la arquitectura de software es una herramienta que ayuda a mitigar riesgos como el descrito anteriormente. Para lograrlo, la evaluación busca esencialmente responder a la pregunta siguiente: ¿El diseño de la arquitectura satisface a los requerimientos que influyen a la arquitectura y, principalmente, a los atributos de calidad?

Técnicas de evaluación

Existen diversas técnicas de evaluación de arquitectura de software, que se describen a continuación:

Checklists y cuestionarios

El uso de checklists (listas de verificación) y cuestionarios para realizar revisiones e inspecciones del diseño que se ha producido. Realizarlos de forma efectiva, no es una tarea trivial. Checklists y cuestionarios deben enfocarse sobre cuestiones de fondo del diseño más que de la forma. Algunos ejemplos de preguntas y comentarios al respecto, se muestran a continuación:

• ¿Todos los campos de la plantilla de vista han sido llenados? Esta pregunta es necesaria, pero se enfoca sobre la forma.
• ¿Se ha definido un mecanismo de manejo de excepciones adecuado? Esta pregunta se enfoca en cuestiones de diseño, la dificultad reside en definir lo que se entiende como un mecanismo “adecuado”.
• ¿Se han documentado decisiones de diseño relativas a todos los drivers arquitecturales? Es una pregunta útil, aunque una respuesta positiva no permite saber si las decisiones de diseño son adecuadas.

Es complicado realizar checklists y cuestionarios genéricos que cubran todo tipo de sistemas, por ello, es conveniente enfocarlos a dominios específicos que requieran diseños arquitectónicos similares.
La evaluación de arquitecturas por medio de checklists y cuestionarios deben mantenerse resguardados y controlados.

Evaluación basada en escenarios

Las evaluaciones basadas en escenarios son una técnica más efectiva que la anterior, sin embargo, se trata también de una técnica más costosa y más compleja de implantar.
La evaluación basada en escenarios, toma como entrada escenarios que pueden ser de atributos de calidad (como los descritos arriba) o bien funcionales (por ejemplo, el flujo principal de algún caso de uso). Los escenarios son usados por un equipo de evaluación para cuestionar al arquitecto sobre las decisiones de diseño que tomó y el arquitecto debe ser capaz de argumentar de manera convincente que el diseño planteado satisface o no los escenarios sobre los cuales se le está cuestionando.
Una evaluación basada en escenarios requiere de poder conformar un comité de evaluación. Generalmente, este comité de evaluación debe estar compuesto por gente suficientemente experimentada como para poder entender y cuestionar el diseño arquitectónico, este tipo de gente generalmente son ingenieros de software experimentados o bien arquitectos de software.
Un proceso genérico de evaluación basada en escenarios se muestra en la figura 1. Como se puede observar, existen tres fases distintas asociadas con la evaluación. Durante la fase de preparación, se solicita la evaluación y se envía un paquete de evaluación al comité. El paquete de evaluación generalmente debe incluir información general del sistema, detalle de los requerimientos que influyen en la arquitectura y la documentación de la misma a través de distintas vistas. El comité prepara la evaluación, incluyendo aspectos logísticos de la misma y define la fecha en que se llevará a cabo.
En la fecha definida, se reúne el arquitecto junto con el comité de evaluación (y posiblemente algunos otros involucrados). La junta de evaluación comienza con una presentación del contexto del sistema, un repaso de los requerimientos que influyeron en el diseño de la arquitectura y una presentación general de la misma (por ejemplo usando la vista de implantación y otros modelos de alto nivel). Enseguida comienza la evaluación en sí. Se elige algún escenario que se desea evaluar y el arquitecto comienza a realizar la presentación del mismo. Al tiempo que el arquitecto presenta el escenario, el comité de evaluación debe tratar de identificar riesgos y problemas con el diseño que se presenta. Los riesgos pueden incluir decisiones de diseño que no se han tomado en cuenta, por ejemplo:

• Las interfaces entre los componentes no han sido especificadas de forma completa.
• No existen diagramas que permitan comprender la manera en que se lleva a cabo el escenario DES-1.

Los problemas pueden incluir decisiones de diseño claramente erróneas o bien que no han sido tomadas, como por ejemplo:
La introducción de un nuevo componente para el escenario MOD-1 requiere de modificar componentes existentes.


Figura 1. Proceso genérico de evaluación basada en escenarios.

Es importante señalar que con frecuencia es muy complicado poder tener seguridad que un diseño puramente conceptual satisface, con seguridad, los drivers arquitecturales. Esto es particularmente relevante respecto a los atributos de calidad asociados con cuestiones en tiempo de ejecución (desempeño). Por ello, es muy conveniente que, en esos casos, el arquitecto sustente sus decisiones de diseño no sólo con diagramas sino con resultados de la ejecución de prototipos que se hayan realizado justamente con el objetivo de mitigar riesgos técnicos. Una vez que se ha terminado de evaluar un escenario, se continua con un escenario distinto hasta que se han cubierto los distintos escenarios, o bien ha terminado el tiempo de la junta. Como resultado de esta junta de evaluación, el comité debe reportar sus observaciones con el fin de que puedan ser atendidas por el arquitecto.
La última fase es de seguimiento, en ella el arquitecto atiende las observaciones levantadas durante la evaluación.
La evaluación basada en escenarios presenta diversas ventajas:

• Es relativamente simple de realizar.
• El beneficio es alto relativo al costo, sobre todo si se realiza en etapas tempranas del desarrollo.
• Permite identificar problemas asociados con requerimientos (por ejemplo, si los atributos de calidad no están cuantificados).
• Permite a diversos involucrados conocer la arquitectura.
• Permite transferir conocimientos arquitectónicos en la organización.

La desventaja principal de este tipo de evaluación es la dificultad de formar comités de evaluación efectivos, sobre todo si la organización es pequeña.
Existen diversas técnicas específicas de evaluación de arquitecturas, de las cuales la más conocida es probablemente el ATAM (Architecture Tradeoff Analysis Method) del SEI [1]. ATAM tiene la particularidad de que puede realizarse sobre sistemas en los cuáles no se documentaron los atributos de calidad de forma inicial. Diversos métodos de evaluación son comparados en [2].

Otras técnicas

Otras técnicas de evaluación incluyen la generación de simulaciones, experimentos y análisis específicos. Estas técnicas son apropiadas para cierto tipo de sistemas como por ejemplo los sistemas de tiempo real. Dependiendo la criticidad del sistema, es conveniente combinar varias de las técnicas de evaluación con el fin de tener mayor seguridad sobre la pertinencia de la evaluación.

Para terminar

La arquitectura de software es un artefacto fundamental dentro del desarrollo de sistemas de calidad. El no cuidar aspectos relacionados con el desarrollo de la arquitectura puede resultar en sistemas que no cubren las expectativas de los clientes y de la organización de desarrollo; la evaluación del diseño de la arquitectura es, por lo tanto, una actividad fundamental dentro de las actividades de desarrollo. El alto costo que tienen los defectos relacionados con la arquitectura en etapas tardías de desarrollo justifica plenamente que se invierta en la realización de esta práctica como parte del desarrollo.
Por último, vale la pena señalar que la evaluación de la arquitectura pone a prueba las habilidades “suaves” (soft skills) de los arquitectos, quienes deben ser capaces de hacer presentaciones efectivas de su diseño, tanto a nivel escrito como a nivel oral o bien de cuestionar diseños de otros arquitectos de forma pertinente.