UNIDAD 5 1

TECNOLÓGICO DE ESTUDIOS SUPERIORES DE COACALCO

NOMBRE: DANIEL SANCHEZ SANCHEZ

GRUPO: 3822

TRABAJO: METODOS DE EVALUACION DE ARQUITECTURA DE SOFTWARE

PROFESOR: LIC.NESTOR APOLO LOPEZ GONZALEZ

MATERIA: ARQUITECTURA Y DISEÑO DE SOFTWARE

UNIDAD 5 2

INDICE

INTRODUCCION…………………………………………………………………….………3

ATAM – ARCHITECTURE TRADEOFF ANALYSIS METHOD……………….…4

DESCRIPCIÓN EN DETALLE DE LOS PASOS DEL ATAM…………………….……4

SAAM - SOFTWARE ARCHITECTURE ANALYSIS METHOD……………....…7

DESCRIPCIÓN DE LA ARQUITECTURA……………………………………………….9

CLASIFICACIÓN DE ESCENARIOS……………………………………………………..9

EVALUACIÓN DE ESCENARIOS………………………………………………………..9

INTERACCIÓN DE ESCENARIOS……………………………………………….…….10

ARID - ACTIVE REVIEWS FOR INTERMEDIATE DESIGNS……………..….10

ARID: UN ADR/ATMA HÍBRIDO…………………………………………………...…11

FASE1: PRE-REUNIÓN…………………………………………………………..…..…12

ROLES EN ARID……………………………………………………………………….….12

ALMA ARCHITECTURE LEVEL MODIFIABILITY ANALYSIS………….…13

SNA - SURVIVABLE NETWORK ANALYSIS..................................................14

CONCLUSION……………………………………………………………….…...17

REFERENCIAS………………………………………………………………….18

UNIDAD 5 3

INTRODUCCION

La Arquitectura de Software de un programa o sistema de computación es la

estructura o las estructuras del sistema, que contienen componentes de software, las

propiedades externamente visibles de dichos componentes y las relaciones entre ellos.

Implicancias de la definición La arquitectura es una abstracción de un sistema o

sistemas Como la arquitectura es abstracta, esta elimina la información local, los

detalles de componentes privados no son arquitectónicos Los sistemas están

compuestos por muchas estructuras.

UNIDAD 5 4

ATAM – ARCHITECTURE TRADEOFF ANALYSIS METHOD

El ATAM también puede ser utilizado para analizar sistemas legados. Esta

necesidad nace cuando el sistema legado necesita ser modificado, integrado con otro

sistema, entre otras necesidades. Aplicar el ATAM incrementa el entendimiento de los

atributos de calidad del sistema legado.

El líder del equipo de evaluación describe el método a los participantes, fija

las expectativas y responde las preguntas que puedan surgir .Presentar las pautas del

negocio En este paso se reitera las actividades del paso 6 utilizando el ranking de

escenarios del paso 7. Estos escenarios se consideran casos de prueba para confirmar

el análisis realizado hasta ahora. Este análisis puede descubrir nuevas propuestas

arquitectónicas, riesgos, no riesgos, sensitivity points y tradeoff points, que son

documentados.

Descripción en detalle de los pasos del ATAM

Paso 1: Presentar el ATAM

En el primer paso el líder del equipo de evaluación presenta el ATAM a los

stakeholders. Este tiempo es utilizado para explicar el proceso que todos seguirán,

responder preguntas, y fijar el contexto y las expectativas para el resto de las

actividades. En particular, el líder describe

Paso 2: Presentar las pautas del negocio

Los participantes de la evaluación, los stakeholders así como el equipo de

evaluación, necesitan entender el contexto del sistema y las principales pautas del

negocio que motivan el desarrollo. En este paso, una decisión maker del proyecto

UNIDAD 5 5

(por ejemplo, el director de proyecto o el cliente del sistema) presenta el sistema

desde la perspectiva del negocio. La presentación debería describir:

Paso 3: Presentar la arquitectura

En este paso, el arquitecto líder (o equipo de arquitectura) realiza una

presentación describiendo la arquitectura en un nivel apropiado de detalle. Cual es el

“nivel apropiado” depende de muchos factores: cuanto de la arquitectura ha sido

diseñada y documentada, cuanto tiempo hay disponible, y de los requerimientos de

