Está en la página 1de 23

Anlisis Y Diseo estructurado.

El anlisis estructurado, como todos los dems mtodos de anlisis de requisitos, es una
actividad de construccin de modelos. Mediante una notacin que es nica de este mtodo,
se crean modelos que reflejan el flujo y el contenido de la informacin (datos y control); se
parte el sistema funcionalmente y, segn los distintos comportamientos, se establece la
esencia de lo que se debe construir.
La tarea del anlisis de sistemas, conlleva ms que slo realizar anlisis de requisitos, pero
es en eso donde se focalizar la discusin.
Una de las principales labores del analista es descubrir detalles y documentar la poltica de
un negocio que pudiera existir slo en forma implcita, "transmitidas de generacin en
generacin" por los usuarios, nunca documentadas formalmente. El analista debe distinguir
entre sntomas, problemas del usuario y causas. Con sus conocimientos de la tecnologa de
los computadores, el analista debe ayudar al usuario a explorar aplicaciones novedosas y
ms tiles de stos as como nuevas formas de hacer negocios. Aunque muchos de los
sistemas antiguos slo se limitaban a perpetuar el negocio original del usuario, pero a
velocidades electrnicas, hoy en da los analistas se enfrentan al desafo de ayudar al
usuario a encontrar productos y mercados radicalmente innovadores, con la ayuda del
computador.
Diseo.

El diseo de software es un proceso mediante el que se traducen los requisitos en una


representacin del software. Inicialmente, la representacin describe una visin holstica del
software. Posteriores refinamientos conducen a una representacin de diseo que se acerca
mucho al cdigo fuente.
En el diseo se realizan dos pasos. El diseo preliminar se centra en la transformacin de
los requisitos en los datos y arquitectura del software. El diseo detallado se ocupa del
refinamiento de la representacin arquitectnica que lleva a una estructura de datos
detallada y a las representaciones algortmicas del software.
Dentro del contexto de los diseos preliminar y detallado, se llevan a cabo varias
actividades de diseo diferentes. Adems del diseo de datos, del diseo arquitectnico y
del diseo procedimental, muchas aplicaciones requieren de un diseo de la interfaz. El
diseo de la interfaz establece la disposicin y los mecanismos para la interaccin hombre
mquina (no cubierto por las herramientas del diseo estructurado).

Fundamentos del Anlisis y Diseo.


Abstraccin.

Cuando se considera una solucin modular para cualquier problema, pueden formularse
muchos niveles de abstraccin. En el nivel superior de abstraccin, se establece una
solucin en trminos amplios, usando el lenguaje del entorno del problema. En los niveles
inferiores de abstraccin se toma una orientacin ms procedimental. La terminologa
orientada al problema se acompaa con una terminologa orientada a la implantacin, en un
esfuerzo para establecer una solucin. Por ltimo, en el nivel ms bajo de abstraccin, se
establece la solucin de forma que pueda implementarse directamente.
Refinamiento

El refinamiento sucesivo es una primera estrategia de diseo descendente (propuesta por


Niklaus Wirth). Un programa se desarrolla en niveles sucesivos de refinamiento de los
detalles procedimentales. Se desarrolla una jerarqua descomponiendo una declaracin
macroscpica de una funcin en forma sucesiva hasta que se llega a las sentencias del
lenguaje de programacin. Cada paso de refinamiento implica algunas decisiones de diseo.
Es importante que el programador sea consciente de sus decisiones y de la existencia de
soluciones alternativas.
Modularidad

Se ha dicho que modularidad es el atributo individual del software que permite a un


programa ser intelectualmente manejable. El software monoltico (compuesto por slo un
mdulo) no puede ser fcilmente abarcado por un lector. El nmero de caminos de control,
la expansin de referencias, el nmero de variables y la complejidad global podran hacer
imposible su correcta comprensin.
La modularidad se deriva naturalmente de un principio elemental para manejar la
complejidad: divide y vencers.

Diseo Modular Efectivo.

La calidad del diseo debe ser una meta para el diseador. El diseo estructurado ofrece
guas para apoyar al diseador a determinar mdulos, y sus interconexiones, que mejor
realizarn los requerimientos especificados por el analista. Las dos reglas ms importantes
son las referentes al acoplamiento y la cohesin.

Cohesin.

