UNIDAD 5 1

TECNOLGICO 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 DISEO DE SOFTWARE

UNIDAD 5 2

INDICE

INTRODUCCION.3 ATAM ARCHITECTURE TRADEOFF ANALYSIS METHOD.4 DESCRIPCIN EN DETALLE DE LOS PASOS DEL ATAM.4 SAAM - SOFTWARE ARCHITECTURE ANALYSIS METHOD....7 DESCRIPCIN DE LA ARQUITECTURA.9 CLASIFICACIN DE ESCENARIOS..9 EVALUACIN DE ESCENARIOS..9 INTERACCIN DE ESCENARIOS..10 ARID - ACTIVE REVIEWS FOR INTERMEDIATE DESIGNS...10 ARID: UN ADR/ATMA HBRIDO...11 FASE1: PRE-REUNIN....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 computacin 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 definicin La arquitectura es una abstraccin de un sistema o sistemas Como la arquitectura es abstracta, esta elimina la informacin local, los detalles de componentes privados no son arquitectnicos Los sistemas estn compuestos por muchas estructuras.

UNIDAD 5 4

ATAM ARCHITECTURE TRADEOFF ANALYSIS METHOD

El ATAM tambin 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 lder del equipo de evaluacin describe el mtodo 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 anlisis realizado hasta ahora. Este anlisis puede descubrir nuevas propuestas arquitectnicas, riesgos, no riesgos, sensitivity points y tradeoff points, que son documentados. Descripcin en detalle de los pasos del ATAM Paso 1: Presentar el ATAM En el primer paso el lder del equipo de evaluacin presenta el ATAM a los stakeholders. Este tiempo es utilizado para explicar el proceso que todos seguirn, responder preguntas, y fijar el contexto y las expectativas para el resto de las actividades. En particular, el lder describe Paso 2: Presentar las pautas del negocio Los participantes de la evaluacin, los stakeholders as como el equipo de evaluacin, necesitan entender el contexto del sistema y las principales pautas del negocio que motivan el desarrollo. En este paso, una decisin maker del proyecto (por ejemplo, el director de proyecto o el cliente del sistema) presenta el sistema desde la perspectiva del negocio. La presentacin debera describir:

UNIDAD 5 5

Paso 3: Presentar la arquitectura En este paso, el arquitecto lder (o equipo de arquitectura) realiza una presentacin describiendo la arquitectura en un nivel apropiado de detalle. Cual es el nivel apropiado depende de muchos factores: cuanto de la arquitectura ha sido diseada y documentada, cuanto tiempo hay disponible, y de los requerimientos de calidad. La informacin arquitectnica presentada afectar directamente el posible anlisis y la calidad del mismo. Paso 4: Identificar las propuestas arquitectnicas El ATAM centraliza el anlisis de una arquitectura en el entendimiento de sus propuestas arquitectnicas. En este paso, son capturadas por el equipo de evaluacin pero no son analizadas. El equipo le pedir al arquitecto que explcitamente nombre toda propuesta usada, pero ellos tambin capturarn todas las propuestas que hayan escuchado durante la presentacin del arquitecto en el paso previo. Paso 5: Generar el rbol de utilidad de los atributos de calidad En este paso el equipo de evaluacin trabaja junto con los decisin makers (el equip de arquitectura, el director y los clientes representativos) para identificar, priorizar y refinar las metas de los atributos de calidad ms importantes del sistema. Este paso crucial gua el resto del anlisis. Sin esta gua, los evaluadores pueden perder su tiempo analizando aspectos de la arquitectura que no son de inters para los stakeholders. Debe haber una manera en la cual los evaluadores y los stakeholders concentren su atencin en los aspectos de la arquitectura que son ms crticos para el xito del sistema. Esto es conseguido construyendo un rbol de utilidad Paso 6: Analizar las propuestas arquitectnicas Este paso mide cuan adecuados son el uno para el otro. Aqu, el equipo de evaluacin puede probar las propuestas arquitectnicas que realizan los atributos de calidad ms importantes. Esto es hecho en detalle documentando estas propuestas arquitectnicas e identificando sus riesgos, no riesgos, sensitivity points y tradeoff

UNIDAD 5 6

points. La meta del equipo de evaluacin es estar convencidos que la propuesta instanciada en la arquitectura que esta siendo evaluada, es la apropiada para satisfacer los requerimientos de un atributo especfico. Paso 7: Lluvia de ideas y priorizacin de escenarios

Los escenarios guan la fase de pruebas del ATAM. Est probado que generar un conjunto de escenarios facilita la discusin y la lluvia de ideas, cuando un gran nmero de stakeholders han sido reunidos para participar en el ATAM. Los escenarios son utilizados para, analizar las propuestas arquitectnicas que se utilizan en la metodologa.

