236 INGENIERA DEL SOFTWARE.

UN ENFOQUE PRCTICO Se han desarrollado diferentes lenguajes de descripcin arquitectnica (LDA) para representar los modelos mencionados anteriormente [SHA95b|. Aunque se han propuesto muchos LDA diferentes, la mayora proporcionan mecanismos para describir componentes de sistema y la manera en que se conectan unos con otros.

13.4.5. Jerarqua de control

La jerarqua de control, tambin denominada estructura del programa, representa la organizacin (a menudo jerrquica) de componentes del programa (mdulos) e implica una jerarqua de control. No representa aspectos procedimentales del software tales como secuencias de procesos, ocurrencia/orden de decisiones o repeticin de operaciones. Se usan muchas notaciones diferentes para representar la jerarqua de control. La ms comn es el diagrama en rbol (Figura 13.3) que representa la jerarqua. Sin embargo, otras notaciones, tales como los diagramas Warnier-

- FIGURA 13.3 Terminologa de la estructura

Orr |ORR77] y Jackson [JAC83] pueden usarse con igual efectividad6. Para facilitar estudios posteriores de la estructura, definimos unas pocas simples medidas y trminos. En la Figura 13.3, profundidad y anchura proporcionan una indicacin del nmero de niveles de control y el mbito global de control, respectivamente. El grado de salida es una medida del nmero de mdulos

que son controlados directamente por otro mdulo. El grado de entrada indica cuntos mdulos controlan directamente un mdulo dado. La relacin de control entre los mdulos se expresa de la siguiente manera: un mdulo que controla otro mdulo se dice que es superior a l; inversamente, un mdulo controlado por otro se dice que es subordinado del consolador [ YOU79], Por ejemplo, como se muestra en la Figura 13.3, el mdulo M es superior a los mdulos a,h y c. El mdulo h es subordinado del mdulo e y finalmente sera subordinado de M. Las relaciones horizontales en anchura (p. ej.: entre los mdulos d y e), aunque se pueden expresar en la prctica, no hacen falta definirlas con una terminologa explcita. La jerarqua de control tambin representa dos caractersticas sutilmente diferentes de la arquitectura del software: visibilidad y conectividad. La visibilidad indica el conjunto de componentes de programa que pueden invocarse o usarse sus datos por un componente dado, incluso cuando esto se realiza indirectamente. Por ejemplo, un mdulo en un sistema orientado a objetos puede tener acceso a un amplio abanico de atributos de datos que haya heredado, pero slo utiliza unos pocos de estos atributos de datos. Todos los atributos son visibles para el mdulo. La conectividad indica el conjunto de componentes que son invocados directamente o usados sus datos por un componente determinado. Por ejemplo, un mdulo que causa directamente que otro empiece la ejecucin, est conectado con l .

13.4.6. Particin estructural

La estructura del programa debera partirse tanto horizontalmente como verticalmente. Como se muestra en la Figura 13.4a, la particin horizontal define ramas separadas de la jerarqua modular para cada funcin principal del programa. Los mdulos de control, representados con un sombreado ms oscuro, se usan para coordinar la comunicacin entre ellos y la ejecucin de

Para los diseos orientados a objelos (Captulo 21), el concepto de estructura de programa es menos obvio. En el Captulo 19, exploramos el concepto de la herencia en el software orientado a objetos. Un componente de programa puede heredar una lgica de control y/o datos.de otro componente sin referencia explcita en el cdigo fuente. Los componentes de esta clase seran visibles, pero no estaran directamente conectados. La Figura ! 3.3 indica la conectividad de mdulos de programa.

wmmm s US!

mtodo de diseo con respecto a su capacidad de definir un sistema modular eficaz: Capacidad de descomposicin modular. Si un mtodo de diseo proporciona un mecanismo sistemtico de descomposicin del problema en subproblemas, reducir la complejidad del problema global, consiguiendo, por tanto, una solucin modular eficaz. Capacidad de empleo de componentes modulares. Si un mtodo de diseo permite ensamblar componentes de diseo existentes (reutiliza- bles) en un nuevo sistema, proporcionar una solucin modular que no invente nada ya inventado.

