Unidad 1: Introduccin al Diseo Estructurado

Definicin: "Diseo es el proceso de aplicar distintas tcnicas y principios con el propsito de definir un dispositivo, proceso, o sistema, con los suficientes detalles como para permitir su realizacin fsica" (E.S.Taylor, An Interim Report on Engineering Design, Massachusetts Institute of Technology, 1959) El objetivo del diseador es producir un modelo de una entidad que se construir ms adelante. El proceso por el cual se desarrolla el modelo combina: la intuicin y los criterios en base a la experiencia de construir entidades similares, un conjunto de principios y/o heursticas que guan la forma en la que se desarrolla el modelo, un conjunto de criterios que permiten discernir sobre calidad y un proceso de iteracin que conduce finalmente a una representacin del diseo final.

1.1 Qu es diseo estructurado? Definicin: "Diseo estructurado es el proceso de decidir que componentes, y la interconexin entre los mismos, para solucionar un problema bien especificado". El diseo es una actividad que comienza cuando el analista de sistemas ha producido un conjunto de requerimientos funcionales lgicos para un sistema, y finaliza cuando el diseador ha especificado los componentes del sistema y las relaciones entre los mismos. Frecuentemente analista y diseador son la misma persona, sin embargo es necesario que se realice un cambio de enfoque mental al pasar de una etapa a la otra. Al abordar la etapa de diseo, la persona debe quitarse el sombrero de analista y colocarse el sombrero de diseador. Una vez que se han establecido los requisitos del software (en el anlisis), el diseo del software es la primera de tres actividades tcnicas: diseo, codificacin, y prueba. Cada actividad transforma la informacin de forma que finalmente se obtiene un software para computadora vlido. En la figura se muestra el flujo de informacin durante la fase de desarrollo. Los requisitos del sistema, establecidos mediante los modelos de informacin, funcional y de comportamiento, alimentan el proceso del diseo. Mediante alguna metodologa (en nuestro caso, estructurada basada en el flujo de informacin) se realiza el diseo estructural, procedimental, y de datos. El diseo de datos transforma el modelo del campo de informacin, creado durante el anlisis, en las estructuras de datos que se van a requerir para implementar el software. El diseo estructural define las relaciones entre los principales elementos estructurales del programa. El objetivo principal del diseo estructural es desarrollar una estructura de programa modular y representar las relaciones de control entre los mdulos.

El diseo procedimental transforma los elementos estructurales en una descripcin procedimental del software. El diseo procedimental se realiza despus de que se ha establecido la estructura del programa y de los datos. Define los algoritmos de procesamiento necesarios. Concluido el diseo se genera el cdigo fuente y para integrar y validar el software, se llevan a cabo pruebas de testeo.

Las fases del diseo, codificacin y prueba absorben el 75% o ms del coste de la ingeniera del software (excluyendo el mantenimiento). Es aqu donde se toman decisiones que afectarn finalmente al xito de la implementacin del programa y, con igual importancia, a la facilidad de mantenimiento que tendr el software. Estas decisiones se llevan a cabo durante el diseo del software, haciendo que sea un paso fundamental de la fase de desarrollo. La importancia del diseo del software se puede sentar con una nica palabra: calidad. El diseo es el proceso en el que se asienta la calidad del desarrollo del software. El diseo produce las representaciones del software de las que puede evaluarse su calidad. El diseo sirve como base para todas las posteriores etapas del desarrollo y de la fase de mantenimiento. Sin diseo nos arriesgamos a construir un sistema inestable, un sistema que falle cuando se realicen pequeos cambios, un sistema que pueda se difcil de probar, un sistema cuya calidad no pueda ser evaluada hasta ms adelante en el proceso de ingeniera de software, cuando quede poco tiempo y se haya gastado ya mucho dinero.

1.2 Objetivos Del Diseo Estructurado "El diseo estructurado, tiende a transformar el desarrollo de software de una prctica artesanal a una disciplina de ingeniera". Eficiencia Mantenibilidad Modificabilidad Flexibilidad Generalidad Utilidad "Diseo" significa planear la forma y mtodo de una solucin. Es el proceso que determina las caractersticas principales del sistema final, establece los lmites en performance y calidad que la mejor implementacin puede alcanzar, y puede determinar a que costos se alcanzar. El diseo se caracteriza usualmente por un gran nmero de decisiones tcnicas individuales. En orden de transformar el desarrollo de software en una disciplina de

