Embed Size (px)
Citation preview
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
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
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.
La relación entre los DFDs y losdiagramas de arquitectura comoel que se ha trasladado a lafigura 4.2 no debe sertomada, en esta fase, como unabisección perfecta entremódulos;
Pressman en dice que «se puedencombinar dos o incluso tresburbujas y representarlas comoun solo módulo, o una solaburbuja puede dividirse en doso más módulos (...)
La revisión y el refinamientopueden llevar a cambios en laestructura, pero puede servircomo una primera iteración deldiseño.»
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.
Más aun, de una manera aún más explícitay menos arbitraria, se puedediferenciar que el proceso servidortiene dos vías de comunicación consubdivisiones de entrada y salida, enlo que a la parte concurrente se refiere.En relación al proceso principal se hanapuntado en la figura 4.3 los tresfrentes en los que -con el nivel deconocimiento que puede tenerse enesta fase- se entiende que habrá queconstruir esta parte del servidor.
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.
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.
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.
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.
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».
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.
Bibliografía
http://www.uv.es/marjoari/pfc/html/node51.html