Grado en el cul los componentes de un mdulo (tpicamente las instrucciones individuales


que lo conforman) son necesarios y suficientes para llevar a cabo una sola funcin bien
definida. En la prctica, esto significa que el diseador debe asegurarse de no fragmentar
los procesos esenciales en mdulos, y tambin debe asegurarse de no juntar procesos no
relacionados en mdulos sin sentido. Los mejores mdulos son aquellos que son
funcionalmente cohesivos (es decir, mdulos en los cuales cada instruccin es necesaria
para poder llevar a cabo una tarea bien definida). Los peores mdulos son los que son
coincidentalmente cohesivos (es decir, donde sus instrucciones no tienen una relacin
significativa entre uno y otro).

Los grados de cohesin, de menor a mayor son:

a. Cohesin Coincidental. No existe una relacin significativa entre los elementos del
mdulo.
b. Cohesin Lgica. La relacin entre los elementos del mdulo est basada en obtener
ventajas en el procesamiento, por ejemplo, todos manipulan el mismo dato. Normalmente
esto implica tener un cdigo truculento o compartido, que degrada los propsitos de un
buen diseo.
c. Cohesin Temporal. Los elementos del mdulo constituyen un conjunto que se ejecuta
secuencialmente en un punto fijo en el tiempo. Aunque tiende, a veces, a confundirse con la
cohesin lgica, la diferencia est en que este tipo de mdulo s ms simple y se ejecuta sin
la intervencin de otras aplicaciones.
d. Cohesin Comunicacional. Los elementos del mdulo hacen referencia al mismo
conjunto de datos. Aqu se presenta un grado "aceptable" de cohesin.
e. Cohesin Secuencial. Implica que la salida de un elemento es la entrada para el prximo.

f. Cohesin Funcional. Aqu, todos los elementos del mdulo estn orientados a la
realizacin de una funcin nica.

Acoplamiento.

Grado en el cul los mdulos se interconectan o se relacionan entre ellos. Entre ms fuerte
sea el acoplamiento entre mdulos en un sistema, ms difcil es implantarlo y mantenerlo,
pues entonces se necesitar un estudio cuidadoso para la modificacin de algn mdulo o
mdulos. En la prctica, esto significa que cada mdulo debe tener interfaces sencillas y
limpias con otros, y que se debe compartir un nmero mnimo de datos entre mdulos.
Tambin significa que un mdulo dado no debe modificar la lgica interna o los datos de
algn otro mdulo; lo que se conoce como una conexin patolgica.

Tamao del Mdulo.

De ser posible, cada mdulo debe ser lo suficientemente pequeo como para caber en una
sola pgina ( o para que se pueda desplegar en una sola pantalla). Desde luego, a veces no
es posible determinar qu tan grande va a ser un mdulo hasta haberlo escrito, pero las
actividades iniciales de diseo a menudo darn al diseador una buena pista de que el
mdulo ser grande o complejo. Si es as, debe subdividirse en uno o ms niveles de
submdulos.

Alcance del control.

El nmero de subordinados inmediatos que un mdulo administrador puede llamar se


conoce como el alcance del control. Un mdulo no debe poder llamar a ms de una media
docena de mdulos de nivel inferior. La razn es evitar la complejidad: si el mdulo tuviera,
por ejemplo, que llamar a 25 mdulos de nivel inferior, entonces seguramente contendr
tanta lgica compleja que nadie lo entender (un sin fin de if-then anidados). La solucin es
introducir un nivel intermedio de mdulos administradores, como hara un administrador de
una organizacin humana.

Alcance del efecto/alcance del control.

Esta regla sugiere que cualquier mdulo afectado por el resultado de alguna decisin debe
ser subordinado (aunque no necesariamente un subordinado inmediato) del mdulo que
toma la decisin. Es un tanto anlogo a la regla de administracin que dice que cualquier
empleado afectado por los resultados de la decisin de algn administrador (es decir, dentro
del alcance de efecto de la decisin), debe estar dentro del alcance de control del
administrador (es decir trabajando entre la jerarqua de personas que se reportan con el
administrador). Violar esta regla en un ambiente de diseo estructurado usualmente lleva a
un paso innecesario de banderas y condiciones (lo cual incrementa el acoplamiento entre
mdulos), la toma redundante de decisiones o (en el peor de los casos) conexiones
patolgicas entre mdulos.

Parsimonia.

Se refiere a la economa de recursos que se emplean para la obtencin de un resultado. Esto


es, slo se debe realizar lo que se pide. Mientras mayor la parsimonia, mejor el diseo.

Manejo Autnomo de Errores.

Los mdulos deben tener la capacidad de manejar sus propias condiciones de error, tanto en
la deteccin como en la correccin de los mismos. De no ser as, el manejo de banderas
(flags) de control y la transmisin de datos errneos a otros mdulos aumentar
considerablemente el acoplamiento.

