El Diseño Arquitectónico

UNIVERSIDAD TECNOLÓGICA DE PEREIRA – INGENIERÍA DE SISTEMAS Y COMPUTACIÓN CURSO DE INGENIERÍA DEL SOFTWARE II

1

El Diseñ o Arquitecto ñico1

Los grandes sistemas siempre se descomponen en subsistemas que proporcionan algún

conjunto de servicios relacionados. El proceso de diseño inicial de identificar estos subsistemas

y establecer un marco de trabajo para el control y las comunicaciones de los subsistemas se

llama diseño arquitectónico. El resultado de este proceso de diseño es una descripción de la

arquitectura del software.

El diseño arquitectónico es la primera etapa en el proceso de diseño y representa un enlace

crítico entre el diseño y el proceso de requerimientos. El proceso de diseño arquitectónico se

preocupa de establecer un marco de trabajo estructural que identifique los componentes

mayores de un sistema y la comunicación entre estos componentes.

Bass y otros (2003) discuten tres ventajas de diseñar y documentar explícitamente una

arquitectura de software:

1. Comunicación con Interesados: La arquitectura es una presentación de alto nivel del

sistema que puede ser usada como foco para discutir con un amplio rango de

interesados.

2. Análisis del Sistema: Hacer explícita la arquitectura del sistema en una etapa temprana

del desarrollo del sistema requiere algún análisis. Las decisiones de diseño

arquitectónico tienen un profundo efecto sobre si el sistema puede cumplir

requerimientos críticos tales como desempeño, confiabilidad y mantenibilidad.

3. Reusabilidad a Gran Escala: Un modelo de la arquitectura del sistema es una

descripción compacta y manejable de cómo el sistema está organizado y cómo

interoperan los componentes. La arquitectura del sistema es a menudo la misma para

sistemas similares y puede soportar reusabilidad del software a gran escala. Puede ser

posible desarrollar arquitecturas de línea de productos donde la misma arquitectura es

usada a través de un rango de sistemas relacionados.

Hofmeister y otros (2000) discuten cómo la etapa de diseño arquitectónico forza a los

diseñadores de software a considerar aspectos clave del diseño de manera temprana en el

proceso. Ellos sugieren que la arquitectura del software puede servir como un plan de diseño

que es usado para negociar requerimientos y como un medio para estructurar discusiones con

clientes, desarrolladores y administradores. También sugieren que es una herramienta esencial

para administrar la complejidad. Esconde los detalles y le permite a los diseñadores enfocarse

en las abstracciones clave del sistema.

La arquitectura del sistema afecta el desempeño, robustez, distribuibilidad y mantenibilidad de

un sistema. El estilo y estructura particulares escogidos para una aplicación puede entonces

depender de los requerimientos no funcionales:

1 Tomado de: Ian Sommerville, Software Engineering, Pearson Education, 8ª Ed., 2007, ISBN 978-0-321-31379-9.


2

1. Desempeño: Si el desempeño es un requerimiento crítico, la arquitectura debe ser

diseñada para localizar las operaciones críticas en un pequeño número de

subsistemas, con tan poca comunicación como sea posible entre estos subsistemas.

Esto puede significar el uso de componentes de grano relativamente grande en lugar

de componentes de grano fino para reducir la comunicación entre componentes.

2. Seguridad: Si la seguridad es un requerimiento crítico, se debe usar una estructura en

capas para la arquitectura, con los activos más críticos protegidos en las capas más

internas y con un alto nivel de validación de seguridad aplicado a estas capas.

3. Protección: Si la protección es un requerimiento crítico, la arquitectura debería estar

diseñada de tal manera que las operaciones relacionadas con la protección estén

localizadas en un solo subsistema o en un pequeño número de subsistemas. Esto

reduce el costo y los problemas de la validación de protección y hace posible

proporcionar sistemas relacionados con la protección.

4. Disponibilidad: Si la disponibilidad es un requerimiento crítico, la arquitectura debería

ser diseñada para incluir componentes redundantes de tal manera que sea posible

reemplazar y actualizar componentes sin parar el sistema.

5. Mantenibilidad: Si la mantenibilidad es un requerimiento crítico, la arquitectura del

sistema debería ser diseñada usando componentes de grano fino, auto contenidos que

puedan ser cambiados rápidamente. Los productores de datos deberían estar

separados de los consumidores y se deberían evitar las estructuras de datos

compartidas.

Obviamente hay conflictos potenciales entre algunas de estas arquitecturas. Por ejemplo, usar

componentes de grano grueso mejora el desempeño y usar componentes de grano fino

mejora la mantenibilidad. Si ambos son requerimientos importantes para el sistema, se debe

