Transcript El Proceso Unificado está Centrado en la Arquitectura

EL PROCESO UNIFICADO ESTÁ
CENTRADO EN LA ARQUITECTURA
ÍNDICE
Utilización de patrones de la
arquitectura
 Un sistema con una arquitectura en
capas
 Descripción de la arquitectura
 El arquitecto crea la arquitectura

UTILIZACIÓN DE PATRONES DE LA
ARQUITECTURA
•
•
•
•
Las ideas del arquitecto Christopher Alexander sobre cómo los
“lenguajes de patrones” se utilizan para sistematizar principios
y prácticas importantes en el diseño de edificios y
comunidades, han inspirado a muchos miembros de !a
comunidad de la orientación a objetos a definir, coleccionar y
probar una gran variedad de patrones software.
La “comunidad de patrones” define un patrón como “una
solución a un problema de diseño que aparece con frecuencia”.
Muchos de los patrones de diseño están documentados en
libros, que presentan los patrones utilizando plantillas estándar.
Estas plantillas asignan un nombre a un patrón y presentan un
resumen de los problemas y las fuerzas que lo hacen surgir,
una solución en términos de colaboración de clases
participantes e interacción entre objetos de esas clases.
UTILIZACIÓN DE PATRONES DE LA
ARQUITECTURA
•
•
•
Las plantillas también proporcionan ejemplos de
cómo se utiliza el patrón en algunos lenguajes de
programación, junto con variantes del patrón, un
resumen con las ventajas y las consecuencias de
la utilización de patrones, y referencias a estos.
Según Alexander, sería bueno que los ingenieros
de software aprendiesen los nombres y el objetivo
de muchos patrones estándar, y que los aplicasen
para hacer diseños mejores y más compresibles.
Existen patrones de diseño como Facade,
Decorator, Proxy Observer Strategy y Visitor
ampliamente citados y utilizados.
UTILIZACIÓN DE PATRONES DE LA
ARQUITECTURA
•
•
•
•
•
La comunidad de patrones también ha aplicado esta idea, con una
plantilla de documento ligeramente modificada, para recoger
soluciones estándar a problemas de la arquitectura que ocurren
frecuentemente.
Algunos de estos patrones incluyen Layers, Pipes and Filters,
Broker Blackboard, Horizontal-Vertical Metadata y MVC.
Otros han desarrollado patrones para que se utilicen durante el
análisis (“patrones de análisis”), durante la implementación
(“idiomas” que hacen corresponder estructuras comunes de
orientación a objetos con aspectos peculiares de los lenguajes,
como C ++ o Smalltalk), e incluso para estructuras de
organización efectivas (“patrones de organización”).
Típicamente los patrones de diseño se implementan de una forma
muy directa en lenguajes orientados a objetos.
Algunos ejemplos pueden ser C++, Java y Smalltalk, mientras
que los patrones de arquitectura se manejan mejor con sistemas
o subsistemas e interfaces, y los ejemplos no incluyen
habitualmente código.
UTILIZACIÓN DE PATRONES DE LA
ARQUITECTURA
•
•
•
•
•
Desde nuestra perspectiva dirigida por modelos, definiremos
patron como una plantilla de colaboración, que es una
colaboración general que puede especializarse según lo
definido en la plantilla.
Por tanto, consideramos los patrones de diseño como
colaboraciones
entre
clases
e
instancias,
con
su
comportamiento explicado en los diagramas de colaboración.
Utilizaremos plantillas de colaboración ya que entendemos que
las soluciones son bastante generales.
Utilizaremos herencia, extensión y otros mecanismos para
especializar el patrón (especificando los nombres de clases,
número de clases, etc., que aparecen en la plantilla).
En muchos casos, cuando especializamos las plantillas de
colaboración, surgen colaboraciones concretas que pueden
trazarse directamente con los casos de uso.
UTILIZACIÓN DE PATRONES DE LA
ARQUITECTURA
•
•
•
•
•
•
Los patrones de las arquitecturas se utilizan de una forma parecida
pero se centran en estructuras e interacciones de grano más grueso,
entre subsistemas e incluso entre sistemas.
Existen muchos patrones de arquitectura, pero aquí sólo trataremos
brevemente algunos de los más interesantes.
El patrón Broker es un mecanismo genérico para la gestión de objetos
distribuidos.
Permite que los objetos hagan llamadas a otros objetos remotos a
través de un gestor que redirige la llamada al nodo y al proceso que
guardan al objeto deseado.
Esta redirección se hace de manera transparente, lo cual quiere decir
que el llamante no necesita saber si el objeto llamado es remoto.
El patrón Broker suele utilizar el patrón de diseño Proxy, que
proporciona un objeto sustituto local con la misma interfaz que el
objeto remoto para hacer transparentes el estilo y los detalles de la
comunicación distribuida.
UTILIZACIÓN DE PATRONES DE LA
ARQUITECTURA
•
•
•
•
•
Hay otros patrones que nos ayudan a comprender el hardware
de los sistemas que construimos y que nos ayudan a diseñar
nuestro sistema sobre él, como por ejemplo Client/Server,
Three-Tier, y Peer-to-Peer.
Estos patrones definen una estructura para el modelo de
despliegue y sugieren cómo se deben asignar los componentes
a los nodos.
En la Sección 4.5, ilustraremos cómo se pudo aplicar el patrón
Client/Server al sistema CA descrito en el Capítulo 3.
En nuestro ejemplo, la distribución cliente/servidor tiene un
nodo cliente que ejecuta el código de interfaces de usuario y
parte de la lógica de negocio (clases de control) en cada CA
“físico”.
El nodo servidor mantiene las cuentas y las reglas de negocio
que permiten verificar las transacciones.
UTILIZACIÓN DE PATRONES DE LA
ARQUITECTURA
•
•
•
•
El patrón Layers es aplicable a muchos tipos de sistemas.
Este patrón define cómo organizar el modelo de diseño en
capas, lo cual quiere decir que los componentes de una capa
sólo pueden hacer referencia a componentes en capas
inmediatamente inferiores.
Este patrón es importante porque simplifica la comprensión y
la organización del desarrollo de sistemas complejos,
reduciendo las dependencias de forma que las capas más bajas
no son conscientes de ningún detalle o interfaz de las
superiores.
Además, nos ayuda a identificar qué puede reutilizarse, y
proporciona una estructura que nos ayuda a tomar decisiones
sobre qué partes comprar y qué partes construir.
Regresar
UN SISTEMA CON UNA
ARQUITECTURA EN CAPAS
•
•
•
•
•
Un sistema con una arquitectura en capas pone a los
subsistemas de aplicación individuales en lo más alto.
Estos se construyen a partir de subsistemas en las capas más
bajas, como son los marcos de trabajo y las bibliotecas de
clases. Observemos la Figura 4.5.
La capa general de aplicación contiene los subsistemas que no
son específicos de una sola aplicación, sino que pueden ser
reutilizados por muchas aplicaciones diferentes dentro del
mismo dominio o negocio.
La arquitectura de las dos capas inferiores puede establecerse
sin considerar los casos de uso debido a que no son
dependientes del negocio.
La arquitectura de las dos capas superiores se crea a partir de
los casos se uso significativos para la arquitectura (estas capas
son dependientes del negocio).
FIGURA 4.5. LA ARQUITECTURA EN CAPAS
ORGANIZA LOS SISTEMAS EN CAPAS DE
SUBSISTEMAS
UN SISTEMA CON UNA
ARQUITECTURA EN CAPAS
•
•
•
•
Una capa es un conjunto de subsistemas que comparten el
mismo grado de generalidad y de volatilidad en las interfaces: las
capas interiores son de aplicación general a varias aplicaciones y
deben poseer interfaces más estables, mientras que las capas
más altas son más dependientes de la aplicación y pueden tener
interfaces menos estables.
Debido a que las capas inferiores cambian con menor frecuencia,
los desarrolladores que trabajan en las capas superiores pueden
construir sobre capas inferiores estables.
Subsistemas en diferentes capas pueden reutilizar casos de uso,
otros subsistemas de más bajo nivel, clases, interfaces,
colaboraciones, y componentes de las capas inferiores. Podemos
aplicar sobre un mismo sistema muchos patrones de arquitectura.
Los patrones que estructuran el modelo de despliegue (es decir,
Client/Server, Three-Tier, o Peer-to-Peer) pueden combinarse con
el patrón Layers, lo cual nos ayuda a estructurar el modelo de
diseño.
Los patrones que tratan estructuras en diferentes modelos son a
menudo independientes unos de otros. Incluso los patrones que
tratan el mismo modelo suelen poder combinarse bien
mutuamente.
UN SISTEMA CON UNA
ARQUITECTURA EN CAPAS
•
•
•
•
•
Por ejemplo, el patrón Broker se combina correctamente con el
patrón Layers, y ambos se utilizan en el modelo de diseño.
El patrón Broker se encarga de cómo tratar con la distribución
transparente de objetos, mientras que el patrón Layers nos
indica cómo organizar el diseño entero.
De hecho, el Patrón Broker puede interpretarse como un
subsistema en la capa intermedia3.
Obsérvese que a veces un patrón es predominante. Por
ejemplo, en un sistema en capas, el patrón Layers define la
arquitectura general y la descomposición del trabajo (cada
capa asignada a un grupo diferente), mientras que se pueden
utilizar Pipes y Filters dentro de una o más capas.
En contraste, en un sistema basado en Pipes y Filters,
mostraríamos la arquitectura general como un flujo entre
filtros, mientras que la división en capas podría utilizarse de
forma explícita para algunos filtros.
Regresar
DESCRIPCIÓN DE LA ARQUITECTURA
•
•
•
•
•
La línea base de la arquitectura desarrollada en la fase de
elaboración sobrevive, como dijimos en la Sección 4.4.1, en
forma de una descripción de la arquitectura.
Esta descripción se obtiene de versiones de los diferentes
modelos que son resultado de la fase de elaboración, como se
muestra en la Figura 4.6.
La descripción de la arquitectura es un extracto o, en nuestros
términos, un conjunto de vistas —quizá con una reescritura
cuidada para hacerlas más legibles— de los modelos que están
en la línea base de la arquitectura.
Estas vistas incluyen los elementos arquitectónicamente
significativos.
Por supuesto, muchos de los elementos del modelo que son
parte de la línea base de la arquitectura aparecerán también en
la descripción de la arquitectura.
DESCRIPCIÓN DE LA ARQUITECTURA
•
•
Sin embargo, no lo harán todos ellos, debido a
que para obtener una línea base operativa puede
ser necesario el desarrollo de algunos elementos
del modelo que no son arquitectónicamente
interesantes, pero que se necesitan para generar
código ejecutable.
Debido a que la línea base de la arquitectura no
sólo se usa para desarrollar una arquitectura, sino
también para especificar los requisitos del sistema
en un nivel que permita el desarrollo de un plan
detallado, el modelo de casos de uso de esta línea
base puede contener también más casos de uso
aparte de los interesantes desde el punto de vista
de la arquitectura.
DESCRIPCIÓN DE LA ARQUITECTURA
•
•
•
•
•
•
•
•
La descripción de la arquitectura debe mantenerse actualizada
a lo largo de la vida del sistema para reflejar los cambios y las
adiciones que son relevantes para la arquitectura.
Estos cambios son normalmente secundarios y pueden incluir:
La identificación de nuevas clases abstractas e interfaces.
La adición de nueva funcionalidad a los subsistemas existentes.
La actualización a nuevas versiones de los componentes
reutilizables.
La reordenación de la estructura de procesos.
Puede que tengamos que modificar la propia descripción de la
arquitectura, pero su tamaño no debe crecer.
Sólo se actualiza para ser relevante (Figura 4.6).
DESCRIPCIÓN DE LA ARQUITECTURA
•
•
•
•
•
•
En el Capítulo 3, comenzamos con una simplificación, diciendo
que sólo los casos de uso mostrarían el camino a través de los
requisitos, análisis, diseño, implementación y pruebas para
producir un sistema.
No obstante, para desarrollar software hay que hacer algo más
que conducirse a través de los flujos de trabajo guiado
exclusivamente por los casos de uso.
Los casos de uso solamente no son suficientes. Se necesitan
más cosas para conseguir un sistema de trabajo.
Esas “cosas” son la arquitectura.
Podemos pensar que la arquitectura de un sistema es la visión
común en la que lodos los empleados (desarrolladores y otros
usuarios) deben estar de acuerdo, o como poco, deben aceptar.
La arquitectura nos da una clara perspectiva del sistema
completo, necesaria para controlar el desarrollo.
DESCRIPCIÓN DE LA ARQUITECTURA
•
•
•
•
•
•
Como dijimos anteriormente, la descripción de la arquitectura
presenta vistas de los modelos.
Esto incluye casos de uso, subsistemas, interfaces algunas clases
y componentes, nodos y colaboraciones.
La descripción de la arquitectura también incluye requisitos
significativos para la arquitectura que no están descritos por
medio de los casos de uso.
Estos otros requisitos son no funcionales y se especifican como
requisitos adicionales, como aquellos relativos a la segundad, e
importantes restricciones acerca de la distribución y la
concurrencia (Sección 9.3.2).
La descripción de la arquitectura debería incluir también una
breve descripción de la plataforma, los sistemas heredados, y el
software comercial que se utilizará, como por ejemplo la
invocación de métodos remotos de Java (Remóte Method
Invocation, RMI) para la distribución de objetos.
Es más, es importante describir los marcos de trabajo que
implementan mecanismos (sección 9.5.1.4) genéricos, como el
almacenamiento y recuperación de un objeto en una base de
datos relacional.
FIGURA 4.6. DURANTE LA CONSTRUCCIÓN, LOS DIVERSOS MODELOS VAN
CRECIENDO HASTA COMPLETARSE (SEGÚN SE MUESTRA CON LAS FORMAS RELLENAS
EN LA ESQUINA SUPERIOR DERECHA). LA DESCRIPCIÓN DE LA ARQUITECTURA, SE
DEFINIÓ DURANTE LA TASE DE ELABORACIÓN. SE INCORPORAN POCOS, CAMBIOS
SECUNDARIOS A LA ARQUITECTURA (INDICADOS POR UN RELLENO PUNTEADO).
DESCRIPCIÓN DE LA ARQUITECTURA
•
•
•
•
•
•
Estos mecanismos pueden reutilizarse en varias realizaciones de caso
de uso ya que se han diseñado para llevar a cabo colaboraciones
reutilizables.
La descripción de la arquitectura también debería documentar todos
los patrones de arquitectura que se han utilizado.
La descripción de la arquitectura subraya los temas de diseño más
importantes y los expone para ser considerados y para obtener la
opinión de otros. Después se deben tratar, analizar y resolver estos
temas.
Estos análisis pueden, por ejemplo, incluir una estimación de la carga
del rendimiento, o requisitos de memoria, e imaginar requisitos
futuros que podrían romper la arquitectura.
Aunque esté detallada en lo necesario, la descripción de la
arquitectura es aún una vista de alto nivel.
Por un lado, no se pretende que cubra todo; no debería inundar a los
participantes con una cantidad desbordante de detalle.
DESCRIPCIÓN DE LA ARQUITECTURA
•
•
•
•
•
Es un mapa de carreteras, no una especificación detallada
del sistema entero. Por otro lado, debe representar lo que
cada participante necesita, por lo que incluso puede que
100 páginas no sean excesivas.
La gente utilizará un documento grande si contiene lo que
necesitan en una forma que sea rápidamente comprensible.
Después de todo, eso es lo que se espera de una
descripción de la arquitectura: debería contener lo que los
desarrolladores necesitan para hacer sus trabajos.
Cuando leemos una descripción de la arquitectura, nos
puede parecer que trata algunos de los subsistemas de
manera superficial, mientras que especifica en detalle las
interfaces y colaboraciones de un puñado de otros
subsistemas.
La razón para este tratamiento distinto es que los
subsistemas muy especificados son significativos para la
arquitectura, y deberían mantenerle bajo el control del
arquitecto (Secciones 12.4.2 y 14.4.3.1).
DESCRIPCIÓN DE LA ARQUITECTURA
•
•
•
•
•
Puede ser útil el tratar qué no es una arquitectura.
La mayoría de las clases, con operaciones, interfaces. y
atributos que son privadas en los subsistemas o en los
subsistemas de servicio (ocultas al resto del sistema), no son
significativas para la arquitectura.
Los subsistemas que son variantes de otros subsistemas no
son importantes desde una perspectiva de la arquitectura. La
experiencia indica que menos del 10 por ciento de las clases
son relevantes para la arquitectura.
El 90 por ciento restante no es significativo porque no es
visible al resto del sistema. Un cambio en una de ellas no
afecta a nada esencial fuera del subsistema de servicio.
Tampoco son arquitectónicamente relevantes la mayoría de las
realizaciones de casos de uso debido a que no imponen
ninguna restricción adicional al sistema.
DESCRIPCIÓN DE LA ARQUITECTURA
•
•
•
•
Este es el motivo por el cual los arquitectos pueden planificar
una arquitectura partiendo sólo de una fracción de los casos de
uso y de otros requisitos.
La mayoría de las realizaciones de caso de uso representan
simple comportamiento añadido fácil de implementar incluso a
pesar de que constituyen la mayoría de las funciones que el
sistema ofrece.
Y ésta es la clave:
la mayoría de la funcionalidad del sistema es en realidad fácil
de implementar una vez que hemos establecido la arquitectura.
La descripción de la arquitectura no incluye información que
sea sólo necesaria para validar o verificar la arquitectura. Por
tanto no tiene casos o procedimientos de prueba, y no incluye
una vista de la arquitectura del modelo de prueba. Estas
cuestiones no son de arquitectura.
DESCRIPCIÓN DE LA ARQUITECTURA

