You are on page 1of 10

Ivan Sommerville Ingeniería de Software DISEÑO ARQUITECTÓNICO Los sistemas grandes siempre se descomponen en subsistemas que suministran algún

conjunto relacionado de servicios. El proceso de diseño inicial para identificar estos subsistemas y establecer un masco de trabajo para el control y comunicación de los subsistemas se llama diseño arquitectónico y lo que produce este proceso de diseño es una descripción de la arquitectura de software. El modelo arquitectónico es a menudo el punto inicial para la especificación de diversas partes del sistema. El proceso de diseño arquitectónico comprende el establecimiento de un marco de trabajo estructural básico para un sistema. Esto implica identificar los componentes principales del sistema y la comunicación entre ellos. Bass el al. (1998) plantean tres ventajas de la especificación del diseño y la documentación de una arquitectura de software: 1. Comunicación entre los stakeholders La arquitectura es una presentación de alto nivel del sistema que es utilizada como punto de discusión por un rango de stakeholders diferentes. 2. Análisis del sistema Hacer explícita la arquitectura del sistema en una etapa inicial del desarrollo del sistema, significa que se debe llevar a cabo cierto tipo de análisis. Las decisiones en el diseño arquitectónico tienen un efecto profundo sobre cuándo el sistema puede cumplir los requerimientos críticos como el desempeño, la fiabilidad y la mantenibilidad. 3. Reutilización a gran escala Una arquitectura del sistema es una descripción compacta y manejable de cómo se organiza el sistema y cómo 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 líneas de productos donde la misma arquitectura se utilice en varios sistemas relacionados. Diversos diseñadores enfocan el proceso de diseño arquitectónico de diferentes formas. El proceso utilizado depende del conocimiento de la aplicación y de la capacidad e intuición de los arquitectos del sistema. Sin embargo, las siguientes actividades son comunes para todos los procesos de diseño arquitectónico: 1. Estructuración 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 sección 10.2. 3. Descomposición modular Cada subsistema identificado se descompone en módulos. El arquitecto debe decidirse sobre los tipos de módulos y sus interconexiones.

el flujo de datos entre los subsistemas. Los subsistemas se componen de módulos y tienen interfaces definidas que se utilizan para la comunicación con otros subsistemas. Utiliza los servicios suministrados por otros módulos.Ivan Sommerville Ingeniería de Software Por lo general. pero es útil distinguirlos como se muestra a continuación: 1 Un subsistema es un sistema por sí mismo cuya operación no depende de los servicios suministrados por otros subsistemas. 4. No existe una distinción clara entre subsistemas y módulos. se utilizan en un número reducido de aplicaciones. Varios investigadores han propuesto la utilización de ADLs (lenguajes de descripción arquitectónica) para describir las arquitecturas del sistema. Los elementos básicos de los ADLs son componentes. 2. Este modelo puede ser diferente al modelo estático. los modelos y notaciones informales como UML son más útiles en la descripción arquitectónica. Describe cómo se estructura el sistema en subsistemas y cómo cada subsisterna se estructura en módulos. Esto hace difícil analizarlos desde una perspectiva práctica. Un modelo de interfaz que define los servicios ofrecidos por cada subsisterna a través de su interfaz pública. En su lugar. Modelos de relación que muestran las relaciones de. Éste consiste de varias representaciones gráficas de los modelos del sistema junto con el texto descriptivo asociado. Sin embargo. y conectores que incluyen reglas y lineamientos para arquitecturas bien formadas. Un modelo estructural estático que muestra los subsistemas o componentes a desarrollar como unidades independientes. como otros lenguajes especializados. Los modelos arquitectónicos que se pueden desarrollar son: 1. Un modelo de proceso dinámico que muestra cómo se organiza el sistema en tiempo de ejecución. 2. 3. . por ejemplo. los módulos están compuestos de varios componentes simples del sistema. se tiene que desarrollar el diseño en más detalle para descubrir si las decisiones en el diseño arquitectónico permiten al sistema cumplir sus requerimientos. (1998) describe las características principales de estos lenguajes. Por lo tanto. Por lo general no se considera un sistema independiente. estas actividades están entrelazadas más que llevarse a cabo de forma secuencial. Los diversos modelos gráficos del sistema muestran diferentes perspectivas de la arquitectura. La salida del proceso de diseño arquitectónico es un documento de diseño arquitectónico. Un módulo es por lo regular un componente del sistema que suministra uno o más servicios a otros módulos. Bass et al. Durante cualquiera de estos procesos. Generalmente. tienen la desventaja de que sólo los expertos en el lenguaje los comprenden —son inaccesibles para los especialistas en el dominio y en la aplicación.

