1. Diseño Orientado Al flujo de Datos Juan Francisco González Reyes – 07230471 ITSL – México

3. Determinación del flujo de datos (primera revisión)

4. Diseño arquitectónico en el cliente

5. Descomposición de primer nivel

6. Descomposición de segundo nivel

7. Diseño arquitectónico en el servidor

8. Descomposición de primer nivel

9. Descomposición de segundo nivel

10. Postproceso de diseño

11. Descripción de módulos en el cliente

12. Limitaciones en el modelo del cliente

13. Descripción de módulos en el servidor

14. Limitaciones en el modelo del servidor

15. Diseño de la interfaz

16. Notas previas

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. 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.

22. Una descripción de la interfaz para cada módulo.

23. Anotar las restricciones y limitaciones del diseño. 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. 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. 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.

24. Descripción de módulos en el cliente Para entender las tablas de esta sección, se deben cotejar conjuntamente con la figura 4.1 y los DFDs de los que procede. 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. Tabla 4.1: Descripción módulo: Grabar tabla localmente.

25. Limitaciones en el modelo del cliente 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. 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.

26. Tabla 4.7: Descripción módulo: generar proceso concurrente. Descripción de módulos en el servidor 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. Tabla 4.7: Descripción módulo: generar proceso concurrente. Tabla 4.8: Descripción módulo: conexión inicial con la base de datos.

27. Limitaciones en el modelo del servidor 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: 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.

28. Diseño de la Interfaz Notas previas Entiéndase por interfaz los tres casos siguientes: El diseño de interfaces entre los módulos software 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 El diseño de interfaces entre el software y otros productores y consumidores no humanos de información 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. El diseño de la interfaz entre el hombre y la computadora

29. Diseño de la Interfaz Consideraciones sobre el diseño de la interfaz hombre-máquina Lo que debe importar de ellos en esta sección es su conocimiento sintáctico y semántico del sistema: 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. 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.

30. Fuente: http://www.uv.es/marjoari/pfc/html/node51.html