Descomposición modular y estilos de control

17,794 views
17,391 views

Published on

Descomposición Modular y Estilos de Control. UTN - FRT. Diseño de Sistemas. 3K1 -2011

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
17,794
On SlideShare
0
From Embeds
0
Number of Embeds
6,060
Actions
Shares
0
Downloads
333
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Descomposición modular y estilos de control

  1. 1. Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
  2. 2. Contenidos de la Unidad 2 Descomposición Modular <ul><li>Organización del Sistema </li></ul><ul><li>a. Arquitectura centrada en datos </li></ul><ul><li>b. Arquitectura en capas </li></ul><ul><li>c. Arquitectura de sistemas distribuidos </li></ul><ul><li>c.1. Multiprocesador </li></ul><ul><li>c.2. Cliente/Servidor </li></ul><ul><li>c.3. Objetos distribuidos </li></ul><ul><li>c.4. Peer-to-peer </li></ul><ul><li>c.5. Orientada a servidos </li></ul><ul><li>d. Arquitecturas de Aplicaciones </li></ul><ul><li>Modelos de dominio específico </li></ul><ul><li>  </li></ul>Sommerville. Cap. 11     Sommerville. Cap. 12             Sommerville. Cap. 13 <ul><li>B. Descomposición modular y estilos de control </li></ul><ul><ul><li>Orientada a Objetos </li></ul></ul><ul><ul><li>Orientada a flujos de funciones </li></ul></ul><ul><ul><li>Control centralizado </li></ul></ul><ul><ul><li>Control basado en eventos </li></ul></ul><ul><li>  </li></ul>Sommerville. Sección 11.3
  3. 3. <ul><li>Después de elegir la organización del sistema en su totalidad , debemos decidir cómo descomponer los subsistemas en módulos . </li></ul><ul><li>No existe una distinción rígida entre la organización del sistema y la descomposición modular. </li></ul><ul><li>Sin embargo, los componentes de los módulos son normalmente más pequeños, lo que permite usar estilos alternativos de descomposición. </li></ul>Estilos de descomposición modular
  4. 4. <ul><li>1. Un subsistema es un sistema en sí mismo. Su funcionamiento no depende de los servicios proporcionados por otros subsistemas . </li></ul><ul><li>Los subsistemas se componen de módulos y tienen interfaces definidas , que se usan para comunicarse con otros subsistemas. </li></ul><ul><li>2. Un módulo suele ser un componente de un subsistema, que brinda uno o más servicios a otros módulos . </li></ul><ul><li>A su vez éste usa los servicios proporcionados por otros módulos. No se le puede considerar como un sistema independiente. </li></ul>Distinción entre subsistemas y módulos
  5. 5. <ul><li>Los módulos se componen normalmente de varios componentes del sistema más simples. </li></ul><ul><li>Hay dos estrategias para descomponer un subsistema en módulos: </li></ul><ul><li>1. Descomposición orientada a objetos: donde se descompone un sistema en un conjunto de objetos que se comunican. </li></ul><ul><li>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. </li></ul>Distinción entre subsistemas y módulos
  6. 6. <ul><li>En la aproximación Orientada a Objetos , los módulos son objetos con estado privado y operaciones definidas sobre ese estado . </li></ul><ul><li>En el modelo de Flujos de Funciones , los módulos son transformaciones funcionales . </li></ul><ul><li>Los programas secuenciales son más fáciles de diseñar, implementar. verificar y probar que los sistemas en paralelo. </li></ul><ul><li>Las dependencias temporales entre los procesos en paralelo son difíciles de formalizar, controlar y verificar. </li></ul>Estilos de descomposición modular
  7. 7. <ul><li>Es mejor descomponer los sistemas en módulos, y entonces decidir durante la implementación si éstos necesitan ejecutarse secuencialmente o en paralelo. </li></ul>Estilos de descomposición modular
  8. 8. <ul><li>Un Modelo Arquitectónico Orientado a Objetos estructura el sistema en un conjunto de objetos débilmente acoplados y con interfaces bien definidas . </li></ul><ul><li>Los objetos realizan llamadas a los servicios ofrecidos por otros objetos . </li></ul><ul><li>Una Descomposición Orientada a Objetos está relacionada con las Clases de Objetos , sus Atributos y sus Operaciones . </li></ul><ul><li>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. </li></ul>Descomposición orientada a objetos
  9. 9. <ul><li>Las ventajas de la aproximación orientada a objetos son bien conocidas. </li></ul><ul><li>Como los objetos están débilmente acoplados, su implementación puede modificarse sin afectar a otros objetos. </li></ul><ul><li>Los objetos suelen ser representaciones de entidades del mundo real, por lo que la estructura del sistema es fácilmente comprensible. </li></ul><ul><li>Como las entidades del mundo real se usan en sistemas diferentes, los objetos pueden reutilizarse. </li></ul>Descomposición orientada a objetos
  10. 10. <ul><li>Desventajas de la aproximación orientada a objetos : </li></ul><ul><li>Para utilizar los servicios, los objetos deben referenciar de forma explícita el nombre y la interfaz de otros objetos . </li></ul><ul><li>Si se requiere un cambio de interfaz, hay que evaluar el efecto de ese cambio sobre todos los usuarios de los objetos cambiados. </li></ul><ul><li>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 . </li></ul>Descomposición orientada a objetos: Desventajas
  11. 11. <ul><li>En una Descomposición Orientada a Flujos de Funciones o Modelo de Flujo de Datos , las transformaciones funcionales procesan sus entradas y producen salidas . </li></ul><ul><li>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 . </li></ul><ul><li>Cada paso de procesamiento se implementa como una transformación. </li></ul><ul><li>Los datos de entrada fluyen a través de estas transformaciones hasta que se convierten en datos de salida. </li></ul>Descomposición orientada a Flujos de Funciones
  12. 12. <ul><li>Las transformaciones se pueden ejecutar secuencialmente o en paralelo . </li></ul><ul><li>Los datos pueden ser procesados por cada transformación elemento a elemento o en un único lote . </li></ul><ul><li>Cuando las transformaciones son secuenciales con datos procesados por lotes , este modelo arquitectónico es un modelo secuencial por lotes . </li></ul><ul><li>Es una arquitectura común para sistemas de procesamiento de datos tales como sistemas de facturación. </li></ul>Descomposición orientada a Flujos de Funciones
  13. 13. <ul><li>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. </li></ul><ul><li>El Modelo de Objetos es más abstracto en tanto que no incluye información sobre la secuencia de operaciones . </li></ul>Descomposición orientada a Flujos de Funciones
  14. 14. <ul><li>Modelo de Flujo de Funciones (sistema de procesamiento de facturas): </li></ul>Descomposición orientada a Flujos de Funciones
  15. 15. <ul><li>Ventajas de esta Arquitectura : </li></ul><ul><li>1. Permite la reutilización de transformaciones. </li></ul><ul><li>2. Es intuitiva y lógica (muchas personas piensan su trabajo en términos de procesamiento de entradas y salidas). </li></ul><ul><li>3. Se puede evolucionar, en forma directa, al sistema, añadiéndole nuevas transformaciones. </li></ul><ul><li>4. Es sencilla de implementar (como sistema concurrente o secuencial). </li></ul>Descomposición orientada a Flujos de Funciones
  16. 16. <ul><li>Desventajas : </li></ul><ul><li>Tiene que haber un formato común para transferir los datos, para que puedan ser reconocidos por todas las transformaciones. </li></ul><ul><li>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. </li></ul><ul><li>Esto incrementa la sobrecarga del sistema y puede hacer imposible integrar transformaciones que utilicen formatos incompatibles de datos. </li></ul>Descomposición orientada a Flujos de Funciones
  17. 17. <ul><li>Los sistemas interactivos son difíciles de describir usando el modelo de flujo de funciones. </li></ul><ul><li>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). </li></ul><ul><li>Es difícil traducir esto a un modelo de flujo de funciones. </li></ul>Descomposición orientada a Flujos de Funciones
  18. 18. <ul><li>Los modelos para estructurar un sistema están relacionados con la forma en que un sistema se descompone en subsistemas . </li></ul><ul><li>Para trabajar como un sistema, los subsistemas deben ser controlados para que sus servicios se entreguen en el lugar correcto, en el momento preciso . </li></ul><ul><li>El diseñador debe organizar los subsistemas , de acuerdo con algún modelo de control que complemente el modelo de estructura usado . </li></ul><ul><li>Los modelos de control a nivel arquitectónico están relacionados con el flujo de control entre subsistemas . </li></ul>Estilos de Control
  19. 19. <ul><li>Hay dos estilos de control genéricos : </li></ul><ul><li>1. Control centralizado. Un subsistema tiene toda la responsabilidad para controlar , iniciar y detener a otros subsistemas. </li></ul><ul><li>También puede devolver el control a otro subsistema, pero esperará que le sea devuelta la responsabilidad del control. </li></ul><ul><li>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 . </li></ul><ul><li>Estos eventos podrían provenir de otros subsistemas o del entorno del sistema. </li></ul>Estilos de Control
  20. 20. <ul><li>Un subsistema se diseña como el controlador del sistema y tiene la responsabilidad de gestionar la ejecución de otros subsistemas . </li></ul><ul><li>Los modelos de control centralizado se dividen en dos clases, según que los subsistemas controlados se ejecuten secuencialmente o en paralelo . </li></ul>Control Centralizado
  21. 21. <ul><li>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. </li></ul><ul><li>Este modelo solo es aplicable a sistemas secuenciales. </li></ul>Control Centralizado
  22. 22. Ejemplo de l modelo de llamada-retorno
  23. 23. <ul><li>2. El modelo del gestor. Es aplicable a sistemas concurrentes. </li></ul><ul><li>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. </li></ul><ul><li>Un proceso es un subsistema o módulo que puede ejecutarse en paralelo con otros procesos. </li></ul>El Modelo del Gestor
  24. 24. <ul><li>La naturaleza rígida y restrictiva de este modelo es tanto una ventaja como un inconveniente. </li></ul><ul><li>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. </li></ul><ul><li>Es un inconveniente debido a que las excepciones a las operaciones normales son difíciles de manejar. </li></ul><ul><li>Este modelo se usa en sistemas de tiempo real «blandos», los cuales no tienen restricciones de tiempo muy estrictas. </li></ul>Control Centralizado
  25. 25. <ul><li>El controlador central gestiona la ejecución de un conjunto de procesos asociados. </li></ul><ul><li>El proceso controlador del sistema decide cuándo deberían comenzar o terminar los procesos, dependiendo de las variables de estado del sistema. </li></ul><ul><li>El sistema comprueba si otros procesos han producido información para ser procesada o para enviarles información para su procesamiento. </li></ul><ul><li>El controlador por lo general realiza ciclos continuamente, consultando los sensores y otros procesos para detectar eventos o cambios de estado. </li></ul><ul><li>Por esta razón, este modelo se llama también modelo de ciclo de eventos. </li></ul>El Modelo del Gestor
  26. 26. <ul><li>Ejemplo de modelo de gestión de control centralizado para un sistema concurrente (en tiempo real): </li></ul>El Modelo del Gestor
  27. 27. <ul><li>En los modelos de control centralizados, las decisiones de control se determinan por los valores de algunas variables de estado del sistema. </li></ul><ul><li>En cambio, los modelos de control dirigidos por eventos se rigen por eventos generados externamente. </li></ul><ul><li>E vento puede ser una señal binaria, otra señal dentro de un rango de valores o la entrada de un comando desde un menú. </li></ul>Sistemas Dirigidos por Eventos
  28. 28. <ul><li>Hay muchos tipos de sistemas dirigidos por eventos. </li></ul><ul><li>Por ejemplo: editores => donde los eventos de la interfaz de usuario provocan la ejecución de comandos. </li></ul><ul><li>Hay dos modelos de control dirigidos por eventos: </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>Sistemas Dirigidos por Eventos

×