Los productores de datos deben estar separados de los consumidores y las estructuras de datos compartidas deben evitarse. La arquitectura del sistema afecta al desempeño. Desempeño Si el desempeño es un requerimiento crítico. y modificarlo acorde a los requerimientos del problema. Ésta se crea al combinar diferentes modelos arquitectónicos.Ivan Sommerville Ingeniería de Software El diseño arquitectónico se basa en un modelo o estilo arquitectónico particular (Garlan y Shaw. Si ambos son requerimientos importantes del sistema. En la discusión de la arquitectura de un compilador donde un modelo de depósito se combina con un modelo de flujo de datos. Por ejemplo. Sin embargo. Protección Si la protección es un requerimiento crítico. se debe encontrar una solución mediadora. 3. las arquitecturas de muchos sistemas grandes comprenden más de un modelo. el estilo particular y la estructura elegida para una aplicación pueden depender de los requerimientos no funcionales del sistema: 1. Mantenibilidad Si la mantenibilidad es un requerimiento crítico. en algunos casos. entre estos subsistemas. 4. la robustez. . modelos de control y modelos de descomposición. 1993). Seguridad Si la seguridad es un requerimiento crítico. esto sugiere que la arquitectura se debe diseñar de tal forma que las operaciones relacionadas con la protección se localicen en un solo subsistema o en un número reducido de subsistemas. 5. Por lo tanto. Las diversas partes del sistema se diseñan utilizando diferentes modelos arquitectónicos. Esto reduce los costos y los problemas de validación y hace posible crear sistemas de protección relacionados. fortalezas y debilidades. hasta donde sea posible. Como se discutió anteriormente. esto sugiere que la arquitectura del sistema se debe diseñar utilizando componentes autocontenidos de grano fino que puedan cambiarse con facilidad. Los diseñadores deben encontrar el modelo más apropiado. Por lo tanto. es importante conocer estos modelos. esto sugiere utilizar una estructura en capas para la arquitectura con los recursos más críticos protegidos por las capas más internas y con un alto nivel de validación de la seguridad aplicado a esas capas. Disponibilidad Si la disponibilidad es un requerimiento crítico. En este capítulo se describen varios modelos estructurales diferentes. algunas veces esto se puede llevar a cabo utilizando diversos estilos arquitectónicos para las diversas partes del sistema. el desempeño se mejora utilizando componentes de grano grueso y el mantenimiento utilizando componentes de grano fino. sus aplicaciones. Obviamente existe un conflicto potencial entre algunas de estas arquitecturas. esto sugiere que la arquitectura se debe diseñar para localizar las operaciones críticas dentro de un número reducido de subsistemas con poca comunicación. la distributibilidad y la mantenibilidad de un sistema. esto sugiere que la arquitectura debe diseñarse para incluir componentes redundantes de tal forma que sea posible reemplazar y actualizar los componentes sin detener el sistema. Esto significa utilizar componentes de grano grueso más que de grano fino para reducir los componentes de comunicación. la arquitectura del sistema es una arquitectura compuesta. 2. Más aún.

