Just Enough Software Architecture Fairbanks 2010-Demo

Machine Translated by Google

Elogio por la arquitectura de software Just Enough: un enfoque basado en el riesgo
Si solo va a leer un libro sobre arquitectura de software, comience con este. Just Enough Software Architecture
cubre los conceptos esenciales de la arquitectura de software que todos (programadores, desarrolladores,
probadores, arquitectos y gerentes) necesitan saber, y proporciona consejos pragmáticos que se pueden poner
en práctica a las pocas horas de leerlo.
—Michael Keeling, ingeniero de software profesional
Este libro refleja la rara combinación del autor de un profundo conocimiento de los conceptos de arquitectura de
software y una amplia experiencia en la industria como desarrollador. Si es arquitecto, querrá que los
desarrolladores de su organización lean este libro. Si eres un desarrollador, léelo. El libro trata sobre arquitectura
en proyectos de software reales (no ideales). Describe un contexto que reconocerá y luego le muestra cómo
mejorar su práctica de diseño en ese contexto.
—Paulo Merson, arquitecto de software en ejercicio y

Científico visitante en el Instituto de Ingeniería de Software
El enfoque de Fairbanks en la arquitectura "solo lo suficiente" debería atraer a cualquier desarrollador que
intente descubrir cómo hacer manejable el proceso de arquitectura. Este enfoque se hace accesible a través de
ejemplos detallados y consejos que ilustran cómo se puede utilizar la comprensión del riesgo para gestionar el
desarrollo y el alcance de la arquitectura. Al mismo tiempo, Fairbanks brinda detalles sobre los aspectos más
académicos de la arquitectura del software, lo que debería ayudar a los desarrolladores interesados en
comprender la teoría y la práctica más amplias para aplicar estos conceptos a sus proyectos.
-Dr. Bradley Schmerl, científico sénior de sistemas, Facultad de Ciencias

de la Computación, Universidad Carnegie Mellon
El enfoque del modelo impulsado por el riesgo descrito en la arquitectura de software Just Enough de George
Fairbanks se ha aplicado al proyecto Extensible Information Modeler (XIM) aquí en el Centro Espacial Johnson
(JSC) de la NASA con mucho éxito. Es imprescindible para todos los miembros del proyecto, desde la gestión
del proyecto hasta los desarrolladores individuales. De hecho, es imprescindible para el cinturón de herramientas
de cada desarrollador. ¡La sección del modelo de código y los antipatrones por sí solos valen el costo del libro!
—Christopher Dean, arquitecto jefe, XIM,

Grupo de contratos de ciencias de la ingeniería - Centro espacial Johnson de la NASA
Just Enough Software Architecture lo guiará en la aplicación estratégica y táctica de las herramientas y
estrategias de la arquitectura de software para sus proyectos de software.
Tanto si es desarrollador como arquitecto, este libro es una base sólida y una referencia para sus proyectos
arquitectónicos.
—Nicholas Sherman, administrador de programas, Microsoft
Fairbanks sintetiza el pensamiento más reciente sobre procesos, ciclo de vida, arquitectura, modelado y
calidad de servicio en un marco coherente que es de aplicabilidad inmediata a las aplicaciones de TI. La
escritura de Fairbanks es excepcionalmente clara y precisa sin dejar de ser atractiva y muy legible. Just
Enough Software Architecture es una contribución importante a la literatura de arquitectura de aplicaciones
de TI y bien puede convertirse en un trabajo de referencia estándar para los arquitectos de aplicaciones
empresariales.
-Dr. Ian Maung, vicepresidente sénior de arquitectura empresarial de Citigroup y

exdirector de arquitectura empresarial de Covance
Este libro aborda directamente algunas de las necesidades clave de los profesionales del software que
buscan esa combinación de herramientas para ayudarlos a crear sistemas más efectivos, de manera más efectiva.
George recurre con frecuencia a su propia experiencia, combinando ideas importantes de la academia para
proporcionar un modelo conceptual, mejores prácticas seleccionadas de la industria para ampliar la cobertura
y orientación pragmática para crear arquitecturas de software que, en última instancia, sean más útiles y
realistas. Su enfoque simple basado en el riesgo enmarca gran parte del libro y ayuda a calibrar lo que
debería ser "lo suficiente". Este libro es una adición importante a cualquier estantería de arquitectura de
software.
—Desmond D'Souza, autor de MAp y Catálisis, Kinetium, Inc.
Este libro muestra cómo la arquitectura de software lo ayuda a crear software en lugar de distraerlo del
trabajo; el libro le permite identificar y abordar solo aquellas preocupaciones arquitectónicas críticas que de
otro modo le impedirían escribir código.
-Dr. Kevin Bierhoff, ingeniero de software profesional
Los desarrolladores de sistemas y software que se pregunten por qué y dónde acerca de la arquitectura del
software apreciarán los argumentos claros y las analogías esclarecedoras que presenta este libro; los
desarrolladores que luchan con cuándo y cómo hacer arquitectura descubrirán la orientación suficiente, junto
con conceptos e ideas que aclaran, empoderan y liberan. En general, este libro es fácil de leer, conciso, pero
rico en referencias: ¡un libro bien diseñado y con una buena arquitectura!
—Dr. Shang-Wen Cheng, ingeniero de software de vuelo

Sólo lo suficiente
Software
Arquitectura
Un enfoque basado en el riesgo
Jorge Fairbanks
Muchas designaciones utilizadas por vendedores y fabricantes para distinguir sus productos se reclaman
como marcas comerciales. En los casos en que Marshall & Brainerd tenga conocimiento de un reclamo, las
designaciones aparecen en mayúscula inicial o en mayúsculas.
El autor y el editor se han ocupado de la preparación de este libro, pero no se expresa ni implica ninguna
garantía de ningún tipo. El autor y el editor no asumen ninguna responsabilidad por errores u omisiones, ni
asumen ninguna responsabilidad por daños incidentales o consecuentes relacionados con el uso del contenido
de este libro o que surjan del mismo.
Publicado por Marshall & Brainerd 2445

7th Street
Canto rodado, CO 80304
(303) 834-7760
Copyright © 2010 George Fairbanks
Todos los derechos reservados. Ninguna parte de este libro puede ser reproducida, almacenada en un
sistema de recuperación o transmitida, de ninguna forma o por ningún medio, ya sea electrónico, mecánico,
fotocopiado, grabación o cualquier otro, sin el consentimiento previo del editor.
Número de control de la Biblioteca del Congreso: 2010910450
ISBN 978-0-9846181-0-1
Primera impresión, agosto de 2010

Prefacio
En la década de 1990, la arquitectura de software surgió como un subcampo explícito de la ingeniería de

software cuando se reconoció ampliamente que conseguir la arquitectura correcta era una cuestión fundamental.
habilitador clave para crear un sistema basado en software que cumpliera con sus requisitos. Qué
Lo que siguió fue una vertiginosa variedad de propuestas de notaciones, herramientas, técnicas y procesos
para respaldar el diseño arquitectónico y para integrarlo en las prácticas de desarrollo de software existentes.
Y, sin embargo, a pesar de la existencia de este cuerpo de material, atención de principios a

la arquitectura de software en muchos casos no ha llegado a la práctica común.
Parte de la razón de esto ha sido una especie de polarización de opiniones sobre
el papel que debe jugar la arquitectura. Por un lado, existe una escuela de pensamiento que aboga por un
diseño centrado en la arquitectura, en el que la arquitectura juega un papel central y esencial.
papel a lo largo del proceso de desarrollo de software. Las personas en este campamento han tendido
centrarse en diseños arquitectónicos detallados y completos, arquitectura bien definida
hitos y estándares explícitos para la documentación de la arquitectura. Por otro lado
es una escuela de pensamiento que resta importancia a la arquitectura, argumentando que surgirá
naturalmente como un subproducto de un buen diseño, o que no es necesario en absoluto ya que la
arquitectura es obvia para esa clase de sistema. Las personas en este campo han tendido a enfocarse
en minimizar el diseño arquitectónico como una actividad separada de la implementación, y
en reducir o eliminar la documentación arquitectónica.
Claramente, ninguno de estos campos tiene derecho a todos los sistemas. Efectivamente, el centro
La pregunta que se debe hacer es "¿Cuánto diseño arquitectónico explícito se debe
llevar a cabo para un sistema dado?
En este libro, George Fairbanks propone una respuesta: “Just Enough Architecture”.
La primera reacción de uno a esto podría ser "¡Bueno, duh!" porque quien querría demasiado
o muy poco. Pero, por supuesto, hay más que eso, y es precisamente el detalle de los principios para
descubrir qué significa "lo suficiente" lo que constituye la idea central de este artículo.
nosotros Prefacio
libro. Como tal, proporciona una forma refrescante y no dogmática de abordar la arquitectura de software, una con un
enorme valor práctico.
Fairbanks argumenta que el criterio central para determinar cuánta arquitectura es suficiente es la reducción del
riesgo. Donde hay poco riesgo en un diseño, se necesita poca arquitectura. Pero cuando surgen problemas de diseño
de sistemas duros, la arquitectura es una herramienta con un enorme potencial. De esta manera, el libro adopta una
verdadera perspectiva de ingeniería sobre la arquitectura, en el sentido de que promueve directamente la consideración
de los costos y beneficios en la selección de una técnica. Específicamente, centrarse en la reducción de riesgos alinea
los beneficios de la ingeniería con los costos al garantizar que el diseño arquitectónico se utilice en situaciones en las
que es probable que tenga la mayor rentabilidad.
Naturalmente, hay muchas preguntas secundarias que responder. ¿Qué riesgos se abordan mejor con la arquitectura
de software? ¿Cómo aplica los principios de diseño arquitectónico para resolver un problema de diseño? ¿Qué anotas
sobre tus compromisos arquitectónicos para que los demás sepan cuáles son? ¿Cómo puede ayudar a garantizar que
los implementadores posteriores respeten los compromisos arquitectónicos?
Este libro responde a todas estas preguntas y muchas más, lo que lo convierte en una contribución única, práctica
y accesible al campo de la arquitectura de software. Para cualquier persona que deba crear sistemas de software
innovadores, para cualquier persona que se enfrente a decisiones difíciles sobre las compensaciones de diseño, para
cualquier persona que deba encontrar un equilibrio adecuado entre agilidad y disciplina, en resumen, para casi cualquier
ingeniero de software, esta es una lectura esencial.
david garlan
Profesor, Facultad de Ciencias de la Computación

Director de Programas Profesionales de Ingeniería de Software
Universidad de Carnegie mellon
mayo de 2010
Prefacio
Este es el libro que desearía haber tenido cuando comencé a desarrollar software. En ese momento,
había libros sobre lenguajes y libros sobre programación orientada a objetos, pero pocos libros sobre
diseño. Conocer las características del lenguaje C++ no significa que pueda diseñar un buen sistema
orientado a objetos, ni conocer el Lenguaje de modelado unificado (UML) implica que pueda diseñar
una buena arquitectura de sistema.
Este libro es diferente de otros libros sobre arquitectura de software. Esto es lo que lo distingue:
Enseña arquitectura impulsada por el riesgo. No hay necesidad de diseños meticulosos cuando los
riesgos son pequeños, ni ninguna excusa para diseños descuidados cuando los riesgos amenazan su éxito.
Muchos defensores de software ágil de alto perfil sugieren que algún diseño inicial puede ser útil, y este
libro describe una manera de hacer suficiente arquitectura. Evita el pozo de alquitrán del proceso de
"talla única" con consejos sobre cómo ajustar su arquitectura y sus esfuerzos de diseño en función de
los riesgos que enfrenta. El rigor de la mayoría de las técnicas se puede ajustar, desde rápido y sucio
hasta meticuloso.
Democratiza la arquitectura. Es posible que tenga arquitectos de software en su organización; de

hecho, puede ser uno de ellos. Todos los arquitectos que he conocido desean que todos los
desarrolladores entiendan la arquitectura. Se quejan de que los desarrolladores no entienden por qué
existen las restricciones y cómo cambios aparentemente pequeños pueden afectar las propiedades de
un sistema. Este libro busca hacer que la arquitectura sea relevante para todos los desarrolladores de
software, no solo para los arquitectos.
Cultiva el conocimiento declarativo. Hay una diferencia entre ser capaz de golpear una pelota de
tenis y saber por qué eres capaz de golpearla, lo que los psicólogos denominan conocimiento
procedimental versus conocimiento declarativo. Si ya es un experto en el diseño y la construcción de
sistemas, habrá empleado muchas de las técnicas.
viii Prefacio
encontrado aquí, pero este libro lo hará más consciente de lo que ha estado haciendo y proporcionará
nombres para los conceptos. Ese conocimiento declarativo mejorará su capacidad para guiar a otros
desarrolladores.
Destaca la ingeniería. Las personas que diseñan y construyen sistemas de software tienen que hacer
muchas cosas, incluido el manejo de cronogramas, compromisos de recursos y necesidades de las
partes interesadas. Muchos libros sobre arquitectura de software ya cubren procesos de desarrollo de
software y estructuras organizacionales. Este libro, por el contrario, se centra en las partes técnicas del
desarrollo de software y se ocupa de lo que hacen los desarrolladores para garantizar que un sistema
funcione: la ingeniería. Le muestra cómo construir modelos y analizar arquitecturas para que pueda
hacer concesiones de diseño basadas en principios. Describe las técnicas que usan los diseñadores de
software para razonar sobre problemas de mediano a gran tamaño y señala dónde puede aprender
técnicas especializadas con más detalle. En consecuencia, a lo largo de este libro, se hace referencia a
los ingenieros de software como desarrolladores, sin diferenciar a los arquitectos de los programadores.
Proporciona consejos prácticos. Este libro ofrece un tratamiento práctico de la arquitectura.

La arquitectura de software es un tipo de diseño de software, pero las decisiones de diseño influyen en
la arquitectura y viceversa. Lo que hacen los mejores desarrolladores es profundizar en los obstáculos
en detalle, comprenderlos y luego volver a aparecer para relacionar la naturaleza de esos obstáculos
con la arquitectura en su conjunto. El enfoque de este libro adopta este comportamiento de desglose/
ventana emergente mediante la descripción de modelos que tienen varios niveles de abstracción, desde
la arquitectura hasta el diseño de la estructura de datos.
Sobre mí
Mi carrera ha sido una búsqueda para aprender a construir sistemas de software. Esa búsqueda me ha
llevado a intercalar lo académico con el desarrollo de software industrial. Tengo el conjunto completo de
títulos de ciencias de la computación del coleccionista: una licenciatura, una maestría y un doctorado
(el doctorado es de la Universidad Carnegie Mellon, en ingeniería de software). Para mi tesis, trabajé
en marcos de software porque son un problema que enfrentan muchos desarrolladores. Desarrollé un
nuevo tipo de especificación, llamado fragmento de diseño, para describir cómo usar marcos, y construí
una herramienta basada en Eclipse que puede validar su uso correcto.
Fui enormemente afortunado de ser asesorado por David Garlan y Bill Scherlis, y de tener a Jonathan
Aldrich y Ralph Johnson en mi comité.
Valoro el rigor académico, pero mis raíces están en la industria. He sido desarrollador de software
en proyectos que incluyen el interruptor telefónico de la oficina central Nortel DMS-100, análisis
estadístico para un simulador de manejo, una aplicación de TI en Time Warner Telecom munications,
complementos para Eclipse IDE y hasta la última puntada de código para mi propia empresa de inicio
web. Jugueteo con las cajas de Linux como administrador de sistemas aficionado y tengo un armario
iluminado por luces parpadeantes y calentado por fuentes de alimentación. he sup-
Prefacio ix
portaron técnicas ágiles desde sus inicios: en 1996 animé con éxito a mi departamento a
cambiar de un ciclo de desarrollo de seis meses a uno de dos semanas, y en 1998 comencé
a hacer primero el desarrollo de prueba.
¿Para quién es este libro?
La audiencia principal de este libro son los desarrolladores de software en ejercicio. Los
lectores ya deberían conocer ideas básicas de desarrollo de software, como el desarrollo de
software orientado a objetos, UML, casos de uso y patrones de diseño. Un poco de
experiencia sobre cómo procede el desarrollo de software real será de gran ayuda, porque
muchos de los argumentos básicos de este libro se basan en experiencias comunes. Si ha
visto a los desarrolladores crear demasiada documentación o pensar demasiado poco antes
de codificar, sabrá cómo el desarrollo de software puede fallar y, por lo tanto, buscará
remedios como los que se ofrecen en este libro. Este libro también es adecuado como libro
de texto en un curso avanzado de pregrado o posgrado.
Esto es lo que puede esperar según el tipo de lector que sea:
Desarrolladores o estudiantes Greenhorn. Si ya ha aprendido la mecánica básica del

desarrollo de software, como los lenguajes de programación y el diseño de estructuras de
datos e, idealmente, ha tomado una clase general de ingeniería de software, este libro le
presentará modelos específicos de software que lo ayudarán a formar un modelo conceptual
de arquitectura de software. Este modelo lo ayudará a comprender el caos de los grandes
sistemas sin tener que dibujar muchos diagramas y documentación. Puede darle una primera
muestra de ideas tales como atributos de calidad y estilos arquitectónicos. Aprenderá cómo
tomar su comprensión de los programas pequeños y aumentarla a escala y calidad
industriales completas. Puede acelerar su progreso para convertirse en un desarrollador
efectivo y experimentado.
Desarrolladores experimentados. Si eres bueno en el desarrollo de sistemas, entonces

se te pedirá que seas mentor de otros. Sin embargo, es posible que descubra que tiene una
perspectiva un tanto idiosincrásica de la arquitectura, tal vez utilizando notaciones o
terminología de diagrama únicas. Este libro lo ayudará a mejorar su capacidad para guiar a
otros, comprender por qué puede tener éxito donde otros luchan y le enseñará sobre
modelos, notaciones y nombres estándar.
Arquitectos de software. El papel del arquitecto de software puede ser difícil cuando otros
en su organización no entienden lo que hace y por qué lo hace. Este libro no solo le enseñará
técnicas para construir sistemas, sino que también le brindará formas de explicar lo que está
haciendo y cómo lo está haciendo. Tal vez incluso entregue este libro a sus compañeros de
trabajo para que puedan trabajar mejor como compañeros de equipo.
X Prefacio
Académica. Este libro hace varias contribuciones al campo de la arquitectura de software.

