Vous êtes sur la page 1sur 10

Ivan Sommerville Ingeniera de Software DISEO ARQUITECTNICO Los sistemas grandes siempre se descomponen en subsistemas que suministran algn

conjunto relacionado de servicios. El proceso de diseo inicial para identificar estos subsistemas y establecer un masco de trabajo para el control y comunicacin de los subsistemas se llama diseo arquitectnico y lo que produce este proceso de diseo es una descripcin de la arquitectura de software. El modelo arquitectnico es a menudo el punto inicial para la especificacin de diversas partes del sistema. El proceso de diseo arquitectnico comprende el establecimiento de un marco de trabajo estructural bsico para un sistema. Esto implica identificar los componentes principales del sistema y la comunicacin entre ellos. Bass el al. (1998) plantean tres ventajas de la especificacin del diseo y la documentacin de una arquitectura de software: 1. Comunicacin entre los stakeholders La arquitectura es una presentacin de alto nivel del sistema que es utilizada como punto de discusin por un rango de stakeholders diferentes. 2. Anlisis del sistema Hacer explcita la arquitectura del sistema en una etapa inicial del desarrollo del sistema, significa que se debe llevar a cabo cierto tipo de anlisis. Las decisiones en el diseo arquitectnico tienen un efecto profundo sobre cundo el sistema puede cumplir los requerimientos crticos como el desempeo, la fiabilidad y la mantenibilidad. 3. Reutilizacin a gran escala Una arquitectura del sistema es una descripcin compacta y manejable de cmo se organiza el sistema y cmo interoperan los componentes. La arquitectura se puede transferir a lo largo de los sistemas con requerimientos similares y as poder reutilizar software a gran escala. Es posible desarrollar arquitecturas de lneas de productos donde la misma arquitectura se utilice en varios sistemas relacionados. Diversos diseadores enfocan el proceso de diseo arquitectnico de diferentes formas. El proceso utilizado depende del conocimiento de la aplicacin y de la capacidad e intuicin de los arquitectos del sistema. Sin embargo, las siguientes actividades son comunes para todos los procesos de diseo arquitectnico: 1. Estructuracin del sistema El sistema se estructura en varios subsistemas principales, donde un subsistema es una unidad de software independiente. Se identifican las comunicaciones entre los subsistemas. 2. Modelado del control Se establece un modelo general de las relaciones de control entre las partes del sistema. Esto se cubre en la seccin 10.2. 3. Descomposicin modular Cada subsistema identificado se descompone en mdulos. El arquitecto debe decidirse sobre los tipos de mdulos y sus interconexiones.

Ivan Sommerville Ingeniera de Software Por lo general, estas actividades estn entrelazadas ms que llevarse a cabo de forma secuencial. Durante cualquiera de estos procesos, se tiene que desarrollar el diseo en ms detalle para descubrir si las decisiones en el diseo arquitectnico permiten al sistema cumplir sus requerimientos. No existe una distincin clara entre subsistemas y mdulos, pero es til distinguirlos como se muestra a continuacin: 1 Un subsistema es un sistema por s mismo cuya operacin no depende de los servicios suministrados por otros subsistemas. Los subsistemas se componen de mdulos y tienen interfaces definidas que se utilizan para la comunicacin con otros subsistemas. 2. Un mdulo es por lo regular un componente del sistema que suministra uno o ms servicios a otros mdulos. Utiliza los servicios suministrados por otros mdulos. Por lo general no se considera un sistema independiente. Generalmente, los mdulos estn compuestos de varios componentes simples del sistema. La salida del proceso de diseo arquitectnico es un documento de diseo arquitectnico. ste consiste de varias representaciones grficas de los modelos del sistema junto con el texto descriptivo asociado. Describe cmo se estructura el sistema en subsistemas y cmo cada subsisterna se estructura en mdulos. Los diversos modelos grficos del sistema muestran diferentes perspectivas de la arquitectura. Los modelos arquitectnicos que se pueden desarrollar son: 1. Un modelo estructural esttico que muestra los subsistemas o componentes a desarrollar como unidades independientes. 2. Un modelo de proceso dinmico que muestra cmo se organiza el sistema en tiempo de ejecucin. Este modelo puede ser diferente al modelo esttico. 3. Un modelo de interfaz que define los servicios ofrecidos por cada subsisterna a travs de su interfaz pblica. 4. Modelos de relacin que muestran las relaciones de, por ejemplo, el flujo de datos entre los subsistemas. Varios investigadores han propuesto la utilizacin de ADLs (lenguajes de descripcin arquitectnica) para describir las arquitecturas del sistema. Bass et al. (1998) describe las caractersticas principales de estos lenguajes. Los elementos bsicos de los ADLs son componentes, y conectores que incluyen reglas y lineamientos para arquitecturas bien formadas. Sin embargo, como otros lenguajes especializados, tienen la desventaja de que slo los expertos en el lenguaje los comprenden son inaccesibles para los especialistas en el dominio y en la aplicacin. Esto hace difcil analizarlos desde una perspectiva prctica. Por lo tanto, se utilizan en un nmero reducido de aplicaciones. En su lugar, los modelos y notaciones informales como UML son ms tiles en la descripcin arquitectnica.

