Post on 25-Mar-2020
Revisión Bibliográfica
14
AMPLIACIÓN E INTEGRACIÓN DEL SISTEMA DE INFORMACIÓN PARA EL CONTROL ACADÉMICO, DE INVESTIGACIÓN Y
EXTENSIÓN DEL DEPARTAMENTO DE COMPUTACIÓN
Autor: Br. Ana Leomarys Montes Peña
Profesor Tutor: Prof. Isabel Besembel Carrera
Proyecto de Grado presentado ante la Ilustre Universidad de Los Andes como
requisito final para optar al título de Ingeniero de Sistemas.
UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA DE SISTEMAS (Mayo, 2001)
Reconocimiento
Revisión Bibliográfica
15
AGRADECIMIENTO
Mi eterna gratitud a la Fuente Suprema del Amor y la Sabiduría por
ayudarme a culminar esta etapa tan trascendental en eL sendero de mi vida.
Agradezco a mis padres, a mis profesores y a mis compañeros de
estudio por sugerirme siempre el norte a lo largo de este caminar.
Gracias al Ingeniero Michael Rouleau por brindarme su aliento de modo
permanente tanto intelectual como espiritualmente.
Mi gratitud a la Profesora Isabel Besembel Carrera por su conducción
sabia y acertada.
También doy gracias al personal directivo, docente, administrativo y
estudiantil del Instituto Anglo-Americano por la compresión y apoyo recibidos.
Todos, a su tiempo y a su manera, significaron un punto de apoyo
insustituible sin el cual no hubiera sido posible llegar con éxito hasta el final.
¡A TODOS ... GRACIAS INFINITAS!
Reconocimiento
Revisión Bibliográfica
16
RESUMEN
Este informe describe el desarrollo de un sistema de información que apoya las
actividades académicas, de investigación y extensión de los profesores y
estudiantes que integran el Departamento de Computación.
Actualmente, en este departamento se realizan importantes procesos que son
llevados a cabo manualmente, consumiendo un gran tiempo en su ejecución y
sobrecargo de trabajo para el personal que lo controla. Este sistema de
información automatizado permitirá obtener un control más eficiente sobre
estos procesos.
Para el diseño, construcción e implementación de dicho sistema, se aplicó la
metodología orientada a objetos MEDIS-00 y algunos de los elementos del
lenguaje de diseño UML para su representación. El sistema está programado
en el leguaje orientado por objetos Java con conexión a una base de datos en
Sybase Anywhere 7.0. Además, puede ser accedido por varios usuarios al
mismo tiempo debido a la arquitectura cliente/servidor bajo la cual fue
construido, y por lo tanto, puede responder a varias peticiones de información a
la vez.
Así pues, este sistema de información servirá de apoyo en la gestión del
Departamento de Computación al optimizar los principales procesos corres-
pondientes a las actividades que lleva a cabo.
Descriptores:
Sistema de Información – Control Académico. *T58.6
M6
Reconocimiento
Revisión Bibliográfica
17
INDICE DE CONTENIDO Agradecimiento ....................................................................................................... ii
Resumen ................................................................................................................... iii
Índice de Contenido .................................................................................................. iv
Índice de Figuras ............................................................................................. ........ vii
Índice de Tablas ...................................................................................................... xii
Capítulo 1: Introducción ....................................................................................... 14
1.1 Planteamiento del problema .................................................................... 16
1.2 Justificación .............................................................................................16
1.3 Objetivos ................................................................................................. 17
1.4 Metodología.............................................................................................. 17
1.5 Alcance del Sistema ............................................................................... 18
1.6 Estructura de la Monografía................................................................... ..20
Capítulo 2: Revisión Bibliográfica ......................................................................... 20 2.1 Sistema de Información: Bases Teóricas Aplicadas:............................... 21
2.1.1 Sistemas de Información Operacionales (SIOp)..................... ..22
2.1.2 Automatización Organizacional de la Información: ............................24
2.1.2.1 Redes de Computadoras.....................................................................25
2.1.2.2 Sistemas Cliente/Servidor. ................................................................ 26
2.1.2.3 Aplicación Cliente/Servidor ............................................................. .29
2.1.2.4 Bases de Datos Corporativas ............................................................. 31
2.2 Programación Orientado a Objetos:.........................................................33
2.3 Lenguaje Universal de Modelado Orientado a Objetos UML: ...............34
2.3.1 Ventajas en el Uso de UML......................................................36
2.3.2 Los Diagramas de UML: ...................................................... ...37
2.3.2.1 Diagrama de Casos de Uso ..................................39
2.3.2.2 Diagramas de Clases ............................................ 41
2.4 Bases de datos: ........................................................................................45
2.4.1 Sistema de Gestión de Bases de Datos.......................................45
2.4.2 Clasificación de los Sistemas de Gestión de Bases
De Datos:
.......................................................................................47
Reconocimiento
Revisión Bibliográfica
18
2.4.3 SQL: Un Lenguaje de Bases de Datos Relacionales:.....................
49
2.5 Lenguaje de Programación Java:
.................................................................49
2.5.1 Origen del Lenguaje Java..................................................................
49
2.5.2 Características de
Java.......................................................................51
2.5.3 Aplicaciones en
Java..........................................................................56
2.5.4 Diferencias entre Applets y Aplicaciones Independientes...............
58
2.5.5 AWT (Abstract Window
Toolkit)……….……………….………...60
2.6 Controladores ODBC – JDBC:. ......................................................................
61
2.6.1 Conectividad Abierta de Bases de Datos
(ODBC)...........................61
2.6.2 Conectividad de Base de Datos de Java
(JDBC)...............................62
Capítulo 3: Análisis y Diseño del
Sistema.....................................................................66
3.1 Análisis del Sistema de Actividades:. ..............................................................
69
3.1.1 Definición del Sistema de
Actividades...............................................69
3.1.2 Identificación de la Tecnología de Información para la
Solución
de Problemas de Información .
................................................71
3.1.3 Modelado de los Procesos Actuales del Sistema
Reconocimiento
Revisión Bibliográfica
19
Organizacional
...............................................................................72
3.1.4 Identificación Preliminar de los Tipos de Entidades
.........................77
3.1.5 Identificación de los Actores
..............................................................80
3.1.6 Identificación de los Principales
Eventos...........................................80
3.2 Especificación de los Requerimientos:
............................................................85
3.2.1 Requerimientos de Interacción Usuario-Sistema
...............................85
3.2.2 Requerimientos de Entrada de
Datos:.................................................86
3.2.3 Requerimientos de
Salida.......................................................86
3.2.4 Requerimientos
Funcionales...............................................................92
3.2.5 Requerimientos de
Almacenamiento..................................................93
3.2.6 Requerimientos de Operación y
Configuración...............................103
3.3 Diseño Preliminar del
Sistema............................................................105
3.3.1 Diseño de la Arquitectura del Sistema de
Información.........105
3.3.2 Diseño Conceptual de la Base de Datos:
.............................107
3.3.2.1 Diseño de los Esquemas Parciales del
Sistema......107
3.3.2.2 Integración de los Esquemas Parciales del
Reconocimiento
Revisión Bibliográfica
20
Sistema
....................................................................113
3.3.3 Diseño de la Interfaz Usuario-Sistema
.................................113
3.4 Diseño Implementable del Sistema:
...................................................124
3.4.1 Conversión del Esquema Conceptual Integrado a un
Esquema
Relacional..............................................................124
3.4.2 Diseño de Programas
............................................................131
Capítulo 4: Implementación del Sistema: ..........................................................
135
4.1 Implementación de la Base de Datos.................................................
135
4.2 Codificación e Implementación del Diseño de Programas de
SIDECOM...........................................................................................
143
4.3 Verificación y Validación del Sistema.................................................
158
Conclusiones.......................................................................................................
161
Recomendaciones
...............................................................................................165
Bibliografía............................................................................................................
167
Anexo A: Diagrama de clases Dinámico Integrado de SIDECOM
......................169
Anexo B: Control del Despliegue de Datos de los Usuarios de
SIDECOM..........171
Anexo C: Diccionario de Datos
............................................................................179
Reconocimiento
Revisión Bibliográfica
21
Anexo D: Documentación de los Programas de SIDECOM en
Java....................201
Reconocimiento
Revisión Bibliográfica
22
ÍNDICE DE FIGURAS
Capitulo 2: Figura 2.1: Componentes de la automatización
organizacional.................25
Figura 2.2: Cliente/servidor con servidores de Bases de
Datos.................28
Figura 2.3: Cliente/servidor con Servidores
Web.......................................28
Figura 2.4: Aplicación Cliente/Servidor para pequeñas empresas y
departamentos...........................................................................30
Figura 2.5: Diferentes tipos de diagramas definidos por
UML...................38
Figura 2.6: Ejemplo de implementación del diagrama de casos de uso
De los estudiantes del Departamento de
Computación...................41
Figura 2.7: Representación gráfica de la clase Laboratorio
de
SIDECOM.............................................................................42
Figura 2.8: Diagrama de clase para el proceso de solicitar y prestar
Equipo de
SIDECOM...................................................................................44
Figura 2.9: Entorno simplificado de un sistema de base de
datos..............46
Figura 2.10: Esquema de solicitud en Java de tipos de
objetos.................56
Figura 2.11: Esquema del Puente JDBC-
ODBC.........................................63
Figura 2.12: Esquema JDBC Java/Protocolo
Nativo...................................64
Reconocimiento
Revisión Bibliográfica
23
Figura 2.13: Esquema JDBC Net
Puro........................................................64
Figura 2.14:. Esquema JDBC 100%
Java...................................................64
Capítulo 3:
Figura 3.1: Diagrama de Casos de Uso del Sistema de Información
para el control académico, de Investigación y Extensión del
Departamento de
Computación...............................................81
Figura 3.2: Diagrama de casos de uso para el control de las actividades
de los Estudiantes del Departamento de
Computación..........86
Figura 3.3: Diagrama de casos de uso para el control de las
actividades realizadas por la Secretaria del Departamento
de
Computación......................................................................87
Figura 3.4: Diagrama de casos de usos para el control de las actividades
realizadas por el Profesor del Departamento de
Computación.
..........................................................................87
Figura 3.5: Diagrama de casos de uso para el control de las actividades
realizadas por el Jefe del Departamento de
Computación.
.........................................................................88
Figura 3.6: Diagrama de casos de uso de las actividades que el Pasante
externo y el Visitante realizan en el Departamento de
Computación............................................................................88
Figura 3.7: Diagrama de casos de uso para el control de las actividades
Reconocimiento
Revisión Bibliográfica
24
realizadas por el Cotutor Externo en el Departamento de
Computación.
.........................................................................88
Figura 3.8: Diagrama de clases para el control de datos personales y
curriculares de los Profesores del Departamento de
Computación..........................................................................94
Figura 3.9: Diagrama de clases para el control de la carga laboral de
los Profesores del Departamento de
Computación...............94
Figura 3.10: Diagrama de clases para el control de los planes e informes
de actividades de los Profesores del Departamento de
Computación.......................................................................95
Figura 3.11: Diagrama de clases para el control de los datos personales,
curriculares y académicos de los Estudiantes del
Departamento de Computación..........................................95
Figura 3.12: Diagrama de clases para el control de concursos, carga
laboral y datos administrativos de los Preparadores y Beca
Trabajos del Departamento de Computación....................96
Figura 3.13: Diagrama de clases para el control de los datos personales,
académicos y carga laboral de los Pasantes Externos y
Cotutores relacionados al Departamento de
Computación.
......................................................................96
Figura 3.14: Diagrama de clases para el control de las evaluaciones y
calificaciones de estudiantes en Asignaturas pertenecientes
al Departamento de
Computación......................................97
Figura 3.15: Diagrama de clases para el control de Proyectos de Grados
asesorados por profesores del Departamento de
Reconocimiento
Revisión Bibliográfica
25
Computación.......................................................................9
7
Figura 3.16: Diagrama de clases para el control de las Pasantías
Industriales y de Investigación realizadas por estudiantes
asesorados por profesores del Departamento de
Computación.......................................................................9
8
Figura 3.17: Diagrama de clases para el control de Equipos
pertenecientes al Departamento de Computación............98
Figura 3.18: Diagrama de clases para el control de los Laboratorios
coordinados por profesores del Departamento de
Computación......................................................................99
Figura 3.19: Diagrama de clase para el control de las Publicaciones
hechas por Estudiantes asesorados por profesores del
Departamento de Computación.........................................99
Figura 3.20: Diagrama de clase para el control de las Publicaciones
hechas por Profesores del Departamento de
Computación....................................................................100
Figura 3.21: Diagrama de clases para el control de Eventos asistidos
por profesores y estudiantes del Departamento de
Computación....................................................................100
Figura 3.22: Diagrama de clases para el control de los Permisos
solicitados por los profesores del Departamento de
Computación.........................................................................
101
Figura 3.23: Diagrama de clases para el control de las Reuniones
del Departamento de
Computación......................................101
Figura 3.24: Modelo Cliente/Servidor
utilizado..........................................106
Reconocimiento
Revisión Bibliográfica
26
Figura 3.25: Contexto de
SIDECOM.........................................................107
Figura 3.26: Esquema parcial para el control de las actividades
académicas del
departamento.............................................109
Figura 3.27: Esquema parcial para el control curricular y las actividades
de extensión de profesores y estudiantes del
departamento.......................................................................1
10
Figura 3.28: Esquema parcial para el control de las actividades de
investigación de los profesores y estudiantes
del
departamento................................................................110
Figura 3.29: Esquema parcial para el control de las actividades
administrativas que involucran profesores y estudiantes del
departamento.......................................................................1
11
Figura 3.30: Diagrama de Clases Estático Integrado de
SIDECOM........112
Figura 3.31: Página Principal de SIDECOM
............................................115
Figura 3.32: Opción para crear Nueva Cuenta (sólo por usuario
autorizados).........................................................................1
15
Figura 3.33: Creación de Nuevas Cuentas dependiendo del
tipo de
Usuario....................................................................115
Figura 3.34: Opción para crear Nueva
Contraseña.................................115
Figura 3.35: Módulos Principales de SIDECOM
.....................................118
Figura 3.36: Categoría Datos Básicos - Opción Estudios
Reconocimiento
Revisión Bibliográfica
27
Realizados..........................................................................1
19
Figura 3.37: Categoría Docencia – Opción Proyectos de
Grados.........119
Figura 3.38: Categoría Datos Básicos – Opción Hoja de Vida
...............121
Figura 3.39: Categoría Académicos – Opción Evaluaciones
.................121
Figura 3.40: Categoría Publicaciones – Opción Informes de
Pasantías...........................................................................12
2
Figura 3.41: Opción Pasantes Externos del Módulo
Administrativos..................................................................12
3
Figura 3.42: Opción Control de Equipos del Módulo
Administrativos..................................................................12
3
Figura 3.43: Diagrama de Módulos de
SIDECOM.................................134
Capitulo4:
Figura 4.1: Representación gráfica del modelo relacional hecha en la
herramienta
PowerDesigner...............................................136
Figura 4.2: Comando CEATE TABLE usado en la Entidad
Estudiante...........................................................................137
Figura 4.3: Comando CREATE INDEX usado en la Entidad
Estudiante...........................................................................138
Figura 4.4: Comandos DROP INDEX y DROP TABLE usados en la
Entidad Estudiante ............................................................138
Figura 4.5: Opción para generar el archivo creaba.sql en el
Reconocimiento
Revisión Bibliográfica
28
PowerDesigner................................................................139
Figura 4.6: Opción para generar el archivo creatrg.trg en el
PowerDesigner. ..............................................................139
Figura 4.7: Creación de la Base de Datos............................................140
Figura 4.8: Conexión ODBC.. ..............................................................141
Figura 4.9: Selección del Origen de Datos...........................................142
Figura 4.10: Configuración del ODBC para la conexión final...............142
Figura 4.11: Representación de la Base de Datos final.......................143
Figura 4.12: Paquete TesisBean del proyecto IntegracionTesis
creados en VisualAge 3.02.............................................145
Figura 4.13 Paquete TesisClases del proyecto IntegraciónTesis
creados en VisualAge 3.02..............................................145
Figura 4.14: Paquete TesisGUI del proyecto Integración Tesis
creado en VisualAge 3.02.............................................146
Figura 4.15: Código del Constructor de la clase DataBase...............148
Figura 4.16: Código del método Actualizar().....................................148
Figura 4.17: Código del método Consultar()......................................149
Figura 4.18: Código del método InitDataBase()................................149
Figura 4.19: Código del método CloseDataBase()............................149
Figura 4.20: Código del método Main...............................................150
Figura 4.21: Código del constructor de la clase DESenc y el método
DESenc()......................................................................152
Figura 4.22: Código del método DESdesencrypt()............................153
Figura 4.23: Código del método Main().............................................153
Figura 4.24: Código de la clase PropertiesTest................................154
Figura 4.25: Código del archivo System.Properties..........................154
Figura 4.26: Código el archivo JefeDepartamento.properies............155
Figura 4.27: Código del método del botón Entrar de la página
principal de SIDECOM................................................156
Figura 4.28: Prueba de datos reales en la pantalla Proyecto de Grado
en el Módulo Profesores.............................................160
Reconocimiento
Revisión Bibliográfica
29
INDICE DE TABLAS
Capitulo 2:
Tabla 2.1 : Características de los SIOp
......................................................23
Tabla 2.2: Características de los Sistemas
Cliente/Servidor.......................27
Tabla 2.3: Ventajas y desventajas del enfoque
centralizado......................32
Tabla 2.4: Términos utilizados en la definición de UML. ...........................
35
Tabla 2.5: Tipo de actores utilizados en los diagramas
de casos de
uso.........................................................................39
Tabla 2.6: Tipo de relaciones utilizados en los diagramas
de casos de
uso.........................................................................40
Tabla 2.7: Valores convencionales de
multiplicidad...................................43
Tabla 2.8: Tipos de asociaciones usados en los diagramas de
casos de
uso.............................................................................44
Tabla 2.9: Característica, recursos de ayuda y ventajas del Enfoque
de Base de
Datos.....................................................................47
Tabla 2.10: Modelos de SGBD y sus
características.................................48
Tabla 2.11: Etapas Lógicas del
ODBC.......................................................62
Capitulo 3:
Reconocimiento
Revisión Bibliográfica
30
Tabla 3.1: Esquema de la metodología MEDÍS-OO y las técnicas
utilizadas para su
desarrollo....................................................67
Tabla 3.2: Diagrama funcional jerárquico del sistema de actividades del
Departamento de
Computación...............................................76
Tabla 3.3: Entidades para el sistema de actividades del Departamento
de
Computación......................................................................79
Tabla 3.4: Recapitulación de los actores y casos de uso
de
SIDECOM...........................................................................85
Tabla 3.5: Requerimientos de
salida........................................................92
Tabla 3.6: Tipo de entidades presentes en los procesos del sistema
de
actividades...........................................................................103
Tabla 3.7: Entidades Utilizadas para la Construcción de los Esquemas
Parciales del
Sistema..............................................................108
Tabla 3.8: Control del despliegue de datos del Jefe del Departamento
en los módulos de
SIDECOM................................................117
Tabla 3.9: Entidad
ActadeEvento.............................................................130
Capitulo 4:
Tabla 4.1: Jerarquía de los componentes de VisualAge 3.02.
para el manejo de
programas................................................144
Tabla 4.2: Métodos implantados en la clase DataBase del
Reconocimiento
Revisión Bibliográfica
31
paquete
TesisClases..............................................................147
Tabla 4.3: Métodos implantados en la clase DESenc del paquete
TesisClases...........................................................................150
Reconocimiento
Revisión Bibliográfica
32
CAPÍTULO 1: INTRODUCCIÓN
La integración de la computación en la vida cotidiana ha hecho cambiar
notoriamente nuestra forma de pensar y actuar ante situaciones y procesos
trascendentes de comunicación que requieren de soluciones eficaces,
consistentes y rápidas y que forman parte del proceso de toma de decisiones
de un ente. La búsqueda del mejoramiento de dichos procesos se ha orientado
en la creación de sistemas especializados informáticos, tales como, sistemas
de información, bases de datos, sistemas de control y una gran diversidad de
aplicaciones esenciales para la automatización organizacional, que nos ofrecen
apoyo a actividades muy particulares y que pueden eventualmente adaptarse a
cambios en la estructura y el contenido de los objetivos de cualquier
organización.
En el caso de los sistemas de información, éstos crean relaciones
lógicas entre sus elementos componentes para realizar un trabajo coordinado
que permite la captura, validación, procesamiento, almacenamiento,
transformación y presentación de los datos. Sin embargo, la integración de un
sistema de información en el ámbito organizacional dependerá de las
necesidades propias de la utilización del sistema por parte de los usuarios y de
las tareas por realizar, así como de los requerimientos crecientes de
disponibilidad, veracidad y rapidez en la búsqueda y procesamiento de los
datos que la sustentan [Barrios99].
Se desea con este proyecto de grado desarrollar un sistema de
información que apoye, en forma automatizada, las actividades que el
Departamento de Computación lleva a cabo y que determinan el tipo de gestión
que ejecuta.
Reconocimiento
Revisión Bibliográfica
33
El Departamento de Computación fue creado en 1975 y está adscrito a
la Escuela de Sistemas de la Universidad de Los Andes con la finalidad de
formar profesionales capaces de realizar trabajos fundamentales técnicos
en el área de la informática. Es ésta, entonces, la unidad académica
responsable de la formación en computación de los estudiantes de la carrera
de Ingeniería de Sistemas.
Actualmente, en este departamento se realizan importantes actividades
que son llevadas a cabo manualmente, lo que implica un gran consumo de
tiempo en su ejecución y sobrecargo de trabajo para el personal que lo
controla, convirtiéndolas posiblemente en ineficientes.
Sin embargo, la Escuela de Ingeniería de Sistemas está llevando a cabo
un proceso de automatización que ha sido iniciado con la creación de un
sistema de información que permite llevar de manera organizada la información
de las diversas actividades realizadas por el personal docente del
departamento [Quero2001]. Este sistema se programó en el lenguaje orientado
a objetos Java con conexión a una base de datos remota por medio de la
implantación de un socket (enchufe virtual entre dos máquinas) y un puente
ODBC (Open Database Connection) – JDBC (Java Database Connection);
además, fue construido en forma de dos Applets incrustados en una dirección
URL y presentó una interfaz con pantallas sencillas y fáciles de manejar.
Así pues, este proyecto de grado plantea la Integración y Ampliación del
Sistema de Información para el Control Académico, de Investigación y
Extensión del Departamento de Computación, cuyo objetivo principal es el
apoyo a las actividades curriculares, laborales y administrativas del profesorado
que labora en dicho departamento y el control de las actividades que involucran
el estudiantado.
Reconocimiento
Revisión Bibliográfica
34
1.1 PLANTEAMIENTO DEL PROBLEMA:
En la actualidad, debido a la creciente demanda de los estudiantes en
cursar asignaturas coordinadas por el departamento de computación, los
procesos involucrados en llevar a cabo sus funciones han aumentado
vertiginosamente en esfuerzo y volumen. Además, la ejecución de estos
procesos es hecha en forma manual y, por estas razones, se requiere de un
cambio en la forma de realizar las actividades, buscando con esto idear un
sistema automatizado que proporcione un mejor control del volumen de datos
de manera fácil, rápida y segura.
Es necesario, entonces, desarrollar un sistema de información que
permita apoyar las gestiones del Departamento de Computación y mejorar el
almacenamiento y actualización de la data con el fin de obtener optimización en
los principales procesos y en el flujo de información necesario en la toma de
decisiones futuras.
1.2 JUSTIFICACIÓN:
Dada la forma actual del procesamiento de los datos, de naturaleza
delicada y compleja, que maneja el Departamento de Computación y, debido al
flujo creciente de información que requiere del control en su almacenamiento,
transformación y presentación, nos vemos en la premura de realizar un sistema
de información que soporte procesos confiables, automatizados considerando
las necesidades de quienes manipulan la información y controlan dichas
acciones.
Ahora bien, es imprescindible que este sistema cumpla con aspectos
significativos que son los que garantizarán la solución a la situación
problemática señalada. Estos aspectos están fundamentados en: el origen del
sistema de actividades llevadas a cabo por la organización, el análisis de los
usuarios actuales y potenciales que manipularán el sistema propuesto, el tipo
Reconocimiento
Revisión Bibliográfica
35
de datos que debe almacenarse y transformarse y el tipo de información que
producirá.
1.3 OBJETIVOS:
En este proyecto se tiene como objetivo principal apoyar las actividades
curriculares, académicas, laborales y administrativas de los profesores y
estudiantes que pertenecientes al Departamento de Computación, a través de
la integración del sistema de información desarrollado originalmente para el
departamento, que abarca las actividades de los profesores que allí laboran,
logrando con esto ampliar las aplicaciones y utilidad del sistema inicial y así
ofrecer el control de los procesos que allí se llevan a cabo.
1.4 METODOLOGÍA:
La metodología empleada en el desarrollo de este proyecto está basada
en la metodología MEDIS-OO (Metodología Orientada por Objeto para el
Desarrollo de Sistemas de Información) [Mont97b, Mon97d] que describe los
pasos necesarios para especificar los requerimientos, diseñar bases de datos,
implementar y probar un Sistema de Información (SI) orientado a objetos.
Así mismo, se utilizaron herramientas que permiten el modelado de
sistemas y bases de datos como el lenguaje de modelado unificado (UML)
[Muller97] y el modelo para aplicaciones cliente/servidor.
Además, se tomaron en cuenta aspectos importantes para el diseño del
sistema como la tecnología y los mecanismos de comunicación disponibles, los
usuarios y la funcionalidad del sistema que nos permitieron definir el sistema en
estudio como una aplicación conectada a una base de datos centralizada y
accesos distribuidos.
Reconocimiento
Revisión Bibliográfica
36
Una vez definidos y diseñados el sistema y la base de datos, la fase de
construcción e implementación del diseño fue llevada a cabo por medio de
herramientas computacionales que permitieron transformar el modelo orientado
a objetos a un esquema relacional implementable. La construcción de la
interfaz usuario-sistema y la programación de sus módulos estuvieron basados
en el lenguaje de programación orientado a objetos, Java [Int-2].
La conexión de la aplicación creada con la base de datos remota fue
hecha mediante el uso de controladores ODBC (Object Data Base
Connectivity) y JDBC (Java Data Base Connectivity) y se usó una arquitectura
de dos capas para la construcción de la aplicación cliente/servidor.
Por último, se diseñaron pruebas de distintas índoles que ayudaron a la
validación y depuración del sistema.
1.5 ALCANCE DEL SISTEMA:
Dado que este proyecto produce un sistema de información que soporta
la administración del Departamento de Computación llevando el control
automatizado de los recursos que allí se manejan, se propone que este sistema
puede ser utilizado como proyecto motor para trabajos futuros de mayor
envergadura donde se involucren, por ejemplo, otros departamentos de la
Escuela de Sistemas, y posteriormente otras escuelas de la Facultad de
Ingeniería con el fin de crear un sistema integrado y donde sea factible
incorporar otras diversas actividades.
Se espera, además, alcanzar una mayor eficiencia en el manejo de los
recursos y actividades con mayor velocidad de repuesta en la búsqueda de la
Reconocimiento
Revisión Bibliográfica
37
información en el momento en que se necesite, acelerando de esta forma los
procesos que requieren de ella.
Por otro lado, la base de datos de este sistema debe cumplir con las
restricciones de integridad necesarias que permitan administrar correctamente
el flujo de información mediante al especificación de los tipos de datos, la
relación entre los archivos, el espacio de almacenamiento y redundancias en el
ingreso y consulta de datos. Al considerar estas restricciones obtendremos un
sistema con procesos de depuración y mantenimiento mucho más cómodos de
ejecutar .
La información que este sistema manejará será definida por el tipo de
actividad que se apoye. Así, se presenta a continuación la información que
podrá ser consultada en el sistema:
• Datos curriculares, académicos, laborales y administrativos de los
profesores y los estudiantes del departamento,
• Información general sobre el pénsum de la carrera, semestres, y
horarios de asignaturas y laboratorios que pertenezcan a la
unidad.
• Calificaciones de estudiantes en asignaturas coordinadas por el
departamento en determinado semestre.
• Información sobre proyectos de grado y pasantías cuyas tutorías
son llevadas a cabo por profesores del área de computación.
• Evaluaciones propuestas en asignaturas, laboratorios y prepara-
durías supervisadas por el departamento de computación.
• Información sobre beca-trabajos, pasantes externos y
preparadores.
• Control de los equipos que pertenecen al departamento.
• Eventos auspiciados por esta unidad.
• Publicaciones hechas por estudiantes y profesores.
Reconocimiento
Revisión Bibliográfica
38
1.6 ESTRUCTURA DE LA MONOGRAFÍA:
La organización de esta monografía viene dada de la siguiente manera:
el capítulo 2 presenta la reseña bibliográfica que sustenta la teoría aplicada en
este proyecto. El capítulo 3 expone el análisis y diseño del sistema, cuyo
desarrolló implicó los siguientes aspectos: análisis del sistema de actividades,
especificación de los requerimientos que el sistema debe cumplir, la
arquitectura del sistema que incluye el diseño conceptual de la base de datos y
el diseño de la interfaz usuario-sistema, el diseño implementable del sistema y
el diseño de programas. El capítulo 4 expone la implementación de la base de
datos, los programas que conforman los módulos del sistema y las pruebas
hechas para la validación y verificación final
Por último, se presentan las conclusiones del trabajo y se especifican
una serie de recomendaciones que contribuyen al mejoramiento futuro del
sistema desarrollado.
Reconocimiento
Revisión Bibliográfica
39
CAPÍTULO 2: REVISIÓN BIBILIOGRÁFICA
2.1 SISTEMAS DE INFORMACIÓN: Bases Teóricas Aplicadas
Unas de las herramientas computacionales más importantes en la
actualidad, capaces de cubrir la necesidad que tiene todo individuo o miembro
de una organización de intercambiar información y datos, son los Sistemas de
Información (SI).
Así pues, podemos definir un sistema de información computarizado
como un sistema que a través de la tecnología informática manipula un
conjunto de datos y los convierte en la información requerida para apoyar tanto
a las actividades organizacionales, como a la toma de decisiones. Este tipo de
sistema incluye todos los recursos dentro de la organización que participa en la
recolección, administración, uso y diseminación de la información [Barrios95].
Los sistemas de información están básicamente clasificados en dos
grupos, el primero relacionado con el grado de cobertura de las actividades
organizacionales, conocidos como sistemas independientes o aislados:
sistemas integrados (SII) y sistemas organizacionales (SIO). El segundo grupo
considera el grado de apoyo a las actividades organizacionales que brindan los
sistemas de información, donde se distinguen: los sistemas operacionales
(SIOp) y gerenciales (SIGe), ejecutivos (SIE) y de apoyo a la toma de
decisiones (SATD).
De esta manera, el sistema de información desarrollado en este proyecto
se encuentra categorizado en el grupo de los Sistemas de Información
Operacionales, mencionados anteriormente, debido a las actividades que
soporta y las características que presenta.
Las siguientes secciones estarán dedicadas a describir las bases
teóricas que permitieron definir el sistema de información implantado y la
Reconocimiento
Revisión Bibliográfica
40
infraestructura organizacional utilizada para la automatización de la información
ofrecida por el sistema.
2.1.1 Sistemas de Información Operacionales (SIOp):
Los sistemas de información operacionales son aquellos que
automatizan, capturan y manipulan los datos originados por las diversas
transacciones y actividades básicas administrativas y de producción de una
organización, que tienen un carácter repetitivo y que, por lo general, están
relacionadas con grandes volúmenes de datos [Barrios97].
Estos sistemas tiene que ver con el quehacer cotidiano organizacional,
permitiendo un mejor control sobre sus elementos internos, tanto en el plano
productivo, como en el administrativo, asegurando su privacidad, actualización
y disposición ante la organización.
El implantación de un SIOp dentro de una organización dependerá de
los tipos de actividades a las que se dedique la unidad. Por ejemplo, en una
organización educativa, los sistemas operacionales son aquellos que llevan los
datos de estudiantes, asignaturas, horarios, profesores, calificaciones,
inscripciones, carreras, cargos administrativos, laboratorios, entre otros.
Bastará entonces conocer aquellas actividades que se realizan repetidas veces
de la misma forma, registradas y controladas en forma manual, mecánica o
semiautomática.
Características de los SIOp:
Entre algunas de las características que distinguen los sistemas
operacionales encontramos las descritas en la tabla 2.1:
Característica Detalles
Son el punto de partida para Todo sistema de información en su parte más
Reconocimiento
Revisión Bibliográfica
41
formar cualquier otro tipo de
sistema de información:
interna, es un sistema de procesamiento primario
de datos.
Apoyan actividades
definidas:
Rutinarias, repetitiva y generadoras de grandes
volúmenes.
Manipulan datos operativos
y administrativos:
Estos datos son originados por los procesos
básicos de la organización y sus entidades.
Capturan los datos
producidos por las
transacciones y
operaciones:
Es para esto que se utilizan sistemas de
adquisición de datos para la captura de los
registros del proceso que lo origina.
El procesamiento sobre los
datos es simple:
La transformación es a nivel de presentación al
usuario y en relación a los formatos de captura.
La información producida es: - Referida al pasado y el presente en forma muy
detallada,
- Relacionada con procesos muy bien definidos y
estructurados,
- Los reportes y consultas se refieren a
transacciones completas.
La Interacción
Hombre/Máquina posee a su
vez las siguientes
características:
- Es fácil de entender y operar,
- Está basada en el uso de menús
desplegables y el manejo de botones, presenta
ayudas en línea y permite al usuario decidir la
información que desea junto con el formato de
presentación adecuado.
- Contiene validaciones de transacciones que
cap-turan datos para que puedan ser
completados o anulados.
Tabla 2.1 : Características de los SIOp
Debido entonces, a que el apoyo fundamental que brindan los sistemas
operacionales radica en la automatización de los registros básicos de la
Reconocimiento
Revisión Bibliográfica
42
organización, es indispensable considerar el enfoque más adecuado de
infraestructura organizacional que permitirá instituir la comunicación y
cooperación entre las unidades funcionales de la organización.
2.1.2 Automatización Organizacional de la Información:
La automatización organizacional surge como una respuesta a las
necesidades informáticas crecientes representadas por las dificultades de los
usuarios ante sistemas tradicionales y aislados que no permiten mayor
comunicación entre las unidades funcionales de una misma organización. Este
tipo de automatización contempla el uso del computador y sus aplicaciones
como elemento esencial de apoyo y ejecución de las diversas tareas en
cualquiera de los niveles gerenciales.
El factor principal que lleva a toda organización a alcanzar un nivel alto
de automatización, se relaciona con la eficiente utilización de la información
que apoyará el cumplimiento de los distintos objetivos formulados. De aquí, que
la infraestructura organizacional de información forma parte del esqueleto
tecnológico a través del cual se establece la comunicación automatizada dentro
de la organización. Es decir, el proceso de automatización debe iniciarse como
resultado de una planificación estratégica gerencial donde se tome en cuenta la
infraestructura organizacional más adecuada.
Observando la figura 2.1, se establece que el grado de automatización
de una organización dependerá de la Tecnología de Información (TI) básica
requerida por la infraestructura de información, dada entonces por las redes de
computadores, las aplicaciones distribuidas y las bases de datos corporativas
centralizadas o distribuidas; los cuales permiten la comunicación y el
procesamiento de datos entre los SI a través de medios físicos.
Reconocimiento
Revisión Bibliográfica
43
Figura 2.1: Componentes de la automatización
organizacional [tomado de Barrios99].
A continuación, se describen los conceptos más relevantes sobre la TI
mínima que una infraestructura organizacional de información estable debe
manejar.
2.1.2.1 Redes de Computadoras:
Una red de computadoras es un conjunto de enlaces de comunicación,
cables, enrutadores, equipos de conmutación, pilas de transporte y
procesadores autónomos conectados entre sí para intercambiar datos e
información [Orfali98]. Las redes facilitan la comunicación entre elementos de
la organización físicamente distantes y que necesitan compartir datos.
Existen dos grandes categorías de redes: redes de área local (LAN: local
area network), que cubren distancias cortas, por lo general un edificio o
+
Sistemas de Información
+ A t ti ió d Ofi i
Automatización de
Producción
Organización
Bases de Datos Corporativas Aplicaciones Distribuidas
Redes de Computadores
Reconocimiento
Revisión Bibliográfica
44
campus, y redes de área amplia (WAN: wide area network), que cubren
grandes extensiones geográficas.
La razón central que conlleva a las organizaciones a implantar redes de
ordenadores, es la necesidad de compartir recursos costosos de TI que no
pueden adquirirse para cada unidad funcional en forma separada, logrando así,
un ahorro económico notable para la organización. Por esta razón, las redes
constituyen la base sobre la cual descansa la infraestructura de información de
una organización, por lo que son imprescindibles para que la automatización
organizacional sea eficiente [Barrios99].
2.1.2.2: Sistemas Cliente/Servidor:
El cliente y el servidor son entidades lógicas independientes que operan
en conjunto a través de una red para realizar una tarea [Harkey98]. Estos
componentes en algún momento solicitan el servicio de otro componente,
comportándose los primeros como clientes y los segundos como servidores.
Así pues, decimos que un sistema cliente-servidor es aquel sistema distribuido,
en el cual existen componentes que prestan servicios y otros componentes que
solicitan dicho servicio [Barrios97].
Todos los sistemas cliente/servidor poseen características que permiten
la fácil distribución de inteligencia a lo largo de una red y el diseño de holgadas
aplicaciones [Orfali98]. La tabla 2.2 presenta las características más relevantes
de un sistema cliente/servidor:
Características Detalles
Servicio: Un sistema cliente/servidor es una relación entre
procesos ejecutados en aparatos distintos donde el
servidor es un proveedor de servicios y el cliente un
consumidor de servicios.
Reconocimiento
Revisión Bibliográfica
45
Recursos
compartidos:
Un servidor puede atender a muchos clientes al
mismo tiempo y regular su acceso a recursos
compartidos.
Protocolos
asimétricos:
Entre clientes y servidor se establece una relación
de “muchos a uno”. Los clientes inician el diálogo al
solicitar el servicio y los servidores aguardan
pasivamente por las solicitudes de los clientes.
Características Detalles
Transparencia de
ubicación:
El servidor puede residir en la misma máquina que
el cliente o una máquina distinta por la red dado
que suele ocultarse la ubicación del servidor
mediante el redireccionamiento de las llamadas de
servicio.
Integridad: El código y datos del servidor se conservan
centralmente, lo que resulta en un mantenimiento
de menor costo y en la protección de la integridad e
independencia de los datos compartidos.
Intercambios
basados en
mensajes:
Los clientes y servidores son sistemas
holgadamente acoplados que interactúan a través
de un mecanismo de transmisión de mensajes para
entregar solicitudes y respuestas de servicio.
Encapsulamiento
de servicios:
El servidor es “especialista”. Un mensaje le indica a
un servidor qué servicio se solicita y éste se lo
envía luego al servidor para determinar el
cumplimiento de la tarea.
Mezcla e igualdad: El software ideal de cliente/servidor es
independiente del hardware o de las plataformas de
software del sistema operativo y se debe ser capaz
de mezclar o igualar plataformas de cliente y de
servidor.
Tabla 2.2: Características de los Sistemas Cliente/Servidor.
Reconocimiento
Revisión Bibliográfica
46
La idea de dividir una aplicación a lo largo de líneas cliente/servidor se
ha utilizado en los últimos diez años para crear diversas modalidades de
soluciones. Sin embargo, cada una de estas soluciones se distinguen por la
naturaleza del servicio que ofrece a sus clientes y las diferentes arquitecturas,
como se indican a continuación:
• Servidores de Archivos,
• Servidores de Base de Datos,
• Servidores de Transacciones,
• Servicios de Groupware,
• Servidor de Objetos,
• Servidor de Web.
Seguidamente se presenta la definición de los servidores utilizados en
este proyecto.
Reconocimiento
Revisión Bibliográfica
47
Servidores de Bases de Datos: El cliente envía solicitudes de SQL en calidad de
mensajes al servidor (ver figura 2.2). Los resultados de cada orden de SQL son
devueltos y el genera un uso mucho más eficiente de la capacidad del procesamiento
distribuido. Estos servidores constituyen el fundamento de los sistemas de apoyo de
decisiones que precisan de consultas específicas.
Servidor Web: En este nuevo modelo de cliente, un servidor Web envía
documentos cuando los clientes los solicitan por su nombre comunicándose
mediante un protocolo denominado http (vea figura 2.3).El Web y los objetos
distribuidos ya han comenzado a combinarse y Java es la primera manifestación.
Aplicación
AplicaciónClientes
Llamadas de SQL
Servidor
Servidor de DBMS
Figura 2.2: Cliente/servidor con servidores de Bases de Datos
http sobre TCP/IP
Internet
Java
HTML y FormasVisualizador
W b
Servidor
Documentos de HTML
Aplicación
CGI
Reconocimiento
Revisión Bibliográfica
49
2.1.2.3 Aplicación Cliente/Servidor:
El desarrollo de aplicaciones cliente/servidor requiere de habilidades
híbridas, entre las que encontramos el procesamiento de transacciones, el diseño
de bases de datos, experiencia en comunicaciones y conocimientos en interfaz
gráfica del usuario y para aplicaciones más avanzadas, se requiere de
conocimientos de objetos distribuidos e Internet.
Debido a esto, la mayoría de las soluciones actuales de clientes/servidores
son implementaciones de LAN de PC personalizadas para el grupo que las usa.
De aquí, que los departamentos de Sistemas de Información cuentan con la
capacidad no sólo para administrar y desplegar grandes redes, sino también para
ofrecer estándares de interoperabilidad. También saben afinar aplicaciones,
distribuir tareas y asegurar la integridad de los datos. La clave, entonces, consiste
en hacer lo que saben hacer en un entorno de clientes/servidores distribuidos en
el que compartan capacidad, responsabilidad, habilidades de computación y
presupuestos financieros con los gerentes de línea de las empresas (los usuarios
finales). En consecuencia, la distribución de la función de Sistemas de Información
es esencial [Orfali, 98].
Existen diferentes formas de modelos cliente/servidor que pueden ser
usadas simultáneamente en un ambiente complejo, como son:
• Arquitectura de una capa: Donde aplicaciones completas se ejecutan en
el anfitrión (host).
• Arquitectura de dos capas: Se tiene un servidor de base de datos y el
resto de las aplicaciones se ejecutan completamente sobre el cliente o
pueden ser ejecutadas sobre el servidor de bases de datos. Esta
arquitectura es una de las más usada.
Reconocimiento
Revisión Bibliográfica
50
• Arquitectura de tres capas: Significa que divide la aplicación en tres
partees: la primera es la interfaz del usuario con la presentación comple-ta;
la segunda es la lógica comercial y la tercera es la base de datos.
En el caso de los modelos cliente/servidor de dos capas, encontramos que
este tipo de aplicación predomina en el 80% de los establecimientos con un único
servidor basado en LAN, que a su vez se compone de múltiples clientes en
comunicación con un servidor local (ver figura 2.4). Lo único que el cliente
necesita es consultar un archivo de configuración para identificar el nombre del
servidor. La seguridad está implementada al nivel de la máquina y también es muy
sencilla. Las interacciones entre servidores no son complejas, de manera que es
muy sencillo detectar fallas: éstas se encuentran ya sea en el cliente o en el
servidor local.
Figura 2.4: Aplicación Cliente/Servidor para pequeñas empresas
y departamentos.
El elemento cliente ejecuta la parte del cliente de la aplicación. Corre en un
sistema operativo (OS: operating system) que ofrece una interfaz gráfica de
usuario (GUI: graphical user interface) o una interfaz de usuario orientada a objeto
(OUI: object oriented user interface) y que pueda acceder a servicios distribuidos,
dondequiera que se encuentren.
Cliente Servidor
Middleware
Reconocimiento
Revisión Bibliográfica
51
Los servidores departamentales seguirán siendo muy comunes, incluso en
grandes instituciones, debido a que ofrecen un alto grado de autonomía y
controles a los usuarios y las aplicaciones de un servidor departamental suelen
atender primeramente las necesidades específicas de los clientes locales, lo que
satisface en gran medida a los usuarios.
Reconocimiento
Revisión Bibliográfica
52
2.1.2.4 Bases de Datos Corporativas:
Una BD Corporativa es aquella que contiene todos los datos relacionados
con una organización, definidos como entidades internas y externas,
transacciones y procesos, actividades y tareas, las cuales tienen un
comportamiento en el tiempo que es necesario almacenar para manejo posterior
[Barrios97].
Estas bases de datos pueden estar almacenadas en diferentes formas. La
primera de ellas es la centralizada que consiste en abarcar todos los datos en una
sola máquina, o servidor de base de datos1 (o de archivos), a la cual acceden las
demás máquinas clientes de la organización para consultar, modificar o
simplemente transferir información. La segunda forma consiste en una BD
corporativa distribuida; los datos se encuentran diseminados en distintas unidades
funcionales y poseen un SI que los manipulan y acceden desde otras unidades
cada vez que se precise.
La BD corporativa centralizada es custodiada y mantenida por una sola
unidad funcional de la organización cuya función es conservar la integridad y
consistencia de los datos almacenados y realizar actividades de seguridad y
control de acceso a través del Sistema Manejador de Base de Datos2 (SMBD)
ubicado en la máquina central, mainframe o servidor de archivos, que contiene la
BD centralizada. Cuando un nodo de la red, desea acceder a la BD, se investiga si
tiene o no derecho a hacerlo y, si es así, bajo que lineamientos le es permitido
consultar, actualizar o transferir datos de la base de datos. Así mismo, el servidor
es el encargado de proporcionar copias de los archivos o datos que los nodos
necesitan y de actualizarlos cuando sea necesario.
1 Consultar la sección 2.1.2.3: Sistemas Cliente/Servidor 2 Consulta la sección 2.4.1: Sistema de Gestión de Bases de Datos:
Reconocimiento
Revisión Bibliográfica
53
Dadas estas definiciones, consideramos que la base de datos de nuestro
sistema de información es una BD corporativa centralizada, debido a que los datos
del sistema se encuentran almacenados en un servidor de bases de datos
permitiendo la consulta y la modificación de la información por medio del acceso
autorizado de usuarios, que se encuentran ubicados en máquinas clientes y que
ingresan al sistema de información a través de una aplicación.
Ahora bien, debido a que la decisión de un enfoque particular de BD
depende directamente de las características de la organización, de la TI
disponible, de las capacidades de procesamiento local que existen, de la
disponibilidad de datos requeridos por los SI y de la distribución de cargas de
trabajo en las unidades funcionales, se presenta en la tabla 2.3 las ventajas y
desventajas que la infraestructura de información presenta dentro de una
organización con un enfoque centralizado:
Ventajas Desventajas
Ubicación de los datos en una
base de datos central.
Permite instalar aplicaciones
distribuidas para apoyo de oficina sólo
si los terminales del sistema son
microcomputadoras.
Ubicación de los SI en un nodo
central.
Limitación en la disponibilidad de
los datos.
Propiedad y seguridad de los
datos centralizados.
Presenta inconvenientes de acceso.
Mayor control de los datos y de
los SI.
El procesamiento local pierde
capacidad de operación independiente
y las unidades funcionales pierden
su autonomía
Tabla 2.3: Ventajas y desventajas del enfoque centralizado [Barrios97].
Reconocimiento
Revisión Bibliográfica
54
De aquí, que la TI mínima de un enfoque centralizado está conformada por
una máquina central o un servidor, terminales tontos o inteligentes, estaciones de
trabajo, SMBD centralizados y redes de computadoras. Estos elementos deberán
ser tomados en cuenta en el momento de implementar el sistema de información,
para que de esta manera pueda prestar el mejor servicio posible dentro de la
organización.
2.2 PROGRAMACIÓN ORIENTADO A OBJETOS:
El término orientado a objetos (OO) se refiere al concepto de reducir las
identidades y complejidades de todos los entes que pertenecen a un sistema, a la
condición simple de objetos. Se considera que todas las personas, lugares, cosas,
eventos y transacciones son objetos en el mundo orientado a objetos y la
naturaleza compleja de las relaciones entre estos objetos no es nada más que una
característica que ellos poseen. Este enfoque se opone diametralmente a los
enfoques más tradicionales que se concentran en separar los datos de los
procesos [Mattison98].
Los principios del concepto OO pueden ser aplicados de varias maneras en
la construcción de sistemas computarizados y se llevan a cabo a través del
modelado, diseño, programación y bases de datos OO.
Elementos Fundamentales en la Programación OO:
Los tres términos fundamentales asociados con la programación OO son
los objetos, los métodos y las clases [Wehling98], explicados a continuación:
1. Objetos: La estructura del objeto consiste en un conjunto de metodologías
de programación que pretende modelar las características de los objetos
del mundo real. Cada objeto tiene un estado, comportamiento e identidad
inherentes. Los objetos proporcionan un modelo de programación y los
Reconocimiento
Revisión Bibliográfica
55
objetos programados tienen las mismas características anteriormente
mencionada definidas por variables de instancia.
2. Clases: El concepto más importante de la programación OO es la clase. La
definición de clase consta de dos partes: el tipo de los objetos que pueden
ser miembros de la clase y los métodos que se pueden aplicar a dichos
objetos. Un objeto pertenece a una clase y por lo tanto posee un tipo y un
comportamiento especificado, que es determinado por los métodos de la
clase. Cuando los objetos se crean a partir de la clase, se denominan
instancias de esa clase.
3. Métodos y datos: Las tareas del objeto se realizan a través de métodos.
La implementación de las operaciones de cada clase se especifican en
términos de procedimientos predefinidos denominados métodos que
determinarán el comporta-miento de cada objeto. Por lo regular, un método
se invoca enviando un mensaje al objeto para que ejecute el método
correspondiente.
2.3 LENGUAJE UNIFICADO DE MODELADO ORIENTADO A OBJETOS UML:
El lenguaje para modelado unificado (UML), es un lenguaje para la
especificación, visualización, construcción y documentación de los artefactos de
un proceso de sistema intensivo [Alhir, 98].
La tabla 2.4 explica los términos usados en la definición acotada
anteriormente:
Reconocimiento
Revisión Bibliográfica
56
Definición Implementada Detalles
Como lenguaje: Es usado para la comunicación. Es decir, un medio
para capturar el conocimiento respecto a un tema y
expresar el conocimiento.
Como un lenguaje para
modelado:
Se enfoca en la comprensión de un tema a través de
la formulación de un modelo. El modelo abarca el
conocimiento del tema y su apropiada aplicación
constituye inteligencia.
Cuida la unificación: Integra las mejores prácticas de la ingeniería y los
sistemas de información pasando por todos los tipos
de sistemas, dominios y los procesos de ciclo de
vida.
Especifica sistemas: Es usado para comunicar "qué" se requiere de un
sistema y "cómo" un sistema puede ser realizado.
Visualiza sistemas: Es usado para describir visualmente un sistema
antes de ser realizado.
Construye sistemas: Es usado para guiar la realización de un sistema
similar a los "planos".
Documenta sistemas: Es usado para capturar conocimiento respecto a un
sistema a lo largo de todo el proceso de su ciclo de
vida.
Tabla 2.4: Términos utilizados en la definición de UML.
Así pues, UML no es:
• Un lenguaje de programación visual, sino un lenguaje de modelado
visual.
• Una herramienta de especificación, sino un lenguaje para el
modelado de especificaciones.
• Un proceso, sino que habilita procesos.
Reconocimiento
Revisión Bibliográfica
57
UML fue originalmente concebido por la Corporación Rational Software y
tres de los más prominentes metodologistas en la industria de la tecnología y
sistemas de información: Grady Booch, James Rumbaugh, y Ivar Jacobson ("The
Three Amigos"). El lenguaje ha ganado un significante soporte de la industria y ha
sido presentado al Object Management Group (OMG) y aprobado por éste como
un estándar (noviembre 17, 1997) [Int-1]. Su alcance extiende su uso más allá de
sus predecesores y es la experiencia y una gradual adopción del estándar, lo que
revelará su verdadero potencial y posibilitará a las organizaciones a darse cuenta
de sus beneficios.
Sin embargo, UML no prescribe ningún enfoque en particular para resolver
un problema, sino que es muy flexible y personalizable para adaptarse a cualquier
enfoque. Permite y promociona un proceso conducido por casos de uso, centrado
en la arquitectura, reiterativo, e incremental que sea orientado al objeto y basado
en componentes. Fundamentalmente, UML provee medios para dirigir puntos
concernientes a problemas, soluciones y resolución de problemas.
2.3.1 Ventajas en el Uso de UML:
UML es un lenguaje para modelado de propósito general evolutivo,
ampliamente aplicable, soportado por herramientas e industrialmente
estandarizado. Se aplica a una multitud de diferentes tipos de sistemas, dominios
y métodos o procesos.
• Como lenguaje de propósito general, se enfoca en el corazón de un
conjunto de conceptos para la adquisición, compartición y utilización de
conocimientos emparejados con mecanismos de extensión.
• Como un lenguaje para modelado ampliamente aplicable, puede ser
aplicado a diferentes tipos de sistemas (software y no - software),
dominios (negocios versus software) y métodos o procesos.
Reconocimiento
Revisión Bibliográfica
58
• Como un lenguaje para modelado soportable por herramientas, las
herramientas ya están disponibles para apoyar la aplicación del lenguaje
y especificar, visualizar, construir y documentar sistemas.
• Como un lenguaje para modelado industrialmente estandarizado, no es
un lenguaje cerrado, propiedad de alguien, sino más bien, un lenguaje
abierto y totalmente extensible reconocido por la industria.
UML posibilita la captura, comunicación y nivelación de conocimiento
estratégico, táctico y operacional para facilitar el incremento de valor, aumentando
la calidad, reduciendo costos y reduciendo el tiempo de presentación al mercado;
manejando riesgos y siendo proactivo para el posible aumento de complejidad o
cambio.
2.3.2 Los Diagramas de UML:
Los elementos de modelado UML son accesibles al usuario por medio de
proyecciones gráficas (elementos de visualización) representados por diagramas,
que ofrecen al usuario un medio para visualizar y manipular dichos elementos. Un
diagrama contiene atributos de colocación y de aspecto visual que sólo dependen
del punto de vista del analista [Muller 97].
La mayor parte de los diagramas se presentan bajos la forma de grafos,
compuestos de nodos y arcos que pueden mostrar todo o parte de las
características de los elementos del modelado, según el nivel de detalle útil en el
contexto de un diagrama dado. Los diferentes tipos de diagramas de UML se
explican a continuación en la figura 2.5, donde:
Reconocimiento
Revisión Bibliográfica
59
Figura 2.5 Diferentes tipos de diagramas definidos por UML
• Los diagramas de clases representan la estructura estática en términos de
clases y relaciones;
• Los diagramas de caso de uso representan las funciones del sistema desde
el punto de vista del usuario;
• Los diagramas de colaboración son una representación espacial de los
objetos, enlaces e interacciones;
• Los diagramas de objetos representa los objetos y sus relaciones y
corresponden a diagramas de colaboración simplificados, sin represen-
tación de envíos de mensajes;
• Los diagramas de secuencia son una representación temporal de los
objetos y sus interacciones;
• Los diagramas de estados– transacciones representan el comportamiento de una clase en términos de estados;
• Los diagramas de actividades representan el comportamiento de una
operación en términos de acciones;
• Los diagramas de componentes representan los componentes físicos de una aplicación;
• Los diagramas de despliegue representan el despliegue de los compo-
nentes sobre los dispositivos materiales.
Diagramas UML
Casos
Clase Secuenci
Estados
Colaboración Actividade
ComponeObjeto
Despliegue
Reconocimiento
Revisión Bibliográfica
60
Las secciones siguientes definen en forma detallada los conceptos de
los diagramas de casos de uso y diagramas de clases que han sido utilizados para
el modelado y el diseño del sistema en estudio desarrollado en el capítulo 3. 2.3.2.1 Diagrama de Casos de Uso:
Los diagramas de casos de uso describen la forma de acciones y
reacciones del comportamiento de un sistema desde el punto de vista de los
usuarios; permite definir los límites del sistema y las relaciones entre el sistema y
el entorno.
El modelo de los casos de uso comprende los actores, el sistema y los
propios casos de uso. Los actores se representan en forma de pequeños
personajes que desencadenan los casos de uso. Existen cuatro categorías de
actores principales, como se señala en la tabla 2.5:
Tipos de Actores Detalles
Actores principales: Son las personas que utilizan las funciones principales del
sistema.
Actores
secundarios:
Agrupa las personas que efectúan tareas administrativas.
Material externo: En esta categoría se encuentran los dispositivos
materiales utilizables e imprescindibles que forman parte
del ámbito de la aplicación.
Otros sistemas: Se agrupan aquí los sistemas con los que el sistema debe
interactuar.
Tabla 2.5: Tipo de actores utilizados en los diagramas de casos de uso.
Reconocimiento
Revisión Bibliográfica
61
Por otra parte, los casos de uso se determinan observando y precisando,
actor por actor, las secuencias de interacción –los escenarios- desde el punto de
vista del usuario. Los casos de uso son abstracciones del diálogo entre los actores
y el sistema; describen interacciones potenciales, sin entrar en los detalles de
cada escenario.
UML define tres tipos de relaciones entre actores y casos de uso, descritos en la tabla 2.6:
Tipos de Relaciones Detalles
La relación de
comunicación:
La participación del actor se señala por una
flecha entre el actor y el caso de uso, donde el
sentido de la flecha indica el iniciador de la
interacción.
La relación de uso: Esta relación significa que una instancia del
caso de uso fuente comprende también el
comportamiento descrito por el caso de uso
destino.
La relación de
extensión:
Una relación de extensión entre casos de uso
significa que el caso de uso fuente extiende el
comportamiento del caso de uso destino.
Tabla 2.6: Tipo de relaciones utilizados en los diagramas de casos de uso.
En la figura 2.6, vemos que el actor Estudiante dispara la relación de
comunicación a los casos de uso Consulta, Solicita y Concursa. A su vez, el actor
Visitante dispara el caso de uso Consulta restringida. La relación uso es utilizada
por Consulta, Solicita, Concursa y Consulta restringida para incluir el
comportamiento del caso de uso Identificación en ellos. La relación de extensión
es utilizada para denotar que Consulta es especialización de Consulta restringida.
Reconocimiento
Revisión Bibliográfica
62
Visitante
Estudiante
Figura 2.6: Ejemplo de implementación del diagrama de casos de uso de los
estudiantes del Departamento de Computación.
2.3.2.2 Diagramas de Clases:
Los diagramas de clases expresan de manera general la estructura estática
de un sistema, en términos de clases y de relaciones entre estas clases. Al igual
que una clase describe un conjunto de objetos, una asociación describe un
conjunto de enlaces; los objetos son instancias de clases y los enlaces son
instancias de relaciones. Un diagrama de clases no expresa nada de particular
sobre los enlaces de un objeto dado, pero describe de manera abstracta los
enlaces potenciales de un objeto hacia otros objetos.
Terminología asociada a diagrama de clases:
• Clases: Las clases se representan por rectángulos de compartimientos. El
primer compartimiento contiene el nombre de la clase que debe permitir
<<dispara >>
<<usa>>
<<dispara>>
<<dispara>>
<<dispara>>
<<usa>>
<<usa>>
<<usa>>
<<extiende>>
Consulta restringida
Consulta
Solicita
Concursa
Identificación
Visitante
Estudiante
Reconocimiento
Revisión Bibliográfica
63
comprender lo que es y no lo que hace. Los otros dos compartimientos
contienen, respectivamente, los atributos y las operaciones de la clase.
• Atributos y Operaciones: Los atributos derivados ofrecen una solución
para asignar propiedades a clases, indicando claramente que estas
propiedades son derivadas de otras propiedades ya signadas. Así mismo,
el conjunto de operaciones describe el comportamiento de los objetos de
una clase.
En la figura 2.7 se ilustra la clase Laboratorio de SIDECOM representada
por un rectángulo con las tres divisiones internas que representan el nombre de la
clase, los atributos y las operaciones, respectivamente:
Laboratorionom Lab : varchar(48) = "capacidad : tinyintubicaLab : varcha r(1 28) = "idLab : char(2) = "
crearLaboratorio() : returncrearLaboratorio(char idLab) : returnModificarLaboratorio() : returnCons ultarLaboratorio() : returnElim inarLaboratorio() : returnReportarLaboratorio() : returnLis tarLaboratorio() : returngetnom Lab() : return varcharsetnom Lab()getubicaLab() : return varchars etubicaLab()getcapacidad() : return varchars etcapacidad()getidLab() : return chars etidLab(char idLab)
Figura 2.7: Representación gráfica de la clase Laboratorio de SIDECOM.
• Asociaciones: Las asociaciones especifica una conexión semántica
bidimensional entre tipos y representan relaciones estructurales entre
clases de objetos. Las asociaciones se representan trazando una línea
rectilínea u oblicua entre las clases asociadas. Una asociación posee al
Nombre de la
Atributos
Operacion
Reconocimiento
Revisión Bibliográfica
64
menos dos funciones que describen la parte tomada. Cada función de una
asociación lleva una indicación de multiplicidad que muestra cuántos
objetos de la clase considerada pueden ser relacionados con un objeto de
la otra clase. Los diferentes tipos de multiplicidad se dan en la tabla 2.7:
Tipo de Multiplicidad
Detalles
1 Uno y sólo uno
0..1 Cero o uno
M..N De M a N (enteros
naturales)
* De cero a muchos
0..* De cero a muchos
1..* De uno a muchos
Tabla 2.7: Valores convencionales de multiplicidad.
Los tipos de asociaciones presentes en un diagrama de clase se describen
a continuación en la tabla 2.8:
Tipo de Asociación
Detalles
Asociación binaria: Representa una relación sencilla
entre dos clases y se indica con una línea
sólida que une dos clases.
Asociación n-aria: Es una asociación entre tres o más
clases y se representa por medio de un
diamante.
Composición: Es un asociación fuerte donde el
elemento dependiente desaparecerá al
destruirse el que lo contiene; el objeto
Reconocimiento
Revisión Bibliográfica
65
contenido es parte vital del que lo contiene;
y los objetos contenidos no son
compartidos. Se denota a través de un
rombo relleno del lado de la clase que
contiene a la otra en la relación.
Tipo de Asociación
Detalles
Generalización Esta relación denota una relación
de herencia entre clases y se representa
dibujando un triángulo sin rellenar en el
lado de la superclase.
Refinamiento: Es una relación que representa la
especificación completa de algo que ya ha
sido especificado con un nivel de detalle.
Agregación Representa una asociación no
simétrica en la que uno de los extremos
cumple un papel predominante respecto al
otro extremo. Se representa añadiendo un
pequeño rombo al lado del agregado
Tabla 2.8: Tipos de asociaciones usados en los diagramas de casos de
uso.
En la figura 2.8 se puede observar el diagrama de clases para el proceso de
solicitar y prestar equipo que pertenece al departamento y que es gestionado por
un estudiante en particular.
Reconocimiento
Revisión Bibliográfica
66
Figura 2.8: Diagrama de clase para el proceso de solicitar y prestar
Equipo de SIDECOM.
2.4 BASES DE DATOS:
Una base de datos (BD) es un conjunto de datos relacionados entre sí. Por
datos entendemos hechos conocidos que pueden registrarse y que tienen un
significado implícito [Navathe97].
Las bases de datos representan algún aspecto del mundo real, por lo tanto,
las modificaciones hechas en ellas se reflejan directamente en los datos. Toda BD
se diseña, construye y puebla con datos para un propósito específico al estar
dirigida a un grupo particular de usuarios. Se dice entonces, que definir una BD
consiste en especificar los tipos de datos, las estructuras y las restricciones de los
datos que se almacenarán en ella; construir una BD es el proceso de guardar los
datos mismos en algún medio de almacenamiento controlado por un sistema de
gestión de base de datos.
Las bases de datos computarizadas se pueden crear y mantener con un
grupo de programas de aplicación escritos específicamente para esta tarea, o bien
mediante un sistema de gestión de bases de datos.
Persona
<<Profesor>> Profesor
Secretaria
<<Asociación>> Presta
Equipo
+solicita
+solicitadoPor
1..1
0..*
+recibe
+recibido
0..*
1..1
recibe
+autorizadoPor +autoriza autoriza
0..* 1..1
Reconocimiento
Revisión Bibliográfica
67
2.4.1 Sistema de Gestión de Bases de Datos:
Un sistema de gestión de bases de datos (SGBD) es un conjunto de
programas que permite a los usuarios crear y mantener una base de datos. Los
SGBD facilitan el proceso de definir, construir y manipular base de datos para
diversas aplicaciones [Navathe97].
Al conjunto formado por la base de datos y el software de SGBD de
propósito específico lo se le llama sistema de base de datos (ver figura 2.9). Estos
sistemas de base de datos son utilizados por múltiples usuarios que necesitan el
valor actual de los datos y que permanentemente actualizan la BD. El tiempo de
respuesta debe ser obligatoriamente rápido y el alcance de información debe ser
infinito, para una cantidad promedio de 10 registros individuales accedidos
[Orfali98].
Programas de aplicación / consultas
Software para procesarconsultas / programas
Software para tener acceso
a los datos almacenados
Definición de la base de datos almacenada (metadatos)
Base de datos
almacenada
SISTEMA DE
BASE DE DATOS
SOFTWARE
DEL SGBD
Usuarios / Programadores
Reconocimiento
Revisión Bibliográfica
68
Figura 2.9: Entorno simplificado de un sistema de base de datos
Resumimos en la tabla 2.9 algunas de las características con que se
distingue el enfoque de bases de datos, además de los recursos de ayuda3 que un
software de SGBD debe ofrecer al diseñador y a los usuarios, así como algunas
ventajas adicionales que ofrece un sistema de BD y que no tienen los sistemas
tradicionales de procesamiento de archivos:
Enfoque de Base de Datos
Características Recursos de Ayuda Ventajas Adicionales
Existencia de un catálogo o diccionario
de datos
Control de redundancia, respaldo y recuperación
Potencial para imponer normas
Abstracción de los datos Restricción de accesos no autorizados
Flexibilidad
Independencia con respecto a programas y datos, y con respecto a
programas y operaciones
Almacenamiento persistente para
estructuras de datos de programas
Más rapidez para crear aplicaciones
Manejo de múltiples vistas de usuario
Inferencias que permiten generar las reglas de
deducción
Disponibilidad de información
actualizada pata todos los usuarios
Compartimiento de datos entre varias
transacciones
Múltiples interfaces Economías de escala.
Imposición de restricciones de
integridad
Tabla 2.9: Característica, recursos de ayuda y ventajas del Enfoque
de Base de Datos.
3 El SGBD debe ofrecer recursos de ayuda que permitan administrar, diseñar y utilizar una base de datos.
Reconocimiento
Revisión Bibliográfica
69
2.4.2 Clasificación de los Sistemas de Gestión de Bases de Datos:
El principal criterio que suele utilizarse para clasificar los SGBD es el
modelo de datos4 en que se basan. Los modelos de datos empleados con mayor
frecuencia en los SGBD comerciales son el relacional, el de red y el jerárquico, y
algunos SGBD se basan en modelos orientado a objetos o conceptuales
[Navathe97].
La tabla 2.10 presenta un resumen de la clasificación de los modelos de
SGBD5, algunas características y las aplicaciones de esos modelos:
Modelos de SGBD Características
Modelo Relacional: • Representa una BD como una colección de tablas, cada una
de las cuales se pueden almacenar en forma de archivos.
• Por lo general, poseen lenguajes de consulta de alto nivel y
manejan una forma limitada de vistas para el usuario.
Modelo de Datos de
Red: • Representa los datos como tipos de registros y un tipo
limitado de vínculos 1:N, llamado tipo de conjunto.
• Poseen un lenguaje de registro por registro asociado que se
debe incorporar en un lenguaje de programación anfitrión.
Modelo Jerárquico: • Representa los datos como estructuras jerárquicas de árbol.
• Cada jerarquía representa varios registros relacionados.
• No existe ningún lenguaje estándar para este modelo, aunque
la mayor parte de los SGBD jerárquicos cuentan con
lenguajes de registros por registro.
Modelo Orientado a
Objetos: • Define una base de datos en términos de objetos, sus
propiedades y sus operaciones.
• Los objetos con la misma estructura y comportamiento
pertenecen a una clase, que a su vez se organizan en
jerarquías.
4 Un modelo de datos es un conjunto de conceptos que pueden servir para describir la estructura de un base de datos. 5 En [Navathe97] se definen ampliamente los modelos de SGBD en los capítulos 6 al 12 y 22,.
Reconocimiento
Revisión Bibliográfica
70
• Las operaciones de cada clase se especifican en términos de
procedimientos denominados métodos.
• Los SGBD relacionales han estado extendiendo sus modelos
para incorporar conceptos orientados a objetos y otras
capacidades conocidos como sistemas relacionales
extendidos.
Tabla 2.10: Modelos de SGBD y sus características.
2.4.3 SQL: Un Lenguaje de Bases de Datos Relacionales:
Uno de los mejores lenguajes disponibles en SGBD comerciales es el SQL,
cuyo nombre se deriva de Structured Query Language (lenguaje estructurado de
consulta). Oracle Corporation fue la primera compañía en ofrecer una versión
comercial de SQL, su base de datos Oracle, en 1979. IBM presentó sus propios
productos de SQL a principios de los años ochenta: SQL/DS y DB2. Hoy en día,
SQL se ha convertido en el lenguaje de bases de datos predominante en
macrocomputadoras, minicomputadoras y servidores de LAN [Orfali98].
SQL es un lenguaje completo de bases de datos basados en el álgebra
relacional6; cuenta con enunciados de definición, consulta y actualización de
datos. Por añadidura, cuenta con mecanismos para definir vistas de la BD, crear y
desechar índices de archivos y para incorporar enunciados de SQL en lenguajes
de programación y facilita la especificación precisa de requerimientos de
productos [Navathe97].
2.5 LENGUAJE DE PROGRAMACIÓN JAVA: 6 El álgebra relacional es una colección de operaciones que sirven para manipular relaciones enteras [Navathe97].
Reconocimiento
Revisión Bibliográfica
71
En las siguientes secciones haremos una breve reseña del origen de este
lenguaje, sus características principales y algunas de las aplicaciones más
comunes de la programación en Java.
2.5.1 Origen del Lenguaje Java:
Java fue un proyecto que rebotó durante mucho tiempo por distintos
departamentos de la Sun Microsystems sin que nadie le prestara ninguna
atención, hasta que finalmente encontró su nicho de mercado en la aldea global,
Internet [Int-2].
Hace algunos años, Sun decidió introducirse en el mercado de la
electrónica de consumo y desarrollar programas para pequeños dispositivos
electrónicos. Sun creó una filial, denominada FirstPerson Inc., que se iniciaron en
el mercado previstos de equipos domésticos programados: microondas,
tostadoras y, fundamentalmente, televisión interactiva. Dada la falta de pericia de
los usuarios para el manejo de estos dispositivos, se requería de unas interfaces
mucho más cómodas e intuitivas que los sistemas de ventanas que proliferaban
en el momento.
James Gosling, el miembro del equipo con más experiencia en lenguajes de
programación, decidió que las ventajas aportadas por la eficiencia de C++ no
compensaban el gran costo de pruebas y depuración. Gosling había estado
trabajando en un lenguaje de programación que él había llamado Oak, el cual,
intentaba remediar las deficiencias que iba observando.
El primer proyecto en que se aplicó este lenguaje recibió el nombre de
proyecto Green y consistía de una interfaz animada cuyo control se llevaba a cabo
mediante una pantalla sensible al tacto. Este proyecto nunca se convirtió en un
sistema comercial, pero fueron desarrollados enteramente en un Java primitivo.
Reconocimiento
Revisión Bibliográfica
72
Pese a lo que parecía ya un olvido definitivo, Bill Joy, cofundador de Sun y
uno de los desarrolladores principales del Unix de Berkeley, juzgó que Internet
podría llegar a ser el campo de juego adecuado para disputar a Microsoft su
primacía casi absoluta en el terreno del software, y vio en Oak el instrumento
idóneo para llevar a cabo estos planes. Tras un cambio de nombre y
modificaciones de diseño, el lenguaje Java fue presentado en sociedad en agosto
de 1995.
2.5.2 Características de Java:
Las características principales que nos ofrece Java respecto a cualquier
otro lenguaje de programación, son las siguientes [Naughton, 96]:
1. Simplicidad:
Java ofrece toda la funcionalidad de un lenguaje potente, pero sin las
características menos usadas y más confusas de éstos. C y C++ son lenguajes
que adolecen de falta de seguridad, pero no por esto menos difundidos; por ello,
Java implementó la tecnología básica de C++ con algunas mejoras y eliminó un
50% de los errores más comunes de éste lenguaje de programación para
mantener el objetivo de la simplicidad del lenguaje y así facilitar un rápido y fácil
aprendizaje. Entre las características de C y C++ eliminadas encontramos las
siguientes:
• aritmética de punteros,
• no existen referencias,
• registros (struct),
• definición de tipos (typedef),
• necesidad de liberar memoria (free).
2. Orientado a objetos:
Reconocimiento
Revisión Bibliográfica
73
Java trabaja con sus datos como objetos y con interfaces a esos objetos.
Soporta las tres características propias del paradigma de la orientación a objetos:
encapsulamiento, herencia y polimorfismo7. Las plantillas de objetos son llamadas,
como en C++, clases y sus copias, instancias. Estas instancias, como en C++,
necesitan ser construidas y destruidas en espacios de memoria.
3. Distribuido:
Java se ha construido con extensas capacidades de interconexión TCP/IP.
Existen librerías de rutinas para acceder e interactuar con protocolos como http y
ftp. Esto permite a los programadores acceder a la información a través de la red
con tanta facilidad como a los ficheros locales. Realmente Java no es distribuido,
sino que proporciona las librerías y herramientas para que los programas puedan
ser distribuidos; se corren en varias máquinas, interactuando.
4. Robusto:
Java realiza verificaciones en busca de problemas tanto en tiempo de
compilación como en tiempo de ejecución. La comprobación de tipos de datos en
Java ayuda a detectar errores, lo antes posible, en el ciclo de desarrollo. Java
obliga a la declaración explícita de métodos, reduciendo así las posibilidades de
error. Estas características reducen drásticamente el tiempo de desarrollo de
aplicaciones en Java.
Java proporciona, pues, comprobación de punteros, comprobación de
límites de arrays (vectores), excepciones y verificación de byte-codes (códigos de
bytes).
7 Consultar la sección 2.2.2: Características de la Programación OO
Reconocimiento
Revisión Bibliográfica
74
5. Arquitectura neutral:
Para establecer Java como parte integral de la red, el compilador Java
compila su código a un fichero objeto de formato independiente de la arquitectura
de la máquina en que se ejecutará. Cualquier máquina que tenga el sistema de
ejecución (run-time) puede ejecutar ese código objeto, sin importar en modo
alguno la máquina en que ha sido generado.
6. Seguridad:
El código Java pasa muchas pruebas antes de ejecutarse en una máquina.
El código se pasa a través de un verificador de byte-codes que comprueba el
formato del código y detecta fragmentos de código ilegal8. Si los byte-codes pasan
la verificación sin generar ningún mensaje de error, entonces sabemos que:
• El código no produce desbordamiento de operandos en la pila.
• El tipo de los parámetros de todos los códigos de operación son conocidos.
• El acceso a los campos de un objeto se sabe que es legal: public, private,
protected.
• No hay ningún intento de violar las reglas de acceso y seguridad
establecidas.
Respecto a la seguridad del código fuente, no ya del lenguaje, JDK9
proporciona un desemsamblador de byte-code, que permite que cualquier
programa pueda ser convertido a código fuente, lo que para el programador
significa una vulnerabilidad total a su código.
Decimos entonces que las aplicaciones de Java resultan extremadamente
seguras, ya que no acceden a zonas delicadas de memoria o del sistema, con lo
8 Código ilegal: Código que viola derechos de acceso sobre objetos o intenta cambiar el tipo de un objeto. 9 JDK: Java Development Kit (herramienta de desarrollo de Java).
Reconocimiento
Revisión Bibliográfica
75
cual evitan la interacción de ciertos virus. Además, para evitar modificaciones por
parte de los crackers10 de la red, implementa un método ultraseguro de
autentificación por clave pública. El Cargador de Clases puede verificar una firma
digital antes de realizar una instancia de un objeto. Por lo tanto, ningún objeto se
crea y almacena en memoria, sin que se validen los privilegios de acceso. Es
decir, la seguridad se integra en el momento de compilación, con el nivel de
detalle y de privilegio que sea necesario.
7. Portable:
Más allá de la portabilidad básica por ser de arquitectura independiente,
Java implementa otros estándares de portabilidad para facilitar el desarrollo. Los
enteros son siempre enteros y además, enteros de 32 bits en complemento 2.
Además, Java construye sus interfaces de usuario a través de un sistema
abstracto de ventanas de forma que las ventanas puedan ser implantadas en
entornos Unix, Pc o Mac.
8. Es interpretado:
El intérprete Java (sistema run-time) puede ejecutar directamente el código
objeto. Enlazar un programa, normalmente, consume menos recursos que
compilarlo, por lo que los desarrolladores con Java pasarán más tiempo
desarrollando y menos esperando por el ordenador.
No obstante, el compilador actual JDK de Java es bastante lento. Se dice
que Java es de 10 a 30 veces más lento que C++, ya que debe ser interpretado y
no ejecutado como sucede en cualquier programa tradicional.
10 Crackers: códigos ilegales.
Reconocimiento
Revisión Bibliográfica
76
9. Multithreaded:
Al ser multithreaded (multihilvanado), Java permite muchas actividades
simultáneas en un programa. Los threads (llamados procesos ligeros), son
básicamente pequeños procesos o piezas independientes de un gran proceso. Al
estar los threads construidos en el lenguaje, son más fáciles de usar y más
robustos que sus homólogos en C o C++.
El beneficio de ser miltithreaded consiste en un mejor rendimiento
interactivo y mejor comportamiento en tiempo real. Aunque el comportamiento en
tiempo real está limitado a las capacidades del sistema operativo subyacente
(Unix, Windows, etc.), aún supera a los entornos de flujo único de programa
(single-threaded) tanto en facilidad de desarrollo como en rendimiento. Por
ejemplo, en Java, las imágenes se pueden ir trayendo en un thread independiente,
permitiendo que el usuario pueda acceder a la información en la página sin tener
que esperar por el navegador.
10. Dinámico:
Java se beneficia todo lo posible de la tecnología orientada a objetos. Java
no intenta conectar todos los módulos que comprenden una aplicación hasta el
tiempo de ejecución. Las librerías nuevas o actualizadas no paralizarán las
aplicaciones actuales.
Java también simplifica el uso de protocolos nuevos o actualizados. Si su
sistema ejecuta una aplicación Java sobre la red y encuentra una pieza de la
aplicación que no sabe manejar, Java es capaz de traer automáticamente
Reconocimiento
Revisión Bibliográfica
77
cualquiera de esas piezas que el sistema necesita para funcionar, como se
describe en el diagrama de la figura 2.10.
Java, para evitar que los módulos de byte-codes, los objetos o nuevas
clases, haya que estar trayéndolos de la red cada vez que se necesiten,
implementa las opciones de persistencia, para que no se eliminen cuando de
limpie la caché de la máquina.
Figura 2.10: Esquema de solicitud en Java de tipos de objetos.
2.5.3 Aplicaciones en Java:
Durante años, las grandes empresas se han convencido de que la "red"
corporativa es la arteria por donde fluye la sangre que mantiene vivo su negocio.
Para muchas compañías, la Red es la Empresa y la necesidad de diagnosticar y
reducir los problemas originados en ella hace que se estén inyectando
continuamente nuevas metodologías que subsanen este grave problema.
Al ser un lenguaje más simple que cualquiera de los lenguajes que
actualmente se aplican, Java permite a los programadores concentrarse en la
mecánica de la aplicación, en vez de pasarse horas y horas controlando la
Reconocimiento
Revisión Bibliográfica
78
memoria, sincronizando los ficheros de cabecera y corrigiendo los mensajes del
linker. Java tiene su propio toolkit para interfaces, maneja por sí mismo la memoria
que utilice la aplicación, no permite ficheros de cabecera separados y solamente
usa enlace dinámico.
El lenguaje Java y los navegadores con soporte Java, proporcionan una
forma diferente de hacer que ese navegador sea capaz de ejecutar programas.
Con Java se puede reproducir sonido desde el navegador, visitar home pages con
animaciones, manejar nuevos formatos de ficheros, e incluso, transmitir video por
las líneas telefónicas. Además, Java permite realizar tanto aplicaciones locales
como aplicaciones Web utilizando los Applets, que son pequeñas porciones de
código con capacidad de funcionamiento en red a las que hacen referencia los
documentos HTML, visualizados por navegadores Web con capacidad de manejo
Java. Así mismo, con Java se puede estar seguro de que el código que intente
actuar destructivamente o que contenga errores, no podrá traspasar los muros
defensivos colocados por las características de seguridad y robustez de Java.
En una empresa de relativo tamaño hay una pléyade diferente de
ordenadores. Probablemente se encuentren estaciones de trabajo Sun para el
desarrollo de software, PCs para cada empleado, algún Mac en el departamento
de documentación y una estación de trabajo HP en administración. Desarrollar
aplicaciones corporativas para un grupo tan diferente de plataformas en
excesivamente complejo y caro. Con un entorno run-time de Java portado a cada
una de las arquitecturas de las plataformas presentes en la empresa y una buena
librería de clases ("packages" en Java), los programadores pueden entenderse y
encontrar muy interesante trabajar con Java. Una vez que los programas estén
escritos en Java, es importante que los programas también sean portables. El
grupo de programadores de la empresa puede ahora enfrentarse a un desarrollo
para cualquiera de las plataformas. La parte del cliente y del servidor de una
aplicación estarán ahora escritas en el mismo lenguaje.
Reconocimiento
Revisión Bibliográfica
79
Con relación a los costos, en contraste con los desarrollos realizados sobre
estaciones de trabajo, el costo de creación de una aplicación Java es similar al de
desarrollar sobre un PC.
Desarrollar utilizando un software caro para una estación de trabajo es un
problema en muchas empresas; por ejemplo, el costo del entorno de desarrollo
con C++ es prohibitivo para la gran mayoría de ellas. La llegada de Java e Intranet
reducen considerablemente estos costos. Las herramientas Java ya no están en el
entorno de precios de los millones, sino a los niveles confortables de precio de las
herramientas de PCs. Esta es la filosofía de precios que parece ser la que se siga
con las herramientas basadas en Java convirtiendo el éxito de los softwares
corporativos en un regalo.
2.5.4 Diferencias entre Applets y Aplicaciones Independientes:
Pese a que a primera vista applets y aplicaciones parecen la misma cosa,
más que hablar de diferencias se puede hablar de lo que se parecen: en que
ambas se escriben en el mismo lenguaje. Los applets no son programas
independientes, sino que precisan de otro para ejecutarse. Por esto, debe
emplearse una aplicación, escrita en Java o no, que lo ejecute. En realidad, puesto
que los applets se incrustan en una página HTML de un modo muy similar al que
se usaría para incrustar una imagen, lo que se necesita adicionalmente es un
browser. Los browsers o navegadores son aplicaciones que cargan una página
HTML con un applet incrustado y pueden ejecutarlo porque disponen de una
Máquina Virtual Java.
En cambio, las aplicaciones sólo necesitan la Máquina Virtual Java
específica para cada sistema operativo, instalada en el equipo en el que vayan a
Reconocimiento
Revisión Bibliográfica
80
ejecutarse. Esta diferencia no es trivial, y la posibilidad que tienen los applets de
cargarse y ejecutarse en equipos remotos a través de la Internet, ha llevado a
someterlos a grandes restricciones, de manera que se minimice el riesgo de daños
para el equipo en que se cargan. No es atractivo para nadie, que en una sesión en
Internet, al ver una página, se cargue un programa que comience a trastear por el
disco duro del equipo o a curiosear información que no le atañe.
Así pues, la razón básica de que los applets estén limitados se debe a la
seguridad que en todo momento debe correr la persona que se conecta a Internet
y carga en su ordenador “algo” sobre cuya procedencia y fines lo ignora todo. De
aquí que en los applets no basten las limitaciones que tiene de por sí el lenguaje
Java (niveles de lenguaje, de verificación de los bytecodes, del cargador de clases
y de la API 11de Java), sino que además no pueden realizarse lo siguiente:
• Establecer conexiones de red, salvo con el ordenador del que provienen.
• Sólo pueden leer una parte de las propiedades del sistema en el que se
ejecutan.
• Aunque puedan leer y escribir en archivos, ciertos browsers –entre ellos
Netscape Navigator- no lo permiten.
• No pueden ordenar la ejecución de una aplicación en el ordenador local.
Todo esto implica que las bases de datos a las que se accede desde
applets deben encontrarse, bien el ordenador local o bien en el servidor desde el
que se ha cargado el applet. Como consecuencia, el servidor de bases de datos
habrá de ser también un servidor Web12.
Otro aspecto, al que no pudiera llamarse limitación, es que no pueden
cargar código que no esté escrito en Java. Las implicaciones de esto en las bases
11 API: Application Programming Interface 12 Consultar la sección 2.1.2.3: Sistemas Cliente/Servidor
Reconocimiento
Revisión Bibliográfica
81
de datos son bastantes relevantes: puesto que algunos controladores JDBC13
requieren bibliotecas escritas en el código máquina del sistema concreto, puede
ser una restricción importante. Aparte, como se les impide escribir en el sistema
de archivo local, algunos sistemas no funcionarán desde una applet. Esto lleva
casi siempre, ya que no existen por ahora muchos controladores JDBC escritos
100% en Java, a consultar la información que se encuentra en el servidor en lugar
de una base de datos local [Wehling, 98].
2.5.5 AWT (Abstract Window Toolkit):
AWT (Abstract Window Toolkit) de Java, se basa en una biblioteca de
clases Java para el desarrollo de Interfaces de Usuario Gráficas (GUI). La versión
comercial del AWT se desarrolló en sólo dos meses, y aún así, posee ventajas
definitivas que permiten obtener una GUI limpia y bastante sencilla,
tradicionalmente independiente de la plataforma.
La estructura básica del AWT consta de una GUI exportable para la
generación de aplicaciones trasladables de un sistema de ventanas a otro.
Contiene clases para elementos básicos de interfaz de usuario, como eventos,
accesorios y contenedores de marcos. Estos últimos contienen componentes
posicionados a su respecto y son componentes a su vez, de forma que los
eventos pueden tratarse tanto en contenedores como en componentes, corriendo
por cuenta del programador el encaje de todas las piezas, así como la seguridad
de tratamiento de los eventos adecuados.
La estructura de la versión actual del AWT se puede resumir en los puntos
que se exponen a continuación:
• Los contenedores contienen componentes, que son los controles básicos.
13 Consultar la sección 2.6.2: Conectividad de Base de Datos de Java (JDBC)
Reconocimiento
Revisión Bibliográfica
82
• No se usan posiciones fijas de los componentes, sino que están situados a
través de una disposición controlada (layouts).
• Alto nivel de abstracción respecto al entorno en que se ejecute la
aplicación.
• La arquitectura de la aplicación es dependiente del entorno de ventanas, en
vez de tener un tamaño fijo.
• Es dependiente de la máquina en que se ejecuta la aplicación.
2.6 CONTROLADORES ODBC – JDBC: 2.6.1 Conectividad Abierta de Bases de Datos (ODBC):
ODBC es la interfaz estratégica de Microsoft por acceder a los datos en un
ambiente heterogéneo de sistemas de gestión de bases de datos relacionales y no
relacionales [Mattison98]. Es una de las interfaces más populares en el mundo de
las PC y poco a poco se está extendiendo a otras plataformas. ODBC ofrece
funciones para interactuar con bases de datos desde un lenguaje de
programación, entre las que figuran la incorporación, modificación y eliminación de
datos, hasta la obtención de los detalles sobre las bases de datos, tablas, visores
e índices [Wehling98].
Una aplicación ODBC posee cinco etapas lógicas: aplicación, interfaz ODBC,
administrador de controladores, controlador y origen de datos, como vemos en la
tabla 2.11:
Comentario [MP1]: no entiede la profesora(corregirlo)
Reconocimiento
Revisión Bibliográfica
83
Etapas Lógicas del ODBC Definición
La capa de aplicación: Proporciona la lógica de la aplicación y se escribe en
lenguajes como Java, Visual Basic o C++. La aplicación
utiliza las funciones ODBC para interactuar con la BD..
La capa Interfaz: Proporciona la GUI (Interfaz Gráfica del Usuario) de la
aplicación. Cuenta con un conjunto de llamadas, como
son las instrucciones SQL e información sobre la BD.
La capa del administrador de
controladores: Administra diversos controladores existentes en el
sistema, proporcionando información del controlador a la
aplicación cuando se requiera. Además, se asegura de que
el sistema administrador de base de datos correcto
obtenga todas las llamadas de programa dirigidas a él y
que en el origen de datos se enrute una llamada de CLI
(interfaces de nivel de llamada) a la aplicación.
Etapas Lógicas del ODBC Definición
El controlador: Es el componente real que tiene el conocimiento acerca
de las BD específicas. Así mismo, el controlador es
responsable de implementar el conjunto de llamadas de
la interfaz ODB emulando las funciones que no son
manejadas por el SGBD. El controlador realiza el trabajo
de enviar consultas a la BD, obteniendo los datos de
vuelta y enrutándolos a la aplicación.
El origen de datos: Puede ser un sistema administrador de BD, o simplemente
un almacén de datos, que es por lo regular un conjunto de
archivos que están en el disco duro.
Tabla 2.11 Etapas Lógicas del ODBC.
Reconocimiento
Revisión Bibliográfica
84
2.6.2 Conectividad de Base de Datos de Java (JDBC):
En marzo de 1996, La compañía Sun Microsystems publicó la
especificación inicial para la conexión de base de datos de Java (JDBC: Java
Database Connection), desarrollado conjuntamente con Oracle, Sybase, Informix y
otras compañías especialistas en BD. JDBC es un conjunto de clases de Java que
ofrece una interfaz semejante a ODBC para los SGBD cuyo lenguaje base es el
SQL [Harkey97].
JDBC define un conjunto de objetos y métodos API para interactuar con la
base de datos subyacente. Un programa Java primero abre una conexión con una
base de datos, crea un objeto de instrucción, pasa instrucciones SQL al SGBD
subyacente a través del objeto de instrucción y recupera los resultados así como
la información sobre el conjunto de resultados. El SGBD y el origen de datos se
ubican por lo regular en un servidor remoto.
El applet/aplicación y las capas JDBC se comunican en el sistema cliente y
el controlador se hace cargo de interactuar con la base de datos a través de la red.
El controlador JDBC puede ser una biblioteca nativa o una clase Java, que se
comunica a través de la red con un proceso RPC o http en el servidor de base de
datos. Así pues, un programa que utilice JDBC necesitará un controlador para el
origen de datos con el que desee interactuar.
Los controladores JDBC se pueden clasificar en cuatro categorías:
a) Puente JDBC - ODBC:
El puente ODBC es una delgada capa sobre JDBC que transforma métodos
JDBC a llamadas ODBC e interactúa con cualquier controlador ODBC disponible.
Las llamadas JDBC son convertidas a llamadas ODBC y posteriormente realiza la
conversión de resultados. La ventaja de este puente consiste en que ahora JDBC
Reconocimiento
Revisión Bibliográfica
85
tiene la capacidad para acceder a casi todas las bases de datos, ya que los
controladores ODBC están disponibles ampliamente.
La figura 2.11 señala la conexión entre ellos por medio de un esquema:
Figura 2.11: Esquema del Puente JDBC-ODBC.
b) JDBC Parcialmente Nativo:
Esta estructura presenta un driver 100% Java que se comunica con la
librería nativa del fabricante del motor de base de datos, como se ilustra en la
figura 2.12:
Figura 2.12: Esquema JDBC Java/Protocolo Nativo.
c) JDBC Net de Java Puro:
Este driver puede comunicarse con la base de datos sin necesidad de
ningún servicio intermedio y todas las peticiones se convertirán en peticiones de
red del servidor de base de datos, según lo mostrado en la figura 2.13:
Figura 2.13: Esquema JDBC Net Puro.
Aplicación Java
Base de Datos
JDBC Puente ODBC Driver ODBC
Protocolo Nativo
p
Base de Datos JDBC Controlador Parcialmente Nativo
Aplicación Java
Controlador de Red 100% Java
Protocolo de Red
Base de Datos
Reconocimiento
Revisión Bibliográfica
86
d) JDBC de Protocolo Nativo de Java Puro: Representa la mejor opción de conectividad JDBC por su flexibilidad. Se tiene un
driver 100% Java que se comunica con un sistema intermedio, que debe
encontrarse junto al servidor de base de datos y que es capaz de traducir nuevas
órdenes a órdenes nativas del servidor. Esta es la opción recomendada para los
proyectos grandes, ya que facilita la distribución de aplicaciones en servidores de
bases de datos y es a su vez, la solución más sencilla al tener que configurarse
solamente el servidor y no los clientes [Fnl, 98]. Esto se ilustra en la figura 2.14:
Figura 2.14: Esquema JDBC 100% Java
Otro aspecto relevante es la seguridad involucrada en la conexión de
aplicaciones con bases de datos. JDBC sigue el modelo estándar de seguridad, en
el que los applets sólo pueden conectarse al servidor desde el cual se carga; los
applets remotos no pueden conectarse a bases de datos locales. Las aplicaciones
no tienen restricciones de conexión. Para los controladores Java puros, la
verificación de seguridad es automática, pero en el caso de los controladores
desarrollados en métodos nativos, son necesarias algunas verificaciones de
seguridad.
En este capítulo se describieron las bases teóricas fundamentales que
serán utilizadas a lo largo del desarrollo de este proyecto y que permitirán lograr
un mejor entendimiento de los siguientes capítulos.
Aplicación Java
JDBC Controlador 100% Java
Base de Datos
Reconocimiento
Revisión Bibliográfica
87
CAPÍTULO 3: ANÁLISIS Y DISEÑO DEL SISTEMA
La creciente demanda del desarrollo de aplicaciones informáticas en la actualidad,
unido con la necesidad de conservar y mantener éstas aplicaciones, hace cada
vez más provechoso la utilización de novedosas tecnologías para el desarrollo de
sistemas, basadas fundamentalmente, en metodologías orientadas a objetos al
proveer ventajas importantes, como las siguientes:
el desarrollo de modelos mucho más próximos al mundo real, con lo que aumenta
las posibilidades de la reutilización,
la consistencia de los modelos debido al encapsulamiento de los atributos y
operaciones de los objetos,
la utilización de la herencia para expresar explícitamente las características
comunes de una serie de objetos.
Así pues, este capítulo describe la metodología y las herramientas utilizadas que
permitieron analizar y diseñar el sistema de información planteado mediante un
enfoque orientado a objetos; entre ellas tenemos: la metodología para el desarrollo
de sistemas de información MEDIS-OO [Mon97b, Mon97d], el lenguaje de
modelado unificado UML y el modelo para aplicaciones cliente/servidor.
La metodología MEDIS-OO (Metodología Orientada por Objetos para el Desarrollo
de Sistemas de Información) fue desarrollada por Jonas A. Montilva de la
Universidad de Los Andes. Este método describe los pasos necesarios para
especificar los requerimientos, diseñar bases de datos, implementar y probar un
Sistema de Información orientado a objetos y está dividida en fases, que se
cumplen mediante la ejecución de diferentes procedimientos, estructurando así, el
diseño de un SI. La Tabla 3.1 representa brevemente ésta metodología:
Reconocimiento
Revisión Bibliográfica
88
Fase # Fases Procedimientos Herramienta Utilizada 1 Análisis del
sistema de
actividades
1. Definir el sistema organizacional de
actividades.
2. Modelar los procesos.
3. Identificar los tipos de entidades del
sistema.
3. Identificar los actores.
4. Identificar los principales eventos.
Diagrama Funcional
Jerárquico
UML: Diagrama de Casos
de Uso
2 Especificación
de
requerimientos
1. Requerimientos de interacción.
2. Requerimientos de entrada de datos.
3. Requerimientos de salida de datos.
4. Requerimientos funcionales.
5. Requerimientos de almacenamiento.
6. 0Requerimientos de operación y configu-
ración.
UML: Diagrama de Casos
de Uso
3 Diseño
preliminar del
sistema
1. Diseño de la arquitectura del sistema de
información.
2. Diseño conceptual de la base de datos:
a) Diseño de esquemas parciales.
b) Integración de esquemas parciales.
3. Diseño de la interfaz Usuario / sistema.
Modelo para Aplicaciones
Cliente/Servidor
UML: Diagrama de Clases
UML: Diagrama de Clases
VisualAge 3.02 -
4 Diseño
implementable
del sistema
1. Diseño implementable de la base de
datos: Convertir el esquema conceptual
integrado a un esquema implementable
(relacional).
2. Diseño de programas.
Modelado Relacional
PowerDesigner 8.0
Diagrama de Módulos.
5 Implementación 1. Implementación de la base de datos.
2. Codificación de programas.
Sybase Anywhere 7.0
VisualAge 3.02
6 Verificación y
validación del
sistema
1. Pruebas funcionales
2. Pruebas de rendimiento
3. Validación con el usuario.
Criterio Caja Blanca.
Tabla 3.1: Esquema de la metodología MEDIS-OO y las
herramientas utilizadas para su desarrollo.
Reconocimiento
Revisión Bibliográfica
89
En la fase 1 se analiza el sistema de actividades en estudio y se elabora un
modelo funcional que facilite en la fase siguiente, la especificación de los
requerimientos que deberá satisfacer el sistema de información. Modelando los
procesos se capturan y representan los componentes del sistema: objetivos,
entidades, actores y eventos.
En la fase 2 tiene por objetivo identificar y documentar los servicios que el sistema
de información deberá proporcionar a los usuarios. Los requerimientos especifican
lo que el SI debe hacer y no cómo hacerlo. Entre los requerimientos que se
especifican en esta fase tenemos: requerimientos de interfaz de usuario-sistema,
requerimientos de procesamiento, requerimientos de operación y configuración.
En la fase 3 se diseña el esquema conceptual de la base de datos, el cual está
compuesto por un conjunto de entidades que se relacionan entre sí y que pueden
ser utilizadas por diferentes usuarios en dos o más procesos, por lo tanto, es
conveniente construir un esquema por cada proceso y luego integrar cada uno de
ellos para así formar el esquema integrado o conceptual de la base de datos, el
cual debe ser verificado al determinar si el esquema contiene todos los datos
necesarios para producir cada requerimiento de información especificado en la
fase 2.
La fase 4 consiste en convertir el esquema global obtenido en la fase 3, a un
esquema implementable que pueda ser utilizado por el SMBD elegido14 para su
implementación. En esta fase también se diseñan los procedimientos y programas
que satisfarán los requerimientos especificados en la fase 2.
En la fase 5 se lleva a cabo la implementación del sistema en la herramienta de
programación elegida y se traslada el diseño de la base de datos obtenido en la
14 Consultar la sección 2.4.2: Clasificación de los Sistemas de Gestión de Bases de Datos (capítulo 2)
Reconocimiento
Revisión Bibliográfica
90
fase anterior al computador por medio del manejador de bases de datos. Esta fase
se desarrolla en el capítulo 4.
Finalmente, se realiza la verificación y validación del sistema aplicando diferentes
pruebas al mismo, para encontrar las discrepancias que puedan existir ente el
sistema de información construido y los objetivos, requerimientos y restricciones
previamente establecidos. El capítulo 5 describe el desarrollo de esta fase.
3.1 ANÁLISIS DEL SISTEMA DE ACTIVIDADES:
En esta sección se obtiene información detallada sobre del sistema de actividades
organizacional del sistema global en estudio, dado que se requiere la
construcción, en forma concisa y precisa, de un modelo abstracto de la situación
real, que refleje lo que se desea hacer y no de cómo debe hacerse.
3.1.1 Definición del Sistema de Actividades:
El sistema de actividades en estudio está orientado a los procesos que el
Departamento de Computación lleva a cabo. Este departamento fue creado en
1975 y está adscrito a la Escuela de Sistema de la Universidad de Los Andes, y
desde entonces, persigue el cumplimiento de las siguientes actividades:
• Apoyar el fortalecimiento de la investigación y la docencia en computación
de los estudiantes de la carrera de Ingeniería de Sistemas, mediante la
contribución fundamental y conducción de las asignaturas asignadas al
departamento.
• Formar ingenieros de sistemas capaces de usar métodos informáticos que
les permitan una actuación creativa y participativa dentro de las
organizaciones.
Reconocimiento
Revisión Bibliográfica
91
• Planificar y coordinar actividades administrativas, académicas y de
investigación de profesores y estudiantes del departamento que faciliten el
logro de los objetivos y metas planteados.
• Evaluar la efectividad de los programas de estudio de asignatura teóricas y
prácticas del área de la computación de acuerdo a programas en operación
y las necesidades actuales y futuras del campo.
• Ejercer función controladora de los siguientes procesos:
o El manejo de recursos humanos. Consiste un llevar en registro
de los datos personales y curriculares de profesores,
preparadores, beca trabajos y pasantes externos del
departamento, así como de estudiantes relacionados de alguna
manera con ésta unidad educativa.
o El manejo de información académica. Reside en coordinar las
asignaturas del departamento y las calificaciones obtenidas por
sus alumnos. De igual manera, se lleva el control de los proyecto
de grados y pasantías de estudiantes que son asistidos por
profesores del departamento de computación.
o El manejo de recursos materiales. El departamento se encarga
de supervisar, tanto la existencia de equipos adquiridos por él,
como el buen funcionamiento de los laboratorios a su cargo,
controlando así, la información referente a sus capacidades,
mobiliario y las actividades internas que allí se realizan.
o El manejo de eventos. Se refiere al control de los eventos
auspiciados por el departamento y de aquellos asistidos por sus
profesores al igual que los estudiantes asesorados por éstos.
o El manejo de publicaciones. Consiste en registrar los datos
generales de las publicaciones hecha por profesores del
departamento y/o estudiantes asistidos por profesores de
computación.
Reconocimiento
Revisión Bibliográfica
92
o El manejo de datos administrativos. Permite controlar la
información relacionada a las actividades administrativas,
laborales y financieras que el departamento debe realizar para la
correcta marcha de las funciones fijadas.
Así pues, el Departamento de Computación requiere de un sistema de información
que controle y automatice los procesos anteriormente expuestos debido al
aumento, en esfuerzo y volumen, de las actividades administrativas, académicas,
de investigación y extensión de los profesores que laboran en ésta unidad y de los
estudiantes que cumplen con el plan de estudio establecido por la Escuela de
Ingeniería de Sistemas.
3.1.2 Identificación de la Tecnología de Información para la Solución de Problemas de Información:
Actualmente, el control sobre los procesos del departamento de computación se
lleva manualmente; día a día se hace más difícil su manejo, lo que a su vez
disminuye la eficiencia y la eficacia en el acceso y administración de la información
en el momento en que se necesita. Debido a estas razones, ésta sección propone
la tecnología de información (TI) que soluciona los problemas de información
existentes en el departamento. Esto es:
o Una base de datos computarizada, en donde se almacenan los datos de
cada uno de los procesos que controlan las actividades del departamento.
o La manipulación de los datos almacenados en la base de datos por medio
de una interfaz gráfica de un sistema de información, que permita la
inserción, modificación, eliminación y búsqueda de los datos que se
requieran en un momento determinado, así como la obtención de
Reconocimiento
Revisión Bibliográfica
93
información por medio de consultas, listados y reportes realizados a los
datos registrados.
o El cálculo automático de las horas por actividad especificadas por el
baremo de los profesores del departamento.
o El cálculo automático de la disponibilidad de un equipo específico
perteneciente al departamento.
Definido el sistema de actividades en base al cual se desarrolló el sistema de
información, se procede en las secciones posteriores a modelar el diagrama
funcional jerárquico del mismo, el cual resume ordenadamente los procesos y
actividades que se llevan a cabo en el sistema organizacional del departamento.
3.1.3 Modelado de los Procesos Actuales del Sistema Organizacional:
Para el modelado de las actividades que actualmente el departamento de
computación desempeña, se presenta la tabla 3.2 que describe el diagrama
funcional jerárquico del sistema en estudio:
Reconocimiento
Revisión Bibliográfica
94
Funciones Procesos Descripción
F1
Manejo de Recursos Humanos:
F1.1
Profesores del
departamento
P1 Control de datos
personales:
Nombres, apellidos, direc-
ción, teléfono, categoría,
condición, e-mail, etc.
P2 Control de datos
curriculares:
Estudios y cursos reali-
zados, reconocimientos,
proyectos, sociedades y
grupos de investigación,
actividades de esténsión,
cargos desempeñados
P3 Control de carga
laboral:
Asignaturas dictadas, hora-
rios, secciones y estudian-
tes asignados, prepa-
radores y laboratorios bajo
su coordinación, proyectos
de grados y pasantías bajo
su tutoría, etc.
P4 Control de planes e
informes de
actividades:
Datos sobre las actividades
realizadas o por realizar
por el profesor: nombre y
tipo de actividad, horas
invertidas, cálculos hechos
por horas definidos por el
baremo, fecha de apro-
bación del baremo, etc.
F1.2
Estudiantes
relacionados
con el
departamento
P1 Control de datos
personales:
Información limitada: nom-
bres, apellidos, cédula, etc.
P2 Control de datos
curriculares:
Información limitada: reco-
nocimientos, experiencia
laboral.
P3 Control de datos
académicos:
Horario y materias
asignadas, calificaciones
de asignaturas del dpto,
laboratorios inscritos
Reconocimiento
Revisión Bibliográfica
95
Funciones Procesos Descripción
F1.3
Preparadores
del
departamento
P1 Control de
concursos:
Recaudo de los requisitos
necesarios para el concur-
so, fecha de concurso, etc.
P2 Control de la carga
laboral:
Objetivos alcanzados, cum-
plimiento de horario, entre-
ga de calificaciones finales,
etc.
F1.4
Beca Trabajos
P1 Control de datos
administrativos:
Departamento a cargo,
fechas de ingreso y fin del
programa, profesor super-
visor, etc.
P2 Control de la carga
laboral:
Número de horas traba-
jadas, objetivos alcanza-
dos, asistencia, etc.
F1.5
Pasantes
Externos
P1 Control de datos
Personales:
Nombres, apellidos, direc-
ción, teléfono, lugar y fecha
de nacimiento, represen-
tante, etc.
P2 Control de datos
académicos:
Instituto, año, sección y
mención que estudia,
tutores, fechas de inicio y
fin.
P3 Control de la carga
laboral:
Nombre de la empresa,
número de horas trabaja-
das, objetivos alcanzados,
asistencia.
F1.6 Cotutor
Externo
P1 Control de datos
personales:
Información limitada:
nombres, apellidos, insti-
tuto, dirección, depen-
dencia.
P2 Control de datos
académicos:
Tema del proyecto o
pasantía bajo su tutoría y
observaciones hechas al
trabajo.
Reconocimiento
Revisión Bibliográfica
96
Funciones Procesos Descripción
F2
Manejo de Información Académica:
P1 Control de las
asignaturas y
calificaciones:
Contenido, objetivos, horas
TPLU, horas/créditos,
prelaciones, códigos, califi-
caciones finales de
asignaturas y laboratorios
del departamento.
P2 Control de los
Proyectos de
Grado:
Información sobre los
temas, tutores, tesistas,
jurados, financiamiento, etc
P3 Control de
Pasantías:
Información sobre temas,
pasantes, tutores, jurados
de pasantías industriales y
de investigación.
F3
Manejo de Recursos Materiales:
P1 Control de
Equipos:
Datos sobre existencia en
inventario, fecha de
solicitudes y devolución,
nombre del solicitante y
encargado de los equipos.
P2 Control de
Laboratorios:
Datos sobre horarios,
ubicación, responsables,
cupos, etc.
F4
Manejo de Eventos:
P1 Control de Eventos
asistidos por
Profesores:
Información limitada: Po-
nencias y datos sobre la
asistencia de profesores
del departamento en
eventos nacionales e
Internacionales.
P2 Control de Eventos
asistidos por
Estudiantes:
Información limitada: Po-
nencias y datos sobre la
asistencia de estudiantes
asesorados por profesores
del departamento en
eventos nacionales e
internacionales.
Reconocimiento
Revisión Bibliográfica
97
Funciones Procesos Descripción
F5
Manejo de Publicaciones:
P1 Control de Publica-
ciones hechas por
Profesores:
Información básica y
técnica limitada de
publicaciones hecha por
profesores: artículos, traba-
jos de asenso, libros, etc.
P2 Control de Publica-
ciones hechas por
Estudiantes:
Información básica y
técnica limitada de
publicaciones hecha por
estudiantes que han sido
asesorados por profesores
del departamento: artí-
culos, informes de
pasantías, monografías,
acta de eventos, etc.
F6
Manejo de Datos Administrativos:
P1 Control de
Permisos:
Datos sobre los permisos
solicitados por el profesor:
fechas, motivo, suplente,
etc.
P2 Control de
Reuniones del
Departamento:
Datos sobre las reuniones
que se realizan: fechas,
asistentes, puntos a tratar,
deci-siones, estatus, etc.
P3 Control de datos
financieros:
Información sobre las
actividades financieras del
departamento: solicitud de
montos para caja chica,
financiamientos internos,
etc.
Tabla 3.2: Diagrama funcional jerárquico del sistema de actividades del
Departamento de Computación.
Reconocimiento
Revisión Bibliográfica
98
3.1.4 Identificación Preliminar de los Tipos de Entidades:
El sistema de actividades estudiado tiene asociado un conjunto de
entidades que son de especial interés para el conocimiento y manipulación de
cada proceso descrito en el modelo funcional jerárquico (tabla 3.2) del sistema. En
la tabla 3.3, encontramos las entidades relevantes al dominio de aplicación junto
con una breve descripción de cada una de ellas.
Tipo de Entidad Descripción
Manejo de Recursos Humanos
Persona Datos básicos de la persona existente en el sistema Profesor Datos del profesor que pertenece al departamento
Secretaria Datos de la secretaria del departamento. Estudiante Datos del estudiante relacionado al departamento. Preparador Datos del preparador que pertenece al departamento.
Beca Trabajo Datos del beca trabajo relacionado al departamento. Jefe Datos del jefe del departamento.
Pasante Externo Datos del pasante externo que realiza pasantías en el departamento.
Cotutor Externo Datos del cotutor externo que asesora estudiantes relacionados al departamento.
Cursos Cursos que los profesores y estudiantes realizan para su mejoramiento profesional.
Estudios Estudios y especializaciones cursados por profesores. Reconocimientos
Especiales Reconocimientos y premios especiales otorgados a los profesores.
Sociedades Científico
Profesionales
Sociedades Científico-Profesionales en los que el profesor participa.
Reconocimientos Estudiantes
Reconocimientos y premios especiales otorgados a los estudiantes relacionado al departamento
Actividades de Extensión
Actividades de extensión que realiza el profesor.
Hoja de Vida Datos curriculares del estudiante relacionado al departamento.
Plan de Actividades Planes de las actividades por realizar del profesor.
Reconocimiento
Revisión Bibliográfica
99
Tipo de Entidad Descripción
Manejo de Recursos Humanos
Informes de Actividades
Informe de las actividades realizadas por el profesor.
Cargos Datos de los cargos desempeñados por el profesor en el departamento.
Cargos Administrativos –
Académicos
Cargos administrativos-académicos que el profesor ha desempeñado.
Baremo Datos del baremo del profesor del departamento, Proyectos Proyectos de investigación desarrollados por el profesor. Grupos de
Investigación Grupos de investigación coordinados y conformados por el profesor.
PuntosAHora Datos de los puntos por horas controlados por el baremo
Manejo de Información Académica
Materia Datos de las asignaturas coordinadas por el departamento.
MateriaSec Datos de las secciones de las asignaturas coordinadas por el depto.
LabMatSec Datos de las secciones de laboratorios del depto. Semestre Datos de los semestres. Horario Horarios de las asignaturas coordinadas por el depto.
Materia Dictada Evaluaciones fijadas por cada asignatura por el profesor. Proyecto de Grado Datos del proyecto de grado de estudiantes asesorados
por un profesor del departamento. Financiamiento Datos del financiamiento asignado a determinado
proyecto de grado asesorado por un profesor del depto. Pasantías Datos de las pasantías realizadas por estudiantes que
han sido asistidos por un profesor del departamento. Industrial Datos de las pasantías industriales realizadas por estu-
diantes que han sido asistidos por un profesor del depto. Investigación Datos de las pasantías de investigación realizadas por
estudiantes que han sido asistidos por un profesor del departamento.
Cursa Calificaciones finales de asignaturas del departamento cursadas por determinado estudiante.
Cursa Laboratorio Calificaciones finales de laboratorios del departamento cursados por determinado estudiante.
Preparaduría Preparadurías hechas a signaturas del departamento. Preparaduría Laboratorio
Preparadurías hechas a laboratorios del departamento.
Tipo de Entidad Descripción Manejo de Recursos Materiales
Equipo Datos generales de los equipos del departamento utilizados con fines académicos.
Solicitud Solicitudes hechas por profesores y estudiantes de equipos.
Laboratorio Datos de los laboratorios coordinados por el depto. Manejo de Eventos
Evento Datos de los eventos nacionales e internacionales asistidos por profesores y estudiantes del departamento, y los auspiciados por la unidad.
Publicación Publicaciones hechas por profesores del departamento y estudiantes asesorados por ellos.
Publicaciones Equivalentes
Publicaciones equivalentes que tipifica una publicación hecha por profesores del departamento.
Reconocimiento
Revisión Bibliográfica
100
Manejo de Publicaciones
Acta de Eventos Datos de actas generadas por los eventos y publicadas por profesores del departamento y estudiantes asesorados por ellos.
Revista Datos de revistas que contienen artículos publicados por profesores del departamento y estudiantes asesorados por ellos.
Artículo Datos de artículos publicados por profesores del departamento y estudiantes asesorados por ellos.
Libro Datos de libros publicados por profesores del departamento y estudiantes asesorados por ellos.
Capítulo Datos de capítulos publicados por profesores del departamento y estudiantes asesorados por ellos.
Informe/Monografía Datos de informes y monografías publicados por profesores del departamento y estudiantes asesorados por ellos.
Manejo de Datos Adminis-trativos
Permisos Datos de los permisos solicitados por profesores del departamento.
Suplentes Datos de las suplencias hechas en asignaturas coordinadas por el departamento.
Escuela Datos generales de la Escuela Departamento Datos generales de los Departamento adscritos a la
Escuela. Reunión de
Departamento Datos de las reuniones hechas por el departamento y las decisiones tomadas.
Puntos Tratados Puntos tratados en las reuniones del departamento.
Tabla 3.3: Entidades para el sistema de actividades del Departamento de Computación.
3.1.5 Identificación de los Actores: Los actores son los encargados de ejecutar los procesos desarrollados dentro del
sistema de actividades. Basados en el análisis del ambiente donde el sistema se
desarrolla, se identificaron los siguientes actores:
• Actores Principales: Son los actores que participan en los procesos
principales del departamento cuyas acciones permitirán la interacción de la
información.
o Jefe de Departamento,
o Secretaria,
o Profesor,
o Estudiante,
o Preparador y Beca Trabajo.
Reconocimiento
Revisión Bibliográfica
101
• Actores Secundarios: Estos actores participan en procesos específicos del
departamento pero no pertenecen a él.
o Pasante Externo,
o Cotutor Externo.
• Visitante: Es todo aquel usuario externo que accede al sistema mediante la
debida autorización.
3.1.6 Identificación de los Principales Eventos:
Toda dinámica está constituida por eventos que disparan procesos, que a su vez,
involucran o usan eventos complejos, permitiendo alcanzar un objetivo específico.
Así mismo, un evento determina el inicio o finalización de un proceso y modifica o
altera de alguna manera el estado de una entidad generando datos útiles para el
sistema de información.
Reconocimiento
Revisión Bibliográfica
102
Los eventos involucrados en el sistema de actividades estudiado se representan
en el diagrama de casos de uso de la figura 3.1. Este diagrama integra los eventos
generados por los actores principales y secundarios que participan en los
procesos del departamento.
La tabla 3.4 recapitula los actores y casos de uso del diagrama de casos de uso
UML en la figura 3.1:
Actor Casos de Uso Descripción
Profesor
Identificación: Verifica su identidad para que el sistema permita el
acceso del actor a determinadas funciones.
Actualiza Datos: Actualiza datos autorizados por el sistema realizando
los cambios más convenientes.
Consulta: Consulta datos de su interés debidamente aprobados
por el sistema.
Solicita: Permisos y Equipos a) Permiso: El actor requiere ausentarse de sus labores
y solicita un permiso por escrito al jefe del
departamento.
b) Equipos: El actor requiere de algún equipo por
razones académicas y lo solicita por escrito al
departamento.
Prepara Informe de Actividades: Desarrolla informes que dan a conocer las actividades
realizadas y horas invertidas por el profesor en un
período determinado para el cálculo del baremo
personal.
Prepara Plan de Actividades: Desarrolla planes que presentan la planificación de las
actividades de un profesor por realizar en un período
determinado para el cálculo del baremo personal.
Publica: a) Artículos de revistas y actas de eventos,
b) Libros y capítulos de libros,
c) Informes y monografías.
d) Trabajos de asenso.
Reconocimiento
Revisión Bibliográfica
103
Actor Casos de Uso Descripción Participa en Eventos: Participa en eventos nacionales e internacionales en
calidad de organizador, ponente o asistente.
Devuelve Equipos: Devuelve el equipo solicitado.
Da Tutoría: Ofrece tutorías en proyectos de grados y pasantías
industriales y de investigación a estudiantes de la
escuela de sistemas.
Imprime Reportes: Imprime datos autorizados por el sistema, requeridos
por el actor.
Jefe de Departamento:
Este actor es extensión de
Profesor y por ende, puede
realizar todas sus actividades.
Identificación: Verifica su identidad para que el sistema permita el
acceso del actor a determinadas funciones.
Da Mantenimiento: Depura la base de datos, lleva el control de los datos
históricos del sistema y actualiza los registros que
presenten información errónea.
Prepara Reunión: Prepara las reuniones del departamento utilizando
datos de las consultas hechas al sistema y datos
provenientes de otras fuentes de información.
Realiza Reunión: Cambia el estatus de los puntos tratados de acuerdo a
las decisiones tomadas en la reunión del
departamento.
Supervisa: Autoriza el ingreso de datos de naturaleza delicada al
sistema.
Estudiante: Este actor incluye a los Preparadores y Beca Trabajos
del Departamento
Identificación: Verifica su identidad para que el sistema permita el
acceso del actor a determinadas funciones.
Actualiza Datos: Actualiza datos autorizados por el sistema de acuerdo
a los privilegios otorgados.
Consulta: Consulta datos de su interés, debidamente aprobados
por el sistema.
Solicita: Beca Trabajo y Equipo a) Beca Trabajo: El actor esté interesado en el cargo y
lo solicita por escrito.
b) Equipo: El actor requiere de algún equipo por
razones académicas y lo solicita por escrito al
departamento.
Reconocimiento
Revisión Bibliográfica
104
Actor Casos de Uso Descripción Devuelve Equipo: Devuelve el equipo solicitado.
Entrega de Documentos:
Proyecto de Grado, Pasantías,
Inscripción, Concurso, Grado.
a) Inscripción: arancel y planilla para la inscripción
semestralmente de las asignaturas.
b) Proyecto de Grado y Pasantías Industriales y/o de
Investigación: requisitos para la inscrip-ción y
presentación de estas asignaturas en particular.
c) Concurso: requisitos para el cargo de preparador.
d) Grado: requisitos para el grado.
Participa en Eventos: Es asesorado por un profesor del departamento y
participa en eventos nacionales e internacionales en
calidad de organizador, ponente o asistente.
Expone Informe/Monografía: Expone la monografía del Proyecto de Grado y/o el
informe de la Pasantía Industrial o de Investigación.
Concursa: Concursa para el cargo de preparador.
Publica: a) Artículos de revistas y actas de eventos,
b) Libros y capítulos de libros,
c) Informes y monografías.
Imprime Reportes: Imprime datos requeridos, ya autorizados.
Secretaria Identificación: Verifica su identidad para que el sistema permita el
acceso del actor a determinadas funciones.
Actualiza Datos: Actualiza datos autorizados por el sistema realizando
los cambios más convenientes.
Consulta: Consulta datos de su interés, debidamente aprobados
por el sistema.
Da Mantenimiento: Depura la base de datos y actualiza los registros que
presenten información errónea según los privilegios
otorgados por el sistema.
Imprime Reportes: Imprime datos autorizados por el sistema, requeridos
por el actor.
Actor Casos de Uso Descripción Cotutor Externo
Identificación: Verifica su identidad para que el sistema permita el
acceso del actor a determinadas funciones.
Da Tutoría Industrial: Ofrece tutorías industriales a Proyectos de Grados y
Pasantías Industriales.
Reconocimiento
Revisión Bibliográfica
105
Consulta Restringida: Consulta datos de acuerdo a los privilegios otorgados
al actor por el sistema.
Pasante Externo y Visitantes
Identificación: Verifica su identidad para que el sistema auto-rice el
acceso del actor a determinadas funciones.
Consulta Restringida: Consulta datos de acuerdo a los privilegios otorgados
al actor por el sistema.
Tabla 3.4: Recapitulación de los actores y casos de uso de SIDECOM.
3.2 ESPECIFICACIÓN DE LOS REQUERIMIENTOS: Una vez que se hayan determinado los objetivos del sistema y el ambiente
en el que se operará, se deben definir el conjunto de funciones y tareas que
realizará el sistema para lograr cumplir con el objetivo establecido. Así pues, se
señalan a continuación los requerimientos del sistema:
3.2.1 Requerimientos de Interacción Usuario-Sistema:
Los requerimientos de interacción usuario-sistema están basados en una interfaz
gráfica de menús desplegables, que se encarga de llevar al usuario a diferentes
pantallas según la actividad seleccionada; y botones, los cuales llevan a cabo las
tareas básicas de interacción como insertar, modificar y consultar dentro de cada
forma diseñada para una actividad particular del sistema. Esta interfaz se diseñó
de manera que fuera lo más amigable posible al usuario, proporcionando facilidad
en la navegación entre las formas y pantallas, que además, son consistentes y
sencillas.
3.2.2 Requerimientos de Entrada de Datos:
Los datos que alimentan al sistema de información provienen de documentos
previamente autorizados para su ingreso y de la observación directa del dominio
Reconocimiento
Revisión Bibliográfica
106
de la aplicación. El medio empleado para su captura es directamente el teclado y
los datos se validan a medida que se van introduciendo.
3.2.3 Requerimientos de Salida:
Los requerimientos de salida se determinan a partir del modelo funcional del
sistema de actividades elaborado en la sección 3.1. Para cada proceso, se
identifica y especifica la información que los actores involucrados en él requieren
para ejecutar cada una de las actividades del proceso. De esta manera, se
descompone el diagrama de casos de uso15 global en pequeños diagramas
representados en las figuras 3.2 al 3.7.
15 Diagrama de la notación UML.
Figura 3.2: Diagrama de casos de uso para el control de las actividades de los
Estudiantes del Departamento de Computación.
Actualiza Datos
Imprime Reportes
Devuelve Equipo
Entrega Documentos
Publica
Participa en Eventos
Solicita
Consulta
Consulta restringidaIdentificación
Estudiante
<<usa>>
ConcursaExpone
Infrome/Monografía
<<usa>>
<<usa>>
<<usa>>
<<dispara>>
<<usa>><<usa>>
<<usa>> <<usa>>
<<usa>>
<<usa>>
<<extiende>>
<<dispara>><<dispara>>
<<dispara>><<dispara>>
<<dispara>><<dispara>><<dispara>>
<<dispara>><<dispara>>
Reconocimiento
Revisión Bibliográfica
107
<<dispara>>
Da Mantenimiento
Ac tua liza Datos
Imprime Reportes
Consulta
C ons ulta re stri ngi daIdentific ación
Secretaria
< <ex tiende>>
<<usa>>
<<usa>>
<<usa>>
<<usa>>
<<dispara>>
<<dispara>>
<<dispara>>
Figura 3.3: Diagrama de casos de uso para el control de las actividades realizadas
por la Secretaria del Departamento de Computación.
<<dispara>>
Consulta restringidaIdentificación
<<usa>>
SolicitaPrepara Plan
Prepara Informe
Participa en Eventos
Da Tutoría
<<usa>>
Publica
Devuelve Equipo
Imprime Reportes
Actualiza Datos
Profesor
(from Logical
<<Profesor>>
Consulta
<<extiende>>
<<usa>>
<<usa>>
<<usa>>
<<usa>>
<<usa>>
<<usa>><<usa>>
<<usa>>
<<dispara>>
<<dispara>>
<<dispara>>
<<dispara>><<dispara>>
<<dispara>>
<<dispara>>
<<dispara>>
<<dispara>>
Figura 3.4: Diagrama de casos de usos para el control de las actividades
realizadas por el Profesor del Departamento de Computación.
Reconocimiento
Revisión Bibliográfica
108
Pro f e so r
( f ro m L o g i c a l V i e w )
< < Pro f e so r> >J e f e
< < Pro f e so r>
D a M a n te n im ie n to
< <d is p a ra >>
R e a liza R e u n ió n
< <di sp a ra >>
Pr e pa r a R eu n ió n
<< d is p a ra > >
Su p e rvisa D a to s
< <d is p a ra >>
I d e n t if ic a c ió n< < us a >>
<< u s a >> << u s a > >
< < us a >>
e s u n
V is itan te
Identif icación Con sul ta r est ri ng ida
Pas ante E x terno
C onsulta
<<us a>>
<<dis para>> <<dis para>>
<<ex t iende>>
<<extiende>>
IdentificaciónDa Tutoría
Cotutor
Consul ta re stringi da
Consulta
<<usa>>
<<dispara>><<dispara >>
<<usa>>
Figura 3.5: Diagrama de casos de uso para el control de las actividades realizadas por el
Jefe del Departamento de Computación.
Figura 3.7: Diagrama de casos de uso para el control de las actividades realizadas
por el Cotutor Externo en el Departamento de Computación.
Figura 3.6: Diagrama de casos de uso de las actividades que el Pasante externo y
el Visitante realizan en el Departamento de Computación.
Reconocimiento
Revisión Bibliográfica
109
Estos diagramas de casos de uso muestran la interacción del sistema con
los usuarios o actores del mismo, capturados algunas funciones visibles
representadas por una secuencia de acciones que producen un resultado
observable valioso para un actor en particular.
La tabla 3.5, resume los requerimientos de información encontrados mediante la
observación directa de la ejecución de las actividades, entrevistas realizadas a los
usuarios principales del sistema y los diagramas de casos de uso anteriormente
señalados. Las funciones y procesos de esta tabla representan las de la tabla 3.2
donde se enmarca el diagrama funcional jerárquico de las actividades del
departamento, y por lo tanto, debemos referirnos a esa leyenda.
Funciones Procesos Requerimientos
F1
F1.1 P1 • Listar los profesores que pertenecen al departamento.
• Consultar datos completos personales.
P2 • Consultar los niveles de estudio realizados y sus financiamientos.
• Consultar idiomas extranjeros dominados.
• Listar reconocimientos especiales otorgados.
• Listar cursos realizados para el mejoramiento profesional.
• Listar los proyectos de investigación en los que ha participado.
• Listar las sociedades científicas-profesionales, grupos de investigación y actividades
de extensión a los que ha pertenecido.
• Listar cargos académicos y administrativos desempeñados en el departa-mento por
el profesor consultado.
P3 • Consultar el horario asignado de clases en determinado semestre.
• Listar las asignaturas dictadas por el profesor consultado.
• Listar proyectos de grado y/o pasantías asesoradas por el profesor.
• Consultar laboratorios y preparadores coordinados por el profesor.
P4 • Listar los informe de actividades realizadas por el profesor consultado.
• Listar los planes de actividades por realizar del profesor consultado.
• Consultar datos de los informes de actividades del profesor: nombre y tipo de
actividad, fechas, porcentaje de avance, horas calculadas por el baremo.
• Consultar datos de los planes de actividades del profesor: nombre y tipo de
actividad, fechas, porcentaje de avance, horas calculadas por el baremo.
• Consultar datos básicos del baremo del profesor consultado.
Reconocimiento
Revisión Bibliográfica
110
Funciones Procesos Requerimientos
F1
F1.2 P1 • Consultar datos completos personales de estudiantes relacionados con el
departamento.
P2 • Listar los cursos realizados para el mejoramiento profesional.
• Consultar idiomas extranjeros dominados.
• Reportar experiencia académica adquirida como preparador o beca trabajo.
• Listar reconocimientos otorgados.
P3 • Reportar las materias y laboratorios asignados al estudiante.
• Consultar las calificaciones obtenidas por el estudiante en asignaturas y laboratorios
del departamento.
F1.3 P1 • Listar los preparadores que pertenecen al departamento.
• Consultar datos completos personales (F1.2: P1), y hoja de vida (F1.2: P2).
• Consultar fechas del concurso, ingreso y salida del cargo
• Consultar los semestres dictados.
P2 • Listar asignaturas y laboratorios asistidos por él en determinado semestre.
• Consultar funciones del preparador.
• Consultar el profesor del departamento que los supervisa.
F1.4 P1 • Listar los beca trabajos que pertenecen al departamento.
• Consultar datos completos personales (F1.2: P1).
• Consultar fechas de ingreso y salida del programa.
P2 • Consultar funciones del beca trabajo.
• Consultar semestres trabajados.
• Consultar el profesor del departamento que lo coordina.
F1.5 P1 • Listar los pasantes externos que han realizado sus pasantías en el depto.
• Consultar datos completos personales.
P2 • Consultar datos completos administrativos del pasante dados por el instituto de donde
proviene y de la empresa donde se ha realizado las pasantías: nombre de la institución,
nombre de la empresa, año, mención, representante, reglamento, fechas de ingreso y
fin de las pasantías y tutores responsables.
P3 • Consultar funciones asignadas al pasante, horas semanales cumplidas y observaciones
hechas por sus tutores responsables.
F1.6 P1 • Consultar datos personales y administrativos del cotutor: nombres, apellidos,
teléfonos e instituto y dependencia al que pertenece.
P2 • Listar los temas de los proyecto asesorados y las observaciones hechas al trabajo por
el cotutor externo.
• Listar los temas de las pasantías industriales asesorados y las observa-ciones hechas al
trabajo por el cotutor externo.
Reconocimiento
Revisión Bibliográfica
111
Funciones Procesos Requerimientos
F2
P1 • Consultar el pénsum de estudio y los datos generales de las asignaturas: horas TPLU,
objetivos, contenidos, reglamentos y prelaciones.
• Consultar datos generales de los semestres.
• Consultar aulas y horario de asignaturas de computación por semestre.
• Listar las evaluaciones fijadas por semestre de las asignaturas que pertenecen al
departamento.
• Reportar rendimiento promedio del curso de las asignatura por semestre.
P2 • Listar los proyectos de grados asistidos por profesores del departamento.
• Consultar información general por estudiante sobre el tema, tutores, jurados,
financiamiento, línea de desarrollo y cotutoría del proyecto de grado inscrito.
P3 • Listar las pasantías de investigación e industriales, cortas y largas, de estudiantes
asesorados por profesores del departamento.
• Consultar información general por estudiante sobre la pasantía industrial inscrita: tipo
de pasantía industrial, tema, tutores, jurados, línea de desarrollo, compañía y cotutoría.
• Consultar información general por estudiante sobre la pasantía de investigación
inscrita: tema, tutores, jurados y línea de investigación.
F3
P1 • Listar equipos existentes en el departamento.
• Reportar fechas de solicitud, entrega y devolución del equipo.
• Consultar responsables y reglamentos para el préstamo.
• Listar los equipos prestados por determinado solicitante.
P2 • Consultar datos generales de los laboratorios del departamento: objetivos,
reglamentos y horas semanales.
• Consultar el horario de los laboratorios por sección, su capacidad y ubicación en
determinado semestre.
• Listar las prácticas, evaluaciones fijadas, preparadores de los laboratorios que
pertenecen al departamento en determinado semestre.
F4
P1 • Listar los eventos nacionales e internacionales asistidos por profesores del
departamento.
• Consultar datos generales de eventos nacionales e internacionales asistidos por el
profesor consultado: tipo de evento, instituto que lo auspicia, fechas de inicio y
finalización, financiamiento y tipo de participación en dicho evento.
P2 • Listar los eventos asistidos por estudiantes que han sido asesorados por profesores del
departamento.
• Consultar datos generales de eventos nacionales e internacionales asistidos por el
estudiante consultado: tipo de evento, instituto que lo auspicia, fechas de inicio y
finalización, financiamiento y tipo de participación en dicho evento.
Reconocimiento
Revisión Bibliográfica
112
Funciones Procesos Requerimientos
F5
P1 • Listar artículos publicados en actas de eventos (ponencias) y revistas de profesores
del departamento.
• Listar capítulos de libros y libros publicados por el profesor consultado.
• Listar trabajos de asenso publicados por el profesor consultado.
• Listar informes y monografías publicados por el profesor consultado.
• Consultar datos técnicos de las publicaciones hechas por el profesor: título, volumen
y número de la revista, editorial, autores secundarios, fecha de publicación,
descriptores, cotas bibliográficas, número de páginas, número de artículos y capítulos,
entre otros.
P2 • Listar artículos publicados en actas de eventos (ponencias) y revistas de estudiante
que han sido asesorados profesores del departamento.
• Listar capítulos de libros y libros publicados por el estudiante consultado.
• Listar informes de las pasantías industriales y/o de investigación realizados por el
estudiante consultado.
• Listar la monografía final de grado publicado por el estudiante consultado.
• Consultar datos técnicos de las publicaciones hechas por el estudiante: título, fecha de
publicación, volumen y número de la revista, editorial, autores secundarios, cotas
bibliográficas, descriptores, número de páginas, número de artículos y capítulos, entre
otros.
F6
P1 • Listar permisos solicitados por el profesor consultado.
• Consultar información sobre los permisos solicitados por el profesor: moti-vos, fechas
de solicitud, fechas de inicio y fin y profesor suplente.
P2 • Listar las reuniones del departamento hechas en un período determinada.
• Consultar datos de las reuniones hechas en el departamento: fechas de reunión, horas
de inicio y fin y estatus.
• Consultar decisiones tomadas en una reunión determinada.
P3 • Consultar los requisitos para solicitar financiamiento por el departamento para fines
académicos menores.
Tabla 3.5: Requerimientos de salida.
3.2.4 Requerimientos Funcionales:
• Adquisición de Datos: La captura de datos se realiza a través de formularios
o ventanas. En estas se pide la entrada de datos al usuario quien
transcribe lo necesario a través del teclado. Algunos otros datos son
Reconocimiento
Revisión Bibliográfica
113
capturados por medio del evento click del mouse, seleccionando alguna
opción entre las que son ofrecidas.
• Administración de la Base de Datos: La base de datos es administrada
por el manejador Sybase Anywhere 7.0. Con él se controla la integridad
referencial, el respaldo y recuperación de la bases de datos ante fallas y la
distribución de los datos en los dispositivos de almacenamiento.
• Generación y presentación de información: la información se presenta
por medio de la pantalla a través de ventanas que contendrán la
información solicitada en forma tabular o de reportes y que podrán ser
impresos, si se posee la autorización dada por el sistema.
3.2.5 Requerimientos de Almacenamiento:
Los requerimientos de almacenamiento de datos se expresan a través de
esquemas conceptuales en los que se especifican los tipos de entidades del
sistema de actividades cuyos datos son almacenados en la base de datos, los
atributos de cada tipo de entidad y las relaciones entre estos tipo de entidades
[Mon97a]. Para la elaboración de estos esquemas conceptuales, se recomienda el
uso de los diagramas de clases de UML.
Los siguientes diagramas de clases, representados en las figuras 3.8 al
3.23, describen las entidades utilizadas en cada uno de los procesos del sistema
de actividades dados en la tabla 3.2, al igual que las asociaciones entre ellas.
Reconocimiento
Revisión Bibliográfica
114
1) Manejo de Recursos Humanos:
1..*
Persona<<Profesor >>
Cursos<<Profesor >>
Jefe<<Profesor>>
Departamento
1..1
1..1
+esJefeDe1..1
+Jefe1..1
jefatura
Cargos<<Profesor>>
Proyectos<<Profesor>>
ReconocEspec iales<< Profesor>>
Estudios<<Profesor>>
SociedadesCP<< Profesor>>
ActividadesDeExtension<<Profesor>>
GrupoDeInvestigacion<<Profesor>>
Profesor<<Profesor>>
1..*
1..1
+labor anEn1..*
+laboran
1..1labora
1..*
*
+desarrollan1..*
+responsable
*
desarrollan
1..1
0..*
+ seAsocia1..1
+asociado0..*
asociados
0..*
+confor ma
*
+conformadoPor0..*
conforman
1..1
0..*
+coordina
1..1
+coordinador0..*
coordinan
1..1
1..*
+hace1..1
+ hechaPor
hacen
*
1..*
+participa
*
+participante1..*
parti cipan
1..1
0..*
+reciben1..1
+fueRecibidoPor
0..*
reciben
1..1 0..*+cursan1..1
+cursadoPor
0..*cursan
1..1
1.. *
+desempeña1..1
+desempeñadoPor
1.. *
desempeñan
es una
es un
MateriaDictada<<Asociación>>
Preparador
BecaTrabajo
Laboratorio<<Profesor>>
Horario<<Profesor>>
Materia<<Profesor>>
0..*
0..3
+prela0..*
prelación
+preladaPor0..3
Pasantias<<Profesor>>
es una
MateriaSec<<Profesor>>
ProyectoDeGrado<<Profesor>>
es una
Profesor<<Profesor>>
0..*
1..1
+supervisadoPor0..*
+supervisan1..1
supervisión
1..10..*
+coordina 1..1+coordinadoPor
0..*coordinación
1..1
0..*
+organiza1..1
+organizadoPor0..*
organizacion
1..1
*tutoría
1..1
1..*1..3
*
0..1
*
+tutorDe
+tutorPor
1..1
*
cotutorProfesor
+cotutorProfDe0..1
*
+dicta
+dictadasPor
1..3
*
guía+esGuía
+guiadoPor
1..1
1..*
es una
+cotutorPor
Figura 3.9: Diagrama de clases para el control de la carga laboral de los Profesores del
Departamento de Computación.
Figura 3.8: Diagrama de clases para el control de datos personales y curriculares
de los Profesores del Departamento de Computación.
Reconocimiento
Revisión Bibliográfica
115
PublicacionesEquivalentes<<Profesor>>
InformedeActvRealizadas<<Profesor>>
PlandeActvPorRealizar<<Profesor>>
Profesor<<Profesor>>
1..1
1..*
+presenta1..1
+presentadoPor
1..*presentan
1..1
1..*+planifica
1..1
+planificadoPor
planifican1..*
PuntosAHoras<<Profesor>>
Baremo<<Profesor>> *
*+codificaPtos
* +sonCodificadosPtos
*codifiPtos
*
*
+codificaPub
*
+sonCodificadas*
codifiPub
CargosAdmAcad<<Profesor>>
*
*
+codifica *
+sonCodificados *
codificación
Cargos<<Profesor>>
1..* 1..1
+clasificadoComo
1..*
+clasifica
1..1clasifica
1..1
1..*
+desempeña1..1
+desempeñadoPor1..*
desempeñan
Figura 3.10: Diagrama de clases para el control de los planes e informes de actividades de
los Profesores del Departamento de Computación.
CursaLab<<Asociación>>
HojaDeVida
Cursos<<Profesor>>
ReconocEstudiantes<<Profesor>>
Escuela Departamento
LabMatSec
Horario<<Profesor >>
Persona<<Profesor>>
Materia<<Profesor >>
1..1
1..5+departamentos
1..1 +adscritoA
1..5adscripción
0..*
0..3
+prela0..*
prelación
+preladaPor0..3
Cursa<<Asociación>>
MateriaSec<<Profesor >>
1..1* +tiene
1..1
+dadaEn*
tieneLab
Estudiante
1..1
1..1
+per teneceA
1..1
+posee1..1
poseen
1..1
0..*+reciben 1..1
+recoRecibidoPor
0..*reciben
es una
*
8..n
+sonCursadas
*
+cursaLab8..n
1..*
1..2
+estudianEn1..*
+estudia1..2
estudian
1..10..* +hace 1..1
+cursoHechoPor
0..*hechoPor
5..n
*
+cursan
+cursadasPor
5..n
*
es una
Figura 3.11: Diagrama de clases para el control de los datos personales,
curriculares y académicos de los Estudiantes del Departamento de Computación.
Reconocimiento
Revisión Bibliográfica
116
Pe rsona<<Profesor>>
PreparaduriaLab<<A sociación>>
P re pa ra du ria<<Asociación>>
Horario<< Pro fes or >>
M ateria<< Profesor >>
0.. *
0..3
+pr ela0.. *
prelación
+prelad aP or0..3
Escuela BecaTrabajo
Laboratorio<<Profesor>>
Profesor<< Profes or >>
0..*
1..1
+supervisadoPo r0..*
+supervisan1..1
supervisión
M ateriaSec<< Profesor >>
e s u na
LabM atSec1..1* + tiene 1..1+dadaEn* t ien eL ab
Departam ento
1..1
1..5
+departam entos1..1
+ ad sc ri toA 1..5
adscripción
1..1
1..*
+ be ca Tr ab ajo1..1
+depACargo1..*
departCargoBT
Preparador1..*
1..1
+a si ste1..*
+asistidoPor
1..1
asistente
1..1
0.. *
+coordina1..1
+coordinadoPor
0.. *
coord inación
1..3
1..2
+p reparad oPo r1..3
+preparadorDe1..2
1.. *
1..*
+prepaLabPor1.. *
+pr ep aL ab De1..*
1..1
1..*
+Preparador1..1
+depACargo1..*
departCargoPrepa
HojaDeVidaCursos<<Profesor>>
ReconocEstudiantes<<Profesor>>
Estudiante
1..1
1..1
+perteneceA1..1
+posee1..1
po se en
1..1
0..*
+hace1..1
+cursoHechoPor0..*
hechoPor
1..1
0..*
+reciben 1..1
+ re co Re ci bid oPo r 0..*
re ciben
e s una
es un
es un
es una
Figura 3.12: Diagrama de clases para el control de concursos, carga laboral y datos
administrativos de los Preparadores y Beca Trabajos
del Departamento de Computación.
PasanteExternoPersona<< Profes or >> 1..1 1..1
+ esR epresentante1..1
+ re pr esentad oP or1..1
representa
Profesor<< Profes or >>
e s una1..*
1..1
+ pasanteExterno1..*
+ responsablePor
1..1 responsable
Pasantias< < Profesor> >
M ater ia< < Profesor> >
0..*
0..3
+ prela0..*
prelación
+ preladaPor
0..3
es una
Proyect oD eGrado< < Profesor> >
C otutor<< Profes or >>
e s una
1..1
1.. *
+ esT utorPasante
1..1
+ PasanteD e1.. *
tutorPasanteExtrerno
*
0..1
Industr iales es un tipo de*
1..1
es u na
es una
tutorPasantiaIndustr ial
+ tutor Indust
+ esT utor Indust
*
1..1
C otutorPG
+ cotutorPor
+ esC otutor
0..1
*
Figura 3.13: Diagrama de clases para el control de los datos personales, académicos y
carga laboral de los Pasantes Externos y Cotutores
relacionados al Departamento de Computación.
Jefe
Reconocimiento
Revisión Bibliográfica
117
2) Manejo de Información Académica:
prelaciónMateria<<Profesor>>
Semestre<<Profesor>>
Horario<<Profesor>>
MateriaDictada<<Asociación>>
0..*
0..3
+prela
0..*
+preladaPor
0..3
Laboratorio<<Profesor>>LabMatSec
* 1..1
MateriaSec<<Profesor>>
es una
*
1..1
+seAbren*
+abre 1..1
apertura
1..1
*
+tiene1..1
+dadaEn*
tieneLab
Departamento
Profesor<<Profesor>>
1..10..*
+organiza
1..1+organizadoPor
0..* organizacion
1..3
1..*1..*
1..1
ubicación
+ubicadaEn +seUbica
* 1..1
+dicta
+dictadaPor
1..3
1..*
laboran
+laboraEn
+labora
1..*
1..1
F in an ci am ie nto
C ursa< < Asociación> >
M ater ia<< P ro fes or >>
0.. *
0..3
+ prela0.. *
prelación
+ preladaPor0..3
C otutor< < Profesor> >
D epar tam e nto
M ater iaSec< < Profesor> >
es una
Estudiante
1..*
5..n
+ cursadaPo r 1..*
+ cu rsa 5..n
P ro ye cto D eG ra do<< P ro fes or >>
es una
* 0..1
+ cotutorPor
*
+ escotutor
0..1C otut or PG
0 ..1
1..1
P ro fesor<< P ro fes or >>
*
1..1
+ tutorPor *
+ tu tor De1..1
tutor ia
*
0..1
+ cotut or Pr ofP or*
+ co tu torProf De0..1
cotutorProfesor
*
2..2
+ evaluadoPor
*
+ esJurado2..2
jurado
*
1..1
+ jurSuplentePor
*
+ ju rSup lente1..1
suplenciaProy
1..11..*+ labora
1..1
+ lab or an En1..* labora
1..1
0..2
financia
+ financiaProyecto
+ financiadoPor
0 ..1
1..1
encargado
+ encargadoDe
+ encargadoPor
1..1
0..2
Figura 3.15: Diagrama de clases para el control de Proyectos de Grados
asesorados por profesores del Departamento de Computación.
Figura 3.14: Diagrama de clases para el control de las evaluaciones y calificaciones
de estudiantes en Asignaturas pertenecientes al Departamento de Computación.
Reconocimiento
Revisión Bibliográfica
118
Indu st r iales
In ve st ig ac ion
M ater ia< < Profesor> >
0..*0..3
+ prela
0..*pr el ación
+ preladaPor
0..3
C ursa< < Asocia ci ón>>
Es tud ia nte
M at er iaSec< < Profesor> >
e s una
1..*
5..n
Pasantias< < Profesor> >
es unaes un tipo de
C otu tor< < Profesor> >
es un tipo de
*
1..1
Profesor< < Profesor> >
1 ..1
1.. *
2..2
*
1 ..1
*
D epartamento
1..1 1..*
g uia
+ esGuia
+ g uiadoPor
1 ..1
1.. *
suplenciaPasan
+ esJurSupPasan
+ jurSupPasanPor
1 ..1
*
juradoPasantia
+ esJurPasan
+ JurPasanPor
2..2
*
laboran+ labora + laboranEn
1..1 1..*
+ cursadasPor
+ cursan
tutorPasantiaIndustr ial
+ tutor Indust
+ esTutorIndust
*
1..1
1..*
5..n
.
3) Manejo de Recursos Materiales:
1..*
Solicitud<<Asociaci ón>>
Estudiante Secretaria Departamento1..11..1
Profesor<<Profesor>>
1..1
1..*
Equipo
0..*
1..1
+recibidoPor
0..*
+recibe1..1
recibe
1..*
0..*
0..* 1..1
secretaria
+secretaria+esSecretariaDe
1..11..1
laboran
+labora
+laboranEn1..*
1..1
autorizado
+autorizadoPor +autoriza
0..*
+solicitaEquipo
+solicitado0..*
1..1
Figura 3.17: Diagrama de clases para el control de Equipos
pertenecientes al Departamento de Computación.
Figura 3.16: Diagrama de clases para el control de las Pasantías Industriales y de
Investigación realizadas por estudiantes asesorados por
profesores del Departamento de Computación
controlan
+controla
+esControladoPor 0..*
1..1
Reconocimiento
Revisión Bibliográfica
119
+tiene
Horario<<Profesor>>Preparadur iaLab
<<Asociación>>
Preparador Departamento1..11..*
departCargoPrepa
+preparador+depACargo1..11..*
Laboratorio<<Profesor>>
1..*
1..1
+asiste
1..*
+asistidoPor1..1
asistente
LabMatSec*
1..1
+prepaLabPor *
+prepaLabDe 1..1
*
1..1
ubicacion
+ubicadaEn
+seUbica
*
1..1
Profesor<<Profesor>>
1..1
0..*
+coordina1..1
+coordinadoPor0..*
coordinación
1..10..*+organiza
1..1+org anizado0..*
org anizacion
1..*
1..1
+laboraEn1..*
+labora1..1
laboran
Mater iaSec<<Profesor>>1..1* 1..1
+dadaEn* tieneLab
Figura 3.18: Diagrama de clases para el control de los Laboratorios
coordinados por profesores del Departamento de Computación.
4) Manejo de Publicaciones:
+ g enera
R evistas< < P ro fesor> >
Libro< < Profesor> >
C apitulo< < Profesor> >
Articulo< < Profesor> >
C ontiene
1 ..1
*
1 ..1
*
R evistaC ontiene
Estudiante
Pub lic ac ion< < Profesor> >
e s una es una
*
1..*
Evento< < Profesor> >
ActadeEvento< < Profesor> >
1..1
*
1..1
*
ActaC ontiene
es una
1..1
1..1
Pasantias< < Profesor> >
Proyect oD eGrado< < Profesor> >
Informe/M onog rafía< < Profesor> >
es una
1 ..1
1..1
1..1
1..1
publica
+ sonPublicacionesD e
+ pu bl ico
*
1..*
Informe
+ dePasantia
+ In for me
1 ..1
1..1
M onog rafía
+d eP ro ye cto
+ M onog rafia
1..1
1..1
g eneran
+ g eneradaPor1..1
1..1
Figura 3.19: Diagrama de clase para el control de las Publicaciones hechas por Estudiantes
asesorados por profesores del Departamento de Computación.
Reconocimiento
Revisión Bibliográfica
120
Libro< < Profesor> >
C apitulo< < Profesor> >
C ontiene
R evis tas<< Profes or >>
Ar ticulo<< Pro fes or >>
1..1
*
1..1
*
R evistaC ontiene
ActadeEvento< < Profesor> >
1 ..1
*
1 ..1
*
ActaC ontiene
E ve nto< < Profesor> >
1 ..1
1..1
+ g eneradaPor1 ..1
+ g enera1..1
g eneran
Pasantias< < Profesor> >
I nfo rme /M on og ra fía< < Profesor> >
1..1
1 ..1
+ dePasantia1..1
+ In for me 1 ..1
Informe
ProyectoD eGrado< < Profesor> >
1..1
1..1
+ deProyecto1..1
+ M onog rafia1..1
M onog rafía
Baremo< < Pro fesor> >
Profesor< < Profesor> >
Publicac ionesEquivalentes< < Pro fesor> >
*
*
+ co dific aP ub
* +s on C odific ad as
* c od ifiPub
Publicac ion<< P ro fesor >>
e s u na es una
es una es una
*
*
+ autorPor *
+ autorDe *
autores
1..* 1..1
+ tipificadaC omo
tipificac ión
+ ti pif ica
1..* 1..1
Figura 3.20: Diagrama de clase para el control de las Publicaciones
hechas por Profesores del Departamento de Computación.
5) Manejo de Eventos:
+departamentos
Persona<<Profesor>>
Escuela Departamento1..1 1..51..1
+adscritoA1..5
adscri pc ión
Estudiante
es una
Evento<<Profesor>>
1..3
*
1..2
** *
Profesor<<Profesor>>
es una
**
EventoOrg anPorEsc
+EscOrganizaEventos
+OrganizadosPorEsc
1..3
*
EventoOrganiPorDep
+DepOrganizaEventos
+OrganizadosPorDepart
1..2
*participa
+par tic ipo +hayParticipantes
* * asisten
+asiste+asistidoPor
**
Figura 3.21: Diagrama de clases para el control de Eventos asistidos por profesores y
estudiantes del Departamento de Computación.
Reconocimiento
Revisión Bibliográfica
121
6) Manejo de Datos Administrativos:
Suplentes<<Asociación>>
Jefe<<Profesor>>
Permisos<<Profesor>>
1..1
0..*
+aprueba1..1
+aprobadoPor0..*
aprobacion
MateriaDictada<<Asociación>>
Profesor<<Profesor>>
es un
0..*
1..1
MateriaSec<<Profesor>> 0..* 1..3
1..*1..3
sol ici tan
+solicita
+solicitadoPor
0..*
1..1
+dictadaPor+dicta
1..*1..3
+suplenciaPor +suplenteDe0..* 1..3
Figura 3.22: Diagrama de clases para el control de los Permisos solicitados
por los profesores del Departamento de Computación.
PtoTratado<<Profesor>>
SecretariaDepartamento
1..11..1
+esSec retariaDe
1..1
+secretaria
1..1 Secretaria
Profesor<<Profesor>>
1..*
1..1
+laboranEn
1..*
+laboran1..1
labora
Escuela1..1
1..5+departamentos
1..1 +adscritoA
1..5adscri pción
1..1
1..1
dirección
+dirigidoPor
+dirige
1..1
1..1
Jefe<<Profesor>>
1..1
1..1
+esJefeDe1..1
+Jefe1..1
jefatura
es un
ReuniónDpto<<Profesor>>
1..1*
+tieneAgenda
1..1
+esAgenda
*Agenda
5..n
0..*
+asis tidoPor
5..n
+asiste0..*
asistencia
1..*
1..1
dirige
+diri gidaPor
+dirige
1..*
1..1
Figura 3.23: Diagrama de clases para el control de las Reuniones del
Departamento de Computación.
Reconocimiento
Revisión Bibliográfica
122
La tabla 3.6 muestra las funciones y procesos básicos del sistema de actividades del
departamento y las entidades que intervienen en la ejecución de estos procesos.
Funciones Procesos Básicos Tipo de Entidad
Manejo de
recursos
humanos
Profesores Control de datos personales: Persona, Profesor, Jefe, Departamento.
Control de datos curriculares: Profesor, ReconocEspeciales, Estudios, SociedadesCP,
Cursos, Proyectos, Cargos, ActividadesDeExtensión,
GrupoDeInvestigación.
Control de carga laboral: Profesor, MateriaDictada, Horario, Materia, MateriaSec,
Laboratorio, Preparador,
BecaTrabajo,ProyectoDeGrado, Pasantias.
Control de planes e informe de
actividades:
Profesor, InformedeActvRealizadas, Cargo,
PlandeActvPorRealizar, Baremo, PuntosAHora,
CargoAdmAcad, PublicacionesEquivalentes.
Estudiantes Control de datos personales: Persona, Estudiante, Departamento.
Control de datos curriculares: Estudiante, HojaDeVida, Cursos, Escuela,
ReconocEstudiantes.
Control de datos académicos: Materia, MateriaSec, LabMatSec,
Cursa, CursaLab, Horario.
Manejo de
recursos
humanos
Preparadores Control de concursos: Persona, Estudiante, Preparador, Departamento
Control de la carga laboral: Preparador, MateriaSec, LabMatSec, Preparaduria,
PreparaduriaLab, Laboratorio, Profesor.
Beca Trabajos Control de datos administrativos: Persona, Estudiante, Beca Trabajo, Departamento.
Control de la carga laboral: Beca Trabajo, Profesor.
Pasantes
Externos
Control de datos personales: Persona, PasanteExterno, Departamento.
Control de datos académicos: PasanteExterno, Persona, Cotutor, Profesor.
Control de la carga labora: PasanteExterno, Profesor, Cotutor.
Cotutor
Externo
Control de datos personales: Persona, Cotutor.
Control de datos académicos: Cotutor, ProyectoDeGrado, Pasantias, Industriales
Manejo de información
académica
Control de las asignaturas Materia, MateriaSec, Semestre, Horario,
MateriaDictada, Departamento.
Control de proyecto de grados Estudiante, Materia, MateriaSec, Cursa, Cotutor,
ProyectoDeGrado, Profesor, Departamento.
Control de pasantías Estudiante, Cursa, MateriaSec, Materia, Pasantias,
Industriales, Investigación, Profesor, Cotutor,.
Funciones Procesos Básicos Tipo de Entidad
Manejo de recursos
Control de equipos Equipo, Solicitud, Estudiante, Secretaria, Profesor,
Departamento.
Reconocimiento
Revisión Bibliográfica
123
materiales Control de laboratorios Laboratorio, Departamento, Horario, PreparaduriaLab,
Preparador.
Manejo de eventos
Control de eventos hechos por
profesores
Eventos, Escuela, Departamento, Profesor.
Control de eventos hechos por
estudiantes
Eventos, Escuela, Departamento, Estudiante.
Manejo de publicaciones
Control de publicaciones hechas
por profesores
Publicacion, Profesor, ActadeEvento, Evento, Revistas,
Libro, Articulo Informe/Monografía, Capitulo,
PublicacionesEquivalentes,
Departamento.
Control de publicaciones hechas
por estudiantes
Publicacion, Estudiante, ActadeEvento, Evento,
Revistas, Libro, Articulo Informe/Monografía, Capitulo,
Departamento.
Manejo de datos
administrativos
Control de permisos Profesor, Jefe, Permisos, Suplentes, MateriaSec,
MateriaDictada.
Control de reuniones del
departamento
ReunionDpto, PtoTratado, Jefe, Profesor,
Departamento, Escuela, Secretaria.
Tabla 3.6: Tipo de entidades presentes en los procesos del
sistema de actividades.
3.2.6 Requerimientos de Operación y Configuración:
Los requerimientos de equipos de computación son los siguientes:
Servidor:
• 1 Computador con procesador Pentium 600 Mhz o superior,
• 128 Mbytes de memoria RAM,
• Disco duro con espacio libre de 2Gbyte o más,
• Monitor Super VGA,
• Unidad de disco 3 1/2
• Unidad CD - ROM
• Tarjeta de red,
• 1 teclado,
Reconocimiento
Revisión Bibliográfica
124
• 1 ratón,
• 1 impresora.
Clientes: Una o más computadoras conectadas en red con el servidor con los
siguientes componentes:
• Procesador Pentium 300 Mhz o superior,
• 64 Mbytes de memoria RAM,
• Disco duro con espacio libre de 300 Mbytes o más,
• Monitor Super VGA
• Unidad de disco 3 ½,
• Tarjeta de red,
• 1 teclado,
• 1 ratón
• 1 impresora.
Los requerimientos de sistemas operativos y programas de aplicación
son los siguientes:
Plataforma sobre el cual se ejecuta el sistema:
Servidor: Windows NT Server o Windows 2000 Server.
Clientes: Unix, Pc o Mac.
JDK (Java Developer Kit) 1.2 o 1.3: corre la aplicación sin que
sea necesario tener instalado el VisualAge 3.02 y realiza la
conexión con la base de datos.
Sybase Anywhere 6.0: es el manejador de base de datos
relacional que administra los datos del sistema.
Reconocimiento
Revisión Bibliográfica
125
3.3 DISEÑO PRELIMINAR DEL SISTEMA:
Esta sección especifica la arquitectura utilizada para el diseño del Sistema
de Información del Departamento de Computación (SIDECOM), así como la
integración del sistema creado para el control de las actividades de los profesores
del departamento [Quero, 2001] con el de los estudiantes relacionados a esta
unidad.
3.3.1 Diseño de la Arquitectura del Sistema de Información:
La arquitectura empleada para la construcción de éste sistema de
información está basada en el modelo para aplicaciones cliente/servidor16. Este
tipo de arquitectura brinda una gran flexibilidad para desarrollar la interfaz del
usuario, dado que se puede crear independiente del servidor de datos. De aquí
que se permite guardar la información en un servidor central, que contendrá la
base de datos bajo un sistema operativo Windows NT Server, y podrá ser
consultada y manipulada desde computadoras (clientes) con plataformas
diferentes, que estarán conectadas con el servidor. Este modelo de
cliente/servidor es llamado arquitectura de dos capas, cuyas aplicaciones son
ejecutadas sobre el cliente, y dado el caso, sobre el servidor. Puesto que la
interfaz del usuario es responsabilidad del cliente, el servidor tiene más recursos
de computación para analizar preguntas y diseminar información.
La figura 3.24 ilustra el modelo Cliente/Servidor utilizado. Se puede
observar el nivel del servidor y de los clientes respectivamente que están
conectados bajo un sistema de red local.
16 Consultar el capítulo 2, sección 2.1.2.3: Sistemas Cliente/Servidor
Reconocimiento
Revisión Bibliográfica
126
Figura 3.24: Modelo Cliente/Servidor utilizado.
Los clientes harán uso de la base de datos para recuperar y respaldar la
información que necesiten, haciendo uso del programa de aplicación desarrollado.
En el servidor se ejecutan las tareas fundamentales de bloqueos de los registros
de la base de datos, usados por dichos clientes y da respuesta a las consultas
realizadas. Además, el servidor puede actuar también como cliente.
Paralelamente a este proyecto, que analiza, construye e implementa un
sistema de información para el control de las actividades de los estudiantes
relacionados con el departamento, se desarrolló un sistema de información
encargado del control de las actividades que realizan los profesores de la misma
unidad [Quero, 2001]. Debido a que existen entidades comunes entre estos dos
sistemas y que es necesario mantener la consistencia de los datos y la no
redundancia de la información, se decidió unir en una sola, las bases de datos
desarrolladas para cada uno de ellos. Algunas de las entidades comunes a las dos
bases de datos fueron: Persona, Profesor, Publicaciones, Eventos y Materia, entre
otras.
BD Servidor
Cliente 1 Cliente 2 Cliente 3 Cliente n
Preguntas
Respuestas
................
Red Local
Reconocimiento
Revisión Bibliográfica
127
La integración de éstos sistemas se realizó mediante el acople de los
esquemas parciales desarrollados, por cada uno de los procesos del sistema de
actividades del departamento y la obtención del esquema conceptual de la base
de datos final a utilizar por ambos sistemas, todo este procedimiento es explicado
con detalle en la siguiente sección. Además, la aplicación final desarrollada
contiene también los dos sistemas de información, dado que resultaría poco
práctico la utilización de dos aplicaciones separadas con conexión a la misma
base de datos para acceder información que ambas necesitan. Por ende, el
Sistema de Información para el control Académico, de Investigación y Extensión
del Departamento de Computación, SIDECOM, presenta el siguiente contexto:
Figura 3.25: Contexto de SIDECOM.
3.3.2 Diseño Conceptual de la Base de Datos:
En la sección anterior se construyeron los diagramas de clases de las actividades
que el departamento realiza detallando las entidades utilizadas, sus atributos y las
relaciones existentes entre ellas. Esta sección presenta el diseño de los esquemas
parciales del sistema y la integración de éstos esquemas para la construcción del
diagrama conceptual final de la base de datos.
3.3.2.1 Diseño de los Esquemas Parciales del Sistema:
Para la concepción de los esquema parciales del sistema, se preintegran
los diagramas de clases relacionados entre sí, desarrollados por cada proceso de
SIDECOM
Profesores Estudiante Administrativ
Reconocimiento
Revisión Bibliográfica
128
las funciones encontradas en el sistema de actividades del departamento,
siguiendo el siguiente orden de esquemas:
1) Esquema parcial para el control de las actividades académicas del
departamento (fig. 3.26).
2) Esquema parcial para el control curricular y las actividades de extensión
de profesores y estudiantes del departamento (fig. 3.27).
3) Esquema parcial para el control de las actividades de investigación de
los profesores y estudiantes del departamento (fig. 3.28).
4) Esquema parcial para el control de las actividades administrativas que
involucran profesores y estudiantes del departamento (fig. 3.29).
Las tabla 3.7 muestra las entidades utilizadas en cada uno los
esquemas:
Esquema Parcial
para el Control
Académico
Esquema Parcial para el
Control Curricular y
Actividades de Extensión
Esquema Parcial para el
Control de Actividades de
Investigación
Esquema Parcial para el
Control de Actividades
Administrativas
Persona Persona Persona Persona Profesor Profesor Profesor Profesor
Estudiante Estudiante Jefe Estudiante Preparador Cursos Secretaria Publicación
Cotutor ReconocEspeciales Estudiante PublicacionesEquivalentes Materia Estudios PasanteExterno ActadeEventos
MateriaSec SociedadesC_P BecaTrabajo Evento LabMatSec ReconocEstudiantiles Laboratorio Revista Semestre ActividadesDeExtension Equipo Libro Horario HojaDeVida Solicitud ArticuloActa
MateriaDictada Escuela Articulo ProyectoDeGrado Departamento Capitulo
Pasantias Financiamiento Informe/Monografía Industrial Permisos GrupoDeInvestigacion
Investigación Suplentes Proyectos Cursa InformedeActvRealizadas
CursaLab PlandeActvPorRealizar Preparaduría ReunionDpto
PreparaduriaLab PtoTratado Cargos CargosAdmAcadf Baremo PuntosAHoras
Tabla 3.7: Entidades Utilizadas para la Construcción de los
Reconocimiento
Revisión Bibliográfica
129
CAPÍTULO 4: IMPLEMENTACIÓN DEL SISTEMA
Este capítulo especifica la construcción e implementación de la base de
datos del sistema planteado y los módulos que la manipulan a través de la interfaz
gráfica usuario-sistema diseñada, y se escriben y prueban los códigos de los
programas que conforman el sistema global.
4.1 IMPLEMENTACIÓN DE LA BASE DE DATOS:
En principio, la base de datos fue construida a partir del esquema relacional
diseñado en el capítulo anterior y fue implementada en la herramienta
PowerDesigner 8.0 del paquete Sybase Anywhere 7.0 [int-3]. Esta herramienta
permite la generación de los scripts que forman procesos en bloques de
comandos SQL agrupados y que realizan las peticiones al SMBD.
En la figura 4.1 vemos la representación gráfica del modelo relacional,
opción que ofrece el PowerDesigner y que permite chequear el orden correcto de
las tablas, columnas, tipo de datos, asociaciones, claves primarias y foráneas,
multiplicidad y demás componentes y especificaciones del modelo propuesto.
A partir del modelo relacional chequeado, utilizamos la opción
GenerateDataBase del mismo PowerDesigner para construir los archivo.sql y
archivo.trg. Estos archivos contienen las tablas SQL que permiten desplegar los
resultados producidos con la conexión a la fuente de datos y los triggers17 que son
invocados automáticamente siempre que haya un intento en insertar y/o eliminar
y/o actualizar los datos en la tabla asociada. La creación de estos archivos inicia el
proceso de construcción de la base de datos definitiva.
17 Los triggers son segmentos de código de SQL asociados con una tabla.
Reconocimiento
Revisión Bibliográfica
130
Figura 4.1: Representación gráfica del modelo relacional
hecha en la herramienta PowerDesigner.
La creación de las tablas en SQL se lleva a cabo mediante la utilización de los siguientes comandos:
• CREATE TABLE tabla(
columna_1 tipoDeDato [valorPorDefecto][restricciones] );
donde tabla expresa el nombre de la tabla que va a crearse y entre paréntesis
se detallan las columnas que la van a constituir. Por ejemplo, la tabla creada
para la entidad Estudiante se señala en la figura 4.2:
/*====================================================*/ /* Table : ESTUDIANTE */
Reconocimiento
Revisión Bibliográfica
131
/*====================================================*/
create table ESTUDIANTE (
IDPERSONA char(5) not null, FECHANAC smalldatetime PAISNACIMIENTO varchar(30) NACIONALIDAD char(2) FECHAINGULA smalldatetime FECHAEGREULA smalldatetime DIRECCHAB varchar(128) EMAIL varchar(24) TELHAB varchar(16) CI char(10) primary key (IDPERSONA) );
Figura 4.2: Comando CREATE TABLE usado en
la entidad Estudiante.
• CREATE [UNIQUE] INDEX nombreDelIndice GN
Tabla (columna1 [orden1]……..columnaN[ordenN]) );
Los índices son elementos que permite acceder a los datos de una tabla en forma más rápida y proporcionan a la base de datos la posibilidad de ordenar sus búsquedas. El modificador UNIQUE especifica que no se admitirán dos filas en las que la columna o columnas que componen la clave del índice sean iguales. En el caso de la entidad Estudiante, la clave idPersona no puede poseer dos valores como vemos en la figura 4.3:
/*====================================================*/ /* Index: INDEX_3 */ /*====================================================*/ create unique index INDEX_3 on ESTUDIANTE ( IDPERSONA ASC);
Reconocimiento
Revisión Bibliográfica
132
Figura 4.3: Comando CREATE INDEX usado en la
entidad Estudiante.
• DROP INDEX y DROP TABLE:
Estas sentencias se utilizan para eliminar físicamente los índices y las tablas
respectivas. La figura 4.4 nos muestra la utilización de estos comandos en la
entidad Estudiante:
if exists(select 1 from sys.sysindex I, sys.systable T where I.table_id=T.table_id and I.index_name='INDEX_3' and
T.table_name='ESTUDIANTE') then drop index ESTUDIANTE.INDEX_3
end if;
if exists(select 1 from sys.systable where table_name='ESTUDIANTE' and table_type='BASE') then
drop table ESTUDIANTE end if;
Figura 4.4: Comandos DROP INDEX y DROP TABLE usandos
en la entidad Estudiante.
Las figuras 4.5 y 4.6 muestran la forma de crear los archivos anteriormente
mencionados en el PowerDesigner y que fueron llamados crebasobdc.sql
creatrg.trg:
Reconocimiento
Revisión Bibliográfica
133
Figura 4.5: Opción para generar el archivo crebasobdc.sql
en el PowerDesigner.
Figura 4.6: Opción para generar el archivo creatrg.trg
en el PowerDesigner.
Reconocimiento
Revisión Bibliográfica
134
Una vez creados los archivos sql y trg, éstos habilitan la construcción de
una base de datos que contendrá tablas y columnas vacías. Este procedimiento
puede ser realizado por medio de la opción CreateDataBase del Manage Adaptive
Server Anywhere18. En nuestro caso, el archivo conformado por la base de datos
fue llamado Tesis.db. La figura 4.7 nos muestra la forma de llevar a cabo el
procedimiento descrito.
Luego de construirse la base de datos, se debe realizar la conexión con el
origen de datos ODBC19, cuya función es la de permitir efectuar peticiones sobre
la misma desde una aplicación [Quero, 2001]. Para esto, podemos hacer uso del
recurso ODBC DataSourse Administrator del Sybase Central que establece la
conexión reseñada. La figura 4.8 señala la pantalla donde el Administrador Central
del Sybase inicia este procedimiento.
18 del paquete del Sybase Anywhere 7.0 19 Consultar la sección 2.6.1: Conectividad Abierta de Bases de Datos (ODBC), del capítulo 2.
Figura 4.7: Creación de la Base de Datos
Reconocimiento
Revisión Bibliográfica
135
Figura 4.8: Conexión ODBC.
A su vez, el Sybase Central nos permite seleccionar el driver de la base de
datos a utilizar. Este driver requiere de la configuración del ODBC a través de la
identificación del administrador de la base de datos, la creación de un servidor y la
localización del archivo que contiene la base de datos vacía, procedimiento que
concluye con la conexión al origen de datos. Las figuras 4.9 y 4.10 muestran al
Adaptive Server Anywhere 7.0 como el driver a utilizar y la forma de configurarlo
para completar la conexión.
Reconocimiento
Revisión Bibliográfica
136
Figura 4.9: Selección del Origen de Datos.
Figura 4.10: Configuración del ODBC para la conexión final
Reconocimiento
Revisión Bibliográfica
137
Así pues, al conectarse con el origen de datos, los script de las tablas
creadas y encontradas en los archivos crebasodbc.sql y creatrg.trg deben ser
ejecutados por medio del Interative SQL del Sybase Central,el cual finalizará con
él proceso de creación de la base de datos. La figura 4.11 muestra la base de
datos vacía final.
Figura 4.11: Representación de la Base de Datos final.
4.2 CODIFICACIÓN E IMPLEMENTACIÓN DEL DISEÑO DE PROGRAMAS DE SIDECOM:
SIDECOM ha sido desarrollado en forma de aplicación utilizando el lenguaje de programación orientado a objetos Java, debido a numerosas ventajas que trae consigo como el manejo por sí mismo de la memoria y el tipo de enlace que utiliza.
El ambiente Java utilizado para la construcción del sistema fue el IBM VisualAge
3.02 EnterpriseEdition [int-4], debido a que se quiso conservar, tanto la interfaz desarrollada por Quero, como parte de la programación implicada en ella. VisualAge es
Reconocimiento
Revisión Bibliográfica
138
distribuido gratuitamente por la red y es un ambiente visual integrado que apoya el ciclo completo del desarrollo de programas en Java, permitiendo diseñar la interfaz del usuario, especificar la conducta de sus elementos y definir la relación entre la interfaz construida y el resto de su programa. A su vez, este paquete maneja sus programas a través de la jerarquía representada en la tabla 4.1 a continuación:
Componentes del VisualAge Para el manejo de Programas
Detalle
Proyectos Puede crear un nuevo proyecto que contendrá
todos los paquetes necesarios.
Paquetes Son familias de clases.
Clases: Están representadas por los distintos tipos de
clases definidas por el usuario utilizando la
sintaxis respectiva del lenguaje.
Métodos Cada clase contiene métodos u operaciones
que le permite llevar a calo las acciones
requeridas por el sistema.
Tabla 4.1: Jerarquía de los componentes de VisualAge 3.02
para el manejo de programas.
El proyecto definido en VisualAge para SIDECOM fue llamado IntegraciónTesis que a su vez
contiene los paquetes TesisBean, TesisClases y TesisGUI, como apreciamos en las figuras 4.12 al 4.14:
Reconocimiento
Revisión Bibliográfica
139
Figura 4.12: Paquete TesisBean del proyecto IntegracionTesis
creados en VisualAge 3.02
Figura 4.13: Paquete TesisClases del proyecto IntegraciónTesis
creados en VisualAge 3.02
Reconocimiento
Revisión Bibliográfica
140
Figura 4.14: Paquete TesisGUI del proyecto IntegraciónTesis
creado en VisualAge 3.02
Los paquetes definidos anteriormente presentan las siguientes clases y
funcionalidad respectiva:
• TesisBean: Este paquete proporciona los beans20 que definen los
componentes reusables del software. Posee tres clases: LlenarChoice,
TextoLimitado y Tokenizer. La clase TextoLimitado, por ejemplo, permite
colocar en todas las pantallas un TextField limitado a un valor específico
definido por el constructor de esa clase.
20 definido por Sun Microsystems como un modelo de componente reusable, portable e independiente de cualquier plataforma.
Reconocimiento
Revisión Bibliográfica
141
• TesisClases: Este paquete contiene las tres clases más importantes del
sistema: DataBase, DESenc y PropertiesTest, explicadas a continuación.
o Clase DataBase: Maneja los métodos que moldean al compor-
tamiento del programa. La tabla 4.2 resume éstos métodos:
Método Implantado Función que ejerce
Actualizar(java.lang.String sql) Actualiza, modifica o inserta valores en la base de datos.
Consulta(java.lang.String sql) Realiza una consulta o búsqueda en la base de datos.
InitDataBase() Inicializa la base de datos.
CloseDataBase() Cierra la conexión con la base de datos.
Main() Método de prueba.
Tabla 4.2: Métodos implantados en la clase DataBase
del paquete TesisClases.
Este sistema utiliza una conexión de tipo Puente ODBC-JDBC21 entre la
aplicación y la base de datos remota dado que el SMBD utilizado, Sybase
Anywhere 7.0, sólo soporta controladores ODBC que son los encargados de
interactuar con la base de datos a través de la red local.
La clase DataBase crea la conexión con la base de datos cargando el driver
del puente ODBC-JDBC y enviando como parámetros la clave y la contraseña
asignados al administrador de la base de datos. Se presentan a continuación el
código hecho para el constructor de la clase DataBase y los métodos implantados
en ella a través de las figuras 4.15 al 4.20:
21 Consultar 2.6.2: Conectividad de Base de Datos de Java (JDBC):
Reconocimiento
Revisión Bibliográfica
142
Constructor de la Clase DataBase: /**Esta clase crea una conexión con la base de datos * @author: Ana L. Montes P. */
import java.sql.*; import java.io.*; import java.net.*; import java.util.*;
public class DataBase {
private String userName = null; private String password = null; private Connection connection = null; private Vector connections = null;
/** * Construye una nueva DataBase. *@param userName El login del usuario a utilizar *@param password El password del usuario */
public DataBase(String userName, String password) { this.userName = userName; this.password = password; connections = new Vector();}
Figura 4.15: Código del Constructor de la Clase DataBase. Método Actualizar(String sql):
/** * Actualiza, modifica o inserta valores en la base de datos *@param sql El sql a utilizar */
public void actualizar(String sql) throws Exception { Statement st = connection.createStatement(); st.executeUpdate(sql);
}
Figura 4.16: Código del método Actualizar().
Reconocimiento
Revisión Bibliográfica
143
Método Consultar(String sql):
/**
* Realiza una consulta o búsqueda en la base de datos *@param sql El sql a utilizar *@return El ResultSet con el resultado */
public ResultSet consultar(String sql) throws Exception { Statement st = connection.createStatement(); ResultSet rs = st.executeQuery(sql); return rs;
}
Figura 4.17: Código del método Consultar().
Método InitDataBase():
/**Inicia la base de datos. Este método carga el driver del puente * JDBC-ODBC y crea la conexion*/ public void initDataBase() throws Exception {
// Cargar el driver Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); // Crear la conexion connection =DriverManager.getConnection("jdbc:odbc:TESIS",
userName, password);}
Figura 4.18: Código del método InitDataBase().
Método CloseDataBase():
/** * Cierra la conexion con la base de datos */
public void closeDataBase() throws SQLException { connection.close();
}
Figura 4.19: Código del método CloseDataBase()
Reconocimiento
Revisión Bibliográfica
144
Método Main():
/** public static void main(String[] args) { try { DataBase dataBase = new DataBase("dba", "sql"); dataBase.initDataBase(); System.out.println("Connected !!!!!"); ResultSet rs = dataBase.consultar("select dependencia from Cotutor"); System.out.println("Got ResultSet !!!!!"); rs.close();
dataBase.actualizar("insert into Persona values('abc', 'test', 'a', 'as', 'cc', 'asw')");
dataBase.closeDataBase(); }
catch (Exception e) { e.printStackTrace(); } }
}
Figura 4.20: Código del método Main().
o Clase DESenc: Esta clase posee los métodos estáticos que cifran y
verifican las contraseñas utilizada por los usuarios que ingresan al
sistema. Así pues, éstos métodos utilizan conceptos básicos de
Criptografía. La tabla 4.3 resume los métodos que esta clase:
Método Implantado Función que ejerce
DESencrypt(java.lang.String mensaje, byte s) Cinfra un mensaje.
DESdesencrypt((java.lang.String mensaje, byte s) Verifica un mensaje cifrado.
Main(java.lang.String[] args) Es un método de prueba.
Tabla 4.3: Métodos implantados en la clase DESenc
del paquete TesisClases.
Reconocimiento
Revisión Bibliográfica
145
Los orígenes de la criptografía se remontan a la antigua Roma. El
Emperador Julio Cesar cifraba sistemáticamente sus mensajes de guerra para que
estos no pudiesen ser entendidos si caían en manos enemigas. Durante siglos,
hasta la llegada de la computación, la tendencia de la criptografía fue a utilizar
claves muy cortas y algoritmos sumamente complejos y secretos. En la actualidad,
se hace más énfasis en la clave; sus características y dimensiones, debido a que
se da por sentado que es imposible mantener el secreto sobre los algoritmos
implicados en la criptografía [Mayol2000]. Existen dos tipos de cifrado:
Cifrado simétrico (o de clave privada): Se utiliza la misma clave para
cifrar y descifrar.
Cifrado asimétrico ( o de clave pública): Se utilizan claves diferentes e
interdependientes para cifrar y descifrar.
Los métodos empleados en la clase DESens pertenecen a la librería import
is.logi.crypto de Java que se basan en un clásico método de cifrado simétrico
denominado DES (Data Encription Standard). El DES utiliza claves de 52 bits, que
son muchos, pero que no los hacen ineficientes. A su vez, los métodos
DESencrypt y DESdesencrypt, empleados en éste proyecto, utilizan cadenas de 9
bytes lo que aumenta notablemente el tamaño de las claves y su utilidad al ser
aplicados.
Específicamente, el método DESencrypt cifra un mensaje (contraseña del
usuario) y lo inserta a la base de datos utilizando un parámetro aleatorio
denominado salt, que luego será empleado en la búsqueda de éstos mensajes; si
salt es igual a 0 el sistema generará uno al azar. El método DESdesencypt toma
un mensaje cifrado de la base de datos (contraseña del usuario) y un mensaje de
texto plano ingresado por pantalla que es también cifrado, y verifica si los dos
mensajes cifrados son iguales.
Reconocimiento
Revisión Bibliográfica
146
Las figuras 4.21 al 4.23 muestran el código del constructor de la clase DESenc y
de los métodos implantados en ella:
Método DESenc(String mensaje, byte s):
package TesisClases; import is.logi.crypto.*; import is.logi.crypto.hash.*; import is.logi.crypto.sign.*; import is.logi.crypto.keys.*; import java.util.Random; import java.io.*; import java.math.*;
/**Esta clase posee métodos estáticos para cifrar y verificar mensajes
* @author: Ana L. Montes P.*/ public class DESenc { *@param mensaje El mensaje a cifrar *@param s El salt *@return El mensaje cifrado */
public static byte[] DESencrypt(String mensaje, byte s) {
byte seed; if (s == 0) seed = (byte) ((Math.random() * 10) + 1); else seed = s; DESKey krum = new DESKey(seed); byte msg[] = new byte[8]; for (int i = 0; i < mensaje.length(); i++) { msg[i] = (byte) mensaje.charAt(i); } for (int i = mensaje.length(); i < 8; i++) { msg[i] = 0; } byte enc[] = new byte[8]; krum.encrypt(msg, 0, enc, 0); byte res[] = new byte[9]; res[0] = seed; for (int i = 1; i < 9; i++) { res[i] = enc[i - 1];} return res; }
Reconocimiento
Revisión Bibliográfica
147
Figura 4. 21: Código del constructor de la clase DESenc y el método DESenc().
Método DESdesencrypt(String mensaje, byte what[])
/** Verifica un mensaje encriptado. * Devuelve cierto si los mensajes encriptados son iguales. *@param mensaje El mensaje a verificar *@param what El mensaje encriptado *@return true si los mensaje son iguales, false de lo contrario*/ static public boolean DESdesencrypt(String mensaje, byte what[]) { byte seed = what[0]; byte res[] = new byte[9]; res = DESencrypt(mensaje, seed); return (( new String(res) ).equals( new String(what) ));
}
Figura 4.22: Código del método DESdesencrypt(). Método Main():
public static void main(String[] args) { String m = "prueba"; byte e[] = new byte[9]; e = DESencrypt(m, (byte) 100); System.out.println(DESdesencrypt("prueba", e));}
}
Figura 4.23: Código del método Main().
o Clase PropertiesTest: Esta clase utiliza el archivo System.properties
que localiza las propiedades de los usuarios definidos en el sistema.
Así mismo, crea un objeto de clase Properties que carga cada una
de las propiedades desde el archivo que las contiene dentro de éste
objeto. Es así como el sistema otorga la permisología corres-
pondiente a los usuarios que entran al sistema. La figura 4.24 señala
Reconocimiento
Revisión Bibliográfica
148
el código escrito para la clase PropertiesTest; las figuras 4.25 y 4.26
representan una parte de los archivos que utiliza dicha clase.
package TesisClases;
import java.util.*; import java.io.*; public class PropertiesTest {
/** * @param args java.lang.String[] */
public static void main(String[] args) { try { Properties properties = new Properties();
FileInputStream fis = new FileInputStream("Properties/JefeDepartamento.properties");
properties.load(fis); boolean bool = Boolean.getBoolean((String) properties.get("profesores.otro.actaseventos.imprimir"));
} catch (Exception e) { e.printStackTrace(); } } }
Figura 4.24: Código de la clase PropertiesTest. Archivo System.properties:
Archivo que contiene los tipos de usuarios definidos en el sistema y la
localización de sus propiedades.
usuario.jefedepartamento=JefeDepartamento.properties usuario.secretariadepartamento=SecretariaDepartamento.properties usuario.profesor=Profesor.properties usuario.estudiante=Estudiante.properties usuario.preparador=Preparador.properties usuario.becatrabajo=BecaTrabajo.properties usuario.visitante=Visitante.properties
Reconocimiento
Revisión Bibliográfica
149
Figura 4.25: Código del archivo System.Properties.
Archivo JefeDepartamento.properties: Este archivo contiene las propiedades o
privilegios otorgados al Jefe de Departamento; es decir, el control del despliegue
de datos22 que el sistema tiene sobre este usuario. Sólo se presentan los
privilegios que tiene en la categoría Básicos del Módulo Profesores:
profesores.otro.datospersonales.nuevos=false profesores.otro.datospersonales.guardar=false profesores.otro.datospersonales.actualizar=false profesores.otro.datospersonales.imprimir=false profesores.otro.datospersonales.consultar=true profesores.otro.estudios.nuevos=false profesores.otro.estudios.guardar=false profesores.otro.estudios.actualizar=false profesores.otro.estudios.imprimir=true profesores.otro.estudios.consultar=true profesores.otro.reconocimientos.nuevos=false profesores.otro.reconocimientos.guardar=false profesores.otro.reconocimientos.actualizar=false profesores.otro.reconocimientos.imprimir=true profesores.otro.reconocimientos.consultar=true
Figura 4.26: Codigo del archivo JefeDepartamento.properties.
• TesisGUI: Este paquete está compuesto por todas las clases que conforman la
interfaz gráfica del usuario. Sobre cada una de estas clases están construidas
las pantallas del sistema y encontramos allí todos los componentes visuales y
la codificación hechas en ellas. El frame principal llamado INTERFAZmain es el
encargado de hacer el llamado a las demás pantallas que estarán conformadas
por paneles y demás componentes visuales.
22 Consulta la sección 3.3.3: Diseño de la Interfaz Usuario-Sistema, en el capítulo 3, y el Anexo B.
Reconocimiento
Revisión Bibliográfica
150
Como ejemplo, el código de la figura 4.27 corresponde al del botón Entrar
encontrado en la página principal de SIDECOM y que permite hacer la
verificación de la clave y la contraseña del usuario en el momento en que
ingresa al sistema.
Este método, denominado jButtonEntrarAlSistemaPortada_ActionEvents()
toma el texto introducido como clave y contraseña y los busca en la base de
datos. La contraseña se encontrará cifrada y por la tanto, los métodos DESenc
y DESdesencrypt serán invocados para realizar la verificación de los mensajes.
Una vez verificados, el método cerrará la base de datos.
public void jButtonEntrarAlSistemaPortada_ActionEvents() { String login = ivjTextFieldClavePortada.getText();
String password = ivjTextFieldContrasenaPortada.getText(); ResultSet rs = null; boolean loginOk = false; try {
rs = dataBase.consultar("select (password, tipoPersona) from Persona where clave='" + login + "'");
while (rs.next()) { String userPassword = rs.getString(1);
loginOk = DESenc.DESdesencrypt(password, userPassword.getBytes()); }
} catch (Exception e) { // Show error dialog e.printStackTrace(); return; } finally { dataBase.closeResultSet(rs);} if (!loginOk) { // Show error window }
Durante la construcción e implementación de este sistema de información,
se han podido encontrar discrepancias significativas con respecto al sistema de
información originalmente desarrollado para el Departamento de Computación por
Figura 4.27: Código del método del botón Entrar
de la página principal de SIDECOM.
Reconocimiento
Revisión Bibliográfica
151
A. Quero [Quero2001]. Estas diferencia pueden ser especificadas de la siguiente
manera:
En la forma de presentar y acceder los sistemas: el primer sistema
consta de dos Applets que son invocados por una página Web; el
sistema desarrollado en este proyecto es una aplicación que puede ser
ejecutada en cualquier plataforma.
En los tipos de arquitecturas cliente/servidor empleados: el primer
sistema se conecta con la base de datos mediante el uso de un socket y
un puente ODBC-JDBC; el segundo sistema planteado, a pesar de que
mantiene conexiones con la base de datos por medio del puente ODBC-
JDBC, no utiliza sockets dado que emplea una arquitectura
cliente/servidor de sólo dos capas.
En la estructura de los paquetes, clases y métodos empleados para la
construcción de los sistemas, y por ende, en el estilo de programación
de las pantallas de la interfaz.
En la forma de asignar privilegios a los usuarios que ingresan al sistema.
En las técnicas de seguridad utilizadas para protege la clave de entrada
de los usuarios: el primer sistema comprende métodos básicos de
verificación de contraseñas y el sistema desarrollado aquí emplea
métodos de cifrado y descrifado.
Debido a esta diferencias, ha sido complicado aprovechar el código
generado por el sistema inicial y han imposibilitado la tarea de integrar estos
sistemas de información. Dado lo extenso del proyecto y las razones
anteriormente señaladas, se ha restringido la codificación de las pantallas a sólo
seis de ellas.
Las pantallas programadas de SIDECOM son las siguientes:
Reconocimiento
Revisión Bibliográfica
152
o Módulo Principal: Nueva Cuenta, Nueva Contraseña y Entrada al
Sistema.
o Módulo Profesores: Datos Personales, Estudios Realizados,
Proyectos de Grado.
4.3 VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA:
El objetivo de ésta sección es verificar si el sistema de información desarrollado en este proyecto trabaja correctamente y cumple con los requerimientos especificados en el diseño. Se Justifica la realización de esta fase al definir los dos conceptos más importantes en el proceso de pruebas del sistema: “Probar un programa es la acción de encontrar errores y fallas de construcción y de definición. Ubicar y corregir esos errores, es la actividad denominada depuración de programas” [Barrios95].
Las pruebas realizadas a SIDECOM se han llevado a cabo a lo largo del
desarrollo de la aplicación y han permitido observar su comportamiento y verificar
la calidad y funcionalidad del sistema.
Las pruebas de lógica interna de cada módulo y de los programas que
conforman éste sistema se basaron en el criterio de Caja Negra; es decir, ante
ciertas entradas se obtienen salidas conocidas. De esta manera, las pruebas a los
módulos y programas del sistema fueron las siguientes:
• De validación del rango del dominio: esta prueba se basa en permitir la
entrada de datos sólo dentro del dominio definido para cada campo en la
base de datos. Estas validaciones han sido realizadas desde el SMBD que
es el encargado de especificar los rangos de los datos en los campos
respectivos.
• De validación de campos vacíos: se ha verificado que el sistema pida
obligatoriamente llenar los campos no nulos en la base de datos antes de
realizar al almacenamiento de los registros.
Reconocimiento
Revisión Bibliográfica
153
• De validación de las restricciones: se ha comprobado que las restricciones
de integridad impuestas para algunos campos se cumplen y sólo permita la
entrada de los datos cuando se efectúen las condiciones establecidas.
• De interconexión entre módulos: se comprobó que la interconexión entre los
módulos que conforman el principal se ejecutan exitosamente.
• De utilización de la base de datos: se ha verificado que cada programa que
hace uso de la base de datos realiza exitosamente las llamadas a las
rutinas que la acceden.
• De interfaz: se comprobó qué tan amigable es el sistema con el usuario
dado que es una interfaz intuitiva y consistente.
Las pruebas hechas al sistema global fueron las siguientes:
• Prueba con datos reales: se ingresaron datos reales en el sistema lo que
verificó el flujo correcto de los datos que son introducidos por las pantallas
de SIDECOM. La figura 4.28 demuestra la prueba de datos reales realizada
en la pantalla Proyectos de Grado en el Módulo Profesores.
• De navegación en el sistema: se comprobó que todas las pantallas se
acceden correctamente desde los enlaces de donde son llamados.
• De control de concurrencia: se pudo verificar que la base de datos puede
responder a los accesos realizados por diferentes usuarios que hacen uso
al mismo tiempo de ella sin presentar inconvenientes en sus transacciones.
Esta prueba se llevó a cabo en una red local de dos computadoras donde
ambas sirvieron de clientes y una de ellas de servidor.
Reconocimiento
Revisión Bibliográfica
154
Figura 4.28: Prueba de datos reales en la pantalla Proyectos de Grado
en el Módulo Profesores.
Este capítulo ha señalado los pasos llevados a cabo para la construcción e
implementación de SIDECOM y ha mencionado algunas de las diferencias
encontradas entre este sistema de información y el inicialmente desarrollado para
el Departamento de Computación. Estas diferencias han dificultado la integración
de estos sistemas en uno, pero se ha determinado durante la fase de validación y
verificación del sistema, que SIDECOM cumple con los requerimientos espe-
cificados en el diseño.
Reconocimiento
Revisión Bibliográfica
155
CONCLUSIONES La realización de este proyecto de grado se basó en el desarrollo de un sistema
de información que apoya las actividades académicas, de investigación y extensión llevadas a cabo por los profesores y estudiantes que integran el Departamento de Computación.
Originalmente, como objetivo principal de este proyecto, se planteó integrar un
sistema de información que fue construido para apoyar las actividades realizada por los profesores del departamento [Quero2001], con un sistema nuevo que prestara apoyo a los procesos ejecutados por estudiantes relacionados a esta misma unidad. Esta integración no pudo ser efectuada por razones que expondremos más adelante, pero se cumplió con la ampliación del sistema, logrando así aumentar las aplicaciones y utilidades del sistema de información inicial.
Ante todo, se consideraron ampliamente los pasos que conforman la definición,
construcción e implementación de una sistema de este tipo. Mediante el uso de la metodología MEDIS-OO y la herramienta de modelado UML fue posible abstraer del sistema de actividades estudiado, los datos necesarios para definir con mayor precisión y orden los problemas de información presentes en la gestión del departamento, la especificación de los requerimientos y el planteamiento de las soluciones que permitieron construir un sistema de información con alta funcionalidad.
La base de datos fue construida e implementada utilizando el sistema
manejador de base de datos relacional Sybase Anywhere 7.0. Esta base de datos logró suplir todos los requerimientos de información en forma correcta, precisa y actualizada.
Por otra parte, este sistema de información fue elaborado en forma de
aplicación y, tanto la interfaz usuario-sistema, como la programación de los
módulos que la conforman, fueron construidos e implementados a través del
ambiente visual integrado IBM VisualAge 3.02 EnterpriseEdition que apoya el ciclo
completo del desarrollo de programas en el lenguaje de programación orientado a
objetos Java. La interfaz probó ser interactiva, sencilla, consistente y fácil de
manejar, logrando que el ingreso, flujo y salida de los datos se realizara sin ningún
inconveniente.
Se usó una arquitectura cliente/servidor de dos capas con conexión de tipo puente ODBC-JDBC entre la aplicación desarrollada y el sistema manejador de bases de
Reconocimiento
Revisión Bibliográfica
156
datos, lo que permite el acceso a la base de datos en forma concurrente al ser usado por varios usuarios al mismo tiempo desde diferentes computadoras conectadas en red al servidor donde se encuentra almacenada la base de datos.
Finalmente, las pruebas realizadas al sistema determinaron el funciona-miento correcto de sus módulos y de las transacciones hechas a la base de datos por los usuarios del sistema. Así pues, el planteamiento inicial de integrar los dos sistemas destinados a apoyar tanto las actividades de los profesores como las de los estudiantes del Departamento de Computación, no pudo desarrollarse debido a las siguientes razones:
• Diferencias en la forma de presentar y acceder los sistemas: el primer sistema consta de dos Applets que son invocados por una página Web; el sistema desarrollado en este proyecto es una aplicación que puede ser ejecutada en cualquier plataforma.
El sistema de información original utilizó una arquitectura cliente/servidor implementada a través de un socket; el sistema desarrollado en este proyecto no necesitó usar este tipo de arquitectura debido a que fue construido como una aplicación que utiliza conexiones más sencillas, y porque este cambio fue sugerido como recomendación en el proyecto de grado anterior.
Dado que ambos sistemas fueron diseñados, construidos e implementados en
forma separada, los dos presentan estilos de programación muy diferente y comportamientos distintos en las transacciones que realizan, lo que dificultó la posibilidad de integrarlos en uno.
Se encontraron diferencias en la forma de asignar privilegios a los usuarios que
ingresan al sistema y las técnicas de seguridad utilizadas que protegen la contraseña de entrada de los usuarios. El primer sistema comprende métodos básicos de verificación de contraseñas y, el sistema desarrollado aquí, emplea métodos de cifrado y descrifado basados en el método clásico de cifrado simétrico DES que garantiza la seguridad en el acceso de los usuarios al sistema.
Sin embargo, se consiguió unificar partes importantes entre ellos:
Debido a que existían entidades comunes entre estos dos sistemas y que era
necesario mantener la consistencia y la no redundancia de los datos, se decidió unificar en una sola, las bases de datos creadas para cada uno de ellos. La base de datos fue ampliada mediante el anexo de nuevas entidades al esquema original y se ejecutaron todos los procesos que conllevan a la creación de una nueva base de datos, como el modelo orientado a objetos de las entidades, la conversión al esquema relacional y la normalización del modelo conceptual.
Reconocimiento
Revisión Bibliográfica
157
La aplicación final, representada por la interfaz usuario-sistema, es el
resultado de la unificación de estos dos sistemas de información, dado que
resultaba poco práctico la utilización de dos aplicaciones separadas con
conexión a la misma base de datos para acceder información que ambas
necesitaban.
Así pues, el sistema de información desarrollado en este proyecto reúne los requerimientos exigidos por el usuario que permite la manipulación y actualización de los datos referentes a los procesos efectuados en el Departamento de Computación con mayor velocidad de repuesta en la búsqueda de información y la calidad esperada en la presentación de la misma.
Reconocimiento
Revisión Bibliográfica
158
RECOMENDACIONES
A partir de esta investigación, se proponen las siguiente recomendaciones
que han surgido como posibles líneas de acción y que llevadas a cabo permitirán
el mejoramiento funcional del sistema:
Se recomienda terminar la implementación del sistema con la programación
de las pantallas faltantes de los módulos de SIDECOM.
Es recomendable analizar el proceso de mantenimiento que este sistema
requiere y que facilitará al administrador del sistema de información
encontrar errores, corregirlos o simplemente modificar el modo en que se
ejecutan ciertas transacciones.
Se recomienda agregar la opción eliminar en los módulos del sistema. Esto
permitirá mantener en la base de datos sólo la información histórica más
relevante.
Se recomienda ampliamente la utilización de la metodología MEDÍS-OO
para desarrollar sistemas de información, dado que contiene todas las
distintas fases del ciclo de desarrollo, desde la definición del proyecto hasta
la implantación del sistema en la organización.
Se recomienda ampliar la utilidad de este sistema de información mediante
la incorporación de las actividades administrativas que maneja el
Departamento de Computación, lo que permitiría el apoyo a más áreas
funcionales dentro de esta unidad. Así mismo, otros departamentos
pudieran ser anexados al sistema con el fin de crear un sistema global
unificado que preste apoyo total a la Escuela de Sistemas.
Reconocimiento
Revisión Bibliográfica
159
Se recomienda también incluir también un Módulo de Auditoría que lleve el
registro de los eventos llevados a cabo en el sistema.
Es recomendable entrenar a los usuarios potenciales del sistema para que
sirvan de fuente informativa a los usuarios que por primera vez ingresan a él.
Reconocimiento
Revisión Bibliográfica
160
BIBLIOGRAFÍA
[Elm97] Elamsri, R Y Navathe, S. Sistema de Bases de Datos. Editorial
Addison-Wesley Iberoamericana. Segunda Edición. México.
1997.
[Int-1] Rational Software Corporation. Unified Modeling Language.
Version 1.0.. 1997.
http://www.rational.com/uml
[Int-2] Tutrial de Java.
http://java.sun.com
[Int-3] Tutorial del Sybase Anywhere 7.0
http://www.sybase.com
[Int-4] Tutorial del VisualAge 3.02
http://www-4.ibm.com/software/ad/smalltalk
[Mattison97] Rob Mattison. Understanding Database Management
Systems. Segunda Edición Mc Grw-Hill. 1997.
[Mon97b] MONTILVA, J. MEDSI-OO: An Object Oriented Method for
Designing Geographical Information Systems. Actas de la
conferencia SCI 1997.
Reconocimiento
Revisión Bibliográfica
161
[Mon97c] MONTILVA, J. Desarrollo de Sistemas de Información.
Universidad de Los Andes – Consejo de Publicaciones.
Segunda Edición. Venezuela. 1997.
[Mon97d] MONTILVA, J. MEDSI-OO: Una Metodología Orientada a
objetos para el desarrollo de sistemas de Información
Gerencial. Universidad de los Andes. Venezuela, 1997.
[Naughton96] Patrick Naughton. Manual de Java. Osborne / Mc Graw –Hill.
1996.
[Orf97] ORFALI, Robert, HARKEY Dan, EDWARDS Jeri. Cliente /
Servidor Guía de Supervivencia. Mc Graw Hill. Segunda
Edición. USA. 1997.
[Wehling97] Wehling, J., Bharat, V. Aproveche las noches con java.
Pretince-Hall Hispanoamericana, S.A. 1997
Reconocimiento