Apunte de Atributos de Calidad (Ingeniería II)

La definición de una arquitectura requiere conocer tres elementos: requerimientos funcionales de negocio, atributos de calidad y restricciones del modelo.

Especificación y Elicitación

Se utiliza el método de escenarios para especificar los atributos de calidad, y el QAW para identificar los de mayor importancia a partir de los stakeholders involucrados en el proyecto.

Escenarios

La especificación de atributos de calidad se hace mediante escenarios, los cuales se componen de los siguientes elementos:

• Fuente del estímulo: Quien origina el evento que afecta al sistema
• Estímulo: Evento que arriba al sistema
• Artefacto: Parte del sistema afectada por el estímulo
• Entorno: Condiciones en las cuales ocurre el estímulo
• Respuesta: Respuesta del sistema al estímulo recibido
• Medida de la respuesta: Cuantificación de la respuesta que hace al atributo de calidad

Se pueden construir escenarios generales para cada uno de los atributos de calidad, los cuales luego se instancian apropiadamente.

Availability

Availability se refiere a los failures del sistema y sus consecuencias. La availability suele definirse como la probabilidad de que un sistema esté operacional cuando se lo necesita, y depende del tiempo de failure y de repair.

• Source: Internal to the system; external to the system.
• Stimulus: Fault: omission, crash, timing, response.
• Artifact: System's processors, communication channels, persistent storage, processes.
• Environment: Normal operation; degraded mode (i.e., fewer features, a fall back solution).
• Response: System should detect event and do one or more of the following: record it; notify appropriate parties, including the user and other systems; disable sources of events that cause fault or failure according to defined rules; be unavailable for a prespecified interval, where interval depends on criticality of system; continue to operate in normal or degraded mode.
• Measure: Time interval when the system must be available; availability time; time interval in which system can be in degraded mode; repair time.

Modifiability

Relacionado al costo del cambio. Implica determinar qué parte del sistema se modifica, y quién y cuándo es el encargado de realizar este cambio. Puede realizarse por un programador sobre los fuentes, o por un usuario sobre un archivo de config.

• Source: End user, developer, system administrator.
• Stimulus: Wishes to add/delete/modify/vary functionality, quality attribute, capacity.
• Artifact: System user interface, platform, environment; system that interoperates with target system.
• Environment: At runtime, compile time, build time, design time.
• Response: Locates places in architecture to be modified; makes modification without affecting other functionality; tests modification; deploys modification.
• Measure: Cost in terms of number of elements affected, effort, money; extent to which this affects other functions or quality attributes.

Performance

Referida a tiempos de respuesta. Puede caracterizarse mediante latency (tiempo entre la llegada de un estímulo y su respuesta), deadlines de procesamiento, throughtput (cantidad de transacciones procesables por unidad de tiempo), jitter (variaciones en latency) y cantidad de eventos o datos perdidos por sobrecarga del sistema. Estos elementos pueden medirse en promedio o en peor caso, y considerando el sistema normal o sobrecargado.

• Source: One of a number of independent sources, possibly from within system.
• Stimulus: Periodic events arrive; sporadic events arrive; stochastic events arrive.
• Artifact: System.
• Environment: Normal mode; overload mode.
• Response: Processes stimuli; changes level of service.
• Measure: Latency, deadline, throughput, jitter, miss rate, data loss.

Security

Seguridad puede caracterizarse mediante no repudiación, confidencialidad, integridad, assurance (los participantes de una transacción son quienes se suponen), availability (resistencia a denial of service), auditing.

Notar que en estos escenarios se hace evidente que la respuesta del sistema no tiene por qué ser visible al usuario. Mantener un audit trail ante una modificación a datos sensibles no es algo visible al usuario, sin embargo es una respuesta válida del sistema, sea para identificar al atacante o restaurar los valores pre ataque.

