Capítulo 1. El ciclo de negocio de arquitecturaÉxito competitivo, simplemente declarado fluye a la empresa que se las arregla para establecer un control de arquitectura propietario sobre un espacio amplio, veloces, competitivo.

Morris C. y C. Ferguson [Morris 93]

Durante décadas, los diseñadores de software han aprendido a construir sistemas basados exclusivamente en los requisitos técnicos. Conceptualmente, el documento de requisitos es arrojado encima de la pared en cabina el diseñador de la, y el diseñador debe venir con un diseño satisfactorio. Requisitos de engendrar diseño, que responde al sistema. Por supuesto, los métodos de desarrollo de software moderno reconocen la ingenuidad de este modelo y proporcionan a todo tipo de reacciones de diseñador de analista. Pero todavía hacen la asunción implícita que el diseño es un producto de los requisitos técnicos del sistema, período.

La arquitectura se ha convertido en una parte crucial del proceso de diseño y es objeto de este libro. Arquitectura de software abarca las estructuras de los sistemas de software grandes. La vista arquitectónico de un sistema es abstracto, destilación de lejos los detalles de implementación, el algoritmo y la representación de datos y concentrarse en el comportamiento y la interacción de los elementos de la "caja negra". Una arquitectura de software es desarrollada como el primer paso para diseñar un sistema que tiene una colección de propiedades que desee. Analizaremos la arquitectura de software en detalle en el capítulo 2. Por el momento que ofrecemos, sin comentarios, la siguiente definición:

La arquitectura de software de un programa o sistema informático es la estructura o estructuras del sistema, que constituyen de elementos de software, las propiedades visibles externamente de esos elementos y las relaciones entre ellos.

Capítulo 2 proporcionará nuestras definiciones de trabajo y distinguir entre la arquitectura y otras formas de diseño. Por razones que vamos a ver en todo, arquitectura sirve como una herramienta de comunicación, razonamiento, análisis y crecimiento importante para los sistemas. Hasta ahora, sin embargo, diseño de la arquitectura se ha discutido en la luz que, si conoce los requisitos para un sistema, puede crear la arquitectura para él.

Esto es miope (consulte la barra lateral el sueco Vasa de barco) y no contar toda la historia. ¿Qué Supongamos que pasaría si dos diferentes arquitectos, trabajando en dos organizaciones diferentes, se les dio la misma especificación de requisitos para un sistema? ¿Cree usted que produciría la misma arquitectura o otras diferentes?

La respuesta es que, en general, se producen los diferentes, que inmediatamente desmiente la noción de que los requisitos determinan la arquitectura. Otros factores son en el trabajo, y no se pueda reconocerlos es continuar trabajando en la oscuridad.

El enfoque de la pregunta es la siguiente: ¿cuál es la relación de la arquitectura de software de un sistema para el medio ambiente en el que el sistema será construido y existen? La respuesta a esta pregunta es el motivo organizador de este libro. Arquitectura de software es que un resultado de técnico, de negocio y social influye. Su existencia a su vez afecta a la técnica, de negocios y entornos sociales que influyen posteriormente en futuras arquitecturas. Llamamos a este ciclo de influencias, desde el entorno a la arquitectura y de nuevo al medio ambiente, el ciclo de negocio de arquitectura (ABC).

Este capítulo presenta el ABC en detalle y sienta las bases para el resto del libro. Las partes principales de la gira de libro el ciclo mediante el examen de los siguientes:

Cómo influyen en objetivos de la organización requisitos y estrategia de desarrollo.

Cómo los requisitos de conducen a una arquitectura.

¿Cómo se analizan las arquitecturas.

¿Cómo arquitecturas de producen sistemas que sugieren los requisitos y las nuevas capacidades organizativas.

1.1 De donde provienen las arquitecturas?Una arquitectura es el resultado de un conjunto de decisiones técnicas y del negocio. Hay muchas influencias en el trabajo en su diseño, y la realización de estas influencias cambiará en función del entorno en el que la arquitectura es necesaria para realizar. Un arquitecto que diseñar un sistema para el que se cree que estrecha los plazos en tiempo real son hará que un conjunto de opciones de diseño; el mismo arquitecto, diseñar un sistema similar en el que los plazos se pueden satisfacerse fácilmente, hará que diferentes opciones. Y el mismo arquitecto, diseñar un sistema no en tiempo real, es probable que tomar decisiones muy diferentes todavía. Incluso con el mismo requisitos, hardware, software de asistencia y los recursos humanos disponibles, un arquitecto de diseñar un sistema de hoy en día es probable que diseñar un sistema diferente que podría han sido diseñados hace cinco años.

En cualquier esfuerzo de desarrollo, los requisitos de hacen explícito algunos — pero sólo algunos — de las propiedades que desee del sistema final. No todos los requisitos se refieren directamente a esas propiedades; un proceso de desarrollo o el uso de una herramienta concreta puede tener el mandato por ellos. Pero la especificación de requisitos sólo comienza a contar la historia. Incumplimiento de otras restricciones puede impedir el sistema tan problemático como si funcionó mal.

Empezamos el ABC de la construcción mediante la identificación de las influencias desde arquitecturas y.

ARQUITECTURAS ESTÁN INFLUENCIADAS POR LOS ACTORES DEL SISTEMAMuchas personas y organizaciones están interesadas en la construcción de un sistema de software. Llamamos a estas partes interesadas: el cliente, los usuarios finales, los

desarrolladores, el jefe de proyecto, los encargados de mantener y incluso a aquellos que el sistema de mercado son algunos ejemplos. Los interesados tienen preocupaciones diferentes que desean el sistema para garantizar u optimizar, incluyendo cosas como diversos como la prestación de un determinado comportamiento en tiempo de ejecución, bien en una pieza particular de hardware, ser fácil de personalizar, lograr poco tiempo al mercado o de bajo costo de desarrollo, ejercicio que emplean los programadores que tienen una especialidad determinada o proporcionar una amplia gama de funciones. La figura 1.2 muestra al arquitecto recibiendo a los interesados útil "sugerencias".

Un sistema aceptable incluye propiedades como el rendimiento, fiabilidad, disponibilidad, compatibilidad de plataforma, utilización de la memoria, uso de la red, seguridad, modificabilidad, facilidad de uso y la interoperabilidad con otros sistemas, así como el comportamiento. De hecho, vamos a ver que estas propiedades determinan el diseño general de la arquitectura. Todos ellos y otros, afectan a cómo se ve el sistema entregado por sus eventuales beneficiarios, y hasta que encuentran una voz en uno o más de las partes interesadas del sistema.

El problema subyacente, por supuesto, es que cada actor tiene diferentes preocupaciones y objetivos, algunos de los cuales pueden ser contradictorios. Propiedades pueden ser enumerados y discutidos, por supuesto, en un artefacto como un documento de requisitos. Pero es un documento de requisitos rara que hace un buen trabajo de captura de requisitos de calidad de un sistema en detalle comprobable. La realidad es que el arquitecto tiene a menudo rellenar los espacios en blanco y mediar en los conflictos.

ARQUITECTURAS ESTÁN INFLUENCIADAS POR LA ORGANIZACIÓN EN DESARROLLO

Además de los objetivos de la organización expresados a través de requisitos, una arquitectura está influenciada por la estructura o la naturaleza de la organización de

desarrollo. Por ejemplo, si la organización tiene una abundancia de inactividad programadores calificados en las comunicaciones del cliente y el servidor, entonces una arquitectura cliente-servidor podría ser el enfoque apoyado por la dirección. Si no es así, bien podrá ser rechazada. Las habilidades del personal son una influencia adicional, pero también lo son el plan de desarrollo y el presupuesto.

Existen tres clases de influencia que provienen de la organización en desarrollo: negocio inmediata, negocios a largo plazo y estructura organizativa.

Una organización puede tener una inversión de negocio inmediata en ciertos activos, como las arquitecturas actuales y los productos basados en ellos. La base de un proyecto de desarrollo puede ser que el sistema propuesto es el siguiente en una secuencia de sistemas similares, y las estimaciones de gastos asuman un alto grado de reutilización de activos.

Tal vez desee hacer una inversión a largo plazo de las empresas en una infraestructura para perseguir objetivos estratégicos y puede ver el sistema propuesto como uno de los medios de financiación y ampliar la infraestructura de una organización.

La estructura organizativa puede dar forma a la arquitectura de software. En el caso de estudio en el capítulo 8 (simulación de vuelo: un caso de estudio en la arquitectura de integrabilidad), el desarrollo de algunos de los subsistemas fue subcontratado porque los subcontratistas proporcionan conocimientos especializados. Esto fue posible por una división de funcionalidad en la arquitectura que permite el aislamiento de las especialidades.

ARQUITECTURAS ESTÁN INFLUENCIADAS POR LOS ANTECEDENTES Y LA EXPERIENCIA DE LOS ARQUITECTOS

Si los arquitectos para un sistema han tenido buenos resultados utilizando un enfoque arquitectónico particular, tales como objetos distribuidos o invocación implícita, lo más probable es que tratarán de ese mismo enfoque en un nuevo esfuerzo de desarrollo. Por el contrario, si su experiencia previa con este enfoque fue desastrosa, los arquitectos pueden ser reacios a vuelva a intentarlo. Opciones de arquitectura también pueden provenir de un arquitecto de la formación, la exposición a los patrones arquitectónicos con éxito o exposición a los sistemas que han trabajado especialmente mal o particularmente bien. Los arquitectos también podría experimentar con un patrón de arquitectura o extraídas de un libro (como éste) o un curso de técnica.

ARQUITECTURAS ESTÁN INFLUENCIADAS POR EL ENTORNO TÉCNICO

Un caso especial de formación y la experiencia del arquitecto se refleja en el entorno técnico. El entorno que es actual cuando se diseña una arquitectura influirá en esa arquitectura. Puede incluir prácticas de la industria estándar o técnicas de ingeniería de software prevalentes en la comunidad profesional del arquitecto. Es un arquitecto valiente que, en el entorno actual, no considera al menos un diseño basado en Web, orientado a objetos, apoyo de middleware para un sistema de información.

RAMIFICACIONES DE INFLUENCIAS EN UNA ARQUITECTURA

Influencias en una arquitectura provienen de una amplia variedad de fuentes. Algunos son sólo implícita, mientras que otros son explícitamente en los conflictos.

Casi nunca son las propiedades requeridas por el negocio y los objetivos de la organización conscientemente entendidas, y mucho menos plenamente articuladas. De hecho, incluso los requerimientos del cliente son rara vez documentados completamente, lo que significa que no se haya resuelto el conflicto inevitable entre los objetivos de los diferentes interesados.

Sin embargo, los arquitectos deban conocer y comprender la naturaleza, origen y prioridad de restricciones en el proyecto lo antes posible. Por lo tanto, deben identificar y participar activamente a las partes interesadas para solicitar sus necesidades y expectativas. Sin tal compromiso, las partes interesadas, en algún momento, exigirá que los arquitectos explican por qué cada uno propuesto arquitectura es inaceptable, así retrasar el proyecto y los trabajadores de ralentí. Principio de compromiso de las partes interesadas permite a los arquitectos a comprender las limitaciones de la tarea, manejar las expectativas, negociar las prioridades y tomar soluciones de compromiso. Arquitectura de revisiones (cubiertas en la tercera parte) y creación de prototipos iterativo son dos medios para su realización.

Es evidente que los arquitectos necesitan más de sólo técnicas. Las explicaciones a los una interesados u otra será necesarias en relación con las prioridades elegidas de diferentes propiedades y por qué los interesados particulares no están teniendo todas sus expectativas satisfechos. A continuación, para un arquitecto eficaz, habilidades de comunicación, la negociación y la diplomacia son esenciales.

Las influencias en el arquitecto y por lo tanto en la arquitectura, se muestran en la figura 1.3. Arquitectos están influenciados por los requisitos para el producto que se deriva de sus grupos de interés, la estructura y los objetivos de la organización en desarrollo, el entorno técnico disponible y su propio fondo y experiencia.

LAS ARQUITECTURAS DE AFECTAR A LOS FACTORES QUE INFLUYEN LES

El mensaje principal de este libro es las relaciones entre los objetivos de negocio, los requisitos del producto, la experiencia de arquitectos, arquitecturas y envió el formulario de sistemas se repite un ciclo con comentarios que puede administrar un negocio. Un negocio administra este ciclo para manejar el crecimiento, para ampliar su área de empresa y para tomar ventaja de las inversiones anteriores en la arquitectura y la construcción del sistema. Figura 1.4 muestra los bucles de retroalimentación. Algunos de los comentarios proviene de la arquitectura, y algunos proviene del sistema construido de ella.

Figura 1.4. El ciclo de negocio de arquitectura

Así es cómo funciona el ciclo:

La arquitectura afecta a la estructura de la organización en desarrollo. Una arquitectura prescribe una estructura para un sistema; como veremos, particularmente prescribe las unidades de software que debe ser implementado (u obtenido) e integrada para formar el sistema. Estas unidades son la base de la estructura del proyecto de desarrollo. Se formaron equipos de unidades individuales de software; y las actividades de desarrollo, prueba e integración todos giran en torno a las unidades. Del mismo modo, presupuestos y programaciones de asignan recursos en paquetes correspondientes a las unidades. Si una empresa se convierte en un experta en la construcción de las familias de sistemas similares, tiende a invertir en cada equipo por crianza de cada área de conocimiento. Equipos de convertirse en incrustado en la estructura de la organización. Se trata de comentarios de la arquitectura a la organización en desarrollo.

En el software de producto línea de estudio en el capítulo 15, grupos separados se dieron la responsabilidad de construir y mantener las porciones individuales de arquitectura de la Organización para una familia de productos. En cualquier diseño emprendida por la

organización en su conjunto, estos grupos tienen una voz fuerte en la descomposición del sistema, presionando para la existencia continuada de las porciones que controlan.

La arquitectura puede afectar a los objetivos de la organización en desarrollo. Un exitoso sistema construido de ella puede permitir a una empresa establecer un punto de apoyo en un área de mercado en particular. La arquitectura puede proporcionar oportunidades para la producción eficiente y despliegue de sistemas similares, y la organización puede ajustar sus objetivos para aprovechar su experiencia nueva para sondear el mercado. Se trata de opiniones desde el sistema a la organización en desarrollo y los sistemas que se construye.

La arquitectura puede afectar a los requisitos del cliente para el sistema siguiente, dando al cliente la oportunidad de recibir un sistema (basado en la misma arquitectura) de una manera más confiable, oportuna y económica que si el sistema posterior fueron construidos desde cero. El cliente puede estar dispuesto a relajar algunos requisitos para obtener estas economías. Cubetas de software claramente ha afectado a los requisitos de las personas mediante el suministro de soluciones que no se ajustan a sus necesidades precisas, pero en su lugar son baratas y (en el mejor de los mundos posibles) de alta calidad. Las líneas de productos tienen el mismo efecto en los clientes que no puede ser tan flexible con sus normas. En el capítulo 15 (CelsuisTech, un caso de estudio en el desarrollo de la línea de productos), le mostraremos cómo una arquitectura de la línea de producto causado los clientes felizmente comprometer sus necesidades porque podrían obtener software de alta calidad que se ajusten a sus necesidades básicas rápida, confiable y a un menor costo.

El proceso de creación del sistema de afectará de experiencia del arquitecto con sistemas posteriores al agregar a la base de la experiencia corporativa. Un sistema que con éxito fue construido alrededor de un bus de la herramienta o.Máquinas de estado finito netas o encapsuladas generará sistemas similares, construidos en el futuro de la misma manera. Por otra parte, arquitecturas que no tienen menos probabilidades de ser elegido para futuros proyectos.

Algunos sistemas influirán y cambiar la cultura de la ingeniería de software, es decir, el entorno técnico, en la que los creadores de sistemas operan y aprenden. La primeras de bases de datos relacionales, generadores de compilador y sistemas operativos de control tuvo este efecto en la década de 1960 y principios de los 70; la primeras de hojas de cálculo y los sistemas de ventanas, en la década de 1980. La World Wide Web es el ejemplo para el decenio de 1990, como sugerimos en su estudio de caso en el capítulo 13. J2EE puede ser el ejemplo para el primer decenio del siglo XXI, como se explica en el capítulo 16. Cuando se construyen tales sistemas de Buscatrazos, sistemas posteriores se ven afectados por su legado.

Estos y otros mecanismos de retroalimentación forman lo que se llama el ABC, que se ilustra en la figura 1.4, el cual representa las influencias de la cultura y los negocios de la organización de desarrollo sobre la arquitectura de software. Esa arquitectura es, a su vez, un factor primario de las propiedades del sistema desarrollado o sistemas. Pero el ABC también se basa en el reconocimiento que organizaciones astutas pueden aprovechar las ventajas de los efectos de organización y basado en la experiencia de desarrollo de una

arquitectura y pueden utilizar dichos efectos para colocar sus negocios estratégicamente para futuros proyectos.

1.2 Procesos de software y el ciclo de negocio de arquitectura

Proceso de software es el término dado a la organización, ritualization y gestión de las actividades de desarrollo de software. ¿Las actividades que están involucradas en la creación de una arquitectura de software, uso de esa arquitectura para darse cuenta de un diseño y, a continuación, aplicar o administrar la evolución de una aplicación o el sistema de destino? Estas actividades incluyen lo siguiente:

Crear el caso empresarial para el sistema

Comprender los requerimientos

Crear o seleccionar la arquitectura

Documentar y comunicar la arquitectura

Análisis o evaluación de la arquitectura

Aplicación del sistema basado en la arquitectura

Garantizar que la aplicación se ajusta a la arquitectura

ACTIVIDADES DE LA ARQUITECTURA

Como se indica en la estructura de la cadena ABC, las actividades de la arquitectura tienen relaciones de retroalimentación integral entre sí. Presentaremos brevemente cada actividad en las subsecciones siguientes.

Creación del análisis de rentabilidad para el sistema

Creación de un caso de negocios es más amplia que simplemente evaluar la necesidad de mercado para un sistema. Es un paso importante en la creación y la restricción de cualquier requisito futuro. ¿Cuánto debería costar el producto? ¿Cuál es su mercado objetivo? ¿Cuál es su tiempo dirigido al mercado? ¿Será necesario interactuar con otros sistemas? ¿Existen limitaciones que tiene que trabajar dentro del sistema?

Estas son todas cuestiones que deben involucrar a los arquitectos del sistema. No pueden ser decididos exclusivamente por un arquitecto, pero si no es consultado un arquitecto en la creación de las oportunidades empresariales, puede ser imposible de alcanzar los objetivos de negocio.

Comprender los requerimientos

Hay una variedad de técnicas para obtener los requisitos de las partes interesadas. Por ejemplo, el análisis orientado a objetos utiliza escenarios, o "casos de uso" encarnar requisitos. Sistemas de seguridad crítica utilizan enfoques más rigurosos, como modelos de máquina de estado finito o especificación formal de idiomas. En el capítulo 4 (atributos de calidad de entendimiento), presentamos una colección de escenarios de atributo de calidad que admiten la captura de requisitos de calidad para un sistema.

Una decisión fundamental con respecto al sistema de construcción es la medida en que es una variación de otros sistemas que han sido construidos. Dado que es un sistema poco común en estos días que no es similar a otros sistemas, técnicas de obtención de requisitos ampliamente involucran entender las características de estos sistemas de prior. Discutimos sobre las implicaciones de arquitectura de líneas de productos en el capítulo 14 (líneas de productos de Software: arquitectura de Re-using de activos).

Otra técnica que nos ayuda a comprender requisitos es la creación de prototipos. Prototipos pueden ayudar a modelar el comportamiento deseado, diseñar la interfaz de usuario o analizar la utilización de los recursos. Esto ayuda a que el sistema "real" a los ojos de sus grupos de interés y rápidamente puede catalizar las decisiones sobre el diseño del sistema y el diseño de su interfaz de usuario.

Independientemente de la técnica utilizada para obtener los requisitos, las cualidades deseadas del sistema a construirse determinan la forma de su arquitectura. Tácticas específicas durante mucho tiempo se han utilizado por los arquitectos para lograr atributos de calidad especial. Discutimos muchas de estas tácticas en el capítulo 5 (logro de cualidades). Un diseño arquitectónico encarna muchas soluciones de compromiso, y no todas estas soluciones de compromiso son evidentes cuando se especifica requisitos. No es hasta que la arquitectura se crea que algunos compensaciones entre requisitos ponerse de manifiesto y forzar una decisión sobre las prioridades de requisito.

Crear o seleccionar la arquitectura

En el libro de hito The Mythical Man, Fred Brooks sostiene con fuerza y con elocuencia que la integridad conceptual es la clave para diseño de sistema de sonido y que sólo puede ser contaba con integridad conceptual por un pequeño número de mentes que se unen para diseñar la arquitectura del sistema. Capítulos 5 (logro de cualidades) y 7 (diseño de la arquitectura) se muestra cómo crear una arquitectura para lograr su comportamiento y requisitos de calidad.

La arquitectura de la comunicación

Para que la arquitectura es eficaz como la columna vertebral del diseño del proyecto, debe comunicarse claramente y sin ambigüedades a todas las partes interesadas. Los desarrolladores deben entender las asignaciones de trabajo requiere de ellos, encargados de pruebas deben comprender la estructura de la tarea les impone, gestión debe comprender las implicaciones de programación sugiere y así sucesivamente. Para este fin, documentación

la arquitectura de la debe ser informativo, sin ambigüedades y legible por muchas personas con antecedentes de variada. Discutimos sobre la documentación de arquitecturas en el capítulo 9 (documentar arquitecturas de Software).

Análisis o evaluación de la arquitectura

En cualquier proceso de diseño, habrá varios diseños de candidato considerados. Algunos serán rechazados inmediatamente. Otros competirán para primacía. La elección de entre ellas compitiendo diseños de manera racional es uno de los grandes del arquitecto desafíos de la est. Los capítulos en la tercera parte (análisis de una arquitectura) describen métodos para hacer este tipo de elecciones.

Evaluación de una arquitectura para las cualidades que soporta es esencial para garantizar que el sistema había construido a partir de que la arquitectura satisface las necesidades de sus agentes interesados. Cada vez más extendido es técnicas de análisis para evaluar los atributos de calidad que imparte una arquitectura a un sistema. Técnicas basadas en el escenario de proporcionan uno de los enfoques más generales y eficaces para la evaluación de una arquitectura. La metodología más madura se encuentra en el método de análisis de equilibrio de arquitectura (ATAM) del capítulo 11, mientras que el método de análisis de beneficio (CBAM) de costo del capítulo 12 proporciona el vínculo crítico a las implicaciones económicas de las decisiones de la arquitectura.

Aplicación basada en la arquitectura

Esta actividad se ocupa de mantener los desarrolladores fiel a las estructuras y protocolos de interacción limitada por la arquitectura. Tener una arquitectura explícita y bien comunicada es el primer paso para garantizar la conformidad de arquitectura. Es mejor tener un entorno o infraestructura que ayuda activamente a los desarrolladores en la creación y mantenimiento de la arquitectura (en lugar de sólo el código).

Garantizar la conformidad de una arquitectura

Por último, cuando se crea y se utiliza una arquitectura, entra en una fase de mantenimiento. Una vigilancia constante es necesaria para asegurar que la arquitectura real y su representación permanecen fieles a unos a otros durante esta fase. Aunque la labor en esta esfera es comparativamente inmadura, ha habido intensa actividad en los últimos años. Capítulo 10 (reconstrucción de arquitecturas de Software) va a presentar el estado actual de recuperarse de una arquitectura de un sistema existente y garantizar que se ajusta a la arquitectura especificada.

1.3 ¿Por qué una "Buena" arquitectura?¿Si es cierto que, habida cuenta de los mismos requisitos técnicos para un sistema, dos arquitectos diferentes en diferentes organizaciones producirá diferentes arquitecturas, cómo podemos nosotros determinar si cada uno de ellos es el correcto?

No existe tal cosa como una arquitectura inherentemente buena o mala. Arquitecturas tampoco son más o menos aptos para algunos propósitos indicados. Una arquitectura de tres niveles distribuidos cliente-servidor puede ser sólo el billete para el sistema de gestión financiera de empresas de gran tamaño pero totalmente equivocada para una aplicación de aviónica. Una arquitectura cuidadosamente para lograr alta modificabilidad no tiene sentido para un prototipo de tirar. Uno de los mensajes de este libro es que de hecho pueden evaluarse arquitecturas — uno de los grandes beneficios de prestar atención a ellos, pero sólo en el contexto de objetivos concretos.

No obstante, existen reglas que se deben seguir al diseñar una arquitectura. Incumplimiento de cualquiera de estos no significa automáticamente que la arquitectura se ser fatalmente defectuosa, pero por lo menos sirva como una señal de advertencia que debe investigarse.

Dividimos nuestras observaciones en dos clústeres: procesar las recomendaciones y las recomendaciones de producto (o estructurales). Nuestras recomendaciones de proceso son las siguientes:

La arquitectura debe ser el producto de un arquitecto o un pequeño grupo de arquitectos con un líder identificado.

El arquitecto (o el equipo de arquitectura) debe tener los requisitos funcionales para el sistema y una lista articulada, con prioridad de calidad atributos (por ejemplo, seguridad o modificabilidad) que la arquitectura es espera satisfacer.

