Diseño de Sistemas

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.
 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.
 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.
 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.
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.
 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.
 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.
 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.
 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.
 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?
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?
 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.
 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.
 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.
 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.
 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.
 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.
 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.
 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.
 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.
 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.
 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:
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.

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.
 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.
 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.
 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.
 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.