Taller de Sistemas de

Información 1
Clase 1
Arquitectura de Software
Temas

Decisiones en el diseño arquitectónico

Organización de un sistema de información

Estilos basados en descomposición

Estilos basados en el control

Arquitecturas de referencia

INCO - Facultad de Ingeniería – Montevideo, Uruguay 2

Arquitectura de software

El diseño arquitectónico es el proceso a
través del cual se identifican los subsistemas
que componen un sistema de información,
así como los mecanismos de control y
comunicación usados por los mismos

El resultado de este proceso es una
descripción de la arquitectura del software

INCO - Facultad de Ingeniería – Montevideo, Uruguay 3

Diseño arquitectónico

Etapa temprana en el proceso de desarrollo
de un sistema de información

Es el enlace entre la especificación del
sistema y el desarrollo del mismo

Implica identificar los principales
componentes del sistema y su mecanismo de
comunicación

INCO - Facultad de Ingeniería – Montevideo, Uruguay 4

Ventajas

Comunicación entre los interesados

Reutilización a gran escala

Análisis del sistema (requerimientos no

funcionales)

INCO - Facultad de Ingeniería – Montevideo, Uruguay 5

Estructura del sistema

Descompone el sistema en subsistemas que
interactúan entre si

Se expresa como un diagrama de bloques
presentando una visión general del sistema

En caso de que sea necesario, se puede
aumentar el detalle de algún subsistema
importante

INCO - Facultad de Ingeniería – Montevideo, Uruguay 6

Subsistemas

INCO - Facultad de Ingeniería – Montevideo, Uruguay 7

Decisiones arquitectónicas

Existe algún ejemplo de arquitectura
genérica que pueda aplicarse?

Como se distribuirá el sistema?

Algún estilo de arquitectura es aplicable?

Como se descompondrá el sistema en

módulos?

Como se controlaran y comunicaran esos
módulos?

INCO - Facultad de Ingeniería – Montevideo, Uruguay 8

Estilos arquitectónicos

El modelo arquitectónico de un sistema
puede basarse en un estilo o modelo
genérico de arquitectura

Conocer estos modelos de antemano puede
facilitar la tarea de definir la arquitectura de
un sistema

Los grandes sistemas, son heterogéneos, no
siguiendo un claro estilo arquitectónico único

INCO - Facultad de Ingeniería – Montevideo, Uruguay 9

Modelos arquitectónicos

Usados para documentar la arquitectura de
un sistema

Modelos estáticos estructurales

Modelos dinámicos de procesos

Modelos de interfaces

Modelos de datos

Modelos de deployment

INCO - Facultad de Ingeniería – Montevideo, Uruguay 10

Organización del sistema

Refleja la estrategia utilizada para organizar
el sistema

Tres estilos organizacionales se utilizan
ampliamente
o Repositorio de datos compartido
o Servidores y servicios compartidos
o Maquina abstracta o basado en capas

INCO - Facultad de Ingeniería – Montevideo, Uruguay 11

Repositorio común

Los subsistemas deben intercambiar datos
o Los datos se almacenan en un repositorio o base
de datos central, y los subsistema acceden a
estos
o Los subsistemas mantienen los datos
internamente, intercambiándolos explícitamente
según sea necesario

Para grandes volúmenes de datos, la primer
opción es la recomendada

INCO - Facultad de Ingeniería – Montevideo, Uruguay 12

Repositorio común

INCO - Facultad de Ingeniería – Montevideo, Uruguay 13

Ventajas

Es una forma eficiente de compartir grandes
volúmenes de información

Los subsistemas no tienen que preocuparse
del manejo centralizado de datos (backup,
seguridad, etc)

El modelo de compartición es publicado en el
esquema del repositorio

INCO - Facultad de Ingeniería – Montevideo, Uruguay 14

Desventajas

Los subsistemas deben acordar un modelo
de datos para el repositorio
o Es inevitable un compromiso

La evolución de los datos es compleja y
costosa

Es complejo de distribuir eficientemente

INCO - Facultad de Ingeniería – Montevideo, Uruguay 15

Cliente / Servidor

Es un modelo de sistema distribuido que
muestra como el procesamiento y los datos
pueden distribuirse en una serie de
componentes
o Serie de servidores que brindan un determinado
servicio (impresión, datos, email, etc)
o Serie de clientes que utilizan esos servidores
o Red que permite conectar ambas partes

INCO - Facultad de Ingeniería – Montevideo, Uruguay 16

Cliente / Servidor

INCO - Facultad de Ingeniería – Montevideo, Uruguay 17

Ventajas

La distribución de los datos es sencilla

Hace un uso extensivo de los servicios de
red

Puede utilizar hardware menos costoso

Sencillo agregar/potenciar servidores

INCO - Facultad de Ingeniería – Montevideo, Uruguay 18

Desventajas

No existe un modelo de datos compartido o
común
o El intercambio de datos puede dificultarse o
hacerse ineficiente

Administración redundante (en los diferentes
servidores)

No existe un registro central de servidores y
servicios
o Puede complicarse hallar lo necesario

INCO - Facultad de Ingeniería – Montevideo, Uruguay 19

Maquinas abstractas (layers)

Usado para modelar la interacción entre
subsistemas

Organiza el sistema en una serie de capas
(layers) o maquinas abstractas, cada una de
las cuales provee una serie de servicios

