Evaluacion de Arquitecturas

Facultad de Ingeniera Gestin De Software
Evaluacin de Arquitecturas de Software
Integrantes
Mauricio Dvila Martn Germn Diego Crutas Andrs Garca 2.942.239-2 3.217.050-4 3.604.630-7 2.612.859-1
Evaluacin de Arquitecturas de Software Software
Gestin de
NDICE
1 INTRODUCCIN...............................................................................................2 2 EVALUANDO UNA ARQUITECTURA DE SOFTWARE.....................................................3 3 SOFTWARE ARCHITECTURE ANALYSIS METHOD (SAAM) .......................................10 4 ATAM ARCHITECTURE TRADEOFF ANALYSIS METHOD........................................16 5 ACTIVE REVIEWS FOR INTERMEDIATE DESIGNS (ARID)........................................45 6 CONCLUSIONES.............................................................................................48 6. REFERENCIAS..............................................................................................49
Pgina 1 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin
Gestin de
1 INTRODUCCIN
1.1 Qu es la Arquitectura de Software?
La Arquitectura de Software es un rea de investigacin y prctica dentro de la Ingeniera de Software. En particular, la arquitectura de sistemas grandes ha sido objeto de un inters creciente durante la pasada dcada. Para empezar, esta materia no naci en forma espontnea en 1990, ao en que el trmino Arquitectura de Software comenz a ganar aceptacin y que fue elemento de especial atencin de parte de la industria y la comunidad cientfica. Este campo fue creado por necesidad, la realidad marcaba que los sistemas de software estaban creciendo, sistemas de cientos de miles de lneas, o incluso de millones de lneas se estaban volviendo comunes. Existen tres razones por las cuales la Arquitectura de Software es importante para sistemas de software grandes y complejos: Es un vehculo de comunicacin entre los stakeholders (interesados) . La Arquitectura de Software es una representacin abstracta del sistema, a la que la mayora de los stakeholders, sino todos, pueden utilizar como base para crear entendimiento mutuo, formar consensos y comunicarse entre ellos. Es una expresin de las decisiones tempranas del diseo . La Arquitectura de Software de un sistema es el artefacto que permite en forma temprana establecer prioridades entre los diferentes aspectos a ser analizados, y es el artefacto con ms influencia en la calidad del sistema. Los aspectos de calidad tales como performance, security, maintainability, reliability, costo del esfuerzo del desarrollo actual y costo del esfuerzo del desarrollo futuro, estn todos presentes en la arquitectura. Es una abstraccin del sistema reusable y transferible . La Arquitectura de Software constituye un modelo relativamente pequeo e intelectualmente comprensible de cmo el sistema esta estructurado, y como sus componentes trabajan juntos. Este modelo es transferible entre sistemas. En particular, puede ser utilizado en otros sistemas con requerimientos similares, y puede promover reuso a gran escala y en una lnea de productos de software.
Hemos comentado sobre el surgimiento e importancia de la Arquitectura de Software, ahora intentaremos definirla: 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. [Bass, 98] Hay algunas implicancias claves en esta definicin: La arquitectura es una abstraccin de un sistema o sistemas. Esta representa sistemas en trminos de componentes abstractos que tienen propiedades externamente visibles y relaciones. 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 (comnmente llamadas vistas). Una vista por si sola puede representar nada ms que una arquitectura trivial. Es ms, una arquitectura debera ser descrita por un conjunto de vistas que soporten las necesidades de su anlisis y comunicacin.
Gestin de
2 EVALUANDO UNA ARQUITECTURA DE SOFTWARE

La pregunta que surge al definir una arquitectura es: cmo puedo estar seguro que la arquitectura elegida es la correcta para mi software? No es una pregunta fcil de responder, lo que si sabemos es que la arquitectura es la piedra fundamental de cualquier software. La arquitectura es quien define los atributos de calidad de un sistema. Hasta hace poco, no existan mtodos de utilidad para validar arquitecturas, que respondieran con confianza a la pregunta planteada. Antes de continuar, sigamos analizando la definicin de arquitectura tomada: 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. [Bass, 98] Por propiedades externamente visibles nos estamos refiriendo a lo que otros componentes asumen de lo que hace un componente, como ser los servicios que provee, caractersticas de performance, manejo de fallas, entre otras. La arquitectura define componentes (como ser mdulos, objetos, procesos, subsistemas, entre otros) y relaciones relevantes (como llamadas, sincronismos, dependencias, entre otras). La arquitectura es el resultado de las decisiones tempranas de diseo, que son necesarias antes de empezar a construir el sistema. Para poder entender claramente que es evaluar una arquitectura, hay que tener claro previamente el siguiente concepto: La Arquitectura permite o excluye prcticamente todos los atributos de calidad del sistema. Esto nos lleva a una verdad fundamental sobre la evaluacin de arquitecturas: Si las decisiones arquitectnicas determinan los atributos de calidad del sistema, entonces es posible evaluar las decisiones arquitectnicas con respecto a su impacto sobre dichos atributos.
2.1 Qu es arquitectnico?
Siempre en algn momento surge la pregunta: Qu es arquitectnico? De repente no surge exactamente de esta manera, pero puede ser preguntada de las siguientes formas: Cul es la diferencia entre arquitectura y diseo de alto nivel? Son arquitectnicos los detalles como las prioridades de los procesos? Por qu debe ser considerados los detalles de implementacin como ser los desbordes de buffers? Son las interfaces de los componentes parte de la arquitectura? Si tengo el diagrama de clases, necesito hacer algo ms? Est la arquitectura involucrada con el comportamiento en tiempo de ejecucin o la estructura esttica? Es el sistema operativo parte de la arquitectura? Lo es el lenguaje de programacin? Si estoy condicionado a utilizar un producto comercial (COTS), es arquitectnico? Si puedo elegir cualquier producto comercial, es arquitectnico?
Gestin de
Razonemos de dos maneras: Consideremos la definicin de arquitectura que estamos tomando. Parafraseando: Es de inters para la Arquitectura de Software la organizacin del sistema a alto nivel, describindola en trminos de componentes, sus propiedades externamente visibles, y las relaciones entre ellos. Esto ltimo es verdadero, pero falla cuando nos centralizamos en determinados contextos, dado que el contexto influye en lo que es arquitectnico. Por ejemplo, si mi contexto es un subsistema de un sistema dado, lo que es arquitectnico para mi, no lo es para el arquitecto del sistema completo. Preguntmonos ahora, qu no es arquitectnico? Se ha dicho que los algoritmos no son arquitectnicos, las estructuras de datos no son arquitectnicas, los detalles del flujo de datos no son arquitectnicos. Esto ltimo, no es del todo verdadero. Por ejemplo, algunas propiedades de los algoritmos, como ser su complejidad, pueden tener un fuerte impacto sobre la performance. Entonces, existe un principio para determinar qu es arquitectnico? Formulmoslo a partir del uso que se le da a una arquitectura. Nuestro criterio para determinar que es arquitectnico sera entonces: Debe ser un componente, relacin entre componentes, o una propiedad (de componentes o relaciones) que necesita ser externamente visible, con el objetivo de razonar sobre la habilidad del sistema de alcanzar sus requerimientos de calidad, o de soportar la descomposicin del sistema en partes independientemente implementables. Aqu presentamos corolarios de este principio: La arquitectura describe que hay en el sistema . Cuando se determina el contexto, se determinan las fronteras que describen que hay dentro y que hay fuera del sistema. La arquitectura describe lo que hay dentro. Una arquitectura es una representacin abstracta del sistema . La informacin en una arquitectura es abstracta y sin embargo es la representacin ms significativa del sistema. Dada la especificacin de la arquitectura, no se debera necesitar ninguna otra descripcin abstracta. Lo que es arquitectnico debera ser crtico para razonar acerca de requerimientos crticos. La arquitectura es el nexo entre los requerimientos y el diseo. Si alguna informacin es crtica para argumentar si el sistema alcanzar los requerimientos de calidad, entonces es arquitectnico. La especificacin de una arquitectura necesita ser comprensible . La idea de una representacin del sistema a alto nivel, es que se puede entender y trabajar con ella. Demasiado detalle podra ir en contra de este propsito. Una arquitectura debe restringir. Esta impone requerimientos a todos los diseos de bajo nivel. En resumen, ser arquitectnico, es ser la representacin ms abstracta del sistema, que permite razonar acerca de los requerimientos crticos y las restricciones a todos los niveles de refinamiento subsecuentes.
2.2 Por qu evaluar una Arquitectura?

Cuanto ms temprano se encuentre un problema en un proyecto de software, mejor. El costo de arreglar un error durante las fases de requerimientos o diseo, es mucho menor al costo de arreglar ese mismo error en la fase de verificacin. Dado que la arquitectura es un producto temprano de la fase de diseo, esta tiene un profundo efecto en el sistema y en el proyecto. Una mala arquitectura puede llevar a un proyecto al fracaso. Todos los requerimientos de calidad pueden quedar insatisfechos. La arquitectura tambin determina la estructura del proyecto: configuracin, agenda y presupuesto, alcance, entre otros aspectos. Es mejor cambiar la arquitectura antes que otros artefactos, que estn basados en ella, se estabilicen. Pgina 4 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin
Gestin de
Realizar una evaluacin de la arquitectura es la manera ms econmica de evitar desastres.
2.3 Cundo una Arquitectura puede ser evaluada?