Introduce el modelo de arquitectura de software basado en el riesgo , que es una forma de
decidir cuánto trabajo de arquitectura y diseño hacer en un proyecto. Describe tres enfoques de
la arquitectura: diseño indiferente a la arquitectura, diseño centrado en la arquitectura y elevación
de la arquitectura. Integra dos perspectivas sobre la arquitectura del software: la perspectiva
funcional y la perspectiva del atributo de calidad, dando como resultado un único modelo
conceptual. E introduce la idea de un estilo de codificación arquitectónicamente evidente que
hace que su arquitectura sea evidente al leer el código fuente.
Expresiones de gratitud
Este libro no hubiera sido posible sin la generosa ayuda de muchas personas. Varios trabajaron
de cerca conmigo en uno o más capítulos y merecen un reconocimiento especial por su ayuda:
Kevin Bierhoff, Alan Birchenough, David Garlan, Greg Hartman, Ian Maung, Paulo Merson,
Bradley Schmerl y Morgan Stanfield.
Otros sufrieron borradores iniciales malos, detectaron una gran cantidad de problemas y
brindaron la orientación necesaria: Len Bass, Grady Booch, Christopher Dean, Michael Donohue,
Daniel Dvorak, Anthony Earl, Hans Gyllstrom, Tim Halloran, Ralph Hoop, Michael Keeling, Ken
LaToza , Thomas LaToza, Louis Marbel, Andy Myers, Carl Paradis, Paul Rayner, Patrick Riley,
Aamod Sane, Nicholas Sherman, Olaf Zimmermann y Guido Zgraggen. Gracias.
Sería negligente si no reconociera a todas las personas que me han guiado a lo largo de los
años, comenzando por mis padres, quienes me brindaron más apoyo del que puedo describir.
Mis mentores profesionales han incluido a Desmond D'Souza y la pandilla de Icon Computing;
mis asesores de tesis, David Garlan y Bill Scherlis; y la facultad y los estudiantes de Carnegie
Mellon.
La maravillosa ilustración de la portada fue concebida y dibujada por mi amiga Lisa Haney
(http://LisaHaney.com). Alan Apt ha sido una fuente de orientación y apoyo durante el proceso
de escritura del libro.
La preparación de este libro se realizó principalmente con herramientas de código abierto,
incluido el sistema operativo Linux, el procesador de documentos LYX, el estilo LATEX de
Memoir, el sistema de preparación de documentos LATEX y el editor de dibujo Inkscape. La
mayoría de los diagramas se crearon con Microsoft Visio y la plantilla Visio UML de Pavel Hruby.
Contenido
Prefacio v
Prefacio vienes
Contenido xi
1 Introducción 1
1.1 Particionamiento, conocimiento y abstracciones .. . . ... ... . . ... 2
1.2 Tres ejemplos de arquitectura de software . . ... ... ... . . ... 3
1.3 Reflexiones . . ..... ... ... ... . . ... ... ... . . ... 5
1.4 Cambio de perspectiva . . . . . . . . . . . . . . . ... ... ... . . ...6
1.5 Arquitectos construyendo arquitecturas . . . . . ... ... ... . . ...7
1.6 Arquitectura de software impulsada por el riesgo . . . . . . ... ... ... . . ...8
1.7 Arquitectura para desarrolladores ágiles . . . . . . ... ... ... . . ...9
1.8 Acerca de este libro . . . . . . . . . . . . . . . . ... ... ... . . . . . 10
I Arquitectura de software orientada al riesgo 13
2 Arquitectura de software 2.1 15

¿Qué es la arquitectura de software? . . ...
. . ... ... ... . . . . . dieciséis
2.2 ¿Por qué es importante la arquitectura de software? . . ... ... ... . . . . . 18

2.3 ¿Cuándo es importante la arquitectura? . . . . . . ... ... ... . . ... 22
2.4 Arquitecturas presuntivas . . ... ... . . ... ... ... . . . . . 23
2.5 ¿Cómo se debe utilizar la arquitectura de software? . ... ... ... . . . . . 24
2.6 Diseño indiferente a la arquitectura . . . . . . . ... ... ... . . . . . 25
2.7 Diseño centrado en la arquitectura . . . . ... . . ... ... ... . . . . . 26
xi CONTENIDO
2.8 Izado de arquitectura . . ... ... ... . . ... ... ... . . . . . 27

2.9 Arquitectura en grandes organizaciones . . . . . ... ... ... . . . . . 30
2.10 Conclusión . . ..... ... ... ... . . ... ... ... . . . . . 31
2.11 Lecturas adicionales . . . . . . . . . . . . . . . . ... ... ... . . . . . 32
3 Modelo impulsado por el riesgo 35

...
3.1 ¿Qué es el modelo orientado al riesgo? . . . .
... ... ... . . . . . 37
3.2 ¿Está impulsado por el riesgo ahora? . . . . .
... . .
... ... ... . . . . . 38
3.3 Riesgos . . ... ..... ... ...... . .
... ... ... . . . . . 39
3.4 Técnicas . . . . . . . ... ...... . .
... ... ... . . . . . 42
3.5 Orientación en la elección de técnicas . . . . . .
... ... ... . . . . . 44
3.6 Cuándo parar . ..... ... ... ... . .
... ... ... . . . . . 47
3.7 Diseño planificado y evolutivo . ... . .
... ... ... . . . . . 48
3.8 Proceso de desarrollo de software . . . . . . .
... ... ... . . . . . 51
3.9 Comprender las variaciones del proceso . . . . . .
... ... ... . . . . . 53
3.10 El modelo orientado al riesgo y los procesos de software . . . . . ... . . . . . 55
3.11 Aplicación a procesos ágiles . ... . . ... ... ... . . . . . 56
3.12 Refactorización de riesgos y arquitectura . . . . . . . . . . . . ... . . . . . 58
3.13 Alternativas al modelo basado en riesgos . . . . ... ... ... . . . . . 58
3.14 Conclusión . . ..... ... ... ... . . ... ... ... . . . . . 60
3.15 Lecturas adicionales . . . . . . . . . . . . . . . . . . . . .
. ... . . . . . 61
4 Ejemplo: Home Media Player sesenta y cinco
4.1 Comunicación del equipo . . . . ... ... . . ... ... ... . . . . . 67

4.2 Integración de componentes COTS . . . . . . ... ... ... . . . . . 75
4.3 Coherencia de los metadatos . . . . . . . . . . . . ... ... ... . . . . . 81
4.4 Conclusión . . ..... ... ... ... . . ... ... ... . . . . . 86
5 Consejos de modelado 89
5.1 Enfoque en los riesgos . ..... ... ... ... . . ... ... ... . . . . . 89
5.2 Comprenda su arquitectura . . . ... . . ... ... ... . . . . . 90
5.3 Distribuir habilidades de arquitectura . ... ... . . ... ... ... . . . . . 91
5.4 Hacer elecciones racionales de arquitectura . . . . . ... ... ... . . . . . 92
5.5 Evite un gran diseño desde el principio . .... ... . . ... ... ... . . . . . 93
...
5.6 Evite el diseño de arriba hacia abajo . ... ... . . ... ... ... . . . . . 95
5.7 Retos pendientes . ... ... ... . . ... ... ... . . . . . 95
5.8 Características y riesgo: una historia . . . . . ... . . ... ... ... . . . . . 97
CONTENIDO XIII
II Modelado de Arquitectura 101
6 Los ingenieros usan 103

. . . .. . . .
modelos 6.1 La escala y la complejidad requieren abstracción ... . . . . . 104
6.2 Las abstracciones proporcionan información y apalancamiento . . ... ... ... . . . . . 105
6.3 Razonamiento sobre las cualidades del sistema . ... . . ... ... ... . . . . . 105
6.4 Modelos elide detalles . . ... ... ... . . ... ... ... . . . . . 106
6.5 Los modelos pueden amplificar el razonamiento . . . . . . . . ... ... ... . . . . . 107
6.6 Pregunta primero y modelo segundo . . . . . . . ... ... ... . . . . . 108
6.7 Conclusión . . ..... ... ... ... . . ... ... ... . . . . . 108
6.8 Lecturas adicionales . . . . . . . . . . . . .
. . . ... ... ... . . . . . 109
7 Modelo Conceptual de Arquitectura de 111

. . . . . ..
Software 7.1 Estructura del modelo canónico . . ... ... ... . . . . . 114
7.2 Modelos de dominio, diseño y código . . . . . . ... ... ... . . . . . 115
7.3 Relaciones de designación y refinamiento . . ... ... ... . . . . . 116
7.4 Vistas de un modelo maestro . . . . . . . . . . . ... ... ... . . . . . 118
7.5 Otras formas de organizar los modelos . . . . . . . ... ... ... . . . . . 121
7.6 Modelado de negocios . . . . . . . . . . . . . . ... ... ... . . . . . 121
7.7 Uso de UML . . ..... ... ... ... . . ... ... ... . . . . . 122
7.8 Conclusión . . ..... ... ... ... . . ... ... ... . . . . . 123
8 El modelo de dominio 127

8.1 Cómo se relaciona el dominio con la arquitectura . . . ... ... ... . . . . . 128
8.2 Modelo de información . . . . . . ... ... . . ... ... ... . . . . . 131
8.3 Navegación e invariantes . . ... ... . . ... ... ... . . . . . 133
8.4 Instantáneas . . . . . . . . ... ... ... . . ... ... ... . . . . . 134
8.5 Escenarios de funcionalidad . . . . ... ... . . ... ... ... . . . . . 135
8.6 Conclusión . . ..... ... ... ... . . ... ... ... . . . . . 136
8.7 Lecturas adicionales . . . . . . .
. ... ... . . ... ... ... . . . . . 137
9 El modelo de diseño 139

9.1 Modelo de diseño . . . . . . ... ...
... . . ... ... ... . . . . . 140
9.2 Modelo de frontera . . . . ... ...
... . . ... ... ... . . . . . 141
9.3 Modelo interno . . . . . ... ...
... . . ... ... ... . . . . . 141
9.4 Atributos de calidad . . . . ... . ...
.. . . ... ... ... . . . . . 142
9.5 Tutorial del diseño de Yinzer . . . ... . . ... ... ... . . . . . 143
9.6 Tipos de vista . . . . . . . . . . . . . . .. . . ... ... ... . . . . . 157
9.7 Modelos de arquitectura dinámica . . . . . . . . ... ... ... . . . . . 161
9.8 Lenguajes de descripción de arquitectura . . . . . ... ... ... . . . . . 162
xiv CONTENIDO
9.9 Conclusión . . ..... ... ... ... . . ... ... ... . . . . . 163
9.10 Lectura adicional . . . . . ... ... ... . . ... ... ... . . . . . 164
10 El modelo de código 167

10.1 Brecha modelo-código . . . . . . . ... ... . . ...
... ... . . . . . 167
10.2 Gestión de la coherencia . . . . ... ... . . ...
... ... . . . . . 171
10.3 Estilo de codificación arquitectónicamente evidente . . . . . ...
... ... . . . . . 174
10.4 Expresar la intención del diseño en el código . . . . . . . ...
... ... . . . . . 175
10.5 Principio de modelo en código . . . . . . . . . . . ...
... ... . . . . . 177
10.6 Qué expresar . . . . ... ... ... . . ...
... ... . . . . . 178
10.7 Patrones para expresar la intención del diseño en el código . . . . . . ... . . . . . 180
10.8 Tutorial de un sistema de procesamiento de correo electrónico . . . . . . ... . . . . . 187
10.9 Conclusión . . ..... ... ... ... . . ... ... ... . . . . . 193
11 Encapsulación y partición 195

11.1 Historia en muchos niveles. .. .. . . . . ... . ... ... ... . . . . . 195
11.2 Jerarquía y partición . . . . . . ... . ... ... ... . . . . . 197
11.3 Estrategias de descomposición . . . . . . ... . ... ... ... . . . . . 199
11.4 Encapsulamiento efectivo . . . . . . . . ... . ... ... ... . . . . . 203
11.5 Construcción de una interfaz encapsulada . . . . . ... ... ... . . . . . 206
11.6 Conclusión . . ..... ... ... ... . . ... ... ... . . . . . 210
12 elementos del modelo 213

12.1 Elementos de asignación . . ... ... ... . . ... ... ... . . . . . 214
12.2 Componentes . ..... ... ... ... . . ... ... ... . . . . . 215
12.3 Conjuntos de componentes . . . . ... ... . . ... ... ... . . . . . 219
12.4 Conectores . . ..... ... ... ... . . ... ... ... . . . . . 223
12.5 Decisiones de diseño . . . . . . . ... ... . . ... ... ... . . . . . 233
12.6 Escenarios de funcionalidad . . . . ... ... . . ... ... ... . . . . . 234
12.7 Invariantes (restricciones) . . . ... ... . . ... ... ... . . . . . 239
12.8 Módulos . . . ..... ... ... ... . . ... ... ... . . . . . 239
12.9 Puertos . . . . . . . . . . ... ... ... . . ... ... ... . . . . . 241
12.10 Atributos de calidad . . . . . .. ... ... . . ... ... ... . . . . . 246
12.11 Escenarios de atributos de calidad . . . . . ... . . ... ... ... . . . . . 249
12.12 Responsabilidades . . . . . . . . . . . ... . . ... ... ... . . . . . 251
12.13 Compensaciones . . . . . . . . ... ... ... . . ... ... ... . . . . . 252
12.14 Conclusión . . ..... ... ... ... . . ... ... ... . . . . . 253
13 Relaciones de 255
. . .. . .. . . . .
modelo 13.1 Relación de proyección (vista) ... ... . . . . . 256
CONTENIDO XV
13.2 Relación de partición . . ... ... ... . . ... ... ... . . . . . 261
13.3 Relación de composición . . ... ... . . ... ... ... . . . . . 261
13.4 Relación de clasificación . . ... ... . . ... ... ... . . . . . 261
13.5 Relación de generalización . ... ... . . ... ... ... . . . . . 262
13.6 Relación de designación . . . ... ... . . ... ... ... . . . . . 263
13.7 Relación de refinamiento . . . ... ... . . ... ... ... . . . . . 264
13.8 Relación vinculante . . ... ... ... . . ... ... ... . . . . . 268
13.9 Relación de dependencia . . . ... ... . . ... ... ... . . . . . 269
13.10 Uso de las relaciones . ... ... ... . . ... ... ... . . . . . 269
13.11 Conclusión . . ..... ... ... ... . . ... ... ... . . . . . 270
13.12 Lecturas adicionales . . . . . . .
. ... ... . . ... ... ... . . . . . 271
14 Estilos 273
. . . . . .... .
Arquitectónicos 14.1 Ventajas ... ... . . ... ... ... . . . . . 274
14.2 Estilos platónicos vs. encarnados . . . . . . . . . . . . . . . ... . . . . . 275
14.3 Restricciones y diseño centrado en la arquitectura . . . . . . ... . . . . . 276
14.4 Patrones frente a estilos . . . . . . . . . . . . . . . . . . . . ... . . . . . 277
14.5 Un catálogo de estilos . . . ... ... ... . . ... ... ... . . . . . 277
14.6 Estilo en capas . . . . . . ... ... ... . . ... ... ... . . . . . 277
14.7 Estilo gran bola de barro . . ... ... ... . . ... ... ... . . . . . 280
14.8 Estilo de tubería y filtro . . . ... ... ... . . ... ... ... . . . . . 281
14.9 Estilo secuencial por lotes . ... ... ... . . ... ... ... . . . . . 283
14.10 Estilo centrado en el modelo . . . . . ... ... . . ... ... ... . . . . . 285
14.11 Estilo de publicación-suscripción . . . . ... ... . . ... ... ... . . . . . 286
14.12 Estilo cliente-servidor y N niveles . . . . . ... . . ... ... ... . . . . . 288
14.13 Estilo de igual a igual . . . . . . . . . . ... . . ... ... ... . . . . . 290
14.14 Estilo de reducción de mapa . . . . . . . . . .
... . . ... ... ... . . . . . 291
14.15 Estilos espejados, de estante y de granja . . . . . . . ... ... ... . . . . . 293
14.16 Conclusión . . ..... ... ... ... . . ... ... ... . . . . . 294
15 Uso de modelos de arquitectura 297

15.1 Características deseables del modelo . ...
... ... . . ... ... ... . . . . . 297
15.2 Trabajar con vistas . . ...
... ... . . ... ... ... . . . . . 303
15.3 Mejora de la calidad de visualización . ...
... ... . . ... ... ... . . . . . 306
15.4 Mejora de la calidad del diagrama . . . . . ... . . ... ... ... . . . . . 310
15.5 Pruebas y demostraciones . . . . . . . . ... . . ... ... ... . . . . . 312
15.6 Análisis de modelos de arquitectura . . . . . . . ... ... ... . . . . . 312
15.7 Desajuste arquitectónico . . . ... ... . . ... ... ... . . . . . 318
15.8 Elija su nivel de abstracción . . . ... . . ... ... ... . . . . . 319
15.9 Planificación de la interfaz de usuario . . . . . . . . ... ... ... . . . . . 320
xvi CONTENIDO
15.10 Modelos prescriptivos vs descriptivos . . . . . ... ... ... . . . . . 320

15.11 Modelado de sistemas existentes . . . . . . . . . . ... ... ... . . . . . 320
15.12 Conclusión . . ..... ... ... ... . . ... ... ... . . . . . 322
16 Conclusión 325
16.1 Desafíos . . ..... ... ... ...
. . ... ... ... . . . . . 326
16.2 Centrarse en los atributos de calidad . . . . . ...
. . ... ... ... . . . . . 330
16.3 Resolver problemas, no solo modelarlos . . . . ... ... ... . . . . . 331
16.4 Usar restricciones como rieles de guía . . . . . . . . ... ... ... . . . . . 332
16.5 Utilizar abstracciones arquitectónicas estándar . . . ... ... ... . . . . . 333
Glosario 335
Bibliografía 347
Índice 355
Capítulo 1
Introducción
Década tras década, los sistemas de software han experimentado aumentos de órdenes de magnitud en su
tamaño y complejidad. Esto es notable, y más que un poco aterrador para aquellos de nosotros que creamos
software. Por el contrario, imagina lo difícil que sería el baloncesto si se escalara de la misma manera, con
5 personas en la cancha una década, luego 50, luego 500.
Debido a este crecimiento, se puede decir que los sistemas de software actuales son las cosas más grandes
y complejas jamás construidas.
Los desarrolladores de software siempre están luchando contra los enemigos cada vez más fuertes de
la complejidad y la escala, pero a pesar de que su oponente crece en fuerza, los desarrolladores han evitado
la derrota e incluso se han deleitado con la victoria. ¿Cómo han hecho esto?
Una respuesta es que los aumentos en el tamaño y la complejidad del software han sido acompañados
por avances en la ingeniería de software. La programación en lenguaje ensamblador dio paso a lenguajes
de alto nivel y programación estructurada. Los procedimientos, en muchos dominios, han dado paso a los
objetos. Y la reutilización de software, que solía significar solo subrutinas, ahora también se realiza con
amplias bibliotecas y marcos.
No es coincidencia que la batalla entre los desarrolladores y la complejidad del software siempre
parezca estar en un punto muerto. Dado que los desarrolladores no pueden desarrollar cerebros más
grandes, en su lugar han mejorado sus armas. Un arma mejorada ofrece a los desarrolladores dos opciones:
conquistar más fácilmente los problemas de ayer o combatir los de mañana. No somos más inteligentes
que los desarrolladores de la generación anterior, pero nuestras armas mejoradas nos permiten crear
software de mayor tamaño y complejidad.
Los desarrolladores de software manejan algunas armas tangibles, como los entornos de desarrollo
integrado (IDE) y los lenguajes de programación, pero se puede decir que las armas intangibles tienen un
impacto mayor. Volviendo a nuestra metáfora del baloncesto, considere un entrenador
2 CAPÍTULO 1 INTRODUCCIÓN
y un novato (un jugador de deportes novato) viendo el mismo juego. El entrenador ve más que el novato,
no porque los ojos del entrenador sean más agudos, sino porque tiene un arma intangible. Ha construido
un conjunto de abstracciones mentales que le permiten convertir sus percepciones de fenómenos en
bruto, como el pase de una pelota, en una comprensión condensada e integrada de lo que está
sucediendo, como el éxito de una estrategia ofensiva. El entrenador ve el mismo partido que el novato,
pero lo entiende mejor. Alan Kay ha observado que su “punto de vista vale 80 puntos de CI” (Kay, 1989).
El software es similar en el sentido de que hay muchos detalles de bajo nivel. Si los desarrolladores
han creado un conjunto de abstracciones mentales (es decir, un modelo conceptual), pueden convertir
esos detalles en una comprensión condensada: donde antes solo veían código, tal vez ahora vean una
política de bloqueo seguro para subprocesos o una estrategia basada en eventos. sistema.
1.1 Particionamiento, conocimiento y abstracciones
Para tener éxito en la lucha contra la escala y la complejidad del software en la próxima década, los
desarrolladores necesitarán armas mejoradas. Esas armas se pueden categorizar, quizás con un poco
de calzador, en tres categorías: división, conocimiento y abstracción. Los desarrolladores dividen un
problema para que sus partes sean más pequeñas y manejables, aplican el conocimiento de problemas
similares y usan abstracciones para ayudarlos a razonar. La partición, el conocimiento y la abstracción
son efectivos porque permiten que nuestras mentes de tamaño fijo comprendan un problema cada vez
mayor.
• Partición. La partición es eficaz como estrategia para combatir la complejidad y la escala cuando
se cumplen dos condiciones: primero, las partes divididas deben ser lo suficientemente pequeñas
como para que una persona pueda resolverlas ahora; segundo, debe ser posible razonar acerca
de cómo las partes se ensamblan en un todo. Las partes que están encapsuladas son más fáciles
de razonar, porque necesita rastrear menos detalles al componer las partes en una solución.
Puedes olvidarte, al menos temporalmente, de los detalles dentro de las otras partes. Esto le
permite al desarrollador razonar más fácilmente sobre cómo las partes interactuarán entre sí.
• Conocimiento. Los desarrolladores de software usan el conocimiento de problemas anteriores para

ayudarlos a resolver los actuales. Este conocimiento puede ser un saber hacer implícito o estar
escrito explícitamente. Puede ser específico, como qué componentes funcionan bien con otros, o
general, como las técnicas para optimizar el diseño de una tabla de base de datos. Viene en
muchas formas, incluidos libros, conferencias, descripciones de patrones, código fuente,
documentos de diseño o bocetos en una pizarra.
1Mary Shaw ha señalado que al dividir y conquistar, dividir es la parte fácil.

1.2. TRES EJEMPLOS DE ARQUITECTURA DE SOFTWARE 3
• Abstracción. La abstracción puede combatir eficazmente la complejidad y la escala porque reduce

los problemas, y los problemas más pequeños son más fáciles de razonar. Si conduce de Nueva
York a Los Ángeles, puede simplificar el problema de navegación considerando solo las autopistas.
Al ocultar detalles (excluyendo la opción de conducir a través de campos o estacionamientos), ha
reducido la cantidad de opciones a considerar, lo que hace que el problema sea más fácil de razonar.
No debe esperar ninguna bala de plata, como las llamó Fred Brooks, que eliminará repentinamente las
dificultades del desarrollo de software (Brooks, 1995). En cambio, debe buscar armas que lo ayuden a
particionar mejor los sistemas, brinden conocimiento y permitan la abstracción para revelar la esencia del
problema.
La arquitectura de software es una de esas armas y puede ayudarlo a abordar la complejidad y la
escala de los sistemas de software. Le ayuda a particionar el software, proporciona conocimientos que le
ayudan a diseñar un mejor software y proporciona abstracciones que le ayudan a razonar sobre el
software. Es una herramienta en manos de un desarrollador experto. Ayuda a los desarrolladores de
software a construir rutinariamente sistemas que antes requerían virtuosos (Shaw y Garlan, 1996), pero
no elimina la necesidad de desarrolladores de software capacitados. En lugar de eliminar la necesidad de
ingenio, permite a los desarrolladores aplicar su ingenio para construir sistemas más grandes y complejos.
1.2 Tres ejemplos de arquitectura de software
Eso es lo que la arquitectura de software hace por ti, pero ¿qué es ? En términos generales, la arquitectura
es el diseño macroscópico de un sistema de software. El Capítulo 2 de este libro analiza una definición
más cuidadosa, pero tal vez sea mejor entender la arquitectura de software utilizando primero algunos
ejemplos concretos.
Puede ser difícil "ver el bosque por los árboles", lo que en este caso significa encontrar la arquitectura
en medio de los detalles del diseño. Pero al comparar múltiples sistemas similares con diferentes
arquitecturas, debería poder notar qué es diferente y, por lo tanto, identificar sus arquitecturas. Lo que
sigue es una descripción de tres sistemas con la misma funcionalidad, pero arquitecturas diferentes, según
las experiencias en Rackspace.
Rackspace es una empresa real que administra servidores de correo electrónico alojados. Los clientes
piden ayuda cuando experimentan problemas. Para ayudar a un cliente, Rackspace debe buscar en los
archivos de registro que registran lo que sucedió durante el procesamiento del correo electrónico del cliente.
Debido a que el volumen de correos electrónicos que manejan siguió aumentando, Rackspace creó tres
generaciones de sistemas para manejar las consultas de los clientes (Hoff, 2008b; Hood, 2008).
Versión 1: archivos de registro locales. La primera versión del programa era simple. Ya había docenas
de servidores de correo electrónico generando archivos de registro. Rackspace escribió un guión que
usaría ssh para conectarse a cada máquina y ejecutar una consulta grep en el archivo de registro de correo. Los
ingenieros podían controlar los resultados de la búsqueda ajustando la consulta grep.
Esta versión inicialmente funcionó bien, pero con el tiempo la cantidad de búsquedas aumentó y la sobrecarga de
ejecutar esas búsquedas en los servidores de correo electrónico se hizo evidente.
Además, se requería un ingeniero, en lugar de un técnico de soporte, para realizar la búsqueda.
Versión 2: Base de datos central. La segunda versión abordó los inconvenientes de la primera al sacar los datos de
registro de los servidores de correo electrónico y permitir que los técnicos de soporte puedan buscarlos. Cada pocos
minutos, cada servidor de correo electrónico enviaba sus datos de registro recientes a una máquina central donde se
cargaba en una base de datos relacional. Los técnicos de soporte tenían acceso a los datos de la base de datos a
través de una interfaz basada en la web.
Rackspace ahora manejaba cientos de servidores de correo electrónico, por lo que el volumen de datos de registro
había aumentado en consecuencia. El desafío de Rackspace se convirtió en cómo obtener los datos de registro en la
base de datos de la manera más rápida y eficiente posible. La empresa se decidió por la inserción masiva de registros
en las tablas de combinación, lo que permitió cargar los datos en dos o tres minutos. Solo se mantuvieron tres días de
registros para que el tamaño de la base de datos no afectara el rendimiento.
Con el tiempo, este sistema también encontró problemas. El servidor de la base de datos era una sola máquina
y, debido a la carga constante de datos y el volumen de consultas, estaba al límite con cargas pesadas de CPU y
disco. Las búsquedas con comodines estaban prohibidas debido a la carga adicional que ponían en el servidor. A
medida que crecía la cantidad de datos de registro, las búsquedas se volvían más lentas. El servidor experimentó
fallas aparentemente aleatorias que se volvieron cada vez más frecuentes. Todos los datos de registro que se
descartaron desaparecieron para siempre porque no se realizó una copia de seguridad. Estos problemas llevaron a
una pérdida de confianza en el sistema.
Versión 3: Clúster de indexación. La tercera versión abordó los inconvenientes de la segunda guardando los datos
de registro en un sistema de archivos distribuido y paralelizando la indexación de los datos de registro. En lugar de
ejecutarse en una sola máquina potente, utilizó diez máquinas básicas. Los datos de registro de los servidores de
correo electrónico se transmitieron al sistema de archivos distribuidos de Hadoop, que mantuvo tres copias de todo en
diferentes discos. En 2008, cuando Rackspace escribió un informe sobre sus experiencias, tenía más de seis terabytes
de datos que abarcaban treinta unidades de disco, lo que representaba seis meses de índices de búsqueda.
La indexación se realizó con Hadoop, que divide los datos de entrada, los indexa (o "mapa") en trabajos y luego
combina (o "reduce") los resultados parciales en un índice completo. Los trabajos se ejecutaban cada diez minutos y
tardaban unos cinco minutos en completarse, por lo que los resultados del índice estaban obsoletos durante unos
quince minutos. Rackspace pudo indexar más de 140 gigabytes de datos de registro por día y ejecutó más de 150 000
trabajos desde que inició el sistema.
Al igual que en el segundo sistema, los técnicos de soporte tenían acceso a través de una interfaz web que se
parecía mucho a la interfaz de un motor de búsqueda web. Los resultados de la consulta se proporcionaron en segundos.
1.3. REFLEJOS 5
Cuando los ingenieros pensaron en nuevas preguntas sobre los datos, pudieron escribir un nuevo tipo de
trabajo y obtener su respuesta en unas pocas horas.
1.3 Reflexiones
Lo primero que debe notar al observar estos tres sistemas es que todos tienen aproximadamente la
misma funcionalidad (consultar registros de correo electrónico para diagnosticar problemas), pero tienen
arquitecturas diferentes. Su arquitectura fue una elección separada de su funcionalidad. Esto significa
que cuando construye un sistema, puede elegir la arquitectura que mejor se adapte a sus necesidades y
luego construir la funcionalidad sobre ese esqueleto arquitectónico.
¿Qué más pueden revelar estos sistemas sobre la arquitectura del software?
Atributos de calidad. A pesar de tener la misma funcionalidad, los tres sistemas difieren en su
modificabilidad, escalabilidad y latencia. Por ejemplo, en la primera y segunda versión, se podían crear
consultas ad hoc en cuestión de segundos, ya sea cambiando la expresión grep utilizada para la búsqueda
o cambiando la consulta SQL. El tercer sistema requiere que se escriba y programe un nuevo programa
antes de que se puedan obtener los resultados de la consulta. Los tres admiten la creación de nuevas
consultas, pero difieren en lo fácil que es hacerlo (modificabilidad).
Nótese también que no había almuerzo gratis: promover una cualidad inhibía otra.
El tercer sistema era mucho más escalable que los otros dos, pero su escalabilidad tenía el precio de una
capacidad reducida para realizar consultas ad hoc y una espera más larga antes de que los resultados
estuvieran disponibles. Los datos en el primer sistema se podían consultar en línea (y el segundo tal vez
podría hacerse casi), pero el tercer sistema tenía que recopilar datos y luego ejecutar un proceso por
lotes para indexar los resultados, lo que significa que los resultados de la consulta estaban un poco obsoletos.
Si alguna vez se encuentra en una situación en la que puede obtener una gran escalabilidad,
latencia, capacidad de modificación, etc., entonces debe considerarse afortunado, porque tales atributos
de calidad generalmente se compensan entre sí. Maximizar un atributo de calidad significa conformarse
con menos de los otros. Por ejemplo, elegir un diseño más modificable puede conllevar una peor latencia.
Modelo conceptual. Incluso sin ser un experto en arquitectura de software, podría leer acerca de estos
tres sistemas y razonar sobre su diseño desde los primeros principios.
¿Qué ventaja tendría ser un experto en arquitectura de software (es decir, ser un entrenador en lugar de
un novato)? Tanto los entrenadores como los novatos tienen una capacidad innata para razonar, pero el
entrenador tiene una ventaja inicial debido al modelo conceptual que lleva en la cabeza que lo ayuda a
dar sentido a lo que ve.
Como experto en arquitectura, estará preparado para notar las diferencias de partición en cada
sistema. Se distinguiría entre fragmentos de código (módulos), fragmentos de tiempo de ejecución
(componentes) y fragmentos de hardware (nodos o elementos ambientales). Notarías y ya sabrías los
nombres de los patrones arquitectónicos.
emplea cada sistema. Sabría qué patrón es adecuado para lograr qué
atributos de calidad, por lo que habría predicho que el sistema cliente-servidor
tienen una latencia más baja que el sistema map-reduce. Clasificaría y relacionaría los hechos principales, las
opciones de diseño y los detalles de implementación, y se daría cuenta cuando alguien
otra persona los ha mezclado. Ser un experto en arquitectura de software te ayuda
para usar sus habilidades innatas de razonamiento de manera más efectiva.
Abstracciones y restricciones. En el software, las cosas más grandes generalmente se construyen a partir de
cosas más pequeñas Siempre puedes razonar sobre las cosas más pequeñas en un sistema (como
líneas individuales de código), pero por lo general le resultará más eficiente razonar sobre el
cosas más grandes (como clientes y servidores). Por ejemplo, el tercer sistema en Rackspace
ejemplos de trabajos programados y datos almacenados en un sistema de archivos distribuido. si lo necesitaras
para resolver un problema sobre cómo fluyen los trabajos a través de ese sistema, entonces sería más
eficiente para razonar sobre el problema a ese nivel. Podrías comenzar tu razonamiento
proceso considerando los bits pequeños, como objetos y llamadas a procedimientos, pero eso sería
ser ineficiente y probablemente lo inundará con detalles.
Además, un “trabajo” es una abstracción que obedece a más restricciones que un “trozo de código”
arbitrario. Los desarrolladores impusieron esas restricciones para hacer
razonar sobre el sistema es más fácil. Por ejemplo, si restringen los trabajos para que no tengan
efectos, pueden ejecutar el mismo trabajo dos veces, en paralelo, en caso de que uno se atasque
abajo. Es difícil razonar sobre un fragmento arbitrario de código específicamente porque
no puede decir lo que no hace. Los desarrolladores imponen voluntariamente restricciones a la
sistema para ampliar sus habilidades de razonamiento.
1.4 Cambio de perspectiva
En 1968, Edsger Dijkstra escribió una carta ahora famosa titulada "GOTO considerado dañino".
abogando por el uso de la programación estructurada. Su argumento es más o menos el siguiente:
Los desarrolladores construyen programas que contienen sentencias estáticas que se ejecutan para producir
resultados. Los desarrolladores, siendo humanos, tienen dificultades para imaginar cómo se ejecutarán las
declaraciones estáticas de un programa en tiempo de ejecución. Las declaraciones GOTO complican el
razonamiento sobre la ejecución en tiempo de ejecución, por lo que es mejor evitar las declaraciones GOTO y adoptar
programación estructurada.
Mirando hacia atrás en este debate de hoy, es difícil imaginar estar en total desacuerdo, pero
en ese momento la resistencia era sustancial. Los desarrolladores estaban acostumbrados a trabajar
dentro del antiguo conjunto de abstracciones. Se centraron en las limitaciones de las nuevas abstracciones en
lugar de los beneficios y se opusieron basándose en casos de esquina que eran difíciles.
expresar usando programación estructurada. A cada aumento similar en la abstracción se oponen algunos que
están familiarizados con las antiguas abstracciones. Durante mi programación
En mi carrera, he visto a los desarrolladores resistirse a los tipos de datos abstractos y la programación
orientada a objetos, solo para adoptarlos más tarde.
1.5. ARQUITECTOS ARQUITECTURAS ARQUITECTURAS 7
Las abstracciones de la nueva arquitectura rara vez reemplazan a las antiguas, sino que coexisten con
ellas. El uso de abstracciones como componentes y conectores no significa que los objetos, métodos y
estructuras de datos desaparezcan. Del mismo modo, los bomberos forestales alternan entre pensar en
árboles individuales o en bosques completos según la parte de su trabajo que estén haciendo en ese
momento.
La aplicación efectiva de ideas de arquitectura de software requiere un cambio consciente y explícito
para adoptar sus abstracciones, como componentes y conectores, en lugar de usar solo las abstracciones
que se encuentran en el lenguaje de programación convencional (a menudo solo clases u objetos). Si no
elige conscientemente la arquitectura de sus sistemas, entonces puede terminar siendo lo que Brian Foote y
Joseph Yoder llaman una gran bola de barro (Foote y Yoder, 2000), que estiman que es la arquitectura de
software más común. Es fácil entender esta arquitectura: imagine cómo se vería un sistema con 10 clases,
luego amplíelo a 100, 1000, ..., sin nuevas abstracciones o particiones, y deje que los objetos en el sistema
se comuniquen entre sí. como es conveniente.
1.5 Arquitectos construyendo arquitecturas
A veces he visto a desarrolladores de software diseñar sistemas con bellas arquitecturas y luego expresar
su resistencia a la arquitectura de software. Esta resistencia puede deberse a la resistencia a los procesos
de diseño inicial que requieren mucha burocracia, a los arquitectos pomposos o a haberse visto obligado a
perder el tiempo haciendo diagramas en lugar de sistemas.
Afortunadamente, ninguno de estos problemas necesita ser parte de la creación de arquitectura de software.
tura
Los títulos de trabajo, los procesos de desarrollo y los artefactos de ingeniería son separables, por lo que
es importante evitar confundir el título de trabajo "arquitecto", el proceso de arquitectura de un sistema y el
artefacto de ingeniería que es la arquitectura de software.
• El puesto de trabajo: arquitecto. Un posible título de trabajo (o función) en una organización es el de

arquitecto de software. Algunos arquitectos se sientan en oficinas de esquina y hacen declaraciones
que están desconectadas de la realidad de la ingeniería, mientras que otros arquitectos están
íntimamente involucrados en la construcción continua del software.
De cualquier manera, el título y la oficina no son intrínsecos al trabajo de diseño o construcción de
software. Todos los desarrolladores de software, no solo los arquitectos, deben comprender la
arquitectura de su software.
• El proceso: la arquitectura. No hay software al comienzo de un proyecto, pero al final del proyecto
hay un sistema en ejecución. En el medio, el equipo realiza actividades (es decir, siguen un proceso)
para construir el sistema. Algunos equipos diseñan por adelantado y otros equipos diseñan mientras
construyen. El proceso que sigue el equipo es separable del diseño que emerge. Un equipo podría
seguir cualquier cantidad de procesos diferentes y producir, por ejemplo, un sistema de 3 niveles. O
dicho de otra manera, es casi imposible saber qué proceso de arquitectura siguió un equipo
mirando solo el software terminado.
• El artefacto de ingeniería: la arquitectura. Si observa un automóvil, puede decir qué tipo

de automóvil es, tal vez un automóvil totalmente eléctrico, un automóvil híbrido o un
automóvil de combustión interna. Esa característica del automóvil es distinta del proceso
seguido para diseñarlo y distinta de los títulos de trabajo utilizados por sus diseñadores.
El diseño del coche es un artefacto de ingeniería. Las diferentes opciones sobre el proceso
y los títulos de los trabajos aún podrían resultar en la creación de, por ejemplo, un automóvil
híbrido. El software es similar. Si observa un sistema de software terminado, puede distinguir
varios diseños; por ejemplo: colaboración de nodos de igual a igual en una red de voz sobre
IP, múltiples niveles en sistemas de tecnología de la información (TI) o nodos de cómputo
de reducción de mapas paralelos en sistemas de Internet. Cada sistema de software tiene
una arquitectura al igual que cada automóvil tiene un diseño. Algunos programas se
improvisan sin un proceso regular, pero su arquitectura sigue siendo visible.
Este libro analiza el proceso en el Capítulo 2 y el Capítulo 3. El resto del libro trata la arquitectura
como un artefacto de ingeniería: algo que debe analizarse, comprenderse y diseñarse para poder
construir mejores sistemas.
1.6 Arquitectura de software impulsada por el riesgo
Diferentes desarrolladores han tenido éxito con diferentes procesos. Algunos tuvieron éxito con
procesos ágiles que tienen poco o ningún trabajo inicial. Otros tuvieron éxito con un trabajo de
diseño inicial detallado. ¿Cuál deberías elegir? Idealmente, tendría un principio rector que lo
ayudaría a elegir adecuadamente.
Este libro sugiere usar el riesgo para decidir cuánto trabajo de arquitectura hacer. Una forma
de entender cómo el riesgo puede guiarlo a tomar buenas decisiones sobre arquitectura es
considerar la historia de mi padre instalando un buzón.
Mi padre tiene dos títulos en ingeniería mecánica, pero cuando puso un buzón lo hizo como
cualquier otro: cavó un hoyo, puso el poste y lo tapó con un poco de cemento. El hecho de que
pudiera calcular momentos, tensiones y deformaciones no significa que deba o deba hacerlo. En
otras situaciones, sería una tontería que se saltara estos análisis. ¿Cómo sabía cuándo usarlos?
La arquitectura de software es una tecnología relativamente nueva e incluye muchas técnicas

para modelar y analizar sistemas. Sin embargo, cada una de estas técnicas requiere tiempo que,
de otro modo, podría dedicarse a construir el sistema. Este libro presenta el modelo basado en el
riesgo para la arquitectura de software, que lo guía para hacer suficiente arquitectura seleccionando
las técnicas de arquitectura apropiadas y sabiendo cuándo puede detenerse.
1.7. ARQUITECTURA PARA DESARROLLADORES ÁGILES 9
Su esfuerzo debe ser proporcional a su riesgo de fracaso. Quizás su sistema tenga requisitos de
escalabilidad exigentes porque ejecuta un servicio web popular. Sería mejor asegurarse de que su sistema
manejará la cantidad esperada de usuarios2 antes de invertir demasiada energía en su diseño (o el sitio
se activa). Si la modificabilidad es una preocupación menor para su sistema (o usabilidad, etc.), dedicaría
poco tiempo a preocuparse por ese riesgo.
Cada proyecto enfrenta diferentes riesgos, por lo que no existe una única forma correcta de hacer
arquitectura de software: debe evaluar los riesgos en cada proyecto. A veces, la respuesta es no hacer
ningún trabajo de arquitectura, porque algunos proyectos tienen tantos precedentes que casi no hay riesgo
siempre que se reutilice una arquitectura probada. Sin embargo, cuando trabaje en dominios novedosos o
lleve un sistema existente a un territorio desconocido, querrá tener más cuidado.
La idea de trabajar constantemente para reducir los riesgos de ingeniería se hace eco del modelo
espiral de desarrollo de software de Barry Boehm (Boehm, 1988). El modelo en espiral es un proceso
completo de desarrollo de software que guía los proyectos para trabajar primero en los elementos de mayor riesgo.
Los proyectos enfrentan riesgos tanto de gestión como de ingeniería, por lo que los gerentes deben
priorizar tanto los riesgos de gestión (como el riesgo de rechazo del cliente) como los riesgos de ingeniería
(como el riesgo de que el sistema sea inseguro o ineficiente).
En comparación con el modelo en espiral, el modelo basado en el riesgo lo ayuda a responder
preguntas más específicas: ¿Cuánto trabajo de arquitectura debe hacer y qué tipo de técnicas de
arquitectura debe usar? Debido a que el modelo basado en riesgos solo se aplica al trabajo de diseño,
significa que se puede aplicar a procesos ágiles, procesos en cascada, procesos en espiral, etc.
Independientemente del proceso, debe diseñar el software: la diferencia es cuándo ocurre el diseño y qué
técnicas se aplican.
1.7 Arquitectura para desarrolladores ágiles
El desarrollo ágil de software es una reacción a los procesos de desarrollo pesados y enfatiza la creación
eficiente de productos que los clientes desean (Beck et al., 2001).
Es cada vez más popular, con un estudio que muestra que el 69% de las empresas lo prueban en al menos
algunos de sus proyectos (Ambler, 2008).
En su deseo de eliminar pasos innecesarios en el desarrollo de software, algunos desarrolladores
ágiles creen que deberían evitar las técnicas de arquitectura de software. Esta renuencia no es universal,
ya que muchas voces importantes en la comunidad ágil apoyan algún trabajo de diseño planificado,
incluidos Martin Fowler, Robert Martin, Scott Ambler y Granville Miller (Fowler, 2004; Martin, 2009; Ambler,
2002; Miller, 2006) . La refactorización de una mala elección de arquitectura puede ser prohibitivamente
costosa en sistemas grandes. Esta
2Recuerde que antes de los populares sitios de redes sociales Facebook y MySpace existía Friendster, pero no pudo
manejar la avalancha de usuarios y se volvió demasiado lento de usar.
El libro puede ayudar a los desarrolladores ágiles a usar la arquitectura de software de una manera que sea
consistente con los principios ágiles por dos razones principales:
• Arquitectura suficiente. El modelo de arquitectura basado en el riesgo guía a los desarrolladores para
que hagan la arquitectura suficiente y luego reanuden la codificación. Si solo prevé riesgos en su proyecto
que pueden manejarse mediante la refactorización, entonces no haría ningún diseño de arquitectura.
Pero si es un agilista al que también le preocupa que la refactorización no sea suficiente para obtener la
seguridad o la escalabilidad que necesita, ahora tiene una manera de mitigar esos riesgos, incluso en su
enésima iteración, luego vuelva a codificar.
• Modelo conceptual. La principal contribución de Agile es el proceso de desarrollo de software, no las

abstracciones de diseño, y ofrece un número limitado de técnicas (como la refactorización y los picos)
para producir buenos diseños. El contenido de este libro aumenta los procesos ágiles al proporcionar un
modelo conceptual para razonar sobre la arquitectura y el diseño de un sistema, un conjunto de técnicas
de modelado y diseño de software, y conocimientos expertos en arquitectura de software.
Este no es un libro específicamente sobre la arquitectura de software ágil, pero encontrará que su enfoque
basado en el riesgo se adapta bien a los proyectos ágiles. En particular, la Sección 3.11 proporciona un esquema
de cómo integrar los riesgos en un proceso iterativo centrado en características.
1.8 Acerca de este libro
Este libro se centra en la arquitectura del software en lo que se refiere a la construcción de software y describe
las técnicas utilizadas para garantizar que el software satisfaga sus demandas de ingeniería. Este libro es en
gran medida agnóstico del proceso porque las técnicas de ingeniería en sí mismas son en gran medida
independientes del proceso. No encontrará consejos sobre actividades de gestión como las responsabilidades
políticas de los arquitectos, cuándo celebrar tipos específicos de reuniones o cómo reunir los requisitos de las
partes interesadas.
Este libro está dividido en dos partes. Esta primera parte presenta la arquitectura del software y el enfoque
basado en el riesgo. La segunda parte lo ayuda a construir un modelo conceptual mental de arquitectura de
software y describe en detalle las abstracciones como componentes y conectores. Lo que sigue son breves
resúmenes de cada parte.
Parte I: Arquitectura de software impulsada por el riesgo
Una definición de arquitectura de software es difícil de precisar con precisión, pero varias cosas al respecto son
bastante claras. Los desarrolladores de software, al igual que los ingenieros en otras áreas especiales, utilizan
la abstracción y los modelos para resolver problemas grandes y complejos. La arquitectura de software actúa
como el esqueleto de un sistema, influye en los atributos de calidad, es ortogonal a la funcionalidad y utiliza
restricciones para influir en las propiedades de un sistema. Arquitectura
1.8. SOBRE ESTE LIBRO 11
es más importante cuando el espacio de la solución es pequeño, los riesgos de falla son altos o enfrenta
demandas difíciles de atributos de calidad. Puede elegir entre un diseño indiferente a la arquitectura, un
diseño centrado en la arquitectura o incluso una elevación de la arquitectura.
Los riesgos se pueden usar para guiarlo con respecto a qué técnicas de diseño y arquitectura debe
usar y cuánto diseño y arquitectura debe hacer. En esencia, el modelo basado en el riesgo es simple: (1)
identificar y priorizar los riesgos, (2) seleccionar y aplicar un conjunto de técnicas y (3) evaluar la reducción
del riesgo.
Para revelar el modelo basado en el riesgo en la práctica, el Capítulo 4 proporciona un ejemplo de
aplicación del modelo basado en el riesgo a un sistema Home Media Player. Los desarrolladores de ese
sistema enfrentan los desafíos de la comunicación en equipo, la integración de los componentes COTS y
la garantía de la consistencia de los metadatos.
La primera parte del libro concluye con consejos sobre el uso de modelos y arquitectura de software,
que incluyen: usar modelos para resolver problemas, agregar restricciones de manera juiciosa, enfocarse
en los riesgos y distribuir las habilidades de arquitectura en todo su equipo.
Parte II: Modelado de arquitectura

La segunda parte del libro lo ayuda a construir un modelo conceptual mental de arquitectura de software.
Comienza con la estructura del modelo canónico: el modelo de dominio, el modelo de diseño y el modelo
de código. El modelo de dominio corresponde a cosas del mundo real, el modelo de diseño es el diseño
del software que está creando y el modelo de código corresponde a su código fuente. Puede crear
modelos adicionales que muestren detalles seleccionados, denominados vistas, y estas vistas se pueden
agrupar en tipos de vista.
Construir límites de encapsulación es una habilidad crucial en la arquitectura de software. Los usuarios
de un componente o módulo a menudo pueden ignorar cómo funciona internamente, liberando sus mentes
para resolver otros problemas difíciles. Y los constructores de un módulo o componente encapsulado
tienen la libertad de cambiar su implementación sin perturbar a sus usuarios. Los constructores solo
tendrán esa libertad si la encapsulación es efectiva, por lo que este libro le enseñará técnicas para
garantizar que sea efectiva.
A lo largo de los años se ha construido un gran número de abstracciones arquitectónicas y técnicas
de modelado. Este libro consolida las técnicas de arquitectura de software que se encuentran en una
variedad de otras fuentes, integrando técnicas que enfatizan los atributos de calidad, así como técnicas
que enfatizan la funcionalidad. También analiza formas pragmáticas de construir modelos efectivos y
depurarlos.
La segunda parte del libro concluye con consejos sobre cómo usar los modelos de manera efectiva.
No se debe confiar en cualquier libro que cubra las ventajas pero no las trampas de una tecnología, por lo
que también cubre los problemas que es probable que encuentre.
Al final de la segunda parte, debería haber construido un rico modelo conceptual de abstracciones y
relaciones que lo ayudará a ver los sistemas de software de la forma en que un entrenador
ve un juego.
Capítulo 3
Modelo impulsado por el riesgo
A medida que construyen software exitoso, los desarrolladores de software eligen entre alternativas
diseños, desechando aquellos que están condenados al fracaso y prefiriendo opciones con bajo
riesgo de fracaso. Cuando los riesgos son bajos, es fácil seguir adelante sin pensar mucho,
pero, invariablemente, surgen problemas de diseño desafiantes y los desarrolladores deben lidiar
con diseños de alto riesgo, que no están seguros de que funcionen.
Construir software exitoso significa anticipar posibles fallas y evitar diseños que puedan fallar. Henry
Petroski, un destacado historiador de la ingeniería, dice esto
sobre la ingeniería en su conjunto:
El concepto de fracaso es fundamental para el proceso de diseño, y es pensando en

términos de obviar el fracaso que se logran diseños exitosos. ...
Aunque a menudo es una parte implícita y tácita de la metodología de diseño, las
consideraciones de fallas y el análisis proactivo de fallas son esenciales para lograr
éxito. Y es precisamente cuando tales consideraciones y análisis son correctos o
incompletos que se introducen errores de diseño y fallas reales.
ocurrir. (Petroski, 1994)
Para abordar los riesgos de falla, los primeros desarrolladores de software inventaron técnicas de diseño,
como modelado de dominio, análisis de seguridad y encapsulación, que les ayudó
construir software exitoso. Hoy en día, los desarrolladores pueden elegir entre una gran cantidad de
técnicas de diseño. De esta abundancia surge una pregunta difícil: ¿Qué diseño y
¿Qué técnicas de arquitectura deberían usar los desarrolladores?
Si no hubiera plazos, la respuesta sería fácil: utilizar todas las técnicas.
Pero eso no es práctico porque un sello distintivo de la ingeniería es el uso eficiente de los recursos.
36 CAPÍTULO 3. MODELO IMPULSADO POR EL RIESGO
fuentes, incluido el tiempo. Uno de los riesgos a los que se enfrentan los desarrolladores es que pierden
demasiado tiempo diseñando. Entonces surge una pregunta relacionada: ¿Cuánto diseño y arquitectura deben
hacer los desarrolladores?
Hay mucho debate activo sobre esta pregunta y se han sugerido varios tipos de respuestas:
• Sin diseño inicial. Los desarrolladores deberían simplemente escribir código. El diseño sucede, pero
coincide con la codificación y sucede en el teclado en lugar de por adelantado.
• Utilice una vara de medir. Por ejemplo, los desarrolladores deberían dedicar el 10 % de su tiempo a la
arquitectura y el diseño, el 40 % a la codificación, el 20 % a la integración y el 30 % a las pruebas.
• Cree un paquete de documentación. Los desarrolladores deben emplear un conjunto integral de técnicas
de diseño y documentación suficientes para producir un documento de diseño escrito completo.
• Ad hoc. Los desarrolladores deben reaccionar a las necesidades del proyecto y decidir en el acto cuánto
diseño hacer.
El enfoque ad hoc es quizás el más común, pero también es subjetivo y no brinda lecciones duraderas. Evitar
el diseño por completo no es práctico cuando los riesgos de falla son altos, pero tampoco lo es crear un paquete
completo de documentación cuando los riesgos son bajos. El uso de un criterio puede ayudarlo a planificar
cuánto esfuerzo requerirá el diseño de la arquitectura, pero no lo ayuda a elegir las técnicas.
Este capítulo presenta el modelo de diseño arquitectónico basado en el riesgo . Su idea esencial es que el
esfuerzo que gaste en diseñar su arquitectura de software debe ser proporcional a los riesgos que enfrenta su
proyecto. Cuando mi padre instaló un buzón nuevo, no aplicó todas las técnicas de diseño y análisis de ingeniería
mecánica que conocía. En cambio, cavó un hoyo, colocó un poste y llenó el hoyo con concreto.
El modelo basado en el riesgo puede ayudarlo a decidir cuándo aplicar técnicas de arquitectura y cuándo puede
omitirlas.
Mientras que un proceso de desarrollo de software orquesta cada actividad, desde los requisitos hasta la
implementación, el modelo basado en el riesgo guía solo el diseño arquitectónico y, por lo tanto, puede usarse
dentro de cualquier proceso de desarrollo de software.
El modelo basado en el riesgo es una reacción a un mundo en el que los desarrolladores están bajo presión
para crear software de alta calidad rápidamente y a un costo razonable, pero esos desarrolladores tienen más
técnicas de arquitectura de las que pueden permitirse aplicar. El modelo basado en el riesgo les ayuda a
responder las dos preguntas anteriores: ¿cuánto trabajo de arquitectura de software deberían hacer y qué
técnicas deberían usar? Es un enfoque que ayuda a los desarrolladores a seguir un camino intermedio, uno que
evita perder tiempo en técnicas que solo ayudan un poco a sus proyectos, pero asegura que los riesgos que
amenazan el proyecto se aborden con técnicas apropiadas.
3.1. ¿QUÉ ES EL MODELO DIRIGIDO AL RIESGO? 37
En este capítulo, examinaremos cómo la reducción de riesgos es fundamental para todos los proyectos de ingeniería.
disciplinas, aprenda a elegir técnicas para reducir los riesgos, comprenda cómo los riesgos de ingeniería
interactúan con los riesgos de gestión y aprenda cómo podemos equilibrar los riesgos planificados.
diseño con diseño evolutivo. Este capítulo recorre las ideas que sustentan
el modelo basado en el riesgo, pero si usted es el tipo de persona que preferiría ver primero
un ejemplo de su uso, puede pasar al Capítulo 4.
3.1 ¿Qué es el modelo orientado al riesgo?
El modelo basado en el riesgo guía a los desarrolladores a aplicar un conjunto mínimo de técnicas de
arquitectura para reducir sus riesgos más apremiantes. Sugiere un proceso de cuestionamiento implacable:
“¿Cuáles son mis riesgos? ¿Cuáles son las mejores técnicas para reducirlas? ¿Se mitiga el riesgo y puedo
comenzar (o reanudar) la codificación? El modelo basado en el riesgo se puede resumir
en tres pasos:
1. Identificar y priorizar riesgos
2. Seleccionar y aplicar un conjunto de técnicas
3. Evaluar la reducción de riesgos
No querrás perder el tiempo en técnicas de bajo impacto, ni tampoco querrás ignorar

riesgos que amenazan el proyecto. Quiere construir sistemas exitosos tomando un camino que
pasa su tiempo de la manera más efectiva. Eso significa abordar los riesgos aplicando técnicas de arquitectura
y diseño, pero solo cuando están motivados por los riesgos.
Enfoque de riesgo o característica. El elemento clave del modelo basado en el riesgo es la promoción
de riesgo a la prominencia. Lo que eliges promover tiene un impacto. La mayoría de los desarrolladores ya
piensan en los riesgos, pero también piensan en muchas otras cosas y
en consecuencia, los riesgos pueden pasarse por alto. Un artículo reciente describe cómo un equipo que
anteriormente había realizado un trabajo de arquitectura inicial, cambió a un trabajo puramente basado en características
proceso. El equipo estaba tan centrado en ofrecer funciones que pospusieron la calidad
preocupaciones sobre los atributos hasta después de que cesó el desarrollo activo y el sistema estuvo en
mantenimiento (Babar, 2009). La conclusión a sacar es que los equipos que se enfocan en características
prestará menos atención a otras áreas, incluidos los riesgos. Estudios anteriores han demostrado que
incluso los arquitectos se centran menos en los riesgos y las compensaciones de lo que cabría esperar (Clerc,
Lago y van Vliet, 2007).
Justificación lógica. Pero, ¿y si su percepción de los riesgos difiere de la percepción de los demás?
Identificación de riesgos, priorización de riesgos, elección de técnicas y evaluación de
la mitigación de riesgos variará dependiendo de quién los haga. ¿El modelo basado en el riesgo es
mera improvisación?
No. Aunque diferentes desarrolladores percibirán los riesgos de manera diferente y, en consecuencia, elegirán
diferentes técnicas, el modelo basado en el riesgo tiene la propiedad útil de que produce argumentos que pueden
evaluarse. Un argumento de ejemplo tomaría esta forma:
Identificamos A, B y C como riesgos, siendo B el principal. Dedicamos tiempo a aplicar las técnicas
X e Y porque creíamos que nos ayudarían a reducir el riesgo de B. Evaluamos el diseño resultante y
decidimos que habíamos mitigado suficientemente el riesgo de B, por lo que procedimos a la
codificación.
Esto le permite responder a la amplia pregunta: "¿Cuánta arquitectura de software debe hacer?" proporcionando un
plan (es decir, las técnicas a aplicar) basado en el contexto relevante (es decir, los riesgos percibidos).
Otros desarrolladores podrían no estar de acuerdo con su evaluación, por lo que podrían proporcionar un
argumento diferente con la misma forma, tal vez sugiriendo que se incluya el riesgo D.
Puede surgir una discusión productiva basada en la ingeniería de los riesgos y las técnicas porque la lógica detrás
de su opinión ha sido articulada y puede evaluarse.
3.2 ¿Está impulsado por el riesgo ahora?
Muchos desarrolladores creen que ya siguen un modelo basado en el riesgo, o algo parecido. Sin embargo, hay
señales reveladoras de que muchos no lo hacen. Uno es la incapacidad de enumerar los riesgos a los que se
enfrentan y las técnicas correspondientes que están aplicando.
Cualquier desarrollador puede responder a la pregunta "¿En qué funciones está trabajando?" pero muchos
tienen problemas con la pregunta: "¿Cuáles son sus principales riesgos de falla y las técnicas de ingeniería
correspondientes?" Si los riesgos fueran realmente primarios, les resultaría una pregunta fácil de responder.
Las opciones de técnica deben variar. Los proyectos enfrentan diferentes riesgos por lo que deben utilizar
diferentes técnicas. Algunos proyectos tendrán requisitos complicados de atributos de calidad que necesitan un
diseño planificado por adelantado, mientras que otros proyectos son ajustes a los sistemas existentes y conllevan
poco riesgo de falla. Algunos equipos de desarrollo están distribuidos y, por lo tanto, documentan sus diseños para
que otros los lean, mientras que otros equipos están ubicados en el mismo lugar y pueden reducir esta formalidad.
Cuando los desarrolladores no logran alinear sus actividades de arquitectura con sus riesgos, sobreutilizarán o
infrautilizarán las técnicas arquitectónicas, o ambas cosas. Examinar el contexto general del desarrollo de software
sugiere por qué puede ocurrir esto. La mayoría de las organizaciones guían a los desarrolladores para que sigan un
proceso que incluye algún tipo de plantilla de documentación o una lista de actividades de diseño. Estos pueden ser
beneficiosos y efectivos, pero también pueden desviar inadvertidamente a los desarrolladores.
Estos son algunos ejemplos de reglas bien intencionadas que guían a los desarrolladores a realizar actividades.
vínculos que pueden no coincidir con los riesgos de su proyecto.
3.3. RIESGOS 39
• El equipo siempre (o nunca) debe crear la documentación completa para cada sistema. • El
equipo debe siempre (o nunca) construir un diagrama de clases, un diagrama de capas, etc. • El
equipo debe dedicar el 10% (o 0%) del tiempo del proyecto a la arquitectura.
Dichas pautas pueden ser mejores que ninguna guía, pero cada proyecto enfrentará un conjunto diferente
de riesgos. Sería una gran coincidencia que el mismo conjunto de diagramas o técnicas fueran siempre la
mejor manera de mitigar un conjunto cambiante de riesgos.
Ejemplo de desajuste. Imagine una empresa que construye un sistema de 3 niveles. El primer nivel tiene
la interfaz de usuario y está expuesto a Internet. Sus mayores riesgos podrían ser la usabilidad y la
seguridad. Los niveles segundo y tercero implementan reglas comerciales y persistencia; están detrás de
un cortafuegos. Los mayores riesgos podrían ser el rendimiento y la escalabilidad.
Si esta empresa siguiera el modelo basado en el riesgo, los desarrolladores front-end y back-end
aplicarían diferentes técnicas de arquitectura y diseño para abordar sus diferentes riesgos. En cambio, lo
que sucede a menudo es que ambos equipos siguen el mismo proceso o plantilla estándar de la empresa y
producen, por ejemplo, un diagrama de dependencia del módulo. El problema es que no hay conexión entre
las técnicas que utilizan y los riesgos a los que se enfrentan.
Los procesos o plantillas estándar no son necesariamente malos, pero a menudo se usan mal. Con el
tiempo, podrá generalizar los riesgos de los proyectos de su empresa y diseñar una lista de técnicas
apropiadas. Lo importante es que las técnicas coincidan con los riesgos.
Los tres pasos para la arquitectura de software impulsada por el riesgo son engañosamente simples,
pero el problema está en los detalles. ¿Qué son exactamente los riesgos y las técnicas? ¿Cómo se elige
un conjunto apropiado de técnicas? ¿Y cuándo dejas de diseñar y comienzas/reanudas la construcción?
Las siguientes secciones profundizan en estas preguntas con más detalle.
3.3 Riesgos
En el contexto de la ingeniería, el riesgo se define comúnmente como la probabilidad de falla multiplicada

por el impacto de esa falla. Tanto la probabilidad de falla como el impacto son inciertos porque son difíciles
de medir con precisión. Puede eludir la distinción entre riesgos percibidos y riesgos reales agrupando el
concepto de incertidumbre en la definición de riesgo. La definición de riesgo entonces se convierte en:
riesgo = probabilidad percibida de falla × impacto percibido
Un resultado de esta definición es que un riesgo puede existir (es decir, puedes percibirlo) incluso si no
existe. Imagine un programa hipotético que no tiene errores. Si nunca ha ejecutado el programa ni lo ha
probado, ¿debería preocuparse de que falle? Es decir, ¿debería percibir un riesgo de fracaso? Por supuesto
que debería, pero después de analizar y probar el programa, adquiere confianza en él y su percepción del
riesgo disminuye. Entonces por
Riesgos de gestión de proyectos Riesgos de ingeniería de software
“Desarrollador líder atropellado por autobús” “El servidor puede no escalar a 1000 usuarios”
"Las necesidades del cliente no se comprenden" "El análisis de los mensajes de respuesta puede tener errores"
“El vicepresidente sénior odia a nuestro gerente” “El sistema está funcionando ahora, pero si tocamos
algo, puede desmoronarse”
Figura 3.1: Ejemplos de gestión de proyectos y riesgos de ingeniería. Debe distinguirlos porque las técnicas de ingeniería
rara vez resuelven los riesgos de gestión y viceversa.
aplicando técnicas, puede reducir la cantidad de incertidumbre y, por lo tanto, la cantidad de riesgo
(percibido). También puede subestimar o no percibir un riesgo, del cual hablaremos en breve.
Describiendo riesgos. Puede declarar un riesgo categóricamente, a menudo como la falta de un atributo
de calidad necesario, como la modificabilidad o la confiabilidad. Pero a menudo esto es demasiado vago
para ser procesable: si hace algo, ¿está seguro de que realmente reduce el riesgo categórico?
Es mejor describir los riesgos de tal manera que luego pueda probarlos para ver si se han mitigado. En
lugar de simplemente enumerar un atributo de calidad como la confiabilidad, describa cada riesgo de falla
como un escenario de falla comprobable, como "Durante las cargas máximas, los clientes experimentan
latencias de interfaz de usuario superiores a cinco segundos".
Riesgos de ingeniería y gestión de proyectos. Los proyectos enfrentan muchos tipos diferentes de riesgos,
por lo que las personas que trabajan en un proyecto tienden a prestar atención a los riesgos relacionados
con su especialidad. Por ejemplo, el equipo de ventas se preocupa por una buena estrategia de ventas y los
desarrolladores de software se preocupan por la escalabilidad de un sistema. En términos generales,
podemos categorizar los riesgos como riesgos de ingeniería o riesgos de gestión de proyectos. Los riesgos
de ingeniería son aquellos riesgos relacionados con el análisis, diseño e implementación del producto. Estos
riesgos de ingeniería están en el dominio de la ingeniería del sistema. Los riesgos de la gestión de proyectos
se relacionan con los cronogramas, la secuencia del trabajo, la entrega, el tamaño del equipo, la geografía,
etc. La Figura 3.1 muestra ejemplos de ambos.
Si eres un desarrollador de software, se te pide que mitigues los riesgos de ingeniería y estarás aplicando
técnicas de ingeniería. El tipo de técnica debe coincidir con el tipo de riesgo, por lo que solo las técnicas de
ingeniería mitigarán los riesgos de ingeniería. Por ejemplo, no puede utilizar un gráfico PERT (una técnica
de gestión de proyectos) para reducir la posibilidad de que se sobrecargue el búfer (un riesgo de ingeniería),
y el uso de Java no resolverá los desacuerdos entre las partes interesadas.
3.3. RIESGOS 41
Dominio del proyecto Riesgos prototípicos
Información Problema complejo, mal entendido

Tecnología (TI) No estoy seguro de que estemos resolviendo el problema real
Puede elegir el software COTS incorrecto

Integración con software existente poco conocido
Conocimiento del dominio disperso entre las personas.
modificabilidad
Sistemas Rendimiento, fiabilidad, tamaño, seguridad

concurrencia
Composición
Web Seguridad
Escalabilidad de aplicaciones
Productividad/expresabilidad del desarrollador
Figura 3.2: Si bien cada proyecto puede tener un conjunto único de riesgos, es posible generalizar por dominio. Los riesgos
prototípicos son los que son comunes en un dominio y son la razón por la que las prácticas de desarrollo de software varían según
el dominio. Por ejemplo, los desarrolladores de proyectos de sistemas tienden a utilizar los lenguajes de mayor rendimiento.
Identificación de riesgos. A los desarrolladores experimentados les resulta fácil identificar los riesgos,
pero ¿qué se puede hacer si el desarrollador tiene menos experiencia o trabaja en un dominio desconocido?
El lugar más fácil para comenzar es con los requisitos, en cualquier forma que adopten, y buscando cosas
que parezcan difíciles de lograr. Los requisitos de atributos de calidad mal entendidos o incompletos son un
riesgo común. Puede utilizar Talleres de atributos de calidad (consulte la Sección 15.6.2), un Cuestionario
basado en taxonomía (Carr et al., 1993), o algo similar, para obtener riesgos y producir una lista priorizada
de escenarios de falla.
Incluso con diligencia, no podrá identificar todos los riesgos. Cuando era niño, mis padres me enseñaron
a mirar a ambos lados antes de cruzar la calle porque identificaban los autos como un riesgo. Hubiera sido
igualmente malo si me hubiera atropellado un coche o si me hubiera caído un meteorito, pero pusieron su
atención en el riesgo previsto y de alta prioridad. Debe aceptar que su proyecto enfrentará riesgos no
identificados a pesar de sus mejores esfuerzos.
Riesgos prototípicos. Después de haber trabajado en un dominio por un tiempo, notará riesgos prototípicos
que son comunes a la mayoría de los proyectos en ese dominio. Por ejemplo, los proyectos de sistemas
suelen preocuparse más por el rendimiento que los proyectos de TI, y los proyectos web casi siempre se
preocupan por la seguridad. Los riesgos prototípicos pueden haberse codificado como listas de verificación
que describen áreas problemáticas históricas, quizás generadas a partir de revisiones de arquitectura. Estas
listas de verificación (consulte la Sección 15.6.2) son un conocimiento valioso
para desarrolladores menos experimentados y un recordatorio útil para los experimentados.

Conocer los riesgos prototípicos en su dominio es una gran ventaja, pero aún más
importante es darse cuenta cuando su proyecto difiere de la norma para evitar
lugares. Por ejemplo, el software que ejecuta un hospital podría parecerse más a un software de TI.
proyecto, con sus preocupaciones de integración y tipos de dominios complejos. Sin embargo, un sistema
que tarda 10 minutos en reiniciarse después de un corte de energía suele ser un riesgo menor para una TI
proyecto, pero un gran riesgo en un hospital.
Priorización de riesgos. No todos los riesgos son igualmente grandes, por lo que se pueden priorizar.
La mayoría de los equipos de desarrollo priorizarán los riesgos discutiendo las prioridades entre ellos.
Esto puede ser adecuado, pero la percepción de los riesgos del equipo puede no ser la misma que la
percepción de los interesados. Si su equipo dedica suficiente tiempo a la arquitectura de software para
que se note en su presupuesto, es mejor validar ese tiempo y dinero.
se gastan de acuerdo con las prioridades de las partes interesadas.
Los riesgos se pueden categorizar1 en dos dimensiones: su prioridad para las partes interesadas y
su dificultad percibida por los desarrolladores. Tenga en cuenta que algunos riesgos técnicos, como
opciones de plataforma, no pueden ser fácilmente evaluadas por las partes interesadas.
Existen procedimientos formales para catalogar y priorizar riesgos utilizando matrices de riesgo,
incluyendo un estándar militar estadounidense MIL-STD-882D. La priorización formal de los riesgos es
apropiada si su sistema, por ejemplo, maneja material radiactivo, pero la mayoría de los sistemas
informáticos pueden ser menos formales.
3.4 Técnicas
Una vez que sepa a qué riesgos se enfrenta, puede aplicar las técnicas que espera
para reducir el riesgo. El término técnica es bastante amplio, por lo que nos centraremos específicamente
en técnicas de reducción de riesgos de ingeniería de software, pero por conveniencia continúe usando
la técnica del nombre simple . La Figura 3.3 muestra una breve lista de ingeniería de software
técnicas y técnicas de otras ramas de la ingeniería.
Espectro desde análisis hasta soluciones. Imagina que estás construyendo una catedral y
te preocupa que se caiga. Podrías construir modelos de varios diseños.
alternativas y calcular sus tensiones y deformaciones. Alternativamente, puede aplicar un
solución conocida, como el uso de un contrafuerte volador. Ambos funcionan, pero el primer enfoque
tiene un carácter analítico mientras que el segundo tiene un carácter de solución conocida.
Las técnicas existen en un espectro que va desde análisis puros, como el cálculo de tensiones, hasta
soluciones puras, como usar un contrafuerte volador en una catedral. Otros libros de arquitectura y diseño
de software han inventariado técnicas en el extremo de la solución del espectro, y llaman a estas técnicas
tácticas (Bass, Clements y Kazman, 2003) o patrones .
1Esta es la misma técnica de categorización utilizada en ATAM para priorizar los controladores de arquitectura y la calidad en
escenarios de tributo, como se discutió en la Sección 12.11.
3.4. TÉCNICAS 43
Ingeniería de software Otra ingeniería
Aplicación de patrón de diseño o arquitectura Cálculos de tensión
modelado de dominio Prueba de punto de ruptura
Modelado de rendimiento Análisis térmico
Análisis de seguridad Pruebas de confiabilidad
Prototipos Prototipos
Figura 3.3: Algunos ejemplos de técnicas de reducción de riesgos de ingeniería en ingeniería de software y
otros campos. El modelado es un lugar común en todos los campos de la ingeniería.
(Schmidt et al., 2000; Gamma et al., 1995), e incluyen soluciones tales como el uso de un monitor de
proceso, un transmisor-receptor o un modelo-vista-controlador.
El modelo impulsado por el riesgo se enfoca en técnicas que están en el extremo del análisis de la
espectro, los que son procedimentales e independientes del dominio del problema. Estas
las técnicas incluyen el uso de modelos como diagramas de capas, modelos de ensamblaje de
componentes y modelos de implementación; aplicar técnicas analíticas de rendimiento, seguridad,
y confiabilidad; y aprovechar estilos arquitectónicos como cliente-servidor y tubería y filtro para lograr
una calidad emergente.
Las técnicas mitigan los riesgos. El diseño es un proceso misterioso, donde los virtuosos pueden hacer
saltos de razonamiento entre problemas y soluciones (Shaw y Garlan, 1996). Para
su proceso sea repetible, sin embargo, necesita hacer explícito lo que los virtuosos
están haciendo tácitamente. En este caso, debe poder indicar explícitamente cómo elegir
técnicas de respuesta a los riesgos. Hoy en día, este conocimiento es mayoritariamente informal, pero podemos
aspiramos a crear un manual que nos ayude a tomar decisiones informadas. Sería
llenarse con entradas que se vean así:
Si tiene <un riesgo>, considere <una técnica> para reducirlo.
Tal manual mejoraría la repetibilidad del diseño de arquitecturas de software.

codificando el conocimiento de arquitectos virtuosos como mapeos entre riesgos y
tecnicas
Cualquier técnica en particular es buena para reducir algunos riesgos pero no otros. en un orden
y ordenado, habría una única técnica para hacer frente a todos los riesgos conocidos.
En la práctica, algunos riesgos pueden mitigarse mediante múltiples técnicas, mientras que otros riesgos
requieren que inventes técnicas sobre la marcha.
Este estado de ánimo, donde eliges técnicas basadas en riesgos, te ayuda a
trabajar eficiente mente. No desea perder tiempo (u otros recursos) en proyectos de bajo impacto
técnicas, ni quiere ignorar los riesgos que amenazan el proyecto. quieres construir
sistemas exitosos al tomar un camino que invierta su tiempo de la manera más efectiva. Eso
significa solo aplicar técnicas cuando están motivadas por los riesgos.
Cesta óptima de técnicas. Para evitar perder su tiempo y dinero, debe elegir las técnicas que
mejor reduzcan su lista priorizada de riesgos. Debe buscar oportunidades para matar dos pájaros
de un tiro aplicando una sola técnica para mitigar dos o más riesgos. Es posible que desee pensar
en ello como un problema de optimización para elegir un conjunto de técnicas que mitiguen de
manera óptima sus riesgos.
Es más difícil decidir qué técnicas se deben aplicar de lo que parece a primera vista. Cada
técnica hace algo valioso, pero no lo valioso que su proyecto más necesita. Por ejemplo, existen
técnicas para mejorar la usabilidad de sus interfaces de usuario. Imagine que usó con éxito tales
técnicas en su último proyecto, por lo que las elige nuevamente en su proyecto actual. Encuentra
tres fallas de usabilidad en su diseño y las corrige. ¿Significa esto que emplear la técnica de
usabilidad fue una buena idea?
No necesariamente, porque tal razonamiento ignora el costo de oportunidad. La comparación

justa es con las otras técnicas que podría haber usado. Si su mayor riesgo es que su marco
elegido sea inapropiado, debe dedicar su tiempo a analizar o crear prototipos de su elección de
marco en lugar de la usabilidad. Su tiempo es escaso, por lo que debe elegir técnicas que sean
máximamente efectivas para reducir sus riesgos de falla, no solo algo efectivas.
No se puede eliminar el riesgo de ingeniería. Tal vez se esté preguntando por qué deberíamos
intentar crear una cesta óptima de técnicas cuando deberíamos ir hasta el final y eliminar el riesgo
de ingeniería. Es tentador, ya que los ingenieros odian ignorar los riesgos, especialmente aquellos
que saben cómo abordar.
La desventaja de tratar de eliminar el riesgo de ingeniería es el tiempo. Como pioneros de la
aviación, los hermanos Wright dedicaron tiempo a investigaciones matemáticas y empíricas sobre
los principios aeronáuticos y, por lo tanto, redujeron su riesgo de ingeniería. Pero, si hubieran
continuado estas investigaciones hasta eliminar los riesgos, su primer vuelo de prueba podría
haber sido en 1953 en lugar de 1903.
La razón por la que no puede darse el lujo de eliminar el riesgo de ingeniería es porque debe
equilibrarlo con el riesgo que no es de ingeniería, que es predominantemente el riesgo de gestión
de proyectos. En consecuencia, un desarrollador de software no tiene la opción de aplicar todas
las técnicas útiles porque las reducciones de riesgo deben equilibrarse con el tiempo y el costo.
3.5 Orientación sobre la elección de técnicas
Hasta ahora, se le ha presentado el modelo basado en el riesgo y se le ha aconsejado que elija

técnicas basadas en sus riesgos. Debería preguntarse cómo tomar buenas decisiones. En el
futuro, tal vez un desarrollador que elija técnicas actuará como un
3.5. ORIENTACIÓN PARA LA ELECCIÓN DE TÉCNICAS 45
ingeniero mecánico que elige materiales consultando tablas de propiedades y tomando decisiones
cuantitativas. Por ahora, tales tablas no existen. Sin embargo, puede preguntar a los desarrolladores
experimentados qué harían para mitigar los riesgos. Es decir, elegirías técnicas basadas en su
experiencia y en la tuya.
Sin embargo, si tiene curiosidad, no estaría satisfecho con una tabla o una colección de consejos
de los veteranos del software. Seguramente debe haber principios que subyacen a cualquier tabla o
experiencia de cualquier veterano, principios que expliquen por qué la técnica X funciona para mitigar
el riesgo Y.
Dichos principios existen y ahora veremos algunos importantes. Aquí hay una breve vista previa.
En primer lugar, a veces tiene un problema que encontrar , mientras que otras veces tiene un problema
que probar, y la elección de su técnica debe coincidir con esa necesidad. En segundo lugar, algunos
problemas se pueden resolver con un modelo analógico , mientras que otros requieren un modelo
analítico , por lo que deberá diferenciar este tipo de modelos. Tercero, puede que solo sea eficiente
analizar un problema usando un tipo particular de modelo. Y finalmente, algunas técnicas tienen
afinidades, como el machacado es adecuado para clavos y el torcer es adecuado para tornillos.
Problemas para encontrar y probar. En su libro Cómo resolverlo, George Polya identifica dos tipos
distintos de problemas matemáticos: problemas para encontrar y problemas para probar (Polya, 2004).
El problema, "¿Hay un número que cuando se eleva al cuadrado es igual a 4?" es un problema para
encontrar, y puede probar su respuesta propuesta fácilmente. Por otro lado, “¿Es infinito el conjunto de
los números primos?” es un problema a probar. Encontrar cosas tiende a ser más fácil que probar
cosas porque para las pruebas necesitas demostrar que algo es cierto en todos los casos posibles.
Al buscar una técnica para abordar un riesgo, a menudo puede eliminar muchas técnicas posibles
porque responden el tipo incorrecto de pregunta de Polya. Algunos riesgos son específicos, por lo que
se pueden probar con casos de prueba sencillos. Es fácil imaginar escribir un caso de prueba para
"¿Puede la base de datos contener nombres de hasta 100 caracteres?" ya que es un problema
encontrarlo. Del mismo modo, es posible que deba diseñar un sitio web escalable.
Este también es un problema para encontrar porque solo necesita diseñar (es decir, encontrar) una
solución, no demostrar que su diseño es óptimo.
Por el contrario, es difícil imaginar un pequeño conjunto de casos de prueba que proporcione
evidencia persuasiva cuando tiene un problema que probar. Considere, "¿El sistema siempre se ajusta
a la interfaz de programación de aplicaciones (API) del marco?" Sus pruebas podrían tener éxito, pero
podría haber un caso que aún no haya visto, tal vez cuando una llamada de marco pasa
inesperadamente una referencia nula. Otro ejemplo de un problema a probar es el interbloqueo:
cualquier número de pruebas puede ejecutarse con éxito sin revelar un problema en un protocolo de
bloqueo.
Modelos analíticos y analógicos. Michael Jackson, dando crédito a Russell Ackoff, distingue entre
modelos analógicos y modelos analíticos (Jackson, 1995; Jackson, 2000).
En un modelo analógico, cada elemento del modelo tiene un análogo en el dominio de interés. Una
pantalla de radar es un modelo analógico de algún terreno, donde las señales en la pantalla corresponden
a aviones: la señal y el avión son análogos.
Los modelos analógicos admiten el análisis solo indirectamente y, por lo general, se requiere
conocimiento del dominio o razonamiento humano. Una pantalla de radar puede ayudarlo a responder
la pregunta: "¿Están estos aviones en curso de colisión?" pero para hacerlo, está utilizando su capacidad
intelectual de propósito especial de la misma manera que un jardinero puede saber si está en posición
de atrapar un elevado (consulte la Sección 15.6.1).
Un modelo analítico (lo que Ackoff llamaría simbólico) , por el contrario, apoya directamente el
análisis computacional. Las ecuaciones matemáticas son ejemplos de modelos analíticos, al igual que
las máquinas de estado. Podrías imaginar un modelo analítico de los aviones donde cada uno está
representado por un vector. Las matemáticas brindan una capacidad analítica para relacionar los
vectores, por lo que puede responder cuantitativamente preguntas sobre cursos de colisión.
Cuando modela software, invariablemente usa símbolos, ya sean elementos del lenguaje de
modelado unificado (UML) o alguna otra notación. Debe tener cuidado porque algunos de esos modelos
simbólicos admiten el razonamiento analítico mientras que otros admiten el razonamiento analógico,
incluso cuando usan la misma notación. Por ejemplo, dos modelos UML diferentes podrían representar
aviones como clases, uno con y otro sin un atributo para el vector del avión. El modelo UML con el
vector le permite calcular un curso de colisión, por lo que es un modelo analítico. El modelo UML sin el
vector no lo hace, por lo que es un modelo analógico. Por lo tanto, el simple uso de una notación
definida, como UML, no garantiza que sus modelos sean analíticos. Los lenguajes de descripción de
arquitectura (ADL) están más restringidos que UML, con la intención de empujar sus modelos de
arquitectura para que sean analíticos.
Que un modelo determinado sea analítico o analógico depende de la pregunta que desee que
responda. Cualquiera de los modelos UML podría usarse para contar aviones, por ejemplo, y por lo
tanto podrían considerarse modelos analíticos.
Cuando sabe qué riesgos desea mitigar, puede elegir adecuadamente un modelo analítico o
analógico. Por ejemplo, si le preocupa que sus ingenieros no entiendan las relaciones entre las
entidades del dominio, puede crear un modelo analógico en UML y confirmarlo con expertos en el
dominio. Por el contrario, si necesita calcular distribuciones de tiempo de respuesta, querrá un modelo
analítico.
Coincidencia de tipo de vista. La eficacia de algunos emparejamientos riesgo-técnica depende del

tipo de modelo o vista que se utilice. Los tipos de vista no se analizan completamente hasta la Sección 9.6.
Por ahora, es suficiente conocer los tres tipos de vista principales. El tipo de vista de módulo incluye
artefactos tangibles como el código fuente y las clases; el tipo de vista de tiempo de ejecución incluye
estructuras de tiempo de ejecución como objetos; y el tipo de vista de asignación incluye elementos de
asignación como salas de servidores y hardware. Es más fácil razonar sobre la modificabilidad desde el
tipo de vista del módulo, el rendimiento desde el tipo de vista del tiempo de ejecución y la seguridad
desde los tipos de vista de implementación y módulo.
3.6. CUANDO PARAR 47
Cada vista revela detalles seleccionados de un sistema. El razonamiento sobre un riesgo funciona mejor
cuando la vista que se utiliza revela detalles relevantes para ese riesgo. Por ejemplo, razonar sobre un
protocolo de tiempo de ejecución es más fácil con una vista de tiempo de ejecución, tal vez una máquina de
estado, que con el código fuente. De manera similar, es más fácil razonar sobre puntos únicos de falla
utilizando una vista de asignación que una vista de módulo.
A pesar de esto, los desarrolladores son adaptables y trabajarán con los recursos que tengan, y
simularán mentalmente los otros tipos de vista. Por ejemplo, los desarrolladores suelen tener acceso al
código fuente, por lo que se han vuelto expertos en imaginar el comportamiento del código en tiempo de
ejecución y dónde se implementará. Si bien un desarrollador puede arreglárselas con el código fuente, el
razonamiento será más fácil cuando el riesgo y el tipo de vista coincidan, y la vista revele detalles
relacionados con el riesgo.
Técnicas con afinidades. En el mundo físico, las herramientas están diseñadas para un propósito: los
martillos son para clavar clavos, los destornilladores para girar tornillos, las sierras para cortar. A veces
puede martillar un tornillo o usar un destornillador como palanca, pero los resultados son mejores cuando
usa la herramienta adecuada para el trabajo.
En la arquitectura de software, algunas técnicas solo conllevan riesgos particulares porque fueron
diseñadas de esa manera y es difícil usarlas para otro propósito. Por ejemplo, Rate Monotonic Analysis
ayuda principalmente con los riesgos de confiabilidad, el modelado de amenazas ayuda principalmente con
los riesgos de seguridad y la teoría de colas ayuda principalmente con los riesgos de rendimiento (estas
técnicas se analizan en la Sección 15.6).
3.6 Cuándo parar
El comienzo de este capítulo planteó dos preguntas. Hasta ahora, este capítulo ha explorado el primero:
¿Qué técnicas de diseño y arquitectura debería usar? La respuesta es identificar los riesgos y elegir técnicas
para combatirlos. Las técnicas más adecuadas para un proyecto no serán las más adecuadas para otro
proyecto. Pero la mentalidad de alinear sus técnicas de arquitectura, su experiencia y la orientación que ha
aprendido lo guiarán hacia las técnicas apropiadas.
Ahora dirigimos nuestra atención a la segunda pregunta: ¿Cuánto diseño y arquitectura debe hacer? El
tiempo dedicado a diseñar o analizar es tiempo que podría haberse dedicado a construir, probar, etc., por lo
que desea obtener el equilibrio correcto, sin hacer demasiado diseño ni ignorar los riesgos que podrían
inundar su proyecto.
El esfuerzo debe ser proporcional al riesgo. El modelo basado en el riesgo se esfuerza por aplicar de
manera eficiente las técnicas para reducir los riesgos, lo que significa no aplicar técnicas en exceso o en
defecto. Para lograr la eficiencia, el modelo basado en el riesgo utiliza este principio rector:
Los esfuerzos de la arquitectura deben ser proporcionales al riesgo de fracaso.

Si recuerda la historia de mi padre y el buzón, no estaba muy preocupado por la caída del buzón, por lo
que no dedicó mucho tiempo a diseñar la solución o aplicar análisis de ingeniería mecánica. Pensó un
poco en el diseño, tal vez considerando qué tan profundo debería ser el agujero, pero la mayor parte de
su tiempo lo dedicó a la implementación.
Cuando no le preocupen los riesgos de seguridad, no dedique tiempo al diseño de seguridad.

Sin embargo, cuando el desempeño es un riesgo que amenaza el proyecto, trabaje en él hasta que esté
razonablemente seguro de que el desempeño estará bien.
Diseños de arquitectura incompletos. Cuando aplica el modelo basado en el riesgo, solo diseña las
áreas en las que percibe riesgos de falla. La mayoría de las veces, aplicar una técnica de diseño significa
construir un modelo de algún tipo, ya sea en papel o en una pizarra blanca. En consecuencia, es probable
que su modelo de arquitectura sea detallado en algunas áreas e incompleto, o incluso inexistente, en otras.
Por ejemplo, si ha identificado algunos riesgos de rendimiento y ningún riesgo de seguridad, crearía
modelos para abordar los riesgos de rendimiento, pero esos modelos no tendrían detalles de seguridad.
Aún así, no se modelarían ni decidirían todos los detalles sobre el rendimiento. Recuerde que los modelos
son un producto intermedio y puede dejar de trabajar en ellos una vez que se haya convencido de que su
arquitectura es adecuada para abordar sus riesgos.
Evaluación subjetiva. El modelo basado en el riesgo dice que priorice sus riesgos, aplique las técnicas
elegidas y luego evalúe cualquier riesgo restante, lo que significa que debe decidir si el riesgo se ha
mitigado lo suficiente. Pero, ¿qué significa suficientemente mitigado?
Ha priorizado sus riesgos, pero ¿qué riesgos hacen el corte y cuáles no?
El modelo basado en el riesgo es un marco para facilitar la toma de decisiones, pero no puede emitir
juicios por usted. Identifica ideas destacadas (riesgos priorizados y técnicas correspondientes) y lo guía
para hacer las preguntas correctas sobre su trabajo de diseño. Al utilizar el modelo basado en el riesgo,
está a la vanguardia porque identificó los riesgos, promulgó las técnicas correspondientes y mantuvo su
esfuerzo acorde con sus riesgos. Pero eventualmente debe hacer una evaluación subjetiva: ¿la arquitectura
que diseñó le permitirá superar sus riesgos de falla?
3.7 Diseño planificado y evolutivo
Ahora debe estar preparado, al menos a nivel conceptual, para salir y aplicar la arquitectura de software
en sus proyectos. Sin embargo, es posible que aún tenga algunas preguntas sobre cómo proceder, ya que
aún no hemos discutido cómo interactúa el modelo basado en riesgos con otros tipos de orientación que
ya conoce, cosas como el diseño planificado y evolutivo, los procesos de software y, específicamente, el
desarrollo ágil de software. .
3.7. DISEÑO PLANIFICADO Y EVOLUTIVO 49
El resto del capítulo muestra cómo el modelo centrado en el riesgo es compatible con cada uno de estos
y se puede utilizar para aumentar su asesoramiento.
Comenzamos analizando tres estilos de diseño: diseño planificado, evolutivo y mínimo planificado.
Planificado y evolutivo son los dos estilos básicos de diseño y el diseño mínimo planificado es una
combinación de ellos.
Diseño evolutivo. El diseño evolutivo “significa que el diseño del sistema crece a medida que se
implementa” (Fowler, 2004). Históricamente, el diseño evolutivo ha sido mal visto porque las decisiones
de diseño locales y descoordinadas generan caos, creando un sistema de mezcolanza que es difícil de
mantener y evolucionar más.
Sin embargo, las tendencias recientes en los procesos de software han revitalizado el diseño
evolutivo al abordar la mayoría de sus deficiencias. Las prácticas ágiles de refactorización, diseño basado
en pruebas e integración continua funcionan contra el caos. La refactorización (una transformación del
código que conserva el comportamiento) limpia los diseños locales descoordinados (Fowler, 1999), el
diseño basado en pruebas garantiza que los cambios en el sistema no provoquen la pérdida o el deterioro
de la funcionalidad existente, y la integración continua proporciona la totalidad equipo con la misma base
de código. Algunos argumentan que estas prácticas son lo suficientemente poderosas como para evitar
por completo el diseño planificado (Beck y Andres, 2004).
De las tres prácticas, la refactorización es el caballo de batalla que reduce la mezcolanza en el

diseño evolutivo. La refactorización reemplaza los diseños que resolvieron problemas locales más
antiguos con diseños que resuelven problemas globales actuales. La refactorización, sin embargo, tiene límites.
Las técnicas de refactorización actuales proporcionan poca orientación para las transformaciones a
escala de la arquitectura. Por ejemplo, el cambio radical de Amazon de una arquitectura de base de
datos única en niveles a una arquitectura orientada a servicios (Hoff, 2008a) es difícil de imaginar como
resultado de pequeños pasos de refactorización a nivel de clases y métodos individuales.
Además, el código heredado generalmente carece de suficientes casos de prueba para participar con confianza en la
refactorización, sin embargo, la mayoría de los sistemas tienen algún código heredado.
Aunque algunos proyectos usan el diseño evolutivo de manera imprudente, sus defensores dicen
que el diseño evolutivo debe combinarse con prácticas de apoyo como la refactorización, el diseño
basado en pruebas y la integración continua.
Diseño planificado. En el extremo opuesto del espectro del diseño evolutivo se encuentra el diseño
planificado. La idea general detrás del diseño planificado es que los planos se elaboran con gran detalle
antes de que comience la construcción. A menudo se plantean analogías con el diseño y la construcción
de puentes, ya que la construcción de puentes rara vez comienza antes de que se complete su diseño.
Pocas personas recomiendan2 hacer un diseño planificado para un sistema de software completo,
un enfoque que a veces se denomina Big Design Up Front (BDUF). Sin embargo, la planificación completa
2Model Driven Engineering (MDE) es una excepción, ya que necesita un modelo detallado para generar código.
algunos autores (Lattanze, 2008; Bass, Clements y Kazman, 2003), ya que a menudo es difícil saber
en un proyecto grande o complejo que cualquier sistema puede satisfacer los requisitos. Cuando no
está seguro de que se pueda construir un sistema, es mejor averiguarlo pronto.
El diseño de arquitectura planificada también es práctico cuando una arquitectura es compartida

por muchos equipos que trabajan en paralelo y, por lo tanto, es útil saberlo antes de que los subequipos
comiencen a trabajar. En este caso, una arquitectura planificada que define los componentes y
conectores de nivel superior se puede combinar con diseños locales, donde los subequipos diseñan los
modelos internos de los componentes y conectores. La arquitectura generalmente insiste en algunas
invariantes generales y decisiones de diseño, como establecer una política de concurrencia, un conjunto
estándar de conectores, asignar responsabilidades de alto nivel o definir algunos escenarios de
atributos de calidad localizados. Tenga en cuenta que los elementos de modelado arquitectónico, como
componentes y conectores, se describirán en detalle en la segunda parte de este libro.
Incluso cuando se sigue un diseño planificado, una arquitectura o un diseño rara vez, o nunca,
debe estar completo al 100 % antes de proceder con la creación de prototipos o la codificación. Con las
técnicas de diseño actuales, es casi imposible perfeccionar el diseño sin la retroalimentación del código
en ejecución.
Diseño mínimo planificado. Entre el diseño evolutivo y el diseño planificado se encuentra el diseño
planificado mínimo, o Little Design Up Front (Martin, 2009). Los defensores del diseño mínimo
planificado se preocupan de que se arrinconen a sí mismos si hicieran todo el diseño evolutivo, pero
también les preocupa que todo el diseño planificado sea difícil y probable que haga las cosas mal.
Martin Fowler pone números estimados en esto, diciendo que hace aproximadamente un 20% de
diseño planificado y un 80% de diseño evolutivo (Venners, 2002).
Es posible equilibrar el diseño planificado y evolutivo. Una forma es hacer un diseño planificado
inicial para garantizar que la arquitectura manejará los mayores riesgos.
Después de este diseño planificado inicial, los cambios futuros en los requisitos a menudo se pueden
manejar a través del diseño local o con un diseño evolutivo si el proyecto también tiene prácticas de
refactorización, diseño basado en pruebas e integración continua que funcionan sin problemas.
Si le preocupa principalmente qué tan bien la arquitectura soportará las cualidades globales o
emergentes, puede hacer un diseño planificado para asegurar estas cualidades y reservar cualquier
diseño restante como diseño evolutivo o local. Por ejemplo, si ha identificado el rendimiento como su
mayor riesgo, podría participar en un diseño planificado para establecer presupuestos de rendimiento
(p. ej., las entregas de mensajes se realizan en 25 ms el 90 % del tiempo).
El resto del diseño, que aseguraba que los componentes y conectores individuales cumplieran con
esos presupuestos de desempeño, podría realizarse como un diseño evolutivo o local.
La idea general es realizar un diseño centrado en la arquitectura (consulte la Sección 2.7) para
configurar una arquitectura conocida por manejar sus mayores riesgos, permitiéndole más libertad en
otras decisiones de diseño.
3.8. PROCESO DE DESARROLLO DE SOFTWARE 51
¿Cuál es el mejor? Independientemente del estilo de diseño que prefiera, debe diseñar el software
antes de escribir el código, ya sea diez minutos antes o diez meses antes. Ambos estilos de diseño
tienen defensores devotos y su debate se basa en anécdotas en lugar de datos sólidos, por lo que,
por ahora, las opiniones variarán. Si tiene mucha confianza en su capacidad para hacer un diseño
evolutivo, hará un diseño menos planificado.
Tenga en cuenta que los diferentes sistemas se prestarán a diferentes estilos de diseño.
Considere los lentos cambios en el servidor web Apache durante la última década. Es adecuado para
el diseño planificado porque su diseño se parece a un problema de optimización para un conjunto
estable de requisitos (por ejemplo, alta confiabilidad, extensibilidad y rendimiento).
Por otro lado, muchos proyectos tienen requisitos que cambian rápidamente y favorecen el diseño
evolutivo.
La tensión esencial entre el diseño planificado y el evolutivo es la siguiente: una larga ventaja en
el diseño arquitectónico genera oportunidades para garantizar propiedades globales, evitar callejones
sin salida en el diseño y coordinar subequipos, pero se produce a expensas de la posibilidad de
cometer errores que se evitarían. si las decisiones se tomaron más tarde. Los equipos con sólidas
prácticas de refactorización, desarrollo basado en pruebas y de integración continua podrán realizar
un diseño más evolutivo que otros equipos.
El modelo basado en el riesgo es compatible con el diseño evolutivo, planificado y mínimo
planificado. Todos estos estilos de diseño están de acuerdo en que el diseño debería ocurrir en algún
momento y todos asignan tiempo para ello. En el diseño planificado, ese tiempo es inicial, por lo que
aplicar el modelo basado en riesgos significa hacer un diseño inicial hasta que los riesgos de la
arquitectura hayan disminuido. En el diseño evolutivo, significa hacer el diseño de la arquitectura
durante el desarrollo, siempre que un riesgo se presente lo suficientemente grande. Aplicarlo al
diseño planificado mínimo es una combinación de los demás.
3.8 Proceso de desarrollo de software
Pocos desarrolladores construyen sistemas usando solo un estilo de diseño, digamos diseño evolutivo
y un compilador. En cambio, sus actividades están estructuradas utilizando un proceso de desarrollo
de software que ha sido diseñado para aumentar sus posibilidades de entregar con éxito un buen
sistema. Un buen proceso de desarrollo de software hace más que minimizar los riesgos de ingeniería,
ya que también debe tener en cuenta otras necesidades y riesgos comerciales, como las presiones
del tiempo de comercialización.
Cuando amplía su atención de los riesgos de ingeniería puros a los riesgos generales del
proyecto, encuentra muchos más riesgos de los que preocuparse. ¿El cliente aceptará su sistema?
¿Habrá cambiado el mercado para el momento de la entrega? ¿Entregarás a tiempo? ¿Reflejaron
sus requisitos los deseos del cliente? ¿Tiene las personas adecuadas, están haciendo los trabajos
correctos y se comunican de manera efectiva? ¿Habrá juicios?
Proceso de desarrollo de software. Un proceso de desarrollo de software organiza las actividades de

un equipo con el objetivo de equilibrar los riesgos de ingeniería y gestión de proyectos. Es tentador,
pero imposible, separar claramente el proceso de ingeniería del proceso de gestión de proyectos. Un
proceso de desarrollo de software lo ayuda a priorizar los riesgos tanto en la ingeniería como en la
gestión de proyectos, y tal vez a decidir que, aunque todavía existen riesgos de ingeniería, otros riesgos
los superan.
El riesgo como vocabulario compartido. Los riesgos son el vocabulario compartido entre ingenieros
y gerentes de proyectos. El trabajo de un gerente es comprender las ventajas y desventajas y tomar
decisiones sobre los riesgos de un proyecto. Es posible que un gerente no sea lo suficientemente
técnico para comprender por qué un módulo no funciona como se desea, pero comprenderá el riesgo
de falla y el ingeniero puede ayudarlo a evaluar la probabilidad y la gravedad del riesgo.
El concepto de riesgo se sitúa en el terreno común entre el mundo de la ingeniería y el mundo de la
gestión de proyectos. Los ingenieros pueden optar por ignorar la política de la oficina y las reuniones de
marketing, y los gerentes pueden optar por ignorar el esquema de la base de datos y las estimaciones
de rendimiento, pero en la idea de los riesgos encuentran un terreno común para tomar decisiones
sobre el sistema.
Riesgos integrados. Si nunca antes había visto un proceso de desarrollo de software, puede imaginar
que es como un ciclo de control en un programa, donde durante cada iteración prioriza los riesgos y
planifica el siguiente paso en consecuencia, en bucle hasta que se entrega el sistema. En la práctica,
algunos pasos de mitigación de riesgos se integran deliberadamente en el proceso de desarrollo de
software.
En una gran empresa preocupada por la coordinación del equipo, el proceso puede insistir en varias
formas de documentación en los hitos del proyecto. Los procesos ágiles generan preocupaciones sobre
el tiempo de comercialización y el rechazo del producto por parte del cliente y, en consecuencia, insisten
en que el software se construya y entregue en iteraciones cortas. Los procesos específicos de TI a
menudo enfrentan riesgos asociados con dominios desconocidos y complejos, por lo que sus procesos
pueden integrarse en la construcción de modelos de dominio. Cada vez que salgo de casa, palpo mis
bolsillos para asegurarme de que tengo mi billetera y las llaves porque es un riesgo suficiente para
adaptarse a mis hábitos.
Integrar técnicas de mitigación de riesgos en el proceso de desarrollo de software puede ser una
bendición. Es una bendición cuando el proceso incorpora riesgos que priorizaría de todos modos, por lo
que le ahorra el tiempo de todos los días decidiendo que, por ejemplo, debe ceñirse a iteraciones de
dos semanas en lugar de retrasarse en el cronograma. Es un medio eficiente de transmitir la experiencia
de los desarrolladores de software experimentados, porque pueden señalar los resultados exitosos de
seguir un proceso, en lugar de explicar su filosofía sobre el desarrollo de software que se incorporó. En
un método ágil como XP, un equipo que sigue el proceso puede tener éxito incluso si no entiende por
qué XP eligió su conjunto particular de técnicas.
Hornear riesgos en el proceso de desarrollo de software puede ser una maldición cuando se obtiene
3.9. COMPRENSIÓN DE LAS VARIACIONES DEL PROCESO 53
está mal. Hace muchos años, me entrevisté con una pequeña empresa nueva. El gerente de
proyecto, anteriormente en $BIGCOMPANY, me preguntó qué pensaba sobre el proceso y le dije
que debía ser apropiado para el proyecto, el dominio y el equipo.
Por encima de todo, dije, aplicar un proceso de un libro, inalterado, era poco probable que
funcionara. Como una escena de una comedia, giró en su silla y tomó un libro que describía el
proceso de desarrollo de $BIGCOMPANY y dijo: "Este es el proceso que seguiremos". No hace
falta decir que no terminé trabajando allí, pero desearía haber visto a los cinco ingenieros ubicados
en el mismo lugar produciendo documentos de diseño detallados y otra burocracia que se integra
en los procesos de equipos grandes y distribuidos.
Si decide adaptar su proceso de desarrollo de software a los riesgos internos, algunas
características importantes a considerar incluyen la complejidad del proyecto (grande, pequeño), el
tamaño del equipo (grande, pequeño), la ubicación (distribuida, coubicada), el dominio (TI, finanzas,
sistemas, embebidos, críticos para la seguridad, etc.), y tipo de cliente (interno, externo, retractilado).
3.9 Comprender las variaciones del proceso
Antes de que pueda ver cómo aplicar el modelo basado en riesgos a un proceso de desarrollo de
software, necesitará conocer las amplias categorías de procesos y algunos detalles sobre ellos.
Esta sección ofrece una descripción general que omite los detalles de cada proceso, pero
proporciona antecedentes adecuados para que pueda pensar en cómo aplicar el modelo basado en
el riesgo.
Esta descripción general ajusta cada proceso en una plantilla simple de dos partes: una parte
de diseño frontal opcional con una o más iteraciones que siguen. No todos los procesos de
desarrollo aquí tienen un diseño inicial, pero todos tienen al menos una iteración. La plantilla varía
en cuatro puntos:
1. ¿Existe un diseño inicial?
2. ¿Cuál es la naturaleza del diseño (planificado/evolutivo; rediseño permitido)?
3. ¿Cómo se prioriza el trabajo en las iteraciones?
4. ¿Cuánto dura una iteración?
La figura 3.4 resume los procesos y destaca algunas de sus diferencias.

Otros dos puntos de variación importantes que surgen cuando se habla del proceso de desarrollo
son: ¿qué tan detallados deben ser sus modelos de diseño y cuánto tiempo debe retener sus
modelos de diseño? Ninguno de los procesos anteriores se compromete con una respuesta para
estos, excepto XP, que permite el modelado pero desalienta mantener los modelos más allá de una
iteración. La aplicación de esta sencilla plantilla a los procesos de desarrollo de software produce
las siguientes descripciones:
Proceso Diseño inicial Naturaleza del diseño Priorización Iteración
de trabajo longitud
Cascada En fase de análisis y diseño Diseño planificado; sin Abierto Abierto
rediseño
Iterativo Opcional planeado o Abierto, a menudo Abierto,
evolutivo; rediseño centrado en funciones generalmente de 1
permitido a 8 semanas
Espiral Ninguna planeado o trabajo más arriesgado Abierto
evolutivo primero
ARRIBA / Opcional; actividades planeado o trabajo más arriesgado Generalmente
RUP de diseño con carga inicial evolutivo primero, 2-6 semanas
luego el valor más alto
XP Ninguno, pero algunos lo hacen Diseño evolutivo El valor más alto Generalmente
en la iteración cero. para el cliente primero 2-6 semanas
Figura 3.4: Ejemplos de procesos de desarrollo de software y cómo tratan los problemas de diseño. A efectos de comparación, un proceso
en cascada se trata como si tuviera una sola iteración larga.
Cascada. El proceso de cascada procede de principio a fin como un solo bloque largo de trabajo que
entrega todo el proyecto (Royce, 1970). Supone un trabajo de diseño planificado que se realiza en
sus fases de análisis y diseño. Estos preceden a la fase de construcción, que puede considerarse
una sola iteración. Con solo una iteración, el trabajo no se puede priorizar entre iteraciones, pero se
puede construir de forma incremental dentro de la fase de construcción. Aplicar el modelo basado en
el riesgo significaría hacer el trabajo de arquitectura principalmente durante las fases de análisis y
diseño.
Iterativo. Un proceso de desarrollo iterativo construye el sistema en múltiples bloques de trabajo,

llamados iteraciones (Larman y Basili, 2003). Con cada iteración, los desarrolladores pueden volver
a trabajar en partes existentes del sistema, por lo que no solo se construye de forma incremental.
El desarrollo iterativo opcionalmente tiene un trabajo de diseño inicial, pero no impone una priorización
en las iteraciones ni brinda orientación sobre la naturaleza del trabajo de diseño. Aplicar el modelo
basado en el riesgo significaría hacer el trabajo de arquitectura dentro de cada iteración y durante el
diseño inicial opcional.
Espiral. El proceso en espiral es una especie de desarrollo iterativo, por lo que tiene muchas
iteraciones, pero a menudo se describe como que no tiene un trabajo de diseño inicial (Boehm, 1988).
Las iteraciones se priorizan por riesgo, con la primera iteración manejando las partes más riesgosas
de un proyecto. El modelo en espiral maneja tanto los riesgos de gestión como los de ingeniería. Para
3.10. EL MODELO DIRIGIDO AL RIESGO Y LOS PROCESOS DE SOFTWARE 55
Oh
Figura 3.5: Un ejemplo de cómo la cantidad de diseño podría variar a lo largo de las iteraciones según
su percepción de los riesgos. Según la cantidad de tiempo invertido, puede inferir que el mayor riesgo
se percibió en la iteración 0 y la iteración 2.
por ejemplo, puede abordar la “escasez de personal” como un riesgo. El proceso en espiral no da ninguna
guía sobre cuánto trabajo de arquitectura/diseño hacer, o sobre qué técnicas de arquitectura y diseño
usar.
[Racional] Proceso Unificado (RUP). El Proceso Unificado y su especialización, el Proceso Unificado

Racional, son procesos iterativos en espiral (Jacobson, Booch y Rumbaugh, 1999; Kruchten, 2003).
Destacan la importancia de abordar los riesgos temprano y el uso de la arquitectura para abordar los
riesgos. El (R)UP aboga por trabajar primero en los requisitos relevantes desde el punto de vista
arquitectónico, en las primeras iteraciones. Puede adaptarse a un diseño planificado o evolutivo.
Programación Extrema (XP). La Programación Extrema es una especialización de un proceso de

desarrollo de software iterativo y ágil, por lo que contiene múltiples iteraciones (Beck y Andres, 2004).
Sugiere evitar el trabajo de diseño inicial, aunque algunos proyectos agregan una iteración cero (Schuh,
2004), en la que no se entrega ninguna funcionalidad visible para el cliente. Guía a los desarrolladores
para que apliquen exclusivamente el diseño evolutivo, aunque algunos proyectos lo modifican para
incorporar una pequeña cantidad de diseño inicial. Cada iteración se prioriza según la valoración de las
características del cliente, no los riesgos.
3.10 El modelo basado en riesgos y los procesos de software
Es posible aplicar el modelo basado en el riesgo a cualquiera de estos procesos de desarrollo de software
mientras se mantiene dentro del espíritu de cada uno. El proceso en cascada prescribe el diseño
planificado en sus fases de análisis y diseño, pero no le dice qué tipo de trabajo de arquitectura y diseño
hacer, o cuánto. Puede aplicar el modelo basado en riesgos durante las fases de análisis y diseño para
responder a esas preguntas.
El proceso iterativo no tiene un lugar designado para el trabajo de diseño, pero podría realizarse al
comienzo de cada iteración. La cantidad de tiempo dedicado al diseño variaría según los riesgos. La
Figura 3.5 proporciona un ejemplo teórico de cómo la cantidad de diseño podría variar entre las iteraciones
en función de su percepción de los riesgos.
El proceso en espiral y el modelo basado en el riesgo son primos en que el riesgo es primordial en
ambos. La diferencia es que el proceso en espiral, al ser un proceso completo de desarrollo de software,
prioriza los riesgos de gestión e ingeniería y guía lo que sucede.
plumas a través de las iteraciones. El modelo basado en riesgos solo guía el trabajo de diseño para mitigar los
riesgos de ingeniería, y solo dentro de una iteración. La aplicación del modelo basado en el riesgo al modelo en
espiral o al (R)UP funciona igual que con un proceso iterativo.
Habrá notado que, de los procesos enumerados en la Figura 3.4, XP (un proceso ágil) tiene el consejo más
específico. En consecuencia, es más complicado aplicar el modelo impulsado por el riesgo en el proceso XP (u
otros procesos ágiles centrados en características), por lo que analizaremos ese proceso con más profundidad.
3.11 Aplicación a procesos ágiles

La siguiente descripción del uso del modelo basado en riesgos en un proyecto ágil destaca algunos problemas
centrales, como cuándo diseñar y cómo combinar los riesgos en un proceso de desarrollo basado en funciones.
Dado que los proyectos ágiles varían en su proceso, esta descripción asume uno con una iteración de dos
semanas que juega un juego de planificación para administrar una acumulación de características. Por el lado de
la ingeniería, hay riesgos de arquitectura de software que debe incluir en este proceso, que incluye la identificación,
priorización, mitigación y evaluación de esos riesgos. Los grandes desafíos son: primero, cómo abordar los
riesgos de ingeniería iniciales y, segundo, cómo incorporar los riesgos de ingeniería que luego descubre en la pila
de trabajo por hacer.
Riesgos. Habrá identificado algunos riesgos al comienzo del proyecto, como las opciones iniciales para el estilo
arquitectónico, la elección de los marcos y la elección de otros componentes COTS (Commercial Off-The-Shelf).
Algunos proyectos ágiles usan una iteración cero para configurar su entorno de desarrollo, incluido el control del
código fuente y las herramientas de compilación automatizadas. Puede aprovechar aquí para comenzar a mitigar
los riesgos identificados. Los desarrolladores podrían tener una simple reunión de pizarra para asegurarse de que
todos estén de acuerdo con un estilo arquitectónico, o crear una lista corta de estilos para investigar. Si las
características de rendimiento de los componentes COTS son desconocidas pero importantes, se pueden realizar
algunos prototipos rápidos para proporcionar cifras aproximadas de velocidad o rendimiento.
Cartera de riesgos. Al final de una iteración, debe evaluar qué tan bien sus actividades mitigaron sus riesgos. La
mayoría de las veces habrá reducido un riesgo lo suficiente como para que desaparezca de su radar, pero a
veces no. Imagine que al final de la iteración ha aprendido que la creación de prototipos muestra que su base de
datos preferida se ejecutará con demasiada lentitud.
Este riesgo se puede escribir como una característica comprobable para el sistema. Este es el comienzo de una
cartera de riesgos. Siempre que sea posible, los riesgos deben escribirse como elementos comprobables.
Algunos riesgos son lo suficientemente pequeños como para que puedan manejarse a medida que surgen
durante una iteración y nunca aparecen en la cartera de pedidos. Pero los riesgos más grandes deberán
programarse al igual que las funciones.
Tenga en cuenta que esto no es una excusa para convertir una iteración nominal cero en un ejercicio inicial
de gran diseño de facto. En lugar de extender el tiempo de iteración cero, los riesgos son
3.11. APLICACIÓN A PROCESOS ÁGILES 57
Figura 3.6: Una forma de incorporar el riesgo en un proceso ágil es convertir la acumulación de características en una
acumulación de características y riesgos. El propietario del producto agrega funciones y el equipo de software agrega
riesgos técnicos. El equipo de software debe ayudar al propietario del producto a comprender los riesgos técnicos y
priorizar adecuadamente la acumulación.
empujado a la cartera de pedidos. Esto plantea una pregunta: ¿cómo podemos manejar tanto las funciones
atrasadas como los riesgos?
Priorización de riesgos y características. Muchos proyectos ágiles dividen el mundo en propietarios de

productos, que crean una lista priorizada de funciones denominada backlog, y desarrolladores, que toman las
funciones de la parte superior del backlog y las construyen.
Es tentador poner funciones y riesgos en el mismo backlog, pero administrar el backlog se vuelve más
complejo una vez que introduce riesgos, porque tanto las funciones como los riesgos deben priorizarse juntos.
¿Quién está calificado para priorizar ambos?
Si le otorga al propietario del producto la responsabilidad adicional de priorizar los riesgos arquitectónicos
junto con las características, simplemente puede cambiar la acumulación de características en una acumulación
de características y riesgos, como se ve en la Figura 3.6. Los desarrolladores de software pueden ver una
característica baja en la cartera de pedidos que solicita seguridad. Es su trabajo educar a los propietarios de
productos de que si alguna vez quieren tener una aplicación segura, deben abordar ese riesgo temprano, ya
que será difícil o imposible agregarla más tarde. Como parte de la reflexión al final de cada iteración, debe
evaluar los riesgos arquitectónicos e incluirlos en la cartera de pedidos.
Resumen. Un proceso ágil puede manejar los riesgos arquitectónicos haciendo tres cosas. Los riesgos
arquitectónicos que conoce de antemano se pueden manejar (al menos parcialmente) en una iteración cero con
límite de tiempo, en la que no se planea entregar características. Los pequeños riesgos arquitectónicos pueden
manejarse a medida que surgen durante las iteraciones. Y los grandes riesgos arquitectónicos deben promoverse
para que estén a la par con las características, e insertarse en una acumulación combinada de características y
riesgos.
3.12 Refactorización de riesgos y arquitectura
Con el tiempo, los desarrolladores de sistemas entienden cada vez mejor cómo debe diseñarse un
sistema. Esto es cierto independientemente del tipo de proceso que sigan (por ejemplo, cascada o
procesos iterativos). Al principio, saben y entienden menos. Después de algún trabajo (diseño, creación
de prototipos, iteraciones, etc.) tienen opiniones mejor fundamentadas sobre diseños adecuados.
Una vez que reconocen que su código no representa el mejor diseño (p. ej., al detectar los olores
del código), tienen dos opciones. Una es ignorar la divergencia, que genera deuda técnica. Si se permite
que se acumule, el sistema se convertirá en una gran bola de lodo (consulte la Sección 14.7). El otro es
refactorizar el código, lo que lo mantiene capaz de mantenerse. Esta segunda opción está bien descrita
por Brian Foote y William Opdyke en sus patrones sobre el ciclo de vida del software (Coplien y Schmidt,
1995).
Refactorizar, por definición, significa rediseñar y la escala de ese rediseño puede variar. A veces,
una refactorización implica solo un puñado de objetos o algún código localizado. Pero otras veces
implica cambios arquitectónicos más radicales y se denomina refactorización de la arquitectura. Dado
que existe poca guía publicada para la refactorización a gran escala, la refactorización de la arquitectura
generalmente se realiza ad hoc.
El ejemplo de la introducción donde Rackspace implementó su sistema de consulta de tres maneras
diferentes (consulte la Sección 1.2) se considera mejor como una refactorización de la arquitectura. Allí,
cada refactorización de la arquitectura fue precipitada por un riesgo de falla apremiante. Las
refactorizaciones a nivel de objeto toman una cantidad de tiempo insignificante y, por lo tanto, necesitan
poca justificación, por lo que debe continuar y, por ejemplo, cambiar el nombre de una variable para que
sea más expresiva de su intención. Una refactorización de arquitectura es costosa, por lo que requiere
un riesgo importante para justificarla.
Dos lecciones importantes son evidentes. En primer lugar, el diseño no ocurre exclusivamente por
adelantado. A menudo es razonable dedicar tiempo por adelantado a tomar las mejores decisiones
posibles, pero es optimista pensar que sabe lo suficiente para tomar todas las decisiones de diseño correctas.
Debe anticipar pasar tiempo diseñando después del inicio de su proyecto.
En segundo lugar, el riesgo de falla puede guiar la refactorización de la arquitectura. En el momento
en que se implementa, casi todos los sistemas están desactualizados en comparación con el mejor
pensamiento de sus desarrolladores. Es decir, existe cierta deuda técnica. Tal vez, en retrospectiva,
desearía haber elegido una arquitectura diferente. Los riesgos pueden ayudarlo a decidir qué tan malo
será si mantiene su arquitectura actual.
3.13 Alternativas al modelo basado en riesgos
El modelo basado en el riesgo hace dos cosas: lo ayuda a decidir cuándo puede dejar de hacer
arquitectura y lo guía a las actividades de arquitectura apropiadas. No es bueno para predecir cuánto
tiempo pasarás diseñando, pero te ayuda a reconocer cuándo
3.13. ALTERNATIVAS AL MODELO DIRIGIDO AL RIESGO 59
haber hecho suficiente. Existen varias alternativas al modelo basado en el riesgo, con sus propias ventajas y
desventajas.
Sin diseño. La opción de no diseñar es un nombre poco apropiado, especialmente si crees que cada sistema
tiene una arquitectura, porque los desarrolladores deben haberlo pensado en algún momento. Tal vez estaban
pensando en el diseño (es decir, lo que codificarán) inmediatamente antes de comenzar a escribir, pero
piensan en el diseño.
Es probable que dichos proyectos tomen mucho prestado de arquitecturas presuntas (consulte la Sección
2.4), donde los desarrolladores diseñan su sistema a partir de sistemas exitosos similares, explícita o
implícitamente.
Paquete de documentación. Algunas personas sugieren, o al menos dan a entender, que debe crear un
paquete de documentación completo que describa su arquitectura. Si sigue esta guía, creará un conjunto de
modelos y diagramas y los escribirá de tal manera que otra persona pueda leer y comprender la arquitectura,
lo que puede ser muy deseable. Si necesita documentación, el libro Documenting Software Architectures
(Clements et al., 2010) lo guiará a un conjunto efectivo de modelos y diagramas para registrar.
Sin embargo, pocos proyectos necesitarán crear un paquete completo de documentación, y el

El inicio de “3 chicos en un garaje” probablemente no pueda darse el lujo de escribir nada.
Criterios. Los datos empíricos pueden ayudarlo a decidir cuánto tiempo debe dedicarse a la arquitectura y el
diseño. Barry Boehm ha calculado la cantidad óptima de tiempo para dedicar a la arquitectura de proyectos
pequeños, medianos y grandes basándose en una variante de su modelo COCOMO (Boehm y Turner, 2003).
Para varios tamaños de proyectos, ha trazado curvas de esfuerzo arquitectónico frente a la duración total del
proyecto. Sus datos indican que la mayoría de los proyectos deberían dedicar entre el 33 % y el 37 % de su
tiempo total a la arquitectura, los proyectos pequeños dedican tan solo el 5 % y los proyectos muy grandes el
40 %.
Los gerentes de proyecto pueden usar un criterio como "dedicar el 33% de su tiempo a la arquitectura"
para planificar las actividades del proyecto y los requisitos de personal, lo que genera un presupuesto de
tiempo para dedicarlo al diseño.
Los criterios, sin embargo, son de poca ayuda para los desarrolladores una vez que ha comenzado el
trabajo de arquitectura. Ningún desarrollador razonable debe continuar con las actividades de diseño durante
días adicionales después de que se hayan resuelto los riesgos, incluso si el criterio proporciona ese presupuesto.
Un desarrollador razonable tampoco debería cambiar a la codificación cuando existe un riesgo de falla
importante.
Lo mejor es ver estos criterios como heurísticas derivadas de la experiencia en la lucha contra los riesgos,
donde los proyectos de cierto tamaño históricamente necesitaron tanto tiempo para mitigar sus riesgos. Ese
criterio no te ayuda a decidir si es apropiado un día más (o uno menos) de trabajo de arquitectura. Además,
los criterios solo sugieren actividades categóricas amplias en lugar de guiarlo a técnicas particulares.
Ad hoc. Al elegir cuánta arquitectura hacer, la mayoría de los desarrolladores probablemente no sigan ninguna
de las alternativas anteriores. En su lugar, toman una decisión en el momento, según su experiencia y su mejor
comprensión de las necesidades del proyecto.
De hecho, esta puede ser la forma más efectiva de proceder, pero depende de la habilidad y la experiencia
del desarrollador. No se puede enseñar, ya que sus lecciones no son explícitas, ni es particularmente útil para
crear estimaciones de planificación de proyectos. Puede ser que, en la práctica, el enfoque ad hoc sea una
especie de modelo informal impulsado por el riesgo, donde los desarrolladores sopesan tácitamente los riesgos
y eligen las técnicas apropiadas.
3.14 Conclusión
Este capítulo se propuso investigar dos cuestiones. Primero, ¿qué técnicas de diseño y arquitectura deberían
usar los desarrolladores? Y segundo, ¿cuánto diseño y arquitectura deben hacer los desarrolladores? Revisó las
respuestas existentes, incluida la ausencia de diseño, el uso de criterios, la creación de paquetes de
documentación y el procedimiento ad hoc. Introdujo el modelo basado en riesgos que alienta a los desarrolladores
a: (1) priorizar los riesgos que enfrentan, (2) elegir técnicas de arquitectura apropiadas para mitigar esos riesgos
y (3) reevaluar los riesgos restantes. Fomenta el diseño y la arquitectura lo suficiente al guiar a los desarrolladores
a un subconjunto priorizado de actividades de arquitectura. El diseño puede suceder por adelantado, pero
también sucede durante un proyecto.
El modelo basado en el riesgo está inspirado en el trabajo de mi padre en su buzón. No realizó cálculos
complejos, simplemente colocó el poste en el agujero y luego lo llenó con concreto. Los proyectos de bajo riesgo
pueden tener éxito sin ningún trabajo de arquitectura planificado, mientras que muchos de alto riesgo fracasarían
sin él.
El modelo impulsado por el riesgo recorre un camino intermedio que evita los extremos de los paquetes
completos de documentación de la arquitectura y la evasión de la arquitectura. Sigue el principio de que sus
esfuerzos de arquitectura deben ser proporcionales al riesgo de fracaso.
Evitar fallas es fundamental para toda la ingeniería y puede usar técnicas de arquitectura para mitigar los riesgos.
El elemento clave del modelo impulsado por el riesgo es la promoción del riesgo a la prominencia. Cada proyecto
tendrá un conjunto diferente de riesgos, por lo que probablemente necesite un conjunto diferente de técnicas.
Para evitar perder su tiempo y dinero, debe elegir las técnicas que mejor reduzcan su lista priorizada de riesgos.
La cuestión de cuánto trabajo de arquitectura de software debe hacer ha sido espinosa durante mucho
tiempo. El modelo basado en el riesgo transforma esa pregunta amplia en una más específica: "¿Las técnicas
elegidas han reducido suficientemente los riesgos de falla?"
La evaluación de la mitigación de riesgos sigue siendo subjetiva, pero es algo sobre lo que los desarrolladores
pueden tener una conversación enfocada.
Las técnicas de ingeniería abordan los riesgos de ingeniería, pero los proyectos enfrentan una amplia
variedad de riesgos. Los procesos de desarrollo de software deben priorizar tanto los riesgos de gestión como
los riesgos de ingeniería. No se pueden reducir los riesgos de ingeniería a cero porque no
3.15. OTRAS LECTURAS 61
también son riesgos de gestión de proyectos a considerar, incluida la presión del tiempo de
comercialización. Al aplicar el modelo basado en riesgos, se asegura de que cualquier tiempo que dedique
a la arquitectura de software reduzca sus riesgos de ingeniería de mayor prioridad y aplique técnicas
relevantes.
Los enfoques ágiles de desarrollo de software a menudo enfatizan el diseño evolutivo sobre el diseño
planificado. Se puede utilizar un camino intermedio, un diseño planificado mínimo, para evitar los
extremos. La tensión esencial es la siguiente: una larga ventaja inicial en el diseño arquitectónico brinda
oportunidades para garantizar propiedades globales, evitar callejones sin salida en el diseño y coordinar
subequipos, pero se produce a expensas de la posibilidad de cometer errores que se evitarían si las
decisiones se tomaran más tarde. . Los procesos ágiles que se centran en las funciones se pueden
adaptar ligeramente para agregar riesgo a la acumulación de funciones, y los desarrolladores educan a
los propietarios de productos sobre cómo priorizar la acumulación de funciones y riesgos.
Algunos lectores pueden sentirse frustrados porque este capítulo no prescribe una lista de técnicas
a utilizar y un solo proceso a seguir. Estos faltan porque las técnicas que funcionan muy bien en un
proyecto serían inapropiadas en otro. Y aún no hay suficientes datos para superar las opiniones sobre el
mejor proceso a recomendar. De hecho, es posible que no pueda elegir qué proceso seguir, pero dentro
de ese proceso es probable que tenga la capacidad de utilizar el modelo basado en el riesgo. Este
capítulo ha tratado de proporcionar información relevante sobre cómo tomar sus propias decisiones para
que pueda hacer suficiente arquitectura para sus proyectos.
3.15 Lectura adicional

La invención del riesgo como concepto probablemente ocurrió bastante temprano, con referencias a él en
la antigüedad griega, pero adquirió su idea moderna y más general en una fecha tan tardía como el siglo
XVII, donde desplazó cada vez más el concepto de fortuna como lo que impulsaba la vida. resultados
(Luhmann, 1996). Unos minutos después de eso, los gerentes de proyecto comenzaron a utilizar el riesgo
para impulsar sus proyectos. Esta larga tradición en la gestión de proyectos se ha trasladado al diseño
de procesos de software, y muchos autores enfatizan el papel del riesgo en el desarrollo de software,
incluidos Philippe Kruchten (Kruchten, 2003), Ivar Jacobson, Grady Booch y James Rumbaugh (Jacobson,
Booch y Rumbaugh ). , 1999), y señalando específicamente la conexión entre arquitectura y riesgo.
Barry Boehm escribió sobre el riesgo en el contexto del desarrollo de software con su artículo sobre
el modelo en espiral del desarrollo de software (Boehm, 1988), que es una lectura interesante incluso si
ya comprende el modelo. El modelo impulsado por el riesgo, a primera vista, parecería bastante similar
al modelo en espiral del desarrollo de software, pero el modelo en espiral se aplica a todo el proceso de
desarrollo, no solo a la actividad de diseño. Un solo giro a través de la espiral tiene un equipo que analiza,
diseña, desarrolla y prueba el software. La espiral completa cubre el proyecto desde el inicio hasta el
despliegue.
Sin embargo, el modelo basado en el riesgo se aplica solo al diseño y puede incorporarse a
casi cualquier proceso de desarrollo de software. Además, el modelo en espiral guía a un equipo
para que construya primero las partes más riesgosas, pero no los guía a actividades de diseño
específicas. Tanto el modelo en espiral como el modelo basado en el riesgo están muy de acuerdo
en su promoción del riesgo a una posición de prominencia.
Barry Boehm y Richard Turner continuaron con un libro sobre riesgos y procesos ágiles
(Boehm y Turner, 2003). El resumen de su juicio es: "La esencia de usar el riesgo para equilibrar
la agilidad y la disciplina es aplicar una pregunta simple a casi todas las facetas del proceso dentro
de un proyecto: ¿Es más riesgoso para mí aplicar (más de) este componente del proceso o
abstenerse de aplicarlo?
Mark Denne y Jane Cleland-Huang analizan tanto la arquitectura como el riesgo en el contexto
de la gestión de proyectos de software (Denne y Cleland-Huang, 2003). Abogan por la gestión de
proyectos fragmentando el desarrollo en características mínimas comercializables, lo que tiene
como consecuencia la construcción incremental de su arquitectura.
El modelo basado en el riesgo es similar al análisis global descrito por Christine Hofmeister,
Robert Nord y Dilip Soni (Hofmeister, Nord y Soni, 2000). El análisis global consta de dos pasos:
(1) analizar los factores organizativos, técnicos y de producto; y (2) desarrollar estrategias. Los
factores y estrategias en el análisis global se asignan a los riesgos y actividades en el modelo
basado en el riesgo. Los factores son más amplios que los riesgos técnicos en el modelo basado
en el riesgo y podrían incluir, por ejemplo, preocupaciones sobre el número de empleados.
Tanto el análisis global como el modelo basado en el riesgo son similares en el sentido de que
externalizan un proceso de pensamiento estructurado de la forma: Estoy haciendo X porque Y
podría causar problemas. En las descripciones publicadas, la intención del análisis global no es
optimizar la cantidad de esfuerzo dedicado a la arquitectura, sino garantizar que se hayan
investigado todos los factores.
Dos publicaciones del SEI pueden ayudarlo a ser más consistente y completo en su
identificación y explicación de los riesgos. Carr et al. (1993) describen un método basado en
taxonomía para identificar riesgos y Gluch (1994) introduce el formato condición-transición-
consecuencia para describir riesgos.
El modelo basado en el riesgo aboga por la construcción de modelos de arquitectura limitados
que tienen detalles solo donde se perciben los riesgos. De manera similar, los autores han
defendido la construcción de modelos mínimamente suficientes durante años, incluidos Desmond
D'Souza, Alan Wills y Scott Ambler (D'Souza y Wills, 1998; Ambler, 2002). En Fairbanks, Bierhoff y
D'Souza (2006) se analiza la adaptación de los modelos construidos en un proyecto a la naturaleza
del proyecto (greenfield, brownfield, coordinación, mejora ).
La idea de las técnicas o tácticas de catalogación se describe en el contexto del diseño
impulsado por los atributos en Bass, Clements y Kazman (2003). El diseño basado en atributos
(ADD) se basa en un mapeo de los atributos de calidad a las tácticas (discutido en la Sección
11.3.4), muy parecido al análisis global. El concepto de este libro de técnicas de desarrollo de
mapas es de naturaleza similar. ADD guía a los desarrolladores hacia un diseño apropiado (un
patrón), mientras que el modelo basado en el riesgo guía a los desarrolladores hacia una actividad, como el desempeñ
modelado de mance o análisis de dominio. Se puede considerar que el modelo basado en el riesgo toma
la promoción del riesgo del modelo en espiral y adapta el mapeo tabular de ADD para mapear los riesgos
a las técnicas.
Saber qué tácticas o técnicas aplicar sería un conocimiento valioso para incluir en un manual de
arquitectura de software y aceleraría el aprendizaje de los desarrolladores novatos. Tal conocimiento ya
está en la cabeza de los virtuosos, como lo describen Mary Shaw y David Garlan (Shaw y Garlan, 1996).
Cuanto mejor codifica nuestro campo este conocimiento, más compacto se vuelve y más rápido la próxima
generación de desarrolladores lo absorbe y ve más allá.
Aunque las tácticas y técnicas se describieron en este capítulo como tablas, podrían expresarse
como un lenguaje de patrones, tal como lo describió originalmente Christopher Alexander para el dominio
de los edificios (Alexander, 1979; Alexander, 1977), y luego se adaptó al software en el Diseño. Libro de
patrones (Gamma et al., 1995) de Erich Gamma y otros.
El ensayo de Martin Fowler, “¿Está muerto el diseño?” (Fowler, 2004) proporciona una introducción
muy amena al diseño evolutivo y las prácticas ágiles que se requieren para que funcione.
La fusión del desarrollo de software basado en riesgos y los procesos ágiles es un área de
investigación abierta. La tesis de Jaana Nyfjord (Nyfjord, 2008) propone la creación de un Foro de Gestión
de Riesgos para priorizar el riesgo entre productos y proyectos en una organización. Dado que el objetivo
aquí es manejar los riesgos de la arquitectura que son solo un subconjunto de todos los riesgos del
proyecto, un cambio más pequeño en el proceso puede funcionar.
Este libro utiliza el riesgo para ayudarlo a decidir qué técnicas usar y cuántas aplicar, asumiendo que
los requisitos no son negociables. Otra forma de usarlo es ayudar a determinar el alcance de los proyectos,
suponiendo que los requisitos se puedan cambiar. Tal técnica cuantitativa se describe en Feather y Hicks
(2006), con el resultado de una bolsa de requisitos que le brinda el mayor beneficio por el riesgo que
asume.
Dado que muchos desarrolladores buscan procesos más livianos, el desarrollo ágil es popular.
Ambler (2009) brinda una descripción general de cómo la arquitectura puede entretejerse en procesos
ágiles, y Fowler (2004) analiza cómo el diseño evolutivo puede complementar el diseño planificado.
Boehm y Turner (2003) discuten la tensión entre moverse rápido y hacerlo bien. Un tratamiento completo
de un proceso práctico para la arquitectura de software se encuentra en (Eeles y Cripps, 2009).
Capítulo 7
Modelo Conceptual de Software