por lo general. identifica el tipo de objeto y selecciona el tipo de embalaje correcto. Por lo general. un diseño arquitectónico se puede ver como un diagrama de bloques en el que cada cuadro del diagrama representa un subsistema. Este sistema puede empacar diferentes tipos de objetos. a la descomposición del sistema en un conjunto de subsistemas que interactúan. Las flechas indican que los datos y/o el control se pasan de un subsistema a otro subsistema en la dirección de las flechas.Ivan Sommerville Ingeniería de Software Estructuración del sistema La primera fase de la actividad de diseño arquitectónico se refiere. Después mueve los objetos de la banda transportadora para empacarlos. Los cuadros dentro de otros cuadros indican que el subsistema se ha descompuesto con subsistemas. Utiliza un sistema de visión para seleccionar los objetos de una banda transportadora. éste es comprensible por los diversos ingenieros que están involucrados en el proceso de desarrollo. En el nivel más abstracto.23 es un modelo estructural de la arquitectura de un sistema robot de embalajes. Un diagrama arquitectónico de bloques presenta un panorama general de la estructura del sistema. Los objetos empaquetados se colocan en otra banda transportadora Figura 5. Sin embargo. Desde una perspectiva de un diseñador de software. este tipo de modelo es . esto es absolutamente conecto. (1998) señalan que los diagramas de cuadros y flechas no son representaciones arquitectónicas útiles puesto que no muestran la naturaleza de las relaciones entre los componentes del sistema ni sus propiedades visibles externas.23 Diagrama de bloques de un sistema robot de control de embalajes Bass et al. La figura 5.

