DOCUMENTACION DE LA ARQUITECTURA Después de entender los conceptos y la importancia y tengamos nociones de disefio de arquitectura de software, necesitamos saber cémo capturar la informacién del proyecto y documentarlo. Para eso, introducimos los conceptos de visiones y de puntos de vista arquitecturales, que facilitan Ia documentacién por mostrar las diferentes dimensiones que una arquitectura presenta. Este capitulo no dicta mm tmico lenguaje o modelo de documentacién de arquitectura, sino que presenta ejemplos de como hacerlo.Este eapitule tiene como objetivo hacer que el lector sea capaz de entender que: + El documento de arquitectura ausilia en el proceso de diseflo, es una herramienta de comunicacton entre las partes interesadas y puede servi de modelo de anilisis del software; + Toda informacion presente arquitectura es una decision arquitectural; + Decisiones arquitecturales pueden ser existenciales, descriptivas 0 ejecutivas, + Decisiones arquitecturales se relacionan, udiendo restringir, impedir, falitar, eomponer, entrar en conflicto, ignorax, depender 0 ser alternativa a otras decisiones arquitecturales; ¥ + Un nico diagrama no es suficiente para contener la cantidad de informacion que debe ser ‘mostrada por un anquiteeto, Por eso, 1a necesidad de miiltiples visiones arquiteeturales; ARQUITECTURA Y DOCUMENTO DE LA ARQUITECTURA La arquitectura de un software existe independientemente de ella ser proyectada o documentada. Sin embargo, al dejar Ia arquitectura simplemente “emerger” a partir del software, 0 sea, evolucionar a lo largo del proceso de desarrollo sin proyecto o documentacién, corremos el riesgo de no guitar provecho de les beneficios que ella proporciona, Por otro lado, sélo realizar el diseiio arquitectural y no documentarlo (o documentarlode forma precaria), puede minimizar las ventajas a ser oblenidas por la arquitectura. Esto puede ‘ocurrir porque documentar la arquitectura, ademas de ausiliar el propio proceso de diseiio, también proporciona: + una herramienta de comunicacién entre las diversas partes involueradas; + Ia integridad conceptual al sistema y al ‘proceso de desarrollo; + un modelo para analisis anticipado del sistema; + una herramienta de rastreabilidad entre los requisitos y los elementos del sistema, Auxilio al Proceso de Disento A pesar de dividir conceptualmente el proceso de diseiio del proceso de documentaci6n, es comin ‘que ambos ocurran en paralelo en la préetica, ‘Cuando esto ocurre, la documentacién ayuda en el iserio, principalmente en el sentido de separacion, de preocupaciones. Esta separacién es beneficiosa porque hay diferentes lenguajes, que pueden ser grifieos © textuales, que encajan mejor en Ia descripcion deARQUITECTURA ¥ DISENO DEL SOFTWARE (SPANISH EDITION) cada aspecto, ayudando no sélo a una mejor representacién, sino también en un mejor odelado y evaluaci6n en relacin a los objetivos. ‘A. continuacion, veremos dos ejemplos que ftustran la documentacton de algunas deeisiones arquitecturales relacionadas con aspectos diferentes del Videoclub. Podemos observar como 1 Videoclub esta dividido en grandes médulos fancionales y, asi, podemos inferir cuales son sus principales fneionalidades y algunas de sus selaciones entre si. Podemos decir que las decisiones arquitecturales del ejemplo son presentadas bajo el punto de vista funcional del sistema, constituyendo una vision funcional del software. Note también que esta no es la mejor forma de representar, por ejemplo, el desarrollo de dar de alta de los usuarios que seré externalizado 0 como el servicio de transmision de videos debe ejecutarse en 7 servidores en los dias habiles yen 15 servidores en Jos fines de semana y festivos, cuando Jademanda aumenta, EJEMPLO: Decisién Arquitectural 001. El ‘Videoclub esta dividido en cineo grandes médulos fiuncionales. Cada miédulo es responsable por proporcionar un conjunto de funcionalidades relacionadas entre sf. Los grandes médulos del Videoclub son: + Alquiler de Peliculas; + Transmisor de Peliculas; + Motor de Sugerencias; + Dar de alta a Usuarios; «+ Dar de alta a Peliculas.Médulos funcionales del Videoelub, EI estereotipo <> del diagrama indica los :médulos funcionales que componen el sistema. Por su parte el estereotipo <> indiea relaciones de uso entre los médulos para que puedan Implementar sus funciones. Por ltimo, el estereotipo <> indica una relacion de especialzacién de los datos guardados enel elemento responsable del registro. Objetivos: La division en médulos funcionales posibilita la division de la implementacién entre los equipos de desarrollo de acuerdo con la cespecialidad de cada equipo.Motivacién: Las diversas funciones a ser ‘proporcionadas por el Videoclub fueron agrupadas ‘en preocupaciones communes (registro de datos, alquiler y transmision de peliculas, y sugerencias al usuario). El registro debe estar especializado en dos tipos para dividir el esfuerzo de desarrollo: alta de peliculas y de usuarios. El motor de sugerencias debe ser alimentado con los datos del hist6rico de alquileres del usuario e informaciones sobre la base de peliculas en el sistema. EJEMPLO: Decisién Arquitectural 002. La implantacion del_médulo que implementa las funcionalidades del servicio de transmision de peliculas debe depender sélo de un pardmetro: + direcciones.servidores configuracién: lista de direcciones IP de los servidores que constituyen el servicio de configuracién del Videoelub, Los otros pardmetros de configuracién deben_ ser obtenidos & partir de Ta comunieaciin con el servicio de configuracin, Objetvos: Facilitar la operabilidad del sistema Motivacién: El servicio de configuracién del YVideoclub es tun cenralizador de la configuracién Gel sistema, En A, el operador del sistema introduce direeciones de servicios para que estén disponibles para la configuracién de una nueva fstancia, Cuando la instancla del servicio de transmmisién de peliculas es iniciada, ella hace peticiones al servicio de configuracion por las direcciones de los servicios dados de alta y de los servicios de almacenamiento de peliculas, por sjemplo.Herramienta de Comunieacién Ya sabemos que las diferentes partes interesadas rmuestran diferentes preocupaciones sobre Giferentes aspectos del sistema, Como 1a documentacién de Ta arquitectura versa sobre las muchas preocupaciones de los interesados, sive de hherramienta para la comunicacién, ya que proporciona un vocabulario comin sobre el sistema, ademils de registrar las relaciones entre las preocupaciones y de que forma los eventuales ‘conflictos fueron o deben ser resueltos. Note que para servir de herramienta de comunicacion, el documento arquitectural debe ser ‘eonstruide de forma que respete el eonocimiento y las necesidades de todas las partes. ara que esto sea posible, se debe conocer para ‘quien el documento esta siendo escrito. Por To ‘tanto, debemos escribir la arquitectura de forma ‘que posea partes que interesen a los usuarios, a los ‘lientes, a los desarrolladores, a los testadores, al gerente de proyecto 0 a otros personajes Involucrados en el proceso, Por ejemplo, los usuarios buscan por las fancionalidades, capacidades y comportamiento del sistema, no por como este fue dividido en médulos, como los médulos se comunican entre s{o si ellos fueron desarrollados desde cero o tuvieron partes reutilizadas de otros sistemas. Clientes y gerentes tienen algunos intereses semejantes, como costes de desarrollo o cronograma de lanzamiento, Sin ‘embargo, Ios clientes también se interesan en Ia adecuacién del software a su negocio, mientras que al gerente basca como minimizar los costes paraAnquitecrura ¥ p1seso pet adecuarse al presupuesto, 0 como las tareas de ‘mplementacién seran divididas entre su equipo de desarrollo. Finalmente, desarrolladores y testadores estén interesados en aspectos téenies del diseio, por ejemplo, como es la divisién en médulos del eben ser implementades, cada uno motivado por su papel en el proceso de desarrollo Integridad Conceptual Porotto lado, el documento necesita demostrar consistencia entre los diversos aspectos del disetio de la arquitectura para que haya comunicaeién preceupaciones es una herramienta poderosa de isolo, las soluciones para las diferentes preocupaciones trabajan interligadas durante Ia implementacién, 0 sea, cuando resuelven el problema. Ast, necesitamos de Integridad en dos nivoles: entre las partes interesadas y entre Tos ‘iversos aspectos del documento de arquitectur. La integridad conceptual entre Las diversas partes es la defendida por Brooks, en The Mythical ‘Man-Month, porque facilita el éxito en el desarrollo de sistemas de software. Si los interesados ~ y principalmente los desarrolladores ~ no tienen en ‘mente el mismo diseiio que se transformard en producto, son pocas las garantias de que el producto implementado seré el proyectado. Por ‘eso, en el proceso, el documento de anquitectura sive para restringir eventuales “deslicescconceptuales” en relacién al diseio arguitectural y prevenir futuras discordanclas entre las partes, Inclusive de intereses similares, EJEMPLO: En ol Videoclub, si dividiéramos a los desarrolladores en varios equipos, es comin que haya una mayor interaceiOn entre Ios miembros de ‘un mismo equipo que entre equips diferentes. ‘Vamos a considerar que delegamos a un equipo la ‘mplementaeién del serviclo responsable de las funcionalidades del médulo Dar de alta de Peliculas ya otto equipo el médulo Transmisor de Peliculas, Para que la implementacion de los dos médulos pueda ser paralelizada y para que sean evitadas ‘suposiciones erréneas o innecesarias por parte de cada equipo sobre otros médulos (, por lo tanto, sea menos costosa la integracion), debemos definir ccuidadosamente las interfaces de los médulos, los ‘métodos disponibles, la forma de comunicacion y los tpos de datos usados como parimettos 0 retomo. 1a Integridad concoptual también se muestra nocesaria durante la entrada de nuevos miembros al equipo de desarrollo ya lo largo dela evolucion y ‘mantenimlento del software. Nuevos miembros necesita de una deseripelén de 1a arguitectura porque normalmente son incorporades al equipo sin conocimiento previo del diseio. Yaa lo largo de la evolueién y mantenimiento del software, el ‘conocimiento de las regias de diseno a ser seguidas se hace necesario para que los requisites de calidad ermanezean implementados, ain durante los ‘cambios. El ejemplo que se muestra a continuacion ilustra una regla de diseno para que un software de ‘manipulacion de imagenes contin ejerciendo altaportabilidad. EJEMPLO: El software de manipullacién de imagenes Image desempeiia bien dos atributos de calidad: la estensibilldad y la portabilidad. Su extensibilidad cest4 garantizada por tener su arquitectura basada cen el uso de plugins. Con eso, este est compuesto de un niicleo de funcionalidades bisicas proporeiona medios_ para que nuevas, funcionalidades sean afiadidas en tiempo de ejecucion, Por otro lado, su portabilidad esta garantizada por tener su miicleo y_ plugins Implementades usando el lenguaje de programacién Java, permitiendo su ejecucion en. cualquier entorno que disponga de la maquina virtual Java. Como el cbdigo-fuente de Images es de dominio piblico, cualquier desarrollador puede Dajarlo, usarlo y eseribir nuevos plugins para él Inclusive, es posible usar el mecanismo Java Native Interfaz (JND para realizar Hamadas a bibliotecas fescritas en otros lenguajes. Sin embargo, si el desarrollador desea mantener el alto grado de portabilidad de ImageJ, debe respetar la regla de diseno dol software que es la de nunca realizar amadas nativas durante la implementacién de inevas funcionalidades. Existe también la integridad entre los diversos aspectos de la arquitectura en el documento 0, en otras palabras, la integridad entre las visiones de la arquitectura. Este tipo de integridad debe ser ‘mantenido para que las partes del disenio funcionen. en conjunto y que, por lo tanto, el diseiio sea responsable de la implementacién. La consistenciacentre visiones se hace necesaria por qué, a pesar de que la separacién de preocupaciones y de elementos arquitecturales faclita el disefo, es en conjunto que ellos son construides y ejecutados. Por lo tanto, si hay en el documento mis de una vision sobre los mismos elementos del sistema, es esencial que en la documentacion de esas visiones exista un mapeo entre las diferentes representaciones de esos elementos. El ejemplo que sigue ilustra la consistencia entre visiones sobre el almacenamiento en el Videoclub. En 61, podemos observar (1) los. servicios proporeionados por el sistema de almacenamiento del Videoclub por medio de la vision funcional; (2) ‘que buena parte de los servicios de almacenamiento no seran implementados desde cero, una vez que serdin obtenidos por el Sistema de Gestion de Bases de datos adoptado, por medio de la vision de desarrollo; y (3) que el sistema de almacenamiento estari ejecutande, como minimo, en tres servidores, por medio de la vision de implantacién. ‘Note que, i alguna de las visiones es ineonsistente con las otras, pueden surgir dudas sobre: (2) que servicios estén disponibles para quienes usan_ almacenamiento, (2) lo que sera implementado y 1o que sera aprovechado durante la implementacion, de la soluci6n de almacenamiento del Videoclub y, por fin, (3) que tipo de hardware sera necesario para ejecutar la solucién de almacenamiento. EJEMPLO: En Ia Decisién Arquitectural 001, descrita en ejemplos anteriores, presentamos tres ‘médulos que deben trabajar directamente con el almacenamiento: alta de Usuatios, alta de Peliculasy Transmisor de Peliculas. Sin embargo, s6lo las funciones que ellos deben implementar fueron deseritas, no como deben implementarse. Las decisiones indicadas a continuacién muestran algunos aspectos de como esas funciones deben ser implementadas. eeisién —Arquitectural 002). EI almacenamfento de las informaciones de los médulos alta de Usuarios y alta de Peliculas sera realizado usando un Sistema de Gestion de Bases de Datos Relacional (SGBDR) de modo que permita la creacién, edicién, obtencién y eliminacién de las entradas, Las informaciones guardadas en el SGBDR son los atributos de los Usuarios y Peliculas y son esencialmente textuales o meta informaciones para localizacién de archivos (fotos 0 videos). El almacenamiento de los arehivos es tratado en la [Decision Arquitectural og). Yael almacenamiento de archivos textuales que no son atributos de los Usuarios o Peliculas, por ejemplo, mensajes para usuarios © comentarios sobre pliculas es tratado en otra decision arquitectural que no es descrita aqui, Objetivo: Permitir la base de datos de los atributos de los Usuarios y Peliculas, faciitando el desarrollo. Motivacién: Los atvibutos de Usuarios y Peliculas son esencialmente _relacionales, eneajéndose perfectamente al paradigma usado para almacenamiento. Ademés de ser un paradigma bien conocido por el equipo de desarrollo, (@ecisién —Arquitectural 003). EL almacenamiento de archivos (fotos de Usuarios,ARQUITECTURA ¥ DISENO DEL SOFTWARE (SPANISH EDITION fotos de Peticulas y archivos de video) serin almacenados usando una Red de Suministro de Contenido (Content Delivery Network 6 CDN). Objetivo: Permitit la base de datos de archives, facilitando la implementacién y permitiendo rendimiento y control de carga. Motivacién: Los archives presentes en el ‘Videodlub son contenido estitico, que puede ser distribuido por una CDN y, asf, quitar provecho de replicacion, distribucién geografica y caching, sin {ener que implementar estas téenicas, ‘Ya las decisiones de Ia vision de implantacion, deben deseribir los servidores que ejecutaron los SGBDR y el servicio que se comunica con la CDN para el envio de archivos, Modelo para Andilisis 1a arquitectura es un modelo del sistema, una ‘ver que describe sus earacteristicas. Al documentar Ya arquitectura, obtenemos un modelo manipulable del sistema que tiene utilidad no sélo al arquitecto, sino también a otros interesades en el proyecto. Con ef modelo manipulable, es posible evaluar las decisiones arquitecturales registradas y validarlas fen relacion a los requisitos que el software debe satisfacer. Ademas de eso, el documento puede avin servir de herramienta que permita la verificacion de sila implementacién esti de aeuerdo con el diseno, pudiendo —prevenir —eventuales slices arquitecturales, Podemos citar tres eategorias de validacién de 1a arquitectura en relacién a los requisites: andlisis ‘basado en inspeeciones, andlisis basado en modelos¥y anilisis basado en simolaciones. Sin embargo, la posibilidad de aplicacién de una téeniea de una ‘categoria de validacion esté direetamente conectada la representacién usada en el documento de arquitectura. Andilisis basado en inspeceiones ‘Andlisis basados en inspeeeiones son ‘conducidas por bases de revision compuestas por ‘varios implicados. Ente los implieados, podemos ‘encontrar, ademés del arquitecto y de los desarrolladores, interesados menos téenieos, como el gerente de proyecto y, en algunos casos, el ‘liente, Durante el proceso de inspeceién, las partes interesadas definen os objetivos del andlisis y estudian las representaciones de la arquitectura de forma para evaluarla de aeuerdo con sus objetivo. Esta categoria de inspecei6 sirve para ‘erificar un conjunto amplio de propiedades de la arquitectura y hace uso de mntiples representaciones del disefto, tanto en lenguajes formales, como informales. Por ser un proceso esencialmente manual, es un tipo de anilisis mas caro que los otros, pero posibilita también la inspeceién en bisqueda de calidades menos formales del software, por ejemplo la escalabilidad, sostenibilidad u operabilidad. Otra ventaja de este lupo de andlisis es la de permitir el uso de representaciones informales o parciales del disenio de la arquitectura, ademés de posibilitar el andlisis ‘considerando miltiples objetives de multiples implicados. Como ejemplos de anilisis basados en inspecciones, podemos citar algunos métodos de evaluaci6n de arquitectura creados por el SoftwareARQUITECTURA ¥ DISES Engineering Institute, de la Carnegie Melon University: el Software Architecture Analysis ‘Method (SAM), el Architectural Trade-Off Analysis Method (ATAN) y el método Active Reviews for Intermediate Designs (ARID). Amilisis basado en modelos ‘Analisis basados en modelos son menos costosos que los basados en inspecciones y ruestran mayor nivel de automacin. Este tipo de anilisis utiliza herramientas que manipulan representaciones de la arqultectura con el objetive de encontrar algunas de sus propiedades. Para posibiitar Ia manipulacion, las representaciones deben ser escritas en lenguajes formales 0 semiformales como ADIs (architecture description languages 0 lenguajes de deseripcin de aquitectura), como por ejemplo, ACME, SADL y Rapide, maquinas de estado finito 0 UML. Esta categoria de inspeccién es utilizada en la Diisqueda de propledades formales de la arquitectura, como correccién sintéctica o ausencia de deadlocks y, a pesar de su alto grado de automatizacion, puede necesitar que el arquitecto gue la herramienta de inspecelén utilizada considerando los resultados parciales. Una desventaja de esta categoria es su rendimiento en el anilisis de grandes sistemas. Una vez que las representaciones de la arquitectura pueden llevar a la explosion de estados, el andlisis de todo el espacio de estados del sistema puede ser inviable. Por lo tanto, es comtin que sélo partes de la anquitectura sean analizadas ~ de preferencia las partes mas critieas.Como ejemplos de anilisis basados en modelos, podemos citar el uso del Ienguaje Wright para la verificacién de ausencia de deadlocks y el uso del lenguaje de modelaje MetaH para anzlisis de propiedades confiabilidad y seguridad (safety). Andlisis basado en simulaciones Analisis basados en simulaciones utilizan modelos ejecutables de la arquitectura para extraer caracteristicas del software o de partes de él. Asi como el anilisis basado en modelos, ese tipo de andlisis también utiliza herramientas que automatizan el proceso, haciéndolo més barato. Sin embargo, este tipo de andlisis produce resultados lnnitados a las propiedades dinmicas del software yy esti sujetas a imprecisiones de los modelos de ejecucién. Para posibilitar 1a ejecucién, as representaciones utilizadas deben ser formales, lo (que disminuye su aplicacién en la industria, pero proporeiona resultados miis precisos en relacién a calidades estructurales, comportamentales y de {nteraccién entre las partes del software, como por ejemplo calidades de rendimiento y confiabilidad. Como ejemplos de anilisis basados en simulaciones, podemos citar el uso de simulacién de eventos diseretos para anilisis de rendimiento 0 el uso de Ia herramienta XTEAM, que utiliza ADLs yy procesos de estado finito para diferentes tipos de andlisis arquitecturales. Herramienta de Rastreabilidad Por ltimo, la documentacién permite la rastreabilidad entre los requisites y los elementos de la arquitectura e implementacién que satisfacenARQUITECTURA ¥ DISERO DEL SOFTWARE (SPANISH EDITION) esos requisites. Al documentar Tas decisiones arquitecturales, registramos (1) sus objetivos, que normalmente son calidades a ser alcanzadas por el software, ¥ (2) como esos objetivos son aleanzados, por medio de la descripcién de los elementos que componen el sistema y sus relaciones y reglas de iselo que deben ser respetadas durante la implementacién. Este registro sirve de puente entre dos extremos del proceso de desarrollo: los requisitos y la implementacién, y asf permite la navegacin entre puntos relacionados, sean ellos Tequisitos, decisiones de disefto 0 partes de Ta implementactén. La rastreabilidad nos permite analizar cual es €l impacto de una decisién de diseito, tanto términos de a que requisitos afecta, como que elementos de software dicta la existencia 0, en caso de mantenimiento, que elementos son 0 deben ser afectados por cambios en los requisites o en las decisiones. El ejemplo que se incluye a continuacion muestra aspectos de rastreabilidad en Ja documentacién de la arquitectura del Videoclub. EJEMPLO: Si observiramos Ja arquitectura del Videoclub y busedramos por las decisiones responsables de facilitar el mantenimiento del sistema, eneontraremos entre ellas Ta decision de divisin del sistema en capas. Esa decision sugiere una division del sistema en capas légicas, pero tamibién influye en Ta divisin en paquetes, servicios mismo procesos. Asi, la satisfaccién del requisito de sostenibilidad esta directamente conectada a la correcta division de las partes del sistema en presentacion, légica de negocio y bases de datos. De Ia misma manera, si partiéramos de Taspartes que forman las capas de presentacién, légica cle negocio y bases de datos, observaremos que ellas estan conectadas a la division del sistema (¥ a Ta decision arquitectural) que se propone atender a requisites de sostenibilidad.