SlideShare una empresa de Scribd logo
1 de 15
Diseño Orientado a Flujo de Datos Sistemas de Información 2
Discusión sobre la orientación a objetos A favor de la Orientación a Objetos podría apuntarse:  El manejo de los sockets puede enmascararse para su uso y hacer esta tarea más trasparente a la hora de abordar los procesos de comunicación. El manejo de las tablas en el interfaz gráfico quizá merece pensarse desde la OO, pudiéndose diferenciar lo que es el contenido de la información de sus métodos de representación en pantalla o de modificación. Se pueden resolver otras tareas como clases, separando información y métodos, creando quizá una clase que encierre lo relativo a las sentencias SQL
Diseño Arquitectónico
Determinación del flujo de datos (primera revisión DFDs) 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
Descomposición de primer nivel 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.
Descomposición de segundo nivel 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 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.»
Diseño arquitectónico en el servidor
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.
Descomposición de segundo nivel Por la manera en que se ha dividido los diagramas del servidor atendiendo a su multiplicidad y a su concurrencia, la fase de conexión es un proceso donde intervienen todos los factores en el servidor de manera concentrada:  - Información del login y el password que el usuario ha introducido en el cliente. - La confirmación de la base de datos. - La creación de un socket dedicado para el nuevo cliente. - La instanciación de un proceso concurrente que resuelva las peticiones del cliente por separado.  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 4.3 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.
Postproceso de diseño En esta sección se han de tratarse principalmente tres aspectos propios de la fase que Pressman define en como Postproceso 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.
Descripción de módulos en el cliente 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.
Limitaciones en el modelo del cliente 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 (librerías, lenguajes de programación, etc) que aún no se disponen.  Algunos de los módulos han quedado ambigüos o diluidos por ser demasiado generales y no se han descrito en las tablas de estas páginas. Sus tareas, sin embargo, siguen siendo diferentes y en fases de implementación deberá revisarse sobretodo los DFDs y documentar debidamente en qué partes del código han quedado dichas soluciones.
Limitaciones en el modelo del servidor El inicio en el servidor: llegada de un nuevo cliente, generación de socket dedicado, generación de un proceso concurrente y posterior conexión a la base de datos ha sido separado atendiendo sobretodo a la multiplicidad en el servidor. Este mecanismo puede resolverse de muy distintas maneras y en posteriores fases de desarrollo, en función de cómo se resuelva la gestión de los sockets quedará como se ha mostrado aquí o con otro «ritmo».
Consideraciones sobre el diseño de la interfaz hombre-máquina El administrador del sistema no debe preocupar al diseñador (además por el momento ambas figuras son la misma). Tiene (o debe tener) 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. -Algunos de los comerciales deben ser considerados usuarios novatos. Sin conocimiento sintáctico. La línea de demarcación para construir la interfaz hombre-máquina en la aplicación cliente debe rebajarse hasta ellos. La imagen del sistema debe guiarles en sus operaciones y sólo deben necesitar información adicional para resolver la conexión inicial, proceso que una vez aprendido debe ser sencillo.
Fin Sistemas de Información 2 Bibliografía http://www.uv.es/marjoari/pfc/html/node51.html

Más contenido relacionado

La actualidad más candente

Aplicaciones en n capas en visual net
Aplicaciones en n capas en visual netAplicaciones en n capas en visual net
Aplicaciones en n capas en visual netSonia Ramos Fernandez
 
A charla12 arq.3-capas
A charla12 arq.3-capasA charla12 arq.3-capas
A charla12 arq.3-capashome
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructuradoMarilugosale
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructuradoazuajesimon
 
03b arquitectura clienteservidor n capas
03b arquitectura clienteservidor n capas03b arquitectura clienteservidor n capas
03b arquitectura clienteservidor n capasWalter Moo Guzmán
 
Modelo vista controlador vas Programacion por n capas
Modelo vista controlador vas Programacion por n capasModelo vista controlador vas Programacion por n capas
Modelo vista controlador vas Programacion por n capasAlex Uhu Colli
 
APLICACIÓN N-CAPAS VISUAL.NET
APLICACIÓN N-CAPAS VISUAL.NETAPLICACIÓN N-CAPAS VISUAL.NET
APLICACIÓN N-CAPAS VISUAL.NETdaniel barboza
 
Estrategias de procesamiento de consultas distribuidas
Estrategias de procesamiento de consultas distribuidasEstrategias de procesamiento de consultas distribuidas
Estrategias de procesamiento de consultas distribuidasJosé Mendoza
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructuradoDascorp
 
