INTRODUCCINa) Presentacin y contextualizacinEn esta unidad aprender los conceptos principales de diseo estructurado yentender la importancia de los sistemas de informacin, as como sus conexiones para solucionar problemas. El diseo estructurado persigue elaborar algoritmos que cumplan la propiedad de modularidad, para ello, dado un problema que se pretende resolver mediante la elaboracin de un programa de ordenador, se busca dividir dicho programa en mdulos siguiendo los principios de diseo de Descomposicin por refinamientos sucesivos, creacin de una Jerarqua modular y elaboracin de mdulos Independientes.b) CompetenciaConoce el concepto de diseo estructurado y practicar su uso para generar habilidades para desarrollar el proceso.c) Capacidades1.Identifica los componentes que integran un diseo estructurado.2.Conoce los conceptos bsicos de diseo estructurado para aplicarlo en un proceso automatizado.3.Analiza y reconoce las distintas etapas de diseo estructurado.4.Emplea organizadamente, adecuadamente los conectores y referentes al anlisis y diseo de sistemas de informacin.d) ActitudesPosee capacidad creativa y empresarial.Muestra habilidad para Investigar, analizar y sintetizar informacin.Posee entusiasmo e inters por la programacin.e) Presentacin de Ideas bsicas y contenido esenciales de la unidad:La Unidad de Aprendizaje 01: Anlisis de diseo, comprende el desarrollo de los siguientes temas:TEMA 01:Introduccin de diseo estructurado.TEMA 02:Conceptos bsicos de diseo estructurado.TEMA 03:Etapas de diseo estructurado.TEMA 04:Criterios de validacin de calidad del diseo estructurado.Tema 01: Introduccin de Diseo Estructurado"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.1Qu 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 ser 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.2Objetivos Del Diseo Estructurado"El diseo estructurado, tiende a transformar el desarrollo de software de una prctica artesanal a una disciplina de ingeniera".EficienciaMantenibilidadModificabilidadFlexibilidadGeneralidadUtilidad

"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 qu 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 lasrestricciones 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 SOFTWAREUn concepto importante 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 =MTBFMTBF + MTTRDnde: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 aceptaciones 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 lacalidad 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 DiseoPodemos 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 yrestricciones 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 sus 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 estructurado1.4.1AbstraccinLa nocin psicolgica de abstraccin permite concentrarse en un problemaal 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 m, es cercana a palabras como tericas, esotricas, acadmicas", 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)

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.2ModularidadLa 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.3Arquitectura del softwareLa 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.4Jerarqua de controlLa 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.5Estructura de datosLa 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.6Procedimientos del softwareLa 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.8Ocultamiento de la informacinEl 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.

Tema 02:Conceptos Bsicos de Diseo EstructuradoCMO 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 partesManejablemente 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 sonFcilmente relacionables con la aplicacinManejablemente pequeasCorregibles 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 aplicacinModificables 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 conceptoCMO 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 sub-problemas ms pequeos, de tal forma que cada sub-problema 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 cmo 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 ms grandes de lo estrictamente necesario para resolver los aspectos del problema que ella abarca. Igualmente importante, es el evitar la introduccin de relaciones en el sistema, que no existe en el dominio del problema.

El concepto de cajas negrasUna 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 engeneral, 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".Comparacin entre las estructuras administrativas y el diseo estructuradoUno 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 ser comprimida en una sola jefatura. Estableciendo una 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.Manejo de la complejidadEn 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 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 respondern 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 queM (P+Q) > M (P) + M(Q)