Soporta el desarrollo incremental de cada
capa
o Cambios en la interfaz, solo afectan a la capa
adyacente

INCO - Facultad de Ingeniería – Montevideo, Uruguay 20

Maquinas abstractas (layers)

INCO - Facultad de Ingeniería – Montevideo, Uruguay 21

Descomposición en módulos

Son los estilos que permiten descomponer
un subsistema en módulos

No hay una frontera clara entre la
organización en subsistemas y la
descomposición en módulos

INCO - Facultad de Ingeniería – Montevideo, Uruguay 22

Subsistemas vs. módulos

Un subsistema es un sistema por si mismo,
cuya operación es independiente de los
servicios provistos por otros subsistemas

Un modulo es un componente de un sistema
que provee servicios a otros componentes
pero no seria normalmente considerado
como un sistema separado

INCO - Facultad de Ingeniería – Montevideo, Uruguay 23

Descomposición modular

Se suelen utilizar dos modelos de
descomposición
o Un modelo de objetos, en los que el sistema es
descompuesto en una serie de objetos que
interactúan
o Un modelo de pipeline o flujo de datos, en los que
el sistema es descompuesto en una serie de
módulos funcionales, que transforman inputs en
outputs

INCO - Facultad de Ingeniería – Montevideo, Uruguay 24

Modelo de objetos

Estructuramos el sistema en un conjunto de
objetos, desacoplados con interfaces
claramente definidas

Este tipo de descomposición debe identificar
clases, atributos y operaciones

Los objetos son creados a partir de estas
clases, usando algún modelo de control para
invocar las operaciones detectadas

INCO - Facultad de Ingeniería – Montevideo, Uruguay 25

Modelo de objetos

INCO - Facultad de Ingeniería – Montevideo, Uruguay 26

Ventajas

Los objetos están desacoplados, de forma
que cambios en su interior no afectan el resto
del subsistema

Los objetos reflejan la realidad

Existen variedad de lenguajes OO hoy dia

INCO - Facultad de Ingeniería – Montevideo, Uruguay 27

Desventajas

Cambios en las interfaces pueden generar
gran impacto en el sistema

Entidades de la realidad complejas, pueden
no se fácilmente representadas como clases

INCO - Facultad de Ingeniería – Montevideo, Uruguay 28

Pipelining

Transformaciones funcionales transforman
las entradas en salidas

Se suele llamar modelo de pipes & filters, en
referencia al shell de UNIX/LINUX

Hay variaciones muy comunes
o Si las operaciones son secuenciales, se
denomina procesamiento batch, muy usado en
sistemas de procesamiento de datos

No muy útil para sistemas interactivos

INCO - Facultad de Ingeniería – Montevideo, Uruguay 29

Pipelining

INCO - Facultad de Ingeniería – Montevideo, Uruguay 30

Ventajas

Facilita la reutilización de transformaciones

Es intuitivo

Fácil agregar / quitar transformaciones

Relativamente sencillo de implementar, a

nivel concurrente o secuencial

INCO - Facultad de Ingeniería – Montevideo, Uruguay 31

Desventajas

Requiere algún formato común para transferir
los datos a través del pipeline

Es difícil soportar interacciones basadas en
eventos

INCO - Facultad de Ingeniería – Montevideo, Uruguay 32

Estilos de control

Estos estilos se preocupan por el flujo de
control entre los subsistemas

Tenemos dos tipos
o Control centralizado, en donde un subsistema es
el encargado de iniciar y detener otros
subsistemas
o Control basado en eventos, en donde cada
subsistema puede responder a eventos
generador por otros subsistemas o por el
ambiente del sistema

INCO - Facultad de Ingeniería – Montevideo, Uruguay 33

Control centralizado

Un subsistema de control, toma la
responsabilidad de administrar la ejecución
de los demás subsistemas

Tenemos dos métodos
o Modelo de Call-Return
o Modelo de Manager

INCO - Facultad de Ingeniería – Montevideo, Uruguay 34

Modelo de Call – Return

INCO - Facultad de Ingeniería – Montevideo, Uruguay 35

Modelo de Manager

INCO - Facultad de Ingeniería – Montevideo, Uruguay 36

Control basado en eventos

Determinado por eventos generados
externamente al subsistema

Tenemos dos modelos basados en eventos
o Broadcast models
o Modelos basados en interrupciones

INCO - Facultad de Ingeniería – Montevideo, Uruguay 37

Modelo de broadcast

Efectivo al integrar subsistemas de diferente
origen y en diferentes ambientes de
hardware

Los subsistemas registran su interés en
determinados eventos. Cuando estos
ocurren, el control es transferido al
subsistema que puede manejar el evento

Los subsistemas no saben cuando un evento
se producirá

INCO - Facultad de Ingeniería – Montevideo, Uruguay 38

Modelo de broadcast

INCO - Facultad de Ingeniería – Montevideo, Uruguay 39

Modelo de interrupciones

Usado en sistemas de tiempo real, en donde
la respuesta inmediata a un evento es
importante

Existen tipos definidos de interrupciones, con
un handler asociado a cada tipo

Facilita la respuesta rápida, pero son
complejos de programar

INCO - Facultad de Ingeniería – Montevideo, Uruguay 40

Modelo de interrupciones

INCO - Facultad de Ingeniería – Montevideo, Uruguay 41