Post on 24-Jun-2015
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.