Archivo de la etiqueta: evaluación de arquitectura

El dominio de una evaluación de arquitectura de software

Entender el dominio de una evaluación de arquitectura es un asunto que, en mi experiencia, ha mostrado ser vital para poder convencer a quienes puedan verse interesados en este tipo de iniciativas. Para esta reflexión acerca del dominio he preparado un modelo de dominio que presento con un diagrama de clases UML. He utilizado la convención tradicional de describir las relaciones entre las entidades de tal manera que se lean en voz activa de izquierda a derecha y de arriba hacia abajo.

El modelo que propongo está lejos de ser una revisión exhaustiva del dominio de las evaluaciones de arquitectura de software. Mi objetivo ha sido capturar los elementos esenciales a la vez que este sea simple y útil para la discusión. En la búsqueda de la simplicidad, también he anotado la multiplicidad en los extremos de las entidades solo en aquellos casos me han parecido más importantes de destacar.

Los stakeholders (no confundir con usuarios de un sistema de software) muestran interés en el proyecto y producto. También tienen potencial poder de influir las decisiones que se tomen respecto de estos. El interés e influencia lo materializan por medio de preocupaciones. «En caso alguno podemos permitirnos que se filtren datos privados de los usuarios» es un ejemplo de una preocupación que puede venir de un abogado o una ingeniera en seguridad.

Las preocupaciones son reflejadas en escenarios, es decir, son los stakeholders quienes crean estos escenarios que luego serán registrados de alguna manera. A su vez, los escenarios dan soporte a los objetivos del negocio, o de la misión. Así, por ejemplo, el escenario «el tiempo de generación de las liquidaciones de sueldo para 2000 trabajadores debe ser menor a 10 minutos» soportará un objetivo como «aumentar participación en el mercado de nuestro sistema de remuneraciones».

Los escenarios también son operacionalizaciones para los atributos de calidad. Los atributos de calidad corresponden a conceptualizaciones, es decir, definiciones para conceptos que se han establecidos como factores de calidad en productos de software. La operacionalización es de vital importancia en las evaluaciones de arquitectura de software y también en la ingeniería de software porque son estas las que nos permiten verificar si se ha alcanzado el nivel esperado del atributo de calidad. El nivel esperado del atributo de calidad puede estar expresado en el escenario, como también por medio de un requisito de atributo de calidad. Podríamos argumentar con facilidad que los escenarios son una más de las posibles formas de expresar estos niveles esperados por lo que en la práctica podemos prescindir de la especificación formal como requisito si es que se nos permite.

Los atributos de calidad son impactados por las decisiones arquitecturales. Esta es una buena heurística para sospechar cuándo una decisión es arquitectural y cuándo no. Por ejemplo, usar colecciones en Java en reemplazo de arreglos será, probablemente en una gran mayoría de casos, una decisión de diseño que no tendrá mayor impacto en los atributos de calidad y puede, por tanto, ser considerada como decisión no arquitectural. Lo que es importante de reconocer de estos impactos es que no siempre son negativos y no siempre son positivos: de hecho, una decisión arquitectural podría afectar negativamente a un atributo (por ejemplo, usabilidad) a la vez que beneficia a otro (por ejemplo, confidencialidad). Así también, las decisiones arquitecturales las tomaremos con el objetivo de tratar de alcanzar requisitos de atributos de calidad. Definiciones y descripciones de atributos de calidad pueden ser encontrados en bibliotecas de atributos de calidad (sugiero revisar [1] y [2]).

Para evaluar una arquitectura necesitamos, ya sea con mayor o menor nivel de acabado, una representación de la arquitectura. Esta representación no solo va a describir la arquitectura sino también expresará de alguna manera las decisiones arquitecturales que componen a esta arquitectura y que impactan los atributos de calidad. Usemos UML, algún ADL o diagramas ad-hoc, lo importante para una evaluación es reconocer que la representación va a describir tanto la arquitectura como las decisiones ya que estas últimas son las que componen el producto de trabajo que llamaremos arquitectura de software.

He dejado para el final de esta columna la que es probablemente la relación más importante en este dominio: la arquitectura de software determina los atributos de calidad. Este consenso tanto de la academia como de la industria es el que sustenta la necesidad de las evaluaciones de arquitectura: evaluamos una arquitectura porque sabemos que una arquitectura no apropiada tendrá un efecto adverso no despreciable en los atributos de calidad.