ingeniera, se debe sistematizar tales decisiones, hacerlas ms explcitas y tcnicas, y menos implcitas y artesanales. Un ingeniero no busca simplemente una solucin, busca la mejor solucin, dentro de las limitaciones reconocidas, y realizando compromisos requeridos en el trabajo del mundo real. En orden de convertir el diseo de sistemas de computadoras en una disciplina de ingeniera, previo a todo, debemos definir objetivos tcnicos claros para los programas de computadora como "sistemas". Es esencial adems comprender las restricciones primarias que condicionan las soluciones posibles. Para realizar decisiones concisas y deliberadas, debemos identificar los puntos de decisin . Finalmente necesitamos una metodologa que nos asista en la toma de decisiones. Dadas estas cosas: objetivos, restricciones, decisiones reconocidas, y una metodologa efectiva, podemos obtener soluciones de ingeniera, y no artesanales.

Diseo estructurado y calidad del software Un concepto importate a clarificar es el de calidad. Desafortunadamente, muchos diseadores se conforman con un sistema que "funcione" sin reparar en un buen sistema. Una corriente de pensamiento estima que un programa es bueno si sus algoritmos son astutos y no obvios a otro programador; esto refleja la "inteligencia" del programador. Otra escuela de pensamiento asocia calidad con incremento de la velocidad de ejecucin y disminucin de los requerimientos de memoria central. Estos son aspectos de un concepto ms amplio: eficiencia. En general, se busca diseos que hagan un uso inteligente de los recursos. Estos recursos no incluyen solamente procesador y memoria, tambin incluyen almacenamiento secundario, tiempo de perifricos de entrada salida, tiempo de lneas de teleproceso, tiempo de personal, y ms. Otra medida de calidad es la confiabilidad. Es importante notar que si bien la confiabilidad del software puede ser vista como un problema de depuracin de errores en los programas, es tambin un problema de diseo. La confiabilidad se expresa en como MTBF (mean time between fairules: tiempo medio entre fallas). Un concepto muy relacionado a la confiabilidad y de suma importancia es el de mantenibilidad. Podemos definir la mantenibilidad como: Mantenibilidad del sistema = ____MTBF___ MTBF + MTTR

donde: MTBF: tiempo medio entre fallas (mean time between fairules) MTTR: tiempo medio de reparacin (mean time to repair) Diremos que un sistema es mantenible si permite la deteccin, anlisis, rediseo, y correccin de errores fcilmente. En tanto la mantenibilidad afecta la viabilidad del sistema en un entorno relativamente constante, la modificabilidad influye en los costos de mantener un sistema viable en condiciones de cambio de requerimientos. La modificabilidad es la posibilidad de realizar modificaciones y extensiones a partes del sistema, o agregar nuevas partes con facilidad (no correccin de errores). En estudios realizados se determin que las organizaciones abocadas al procesamiento de datos invierten aproximadamente un 50% del presupuesto en mantenimiento de los sistemas, involucrando esto correccin de errores y modificaciones, razn por la cual la mantenibilidad y la modificabilidad son dos objetivos primarios en el diseo de software.

La flexibilidad representa la facilidad de que el mismo sistema pueda realizar variaciones sobre una misma temtica, sin necesidad de modificaciones. La generalidad expresa el alcance sobre un determinado tema. Flexibilidad y generalidad son dos objetivos importantes en el diseo de sistemas del tipo de propsitos generales. La utilidad o facilidad de uso es un factor importante que influye en el xito del sistema y sus aceptacin por parte del usuario. Un sistema bien diseado pero con interfaces muy "duras" tiende a ser resistido por los usuario.

Finalmente diremos que eficiencia, mantenibilidad, modificabilidad, flexibilidad, generalidad, y utilidad, son componentes de la calidad objetiva de un sistema. En trminos simples tambin diremos que nuestro objetivo primario es obtener sistemas de costo mnimo. Es decir, es nuestro inters obtener sistemas econmicos para desarrollar, operar, mantener y modificar.

