La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

1 ACHIEVING QUALITIES. 2 Introducción - Tácticas Decisiones de diseño que permiten mejorar y lograr cualidades para mejorar un programa Diseño tenga portabilidad.

Presentaciones similares


Presentación del tema: "1 ACHIEVING QUALITIES. 2 Introducción - Tácticas Decisiones de diseño que permiten mejorar y lograr cualidades para mejorar un programa Diseño tenga portabilidad."— Transcripción de la presentación:

1 1 ACHIEVING QUALITIES

2 2 Introducción - Tácticas Decisiones de diseño que permiten mejorar y lograr cualidades para mejorar un programa Diseño tenga portabilidad Buen rendimiento Presente integrabilidad a otro sistema

3 3 Las tácticas están destinadas a controlar las respuestas a los estímulos Introducción - Tácticas Tácticas para controlar Respuestas Respuesta Estímulos Cada táctica es una opción de diseño para el arquitecto.

4 4 Ejemplo: Una de las tácticas introduce redundancia para aumentar la disponibilidad de un sistema. Esta es una opción que el arquitecto tiene para aumentar la disponibilidad pero no es la única. Por lo general, el logro de una alta disponibilidad mediante la redundancia implica una necesidad de sincronización (para garantizar que la copia redundante se puede utilizar si el original no esta disponible). A partir del presente ejemplo vemos dos ramificaciones: Tácticas puede refinar otras tácticas 1 Paquetes de patrones de Tácticas 2

5 5 Tácticas puede refinar otras tácticas 1 Se identificó la redundancia como una táctica, la cual puede ser refinada en función de: Redundancia de datos (en un sistema de base de datos) Redundancia de la computación (en un sistema de control integrado) Estas son tácticas que se pueden emplear para hacer cada tipo de redundancia más concreta. Para cada atributo de calidad que se discute, se organiza las tácticas como una jerarquía. Paquetes de patrones de Tácticas 2 2 Un patrón que admite probable disponibilidad utilizará tanto una táctica redundancia y una táctica de sincronización. También puede utilizar las versiones más concretas de estas tácticas..

6 6 Tácticas de disponibilidad: Todos los métodos para mantener la disponibilidad de incluir: Algunos tipos de redundancia Algún tipo de control sanitario para detectar un fallo Algún tipo de recuperación cuando se detecta una falla (ya sea automático o manual). A partir del presente ejemplo vemos dos ramificaciones: Tácticas puede refinar otras tácticas 1 Paquetes de patrones de Tácticas 2

7 7 Ejemplo: Una de las tácticas introduce redundancia para aumentar la disponibilidad de un sistema. Esta es una opción que el arquitecto tiene para aumentar la disponibilidad pero no es la única. Por lo general, el logro de una alta disponibilidad mediante la redundancia implica una necesidad de sincronización (para garantizar que la copia redundante se puede utilizar si el original no esta disponible). A partir del presente ejemplo vemos dos ramificaciones: Tácticas puede refinar otras tácticas 1 Paquetes de patrones de Tácticas 2

8 8 Tácticas de disponibilidad: Todos los métodos para mantener la disponibilidad de incluir: Algunos tipos de redundancia Algún tipo de control sanitario para detectar un fallo Algún tipo de recuperación cuando se detecta una falla (ya sea automático o manual).

9 9 Meta de Tácticas Disponibilidad Recuperación o reparación Tácticas para controlar la disponibilidad Falla

10 10 Detección de Fallas: Ping/echo: Un componentes al enviar un Ping espera recibir de vuelta un eco, en un tiempo determinado Heartbeat: Uno de los componentes emite periódicamente un mensaje de latido y otro componente esta a la escucha de este. Si falla, el componente de origen ha fracasado y un componente de corrección de defectos es notificada. Excepciones: Encontrarse con una excepción.