La arquitectura debe ser bien documentada, con al menos una vista estática y una vista dinámica (que se explica en el capítulo 2), utilizando una notación de acuerdo en que todas las partes interesadas puedan entender con un esfuerzo mínimo.

La arquitectura se distribuya a los actores del sistema, que deben participar activamente en su examen.

La arquitectura debe ser analizada para medidas cuantitativas aplicables (por ejemplo, rendimiento máximo) y formalmente evaluada para los atributos de calidad antes de que sea demasiado tarde hacer cambios en ella.

La arquitectura debe prestarse a implementación incremental a través de la creación de un sistema de "esqueleto" en que se ejercen las rutas de comunicación, pero que al principio tiene una funcionalidad mínima. Este sistema esquelético, a continuación, puede utilizarse para "crecer" el sistema de forma incremental, facilitar la integración y pruebas de esfuerzos (véase el capítulo 7, sección 7.4).

La arquitectura debe resultar en una serie de zonas de contención de recursos, la resolución de los cuales claramente especificada, distribuida y mantiene específica (y pequeña). Por ejemplo, si la utilización de la red es un área de preocupación, el arquitecto debe producir (y hacer cumplir) para cada directrices de equipo de desarrollo que dan lugar a un mínimo

de tráfico de red. Si el rendimiento es una de las preocupaciones, los arquitectos deben producir (y hacer cumplir) presupuestos de tiempo para los subprocesos principales.

Nuestras reglas estructurales son las siguientes:

La arquitectura debería figurar módulos bien definidos cuyas responsabilidades funcionales se asignan en los principios de la clandestinidad de la información y la separación de preocupaciones. Los módulos de ocultación de la información deben incluirlas que encapsular la idiosincrasia de la infraestructura informática, aislantes, por tanto, la mayor parte del software de cambio deben el cambio de infraestructura.

Cada módulo debe tener una interfaz bien definida que encapsula u "oculta" aspectos pueden cambiables (por ejemplo, aplicación estrategias y datos de estructura selecciones) de otro software que utilice sus instalaciones. Estas interfaces deberían permitir que sus equipos de desarrollo respectivas trabajar en gran medida de forma independiente.

Atributos de calidad deberían lograrse usando tácticas arquitectónicos conocidos específicos para cada atributo, como se describe en el capítulo 5 (logro de cualidades).

La arquitectura nunca debería depender de una versión determinada de una herramienta o producto comercial. Si depende de un producto comercial en particular, debería estructurarse tal que el cambio a un producto diferente es simple y de bajo costo.

Módulos que producen datos deberán ser independientes de módulos que consumen datos. Esto tiende a aumentar modificabilidad debido a cambios a menudo se limitan a la producción o el lado de consumo de los datos. Si se agregan datos nuevos, ambas partes tendrán que cambiar, pero la separación permite el upgrade (incremental) puesta en escena.

Para los sistemas de procesamiento en paralelo, la arquitectura debe cuentan con procesos bien definidos o tareas que no reflejan necesariamente la estructura de descomposición de módulo. Es decir, de procesos pueden subprocesos a través de más de un módulo; un módulo puede incluir procedimientos que se invocan como parte de más de un proceso (el caso de estudio de A-7E del capítulo 3 es un ejemplo de emplear este principio).

Cada tarea o proceso se debe escribir para que su asignación a un procesador específico puede modificarse fácilmente, tal vez incluso en tiempo de ejecución.

La arquitectura debe cuentan con un pequeño número de patrones de interacción simple (véase el capítulo 5). Es decir, el sistema debe hacer las mismas cosas de la misma manera en todo. Esto ayuda en la comprensibilidad, reducir el tiempo de desarrollo, aumentar la confiabilidad y mejorar la modificabilidad. También mostrará integridad conceptual en la arquitectura, que, si bien no mensurable, lleva a suavizar el desarrollo.

Como se examen los casos prácticos de este libro, con éxito, cada uno de los cuales resuelve un problema arquitectónico desafiante, es útil ver cuántos de ellos seguido cada una de estas reglas. Este conjunto de reglas no es ni completa ni absoluta, pero puede servir

como un guidepost para un arquitecto a partir de avanzar en un problema de diseño de la arquitectura.

.4 Resumen

En este capítulo, nos mostró que la arquitectura es más que el resultado de los requisitos funcionales para un sistema. También es el resultado de fondo del arquitecto, el entorno técnico en las que vive el arquitecto y objetivos de negocio de la organización patrocinadora. A su vez, la arquitectura influye el entorno que lo había generado mediante la adición de su presencia para el entorno técnico y dando el negocio nuevas posibilidades de marketing. Hemos introducido el ciclo de negocio de arquitectura como el motivo para este libro, pero el lector debe tener en cuenta que la ABC como se describe aquí se extenderá en capítulos posteriores.

Por último, nos propuso un conjunto de reglas que generalmente llevan a arquitecturas de éxito.

A continuación, pasamos nuestra atención a la arquitectura de software, por sí misma.

Capítulo 2. ¿Qué es la arquitectura de Software?con Linda Northrop

Nota: Linda Northrop es un director de programa en el Instituto de ingeniería de Software de la Universidad de Carnegie Mellon.

Si un proyecto no ha logrado una arquitectura de sistema, incluyendo su fundamento, el proyecto no proceda a desarrollo de sistemas a gran escala. Especificación de la arquitectura como una entrega permite su uso en todo el proceso de desarrollo y mantenimiento.

— Barry Boehm [Boehm 95]

En el capítulo 1, se explicó que la arquitectura desempeña un papel fundamental que permite a una organización lograr sus metas de negocios. Arquitectura comandos un precio (el coste de su desarrollo cuidado), pero paga por sí mismo generosamente al permitir a la Organización alcanzar sus objetivos de sistema y ampliar sus capacidades de software. La arquitectura es un activo que contiene el valor tangible a la organización en desarrollo más allá del proyecto para el que fue creado.

En este capítulo se tratará en arquitectura estrictamente desde un punto de vista de la ingeniería de software. Es decir, vamos a explorar el valor que una arquitectura de software aporta a un proyecto de desarrollo, además del valor devuelto a la empresa en la forma descrita en el capítulo 1.

2.1 Qué es la arquitectura de Software y lo que no es

Figura 2.1, tomado de una descripción del sistema para una simulación acústica submarina, pretende describir ese "nivel superior arquitectura" del sistema y es precisamente el tipo de diagrama que se muestra más a menudo para ayudar a explicar una arquitectura. ¿Exactamente qué podemos decir de ella?

Figura 2.1. Típico, pero indeterminado, presentación de una arquitectura de software

El sistema se compone de cuatro elementos.

Tres de los elementos: modelo de pérdida de Prop (MODP), modelo de reverberación (MODR) y modelo de ruido (MODN), podría tener más en común con cada uno distinto con la cuarta — Control de proceso (CP) — porque se sitúan al lado del otro.

Al parecer todos los elementos tienen algún tipo de relación entre sí, ya que el diagrama está totalmente conectado.

¿Es esto una arquitectura? Asumiendo (como muchas definiciones) que la arquitectura es un conjunto de componentes (de los cuales tenemos cuatro) y conexiones entre ellos (también presente), este diagrama parece llenar el proyecto de ley. ¿Sin embargo, incluso si aceptamos la definición más primitiva, lo podemos no decir del diagrama?

¿Cuál es la naturaleza de los elementos? ¿Cuál es el significado de su separación? ¿Que ejecuten en procesadores separados? ¿Funcionan a veces? ¿Los elementos constan de procesos, programas o ambos? ¿Que representan formas en las que se dividirá el trabajo del proyecto, o que transmiten una sensación de separación de tiempo de ejecución? ¿Son objetos, tareas, funciones, procesos, programas distribuidos o algo más?

¿Cuáles son las responsabilidades de los elementos? ¿Qué es lo que hacen? ¿Cuál es su función en el sistema?

¿Cuál es el significado de las conexiones? ¿Significan las conexiones que los elementos comunican entre sí, controlan unos a otros, envían datos entre sí, utilizan mutuamente, invocan entre sí, sincronizan entre sí, compartan algún secreto de ocultación de información entre sí, o alguna combinación de estas u otras relaciones? ¿Cuáles son los mecanismos para la comunicación? ¿Qué información fluye a través de los mecanismos, cualquiera sea?

¿Cuál es el significado del diseño? ¿Por qué es CP en un nivel separado? ¿Exige a los otros tres elementos, y los otros no se les permite llamarlo? ¿Contiene los otros tres en un sentido de unidad de implementación? ¿O no hay simplemente espacio para poner todos los cuatro elementos en la misma fila en el diagrama?

Hay que levantar estas preguntas porque si no sabemos con precisión cuáles son los elementos y cómo cooperan para lograr el propósito del sistema, diagramas, como no son mucho ayudan y pueden considerarse escepticismo.

Este diagrama no muestra una arquitectura de software, al menos no en cualquier forma útil. La cosa más caridad que podemos decir acerca de los dichos diagramas es que representan un punto de partida. Definimos, ahora, lo que constituye una arquitectura de software:

La arquitectura de software de un programa o sistema informático es la estructura o estructuras del sistema, que constituyen de elementos de software, las propiedades visibles externamente de esos elementos y las relaciones entre ellos.[1]

[1] Es un ligero cambio de la primera edición. Allí los elementos primarios fueron llamados "componentes", un término que desde entonces ha sido estrechamente asociado con el movimiento de la ingeniería de software basado en componentes, tomando un sabor decididamente de tiempo de ejecución. "Elemento" fue elegido aquí para transmitir algo más general.

Propiedades "Visibles externamente" son estos supuestos otros elementos pueden hacer de un elemento, como sus servicios prestados, características de rendimiento, de fallas de manipulación, uso de recursos compartidos y así sucesivamente. Echemos un vistazo a algunas de las implicaciones de esta definición con más detalle.

En primer lugar, la arquitectura define elementos de software. La arquitectura encarna la información acerca de cómo se relacionan entre sí los elementos. Esto significa que específicamente omite cierta información acerca de los elementos que no pertenece a su interacción. Por lo tanto, una arquitectura es sobre todo una abstracción de un sistema que suprime los detalles de los elementos que no afectan a cómo utilizan, son utilizados por, se refieren a o interactuar con otros elementos. En casi todos los sistemas modernos, elementos interactúan entre sí por medio de interfaces que partición detalles acerca de un elemento en público y partes de privado. Arquitectura se refiere a la parte pública de esta

división; detalles privados — los que tienen que ver exclusivamente con la implementación interna — no son arquitectónico.

En segundo lugar, la definición deja en clara que los sistemas pueden y lo componen más de una estructura y que nadie la estructura puede irrefutablemente dicen ser la arquitectura. Por ejemplo, en que todos los proyectos no triviales se dividen en unidades de ejecución; Estas unidades tienen responsabilidades específicas y con frecuencia son la base de las asignaciones de trabajo para la programación de equipos. Este tipo de elemento compone de programas y datos que se puede llamar a software en otras unidades de aplicación o acceso y programas y datos que son privados. En grandes proyectos, estos elementos se subdividen casi seguro para realizar asignaciones a subequipos. Este es un tipo de estructura que se utiliza para describir un sistema. Es muy estática que se centra en la forma de la funcionalidad del sistema es dividida y asignada a los equipos de implementación.

Otras estructuras son mucho más centradas en el camino que los elementos interactúan entre sí en tiempo de ejecución para llevar a cabo la función del sistema. Supongamos que el sistema es construido como un conjunto de procesos paralelos. Los procesos que se darán en tiempo de ejecución, los programas en las distintas unidades de aplicación se ha descrito anteriormente que se encadenan secuencialmente a juntos forma cada proceso, y las relaciones de sincronización entre los procesos constituyen otro tipo de estructura que se utiliza a menudo para describir un sistema.

¿Cualquiera de estas estructuras son solo la arquitectura? No, aunque todos ellos transmiten información arquitectónica. La arquitectura consta de estas estructuras, así como muchos otros. Este ejemplo muestra que puesto que la arquitectura puede incluir más de un tipo de estructura, hay más de un tipo de elemento (por ejemplo, la unidad de ejecución y procesos), más de un tipo de interacción entre elementos (por ejemplo, Subdivisión y sincronización) y aún más de un contexto (por ejemplo, el tiempo de desarrollo frente a tiempo de ejecución). Por la intención, la definición no especifica cuáles son los elementos de la arquitectura y las relaciones. ¿Es un objeto de un elemento de software? ¿Un proceso? ¿Una biblioteca? ¿Una base de datos? ¿Un producto comercial? Puede ser cualquiera de estas cosas y más.

En tercer lugar, la definición implica que cada sistema informático con el software tiene una arquitectura de software, ya que cada sistema puede demostrar que comprenden los elementos y las relaciones entre ellos. En el caso más trivial, un sistema de sí mismo es un único elemento — poco interesante y probablemente nonuseful pero una arquitectura sin embargo. A pesar de que cada sistema tiene una arquitectura, no significa necesariamente que la arquitectura se conoce a nadie. Quizás todas las personas que diseñó el sistema han quedado atrás, ha desaparecido la documentación (o nunca fue producido), el código fuente se ha perdido (o nunca se entregó), y todo lo que tenemos es el código binario de ejecución. Esto revela la diferencia entre la arquitectura de un sistema y la representación de esa arquitectura. Por desgracia, una arquitectura puede existir independientemente de su descripción o especificación, que plantea la importancia de la documentación de la arquitectura (que se describe en el capítulo 9) y la reconstrucción de la arquitectura (que se describen en el capítulo 10).

En cuarto lugar, el comportamiento de cada elemento es parte de la arquitectura, en la medida que el comportamiento puede ser observado o discernir desde el punto de vista de otro elemento. Este tipo de comportamiento es lo que permite que los elementos que interactúan entre sí, que claramente es parte de la arquitectura. Esta es otra razón que los dibujos de líneas y cuadro que se pasan como arquitecturas no son las arquitecturas en absoluto. Son simplemente cuadro de líneas y dibujos — o, para ser más benéficas, que sirven como información sobre el proporcionar más información que explica lo que realmente hacen los elementos que se muestran. Cuando observamos los nombres de los cuadros (base de datos, interfaz gráfica de usuario, ejecutivo, etc.), un lector puede imaginar la funcionalidad y el comportamiento de los elementos correspondientes. Esta imagen mental acerca a una arquitectura, pero surge de la mente del observador y se basa en información que no está presente. No queremos decir que el comportamiento exacto y el rendimiento de cada elemento deben estar documentadas en todas las circunstancias; Sin embargo, en la medida en que comportamiento de un elemento influye en cómo otro elemento deben escribirse en interactuar con él o influye en la aceptabilidad del sistema en su conjunto, este comportamiento es parte de la arquitectura de software.

Por último, la definición es indiferente si la arquitectura de un sistema es una buena o una mala, lo que significa que permitir o impedir que el sistema de cumplir su comportamiento, requerimientos de performance y ciclo de vida. No aceptaremos como la mejor forma para elegir una arquitectura para un sistema de ensayo y error — es decir, una arquitectura de picking al azar, creación del sistema de ella y con la esperanza de los mejores, por lo que se plantea la importancia de la evaluación (capítulos 11 y 12) de la arquitectura y diseño de la arquitectura (capítulo 7).

2.2 Otros puntos de vistaArquitectura de software es un creciente pero aún joven disciplina; por lo tanto, no tiene ninguna definición única y aceptada. Por otra parte, no hay escasez de definiciones. La mayoría de los comúnmente distribuido es consistente en sus temas: estructura, los elementos y las conexiones entre ellos, pero varían ampliamente en los detalles y no son intercambiables.

El estudio de arquitectura de software ha evolucionado mediante observación de los principios de diseño que siguen a los diseñadores y las acciones que se toman cuando se trabaja en sistemas reales. Es un intento para abstraer los elementos comunes inherentes al diseño del sistema, y como tal debe tener en cuenta una amplia gama de actividades, los conceptos, métodos, enfoques y resultados. Por esa razón, otras definiciones de arquitectura están presentes en la comunidad de ingeniería de software, y porque es probable que encuentro algunos de ellos, debe comprender sus implicaciones y poder discutirlas. Algunas de las definiciones más a menudo oído siguen.

La arquitectura es el diseño de alto nivel. Esto es cierto, en el sentido de que un caballo es una especie de mamífero, pero los dos no son intercambiables. Otras tareas asociadas con diseño no son arquitectónicas, como decidir sobre las estructuras de datos importantes que se encapsular. La interfaz para esas estructuras de datos es decididamente una preocupación arquitectónica, pero su elección real no es.

La arquitectura es la estructura general del sistema. Este estribillo común (incorrectamente) implica que los sistemas tienen pero una estructura. Sabemos que esto es falso, y, si alguien toma esta posición, es por lo general entretenido pedir la estructura que quieren decir. El punto tiene más de importancia pedagógica. Como veremos más tarde, las diferentes estructuras proporcionan los puntos críticos de apalancamiento ingeniería imbuir un sistema con los atributos de calidad que se representará un éxito o el fracaso. La multiplicidad de las estructuras en una arquitectura se encuentra en el corazón del concepto.

La arquitectura es la estructura de los componentes de un programa o sistema, sus interrelaciones y los principios y directrices que rigen su diseño y evolución en el tiempo. Esta es una de varias definiciones centrado en el proceso que incluyen información auxiliar, como los principios y directrices. Muchas personas afirman que la arquitectura incluye una declaración de las necesidades de las partes interesadas y una justificación de cómo esas necesidades. Estamos de acuerdo en que la recopilación de dicha información es esencial y una cuestión de buena práctica profesional. Sin embargo, no consideramos parte de la arquitectura de por sí más de lo que el manual de un propietario de un automóvil es parte del coche. Cualquier sistema posee una arquitectura que puede descubrir y analizar independientemente de cualquier conocimiento del proceso por el cual la arquitectura fue diseñada o evolucionada.

La arquitectura es componentes y conectores. Conectores implican un mecanismo de tiempo de ejecución para la transferencia de control y datos alrededor de un sistema. Por lo tanto, esta definición se concentra en las obras arquitectónicas de tiempo de ejecución. Una tubería de UNIX es un conector de, por ejemplo. De este modo no-el tiempo de ejecución de ciudadanos de segunda clase de estructuras arquitectónicas (por ejemplo, la división estática en unidades responsables de la aplicación que se explicó anteriormente). No son de segunda clase, pero son tan fundamental para la satisfacción de los objetivos del sistema. Cuando se habla de "relaciones" entre elementos, tenemos la intención de capturar las relaciones tanto en tiempo de ejecución y en tiempo de ejecución de no.

En la raíz de todo el debate acerca del software de la arquitectura es un enfoque en el razonamiento acerca de los problemas estructurales del sistema. Y aunque la arquitectura se usa a veces en el sentido de un cierto patrón arquitectónico, como el cliente y el servidor y a veces hace referencia a un campo de estudio, tales como un libro sobre la arquitectura, más a menudo se utiliza para describir aspectos estructurales de un sistema en particular. Eso es lo que hemos tratado de capturar en nuestra definición.

2.3 Arquitectónicos patrones, modelos de referencia y arquitecturas de referenciaEntre líneas y cuadro de bocetos que son el amparo de inicio puntos y arquitecturas de pleno derecho, con toda la información adecuada acerca de un sistema rellenado, se encuentran una serie de fases intermedias. Cada etapa representa el resultado de un conjunto de decisiones arquitectónicas, el enlace de opciones de arquitectura. Algunas de estas fases intermedias son muy útiles en su propio derecho. Antes de examinar las estructuras arquitectónicas, definimos tres de ellos.

Un patrón de arquitectura es una descripción de los tipos de elemento y relación junto con un conjunto de restricciones sobre cómo se puede utilizar. Un patrón puede considerarse como un conjunto de restricciones en una arquitectura — sobre los tipos de elemento y sus patrones de interacción — y las restricciones de estas definen un conjunto o la familia de arquitecturas que satisfacerlas. Por ejemplo, el cliente y el servidor es un modelo arquitectónico común. Cliente y el servidor son dos tipos de elemento, y su coordinación se describe en términos de protocolo que utiliza el servidor para comunicarse con cada uno de sus clientes. Uso del término cliente-servidor sólo implica que existen varios clientes; no se identifican los clientes propios, y no hay ningún debate de qué funcionalidad, distintos de la implementación de los protocolos, se ha asignado a cualquiera de los clientes o al servidor. Las arquitecturas de innumerables son del modelo cliente-servidor bajo esta definición (informal), pero son diferentes entre sí. Un patrón de arquitectura es una arquitectura de no, entonces, pero aún transmite una imagen útil del sistema — que impone restricciones útiles en la arquitectura y, a su vez, en el sistema.

Uno de los aspectos más útiles de los patrones es que exhiben los atributos de calidad conocidos. Por eso, el arquitecto elige un modelo concreto y no uno al azar. Algunos patrones representan soluciones conocidas a problemas de rendimiento, otros prestan bien a los sistemas de alta seguridad, aún otros se han utilizado con éxito en sistemas de alta disponibilidad. Elegir un modelo arquitectónico es a menudo la primera opción de grandes del diseño del arquitecto.

El estilo arquitectónico de término también ha sido ampliamente utilizado para describir el mismo concepto.

Un modelo de referencia es una división de funcionalidad junto con el flujo de datos entre las piezas. Un modelo de referencia es un estándar de la descomposición de un problema conocido en partes que cooperativamente resolver el problema. A partir de experiencia, modelos de referencia son una característica de dominios maduros. ¿Puede que usted nombre las partes estándar de un compilador o un sistema de gestión de base de datos? ¿Puede explicar en términos generales cómo las partes trabajan juntos para lograr su propósito colectivo? Si es así, es porque ha aprendido un modelo de referencia de estas aplicaciones.

Una arquitectura de referencia es un modelo de referencia que se asignan a los elementos de software (que forma cooperativa implementan la funcionalidad definida en el modelo de referencia) y los datos fluyen entre ellos. Considerando que un modelo de referencia divide la funcionalidad, una arquitectura de referencia es la asignación de esa funcionalidad en una descomposición del sistema. La asignación puede ser, pero no necesariamente es, uno a uno. Un elemento de software puede implementar parte de una función o varias funciones.

Modelos de referencia, patrones arquitectónicos y arquitecturas de referencia no son arquitecturas; son conceptos útiles que los elementos de un architure de la captura. Cada uno es el resultado de las primeras decisiones de diseño. En la figura 2.2 se muestra la relación entre estos elementos de diseño.

Figura 2.2. Las relaciones de modelos de referencia, patrones de arquitectura, arquitecturas de referencia y arquitecturas de software. (Las flechas indican que los conceptos siguientes contienen más elementos de diseño).

A menudo la gente toma analogías a otros usos de la arquitectura de la palabra, sobre el que tienen alguna intuición. Lo asocian comúnmente arquitectura con estructura física (edificios, calles, hardware) y disposición física. Un arquitecto del edificio debe diseñar un edificio que proporciona la accesibilidad, la estética, la luz, la capacidad de mantenimiento y así sucesivamente. Arquitecto de software debe diseñar un sistema que proporciona la concurrencia, portabilidad, modificabilidad, facilidad de uso, seguridad y similares, y refleja el examen de las compensaciones entre estas necesidades.

Analogías entre edificios y sistemas de software no deben tomarse demasiado lejos, en la medida que se descomponen rápidamente. Por el contrario, nos ayuden a comprender que la perspectiva del espectador es importante y esa estructura puede tener diferentes significados en función de la motivación para el análisis de TI. Una definición precisa de la arquitectura de software es no casi tan importante como lo que investigar el concepto permite que hagamos.

2.4 ¿Por qué es importante la arquitectura de Software?Capítulo 1 había cubierta la importancia de la arquitectura en la empresa. En este capítulo, nos enfocamos en por qué importa la arquitectura desde una perspectiva técnica. En ese contexto, hay fundamentalmente tres razones para importantance la arquitectura de software.

Comunicación entre las partes interesadas. Arquitectura de software representa una abstracción común de un sistema que la mayoría si no todos los participantes del sistema pueden utilizar como base para la comunicación, negociación, consenso y entendimiento mutuo.

Principios de las decisiones de diseño. Arquitectura de software manifiesta las primeras decisiones de diseño acerca de un sistema, y estos enlaces principios tienen un peso mucho fuera de proporción con su gravedad individual con respecto a su vida de mantenimiento, su despliegue y el desarrollo del sistema restantes. También es el punto más temprano en que diseño se pueden analizar las decisiones que rigen el sistema a construirse.

Abstracción transferible de un sistema. Arquitectura de software constituye un modelo para la estructura de un sistema y cómo funcionan en conjunto sus elementos relativamente pequeño y intelectualmente llegar, y este modelo es transferible a través de sistemas. En particular, se puede aplicar a otros sistemas exhibiendo el atributo de calidad similar y requisitos funcionales y puede promover la reutilización a gran escala.

A su vez abordará con cada uno de estos puntos.

LA ARQUITECTURA ES EL VEHÍCULO PARA LA COMUNICACIÓN DE LAS PARTES INTERESADASCada participante de un sistema de software: cliente, usuario, Administrador de proyectos, codificador, tester etc. — se ocupa de las características de los diferentes sistemas que se ven afectadas por la arquitectura. Por ejemplo, el usuario se refiere a que el sistema es fiable y disponible cuando sea necesario; el cliente está preocupado de que la arquitectura puede aplicarse en programación y presupuesto; el administrador está preocupado (así como acerca de costo y la programación) que la arquitectura le permite a los equipos trabajar en gran medida de forma independiente, interactuando en disciplinados y controlado de formas. El arquitecto está preocupado acerca de estrategias para alcanzar todos estos objetivos.

