Unidad 6: Morfología de Sistemas Simples

6.0 Introducción: Organización y Morfología

En el contexto del diseño de programas y de sistemas, utilizamos la palabra "organización" para describir la forma en que la estructura es utilizada para realizar una función deseada. Dicho de otra manera, la organización es la relación entre función y estructura.

El término "Morfología" se refiere a la forma de un sistema con respecto a su estructura. Por ejemplo, la profundidad de una estructura (el número de niveles de módulos subordinados) es una característica morfológica visible. El ancho de una estructura modular, es otra característica morfológica.

Nuestro propósito es doble. Primero, examinaremos organizaciones comunes de sistemas modulares, y morfologías de sistemas comunes. Segundo, realizaremos comparaciones entre organizaciones comunes y buenos sistemas, es decir aquellos con bajo acoplamiento y alta cohesión.

6.1 Organización de Sistemas Modulares

En que se basa el diseñador para decidir sobre una división particular de un programa o sistema en módulos? Cómo decide qué porciones del procesamiento total pertenecerán a un módulo determinado?

Encontraremos que un sistema modular usualmente está centrado alrededor de varios aspectos específicos de su función. Más allá de que el diseñador explícitamente reconozca una estructura modular en particular, usualmente podremos identificar un concepto o criterio de organización implícito.

En muchos casos, la estructura literalmente se centra alrededor de un módulo con un propósito o función muy distintivo. Entonces, podemos hablar de diseño Centrado en la Transacción. Tales sistemas se desarrollan en torno a módulos que realizan varias acciones asociadas con transacciones. Generalmente, existe un módulo (o pequeño grupo de módulos) que pasan todas las transacciones a sus módulos subordinados para procesar las transacciones.

Algunos tipos de organizaciones modulares han sido reflejadas en estrategias: procedimientos formales sistemáticos para desarrollar, desde la descripción de un problema, la estructura modular de sistemas del tipo deseado.

Así existe un esquema conocido como Análisis de Transacción.

El diseño centrado en el procedimiento es derivado de representaciones procedurales (diagramas de flujo de control). Usualmente los sistemas centrados en el procesamiento alcanzan solo cohesión temporal o procedural.

El diseño centrado en dispositivos, el cual es común en porciones de sistemas operativos pero raro en otros casos, se enfoca en dispositivos físicos de entrada-salida y sus interfaces. Aunque en los niveles más bajos de un sistema se invocará algún módulo orientado a dispositivo, este enfoque usualmente no se pasa hacia los niveles superiores de la estructura.

Todo sistema puede pensarse involucrando una o más transformaciones centrales: principales funciones del sistema que "digieren" los datos provenientes de las corrientes de entrada y producen las mayores corrientes de salida del sistema. Debido a esto, podemos tener sistemas Centrados en la Transformación.

Una estrategia formal de diseño conocida como Análisis de Transformación se utiliza para derivar este tipo de sistemas.

En la práctica, el diseño centrado en la transformación no comienza con identificar las transformaciones como los módulos centrales del sistema. Es más sencillo identificar primero todo lo demás, y luego llamar al resto, transformaciones "esenciales" o "mayores" del sistema.

Consideremos el siguiente ejemplo:

fig6-1.jpg (8261 bytes)

 

Las funciones A y B, básicamente son operaciones que realizadas en secuencia, obtienen la principal corriente de datos del sistema. Hasta la primera línea vertical marcada como "I", los datos están ingresando al sistema. Luego de la línea II, los datos pueden pensarse como fluyendo fuera del sistema. Las partes remanentes del proceso no son ni entrada ni salida, por lo tanto C es la transformación central del sistema.

6.2 Modelos Específicos de Organización de Sistemas

Ocasionalmente, los diseñadores hacen uso de un modelo funcional o estructural específico como una guía para el diseño estructural. En un sentido, tal uso representa una preconcepción técnica acerca de como debe parecerse el sistema. Esto debería simplificar y generalizar la tarea del diseño, sin embargo muchas veces es perjudicial debido a la aplicación literal de los modelos.

