la arquitectura de 4+1 vistas_jocelyn

7/31/2019 La Arquitectura de 4+1 Vistas_Jocelyn

1/12


2/12

Muchos autores intentan capturar todos los detalles de la arquitectura de un sistema enun nico diagrama. Esto implica que quienes necesiten interpretarlo tengan que recurrir auna enorme cuota de esfuerzo para lograr comprender todos los planos y aspectos quelos diseadores y desarrolladores quieren exhibir en dicho diagrama. Mucho ms grandeser el esfuerzo si quien lo interpreta es completamente ajeno al proyecto y/o equipo dedesarrollo.

Pero si miramos cuidadosamente el conjunto de cajas y flechas que muestran estosdiagramas, resulta evidente que sus autores han trabajado duramente para intentarrepresentar ms de un plano que lo que realmente podra expresar la notacin. Es acasoque las cajas representan programas en ejecucin? O representan partes del cdigofuente? O computadores fsicos? O acaso meras agrupaciones de funcionalidad? Lasflechas representan dependencias de compilacin? O flujo de control? Generalmente esun poco de todo.

Ser que una arquitectura requiere un estilo nico de arquitectura? A veces laarquitectura del software tiene secuelas de un diseo del sistema que fue muy lejos enparticionar prematuramente el software, o de un nfasis excesivo de algunos de losaspectos del desarrollo del software: ingeniera de los datos, o eficiencia en tiempo deejecucin, o estrategias de desarrollo y organizacin de equipos. A menudo laarquitectura tampoco aborda los intereses de todos sus clientes.

Para remediar este problema se pens en un modelo que pudiera disgregar las partesfundamentales de la aplicacin para lograr una mayor comprensin y asimilacin de lainformacin que se muestra, a la vez de aplicar un mayor nivel de detalle para cada unode los aspectos importantes que conforman la arquitectura de un sistema: Modelo de 4+1

Vistas.

Cada una de estas partes disgregadas llamadas se requiere a un conjunto deintereses de diferentes del sistema:

La vista Lgica o de Diseo: describe el modelo de objetos del diseo cuando se usa unmtodo de diseo orientado a objetos. Si el diseo es muy orientado a los datos puedenutilizarse alternativas de vista lgica como ser diagramas de Entidad-Interrelacin, entreotros.

La vista de Componentes o de Desarrollo: describe la organizacin esttica delsoftware en su ambiente de desarrollo.

La vista de Despliegue o de Arquitectura: describe el mapeo del software en elhardware y refleja los aspectos de distribucin.

La vista de Procesos: describe los aspectos de concurrencia y sincronizacin del diseo.


3/12

La arquitectura del software se trata de abstracciones, de descomposicin y composicin,de estilos y esttica. Tambin tiene relacin con el diseo y la implementacin de laestructura de alto nivel del software. Los diseadores construyen la arquitectura usando

varios elementos arquitectnicos elegidos apropiadamente.

Estos elementos satisfacen la mayor parte de los requisitos de funcionalidad yperformance del sistema, as como tambin otros requisitos no funcionales tales comoconfiabilidad, escalabilidad, portabilidad y disponibilidad del sistema.

Diferentes modelos de 4+1 vistas


4/12

La arquitectura lgica apoya principalmente los requisitos funcionales lo que el sistemadebe brindar en trminos de servicios a sus usuarios. El sistema se descompone en unaserie de abstracciones clave, tomadas (principalmente) del dominio del problema en laforma de objetos o clases de objetos. Aqu se aplican los principios de abstraccin,

encapsulamiento y herencia. Esta descomposicin no slo se hace para potenciar elanlisis funcional, sino tambin sirve para identificar mecanismos y elementos de diseocomunes a diversas partes del sistema.

