10.

Diseo Arquitectnico

Objetivos
p

Importancia del diseo arquitectnico de Software. Modelos para la documentacin de una arquitectura de software. Diferentes tipos de arquitecturas de SW. Utilizacin de los modelos arquitectnicos de dominio especfico.

Tpicos
p

Estructuracin del sistema.

Modelo de depsito Modelo cliente-servidor Modelo de mquina abstracta

Modelos de Control.

Control centralizado Dirigidos por eventos Modelos de objetos Modelos de flujos de datos Modelos genricos Modelos de referencia

Descomposicin modular.

Arquitecturas de dominio especfico.

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 marco 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. Esto implica identificar los componentes principales y la comunicacin entre ellos. Ventajas de la especificacin del diseo y la documentacin de una arquitectura de sw:
1. 2. 3.

Comunicacin entre los stakeholders Anlisis del sistema. Reutilizacin a gran escala.

Ventajas de la especificacin del diseo

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. Anlisis del sistema. Hacer explcita la arquitectura es 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. 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.

Actividades comunes en el proceso de diseo arquitectnico:

1.

Estructuracin del sistema.

el sistema se estructura en varios subsistemas principales, donde un subsistema es una unidad de software independiente.

2.

Modelado del control.

se establece un modelo general de las relaciones de control entre las partes del sistema.

3.

Descomposicin modular.

cada subsistema identificado se descompone en mdulos.

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 si mismo cuya operacin no depende de los servicios suministrados por otro subsistemas. Un mdulo es por lo regular un componente del sistema que suministra uno o ms servicios a otros mdulos.

2.

p
n

La salida:
Documento de diseo arquitectnico; ste consiste de varias representaciones grficas de los modelos del sistema junto con el texto descriptivo asociado. Descripcin de cmo se estructura el sistema en subsistemas y cmo cada subsistema se estructura en mdulos. Los modelos arquitectnicos que se pueden desarrollar son:
1. 2. 3. 4.

Un modelo estructural esttico. Un modelo de proceso dinmico. Un modelo de interfaz. Modelos de relacin.

Descripcin arquitectnica: -Utilizacin de ADLs. -UML.

La arquitectura del sistema afecta directamente a los requerimientos no funcionales del sistema, por lo tanto, el estilo particular y la estructura elegida para una aplicacin puede depender de ellos: Desempeo.
la arquitectura se debe disear para localizar las operaciones crticas dentro de un nmero
reducido de subsistemas con poca comunicacin.

Seguridad.
utilizar una estructura en capas con los recursos ms crticos protegidos por las capas ms internas.

Proteccin.
las operaciones relacionadas con la proteccin se deben localizar en un solo subsistema o un nmero reducido de subsistemas.

Disponibilidad.
inclur componentes redundantes de tal forma que sea posible reemplazar y actualizar los componentes sin detener el sistema.

Mantenibilidad.
utilizar componentes autocontenidos que puedan cambiarse con facilidad.

10.1 Estructuracin del sistema

p

En el nivel ms abstracto, un diseo arquitectnico se puede ver como un diagrama de bloques en el que cada cuadro representa un subsistema. Las flechas indican que los datos y/o el control se pasan de un subsistema a otro en la direccin de las flechas. Un diagrama arquitectnico de bloques presenta un panorama general de la estructura del sistema; por lo general, comprensible por los diversos ingenieros involucrados. Los diagramas de cuadros y flechas no son la nica representacin arquitectnica que se utiliza, sin embargo es uno de los ms tiles.

Modelo estructural de la arquitectura de un sistema de robot de embalajes

Sistema de Visin

Sistema de Identificacin de Objetos

Controlador del Brazo

Controlador Gripper

Sistema de Seleccin de Paquetes Controlador Conveyor

Sistema Empaquetador

Se pueden desarrollar modelos ms especficos de la estructura que muestren como los subsistemas comparten datos, como estn distribuidos y cmo se conectan entre ellos.
1.

Modelo de depsito Modelo cliente-servidor Modelo de mquina abstracta

2.

3.

10.1.1 El modelo de depsito

p

Los subsistemas que componen un sistema deben intercambiar informacin con el fin de que puedan trabajar de forma conjunta y efectiva. Existen 2 formas fundamentales para lograr esto:
n n

Todos los datos compartidos se ubican en una base de datos central que puede ser accedida por todos los subsistemas. Cada subsistema tiene su propia base de datos. Los datos se intercambian con otros subsistemas pasando mensajes entre ellos.

La gran 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.

Las ventajas y desventajas de un depsito compartido son:

1. 2.

Es una forma eficiente de compartir grandes cantidades de datos. Los subsistemas que producen datos no necesitan saber cmo son utilizados esos datos por otros subsistemas. Sin embargo, si se genera un gran volumen de informacin, ser difcil evolucionar si se ha acordado un modelo de datos. Las actividades como respaldo, seguridad, control de acceso y recuperacin de errores estn centralizadas. Sin embargo, varios subsistemas pueden tener diferentes requerimientos de polticas de seguridad, recuperacin y respaldo. El modelo de comparticin es visible a lo largo del esquema de depsito. Sin embargo, es difcil distribuir el depsito en varias mquinas.