calidad. La información arquitectónica presentada afectará directamente el posible

análisis y la calidad del mismo.

Paso 4: Identificar las propuestas arquitectónicas

El ATAM centraliza el análisis de una arquitectura en el entendimiento de sus

propuestas arquitectónicas. En este paso, son capturadas por el equipo de evaluación

pero no son analizadas. El equipo le pedirá al arquitecto que explícitamente nombre

toda propuesta usada, pero ellos también capturarán todas las propuestas que hayan

escuchado durante la presentación del arquitecto en el paso previo.

Paso 5: Generar el árbol de utilidad de los atributos de calidad

En este paso el equipo de evaluación trabaja junto con los decisión makers (el

equipó de arquitectura, el director y los clientes representativos) para identificar,

priorizar y refinar las metas de los atributos de calidad más importantes del sistema.

Este paso crucial guía el resto del análisis. Sin esta guía, los evaluadores pueden

perder su tiempo analizando aspectos de la arquitectura que no son de interés para los

stakeholders. Debe haber una manera en la cual los evaluadores y los stakeholders

concentren su atención en los aspectos de la arquitectura que son más críticos para el

éxito del sistema. Esto es conseguido construyendo un árbol de utilidad

UNIDAD 5 6

Paso 6: Analizar las propuestas arquitectónicas

Este paso mide cuan adecuados son el uno para el otro. Aquí, el equipo de

evaluación puede probar las propuestas arquitectónicas que realizan los atributos de

calidad más importantes. Esto es hecho en detalle documentando estas propuestas

arquitectónicas e identificando sus riesgos, no riesgos, sensitivity points y tradeoff

points. La meta del equipo de evaluación es estar convencidos que la propuesta

instanciada en la arquitectura que esta siendo evaluada, es la apropiada para satisfacer

los requerimientos de un atributo específico.

Paso 7: Lluvia de ideas y priorización de escenarios

Los escenarios guían la fase de pruebas del ATAM. Está probado que generar

un conjunto de escenarios facilita la discusión y la lluvia de ideas, cuando un gran

número de stakeholders han sido reunidos para participar en el ATAM. Los escenarios

son utilizados para, analizar las propuestas arquitectónicas que se utilizan en la

metodología.

Paso 8: Analizar las propuestas arquitectónicas

Después que los escenarios han sido recolectados y analizados, el equipo de

evaluación guía al arquitecto en el proceso de llevar a cabo los escenarios con ranking

más alto del paso 7 en todas las descripciones arquitectónicas que se han presentado.

El arquitecto explica como las decisiones arquitectónicas relevantes contribuyen a

realizar el escenario.

Paso 9: Presentar los resultados

Finalmente, la información recogida por el ATAM necesita ser resumida y

presentada a los stakeholders. En esta presentación el líder de la evaluación recapitula

UNIDAD 5 7

los pasos del ATAM y toda la información recogida en cada paso, incluyendo el

contexto del negocio, los requerimientos guías, las restricciones, y la arquitectura.

Pero más importante son las salidas del ATAM.

SAAM -SOFTWARE ARCHITECTURE ANALYSIS METHOD

El primer método de evaluación basado en escenarios que surgió. El foco de

este método es la modificabilidad. Esta noción de evaluación basada en el contexto,

nos ha llevado a adoptar a los escenarios como los medios descriptivos para

especificar y evaluar atributos de calidad. Podemos definir un escenario como una

breve descripción de la interacción entre un interesado y el sistema. El interesado

puede ser un cliente, usuario final, desarrollador, empresa desarrolladora,

administrador, inversor, etc.

Los escenarios son clasificados en escenarios directos e indirectos. (Son

equivalentes en notación UML a casos de uso y casos de cambio). Un escenario

directo no requiere que el sistema sea modificado para soportarlo (consideramos que

el sistema es modificado cuando se cambia la función asignada a un componente o se

agrega un componente o conector). Un escenario indirecto requiere que el sistema sea

modificado para soportarlo.

Cuando dos o más escenarios indirectos requieren cambios sobre la misma

entidad o componente, se dice que interactúan en dicho componente. En este caso, los

componentes afectados necesitan ser modificados o divididos en subcomponentes

para evitar la interacción de diferentes escenarios. Podemos decir que a mayor