Generalmente, la evaluacin de la arquitectura ocurre despus que esta ha sido especificada, pero antes que empiece la implementacin. En un proceso iterativo y/o incremental, la evaluacin se puede realizar al final de cada ciclo. Sin embargo, uno de los atractivos de la evaluacin de arquitecturas es que se puede efectuar en cualquier etapa de la vida de una arquitectura. En particular, existen dos variaciones tiles: temprana y tarda. 2.3.1 Evaluacin temprana La evaluacin no tiene porque esperar a que la arquitectura este totalmente especificada. Esta puede ser utilizada en cualquier etapa del proceso de creacin de la arquitectura, para examinar las decisiones arquitectnicas ya tomadas y decidir entre las opciones que estn pendientes. Por supuesto, la completitud y fidelidad de la evaluacin es directamente proporcional a la completitud y fidelidad de la descripcin de la arquitectura. 2.3.2 Evaluacin tarda Esta variacin toma lugar no solo cuando la arquitectura esta terminada, tambin cuando la implementacin esta completa. Este caso ocurre cuando la organizacin hereda un sistema legado. La tcnica para evaluar un sistema legado es la misma que para evaluar un sistema recin nacido. Una evaluacin es til para entender el sistema legado, y saber si este cumple con los requerimientos de calidad y comportamiento. En general, una evaluacin debe realizarse cuando hay suficiente de la arquitectura como para justificarlo. Una buena regla sera: realizar una evaluacin cuando el equipo de desarrollo empieza a tomar decisiones que dependen de la arquitectura y el costo de deshacerlas sobrepasa al costo de realizar una evaluacin.
2.4 Quines estn involucrados?

Hay dos grupos de personas involucrados en la evaluacin de la arquitectura. 2.4.1 Equipo de evaluacin Estas son las personas que conducirn la evaluacin y realizaran el anlisis. 2.4.2 Stakeholders Estos son los interesados en la arquitectura, y en el sistema que se construir a partir de ella. Algunos de los stakeholders, pero no todos, sern miembros del equipo de desarrollo, como ser implementadores, verificadores, entre otros. Un tipo especial de stakeholder es el decision maker (tomador de decisiones) del proyecto. Estos son los interesados en la salida de la evaluacin y tienen el poder de toma de decisiones. Algunos de ellos son el arquitecto, los diseadores y el director de proyecto. Cuando un stakeholder quiere que algo sea verdad en la arquitectura, un decision maker tiene el poder de asignar recursos para hacerlo realidad. Generalmente el cliente de la evaluacin de la arquitectura es un decision maker, con un gran inters en la salida de la misma y poder sobre todo el proyecto.
Evaluacin de Arquitecturas de Software Gestin de Software En ocasiones el equipo de evaluacin esta formado por integrantes del plantel del proyecto, en cuyo caso tambin son stakeholders. Esto no est recomendado dado que habr prdida de la objetividad a la hora de ver la arquitectura.
2.5 Qu resultado produce la evaluacin de una Arquitectura?

En trminos concretos, la evaluacin de la arquitectura produce un informe, la forma y contenido del mismo vara segn el mtodo utilizado. En particular, produce repuestas a dos tipos de preguntas: Es esta arquitectura adecuada para el sistema para la cual fue diseada? Cul de dos o ms arquitecturas propuestas es la ms adecuada para el sistema? Decimos que una arquitectura es adecuada cuando cumple dos criterios: El sistema resultante de ella cumple con los objetivos de calidad. No todas las propiedades de calidad del sistema son resultado directo de la arquitectura, pero muchas lo son. El sistema puede ser construido con los recursos con que se cuenta: el plantel, el presupuesto, el sistema legado (si hay), entre otros. Esto es, la arquitectura es construble. Un resultado que tambin produce la evaluacin de una arquitectura es la captura y priorizacin de las metas que la arquitectura debe cumplir para poder ser considerada adecuada. La evaluacin de una arquitectura no produce resultados cuantitativos. No es de inters, por ejemplo, evaluar la performance en cantidad de transacciones por segundo a esta altura, dado que el sistema no esta construido an. Lo que interesa, en un espritu de mitigacin de riesgos, es aprender como un atributo de calidad es afectado por una decisin de diseo arquitectnico, para que de esta manera se pueda estudiar con cuidado dicha decisin. Una evaluacin arquitectnica dice si una arquitectura es adecuada respecto a un conjunto de metas, y problemtica con respecto a otro conjunto de metas. En ocasiones, las metas pueden ser contradictorias entre ellas, o algunas ser ms importantes que otras. El director de proyecto es quien deber tomar la decisin si la arquitectura evala bien o mal en las distintas reas. La evaluacin ayuda a encontrar debilidades, no dir si o no, bien o mal, 6 en 10, dir donde estn los riesgos.
2.6 Por qu cualidades puede ser evaluada una Arquitectura?

No es del todo cierto que podamos decir que el sistema alcanzar todas sus metas de calidad con solo mirar la arquitectura. Pero muchos atributos de calidad yacen directamente en el reino de la arquitectura. Una arquitectura puede ser evaluada en base a los siguientes atributos de calidad: Performance: Refiere a la responsiveness del sistema. Es el tiempo requerido para responder a un estmulo (evento), o nmero de eventos por unidad de tiempo. Por ejemplo, una posible medida podra ser cantidad de transacciones por segundo. Reliability: Es la habilidad del sistema de continuar operando sobre el tiempo. Es usualmente medida en tiempo promedio entre fallas. Availability: Es la porcin de tiempo en que el sistema esta levantado y corriendo. Se mide como el tiempo transcurrido entre fallas, as como, cuan rpido el sistema esta apto para reanudar y quedar operativo ante una falla. Security: Es la medida de la habilidad del sistema de resistirse al uso no autorizado y negar los servicios, mientras los provee a usuarios legtimos.
Evaluacin de Arquitecturas de Software Gestin de Software Modifiability: Es la habilidad de realizar cambios al sistema en forma rpida y a bajo costo. Portability: Es la habilidad del sistema de correr sobre diferentes ambientes. Estos ambientes pueden ser de hardware, de software o una combinacin de ambos. Portability es un caso particular de modifiability. Functionality: Es la habilidad del sistema de hacer el trabajo para el cual fue construido. Variability: Es la capacidad de la arquitectura de ser expandida o modificada para producir nuevas arquitecturas. Variability es importante cuando la arquitectura se va a utilizar como piedra fundamental de toda una familia de productos relacionados, como ser una lnea de producto. Subsetability: Es la habilidad de soportar la produccin de un subconjunto del sistema. Subsetability permite el desarrollo incremental. Es un tipo especial de variability. Conceptual integrity: Es la visin que unifica el diseo del sistema en todos los niveles. La arquitectura debe hacer cosas similares en forma similar. Debe mostrar consistencia en los mecanismos, decisiones y patrones aplicados. Si otro atributo de calidad, adems de los mencionados antes, es importante para determinado proyecto, este tambin debe formar parte de la evaluacin. En particular, el ATAM permite definir nuevos atributos de calidad a ser utilizados en la evaluacin.
2.7 Por qu los atributos de calidad son demasiados imprecisos para el anlisis?
Los atributos de calidad son la base para a la evaluacin de una arquitectura, pero por si solos no son suficiente para juzgar la adecuabilidad de la arquitectura. Generalmente, los requerimientos son escritos de la siguiente manera: El sistema debe ser robusto. El sistema debe ser modificable. El sistema debe ser seguro. El sistema debe tener una performance aceptable. Cada una de las frases anteriores esta sujeta a diferentes interpretaciones y malos entendidos. Lo que uno puede considerar robusto, otro puede considerarlo apenas aceptable. El punto es que los atributos de calidad no son cantidades absolutas, existen en un contexto con metas especficas. En particular: Un sistema es modificable (o no) con respecto a un tipo de cambio especfico. Un sistema es seguro (o no) con respecto a un tipo de amenaza especfica. Un sistema es confiable (o no) con respecto a la ocurrencia de un tipo de falta especfica. Un sistema es performante (o no) con respecto a un criterio especfico de performance. Una arquitectura es construble (o no) con respecto a restricciones de tiempo y presupuesto especficas. No parece razonable, considerar que un sistema pueda alguna vez, por ejemplo, ser completamente confiable bajo toda circunstancia (pensar en problemas de energa, meteorolgicos, entre otros). Dado esto, es importante que el arquitecto entienda perfectamente bajo que circunstancias un sistema debe ser confiable para ser considerado aceptable. Por lo tanto, el primer trabajo que debe realizar una evaluacin de arquitectura es obtener las metas especficas de calidad ante las cuales la arquitectura ser juzgada.
Evaluacin de Arquitecturas de Software Gestin de Software Si algunas de estas metas no son especficas o son ambiguas, se debe pedir a los stakeholders que ayuden al equipo de evaluacin a reescribirlas. El mecanismo a utilizar para representar estas metas es el de escenario. Un escenario es una pequea descripcin de la interaccin de un stakeholder con el sistema. Los escenarios son parecidos a los casos de uso.
2.8 Cules son las salidas de una evaluacin arquitectnica?