La arquitectura proporciona un lenguaje común en el que diferentes preocupaciones puedan expresó, negociados y resolverse en un nivel que sea manejable intelectualmente incluso para sistemas grandes y complejos (consulte la barra lateral, lo que sucede cuando presione este botón?). Sin dicha lengua, es difícil de entender grandes sistemas lo suficiente como para hacer las primeras decisiones que influyen en la calidad y utilidad. Análisis de la arquitectura, como veremos en la tercera parte, tanto que dependerán de este nivel de comunicación y lo mejora.

ARQUITECTURA MANIFIESTA EL CONJUNTO MÁS TEMPRANO DE LAS DECISIONES DE DISEÑOArquitectura de software representa el conjunto primer de un sistema de decisiones de diseño. Estas decisiones principios son los más difíciles de obtener correcta y la más difícil de cambiar más adelante en el proceso de desarrollo, y tienen los efectos de mayor alcance.

La arquitectura define restricciones sobre la aplicaciónUna implementación exhibe una arquitectura si es conforme a las decisiones de diseño estructural descritas por la arquitectura. Esto significa que la aplicación debe estar dividida en los elementos prescritos, los elementos deben interactuar entre sí en el modo indicado, y cada elemento debe cumplir su responsabilidad a los demás como dictada por la arquitectura.

Las decisiones de asignación de recursos también restringen las implementaciones. Estas decisiones pueden ser invisibles para implementadores trabajando en elementos individuales. Las restricciones permiten una separación de las preocupaciones que permite a las decisiones de gestión hacer el mejor uso del personal y la capacidad computacional. Constructores de elemento deben ser fluidas en la especificación de sus elementos

individuales pero no en arquitectura de soluciones de compromiso. Por el contrario, arquitectos no tienen que ser expertos en todos los aspectos de diseño de algoritmos o las complejidades del lenguaje de programación, pero son ellos los responsables de los tratos arquitectónicos.

La estructura organizativa de dictados de arquitecturaNo sólo arquitectura prescribe la estructura del sistema que se está desarrollado, pero esa estructura se convierte en grabado en la estructura del proyecto de desarrollo (y a veces, como se menciona en el capítulo 1, la estructura de la organización). El método normal para dividir el trabajo en un gran sistema consiste en asignar a diferentes grupos de diferentes partes del sistema para construir. Esto se llama la estructura de descomposición del trabajo de un sistema. Dado que la arquitectura del sistema incluye la descomposición de más alto nivel del sistema, por lo general se usa como base para la estructura de desglose de trabajo, que a su vez dicta unidades de planificación, programación y presupuesto; interteam canales de comunicación; Organización del sistema de control y archivo de configuración; planes de integración y pruebas y procedimientos; y es minucias incluso tales como cómo está organizada la intranet del proyecto y el número de equipo de picnics allí. Equipos de comunicarán entre sí en términos de las especificaciones de interfaz a los elementos más importantes. La actividad de mantenimiento, cuando se inicia, también reflejará la estructura del software, con equipos formados para mantener los elementos estructurales específicos.

Un efecto secundario de establecer la estructura de desglose de trabajo es congelar algunos aspectos de la arquitectura de software. Un grupo que es responsable de uno de los subsistemas resistirán a tener sus responsabilidades que se distribuye a través de otros grupos. Si estas responsabilidades han sido formalizadas en una relación contractual, se cambian con el puede ser caro. Seguimiento de los progresos en un conjunto de tareas que se está distribuyendo también se hace mucho más difícil.

Una vez la arquitectura ha sido acordada, a continuación, es casi imposible, por razones de gestión y de negocios, para modificarlo. Se trata de un argumento (entre muchos) para la realización de una evaluación completa antes de la congelación de la arquitectura de software para un sistema de gran tamaño.

La arquitectura inhibe o permite atributos de calidad de un sistemaSi un sistema será capaz de exhibir su deseado (o requieren) atributos de calidad sustancialmente está determinado por su arquitectura. Capítulo 5 se profundizan en la relación entre arquitecturas y calidad con más detalle, pero por el momento tenga en mente la siguiente:

Si su sistema requiere de alto rendimiento, que necesita administrar el comportamiento basada en tiempos de elementos y la frecuencia y el volumen de comunicación baja-frecuencia.

Si modificabilidad es importante, es necesario asignar responsabilidades a los elementos tal que los cambios en el sistema no tienen consecuencias de largo alcance.

Si el sistema debe ser altamente seguro, que necesita para administrar y proteger la comunicación baja-frecuencia y qué elementos pueden acceder a la información. Puede que también deba introducir elementos especializados (por ejemplo, un núcleo de confianza) en la arquitectura.

Si usted cree que será necesario escalabilidad en su sistema, usted tiene que localizar cuidadosamente la utilización de recursos para facilitar la introducción de reemplazos de mayor capacidad.

Si su proyecto necesita entregar subconjuntos incrementales del sistema, debe administrar con cuidado uso inter-component.

Si desea que los elementos del sistema debe ser reutilizables en otros sistemas, debe restringir el acoplamiento baja-frecuencia para que al extraer un elemento no sale con demasiados archivos adjuntos a su entorno actual para ser útil.

Las estrategias para estos y otros atributos de calidad son supremamente arquitectónicas. Es importante comprender, sin embargo, que la arquitectura por sí sola no puede garantizar la funcionalidad o la calidad. Pobres decisiones de diseño o implementación aguas abajo siempre pueden socavar una adecuada arquitectónica

Predicción de cualidades de sistema mediante el estudio de la arquitectura¿Es posible decir que las correspondientes decisiones arquitectónicas se han hecho (por ejemplo, si el sistema exhibirá sus atributos de calidad requerida) sin tener que esperar hasta que el sistema es desarrollar e implementar? Si la respuesta no, la selección de una arquitectura sería una tarea sin esperanza: selección aleatoria llevaría a cabo, así como cualquier otro método. Afortunadamente, es posible hacer predicciones de calidad sobre un sistema basado exclusivamente en una evaluación de su arquitectura. Técnicas de evaluación de la arquitectura, como la arquitectura de contrapartida análisis método de capítulo 11 apoyan una visión de arriba hacia abajo en los atributos de calidad de los productos de software que se hace posible (y restringido) por arquitecturas de software.

La arquitectura facilita la razón sobre y administrar el cambioLa comunidad de desarrollo de software está llegando a enfrentarse con el hecho de que aproximadamente el 80 por ciento del costo de un sistema de software común se produce después de la implementación inicial. Un corolario de esta estadística es que la mayoría de los sistemas que la gente trabaja en está en esta fase. Muchos, si no la mayoría de programadores y diseñadores nunca trabajan en el desarrollo de nuevos — que trabajan bajo las restricciones del cuerpo del código existente. Sistemas de software cambian con sus vidas; lo hacen tan a menudo y a menudo con dificultad.

Cada arquitectura particiones posibles cambios en tres categorías: arquitectura locales y no locales. Un cambio local se puede lograr mediante la modificación de un solo elemento. Un cambio no local requiere múltiples modificaciones de elemento pero deja el enfoque de la arquitectura subyacente intacto. Un cambio de arquitectura afecta a las formas fundamentales en los que los elementos interactúan entre sí: el patrón de la arquitectura — y probablemente requerirá cambios en el sistema. Obviamente, los cambios locales son los

más deseables, y por lo tanto una arquitectura eficaz es uno en que los cambios más probable es que también son los más fáciles de hacer.

Decidir cuando cambios son esenciales, determinar qué trazados de cambio tienen el menor riesgo, evaluar las consecuencias de los cambios propuestos y arbitrar secuencias y las prioridades para los cambios solicitados todos requieren amplios conocimientos sobre relaciones, rendimiento y comportamientos de los elementos de software de sistema. Estos son en la descripción del trabajo de un arquitecto. Razonamiento acerca de la arquitectura puede proporcionar la información necesaria para tomar decisiones acerca de los cambios propuestos.

La ayuda de arquitectura en prototipos evolutivosUna vez que se ha definido una arquitectura, puede ser analizado y prototipo como un sistema esquelético. Esto ayuda el proceso de desarrollo de dos maneras.

El sistema es ejecutable principios de ciclo de vida del producto. Su fidelidad aumenta como prototipo partes son reemplazados por versiones completas del software. Estas partes de prototipo pueden ser una versión de baja fidelidad de la funcionalidad final, o pueden ser sustitutos que consumen y producen datos a las tasas apropiadas.

Un caso especial de tener el ejecutable del sistema temprano es que los posibles problemas de rendimiento pueden identificarse a principios de ciclo de vida del producto.

Cada uno de estos beneficios reduce el riesgo en el proyecto. Si la arquitectura es parte de una familia de sistemas relacionados, se puede distribuir el costo de crear un marco para la creación de prototipos sobre el desarrollo de muchos sistemas.

La arquitectura permite más preciso del coste y estimaciones de programaciónLas estimaciones de costo y la programación son una importante herramienta de gestión que permiten al administrador a adquirir los recursos necesarios y a comprender si un proyecto está en problemas. Estimaciones de costos basados en la comprensión de las piezas del sistema son, inherentemente, más precisos que los basados en el conocimiento global del sistema. Como hemos dicho, la estructura organizativa de un proyecto se basa en su arquitectura. Cada equipo será capaz de hacer estimaciones más precisas para su pieza que una voluntad de administrador de proyecto y sentirá más propiedad en la toma de las estimaciones se hacen realidad. En segundo lugar, la definición inicial de una arquitectura significa que los requisitos para un sistema han sido revisados y, en cierto sentido, validado. El más conocimiento sobre el ámbito de aplicación de un sistema, más preciso las estimaciones.

ARQUITECTURA COMO UN MODELO TRANSFERIBLES, REUTILIZABLECuanto antes en el ciclo de vida es de reutilización aplicado, mayor será el beneficio que se puede lograr. Mientras que la reutilización de código es beneficioso, reutilización en el plano arquitectónico proporciona un enorme influencia para sistemas con requerimientos similares. No sólo puede utilizarse el código pero puede por lo tanto los requisitos que condujo a la arquitectura en primer lugar, así como la experiencia de la construcción de la arquitectura de volver a utilizarse. Cuando decisiones arquitectónicas se puede volver a

utilizarse en múltiples sistemas, también se transfieren todas las consecuencias de decisión temprana que acabo de describir.

Las líneas de productos de software comparten una arquitectura comúnUna línea de productos de software o la familia es un conjunto de sistemas de software de uso intensivo, compartir un conjunto común y administrado de funciones que satisfacen las necesidades específicas de un segmento de mercado en particular o la misión y que se desarrollan en un conjunto común de activos básicos de forma prescrita. Principal entre los activos de estos centrales es la arquitectura que fue diseñada para manejar las necesidades de toda la familia. Arquitectos de línea de producto Elija una arquitectura (o una familia de arquitecturas estrechamente relacionadas) que se sirven todos imaginado miembros del producto línea al tomar decisiones de diseño que se aplican a toda la familia temprano y haciendo otras decisiones que se aplican sólo a los miembros individuales de la tarde. La arquitectura define lo que es fijo para todos los miembros de la línea de productos y lo que es variable. Las líneas de productos de software representan un enfoque poderoso para el desarrollo de múltiples sistemas que muestra el orden de magnitud recompensas en el tiempo al mercado, costos, productividad y calidad de los productos. La potencia de la arquitectura se encuentra en el corazón del paradigma. Similar a otras inversiones de capital, la arquitectura para una línea de productos se convierte en activo del núcleo de una organización en desarrollo. Las líneas de productos de software se explican en el capítulo 14, y estudios de caso de líneas de productos se dan en capítulos 15 y 17.

Los sistemas pueden construirse usando elementos grandes, desarrollados desde el exteriorConsiderando que los paradigmas de software anteriores se centraron en la programación como la principal actividad, con el progreso que se mide en líneas de código, a menudo en desarrollo basado en la arquitectura se centra en componer o montaje de elementos que están probables que se han desarrollado por separado, incluso independientemente, unos de otros. Esta composición es posible porque la arquitectura define los elementos que pueden ser incorporados en el sistema. Limita el posible de los reemplazos (o adiciones) de acuerdo con cómo interactúan con su medio ambiente, cómo recibir y renunciar al control, qué datos que consumen y productos, cómo acceden a los datos y qué protocolos que se utilizan para la comunicación y el intercambio de recursos.

Uno de los aspectos clave de la arquitectura es la organización de la estructura del elemento, interfaces y conceptos operativos. El principio más importante de esta organización es la capacidad de intercambio. En 1793, producción en masa de Eli Whitney de mosquetes, basado en el principio de piezas intercambiables, marcó el comienzo de la era Industrial. En los días anteriores mediciones fiables de físicas, ésta era una noción de enormes proporciones. Hoy en día en software, hasta abstracciones pueden ser confiable delimitados, la noción de intercambiabilidad estructural es sólo como desalentadora y sólo tan significativo.

Componentes disponibles en el mercado comerciales, subsistemas y las interfaces de comunicaciones compatible que todos dependen el principio de la capacidad de intercambio. Sin embargo, hay mucho acerca del desarrollo de software a través de la composición que sigue sin resolverse. Cuando los componentes que son candidatos para la importación y la reutilización son distintos subsistemas que se han construido con

supuestos arquitectónicos conflictivos, complicaciones imprevistas pueden aumentar el esfuerzo necesario para integrar sus funciones. David Garlan y sus colegas acuñó el desajuste de término arquitectónico para describir esta situación.

Menos es más: Paga restringir el vocabulario de alternativas de diseñoTal como se recogen los patrones arquitectónicos útiles y patrones de diseño, es evidente que, a pesar de que los programas informáticos pueden combinarse de manera más o menos infinito, hay algo que ganar restringiendo voluntariamente nosotros mismos a un número relativamente pequeño de opciones cuando se trata de programa de cooperación y la interacción. Es decir, queremos minimizar la complejidad del diseño del sistema que estamos construyendo. Las ventajas de este enfoque incluyen reutilización mejorada, más regulares y más simples diseños que son más fácilmente comprensibles y comunicados, mayor capacidad análisis, menor tiempo de selección y una mayor interoperabilidad.

Propiedades del diseño de software siguen desde la elección del patrón arquitectónico. Patrones que son más convenientes para un problema particular deberían mejorar la aplicación de la solución de diseño resultante, tal vez, haciéndolo más fácil arbitrar el conflicto de las limitaciones de diseño, mediante el aumento de conocimientos sobre los contextos de diseño muy poco, o ayudando a superficies incoherencias en las especificaciones de requisitos.

Una arquitectura permite el desarrollo basado en la plantillaUna arquitectura encarna diseño decisiones acerca de cómo elementos interactúan que, si bien se refleja en la aplicación de cada elemento, pueden ser localizadas y escritas una sola vez. Plantillas pueden utilizarse para capturar en un solo lugar los mecanismos de interacción baja-frecuencia. Por ejemplo, una plantilla puede codificar las declaraciones de área pública de un elemento donde se dejará resultados o pueden codificar los protocolos que el elemento se utiliza para colaborar con el Ejecutivo de sistema. Un ejemplo de un conjunto de decisiones arquitectónicas firmes, lo que permite el desarrollo basado en la plantilla se debatirá en el capítulo 8.

Una arquitectura puede ser la base para la formaciónLa arquitectura, incluyendo una descripción de cómo elementos interactúa para llevar a cabo el comportamiento requerido, puede servir como la introducción al sistema para los nuevos miembros del proyecto. Esto refuerza nuestro punto de que uno de los usos importantes de la arquitectura de software es apoyar y fomentar la comunicación entre las diversas partes interesadas. La arquitectura es un punto de referencia común.

2.5 VISTAS Y ESTRUCTURAS ARQUITECTÓNICAS

El neurólogo, el ortopedista, el hematólogo y el dermatólogo todos tienen una opinión diferente de la estructura de un cuerpo humano. Oftalmólogos, cardiólogos y los podólogos concentran en subsistemas. El Kinesiólogo y psiquiatra se ocupan de diferentes aspectos de la conducta de los arreglos todos. Aunque estas opiniones se muestra de forma diferente y

tienen propiedades muy diferentes, todos están intrínsecamente relacionados: juntos que describen la arquitectura del cuerpo humano.

Por lo que es con el software. Los sistemas modernos son más de lo suficientemente complejos como para que sea difícil captarles todos a la vez. En su lugar, restringimos nuestra atención en un momento dado a uno o un pequeño número de las estructuras del sistema software. Para comunicarse de manera significativa sobre una arquitectura, debemos dejar claro qué estructura o estructuras que estamos debatiendo en este momento: vista que estamos llevando a cabo de la arquitectura.

Utilizaremos la estructura de términos relacionados y la vista cuando se habla de la representación de la arquitectura. Una vista es una representación de un conjunto coherente de elementos arquitectónicos, como está escrito por y leídos por los actores del sistema. Se trata de una representación de un conjunto de elementos y las relaciones entre ellos. Una estructura es el conjunto de elementos, tal como existen en software o hardware. Por ejemplo, una estructura de módulo es el conjunto de módulos del sistema y su organización. Una vista del módulo es la representación de dicha estructura, como lo documenta y utilizado por algunas partes interesadas del sistema. Estos términos a menudo se utilizan indistintamente, pero se adhieran a estas definiciones.

Estructuras arquitectónicas en general pueden dividirse en tres grupos, dependiendo el carácter amplio de los elementos que se muestran.

Módulo de estructuras. Aquí los elementos son módulos, que son las unidades de ejecución. Módulos representan una forma basada en código de considerar el sistema. Se asignan a las áreas de responsabilidad funcional. Hay menos énfasis en cómo el software resultante manifiesta en tiempo de ejecución. Módulo de estructuras nos permiten responder a preguntas como ¿qué es la responsabilidad funcional asignada a cada módulo? ¿Qué otros elementos de software de un módulo puede utilizar? ¿Qué otro software ¿utiliza realmente? ¿Qué módulos están relacionadas con otros módulos por generalización o especialización (es decir, herencia) relaciones?

Estructuras de componente y el conector. Aquí los elementos son componentes de tiempo de ejecución (que son las principales unidades de computación) y conectores (que son los vehículos de comunicación entre componentes). ¿Estructuras de componente y el conector ayudar a responder preguntas tales como lo que son los principales componentes de la ejecución y cómo interactúan? ¿Cuáles son los principales datos compartidos almacena? ¿Qué partes del sistema se replican? ¿Cómo does progresan los datos a través del sistema? ¿Qué partes del sistema pueden ejecutar en paralelo? ¿Cómo puede cambiar la estructura del sistema como se ejecuta?

Estructuras de asignación. Estructuras de asignación muestran la relación entre los elementos de software y de los elementos en uno o varios entornos externos en el que se crea y se ejecuta el software. Responden a preguntas como ¿qué procesador cada elemento de software ejecutar en? ¿En qué archivos está construyendo cada

elemento almacenado durante el desarrollo, pruebas y sistema? ¿Qué es la asignación de elementos de software para equipos de desarrollo?

Estas tres estructuras corresponden a los tres tipos generales de decisión que implica el diseño de la arquitectura:

¿Cómo es el sistema estructurarse como un conjunto de unidades de código (módulos)?

¿Cómo es el sistema estructurarse como un conjunto de elementos que tienen interacciones (conectores) y comportamiento de tiempo de ejecución (componentes)?

¿Cómo es el sistema que se refieren a las estructuras nonsoftware en su entorno (es decir, CPUs, sistemas de archivos, redes, equipos de desarrollo, etc.)?

ESTRUCTURAS DE SOFTWAREEn la figura 2.3 se muestran algunas de las estructuras de software más comunes y útil. Éstas se describen en las secciones siguientes.

MóduloLas siguientes las estructuras basadas en el módulo.

Descomposición. Las unidades son módulos relacionados entre sí por la relación "es un submódulo de", que muestra cómo más grandes módulos se descomponen en recursivamente de los más pequeño hasta que estén lo suficientemente pequeños para ser fácil de entender. Los módulos de esta estructura representan un punto de

partida común para el diseño, como el arquitecto enumera lo que tendrá que hacer las unidades de software y asigna cada elemento a un módulo para el posterior diseño (más detallado) y eventual aplicación. Módulos a menudo tienen asociados productos (es decir, las especificaciones de interfaz, código, probar planes, etc..). La estructura de descomposición proporciona una gran parte de la modificabilidad del sistema, asegurándose de que probable que los cambios son de la competencia de como máximo unos pequeños módulos. A menudo se utiliza como base para de organización el desarrollo del proyecto, incluyendo la estructura de la documentación y sus planes de integración y prueba. Las unidades de esta estructura a menudo tienen nombres específicos de la organización. Ciertas normas del Departamento de defensa de Estados Unidos, por ejemplo, definen elementos de configuración de Software de ordenador (CSCIs) y componentes de Software de ordenador (células madre cancerosas), que son unidades de descomposición modular. En el capítulo 15, vamos a ver grupos de funciones de sistema y funciones del sistema como las unidades de descomposición.

Uso. Las unidades de esta estructura importante pero se pasa por alto también son módulos, o (en circunstancias cuando lo justifique un grano más fino) procedimientos o recursos en las interfaces de módulos. Las unidades están relacionadas por la relación de usos. Una unidad utiliza otro si la corrección de la primera requiere la presencia de una versión correcta (en lugar de un stub) de la segunda. La estructura de usos se utiliza para el ingeniero de sistemas que pueden ser fácilmente extendido para agregar funcionalidad o subconjuntos funcionales útiles desde el que se pueden extraer fácilmente. La capacidad fácilmente subconjunto un sistema de trabajo permite desarrollo incremental, una disciplina de compilación potente que se tratarán más detalladamente en el capítulo 7.

En capas. Cuando las relaciones de usos de esta estructura son cuidadosamente controladas en forma particular, surge un sistema de capas, en el que una capa es un conjunto coherente de funcionalidad relacionada. En una estructura estrictamente en capas, la capa n sólo puede usar los servicios de capa n-1. Muchas variaciones de esto (y una disminución de esta restricción estructural) se producen en la práctica, sin embargo. Las capas son a menudo diseñadas como abstracciones (máquinas virtuales) que se ocultan los detalles de implementación por debajo de las capas superiores, engendrando portabilidad. Vamos a ver las capas en los estudios de caso de los capítulos 3, 13 y 15.

Clase, o generalización. Las unidades de módulo en esta estructura se denominan clases. La relación es "hereda-de" o "es-an-instancia-." Esta vista es compatible con el razonamiento acerca de las colecciones de un comportamiento similar o capacidad (es decir, las clases que heredan de otras clases de) y parametrizadas diferencias que son capturadas por subclasificación. La estructura de clase nos permite razonar sobre la reutilización y la adición incremental de funcionalidad.

Componente y el conectorEstas estructuras incluyen lo siguiente.

Proceso, o procesos de comunicación. Al igual que todas las estructuras de componente y el conector, éste es ortogonal a las estructuras basadas en el módulo y se ocupa de los aspectos dinámicos de un sistema en ejecución. Las unidades de aquí son procesos o hilos que están conectados entre sí por las operaciones de comunicación, sincronización y exclusión. La relación en esto (y en todas las estructuras de componente y el conector) es adjunto, que muestra cómo los componentes y conectores están enganchados juntos. La estructura del proceso es importante para ayudar a ingeniero de disponibilidad y rendimiento de ejecución de un sistema.

Concurrencia. Esta estructura de componente y el conector permite el arquitecto determinar oportunidades de paralelismo y las ubicaciones donde se produzcan contención de recursos. Las unidades son componentes y los conectores son "hilos de lógicas". Un subproceso lógico es una secuencia de computación que se puede asignar a un subproceso físico independiente más adelante en el proceso de diseño. La estructura de la concurrencia se utiliza principios de diseño para identificar los requisitos para la gestión de las cuestiones relacionadas con la ejecución simultánea.

Datos compartidos, o repositorio. Esta estructura consta de componentes y conectores que creación, almacenan y acceder a datos persistentes. Si el sistema está estructurado, de hecho, alrededor de uno o más depósitos de datos compartidos, esta estructura es una buena para iluminar. Muestra cómo los datos es producidos y consumidos por elementos de software de tiempo de ejecución, y se puede utilizar para garantizar el buen rendimiento y la integridad de los datos.

Cliente y el servidor. Si el sistema está construido como un grupo de cooperantes de clientes y servidores, esto es una buena estructura de componente y el conector para iluminar. Los componentes son los clientes y servidores, y los conectores son protocolos y mensajes que comparten para llevar a cabo la labor del sistema. Esto es útil para la separación de preocupaciones (con soporte modificabilidad), para la distribución física y para (soporte de tiempo de ejecución rendimiento) de equilibrio de carga.

AsignaciónLas siguientes estructuras de asignación.

Despliegue. La estructura de implementación muestra cómo el software se asigna a los elementos de procesamiento de hardware y de la comunicación. Los elementos son rutas de comunicación, entidades (procesadores) de hardware y software (generalmente un proceso desde una vista de componente y el conector). Las relaciones son "asignado a," que muestra en qué unidades físicos residen los elementos de software, y "migra-a," si la asignación es dinámica. Esta vista permite a un ingeniero para razonar sobre la integridad de los datos, rendimiento, disponibilidad y seguridad. Es de particular interés en sistemas distribuidos o paralelos.

