UNIVERSIDAD TECNOLÓGICA DE PEREIRA – INGENIERÍA DE SISTEMAS Y

COMPUTACIÓN – CURSO DE INGENIERÍA DEL SOFTWARE II

Estilos de Control 1
Los modelos para estructurar un sistema se preocupan de cómo el sistema se descompone en
subsistemas. Para trabajar como un sistema, los subsistemas deben ser controlados para que
sus servicios sean enviados al lugar correcto y en el tiempo correcto. Los modelos estructurales
no incluyen (y no deberían) información de control. En vez de eso, la arquitectura debería
organizar los subsistemas de acuerdo con algún modelo de control que suplemente el modelo
estructural que esté siendo usado. Los modelos de control a nivel arquitectónico se preocupan
del flujo de control entre subsistemas.

Hay dos estilos genéricos de control que son usados en sistemas de software:

1. Control centralizado Un subsistema tiene la responsabilidad total del control e inicia y

para a los otros subsistemas. Podría también delegar el control a otro subsistema pero
esperará que le retornen esta responsabilidad del control.
2. Control controlado por eventos En lugar de que la información sobre el control sea
embebida en un subsistema, cada subsistema puede responder a eventos generados
externamente. Estos eventos podrían venir de otros subsistemas o del ambiente del
sistema.

Los estilos de control se usan junto con los estilos estructurales. Todos los estilos estructurales
que se han discutido pueden ser realizados usando control centralizado o por eventos.

Control Centralizado

En un modelo de control centralizado, un subsistema es diseñado como el controlador del

sistema y tiene la responsabilidad de administrar la ejecución de los otros subsistemas. Los
modelos de control centralizado caen en dos clases, dependiendo de si los subsistemas se
ejecutan secuencialmente o en paralelo.

1. El modelo llamada-retorno Este es el familiar modelo Top-Down de subrutinas donde

el control comienza en el tope de una jerarquía de subrutinas y, por medio de
llamadas a subrutinas, pasa a niveles más bajos en el árbol. Este modelo sólo es
aplicable a sistemas secuenciales.
2. El modelo administrador Esto es aplicable a sistemas concurrentes. Un componente
del sistema está diseñado como un administrador del sistema y arranca, para y
coordina los otros procesos del sistema. Un proceso es un subsistema o módulo que
puede ser ejecutado en paralelo con otros procesos. Una forma de este modelo
también puede ser aplicada en sistemas secuenciales donde una rutina de
administración llama a subsistemas particulares dependiendo de los valores de
algunas variables de estado. Esto se implementa usualmente como una instrucción
case.

1
Tomado de: Ian Sommerville, Software Engineering, Pearson Education, 8ª Ed., 2007, ISBN 978-0-321-
31379-9.

1
 UNIVERSIDAD TECNOLÓGICA DE PEREIRA – INGENIERÍA DE SISTEMAS Y
COMPUTACIÓN – CURSO DE INGENIERÍA DEL SOFTWARE II

El modelo de llamada-retorno se ilustra en la figura.

El programa Main puede llamar a las rutinas 1, 2 y 3; la rutina 1 puede llamar a las rutinas 1.1 o
1.2; la rutina 3 puede llamar a las rutinas 3.1 o 3.2; etc. Este es un modelo de la dinámica del
programa, no es un modelo estructural; no hay necesidad de que la rutina 1.1, por ejemplo,
sea parte de la rutina 1.

Este familiar modelo está embebido en lenguajes de programación tales como el C, Ada y
Pascal. El control pasa de una rutina de alto nivel en la jerarquía a una rutina de más bajo nivel.
Luego retorna al punto donde la rutina fue llamada. La subrutina que se está ejecutando
actualmente tiene la responsabilidad del control y puede llamar a otras rutinas o retornar el
control a su padre. Es un pobre estilo de programación para retornar el control a algún otro
punto del programa.

