Chapters 3-4.pdf

43
de los elementos del método descritos en este libro también se da en el Apéndice C,
establecer algunos conceptos básicos presentes en un método. El Software y los Sistemas
Gestión de objetos de especificación de metamodelo de ingeniería de procesos (SPEM)
elementos de varios enfoques, incluidos Rational Unified Process, IBM Unified Method
Framework, OpenUP, eXtreme Programming (XP), Scrum, Feature Driven Development (FDD)
y Lean. También consideramos iniciativas de estandarización relevantes, como la especificación
del metamodelo de ingeniería de procesos de software y sistemas (SPEM).
tales conceptos, y los usamos en este libro. El estándar SPEM está influenciado
"Resumen del método".
El propósito de este capítulo es proporcionar una descripción general del método clave
(OMG) estándar (SPEM 2007) puede ayudar, porque proporciona definiciones de
Habiendo discutido algunos conceptos centrales, ahora dirigimos nuestra atención a algunos de
los detalles que sustentan el proceso de arquitectura, como los productos de trabajo,
elementos en los que se basa este libro. Por lo tanto, este capítulo prepara el escenario para
los capítulos restantes, en los que desarrollamos estos conceptos. Un resumen
Para que la discusión posterior en este capítulo tenga sentido, es importante para nosotros
tareas y roles. Para proporcionar este resumen, consideramos varias mejores prácticas
relacionadas con la arquitectura que se han desarrollado en la industria del software y nos basamos en
Fundamentos del método
Capítulo 3
Conceptos clave
Machine Translated by Google

Tarea
Iteración
Método Contenido
Fase
Proceso
Papel
Actividad
Producto de trabajo
Además, un método incluye orientación en forma de plantillas, ejemplos y
técnicas. Con referencia a la Figura 3.1, un proyecto de desarrollo de software
generalmente pasa por varias fases, cada una de las cuales se divide en varias
iteraciones (aunque, como verá, no todos los procesos están organizados por
En esencia, un método eficaz de desarrollo de software debe describir quién
hace qué, cómo y cuándo. Este libro hace exactamente eso en términos de los
siguientes conceptos clave:
El estándar SPEM define varios conceptos con una gran cantidad de detalles.
Sin embargo, para los propósitos de este libro, adoptamos un subconjunto simple e
hicimos algunos supuestos simplificadores. Los términos relevantes usados en este
libro se muestran en la Figura 3.1, que usa, cuando se definen, relaciones e íconos
del estándar SPEM.
por y es compatible con varios métodos de desarrollo de software existentes,
incluidos OpenUP (OpenUP 2008), Rational Unified Process (RUP 2008), IBM
Unified Method Framework, Fujitsu DMR Macroscope y Unisys QuadCycle.
Figura 3.1 Conceptos clave del método y sus relaciones
interpretado por
responsable de
44 | Capítulo 3 Fundamentos del método
dividido en
referencias
usa y produce
considera
ÿ Productos de trabajo: el qué
ÿ Fases, iteraciones y actividades: El cuándo
ÿ Tareas: el cómo
ÿ Roles: el quién

Proceso
Elaboración de inicio Transición
iteraciones
Etapas
Construcción
Además, como se muestra en la Figura 3.1, se puede considerar que un método
comprende el contenido y el proceso del método. El contenido del método describe los
elementos independientes del ciclo de vida, como roles, tareas y productos de trabajo. Luego,
un proceso toma estos elementos y define una secuencia en la que se aplican, según la
naturaleza del proyecto que se esté considerando, y considera conceptos como fases,
iteraciones y actividades. OpenUP proporciona un ejemplo de la separación del contenido del
método y el proceso, cuya visualización se proporciona en la Figura 3.2. En esta figura, el eje
vertical representa el contenido del método, agrupado por disciplina, y el acceso horizontal
describe el proceso.
fases e iteraciones). Dentro de cada iteración, consideramos varias actividades y las tareas a
las que hacen referencia, que se ejecutan para lograr un resultado particular.
Una disciplina es una colección de actividades que están relacionadas con un área
principal de interés dentro del proyecto general. Como se muestra en la Figura 3.2, OpenUP
está organizado en torno a cinco disciplinas, que se describen en la Tabla 3.1.
Las tareas son realizadas por roles apropiados, y los productos de trabajo relevantes son
usados y producidos.
Desarrollo
Requisitos
Arquitectura
Prueba
Gestión de proyectos
Tran
#n
Elab
#n
Tran
#1
constante
#n
Elab #
1
Incep #n Constante
#2
Comienzo
# 1
Constante
#1
Conceptos clave | 45
Figura 3.2 Contenido del método y dimensiones del proceso de OpenUP
[Una disciplina es un] mecanismo de categorización primario para organizar tareas
que definen un “área de interés” principal y/o cooperación de esfuerzo de trabajo.
(Abrir 2008)

Método Contenido
Esta disciplina explica cómo crear una arquitectura de software
a partir de requisitos arquitectónicamente significativos. La
arquitectura se construye en la disciplina Desarrollo.
Proyecto
Tabla 3.1 Resumen de disciplina de OpenUP
Prueba
Arquitectura
Esta disciplina explica cómo entrenar, facilitar y apoyar al equipo,
ayudándolo a lidiar con riesgos y obstáculos al construir software.
Esta disciplina explica cómo proporcionar retroalimentación sobre el sistema en
proceso de maduración mediante el diseño, la implementación, la ejecución y la
evaluación de pruebas.
Esta disciplina explica cómo obtener, analizar, especificar, validar y
gestionar los requisitos para el sistema a desarrollar.
Gestión
Esta disciplina explica cómo diseñar e implementar una solución
técnica que se ajuste a la arquitectura y soporte los requisitos.
Desarrollo
Requisitos
Descripción de la disciplina OpenUP
Papel
se dedica más tiempo a los requisitos y, en iteraciones posteriores, se dedica más tiempo
Tareas. El rol de Business Analyst , por ejemplo, es responsable de Func
tienden a variar mucho entre los diferentes tipos de ciclos de vida y proyectos. Un software
Un rol define las responsabilidades de un individuo o un conjunto de individuos que trabajan
juntos como un equipo dentro del contexto de una organización de desarrollo de software. Un
rol es responsable de uno o más productos de trabajo y realiza un conjunto de
Como demuestran las “jorobas” de la Figura 3.2, el énfasis relativo de las disciplinas cambia
a lo largo de la vida del proyecto. En las primeras iteraciones, por ejemplo,
los mismos pasos que un proyecto que está cambiando un sistema existente, pero el
ser altamente reutilizables porque, a diferencia de los elementos relacionados con el proceso, no
Las definiciones de roles, tareas y productos de trabajo por lo general se consideran
El énfasis en esta tarea será muy diferente a lo largo del ciclo de vida.
realizará una tarea como Identificar requisitos funcionales mediante el uso de
a los roles, productos de trabajo y tareas que comprenden el método que se está siguiendo.
sobre el desarrollo
Como mencionamos en la sección anterior de este capítulo, el contenido del método se refiere
proyecto de desarrollo que está desarrollando un sistema a partir de una hoja de papel en blanco

Datos
Arquitecto
Método Contenido | 47
Dirigir
Arquitecto
Infraestructura
Arquitecto Arquitecto
Solicitud
individuos a roles al planificar y dotar de personal al proyecto, aunque el
requisitos del sistema (cualidades y restricciones).
desempeñar múltiples roles (usar múltiples sombreros), y varios individuos pueden desempeñar
un solo rol. El Project Manager es responsable de realizar el mapeo de
automatizar los procesos comerciales y satisfacer las necesidades comerciales. Este rol se enfoca
principalmente en satisfacer la funcionalidad requerida por el negocio, pero también se preocupa
por cómo los elementos relacionados con la aplicación cumplen con los requisitos no funcionales.
Este rol define las propiedades apropiadas relacionadas con los datos, como estructura, fuente,
ubicación, integridad, disponibilidad, rendimiento y antigüedad.
El Arquitecto de Aplicaciones se enfoca en aquellos elementos de un sistema que
se comunican, validan y cumplen de manera eficaz.
Es importante enfatizar que los roles no son individuos. Los individuos pueden
sistema de archivos, un sistema de administración de contenido o algún otro mecanismo de almacenamiento.
Roles primarios y secundarios”.
Tarea de requisitos . En este libro, cuando un rol realiza una tarea, se considera que el rol es
primario o secundario, como se explica en la barra lateral “Concepto:
partes interesadas; gestionar riesgos y problemas técnicos; y garantizar que las decisiones
datos que se hacen persistentes en un mecanismo apropiado, como una base de datos, un
producto de trabajo de requisitos funcionales y realiza la identificación funcional
proporcionando la justificación de estas decisiones; equilibrar las preocupaciones de los diversos
El arquitecto de datos se centra en los elementos de datos de un sistema, especialmente
El arquitecto principal tiene la responsabilidad general de las principales decisiones
técnicas que definen la arquitectura del sistema. Este rol también es responsable de
elementos relacionados con la aplicación. Este papel se centra en los elementos que tienen una
relación significativa con las cualidades exhibidas por el sistema y, por lo tanto, la medida
a los que se dirigen determinados requisitos no funcionales.
requieren estos roles especializados, y un solo rol de arquitecto puede ser suficiente).
El Gerente de Proyecto, por supuesto, consulta a otros al hacer esto. Los roles relacionados con
el arquitecto utilizados en este libro se muestran en la Figura 3.3 (aunque no todos los proyectos
El Arquitecto de Infraestructura se concentra en aquellos elementos del sistema que son
independientes de la funcionalidad del negocio, como un mecanismo de persistencia, hardware y
middleware. Tales elementos apoyan la ejecución de la
Figura 3.3 Roles relacionados con la arquitectura de software

y/o utilizados durante la ejecución del proceso. Ejemplos de productos de trabajo
código fuente, ejecutable o plan de proyecto. Un entregable es también una obra tangible.
Un producto de trabajo es una pieza de información o entidad física que se produce
Salir. Un artefacto es un producto de trabajo tangible, como un documento, modelo,
El SPEM define tres tipos de productos de trabajo: artefacto, entregable y
productos, como se describe más adelante en este capítulo y en los capítulos relacionados con el
estudio de caso (Capítulos 6 a 9).
resumido en esta figura.
llevar a cabo. El arquitecto participa en diversas tareas que producen y utilizan la obra.
Documento entregable. Los productos de trabajo de los que el arquitecto es específi camente
responsable se muestran en la Figura 3.4, que también muestra los diferentes roles de los arquitectos.
Cualquier método dado puede agregar o eliminar algunos de los productos de trabajo
tareas y roles producen o modifican productos de trabajo como resultado de tareas que
El enfoque descrito en este libro se centra principalmente en los artefactos. Además de los
artefactos, el arquitecto es responsable de la arquitectura del software .
colaborar para producir un producto de trabajo. Los roles usan productos de trabajo como entrada para
representan un producto de trabajo que es de valor (material o de otro tipo) para una parte interesada.
Un resultado representa un resultado o estado como resultado de la ejecución de una tarea.
A diferencia de los artefactos y los entregables, los resultados no representan activos potencialmente
reutilizables.
producto del trabajo es responsabilidad de un solo rol, aunque múltiples roles pueden
incluyen modelos, planos, código, ejecutables, documentos, bases de datos, etc. A
producto que representa contenido empaquetado para su entrega. Los entregables se utilizan para
Producto de trabajo
Concepto: Roles Primarios y Secundarios
El rol principal de una tarea determinada se considera responsable de la tarea
y nunca es opcional. Se considera que un rol secundario contribuye a la tarea
pero no es responsable de ella y puede considerarse opcional.
La clasificación RACI ofrece una caracterización más completa de los
roles, en la que cada rol puede ser Responsable de la tarea, Responsable de
la tarea, Consultado (se busca la opinión del actor) e Informado (se mantiene
informado al actor sobre el progreso ). sobre la tarea y su contenido). Nuestra
caracterización simplificada considera un rol primario como el rol que es tanto
responsable como responsable y un rol secundario como el rol que es
consultado e informado.

