La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

 La arquitectura se desarrolla en iteraciones de la fase de elaboración La arquitectura se desarrolla en iteraciones de la fase de elaboración  Ejemplo.

Presentaciones similares


Presentación del tema: " La arquitectura se desarrolla en iteraciones de la fase de elaboración La arquitectura se desarrolla en iteraciones de la fase de elaboración  Ejemplo."— Transcripción de la presentación:

1

2  La arquitectura se desarrolla en iteraciones de la fase de elaboración 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 Ejemplo. Adaptación de los casos de uso a la arquitectura ya existente  Los casos de uso conducen la arquitectura. Los casos de uso conducen la arquitectura.  ¿Qué es primero, la arquitectura o los casos de uso? ¿Qué es primero, la arquitectura o los casos de uso?  ¿Qué casos de uso son relevantes arquitectónicamente hablando? ¿Qué casos de uso son relevantes arquitectónicamente hablando?  La línea base de la arquitectura La línea base de la arquitectura  La descripción de la arquitectura puede adoptar diferentes formas La descripción de la arquitectura puede adoptar diferentes formas

3 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).

4 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.

5

6 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 implementa­mos 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.

7 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

8 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

9

10 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

11 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.

12 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

13 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.

14 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

15 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.

16 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.

17 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.

18

19 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 arquitectu­ra 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

20 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.

21 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 res­to 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


Descargar ppt " La arquitectura se desarrolla en iteraciones de la fase de elaboración La arquitectura se desarrolla en iteraciones de la fase de elaboración  Ejemplo."

Presentaciones similares


Anuncios Google