Universidad Adventista de Centro Amrica

II Cuatrimestre
2015

Ing. del Software II

Licenciatura Cdigo: IS-593.

Profesor: Roberto Rodrguez.

Ttulo: Diagramas de Estructuras (DE).

Alumnos:
Julio Guerra, Misael Vallejos, Ramn Gonzlez Porras, Carlos Aguirre, Eduardo Martnez.

Julio 2015.

Contenido
Introduccin ...................................................................................................................................... 3
1. Antecedentes................................................................................................................................. 4
2. Definicin....................................................................................................................................... 4
3. Elementos ...................................................................................................................................... 5
3.1. Modulo ................................................................................................................................... 5
3.2. Relacin entre mdulos (Conexin o invocacin) .................................................................. 6
3.3 Comunicacin entre mdulos (Parmetro o cupla) ................................................................ 7
3.4 Otros componentes ................................................................................................................. 8
4. Estructura de diagrama ................................................................................................................. 8
5. Principios de diseo ....................................................................................................................... 9
6 Criterios de validacin de calidad ................................................................................................... 9
6.1 Acoplamiento .......................................................................................................................... 9
6.2 Cohesin ................................................................................................................................ 10
6.3 Descomposicin (Factoring) .................................................................................................. 10
6.3.1 Reducir el tamao del mdulo ....................................................................................... 10
6.3.2 Hacer el sistema ms claro ............................................................................................. 10
6.3.3 Minimizar la duplicacin de cdigo ................................................................................ 10
6.3.4 Separar el trabajo de la administracin ....................................................................... 11
6.3.5 Crear mdulos ms generales ........................................................................................ 11
6.4 Fan-Out .................................................................................................................................. 11
6.5 Fan-In ..................................................................................................................................... 11
7 Ejercicio de demostracin ............................................................................................................ 12
Conclusin ....................................................................................................................................... 15
Anexos ............................................................................................................................................. 16

Introduccin

1. Antecedentes
El diseo estructurado de sistemas se ocupa de la identificacin, seleccin y organizacin de los
mdulos y sus relaciones. Se comienza con la especificacin resultante del proceso de anlisis, se
realiza una descomposicin del sistema en mdulos estructurados en jerarquas, con
caractersticas tales que permitan la implementacin de un sistema que no requiera elevados
costos de mantenimiento.
La idea original del diseo estructurado fue presentada en la dcada de los '70, por Larry
Constantine, y continuada posteriormente por otros autores: Myers, Yourdon y Stevens.
El diseo estructurado es un enfoque disciplinado de la transformacin de qu es necesario para
el desarrollo de un sistema, a cmo deber ser hecha la implementacin.
La definicin anterior implica que: el anlisis de requerimientos del usuario (determinacin del
qu) debe preceder al diseo y que, al finalizar el diseo se tendr medios para la implementacin
de las necesidades del usuario (el cmo), pero no se tendr implementada la solucin al problema.
Cinco aspectos bsicos pueden ser reconocidos:
1. Permitir que la forma del problema gue a la forma de la solucin. Un concepto bsico del
diseo de arquitecturas es: las formas siempre siguen funciones.
2. Intentar resolver la complejidad de los grandes sistemas a travs de la segmentacin de un
sistema en cajas negras, y su organizacin en una jerarqua conveniente para la
implementacin.
3. Utilizar herramientas, especialmente grficas, para realizar diseos de fcil comprensin.
Un diseo estructurado usa diagramas de estructura (DE) en el diseo de la arquitectura
de mdulos del sistema y adiciona especificaciones de los mdulos y cuplas (entradas y
salidas de los mdulos), en un Diccionario de Datos (DD).
4. Ofrecer un conjunto de estrategias para derivar el diseo de la solucin, basndose en los
resultados del proceso de anlisis.
5. Ofrecer un conjunto de criterios para evaluar la calidad de un diseo con respecto al
problema a ser resuelto, y las posibles alternativas de solucin, en la bsqueda de la mejor
de ellas.
El diseo estructurado produce sistemas fciles de entender y mantener, confiables, fcilmente
desarrollados, eficientes y que funcionan.

2. Definicin
Los diagramas de estructura (DE) sirven para el modelamiento top-down de la estructura de control
de un programa descripto a travs de un rbol de invocacin de mdulos.
El objetivo de este diagrama es representar la estructura modular del sistema o de un componente
del mismo y definir los parametros de entrada y salida de cada uno de los modulos.
Un diagrama de estructura permite modelar un programa como una jerarqua de mdulos. Cada
nivel de la jerarqua representa una descomposicin ms detallada del mdulo del nivel superior.
La notacin usada se compone bsicamente de tres smbolos:

Mdulos.
Invocaciones o conexiones.
Cuplas o parmetros.

Ver anexo 1.

3. Elementos
Un diagrama de estructura se representa en forma de arbol con los siguientes elementos:

3.1. Modulo
Un modulo puede representar un programa, subprograma o rutina dependiendo del lenguaje a
utilizar. Admite parametros de llamada y retorno. En el disen o de alto nivel hay que ver un modulo
como una caja negra, donde se contemplan exclusivamente sus entradas y sus salidas y no los
detalles de la logica interna del modulo. Para que se reduzca la complejidad del cambio ante una
determinada modificacion, es necesario que los modulos cumplan las siguientes condiciones:
Que sean de pequen o taman o.
Que sean independientes entre s .
Que realicen una funcion clara y sencilla.
Desde un punto de vista prctico, un mdulo es una coleccin de instrucciones de un programa
con cuatro caractersticas bsicas:
Entradas y Salidas: lo que un mdulo recibe en una invocacin y lo que retorna como
resultado.
Funcin: las actividades que un mdulo hace con la entrada para producir la salida.
Lgica Interna: por la cual se ejecuta la funcin.
Estado Interno: su rea de datos privada, datos para los cuales slo el mdulo hace
referencia.
Las entradas y salidas son, respectivamente, datos que un mdulo necesita y produce. Una funcin
es la actividad que hace un mdulo para producir la salida. Entradas, salidas y funciones proveen
una visin externa del mdulo. La lgica interna son los algoritmos que ejecutan una funcin, esto
es, junto con su estado interno representan la visin interna del mdulo.
Un mdulo es diseado como una caja, su funcin es representada por un nombre en el interior y
las entradas y salidas de un mdulo son representadas por pequeas flechas que entran y salen
del mdulo.

Mdulo

S
M

Un mdulo es una caja negra conteniendo una coleccin de

instrucciones y reas de datos locales. Los mdulos tienen una
funcin, definida por el nombre contenido en el interior (M),
datos de entrada y datos de salida generados por la aplicacin
de la funcin a los datos de entrada.

Notacion
Se representa mediante un rectangulo con su nombre en el interior.

Un modulo predefinido, es aquel modulo que esta disponible en la

biblioteca del sistema o de la propia aplicacion, y por tanto no es necesario
codificarlo. Se representa an adiendo dos l neas verticales y paralelas en el
interior del rectangulo.

3.2. Relacin entre mdulos (Conexin o invocacin)

En la realidad, los mdulos no son realmente cajas negras. Los diagramas de estructura muestran
las invocaciones que un mdulo hace a otros mdulos. Estas invocaciones son diseadas como una
flecha que sale del mdulo llamador y apunta al mdulo llamado.

El mdulo A invoca (o llama) a los mdulos B, C y D. La interpretacin de las invocaciones provee

informacin de la estructura interna del mdulo llamador, que no concuerda con la idea de caja
negra. Una caja negra no permite que se observe su interior y, las invocaciones que un mdulo
hace son componentes de su estructura interna. De todas formas, se dice que un mdulo es una
caja casi negra o caja gris porque ella permite que se observe solo las invocaciones.
Los diagramas de estructura no tienen especificado el orden de invocacin de los mdulos
invocados. El orden de dibujo de los mdulos B, C, y D (de izquierda a derecha) no debe ser
interpretado como el orden de invocaciones ejecutado por el mdulo
A. Ese orden puede ser cambiado, al dibujar, para evitar que se crucen flechas o se dupliquen
mdulos. A pesar que el orden de invocacin de los mdulos del mismo nivel en un diagrama de
estructura, no es especificado por el formalismo, se recomienda que siempre que fuese posible, se
siga un orden de izquierda a derecha (si esto no produce que se crucen flechas) que se corresponde
con el orden de invocacin, y permitiendo un orden de lectura que es patrn en la mayora de los
idiomas.

Invocacin
Estndar

El mdulo A invoca al mdulo B con la semntica de

invocacin de procedimientos o funciones en los lenguajes
de programacin convencionales (C, Pascal, etc.).