Arquitectura
En la introducción de este libro, leíste una historia sobre un entrenador y un novato viendo el
mismo juego. Ambos vieron que sucedían las mismas cosas en el campo, pero a pesar de que
los ojos del novato eran más jóvenes y más agudos, el entrenador entendió y evaluó mejor la
acción. Como desarrollador de software, le gustaría entender y evaluar el software con la
misma eficacia con la que el entrenador entiende el juego. Este capítulo y los subsiguientes lo
ayudarán a construir una representación mental de cómo funciona la arquitectura del software
para que cuando vea el software lo entienda mejor y lo diseñe mejor.
Sin embargo, la idea de usar modelos a menudo se confunde erróneamente con la elección
del proceso de software (es decir, cascada) y se ha asociado con la parálisis del análisis. Este
libro no recomienda la construcción de muchos modelos escritos (es decir, documentación) por
adelantado, por lo que es mejor derribar algunos argumentos falsos o malentendidos:
• Todo proyecto debe documentar su arquitectura: Falso. Debe hacer planes antes de
emprender un viaje por carretera, pero ¿planea su viaje al trabajo por la mañana? Los
modelos lo ayudan a resolver problemas y mitigar riesgos, pero mientras algunos
problemas se resuelven mejor con modelos, otros se pueden resolver directamente.
• Los documentos de arquitectura deben ser completos: Falso. Puede decidir crear un
documento de arquitectura amplio, o incluso uno integral, pero solo en algunas
circunstancias, tal vez para comunicar un diseño a otros. Más
112 CAPÍTULO 7. MODELO CONCEPTUAL DE ARQUITECTURA DE SOFTWARE
a menudo, puede modelar solo las partes que se relacionan con sus riesgos, por lo que un proyecto
con riesgos de escalabilidad crearía un modelo limitado centrado en la escalabilidad.
• El diseño siempre debe preceder a la codificación: Falso. En cierto sentido, esto es cierto, porque
el código no fluye de tus dedos hasta que hayas pensado en lo que construirás. Pero es falso creer
que una fase de diseño (en el sentido del proceso de software) debe preceder a la codificación. De
hecho, la codificación temprana puede ayudarlo a descubrir los problemas más difíciles.
Así que deberías dejar de lado estas ideas de testaferros. La verdadera razón para usar modelos de
arquitectura de software es que te ayudan a desempeñarte como el entrenador, no como el novato. Si aún
no está en el nivel de entrenador, quiere llegar lo antes posible. Los modelos de arquitectura estándar
representan un cuerpo de conocimiento condensado que le permite aprender de manera eficiente sobre la
arquitectura y el diseño del software. Posteriormente, encontrará que tener un modelo estándar libera su
mente para concentrarse en el problema en cuestión en lugar de inventar un nuevo tipo de modelo para
cada problema.
Los modelos conceptuales aceleran el aprendizaje. Si desea volverse tan efectivo como un entrenador,
simplemente puede trabajar en un software y esperar hasta que sea viejo. Eventualmente, todos los
desarrolladores de software aprenden algo sobre arquitectura, incluso si se acercan sigilosamente a ese
conocimiento indirectamente. Solo se necesita práctica, práctica y práctica en la construcción de sistemas.
Sin embargo, hay varios problemas con ese enfoque. Primero, no todos los desarrolladores de software
antiguos son los más efectivos. En segundo lugar, el enfoque lleva décadas. Y tercero, su comprensión de
la arquitectura será idiosincrásica, por lo que tendrá dificultades para comunicarse con los demás, y
viceversa.
Considere otro camino, uno en el que vea más lejos al pararse sobre los hombros de los demás. Tal
vez todavía estemos esperando al Isaac Newton de la ingeniería de software, pero hay mucho que aprender
de quienes han creado software antes que nosotros. No solo nos han dado cosas tangibles como
compiladores y bases de datos, también nos han dado un conjunto de abstracciones para pensar en
programas. Algunas de estas abstracciones se han integrado en nuestros lenguajes de programación:
funciones, clases, módulos, etc. Es probable que otras lo sean, como componentes, puertos y conectores1 .
Algunas personas nacen brillantes, pero para aquellos de nosotros que no lo somos, ¿qué tan efectivo
es pararse sobre los hombros de quienes nos precedieron? Considere esto: usted es probablemente mejor
matemático que todos menos un puñado de personas en el siglo XVII. Entonces, como ahora, los virtuosos
de las matemáticas tenían talento y practicaban mucho, pero hoy tienes el beneficio de siglos de
comprensión compacta. Cuando terminas la escuela secundaria, resuelves problemas matemáticos que
requerían de un virtuoso hace unos cientos de años.
Y antes de eso, los virtuosos del siglo XVII tuvieron la ventaja de que alguien más inventó el sistema
numérico posicional y el concepto de cero. como usted considera
1Los lenguajes de investigación como ArchJava ya han agregado estos conceptos a Java.
113
los dos caminos, recuerda que puedes y debes hacer ambos: aprender la comprensión condensada
de la arquitectura y luego practicar, practicar, practicar.
Los modelos conceptuales liberan la mente. Una comprensión condensada puede tomar la forma
de un modelo conceptual. El modelo conceptual del entrenador incluye cosas como estrategias,
posiciones y jugadas de ataque y defensa. Cuando observa el movimiento de los jugadores en el
campo, clasifica lo que ve de acuerdo con su modelo conceptual. Él ve el movimiento de un jugador
como algo más que eso: es un elemento de una jugada, que es parte de una estrategia. El novato,
con su modelo conceptual limitado, ve menos de esto.
Los modelos conceptuales aceleran el progreso en muchos campos. Si alguna vez estudiaste
física, es posible que hayas olvidado la mayoría de las ecuaciones que aprendiste, pero aún
concebirás las fuerzas que actúan sobre los cuerpos. Las lecciones de su profesor de física fueron
diseñadas para inculcar ese modelo conceptual. Del mismo modo, si alguna vez ha estudiado
patrones de diseño, no podrá evitar reconocer esos patrones en los programas que encuentre.
Un modelo conceptual puede ahorrarle tiempo gracias a un reconocimiento y una coherencia más
rápidos, y puede ampliar su razonamiento. Alfred Whitehead, dijo: “Al liberar al cerebro de todo el
trabajo innecesario, una buena notación lo libera para concentrarse en problemas más avanzados y,
de hecho, aumenta el poder mental de la raza”. (Whitehead, 1911) Esto se aplica igualmente a los
modelos conceptuales. Como se mencionó en la introducción, Alan Kay ha observado que un “punto
de vista vale 80 puntos de CI”, continuando diciendo que la razón principal por la que somos mejores
ingenieros que en la época romana es porque tenemos mejores representaciones de problemas (Kay,
1989). ).
Existe un consenso general sobre los elementos y técnicas esenciales para el modelado de
arquitectura, aunque diferentes autores enfatizan diferentes partes. Por ejemplo, el Instituto de
Ingeniería de Software (SEI) enfatiza las técnicas para el modelado de atributos de calidad (Bass,
Clements y Kazman, 2003; Clements et al., 2010). El campo del lenguaje de modelado unificado
(UML) enfatiza las técnicas para el modelado funcional (D'Souza y Wills, 1998; Cheesman y Daniels,
2000). El modelo conceptual de este libro integra modelos funcionales y de atributos de calidad.
Objetivos y organización del capítulo. El objetivo de esta parte del libro es proporcionarle un
modelo conceptual de arquitectura de software, uno que le permita dar sentido rápidamente al
software que ve y razonar sobre el software que diseña. El modelo conceptual incluye un conjunto de
abstracciones, formas estándar de organizar modelos y conocimientos. Nunca serás bueno en nada
sin talento y práctica, pero puedes acelerar tu progreso construyendo un modelo conceptual mental.
Este capítulo le muestra cómo dividir su arquitectura en tres modelos principales: el dominio, el
diseño y el código. Relaciona estos modelos usando relaciones de designación y refinamiento.
Dentro de cada modelo, los detalles se muestran mediante vistas. Los tres capítulos que siguen a
este examinan los modelos de dominio, diseño y código con más detalle. Un sistema de ejemplo para
un sitio web llamado Yinzer se ejecuta en todo momento. Un Yinzer es un
término de la jerga para alguien de Pittsburgh, sede de la Universidad Carnegie Mellon, y se deriva de yinz,
que es el dialecto de Pittsburgh equivalente a todos ustedes.
Yinzer ofrece a sus miembros servicios de redes sociales comerciales en línea y anuncios
de empleo en el área de Pittsburgh. Los miembros pueden agregar a otros miembros como
contactos comerciales, publicar anuncios de trabajos, recomendar un contacto para un trabajo
y recibir notificaciones por correo electrónico sobre trabajos coincidentes.
Los capítulos posteriores cubren otros detalles sobre el modelado y brindan consejos sobre cómo usar los
modelos de manera efectiva.
7.1 Estructura del modelo canónico
Una vez que comience a construir modelos, hay muchos fragmentos para realizar un seguimiento. Si ve un
diagrama de clases UML para el sistema Yinzer que muestra un anuncio de trabajo asociado con una
empresa, querrá saber qué representa: ¿son cosas del mundo real, su diseño o tal vez incluso el esquema
de su base de datos? Necesitas una organización que te ayude a clasificar esos fragmentos en los lugares
correctos y darle sentido a todo.
La estructura del modelo canónico que se presenta aquí le brinda una forma estándar de organizar y
relacionar los hechos que encuentra y los modelos que construye. No siempre construirá modelos que
cubran toda la estructura del modelo canónico, pero la mayoría de los proyectos con el tiempo tendrán
fragmentos de modelos que siguen la estructura canónica.
7.1.1 Resumen
La esencia de la estructura del modelo canónico es simple: sus modelos van desde abstractos a concretos,
y utiliza vistas para profundizar en los detalles de cada modelo.
Hay tres modelos principales: el modelo de dominio, el modelo de diseño y el modelo de código, como
se ve en la Figura 7.1. La estructura del modelo canónico tiene el modelo más abstracto (el dominio) en la
parte superior y el más concreto (el código) en la parte inferior.
Las relaciones de designación y refinamiento aseguran que los modelos se correspondan, pero les permiten
diferir en su nivel de abstracción.
Cada uno de los tres modelos primarios (los modelos de dominio, diseño y código) son como bases de
datos en el sentido de que son completos, pero por lo general son demasiado grandes y detallados para
trabajar en ellos directamente. (Más sobre esto en breve, en la Sección 7.4). Las vistas le permiten
seleccionar solo un subconjunto de los detalles de un modelo. Por ejemplo, puede seleccionar solo los
detalles sobre un solo componente o solo las dependencias entre módulos. Sin duda, ha trabajado antes
con vistas, como un diccionario de datos o un diagrama de contexto del sistema. Las vistas le permiten
relacionar estas listas y diagramas con la estructura del modelo canónico. Organizar los modelos en la
estructura canónica ayuda a la categorización y simplificación.
7.2. MODELOS DE DOMINIO, DISEÑO Y CÓDIGO 115
La estructura del modelo canónico clasifica diferentes tipos de hechos en diferentes modelos. Los
datos sobre el dominio, el diseño y el código van en sus propios modelos. Cuando encuentra un hecho
de dominio como "los ciclos de facturación son de 30 días", un hecho de diseño como "los recursos de
fuente siempre deben desasignarse explícitamente" o un hecho de implementación como "la dirección
del cliente se almacena en un campo varchar (80), Es fácil clasificar estos detalles en un modelo mental
existente.
La estructura del modelo canónico reduce el tamaño de cada problema. Cuando desea razonar
sobre un problema de dominio, los detalles del código no lo distraen, y viceversa, lo que hace que cada
uno sea más fácil de razonar.
Primero echemos un vistazo a los modelos de dominio, diseño y código antes de centrar nuestra
atención en las relaciones entre ellos.
7.2 Modelos de dominio, diseño y código
El modelo de dominio describe verdades perdurables sobre el dominio; el modelo de diseño describe el
sistema que construirá; y el modelo de código describe el código fuente del sistema. Si algo es
"simplemente cierto", entonces probablemente va en el modelo de dominio; si algo es una decisión de
diseño o un mecanismo que usted diseña, entonces probablemente va en el modelo de diseño; y si algo
está escrito en un lenguaje de programación, o es un modelo en ese mismo nivel de abstracción,
entonces va en el modelo de código. La Figura 7.1 muestra gráficamente los tres modelos y resume el
contenido de cada uno.
modelo de dominio. El modelo de dominio expresa verdades perdurables sobre el mundo que son
relevantes para su sistema. Para el sistema Yinzer, algunas verdades relevantes incluirían definiciones
de tipos importantes como anuncios y contactos, relaciones entre esos tipos y comportamientos que
describen cómo cambian los tipos y las relaciones con el tiempo. En general, el dominio no está bajo tu
control, por lo que no puedes decidir que las semanas tengan seis días o que tengas una fiesta de
cumpleaños todas las semanas.
modelo de diseño. Por el contrario, el diseño está en gran medida bajo su control. El sistema a construir
no aparece en el modelo de dominio, pero hace su aparición en el modelo de diseño. El modelo de
diseño es un conjunto parcial de compromisos de diseño. Es decir, dejas sin decidir algunos detalles
(generalmente de bajo nivel) sobre cómo funcionará el diseño, aplazándolos hasta el modelo de código.
El modelo de diseño se compone de modelos de límites anidados recursivamente y modelos