FSS1
rMIttJ

Capacidad de comprensin modular. Si se puede entender un mdulo como - ne o nc ihi rpni una unidad por s sola (sin

jitrvc 1 rjp] sistema

referencias a otros mdulos) ser ms fcil de construir y de cambiar. Cntinuidad modular. Si pe :ostes) para desadida que crece el sitos, ms mdubargo, a medida iados con la inte- an a una curva de lulos que resultaifisticacin necejna til directriz :ar, pero hay que modularizar de le M ? Cunto ireguntas requiems adelante en a modularidad. o? La respuesta lentro de unsisiten evaluar un provocan cambios en los mdulos individuales, en vez de cambios generalizados en el sistema, se minimizar el impacto de los efectos secundarios de los cambios. Proteccin modular. Si se da una condicin aberrante dentro de un mdulo y los efectos se restringen dentro de ese mdulo, se minimizar el impacto de los efectos secundarios de los errores. Finalmente, es importante resaltar que un sistema puede disearse modularmente, aunque su implementacin deba ser monoltica. Hay situaciones (p. ej.: software de tiempo real, software empotrado) en que es inaceptable la introduccin de una relativamente mnima sobrecarga de velocidad y de memoria (p. ej.: subrutinas. procedimientos). En tales situaciones el software puede y debera disearse con modularidad como filosofa predominante. El cdigo se puede desarrollar en lnea. Aunque el cdigo fuente del programa no parezca modular a primera vista, se ha mantenido la filosofa y el programa proporcionar los beneficios de un sistema modular.

13.4.4. Arquitectura del software

La arquitectura del software alude a laestructura global deLsofl-w-ate y-las manfiras fn qn IT fin Pfltrnrtum pr"pprr'"n? jntP<jrtlarl_r-rmrpptiiaLa iin-cictP. ma [SHA95a]. En su forma ms simple, la arquitectura es la estructura jerr, quica de los componentes del programa (mdulos), la manerq tlf intpra^tuflr de estos componentes, y la estructura de los datos usados por estos compn- nenles. En un sentido ms amplio, sin embargo, los componentes pueden

generalizarse para representar los elementos principales del sistema y sus interacciones5. Un objetivo del diseo del software es crear una vendn arquitectnica de un sistema. Esta versin sirve como estructura desde la que se pueden llevar a cabo actividades de diseo ms detalladas. Un conjunto de estructuras arqmtprfnpjpi; pprmite jnpfnifrP rlpl ynftw!lrp rpntil7ar rnpfgpfns q nivel diseo. /Shaw y Garlan |SHA95a] describen un conjunto de propiedades que debelan especificarse como parte de un diseo arquitectnico: /^Propiedades estructurales. Este aspecto de la representacin del diseo I arquitectnico define los componentes de un sistema (p. ej.: mdulos, objetos, filtros) y la manera en*que se empaquetan estos componentes e \ interactan los unos con los otros.,Por ejemplo, los objetos se empaquetan \ para encapsulaD> tanto los datos como el proceso que manipula los datos \ y para interactuar a travs de la invocacin de mtodos (Captulo 19). I Propiedades extra-funcionales. La descripcin del diseo arquitectnico debera ocuparse de cmo consigue la arquitectura del diseo los requisi- / tos de rendimiento, capacidad, fiabilidad, seguridad, adaptabilidad y otras / caractersticas del sistema. \ Familias de sistemas relacionados. El diseo arquitectnico debera \ dibujarse con estructuras imagen de as que se encuentran comnmente en / el diseo de familias de sistemas similares. En definitiva, el diseo debera tener la capacidad de utilizar bloques de construccin arquitectnica ' / reutilizados. V Dada la especificacin de estas propiedades, el diseo arquitectnico puede representarse usando uno o ms modelos diferentes [GAR95], Los modelos estructurales representan la arquitectura como una_colecin organizjdajjecomponentTs!ife_programa. Los modelos de estructuras aumentan el nivel de abstraccin de diseo intentando ident ifai estructu ras-dediseo arquitectnico repetibles (patrones) quej^j5ue.dn RGefrtfF-eflpQS simila- res de aplicaciones. Los modelos dinmicos tratan los aspectos del comporta-