1.3 Restricciones, compromisos, y decisiones del Diseo

Podemos ver los objetivos tcnicos del diseo como constituyendo una "funcin objetivo" de un problema de optimizacin, la cual se desea maximizar, sujeta a ciertas restricciones. Como regla, las restricciones sobre un proceso de diseo de un sistema, caen en dos categoras: restricciones de desarrollo y restricciones operacionales. Las restricciones de desarrollo son limitaciones al consumo de recursos durante el perodo de desarrollo, y pueden ser expresadas en trminos generales o descomponerla en su partes como ser tiempo de mquina y horas-hombre. Dentro de las restricciones de desarrollo, entran tambin las restricciones de planificacin. Estas se refieren a metas y plazos a ser cumplidos ("el mdulo X debe terminarse para Febrero"). Las restricciones operacionales pueden ser expresadas en trminos tcnicos, como ser mximo tamao de memoria disponible, mximo tiempo de respuesta aceptable, etc. El carcter de muchas decisiones de diseo no fija lmites rgidos, si no un intervalo de tolerancia, dentro del cual el diseador puede moverse a costa de variaciones en otros aspectos del sistema. Por ejemplo se puede priorizar eficiencia, en detrimento de facilidad de mantenimiento, o velocidad de ejecucin contra tamao de memoria utilizada. La esencia del diseo en el mundo real y las decisiones inherentes al mismo es obtener una solucin de compromiso. El diseo total es el resultado acumulativo de un gran nmero de decisiones tcnicas incrementales.

1.4 Principios utilizados por el diseo estructurado 1.4.1 Abstraccin La nocin psicolgica de abstraccin permite concentrarse en un problema al mismo nivel de generalizacin, independientemente de los detalles irrelevantes de bajo nivel. El uso de la abstraccin tambin permite trabajar con conceptos y trminos que son familiares al entorno del problema, sin tener que transformarlos a una estructura no familiar. Cada paso de un proceso de ingeniera de software es un refinamiento del nivel de abstraccin de la solucin de software. Conforme nos movemos por diferentes niveles de abstraccin, trabajamos para crear abstracciones de datos y de procedimientos. Una abstraccin procedural es una determinada secuencia de instrucciones que tienen una funcin limitada y especfica. Una abstraccin de datos es una determinada coleccin de datos que describen un objeto.

La abstraccin, para mi, es cercana a palabras como "terico", "esotrico", "acadmico", e "imprctico". Pero en un sentido en particular, significa la separacin de los aspectos ms importantes de un determinado problema, del detalle. Este es el nico camino que tengo para abordar con mi mente finita cualquier tema complejo.
Alan Cameron Wills - (Object Expert Jan/Feb 1996)

1.4.2 Refinamiento sucesivo El refinamiento sucesivo es una primera estrategia de diseo descendente propuesta por Niklaus Wirth. La arquitectura de un programa se desarrolla en niveles sucesivos de refinamiento de los detalles procedimentales. Se desarrolla una jerarqua descomponiendo una declaracin macroscpica de una funcin de una forma sucesiva, hasta que se llega a las sentencias del lenguaje de programacin.

1.4.3 Modularidad La arquitectura implica modularidad, el software se divide en componentes con nombres y ubicaciones determinados, que se denominan mdulos, y que se integran para satisfacer los requisitos del problema.

1.4.4 Arquitectura del software La arquitectura del software se refiere a dos caractersticas importantes del software de computadoras: 1. la estructura jerrquica de los componentes procedimentales (mdulos) 2. la estructura de datos

1.4.5 Jerarqua de control La jerarqua de control, tambin denominada estructura de programa, representa la organizacin (frecuentemente jerrquica) de los componentes del programa (mdulos) e implica una jerarqua de control. No representa aspectos procedimentales del software, tales como secuencias de procesos, o la repeticin de operaciones.

1.4.6 Estructura de datos La estructura de datos es una representacin de la relacin lgica existente entre los elementos individuales de datos. Debido a que la estructura de la informacin afectar

invariablemente al diseo procedimental final, la estructura de datos es tan importante como la estructura del programa en la representacin de la arquitectura del software.