encontrar alguna solución de compromiso. Algunas veces esto se puede cumplir usando

diferentes estilos arquitectónicos para diferentes partes del sistema.

Hay un traslape significativo entre el proceso de requerimientos y el diseño arquitectónico.

Idealmente, la especificación de un sistema no debería incluir ninguna información de diseño.

En la práctica esto no es realista excepto para sistemas muy pequeños. La descomposición

arquitectónica es necesaria para estructurar y organizar la especificación. Se puede usar un

modelo arquitectónico como punto de inicio para la especificación de subsistemas.

Un diseño de subsistemas es una descomposición abstracta de un sistema en componentes de

grano grueso, cada uno de los cuales puede ser un sistema substancial por derecho propio. Las

cajas dentro de las cajas indican que el subsistema ha sido descompuesto a su vez en

subsistemas. Las flechas significan que los datos y las señales de control se pasan de

subsistema a subsistema en la dirección de las flechas. Los diagramas de bloques presentan un

gráfico de alto nivel de la estructura del sistema, que la gente de diversas disciplinas

interesada en el sistema puede comprender fácilmente.

Por ejemplo, la siguiente figura es un modelo abstracto de la arquitectura para un sistema de

robot empacador que muestra los subsistemas que tienen que ser desarrollados. Este sistema

de robot puede empacar diferentes clases de objetos. Usa un subsistema de visión para

escoger objetos en una cinta transportadora (conveyor), identifica el tipo de objeto y


3

selecciona la clase correcta de empaquetamiento. El sistema entonces mueve los objetos

desde la cinta transportadora de envíos a ser empacados. Ubica los objetos empacados sobre

otra cinta transportadora.

Bass y otros (2003) reclaman que diagramas simples de cajas y líneas no son representaciones

arquitectónicas útiles porque no muestran la naturaleza de las relaciones entre componentes

del sistema ni muestran las propiedades visibles externamente de los componentes. Desde el

punto de vista de un diseñador de software, esto es absolutamente correcto. Sin embargo,

este tipo de modelo es efectivo para comunicarse con los interesados en el sistema y para

planeación de proyectos, porque no está superpoblado de detalles. Los interesados pueden

comprender una visión abstracta del sistema. El modelo identifica los subsistemas clave que

van a ser desarrollados de manera independiente para que los administradores puedan

comenzar a asignar personas para planear el desarrollo de estos sistemas. Los diagramas de

cajas y líneas ciertamente no deberían ser la única representación usada del sistema; sin

embargo, son uno de los muchos modelos útiles.

El problema general de decidir cómo descomponer el sistema en subsistemas es difícil. Por

supuesto, los requerimientos del sistema son un factor mayor y usted debería tratar de crear

un diseño donde haya una cercana concordancia entre requerimientos y subsistemas. Esto


4

significa que, si el requerimiento cambia, este cambio probablemente será localizado en lugar

de distribuido a través de varios subsistemas.

1. Decisiones de Diseño Arquitectónico El diseño arquitectónico es un proceso creativo donde usted trata de establecer una

organización del sistema que satisfaga los requerimientos funcionales y no funcionales del

sistema. Como es un proceso creativo, las actividades dentro del proceso difieren radicalmente

dependiendo del tipo de sistema siendo desarrollado, la hoja de vida y experiencia del

arquitecto del sistema y los requerimientos específicos del sistema. Entonces es más útil

pensar el proceso de diseño arquitectónico desde el punto de vista de las decisiones en lugar

del punto de vista de las actividades. Durante el proceso de diseño arquitectónico, los

arquitectos de sistemas tienen que tomar una cantidad de decisiones fundamentales que

afectan profundamente el sistema y su proceso de desarrollo. Con base en su conocimiento y

experiencia, ellos tienen que responder las siguientes preguntas fundamentales:

1. Hay una arquitectura genérica de aplicación que pueda actuar como una plantilla para

el sistema que está siendo diseñado?

2. Cómo será distribuido el sistema a través de una cantidad de procesadores?

3. Qué estilo o estilos arquitectónicos son apropiados para el sistema?

4. Cual será el enfoque fundamental utilizado para estructurar el sistema?

5. Cómo las unidades estructurales del sistema se descomponen en módulos?

6. Qué estrategia será usada para controlar la operación de las unidades del sistema?

7. Cómo se evaluará el diseño arquitectónico?

8. Cómo debería ser documentada la arquitectura del sistema?

Aunque cada sistema de software es único, los sistemas en el mismo dominio de aplicación a

menudo tienen arquitecturas similares que reflejan los conceptos fundamentales del dominio.

