David Acevedo SalazarArquitecturas de Software ADS 010da.acevedos@profesor.duoc.cl

de ingeniera de requisitos respecto a la arquitectura. Modelado de casos de uso y escenarios de calidad. Determinacin de un perfil de calidad Tareas

Requisitos Arquitecturales

Diseo de la Arquitectura

Implementacin de la Arquitectura

Evaluacin de la Arquitectura

Identificar escenarios relevantes

Priorizar escenarios

Detallar escenarios

Documentar Arquitectura Preliminar

Escenario Funcional, Caso de Uso

Escenario No Funcional, Escenario de Calidad

Mtodo que rene a los participantes tempranamente en el ciclo de vida, durante un da, para descubrir los atributos de calidad orientadores de un sistema intensivo de software QAW se centra en el sistema y los participantes y se utiliza antes que se defina la arquitectura del sistema Fue desarrollado en CMU/SEI para complementar el Architecture Tradeoff Analysis Method (ATAM). Se trabaj inicialmente con el Servicios de Guardacostas de USA en un caso real.

Distinciones PreliminaresLos tericos de QAW distinguen entre arquitectura de sistemas y arquitectura de software: La arquitectura de un sistema es la estructura fundamental y unificadora definida en trminos de elementos, interfaces, procesos, restricciones y comportamientos del sistema [INCOSE 96] La arquitectura del software es la estructura o estructuras del sistema, que comprende elementos del software, las propiedades visibles de esos elementos y las relaciones entre ellos [Bass03]

Fundamentacin El objetivo de QAW es identificar : escenarios desde el punto de vista de los diversos participantes identificar riesgos, ejemplos: (p. ej. baja performance, denegacin de servicio) posibles estrategias de mitigacin (p. ej. replicacin, prototipado, etc) Existe poco rigor en el tratamiento de los requisitos

no funcionales en la metodologa tradicional

Fundamentacin Existen diversas tcnicas cualitativas y cuantitativas para

analizar requisitos especficos y estn surgiendo algunos estndares Barbacci 95, 96; Rushby 93, ISO 01, IEEE 90, IEEE 92 Se requiere que los objetivos de atributos de calidad sean

ms concretos. Se sugiere el uso de escenarios especficos de sistema para describir los atributos requeridos y el modo de satisfacerlos.

Terminologa Riesgos son decisiones arquitectnicas que pueden

acarrear futuros problemas para algn requisito de calidad. Puntos de sensitividad son parmetros arquitectnicos para los cuales un pequeo cambio podra acarrear consecuencias importantes en algn atributo de calidad. Tradeoffs son parmetros arquitectnicos que afectan a ms un atributo de calidad.

Son historias breves que describen una interaccin con un sistema que ejercita un atributo de calidad en particular. Por ejemplo: Est disponible un nuevo producto COTS generador de eventos discretos requerido por el sistema, y el sistema permite a los ingenieros remover el viejo generador de eventos y reemplazarlo por el nuevo en menos de dos semanas-persona

Para ser til, un escenario tiene que tener un estmulo y una respuesta El estmulo es la parte del escenario que describe un factor

o agente que ocasiona que el sistema reaccione de cierta manerax Est disponible un nuevo producto COTS generador de eventos discretos requerido por el sistema

La respuesta es la reaccin del sistema al estmulo x el sistema permite a los ingenieros remover el viejo generador de eventos y reemplazarlo por el nuevo en menos de dos semanaspersona Es importante que exista una medida de respuesta, pues

con tiempo cualquier modificacin sera posible

Estmulo, ambiente, respuesta

Escenario de caso de uso: Un usuario remoto de web requiere un reporte de base de

datos en hora pico y lo recibe dentro de los 5 segundos.

Escenario de crecimiento: Agregar un nuevo servidor de base de datos para reducir

latencia en escenario 1 a 2.5 segundos dentro de una personasemana.

Escenario exploratorio: La mitad de los servidores se bajar durante operacin normal

sin afectar la disponibilidad del sistema.

Deben

