chapter 1-2-spanish.pdf

Capítulo 1
Introducción
ÿ ¿Cuál es el papel del arquitecto en un proyecto de desarrollo de software?
ÿ ¿Qué es una arquitectura?
1
Bjarne Stroustrup, el inventor del lenguaje de programación C++, dijo una vez: “Nuestra
civilización funciona con software”. De hecho, el software toca muchos aspectos de
nuestra vida cotidiana y se encuentra en algo tan simple como una tarjeta de cumpleaños
que canta "Feliz cumpleaños" cuando se abre en el omnipresente teléfono celular y, por
supuesto, en sistemas muy complejos como aviones y energía nuclear. estaciones De
hecho, muchas de las innovaciones que damos por sentado hoy en día, y organizaciones
como eBay o Amazon, simplemente no existirían si no fuera por el software. Incluso las
organizaciones tradicionales, como las de los sectores financiero, minorista y público,
dependen en gran medida del software. Hoy en día, es difícil encontrar una organización
que no esté en el negocio del software de alguna manera.
Aquí es donde entra en juego el proceso de arquitectura . Si se va a mantener esta
dependencia cada vez mayor en el software, el software debe proporcionar la capacidad
requerida, ser de calidad suficiente, estar disponible cuando se prometió y entregarse a
un precio aceptable. Todas estas características están directamente influenciadas por la
arquitectura del software, y se deduce que si hacemos un buen trabajo de arquitectura ,
es más probable que alcancemos los objetivos deseados.
El propósito de este libro es guiarlo a través de las tareas y las mejores prácticas
asociadas que se aplican en la arquitectura de un sistema de software. Para cumplir con
este objetivo, el libro abordará algunas preguntas básicas, como las siguientes:
Machine Translated by Google

2 | Capítulo 1 Introducción
El proceso en resumen
Aplicar el proceso
Una visión general de alto nivel de las actividades macro que componen el proceso es
Al responder tales preguntas, presentamos una serie de mejores prácticas que se manifiestan
en los roles, tareas y productos de trabajo descritos a lo largo de este libro.
Estas prácticas se pueden incorporar dentro de cualquier proceso que pueda usar, incluidos
aquellos caracterizados como un proceso en cascada, un proceso de desarrollo iterativo (como
Rational Unified Process) o un proceso ágil (como Scrum). Como tal, no asociamos las prácticas
con ningún proceso en particular, aunque presentamos las prácticas en una secuencia que nos
permite demostrar las relaciones entre ellas y su relevancia en diferentes puntos del ciclo de vida
del proyecto. Lo alentamos a elegir aquellas prácticas que agregarán el mayor valor a sus
proyectos y, por supuesto, a sus arquitecturas.
Yendo directo al grano, pensamos que valdría la pena brindarle un breve recorrido por los
elementos clave del proceso descritos en este libro para abrirle el apetito. Aquí, nos enfocamos
en un solo paso a través de las tareas descritas en detalle en este libro (a las que nos referiremos
como una iteración) aunque, por supuesto, podemos ejecutar cada una de las tareas muchas
veces en un proyecto.
se muestra en la Figura 1.1, alineado con las disciplinas de ingeniería de software.
ÿ ¿Cuándo y cómo produce el arquitecto una arquitectura inicial? ÿ ¿Cómo refina el
arquitecto la arquitectura?
ÿ ¿Cómo se valida una arquitectura?
ÿ ¿Cuál es la relación del arquitecto con los demás roles del proyecto? ÿ ¿Cuál es el
papel del arquitecto con respecto a los requisitos? ÿ ¿Cómo se describe una arquitectura?
ÿ ¿Cuándo considera el arquitecto la reutilización?
[Una disciplina es un] mecanismo de categorización primario para organizar tareas
que definen un “área de interés principal: y/o cooperación de esfuerzo de trabajo.
(Abrir 2008)
Una práctica es un enfoque para resolver uno o varios problemas comunes. Las
prácticas están pensadas como "fragmentos" del proceso para su adopción,
habilitación y configuración. (RUP 2008)

Figura 1.1 Descripción general de la actividad
Arquitectura
Crear lógico
Crear físico
Requisitos Diseño detallado
El proceso en breve | 3
Definir
Diseño detallado
Crear lógico
Crear físico
Arquitectura
Como puede ver, las actividades de arquitectura se sitúan entre los requisitos
y el desarrollo. La iteración comienza con la definición de los requisitos de software
en la actividad Definir requisitos . Aunque esta actividad es principalmente
responsabilidad del analista comercial, el arquitecto participará en algunas de las
tareas detalladas que comprenden esta actividad. Posteriormente, el arquitecto
crea una arquitectura de primer corte en la actividad Crear arquitectura lógica .
La arquitectura resultante es independiente de cualquier consideración tecnológica
y se denomina arquitectura lógica. Considere esto como un trampolín para pasar
de los requisitos a una arquitectura física, que es específica de la tecnología y
forma la base de la implementación (codificación). La arquitectura lógica se incluye
en cualquier diseño detallado que se realice en la actividad Crear diseño
detallado lógico . Esta actividad da como resultado la adición de cualquier detalle
restante que pueda ser necesario a nivel lógico pero que no se considere
arquitectónico. Para obtener una explicación de la diferencia entre arquitectura y
diseño detallado, consulte la barra lateral "Concepto: arquitectura versus diseño".
Según los requisitos, la arquitectura lógica y el diseño lógico detallado, el
arquitecto refina la arquitectura en la actividad Crear arquitectura física , que
tiene en cuenta la tecnología, lo que da como resultado la arquitectura física. Esta
es una entrada para cualquier diseño detallado que se realice en la actividad
Crear diseño físico detallado , que constituye la base de la implementación.
Desarrollo
Requisitos Arquitectura

Toda arquitectura es diseño, pero no todo diseño es arquitectura. La arquitectura representa
las decisiones de diseño significativas que dan forma a un sistema, donde la importancia se mide
por el costo del cambio. (Boocho 2009)
Dicho de otra manera, la arquitectura puede ser considerada como un diseño estratégico,
mientras que el diseño detallado se considera diseño táctico.
sugiere su nombre, se enfoca en comprender las necesidades de los diversos interesados.
puede encontrar que se necesita una aclaración de los requisitos y puede revisar el
interés para el arquitecto, porque define los elementos externos que deben
se puede lograr de manera realista con la tecnología disponible, dentro de los requisitos
se refiere a las tareas, el arquitecto está particularmente involucrado en el Priorizar
secuencia, sólo una secuencia probable. Con base en la arquitectura realizada, usted
tarea Vocabulario común , la tarea Definir contexto del sistema es de particular
Ahora analicemos un poco más a fondo algunas de estas actividades para que pueda
En este contexto, las tareas Esquema de requisitos funcionales y Esquema de requisitos
no funcionales identifican los requisitos funcionales y no funcionales, respectivamente. El
arquitecto está interesado no sólo en la clave funcional
stakeholders en los que el arquitecto participa activamente. En cuanto a los requisitos
interactuar con el sistema, como los usuarios finales y otros sistemas. Basado en esto
requisitos como resultado, por ejemplo.
Tarea de requisitos , en la que el arquitecto se asegura de que las prioridades se vean
influidas por aquellos requisitos y riesgos que permitirán que la arquitectura se estabilice lo
antes posible.
Las tareas que comprenden la actividad Definir requisitos se muestran en la Figura 1.2.
a menudo más difíciles de abordar que los requisitos funcionales.
La iteración comienza con la tarea Recopilar solicitudes de partes interesadas , que, como su
apreciar mejor el papel del arquitecto dentro de la iteración. el detallado
requisitos, sino también en las cualidades del sistema (como el rendimiento) y las restricciones
de solución que comprenden los requisitos no funcionales, que son
Las flechas que vinculan las actividades no pretenden mostrar un resumen
Las solicitudes proporcionan al arquitecto una indicación inicial del alcance del sistema que se
va a diseñar. Después de desarrollar un vocabulario de términos en el Captura
El arquitecto está involucrado, hasta cierto punto, a lo largo de las actividades de
definición de requisitos para garantizar que los requisitos se especifiquen de manera que
cronograma y dentro del presupuesto. Esto a menudo requiere cierto grado de negociación con
Aunque el diseño detallado y las actividades de implementación no son responsabilidad del
arquitecto, brindan orientación al equipo según sea necesario.
Concepto: Arquitectura versus Diseño

Figura 1.2 Tareas en la actividad Definir requisitos
Los requisitos priorizados impulsan el contenido del resto de la iteración, en
el sentido de que solo se consideran los requisitos de mayor prioridad, porque la
medida en que aborde estos requisitos determina si tiene un sistema viable. (Los
requisitos de menor prioridad se consideran en iteraciones posteriores). Los
requisitos de alta prioridad se detallan en las tareas Detalle de requisitos
funcionales y Detalle de requisitos no funcionales . Luego, el arquitecto
documenta formalmente un resumen de los requisitos significativos desde el punto
de vista arquitectónico en la tarea Actualizar documento de arquitectura de
software . Las tareas relacionadas con los requisitos concluyen con una revisión
de los requisitos en la tarea Revisar requisitos con las partes interesadas . En
cuanto a las actividades, las flechas que vinculan las tareas no pretenden mostrar
una secuencia estricta y rápida (solo una secuencia probable), y las tareas pueden revisars
Requisitos
Requisitos
Actualiza el software
esquema funcional
Requisitos
Recopilar parte interesada
Requisitos
Documento de arquitectura con las partes interesadas
Esquema no funcional
Requisitos de revisión
Requisitos
Vocabulario
Peticiones
priorizar
Detalle Funcional
Captura común
Contexto
Detalle No Funcional
Definir sistema

Verificar
Arquitectura del documento
Prueba de concepto
Arquitectura
Revisar la arquitectura con
las partes interesadas
Visión de conjunto
Construir arquitectura
esquema funcional
Elementos
Documento de Arquitectura
Decisiones
Detalle Funcional
Esquema de implementación
Elementos
Elementos
Elementos
Arquitectura topográfica
Implementación detallada
Definir Arquitectura
Arquitectura
Validar Actualiza el software
Activos
descripción general proporciona el esquema de "panorama general" de la arquitectura.
Luego, las tareas Esquema de elementos funcionales y Esquema de elementos
de implementación se realizan simultáneamente, refinando posteriormente este
esquema en términos de componentes, sus interacciones y relaciones, y su
implementación en los nodos. La tarea Verificar arquitectura garantiza que los
diversos elementos funcionales y de implementación que componen la arquitectura sean cohere
Las tareas que componen la actividad Crear Arquitectura Lógica se muestran
en la Figura 1.3. A lo largo de esta actividad, el arquitecto considera el uso de activos
existentes en la tarea Levantar activos de arquitectura . Incluso al principio del
proyecto, usted puede, como arquitecto, seleccionar un activo como una arquitectura
de referencia que tenga una influencia significativa en su arquitectura. A medida que
se realiza cada tarea, el arquitecto captura esas decisiones en la tarea Decisiones de
arquitectura del documento .
En función de los requisitos de mayor prioridad, el arquitecto describe la solución
candidata en la tarea Definir descripción general de la arquitectura . La arquitectura
Figura 1.3 Tareas en la actividad Crear arquitectura lógica

