2.

1 DISEO ESTRUCTURADO DE SISTEMAS

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" 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. "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.

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

2.1.1 CONCEPTOS BASICOS. 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.

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. 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". 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. 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.). 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.

2.1.2 DIAGRAMAS DE FLUJO DE DATOS. Los diagramas de flujo de datos que usaremos en la etapa de diseo son similares a los utilizados para la etapa del anlisis. Las transformaciones son representadas por burbujas (crculos) y los flujos de datos se representan con flechas. Cada flujo se etiqueta con su contenido. Si dos flujos dibujados adyacentemente son ambos necesarios para realizar una determinada transformacin (a la cual arriban), dibujaremos entre ambos un asterisco ("*"). Este smbolo al igual que en otras disciplinas matemticas representa el operador "Y" o de conjuncin. De igual manera, si solo uno de los flujos es necesario, utilizaremos el smbolo , que representa al operador "O" o de disyuncin. La cantidad de detalle mostrado en el diagrama de flujo de datos variar de problema en problema y de diseador en diseador. (ver ejemplo en Const/Your) Los diagramas de flujo de datos sern de gran utilidad en el estudio del concepto de cohesin Estructura y Procedimiento Tanto nefitos como veteranos, muchas veces encuentran difcil de comprender la diferencia entre el procedimiento y la estructura de programas y sistemas. Peor an son las fallas en la diferenciacin entre codificacin y diseo estructural.

La estructura nos da una relacin jerrquica de control existente entre los mdulos que conforman un programa. 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 travs del tiempo. Un diagrama de estructura en cambio no modela la secuencia de ejecucin sino la jerarqua de control existente entre los mdulos que conforman el programa, independientemente del factor tiempo. Existe un mdulo raz de mximo nivel, del cual dependen los dems, en una estructura arborescente. En el estudio de la estructura de programas, se pueden realizar comparaciones tiles entre dichas estructuras, y las estructuras de las organizaciones humanas.

Notacin de los Diagramas de Flujo de control

Notacin de los Diagramas de Estructura

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

Diagrama de estructura

2.1.3 LOS SISTEMAS DE TIEMPO REAL Y SU MODELADO. Los sistemas de tiempo real son una clase concreta de sistemas informaticos que se pueden denir de manera informal como aquellos sistemas en los que el tiempo de respuesta es crucial para su funcionamiento correcto. Uno de los ejemplos mas habituales de los sistemas de tiempo real son los sistemas de control, en los que un sistema computerizado se encarga de controlar el funcionamiento de otro sistema, informatico o no. Por ejemplo, en los automoviles actuales se encuentran multitud de estos sistemas, como el sistema de antibloqueo de los frenos (ABS). Este sistema se encarga de vigilar el funcionamiento de las ruedas del vehculo durante la frenada. Si se bloquean, se liberan momentaneamente las ruedas para que sigan girando y no se deslicen. Los sistemas de tiempo real tienen unas caractersticas propias que hace que su desarrollo sea aun mas difcil que el de la mayora del resto de los sistemas informaticos:

Son sistemas inherentemente concurrentes en los que hay varios ujos de control ejecutndose simultneamente e interaccionando, accediendo a recursos comunes y comunicndose y sincronizndose entre ellos. El desarrollo de sistemas concurrentes es ms complejo por la posibilidad de problemas adicionales como el bloqueo, la inversin de prioridades, etc. Interactan directamente con sistemas fsicos. Es muy habitual encontrar sistemas que tienen una relacin a muy bajo nivel con dispositivos fsicos para lectura de datos para monitorizar los sistemas controlados y para escritura de datos para su control. Su funcionamiento depende habitualmente de estmulos procedentes del entorno (se suelen clasicar dentro de los llamados sistemas reactivos, que actan dando respuesta a un estmulo exterior). La frecuencia de los estmulos exteriores es unas veces periodica, otras sigue una distribucin de probabilidad y, en ocasiones, es desconocida. Se desarrollan en arquitecturas fsicas muy variadas, no solo en ordenadores tradicionales, sino en otros dispositivos electrnicos autnomos, desde vehculos a telfonos mviles, pasando por un amplio abanico. A este tipo de sistemas de tiempo real se les llama empotrados (embedded real-time systems). Es habitual que esos sistemas empotrados impongan fuertes restricciones en varios aspectos. Por un lado, los recursos fsicos con los que se cuenta, como memoria y capacidad de clculo, suelen estar muy ajustados, lo que incide en una mayor dicultad para encontrar una solucin viable. Los recursos software, como bibliotecas de funciones o sistemas operativos, pueden tambin estar limitados, ya que es habitual la ausencia de versiones para estos entornos no estndares.

Tienen el requisito no funcional adicional de los plazos temporales de las respuestas. Este requisito hace necesario el anlisis de la planicabilidad del sistema, que establece si se pueden cumplir o no los plazos temporales y, si no se puede, cuales son los que fallan.