Diagramas de Flujo de Datos.

Los diagramas de flujos de datos tambin son llamados Carta de Burbujas, DFD, Diagramas
de burbujas, modelo de proceso, diagrama de flujo de trabajo o modelo de funcin en la
literatura computacional.

A medida que la informacin se mueve a travs del software, es modificada por una serie de
transformaciones. El DFD es una tcnica grfica que representa el flujo de la informacin y
las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida.

Componentes de un DFD.

El proceso.
Sinnimos comunes son burbuja, funcin o transformacin.
El proceso muestra una parte del sistema que transforma entradas en salidas; es decir,
muestra cmo es que una o ms entradas se transforman en salidas. El proceso se representa
grficamente como un valo o un rectngulo con esquinas redondeadas. Estas diferencias
son slo de forma, y se debe optar por alguna de ellas y utilizarla en forma consistente.

Representaciones utilizadas para procesos, la de la izquierda corresponde a la utilizada por


Gane y Sarson, y la de la derecha es utilizada por Ward y Mellor, as como por Yourdon y
De Marco.

Ntese que el proceso se nombra con una palabra o frase, que intentan dar una primera
aproximacin de lo que hacen, por ejemplo VALIDAR ENTRADA, CONTROL
TEMPERATURA, etc.

El flujo.
Un flujo se representa grficamente por medio de una flecha que entra o sale de un proceso.
El flujo se usa para describir el movimiento de bloques o paquetes de informacin de una
parte del sistema a otra. Por ello, los flujos representan datos en movimiento, mientras que
los almacenes representan datos en reposo.

Flujo de Datos, que lleva el Rut de un cliente. Se utiliza esta presentacin en casi todos los
formalismos propuestos.

En la mayora de los sistemas que se modelan, los flujos realmente representarn datos, es
decir, bits, caracteres, mensajes, nmeros de punto flotante y los diversos otros tipos de
informacin con los que se suele tratar en sistemas computarizados. Esto no significa que
los DFD no sean una herramienta til en el modelado de procesos no automatizados
computacionalmente, como por ejemplo una linea de ensamblado.

Este es la representacin dada por Gane y Sarson a un flujo de materiales. Con esto, se
representa que se ingresan datos o materiales de tipo no computacional. Es til en el
modelamiento de procesos productivos.

Los flujos de datos tienen un nombre el que representa el significado del paquete de
informacin que se mueve a lo largo del flujo.

Los flujos de datos pueden converger o divergir en un DFD.

El almacn.
El almacn se utiliza para modelar un conjunto de paquetes de datos en reposo. Se denota
por dos lneas paralelas u otras alternativas grficas. De modo caracterstico, el nombre que
se usa para un almacn es el plural del que se usa para los paquetes que entran y salen del
almacn por medio de flujos.

Representaciones utilizadas para almacenes de datos, la de la izquierda corresponde a la


utilizada por Gane y Sarson, y la de la derecha es utilizada por Ward y Mellor, as como por
Yourdon y De Marco.

A menudo, los almacenes de datos se implementan como archivos o bases de datos.


Tambin pueden ser implementados en sistemas manuales como archivadores, carpetas, etc.

El Terminador.
Un terminador grficamente se representa como un rectngulo. Los terminadores
representan entidades externas con las cuales el sistema se comunica. Comnmente un
terminador es una persona o un grupo, por ejemplo una organizacin externa o una agencia
gubernamental, o un grupo o departamento que est dentro de la misma compaa u
organizacin, pero fuera del control del sistema que se est modelando. En algunos casos, el
terminador puede ser otro sistema.

Terminador o "External", que en este caso representa al usuario del sistema. Se utiliza esta
presentacin en casi todos los formalismos propuestos.

Suele ser muy fcil identificar los terminadores en el sistema que se est modelando. A
veces el terminador es el usuario, que nos dice "pienso entregar los datos A, B y C al
sistema y espero que ste me entregue los datos X, Y y Z". En otros casos, el usuario se
considera parte del sistema y ayudar a identificar los terminadores relevantes.

Gua para la construccin de un DFD.

a. Escoger nombres con significado para los procesos, flujos, almacenes y terminadores.
b. Numerar los procesos.
c. Redibujar el DFD tantas veces como sea necesario estticamente.
d. Evitar los DFD excesivamente complejos.
e. Asegurarse de que el DFD sea internamente consistente y que tambin lo sea con
cualesquiera DFD relacionado con l. (evitar procesos con slo entradas o salidas, as como
flujos y procesos no etiquetados).