Al llegar a este punto, comprender el beneficio de una evaluación de arquitectura debiera ser transparente y directo. Usaremos estas instancias para determinar qué tan probable es que nuestro sistema de software alcance los niveles de calidad esperados así como también usaremos el resultado de las evaluaciones para definir líneas de acción concretas que nos permitan corregir, tempranamente, asuntos que pueda dificultar o inhibir alcanzar los requisitos de nuestro sistema.

[1] «Software Architecture in Practice», Bass et al. Addison-Wesley, 3a edición, 2012.

[2] “Evaluating Software Architectures: Methods and Case Studies”, Clements et al. Addison-Wesley, 2002.

Sugerencias para escenarios en la arquitectura de software

Uno de los desafíos que enfrentan los arquitectos de software, tanto en el diseño como en la evaluación, es cómo poder expresar de manera concreta los atributos de calidad. Lo cierto es que los atributos de calidad se mueven conceptualmente en otro nivel, por lo que teóricamente nunca será posible describirlos en forma operacional. Lo que sí podemos hacer es escribir escenarios que describan las respuestas del sistema y estos pueden ser asociados a atributos de calidad.

En mi experiencia, la escritura de escenarios en la arquitectura de software no es muy común y por ello muchas veces los arquitectos terminan estableciendo muchos supuestos que se motivan desde los requisitos funcionales que, paradójicamente, muchas veces están descritos como escenarios (por ejemplo, casos de uso e historias de usuario).

Los comentarios de los stakeholders en las reuniones de diseño, incluidas las evaluaciones de arquitectura, son siempre origen para escenarios. Estos deben describir, al menos, un estímulo al sistema y una respuesta de este. El estímulo al sistema implica reconocer algún actor (humano o no) o un factor que motiva al sistema a reaccionar de alguna manera (respuesta). En algunos casos conviene también describir el ambiente para el escenario: por ejemplo, indicar si el escenario refiere a casos de alta concurrencia de usuarios o no (en caso de que aplique).

Además, la respuesta del sistema debe ser descrita de tal manera que sea verificable. Para poder verificar la respuesta necesitamos que esta contenga una medida concreta que sea evaluable para poder llevar a cabo la verificación. A modo de ejemplo, en vez de hablar de «interfaz usable», preferimos decir «interfaz con la limitación de que todos los formularios deben tener un máximo de 5 campos para ser llenados». En este ejemplo, 5 campos por formulario es algo observable, evaluable y, por tanto, verificable (es decir, podemos decir si el escenario ha sido alcanzado o no).

Veamos un ejemplo de escenario originado por un actor (humano u otro sistema):

«La solicitud de generación de reportes completos (estímulo) debe ser atendida en no más de 24 horas desde que se ingresa la solicitud (respuesta)».

Notar que el escenario anterior inmediatamente comienza a dar luces del diseño que tendrá la arquitectura: un reporte completo que puede tomar tiempo en su generación, pero que es aceptable hasta 24 horas después de la solicitud, nos lleva a pensar en que la API del reporte puede ser diseñada de en forma asincrónica siguiendo un estilo REST.

Ahora un ejemplo de escenario originado por un factor:

«La incorporación de un componente ‘logger’ en el sistema (estímulo) permite estandarizar el mecanismo de registro de eventos (respuesta)»

El lector debe notar que, como se ha discutido en una publicación anterior de este blog, en el contexto de la evaluación de una arquitectura es posible que stakeholders relacionados con la seguridad insistan en escenarios como el siguiente, lo cual claramente pone de manifiesto un tradeoff o compromiso entre atributos de calidad:

«Los eventos del sistema (estímulo) deben ser registrados en formato y con mecanismo propios de la organización».

Finalmente, algunas palabras respecto de la «clasificación» de escenarios en atributos de calidad. El escenario anterior puede ser visto desde el punto de vista de la confidencialidad, así como también desde la integridad. En la práctica, a veces se dan discusiones acerca de a qué atributo de calidad pertenece un escenario. Esta discusión es interesante, pero no aporta más información para la arquitectura de un sistema de software ni tampoco para las evaluaciones de las mismas.

Evaluaciones de arquitectura: cuándo ejecutarlas