Las salidas de una evaluacin arquitectnica son informacin e ideas sobre la arquitectura.
2.8.1 Lista priorizada de los atributos de calidad requeridos Una evaluacin arquitectnica solo puede proceder si se conoce el criterio de adecuabilidad. Es ms, la obtencin de los atributos de calidad requeridos contra los cuales la arquitectura ser juzgada, constituye la mayor parte del trabajo. Pero ninguna arquitectura puede tener una lista interminable de atributos de calidad, y por lo tanto, se utilizan mtodos de priorizacin consensuados. 2.8.2 Riesgos y no riesgos Los riegos son decisiones arquitectnicas potencialmente problemticas. Los no riesgos son buenas decisiones, que confan en asunciones que con frecuencia son implcitas en la arquitectura. Documentar riesgos y no riesgos consiste en: Una decisin arquitectnica (o una decisin que no ha sido tomada) Una respuesta especfica al atributo de calidad que esta siendo tratado, junto con las consecuencias del nivel predecible de la respuesta. Una base lgica por el efecto positivo o negativo que la decisin tuvo en alcanzar el requerimiento del atributo de calidad. Para que un no riesgo se mantenga como tal, las asunciones no deben cambiar, o al menos si cambian, la designacin como no riesgo debe ser rejustificada.
2.9 Cules son los costos y beneficios de realizar una evaluacin arquitectnica?
El mayor beneficio que brinda la evaluacin de una arquitectura, es que descubre los problemas que si se hubiesen dejado sin descubrir, habra sido mucho ms costoso corregirlos luego. En breve, una evaluacin produce una mejor arquitectura. Algunos beneficios ms que brinda la evaluacin se presentan a continuacin. 2.9.1 Rene a los stakeholders En una evaluacin arquitectnica es, comnmente, la primera vez en que la mayora de los stakeholders se encuentran. Es ms, es la primera vez que el arquitecto se encuentra con ellos. Todos comparten un objetivo, lograr un sistema exitoso. 2.9.2 Fuerza una articulacin en las metas especficas de calidad El rol del stakeholder es articular las metas de calidad que la arquitectura debera alcanzar para ser considerada exitosa. Estas metas no siempre son capturadas en algn documento de requerimientos.
Evaluacin de Arquitecturas de Software Software 2.9.3 Fuerza una explicacin clara de la arquitectura
Gestin de
El arquitecto convoca a un grupo de personas, no en privado, para explicarles la creacin de la arquitectura, en detalle y sin ambigedades. El proyecto se ve beneficiado cuanto antes se realice esta explicacin. 2.9.4 Mejora la calidad de la documentacin de la arquitectura Generalmente, la evaluacin pide documentacin que an no esta terminada, entonces se designa alguien del plantel a terminarla. Una vez ms, el proyecto se ve beneficiado porque se ingresa al desarrollo mejor preparado al tener los documentos terminados. 2.9.5 Descubre oportunidades de reuso Los stakeholders y el equipo de evaluacin provienen de afuera del proyecto de desarrollo, pero trabajan o estn familiarizados con otros proyectos. Por lo tanto, ambos estn en una buena posicin para detectar componentes que pueden ser reusados en otros proyectos, o conocer componentes que ya existen que pueden ser utilizados en el proyecto actual. 2.9.6 Resultan mejoras en las arquitecturas Las organizaciones que practican la evaluacin arquitectnica como un estndar de su proceso de desarrollo, reportan una mejora en la calidad de las arquitecturas que son evaluadas. La evaluacin de arquitecturas resulta en mejores arquitecturas no solo despus de hecha, pero antes tambin. Los costos de la evaluacin arquitectnica son todos costos de personal y costos de oportunidad por aquel personal que participa de la evaluacin en vez de hacer otra cosa. Estos costos son sencillos de calcular (estn tabulados).
Gestin de
3 SOFTWARE ARCHITECTURE ANALYSIS METHOD (SAAM)

3.1 Introduccin
SAAM (Software Architecture Analysis Method) fue el primer mtodo de evaluacin basado en escenarios que surgi. El foco de este mtodo es la modificabilidad.
3.2 Propsito
Los creadores de SAAM idearon un mtodo para evaluar, por medio de escenarios, los diferentes atributos de calidad que las arquitecturas de software demandaban. En la prctica SAAM ha demostrado ser til para evaluar muchos atributos de calidad rpidamente, como portabilidad, modificabilidad, extensibilidad, integrabilidad, as como el cubrimiento funcional que tiene la arquitectura sobre los requerimientos del sistema. El mtodo tambin puede ser utilizado para evaluar aspectos ms ligados con la arquitectura como performance o confiabilidad. Sin embargo, existen otros mtodos como ATAM (Architecture Trade-off Analysis Method) que exploran estos aspectos con ms profundidad. SAAM puede ser utilizado para evaluar una o mltiples arquitecturas. Si se comparan dos o ms se culmina el anlisis con una tabla indicando las fortalezas y debilidades de cada una en cada escenario. Si se evala una sola, se culmina con un reporte sealando los componentes computacionales donde la arquitectura no alcanza el nivel requerido. En ningn caso se emite un valor absoluto acerca de la calidad arquitectnica.
3.3 Contexto y escenarios de SAAM.

La mayora de los atributos de calidad son demasiados complejos y amorfos para ser evaluados simplemente. Consideremos dos ejemplos: Supongamos que un sistema puede acomodarse a nuevas plataformas computacionales, con el solo hecho de recompilarse, pero antes de la recopilacin, deben ser modificados manualmente una docena de archivos y programas. Nosotros decimos que el sistema es o no modificable? Supongamos que un sistema posee una interfaz de usuario que se piensa cuidadosamente para que los usuarios novatos puedan utilizarlo con un mnimo de esfuerzo, pero esto implica que la utilizacin del sistema sea muy tediosa para los usuario experimentados. Nosotros decimos que el sistema es o no usable? El punto en los ejemplos anteriores, es que no existe aislamiento para evaluar esos atributos de calidad. Dichos atributos slo tienen sentido y pueden ser evaluados dentro de un contexto. Un sistema es modificable (o no) respecto a ciertas clases de cambios, es seguro (o no) respecto a amenazas especficas, es usable (o no) respecto a ciertos tipos de usuarios. Declaraciones como el sistema es altamente mantenible, no tienen significado operacional. Deseamos validar enunciados sobre la calidad del sistema a partir de una descripcin arquitectnica, y no a travs de enunciados abstractos y en general, carentes de significado. 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. Un escenario en particular sirve como representante para un grupo de escenarios diferentes. Por ejemplo el escenario Cambiar el color de fondo de todas las ventanas a azul es esencialmente equivalente a cambiar las decoracin en todas las ventanas.
Evaluacin de Arquitecturas de Software Gestin de Software Entendemos por escenarios equivalentes a aquellos que al ejecutarse ponen en juego los mismos componentes y conectores de la arquitectura. 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 modularizada adecuadamente. Por el contrario, si la agrupacin de estos escenarios similares, afecta diferentes componentes (no son equivalentes), la arquitectura posiblemente debe ser corregida. Para ilustrar los conceptos que hemos definido hasta el momento veremos un ejemplo.
3.3.1 Determinando el nivel de detalle arquitectnica, mediante escenarios.
apropiado
para
una
descripcin
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.
11 visdiff 11 11, 12 ctrls diff
12 msarn200 12 make
11, 12, 13 main
13
fmext
13 13 report
fntext
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. El mdulo principal, main, es afectado por los tres escenarios. Cul es el significado de esta situacin?. Puede tener tres significados distintos: Los escenarios son todos de la misma clase; es decir, podran ser variantes del mismo escenario bsico. Para este caso, el hecho de que los escenarios sean de Pgina 11 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin
Evaluacin de Arquitecturas de Software Gestin de Software la misma clase y se agrupen juntos puede tomarse como una seal positiva. Significa que la arquitectura exhibe alta cohesin. Los escenarios son de clases distintas y el mdulo main podra estar ms subdividido, aunque esto no se haya mostrado en la descripcin de la arquitectura. Podra ocurrir que el mdulo estuviera compuesto por tres funciones cada una de las cuales procesara cada escenario. En esta caso, podramos afirmar que el anlisis ayud a refinar el nivel de descripcin del mdulo en cuestin. Los escenarios son de clases distintas y el mdulo main no puede subdividirse ms. Este caso revela un rea de problema potencial. Si escenarios de diferentes clases afectan al mismo mdulo, entonces la arquitectura no est dividida adecuadamente.
3.4 Roles en SAAM

Identificamos tres clases de roles 3.4.1 Interesados externos No estn directamente involucrados en el proceso de desarrollo de la arquitectura de software. Ellos son los interesados en el sistema y sus principales tareas consisten en presentar los objetivos del negocio, proveer los atributos de cualidad del sistema y proveer los escenarios directos e indirectos junto con su priorizacin. Ejemplos de interesados externos son: clientes, usuarios finales, administradores del sistema, etc. 3.4.2 Interesados internos Estn directamente involucrados con el proceso de desarrollo y proponen estrategias y solucione para construir la arquitectura de modo que pueda reunir los atributos de calidad correspondientes. Tienen el rol de analista. Definen y presentan los principales conceptos arquitectnicos, estimando costos y realizando actividades de planificacin. Ejemplos de interesados internos son: arquitectos de software, analistas de requerimientos. 3.4.3 El equipo de SAAM Ningn integrante del equipo tiene inters directo en la arquitectura del sistema, pero conducen la sesin de evaluacin de SAAM. Ellos tienen el papel de apoyar y asesorar los interesados del sistema y pueden detallar los atributos de calidad principales junto con los escenarios asociados a los mismos. El equipo consiste en un evaluador (el lder o portavoz), expertos en el dominio de la aplicacin, expertos externos en arquitectura (opcional) y secretario.
3.5 Mtodo de anlisis de SAAM