participar no menos de 5 y no ms de 30 stakeholders en cada taller Cada uno recibe al principio un manual del participante que proporciona Taxonomas, preguntas y escenarios de atributos de calidad (si es posible, adaptado al caso) Mario Barbacci, Robert Ellison, Charles Weinstock, William

Wood, Quality Attribute Workshop Participant's Handbook (CMU/SEI-2000-SR-001). [disponible]

1. Presentacin e instrucciones del QAW 2. Presentacin de Negocio/Organizacin 3. Presentacin del plan Arquitectural 4. Identificacin de los atributos controladores 5. Lluvia de ideas en escenarios 6. Consolidacin de escenarios 7. Priorizacin de escenarios 8. Refinamiento de escenarios

Los facilitadores describen la motivacin para el QAW y explican cada paso del mtodo Se recomienda el uso de una presentacin estndar tipo PowerPoint Los facilitadores se presentan a s mismos y los otros participantes hacen lo propio, describiendo su background, su papel en la organizacin y su relacin con el sistema a construir

Se distingue entre drivers de negocio (p. ej. expectativas de beneficios econmicos) y de misin (p. ej. empresa gubernamental) El participante que represente las preocupaciones primordiales de negocio/misin (tpicamente, un manager o representante del management) dedica una hora a presentar El contexto del negocio/misin del sistema Los requerimientos, restricciones (constraints) y requisitos de atributos de calidad de alto nivel Los atributos de calidad que se refinen en pasos posteriores sern los que se presenten en este paso.

Como puede que no exista una arquitectura detallada del sistema, un participante tcnico expondr las descripciones, diagramas etc existentes que describan algunos de los detalles tcnicos. La informacin incluye: Planes y estrategias para satisfacer los requisitos de

negocio/misin Requisitos y restricciones tcnicas claves (sistema operativo impuesto, hardware, middleware, estndares) que orientarn las decisiones arquitectnicas Diagramas de alto nivel

Los facilitadores irn capturando los elementos fundamentales para ulterior referencia

Antes de este paso, los facilitadores dispondrn un descanso de 15 minutos, durante los cuales ellos cotejarn y consolidarn las notas tomadas durante los pasos 2 y 3. Cuando los participantes retomen, los facilitadores compartirn su lista de drivers arquitectnicos fundamentales y solicitarn clarificaciones, agregados, eliminaciones y correcciones. La idea es alcanzar un consenso sobre una lista destilada de drivers arquitectnicos que incluirn requerimientos de alto nivel, drivers de negocios, restricciones y atributos de calidad. La lista final de drivers arquitectnicos ayudarn a los participantes durante los brainstormings de escenarios para asegurarse que esas incumbencias (concerns) estn representadas en los escenarios recolectados.

Los facilitadores inician el brainstorming durante el cual los participantes generarn escenarios. Los facilitadores sealarn las partes de un buen escenario (estmulo, ambiente y respuesta) y se asegurarn que durante el taller los escenarios queden bien formados. Cada participantes expresa un escenario representando sus preocupaciones respecto del sistema en forma circular (roundrobin) Durante un QAW nominal, se harn al menos dos pasos en redondo, para que cada participante contribuya a dos escenarios. Los faciliadores se asegurarn de que exista al menos un escenario representativo para cada driver arquitectnico listado en el paso 4.

Sugerencias Mantener los escenarios bien formados. No: El sistemaproducir reportes para los usarios. Si: Un usuario remoto requiere un reporte de base de datos via web durante horas pico y recibe el reporte dentro de los cinco segundos.

No importa cmo se llame un atributo de calidad, en tanto hayaun escenario que lo describa.

Hay que recordar que existen 3 tipos de escenarios y seasegurarn que los 3 se cubran durante el QAW:

x Escenarios de casos de uso - Involucran uso anticipado del sistema x Escenarios de crecimiento - Involucran cambios anticipados en el xsistema Escenarios exploratorios - Involucran presiones no anticipadas que pueden incluir usos y cambios