Paso 8: Analizar las propuestas arquitectnicas Despus que los escenarios han sido recolectados y analizados, el equipo de evaluacin gua al arquitecto en el proceso de llevar a cabo los escenarios con ranking ms alto del paso 7 en todas las descripciones arquitectnicas que se han presentado. El arquitecto explica como las decisiones arquitectnicas relevantes contribuyen a realizar el escenario.

Paso 9: Presentar los resultados Finalmente, la informacin recogida por el ATAM necesita ser resumida y presentada a los stakeholders. En esta presentacin el lder de la evaluacin recapitula los pasos del ATAM y toda la informacin recogida en cada paso, incluyendo el contexto del negocio, los requerimientos guas, las restricciones, y la arquitectura. Pero ms importante son las salidas del ATAM.

UNIDAD 5 7

SAAM -SOFTWARE ARCHITECTURE ANALYSIS METHOD

El primer mtodo de evaluacin basado en escenarios que surgi. El foco de este mtodo es la modificabilidad. Esta nocin de evaluacin 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 descripcin de la interaccin 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 notacin 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 funcin 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 ms escenarios indirectos requieren cambios sobre la misma entidad o componente, se dice que interactan en dicho componente. En este caso, los componentes afectados necesitan ser modificados o divididos en subcomponentes para evitar la interaccin de diferentes escenarios. Podemos decir que a mayor interaccin de escenarios, menor separacin de conceptos.

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 agrupacin ha sido exitosa, porque significa que la funcionalidad del sistema ha sido modula rizada adecuadamente. Por el contrario, si la agrupacin de estos escenarios similares, afecta diferentes componentes (no son equivalentes), la arquitectura posiblemente debe ser corregida.

UNIDAD 5 8

Determinando el nivel de detalle apropiado para una descripcin arquitectnica, mediante escenarios. Resulta til reflejar en un ejemplo la relacin entre los escenarios y la descripcin arquitectnica. Uno de los beneficios de la arquitectura es la habilidad de visualizar el software desde un nivel ms alto de abstraccin. Cmo saben los diseadores 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)

11 visdiff 11 diff 12 11, 12, 13 msarn200 12 make 13 fntext main 13 13 fmext 11, 12 ctrls

(FIGURA 1) .Descripcin inicial de la arquitectura.

report

La figura anterior muestra una descripcin inicial de una arquitectura. Necesitamos mapear los escenarios hacia ella. En particular, para cada escenario 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.

UNIDAD 5 9

Descripcin de la Arquitectura En este paso se presentan las arquitecturas candidatas. Es fundamental que la notacin empleada sea bien entendida por todos los involucrados y la granularidad sea comn para todas las arquitecturas candidatas presentados. Se deben indicar los principales elementos de la arquitectura. Usualmente alcanza con:

Las estructuras de uso, de importacin y de flujo de datos y control, ms un documento de asignacin de funcionalidad. Hay una cantidad apreciable de investigacin sobre las notaciones y representaciones posibles para estos componentes. Una representacin tpica distingue entre componentes que son activos (transforman datos) y pasivos (datos almacenados). Tambin podemos describir agrupaciones de componentes en subsistemas o capas. Acompaando el punto

anterior debe existir una descripcin de cmo el sistema se comporta con el paso del tiempo: una descripcin dinmica. Puede realizarse mediante lenguaje natural o algn otro mtodo ms formal. Clasificacin de escenarios En este paso debemos clasificar los escenarios como directos o indirectos utilizando la definicin antes detallada (en la seccin Contexto y escenarios de SAAM) Evaluacin de escenarios 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 anlisis de la arquitectura. Si se da el hecho de que la informacin necesaria para llevar a cabo la clasificacin no est disponible, puede indicar que ciertos componentes de la arquitectura requieran un mayor anlisis y estudio. Usualmente el resultado de este paso se documenta en forma tabular.

UNIDAD 5 10

Interaccin 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 seccin Contexto y escenarios de SAAM. Paso 6. Evaluacin general: Un peso es asignado a cada escenario en trminos 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 mtodo ARID es conveniente para realizar la evaluacin de diseos parciales en las etapas tempranas del desarrollo. ADRs son tcnicas efectivas para asegurar la calidad dando diseos detallados del software. El mtodo 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 diseo y las respuestas nos dan el estado actual y no algo fingido. ADR es utilizado para la evaluacin de diseos detallados de unidades del software como los componentes o mdulos. Las preguntas giran en torno a la calidad y completitud de la documentacin y la suficiencia, el ajuste y la conveniencia de los servicios que provee el diseo propuesto. ARID: un ADR/ATMA hbrido Las revisiones de diseo activas y los ATAM tienen caractersticas tiles para resolver el problema de evaluar diseos preliminares. En el ADR, los interesados reciben documentacin detallada del diseo y realizan los ejercicios en forma individual, pero en las etapas preliminares de diseo no hay documentacin detallada. Adems unos de los objetivos del ARID es crear intereses en los inversionistas a travs de reuniones centrales y esto no se lograra con los trabajos individuales.

