Centrado en la Arquitectura-3.ppt

EL PROCESO UNIFICADO ESTÁ
CENTRADO EN LA ARQUITECTURA
ÍNDICE







La arquitectura se desarrolla en iteraciones de la
fase de elaboración
Ejemplo. Adaptación de los casos de uso a la
arquitectura ya existente
Los casos de uso conducen la arquitectura.
¿Qué es primero, la arquitectura o los casos de
uso?
¿Qué casos de uso son relevantes
arquitectónicamente hablando?
La línea base de la arquitectura
La descripción de la arquitectura puede adoptar
diferentes formas
LA ARQUITECTURA SE DESARROLLA EN
ITERACIONES DE LA FASE DE ELABORACIÓN
•
•
•
Comenzaremos determinando un diseño de alto
nivel para la arquitectura, a modo de una
arquitectura en capas.
Después formamos la arquitectura en un par de
construcciones (Capítulo 10) dentro de la
primera iteración.
En la primera construcción, trabajamos con las
partes generales de la
aplicación que son
generales en cuanto al dominio, y que no son
específicas
del
sistema
que
pensamos
desarrollar es decir, seleccionamos el software
del sistema (capa de software del sistema)
(sección 9.5.1.2.2), el middleware, los sistemas
heredados, los estándares y las políticas de
uso).
LA ARQUITECTURA SE DESARROLLA EN
ITERACIONES DE LA FASE DE ELABORACIÓN
•
•
•
Decidimos que nodos contendrá nuestro
modelo de desarrollo y cómo deben
interactuar entre ellos.
También decidimos cómo
manejar los
requisitos generales no funcionales, así
como la funcionalidad de estos requisitos.
Con la primera pasada es suficiente para
tener
una
visión
general
del
funcionamiento de la aplicación.
FIGURA 4.2. LOS CASOS DE USO PUEDEN SER DE SARRO
LIADOS DE ACUERDO A LAS ENTRADAS DE LOS CLIENTES Y
DE LOS USUARIOS. NO OBSTANTE, TAMBIÉN SE VEN
INFLUENCIADOS POR LA ARQUITECTURA SELECCIONADA.
LA ARQUITECTURA SE DESARROLLA EN
ITERACIONES DE LA FASE DE ELABORACIÓN.
•
•
•
•
•
•
•
En la segunda construcción, trabajamos con los aspectos de la
arquitectura específicos de la aplicación (capa específica de la
aplicación).
Escogemos un conjunto de casos de uso relevantes en cuanto a la
arquitectura, capturamos los requisitos, los analizamos, los
diseñamos, los implementamos y los probamos.
El resultado serán nuevos subsistemas implementados como
componentes del desarrollo que soportan los casos de uso
seleccionados.
Pueden existir también algunos cambios en los componentes
significativos de la arquitectura que implementamos en la primera
entrega (cuando no pensamos en términos de casos de uso).
Los componentes nuevos o cambiados se desarrollan para realizar
los casos de uso, y de esta forma la arquitectura se adapta para
ajustarse mejor a los casos de uso.
Entonces elaboraremos otra construcción, y así sucesivamente
hasta terminar con las iteraciones.
Si este final de las iteraciones tiene lugar en el final de la fase de
elaboración, habremos conseguido una arquitectura estable.
LA ARQUITECTURA SE DESARROLLA EN
ITERACIONES DE LA FASE DE ELABORACIÓN
•
•
•
•
•
Cuando
tenemos
una
arquitectura
estable,
podemos
implementar la funcionalidad completamente realizando el
resto de casos de uso durante la fase de construcción.
Los casos de uso implementados durante la fase de
construcción se desarrollan utilizando como entradas los
requisitos de los clientes y de los usuarios (Figura 4.2), pero
los casos de uso están también influenciados por la
arquitectura elegida en la fase de elaboración.
Según vayamos capturando nuevos casos de uso, vamos
utilizando el conocimiento que ya tenemos de la arquitectura
existente para hacer mejor nuestro trabajo.
Cuando calculamos el valor y el coste de los casos de uso que
se sugieren, lo hacemos a la luz de la arquitectura que
tenemos.
Algunos casos de uso serán más fáciles de implementar,
mientras que otros serán nías difíciles.
Regresar
EJEMPLO. ADAPTACIÓN DE LOS CASOS DE USO
A LA ARQUITECTURA YA EXISTENTE
•
•
•
•
•
El cliente ha requerido una función que supervise el
proceso de carga.
Esto se especificó como un caso de uso que midiera la
carga, con un nivel de prioridad alto en el computador.
La implementación de ese caso de uso podría haber
requerido algunos cambios en sistema operativo en
tiempo real que se estaba utilizando.
Entonces, el equipo de desarrollo sugirió que la
funcionalidad requerida fuera implementada en un
dispositivo externo separado que hiciera llamadas al
sistema y midiera el tiempo de respuesta.
El cliente obtuvo mayor fiabilidad en las medidas y el
equipo de desarrollo evitó tener que cambiar partes
críticas de la arquitectura subyacente.
Regresar
FIGURA 4.3. LOS CASOS DE USO CONDUCEN EL
DESARROLLO DE LA ARQUITECTURA, Y LA
ARQUITECTURA INDICA QUÉ CASOS DE USO
PUEDEN REALIZARSE.
LOS CASOS DE USO CONDUCEN LA
ARQUITECTURA.
•
•
•
•
•
Negociamos con el cliente y decidimos si los casos de uso
podrían cambiarse para hacer la implementación más
sencilla, ajustando los casos de uso y el diseño resultante
con la arquitectura que ya tenemos.
Este ajuste significa que debemos considerar que ya
tenemos los subsistemas, interfaces. casos de uso,
realizaciones de casos de uso, clases y demás.
Ajustando los casos de uso con la arquitectura, podemos
crear nuevos casos de uso, subsistemas y clases con poco
esfuerzo, partiendo de las que ya existen.
Así, por una parte, la arquitectura está influenciada por
aquellos casos de uso que queremos que el sistema
soporte.
Los casos de uso conducen la arquitectura.
Por otra parte, utilizamos nuestro conocimiento de la
arquitectura para hacer mejor el trabajo de captura de
requisitos, para obtener casos de uso. La arquitectura guía
los casos de uso (Figura 4.3).
Regresar
¿QUÉ ES PRIMERO, LA ARQUITECTURA O
LOS CASOS DE USO?
•
•
•
•
•
Tenemos otra vez el típico problema del “huevo y la gallina”.
La mejor forma de resolver estos problemas es mediante una
iteración. Primero, construimos una arquitectura tentativa
básica a partir de una buena comprensión del área del dominio
pero sin considerar los casos de uso detallados.
Entonces, escogemos un par de casos de uso y ampliamos la
arquitectura adaptándola para que soporte esos casos de uso.
Después, escogemos algunos casos de uso más y construimos
una arquitectura todavía mejor, y así sucesivamente.
Con cada iteración, escogemos e implementamos un conjunto
de casos de uso para validar, y si es necesario, mejorar la
arquitectura.
¿QUÉ ES PRIMERO, LA ARQUITECTURA O
LOS CASOS DE USO?
•
•
•
•
•
Con cada iteración, escogemos e implementamos un
conjunto de casos de uso para validar, y si es necesario,
mejorar la arquitectura.
Con cada iteración también implementamos además las
partes de la arquitectura específicas de la aplicación
basadas en los casos de uso que hemos seleccionado.
Los casos de uso entonces nos ayudan a mejorar
gradualmente la arquitectura según vamos iterando para
completar el sistema.
Este es uno de los beneficios de los desarrollos
conducidos por casos de uso.
Resumiendo, una buena arquitectura es algo que nos
permite obtener los casos de uso correctos, de manera
económica, hoy y en el futuro.
Regresar
¿QUÉ CASOS DE USO SON RELEVANTES
ARQUITECTÓNICAMENTE HABLANDO?
•
•
•
•
•
La arquitectura se desarrolla mediante iteraciones, principalmente
durante la fase de elaboración.
Cada iteración se desarrolla, comenzando con los requisitos y
siguiendo con el análisis, diseño, implementación y pruebas, pero
centrándonos en los casos de uso relevantes desde el punto de
vista de la arquitectura y en otros requisitos.
El resultado al final de la fase de elaboración es una línea base de
la arquitectura —un esqueleto del sistema con pocos “músculos”
de software.
¿Qué casos de uso son relevantes arquitectónicamente
hablando?
Plantearemos esta cuestión en la Sección 12.6.
Por ahora, es suficiente con decir que los casos de uso
arquitectónicamente relevantes son aquellos que nos ayudan a
mitigar los riesgos más importantes, aquellos que son los más
importantes para los usuarios del sistema, y aquellos que nos
ayudan a cubrir todas las funcionalidades significativas, de forma
que nada quede en penumbra.
¿QUÉ CASOS DE USO SON RELEVANTES
ARQUITECTÓNICAMENTE HABLANDO?
•
•
•
La implementación, integración y prueba de la
línea base de la arquitectura proporciona
seguridad al arquitecto y a otros trabajadores de
su equipo, por lo que comprender estos puntos es
algo francamente operativo.
Esto es algo que no puede obtenerse mediante un
análisis y diseño “sobre el papel”.
La línea base de la arquitectura de operación
proporciona una demostración que funciona para
que los trabajadores puedan proporcionar sus
retroalimentaciones.
Regresar
LA LÍNEA BASE DE LA ARQUITECTURA ES
UN SISTEMA “PEQUEÑO Y FLACO”
•
•
•
•
•
Al final de la fase de elaboración hemos desarrollado
modelos del sistema que representan los casos de uso más
importantes y sus realizaciones, desde la perspectiva de la
arquitectura.
También hemos decidido, como ya se discutió en la Sección
4.3, “Casos de uso y arquitectura”, con qué estándares
contamos, qué software del sistema y qué middleware
utilizar, qué sistemas heredados reutilizar y qué
necesidades de distribución tenemos.
Así, tendremos una primera versión de los modelos de
casos de uso, de análisis, de diseño y demás.
Esta agregación de modelos (Figura 4.4) es la línea base de
la arquitectura: es un sistema pequeño y flaco.
Tiene las versiones de todos los modelos que un sistema
terminado contiene al final de la fase de construcción.
Incluye el mismo esqueleto de subsistemas, componentes y
nodos que un sistema definitivo, pero no existe toda la
musculatura.
LA LÍNEA BASE DE LA ARQUITECTURA ES
UN SISTEMA “PEQUEÑO Y FLACO”
•
•
•
•
No obstante, contiene comportamiento y código ejecutable.
El sistema flaco se desarrollará para convertirse en un
sistema hecho y derecho, quizás con algunos cambios sin
importancia en su estructura y comportamiento.
Los cambios son menores porque al final de la tase de
elaboración hemos definido una arquitectura estable; si no.
la fase de elaboración debe continuar hasta que alcance su
objetivo.
Esto no es del todo correcto, Al final de la fase de
elaboración, tenemos una versión del modelo de casos de
uso arquitectónicamente significativos y los casos de uso
(más del 80%) que necesitamos tener especificados para
hacer un análisis del negocio.
Así, la línea base de la arquitectura tiene más del modelo
de casos de uso y del modelo de análisis que lo que la
figura 4.4 indica. No obstante, para nuestro propósito en
este momento podemos hacer esta simplificación.
LA LÍNEA BASE DE LA ARQUITECTURA ES
UN SISTEMA “PEQUEÑO Y FLACO”
•
•
•
Cada caso de uso del modelo de casos de uso
corresponde, por ejemplo, a una realización de caso de
uso en los modelos de análisis y diseño. y a una prueba
en el modelo de pruebas.
Los procesos y la estructura de los nodos deben
ajustarse a la ejecución requerida por los casos de uso,
en caso contrario, el modelo de casos de uso o el modelo
de despliegue deben modificarse, quizás cambiando la
forma en que las clases activas se asignan a los nodos
para una mejor ejecución.
Tales cambios en el desarrollo o en el modelo de diseño
pueden conducir a alteraciones en el modelo de casos de
uso, si es que los cambios lo requieren). Los elementos
del modelo, en los diferentes modelos, están, como se
dijo en la Sección 2.3.7, relacionados entre sí a través de
las dependencias de traza.
FIGURA 4.4. LA LÍNEA BASE DE LA ARQUITECTURA ES UNA
VERSIÓN INTERNA DEL SISTEMA, QUE ESTÁ CENTRADA EN LA
DESCRIPCIÓN DE LA ARQUITECTURA.
LA LÍNEA BASE DE LA ARQUITECTURA ES
UN SISTEMA “PEQUEÑO Y FLACO”
•
•
•
•
•
•
No obstante, la línea base de la arquitectura, esto es, la
versión interna del sistema al final de la fase de
elaboración, se representa por algo más que los artefactos
del modelo.
También se incluye la descripción de la arquitectura.
Esta descripción se desarrolla habitual mente de forma
concurrente, a menudo incluso antes que las actividades
que obtienen las versiones del modelo que son parte de la
línea base de la arquitectura.
El papel de la descripción de la arquitectura es guiar al
equipo de desarrollo a través del ciclo de vida del sistema
—no sólo por las iteraciones del ciclo actual, sino por todos
los ciclos que vengan—.
Éste es el estándar a seguir por todos los desarrolladores,
ahora y en el futuro.
Como la arquitectura debería ser estable, el estándar
debería ser estable también.
Regresar
LA DESCRIPCIÓN DE LA ARQUITECTURA
PUEDE ADOPTAR DIFERENTES FORMAS
•
•
•
•
•
Puede ser un extracto (de las versiones) de los modelos que son parle
de la línea base de la arquitectura, o puede ser una reescritura de los
extractos de forma que sea más fácil leerlos.
Volveremos a esto en la Sección 4.4.3, “Descripción de la
arquitectura”.
En cualquier caso, incluye extractos o vistas de los modelos que son
parte de la línea base de la arquitectura.
A medida que se desarrolla el sistema y los modelos se van haciendo
más voluminosos en las últimas fases, la arquitectura seguirá
incluyendo vistas de las nuevas versiones de los modelos.
Asumiendo que la línea base de la arquitectura ha desarrollado una
arquitectura estable —esto es, los elementos del modelo relevantes
arquitectónicamente no cambian en las sucesivas iteraciones—, la
descripción de la arquitectura también será estable, e incluirá en todo
momento vistas de los modelos del sistema.
LA DESCRIPCIÓN DE LA ARQUITECTURA
PUEDE ADOPTAR DIFERENTES FORMAS
•
•
•
•
•
•
•
Es fascinante observar que resulta posible desarrollar una
arquitectura estable durante la fase de elaboración del primer
ciclo de vida, cuando solamente se ha invertido aproximadamente
un 30 por ciento de la primera versión.
Esta arquitectura constituirá los pilares del sistema el resto de su
vida.
Aunque los cambios en los pilares resultarán costosos, y en
algunos casos muy difíciles, es importante obtener una
arquitectura estable pronto en el desarrollo del trabajo.
El desarrollo de una arquitectura para un sistema en particular es,
por una parte, la creación de algo nuevo. Por otro lado, la gente
lleva desarrollando arquitecturas muchos años.
Se tiene experiencia y conocimiento en el desarrollo de buenas
arquitecturas. Hay muchas “soluciones” genéricas —estructuras,
colaboraciones y arquitecturas físicas— que han evolucionado a lo
largo de muchos años y con las que todo arquitecto con
experiencia debería estar familiarizado.
Estas soluciones se llaman habitualmente patrones.
Los patrones genéricos son recursos con los que los arquitectos
pueden contar.
Regresar