Las evaluaciones de arquitectura de software son instancias formales en las que, haciendo uso de algún método, se analiza si la arquitectura es adecuada para el propósito por el cual se concibe un sistema de software. No corresponde aquí discutir acerca de lo que es concretamente el propósito de un sistema de software, pero sepa el lector que este puede ser eventualmente caracterizado a nivel de escenarios o requisitos de atributos de calidad. Que las evaluaciones sean instancias formales no quiere decir que las arquitectura de software se pueden evaluar solo en iniciativas, sino más bien que al reconocer la instancia como tal dentro de un proceso y hacer uso de un método específico estamos apuntando a la sistematización de las evaluaciones.

Una pregunta que me han hecho en reiteradas ocasiones es: cuándo ejecutar una evaluación de arquitectura. La respuesta no es fácil y si agregamos el hecho de que algunos métodos como ATAM [1] presuponen contar con al menos una idea concreta de arquitectura y otros como ARID [2] se enorgullecen al decir que no requieren de una arquitectura completa, la discusión se torna un tanto más nebulosa.

Evaluar una arquitectura de software requiere reconocer todo el ciclo de diseño de estas. Analizar, por ejemplo, la decisión de tercerizar el sistema de pago en un producto requiere de caracterizar, y muchas veces levantar, los escenarios o requisitos, especialmente aquellos relacionados con atributos de calidad para determinar si las decisiones tomadas son adecuadas o no. Algunos métodos como ATAM [1] ponen énfasis en determinar también cómo estas decisiones se deben balancear con otras decisiones (tradeoffs o compromisos). Podemos decir que cada método hará énfasis en lo que promete atender con prioridad, como es el caso de DCAR [3] que se enfocará en decisiones concretas que deben ser desafiadas en el análisis.

Lo anterior pone de manifiesto que una evaluación de arquitectura puede comenzar tan tempranamente como el visionado mismo del producto de software en cuestión. El modelado de contexto que normalmente se realiza en etapas muy tempranas del desarrollo es una entrada importante para el diseño de una arquitectura de software. Los escenarios, especialmente aquellos que se levantan para propiedades cualitativas del sistema, son muy importantes a la hora de ejecutar una evaluación de arquitectura. Con mayor razón se justifica la inclusión de evaluaciones de arquitectura en etapas tempranas en el contexto del desarrollo ágil: no es de extrañar que ya en el primer Sprint Planning del primer Sprint en Scrum los ingenieros y desarrolladores comiencen a visualizar y diagramar una arquitectura de software (las evaluaciones normalmente se extienden por varios días por lo que es de esperar que en un primer Sprint la evaluación esté presente en una parte considerable de la extensión de este). Las evaluaciones también se pueden ejecutar en forma continua, es decir, a lo largo del desarrollo de un producto de software.

No solo desde un punto de vista temporal es posible discutir la inclusión de evaluaciones de arquitectura. También se puede discutir en términos del tipo de proyecto o iniciativa de desarrollo. Evaluaciones de arquitectura son bienvenidas en el desarrollo de productos [2], migraciones [4], adquisiciones [5] y mantenciones de software [2]. En el caso de las adquisiciones, las evaluaciones de arquitectura pueden incluso comenzar antes de la licitación, donde los resultados de la evaluación serán esenciales para explicitar concretamente los aspectos esperados de la propuesta de software que hagan los oferentes interesados en la licitación.

Finalmente, los resultados de las evaluaciones de arquitecturas de software no terminan en «sí» o «no». Por lo mismo, no corresponde asignar la responsabilidad de tomar decisiones a nivel de proyecto a las evaluaciones. Las evaluaciones terminarán con resultados que serán un input valiosísimo para la toma de decisiones a nivel de proyecto (por ejemplo, ¿continuamos con la migración?) y a nivel estratégico (por ejemplo, ¿estamos en condiciones de ofrecer un software mejor que la competencia?), pero la responsabilidad de tomar esas decisiones será siempre de los las personas que estén asumiendo esos roles.

[1] «ATAM: Method for Architecture Evaluation», Kazman et al. SEI, 2000.

[2] «Evaluating Software Architectures: Methods and Case Studies», Clements et al. Addison-Wesley, 2002.

[3] «Decision-Centric Architecture Reviews», van Heesch et al. IEEE Software, 2013.

[4] «Assessing Migration of a 20-Year-Old System to a Micro-Service Platform Using ATAM», Cruz et al. ICSA-C, 2019.

[5] «The Need for Software Architecture Evaluation in the Acquisition of Software-Intensive Systems», Zhu et al. Australian Government – Department of Decence, 2014.