Los escenarios similares sern consolidados cuando sea posible. Para hacerlos, los facilitadores pedirn a los participantes que identifiquen los escenarios cuyos contenidos sean semejantes. Los escenarios similares se unificarn en tanto los participantes estn de acuerdo y sientan que los suyos no se diluirn en el proceso. La consolidacin es importante porque impide que se diluyan los votos durante la priorizacin (Paso 7). Si eso sucede, puede que algunos escenarios no ganen importancia y no se refinan. (Paso 8). Los facilitadores deben hacer todo lo posible para que se alcance consenso de mayora antes de unificar los escenarios. Generalmente, son pocos los escenarios que se unifican.

Se asigna a cada participante un nmero de votos igual al 30% del nmero total de escenarios generados despus de la consolidacin. El nmero real de votos asignado a los participantes se redondea a un nmero par a discrecin de los facilitadores. Por ejemplo, si se generaran 30 escenarios, cada participante tiene 30*0.3, o 9 votos, redondeados a 10. El voto se hace en redondo, en dos pases. En cada pase, los participantes alocan la mitad de sus votos. Los participantes pueden asignar cualquier cantidad de sus votos a un escenario o combinacin de escenarios

Se toman los 4 o 5 escenarios ms importantes y se los refina, considerando: 1. Estmulo - La condicin que afecta al sistema 2. Respuesta - La actividad que resulta del estmulo 3. Fuente del estmulo - La entidad que lo genera 4. Ambiente - La condicin bajo la cual el estmulo ocurre 5. Artefacto estimulado 6. Medida de respuesta - Para evaluar la respuesta del sistema

Tambin hay que describir los objetivos de negocio/misin afectados por el escenario y las cualidades relevantes asociadas con l Finalmente se evacan las dudas y preguntas de los participantes a satisfaccin.

Productos resultantes Lista de drivers arquitectnicos Los escenarios en s La lista priorizada de escenarios Los escenarios refinados

Esta informacin puede usarse para: Actualizar la visin arquitectnica de la organizacin Refinar el sistema y los requisitos del software Orientar en el desarrollo de prototipos Ejercitar simulaciones Comprender y clarificar los drivers arquitectnicos del sistema Influenciar el orden en que se desarrolla la arquitectura Describir la operacin de un sistema

Si se elige Architecture Tradeoff Analysis Method (ATAM) como mtodo de evaluacin de la arquitectura, se pueden usar los productos de QAW como escenarios originadores (seed) de esa evaluacin

La generacin de escenarios puede llevar a la creacin de diagramas de casos de uso, diagramas de contexto o sus equivalentes Los escenarios refinados se pueden documentar como diagramas de secuencia o diagramas de colaboracin. Los concerns de los participantes y toda otra informacin de justificacin se puede capturar de modo tal que se pueda incluir en el view packet apropiado o en la documentacin de overview. Otros detalles que explican cmo realizar la transicin de estos artefactos en documentacin arquitectnica estn siendo desarrollados en estos das en CMU/SEI.

Mario Barbacci, Robert Ellison, Anthony Lattanze, Judith Stafford, Charles Weinstock, William Wood. Quality Attribute Workshops (QAWs), 3rd edition, CMU/SEI 2003-TR-016 Bass, L.; Clements, P.; & Kazman R. Software Architecture in Practice, Second Edition. Boston, MA: Addison-Wesley, 2003. Mario Barbacci, Robert Ellison, Charles Weinstock, William Wood, Quality Attribute Workshop Participant's Handbook (CMU/SEI-2000-SR-001). Mario Barbacci. Software quality attributes and architecture tradeoffs. SEI/CMU Presentation. Rushby, J. Critical System Properties: Survey and Taxonomy. (CSL-93-01). Menlo Park, CA: Computer Science Laboratory, SRI International, 1993.

[IEEE 90] Institute of Electrical and Electronics Engineers. IEEE Standard Glossary of Software Engineering Terminology (IEEE Standard 610.121990). New York, NY: Institute of Electrical and Electronics Engineers, 1990. [IEEE 92] Institute of Electrical and Electronics Engineers. Standard for a Software Quality Metrics Methodology (IEEE Standard 1061-1992). New York, NY: Institute of Electrical and Electronics Engineers, 1992. [INCOSE 96] International Council on Systems Engineering (INCOSE). INCOSE Systems Architecture Working Group (Processes & Methods Technical Committee). (August 2003). [ISO 01] International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC). Software Engineering Product Quality (ISO Std 9126). Geneva, Switzerland: ISO/IEC, 2001.