Un modelo específico de organización de sistema es mostrado a continuación en dos variantes:

fig6-2.jpg (10684 bytes)

Uno puede considerar la versión CIPO como la estructura literal de un sistema. En este caso, solo cuatro módulos serán implementados, a pesar del tamaño del problema. Nótese que el módulo "Entrada", implementado literalmente, probablemente alcance a ser solo lógicamente cohesivo.

En general diremos que, mientras que modelos estructurales específicos pueden desarrollarse, su simple y literal aplicación al diseño estructurado no es recomendable.

6.3 Factorización

La factorización implica la descomposición de una determinada tarea en una jerarquía de módulos partiendo de un módulo raíz o ejecutivo y llegando a los módulos atómicos que realiza las funciones operativas.

Análogamente a lo que sucede en las organizaciones humanas, un módulo ejecutivo de máximo nivel, no realiza ninguna de las tareas del sistema por si mismo, si no a través de sus subordinados. En el caso límite, un módulo ejecutivo solo contiene llamadas a otros módulos.

Diremos que el sistema estará completamente factorizado si todo el proceso (computación y manipulación de datos) es realizado en módulos atómicos de bajo nivel, y si todos los módulos no atómicos de nivel superior consisten solo de control y coordinación. En un sistema completamente factorizado, cada módulo no atómico es un ejecutivo con respecto a sus subordinados.

Basado en una regla de pensamiento de diseño y en estrategias sistemáticas, sistemas bien diseñados tienden a mostrar una distribución del proceso de decisión característico. A medida que se desciende en la estructura, la proporción de elementos de decisión decrece. El carácter de las decisiones también cambia. Los módulos de alto nivel normalmente tratan decisiones globales, en tanto que los de bajo nivel tratan aspectos específicos de las decisiones de nivel superior.

6.4 Flujo Aferente, Eferente, Transformación y Coordinación

En el estudio de la estructura modular de un sistema, usualmente encontramos un pequeño número de categorías de módulos.

Notamos por ejemplo, que algunos módulos obtienen información de sus subordinados y luego la transmites hacia a arriba a sus superiores. Esto se conoce como flujo aferente de datos. Un módulo con este tipo de flujo se conoce como módulo aferente.

Normalmente este tipo de módulos están involucrados en procesos de entrada.

fig6-3.jpg (2138 bytes)

 

Otros módulos en cambio reciben datos de sus superiores y lo transmiten a sus subordinados. En tal caso hablamos de flujo eferente y de módulos eferentes.

Normalmente este tipo de módulos están involucrados en procesos de salida.

fig6-4.jpg (2093 bytes)

 

Normalmente, tanto los módulo aferentes como los eferentes, no transmitirán los datos tal como los reciben, si no que usualmente realizarán alguna transformación sobre ellos.

Más allá de esto, lo importante es que estos módulos pasan información hacia arriba y hacia abajo.

fig6-5.jpg (2118 bytes)

Existe otro tipo de módulos que solamente realizan una transformación sobre los datos que reciben y los devuelven en otra forma. En este caso hablamos de flujo de transformación y de módulos de transformación.

Un caso típico de este tipo de módulo son los aquellos que realizan cálculos, por ejemplo los matemáticos (raíz cuadrada, etc.).

fig6-6.jpg (1976 bytes)

 

Finalmente, observamos que existen otros módulos cuya función es la de coordinar y administrar los tareas de otros. En tal caso hablamos de flujo de coordinación y de módulos de coordinación.

Este tipo de módulos pueden encontrarse en las porciones de entrada, transformaciones centrales, y salidas de un determinado sistema.

En un sistema bien diseñado, usualmente encontraremos este tipo de módulos en un nivel alto en la jerarquía.

fig6-7.jpg (2663 bytes)

Además de estos tipos específicos, es común encontrar módulos que combinen más de un tipo de flujo. Así encontramos módulos de coordinación y eferentes, o aferentes, etc.

6.5 Morfología de Sistemas