^tnirtnra " lci gr,"fin,r"'irn dfl -;i';tpmn pn fnnriniie arontfrimifMtr"! esleaos* I ns modp[nc rlr prnrarn rp rnnrpntnn pn f | ffie.o del negorQ n PrnCP.so tcnico que, rie|-ifi tpnpr pl ci<;tpfn^ Finnlmpn;p los modelos funCQnales pnedeiLUSarse- para -repre sentar.jajerargua funcional de un sistema.
Por ejemplo, los componentes arquitectnicos de un sistema cliente/servidor se representan a diferentes niveles de abstraccin. Vea el Captulo 28 para ms detalle.

fHaxRHlSK

eri MlalS

sin tener en cuenta ;edimiento del soft- mdulo individualn exacta del proce- , puntos exactos de in / estructura de los el procedimiento. El na referencia a todos decir, una represen- corno se ilustra en la

Procedimiento para el mdulo superior

Procedimient o7 para el mdulo subordinado

>s del software a una ilucin software para de ocultamiento de etericen por decisio- ns. Con otras pala- a que la informacin lio sea inaccesible a

Procedimiento para el ltimo mdulo subordinado

13.5. DISEO MODULAR EFECTIVO

Los conceptos fundamentales del diseo descritos en la seccin anterior sirven para incentivar diseos modulares. De hecha la modularidad se ha convertido en un enfoque admitido en todas las disciplinas de la ingeniera. Un diseo modular reduce la complejidad (ver la Seccin 13.4.3), facilita los cambios ( un aspecto crtico de la capacidad de

i modularidad eficaz ; se comunican entre cin del software. La 2S (o de informacin) erza las restricciones ulo como a cualquier 75], diseo para sistemas se requieren modifimtenimiento del soft- estn ocultos a otras )s durante las modifi- lel software.

mantenimiento del software), yhaee ms fcil la implementacin al fomentar el desarrollo en paralelo de diferentes partes de un sistema.

13.5.1. Independenc ia funcional

El concepto de independencia funcional es un producto directo de la modularidad y de los conceptos de abstraccin y ocultamiento de informacin. En referencias obligadas sobre el diseo del software, Pamas [PAR72] y Wirth [WIR71 ] aluden a tcnicas de refinamiento que mejoran la independencia del mdulo. Trabajos posteriores de Stevens, Wyers y Constantine [STE74] consolidaron el concepto. La independencia funcional se consigue desarrollando mdulos con una funcin nica y una aversin

a excesiva interaccin con otros mdulos. Dicho de otra manera queremos disear software de manera que cada mdulo trate una subfuncin especfica de los requisitos y tenga una sencilla interfaz cuando se vea <iesde otras partes de la estructura del programa. Es justo preguntarse por qu es importante la independencia. El software con una mdutaridad efectiva (p. ej.: mdulos independientes), es ms fcil de desarrollar porque la funcin se puede compartimentar y las interfaces se simplifican (considere las ramificaciones cuando el

desarrollo se hace en equipo). Los mdulos independientes son ms fciles de mantener (y probar) porque los efectos secundarios causados por la modificacin del diseo/cdigo estn limitados, la propagacin de errores es reducida y se pueden usar mdulos reutilizados. En resumen, la independencia funcional es la clave para un buen diseo y el diseo es la clave de la calidad del software. La independencia se mide usando dos criterios cualitativos: cohesin y acoplamiento. La cohesin es una medida de la fuerza relativa funcional de un mdulo. El

