Quality Attribute Scenarios

Para qué sirve un escenario

Un Quality Attribute Scenario convierte una preocupación en una conversación evaluable sobre estímulo, contexto y respuesta. Ayuda a comparar decisiones arquitectónicas y a identificar evidencia pendiente. «La aplicación será modificable» no muestra qué cambio importa; un escenario situado permite discutirlo.

El modelo de seis partes de Software Architecture in Practice, capítulo 4 organiza Source, Stimulus, Artifact, Environment, Response y Response Measure. Es una herramienta de razonamiento, no una sintaxis obligatoria ni una extensión de metadata del Atlas.

quality-attributes-overview ofrece el contexto. El escenario no necesita resolver la arquitectura antes de describir la necesidad: puede preguntar cómo debe responder una capacidad sin prescribir un broker, un framework o un patrón.

Anatomía del modelo

Parte	Pregunta central
Source	¿Quién o qué genera el estímulo?
Stimulus	¿Qué evento o condición ocurre?
Artifact	¿Qué parte del sistema queda afectada?
Environment	¿Bajo qué condiciones sucede?
Response	¿Qué respuesta debe producirse?
Response Measure	¿Cómo evaluamos si esa respuesta resulta aceptable?

Source → Stimulus → Artifact
                       + Environment
                             ↓
                         Response
                             ↓
                      Response Measure

Source puede ser un usuario, un sistema externo, un desarrollador, un operador, un atacante o un componente que falla. Identificarlo puede importar para carga, confianza y autoridad. Un cambio pedido por producto y una modificación automática de una dependencia tienen contextos diferentes.

Stimulus puede ser llegada de solicitudes, crecimiento de workload, inicio de deployment, fallo de una instancia o petición de cambio. No debe confundirse con la solución: «instalar una cache» propone una decisión, mientras «aumentan búsquedas repetidas» describe una condición a analizar.

Artifact es el sistema, servicio, módulo, API, almacenamiento o pipeline relevante. Aquí no significa necesariamente un documento o archivo. Su alcance delimita qué observamos y evita atribuir al sistema completo una medida tomada solo dentro de un componente.

Environment incluye operación normal, carga pico, degradación, deployment, mantenimiento o fallo. Una misma solicitud puede recibir respuestas aceptables diferentes según el modo. Una medida sin entorno permite comparaciones engañosas entre pruebas cómodas y condiciones reales.

Response describe comportamiento esperado: procesar, rechazar trabajo, aislar un fallo, recuperar, notificar, desplegar un cambio o preservar evidencia. Puede corresponder al software o al trabajo de sus desarrolladores y operadores. El modelo no se limita a eventos de runtime.

Response Measure es el punto de contraste

Response Measure permite decidir qué observación respaldaría satisfacción. Puede incluir latencia p95, tiempo de recuperación, esfuerzo de ingeniería, alcance de una modificación o continuidad de una capacidad ante un fallo definido.

Una medida necesita unidad, frontera y condiciones. «Recuperar en 60 segundos» exige acordar cuándo comienza la cuenta y qué significa recuperado. Restablecer un proceso y restablecer el servicio para sus usuarios pueden ser instantes distintos.

No toda quality cabe perfectamente en una cifra. Para un cambio, puede importar el esfuerzo y que permanezca localizado; para seguridad, puede importar impedir cierto acceso y conservar evidencia. Buscar observación reproducible no obliga a inventar un número para todo.

Los límites deben provenir de necesidades y acuerdos del contexto. Si aún se desconocen, registrar la incertidumbre y cómo se resolverá es más honesto que presentar una cifra arbitraria como requisito. Un escenario incompleto puede servir para elicitar, pero no permite todavía afirmar cumplimiento.

Ejemplo completo de runtime

El siguiente escenario de performance es ilustrativo; no representa una medición del Atlas ni un valor universal.

Parte	Escenario de búsqueda
Source	Usuarios externos.
Stimulus	Envían solicitudes de búsqueda.
Artifact	Servicio de búsqueda y su respuesta observable.
Environment	Operación normal de producción con 2.000 usuarios concurrentes y una mezcla de consultas y datos acordada.
Response	El sistema procesa y devuelve resultados correctos.
Response Measure	Al menos 95% de las solicitudes elegibles devuelve resultados dentro de 300 ms, bajo la ventana y frontera de medición acordadas.

La concurrencia no especifica por sí sola tasa de llegada ni duración de cada sesión. Antes de evaluar hay que completar esas condiciones, decidir qué solicitudes son elegibles y contabilizar errores por separado. Responder rápido con errores no satisface la intención del escenario.

estimation puede aproximar el workload para explorar viabilidad, conservando unidades, supuestos y diferencia entre medias y percentiles. trade-off-analysis utiliza escenarios relevantes para contrastar candidatos; una aproximación favorable no demuestra por sí sola que la implementación cumpla la respuesta requerida.

Medir desde el consumidor o solo dentro del servicio produce evidencias diferentes. La frontera debe corresponder a la experiencia que importa. El escenario permite descubrir esa pregunta antes de elegir optimizaciones; una prueba concreta después operacionaliza el acuerdo.

