Determinación del flujo de datos (primera revisión
Descargar como PPTX, PDF0 recomendaciones213 vistas
El documento describe los primeros pasos en el diseño de un sistema de flujo de datos, incluyendo la descomposición del proceso servidor y cliente en niveles de profundidad uno y dos, así como la interfaz gráfica dividida en procesos de entrada, salida local y comunicación con el servidor. También discute la relación entre los diagramas de flujo de datos y los diagramas de arquitectura durante esta fase preliminar del diseño.
![La relación entre los DFDs y los diagramas de arquitectura como el que se ha trasladado a la figura 4.2 no debe ser tomada, en esta fase, como una bisección perfecta entre módulos; Pressman en [9] dice que «se pueden combinar dos o incluso tres burbujas y representarlas como un solo módulo, o una sola burbuja puede dividirse en dos o más módulos (...) La revisión y el refinamiento pueden llevar a cambios en la estructura, pero puede servir como una primera iteración del diseño.»](https://image.slidesharecdn.com/determinacindelflujodedatosprimerarevisin-100905165013-phpapp02/85/Determinacion-del-flujo-de-datos-primera-revision-7-320.jpg)
Determinación del flujo de datos (primera revisión
- 1. Determinación del flujo de datos (primera revisión DFDs)en general todos los diagramas de flujo de datos que se han utilizado en la fase de análisis se puede descartar que haya un flujo de transacción. Pressman define este tipo de flujo de la información cuando los datos se <<mueven a lo largo de un camino de entrada que convierte la información del mundo exterior en una transacción. La transacción se evalúa y basándose en ese valor, se inicia el flujo a lo largo de uno de muchos caminos de acción. El centro del flujo de información del que parten los caminos de acción se denomina centro de transacción>>. Y no existe en el capítulo de análisis ningún DFD con ese aspecto.
- 2. Descomposición de primer nivelLa constante emisión gráfica de la tabla y del resto de variables de entorno que supone tener una ventana para la aplicación y los diferentes menús y submenús. Las ocasionales entradas de datos que el usuario hace para modificar registros de la tabla o variables como los datos de la conexión, los datos desde Ms-Excel, etc. Lo único que requiere de especial la fase de diseño del proceso servidor es atender a la presencia de un proceso concurrente que atiende las peticiones de cada cliente y un proceso principal. Por todo lo demás, el proceso servidor, es aún más sencillo que el del cliente y la conversión de los DFDs mucho menos problemática. El diagrama de flujo de datos del servidor, en la profundidad uno, tanto del proceso principal como del proceso concurrente, puede dejarse tal cual en la revisión y en el refinado. Las figuras 3.13 y 3.14muestran con claridad los problemas que habrá que abordar a la hora de desarrollar el servidor.
- 3. Al nivel que aquí interesa, la parte del proceso servidor que no atiende en profundidad las cuestiones del cliente, no necesita información acerca de la base de datos ni proviene de ella. Permanecer a la escucha por el socket inicial (conocido). Cuando llega una conexión automáticamente lee el mensaje entrante y: Abre un socket a parte, por el cual se comunica con el cliente. Crea un proceso concurrente que atiende las peticiones que entren por este socket. Fig. 3.13
- 4. Modelo del proceso servidor: Nivel 1 en el proceso concurrenteLas necesidades para atender al cliente pueden desglosarse es: - Una primera gestión del login y el password que responde según la base de datos acepte o no a dicho usuario. - Gestionar los mensajes que envía el cliente y separar de él las sentencias SQL que incluyen en el caso que así sea, o generando las sentencias implícitas como en el caso de la desconexion. - Emitir las sentencias SQL a la base de datos y recoger los resultados. - Enviar al cliente los resultados obtenidos por de la base de datos.
- 5. Como muestra la figura 4.1, la interfaz gráfica se dividiría en varios procesos diferenciándose lo que es la salida gráfica propiamente dicha de las entradas de valores de la conexión, de la tabla o las instrucciones implícitas si el usuario interactúa con la tabla. De la misma manera se separa la salida a nivel local ya sea de información de la tabla al disco (en un archivo Ms-Excel) o la salida por pantalla; de las salidas de información o preguntas al servidor.
- 6. Descomposición de segundo nivelCon la subdivisión de la figura 4.1 se puede presentar una descomposición de segundo nivel con un aspecto de árbol propio de la notación de una jerarquía de control. Siguiendo una partición estructural de tipo horizontal en la figura 4.2se ha hecho una primera aproximación desglosando por niveles de profundidad y separando la entrada de la salida a nivel local, aunque la interfaz gráfica sea un concepto que cubra uno y otro servicio.
- 7. La relación entre los DFDs y los diagramas de arquitectura como el que se ha trasladado a la figura 4.2 no debe ser tomada, en esta fase, como una bisección perfecta entre módulos; Pressman en [9] dice que «se pueden combinar dos o incluso tres burbujas y representarlas como un solo módulo, o una sola burbuja puede dividirse en dos o más módulos (...) La revisión y el refinamiento pueden llevar a cambios en la estructura, pero puede servir como una primera iteración del diseño.»