3.

4.

5.

6. 7.

Diseo del Editor

Generador de Cdigo

Diseo del Trasladador

Proyecto Repositorio

Editor de Programa

Analizador de diseo

Generador de Reporte

10.1.2 El modelo cliente-servidor

p

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:
n n n

Un conjunto de servidores independientes que ofrecen servicios a otros subsistemas. Un conjunto de clientes que llaman a los servicios ofrecidos por los servidores. Por lo general estos son subsistemas. Una red que permite a los clientes acceder a estos servicios.

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.

Arquitectura de un sistema bibliotecario para pelculas e imgenes.

Cliente 1 Cliente 2 Cliente 3 Cliente 4

Ancho de Banda de la red

Servidor de Catlogo Catlogo

Servidor de Vdeo Archivos clip de Pelcula

Servidor de Fotografa Fotografa Digitalizada

Servidor de Hipertexto Hipertexto WEB

La ventaja mas importante del modelo cliente-servidor es que es una arquitectura distribuida. 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. Cada servidor debe tener responsabilidad de las actividades de administracin de datos como la de respaldo y de recuperacin.

10.1.3 El modelo de mquina abstracta

p

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. Soporta el desarrollo incremental de subsistemas en diferentes capas. Cuando una interfase de la capa cambia, slo la capa adyacente es afectada. Sin embargo, una desventaja de este enfoque es que estructurar a los sistemas de esta forma es difcil. El desempeo tambin puede ser un problema debido a los mltiples niveles de interpretacin de rdenes que algunas veces se requieren.

Modelo de mquina abstracto de un sistema de administracin de versiones

Administrador de Versiones Administrador de Objetos Sistema de Base de Datos

Sistema Operativo

10.2 Modelos de Control

p

Los modelos para estructurar un sistema se refieren a la manera en que un sistema se descompone en subsistemas. Para trabajar como un sistema, los subsistemas deben controlarse para que sus servicios se entreguen al lugar correcto en el momento justo. Los modelos estructurales no incluyen informacin de control; en su lugar, el arquitecto debe organizar los subsistemas acorde a un modelo de control que complemente el modelo estructural.

Se pueden identificar 2 enfoques generales para el control:

n

Control Centralizado. Un subsistema tiene completa responsabilidad para controlar, iniciar y detener otros subsistemas. Control basado en eventos. En lugar de que la informacin de control est contenida en un sistema, cada subsistema puede responder a eventos generados en el exterior.

Los modelos de control complementan a los modelos estructurales.

10.2.1 Control Centralizado

p

Un subsistema se designa como controlador del sistema y tiene la responsabilidad de administrar la ejecucin de otros subsistemas.

Se dividen en 2 clases, dependiendo de si los subsistemas controlados se ejecutan secuencialmente o en paralelo.

1.

El modelo de llamada-retorno. El modelo del administrador.

2.

10.2.1 Control Centralizado

1. El modelo de llamada-retorno. Este es el modelo familiar de subrutina descendente en el que el control inicia en la parte superior de una jerarqua y, por medio de llamadas a la subrutina, pasa a los niveles inferiores del rbol. Slo es aplicable a sistemas secuenciales.
Programa Principal

Rutina 1

Rutina 2

Rutina 3

Rutina 1.1

Rutina 1.2

Rutina 3.1

Rutina 3.2

10.2.1 Control Centralizado

2. El modelo del administrador. Este se aplica a los modelos concurrentes. Un componente del sistema se designa como un sistema administrador y controla el inicio, la detencin y la coordinacin de otros procesos del sistema.

Proceso de Sensor

Proceso Actuador

Controlador del Sistema

Procesos de Computacin

Interface de Usuario

Manejador de Fallas

10.2.2 Sistemas dirigidos por eventos

p

En los modelos de control centralizados, las decisiones de control por lo regular se determinan por los valores de algunas variables del estado del sistema. En contraste, los modelos de control dirigidos por eventos se rigen por eventos generados en el exterior. Existe una variedad de diferentes tipos de sistemas dirigidos por eventos que se pueden desarrollar. Estos incluyen:
n n

a las hojas de clculo, en las que el valor cambiante de las celdas provoca que otras celdas se modifiquen, los sistemas de produccin basados en reglas como los de IA, en los que una condicin que se convierte en verdadera provoca que se dispare una accin, y los objetos activos en los que cambiar un valor de un atributo del objeto dispara algunas acciones.

En esta seccin se tratan 2 modelos de control dirigidos por eventos:

Modelos de transmisin. En estos modelos, un evento se transmite, en principio, a todos los subsistemas. Cualquier subsistema que pueda manejar ese evento responde a l.

1.

Subsistema 1

Subsistema 2

Subsistema 3

Subsistema 4

Manejador de Eventos y Mensajes

2. Modelos dirigidos por interrupciones. Estos se utilizan exclusivamente en sistemas de tiempo real donde las interrupciones externas son detectadas por un controlador de interrupciones. Despus stas se pasan a algn otro componente para su procesamiento.
Interrupciones

Vector de Interrupciones

