diseño arquitectónico

Ingeniería en Sistemas de Información

Diseño de Sistemas(3K1)

Contenidos de la Unidad 2Diseño Arquitectónico

A. Organización del Sistemaa. Arquitectura centrada en datos b. Arquitectura en capas c. Arquitectura de sistemas distribuidos

c.1. Multiprocesador c.2. Cliente/Servidorc.3. Objetos distribuidosc.4. Peer-to-peerc.5. Orientada a servidos

d. Arquitecturas de Aplicaciones Modelos de dominio específico

Sommerville. Cap. 11 Sommerville. Cap. 12 Sommerville. Cap. 13

B. Descomposición modular y estilos de control

a. Orientada a Objetosb. Orientada a flujos de funcionesc. Control centralizadod. Control basado en eventos

Sommerville. Sección 11.3

Diseño ArquitectónicoDiseño Arquitectónico(Organización del (Organización del

SistemaSistema

Ian Sommerville, Cap. 11Ian Sommerville, Cap. 11

Ingeniería en Sistemas de Información

Los grandes sistemas se descomponen en subsistemas que proporcionan algún conjunto de servicios relacionados.

El Proceso de Diseño que:1) Identifica estos subsistemas y 2) establece un marco para el control y comunicación entre ellos

es el Diseño Arquitectónico. El Proceso de Diseño Arquitectónico está relacionado

con establecer un marco estructural básico para identificar los principales componentes de un sistema y las comunicaciones entre estos componentes.

Diseño ArquitectónicoIntroducción

Diseño ArquitectónicoVentajas

Hay 3 ventajas al diseñar explícitamente y documentar la arquitectura del software:

1. Comunicación con los usuarios. La arquitectura es una presentación de alto nivel del sistema que puede usarse como punto de discusión por varios usuarios.

2. Análisis del sistema. Hacer explícita la arquitectura del sistema, en una etapa temprana, requiere realizar algún análisis. Las decisiones de diseño arquitectónico tienen un gran efecto sobre los requerimientos críticos del sistema: rendimiento, fiabilidad y mantenibilidad.

3. Reutilización a gran escala. Un Modelo de Arquitectura del Sistema es una descripción compacta y manejable de cómo se organiza un sistema y cómo inter-operan sus componentes.La arquitectura del sistema es a menudo la misma para sistemas con requerimientos similares.Por eso pueden soportar reutilización del software a gran escala. Es posible desarrollar arquitecturas en donde la misma arquitectura se usa en varios sistemas relacionados.

Diseño ArquitectónicoVentajas

El Diseño Arquitectónico fuerza a los diseñadores a considerar aspectos de diseño claves en etapas tempranas del proceso.

La Arquitectura del Software sirve como un Plan de Diseño que se usa para negociar los requerimientos del sistema y para estructurar las discusiones con los clientes, desarrolladores y gestores.

También es una herramienta esencial para la gestión de la complejidad.

La Arquitectura del Software oculta detalles y permite a los diseñadores centrarse en las abstracciones clave del sistema.

Diseño ArquitectónicoOtras Ventajas

La Arquitectura del Sistema afecta al rendimiento, solidez, grado de distribución y mantenibilidad de un Sistema.

La estructura elegida para una aplicación puede depender de :

1. Rendimiento. Si el rendimiento es un requerimiento crítico, la arquitectura debería identificar las operaciones críticas en un pequeño número de subsistemas, con tan poca comunicación como sea posible entre los mismos, para priorizar el rendimiento.

Diseño ArquitectónicoCriterios que lo determinan

2. Protección. Si la protección es un requerimiento crítico, debería usarse una arquitectura estructurada en capas, con los recursos más críticos protegidos en las capas más internas y aplicando una validación de seguridad de alto nivel en tales capas.3. Seguridad. Si la seguridad es un requerimiento crítico, la arquitectura debe diseñarse para que las operaciones de seguridad se localicen en un único subsistema o en un pequeño número de subsistemas. Esto reduce los costos y los problemas de validación de seguridad.


4. Disponibilidad. Si la disponibilidad es un requerimiento crítico, la arquitectura debería diseñarse para incluir componentes redundantes y que se pueda reemplazar y actualizar componentes, sin detener el sistema. 5. Mantenibilidad. Si la mantenibilidad es un requerimiento crítico, la arquitectura del sistema debe diseñarse usando componentes independientes que puedan modificarse con facilidad.


