2.

1 DISEÑO ESTRUCTURADO DE SISTEMAS

Definición: "Diseño es el proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, proceso, o sistema, con los suficientes detalles como para permitir su realización física" El objetivo del diseñador es producir un modelo de una entidad que se construirá más adelante. El proceso por el cual se desarrolla el modelo combina: la intuición y los criterios en base a la experiencia de construir entidades similares, un conjunto de principios y/o heurísticas que guían la forma en la que se desarrolla el modelo, un conjunto de criterios que permiten discernir sobre calidad y un proceso de iteración que conduce finalmente a una representación del diseño final. "Diseño estructurado es el proceso de decidir que componentes, y la interconexión entre los mismos, para solucionar un problema bien especificado". El diseño es una actividad que comienza cuando el analista de sistemas ha producido un conjunto de requerimientos funcionales lógicos para un sistema, y finaliza cuando el diseñador ha especificado los componentes del sistema y las relaciones entre los mismos. Frecuentemente analista y diseñador 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 diseño, la persona debe quitarse el sombrero de analista y colocarse el sombrero de diseñador. Una vez que se han establecido los requisitos del software (en el análisis), el diseño del software es la primera de tres actividades técnicas: diseño, codificación, y prueba. Cada actividad transforma la información de forma que finalmente se obtiene un software para computadora válido.

Objetivos Del Diseño Estructurado "El diseño estructurado, tiende a transformar el desarrollo de software de una práctica artesanal a una disciplina de ingeniería". • • Eficiencia Mantenibilidad

1. Por supuesto la interpretación de manejablemente pequeña varía de persona en persona. y para implementar algo de B. Específicamente.1 CONCEPTOS BASICOS. es difícil que una sola persona sea capaz de llevar todas las tareas y tener en mente todos los elementos a la vez. no se tienen mayores problemas. Por otro lado muchos intentos de particionar sistemas en pequeñas partes arribaron incrementos en los tiempos de implementación.• • • • Modificabilidad Flexibilidad Generalidad Utilidad 2. Esto se debe fundamentalmente al segundo punto: solucionables separadamente En muchos sistemas para implementar la parte A. y el desarrollador puede tener todos los elementos del problema "en mente" a la vez. debemos conocer algo de C. diremos que el costo de implementación de un sistema de computadora podrá minimizarse cuando pueda separarse en partes • • manejablemente pequeñas solucionables separadamente. por ejemplo un sistema que pueda ser desarrollado en un par de semanas. debemos conocer algo sobre la B. . Sin embargo cuando se trabaja en proyectos de gran escala. De manera similar. Como alcanzar sistemas de mínimo costo Cuando se trata con un problema de diseño. podemos decir que el costo de mantenimiento puede ser minimizado cuando las partes de un sistema son • • • fácilmente relacionables con la aplicación manejablemente pequeñas corregibles separadamente Muchas veces la persona que realiza la modificación no es quien diseño el sistema. El diseño exitoso se basa en un viejo principio conocido desde los días de Julio Cesar: Divide y conquistarás.

No solo disminuye el tiempo de localizar la falla sino que si la modificación es muy engorrosa. mantenimiento. Un trabajo de encontrar y corregir un error en una "pieza" de código de 1. para minimizar los costos de mantenimiento debemos lograr que cada pieza sea independiente de otra. diremos que el costo de modificación de un sistema puede minimizarse si sus partes son • • fácilmente relacionables con la aplicación modificables separadamente En resumen. Este concepto de "módulos descartables" ha sido utilizado con éxito muchas veces. y modificación. generalmente serán minimizados cuando cada pieza del sistema corresponda a exactamente una pequeña. bien definida pieza del dominio del problema. Finalmente. Por otra parte. podemos afirmar lo siguiente: los costos de implementación. En otras palabras debemos ser capaces de realizar modificaciones al módulo A sin introducir efectos indeseados en el módulo B.Es importante que las partes de un sistema sean manejablemente pequeñas en orden de simplificar el mantenimiento. y cada relación entre las piezas del sistema corresponde a relaciones entre piezas del dominio del problema.000 líneas es muy superior a hacerlo con piezas de 20 líneas. puede reescribirse la pieza completamente. .

