Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)

Contenidos de la Unidad 2 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   Sommerville. Cap. 11 Sommerville. Cap. 12 Sommerville. Cap. 13 B. Descomposición modular y estilos de control Orientada a Objetos Orientada a flujos de funciones Control centralizado Control basado en eventos Sommerville. Sección 11.3

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.

Estilos de descomposición modular En la aproximación Orientada a Objetos, los módulos son objetos con estado privado y operaciones definidas sobre ese estado. En el modelo de Flujos de Funciones, los módulos son transformaciones funcionales. Los programas secuenciales son más fáciles de diseñar, implementar. verificar y probar que los sistemas en paralelo. Las dependencias temporales entre los procesos en paralelo son difíciles de formalizar, controlar y verificar.

Estilos de descomposición modular Es mejor descomponer los sistemas en módulos, y entonces decidir durante la implementación si éstos necesitan ejecutarse secuencialmente o en paralelo.

Descomposición orientada a objetos Un Modelo Arquitectónico Orientado a Objetos estructura el sistema en un conjunto de objetos débilmente acoplados y con interfaces bien definidas. Los objetos realizan llamadas a los servicios ofrecidos por otros objetos. Una Descomposición Orientada a Objetos está relacionada con las Clases de Objetos, sus Atributos y sus Operaciones. Cuando se implementa, los objetos se crean a partir de estas clases y se usan algunos modelos de control para coordinar las operaciones de los objetos.

Descomposición orientada a objetos Las ventajas de la aproximación orientada a objetos son bien conocidas. Como los objetos están débilmente acoplados, su implementación puede modificarse sin afectar a otros objetos. Los objetos suelen ser representaciones de entidades del mundo real, por lo que la estructura del sistema es fácilmente comprensible. Como las entidades del mundo real se usan en sistemas diferentes, los objetos pueden reutilizarse.

Descomposición orientada a objetos: Desventajas Desventajas de la aproximación orientada a objetos: Para utilizar los servicios, los objetos deben referenciar de forma explícita el nombre y la interfaz de otros objetos. Si se requiere un cambio de interfaz, hay que evaluar el efecto de ese cambio sobre todos los usuarios de los objetos cambiados. Si bien los objetos pueden corresponderse con entidades del mundo real a pequeña escala, algunas veces es difícil representar como objetos entidades más complejas.

Descomposición orientada a Flujos de Funciones En 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 una transformación. Los datos de entrada fluyen a través de estas transformaciones hasta que se convierten en datos de salida.

Descomposición orientada a Flujos de Funciones Las transformaciones se pueden ejecutar secuencialmente o en paralelo. Los datos pueden ser procesados por cada transformación elemento a elemento o en un único lote. Cuando las transformaciones son secuenciales con datos procesados por lotes, este modelo arquitectónico es un modelo secuencial por lotes. Es una arquitectura común para sistemas de procesamiento de datos tales como sistemas de facturación.

Descomposición orientada a Flujos de Funciones Los Sistemas de Procesamiento de Datos suelen generar muchos informes de salida, que se derivan, a partir de cálculos simples, sobre un gran número de registros de entrada. El Modelo de Objetos es más abstracto en tanto que no incluye información sobre la secuencia de operaciones.

Descomposición orientada a Flujos de Funciones Modelo de Flujo de Funciones (sistema de procesamiento de facturas):

Descomposición orientada a Flujos de Funciones Ventajas de esta Arquitectura: 1. Permite la reutilización de transformaciones. 2. Es intuitiva y lógica (muchas personas piensan su trabajo en términos de procesamiento de entradas y salidas). 3. Se puede evolucionar, en forma directa, al sistema, añadiéndole nuevas transformaciones. 4. Es sencilla de implementar (como sistema concurrente o secuencial).

Descomposición orientada a Flujos de Funciones Desventajas: Tiene que haber un formato común para transferir los datos, para que puedan ser reconocidos por todas las transformaciones. Cada transformación debe estar acorde con las transformaciones con las que se comunica, o bien se debe imponer un formato estándar para todos los datos comunicados. Esto incrementa la sobrecarga del sistema y puede hacer imposible integrar transformaciones que utilicen formatos incompatibles de datos.

