01 arquitectura de software
Post on 02-Aug-2015
37 Views
Preview:
TRANSCRIPT
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 3
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 4
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)
INCO - Facultad de Ingeniería – Montevideo, Uruguay 5
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 6
presentando una visión general del sistema
� En caso de que sea necesario, se puede aumentar el detalle de algún subsistema importante
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?
INCO - Facultad de Ingeniería – Montevideo, Uruguay 8
� 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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 9
� 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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 10
� 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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 11
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 12
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
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,
INCO - Facultad de Ingeniería – Montevideo, Uruguay 14
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 15
� 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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 16
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
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 18
� 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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 19
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 20
(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)
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 22
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 23
� 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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 24
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 25
� 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
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 27
� 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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 28
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 29
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 30
Ventajas
� Facilita la reutilización de transformaciones
� Es intuitivo
� Fácil agregar / quitar transformaciones
INCO - Facultad de Ingeniería – Montevideo, Uruguay 31
� 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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 32
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 33
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 34
� Tenemos dos métodoso Modelo de Call-Return
o Modelo de Manager
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 eventosBroadcast models
INCO - Facultad de Ingeniería – Montevideo, Uruguay 37
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 38
� 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
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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 40
� 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
INCO - Facultad de Ingeniería – Montevideo, Uruguay 41
top related