1.4.7 Procedimientos del software La estructura del programa define la jerarqua de control, independientemente de las decisiones y secuencias de procesamiento. El procedimiento del software se centra sobre los detalles de procesamiento de cada mdulo individual. El procedimiento debe proporcionar una especificacin precisa del procesamiento, incluyendo la secuencia de sucesos, los puntos concretos de decisiones, la repeticin de operaciones, e incluso la organizacin/estructura de los datos.

1.4.8 Ocultamiento de la informacin El principio de ocultamiento de la informacin sugiere que los mdulos se han de caracterizar por decisiones de diseo que los oculten unos a otros. Los mdulos deben especificarse y disearse de forma que la informacin (procedimientos y datos) contenida dentro de un mdulo sea accesible a otros mdulos nicamente a travs de las interfaces formales establecidas para cada mdulo.

Unidad 2: Conceptos Bsicos de Diseo Estructurado

2.1 Como alcanzar sistemas de mnimo costo Cuando se trata con un problema de diseo, por ejemplo un sistema que pueda ser desarrollado en un par de semanas, no se tienen mayores problemas, y el desarrollador puede tener todos los elementos del problema "en mente" a la vez. Sin embargo cuando se trabaja en proyectos de gran escala, es difcil que una sola persona sea capaz de llevar todas las tareas y tener en mente todos los elementos a la vez. El diseo exitoso se basa en un viejo principio conocido desde los das de Julio Cesar: Divide y conquistars. Especficamente, diremos que el costo de implementacin de un sistema de computadora podr minimizarse cuando pueda separarse en partes manejablemente pequeas solucionables separadamente. Por supuesto la interpretacin de manejablemente pequea vara de persona en persona. Por otro lado muchos intentos de particionar sistemas en pequeas partes arribaron incrementos en los tiempos de implementacin. Esto se debe fundamentalmente al segundo punto: solucionables separadamente En muchos sistemas para implementar la parte A, debemos conocer algo sobre la B, y para implementar algo de B, debemos conocer algo de C.

De manera similar, podemos decir que el costo de mantenimiento puede ser minimizado cuando las partes de un sistema son fcilmente relacionables con la aplicacin manejablemente pequeas corregibles separadamente Muchas veces la persona que realiza la modificacin no es quien diseo el sistema. Es importante que las partes de un sistema sean manejablemente pequeas en orden de simplificar el mantenimiento. Un trabajo de encontrar y corregir un error en una "pieza" de cdigo de 1.000 lneas es muy superior a hacerlo con piezas de 20 lneas. No solo disminuye el tiempo de localizar la falla sino que si la modificacin es muy engorrosa, puede reescribirse la pieza completamente. Este concepto de "mdulos descartables" ha sido utilizado con xito muchas veces. Por otra parte, para minimizar los costos de mantenimiento debemos lograr que cada pieza sea independiente de otra. En otras palabras debemos ser capaces de realizar modificaciones al mdulo A sin introducir efectos indeseados en el mdulo B. Finalmente, diremos que el costo de modificacin de un sistema puede minimizarse si sus partes son fcilmente relacionables con la aplicacin modificables separadamente En resumen, podemos afirmar lo siguiente: los costos de implementacin, mantenimiento, y modificacin, generalmente sern minimizados cuando cada pieza del sistema corresponda a exactamente una pequea, bien definida pieza del dominio del problema, y cada relacin entre las piezas del sistema corresponde a relaciones entre piezas del dominio del problema. En la siguiente figura apreciamos este concepto

2.2 Como se logra el costo mnimo con Diseo Estructurado Un buen diseo estructurado es un ejercicio de particionamiento y organizacin de los componentes de un sistema. Entenderemos por particionamiento, la subdivisin de un problema en subproblemas ms pequeos, de tal forma que cada subproblema corresponda a una pieza del sistema. La cuestin es: Dnde y cmo debe dividirse el problema? Qu aspectos del problema deben pertenecer a la misma pieza del sistema, y cuales a distintas piezas? El diseo estructurado responde estas preguntas con dos principios bsicos: Partes del problema altamente interrelacionadas debern pertenecer a la misma pieza del sistema. Partes sin relacin entre ellas, deben pertenecer a diferentes piezas del sistema sin relacin directa. Otro aspecto importante del diseo estructurado es la organizacin del sistema. Debemos decidir como se interrelacionan las partes, y que parte est en relacin con cual. El objetivo es organizar el sistema de tal forma que no existan piezas mas grandes

