Taller de Sistemas de
Información 1
Clase 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
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
así como los mecanismos de control y comunicación usados por los mismos
El resultado de este proceso es una
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 sistema y el desarrollo del mismo
Implica identificar los principales
componentes del sistema y su mecanismo de comunicación
Ventajas
Comunicación entre los interesados
Reutilización a gran escala
Análisis del sistema (requerimientos no
funcionales) funcionales)
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 presentando una visión general del sistema
En caso de que sea necesario, se puede
aumentar el detalle de algún subsistema importante
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?
Algún estilo de arquitectura es aplicable?
Como se descompondrá el sistema en
módulos?
Como se controlaran y comunicaran esos
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
Conocer estos modelos de antemano puede
facilitar la tarea de definir la arquitectura de un sistema
Modelos arquitectónicos
Usados para documentar la arquitectura de
un sistema
Modelos estáticos estructurales
Modelos dinámicos de procesos
Modelos dinámicos de procesos
Modelos de interfaces
Modelos de datos
Organización del sistema
Refleja la estrategia utilizada para organizar
el sistema
Tres estilos organizacionales se utilizan
ampliamente ampliamente
o Repositorio de datos compartido
o Servidores y servicios compartidos
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
estos
o Los subsistemas mantienen los datos
internamente, intercambiándolos explícitamente según sea necesario
Para grandes volúmenes de datos, la primer
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, del manejo centralizado de datos (backup, seguridad, etc)
El modelo de compartición es publicado en el
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
La evolución de los datos es compleja y
costosa
Cliente / Servidor
Es un modelo de sistema distribuido que
muestra como el procesamiento y los datos pueden distribuirse en una serie de
componentes componentes
o Serie de servidores que brindan un determinado
servicio (impresión, datos, email, etc)
o Serie de clientes que utilizan esos servidores
Ventajas
La distribución de los datos es sencilla
Hace un uso extensivo de los servicios de
red
Puede utilizar hardware menos costoso
Puede utilizar hardware menos costoso
Desventajas
No existe un modelo de datos compartido o
común
o El intercambio de datos puede dificultarse o
hacerse ineficiente hacerse ineficiente
Administración redundante (en los diferentes
servidores)
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 (layers) o maquinas abstractas, cada una de las cuales provee una serie de servicios
Soporta el desarrollo incremental de cada
capa
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 organización en subsistemas y la descomposición en módulos
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
Un modulo es un componente de un sistema
que provee servicios a otros componentes pero no seria normalmente considerado como un sistema separado
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 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
Modelo de objetos
Estructuramos el sistema en un conjunto de
objetos, desacoplados con interfaces claramente definidas
Este tipo de descomposición debe identificar
Este tipo de descomposición debe identificar
clases, atributos y operaciones
Los objetos son creados a partir de estas
Ventajas
Los objetos están desacoplados, de forma
que cambios en su interior no afectan el resto del subsistema
Los objetos reflejan la realidad
Los objetos reflejan la realidad
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 no se fácilmente representadas como clases
Pipelining
Transformaciones funcionales transforman
las entradas en salidas
Se suele llamar modelo de pipes & filters, en
referencia al shell de UNIX/LINUX referencia al shell de UNIX/LINUX
Hay variaciones muy comunes
o Si las operaciones son secuenciales, se
Ventajas
Facilita la reutilización de transformaciones
Es intuitivo
Fácil agregar / quitar transformaciones
Relativamente sencillo de implementar, a
Desventajas
Requiere algún formato común para transferir
los datos a través del pipeline
Es difícil soportar interacciones basadas en
eventos eventos
Estilos de control
Estos estilos se preocupan por el flujo de
control entre los subsistemas
Tenemos dos tipos
Control centralizado, en donde un subsistema es
o Control centralizado, en donde un subsistema es
el encargado de iniciar y detener otros subsistemas
Control centralizado
Un subsistema de control, toma la
responsabilidad de administrar la ejecución de los demás subsistemas
Tenemos dos métodos
Tenemos dos métodos
o Modelo de Call-Return
Control basado en eventos
Determinado por eventos generados
externamente al subsistema
Tenemos dos modelos basados en eventos
Broadcast models
o Broadcast models
Modelo de broadcast
Efectivo al integrar subsistemas de diferente
origen y en diferentes ambientes de hardware
Los subsistemas registran su interés en
Los subsistemas registran su interés en
determinados eventos. Cuando estos ocurren, el control es transferido al
subsistema que puede manejar el evento
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
Existen tipos definidos de interrupciones, con
un handler asociado a cada tipo
Facilita la respuesta rápida, pero son
