Medibles y No Medibles Medibles Pueden ser medidos mientras que el sistema ejecuta Devuelve la respuesta correcta? Es fácil de usar? Cuánto tarda en ejecutar un transacción? Un usuario no autorizado puede vulnerar la seguridad? Con qué frecuencia se cae o deja de funcionar? No Medibles No pueden ser medidos mientas el sistema ejecuta, sino antes o después Cuánto esfuerzo requiere su construcción? Cuánto esfuerzo requiere su testeo? Cuánto esfuerzo requiere su integración? Cuánto costó? Cuán fácil será de modificar? Clases de Cualidades Cualidades del Sistema Cualidades Relativas al Negocio Cualidades de la Arquitectura Aspectos relativos al funcionamiento del sistema. Pueden ser fehacientemente medibles o no. Aspectos del negocio que tienen impacto en decisiones arquitectura Cualidades de la arquitectura que suelen tener impacto en otros atributos de calidad. Disponibilidad Modificabilidad Performance Seguridad Time to market Vida útil del sistema Costo y beneficio Plan de evolución Etc. Testeabilidad Usabilidad Etc. Integridad conceptual Correctitud y completitud Buildability (factibilidad de construcción) Etc. Arquitectura y Diseño de Sistemas 12 Arquitectura y Diseño de Sistemas 13 Cualidades Relativas al Negocio Costo y Planificación Time To Market Costos y Beneficios Vida Útil Proyectada Integración con Sistemas Legados Marketing Mercado Apuntado Plan de Lanzamiento (incremental vs one-time) Organizacional Disponibilidad de equipo adecuada Experiencia en el dominio y tecnologías Cualidades de la Arquitectura Integridad Conceptual El sistema se construye a partir de un numero pequeño de estructuras arquitectónicas que interactúan en un numero pequeño de formas (predeterminadas) Se logra típicamente vía un solo arquitecto, o un grupo de arquitectos pequeño y coordinado Correctitud y Completitud Es esencial que tanto los requerimientos funcionales como las restricciones sean satisfechos por la arquitectura. Se utilizan evaluaciones formales para verificarlos (por ej, ATAM) Buildability Determina si el sistema puede ser construido con los recursos disponibles Equipo Conocimientos Herramientas / Componentes Arquitectura y Diseño de Sistemas 14 Arquitectura y Diseño de Sistemas 15 Cómo Definir Existen 3 problemas para definir atributos de calidad Las definiciones provistas por un atributo no son testeables Ejemplo: El sistema tiene que ser modificable No es claro a qué cualidad pertenece un aspecto particular del sistema Ejemplo: Una falla del sistema es un aspecto de disponibilidad, seguridad o usabilidad? Cada comunidad tiene su propio vocabulario Performance: Habla de eventos arribando en el sistema Seguridad: Habla de ataques arribando al sistema Disponibilidad: Habla de fallas de un sistema Usabilidad: Habla de inputs de usuario Escenarios de Atributo de Calidad Escenarios Generales vs Concretos Definición Mecanismo que permite caracterizar/capturar aspectos de atributos de calidad de una forma que puede ser evaluado y utilizado en diseño Generales Son independientes del sistema y, potencialmente pueden pertenecer a cualquier sistema. Concretos Aquellos que son específicos al sistema en consideración. Un requerimiento de atributo de calidad debería ser testeable y no ambiguo. Para lograrlo, se utilizan escenarios de atributo de calidad como una forma de caracterizarlos. Ejemplo Llega un requerimiento para hacer un cambio en la funcionalidad, y el cambio debe ser hecho en un momento particular dentro del proceso de desarrollo y dentro de un periodo de tiempo específico. Llega un requerimiento para agregar soporte a un nuevo browser para un sistema web y el cambio debe ser hecho en, como máximo, 2 semanas. Arquitectura y Diseño de Sistemas 16 Arquitectura y Diseño de Sistemas 17 1
Escenarios s de un Escenario de Atributo de Calidad. La condición a ser considerada cuando arriba al sistema. de. Es la entidad (humano, otro sistema, u otro actor) que generó el estímulo.. Las condiciones sobre las que ocurre el estímulo. El artefacto (componente, equipo, sistema entero) que es estimulado.. Define las acciones que el artefacto debería realizar como respuesta al estímulo. la. La medida de la respuesta por la cual el artefacto es evaluado. Las partes de un Escenario de Atributo de Calidad Tácticas Consideraciones Cada táctica es una opción de diseño. Puede haber otras Una táctica puede ser refinada en otras Cómo se imparte portabilidad a un diseño? Y performance? E interoperabilidad? Una táctica es una decision de diseño que influencia el control de la respuesta de un atributo de calidad Generalmente las tácticas para un atributo de calidad se organizan en una jerarquía. Táctica para Controlar la Arquitectura y Diseño de Sistemas 18 Arquitectura y Diseño de Sistemas 19 Ejemplo: Disponibilidad Áreas de Interés Es la probabilidad que tiene el Sistema de estar operativo cuando se lo necesita. Se preocupa de las fallas del Sistema y sus consecuencias asociadas: Una falla ocurre cuando el Sistema no provee un servicio consistente con sus especificaciones. Dicha falla es observable por los usuarios del Sistema. Disponibilidad Fallas vs Defectos Las fallas son observables por los usuarios del Sistema, mientras que un defecto no. Cuando un defecto es observable por usuarios, pasa a ser una falla. Si el Sistema puede corregir automáticamente los efectos de un defecto, entonces no se convierte en una falla Medición Disponibilidad 1 = tiempo medio de falla tiempo medio de falla + tiempo medio de reparación Cómo se detecta la falla? Cuán frecuentemente ocurre? Qué pasa cuando la falla ocurre? Cuánto tiempo el Sistema puede estar fuera de operación? Cuándo una falla puede ocurrir de manera segura? Cómo se puede evitar una falla? Qué tipo de notificaciones son necesarias cuando ocurre una falla? Cuánto tiempo toma su reparación? 1 Los downtimes (fuera de servicio) planificados no son considerados en el cálculo. Arquitectura y Diseño de Sistemas 20 Arquitectura y Diseño de Sistemas 21 Disponibilidad Disponibilidad Requerimientos de Disponibilidad de Ejemplo la Interna al Sistema; externa al sistema Defecto: omisión, crash, timing incorrecto, respuesta incorrecta Procesadores del sistema, canales de comunicación, almacenamiento persistente, procesos Operación Normal, Inicio del Sistema, Modo de Reparación Operación Degradada (por ej, funcionalidad limitada) El Sistema detectaría un evento y haría una o varias de las siguientes acciones: Registrarlo Notificar a quienes corresponda, incluyendo el usuario y otros sistemas Deshabilitar las fuentes de eventos que causan el defecto o falla de acuerdo a las reglas definidas Quedar no disponible por un intervalo de tiempo, hasta que se repare Continuar la operación en Modo Degradado mientras se repara. Intervalo de tiempo en el que el Sistema debe estar disponible Porcentaje de disponibilidad Tiempo para detectar la falla Tiempo para reparar la falla Tiempo que el Sistema puede funcionar en modo Degradado Arquitectura y Diseño de Sistemas 22 Arquitectura y Diseño de Sistemas 23 2
Disponibilidad Disponibilidad El heartbeat monitor determina que el servidor no responde ante operaciones normales. El sistema le informa al operador y continua operando sin tiempo de caídas. Heartbeat Monitor : Servidor no responde Proceso Informar al operador Continuar la Operación Normal operación Sin caídas Arquitectura y Diseño de Sistemas 24 Arquitectura y Diseño de Sistemas 25 Ejemplo: Modificabilidad Áreas de Interés Qué puede cambiar (el artefacto)? Es el costo (y riesgo) que tiene realizar un cambio en el Sistema. Cuándo se hace el cambio? Desarrollador Quién lo hace? Administrador de Sistema Usuario Final Cuál es la probabilidad de cambio Funcionalidad Plataforma (hw, so, middleware) (sistemas con los que debe interoperar) Cualidades del Sistema (performance) Capacidad (# usuarios, # tx) Codificación Compilación Build Configuración Ejecución Modificabilidad Cuál es el costo de hacer un sistema más modificable? El costo de introducir el/los mecanismo/s para hacer el sistema más modificable El costo de hacer la modificación usando el/los mecanismo/s Costo de Introducir el mecanismo Costo de hacer la modificación Sin mecanismo Cero El costo de cambiar el código fuente y testearlo Con mecanismo Costo de crear el mecanismo Costo de usar el mecanismo para hacer el cambio y testear el cambio Para N modificaciones similares, una justificación simplificada para la creación de un mecanismo de cambios podría ser: N x Costo de hacer el cambio sin el mecanismo => * N es la cantidad de modificaciones del mismo tipo que se preven (una predicción) Costo de crear el mecanismo + (N x Costo de hacer el cambio usando el mecanismo) Arquitectura y Diseño de Sistemas 26 Arquitectura y Diseño de Sistemas 27 Modificabilidad [Quién hace el cambio] Usuario final, desarrollador, administrador del sistema [Qué cambio debe hacerse] Deseo de agregar/modificar/eliminar funcionalidad, atributos de calidad, etc. [Qué tiene que cambiar] UI del sistema, plataforma, ambiente, sistemas con los que interactúa [Cuándo se hace el cambio] Ejecución, compilación, build, diseño Localizar los lugares a ser modificados Realizar las modificaciones sin afectar otras características del sistema Testear las modificaciones Instalar modificaciones la Costo del cambio en términos de: Elementos afectados Esfuerzo Dinero Grado en que afecta a otras características del sistema. Modificabilidad Un desarrollador desea cambiar la interfaz de usuario para que el color de fondo de la pantalla sea azul. El cambio se realizará sobre el código en tiempo de diseño, debiendo tomar no más de 3 horas en realizarlo y testearlo y sin tener efectos colaterales sobre el comportamiento del sistema. Desarrollador : Desea modificar la UI Código En tiempo de diseño La modificación es hecha sin efectos colaterales 3 horas Arquitectura y Diseño de Sistemas 28 Arquitectura y Diseño de Sistemas 29 3
Modificabilidad Se basan en 4 variables Tamaño del un módulo Siempre y cuando el criterio para dividir el módulo refleje el tipo de cambio que es probable de ocurrir Acoplamiento Reducir el acoplamiento entre dos módulos A y B disminuirá el costo esperado de cualquier modificación que afecte a uno de esos módulos. Cohesión Si un módulo tiene una baja cohesión, puede ser mejorada eliminando responsabilidad no afectadas por los cambios previstos. Así se reduce la posibilidad de efectos colaterales. Momento de implementación (binding time) En una arquitectura que propicia modificaciones tardías en el ciclo de vida, en promedio, un cambio costará menos que en una arquitectura que fuerza que la misma modificación sea hecha más temprano. Modificabilidad Arquitectura y Diseño de Sistemas 30 Arquitectura y Diseño de Sistemas 31 Ejemplo: Performance Consideraciones Origen de eventos Se ocupa básicamente de cuánto tiempo le toma al Sistema responder cuando ocurre un evento. Patrón de arribo del eventos Variable a evaluar De usuarios De otros sistemas Del mismo sistema Periódico Estocástico Esporádico Latencia Momento de procesamiento Throughput Varianza de la latencia Cantidad de eventos no procesados por exceso de carga Datos perdidos por exceso de carga Performance Una de un número independiente de fuentes posibles Eventos periódicos arriban Eventos estocásticos arriban Eventos esporádicos arriban El sistema, uno de sus componentes, un conjunto de componentes Modo normal Modo sobrecargado Modo emergencia Procesar el estímulo Cambiar el nivel de servicio la Latencia Deadline, Throughput Varianza de latencia Tasa de pérdida de requerimientos Tasa de pérdida de datos. Arquitectura y Diseño de Sistemas 32 Arquitectura y Diseño de Sistemas 33 Performance Bajo una operación normal del sistema, las transacciones ejecutadas por los usuarios deberían resolverse, en promedio, en 2 segundos. Usuarios Sistema : Instanciar Transacciones Transacciones procesadas Bajo operación normal Latencia promedio de 2 segundos Performance Background Tiempo de Procesamiento Los eventos son manejados por la ejecución de uno o más componentes, cuyo tiempo utilizado es un recurso. Contención de Recursos Muchos recursos pueden ser usados por un único cliente a la vez. Otros clientes deben esperar para acceder a ese recurso. Tiempo de Bloqueo Un cómputo puede estar bloqueado debido a contención sobre otro recurso, ya que el recurso no está disponible, o a que el cómputo depende del resultado de otro cómputo que aun no está disponible. Disponibilidad de Recursos Un cómputo podría estar detenido debido a la no disponibilidad de un recurso: porque el recursos está offline, o porque está atravesando una falla. Dependencia sobre otros cómputos Un cómputo puede tener que esperar porque debe sincronizarse con el resultado de otro cómputo Arquitectura y Diseño de Sistemas 34 Arquitectura y Diseño de Sistemas 35 4
Performance Ejemplo: Seguridad Consideraciones Tipos de ataque Acceder a datos/servicios a los que el usuario no está autorizado Limitar el servicio a usuarios legítimos Es una medida de la capacidad que tiene un Sistema para resistir el uso no autorizado mientras continua proveyendo servicio a usuarios legítimos La seguridad puede ser caracterizada en términos de: Confidencialidad Integridad Disponibilidad Autenticación No repudiación Autorización Arquitectura y Diseño de Sistemas 36 Arquitectura y Diseño de Sistemas 37 Seguridad la Arquitectura y Diseño de Sistemas 38 Individuo o sistema que está correctamente identificado, incorrectamente identificado, de identidad desconocida que es Interno/externo, autorizado/no autorizado con acceso a. Recursos limitados, vastos recursos Trata de Ver datos, modificar/eliminar datos, acceder a servicios del sistema, reducir la disponibilidad de los servicios del sistema Servicios del sistema; datos dentro del sistema Online u offline; conectado o desconectado; detrás de un firewall o abierto Autentica al usuario; oculta la identidad del usuario; bloquea/permite accesos a datos y/o servicios; garantiza o rechaza permisos para acceder a datos y/o servicios; registra los accesos por usuario; almacena datos en un formato no legible; reconoce un inexplicable aumento de demanda del servicio, informando a un usuario u otro sistema y restringiendo la disponibilidad del servicio. Tiempo/esfuerzo/recursos necesarios para sortear medidas de seguridad con probabilidad de éxito; probabilidad de detectar ataques; probabilidad de identificar responsables de un ataque o del acceso/modificación de datos; porcentaje de servicio aun disponible ante un ataque denial-of-services. Seguridad Un empleado descontento desde una ubicación remota intenta acceder a la tabla de tasas de pago durante la operación normal. El sistema mantiene un registro de auditoría y los datos correctos son restaurados dentro de 1 día. Empleado descontento conectado remotamente Arquitectura y Diseño de Sistemas 39 : Intenta modificar tasas de pago Datos dentro del Sistema Bajo operación normal El Sistema mantiene registros de auditoría Los datos correctos son restaurados dentro de 1 día y el autor es identificado Seguridad Ejemplo: Testeabilidad Es el grado en el cual un artefacto de software (sistema, modulo, clase, etc) soporta testing en un contexto de test dado. Si la testeabilidad del arterfacto de sw es alta, entonces encontrar defectos a través del testing es más sencillo. Consideraciones Se orienta, principalmente, a la posibilidad de realizar tests automatizados: unit tests, integration tests, UI tests. Para que un artefacto de software sea testeable, debe ser posible Controlar las entradas del componente, ejercitando su estado interno. Observar las salidas Arquitectura y Diseño de Sistemas 40 Arquitectura y Diseño de Sistemas 41 5
Testeabilidad Testers unitarios; testers de integración, tester de sistema, tester de aceptación, usuario finales del sistema (ya sea de manera manual o automática) Un conjunto de tests es ejecutado debido a: Incremento de código terminado o integración de subsistema terminada Sistema entregado La porción del sistema siendo testeada En tiempo de desarrollo En tiempo de compilación En tiempo de deployment En tiempo de ejecución Ejecutar un conjunto de tests y capturar el resultado Capturar las actividades que resultaron en una falla. Controlar y monitorear el estado del sistema la Porcentaje de cobertura del código ejecutable Probabilidad de falla, si la falla existe Tiempo para realizar los test Longitud de la cadena de dependencias más larga en un test Cantidad de tiempo para preparar un ambiente de test Testeabilidad Un tester unitario (desarrollador) terminó una unidad de código durante el desarrollo y realiza una secuencia de tests cuyos resultados son capturados logrando una cobertura del 85% en menos de 3 horas. Tester Unitario : Unidad de código terminada Unidad de códigp Desarrollo Resultados capturados La cobertura de código del 85% es realizada en 3 horas. Arquitectura y Diseño de Sistemas 42 Arquitectura y Diseño de Sistemas 43 Testeabilidad Testeabilidad Caso de Estudio: El Ejército de Simios de Netflix Netfix está montado sobre la nube de Amazon (AWS), más precisamente sobre instancias de EC2 (servidores virtuales). Utiliza un ejército de simios como para parte de su proceso de testing. Chaos Monkey: Aleatoriamente mata procesos en el sistema ejecutando para monitorear el efecto de un proceso fallido. Latency Monkey: Introduce retardos artificiales en la capa de comunicación cliente-servidor para simular degradación. Conformity Monkey: Busca instancias que no adhieren a las buenas prácticas y las baja (por ej., instancias que no pertenecen a un auto-scaling group). Doctor Monkey: Monitorea la salud de las instancias de EC2. Janitor Monkey: Asegura que en ambiente de Netflix en la nube no desperdicia recursos. Donde encuentra un recurso no usado, lo libera. Security Monkey: Busca violaciones o vulnerabilidades de seguridad. Si las encuentra, las elimina. También chequea que los certificados SSL no se venzan. 10-18 Monkey: Detecta problemas de configuración de localización e i18n. Netflix pondera la testeabilidad de su sistema para asegurar la calidad de su servicio. Arquitectura y Diseño de Sistemas 44 Arquitectura y Diseño de Sistemas 45 Ejemplo: Usabilidad Areas de Interés Aprendizaje de características del sistema Uso eficiente del sistema Minimizar el impacto de errores Adaptación del sistema a las necesidades del usuario Incrementar la confianza y satisfacción Relación con la Arquitectura Muchas características de usabilidad requieren de soluciones arquitectónicas tempranas Arquitectura y Diseño de Sistemas 46 La facilidad con que las personas pueden utilizar un Sistema con el fin de alcanzar un objetivo concreto. Usabilidad Arquitectura y Diseño de Sistemas 47 Usuario final Quiere Aprender las características del sistema; usar el sistema eficientemente; minimizar el impacto de errores de usuario; adaptar el sistema a sus necesidades; configurar el sistema Sistema En tiempo de ejecución; en tiempo de configuración Para soportar el aprendizaje de las características del sistema Sistema de ayuda sensible al contexto; UI familiar para el usuario Para soportar el uso del sistema eficientemente Agregación de datos/comandos; reuso de datos y comandos ya ingresados; soporte para una navegación eficiente; distintas vistas con operaciones consistentes; Para minimizar el impacto de errores de usuario Deshacer, rehacer y recuperarse de una falla del sistema; reconocer y corregir un error de usuario; recuperar password olvidada Para adaptar el sistema Personalización; Internacionalización Para sentirse cómodo Mostrar el estado del sistema; trabajar al ritmo del usuario la Tiempo de la tarea; cantidad de errores; cantidad de problemas resueltos; satisfacción del usuario; tasa de operaciones exitosas vs operaciones no exitosas; interacción necesaria para completar una tarea. 6
Usabilidad Usabilidad Un usuario descarga una nueva aplicación y está usándola productivamente luego de 2 minutos de experimentación. Usuarios : Descargar una nueva aplicación Sistema En ejecución El usuario usa la aplicación productivamente Dentro de 2 minutos de exploración Arquitectura y Diseño de Sistemas 48 Arquitectura y Diseño de Sistemas 49 Ejemplo: Confiabilidad La capacidad de un sistema de mantenerse operativo en el tiempo. La probabilidad que tiene el sistema de realizar su función sin fallas durante un período de tiempo Medidas: Tiempo Medio Entre Fallas (MTTF) Porcentaje de operaciones que se ejecutan correctamente en un periodo Ejemplo: Sistema de Aterrizaje Automático Disponibilidad Alta: Debe estar disponible cuando el avión debe aterrizar Confiabilidad Baja: No tiene que permanecer operativo por largos periodos de tiempo. Confiabilidad Observaciones: Está muy ligado a otros atributos de calidad: Disponiblidad: Es la probabilidad que tiene el Sistema de estar operativo en un determinado punto en el tiempo. Tolereancia a Fallas: La capacidad para mantener un determinado nivel de rendimiento en casos de fallas de software o de violación a su interfaz. Recuperabilidad: La capacidad de restablecer un nivel de rendimiento determinado y recuperar los datos directamente afectados en caso de falla. Madurez: La capacidad de evitar fallas como resultado de defectos en el software. Arquitectura y Diseño de Sistemas 50 Arquitectura y Diseño de Sistemas 51 Confiabilidad la Interna al Sistema; externa al sistema Defecto: datos erróneos, falla de hardware, bug en el código, problemas de ambiente Procesadores del sistema, canales de comunicación, almacenamiento persistente, procesos, datos Modo Normal, Modo Sobrecargado El Sistema detectaría un evento y haría una o varias de las siguientes acciones: Registrarlo Notificar a quienes corresponda, incluyendo el usuario y otros sistemas Tomar las acciones necesarias para dejar los datos consistentes Reintentar la operación (probablemente con algún delay) Tiempo medio entre fallas Porcentaje de operaciones que se ejecutan correctamente en un periodo Tiempo que el Sistema puede funcionar en modo Sobrecargado Disponibilidad En AWS (la nube de Amazon) las conexiones a los servicios de AWS pueden fallar eventual y esporádicamente. Ante una falla de la infraestructura de AWS, el sistema debe reintentar la transacción en 5, 10, 20, 40... segundos hasta que logre ejecutarse existosamente. Infraestructura de AWS : Error de acceso a un servicio de AWS Proceso Operación Normal Reintentar la transacción hasta tener éxito. Frecuencia de reintento: 5, 10, 20, 40 segundos, Sin transacciones fallidas Arquitectura y Diseño de Sistemas 52 Arquitectura y Diseño de Sistemas 53 7
Usabilidad Reliability Tactics Detect Faults Recover from Faults Prevent Faults Fault Ping/Echo Monitor Heartbeat Timestamp Sanity Checking Condition Monitoring Voting Exception Detection Self-Test Preparation and Repair Active Redundancy Retry Ignore Faulty Behaior Degradation Reconfiguration Async. Processing Reintroduction Shadow Passive State Resync Redundancy Escalating Restart Exception Handling Non-Stop Rollback Forwarding Transaction Predective Model Exception Prevention Increase Competence Set Replace Fault Masked or Repair Made Arquitectura y Diseño de Sistemas 54 8