Descomposición orientada a Flujos de Funciones Los sistemas interactivos son difíciles de describir usando el modelo de flujo de funciones. Mientras que un modelo textual sencillo de entradas y salidas puede modelarse de esta forma, las interfaces gráficas de usuario tienen fórmalos de entrada/salida más complejos y controles (que se basan en eventos, tales como pulsaciones del ratón o selecciones de menús). Es difícil traducir esto a un modelo de flujo de funciones.

Estilos de Control Los modelos para 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. El diseñador debe organizar los subsistemas, de acuerdo con algún modelo de control que complemente el modelo de estructura usado. Los modelos de control a nivel arquitectónico están relacionados con el flujo de control entre subsistemas.

Estilos de Control Hay dos estilos de control genéricos: 1. Control centralizado. Un subsistema tiene toda la responsabilidad para controlar, iniciar y detener a otros subsistemas. También puede devolver el control a otro subsistema, pero esperará que le sea devuelta la responsabilidad del control. 2. Control basado en eventos. En vez de que la información de control esté embebida en un subsistema, cada subsistema puede responder a eventos generados externamente. Estos eventos podrían provenir de otros subsistemas o del entorno del sistema.

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 que los subsistemas controlados se ejecuten secuencialmente o en paralelo.

Control Centralizado 1. Modelo de llamada-retorno. Es el modelo 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. Este modelo solo es aplicable a sistemas secuenciales.

Ejemplo del modelo de llamada-retorno

El Modelo del Gestor 2. El modelo del gestor. Es aplicable a sistemas concurrentes. Un componente del sistema se diseña como un gestor del sistema y controla el inicio, parada y coordinación del resto de los procesos del sistema. Un proceso es un subsistema o módulo que puede ejecutarse en paralelo con otros procesos.

Control Centralizado La naturaleza rígida y restrictiva de este modelo es tanto una ventaja como un inconveniente. Es una ventaja debido a que es relativamente simple analizar flujos de control y conocer cómo responderá el sistema a cierto tipo de entradas. Es un inconveniente debido a que las excepciones a las operaciones normales son difíciles de manejar. Este modelo se usa en sistemas de tiempo real «blandos», los cuales no tienen restricciones de tiempo muy estrictas.

El Modelo del Gestor El controlador central gestiona la ejecución de un conjunto de procesos asociados. El proceso controlador del sistema decide cuándo deberían comenzar o terminar los procesos, dependiendo de las variables de estado del sistema. El sistema comprueba si otros procesos han producido información para ser procesada o para enviarles información para su procesamiento. El controlador por lo general realiza ciclos continuamente, consultando los sensores y otros procesos para detectar eventos o cambios de estado. Por esta razón, este modelo se llama también modelo de ciclo de eventos.

El Modelo del Gestor Ejemplo de modelo de gestión de control centralizado para un sistema concurrente (en tiempo real):

Sistemas Dirigidos por Eventos En los modelos de control centralizados, las decisiones de control se determinan por los valores de algunas variables de estado del sistema. En cambio, los modelos de control dirigidos por eventos se rigen por eventos generados externamente. Evento puede ser una señal binaria, otra señal dentro de un rango de valores o la entrada de un comando desde un menú.

Sistemas Dirigidos por Eventos Hay muchos tipos de sistemas dirigidos por eventos. Por ejemplo: editores => donde los eventos de la interfaz de usuario provocan la ejecución de comandos. Hay dos modelos de control dirigidos por eventos: 1. Modelos de transmisión (broadcast). Acá, un evento se transmite a todos los subsistemas. Cualquier subsistema que haya sido programado para manejar ese evento le puede responder. 2. Modelos dirigidos por interrupciones. Se usan en sistemas de tiempo real, donde las interrupciones externas son detectadas por un manejador de interrupciones. Luego, éstas se envían a algún otro componente para su procesamiento.