Actividad
Figura 3.4 Productos de trabajo propiedad de roles relacionados con la arquitectura
Decisiones
Arquitecto
Datos
Arquitectura
Solicitud Datos
Arquitecto
Evaluación Arquitectura
Documento
Modelo
Arquitectura
Arquitecto
Software
Despliegue
Dirigir
Prueba de concepto
Arquitecto
Método Contenido | 49
Arquitectura
Modelo
Infraestructura
Visión de conjunto
Arquitectura
Funcional
Modelo
Una actividad representa una agrupación de tareas. El arquitecto realiza tareas dentro
de las actividades que se muestran en la Figura 3.5, que desarrollamos en el Capítulo
8, "Creación de la arquitectura lógica" y el Capítulo 9, "Creación de la arquitectura física".
Esta cifra puede dar dos impresiones engañosas. La primera es que todos los
productos de trabajo son documentos (¡porque el ícono de SPEM para un producto de
trabajo parece un documento!). Este no es el caso, sin embargo. El modelo funcional
y el modelo de implementación, por ejemplo, pueden representarse como modelos de
lenguaje de modelado unificado (UML) en una herramienta de modelado adecuada, y el
producto de trabajo de decisiones de arquitectura puede capturarse en un wiki de
proyecto. La segunda es que el nivel de ceremonia asociado con la creación de cada
producto de trabajo depende mucho del contexto (como la complejidad del sistema, el
punto del ciclo de vida y similares). El producto de trabajo Descripción general de la
arquitectura podría ser una página, por ejemplo, y el producto de trabajo Decisiones
de arquitectura puede comprender tres elementos en una hoja de cálculo.
Aunque no se muestra en la Figura 3.4, también hay productos de trabajo a los que
el arquitecto contribuye pero de los que no es propietario, como la Lista de requisitos
priorizados. Otro ejemplo es el producto de trabajo RAID Log , al que contribuye el
arquitecto pero que es propiedad del Project Manager. Como era de esperar, existe
una correlación entre el rol responsable de una tarea y la propiedad de los productos de
trabajo que se generan. El Business Analyst es responsable de la tarea Recopilar
solicitudes de partes interesadas y es el propietario del producto de trabajo Solicitudes
de partes interesadas , por ejemplo.

Las tareas pueden repetirse varias veces, especialmente cuando se adopta un
enfoque de desarrollo iterativo (las iteraciones se analizan más adelante en este capítulo).
Las tareas relacionadas con la arquitectura, que se describen en detalle en el Capítulo 8,
"Creación de la arquitectura lógica" y el Capítulo 9, "Creación de la arquitectura física", se
muestran en la Figura 3.6, junto con las funciones principales involucradas. Sin embargo,
debe recordar que este conjunto de tareas representa solo las tareas básicas de
arquitectura y que un arquitecto generalmente también está involucrado en otras tareas,
como el desarrollo de una estrategia tecnológica y el desarrollo de habilidades. Como verá,
el arquitecto también asiste en otras funciones, como la supervisión del proceso de
desarrollo, la identificación de las partes interesadas, la definición y priorización de
requisitos, la estimación y la planificación.
Una tarea es una unidad de trabajo que proporciona un resultado significativo en el
contexto del proyecto. Tiene un propósito claro, que generalmente implica crear o actualizar
productos de trabajo. Todas las tareas son realizadas por roles apropiados.
En esta sección, consideramos tres tipos de procesos, que se caracterizan por ser en
cascada, iterativos y ágiles. Mientras lo hacemos, no solo examinamos las características
clave de cada enfoque, sino que también destacamos aquellas prácticas que son de mayor
relevancia para el arquitecto de software y también exploramos algunos de los mitos que
parecen impregnar tales discusiones.
Ahora dirigimos nuestra atención a la aplicación del contenido del método en términos de
una secuencia en la que se aplican. Como verá, muchas de las diferencias entre los
diversos métodos utilizados en la industria del software se relacionan principalmente con
el proceso que se sigue más que con los roles, los productos del trabajo, las actividades y
las tareas realizadas.
Figura 3.5 Actividades relacionadas con la arquitectura
Proceso
Crear físico
Arquitectura Arquitectura
Crear lógico
Tarea

Procesos en cascada
Despliegue
Actualizar
Encuesta
Construir
Detalle
Validar
Funcional
Arquitectura
Elementos
Arquitectura
con Stakeholders
Visión de conjunto
Dirigir
Esquema
Documento
Definir Verificar
Solicitud
Arquitecto
Funcional
Arquitectura
Arquitectura Software
Elementos
Elementos
Decisiones
Arquitectura
Detalle
Despliegue
Documento
Arquitecto
Esquema
Arquitecto
Arquitectura
Arquitectura
Revisar
Infraestructura
Prueba de concepto Arquitectura
Activos
Elementos
Este enfoque es ampliamente utilizado, especialmente en aquellos proyectos que
representan mejoras menores de un sistema existente o en el desarrollo de un sistema.
En la Figura 3.7 se muestra un proceso tradicional de desarrollo en cascada, usando
nombres de disciplina tomados de OpenUP. En este enfoque, se considera que cada
disciplina está completa cuando se han creado y firmado todos los productos de trabajo
apropiados para esa disciplina. La disciplina de requisitos, por ejemplo, puede
considerarse completa cuando todos los requisitos han sido identificados, definidos en
detalle y revisados. Luego, el resultado de los requisitos fluye hacia la disciplina de la
arquitectura. Este proceso continúa hasta que el sistema ha sido diseñado y codificado
en detalle (en la disciplina de desarrollo), probado y puesto a disposición de sus
usuarios finales. Los cambios en los productos de trabajo (que se muestran con las
flechas que apuntan hacia atrás) generalmente se manejan a través de un proceso de cambio fo
Proceso | 51
Figura 3.6 Tareas relacionadas con la arquitectura

Figura 3.7 Un proceso en cascada
[Una iteración es una] división corta y de duración determinada de un proyecto. Las iteraciones permiten
que demuestre un valor incremental y obtenga una retroalimentación temprana y continua. (Abrir 2008)
Procesos Iterativos
Requisitos
Desarrollo
Arquitectura
Prueba
ÿ Los comentarios de los usuarios no se pueden obtener hasta una etapa avanzada del
proyecto, cuando el sistema está disponible para su uso, lo que retrasa la convergencia final
con los requisitos reales.
que implica una cantidad relativamente pequeña de riesgo. En proyectos greenfield (en los que
Completar los requisitos para una máquina del tiempo sin hacer ninguna arquitectura, desarrollo
o prueba, por ejemplo, no le dará una indicación precisa de cuánto tiempo llevará el proyecto,
porque realmente no puede determinar si existe una solución factible. !
discutimos en la siguiente sección.
ÿ El progreso del proyecto no se puede medir con precisión porque se basa en la creación de
productos de trabajo más que en el logro de resultados.
Un enfoque alternativo es utilizar un proceso de desarrollo iterativo, que
Cambiando mucho, este enfoque puede ser problemático por varias razones:
ÿ La resolución de ciertos riesgos se pospone hasta el final del proyecto, después de que el
sistema se haya construido, integrado y probado. Tales actividades a menudo identifican fallas
en el diseño e incluso en los requisitos establecidos, razón por la cual ciertas clases de proyectos
que siguen un enfoque en cascada son propensos a sufrir retrasos en el cronograma.
el arquitecto parte de una hoja de papel en blanco), sin embargo, o proyectos que son

Requisitos
Desarrollo
Arquitectura
Requisitos
Requisitos
Prueba
Arquitectura
Prueba
Desarrollo
Prueba
Arquitectura
Desarrollo
Dentro de una iteración, se pasa por cada una de las disciplinas, incluidos los
requisitos, la arquitectura, el desarrollo y la prueba. Una iteración es una secuencia
de actividades diferenciada y limitada en el tiempo que da como resultado una versión
(interna o externa) de un producto ejecutable. A medida que avanza el proyecto, las
versiones proporcionan mejoras incrementales en la capacidad hasta que se completa
el sistema final. Un proceso de desarrollo iterativo es similar al software en crecimiento,
en el que el producto final madura con el tiempo. Cada iteración da como resultado
una mejor comprensión de los requisitos, una arquitectura más robusta, una
organización de desarrollo más experimentada y una implementación más completa.
La noción de hacer crecer una arquitectura a través de una serie de iteraciones y
ejecutables parece ser una práctica común en organizaciones que consideraríamos
productivas y exitosas en la arquitectura de sus sistemas de software.
La figura 3.8 ilustra cómo cambia el enfoque de un proyecto a través de
iteraciones sucesivas. En esta figura, puede ver que cada disciplina se aborda durante
cada iteración, y el tamaño de los cuadros dentro de cada una de las disciplinas ilustra
el tiempo relativo dedicado a realizar las actividades (y tareas) dentro de esa disciplina.
En este ejemplo simple, verá que la iteración 1 se enfoca en la definición de requisitos,
pero se realiza algo de arquitectura (centrándose en la prioridad más alta).
Figura 3.8 Un proceso iterativo
Proceso | 53
Iteración 1 Iteración 3
Iteración 2

un proyecto que normalmente termina con un punto de control de decisión, hitos importantes o un
la base de cómo se estructurará el trabajo del proyecto. (Abrir 2008)
[Una fase es] un tipo especializado de actividad que representa un período significativo en
conjunto de entregables. Las fases suelen tener objetivos bien definidos y proporcionan
debe reducir con el tiempo, por supuesto. El punto es que tales cambios no son pensamientos
posteriores, sino que se consideran aspectos esenciales del ciclo de vida del proyecto.
Las fases proporcionan hitos comerciales bien definidos que aseguran que las iteraciones
progresen y converjan en una solución, en lugar de iterar indefinidamente. Las iteraciones están
enmarcadas en el tiempo (de una duración fija), mientras que las fases
tienen éxito en seguir un proceso iterativo:
deben hacerse a medida que avanza el proyecto. El número de cambios arquitectónicos.
A continuación se presentan algunas características importantes de las iteraciones en proyectos que
porque reconoce específicamente que los ajustes a la arquitectura
Un enfoque de desarrollo iterativo es particularmente atractivo para el arquitecto.
requisitos y arquitectura, razón por la cual ve un énfasis en el desarrollo y las pruebas.
La iteración 3 se enfoca en completar la solución basada en un conjunto relativamente estable de
requisitos a considerar en la iteración), junto con algunos desarrollos y pruebas. En este ejemplo,
la iteración 2 se enfoca en estabilizar la arquitectura, razón por la cual ve el énfasis en las
actividades de arquitectura.
metas y objetivos de cada iteración. Tal marco se proporciona por fases.
la iteración se evalúa en relación con los criterios objetivos de éxito para esa iteración en
particular.
realizado, que representa el plan estratégico para el proyecto e impulsa el
sin embargo. También debe tener un marco general en el que se realicen las iteraciones.
evaluado en base al estado del proyecto. Algunas organizaciones no reconocen este importante
principio, como se explica en el recuadro “Error: Declarar la victoria demasiado pronto”.
Un proceso de desarrollo iterativo implica más que un flujo de iteraciones,
se basan en objetivos. Una fase no está limitada en el tiempo, porque la finalización de una fase es
ÿ Durante la iteración, los productos de trabajo se actualizan (los productos de trabajo
evolucionan con el sistema).
ÿ La iteración tiene una capacidad planificada que es demostrable.
ÿ Durante la iteración, el sistema se integra y prueba.
ÿ La iteración tiene criterios de evaluación claros.
ÿ La iteración concluye con un hito menor, donde el resultado de la