• Source: Individual or system that is correctly identified, identified incorrectly, of unknown identity, who is internal/external, authorized/not authorized, with access to limited resources, vast resources.
• Stimulus: Tries to display data, change/delete data, access system services, reduce availability to system services.
• Artifact: System services; data within system.
• Environment: Either online or offline, connected or disconnected, firewalled or open.
• Response: Authenticates user; hides identity of the user; blocks access to data and/or services; allows access to data and/or services; grants or withdraws permission to access data and/or services; records access/modifications or attempts to access/modify data/services by identity; stores data in an unreadable format; recognizes an unexplainable high demand for services, and informs a user or another system, and restricts availability of services.
• Measure: Time/effort/resources required to circumvent security measures with probability of success; probability of detecting attack; probability of identifying individual responsible for attack or access/modification of data and/or services; percentage of services still available under denial-of-services attack; restore data/services; extent to which data/services damaged and/or legitimate access denied.

Testability

Referido a la facilidad con que puede testearse para determinar sus fallas. Debe ser posible controlar el estado de cada componente y analizar sus outputs ante determinados inputs. Se utilizan test harnesses para esto.

Los estímulos están referidos a la finalización de un determinado milestone que implica la ejecución de determinados tests. El environment, entonces, puede ser al completar determinado componente. Las respuestas vinculadas a que cada componente testeable efectivamente lo es.

• Source: Unit developer, increment integrator, system verifier, client acceptance tester, system user.
• Stimulus: Analysis, architecture, design, class, subsystem integration completed; system delivered.
• Artifact: Piece of design, piece of code, complete application.
• Environment: At design time, at development time, at compile time, at deployment time.
• Response: Provides access to state values; provides computed values; prepares test environment.
• Measure: Percent executable statements executed, probability of failure if fault exists, time to perform tests, length of longest dependency chain in a test, length of time to prepare test environment.

Usability

Usabilidad se refiere a cuan sencillo le es a un usuario completar una determinada tarea y el soporte que el sistema le ofrece para esto. Puede dividirse en aprender features del sistema, usar el sistema eficientemente, minimizar el impacto de errores, adaptar el sistema a las necesidades del usuario y aumentar confianza y satisfaccion.

• Source: End user.
• Stimulus: Wants to learn system features; use system efficiently; minimize impact of errors; adapt system; feel comfortable.
• Artifact: System.
• Environment: At runtime or configure time.
• Response: System provides one or more of the following responses:
  • To support "learn system features": help system is sensitive to context; interface is familiar to user; interface is usable in an unfamiliar context.
  • To support "use system efficiently": aggregation of data and/or commands; re-use of already entered data and/or commands; support for efficient navigation within a screen; distinct views with consistent operations; comprehensive searching; multiple simultaneous activities.
  • To "minimize impact of errors": undo, cancel, recover from system failure, recognize and correct user error, retrieve forgotten password, verify system resources.
  • To "adapt system": customizability; internationalization.
  • To "feel comfortable": display system state; work at the user's pace.
• Measure: Task time, number of errors, number of problems solved, user satisfaction, gain of user knowledge, ratio of successful operations to total operations, amount of time/data lost.

Quality Attribute Workshops

Metodología que relaciona los stakeholders del sistema y sus intereses para poder elicitar de forma temprana los atributos de calidad requeridos. El proceso consta de 8 etapas e itera mientras sea necesario agregando stakeholders.

• Presentación del método, donde se describe el QAW y presentan los stakeholders.
• Presentación del negocio, donde un representante de los stakeholders presenta la motivación del sistema.
• Presentación del plan de arquitectura, donde se presenta una vista de alto nivel de la arquitectura so far.
• Identificacion de drivers de arquitectura, se busca depurar lo anterior extrayendo requerimientos, restricciones y atributos de calidad.
• Brainstorming de escenarios, en el que se buscan escenarios de caso de uso, de crecimiento y exploratorios en dos rondas.
• Consolidación de escenarios, se agrupan escenarios similares.
• Definición de prioridades, en el que cada stakeholder vota por los escenarios más importantes, en dos rondas.
• Refinamiento de escenarios, se especifican y refinan los 5 escenarios más votados y analizan los atributos de calidad elegidos.

Tácticas

Una táctica es una decisión de diseño que influencia el control de la respuesta a un evento relacionado a un atributo de calidad. Una colección de tácticas forma una estrategia arquitectónica.

Availability

Availability se inscribe dentro de Dependability, que indica el nivel de confianza que puede ser delegada sobre los servicios que presenta. Otros atributos de Dependability son:

• Reliability, continuidad de servicio en el tiempo
• Safety, no ocurrencia de situaciones catastróficas para el entorno
• Confidencialidad, no apertura de información no autorizada (security)
• Integrity, no ocurrencia de alteraciones de información no deseadas (security)
• Maintainability, aptitud para sobrellevar reparaciones (modificability). Impacta sobre dependability pues el tiempo medio de reparación es parámetro de la availability.

Es importante distinguir failure, fault y error. Un failure (falla) es cuando el sistema difiere de su comportamiento intencionado (no del especificado). Pueden darse fallas de datos o de tiempos, benignas o catastróficas, y consistentes o inconsistentes.

Un error, por su parte, es un estado del sistema que probablemente lleve a un estado de falla. Los errores pueden estar latentes o detectados. La causa del error se denomina fault (falta). Las que aún no se manifestaron como errores se denominan dormant, de lo contrario, active.

Los concerns típicos de availabilty son quality of service, downtime, recovery time, fault rate y recuperación de desastres. Es importante evitar los Single Point Of Failure en los sistemas.

Fault Detection

• Ping/echo: Un proceso externo hace ping al monitoreado para determinar su estado. Puede haber múltiples pingers en distintas capas.
• Heartbeat: El proceso monitoreado envía información de su estado (más otra información de interés, como ser logs) a otro proceso monitor.
• Exception: A diferencia de los anteriores se realiza en el mismo proceso que falló. El handler de excepciones efectúa las transformaciones necesarias para permitir que el sistema siga funcionando.

Recovery

Las tácticas de recuperación se dividen en tácticas de preparación y reparación de componentes, y de reintroducción de componentes reparados por otra parte.

Preparation and Repair

La redundancia es el mecansimo principal. La redundancia se clasifica en redundancia de información (ej checksums en una transmisión, RAID en almacenamiento), redundancia de tiempo (se realiza una misma acción más de una vez) o física (agregado de hardware extra).

• Voting: Un voter central (SPOF!) recibe las salidas de múltiples procesos redundantes y decide un resultado correcto en función de los votos. Cada proceso puede utilizar un algoritmo diferente o correr sobre una plataforma distinta.
• Active redundancy: Todos los componentes en redundancia reciben los estímulos en simultáneo y los procesan en simultáneo, se usa la respuesta de un solo componente. En caso de falla simplemente se hace un switch.
• Passive redundancy: Se tiene un componente que recibe los estímulos y es el encargado de resolverlos, otorgar la respuesta y además forwardearlos a los componentes redundantes. Al caer el primero alguno de los otros toma su lugar.
• Spare: Plataforma en standby para usar en caso de caída de alguno de los componentes. Debe ser rebooteada con el estado del componente antes de caer, para lo cual debe usarse algún mecansimo de checkpoints.

Reintroduction

La reintroducción de un componente se da una vez que este es reparado.

• Shadow: Un componente puede correrse en shadow mode hasta asegurarse que funciona correctamente antes de ponerlo efectivamente en servicio.
• State resync: El componente debe tomar el estado actual del sistema (en caso de redundancia) antes de volver a ejecución, para esto puede recibir mensajes de los componentes que se mantuvieron en ejecución para actualizarse.
• Rollback: En caso de llegar a un estado inconsistente, puede hacerse rollback a un estado conocido seguro antes de restaurar el componente.

Prevention

• Removal from service: Si se detecta que un componente puede caer en estado de falla, se lo quita de servicio antes de que genere una falla mayor.
• Transactions: Permiten restaurar estados válidos en caso de que falle algún paso en la transacción.
• Process monitor: Un monitor puede detectar fallas en procesos y generar una nueva instancia en caso de falla.
• Compensación: En casos que no sea posible concentrar el estado en un componente, debemos manejar mecanismos de undo o de compensación.

Modifiability

Habilidad del sistema para ser flexible ante cambios durante y después de su desarrollo, sea por desarrolladores, usuarios o admins, mediante código, config files, u otro artefacto.