Ivan Sommerville Ingeniera de Software El diseo arquitectnico se basa en un modelo o estilo arquitectnico particular (Garlan y Shaw, 1993). Por lo tanto, es importante conocer estos modelos, sus aplicaciones, fortalezas y debilidades. En este captulo se describen varios modelos estructurales diferentes, modelos de control y modelos de descomposicin. Sin embargo, las arquitecturas de muchos sistemas grandes comprenden ms de un modelo. Las diversas partes del sistema se disean utilizando diferentes modelos arquitectnicos. Ms an, en algunos casos, la arquitectura del sistema es una arquitectura compuesta. sta se crea al combinar diferentes modelos arquitectnicos. Los diseadores deben encontrar el modelo ms apropiado, y modificarlo acorde a los requerimientos del problema. En la discusin de la arquitectura de un compilador donde un modelo de depsito se combina con un modelo de flujo de datos. La arquitectura del sistema afecta al desempeo, la robustez, la distributibilidad y la mantenibilidad de un sistema. Por lo tanto, el estilo particular y la estructura elegida para una aplicacin pueden depender de los requerimientos no funcionales del sistema: 1. Desempeo Si el desempeo es un requerimiento crtico, esto sugiere que la arquitectura se debe disear para localizar las operaciones crticas dentro de un nmero reducido de subsistemas con poca comunicacin, hasta donde sea posible, entre estos subsistemas. Esto significa utilizar componentes de grano grueso ms que de grano fino para reducir los componentes de comunicacin. 2. Seguridad Si la seguridad es un requerimiento crtico, esto sugiere utilizar una estructura en capas para la arquitectura con los recursos ms crticos protegidos por las capas ms internas y con un alto nivel de validacin de la seguridad aplicado a esas capas. 3. Proteccin Si la proteccin es un requerimiento crtico, esto sugiere que la arquitectura se debe disear de tal forma que las operaciones relacionadas con la proteccin se localicen en un solo subsistema o en un nmero reducido de subsistemas. Esto reduce los costos y los problemas de validacin y hace posible crear sistemas de proteccin relacionados. 4. Disponibilidad Si la disponibilidad es un requerimiento crtico, esto sugiere que la arquitectura debe disearse para incluir componentes redundantes de tal forma que sea posible reemplazar y actualizar los componentes sin detener el sistema. 5. Mantenibilidad Si la mantenibilidad es un requerimiento crtico, esto sugiere que la arquitectura del sistema se debe disear utilizando componentes autocontenidos de grano fino que puedan cambiarse con facilidad. Los productores de datos deben estar separados de los consumidores y las estructuras de datos compartidas deben evitarse. Obviamente existe un conflicto potencial entre algunas de estas arquitecturas. Por ejemplo. el desempeo se mejora utilizando componentes de grano grueso y el mantenimiento utilizando componentes de grano fino. Si ambos son requerimientos importantes del sistema, se debe encontrar una solucin mediadora. Como se discuti anteriormente, algunas veces esto se puede llevar a cabo utilizando diversos estilos arquitectnicos para las diversas partes del sistema.