UNIDAD 5 11

Por otra parte, el ATAM se est pensado para evaluar una arquitectura entera, y no a una porcin de la misma. Adems, el inters de la calidad fue limitada a la viabilidad de la totalidad de la arquitectura. Las otras caractersticas que se centra el ATAM no nos interesan. ARID surge de combinar las mejores cualidades de los mtodos ADRs y los mtodos basados en escenarios.

De los ADRs nos quedamos con la participacin 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 participacin activa puede captar la atencin del grupo de compradores. Del ATAM nos quedamos con la idea de la generacin de los escenarios por parte de todos los interesados, los usuarios le dirn a los diseadores que los que ellos necesitan o mejor dicho que es lo que ellos esperan y si los diseadores demuestran en la pruebas que el diseo cumple con los requerimientos tambin va a atraer el inters de los compradores. Roles en ARID Se identifican tres grupos de participante en una evaluacin ARID: El equipo de verificacin, el cual est formado por tres roles: lder de la evaluacin que se encarga de preparar conjuntamente con el arquitecto la evaluacin, 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. Opcionalmente se podr tener un observador para mejorar el proceso de evaluacin El arquitecto, el cual es responsable de presentar el diseo y a quien se la dar los resultados de la evaluacin. Revisores, son los interesados en la viabilidad y adecuacin del diseo que se presentan. Son las personas que van a utilizar el diseo (software engineers) y son las personas ms adecuadas para juzgar su calidad.

UNIDAD 5 12

Fase1: PRE-reunin Primero una reunin entre el arquitecto y el lder de la evaluacin se lleva a cabo para preparar el ejercicio. Esta reunin dura un da 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 diseo reparar la presentacin del diseo, el arquitecto prepara un informe que explica el diseo, el mismo deber ser lo suficientemente detallado como para que una capacitada audiencia pueda usar el diseo.

El arquitecto presenta el informe al lder de la evaluacin, esta presentacin es provechosa por varios motivos, preparar los escenarios, el arquitecto y el lder 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: Evaluacin Durante la fase dos, los revisores son reunidos y la evaluacin comienza. Esta durar un da y medio y las 5 actividades restantes son completadas. Presentacin del ARID, el lder utiliza 30 minutos para explicar los pasos de la evaluacin a los participantes. Presentacin del diseo, el arquitecto realiza una presentacin de dos horas del diseo mostrando los ejemplos. Durante la presentacin no se podrn hacer preguntas concernientes a la implementacin ni tampoco se proponen diseos alternativos. El objetivo es ver si el diseo es adecuado no saber porque el diseo se hizo de esa manera u obtener tips para la futura implementacin. Preguntas para clarificar el diseo 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.

UNIDAD 5 13

Lluvia de ideas y priorizacin 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 continuacin 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 ms votos son usados para testear la adecuacin del diseo.

Se realiza la revisin, comenzando con el escenario que tuvo la mayor cantidad de votos, el lder de la evaluacin pide a los revisores que trabajando como grupo usen el diseo para resolver el problema presentado en el escenario. Durante este trabajo el arquitecto no podr ayudar a los revisores, sin embargo si el lder ve que los revisores van por un mal camino, puede pedirle al arquitecto que los gue o le brinde cierta informacin para no perder el tiempo (todo esto debe ser registrado por el secretario). Todas las discrepancias tambin son registradas. La etapa contina hasta que alguno de los siguientes eventos ocurre: El tiempo reservado para la revisin se acaba. Los escenarios con ms votos han sido analizados. El grupo se siente satisfecho tanto porque vio que el diseo era correcto o porque no lo aprob.

ALMA Architecture Level Modifiability Analysis

ALMA es un mtodo de evaluacin orientado a metas; dependiendo de la meta, este mtodo puede ser usado para predecir el costo de mantenimiento en una arquitectura, evaluar los riesgos al haber una modificacin en esta, o comparar un conjunto de arquitecturas para determinar cul es la ms apropiada en soportar cambios. Este mtodo se compone de cinco pasos que se muestran en la Figura 1 y que a continuacin se describen.

UNIDAD 5 14