DFD por niveles.

Se organiza el DFD global en una serie de niveles de modo que cada uno proporcione
sucesivamente ms detalles sobre una porcin del nivel anterior. Esto es anlogo a la
organizacin de mapas en un atlas.

El DFD de primer nivel consta slo de una burbuja, que representa el sistema completo; los
flujos de datos muestran las interfaces entre el sistema y los terminadores externos (junto
con los almacenes externos que pudiera haber). Este DFD especial se conoce como
Diagrama de Contexto.

El DFD que sigue del diagrama de Contexto se conoce como la figura 0. Representa la vista
de ms alto nivel de las principales funciones del sistema, al igual que sus principales
interfaces.

Ejemplo de un diagrama de contexto.

Diagrama nivel 0. Aqu se presenta la primera descomposicin funcional del sistema.

Diagrama Nivel 1. En este caso se presenta una descomposicin funcional del mdulo 1.

Diagrama nivel 2. En este caso se presenta una descomposicin funcional del mdulo 1.3

Diccionario de Datos.

La segunda herramienta de modelado importante, aunque no tiene la presencia y atractivo


grfico de los DFD, los diagramas Entidad-Relacin o los diagramas de estructuras, es el
diccionario de datos.

El diccionario de datos es un listado organizado de todos los datos pertinentes al sistema,


con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un
entendimiento comn de todas las entradas, salidas, componentes de los almacenes y
clculos intermedios. El diccionario de datos define los datos haciendo lo siguiente:

Describe el significado de los flujos y almacenes que se muestran en los DFD.

Describe la composicin de agregados de paquetes de datos que se mueven a lo largo


de los flujos, es decir, paquetes complejos que pueden descomponerse en unidades
ms elementales.

Describen la composicin de los paquetes de datos en los almacenes.

Especifica los valores y unidades relevantes de piezas elementales de informacin en


los flujos de datos y en los almacenes de datos.

Describe los detalles de las relaciones entre almacenes que se enfatizan en un


diagrama de entidad-relacin u otro modelo de datos.

Notacin del diccionario de datos.

Existen muchos esquemas de notacin comunes utilizados. Este es uno de los ms


utilizados.

= : est compuesto de
+:y
( ) :optativo (puede estar presente o ausente)
{ } : iteracin
[ ] : seleccionar una de varias alternativas
* * : comentario
@ : identificador (campo clave) para un almacn

| : separa opciones alternativas en la construccin

Por ejemplo, podemos definir

nombre = ttulo de cortesa + nombre + (segundo nombre) + apellido paterno + apellido


materno

ttulo de cortesa = [Sr. | Srta. | Sra. | Dr. | Profesor ]

nombre = {caracter legal}


apellido paterno = {caracter legal}
apellido materno = {caracter legal}

Completitud del Diccionario de Datos.

Para verificar varios detalles de correccin del sistema independientemente del usuario, el
analista puede asegurarse que el diccionario est completo y sea consistente y no
contradictorio. As, puede plantearse las siguientes preguntas:

Se ha definido en el diccionario cada flujo del DFD?

Se han definido todos los componentes de los datos en el diccionario?

Se ha definido ms de una vez algn dato?

Se ha utilizado la notacin correcta para todas las definiciones del diccionario de


datos?

Hay elementos de datos en el diccionario que no estn relacionados con el DFD u


otros diagramas?

Especificaciones de Proceso.

La especificacin del proceso es la descripcin de qu es lo que sucede en cada burbuja


primitiva en el nivel ms bajo en un DFD. Tambin es llamado Minispec o
miniespecificacin. Su propsito es definir lo que debe hacerse para transformar entradas en
salidas.

La forma ms utilizada para realizar las especificaciones de procesos es el lenguaje


estructurado, pero se puede utilizar cualquier mtodo que satisfaga dos requerimientos
cruciales:

La especificacin del proceso debe expresarse de una manera que puedan verificar
tanto el usuario como el analista. Precisamente por esta razn se evita el lenguaje
narrativo como herramienta de especificacin: es ambiguo, sobre todo si describe
acciones alternativas y acciones repetitivas. Por naturaleza, tambin tiende a causar
gran confusin cuando expresa condiciones booleanas compuestas (esto es
combinaciones de los operadores AND, OR y NOT).

El proceso debe especificarse en una forma que pueda ser comunicada efectivamente
al pblico amplio que est involucrado. A pesar de que el analista es tpicamente
quien escribe la especificacin del proceso, habitualmente ser un pblico bastante

