Diseño Orientado Al flujo de Datos<br />Juan Francisco González Reyes – 07230471<br />ITSL – México<br />
Diseño orientado al flujo de datos<br /><ul><li>Diseño arquitectónico
Determinación del flujo de datos (primera revisión)
Diseño arquitectónico en el cliente
Descomposición de primer nivel
Descomposición de segundo nivel
Diseño arquitectónico en el servidor
Descomposición de primer nivel
Descomposición de segundo nivel
Postproceso de diseño
Descripción de módulos en el cliente
Limitaciones en el modelo del cliente
Descripción de módulos en el servidor
Próxima SlideShare
Cargando en…5
×

Diseño orientado al flujo de datos

1.203 visualizaciones

Publicado el

Publicado en: Educación
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
1.203
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
14
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Diseño orientado al flujo de datos

  1. 1. Diseño Orientado Al flujo de Datos<br />Juan Francisco González Reyes – 07230471<br />ITSL – México<br />
  2. 2. Diseño orientado al flujo de datos<br /><ul><li>Diseño arquitectónico
  3. 3. Determinación del flujo de datos (primera revisión)
  4. 4. Diseño arquitectónico en el cliente
  5. 5. Descomposición de primer nivel
  6. 6. Descomposición de segundo nivel
  7. 7. Diseño arquitectónico en el servidor
  8. 8. Descomposición de primer nivel
  9. 9. Descomposición de segundo nivel
  10. 10. Postproceso de diseño
  11. 11. Descripción de módulos en el cliente
  12. 12. Limitaciones en el modelo del cliente
  13. 13. Descripción de módulos en el servidor
  14. 14. Limitaciones en el modelo del servidor
  15. 15. Diseño de la interfaz
  16. 16. Notas previas
  17. 17. Consideraciones sobre el diseño de la interfaz hombre-máquina </li></li></ul><li>Determinación del flujo de datos (primera revisión)<br /><ul><li>Repasando sobretodo las siguientes figuras y 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.
  18. 18. 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.
  19. 19. 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.
  20. 20. 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. </li></li></ul><li>Diseño arquitectónico en el cliente<br />Descomposición de primer nivel<br /><ul><li>Atendiendo pues, a un punto de vista de flujo de trasformación y estudiando primeramente la figura, puede desglosarse el subproceso de interfaz gráfica desde dos intereses: La 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.</li></ul>Descomposición de segundo nivel<br /><ul><li>Con 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.2 se 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.</li></li></ul><li>Diseño arquitectónico en el servidor<br />Descomposición de primer nivel<br /><ul><li>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.14 muestran con claridad los problemas que habrá que abordar a la hora de desarrollar el servidor.</li></ul>Descomposición de segundo nivel<br /><ul><li>Más aun, de una manera aún más explícita y menos arbitraria, se puede diferenciar que el proceso servidor tiene dos vías de comunicación con subdivisiones de entrada y salida, en lo que a la parte concurrente se refiere.
  21. 21. En relación al proceso principal se han apuntado en la figura los tres frentes en los que -con el nivel de conocimiento que puede tenerse en esta fase- se entiende que habrá que construir esta parte del servidor.</li></li></ul><li>Post-proceso de Diseño<br />En esta sección se han de tratarse principalmente tres aspectos propios de la fase que Pressmandefine como post-proceso y que en este caso se han considerado los más importantes: <br /><ul><li>Desarrollar una descripción del procesamiento para cada módulo.
  22. 22. Una descripción de la interfaz para cada módulo.
  23. 23. Anotar las restricciones y limitaciones del diseño. </li></ul>Concretamente, conviene releer que un texto explicativo del procesamiento es una delimitada descripción sin ambigüedades del procesamiento que ocurre dentro de un módulo. La narrativa describe el procesamiento, las tareas, las decisiones y la entrada/salida. <br />Y resaltar que en cuanto a la interfaz, convendrá detenerse a concretar la entrada y la salida del sistema en cada módulo, al tiempo que postergar lo relativo a las interfaces entre módulos y las interfaces hombre-computadora que se abordarán en secciones siguientes.<br />Es interesante respetar la jerarquía de los árboles que se han dibujado en secciones anteriores, no sólo para facilitar el trabajo en esta sección y su lectura sino también para poder anotar las limitaciones que se van encontrando en el diseño y que se deberán tener en cuenta en próximas fases.<br />
  24. 24. Descripción de módulos en el cliente<br />Para entender las tablas de esta sección, se deben cotejar conjuntamente con la figura 4.1 y los DFDs de los que procede.<br />El objetivo de esta sección es reducir el máximo número de módulos a una descripción más o menos inmediata. Comprender en ese proceso las debilidades del modelo y dejar previstas el resto de cuestiones para fases posteriores de desarrollo con el máximo nivel de entendimiento. <br />Tabla 4.1: Descripción módulo: Grabar tabla localmente.<br />
  25. 25. Limitaciones en el modelo del cliente<br />Avanzar la descripción de los módulos provista en esta fase del refinado de los DFDs, su estudio y su descomposición: aproxima una visión más real del trabajo hecho hasta ahora, sus limitaciones y algunas de las dificultades que aún no han sido resultas.<br />La cuestión de la estructura de datos que contiene en memoria a la tabla inicializada o cargada (ya sea desde un archivo o desde la base de datos), no ha sido finalmente abordada hasta el momento. El riesgo de tropezar más adelante con una interfaz gráfica o un soporte propio del lenguaje de programación que resuelva esto sigue invitando por el momento a postergar esta decisión, pero al mismo tiempo debilita la visión global que se tiene y supone una dependencia de un entorno de trabajo.<br />
  26. 26. Tabla 4.7: Descripción módulo: generar proceso concurrente. <br />Descripción de módulos en el servidor<br />Para esta parte deben examinarse las tablas revisando las figuras y tenerse en cuenta que el proceso servidor se ha estudiado por duplicado desde la fase de análisis teniendo en cuenta su concurrencia. <br />Tabla 4.7: Descripción módulo: generar proceso concurrente.<br />Tabla 4.8: Descripción módulo: conexión inicial con la base de datos.<br />
  27. 27. Limitaciones en el modelo del servidor<br />Igual que cuando se ha procedido al refinamiento y estudio de los DFDs del cliente para describir sus módulos, se trata ahora de ver qué debilidades han aparecido al hacer lo propio con los módulos del servidor: <br />Examinando los módulos del proceso concurrente se nota que se han desglosado excesivamente (aunque con el buen objetivo de separar mecanismos diferentes) los módulos de entrada y salida ya sea con el cliente o con la base de datos. A la hora de describir dichos procesos resulta más cómodo y mucho más intuitivo juntarlos pues la salida se debe a la entrada y no puede entenderse por separado.<br />
  28. 28. Diseño de la Interfaz<br />Notas previas<br />Entiéndase por interfaz los tres casos siguientes: <br />El diseño de interfaces entre los módulos software<br />Invita a pensar que en posteriores fases del desarrollo, podrá resolverse de una manera más o menos inmediata, y si hiciera falta revisar lo aquí descrito sería entonces el momento correspondiente donde explicar<br />El diseño de interfaces entre el software y otros productores y consumidores no humanos de información<br />En el caso de este sistema, se trata del interfaz con el proceso cliente (como entidad externa del servidor) y el interfaz con la base de datos. Sí que se ha escrito sobre ambos: Con respecto al interfaz entre el servidor y el cliente se ha decidido, y ya se ha escrito sobre ello, que habrá una comunicación mediante sockets, es decir, un interfaz TCP/IP. También se ha descrito en distintos momentos que a la hora de enviarse mensajes, cliente y servidor, deben encapsular sus envíos en un marco conocido por ambos. <br />El diseño de la interfaz entre el hombre y la computadora <br />
  29. 29. Diseño de la Interfaz<br />Consideraciones sobre el diseño de la interfaz hombre-máquina<br />  Lo que debe importar de ellos en esta sección es su conocimiento sintáctico y semántico del sistema:<br />El administrador del sistema no debe preocupar al diseñador, tiene conocimiento completo del sistema. Es el único que maneja el proceso servidor con lo que esta interfaz puede ser simple, aunque sí clara, y puede ser en modo consola. <br />Los gestores pueden ser considerados usuarios frecuentes, lo que hay que considerar de ellos es que trabajan en el mismo entorno del servidor. Pueden resolver cualquier dificultad in situ pues no trabajan remotamente. Pueden disponer de notas, de ésta u otra documentación, y de la ayuda del administrador del sistema. De todas maneras lo más importante es que si los usuarios novatos pueden utilizar la interfaz gráfica de la aplicación cliente ellos deben tenerlo más fácil. <br />
  30. 30. Fuente:<br />http://www.uv.es/marjoari/pfc/html/node51.html<br />

×