Planos arquitectonicos el modelo de 4+1 vistas de la

2,346 views
2,245 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,346
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Planos arquitectonicos el modelo de 4+1 vistas de la

  1. 1. Planos Arquitect´nicos: El Modelo de “4+1” Vistas de la o Arquitectura del Software∗ Philippe Kruchten Abstract Este art´ıculo presenta un modelo para describir la arquitectura de sistemas de software, bas´ndose a en el uso de m´ ltiples vistas concurrentes. Este uso de m´ltiples vistas permite abordar los intereses u u de los distintos “stakeholders” de la arquitectura por separado: usuarios finales, desarrolladores, inge- nieros de sistemas, administradores de proyecto, etc., y manejar los requisitos funcionales y no funcionales separadamente. Se describe cada una de las cinco vistas descritas, conjuntamente con la notaci´n para o captarla. Las vistas se dise˜ an mediante un proceso centrado en la arquitectura, motivado por escenarios n y desarrollado iterativamente.1 Introducci´n oTodos hemos visto muchos libros y art´ ıculos donde se intenta capturar todos los detalles de la arquitecturade un sistema usando un unico diagrama. Pero si miramos cuidadosamente el conjunto de cajas y flechas que ´muestran estos diagramas, resulta evidente que sus autores han trabajado duramente para intentar representarm´s de un plano que lo que realmente podr´ expresar la notaci´n. ¿Es acaso que las cajas representan a ıa oprogramas en ejecuci´n? ¿O representan partes del c´digo fuente? ¿O computadores f´ o o ısicos? ¿O acaso merasagrupaciones de funcionalidad? ¿Las flechas representan dependencias de compilaci´n? ¿O flujo de control? oGeneralmente es un poco de todo. ¿Ser´ que una arquitectura requiere un estilo unico de arquitectura? A veces la arquitectura del software a ´tiene secuelas de un dise˜o del sistema que fue muy lejos en particionar prematuramente el software, o de un n´nfasis excesivo de algunos de los aspectos del desarrollo del software: ingenier´ de los datos, o eficiencia ene ıatiempo de ejecuci´n, o estrategias de desarrollo y organizaci´n de equipos. A menudo la arquitectura tampoco o oaborda los intereses de todos sus “clientes”. Varios autores han notado este problema, incluyendo a David Garlan y Mary Shaw [7], Gregory Abowd yRobert Allen [1], y Paul Clements [4]. El modelo de 4+1 vistas fue desarrollado para remediar este problema. El modelo 4+1 describe la ar-quitectura del software usando cinco vistas concurrentes. Tal como se muestra en la Figura 1, cada vista serefiere a un conjunto de intereses de diferentes stakeholders del sistema. • La vista l´gica describe el modelo de objetos del dise˜o cuando se usa un m´todo de dise˜o orientado a o n e n objetos. Para dise˜ar una aplicaci´n muy orientada a los datos, se puede usar un enfoque alternativo n o para desarrollar alg´n otro tipo de vista l´gica, tal como diagramas de entidad-relaci´n. u o o • La vista de procesos describe los aspectos de concurrencia y sincronizaci´n del dise˜o. o n • La vista f´ ısica describe el mapeo del software en el hardware y refleja los aspectos de distribuci´n. o • La vista de desarrollo describe la organizaci´n est´tica del software en su ambiente de desarrollo. o a Los dise˜adores de software pueden organizar la descripci´n de sus decisiones de arquitectura en estas n ocuatro vistas, y luego ilustrarlas con un conjunto reducido de casos de uso o escenarios, los cuales constituyenla quinta vista. La arqutitectura evoluciona parcialmente a partir de estos escenarios. ∗ Art´ ıculo publicado en IEEE Software 12(6), Noviembre 1995. Traducido por Mar´ Cecilia Bastarrica en Marzo 2006 ıa 1
  2. 2. En Rational, aplicamos la f´rmula de Dwayne Perry y Alexander Wolf [9] de manera independiente para ocada vista:Arquitectura del software = {Elementos, Formas, Motivaci´n/Restricciones} o Para cada vista definimos un conjunto de elementos (componentes, contenedores y conectores), captamosla forma y los patrones con que trabajan, y captamos la justificaci´n y las restricciones, relacionando la oarquitectura con algunos de sus requisitos. Cada vista se describe en lo que llamamos “diagrama” (blueprint) que usa su notaci´n particular. Los oarquitectos tambi´n pueden usar estilos de arquitectura para cada vista, y por lo tanto hacer que coexistan edistintos estilos en un mismo sistema. El modelo de 4+1 vistas es bastante gen´rico: se puede usar otra notaci´n y herramientas que las aqu´ e o ıdescritas, as´ como tambi´n otros m´todos de dise˜o, especialment para las descomposiciones l´gica y de ı e e n oprocesos.2 El Modelo de 4+1 VistasLa arquitectura del software se trata de abstracciones, de descomposici´n y composici´n, de estilos y est´tica. o o eTrambi´n tiene relaci´n con el dise˜o y la implementaci´n de la estructura de alto nivel del software. e o n o Los dise˜adores construyen la arquitectura usando varios elementos arquitect´nicos elegidos apropiada- n omente. Estos elementos satisfacen la mayor parte de los requisitos de funcionalidad y performance del sis-tema, as´ como tambi´n otros requisitos no funcionales tales como confiabilidad, escalabilidad, portabilidad y ı edisponibilidad del sistema. Figure 1: Modelo de “4+1” vistas3 La Arquitectura L´gica o La arquitectura l´gica apoya principalmente los requisitos funcionales –lo que el sistema debe brindar en ot´rminos de servicios a sus usuarios. El sistema se descompone en una serie de abstracciones clave, tomadas e(principalmente) del dominio del problema en la forma de objetos o clases de objetos. Aqu´ se aplican los ıprincipios de abstracci´n, encapsulamiento y herencia. Esta descomposici´n no s´lo se hace para potenciar el o o oan´lisis funcional, sino tambi´n sirve para identificar mecanismos y elementos de dise˜o comunes a diversas a e npartes del sistema. Usamos el enfoque de Booch/Rational para representar la arquitectura l´gica, mediante diagramas de oclases y templates de clases [3]. Un diagrama de clases muestra un conjunto de clases y sus relaciones l´gicas: o 2
  3. 3. asociaciones, uso, composici´n, herencia y similares. Grupos de clases relacionadas pueden agruparse en ocategor´ de clases. Los templates de clases se centran en cada clase individual; enfatizan las operaciones ıasprincipales de la clase, e identifican las principales caracter´ ısticas del objeto. Si es necesario definir el com-portamiento interno de un objeto, esto ser realiza con un diagrama de transici´n de estados o diagrama de oestados. Los mecanismos y servicios comunes se definen como utilities de la clase.Notaci´n. La notaci´n para la vista l´gica se deriva de la notaci´n de Booch [3]. Esta se simplifica consider- o o o oablemente de tal modo de tener en cuenta solamente los items relevantes para la arquitectura. En particular,los numerosos adornos disponibles son bastante in´tiles a este nivel de dise˜o. Usamos Rational Rose para u napoyar el dise˜o l´gico de la arquitectura. n o Figure 2: Notaci´n para la vista l´gica o oEstilo. El estilo usado para la vista l´gica es el estilo de orientaci´n a objetos. La principal gui´ para el o o ıadise˜o de la vista l´gica es el intentar mantener un modelo unico y coherente de objetos a lo largo de todo el n o ´sistema, para evitar la especializaci´n prematura de las clases y mecanismos particulares o de un procesador. oEjemplos. La Figura 3 muestra las principales clases que forman parte de la arquitectura de una muestrade PBX que desarrollamos en Alcatel. Un PBX establece comunicaciones entre terminales. Un terminal puede ser un tel´fono, una l´ e ınea troncal(i.e. una l´ınea a la oficina central), una l´ ınea de uni´n (i.e. de un PBX privado a una l´ o ınea PBX), o unacaracter´ıstica de una l´ ınea telef´nica. o Diferentes tarjetas de interfaz de l´ınea soportan distintas l´ıneas. El objeto controlador decodifica e inyectatodas las se˜ales en la tarjeta de interfaz de la l´ n ınea, traduce las se˜ales espec´ n ıficas desde y hacia un conjuntopeque˜o y uniforme de eventos: comenzar, deterner, d´ n ıgito, etc. El controlador tiene tambi´n todas las erestricciones hard de tiempo real. Esta clase tiene muchas subclases a las que proporciona distintos tipos deinterfaces. El objeto terminal mantiene el estado de una terminal, y negocia los servicios para esa l´ ınea. Por ejemplo,usa los servicios del plan de numeraci´n para interpretar el discado. o El objeto conversaci´n representa un conjunto de terminales que participan de una conversaci´n. Usa los o oservicios de traducci´n (directorio, mapeo de direcciones l´gicas a f´ o o ısicas, rutas), y servicios de conexi´n para oestablecer una ruta de voz entre los terminales. Para sistemas mucho m´s grandes, que contienen varias docentas de clases de relevancia para la arquitec- atura, la Figura 3b muestra un diagrama de clases de alto nivel para un sistema de control de tr´fico a´reo a edesarrollado por Hughes Aircraft of Canada que contiene 8 categor´ de clases (i.e. grupos de clases). ıas 3
  4. 4. Figure 3: (a) Diagrama l´gico del T´lic PBX; (b) Diagrama de un sistema de control de tr´fico a´reo o e a e4 La Vista de ProcesosLa arquitectura de procesos toma en cuenta algunos requisitos no funcionales tales como la performance y ladisponibilidad. Se enfoca en asuntos de concurrencia y distribuci´n, integridad del sistema, de tolerancia a ofallas. La vista de procesos tambi´n especifica en cu´l hilo de control se ejecuta efectivamente una operaci´n e a ode una clase identificada en la vista l´gica. o La arquitectura de procesos se describe en varios niveles de abstracci´n, donde cada nivel se refiere a odistintos intereses. El nivel m´s alto la arquitectura de procesos puede verse como un conjunto de redes l´gicas a ode programas comunicantes (llamados “procesos”) ejecut´ndose en forma independiente, y distribuidos a lo alargo de un conjunto de recursos de hardware conectados mediante un bus, una LAN o WAN. M´ltiples redes ul´gicas pueden usarse para apoyar la separaci´n de la operaci´n del sistema en l´ o o o ınea del sistema fuera de ´ ınea,as´ como tambi´n para apoyar la coexistencia de versiones de software de simulaci´n o de prueba. ı e o Un proceso es una agrupaci´n de tareas que forman una unidad ejecutable. Los procesos representan el nivel oal que la arquitectura de procesos puede ser controlada t´cticamente (i.e., comenzar, recuperar, reconfigurar, y adetener). Adem´s, los procesos pueden replicarse para aumentar la distribuci´n de la carga de procesamiento, a oo para mejorar la disponibilidad.Partici´n. El software se particiona en un conjunto de tareas independientes: hilo de control separado que opuede planificarse para su ejecuci´n independiente en un nodo de procesamiento. o Podemos entonces distinguir: • tareas mayores son elementos arquitect´nicos que pueden ser manejados en forma un´ o ıvoca. Se comu- nican a trav´s de un conjunto bien definido de mecanismos de comunicaci´n inter-tarea: servicios de e o comunicaci´n sincr´nicos y asincr´nicos basados en mensajes, llamados a procedimientos remotos, di- o o o fusi´n de eventos, etc. Las tareas mayores no debieran hacer suposiciones acerca de su localizaci´n con o o otras tareas dentro de un mismo proceso o un mismo nodo de procesamiento. • tareas menores son tareas adicionales introducidas localmente por motivos de implementaci´n tales como o actividades c´ ıclicas, almacenamiento en un buffer, time-out, etc.). Pueden implementarse en Ada por ejemplo, o como hilos de control liviano (threads). Pueden comunicarse mediante rendezvous o memoria compartida. El flujo de mensajes y la carga de procesos puede estimarse en base al diagrama de procesos. Tambi´n es eposible implmentar una vista de procesos “vac´ıa”, con cargas dummy para los procesos y medir entonces superformance en el sistema objetivo [5]. 4
  5. 5. Notaci´n. La notaci´n que usamos para la vista de procesos se expande de la notaci´n originalmente o o opropues por Booch para las tareas de Ada yse centra solamente en los elementos arquitect´nicamente relevantes o(Figura 4). Figure 4: Notaci´n para el diagrama de procesos o Hemos usado el producto Universal Network Architecture Services (UNAS) de TRW para dise˜ar e imple- nmentar un conjunto de procesos y tareas (con sus respectivas redundancias) como redes de procesos. UNAScontiene una herramienta –el Software Architects Lifecycle Environment (SALE)– el cual apoya dicha no-taci´n. SALE permite describir gr´ficamente la arquitectura de procesos, incluyendo la especificaci´n de las o a oposibles rutas de comunicaci´n inter-tareas del cual se puede generar autom´ticamente el correspondiente o ac´digo fuente Ada o C++. La generaci´n autom´tica de c´digo permite hacer cambios f´cilmente a la vista o o a o ade procesos.Estilo. Varios estilos podr´ servir para la vista de procesos. Por ejemplo, tomando la taxonom´ de Garlan ıan ıay Shaw [7] tenemos: tubos y filtros, o cliente/servidor, con variantes de varios clientes y un unico servidor ´o m´ltiples clientes y m´ltiples servidores. Para sistemas m´s complejos, podemos usar un estilo similar a u u ala forma de agrupaci´n de procesos del sistema ISIS descrito por Kenneth Birman con otra notaci´n y otras o oherramientas [2].Ejemplo. La Figura 5 muestra una vista de procesos parcial para el sistema PBX. Todas las terminalesson adminsitradas por un unico proceso terminal, el cual es manejado a trav´s de mensajes en sus colas de ´ einput. Los objetos controladores se ejecutan en alguna de las tres tareas que componen el proceso controlador:una tarea c´ ıclica de baja tasa que chequea todas las terminales inactivas (200ms), pone toda terminal que setorna activa en la lista de b´squeda del la tarea c´ u ıclica de alta tasa (10ms), la cual detecta cualquier cambiode estado significativo, y lo pasa a la tarea controladora principal la cual interpreta el cambio y lo comunicamediante un mensaje con el terminal correspondiente. Aqu´ el mensaje pasa dentro del controlador a trav´s ı ede memoria compartida.5 Vista de DesarrolloLa vista de desarrollo se centra en la organizaci´n real de los m´dulos de software en el ambiente de desarrollo o odel software. El software se empaqueta en partes peque˜as –bibliotecas de programas o subsistemas– que npueden ser desarrollados por uno o un grupo peque˜o de desarrolladores. Los subsistemas se organizan en nuna jerarqu´ de capas, cada una de las cuales brinda una interfaz estrecha y bien definida hacia las capas ıasuperiores. 5
  6. 6. Figure 5: Diagrama (parcial) de procesos para T´lic PBX e La vista de desarrolla tiene en cuenta los requisitos internos relativos a la facilidad de desarrollo, admin-istraci´n del software, reutilizaci´n y elementos comunes, y restricciones impuestas por las herramientas o el o olenguaje de programaci´n que se use. La vista de desarrollo apoya la asignaci´n de requisitos y trabajo al o oequipo de desarrollo, y apoya la evaluaci´n de costos, la planificaci´n, el monitoreo de progreso del proyecto, o oy tambi´n como base para analizar reuso, portabilidad y seguridad. Es la base para establecer una l´ e ınea deproductos. La vista de desarrollo de un sistema se representa en diagramas de m´dulos o subsistemas que muestran las orelaciones exporta e importa. La arquitectura de desarrollo completa s´lo puede describirse completamente ocuando todos los elementos del softare han sido identificados. Sin embargo, es posible listar las reglas que rigenla arquitectura de desarrollo – partici´n, agrupamiento, visibilidad– antes de conocer todos los elementos. oNotaci´n. Tal como se muestra en la Figura 6, usamos una variante de la notaci´n de Booch limit´ndonos o o aa aquellos items relevantes para la arquitectura. Figure 6: Notaci´n para el diagrama de desarrollo o El ambiente de desarrollo Apex de Rational apoya la definici´n e implementaci´n de la arquitectura de o o 6
  7. 7. desarrollo, la estrategia de capas antes descrita, y el cumplimiento de las reglas de dise˜o. Se puede dibujar nla arquitectura de desarrollo en Rational Rose a nivel de m´dulos y subsistemas, en ingenier´ hacia adelante o ıay reversa a partir de c´digo fuente Ada y C++. oEstilo para la vista de desarrollo. Recomendamos adptar el estilo de capas para la vista de desarrollo,definido en 4 a 6 niveles de subsistemas. Cada capa tiene una responsabilidad bien definida. La regla dedise˜o es que un subsistema en una cierta capa s´lo puede depender de subsistemas que est´n o bien en la n o emisma capa o en capas inferiores, de modo de minimizar el desarrollo de complejas redes de dependenciasentre m´dulos y permitir estrategias de desarrollo capa por capa. oEjemplo de Arquitectura de Desarrollo. La Figura 7 representa la organizaci´n del desarrollo en cinco ocapas de la l´ ınea de productos de sistemas de control de tr´fico a´reo desarrollados por Hughes Aircraft de a eCanad´ [8]. Esta es la arquitectura de desarrollo correspondiente a la arquitectura l´gica que se muestra en a ola Figura 3b. Figure 7: Las 5 capas del Sistema de Tr´fico A´reo de Hughes (HATS) a e Las capas 1 y 2 constituyen la infraestructura distribuida independiente del dominio que es com´n a toda ula l´ ınea de productos y la independiza de las variaciones de la plataforma de hardware, sistema operativo, oproductos comerciales tales como administradores de bases de datos. La capa 3 agrega a esta infraestrucuraun framework ATC para forma una arquitectura de software dependiente del dominio. Usando este framework,en la capa 4 se construye una paleta de funcionalidad. La capa 5 es dependiente del cliente y del producto, ycontiene la mayor parte de las interfaces con el usuario y con sistemas externos. Tantos como 72 subsistemasforman parte de la capa 5, cada uno de los cuales contiene entre 10 y 50 m´dulos, y puede representarse en odiagramas adicionales.6 Arquitectura F´ ısicaMapeando el software al hardware La arquitectura f´ısica toma en cuenta primeramente los requisitos no funcionales del sistema tales comola disponibilidad, confiabilidad (tolerancia a fallas), performance (throughput), y escalabilidad. El softwareejecuta sobre una red de computadores o nodos de procesamiento (o tan solo nodos). Los variados elementosidentificados –redes, procesos, tareas y objetos– requieren ser mapeados sobre los variados nodos. Esperamosque diferentes configuraciones puedan usarse: algunas para desarrollo y pruebas, otras para emplazar elsistema en varios sitios para distintos usuarios. Por lo tanto, el mapeo del software en los nodos requiere seraltamente flexible y tener un impacto m´ ınimo sobre el c´digo fuente en s´ o ı. 7
  8. 8. Notaci´n para la arquitectura f´ o ısica. Los diagramas f´ ısicos pueden tornarse muy confusos en grandessistemas, y por lo tanto toman diversas formas, con o sin el mapeo de la vista de procesos. Figure 8: Notaci´n para el diagrama f´ o ısico UNAS de TRW nos brinda los medios de datos para mapear la arquitectura de procesos en la arquitecturaf´ ısica permitiendo realizar una gran cantidad de clases de cambios en el mapeo sin modificar el c´digo fuente. o Figure 9: Diagrama f´ ısico de PABXEjemplo de diagrama f´ ısico. La Figura 9 muestra una configuraci´n de hardware posible para un gran oPABX, mientras que las Figuras 10 y 11 muestran el mapero de la arquitectura de procesos en dos arquitecturasf´ ısicas diferentes, que corresponden a un PABX peque˜o y uno grande, respectivamente. C, F y K son tres ntipos de computadores de diferente capacidad que soportan tres tipos diferentes de ejecutables.7 EscenariosTodas las partes juntas 8
  9. 9. Figure 10: Una peque˜a arquitectura f´ n ısica de PABX con emplazamiento de procesosFigure 11: Diagrama f´ ısico para un PABX m´s grande incluyendo emplazamiento de procesos a 9
  10. 10. Los elementos de las cuatro vistas trabajan conjuntamente en forma natural mediante el uso de un conjuntopeque˜o de escenarios relevantes –instancias de casos de uso m´s generales– para los cuales describimos sus n ascripts correspondientes (secuencias de interacciones entre objetos y entre procesos) tal como lo describenRubin y Goldberg [10]. Los escenarios son de alguna manera una abstracci´n de los requisitos m´s importantes. o aSu dise˜o se expresa mediante el uso de diagramas de escenarios y diagramas de interacci´n de objetos [3]. n o Esta vista es redundante con las otras (y por lo tanto “+1”), pero sirve a dos prop´sitos principales: o • como una gu´ para descubrir elementos arquitect´nicos durante el dise˜o de arquitectura tal como lo ıa o n describiremos m´s adelante a • como un rol de validaci´n e ilustraci´n despu´s de completar el dise˜o de arquitectura, en el papel y o o e n como punto de partido de las pruebas de un prototipo de la arquitectura.Notaci´n para escenarios. La notaci´n es muy similar a la vista l´gica para los componentes(ver Figura 2), o o opero usa los conectores de la vista de procesos para la interacci´n entre objetos (ver Figura 4). N´tese que o olas instancias de objetos se denotan con l´ ıneas s´lidas. Para el diagrama l´gico, capturamos y administramos o olos diagramas de escenarios de objetos usando Rational Rose.Ejemplo de escenario. La Figura 12 muestra un fragmento del PABX peque˜o. El script correspondiente npodr´ ser: ıa 1. el controlador del tel´fono de Joe detecta y valida la transici´n desde colgado a descolgado y env´ un e o ıa mensaje para despertar la objeto terminal correspondiente. 2. el terminal reserva recursos y le indica al controlador que emita cierto tono de discado. 3. el controlador recibe los d´ ıgitos y los transmite hacia el terminal. 4. el terminal usa el plan de numeraci´n para analizar el flujo de d´ o ıgitos. 5. cuando se ingresa una secuencia v´lida de d´ a ıgitos, el terminal abre una conversaci´n. o Figure 12: Embri´n de un escenario de una llamada local–fase de selecci´n o o8 Correspondencia entre las VistasLas distintas vistas no son completamente ortogonales o independientes. Los elementos de una vista est´n aconectados a los elementos de las otras vistas siguiendo ciertas reglas y heur´ ısticas de dise˜o. n 10
  11. 11. De la vista l´gica a la vista de procesos. o Identificamos varias caracter´ ısticas importantes de las clasesde la arquitectura l´gica: o • Autonom´ ¿Los objetos son activos, pasivos o protegidos? ıa: – un objeto activo toma la iniciativa de invocar las operaciones de otros objetos o sus propias op- eraciones, y tiene el control completo sobre la invocaci´n de sus operaciones por parte de otros o objetos. – un objeto pasivo nunca invoca espont´neamente ninguna operaci´n y no tiene ning´n control sobre a o u la invocaci´n de sus operaciones por parte de otros objetos. o – un objeto protegido nunca invoca espont´neamente ninguna operacio´n pero ejecuta cierto arbitraje a o sobre la invocaci´n de sus operaciones. o • Persistencia: ¿Los objetos son permanentes o temporales? ¿Qu´ hacen ante la falla de un proceso o un e procesador? • Subordinaci´n: ¿La existencia o persistencia de un objeto depende de otro objeto? o • Distribuci´n: ¿Est´n el estado y las operaciones de un objeto accesibles desde varios nodos de la arqui- o a tectura f´ ısica, ydesde varios procesos de la arquitectura de procesos? En la vista l´gica de la arquitectura consideramos que cada objeto es activo y potencialmente “concur- orente”, i.e. teniendo comportamiento en paralelo con otros objetos, y no prestamos m´s atenci´n al grado a opreciso de concurrencia que requerimos para alcanzar este efecto. Por lo tanto, la arquitectura l´gica tiene en ocuenta s´lo el aspecto funcional de los requisitos. o Sin embargo, cuanto definimos la arquitectura de procesos, implementar cada objeto con su propio threadde control (e.g., su propio proceso Unix o tarea Ada) no es muy pr´ctico en el estado actual de la tecnolog´ a ıadebido al gran overhead que esto impone. M´s a´n, si los objetos son concurrentes, deber´ haber alguna a u aforma de arbitraje para invocar sus operaciones. Por otra parte, ser requiere m´ltiples threads de control por varias razones: u • para reaccionar r´pidamente a ciertas clases de estmulos externos, incluyendo eventos relativos al tiempo a ´ • para sacar partido de las m´ltiples CPUs en un nodo, o los m´ltiples nodos en un sistema operativo u u • para aumentar la utilizaci´n de la CPU, asignando la CPUa otras actividades mientras alg´n thread de o u control est´ suspendido esperando que otra actividad finalice (e.g., acceso a cierto dispositivo externo, a o acceso a otro objeto activo) • para priorizar actividades (y potencialmente mejorar la respuesta) • para apoyar la escalabilidad del sistema (con procesos adicionales que compartan la carga) • para separar intereses entre las diferentes ´reas del software a • para alcanzar una mayor disponibilidad del sistema (con procesos de backup) Usamos dos estrategias concurrentemente para determinar la cantidad correcta de concurrencia y definirel conjunto de procesos que se necesitan. Considerando el conjunto de posibles arquitecturas f´ ısicas, podemosproceder o bien:Inside-out Comenzando a partir de la arquitectura l´gica: definir las tareas agentes que multiplexan un unico o ´ thread de control entre m´ltiples objetos activos de una clase; los objetos cuya persistencia o vida est´ u a subordinada a un objeto activo tambi´n se ejecutan en ese mismo agente; muchas clases que requieren ser e ejecutadas con mutua exclusi´n, o que requieren s´lo un peque˜o procesamiento comparten el mismo o o n agente. Este clustering prosigue hasta que se reducen los procesos hasta un n´mero razonablemente u peque˜o que a´n permite distribuci´n y uso de los recursos f´ n u o ısicos. 11
  12. 12. Outside-in Comenzando con la arquitectura f´ ısica: identificar los est´ ımulos externos (requerimientos) al sistema, definir los procesos cliente para manejar los est´ımulos y procesos servidores que s´lo brindan o servicios y que no los inician; usar la integridad de los datos y las restricciones de serializaci´n del o problema para definir el conjunto correcto de servidores, y asignar objetos a los agentes cliente y servidor; identificar cu´les objetos deben ser distribuidos. a El resultado es el mapeo de las clases (y sus objetos) en un conjunto de tareas y procesos de la arquitecturade procesos. T´ıpicamente existe una tarea agente para una clase activa con algunas variaciones: varios agentespara una clase dada para aumentar el throughput, o varias clases mapeadas en un mismo agente porque susopraciones se no se invocan frecuentemente o para garantizar su ejecuci´n secuencial. o N´tese que esto no es un proceso lineal y determin´ o ıstico que nos lleva a una arquitectura de procesoso´ptima; requiere una serie de iteraciones para lograr un compromiso aceptable. Hay numerosas otras formasde hacerlo, tal como lo establecen por ejemplo Birman et al. [2] o Witt et al. [11]. El m´todo preciso a usar een la contrucci´n del mapeo est´ fuera del alcance de este art´ o a ıculo, pero podemos ilustrarlo con un peque˜onejemplo. La Figura 13 muestra c´mo un peque˜o conjunto de clases de un sistema de control de tr´fico a´reo o n a ehipot´tico puede mapearse en procesos. e Figure 13: Mapeo de la vista l´gica a la vista de procesos o La clase vuelo se mapea a un conjunto de agentes de vuelo: existen muchos vuelos a procesar, una altatasa de est´ ımulos externos, el tiempo de respuesta es cr´ıtico, la carga debe distribuirse entre m´ltiples CPUs. uM´s a´n, los aspectos de persistencia y distribui´n del procesamiento a´reo se difieren a un servidor de vuelos, a u o eel cual est´ duplicado por motivos de disponibilidad. a Un perfil de vuelo o una liquidaci´n siempre est´n subordinadas a un vuelo, y a pesar que son clases o acomplejas, ellas comparten los mismos procesos que la clase vuelo. Los vuelos se distribuyen en variosprocesadores, de forma notable para el despliegue y las interfaces externas. Una clase sectorizaci´n, que establece una partici´n del espacio a´reo para la asignaci´n de jurisdicci´n de o o e o ocontroladores de vuelos, debido a sus restricciones de integridad puede ser manejada solamente por un agenteunico, pero puede compartir el proceso servidor con el vuelo: las modificaciones son infrecuentes.´ Localizaci´n y espacio a´reo y otra informaci´n aeron´utica est´tica son objetos protegidos, compartidos o e o a aentre muchas otras clases, y raramente modificados; se mapean en su propio servidor, y se distribuye a otrosprocesos.De la l´gica al desarrollo. Una clase se implementa generalmente como un m´dulo, por ejemplo un tipo de o ola parte visible de un paquete Ada. Las clases grandes se descomponen en m´ltiples paquetes. Colecciones de u 12
  13. 13. clases ´ ıntimamente relacionadas –categor´ de clases– se agrupan en subsistemas. Deben tambi´n considerarse ıas eotras restricciones para la definici´n de subsistemas tales como la organizaci´n del equipo de desarrollo, el o otama˜o esperado del c´digo (t´ n o ıpicamente 5K a 20K SLOC por subsistema), grado de reuso y comonalidadesperado, principio de distribuci´n en capas (visibilidad), pol´ o ıticas de liberaci´n, y administraci´n de la o oconfiguraci´n. Por lo tanto, generalmente terminamos con una vista que no tiene necesariamente una relaci´n o ouno a uno con la vista l´gica. o Las vistas l´gica y de desarrollo son muy cercanas, aunque se refieren a distintos asuntos. Hemos encontrado oque cuanto mayor es el proyecto, mayor es tambi´n la distancia entre estas dos vistas. Similarmente para las evistas de procesos y f´ ısica: cuanto mayor el proyecto, mayor es la distancia entre estas vistas. Por ejemplo,si comparamos las figuras 3b y 7, no existe una correspondencia uno a uno de las categor´ de clases y las ıascapas. Si tomamos la categor´ “Interfaces externas–Gateway”, su implementaci´n se distribuye a lo largo ıa ode varias capas: los protocolos de comunicaci´n est´n en los subsistemas dentro o debajo de la capa 1, los o amecanismos generales de gateways est´n en los subsistemas de la capa 2, y los gateways espec´ a ıficos realesest´n en los subsistemas de la capa 5. aDe procesos a f´ ısico. Los procesos y grupos de procesos se mapean sobre el hardware f´ ısico disponibleen varias configuraciones para testing o distribuci´n. Birman describe algunos esquemas eleaborados para orealizar este mapeo dentro del proyecto Isis [2]. Los escenarios se relacionan esencialmente con la vista l´gica, en t´rminos de cu´les clases se usan y con o e ala vista de procesos cuando las interacciones entre objetos involucran m´s de un thread de control. a9 Confeccionando el ModeloNo toda arquitectura de software requiere las “4+1” vistas completas. Las vistas que no son utiles pueden ´omitirse de la descripci´n de arquitectura, tales como la vista f´ o ısica si hay un unico procesador, y la vista de ´procesos si existe un solo proceso o programa. Para sistemas muy peque˜os, es posible que las vistas l´gica n oy de desarrollo sean tan similares que no requieran descripciones independientes. Los escenarios son utiles en ´todas las circunstancias.9.1 Proceso IterativoWitt et al. indican 4 fases para el dise˜o de arquitectura: bosquejo, organizaci´n, especificaci´n y opti- n o omizaci´n, subdivididos en 12 pasos [11]. Indican que puede ser necesario alg´n tipo de backtrack. Creemos o uque este enfoque es muy “lineal” para proyectos ambiciosos y novedosos. Al final de las cuatro fases se tienemuy poco conocimiento para validar la arquitectura. Abogamos por un desarrollo m´s iterativo, donde la aarquitectura se prototipa, se prueba, se mide, se analiza y se refina en sucesivas iteraciones. Adem´s de apermitir mitigar los riesgos asociados a la arquitectura, este desarrollo tiene otros beneficios asociados parael proyecto: construcci´n en equipo, entrenamiento, familiarizaci´n con la arquitectura, adquisici´nn de her- o o oramientas, ejecuci´n de procedimientos y herramientas, etc. (Hablamos de un prototipo evolutivo, que crece olentamente hasta convertirse en el sistema, y no de un prototipo desechable, exploratorio.) Este enfoqueiterativo tambi´n permite refinar los requisitos, madurarlos y comprenderlos m´s profundamente. e aUn enfoque dirigido por escenarios La funcionalidad m´s cr´ a ıtica del sistema se captura en forma deescenarios (o casos de uso). Cr´ ıticos se refiere a: funciones que son las m´s importantes, la raz´n de existir del a osistema, o que tienen la mayor frecuencia de uso, o que presentan cierto riesgo t´cnico que debe ser mitigado. eComienzo: • Se elige un peque˜o n´mero de escenarios para cierta iteraci´n basado en el riesgo y la criticidad. Los n u o escenarios pueden sintetizarse para abstraer una serie de requisitos de usuario. • Se bosqueja una arquitectura. Los escenarios se describen para identificar las abstracciones mayores (clases, mecanismos, procesos, subsistemas) como lo indican Rubin y Goldberg [10] –descomponi´ndolos e en secuencias de pares (objeto, operaci´n). o 13
  14. 14. • Los elementos de la arquitectura descubieros se ponen en las 4 vistas de arquitectura: l´gica, de procesos, o de desarrollo y f´ ısica. • Se implementa la arquitectura, se prueba, se mide, y se analiza para detectar errores o potenciales mejoras. • Se recogen las lecciones aprendidas.Loop: La siguiente iteraci´n puede entonces comenzar mediante: o • reestudiando los riesgos, • extendiendo la paleta de escenarios a considerar, • seleccionando una serie de escenarios que permitir´n mitigar el riesgo o cubrir una mayor parte de la a arquitectura. Entonces: • Intentar describir los escenarios de la arquitectura preliminar, • descubrir elementos de arquitectura adicionales, o algunos cambios que es necesario aplicar a la arqui- tectura para dar cabida a estos escenarios, • actualizar las 4 vistas de arquitectura, • revisar los escenarios existentes bas´ndose en los cambios, a • actualizar la implementaci´n (el prototipo de la arquitectura) para dar apoyo al nuevo conjunto exten- o dido de escenarios, • probar y medir bajo sobrecarga en lo posible en el ambiente de ejecuci´n objetivo, o • las 5 vistas se revisan para detectar potenciales simplificaciones, reutilizaci´n, y comonalidades, o • actualizar las gu´ de dise˜o y justificaci´n del mismo, ıas n o • recoger las lecciones aprendidas.End loop El prototipo inicial de la arquitectura evoluciona hasta convertirse en el sistema real. Con suerte, luegode 2 o 3 iteraciones, la arquitectura se vuelve estable: no se encuentran nuevas abstracciones mayores, nisubsistemas, ni procesos, ni interfaces. El resto de la historia est´ dentro de la t´nica del dise˜o, donde de a o nhecho, el desarrollo puede continuar usando m´todos y procesos muy similares. e La duraci´n de estas iteraciones var´ considerablemente: con el tama˜o del proyecto, con el n´mero de o ıa n upersonas involucradas y su familiaridad con el dominio y el m´todo, y con el grado de novedad del sistema con erespecto a la organizaci´n de desarrollo. Por lo tanto la duraci´n de una iteraci´n puede ser de 2 a 3 semanas o o opara un peque˜o proyecto (e.g. 10KSLOC), o entre 6 y 9 meses para un gran sistema de comando y control n(e.g. 700KSLOC).10 Documentaci´n de la Arquitectura oLa documentaci´n producida durante el dise˜o de la arquitectura se captura en dos documentos: o n • un Documento de Arquitectura del Software, cuya organizaci´n sigue las “4+1” vistas (ver la figura 14 o por un punteo t´ ıpico) • un documento de Gu´ del Dise˜o del Software, que captura (entre otras cosas) las decisiones de dise˜o ıas n n m´s importantes que deben respetarse para mantener la integridad de la arquitectura del sistema. a 14
  15. 15. Pagina de titulo Historia de cambios Tabla de contenidos Lista de figuras 1. Alcance 2. Referencias 3. Arquitectura del software 4. Objetivos y restricciones de la arquitectura 5. Arquitectura logica 6. Arquitectura de procesos 7. Arquitectura de desarrollo 8. Arquitectura fisica 9. Escenarios 10. Tama˜ o y performance n 11. Cualidades Apendices A. Siglas y abreviaturas B. Definiciones C. Principios de dise˜ o n Figure 14: Punteo de un documento de Arquitectura de Software11 Conclusi´n oEl modelo de “4+1” vistas ha sido usado con´xito en varios proyectos grandes con o sin ajustes locales en esu terminolog´ [3]. Realmente permiti´ a los distintos stakeholders encontrar lo que quer´ acerca de la ıa o ıanarquitectura del software. Los ingenieros de sistemas se enfocaron en la vista f´ ısica, y luego en la vista deprocesos. Los usuarios finales, los clientes, y los especialistas en datos en la vista l´gica. Los administradores ode proyectos, las personas de configuraci´n del software en la vista de desarrollo. o Se han propuesto y discutido otra serie de vistas, tanto dentro de Rational como en otras partes, como porejemplo Meszaros (BNR), Hofmeister, Nord y Soni (Siemens), Emery y Hilliard (Mitre) [6], pero en generalhemos visto que estas otras vistas propuestas pueden reducirse a una de las cuatro vistas aqu´ propuestas. ıPor ejemplo una vista de costo&planificaci´n puede verse como una vista de desarrollo, una vista de datos opuede verse como una vista l´gica, una vista de ejecuci´n puede ser una combinaci´n de las vistas f´ o o o ısica y deprocesos. Vista L´gica o Proceso Desarrollo F´ısica Escenarios Componentes Clase Tarea M´dulo, subsistema o Nodo Paso, script Conectores asociaci´n, o rendez-vous, dependencia de medio de herencia, mensaje, broadcast, compilaci´n, sentencia o comunicaci´n, o contenci´n o RPC, etc. “with”, “include” LAN, WAN, bus Contenedores Categor´ de clase ıa Proceso Subsistema Subsistema Web (biblioteca) f´ ısico Stakeholders Usuario Dise˜ ador, n Desarrollador, Dise˜ ador n Usuario, final integrador administrador de sistema desarrollador Intereses Funcionalidad Performance, Organizaci´n, o Escalabilidad, Comprensibilidad disponibilidad, reuso, portabilidad, performance, tolerancia a fallas, l´ ıneas de productos disponibilidad integridad Herramientas Rose UNAS/SALE DADS Apex, SoDA UNAS, Rose Openview, DADS Table 1: Resumen del modelo de “4+1” vistasAgradecimientosEl modelo de “4+1” vistas debe su existencia a varios colegas de Rational, de Hughes Aircraft de Canad´, de aAlcatel, y de otras partes. En particular quisiera agradecer por sus contribuciones a Ch. Thompson, A. Bell,M. Devlin, G. Booch, W. Royce, J. Marasco, R. Reitman, V. Ohnjec, y E. Schonberg. 15
  16. 16. References [1] Gregory D. Abowd, Robert Allen, and David Garlan. Using Style to Understand Descriptions of Software Archi- tecture. In Proceedings of the First ACM SIGSOFT Symposium on Foundations of Software Engineering, pages 9–20, Los Angeles, California, USA, 1993. [2] Kenneth P. Birman and Robbert Van Renesse. Reliable Distributed Computing with the Isis Toolkit. Wiley-IEEE Computer Society Press, April 1994. [3] Grady Booch. Object-Oriented Analysis and Design with Applications. Benjamin-Cummings Pub. Co., Redwood City, California, 2nd edition, 1993. [4] Paul Clements. From Domain Model to Architectures. In A. Abd-Allah et al., editor, Focused Workshop on Software Architecture, pages 404–420, 1994. [5] A. R. Filarey, W. E. Royce, R. Rao, P. Schmutz, and L. Doan-Minh. Software First: Applying Ada Megapro- gramming Technology to Target Platform Selection Trades. In TRI-Ada, pages 90–101, 1993. [6] David Garlan. Proceedings of the first internal workshop on architectures for software systems. Technical Report CMU-CS-TR-95-151, Carnegie Mellon University, Pittsburgh, 1995. [7] David Garlan and Mary Shaw. An Introduction to Software Architecture. Advances in Software Engineering and Knowledge Engineering, 1, 1993. World Scientific Publishing Co. [8] Phillipe Kruchten and Ch. Thompson. An object-oriented, distributed architecture for large scale ada systems. In Proceedings of the TRI-Ada’94 Conference, pages 262–271, Baltimore, November 1994. ACM. [9] Dewayne E. Perry and Alexander L. Wolf. Foundations for the study of software architecture. SIGSOFT Software Engineering Notes, 17(4):40–52, 1992. ACM Press.[10] Kenneth S. Rubin and Adele Goldberg. Object behavior analysis. Communications of the ACM, 35(9):48–62, 1992.[11] Bernard I. Witt, Terry Baker, and Everett W. Merrit. Software Architecture and Design–Principles, Models, and Methods. Van Nostrand Reinhold, New York, 1994. 16

×