acoplamiento es una medida de la interdependencia relativa entre los mdulos. (rs^TCohesin

a rr.hpsjr)

extensin natnr?| ffel mpreptp fie ocultacin dp. informa cin descrito en la Scc.cin-13.4.9. Un mdulo con cohesin realiza nna sola tareadentre d un procedimiento software, requiriendo poca interaccin con log prorprlimipntos qiif sp rp-.il7an pn otras partpc HpI programa Dicho de maera senrjlla, nn mHijlo ron cohesin debera (jrlp;)|mpntp) harpr tinaco)1 cosa. La cohesin puede represp1ntnrs'? romo un p^peclro^no^lrarl

o pn ta Figura 13.6. Siempre debemos bustla eohesin insjllta.,_aunque la parle media del espectro pv menudo mvplahlr _La escala de la cohesin no es lineal.. Es decir, la parte baja de la cohesin es mucho peor que el rango medio1 que es casi tan bueno como.IZmISSrfajil gfageweaia- En la prctica, un diseador no debe preo&uparse de categorizar la cohesin en un mdulo

240 INGENIER A DEL SOFTWARE. UN ENFOQUE PRCTICO

F I G U

R A

1 3 . 6

f C o h e s i n ,
na medida de la fuerza funcionaf relativa de un mdulo1U

* ^MiMSi'lft'?' f. "^iTl^^^^^^^t e&^&JiffflSa ^fe cowMtedfin.'fVy< Fi|Ss^ajg|

ffii Baia 11 lHft 11

E 1

iijSflj |U f|

especfico. Ms bien, debera entenderse el concepto global y evitar niveles inferiores de cohesin cuando se disean los mdulos. Para ilustrar (de forma algo irnica) la parte baja del espectro, relatamos la siguiente historia: A finales de los aos 60 lu mayor a de los gestore s de CPD empeza ron a darse

cuenta del valor de la modula ridad. Desgra ciadam ente muchos de los programas existent es eran de un bloque (p. ej.: 20.000 lneas de Fortran sin documentar con una subruti na de 2.500 lneas!) . Para transfor mar un progra ma de comput adora grande a la ltima tecnolo

ga, un gestor pidi a su persona l que modula rizaran el progra ma. Adem s, haba que hacerlo en su tiempo libre. Co ntra la espada y la pared, un miembr o de la plantill a pregunt (inocen -. tement e) la longitu d adecua da de un mdulo . Setent

a y cinco lneas de cdigo. ue la respues ta. Consig ui un lpiz rojo y una regla, midi la distanci a lineal que ocupab an 75 lneas de cdigo fuente y dibuj una lnea roja en el listado fuente, y despu s otra y otra. Cada lnea indicab a el

lmite de un mdulo . Esta tcnica es justo lo que se dice desarro llar softwar e con increbl e cohesin! Un mdulo que realiza un conjunto de tareas poco relacionadas las unas con las otras, si es que tienen algo que ver, se denomina coincidentalm ente cohesivo. Un mdulo que realiza tareas relacionadas lgicamente (p. ej.: un mdulo que produce toda las salidas independiente mente del upo) es de cohesin

lgica. Cuando un mdulo contiene tareas relacionadas por el hecho de que todas deben hacerse en el mismo intervalo de tiempo, este mdulo pre- ) senta cohesin temporal. f ' Como ejemplo de poca cohesin, considere un mdulo que realiza el pro- \ cesamiento de errores de un paquete de anlisis de ingeniera. El mdulo es j invocado cuando los datos calculados exceden de unos lmites preestableci- J dos. Realiza las siguientes tareas: (1) calcula datos suplementarios basndose