El mtodo de evaluacin consiste en seis pasos que se detallan a continuacin. 3.5.1 Paso 1. Desarrollo de escenarios La meta principal es capturar las principales actividades que el sistema debe soportar. Los escenarios encontrados deben reflejar los atributos de calidad de inters y tambin mostrar la interaccin entre las diferentes personas que utilizarn el sistema: usuarios finales, administrador, mantenedor, desarrolladores, etc. Este paso debe ser realizado por un equipo experto en el dominio de la aplicacin que se est desarrollando. Dado que la informacin sobre las actividades que el sistema soportar, por lo general, es recabada de forma gradual, y puede sufrir modificaciones, el mejor mtodo para ejecutar este paso, es realizar un proceso iterativo e incremental. Adems, se recomienda realizarlo de forma paralela al paso 2: Descripcin de la Arquitectura, que se describir a continuacin. Pgina 12 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin
Evaluacin de Arquitecturas de Software Gestin de Software De esta forma, se logra que las dos actividades indicadas en los pasos 1 y 2 influyan y se retroalimenten una sobre la otra. Los escenarios que se desarrollen deben ser tales que: Reflejen el punto de vista de cada interesado. Reflejen los atributos ms importantes requeridos. Reflejen la variedad de interacciones posibles. El total sea un nmero manejable, es decir haya recursos suficientes como para desarrollarlos, ejecutarlos y evaluarlos.
3.5.2 Paso 2. 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.
3.5.3 Paso 3. 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) Por ejemplo, si un escenario es directo en la arquitectura A e indirecto en B, no significa que A es mejor que B, pues A puede soportarlo sin cambios, lo que aparentara como una ventaja, pero podra ser de una forma ineficiente. 3.5.4 Paso 4. 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. 3.5.5 Paso 5. 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. 3.5.6 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. En este proceso deben participar todos los interesados. Por ejemplo, si se estn comparando varias propuestas arquitectnicas, el peso asignado es til para resolver casos en los que la propuesta de la arquitectura A es mejor en los escenarios a, b y c, y la propuesta de la arquitectura B lo es en d y e.
Evaluacin de Arquitecturas de Software Software 3.5.7 Observaciones sobre el mtodo de anlisis de SAAM
Gestin de
Los pasos 1 y 2 del SAAM son muy interdependientes. Decidir el nivel apropiado de detalle para una arquitectura depende de los tipos de escenarios que se desean evaluar. Determinar un conjunto razonable de escenarios depende de los tipos de actividades que se esperan que el sistema realice. El significado de "razonable" aqu depende de las necesidades de los interesados del sistema. Una relacin importante entre los pasos 1 y 2 es el papel que juegan los escenarios directos que se distinguen en el paso 1, pues ayudan a entender la descripcin arquitectnica que se realiza en el paso 2. Los escenarios directos pueden ayudar a determinar conexiones arquitectnicas y a formular descripciones ms estructuradas de la conducta dinmica de una arquitectura. Los escenarios directos proporcionan una forma de realizar caminatas (walkthrough) a travs de la arquitectura, ayudando tambin a la documentndolo adecuada de la misma. En lugar de ofrecer una sola mtrica de arquitectura, SAAM produce una coleccin de pequeas mtricas realizando anlisis por escenarios. Dado esta caracterstica de mini-mtrica, SAAM puede ser utilizado para comparar arquitecturas basadas en escenarios
3.6 Esfuerzo estimado en la aplicacin de SAAM

La sesin de evaluacin de SAAM est planificada para ser llevada a cabo en un da. Esto incluye la realizacin de los seis pasos del mtodo y excluye el tiempo de preparacin de la evaluacin, as como tambin el esfuerzo de investigacin de las arquitecturas candidatas con la identificacin y anlisis de los escenarios y estudios posteriores. Dependiendo del tamao del proyecto, el nmero de interesados involucrados durante la sesin de evaluacin vara. Algunos reportes muestran que en evaluaciones realizadas para proyectos entre 5-100 KLOCs el esfuerzo estimado para completar totalmente las actividades relacionadas con el mtodo es de catorce das.
3.7 Fortalezas y debilidades

Las principales fortalezas del mtodo son:
Los interesados entienden en profundidad la arquitectura o arquitecturas que se analizarn. En algunos casos, luego de la sesin de evaluacin de SAAM, la documentacin relacionada con arquitectura de software es mejorada. Aumenta la comunicacin entre los interesados. Con respecto a la modificabilidad, podemos decir que, los escenarios correspondientes a futuros cambios pueden ser evaluados en la arquitectura o arquitecturas candidatas, logrando estudiar e identificar las reas potencialmente complejas. El esfuerzo y costo de los cambios mencionados pueden ser estimados con anticipacin.
Las debilidades del mtodo son las siguientes: El proceso de generacin de escenarios est basado en la visin de los interesados. En general, existe un muy pequeo esfuerzo para imaginar los escenarios indirectos. SAAM no provee una mtrica clara sobre la calidad de la arquitectura analizada. La descripcin de la arquitectura puede resultar confusa a la hora de realizar comparaciones si no se adoptan una notacin y un nivel de detalle comunes. El equipo de evaluacin confa en la experiencia de los arquitectos para proponer arquitecturas candidatas. En general, este equipo no tiene conocimiento sobre el conjunto completo de requerimientos y los objetivos del negocio.
3.8 Conclusin
SAAM es un mtodo para la evaluacin temprana de arquitecturas, con respecto a algunos atributos de calidad expresados en el contexto de circunstancias especficas (escenarios). Proporciona un
Gestin de
marco conceptual suficiente para saber qu es necesario, pero no suficiente para realizar una evaluacin completa de la arquitectura. La utilizacin de escenarios ha demostrado constituir una herramienta importante para la comunicacin entre el equipo de desarrollo, el equipo de diseadores y los gerentes y superiores. La evaluacin de arquitecturas mediante SAAM posee algunos puntos en comn con los conceptos tradicionales de acoplamiento y cohesin. Las arquitecturas buenas exhiben bajo acoplamiento y alta cohesin. Qu significa esto en trminos de SAAM? El significado de bajo acoplamiento est relacionado con que los escenarios no afecten grandes cantidades de componentes. Alta cohesin significa que los componentes no soportan varios escenarios. (escasa interaccin de escenarios). Estas correspondencias implica que el anlisis mediante SAAM brinda una metodologa dirigida para elegir las mejores arquitecturas (con bajo acoplamiento y alta cohesin). Actualmente, SAAM no est bien preparado para predecir la performance de un sistema. Dado un escenario que refleja que es importante lograr una determinada performance, un usuario de SAAM intentara realizar un experimento ejecutando el escenario y midiendo los resultados conceptualmente. Medir la performance de esta manera, no es confiable. Actualmente se puede predecir la performance por medios ms analticos y seguros. La incorporacin de evaluacin de la performance en SAAM es un rea de investigacin continua. En el futuro, nos gustara que SAAM fuera ms repetible. Es decir, debera ser probable que dos evaluadores diferentes, dados el mismo juego de escenarios, deben derivar en las mismas particiones funcionales y los mismos resultados de evaluacin.
Gestin de
4 ATAM ARCHITECTURE TRADEOFF ANALYSIS METHOD

El Architecture Tradeoff Analysis Method (ATAM) obtiene su nombre no solo porque nos dice cuan bien una arquitectura particular satisface las metas de calidad, sino que tambin provee ideas de cmo esas metas de calidad interactan entre ellas, como realizan concesiones mutuas entre ellas. Tener un mtodo estructurado, permite hacer el anlisis repetible y ayuda a asegurar que las preguntas acerca de una arquitectura sern contestadas en forma temprana, cuando es relativamente econmico corregir problemas. 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.
4.1 Resumen de los pasos del ATAM

La parte principal del ATAM consiste de nueve pasos. Estos pasos se dividen cuatro grupos: Presentacin, donde la informacin es intercambiada. Investigacin y anlisis, donde se valoran los atributos claves de calidad requeridos, uno a uno con las propuestas arquitectnicas. Pruebas, donde se revisan los resultados obtenidos contra las necesidades relevantes de los stakeholders. Informes, donde se presentan los resultados del ATAM.
4.1.1 Presentacin
1.
Presentar el ATAM El lder del equipo de evaluacin describe el mtodo a los participantes, fija las expectativas y responde las preguntas que puedan surgir.
2.
Presentar las pautas del negocio Un representante del proyecto (por ejemplo, el director de proyecto o el cliente del sistema) describe las metas del negocio que motivan el esfuerzo de desarrollo y que se convertirn en las pautas primordiales de la arquitectura (por ejemplo, alta disponibilidad o alta seguridad).
3.
Presentar la arquitectura El arquitecto describe la arquitectura, enfocndose en como esta sigue las pautas del negocio.
4.1.2 Investigacin y anlisis

4.
Identificar las propuestas arquitectnicas Las propuestas arquitectnicas son identificadas por el arquitecto, pero no son analizadas.
Evaluacin de Arquitecturas de Software Software 5. Generar el rbol de utilidad de los atributos de calidad
Gestin de
Los atributos de calidad que comprometen la utilidad del sistema (performance, availability, entre otros) son obtenidos, especificados en escenarios (con estmulos y respuestas) y priorizados.
6.
Analizar las propuestas arquitectnicas Basados en los escenarios de mayor prioridad identificados en el paso 5, las propuestas arquitectnicas que cumplen con estos escenarios, son obtenidas y analizadas (por ejemplo, una propuesta arquitectnica que logra una meta de performance, ser objeto de un anlisis de performance). Durante este paso los riesgos arquitectnicos, los no riesgos, los sensitivity points y tradeoff points son identificados.
4.1.3 Pruebas
7.
Lluvia de ideas y priorizacin de escenarios Un gran conjunto de escenarios es obtenido por todos los stakeholders. Este conjunto es priorizado mediante votacin.
8.
Analizar las propuestas arquitectnicas 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.
4.1.4 Informes
9.
Presentar los resultados Basados en la informacin recogida durante el ATAM (propuestas, escenarios, rbol de utilidad, riesgos, no riesgos, sensitivity points y tradeoff points), el equipo de ATAM presenta los resultados a los stakeholders.
A veces, se deben hacer modificaciones dinmicas al calendario para poder acomodarse a la disponibilidad del personal o de la informacin arquitectnica. A pesar que los pasos estn numerados, sugiriendo linealidad, este no es un proceso en cascada estricto. De vez en cuando, un evaluador podr volver a pasos anteriores, saltar a un paso posterior, o iterar entre pasos, segn la necesidad. La importancia de los pasos esta claramente delineada en las actividades involucradas en el ATAM, junto con las salidas de estas actividades.
4.2 Descripcin en detalle de los pasos del ATAM