de lo estrictamente necesario para resolver los aspectos del problema que ella abarca. Igualmente importate, es el evitar la introduccin de relaciones en el sistema, que no existe en el dominio del problema.

2.3 El concepto de Cajas Negras Una caja negra es un sistema (o un componente) con entradas conocidas, salidas conocidas, y generalmente transformaciones conocidas, pero del cual no se conoce el contenido en su interior. En la vida diaria existe innumerable cantidad de ejemplos de uso cotidiano: una radio, un televisor, un automvil, son cajas negras que usamos a diario sin conocer (en general) como funciona en su interior. Solo conocemos como controlarlos (entradas) y las respuestas que podemos obtener de los artefactos (salidas). El concepto de caja negra utiliza el principio de abstraccin. Este concepto es de suma utilidad e importancia en la ingeniera en general, y por ende en el desarrollo de software. Lamentablemente muchas veces para poder hacer un uso efectivo de determinado mdulo, el diseador debe revisar su contenido ante posibles contingencias como ser comportamientos no deseados ante determinados valores. Por ejemplo es posible que una rutina haya sido desarrolla para aceptar un determinado rango de valores y falla si se la utiliza con valores fuera de dicho rango, o produce resultados inesperados. Una buena documentacin en tales casos, es de utilidad pero no transforma al mdulo en una verdadera caja negra. Podramos hablar en todo caso de "cajas blancas". Los mdulos de programas de computadoras pueden variar en un amplio rango de aproximacin al ideal de caja negra. En la mayora de los casos podemos hablar de "cajas grises".

2.4 Comparacin entre las estructuras administrativas y el diseo estructurado Uno de los aspectos ms interesantes del diseo de programas es la relacin que puede establecerse con las estructuras de organizacin humanas, particularmente la jerarqua de administracin encontrada en la mayora de las grandes organizaciones. Observemos por ejemplo el siguiente diagrama de organizacin de una empresa

A simple vista podemos apreciar que el presidente de la empresa tiene demasiados subordinados, y consecuentemente su trabajo involucrar el manejo de demasiados datos y la toma de demasiadas decisiones, demasiada complejidad, que lo llevar a cometer posibles errores. Podemos establecer una analoga con la estructura de programas y es razonable pensar que un mdulo que tenga demasiados mdulos subordinados a quienes controlar, sea sumamente complejo, y susceptible a fallas. Veamos otro ejemplo

Podemos apreciar a simple vista que la tarea de los jefes A, X, Y, es relativamente trivial y podra se comprimida en una sola jefatura. Estableciendo un comparacin con la estructura de programas, si tenemos un mdulo cuya nica funcin es llamar a otro, y este a su vez a otro, el cual llama a uno que finalmente realizar la tarea, los mdulos intermedios podrn comprimirse un nico mdulo de control. Podemos decir que en una organizacin perfecta, los administradores no realizan ninguna tarea operativa. Su labor consiste en coordinar informacin entre los subordinados y tomar decisiones. Los niveles inferiores son los que realizan el trabajo operativo. Anlogamente, podemos argumentar que los mdulos de nivel alto en un programa o sistema solamente coordinan y controlan la ejecucin de los mdulos de menor nivel, quienes son los que realizan los cmputos y procesos que el sistema requiere. Finalmente observaremos que los administradores suministran a sus subordinados nicamente la informacin que estrictamente necesitan. Anlogamente los mdulos inferiores solo deben tener acceso a la informacin que necesitan, y no a otras.

El establecimiento de un paralelo entre las estructuras organizativas humanas y los programas de computadora nos ser muy til en el estudio del diseo estructurado.