la subdivisión de un problema en subproblemas más pequeños. La cuestión es: Dónde y cómo debe dividirse el problema? Qué aspectos del problema deben pertenecer a la misma pieza del sistema. Entenderemos por particionamiento. deben pertenecer a diferentes piezas del sistema sin relación directa. de tal forma que cada subproblema corresponda a una pieza del sistema. y cuales a distintas piezas? El diseño estructurado responde estas preguntas con dos principios básicos: • • Partes del problema altamente interrelacionadas deberán pertenecer a la misma pieza del sistema.Como se logra el costo mínimo con Diseño Estructurado Un buen diseño estructurado es un ejercicio de particionamiento y organización de los componentes de un sistema. . Partes sin relación entre ellas.

Observemos por ejemplo el siguiente diagrama de organización de una empresa . es de utilidad pero no transforma al módulo en una verdadera caja negra. el diseñador debe revisar su contenido ante posibles contingencias como ser comportamientos no deseados ante determinados valores. y que parte está en relación con cual. o produce resultados inesperados. 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. El concepto de caja negra utiliza el principio de abstracción. salidas conocidas. y por ende en el desarrollo de software. Solo conocemos como controlarlos (entradas) y las respuestas que podemos obtener de los artefactos (salidas). un automóvil. En la vida diaria existe innumerable cantidad de ejemplos de uso cotidiano: una radio. y generalmente transformaciones conocidas. Una buena documentación en tales casos. El concepto de Cajas Negras Una caja negra es un sistema (o un componente) con entradas conocidas. 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. Este concepto es de suma utilidad e importancia en la ingeniería en general. En la mayoría de los casos podemos hablar de "cajas grises". es el evitar la introducción de relaciones en el sistema. Igualmente importate. que no existe en el dominio del problema. Comparación entre las estructuras administrativas y el diseño estructurado Uno de los aspectos más interesantes del diseño de programas es la relación que puede establecerse con las estructuras de organización humanas. Los módulos de programas de computadoras pueden variar en un amplio rango de aproximación al ideal de caja negra. Podríamos hablar en todo caso de "cajas blancas". un televisor. particularmente la jerarquía de administración encontrada en la mayoría de las grandes organizaciones. pero del cual no se conoce el contenido en su interior.Otro aspecto importante del diseño estructurado es la organización del sistema. son cajas negras que usamos a diario sin conocer (en general) como funciona en su interior. Lamentablemente muchas veces para poder hacer un uso efectivo de determinado módulo. Debemos decidir como se interrelacionan las partes.

A simple vista podemos apreciar que el presidente de la empresa tiene demasiados subordinados. y susceptible a fallas. Estableciendo un comparación con la estructura de programas. Podemos decir que en una organización perfecta. Los niveles inferiores son los que realizan el trabajo operativo. demasiada complejidad. sea sumamente complejo. . Veamos otro ejemplo Podemos apreciar a simple vista que la tarea de los jefes A. que lo llevará a cometer posibles errores. Su labor consiste en coordinar información entre los subordinados y tomar decisiones. el cual llama a uno que finalmente realizará la tarea. si tenemos un módulo cuya única función es llamar a otro. Podemos establecer una analogía con la estructura de programas y es razonable pensar que un módulo que tenga demasiados módulos subordinados a quienes controlar. los administradores no realizan ninguna tarea operativa. los módulos intermedios podrán comprimirse un único módulo de control. X. Y. podemos argumentar que los módulos de nivel alto en un programa o sistema solamente coordinan y controlan la ejecución de los módulos de menor nivel. y consecuentemente su trabajo involucrará el manejo de demasiados datos y la toma de demasiadas decisiones. es relativamente trivial y podría se comprimida en una sola jefatura. Análogamente. y este a su vez a otro. quienes son los que realizan los cómputos y procesos que el sistema requiere.

