c



    
É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.

   
   

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 SISTEMA

Muchas 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.

       

?

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.

m 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.

c
      

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.
      

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 2m
m 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 vista

Arquitectura 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 referencia

Entre 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 2m2m Las relaciones de modelos de referencia, patrones de arquitectura,
arquitecturas de referencia y arquitecturas de softwarem (Las flechas indican que los
conceptos siguientes contienen más elementos de diseño)m

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 INTERESADAS
Cada 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ÑO
Arquitectura 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ón

Una 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 arquitectura

No 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 sistema

Si 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 cambio

La 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 evolutivos

Una 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ón

Las 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, REUTILIZABLE

Cuanto 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ún

Una 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 exterior
Considerando 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ño

Tal 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 plantilla

Una 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ón

La 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.

2m 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 muestranm

? 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 SOFTWARE
En 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ódulo
Las siguientes las estructuras basadas en el módulo.

? Descomposiciónm 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 capasm 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ónm 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 conector
Estas estructuras incluyen lo siguiente.

? Proceso, o procesos de comunicaciónm 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.

? Concurrenciam 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 repositoriom 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ón
Las siguientes estructuras de asignación.

? Desplieguem 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ónm 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 trabajom 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 2m
se resumen las estructuras de softwarem 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 param

Estructura del software Las relaciones Útil para

Descomposición Es un submódulo de; secreto Asignación de recursos y la
de accion 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ógicam 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.

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

? Desarrollom 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ísicam 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.

2m Resumen
Este 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 adicionales

Los 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 3m 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.

3m
Relación con el ciclo de negocio de arquitectura

La 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 3m
m 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.
3m2 Requisitos y cualidades
Figura 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 3m3m 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.

3m3 Arquitectura para el sistema de aviónica de A-7E

La 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ÓN
A 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ón
La 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 Ocultación de información
plataforma, la simbología, de entrada
Comprender los cambios previstos Procedimiento de evaluación formal para
tomar
Asignar los equipos de trabajo para que se Módulos estructurados como una jerarquía;
redujeron sus interacciones 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-7E

Para 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 3m m 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 USOS
La 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 usos
El 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 arquitectura
Una 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 m Atributos de calidad de entendimiento

con 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.

m
La funcionalidad y la arquitectura
Atributos 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.

m2 La arquitectura y los atributos de calidad

Logro 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.

m3 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 CALIDAD

Un 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 m
m 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 m2m 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 m3m 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 modificabilidad
Un 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 m m 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.

m 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 General

De 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

MODIFICABILIDAD
Modificabilidad 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 General

De 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ímulom 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.

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

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

? Respuestam 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 respuestam 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 mm 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 ambientem 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 m muestra en la tabla de generación de escenario general de seguridadm

Tabla m m Generación de escenario de Seguridad General

TESTABILIDAD
Testabilidad 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 General

Figura 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 m7m Escenario de ejemplo Testabilidad

? Fuente de estímulom 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ímulom 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.

? Artefactom 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 ambientem 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.

? Respuestam 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 respuestam 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 mm 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 aprendizajem 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 erroresm ¿Qué puede hacer el sistema para que un error
de usuario tiene un impacto mínimo?

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

? Aumento de confianza y satisfacciónm ¿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ímulom 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.

? Artefactom El artefacto es siempre el sistema.

? Medio ambientem 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 mm

Cuadro mm 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.

m Otros atributos de calidad del sistema

Hemos 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.

m 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ónm 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 beneficiom 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 sistemam 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 destinom 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 heredadosm 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.

m7 Cualidades de la arquitectura de
Ademá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 cualidades

con 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.

m
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.

m2 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 votarm 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)m 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 repuestom 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 sombram 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/rollbackm 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 serviciom 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.

? Transaccionesm 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 procesosm 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 m3m Resumen de las tácticas de disponibilidad

m3 Tácticas de modificabilidad de

Recuerda, 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 m m 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ónm 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ónm 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 intermediariom 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