Implementación. Esta estructura muestra cómo se asignan los elementos de software (por lo general módulos) para el archivo structure(s) en el desarrollo, integración o entornos de control de la configuración del sistema. Esto es crítico para la gestión de las actividades de desarrollo y procesos de construcción.

Asignación de trabajo. Esta estructura asigna la responsabilidad de la aplicación y la integración de los módulos a los equipos de desarrollo adecuadas. Disponer de una estructura de asignación de trabajo como parte de la arquitectura hace claro que la decisión sobre quién hace el trabajo tiene arquitectónica, así como las consecuencias de la gestión. El arquitecto sabrá la experiencia necesaria en cada equipo. También, en proyectos de gran desarrollo distribuido multi-de origen, la estructura de asignación de trabajo es el medio para llamadas unidades de compatibilidad funcional y asignarlos a un solo equipo, en lugar de haberlos implementado todas las personas que las necesita.

Tabla 2.1 se resumen las estructuras de software. La tabla muestra el significado de los elementos y las relaciones en cada estructura y le dice a lo que cada estructura podría ser utilizado para.

Estructura del software Las relaciones Útil paraDescomposición

Es un submódulo de; secreto de accion

Asignación de recursos y la estructuración de proyectos y la planificación; información de ocultar, encapsulación; control de configuración

Aunque a menudo pensamos acerca de la estructura de un sistema en términos de su funcionalidad, hay propiedades del sistema además de funcionalidad, como la distribución física, proceso de comunicación y sincronización, que debe ser considerado en un nivel arquitectónico. Cada estructura proporciona un método para razonar sobre algunos de los atributos de calidad pertinentes. La estructura de usos, por ejemplo, debe diseñarse (no simplemente grabado) para construir un sistema que puede ser fácilmente ampliado o contratado. La estructura del proceso está diseñada para eliminar los interbloqueos y reducir los cuellos de botella. La estructura de descomposición del módulo está diseñada para producir sistemas modificables y así sucesivamente. Cada estructura proporciona al arquitecto con una visión diferente en el sistema y un punto de apalancamiento diferentes para el diseño.

ESTRUCTURAS RELACIONADAS ENTRE SÍCada una de estas estructuras proporciona un identificador de perspectiva y diseño diferente en un sistema, y cada uno de ellos es válida y útil en sí mismo. Si bien las estructuras de sistema diferentes perspectivas, no son independientes. Elementos de uno estará relacionada con elementos de otros, y necesitamos razonar sobre estas relaciones. Por ejemplo, un módulo en una estructura de descomposición puede manifestarse como uno, como parte de uno o como varios componentes en una de las estructuras de componente y el conector, lo que refleja su alter ego de tiempo de ejecución. En general, las asignaciones entre las estructuras son muchos a muchos.

Proyectos individuales a veces considere la posibilidad de una estructura dominante y emitidos a otras estructuras, cuando sea posible, en términos de lo. A menudo, aunque no siempre, la estructura dominante es la descomposición de módulo. Esto es por una buena razón: tiende a generar la estructura del proyecto. Escenarios, descritos en el capítulo 4, son útiles para el ejercicio de una estructura determinada, así como sus conexiones a otras estructuras. Por ejemplo, un ingeniero de software que desean hacer un cambio en la estructura del cliente y el servidor de un sistema tendría que considerar las opiniones de proceso e implementación porque mecanismos de cliente y el servidor por lo general incluyen procesos y subprocesos, y distribución física podría involucrar los mecanismos de control diferentes que se utilizaría si los procesos fueron dirección en un solo equipo. Si necesitan cambiar los mecanismos de control, la vista en capas o módulo de descomposición tendría que considerarse para determinar el alcance de los cambios.

No todos los sistemas merecen consideración de muchas estructuras arquitectónicas. Cuanto mayor sea el sistema, más dramática las diferencias entre estas estructuras tienden a ser; Sin embargo, para los pequeños sistemas a menudo conseguimos con menos. En lugar de trabajar con cada una de varias estructuras de componente y el conector, un solo uno hará. Si hay un único proceso, entonces la estructura del proceso se contrae en un único nodo y no necesita llevarse a través del diseño. Si va a no haber ninguna distribución (es decir, si hay sólo un procesador), a continuación, la estructura de implementación es trivial y no deben considerarse más.

Estructuras representan los principales puntos de apalancamiento de ingeniería de una arquitectura. Estructuras individuales traen consigo el poder manipular uno o más atributos de calidad. Representan un enfoque de separación de preocupaciones potente para la creación de la arquitectura (y, más tarde, para analizarlo y explicarlo a los interesados). Y, como veremos en el capítulo 9, las estructuras que el arquitecto ha elegido como ingeniería de puntos de apalancamiento también son los principales candidatos para la base de la documentación de la arquitectura.

¿QUÉ ESTRUCTURAS PARA ELEGIR?Hemos descrito brevemente una serie de estructuras arquitectónicas útiles y hay muchos más. ¿Los que debería funcionar un arquitecto en? ¿Las que deben el arquitecto documento? Seguramente no todos de ellos.

No hay escasez de asesoramiento. En 1995, Philippe Krutchen [Krutchen 95] publicó un libro muy influyente en la que se describe el concepto de arquitectura que comprende estructuras separadas y asesoró a concentrarse en cuatro. Para confirmar que las estructuras no estaban en conflicto con otras y juntos en realidad describió un sistema que cumpla sus requisitos, Krutchen aconseja con casos de uso clave como un cheque. Este enfoque llamado "Cuatro más uno" se hizo popular y ahora se ha institucionalizado como base conceptual para el proceso racional unificado. Cuatro vistas del Krutchen siguen:

Lógica. Los elementos son "abstracciones claves," que se manifiestan en el mundo orientado a objetos como objetos o clases de objetos. Esta es una vista de módulo.

Proceso. Este punto de vista aborda la concurrencia y distribución de funcionalidad. Es una vista de componente y el conector.

Desarrollo. Esta vista muestra la organización de los módulos de software, bibliotecas, subsistemas y unidades de desarrollo. Es una vista de asignación, software de asignación para el entorno de desarrollo.

Física. Este punto de vista mapas de otros elementos en nodos de procesamiento y comunicación y también es una vista de asignación (que otros llaman la vista de la implementación).

Al mismo tiempo esencialmente que Krutchen publicó su trabajo, Soni, Nord y Hofmeister [Soni 95] publicó un papel influyente en la que informaron de las estructuras puestas en uso en muchos proyectos por los arquitectos de software en su organización. Sus opiniones fueron conceptuales, módulo de interconexión, la ejecución y código. Una vez más, estos se asignan claramente a los modelos de módulo, componente y el conector y asignación.

Seguido de otros autores, y la lista de las estructuras disponibles crece cada vez más rica. Por supuesto, no debe utilizar todos ellos a pesar de que la mayoría de ellos de hecho va a existir en el sistema que se va a crear. En cambio, consideran que una de las obligaciones del arquitecto es comprender cómo las diversas estructuras conducen a atributos de calidad y, a continuación, elija los que mejor le proporcionará esos atributos. Este punto se tratará con mayor detalle en el capítulo 9, sobre representación arquitectónica.

2.6 ResumenEste capítulo define la arquitectura de software y también introdujo los conceptos

conexos de modelo de referencia, la arquitectura de referencia y patrón arquitectónico. Hemos explicado por qué arquitectura es un concepto fundamentalmente útil en ingeniería de software, en términos de las percepciones de principios proporciona en el sistema, la comunicación permite que entre las partes interesadas y el valor que se proporciona como un activo reutilizable. Todos estos temas se ampliará en los capítulos siguientes.

Nuestra definición de la arquitectura deja claro que los sistemas comprenden muchas estructuras. Mostramos varios de los más comúnmente utilizan en las estructuras y explicaron cómo cada uno sirve como una ingeniería aprovechar el punto en el proceso de diseño.

El siguiente capítulo es el primer estudio de caso del libro. Su propósito es mostrar la utilidad de diferentes estructuras arquitectónicas en el diseño de un sistema complejo.

2.7 Para lecturas adicionalesLos primeros trabajos de David Parnas puso gran parte de la base conceptual de lo que se convirtió en el estudio de arquitectura de software (consulte la barra lateral arquitectura Déjà Vu). Un lector por excelencia de Parnas incluiría su artículo fundacional sobre información ocultar [Parnas 72], así como sus trabajos sobre el programa de familias [Parnas 76], las estructuras inherentes a los sistemas de software [Parnas 74] y la introducción de la estructura de usos para crear subconjuntos y superconjuntos de sistemas [Parnas 79]. Todos estos documentos pueden encontrarse en la colección más fácilmente accesible de sus documentos importantes [Hoffman 00].

Patrones de arquitectura de software han sido ampliamente catalogados en arquitectura de Software de Pattern-Oriented [96 Buschmann, Schmidt 00].

Los proyectos de documentos de principios sobre puntos de vista arquitectónicos como el usado en el desarrollo industrial son [Soni 95] y [Krutchen 95]. El primero se convirtió en un libro [Hofmeister 00] que presenta un panorama completo de opiniones como se utiliza en el desarrollo y análisis. Este último se convirtió en el proceso racional unificado, sobre el que no hay escasez de referencias, tanto en papel como en línea. Una buena es [Krutchen 00].

Una discusión de mismatch arquitectónico se encuentran en Garlan y otros [Garlan 95]. Barry Boehm [Boehm 95] analiza la problemática de proceso de arquitectura de software.

Página Web de arquitectura del Instituto de ingeniería de Software software [SEI ATA] proporciona una amplia variedad de recursos de arquitectura de software y de vínculos, incluyendo una amplia colección de definiciones del término.

Paulish [Paulish 02] trata sobre la relación entre el costo y la programación a la existencia de una arquitectura.

Capítulo 3. Sistema de aviónica de A-7E: un estudio de caso en el uso de estructuras arquitectónicas

Estructura de tiempo de ejecución de un programa orientado a menudo tiene poco que ver con su estructura de código. La estructura de código está congelada en tiempo de compilación; consta de las clases en las relaciones de herencia fijo. Estructura de tiempo de ejecución de un programa consiste en rápida evolución de las redes de comunicación de objetos. De hecho, las dos estructuras son en gran medida independientes. Tratando de [comprender] una de la otra es como tratar de comprender la dinámica de los ecosistemas de la vida de la taxonomía estática de plantas y animales y viceversa.

: Gamma e., r. Helms, r. Johnson y j. Vlissides [Gamma 95]

En el capítulo 2, declaramos que la arquitectura de software describe los elementos de un sistema y las relaciones entre ellos. También destacamos que cada sistema tiene muchos tipos de elementos y que diferentes estructuras arquitectónicas son útiles, incluso necesario, presentar una imagen completa de la arquitectura de un sistema. Cada estructura se centra en un aspecto de la arquitectura.

Este capítulo presentará un estudio de caso de una arquitectura diseñada por la ingeniería y la especificación de tres estructuras arquitectónicas específicas: módulo de descomposición, usos y proceso. Vamos a ver cómo estas estructuras complementan mutuamente para proporcionar una imagen completa de cómo funciona el sistema, y vamos a ver cómo ciertas cualidades del sistema se ven afectados por cada uno. La tabla 3.1 se resumen las tres estructuras que vamos a debatir.

3.1 Relación con el ciclo de negocio de arquitecturaLa figura 3.1 muestra el ABC, lo que se refiere al sistema de aviónica A-7E descrito en este capítulo. El sistema fue construido a partir de 1977 para los aviadores navales que volaron el avión A-7E y fue pagados por la Armada de los Estados Unidos. La organización en desarrollo fue el grupo de ingeniería de software en el laboratorio de Investigación Naval de los Estados Unidos. Los desarrolladores crean el software para probar su creencia de que ciertas estrategias de ingeniería de software (en este caso, información de ocultar y cooperando procesos secuenciales) eran apropiadas para alto rendimiento embedded sistemas en tiempo real.

Figura 3.1. La ABC como la se refiere a los sistemas de aviónica de A-7E

Los arquitectos incluyen uno de los autores de este libro y uno de los líderes en el desarrollo de principios de ingeniería de software, pero los arquitectos tenían poca experiencia en el dominio de la aviónica, aunque tienen acceso a otros sistemas de aviónica y a expertos en aviónica. No hubo ningún compilador disponibles para la plataforma de destino.

Comenzaremos explicando la aplicación, lo que hace el sistema, qué cualidades son importantes para lograr y papel del software en la realización de tareas del sistema.

3.2 Requisitos y cualidadesFigura 3.2 muestra el A-7E Corsair II. Es un avión monoplaza, con base en portaaviones de ataque utilizado por la Marina de los Estados Unidos a lo largo de la década de 1960, los años 70 y los 80. Una versión anterior, el C A-7, fue uno de los primeros aviones en el mundo en ser equipado con un ordenador de bordo para ayudar a la prueba piloto con la navegación y la "entrega de armas" (el eufemismo militar para atacar un blanco de la tierra).

Figura 3.2. Un A-7E Corsair II.Utilizado con permiso y bajo derechos de autor de Squadron/Signal Publications, Inc.

Equipo incorporado del A-7E es una máquina de IBM de pequeña, especiales para los que no exista ningún compilador; la programación es en lenguaje ensamblador sólo. El equipo tiene registros especiales conectados a los convertidores de analógico a digital y digital a analógica que dejarlo recibir y enviar datos a los dispositivos de casi dos docenas de aviónica de la aeronave.

En términos generales, el software de A-7E es responsable de leer sensores y actualización muestra de cabina que ayudan a la prueba piloto soltar las armas en un objetivo. Realmente, el software de A-7E no vuelan los aviones, como lo hacen los sistemas más modernos de la aviónica.

Los siguientes son los sensores principales el software Lee y gestiona:

Un sondeo de aire que las medidas de presión barométrica y velocidad del aire.

Un radar con visión de futuro que puede tener como objetivo en acimut y elevación y devuelve el rango de línea recta hasta el punto sobre el terreno en el que se indica.

Un radar Doppler que informa de la velocidad y el ángulo de desviación (la diferencia entre la dirección en la que es puntiaguda nariz de la aeronave y la dirección en la que se mueve sobre el terreno).

Un conjunto de medición inercial (IMS) que informa aceleraciones a lo largo de cada uno de los tres ejes ortogonales. El software debe leer estas aceleraciones de manera oportuna e integrarlos con el tiempo para obtener velocidades, y deben integrar las velocidades con el tiempo para obtener la posición actual del avión en el mundo físico. También debe administrar la alineación y compensar por la deriva de los ejes para mantenerlos al norte, señaló este y vertical, respectivamente, para que las mediciones con exactitud corresponden a marco de referencia la aeronave.

Una interfaz al sistema de medición inercial del portaaviones, a través del cual el avión puede calcular su posición actual, mientras que a bordo del buque.

Sensores que informan que de seis bajo las alas bomba racks de la A-7E mantienen las armas y que de más de 100 tipos de armas en el repertorio de la aeronave son. El

software almacena grandes tablas de los parámetros para cada tipo de arma, que dejarlo a calcular cómo esa arma se mueve a través de la atmósfera en una trayectoria balística de caída libre.

Un altímetro de radar que mide la distancia al suelo.

Los dispositivos de visualización de cabina gestionados por el software incluyen algunas que son sólo para la visualización y otras por que el piloto comunica con el software, como sigue:

Una pantalla de mapa que siempre muestra la ubicación actual de la aeronave moviendo una tira de película de iluminación posterior como viaja en el avión. El piloto puede elegir orientación del mapa para que la parte superior corresponde que el título actual o true hacia el norte.

Una pantalla de mano a mano: un dispositivo que proyecta la información digital y artístico sobre una ventana transparente entre el piloto y el parabrisas. Como posición de cabeza del piloto asume fijo y conocido, la pantalla puede utilizarse para superponer información sobre el mundo real, tales como la posición de destino o una línea que muestra la dirección de la aeronave del viaje.

Un teclado y un trío de windows de la pequeña pantalla alfanumérica. Con el teclado, el piloto puede solicitar aproximadamente cien tipos de información digital desde el equipo. Un banco de switches en el panel de control de equipo permite el piloto elegir la navegación deseada y modalidades de entrega de armas.

Varias luces y diales y una señal acústica.

El piloto comunica la ubicación de un destino de la tierra (o un punto de referencia de navegación) del software en varias formas, entre ellas las siguientes:

Incrustación en su latitud y la longitud mediante el teclado

Torre del mapa con una palanca de mando hasta sus coordenadas son bajo el punto de mira del centro y, a continuación, "designándolo" al presionar un botón especial en la palanca

Con el objetivo del radar con visión de futuro al punto y designándolo

Torre un símbolo especial en la pantalla de la mano a mano hasta que superpone el punto de interés sobre el terreno y, a continuación, designándolo

El software proporciona, a continuación, información de navegación (la dirección, la distancia, la hora de ir) y señales direccionales en la pantalla de mano a mano que tomar el avión para la ubicación designada.

El piloto puede elegir entre más de dos docenas modos de navegación, basados en qué sensores son más confiables en las condiciones del momento. El software tiene por lo menos cinco formas directas e indirectas para calcular la altura actual del avión, incluyendo un esquema trigonométrico utilizando el ángulo de rango y elevación del radar con visión de futuro como componentes de un triángulo (véase la figura 3.3). Hay más de 20 modos de entrega de armas, todos exigentes en términos de los cálculos en tiempo real (repetidos 25 veces por segundo) sea necesario para mantener el A-7E del bombardeo de precisión.

Figura 3.3. Cálculo de la altitud de la A-7E

A-7Es fueron retirados del servicio activo en la década de 1980, pero combatientes de la generación actual cuentan con una pantalla de mano a mano y modos de entrega y la navegación de armas que muestran una fuertes influencian del corsario.

La arquitectura que presentaremos en este capítulo no es la arquitectura del software original, sino que para que un proyecto de rediseño iniciado por ingenieros de software Marina utilizando el A-7E como un proyecto de demostración para sus ideas (consulte la barra lateral sobre el proyecto A-7). Las cualidades que se esperaba que el sistema de software han incluido rendimiento en tiempo real y modificabilidad para cambios esperados. En particular, los requisitos de rendimiento se declaró en términos de actualizaciones por segundo de muestra y cálculos de entrega de armas de la A7-E. Los requisitos de modificabilidad tratan de realizar cambios en las armas, la plataforma, la simbología en la pantalla y la adición de una entrada nueva a través del teclado.

3.3 Arquitectura para el sistema de aviónica de A-7ELa arquitectura del sistema de aviónica de A-7E se centra alrededor de tres estructuras arquitectónicas, debatidas en el capítulo 2:

Descomposición, una estructura de módulos

Utiliza, una estructura de módulos

Proceso, una estructura de componentes y conectores

A su vez se tratará con cada uno de ellos.

ESTRUCTURA DE DESCOMPOSICIÓNA menos que un programa es lo suficientemente pequeño para ser producida por un programador único, debemos pensar cómo el trabajo se divide en unidades que pueden ser implementadas por separado y el modo en que se relacionarán los módulos. La unidad de la estructura de descomposición es, por supuesto, el módulo. Un módulo puede considerarse como la definición de un grupo de procedimientos, algunos públicos y algunos privados, además de un conjunto de estructuras de datos privados. La relación entre módulos en la estructura de descomposición es "es-a-submódulo-de" o "acciones-a-secreto-con."

Antes de 1977, rendimiento era el objetivo fundamental de los sistemas incrustados (como muchos otros). El objetivo de los diseñadores de A-7E era equilibrar el rendimiento con modificabilidad y demostrar que era posible lograr modificabilidad sin comprometer el rendimiento.

Ocultación de informaciónLa descomposición de módulo de A-7E se basa en ocultar información. Una táctica de arquitectura revisará en el capítulo 5, ocultación de obras por encapsular los detalles del sistema que puedan cambiar de forma independiente en diferentes módulos de información. La interfaz de un módulo revela sólo aquellos aspectos que considera poco probable que el cambio; los detalles ocultados por la interfaz del módulo son secretos del módulo.

Por ejemplo, si un dispositivo como un sensor de altitud del avión es probable que sustituir durante la vida de un programa de aviónica, el principio de ocultación de información hace que los detalles de interactuar con el dispositivo el secreto de un módulo. La interfaz con el módulo proporciona una abstracción del sensor, consistente en tal vez de un solo programa que devuelve el valor más reciente medido por el sensor, porque todos los sensores de reemplazo probablemente compartan esta capacidad. Si alguna vez se sustituye el sensor, sólo las partes internas de ese módulo deben cambiar; el resto del software no se ve afectado.

Ocultación de información se aplica al exigir que los módulos interactúan sólo a través de un conjunto definido de instalaciones públicas — sus interfaces. Cada módulo proporciona un conjunto de procedimientos de acceso, que puede ser llamado por cualquier otro módulo

en el sistema. Los procedimientos de acceso proporcionan los medios sólo entre para interactuar con la información encapsulada en un módulo.

Por supuesto, esto es la filosofía de diseño basado en objetos, con una diferencia clave: mientras que los objetos son creados a partir de los objetos físicos inherentes a la aplicación o dibuja de ideas intuitivas acerca del sistema, información-ocultar módulos se derivan mediante los cambios al software que se percepción como probable que durante tiempo de vida del sistema de catalogación.

Puede consistir en un módulo de submódulos, o se puede considerar una unidad de implementación. Si contiene submódulos, se ofrece una guía para su subestructura. La descomposición en su diseño y submódulos se continúa hasta que cada módulo es lo suficientemente pequeño como para ser descartado y comenzado de nuevo si el programador le asignado abandona el proyecto.

Objetivos específicos de la descomposición del módulo son los siguientes:

Estructura de cada módulo debería ser suficientemente simple ser entendido plenamente.

Es posible cambiar la implementación de un módulo sin conocimiento de la aplicación de otros módulos y sin afectar el comportamiento de los demás módulos.

La facilidad de hacer un cambio en el diseño debe tener una relación razonable con la probabilidad de que el cambio que se necesita; es posible realizar cambios probablemente sin cambiar cualquier módulo de interfaz; menos probabilidades de cambios pueden implicar cambios en la interfaz pero sólo para módulos que son pequeños y no utilizado. Sólo muy poco probable que los cambios deben exigir cambios en las interfaces de módulos ampliamente utilizados.

Es posible hacer un software importante cambio como un conjunto de cambios independientes de módulos individuales (es decir, excepto para los cambios en la interfaz, los programadores de cambiar los módulos individuales no es necesario para comunicarse). Si no se revisan las interfaces de módulo, es posible ejecutar y probar cualquier combinación de viejas y nuevas versiones del módulo.

La documentación de la estructura de descomposición a veces se llama a una guía de módulo. Define las responsabilidades de cada uno de los módulos declarando las decisiones de diseño que se encapsular por ella. Su objetivo es evitar la duplicación y lagunas, para lograr la separación de preocupaciones, y, sobre todo, para ayudar a un encargado de averiguar qué módulos se ven afectados por un problema de un informe o solicitud de cambio.

La Guía de los Estados de los criterios utilizados para asignar una responsabilidad particular de un módulo y organiza los módulos de tal forma que podamos encontrar la información necesaria sin buscar a través de la documentación no relacionada. Refleja la estructura del árbol de la estructura de descomposición, dividiendo el sistema en un

pequeño número de módulos y el tratamiento de cada uno de ellos de la misma manera hasta que todos ellos son muy pequeños. Cada nodo de nodo en el árbol representa un módulo compuesto por los módulos representados por sus descendientes. La guía no describe cualquier relación de tiempo de ejecución entre los módulos: no habla acerca de cómo interactúan los módulos entre sí mientras el sistema está ejecutando; más bien, simplemente describe una relación entre las unidades de ejecución que constituyen la fase de diseño de un proyecto de tiempo de diseño.

Aplicar este principio no siempre es fácil. Es un intento de reducir el coste esperado de software anticipando probables cambios. Estas estimaciones se basan necesariamente en la experiencia, conocimiento de la zona de aplicación y la comprensión de la tecnología de hardware y software. Debido a que un diseñador podría no haber tenido todos la experiencia pertinente, procedimientos de evaluación formal fueron usados que fueron diseñadas para aprovechar la experiencia de otros. Tabla 3.2 resume la función de la estructura del módulo en la arquitectura de A-7E.

Tabla 3.2. ¿Cómo la estructura de descomposición del módulo de A-7E logra objetivos de calidad

Objetivo ¿Cómo logróFacilidad de cambio: las armas, la plataforma, la simbología, de entrada

Ocultación de información

Comprender los cambios previstos Procedimiento de evaluación formal para tomar

Asignar los equipos de trabajo para que se redujeron sus interacciones

Módulos estructurados como una jerarquía; cada equipo de trabajo asignado a un módulo de segundo nivel y todos sus descendientes

Estructura de descomposición de módulo de A-7EPara describir la estructura de descomposición del módulo de A-7E y para dar un ejemplo de cómo se documenta una estructura de módulo, proporcionamos los siguientes extractos de la Guía de módulo de software de A-7E. El árbol de descomposición se describe a partir de los tres módulos de más alto nivel. Estos están motivados por la observación de que, en sistemas como el A-7E, cambios tienden a proceden de tres áreas: el hardware con el que el software debe interactuar, el comportamiento visible externamente necesario del sistema y una decisión exclusivamente bajo la jurisdicción del diseñador de software de un proyecto.