Estas arquitecturas de aplicación pueden ser genéricas, tales como la arquitectura de sistemas

de administración de la información, o mucho más específicas. Por ejemplo, las aplicaciones de

líneas de productos son aplicaciones que están construidas alrededor de una arquitectura

núcleo con variantes que satisfacen los requerimientos específicos del cliente. Cuando se

diseña una arquitectura del sistema, hay que decidir qué tienen en común su sistema y clases

de aplicación más amplias, y decidir cuánto conocimiento de estas arquitecturas de aplicación

puede ser reutilizado.

Para sistemas embebidos y sistemas diseñados para computadoras personales, usualmente

sólo hay un procesador y usted no tendrá que diseñar una arquitectura distribuida a través de

muchos computadores distintos. Sin embargo, la mayoría de los sistemas son ahora sistemas

distribuidos donde el software del sistema está distribuido en muchas computadoras

diferentes. La elección de la arquitectura distribuida es una decisión clave que afecta el

desempeño y la confiabilidad del sistema.

La arquitectura de un sistema de software se puede basar en un modelo arquitectónico

particular o estilo. Un estilo arquitectónico es un patrón de organización del sistema tal como

una organización cliente-servidor o una arquitectura en capas. Una conciencia de estos estilos,

sus aplicaciones, y sus fortalezas y debilidades es importante. Sin embargo, las arquitecturas


5

de la mayoría de los grandes sistemas no se apegan a un solo estilo. Partes diferentes del

sistema pueden ser diseñadas usando diferentes estilos arquitectónicos. En algunos casos, la

arquitectura del sistema global puede ser una arquitectura compuesta que es creada

combinando diferentes estilos arquitectónicos.

La noción de Garlan y Shaw de un estilo arquitectónico cubre las siguientes tres preguntas de

diseño. Usted ha escogido la estructura más apropiada tal como cliente servidor, o estructura

en capas, que le permitirá cumplir los requerimientos del sistema. Para descomponer las

unidades estructurales del sistema en módulos, usted decide sobre la estrategia de

descomposición de subsistemas en sus componentes o módulos. El enfoque que usted use le

permite diferentes tipos de arquitectura a ser implementada. Finalmente, en el proceso de

modelamiento del control, usted toma decisiones acerca de cómo se controla la ejecución de

los subsistemas. Usted desarrolla un modelo general de relaciones de control entre las partes

establecidas del sistema.

Evaluar un diseño arquitectónico es difícil porque la verdadera prueba de una arquitectura

está en qué tan bien cumple sus requerimientos funcionales y no funcionales después de que

ha sido desplegada. Sin embargo, en algunos casos usted puede hacer algunas evaluaciones

comparando su diseño contra diseños de referencia o contra modelos arquitectónicos

genéricos.

El producto de un proceso de diseño arquitectónico es un documento de diseño

arquitectónico. Este puede incluir una cantidad de representaciones gráficas junto con texto

descriptivo asociado. Debería describir cómo el sistema se estructura en subsistemas, el

enfoque adoptado y cómo cada subsistema se estructura en módulos. Los modelos gráficos del

sistema presentan diferentes perspectivas sobre la arquitectura. Los modelos arquitectónicos

que pueden ser desarrollados pueden incluir:

1. Un modelo de estructura estático: muestra los subsistemas o componentes que van a

ser desarrollados como unidades independientes.

2. Un modelo dinámico de procesos: muestra cómo el sistema está organizado en

procesos en tiempo de corrida. Este puede ser diferente del modelo estático.

3. Un modelo de interfaces: define los servicios ofrecidos por cada subsistema a través

de su interfaz pública.

4. Un modelo de relaciones: muestra las relaciones tales como flujo de datos, entre los

subsistemas.

5. Un modelo de distribución: muestra cómo los subsistemas pueden ser distribuidos

entre las computadoras.

Varios investigadores han propuesto el uso de lenguajes de descripción arquitectónica (ADLs)

para describir arquitecturas de sistemas. Bass y otros (2003) describen las principales

características de estos lenguajes. Los elementos básicos de los ADLs son los componentes y

los conectores, e incluyen reglas y guías para arquitecturas bien formadas. Sin embargo, como

todos los lenguajes especializados, los ADLs sólo pueden ser comprendidos por expertos en el

lenguaje y son inaccesibles a los especialistas en el dominio de la aplicación. Esto los hace

difíciles de analizar desde un punto de vista práctico. Seguramente serán usados en un


6

pequeño número de aplicaciones. Los modelos y notaciones informales tales como UML

permanecerán siendo la notación más ampliamente usada para descripciones arquitectónicas.

Documents

El Diseño Arquitectónico