2.5 Manejo de la complejidad En principio diremos que escribir un programa "grande" generalmente lleva ms tiempo que escribir un "pequeo". Esto es valedero si medimos "grande" y "pequeo" en unidades apropiadas. Claramente, el nmero de instrucciones de un programa no es una medida de complejidad ya que existe instrucciones ms complejas que otras, y algoritmos ms complejos que otros. En realidad lo que diremos es que es ms difcil resolver un problema difcil! , e intentaremos realizar un anlisis sobre como disminuir la complejidad de un determinado problema. Si asumimos que hemos podemos medir por algn mtodo la complejidad de un problema P (no importa aqu que mtodo), diremos que la complejidad del mismo ser M(P), y que el costo de realizar un programa que resuelva el problema P ser C(P). Los enunciados previos responder a la siguiente regla: dados dos problemas P y Q observaremos lo siguiente Si M(P) > M(Q) entonces C(P) > C(Q) es decir el costo de resolver un determinado problema es directamente proporcional al tamao del mismo. Intentaremos tomar dos problemas separados y en lugar de escribir dos programas, crear un programa combinado. Si juntamos los dos problemas, obtendremos uno mayor que si tomamos los dos por separado. La razn fundamental para no combinar los problemas, es que los humanos tenemos inconvenientes para tratar adecuadamente grandes complejidades, y en la medida que esta se incrementa somos susceptibles a cometer un mayor nmero de errores. En virtud de esto podemos afirmar que M(P+Q) > M(P) + M(Q) y consecuentemente C(P+Q) > C(P) + C(Q) Siempre ser preferible crear dos piezas pequeas que una sola ms grande, si ambas solucionan el mismo problema. Este fenmeno no es solo vlida para el campo de la computacin. Es verdadero en cualquier campo de la solucin de problemas (matemtica, fsica, etc.). El psiclogo-matemtico George Miller, realiz una serie de investigaciones sobre las limitaciones en el procesamiento de informacin humano. Estos estudios determinaron que la mente humana puede mantener y tratar simultneamente hasta con siete objetos, o conceptos. En efecto, la memoria necesaria para la resolucin de problemas con

mltiples elementos, tiene una capacidad de 7 s 2 entidades. Por sobre este nmero la cantidad de errores se incrementa desproporcionadamente en forma no lineal.

Esta es una propiedad de la capacidad de procesamiento de informacin del cerebro humano bien establecida sobre la que se acienta la descomposicin de problemas en subproblemas. Esto nos lleva a que dado un problema P no trivial, es conveniente descomponerlo en problemas ms pequeos ya que se observa que C(P) > C( P) + C( P) Ahora bien, cuando se descompone una tarea en dos, si las subtareas no son realmente independientes, al solucionar una de las partes, debe simultneamente tratarse aspectos de la otra. Supongamos que descomponemos P en dos partes iguales P = P y P" = P, si las partes no son independientes, el costo de resolver el problema entero ser: C(P + I1 x P) + C(P" + I2 x P") donde I1 es una fraccin que representa la interaccin de P con P", e I2 es una fraccin que representa la interaccin de P" con P. Siempre que I1 e I2 sean mayores a cero, es obvio que ser C(P + I1 x P) + C(P" + I2 x P") > C( P) + C( P) Si I1 e I2 son muy pequeos podremos decir que: C(P) > C(P + I1 x P) + C(P" + I2 x P") Ahora, la subdivisin de un problema en otros menores tiene un lmite. Es obvio que no podemos esperar dividir el sistema en un infinito nmero de "nadas", y en el caso lmite, el desarrollo de un sistema como un nmero muy grande de piezas independientes es equivalente a desarrollarlo en una sola pieza. Ms adelante analizaremos como determinar el tamao conveniente de cada parte.

El proceso de factorizacin de un problema en partes, puede introducir algunos errores, pero en general si se realiza correctamente tiende a aplastar la curva de errores

Como puede sugerirse, la factorizacin de un sistema en mil mdulos de una lnea, es equivalente al costo de un mdulo de 1000 lneas (y posiblemente mayor). Claramente estos son los extremos de un espectro de alternativas. A medida que los mdulos sean ms pequeos, podemos esperar que su complejidad (y costo) disminuyan, pero adems, a mayor cantidad de mdulos, tendremos mayor posibilidad problemas debido a errores en las conexiones intermdulos. Estas son dos curvas en contraposicin