Ivan Sommerville Ingeniera de Software Estructuracin del sistema La primera fase de la actividad de diseo arquitectnico se refiere, por lo general, a la descomposicin del sistema en un conjunto de subsistemas que interactan. En el nivel ms abstracto, un diseo arquitectnico se puede ver como un diagrama de bloques en el que cada cuadro del diagrama representa un subsistema. Los cuadros dentro de otros cuadros indican que el subsistema se ha descompuesto con subsistemas. Las flechas indican que los datos y/o el control se pasan de un subsistema a otro subsistema en la direccin de las flechas. Un diagrama arquitectnico de bloques presenta un panorama general de la estructura del sistema. Por lo general, ste es comprensible por los diversos ingenieros que estn involucrados en el proceso de desarrollo. La figura 5.23 es un modelo estructural de la arquitectura de un sistema robot de embalajes. Este sistema puede empacar diferentes tipos de objetos. Utiliza un sistema de visin para seleccionar los objetos de una banda transportadora, identifica el tipo de objeto y selecciona el tipo de embalaje correcto. Despus mueve los objetos de la banda transportadora para empacarlos. Los objetos empaquetados se colocan en otra banda transportadora

Figura 5.23 Diagrama de bloques de un sistema robot de control de embalajes Bass et al. (1998) sealan que los diagramas de cuadros y flechas no son representaciones arquitectnicas tiles puesto que no muestran la naturaleza de las relaciones entre los componentes del sistema ni sus propiedades visibles externas. Desde una perspectiva de un diseador de software, esto es absolutamente conecto. Sin embargo, este tipo de modelo es

Ivan Sommerville Ingeniera de Software efectivo para la comunicacin con los s:akeholders del sistema y los planeadores del proyecto. Puesto que no muestra los detalles, los gestores lo relacionan con el sistema y tienen una visin abstracta de l. Identifica los subsistemas clave a desarrollar de forma independiente de tal forma que los administradores pueden iniciar asignando personas al plan de desarrollo de esos sistemas. Los diagramas de cuadros y flechas no son la nica representacin arquitectnica que se utiliza; sin embargo, es uno de los modelos de representacin arquitectnica tiles. Se pueden desarrollar modelos ms especficos de la estructura que muestren cmo los subsistemas comparten datos, cmo estn distribuidos y cmo se conectan entre ellos. En esta seccin se discuten tres de esos modelos estndar: el modelo de depsito, el modelo cliente-servidor y el modelo de mquina abstracta. El modelo de depsito Los subsistemas que componen un sistema deben intercambiar informacin con el fin de que puedan trabajar de forma conjunta y efectiva. Existen dos formas fundamentales para lograr esto. 1. Todos los datos compartidos se ubican en una base de datos central que puede ser accedida por todos los subsistemas. Un modelo del sistema basado en una base de datos compartida se denomina algunas veces modelo de depsito. 2. Cada subsistema tiene su propia base de datos. Los datos se intercambian con otros subsistemas pasando mensajes entre ellos. La mayora de los sistemas que utilizan grandes cantidades de datos se organizan alrededor de una base de datos compartida o depsito. Por lo tanto, este modelo es adecuado para aplicaciones donde los datos sean generados por un subsistema y utilizados por otro. Ejemplos de este tipo de sistemas son los sistemas de mando y control, los sistemas de administracin de la informacin, los sistemas CAD y los conjuntos de herramientas CASE. La figura 5.24 es un ejemplo de una arquitectura para un conjunto de herramientas CASE basada en un depsito compartido. El primer depsito compartido para las herramientas CASE se desarroll probablemente a principios de los 70 por una compaa del Reino Unido, denominada ICL, como ayuda al desarrollo de su sistema operativo (McGuffin el al., 1979). Este modelo lleg a ser ampliamente conocido cuando Buxton (1980) hizo las propuestas para el entorno Stoneman como ayuda al desarrollo de sistemas escritos en Ada. Desde entonces, muchos de los conjuntos de herramientas CASE se han desarrollado alrededor de un depsito compartido.

Ivan Sommerville Ingeniera de Software Las ventajas y desventajas de un depsito compartido son: 1. Es una forma eficiente de compartir grandes cantidades de datos. No existe la necesidad de transmitir datos explcitamente de un subsistema a otro.