A lo largo de este capítulo hemos examinado las estructuras modulares desde diferentes puntos de vista. Hemos visto que el diseñador puede verse motivado a desarrollar una estructura centrada en la transacción, en el procedimiento, u verse influenciado por otro tipo de organizaciones modulares, las cuales se toman como modelos. También hemos visto que consideraciones de factorización influenciarán la distribución de módulos y la cantidad de "inteligencia" dentro de cada módulo. Finalmente, hemos visto que otra manera de caracterizar a los módulos es según los flujos de información entrantes y salientes, en aferentes, eferentes, de coordinación, o de transformación.

Ahora podemos poner todas las piezas juntas, y examinar la morfología o forma de una estructura completa.

Veremos que ciertas características como el ancho o amplitud y la profundidad, se encuentran en todos los sistemas. Comparando estas características de un determinado diseño contra las de otro, podremos determinar que dicho diseño es bueno o malo.

 

Profundidad

Una de las características morfológicas obvias es la profundidad, esto es el número de niveles de la jerarquía.

La profundidad, por sí misma, no es una medida válida de la calidad de un diseño.

En la práctica se observa que un programa de simple (300 líneas) puede tener una profundidad de 5 o 6 niveles, y algunos de mediana complejidad pueden tener fácilmente una profundidad de 10 a 12 niveles.

 

Amplitud

Otro aspecto a considerar sobre la forma de un sistema es la amplitud, esto es la cantidad de módulos que tiene de ancho el diseño.

A primera vista podremos decir que obviamente, cuando mayor sea la amplitud del sistema, mayor será su complejidad.

Una medida relacionada con la amplitud en forma directa es lo que los diseñadores llaman el ancho de salida (fan-out). Esto es el número de módulos inmediatamente subordinados que tiene un determinado módulo.

El fan-out promedio de una estructura será el promedio de los fan-out de todos los módulos excepto los inferiores o terminales que tienen fan-out cero.

Cuando mayor sea el fan-out de un módulo, mayor será su complejidad, debido a que debe contener más lógica de control y coordinación.

En una estructura modular efectiva, el fan-out promedio tiende a ser bajo.

 

Morfologías generales

En lugar de manejar medidas primitivas como amplitud y profundidad, consideraremos la morfología general del sistema.

Basados en la observación y estudio de numerosos sistemas durante varios años, se determinó que los sistemas mejor diseñados tienden a tener una forma como la siguiente:

fig6-8.jpg (6119 bytes)

La estructura puede compararse con un cigarro, un plato volador, o una mezquita.

Note que la forma de mezquita tiene un alto fan-out en los módulos de alto nivel, y de bajo nivel. Debemos observar que la forma de mezquita es característica de los sistemas bien diseñados, pero es potencialmente peligroso si es usado como una herramienta de diseño. Veremos también que las metodologías de Análisis de Transacción, y Análisis de Transformación, que estudiaremos más adelante, tienden a producir diseños con esta forma.

 

Estructuras Balanceadas y Desbalanceadas

Veremos ahora dos características morfológicas conocidas como "balanceo" y "desbalanceo".

Veamos las siguientes estructuras:

fig6-9.jpg (12231 bytes)

 

A simple vista muchos dirán que la estructura de la figura A está desbalanceada, y que la figura B está balanceada. Sin embargo, debido a que solo las relaciones topológicas entre módulos son estructuralmente relevantes, la figura B es equivalente a la A.

El concepto de balanceo sin embargo puede ser de utilidad si podemos fijar un orden predeterminado en el dibujo de la estructura. El flujo de datos desde el origen de entradas físicas, atravesando transformaciones, y llegando finalmente a las salidas establece una determinada orientación predefinida.

En nuestro ejemplo de las figuras previas (A, B), AA es un módulo aferente cuya salida es procesada a través de BB y CC y eventualmente GG. Podemos decir que dichas estructuras están desbalanceadas respecto del flujo de datos.

Los sistemas pueden estar desbalanceados en la dirección de sus entradas, como sucede en el ejemplo previo (fig. A), o estar desbalanceado en la dirección de sus salidas.