11 11 Recuperación de fallas Votación : De cada entrada de los procesos que se ejecutan en procesadores redundantes, se calcula un valor de salida simple que se envía a un votante. Si el elector detecta un comportamiento desviado desde un único procesador, este falla. El algoritmo de voto "reglas de la mayoría" o "El componente preferido.

12 12 Recuperación de fallas: Redundancia Activa: Todos los componentes redundantes responder a los eventos en paralelo La respuesta de un solo componente se utiliza (por lo general los primeros en responder).

13 13 Recuperación de fallas Redundancia Pasiva: Uno de los componentes (el primario) responde a los eventos e informa a los otros componentes estado de cambios que deben tomar. Para la sincronización: De repuesto: Una plataforma de computación en espera de respuesta está configurado para reemplazar muchos componentes fallidos. Este tiene que ser reiniciado a la configuración del software adecuado y tener su estado inicializado cuando se produce un error.

14 14 Hay tácticas para la reparación que se basan en la reintroducción de los componentes. Operación oculta: Un componente que haya fallado antes puede ejecutarse en modo oculto "por un corto tiempo para asegurarse de que imita el comportamiento de los otros componentes de trabajo antes de restaurar el servicio.

15 15 Re-sincronización de Estado: Cuando los componentes están desactivados en cualquiera de las tácticas de redundancia pasiva o activa, deben tener sus estados actualizados antes de retornar al servicio. Punto de control / reversión: La grabación de un estado coherente creado ya sea periódicamente o en respuesta a eventos específicos. Cuando ocurre una falla del sistema se pueden deshacer de ese estado.

16 16 Prevención de fallos: Separación del servicio: La eliminación de un componente del servicio para someterse a algunas actividades prever fracasos anticipados Transacciones: La agrupación de varias etapas sucesivas en las que se puede deshacer todo el paquete a la vez. Proceso de monitor: Seguimiento de un fallo en un proceso y eliminar el proceso de mora así permitir la creación de una nueva instancia de la misma.

17 17 Resumen: Falla Falla reparada o recuperada Disponibilidad Detección de falla Ping/Echo Heartbeat Excepción Recuperación, preparación y reparación Votante Redundancia Activa Redundancia Pasiva Repuesto Recuperación- reintroducción Oculto Resincronización de estado Rollback Prevención Remover del servicio Transacción Monitor de procesos

18 18 Tácticas de Modificabilidad: El objetivo es controlar el tiempo y el costo de implementar, probar y desplegar los cambios. tácticas específicas incluyen: Localizar modificaciones Prevenir los efectos dominó Aplazar el enlace en tiempo

19 19 Meta de Tácticas de Modificabilidad Los cambios realizados, probado y desplegado dentro de tiempo y presupuesto Tácticas para controlar la modificabilidad Llega el Cambio

20 20 Localizar modificaciones Mantener la coherencia semántica : asegurándose de que todas las responsabilidades en un módulo están relacionados y trabajar juntos sin excesiva dependencia de otros módulos. Servicios comunes resumidos- que las modificaciones solamente necesiten ser hechas una vez. Anticípese a los cambios esperados - considerar cambios al hacer la descomposición. Generalizar el módulo - el más general es el módulo, los cambios más probables pueden ser alojados con poco o ningún cambio. Limitar las opciones posibles - por ejemplo la limitación de la plataforma para una línea de productos podría mejorar la modificabilidad.

21 21 Prevent Ripple Effects Tipos de dependencias de un módulo (B) puede tener sobre otro (A), que podría causar un efecto: – Sintaxis de los datos – Sintaxis del servicio – Semántica de los datos – Semántica de servicio – Secuencia de los datos – Secuencia de control

22 22 Identidad de una interfaz de A Ubicación de A (tiempo de ejecución) Calidad del servicio / datos facilitados por A Existencia de A Recursos comportamiento de A

23 23 Tácticas para evitar un efecto ripple incluyen: Ocultar información Mantener las actuales interfaces Adición de interfaces Agregar adaptador Proporcionar un stub Restringir los caminos de comunicación