diverso de usuarios, administradores, auditores, personal de control de calidad y


otros, el que leer la especificacin del proceso.

Lenguaje estructurado.

Tambin conocido como espaol estructurado, es el ms utilizado para realizar


especificaciones de procesos. Es un subconjunto del espaol, como lo son del ingls
muchos de los lenguajes de programacin.

Una frase del lenguaje estructurado puede ser una expresin algebraica:

x= (y*z)/(q+10)

o una frase imperativa consistente de un verbo y un objeto.

Se sugiere seleccionar una cantidad de verbos reducida, como

Conseguir (aceptar, leer)


poner (mostrar, desplegar, escribir)
encontrar (buscar, localizar)
sumar
restar
dividir
multiplicar

calcular
borrar
validar
mover
reemplazar
ordenar
Adems se utilizan las estructuras de control de la programacin estructurada (ifthen-else, while-do, repeat-until, for-do y la concatenacin de sentencias) traducidas
al espaol:

Si condicin 1 entonces

bloque
sino
bloque alternativo
fin-si

mientras condicin hacer


bloque
fin-mientras

repetir
bloque
hasta condicin

para var desde inicio hasta fin hacer


bloque
fin-para
En general, se pueden hacer adaptaciones a lenguajes como Pascal o SQL para fines
de acceso a datos, de modo de utilizarlos en las especificaciones de procesos.
Tambin se utilizan tablas de decisin y diagramas de flujo en las minispecs.

Diagramas de Estructura.

A travs de los diagramas de estructura se puede modelar el control del sistema, as


como la descomposicin de las funciones en forma jerrquica.

En un diagrama de estructura, los mdulos son representados por rectngulos. Se


representa la dependencia (jerrquica) entre mdulos, las instancias de repeticin y
decisin as como el flujo de los datos de control y otros a travs de las funciones.
Los mdulos del diagrama de estructura son los mismos que los que aparecen en los
distintos niveles del DFD, vistos en otra dimensin.

Aunque el mdulo padre de un diagrama de estructura o mdulo raz puede tener dos
o n hijos en su segundo nivel de descomposicin, se recomienda descomponer este
mdulo en 3 hijos, cada uno de ellos dar origen a una rama en el diagrama de
estructura, es decir, cada uno de ellos a su vez podr tener otros mdulos hijos.

Estas ramas son:

a. rama aferente: su objetivo es capturar u obtener la informacin proveniente


generalmente del usuario.
b. rama de proceso: transforma la informacin capturada, es decir las entradas, en las
salidas del sistema.
c. rama eferente: su objetivo es entregar las salidas del sistema al usuario o al
terminador que corresponda.

Documentacin.

La documentacin del diseo es vital para garantizar su legibilidad y correcto


entendimiento en la etapa de construccin o codificacin, adems de permitir
detectar errores de consistencia. Debe entenderse que el diseo debe ser perfectible
por personas ajenas a quienes lo construyeron, por lo que la documentacin no puede
faltar. Por otro lado, no hay que olvidar que el diseo constituye la especificacin de
la etapa subsiguiente.

Para documentar el diseo se tienen que documentar todos los elementos que
aparecen en los diagramas de flujos de datos y disgramas de estructuras, esto es:
Terminadores, almacenes de datos, flujos de datos y procesos.
Esquema de documentacin Terminadores.

Terminador:
Descripcin:
Flujos
Flujos que recibe.

que

genera:

Esquema Documentacin Flujos de Datos.

Flujo:
Descripcin
Compuesto
Parte
Fuente:
Destino:
[Volumen:]

Narrativa:
por:
de:

Esquema Documentacin Procesos.

Nivel:
Nmero:
Nombre:
Parte
Compuesto
Descripcin

de:
por:
Narrativa:

Entradas:
Salidas:
Miniespecificacin:
Esquema Documentacin Almacenes de Datos.

Nombre:
Descripcin
Contenido:
Flujos
Flujos Salientes:

Narrativa:
entrantes:

Esquema Documentacin DFD.

Nivel
Diagrama
Terminadores:
Flujos
Almacenes
Procesos:

Diagrama:
Proceso:
de
de

Datos:
Datos:

Esquema Documentacin Diagramas de Estructura.

Diagrama
Terminadores:
Flujos
Almacenes
Procesos:

Proceso:
de
de

Esquema Documentacin Elementos de Datos.

Nombre:
Alias:
Descripcin:
Dominio:
Si es discreto:
Si es discreto:
Valor

Significado

Datos:
Datos:

Si es continuo:
Tipo

Largo

Rango

También podría gustarte