en los datos calculados originalmente; (2) produce un informe del error (con contenido grfico) en la estacin de trabajo del usuario; (3) realiza los siguientes clculos pedidos por el usuario; (4) actualiza una base de datos; y (5) activa un men de seleccin para el siguiente procesamiento. Aunque las tareas anteriores estn poco relacionadas, cada una es una entidad1 funcional independiente que podra realizarse mejor como un mdulo separado. El combinar las funciones en un solo mdulo nicamente puede servir para aumentar la probabilidad de

propagacin de errores cuando se hace una modificacin a alguna de las tareas procedimentales mencionadas anteriormente. . i' Los niveles moderados de cohesin estn relativamente cerca unos de otrgs en la escala de independencia modular. Cuando los elementos de procesamiento de un mdulo estn relacionados y deben ejecutarse en un orden especfico, existe cohesin procedimental. Cuando todos los elementos de procesamiento se concentran en un rea de la estructura de datos, tenemos presente la cohesin de comunicacin. Una cohesin alta

se caracteriza por un mdulo que realiza una nica tarea. Como ya hemos dicho anteriormente, no es necesario determinar el nivel preciso de cohesin. Ms bien, lo importante es intentar conseguir una alta cohesin y reconocer cuando hay poca cohesin para modificar el diseo del software y conseguir una mayor independencia funcional.

FK3URA 13.7
Acoplamiento Un* Sin
acoplamiento Ac-

Baja