Módulo de hardware-ocultar. El módulo de Hardware-ocultar incluye los procedimientos que deben modificarse si cualquier parte del hardware es reemplazado por una nueva unidad con una interfaz de hardware y software diferentes, pero con las mismas capacidades generales. Este módulo implementa hardware virtual, o un conjunto de dispositivos abstractos que son utilizados por el resto del software. Los secretos principales de este módulo son las interfaces de hardware y software. Los secretos secundarios de este

módulo son las estructuras de datos y algoritmos que se utilizan para implementar el hardware virtual. Uno de los submódulos del módulo Hardware-ocultar es el módulo de equipo extendido que oculta los detalles del procesador.

Módulo de comportamiento-ocultar. El módulo de comportamiento-ocultar incluye los procedimientos que deben cambiarse si hay cambios en los requisitos que afectan el comportamiento requerido. Estos requisitos son el secreto principal de este módulo. Estos procedimientos determinan los valores para enviarlos a los dispositivos de salida virtual proporcionados por el módulo de Hardware-ocultar.

Módulo de decisión de software. El módulo de Software decisión oculta las decisiones de diseño de software basados en teoremas matemáticos, físicos hechos y consideraciones de programación como eficiencia algorítmica y precisión. Los secretos de este módulo no se describen en el documento de requisitos. Este módulo se diferencia de los demás módulos en que tanto los secretos y las interfaces están determinadas por los diseñadores de software. Cambios en estos módulos son más probabilidades de ser motivada por un deseo de mejorar el rendimiento o precisión que por cambios impuestos desde el exterior.

La Guía del módulo pasa a explicar cómo los conflictos entre estas categorías (por ejemplo, es una parte de algoritmo requiere del comportamiento o una decisión de software?) son arbitrado por una especificación de requerimientos completa y sin ambigüedades y, a continuación, se proporciona la descomposición de segundo nivel. Las secciones siguientes describen cómo se descompone el módulo de la decisión de Software.

Módulo de tipo de datos de aplicación: El módulo de tipo de datos de aplicación complementa a los tipos de datos proporcionados por el módulo de equipo ampliado con tipos de datos que son útiles para aplicaciones de aviónica y no requieren una implementación dependiente de equipo. Ejemplos de tipos incluyen distancia (útil para altitud), intervalos de tiempo y los ángulos (útiles para la latitud y longitud). Estos tipos de datos se implementan utilizando los tipos de datos numéricos básicos proporcionados por el equipo ampliado; variables de estos tipos se utilizan como si los tipos fueron construidos en el equipo extendido.

Los secretos del módulo de tipo de datos de aplicación son la representación de datos utilizados en las variables y los procedimientos utilizados para implementar operaciones en esas variables. Unidades de medida (por ejemplo, pies, segundos o radianes) forman parte de la representación y están ocultos. En su caso, los módulos ofrecen a los operadores de conversión que ofrecen o aceptan valores reales en las unidades especificadas.

Módulo de banquero de datos: Mayoría de los datos es producida por un módulo y consumida por otro. En la mayoría de los casos, los consumidores deben recibir un valor que es lo más actualizado posible. El tiempo en el que debe calcularse un dato de referencia se determina por propiedades de sus consumidores (por ejemplo, los requisitos de precisión) y por propiedades de su productor (por ejemplo, el costo del cálculo, tasa de cambio de valor). El módulo de banquero de datos actúa como un "intermediario" y determina cuando se calculan los nuevos valores para estos datos.

El módulo de banquero de datos obtiene valores de procedimientos del productor; procedimientos de consumidores obtener datos de los procedimientos de acceso de datos banquero. Los productores y los consumidores de una referencia particular pueden escribirse sin saber cuando se actualiza un valor almacenado. En la mayoría de los casos, debe modificarse ni el productor ni el consumidor si cambia la política de actualización.

El banquero de datos proporciona valores para todos los datos de ese informe sobre el estado interno de un módulo o sobre el estado de la aeronave. El banquero de datos también señales de eventos que implican cambios en los valores que suministra. El banquero de datos se utiliza como consumidores y los productores son módulos separados, incluso cuando son ambos submódulos de un módulo más grande. El banquero de datos no se utiliza si los consumidores requieren a miembros específicos de la secuencia de valores calculados por el productor o un valor producido es únicamente una función de los valores de parámetros de entrada para el procedimiento de producción, tales como sin(x).[1]

[1] El módulo de banquero de datos es un ejemplo de la utilización

La opción entre la actualización de políticas debe basarse en los requisitos de precisión de los consumidores, con qué frecuencia los consumidores requieren el valor, la máxima de esperar que los consumidores puedan aceptar, cuán rápidamente los cambios de valor y el costo de producir un nuevo valor. Esta información es parte de la especificación para el implementador del módulo de banquero de datos.

Módulo de comportamiento de filtro: El módulo de comportamiento de filtro contiene modelos digitales de filtros físicos. Se puede utilizar por otros procedimientos para filtrar datos potencialmente ruidosos. Los secretos principales de este módulo son los modelos utilizados para la estimación de valores basados en valores de ejemplo y las estimaciones de error. Los secretos secundarios son el equipo algoritmos y estructuras de datos que se utiliza para implementar esos modelos.

Módulo de modelos físicos — El software requiere las estimaciones de las cantidades que no se puede medir directamente, pero pueden calcularse de observables mediante modelos matemáticos. Un ejemplo es el tiempo que un arma balístico a huelga el terreno. Los secretos principales del módulo modelos físicos son los modelos; los secretos secundarios son las implementaciones de equipo de esos modelos.

Módulo de herramientas de software: El módulo de herramientas de Software contiene estas rutinas de utilidad que de lo contrario tendría que ser escrita por más de un programador de otro. Las rutinas incluyen funciones matemáticas, monitores de recursos y los procedimientos que la señal cuando todos los módulos han completado su inicialización de puesta en marcha. Los secretos del módulo son las estructuras de datos y algoritmos que se utilizan para implementar los procedimientos.

Módulo de generación de sistema: Los secretos principales del módulo de generación de sistema son decisiones que se posponen hasta el sistema de tiempo de generación. Estos incluyen los valores de parámetros del sistema de generación y la opción entre implementaciones alternativas de un módulo. Los secretos secundarios del módulo de generación de sistema son el método utilizado para generar un formulario de máquina ejecutables del código y la representación de las decisiones aplazadas. Los procedimientos descritos en este módulo no se ejecutan en el equipo incorporado; que se ejecuten en el equipo utilizado para generar el código para el sistema integrado.

La Guía de módulo describe una tercera-(y en algunos casos una cuarta-) descomposición nivel, pero que se ha omitido aquí. Figura 3.4 muestra la estructura de descomposición de la arquitectura de A-7E hasta el tercer nivel. Tenga en cuenta que muchos de los módulos de interfaz de dispositivo tienen los mismos nombres que los módulos del controlador de función. La diferencia es que los módulos de interfaz de dispositivo se programan con conocimiento de la manera en que el software se interrelaciona con los dispositivos; los módulos del controlador de función se programan con el conocimiento de los valores necesarios para ser calculado y enviado a dichos dispositivos. Esto sugiere otra relación arquitectónico que vamos a explorar poco: cómo el software en estos módulos coopera para realizar sus trabajos.

Figura 3.4. La vista de descomposición del módulo de la arquitectura de software de A-7E

Pero la vista de la descomposición de módulo aún no está completa. Recuerda, en el capítulo 2, nuestra definición de la arquitectura como incluyendo la especificación de comportamiento para cada uno de los elementos. Interfaces de independiente del lenguaje cuidadosamente diseñadas son cruciales para mantener la portabilidad y lograr la interoperabilidad. Aquí, cada módulo debe tener una interfaz especificada. Capítulo 9 analiza la documentación para interfaces de software.

En el capítulo anterior, nos comentó que arquitecturas de servir como el modelo para un proyecto en desarrollo, así como para el software. En el caso de la arquitectura de A-7E, esta estructura de descomposición del módulo de segundo nivel se convirtió en consagrados en muchas formas: documentación de diseño, archivos de configuración-controlada en línea, planes de pruebas, programación de equipos, procedimientos de examen y programación de proyectos y hitos todos lo usó como su unidad de referencia.

ESTRUCTURA DE USOSLa segunda estructura más importante de interés en la arquitectura de A-7E es la estructura de usos. La estructura de descomposición lleva a cabo ninguna información sobre la ejecución del software; podría hacer una suposición educada sobre cómo dos procedimientos en diferentes módulos interactuar en tiempo de ejecución, pero esta información no es de hecho en la descomposición del módulo. En su lugar, la estructura de usos suministra la imagen autoritaria de cómo interactúa el software.

La relación de usosEl concepto detrás de la estructura de usos es la relación de usos. Procedimiento a se dice que utilice el procedimiento b si un procedimiento funcionan correctamente b debe estar presente para el procedimiento a para atender sus necesidades. En la práctica, esta relación es similar, pero no exactamente lo mismo que la relación de llamadas. Procedimiento a usualmente llama procedimiento b porque la usa. Sin embargo, aquí tiene dos casos donde los usos y las llamadas son diferentes:

Procedimiento a es simplemente necesario para llamar a procedimiento b en su especificación, pero el futuro cálculo realizado por el no depende de lo que hace B. Procedimiento b debe estar presente para que procedimiento a trabajar, pero no necesita ser correcta. Un llama, pero no utiliza, B. B puede ser un controlador de errores, por ejemplo.

Procedimiento b realiza su función sin que se llama al procedimiento A, pero un usos de los resultados. Los resultados podrían ser un almacén de datos actualizados b deja tras de sí. O b puede ser un manejador de interrupción que a supone que existe y funciones correctamente. A usa, pero no exige, B.

La relación de usos permite la identificación rápida de los subconjuntos funcionales. Si conoce ese procedimiento a que se necesita para estar en el subconjunto, también sabe que todos los procedimientos que a usa deben estar allí. El cierre transitivo de esta relación define el subconjunto. Por lo tanto, vale la ingeniero de esta estructura, imponer una disciplina en la misma, para que todo subconjunto no necesita consisten en todo el sistema. Esto significa especificando una estructura permitió usar para programadores. Una vez finalizada la aplicación, pueden catalogarse los usos reales.

La estructura de unidades de los usos (o permitido usar) es el procedimiento de acceso. Dictando qué procedimientos se les permite utilizar qué otros procedimientos (y, en consecuencia, qué procedimientos no pueden ser utilizados por qué otros procedimientos), se define la estructura de usos.

A pesar de que la unidad de la estructura de usos es un procedimiento, en la práctica todos los procedimientos de un módulo pueden compartir restricciones de uso. Por lo tanto, puede aparecer el nombre de un módulo en la estructura de usos; Si es así, es una abreviación para todos los procedimientos de acceso en ese módulo.

La estructura de usos (permitido usar) es conceptualmente documentada con una matriz binaria; cada fila y columna enumeran todos los procedimientos del sistema. Por lo tanto, si el elemento (m, n) es true, m de procedimiento utiliza (se permite utilizar) n de procedimiento. En la práctica, esto es demasiado complicado y forma abreviada se introdujo en la que se adoptaron normas para todo los módulos (a diferencia de los procedimientos individuales dentro de cada módulo).

3.3 Tabla resume la función de la estructura de usos en la arquitectura de software de A-7E.

Tabla 3.3. ¿Cómo la estructura de usos de A-7E logra objetivos de calidad

Parte 2: Crear una arquitecturaUna parte de este libro presenta el ciclo de negocio de arquitectura (ABC) y sentó las bases para el estudio de arquitectura de software. En particular, exponen las influencias en el trabajo cuando un arquitecto comienza a construir un sistema, y señaló que los requisitos para los atributos de calidad especial tales como el rendimiento o la modificabilidad a menudo proceden de los objetivos de negocio de la organización. Entonces, ¿cómo un arquitecto ¿crea una arquitectura? Es el foco de la segunda parte. Dado que el logro de los atributos de calidad es fundamental para el éxito de un sistema, empezamos con un análisis de calidad y cómo se logra con el contenido de la caja de herramientas del arquitecto.

La calidad es a menudo en el ojo del observador (para parafrasear a Booth Tarkington). Para el arquitecto, esto significa que los clientes pueden no gusta un diseño porque su concepto de calidad es distinto del arquitecto. Escenarios de atributo de calidad son el medio por el cual calidad se mueve desde el ojo del observador a una base más objetiva. En el capítulo 4, exploramos diferentes tipos de calidad que puede ser apropiado para una arquitectura. Para seis atributos importantes (disponibilidad, modificabilidad, rendimiento, seguridad, Testabilidad y facilidad de uso), se describe cómo generar escenarios que pueden utilizarse para caracterizar los requisitos de calidad. Estos escenarios demuestran qué calidad significa para un sistema en particular, dando el arquitecto y el cliente una base para juzgar un diseño.

Conocer los requisitos de calidad, por supuesto, sólo proporciona un objetivo para el arquitecto. En el capítulo 5, enumeramos las herramientas (tácticas y patrones) en el kit del arquitecto que se utilizan para alcanzar los atributos de calidad. Alta disponibilidad, por ejemplo, depende de tener alguna forma de redundancia en datos o código, y esta redundancia genera consideraciones adicionales para el arquitecto (por ejemplo, para asegurar la sincronización entre las repeticiones).

En el capítulo 6, presentamos nuestro segundo estudio de caso: un sistema diseñado para admitir las funciones de control de tráfico aéreo de la Administración Federal de aviación. Este sistema fue diseñado para cumplir requerimientos de ultra alta disponibilidad (menos de cinco minutos el tiempo de inactividad al año) e ilustra las tácticas enumeradas en el capítulo 5.

Escenarios de atributo de calidad y arquitectura de tácticas es algunas de las herramientas disponibles para la creación de una arquitectura. En el capítulo 7, discutimos cómo aplicar estas herramientas en el diseño de una arquitectura y en la construcción de un sistema esquelético, y cómo la arquitectura se refleja en la estructura organizativa.

En el capítulo 8, presentamos nuestro tercer caso de estudio, de simuladores de vuelo. Estos sistemas fueron diseñados para lograr el rendimiento en tiempo real y modificarse fácilmente. Mostramos cómo estos objetivos fueron alcanzados.

Una vez que ha diseñado una arquitectura, deben documentarse. Se trata de una cuestión de documentar en primer lugar las opiniones pertinentes y, a continuación, el material que se extiende más allá de cualquier vista determinada. Capítulo 9 detalla cómo documentar una arquitectura.

Con frecuencia, la arquitectura de un sistema no está disponible, porque nunca se fue documentado, se ha perdido o el sistema de instalación difiere el sistema diseñado. Se discuten en capítulo 10 recuperar la arquitectura de un sistema existente.

Capítulo 4. Atributos de calidad de entendimientocon Felix Bachmann y Mark Klein

Nota: Felix Bachmann y Mark Klein son altos miembros del personal técnico en el Instituto de ingeniería de Software.

"Cheshire-gato," [Alice] comenzó, más bien tímidamente … "Podría decirme, por favor, de qué manera debería ir desde aquí?" "Eso depende mucho en la que desee ir," dijo el gato. "Oh, no sé mucho cuidado donde —" dijo Alicia. A continuación, no importa que forma vaya, "dijo el gato. "— siempre y cuando llegar a alguna parte," dijo Alicia. "¡ Oh, estás seguro hacer eso," dijo el gato, "si sólo caminas durante bastante tiempo."

— Lewis Carroll, Alicia en el país de las maravillas.

Como hemos visto en el ciclo de negocio de arquitectura, consideraciones de negocios determinan cualidades que deben incluirse en la arquitectura de un sistema. Estas cualidades son por encima de la de funcionalidad, que es la declaración básica de las capacidades del sistema, los servicios y el comportamiento. Aunque la funcionalidad y otras cualidades están estrechamente relacionados, como puede ver, funcionalidad con frecuencia tiene no sólo en el asiento delantero en el esquema de desarrollo sino en la sede única. Esto es miope, sin embargo. Sistemas son rediseñados con frecuencia no porque sean funcionalmente deficientes — los reemplazos a menudo son funcionalmente idénticos, pero porque son difíciles de mantener, el puerto, o cambiar la escala, o son demasiado lentas o han estado en peligro por los piratas de la red. En el capítulo 2, dijimos que la arquitectura fue la primera etapa en la creación de software, en cuya calidad podrían abordarse los requisitos. Es la asignación de funcionalidad del sistema en las estructuras de software que determina asistencia la arquitectura de la para las calidades. En el capítulo 5, que hablamos

de cómo se admiten las cualidades por las decisiones de diseño de la arquitectura y en el capítulo 7 discutimos cómo el arquitecto puede administrar el equilibrio inherente a cualquier diseño.

Aquí, nuestro enfoque es en la comprensión de cómo expresar las cualidades que queremos nuestra arquitectura para proporcionar al sistema o sistemas que estamos construyendo desde él. Comenzamos el debate sobre la relación entre los atributos de calidad y arquitectura de software mirando de cerca de atributos de calidad. ¿Qué significa decir que un sistema es modificable o fiable o seguro? En este capítulo se caracteriza estos atributos y explica cómo puede utilizarse esta caracterización para expresar los requisitos de calidad para un sistema.

4.1 La funcionalidad y la arquitecturaAtributos de funcionalidad y calidad son ortogonales. Esta Declaración suena más bien negrita en primer lugar, pero cuando usted pensar en ello te das cuenta de que no puede ser de otra manera. Si no fueron ortogonales atributos de calidad y funcionalidad, la elección de la función dictaría el nivel de seguridad o el rendimiento o la disponibilidad o la facilidad de uso. Claramente sin embargo, es posible elegir independientemente un nivel deseado de cada uno. Ahora, eso no quiere decir que cualquier nivel de cualquier atributo de calidad es alcanzable con cualquier función. Manipulación de imágenes gráficas complejas o una base de datos enorme de clasificación puede ser inherentemente complejo, haciendo imposible la veloz rendimiento. Pero lo que es posible es que, para cualquiera de estas funciones las opciones elegidas como arquitecto determinará el nivel relativo de calidad. Algunas opciones de arquitectura conducirá a un mayor rendimiento; Algunos conducirá en la otra dirección. Habida cuenta de este entendimiento, el propósito de este capítulo es, al igual que con una buena arquitectura, para separar las preocupaciones. Examinará cada atributo de calidad importante a su vez y aprender a pensar en ello de una manera disciplinada.

¿Cuál es la funcionalidad? Es la capacidad del sistema para hacer el trabajo para los que fue concebido. Una tarea requiere que muchas o la mayoría de los elementos del sistema de trabaja de manera coordinada para completar el trabajo, así como autores, electricistas, plomeros, perchas de cartón yeso, pintores, y acabado de carpinteros vienen todos juntos a cooperativamente construir una casa. Por lo tanto, si los elementos no se han asignado las responsabilidades correctas o no han sido dotados de las instalaciones correctas para coordinar con otros elementos (de modo que, por ejemplo, saben cuándo es tiempo para que puedan empezar a su parte de la tarea), el sistema no podrá ofrecer la funcionalidad necesaria.

Funcionalidad se puede lograr mediante el uso de cualquiera de una serie de estructuras posibles. De hecho, si la funcionalidad es el único requisito, el sistema podría existir como un solo módulo monolítico con ninguna estructura interna en absoluto. En su lugar, se descompone en módulos para que sea comprensible y para soportar una variedad de otros fines. De esta manera, la funcionalidad es en gran medida independiente de la estructura. Arquitectura de software restringe su asignación a la estructura cuando otros atributos de calidad son importantes. Por ejemplo, los sistemas se dividen con frecuencia para que

varias personas cooperativamente pueden construir (que es, entre otras cosas, una cuestión de tiempo al mercado, aunque rara vez se declaró esta forma). El interés de funcionalidad es cómo interactúa con y las limitaciones, las otras cualidades.

4.2 La arquitectura y los atributos de calidadLogro de atributos de calidad debe ser considerado a lo largo de diseño, implementación y despliegue. No hay ningún atributo de calidad es depende enteramente de diseño, ni depende enteramente de la aplicación o implementación. Resultados satisfactorios son un asunto de conseguir el panorama general (arquitectura), así como los detalles (aplicación) correctos. Por ejemplo:

Facilidad de uso implica aspectos arquitectónicos y nonarchitectural. Los aspectos nonarchitectural incluyen hacer la interfaz de usuario clara y fácil de usar. ¿Debe proporciona un botón de opción o de una casilla de verificación? ¿Qué diseño de pantalla es más intuitivo? ¿Qué tipo de letra es más claro? Aunque estos detalles son importantes tremendamente para el usuario final y facilidad de uso de influencia, no son arquitectónicos porque pertenecen a los detalles de diseño. Sin embargo es arquitectónico, si un sistema proporciona al usuario con la capacidad de cancelar operaciones, para deshacer las operaciones, o con los datos de reutilización previamente especificados. Estos requisitos incluyen la cooperación de varios elementos.

Modificabilidad se determina por cómo la funcionalidad se divide (arquitectura) y por técnicas dentro de un módulo (nonarchitectural) de codificación. Por lo tanto, un sistema es modificable si cambios implican al menor número posible de elementos distintos. Esta fue la base de la estructura de descomposición del módulo de A-7E en el capítulo 3. A pesar de tener la arquitectura ideal, sin embargo, siempre es posible hacer un sistema difícil modificar mediante la escritura de código oscuro.

Rendimiento consiste en las dependencias de arquitectura y nonarchitectural. Se depende parcialmente de cuánto comunicación es necesaria entre los componentes (arquitectura), parcialmente sobre el tipo de funcionalidad que se ha asignado a cada componente (arquitectura), parcialmente en los recursos compartidos de cómo se asignan (arquitectura), parcialmente en la elección de algoritmos para implementar la funcionalidad seleccionada (nonarchitectural), y parcialmente en cómo estos algoritmos están codificados (nonarchitectural).

El mensaje de esta sección es doble:

1. Arquitectura es fundamental para la realización de muchas cualidades de interés en un sistema, y estas cualidades deben ser diseñadas en y pueden ser evaluadas en el plano arquitectónico.

2. Arquitectura, por sí sola, es incapaz de alcanzar cualidades. Proporciona la base para el logro de la calidad, pero esta Fundación será en vano si no se presta atención a los detalles.

Dentro de los sistemas complejos, atributos de calidad nunca pueden lograrse de manera aislada. El logro de cada uno tendrá un efecto, a veces positivo y a veces negativos, en el logro de los demás. Por ejemplo, seguridad y confiabilidad a menudo existen en un Estado de tensión mutua: el sistema más seguro tiene la menor cantidad de puntos de falla, normalmente un núcleo de seguridad. El sistema más confiable tiene más puntos de falla, normalmente un conjunto de procesos redundantes o procesadores donde el hecho de que cualquiera no hará que el sistema falle. Otro ejemplo de la tensión entre los atributos de calidad es que casi cada atributo de calidad afecta negativamente al rendimiento. Tomar la portabilidad. La principal técnica para el logro de software portable es aislar las dependencias del sistema, que introduce la sobrecarga en la ejecución del sistema, normalmente como límites de proceso o procedimiento, y esto perjudica el rendimiento.

Comencemos nuestro tour de atributos de calidad. Examinaremos las siguientes tres clases:

1. Cualidades del sistema. Nos centraremos en disponibilidad, modificabilidad, rendimiento, seguridad, Testabilidad y facilidad de uso.

2. Cualidades de negocios (por ejemplo, el tiempo de comercialización) que se ven afectados por la arquitectura.

3. Cualidades como integridad conceptual, son acerca de la arquitectura de sí mismo aunque indirectamente afectar otras cualidades, tales como la modificabilidad.

4.3 Atributos de calidad del sistema de

Atributos de calidad del sistema han sido de interés para la comunidad de software por lo menos desde la década de 1970. Hay una variedad de taxonomías publicadas y las definiciones, y muchos de ellos tienen sus propias comunidades de investigación y practicante. Desde la perspectiva de un arquitecto, hay tres problemas con debates anteriores de atributos de calidad de sistema:

Las definiciones proporcionadas para un atributo no están operativas. Tiene sentido decir que un sistema sea modificable. Cada sistema es modificable con respecto a un conjunto de cambios y no modificable con respecto a otro. Los otros atributos son similares.

Un foco de discusión es, a menudo, en cuya calidad un aspecto particular pertenece a. ¿Es un error del sistema un aspecto de la disponibilidad, un aspecto de seguridad o un aspecto de la facilidad de uso? Todas las comunidades de atributo tres reclaman la propiedad de un fallo del sistema.

Cada comunidad de atributo ha desarrollado su propio vocabulario. La comunidad de rendimiento tiene "eventos" llegar a un sistema, la comunidad de seguridad tiene "ataques" de llegar a un sistema, la comunidad de disponibilidad tiene "fallas" de un sistema y la comunidad de usabilidad tiene "usuario de entrada". Todos estos realmente pueden referirse a la ocurrencia misma, pero se describen usando términos diferentes.

Una solución para los dos primeros de estos problemas (definiciones rehusadas y preocuparse de superposición) es utilizar los escenarios de atributo de calidad como medio de caracterizar los atributos de calidad. Una solución para el tercer problema es proporcionar una breve discusión de cada atributo, concentrándose en sus preocupaciones subyacentes — para ilustrar los conceptos que son fundamentales para esa comunidad de atributo.