24 24 El uso de un intermediario – De datos (sintaxis) – repositorios – Servicio (sintaxis) - façade, bridge, mediator, strategy, proxy, and factory patterns – Identidad de una interfaz de A- patrón broker – Ubicación de A (tiempo de ejecución) - servidor de nombres – Recursos comportamiento de A o recurso controlado por A - administrador de recursos. – Existencia de A - factory patterns

25 25 Defer Binding Time Tactics Muchas tácticas están destinadas a tener un impacto en el tiempo de carga o tiempo de ejecución, tales como las siguientes: – Tiempo de ejecución de registro plug-and-play – Los archivos de configuración están destinadas a establecer los parámetros en el arranque. – El polimorfismo permite el enlace de llamadas a métodos. – Componente de reemplazo permite el tiempo de carga vinculante. – La adhesión a los protocolos definidos permite en tiempo de ejecución obligar a los procesos independientes.

26 26 Performance Tactics El objetivo es generar una respuesta a un evento que llega al sistema, dentro de algunas limitaciones de tiempo.

27 27 Las tácticas se dividen en tres categorías: Resource Demand Resource Management Resource Arbitration

28 28 Contribuyentes básicos al tiempo de respuesta El consumo de recursos - Los recursos incluyen el CPU, almacenamiento de datos, ancho de banda, y la memoria. Los eventos pueden ser diversos tipos, y cada tipo pasa por una secuencia de procesamiento. Tiempo de Bloqueo - La contención de recursos - Falta de disponibilidad de recursos - La dependencia de otro tipo de cálculo

29 29 Administración de Recursos Aunque la demanda de recursos no es controlable, la administración de estos recursos afectan los tiempos de respuesta. Algunas tácticas para la administración de recursos son: Introducir concurrencia. Mantener múltiples copias de datos o cálculos. Incrementar recursos disponibles.

30 30 Recursos de Arbitraje Cada vez que existe una contención por un recurso, el recurso debe ser programado. La tarea de un arquitecto es entender las características de cada recurso para tener una estrategia de programación. Una política de programación conceptualmente posee 2 partes: Asignación de prioridades. Distribución.

31 31 Recursos de Arbitraje Algunas políticas comunes de programación son: First-in/First-out Prioridad de programación fijada Importancia Semántica Plazo monotónico Tasa monotónica Programación dinámica de prioridad Round Robin Plazo más cercano primero Programación estática

32 32 Resumen

33 33 TÁCTICAS DE SEGURIDAD

34 34 Tácticas de seguridad Pueden ser divididas en 3 tipos: Resistencia ante ataques: Usar una cerradura en la puerta. Detección de ataques: Usar un censor de movimiento. Recuperación: Tener un seguro contra robos.

35 35 Resistencia ante ataques Autentificación de usuarios Autorización de usuarios Mantener la confidenciabilidad de los datos Mantener la integridad Límite de exposición Acceso limitado

36 36 Detección de ataques La detección de un ataque es generalmente a través de un sistema de detección de intrusos. Estos sistemas trabajan mediante la comparación de patrones de tráfico de red a una base de datos. En el caso de detección de mal uso, el patrón de tráfico se compara con los patrones históricos de ataques conocidos. En el caso de detección de anomalías, el patrón de tráfico se compara con una base histórica de sí mismo. Con frecuencia, los paquetes deben ser filtrados con el fin de hacer comparaciones. La filtración puede hacerse sobre la base del protocolo, las banderas TCP, el tamaño de la carga útil, origen o destino, o número de puerto.

37 37 Recuperación frente ataques Estas tácticas pueden ser divididas en 2: Restauración Restaurar el sistema o los datos a un estado correcto o consistente. Identificación Mantener una pista de auditoría: Mantener una copia de cada transacción con información de identificación. Las pistas de auditoría son en muchos casos víctimas de ataques.

38 38 Resumen

39 39 TÁCTICAS DE COMPROBABILIDAD