Pueden haber conflictos potenciales entre algunas de estas arquitecturas.

Por ejemplo, hay componentes que mejoran el rendimiento, y otros, que mejoran la mantenibilidad.

Si ambas propiedades son requerimientos importantes del sistema, entonces debería encontrarse una solución intermedia.

Esto puede conseguirse usando diferentes estilos arquitectónicos para diferentes partes del sistema.


Acá se solapan los procesos de Análisis y de Diseño Arquitectónico.

Idealmente, el Análisis del Sistema no debería incluir ninguna información de Diseño.

En la práctica, esto no es así, salvo en sistemas muy pequeños.

La descomposición arquitectónica es necesaria para estructurar y organizar la especificación (Análisis).


Un Diseño de Subsistemas es una descomposición abstracta de un sistema en componentes, donde cada uno puede ser un sistema importante.

Los Diagramas de Bloques se usan para describir diseños de subsistemas, en donde cada caja, en el diagrama, representa un subsistema.

Cajas dentro de otras cajas indican que el subsistema se ha descompuesto, a su vez, en otros subsistemas.

Las flechas significan que los datos o señales de control pasan de un subsistema a otro, en la dirección de las flechas.

Diseño ArquitectónicoDiseño de Subsistemas

Los Diagramas de Bloques presentan un dibujo de alto nivel de la estructura del sistema, que puede entenderse fácilmente por personas de diferentes disciplinas, implicadas en el proceso de desarrollo.

Los Diagramas de cajas y líneas no muestran la naturaleza de las relaciones entre los componentes del sistema ni tampoco las propiedades visibles de los componentes.

Sin embargo, es un modelo efectivo para la comunicación con los usuarios del sistema y para la Planificación del Proyecto, porque no muestran los detalles.

Diseño ArquitectónicoDiagramas de Bloques

Los usuarios pueden relacionarlo con el sistema y tener una visión abstracta del mismo.

El modelo identifica los subsistemas clave, que deben ser desarrollados de forma independiente, para poder asignar personal al desarrollo de cada uno.

Los diagramas de cajas y líneas no deberían ser la única representación arquitectónica usada; aunque puedan resultar muy útiles.

Decidir cómo descomponer un sistema en subsistemas es difícil.

Diseño ArquitectónicoDiagramas de Bloques

Los Requerimientos del Sistema son un factor fundamental.

Debe diseñarse con una clara correspondencia entre los requerimientos y los subsistemas.

Esto significa que, si los requerimientos cambian, este cambio probablemente esté localizado en un único sitio, en vez de estar distribuido entre varios subsistemas.

Diseño ArquitectónicoCorrespondencia de los

Subsistemas con los Requerimientos

El Diseño Arquitectónico es un proceso creativo, que organiza al sistema para satisfacer sus requerimientos funcionales y no funcionales.

Como es un proceso creativo, las actividades del proceso difieren, dependiendo del tipo de sistema a desarrollar, el conocimiento y la experiencia del arquitecto del sistema, y los requerimientos específicos del mismo.

Por eso es mejor concebir al Proceso de Diseño Arquitectónico desde una perspectiva de decisión en lugar de una perspectiva de actividades.

Diseño ArquitectónicoUn Proceso Creativo

Durante el Proceso de Diseño Arquitectónico, los diseñadores deben tomar decisiones fundamentales que afectan profundamente al sistema y a su proceso de desarrollo.

Los Diseñadores deben responder las siguientes preguntas fundamentales:

1. ¿Hay alguna arquitectura genérica que pueda sirva como “plantilla” para el sistema que se está diseñando?

2. ¿Cómo se distribuirá el sistema entre varios procesadores?

Diseño ArquitectónicoUn Proceso Creativo

3. ¿Qué estilo o estilos arquitectónicos son apropiados para el sistema?4. ¿Cuál será la aproximación fundamental para estructurar el sistema?5. ¿Cómo se descompondrán en módulos las unidades estructurales del sistema?6. ¿Qué estrategia se usará para controlar el funcionamiento de las unidades del sistema?7. ¿Cómo se evaluará el diseño arquitectónico?8. ¿Cómo debería documentarse la arquitectura del sistema?