interacción de escenarios, menor separación de conceptos.

UNIDAD 5 8

SAAM utiliza el agrupamiento de escenarios como criterio para evaluar la

arquitectura. Esto significa que si se agrupa un conjunto de escenarios por ser

similares y luego se observa que son equivalentes, la agrupación ha sido exitosa,

porque significa que la funcionalidad del sistema ha sido modula rizada

adecuadamente. Por el contrario, si la agrupación de estos escenarios similares, afecta

diferentes componentes (no son equivalentes), la arquitectura posiblemente debe ser

corregida.

Determinando el nivel de detalle apropiado para una descripción

arquitectónica, mediante escenarios. Resulta útil reflejar en un ejemplo la relación

entre los escenarios y la descripción arquitectónica. Uno de los beneficios de la

arquitectura es la habilidad de visualizar el software desde un nivel más alto de

abstracción. ¿Cómo saben los diseñadores cual debe ser este nivel con exactitud? La

respuesta está determinada por lo que los escenarios identificados en el sistema

determinen. Para ilustrar este concepto veamos el ejemplo siguiente. (Figura 1)

(FIGURA 1) .Descripción inicial de la arquitectura.

La figura anterior muestra una descripción inicial de una arquitectura.

Necesitamos mapear los escenarios hacia ella. En particular, para cada escenario

11

visdiff

12

msarn200

12

make

11, 12, 13

main

11

1313

13

11, 12

UNIDAD 5 9

indirecto, debemos reflejar los componentes que son afectados. Nos interesaremos

principalmente en los escenarios indirectos, pues representan los atributos que la

arquitectura deberá satisfacer. Los escenarios directos, representan las

funcionalidades del sistema Para este ejemplo consideramos que existen tres

escenarios indirectos: 11, 12 y 13. Se pueden observar en la figura, los componentes

afectados por cada uno de ellos.

Descripción de la Arquitectura

En este paso se presentan las arquitecturas candidatas. Es fundamental que la

notación empleada sea bien entendida por todos los involucrados y la granularidad

sea común para todas las arquitecturas candidatas presentados. Se deben indicar los

principales elementos de la arquitectura. Usualmente alcanza con:

Las estructuras de uso, de importación y de flujo de datos y control, más un

documento de asignación de funcionalidad. Hay una cantidad apreciable de

investigación sobre las notaciones y representaciones posibles para estos

componentes. Una representación típica distingue entre componentes que son activos

(transforman datos) y pasivos (datos almacenados). También podemos describir

agrupaciones de componentes en subsistemas o capas. Acompañando el punto

anterior debe existir una descripción de cómo el sistema se comporta con el paso del

tiempo: una descripción dinámica. Puede realizarse mediante lenguaje natural o algún

otro método más formal.

Clasificación de escenarios

En este paso debemos clasificar los escenarios como directos o indirectos

utilizando la definición antes detallada (en la sección “Contexto y escenarios de

SAAM”)

Evaluación de escenarios

UNIDAD 5 10

Para cada escenario indirecto, se deben listar los cambios necesarios en la

arquitectura para soportarlo, y el costo de llevarlos a cabo debe ser estimado. Notar

que el solo hecho de clasificar los escenarios implica un análisis de la arquitectura. Si

se da el hecho de que la información necesaria para llevar a cabo la clasificación no

está disponible, puede indicar que ciertos componentes de la arquitectura requieran

un mayor análisis y estudio. Usualmente el resultado de este paso se documenta en

forma tabular.

Interacción de escenarios

Debemos determinar las interacciones de escenarios sobre cada componente

de cada arquitectura. Está claro, que el resultado puede interpretarse de varias formas,

tal como se observó en el ejemplo de la sección “Contexto y escenarios de SAAM”.

Paso 6. Evaluación general: Un peso es asignado a cada escenario en términos de su

influencia para que el sistema sea exitoso. El peso puede ser elegido de acuerdo a los

objetivos del negocio, costos, riesgos, etc.

ARID ACTIVE REVIEWS FOR INTERMEDIATE DESIGNS

El método ARID es conveniente para realizar la evaluación de diseños parciales en las

etapas tempranas del desarrollo. ADRs son técnicas efectivas para asegurar la calidad

dando diseños detallados del software. El método se basa en que los participantes