40 40 Tácticas de Comprobabilidad La meta de este tipo de tácticas es permitir un testing mucho más sencillo cuando un incremento en el desarrollo de software es completado. Las técnicas de arquitectura para mejorar el testing de software no han recibido mucha atención pero tomando en cuenta que el arquitecto debe reducir costos entonces debemos tomarlas en cuenta. Proveemos 2 categorías: Proveer entradas y capturar salidas. Monitoreo interno

41 41 Entrada/Salida Grabar/reproducir: La información dada en una interfaz en ejecución normal es guardada en un repositorio, sirve de entrada para un componente y salida para otro. Entradas de prueba y salidas para comparación. Separar la interfaz de la implementación Permite sustitución de implementaciones. Apagar implementaciones. Especializar rutas/interfaces de acceso Permite la captura o especificaciones de los valores de variables para un componente a través del test harness, de manera independiente de su ejecución normal.

42 42 Monitoreo Interno Un componente puede implementar tácticas basadas en su estado interno: Built-in monitors : El componente puede mantener el estado, la carga de rendimiento, capacidad, seguridad, u otra información accesible a través de una interfaz. Una técnica común consiste en registrar los acontecimientos cuando los estados de vigilancia se han activado. Los estados de monitoreo pueden hacer aumentar el esfuerzo de pruebas ya que las pruebas pueden tener que ser repetido con la vigilancia desactivada.

43 43 Resumen

44 44 TÁCTICAS DE USABILIDAD Usabilidad: Cuan fácil es para el usuario realizar una tarea y el soporte que el sistema brinda al usuario.

45 45 Tácticas en tiempo de Ejecución Cuando un sistema es ejecutándose, la usabilidad es mejorada: Informando al usuario de lo que el sistema esta haciendo. Proporcionando al usuario la capacidad para aplicar comandos basados en la usabilidad, como Cancelar, Deshacer, Agregar.

46 46 Interacción Humano-Computador Los investigadores definen 3 términos: Iniciativa del Usuario: El usuario presiona Cancelar. Iniciativa del Sistema: El sistema responde y además muestra una barra de progreso. Iniciativa Mixta

47 47 Tácticas de Iniciativa del Sistema El sistema necesita información (modelos) sobre el usuario, las tareas ejecutadas por el usuario, o el estado actual del mismo sistema: Identificar los modelos que el sistema usa para predecir la intenciones del usuario o el comportamiento del sistema. Encapsular la información, proveerá facilidad diseñar y modificar los modelos.

48 48 Mantener un Modelo de Tarea: Identificar situaciones en las que el sistema puede saber lo que el usuario esta intentando hacer, y en consecuencia proveer asistencia. Mantener un Modelo de Usuario: Mantener un Modelo del Sistema: Identifica los comportamientos del Sistema, para brindarle información adecuada al usuario.

49 49 Tácticas de Tiempo de Diseño Separar las interfaces de Usuario, de todo lo demás: Model-View-Controller: Separa los datos de una aplicación, la interfaz de usuario, y lalógica de control en tres componentes distintos. Presentation-Abstraction-Control: Jerarquía de agentes cooperantes similar a Modelo Vista Controlador (MVC). Seeheim: Arch/Slinky: Delegación de conocimiento del dominio. Las distintas funcionalidades de cada componente pueden desplazarsea otras componentes.

50 50 Patrones Arquitectónicos y Estilos Se necesita y reglas para preservar la integridad arquitectónica: Conjunto de Tipos de Elementos: Repositorio de Datos. Una capa topológica: Indica la relación entre elementos. Un conjunto de Restricciones Semánticas Un conjunto de Mecanismos de Interacción: Determina como los elementos coordinan entre ellos en una capa topológica.


Descargar ppt "1 ACHIEVING QUALITIES. 2 Introducción - Tácticas Decisiones de diseño que permiten mejorar y lograr cualidades para mejorar un programa Diseño tenga portabilidad."

Presentaciones similares


Anuncios Google