2.

1 Diseo estructurado de sistemas

El diseo estructurado de sistemas se ocupa de la identificacin, seleccin y
organizacin de los mdulos y sus relaciones. Se comienza con la especificacin
resultante del proceso de anlisis, se realiza una descomposicin del sistema en
mdulos estructurados en jerarquas, con caractersticas tales que permitan la
implementacin de un sistema que no requiera elevados costos de mantenimiento.
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 bsicos.

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

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 informticos 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 ms habituales de los sistemas de tiempo real son los
sistemas de control, en los que un sistema computarizado se encarga de controlar
el funcionamiento de otro sistema, informtico o no. Por ejemplo, en los
automviles 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 momentneamente 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 an ms difcil que el de la mayora del resto de los sistemas
informticos:

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 peridica, 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.