Este modelo de llamada-retorno puede ser usado al nivel de módulo para controlar funciones
u objetos. Las subrutinas en un lenguaje de programación que son llamadas por otras
subrutinas son naturalmente funcionales. Sin embargo, en muchos sistemas orientados a
objetos, las operaciones sobre objetos (métodos) son implementadas como procedimientos o
funciones. Por ejemplo, cuando un objeto en Java solicita un servicio de otro objeto, lo hace
llamando al método asociado.

La naturaleza rígida y restringida de este modelo es tanto una fortaleza como una debilidad. Es
una fortaleza porque es relativamente simple analizar el flujo de control y trabajar cómo
responde el sistema a una entradas particulares. Es una debilidad debido a que las excepciones
a la operación normal son difíciles de manejar.

2
 UNIVERSIDAD TECNOLÓGICA DE PEREIRA – INGENIERÍA DE SISTEMAS Y
COMPUTACIÓN – CURSO DE INGENIERÍA DEL SOFTWARE II

La figura es una ilustración de un modelo de control de administración centralizada para un

sistema concurrente. Este modelo es usado a menudo en sistemas de tiempo real “blando”
que no tienen restricciones de tiempo muy fuertes. El controlador central administra la
ejecución de un conjunto de procesos asociados con sensores y actuadores.

El proceso controlador del sistema decide cuando los procesos deben ser iniciados o parados
dependiendo de las variables de estado del sistema. Verifica si otros procesos han producido
información para ser procesada o para pasarle información a ellos para su procesamiento.
Usualmente el controlador da vueltas continuamente, interrogando sensores y otros procesos
por eventos o cambios de estado. Por esta razón a veces se le llama modelo de ciclo de
eventos.

Sistemas administrados por eventos

En los modelos de control centralizado, las decisiones de control usualmente están

determinadas por los valores de algunas variables de estado del sistema. En contraste, los
modelos de control administrados por eventos son manejados por eventos generados
externamente. El término evento en este contexto no sólo significa señal binaria. Puede ser
una señal que puede tomar un rango de valores o una entrada de comando de un menú. La
distinción entre un evento y una simple entrada es que la temporización del evento está fuera
del control del proceso que maneja el evento.

Hay muchos tipos de sistemas manejados por eventos. Estos incluyen editores donde la
interfaz de usuario significa comandos de edición, sistemas de producción basados en reglas
como los usados en IA donde una condición que se vuelve verdadera causa que una acción sea

3
 UNIVERSIDAD TECNOLÓGICA DE PEREIRA – INGENIERÍA DE SISTEMAS Y
COMPUTACIÓN – CURSO DE INGENIERÍA DEL SOFTWARE II

disparada y objetos activos donde cambiar el valor de un atributo de un objeto dispara algunas
acciones. Garlan y otros (1992) discuten estos diferentes tipos de sistemas.

En esta sección se discuten dos modelos de control manejados por eventos:

1. Modelos de difusión En estos modelos un evento es difundido a todos los subsistemas.

Cualquier subsistema que ha sido programado para manejar ése evento puede
responder a él.
2. Modelo manejado por interrupciones Estos se usan exclusivamente en sistemas de
tiempo real donde las interrupciones externas son detectadas por un administrador de
interrupciones. Ellas son entonces pasadas a algún otro componente para su
procesamiento.

Los modelos de difusión son efectivos en integrar subsistemas distribuidos a través de

diferentes computadores sobre una red. Los modelos manejados por interrupciones son
usados en sistemas de tiempo real con severos requerimientos de temporización.

En un modelo de difusión los subsistemas registran un interés en eventos específicos. Cuando

estos eventos ocurren, el control es transferido al subsistema que puede manejar el evento. La
distinción entre este modelo y el modelo centralizado es que la política de control no está
embebida en el evento ni el administrador de mensajes. Los subsistemas deciden qué eventos
requieren, y el administrador de eventos y mensajes asegura que estos eventos son enviados a
ellos.

Todos los eventos pueden ser difundidos a todos los subsistemas, pero esto significa una gran
sobrecarga de procesamiento. Más a menudo, el manejador de eventos y mensajes mantiene
un registro de los subsistemas y los eventos de interés para ellos. Los subsistemas generan
eventos indicando quizás, que algunos datos están disponibles para procesamiento. El
manejador de eventos detecta los eventos, consulta el registro de eventos y pasa el evento a
aquellos subsistemas que han declarado un interés. En sistemas más simples, tales como
sistemas basados en PC direccionados por eventos de la interfaz de usuario, hay subsistemas
explícitos que escuchan los eventos del mouse, teclado, etc. Y traducen estos a comandos más
específicos.