Notacin
Se representa mediante una l nea terminada en punta de flecha cuya direccion indica el modulo
llamado. Para llamadas a modulos estaticos se utiliza trazo continuo y para llamadas a modulos
dinamicos trazo discontinuo.

3.3 Comunicacin entre mdulos (Parmetro o cupla)

Informacion que se intercambia entre los modulos. Pueden ser de dos tipos en funcion de la clase
de informacion a procesar:
Control: son valores de condicion que afectan a la logica de los modulos llamados.
Sincronizan la operativa de los modulos.
Datos: informacion compartida entre modulos y que es procesada en los modulos
llamados.

Cuando una funcin o un procedimiento, en un lenguaje convencional, es invocado,

comnmente un conjunto de argumentos es comunicado y, en el caso de las funciones,
tambin se espera que retorne un resultado. Estos datos comunicados en una invocacin
son modelados por medio de flechas, sobre el smbolo de invocacin, llamadas cuplas.

Existen varios tipos de cuplas, basado en lo que ellas pueden producir en el mdulo receptor, las
cuales se describen a continuacin:
Tipos de Cuplas
Cupla de
Datos

Una cupla de datos transporta datos puros a un mdulo. No es necesario conocer la

lgica interna del mdulo receptor, para de- terminar los valores vlidos de la cupla (ej.:
nmero de cuenta, saldo, tabla de movimientos).

Con una flecha doble (apuntando al mdulo llamador y al mdulo llamado) se especifica
Cupla
Modificada un argumento enviado a un mdulo que deber modificar su valor, fijando un nuevo valor
disponible para el mdulo llamador (en la implementacin, se precisar que el lenguaje
posea un mecanismo de pasaje de parmetros por referencia) (ej.: el buffer enviado a un
mdulo de lectura de un archivo).
Cupla de
Resultados

Existen mdulos que retornan valores sin la necesidad de que estn inicializados en el
momento que se invocan. Estos casos son dos:
1. Cuplas similares al tipo Modificada cuyos valores previos a la invocacin del mdulo
NO se utilizan para calcular el valor de retorno. Si bien en Pascal se implementa como
las Cuplas Modificadas, es conveniente documentarlas en el DE como de
Resultados por cuestiones de claridad.
2. Si el Mdulo en cuestin es una funcin (retorna un valor), se debe documentar este
valor de retorno como Cupla de Resulta- do cuyo nombre se corresponder con el
nombre de la funcin.

Notacin
La representacion var a segun su
tipo: control (flags) o datos.

3.4 Otros componentes

Otros componentes que se pueden representar en el diagrama de estructura son:
Almacen de datos: es la representacion f sica del lugar donde estan almacenados los datos
del sistema.

Dispositivo f sico: es cualquier dispositivo por el cual se puede recibir o enviar informacion
que necesite el sistema.

4. Estructura de diagrama
Existen ciertas representaciones graficas que permiten mostrar la secuencia de las llamadas entre
modulos. Las posibles estructuras son:

Secuencial: un modulo llama a otros

modulos una sola vez y, se ejecutan de
izquierda a derecha y de arriba abajo.

Repetitiva: cada uno de los modulos

inferiores se ejecuta varias veces mientras se
cumpla una condicion.

Alternativa: cuando el modulo superior, en

funcion de una decision, llama a un modulo u
otro de los de nivel inferior.

5. Principios de diseo
El diagrama de estructura se basa en tres principios fundamentales:
La descomposicion de los modulos, de manera que los modulos que realizan multiples
funciones se descompongan en otros que solo realicen una. Los objetivos que se persiguen
con la descomposicion son:
Reducir el taman o del modulo.
Hacer el sistema mas facil de entender y modificar y por lo tanto facilitar el
mantenimiento del mismo.
Minimizar la duplicidad de codigo.
Crear modulos utiles.
La jerarqu a entre los modulos, de forma que los modulos de niveles superiores coordinen
a los de niveles inferiores. Al dividir los modulos jerarquicamente, es posible controlar
el numero de modulos que interactuan con cualquiera de los otros.
La independencia de los modulos, de manera que cada modulo se ve como una caja
negra, y nicamente es importante su funcin y su apariencia externa, y no los detalles de
su construccin.

6 Criterios de validacin de calidad

