Ingeniera en Sistemas de Informacin

Diseo de Sistemas (3K1)

Contenidos de la Unidad 2 Descomposicin Modular

A. Organizacin 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 especfico B. Descomposicin modular y estilos de control a. Orientada a Objetos b. Orientada a flujos de funciones c. Control centralizado d. Control basado en eventos Sommerville. Cap. 11

Sommerville. Cap. 12

Sommerville. Cap. 13 Sommerville. Seccin 11.3

Estilos de descomposicin modular

Despus de elegir la organizacin del sistema en su totalidad, debemos decidir cmo descomponer los subsistemas en mdulos. No existe una distincin rgida entre la organizacin del sistema y la descomposicin modular. Sin embargo, los componentes de los mdulos son normalmente ms pequeos, lo que permite usar estilos alternativos de descomposicin.

Distincin entre subsistemas y mdulos

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 mdulos y tienen interfaces definidas, que se usan para comunicarse con otros subsistemas. 2. Un mdulo suele ser un componente de un subsistema, que brinda uno o ms servicios a otros mdulos. A su vez ste usa los servicios proporcionados por otros mdulos. No se le puede considerar como un sistema independiente.

Distincin entre subsistemas y mdulos

Los mdulos se componen normalmente de varios componentes del sistema ms simples. Hay dos estrategias para descomponer un subsistema en mdulos: 1. Descomposicin orientada a objetos: donde se descompone un sistema en un conjunto de objetos que se comunican. 2. Descomposicin orientada a flujos de funciones: donde se descompone el sistema en mdulos funcionales que aceptan datos y los transforman en datos de salida.

Estilos de descomposicin modular

En la aproximacin Orientada a Objetos, los mdulos son objetos con estado privado y operaciones definidas sobre ese estado. En el modelo de Flujos de Funciones, los mdulos son transformaciones funcionales. Los programas secuenciales son ms fciles de disear, implementar. verificar y probar que los sistemas en paralelo. Las dependencias temporales entre los procesos en paralelo son difciles de formalizar, controlar y verificar.

Estilos de descomposicin modular

Es mejor descomponer los sistemas en mdulos, y entonces decidir durante la implementacin si stos necesitan ejecutarse secuencialmente o en paralelo.

Descomposicin orientada a objetos

Un Modelo Arquitectnico Orientado a Objetos estructura el sistema en un conjunto de objetos dbilmente acoplados y con interfaces bien definidas. Los objetos realizan llamadas a los servicios ofrecidos por otros objetos. Una Descomposicin 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.

Descomposicin orientada a objetos

Las ventajas de la aproximacin orientada a objetos son bien conocidas. Como los objetos estn dbilmente acoplados, su implementacin 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 fcilmente comprensible. Como las entidades del mundo real se usan en sistemas diferentes, los objetos pueden reutilizarse.

Descomposicin orientada a objetos: Desventajas

Desventajas de la aproximacin orientada a objetos: Para utilizar los servicios, los objetos deben referenciar de forma explcita 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 pequea escala, algunas veces es difcil representar como objetos entidades ms complejas.

Descomposicin orientada a Flujos de Funciones

En una Descomposicin 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 funcin a otra y se transforman a medida que se mueven a travs de la secuencia de funciones. Cada paso de procesamiento se implementa como una transformacin. Los datos de entrada fluyen a travs de estas transformaciones hasta que se convierten en datos de salida.

Descomposicin orientada a Flujos de Funciones

Las transformaciones se pueden ejecutar secuencialmente o en paralelo. Los datos pueden ser procesados por cada transformacin elemento a elemento o en un nico lote. Cuando las transformaciones son secuenciales con datos procesados por lotes, este modelo arquitectnico es un modelo secuencial por lotes. Es una arquitectura comn para sistemas de procesamiento de datos tales como sistemas de facturacin.

Descomposicin orientada a Flujos de Funciones

Los Sistemas de Procesamiento de Datos suelen generar muchos informes de salida, que se derivan, a partir de clculos simples, sobre un gran nmero de registros de entrada. El Modelo de Objetos es ms abstracto en tanto que no incluye informacin sobre la secuencia de operaciones.

Descomposicin orientada a Flujos de Funciones

Modelo de Flujo de Funciones procesamiento de facturas): (sistema de

Descomposicin orientada a Flujos de Funciones

Ventajas de esta Arquitectura: 1. Permite la reutilizacin de transformaciones. 2. Es intuitiva y lgica (muchas personas piensan su trabajo en trminos de procesamiento de entradas y salidas). 3. Se puede evolucionar, en forma directa, al sistema, aadindole nuevas transformaciones. 4. Es sencilla de implementar (como sistema concurrente o secuencial).

Descomposicin orientada a Flujos de Funciones

Desventajas: Tiene que haber un formato comn para transferir los datos, para que puedan ser reconocidos por todas las transformaciones. Cada transformacin debe estar acorde con las transformaciones con las que se comunica, o bien se debe imponer un formato estndar para todos los datos comunicados. Esto incrementa la sobrecarga del sistema y puede hacer imposible integrar transformaciones que utilicen formatos incompatibles de datos.

Descomposicin orientada a Flujos de Funciones

Los sistemas interactivos son difciles 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 grficas de usuario tienen frmalos de entrada/salida ms complejos y controles (que se basan en eventos, tales como pulsaciones del ratn o selecciones de mens). Es difcil traducir esto a un modelo de flujo de funciones.

Estilos de Control
Los modelos para estructurar un sistema estn 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 diseador debe organizar los subsistemas, de acuerdo con algn modelo de control que complemente el modelo de estructura usado. Los modelos de control a nivel arquitectnico estn relacionados con el flujo de control entre subsistemas.

Estilos de Control
Hay dos estilos de control genricos: 1. Control centralizado. Un subsistema tiene toda la responsabilidad para controlar, iniciar y detener a otros subsistemas. Tambin 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 informacin de control est embebida en un subsistema, cada subsistema puede responder a eventos generados externamente. Estos eventos podran provenir de otros subsistemas o del entorno del sistema.

Control Centralizado
Un subsistema se disea como el controlador del sistema y tiene la responsabilidad de gestionar la ejecucin de otros subsistemas. Los modelos de control centralizado se dividen en dos clases, segn 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 jerarqua de subrutinas y, a travs de las llamadas a subrutinas, el control pasa a niveles inferiores en el rbol de la jerarqua. Este modelo solo es aplicable a sistemas secuenciales.

Ejemplo del modelo de llamadaretorno

El Modelo del Gestor

2. El modelo del gestor. Es aplicable a sistemas concurrentes. Un componente del sistema se disea como un gestor del sistema y controla el inicio, parada y coordinacin del resto de los procesos del sistema. Un proceso es un subsistema o mdulo que puede ejecutarse en paralelo con otros procesos.

Control Centralizado
La naturaleza rgida 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 cmo responder el sistema a cierto tipo de entradas. Es un inconveniente debido a que las excepciones a las operaciones normales son difciles 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 ejecucin de un conjunto de procesos asociados. El proceso controlador del sistema decide cundo deberan comenzar o terminar los procesos, dependiendo de las variables de estado del sistema. El sistema comprueba si otros procesos han producido informacin para ser procesada o para enviarles informacin 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 razn, este modelo se llama tambin modelo de ciclo de eventos.

El Modelo del Gestor

Ejemplo de modelo de gestin 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 seal binaria, otra seal 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 ejecucin de comandos. Hay dos modelos de control dirigidos por eventos: 1. Modelos de transmisin (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 envan a algn otro componente para su procesamiento.