AMPLIACIÓN E INTEGRACIÓN DEL SISTEMA DE INFORMACIÓN …bdigital.ula.ve/storage/pdf/42302.pdf ·...

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


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


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


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


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


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


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


21

Anexo D: Documentación de los Programas de SIDECOM en

Java....................201

Reconocimiento


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


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


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


Reconocimiento


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


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


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


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


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


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


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


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


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


31

paquete

TesisClases..............................................................147

Tabla 4.3: Métodos implantados en la clase DESenc del paquete

TesisClases...........................................................................150

Reconocimiento


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


48

Figura 2.3: Cliente/servidor con Servidores Web

Reconocimiento


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


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


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


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


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


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


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


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


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


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


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


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


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

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


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


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


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

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


95


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.


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.


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


96


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


97


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


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


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


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


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


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


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.



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



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


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


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



Da Tutoría Industrial: Ofrece tutorías industriales a Proyectos de Grados y

Pasantías Industriales.

Reconocimiento


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


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

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>>


Reconocimiento

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>>

Figura 3.4: Diagrama de casos de usos para el control de las actividades

realizadas por el Profesor del Departamento de Computación.

Reconocimiento

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 >>

<> < >

< < 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


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


110


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


111


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


112


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


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

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


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


Figura 3.8: Diagrama de clases para el control de datos personales y curriculares

de los Profesores del Departamento de Computación.

Reconocimiento

115

PublicacionesEquivalentes<<Profesor>>

InformedeActvRealizadas<<Profesor>>

PlandeActvPorRealizar<<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


curriculares y académicos de los Estudiantes del Departamento de Computación.

Reconocimiento

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


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

117

2) Manejo de Información Académica:

prelaciónMateria<<Profesor>>

Semestre<<Profesor>>

Horario<<Profesor>>


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


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<>

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<>

es una

* 0..1

+ cotutorPor

*

+ escotutor

0..1C otut or PG

0 ..1

1..1

P ro fesor<>

*

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

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


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


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

119

+tiene

Horario<<Profesor>>Preparadur iaLab

<<Asociación>>

Preparador Departamento1..11..*

departCargoPrepa

+preparador+depACargo1..11..*


1..*

1..1

+asiste

1..*

+asistidoPor1..1

asistente

LabMatSec*

1..1

+prepaLabPor *

+prepaLabDe 1..1

*

1..1

ubicacion

+ubicadaEn

+seUbica

*

1..1


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< >

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


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

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


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<>

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


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

** *


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

121

6) Manejo de Datos Administrativos:

Suplentes<<Asociación>>

Jefe<<Profesor>>

Permisos<<Profesor>>

1..1

0..*

+aprueba1..1

+aprobadoPor0..*

aprobacion



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


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


Reconocimiento


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


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


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


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


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


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


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


Control de Actividades de

Investigación


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


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


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


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


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


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


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


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


136

Figura 4.9: Selección del Origen de Datos.

Figura 4.10: Configuración del ODBC para la conexión final

Reconocimiento


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


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


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


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


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


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


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


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


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

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


162

ANEXO A:

DIAGRAMA DE CLASES DINÁMICO INTEGRADO DE SIDECOM

Reconocimiento


163

Reconocimiento

AMPLIACIÓN E INTEGRACIÓN DEL SISTEMA DE INFORMACIÓN …bdigital.ula.ve/storage/pdf/42302.pdf ·...

Documents

Transcript of AMPLIACIÓN E INTEGRACIÓN DEL SISTEMA DE INFORMACIÓN …bdigital.ula.ve/storage/pdf/42302.pdf ·...