Figura 5.24 La arquitectura de un conjunto integrado de herramientas CASE 2. Sin embargo, los subsistemas deben estar acordes al modelo de depsito de datos. De forma inevitable, esto es un compromiso entre las necesidades especficas de cada herramienta. El desempeo se puede ver afectado por este compromiso. Puede ser difcil o imposible integrar los nuevos subsistemas si sus modelos de datos no se ajustan al esquema acordado. 3. Los subsistemas que producen datos no necesitan saber cmo son utilizados esos ciatos por otros subsistemas. 4. Sin embargo, si se genera un gran volumen de informacin, ser difcil evolucionar si se ha acordado un modelo de datos. Traducir esto a un nuevo modelo ser costoso; puede ser difcil o incluso imposible. 5. Las actividades como las de respaldo, seguridad, control de acceso y recuperacin de errores estn centralizadas. Son las responsables de administrar el depsito. Las herramientas se enfocan a su funcin principal ms que a estas cuestiones. 6. Sin embargo, varios subsistemas tienen diferentes requerimientos de polticas de seguridad, recuperacin y respaldo. El modelo de depsito fuerza a la misma poltica para todos los subsistemas. 7. El modelo de comparticin es visible a lo largo del esquema de depsito. De forma directa se integran las nuevas herramientas puesto que son compatibles con el modelo de datos acordado.

Ivan Sommerville Ingeniera de Software 8. Sin embargo, es difcil distribuir el depsito en varias mquinas. Aunque es posible distribuir un depsito centralizado lgicamente, habr problemas con la redundancia e inconsistencia de los datos. En el modelo anterior, el depsito es pasivo y el control es responsabilidad de los subsistemas que utilizan el depsito. Existe un enfoque alternativo para los sistemas de JA que utilizan un modelo de pizarrn el cual dispara subsistemas cuando estn disponibles ciertos datos. Esto es apropiado cuando la forma del depsito de datos no es tan estructurada. Las decisiones sobre qu herramienta activar se tornan cuando los datos se han analizado. Nii (1986) trata este modelo. El modelo diente-servidor El modelo arquitectnico cliente-servidor es un modelo de sistemas distribuido que muestra cmo los datos y el procesamiento se distribuyen a lo largo de varios procesadores. Los componentes principales de este modelo son: 1. Un conjunto de servidores independientes que ofrecen servicios a otros subsistemas. Ejemplos de servidores son los servidores de impresin que ofrecen estos servicios, los servidores de archivos que ofrecen los servicios de administracin de archivos y los servidores de compilacin que ofrecen los servicios de compilacin de lenguajes de programacin. 2. Un conjunto de clientes que llaman a los servicios ofrecidos por los servidores.. Por lo general, stos son subsistemas. Existen varias instancias de un programa cliente que se ejecuta de forma concurrente. 3. Una red que permite a los clientes acceder a estos servicios. En principio, sta no es realmente necesaria puesto que tanto los clientes como los servidores podran ejecutarse en una sola mquina. Sin embargo, en la prctica este modelo no se utilizara como tal. Los clientes tienen que conocer los nombres de los servidores disponibles y los servicios que suministran. Sin embargo, los servidores no requieren conocer la identidad de los clientes o cuntos clientes existen. Los clientes acceden a los servicios suministrados por un servidor a travs de llamadas a procedimientos remotos. En la figura 5.25 se muestra un ejemplo de un sistema construido utilizando un modelo cliente-servidor. ste es un sistema de hipertexto multiusuario que provee una biblioteca de pelculas y fotografas. En este sistema existen varios servidores que administran y despliegan los diferentes tipos de medios. Las pelculas se deben transmitir rpidamente y de forma sincronizada, pero a una resolucin relativamente bajas. Pueden estar comprimidas en un almacn. Sin embargo, las imgenes se deben enviar en alta resolucin. El catlogo debe estar disponible para responder a una gran variedad de peticiones

Ivan Sommerville Ingeniera de Software