internos. Un modelo de límites y un modelo de componentes internos describen lo mismo (como un
componente o un módulo), pero el modelo de límites solo menciona la interfaz públicamente visible,
mientras que el modelo de componentes internos también describe el diseño interno.
modelo de código. El modelo de código es la implementación del código fuente del sistema o un
modelo equivalente. Podría ser el código Java real o el resultado de
%
en
!
en
!"
#
"
PS
% & '
Figura 7.1: La estructura del modelo canónico que organiza los modelos de dominio, diseño y código.
El modelo de diseño contiene un modelo de límites de nivel superior y modelos internos anidados recursivamente.
ejecutando una herramienta de código a UML, pero su característica importante es que tiene un conjunto completo de diseño
compromisos
Los modelos de diseño a menudo omiten descripciones de partes de bajo riesgo sabiendo que el diseño
es suficiente siempre que el desarrollador comprenda el diseño y la arquitectura en general.
Pero donde el modelo de diseño tiene un conjunto incompleto de compromisos de diseño, el código
modelo tiene un conjunto completo, o al menos un conjunto suficientemente completo para ejecutar en un
máquina.
7.3 Relaciones de designación y refinamiento
Sin duda tiene un sentido intuitivo de cómo el dominio se relaciona con el diseño y
cómo el diseño se relaciona con el código. Debido a que este capítulo busca dividir los modelos
y relacionarlos, es una buena idea examinar estas relaciones cuidadosamente para que usted
puede entenderlos completamente.
Designacion. La relación de designación te permite decir que cosas similares en