Definir la meta de evaluacin. Dependiendo del objetivo de la evaluacin se selecciona alguna de las tres metas. Describir la arquitectura de software. En este punto se colecta la informacin de las partes ms relevantes de la arquitectura como son la descomposicin 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 informacin de la arquitectura se procede a encontrar y definir los escenarios de cambio, estos escenarios son agrupados en categoras.

Evaluar escenarios. En este punto se realiza un anlisis 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 anlisis se deben expresar ya sea de manera cuantitativa o cualitativa.

Interpretar resultados. Finalmente se interpretan los resultados as como las conclusiones del anlisis dependiendo de la meta de evaluacin seleccionada.

SNA Survivable Network Analysis SNA es un mtodo desarrollado por el CERT (Computer Emergency

Response Team) que forma parte del SEI (Software Engineering Institute). Este mtodo 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 misin a tiempo ante la presencia de ataques, fallas o accidentes. Un ejemplo de la definicin anterior es la siguiente: un cajero automtico debe garantizar al usuario los servicios esenciales aun cuando este se encuentre en presencia de algn ataque externo o falla interna. SNA utiliza tres propiedades clave para evaluar la supervivencia en un sistema. Estas son:

UNIDAD 5 15

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 daos. Recuperacin. Es la capacidad de mantener en operacin los servicios esenciales en presencia de ataques, fallas o accidentes. Este mtodo puede ser usado en el proceso de construccin de la arquitectura (evaluacin temprana), una vez que la construccin de esta ha terminado o si la arquitectura se encuentra implementada. La tcnica de evaluacin 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 intrusin, en los que se representan diferentes tipos de ataques al sistema. Para llevar a cabo la evaluacin, se requiere que se cuente con la especificacin de la arquitectura. Si hace falta documentacin de la especificacin se procede a completarla. SNA est compuesto de cuatro pasos que a continuacin se describen: 1. Definicin del sistema. En este paso se obtiene la misin del sistema, se discute el entorno de uso en trminos 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. 2. Definicin de las capacidades esenciales. A continuacin se seleccionan los servicios esenciales y los activos que usan. Se deben de seleccionar aquellos servicios y activos que sean crticos para garantizar en condiciones adversas la misin del sistema. Una vez seleccionados, estos se trazan a travs de la arquitectura para identificar los componentes que participan en proporcionar los servicios esenciales.

UNIDAD 5 16

3. Definicin de las capacidades que comprometen al sistema. En este paso se selecciona un conjunto representativo de posibles ataques basados en el entorno de operacin del sistema. Se definen los escenarios de intrusin y se trazan a travs de la arquitectura para identificar componentes que comprometan la supervivencia del sistema logrando as el acceso y dao a ste. 4. Analizar la supervivencia. Finalmente se identifican los escenarios de intrusin que contienen los componentes esenciales y que comprometen la supervivencia del sistema. Por cada componente identificado se procede a analizarlo en trminos de las capacidades de resistencia, reconocimiento y recuperacin. Estos anlisis se colocan en una tabla llamada mapa de supervivencia que contiene porcada escenario de intrusin 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. Gmez, (2008), Evaluando la arquitectura de software Parte 2. Mtodos de evaluacin, Consulto el 03 de julio del 2012, Recuperado de http://www.osgg.net/omarsite/resources/papers/ev_arch_02.pdf

Mauricio Dvila, Evaluacin de Arquitecturas de Software, Universidad de la republica Facultad de ingeniera, 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=0 CEwQFjAA&url=http%3A%2F%2Fwww.fing.edu.uy%2Finco%2Fcursos%2Fgestso ft%2FPresentaciones%2FEvaluacion%2520de%2520Arquitecturas%2520%2520G10%2FEvaluacion%2520de%2520Arquitecturas.doc&ei=dd_zT9vMOSU2AWV0P3zBg&usg=AFQjCNFoBEY6JCqN5lCs9i8PVtEnt8OdUg&sig2=0F1iur WqYrVKxUkLrYpgAQ Omar Salvador Gmez (2005), Proceso de evaluacin 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. Evaluacin de software para bibliotecas: requerimientos tcnicos, 1997. In Bibliotecas y archivos: rgano de la Escuela Nacional de Biblioteconoma y Archivonoma. Escuela Nacional de Biblioteconoma y Archivonoma. pp.23-31. (Published) [Journal Article (Print/Paginated)]. http://eprints.rclis.org/handle/10760/11257#.T_R62KsqB1E Andrea Delgado, Alberto Castro, Martn Germn, Evaluacin de Arquitecturas de Software con ATAM (Architecture Tradeoff Analysis Method): un caso de estudio, Universidad de la Repblica, Facultad de Ingeniera, Instituto de Computacin, Consulto el da 04 de julio del 2012, Recuperado de http://www.bvs.hn/cu2007/ponencias/CAL/CAL027.pdf