Diseño ArquitectónicoPreguntas que debe

formularse el Diseñador

Si bien cada sistema de software es único, los sistemas, en el mismo dominio de aplicación, suelen tener arquitecturas similares, que reflejan los conceptos fundamentales del dominio.

Estas arquitecturas de las aplicaciones pueden ser bastante genéricas, tales como la arquitectura de los sistemas de gestión de información, o pueden ser mucho más específicas.

Diseño ArquitectónicoArquitecturas “plantillas”

Las aplicaciones son aplicaciones construidas sobre una arquitectura base, con variantes que satisfacen los requerimientos específicos del cliente.

Cuando se diseña la arquitectura de un sistema, se debe decidir qué tiene en común ese sistema con clases de aplicaciones más amplias, y determinar en qué medida se pueden reutilizar esas arquitecturas.

Diseño ArquitectónicoArquitecturas “plantillas”

Para sistemas embebidos y sistemas diseñados para computadoras personales, se utiliza normalmente un único procesador.

Allí no será preciso diseñar una arquitectura distribuida para el sistema.

Sin embargo, la mayoría de los sistemas grandes son sistemas distribuidos, donde el software del sistema se distribuye entre muchas computadoras diferentes.

La elección de la arquitectura de distribución es una decisión clave que afecta al rendimiento del sistema.

Diseño ArquitectónicoDistribuir el procesamiento

La Arquitectura de un Sistema puede basarse en un Modelo o Estilo Arquitectónico particular.

El Estilo Arquitectónico es un patrón de organización de un sistema, como ser: una organización cliente-servidor o una arquitectura por capas.

Es importante conocer estos estilos, sus aplicaciones, y sus ventajas e inconvenientes.

Sin embargo, las arquitecturas de la mayoría de los sistemas grandes no utilizan un único estilo.

Diseño ArquitectónicoEstilos Arquitectónicos

Pueden diseñarse diferentes partes del sistema utilizando distintos estilos arquitectónicos.

En algunos casos, toda la arquitectura del sistema puede ser una arquitectura compuesta, creada mediante la combinación de diferentes estilos arquitectónicos.

La noción de un Estilo Arquitectónico incluye las siguientes cuestiones de diseño:

Se debe elegir la estructura más adecuada: sea cliente-servidor, o por capas, que permita satisfacer los requerimientos del sistema.

Diseño ArquitectónicoEstilos Arquitectónicos

Para descomponer las unidades del sistema estructural en módulos, hay que decidir la estrategia.

Igual para descomponer subsistemas en sus componentes o módulos.

En función de ello, podemos implementar diferentes tipos de arquitecturas.

Diseño ArquitectónicoDescomposición en Módulos

La Evaluación de un Diseño Arquitectónico es difícil.

La verdadera prueba de una arquitectura consiste en averiguar el grado de satisfacción de sus requerimientos funcionales y no funcionales, lo que ocurre después de que se hubo desarrollado el sistema.

Sin embargo, en algunos casos, se puede realizar alguna evaluación comparando el diseño elaborado, con modelos arquitectónicos genéricos o de referencia.

Diseño ArquitectónicoEvaluación

El resultado del Proceso de Diseño Arquitectónico es un Documento de Diseño Arquitectónico.

Éste puede incluir varias representaciones gráficas del sistema, junto con texto descriptivo asociado.

Debe describir cómo se estructura el sistema en subsistemas, la aproximación adoptada y cómo se estructura cada subsistema en módulos.

Una forma posible de documentación es mediante la utilización de “Modelos Gráficos del Sistema”, que presentan diferentes perspectivas de la Arquitectura.

Diseño ArquitectónicoDocumentación

Los modelos gráficos del sistema pueden ser:1. Modelo estructural estático: muestra los subsistemas o

componentes que han sido desarrollados como unidades separadas.2. Modelo de proceso dinámico: muestra cómo se organiza el

sistema en procesos, en tiempo de ejecución.3. Modelo de interfaz: define los servicios ofrecidos por cada

subsistema a través de su interfaz.4. Modelos de relaciones: muestra las relaciones (flujo de datos)