Servidores informaticos, modelo cliente servdor
Servidores informaticos, modelo cliente servdor Servidores informaticos, modelo cliente servdor
Servidores informaticos, modelo cliente servdor Erivan Martinez Ovando
 
Marmolejo Verduzco y Hernandez Medina
Marmolejo Verduzco y Hernandez Medina Marmolejo Verduzco y Hernandez Medina
Marmolejo Verduzco y Hernandez Medina MARVERWORLD
 
Modelo de diseño_iv
Modelo de diseño_ivModelo de diseño_iv
Modelo de diseño_ivRaul Mendes
 

La actualidad más candente (20)

Aplicaciones en n capas en visual net
Aplicaciones en n capas en visual netAplicaciones en n capas en visual net
Aplicaciones en n capas en visual net
 
Framework
FrameworkFramework
Framework
 
A charla12 arq.3-capas
A charla12 arq.3-capasA charla12 arq.3-capas
A charla12 arq.3-capas
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
APLICACIONES N-CAPAS EN VISUAL NET
APLICACIONES N-CAPAS EN VISUAL NETAPLICACIONES N-CAPAS EN VISUAL NET
APLICACIONES N-CAPAS EN VISUAL NET
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
Taller 4 - Teleinformatica
Taller 4 - TeleinformaticaTaller 4 - Teleinformatica
Taller 4 - Teleinformatica
 
Aplicaciones n capas en visual net
Aplicaciones n capas en visual netAplicaciones n capas en visual net
Aplicaciones n capas en visual net
 
03b arquitectura clienteservidor n capas
03b arquitectura clienteservidor n capas03b arquitectura clienteservidor n capas
03b arquitectura clienteservidor n capas
 
Modelo vista controlador vas Programacion por n capas
Modelo vista controlador vas Programacion por n capasModelo vista controlador vas Programacion por n capas
Modelo vista controlador vas Programacion por n capas
 
APLICACIÓN N-CAPAS VISUAL.NET
APLICACIÓN N-CAPAS VISUAL.NETAPLICACIÓN N-CAPAS VISUAL.NET
APLICACIÓN N-CAPAS VISUAL.NET
 
Estrategias de procesamiento de consultas distribuidas
Estrategias de procesamiento de consultas distribuidasEstrategias de procesamiento de consultas distribuidas
Estrategias de procesamiento de consultas distribuidas
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
Aplicaciones de n capas en visual net
Aplicaciones de n capas en visual netAplicaciones de n capas en visual net
Aplicaciones de n capas en visual net
 
Unidad i esp parte 2
Unidad i esp parte 2Unidad i esp parte 2
Unidad i esp parte 2
 
Aplicaciones n capas en visual net
Aplicaciones n capas en visual netAplicaciones n capas en visual net
Aplicaciones n capas en visual net
 
Servidores informaticos, modelo cliente servdor
Servidores informaticos, modelo cliente servdor Servidores informaticos, modelo cliente servdor
Servidores informaticos, modelo cliente servdor
 
Monografia Programación 3 Niveles
Monografia Programación 3 NivelesMonografia Programación 3 Niveles
Monografia Programación 3 Niveles
 
Marmolejo Verduzco y Hernandez Medina
Marmolejo Verduzco y Hernandez Medina Marmolejo Verduzco y Hernandez Medina
Marmolejo Verduzco y Hernandez Medina
 
Modelo de diseño_iv
Modelo de diseño_ivModelo de diseño_iv
Modelo de diseño_iv
 

Similar a Diseño orientado a flujo de datos

Similar a Diseño orientado a flujo de datos (20)

Arquitecturasdesistemasdebasesdedatos.docx
Arquitecturasdesistemasdebasesdedatos.docxArquitecturasdesistemasdebasesdedatos.docx
Arquitecturasdesistemasdebasesdedatos.docx
 
SISTEMA DE BASE DE DATOS
SISTEMA DE BASE DE DATOSSISTEMA DE BASE DE DATOS
SISTEMA DE BASE DE DATOS
 
Cliente servidor1
Cliente servidor1Cliente servidor1
Cliente servidor1
 
Programacion por capas
Programacion por capasProgramacion por capas
Programacion por capas
 
Tema4 a
Tema4 aTema4 a
Tema4 a
 
Diseño de una Base de Datos
Diseño de una Base de DatosDiseño de una Base de Datos
Diseño de una Base de Datos
 
C:\fakepath\diseño orientado a flujo de datos
C:\fakepath\diseño orientado a  flujo de datosC:\fakepath\diseño orientado a  flujo de datos
C:\fakepath\diseño orientado a flujo de datos
 
Exps jueves
Exps juevesExps jueves
Exps jueves
 