4.2.1 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: Los pasos del ATAM en resumen. Las tcnicas que sern utilizadas para la obtencin y anlisis: generacin del rbol de utilidad, obtencin y anlisis de las propuestas arquitectnicas, lluvia de ideas y priorizacin de escenarios.
Evaluacin de Arquitecturas de Software Gestin de Software Las salidas de la evaluacin: los escenarios obtenidos y priorizados, las preguntas utilizadas para entender y evaluar la arquitectura, el rbol de utilidad describiendo y priorizando los requerimientos que guan la arquitectura, un conjunto de propuestas arquitectnicas identificadas, un conjuntos de riesgos y no riesgos descubiertos, y un conjunto de sensitivity points y tradeoff points descubiertos. 4.2.2 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, un decision 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: Las funciones ms importantes del sistema. Toda restriccin tcnica, dirigencial, econmica o poltica relevante. Como las metas del negocio y el contexto se relacionan con el proyecto. La mayora de los stakeholders. Las guas de la arquitectura (mayoritariamente las metas de los atributos de calidad que dan forma a la arquitectura).
Plantilla de ejemplo para presentacin del negocio.
4.2.3 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. La presentacin de la arquitectura debera cubrir: Las restricciones tcnicas, como el sistema operativo, el hardware, o middleware prescrito para el uso. Otros sistemas con los cuales el sistema debe interactuar. Propuestas arquitectnicas utilizadas para alcanzar los requerimientos de los atributos de calidad.
Evaluacin de Arquitecturas de Software Gestin de Software Las vistas contenidas en el documento de la arquitectura, son el principal vehculo que el arquitecto debera utilizar para presentar la arquitectura. En este momento el equipo de evaluacin comienza su prueba inicial capturando las propuestas arquitectnicas como preludio del paso 4.
Plantilla de ejemplo para presentacin de la arquitectura.
4.2.4 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. El ATAM se concentra en identificar propuestas arquitectnicas y estilos arquitectnicos porque estos representan la manera en que la arquitectura cumple con los atributos de calidad de mayor prioridad, esto significa que se asegura que los requerimientos crticos sern alcanzados de manera predecible. Estas propuestas arquitectnicas definen las estructuras importantes del sistema, y describen como el sistema puede crecer, responder a cambios, entre otros.
Evaluacin de Arquitecturas de Software Gestin de Software Un estilo arquitectnico incluye una descripcin de los tipos de componentes y su topologa, una descripcin del patrn de datos y control de interacciones entre componentes, y una descripcin informal de los beneficios y perjuicios que tiene. Un estilo puede ser considerado como un conjunto de restricciones sobre una arquitectura, restricciones sobre los tipos de componentes y sus interacciones, y como esas restricciones definen una familia de arquitecturas que las satisfacen. Al descubrir estilos arquitectnicos en la arquitectura, los evaluadores pueden ver que estrategias utiliz el arquitecto para responder a las metas establecidas por los atributos de calidad del sistema. 4.2.5 Paso 5: Generar el rbol de utilidad de los atributos de calidad En este paso el equipo de evaluacin trabaja junto con los decision 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. La salida de la generacin del rbol de utilidad es una lista priorizada de los requerimientos de los atributos de calidad, comprendidos como escenarios. Le dice al equipo de evaluacin donde gastar su tiempo, y en particular donde buscar propuestas arquitectnicas y riesgos. El rbol de utilidad gua a los evaluadores a buscar propuestas arquitectnicas que estn involucradas en la satisfaccin de los escenarios de alta prioridad que se encuentran en las hojas del rbol de utilidad. Es ms, el rbol de utilidad sirve para hacer que los requerimientos de los atributos de calidad sean concretos, forzando al arquitecto y a los clientes representativos a que definan en forma precisa los requerimientos de calidad relevantes. El rbol de utilidad provee un mecanismo que en forma directa y eficiente traduce las pautas del negocio del sistema en escenarios concretos de los atributos de calidad. Los participantes priorizan al rbol de utilidad en dos dimensiones:
1. 2.
Por la importancia que cada escenario tiene para el xito del sistema. Por el grado de dificultad que posee el escenario para ser realizado, segn la estimacin del arquitecto.
Habitualmente la escala utilizada para ambas dimensiones es High, Medium, Low.
Gestin de
Ejemplo de rbol de utilidad.
4.2.5.1 Escenarios Tpicamente el primer trabajo que se hace en una evaluacin es precisamente obtener las metas de calidad especficas contra las cuales la arquitectura ser juzgada. El mecanismo que usa para esta obtencin es el de escenario. Un escenario es una corta descripcin de una interaccin de un stakeholder con el sistema. Por ejemplo, un usuario describe como utiliza el sistema para realizar una tarea, sus escenarios sern muy parecidos a los casos de uso. Un escenario de un desarrollador se centrar en usar la arquitectura para construir el sistema o predecir su performance. Los escenarios proveen un vehculo para tomar las cualidades de tiempo de desarrollo vagas, como ser modifiability, y transformarlas en algo concreto: ejemplos especficos sobre el uso actual y futuro del sistema. Los escenarios tambin son tiles para entender las cualidades de tiempo de ejecucin como performance o availability. Estructura de los escenarios: Los escenarios cuentan una pequea historia sobre una interaccin con el sistema desde el punto de vista de un stakeholder. Se le pide a los stakeholders en un ejercicio de evaluacin que escriban escenarios utilizando el formato tripartito. Las tres partes son estmulo, entorno y respuesta. El estmulo es la parte del escenario que explica o describe lo que hace un stakeholder para iniciar una interaccin con el sistema, por ejemplo invocar una funcin. El entorno describe que esta pasando al tiempo del estmulo. Por ejemplo, cul es el estado del sistema?, cules son las condiciones inusuales? Cualquier condicin del Pgina 21 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin
Evaluacin de Arquitecturas de Software Gestin de Software entorno que es relevante para entender el escenario debera ser descrita. Por convencin, si el entorno es en condiciones normales, entonces se omite. La respuesta dice como el sistema, a travs de la arquitectura, debera responder al estmulo. Por ejemplo, es la funcin llevada a cabo? La respuesta es a menudo la clave para entender en que atributo de calidad esta interesado el stakeholder que propuso el escenario. Si la respuesta a un estmulo de una funcin invocada por un usuario es simplemente que la funcin suceda, entonces el stakeholder probablemente esta interesado en la funcionalidad del sistema. Si el stakeholder le agrega sin error o en dos segundos al final, esto indica que esta interesado en reliability y performance, respectivamente. Notando cual es el atributo de calidad de inters, el lder de la evaluacin le pude pedir al stakeholder que clarifique o refine el escenario si es necesario. Tipos de escenarios: En el ATAM hay tres tipos de escenarios: escenarios de caso de uso (tpicamente usos del sistema existente), escenarios de crecimiento (cambios anticipados al sistema), y escenarios exploratorios (cambios extremos que se espera que estresen el sistema). Estos diferentes tipos de escenarios son utilizados para probar el sistema desde diferentes ngulos, optimizando las oportunidades de que aparezcan riesgos en las decisiones arquitectnicas. Escenarios de Caso de Uso: Los escenarios de caso de uso describen una interaccin completa del usuario con el sistema corriendo. Por ejemplo, un usuario solicita un informe a una base de datos va Web durante un perodo pico y lo recibe en cinco segundos (performance). Notar que los escenarios de caso de uso expresan deseos especficos de los stakeholders. Escenarios de Crecimiento: Los escenarios de crecimiento representan cambios tpicos anticipados a un sistema. Cada escenario tambin tiene ramificaciones por atributos relacionados. Por ejemplo, el escenario migrar a un sistema operativo de la misma familia, o a una nueva versin del sistema operativo existente con menos de un ao-persona de trabajo, tiene implicaciones de performance, security y reliability. Escenarios exploratorios: Los escenarios exploratorios estresan el sistema. El objetivo de estos escenarios es exponer las condiciones lmite del diseo actual, exponiendo posibles suposiciones implcitas. Los sistemas son raramente concebidos o diseados para manejar esta clase de modificaciones, pero en el futuro estos podran cambiar a requerimientos reales, entonces a los stakeholders les podra gustar entender las ramificaciones de dichos cambios. Por ejemplo, cambiar la plataforma Unix subyacente a Macintosh. Cada tipo de escenario (de caso de uso, de crecimiento y exploratorio) ayuda esclarecer los diferentes aspectos de la arquitectura, y juntos proveen una estrategia de evaluacin de tres puntas. Los escenarios son un excelente vehculo con el cual todos los stakeholders comunican sus intereses arquitectnicos. 4.2.6 Paso 6: Analizar las propuestas arquitectnicas En este momento, hay un conjunto priorizado de requerimientos de calidad concretos (del paso 5) y un conjunto de propuestas arquitectnicas utilizados en la arquitectura (del paso 4). Este paso mide cuan adecuados son el uno para el otro. Aqu, el equipo Pgina 22 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin
Evaluacin de Arquitecturas de Software Gestin de Software 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 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. Las salidas de este paso incluyen: Las propuestas arquitectnicas o decisiones relevantes para cada escenario de alta prioridad del rbol de utilidad. Las preguntas de anlisis asociadas con cada propuesta, quedando los atributos de calidad equipados con los escenarios asociados. Las respuestas del arquitecto a las preguntas. Los riesgos, no riesgos, sensitivity points y tradeoff points identificados. Cada uno de estos esta asociado con el logro de uno o ms refinamientos de los atributos de calidad en el rbol de utilidad.
En efecto, el rbol de utilidad le dice al equipo de evaluacin donde probar la arquitectura, el arquitecto responde con la propuesta arquitectnica que satisface esta necesidad, y el equipo puede utilizar las preguntas sobre un atributo de calidad especfico para probar la propuesta en mayor profundidad. Las preguntas ayudan al equipo a: Entender la propuesta en detalle y como fue aplicada en esta instancia. Buscar las debilidades conocidas de la propuesta. Buscar los sensitivity points y los tradeoff points de la propuesta. Encontrar interacciones y concesiones mutuas (tradeoffs) con otras propuestas.
Al final, cada una de estas puede proveer el material bsico para describir un riesgo, y registrarlo en una lista de riesgos que siempre crece. Las preguntas de anlisis no son un fin en s mismas. Cada una es disparador de discusiones que determinarn un posible riesgo, no riesgo, sensitivity point o tradeoff point. El anlisis no esta pensado para ser comprensivo y detallado. La clave esta en obtener la suficiente informacin arquitectnica para establecer un vnculo entre las decisiones arquitectnicas que han sido tomadas y los requerimientos de los atributos de calidad que necesitan ser satisfechos. Todos los sensitivity points y tradeoff points son candidatos a riesgos. Al final del ATAM cada sensitivity point y tradeoff point debe ser catalogado como un riesgo o no riesgo. Los riesgos, no riesgos, sensitivity points y tradeoff points deben ser recolectados e indexados, en listas separadas. Al final de este paso, el equipo de evaluacin debera tener una idea clara de los aspectos ms importantes de toda la arquitectura, la base lgica para las decisiones de diseo claves que han sido tomadas, y una lista de riesgos, no riesgos, sensitivity points y tradeoff points.
Evaluacin de Arquitecturas de Software Software 4.2.6.1 Ejemplos de caracterizacin de atributos de calidad
Gestin de
Caracterizacin de la Performance Estmulo.
Caracterizacin de la Performace Decisiones Arquitectnicas.
Gestin de
Caracterizacin de la Performace Respuestas.
Ejemplos de preguntas de Performance.
Gestin de
Caracterizacin de la Availability.
Ejemplos de preguntas de Availability.
Gestin de
Caracterizacin de la Modifiability.
Ejemplos de preguntas de Modifiability.
Gestin de
Plantilla para analizar una propuesta arquitectnica.
Gestin de
Ejemplo de un anlisis de una propuesta arquitectnica.
4.2.7 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: Representar los intereses de los stakeholders. Entender los requerimientos de un atributo de calidad.
Mientras que la generacin del rbol de utilidad es primordial para entender como el arquitecto percibe y maneja las guas arquitectnicas de los atributos de calidad, el propsito de la lluvia de ideas de escenarios es tomarle el pulso a una gran comunidad de stakeholders. La lista priorizada de los escenarios de la lluvia de ideas es comparada con los generados por el rbol de utilidad. Si se descubren nuevos escenarios guas, estos tambin son una salida importante. En este paso, el equipo de evaluacin le pide a los stakeholders que piensen en los tres tipos de escenarios mencionados: Pgina 29 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin
Evaluacin de Arquitecturas de Software Gestin de Software 1. Los escenarios de caso de uso representan la manera en la cual los stakeholders esperan que el sistema sea utilizado. En los escenarios de caso de uso los stakeholders son usuarios finales.
2.
Los escenarios de crecimiento representan la manera en la cual se espera que una arquitectura se adapte al crecimiento y al cambio en un tiempo cercano: modificaciones esperadas, cambios en la performance o availability, entre otros. Los escenarios de exploracin representan formas extremas de crecimiento, maneras en las cuales la arquitectura podra ser estresada por los cambios, por ejemplo, cambios dramticos en la performance. Mientras que los escenarios de crecimiento muestran las fortalezas y debilidades de la arquitectura con respecto a fuerzas anticipadas en el sistema, los escenarios de exploracin intentan encontrar ms sensitivity points y tradeoff points que aparecen en los puntos de estrs de la arquitectura. La identificacin de estos puntos ayuda a evaluar los lmites de la arquitectura del sistema.
3.
Una vez que los escenarios han sido recogidos, deben ser priorizados. Primero, se le pide a los stakeholders que unan los escenarios que consideren iguales. Luego, los stakeholders votan por los escenarios que crean ms importantes. En este punto de la evaluacin, hacemos una pausa y comparamos el resultado de la priorizacin de los escenarios con el resultado del rbol de utilidad del paso 5, y se buscan acuerdos o desacuerdos. Cada escenario de alta prioridad de la lluvia de ideas es, en forma consensuada, ubicado en la hoja apropiada del rbol de utilidad. Cuando un escenario de la lluvia de ideas es ubicado en el rbol de utilidad, una de estas tres cosas pasar:
1.
El escenario coincidir o prcticamente ser un duplicado de uno ya existente en alguna hoja. El escenario ir en una nueva hoja de una bifurcacin existente. El escenario no encajar en bifurcacin alguna del rbol porque expresa un atributo de calidad que no fue considerado previamente.
2. 3.
El primer y segundo caso indican que la gran comunidad de stakeholders estuvo pensando en la misma lnea que el arquitecto. El tercer caso, sin embargo, sugiere que el arquitecto pudo haber fallado en considerar un importante atributo de calidad, y subsecuentemente probar aqu podra producir fallas al documento. La generacin del rbol de utilidad y la lluvia de ideas de escenarios reflejan las metas de los atributos de calidad, pero por caminos de obtencin diferentes y desde el punto de vista de los diferentes grupos de stakeholders. Despus de este paso, el rbol de utilidad contina siendo el repositorio de todos los requerimientos de alta prioridad de los atributos de calidad
Gestin de
Ejemplo de escenarios con ranking.
Escenarios con alto rango, con anotaciones de los atributos de calidad.
rbol de utilidad versus lluvia de ideas.
Evaluacin de Arquitecturas de Software Software 4.2.7.1 Stakeholders
Gestin de
Gestin de
Gestin de
Stakeholders de la evaluacin de la arquitectura.
4.2.8 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. En este paso el equipo de evaluacin realiza las mismas actividades que en el paso 6, mapeando los escenarios recientemente generados con ranking ms alto en los artefactos arquitectnicos. Como este es un paso de prueba, se espera que poca informacin sea descubierta. 4.2.9 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: El documento de propuestas arquitectnicas. El conjunto de escenarios priorizados. El conjunto de preguntas basadas en los atributos. El rbol de utilidad. Los riesgos descubiertos. Los no riesgos documentados. Los sensitivity points y tradeoff points encontrados.
Todas estas salidas son descubiertas, capturadas y catalogadas durante la evaluacin. Pero en este paso, el equipo de evaluacin produce una salida adicional: temas de riesgo. Los riesgos pueden ser agrupados basados en algunas preocupaciones subyacentes comunes o deficiencias sistemticas. Por cada tema de riesgo, el equipo de evaluacin identifica cuales pautas del negocio, listadas en paso 2, son afectadas. Identificar temas de riesgo y relacionarlos con pautas especficas produce dos efectos. Primero, cierra el crculo de la evaluacin relacionando los resultados finales con la presentacin inicial. Segundo, eleva los riesgos que se descubrieron a la atencin de la direccin del proyecto. Pgina 34 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin
Gestin de
Como el equipo de evaluacin esta sistemticamente trabajando en intentar de entender las propuestas arquitectnicas, es inevitable que, a veces, haga recomendaciones de como la arquitectura podra haber sido diseada, o analizada diferente. Estas estrategias de mitigacin podran estar relacionadas con el proceso, podran ser directivas, o podran ser tcnicas. Sin embargo, no es una parte integral del ATAM ofrecer estrategias de mitigacin. El objetivo del ATAM es localizar los riesgos de la arquitectura. 4.2.9.1 Sensitivities, riesgos y no riesgos El ATAM confa fuertemente en la identificacin de los sensitivity points y los riesgos de la arquitectura. Confa en que los sensitivity points no solo descubrirn potenciales problemas (riesgos), sino tambin fortalezas de la arquitectura. Un aspecto del mtodo es que no solo encuentra riesgos, sino que tambin encuentra no riesgos. Recordar que los no riesgos, como los riegos, estn relacionados con las respuestas arquitectnicas provenientes de las decisiones arquitectnicas. Pero con los no riesgos se puede decir que las decisiones arquitectnicas son apropiadas, es decir, el diseo de la arquitectura satisface los requerimientos de los atributos calidad. Interesa registrar esta informacin, como se registra informacin sobre los riesgos, porque si esta decisin arquitectnica alguna vez cambia, es necesario examinar si el no riesgo se transforma en un riesgo. Como es sabido, un sensitivity point es una propiedad de uno o ms componentes (y/o relaciones entre componentes) que son crticos para lograr una respuesta de un atributo de calidad particular. ATAM, sugiere que cada sensitivity point sea clasificado como riesgo o no riesgo, dependiendo si la respuesta deseada es lograda o no.
4.3 Las fases del ATAM