ESCENARIOS DE ATRIBUTO DE CALIDADUn escenario de atributo de calidad es un requisito de calidad atributo-específicas. Consta de seis partes.

Fuente de estímulo. Se trata de una entidad (un ser humano, un sistema informático o cualquier otro actuador) que generó el estímulo.

Estímulo. El estímulo es una condición que debe considerarse cuando llega a un sistema.

Medio ambiente. El estímulo se produce dentro de ciertas condiciones. El sistema puede estar en una condición de sobrecarga o puede que esté ejecutando cuando se produce el estímulo, o alguna otra condición puede ser cierto.

Artefacto. Algunos artefacto es estimulada. Esto puede ser todo el sistema o algunas piezas de la misma.

Respuesta. La respuesta es la actividad realizada después de la llegada del estímulo.

Medida de la respuesta. Cuando se produce la respuesta, debe ser medible de alguna manera para que el requisito se puede probar.

Distinguimos escenarios de atributo de calidad general (generales escenarios) — los que independiente del sistema y puede, potencialmente, pertenecen a cualquier sistema — de los escenarios de atributo de calidad concretas (escenarios concretos) — las que son específicas para el sistema particular que se examina. Presentamos caracterizaciones de atributo como una colección de escenarios generales; Sin embargo, para traducir la caracterización de atributo en los requisitos para un sistema en particular, los escenarios generales pertinentes deben realizarse sistema específico.

Figura 4.1 muestra las partes de un escenario de atributo de calidad.

Figura 4.1. Piezas de atributo de calidad

Escenario de disponibilidad

Un escenario general para el atributo de calidad de la disponibilidad, por ejemplo, se muestra en la figura 4.2. Se muestran sus seis partes, que indica el intervalo de valores que pueden tomar. De esto nos podemos derivar concretos, específicas del sistema, escenarios. No cada escenario de específicos del sistema tiene todas las seis partes. Las partes que son necesarias son el resultado de la aplicación del escenario y los tipos de pruebas que se realizarán para determinar si el escenario se ha logrado.

Figura 4.2. Escenarios de disponibilidad generales‘

Un escenario de disponibilidad de ejemplo, derivado de la situación general de la figura 4.2 por una instancia de cada una de las partes, es "un mensaje externo no previsto es recibido por un proceso durante el funcionamiento normal. El proceso informa al operador de la recepción del mensaje y sigue funcionando sin downtime." Figura 4.3 muestra las piezas de este escenario derivada.

Figura 4.3. Escenario de disponibilidad de ejemplo

El origen del estímulo es importante ya que las respuestas diferentes pueden ser necesarias en función de lo que es. Por ejemplo, una solicitud de una fuente de confianza puede tratarse de manera diferente de una solicitud de una fuente que no se confía en un escenario de seguridad. El medio ambiente también puede afectar la respuesta, en que un evento al llegar a un sistema puede tratarse de forma diferente si el sistema ya está sobrecargado. El artefacto que se estimula es menos importante como requisito. Casi siempre es el sistema y lo explícitamente llamamos por dos razones.

En primer lugar, muchos requisitos hacen suposiciones sobre la parte interna del sistema (por ejemplo, "un servidor Web dentro de la falla del sistema"). En segundo lugar, cuando utilizamos escenarios dentro de un método de diseño o de evaluación, refinamos el artefacto de escenario a ser bastante explícito sobre la parte del sistema que se está estimulado. Por último, ser explícito acerca del valor de la respuesta es importante para que los requisitos de atributo de calidad se hacen explícitos. Por lo tanto, incluimos la medida de la respuesta como una parte del escenario.

Escenario de modificabilidadUn escenario de modificabilidad de ejemplo es "un desarrollador desea cambiar la interfaz de usuario para hacer que color de fondo de una pantalla azul. Este cambio se hará al código en tiempo de diseño. Lleva menos de tres horas para hacer y probar el cambio y no hay efecto secundario se cambios en el comportamiento". Figura 4.4 ilustra este escenario de ejemplo (omitiendo algunos detalles menores por brevedad).

Figura 4.4. Escenario de modificabilidad de ejemplo

Una colección de escenarios concretos puede utilizarse como los requisitos de atributo de calidad para un sistema. Cada escenario es lo suficientemente concreta para ser significativa al arquitecto, y los detalles de la respuesta son lo suficientemente significativos como para que sea posible comprobar si el sistema ha logrado la respuesta. Cuando obteniendo requisitos, por lo general organizamos nuestra discusión de escenarios generales por atributos de calidad; Si el mismo escenario se genera por dos atributos diferentes, uno se puede eliminar.

Para cada atributo presentamos una tabla que ofrece posible independiente del sistema valores para cada una de las seis partes de un escenario de calidad. Se genera un escenario de calidad general, elija un valor para cada elemento; se genera un escenario concreto como parte de la obtención de requisitos eligiendo una o más entradas de cada columna de la tabla y, a continuación, haciendo el resultado legible. Por ejemplo, el escenario que se muestra en la figura 4.4 se genera desde el escenario de modificabilidad dado en la tabla 4.2 (en la página 83), pero las partes individuales fueron editadas ligeramente para hacerlos leer sin problemas como un escenario.

Escenarios concretos juegan el mismo papel en la especificación de requisitos de atributo de calidad que utilizan play de casos en la especificación de requisitos funcionales.

GENERACIÓN DE ESCENARIO DE ATRIBUTO DE CALIDAD

Nuestra preocupación en este capítulo está ayudando a que el arquitecto generar requerimientos de atributo de calidad significativo para un sistema. En teoría, esto se hace en la obtención de requisitos de un proyecto, pero en la práctica esto es rara vez rigurosamente. Como dijimos en el capítulo 1, requisitos de atributo de un sistema de calidad rara vez son suscitó y grabadas de forma disciplinada. Nos remediar esta situación mediante la generación de escenarios de atributo de calidad concretas. Para ello, utilizamos las tablas específicas de atributo de calidad para crear escenarios generales y de éstos se derivan los escenarios específicos del sistema. Por lo general, no todos los posibles escenarios generales se crean. Las tablas sirven como una lista de comprobación para

asegurarse de que se han considerado todas las posibilidades más que como un mecanismo de generación explícita. Somos despreocupados sobre la generación de escenarios que no encajan en una definición estrecha de un atributo — si dos atributos permiten la generación de la misma exigencia de atributo de calidad, se corrige fácilmente la redundancia. Sin embargo, si se omite un requisito de atributo de calidad importante, las consecuencias pueden ser más graves.

4.4 Escenarios de atributo de calidad en la práctica

Escenarios generales proporcionan un marco para la generación de un gran número de escenarios genéricos, independiente del sistema específico de atributo de calidad. Cada uno de ellos es potencialmente pero no necesariamente pertinente para el sistema le preocupa. Para hacer que los escenarios generales útil para un sistema en particular, debe hacer ellos sistema específico.

Hace que el sistema general de escenario específico significa traducirla en términos concretos para el sistema en particular. Por lo tanto, un escenario general es "llega una petición de un cambio en la funcionalidad y el cambio debe efectuarse en un momento determinado dentro del proceso de desarrollo en un plazo determinado". Una versión específica del sistema podría ser "una solicitud llega para agregar soporte para un nuevo navegador a un sistema basado en la Web, y el cambio debe efectuarse dentro de dos semanas". Además, un único escenario general puede tener muchas versiones de específicos del sistema. El mismo sistema que tiene que apoyar un nuevo explorador tenga también apoyar un nuevo tipo de medios de comunicación.

Ahora hablamos de los seis más común e importante calidad atributos, con el doble objetivo de identificar los conceptos utilizados por el atributo comunidad y proporcionar un método para generar escenarios generales para dicho atributo.

DISPONIBILIDAD

Disponibilidad se refiere a la falla en el sistema y sus consecuencias asociadas. Un error del sistema se produce cuando el sistema ya no ofrece un servicio coherente con su especificación. Un fracaso es observable por los usuarios del sistema, ya sea en los seres humanos o en otros sistemas. Un ejemplo de un escenario de disponibilidad general apareció en la figura 4.3.

Entre las esferas de interés se encuentran cómo se detecta una falla del sistema, con qué frecuencia puede ocurrir falla en el sistema, lo que ocurre cuando se produce un error, durante cuánto tiempo un sistema puede estar fuera de operación, cuando pueden ocurren fallas con la seguridad y modo de evitar fallas, y qué tipo de notificaciones es necesario cuando se produce un error.

Tenemos que diferenciar entre los errores y fallas. Una falla puede llegar a ser un fracaso si no corregida o enmascarados. Es decir, un fracaso es observable por usuario del sistema y un fallo no lo es. Cuando un observable hace convertirse en fallas, se convierte en un

fracaso. Por ejemplo, un fallo puede elegir el algoritmo mal para un cálculo, lo que resulta en un error de cálculo que hace que el sistema falle.

Una vez que se produce un error en un sistema, un importante concepto relacionado se convierte en el tiempo que toma para repararlo. Debido a un error del sistema es observable por los usuarios, el tiempo de reparación es el momento hasta que el fracaso no es más largo observable. Esto puede ser un breve retraso en el tiempo de respuesta o puede ser el tiempo que lleva a alguien a volar a una ubicación remota en las montañas de Perú para reparar una pieza de maquinaria de minería (en este ejemplo fue dado por una persona que fue responsable de reparar el software en un motor de la máquina de minería.).

La distinción entre las fallas y errores permite la discusión de estrategias de reparación automática. Es decir, si se ejecuta código que contiene un error, pero el sistema es capaz de recuperarse de la culpa, sin que sea observable, no hay ningún error.

La disponibilidad de un sistema es la probabilidad de que estará operativo cuando sea necesario. Por lo general se define como:

De este procede términos como disponibilidad del 99,9%, o una 0,1% de probabilidad que el sistema no estará operativo cuando sea necesario.

Paradas programadas (es decir, fuera de servicio) no se consideran por lo general al calcular la disponibilidad, ya que el sistema "no es necesario" por definición. Esto conduce a situaciones donde el sistema está inactivo y se esperan los usuarios, pero el tiempo de inactividad está programada y por lo tanto, no se cuenta contra cualquier requisito de disponibilidad.

Escenarios de disponibilidad GeneralDe estas consideraciones podemos ver las porciones de un escenario de disponibilidad, que se muestra en la figura 4.2.

Fuente de estímulo. Hay diferenciar entre las indicaciones internas y externas de fallas o fracaso ya que la respuesta del sistema deseado puede ser diferente. En nuestro ejemplo, el mensaje inesperado llega de fuera del sistema.

Estímulo. Se produce un fallo de una de las siguientes clases.

-omisión. Un componente no responde a una entrada.

-accidente. El componente sufre varias veces errores de omisión.

-calendario. Un componente responde, pero la respuesta es temprano o tardío.

-respuesta. Un componente responde con un valor incorrecto.

-En la figura 4.3, el estímulo es que llegue un mensaje no previsto. Este es un ejemplo de un error de sincronización. El componente que generó el mensaje lo hicieron en un momento diferente de lo que se esperaba.

Artefacto. Especifica el recurso que se requiere para ser altamente disponibles, tales como un procesador, el canal de comunicación, el proceso o el almacenamiento de información.

Medio ambiente. El estado del sistema cuando se produce el error o el fracaso también puede afectar la respuesta del sistema deseado. Por ejemplo, si el sistema ya ha visto algunos errores y está funcionando en distintos de modo normal, puede ser deseable para apagar totalmente. Sin embargo, si este es el primer fallo observado, algunos degradación de función o el tiempo de respuesta puede ser preferible. En nuestro ejemplo, el sistema está funcionando normalmente.

Respuesta. Hay una serie de posibles reacciones a un error del sistema. Estos incluyen el fracaso, notificar a los usuarios seleccionados u otros sistemas, cambiar a un modo degradado con función de menos capacidad o menos, apagar los sistemas externos, o llegar a ser no está disponible durante la reparación de inicio de sesión. En nuestro ejemplo, el sistema debe notificar al operador del mensaje inesperado y seguirán funcionando normalmente.

Medida de la respuesta. La medida de la respuesta puede especificar un porcentaje de disponibilidad, o puede especificar un tiempo de reparación, tiempo durante el cual el sistema debe estar disponible, o la duración para que el sistema debe estar disponible. En la figura 4.3, no hay tiempo de inactividad por el mensaje inesperado.

Tabla 4.1 presenta los valores posibles para cada parte de un escenario de disponibilidad.

Cuadro 4.1. Generación de escenario de disponibilidad General

MODIFICABILIDADModificabilidad es sobre el coste del cambio. Abre dos preocupaciones.

1. ¿Lo que puede cambiar (el artefacto)? Un cambio produzca en cualquier aspecto de un sistema más comúnmente las funciones que el sistema calcula, la plataforma que el sistema existe en (el hardware, sistema operativo, middleware, etc.), el entorno en el que el sistema Opera (los sistemas con los que debe interoperar, los protocolos que se utiliza para comunicarse con el resto del mundo, etc.), las cualidades las exposiciones de sistema (su rendimiento, su fiabilidad y incluso sus futuras modificaciones) y su capacidad (número de usuarios admitidos, número de operaciones simultáneas, etc.). Algunas partes del sistema, tales como la interfaz de usuario o de la plataforma, son suficientemente distinguido y sujetos a cambios, los que consideramos por separado. La categoría de los cambios de plataforma también se denomina portabilidad. Esos cambios pueden agregar, eliminar o modificar alguno de estos aspectos.

2. ¿Cuándo es el cambio realizado y lo que hace (medio ambiente)? Más comúnmente en el pasado, se realizó un cambio al código fuente. Es decir, un desarrollador se tuvo que hacer el cambio, que fue probado y, a continuación, desplegado en una nueva versión. Ahora, sin embargo, la cuestión de cuando se realiza un cambio está entrelazada con la cuestión de quién lo hace. Un usuario final cambiar el protector de pantalla claramente es realizar un cambio en uno de los aspectos del sistema. Igualmente claro, no está en la misma categoría que cambiar el sistema para que se puede utilizar en la Web, en lugar de en un solo equipo. Cambios es posible a la aplicación (modificando el código fuente), durante la compilación (mediante switches de tiempo de compilación), durante la generación (por elección de las bibliotecas), durante la instalación de configuración (por una variedad de técnicas, incluyendo la configuración de parámetros) o durante la ejecución (por valor de

parámetro). También es posible un cambio por un desarrollador, un usuario final o un administrador del sistema.

Una vez que se ha especificado un cambio, la nueva implementación deberá diseñarse, implementada, probada y desplegada. Todas estas acciones toman tiempo y dinero, las cuales se pueden medir.

Escenarios de modificabilidad General

De estas consideraciones podemos ver las porciones de los escenarios de modificabilidad general. Figura 4.4 proporciona un ejemplo: "un desarrollador desea cambiar la interfaz de usuario. Este cambio se hará de forma automática al código en tiempo de diseño, lleva menos de tres horas para hacer y probar el cambio, y no hay efectos secundarios se cambios en el comportamiento".

Fuente de estímulo. Esta parte especifica que realiza los cambios — el desarrollador, un administrador del sistema o un usuario final. Claramente, debe haber maquinaria en el lugar para permitir que el administrador del sistema o usuario final modificar un sistema, pero esto es algo común. En la figura 4.4, la modificación deba efectuarse por el desarrollador.

Estímulo. Esta parte especifica los cambios a realizar. Un cambio puede ser la adición de una función, la modificación de una función existente o la supresión de una función. También se puede hacer a las cualidades del sistema — lo que es más sensible, aumentar su disponibilidad y así sucesivamente. También puede cambiar la capacidad del sistema. Aumentar el número de usuarios simultáneos es un requisito frecuente. En nuestro ejemplo, el estímulo es una solicitud para hacer una modificación, que puede ser a la función, calidad o capacidad.

Variación es un concepto asociado a las líneas de productos de software (consulte el capítulo 14). Al considerar la variación, un factor es el número de veces que se debe especificar una variación determinada. Uno que tiene que hacerse con frecuencia va a imponer un requisito más estricto sobre las medidas de respuesta de uno que se hace sólo esporádicamente.

Artefacto. Esta parte especifica lo que debe cambiarse — la funcionalidad de un sistema, su plataforma, su interfaz de usuario, su entorno o otro sistema con el que interopera. En la figura 4.4, la modificación es la interfaz de usuario.

Medio ambiente. Esta parte especifica cuando es posible el cambio: tiempo de diseño, tiempo de compilación, construir la hora, tiempo de iniciación o el tiempo de ejecución. En nuestro ejemplo, la modificación es que se produzca en tiempo de diseño.

Respuesta. Quien hace el cambio debe comprender cómo hacerlo y, a continuación, convertirlo en, la prueba y desplegarlo. En nuestro ejemplo, la modificación se realiza sin efectos secundarios.

Medida de la respuesta. Todas las respuestas posibles toman tiempo y cuestan dinero, y por lo tanto tiempo y los costos son las medidas más deseables. Tiempo no siempre es posible predecir, sin embargo, y por lo tanto menos medidas ideales se utilizan con frecuencia, tales como la magnitud del cambio (número de módulos afectados). En nuestro ejemplo, el tiempo para realizar la modificación debe ser menos de tres horas.

Tabla 4.2 presenta los valores posibles para cada parte de un escenario de modificabilidad.

Tabla 4.2. Generación de escenario de modificabilidad General

PERFORMANCE

El rendimiento es acerca de temporización. Se producen eventos (interrupciones, mensajes, las solicitudes de los usuarios o el paso del tiempo), y el sistema debe responder a ellos. Hay una variedad de caracterizaciones de llegada del evento y la respuesta, pero básicamente se refiere a rendimiento con cuánto tiempo tarda el sistema para responder cuando se produce un evento.

Una de las cosas que hacen de rendimiento complicado es el número de orígenes de eventos y los patrones de llegada. Eventos pueden llegar desde las solicitudes del usuario, de otros sistemas o desde el sistema. Un sistema de servicios financieros basados en Web obtiene eventos de sus usuarios (posiblemente numeración en las decenas o cientos de miles). Un sistema de control de motor obtiene sus solicitudes desde el paso del tiempo y debe controlar tanto el disparo de la ignición cuando un cilindro está en la posición correcta y la mezcla del combustible para maximizar la energía y reducir al mínimo la contaminación.

Para el sistema financiero basado en Web, la respuesta podría ser el número de transacciones que se pueden procesar en un minuto. Para el sistema de control de motor, la respuesta podría ser la variación en el tiempo de cocción. En cada caso, se pueden caracterizar el patrón de eventos que llegan y el de las respuestas y, a continuación, esta caracterización forma el lenguaje con el que construir escenarios de rendimiento general.

Un escenario de rendimiento comienza con una solicitud de algún servicio que llegan en el sistema. Satisfacer la solicitud requiere recursos para ser consumidos. Mientras esto ocurre el sistema puede ser simultáneamente servicios otras solicitudes.

Un patrón de llegada para eventos puede caracterizarse como periódicos o estocástico. Por ejemplo, un evento periódico puede llegar cada 10 milisegundos. Evento periódico llegada se ve más a menudo en sistemas en tiempo real. Llegada estocástico significa que eventos llegan de acuerdo con alguna distribución probabilística. Eventos también pueden llegar esporádicamente, es decir, con arreglo a una distribución no capturarla por caracterizaciones estocásticos o periódicos.

Varios usuarios u otros factores de carga pueden ser modelados mediante la variación de la trama de la llegada de eventos. En otras palabras, desde el punto de vista del rendimiento del sistema, no importa si un usuario envía solicitudes de 20 en un período de tiempo o si dos usuarios envían 10. Lo que importa es el patrón de llegada en el servidor y las dependencias dentro de las solicitudes.

La respuesta del sistema a un estímulo puede ser caracterizado por la latencia (el tiempo entre la llegada del estímulo y la respuesta del sistema a ella), los plazos en el procesamiento (en el controlador de motor, por ejemplo, el combustible debe encender cuando el cilindro está en una posición determinada, introduciendo un plazo de procesamiento), el rendimiento del sistema (por ejemplo, el número de transacciones que el sistema pueda procesar en un segundo), la variación de la respuesta (la variación en la latencia), el número de eventos que no procesados ya que el sistema estaba demasiado ocupado para responder y los datos que se perdieron debido a que el sistema estaba demasiado ocupado.

Observe que esta formulación no tiene en cuenta si el sistema está en red o standalone. Tampoco (todavía) considera la configuración del sistema o el consumo de recursos. Estas cuestiones son dependientes de soluciones de arquitectura, que se explica en el capítulo 5.

Escenarios de rendimiento GeneralDe estas consideraciones podemos ver las porciones de la situación general de rendimiento, se muestra un ejemplo de que en la figura 4.5: "los usuarios iniciar 1.000 transacciones por minuto autosimilar bajo las operaciones normales, y estas transacciones se procesan con una latencia promedio de dos segundos".

Figura 4.5. Escenario de rendimiento de ejemplo

Fuente de estímulo. Los estímulos llegan ya sea desde el exterior (posiblemente múltiple) o fuentes internas. En nuestro ejemplo, la fuente del estímulo es una colección de usuarios.

Estímulo. Los estímulos son las llegadas de evento. El patrón de llegada puede ser caracterizado como periódico, estocástico o esporádicos. En nuestro ejemplo, el estímulo es la iniciación estocástica de 1.000 transacciones por minuto.

Artefacto. El artefacto es siempre los servicios del sistema, como en nuestro ejemplo.

Medio ambiente. El sistema puede estar en diferentes modos de funcionamiento, como normal, emergencia, o de sobrecarga. En nuestro ejemplo, el sistema está en modo normal.

Respuesta. El sistema debe procesar los eventos que llegan. Esto puede causar un cambio en el entorno del sistema (por ejemplo, de normal a modo de sobrecarga). En nuestro ejemplo, se procesan las transacciones.

Medida de la respuesta. Las medidas de respuesta son el tiempo necesario para procesar los eventos que llegan (latencia o un plazo por el que se debe procesar el evento), la variación en este momento (jitter), el número de eventos que se pueden procesar dentro de un intervalo de tiempo determinado (producción), o una caracterización de los eventos que no puede ser procesado (miss tasa de pérdida de datos). En nuestro ejemplo, las transacciones deben procesarse con un promedio de latencia de dos segundos.

Tabla 4.3 da elementos de los escenarios generales que caracterizan el rendimiento.

Cuadro 4.3. Generación de escenario de rendimiento General

La mayor parte de la historia de la ingeniería de software, rendimiento ha sido el factor determinante de la arquitectura del sistema. Como tal, con frecuencia ha comprometido el logro de todas las otras cualidades. A medida que aumenta la relación precio/rendimiento de hardware viviente y el costo de desarrollo de software, han surgido otras cualidades como competidores importantes de rendimiento.

SEGURIDAD

La seguridad es una medida de la capacidad del sistema para resistir el uso no autorizado mientras ofrece sus servicios a los usuarios legítimos. Un intento de romper la seguridad se llama un ataque [1] y puede tomar un número de formas. Puede ser un intento no autorizado para acceder a datos o servicios o para modificar los datos o puede tener por objeto negar servicios a los usuarios legítimos.

[1] Algunos expertos en seguridad utilizan "amenaza" indistintamente con "ataque".

Los ataques, a menudo ocasiones para medios de comunicación amplia cobertura, pueden variar de robo de dinero por transferencia electrónica a la modificación de datos confidenciales, contra el robo de números de tarjeta de crédito a la destrucción de archivos en los sistemas informáticos, o a los ataques de denegación de servicio llevado a cabo por gusanos o virus de. Aún así, los elementos de un escenario general de seguridad son los mismos que los elementos de otros escenarios nuestros generales — un estímulo y su origen, un entorno, el destino bajo ataque, la respuesta deseada del sistema y la medida de esta respuesta.

Seguridad puede ser caracterizado como un sistema de prestación de no rechazo, la confidencialidad, la integridad, la garantía, la disponibilidad y la auditoría. Para cada término, proporcionamos una definición y un ejemplo.

1. No rechazo es la propiedad que no se puede negar una transacción (acceso o modificación de datos o servicios) por cualquiera de las partes. Esto significa que no puede negar que ordenó que el tema por Internet si, de hecho, lo hizo.

2. Confidencialidad es que los datos de la propiedad o los servicios están protegidos contra accesos no autorizados. Esto significa que un hacker no puede tener acceso a sus declaraciones de impuestos de ingresos en un equipo de Gobierno.

3. Integridad es que los datos de la propiedad o servicios se entregan como se esperaba. Esto significa que su grado no ha cambiado desde que el instructor le asignó.

4. El aseguramiento es la propiedad de que las partes en una transacción son quienes pretende ser. Esto significa que, cuando un cliente envía un número de tarjeta de crédito a un comerciante de Internet, el comerciante es que el cliente piensa que son.

5. La disponibilidad es la propiedad que el sistema estará disponible para uso legítimo. Esto significa que un ataque de denegación de servicio no impide que sus pedidos de este libro.

6. La auditoría es la propiedad que el sistema realiza un seguimiento de las actividades dentro de ella a nivel suficiente para reconstruirles. Esto significa que, si transfiere dinero de una cuenta a otra cuenta, en Suiza, el sistema mantendrá un registro de dicho traslado.