Identificar

actores Identificar casos de uso Priorizar casos de uso preguntas clave para la arquitectura. Detallar casos de uso relevantes para la arquitectura: Flujo normal de eventos Flujos alternativos

> Sistema de Gestin Transantiago

ID Nombre ActoresResumen

CU1 Acceso a Servicios de Transporte :: Debitar Bus PasajeroSe inicia cuando el pasajero sube a un bus y debe cancelar su pasaje. O al hacerlo en un terminal de acceso al bus.

Curso Normal de Eventos 1. El pasajero acerca su tarjeta BIP! al validador de tarjetas del bus. 2. El sistema comprueba validez de la tarjeta 3. El sistema descuenta del saldo de la tarjeta BIP! del pasajero, el valor del pasaje, an cuando el saldo de la tarjeta quede negativo (siendo positivo previamente al pago) y da acceso al uso del bus.

Eventos alternativos 3a. Si la tarjeta es invlida, el sistema no da acceso al uso del bus o paso por el terminal de acceso. Prioridad AQ Alta

Identificar

atributos relevantes Identificar escenarios de calidad - QAW Priorizar escenarios QAW Detallar escenarios de calidad relevantes para la arquitectura:

Seguridad

en las tarjetas Tiempo de respuesta en la lectura de tarjeta Recuperacin en un fallo al momento de la recaudacin de las ventas Denegar acceso a usuarios sin los privilegios respectivos Cambio en la lgica de cobro del servicio. Crecimiento del Sistema de Transportes Transantiago

Cambiar el modelo de cobro SGT

Modelo de cobro reemplazado

1 2 3 4

Departamento de Marketing

Desarrollo/Evolucin

Tiempo < 2 semanas Esfuerzo < 3 personas/mes

Nombre: Modificabilidad::Cambio en la lgica de cobro Resumen : La organizacin desarrolladora piensa proveer la misma solucin a otras empresas municipales. Es necesario que la misma solucin, en el mismo contexto, soporte cambios en su lgica de cobro.

medible a partir de las caractersticas intrnsecas, como el cdigo fuente Externa: medible en el comportamiento del producto, como en una prueba En uso: durante la utilizacin efectiva por parte del usuario Interna:

Proceso

Producto

Efecto del producto

Influye Proceso de calidad Depende de Calidad interna

Influye Calidad externa Depende de

Influye Calidad en uso Depende de Contextos de uso

proveedor

usuario

x x x x x x x x x x x x x x x

x x

x x x x

x x

x

x x x x x x

atributo

subcaracterstica

atributos internos

caracterstica

atributos externos

Visin de la direccin Visin de usuario Facilidad de uso Seguridad (integridad) Eficiencia Correccin (exactitud) Fiabilidad

Visin del desarrolladorOperabilidad Familiarizacin Comunicatividad Volumen y tasa de E/S Datos comunes Control y audit. de acceso Integridad de datos Eficiencia de almacenam. Eficiencia de ejecucin Complecin Trazabilidad Consistencia Precisin Tolerancia a errores Simplicidad Concisin Autodescriptividad Modularidad Instrumentacin Capacidad de ampliacin Generalidad Indep. mquina Indep. soft. de sistema Comunicac. comunes

Operacin de producto

Revisin de producto

Facilidad de mantenimiento Facilidad de prueba Flexibilidad Capacidad de reutilizacin Transportabilidad Interoperabilidad

Transicin de producto

calidad externa e interna

funcionalidad

fiabilidad

usabilidad

eficiencia

mantenibilidad

portabilidad

adecuacin exactitud interoperabilidad seguridad de acceso

madurez tolerancia a fallos capacidad de recuperacin

cumplimiento de la funcionalidad