Si la carga excede ese entorno, necesitamos otro escenario para degradación o admisión. No podemos extrapolar la medida a cualquier volumen ni interpretar un rechazo deliberado como el mismo resultado que una búsqueda exitosa.

Ejemplo completo de development-time

modifiability muestra que la respuesta puede incluir trabajo de ingeniería. Este caso también es ilustrativo y deja el presupuesto de esfuerzo sujeto a acuerdo.

Parte	Escenario de integración
Source	Equipo de producto.
Stimulus	Solicita incorporar un nuevo proveedor de pagos dentro del contrato de integración previsto.
Artifact	Módulo de integración de pagos y sus consumidores.
Environment	Condiciones normales de desarrollo, con acceso al contrato del proveedor, entorno de pruebas y equipo disponible.
Response	Ingeniería implementa, prueba y despliega el proveedor preservando el comportamiento existente.
Response Measure	El cambio permanece dentro de las fronteras acordadas y su esfuerzo total no supera el presupuesto convenido.

El presupuesto debe incluir qué trabajo cuenta: análisis, implementación, pruebas, revisión y deployment. Esfuerzo de ingeniería y tiempo calendario no son iguales; una espera por aprobación externa puede aumentar uno sin aumentar proporcionalmente el otro.

«Localizado» también necesita interpretación. Puede admitir cambiar configuración y una adaptación, sin modificar consumidores del contrato común. Una inspección del cambio y pruebas de comportamiento aportan evidencia complementaria. Contar archivos sin comprender responsabilidades puede premiar concentraciones artificiales.

architectural-significance ayuda a determinar si ese escenario condiciona fronteras o decisiones relevantes. Un proveedor con garantías incompatibles podría revelar que el contrato previsto es insuficiente; no sería correcto atribuir todo el esfuerzo a una falla genérica de modificabilidad.

Los escenarios de operability, interoperability y portability amplían ese recorrido: diagnóstico e intervención de una guardia, interpretación de un contrato externo y adaptación a otra plataforma. Conservan las seis partes con medidas situadas; sus ejemplos completos permanecen en cada canonical.

cost-efficiency muestra por qué costo por resultado necesita servicio y población definidos. sustainability distingue medidas de recursos de estimaciones ambientales y sus datos pendientes. Sus escenarios completos permanecen en los canonicals; usar las seis partes no elimina incertidumbre de medición.

General y concrete scenarios

Un general scenario es independiente de un sistema concreto y orienta preguntas reutilizables. Un concrete scenario identifica el sistema y situación evaluados. El SEI utiliza esa distinción para pasar de categorías generales a requisitos situados. Reasoning About Software Quality Attributes.

«Llega una petición de cambio, se modifica el sistema y el esfuerzo queda acotado» deja variables abiertas. «Producto solicita otro proveedor para el módulo de pagos, bajo condiciones acordadas y preservando sus consumidores» concreta varias de ellas.

Concretar no significa agregar todos los detalles posibles. Hay que incluir los que discriminan alternativas y permiten observar una respuesta. Copiar un escenario general sin elegir valores o fronteras puede dar apariencia de precisión y conservar toda la ambigüedad original.

Scenario, test case, aceptación, SLO y SLA

Un escenario expresa una preocupación arquitectónica evaluable. Un test case especifica una comprobación concreta con preparación, entradas y resultado esperado. Un acceptance criterion establece una condición de aceptación para un entregable. Pueden derivarse unos de otros, sin ser sinónimos.

Un SLO fija un objetivo para un indicador de servicio; un SLA agrega un acuerdo y consecuencias asociadas. Google SRE: Service Level Objectives. Un escenario puede orientar un SLO, pero también abordar una modificación de código para la que ese instrumento operacional no resulta apropiado.

Tener una prueba verde no demuestra que cubra todo el entorno del escenario. Tampoco escribir seis campos convierte una expectativa en un compromiso contractual. Deben conservarse propósito, alcance y autoridad de cada artefacto.

Priorización, evidencia y feedback

utility-trees organiza escenarios para discutir importancia y dificultad. architectural-tactics propone decisiones candidatas; quality-attribute-trade-offs revisa efectos secundarios y evidencia.

El recorrido debe volver al escenario cuando aparecen supuestos falsos, necesidades nuevas o una frontera de medición inadecuada. Cambiar la definición solo para aprobar una solución oculta el problema; revisarla con stakeholders y razones explícitas puede mejorar el requisito.

requirements-to-architecture muestra cómo esa aclaración convierte una petición vaga en una entrada útil. design-process emplea el escenario para distinguir candidatos y decidir qué evidencia falta. Un escenario no produce una arquitectura única: varias respuestas pueden satisfacerlo con costos y obligaciones diferentes.

high-level-design necesita mostrar los compromisos relevantes para el escenario. deep-dives puede investigar una incertidumbre específica, por ejemplo si una autorización tardía permite mantener la respuesta prometida al checkout. La evidencia vuelve al escenario y a la propuesta; una demo del caso feliz no cubre automáticamente carga, fallos ni todos sus resultados requeridos.

Errores frecuentes son omitir Environment, confundir Source con quien implementa, medir únicamente casos favorables y prescribir soluciones dentro del Stimulus. quality-attributes conecta el ciclo completo. El valor del modelo es hacer discutibles esas decisiones y sus límites, conservando incertidumbre visible.