entre los subsistemas.5. Modelo de distribución: muestra cómo se distribuyen los

subsistemas entre las computadoras.

Diseño ArquitectónicoModelos Gráficos del

Sistema

La Organización de un Sistema refleja la estrategia usada para estructurar dicho sistema.

Al principio del Proceso de Diseño Arquitectónico se toman decisiones sobre todo el modelo organizacional de un sistema.

La Organización del Sistema puede reflejarse en la estructura de los subsistemas.

Estudiaremos tres estilos organizacionales: un estilo de repositorio de datos, un estilo de servicios y servidores compartidos y una máquina abstracta o estilo por capas, en donde el sistema se organiza en un conjunto de capas funcionales.

Estos estilos se pueden utilizar juntos o por separado.

Diseño ArquitectónicoOrganización del Sistema

Diseño ArquitectónicoEl Modelo de Repositorio

Los subsistemas que forman un sistema deben intercambiar información para poder trabajar, conjuntamente, de forma efectiva.

Esto es puede conseguir de dos formas:1.Todos los datos compartidos se almacenan

en una base de datos central a la que puede acceder por todos los subsistemas.

Este modelo basado en una base de datos compartida se denomina Modelo de Repositorio.

2. Cada subsistema mantiene su propia base de datos. Los datos se intercambian con otros subsistemas, pasando mensajes entre ellos.Este modelo es adecuado para aplicaciones donde los datos son generados por un subsistema y utilizados por otro. Ejemplos: los sistemas de gestión de información, CAD y herramientas CASE.La mayoría de los sistemas que usan grandes cantidades de datos se organizan alrededor de una base de datos compartida o repositorio.


Ventajas y Desventajas del Modelo Repositorio:

1. Forma eficiente de compartir grandes cantidades de datos.

No hay necesidad de transmitir datos explícitamente de un subsistema a otro.

2. Los subsistemas deben estar acordes (compatibilidad) con el modelo de datos del repositorio.

Puede ser difícil o imposible integrar nuevos subsistemas si sus modelos de datos no se ajustan al esquema acordado.


3. Los subsistemas que producen datos no necesitan conocer cómo los otros subsistemas emplean sus datos.4. La evolución puede ser difícil a medida que se genera mayor volumen de información. Llevar el Repositorio a un nuevo modelo tendrá un costo elevado; puede ser difícil o aún imposible.La Figura siguiente muestra una arquitectura de herramientas CASE, basada en un Repositorio Compartido:

Diseño ArquitectónicoRepositorio: Ventajas y

Desventajas

5. Las actividades tales como: copias de seguridad, protección, control de acceso y recuperación de errores están centralizadas. Se gestionan a nivel del Repositorio.6. Sin embargo, diferentes subsistemas pueden tener distintos requerimientos de protección, recuperación y políticas de seguridad. El modelo de repositorio impone una misma política para todos los subsistemas.


Desventajas

7. El Repositorio facilita compartir recursos. Las nuevas herramientas se integran directamente, ya que son compatibles con el modelo de datos.8. Es difícil distribuir el Repositorio sobre varias máquinas. Si bien es posible un Repositorio Centralizado Lógicamente, puede haber problemas con la redundancia de datos y las inconsistencias.


Desventajas

Arquitectura de un conjunto de herramientas Case integradas


El Modelo Arquitectónico Cliente-Servidor es un Modelo de Sistema, que se organiza como un conjunto de servicios y servidores asociados, más unos clientes que acceden y usan los servicios.

Componentes de este modelo:1. Un conjunto de servidores que ofrecen servicios a otros

subsistemas. Ejemplos: Servidores de Impresoras, que ofrecen servicios

de impresión: Servidores de Archivos que ofrecen servicios de gestión de ficheros; y Servidores de Compilación: que ofrecen servicios de compilación de lenguajes de programación, etc.

Diseño ArquitectónicoModelo Cliente – Servidor

2. Un conjunto de clientes que llaman a los servicios ofrecidos por los servidores.

Son normalmente subsistemas. Pueden haber varias instancias de un programa cliente

ejecutándose concurrentemente.3. Una red que permite a los clientes acceder a estos

servicios. Esto no es estrictamente necesario, cuando clientes y