Los diagramas de estructura son simplemente una herramienta para modelar los mdulos de un
sistema y sus relaciones y, junto con las especificaciones de funcionalidad de los mdulos y las
estructuras de datos de las cuplas, componen un diseo inicial que deber ser analizado y
mejorado.
Uno de los principios fundamentales del diseo estructurado es que un sistema grande debera
particionarse en mdulos ms simples. Sin embargo, es vital que esa particin sea hecha de tal
manera que los mdulos sean tan independientes como sea posible y que cada mdulo ejecute
una nica funcin. Para que los diseos tengan esas cualidades, son necesarios algunos criterios
de medicin que permitan clasificar y mejorar los diagramas de estructura. A continuacin se
describen los criterios utilizados para mejorar un diseo.

6.1 Acoplamiento
El acoplamiento entre mdulos clasifica el grado de independencia entre pares de mdulos de un
DE. El objetivo es minimizar el acoplamiento, es decir, maximizar la independencia entre mdulos.
A pesar de que el acoplamiento, es un criterio que clasifica caractersticas de una invocacin (una
relacin existente entre dos mdulos), ser usado para clasificar un DE completo. Un DE se
caracteriza por el peor acoplamiento existen- te entre pares de sus mdulos, ya que ese es el
problema que debe ser resuelto para me- jorar la calidad del DE completo.
Un bajo acoplamiento indica un sistema bien particionado y puede obtenerse de tres maneras:
Eliminando relaciones innecesarias: Por ejemplo, un mdulo puede recibir algunos datos,
innecesarios para l, porque debe enviarlos para un mdulo subordinado.
Reduciendo el nmero de relaciones necesarias: Cuanto menos conexiones existan entre
mdulos, menor ser la posibilidad del efecto en cadena (un error en un mdulo aparece
como sntoma en otro).
Debilitando la dependencia de las relaciones necesarias: Ningn mdulo se tiene que
preocupar por los detalles internos de implementacin de cualquier otro. Lo nico que
tiene que conocer un mdulo debe ser su funcin y las cuplas de entrada y salida (cajas
negras).

6.2 Cohesin
Otro medio para evaluar la particin en mdulos (adems del acoplamiento) es observar como las
actividades de un mdulo estn relacionadas unas con otras; este es el criterio de cohesin.
Generalmente el tipo de cohesin de un mdulo determina el nivel de acoplamiento que tendr
con otros mdulos del sistema.
Cohesin es la medida de intensidad de asociacin funcional de los elementos de un mdulo. Por
elemento debemos entender una instruccin, o un grupo de instrucciones o una llamada a otro
mdulo, o un conjunto de procedimientos o funciones empaquetados en el mismo mdulo.
El objetivo del diseo estructurado es obtener mdulos altamente cohesivos, cuyos elementos
estn fuerte y genuinamente relacionados unos con otros. Por otro lado, los elementos de un
mdulo no deberan estar fuertemente relacionados con elementos de otros mdulos, porque eso
llevara a un fuerte acoplamiento entre ellos.

6.3 Descomposicin (Factoring)

La descomposicin es la separacin de una funcin contenida en un mdulo, para un nuevo
mdulo. Puede ser hecha por cualquiera de las siguientes razones.

6.3.1 Reducir el tamao del mdulo

La descomposicin es una manera eficiente de trabajar con mdulos grandes. Un buen tamao
para un mdulo es alrededor de media pgina (30 lneas). Ciertamente, toda codificacin de un
mdulo debera ser visible en una pgina (60 lneas).
La cantidad de lneas no es un patrn rgido, otros criterios para determinar cuando es conveniente
terminar de realizar la descomposicin, son los siguientes:
Funcionalidad: Terminar de realizar la descomposicin cuando no se pueda encontrar una
funcin bien definida. No empaquetar lneas de cdigo dispersas, de otros mdu- los,
porque probablemente juntas podrn formar mdulos con mala cohesin.
Complejidad de Interfaz: Terminar de realizar la descomposicin cuando la interfaz de un
mdulo es tan compleja como el propio mdulo. Un mdulo de mil lneas es muy confuso,
mas mil mdulos de una lnea son an ms confusos.

6.3.2 Hacer el sistema ms claro

La descomposicin no debera ser hecha de una manera arbitraria, los mdulos resul- tantes de la
descomposicin de un mdulo deben representar sub-funciones del mdulo de mas alto nivel en
el DE.
En una descomposicin no se debe preocupar por conceptos de programacin. Si una sub-funcin,
presentada como un mdulo separado permite una mejor comprensin del diseo, puede ser
subdividida, an cuando, en una implementacin, el cdigo del mdu- lo sea programado dentro
del mdulo jefe.