Cada una de estas categorías de seguridad da lugar a una colección de escenarios generales.

Escenarios de Seguridad General

A continuación figuran las porciones de un escenario general de seguridad. Figura 4.6 presenta un ejemplo. Un individuo correctamente identificado intenta modificar datos del sistema de un sitio externo; sistema mantiene una pista de auditoría y los datos correctos se restaura dentro de un día.

Fuente de estímulo. El origen del ataque puede ser un ser humano u otro sistema. Se habrá sido previamente identificado (correctamente o incorrectamente) o puede ser actualmente desconocido. Si el origen del ataque es altamente motivado (dicen por motivos políticos), a continuación, las medidas defensivas como "sabemos que usted es y será enjuiciar le" no están probables que sean eficaces; en tales casos, la motivación del usuario puede ser importante. Si la fuente tiene acceso a gran cantidad de recursos (por ejemplo, un gobierno), las medidas defensivas son muy difíciles. El ataque es el acceso no autorizado, la modificación o la denegación de servicio.

La dificultad con la seguridad es permitir el acceso a los usuarios legítimos y determinar la legitimidad. Si el único gol impedir el acceso a un sistema, si no se permite acceso todos sería una medida defensiva eficaz.

Figura 4.6. Escenario de seguridad de ejemplo

Estímulo. El estímulo es un ataque o un intento de romper la seguridad. Se caracteriza por esto como una persona no autorizada o sistema intentando mostrar información, cambiar o eliminar la información, acceder a los servicios del sistema o reducir la disponibilidad de servicios del sistema. En la figura 4.6, el estímulo es un intento de modificar los datos.

Artefacto. El objetivo del ataque puede ser los servicios del sistema o los datos dentro de ella. En nuestro ejemplo, el objetivo es datos dentro del sistema.

Medio ambiente. El ataque puede venir cuando el sistema está ya sea en línea o sin conexión, o conectado a o desconectado de una red, ya sea detrás de un firewall o abre a la red.

Respuesta. Utilizando servicios sin autorización o impedir que los usuarios legítimos utilicen servicios es un objetivo diferente de ver datos confidenciales o modificarlo. De este modo, el sistema debe autorizar a los usuarios legítimos y concederles acceso a datos y servicios, a la vez rechazar los usuarios no autorizados, negándoles acceso y reporting de acceso no autorizado. No sólo es el sistema necesario proporcionar acceso a los usuarios legítimos, pero que necesita para apoyar la concesión o retirada de acceso. Una técnica para evitar los ataques es para causar miedo al castigo por mantener un seguimiento de auditoría de las modificaciones o intentos de accesos. Una pista de auditoría también es útil en la corrección de un ataque con éxito. En la figura 4.6, se mantiene un registro de auditoría.

Medida de la respuesta. Las medidas de respuesta del sistema incluyen la dificultad de montaje de diversos ataques y la dificultad de recuperarse y sobrevivir a los ataques. En nuestro ejemplo, la pista de auditoría permite que las cuentas de la que fue malversado dinero para ser restaurada a su estado original. Por supuesto, el

embezzler todavía tiene el dinero y él debe ser acorralado y recuperó el dinero, pero esto es fuera del campo del sistema informático.

Tabla 4.4 muestra en la tabla de generación de escenario general de seguridad.

Tabla 4.4. Generación de escenario de Seguridad General

TESTABILIDADTestabilidad de software se refiere a la facilidad con la que es posible software para demostrar sus fallas a través de pruebas (por lo general basada en ejecución). Al menos 40% del coste de desarrollo de sistemas bien diseñados es tomado por pruebas. Si el arquitecto de software puede reducir este costo, la recompensa es grande.

En particular, Testabilidad se refiere a la probabilidad, asumiendo que el software tiene al menos un fallo, que se producirá un error en su próxima ejecución de la prueba. Por supuesto, calcular esta probabilidad no es fácil y, cuando llegamos a las medidas de respuesta, otras medidas se utilizará.

Para que un sistema ser debidamente comprobables, deberán poder controlar las entradas y el estado interno de cada componente y luego a observar sus resultados. Con frecuencia, esto se hace mediante el uso de un instrumento de la prueba, diseñado para ejercer el software de prueba de software especializado. Esto puede ser tan simple como una capacidad de reproducción para los datos registrados a través de distintas interfaces o tan complicado como una cámara de prueba para un motor.

Las pruebas se hace por varios desarrolladores, testers, verificadores o usuarios y es el último paso de varias partes del ciclo de vida del software. Pueden probar porciones del

código, el diseño o el sistema completo. Las medidas de respuesta para Testabilidad tratan de las pruebas cuán eficaces son en el descubrimiento de errores y el tiempo que lleva realizar las pruebas a cierto nivel deseado de cobertura.

Escenarios de Testabilidad GeneralFigura 4.7 es un ejemplo de un escenario de Testabilidad referente a los resultados de una prueba unitaria: un probador de unidad realiza una prueba unitaria en un componente del sistema completo que proporciona una interfaz para controlar su comportamiento y observar su salida; 85% de cobertura de ruta de acceso se consigue dentro de tres horas.

Figura 4.7. Escenario de ejemplo Testabilidad

Fuente de estímulo. La prueba se realiza mediante dispositivos de pruebas de unidad, encargados de pruebas de integración, encargados de pruebas de sistema o el cliente. Por otros desarrolladores o por un grupo externo, se puede realizar un examen del diseño. En nuestro ejemplo, la prueba se realiza por un tester.

Estímulo. El estímulo para la prueba es que se cumpla un hito en el proceso de desarrollo. Esta puede ser la realización de un incremento de análisis o el diseño, la realización de un incremento de codificación, como una clase, la integración completa de un subsistema o la realización de todo el sistema. En nuestro ejemplo, la prueba se activa por la finalización de una unidad de código.

Artefacto. Un diseño, una pieza de código, o todo el sistema es el artefacto que se está probando. En nuestro ejemplo, una unidad de código es someterse.

Medio ambiente. La prueba puede ocurrir en tiempo de diseño, en tiempo de desarrollo, en tiempo de compilación o en tiempo de implementación. En la figura 4.7, la prueba se produce durante el desarrollo.

Respuesta. Puesto Testabilidad está relacionado con la observación y la capacidad de control, la respuesta deseada es que el sistema puede ser controlado para realizar

las pruebas deseadas y que se puede observar la respuesta a cada prueba. En nuestro ejemplo, la unidad puede ser controlada y capturan de sus respuestas.

Medida de la respuesta. Las medidas de respuesta son el porcentaje de declaraciones que han sido ejecutadas en alguna prueba, la longitud de la cadena más larga de la prueba (una medida de la dificultad de efectuar las pruebas) y las estimaciones de la probabilidad de encontrar errores adicionales. En la figura 4.7, la medición es el porcentaje de cobertura de instrucciones ejecutables.

Cuadro 4.5 da la tabla de generación de escenario general de Testabilidad.

Cuadro 4.5. Generación de escenario de Testabilidad General

FACILIDAD DE USO

Facilidad de uso se ocupa de lo fácil que es para que el usuario realizar una tarea deseada y el tipo de soporte de usuario que proporciona el sistema. Se puede dividir en las siguientes áreas:

Características del sistema de aprendizaje. Si el usuario no está familiarizado con un sistema en particular o un aspecto particular de la misma, ¿qué puede el sistema hacer para facilitar la tarea de aprendizaje?

Uso eficiente de un sistema. ¿Qué puede hacer el sistema para hacer que el usuario más eficiente en su funcionamiento?

Minimiza el impacto de los errores. ¿Qué puede hacer el sistema para que un error de usuario tiene un impacto mínimo?

Adaptando el sistema a las necesidades del usuario. ¿Cómo puede adaptar el usuario (o el propio sistema) para facilitar la tarea del usuario?

Aumento de confianza y satisfacción. ¿Qué hace el sistema para dar la confianza de los usuarios que se tiene la acción correcta?

En los últimos cinco años, se ha profundizado nuestra comprensión de la relación entre usabilidad y arquitectura de software (consulte la barra lateral usabilidad Mea Culpa). El proceso de desarrollo normal detecta problemas de usabilidad mediante la creación de prototipos y pruebas de usuario. Más tarde se descubre un problema y más profundo en la arquitectura que se efectuará su reparación, más la reparación está amenazada por las presiones de tiempo y presupuestas. En nuestros escenarios nos centramos en aspectos de usabilidad que tengan un gran impacto en la arquitectura. En consecuencia, estos escenarios deben ser correctos antes para el diseño de la arquitectura para que no se descubrieron durante la realización de pruebas de usuario o la creación de prototipos.

Escenarios de uso General

Figura 4.8 da un ejemplo de un escenario de facilidad de uso: un usuario, que desean minimizar el impacto de un error, desea cancelar una operación del sistema en tiempo de ejecución; cancelación tiene lugar en menos de un segundo. Las porciones de los escenarios de uso general son:

Fuente de estímulo. El usuario final es siempre la fuente del estímulo.

Estímulo. El estímulo es que el usuario final desea utilizar un sistema de manera eficiente, aprender a utilizar el sistema, minimizar el impacto de los errores, adaptar el sistema o se sienten cómodos con el sistema. En nuestro ejemplo, el usuario desea cancelar una operación, que es un ejemplo de reducir al mínimo el impacto de los errores.

Artefacto. El artefacto es siempre el sistema.

Medio ambiente. Las acciones del usuario con el que la facilidad de uso se refiere siempre se producen en tiempo de ejecución o en el momento de la configuración de sistema. Cualquier acción que se produce antes de a continuación, se lleva a cabo por desarrolladores y, aunque un usuario también puede ser el desarrollador, distinguimos entre estas funciones incluso si lleva a cabo por la misma persona. En la figura 4.8, la cancelación se produce en tiempo de ejecución.

Respuesta. El sistema debe proporcionar al usuario las características necesarias o anticiparse a las necesidades del usuario. En nuestro ejemplo, la cancelación se produce como los deseos del usuario y el sistema se restaura a su estado anterior.

Medida de la respuesta. La respuesta se mide por el tiempo de la tarea, número de errores, número de problemas resueltos, satisfacción de los usuarios, ganancia de conocimiento del usuario, relación de operaciones exitosas al total de operaciones, o la cantidad de datos/tiempo perdido cuando se produce un error. En la figura 4.8, la cancelación debe ocurrir en menos de un segundo.

La tabla de generación de capacidad de uso general escenario figura en el cuadro 4.6.

Cuadro 4.6. Generación de escenario de la facilidad de uso General

COMUNICAR CONCEPTOS GENERALES DE ESCENARIOS

Uno de los usos de escenarios generales es que las partes interesadas para comunicarse. Ya hemos señalado que cada comunidad de atributo tiene su propio vocabulario para describir sus conceptos básicos y que diferentes términos pueden representar la misma ocurrencia. Esto puede conducir a la falta de comunicación. Por ejemplo, durante un debate de rendimiento, un protagonista que representan a los usuarios no puede obtener que la latencia de la respuesta a los eventos tiene algo que ver con los usuarios. Debates de decisiones arquitectónicas, particularmente sobre disyuntivas ayuda a facilitar este tipo de entendimiento.

Tabla 4.7. Estímulos de atributo de calidad

4.7 Tabla da los estímulos posibles para cada uno de los atributos y muestra una serie de conceptos diferentes. Algunos estímulos se producen en tiempo de ejecución y otros se producen antes. El problema para el arquitecto es comprender cuál de estos estímulos representan la misma aparición, que son agregados de otros estímulos, y que son independientes. Una vez que las relaciones son claras, que el arquitecto puede comunicarlas a las diversas partes interesadas utilizando el lenguaje que cada uno comprende. No podemos dar las relaciones entre los estímulos de manera general porque dependen parcialmente sobre el medio ambiente. Un evento de rendimiento puede ser atómico o puede ser un agregado de otras apariciones de nivel inferior; una falla puede ser un evento de rendimiento individual o un conjunto. Por ejemplo, puede ocurrir con un intercambio de severalmessages entre un cliente y un servidor (que culminaron en un mensaje inesperado), cada uno de ellos es un evento atómico desde una perspectiva de rendimiento.

4.5 Otros atributos de calidad del sistemaHemos hablado de los atributos de calidad de manera general. Un número de otros atributos puede encontrarse en las taxonomías de atributo en la literatura de investigación y en los textos de la ingeniería de software estándar, y que hemos capturado a muchos de ellos en nuestros escenarios. Por ejemplo, la escalabilidad es a menudo un atributo importante, pero en nuestra discusión aquí la escalabilidad es capturado por modificar la capacidad del sistema: el número de usuarios admitidos, por ejemplo. Portabilidad se captura como una modificación de la plataforma.

Si algún atributo de calidad — decir interoperabilidad — es importantes para su organización, es razonable crear su propio escenario general para él. Simplemente se trata de rellenar las seis partes del marco de la generación de escenario: origen, estímulo, medio ambiente, artefacto, respuesta y medida de la respuesta. Para la interoperabilidad, un estímulo podría ser una solicitud para interoperar con otro sistema, una respuesta podría ser una nueva interfaz o un conjunto de interfaces para la interoperación y una medida de la respuesta podría ser la dificultad en términos de tiempo, el número de interfaces a modificarse y así sucesivamente.

4.6 Cualidades de negocios

Además de las cualidades que se aplican directamente a un sistema, una serie de objetivos de calidad de negocios con frecuencia forma a la arquitectura de un sistema. Estos objetivos se centran en costo, programación, mercado y consideraciones de marketing. Cada uno de ellos padece la misma ambigüedad que tienen cualidades del sistema y que necesitan para hacerse específicos con los escenarios a fin de hacerlas apropiadas para influir en el proceso de diseño y hacerse comprobables. Aquí, nos presentarlos como generalidades, sin embargo y dejar la generación de escenarios como una de nuestras preguntas de discusión.

Tiempo de comercialización. Si hay presión de la competencia o una breve ventana de oportunidad para un producto o sistema, tiempo de desarrollo se convierte en un importante. Esto a su vez lleva a presión para comprar o de lo contrario reutilizar los elementos existentes. Tiempo de comercialización a menudo se reduce mediante el uso de elementos prediseñados como productos comerciales de (COTS) disponibles en el mercado o reutilizados de proyectos previos. La capacidad para insertar o implementar un subconjunto del sistema depende de la descomposición del sistema en elementos.

Costo y beneficio. El esfuerzo de desarrollo, naturalmente, tendrá un presupuesto que no deberá ser superado. Diferentes arquitecturas producirá los costos de desarrollo diferentes. Por ejemplo, una arquitectura que se basa en la tecnología (o conocimientos especializados con una tecnología) no residente en la organización en desarrollo será más caro a darse cuenta de que uno que se aprovecha de los activos ya internos. Una arquitectura que es altamente flexible normalmente será más costosa construir que uno que es rígida (aunque es menos costoso de mantener y modificar).

Toda la vida proyectada del sistema. Si el sistema va a tener una vida útil larga, modificabilidad, escalabilidad y portabilidad convertido en importantes. Pero el edificio en la infraestructura adicional (por ejemplo, una capa para apoyar la portabilidad) por lo general pondrá en peligro al mercado. Por otra parte, un

producto modificable y ampliable es más probable que sobreviven por más tiempo en el mercado, extender su vida útil.

Mercado de destino. Para el software (mercado de masas) para fines generales, las plataformas en el cual un sistema funciona tan bien como su función conjunto de voluntad determinan el tamaño del mercado potencial. Por lo tanto, portabilidad y funcionalidad son clave para la participación en el mercado. Otras cualidades, tales como el rendimiento, fiabilidad y facilidad de uso también desempeñan un papel. Para atacar un gran mercado con una colección de productos relacionados, debe considerarse un enfoque de línea de producto en el que un núcleo del sistema es común (con frecuencia incluidas las disposiciones para la portabilidad) y alrededor de las capas de software cada vez más especificidad que se construyen. Este enfoque se tratarán en el capítulo 14, que trata sobre las líneas de productos de software.

Plan de puesta en servicio. Si un producto es que se introduzcan como funcionalidad básica con muchas características lanzadas más tarde, la flexibilidad y la personalización de la arquitectura son importantes. En particular, el sistema debe construirse con la facilidad de expansión y contracción en mente.

Integración con sistemas heredados. Si el nuevo sistema tiene que integrar con los sistemas existentes, se debe tener cuidado para definir los mecanismos de integración adecuada. Esta propiedad es claramente de la comercialización de importancia, pero tiene importantes implicaciones de arquitectura. Por ejemplo, la capacidad de integrar un sistema heredado con un servidor HTTP para que sea accesible desde la Web ha sido un objetivo de marketing en muchas empresas en la última década. Las restricciones arquitectónicas que implica esta integración deben ser analizadas.

4.7 Cualidades de la arquitectura deAdemás de las cualidades del sistema y cualidades relacionadas con el entorno empresarial en el que se está desarrollando el sistema, también hay cualidades directamente relacionados con la arquitectura que son importantes para alcanzar. Discutimos sobre tres, dejando nuevamente a la generación de escenarios específicos a nuestras preguntas de discusión.

Integridad conceptual es el tema subyacente o la visión que unifica el diseño del sistema en todos los niveles. La arquitectura debe hacer cosas similares de manera similar. Fred Brooks escribe enfáticamente que integridad conceptual de un sistema es de importancia de primer orden, y que los sistemas sin ella no:

Sostengo que la integridad conceptual es la consideración más importante en el diseño del sistema. Es mejor tener un sistema omitir ciertas mejoras y características anómalas, pero para reflejar un conjunto de ideas de diseño, que tener que contiene muchas ideas buenas pero independientes y falta de coordinación. [Brooks 75]

Brooks escribió principalmente sobre los sistemas de forma aparecen a sus usuarios, pero el punto es igualmente válido para el diseño arquitectónico. Idea de qué Brooks de integridad conceptual se hace por el usuario, integridad arquitectónica hace por las otras partes interesadas, particularmente los desarrolladores y mantenedores.

En la tercera parte, verá una recomendación para la evaluación de la arquitectura que requiere el proyecto que se está examinando para poner a disposición del arquitecto. Si nadie se identifica con ese rol, es una señal de que puede que falte la integridad conceptual.

Exactitud e integridad son esenciales para la arquitectura permitir todos requisitos del sistema y las limitaciones de recursos de tiempo de ejecución para cumplirse. Una evaluación formal, tal como se prescribe en la tercera parte, es una vez más mejor esperanza del arquitecto para una arquitectura correcta y completa.

Edificabilidad permite al sistema a cumplimentar por el equipo disponible de manera oportuna y estar abierto a ciertos cambios a medida que avanza el desarrollo. Se refiere a la facilidad de construir un sistema deseado o se logra, arquitectónicamente, prestando una atención especial a la descomposición en módulos, con criterio asignando de esos módulos para equipos de desarrollo y limitar las dependencias entre los módulos (y por lo tanto los equipos). El objetivo es maximizar el paralelismo que puede ocurrir en el desarrollo.

Porque edificabilidad suele medirse en términos de costo y tiempo, existe una relación entre ella y varios modelos de costos. Sin embargo, la edificabilidad es más complejo que lo que se trata por lo general en modelos de costos. Se crea un sistema de ciertos materiales, y estos materiales se crean usando una variedad de herramientas. Por ejemplo, una interfaz de usuario puede ser construida de elementos en una caja de herramientas de interfaz de usuario (llamada widgets o controles), y estos widgets pueden ser manipulados por un constructor de interfaces de usuario. Los widgets son los materiales y el generador es la herramienta, por lo que un elemento de Edificabilidad es el partido entre los materiales que van a utilizar en el sistema y las herramientas que están disponibles para manipularlos. Otro aspecto de la edificabilidad es conocimiento sobre el problema a ser resuelto. El fundamento de este aspecto es para acelerar el tiempo para comercializar y no obligar a proveedores potenciales para invertir en la comprensión y la ingeniería de un nuevo concepto. Un diseño que proyecta una solución en términos de conceptos bien entendidos, por tanto, es más generable que uno que introduce nuevos conceptos.

Capítulo 5. Logro de cualidadescon Felix Bachmann, Mark Klein y Bill Wood

Nota: Felix Bachmann, Mark Klein y madera de proyecto de ley son altos miembros del personal técnico en el Instituto de ingeniería de Software.

Cada buena calidad es nociva si sin mezclar.

— Ralph Waldo Emerson

Capítulo 4 caracteriza una serie de atributos de calidad del sistema. Esa caracterización fue en términos de una colección de escenarios. Comprender el significado de un atributo de calidad permite obtener los requisitos de calidad, pero no proporciona ninguna ayuda para entender cómo alcanzarlos. En este capítulo, comenzamos a proporcionar esa ayuda. Para cada uno de los atributos de calidad de seis sistema que elaboramos en el capítulo 4, proporcionamos orientación arquitectónica por su logro. Las tácticas que se enumeran aquí no cubren todos los atributos de calidad posible, pero vamos a ver tácticas para la integración en el capítulo 8.

Estamos interesados en cómo el arquitecto logra cualidades particulares. Los requisitos de calidad especifican las respuestas del software para alcanzar los objetivos de negocio. Nuestro interés es en las tácticas utilizadas por el arquitecto para crear un diseño utilizando patrones de diseño, patrones de arquitectura o estrategias arquitectónicas. Por ejemplo, podría ser un objetivo de negocio crear una línea de productos. Un medio para alcanzar ese objetivo es permitir la variabilidad de clases particulares de funciones.

Antes de decidir sobre un conjunto de patrones para lograr la deseada variación, el arquitecto debe considerar qué combinación de tácticas para modificabilidad debe aplicarse, como las tácticas elegidas guiarán las decisiones arquitectónicas. Un patrón de arquitectura o estrategia implementa una colección de tácticas. La conexión entre las necesidades de atributo de calidad (que se describen en el capítulo 4) y las decisiones de la arquitectura es objeto de este capítulo.

5.1 Introducción de tácticas

¿Qué es lo que imparte la portabilidad a un dibujo o modelo, a otro de alto rendimiento y integrabilidad a un tercer? El logro de estas cualidades se basa en las decisiones fundamentales del diseño. Examinaremos esas decisiones de diseño, que llamamos tácticas. Una táctica es una decisión de diseño que influye en el control de una respuesta de atributo de calidad. Pedimos una colección de las tácticas de una estrategia de arquitectura, que trataremos en el capítulo 12. Un patrón de arquitectura paquetes de tácticas de manera que se describen en la sección 5.6.

Un diseño de sistema consta de una colección de las decisiones. Algunas de estas decisiones ayudan a controlar las respuestas de atributo de calidad; otros garanticen el logro de la funcionalidad del sistema. En esta sección, discutimos las decisiones de atributo de calidad conocidas como tácticas. Representamos a esta relación en la figura 5.1. Las tácticas son las que arquitectos han estado utilizando desde hace años, y aislar y describirlas. No estamos inventando tácticas aquí, sólo captura lo que hacen arquitectos en la práctica.

Figura 5.1. Tácticas están destinadas a controlar las respuestas a estímulos.

Cada táctica es una opción de diseño para el arquitecto. Por ejemplo, una de las tácticas introduce redundancia para aumentar la disponibilidad de un sistema. Se trata de una opción, que el arquitecto ha de aumentar la disponibilidad, pero no el único. Suele lograr una alta disponibilidad mediante la redundancia, supone una necesidad concomitante de sincronización (garantizar que la copia redundante puede utilizarse si se produce un error en el original). Vemos dos ramificaciones inmediatas de este ejemplo.

Tácticas pueden refinar otras tácticas. Se identificaron redundancia como táctica. Como tal, puede ser refinado en la redundancia de datos (en un sistema de base de datos) o redundancia de computación (en un sistema de control integrado). Ambos tipos son también tácticas. Hay más mejoras que puede emplear un diseñador para concretar cada tipo de redundancia. Para cada atributo de calidad que discutir, organizamos las tácticas como una jerarquía.

Tácticas de paquete de patrones. Un patrón que soporta la disponibilidad es probable que usará una táctica de redundancia y de una táctica de sincronización. También es probable que utilizará las versiones más concretas de estas tácticas. Al final de esta sección, presentamos un ejemplo de un patrón que se describen en términos de sus tácticas.

Organizamos las tácticas para cada atributo de calidad del sistema como una jerarquía, pero es importante comprender que cada jerarquía está diseñado exclusivamente para mostrar algunas de las tácticas, y que cualquier lista de tácticas es necesariamente incompleto. Para cada uno de los seis atributos que elaboramos en el capítulo 4 (disponibilidad, modificabilidad, rendimiento, seguridad, Testabilidad y facilidad de uso), discutimos sobre enfoques tácticos para su realización. Para cada uno, presentamos una organización de las tácticas y una breve discusión. La organización pretende proporcionar una ruta de acceso para el arquitecto buscar tácticas adecuadas.

5.2 Tácticas de disponibilidad de

Recordar el vocabulario para disponibilidad del capítulo 4. Se produce un error cuando el sistema ya no ofrece un servicio que es consistente con su especificación; Este fracaso es observable por los usuarios del sistema. Un error (o una combinación de fallos) tiene el potencial para causar un error. Recordar también que la recuperación o la reparación es un aspecto importante de la disponibilidad. Las tácticas que discutimos en esta sección mantendrá fallas de convertirse en fallas o enlazado al menos los efectos de la falla y hacen posible la reparación. Ilustramos esto en la figura 5.2.