servidores se ejecutan sobre una única máquina. En la práctica, la mayoría de los sistemas cliente-servidor se

implementan como sistemas distribuidos.

Diseño ArquitectónicoCliente – Servidor.

Componentes

Los clientes pueden conocer los nombres de los servidores disponibles y los servicios que éstos proporcionan.

Sin embargo, los servidores no necesitan conocer la identidad de los clientes o cuántos clientes tienen.

Los clientes acceden a los servicios proporcionados por un servidor, a través de llamadas a procedimientos remotos usando un protocolo de petición-respuesta.

Básicamente, un cliente realiza una petición a un servidor y espera hasta que recibe una respuesta.


Arquitectura de un sistema de biblioteca de películas y fotografías:


La Figura anterior muestra un ejemplo de un sistema basado en el Modelo Cliente-Servidor.

Es un sistema multiusuario, basado en web, para proporcionar una biblioteca de películas y fotografías.

Aquí, varios servidores gestionan diferentes tipos de dispositivos.

Las secuencias de video deben ser transmitidas rápidamente y en sincronía, pero con baja resolución.

Éstas pueden comprimirse en un almacén para que el servidor de vídeo gestione la compresión y descompresión de video en diferentes formatos.


Sin embargo, las fotografías deben mantenerse con una alta resolución, por lo que es adecuado mantenerlas en un servidor separado.

El catálogo debe manejar gran variedad de peticiones y proporcionar enlaces al sistema de información, con datos sobre las películas y las fotografías.

También debe contemplar un sistema de comercio electrónico, para la venta de películas y fotografías.

El programa Cliente es simplemente una interfaz de usuario integrada con estos servicios y construida sobre un navegador web.


La ventaja más importante del modelo Cliente-Servidor es que es una arquitectura distribuida.

Se puede hacer un uso efectivo de los sistemas en red, con muchos procesadores distribuidos.

Es fácil añadir un nuevo servidor e integrarlo con el resto del sistema o actualizar los servidores de forma transparente, sin afectar al resto del sistema.


El Modelo de Capas (o de Máquina Abstracta) organiza el sistema en capas, cada una de las cuales proporciona un conjunto de servicios.

La aproximación por capas soporta el desarrollo incremental de sistemas.

A medida que se desarrolla una capa, algunos de los servicios proporcionados por esa capa pueden estar disponibles para los usuarios.

Esta arquitectura soporta bien los cambios y es portable.

Diseño ArquitectónicoModelo de Capas

Mientras su interfaz permanezca sin cambios, una capa puede reemplazarse por otra capa equivalente.

Cuando las interfaces de la capa cambian o se añaden nuevas facilidades a una capa, solamente se ve afectada la capa adyacente.

Únicamente las capas más internas deben ser reimplementadas para incorporar las facilidades de un sistema operativo o base de datos diferente.


Ejemplo de un Modelo de Capas:


La Capa de Gestión de Configuraciones es similar a la Capa de Presentación que nos enseñaba Craig Larman.

La Capa de Gestión de Objetos almacena información y servicios de gestión (análoga a la Capa de Lógica de Larman).

El sistema se construye sobre una Capa de Base de Datos, para almacenamiento básico de datos y servicios (gestión de transacciones, recuperación de actualizaciones y control de acceso).

La Base de Datos usa las facilidades del Sistema Operativo subyacente.


Desventaja de este modelo: la estructuración de los sistemas puede resultar difícil.

Las capas internas pueden proporcionar facilidades básicas, tales como gestión de archivos, que son requeridas por todos los niveles.

Por lo tanto: los servicios requeridos por un usuario del nivel superior pueden tener que «atravesar» las capas adyacentes para acceder a los servicios proporcionados por los niveles inferiores.

Esto trastoca el modelo, ya que implica que la capa más externa del sistema no solamente depende de su predecesora inmediata.


El rendimiento puede también ser un problema. Si hay muchas capas, un servicio solicitado

desde la capa superior puede tener que ser interpretado varias veces en diferentes capas, antes de ser procesado.

Para evitar estos problemas, las aplicaciones tienen que comunicarse directamente con las capas interiores en vez de usar los servicios proporcionados por las capas adyacentes.


diseño arquitectónico

Documents