Y consecuentementeC(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 vlido 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 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 asienta la descomposicin de problemas en sub-problemas. Esto nos lleva a que dado un problema P no trivial, es conveniente descomponerlo en problemas ms pequeos ya que se observa queC(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 + I1x P) + C(P" + I2x P")Donde 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 serC(P + I1x P) + C(P" + I2x P") > C( P) + C( P)Si I1 e I2 son muy pequeos podremos decir que:C(P) > C(P + I1x P) + C(P" + I2x 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 establecerse con precisin, pero veremos una serie de principios que nos conducirn a aproximarnos.Complejidad en trminos humanosEn el punto anterior realizamos un anlisis sobre la incidencia de la complejidad en los costos, y cmo 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 extensinQu 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 una 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.

CantidadPor 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, l debe conocer cmo 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.

AccesibilidadQuiz 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 cul 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 parame trizadas por algunas personas fundamentadas principalmente en:Parametrizar una interface requiere ms trabajoEl proceso de parametrizacin mismo puede introducir erroresEn general la velocidad del programa es menor que cuando se usan variables globales

EstructuraFinalmente 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) )

INTRODUCCINLos mtodos de diseo del software se obtienen del estudio de cada uno de los tres dominios del modelo de anlisis. El dominio de los datos, el funcional y el de comportamiento sirven de directriz para la creacin del diseo.En el diseo estructurado orientado al flujo de datos, partimos de la representacin del flujo de la informacin obtenida en la fase de anlisis, donde la informacin puede representarse como un flujo continuo que sufre una serie de transformaciones conforme va de la entrada a la salida. El diagrama de flujo de datos DFD (o de burbujas) se utiliza como herramienta grfica para la descripcin del flujo de la informacin.

1.Diseo de datosEl impacto de la estructura de datos sobre la estructura del programa y la complejidad procedimental hace que el diseo de datos tenga una gran influencia en la calidad del software. Los datos bien diseados pueden conducir a una mejor estructura de programa, a una modularidad efectiva y a una complejidad procedimental reducida.2.Diseo arquitectnicoElobjetivoprincipaldeldiseoarquitectnicoesdesarrollarunaestructuradeprograma modularyrepresentarlasrelacionesdecontrolentrelosmdulos.Mezclalaestructurade programas y laestructura de datos y define las relaciones que facilitan el flujo de los datos a lo largo del programa. El diseo orientado al flujo de datos es compatible con un amplio rango de reas de aplicacin. Es particularmente til cuando se procesa secuencialmente la informacin y no existe ninguna estructura jerrquica formal. De hecho, todo el software puede representarse como un diagrama de flujo de datos.Ejemplo: aplicaciones con microprocesadores, procedimientos de anlisis numrico, procesos de control, etc.

3.El proceso del diseo arquitectnicoEl diseo orientado al flujo de datos define varias representaciones que transforman el flujo de la informacin en la estructura del programa.El Diseo Orientado al Flujo de Datos permite una cmoda transformacin de las representaciones de la informacin (DFD) a una descripcin de la estructura del programa. Este proceso debe seguir los siguientes pasos:1)Establecer el tipo de flujo de informacin.a.Flujo de transformacin.b.Flujo de transaccin.2)Determinar los lmites del flujo.3)Convertir el DFD en la estructura del programa.4)Definir la jerarqua de control descomponindola mediante particionalmente.5)Refinar la estructura resultante usando medidas y heursticas de diseo.

El tipo de flujo de informacin es lo que determina el mtodo de conversin requerido en el paso 3.ETAPAS DE DISEO ESTRUCUTURADODescomposicinPor qu descomponer un problema en partes? Experimentalmente est comprobado que:Un problema complejo cuesta ms de resolver que otro ms sencillo (de Perogrullo).La complejidad de un problema global es mayor que el valor de las complejidades de cada una de sus partes por separado.Segn esto, merece la pena el esfuerzo de dividir un problema grande en subproblemas ms pequeos. Si el objetivo es elaborar un programa para resolver dicho problema grande, cada subproblema (menos complejo) podr ser resuelto por un mdulo (subalgoritmo) relativamente fcil de implementar (ms que el programa global No dividido).

Ahora la cuestin es cmo realizar la descomposicin?; realizando un estudio descendente Top-Down que nos lleve desde la concepcin del problema (programa o algoritmo) global hasta identificar sus partes (mdulos). Esta tcnica se repite aplicando una estrategia llamada de refinamiento sucesivo propuesta por el experto en Ciencias de la Computacin Niklaus Wirth, que consiste precisamente en volver a aplicar el estudio descendente Top-Down a cada subproblema una y otra vez hasta obtener subproblemas suficientemente pequeos, que puedan ser resueltos por mdulos que cumplan, en la medida de lo posible, las caractersticas deseables en un mdulo en el mbito de la programacin. En palabras del propio Niklaus Wirth:

En cada paso (del refinamiento), una o varias instrucciones del programa dado, se descomponen en instrucciones ms detalladas. Esta descomposicin sucesiva o refinamiento de especificaciones termina cuanto todas las instrucciones estn expresadas en trminos de la computadora usada o del lenguaje de programacin...Conforme se refinan las tareas, tambin los datos pueden ser refinados, descompuestos o estructurados, siendo lo natural refinar las especificaciones del programa y de los datos en paralelo.Cada paso de refinamiento implica algunas decisiones de diseo. Es importante que el programador sea consciente de los criterios subyacentes (en las decisiones de diseo adoptadas) y de la existencia de soluciones alternativas.

Problema del refinamiento sucesivoCundo parar el refinamiento? Un refinamiento excesivo podra dar lugar a un nmero tan grande de mdulos que hara poco prctica la descomposicin. Se tendrn en cuenta estos criterios para dejar de descomponer:Cuando no haya tareas bien definidas.Cuando la interfaz de un mdulo sea tan complicada como el propio mdulo

Jerarqua de mdulossta es una consecuencia directa de la descomposicin del problema mediante refinamientos sucesivos, el resultado ser un conjunto de mdulos estratificados en capas a modo de pirmide donde en la cima habr un nico mdulo que representar al programa global y en los niveles inferiores aparecern los mdulos resultantes de las sucesivas divisiones.Al final, debe obtenerse una estructura piramidal donde los mdulos de los niveles superiores se encargan de las tareas de coordinacin, lgica de la aplicacin y manipulacin de los mdulos inferiores; estos otros debern realizar tareas de clculo, tratamiento y entrada/salida de informacin.

IndependenciaIndependencia modular.-Cuanto ms independientes son los mdulos entre s ms fcil y flexiblemente se trabajar con ellos, esto implica que para desarrollar un mdulo no es necesario conocer detalles internos de otros mdulos. Como consecuencia de la independencia modular un mdulo cumplir:Caractersticas de caja negra, es decir abstraccin (ver abstraccin en programacin orientada a objetos).Aislamiento de los detalles mediante encapsulamiento (ver encapsulamiento en programacin orientada a objetos).

La independencia modular mejora el rendimiento humano, pudiendo realizarse programacin en equipo y desarrollar mdulos paralelamente. Tambin contribuye a la reutilizacin de software.Tema 04:Criterios de Validacin de Calidad del Diseo EstructuradoLos 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 peticionarse 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 lo diagramas de estructura. A continuacin se describen los criterios utilizados para mejorar un diseo.

1.1.AcoplamientoEl 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 existente entre pares de sus mdulos, ya que ese es el problema que debe ser resuelto para mejorar 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).

1.2CohesinOtro 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.

1.3Descomposicin (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.1.3.1Reducir el tamao del mduloLa 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 cundo 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 mdulos, 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.

1.3.2Hacer el sistema ms claroLa descomposicin no debera ser hecha de una manera arbitraria, los mdulos resultantes de la descomposicin de un mdulo deben representar sub-funciones del mdulo de ms 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, aun cuando, en una implementacin, el cdigo del mdulo sea programado dentro del mdulo jefe.

1.3.3Minimizar la duplicacin de cdigoCuando se reconoce una funcin que puede ser reutilizada en otras partes del DE, lo ms conveniente es convertirla en un mdulo separado. As, se puede localizar ms 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 funcin debe ser modificada) pueden ser evitados, y se reduce el costo de implementacin.

1.3.4Separar el trabajo de la administracinUn administrador o gerente de una compaa bien organizada debera coordinar el trabajo 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 subordinados 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 trabajo 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 raramente ambos.

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

1.4Fan-OutEl 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 fcilmente ser mejorado por descomposicin.

1.5Fan-InEl 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.