Manejador 1

Manejador 2

Manejador 3

Manejador 4

Proceso 1

Proceso 2

Proceso 3

Proceso 4

10.3 Descomposicin modular

p

Despus de disear una arquitectura estructural, la siguiente etapa del proceso de diseo arquitectnico es descomponer los subsistemas en mdulos. No existe una distincin rgida entre la descomposicin del sistema y la descomposicin modular. Se consideran 2 modelos que son de utilidad cuando se descompone un subsistema en mdulos:
n

Un modelo orientado a objetos. el sistema se descompone en un conjunto de objetos que se comunican entre ellos. Un modelo de flujo de datos. el sistema se descompone en mdulos funcionales que afectan entradas de datos y las transforman, de alguna manera, en datos de salida.

10.3.1 Modelo de objetos

p

Un modelo orientado a objetos de una arquitectura de sistema estructura el sistema en un conjunto de objetos dbilmente acoplados con interfases bien definidas. Los objetos llaman a los servicios ofrecidos por otros objetos. Cliente
Cliente # Nombre Direccin Perodo de Crdito

Recibo Factura
Factura # Fecha Cantidad Cliente Emisin Envo de Recordatorio Aceptacin de Pago Envo de Recibo Factura # Fecha Cantidad Cliente #

Es posible utilizar una notacin de UML.

Pago
Factura # Fecha Cantidad Cliente #

Un modelo de objetos de un sistema de procesamiento de facturas

10.3.2 Modelo de flujo de datos

p

En este modelo las transformaciones funcionales procesan sus entradas y producen sus salidas. Los datos fluyen de un lugar a otro y se transforman durante este movimiento. Cada paso de procesamiento se implementa como una transformacin. Los datos de entrada fluyen a travs de estas transformaciones hasta que se convierten en salidas. Las transformaciones se pueden ejecutar secuencialmente o en paralelo.

Un modelo de flujo de datos de un sistema de procesamiento de facturas.

Emisin de Recibos Recibos

Lectura de Emisin de Facturas

Identificacin de Pagos

Encontrar pagos duplicados

Emisin del Recordatorio de Pago

Facturas

Pagos Recordatorios

Las ventajas de esta arquitectura son:

1.

Permite la reutilizacin de transformaciones. Es intuitiva puesto que muchas personas visualizan su trabajo en trminos del procesamiento de entradas y salidas. Permite que el sistema evolucione al agregar nuevas transformaciones de forma directa. Es sencilla de implementar ya sea como un sistema concurrente o uno secuencial.

2.

3.

4.

La desventaja principal del modelo proviene de la necesidad de un formato para transferir datos que sea reconocido por todas las transformaciones.

10.4 Arquitecturas de dominio especfico

p

Los anteriores modelos arquitectnicos son modelos generales, se pueden aplicar a diversas clases de sistemas. As como estos modelos generales, tambin se pueden utilizar modelos arquitectnicos especficos para un dominio de aplicacin particular. Existen 2 tipos de modelos arquitectnicos de dominio especfico:
n

Modelos genricos, que son abstracciones de varios sistemas reales. Modelos de referencia, que son modelos abstractos y describen a una clase mayor de sistemas. Son una forma de informar a los diseadores de la estructura general de esa clase de sistemas.

Por supuesto, no existe una distincin rgida entre estos tipos de modelo. Algunas veces, los modelos genricos tambin sirven como modelos de referencia. Los modelos genricos se pueden utilizar directamente en el diseo. Los modelos de referencia se utilizan normalmente para comunicar conceptos del dominio y comparar las posibles arquitecturas. Por lo general, los modelos genricos se derivan de forma ascendente a partir de los sistemas existentes, mientras que los modelos de referencia se derivan de forma descendente.

10.4.1 Modelos genricos

Quiz el ejemplo ms conocido de un modelo arquitectnico genrico es un modelo de un compilador. Tabla de Smbolos

Analizador Lxico

Analizador Sintctico

Analizador Semntico

Generacin de Cdigo

10.4.2 Modelos de referencia

p p

Por lo regular se derivan de un estudio del dominio de la aplicacin. Representan la arquitectura ideal que incluye todas las caractersticas que un sistema podra tener. Las arquitecturas de referencia se utilizan como una base para la implementacin de sistemas. Esta fue la intencin original del modelo de referencia OSI para la interconexin de sistemas abiertos. Si un sistema est acorde con el modelo, le debe ser posible comunicarse con otros sistemas que tambin estn acordes al modelo. Sin embargo, los modelos de referencia normalmente no son considerados como la ruta para la implementacin. En su lugar, la funcin principal es servir como medio de comparacin de diversos sistemas en un dominio.

10.4.2 Modelos de referencia

p

Un modelo de referencia provee un vocabulario para la comparacin. Acta como un estndar, contra el cual se deben evaluar los sistemas.

Modelo OSI
7 6 5 4 3 2 1

Aplicacin Presentacin Sesin Transporte Red Liga de Datos Fsico Red Liga de Datos Fsico

Aplicacin Presentacin Sesin Transporte Red Liga de Datos Fsico

Medio de Comunicacin