diferentes modelos deben corresponder. Usando el ejemplo de Yinzer, el modelo de dominio
describe verdades de dominio, como personas que construyen una red de contactos y empresas que publican
anuncios. Usando la relación de designación, estas verdades se trasladan al
diseño, como se ve en la Figura 7.2.
7.3. RELACIONES DE DESIGNACIÓN Y REFINAMIENTO 117
en
Figura 7.2: La relación de designación garantiza que los tipos que elija del dominio se correspondan
con los tipos o estructuras de datos de su diseño.
Tiene margen de maniobra en su diseño, pero no debe violar las verdades del dominio. Puede
designar que los tipos seleccionados del dominio se correspondan con los tipos y estructuras de datos
del diseño. Las cosas que no designas no están restringidas.
Si bien en la práctica la relación de designación rara vez se escribe con precisión, sería un mapeo
que definiera la correspondencia entre los elementos del dominio (p. ej., Tipos de anuncios y trabajos) y
los elementos de diseño (p. ej., Tipos de anuncios y trabajos y estructuras de datos).
Quizás sorprendentemente, el diseño rara vez es 100% consistente con el dominio porque los
sistemas a menudo usan una versión simplificada o restringida de los tipos de dominio. Por ejemplo, es
posible que el sistema no se dé cuenta de que la misma persona lee el correo electrónico en dos
direcciones de correo electrónico diferentes y, por lo tanto, podría considerarlas dos personas diferentes.
O el sistema puede restringir los tipos de dominio, como limitar la cantidad de contactos que una persona
puede tener en el sistema. Pero cuando se interrumpe la correspondencia con el dominio, a menudo surgen errores.
La relación de designación se cubre con más detalle en la Sección 13.6.
Refinamiento. El refinamiento es una relación entre un modelo de bajo detalle y uno de alto detalle de
la misma cosa. Se utiliza para relacionar un modelo de límites con un modelo de interiores, ya que
ambos son modelos de lo mismo, pero varían en los detalles que exponen. El refinamiento es útil porque
le permite descomponer su diseño en partes más pequeñas. Tal vez el sistema Yinzer se compone de
un cliente y una pieza de servidor, y el servidor se compone de varias piezas más pequeñas. El
refinamiento se puede utilizar para ensamblar estas partes en un todo, y viceversa. La mecánica del
refinamiento se analiza en profundidad en la Sección 13.7.
El refinamiento también se usa para relacionar el modelo de diseño con el modelo de código, pero
no es tan sencillo. Los elementos estructurales del modelo de diseño se corresponden claramente con
los elementos estructurales del modelo de código. Por ejemplo, un módulo en el diseño se asigna a
paquetes en el código y un componente en el diseño se asigna a un conjunto de clases en el código.
Oh
Oh
Figura 7.3: La relación de refinamiento garantiza que los tipos que elija del dominio se correspondan
con los tipos o estructuras de datos de su diseño. Tenga en cuenta que hay elementos en el diseño
(invariantes, restricciones, estilos) que no se pueden expresar en lenguajes de programación.
Sin embargo, como se muestra en la Figura 7.3, otras partes del modelo de diseño están
ausentes en el modelo de código: invariantes, restricciones y estilos arquitectónicos. Esencialmente,
ningún lenguaje de programación convencional puede expresar directamente las restricciones del
modelo de diseño. Es cierto que las restricciones como "todas las solicitudes web deben completarse
en 1 segundo" o "adherirse al estilo de tubería y filtro" pueden ser respetadas por el código, pero no
pueden expresarse directamente. Esta brecha entre el diseño y los modelos de código se analiza
con mayor profundidad en la Sección 10.1.
7.4 Vistas de un modelo maestro
En tu cabeza, entiendes cómo funcionan varios sistemas y llevas modelos que los describen, como
modelos de tu vecindario o cómo administras tu hogar. De vez en cuando, dibuja extractos de esos
modelos, como un mapa para un amigo que le muestra cómo llegar a ese gran restaurante, o
escribe una lista de comestibles. Estos extractos son consistentes con ese modelo integral de tu
cabeza. Por ejemplo, podría haber escrito un mapa completo para su amigo, pero presumiblemente
el que dibujó es exacto hasta donde llega y es suficiente para llevarlo allí. Y su lista de compras
representa la diferencia entre sus planes de alimentación y el contenido de su refrigerador.
Los modelos de dominio, diseño y código son modelos integrales como estos. Están repletos de
detalles ya que, al menos conceptualmente, contienen todo lo que sabes sobre esos temas. Sería
difícil o imposible escribir todos esos detalles, e incluso mantenerlos en tu cabeza es difícil. Por lo
tanto, si desea utilizar un modelo para razonar acerca de la seguridad, la escalabilidad o cualquier
otro motivo, debe reducir los detalles para poder ver claramente los factores relevantes. Esto se
hace con vistas.
7.4. VISTAS DE UN MODELO MAESTRO 119
Oh
Figura 7.4: El modelo de dominio actúa como un modelo maestro que contiene todos los detalles. Las vistas
muestran detalles seleccionados del modelo maestro. Dado que todas son vistas del mismo modelo maestro,
todas las vistas son coherentes entre sí.
Definición. Una vista, también llamada proyección, muestra un subconjunto definido de los detalles
de un modelo, posiblemente con una transformación. Los modelos de dominio, diseño y código
tienen cada uno muchas vistas estándar. Las vistas del modelo de dominio incluyen listas de tipos,
listas de relaciones entre ellos y escenarios que muestran cómo cambian los tipos y las relaciones
con el tiempo (consulte la Figura 7.4). Las vistas de diseño incluyen el diagrama de contexto del
sistema y el diagrama de implementación. Puede inventar nuevas vistas según corresponda.
Philippe Kruchten, en su artículo sobre 4+1 vistas de la arquitectura, demostró que no es práctico
usar un solo diagrama para expresar todo sobre su arquitectura y diseño (?, ). Explicó que necesita
vistas arquitectónicas distintas porque cada una tiene sus propias abstracciones, notación,
preocupaciones, partes interesadas y patrones. Cada vista puede usar una notación apropiada y
enfocarse en una sola preocupación, lo que facilita su comprensión. Juntas, las vistas comprenden
un modelo de arquitectura completo, y cada vista presenta un subconjunto de los detalles de ese
modelo completo.
Ver consistencia. Cada vista (o diagrama) que cree de un dominio, diseño o modelo de código
muestra una sola perspectiva de ese modelo, exponiendo algunos detalles y ocultando otros. Los
diagramas no son partes aisladas del modelo, como los cajones de un armario.
En cambio, son proyecciones en vivo del modelo y las vistas son consistentes entre sí. Entonces, si
el modelo cambia, las vistas también lo hacen. Los planos de la casa son vistas de una casa (o su
diseño), por lo que espera que sean coherentes entre sí.
Por ejemplo, imagine que tiene dos vistas del modelo de dominio: una lista de tipos en el dominio
de redes y anuncios de trabajo (como anuncios, trabajos y contactos) y un escenario (una historia)
que los describe. Describiremos los escenarios con más detalle pronto, pero por ahora considérelo
como una historia sobre cómo interactúan los tipos de dominio a lo largo del tiempo. Si tuviera que
revisar el escenario para hacer referencia a un nuevo tipo de dominio, como una invitación rechazada
para unirse a una red de contactos, esperaría ver ese tipo en la lista de tipos definidos. Si no está
allí, es un error en su modelo de dominio.
Modelos maestros. Los modelos de dominio, diseño y código son conceptualmente un único modelo
maestro. Cada vista que dibuje debe ser consistente con ese modelo maestro.
Piénselo de esta manera: cuando revisó el escenario para referirse a un nuevo tipo, se revisó su
comprensión del modelo maestro. Dado que cualquier otra vista se deriva del modelo maestro, debe
reflejar su nueva comprensión. Dejando de lado la pragmática por un momento, todos los diagramas
que construyas deben ser consistentes en todo momento entre sí porque esa es la forma en que tú,
en tu mente, entiendes el dominio para trabajar. Sin embargo, desde un punto de vista pragmático,
mientras crea modelos, habrá ocasiones en las que no serán coherentes entre sí, pero se esfuerza
por eliminar esos errores.
Para reforzar la idea de modelos unificados y consistentes, puede ser útil imaginar un entorno de
programación donde todos estos elementos encajen y se verifiquen. En ese entorno de programación,
un escenario que intentara hacer referencia a un tipo que no estaba definido en el modelo maestro
generaría un error de verificación de tipo.
Discutir puntos de vista formalmente hace que suenen difíciles, pero en realidad las personas
pueden usarlos casi sin esfuerzo. Por ejemplo, puede imaginar su biblioteca tal como está ahora, o
imaginarla solo con los libros rojos, o imaginarla con los libros rojos girados para que pueda ver la
cubierta en lugar del lomo. Cada uno de estos es una vista de su modelo maestro de la librería. Tenga
en cuenta que si bien nunca ha escrito un modelo de su estantería, tiene uno en su cabeza que puede
manipular. Uno de los desafíos en el desarrollo de software es garantizar que los desarrolladores, los
expertos en la materia y otros tengan el mismo modelo maestro en mente.
Ejemplos de modelos maestros. Los modelos maestros son un concepto útil porque explican a qué
se refieren sus vistas, pero tiene opciones con respecto a lo que representa el modelo maestro. El
ejemplo más directo de un modelo maestro es un sistema ya existente. Puede crear muchas vistas de
un sistema existente. Considere su vecindario como un ejemplo de un sistema existente. No tiene un
modelo completo de su vecindario escrito en ningún lado, pero sí tiene el vecindario en sí.
Las vistas del vecindario se pueden probar con el vecindario para ver si son consistentes con ese
modelo maestro.
Otro ejemplo de un modelo maestro es un sistema que se construirá. A diferencia de su vecindario,
este sistema aún no existe, por lo que es un poco más complicado crear vistas de él y asegurarse de
que las vistas sean consistentes. Sin embargo, de alguna manera las cosas tienden a funcionar bien.
Puede embarcarse en un proyecto para renovar una habitación de su casa sin escribir ningún modelo
explícito, pero debe tener un modelo maestro en su cabeza de alguna forma. Ese modelo incluye
detalles sobre lo que debería suceder cuando (por ejemplo, la demolición ocurre antes de pintar) y
estimaciones de costos. Es probable que ese modelo en su cabeza esté incompleto, por lo que las
vistas de él también estarán necesariamente incompletas.
Aquí hay algunos ejemplos concretos de modelos maestros de sistemas de software. El modelo
maestro puede ser el sistema que construyó previamente o un sistema que planea construir. Puede
ser una combinación de los dos, como un sistema existente con adiciones planificadas.
7.5. OTRAS FORMAS DE ORGANIZAR LOS MODELOS 121
O podría ser aún más complejo, como un modelo del sistema tal como espera que se vea en intervalos de
tres meses durante los próximos años.
Limitar el tamaño y centrar la atención. Las vistas se utilizan en el modelado para limitar el tamaño de los
diagramas y centrar la atención. Imagine lo confuso que sería un modelo de dominio de tamaño mediano si
intentara mostrar todos los tipos, definiciones, comportamientos, etc., en el mismo diagrama. Es posible que
haya visto las copias impresas gigantes de esquemas de bases de datos corporativas pegadas en una pared
en algún lugar y haya visto a personas tratando de usarlas poniendo un dedo en un lugar y trazando las
líneas a otras partes del diagrama. Las vistas evitan eso.
7.5 Otras formas de organizar modelos