En esta seccin describiremos como los pasos del ATAM se distribuyen en el tiempo. El ATAM esta compuesto por cuatro fases, que corresponden a los intervalos de tiempo de mayor actividad. La fase 0 es de preparacin, en la cual el equipo de evaluacin es creado y se forma una sociedad entre la organizacin evaluadora y la organizacin cuya arquitectura ser evaluada. Las fases 1 y 2, las fases de evaluacin del ATAM, comprenden los nueve pasos vistos hasta ahora. La fase 1 esta centrada en la arquitectura, y se concentra en obtener y analizar la informacin arquitectnica. La fase 2 esta centrada en los stakeholders, y se concentra en obtener los puntos de vista de los de los stakeholders y verificar los resultados de la fase 1. En la fase 3 se realiza el reporte final, y se continua con las acciones (si hay) planeadas, y la organizacin evaluadora actualiza sus archivos e incorpora la experiencia adquirida.
Gestin de
Tabla de pasos y salidas del ATAM.
4.3.1 Fase 0 En las fases 1 y 2 del ATAM es donde se realiza el anlisis y por eso son consideradas el corazn del mtodo. Pero antes que la fase 1 pueda comenzar, se debe establecer una sociedad entre el responsable de la evaluacin y la organizacin que la lleva adelante. Los propsitos de la fase 0 son establecer acuerdos sobre tiempo, fechas, costos, y disposicin al trabajo, y formar el equipo de evaluacin. Pgina 36 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin
Gestin de
En la fase 0 se realiza todo el trabajo base para que la evaluacin arquitectnica pueda comenzar, y asegurar su xito. La fase 0 consiste de dos partes: establecer una sociedad con el cliente y la preparacin para las siguientes fases. 4.3.1.1 Sociedad La fase 0 involucra comunicarse con las personas que solicitan la evaluacin, los clientes. El cliente debe ser alguien que pueda ejercer control sobre el proyecto cuya arquitectura es objeto de evaluacin, por ejemplo, el cliente podra ser el director del proyecto. Se asume que el cliente tiene suficiente influencia para lograr que el desarrollo se tome una pausa, para que la arquitectura pueda ser evaluada. Y tambin, se asume que el cliente tiene acceso a una amplia seleccin de stakeholders para la arquitectura. Los siguientes problemas deben ser resueltos antes de que el cliente de el visto bueno para que la evaluacin comience:
1.
El cliente debera tener un conocimiento bsico del mtodo y del proceso que se sigue. Esto se puede realizar mediante una charla informativa o una descripcin escrita del mtodo. El cliente debera describir el sistema y la arquitectura que es evaluada. Esto permite al lder de la evaluacin decidir si hay, o no, suficiente material para que una evaluacin basada en ATAM sea til. En este punto, el lder de la evaluacin debe decidir si se continua, o no, con la evaluacin. En caso de continuar, se debera negociar y firmar un contrato de trabajo. Esto asegura a ambos involucrados que los siguientes puntos estn entendidos:

2.
3.
Quien es responsable de proveer los recursos necesarios para la evaluacin. A quien corresponde el informe final de la evaluacin y cuando hay que entregrselo. Cual es la disponibilidad del equipo para continuar el trabajo.
4.
Los problemas de propiedad de la informacin deberan ser resueltos.
La fase de negociacin tambin es un buen momento para conversar sobre el costo/beneficio de la evaluacin arquitectnica. 4.3.1.2 Preparacin La preparacin de la fase 0 consisten en: Formar el equipo de evaluacin. Tener una reunin inicial con el equipo de evaluacin. Hacer las preparaciones necesarias para la fase 1.
Una vez que el equipo esta armado, es necesario asignarle a cada miembro un rol en la evaluacin venidera. Es una buena idea rotar los roles entre los miembros del equipo, como forma de capacitar a todos los miembros del equipo en todos los roles.
Evaluacin de Arquitecturas de Software Gestin de Software Un rol pude ser asumido por ms de una persona, y una persona pede asumir ms de un rol. Es el lder de la evaluacin quien asigna las personas a los roles, y los roles a las personas. Algunas reglas que ayudan: El mnimo de integrantes de un equipo de evaluacin debera ser cuatro personas. Una persona puede desempear los roles de observador del proceso, controlador del tiempo e interrogador. El lder del equipo generalmente tambin es el lder de la evaluacin. El interrogador debera ser especializado en las cualidades que interesan del sistema.
Gestin de
Tabla de roles y responsabilidades del equipo de evaluacin. Despus que el equipo esta formado, se debera hacer una reunin inicial donde se intercambie todo el conocimiento sobre la evaluacin y los roles sean asignados. Preparaciones para la fase 1 incluyen tomar recaudo de una infinidad de detalles logsticos para asegurar que todos estn en el momento y lugar correcto preparados para trabajar, esto incluye, adems del equipo de evaluacin, a los representantes del proyecto. 4.3.2 Fase 1 En la fase 1, el equipo de ATAM se encuentra con una parte del equipo cuya arquitectura esta siendo evaluada, de repente por primera vez. Esta reunin tiene dos objetivos: organizar el resto de la evaluacin y recolectar informacin. Con un pequeo grupo de personas claves, la fase 1 se concentra en los pasos 1 al 6. El equipo de evaluacin presenta el ATAM, un portavoz del proyecto presenta las pautas del negocio, y el arquitecto presenta la arquitectura. El grupo cataloga las propuestas arquitectnicas y construye el rbol de utilidad. Los escenarios de alta prioridad del rbol de utilidad sern luego la base del anlisis.
Evaluacin de Arquitecturas de Software Gestin de Software Adems de realizar los seis pasos, el equipo de evaluacin tiene otros objetivos para cumplir durante la fase 1. Necesita obtener tanta informacin como sea posible para determinar: Si el resto de la evaluacin es factible y debera continuar. Si no, la fase 1 es un buen lugar para cortar. Si se necesita ms documentacin de la arquitectura, y de ser as, determinar que tipo de documentacin y como debera ser presentada. Cuales stakeholders deberan estar presentes en la fase 2. Al final de la fase 1 el responsable de la evaluacin se debe asegurar que los stakeholders adecuados sean convocados a la fase 2.
Hay un intervalo entre las fases 1 y 2 en donde el equipo de arquitectos contina con el anlisis, en colaboracin con el equipo de evaluacin. En esta fase el equipo de evaluacin no construye modelos analticos detallados, pero construye modelos rudimentarios que le darn ideas a los evaluadores y al arquitecto sobre la arquitectura, para hacer que la reunin de la fase 2 sea productiva. Adems, en este intervalo el equipo de evaluacin toma su forma final, de acuerdo a las necesidades de la evaluacin. Por ejemplo, si el sistema es centrado en la base de datos, un experto en diseo de base de datos podra ser reclutado para el equipo. 4.3.3 Fase 2 A esta altura, el equipo de evaluacin habr entendido con suficiente detalle la arquitectura como para verificar el anlisis ya realizado, y llevar acabo el anlisis necesario restante. Los stakeholders apropiados fueron identificados, y se les dio material de lectura avanzado, como por ejemplo una descripcin del ATAM y documentacin del sistema. Ahora, los stakeholders son reunidos para la fase 2, que puede involucrar tres a cuarenta stakeholders (lo recomendado es no ms de 15). Como habr un mayor nmero de stakeholders asistiendo a la fase 2 y como las reuniones entre la fase 1 y la fase 2 estn separadas por das o semanas, la fase 2 comienza con una repeticin del paso 1. Luego, se hace una recapitulacin de los pasos 2 al 6 de la fase 1. La evaluacin contina ejecutando los pasos 7, 8 y 9.
Gestin de
Tabla con los pasos del ATAM asociados a los grupos de stakeholders.
Evaluacin de Arquitecturas de Software Gestin de Software A continuacin se presenta una posible agenda para las fases 1 y 2. Es un ejemplo de como planificar las actividades a realizar, no pretende ser seguido en forma estricta.
Ejemplo de agenda para las fases 1 y 2 del ATAM. Pgina 42 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin
Evaluacin de Arquitecturas de Software Software 4.3.4 Fase 3
Gestin de
Al trmino del ATAM, el informe final debe ser escrito y entregado. Pero tambin es importante mantener la capacidad del ATAM actualizando los repositorios de artefactos, encuestas y medidas de esfuerzo tomadas, y los cuestionarios realizados al equipo de evaluacin para encontrar formas de mejorar el mtodo. En la fase 3, las siguientes tareas deben ser cumplidas:
1. 2. 3.
Realizar el informe final. Recoger informacin para la medida y mejora del proceso. Actualizar los repositorios de artefactos.
4.3.4.1 Realizar el informe final El informe final se realiza en la fase 3. Producir el informe final significa catalogar: a) qu se hizo?, b) qu se encontr?, c) qu se concluy?. Al asignar la responsabilidad a miembros del equipo de secciones especficas del informe, al comienzo de la evaluacin, tiene como resultado que escribirlo se hace rpido y eficiente. 4.3.4.2 Recoger informacin para la medida y mejora del proceso Cada evaluacin provee una conveniente oportunidad para recoger informacin de manera tal de mejorar las ideas sobre costo/beneficio de efectuar evaluaciones, y tambin recoger opiniones sobre lo que anduvo bien y lo que anduvo mal. La informacin tiene dos fuentes: el equipo de evaluacin y el cliente. En ambos casos de debe recoger informacin sobre mejora y costo/beneficio. En particular, se recomienda realizar las encuestas a los clientes luego de seis meses de realizada la evaluacin, con el objetivo de medir los efectos a largo plazo. Se recomienda realizar las siguientes cinco encuestas:
1.
Una encuesta de mejora a los participantes, preguntndoles sus impresiones sobre la evaluacin realizada. Una encuesta de mejora a los miembros del equipo, preguntndoles sus impresiones sobre la evaluacin realizada. Una encuesta de costo al cliente. Una encuesta de costo al equipo de evaluacin. Una encuesta de beneficio a largo plazo al cliente.
2.
3. 4. 5.
4.3.4.3 Actualizar los repositorios de artefactos Se recomienda mantener repositorios de los artefactos utilizados y producidos durante cada evaluacin. Esto ayudar en futuras evaluaciones. Adems de registrar informacin de costo/beneficio, es conveniente guardar tambin los escenarios producidos. En el futuro sistemas similares pueden ser evaluados, entonces estos escenarios pueden servir de mucha ayuda a la hora de generar los nuevos escenarios. Es ms, a medida que los distintos escenarios se van guardando, se puede generar una checklist, para luego utilizarla en cada arquitectura a evaluar. Pgina 43 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin
Gestin de
Aparte de los escenarios, es conveniente realizar una lista de las preguntas de anlisis utilizadas, estas son las mejores herramientas del equipo de evaluacin. Tambin es importante agregar al repositorio los comentarios de los participantes. Futuros lderes de evaluaciones pueden leerlos y obtener valiosas ideas de pasadas evaluaciones. Finalmente, archivar una copia del informe final. Futuros equipos de evaluacin apreciarn tener una plantilla para hacer sus informes.
Gestin de
5 ACTIVE REVIEWS FOR INTERMEDIATE DESIGNS (ARID)