En este punto no estamos preparados para predecir el tamao "ptimamente pequeo" de un mdulo. En realidad es muy dudoso que pueda establecerce con precisin, pero veremos una serie de principios que nos conducirn a aproximarnos.

2.6 Complejidad en trminos humanos En el punto anterior realizamos un anlisis sobre la incidencia de la complejidad en los costos, y como manejarla a travs de la subdivisin de un problema en problemas menores. Vimos que muchos de nuestros problemas en diseo y programacin se deben a la limitada capacidad de la mente humana para lidiar con la complejidad. La cuestin ahora es:

Qu es lo complejo para los humanos? En otras palabras: Que aspectos del diseo de sistemas y programas son considerados complejos por el diseador? Y por extensin Que podemos hacer para realizar sistemas menos complejos? En primer trmino podemos decir que el tamao de un mdulo es una medida simple de la complejidad. Generalmente un mdulo de 1000 sentencias, ser ms complejo que uno de 10. Obviamente el problema es mayor ya que existen sentencias ms complejas que otras. Por ejemplo las sentencias de decisin son uno de los primeros factores que contribuyen a la complejidad de un mdulo. Otro factor de importancia es el "espacio" de vida o alcance de los elementos de dato, es decir el nmero de sentencias durante las cuales el estado y valor de un elemento de datos debe ser recordado por el programador en orden de comprender que es lo que hace el mdulo. Otro aspecto relacionado con la complejidad es el alcance o amplitud del flujo de control, esto es el nmero de sentencias lexicogrficamente contiguas que deben examinarse antes de encontrar un seccin de cdigo caja-negra con un punto de entrada y un punto de salida. Es interesante notar que la teora detrs de la programacin estructurada provee el medio de reducir este alcance a una mnima longitud organizando la lgica en combinaciones de operaciones de "secuencia", "decisin", e "iteracin". Todas estas medidas reconocen que la complejidad de los programas percibida por humanos, se ve altamente influenciada por el tamao del mdulo. Tres factores, implcitos en el enfoque previo, han sido identificados como afectando la complejidad de las sentencias: la cantidad de informacin que debe ser comprendida correctamente. la accesibilidad de la informacin. la estructura de la informacin. Estos factores determinan la probabilidad de error humano en el procesamiento de informacin de todo tipo. Mientras que la complejidad de todo tipo de sentencias de programas pueden evaluarse segn estos criterios, enfocaremos la atencin en aquellas que establecen relaciones intermodulares.

Cantidad

Por cantidad de informacin, entenderemos el nmero de bits de datos, en el sentido que le asigna la teora de la informacin este trmino, que el programador debe manejar para comprender la interface. En trminos simples, esto se relaciona con el nmero de argumentos o parmetros que son pasados en la llamada al mdulo. Por ejemplo, una llamada a una subrutina que involucra 100 parmetros, ser ms compleja que una que involucra solo 3. Cuando un programador ve una referencia a un mdulo en el medio de otro, el debe conocer como se resolver la referencia, y que tipo de transformacin se transmitir. Consideremos el siguiente ejemplo: una llamada al procedimiento SQRT Si la llamada es: SQRT(X) el programador inferir que X funciona como parmetro de entrada y como valor de retorno del procedimiento. Y es muy probable que esto sea as. Ahora bien, si la llamada es: SQRT(X,Y) el programador inferir que X funciona como parmetro de entrada y que el resultado es retornado en Y. Es muy probable que esto sea as, aunque podra ser al revs. Ahora supongamos que tenemos: SQRT(X,Y,Z) el programador podr inferir que X funciona como parmetro de entrada, que el resultado es retornado del procedimiento, y que en Z se retorna algn cdigo de error. Esto podra ser cierto, pero es alta la probabilidad de que el orden de los parmetros sea diferente. Vemos que a medida que crece la cantidad de parmetros, la posibilidad de error es mayor. Puede argumentarse que esto se soluciona con una adecuada documentacin, pero la realidad demuestra que en la mayora de los casos los programas no estn bien documentados. Notaremos adems que un mdulo con demasiados parmetros, posiblemente est realizando ms de una funcin especfica, y por lo tanto podra descomponerse en dos mdulos las sencillos y funcionales con una menor cantidad de argumentos.