cumplimiento de la fiabilidad

capacidad para ser entendido capacidad para ser aprendido capacidad para ser operado capacidad de atraccin cumplimiento de la usabilidad

comportamiento temporal utilizacin de recursos cumplimiento de la eficiencia

capacidad para ser analizado capacidad para ser cambiado estabilidad capacidad para ser probado cumplimiento de la mantenibilidad

adaptabilidad instalabilidad coexistencia capacidad para ser reemplazado

cumplimiento de la portabilidad

calidad en uso

efectividad

productividad

seguridad de acceso

satisfaccin

Evaluacin del producto software: ISO 14598Recursos y entorno Proceso de evaluacin Producto software Efecto del producto software

Apoyo a la evaluacin

Proceso de evaluacin

Mtricas Internas

Mtricas externas

Mtricas de calidad en uso

14598-1

14598-2

14598-3 14598-4

9126-1

14598-6

14598-5

9126-3

9126-2

9126-4

Hacer efectivas decisiones de diseo Razonar predicativamente sobre los atributos del software sin hacer suposiciones errneas o sin sustentar. Evaluar cuantitativamente los atributos de calidad para lograr la mejor solucin general del sistema. Taxonoma de los atributos de calidad. Conexin entre los atributos de calidad.

Software de funcin crtica: Las aplicaciones presentan largos ciclos de vida

y requieren actualizaciones evolutivas. Las aplicaciones requieren operacin continua o cercana a una disponibilidad 100% Las aplicaciones requieren interaccin con dispositivos hardware Las aplicaciones asignan gran importancia a atributos de calidad como desempeo, confiabilidad, seguridad, interoperabilidad, etc.

Calidad de software es el grado en que un proceso software presenta una combinacin deseada [IEEE 1061] Opiniones/escuelas Desempeo de los sistemas de tiempo real Dependencia - sistemas muy confiables y tolerante a fallas Seguridad (Security) de los sistemas de gobierno, bancarias

y comunidades acadmicas. Seguridad (Safety ) del anlisis de riesgos e ingeniera de sistemas seguros.

Dependencia vs desempeo Comunicacin de replicacin (tolerancia

fallos), inversin en tiempo. Procesos crticos en paralelo para lograr desempeo entra en conflicto con dependencia pues ahora ya no se tiene un solo punto de fallo. Eficiencia

vs portabilidad, exactitud, entendibilidad y matenibilidad.

Habilidad

para evaluar cuantitativamente atributos de calidad y negociar para lograr la mejor solucin arquitectnica.

Atributo

propiedad del servicio prestado por el sistema a los usuarios. Servicio prestado comportamiento percibido por el usuario. Usuario otro sistema (fsico o humano) Evento iniciador de del servicio , es un estmulo indicando la necesidad de un servicio (externos o interno).

Atributo

Incumbencia

Factores especficos

Interno/ Externo

Causa/Efecto

Mtodos

Anlisis/ Sntesis

Procedimientos /Entrenamiento

Desarrollo/ Ejecucin

[IEEE

610.12] grado en el cual un sistema o componente cumple con las funciones designadas dentro de unas restricciones dadas, tales como velocidad, precisin o uso de memoria.

Atributo

Incumbencia

Latencia

Throuhput

Capacidad

Modos

Factores especficos

Demanda

Sistema

Mtodos

Anlisis/ Sntesis

Procedimientos /Entrenamiento

Latencia: tiempo

que se toma el sistema para responder a un evento: Throuhput: se refiere al nmero de respuestas que han sido completadas en un intervalo de observacin.

Capacidad: medida de trabajo que el sistema puede soportar. El mximo throughput posible bajo unas condiciones de carga ideales. Modos:

Fase de ejecucin en la cual el sistema

cumple diferentes requisitos de desempeo:x Capacidad reducida x Sobrecarga

Performance

= f (demanda, recursos, localizacin de los recursos) Demanda: eventos, velocidad de llegada para

cada evento, recursos asociados a cada evento. Sistema: tipos de recursos, servicios software para gestionar estos recursos, distribucin de los recursos.