| Revisión actual |
Tu texto |
| Línea 1: |
Línea 1: |
| {{Back|Ingeniería de Software II}} | | {{Back|Ingeniería de Software II}} |
|
| |
|
| La definición de una arquitectura requiere conocer tres elementos: requerimientos funcionales de negocio, atributos de calidad y restricciones del modelo.
| | = Atributos y Tácticas = |
| | |
| = 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 == |
|
| |
| 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 === | | === Fault Detection === |
|
| |
|
| * Ping/echo: Un proceso externo hace ping al monitoreado para determinar su estado. Puede haber múltiples pingers en distintas capas. | | * Ping/echo |
| * 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. | | * Heartbeat |
| * 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. | | * Exception |
|
| |
|
| === Recovery === | | === 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 ==== | | ==== 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 |
| | | * Active redundancy |
| * 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. | | * Passive redundancy |
| * 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. | | * Spare |
| * 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 ==== | | ==== Reintroduction ==== |
|
| |
|
| La reintroducción de un componente se da una vez que este es reparado.
| | * Shadow |
| | | * State resync |
| * Shadow: Un componente puede correrse en shadow mode hasta asegurarse que funciona correctamente antes de ponerlo efectivamente en servicio. | | * Rollback |
| * 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 === | | === 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. | | * Removal from service |
| * Transactions: Permiten restaurar estados válidos en caso de que falle algún paso en la transacción. | | * Transactions |
| * Process monitor: Un monitor puede detectar fallas en procesos y generar una nueva instancia en caso de falla. | | * Process monitor |
| * Compensación: En casos que no sea posible concentrar el estado en un componente, debemos manejar mecanismos de undo o de compensación.
| |
|
| |
|
| == Modifiability == | | == 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 === | | === Localize Changes === |
|
| |
|
| Se busca reducir el número de módulos que se debe modificar para realizar un cambio.
| | * Semantic coherence |
| | | * Anticipate expected changes |
| * 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. | | * Generalize module |
| * 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''. | | * Limit possible options |
| * 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. | | * Abstract common services |
| * 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 === | | === 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 |
| | | * Mantain existing interfaces |
| * Information hiding: Controla dependencias sintácticas principalmente. | | * Restrict communication paths |
| * 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. | | * Use intermediary |
| * 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 === | | === Defer Binding Time === |
| Línea 207: |
Línea 61: |
| == Performance == | | == Performance == |
|
| |
|
| Performance se refiere exclusivamente a optimización de tiempos. Notar que scalability puede incluirse dentro de performance. Los concerns relacionados son: | | Performance se refiere exclusivamente a optimización de tiempos. |
| | |
| * 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. | | 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. |
| Línea 217: |
Línea 67: |
| === Resource Demand === | | === Resource Demand === |
|
| |
|
| Atacan la demanda de recursos en sí. Una posibilidad es reducir la cantidad de recursos que requiere cada evento.
| | * Increase computation efficiency |
| | | * Reduce computational overhead |
| * 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 | | * Manage event rate |
| * Control frequency sampling | | * Control frequency sampling |
|
| |
| También se puede controlar el uso de recursos.
| |
|
| |
| * Bound execution times
| |
| * Bound queue sizes
| |
|
| |
|
| === Resource Management === | | === Resource Management === |
|
| |
|
| * Introduce concurrency: Procesar los eventos concurrentemente para reducir tiempos de bloqueo. | | * Introduce concurrency |
| * Mantain multiple copies: Sea de datos o de cómputos, en otras palabras, caching. | | * Mantain multiple copies |
| * Increase available resources: Aumentar recursos a cambio de aumentar el costo. | | * Increase available resources |
|
| |
|
| === Resource Arbitration === | | === Resource Arbitration === |
| Línea 275: |
Línea 115: |
|
| |
|
| == Testability == | | == 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 == | | == Usability == |
|
| |
| Usabilidad se basa en la confianza y facilidad de uso de un usuario con respecto al sistema.
| |
|
| |
|
| === Concerns === | | === Concerns === |
|
| |
|
| * Interfaz de usuarios | | * Interfaz de usuarios |
| * Proceso de negocio | | * Procedo de negocio |
| * Calidad de información | | * Calidad de información |
| * Alinear la capacidad del usuario con la interfaz | | * Alinear la capacidad del usuario con la interfaz |
| Línea 304: |
Línea 128: |
| === Tácticas === | | === 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.
| | * Support User Interface |
| | | * Support User Initiative (Cancel, Undo o Agregatte) |
| * 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 System Initiative (User model, System model, System Task) |
| * 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. | |
|
| |
|
| [[Category:Apuntes]] | | [[Category:Apuntes]] |