Dependiendo del tipo de balanceo o desbalanceo que se observe, tendremos estructuras orientadas a las entradas, o input-driven, orientadas a las salidas u output-driven, y balanceadas.

 

Estructuras Input-Driven

Un sistema altamente desbalanceado en la dirección de sus entradas, obtiene todas sus entradas en forma física elemental (raw, crudo), cerca del tope de la jerarquía. Todo el procesamiento de las entradas tiene lugar en niveles menores de la jerarquía, y principalmente, en ramas de la jerarquía que son predominantemente eferentes. En verdad el sistema entero es predominantemente eferente. Esto es tradicionalmente llamado un sistema input-driven.

Un sistema input-driven puede comparase a un gerente sin recepcionista o secretaría que se ve forzado a atender personalmente los requerimientos operativos.

En el siguiente ejemplo se puede ver una estructura de un programa que recibe sus entradas desde una terminal CRT en forma de líneas elementales. Un mismo campo puede conformarse de una línea para lo cual se utiliza un carácter de continuación de línea. Estas líneas son recibidas directamente por el módulo ejecutivo, y de las mismas debe extraerse y editarse campos con los que se actualizarán un archivo maestro.

fig6-10.jpg (29497 bytes)

 

Estructuras Output-Driven

Un sistema en el cual el módulo tope produce las salidas del sistema en forma elemental o cruda (raw).

El código Output-driven puede verse como filosóficamente diferente. Con código input-driven, las entradas determinan que ocurre en el proceso: los ítems son leídos primero, luego el código decide que hacer con ellos. De otro modo, inicialmente podemos identificar un ítem que será producido como salida del sistema, y en base a esto, desarrollar el proceso que será necesario para obtener dicho ítem.

En este caso, el sistema es predominantemente aferente. Un sistema estrictamente output-driven activará todos sus módulos aferentes, en los niveles bajos de la estructura, antes de poder obtener una primera entrada.

Por supuesto, los eventos pueden sucederse en el mismo orden que en un sistema input driven, pero la estructura del sistema será muy diferente.

Se observa como regla general que los sistemas output-driven son menos eficientes que un equivalente input-driven.

 

Estructuras Balanceadas

Los sistemas balanceados no tendrán ítems elementales en el tope de la jerarquía, en ninguna de las ramas de entrada ni salida. Generalmente implica que el nivel tope tendrá control inmediato sobre las funciones más importantes del sistema.

Los sistemas balanceados en sus ramas aferentes y eferentes también se conocen como centrados en la transformación. Este es el tipo de estructura que buscaremos lograr.

El balance también puede alcanzarse teniendo entradas y salidas elementales en el tope de la estructura, pero esto es un reflejo de una violación a la regla de factorización, provocando que el módulo ejecutivo se deba inmiscuir en los detalles.

6.6 Morfología Centrada en la Transformación

De los factores morfológicos relacionados con la simplicidad de un sistema, la morfología conocida como organización centrada en la transformación es la más importante.

La siguiente figura refleja un modelo centrado en la transformación:

 

fig6-11.jpg (27065 bytes)

 

Este modelo combina varias características morfológicas deseables. Es altamente factorizado. Las ramas aferentes y eferentes están balanceadas. El modelo no es input-driven ni output-driven.

Las ramas aferentes y eferentes tienen una estructura característica. En la forma totalmente factorizada, esta estructura involucra en cada nivel una transformación simple, o conjunto de transformaciones alternativas realizadas por módulos subordinados de transformación, cuyas entradas son suministradas por el último módulo subordinado aferente (en la rama aferente), o cuyas salidas alimentan al próximo módulo subordinado eferente (en la rama eferente).

Este tipo de modelo fue derivado empíricamente de una cuidadosa revisión de morfologías de sistemas, comparando sistemas simples y económicos de implementar, mantener y modificar, con otros complicados y costosos.

 

 

WB01343_.gif (599 bytes) WB01344_.gif (1348 bytes) WB01345_.gif (616 bytes)