El manejador de eventos usualmente maneja también comunicación punto a punto. Un

subsistema puede enviar explícitamente un mensaje a otro subsistema. Ha habido una serie de
variaciones de este modelo, tal como el ambiente Field (Reiss 1990) y el Softbench de Hewlett
Packard (Fromme y Walker 1993). Ambos han sido usados para controlar las interacciones de
las herramientas en ambientes de ingeniería del software. Los agentes solicitadores de
objetos, en inglés Object Request Brokers (ORBs), también soportan este modelo de control
para comunicación entre objetos distribuidos.

La ventaja de este modelo de difusión es que la evolución es relativamente simple. Un nuevo

subsistema para manejar clases particulares de eventos puede ser integrado registrando sus
eventos en el manejador de eventos. Cualquier subsistema puede activar a cualquiera otro sin

4
 UNIVERSIDAD TECNOLÓGICA DE PEREIRA – INGENIERÍA DE SISTEMAS Y
COMPUTACIÓN – CURSO DE INGENIERÍA DEL SOFTWARE II

conocer su nombre o localización. Los subsistemas pueden ser implementados sobre máquinas
distribuidas. Esta distribución es transparente a los otros subsistemas.

La desventaja de este modelo es que los subsistemas no saben si los eventos serán manejados
ni cuando. Cuando un subsistema genera un evento no sabe qué otro subsistema ha registrado
un interés en ese evento. Es bastante posible para diferentes subsistemas registrarse para el
mismo evento. Esto puede causar conflictos cuando los resultados de manejar el evento estén
disponibles.

Los sistemas de tiempo real que requieren eventos generados externamente a ser manejados
muy rápidamente. Por ejemplo, si un sistema de tiempo real es usado para controla los
sistemas de protección en un carro, deben detectar un posible choque y quizás inflar una bolsa
de aire (airbag) antes de que la cabeza del conductor le pegue al volante de la dirección. Para
proporcionar esta rápida respuesta a los eventos, usted tiene que usar control manejado por
interrupciones.

Un modelo de control manejado por interrupciones se muestra en la figura. Hay un número

conocido de tipos de interrupción con un manejador definido para cada tipo. Cada tipo de
interrupción está asociado con una localización de memoria donde se almacena la dirección
del manejador. Cundo una interrupción de un tipo en particular es recibid, un switche de
hardware causa que el control sea transferido inmediatamente a su manejador. Este
manejador de interrupciones puede entonces arrancar o parar otros procesos en respuesta al
evento señalado por la interrupción.

5
 UNIVERSIDAD TECNOLÓGICA DE PEREIRA – INGENIERÍA DE SISTEMAS Y
COMPUTACIÓN – CURSO DE INGENIERÍA DEL SOFTWARE II

Este modelo se usa principalmente en sistemas de tiempo real donde es necesaria una
respuesta inmediata a algún evento. Se podría combinar con un modelo de administración
centralizada. El administrador central maneja la corrida normal del sistema con el control
basado en interrupciones para las emergencias.

La ventaja de este enfoque es que permite repuestas muy rápidas a los eventos a ser
implementados. Sus desventajas son que es complejo de programar e imposible de validar.
Podría ser imposible replicar patrones de tiempo de interrupción durante la prueba del
sistema. Puede ser difícil cambiar sistemas desarrollados usando este modelo si el número de
interrupciones está limitado por el hardware. Una vez se ha alcanzado este número, ningún
otro tipo de eventos puede ser manejado. Usted algunas veces puede manejar esta limitación
relacionando varios tipos de eventos con una sola interrupción. El manejador entonces
determina qué evento ha ocurrido. Sin embargo, la relación con la interrupción puede ser
impráctica si se requiere una respuesta muy rápida a una interrupción individual.