OpenUP define cuatro fases secuenciales, que usamos en este libro: Incep
se ha cumplido Una evaluación satisfactoria permite que el proyecto pase a la siguiente
Las fases y las iteraciones juntas proporcionan la base para un proceso de
desarrollo iterativo. Los objetivos de cada fase se logran ejecutando una
ción, Elaboración, Construcción y Transición (ver Figura 3.9).
fase.
o más iteraciones dentro de la fase. Cada fase concluye con un hito importante y una
evaluación para determinar si los objetivos de la fase han
Trampa: Declarar la victoria demasiado pronto
Elaboración
Hito
Hito
Construcción
Comienzo
Hito
Hora
Transición
Lanzamientos
Hito
#metro
Iteración Iteración
#1 #n+2
Iteración
Iteraciones
Iteración
Preliminar
#n+1
Iteración
#norte
Iteración
#m+1
#2
Iteración
Figura 3.9 Fases del proyecto
Proceso | 55
quienes cocinan los libros de esta manera a menudo se despegan cuando sus decisiones
equivocadas vuelven para atormentarlos.
la noticia de que la fase no se completó según lo planeado, en lugar de engañarse a
sí mismos y a todos los demás, de que todo va por buen camino, una situación que
normalmente resulta en una presión adicional e innecesaria sobre el proyecto.
Un error muy común es que el Project Manager declare la victoria afirmando que una fase
ha sido completada cuando en realidad no lo ha sido, simplemente porque se ha llegado a
la fecha en la que la fase debería haber sido completada. Este escenario es el equivalente
en software de la contabilidad falsa, y los gerentes de proyecto
Por lo general, es mucho mejor para un gerente de proyecto morder la bala y transmitir