realicen tareas que son cuidadosamente estructuradas para que el entrevistado no

pueda responder si o no, sino que obliga a utilizar el diseño y las respuestas nos dan

el estado actual y no algo fingido. ADR es utilizado para la evaluación de diseños

detallados de unidades del software como los componentes o módulos. Las preguntas

giran en torno a la calidad y completitud de la documentación y la suficiencia, el

ajuste y la conveniencia de los servicios que provee el diseño propuesto.

UNIDAD 5 11

ARID: un ADR/ATMA híbrido

Las revisiones de diseño activas y los ATAM tienen características útiles para resolver

el problema de evaluar diseños preliminares. En el ADR, los interesados reciben

documentación detallada del diseño y realizan los ejercicios en forma individual, pero

en las etapas preliminares de diseño no hay documentación detallada. Además unos

de los objetivos del ARID es crear intereses en los inversionistas a través de reuniones

centrales y esto no se lograría con los trabajos individuales.

Por otra parte, el ATAM se está pensado para evaluar una arquitectura entera,

y no a una porción de la misma. Además, el interés de la calidad fue limitada a la

viabilidad de la totalidad de la arquitectura. Las otras características que se centra el

ATAM no nos interesan. ARID surge de combinar las mejores cualidades de los

métodos ADRs y los métodos basados en escenarios.

De los ADRs nos quedamos con la participación activa de los entrevistados los

cual es ideal por dos motivos: Nos asegura alta fidelidad en las respuestas (evita

sentarse en un lado y no hacer nada).La participación activa puede captar la atención

del grupo de compradores. Del ATAM nos quedamos con la idea de la generación de

los escenarios por parte de todos los interesados, los usuarios le dirán a los

diseñadores que los que ellos necesitan o mejor dicho que es lo que ellos esperan y si

los diseñadores demuestran en la pruebas que el diseño cumple con los

requerimientos también va a atraer el interés de los compradores.

Roles en ARID

Se identifican tres grupos de participante en una evaluación ARID: El equipo

de verificación, el cual está formado por tres roles: líder de la evaluación que se

encarga de preparar conjuntamente con el arquitecto la evaluación, un secretario que

se encarga de recolectar los resultados y realizar las anotaciones; y un conjunto de

interrogadores que ayudan a obtener los escenarios durante las entrevistas.

UNIDAD 5 12

Opcionalmente se podrá tener un observador para mejorar el proceso de evaluación

El arquitecto, el cual es responsable de presentar el diseño y a quien se la dará los

resultados de la evaluación. Revisores, son los interesados en la viabilidad y

adecuación del diseño que se presentan. Son las personas que van a utilizar el diseño

(software engineers) y son las personas más adecuadas para juzgar su calidad.

Fase1: PRE-reunión

Primero una reunión entre el arquitecto y el líder de la evaluación se lleva a

cabo para preparar el ejercicio. Esta reunión dura un día aproximadamente y en la

misma se llevan a cabo los primeros 4 pasos. Identificar los revisores, son los

ingenieros de software que van a usar el diseño reparar la presentación del diseño, el

arquitecto prepara un informe que explica el diseño, el mismo deberá ser lo

suficientemente detallado como para que una capacitada audiencia pueda usar el

diseño.

El arquitecto presenta el informe al líder de la evaluación, esta presentación es

provechosa por varios motivos, preparar los escenarios, el arquitecto y el líder

prepara los escenarios que sirven para ilustrar los conceptos a lo revisado. Preparar

los materiales, copias de la presentaciones, escenarios, se realiza la agenda invitando

a interesados externos y asegurando la presencia de los revisores.

Fase 2: Evaluación

Durante la fase dos, los revisores son reunidos y la evaluación comienza. Esta

durará un día y medio y las 5 actividades restantes son completadas. Presentación del

ARID, el líder utiliza 30 minutos para explicar los pasos de la evaluación a los

participantes. Presentación del diseño, el arquitecto realiza una presentación de dos

horas del diseño mostrando los ejemplos. Durante la presentación no se podrán hacer

preguntas concernientes a la implementación ni tampoco se proponen diseños

UNIDAD 5 13

alternativos. El objetivo es ver si el diseño es adecuado no saber porque el diseño se

hizo de esa manera u obtener tips para la futura implementación. Preguntas para