tura. Se da una va to de marca (stam argumentos simpl ocurre entre los m A niveles modi trol entre los mdi El acoplamieitt del software y se r

13.5.3. Acoplamiento
El acoplamiento es una medida de la interconexin entre los mdulos de una estructura de programa. Al igual que la cohesin, el

acoplamiento puede represe ntarse en un espectro comojguestraja Figura 13.7. El acoplamiento depen- de_de la Crnplejidad de lajnteifaz entre los mdulos, el punto en el que se entra o sej3ace.xefererici a al mdulo y qu datos pasan a travs de la interfaz. En el diseo del software, intentamos conseguir el menor nivel posible de acoplamiento. Las conexiones sencillas entre los mdulos hacen que el soft- ware sea ms fcil de entender y menos dado al efecto ola [STE74] causado cuando ocurren errores en un lugar y se propagan a travs del sistema.

La Figura 13.8 proporciona ejemplos de diferentes tipos de acoplamiento de mdulo. Los mdulos a y d son subordinados a mdulos diferentes. Ninguno est relacionado y por tanto no ocurre ningn acoplamiento directo. El mdulo c est subordinado al mdulo a y se accede a l por medio de una lista convencional de argumentos a travs de la cual se pasan los datos. Mientras est presente una sola lista de argumentos (p. ej.: se pasan datos simples; existe una correspondencia de elementos uno a uno), se presenta un bajo acoplamiento (acoplamiento de

FIGURA 13.8 Tipos de acoplas:

Estructura de datos

datos en el espectro) en esta porcin de la estruc-

FIGURA 13-.7 ; _ __ /;' ' _ ."fri'^fM'y : ES PSl Slfp p mm

interdependencia entre los. mdulos del software Acoplamiento de marca Acoplamiento externo Acoplamiento de contenido Acoplamiento de control/ Acoplamient normal

ame Sin

directo

acoplamiento

7 r . f j

jL

i11-I-I uni.:

tura. Se da una variante del acoplamiento de datos, denominado acoplamiento de marca (slump), cuando una porcin de la estructura de datos (en vez de argumentos simples) se pasa a travs de la interfaz del mdulo. Esto es lo ocurre entre los mdulos h y a.

A : del error (con (3) realiza los ase de datos; y to. ida una es una orno un mducamente puede ares cuando se :s mencionadas cerca unos entos procese en orden elementos datos, tenemos caracteriza por de de un s de

erminar el nivel iseguir una alta :ar el diseo del niveles moderados, el acoplamiento se caracteriza por el paso del control entre los mdulos. El acoplamiento de control es muy comn en la mayora de los diseos del software y se muestra en la

Figura 13.8, donde se pasa un indicador de

FIGURA 13.8

"mdulos de una tnto puede repreilamiento depennto en el que se s de la interfaz. nivel posible de acen que el soft[STE74] causa- s del sistema. de acoplamiento ; diferentes. Niniento directo. El or medio de una i los datos. Mienan datos simples; enta un bajo acocin de la estruc-

Tipos de acoplamiento
V; Sin ''acoplamientos directo

III
(variable s) Datos

fp lljfe& SK^fi t^jpp BIS lili Bill

control (una variable que controla las decisiones en un mdulo subordinado o superior) entre los mdulos d y e. Cuando los mdulos estn atados a un entorno extemo al software se dan niveles relativamente altos de acoplamiento. Por ejemplo, la I/C)(Entrada/SaIida) acopla un mdulo a dispositivos, formatos y protocolos de comunicaciones especficos. El acoplamiento externo es esencial, pero debera limitarse a unos pocos mdulos en una estructura. Tambin aparece un acoplamiento alto cuando varios mdulos hacen referencia a un rea global de (fetos. El acoplamiento comn, tal como se denomina este modo, se muestra en la Figura 13.8. Los mdulos c, g y k acceden a elementos de datos de un rea global de datos (p. ej.: un archivo de disco, Fortran COMMON, tipos de datos externos en el lenguaje de programacin C). El mdulo c inicializa el elemento. Ms tarde el mdulo g recalcula y actualiza el elemento. Xsumamos que ocurre un error y que # actualiza el elemento incorrectamente. Mucho
o

mas adelante en el procesamiento, el mdulo k lee el elemento, intenta procesarlo y falla, haciendo que aborte el software. La causa aparente del aborto es el mdulo k y la causa real, el mdulo g. El diagnstico de problemas en estructuras con un acoplamiento comn es costoso en tiempo y es difcil. Sin embargo, esto no significa necesariamente que el uso de datos globales sea malo. Significa que el diseador del software debe ser consciente de las potenciales consecuencias del acoplamiento comn y tener especial cuidado de prevenirse de ellos. El grado ms alto de acoplamiento, acoplamiento de contenido, ocurre cuando un mdulo hace uso de datos o de informacin de control mantenidos dentro de los lmites de otro mdulo. El acoplamiento de contenido tambin puede ocurrir cuando se realiza una bifurcacin hacia la mitad de un mdulo. Este modo de acoplamiento puede y debe evitarse. Los modos de acoplamiento tratados anteriormente ocurren por decisiones de diseo tomadas durante el desarrollo de la estructura del programa. Sin embargo, se pueden introducir variantes del acoplamiento externo durante la codificacin. Por ejemplo, el compilar acopla el cdigo fuente con atributos especficos (y a menudo no estndares) del compilador; el acoplamiento del sistema operativo (SO) se produce por la vinculacin del diseo y del cdigo resultante con servicios del sistema operativo, que pueden causar estragos cuando se hagan cambios en el SO.

13.6. HEURSTICAS DE DISEO PARA UNA MODULARIDAD EFECTIVA

Una vez desarrollada la estructura del programa, se puede conseguir una modularidad efectiva aplicando los conceptos de diseo introducidos ante-

242 INGENIERA DEL SOFTWARE. UN ENFOQUE PRCTICO

riormente en este captulo. La arquitectura del programa se manipula de acuerdo

con un conjunto de heursticas (directrices o consejs) que se presentan en esta seccin. I.Evaluar la primera iteracin de la estructura del programa para rducir el acoplamiento y mejorar la cohesin. Una vez que se ha desarrollado la estructura del programa, se puede explosionar o implosionar los mdulos con vistas a mejorar la independencia del mdulo. Un mdulo explosionado se convierte en dos o ms mdulos en la estructura final del programa. Un mdulo implosionado (de agregacin) es el resultado de combinar el procesamiento implicado en dos o ms mdulos. Un mdulo explosionado se suele dar cuando existe un componente comn de proceso en dos o mas modulos y puede redefinirse como un mdulo cohesivo diferente. Cuando se espera un acoplamiento alto, se puede a veces implosionar un mdulo para reducir el paso de control, referencia a datos globales y la complejidad de la interfaz. II.Intentar minimizar las estructuras con mucho grado de salida; intentar concentrar a medida que aumenta la profundidad. La estructura mostrada dentro de la nube en la Figura 13.9 no hace un empleo eficaz del de la particin. Todos los mdulos estn al mismo nivel debajo de un solo mdulo de control. En general, se muestra una distribucin ms razonable de control en la estructura de arriba. La estructura toma una forma oval, indicando varias capas de control y mdulos de alta utilidad en las capas inferiores. III.Mantener el alcance del efecto de un mdulo dentro del alcance del control de ese mdulo. Se define el mbito del efecto de un mdulo e como todos los dems mdulos afectados por una decisin lomada en el mdulo e. El alcance del" control del mdulo e son todos los mdulos subordinados al mdulo e. Como se muestra en la Figura 13.9. si el mdulo e toma una decisin que afecta el mdulo r, tenemos una violacin de la heurstica III, porque el mdulo r queda fuera del alcance de control del mdulo e. IV.Evaluar las interfaces de los mdulos para reducir la complejidad, la redundancia y mejorar la consistencia. La complejidad de la interfaz de un mdulo es una causa principal de errores en el software. Las interfaces deberan disearse para pasar informacin de manera sencilla y deberan ser consistentes con la funcin del mdulo. La inconsistencia de una interfaz (p. ej.: datos aparentemente no relacionados pasados a travs de una lista de argumentos u otra tcnica) es una indicacin poca cohesin. El mdulo en cuestin debera reevaluarse. V.Definir mdulos cuya funcin sea predecible, pero evitar mdulos que sean demasiado restrictivos. Un mdulo es predecible cuando puede tratarse como una caja negra; es decir, se producirn los mismos datos externos independientemente de los detalles del procesamiento interno8. Los mdulos que tienen memoria interna pueden ser impredecibles a no ser que se tenga cuidado en su empleo. Un mdulo que restringe el procesamiento a una sola subfuncin exhibe una

gran cohesin y es bien visto por los diseadores. Sin embargo, un mdulo que arbitrariamente restringe el tamao de una estructura de datos local, las opciones dentro del flujo de control o los modos de interfaz externa requerir invariablemente mantenimiento para quitar #sas restricciones.
's Un mdulo de caja negra es una abstraccin procedimenlal.

VI.Intentar conseguir mdulos de entrada controlada, evitando conexiones patolgicas. Esta heurstica de diseo advierte contra el acoplamiento de contenido. El software es ms fcil de entender y por tanto ms fcil de mantener cuando los mdulos que se interaccionan estn restringidos y controlados. Las conexiones patolgicas se refieren a bifurcaciones o referencias en el medio de un mdulo.

VII.Empaquetar el software basndose en las restricciones del diseo y los requisitos de portabilidad. El empaquetamiento alude a las tcnicas usadas para ensamblar software para un entorno procedimental especfico. Las restricciones de diseo dictan a veces que un programa se superponga a s mismo en memoria. Cuando tenga que pasar esto, puede ser necesario reorganizar la estructura de diseo para agrupar los mdulos por l grado de repeticin, frecuencia de acceso e intervalos entre llamadas. Adems, los mdulos opcionales o de un solo uso pueden separarse en la estructura de manera que sean superpuestos eficazmente.

13.7. EL MODELO DEL DISEO

Los principios y conceptos de diseo tratados en este captulo establecen el fundamento para la creacin del modelo de diseo que comprende representaciones de datos, arquitectura, interfaces y procedimientos. Como antes en el modelo de anlisis, en el modelo de diseo cada una de esas representaciones de diseo est atada a las otras y a todas se le puede hacer un seguimiento hasta los requisitos del software. En la Figura 13.1, el modelo de diseo se represent como una pirmide. El simbolismo de esta forma es importante. Una pirmide es un objeto extremadamente estable con una base muy amplia y un centro de gravedad muy bajo. Como la pirmide, nosotros queremos crear un diseo del software que sea estable. Establecemos una amplia base en el diseo de datos, una regin media estable en el diseo arquitectnico y de interfaz, y una parte superior aplicando diseo procedimental, creamos as un modelo de diseo que no se tambalee fcilmente con los vientos de los cambios. Es interesante resaltar que algunos programadores continan diseando implcitamente, llevando a cabo el diseo procedimental a la vez que escriben el cdigo. Esto es lo mismo que coger la pirmide de diseo y ponerla apoyada sobre la punta: resulta un diseo extremadamente inestable. El ms mnimo

cambio puede hacer que caiga la pirmide (y el programa). Los mtodos que llevan a la creacin del modelo de diseo se tratan en los Captulos 14 y 21 (para sistemas orientados a objetos). Todos los mtodos permiten al diseador crear un diseo estable conforme a los conceptos fundamentales que conducen a un software de alta calidad.

13.8. LA DOCUMENTACIN DEL DISEO

El documento esbozado en la Figura 13.10 puede usarse como plantilla para una especificacin del diseo. Cada prrafo numerado trata diferentes aspectos del model de diseo. Las secciones numeradas de la especificacin del diseo se completan a medida que el diseador refina su representacin del software. El alcance global del esfuerzd de diseo se describe en la Seccin I (los nmeros de seccin se refieren al esquema de la especificacin del diseo). Mucha de la informacin contenida en esta seccin se obtiene de la especificacin del sistema y del modelo de anlisis (especificacin de los requisitos del software). La Seccin II presenta el diseo de datos, describiendo ^structures externas de archivos, estructurasen temas de datos y referencias cruzadas que conectan objetos de datos a archivos especficos. La seccin III, el diseo arquitectnico, indica cmo se ha obtenido la arquitectura del programa del modelo de anlisis. Se utilizan grficos de estructuras (una representacin de la estructura del programa) para representar la jerarqua del mdulo. Las Secciones IV y V evolucionan en cuanto comienzan los diseos de la interfaz y de los procedimientos. Se representan las interfaces extemas e internas del programa y se describe un detallado diseo de la interfaz hombre- mquina. Se describen inicialmente los mdulos (elementos de software tratables separadamente; subrutinas, funciones o procedimientos) con una narrativa de procesamiento. La narrativa del procesamiento explica la funcin procedimental de un mdulo. Ms adelante se usa una herramienta de diseo procedimental para traducir la narrativa en una descripcin estructurada. La Seccin VI de la especificacin de diseo contiene una referencia cruzada de requisitos. El propsito de esta matriz de referencia cruzada es (1) establecer que se han satisfecho todos los requisitos por el diseo del software y (2) indicar qu mdulos son crticos para la implementacin de los requisitos especficos. La primera fase en el desarrollo de la documentacin de pruebas est contenida en la Seccin VII del documento del diseo- Una vez que se han establecido la estructura del software y las interfaces, podemos desarrollar directrices para probar mdulos individuales y la integracin del. paquete entero. En algunos casos, se da paralelamente una detallada especificacin del procedimiento de prueba con el diseo. En tales casos, esta seccin puede eliminarse de la especificacin del diseo. Las restricciones de diseo, tales como limitaciones fsicas de memoria o la necesidad de una interfaz extema especializada puede dictar

requisitos especiales para ensamblar o empaquetar el software. Algunas consideraciones especiales causadas por la necesidad de superposicin (overlay) de pro-