Figura 5.25 La arquitectura de un sistema bibliotecario para pelculas e imgenes y proveer vnculos a los sistemas de informacin de hipertexto. El programa cliente es simplemente una interfaz de usuario integrada a esos servicios. El enfoque cliente-servidor se puede utilizar para implementar un sistema basado en depsitos, donde el depsito se suministra como un servidor del sistema. Los subsiste- mas que acceden al depsito son los clientes. Sin embargo, normalmente cada subsistema administra sus propios datos. Los servidores y clientes intercambian datos para su procesamiento. Esto conduce a problemas de desempeo citando se intercambian grandes cantidades de datos. Sin embargo, puesto que cada vez existen redes ms veloces, este problema es cada vez menos importante. La ventaja ms importante del modelo cliente-servidor es que es una arquitectura distribuida. Los sistemas en red se pueden utilizar de forma efectiva con muchos procesadores distribuidos. Es fcil agregar un nuevo servidor e integrarlo con el resto del sistema o actualizar de forma transparente los servidores sin afectar otras partes del sistema. Las arquitecturas distribuidas, incluyendo las arquitecturas cliente-servidor y las de objetos distribuidos. Sin embargo, es necesario hacer cambios a los clientes y servidores existentes pasa obtener los mayores beneficios al integrar un nuevo servidor. No existe un modelo compartido de datos y los subsistemas por lo regular organizan sus datos de diversas formas. Esto significa que los modelos de datos especficos se establecen para cada servidor que permita optimizar su desempeo. La falta de un modelo de referencia compartido para los datos implica que es difcil anticiparse a los problemas al momento de integrar los datos de un nuevo servidor. Cada servidor debe tener responsabilidad de las actividades de administracin de datos como la de respaldo y de recuperacin.

Ivan Sommerville Ingeniera de Software El modelo de mquina abstracta El modelo de mquina abstracta de una arquitectura (algunas veces denominado modelo de capas) modela la interaccin entre los subsistemas. Organiza un sistema en una serie de capas cada una de las cuales suministra un conjunto de servicios. Cada capa define una mquina abstracta cuyo lenguaje de mquina (los servicios suministrados por la capa) se utiliza para implementar el siguiente nivel de la mquina abstracta. Por ejemplo, una forma comn de implementar un lenguaje es definir un lenguaje de mquina ideal y compilarlo a cdigo para esa mquina. Un paso de traduccin adicional convierte este cdigo de mquina abstracta a un cdigo de mquina real. Un ejemplo bien conocido de este enfoque es el modelo de referencia OSI para los protocolos de red (Zimmermann, 1980) que se discute en la seccin 10.4. Otro ejemplo que ha tenido cierta influencia fue propuesto por Buxton (1980) quien sugiri un modelo de tres capas para un Entorno de Ayuda a la Programacin en Ada (APSE). La figura 5.26 tiene algo en comn con este modelo y muestra cmo se puede integrar un sistema de administracin de versiones utilizando este enfoque de mquina abstracta. El sistema de administracin de versiones comprende la administracin de versiones de objetos y suministra recursos de administracin de la configuracin general. Para soportar estos recursos de administracin de la configuracin, utiliza un sistema de administracin de objetos que provee servicios de administracin y almacenamiento de informacin para los objetos. Este sistema utiliza un sistema de bases de datos para proveer el almacenamiento bsico de datos y servicios como la administracin de transacciones, la confirmacin y recuperacin, y el control de acceso.

Figura 2.26 Modelo de mquina abstracto de un sistema de administracin de versiones La administracin de la base de datos utiliza los recursos del sistema operativo en cuestin y almacena los archivos en su implementacin.

Ivan Sommerville Ingeniera de Software El enfoque de capas permite el desarrollo incremental de sistemas. Cuando una capa se desarrolla, algunos de los servicios suministrados por esa capa estn disponibles para los usuarios. Esta arquitectura tambin es cambiable y portable. Si SU interfaz se preserva, una capa se puede reemplazar por otra capa. Cuando las interfaces de las capas cambian, slo se afecta la capa adyacente. Cuando los sistemas en capas localizan dependencias de las mquinas en las capas ms internas, se pueden implementar relativamente a bajo costo en otras computadoras. Slo es necesario reimplementar las capas internas dependientes de la mquina. Una desventaja del enfoque de capas es que estructurar a los sistemas de esta forma es difcil. Los recursos bsicos, como la administracin de archivos, que son requeridos por todas las mquinas abstractas, pueden ser suministrados por las capas internas. Por lo tanto, los servicios requeridos por el usuario necesitan tener acceso a una mquina abstracta que est a varios niveles por debajo de la capa ms externa. Esto subvierte el modelo, puesto que una capa externa ya no es dependiente de su predecesor inmediato. El desempeo tambin puede ser un problema debido a los mltiples niveles de interpretacin de rdenes que algunas veces se requieren. Si existen muchas capas, las capas exteriores se asocian a las de administracin. Para evitar estos problemas, las aplicaciones se tienen que comunicar directamente con las capas internas, ms que con la utilizacin de los recursos suministrados en la mquina abstracta.

Vous aimerez peut-être aussi