La estructura del modelo canónico de este capítulo consta de un modelo de dominio, un modelo de diseño y
un modelo de código. Esta organización básica de modelos tiene una larga historia, visible en el proceso de
desarrollo del software Syntropy (Cook y Daniels, 1994), aunque probablemente se remonta aún más atrás.
Otros autores han propuesto estructuras modelo similares, y aunque existen algunas diferencias en sus
organizaciones y nomenclatura, existe una similitud central compartida por todos. Con solo un poco de
entrecerrar los ojos, uno puede identificar el dominio, el diseño (límites e internos) y los modelos de código.
La figura 7.5 es un resumen que asigna los nombres de los modelos de este libro a algunos de los que se
encuentran en otros lugares.
A pesar de los grandes rasgos de similitud entre los autores, existen diferencias.
El único concepto que no se alinea bien entre los autores es el de los requisitos, porque puede significar
diferentes cosas para diferentes personas. Los modelos de requisitos pueden superponerse con modelos
comerciales, modelos de dominio, modelos de límites o modelos internos.
7.6 Modelado de negocios

Hay un tipo de modelo que no se encuentra en la estructura del modelo canónico de este libro: los modelos
de negocio. Los modelos de negocio describen lo que hace una empresa u organización y por qué lo hace.
Diferentes negocios en el mismo dominio tendrán diferentes estrategias, capacidades, organizaciones,
procesos y metas y, por lo tanto, diferentes modelos de negocios.
El modelado de dominio está relacionado con el modelado de negocios, que incluye no solo hechos sino
también decisiones y objetivos que las organizaciones deben tomar. Alguien en algún momento decide lo
que hace la organización y los procesos que sigue. Algunos de los procesos están total o parcialmente
automatizados con software. Los objetivos y las decisiones de una organización pueden verse influidos por
el software que crea y compra.
Entonces, ¿por qué incluir modelos de dominio pero no modelos de negocios en este libro? Este libro
incluye el modelado de dominios porque entender mal el dominio es una causa común de falla en los
proyectos de TI. La mala comprensión de los procesos comerciales también puede causar fallas, pero rara
vez son fallas de ingeniería.
Negocio Dominio modelo de diseño Código

Modelo Modelo Modelo
Perímetro Internos
Modelo Modelo
el bosco Sistema Componente Código

contexto diseño
queso y Negocio Tipo de especificaciones Componente Código

daniels concepto arquitectura
D'Souza Negocio Dominio Caja negra Caja blanca Código
(Mapa) arquitecto
tura
Software Requisitos Arquitectura Código
Ingenieria
Instituto (SEI)
jackson Dominio Dominio + Máquina

máquina
RUP Negocio Negocio Requisitos Análisis y Código
modelado modelado diseño
sintropía Esencial Código de implementación de la especificación
Figura 7.5: Una tabla que resume los modelos propuestos por varios autores y cómo se asignan a la
modelos de negocio, dominio, diseño (límite, internos) y código que se encuentran en este libro.
7.7 Uso de UML

Este libro utiliza la notación del lenguaje de modelado unificado (UML) porque es ubicuo
y su adición de notación arquitectónica en UML 2.0 lo ha acercado visualmente a
Lenguajes de arquitectura de propósito especial. Este libro se desvía del UML estricto en algunos
lugares. Cualquier desviación restante de UML es inadvertida.
• En UML, los conectores pueden ser líneas continuas o estilo bola y cavidad. Se distinguen utilizando
estereotipos para indicar sus tipos. En este libro, los conectores son
se muestra usando una variedad de estilos de línea, que es una forma más compacta de transmitir
sus tipos y pueden estar menos abarrotados.
• En UML, el tipo de puerto se muestra con una etiqueta de texto cerca. Este libro usa eso
estilo, pero a veces abarrota el diagrama, en cuyo caso los puertos están sombreados y
definido en una leyenda. No todas las herramientas UML permiten sombrear o colorear los puertos.
7.8. CONCLUSIÓN 123
7.8 Conclusión
Una vez que comienza a construir modelos de su sistema, se da cuenta de que comprender y
rastrear muchos modelos pequeños es difícil, pero construir un solo modelo gigantesco no es
práctico. La estrategia propuesta en este capítulo es construir modelos pequeños que encajen
en una estructura de modelo canónico. Si comprende la estructura canónica, comprenderá
dónde encaja cada modelo.
La primera gran idea fue utilizar la designación y el refinamiento para crear modelos que
difieran en su abstracción. Los modelos principales son el modelo de dominio, el modelo de
diseño y el modelo de código, y van desde lo abstracto a lo concreto. La segunda gran idea fue
usar vistas para ampliar los detalles de un modelo. Dado que todas las vistas son proyecciones
de un solo modelo maestro, sus detalles son coherentes (o se pretende que lo sean). Para
anidar jerárquicamente los modelos de diseño, utilice el refinamiento para relacionar los
modelos internos y de límites.
Los entrenadores ven y entienden más que los novatos no porque tengan ojos más agudos,
sino porque tienen un modelo conceptual que les ayuda a categorizar lo que están viendo. Este
capítulo describe en detalle toda la estructura del modelo canónico, pero no deje que esto lo
alarme. En la práctica, rara vez, o nunca, crearía todos los modelos y vistas posibles. Una vez
que haya interiorizado estas ideas, le ayudarán a comprender dónde encaja un detalle,
diagrama y modelo dado. Como se muestra en el estudio de caso (Capítulo 4) y el capítulo
sobre el modelo basado en el riesgo (Capítulo 3), seguir un enfoque de arquitectura basado en
el riesgo lo alienta a construir un subconjunto de modelos, que lo ayudan a reducir los riesgos
que ha identificado. . Este capítulo, y los subsiguientes, proporcionan descripciones detalladas
para ayudarlo a internalizar los modelos y, por lo tanto, ser mejor en la construcción de software,
no para alentarlo a la parálisis del análisis.
7.9 Lectura adicional

Este libro es una síntesis de los enfoques de modelado arquitectónico inventados por otros
autores. Tiene tres influencias principales. El primero es el trabajo sobre el modelado de
componentes en UML de D'Souza y Wills (1998) y Cheesman y Daniels (2000), que se centra
principalmente en la funcionalidad del modelado. El segundo es el enfoque centrado en los
atributos de calidad del Instituto de Ingeniería de Software (Bass, Clements y Kazman, 2003;
Clements et al., 2010) y la Universidad Carnegie Mellon (Shaw y Garlan, 1996). La tercera es
la comunidad de desarrollo de software ágil (Boehm y Turner, 2003; Ambler, 2002) que fomenta
prácticas eficientes de desarrollo de software.
Hay varios buenos libros que describen los conceptos generales de la arquitectura de
software. Bass, Clements y Kazman (2003) describen una visión de la arquitectura de software
centrada en los atributos de calidad y proporcionan estudios de casos de aplicación de sus técnicas.
Taylor, Medvidović y Dashofy (2009) es un tratamiento más moderno y lógicamente
organizado como un libro de texto. Shaw y Garlan (1996) está quedando anticuado, pero es el mejor
libro para comprender la promesa de la arquitectura de software. Clemente et al. (2010) es un
excelente libro de referencia para conceptos y notaciones de arquitectura (y también tiene un
apéndice útil sobre el uso de UML como lenguaje de descripción de arquitectura). Estos libros rara
vez se adentran en los objetos y el diseño, pero D'Souza y Wills (1998) y Cheesman y Daniels
(2000) sí lo hacen, mostrando cómo la arquitectura encaja en el diseño orientado a objetos.
Probablemente más que cualquier otro libro, Bass, Clements y Kazman (2003) ha moldeado la
forma en que el campo piensa sobre la arquitectura de software, cambiando el enfoque de la
funcionalidad hacia los atributos de calidad. Describe no solo la teoría sino también los procesos
para analizar arquitecturas y descubrir requisitos de atributos de calidad. El libro también contiene
una gran discusión sobre la ortogonalidad de la funcionalidad y los atributos de calidad.
Rozanski y Woods (2005) ofrecen quizás el tratamiento más completo de cómo comprender y
utilizar vistas múltiples en la arquitectura de software. También contiene valiosas listas de verificación
relacionadas con varias preocupaciones estándar.
El enfoque pragmático más simple para el desarrollo basado en componentes se encuentra en
Cheesman y Daniels (2000). Presentan una estructura organizativa para los modelos que utilizan
UML y tratan los componentes como tipos de datos abstractos con límites de encapsulación
estrictos. Un enfoque similar, pero con mayor detalle, se encuentra en D'Souza y Wills (1998).
Ambos enfatizan las especificaciones detalladas, como las condiciones previas y posteriores, como
una forma de detectar errores durante el diseño. Este libro resta importancia a las condiciones
previas y posteriores porque en la mayoría de los proyectos son demasiado costosas, pero la
mentalidad que fomentan es excelente.
El mejor libro para articular una visión de la ingeniería de software que incluye la arquitectura
de software es probablemente Shaw y Garlan (1996). Al leerlo, es difícil no compartir su entusiasmo
por cómo la arquitectura puede ayudar a nuestro campo.
Los elementos básicos del modelado arquitectónico, incluidas las trampas, están bien descritos
por Clements et al. (2010). Uno de los objetivos del libro es enseñar a los lectores cómo documentar
los modelos en un paquete de documentación, lo que puede ser importante en proyectos grandes.
Hasta la fecha, el tratamiento más completo de la arquitectura de software es el de Taylor,