Sin embargo, como puede verse en la Figura 4.6, la
línea base de la arquitectura contiene una versión de
todos los modelos, incluida una versión del modelo
de prueba. Por tanto, la línea base subyacente a la
descripción de la arquitectura contiene pruebas
realizadas —todas las líneas base las incluyen.
Regresar
EL ARQUITECTO CREA LA
ARQUITECTURA
•
•
•
•
•
El arquitecto crea la arquitectura junto con otros
desarrolladores.
Trabajan para conseguir un sistema que tendrá un alto
rendimiento y una alta calidad, y será completamente
funcional, verificable, amigable para el usuario, fiable, de
alta disponibilidad, preciso, extensible, tolerante a cambios,
robusto, mantenible, portable, confiable, seguro, y
económico.
Ellos saben que han de convivir con esas restricciones y
que tendrán que tomar soluciones de compromiso entre
ellas —éste es el motivo por el que hay un arquitecto—.
El arquitecto posee la responsabilidad técnica más
importante en estos aspectos y selecciona entre patrones
de arquitectura y entre productos para establecer las
dependencias entre subsistemas para cada uno de esos
distintos intereses.
Aquí la separación de intereses significa la creación de un
diseño donde un cambio en un subsistema no retumba en
otros varios subsistemas.
EL ARQUITECTO CREA LA
ARQUITECTURA
•
•
•
•
El verdadero objetivo es cumplir con las necesidades de la
aplicación de la mejor forma posible con el estado actual de la
tecnología y con un coste que la aplicación pueda soportar, en
otras palabras, ser capaz de implementar la funcionalidad de la
aplicación (es decir, los casos de uso) de manera económica,
ahora y en el futuro.
En este punto el arquitecto tiene el soporte de UML y del Proceso
Unificado.
UML posee construcciones potentes para la formulación de la
arquitectura, y el Proceso Unificado nos ofrece directrices
detalladas sobre lo que constituye una buena arquitectura. Incluso
así, al final, la arquitectura seleccionada es el resultado de un
juicio basado en aptitudes y experiencia.
El arquitecto es el responsable de emitir este juicio. Cuando el
arquitecto presenta la descripción de la arquitectura, al término
de la fase de elaboración, al jefe de proyecto, está queriendo
decir: “Ahora sé que podemos construir el sistema sin, encontrar
ninguna sorpresa técnica importante,”
EL ARQUITECTO CREA LA
ARQUITECTURA
•
•
•
•
•
Un arquitecto cualificado se consigue mediante dos tipos de aptitudes.
Una es el conocimiento del dominio en el que trabaja, por lo que debe
trabajar adquiriendo experiencia con todos los usuarios —no sólo con
los desarrolladores—.
El otro es el conocimiento del desarrollo de software, incluso debe ser
capaz de escribir código, ya que debe comunicar la arquitectura a los
desarrolladores,
coordinar
sus
esfuerzos,
y
obtener
su
retroal¡mentación.
También es valioso que el arquitecto tenga experiencia con sistemas
similares al que se está desarrollando.
El arquitecto ocupa un puesto difícil en la organización de desarrollo.
No debería ser jefe de proyecto, ya que ese puesto tiene muchas
dificultades además de la arquitectura.
Debe contar con el compromiso incondicional de la dirección, tanto
para crear la arquitectura por primera vez, como para forzar a que se
cumpla. Además debe ser lo bastante flexible como para encajar las
opiniones útiles de los desarrolladores y otros implicados.
EL ARQUITECTO CREA LA
ARQUITECTURA
•
•
•
•
•
•
Éste es un breve resumen de lo que el arquitecto pone sobre la
mesa.
Puede que un solo arquitecto no sea suficiente para sistemas
grandes.
En su lugar, puede ser una sabia decisión el tener un grupo de
arquitectura para desarrollarla y mantenerla.
El desarrollo de la arquitectura consume un tiempo de
calendario considerable.
Este tiempo está al principio del calendario de desarrollo y
puede incomodar a los directores que están acostumbrados a
ver dedicado el tiempo de desarrollo a la implementación y
pruebas en su mayor parte.
Sin embargo, la experiencia indica que la duración total del
desarrollo desciende marcadamente cuando es una buena
arquitectura la que guía las últimas fases. (Capítulo 5.)
Regresar