Diferencia entre revisiones de «Análisis de Arquitecturas de Software (SAAM)»

(Véase También)
Línea 51: Línea 51:
 
== Véase También  ==
 
== Véase También  ==
 
[[Architecture Trade-off Analysis Method (ATAM)]].
 
[[Architecture Trade-off Analysis Method (ATAM)]].
 +
 +
[[Active Reviews for Intermediate Designs (ARID)]].
  
 
[[Architecture Level Modifiability Analysis (ALMA)]].  
 
[[Architecture Level Modifiability Analysis (ALMA)]].  
Línea 59: Línea 61:
  
 
[[Survivable Network Analysis  (SNA)]].
 
[[Survivable Network Analysis  (SNA)]].
 
  
 
==Fuentes==
 
==Fuentes==

Revisión del 13:50 29 jun 2011

Método de Análisis de Arquitectura de Software(SAAM)
Información sobre la plantilla
Evaluacion de arquitectura-de-software-atam.JPG

Método de Análisis de Arquitecturas de Software (Software Architecture Analysis Method, SAAM) al igual que el ATAM, y el ARID son de los métodos de evaluación de arquitectura de software, más usados.

Introducción

El método fue originalmente creado para el análisis de la modificabilidad de una arquitectura, pero en la práctica ha demostrado ser muy útil para evaluar de forma rápida distintos atributos de calidad, tales como modificabilidad, portabilidad, escalabilidad e integrabilidad. El método de evaluación SAAM se enfoca en la enumeración de un conjunto de escenarios que representan los cambios probables a los que estará sometido el sistema en el futuro. Como entrada principal, es necesaria alguna forma de descripción de la arquitectura a ser evaluada. Las salidas de la evaluación del método SAAM son las siguientes:

  • Una proyección sobre la arquitectura de los escenarios que representan los cambios posibles ante los que puede estar expuesto el sistema.
  • Entendimiento de la funcionalidad del sistema, e incluso una comparación de múltiples arquitecturas con respecto al nivel de funcionalidad que cada una soporta sin modificación.

Con la aplicación de este método, si el objetivo de la evaluación es una sola arquitectura, se obtienen los lugares en los que la misma puede fallar, en términos de los requerimientos de modificabilidad. Para el caso en el que se cuenta con varias arquitecturas candidatas, el método produce una escala relativa que permite observar qué opción satisface mejor los requerimientos de calidad con la menor cantidad de modificaciones.

Procedimiento

En la siguiente tabla se presentan los pasos que contempla el método de evaluación SAAM, con una breve descripción:

Pasos Descripción
Desarrollo de escenarios. Un escenario es una breve descripción de usos anticipados o deseados del sistema. De igual forma, estos pueden incluir cambios a los que puede estar expuesto el sistema en el futuro.
Descripción de la arquitectura. La arquitectura (o las candidatas) debe ser descrita haciendo uso de alguna notación arquitectónica que sea común a todas las partes involucradas en el análisis. Deben incluirse los componentes de datos y conexiones relevantes, así como la descripción del comportamiento general del sistema. El desarrollo de escenarios y la descripción de la arquitectura son usualmente llevados a cabo de forma intercalada, o a través de varias iteraciones.
Clasificación y asignación de prioridad de los escenarios.

La clasificación de los escenarios puede hacerse en dos clases: directos e indirectos.

Un escenario directo es el que puede satisfacerse sin la necesidad de modificaciones en la arquitectura. Un escenario indirecto es aquel que requiere modificaciones en la arquitectura para poder satisfacerse. Los escenarios indirectos son de especial interés para SAAM, pues son los que permiten medir el grado en el que una arquitectura puede ajustarse a los cambios de evolución que son importantes para los involucrados en el desarrollo.

Evaluación individual de los escenarios indirectos. Para cada escenario indirecto, se listan los cambios necesarios sobre la arquitectura, y se calcula su costo. Una modificación sobre la arquitectura significa que debe introducirse un nuevo componente o conector, o que alguno de los existentes requiere cambios en su especificación.
Evaluación de la interacción entre escenarios. Cuando dos o más escenarios indirectos proponen cambios sobre un mismo componente, se dice que interactúan sobre ese componente. Es necesario evaluar este hecho, puesto que la interacción de componentes semánticamente no relacionados revela que los componentes de la arquitectura efectúan funciones semánticamente distintas. De forma similar, puede verificarse si la arquitectura se encuentra documentada a un nivel correcto de descomposición estructural.
Creación de la evaluación global. Debe asignársele un peso a cada escenario, en términos de su importancia relativa al éxito del sistema. Esta asignación de peso suele hacerse con base en las metas del negocio que cada escenario soporta. En el caso de la evaluación de múltiples arquitecturas, la asignación de pesos puede ser utilizada para la determinación de una escala general.

Características

Este método tiene como característica principal la realización de un análisis que delimita la forma en que variarán los atributos de calidad, como resultado de algunas modificaciones futuras de la arquitectura. Este elemento es fundamental pues, le da una visión arquitectónica al equipo de desarrollo, que conocen hasta que punto puede variar la arquitectura sin que afecte el nivel requerido de los atributos de calidad. Sin embargo, el comportamiento de un atributo de calidad puede afectar el desempeño de otros, por lo que no solamente se debe tener en cuenta la estructura de los componentes, sino también las relaciones que se establecen entre los mismos. Y es ahí donde este método, presenta su principal desventaja, ya que no valora la interrelación entre los distintos atributos.

Véase También

Architecture Trade-off Analysis Method (ATAM).

Active Reviews for Intermediate Designs (ARID).

Architecture Level Modifiability Analysis (ALMA).

Performance Assessment of Software Architecture (PASA).

Scenario Based Architecture Level Usability Analysis (SALUTA).

Survivable Network Analysis (SNA).

Fuentes

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 .