Técnicas de Evaluación de Arquitectura de Software

Técnicas de Evaluación de Arquitectura de Software.
Información sobre la plantilla
Tecnicas de evaluación de arquitectura.JPG

Técnicas de Evaluación de Arquitectura de Software. Se utilizan para la evaluación de atributos de calidad. Requieren grandes esfuerzos por parte de los ingenieros de software para crear especificaciones y predicciones respecto a si la propuesta arquitectónica satisface las cualidades del Software.

Introducción

Estas técnicas requieren información del sistema a desarrollar que no está disponible durante el diseño arquitectónico, sino al principio del diseño detallado del sistema. En vista de que el interés es tomar decisiones de tipo arquitectónico en las fases tempranas del desarrollo, son necesarias técnicas que requieran poca información detallada y puedan conducir a resultados relativamente precisos.Hasta ahora las técnicas existentes para evaluar arquitecturas permiten hacer una evaluación cuantitativa sobre los atributos de calidad a nivel arquitectónico, pero se tienen pocos medios para predecir el máximo (o mínimo) teórico para la Arquitectura de software. Sin embargo, debido al costo de realizar este tipo de evaluación, en muchos casos los arquitectos de software evalúan cualitativamente, para decidir entre las alternativas de diseño.

Existen diferentes técnicas de evaluación de arquitecturas de software: evaluación basada en escenarios, evaluación basada en simulación, evaluación basada en modelos matemáticos y evaluación basada en experiencia.

Por lo regular, las técnicas de evaluación cualitativas son utilizadas cuando la arquitectura está en construcción, mientras que las técnicas de evaluación cuantitativas, se usan cuando la arquitectura ya ha sido implantada. A continuación algunas de las técnicas más usadas.

Evaluación Basada en Escenarios

Primeramente un escenario es una breve descripción de la interacción de alguno de los involucrados en el desarrollo del sistema con éste. Por ejemplo, un usuario hará la descripción en términos de la ejecución de una tarea; un encargado de mantenimiento hará referencia a cambios que deban realizarse sobre el sistema; un desarrollador se enfocará en el uso de la arquitectura para efectos de su construcción o predicción de su desempeño.

Un escenario consta de tres partes: el estímulo, el contexto y la respuesta. El estímulo es la parte del escenario que explica o describe lo que el involucrado en el desarrollo hace para iniciar la interacción con el sistema. Puede incluir ejecución de tareas, cambios en el sistema, ejecución de pruebas, configuración, etc. El contexto es el que describe qué sucede en el sistema al momento del estímulo. La respuesta describe, a través de la arquitectura, cómo debería responder el sistema ante el estímulo. Este último elemento es el que permite establecer cuál es el atributo de calidad asociado.

Los escenarios proveen un vehículo que permite concretar y entender atributos de calidad. Su uso, no sólo es de importancia para efectos de la evaluación de arquitecturas de software.

Entre las ventajas de su uso están:

  • Son simples de crear y entender.
  • Son poco costosos y no requieren mucho entrenamiento.
  • Son efectivos.

Actualmente las técnicas basadas en escenarios cuentan con dos instrumentos de evaluación relevantes, a saber: el árbol de utilidad (Utility Tree, UT) y los Perfiles (Profiles).

Árbol de Utilidad (Utility Tree)

Un UT es un esquema en forma de árbol que presenta los atributos de calidad de un sistema de software, refinados hasta el establecimiento de escenarios que especifican con suficiente detalle el nivel de prioridad de cada uno.

La intención de su uso es la identificación de los atributos de calidad más importantes para un proyecto particular. No existe un conjunto preestablecido de atributos, sino que son definidos por los involucrados en el desarrollo del sistema al momento de la construcción del árbol. El UT contiene como nodo raíz la utilidad general del sistema. Los atributos de calidad asociados al mismo conforman el segundo nivel del árbol, los cuales se refinan hasta la obtención de un escenario lo suficientemente concreto para ser analizado y otorgarle prioridad a cada atributo considerado.

Cada atributo de calidad perteneciente al árbol contiene una serie de escenarios relacionados, y una escala de importancia y dificultad asociada, que será útil para efectos de la evaluación de la arquitectura.

Perfiles (Profiles)

Un perfil (Profile) es un conjunto de escenarios, generalmente con alguna importancia relativa asociada a cada uno de ellos. El uso de perfiles permite hacer especificaciones más precisas del requerimiento para un atributo de calidad. Los perfiles tienen asociados dos formas de especificación: perfiles completos y perfiles seleccionados.

Los perfiles completos definen todos los escenarios relevantes como parte del perfil. Esto permite al ingeniero de software realizar un análisis de la arquitectura para el atributo de calidad estudiado de una manera completa, puesto que incluye todos los casos posibles. Su uso se reduce a sistemas relativamente pequeños y sólo es posible predecir conjuntos de escenarios completos para algunos atributos de calidad.

Los perfiles seleccionados se asemejan a la selección de muestras sobre una población en los experimentos estadísticos. Se toma un conjunto de escenarios de forma aleatoria, de acuerdo a algunos requerimientos. La aleatoriedad no es totalmente cierta por limitaciones prácticas, por lo que se fuerza la realización de una selección estructurada de elementos para el conjunto de muestra. Si bien es informal, permite hacer proposiciones científicamente válidas.

A pesar de todos los elementos definidos alrededor de dicha técnica de evaluación, ésta presenta como desventaja que es dependiente de manera directa del perfil definido para el atributo de calidad que va a ser evaluado. La efectividad de la técnica es altamente dependiente de la representatividad de los escenarios. Es importante destacar que la definición de los casos de uso debe ser independiente del perfil de uso, debido a que los casos de uso permiten optimizar el diseño arquitectónico, y puede resultar una muestra no representativa de la población de escenarios para la evaluación de cierto atributo de calidad. La evaluación basada en escenarios puede ser empleada para comparar dos arquitecturas y para la evaluación absoluta de una arquitectura. La diferencia está en que la evaluación absoluta requiere mayor cantidad de datos estimados y cuantitativos necesarios para la evaluación, factor que dificulta en gran medida este tipo de evaluación.

Véase También

Fuentes

  • Bosch, J. 2000. Design & Use of Software Architectures. s.l. : Adison-Wesley, 2000.
  • Carriere, J, Kazman, R y Woods, S. 2007. Toward a Discipline of Scenario based Architectural Engineering. s.l. : Software Engineering Institute, Carnegie Mellon University, 2007. págs. 5-33. ISSN: 1573-7489.
  • Gómez, Omar Salvador. 2007. Evaluando Arquitecturas de Software. Parte 1. Panorama General. México : México: Brainworx S.A, 2007.
  • Kazman, R, Bass, L y Clements, P. 2003. Software Architecture in Practice. 2da Edición. s.l. : Addison-Wesley Professional, 2003. pág. 560. ISSN: 0321154959 .
  • Kazman, R, Clements, Paul y Klain, M. 2005. Evaluating Software Architectures.Methods and case studies. 1ra Edicición. s.l. : Adison-Wesley Professional, 2005. pág. 368. ISSN: 978-0201704822 .