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 especco

B. Descomposicin modular y estilos de control
a. Orientada a Objetos
b. Orientada a ujos 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
denidas, 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 ujos 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 denidas
sobre ese estado.
* En el modelo de Flujos de Funciones, los mdulos son
transformaciones funcionales.
* Los programas secuenciales son ms fciles de disear,
implementar. vericar y probar que los sistemas en
paralelo.
* Las dependencias temporales entre los procesos en
paralelo son difciles de formalizar, controlar y vericar.

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 denidas.
* 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 modicarse 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 uyen 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 uyen a travs de estas
transformaciones hasta que se convierten en datos de
salida.

Descomposicin orientada a
Flujos de Funciones
* L a s t r a n s f o r m a c i o n e s s e p u e d e n e j e c u t a r
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 (sistema de
procesamiento de facturas):

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 ujo de funciones.
* Mientras que un modelo textual sencillo de entradas y
salidas puede modelarse de esta forma, las interfaces
grcas 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 ujo 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 ujo 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 llamada-

retorno

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 ujos 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
e v e n t o s s e r i g e n p o r e v e n t o s g e n e r a d o s
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.