Está caracterizado por complexity, la complejidad del sistema proporcional a la cantidad de módulos e interacciones, portability, la habilidad del sistema para ejecutar en distintas plataformas y adaptability, la capacidad del sistema para adaptarse a nuevos entornos o requerimientos.

Es importante mantener componentes y conectores cohesivos y agrupados según funcionalidad o interacción; también eliminar interdependencias innecesarias. Los conectores deben ser flexibles y permitir composición.

Localize Changes

Se busca reducir el número de módulos que se debe modificar para realizar un cambio.

• Semantic coherence: Mantener juntos a los módulos que realizan las mismas tareas semánticas para mantener los cambios a esas tareas limitadas a esos módulos.
• Anticipate expected changes: La anterior implica anticipar cambios que van a ser semánticamente coherentes, se debe analizar qué otros tipos de cambios puede haber y design for change.
• Generalize module: Al generalizar un módulo se puede modificar su tarea simplemente cambiando su input o configuración en lugar de su lógica.
• Limit possible options: Limitar opciones de cambios a cambios por componentes similares.
• Abstract common services: Ademas de promover reuso, un cambio a un servicio común puede realizarse en un solo lugar en vez de en cada módulo donde es usado.

Prevent Ripples

Ripple effect es la necesidad de realizar cambios a un módulo no afectado directamente por una modificación. Las ripples se dan por dependencias entre distintos módulos, las cuales pueden ser sintácticas, semánticas, de secuencia, de interfaz, location in runtime (ubicacion en cierto proceso), quality of service, existencia (resoluble mediante stubs) o uso re recursos.

• Information hiding: Controla dependencias sintácticas principalmente.
• Mantain existing interfaces: Permite salvar dependencias sintácticas entre dos módulos, aunque no sintácticas; algunos patterns relacionados son soportar múltiples interfaces, usar wrappers o stubs.
• Restrict communication paths: Reduce dependencias entre módulos pues intercambio de datos genera dependencias.
• Use intermediary: Distintos tipos de intermediarios según la dependencia:
  • Sintáctica de Datos: Uso de repositorios, patterns de publish/subscribe, etc.
  • Sintáctica de Servicios: Facade, bridge, adaptor, mediator, etc.
  • Localización: DNS, proxy, etc.
  • Interfaz: Broker entre los componentes que implemente la interfaz.
  • Recursos: Uso de un resource manager.
  • Existencia: Abstract factory.

Defer Binding Time

El objetivo de esta categoría de tácticas no es disminuir la cantidad de módulos impactados por un cambio sino reducir los tiempos de deployment de modificaciones y permitir la realización de cambios por nondevelopers o fuera de design time.

• Runtime registration
• Config files
• Polymorphism
• Component replacement
• Adherence to defined protocols

Performance

Performance se refiere exclusivamente a optimización de tiempos. Notar que scalability puede incluirse dentro de performance. Los concerns relacionados son:

• Response time: Incluye el turnaround (transacción individual compleja) y el responsiveness (en sistemas interactivos, nivel de respuesta individual de cada interacción e impacto sobre usability).
• Throughtput: Cantidad de requerimientos que el sistema puede atender dentro de una ventana de tiempo definida.
• Scalability: Puede considerarse un atributo separado o dentro de performance.

Las tácticas de performance se basan en que el tiempo que pasa entre un pedido y la respuesta se debe o bien a consumo de recursos por parte de ese pedido (sea CPU o IO) o bien a que se encuentre bloqueado a la espera de un recurso o del resultado de otro cálculo.

Resource Demand

Atacan la demanda de recursos en sí. Una posibilidad es reducir la cantidad de recursos que requiere cada evento.

• Increase computation efficiency: Mejorar los algoritmos reduce la latencia.
• Reduce computational overhead: Cualquier overhead agregado por clases o lógica que no se utiliza daña la performance, aunque favorece generalmente la modificabilidad.

Otro enfoque es simplemente reducir la cantidad de eventos que arriban al sistema.

• Manage event rate
• Control frequency sampling

También se puede controlar el uso de recursos.

• Bound execution times
• Bound queue sizes

Resource Management

• Introduce concurrency: Procesar los eventos concurrentemente para reducir tiempos de bloqueo.
• Mantain multiple copies: Sea de datos o de cómputos, en otras palabras, caching.
• Increase available resources: Aumentar recursos a cambio de aumentar el costo.