Arquitecturas centralizadas
Arquitecturas centralizadasArquitecturas centralizadas
Arquitecturas centralizadas
 
Procedimientos almacenados..mañana
Procedimientos almacenados..mañanaProcedimientos almacenados..mañana
Procedimientos almacenados..mañana
 
Diseño estructurado y las técnicas que lo caracterizan
Diseño estructurado y las técnicas que lo caracterizanDiseño estructurado y las técnicas que lo caracterizan
Diseño estructurado y las técnicas que lo caracterizan
 
Clase03
Clase03Clase03
Clase03
 
Diseño orientado a flujo de datos deahesy
Diseño orientado a flujo de datos deahesyDiseño orientado a flujo de datos deahesy
Diseño orientado a flujo de datos deahesy
 
Programación en capass
Programación en capassProgramación en capass
Programación en capass
 
Programacion por capas
Programacion por capasProgramacion por capas
Programacion por capas
 
Presentacion
PresentacionPresentacion
Presentacion
 
Diapositivas de n capas en visual net 2017
Diapositivas de n capas en visual net 2017Diapositivas de n capas en visual net 2017
Diapositivas de n capas en visual net 2017
 
Trabajo
TrabajoTrabajo
Trabajo
 
Fundam servclient
Fundam servclientFundam servclient
Fundam servclient
 
Cliente servidor
Cliente servidorCliente servidor
Cliente servidor
 

Diseño orientado a flujo de datos

  • 1. Diseño Orientado a Flujo de Datos Sistemas de Información 2
  • 2. Discusión sobre la orientación a objetos A favor de la Orientación a Objetos podría apuntarse: El manejo de los sockets puede enmascararse para su uso y hacer esta tarea más trasparente a la hora de abordar los procesos de comunicación. El manejo de las tablas en el interfaz gráfico quizá merece pensarse desde la OO, pudiéndose diferenciar lo que es el contenido de la información de sus métodos de representación en pantalla o de modificación. Se pueden resolver otras tareas como clases, separando información y métodos, creando quizá una clase que encierre lo relativo a las sentencias SQL
  • 4. Determinación del flujo de datos (primera revisión DFDs) 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
  • 5. Descomposición de primer nivel 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 nivel 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 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.»
  • 8. 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.
  • 9. Descomposición de segundo nivel Por la manera en que se ha dividido los diagramas del servidor atendiendo a su multiplicidad y a su concurrencia, la fase de conexión es un proceso donde intervienen todos los factores en el servidor de manera concentrada: - Información del login y el password que el usuario ha introducido en el cliente. - La confirmación de la base de datos. - La creación de un socket dedicado para el nuevo cliente. - La instanciación de un proceso concurrente que resuelva las peticiones del cliente por separado. 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 4.3 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.
  • 10. Postproceso de diseño En esta sección se han de tratarse principalmente tres aspectos propios de la fase que Pressman define en como Postproceso 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.
  • 11. Descripción de módulos en el cliente 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.
  • 12. Limitaciones en el modelo del cliente 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 (librerías, lenguajes de programación, etc) que aún no se disponen. Algunos de los módulos han quedado ambigüos o diluidos por ser demasiado generales y no se han descrito en las tablas de estas páginas. Sus tareas, sin embargo, siguen siendo diferentes y en fases de implementación deberá revisarse sobretodo los DFDs y documentar debidamente en qué partes del código han quedado dichas soluciones.
  • 13. Limitaciones en el modelo del servidor El inicio en el servidor: llegada de un nuevo cliente, generación de socket dedicado, generación de un proceso concurrente y posterior conexión a la base de datos ha sido separado atendiendo sobretodo a la multiplicidad en el servidor. Este mecanismo puede resolverse de muy distintas maneras y en posteriores fases de desarrollo, en función de cómo se resuelva la gestión de los sockets quedará como se ha mostrado aquí o con otro «ritmo».
  • 14. Consideraciones sobre el diseño de la interfaz hombre-máquina El administrador del sistema no debe preocupar al diseñador (además por el momento ambas figuras son la misma). Tiene (o debe tener) 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. -Algunos de los comerciales deben ser considerados usuarios novatos. Sin conocimiento sintáctico. La línea de demarcación para construir la interfaz hombre-máquina en la aplicación cliente debe rebajarse hasta ellos. La imagen del sistema debe guiarles en sus operaciones y sólo deben necesitar información adicional para resolver la conexión inicial, proceso que una vez aprendido debe ser sencillo.
  • 15. Fin Sistemas de Información 2 Bibliografía http://www.uv.es/marjoari/pfc/html/node51.html