Juan Francisco González Reyes – 07230471ITSL – México

Diseño Orientado Al flujo de Datos

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

Diseño de la interfaz Notas previas Consideraciones sobre el diseño de la interfaz hombre-máquina

Diseño orientado al flujo de datos

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.

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.

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

Descomposición de primer nivel

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.

Diseño arquitectónico en el cliente

Descomposición de segundo nivel

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.

Descomposición de primer nivel

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.

Diseño arquitectónico en el servidor

Descomposición de segundo nivel

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.

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.

En esta sección se han de tratarse principalmente tres aspectos propios de la fase que Pressman define como post-proceso y que en este caso se han considerado los más importantes:

Desarrollar una descripción del procesamiento para cada módulo. Una descripción de la interfaz para cada módulo. 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.

Post-proceso de Diseño

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.

Descripción de módulos en el cliente

Nombre del módulo Grabar tabla localmenteProceso ClienteEntrada Tabla en memoriaSalida archivo en disco con formato Ms-Excel

Descripción

Permite al usuario nombrar el archivo y ubicarlo localmente. Le da una extensión xls al nombre y graba en él, el contenido de la tabla que hay cargada en memoria y que el interfaz visualiza.

Tabla 4.1: Descripción módulo: Grabar tabla localmente.

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.

Limitaciones en el modelo del cliente

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.

Descripción de módulos en el servidor

Tabla 4.7: Descripción módulo: generar proceso concurrente.

Nombre del módulo generar proceso concurrenteProceso servidor (proceso principal)Entrada Socket para hablar con el clienteSalida un manejador de proceso

DescripciónEn esta parte el proceso servidor lanza (en connivencia con el sistema operativo) un proceso concurrente que escucha las peticiones del cliente.

Tabla 4.7: Descripción módulo: generar proceso concurrente.

Nombre del módulo conexión con la base de datos

Entrada login y password del usuario en el cliente

DescripciónCon la información del usuario que remotamente está conectado desde el cliente, el proceso servidor pide conexión a la base de datos, obteniendo acceso.

Tabla 4.8: Descripción módulo: conexión inicial con la base de datos.

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.

Limitaciones en el modelo del servidor

Notas previasEntiéndase por interfaz los tres casos siguientes:

El diseño de interfaces entre los módulos softwareInvita 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ónEn 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

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.

Diseño de la Interfaz

Fuente:

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