incluyendo diseñadores, programadores, evaluadores, gerentes de proyectos, mantenedores y
riesgos y, a menudo, adopta la forma de software ejecutable que permite evaluar la
funcionalidad y las cualidades del sistema.
Como se indica en la Figura 1.1, el conjunto de productos de trabajo relacionados con la arquitectura
productos que se generan a partir de las fuentes de actividades Crear arquitectura física
la base de la implementación. La implementación finalmente da como resultado una versión
ejecutable del software que luego se prueba para garantizar que cumpla con los requisitos
asociados con la iteración actual. Comentarios sobre la arquitectura de
la prueba de concepto proporciona un vehículo para mitigar ciertos problemas relacionados con la arquitectura
tarea permite establecer un acuerdo sobre la arquitectura.
Tareas Elementos y Detalle Elementos de Despliegue . La tarea Validar arquitectura
garantiza que los elementos arquitectónicos satisfarán los requisitos
en particular, se asegura de que cualquier inquietud que afecte a estos elementos (por
ejemplo, una cualidad como el rendimiento que influya tanto en los elementos funcionales
como en los de implementación) se haya abordado adecuadamente. Reconocemos que
agrega detalles a los elementos de arquitectura identificados, antes de pasar a la
nivel de detalle a los elementos de arquitectura identificados y que pueden ser utilizados como
A continuación, se detallan los elementos arquitectónicos en el Detalle Funcional
posteriormente alimenta la actividad Crear diseño detallado lógico , que
como restricciones de recursos, presupuesto y cronograma. Luego, el arquitecto documenta
un resumen de la arquitectura independiente de la plataforma en la actualización .
La actividad Crear arquitectura física contiene exactamente el mismo
El arquitecto también se enfoca en probar ciertos aspectos de la arquitectura en
Los elementos funcionales y de implementación no dominan necesariamente todas las
arquitecturas (por ejemplo, los elementos de concurrencia pueden dominar un sistema
integrado en tiempo real), por lo que en el Capítulo 4, "Documentación de una arquitectura de software",
como se indica (tanto funcional como no funcional), así como las consideraciones del proyecto
Tarea Documento de arquitectura de software . La descripción de la arquitectura resultante
se utiliza para comunicar la arquitectura a las partes interesadas relevantes,
Introducir un marco de descripción de arquitectura extensible para acomodar tales
preocupaciones.
Crear actividad de Arquitectura Física .
si existe tal solución, tal como la concibió el arquitecto. En particular, el
personal de apoyo. Finalmente, la Arquitectura de Revisión con las Partes Interesadas
tareas como las de la actividad Crear arquitectura lógica , pero tiene en cuenta
consideraciones tecnológicas. Por lo tanto, las tareas adoptan mejores prácticas adicionales
que reconocen esta diferencia. El conjunto de trabajos relacionados con la arquitectura.
en la actividad Crear Diseño Detallado Físico , que agrega los datos relevantes
la tarea de prueba de concepto de arquitectura de compilación . El objetivo es sintetizar
el tamaño de al menos una solución (que puede ser simplemente conceptual en lugar de
física) que satisfaga los requisitos arquitectónicamente significativos para determinar

las actividades de revisión y prueba de la arquitectura ayudan a guiar las prioridades y el
contenido de la siguiente iteración.
Este capítulo se centró en preparar el escenario para el resto del libro. Antes de profundizar
en los detalles, debemos establecer algunos conceptos básicos, que utilizaremos
ampliamente en los capítulos restantes. Estos conceptos son el papel del arquitecto, las
características de las tareas arquitectónicas que realizan y la arquitectura que resulta.
Todos estos conceptos se describen en el Capítulo 2.
Este libro se centra en los sistemas intensivos en software. Por lo tanto, los términos
arquitectura, arquitecto y arquitectura, cuando no están calificados, son sinónimos de los
términos arquitectura de software, arquitecto de software y arquitectura de software,
respectivamente. Aunque este libro se enfoca en los sistemas intensivos en software, más
adelante en este libro se analizan varias consideraciones adicionales. Es importante
recordar, por ejemplo, que un sistema intensivo en software aún necesita hardware para
ejecutarse y que ciertas cualidades, como la confiabilidad o el rendimiento, se logran solo
a través de una combinación de software y hardware. Por lo tanto, este aspecto de la
solución total no puede ser ignorado y será considerado en discusiones posteriores.
Así que ahí lo tiene: ¡una iteración completa en términos de aquellas tareas que más
influyen en la arquitectura! Existen muchos más detalles detrás de cada una de estas
tareas, que describimos brevemente en este capítulo. Desarrollaremos estas tareas y los
principios de arquitectura en los que se basan en el resto de este libro.
También debe ser consciente de que los sistemas intensivos en software admiten una
imagen aún más amplia en la que puede considerar que los sistemas que comprenden
personas e información son ciudadanos de primera clase, así como el software y el
hardware. Una perspectiva aún más amplia es la consideración de una arquitectura
empresarial que proporcione, entre otras cosas, un panorama de los procesos comerciales
y los sistemas de TI existentes, así como una visión de las iniciativas de cambio comercial
que incluyen la planificación y la gobernanza de la transición. La arquitectura empresarial
y la ingeniería de sistemas están fuera del alcance de este libro, aunque reconocemos
tales perspectivas y las influencias que tienen en cuanto a guiar y limitar nuestro trabajo
como arquitectos de software.
Alcance
Resumen

Capitulo 2
Arquitectura, Arquitecto
Arquitectura
9
[La arquitectura es] La organización fundamental de un sistema encarnado
en sus componentes, sus relaciones entre sí y con el entorno, y los principios
que guían su diseño y evolución. (IEEE 1471 2000)
Este capítulo proporciona una descripción general de tres de los conceptos básicos
relacionados con el tema de este libro y concluye con una discusión de los beneficios
de la arquitectura. Estos conceptos, como se muestra en la Figura 2.1, son el papel
del arquitecto, las características de las tareas arquitectónicas que realizan y la
arquitectura que resulta.
No hay escasez de definiciones cuando se trata de arquitectura. Incluso algunos sitios
web mantienen colecciones de definiciones (SEI 2009). La definición utilizada en este
libro es la tomada de IEEE 1471-2000, Práctica recomendada de IEEE para la
descripción arquitectónica de sistemas intensivos en software (IEEE 1471 2000). Esta
definición es la siguiente, con características clave destacadas:

10 | Capítulo 2 Arquitectura, Arquitecto, Arquitectónico
Figura 2.1 Conceptos básicos utilizados en este libro
Una misión es un uso u operación para el cual un sistema está destinado por uno o más
líneas, familias de productos, empresas completas y otras agregaciones de interés. A
del mismo) con intereses en, o preocupaciones relativas a, un sistema. (IEEE 1471 2000)
partes interesadas para cumplir con un conjunto de objetivos. (IEEE 1471 2000)
El entorno, o contexto, determina el escenario y las circunstancias de
sistema existe para cumplir una o más misiones en su entorno. (IEEE 1471 2000)
Un componente representa una parte modular de un sistema que encapsula su contenido y cuya
manifestación es reemplazable dentro de su entorno. Un componente define su comportamiento en
términos de interfaces proporcionadas y requeridas. Como
influencias de desarrollo, operativas, políticas y de otro tipo sobre ese sistema.
[Un sistema es] una colección de componentes organizados para lograr un objetivo específico.
(IEEE 1471 2000)
[Una parte interesada del sistema es] un individuo, equipo u organización (o clases
función o conjunto de funciones. El término sistema abarca aplicaciones individuales, sistemas en
el sentido tradicional, subsistemas, sistemas de sistemas, productos
término pretende cubrir las muchas interpretaciones en la industria. Un componente puede
ser lógico o físico, independiente de la tecnología o específico de la tecnología, de grano
grande o de grano pequeño. A los efectos de este libro, utilizamos
especificación:
1471 no es una excepción, eligiendo dejarlo deliberadamente vago porque el
Esta norma también define los siguientes términos relacionados con esta definición:
la definición de componente del lenguaje de modelado unificado (UML) 2.2
Como puede ver, el término componente se usa en esta definición. Sin embargo, la
mayoría de las definiciones de arquitectura no definen el término componente y IEEE
Arquitectura
- crea
- realiza
- da como resultado
Arquitecto arquitectura

Todos estos temas y otros se tratan en las siguientes secciones.
Vale la pena considerar algunas otras definiciones de arquitectura para que
pueda observar similitudes entre esas definiciones. Considere las siguientes
definiciones, en las que se destacan algunas de las características clave:
Si le pidieras a alguien que te describiera la arquitectura, nueve de cada diez veces,
esa persona haría alguna referencia a algo relacionado con la estructura, muy a
menudo en relación con un edificio o alguna otra estructura de ingeniería civil,
Puede ver que, aunque las definiciones son algo diferentes, tienen un alto
grado de similitud. La mayoría de las definiciones indican que una arquitectura se
preocupa tanto por la estructura como por el comportamiento, se preocupa solo por
los elementos significativos, puede ajustarse a un estilo arquitectónico, está
influenciada por sus partes interesadas y su entorno, y encarna decisiones basadas en la lóg
Arquitectura | 11
Una arquitectura define la estructura
La arquitectura de software de un sistema o una colección de sistemas consta de
todas las decisiones de diseño importantes sobre las estructuras de software y las
interacciones entre esas estructuras que componen los sistemas. Las decisiones de
diseño respaldan un conjunto deseado de cualidades que el sistema debe respaldar
para tener éxito. Las decisiones de diseño proporcionan una base conceptual para el
desarrollo, soporte y mantenimiento del sistema. (McGovern 2004)
Una arquitectura es el conjunto de decisiones significativas sobre la organización de
un sistema de software, la selección de los elementos estructurales y sus interfaces
por los que se compone el sistema, junto con su comportamiento como se especifica
en las colaboraciones entre esos elementos, la composición de estos elementos en
subsistemas progresivamente más grandes y el estilo arquitectónico que guía esta
organización: estos elementos y sus interfaces, sus colaboraciones y su composición.
(Kruchten 2000)
La arquitectura de software de un programa o sistema informático es la estructura o
estructuras del sistema, que comprenden elementos de software, las propiedades
visibles externamente de esos elementos y las relaciones entre ellos. (Bajo 2003)
así, un componente sirve como un tipo cuya conformidad está definida por estas
interfaces proporcionadas y requeridas (abarcando tanto su semántica estática como
dinámica). Por lo tanto, un componente puede sustituirse por otro solo si los dos son
conformes al tipo. (UML 2.2 2009)

Figura 2.2 Diagrama de componentes UML que muestra los elementos estructurales
Una arquitectura define el comportamiento
El elemento estructural podría ser un subsistema, un proceso, una biblioteca, una base de datos, un
nodo computacional, un sistema heredado, un producto listo para usar, etc.
No debería sorprenderte, entonces, que si le pides a alguien que describa el
relaciones (y cualquier conector necesario para apoyar estas relaciones), sus
Componente de administración de cuentas, indicado por una dependencia UML.
entre estos elementos estructurales. Estas interacciones proporcionan el sistema deseado.
es el más familiar y el más mencionado.
elementos en sí mismos, sino también la composición de los elementos estructurales, su
mostrarse un diagrama que muestre los aspectos estructurales del sistema, ya sea
La Figura 2.2 muestra un ejemplo de algunos elementos estructurales. Esta figura
Además de definir los elementos estructurales, una arquitectura define las interacciones
La figura 2.3 es un diagrama de secuencia UML que muestra varias interacciones que,
arquitectura de un sistema de software en el que él o ella está trabajando, probablemente
interfaces y su partición. Una vez más, cada uno de estos elementos se puede proporcionar de
diversas formas. Un conector, por ejemplo, podría ser un socket, ser síncrono o asíncrono, estar
asociado con un protocolo particular, etc.
conducta.
Los aspectos estructurales de una arquitectura se manifiestan en muchos
sistema de procesamiento de pedidos. Verá tres componentes, denominados Entrada de pedidos,
Gestión de clientes y Gestión de cuentas. El componente Entrada de pedidos es
formas, y la mayoría de las definiciones de arquitectura son deliberadamente vagas como resultado. A
estos aspectos son capas arquitectónicas, componentes o nodos de distribución. La estructura es, en
efecto, una característica esencial de una arquitectura.
muestra un diagrama de componentes UML que contiene algunos elementos estructurales en un
juntos, permiten que el sistema admita la creación de una orden en una orden pro
comportamiento, adecuación al propósito e incluso estética, la característica estructural
Muchas definiciones de arquitectura también reconocen no sólo la estructura
mostrado como dependiendo del componente de Gestión de Clientes y también del
como un puente. Aunque existen otras características de estos artículos, como
Orden de entrada
Gestión de clientes Administración de cuentas

Figura 2.3 Diagrama de secuencia UML que muestra elementos de comportamiento
Arquitectura | 13
Una arquitectura se centra en elementos significativos
Cabe señalar que la Figura 2.3 es coherente con la Figura 2.2 en el sentido de que
puede derivar las dependencias que se muestran en la Figura 2.2 a partir de las interacciones
definidas en la Figura 2.3. Una instancia de Entrada de Pedidos, por ejemplo, depende de
una instancia de Gestión de Clientes durante su ejecución, como se muestra en las
interacciones de la Figura 2.3. Esta dependencia se refleja en una relación de dependencia
entre los componentes correspondientes Entrada de pedidos y Gestión de clientes, como se
muestra en la Figura 2.2.
Aunque una arquitectura define la estructura y el comportamiento, no se preocupa por definir
toda la estructura y todo el comportamiento. Sólo se ocupa de aquellos elementos que se
consideran significativos. Los elementos significativos son aquellos
sistema de cesación. La figura muestra cinco interacciones. En primer lugar, un actor de
vendedor crea un pedido utilizando una instancia del componente Entrada de pedidos. La
instancia de Entrada de pedidos obtiene los detalles del cliente mediante el uso de una
instancia del componente de Gestión de clientes. Luego, la instancia de Entrada de pedidos
utiliza una instancia del componente Gestión de cuentas para crear el pedido, completar el
pedido con artículos de pedido y realizar el pedido.
:Orden de entrada
1.3: realizar el pedido
1.2: crear orden
:Gestión de clientes
lazo
:Administración de cuentas
[1,*]
1: crear orden
:Empleado de ventas
1: añadir artículo de pedido
1.1: obtener detalles del cliente

Una arquitectura equilibra las necesidades de las partes interesadas
ÿ Las necesidades del mercadólogo están asociadas con características competitivas, tiempo para
ÿ Las necesidades del administrador del sistema están asociadas con el comportamiento intuitivo,
la administración y las herramientas para ayudar al monitoreo.
ÿ Las necesidades del usuario final están asociadas a un comportamiento intuitivo y correcto.
y la negociación es una característica esencial del arquitecto.
puede cambiar con el tiempo. Como consecuencia del perfeccionamiento de los requisitos, los riesgos
puede solicitar alguna funcionalidad dentro de un marco de tiempo específico, por ejemplo, pero
También vale la pena señalar que el conjunto de elementos significativos no es estático y
necesidades, pero a menudo no es posible satisfacer todas las necesidades expresadas. una parte interesada
que tienen un efecto largo y duradero, como los principales elementos estructurales, los
los elementos pueden cambiar. La relativa estabilidad de la arquitectura frente a
el alcance se puede reducir para cumplir con el cronograma, o toda la funcionalidad se puede
un conjunto de partes interesadas:
software ejecutable identificado, construido y lecciones aprendidas, el conjunto de
las dos necesidades, la funcionalidad y el marco de tiempo, son mutuamente excluyentes. Cualquiera
ior, rendimiento, confiabilidad, usabilidad, disponibilidad y seguridad.
un proceso de arquitectura bien ejecutado, y el signo de un buen arquitecto. La revisión continua de la
arquitectura debido a cambios relativamente menores no es una buena
expresar necesidades en conflicto, y nuevamente, se debe lograr un equilibrio apropiado.
mercado, posicionamiento con otros productos y costo.
Los impulsores principales para considerar ciertos elementos sobre otros son el costo de creación y el costo
del cambio.
elementos asociados con el comportamiento esencial, y aquellos elementos que abordan
cambio, sin embargo, es en cierta medida el signo de una buena arquitectura, el signo de
firmar. Sin embargo, si la arquitectura es relativamente estable, lo contrario es cierto.
cualidades importantes como la fiabilidad y la escalabilidad. En general, la arquitectura no se preocupa por
los detalles de grano fino de estos elementos. La importancia arquitectónica también se puede expresar como
importancia económica, porque la
proporcionado dentro de un marco de tiempo prolongado. Del mismo modo, las diferentes partes interesadas pueden
En última instancia, se crea una arquitectura para abordar un conjunto de partes interesadas del sistema.
enfoque particular del sistema bajo consideración, el enfoque que es más relevante para el arquitecto. En
este sentido, una arquitectura es una abstracción del sistema que ayuda a un arquitecto a gestionar la
complejidad.
Hacer concesiones, por lo tanto, es un aspecto esencial del proceso de arquitectura,
Solo para darle una idea de la tarea que tiene entre manos, considere las siguientes necesidades de
Debido a que una arquitectura se enfoca solo en elementos significativos, proporciona una

Las consideraciones son la documentación de las decisiones que condujeron a esta arquitectura y la
justificación de estas decisiones.
representan cualidades o restricciones del sistema. Los requisitos no funcionales son bastante
ellos mismos cuando necesitan revisar la lógica detrás de las decisiones que
La mayoría de las arquitecturas se derivan de sistemas que tienen un conjunto similar de preocupaciones.
que no contribuyen a la funcionalidad del sistema). tales preocupaciones
debe mantener el sistema. Esta información suele ser valiosa para los arquitectos.
se analizan en detalle en el Capítulo 7, “Definición de los requisitos”.
Además, algunas de estas decisiones pueden haber sido impuestas al arquitecto y,
de los estilos utilizados en la construcción de arquitecturas. Puedes pensar en una arquitectura
a menudo los requisitos más importantes en lo que respecta a un arquitecto; ellos
fueron hechos, para que no terminen teniendo que volver sobre sus pasos innecesariamente. Esta
información se utiliza cuando se revisa la arquitectura y el arquitecto necesita justificar las decisiones que
ha tomado, por ejemplo.
Un aspecto importante de una arquitectura no es solo el resultado final, la arquitectura en sí misma, sino
también la lógica que explica por qué es como es. Así, como
Por ejemplo, puede existir el uso de tecnologías y productos particulares, y esta política debe adaptarse
a la solución.
descrito en el Capítulo 4, "Documentación de una arquitectura de software", importante
en este sentido, representan restricciones a la solución. Una política de toda la empresa para
las partes interesadas no solo se preocupan de que el sistema proporcione la funcionalidad requerida.
Muchas de las preocupaciones que se enumeran son de naturaleza no funcional (en
Esta información es relevante para muchas partes interesadas, especialmente aquellas que
Esta similitud se puede describir como un estilo arquitectónico, un término prestado
Otro desafío para el arquitecto, como puede ver en esta lista, es que el
Arquitectura | 15
Una arquitectura encarna decisiones basadas en fundamentos
Una arquitectura puede ajustarse a un estilo arquitectónico
ÿ Las necesidades del cliente están asociadas con el costo, la estabilidad y el cronograma.
ÿ Las necesidades del director del proyecto están asociadas con la previsibilidad en el
seguimiento del proyecto, el cronograma, el uso productivo de los recursos y el presupuesto.
ÿ Las necesidades del desarrollador están asociadas con requisitos claros y un enfoque
de diseño simple y consistente.
ÿ Las necesidades del mantenedor están asociadas con un enfoque de diseño
comprensible, coherente y documentado, así como con la facilidad con la que se pueden
realizar modificaciones.

2009)
de componentes y tipos de conectores, y un conjunto de restricciones sobre cómo pueden
[Un estilo arquitectónico] define una familia de sistemas en términos de un patrón de
organización estructural. Más específicamente, un estilo arquitectónico define un vocabulario
Cada sistema intensivo de software bien estructurado está lleno de patrones. (Boocho
combinarse (Shaw 1996)
Una arquitectura está influenciada por su entorno
demostrado, reduciendo así el riesgo y, por supuesto, el esfuerzo. Normalmente, un estilo se
documenta en términos de la justificación de su uso (por lo que hay que pensar menos).
pronto. Los estilos arquitectónicos se analizan con más detalle en el Capítulo 5, “Activos
arquitectónicos reutilizables”. Un sistema dado puede exhibir más de un estilo arquitectónico.
Activos de arquitectura.”
el requisito de ajustarse a los estándares de la organización) y las restricciones técnicas externas
(como la necesidad de utilizar una tecnología específica, la interfaz con un
2ª ed. (Bass 2003), la arquitectura también puede influir en su entorno. los
estilo, un estilo centrado en datos, un estilo basado en reglas, arquitectura orientada a servicios y
en lugar de). Los activos de arquitectura se analizan en detalle en el Capítulo 5, “Reutilizables
estilo como un tipo particular de patrón, aunque a menudo un patrón complejo y compuesto (varios
patrones aplicados juntos).
Un sistema reside en un entorno, y este entorno influye en la arquitectura. Esto a veces se denomina
arquitectura en contexto. En esencia, el
Por el contrario, como se describe elocuentemente en Software Architecture in Practice,
La aplicación de un estilo arquitectónico (y activos reutilizables en general)
influir en la arquitectura incluir la misión comercial que la arquitectura
hace la vida de un arquitecto algo más fácil porque tales activos ya están
El entorno determina los límites dentro de los cuales debe operar el sistema, que luego influyen en
la arquitectura. Los factores ambientales que
Un estilo arquitectónico representa una codificación de la experiencia, y es bueno
Los ejemplos de estilos arquitectónicos incluyen un estilo distribuido, un estilo de tuberías y filtros
hecho) y en términos de sus estructuras y comportamientos clave (por lo que hay menos
documentación de arquitectura que producir porque simplemente puede consultar el estilo
apoyará, las partes interesadas del sistema, las limitaciones técnicas internas (como
sistema externo, o se ajustan a los estándares regulatorios externos).
práctica para que los arquitectos busquen oportunidades para reutilizar dicha experiencia.

Una arquitectura está presente en cada sistema
Una arquitectura influye en la estructura del equipo de desarrollo
Arquitectura | 17
La partición arquitectónica debe reflejar la partición geográfica y viceversa. Las
responsabilidades arquitectónicas deben asignarse para que las decisiones se
puedan tomar (geográficamente) localmente. (Coplién 2005)
la creación de una arquitectura puede aportar activos reutilizables a la organización propietaria,
por ejemplo, poniendo así dichos activos a disposición del siguiente esfuerzo de desarrollo.
Otro ejemplo es la selección de un paquete de software que se utiliza dentro de la arquitectura,
como un sistema de gestión de relaciones con el cliente (CRM), que posteriormente requiere
que los usuarios cambien los procesos que siguen para adaptarse a la forma en que funciona
el paquete.
Una arquitectura define agrupaciones coherentes de elementos relacionados que abordan un
conjunto determinado de preocupaciones. Una arquitectura para un sistema de procesamiento
de pedidos, por ejemplo, puede tener agrupaciones definidas de elementos para la entrada de
pedidos, gestión de cuentas, gestión de clientes, cumplimiento, integraciones con sistemas
externos, persistencia y seguridad.
Aunque organizar el trabajo de acuerdo con la arquitectura puede ser beneficioso, esta
visión un tanto idealizada no siempre es práctica. Por razones puramente pragmáticas, la
estructura actual del equipo y las habilidades disponibles (tanto en el equipo actual como en
los equipos de mantenimiento) representan una restricción muy real sobre lo que es posible, y
el arquitecto debe tener en cuenta esta restricción.
También vale la pena señalar que todo sistema tiene una arquitectura, incluso si esta
arquitectura no está formalmente documentada o si el sistema es extremadamente simple y,
por ejemplo, consta de un solo elemento. Documentar la arquitectura suele tener
Cada uno de estos grupos puede requerir diferentes conjuntos de habilidades. Por lo
tanto, tiene perfecto sentido alinear las estructuras del equipo de desarrollo de software con la
arquitectura después de que se haya definido. A menudo, sin embargo, la arquitectura está
influenciada por la estructura del equipo inicial y no al revés. Es mejor evitar este escollo,
porque el resultado suele ser una arquitectura menos que ideal. La Ley de Conway establece:
"Si tiene cuatro grupos trabajando en un compilador, obtendrá un compilador de cuatro pasos".
En la práctica, los arquitectos a menudo crean sin querer arquitecturas que reflejan la
organización que crea la arquitectura.
La distribución geográfica del equipo es otra limitación que debe tenerse en cuenta:

sobre ese sistema de una manera funcional, económica y elegante.
satisfacer una necesidad u objetivo declarado. (IEEE 12207 1995)
En última instancia, todo sistema intensivo en software tiene una arquitectura, ya sea intencional o
accidental. Cada una de estas arquitecturas sirve para contener las fuerzas
(Boocho 2009)
[Un sistema es] un compuesto integrado que consta de uno o más de los procesos, hardware,
software, instalaciones y personas, que proporciona una capacidad para
Una arquitectura tiene un alcance particular
arquitectura y arquitectura de datos. También escucha otros términos mencionados. Cada
mantener el sistema en el tiempo.
todos estos términos o sus relaciones entre sí, dando como resultado diferentes significados
para el mismo término (homónimos) y dos o más términos que significan lo mismo
La inspiración para los elementos que se muestran en la Figura 2.4 provino de varios
de las cualidades del tiempo de desarrollo, como la flexibilidad, la acomodación de las mejores
prácticas, etc. La falta de documentación también puede hacer que sea extremadamente difícil
Desafortunadamente, la industria no ha llegado a un acuerdo sobre los significados de
valor considerable; este tema se analiza en detalle en el Capítulo 4, “Documentación de una
arquitectura de software”.
Existen muchos tipos de arquitectura, siendo la más conocida la arquitectura asociada con
edificios y otras estructuras de ingeniería civil. Incluso en el campo de
este libro, de la figura 2.4, en el que nos centramos en la arquitectura de los sistemas intensivos
en software. Al considerar esta figura y la discusión que la sigue,
Procesos del ciclo de vida del software, define un sistema de la siguiente manera:
cosa (sinónimos). Puede inferir el alcance de algunos de estos términos, tal como se utilizan en
Además del concepto de arquitectura de software, por ejemplo, puede encontrar conceptos
como arquitectura empresarial, arquitectura de sistemas, información
diferente dentro de su organización. Considere este ejemplo como un reconocimiento de (y una
interpretación de) varios alcances posibles de la arquitectura.
arquitectura, arquitectura de hardware, arquitectura de aplicaciones, infraestructura
ingeniería de software, a menudo te encuentras con diferentes formas de arquitectura. En
es casi seguro que encontrará elementos con los que no está de acuerdo o que utiliza
evaluar la arquitectura y demostrar que cumple con los requisitos establecidos en términos
de estos términos define un alcance específico de las actividades de arquitectura.
ocupaciones.
fuentes. IEEE Std 12207-1995, el estándar IEEE para tecnología de la información:
Si una arquitectura no está documentada, es difícil (si no imposible)

ÿ Hardware. Este elemento considera elementos como CPU, memoria, discos duros, dispositivos
periféricos como impresoras y los elementos utilizados para conectar estos elementos.
ÿ Sistema. Como se describe en las definiciones anteriores, un sistema comprende soft
ÿ Información. Este elemento considera la información utilizada dentro
Una configuración de Rational Unified Process for Systems Engineering
ware, hardware, información y trabajadores.
Los diversos elementos que se muestran en la Figura 2.4 son
el sistema.
(RUP SE), también conocido como Model-Driven Systems Development (MDSD), contiene
ÿ Trabajadores. Este elemento considera los aspectos relacionados con las personas de un sistema,
ÿ Software. Este elemento es el enfoque principal de este libro y considera elementos tales como
componentes, relaciones entre componentes e interacciones entre componentes.
ÿ Empresa. Este elemento es similar a un sistema en que también considera elementos como hardware,
software, información y trabajadores. Una empresa, sin embargo, puede abarcar múltiples sistemas
y poner restricciones en el
tales como procesos comerciales, estructuras organizativas, funciones y responsabilidades, y
competencias básicas de la organización.
una definición similar:
Empresa
Software
trabajadores
Sistema
Arquitectura | 19
Hardware
Información
Figura 2.4 Diferentes alcances de arquitectura
[Un sistema es] un conjunto de recursos que brindan servicios que son utilizados por una
empresa para llevar a cabo un propósito o misión comercial. Los componentes del sistema normalmente
consisten en hardware, software, datos y trabajadores. (Cantor 2003)

arquitectura es la misma que la arquitectura de datos que se encuentra en algunos software de uso intensivo de datos
asumir información persistente durante su ejecución. En este libro, garantizar la consideración
adecuada de la información es responsabilidad del arquitecto de datos.
ÿ Software e información. Los elementos de software pueden producir y estafar
sistemas que forman parte de la empresa. Una empresa también tiene un vínculo más
fuerte con el negocio que un sistema, ya que una empresa se enfoca en el logro de los
objetivos comerciales y se preocupa por elementos como la estrategia comercial, la agilidad
comercial y la eficiencia organizacional. Además, una empresa puede cruzar los límites de la
empresa.
existe (arquitecto de software, arquitecto de hardware, etc.), así como un tipo correspondiente de
arquitectura (arquitectura de software, arquitectura de hardware,
Para cada tipo específico de arquitectura, un tipo de arquitecto correspondiente
Ahora que ya entendió estas definiciones, es posible que tenga muchas
preguntas sin respuesta. ¿Cuál es la diferencia entre una arquitectura empresarial y una arquitectura
de sistema? ¿Es una empresa un sistema? es una informacion
y así).
ÿ Software y trabajadores. Si bien los trabajadores no se consideran parte de los sistemas
considerados en este libro, existe una relación en términos de la funcionalidad que el sistema
debe brindar para brindar soporte a cualquier persona que interactúe con el sistema. En este
libro, garantizar que se proporcione esta funcionalidad es responsabilidad del arquitecto de la
aplicación.
Debido a que en este libro nos enfocamos en los sistemas intensivos en software, vale la pena
hacer algunas observaciones adicionales. En particular, debemos señalar que un sistema intensivo
en software es un sistema. Por lo tanto, debe comprender la relación
entre el software y aquellos elementos con los que debe coexistir:
siempre debe tenerse en cuenta en los sistemas intensivos en software es el hardware en el
que se ejecuta el software. El sistema resultante, por lo tanto, es una combinación de software
y hardware, y esta combinación permite lograr propiedades como la confiabilidad y el
rendimiento. El software no puede lograr estas propiedades de forma aislada del hardware en
el que se ejecuta. Asegurar la consideración adecuada del hardware es, en este libro,
responsabilidad del arquitecto de la infraestructura.
¿aplicaciones de artículos? Desafortunadamente, no existe un conjunto de respuestas acordadas
para estas preguntas. Por ahora, tenga en cuenta que estos diferentes términos existen pero que el
ÿ Software y hardware. Un aspecto particular del medio ambiente que

Arquitecto
Arquitecto | 21
El arquitecto es un líder técnico
arquitectura. (IEEE 1471 2000)
[Un arquitecto es] la persona, equipo u organización responsable de los sistemas
áreas particulares).
arquitecto. Podría decirse que el papel del arquitecto es el más desafiante en cualquier proyecto de
desarrollo de software. El arquitecto es el líder técnico del proyecto.
las cualidades que exhibe el arquitecto.
el gerente es el productor (asegurándose de que las cosas se hagan), mientras que el arquitecto es
el director (asegurándose de que las cosas se hagan correctamente). Como resultado de
a la organización
atención al papel que es responsable de la creación de la arquitectura: el
Ante todo, el arquitecto es un líder técnico, lo que significa que además de tener habilidades técnicas,
el arquitecto exhibe cualidades de liderazgo. El liderazgo se puede caracterizar en términos de
posición en la organización y
La industria no tiene una definición consistente de estos términos y cómo se relacionan entre sí.
el papel del arquitecto lo cumple un equipo) es el líder técnico del proyecto y
del proyecto y, como equipo, son los principales puntos de contacto con las personas ajenas al
proyecto. El arquitecto en particular debe ser un defensor de la inversión realizada en la creación de
una arquitectura y el valor que aporta.
y, desde una perspectiva técnica, en última instancia, tiene la responsabilidad del éxito o fracaso
técnico del proyecto.
En términos de posición en la organización, el arquitecto (o el arquitecto principal, si
Como líder técnico del proyecto, el arquitecto debe tener habilidades que sean
por otro lado, está más preocupado por la gestión del plan del proyecto en términos de
típicamente amplio en lugar de profundo (aunque los arquitectos deben tener habilidades profundas en
otro. Le recomendamos, por lo tanto, que seleccione los términos que son relevantes
cierta consistencia, al menos, y reducir el potencial de falta de comunicación.
debe tener la autoridad para tomar decisiones técnicas. El director del proyecto, en
a su organización y defínalos apropiadamente. Entonces lo lograrás
Ahora que hemos definido lo que entendemos por arquitectura, podemos convertir nuestra
sus puestos, el arquitecto y el director del proyecto representan la persona pública
recursos, cronograma y costo. Usando la industria del cine como una analogía, el proyecto

El rol de arquitecto puede ser cumplido por un equipo
[Un equipo es] un pequeño número de personas con habilidades complementarias
que están comprometidas con un propósito común, metas de desempeño y un enfoque
por el cual se consideran mutuamente responsables. (Katzenbach 1993)
Los arquitectos deben ser capaces de tomar decisiones (a menudo bajo presión) y asegurarse de
que esas decisiones se comuniquen, se entiendan y finalmente se mantengan.
Si la función de arquitecto debe ser desempeñada por un equipo, es importante contar con
una persona que se considere el arquitecto principal, que sea responsable de apropiarse de la
visión y que pueda actuar como un único punto de coordinación en todo el proyecto.
El arquitecto también debe participar en la determinación de cómo se integra el equipo, porque
la arquitectura implicará la necesidad de ciertas habilidades.
Además, los arquitectos deben estar muy enfocados en la entrega de resultados tangibles y
deben actuar como la fuerza impulsora del proyecto desde una perspectiva técnica.
A lo largo de este libro, el término arquitecto se refiere al rol, que puede ser desempeñado por
un individuo o un equipo.
Los arquitectos exitosos están orientados a las personas, y todos los arquitectos se toman el
tiempo para asesorar y capacitar a los miembros de su equipo. Esta práctica beneficia a los
miembros del equipo en cuestión, al proyecto y, en última instancia, a la propia organización,
porque algunos de sus activos más valiosos (las personas) se vuelven más hábiles.
Hay una diferencia entre un rol y una persona. Una persona puede desempeñar muchos roles
(Mary es desarrolladora y probadora), y un rol puede ser desempeñado por muchas personas
(Mary y John cumplen el rol de probador). Dado el requisito de un conjunto muy amplio de
habilidades en un arquitecto, a menudo ocurre que el rol de arquitecto lo desempeña más de una
persona. Esta práctica permite que las habilidades se extiendan entre varias personas, cada una
aportando sus propias experiencias. En particular, las habilidades requeridas para comprender
tanto el dominio comercial como varios aspectos de la tecnología a menudo se distribuyen mejor
entre varias personas. Sin embargo, el equipo resultante debe estar equilibrado.
En términos de las cualidades que exhibe el arquitecto, el liderazgo también se puede
caracterizar en términos de interacciones con otros miembros del equipo. Específicamente, el
arquitecto debe predicar con el ejemplo y mostrar confianza al establecer la dirección.
Las dependencias entre los elementos de la arquitectura influyen en la secuencia de tareas y, por
lo tanto, cuando se requieren estas habilidades, por lo que el arquitecto debe contribuir activamente
a las actividades de planificación. En una nota relacionada, debido a que el éxito del arquitecto está
estrechamente relacionado con la calidad del equipo, la participación en las entrevistas a los nuevos
miembros del equipo también es muy apropiada.

El arquitecto entiende el proceso de desarrollo de software
El Arquitecto Tiene Conocimiento del Dominio Empresarial
Arquitecto | 23
Para un equipo que es nuevo en el concepto de arquitectura, se ha sugerido que
para lograr este propósito, objetivos y enfoque comunes, el equipo debería crear y
publicar un estatuto del equipo (Kruchten 1999).
Una trampa con el concepto de un equipo de arquitectura, especialmente en
proyectos grandes, es que puede ser percibido como una torre de marfil cuya producción
es más intelectual que útil. Este concepto erróneo se puede minimizar desde el principio
asegurándose de que todas las partes interesadas sean consultadas activamente, que
se comunique la arquitectura y su valor, y que se considere cualquier política
organizacional en juego.
La mayoría de los arquitectos han sido desarrolladores en algún momento y deberían
tener una buena apreciación de la necesidad de definir y respaldar las mejores prácticas
utilizadas en el proyecto. Más específicamente, el arquitecto debe tener una apreciación
del proceso de desarrollo de software, porque este proceso asegura que todos los
miembros del equipo trabajen de manera coordinada.
equipo de arquitectura. Sin este punto de coordinación, existe el peligro de que los
miembros del equipo de arquitectura no produzcan una arquitectura cohesiva o que no
se tomen decisiones.
Los buenos arquitectos conocen sus fortalezas y debilidades. Ya sea que el papel
del arquitecto lo cumpla o no un equipo, un arquitecto cuenta con el apoyo de varios
asesores de confianza. Dichos arquitectos reconocen dónde son débiles y compensan
estas debilidades obteniendo las habilidades necesarias o trabajando con otras personas
para llenar los vacíos en su conocimiento. Las mejores arquitecturas generalmente son
creadas por un equipo en lugar de un individuo, simplemente porque hay una mayor
amplitud y profundidad de conocimiento cuando hay más de una persona involucrada.
Esta coordinación se logra definiendo los roles involucrados, las tareas realizadas,
los productos de trabajo creados y los puntos de traspaso entre los diferentes roles.
Debido a que los arquitectos están involucrados con muchos de los miembros del equipo
a diario, es importante que comprendan las funciones y responsabilidades de los
miembros del equipo, así como lo que están produciendo y utilizando. En esencia, los
miembros del equipo buscan orientación en el arquitecto sobre cómo cumplir con sus
responsabilidades, y el arquitecto debe ser capaz de responder de manera coherente
con el proceso de desarrollo que está siguiendo el equipo.
Además de tener conocimientos de desarrollo de software, también es muy deseable
(algunos dirían esencial) que los arquitectos comprendan el dominio empresarial para
que puedan actuar como intermediarios entre las partes interesadas y

[Un dominio es] un área de conocimiento o actividad caracterizada por un conjunto de
conceptos y terminología que entienden los profesionales de esa área. (Guía del usuario
de UML 1999)
El arquitecto tiene conocimientos tecnológicos
El arquitecto tiene habilidades de diseño
Por lo tanto, un buen arquitecto tiene un buen equilibrio entre el conocimiento del
desarrollo de software y el dominio del negocio. Cuando los arquitectos entienden el
desarrollo de software pero no el dominio comercial, se puede desarrollar una solución
que no se ajuste al problema, sino que refleje la zona de confort de las cosas con las que
el arquitecto está familiarizado.
Aunque la arquitectura no se limita únicamente al diseño (como ha visto, el arquitecto
también está involucrado en las tareas de requisitos), el diseño claramente es el núcleo
los usuarios, que entienden el negocio, y los miembros del equipo de desarrollo, que
pueden estar más familiarizados con la tecnología.
El conocimiento del dominio empresarial también permite al arquitecto comprender
mejor los requisitos del sistema y contribuir a ellos, así como estar en condiciones de
garantizar que se capturen los requisitos probables. Además, un dominio particular a
menudo se asocia con un conjunto particular de patrones arquitectónicos (y otros activos)
que se pueden aplicar en la solución, y conocer este mapeo puede ser de gran ayuda para
el arquitecto.
La familiaridad con el dominio empresarial también permite a los arquitectos anticipar
cambios probables en su arquitectura. Dado que la arquitectura está fuertemente
influenciada por el entorno en el que se implementará, que incluye el dominio empresarial,
una apreciación del dominio empresarial permite al arquitecto tomar decisiones mejor
informadas en términos de áreas probables de cambio y áreas de trabajo. estabilidad. Si
el arquitecto es consciente de que será necesario cumplir con los nuevos estándares
regulatorios en algún momento en el futuro, este requisito debe adaptarse a la arquitectura,
por ejemplo.
Ciertos aspectos de la arquitectura claramente requieren conocimiento de la tecnología,
por lo que un arquitecto debe tener un cierto nivel de habilidades tecnológicas. Sin
embargo, un arquitecto no necesita ser un experto en tecnología como tal y debe
preocuparse solo por los elementos significativos de una tecnología, no por los detalles. El
arquitecto puede comprender los marcos clave disponibles en una plataforma como Java
EE o .NET, pero no necesariamente los detalles de cada interfaz de programación de
aplicaciones (API) que está disponible para acceder a estas plataformas. Debido a que la
tecnología cambia con bastante frecuencia, es esencial que el arquitecto se mantenga al tanto de es

escribir código. Si el arquitecto implementa, la organización de desarrollo percibe la aceptación
de los arquitectos guía, y esa percepción puede directamente
el proceso de desarrollo (Coplién 2005)
El Arquitecto debe estar comprometido organizacionalmente con los Desarrolladores y debe
trabajar y estremecerme de lo mal que estaba. Como con cualquier otra habilidad, uno debe
practicar el diseño para obtener la competencia. (Coplién 2005)
resultados de primera mano de sus decisiones y diseños, brindándoles así retroalimentación sobre
resultado de años de experiencia. Incluso los diseñadores expertos recuerdan sus primeros
aprovechar la experiencia arquitectónica. Los arquitectos también aprenden viendo el
Uno no adquiere destreza en el diseño de la noche a la mañana; en cambio, tal habilidad es la
Arquitecto | 25
El arquitecto tiene habilidades de programación
proyecto, y esas habilidades deben mantenerse actualizadas con las tecnologías
aspectos de su comercio. Incluso a medida que evolucionan las tecnologías y se introducen nuevos
lenguajes de programación, los buenos arquitectos pueden abstraer los conceptos en cualquier
elementos de la implementación, como la organización del código fuente
será incapaz de tomar decisiones con respecto a la arquitectura significativa
aspecto de la arquitectura. La arquitectura incorpora decisiones clave de diseño, por lo que el
con los que el arquitecto debe interactuar. Después de todo, sus productos de trabajo en última instancia
existe entre el arquitecto y los desarrolladores.
Los desarrolladores del proyecto representan uno de los grupos más importantes
y la adopción de estándares de programación, y una barrera de comunicación
el arquitecto y los desarrolladores pueden ser efectivos solo si el arquitecto aprecia el trabajo de los
desarrolladores. Por lo tanto, los arquitectos deben tener un cierto nivel
La mayoría de los arquitectos de software exitosos han sido, en algún momento,
deben ser identificados por alguien que tenga las habilidades apropiadas.
arquitecto debe poseer fuertes habilidades de diseño. Tales decisiones podrían representar
entregar el software ejecutable de trabajo. La comunicación entre los
de habilidades de programación, incluso si no necesariamente escriben código en el
decisiones clave de diseño estructural, la selección de patrones particulares, la especificación de pautas,
etc. Para garantizar la integridad de la arquitectura del sistema, estos elementos generalmente se
aplican de forma generalizada y pueden tener efectos de largo alcance en términos del éxito del sistema.
Por lo tanto, tales elementos
siendo utilizado.
lenguaje de programación y aplicar este conocimiento para aprender un nuevo lenguaje de programación
a la profundidad requerida. Sin este conocimiento, el arquitecto
programadores En cierta medida, esta experiencia es la forma en que aprendieron ciertas

Por lo tanto, los arquitectos deben ser duros, porque es posible que deban corregir sus
decisiones y dar marcha atrás.
De todas las habilidades blandas asociadas con el arquitecto, la comunicación es la
más importante. La comunicación efectiva implica varias dimensiones, y el arquitecto
debe ser competente en todas ellas. Específicamente, el arquitecto debe tener
habilidades verbales, escritas y de presentación efectivas. Además, la comunicación
debe ser bidireccional. El arquitecto debe ser un buen oyente y también un buen observador.
Ser capaz de comunicarse de manera efectiva es una habilidad fundamental para
el éxito del proyecto por muchas razones. Claramente, la comunicación con las partes
interesadas es particularmente importante para comprender sus necesidades y también
para comunicar la arquitectura de una manera que obtenga (y mantenga) el acuerdo
con todas las partes interesadas. La comunicación con el equipo del proyecto es
particularmente importante, porque el arquitecto no es responsable simplemente de
transmitir información al equipo, sino también de motivar al equipo. Específicamente, el
arquitecto es responsable de comunicar (y reforzar la comunicación de) la visión del
sistema para que la visión sea compartida, no algo que solo el arquitecto entienda y en
lo que crea.
Un arquitecto que es incapaz de tomar decisiones en un entorno donde se desconoce
mucho, donde no hay tiempo suficiente para explorar todas las alternativas y donde
existe presión para cumplir, es poco probable que sobreviva. Desafortunadamente, tales
entornos son la norma y no la excepción, y los arquitectos exitosos reconocen la
situación en lugar de tratar de cambiarla. Aunque el arquitecto puede consultar a otros
al tomar decisiones y fomentar un entorno en el que los demás estén incluidos en la
toma de decisiones, sigue siendo responsabilidad del arquitecto tomar las decisiones
adecuadas, que no siempre resultan correctas.
La incapacidad para tomar decisiones socavará lentamente el proyecto. El equipo
del proyecto perderá la confianza en el arquitecto y el director del proyecto se preocupará
porque aquellos que esperan la arquitectura no pueden lograr el progreso requerido. El
peligro real es que si el arquitecto no toma y documenta las decisiones sobre la
arquitectura, los miembros del equipo comenzarán a tomar sus propias decisiones,
posiblemente incorrectas.
Los arquitectos exitosos no solo se preocupan por la tecnología. También son
políticamente astutos y conscientes de dónde reside el poder en una organización.
Utilizan este conocimiento para garantizar que se comunique a las personas adecuadas.
El arquitecto es un buen comunicador
El arquitecto toma decisiones
El arquitecto es consciente de la política organizacional

nervioso. Los obliga a jugar en "la cancha de otra persona", por así decirlo, un lugar
entender mejor la política como un medio eficaz para hacer frente a la necesidad
ineludible de resolver las diferencias de opinión. (Marasco 2004)
La política implica una gran cantidad de ambigüedad, lo que hace que muchos técnicos
donde sienten que están en desventaja debido a su destreza técnica
Los seres humanos tendemos a no pensar todos igual; para resolver diferencias de
[La arquitectura de software representa] las actividades de definir, documentar,
no cuenta mucho. (Marasco 2004)
opinión, un proceso político es inevitable. Entonces, en lugar de condenarlo, es
mantener, mejorar y certificar la implementación adecuada de una arquitectura. (IEEE
1471 2000)
Arquitectura | 27
arquitectura
El arquitecto es un negociador
con y que el apoyo a un proyecto se ventila en los círculos adecuados. Ignorar la política organizacional
es, sencillamente, ingenuo.
proyecto que entrega el sistema, y estas fuerzas deben tenerse en cuenta.
cambios en los requisitos), una forma de eliminar un riesgo es refinar los requisitos para que el riesgo
ya no esté presente, por lo tanto, la necesidad de hacer retroceder
Habiendo descrito qué es una arquitectura, y habiendo definido las características del papel del
arquitecto, ahora podemos mirar algunos de los temas, o características, que subyacen en el proceso
de arquitectura. No entraremos en el detalle de
partes interesadas. Algunas de estas interacciones requieren habilidades de negociación. Un particular
tales requisitos para que las partes interesadas y el arquitecto puedan llegar a un acuerdo mutuo
Dadas las muchas dimensiones de la arquitectura, el arquitecto interactúa con muchos
el enfoque para el arquitecto es minimizar el riesgo lo antes posible en el proyecto,
cada tarea, porque este detalle se trata en el resto de este libro.
posición agradable. Esta situación requiere que el arquitecto sea un negociador eficaz que sea capaz
de articular las consecuencias de diferentes compensaciones.
Además, aquellas características de la arquitectura que se pueden describir en términos de beneficios
se describen más adelante en este capítulo.
La realidad es que muchas fuerzas que actúan en las organizaciones se encuentran fuera del
porque minimizar el riesgo tiene una correspondencia directa con el tiempo que lleva estabilizar la
arquitectura. Debido a que los riesgos están asociados con los requisitos (y

- descrito por
- posee
- cumple
1..*
1
1..*
- es importante para
Projecto de desarrollo
arquitectura
- da como resultado
Proceso de desarrollo
Interesado
Equipo
Decisión de arquitectura
Sistema
- crea
- realiza
1..*
- desarrolla
Ambiente
Arquitecto Razón fundamental
- identifica
1..*
- direcciones
1..*
Descripción arquitectónica
- sigue
1..*
- habita
- es atendido por
- influencias
- justifica
Arquitectura
1..*
- incluye
- proporciona
- identifica
1..*
- tiene
1..*
Preocupación
- incluye
1..*
- tiene un
Misión
Figura 2.5 Un metamodelo de términos relacionados con la arquitectura
El alcance de la arquitectura es bastante amplio. La figura 2.5 muestra un
metamodelo que define varios aspectos del proceso de arquitectura de software.
Este metamodelo se deriva del estándar IEEE 1471 y se puede considerar como
un mapa de ruta a través de los diversos aspectos de la arquitectura que le
preocupan a un arquitecto. A lo largo de este libro se considerarán elementos
adicionales del metamodelo. Desarrollamos el elemento Descripción
arquitectónica, por ejemplo, en el Capítulo 4, "Documentación de una arquitectura de soft

ÿ El arquitecto es una especie de parte interesada.
ÿ Un proyecto de desarrollo está integrado por un equipo.
ÿ Un proyecto de desarrollo sigue un proceso de desarrollo. ÿ Un proyecto
de desarrollo desarrolla un sistema. ÿ El proceso de desarrollo incluye la
arquitectura.
ÿ Una decisión de arquitectura aborda una o más inquietudes.
ÿ Un sistema tiene una arquitectura. ÿ
Un sistema cumple una o más misiones. ÿ Un sistema
tiene una o más partes interesadas. ÿ Un sistema
habita un entorno. ÿ Un entorno influye en un sistema.
ÿ Una arquitectura se describe mediante una
descripción arquitectónica. ÿ Una descripción arquitectónica identifica a una o
más partes interesadas. ÿ Una descripción arquitectónica identifica una o más
preocupaciones. ÿ Una descripción arquitectónica proporciona una justificación.
ÿ El arquitecto crea una arquitectura.
ÿ La arquitectura da como resultado una arquitectura.
ÿ La lógica justifica una o más decisiones de arquitectura.
ÿ El arquitecto realiza la arquitectura
ÿ Una preocupación es importante para una o más partes interesadas.
ÿ El equipo incluye un arquitecto.
ÿ Una parte interesada tiene una o más inquietudes.
Arquitectura | 29
Las relaciones en este metamodelo que se toman directamente del IEEE
1471 estándar, en palabras, son
Un beneficio adicional del estándar IEEE 1471 es que no solo se aplica a la
documentación de una arquitectura de software, sino que también se puede considerar
como un marco de razonamiento para los conceptos que los arquitectos deben tener en
cuenta en su trabajo. Las relaciones adicionales en la figura que no forman parte del
estándar IEEE 1471 son
donde consideramos cómo se documenta una arquitectura. Proporcionamos una
descripción completa del metamodelo utilizado en este libro en el Apéndice A, “Metamodelo
de arquitectura de software”.

La arquitectura es una disciplina reconocida, aunque todavía emergente. Con este reconocimiento
viene un énfasis en técnicas, procesos y activos que se enfocan en mejorar la madurez del
proceso de arquitectura. Una forma de avanzar en esta madurez es recurrir a un cuerpo de
conocimiento existente. En términos generales, los arquitectos buscan soluciones comprobadas
al desarrollar una arquitectura en lugar de reinventar la rueda, evitando así la creatividad
innecesaria.
ÿ El arquitecto ayuda en la disciplina de requisitos, por ejemplo, asegurando que se capturen
aquellos requisitos de particular interés para el arquitecto.
Incluso en el más novedoso de los sistemas, normalmente es posible copiar soluciones de otros
lugares y luego adaptarlas al sistema en consideración.
La experiencia codificada en términos de arquitecturas de referencia, patrones arquitectónicos y
de diseño y otros activos reutilizables también tiene un papel que desempeñar.
ÿ El arquitecto participa en la priorización de requisitos.
A medida que el proceso de arquitectura de software se generaliza, es probable que ya no
se vea como un conjunto misterioso de prácticas que solo unos pocos elegidos pueden
comprender, sino como un conjunto ampliamente accesible de prácticas bien definidas y
comprobadas que tienen alguna base científica y son ampliamente aceptados.
Sin embargo, aún queda camino por recorrer antes de que el proceso de arquitectura de
software esté tan maduro como, por ejemplo, los procesos de ingeniería civil. Esta madurez se
puede considerar en muchas dimensiones, incluido el uso de estándares y la comprensión de
las mejores prácticas, técnicas y procesos.
El arquitecto está involucrado en muchos aspectos del proceso de desarrollo de software más
allá de la arquitectura:
Aunque la arquitectura puede verse como una ciencia, siempre existe la necesidad de
proporcionar cierto nivel de creatividad, especialmente cuando se trata de sistemas novedosos y
sin precedentes. En tales casos, es posible que no se disponga de experiencia codificada a la
que recurrir. Así como los pintores buscan inspiración cuando se enfrentan a un lienzo en blanco,
los arquitectos pueden, en ocasiones, ver su trabajo más como un arte que como una ciencia.
En su mayor parte, sin embargo, el lado artístico de la arquitectura es mínimo.
La arquitectura es una ciencia
La arquitectura es un arte
La arquitectura abarca muchas disciplinas

el enfoque del arquitecto es a través de la vida del proyecto.
Todos estos elementos se describen más adelante en este libro.
perfil se indica en la Figura 2.6, que se atribuye a Bran Selic.
Cabe señalar que las preocupaciones de descubrimiento, invención e implementación no son
estrictamente secuenciales. Cierta implementación ocurre temprano en el
Fundamentos.”
tiene entrada en las actividades de planificación del proyecto.
del arquitecto cambia con el tiempo a medida que los resultados deseados cambian con el tiempo. Esta
La experiencia demuestra que la arquitectura no es algo que se hace una vez,
las características críticas y los riesgos asociados. Estos elementos tienen claramente un
tarde en el proyecto a medida que se aprenden las lecciones y se implementan diferentes estrategias
para implementar ciertos elementos de la arquitectura. Este énfasis cambiante de la arquitectura a lo
largo del tiempo se analiza con más detalle en el Capítulo 3, “Método
La Figura 2.6 muestra que al principio del proyecto, el arquitecto se centra en el descubrimiento.
El énfasis está en comprender el alcance del sistema e identificar
La arquitectura crece a través de la entrega de una serie de entregas incrementales e iterativas de
software ejecutable. En cada entrega, la arquitectura
base para la implementación a gran escala. Finalmente, el énfasis cambia a
se vuelve más completo y estable, lo que plantea la pregunta obvia de qué
temprano en un proyecto. Más bien, la arquitectura se aplica durante la vida del proyecto; los
impacto en la arquitectura. Entonces el énfasis cambia a la invención; La principal preocupación del
arquitecto es desarrollar una arquitectura estable que pueda proporcionar la
Los esfuerzos exitosos de arquitectura de software están orientados a los resultados. Así, el foco
proyecto a medida que se construyen los prototipos arquitectónicos y se produce algún descubrimiento
implementación cuando ha tenido lugar la mayor parte del descubrimiento y la invención.
porque las estructuras de gestión de la configuración (que admiten el control de versiones) a
menudo reflejan la arquitectura que se ha definido.
Arquitectura | 31
La arquitectura es una actividad continua
ÿ El arquitecto participa en la implementación, definiendo las estructuras de implementación
que se utilizarán para organizar el código fuente y los productos de trabajo ejecutables.
ÿ El arquitecto es responsable de ciertos elementos del entorno de desarrollo, en
términos de definir ciertos estándares y pautas del proyecto.
ÿ El arquitecto participa en la disciplina de prueba, asegurándose de que la arquitectura
sea comprobable y probada.
ÿ El arquitecto ayuda a definir la estrategia de gestión de la configuración,
ÿ El arquitecto y el director del proyecto trabajan en estrecha colaboración, y el arquitecto

Invención
Enfocar
Hora
32 | Arquitectura, Arquitecto
Figura 2.6 Énfasis del proyecto a lo largo del tiempo
Descubrimiento
Implementación
Involucrar a todas las partes interesadas es fundamental para garantizar un resultado
exitoso en términos de la arquitectura resultante. Las partes interesadas influyen en muchos
aspectos del proceso, como se analiza más adelante en este libro, incluida la forma en que
Una arquitectura satisface las necesidades de una serie de partes interesadas. El proceso
de arquitectura, por lo tanto, debe acomodar a todas estas partes interesadas para garantizar
que sus preocupaciones, específicamente aquellas que probablemente tengan un impacto
en la arquitectura, sean capturadas, aclaradas, reconciliadas y gestionadas. También es
necesario involucrar a las partes interesadas relevantes en cualquier revisión de la solución
a estas preocupaciones.
El proceso de arquitectura no está completo hasta que se entrega el sistema; por lo
tanto, el arquitecto debe estar involucrado hasta el final del proyecto. Una organización a
menudo tiene un fuerte deseo de eliminar al arquitecto de un proyecto cuando la arquitectura
se ha estabilizado para utilizar este preciado recurso en otros proyectos. Sin embargo, es
posible que las decisiones arquitectónicas aún deban tomarse tarde en el proyecto. En la
práctica, a menudo se encuentra un término medio: después de que se han tomado las
principales decisiones que afectan a la arquitectura, el arquitecto se convierte en un miembro
a tiempo parcial del equipo. Sin embargo, el arquitecto no debe desvincularse por completo.
Existe una situación mucho más flexible cuando el papel del arquitecto lo desempeña un
equipo, porque algunos de los miembros pueden ser utilizados en otros proyectos, mientras
que los que quedan continúan asegurando la integridad arquitectónica del sistema.
La arquitectura es impulsada por muchas partes interesadas

La arquitectura a menudo implica hacer concesiones
Tiempo de ejecución
Técnico
Restricciones
Cualidades
Restricciones
Requisitos
Negocio
Funcional
Cualidades
Arquitectura | 33
Sin tiempo de ejecución
Figura 2.7 Hacer compensaciones aborda fuerzas opuestas
La figura 2.7 proporciona una clasificación simple de algunas de las fuerzas que
intervienen en la arquitectura de una solución. Además de la función proporcionada por el
sistema, debe preocuparse por los requisitos no funcionales que incluyen el tiempo de ejecución.
Dados los muchos factores que influyen en una arquitectura, está claro que el proceso de
arquitectura implica hacer concesiones. Muy a menudo, la compensación es entre
requisitos en conflicto, y es posible que sea necesario consultar a las partes interesadas
para ayudar a hacer la compensación correcta. Un ejemplo de compensación es entre
costo y desempeño; arrojar más potencia de procesamiento al problema mejorará el
rendimiento, pero a un costo. Esto puede ser un conflicto en los requisitos y, asumiendo
que el arquitecto ha sido diligente en su trabajo explorando todas las opciones, es un
asunto que debe resolverse con las partes interesadas cuyas necesidades están en
conflicto.
Otras compensaciones ocurren en el espacio de la solución. El uso de una tecnología
sobre otra, un componente de terceros sobre otro, o incluso el uso de un conjunto de
patrones sobre otro, son compensaciones relacionadas con la solución más que con los
requisitos. Hacer concesiones no es algo que el arquitecto pueda o deba evitar. Se espera
que el arquitecto considere alternativas, y hacer concesiones entre ellas es un aspecto
esencial del proceso de arquitectura.
se recogen los requisitos, la forma en que se documenta la arquitectura, y la forma en que
se evalúa la arquitectura.

Architecting reconoce la experiencia
La arquitectura es tanto de arriba hacia abajo como de abajo hacia arriba
Un activo reutilizable es una solución a un problema recurrente. Un activo reutilizable es un
activo que ha sido desarrollado con la reutilización en mente. (RAS 2004)
elementos del mismo, como activos reutilizables que se pueden utilizar fuera del sistema actual.
patrones, componentes listos para usar, etc. En otras palabras, el arquitecto
Muchas arquitecturas a menudo se consideran de arriba hacia abajo, donde las necesidades de las
partes interesadas se capturan y los requisitos se desarrollan antes de que la arquitectura
ejemplo podría ser una restricción de que el diseño utilizará una base de datos relacional o
buscar activamente experiencia que pueda ser codificada en patrones arquitectónicos, diseño
Una arquitectura también puede impulsarse de abajo hacia arriba como resultado de las lecciones
que se aprenden de cualquier software ejecutable que se haya creado, como
cualidades (como rendimiento y facilidad de uso), cualidades que no son de tiempo de ejecución (como
lo que ha pasado antes.
La razón principal es que la mayoría de los sistemas no parten de una hoja en blanco de
busca activos reutilizables. Sólo el arquitecto más ignorante no considera
se define, se diseñan los elementos arquitectónicos y se implementan estos elementos. Sin embargo,
las arquitecturas rara vez se impulsan totalmente desde arriba hacia abajo.
que necesitan ser acomodados y que influyen en la arquitectura. Tal ele
estándares y componentes de solución obligatorios).
mantenibilidad y portabilidad), restricciones comerciales (tales como regulaciones y
Si bien es cierto que los elementos de una arquitectura son reutilizables en el contexto del sistema
actual, los arquitectos también pueden considerar su arquitectura, o
papel. Suele existir algo de herencia, en forma de elementos de solución existentes
restricciones de recursos) y restricciones técnicas (como la tecnología obligatoria
Los arquitectos rara vez trabajan a partir de una hoja de papel en blanco. Como se señaló anteriormente, ellos
El tema de la reutilización se analiza más adelante en este capítulo y en el Capítulo 5, “Activos de
arquitectura reutilizables”.
Los elementos van desde aplicaciones completas que deben rediseñarse hasta elementos de diseño
o implementación obligatorios que restringen la arquitectura. Un
interfaz con un sistema existente.

Los beneficios de la arquitectura
Los beneficios de la arquitectura | 35
Cualidades del sistema de direcciones de arquitectura
La funcionalidad del sistema es soportada por la arquitectura a través de la
En términos generales, la arquitectura es un factor clave para reducir costos, mejorar la calidad,
visión arquitectónica unificadora; estas cualidades no se limitan a un único elemento arquitectónico,
sino que impregnan toda la arquitectura.
entre ellos.
para garantizar específicamente que se aborden dichas cualidades. Demostrando que tal
vehículo a través del cual se logran las cualidades del sistema. Cualidades como el rendimiento, la
seguridad y la mantenibilidad no se pueden lograr en ausencia de un
temprano en el ciclo de vida del proyecto. Las pruebas arquitectónicas de concepto a menudo se crean
una prueba de concepto de arquitectura, donde estas lecciones dan como resultado la arquitectura
que contribuyen al cumplimiento de estos objetivos.
considerar el tiempo de ejecución de cada componente de la arquitectura y también
respaldar la entrega oportuna contra el cronograma, respaldar la entrega contra los requisitos y reducir
el riesgo. En esta sección, nos enfocamos en beneficios más específicos
Para abordar los requisitos de desempeño, por ejemplo, puede ser necesario
del proceso de desarrollo de software.
donde sea necesario. Todas estas preocupaciones son arquitectónicas y, en estos ejemplos,
son necesarios y que sus arquitecturas se crean tanto de arriba hacia abajo como
Además, debido a que los arquitectos a veces tienen que justificar su existencia, esta sección
proporciona munición útil para tratar la arquitectura como una parte crítica.
siendo refinado en consecuencia.
el tiempo dedicado a la comunicación entre componentes. De manera similar, para abordar los
requisitos de seguridad, puede ser necesario considerar la naturaleza de la comunicación entre los
componentes e introducir componentes específicos que tengan en cuenta la seguridad.
Los arquitectos exitosos reconocen que ambos enfoques de la arquitectura
a la arquitectura.
interacciones que se dan entre los diversos elementos que componen la arquitectura. Sin embargo,
una de las características clave de la arquitectura es que es el
preocuparse por los componentes individuales y las conexiones
Un beneficio relacionado de la arquitectura es que es posible evaluar tales cualidades
de abajo hacia arriba, que podría denominarse el enfoque de "encuentro en el medio"

La arquitectura apoya el proceso de planificación
La arquitectura impulsa el consenso
Arquitectura."
apoyar tal debate, el proceso de arquitectura necesita asegurar que la arquitectura sea
claramente comunicada y probada.
la arquitectura debe ser comunicada de manera efectiva para que este beneficio sea
aporte directo a estas actividades. Sin embargo, en términos de los beneficios que trae el
proceso de arquitectura, podría decirse que los principales beneficios son los relacionados con la
porque proporciona un vehículo para permitir el debate sobre la solución del sistema. Para
(y su visión) y miembros del equipo nuevos o existentes como parte de la capacitación. Otra vez,
cualidades se cumplen a través de una implementación real (en este caso, una arquitectura
se debatan las compensaciones, facilita las revisiones y permite que se llegue a un acuerdo.
Impulsar el consenso también se logra al validar que la arquitectura cumple
actividades detalladas de diseño e implementación, porque la arquitectura es un
y desarrollo de habilidades. El proceso de arquitectura puede soportar todas estas
preocupaciones, que es una de las principales razones por las que el arquitecto y el director del
proyecto deben tener una relación tan estrecha.
Una arquitectura comunicada de forma eficaz permite tomar decisiones y
logrado. Los equipos de desarrollo con una buena visión de lo que están implementando tienen
más posibilidades de implementar el producto como se desea.
apoyo brindado a las actividades de planificación y gestión de proyectos en general,
específicamente programación, asignación de trabajo, análisis de costos, gestión de riesgos,
debate que se produzca. Sin dicha entrada, es probable que la arquitectura resultante sea
una prueba de concepto ejecutable es una excelente manera de demostrar que el
la arquitectura ha abordado tales cualidades.
prueba de concepto) es importante porque no importa cuán buena sea la arquitectura
Por el contrario, una arquitectura mal comunicada no permite tal
de menor calidad. Claramente, un aspecto importante de comunicar la arquitectura de manera
efectiva es documentarla apropiadamente. Este tema es una preocupación principal para el
arquitecto y es el tema del Capítulo 4, “Documentación de un software
se ve en el papel, el software ejecutable es la única medida verdadera de si el
los requisitos indicados. Como se mencionó en la sección anterior, la creación de
El proceso de arquitectura impulsa el consenso entre las diversas partes interesadas.
En una nota relacionada, la arquitectura puede impulsar el consenso entre los arquitectos.
la arquitectura cumple con ciertas cualidades de tiempo de ejecución.
El proceso de arquitectura soporta varias disciplinas. Claramente, apoya la

Registro de errores
Cliente
Cuenta
Cumplimiento
Gestión
Gestión
Figura 2.8 Diagrama de componentes UML que muestra elementos arquitectónicamente significativos
Gran parte de este soporte se deriva del hecho de que la arquitectura identifica los
componentes significativos del sistema y las relaciones entre ellos.
Para los propósitos de esta discusión, considere un caso simple en el que cada
componente siempre se implementa en su totalidad (es decir, no creamos implementaciones
parciales de cada elemento y no existe separación entre la interfaz y la implementación).
En términos de programación, las dependencias implican un orden en el que se debe
considerar cada uno de estos elementos. Desde una perspectiva de implementación, por
ejemplo, las dependencias le dicen que el componente Registro de errores debe
implementarse antes que cualquier otra cosa, porque todos los demás componentes usan
este componente. A continuación, los componentes Gestión de clientes y Cumplimiento
se pueden implementar en paralelo porque no dependen unos de otros. Finalmente,
cuando se hayan implementado estos dos componentes, se puede implementar el
componente Gestión de cuentas. A partir de esta información, puede derivar el diagrama
de Gantt (una de las técnicas de planificación convencionales utilizadas por un director
de proyecto) que se muestra en la figura 2.9. La duración de cada una de las tareas
mostradas requiere cierta reflexión, pero puede derivarse parcialmente de la complejidad
de cada uno de los elementos arquitectónicos.
Considere el diagrama de componentes de UML en la Figura 2.8, que se ha mantenido
deliberadamente simple para los propósitos de esta discusión. Esta figura muestra cuatro
componentes con dependencias entre ellos.
El arquitecto también puede ayudar en la estimación de costos del proyecto. Los
costos asociados con un proyecto provienen de muchas áreas. Claramente, la duración
de las tareas y los recursos asignados a la tarea permiten que el costo de la mano de obra sea

El arquitecto también debe definir las prácticas, normas y directrices adecuadas que guiarán
a los diseñadores e implementadores en su trabajo.
Finalmente, la arquitectura identifica componentes discretos de la solución que pueden
proporcionar información en términos de las habilidades requeridas en el proyecto. Si los recursos
adecuadamente calificados no están disponibles dentro del proyecto o dentro de la organización,
la arquitectura claramente ayuda a identificar las áreas en las que se requiere la adquisición de
habilidades. Esta adquisición puede lograrse mediante el desarrollo del personal existente, la
subcontratación o la contratación de nuevo personal.
Uno de los principales objetivos del proceso de arquitectura es asegurarse de que la arquitectura
proporcione un marco sólido para el trabajo realizado por los diseñadores e implementadores.
Claramente, este objetivo es más que simplemente transmitir una visión arquitectónica. Para
garantizar la integridad de la arquitectura resultante, el arquitecto debe definir claramente la
arquitectura misma, que identifica los elementos significativos desde el punto de vista
arquitectónico, como los componentes del sistema, sus interfaces y sus interacciones.
Otro objetivo de la arquitectura es eliminar la creatividad innecesaria por parte de los diseñadores
e implementadores, y este objetivo se logra imponiendo las restricciones necesarias sobre lo que
pueden hacer los diseñadores e implementadores, porque la desviación de las restricciones
puede provocar la ruptura de la arquitectura.
Otro aspecto más de la arquitectura que ayuda a garantizar la integridad arquitectónica es la
adopción de actividades de revisión y evaluación adecuadas que confirmen el cumplimiento de
las normas y directrices arquitectónicas por parte de los diseñadores e implementadores.
determinado. La arquitectura también puede ayudar a determinar los costos relacionados con el
uso de componentes de terceros que se utilizarán en el sistema entregado. Otro costo se deriva
del uso de herramientas particulares que se requieren para apoyar la creación de los elementos
arquitectónicos. La arquitectura también implica la priorización de riesgos y la identificación de
estrategias adecuadas de mitigación de riesgos, las cuales se proporcionan como información
para el administrador del proyecto.
Implementar Cumplimiento
Implementar la gestión de clientes
Implementar la gestión de cuentas
Implementar registro de errores
La arquitectura impulsa la integridad arquitectónica
Figura 2.9 Diagrama de Gantt basado en dependencias entre elementos arquitectónicamente
significativos

La arquitectura proporciona una base para la reutilización
La arquitectura ayuda a gestionar la complejidad
La arquitectura reduce los costos de mantenimiento
En primer lugar, el proceso de arquitectura siempre debe garantizar que el
En términos de consumo de activos, la creación de una arquitectura apoya la identificación
de posibles oportunidades de reutilización. La identificación de los componentes significativos
desde el punto de vista arquitectónico y sus interfaces y calidades asociadas respalda la selección
de componentes listos para usar, sistemas existentes, aplicaciones empaquetadas, etc., que
pueden usarse para implementar estos componentes.
Los sistemas de hoy en día son más complejos que nunca, y esta complejidad debe gestionarse.
Como se mencionó anteriormente en este capítulo, debido a que una arquitectura se enfoca solo
en aquellos elementos que son significativos, proporciona una abstracción del sistema y, por lo
tanto, proporciona un medio para administrar la complejidad. Además, el proceso de arquitectura
considera la descomposición recursiva de componentes, que es claramente una buena forma de
tomar un gran problema y dividirlo en una serie de problemas más pequeños.
En términos de producción de activos, la arquitectura puede contener elementos que, por su
propia naturaleza, son aplicables fuera del sistema actual. La arquitectura puede contener un
mecanismo de registro de errores que podría reutilizarse en varios otros contextos. Dicha
reutilización generalmente es oportunista, mientras que una iniciativa de reutilización estratégica
considera los activos candidatos con anticipación. Tocamos este tema en el Capítulo 10, “Más allá
de lo básico”.
Finalmente, otro aspecto de la gestión de la complejidad es el uso de técnicas que permitan
comunicar abstracciones de la arquitectura. Puede elegir agrupar componentes en subsistemas o
separar las interfaces de la implementación, por ejemplo. La adopción de estándares de la industria
que permiten expresar abstracciones, como UML, es un lugar común en la industria hoy en día
para documentar la arquitectura de sistemas intensivos en software.
El proceso de arquitectura puede ayudar a reducir los costos de mantenimiento de varias maneras.
Hablamos más sobre la evaluación de la arquitectura en el Capítulo 8, "Creación de la arquitectura
lógica", y en el Capítulo 9, "Creación de la arquitectura física".
El proceso de arquitectura puede soportar tanto la producción como el consumo de activos
reutilizables. Los activos reutilizables son beneficiosos para una organización porque pueden
reducir el costo total de un sistema y también mejorar su calidad, dado que un activo reutilizable
ya ha sido probado (porque ya se ha utilizado).

La arquitectura admite el análisis de impacto
Resumen
que evolucionará con el tiempo, no para sistemas cuyo propósito es proporcionar una solución
táctica y cuya vida es limitada.
requieren cambios y luego aislarlos. Este proceso puede ser bastante sencillo si el cambio afecta
a un solo componente oa una pequeña cantidad de componentes. Sin embargo, algunos cambios,
como los relacionados con las cualidades del sistema, como
el impacto de hacer un cambio antes de que se lleve a cabo. Una arquitectura identifica los
componentes principales y sus interacciones, las dependencias entre
otros componentes que dependen de él. Estos análisis pueden ser de gran ayuda para
El arquitecto debe considerar las áreas del sistema que tienen más probabilidades de
Un beneficio importante de la arquitectura es que permite a los arquitectos razonar sobre
mantenedor del sistema es una parte interesada clave y que las necesidades del mantenedor
El arquitecto debe considerar cualquier posible requisito futuro al diseñar la arquitectura.
se dieron cuenta.
y el riesgo asociado con hacer el cambio.
libro: arquitectura, arquitecto y arquitecto. También se discutieron los beneficios de adoptar un
enfoque centrado en la arquitectura para el proceso de desarrollo de software.
como el rendimiento o la fiabilidad, no se pueden aislar de esta manera. Por esta razón, el
componentes, y la trazabilidad de estos componentes a los requisitos que
Este capítulo definió y explicó los conceptos centrales utilizados a lo largo de este
las decenas de usuarios para los que se diseñó originalmente el sistema pueden no ser posibles
sin cambiar la arquitectura de manera fundamental, por ejemplo.
del impacto sobre los componentes que colaboran para realizar este requerimiento.
El tema de la mantenibilidad es una preocupación principal solo para aquellos sistemas
del sistema; el arquitecto también se asegura de que se incorporen los mecanismos apropiados
para mantener el sistema y considera la adaptabilidad y extensibilidad del sistema al crear la
arquitectura. Además, el arquitecto
se abordan como una preocupación principal, no como una ocurrencia tardía. El resultado debería
sistema actual. Ampliar un sistema para admitir miles de usuarios en lugar de
ser una arquitectura que esté debidamente documentada para facilitar la mantenibilidad
Dada esta información, un cambio en un requisito se puede analizar en términos
de los miembros del equipo que crearon el sistema.
determinar el costo de un cambio, el impacto que un cambio tiene en el sistema,
De manera similar, el impacto de cambiar un componente se puede analizar en términos de
considera las habilidades disponibles para mantener el sistema, que pueden ser diferentes

Resumen | 41
terco. Sin embargo, quedan muchas cuestiones sin resolver, como lo que el arquitecto
realmente hace en un proyecto de desarrollo de software, lo que produce el arquitecto
y cómo se relaciona el rol del arquitecto con otros roles del proyecto.
Habiendo definido estos conceptos centrales, dirigimos nuestra atención a la
aplicación de estos conceptos dentro del proceso general de desarrollo de software en
el Capítulo 3, “Fundamentos del método”.

chapter 1-2-spanish.pdf

Recomendados

Recomendados

Más contenido relacionado

Similar a chapter 1-2-spanish.pdf

Similar a chapter 1-2-spanish.pdf (20)

Último

Último (20)

chapter 1-2-spanish.pdf