Medvidović y Dashofy (2009) en su libro de texto sobre arquitectura de software. Cubre ejemplos
del mundo real de arquitectura de software, así como desarrollos de investigación sobre formalismos
y análisis.
Los desarrolladores que trabajan en el campo de la tecnología de la información (TI) estarán
bien atendidos por el tratamiento de la arquitectura de software de Ian Gorton, ya que su libro cubre
no solo los conceptos básicos de la arquitectura de software, sino también las tecnologías comunes
en TI, como Enterprise Java Beans ( EJB), Middleware orientado a mensajes (MOM) y Arquitectura
orientada a servicios (SOA) (Gorton, 2006).
Usar la abstracción para organizar una pila de modelos es una técnica antigua. se usa en
el método de diseño orientado a objetos Syntropy (Cook y Daniels, 1994) y es central
a Cheesman y Daniels (2000), Fowler (2003a) y D'Souza y Wills (1998).
Muchos autores han sugerido formas de organizar y relacionar los modelos de arquitectura. Jan Bosch
modela el contexto del sistema, los arquetipos y los componentes principales
(Bosque, 2000). John Cheesman y John Daniels proponen construir un modelo de requisitos (un modelo de
información comercial y un modelo de escenario) y un modelo de
especificación del sistema (un modelo de tipo de negocio, especificaciones de interfaz, especificaciones de
componentes y la arquitectura de componentes) (Cheesman y Daniels, 2000). Desmond
D'Souza, en MAp, sugiere modelar la arquitectura empresarial, el dominio y la
diseño como una caja negra y una caja blanca (D'Souza, 2006). David Garlan concibe la arquitectura como
un puente entre los requisitos y la implementación (Garlan,
2003). Michael Jackson sugiere modelar el dominio, el dominio con la máquina,
y la máquina (Jackson, 1995). El enfoque principal de Jackson está en los requisitos del sistema
ingeniería, no diseño, pero sus especificaciones se superponen bien con el diseño. Lo racional
Unified Process (RUP) no aboga por modelos específicos, pero sugiere actividades para
modelado de negocios, requisitos y análisis y diseño (Kruchten, 2003).
Todo desarrollador debe estar familiarizado con el documento de vistas de arquitectura 4+1 (?, ),
pero también tenga en cuenta que es solo uno de los muchos conjuntos de puntos de vista diferentes que se han
propuestas para la arquitectura, como las Four Views de Siemens (Hofmeister, Nord y
Soni, 2000).
También debe tener en cuenta la descripción estándar IEEE de arquitectura de software, IEEE 1471-2000
(Society, 2000). En él, encontrará la mayoría de los mismos conceptos que
en este libro. Tiene algunas adiciones y diferencias que vale la pena señalar. Si bien utiliza vistas,
los trata como requisitos desde el punto de vista de una parte interesada enfocada en una preocupación
particular, en lugar de como proyecciones de un modelo maestro consistente, lo que sería
llamar a una descripción de la arquitectura. También describe el entorno en el que habita el sistema,
su misión y los puntos de vista de la biblioteca (que son definiciones de puntos de vista reutilizables).
Los autores están prestando cada vez más atención al modelado de procesos de negocio además del
modelado de dominio. Martin Ould proporciona un proceso práctico para modelar
procesos de negocio (Ould, 1995). Desmond D'Souza describe cómo conectar los procesos comerciales con
la arquitectura del software conectando los objetivos comerciales con los objetivos del sistema.
(D'Souza, 2006).
La relación entre la arquitectura de software (específicamente la arquitectura empresarial) y la estrategia
empresarial se trata en Ross, Weill y Robertson (2006). Como desarrolladores de software, tal vez asumimos
que el estado futuro natural debería ser que todos
los sistemas pueden interoperar. La tesis sorprendente del libro es que el nivel de integración debe relacionarse
con la estrategia empresarial elegida.
Glosario
Especificación de acción Una especificación (a veces formal) de un método, procedimiento o más comportamiento de
abstracción. A menudo consta de una condición previa (lo que debe ser cierto para que el método se ejecute
correctamente) y una condición posterior (lo que el método garantiza que será cierto después de que se complete).
Ver diseño por contrato.
Proceso ágil Un estilo de proceso de desarrollo de software caracterizado por un desarrollo iterativo. Ver proceso en
cascada , programación extrema, proceso iterativo, proceso ágil y proceso en espiral.
Elemento de asignación (es decir, nodo UML o elemento ambiental) Hardware (como computadoras) y ubicaciones
geográficas (como centros de datos) que pueden albergar módulos e instancias de componentes .
UML (Booch, Rumbaugh y Jacobson, 2005) se refiere a lugares donde el software se puede implementar como
nodos y los autores de SEI (Bass, Clements y Kazman, 2003) se refieren a él como un elemento ambiental.
Tipo de vista de asignación El tipo de vista que contiene vistas de elementos relacionados con la implementación del
software en el hardware. Incluye diagramas de implementación, descripciones de elementos ambientales como
servidores y descripciones de canales de comunicación como enlaces ethernet. También puede incluir elementos
geográficos, de modo que pueda describir dos servidores en diferentes ciudades.
Ver tipo de vista de tiempo de ejecución y tipo de vista de módulo.
Modelo analógico En un modelo analógico, cada elemento del modelo tiene un análogo en el dominio de interés. Una
pantalla de radar es un modelo analógico de algún terreno, donde las señales en la pantalla corresponden a
aviones: son análogos. Los modelos analógicos admiten el análisis solo indirectamente y, por lo general, se
requiere conocimiento del dominio y razonamiento humano. Ver modelo analítico.
Parálisis de análisis La situación en la que un desarrollador dedica un tiempo excesivo a analizar o crear modelos y
no crear una solución.
Modelo analítico Un modelo analítico soporta directamente el análisis del dominio de interés. Las ecuaciones
matemáticas son ejemplos de modelos analíticos, al igual que las máquinas de estado. Podrías imaginar un
modelo analítico de los aviones donde cada uno está representado por un vector. Las matemáticas proporcionan
un modelo analítico para evaluar los vectores, por lo que puede responder preguntas cuantitativamente sobre
los cursos de colisión. Ver modelo analógico.
336 Glosario
Instancia anónima Una instancia (como un objeto o una instancia de componente) a la que no se le ha dado un nombre.
Gráficamente, está etiquetado como ": TypeName". Por el contrario, una instancia con nombre tendría un nombre
que precede a los dos puntos.
Arquitecto de aplicaciones Los arquitectos de aplicaciones son desarrolladores responsables de una sola aplicación. Es
posible que entiendan y manejen miles de objetos que componen su aplicación. Los arquitectos de aplicaciones
son como directores de cine cuyas acciones diarias crean la forma del producto.
Interfaz de programación de aplicaciones (API) Un conjunto de operaciones que se pueden realizar en un módulo,
componente u objeto. Cuando nos referimos a operaciones a nivel de API, queremos decir que no son abstractas,
y esas operaciones son exactamente lo que se vería en el lenguaje de programación.
Estilo arquitectónico (es decir, patrón arquitectónico). Un estilo arquitectónico es “una especialización de elementos y
tipos de relaciones, junto con un conjunto de restricciones sobre cómo se pueden usar”.
(Clements et al., 2010)
Estilo de codificación evidente desde el punto de vista arquitectónico Un estilo de programación que codifica un
diseño adicional en la tienda proporcionando sugerencias sobre la arquitectura del sistema. Lo alienta a incrustar
sugerencias en el código fuente que hacen que la arquitectura sea evidente para un desarrollador que lee el
código. Sigue el principio del modelo en código.
Arquitectura ver arquitectura de software.
Lenguaje de descripción de arquitectura (ADL) Lenguaje utilizado para describir arquitecturas que define elementos
(por ejemplo, componentes, conectores, módulos, puertos) y relaciones. Los ejemplos incluyen UML, C2, AADL y
Acme.
Deriva de la arquitectura La deriva de la arquitectura es la tendencia de un sistema, con el tiempo, a violar su

diseño. (Perry y Lobo, 1992)
Controlador de arquitectura Escenarios de atributos de calidad o escenarios de funcionalidad que son importantes para
las partes interesadas y difíciles de lograr. Como tales, son los escenarios a los que se debe prestar más atención
al diseñar el sistema (Bass, Clements y Kazman, 2003)
Elevación de la arquitectura Cuando se sigue un enfoque de elevación de la arquitectura , los desarrolladores diseñan la
arquitectura con la intención de garantizar un objetivo o una propiedad del sistema. La idea es que una vez que
un objetivo o una propiedad se ha incorporado a la arquitectura, los desarrolladores no deberían necesitar escribir
ningún código adicional para lograrlo. Véase diseño centrado en la arquitectura y diseño indiferente a la
arquitectura.
Refactorización de arquitectura Una refactorización de la arquitectura de un sistema, posiblemente de un estilo

arquitectónico a otro, o la introducción de consistencia (ver restricciones) donde antes no había ninguna.
Diseño centrado en la arquitectura En el diseño centrado en la arquitectura, los desarrolladores son conscientes de la
arquitectura de software de su sistema y la eligen deliberadamente para que su sistema pueda lograr sus objetivos.
Véase diseño indiferente a la arquitectura y elevación de la arquitectura.
Glosario 337
Diseño indiferente a la arquitectura En el diseño indiferente a la arquitectura, los desarrolladores ignoran la

arquitectura de su sistema y no eligen conscientemente una arquitectura que los ayude a reducir riesgos,
lograr funciones o garantizar cualidades. Los desarrolladores pueden simplemente ignorar su arquitectura,
copiar la arquitectura de su proyecto anterior, usar la arquitectura presunta en su dominio o seguir un
estándar corporativo. Ver diseño centrado en la arquitectura y elevación de la arquitectura.
Riesgos integrados Cuando un proceso está diseñado para abordar siempre un determinado riesgo, se dice que
ese riesgo está integrado en el proceso. Por ejemplo, los procesos ágiles abordan el riesgo de rechazo del
cliente al construir y entregar el sistema de forma incremental.
Big Design Up Front (BDUF) En Big Design Up Front (BDUF), las primeras semanas o meses de un proyecto se
dedican principalmente al diseño en lugar de crear prototipos o construir. Es un término peyorativo acuñado
por personas, como los defensores ágiles, que están preocupados por la parálisis del análisis, una situación
en la que un proyecto dedica demasiado tiempo al diseño y no el suficiente tiempo a la construcción.
BDUF se asocia más con procesos en cascada que con procesos en espiral.
Conector binario Un conector que se puede unir a solo dos componentes. Ver conector de N-vías.
Vinculación (1) Al utilizar vinculaciones, los puertos de un componente externo se vinculan a puertos compatibles
o idénticos en componentes internos. Los escenarios de atributos de calidad e invariantes en el componente
externo deben ser satisfechos por los componentes internos. (2) La relación vinculante se utiliza para mostrar
la correspondencia entre las partes del patrón y los elementos de un modelo que utiliza ese patrón.
Modelo de límite El modelo de límite es lo que los externos pueden ver del sistema (o un elemento del sistema),
que incluye su comportamiento, datos de intercambio y atributos de calidad. El límite es un compromiso con
una interfaz pero no con los detalles de implementación. El modelo de límites describe lo que un usuario
necesita saber para comprender cómo funciona un sistema. Es una vista encapsulada del sistema que oculta
detalles internos. Cuando los desarrolladores cambian el diseño interno, los usuarios no se molestan. Ver
modelo de interiores.
Modelo de negocio Un modelo de negocio describe lo que hace una empresa u organización y por qué lo hace. Los
modelos de negocio rara vez hablan de software. Diferentes negocios en el mismo dominio tendrán diferentes
estrategias, capacidades, organizaciones, procesos y objetivos y, por lo tanto, diferentes modelos de
negocios. Describe no solo hechos (que aparecerían en un modelo de dominio), sino también decisiones y
objetivos que las organizaciones deben tomar.
Estructura de modelo canónico Un conjunto de modelos, que van desde abstractos a concretos, que usan vistas
para profundizar en los detalles de cada modelo. Consta de tres modelos principales: el modelo de dominio,
el modelo de diseño y el modelo de código. La estructura del modelo canónico tiene el modelo más abstracto
(el dominio) en la parte superior y el más concreto (el código) en la parte inferior. Las relaciones de
designación y refinamiento aseguran que los modelos se correspondan, pero les permiten diferir en su nivel
de abstracción.
Relación de clasificación Una relación de clasificación es la misma que existe entre clases y objetos en la
programación orientada a objetos.
Semántica cerrada En el refinamiento con semántica cerrada, el refinamiento restringe qué tipos de elementos
nuevos se pueden introducir enumerando los tipos de elementos que no cambiarán. Ver semántica abierta.
338 Glosario
Modelo de código El modelo de código describe el código fuente del sistema. El modelo de código es la implementación del
código fuente del sistema o un modelo equivalente. Podría ser el código Java real o el resultado de ejecutar una
herramienta de código a UML, pero su característica importante es que tiene un conjunto completo de compromisos
de diseño. Cuando el modelo de diseño tiene un conjunto incompleto de compromisos de diseño, el modelo de
código tiene un conjunto completo, o al menos un conjunto suficientemente completo para ejecutarse en una
máquina. Compare con el modelo de dominio y el modelo de diseño. Los tres son parte de la estructura del modelo
canónico.
Módulos comerciales listos para usar (COTS) , componentes u otro código fuente disponible de terceros. Este término se
usa a menudo incluso si son de código abierto o de una fuente no comercial.
grupo.
Canal de comunicación (es decir, conexión o elemento ambiental) Hardware que permite que los elementos de asignación
se comuniquen. UML (Booch, Rumbaugh y Jacobson, 2005) se refiere a los canales de comunicación entre nodos
como conexiones y los autores de SEI (Bass, Clements y Kazman, 2003) se refieren a ellos como elementos
ambientales.
Componente “Los componentes [son] los principales elementos de cómputo y almacenes de datos que se ejecutan en un
sistema”. (Clements et al., 2010) Por lo general, se refiere a una instancia de componente, pero también podría
referirse a un tipo de componente. Ver módulo.
Ensamblaje de componentes (es decir, diagrama de componentes y conectores) Un ensamblaje de componentes muestra
una configuración específica de instancias o tipos de componentes, puertos y conectores. Su arreglo es el diseño
de componentes y diferentes arreglos producirán diferentes calidades. Puede mostrar enlaces entre puertos externos
e internos .
Desarrollo basado en componentes (CBD) Desarrollo de software cuyo producto final es vagamente
componentes acoplados para ser vendidos en un mercado de componentes.
Modelo conceptual Un modelo conceptual identifica características sobresalientes y cómo operan. Las clases introductorias
de física enseñan mecánica newtoniana, un modelo conceptual de cómo se comportan los objetos físicos, que
incluye características como masa y fuerzas.
Conector Un conector es una vía de interacción en tiempo de ejecución entre dos o más componentes.
Esto es ligeramente diferente a la definición de (Clements et al., 2010), que establece que un "conector [es] una vía
de interacción en tiempo de ejecución entre dos o más componentes".
Restricción Véase invariante.
Diagrama de contexto del sistema Conjunto de componentes que se centra en el sistema que se está diseñando e incluye
todos los sistemas externos a los que se conecta el sistema.
Diseño por contrato Bertrand Meyer popularizó el concepto de diseño por contrato donde las condiciones previas y
posteriores del método, así como las invariantes del objeto , se insertan en el código fuente y se verifican mediante
herramientas automatizadas (Meyer, 2000). Al confiar en el contrato de un método, los clientes pueden ignorar con
seguridad cualquier implementación interna y tratar el método o el objeto completo como una caja negra.
Decisión de diseño Decisiones tomadas por los desarrolladores durante el curso del diseño del sistema que comprometen
el proyecto con una elección de diseño particular o restringen el espacio de diseño. Véase invariante.
Glosario 339
Intención del diseño La comprensión y las intenciones de los desarrolladores del sistema. La intención del diseño está
perfectamente contenida en el código fuente de un sistema, lo que obliga a los desarrolladores a inferir partes de él.
Modelo de diseño El modelo de diseño describe el sistema que construirá y está en gran parte bajo su control. El sistema a
construir aparece en el modelo de diseño. El modelo de diseño es un conjunto parcial de compromisos de diseño.
Es decir, dejas sin decidir algunos detalles (generalmente de bajo nivel) sobre cómo funcionará el diseño,
aplazándolos hasta el modelo de código. El modelo de diseño se compone de modelos de límites anidados
recursivamente y modelos internos. Compare con el modelo de dominio y el modelo de código. Los tres son parte
de la estructura del modelo canónico.
Designación Una relación de designación le permite mostrar correspondencias entre dos dominios, por ejemplo, entre el
mundo real y un modelo de dominio de problemas. Identifica que algo de un dominio corresponde a algo en un
segundo dominio.
Paquete de documentación Una descripción escrita completa, o casi completa, de un archivo de software.
tecture
Conector de dominio Un conector que une los dominios de los componentes que conecta. Cuando dos componentes
interactúan, a menudo hay alguna lógica que depende del dominio de ambos componentes. Al poner esta lógica en
un conector de dominio, aísla cada uno de los componentes para que no conozcan detalles innecesarios sobre el
otro.
Diseño impulsado por el dominio El diseño impulsado por el dominio aboga por incorporar el modelo de dominio en el
código fuente (Evans, 2003). Es compatible con el principio del modelo en código, pero va más allá al fomentar un
proceso de desarrollo ágil y desaconsejar la expresión de modelos de dominio en
papel.
Modelo de dominio El modelo de dominio describe verdades perdurables sobre el dominio que son relevantes para su
sistema. En general, el dominio no está bajo tu control, por lo que no puedes decidir que las semanas tengan seis
días o que tengas una fiesta de cumpleaños todas las semanas. El sistema a construir no aparece en el modelo de
dominio. Compare con el modelo de diseño y el modelo de código. Los tres son parte de la estructura del modelo
canónico.
Descomposición dominante El sistema organizativo de un sistema que promueve una sola preocupación.
Los problemas relacionados con esa preocupación dominante serán más fáciles de resolver, pero los problemas
relacionados con otras preocupaciones serán más difíciles. Por ejemplo, si organiza los libros por su tamaño, será
fácil encontrar los libros más altos pero será más difícil encontrar los de un autor específico. Este problema de una
preocupación que domina a las demás se conoce como la tiranía de la descomposición dominante (Tarr et al., 1999).
Controlador Ver controlador de arquitectura.
Modelo de arquitectura dinámica Modelo que generaliza todas las configuraciones instantáneas posibles (p. ej., topología
de instancias de componentes) de una arquitectura. La mayoría de los sistemas cambian durante el inicio y el
apagado, pero tienen una larga configuración de estado estable en el medio que se modela como un modelo de
arquitectura estática.
Encapsulación eficaz Encapsulación en la que el límite no filtra innecesariamente abstracciones a través de su interfaz. En
última instancia, lo que cuenta como efectivo es subjetivo y requiere buen juicio.
340 Glosario
Encapsulación "[E]l proceso de compartimentar los elementos de una abstracción que constituyen su estructura y comportamiento;
la encapsulación sirve para separar la interfaz contractual de una abstracción y su implementación". (Booch et al., 2007)
Riesgo de ingeniería Un riesgo relacionado con el análisis, diseño e implementación del producto. Véase riesgo de gestión de
proyectos.
Arquitecto empresarial Arquitectos que son responsables de muchas aplicaciones, que no controlan la funcionalidad de ninguna
aplicación y que, en cambio, diseñan un ecosistema dentro del cual las aplicaciones individuales contribuyen a la empresa
en general. Los arquitectos empresariales son como los productores de películas en el sentido de que influyen en el
resultado solo indirectamente.
Arquitectura empresarial La arquitectura de software de una organización que abarca múltiples aplicaciones
ciones (sistemas).
Elemento ambiental (es decir, nodo UML) Hardware con el objetivo principal de ejecutar software
que se comunica a través de los canales de comunicación.
Bus de eventos Un conector de publicación-suscripción de N vías .
Diseño evolutivo Diseño evolutivo “significa que el diseño del sistema crece a medida que se implementa” (Fowler, 2004). A
menudo se combina con la refactorización. Comparar con el diseño planificado.
Elemento de extensión Se enumeran los elementos de extensión, como "El sistema se compone de un cliente, un procesador de
pedidos y un componente de almacenamiento de pedidos". Los ejemplos incluyen módulos, componentes, conectores,
puertos y ensamblajes de componentes. Véase elemento intencional.
Extreme Programming_(XP) Una especialización de un proceso de desarrollo de software iterativo y ágil , por lo que contiene
múltiples iteraciones (Beck y Andres, 2004). Sugiere evitar el trabajo de diseño inicial, aunque algunos proyectos agregan
una iteración cero (Schuh, 2004), en la que no se entrega ninguna funcionalidad visible para el cliente. Guía a los
desarrolladores para que apliquen exclusivamente el diseño evolutivo , aunque algunos proyectos lo modifican para
incorporar una pequeña cantidad de diseño planificado.
Cada iteración se prioriza según la valoración de las características del cliente, no los riesgos. Compare con el proceso en
cascada , el proceso iterativo, el proceso ágil y el proceso en espiral.
Marco (es decir, marco de software o marco orientado a objetos) Una forma de reutilización de software caracterizada por la
inversión del control. Los marcos, a diferencia de las bibliotecas, son un medio eficaz para compartir o reutilizar una
arquitectura de software.
Escenario de funcionalidad Los escenarios de funcionalidad, también llamados simplemente escenarios, expresan una serie de
eventos que provocan cambios en un modelo. Un escenario describe un único camino posible en lugar de generalizar
muchos caminos. Ver caso de uso.
Generalización La relación entre un tipo más general y un tipo más específico, como muebles y sillas.
Conector de meta Un conector de meta tiene una meta u objetivo asignado que es responsable de lograr. Un desarrollador que
crea un conector de objetivos debe evitar fallas investigando el problema, descubriendo posibles casos de falla y
asegurándose de que el conector los maneje.
Los conectores de objetivos suelen ser complejos, ya que tienen un trabajo de dominio real que hacer y son responsables
de verlo completado. Ver conector microgestionado.
Glosario 341
Modelo de información Un conjunto de tipos y sus definiciones que describe las cosas que existen en el dominio. También describe las
relaciones entre esos tipos. Se puede dibujar textualmente, a menudo como una tabla, o gráficamente, a menudo usando la
sintaxis del diagrama de clases UML.
Tecnología de la información (TI) Una especialidad dentro del diseño de software que se enfoca en “el estudio, diseño, desarrollo,
implementación, soporte o administración de sistemas de información basados en computadora, particularmente aplicaciones de
software y hardware de computadora”. (Asociación de Tecnología de la Información de América).
Elemento intensional Los elementos intensionales son aquellos que se cuantifican universalmente, como "Todos los filtros pueden
comunicarse a través de tuberías". Los ejemplos incluyen estilos, invariantes, asignaciones de responsabilidad, decisiones de
diseño, justificación, protocolos y atributos de calidad. Véase elemento extensional.
Modelo interno Un modelo interno es un refinamiento de un modelo de límites. Ambas son vistas del modelo de diseño pero difieren en
los detalles que revelan. Todo lo que sea cierto en el modelo de límites debe ser cierto en el modelo interno. Cualquier
compromiso hecho en el modelo de límites (el número y tipo de puertos, escenarios de control de calidad) debe mantenerse en
el modelo interno. Ver modelo de límites.
Invariante Aproximadamente lo mismo que una restricción. Puede expresarse como un predicado que siempre es verdadero con respecto
al sistema o diseño. A veces se divide en invariantes estáticos (o invariantes de representación) que tratan con estructuras
estáticas e invariantes dinámicos que tratan con comportamientos. El término invariable se usa más a menudo para aplicarlo al
código fuente o estructuras de datos.
Cuando se hace referencia a sistemas, el término restricción se usa con más frecuencia.
Iteración Un período de tiempo en un proceso iterativo donde todas las actividades de desarrollo de software pueden
tener lugar.
Proceso iterativo Un proceso de desarrollo iterativo construye el sistema en múltiples bloques de trabajo, llamados iteraciones (Larman
y Basili, 2003). Con cada iteración, los desarrolladores pueden volver a trabajar en partes existentes del sistema, por lo que no
solo se construye de forma incremental. El desarrollo iterativo opcionalmente tiene un trabajo de diseño por adelantado, pero no
impone una priorización a través de las iteraciones, ni brinda orientación sobre la naturaleza del trabajo de diseño. Ver proceso
en cascada, programación extrema, proceso ágil y proceso en espiral.
Capa Un sistema en capas organiza sus módulos de modo que las capas inferiores actúen como máquinas virtuales para las capas
superiores. Las dependencias son (casi) exclusivamente hacia abajo, donde las capas superiores pueden usar y depender de
las capas inferiores, pero no al revés.
Vínculo Un borde entre dos objetos en una instantánea (o diagrama de instancia).
Modelo maestro Un modelo que contiene un conjunto completo de detalles necesarios para proyectar las vistas.
tu construyes.
Firma de método Una especificación de un método o procedimiento que normalmente incluye el nombre del método, su tipo de
devolución y los tipos de sus parámetros. Se puede aumentar con condiciones previas y posteriores para formar una
especificación de acción.
Conector microadministrado Un conector que simplemente hace el trabajo que le asigna. Si falla es porque no lo supervisó lo suficiente.
Su trabajo es solo hacer lo que le dijiste que hiciera.
Los conectores microgestionados son conectores simples. Ver conector de meta.
342 Glosario
Diseño planificado mínimo (es decir, Little Design Up Front) Entre el diseño evolutivo y el diseño planificado se encuentra el diseño
planificado mínimo (Martin, 2009). Los defensores del diseño planificado mínimo se preocupan de que puedan diseñarse a sí
mismos en una esquina si hicieran todo el diseño evolutivo, pero también les preocupa que todo el diseño planificado sea
difícil y que pueda hacer las cosas mal.
Modelo Una representación simbólica de un sistema que contiene solo detalles seleccionados.
Brecha modelo-código La diferencia entre cómo expresamos la solución en el modelo de diseño y cómo la expresamos en el código
fuente. Véase elemento intensional y elemento extensional.
Principio del modelo en código Expresar un modelo en el código del sistema ayuda a la comprensión y evolución. Un corolario de
este principio es que expresar un modelo en código implica necesariamente realizar más trabajo del estrictamente necesario
para que la solución funcione.
Módulo (es decir, paquete) Una colección de artefactos de implementación, como código fuente (clases, funciones, procedimientos,
reglas, etc.), archivos de configuración y definiciones de esquema de base de datos. Los módulos pueden agrupar código
relacionado, revelando una interfaz pero ocultando la implementación.
Tipo de vista del módulo El tipo de vista que contiene vistas de los elementos que puede ver en tiempo de compilación.
Incluye artefactos como código fuente y archivos de configuración. Las definiciones de tipos de componentes, tipos de
conectores y tipos de puertos también se encuentran en el tipo de vista del módulo, al igual que las definiciones de clases e
interfaces. Consulte el tipo de vista de tiempo de ejecución y el tipo de vista de asignación.
Conector de n vías Un conector que puede unir uno a muchos componentes, generalmente tres o más, como un bus de eventos. Ver
conector binario.
Navegación La idea de que se puede atravesar de un nodo a otro en un modelo a través de los bordes. Por ejemplo, puede navegar
a través de un diagrama de clases UML de una clase a otra a través de las asociaciones. Consulte Lenguaje de restricciones
de objetos.
Lenguaje de restricciones de objetos (OCL) Un lenguaje preciso para expresar invariantes y restricciones sobre modelos UML. Ver
navegación.
Semántica abierta En el refinamiento con semántica abierta, el refinamiento puede introducir cualquier elemento nuevo que le plazca.
Ver semántica cerrada.
Módulo Parnas Una técnica de modularización en la que se asegura de que los detalles que probablemente cambien estén ocultos
dentro del módulo y que los cambios en esos detalles no influyan en la interfaz del módulo. Un módulo de Parnas esconde un
secreto para minimizar el acoplamiento, en lugar de simplemente agrupar el código relacionado. Ver encapsulación y
encapsulación efectiva.
Partición (1) Como sustantivo, una relación entre partes y un todo tal que las partes se combinan para formar exactamente el todo, ni
más ni menos. (2) Como verbo, un sinónimo suelto de "dividir" o "descomponer". O como en (1), la división de un sistema en
piezas inconexas.
Patrón Un patrón es una solución reutilizable a un problema recurrente (Gamma et al., 1995).
Diseño planificado (es decir, diseño inicial) Una especie de proceso de desarrollo de software en el que el diseño se realiza en su
mayor parte o en su totalidad antes de que comience la implementación. Ver diseño evolutivo y diseño evolutivo .
Glosario 343
Puerto Toda la comunicación dentro o fuera de un componente se realiza a través de puertos en el componente. Todos los
métodos disponibles públicamente que admite un componente y todos los eventos públicos a los que responde se
especificarán en sus puertos. No existe una conexión necesaria entre los puertos de los componentes y los puertos
de un sistema operativo.
Condición previa y condición posterior Ver especificación de acción.
Arquitectura presuntiva Una arquitectura de software (o, más cuidadosamente, una familia de arquitecturas) que es
dominante en un dominio particular. En lugar de justificar su elección de usarlo, los desarrolladores de ese dominio
pueden tener que justificar una elección que difiera de la arquitectura presunta.
Por ejemplo, una arquitectura de 3 niveles es una arquitectura presunta en muchos grupos de tecnología de la
información (TI). Ver arquitectura de referencia.
Proyección Ver vista.
Riesgo de gestión de proyectos Riesgos relacionados con cronogramas, secuencia de trabajo, entrega, tamaño del
equipo, geografía, etc. Ver riesgo de ingeniería.
Los elementos del modelo de propiedades se pueden anotar con propiedades que elaboran detalles sobre el elemento.
Por ejemplo, se puede anotar un conector con una propiedad que describa su protocolo o su rendimiento.
Prototipo (es decir, pico arquitectónico o prueba de concepto) Una implementación destinada a reducir el riesgo al demostrar
la viabilidad, evaluar las propiedades o similar. No se usa de forma peyorativa (es decir, “código descartable”) en
este libro.
Riesgo prototípico Cada dominio tiene un conjunto de riesgos prototípicos que es diferente de otros dominios.
Por ejemplo, los proyectos de sistemas suelen preocuparse más por el rendimiento que los proyectos de TI.
Atributo de calidad (es decir, QA, requisitos extrafuncionales o "-idades") Un atributo de calidad es un tipo de requisito
extrafuncional, como rendimiento, seguridad, escalabilidad, modificabilidad o confiabilidad.
Escenario de atributo de calidad (es decir, escenario de control de calidad) Una descripción concisa de un requisito
extrafuncional, que consiste en una fuente, un estímulo, un entorno, un artefacto, una respuesta y una medida de respuesta.
Por supuesto.
Elección de arquitectura racional Las opciones de arquitectura racional son aquellas en las que sus compensaciones se
alinean con sus prioridades de atributos de calidad. A menudo siguen esta plantilla: dado que <x> es una prioridad,
elegimos el diseño <y> y aceptamos la desventaja <z>.
Proceso unificado racional (RUP) Un metaproceso que se puede adaptar, por ejemplo, a un proceso iterativo, en espiral o
en cascada .
Refactorización Una transformación de código o diseño que mejora su estructura u otra calidad, mientras conserva su
comportamiento. Ver refactorización de arquitectura. (Fowler, 1999)
Arquitectura de referencia Una especificación que describe una solución arquitectónica prescrita para un problema. Los
proveedores o expertos suelen proponer arquitecturas de referencia como arquitecturas canónicas para problemas
determinados. Ver arquitectura presuntiva. (Bajo, Clements y Kazman, 2003)
344 Glosario
Refinamiento El refinamiento es una relación entre un modelo de bajo detalle y uno de alto detalle del mismo
cosa.
Diseño impulsado por la responsabilidad En contraste con pensar en datos y algoritmos, la responsabilidad
El diseño impulsado se centra en las funciones y responsabilidades.
Riesgo En este libro, el riesgo es la probabilidad percibida de falla multiplicada por el impacto percibido.
Modelo basado en riesgos El modelo de arquitectura de software basado en riesgos guía a los desarrolladores a aplicar un conjunto
mínimo de técnicas de arquitectura para reducir sus riesgos más apremiantes. Sugiere un proceso de cuestionamiento
implacable: “¿Cuáles son mis riesgos? ¿Cuáles son las mejores técnicas para reducirlas? ¿Se mitiga el riesgo y puedo comenzar
a programar?” El elemento clave del modelo impulsado por el riesgo es la promoción del riesgo a la prominencia.
Rol (1) En un diagrama de clases UML, el nombre al final de una asociación. (2) El extremo mecanografiado de un conector,
aproximadamente equivalente a un puerto en un componente. (3) En un patrón, una parte que se puede unir o sustituir por una
parte concreta en la implementación.
Tipo de vista en tiempo de ejecución (es decir, tipo de vista de componente y conector) El tipo de vista que contiene vistas de elementos
que puede ver en tiempo de ejecución. Incluye artefactos como escenarios de funcionalidad, listas de responsabilidad y
ensamblajes de componentes. Las instancias de componentes, conectores y puertos están en el tipo de vista de tiempo de
ejecución, al igual que los objetos (instancias de clase). Ver tipo de vista de módulo y tipo de vista de asignación.
Escala Al referirse al software, la escala generalmente se refiere al tamaño absoluto de un sistema, a menudo contado en líneas de
código. La escalabilidad (un atributo de calidad) se refiere a la capacidad de un sistema para manejar una carga mayor de la
que maneja actualmente, como ejecutarse en un hardware más grande (como en la escalabilidad vertical) o más copias del
hardware (escalabilidad horizontal). Algo confusa, la pregunta, "¿Se escalará?" se refiere a la escalabilidad de un sistema, no a
sus líneas de código.
Escenario Por lo general, se refiere a un escenario de funcionalidad, pero también podría referirse a un escenario de atributos de calidad.
Instantánea (es decir, diagrama de instancias) Un diagrama que muestra objetos o instancias de componentes en un instante
a tiempo.
Arquitectura de software Esta es la definición estándar de la SEI: “La arquitectura de software

de un sistema de cómputo es el conjunto de estructuras necesarias para razonar sobre el sistema, las cuales comprenden
elementos de software, relaciones entre ellos y propiedades visibles externamente de ambos.”
(Clements et al., 2010)
Software Engineering Institute (SEI) Un centro de investigación y desarrollo financiado con fondos federales cuya misión es “avanzar
en la ingeniería de software y disciplinas relacionadas para garantizar el desarrollo y la operación de sistemas con costos,
cronogramas y calidad predecibles y mejorados”.
Código fuente Las declaraciones del lenguaje de programación escritas por los desarrolladores que parecen crípticas para el
no iniciado
Tipo de vista de expansión El tipo de vista que contiene vistas que se cruzan entre dos o más tipos de vista. Un ejemplo de una
compensación que abarca los tipos de vista es: usted decide desnormalizar un esquema de base de datos (que se describiría
en el tipo de vista del módulo) para lograr un mayor rendimiento de transacciones (que se describiría en el tipo de vista en
tiempo de ejecución), por lo que describe que compensación en el tipo de vista de expansión.
Glosario 345
Proceso en espiral El proceso en espiral (Boehm, 1988) es un tipo de desarrollo iterativo, por lo que tiene muchas
iteraciones, sin embargo, a menudo se describe como que no tiene un trabajo de diseño inicial. Las iteraciones se priorizan
por riesgo, con la primera iteración manejando las partes más riesgosas de un proyecto. El modelo espiral
maneja tanto la gestión como los riesgos de ingeniería. Por ejemplo, puede referirse a “personal
insuficiencias” como un riesgo. El proceso en espiral no brinda orientación sobre la naturaleza del trabajo de diseño, o sobre
qué arquitectura y técnicas de diseño utilizar. Ver proceso en cascada, Programación extrema,
proceso iterativo y proceso ágil.
Parte interesada Un cliente u otra persona que tiene interés en las características o el éxito de un sistema.
Modelo de arquitectura estática Un modelo de un sistema que lo muestra en un instante en el tiempo o en su constante
configuración de estado. Ver modelo de arquitectura dinámica.
Historia en muchos niveles Una forma de estructurar su software de manera que cada nivel de anidamiento cuente una
historia sobre cómo interactúan esas partes. Un desarrollador que no estaba familiarizado con el sistema podría
dejarse caer en cualquier nivel y aún así tener sentido en lugar de ser inundado. su principal
el beneficio es cognitivo, no técnico.
Experto en la materia (SME) Un experto en el dominio, a veces un cliente.
Diagrama de contexto del sistema Diagrama de ensamblaje de componentes en el modelo de límites de nivel superior que
incluye el sistema (como componente) y sus conexiones (como conectores) a sistemas externos.
Ver diagrama de caso de uso.
Táctica En el diseño basado en atributos, una táctica es un tipo de patrón que es más grande que un patrón de diseño.
y más pequeño que un estilo arquitectónico. Los ejemplos de tácticas incluyen: ping/eco, redundancia activa, registro en
tiempo de ejecución, autenticación de usuarios y detección de intrusos (Bass, Clements
y Kazman, 2003).
Deuda técnica La desalineación acumulada del código con respecto al entendimiento actual
del problema (Cunningham, 1992; Fowler, 2009)
Técnica Una actividad de ingeniería de software realizada por los desarrolladores. Las técnicas existen en un espectro que va
desde el análisis puro, como el cálculo de las tensiones, hasta las soluciones puras, como usar un árbol volador en una
catedral. Otros libros de arquitectura y diseño de software han inventariado técnicas en el extremo de la solución del
espectro, y llaman a estas técnicas tácticas (Bass, Clements
y Kazman, 2003) o patrones (Schmidt et al., 2000; Gamma et al., 1995). Este libro se centra
en técnicas que están en el extremo del análisis del espectro, procedimentales e independientes de
el dominio del problema.
Diseño de arriba hacia abajo El diseño de arriba hacia abajo es el proceso de refinar una especificación de alto nivel de un elemento
(componente, módulo, etc.) en un diseño detallado al descomponer el elemento en
piezas más pequeñas y especificar esas piezas mediante la asignación de responsabilidades.
Modelo de límite de nivel superior El modelo de límite de nivel superior es el único modelo encapsulado superior
vista del modelo de diseño. Se puede refinar en un modelo interno para mostrar detalles de diseño internos no encapsulados.
Compensación A veces, obtener más de una cosa implica obtener menos de otra. Las compensaciones pueden
existen entre los atributos de calidad, como agregar seguridad puede compensar la usabilidad.
346 Glosario
Escenarios de dos niveles Un escenario de funcionalidad que se ha elaborado para mostrar un nivel adicional de mensajes
internos, como entre los componentes de un modelo interno.
Lenguaje ubicuo Un lenguaje común compartido por desarrolladores y expertos en el dominio, a diferencia de los desarrolladores
que usan un término y los expertos del dominio usan uno diferente para el mismo concepto. Véase diseño dirigido por
dominio.
Lenguaje de modelado unificado (UML) Un lenguaje de modelado común adecuado para diseños orientados a objetos.
firma y arquitectura de software.
Caso de uso Los casos de uso son en gran medida equivalentes a los escenarios de funcionalidad, pero existen algunas
diferencias importantes. Los casos de uso son actividades de alto nivel y visibles para los usuarios del sistema.
Los casos de uso a menudo se definen para lograr un objetivo de un actor fuera del sistema, por lo que las actividades
internas del sistema no contarían como casos de uso. Donde los escenarios de funcionalidad son un solo rastro de
comportamiento, los casos de uso pueden incluir pasos de variación que les permitan describir múltiples rastros.
Diagrama de casos de uso Un diagrama UML que muestra los actores, el sistema y los casos de uso.
Vista (es decir, proyección) Una vista muestra un subconjunto definido de los detalles de un modelo , posiblemente con una transformación
mación
Punto de vista La vista de un sistema desde una sola perspectiva, como la vista de una sola parte interesada.
Se utiliza en la definición IEEE de arquitectura de software. Los puntos de vista se utilizan en el enfoque de vistas como
requisitos, en lugar del enfoque de modelo maestro para las vistas.
Viewtype Un conjunto o categoría de vistas que se pueden conciliar fácilmente entre sí (Clements et al., 2010). Ver tipo de vista
de módulo, tipo de vista de tiempo de ejecución y tipo de vista de asignación.
Proceso en cascada El proceso en cascada (Royce, 1970) procede de principio a fin como un solo bloque largo de trabajo que
entrega todo el proyecto. Supone un trabajo de diseño planificado que se realiza en sus fases de análisis y diseño. Estos
preceden a la fase de construcción, que puede considerarse una sola iteración. Con solo una iteración, el trabajo no se
puede priorizar entre iteraciones, pero se puede construir de forma incremental dentro de la fase de construcción.
Consulte Programación extrema, proceso iterativo, proceso ágil y proceso en espiral.
XP Ver Programación Extrema.
Yinzer Un término del argot para alguien de Pittsburgh, sede de la Universidad Carnegie Mellon, y se deriva de yinz, que es el
dialecto de Pittsburgh equivalente a ustedes, la forma plural de ustedes.
Bibliografía
Abi-Antoun, Marwan, Wang, Daniel y Torr, Peter, Comprobación de los diagramas de flujo de datos de modelado de
amenazas para el cumplimiento de la implementación y la seguridad. en: ASE '07: Actas de la Vigésima Segunda
Conferencia Internacional IEEE/ACM sobre Ingeniería de Software Automatizada. ACM,
2007, págs. 393–396.
Aldrich, Jonathan, Chambers, Craig y Notkin, David, ArchJava: Conexión de la arquitectura de software con la
implementación. en: ICSE '02: Actas de la 24ª Conferencia Internacional
en Ingeniería de Software. Nueva York, NY, EE. UU.: ACM Press, 2002, págs. 187–197.
Alexander, Christopher, A Pattern Language: Towns, Buildings, Construction (Center for Environ
Serie Estructura mental). Prensa de la Universidad de Oxford, EE. UU., 1977.
Alexander, Christopher, La forma eterna de construir. Prensa de la Universidad de Oxford, 1979.
Ambler, Scott, Modelado ágil: prácticas efectivas para la programación extrema y el proceso unificado. Wiley, 2002.
Ambler, Scott, Resultados de la encuesta sobre la tasa de adopción ágil: febrero de 2008. Dr. Dobb's Journal, mayo de 2008
hhttp://www.ambysoft.com/surveys/agileFebruary2008.htmli.
Ambler, Scott, Arquitectura ágil: estrategias para escalar el desarrollo ágil. 2009 http://www.
agilemodeling.com/essays/agileArchitecture.htmi.
Amdahl, Gene, Validez del enfoque de procesador único para lograr la capacidad informática a gran escala
pabilidades Actas de la conferencia AFIPS, 30 de 1967, págs. 483–485.
Apache Software Foundation, sitio web de Hadoop. 2010 hhttp://hadoop.apache.orgi.
Babar, Muhammad Ali, un estudio exploratorio de prácticas arquitectónicas y desafíos en el uso

Enfoques ágiles de desarrollo de software. Conferencia de trabajo conjunto IEEE/IFIP sobre software
Architecture 2009 & European Conference on Software Architecture 2009 Septiembre 2009.
Bach, James, Calidad suficiente: más allá de la palabra de moda. IEEE Computer, 30 1997:8, págs. 96–98.
Barbacci, Mario et al., Atributos de calidad. Instituto de Ingeniería de Software, Universidad Carnegie Mellon, 1995 (CMU/
SEI-95-TR-021, ESC-TR-95-021). - Reporte técnico.
Barbacci, Mario R. et al., Talleres de atributos de calidad (QAW), tercera edición. Instituto de Ingeniería de Software,
Universidad Carnegie Mellon, 2003 (CMU/SEI-2003-TR-016). - Reporte técnico.
348 BIBLIOGRAFÍA
Barrett, Anthony et al., Planificación y ejecución de misiones dentro del sistema de datos de misiones. en: Actas
del Taller Internacional sobre Planificación y Programación del Espacio (IWPSS). 2004.
Bass, Len, Clements, Paul y Kazman, Rick, Arquitectura de software en la práctica. 2ª edición.
Addison-Wesley, 2003.
Bass, Len y John, Bonnie E., Vinculación de la usabilidad con patrones de arquitectura de software a través de
escenarios generales. Journal of Systems and Software, 66 2003:3, págs. 187–197.
Beck, Kent, patrones de mejores prácticas de Smalltalk. Prentice Hall PTR, 1996.
Beck, Kent and Andres, Cynthia, Explicación de la programación extrema: aceptar el cambio (2nd Edi
ción). 2ª edición. Addison-Wesley Professional, 2004.
Beck, Kent et al., Manifiesto para el desarrollo ágil de software. 2001 hhttp://agilemanifesto.orgi.
Beck, Kent y Cunningham, Ward, Un laboratorio para la enseñanza del pensamiento orientado a objetos. OOP
SLA '89: Actas de conferencias sobre sistemas, lenguajes y aplicaciones de programación orientados a
objetos, 1989, págs. 1–6.
Bloch, Joshua, Extra, Extra - Lea todo sobre esto: Casi todas las búsquedas binarias y Mergesorts están rotas.
Junio de 2006 hhttp://googleresearch.blogspot.com/2006/06/ extra-extra-read-all-about-it-nearly.htmli.
Boehm, Barry, Un modelo en espiral de desarrollo y mejora de software. Computadora IEEE, 21 (5)
1988, págs. 61–72.
Boehm, Barry y Turner, Richard, Equilibrando la agilidad y la disciplina: una guía para los perplejos.
Addison-Wesley Professional, 2003.
Booch, Grady, Presentación de arquitectura de software. 2004 hhttp://www.booch.com/architecture/

blog/artefactos/Software%20Architecture.ppti.
Booch, Grady et al., Análisis y diseño orientado a objetos con aplicaciones. 3ra edición. Addison Wesley
Professional, 2007.
Booch, Grady, Rumbaugh, James y Jacobson, Ivar, el usuario del lenguaje de modelado unificado
Guía. 2ª edición. Addison-Wesley Professional, 2005.
Bosch, Jan, Diseño y uso de arquitecturas de software: adopción y evolución de un enfoque de línea de productos
(ACM Press). Addison-Wesley Professional, 2000.
Bowker, Geoffrey C. y Star, Susan Leigh, Sorting Things Out: Classification and its Consences. Prensa del MIT,
1999.
Box, George EP y Draper, Norman R., Construcción de modelos empíricos y superficies de respuesta (Wiley
Series en Probabilidad y Estadística). Wiley, 1987.
Bredemeyer, Dana y Malan, Ruth, Bredemeyer Consulting. 2010 http://bredemeyer.comi.
Brooks, Frederick P, The Mythical Man-Month: ensayos sobre ingeniería de software. 2ª edición.
Buschmann, Frank et al., Arquitectura de software orientada a patrones Volumen 1: Un sistema de patrones.
Wiley, 1996.
Butler, Shawn A., Método de evaluación de atributos de seguridad: un enfoque de costo-beneficio. Procedimientos de
CISE 2002, 2002, págs. 232–240.
BIBLIOGRAFÍA 349
Carr, Marvin J. et al., Identificación de riesgos basada en taxonomía. instituto de ingenieria de software,
Universidad Carnegie Mellon, junio de 1993 (CMU/SEI-93-TR-6). - Reporte técnico.
Cheesman, John and Daniels, John, Componentes UML: Un proceso simple para especificar
Software basado en componentes. Addison-Wesley, 2000.
Chomsky, Noam, Estructuras sintácticas. 2ª edición. Walter de Gruyter, 2002.
Clements, Paul et al., Documentación de arquitecturas de software: vistas y más allá. 2ª edición.
Clerc, Viktor, Lago, Patricia y Vliet, Hans van, La mentalidad del arquitecto. Tercera Conferencia Internacional
sobre Calidad de Arquitecturas de Software (QoSA), 2007, pp. 231–248.
Cockburn, Alistair, Escritura de casos de uso efectivos (Serie de desarrollo de software ágil). Addison Wesley
Profesional, 2000.
Coleman, Derek, Desarrollo orientado a objetos: el método de fusión. Prentice Hall, 1993.
Conway, Melvin, ¿Cómo inventan los comités? Datamation, 14 (5) 1968, págs. 28–31.
Cook, Steve y Daniels, John, Diseño de sistemas de objetos: modelado orientado a objetos con sintropía. Prentice
Hall, 1994.
Cook, William, Sobre la comprensión de la abstracción de datos, revisado. OOPSLA: Actas de la conferencia sobre
sistemas, lenguajes y aplicaciones de programación orientada a objetos 2009.
Coplien, James O. and Schmidt, Douglas C., Lenguajes de patrones de diseño de programas. Addison
Wesley Professional, 1995.
Cunningham, Ward, El sistema de gestión de cartera WyCash. OOPSLA '92: Anexo a las actas sobre sistemas,
lenguajes y aplicaciones de programación orientada a objetos, 1992, págs. 29–30.
Dean, Jeffrey y Ghemawat, Sanjay, MapReduce: Procesamiento de datos simplificado en clústeres grandes.
OSDI'04: Sexto Simposio sobre Diseño e Implementación de Sistemas Operativos Diciembre 2004.
Denne, Mark y Cleland-Huang, Jane, Software by Numbers: Low-Risk, High-Return Development. Prentice Hall,
2003.
Dijkstra, Edsger, Declaración Go-to considerada dañina. Comunicaciones de la ACM, 11 1968:3,

págs. 147–148.
D'Souza, Desmond F., MAp: Enfoque basado en modelos para RoadMAps de arquitectura alineada con el negocio.
2006 hhttp://www.kinetium.com/map/demo/demo_index.htmli.
D'Souza, Desmond F. y Wills, Alan Cameron, Objetos, componentes y marcos con UML:
El enfoque de catálisis. Addison-Wesley, 1998.
Dvorak, Daniel, Encapsulación desafiante en el diseño de sistemas de control de alto riesgo. Actas de la Conferencia
de 2002 sobre Programación Orientada a Objetos, Sistemas, Lenguajes y Aplicaciones (OOPSLA) 2002.
Eden, Amnon H. and Kazman, Rick, Arquitectura, Diseño, Implementación. Conferencia Internacional sobre
Ingeniería de Software (ICSE), 2003, pp. 149–159.
Eeles, Peter y Cripps, Peter, El proceso de la arquitectura de software. addison wesley profesional,
2009.
350 BIBLIOGRAFÍA
Evans, Eric, Diseño impulsado por el dominio: abordar la complejidad en el corazón del software. Addison Wesley
Profesional, 2003.
Fairbanks, George, ¿Por qué no pueden crear modelos de arquitectura como "Desarrollador X"?: Informe de una
experiencia. en: ICSE '03: Actas de la 25ª Conferencia Internacional sobre Software
Ingenieria. 2003, págs. 548–552.
Fairbanks, George, Bierhoff, Kevin y D'Souza, Desmond, Arquitectura de software en general
Firma Financiera. Actas de la Conferencia ACM SIGPLAN sobre programas, sistemas, lenguajes y aplicaciones
orientados a objetos (OOPSLA) 2006.
Fay, Dan, una arquitectura para aplicaciones distribuidas en Internet: descripción general de .NET de Microsoft
Plataforma. Simposio internacional de procesamiento paralelo y distribuido de IEEE, abril de 2003.
Feather, Steven Cornford Martin and Hicks, Kenneth, DDP: una herramienta para la gestión del riesgo del ciclo de vida
mento Revista de sistemas electrónicos y aeroespaciales de IEEE, 21 2006:6, págs. 13–22.
Firesmith, Donald G., Conceptos comunes subyacentes a la ingeniería de seguridad, protección y supervivencia ing.
Instituto de Ingeniería de Software, Universidad Carnegie Mellon, diciembre de 2003 (CMU/SEI 2003-TN-033).
- Nota tecnica.
Foote, Brian y Yoder, Joseph, cap. 29, Gran Bola de Barro. En lenguajes de patrones de programa
Diseño 4. Addison-Wesley, 2000.
Fowler, Martin, Patrones de análisis: modelos de objetos reutilizables. Addison-Wesley Professional, 1996.
Fowler, Martin, Refactorización: Mejora del diseño del código existente. addison wesley profesional,
1999.
Fowler, Martin, Patrones de arquitectura de aplicaciones empresariales. Addison-Wesley Professional, 2002.

Fowler, Martin, UML destilado: una breve guía para el lenguaje de modelado de objetos estándar. 3ra edición.
Addison-Wesley Professional, 2003a.
Fowler, Martin, ¿Quién necesita un arquitecto? Software IEEE, 20 (5) 2003b, págs. 11–13.
Fowler, Martin, ¿Ha muerto el diseño? 2004 hhttp://martinfowler.com/articles/designDead.htmli.
Fowler, Martin, Deuda técnica. Febrero de 2009 hhttp://martinfowler.com/bliki/TechnicalDebt.
htmli.
Gabriel, Richard P., Lisp: Buenas noticias Malas noticias Cómo ganar en grande. AI Expert, 6 1994, págs. 31–39
hhttp://www.laputan.org/gabriel/peor-es-mejor.htmli.
Gamma, Erich et al., Patrones de diseño: Elementos de software orientado a objetos reutilizable (Addison
WesleyProfessional Computing Series). Addison-Wesley Professional, 1995.
Garlan, David, Curso de Arquitectura de Software. 2003 hhttp://www.cs.cmu.edu/~garlan/courses/
Arquitecturas-S03.htmli.
Garlan, David, Allen, Robert y Ockerbloom, John, Discrepancia arquitectónica o Por qué es difícil
para construir sistemas a partir de piezas existentes. en: Actas de la 17ª Conferencia Internacional
en Ingeniería de Software (ICSE). Seattle, Washington, abril de 1995, págs. 179–185.
Garlan, David, Monroe, Robert T. and Wile, David, Acme: Descripción arquitectónica de
Sistemas Basados en Componentes. en: Leavens, Gary T. y Sitaraman, Murali, editores: Foundations of
Component-Based Systems. Cambridge University Press, 2000. – capítulo 3, págs. 47–
67.
Garlan, David y Schmerl, Bradley, página web de AcmeStudo. 2009 hhttp://www.cs.cmu.edu/

~acme/AcmeStudio/index.htmli.
BIBLIOGRAFÍA 351
Gluch, David P., Una construcción para describir los riesgos de desarrollo de software. Instituto de Ingeniería de
Software, Universidad Carnegie Mellon, julio de 1994 (CMU/SEI-94-TR-14). - Reporte técnico.
Gorton, Ian, Arquitectura de software esencial. Springer, 2006.
Harrison, William H. y Ossher, Harold, Programación orientada al sujeto (una crítica de los objetos puros). Actas
de la Conferencia de 1993 sobre programación, sistemas, lenguajes y aplicaciones orientados a objetos
(OOPSLA), 1993, págs. 411–428.
Heineman, George T. y Councill, William T., Ingeniería de software basada en componentes: juntando las piezas.
Hoff, Todd, Arquitectura amazónica. 2008a hhttp://highscalability.com/amazon-architecturei.
Hoff, Todd, cómo Rackspace ahora usa MapReduce y Hadoop para consultar terabytes 30 de enero de 2008b
de datos. HighScalability.com, cómo- hhttp://highscalability.com/
rackspace-ahora-usa-mapreduce-y-hadoop-query-terabytes-datai.
Hofmeister, Christine, Nord, Robert y Soni, Dilip, Arquitectura de software aplicada. Addison
Wesley, 2000.
Holmes, James, Struts: La referencia completa, 2ª edición. McGraw-Hill Osborne Media, 2006.
Holmevik, Jan R., Compilación de SIMULA: un estudio histórico de la génesis tecnológica. IEEE Anales de
the History of Computing, 16 1994:4, pp. 25–37.
Holzmann, Gerard J., The SPIN Model Checker: manual básico y de referencia. Addison-Wesley Professional,
2003.
Hood, Stu, MapReduce en Rackspace. Enero de 2008 hhttp://blog.racklabs.com/?p=66i.
Ingham, Michel D. et al., Sistemas integrados complejos de ingeniería con análisis de estado y el sistema de datos
de la misión. AIAA Journal of Aerospace Computing, Information and Communication, 2 de diciembre de
2005: 12, págs. 507–536.
Jackson, Daniel, Alloy: una notación de modelado de objetos ligeros. ACM Transactions on Software Engineering
and Methodology (TOSEM'02), 11 de abril de 2002:2, págs. 256–290.
Jackson, Michael, Requisitos y especificaciones del software. Addison-Wesley, 1995.
Jackson, Michael, Marcos de problemas: análisis y estructuración de problemas de desarrollo de software.
Jacobson, Ivar, Booch, Grady y Rumbaugh, James, The Unified Software Development Pro
impuesto. Addison-Wesley Profesional, 1999.
Kay, Alan, Prediciendo el Futuro. Stanford Engineering, 1 de otoño de 1989: 1, págs. 1–6.
Kruchten, Philippe, El proceso unificado racional: una introducción. 3ra edición. Addison-Wesley Professional,
2003.
Larman, Craig and Basili, Victor R., Desarrollo iterativo e incremental: una breve historia. IEEE
Computer, 36 2003:6, págs. 47–56.
Lattanze, Anthony J., Arquitectura de sistemas intensivos de software: una guía para profesionales. Publicaciones
de Auerbach, 2008.
Liskov, Barbara, Conferencia magistral - Abstracción y jerarquía de datos. Conferencia sobre lenguajes y
aplicaciones de sistemas de programación orientados a objetos, 1987, pp. 17 - 34.
Luhmann, Niklas, La sociedad moderna conmocionada por sus riesgos. Centro de Investigación de Ciencias
Sociales: Documentos ocasionales, 1996 hhttp://hub.hku.hk/handle/123456789/38822i.
352 BIBLIOGRAFÍA
Magee, Jeff y Kramer, Jeff, Concurrency: State Models and Java Programs. 2ª edición. Wiley,
2006.
Maranzano, Joseph, Revisiones de arquitectura: práctica y experiencia. IEEE Computer, 2005, págs. 34–
43.
Martin, Robert, La escatología de la arquitectura ágil. Abril de 2009 hhttp://blog.objectmentor.com/articles/2009/04/25/the-

scatology-of-agile-architecturei .
Meier, JD et al., Listas de verificación para arquitectura de aplicaciones. 2003 hhttp://www.codeplex.com/

wikipage?ProjectName = AppArch & title = Checklistsi.
Meyer, Bertrand, Construcción de software orientada a objetos. 2ª edición. Prentice Hall PTR, 2000.
Meyer, Kenny, sitio web del sistema de datos de la misión. 2009 hhttp://mds.jpl.nasa.govi.
Miller, Granville, Desarrollo de software ágil de segunda generación. Marzo de 2006 hhttp://blogs.
msdn.com/randymiller/archive/2006/03/23/559229.aspxi.
Monson-Haefel, Richard, Enterprise JavaBeans. 3ra edición. O´Reilly, 2001.
Moriconi, Mark, Qian, Xiaolei y Riemenschneider, RA, Correct Architecture Refinement.

IEEE Transactions on Software Engineering, 21 1995:4, págs. 356–372.
Nyfjord, Jaana, Hacia la integración del desarrollo ágil y la gestión de riesgos. Tesis doctoral, Universidad de Estocolmo,
2008.
Oreizy, Peyman, Medvidović, Nenad and Taylor, Richard N., Adaptación de software en tiempo de ejecución: marco,
enfoques y estilos. en: ICSE Companion '08: Companion of the 30th International Conference on Software
Engineering. ACM, 2008, págs. 899–910.
Alianza OSGi, sitio web de OSGi. 2009 hhttp://www.osgi.orgi.
Ould, Martin, Procesos comerciales: modelado y análisis para reingeniería y mejora.

John Wiley and Sons, 1995.
Parnas, David, Fundamentos de software: artículos recopilados de David L. Parnas. Addison Wesley Pro
profesional, 2001, Editores: Daniel M. Hoffman y David M. Weiss.
Perry, Dewayne E. and Wolf, Alex L., Fundación para el Estudio de la Arquitectura de Software. MCA
SIGSOFT Software Engineering Notes, 17 1992:4, pp. 40–52.
Petroski, Henry, Paradigmas de diseño: historias de casos de error y juicio en ingeniería. Leva
prensa universitaria del puente, 1994.
Polya, George, Cómo resolverlo: un nuevo aspecto del método matemático (Biblioteca de Ciencias de Princeton).
Prensa de la Universidad de Princeton, 2004.
Rosch, Elanor y Lloyd, Bárbara; Rosch, Elanor and Lloyd, Barbara, editores, Cognición y Categorización. Lawrence
Erlbaum, 1978.
Ross, Jeanne W., Weill, Peter y Robertson, David, Arquitectura empresarial como estrategia: creación de una base para
la ejecución empresarial. Prensa de la Escuela de Negocios de Harvard, 2006.
Royce, Winston W., Gestión del desarrollo de grandes sistemas de software: conceptos y técnicas. en: Documentos
técnicos de Western Electronic Show and Convention (WesCon). 1970.
Rozanski, Nick and Woods, Eóin, Arquitectura de sistemas de software: trabajar con las partes interesadas utilizando
puntos de vista y perspectivas. Addison-Wesley Professional, 2005.
Schmidt, Douglas et al., Arquitectura de software orientada a patrones Volumen 2: Patrones para objetos concurrentes y
en red. Wiley, 2000.
BIBLIOGRAFÍA 353
Schmidt, Douglas C. and Buschmann, Frank, Patterns, Frameworks, and Middleware: Their Synergistic Relations. en:
ICSE '03: Actas de la 25ª Conferencia Internacional sobre
Ingeniería de software. Washington, DC, EE. UU.: IEEE Computer Society, 2003, págs. 694–704.
Schuh, Peter, Integración del desarrollo ágil en el mundo real. Charles River Media, 2004.
Biblioteca SEI, Biblioteca del Instituto de Ingeniería de Software. 2009 hhttp://www.sei.cmu.edu/libraryi.
Selic, Bran, Brass Bubbles: una descripción general de UML 2.0 (y MDA). 2003a hhttp://www.omg.org/
noticias/reuniones/talleres/UML%202003%20Manual/Tutorial7-Hogg.pdfi.
Selic, Bran, La pragmática del desarrollo dirigido por modelos. Software IEEE, 20 2003b:5, págs. 19–25.
Shaw, Mary, Abstracción, tipos de datos y modelos para software. Avisos ACM SIGPLAN, 16 de enero
1981:1, págs. 189–91.
Shaw, Mary y Clements, Paul, Una guía de campo para la boxología: clasificación preliminar de estilos arquitectónicos
para sistemas de software. proc. COMPSAC97 21st Int'l Software Informático y
Conferencia de aplicaciones, 1997, págs. 6–13.
Shaw, Mary y Garlan, David, Arquitectura de software: perspectivas sobre una disciplina emergente.
Prentice Hall, 1996.
Simon, Herb, Las Ciencias de lo Artificial. 2ª edición. Prensa del MIT, 1981.
Society, IEEE Computer, IEEE 1471-2000 Práctica recomendada de IEEE para la descripción arquitectónica de sistemas
intensivos en software. Edición IEEE Std 1471-2000. Comité de Estándares de Ingeniería de Software de la IEEE
Computer Society, 2000.
Sutherland, Dean, El código de muchos colores: Razonamiento semiautomático sobre la política de subprocesos múltiples
para Java. Tesis doctoral, Instituto de Investigación de Software de la Universidad Carnegie Mellon, 2008,
hhttp://reports-archive.adm.cs.cmu.edu/anon/isr2008/CMU-ISR-08-112.pdfi.
Szyperski, Clemens, Software de componentes: más allá de la programación orientada a objetos. 2ª edición.
Tarr, Peri L. et al., N Grados de separación: Separación multidimensional de preocupaciones. en: Congreso Internacional
de Ingeniería de Software. 1999, págs. 107–119.
Taylor, Richard, Medvidović, Nenad y Dashofy, Eric, Arquitectura de software: Fundamentos, La

teoría y práctica. Wiley, 2009.
The Open Group, TOGAF Versión 9 - Un manual. 9ª edición. Editorial Van Haren, 2008.
Venners, Bill, Una conversación con Martin Fowler, Parte III. Desarrollador Artima, 2002 hhttp://www.
artima.com/intv/evolutionP.htmli.
Warmer, Jos y Kleppe, Anneke, El lenguaje de restricción de objetos: preparación de sus modelos
para MDA. 2ª edición. Addison-Wesley Professional, 2003.
Whitehead, Alfred North, Introducción a las matemáticas. Reimpresión de libros olvidados 2009, 1911.
Wing, Jeannette M., Un estudio de 12 especificaciones del problema de la biblioteca. Software IEEE, 5 1988:4,
págs. 66–76.
Wirfs-Brock, Rebecca, Wilkerson, Brian y Wiener, Lauren, Diseño suave orientado a objetos
mercancía. PTR Prentice Hall, 1990.
Wisnosky, Dennis E., DoDAF Wizdom: una guía práctica. Prensa de sabiduría, 2004.
Zachman, John, Un marco para la arquitectura de sistemas de información. Diario de sistemas de IBM, 26 (3)
1987, págs. 276–292.
Índice
4+1 vistas arquitectónicas, 119, 125, 160, 304, 311 empresa, 30, 338
frente a desarrollador,
viii, 30 estilo arquitectónico, 5, 56, 156, 266, 271,
tipo de datos abstractos (ADT), 124, 204, 205, 208 334 Platónico y encarnado, 273 Método de
abstracción, 3, 6, 27, 90, 104, 105, 112, 123, 194, análisis de compensación arquitectónica (ATAM),
200, 299, 317 fuga, 202 complejidad 248, 313 estilo de codificación
accidental, 169 precisión, 297 arquitectónicamente evidente, 165, 169, 172, 326,
334 arquitectura, 16, 342 y funcionalidad,
5, 20 lista de verificación, 312 deriva, 67, 71, 334
Ackoff, Russell, 45 controlador, 42, 70, 75, 80, 150, 151, 199,
especificación de acción, 174, 204, 307, 333 200, 248, 250, 334 empresa, 30, 34 erosión,
diagrama de actividad, 136, 144, 236 ágil, ix, 67 elevación, 16, 24, 27, 29, 30, 32, 183,
8, 9, 52, 55–57, 62, 333 187, 189, 274, 329, 334 lo suficiente, 8, 10,
Aldrich, Jonathan, 60, 90 patrón, 275 refactorización, 58 ,
elemento de asignación viii , 334 revisión, 41, 312, 313 lenguaje de
212, 333 tipo de vista de asignación, 46, 158, 177, descripción de arquitectura (ADL), 46, 162,
258, 304, 333 318, 334 diseño centrado en la arquitectura,
Comprobador de modelo de aleación, 315 26, 27, 50, 78, 274, 329, 330, 334
Ambler, Scott, 9 diseño indiferente a la arquitectura, 25, 329,
modelo analógico, 45, 333 334 ArchJava, 112, 168 programación
análisis, 8, 258 parálisis de orientada a aspectos, 209 afirmaciones, 182
análisis, 94, 111, 130, 333, 335 patrón de asociación, 131 archivo adjunto, consulte el
análisis, 275 modelo analítico, 45, 333 instancia archivo adjunto del puerto
anónima, 214, 334
Puntales Apache, 183, 190

servidor web apache, 156
Interfaz de programación de aplicaciones (API),
45, 69, 189, 201, 243, 317, 334
arquetipo, 198 arquitecto, 7 aplicación, 30, 334
356 ÍNDICE
atención, 32, 298 diagrama de componente y conector, consulte tipo de

Diseño basado en atributos (ADD), 62, 199, 247, 249 vista de componente y conector de
ensamblaje de componente , consulte ensamblaje de
componente de tipo de vista de tiempo de
riesgos integrados, 335 ejecución, 145, 152, 217–220, 336
estilo secuencial por lotes, 281
Beck, Kent, 173 desarrollo basado en componentes, 216, 336
Bierhoff, Kevin, 62 estilo composición, 259 integridad conceptual, 21, 246, 278
gran bola de barro, 7, 24, 28, 57, 169, 278, 319 modelo conceptual, 5, 10, 336 preocupación, 160,
256, 301 conexión, 212, 336 conector, 71, 146, 147,
Big Design Up Front (BDUF), 49, 89, 93, 335 221–224 , 226–230, 336
encuadernación, 77, 153, 218, 230, 243, 266, 335
Bloch, Josué, 265
Boehm, Barry, 9, 59, 61
Booch, Grady, 61, 296, 321 binario, 226, 335
Bosch, Ene, 124, 198 elegir, 223 delegación
modelo de límites, 76, 115, 122, 141, 157, 196, 197, 229, (UML), 244 dominio, 228, 337
263, 317, 335, 337 puentes de Königsberg, objetivo, 227, 338 instancia,
265 221 microgestionado, 227, 339
Brooks, Frederick, 3, 21, 33
hermano, 17, 255, 259 brownfield,
62, 297 modelo de negocio, 121, N-way, 226, 340
122, 125, 127, 335 propiedades, 224
Mayordomo, Shawn, 315 refinamiento, 229
sustitución, 223 tipo,
estructura del modelo canónico, 114, 116, 139, 335 221 consistencia, 297
nivel de detalle consistente,
dibujos animados, 105, 106, 296 299 restricción, 6, 20–22, 154, 237,
Catálisis, 137, 164, 269 cadena 272, 277, 339 integración continua, 49
de intencionalidad, 18, 249 checklist,
arquitectura, 41, 124 Ley de Conway, 95
Cheesman, John, 124, 198 Cook, William, 209 tipo
Chomsky, Noam, 162 de núcleo, 198
Responsabilidad de Clase y Colaborador (CRC), 154 COTS (comercial listo para usar), 75, 336
CRUD, 318
clase frente a tipo, 260 Cunningham, barrio, 176
clasificación, 134, 260, 335 Cleland-
Huang, Jane, 61 estilo cliente- D'Souza, Desmond, 21, 125, 269, 321 Daniels,
servidor, 6, 286 semántica de John, 124, 198 Dashofy, Eric, 164 diagrama de
refinamiento cerrado, 219, 263, 335 entrenador, 1, 5, 11, flujo de datos (DFD), 315 estilo centrado en datos,
90, 111, 139 modelo de código, 115, 122, 165, olor de consulte la base de datos de estilo centrado en el
código 335 , canal de comunicación 57 , 149, 212, modelo, 4, 23, 26 , 105, 216 conocimiento declarativo, vii
diagrama de conmutación 336 , 104, componente 329 , definir vs designar, 262 Denne, Mark, 61 dependencia, 39,
5, 71, 146, 213–216, instancia 336 , 146, tipo 213 , 146, 69, 149, 186, 238, 267, 304 modelo descriptivo vs
147, 213 prescriptivo, 318
ÍNDICE 357
diseño por contrato, 174, 336 Foote, Brian, 7, 57, 278

decisión de diseño, 33, 49, 50, 58, 71, 93, 148, 166, 168, Fowler, Martin, 9, 33, 62 marco,
231, 251, 336 intención de diseño, 165, 20, 45, 56, 96, 338 arquitectura
172, 173, 232, 336 modelo de diseño, 115, 140, 337 empresarial, 34 funcionalidad, 3,
patrón de diseño, 2, 62, 104, 113, 174, 177, 179–181, 5, 19, 245 escenario de funcionalidad,
187, 216, 271–273, 283, 325 135, 151, 160, 232– 235, 338 animación, 236 , 306 dos
niveles, 235, 236, 343
designación, 114, 116, 140, 261, 335, 337 perilla de

detalle, 300 diseño detallado, 16 desarrollador vs.
arquitecto, viii, 30 Dijkstra, Edsger, 6, 159 sistema de Gabriel, Ricardo, 279
archivos distribuido, 4, 6 divide y vencerás, 2, 160 , Gama, Erich, 62
paquete de documentación 301 , 36, 38, 58, 124, 337 Garlan, David, viii, 16, 93, 125, 164, 296, 308, 316
DODAF, 34 diseño controlado por dominio, 175, generalización, 133, 213, 260, 338 análisis
modelo de dominio 337 , 115, 122, descomposición global, 61
dominante 337 , 196, controlador 337 , ver controlador
de arquitectura Dvorak, Daniel, 32, 196 modelo de Gorton, Ian, 124
arquitectura dinámica, 161, 337 invariante dinámico, 237 GOTO Considerado nocivo, 6, 159
greenfield, 62, 297 rieles de guía, 20, 154,
237, 272, 276, 330
Sistema de archivos distribuido Hadoop, 4

Hadoop map-reduce, 4, 291
descomposición jerárquica, 195
Hofmeister, Christine, 61
Eclipse, viii, 29, 182, 183
elevación, véase arquitectura elevación
Eden, Amnon, 167
encapsulación efectiva, 202 estilo
arquitectónico incorporado, 273, 320 icono (UML), 243
encapsulación, 140, 201, 202, 337 arquitectura IEEE 1471-2000 estándar, 125
empresarial efectiva, 337 , ver arquitectura, económico, 300 modelo de información,
empresa, 338 131, 338 tecnología de la información
(TI), 339 instancia, 134, 260 diagrama de
Enterprise Java Beans (EJB), 124, 183, 271 elemento instancia, 134 intensional, 167, 168, 339
ambiental, 5, 149, 212, 333, 336, 338 interfaz, 76, 115, 124, 140, 141 , 145, 148,
153, 157, 159, 174, 193, 199, 202, 204,
Euler, Leonhard, 265 205, 214, 217, 223, 229, 234, 238, 240–242, 277, 278,
event bus, 285, 338 diseño 317, 325, consulte Programación de
evolutivo, 49, 63, 338 extensional, 167, aplicaciones Modelo interno de interfaz
168, 338 (API), 115, 122, 141, 197, 229, 337, 339
Programación extrema (XP), 52, 54, 338 invariable, 133, 174, 237, 336, 339 iteración,
56, 339 iteración cero, 54, 56, 338 desarrollo
falla, 35 iterativo, 53, 339
escenarios de falla, 40
falsabilidad, 298 padre,
8, 36, 103, 259 acumulación
de características, 56
Procesos de estado finito (FSP), 315
358 ÍNDICE
Jackson, Michael, 45, 125, 228, 262, 269 ingeniería impulsada por modelos,
Jacobson, Ivar, 61 49 estilo centrado en modelos, 282
Lenguaje de modelado Java (JML), 182 brecha de código de modelo, 168,
Johnson, Ralph, viii, 33 340 principio de modelo en código, 172, 175, 340
conductor de autobús de broma, módulo, 5, 148, 237, 340 ensamblaje .NET, 184
97 llaves de coche, 296 paquete OSGi, 184 propiedades , 238
bombero, 329 naturaleza
de un objeto, 231
tipo de vista de módulo, 46, 157, 176, 258, 304, 340
vistas monotemáticas, 300
Kay, Alan, 2, 113
Kazman, Rick, 167 Análisis de Monte Carlo, 315
Kruchten, Philippe, 119, 160, 304, 321 madre, 142 productora de cine,
30, 338 separación
Analizador de sistemas de transición etiquetados (LTSA), multidimensional de preocupaciones, 209
315
ley
Amdahl, 23, 33 Estilo de N niveles, 7, 8, 185, 287
Brooks', 33 puente angosto, 262
Conway's, 33 NASA/JPL, 32, 161, 272
capas, 239, 277, diagrama navegación, 133, 340
de 339 capas, estilo de creatividad innecesaria, 21
68 capas, 239, 275 enlace, anidamiento, 140, 194, 195, 215, 238, 263 nodo,
134, 339 5, 149, 212, 336
Principio de sustitución de Liskov, 260 Nord, Robert, nota
diseño pequeño al frente, 50 diseño local, 61 (UML), 133
49 telar, 142 Nyfjord, Jaana, 62
Lenguaje de restricción de objetos (OCL), 133, 237, 340

mailbox, 8, 36 estrategia ofensiva, 2, 90
map-reduce style, 4, 6, 8, 200, 289, 330
marketecture, 298 Martin, Robert, 9 master model, Opdyke, William, 57
120, 140, 257, 301, 302, 339 Medvidović, Nenad, semántica de refinamiento abierto, 263, 340
164 Middleware orientado a mensajes (MOM), 124 Meta costo de oportunidad, 44 problema de
Object Facility (MOF), 261 metamodelado , 261 Meyer, optimización, 44
Bertrand, 174, 336 Meyer, Kenny, 33 Microsoft .NET, OSGi, 183
184 MIL-STD-882D, 42 Miller, Granville, 9 diseño
planificado mínimo, 50, 339 estilo reflejado, 291 Sistema Módulo Parnas, 203, 340
de datos de misión (MDS), 32, 161, 272, 274 verificador Parnas, David, 202
de modelos, 315 partición, 2, 195, 259, patrón
340 , 43, 271, 340, 343
arquitectura empresarial, 34 estilo
peer-to-peer, 8, 185, 288
Petroski, Enrique, 35
Philippe Kruchten, 311 estilo
de tubería y filtro, 185, 186, 198, 279 diseño
planificado, vii, 7, 36, 49, 51, 53, 63, 89 juego de
planificación, 56
ÍNDICE 359
Estilo arquitectónico platónico, 273, 320 Polya, relación (modelo de información), 131, 338 estilo de
George, 45 port, 77, 122, 145–148, 153, 180, repositorio, véase estilo centrado en el modelo
200, 206, 207, 239–243, 340 adjunto, 244 provisto y Transferencia de estado representacional (REST), 275
requerido, 239 condición posterior, consulte requisito extrafuncional, 244, 341 responsabilidad, 71, 154
especificación de acción arquitectura de PowerPoint, diseño basado en la responsabilidad, 154, 184, 341
298 condición previa, ver especificación de acción revisión, consulte el riesgo de revisión de arquitectura, 8,
predictivo, 298 modelo prescriptivo vs. descriptivo, 318 37, 39–42, 341 trabajo atrasado, 56 integrado, 52 riesgo
arquitectura presuntiva, 23, 341 priorización de riesgos, 42 de ingeniería, 40 matriz, 42 riesgo de gestión de proyectos,
problemas para encontrar vs. probar, 45 conocimiento 40 modelo basado en el riesgo, 8, 36, 37, 342
procedimental, vii riesgo de gestión de proyectos, 341
proyección, 119, 254, 344 promover la comprensión, 298
prueba de concepto, 341 propiedad, 148, 341 prototipo, 66,
96, 260, 329, 341 riesgos prototípicos en el dominio, 41,
341 pruebas y pruebas, 310 estilo de publicación-suscripción,
284
Robertson, David, 34 rol,

342 extremo del conector,
226
UML, 133
novato, 2, 5, 90, 111, 139
Rosch, Elanor, 260
Ross, Juana, 34
Rouquette, Nicolás, 32
Rumbaugh, James, diagrama
de tiempo de ejecución 61 , consulte tipo de vista de
atributo de calidad, 5, 18, 19, 99, 142, 150, 244–246, 250,
tiempo de ejecución de ensamblaje de componentes, 46,
251, 341 naturaleza emergente, 142 escenario
68, 158–160, 177, 186, 190, 213, 214, 221,
de atributos de calidad, 150, 151, 232, 247, 248,
237, 258, 271, 304, 342
312, 341 taller de atributos de calidad, 41 , 248, 312 teoría
de colas, 47, 315
escenario, ver escenario de funcionalidad, ver escenario
de atributos de calidad
Scherlis, William, viii
estilo estante, 292 Selic, Bran, 296, 321
Rackspace, análisis diagrama de secuencia, 232, 236

monotónico de tasa 3–5 , 47, 315 elección estilo de granja de servidores, 292
de arquitectura racional, 92, 341 Arquitectura orientada a servicios (SOA), 124 estilo de
Rational Unified Process (RUP), 54, 94, 125, 341 datos compartidos, consulte estilo centrado en el modelo
refactorización, 49, 341 arquitectura, consulte Shaw, Mary, 2, 16, bala de
arquitectura refactorización arquitectura de referencia, 23, plata 104 , 3
341 integridad referencial, 298 refinamiento, 114, Simon, Herbert, 209, 298 sumidero
117, 141, 142, 229, 262, 269, 335, 341 mapa de refinamiento, y fuente, 279
263, 327 cosificación, 178 Skype, 289
instantánea, 83–85, 134, 135, 206, 207, 342 arquitectura
de software, ver arquitectura proceso de desarrollo de
software, vii, viii, 7–10, 27, 30, 36, 39, 48, 49, 51–53 , 55,
57, 89, 91, 94
Reinholtz, Kirk, 32
360 ÍNDICE
Instituto de Ingeniería de Software (SEI), 15, 33, 62, 113, tipo (modelo de información), 131, 338 tipo
122, 164, 199, 212, 246, 249, 342 espacio contra clase, 260 tiranía de la descomposición
de soluciones, 22, 99 dominante, 196, 337
Soni, Dilip, 61
fuente y sumidero, 279 lenguaje ubicuo, 128, 136, 343
vista panorámica, 158–160, 342 Lenguaje de modelado unificado (UML), 46, 113, 122, 123,
n.° de especificación, 182 132, 162, 164, 166, 261, 331, 343
Verificador de modelo giratorio,
modelo espiral 315 , 9, 54, 55, 90, 94, 342 Proceso unificado, 54
SQL, 72, 151, 222, 225 etapa, diseño inicial, consulte caso de uso de diseño
281 parte interesada, viii, 27, planificado, 143, 232, 344 diagrama de caso
40, 42, 90, 107, 109, 119, 125, 151, 157, 247, 248, 257, de uso, 143, 344 interfaz de usuario, 318
297, 312, 315, 343 estado diagrama, 136, relación de usos, 277
224, 236 modelo de arquitectura estática,
343 invariante estática, 237 configuración de estado
estable, 161, 315 estereotipo, 122, 132, 224, 225, 238, vista, 114, 118, 160, 254, 344
243 historia en muchos niveles, 193–195, 299, 319, 343 coherencia de vista, 119, 255, 257, 327 punto
estilo, arquitectónico, consulte el subcomponente de estilo de vista, 157, 344 vistas como requisitos, 257
arquitectónico, 77, 194–196, 198, 213, 215, 230, 235, 243, tipo de vista, 46, 157, 160, 258, 344 máquina
265, 299, 303 experto en la materia (SME), 120, 128, 132, virtual, 277 virtuoso, 3, 43, 112
136, 297, 343 programación orientada a temas, 209
subtipos y supertipos, 260
cascada, 27, 53, 111, 344

Bien, Peter, 34
Whitehead, Alfredo, 113
Wills, Alan, 269, 321 peor
es mejor, 279
Syntropy, 121
diagrama de contexto del sistema, 145, 217, 336, 343 hermanos Wright, 44
Szyperski, Clemens, 217

XP, consulte Programación extrema (XP)
táctica, 43, 199, 343

Yinzer, 113, 344
taxonomía, 261
Yoder, José, 7, 278
Taylor, Richard, 164
deuda técnica, 57, 80, 176, 278, 343 técnica,
Marco Zachman, 34 acercar y
35–39, 42–44, 343 caso de prueba, 45, 49, 151,
alejar, 264
310 diseño basado en pruebas, 49 pruebas y
demostraciones, 310 amenaza modelado, 47
niveles, 287
TOGAF, 34
diseño de arriba hacia abajo, 95, 196,
343 compensación, 5, 29, 51, 68, 70, 92, 99, 107, 152,
158, 160, 250, 251, 274, 302, 313, 330, 343
Turner, Ricardo, 61 años

Just Enough Software Architecture Fairbanks 2010-Demo

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Just Enough Software Architecture Fairbanks 2010-Demo

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Machine Translated by Google

Elogio por la arquitectura de software Just Enough: un enfoque basado en el riesgo

—Michael Keeling, ingeniero de software profesional

—Paulo Merson, arquitecto de software en ejercicio y

-Dr. Bradley Schmerl, científico sénior de sistemas, Facultad de Ciencias

—Christopher Dean, arquitecto jefe, XIM,

—Nicholas Sherman, administrador de programas, Microsoft

-Dr. Ian Maung, vicepresidente sénior de arquitectura empresarial de Citigroup y

—Desmond D'Souza, autor de MAp y Catálisis, Kinetium, Inc.

-Dr. Kevin Bierhoff, ingeniero de software profesional

—Dr. Shang-Wen Cheng, ingeniero de software de vuelo

Un enfoque basado en el riesgo

Publicado por Marshall & Brainerd 2445

Copyright © 2010 George Fairbanks

Número de control de la Biblioteca del Congreso: 2010910450

Primera impresión, agosto de 2010

En la década de 1990, la arquitectura de software surgió como un subcampo explícito de la ingeniería de

Y, sin embargo, a pesar de la existencia de este cuerpo de material, atención de principios a

Profesor, Facultad de Ciencias de la Computación

Democratiza la arquitectura. Es posible que tenga arquitectos de software en su organización; de

Proporciona consejos prácticos. Este libro ofrece un tratamiento práctico de la arquitectura.

¿Para quién es este libro?

Desarrolladores o estudiantes Greenhorn. Si ya ha aprendido la mecánica básica del

Desarrolladores experimentados. Si eres bueno en el desarrollo de sistemas, entonces

Académica. Este libro hace varias contribuciones al campo de la arquitectura de software.

I Arquitectura de software orientada al riesgo 13

2 Arquitectura de software 2.1 15

2.2 ¿Por qué es importante la arquitectura de software? . . ... ... ... . . . . . 18

2.8 Izado de arquitectura . . ... ... ... . . ... ... ... . . . . . 27

3 Modelo impulsado por el riesgo 35

4 Ejemplo: Home Media Player sesenta y cinco

4.1 Comunicación del equipo . . . . ... ... . . ... ... ... . . . . . 67

II Modelado de Arquitectura 101

6 Los ingenieros usan 103

7 Modelo Conceptual de Arquitectura de 111

8 El modelo de dominio 127

9 El modelo de diseño 139

10 El modelo de código 167

11 Encapsulación y partición 195

12 elementos del modelo 213

15 Uso de modelos de arquitectura 297

15.10 Modelos prescriptivos vs descriptivos . . . . . ... ... ... . . . . . 320

1.1 Particionamiento, conocimiento y abstracciones

• Conocimiento. Los desarrolladores de software usan el conocimiento de problemas anteriores para

1Mary Shaw ha señalado que al dividir y conquistar, dividir es la parte fácil.

1.2. TRES EJEMPLOS DE ARQUITECTURA DE SOFTWARE 3

• Abstracción. La abstracción puede combatir eficazmente la complejidad y la escala porque reduce

1.2 Tres ejemplos de arquitectura de software

1.4 Cambio de perspectiva

1.5. ARQUITECTOS ARQUITECTURAS ARQUITECTURAS 7

1.5 Arquitectos construyendo arquitecturas

• El puesto de trabajo: arquitecto. Un posible título de trabajo (o función) en una organización es el de

• El artefacto de ingeniería: la arquitectura. Si observa un automóvil, puede decir qué tipo

1.6 Arquitectura de software impulsada por el riesgo

La arquitectura de software es una tecnología relativamente nueva e incluye muchas técnicas

1.7. ARQUITECTURA PARA DESARROLLADORES ÁGILES 9

1.7 Arquitectura para desarrolladores ágiles

• Modelo conceptual. La principal contribución de Agile es el proceso de desarrollo de software, no las

1.8 Acerca de este libro

Parte I: Arquitectura de software impulsada por el riesgo

1.8. SOBRE ESTE LIBRO 11

Parte II: Modelado de arquitectura

Modelo impulsado por el riesgo