Mapping the Community Stadia Facilities and Services

En el caso de este sistema de autogestión, la interfaz fue desarrollada con pantallas o ventanas con menús de opciones estrictamente jerárquicos, los que proporcionan al usuario una lista de las selecciones disponibles. El usuario no necesita conocer el sistema, pero sí necesita saber qué tarea debe ser realizada.

El espacio de diseño de la interfaz es de dos dimensiones. En el caso de este sistema, sólo se permite la utilización del teclado numérico y teclas de movimiento del cursor, así como también las teclas ENTER y ESC, además de FIN. El color añade una nueva dimensión a la facilidad de uso de la pantalla, para atraer la atención del usuario al facilitar la separación de componentes de la pantalla y acentuar las diferencias.

La crítica a realizar a esta interfaz se presenta en el menú principal, en el que no existe la suficiente separación jerárquica entre las opciones de consulta y las de actualización. Por ejemplo, Eliminar inscripción en Materia, debería estar dentro del grupo de actualización y, las consultas dentro de la misma opción de Consulta, por ejemplo: cronograma de actividades y consulta de situación arancelaria figuran como una opción nueva dentro del Menú de Opciones, y no, dentro de las consultas.

A continuación, en las siguientes figuras, presentamos las distintas pantallas del Menú de Autogestión del alumno, desde el ingreso al sistema, menú de opciones, entre las que pueden seleccionarse consultas, Inscripciones en exámenes y materias, Listado

de mesas de examen, Cronograma de actividades, consulta de situación arancelaria y Modificación de PIN.

Figura 15 – Menú de Ingreso al Sistema de Autogestión

Figura 17 – Menú de Consultas del Sistema de Autogestión

Figura 19 – Consulta de Situación Arancelaria

Figura 21 – Inscripción en Materias

b) Construcción del metamodelo del sistema

A los fines de realizar un estudio comparativo entre ambas aplicaciones, se propone la construcción de un meta-modelo empleando el Lenguaje UML.

La entidad central es el Módulo Principal, el cual despliega la información al usuario mediante la carga de forms.

Para acceder a él, previamente se toman los recaudos necesarios de seguridad de acceso, a través de un pequeño form denominado Login. Este Login se autocargará hasta un máximo de tres veces cuando ocurran intentos fallidos de acceso y en caso contrario desplegará el Modulo Principal.

Mientras que el contenido del FormRegistro, que se utiliza para el ingreso de datos, es estático y fijo, el contenido del FormConsulta es dinámico determinado por el puesto de trabajo y puede depender de la información provista por el usuario a través de campos de entrada.

Para modelar estas dos alternativas existen dos subclases derivadas de la clase ModuloPrincipal: FormConsulta y FormRegistro. Cuando el contenido de un form dinámico depende del valor de un conjunto de variables de entrada, estos estarán contenidos en el atributo “use” de las clase Componentes. Por otra parte un form estático sólo estará compuesto de campos que serán completados por el usuario para actualizar la Base de Datos.

La interfaz AccesoDatos existente entre los forms y la BaseDatos, es lo que permite el uso del SGBD. El acceso se produce mediante la clase Componentes, la que provee los drivers nativos de conexión. Las validaciones necesarias las realiza AccesoDatos y es la que permitirá interactuar con la BaseDatos.

En la figura 24 puede observarse gráficamente la implementación de este metamodelo de la aplicación GUI.

SGBD

.dll .ocx

ODBC

5.2.5 Descripción de la arquitectura física y del software de base a) Arquitectura física

La arquitectura de esta aplicación se basa en la tecnología cliente/servidor, la cual hace referencia a la conexión de ordenadores por medio de una red a los fines de descentralizar el procesamiento y utilizar fuentes de datos centralizadas. La arquitectura utilizada en este caso de estudio fue de dos capas, la cual se orientaba a la conexión de PC’s clientes (alumnos), con servidores conectados a una red, en nuestro caso servidor de aplicaciones y de datos.

En la figura 25 se muestra cómo se implementó en el sistema anterior de autogestión el modelo de dos capas.

Usuario local

• Consultar actividades obligatorias • Registrar inscripción en materias • Consultar notas de exámenes • Registrar inscripción a exámenes

• Consultar deuda • Eliminar inscripción en materias

• Consultar cronograma de actividades • Consultar mesas de exámenes

Driver nativo para conexión de datos

Capa de Presentación

Menú principal de sistema de Autogestión

Lógica de la aplicación

cliente

Almacenamiento

Base de Datos

Como puede observarse en la figura anterior, la arquitectura de dos capas presenta el inconveniente de que la lógica de presentación y la lógica de negocio se hallan en la máquina cliente (en nuestro caso del alumno), y la lógica de datos en el servidor de base de datos, realizándose el acceso a través de drivers nativos para conexión a datos.

Es por ello que en estos casos debido al grado de procesamiento de la máquina cliente, a éste se lo denomina en nuestro caso Fat Client o cliente pesado, debido a la fuerte dependencia existente entre la aplicación, del lado del cliente y la Base de Datos. En consecuencia, cualquier modificación que se realice sobre ella, hace necesaria la modificación de todas las aplicaciones asociadas, lo que fue crítico en este sistema porque al incorporarse nuevas funcionalidades, la carga de mantenimiento fue creciente. b) Arquitectura del software de base. Diagrama de componentes

A continuación, se detallan los componentes de este modelo de dos capas: b.1 Cliente Windows

• El componente EXE UIAutogestion representa al programa que se ejecuta en la máquina cliente, es decir, que éste se encuentra instalado en la PC cliente y es el front-end de la aplicación.

• En el componente ActiveX LogicaUIAutogestion se encuentra la organización de los programas para la gestión.

• En tanto, en la capa componente ActiveX ComponentesLogicos se realiza la gestión de transacciones contra la base de datos. Ejemplo: cadenas de conexión y permisos.

• El componente ActiveX Entidades personaliza la gestión de transacciones por cada operación, es decir, separa por tareas las operaciones. Ejemplo: inscripción en materias, consulta de calificaciones.

• Por último, el componente ADO AccesoDatos utiliza drivers de conexión entre la aplicación y la base de datos. Ejemplo: drivers nativos del lenguaje de programación.

b.2 Servidor de base de datos

Del lado del servidor de base de datos se encuentran:

• El MotorBaseDatos es el servicio otorgado por SGBD y que, en este caso, es SQL Server. En el componente Tablas se encuentran almacenados los datos. En el componente Vistas se encuentran sentencias de consultas habituales a la BaseDatos y en el componente ProcedimientosAlmacenados se encuentran los script transaccionales principales para gestionar los datos.

La concurrencia es dividida en dos, por un lado cada ActiveX Entidades debe ser lo suficientemente corto y preciso en el envío y recepción de solicitudes de BaseDatos de manera que permita liberar rápidamente los registros en cuestión. Por otro lado, los componentes Vistas y ProcedimientosAlmacenados deben marcar el comienzo de una transacción mediante un Begin Transaction de manera que aseguren la consistencia de la información. Si la operación es exitosa se termina con un Commit Transaction actualizando, recién en este momento, los datos físicos de la Base, en caso contrario, se aplica un Rollback, la operación se deshace y vuelve al punto de partida. Por último el componente MotorBaseDatos manejará un determinado número de conexiones y solicitudes al mismo tiempo administrado por DBA (Data Base Administrador).

La figura 26 ilustra la distribución del procesamiento entre los distintos componentes o nodos distribuidos entre las estaciones de cliente (bajo Windows), y el servidor central.

Los componentes físicos se implementan agrupándolos en subsistemas organizados en capas y jerarquías.