Escolar Documentos
Profissional Documentos
Cultura Documentos
Contenidos
Definiciones.
Análisis.
Diseño.
Fundamentos del Análisis y Diseño.
Abstracción.
Refinamiento
Modularidad
Diseño Modular Efectivo.
Cohesión.
Acoplamiento.
Tamaño del Módulo.
Alcance del control.
Alcance del efecto/alcance del control.
Parsimonia.
Manejo Autónomo de Errores.
Diagramas de Flujo de Datos.
Componentes de un DFD.
El proceso.
El flujo.
El almacén.
El Terminador.
Guía para la construcción de un DFD.
DFD por niveles.
Diccionario de Datos.
Notación del diccionario de datos.
Completitud del Diccionario de Datos.
Especificaciones de Proceso.
Lenguaje estructurado.
Diagramas de Estructura.
Documentación.
Esquema de Documentación Terminadores
Esquema de Documentación Flujos de Datos
Esquema de Documentación Procesos
Esquema de Documentación Almacenes de Datos
Esquema de Documentación DFD
Esquema de Documentación Diagramas de Estructuras
Esquema de Documentación Elementos de Datos
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.
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
Modularidad
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.
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.
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.
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.
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.
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.
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.
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.
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.
El almacén.
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.
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.
a. Escoger nombres con significado para los procesos, flujos, almacenes y terminadores.
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.
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.
Existen muchos esquemas de notación comunes utilizados. Este es uno de los más
utilizados.
= : está compuesto de
+ : y
{ } : iteración
* * : comentario
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 utilizado la notación correcta para todas las definiciones del diccionario
de datos?
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.
Lenguaje estructurado.
Una frase del lenguaje estructurado puede ser una expresión algebraica:
x= (y*z)/(q+10)
Se sugiere seleccionar una cantidad de verbos reducida, como
sumar
restar
dividir
multiplicar
calcular
borrar
validar
mover
reemplazar
ordenar
Si condición 1 entonces
bloque
sino
bloque alternativo
fin-si
fin-mientras
repetir
bloque
hasta condición
bloque
fin-para
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.
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.
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.
Terminador:
Descripción:
Flujos que genera:
Flujos que recibe.
Flujo:
Descripción Narrativa:
Compuesto por:
Parte de:
Fuente:
Destino:
[Volumen:]
Nivel:
Número:
Nombre:
Parte de:
Compuesto por:
Descripción Narrativa:
Entradas:
Salidas:
Miniespecificación:
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:
Diagrama Proceso:
Terminadores:
Flujos de Datos:
Almacenes de Datos:
Procesos:
Nombre:
Alias:
Descripción:
Dominio:
Si es discreto:
Si es discreto:
Valor Significado
. .
Si es continuo:
Tipo Largo Rango
. . .