Figura 5.2. Objetivo de tácticas de disponibilidad

Muchas de las tácticas que discutimos están disponibles dentro de los entornos de ejecución estándar tales como sistemas operativos, servidores de aplicaciones y sistemas de gestión de base de datos. Es aún importante comprender las tácticas utilizadas para que los efectos del uso de un determinado uno puede considerarse durante el diseño y la evaluación. Todos los enfoques para mantener disponibilidad implican algún tipo de redundancia, algún tipo de control para detectar un error de la salud y algún tipo de recuperación cuando se detecta un fallo. En algunos casos, la supervisión o la recuperación es automática y en otros es manual.

En primer lugar, consideramos de detección de fallas. Nosotros, a continuación, considere la posibilidad de recuperación ante fallas y por último, brevemente, prevención de fallas.

DETECCIÓN DE FALLAS

Tres tácticas ampliamente utilizados para el reconocimiento de errores son excepciones, latido y ping/eco.

Ping/eco. Uno de los componentes emite un ping y espera recibir de vuelta un eco, dentro de un plazo predefinido, desde el componente bajo la lupa. Esto puede usarse dentro de un grupo de componentes mutuamente responsables de una tarea. También puede utilizar se utilizan los clientes para garantizar que un objeto de servidor y la ruta de comunicación con el servidor funcionen dentro de los límites del rendimiento esperado. Detectores de fallas "Ping/eco" pueden ser organizados en una jerarquía, en la que un detector de nivel inferior hace ping en los procesos de software con los que comparte un procesador, y los detectores de fallas de nivel superiores haga ping a los de nivel inferior. Esto utiliza menos ancho de banda de las comunicaciones que un detector de fallas remoto que hace ping en todos los procesos.

Latido (temporizador de hombre muerto). En este caso un componente emite un mensaje de latido periódicamente y se escucha otro componente. Si se produce un error en los latidos del corazón, el componente original se supone que han fracasado y se notifica un componente de corrección de errores. Los latidos del corazón también pueden transportar datos. Por ejemplo, un cajero automático puede enviar periódicamente el registro de la última transacción a un servidor. Este mensaje no sólo actúa como un latido de corazón, sino que también transmite datos a procesar.

Excepciones. Un método para reconocer errores es encontrar una excepción que se produce cuando una de las clases de errores que hemos debatido en el capítulo 4 se reconoce. El controlador de excepciones se ejecuta normalmente en el mismo proceso que introdujo la excepción.

Las tácticas de ping/echo y latido funcionan entre distintos procesos, y la táctica de excepción opera dentro de un único proceso. El controlador de excepciones por lo general lleva a cabo una transformación semántica de la falla en una forma que pueda ser procesada.

RECUPERACIÓN ANTE FALLAS

Recuperación ante fallas consiste en preparar para la recuperación y hacer la reparación del sistema. Siguen algunas tácticas de preparación y reparación.

A votar. Procesos que se ejecutan en los procesadores redundantes cada uno tener entrada equivalente y calculan un valor de salida simple que se envía a un votante. Si el votante detecta un comportamiento anormal de un solo procesador, no lo son. El algoritmo de voto puede ser "reglas de mayoría" o "componente preferido" o algún otro algoritmo. Este método se utiliza para corregir el funcionamiento defectuoso de algoritmos o el fracaso de un procesador y a menudo se utiliza en sistemas de control. Si todos los procesadores utilizan los mismos algoritmos, la redundancia detecta sólo un fallo de procesador y no un error de algoritmo. Por lo tanto, si la consecuencia de una falla es extrema, como la posible pérdida de la vida, los componentes redundantes pueden ser diversos.

Un extremo de la diversidad es que el software para cada componente redundante es desarrollado por diferentes equipos y se ejecuta en las plataformas de diferentes características. Menos extremo es desarrollar un componente de software único en diferentes plataformas. Es costoso para desarrollar y mantener la diversidad y se utiliza sólo en circunstancias excepcionales, como el control de las superficies en el avión. Por lo general se utiliza para sistemas de control en el que las salidas a los votantes son simples y fáciles de clasificar como equivalente o desviadas, los cálculos son cíclicos, y todos los componentes redundantes reciban entradas equivalentes de sensores. Diversidad no tiene tiempo de inactividad cuando se produce un error, ya que el votante sigue funcionando. Variaciones sobre este enfoque incluyen el enfoque Simplex, que utiliza los resultados de un componente "preferido" a menos que aparten de las de un componente "de confianza", a la que pospone. Sincronización entre los componentes redundantes es automático, ya que todos se supone que se computación en el mismo conjunto de insumos en paralelo.

Redundancia activa (hot reinicio). Todos los componentes redundantes responden a eventos en paralelo. En consecuencia, son todos en el mismo Estado. La respuesta de sólo un componente es utilizado (por lo general, la primera en responder), y el resto se descartan. Cuando ocurre una falla, el tiempo de inactividad de los sistemas que utilizan esta táctica es milisegundos desde la copia de seguridad es la actual y la única vez para recuperar es el tiempo de conmutación. Redundancia activa se utiliza

a menudo en una configuración cliente/servidor, tales como sistemas de gestión de base de datos, que respuestas rápidas sean necesarias incluso cuando se produce un error. En un sistema distribuido de alta disponibilidad, la redundancia puede ser en las rutas de comunicación. Por ejemplo, puede ser conveniente utilizar una red LAN con un número de caminos paralelos y colocar cada componente redundante en una ruta de acceso independiente. En este caso, un solo fallo de puente o ruta de acceso no hará todos los componentes del sistema no está disponible.

Se realiza la sincronización al asegurar que todos los mensajes a cualquier componente redundante se envían a todos los componentes redundantes. Si comunicación tiene una posibilidad de perderse (a causa de las líneas de comunicación ruidosos o sobrecargado), un protocolo de transmisión fiable puede utilizarse para recuperar. Un protocolo de transmisión fiable requiere que todos los destinatarios acusar recibo junto con alguna indicación de integridad, como una suma de comprobación. Si el remitente no puede comprobar que todos los destinatarios han recibido el mensaje, se vuelva a enviar el mensaje a esos elementos no acusando recibo. Los reenvíos de mensajes unreceived (posiblemente más de comunicación diferentes rutas) continúa hasta que el remitente marca al destinatario como fuera de servicio.

Redundancia pasiva (cálido reinicio/dual redundancia/triple redundancia). Uno de los componentes (primario) responde a los eventos e informa a los demás componentes (el estar) de las actualizaciones de Estado deben hacer. Cuando ocurre una falla, el sistema debe asegurar primero que el estado de copia de seguridad es suficientemente fresco antes de reanudar los servicios. Este enfoque también se utiliza en sistemas de control, a menudo cuando los insumos proceden sobre canales de comunicación o de sensores y tienen que cambiar de las primarias a la copia de seguridad en caso de fallo. Capítulo 6, que se describe un ejemplo de control de tráfico aéreo, muestra un sistema de usarlo. En el sistema de control de tráfico aéreo, la secundaria decide cuándo se debe tomar el relevo de la primaria, pero en otros sistemas, esta decisión es posible en otros componentes. Esta táctica depende de los componentes en espera hacerse cargo de forma fiable. Obligando a switchovers periódicamente — por ejemplo, una vez al día o una vez por semana: aumenta la disponibilidad del sistema. Algunos sistemas de base de datos de forzar la conmutación con almacenamiento de información de cada elemento de datos nuevos. El nuevo elemento de datos se almacena en una página de la sombra y la página antigua se convierte en una copia de seguridad para la recuperación. En este caso, el tiempo de inactividad por lo general puede ser limitado a segundos.

La sincronización es la responsabilidad de la componente principal, que puede utilizar emisiones atómicas a las secundarias para garantizar la sincronización.

De repuesto. Un plataforma de computación de repuesto en espera está configurado para sustituir cualquier componente fallido diferente. Se debe reiniciar para que la configuración de software apropiado y tienen su estado inicializa cuando se produce un error. Hacer un punto de comprobación de estado del sistema a un dispositivo

persistente periódicamente y registro de todos los cambios de Estado a un dispositivo persistente permite el spare para establecerse en el estado adecuado. Esto se utiliza a menudo como la estación de trabajo cliente en espera, donde el usuario puede mover cuando ocurre una falla. El tiempo de inactividad para esta táctica es por lo general unos minutos.

Hay tácticas para la reparación que se basan en la reintroducción de componente. Cuando se produce un error en un componente redundante, puede ser presentada de nuevo después de se ha corregido. Estas tácticas son operación de sombra, estado resincronización y rollback.

Operación de sombra. Puede ejecutar un componente previamente fallido en "modo de sombra" por un corto tiempo para asegurarse de que imita el comportamiento de los componentes de trabajo antes de restaurarla al servicio.

Resincronización estatal. Las tácticas de redundancia activa y pasiva requieren el componente que se va a restaurar su estado actualizado antes de su retorno al servicio. El enfoque de actualización dependerá el tiempo de inactividad que puede mantenerse, el tamaño de la actualización y el número de mensajes requeridos para la actualización. Un único mensaje que contiene el Estado es preferible, si es posible. Actualizaciones de estado incremental, con períodos de servicio entre incrementos, llevan a software complicado.

Punto de comprobación/rollback. Un punto de comprobación es una grabación de un estado coherente creada periódicamente o en respuesta a eventos específicos. A veces un sistema no cumple de manera inusual, con un Estado detectar incoherente. En este caso, el sistema debe restaurarse utilizando un punto de comprobación anterior de un estado consistente y un registro de las transacciones que se ha producido desde que se tomó la instantánea.

PREVENCIÓN DE ERRORES

Las siguientes son algunas tácticas de prevención de fallas.

Eliminación del servicio. Esta táctica quita un componente del sistema de operación a someterse a algunas de las actividades para prevenir fallas previstos. Un ejemplo está reiniciando un componente para evitar fugas de memoria causando una falla. Si esta eliminación del servicio es automática, una estrategia de arquitectura puede diseñarse para apoyarlo. Si es manual, el sistema debe estar diseñado para apoyarlo.

Transacciones. Una transacción es la agrupación de varios pasos secuenciales tal que a la vez el paquete completo puede deshacerse. Las transacciones se utilizan para evitar que los datos se vean afectados si se produce un error en un paso en un proceso y también para prevenir colisiones entre varios subprocesos simultáneos, acceso a los mismos datos.

Monitor de procesos. Una vez que se ha detectado un fallo en un proceso, un proceso de vigilancia puede eliminar el proceso nonperforming y crear una nueva instancia de la misma, inicializada a algún Estado apropiado como en la táctica de repuesto.

Figura 5.3 resume las tácticas que acabamos de analizar.

Figura 5.3. Resumen de las tácticas de disponibilidad

5.3 Tácticas de modificabilidad deRecuerda, en el capítulo 4, que tácticas para control de modificabilidad tienen como objetivo controlar el tiempo y el costo de implementar, probar e implementar cambios. Figura 5.4 muestra esta relación.

Figura 5.4. Objetivo de tácticas de modificabilidad

Organizamos las tácticas para modificabilidad en conjuntos de acuerdo con sus metas. Un conjunto tiene como objetivo reducir el número de módulos que son directamente afectados por un cambio. Llamamos a este conjunto "traducir las modificaciones". Un segundo conjunto tiene como objetivo limitar las modificaciones a los módulos localizadas. Utilizamos este conjunto de tácticas para "evitar que el efecto rizo". Implícito en esta distinción es que hay módulos directamente afectados (aquellos cuyas responsabilidades se ajustan para lograr el cambio) y indirectamente afectado por un cambio (aquellos cuyas responsabilidades no se modifican, pero cuya aplicación debe cambiarse para dar cabida a los módulos directamente afectados). Un tercer conjunto de tácticas tiene como objetivo controlar el tiempo de implementación y costo. Llamamos a este conjunto "aplazar el enlace de tiempo".

LOCALIZAR LAS MODIFICACIONES

Aunque no necesariamente es una relación precisa entre el número de módulos afectados por un conjunto de cambios y el costo de aplicar esos cambios, el restringir las modificaciones a un pequeño conjunto de módulos generalmente reducirá el costo. El objetivo de tácticas en este conjunto consiste en asignar responsabilidades a los módulos durante el diseño tal que prevé cambios está limitados en su alcance. Identificamos cinco esas tácticas.

Mantener la coherencia semántica. Coherencia semántica se refiere a las relaciones entre responsabilidades en un módulo. El objetivo es garantizar que todas estas responsabilidades trabajan juntos sin excesiva dependencia de otros módulos. Logro de este objetivo se viene desde la elección de responsabilidades que tienen coherencia semántica. Métricas de acoplamiento y de cohesión son un intento de medir la coherencia semántica, pero faltan en el contexto de un cambio. En su lugar, la coherencia semántica debe medirse contra un conjunto de cambios previstos. Una subtactic es abstraer servicios comunes. Prestación de servicios comunes a través de módulos especiales es visto generalmente como un apoyo a su reutilización. Esto es correcto, pero también abstraer servicios comunes admite modificabilidad. Si han sido resumieron los servicios comunes, las modificaciones que se les tendrá que hacerse una sola vez, en lugar de en cada módulo donde se utilizan los servicios. Por otra parte, modificación a los módulos de utilizar esos servicios no afectará a otros usuarios. Esta táctica, pues, admite localización no sólo de las modificaciones, pero también la prevención de los efectos de rizo. Ejemplos de abstraer servicios comunes son el uso de marcos de aplicación y el uso de otro software de middleware.

Anticipar los cambios esperados. Teniendo en cuenta el conjunto de cambios previstos proporciona una manera de evaluar una asignación especial de responsabilidades. La pregunta básica es "Para cada cambio, does la descomposición propuesta limitar el conjunto de módulos que deben ser modificados para lograrlo?" Una pregunta asociada es "fundamentalmente diferentes cambios afectan los módulos mismos?" ¿Cómo es diferente de coherencia semántica? Asignar responsabilidades basados en coherencia semántica asume que semánticamente coherentes cambios esperados. La táctica de anticipar los cambios

esperados no preocuparse a la coherencia de las responsabilidades de un módulo de sino más bien de minimizar los efectos de los cambios. En realidad, esta táctica es difícil de utilizar por sí mismo, ya que no es posible anticipar todos los cambios. Por esa razón, normalmente sirve junto con coherencia semántica.

Generalizar el módulo. Haciendo un módulo más general permite calcular una gama más amplia de funciones basadas en la entrada. La entrada puede ser pensado de como la definición de un lenguaje para el módulo, que puede ser tan simple como hacer parámetros de constantes de entrada o tan complicado como implementar el módulo como intérprete y hacer los parámetros de entrada un programa en lenguaje del intérprete. El general más un módulo, más probable pidió cambios pueden hacerse por adjusing el idioma de entrada, en lugar de mediante la modificación del módulo.

Limitar las opciones posibles. Modificaciones, especialmente dentro de una línea de productos (ver capítulo 14), puede ser que ahora van y, por tanto, afectar a muchos módulos. La restricción de las posibles opciones será reducir el efecto de estas modificaciones. Por ejemplo, un punto de variación en una línea de productos puede ser que permite un cambio de procesador. Restringir los cambios de procesador a los miembros de la misma familia limita las opciones posibles.

EVITAR LOS EFECTOS DE RIZO

Un efecto multiplicador de una modificación es la necesidad de realizar cambios a los módulos no afectados directamente por él. Por ejemplo, si se cambia módulo a realizar una modificación particular, entonces módulo que b se cambia sólo a causa del cambio al módulo a. B tiene que modificarse porque depende, en cierto sentido, a.

Comenzamos nuestra discusión del efecto rizo con un análisis de los diversos tipos de dependencias que un módulo puede tener en otra. Identificamos ocho tipos:

1. Sintaxis de

-datos. B compilar (o ejecutar) correctamente, el tipo (o formato) de los datos que se produce por el a y consumidos por b debe ser coherente con el tipo (o formato) de datos asumidas por B.

-servicio. Para que b compilar y ejecutar correctamente, la firma de servicios prestados por el a y invocado por b debe ser coherente con los supuestos de B.

2. Semántica de

-datos. Para que b ejecutar correctamente, la semántica de los datos producidos por el a y consumidos por b debe ser coherente con los supuestos de B.

-servicio. Para que b ejecutar correctamente, la semántica de los servicios producidos por el a y utilizados por b debe ser coherente con los supuestos de B.

3. Secuencia de

-datos. Para que b ejecutar correctamente, deben recibir los datos producidos por el a en una secuencia fija. Por ejemplo, encabezado de un paquete de datos debe preceder a su cuerpo en el orden de recepción (a diferencia de los protocolos que tienen el número de secuencia integrado en los datos).

-control. Para que b ejecutar correctamente, A debe han ejecutado anteriormente dentro de ciertas limitaciones de tiempo. Por ejemplo, A debe han ejecutado no más de 5 ms antes de b se ejecuta.

4. Identidad de una interfaz de la a. A puede tener varias interfaces. Para que b compilar y ejecutar correctamente, la identidad (nombre o identificador) de la interfaz debe ser coherente con los supuestos de B.

5. Ubicación de un (tiempo de ejecución). Para que b ejecutar correctamente, la ubicación de tiempo de ejecución de la a debe ser coherente con los supuestos de B. Por ejemplo, B puede asumir que a se encuentra en un proceso diferente en el mismo procesador.

6. Calidad de servicio/datos proporcionados por el a. Para que b ejecutar correctamente, alguna propiedad que participan de la calidad de los datos o el servicio prestado por el debe ser coherente con las hipótesis de B. Por ejemplo, los datos proporcionados por un sensor particular deben tener una cierta precisión a fin de que los algoritmos de b para que funcione correctamente.

7. Existencia de a. Para que b ejecutar correctamente, debe existir A. Por ejemplo, si b es que solicita un servicio desde un objeto a y a no existe y no se pueden crear de forma dinámica, entonces b no se ejecutará correctamente.

8. Comportamiento de los recursos de la a. Para que b ejecutar correctamente, el comportamiento de los recursos de la a debe ser coherente con las hipótesis de B. Esto puede ser cualquier uso de los recursos de la A (A usa la misma memoria como B) o la propiedad de recursos (B reserva un recurso que a cree posee).

Con esta comprensión de los tipos de dependencia, ahora podemos discutir tácticas disponibles al arquitecto para prevenir el efecto rizo para determinados tipos.

Tenga en cuenta que ninguna de nuestras tácticas necesariamente prevenir el rizo de cambios semánticos. Comenzamos con la discusión de los que son pertinentes a las interfaces de un módulo en particular — información oculta y el mantenimiento de las interfaces existentes — y siga con uno que rompe una cadena de dependencia: el uso de un intermediario.

Ocultar la información. Ocultación de información es la descomposición de las responsabilidades para una entidad (un sistema o algunos descomposición de un sistema) en piezas más pequeñas y elegir qué información para hacer que se va a hacer público y privado. Las responsabilidades públicas están disponibles a través de interfaces especificadas. El objetivo es aislar cambios dentro de un módulo y evitar que los cambios se propaguen a otros. Esta es la técnica más antigua para la prevención de cambios de materiales de multiplicación. Está fuertemente relacionado con "prever cambios esperados" porque utiliza esos cambios como base para la descomposición.

Mantener las interfaces existentes. Si b depende el nombre y la firma de una interfaz de la A, mantenimiento de esta interfaz y su sintaxis permite b para permanecer sin cambios. Por supuesto, esta táctica no necesariamente funciona si b tiene una dependencia semántica A, ya que los cambios en el significado de los datos y servicios son difíciles de máscara. Además, es difícil a las dependencias de la máscara en la calidad de los datos o la calidad del servicio, uso de recursos o la propiedad de recursos. Estabilidad de interfaz también se consigue al separar la interfaz de la aplicación. Esto permite la creación de interfaces abstractas de las variaciones de esa máscara. Pueden estar materializadas las variaciones dentro de las obligaciones contraídas, o que pueden ser consagrados al reemplazar una implementación de un módulo con el otro.

Incluyen patrones que implementan esta táctica

-agregar interfaces. La mayoría de lenguajes de programación permiten múltiples interfaces. Recién servicios visibles o datos pueden quedar disponibles a través de interfaces nuevas, lo que permite las interfaces existentes no se modifican y proporcionar la misma firma.

-Agregar adaptador. Agregar un adaptador a la a que envuelve a y proporciona la firma de la original de a.

-proporcionar un stub A. Si la modificación se pide la supresión de la a y, a continuación, establecer un código auxiliar para a permitirá b permanecer sin cambios si b depende sólo por firma la.

Restringir las rutas de comunicación. Restringir los módulos con el que un determinado módulo comparte datos. Es decir, reducir el número de módulos que consumen datos producidos por el módulo determinado y el número de módulos que producir datos consumidas por el mismo. Esto reducirá el efecto Rizo ya producción/consumo de datos presenta las dependencias que causan las ondulaciones. Capítulo 8 (simulación de vuelo) describe un patrón que utiliza esta táctica.

Utilizar a un intermediario. Si b tiene cualquier tipo de dependencia por un otro que semántico, es posible insertar un intermediario entre b y a que administra las actividades asociadas con la dependencia. Todos estos intermediarios van por diferentes nombres, pero vamos a debatir cada uno de los tipos de dependencia que hemos enumerado. No como antes, en el peor de los casos, un intermediario puede compensar cambios semánticos. Los intermediarios son

-datos (sintaxis). Repositorios (pizarra y pasivo) actúan como intermediarios entre el productor y el consumidor de datos. Los repositorios pueden convertir la sintaxis producida por el a en que asumió por B. Algunos patrones de publicación/suscripción (aquellos que tienen datos que fluye a través de un componente central) también pueden convertir la sintaxis en que asumió por B. Los patrones MVC y el PAC conversión los datos en un formalismo (dispositivo de entrada o de salida) a otro (que se utiliza por el modelo en MVC o la extracción en PAC).

-servicio (sintaxis). Los patrones de fachada, el puente, mediador, estrategia, proxy y fábrica todos proporcionan a intermediarios que convierten la sintaxis de un servicio de una forma a otra. Por lo tanto, todo sirve para evitar que los cambios en el a se propaguen a B.

-la identidad de una interfaz de la a. Un patrón de intermediario puede utilizarse para enmascarar los cambios en la identidad de una interfaz. Si b depende de la identidad de una interfaz de la a y cambios de identidad, mediante la adición de esa identidad al intermediario y el intermediario de realicen la conexión a la nueva identidad de la A, B puede permanecer sin cambios.

-ubicación de un (tiempo de ejecución). Un servidor de nombres permite la ubicación a cambiarse sin afectar a la B. A es responsable del registro de su ubicación actual con el servidor de nombres, y b recupera esa ubicación desde el servidor de nombres.

-comportamiento de los recursos de la a o recurso controlado por el a. Un administrador de recursos es un intermediario que es responsable de la asignación de recursos. Algunos administradores de recursos (por ejemplo, aquellas basadas en análisis monótono de tasa en sistemas de tiempo real), pueden garantizar la satisfacción de todas las solicitudes dentro de ciertas limitaciones. A, por supuesto, debe renunciar a control del recurso para el administrador de recursos.

-existencia de la a. El patrón de fábrica tiene la capacidad de crear instancias según sea necesario, y por lo tanto, la dependencia de b de la existencia del a está satisfecho por las acciones de la fábrica.

APLAZAR EL ENLACE DE TIEMPO

Las categorías de dos táctica que hemos discutido hasta ahora están diseñadas para reducir al mínimo el número de módulos que requieren cambiar para aplicar las modificaciones. Nuestros escenarios de modificabilidad son dos elementos que no están satisfechos al reducir el número de módulos que cambiar: el tiempo de implementación y que permite nondevelopers realizar cambios. Aplazamiento de enlace de tiempo soporta ambos de estos escenarios a costa de que requieren una infraestructura adicional para admitir el enlace.

En diversas ocasiones se pueden enlazar las decisiones en el sistema de ejecución. Las que afectan a tiempo de implementación discutimos sobre. La implementación de un sistema viene dictada por algún tipo de proceso. Cuando se realiza una modificación por el desarrollador, suele haber un proceso de pruebas y distribución que determina el tiempo que transcurre entre la realización del cambio y la disponibilidad de ese cambio al usuario final. Enlace en tiempo de ejecución significa que el sistema se ha preparado para ese enlace y se han completado todos los pasos de pruebas y distribución. Aplazamiento de enlace de tiempo también es compatible con lo que permite al usuario final o el administrador del sistema realizar la configuración o brindar información que afecta al comportamiento.

Muchas tácticas están destinadas a tener impacto en tiempo o en tiempo de ejecución, como los siguientes.

Registro de tiempo de ejecución es compatible con la operación de "plug-and-play" a costa de una sobrecarga adicional para administrar el registro. Registro de publicación/suscripción, por ejemplo, puede implementarse en tiempo de ejecución o de carga.

Archivos de configuración están destinados a establecer parámetros en el inicio.

Polimorfismo permite el enlace de llamadas a métodos.

Reemplazo de componentes permite el enlace en tiempo de carga.

Cumplimiento de protocolos definidos permite el enlace de tiempo de ejecución de procesos independientes.

Las tácticas de modificabilidad se resumen en la figura 5.5.

Figura 5.5. Resumen de las tácticas de modificabilidad