6.3.3 Minimizar la duplicacin de cdigo

Cuando se reconoce una funcin que puede ser reutilizada en otras partes del DE, lo mas
conveniente es convertirla en un mdulo separado. As, se puede localizar mas fcilmente las
funciones ya identificadas y evitar la duplicacin del mismo cdigo en el interior de otro mdulo.
De esta manera, los problemas de inconsistencia en el mantenimiento (si esa fun- cin debe ser
modificada) pueden ser evitados, y se reduce el costo de implementacin.

6.3.4 Separar el trabajo de la administracin

Un administrador o gerente de una compaa bien organizada debera coordinar el tra- bajo de los
subordinados en lugar de hacer el trabajo. Si un gerente hace el trabajo de los subordinados no
tendr tiempo suficiente para coordinar y organizar el trabajo de los su- bordinados y, por otro
lado, si hace el trabajo los subordinados no seran necesarios. Lo mismo se puede aplicar al diseo
del DE, relacionado a los mdulos de Trabajo (edicin, clculo, etc.) y a los mdulos de Gerencia
(decisiones y llamadas para otros mdulos).
El resultado de este tipo de organizacin es un sistema en el cual los mdulos en los niveles medio
y alto de un DE son fciles de implementar, porque ellos obtienen el tra- bajo hecho por la
manipulacin de los mdulos de los niveles inferiores.
La separacin del trabajo de la administracin mejora la mantenibilidad del diseo. Una alteracin
en un sistema es: un cambio de control o un cambio de trabajo, pero ra- ramente ambos.

6.3.5 Crear mdulos ms generales

Otra ventaja de la descomposicin es que, frecuentemente, se pueden reconocer m- dulos ms
generales y, as, ms tiles y reutilizables en el mismo sistema y, adems, pueden ser generadas
bibliotecas de mdulos reutilizables en otros sistemas.

6.4 Fan-Out
El fan-out de un mdulo es usado como una medida de complejidad. Es el nmero de subordinados
inmediatos de un mdulo (cantidad de mdulos invocados).

Si un mdulo tiene un fan-out muy grande, entonces compone el trabajo de muchos mdulos
subordinados y, casi con certeza, tiene toda la funcionalidad no trivial representada por ese
subrbol en el DE.
Para tener acotada la complejidad de los mdulos se debe limitar el fan-out a no ms de siete ms
o menos dos (7 2). Un mdulo con muchos subordinados puede fcil- mente ser mejorado por
descomposicin.

6.5 Fan-In
El fan-in de un mdulo es usado como una medida de reusabilidad, es el nmero de superiores
inmediatos de un mdulo (la cantidad de mdulos que lo invocan).

Un alto fan-in es el resultado de una descomposicin inteligente. Durante la programacin, tener

una funcin llamada por muchos superiores evita la necesidad de codificar la misma funcin varias
veces. Existen dos caractersticas fundamentales que deben ser garantizadas en mdulos con un
alto fan-in:
Buena Cohesin: Los mdulos con mucho fan-in deben tener alta cohesin, con lo cual es
muy probable que tengan buen acoplamiento con sus llamadores.
Interfaz Consistente: Cada invocacin para el mismo mdulo debe tener el mismo nmero
y tipo de parmetros. En el ejemplo que sigue, hay un error.

7 Ejercicio de demostracin
Problema: El sistema ABControl tiene como propsito llevar un control de cada uno de las
solicitudes de suministros internas de la empresa XYZ que actualmente tiene un sistema
rudimentario para llevar a cabo esta tarea. XYZ quiere que el sistema permita que la gerencia pueda
tener conocimiento en el momento justo que se deba proveer o adquirir los suministros para cada
departamento.
Este sistema deber tener un mdulo de solicitudes en el cual se realizaran todas las solicitudes
internas de suministros, tambin un mdulo de aprobacin de solicitudes que aprobara o denegara
cada una dependiendo de lo que tenga en existencia el inventario del Sistema, si existen los
artculos solicitados, se aprueba la solicitud y se descuentan los suministros del inventario, y si no
existen los artculos, se tendr que realizar un pedido el cual tendr que ser aprobado de acuerdo
al criterio del Contador de la empresa, con la informacin de los suministros necesitados, su
respectivo proveedor y precios.

Solucin:

Conclusin

Anexos
1- Ejemplo de un Diagrama de Estructura.