clarificar el diseño son permitidas. El secretario es el encargado de recolectar las

preguntas y registrar las veces que el arquitecto evadió una respuesta afirmando que

estaba pensado pero no disponible.

Lluvia de ideas y priorización de escenarios, entre todos los presentes se

proponen escenarios relevantes para solucionar problemas que esperan hacer frente.

Luego los revisores pueden sugerir que dos escenarios son versiones del mismo o un

escenario es parte de otro y deben ser unidos. A continuación cada revisor puede

votar, siendo la cantidad de votos un 30% de la totalidad de los escenarios, los

revisores pueden utilizar todo sus votos en un escenario o repartirlos entre varios. Los

escenarios con más votos son usados para testear la adecuación del diseño.

Se realiza la revisión, comenzando con el escenario que tuvo la mayor

cantidad de votos, el líder de la evaluación pide a los revisores que trabajando como

grupo usen el diseño para resolver el problema presentado en el escenario. Durante

este trabajo el arquitecto no podrá ayudar a los revisores, sin embargo si el líder ve

que los revisores van por un mal camino, puede pedirle al arquitecto que los guíe o le

brinde cierta información para no perder el tiempo (todo esto debe ser registrado por

el secretario). Todas las discrepancias también son registradas. La etapa continúa

hasta que alguno de los siguientes eventos ocurre: El tiempo reservado para la

revisión se acaba. Los escenarios con más votos han sido analizados. El grupo se

siente satisfecho tanto porque vio que el diseño era correcto o porque no lo aprobó.

ALMA Architecture Level Modifiability Analysis

ALMA es un método de evaluación orientado a metas; dependiendo de la

meta, este método puede ser usado para predecir el costo de mantenimiento en una

arquitectura, evaluar los riesgos al haber una modificación en esta, o comparar un

UNIDAD 5 14

conjunto de arquitecturas para determinar cuál es la más apropiada en soportar

cambios. Este método se compone de cinco pasos que se muestran en la Figura 1 y

que a continuación se describen.

Definir la meta de evaluación. Dependiendo del objetivo de la evaluación se

selecciona alguna de las tres metas.

Describir la arquitectura de software. En este punto se colecta la información

de las partes más relevantes de la arquitectura como son la descomposición de

ésta en componentes, las relaciones entre componentes así como las relaciones

que existen en el entorno del sistema.

Obtener escenarios. Una vez que se cuenta con la información de la

arquitectura se procede a encontrar y definir los escenarios de cambio, estos

escenarios son agrupados en categorías.

Evaluar escenarios. En este punto se realiza un análisis de impacto que

consiste en identificar los componentes afectados por los escenarios

previamente definidos, determinar el efecto del cambio sobre los componentes

así como determinar los efectos del cambio en otros componentes. Los

resultados de este análisis se deben expresar ya sea de manera cuantitativa o

cualitativa.

Interpretar resultados. Finalmente se interpretan los resultados así como las

conclusiones del análisis dependiendo de la meta de evaluación seleccionada.

SNA Survivable Network Analysis

SNA es un método desarrollado por el CERT (Computer Emergency

Response Team) que forma parte del SEI (Software Engineering Institute). Este

método ayuda a identificar la capacidad de supervivencia en un sistema analizando su

arquitectura. La supervivencia es la capacidad que tiene un sistema para completar su

UNIDAD 5 15

misión a tiempo ante la presencia de ataques, fallas o accidentes. Un ejemplo de la

definición anterior es la siguiente: un cajero automático debe garantizar al usuario los

servicios esenciales aun cuando este se encuentre en presencia de algún ataque

externo o falla interna. SNA utiliza tres propiedades clave para evaluar la

supervivencia en un sistema. Estas son:

Resistencia. Es la capacidad del sistema para repeler ataques, fallas o

accidentes.

Reconocimiento. Es la capacidad de detectar ataques, fallas o accidentes y si

estos ocurren evaluar los daños.

Recuperación. Es la capacidad de mantener en operación los servicios

esenciales en presencia de ataques, fallas o accidentes. Este método puede ser

usado en el proceso de construcción de la arquitectura (evaluación temprana),

una vez que la construcción de esta ha terminado o si la arquitectura se

encuentra implementada.

La técnica de evaluación que utiliza SNA es el uso de escenarios. SNA hace