Si juntamos los dos problemas. Si asumimos que hemos podemos medir por algún método la complejidad de un problema P (no importa aquí que método). crear un programa combinado. Claramente. y no a otras. si ambas solucionan el mismo problema. .Finalmente observaremos que los administradores suministran a sus subordinados únicamente la información que estrictamente necesitan. Esto es valedero si medimos "grande" y "pequeño" en unidades apropiadas. 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 pequeñas que una sola más grande. Intentaremos tomar dos problemas separados y en lugar de escribir dos programas. diremos que la complejidad del mismo será M(P). y en la medida que esta se incrementa somos susceptibles a cometer un mayor número de errores. Manejo de la complejidad En principio diremos que escribir un programa "grande" generalmente lleva más tiempo que escribir un "pequeño". es que los humanos tenemos inconvenientes para tratar adecuadamente grandes complejidades. En realidad lo que diremos es que es más difícil resolver un problema difícil! . e intentaremos realizar un análisis sobre como disminuir la complejidad de un determinado problema. obtendremos uno mayor que si tomamos los dos por separado. y algoritmos más complejos que otros. 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 tamaño del mismo. El establecimiento de un paralelo entre las estructuras organizativas humanas y los programas de computadora nos será muy útil en el estudio del diseño estructurado. el número de instrucciones de un programa no es una medida de complejidad ya que existe instrucciones más complejas que otras. y que el costo de realizar un programa que resuelva el problema P será C(P). Análogamente los módulos inferiores solo deben tener acceso a la información que necesitan. La razón fundamental para no combinar los problemas.

Es verdadero en cualquier campo de la solución de problemas (matemática. es decir el número 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 módulo. Otro aspecto relacionado con la complejidad es el alcance o amplitud del flujo de control. Es interesante notar que la teoría detrás de la programación estructurada provee el medio de reducir este alcance a una mínima longitud organizando la lógica en combinaciones de operaciones de "secuencia". "decisión". física. se ve altamente influenciada por el tamaño del módulo. Obviamente el problema es mayor ya que existen sentencias más complejas que otras. La cuestión ahora es: Qué es lo complejo para los humanos? En otras palabras: Que aspectos del diseño de sistemas y programas son considerados complejos por el diseñador? Y por extensión Que podemos hacer para realizar sistemas menos complejos? En primer término podemos decir que el tamaño de un módulo es una medida simple de la complejidad. han sido identificados como afectando la complejidad de las sentencias: . e "iteración". implícitos en el enfoque previo. Generalmente un módulo de 1000 sentencias. Vimos que muchos de nuestros problemas en diseño y programación se deben a la limitada capacidad de la mente humana para lidiar con la complejidad.Este fenómeno no es solo válida para el campo de la computación. será más complejo que uno de 10. etc. Tres factores. Complejidad en términos humanos En el punto anterior realizamos un análisis sobre la incidencia de la complejidad en los costos. y como manejarla a través de la subdivisión de un problema en problemas menores.). Todas estas medidas reconocen que la complejidad de los programas percibida por humanos. Por ejemplo las sentencias de decisión son uno de los primeros factores que contribuyen a la complejidad de un módulo. Otro factor de importancia es el "espacio" de vida o alcance de los elementos de dato. esto es el número de sentencias lexicográficamente contiguas que deben examinarse antes de encontrar un sección de código caja-negra con un punto de entrada y un punto de salida.

enfocaremos la atención en aquellas que establecen relaciones intermodulares. dibujaremos entre ambos un asterisco ("*"). la estructura de la información. si solo uno de los flujos es necesario. Peor aún son las fallas en la diferenciación entre codificación y diseño estructural.1. La cantidad de detalle mostrado en el diagrama de flujo de datos variará de problema en problema y de diseñador en diseñador. Las transformaciones son representadas por burbujas (círculos) y los flujos de datos se representan con flechas. Estos factores determinan la probabilidad de error humano en el procesamiento de información de todo tipo. Cada flujo se etiqueta con su contenido. la accesibilidad de la información. muchas veces encuentran difícil de comprender la diferencia entre el procedimiento y la estructura de programas y sistemas. Los diagramas de flujo de datos que usaremos en la etapa de diseño son similares a los utilizados para la etapa del análisis. Este símbolo al igual que en otras disciplinas matemáticas representa el operador "Y" o de conjunción. De igual manera.• • • la cantidad de información que debe ser comprendida correctamente. que representa al operador "O" o de disyunción. 2. Si dos flujos dibujados adyacentemente son ambos necesarios para realizar una determinada transformación (a la cual arriban). utilizaremos el símbolo Å . Mientras que la complejidad de todo tipo de sentencias de programas pueden evaluarse según estos criterios. .2 DIAGRAMAS DE FLUJO DE DATOS. (ver ejemplo en Const/Your) Los diagramas de flujo de datos serán de gran utilidad en el estudio del concepto de cohesión Estructura y Procedimiento Tanto neófitos como veteranos.