Resource Arbitration

La arbitración de recursos se basa en el scheduling utilizado para otorgar recursos a quienes lo soliciten, para lo cual pueden usarse distintos esquemas:

• FIFO: El primer pedido en pedir un recurso lo recibe, se tratan todos los requests por igual.
• Fixed priority: Se asigna una prioridad fija a cada pedido o stream de pedidos. Puede ser por semantic importance, o basado en la longitud de los deadlines o de los períodos.
• Dynamic priority: Puede ser round-robin o earliest deadline first.
• Static: El asignamiento de recursos se determina offline.

Security

Resisting Attacks

• Authenticate users: Solicitar algún tipo de autenticación, desde user/pass hasta biometrics.
• Authorize users: Definir los permisos para un usuario ya autenticado; los permisos pueden definirse sobre usuarios o sobre roles.
• Maintain data confidentiality: Proteger datos de ser accedidos por usuarios no autorizados, principalmente via encripción de los datos.
• Maintain integrity: La integridad puede mantenerse enviando info extra, como ser hashes o checksums.
• Limit exposure: Un ataque generalmente permite al intruso obtener toda la data del host; al limitar los servicios a distintos hosts se limita la cantidad de data expuesta ante un solo ataque exitoso.
• Limit access: Uso de firewalls y demilitarized zones para proveer servicios a hosts conocidos y desconocidos.

Detecting Attacks

Se logra agregando un sistema de detección de intrusos que analiza patterns de tráfico en la red y los compara contra el histórico. Debe tener acceso a la red, ser configurable y poder guardar los logs de patterns de tráfico.

Recovering from Attacks

Se divide en dos partes. Restoration implica volver a un estado anterior que se sabe seguro previo al ataque. Identification permite saber quién fue el autor del ataque.

Restoration

Utiliza tácticas de availability para recuperar un estado válido. Puede ser mediante checkpoints, redundancia, etc.

Identification

Requiere el uso de un audit trail para guardar quién fue el usuario que realizó cada transacción. Permite, además de seguir a un atacante, la no repudiación y ayuda a la recuperación del sistema junto a las tácticas de availability.

Testability

Las tácticas de testability se basan en poder detectar faltas tras haber completado un determinado incremento del producto.

Managing IO

El objetivo de esta categoría es controlar la entrada y la salida de un artefacto a fin de poder testearlo adecuadamente con un harness.

• Record/playback: Capturar entrada para poder reproducirla y compararla contra la salida en un test harness.
• Separate interface from implementation: Permite stubbing y mocking.
• Specialize access routes/interfaces: Mantener interfaces especializadas para testing, como ser interfaces que provean metadata acerca del procesamiento.

Internal Monitoring

• Built-in monitors: Monitores del estado interno de un determinado componente que registran información que puede accederse a través de una interfaz especializada.

Usability

Usabilidad se basa en la confianza y facilidad de uso de un usuario con respecto al sistema.

Concerns

• Interfaz de usuarios
• Proceso de negocio
• Calidad de información
• Alinear la capacidad del usuario con la interfaz
• Crecimiento de la productividad con el aprendizaje de uso.

Tácticas

Las tácticas pueden separarse entre runtime y design time, según el momento en que sean aplicadas, y están orientadas hacia fines distintos. Las tácticas de runtime se dividen según quién toma la iniciativa en la interacción: el usuario o el sistema.

• Separate User Interface: Separar la interfaz de usuario del resto del sistema permite al ingeniero de usabilidad realizar las modificaciones necesarias sin impactar en la funcionalidad en sí. Para esto se usan patrones como MVC. Es de design time.
• Support User Initiative: El sistema debe presentar al usuario las opciones que desee, como ser Cancel, Undo o Aggregate.
• Support System Initiative: Para que el sistema tome la iniciativa, este debe mantener distintos modelos para poder presentar al usuario la información que corresponda. Un User model para saber qué tipo de respuesta éste espera; un System model con la información que se le presenta al usuario del estado del sistema; y un Task model con el contexto de la tarea para acotar al usuario las opciones posibles que posee.