los sistemas CAD y los conjuntos de herramientas CASE. es uno de los modelos de representación arquitectónica útiles.Ivan Sommerville Ingeniería de Software efectivo para la comunicación con los s:akeholders del sistema y los planeadores del proyecto.. Cada subsistema tiene su propia base de datos. El modelo de depósito Los subsistemas que componen un sistema deben intercambiar información con el fin de que puedan trabajar de forma conjunta y efectiva. Un modelo del sistema basado en una base de datos compartida se denomina algunas veces modelo de depósito. sin embargo. Todos los datos compartidos se ubican en una base de datos central que puede ser accedida por todos los subsistemas. El primer depósito compartido para las herramientas CASE se desarrolló probablemente a principios de los 70 por una compañía del Reino Unido. denominada ICL. Se pueden desarrollar modelos más específicos de la estructura que muestren cómo los subsistemas comparten datos. 2. 1. 1979). Desde entonces. 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. Existen dos formas fundamentales para lograr esto. .24 es un ejemplo de una arquitectura para un conjunto de herramientas CASE basada en un depósito compartido. Puesto que no muestra los detalles. este modelo es adecuado para aplicaciones donde los datos sean generados por un subsistema y utilizados por otro. cómo están distribuidos y cómo se conectan entre ellos. 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. Ejemplos de este tipo de sistemas son los sistemas de mando y control. La mayoría de los sistemas que utilizan grandes cantidades de datos se organizan alrededor de una base de datos compartida o depósito. como ayuda al desarrollo de su sistema operativo (McGuffin el al. Por lo tanto. Los datos se intercambian con otros subsistemas pasando mensajes entre ellos. En esta sección se discuten tres de esos modelos estándar: el modelo de depósito. muchos de los conjuntos de herramientas CASE se han desarrollado alrededor de un depósito compartido. los gestores lo relacionan con el sistema y tienen una visión abstracta de él. los sistemas de administración de la información. el modelo cliente-servidor y el modelo de máquina abstracta. La figura 5. Los diagramas de cuadros y flechas no son la única representación arquitectónica que se utiliza.

varios subsistemas tienen diferentes requerimientos de políticas de seguridad. 7. recuperación y respaldo. esto es un compromiso entre las necesidades específicas de cada herramienta. Traducir esto a un nuevo modelo será costoso. El modelo de compartición es visible a lo largo del esquema de depósito. Sin embargo. Sin embargo. puede ser difícil o incluso imposible. De forma directa se integran las nuevas herramientas puesto que son compatibles con el modelo de datos acordado. El modelo de depósito fuerza a la misma política para todos los subsistemas. Sin embargo. Son las responsables de administrar el depósito. control de acceso y recuperación de errores están centralizadas. seguridad. De forma inevitable. Figura 5. Las actividades como las de respaldo. . si se genera un gran volumen de información. 3. No existe la necesidad de transmitir datos explícitamente de un subsistema a otro. 5. será difícil evolucionar si se ha acordado un modelo de datos.Ivan Sommerville Ingeniería de Software Las ventajas y desventajas de un depósito compartido son: 1. Las herramientas se enfocan a su función principal más que a estas cuestiones.24 La arquitectura de un conjunto integrado de herramientas CASE 2. Puede ser difícil o imposible integrar los nuevos subsistemas si sus modelos de datos no se ajustan al esquema acordado. Los subsistemas que producen datos no necesitan saber cómo son utilizados esos ciatos por otros subsistemas. los subsistemas deben estar acordes al modelo de depósito de datos. El desempeño se puede ver afectado por este compromiso. 6. Es una forma eficiente de compartir grandes cantidades de datos. 4.

en la práctica este modelo no se utilizaría como tal. En el modelo anterior. Una red que permite a los clientes acceder a estos servicios. pero a una resolución relativamente bajas. las imágenes se deben enviar en alta resolución. Sin embargo.Ivan Sommerville Ingeniería de Software 8. éstos son subsistemas. Los clientes tienen que conocer los nombres de los servidores disponibles y los servicios que suministran. En este sistema existen varios servidores que administran y despliegan los diferentes tipos de medios. el depósito es pasivo y el control es responsabilidad de los subsistemas que utilizan el depósito. Las películas se deben transmitir rápidamente y de forma sincronizada. Esto es apropiado cuando la forma del depósito de datos no es tan estructurada. Sin embargo.. es difícil distribuir el depósito en varias máquinas. Nii (1986) trata este modelo. Aunque es posible distribuir un depósito centralizado lógicamente. Existe un enfoque alternativo para los sistemas de JA que utilizan un modelo de pizarrón el cual dispara subsistemas cuando están disponibles ciertos datos. Los clientes acceden a los servicios suministrados por un servidor a través de llamadas a procedimientos remotos. Pueden estar comprimidas en un almacén. 3. Éste es un sistema de hipertexto multiusuario que provee una biblioteca de películas y fotografías. ésta no es realmente necesaria puesto que tanto los clientes como los servidores podrían ejecutarse en una sola máquina. Un conjunto de clientes que llaman a los servicios ofrecidos por los servidores. El catálogo debe estar disponible para responder a una gran variedad de peticiones . El modelo diente-servidor El modelo arquitectónico cliente-servidor es un modelo de sistemas distribuido que muestra cómo los datos y el procesamiento se distribuyen a lo largo de varios procesadores. Existen varias instancias de un programa cliente que se ejecuta de forma concurrente. Sin embargo. Por lo general. Sin embargo. habrá problemas con la redundancia e inconsistencia de los datos. Ejemplos de servidores son los servidores de impresión que ofrecen estos servicios. En principio. Los componentes principales de este modelo son: 1. En la figura 5. los servidores no requieren conocer la identidad de los clientes o cuántos clientes existen. 2.25 se muestra un ejemplo de un sistema construido utilizando un modelo cliente-servidor. Las decisiones sobre qué herramienta activar se tornan cuando los datos se han analizado. Un conjunto de servidores independientes que ofrecen servicios a otros subsistemas. los servidores de archivos que ofrecen los servicios de administración de archivos y los servidores de compilación que ofrecen los servicios de compilación de lenguajes de programación.

El enfoque cliente-servidor se puede utilizar para implementar un sistema basado en depósitos. Sin embargo.Ivan Sommerville Ingeniería de Software Figura 5. El programa cliente es simplemente una interfaz de usuario integrada a esos servicios. Las arquitecturas distribuidas. . Los subsiste.25 La arquitectura de un sistema bibliotecario para películas e imágenes y proveer vínculos a los sistemas de información de hipertexto. puesto que cada vez existen redes más veloces. La ventaja más importante del modelo cliente-servidor es que es una arquitectura distribuida. donde el depósito se suministra como un servidor del sistema. No existe un modelo compartido de datos y los subsistemas por lo regular organizan sus datos de diversas formas. Esto conduce a problemas de desempeño citando se intercambian grandes cantidades de datos. Esto significa que los modelos de datos específicos se establecen para cada servidor que permita optimizar su desempeño. incluyendo las arquitecturas cliente-servidor y las de objetos distribuidos. este problema es cada vez menos importante. Cada servidor debe tener responsabilidad de las actividades de administración de datos como la de respaldo y de recuperación. Los sistemas en red se pueden utilizar de forma efectiva con muchos procesadores distribuidos. Los servidores y clientes intercambian datos para su procesamiento. Sin embargo.mas que acceden al depósito son los clientes. Sin embargo. La falta de un modelo de referencia compartido para los datos implica que es difícil anticiparse a los problemas al momento de integrar los datos de un nuevo servidor. normalmente cada subsistema administra sus propios datos. Es fácil agregar un nuevo servidor e integrarlo con el resto del sistema o actualizar de forma transparente los servidores sin afectar otras partes del sistema. es necesario hacer cambios a los clientes y servidores existentes pasa obtener los mayores beneficios al integrar un nuevo servidor.

Para soportar estos recursos de administración de la configuración. El sistema de administración de versiones comprende la administración de versiones de objetos y suministra recursos de administración de la configuración general. Por ejemplo.26 tiene algo en común con este modelo y muestra cómo se puede integrar un sistema de administración de versiones utilizando este enfoque de máquina abstracta. 1980) que se discute en la sección 10. utiliza un sistema de administración de objetos que provee servicios de administración y almacenamiento de información para los objetos. La figura 5. Un paso de traducción adicional convierte este código de máquina abstracta a un código de máquina real.4. la confirmación y recuperación. Este sistema utiliza un sistema de bases de datos para proveer el almacenamiento básico de datos y servicios como la administración de transacciones. Organiza un sistema en una serie de capas cada una de las cuales suministra un conjunto de servicios. y el control de acceso. 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 Programación en Ada (APSE). Cada capa define una máquina abstracta cuyo lenguaje de máquina (los servicios suministrados por la capa) se utiliza para implementar el siguiente nivel de la máquina abstracta. una forma común de implementar un lenguaje es definir un “lenguaje de máquina” ideal y compilarlo a código para esa máquina.26 Modelo de máquina abstracto de un sistema de administración de versiones La administración de la base de datos utiliza los recursos del sistema operativo en cuestión y almacena los archivos en su implementación. Figura 2. .Ivan Sommerville Ingeniería de Software El modelo de máquina abstracta El modelo de máquina abstracta de una arquitectura (algunas veces denominado modelo de capas) modela la interacción entre los subsistemas. Un ejemplo bien conocido de este enfoque es el modelo de referencia OSI para los protocolos de red (Zimmermann.

Si existen muchas capas. Los recursos básicos. puesto que una capa externa ya no es dependiente de su predecesor inmediato. se pueden implementar relativamente a bajo costo en otras computadoras. sólo se afecta la capa adyacente. Para evitar estos problemas. Esta arquitectura también es cambiable y portable. Cuando una capa se desarrolla. las aplicaciones se tienen que comunicar directamente con las capas internas. las capas exteriores se asocian a las de administración. algunos de los servicios suministrados por esa capa están disponibles para los usuarios. como la administración de archivos. Por lo tanto. Esto subvierte el modelo. Si SU interfaz se preserva. Cuando los sistemas en capas localizan dependencias de las máquinas en las capas más internas. una capa se puede reemplazar por otra capa. . Una desventaja del enfoque de capas es que estructurar a los sistemas de esta forma es difícil. los servicios requeridos por el usuario necesitan tener acceso a una máquina abstracta que está a varios niveles por debajo de la capa más externa. Cuando las interfaces de las capas cambian. Sólo es necesario reimplementar las capas internas dependientes de la máquina.Ivan Sommerville Ingeniería de Software El enfoque de capas permite el desarrollo incremental de sistemas. que son requeridos por todas las máquinas abstractas. pueden ser suministrados por las capas internas. El desempeño también puede ser un problema debido a los múltiples niveles de interpretación de órdenes que algunas veces se requieren. más que con la utilización de los recursos suministrados en la máquina abstracta.