5.1 Introduccin
Las arquitecturas generalmente crecen lentamente, a travs de una serie de pasos y cada uno de estos pasos presentan complejos problemas de sub diseo. Si estos diseos intermedios se resuelven de una manera inapropiada, la arquitectura puede no ser adecuada para el proyecto. Por esto hacerle revisiones a la arquitectura en las etapas intermedia nos provee una valiosa visn de la viabilidad de la arquitectura a construir, as como tambin nos permite descubrir errores e inconsistencias. En un futuro la mayora de los proyectos van a realizar estas revisiones en sus subsistemas. Lo que se requiere en estas etapas, es una liviana evaluacin que se concentre en la conveniencia, expone el diseo a los interesados provocando inters y pueda ser llevada a cabo en la ausencia de una detallada documentacin. El mtodo ARID cumple con todas estas caractersticas y se basa en las mejores cualidades de los mtodos basados en escenarios (ATAM o SAAM) y las revisiones activas de diseos (ADRS). El mtodo ARID es conveniente para realizar la evaluacin de diseos parciales en las etapas tempranas del desarrollo.
5.2
Revisiones activas de diseos
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. Por ejemplo revisiones de diseo convencionales comienzan por repartir documentacin, juntar a los interesados en un lugar, presentar la arquitectura a analizar y empezar la discusin. Otro tipo de revisin ms estructurada usa una checklist para asegurar que el diseo cumple con ciertos estndares. Sin embargo este tipo de revisiones son susceptibles al aburrimiento del entrevistado y puede generar que las respuestas sean poco pensadas o simplemente no se responda nada. 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.
5.3
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 Pgina 45 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin
Evaluacin de Arquitecturas de Software Gestin de Software los inversionistas a travs de reuniones centrales y esto no se lograra con los trabajos individuales. 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.
5.3
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.
5.4
Mtodo de anlisis ARID
Una evaluacin ARID progresa a travs de dos fases que abarquen nueve pasos. 5.4.1 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 Preparar 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: El diseo es mostrado al lder de la evaluacin y este realizar una serie de preguntas que los revisores van a realizarle, preparando al arquitecto.
Evaluacin de Arquitecturas de Software Gestin de Software Ayuda a identificar reas donde la presentacin puede ser mejorada. Ayuda a tomar el tiempo de la presentacin. Ayuda al arquitecto a practicar la presentacin que luego dar a una audiencia ms crtica. Preparar los escenarios , el arquitecto y el lder prepara los escenarios que sirven para ilustrar los conceptos a los revisadotes. Preparar los materiales, copias de la presentaciones, escenarios, se realiza la agenda invitando a interesados externos y asegurando la presencia de los revisores.
5.4.2 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. Lluvia de ideas y priorizacion 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 le 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.
Conclusiones, finalmente, el lder recolecta los ejercicios y pregunta a los revisores una opinin sobre la eficacia de la evaluacin y se agradece por su participacin.
Gestin de
6 CONCLUSIONES
El ATAM fue diseado para obtener los requerimientos de los atributos de calidad que son importantes para lograr las metas del negocio. La expresin concreta de esas metas son los escenarios de los atributos de calidad que aparecen en las hojas del rbol de utilidad. El ATAM tambin fue diseado para obtener las propuestas arquitectnicas utilizadas para alcanzar las metas de los atributos de calidad. Los escenarios y las propuestas se unen cuando se pregunta como los escenarios ms importantes son soportados por la arquitectura. El resultado es un conjunto de decisiones arquitectnicas. Si estas decisiones son potencialmente problemticas o especialmente importantes, o si afectan a ms de un atributo, entonces son registradas como riesgos, sensitivity points y/o tradeoff points. Los riesgos son agrupados en temas de riesgo, los cuales son examinados de acuerdo a su impacto en lograr las pautas del negocio. Por lo tanto, el ATAM expone los riesgos arquitectnicos que potencialmente prohben a una organizacin conquistar las metas del negocio. Las propiedades del ATAM que realzan su habilidad para encontrar riesgos arquitectnicos significativos son las siguientes:
1.
Alcance auto contenido de las pautas del negocio. El ATAM se centra en la evaluacin de aquellos aspectos de la arquitectura que tengan un impacto significativo en lograr las metas del negocio. Auto escalado basado en el nmero de escenarios analizados . El ATAM puede llevarse a cabo tanto en un perodo corto como extenso de tiempo. LA diferencia estar en el nmero de escenarios que sern analizados. Involucramiento de todos los stakeholders. El ATAM esta diseado para obtener informacin de todos los stakeholders relevantes, y explotar sus talentos y perspectivas. El ATAM insta al equipo de evaluacin a mejorar el proceso en base a la experiencia .
2.
3.
4.
En resumen, el ATAM apunta a los requerimientos de los atributos de calidad esenciales utilizando las pautas del negocio como clave para el criterio de priorizacin. Al mismo tiempo, se concentra en las decisiones arquitectnicas principales explotando la experiencia del equipo de evaluacin y el arquitecto. Finalmente, el ATAM ofrece un entendimiento de las decisiones arquitectnicas ms importantes de las ramificaciones del negocio.
Gestin de
6.
REFERENCIAS
Evaluating Software Architectures: Methods and Case Studies; Paul Clements, Rick Kazman y Mark Klein; Marzo 2004; ISBN 0-201-70482-X.

Evaluacion de Arquitecturas

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Evaluacion de Arquitecturas

Uploaded by

Copyright:

Available Formats

Facultad de Ingeniera Gestin De Software

Evaluacin de Arquitecturas de Software

Evaluacin de Arquitecturas de Software Software

Pgina 1 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

Evaluacin de Arquitecturas de Software Software

Pgina 2 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

Evaluacin de Arquitecturas de Software Software

2 EVALUANDO UNA ARQUITECTURA DE SOFTWARE

Pgina 3 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

Evaluacin de Arquitecturas de Software Software

2.2 Por qu evaluar una Arquitectura?

Evaluacin de Arquitecturas de Software Software

Realizar una evaluacin de la arquitectura es la manera ms econmica de evitar desastres.

2.3 Cundo una Arquitectura puede ser evaluada?

2.4 Quines estn involucrados?

Pgina 5 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

2.5 Qu resultado produce la evaluacin de una Arquitectura?

2.6 Por qu cualidades puede ser evaluada una Arquitectura?

Pgina 6 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

Pgina 7 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

2.8 Cules son las salidas de una evaluacin arquitectnica?

Pgina 8 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

Pgina 9 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

Evaluacin de Arquitecturas de Software Software

3 SOFTWARE ARCHITECTURE ANALYSIS METHOD (SAAM)

3.3 Contexto y escenarios de SAAM.

Pgina 10 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

3.3.1 Determinando el nivel de detalle arquitectnica, mediante escenarios.

11, 12, 13 main

3.4 Roles en SAAM

3.5 Mtodo de anlisis de SAAM

3.5.2 Paso 2. Descripcin de la Arquitectura

Pgina 13 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

3.6 Esfuerzo estimado en la aplicacin de SAAM

3.7 Fortalezas y debilidades

Evaluacin de Arquitecturas de Software Software

Pgina 15 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

Evaluacin de Arquitecturas de Software Software

4 ATAM ARCHITECTURE TRADEOFF ANALYSIS METHOD

4.1 Resumen de los pasos del ATAM

4.1.2 Investigacin y anlisis

Pgina 16 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

4.2 Descripcin en detalle de los pasos del ATAM

Pgina 17 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

Plantilla de ejemplo para presentacin del negocio.

Pgina 18 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

Plantilla de ejemplo para presentacin de la arquitectura.

Pgina 19 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

Habitualmente la escala utilizada para ambas dimensiones es High, Medium, Low.

Pgina 20 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

Evaluacin de Arquitecturas de Software Software

Ejemplo de rbol de utilidad.

Pgina 23 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

Evaluacin de Arquitecturas de Software Software 4.2.6.1 Ejemplos de caracterizacin de atributos de calidad

Caracterizacin de la Performance Estmulo.

Caracterizacin de la Performace Decisiones Arquitectnicas.

Pgina 24 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

Evaluacin de Arquitecturas de Software Software

Caracterizacin de la Performace Respuestas.

Ejemplos de preguntas de Performance.

Pgina 25 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin

Evaluacin de Arquitecturas de Software Software

Ejemplos de preguntas de Availability.

Pgina 26 de 49 Universidad de la Repblica Facultad de Ingeniera Instituto de Computacin