Usamos el enfoque de Booch/Rational para representar la arquitectura lgica, mediantediagramas de clases y templates de clases. Un diagrama de clases muestra un conjuntode clases y sus relaciones lgicas: asociaciones, uso, composicin, herencia y similares.Grupos de clases relacionadas pueden agruparse en categoras de clases. Los templatesde clases se centran en cada clase individual; enfatizan las operaciones principales de laclase, e identifican las principales caractersticas del objeto. Si es necesario definir elcomportamiento interno de un objeto, esto ser realiza con un diagrama de transicin deestados o diagrama de estados. Los mecanismos y servicios comunes se definen como

utilities de la clase.

Notacin. La notacin para la vista lgica se deriva de la notacin de Booch. Esta sesimplifica considerablemente de tal modo de tener en cuenta solamente los temsrelevantes para la arquitectura. En particular, los numerosos adornos disponibles sonbastante intiles a este nivel de diseo. Usamos Rational Rose para apoyar el diseolgico de la arquitectura.

Estilo. El estilo usado para la vista lgica es el estilo de orientacin a objetos. La principalgua para el diseo de la vista lgica es el intentar mantener un modelo nico y coherentede objetos a lo largo de todo el sistema, para evitar la especializacin prematura de lasclases y mecanismos particulares o de un procesador.


5/12

La vista de desarrollo se centra en la organizacin real de los mdulos de software en elambiente de desarrollo del software. El software se empaqueta en partes pequeas -bibliotecas de programas o subsistemas que pueden ser desarrollados por uno o ungrupo pequeo de desarrolladores. Los subsistemas se organizan en una jerarqua de

capas, cada una de las cuales brinda una interfaz estrecha y bien definida hacia las capassuperiores.

La vista de desarrolla tiene en cuenta los requisitos internos relativos a la facilidad dedesarrollo, administracin del software, reutilizacin y elementos comunes, y restriccionesimpuestas por las herramientas o el lenguaje de programacin que se use. La vista dedesarrollo apoya la asignacin de requisitos y trabajo al equipo de desarrollo, y apoya laevaluacin de costos, la planificacin, el monitoreo de progreso del proyecto, y tambincomo base para analizar reuso, portabilidad y seguridad. Es la base para establecer unalnea de productos.

La vista de desarrollo de un sistema se representa en diagramas de mdulos o

subsistemas que muestran las relaciones exporta e importa. La arquitectura de desarrollocompleta solo puede describirse completamente cuando todos los elementos del softwarehan sido identificados. Sin embargo, es posible listar las reglas que rigen la arquitecturade desarrollo particin, agrupamiento, visibilidad antes de conocer todos loselementos.

Notacin. Tal como se muestra en la Figura, usamos una variante de la notacin deBooch limitndonos a aquellos tems relevantes para la arquitectura.

El ambiente de desarrollo Apex de Rational apoya la definicin e implementacin de laarquitectura de desarrollo, la estrategia de capas antes descrita, y el cumplimiento de lasreglas de diseo. Se puede dibujar la arquitectura de desarrollo en Rational Rose a nivelde mdulos y subsistemas, en ingeniera hacia adelante y reversa a partir de cdigofuente Ada y C++.


6/12

Estilo. Para la vista de desarrollo. Recomendamos adaptar el estilo de capas para la vistade desarrollo, definido en 4 a 6 niveles de subsistemas. Cada capa tiene unaresponsabilidad bien definida. La regla de diseo es que un subsistema en una ciertacapa slo puede depender de subsistemas que estn o bien en la misma capa o en capasinferiores, de modo de minimizar el desarrollo de complejas redes de dependencias entremdulos y permitir estrategias de desarrollo capa por capa.

Ejemplo de Arquitectura de Desarrollo. La Figura siguiente representa la organizacin deldesarrollo en cinco capas de la lnea de productos de sistemas de control de trfico areodesarrollados por Hughes Aircraft de Canad. Esta es la arquitectura de desarrollocorrespondiente a la arquitectura lgica que se muestra en la figura.

