01 Arquitectura de Software

Taller de Sistemas de Información 1

Clase 1Clase 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

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

� Estilos basados en el control

� Arquitecturas de referencia

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 descripción de la arquitectura del software

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

Subsistemas


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 módulos?

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

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

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

� Modelos de deployment

Organización del sistema

� Refleja la estrategia utilizada para organizar el sistema

� Tres estilos organizacionales se utilizan ampliamente


ampliamenteo Repositorio de datos compartido

o Servidores y servicios compartidos

o Maquina abstracta o basado en capas

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 opción es la recomendada

Repositorio común


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 esquema del repositorio

Desventajas

� Los subsistemas deben acordar un modelo de datos para el repositorioo Es inevitable un compromiso

� La evolución de los datos es compleja y


� La evolución de los datos es compleja y costosa

� Es complejo de distribuir eficientemente

Cliente / Servidor

� Es un modelo de sistema distribuido que muestra como el procesamiento y los datos pueden distribuirse en una serie de componentes


componenteso 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

Cliente / Servidor


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

� Sencillo agregar/potenciar servidores

Desventajas

� No existe un modelo de datos compartido o comúno El intercambio de datos puede dificultarse o

hacerse ineficiente


hacerse ineficiente

� Administración redundante (en los diferentes servidores)

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

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 capao Cambios en la interfaz, solo afectan a la capa

adyacente

Maquinas abstractas (layers)


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óno 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 clases, usando algún modelo de control para invocar las operaciones detectadas

Modelo de objetos


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

� Existen variedad de lenguajes OO hoy dia

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 comuneso Si las operaciones son secuenciales, se

denomina procesamiento batch, muy usado en sistemas de procesamiento de datos

� No muy útil para sistemas interactivos

Pipelining


Ventajas

� Facilita la reutilización de transformaciones

� Es intuitivo

� Fácil agregar / quitar transformaciones


� Relativamente sencillo de implementar, a nivel concurrente o secuencial

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 tiposControl centralizado, en donde un subsistema es


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

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étodoso Modelo de Call-Return

o Modelo de Manager

Modelo de Call – Return


Modelo de Manager


Control basado en eventos

� Determinado por eventos generados externamente al subsistema

� Tenemos dos modelos basados en eventosBroadcast models


o Broadcast models

o Modelos basados en interrupciones

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

� Los subsistemas no saben cuando un evento se producirá

Modelo de broadcast


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 complejos de programar

Modelo de interrupciones


Documents

01 Arquitectura de Software