Análisis y Diseño Estructurado
Contenidos
Definiciones.
Análisis.
El análisis estructurado, como todos los
demás métodos de análisis de requisitos, es una actividad de construcción de
modelos. Mediante una notación que es única de este método, se crean modelos que
reflejan el flujo y el contenido de la información (datos y control); se parte
el sistema funcionalmente y, según los distintos comportamientos, se establece
la esencia de lo que se debe construir.
La tarea del análisis de sistemas, conlleva más que sólo realizar análisis de
requisitos, pero es en eso donde se focalizará la discusión.
Una de las principales labores del analista es descubrir detalles y
documentar la política de un negocio que pudieran existir sólo en forma
implícita, "transmitidas de generación en generación" por los usuarios, nunca
documentadas formalmente. El analista debe distinguir entre síntomas, problemas
del usuario y causas. Con sus conocimientos de la tecnología de los
computadores, el analista debe ayudar al usuario a explorar aplicaciones
novedosas y más útiles de éstos así como nuevas formas de hacer negocios. Aunque
muchos de los sistemas antiguos sólo se limitaban a perpetuar el negocio
original del usuario, pero a velocidades electrónicas, hoy en día los analistas
se enfrentan al desafío de ayudar al usuario a encontrar productos y mercados
radicalmente innovadores, con la ayuda del computador.
Diseño.
El diseño de software es un proceso mediante
el que se traducen los requisitos en una representación del software.
Inicialmente, la representación describe una visión holística del software.
Posteriores refinamientos conducen a una representación de diseño que se acerca
mucho al código fuente.
En el diseño se realizan dos pasos. El diseño preliminar se centra en la
transformación de los requisitos en los datos y arquitectura del software. El
diseño detallado se ocupa del refinamiento de la representación arquitectónica
que lleva a una estructura de datos detallada y a las representaciones
algorítmicas del software.
Dentro del contexto de los diseños preliminar y detallado, se llevan a cabo
varias actividades de diseño diferentes. Además del diseño de datos, del diseño
arquitectónico y del diseño procedimental, muchas aplicaciones requieren de un
diseño de la interfaz. El diseño de la interfaz establece la disposición y los
mecanismos para la interacción hombre máquina (no cubierto por las herramientas
del diseño estructurado).
Fundamentos del Análisis y Diseño.
Abstracción.
Cuando se considera una solución modular
para cualquier problema, pueden formularse muchos niveles de abstracción. En el
nivel superior de abstracción, se establece una solución en términos amplios,
usando el lenguaje del entorno del problema. En los niveles inferiores de
abstracción se toma una orientación más procedimental. La terminología orientada
al problema se acompaña con una terminología orientada a la implantación, en un
esfuerzo para establecer una solución. Por último, en el nivel más bajo de
abstracción, se establece la solución de forma que pueda implementarse
directamente.
Refinamiento
El refinamiento sucesivo es una primera
estrategia de diseño descendente (propuesta por Niklaus Wirth). Un programa se
desarrolla en niveles sucesivos de refinamiento de los detalles procedimentales.
Se desarrolla una jerarquía descomponiendo una declaración macroscópica de una
función en forma sucesiva hasta que se llega a las sentencias del lenguaje de
programación. Cada paso de refinamiento implica algunas decisiones de diseño. 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 monolítico (compuesto por sólo un módulo) no puede ser
fácilmente abarcado por un lector. El número de caminos de control, la expansión
de referencias, el número de variables y la complejidad global podrían hacer
imposible su correcta comprensión.
La modularidad se deriva naturalmente de un principio elemental para manejar
la complejidad: divide y vencerás.
Diseño Modular Efectivo.
La calidad del diseño debe ser
una meta para el diseñador. El diseño estructurado ofrece guías para apoyar al
diseñador a determinar módulos, y sus interconexiones, que mejor realizarán los
requerimientos especificados por el analista. Las dos reglas más importantes son
las referentes al acoplamiento y la cohesión.
Cohesión.
Grado en el cuál los componentes de un
módulo (típicamente las instrucciones individuales que lo conforman) son
necesarios y suficientes para llevar a cabo una sola función bien definida. En
la práctica, esto significa que el diseñador debe asegurarse de no fragmentar
los procesos esenciales en módulos, y también debe asegurarse de no juntar
procesos no relacionados en módulos sin sentido. Los mejores módulos son
aquellos que son funcionalmente cohesivos (es decir, módulos en los cuales cada
instrucción es necesaria para poder llevar a cabo una tarea bien definida). Los
peores módulos son los que son coincidentalmente cohesivos (es decir, donde sus
instrucciones no tienen una relación significativa entre uno y otro).
Los grados de cohesión, de menor a mayor son:
a. Cohesión Coincidental. No existe una relación significativa entre los
elementos del módulo.
b. Cohesión Lógica. La relación entre los elementos del módulo está
basada en obtener ventajas en el procesamiento, por ejemplo, todos manipulan el
mismo dato. Normalmente esto implica tener un código truculento o compartido,
que degrada los propósitos de un buen diseño.
c. Cohesión Temporal. Los elementos del módulo constituyen un conjunto
que se ejecuta secuencialmente en un punto fijo en el tiempo. Aunque tiende, a
veces, a confundirse con la cohesión lógica, la diferencia está en que este tipo
de módulo s más simple y se ejecuta sin la intervención de otras aplicaciones.
d. Cohesión Comunicacional. Los elementos del módulo hacen referencia
al mismo conjunto de datos. Aquí se presenta un grado "aceptable" de cohesión.
e. Cohesión Secuencial. Implica que la salida de un elemento es la
entrada para el próximo.
f. Cohesión Funcional. Aquí, todos los elementos del módulo están
orientados a la realización de una función única.
Acoplamiento.
Grado en el cuál los módulos se
interconectan o se relacionan entre ellos. Entre más fuerte sea el acoplamiento
entre módulos en un sistema, más difícil es implantarlo y mantenerlo, pues
entonces se necesitará un estudio cuidadoso para la modificación de algún módulo
o módulos. En la práctica, esto significa que cada módulo debe tener interfaces
sencillas y limpias con otros, y que se debe compartir un número mínimo de datos
entre módulos. También significa que un módulo dado no debe modificar la lógica
interna o los datos de algún otro módulo; lo que se conoce como una conexión
patológica.
Tamaño del Módulo.
De ser posible, cada módulo debe
ser lo suficientemente pequeño como para caber en una sola página ( 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 módulo hasta haberlo escrito, pero las
actividades iniciales de diseño a menudo darán al diseñador una buena pista de
que el módulo será grande o complejo. Si es así, debe subdividirse en uno o más
niveles de submódulos.
Alcance del control.
El número de subordinados
inmediatos que un módulo administrador puede llamar se conoce como el alcance
del control. Un módulo no debe poder llamar a más de una media docena de módulos
de nivel inferior. La razón es evitar la complejidad: si el módulo tuviera, por
ejemplo, que llamar a 25 módulos de nivel inferior, entonces seguramente
contendrá tanta lógica compleja que nadie lo entenderá (un sin fin de if-then
anidados). La solución es introducir un nivel intermedio de módulos
administradores, como haría un administrador de una organización humana.
Alcance del efecto/alcance del control.
Esta regla
sugiere que cualquier módulo afectado por el resultado de alguna decisión debe
ser subordinado (aunque no necesariamente un subordinado inmediato) del módulo
que toma la decisión. Es un tanto análogo a la regla de administración que dice
que cualquier empleado afectado por los resultados de la decisión de algún
administrador (es decir, dentro del alcance de efecto de la decisión), debe
estar dentro del alcance de control del administrador (es decir trabajando entre
la jerarquía de personas que se reportan con el administrador). Violar esta
regla en un ambiente de diseño estructurado usualmente lleva a un paso
innecesario de banderas y condiciones (lo cual incrementa el acoplamiento entre
módulos), la toma redundante de decisiones o (en el peor de los casos)
conexiones patológicas entre módulos.
Parsimonia.
Se refiere a la economía de recursos que
se emplean para la obtención de un resultado. Esto es, sólo se debe realizar lo
que se pide. Mientras mayor la parsimonia, mejor el diseño.
Manejo Autónomo de Errores.
Los módulos deben tener la
capacidad de manejar sus propias condiciones de error, tanto en la detección
como en la corrección de los mismos. De no ser así, el manejo de banderas
(flags) de control y la transmisión de datos erróneos a otros módulos aumentará
considerablemente el acoplamiento.
Diagramas de Flujo de Datos.
Los diagramas de flujos de
datos también son llamados Carta de Burbujas, DFD, Diagramas de burbujas, modelo
de proceso, diagrama de flujo de trabajo o modelo de función en la literatura
computacional.
A medida que la información se mueve a través del software, es modificada por
una serie de transformaciones. El DFD es una técnica gráfica que representa el
flujo de la información y las transformaciones que se aplican a los datos al
moverse desde la entrada hasta la salida.
Componentes de un DFD.
El proceso.
Sinónimos comunes son burbuja, función o
transformación.
El proceso muestra una parte del sistema que transforma entradas en
salidas; es decir, muestra cómo es que una o más entradas se transforman en
salidas. El proceso se representa gráficamente como un óvalo o un rectángulo con
esquinas redondeadas. Estas diferencias son sólo 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.
Nótese que el proceso se nombra con una palabra o frase, que intentan dar una
primera aproximación de lo que hacen, por ejemplo VALIDAR ENTRADA, CONTROL
TEMPERATURA, etc.
El flujo.
Un flujo se representa gráficamente 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 información 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 presentación en casi todos los formalismos
propuestos.
En la mayoría de los sistemas que se modelan, los flujos realmente
representarán datos, es decir, bits, caracteres, mensajes, números de punto
flotante y los diversos otros tipos de información 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 representación
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 información que se mueve a lo largo del flujo.
Los flujos de datos pueden converger o divergir en un DFD.
El almacén.
El almacén se utiliza para modelar un
conjunto de paquetes de datos en reposo. Se denota por dos líneas paralelas u
otras alternativas gráficas. De modo característico, el nombre que se usa para
un almacén es el plural del que se usa para los paquetes que entran y salen del
almacén 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. También pueden ser implementados en sistemas manuales como archivadores,
carpetas, etc.
El Terminador.
Un terminador gráficamente se
representa como un rectángulo. Los terminadores representan entidades externas
con las cuales el sistema se comunica. Comúnmente un terminador es una persona o
un grupo, por ejemplo una organización externa o una agencia gubernamental, o un
grupo o departamento que esté dentro de la misma compañía u organización, 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 presentación en
casi todos los formalismos propuestos.
Suele ser muy fácil 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.
Guía para la construcción 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 estéticamente.
d. Evitar los DFD excesivamente complejos.
e. Asegurarse de que el DFD sea internamente consistente y que también
lo sea con cualesquiera DFD relacionado con él. (evitar procesos con sólo
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 más detalles
sobre una porción del nivel anterior. Esto es análogo a la organización de mapas
en un atlas.
El DFD de primer nivel consta sólo 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 más 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 descomposición funcional del sistema.
Diagrama Nivel 1. En este
caso se presenta una descomposición funcional del módulo 1.
Diagrama nivel 2. En este
caso se presenta una descomposición funcional del módulo 1.3
Diccionario de Datos.
La segunda herramienta de modelado
importante, aunque no tiene la presencia y atractivo gráfico de los DFD, los
diagramas Entidad-Relación 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 común de todas las entradas,
salidas, componentes de los almacenes y cálculos 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 composición de agregados de paquetes de datos que se mueven a
lo largo de los flujos, es decir, paquetes complejos que pueden descomponerse
en unidades más elementales.
- Describen la composición de los paquetes de datos en los almacenes.
- Especifica los valores y unidades relevantes de piezas elementales de
información 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-relación u otro modelo de datos.
Notación del diccionario de datos.
Existen muchos
esquemas de notación comunes utilizados. Este es uno de los más utilizados.
= : está compuesto de
+ : y
( ) :optativo (puede estar presente o ausente)
{ } : iteración
[ ] : seleccionar una de varias alternativas
* * : comentario
@ : identificador (campo clave) para un almacén
| : separa opciones alternativas en la construcción
Por ejemplo, podemos definir
nombre = título de cortesía + nombre + (segundo nombre) + apellido paterno +
apellido materno
título de cortesía = [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 corrección 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 más de una vez algún dato?
- ¿Se ha utilizado la notación correcta para todas las definiciones del
diccionario de datos?
- ¿Hay elementos de datos en el diccionario que no estén relacionados con el
DFD u otros diagramas?
Especificaciones de Proceso.
La especificación del
proceso es la descripción de qué es lo que sucede en cada burbuja primitiva en
el nivel más bajo en un DFD. También es llamado Minispec o miniespecificación.
Su propósito es definir lo que debe hacerse para transformar entradas en
salidas.
La forma más utilizada para realizar las especificaciones de procesos es el
lenguaje estructurado, pero se puede utilizar cualquier método que satisfaga dos
requerimientos cruciales:
- La especificación del proceso debe expresarse de una manera que puedan
verificar tanto el usuario como el analista. Precisamente por esta razón se
evita el lenguaje narrativo como herramienta de especificación: es ambiguo,
sobre todo si describe acciones alternativas y acciones repetitivas. Por
naturaleza, también tiende a causar gran confusión 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 público amplio que esté involucrado. A pesar de que el
analista es típicamente quien escribe la especificación del proceso,
habitualmente será un público bastante diverso de usuarios, administradores,
auditores, personal de control de calidad y otros, el que leerá la
especificación del proceso.
Lenguaje estructurado.
También conocido como español
estructurado, es el más utilizado para realizar especificaciones de procesos.
Es un subconjunto del español, como lo son del inglés muchos de los lenguajes
de programación.
Una frase del lenguaje estructurado puede ser una expresión 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
Además se utilizan las estructuras de control de la programación
estructurada (if-then-else, while-do, repeat-until, for-do y la concatenación
de sentencias) traducidas al español:
Si condición 1 entonces
bloque
sino
bloque alternativo
fin-si
mientras condición hacer
bloque
fin-mientras
repetir
bloque
hasta condición
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. También se utilizan tablas de decisión y diagramas de flujo en las
minispecs.
Diagramas de Estructura.
A través de los diagramas de
estructura se puede modelar el control del sistema, así como la descomposición
de las funciones en forma jerárquica.
En un diagrama de estructura, los módulos son representados por
rectángulos. Se representa la dependencia (jerárquica) entre módulos, las
instancias de repetición y decisión así como el flujo de los datos de control
y otros a través de las funciones. Los módulos del diagrama de estructura son
los mismos que los que aparecen en los distintos niveles del DFD, vistos en
otra dimensión.
Aunque el módulo padre de un diagrama de estructura o módulo raíz puede
tener dos o n hijos en su segundo nivel de descomposición, se recomienda
descomponer este módulo 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 módulos hijos.
Estas ramas son:
a. rama aferente: su objetivo es capturar u obtener la información
proveniente generalmente del usuario.
b. rama de proceso: transforma la información 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.
Documentación.
La documentación del diseño es vital
para garantizar su legibilidad y correcto entendimiento en la etapa de
construcción o codificación, además de permitir detectar errores de
consistencia. Debe entenderse que el diseño debe ser perfectible por personas
ajenas a quienes lo construyeron, por lo que la documentación no puede faltar.
Por otro lado, no hay que olvidar que el diseño constituye la especificación
de la etapa subsiguiente.
Para documentar el diseño 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 documentación Terminadores.
Terminador:
Descripción:
Flujos que genera:
Flujos que recibe.
Esquema Documentación Flujos de Datos.
Flujo:
Descripción Narrativa:
Compuesto por:
Parte de:
Fuente:
Destino:
[Volumen:]
Esquema Documentación Procesos.
Nivel:
Número:
Nombre:
Parte de:
Compuesto por:
Descripción Narrativa:
Entradas:
Salidas:
Miniespecificación:
Esquema Documentación Almacenes de Datos.
Nombre:
Descripción Narrativa:
Contenido:
Flujos entrantes:
Flujos
Salientes:
Esquema Documentación DFD.
Nivel Diagrama:
Diagrama Proceso:
Terminadores:
Flujos de Datos:
Almacenes de
Datos:
Procesos:
Esquema Documentación Diagramas de
Estructura.
Diagrama Proceso:
Terminadores:
Flujos de Datos:
Almacenes de Datos:
Procesos:
Esquema Documentación Elementos de Datos.
Nombre:
Alias:
Descripción:
Dominio:
Si es discreto:
Si es discreto:
| Valor |
Significado |
| . |
. |
Si es continuo:
| Tipo |
Largo |
Rango |
| . |
. |
. |