Las capas 1 y 2 constituyen la infraestructura distribuida independiente del dominio que escomn a toda la lnea de productos y la independiza de las variaciones de la plataformade hardware, sistema operativo, o productos comerciales tales como administradores debases de datos. La capa 3 agrega a esta infraestructura un framework ATC para formauna arquitectura de software dependiente del dominio. Usando este framework, en la capa4 se construye una paleta de funcionalidad. La capa 5 es dependiente del cliente y delproducto, y contiene la mayor parte de las interfaces con el usuario y con sistemas

externos. Tantos como 72 subsistemas forman parte de la capa 5, cada uno de los cualescontienen entre 10 y 50 mdulos, y puede representarse en diagramas adicionales.


7/12

Mapeando el software al hardware.

La arquitectura fsica toma en cuenta primeramente los requisitos no funcionales delsistema tales como la disponibilidad, confiabilidad (tolerancia a fallas), performance

(throughput), y escalabilidad. El software ejecuta sobre una red de computadores o nodosde procesamiento (o tan solo nodos). Los variados elementos identificados redes,procesos, tareas y objetos requieren ser mapeados sobre los variados nodos.Esperamos que diferentes configuraciones puedan usarse: algunas para desarrollo ypruebas, otras para emplazar el sistema en varios sitios para distintos usuarios. Por lotanto, el mapeo del software en los nodos requiere ser altamente flexible y tener unimpacto mnimo sobre el cdigo fuente en s.

Notacin para la arquitectura fsica. Los diagramas fsicos pueden tornarse muy confusosen grandes sistemas, y por lo tanto toman diversas formas, con o sin el mapeo de la vistade procesos.

Notacin del Diagrama de Despliegue ode Arquitectura


8/12

UNAS de TRW nos brindan los medios de datos para mapear la arquitectura de procesosen la arquitectura fsica permitiendo realizar una gran cantidad de clases de cambios en elmapeo sin modificar el cdigo fuente.

Ejemplo de diagrama de Despliegue o de Arquitectura. La Figura muestra unaconfiguracin de hardware posible para un gran PABX, mientras que las siguientes figurasse muestran el mapeo de la arquitectura de procesos en dos arquitecturas fsicasdiferentes, que corresponden a un PABX pequeo y uno grande, respectivamente. C, F yK son tres tipos de computadores de diferente capacidad que soportan tres tiposdiferentes de ejecutables.

Diagrama de Arquitectura


9/12

La arquitectura de procesos toma en cuenta algunos requisitos no funcionales tales comola performance y la disponibilidad. Se enfoca en asuntos de concurrencia y distribucin,integridad del sistema, de tolerancia a fallas. La vista de procesos tambin especifica encual hilo de control se ejecuta efectivamente una operacin de una clase identificada en la

vista lgica. La arquitectura de procesos se describe en varios niveles de abstraccin,donde cada nivel se refiere a distintos intereses. El nivel ms alto la arquitectura deprocesos puede verse como un conjunto de redes lgicas de programas comunicantes(llamados procesos) ejecutndose en forma independiente, y distribuidos a lo largo deun conjunto de recursos de hardware conectados mediante un bus, una LAN o WAN.Mltiples redes lgicas pueden usarse para apoyar la separacin de la operacin delsistema en lnea del sistema fuera de lnea, as como tambin para apoyar la coexistenciade versiones de software de simulacin o de prueba.

Un proceso es una agrupacin de tareas que forman una unidad ejecutable. Los procesosrepresentan el nivel al que la arquitectura de procesos puede ser controlada tcticamente(i.e., comenzar, recuperar, reconfigurar, y detener). Adems, los procesos pueden

replicarse para aumentar la distribucin de la carga de procesamiento, o para mejorar ladisponibilidad.

Particin. El software se particiona en un conjunto de tareas independientes: hilo decontrol separado que puede planificarse para su ejecucin independiente en un nodo deprocesamiento.

Podemos entonces distinguir:

Tareas mayores son elementos arquitectnicos que pueden ser manejados en forma uninvoca. Se comunican a travs de un conjunto bien definido de mecanismos decomunicacin inter-tarea: servicios de comunicacin sincrnicos y asincrnicos basadosen mensajes, llamados a procedimientos remotos, difusin de eventos, etc. Las tareas

mayores no debieran hacer suposiciones acerca de su localizacin con otras tareasdentro de un mismo proceso o un mismo nodo de procesamiento.

Tareas menores son tareas adicionales introducidas localmente por motivos deimplementacin tales como actividades cclicas, 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 pueden estimarse en base al diagrama deprocesos. Tambin es posible implementar una vista de procesos vaca, con cargasdummy para los procesos y medir entonces su performance en el sistema objetivo.


10/12

Notacin. La notacin que usamos para la vista de procesos se expande de la notacinoriginalmente propuesta por Booch para las tareas de Ada y se centra solamente en loselementos arquitectnicamente relevantes en la Figura.

Hemos usado el producto Universal Network Architecture Services (UNAS) de TRW paradisear e implementar un conjunto de procesos y tareas (con sus respectivasredundancias) como redes de procesos. UNAS contiene una herramienta el SoftwareArchitects Lifecycle Environment (SALE) el cual apoya dicha notacin. SALE permitedescribir grficamente la arquitectura de procesos, incluyendo la especificacin de las

posibles rutas de comunicacin inter-tareas del cual se puede generar automticamente elcorrespondiente cdigo fuente Ada o C++. La generacin automtica de cdigo permitehacer cambios fcilmente a la vista de procesos.

Estilo. Varios estilos podran servir para la vista de procesos. Por ejemplo, tomando lataxonoma de Garlan y Shaw [7] tenemos: tubos y filtros, o cliente/servidor, con variantesde varios clientes y un nico servidor o mltiples clientes y mltiples servidores. Parasistemas ms complejos, podemos usar un estilo similar a la forma de agrupacin deprocesos del sistema ISIS descrito por Kenneth Birman con otra notacin y otrasherramientas.

Ejemplo. La siguiente Figura muestra una vista de procesos parcial para el sistema PBX.

Todas las terminales son administradas por un nico proceso terminal, el cual esmanejado a travs de mensajes en sus colas de input.

Notacin para el diagrama de procesos


11/12

Los objetos controladores se ejecutan en alguna de las tres tareas que componen elproceso controlador: una tarea cclica de baja tasa que chequea todas las terminalesinactivas (200ms), pone toda terminal que se torna activa en la lista de bsqueda de latarea cclica de alta tasa (10ms), la cual detecta cualquier cambio de 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 travs de memoria compartida.

Diagrama (parcial) de procesos para Tlic PBX


12/12

BIBLIOGRAFIAS.

http://tecnicas-grupo2.googlecode.com/svn-

history/r259/trunk/informe_arquitectura/arquitectura.pdf

http://www.oscargallardo.com/wp-content/uploads/2011/04/Modelo4_1Krutchen.pdf
http://tecnicas-grupo2.googlecode.com/svn-history/r259/trunk/informe_arquitectura/arquitectura.pdfhttp://tecnicas-grupo2.googlecode.com/svn-history/r259/trunk/informe_arquitectura/arquitectura.pdfhttp://tecnicas-grupo2.googlecode.com/svn-history/r259/trunk/informe_arquitectura/arquitectura.pdfhttp://www.oscargallardo.com/wp-content/uploads/2011/04/Modelo4_1Krutchen.pdfhttp://www.oscargallardo.com/wp-content/uploads/2011/04/Modelo4_1Krutchen.pdfhttp://www.oscargallardo.com/wp-content/uploads/2011/04/Modelo4_1Krutchen.pdfhttp://tecnicas-grupo2.googlecode.com/svn-history/r259/trunk/informe_arquitectura/arquitectura.pdfhttp://tecnicas-grupo2.googlecode.com/svn-history/r259/trunk/informe_arquitectura/arquitectura.pdf

la arquitectura de 4+1 vistas_jocelyn

Documents