Existe un módulo raíz de máximo nivel.La estructura nos da una relación jerárquica de control existente entre los módulos que conforman un programa. en una estructura arborescente. se pueden realizar comparaciones útiles entre dichas estructuras. Notación de los Diagramas de Flujo de control . Un diagrama de estructura en cambio no modela la secuencia de ejecución sino la jerarquía de control existente entre los módulos que conforman el programa. del cual dependen los demás. Diagramas de Flujo y Diagramas de Estructura Normalmente los procedimientos se representan con diagramas de flujo (no confundir con diagramas de flujo de datos) los cuales modelan la secuencia de operaciones que realiza el programa a través del tiempo. En el estudio de la estructura de programas. independientemente del factor tiempo. y las estructuras de las organizaciones humanas.

Notación de los Diagramas de Estructura .

Ejemplo Comparativo entre Diagramas de Procesamiento y de Estructura Diagrama de flujo Diagrama de estructura .

1. Si se bloquean. Por ejemplo. Uno de los ejemplos m´as habituales de los sistemas de tiempo real son los sistemas de control. en los autom´oviles actuales se encuentran multitud de estos sistemas. Los sistemas de tiempo real tienen unas caracter´ısticas propias que hace que su desarrollo sea a´un m´as dif´ıcil que el de la mayor´ıa del resto de los sistemas inform´aticos: . como el sistema de antibloqueo de los frenos (ABS).2. Los sistemas de tiempo real son una clase concreta de sistemas inform´aticos que se pueden definir de manera informal como aquellos sistemas en los que el tiempo de respuesta es crucial para su funcionamiento correcto. Este sistema se encarga de vigilar el funcionamiento de las ruedas del veh´ıculo durante la frenada. inform´atico o no.3 LOS SISTEMAS DE TIEMPO REAL Y SU MODELADO. se liberan moment´aneamente las ruedas para que sigan girando y no se deslicen. en los que un sistema computerizado se encarga de controlar el funcionamiento de otro sistema.

sino en otros dispositivos electrónicos autónomos. los recursos f´ısicos con los que se cuenta. • • • • Tienen el requisito no funcional adicional de los plazos temporales de las respuestas. pueden también estar limitados. ya que es habitual la ausencia de versiones para estos entornos no estándares. como memoria y capacidad de cálculo. no solo en ordenadores tradicionales. cuales son los que fallan. Su funcionamiento depende habitualmente de est´ımulos procedentes del entorno (se suelen clasificar dentro de los llamados sistemas reactivos. . en ocasiones. pasando por un amplio abanico. si no se puede. Es habitual que esos sistemas empotrados impongan fuertes restricciones en varios aspectos. La frecuencia de los est´ımulos exteriores es unas veces peri´odica. Se desarrollan en arquitecturas f´ısicas muy variadas. Este requisito hace necesario el análisis de la planificabilidad del sistema. El desarrollo de sistemas concurrentes es más complejo por la posibilidad de problemas adicionales como el bloqueo. etc. como bibliotecas de funciones o sistemas operativos. Los recursos software. accediendo a recursos comunes y comunicándose y sincronizándose entre ellos. es desconocida. desde veh´ıculos a teléfonos móviles. que establece si se pueden cumplir o no los plazos temporales y. Por un lado. Interactúan directamente con sistemas f´ısicos. lo que incide en una mayor dificultad para encontrar una solución viable. Es muy habitual encontrar sistemas que tienen una relación a muy bajo nivel con dispositivos físicos para lectura de datos para monitorizar los sistemas controlados y para escritura de datos para su control. A este tipo de sistemas de tiempo real se les llama empotrados (embedded real-time systems).• Son sistemas inherentemente concurrentes en los que hay varios flujos de control ejecutándose simultáneamente e interaccionando. que actúan dando respuesta a un est´ımulo exterior). otras sigue una distribución de probabilidad y. suelen estar muy ajustados. la inversión de prioridades.