Accesibilidad Quiz ms importante que la cantidad de informacin es su accesibilidad. Cierta informacin acerca del uso de la interface debe ser comprendida por el programador para escribir o interpretar el cdigo correctamente. Consideraremos los siguientes puntos en esto: La interface es menos compleja si la informacin puede ser accedida (por el

programador, no por la computadora) directamente; es ms compleja si la informacin referencia indirectamente otros elementos de datos. La interface es menos compleja si la informacin es presentada localmente dentro de la misma sentencia de llamada. La interface es ms compleja si la informacin necesaria es remota a la sentencia. La interface es menos compleja si la informacin es presentada en forma standard que si se presenta de forma imprevista. La interface es menos compleja si su naturaleza es obvia es menos compleja que si su naturaleza es obscura. Observaremos el siguiente ejemplo: supongamos que tenemos la funcin DIST que calcula la distancia existente entre dos puntos. La frmula matemtica para realizar dicho clculo es: DIST = SQRT ( (y1 - y0)2 + (x1 - x0)2 ) Consideraremos las siguientes interfaces: Opcin 1. CALL DIST (X0, Y0, X1, Y1, DISTANCIA) Opcin 2. CALL DIST (ORIGEN, FIN, DISTANCIA) Opcin 3. CALL DIST (XCOORDS, YCOORDS, DISTANCIA) Opcin 4. CALL DIST (LINEA, DISTANCIA) Opcin 5. CALL DIST ( LINETABLA) Opcin 6. CALL DIST Trataremos de determinar cual de las interfaces es la menos compleja. A primera vista podemos pensar que la opcin 1 es la ms compleja ya que involucra el mayor nmero de parmetros. Sin embargo la opcin 1 presenta los parmetros en forma directa. En contraste, la opcin 2 presenta la informacin de manera indirecta. En orden de comprender la interface, deberemos ir a otra parte del programa y verificar que ORIGEN se define en trminos de subelementos X0 e Y0, FIN como X1 e Y1. La opcin 3, adems de presentar la informacin en forma indirecta adems la presenta en forma no estndar lo cual complica ms la interface. La opcin 4 presenta la misma desventaja que 2 y 3, presentando los valores en forma remota. La opcin 5 es an ms compleja. El identificador LINETABLE es obscuro . La opcin 6 a diferencia de las anteriores no representa parmetros localmente sino en forma remota.

Lamentablemente, algunos lenguajes como COBOL no permiten la llamada a mdulos con parmetros dentro de un mismo programa. Adems, existe cierta aversin a utilizar llamadas parametrizadas por algunos personas fundamentadas principalmente en: parametrizar una interface requiere ms trabajo el proceso de parametrizacin mismo puede introducir errores en general la velocidad del programa es menor que cuando se usan variables globales

Estructura Finalmente observaremos que la estructura de la informacin puede ser un punto clave en la complejidad. La primera observacin es que la informacin es menos compleja si se presenta en forma lineal y ms compleja si se presenta en forma anidada. La segunda observacin es que la informacin se menos compleja se se presenta en modo afirmativo o positivo, y es ms compleja si se presenta en modo negativo. Ambos conceptos tienen aplicacin primaria en la escritura de cdigo de programas. Por ejemplo, ciertas construcciones de sentencias IF anidadas son ms complejas de entender que un secuencia de varias sentencias IF simples. Similarmente, las expresiones lgicas que involucran operadores de negacin (NOT) son ms difciles de comprender que aquellas que no lo presentan. Estas filosofas de pensamiento linear y positivo tambin son importantes en las referencias intermodulares. Supongamos la siguiente instruccin: DISTANCIA = SQRT ( sum( square ( dif (Y1,Y0), square ( dif (X1, X0) ) ) ) Normalmente esta expresin para el comn de los programadores resultar complicada de leer. Si por el contrario descomponemos la expresin en otras menores tendremos una mayor cantidad de elementos lineares, y una reduccin en el anidamiento. La secuencia de expresiones resultantes resulta ms sencilla de leer: A = dif (Y1, Y0) B = dif (X1, X0) A2 = square (A) B2 = square (B) DISTANCIA = SQRT ( sum (A2, B2) )