Contenido
1: Organización del sistema
La organización de un sistema refleja la estrategia
básica usada para estructurar dicho sistema. Deben tomarse decisiones sobre la
tonalidad del modelo organizacional de un sistema al principio del proceso de
diseño arquitectónico. La organización del sistema puede reflejarse
directamente en la estructura de los subsistemas .Sin embargo, es frecuente que
el modelo de subsistemas incluya más detalle que el organizacional, y no es
siempre hay una correspondiente sencilla desde los subsistemas a la estructura organizacional.
En esta sección, se incluye tres estilos organizacionales
ampliamente usados: un estilo de repositorio de datos, un estilo de servicios y
servicios compartidos y una maquina abstracto estilo por capas en donde el
sistema se organiza en un conjunto de capas funcionales.
Estos estilos se pueden utilizar juntos o por separados:
Por ejemplo un sistema puede organizarse alrededor de un repositorio de datos
compartidos pero puede también construir capas alrededor de dicho repositorio
para presentar una visión más abstracta de los datos
2: Modelo del repositorio
Los subsistemas que forman un sistema deben intercambiar
información para que puedan trabajar conjuntamente de forma efectiva. Esto
puede conseguir de dos formas fundamentales:
1) Todos
los datos compartidos se almacenan en una base de datos central a la que puede
acceder por todos los subsistemas. Un modelo de sistema basado en una base de
datos compartida se denomina algunas veces modelo de repositorio.
2) Cada
subsistema mantiene su propia base de datos. Los datos intercambian con otros
subsistemas mediante el paso de mensajes entre ellos.
La mayoría de los sistemas que usan grandes cantidades de
datos se organizan alrededor de una base de datos compartida o repositorio. Por
lo tanto, este modelo es adecuado para aplicaciones en las que los datos son
generados por un subsistema y son usados por otro.
Las ventajas y desventajas de un repositorio compartido
son las siguientes:
1) Es
una forma eficiente de compartir grandes cantidades de datos. No hay necesidad
de transmitir datos explícitamente de un subsistema a otro.
2) Sin
embargo los subsistemas deben estar acordes con el modelo de datos del
repositorio. Inevitablemente, hay un compromiso entre las necesidades específicas
de cada herramienta. El rendimiento puede verse afectado de forma adversa por
este compromiso. 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 se utilizan sus datos
por otros subsistemas.
4) Sin
embargo, la evolución puede ser difícil a medida que se genera un gran volumen
de información de acuerdo con el modelo de datos establecido. Traducir esto a
nuevo modelo, desde luego, tendrá un coste elevado; puede ser difícil o incluso
imposible.
3. Modelo Cliente-Servidor:
TCP es un protocolo orientado a conexión. No hay
relaciones maestro/esclavo. Las aplicaciones, sin embargo, utilizan un modelo
cliente/servidor en las comunicaciones.
Un servidor es una aplicación que
ofrece un servicio a usuarios de Internet; un cliente es el que pide ese
servicio. Una aplicación consta de una parte de servidor y una de cliente, que
se pueden ejecutar en el mismo o en diferentes sistemas.
Los usuarios invocan la parte cliente
de la aplicación, que construye una solicitud para ese servicio y se la envía
al servidor de la aplicación que usa TCP/IP como transporte.
El servidor es un programa que recibe
una solicitud, realiza el servicio requerido y devuelve los resultados en forma
de una respuesta. Generalmente un servidor puede tratar múltiples peticiones
(múltiples clientes) al mismo tiempo.
Figura: El modelo de aplicación
cliente/servidor
Algunos servidores esperan las
solicitudes en puertos bien conocidos de modo que sus clientes saben a que
zócalo IP deben dirigir sus peticiones. El cliente emplea un puerto arbitrario
para comunicarse. Los clientes que se quieren comunicar con un servidor que no
usa un puerto bien conocido tienen otro mecanismo para saber a qué puerto
dirigirse. Este mecanismo podría usar un servicio de registro como Portmap, que
utiliza un puerto bien conocido.
4: Modelo de capas
El modelo de capas de una arquitectura (algunas veces
denominada modelo de máquina abstracta) organiza el sistema en capas, cada una
de las cuales proporciona un conjunto de ser- vicios. Cada capa puede pensarse
como una máquina abstracta cuyo lenguaje máquina se de- fine por los
servicios proporcionados por la capa.
Este «lenguaje» se usa para implementar el siguiente nivel de la máquina
abstracta. Por ejemplo, una forma usual de implementar un lenguaje es definir
un «lenguaje máquina» ideal y compilar el lenguaje para convertirlo en código para esta máquina.
A continuación, un paso de traducción adicional convierte este código de
máquina abstracta en código de máquina real.
Un ejemplo del modelo de capas es el modelo de referencia
OS1 de protocolos de red (Zimmermann,
1980).
El sistema de gestión de configuraciones gestiona las
versiones de los objetivos y proporciona facilidades de gestión de
configuraciones generales. Para soportar estas facilidades de gestión de
configuraciones, se una un sistema de gestión de objetos que proporciona
almacenamiento de información y servicios de gestión para los objetos de
configuración u objetos. El sistema construye sobre un sistema de base de datos
para proporcionar el almacenamiento básico de datos y servicios tales como
gestión de transacciones, recuperación de actualizaciones y control de acceso.
La gestión de la base de datos usa las facilidades del sistema operativo
subyacente y almacenes de ficheros en su implementación.
5: punto
Estilos de descomposición modular
- Organización del
Sistema
a. Arquitectura centrada en datos
b. Arquitectura en capas
c. Arquitectura de sistemas distribuidos
c.1. Multiprocesador
c.2. Cliente/Servidor
c.3. Objetos distribuidos
c.4. Peer-to-peer
c.5. Orientada a servidos
d. Arquitecturas de Aplicaciones
Modelos de dominio específico
B) Descomposición modular y estilos de control
- Orientada a Objetos
- Orientada a flujos de
funciones
- Control centralizado
- Control basado en eventos
Estilos de descomposición modular
*
Después de elegir la organización del sistema en su totalidad, debemos decidir cómo descomponer los subsistemas en módulos.
*
No existe una distinción rígida entre la organización del
sistema y la descomposición modular.
*
Sin embargo, los componentes de los módulos son
normalmente más pequeños, lo que permite usar estilos alternativos de
descomposición.
Distinción entre subsistemas y módulos
1. Un subsistema es un sistema en
sí mismo. Su funcionamiento no depende de los servicios proporcionados por
otros subsistemas.
*
Los
subsistemas se componen de módulos y tienen interfaces definidas, que se usan para comunicarse con otros subsistemas.
2. Un módulo suele ser un componente de un subsistema, que brinda uno o
más servicios a otros módulos.
A su vez éste usa los
servicios proporcionados por otros módulos. No se le puede considerar como un
sistema independiente.
Distinción entre subsistemas y módulos
*
Los
módulos se componen normalmente de varios componentes del sistema más simples.
*
Hay dos
estrategias para descomponer un subsistema en módulos:
1. Descomposición
orientada a objetos: donde se descompone un sistema en un conjunto de
objetos que se comunican.
2. Descomposición
orientada a flujos de funciones: donde se descompone el sistema en
módulos funcionales que aceptan datos y los transforman en datos de salida.
6: DESCOMPOSICION ORIENTADA A OBJETOS
Donde se descompone un sistema en un conjunto de objetos
que se comunican en la aproximación orientada a objetos, los módulos son
objetos con estado privado y operacionales definidas sobre ese estado.
Existe una analogía directa entre objetos de la vida real
y los objetos del problema.
Son sistemas más fáciles de comprender para el usuario.
Diseño más intuitivo. Simplifica el seguimiento entre requerimientos y
codificación.
Es fácil ampliar un sistema, son más resistentes al
cambio. Evolucionan mejor reduce el riesgo de construir sistemas complejos.
La descomposición se basa en objetos del dominio del
problema. Desarrolladores de diferentes programas en el mismo dominio tienden a
descubrir los mismos objetos.
7: Descomposición orientada
a flujos de funciones
Es una descomposición orientada a flujos de funciones o
modelo de flujo de datos, las transformaciones funcionales procesan sus entradas y producen salidas. Los datos
fluyen de una función a otra y se transforman a medida que se mueven a través
de la secuencia de funciones. Cada paso de procesamiento se implementa como
unas transformaciones hasta que se convierten en datos de salida. Las
transformaciones se pueden ejecutar secuencialmente o en paralelo
8: Estilos De Control
Los modelos para estudiar estructurar un sistema están
relacionados con la forma en que un sistema se descompone en subsistemas. Para
trabajar como un sistema, los subsistemas deben ser controlados para que sus
servicios se entreguen en el lugar correcto en el momento preciso.
Los modelos estructurales no incluyen información de
control, en su lugar, el arquitecto debería organizar los subsistemas de
acuerdo con algún modelo de control que complemente el modelo estructurado
usado, los modelos de control a nivel arquitectónico están relacionados con el
flujo de control entre subsistemas.
Existen dos estilos de control genéricos que se usan en
sistemas de software:
Ø Control
Centralizado: Un subsistema tiene toda la responsabilidad para controlar,
iniciar, detener a otro subsistema.
También puede devolver el control a otro subsistema, pero esperara que le sea devuelta la responsabilidad de control.
También puede devolver el control a otro subsistema, pero esperara que le sea devuelta la responsabilidad de control.
Ø Control
Basado en eventos: En lugar de que la información de control este embebida en e
un subsistema puede responder a eventos generados externamente.
Estos eventos podrían provenir de otros subsistemas o del control del sistema.
Estos eventos podrían provenir de otros subsistemas o del control del sistema.
Los
estilos de control se usan conjuntamente con estilos estructurales, todos los
estilos estructurales analizados se pueden llevar a cabo utilizando control
centralizado o control basado en los eventos.
9: CONTROL CENTRALIZADO
En un modelo de control centralizado, un subsistema se
diseña como el controlador del sistema y tiene la responsabilidad de gestionar
la ejecución de otros subsistemas. Los modelos de control centralizado se dividen en dos clases, según los subsistemas
controlados se ejecuten secuencialmente o en paralelo.
Ø El
modelo de llamada retronó
Es el modelo usual de subrutina
descendente en donde el control comienza al inicio de una jerarquía de
subrutinas y, a través de las llamadas a subrutinas, el control pasa a niveles
inferiores en el árbol de la jerarquía. El modelo de subrutinas solamente es
aplicable a sistemas secuenciales.
Ø El
modelo del gestor
Este es aplicable a sistemas
concurrentes .Un componente del sistema se diseña como un gesto del sistema y
controla el inicio, parada y coordinación del resto de los procesos del sistema.
Un proceso es un subsistema o modulo que puede ejecutarse en paralelo con otros
procesos. Una variante de este modelo también puede aplicarse a sistemas
secuenciales en los que la rutina de gestión llama a subsistemas particulares
dependiendo de los valores de algunas variables de estado.
El modelo de llamada retronó
Es un modelo de gestion de control centralizado para un sistema
concurrente
10: Sistemas dirigidos por eventos
En los modelos de control centralizados, las decisiones de control se
determinan normalmente por los valores de algunas variables de estado del
sistema. Por el contrario, los modelos de control dirigidos por eventos se
rigen por eventos generados externamente. El termino evento en este contexto no
solo significa una señal binaria. Puede ser una señal dentro de un rango de
valores o una entrada de un comando desde un menú. La diferencia entre un
evento y una entrada simple es que la aparición del evento está fuera del
control del proceso que maneja ese evento.
Hay muchos tipos de sistemas dirigidos por eventos. Estos incluyen
editores, en donde los eventos de la interfaz de usuario provocan la ejecución
de comandos; sistemas de producción basados en reglas, como los usados en AI,
en donde una condición que se convierte en verdadera provoca que se dispare una
acción, y los objetos activos, en los que cambiar un valor de un atributo de un
objeto dispara algunas acciones, garlan y otros (garlan et..1992) estudian
estos diferentes tipos de sistemas.
En esta sección, se finalizan dos modelos de control dirigidos por
eventos:
1. Modelos de transmisión
(broadcast). En estos modelos, un evento se transmite a todos los subsistemas.
Cualquier subsistema que haya sido programado para manejar ese evento puede
responder a él.
2. Modelos dirigidos por
interruptores. Estos se usan exclusivamente en sistemas de tiempo real, en
donde las interrupciones externas son detectadas por un manejador de
interruptores. A continuación, éstas se envían a algún otro componente para su
procesamiento.
Los modelos de transmisión son efectivos para ingresar subsistemas
distribuidos en diferentes computadoras de una red. Los modelos dirigidos por
interrupciones se usan en sistemas de tiempo real con requerimientos temporales
rígidos.
En un modelo de transmisión, los subsistemas registran un interés en
eventos específicos. Cuantos estos eventos ocurren, el control de transfiere al
subsistema que puede manejar el evento. La diferencia entre este modelo y el
modelo centralizado , es que la política de control no está embebida en el
manejado de eventos y mensajes. Los subsistemas deciden que eventos requieren y
el manejador de eventos y mensajes asegura que estos eventos sean enviados a
dichos subsistemas.
Todos los eventos podrían enviarse a todos los subsistemas, pero estos
supondría una gran sobre carga de procesamiento. A menudo, el manejador de
eventos y de mensajes mantiene un registro de subsistemas y de los eventos que
ha estos les interesa. Los subsistemas generan eventos que indican, quizás, que
algún dato está disponible para su procesamiento.
No hay comentarios:
Publicar un comentario