INSTITUTO TECNOLÓGICO

Superior de Apatzingán
CARRERA
Ingeniería en informática

DESARROLLO E IMPLEMENTACION DE SISTEMAS DE INFORMACION

UNIDAD
2. Diseño de sistema

TEMA
2.1 Diseño estructurado de sistemas

PRESENTAN
Ramón Morales Huato Ángel Cruz Hernández

DOCENTE
MTI. Monica Reynoso Bucio

APATZINGÁN, MICHOACÁN; MARZO DE 2013.

1

y la interconexión entre los mismos. 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. tiende a transformar el desarrollo de software de una práctica artesanal a una disciplina de ingeniería". sin embargo es necesario que se realice un cambio de enfoque mental al pasar de una etapa a la otra. Una vez que se han establecido los requisitos del software (en el análisis). y finaliza cuando el diseñador ha especificado los componentes del sistema y las relaciones entre los mismos. • • • Eficiencia Mantenibilidad Modificabilidad 1 .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. la persona debe quitarse el sombrero de analista y colocarse el sombrero de diseñador. un conjunto de principios y/o heurísticas que guían la forma en la que se desarrolla el modelo. Al abordar la etapa de diseño. el diseño del software es la primera de tres actividades técnicas: diseño. "Diseño estructurado es el proceso de decidir que componentes.2. Frecuentemente analista y diseñador son la misma persona. Cada actividad transforma la información de forma que finalmente se obtiene un software para computadora válido. o sistema. Objetivos Del Diseño Estructurado "El diseño estructurado. y prueba. 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. 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. codificación. proceso. 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.

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

bien definida pieza del dominio del problema. para minimizar los costos de mantenimiento debemos lograr que cada pieza sea independiente de otra. mantenimiento. En otras palabras debemos ser capaces de realizar modificaciones al módulo A sin introducir efectos indeseados en el módulo B. podemos afirmar lo siguiente: los costos de implementación. y modificación. 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. No solo disminuye el tiempo de localizar la falla sino que si la modificación es muy engorrosa. generalmente serán minimizados cuando cada pieza del sistema corresponda a exactamente una pequeña.error en una "pieza" de código de 1. 1 . Finalmente. puede reescribirse la pieza completamente. Por otra parte. Este concepto de "módulos descartables" ha sido utilizado con éxito muchas veces.000 líneas es muy superior a hacerlo con piezas de 20 líneas. y cada relación entre las piezas del sistema corresponde a relaciones entre piezas del dominio del problema.

la subdivisión de un problema en subproblemas más pequeños. Entenderemos por particionamiento. 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. 1 .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. 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. Partes sin relación entre ellas. deben pertenecer a diferentes piezas del sistema sin relación directa. de tal forma que cada subproblema corresponda a una pieza del sistema.

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

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

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

física. 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. Generalmente un módulo de 1000 sentencias. "decisión". implícitos en el enfoque previo. han sido identificados como afectando la complejidad de las sentencias: 1 . Todas estas medidas reconocen que la complejidad de los programas percibida por humanos. e "iteración". será más complejo que uno de 10. Es verdadero en cualquier campo de la solución de problemas (matemática. Otro factor de importancia es el "espacio" de vida o alcance de los elementos de dato. Por ejemplo las sentencias de decisión son uno de los primeros factores que contribuyen a la complejidad de un módulo.). Otro aspecto relacionado con la complejidad es el alcance o amplitud del flujo de control. Tres factores. 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. 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". 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. 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. Complejidad en términos humanos En el punto anterior realizamos un análisis sobre la incidencia de la complejidad en los costos.Este fenómeno no es solo válida para el campo de la computación. etc. 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. y como manejarla a través de la subdivisión de un problema en problemas menores.

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

en una estructura arborescente. y las estructuras de las organizaciones humanas. Notación de los Diagramas de Flujo de control 1 . En el estudio de la estructura de programas. 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. Existe un módulo raíz de máximo nivel. 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. independientemente del factor tiempo.La estructura nos da una relación jerárquica de control existente entre los módulos que conforman un programa. se pueden realizar comparaciones útiles entre dichas estructuras.

Notación de los Diagramas de Estructura 1 .

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

en los que un sistema computerizado se encarga de controlar el funcionamiento de otro sistema. Este sistema se encarga de vigilar el funcionamiento de las ruedas del veh´ıculo durante la frenada. como el sistema de antibloqueo de los frenos (ABS). Por ejemplo. inform´atico o no.3 LOS SISTEMAS DE TIEMPO REAL Y SU MODELADO. en los autom´oviles actuales se encuentran multitud de estos sistemas.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. se liberan moment´aneamente las ruedas para que sigan girando y no se deslicen. Uno de los ejemplos m´as habituales de los sistemas de tiempo real son los sistemas de control. Si se bloquean.1. 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: 1 .

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