Elevado
Bajo
es un enfoque particular para el arquitecto.
elaboración o que los requisitos nunca cambian, pero la mayoría de los requisitos
la arquitectura. En este libro, esta fase es la fase de Elaboración, que claramente
Esto no quiere decir que todos los requisitos hayan sido definidos al final de
se estabiliza con el tiempo, como se indica en la Figura 3.10. Da la casualidad de que la mayoría de
los procesos de desarrollo de software basados en fases tienen una fase que se enfoca en estabilizar
y las decisiones de financiación se pueden tomar con mayor confianza.
Por lo tanto, existe un nivel mucho más alto de fidelidad en las estimaciones de costos y cronogramas,
y las estimaciones de costos y cronogramas se vuelven más precisas. La arquitectura también
el proyecto avanza. Los riesgos se reducen durante el ciclo de vida del proyecto, por ejemplo,
suele haber una buena comprensión tanto del problema como de la solución.
Un enfoque basado en fases admite la convergencia de varios elementos como
representa un hito importante en lo que al negocio se refiere. La etapa de producción generalmente
es más predecible que la etapa de ingeniería, porque
proyecto y posiblemente revisando la fase de elaboración (e incluso de inicio).
(es decir, de la ingeniería a la producción) es particularmente interesante porque este movimiento
se agrega un requisito, por ejemplo), existe un caso para revisar el proyecto y
su cronograma y ajustándose en consecuencia. Esto puede requerir esencialmente restablecer el
Marco unificado (Royce 1998). Pasando de la Elaboración a la Construcción
La Figura 3.10 también caracteriza las fases de Inicio y Elaboración como ingeniería, mientras
que las fases de Construcción y Transición se tratan como producción. Esta distinción se analiza en
detalle en Software Project Management: A
se espera que se hayan definido, y se espera que cualquier cambio tenga un impacto mínimo en la
arquitectura. Si este no fuera el caso (cuando una cantidad significativa
Figura 3.10 Estabilidad de la arquitectura en el tiempo
Etapa de Ingeniería
Transición
Estabilidad
Construcción
Arquitectura
Etapa de producción
Comienzo
Hora
Elaboración

enfocado en
Arquitectura
% Recursos
Gestión de proyectos de software: un marco unificado (Royce 1998).
de las fases:
Claramente, pasar de una fase a otra es un momento significativo en la
ÿ La fase de Construcción es donde se aclaran los requisitos restantes y donde se
completa el desarrollo del sistema en la arquitectura de referencia establecida
durante la fase de Elaboración. Entre las fases de Elaboración y Construcción, el
enfoque cambia de comprender el problema e identificar los elementos clave de la
solución para desarrollar un producto desplegable.
Como se indica en la Figura 3.11, existe una relación directa entre el énfasis en la
arquitectura en cada una de las fases y la cantidad de recursos típicamente
ÿ La fase de inicio es donde se establece el caso de negocio para el proyecto
ciclo de vida del proyecto, por lo que es importante entender los criterios bajo los cuales se
dedicado a la arquitectura (que, por supuesto, variará dependiendo de la naturaleza
y donde se establece la concurrencia entre todos los interesados en los objetivos del
proyecto. El inicio es donde el enfoque está en asegurar que el proyecto sea valioso
y factible.
se hace la transición de una fase a la siguiente. Se presenta un resumen detallado de los
objetivos principales de cada una de las fases y sus criterios de evaluación de hitos.
del sistema en desarrollo). Este gráfico se deriva de la información en
ÿ La fase de Elaboración es donde se establece la arquitectura para proporcionar una
base estable para las actividades realizadas durante la fase de Construcción. Esta
fase, por lo tanto, es de particular relevancia para el arquitecto y ciertamente es
donde el arquitecto gasta el mayor esfuerzo.
proporcionado en el Apéndice C, “Resumen del método”. A continuación se muestra una descripción general de cada
75
0
25
100
50
Figura 3.11 Porcentaje de recursos enfocados en la arquitectura a lo largo del tiempo
Proceso | 57
Construcción
Elaboración Transición
Hora
Comienzo

Desarrollo iterativo y desarrollo en cascada
Procesos ágiles
ÿ Individuos e interacciones sobre procesos y herramientas
ÿ Software de trabajo sobre documentación completa
abordado temprano para aumentar la previsibilidad y evitar costos posteriores
Establezca un proceso de ciclo de vida iterativo que enfrente el riesgo temprano. con el de hoy
sofisticados sistemas de software, no es posible definir todo el problema,
secuencia. En cambio, un proceso iterativo que refina la comprensión del problema, una
solución efectiva y un plan efectivo a lo largo de varias iteraciones fomenta un tratamiento
equilibrado de todos los objetivos de las partes interesadas. Los principales riesgos deben ser
chatarra y reelaboración. (Royce 1998)
diseñar la solución completa, crear el software y luego probar el producto final en
medidas más precisas del progreso del proyecto. Un enfoque iterativo permite
iteración dada) en lugar de impulsada por el producto del trabajo y se presta a proporcionar
Manifiesto 2009) que establece los siguientes valores:
principios Una articulación de tales principios es el Manifiesto Ágil (Agile
En comparación con un proceso de desarrollo en cascada, un proceso de desarrollo iterativo se
basa en los resultados (en el sentido de que se centra en los resultados que se lograrán dentro de un
método y las prácticas que defienden, todos se basan en el mismo fundamento
antes de que se realice una inversión sustancial en el proyecto. Como dice Royce:
tales como eXtreme Programming (XP), Scrum, Lean y Feature-Driven Development. Aunque
existen algunas diferencias con respecto a cada metodología ágil específica
aceptado por sus usuarios finales. Esta fase es donde el sistema se implementa en el
entorno de los usuarios para su evaluación y prueba. La atención se centra en el ajuste
fino del producto y en abordar los problemas de configuración, instalación y uso. Al final de
la fase de transición, el proyecto debería estar en condiciones de cerrarse.
ÿ La fase de Transición garantiza que el software esté disponible y
temprano en el proyecto, apoyando así al negocio en la toma de decisiones
El interés por los procesos ágiles ha aumentado en los últimos años, expresado en métodos
y que se produzca una versión ejecutable. Los riesgos son atacados de frente y
dicha retroalimentación acelera la convergencia en los requisitos reales. Además, un enfoque
iterativo asegura que la integración y las pruebas ocurran dentro de cada iteración.
comentarios de los usuarios a través de la ejecución de versiones incrementales del sistema, y

Scrum es un proceso de gestión y control que reduce la complejidad para centrarse
en crear software que satisfaga las necesidades comerciales. Scrum se superpone
y envuelve las prácticas de ingeniería, las metodologías de desarrollo y los
estándares existentes. (Schwaber 2002)
Parece haber un temor en la comunidad ágil de que si usamos términos como
"modelo" o "documento", de repente los "burócratas malvados" clavarán sus garras
en nuestros proyectos y nos obligarán a escribir especificaciones de requisitos
grandes y detalladas o adoptar un enfoque de gran diseño por adelantado. . . lo
extraño es que los agilistas, de hecho, están modelando regularmente, aunque no
estén hablando directamente de eso. (Ambler 2008)
ÿ Colaboración con el cliente sobre la negociación del
contrato ÿ Responder al cambio sobre seguir un plan
Resumen
Resumen | 59
Los principios ágiles también son relevantes para los arquitectos, y es sorprendente la
frecuencia con la que se tergiversan los principios. Una percepción común es que los procesos
ágiles no abogan por un diseño inicial y que, de alguna manera, la arquitectura simplemente
emerge del código. Sin embargo, el principio de que el software funciona sobre la documentación
completa no significa que no exista documentación (incluida la documentación relacionada con
la arquitectura); simplemente significa que existe suficiente documentación para los propósitos
de la iteración actual.
Este capítulo proporcionó una breve descripción general de los fundamentos del método
utilizados en este libro, utilizando el estándar SPEM (Software and Systems Process Engineering
Metamodel Specification) como marco para explicar estos conceptos. los
Scrum también ejemplifica el énfasis en el proceso. Se centra en el contenido de una
iteración (refiriéndose a una iteración como un Sprint), los requisitos priorizados que se
considerarán en la iteración (el Sprint Backlog) y una breve reunión diaria de estado (un Scrum).
La opinión de los autores es que estos principios son complementarios a los que se
encuentran en un enfoque de desarrollo iterativo. Además, como puede ver en el Manifiesto Ágil,
la distinción principal es el énfasis puesto en los principios que guían la ejecución del proceso,
en lugar del contenido del método nuevo o diferente. Un ejemplo proviene de Scrum:

Los siguientes dos capítulos, el Capítulo 4, “Documentación de una arquitectura de
software”, y el Capítulo 5, “Activos de arquitectura reutilizables”, se enfocan en aspectos
específicos del método que justifican una discusión más detallada y que impregnan el
ciclo de vida del proyecto.
El capítulo enfatizó la distinción entre el contenido del método y los procesos que
promulgan este contenido, y consideró diferentes tipos de procesos, incluidos los de
cascada, iterativos y ágiles. El capítulo discutió la relevancia de estos conceptos para el
arquitecto y para el proceso de arquitectura. El método utilizado en este libro toma
prestado de todos estos tipos de procesos.

61
respectivamente. Esta comunicación es crítica para asegurar que ciertas partes interesadas se
sientan cómodas con la solución propuesta, por ejemplo, y que el
dedicamos este capítulo a explorar varios aspectos de la descripción de un software
arquitectura. Documentar una arquitectura de software es beneficioso por las siguientes razones:
El equipo del proyecto tiene una visión coherente del sistema que se va a construir. acomodar a todos
Sin embargo, las preocupaciones de todas las partes interesadas suelen ser un desafío. Por lo tanto,
arquitectura a comunicar. Esta comunicación es fundamental para garantizar
El propósito principal de documentar una arquitectura de software es permitir que la
entre las diferentes partes interesadas, como la comunicación entre quienes desarrollan el
sistema y quienes lo mantienen, incluso si las personas involucradas nunca se encuentran
físicamente.
que todas las partes interesadas entiendan la arquitectura y puedan proporcionar su opinión
productos, como productos de trabajo de diseño detallado o incluso materiales de formación.
Capítulo 4
Documentación de una arquitectura de software
ÿ Una arquitectura documentada contribuye a una comunicación eficaz
ÿ Una arquitectura documentada proporciona el contexto para derivar otros trabajos
ÿ Una arquitectura documentada puede ayudar con la planificación de la transición de una
arquitectura existente a una nueva arquitectura.
ÿ Una arquitectura documentada puede transmitir soluciones arquitectónicas alternativas y los
pros y los contras de cada una.

El juego final
ÿ Una arquitectura documentada puede ayudar con la evaluación de la arquitectura y puede, por
ejemplo, ayudar a determinar si la implementación está de acuerdo con la especificación
proporcionada.
ÿ Una arquitectura documentada puede ayudar con la planificación en general al identificar los
elementos que componen la arquitectura y las dependencias entre ellos. Esta información puede
ayudar a planificar una secuencia adecuada para implementar la arquitectura y también
comprender el impacto de realizar un cambio en la arquitectura.
ÿ Una arquitectura documentada puede ayudar a identificar oportunidades de reutilización en
términos de creación y uso de activos reutilizables.
ÿ Una arquitectura documentada puede recordarle al arquitecto la lógica
Dirigir
Desarrolladores
Modelo de implementación
Usuarios
modelo funcional
Arquitecto
Documento de arquitectura de software
Figura 4.1 Elementos involucrados en la documentación de una arquitectura de software
62 | Capítulo 4 Documentación de una arquitectura de software
documentar arquitecturas. Comenzamos este capítulo discutiendo estos conceptos.
Luego discutimos varios marcos de descripción de arquitectura (ADF) y cerramos
Algunos conceptos simples que se pueden aplicar al documentar un software
describiendo el marco de descripción de arquitectura utilizado en este libro.
arquitectura son particularmente útiles para los arquitectos que tienen poca experiencia en
detrás de ciertas decisiones que se han tomado.
en la figura 4.1.
Antes de saltar a los elementos que componen una arquitectura de software documentada,
presentamos un ejemplo muy simple de lo que buscamos, como se muestra

El juego final | 63
Modelo para describir el despliegue del sistema en términos de, por ejemplo, nodos y
las conexiones entre ellos. Para simplificar, otros puntos de vista y sus productos de
trabajo correspondientes, como las decisiones de arquitectura y los productos de trabajo
de prueba de concepto de arquitectura , no se muestran en la figura.
ÿ Crear los productos de trabajo. El arquitecto (o equipo de arquitectura) popu
Al documentar una arquitectura de software, debe seguir algunos pasos simples:
ÿ Seleccionar los puntos de vista. Después de identificar los grupos de partes interesadas,
clasifica los productos de trabajo en consecuencia. Puede agregar elementos a cualquier
modelo que haya decidido crear, así como cualquier diagrama que le permita expresar
estos elementos visualmente. En la Figura 4.1, mostramos dos diagramas en el Modelo
funcional y uno en el Modelo de implementación. En términos generales, todo producto
de trabajo puede considerarse como un modelo del sistema en desarrollo; discutimos este
tema en la siguiente sección.
ÿ Identificar los grupos de partes interesadas. Al documentar una arquitectura de
software, lo primero que hay que entender es el público objetivo. Uno de los primeros
elementos que considerará el arquitecto principal es el público objetivo en términos de
partes interesadas de la arquitectura. Las partes interesadas se pueden organizar en
grupos que comparten preocupaciones relacionadas. Los dos grupos de partes interesadas
que se muestran en la figura son Desarrolladores y Usuarios.
necesidad de identificar los puntos de vista correspondientes que permitan expresar las
preocupaciones de las partes interesadas. Los puntos de vista son fundamentales para
documentar una arquitectura de software y se analizan en detalle en "Puntos de vista y
vistas" más adelante en este capítulo. Un punto de vista, por ejemplo, define los productos
de trabajo necesarios para que la arquitectura pueda comunicarse a las partes interesadas
identificadas de manera adecuada. En el ejemplo de la figura 4.1, la selección de un punto
de vista funcional requiere que el arquitecto cree un modelo funcional para describir la
funcionalidad (lógica) del sistema en términos de, por ejemplo, componentes, relaciones
entre componentes y sus interacciones. La selección de un punto de vista de implementación
requiere que el arquitecto cree una implementación
ÿ Empaquetar la descripción de la arquitectura. En lugar de comunicar la arquitectura
utilizando todos los productos de trabajo que se han creado, el arquitecto normalmente
empaqueta los elementos en una forma que los interesados pueden consumir más
fácilmente. (Es posible que no todas las partes interesadas tengan acceso a las herramientas
de modelado utilizadas para crear ciertos productos de trabajo, por ejemplo). En nuestro
ejemplo de la Figura 4.1, el arquitecto crea un Documento de arquitectura de software

Dado que las partes interesadas de la arquitectura pueden ser miembros del
equipo o mantenedores, también debe prestar la atención adecuada al mantenimiento
de cualquier producto de trabajo que cree y asegurarse, cuando corresponda, de que
se mantengan actualizados y coherentes entre sí.
Uno de los principios ágiles es "Software de trabajo sobre documentación
completa" (Manifiesto Ágil), y este principio le recuerda que la creación de cualquier
producto de trabajo debe ser mínima pero suficiente. Al documentar una arquitectura
de software, determina lo que quiere decir con suficiente al considerar las necesidades
de las partes interesadas identificadas.
Los conceptos de punto de vista, vista y modelo se discuten en detalle en el
subconjunto de los elementos definidos en esta norma. Esta figura amplía la discusión en el
Capítulo 2, “Arquitectura, Arquitecto, Arquitectura”, específicamente
Siguiente sección.
identificando aquellos elementos que están relacionados con una descripción arquitectónica.
Los conceptos clave de la descripción de la arquitectura son el punto de vista , la vista y el modelo.
Todas las relaciones que se muestran en esta figura provienen del estándar IEEE 1471.
Aquellas relaciones no descritas en el Capítulo 2 se proporcionan en la siguiente lista; ampliaremos
estas relaciones más adelante en este capítulo.
Estos conceptos se definen en IEEE 1471-2000, Práctica recomendada de IEEE
entregable. Este entregable está organizado por las diferentes vistas de la arquitectura,
y cada vista representa la aplicación de un punto de vista particular para un sistema dado.
El alcance de la documentación de arquitectura requerida se analiza en la barra lateral
"Mejores prácticas: la documentación es mínima pero suficiente".
para la Descripción Arquitectónica de Sistemas Intensivos de Software. La Figura 4.2 muestra un
Conceptos clave
ÿ Una descripción arquitectónica está organizada por una o más vistas.
ÿ Una vista consta de uno o más modelos.
ÿ Un modelo participa en una o más descripciones arquitectónicas.
ÿ Un modelo participa en una o más vistas.
Mejores prácticas: la documentación es mínima pero suficiente

Figura 4.2 Un metamodelo de elementos relacionados con una descripción arquitectónica
Vista
Punto de vista
Modelo
Arquitectura
Descripción arquitectónica
Interesado
Preocupación
Razón fundamental
ÿ Una vista se ajusta a un punto de
vista. ÿ Una descripción arquitectónica selecciona uno o más puntos de
vista. ÿ Un punto de vista establece métodos para uno o más modelos.
ÿ Se utiliza un punto de vista para cubrir una o más inquietudes.
Como puede ver, los conceptos de punto de vista, vista y modelo son fundamentales
para describir una arquitectura de software, y todos ellos se describen con más detalle en
las siguientes secciones.
Si bien este enfoque puede ser un medio eficaz para comunicar de manera informal
algunos aspectos de la arquitectura a las partes interesadas, adoptar un enfoque tan
estrecho (una descripción técnica informal destinada a cubrir todas las facetas de la
arquitectura) generalmente genera confusión, porque tales diagramas tienden a generar
confusión. ser demasiado complejo. Dichos diagramas también tienden a mezclar diferentes aspecto
Sería bueno pensar que podría comunicar la arquitectura de un sistema mediante el uso
de un solo diagrama que satisfaga las necesidades de todas las partes interesadas.
Miradores y Vistas
Miradores y Vistas | sesenta y cinco
- tiene
1..*
1..*
- descrito por 1
- es importante para
1..*
- agregados
- identifica
1..*
1..*
*
- proporciona
- direcciones
- consta de 1..*
- De acuerdo a
- identifica
- establece métodos para 1..*
- selecciona
1..*
1..*
1..*
- organizado por
1..*
- usado para cubrir
1..*
- participa en - participa en

responsabilidades funcionales con preocupaciones de implementación, y una flecha entre
La solución a tales fallas es describir una arquitectura de software aplicando varios puntos de
vista al mismo tiempo, con cada punto de vista abordando un conjunto particular de preocupaciones.
ÿ Un punto de vista tiene una audiencia identificada. Una preocupación principal de un punto
de vista es que aborda las necesidades de una audiencia particular, donde la audiencia
representa a uno o más interesados en el sistema. Un punto de vista funcional puede abordar
las necesidades de un desarrollador (que debe realizar actividades de diseño detalladas e
implementar código), un probador (que debe probar el sistema), etc.
arquitectura. Un cuadro de aspecto inocente en un diagrama de este tipo, por ejemplo, puede mezclar
Un mirador tiene varias características que vale la pena señalar:
arquitectura en componentes, sus relaciones e interacciones en detrimento de las preocupaciones
sobre el despliegue del sistema, por ejemplo.
vista se ajusta a un punto de vista. El punto de vista define las reglas mediante las cuales se
crea y utiliza la vista. En la terminología orientada a objetos, un punto de vista representa una
clase (de vista), y una vista es una instancia particular de un punto de vista. Por lo tanto, al
documentar la arquitectura de un sistema en particular
Otro defecto común es enfatizar un aspecto de la arquitectura en detrimento de los demás. El
diagrama puede enfatizar la partición funcional del
ÿ Un punto de vista es un patrón o plantilla para una vista. En términos simples, un
ÿ Un punto de vista sirve para uno o más propósitos. Aunque un punto de vista respalda a un
conjunto de partes interesadas que tienen preocupaciones similares, es posible que esas
preocupaciones no sean idénticas. Un desarrollador puede usar un punto de vista funcional para
comprender el contexto para diseñar las partes internas de un elemento de diseño específico
antes de implementar ese elemento en un lenguaje de programación dado, mientras que un
probador puede usar el mismo punto de vista funcional para comprender los componentes clave
del sistema para los propósitos. de determinar si el sistema cumple con ciertos requisitos.
Las cajas pueden mezclar el flujo de control con una dependencia simple entre elementos.
[Una vista arquitectónica es] una representación de un sistema completo desde la perspectiva
de un conjunto relacionado de preocupaciones. (IEEE 1471 2000)
técnicas para su creación y análisis. (IEEE 1471 2000)
[Un punto de vista arquitectónico es] una especificación de las convenciones para construir y
usar una vista. Un patrón o plantilla a partir del cual desarrollar puntos de vista individuales al
establecer los propósitos y la audiencia de un punto de vista y el

desde los cuales se pueden seleccionar puntos de vista para cualquier proyecto dado.
La justificación para considerar los puntos de vista se puede ampliar aún más, como se muestra
selecciona el conjunto apropiado de puntos de vista y, como resultado, crea las vistas que son
específicas para la arquitectura del sistema en desarrollo. Debido a que un punto de vista
puede considerarse como una plantilla, no sorprende que algunas organizaciones inviertan en
la creación de un catálogo de puntos de vista.
las conexiones entre ellos).
Como consecuencia, puede ver que un punto de vista influye en la forma en que se crean los
productos de trabajo que componen la vista.
y su comportamiento), y un punto de vista de implementación, que se ocupa de los elementos que
soportan la distribución del sistema (como nodos, dispositivos y
se creará con el Lenguaje Unificado de Modelado (UML); que el Modelo de Despliegue
se creará aplicando ciertas técnicas y convenciones; y que el Modelo de Despliegue debe
ser aplicado en determinadas situaciones (con los correspondientes beneficios acumulados y
escollos a evitar).
práctica: un punto de vista funcional, que se ocupa de los elementos que apoyan la funcionalidad
del sistema (como los componentes, sus relaciones,
en la Figura 4.3, en la que los puntos de vista parecen estar en los márgenes de una arquitectura
ÿ Un punto de vista define las técnicas. Finalmente, un punto de vista define las convenciones
mediante las cuales se crea, representa y analiza una vista. Un punto de vista define el
lenguaje en el que se define una vista que se ajusta al punto de vista, tal vez incluyendo
notaciones y técnicas específicas para derivar el contenido de la vista. Un punto de vista de
implementación puede indicar que una vista de implementación contiene un modelo de
implementación; que el modelo de implementación
Ya hemos mencionado dos puntos de vista que los arquitectos suelen encontrar en
Figura 4.3 Puntos de vista básicos
Punto de vista
Grupo de partes interesadas C
Funcional
Punto de vista
Grupo B de partes interesadas
Validación
Punto de vista
Miradores y Vistas | 67
Grupo de partes interesadas A
Requisitos
Punto de vista
Despliegue
Grupo de partes interesadas D
Puntos de vista básicos

propiedades que requieren consideración a través de una serie de vistas arquitectónicas del
sistema. (Rozanski 2005)
Una perspectiva arquitectónica es una colección de actividades, tácticas y pautas.
que se utilizan para garantizar que un sistema exhiba un conjunto particular de calidad relacionada
sistema, por ejemplo, es posible que deba especificar requisitos de seguridad, introducir elementos
funcionales relacionados con la seguridad y elementos de implementación en el
exhibir las cualidades requeridas y adaptarse a las restricciones definidas.
cualidades que debe exhibir el sistema. Para abordar los requisitos de seguridad en un
una indicación de si el sistema proporcionará la funcionalidad requerida,
Una perspectiva es realmente un tipo especial de punto de vista que se enfoca en el
cualidades y limitaciones. El propósito del punto de vista de validación es proporcionar
del punto de vista de los requisitos es proporcionar una indicación de los requisitos del sistema
que han dado forma a la arquitectura; incluye requisitos funcionales,
estos puntos de vista:
descripción: un punto de vista de requisitos y un punto de vista de validación. El propósito
puede considerar las siguientes intersecciones entre los puntos de vista implicados por
los mismos elementos. Más específicamente, dados los ejemplos que se muestran en la Figura 4.4,
Woods otorga un significado especial al término perspectiva para representar la colección de
elementos que abordan una preocupación transversal:
creados mediante la aplicación de estos puntos de vista se considera transversal a los requisitos,
vistas funcionales, de implementación y de validación en el sentido de que pueden compartir
Uso de puntos de vista y perspectivas (Rozanski 2005), Nick Rozanski y Eoin
solución, y posteriormente validar la seguridad implementada en la arquitectura. Esta situación se
muestra en la figura 4.4, en la que introducimos tanto el punto de vista del rendimiento como el
punto de vista de la seguridad. Las vistas correspondientes
En su libro Software Systems Architecture: Working with Stakeholders
ÿ La vista de rendimiento identifica los elementos en la vista funcional que
contribuyen a cumplir con los requisitos de rendimiento, lo que puede resultar en
la necesidad de acoplar elementos estrechamente cuando ocurre mucha
comunicación, por ejemplo.
ÿ La vista de rendimiento identifica los elementos de la vista de implementación
que contribuyen a cumplir los requisitos de rendimiento. Esta vista
ÿ La vista de rendimiento identifica los requisitos relacionados con el rendimiento
en la vista de requisitos y cómo se cumplen esos requisitos.
Puntos de vista transversales

Punto de vista
Punto de vista
Seguridad
Rendimiento
Interesado
Punto de vista
Despliegue
Grupo C
Punto de vista
Interesado
Requisitos
Grupo A
Punto de vista
Interesado
Funcional
Grupo E
Validación
Punto de vista
Interesado
Interesado
Grupo B Grupo D
Grupo F
Interesado
Figura 4.4 Puntos de vista básicos y puntos de vista transversales
Considere la ubicación de los elementos de comunicación, la especificación del
hardware que soporta el sistema y la distribución del sistema como un todo
(teniendo en cuenta elementos como la latencia de la red, por ejemplo).
vista de requisitos y cómo se realizan esos requisitos. Los requisitos de
seguridad pueden ser de naturaleza funcional, como la forma en que los usuarios
se autentican en el sistema, o pueden ser restricciones que se imponen al sistema,
como qué nivel de cifrado se debe usar para cifrar los datos en el sistema.
tributo al cumplimiento de los requisitos de seguridad, como los componentes que
manejan la autenticación, la autorización, la auditoría y el no repudio. Esta vista
también puede mostrar qué componentes y elementos de datos deben protegerse.
ÿ La vista de rendimiento identifica los elementos en la vista de validación que respaldan
la validación de los requisitos de rendimiento. Este punto de vista consideraría qué tan
bien la arquitectura cumple con las características de rendimiento requeridas, la
justificación de cualquier compensación realizada y los riesgos y problemas pendientes.
ÿ La vista de seguridad identifica los requisitos relacionados con la seguridad en el
ÿ La vista de seguridad identifica los elementos en la vista funcional que
requisitos
Especificación de hardware
Ubicación del componente
Rendimiento Acoplamiento de componentes
elementos
requisitos
elementos
Validación de seguridad
Seguridad
Validación de rendimiento
Autorización de usuario
cortafuegos
Autenticacion de usuario
Políticas de seguridad
Topología de distribución

Vistas y Diagramas
ÿ La vista de seguridad identifica los elementos de la vista de implementación que
contribuyen a cumplir los requisitos de seguridad. La vista puede identificar la necesidad
de hardware o software especializado (como firewalls).
ÿ La vista de seguridad identifica los elementos en la vista de validación que respaldan
punto de vista que se centra en los elementos que sustentan el sistema en desarrollo, pero que son
independientes del dominio empresarial (como un registro de errores o
Un concepto erróneo común entre los arquitectos es la suposición de que una vista es un
1960 Si cada diagrama fuera una vista, el resultado no sería solo una explosión
una consideración de cualidades. Puede decidir introducir una infraestructura
más de 75.000 dibujos de ingeniería cuando se diseñó el primer 747 en el
puede transportar cientos de pasajeros miles de millas sin parar. Boeing producido
La consideración de los puntos de vista transversales puede extenderse más allá de
aspectos de nuestra arquitectura y puede asegurar que se pone el énfasis apropiado
en las características arquitectónicas clave a lo largo del ciclo de vida del proyecto.
más de 160 millas, tiene una cabina que contiene cientos de elementos de control y
puerto la validación de los requisitos de seguridad. Esta vista consideraría qué tan bien la
arquitectura cumple con las características de seguridad requeridas, la justificación de cualquier
compensación realizada y los riesgos y problemas pendientes.
En la práctica, los autores han descubierto que centrarse tanto en puntos de vista básicos como
transversales nos proporciona un modelo mental simple para considerar ciertos
partes que pesan cientos de miles de libras, contiene cableado que corre
qué tan bien el mecanismo de registro de errores aborda los requisitos establecidos).
Considere un jumbo jet Boeing 747, que consta de más de 6 millones
considerada como una vista, dadas nuestras definiciones. En esencia, una vista es una ventana.
en toda la arquitectura desde un punto de vista particular.
(como un mecanismo de registro de errores), elementos de implementación relacionados con la
infraestructura (como nodos de hardware utilizados para alojar el mecanismo de registro de errores) y
elementos de validación relacionados con la infraestructura (como una evaluación de
en los círculos de TI. Aunque una vista puede estar completamente representada por un solo diagrama,
más a menudo una vista se representa en muchos diagramas.
conjunto de preocupaciones y deben ser considerados como un grupo. Cada grupo de diagramas es
vistas basicas. Puede tener requisitos relacionados con la infraestructura (como una restricción para
usar una base de datos relacional en particular), requisitos funcionales relacionados con la infraestructura
mecanismo de persistencia). Nuevamente, la vista correspondiente atravesaría el
diagrama o que un diagrama es una vista, en gran parte debido a la similitud de estos términos
de vistas (porque estarían involucrados muchos diagramas), pero también un número inmanejable de
diagramas. Por lo tanto, diferentes diagramas a menudo apuntan a la misma

Vista de implementación
grupo de partes interesadas B, está preocupado por la topología de implementación en términos de
y vistas:
La relación entre vistas y diagramas se indica en la Figura 4.5,
puede lograr algunos beneficios específicos adoptando un enfoque basado en puntos de vista
de dos diagramas. La vista de implementación, que es relevante para las preocupaciones de
tienen varios puntos de vista relacionados pero diferentes. Un avión tiene una estructura
externa que se manifiesta en sus alas, fuselaje y tren de aterrizaje; circuitos eléctricos;
sistemas hidráulicos; y así. De manera similar, un sistema de software tiene
Además de los beneficios generales de documentar una arquitectura de software, usted
grupo A, se ocupa de los componentes y sus interacciones, y consiste
ÿ Gestionar la complejidad del sistema. Una vista representa una simplificación de la realidad.
Esta simplificación se logra centrándose en un aspecto particular del sistema bajo
consideración. Una vista física de un avión puede centrarse en sus propiedades
aerodinámicas, mientras que una vista del despliegue de un sistema de software se centra
en el entorno operativo en el que se ejecutará el sistema.
ÿ Para centrarse en un aspecto específico del sistema. Los sistemas más complejos
nodos y conexiones entre nodos, y consta de un solo diagrama.
ejemplo, la vista funcional, que es relevante para las preocupaciones de las partes interesadas
que muestra dos vistas: una vista funcional y una vista de implementación. En esto
Vista funcional
Figura 4.5 Un ejemplo de vistas y diagramas
Diagrama
Diagrama
Diagrama
Beneficios de los puntos de vista y las vistas

presente dentro de una vista. Un buen ejemplo de un modelo es una maqueta de un avión.
Los modelos descritos en este libro incluyen un Modelo Funcional, un
que participa en una vista. Los modelos contienen los elementos específicos que son
también vea que la vista de implementación presenta elementos en el modelo funcional
la vista de implementación presenta elementos en el modelo de implementación, puede
Modelo es el término utilizado en el estándar IEEE 1471 para representar un producto de trabajo
aunque la vista funcional presenta elementos en el Modelo Funcional y
ÿ Para comunicarse con las partes interesadas. Para comunicar un sistema a sus
diversas partes interesadas de manera efectiva, a menudo tiene que representar
diferentes aspectos del mismo sistema en diferentes vistas para abordar las necesidades
de cada parte interesada. Se puede usar una vista que considere la estructura externa de
un avión para comunicarse con un ingeniero aerodinámico. De manera similar, se puede
usar una vista del despliegue de un sistema de software para comunicarse con diseñadores
y administradores de sistemas.
consideración.
Como puede ver en esta figura, los modelos pueden compartirse entre vistas. Específicamente,
características funcionales, características de despliegue, etc. Las vistas proporcionan
una separación clara de estas diversas preocupaciones. Esta separación le permite
considerar un subconjunto del sistema general sin empantanarse en la complejidad del
sistema como un todo.
sistema de software, en el que un modelo representa una abstracción del sistema bajo
La figura 4.6 muestra la relación entre vistas, diagramas y modelos. Como
este ejemplo y la creación de modelos que representan diferentes aspectos de un
los productos de trabajo que se representan en documentos u hojas de cálculo (por ejemplo)
pueden considerarse modelos, porque se ajustan a la definición de
un modelo dado en el párrafo anterior.
propiedades Como verá, en términos de propósito, no hay diferencia entre
que se coloca en un túnel de viento para obtener una mejor comprensión de su aerodinámica
modelo de implementación y un modelo de datos. Además, en un sentido general, incluso
Los modelos proporcionan la descripción específica, o el contenido, de una arquitectura. Para
Por ejemplo, una vista estructural podría consistir en un conjunto de modelos de la estructura
del sistema. Los elementos de tales modelos pueden incluir componentes identificables del
sistema y sus interfaces, y las interconexiones entre esos componentes.
(IEEE 1471 2000)
Modelos

Figura 4.6 Ejemplo de vistas, diagramas y modelos
Vista funcional
Es posible considerar el contenido del producto de trabajo del modelo funcional
tanto de forma lógica (o independiente de la tecnología) como física (o específica de la
tecnología) , por ejemplo. Estos dos aspectos del mismo modelo representan diferentes
niveles de realización del modelo.
porque queremos mostrar el despliegue de componentes (del Modelo Funcional) a los
nodos (del Modelo de Despliegue).
Aunque se utilizan diferentes modelos para capturar diferentes aspectos del sistema, un
modelo determinado puede pasar por una serie de refinamientos, en particular modelos
que representan aspectos de la solución, como el producto de trabajo del modelo
funcional. Los niveles discretos de realización por los que se mueve un modelo durante
su vida pueden proporcionar peldaños para pasar de un modelo inicial cuyo contenido es
muy conceptual a un modelo cuyo contenido es lo suficientemente detallado como para
ser utilizado como base de implementación.
El mismo pensamiento se puede aplicar a otros modelos. El modelo de datos, por
ejemplo, puede considerarse en términos de un modelo de datos lógicos (que identifica
entidades y sus relaciones) o en términos de un modelo de datos físicos (que también
Niveles de Realización
Diagrama
Modelos | 73
Funcional
Diagrama Diagrama
Modelo
Despliegue
Modelo

Físico
Lógico
Arquitectura
Arquitectura
reconoce las preocupaciones de implementación, como las tablas de índice y los
procedimientos almacenados que mejoran el rendimiento del acceso a los datos). Este
pensamiento se refleja en la Figura 4.7. Si corresponde, el arquitecto también puede optar
por conservar los modelos lógicos y crear modelos físicos separados. Este tema se analiza
con más detalle en el Capítulo 8, "Creación de la arquitectura lógica".
Finalmente, debemos señalar que la distinción entre elementos lógicos y físicos no es
blanco o negro. ¿Es lógico un componente Load Balancer, por ejemplo? La respuesta, por
supuesto, es "Depende". Ciertamente, el componente no es específico de la tecnología,
porque no hemos declarado qué tecnología se usará para proporcionar el equilibrio de
carga. ¡Tampoco es independiente de la tecnología, porque asume que hemos elegido un
entorno que requiere equilibrio de carga! En resumen, recuerde que los términos lógico y
físico no están bien definidos.
Tenga en cuenta que un nivel de realización no es lo mismo que un nivel de abstracción.
Un nivel de abstracción se refiere a una cantidad particular de detalle, donde cuanto mayor
sea el nivel de abstracción, menos detalle. Sin embargo, al considerar los niveles de
realización, no está simplemente agregando o eliminando detalles; usted está
fundamentalmente tomando decisiones que dan como resultado que se consideren diferentes element
Un componente que representa un Order Manager en el modelo funcional lógico
puede realizarse, en un entorno Java EE, como un Enterprise JavaBean (EJB) y proporcionar
interfaces específicas de Java EE en el modelo funcional físico, por ejemplo. Por lo tanto,
al pasar de la arquitectura lógica a la arquitectura física, es posible que el arquitecto deba
consultar a especialistas técnicos que estén profundamente familiarizados con cualquier
tecnología que se esté considerando, porque un uno a uno, uno a muchos o muchos a
-puede existir un mapeo entre elementos lógicos y elementos físicos, dependiendo de las
tecnologías (y patrones) que se utilicen. Analizamos este tema con más detalle en el
Capítulo 8, "Creación de la arquitectura lógica".
Figura 4.7 Vistas, modelos y niveles de realización
Modelo de datos
modelo funcional
Vista
modelo funcional
Nivel
Modelo de datos
Vista funcional Vista de implementación

Beneficios de los modelos
Características de un marco de descripción de arquitectura
Características de un Marco de Descripción de Arquitectura | 75
Además de los beneficios generales de documentar una arquitectura, crear
ÿ Comprender el impacto del cambio. Si un modelo contiene elementos que se derivan de
elementos de otros modelos (como elementos de solución que se derivan de requisitos), puede
ser posible documentar las relaciones entre los elementos de los distintos modelos. Estas
relaciones a menudo se denominan relaciones de trazabilidad, porque muestran cómo los
elementos de un modelo se remontan a los elementos de otro. Entonces el arquitecto puede
utilizarlos para
modelos tiene algunos beneficios específicos:
En términos simples, un marco de descripción de arquitectura representa un conjunto de
entender el impacto de hacer un cambio. El impacto de cambiar un requisito se puede
evaluar en términos del impacto en los elementos de la solución, por ejemplo. Por el contrario, el
impacto de cambiar un elemento de la solución (como reescribir un algoritmo computacional) se
puede determinar en términos de su cobertura observando los requisitos que este elemento de la
solución satisface total o parcialmente.
ÿ Detectar errores y omisiones en las primeras etapas del ciclo de vida. es mucho
puntos de vista (y, por lo tanto, puntos de vista, modelos, otros productos de trabajo, técnicas,
ÿ Ayudar con la planificación de proyectos. Los elementos de un modelo pueden ayudar
Es más barato crear un modelo a escala de un avión y colocarlo en un túnel de viento que construir
un avión real y hacerlo volar para comprender sus propiedades aerodinámicas. Del mismo modo,
es mucho más económico crear un modelo del diseño de un sistema de software y probar este
modelo que construir el sistema de software real para validar el diseño.
y así sucesivamente) que se pueden usar juntos para describir una arquitectura. En vez de
con la planificación del proyecto en términos de cronograma y recursos. Tener un modelo de la
solución que muestre qué elementos dependen de otros puede proporcionar una indicación de la
secuencia en la que se pueden implementar estos elementos, las habilidades requeridas y el
esfuerzo requerido.
ÿ Examinar los méritos relativos de diferentes opciones. La creación de varios modelos de un
avión, que cumplan todos los mismos requisitos, permite debatir los méritos relativos de cada
solución sin tener que pasar a la producción real a gran escala de varios aviones. De manera
similar, se pueden usar varios diseños de un sistema de software, capturados en modelos
apropiados, para discutir los méritos relativos de las soluciones de software propuestas.

poner un poco de carne en los huesos de la discusión anterior. Esta sección no es
Trabajar con las partes interesadas utilizando puntos de vista y perspectivas (Rozanski
2005)
otros en sus descripciones.
ejemplificado en ciertos marcos de descripción de arquitectura en uso hoy en día y para
ÿ Preocupaciones transversales, tomadas de Software Systems Architecture:
ser una instancia de un punto de vista) para cualquier proyecto dado, aunque diferentes
marcos de descripción de la arquitectura prefieren utilizar un término en lugar del
El propósito de esta sección es preparar el escenario para el marco de descripción de la
arquitectura utilizado en este libro mediante el examen de las características específicas que son
John Zachman (Zachman 1987)
ÿ Niveles de realización, tomados del Marco Zachman, creado por
existe correspondencia entre una vista y un punto de vista (si se considera una vista
la naturaleza del sistema en consideración (un sistema que se ejecuta en un solo nodo puede
no usar un punto de vista de implementación, por ejemplo).
catálogo y, si es necesario, los adapta a sus necesidades. La elección de los puntos de vista a
menudo se especifica mediante algún estándar organizacional (un punto de vista de requisitos
y un punto de vista funcional pueden ser obligatorios, por ejemplo), así como
“El modelo de vista “4+1” de la arquitectura de software” de Kruchten (Kruchten 1995)
En las siguientes descripciones, es importante recordar que un uno a uno
comenzando desde cero, un arquitecto normalmente selecciona puntos de vista desde un punto de vista
ÿ Múltiples vistas y el uso de una vista de escenarios, tomado de Philippe
(Clements 2003).
Modelo de Arquitectura de Software”, como lo define Philippe Kruchten (Kruchten
característica particular. Las características destacadas en esta sección son
se enfoca en asegurar que los muchos aspectos de la arquitectura estén claramente separados
pero tengan relaciones bien definidas y, por lo tanto, sean consistentes. Muchos de
los marcos de descripción de la arquitectura también incluyen elementos de orientación del
proceso. En Documenting Software Architectures: Views and Beyond se brindan consideraciones
adicionales para documentar una arquitectura de software de manera efectiva .
Un marco de descripción de arquitectura de uso común es "La vista "4 + 1"
marcos que puede encontrar, simplemente aquellos que ayudan a demostrar un
destinado a ser una discusión exhaustiva de toda la descripción de la arquitectura
Como verá, cada marco de descripción de arquitectura que discutimos
El modelo de vista 4 + 1 de arquitectura de software

Marco Zachman
el diseño.
requisitos arquitectónicamente significativos que ejercerán los escenarios, que
el uso de una vista de escenarios. Los escenarios normalmente se seleccionan en función de la
marco de descripción, que exhibe algunas características que vale la pena
mencionando específicamente, se muestra en la Figura 4.9. En particular, este marco
Una característica interesante de este marco de descripción de arquitectura es
o escenarios que se convierten en una quinta vista (la vista de escenarios).
arquitectura empresarial en lugar de arquitectura de software. esta arquitectura
El autor describe los diversos puntos de vista de la siguiente manera:
se muestra en la Figura 4.8.
Framework for Information Systems Architecture” (Zachman 1987), objetivos
1995). Este marco de descripción de la arquitectura define cinco vistas y es
y refleja su aspecto distribuido.
El Marco Zachman, creado por John Zachman y discutido en “A
dirigido.
su entorno de desarrollo.
permite al arquitecto validar si estos requisitos han sido
Vista de desarrollo
Vista de proceso
Vista lógica
Escenarios
Vista física
Figura 4.8 El modelo de vista “4+1” de la arquitectura de software
ÿ La vista de desarrollo describe la organización estática del software en
ÿ La vista lógica es el modelo de objetos del diseño (cuando se utiliza un método de
diseño orientado a objetos).
ÿ La descripción de una arquitectura se ilustra con algunos casos de uso seleccionados
ÿ La vista física describe la(s) asignación(es) del software al disco
ÿ La vista de proceso captura los aspectos de concurrencia y sincronización de

Gente Hora
La red
Datos Motivación
Función
Lista de procesos del
negocio metas/estrategias
LA RED
p.ej
p.ej
Arquitectura de
interfaz humana
Plan de negocios
Arquitectura
tecnológica
p.ej
p.ej
Modelo de negocio Modelo semántico
Estructura
de control
Arquitectura de
presentación
modelo de reglas
de negocio
p.ej
p.ej
abstracciones
p.ej
modelo de proceso de
negocio
p.ej
Definición
de tiempo
p.ej
p.ej
Arquitectura
de la aplicación
Diseño de sistemas
ORGANIZACIÓN
Lista de
organizaciones
importantes para
el negocio
p.ej
p.ej
p.ej
p.ej
DATOS
diseño de reglas
modelo de flujo
de trabajo
p.ej
Modelo de datos
físicos
Arquitectura
de seguridad
Perspectivas
Arquitectura
del sistema
distribuido
p.ej
Definición de datos
p.ej
Lista de ubicaciones
en las que opera la
empresa
p.ej
p.ej
ESTRATEGIA
Procesando
Modelo de datos
lógicos
Red de
arquitectura
p.ej
p.ej
Programa maestro
Programa
Lista de cosas
importantes para
el negocio.
eventos/ciclos
significativos
para el negocio
p.ej
estructura
Lista de
realiza
p.ej
Especificación de regla
p.ej
p.ej
p.ej
p.ej
CALENDARIO
sistema
logístico empresarial
p.ej
p.ej
lista de negocios
p.ej
FUNCIÓN
Figura 4.9 El marco de Zachman
Los miradores (las columnas) son
ÿ Función (el cómo). Esta columna describe las funciones de la empresa, como
los procesos comerciales y la funcionalidad de la aplicación de software. ÿ
Red (el dónde). Esta columna describe las ubicaciones en la empresa, como las
principales ubicaciones geográficas comerciales y los nodos del sistema. ÿ
Personas (el quién). Esta columna describe a las personas en la empresa.
ÿ Datos (el qué). Esta columna describe las entidades de la empresa, como
las entidades comerciales y las tablas relacionales.
no solo define varios puntos de vista (las columnas), sino que también define
explícitamente varios niveles de realización (las filas). El Marco Zachman utiliza el
término perspectiva para representar un nivel de realización (como se describe en este
libro) y el término abstracción para representar una vista.
Modelo de sistema
Detallado
Representaciones
modelo de tecnología
Empresa
Marcha
Alcance

ÿ Alcance. Esta fila define una perspectiva contextual.
conjunto de puntos de vista transversales (referidos como perspectivas) además de varios puntos de
vista básicos, como se muestra en la Figura 4.10.
Los niveles de realización (las filas) son
and Perspectives (Rozanski 2005), Nick Rozanski y Eoin Woods enfatizan una
ÿ Concurrencia. Describe la estructura de concurrencia del sistema y asigna elementos de
funcionalidad a unidades de concurrencia para identificar claramente las partes del sistema
que pueden ejecutarse simultáneamente y cómo se coordina y controla esta ejecución.
ÿ Desarrollo. Describe la arquitectura que soporta el proceso de desarrollo de software.
empresa, tales como metas y objetivos.
En Arquitectura de sistemas de software: trabajar con las partes interesadas utilizando puntos de vista
gestiona y distribuye la información.
ÿ Motivación (el por qué). Esta columna describe las motivaciones de los
ÿ Empresa en funcionamiento. Esta fila define el sistema operativo.
premio, como la programación de las capacidades.
ÿ Información. Describe la forma en que la arquitectura almacena, manipula,
ÿ Tiempo (el cuándo). Esta columna describe el impacto del tiempo en la entrada.
ÿ Representaciones detalladas. Esta fila define los módulos que se pueden implementar.
habilidades, interfaces e interacciones primarias.
ÿ Modelo tecnológico. Esta fila define una perspectiva física.
puntos de vista básicos, como se describe en su trabajo, son
ÿ Funcional. Describe los elementos funcionales del sistema y sus responsabilidades.
ÿ Modelo del sistema. Esta fila define una perspectiva lógica.
ÿ Modelo de negocio. Esta fila define una perspectiva conceptual.
Los autores describen sus diversos puntos de vista en forma de catálogo. los
Rozanski y Woods

Perspectiva de ubicación
Perspectiva de accesibilidad
Vista operativa
Perspectiva de usabilidad
Vista de simultaneidad
Perspectiva de disponibilidad
Perspectiva de rendimiento
Vista de información
Perspectiva de seguridad
Vista funcional
Vista de desarrollo
etc
Perspectiva de regulación
Figura 4.10 El marco de Rozanski y Woods
ÿ Operacional. Describe cómo se operará, administrará y admitirá el sistema cuando se
ejecute en su entorno de producción.
implementado, incluida la captura de las dependencias del sistema en su entorno de
tiempo de ejecución.
ÿ Rendimiento (y escalabilidad). La capacidad del sistema para ejecutarse de manera
predecible dentro de su perfil de rendimiento obligatorio y para manejar mayores volúmenes
de procesamiento.
ÿ Despliegue. Describe el ambiente en el cual el sistema será
ÿ Seguridad. La capacidad del sistema para controlar, monitorear y auditar de manera
confiable quién puede realizar qué acciones en qué recursos, y para detectar y recuperarse
de fallas en los mecanismos de seguridad.
ÿ Evolución. La capacidad del sistema para ser flexible frente al cambio inevitable que
experimentan todos los sistemas después de la implementación, en equilibrio con los costos
de proporcionar dicha flexibilidad.
Las perspectivas descritas (aunque no todas se muestran en la Figura 4.10) son
en parte operativo cuando sea necesario, y para manejar de manera efectiva las fallas que
podrían afectar la disponibilidad del sistema.
ÿ Disponibilidad (y resiliencia). La capacidad del sistema para ser total o

Un marco de descripción de la arquitectura
puntos de vista
Un marco de descripción de la arquitectura | 81
ÿ Regulación. La capacidad del sistema para cumplir con las leyes locales e internacionales, los
reglamentos cuasilegales, las políticas de la empresa y otras reglas y normas.
La Figura 4.11 muestra un resumen de los puntos de vista (y, por lo tanto, vistas) utilizados en
Es importante asegurarse de que se aplican los puntos de vista correctos en cualquier
ÿ Ubicación. La capacidad del sistema para superar los problemas provocados por las ubicaciones
absolutas de sus elementos y las distancias entre ellos.
cada uno de estos puntos de vista, consulte el Apéndice B, “Catálogo de puntos de vista”.
La Tabla 4.2 resume los puntos de vista. Para una descripción más completa de
ÿ Internacionalización. La capacidad del sistema para ser independiente de cualquier idioma, país
o grupo cultural en particular.
puntos de vista, dependiendo de la naturaleza del sistema bajo consideración. En
Además, el marco debe considerarse extensible, en el sentido de que se pueden agregar puntos de
vista según sea necesario.
ese equipo.
ÿ Recurso de desarrollo. La capacidad del sistema para ser diseñado, construido, implementado
y operado dentro de las limitaciones conocidas de personas, presupuesto, tiempo y materiales.
sistemas, y cada arquitecto que utilice este marco debe seleccionar el apropiado
discapacidades
el equipo de desarrollo actual, y las partes interesadas externas no son miembros de
ÿ Accesibilidad. La capacidad del sistema para ser utilizado por personas con
los marcos de descripción de la arquitectura discutidos en este capítulo. Este marco de descripción de
arquitectura se puede reutilizar para las arquitecturas de diferentes
indica el alcance de cada actor; las partes interesadas internas son miembros de
El marco de descripción de la arquitectura utilizado en este libro se basa en varios de
La Tabla 4.1 proporciona un resumen de las partes interesadas de la arquitectura y
identifica a quienes están potencialmente interesados en cada punto de vista. la mesa tambien
un ejemplo que demuestra los principios inherentes a dicho marco.
este libro.
ÿ Usabilidad. La facilidad con la que las personas que interactúan con el sistema pueden trabajar
de manera efectiva.
situación dada. El marco de descripción de la arquitectura presentado aquí es solo

Interno
Externo
Gestiona la ejecución operativa del sistema.
Externo
Papel
Desarrollador
Interno
Interno
Gerente de proyecto
Externo
Usuario
Cuadro 4.1 Resumen de las partes interesadas
Define la estructura del depósito de gestión de la configuración y los elementos
que residen en él
Comisiona (y financia) el sistema
Gestiona la evolución continua del sistema una vez que ha sido
Personal de apoyo
Externo
Proporciona los elementos de software o hardware necesarios en el desarrollo.
Prueba el sistema para asegurarse de que es apto para su propósito
Propietario de la aplicación
Externo
Responsabilidad primaria
mantenedor
Gestiona la ejecución del proyecto de desarrollo en términos de planificación,
dotación de personal, seguimiento y gestión de riesgos.
Proporciona soporte al sistema y realiza funciones de diagnóstico.
Externo
Alcance
Proveedor
Administrador de configuración interno
Administra los elementos relacionados con el negocio del sistema operativo.
desplegado
Administrador de sistema
Figura 4.11 El marco de descripción de la arquitectura
Utiliza la funcionalidad empresarial del sistema.
Ensayador
Administrador de Empresas Externo
Realiza el diseño detallado y la implementación del sistema.
opment o funcionamiento del sistema
Puntos de vista básicos
Solicitud
Punto de vista
Punto de vista
Gestión de sistemas
Punto de vista
Infraestructura
Funcional
Punto de vista
Punto de vista
Requisitos
Punto de vista
Seguridad
Validación
Punto de vista
Punto de vista
Punto de vista
Rendimiento
Despliegue
Punto de vista
Disponibilidad

Este punto de vista se ocupa de los elementos de la arquitectura que
contribuyen al funcionamiento operativo del sistema cuando se ha
implementado en producción.
Administrador, probador
Cuadro 4.2 Resumen del punto de vista
Todos los interesados
Propietario de la aplicación,
Proveedor, Sistema
Continuado
Ensayador
Proveedor, Sistema
Este punto de vista se ocupa de los elementos arquitectónicos que
soportan la distribución del sistema e incluye elementos como la
ubicación, los nodos, los dispositivos y las conexiones entre ellos.
Desarrollador, Mantenedor,
Este punto de vista se refiere a aquellos elementos arquitectónicos que
permiten que el sistema cumpla con los requisitos de disponibilidad
especificados. Este punto de vista también se ocupa de aquellos
elementos arquitectónicos que permiten que el sistema se recupere de
las fallas (que hacen que el sistema no esté total o parcialmente disponible).
Este punto de vista se ocupa de los requisitos del sistema que han dado
forma a la arquitectura e incluye requisitos funcionales, cualidades y
restricciones.
personal de apoyo,
Gestión
Solicitud
proporcionan el comportamiento independiente de la aplicación de la
solución, es decir, el comportamiento que el sistema debe proporcionar
para respaldar el propósito comercial del sistema.
Requisitos Todas las partes interesadas
permiten que el sistema cumpla con los requisitos de rendimiento
especificados (como el tiempo de respuesta y el rendimiento).
Punto de vista
Despliegue
Gerente de Proyecto, Tester
Desarrollador de Infraestructura, Mantenedor,
Proveedor, Sistema
Funcional
Validación
sustentan la funcionalidad (lógica) del sistema e incluye los elementos
estructurales a partir de los cuales se construye el sistema, las relaciones
entre ellos y su comportamiento.
Administrador de sistema,
Proveedor, Sistema
Rendimiento
Sistemas
Disponibilidad
Descripción
Gerente de Proyecto, Proveedor,
Administrador de negocios,
administrador de configuración,
Este punto de vista se ocupa de evaluar si el sistema proporcionará la
funcionalidad requerida, exhibirá las cualidades requeridas y se adaptará
a las restricciones definidas.
proporcionan el comportamiento específico de la aplicación de la
solución, es decir, el comportamiento que el sistema debe proporcionar
para cumplir con los requisitos comerciales.
Partes interesadas
Proveedor, Sistema

Productos del trabajo
Cuadro 4.2 Resumen del punto de vista (continuación)
Seguridad Este punto de vista se refiere a aquellos elementos arquitectónicos que
permiten que el sistema cumpla con los requisitos de seguridad
especificados, como el acceso autorizado a las funciones y recursos del
sistema. Este punto de vista también se ocupa de los elementos
arquitectónicos que permiten que el sistema detecte y se recupere de fallas
en los mecanismos de seguridad del sistema.
Descripción
Proveedor, Sistema
Partes interesadas
Punto de vista
la arquitectura.
ÿ La vista funcional se refiere a los elementos contenidos en las Decisiones de
arquitectura, Descripción general de la arquitectura, Modelo de datos y Funcional .
como agregar una vista de evolución si la evolución del sistema es una preocupación principal de
Solicitud, Principios de arquitectura empresarial, Entorno de TI existente,
Requisitos funcionales, Glosario, Requisitos no funcionales, Lista de requisitos
priorizados, Solicitudes de partes interesadas, Sistema
Productos de trabajo de Contexto y Visión .
no es una consideración inherente de la descripción de la arquitectura que seleccionó,
puede ignorar la vista de implementación (que considera la distribución). Por el contrario, puede
optar por agregar vistas si necesita un énfasis particular que
Modelo de Entidad, Modelo de Proceso de Negocio, Reglas de Negocio, Cambio
ÿ La vista de requisitos se refiere a los elementos contenidos en el Business
está construyendo un sistema que siempre se ejecuta en un solo nodo, por ejemplo,
Por lo tanto, para cualquier sistema dado, puede eliminar o agregar vistas según sea necesario. Si
este libro:
participar en una o más vistas. La figura 4.12 muestra los siguientes productos de trabajo, que se
utilizan en el marco de descripción de la arquitectura que utilizamos en
En la sección "Modelos" anterior en este capítulo, afirmamos que una vista se refiere a los
elementos contenidos en uno o más modelos (productos de trabajo) y que un modelo puede
Modelo de productos de trabajo.

Figura 4.12 Puntos de vista y productos de trabajo
Punto de vista Punto de vista
Despliegue Validación
Punto de vista
Punto de vista
Punto de vista
Infraestructura
Funcional
Punto de vista
Punto de vista
Solicitud
Punto de vista
Requisitos
Seguridad
Rendimiento
Punto de vista
Disponibilidad
Punto de vista
Productos de trabajo de evaluación, prueba de concepto de arquitectura, lista de
problemas, registro RAID y registro de revisión .
ÿ La vista de implementación hace referencia a los elementos contenidos en los productos de
trabajo Decisiones de arquitectura, Descripción general de la arquitectura y Modelo de
implementación .
Este marco de descripción de arquitectura utilizado en este libro también incorpora diferentes niveles
de realización y se representa en la Figura 4.13. El elemento importante a tener en cuenta es que el
marco se utiliza para describir tanto la arquitectura lógica como la arquitectura física. La arquitectura
lógica se analiza en detalle en el Capítulo 8, "Creación de la arquitectura lógica", y la arquitectura
física se analiza en el Capítulo 9, "Creación de la arquitectura física".
Una vista transversal potencialmente hace referencia a elementos en todos estos productos de
trabajo.
ÿ La vista de validación se refiere a los elementos contenidos en la Arquitectura
Niveles de Realización
Concepto
Glosario
Evaluación de arquitectura
Prueba de arquitectura
Registro RAID
Requerimientos funcionales
Entorno de TI existente
Visión
Descripción general de la arquitectura
Principios
Contexto del sistema
Decisiones de arquitectura
Arquitectura empresarial
Solicitudes de las partes interesadas
modelo funcional
Solicitud de cambio
Requisitos Priorizados
Lista
Registro de revisión
Modelo de datos
Modelo de proceso de negocio
Reglas del negocio
Requisitos
modelo de entidad comercial
no funcional

Visión
Solicitud de cambio
Lista
Requisitos
modelo funcional Registro RAID
Glosario
Reglas del negocio
no funcional
Modelo de datos
Visión
Concepto
Principios
Reglas del negocio
Modelo de datos
Solicitud de cambio
Lista
no funcional
Requisitos
modelo funcional
Concepto
Principios
Glosario
Registro RAID
Lógico
Físico
Figura 4.13 Niveles de Realización
Funcional
Solicitud
Punto de vista
Infraestructura
Punto de vista
Punto de vista
Requisitos
Validación
Punto de vista
Validación
Despliegue
Punto de vista
Punto de vista
Punto de vista
Punto de vista
Requisitos
Punto de vista
Punto de vista
Despliegue
Funcional
Punto de vista
Seguridad
Punto de vista
Punto de vista
Punto de vista
Rendimiento
Seguridad
Punto de vista
Punto de vista
Disponibilidad
Rendimiento
Solicitud
Punto de vista
Disponibilidad
Punto de vista
Infraestructura
Punto de vista
Punto de vista

El documento de arquitectura de software
Ver correspondencia
El Documento de arquitectura de software proporciona una descripción general completa
de la arquitectura del sistema, utilizando varias vistas arquitectónicas diferentes para
representar diferentes aspectos del sistema. (RUP 2008)
ÿ Decisiones de arquitectura
ÿ Vista de validación
ÿ Descripción general de la arquitectura
ÿ Vista de implementación
ÿ Objetivos del Documento de Arquitectura de Software
ÿ Vista funcional
ÿ Vista de requisitos
ÿ Portada (portada, historial de cambios, tabla de contenido, lista de figuras,
ÿ Vista de la aplicación
El documento de arquitectura de software | 87
referencias)
Como era de esperar, el documento de arquitectura de software que se entrega
se ajusta al marco de descripción de la arquitectura elegido. Un esquema para un
Documento de Arquitectura de Software, que se ajusta al marco de descripción de la
arquitectura que elaboramos en este capítulo, es el siguiente:
Aunque puede pensar que los puntos de vista son independientes, este no es
necesariamente el caso. Es posible que desee aplicar una regla que diga que todos los
componentes descritos en una vista funcional se implementan en los nodos en una vista
de implementación, por ejemplo. El término correspondencia de vista se usa para describir tales rela
Como mencionamos en el Capítulo 3, “Fundamentos del método”, la Especificación del
metamodelo de ingeniería de procesos de software y sistemas (SPEM) define tres tipos
de productos de trabajo: artefacto, resultado y entregable. Un entregable es un producto
de trabajo que se proporciona a un tercero interno o externo. El Documento de
arquitectura de software es un ejemplo de entrega y es el vehículo principal para
documentar y comunicar la arquitectura de software. En lugar de reinventar el contenido
definido en otros productos de trabajo, el Documento de arquitectura de software hace
referencia a estos productos de trabajo, como se explica en el Capítulo 3.

ÿ Vista de seguridad
ÿ Apéndices
ÿ Vista de infraestructura
Este marco de descripción de arquitectura se ejemplifica en los capítulos relacionados con
el estudio de caso (Capítulos 6 a 9). Primero, tocamos otro concepto fundamental de la
arquitectura de un sistema intensivo en software: la reutilización de activos existentes. Este tema
es el objeto del Capítulo 5, “Activos de arquitectura reutilizables”.
ÿ Vista de administración de
sistemas ÿ Vista de disponibilidad ÿ
Vista de rendimiento
Este capítulo discutió muchos de los conceptos fundamentales en la documentación de una
arquitectura de software, incluyendo vistas y puntos de vista y sus relaciones con los productos
de trabajo subyacentes. También presentamos un marco de trabajo de descripción de arquitectura
que se basa en prácticas comprobadas al documentar una arquitectura de software.
Resumen

Chapters 3-4.pdf

Recomendados

Recomendados

Más contenido relacionado

Similar a Chapters 3-4.pdf

Similar a Chapters 3-4.pdf (20)

Último

Último (20)

Chapters 3-4.pdf