uso de dos tipos de escenarios. El primer tipo son los escenarios normales de uso,

éstos se componen de una serie de pasos donde los usuarios invocan a servicios y

obtienen acceso a activos tales como bases de datos. El segundo tipo de escenarios

son los de intrusión, en los que se representan diferentes tipos de ataques al sistema.

Para llevar a cabo la evaluación, se requiere que se cuente con la especificación de la

arquitectura. Si hace falta documentación de la especificación se procede a

completarla.

SNA está compuesto de cuatro pasos que a continuación se describen:

1. Definición del sistema. En este paso se obtiene la misión del sistema, se

discute el entorno de uso en términos de capacidades y ubicaciones de los

usuarios, se analizan posibles riesgos que el sistema pueda presentar en

condiciones adversas, finalmente se analiza la arquitectura de software.

UNIDAD 5 16

2. Definición de las capacidades esenciales. A continuación se seleccionan los

servicios esenciales y los activos que usan. Se deben de seleccionar aquellos

servicios y activos que sean críticos para garantizar en condiciones adversas la

misión del sistema. Una vez seleccionados, estos se trazan a través de la

arquitectura para identificar los componentes que participan en proporcionar

los servicios esenciales.

3. Definición de las capacidades que comprometen al sistema. En este paso se

selecciona un conjunto representativo de posibles ataques basados en el

entorno de operación del sistema. Se definen los escenarios de intrusión y se

trazan a través de la arquitectura para identificar componentes que

comprometan la supervivencia del sistema logrando así el acceso y daño a

éste.

4. Analizar la supervivencia. Finalmente se identifican los escenarios de

intrusión que contienen los componentes esenciales y que comprometen la

supervivencia del sistema. Por cada componente identificado se procede a

analizarlo en términos de las capacidades de resistencia, reconocimiento y

recuperación. Estos análisis se colocan en una tabla llamada mapa de

supervivencia que contiene porcada escenario de intrusión las estrategias de

supervivencia actuales y las recomendadas con respecto a cada una de las

capacidades.

UNIDAD 5 17

CONCLUSIONES

UNIDAD 5 18

REFERENCIAS

Por Omar S. Gómez, (2008), Evaluando la arquitectura de software Parte 2. Métodos de evaluación, Consulto el 03 de julio del 2012, Recuperado de http://www.osgg.net/omarsite/resources/papers/ev_arch_02.pdf

Mauricio Dávila, Evaluación de Arquitecturas de Software, Universidad de la republica Facultad de ingeniería, Consulta el 04 de julio del 2012, Recuperado de http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CEwQFjAA&url=http%3A%2F%2Fwww.fing.edu.uy%2Finco%2Fcursos%2Fgestsoft%2FPresentaciones%2FEvaluacion%2520de%2520Arquitecturas%2520-%2520G10%2FEvaluacion%2520de%2520Arquitecturas.doc&ei=dd_zT9vMO-SU2AWV0P3zBg&usg=AFQjCNFoBEY6JCqN5lCs9i8PVtEnt8OdUg&sig2=0F1iurWqYrVKxUkLrYpgAQ

Omar Salvador Gómez (2005), Proceso de evaluación para arquitecturas de software usadas en el sector empresarial (PEASSE), CIMAT, Consulto el 03 de julio del 2012, Recuperado de http://osgg.net/omarsite/resources/proceedings/PEASSE.pdf

Arriola Navarrete, O., & Garmendia Bonilla, L. Evaluación de software para bibliotecas: requerimientos técnicos, 1997. In Bibliotecas y archivos: órgano de la Escuela Nacional de Biblioteconomía y Archivonomía. Escuela Nacional de Biblioteconomía y Archivonomía. pp.23-31. (Published) [Journal Article (Print/Paginated)]. http://eprints.rclis.org/handle/10760/11257#.T_R62KsqB1E

Andrea Delgado, Alberto Castro, Martín Germán, Evaluación de Arquitecturas de Software con ATAM (Architecture Tradeoff Analysis Method): un caso de estudio,

UNIDAD 5 19

Universidad de la República, Facultad de Ingeniería, Instituto de Computación, Consulto el día 04 de julio del 2012, Recuperado de http://www.bvs.hn/cu-2007/ponencias/CAL/CAL027.pdf