UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE … · Ilustración 7 : Librería Primefaces. ... IDE...

UNIVERSIDAD CENTRAL DEL ECUADOR

FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS

Y MATEMÁTICA

CARRERA DE INGENIRÍA INFORMÁTICA

SISTEMA DE GESTIÓN DE HORARIOS ACADÉMICOS PARA

LA UNIVERSIDAD CENTRAL DEL ECUADOR

TRABAJO DE GRADUACIÓN, PREVIO A LA OBTENCIÓN DEL TÍTULO

DE INGENIERO INFORMÁTICO.

AUTOR: Campoverde Ramos Hernán Oswaldo

TUTOR: Ing. Carrillo Flores René Alfonso, MSc

QUITO – ECUADOR

2015

ii

DEDICATORIA

Dedico el presente trabajo de graduación primero a Dios, ya que él ha sido el

principal artífice de tener junto a mí, a mi madre Martha Ramos y a mi padre Calixto

Campoverde, quienes con su sacrificio y ahínco me supieron guiar por buen camino

otorgándome el regalo más importante que ha sido la educación, inculcándome

buenos valores y dejándome la mejor herencia que me han podido dar, tampoco

dudaron de mis capacidades motivándome siempre a seguir adelante.

A mi hermano Marlon quien siempre ha estado a mi lado dándome su apoyo para

seguir adelante y no darme por vencido en cumplir mis objetivos.

iii

AGRADECIMIENTO

En primer lugar a Dios por darme salud y la oportunidad de tener a mis padres y

hermano a mi lado, cuidar a toda mi familia ya que para todos ellos está dedicado el

haber hecho realidad este sueño anhelado de ser un profesional.

Un agradecimiento a todos mis profesores quienes aportaron cada uno de ellos con

un granito de arena para convertirme en un buen profesional como ellos, a la

Universidad Central del Ecuador quien me acogió para poder instruirme ya que es un

excelente centro de educación superior y de la cual me siento muy orgulloso haber

formado parte.

A todos mis amigos, quienes nos conocimos a lo largo de este camino que han

formado parte de mi vida estudiantil día a día, me apoyaron de manera incondicional

en las buenas y malas, y con sus concejos me han ayudado a ser mejor persona y

profesional, gracias a todos ustedes, los llevo dentro de mi corazón.

Y a todas las personas que contribuyeron con su apoyo a lo largo de mi carrera

profesional.

iv

AUTORIZACIÓN DE AUTORÍA INTELECTUAL

v

CERTIFICADO TUTOR

vii

CALIFICACIÓN TRABAJO DE GRADUACIÓN

ix

CONTENIDO

DEDICATORIA ........................................................................................................ II

AGRADECIMIENTO ............................................................................................ III

AUTORIZACIÓN DE AUTORÍA INTELECTUAL ........................................... IV

CERTIFICADO TUTOR ......................................................................................... V

CALIFICACIÓN TRABAJO DE GRADUACIÓN ............................................ VII

CONTENIDO ........................................................................................................... IX

LISTA DE TABLAS ................................................................................................ XI

LISTAS DE ILUSTRACIONES ........................................................................... XII

RESUMEN ............................................................................................................. XIII

SISTEMA DE GESTIÓN DE HORARIOS ACADÉMICOS PARA LA

FACULTAD DE INGENIRÍA, CIENCIAS FÍSICAS Y MATEMÁTICAS,

CARRERA DE INGENIRÍA INFORMÁTICA ................................................. XIII

ABSTRACT ........................................................................................................... XIV

CERTIFICACIÓN DE TRADUCCIÓN .............................................................. XV

TITULO DEL TRADUCTOR ............................................................................. XVI

INTRODUCCIÓN ..................................................................................................... 1

CAPÍTULO 1 .............................................................................................................. 2

1. PRESENTACIÓN DEL PROBLEMA ................................................................. 2

1.1 Planteamiento del Problema .......................................................................... 2

1.2 Formulación del Problema ............................................................................. 2

1.3 Interrogantes de la Investigación ................................................................... 3

1.4 Objetivos de la Investigación .......................................................................... 3

1.5 Justificación .................................................................................................... 4

1.6 Alcance............................................................................................................ 4

1.7 Planteamiento de Solución ............................................................................. 6

CAPÍTULO 2 .............................................................................................................. 7

2. REVISIÓN BIBLIOGRAFICA ............................................................................ 7

2.1 Antecedentes ................................................................................................... 7

2.2 Fundamentación Teórica ................................................................................ 7

2.3 Hipótesis ....................................................................................................... 27

CAPÍTULO 3 ........................................................................................................... 28

3. MARCO METODOLÓGICO ............................................................................. 28

3.1 Diseño de la Investigación ............................................................................ 28

x

3.2 Diseño Experimental..................................................................................... 29

3.3 Ámbito de la Investigación .......................................................................... 29

3.4 Identificación de las Fuentes de Investigación ............................................. 29

3.5 Fase de Elaboración Análisis y Diseño ........................................................ 30

3.6 Requerimientos Específicos .......................................................................... 34

3.7 Casos de Uso ................................................................................................ 34

CAPÍTULO 4 ............................................................................................................ 65

4. DISEÑO DEL SISTEMA ................................................................................... 65

4.1 Definición de Arquitectura del Sistema ........................................................ 65

4.2 Determinación de las Herramientas tecnológicas........................................ 67

4.3 Presupuesto ................................................................................................... 78

4.4 Cronograma .................................................................................................. 79

CAPÍTULO 5 ............................................................................................................ 80

5. CONCLUSIONES Y RECOMENDACIONES.................................................. 80

5.1 Conclusiones ................................................................................................. 80

5.2 Recomendaciones.......................................................................................... 81

BIBLIOGRAFÍA ...................................................................................................... 82

TERMINOLOGÍA ..................................................................................................... 1

ANEXOS ..................................................................................................................... 3

A.- MANUAL DE USUARIO ......................................................................................... 3

Introducción .......................................................................................................... 4

B. MANUAL DE INSTALACIÓN .................................................................................. 18

xi

LISTA DE TABLAS

Tabla 1: Cuadro comparativo entre diferentes lenguajes de programación ............... 9

Tabla 2: Características de los lenguajes de programación Web. .............................. 9

Tabla 3: Cuadro comparativo entre los diferentes Servidores Web. ......................... 15

Tabla 4 : Descripción Actor Administrador SGHA. (Fuente Tesista) ....................... 37

Tabla 5 : Descripción Actor Docentes SGHA. (Fuente Tesista) ............................... 38

Tabla 6 : Descripción Actor Estudiantes SGHA. (Fuente Tesista) ............................ 39

Tabla 7: Descripción Caso Uso Administrador SGHA. (Fuente Tesista) ................. 41

Tabla 8 : Descripción Caso Uso Docente SGHA. (Fuente Tesista) .......................... 42

Tabla 9 : Descripción Caso Uso Estudiante SGHA. (Fuente Tesista) ...................... 43

Tabla 10 : Descripción Registro Usuario SGHA. (Fuente Tesista) .......................... 44

Tabla 11 : Descripción Registro Perfiles SGHA. (Fuente Tesista) ........................... 45

Tabla 12 : Descripción Registro Docentes SGHA. (Fuente Tesista) ......................... 46

Tabla 13 : Descripción Registro Horarios SGHA. (Fuente Tesista) ......................... 47

Tabla 14: Descripción Registro Aulas SGHA. (Fuente Tesista) ............................... 48

Tabla 15 : Descripción Registro Categoría SGHA. (Fuente Tesista) ....................... 49

Tabla 16 : Descripción Registro Asignaturas SGHA. (Fuente Tesista) .................... 50

Tabla 17: Descripción Caso Uso Consulta Docentes SGHA. (Fuente Tesista) ........ 52

Tabla 18 : Descripción Caso Uso Consulta Horarios SGHA. (Fuente Tesista) ....... 53

Tabla 19 : Descripción Caso Uso Consulta Aulas SGHA. (Fuente Tesista) ............. 54

Tabla 20 : Descripción Caso Uso Consulta Hora Docente. (Fuente Tesista)........... 55

Tabla 21 : Descripción Caso Uso Consulta Asignaturas. (Fuente Tesista) .............. 56

Tabla 22: Descripción Caso Uso Consulta Docentes. (Fuente Tesista) ................... 58

Tabla 23 : Descripción Caso Uso Consulta Horarios. (Fuente Tesista) ................... 59

Tabla 24 : Descripción Caso Uso Consulta Aulas. (Fuente Tesista) ........................ 60

Tabla 25 : Descripción Caso Uso Consulta Hora Docente. (Fuente Tesista)........... 61

Tabla 26 : Descripción Caso Uso Consulta Asignatura. (Fuente Tesista)................ 62

Tabla 27: Descripción de Entidad Alumnos. (Fuente Tesista) .................................. 70

Tabla 28 : Descripción de Catalogo Docente. (Fuente Tesista) ............................... 70

Tabla 29 : Descripción de Asignaturas. (Fuente Tesista) ......................................... 70

Tabla 30 : Descripción de Aulas. (Fuente Tesista) ................................................... 70

Tabla 31 : Descripción de Entidad. (Fuente Tesista) ................................................ 71

Tabla 32 : Descripción de Rol. (Fuente Tesista) ....................................................... 72

Tabla 33 : Descripción de Control de Horas. (Fuente Tesista) ................................ 72

Tabla 34 : Descripción de Detalle Catálogo. (Fuente Tesista) ................................. 73

Tabla 35 : Descripción de Docentes. (Fuente Tesista) .............................................. 74

Tabla 36 : Descripción de Estudios Docente. (Fuente Tesista) ................................ 74

Tabla 37 : Descripción Horario. (Fuente Tesista) .................................................... 75

Tabla 38 : Descripción de Horas Docente. (Fuente Tesista) .................................... 75

Tabla 39 : Descripción de Menú. (Fuente Tesista) ................................................... 76

Tabla 40 : Descripción de Rol Menú. (Fuente Tesista) ............................................. 76

Tabla 41 : Descripción tipo docente. (Fuente Tesista) .............................................. 77

xii

LISTAS DE ILUSTRACIONES

Ilustración 1: Arquitectura JEE6 ........................................................................................... 13

Ilustración 2: Etiquetas para definir plantillas. .................................................................... 19

Ilustración 3 : Define que la página utilice una plantilla. ..................................................... 19

Ilustración 4 : Pantalla .......................................................................................................... 19

Ilustración 5 : Clase Bean ..................................................................................................... 20

Ilustración 6 : Aplicación de los Bean. .................................................................................. 20

Ilustración 7 : Librería Primefaces. ...................................................................................... 21

Ilustración 8 : Ciclo de vida RUP. ......................................................................................... 23

Ilustración 9 : 3 UML. (Autoría Tesista) ............................................................................... 25

Ilustración 10 : Funciones del Administrador del Sistema. (Autoría Tesista)....................... 33

Ilustración 11 : Funciones del Docentes. (Autoría Tesista) .................................................. 33

Ilustración 12 : Funciones del Estudiantes. (Autoría Tesista) .............................................. 34

Ilustración 13 : Plantilla Descripción de Actores. (Fuente Internet) .................................... 35

Ilustración 14 : Plantilla Descripción Casos de Uso. (Fuente Internet) ............................... 36

Ilustración 15 : Diagrama Caso de Uso General. (Autor Tesista) ........................................ 40

Ilustración 16 : Diagrama Caso de Uso Administrador. (Autor Tesista) .............................. 43

Ilustración 17 : Diagrama Caso de Uso Docente. (Autor Tesista) ........................................ 51

Ilustración 18: Diagrama Caso de Uso Estudiante. (Autor Tesista) ..................................... 57

Ilustración 19 : Diagrama de secuencia gestión Administrador. (Autor Tesista) ................. 63

Ilustración 20 : Diagrama de secuencia gestión Admin/Docente. (Autor Tesista) ............... 63

Ilustración 21 : Diagrama de secuencia de Reportes. (Autor Tesista) .................................. 64

Ilustración 22: Diagrama de secuencia de Consultas. (Autor Tesista) ................................. 64

Ilustración 23 : Capa de Presentación. (Fuente Tesista) ...................................................... 65

Ilustración 24 : Capa de Negocio. (Fuente Tesista) .............................................................. 66

Ilustración 25 : Gestor de Base de Datos. ............................................................................. 67

Ilustración 26 : Administración GlassFish. ........................................................................... 68

Ilustración 27 : IDE NetBeans 8.0.2 ...................................................................................... 68

Ilustración 28 : Diagrama Entidad Relación. (Fuente Tesista) ............................................ 69

Ilustración 29 : Planificación ................................................................................................ 79

xiii

RESUMEN

SISTEMA DE GESTIÓN DE HORARIOS ACADÉMICOS PARA LA

FACULTAD DE INGENIRÍA, CIENCIAS FÍSICAS Y MATEMÁTICAS,

CARRERA DE INGENIRÍA INFORMÁTICA

El presente proyecto de tesis que aquí se presenta, tiene la finalidad de automatizar

los procesos que se lleven a cabo dentro de la Facultad de Ciencias Físicas y

Matemática para la generación de sus horarios académicos y los docentes puedan

impartir sus cátedras en las horas correspondientes, permitiendo agilizar el proceso

de generación de horarios y que estén disponibles en cualquier momento que se lo

requiera tanto para el docente como para el alumnado por medio de este sistema web.

El proyecto se basa en la construcción de una aplicativo web en Java, bajo la

especificación JEE6, Servidor Glassfish 4.1, Base de Datos PostgresSQL, se

especifica un esquema completo del sistema en cada una de sus etapas de

construcción, se ha realizado las correspondientes pruebas necesarias previas a la

puesta en producción del aplicativo.

DESCRIPTORES:

APLICACIÓN WEB / JAVA PARA NETBEANS / GENERADOR DE CODIGO

WEB / METODOLOGÍA UML / BASE DE DATOS POSTGREST / SERVIDOR

GLASSFISH

xiv

ABSTRACT

MANAGEMENT SYSTEM OF SCHEDULES ACADEMIC FOR THE


This thesis project presented here below, is intended to automate the processes that

take place within the Faculty of Physical Sciences and Mathematics to generate their

academic schedules and teachers to teach their classes in the hours corresponding,

allowing expedite the process of generation of schedules and available at any time to

be required for both the teacher and students through this web system.

The project is based on building a web application in Java, under the JEE6

specification, Glassfish Server 4.1, PostgreSQL Database, a complete diagram of the

system in each of its stages of construction, has made the appropriate tests specified

prior to the start of production of the necessary application.

DESCRIPTORS:

WEB APPLICATION / JAVA FOR NETBEANS / WEB CODE GENERATOR /

METHODOLOGY UML / POSTGREST DATABASE / GLASSFISH SERVER

xv

CERTIFICACIÓN DE TRADUCCIÓN

xvi

TITULO DEL TRADUCTOR

1

INTRODUCCIÓN

Hoy en día nos encontramos en la necesidad de la utilización de las tecnologías de la

información y comunicaciones existentes para una rápida y ordenada gestión de sus

procesos para poder acceder al beneficio de obtener información desde cualquier

lugar y a todo momento, brindando así un mejor servicio y bienestar a la sociedad.

La Facultad de Ciencias Físicas y Matemáticas de la Universidad Central del

Ecuador desde su existencia realiza un proceso sumamente necesario para el inicio

de sus actividades académicas como es la creación de los horarios de clase para la

cátedra que dictará el personal docente, el cual conlleva a realizar un análisis muy

minucioso de tres factores sumamente importantes como son la disponibilidad en

tiempo del docente, las materias que deben impartir y las aulas donde realizarán sus

cátedras.

La finalidad de este proyecto consiste en automatizar los procesos que se lleven a

cabo dentro de la Facultad de Ciencias Físicas y Matemáticas para la generación de

sus horarios académicos para dar un correcto seguimiento a los datos generados por

la herramienta implementada y crear una interface para que la información esté

disponible en cualquier momento y lugar que se lo requiera tanto para el docente

como para el alumnado.

2

CAPÍTULO 1

1. PRESENTACIÓN DEL PROBLEMA

1.1 Planteamiento del Problema

La Facultad de Ciencias Físicas y Matemáticas se encuentra realizando la

elaboración del horario académico de manera manual de una forma que para los

estándares actuales de tecnología puede calificarse como rudimentaria. De esta

manera la generación del horario no cuenta con una fuente centralizada de

almacenamiento ni un sistema que se acople a las necesidades de su actividad por lo

cual conlleva horas de mucho trabajo y esfuerzo en poder realizar el análisis para la

elaboración de los horarios que cumplan y se acoplen con los docentes y la

infraestructura que posee la institución.

A esto se suma el hecho que los docentes tienen distintos horarios para poder

impartir sus cátedras y esto conlleva a que el horario sea más complejo de realizarse

ya que se debe analizar la disponibilidad del docente y el aula para que no exista

cruce con otras materias y de ser así causaría el movimiento de todo el horario

generando que las personas encargadas de realizar el mismo vuelvan analizar las

posibles soluciones a generarse, este nuevo análisis ocupa mayor disponibilidad de

tiempo para el recurso asignado a realizar esta importante labor.

Por lo enunciado se puede entender que la implementación de un sistema informático

cubrirá las necesidades tecnológicas que la Facultad de Ciencias Físicas y

Matemáticas de la Universidad Central del Ecuador que como institución educativa

requieren de manera inmediata y además permitirá una mejor administración de los

docentes y su infraestructura.

1.2 Formulación del Problema

Principalmente con la implementación del sistema la Facultad de Ciencias Físicas y

Matemáticas manejará el proceso de acuerdo a los estándares de la tecnología actual.

La información de profesores, materias y aulas de la Facultad de Ciencias Físicas y

Matemáticas se manejará de forma centralizada permitiendo realizar los horarios

académicos de la mejor manera posible.

3

A partir del uso de un sistema que operará dentro de la red interna de la Facultad de

Ciencias Físicas y Matemáticas se agilitaran los procesos en la generación del

horario académico.

En lo que tiene que ver con la parte administrativa con el uso del sistema se podrá

manejar de forma adecuada una vez que se generen los horarios y estos sean los más

óptimos los mismo podrán ser enviados por correo a los docentes indicándoles su

horario académico para poder impartir su cátedra.

1.3 Interrogantes de la Investigación

A partir de la observación de la situación de la Facultad de Ciencias Físicas y

Matemáticas en cuanto al proceso en la creación de los horarios académicos se han

planteado las siguientes interrogantes:

- ¿De qué manera el Sistema de Gestión de Horarios Académicos cubrirá las

necesidades que una institución de esta índole necesita?

- ¿Cómo se logrará generar las combinaciones posibles de horarios?

- ¿Cómo se logrará generar el mejor horario para el docente?

- ¿Cómo se logrará la disponibilidad de la información de los horarios?

- ¿Cómo se lograra tomar en cuenta a los alumnos que arrastran materias?

1.4 Objetivos de la Investigación

1.4.1 Objetivo General

Implementar un sistema de automatización informático para la Facultad de Ciencias

Físicas y Matemáticas que provea: una forma dinámica y ágil en la ejecución de los

procesos que se lleven a cabo para la obtención de los horarios académicos, de una

manera rápida y efectiva con la mejor opción para que el personal docente dicte su

cátedra, previendo el conocimiento del personal docente en la cátedra que impartirá,

la cantidad de docentes y su tiempo disponible , la infraestructura que posee la

facultad y el número de alumnos que tomen la cátedra, para este punto basándose en

estadísticas de años lectivos anteriores, ya que los horarios de los docentes deben ser

generados antes de las inscripciones del alumnado.

4

1.5 Justificación

Con la implementación del Sistema de Gestión de Horarios Académicos se pretende:

- Facilitar a la facultad la asignación del personal docente de acuerdo a su

horario de trabajo.

- Beneficiar a la facultad de un proceso rápido y bien elaborado de los horarios

académicos como también de la infraestructura disponible para las cátedras.

- Asegurar que las asignaturas tendrán aulas para las correspondientes prácticas

si estás las requieren y también considerar la capacidad de las mismas.

- Facilitar la disponibilidad de la información para que esta pueda ser

consultada por los docentes y estudiantes cuando se la requiera.

- Beneficiar a personal docente a que pueda tener más opciones para dictar otra

asignatura que las habituales.

- Facilitar a la facultad en realizar un buen balanceo de la carga de horarios al

personal docente como alumnado de acuerdo a la infraestructura disponible.

1.6 Alcance

El sistema constará de 4 módulos.

1 Módulo de Docentes: Módulo que está destinado a registrar todos los datos

relacionados con los docentes. Este consta de las siguientes características.

a. Datos de del docente.

- Horario de trabajo (Tiempo Completo, Medio, Parcial).

- Las materias a cargo del docente.

b. Registro de materias que el docente va impartir.

c. Consultas de docentes:

- Registro de los datos relacionados a las asignaturas del

docente.

- Consulta de horarios programados para cada docente.

- Horas ingresadas para dictar sus cátedras.

- Las asignaturas que son tentativas para dictar la cátedra.

- Las clases asignadas una vez generado el horario.

5

2. Módulo de Aulas: Módulo que está destinado a registrar los datos

relacionados con las aulas disponibles para que se dicten las cátedras.

a. Registro de las aulas en el sistema.

- Ubicación logística del aula.

- Capacidad del aula.

- Asignaturas que se podrían dictar en el aula (De acuerdo a su

infraestructura).

b. Horarios que está siendo utilizado el aula.

- Consulta de los días que se dictan cátedra.

- Consulta de las asignaturas impartidas en la misma.

3. Módulo de Materias: Módulo que está destinado a registrar los datos

relacionados con las asignaturas a dictar en el año lectivo.

a. Registro de las asignaturas en el sistema.

b. Registro del número de horas que se debe dictar cátedra.

c. Registro si requiere obligatoriedad de laboratorio para realizar

prácticas.

- Consulta de los docentes asignados a la asignatura.

- Consulta de los días en que se imparte la asignatura.

- Consulta de número de docentes por asignatura.

-

4. Módulo de Administración: Módulo que está destinado a la administración

del sistema de Gestión de Horarios Académicos en el cual se podrá realizar la

generación del horario académico.

5. Análisis de los horarios generados automáticamente por la herramienta o

realizar modificaciones manuales con el acoplamiento automático de la

misma.

6

1.7 Planteamiento de Solución

A continuación, se describe los requerimientos que la Facultad de Ingeniería en

Ciencias Físicas y Matemáticas necesita para la programación de horarios y

asignación de salas de clase.

1. Cada curso debe ser asignado a una sala de clase con capacidad suficiente

para la demanda estimada de alumnos para dicho curso (basándose en

periodos lectivos anteriores).

2. En una sala de clase, en un mismo día y bloque (horas de clase) se puede

realizar a lo más una clase (cátedra u optativa).

3. Un profesor no puede dictar más de una clase a la vez.

4. Se deben respetar los horarios disponibles de los profesores.

5. Un factor muy importante y principal es seguir algunos patrones horarios que

deben ser impuestos para la realización de las clases.

a. Patrón 1: Compuesto por la combinación entre un día de la semana y

un bloque horario. Ejemplo, un patrón de esta clase es {LUN-A} que

corresponde al día lunes bloque de horario A (7 a 9) horas.

b. Patrón 2: Compuesto por la combinación de un día de la semana y

dos bloques horarios consecutivos. Ejemplo un patrón de este grupo

puede ser {MAR-B, MAR-C} que corresponde al patrón que contiene

los días martes y los bloques horario B (9 a 11) y C (11-13) horas.

c. Patrón 3: Para este caso los patrones deben contener dos días de la

semana distintos y un bloque horario. Las combinaciones posibles

son: lunes – jueves y martes – viernes. Un ejemplo de este tipo de

patrón es {LUN-E, JUE- E}, el patrón contiene los días lunes y jueves

en el bloque horario E (15 a 17) horas.

d. Patrón 4: Este grupo de patrones está compuesto por la combinación

de tres días de la semana distintos y un bloque horario. En este caso se

permite cualquier combinación de días, es decir, los patrones de este

tipo son aquellos de la forma {D1-X, D2-X, D3-X} donde D1, D2, y

D3 son tres días distintos de la semana y X es un bloque horario

cualquiera.

7

CAPÍTULO 2

2. REVISIÓN BIBLIOGRAFICA

2.1 Antecedentes

Conforme ha venido avanzando la ciencia y tecnología en la actualidad, la

humanidad se ha visto en la necesidad de la utilización de las mismas, por tal razón

se debe aprovechar al máximo las bondades qué nos brinda la tecnología, las cuales

deben ser utilizadas al 100%.

Existen una gran cantidad de procesos hoy en día que aún no han tenido la

posibilidad de poder utilizar la tecnología para ejecutar sus objetivos de manera

dinámica, sencilla y sobretodo un factor sumamente importante que es lograr cumplir

sus tareas en tiempos rápidos.

Todo esto se lo logra gracias a la automatización de los procesos que son utilizados

en instituciones educativas, empresas públicas, empresas privadas grandes y

pequeñas las mismas que necesitan ayuda inmediata de la herramienta más potencial

que existe en la actualidad y es “La Tecnología”.

A todo lo expuesto anteriormente la Facultad de Ciencias Físicas y Matemáticas ha

decido implementar un sistema que le permita generar los horarios académicos del

personal docente para que puedan impartir su cátedra, garantizando que los mismos

se han los más óptimos posibles y ajustándose a las directrices del personal docente.

2.2 Fundamentación Teórica

Una vez que se ha realizado el análisis correspondiente para la elaboración del

proyecto, el mismo que se lo efectuará siguiendo el lineamiento que nos indica la

Ingeniería de Software, el cual consiste en la metodología compuesta por un conjunto

de etapas que se realizan secuencialmente para dar vida a una aplicación en forma

evolutiva. Cada etapa se integra por un conjunto de acciones encaminadas para

obtener productos específicos, como especificaciones, diagramas, formatos, códigos,

pruebas y documentos diversos.

8

2.2.1 Ingeniería de Software

Es de suma importancia tener muy claro la definición de ingeniería de software ya

que es el punto de partida esencial para llevar a cabo un buen desarrollo de software,

y al final de todo el proceso poder obtener un producto de muy alta calidad.

1La ingeniería del software es el establecimiento y uso de principios sólidos de la

ingeniería para obtener económicamente un software confiable y que funcione de

modo eficiente en máquinas reales.

2Para complementar esta definición, la ingeniería de software es una disciplina que

comprende todos los aspectos de la producción de software desde las etapas iniciales

de la especificación del sistema, hasta el mantenimiento de éste después que se

utiliza.

Se tiene claro que la ingeniería de software es un proceso mientras se encuentra en la

etapa de desarrollo del software, pero también abarca las tecnologías que requiere el

proceso (métodos técnicos y herramientas automatizadas).

2.2.2 Lenguajes de Programación

Un software de programación tiene como principal objetivo computarizar la parte

lógica de un sistema informático, mediante un conjunto de instrucciones o

secuencias, que permiten controlar actividades realizadas por el usuario, para ello

utiliza una serie de lenguajes que facilitan el proceso de la programación.

Un lenguaje de programación comúnmente conocido como código de máquina o

lenguaje de máquina, consiste en un conjunto de símbolos y reglas sintácticas y

semánticas que definen la estructura y el significado de las expresiones, es decir, son

herramientas que permiten crear programas y software con la finalidad de controlar

el comportamiento de un computador.

Existen diferentes lenguajes de programación cada uno de ellos implica objetivos

distintos, lo cual facilita a los programadores especificar de manera precisa cómo

deben operar los datos sobre una computadora.

____________________________

1Definición: Roger Pressman en su libro (Ingeniería de Software “Un Enfoque Práctico” sexta edición Pág. 23). 2Definición: Ian Sommerville en su libro (Ingeniería de Software séptima edición Pág. 6).

9

A continuación se muestra un cuadro comparativo de lenguajes de programación

más importantes para el desarrollo de aplicaciones.

Características Java .Net PHP

Desarrollado Oracle Microsoft Php Group, Php

.Net

Paradigma de

Programación

Orientado a

objetos

Orientado a

objetos

Orientado a

objetos

Nivel de

Conocimiento Avanzado Avanzado Medio

Tipo de

Licenciamiento

Licencia Pública

General de GNU

Propietario

Comercial

Software Libre

Multiplataforma Si, para todo tipo

de plataforma

mediante la

máquina virtual

No, solo

plataforma

Microsoft

Si para todo tipo

de plataforma

3Tabla 1: Cuadro comparativo entre diferentes lenguajes de programación

Características Lenguajes de Programación

JSP ASP.Net PHP RUBY

Software Libre SI NO SI SI

Multiplataforma SI NO SI SI

Lenguaje de Programación Java C#,VB,J# Perl,C Perl

Soporta múltiples servidores Web SI NO SI SI

Integración con varias Base de

Datos

SI POBRE SI SI

Curva de Aprendizaje SI SI POBRE NO

Costo de Licenciamiento NO SI NO NO

Facilidad de mantenimiento SI SI SI SI

4Tabla 2: Características de los lenguajes de programación Web.

____________________________

3Definición Tabla 2.1: Autor Tesista, fuente internet 4Definición Tabla 2.2: Autor Tesista, fuente internet

10

2.2.3 Programación Orientada a Objetos

5POO o programación orientada a objetos es un paradigma de programación que está

basado en entender la creación de programas tal como es la vida real, un universo de

objetos que interaccionan entre sí.

Un objeto es todo lo que vemos. Dentro de la programación orientada a objetos

tenemos varias características como la herencia, polimorfismo, acoplamiento,

encapsulamiento, entre otras.

6Recordemos que tres son las principales características de un lenguaje orientado a

objetos, es decir, se considera que un lenguaje está totalmente orientado a objetos si

es capaz de proveer estas tres características:

Encapsulación

Herencia

Polimorfismo

Veamos una pequeña descripción de cada una de ellas y después las ampliaremos

para comprender mejor su significado y cómo puede ayudarnos a crear aplicaciones

que aprovechen todas las posibilidades que nos da la POO.

Encapsulación es la cualidad de unificar los datos y la forma de

manipularlos, de esta forma podemos ocultar el funcionamiento de una clase

y exponer solo los datos que manipula (mediante propiedades), así como

proveer de medios para poder manipular dichos datos (mediante métodos).

De esta forma solo exponemos al mundo exterior la información y la forma

de manipularla, ocultando los detalles usados para manejar esos datos y, lo

que es más importante, evitando que nadie manipule de una forma no

controlada dicha información.

Herencia es la cualidad de poder crear nuevas clases (o tipos) basadas en

otras clases, de forma que la nueva clase obtenga todas las características de

la clase que ha heredado.

____________________________

5Definición: http://www.desarrolloweb.com/articulos/programacion-orientada-objetos-java.html 6Definición: http://www.mundoprogramacion.com/NET/dotnet/POO_VB_NET_tp6.htm

11

7Mediante la herencia podemos crear de forma fácil una jerarquía de clases

que comparten un mismo comportamiento básico pero que cada nueva

generación puede tener (y de hecho tiene) un nuevo comportamiento.

Polimorfismo es la cualidad de implementar de forma particular algunas de

las características que tienen las clases, de forma que cuando necesitemos

usarlas no nos preocupe la implementación interna que cada una tenga, lo

que realmente nos interesa o nos debe importar es que podemos usar esas

características e incluso podamos acceder a ellas de forma anónima o casi.

2.2.4 Lenguaje Java

8Java es un lenguaje de programación orientado a objetos que se popularizó a

partir del lanzamiento de su primera versión comercial de amplia difusión, la

JDK 1.0 en 1996. Actualmente es uno de los lenguajes más usados para la

programación en todo el mundo.

Java es un lenguaje que evoluciona a partir de C y C++, pero que elimina diversos

aspectos de estos lenguajes y se constituye en un lenguaje definitivamente orientado

a objetos. El romper con distintos aspectos de C++ cuyo manejo inadecuado por

parte de muchos programadores daba lugar a problemas en las aplicaciones ha sido

un factor decisivo para convertir a Java en un lenguaje popular y de amplio uso.

No hay que suponer que lo único válido sea la programación orientada a objetos por

ser lo más moderno. Al contrario, muchísima programación de la que se hace hoy en

día se basa en lenguajes o código no orientado a objetos. Podemos citar como

funcionalidades de Java varias:

Aplicaciones “cliente”: son las que se ejecutan en un solo ordenador (por

ejemplo el portátil de tu casa) sin necesidad de conectarse a otra máquina.

Pueden servirte por ejemplo para realizar cálculos o gestionar datos.

___________________________

7Definición: https://www.java.com/es/download/faq/helpful_concepts.xml 8Definición: http://www.mundoprogramacion.com/NET/dotnet/POO_VB_NET_tp6.htm

12

9Aplicaciones “cliente/servidor”: son programas que necesitan conectarse a

otra máquina (por ejemplo un servidor de datos) para pedirle algún servicio

de forma más o menos continua, como podría ser el uso de una base de

datos. Pueden servir por ejemplo para el teletrabajo: trabajar desde casa pero

conectados a un ordenador de una empresa.

Aplicaciones “aplicaciones web”, que son programas Java que se ejecutan

en un servidor de páginas web. Estas aplicaciones reciben “solicitudes”

desde un ordenador y envían al navegador (Internet Explorer, Firefox, Safari,

etc.) que actúa como su cliente páginas de respuesta en HTML.

2.2.5 Plataforma JEE6 (Java Enterprise Edition)

10Es una plataforma de programación parte de la para desarrollar y ejecutar software

de aplicaciones en Lenguaje de programación Java con arquitectura de N niveles

distribuida, basándose ampliamente en componentes de software modulares

ejecutándose sobre un servidor de aplicaciones. La plataforma Java EE está definida

por una especificación. Similar a otras especificaciones del Java Community Process,

Java EE es también considerada informalmente como un estándar debido a que los

suministradores deben cumplir ciertos requisitos de conformidad para declarar que

sus productos son conformes a Java EE.

Especificaciones: JEE6 incluye varias especificaciones de API, tales como

JDBC, RMI, e-mail, JMS, Servicios Web, XML y define cómo coordinarlos.

Su arquitectura se basa en los conceptos de capas, containers, componentes,

servicios y las características de cada uno de éstos.

___________________________

9Definición: http://www.mundoprogramacion.com/NET/dotnet/POO_VB_NET_tp6.htm 10Definición: http://es.slideshare.net/cptanalatriste/arquitectura-y-diseo-de-aplicaciones-java-ee

13

Realizar aplicaciones de n – niveles tiene sus ventajas:

Mejor utilización de recursos

Asignar expertos a cada nivel

Simplificación en el mantenimiento del aplicativo

Muy buen desempeño de la aplicación

11Los contenedores JEE6 proveen un entorno de ejecución para componentes Java,

también brindan los servicios de seguridad, transaccional, administración del ciclo

vida, persistencia comunicación en red

2.2.6 Arquitectura Java Enterprise Edition

JEE se basa en el siguiente modelo de componentes dividido en capas.

Ilustración 1: Arquitectura JEE6

Capa Cliente

Consta de aplicaciones de escritorio y clientes web.

- Aplicaciones de Escritorio: Son aplicaciones escritas en lenguaje Java que

se instalan en la computadora del cliente y si es necesario pueden conectarse

con componentes de un servidor de aplicaciones.

___________________________

11Definición: http://es.slideshare.net/cptanalatriste/arquitectura-y-diseo-de-aplicaciones-java-ee 12 Ilustración: Autor Tesista, fuente internet

14

- Clientes Web: Consiste en:

o Páginas web que contienen un lenguaje de marcado (HTML) que es

generado por los componentes web que residen en la capa web.

Capa Web

Consta de componentes que procesan dinámicamente las peticiones de los clientes y

construyen respuestas que son devueltas.

Capa del Negocio

Consta de componentes que resuelven las necesidades particulares de un dominio de

negocio

Capa de la Base de Datos

Consiste en un sistema que el almacenamiento, la organización y manejo de los

datos.

2.2.7 Servidor Web

Un servidor Web es una máquina que almacena y maneja los sitios Web,

comúnmente se le conoce con el nombre de hosting ya que hospeda las páginas Web

utilizando un software o programa que sirve para atender y responder a las diferentes

peticiones de los navegadores, usando el protocolo HTTP (HyperText Transfer

Protocol), que sirve para enviar páginas Web al ordenador de un usuario, cuando éste

las solicita, es decir, los archivos para cada sitio de Internet se almacenan y ejecutan

en el servidor Web mediante una petición HTTP que tiene asociada una URL, el

servidor responde al cliente enviando el código HTML de la página y cuando el

navegador recibe el código, lo interpreta y lo muestra en pantalla.

Dependiendo del tipo de petición, el servidor Web buscará una página de las muchas

que componen el sitio Web o bien ejecutará un programa en el servidor. De cualquier

modo, siempre devolverá algún tipo de resultado HTML al cliente o navegador que

realizó la petición.

Si no se dispone de un hosting (compañía dedicada al mantenimiento de servidores

Web) se puede configurar un servidor Web local con lo cual se facilita el desarrollo

de páginas Web, permitiendo corregir errores y realizar las diferentes pruebas de

implementación. Hay muchos servidores en Internet y variados servidores Web con

15

diferentes características, pero comparten la función común de proporcionar el

acceso a los archivos y servicios, entre ellos tenemos: Glassfish, Jboss, Weblogic,

Apache, Tomcat etc.

Características Servidor de Aplicación

Glassfish Jboss Tomcat

Administración SI POBRE POBRE

Arquitectura orientado a servicios SI SI SI

Multiplataforma SI SI SI

Curva de Aprendizaje SI SI SI

Costo de Licenciamiento NO NO NO

Facilidad de mantenimiento SI SI SI

12Tabla 3: Cuadro comparativo entre los diferentes Servidores Web.

2.2.8 Justificación del software de desarrollo a utilizarse

En base a los conceptos anteriormente analizados se ha considerado conveniente

utilizar Glassfish como servidor Web, para el sistema Operativo Windows, debido a

que es un servidor más seguro y usado a nivel mundial y, como lenguaje de

programación Java, para el mismo sistema operativo ya que es un lenguaje que posee

una serie de librerías que facilitaran el desarrollo y la implantación del proyecto.

¿Por qué Java?

Java es un lenguaje de programación orientado a objetos, a la web y de

implementación libre, jquery la librería de JavaScript es bastante bueno se usa

mucho y lo principal porque es funcional en la mayoría de plataformas.

El objetivo de la plataforma JEE es el de proveer:

- Un conjunto del APIs que reducen el tiempo y complejidad del desarrollo,

permitiendo mejorar el rendimiento de las aplicaciones.

___________________________

12 Definición Tabla 2.3: Autor Tesista, fuente internet

16

- Un modelo de programación simplificado que excluye al programador de

tareas rutinarias como el manejo de transaccionalidad, manejo de recursos,

implementación de diseños complejos y seguridad.

- Estas características dan al lenguaje Java las propiedades de robustez y

seguridad, evitando ataques a los sistemas.

Es así que el desarrollo basado en JEE puede dejar de lado los aspectos más comunes

y centrarse en los aspectos concernientes a las reglas del negocio que se van a

implementar el los aplicativos.

Glassfish ¿Por qué? ¿Para qué? ¿Para quién?

Esta es una de las preguntas más frecuentes que se realiza en el análisis del desarrollo

de aplicaciones web, ya que se debe elegir las mejores herramientas tecnológicas

para el desarrollo dependiendo del producto que se va a desarrollar.

¿Por qué?

Porque para una empresa lo principal es saber si existe soporte sobre los que se está

implementando, si existe información y si es accesible a conseguir.

¿Para qué?

Para realizar el hospedaje de las aplicaciones Web, las cuales deben estar disponibles

las 24 horas del día y por 365 días al año, es decir alta disponibilidad y escalabilidad.

¿Para quién?

Para todas las personas que están involucrados en el mundo de la programación con

Java ya que necesario realizar pruebas en el transcurso del desarrollo aplicaciones

web, todo esto con el principal objetivo de garantizar la puesta en producción del

aplicativo.

17

2.2.9 Servidor de Aplicaciones Glassfish

13

GlassFish es un servidor de aplicaciones que implementa las tecnologías

definidas en la plataforma Java EE y permite ejecutar aplicaciones que siguen esta

especificación, es un gran servidor de aplicaciones web.

GlassFish tiene como base al servidor Sun Java System Application.

GlassFish es la implementación de referencia (RI) de Java EE 5.

GlassFish es un proyecto Open Source modular que permite incluir sus

librerías como parte de otros frameworks, toolkits y productos.

GlassFish es la base de código de las distribuciones estables,

certificadas y con opción de contratar soporte y mantenimiento del

Servidor de Aplicaciones de Sun: Sun Java System Application Server.

2.2.10 Introducción a JSF

14JSF (Java Server Faces) es un framework de desarrollo basado en el patrón MVC

(Modelo Vista Controlador), facilita la construcción de estas aplicaciones

proporcionando un entorno de trabajo (framework) vía web, gestionando las acciones

producidas por los usuarios, traduciendo a eventos que son enviados al servidor con

el objetivo de ejecutar las acciones solicitadas por parte del cliente hacia el aplicativo

web.

Un punto muy importante, JSF trata la interfaz de usuario de una forma diferente a lo

que se está acostumbrado en aplicaciones web, donde la programación del interfaz se

hace a través de componente y basada en eventos, en donde un conjunto de vistas de

las aplicaciones realizan sus peticiones a través de un controlador, que es quien

recibe las peticiones y las ejecuta.

Los eventos realizados sobre una página JSF incurren en una carga sobre la red, ya

que por este medio se realiza transmisión de los datos a para ser procesados por el

servidor, y la respuesta a esta solicitud debe ser devuelta al cliente de manera

inmediata.

__________________________

13 Definición: http://webservicelearning.googlecode.com/svn/trunk/documentación/glassfish.pdf 14 Definición: http://www.desarrolloweb.com/articulos/2380.php

18

2.2.10.1 Características de JSF

Cabe mencionar que las principales características de JSF son:

Es un framework MVC (Modelo/Vista/Controlador).

Proporciona un conjunto de componentes definidas en páginas XHTML.

Características de plantilla.

Creación de componentes compuestos.

Utilización de beans gestionados para la conexión de los componentes

gráficos con los datos de la aplicación.

Navegación entre vistas y un modelo de comunicación Ajax estándar entre la

vista y el servidor.

El lenguaje en el que se definen las páginas JSF es XHTML, en las versiones

anteriores las páginas JSF se utilizaba HTML para realizar la construcción de las

interfaces visuales del aplicativo, pero no se podía implementar funcionalidades

potentes en JSF entonces se nació XHTML.

El lenguaje XHTML se implementó con el objetivo de poder hacer compatible el

formato XML con HTML obteniendo un como resultado final un documento

XHTML formateado en forma de documento XML.

Estos documentos son más fáciles de validar y se procesan más rápido además se

puede utilizar herramientas genéricas para poder realizar ediciones al documento que

son orientadas específicamente a XML y una de las características más importantes

es que pueden coexistir con distintos tipos de etiquetas que son iguales en varios

lenguajes.

2.2.10.2 Facelest

Framework define una estructura general de las páginas mediante plantillas, se

adapta al enfoque de JSF. La estructura de las páginas se las define con la utilización

de las etiquetas Facelest.

Se tiene las siguientes características:

Se puede realizar composición de componentes.

En las etiquetas se puede definir funciones y lógica.

19

Se presenta un cuadro en el que explica las etiquetas definidas para definir las

plantillas.

Ilustración 2: Etiquetas para definir plantillas.

Para poder utilizar los tags de Facelest, se debe hacer la declaración del namespace

de la página JSF: xmlns:ui="http://xmlns.jcp.org/jsf/facelets"

Además Facelest nos ayuda encapsular los componentes de la aplicación que son

más comunes, y lo principal es la creación de una plantilla, la misma que será el

molde de la aplicación para la parte gráfica, es decir si realizamos algún cambio en la

plantilla afectara a todas las páginas que estén utilizando la plantilla.

Ilustración 3 : Define que la página utilice una plantilla.

Esta plantilla llamada template.xml es una página XHTML, en la cual se han definido

los elementos principales que debe tener una plantilla cabecera, menú, contenido y

pie.

Ilustración 4 : Pantalla

20

2.2.10.3 Bean

Es un componente reutilizable que nos sirve para desarrollar nuestro modelo de

objetos, además tiene un constructor sin parámetros, atributos y propiedad setter y

getter y deben ser serializables.

Ilustración 5 : Clase Bean

2.2.10.4 ManagedBean

Son Beans y que nos permite hacer referencia entre la aplicación jsf y sus métodos

del negocio, además es una clase para definir lo que se denomina como bean

gestionado.

Ilustración 6 : Aplicación de los Bean.

21

2.2.11 PrimeFaces 5.1

15PrimeFaces es una librería de componentes para JavaServer Faces (JSF) de código

abierto, que cuenta con un conjunto de componentes enriquecidos que facilitan la

creación de las aplicaciones web.

Una de las ventajas de utilizar Primefaces, es que permite la integración con otros

componentes como por ejemplo 16

RichFaces, 17

IceFaces.

18Las principales características de Primefaces son:

Soporte nativo de Ajax, incluyendo Push/Comet.

Kit para crear aplicaciones web para móviles.

Uso de JavaScript no intrusivo (no aparece en línea dentro de los elementos,

sino dentro de un bloque <script>).

Es un proyecto open source, activo y bastante estable entre versiones.

Algunos inconvenientes podrían ser:

Para utilizar el soporte de Ajax tenemos que indicarlo explícitamente, por

medio de atributos específicos de cada componente.

No podemos utilizar el soporte de Ajax de JSF 2 (mediante <f:ajax>) con los

componentes de Primefaces.

Ilustración 7 : Librería Primefaces.

__________________________

15 Definición: https://es.wikipedia.org/wiki/PrimeFaces 16 Definición: http://showcase.richfaces.org 17 Definición: http://wiki.icefaces.org/display/ICE/ICE+Components+Reference 18 Definición: http://www.adictosaltrabajo.com/tutoriales/introduccion-primefaces/

https://es.wikipedia.org/wiki/JavaServer_Faces

https://es.wikipedia.org/wiki/C%C3%B3digo_abierto

https://es.wikipedia.org/wiki/C%C3%B3digo_abierto

https://es.wikipedia.org/wiki/RichFaces

22

2.2.12 EL Proceso Unificado de Rational (RUP)

19Este es un proceso de desarrollo de software y que junto con el Lenguaje Unificado

de Modelado UML, constituye una metodología estándar para el análisis,

implementación y documentación de sistemas orientados a objetos. Esta metodología

fue adaptada a las características de la organización y se realizan ajustes en base a las

características específicas de cada proyecto.

El conjunto de disciplinas básico utilizado contempla:

Realización de reuniones y entrevistas (preliminares y específicas) que son

documentadas, o confección de un documento de visión a partir del proyecto

base, ajustando y precisando las necesidades de alto nivel en base a lo

relevado en las reuniones preliminares. Se focaliza en las necesidades de los

stakeholders y los usuarios finales y en porque esas necesidades existen

Realizar el análisis detallado, profundizando en cada una de las características

obteniendo los requerimientos funcionales y no funcionales que deben ser

atendidos.

Confeccionar un glosario: dada la necesidad de trabajar en forma

interdisciplinaria en prácticamente todo los proyectos es de vital importancia

confeccionar un glosario o diccionario que permita unificar el lenguaje a

utilizar en la ejecución del proyecto. Este glosario se realiza con la técnica de

Léxico extendido del Lenguaje.

Confección del diagrama de casos de uso y determinación de los casos de uso

a través del conocimiento de los requerimientos funcionales comenzar la

construcción del diagrama de casos de uso, determinación de actores del

sistema y definir los atributos necesario que permitan ser utilizados para

estimar el esfuerzo para la construcción de la solución.

__________________________

19 Definición: www.trazar.org Publicación PDF “Buenas prácticas en Desarrollo de Software” pág. 5

http://www.trazar.org/

23

Ilustración 8 : Ciclo de vida RUP.

20Por cada una de las 4 fases se define la cantidad de iteraciones en base a la

particularidad del proyecto. Se suele utilizar una iteración en la fase de Inicio y de

Elaboración, varias iteraciones de construcción y transición. En la Figura 2.2 se

muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se

encuentre el proyecto.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades

relacionadas a los requerimientos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la línea base de

la arquitectura, abarcan más los flujos de trabajo de refinamiento de los

requerimientos, análisis, diseño y una parte de implementación orientado a la línea

base de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por medio de

una serie de iteraciones.

Para cada iteración se selecciona algunos casos de uso, se refina su análisis y diseño

y se procede a su implementación y pruebas. Se realiza una pequeña cascada para

cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación.

__________________________



24

21En la fase de transición se pretende garantizar que se tiene un producto preparado

para su entrega a la comunidad de usuarios.

Como se puede observar en cada fase participan todas las disciplinas, pero que

dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

2.2.13 Características que posee la metodología

Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,

cuándo y cómo)

Pretende implementar las mejores prácticas en Ingeniería de Software.

Desarrollo iterativo.

Administración de requisitos.

Uso de arquitectura basada en componentes.

Control de cambios.

Modelado visual del software.

Verificación de la calidad del software.

Acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los

desarrolladores trabajan para obtener resultados claros a corto plazo.

Distribuye la carga de trabajo a lo largo del tiempo del proyecto ya que todas

las disciplinas colaboran en cada iteración. Facilita la reutilización del código

teniendo en cuenta que se realizan revisiones en las primeras iteraciones lo

cual además permite que se aprecien oportunidades de mejoras en el diseño

A su vez la misma se caracteriza por ser iterativo e incremental, estar centrado en la

arquitectura y guiado por los casos de uso.

__________________________



25

2.2.14. UML

22UML es un lenguaje para hacer modelos y es independiente de los métodos de

análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de

modelado. Un método es una manera explícita de estructurar el pensamiento y las

acciones de cada individuo.

Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por

qué hacerlo, mientras que el lenguaje de modelado carece de estas instrucciones.

Los métodos contienen modelos y esos modelos son utilizados para describir algo y

comunicar los resultados del uso del método.

Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo, los

símbolos utilizados en los modelos y un conjunto de mecanismos generales o reglas

que indican cómo utilizar los elementos.

Ilustración 9 : 3 UML. (Autoría Tesista)

Vistas: muestran diferentes aspectos del sistema modelado. Una vista no es una

gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos

diagramas juntos muestran una "fotografía" completa del sistema.

Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos

para el desarrollo. Las diferentes vistas que UML tiene son:

Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la

perciben los actores externos.

__________________________

22 Definición: http://profesores.fi-b.unam.mx/carlos/aydoo/uml.html

26

Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en

términos de la estructura estática y la conducta dinámica del sistema.

Vista de Componentes: Muestra la organización de los componentes de

código.

Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los

problemas con la comunicación y sincronización que están presentes en un

sistema concurrente.

Vista de Distribución: muestra la distribución del sistema en la arquitectura

física con computadoras y dispositivos llamados nodos.

Diagramas: 23

Los diagramas son las gráficas que describen el contenido de una

vista, UML tiene nueve tipos de diagramas que son utilizados en combinación para

proveer todas las vistas de un sistema:

Diagramas de caso de uso.

Diagrama de clases.

Diagrama de objetos.

Diagrama de estados.

Diagrama de secuencia.

Diagrama de actividad.

Diagrama de componentes.

Diagrama de distribución.

Símbolos: Los conceptos utilizados en los diagramas son los elementos de modelo

que representan conceptos comunes orientados a objetos, tales como clases, objetos y

mensajes, y las relaciones entre estos conceptos incluyendo la asociación,

dependencia y generalización. Un elemento de modelo es utilizado en varios

diagramas diferentes, pero siempre tiene el mismo significado y simbología.

Reglas: Proveen comentarios extras, información o semántica acerca del elemento de

modelo; además proveen mecanismos de extensión para adaptar o extender UML a

un método o proceso específico, organización o usuario.

__________________________

23 Definición: http://profesores.fi-b.unam.mx/carlos/aydoo/uml.html

27

2.2.15 Identificación de Variables

Administrador del sistema: Es la persona responsable de asignar los debidos

permisos a los usuarios que se conecten al sistema según su función.

Personal de recepción: Es la o las personas encargadas de:

o Registrar los datos de las Aulas.

o Registrar los datos de Asignaturas.

o Registrar los datos de la Categoría del Docente

o Registrar los datos del Docente.

o Registrar las horas del Docente.

o Registrar las cátedras que dicta el Docente.

Personal de Operación: Encargado de generar los horarios académicos para

el inicio de las actividades, tendrá la posibilidad de optar por la mejor opción

que la herramienta de gestión de horarios académicos genere.

2.3 Hipótesis

Con la implementación del sistema de gestión de horarios académicos se agilizará y

las actividades que se lleven a cabo por los empleados encargados de generar los

horarios académicos y además con el uso de la información que el sistema nos

genera se optimizara el uso de recursos como tiempo, dinero y una mejor

organización en la asignación de aula.

Además de una mejora en este proceso en el cual se tendrá información del personal

docente de la facultad, los horarios de clases, información de la disponibilidad de las

aulas y la ubicación, obtener un horario individual por docente de las asignaturas que

debe dictar su cátedra y el aula.

28

CAPÍTULO 3

3. MARCO METODOLÓGICO

Para el desarrollo del sistema se ha escogido el modelo RUP y nos basaremos en lo

que indica su metodología.

El sistema crece al incorporar nuevas funciones en cada ciclo de desarrollo. Tras una

fase preliminar de planeación y especificación, el desarrollo pasa a una fase de

construcción a través de una serie de ciclos de desarrollo.

En cada ciclo se aborda un conjunto relativamente pequeño de requerimientos

pasando por el análisis, el diseño, la construcción y las pruebas. El sistema va

creciendo con cada ciclo que concluye.

3.1 Diseño de la Investigación

La generación de horarios académicos en las instituciones educativas debe ser de

forma precisa, sin ningún margen de error ya que el objetivo principal es poder dictar

la catedral y para ello intervienen factores como el aula donde se va a dar las clases,

la misma que no debe ser utilizada por ningún otro docente, no al mismo tiempo el

docente dar materias distintas, entonces el horario académico debe ser generado

correctamente.

Es por esta razón que es necesario diseñar un programa que realice la generación de

horarios académicos para la Carrera de Ingeniería Informática de la Universidad

Central del Ecuador, con la finalidad de poder realizar un horario académico

consistente y en corto tiempo, con la facilidad de tener varias alternativas y escoger

el mejor horario y un adecuado control de los docentes que están dictando sus

cátedras, las asignaturas por semestre y sus horas en las que se imparten las mismas.

Para poder el desarrollar el sistema informático en mención se va a utilizar una de las

metodologías que se analizado y nos ayudara de manera efectiva a lo largo de la

elaboración del proyecto empezando con el análisis, diseño, implementación, y

finalmente la documentación, que se la efectuara con la metodología RUP.

29

3.2 Diseño Experimental

3.2.1 Investigación de Campo

En la Facultad de Ingeniería Informática, los horarios académicos representan la

parte principal para poder empezar un nuevo semestre de clases y para poder

realizarlo se necesita de tres factores primordiales que son:

Factor Docentes.

Factor Tiempo.

Espacio Físico (Aulas).

3.2.2 Diseño de la Investigación de Campo

La búsqueda de información confiable debe ser adecuada, tener la validez del caso,

fiabilidad y lo fundamental estar actualizada.

Se realizara el estudio de casos en donde se tendrá reuniones para poder tener claro el

objetivo fundamental que es lograr generar un horario académico consistente.

3.3 Ámbito de la Investigación

La investigación se llevó a cabo en la Facultad de Ingeniería Informática de la

Universidad Central del Ecuador que es el lugar en donde se va a realizar la

implementación del sistema informático Gestión de Horarios Académicos (SGHA).

3.4 Identificación de las Fuentes de Investigación

3.4.1 Fuentes Primarias

Es la fuente de información que se obtiene en la Facultad de Ingeniería Informática,

la misma que se la puede realizar mediante cuestionarios o entrevistas con el

personal que realiza la generación de horarios dentro de la facultad.

3.4.2 Fuentes Secundarias

Se realizó también la búsqueda de horarios generados manualmente de semestres

anteriores los cuales sirvieron para poder reforzar la investigación.

30

3.4.2.1 Determinación del universo

Para la generación de horarios académicos se tiene varios factores que intervienen en

el proceso que son las aulas, docentes, las asignaturas y la capacidad de las aulas,

todos estos factores son de naturaleza finita por tal motivo antes de realizar la

generación de los horario académicos se conoce el número exacto de cada uno de los

factores involucrados en el proceso de generación.

3.4.2.2 Tamaño de la muestra

Se determinó que el universo de la Facultad de Ingeniería Informática de la

Universidad Central del Ecuador para la generación de horarios es finito, para ello se

llevó a cabo una entrevista para la investigación con las personas involucradas en la

generación de horarios académicos para poder determinar la manera de cómo lo

vienen generando de manera manual.

3.5 Fase de Elaboración Análisis y Diseño

Esta fase es la más importante del proyecto ya que aquí determinamos varios factores

como el modelamiento, refinamiento y especificación, se crean modelos de los

requisitos de datos, flujos de información, control y también el comportamiento

operativo todo esto antes de empezar a codificar, analizamos soluciones técnicas del

proyecto, rendimientos de software, arquitectura.

3.5.1 Gestión de Riesgos

El proyecto es un sistema dinámico y su riesgo viene dado por la diferencia entre el

estado final deseado y el estado alcanzado. Los proyectos de sistematización

deberían cumplir siempre dos requisitos, por un lado, ser cerrados en sí mismos, es

decir, aparecer ante el usuario como una totalidad cerrada que se pueda reconocer

como tal; por otra parte, deben dar cuenta del hecho de que ellos mismos son parte de

una plataforma extendida.

3.5.2 Identificación de Riesgos

Riesgos en los recursos

Insuficiencias de personal.

31

Plazos y presupuestos irreales.

Insuficiencia de Dinero.

Riesgos en los requerimientos

Desarrollo de interfaz de usuario equivocada.

Continuos cambios de requerimientos.

Otros Riesgos

Insuficiencias del rendimiento del sistema al funcionar en tiempo real.

Optimismo sobre las capacidades de las tecnologías informáticas.

3.5.3 Identificación de Requerimientos Funcionales

El análisis de requisitos nos permite poder determinar a los objetos de dominio y a

las relaciones entre objetos que intervienen en el problema, actores del sistema,

objetivos y finalmente responsabilidades principales que realizan cada uno de ellos.

El sistema constará de 4 módulos.

1 Módulo de Docentes: Módulo que está destinado a registrar todos los datos

relacionados con los docentes. Este consta de las siguientes características.

b. Datos de del docente.

- Horario de trabajo (Tiempo Completo, Medio, Parcial).

- Las materias a cargo del docente.

b. Registro de materias que el docente va impartir.

c. Consultas de docentes:

- Registro de los datos relacionados a las asignaturas del

docente.

- Consulta de horarios programados para cada docente.

- Horas ingresadas para dictar sus cátedras.

- Las asignaturas que son tentativas para dictar la cátedra.

- Las clases asignadas una vez generado el horario.

32

2 Módulo de Aulas: Módulo que está destinado a registrar los datos

relacionados con las aulas disponibles para que se dicten las cátedras.

a. Registro de las aulas en el sistema.

- Ubicación logística del aula.

- Capacidad del aula.

- Asignaturas que se podrían dictar en el aula (De acuerdo a su

infraestructura).

b. Horarios que está siendo utilizado el aula.

- Consulta de los días que se dictan cátedra.

- Consulta de las asignaturas impartidas en la misma.

3 Módulo de Materias: Módulo que está destinado a registrar los datos

relacionados con las asignaturas a dictar en el año lectivo.

a. Registro de las asignaturas en el sistema.

b. Registro del número de horas que se debe dictar cátedra.

c. Registro si requiere obligatoriedad de laboratorio para realizar

prácticas.

- Consulta de los docentes asignados a la asignatura.

- Consulta de los días en que se imparte la asignatura.

- Consulta de número de docentes por asignatura.

-

4 Módulo de Administración: Módulo que está destinado a la administración

del sistema de Gestión de Horarios Académicos en el cual se podrá realizar la

generación del horario académico.

5 Análisis de los horarios generados automáticamente por la herramienta o

realizar modificaciones manuales con el acoplamiento automático de la

misma.

3.5.4 Identificación de Actores

Se puede identificar tres tipos de actores que son quienes están en constante

interacción con el sistema de manera directa o indirecta, a continuación presentamos

los actores:

33

Administrador

Docentes

Estudiantes

3.5.4.1 Actor Administrador

El Administrador del sistema cumple el rol principal que consiste en dar acceso,

asignar perfil de usuario, realizar registro, modificaciones, eliminación de los datos

que el sistema necesita para poder generar los horarios.

Ilustración 10 : Funciones del Administrador del Sistema. (Autoría Tesista)

3.5.4.2 Actor Docentes

Los Docentes pueden acceder al sitio web, en el podrán acceder a la consulta de sus

horarios, las asignaturas que van a dictar cátedra en el semestre y las aulas donde se

realizaran las mismas.

Ilustración 11 : Funciones del Docentes. (Autoría Tesista)

34

3.5.4.3 Actor Estudiantes

Al sistema también pueden acceder los estudiantes de la facultad para poder revisar

los horarios donde recibirán sus cátedras, las aulas, los profesores.

Ilustración 12 : Funciones del Estudiantes. (Autoría Tesista)

3.6 Requerimientos Específicos

El docente y alumnos podrán acceder al portal web para realizar las consultas que

requieran consultar con respecto a los horarios del semestre en el que se encuentre

vigente en la facultad.

No es necesario dar acceso a cada uno de los estudiantes para que puedan ingresar al

aplicativo web, basta con la creación de un usuario genérico para que lo puedan

hacer, de igual manera se debe proceder con los docentes, o si es necesario se puede

acceder al directorio activo de la institución educativa para consultar los usuario

vigentes y puedan acceder al aplicativo web.

3.7 Casos de Uso

Se presentan a continuación los casos de uso definidos para el Sistema Generación de

Horarios Académicos para la Universidad Central del Ecuador (SGHA), los cuales

no ayudarán a identificar todas las funcionalidades que se necesitaran para correcta

codificación, debemos estar muy claros en los procesos que deben existir en el

aplicativo, en cada uno de los escenarios que se presentaran a continuación.

35

Para poder comenzar el caso de uso debemos saber que siempre los inicia el actor,

solicita información del sistema, realiza modificaciones al sistema o consultas.

Vamos a utilizar las siguientes plantillas para llevar acabo el registro de la

descripción de los actores que están involucrados en el sistema SGHA.

24Los actores no necesariamente coinciden con los Usuarios, un usuario puede

interpretar distintos roles, correspondientes a distintos actores, los actores

representan papeles (Roles) que interpretan personas, periféricos u otros sistemas

cuando el sistema está en uso.

Un actor podría desempeñar distintos papeles dependiendo del caso de uso en el que

participe, un actor representa un conjunto coherente de papeles que los usuarios de

una entidad (sistema, subsistema) pueden desempeñar al interaccionar con la misma.

Primarios: interaccionan con el sistema para explotar su funcionalidad,

trabajan directa y frecuentemente con el software.

Secundarios: soporte del sistema para que los primarios puedan trabajar.

Iniciadores: no utilizan directamente el sistema pero desencadenan el

trabajo de otro actor.( No aparecen en UML pero sí los consideran otros

actores.

Ilustración 13 : Plantilla Descripción de Actores. (Fuente Internet)

__________________________

24 Definición: http://es.slideshare.net/jpincay/diagramas-de-caso-de-uso-ejemplos

36

25La especificación de un caso de uso se la describe en como el actor interactúa con

el sistema, es una narración en la que se describe el rol desempeñado por los actores

en su interacción con el sistema.

Lo más importante de los casos de uso es su descripción, mucho más que los

diagramas de casos de uso.

Para los casos de uso se va utilizar la plantilla para realizar la descripción

correspondiente a cada uno de ellos, ya que es sumamente importante realizar una

buena descripción de los casos involucrados en el proceso completo del sistema

SGHA.

Ilustración 14 : Plantilla Descripción Casos de Uso. (Fuente Internet)

A continuación se presentan las plantillas de los actores y los casos de usos del

sistema SGHA, con la descripción del flujo correspondiente para poder realizar la

generación de horarios académicos de manera efectiva y muy ágil.

__________________________

25 Definición: http://es.slideshare.net/jpincay/diagramas-de-caso-de-uso-ejemplos

37

Descripción de Actores

Actor

Administrador

AC1

Descripción Realiza la asignación de perfiles para el acceso al sistema SGHA.

Ingreso modificación y eliminación de datos.

Características

Gestiona las funcionalidades del sistema.

Relaciones Docentes: Ingreso de datos Acceso y acceso al sistema SGHA.

Alumnos: Acceso al sistema SGHA.

Referencias

Autor

Hernán Campoverde R.

Fecha

16/07/2014

Versión

1.0

Atributos

Nombre Descripción

Rol Corresponde a la función que puede desempeñar en el sistema.

Nombre del Rol Nombre del Rol (Administrador, Usuario, Estudiante, Invitado)

Descripción Rol

Breve reseña del rol que desempeña en el sistema.

Comentarios

El administrador tiene la posibilidad de generar los horarios académicos y puede

seleccionar el que este a su criterio, puede realizar cambios en las horas de los

docentes si es necesario para poder armar un horario de manera manual y ya no

automáticamente.

Tabla 4 : Descripción Actor Administrador SGHA. (Fuente Tesista)

38


Actor

Docente

AC2

Descripción

Ingresa al sistema SGHA para poder realizar la consulta de sus

horarios generados para el presente semestre, consulta de

asignaturas y aulas asignadas para dictar sus cátedras.

Características

Utiliza las funcionalidades de consulta y reportes del sistema.

Relaciones Aulas: Asignación del sistema SGHA de manera automática.

Asignaturas: Correspondientes a las seleccionadas por el docente.

Referencias

Autor


Fecha

16/07/2014

Versión

1.0

Atributos

Nombre Descripción

Categoría Es la categoría del docente para poder cumplir con las horas

diarias, Tiempo Completo, Medio Tiempo y Parcial.

Horario Disponibilidad del docente para impartir su cátedra.

Asignaturas

Son las correspondientes a cada semestre, las cuales tienen su

número de horas o créditos que se deben cumplir en la semana.

Comentarios

El docente es el principal actor del proceso de generación de horarios académicos a

través del SGHA ya que en base a sus horas disponibles y las asignaturas se arman

los horarios con las correspondientes aulas para que sean impartidas las cátedras y si

se presenta algún cruce el sistema pueda determinar automáticamente otra hora.

Tabla 5 : Descripción Actor Docentes SGHA. (Fuente Tesista)

39


Actor

Estudiante

AC3

Descripción

Ingresa al sistema SGHA para poder realizar la consulta de sus

horarios generados para el presente semestre, consulta de

asignaturas y aulas asignadas para recibir sus cátedras.

Características

Utiliza las funcionalidades de consulta y reportes del sistema.

Relaciones Aulas: Asignación del sistema SGHA de manera automática.

Asignaturas: Correspondientes a cada semestre.

Referencias

Autor


Fecha

16/07/2014

Versión

1.0

Atributos

Nombre Descripción

Asignatura Correspondiente a semestre en el que se encuentre el alumno.

Semestre Está relacionado con el número de horas semanales.

Carrera

La facultad tiene varias carreras, involucra el cruce de aulas.

Comentarios

El alumno participa como un parámetro de entrada del sistema, la generación de

horarios académicos necesita de la cantidad de aulas, número de alumnos que puede

alojar el aula, es necesario saber el número del alumnado ya que así el sistema

analizará cuantos paralelos se requieren generar para poder cubrir la cantidad del

alumnado de la facultad.

Tabla 6 : Descripción Actor Estudiantes SGHA. (Fuente Tesista)

40

3.7.1 Diagrama general caso de uso general

Ilustración 15 : Diagrama Caso de Uso General. (Autor Tesista)

Descripción Casos de Uso

Caso de Uso

Administrador SGHA

CU1

Actores Administrador

Tipo

Primario

Precondición

Ingresa al Sistema como Administrador

41

Postcondición Gestiona las funcionalidades del sistema

Autor


Fecha

16/07/2014

Versión

1.0

Propósito

Administrar el sistema SGHA

Resumen

El administrador ingresa al aplicativo y es autenticado por el sistema.

El administrador selecciona el menú para ejecutar una acción a realizar.

El administrador registra, modifica, elimina, consulta datos en el formulario

del sistema.

El administrador genera el horario y realiza las validaciones

correspondientes.

El administrador realiza la consulta del horario generado.

El administrador genera el reporte con todos los horarios desde primero a

noveno semestre.

Tabla 7: Descripción Caso Uso Administrador SGHA. (Fuente Tesista)


Caso de Uso

Docentes SGHA

CU2

Actores Docente

Tipo

Primario

Precondición

Ingresa al Sistema como Usuario.

Postcondición


42

Autor


Fecha

16/07/2014

Versión

1.0

Propósito

Acceder al sistema SGHA y realizar consultas.

Resumen

El docente ingresa al aplicativo y es autenticado por el sistema.

El docente selecciona el menú para ejecutar una acción a realizar.

El docente consulta datos en el formulario del sistema.

El docente realiza la consulta del horario generado.

El docente puede generar los reportes.

Tabla 8 : Descripción Caso Uso Docente SGHA. (Fuente Tesista)


Caso de Uso

Estudiante SGHA

CU3

Actores Estudiante

Tipo

Primario

Precondición

Ingresa al Sistema como Estudiante.

Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito

43


Resumen

El estudiante ingresa al aplicativo y es autenticado por el sistema.

El estudiante selecciona el menú para ejecutar una acción a realizar.

El estudiante consulta datos en el formulario del sistema.

El estudiante realiza la consulta del horario generado.

El estudiante puede generar los reportes.

Tabla 9 : Descripción Caso Uso Estudiante SGHA. (Fuente Tesista)

3.7.1 Diagramas de Casos de Uso Específicos

3.7.1.1 Diagrama caso de uso Administrador

Ilustración 16 : Diagrama Caso de Uso Administrador. (Autor Tesista)

44


Caso de Uso

Registro Usuario

CU4


Tipo

Primario

Precondición

Ingresa al Sistema como Administrador.

Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito

Administra al sistema SGHA.

Resumen




del sistema.

El sistema ejecuta la acción realizada por el administrador almacenado los

datos ingresados.

El sistema devuelve un mensaje de ejecución exitosa o errónea.

Tabla 10 : Descripción Registro Usuario SGHA. (Fuente Tesista)

45


Caso de Uso

Registro Perfiles

CU5


Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen




del sistema.


datos ingresados.


Tabla 11 : Descripción Registro Perfiles SGHA. (Fuente Tesista)

46


Caso de Uso

Registro Docentes

CU6


Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen




del sistema.


datos ingresados.


Tabla 12 : Descripción Registro Docentes SGHA. (Fuente Tesista)

47


Caso de Uso

Registro Horarios

CU7


Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen




del sistema.


datos ingresados.


Tabla 13 : Descripción Registro Horarios SGHA. (Fuente Tesista)

48


Caso de Uso

Registro Aulas

CU8


Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen




del sistema.


datos ingresados.


Tabla 14: Descripción Registro Aulas SGHA. (Fuente Tesista)

49


Caso de Uso

Registro Categoría Docente

CU9


Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen




del sistema.


datos ingresados.


Tabla 15 : Descripción Registro Categoría SGHA. (Fuente Tesista)

50


Caso de Uso

Registro Categoría Asignaturas

CU10


Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen




del sistema.


datos ingresados.


Tabla 16 : Descripción Registro Asignaturas SGHA. (Fuente Tesista)

51

3.7.1.2 Diagrama caso de uso Docente

Ilustración 17 : Diagrama Caso de Uso Docente. (Autor Tesista)

52


Caso de Uso

Consulta Docentes

CU11

Actores Docente

Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen






EL docente puede visualizar los reportes solicitados.

A cada solicitud de consulta el sistema consulta en base de dato.

A cada consulta el sistema responde con un mensaje de error o éxito.

Tabla 17: Descripción Caso Uso Consulta Docentes SGHA. (Fuente Tesista)

53


Caso de Uso

Consulta Horarios

CU12

Actores Docente

Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen









Tabla 18 : Descripción Caso Uso Consulta Horarios SGHA. (Fuente Tesista)

54


Caso de Uso

Consulta Aulas

CU13

Actores Docente

Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen









Tabla 19 : Descripción Caso Uso Consulta Aulas SGHA. (Fuente Tesista)

55


Caso de Uso

Consulta Hora Docente

CU14

Actores Docente

Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen









Tabla 20 : Descripción Caso Uso Consulta Hora Docente. (Fuente Tesista)

56


Caso de Uso

Consulta Asignaturas

CU15

Actores Docente

Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen









Tabla 21 : Descripción Caso Uso Consulta Asignaturas. (Fuente Tesista)

57

3.7.1.3 Diagrama caso de uso Estudiante

Ilustración 18: Diagrama Caso de Uso Estudiante. (Autor Tesista)

58


Caso de Uso

Consulta Docente

CU16

Actores Estudiante

Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen






EL estudiante puede visualizar los reportes solicitados.



Tabla 22: Descripción Caso Uso Consulta Docentes. (Fuente Tesista)

59


Caso de Uso

Consulta Horarios

CU17

Actores Estudiante

Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen









Tabla 23 : Descripción Caso Uso Consulta Horarios. (Fuente Tesista)

60


Caso de Uso

Consulta Aulas

CU18

Actores Estudiante

Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen









Tabla 24 : Descripción Caso Uso Consulta Aulas. (Fuente Tesista)

61


Caso de Uso

Consulta Hora Docente

CU19

Actores Estudiante

Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen









Tabla 25 : Descripción Caso Uso Consulta Hora Docente. (Fuente Tesista)

62


Caso de Uso

Consulta Hora Asignaturas

CU20

Actores Estudiante

Tipo

Primario

Precondición


Postcondición


Autor


Fecha

16/07/2014

Versión

1.0

Propósito


Resumen









Tabla 26 : Descripción Caso Uso Consulta Asignatura. (Fuente Tesista)

63

3.7.2 Diagramas de Secuencia

Ilustración 19 : Diagrama de secuencia gestión Administrador. (Autor Tesista)

Ilustración 20 : Diagrama de secuencia gestión Admin/Docente. (Autor Tesista)

64

Ilustración 21 : Diagrama de secuencia de Reportes. (Autor Tesista)

Ilustración 22: Diagrama de secuencia de Consultas. (Autor Tesista)

65

CAPÍTULO 4

4. DISEÑO DEL SISTEMA

4.1 Definición de Arquitectura del Sistema

Se presenta el detalle de la Arquitectura que se implementó para el Sistema de

Gestión de Horarios Académicos (SGHA).

En la actualidad tenemos una gama amplia de tecnologías disponibles para la

implementación de sistemas informáticos, el seleccionado para el proyecto cumple

con los estándares de desarrollo.

La arquitectura implementada es el de n-capas que están basados en el modelo MVC

(Modelo – Vista – Controlador), por definición las aplicaciones JEE utilizan una

arquitectura n-capas lo cual nos permite separar lógicamente y en algunos casos

físicamente dando como resultado la Interfaz de Usuario, la lógica del negocio, y

acceso a datos.

4.1.1 La Capa de Presentación

Esta capa es la que se despliega al Usuario, por medio de esta capa el usuario puede

interactuar con la aplicación, debe ser una interfaz amigable para el usuario, fácil de

utilizar, se encarga de recolectar los datos de entrada que necesita la capa de negocio

para dar funcionamiento al sistema, esta capa únicamente se puede comunicar con la

capa de negocio.

Ilustración 23 : Capa de Presentación. (Fuente Tesista)

66

4.1.2 La Capa Lógica de Negocio

Esta capa es la que se encarga de la lógica del sistema web SGHA, aquí es donde se

encuentran los programas que se ejecutan, recibe las solicitudes de la capa de

presentación las que son realizadas por solicitud del usuario y envían respuestas a las

solicitudes ingresadas.

Por lo enunciado anteriormente esta capa se comunica con la capa de presentación

para recibir las solicitudes y mostrar los resultados, y con la capa de datos para

solicitar al gestor de base de datos almacenar o recuperar.

Ilustración 24 : Capa de Negocio. (Fuente Tesista)

4.1.3 La Capa de Datos

Aquí es donde se almacenan los datos ingresados desde la capa de presentación que

pasa por la capo de negocio y finalmente se guardan en la base de datos, de igual

manera recupera los datos que son solicitados por la capa de negocio que a su vez

fueron solicitados por la capa de presentación la misma que presenta la información

solicitada por el usuario.

67

4.2 Determinación de las Herramientas tecnológicas

Ya tenemos listo la arquitectura del sistema, ahora nos toca explicar el conjunto de

APIS y tecnologías que se van a utilizar en cada una de las capas correspondientes a

al sistema SGHA.

4.2.1 Lenguaje de Programación

En el capítulo dos se indican los términos conceptuales y la justificación

correspondiente para seleccionar a JAVA como el lenguaje de programación el

mismo que estará bajo las especificaciones JEE6 para aplicaciones.

4.2.2 Sistema Gestor de Base de Datos

La Bdd es el pilar fundamental de cualquier aplicación independientemente de la

arquitectura o del lenguaje de programación escogido, para el SGHA se optó por

usar PostgreSQL-9.3.9-3 como nuestro gestor de base de datos.

Ilustración 25 : Gestor de Base de Datos.

68

4.2.3 Servidor de Aplicaciones JEE

GlassFish ha sido seleccionado como nuestro servidor de aplicaciones web, es un

servidor que implementa las tecnologías definidas en la plataforma Java EE y por tal

razón nos permite ejecutar estas aplicaciones, además cabe mencionar que es gratuito

y de código libre.

Ilustración 26 : Administración GlassFish.

4.2.4 Entorno de Desarrollo (IDE)

Se escogió a NetBeans 8.0.2 como el IDE para el desarrollo de la aplicación,

independientemente el IDE no es una ventaja ni desventaja para el desarrollo,

Ilustración 27 : IDE NetBeans 8.0.2

69

4.2.5 Herramientas Case

Una de las herramientas muy recomendadas usar para el diseño de sistemas es el

Power Designer 16.1.0.3637, es utilizada por la mayoría de desarrolladores y es una

muy buena herramienta para el diseño, se la utilizo para el modelado de base de

datos y los casos de uso UML.

4.2.6 Diseño de modelo Entidad –Relación

Ilustración 28 : Diagrama Entidad Relación. (Fuente Tesista)

70

4.2.7 Diccionario de Datos

ho_alumnos_uce

Nombre Tipo Descripción

al_id_alumnos seal Secuencial autogenerado, llave primaria

al_semestre numeric Semestre

al_numero_alumnos numeric Número de Alumnos por semestre

al_numero_horario numeric Número de Paralelos a Generar para el horario

Tabla 27: Descripción de Entidad Alumnos. (Fuente Tesista)

ho_catalogo_docente_uce


cd_id_catalogo serial Secuencial autogenerado, llave

primaria

cd_descripcion_catalogo character

varying(100) Descripción del Producto

Tabla 28 : Descripción de Catalogo Docente. (Fuente Tesista)

ho_asignaturas_uce


as_id_asignatura serial Secuencial autogenerado, llave

primaria

as_nombre_asignatura character

varying(100) Nombre de la Asignatura

as_creditos numeric Número de Créditos

as_semestre numeric Número de Semestre de la asignatura

Tabla 29 : Descripción de Asignaturas. (Fuente Tesista)

ho_aulas_uce


au_id_aula serial Secuencial autogenerado, llave

primaria

au_nombre_aula character

varying(100) Nombre del Aula

au_capacidad_aula Numeric Número de Alumnos

au_ubicacion character

varying(100) Ubicación del Aula

Tabla 30 : Descripción de Aulas. (Fuente Tesista)

71

ho_aula_horario


ah_id_secuencial Serial Secuencial autogenerado, llave

primaria

ah_id_hora Numeric Nombre de la Asignatura

ah_id_docente Numeric Número de Créditos

ah_id_asignatura Numeric Número de Semestre de la asignatura

ah_lunes character

varying(100) Hora Lunes

ah_martes character

varying(100) Hora Martes

ah_miercoles character

varying(100) Hora Miércoles

ah_jueves character

varying(100) Hora Jueves

ah_viernes character

varying(100) Hora Viernes

ah_id_paralelo Numeric Id paralelo

ah_id_semestre Numeric Id del semestre

ah_docente character

varying(100) Id del docente

ah_id_aula Numeric Id del Aula

ah_opcional character

varying(100) Campo Opcional

Tabla 31 : Descripción de Entidad. (Fuente Tesista)

ho_rol_uce


ro_id_rol Serial

Secuencial autogenerado, llave

primaria

ro_nombre_rol

character

varying(20) Nombre del Rol

ro_descripcion_rol Numeric Descripción del Rol

72

ro_estado Numeric Estado del Rol

Tabla 32 : Descripción de Rol. (Fuente Tesista)

ho_control_horas_uce


ch_id_control_horas Serial Secuencial autogenerado, llave primaria

ch_id_docente numeric Id del docente

ch_numero_horas numeric Número de horas del docente asignadas

ch_primera_hora numeric Primera hora de clases

ch_segunda_hora numeric Segunda hora de clases

ch_tercera_hora numeric Tercera hora de clases

ch_cuarta_hora numeric Cuarta hora de clases

ch_quinta_hora numeric Quinta hora de clases

ch_sexta_hora numeric Sexta hora de clases

ch_septima_hora numeric Séptima hora de clases

ch_octava_hora numeric Octava hora de clases

Tabla 33 : Descripción de Control de Horas. (Fuente Tesista)

ho_detalle_catalogo_docente_uce


dc_id_detalle_catalogo

serial Serial


primaria

dc_id_catalogo numeric Id del Catálogo

dc_padre_catalogo numeric Id del Catálogo padre

73

dc_detalle_descripcion

character

varying(100) Descripción del Catálogo

dc_nemonico

character

varying(100) Nemónico

Tabla 34 : Descripción de Detalle Catálogo. (Fuente Tesista)

ho_docentes_uce


do_id_docente serial

Secuencial autogenerado,

llave primaria

do_nombres_docente

character

varying(50) Nombres del Docente

do_apellidos_docente

character

varying(50) Apellidos del Docente

do_cedula_docente

character

varying(20) Número de Cédula

do_id_detalle_estado_civil numeric Id del estado Civil

do_id_tipo_docente numeric Id del tipo de Docente

do_horario_docente boolean

Flag para generar horario

al docente

do_horario_generado_doc

ente boolean

Flag para genar horario al

docente

do_fecha_nacimiento_doc

ente Date

Fecha nacimiento del

docente

do_fecha_registro_docente Date Fecha de registro del

74

docente

do_estado_docente character(1) Estado del Docente

do_categoria_docente numeric Id Categoría del Docente

Tabla 35 : Descripción de Docentes. (Fuente Tesista)

ho_estudios_docente_uce


ed_id_estudio_docente serial Secuencial autogenerado, llave primaria

dc_id_detalle_catalogo numeric Id del Catálogo

do_id_docente numeric Id del docente

ed_id_detalle_profesion numeric Id de la Descripción del Catálogo

ed_id_detalle_maestria numeric Null

Tabla 36 : Descripción de Estudios Docente. (Fuente Tesista)

ho_horarios_uce


ho_id_horario Serial Secuencial autogenerado, llave primaria

ho_id_docente Numeric Id Docente

ho_primera_hora Numeric Valor Primera Hora

ho_segunda_hora Numeric Valor Segunda Hora

ho_tercera_hora Numeric Valor Tercera Hora

ho_cuarta_hora Numeric Valor Cuarta Hora

ho_quinta_hora Numeric Valor Quinta Hora

ho_sexta_hora Numeric Valor Sexta Hora

ho_septima_hora Numeric Valor Séptima Hora

ho_octava_hora Numeric Valor Octava Hora

75

ho_novena_hora Numeric Valor Novena Hora

ho_decima_hora Numeric Valor Décima Hora

ho_id_asignatura Numeric Id de la Asignatura

ho_id_aula Numeric Id Aula

hd_paralelo Numeric Número de Paralelo

Tabla 37 : Descripción Horario. (Fuente Tesista)

ho_horas_docentes_uce


hd_id_hora_docente Serial Secuencial autogenerado, llave primaria

hd_id_docente numeric Id Docente

hd_primera_hora numeric Valor Primera Hora

hd_segunda_hora numeric Valor Segunda Hora

hd_tercera_hora numeric Valor Tercera Hora

hd_cuarta_hora numeric Valor Cuarta Hora

hd_quinta_hora numeric Valor Quinta Hora

hd_sexta_hora numeric Valor Sexta Hora

hd_septima_hora numeric Valor Séptima Hora

hd_octava_hora numeric Valor Octava Hora

hd_novena_hora numeric Valor Novena Hora

hd_decima_hora numeric Valor Décima Hora

hd_id_asignatura numeric Id de la Asignatura

Tabla 38 : Descripción de Horas Docente. (Fuente Tesista)

76

ho_menu_uce


me_id_menu Serial Secuencial autogenerado, llave

primaria

me_nivel Numeric Id del nivel de menú

me_orden Numeric Orden del Menú

me_nombre character

varying(20) Nombre del menu

me_url character

varying(20) Ubicación de las páginas

me_icono character

varying(20) Icono

me_estado Numeric Estado del Menú

Tabla 39 : Descripción de Menú. (Fuente Tesista)

ho_rol_menu_uce


mr_id_rol_menu serial Secuencial autogenerado, llave primaria

me_id_menu numeric Id del nivel de menú

ro_id_rol numeric Id del Rol

mr_id_rol numeric Id del Ro (foráneas)

mr_id_menu numeric id del menu (foráneas)

Tabla 40 : Descripción de Rol Menú. (Fuente Tesista)

ho_tipo_docentes_uce


td_id_tipo_docente Serial


primaria

td_descripcion character varying(20) Nombre del tipo de docente

td_padre Numeric Id del tipo /categoría docente

77

td_numero_horas Numeric Número de horas del tipo de

docente

Parcial : 10 horas

--> Debe dictar 2 a 4 horas de

clase

Medio Tiempo : 20 horas -

-> Debe dictar 8 a 10 horas de

clase

Tiempo Completo : 40 horas -

-> Debe dictar 16 a 20 horas de

clase

Tabla 41 : Descripción tipo docente. (Fuente Tesista)

ho_usuario_uce


us_id_usuario Serial Secuencial autogenerado, llave

primaria

ro_id_rol character

varying(20) Id del Rol

us_id_rol Numeric Id usuario del Rol

us_usuario Numeric Usuario

us_clave character

varying(20) clave de usuario

us_email character

varying(20) Email

us_estado character (2) estado del usuario

us_usuario_creacion character

varying(20) usuario de creación

us_fecha_creacion Date fecha de creación

us_usuario_modificacion character

varying(20)

usuario que realiza

modificación

us_fecha_modificacion Date fecha de modificación

Tabla 42 : Descripción usuario. (Fuente Tesista)

78

4.3 Presupuesto

El siguiente presupuesto es un cálculo aproximado sobre los gastos que requiere el

proyecto, para el diseño, análisis, desarrollo e implementación

FACULTAD DE INGENIERIA, CIENCIAS FISICAS Y MATEMATICA

ESCUELA DE CIENCIAS

TESIS: SISTEMA DE GESTIÓN DE HORARIOS ACADÉMICOS PARA LA FACULTAD DE CIENCIS FÍSICAS Y MATEMÁTICAS DE LA UNIVERSIDAD CENTRAL DEL ECUADOR

Ítem Rubro

Cantidad Valor Unitario Valor Rubro

Nº Nº $ $

1

RECURSOS HUMANOS

Tutor de Trabajo de Graduación 1 0,00 0,00

Tribunal de Trabajo de Graduación 3 0,00 0,00

Investigador (Autor de Trabajo de Grado) 1 0,00 0,00

SUBTOTAL RECURSOS HUMANOS 0,00

2

RECURSOS MATERIALES

Material de Escritorio:

*Equipos , Servicio Técnico, Software 50,00 50,00

* Resma de papel 5 5,00 25,00

* Tóner de Tinta B/N 2 320,00 320,00

* Cartucho a Color 4 100,00 100,00

* Copias 300 0,02 6,00

Material Bibliográfico :

* Internet 400 0,60 240,00

* Fotocopias de Libros 300 0,02 6,00

*Costo Desarrollador 180(Días) 20,00 3600,00

Empastado del Trabajo de Grado 6 20,00 120,00

SUBTOTAL RECURSOS Y MATERIALES 4467,00

3

OTROS

*Transporte 150,00 150,00

* Gastos varios 1 200,00 200,00

SUBTOTAL OTROS 350,00

TOTAL 4817,00

IMPREVISTOS (10%) 100,00

TOTAL PRESUPUESTO 4917,00

RESUMEN FINANCIAMIENTO DATOS DEL ALUMNO

UCE

$ 0,00 Nombre: Hernán Campoverde

EMPRESA CI: 1714977061

ALUMNO

$4917,00

79

4.4 Cronograma

Planificación del Sistema de Gestión de Horarios Académicos.

Ilustración 29 : Planificación

80

CAPÍTULO 5

5. CONCLUSIONES Y RECOMENDACIONES

5.1 Conclusiones

Se puedo codificar el algoritmo para la generación de horarios académicos.

El sistema ha culminado llegado a su fase de finalización de manera correcta.

Se ha podido diseñar un sistema informático con herramientas de software

libre.

Los Docentes y Estudiantes pueden hacer uso de la aplicación web ya que

tienen la información disponible para hacerlo.

Con la ayuda de la aplicación se pudo optimizar el proceso de generación de

horarios académicos, generándolos en poco tiempo y de manera óptima.

El sistema entra en funcionamiento en la Facultad de Ingeniería en Ciencias

Físicas y Matemática Carrera de Informática sujeto a futuras modificaciones

ya que en un corto plazo de estabilización del sistema se procederá a

implementar en otras facultades de la Universidad Central del Ecuador.

La arquitectura implementada en el proyecto nos ayudó positivamente en

poder usar el patrón MVC para tener una mejor optimización de recursos y

procedimientos a nivel de código.

Es muy importante hacer un análisis del proyecto punto por punto para poder

realizar una buena estimación de tiempos y recursos, ya que si existe alguna

modificación en el alcance del proyecto, esto ocasionaría retrasos en la

entrega del producto al usuario.

También fue muy importante el haber creado funciones que sean óptimas,

basándonos en las buenas prácticas de programación ya que esto no ayuda a

que el algoritmo de generación de horarios académicos no demore mucho en

tiempo de ejecución.

Se debe aprovechar los recursos tecnológicos que disponemos en la

actualidad, sacar el mayor esfuerzo posible a estas herramientas informáticas

ya que así no desperdiciaremos recursos tecnológicos.

Independientemente del lenguaje de programación los sistemas informáticos

no son más rápidos si se codificaron en x o y programa, todo depende del

buen análisis que se debe levantar al inicio de un proyecto como

81

Arquitectura, modelos de programación y tener muy claro lo que el usuario

necesita.

5.2 Recomendaciones

Todo sistema informático necesita de un mantenimiento, dependiendo de la

transaccionalidad, el sistema de generación de horarios académicos

necesitaría a futuro trabajar con tablas históricas.

El personal que manipule el sistema debe tener conocimiento básico de

computación.

Para la generación de horarios se debe hacer por carrera, es decir si queremos

realizar la generación de la carrera de Diseño Gráfico junto con la

Informática debemos aumentar el número de aulas y realizar el ingreso de los

docentes y asignaturas de esta carrera.

A medida que se vaya utilizando el sistema la misma ira madurando en cada

generación, si existe inconsistencias se deberá ir solventando.

82

BIBLIOGRAFÍA

1. ÁLVAREZ, N. (21 de Marzo de 2015). Desarrollo Web. Obtenido de:

http://www.desarrolloweb.com/articulos/que-es-mvc.html

2. ANDREEVSOAI, A., & BERGLERS, S. (2006b). Semantic tag extraction

from wordnet glosses. En In 5th Conference on Language Resources and

Evaluation. Genova: IT.

3. ANDRREVSKAI, A., & BERGLER, S. (2007). In Proceedings of the 4th

International Workshop on Semantic Evaluations. Prague: Association for

Computational Linguistics.

4. BELIALE DIAZ, E. J. (05 de Marzo 2015). Monografias. Obtenido de

http://www.monografias.com/trabajos84/redes-sociales/redes-sociales.shtml

5. CARBONELL, J. (14 de Marzo 2015). Centro Cervantes. Obtenido de

http://cvc.cervantes.es/obref/congresos/sevilla/tecnologias/ponenc_carbonell.

html

6. GARCIA, J. (18 de Abril de 2015). Ceit. Obtenido de

http://www1.ceit.es/Asignaturas/Informat2/Clases/Clases9899/Clase01/JavaE

ntorno/tsld003.htm

7. GIL, J. V. (18 de Abril de 2015). Dataprix. Obtenido de

http://www.dataprix.com/blog-it/big-data/big-data-gestion-datos-no-

estructurados

8. GOSLING, J. (2005). The Java language specification. Addison-Wesley.

Obtenido de http://thesaurus.reference.com. (2007). Roget’s New Millennium

9. THESAURUS, volume 1.3.1. Lexico Publishing Group,LLC, 1st edition.

Obtenido de http://thesaurus.reference.com

1

TERMINOLOGÍA

API: Una interfaz de programación de aplicaciones es un conjunto de convenciones

internacionales que definen cómo debe invocarse una determinada función de un

programa desde una aplicación.

ENCAPSULAMIENTO: Es el ocultamiento del estado, es decir, del dato miembro,

de un objeto de manera que sólo se puede cambiar mediante las operaciones

definidas para ese objeto.

FRAMEWORK: Representa una arquitectura de software que modela las relaciones

generales de las entidades del dominio, y provee una estructura y una especial

metodología de trabajo, la cual extiende o utiliza las aplicaciones del dominio.

HERENCIA: A través de ella los diseñadores pueden crear nuevas clases partiendo

de una clase o de una jerarquía de clases preexistente (ya comprobadas y verificadas)

evitando con ello el rediseño, la modificación y verificación de la parte ya

implementada.

JAVA: Java es un lenguaje de programación por objetos creado por Sun

Microsystems, Inc. que permite crear programas que funcionan en cualquier tipo de

ordenador y sistema operativo.

JEE6: Java Enterprise Edition.

PostgreSQL: es un sistema de gestión de bases de datos objeto-relacional

(ORDBMS) basado en el proyecto POSTGRES, de la universidad de Berkeley.

MVC: Es un patrón en el cual se separan los componentes de una aplicación en tres

capas, la capa de datos, la capa de interfaz y la capa lógica.

RUP: es un proceso de desarrollo de software desarrollado por la empresa Rational

Software, actualmente propiedad de IBM.

SGHA: Sistema de generación de horarios académicos.

POLIMORFISMO: Se refiere a la posibilidad de enviar un mensaje a un grupo de

objetos cuya naturaleza puede ser heterogénea.

2

RDBMS: (Sistema de Gestión de Bases de Datos Relacionales), se basa en el modelo

relacional como inventado. Muchas bases de datos populares actualmente en uso se

basan en la base de datos relacional modelo.

HTTP: Protocolo de transferencia de hipertextos.

HTML: Lenguaje de marcas de hipertexto.

POO: Programación orientado a objetos.

SSL: Capa de conexión segura.

SQL: Lenguaje de consulta estructurado.

XML: Lenguaje de marcas extensible.

3

ANEXOS

A.- Manual de Usuario


FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y

MATEMÁTICA

CARRERA DE INFORMÁTICA

MANUAL DE USUARIO




TUTOR: Ing. Carrillo Flores René Alfonso MSc.

QUITO – ECUADOR

2015

4

Introducción

El sistema GESTIÓN DE HORARIOS ACADÉMICOS tiene la funcionalidad de

automatizar los procesos que se lleven a cabo dentro de la Facultad de Ciencias

Físicas y Matemática para la generación de sus horarios académicos y dar un

correcto seguimiento a los datos generados por la herramienta, esta aplicación web

administra información de los docentes, disponibilidad de los docentes, horarios de

los docentes para dictar sus cátedras, aulas, capacidad de las aulas, las cátedras que

se dictan en cada aula, disponibilidad de las aulas, asignaturas, número de créditos de

las asignaturas por semestre, reporte general del horario académico de la carrera de

informática.

1 Generalidades

1.1 Acerca del Manual

La Facultad de Ciencias Físicas y Matemáticas se encuentra realizando la

elaboración del horario académico de manera manual de una forma que para los

estándares actuales de tecnología puede calificarse como rudimentaria. De esta

manera la generación del horario no cuenta con una fuente centralizada de

almacenamiento ni un sistema que se acople a las necesidades de su actividad por lo

cual conlleva horas de mucho trabajo y esfuerzo en poder realizar el análisis para la

elaboración de los horarios que cumplan y se acoplen con los docentes y la

infraestructura que posee la institución.

Por lo enunciado el sistema informático cubrirá las necesidades tecnológicas que la

Facultad de Ciencias Físicas y Matemáticas de la Universidad Central del Ecuador

que como institución educativa requieren de manera inmediata y además permitirá

una mejor administración de los docentes y su infraestructura.

A continuación se presenta el siguiente manual para la correcta administración del

aplicativo web y se lo pueda utilizar de manera efectiva utilizando toda la capacidad

que el sistema GENERACIÓN DE HORARIOS ACADÉMICOS les ofrece.

BIENVENIDOS AL SISTEMA GESTIÓN DE HORARIOS ACADÉMICOS

2

2 Menú

El siguiente menú nos lleva a cada una de las funcionalidades del sistema que a

continuación se procederá a describir. Figura 2.1.

Figura 2.1 Menú

2.1 Registrar

2.1.2 Registro de Aulas

Figura 2.2 Registro Aulas

3

La figura 2.2 nos ayuda a registrar las aulas, solicita nombre del aula, capacidad del

aula y la ubicación de la misma.

La capacidad del aula es para saber si la asignatura que se va a impartir cumple con

la cantidad de alumnos.

Figura 2.3 Editar Aula.

En la figura 2.3 se puede realizar la edición de los datos del aula ingresada, el

nombre, capacidad o la ubicación pueden ser los valores a cambiar.

Figura 2.4 Eliminar Aula.

También se puede realizar la eliminación de registro de aulas mal ingresados.

4

Figura 2.5 Registrar Asignaturas.

Para realizar el ingreso de las asignaturas procedemos a utilizar la pantalla de registro

de asignaturas, la misma que puede ser accedida pro el menú.

Figura 2.6 Menú Registrar Asignatura.

Todos los datos de la pantalla son obligatorios y validados, si no se ingresa alguno

nos muestra un mensaje de error y no permite realizar el ingreso del registro.

Figura 2.7 Validación Incorrecta

5

Cuando se completa la acción de registro de manera correcta se muestra el siguiente

mensaje.

Figura 2.8 Registro Correcto.

Para poder realizar la edición del registro se debe dar click en el botón que se

encuentra adjunto en la grilla de consulta.

Figura 2.9 Modificar Registros.

A continuación se nos despliega una pantalla con los datos de la asignatura

seleccionada para la correspondiente modificación,

Figura 2.10 Modificar Registro Asignatura.

6

Para poder acceder a la opción de eliminación de registro asignatura procedemos de

la siguiente manera, damos click en el siguiente icono.

Figura 2.11 Eliminar Registros Asignatura

Nos presenta la siguiente pantalla con el registro a ser eliminado.

Figura 2.12 Pantalla de eliminación de Asignatura.

Realizada la eliminación del registro se presenta el siguiente mensaje de

confirmación indicando que el registro ha sido modificado de manera correcta.

Figura 2.13 Eliminación Correcta del registro aula.

7

Registrar la Categoría del dicente

La siguiente acción de registro se la realiza en la siguiente navegabilidad:

Figura 2.14 Menú Categoría Docente

La presente pantalla es la siguiente, la cual se debe ingresar la categoría del docente

dependiendo del tipo de horario seleccionado.

Figura 2.15 Pantalla de Registro de Categoría Docente

Se debe tener en cuenta lo siguiente para poder realizar el ingreso de horas para la

categoría del docente.

Categoría Docente Descripción

Parcial 10 horas --> Debe dictar 2 a 4 horas de clase

Medio Tiempo 20 horas --> Debe dictar 8 a 10 horas de clase

Tiempo Completo 40 horas --> Debe dictar 16 a 20 horas de clase

Tabla 1 Horas Categoría Docente

8

Cabe señalar que solo tenemos tres tipos de categoría de docentes, para los cuales se

les puede hacer la edición de los valores parametrizados.

Figura 2.16 Pantalla de Modificación de Categoría Docente

Registrar Horas Docentes

Para poder realizar el registro de las horas del docente se debe realizar los siguientes

pasos.

Crear el Docente, en la pantalla correspondiente

El cliente nuevo se mostrara en la siguiente pantalla, a la cual se puede

acceder por la siguiente navegabilidad:

Menú Registrar Horas Docentes

Figura 2.17 Pantalla para asignar horas a docentes.

9

Una vez que tenemos el cliente nuevo en la figura 2.17 se puede acceder a

realizar el registro del horario.

EL registro del horario que se está realizando en esta pantalla no es el horario

definitivo para que el docente imparta sus clases, hasta el momento no

estamos generando ningún horario.

Las horas seleccionadas son un rango en las que el sistema recorrerá todo el

universo de profesores, aulas y asignaturas para poder generar el horario.

Estas horas son tentativas para que el sistema pueda seleccionar un horario

que esté acorde.

A continuación presentamos la pantalla de registro de horas del docente.

Figura 2.18 Pantalla para asignar horas a docentes.

Esta pantalla tiene dos funcionalidades, registrar las horas de los docentes y

seleccionar las asignaturas que el docente va a dictar cátedra.

10

Figura 2.19 Pantalla para asignar horas a docentes

En la figura 2.19 se puede realizar el registro de la asignatura o las asignaturas

seleccionadas para que el docente pueda entrar en el proceso de generación de

horarios con las horas seleccionadas en esta pantalla.

2.2 Consultas

Para el módulo de consultas se puede acceder por el siguiente menú.

Figura 2.20 Pantalla para Consultas

11

2.2.1 Consultas Asignaturas

Figura 2.21 Pantalla para Consultas Asignaturas

En esta pantallas a más de poder realizar las consultas, se puede filtrar por nombre y

también se puede realizar modificaciones de los registros de acuerdo a lo indicado en

la sección de registros/ modificación / de registros.

2.2.3 Consulta de Aulas

Figura 2.22 Pantalla para Consultas Aulas

12

En esta pantallas a más de poder realizar las consultas de las aulas, se puede filtrar

por nombre y también se puede realizar modificaciones de los registros de acuerdo a

lo indicado en la sección de registros/ modificación / de registros.

2.2.4 Consulta de Aulas

Figura 2.23 Pantalla para Consultas Categoría Docente

En esta pantallas a más de poder realizar las consultas de la categoría docente, se

puede filtrar por nombre y también se puede realizar modificaciones de los registros

de acuerdo a lo indicado en la sección de registros/ modificación / de registros.

2.2.5 Consulta de Horas Docente

Figura 2.24 Pantalla para Consultas Horario Docente

En esta pantalla se tiene tres opciones para poder realizar consultas referentes al

docente, las materias seleccionadas para dictar la cátedra, las horas seleccionadas

para poder dictar las clases y las clases asignadas que le fueron otorgadas con la

13

materia y aula cuando el sistema ha realizado la generación de horarios académicos,

a continuación se indica las pantallas de consulta.


La interpretación de la siguiente consulta es la siguiente:

El Docente Ing. Iván Naula va a dictar tres clases, Fundamentos de

Matemática, Análisis II y Análisis III


14

3 Generación de Horario

Figura 2.27 Pantalla para Generar el horario.

Una vez realizada el ingreso de los datos del docente, horarios, asignaturas, aulas,

cantidad de alumnos, procedemos a la generación de horarios, damos click en el

botón generar.

El resultado obtenido es el que se muestra a continuación.

Figura 2.28 Pantalla para Generar el horario.

15

También se puede visualizar el horario en la pantalla de consulta de horarios, el cual

podemos acceder por el menu:

Figura 2.29 Menú para acceso a Generar el horario.

La pantalla que se despliega es desde Primer a Noveno Semestre, para este caso

generamos uno horario por semestre.

Primer Semestre

Figura 2.30 Horario para primer semestre.

Segundo Semestre

Figura 2.31 Horario para segundo semestre.

16

Tercer Semestre

Figura 2.32 Horario para tercer semestre.

Cuarto Semestre

Figura 2.33 Horario para cuarto semestre.

Quinto Semestre

Figura 2.34 Horario para quinto semestre.

17

Sexto Semestre

Figura 2.35 Horario para sexto semestre.

4.- Exportar a Excel

Finalmente tenemos la opción de exportar a Excel los horarios generados desde la

misma pantalla de consulta de horarios lo podemos hacer.

Figura 2.36 Generar Reporte

Figura 2.37 Reporte Excel.

18

ANEXOS

B. Manual de Instalación


FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y

MATEMÁTICA

CARRERA DE INFORMÁTICA

MANUAL DE TÉCNICO




TUTOR: Ing. Carrillo Flores René Alfonso MSc.

QUITO – ECUADOR

2015

19

1 Generalidades

1.1 Introducción

El presente documento tiene el objetivo principal de ser una ayuda didáctica para

efectuar de manera correcta la instalación del aplicativo web Generación de

Horarios Académicos.

A continuación se presenta el entorno en el cual se debe realizar la instalación y los

componentes que se requieren para tener el ambiente óptimo para el levantamiento y

ejecución del aplicativo.

BIENVENIDOS A LA GUIA PARA INSTLACIÓN DEL SISTEMA GESTIÓN

DE HORARIOS ACADÉMICOS

1.2 Objetivo

Guiar de manera puntual y efectiva al personal del laboratorio de la unidad

educativa para que pueda realizar la instalación del aplicativo web.

20

1 Requisitos

A continuación se realiza la descripción de los componentes necesarios para poder

realizar el levantamiento del aplicativo.

1.1 Software

REQUERIMIENTO DE HARDWARE

Memoria 4 GB

Procesador Inter Core 2 Duo

Espacio Disco 10 GB

Video 1024 x 728

CD/DVD SI

USB SI

REQUERIMIENTO DE SOFTWARE

Sistema Operativo Windows XP, Windows 7, Windows 8

Tipo de Sistema Sistema operativo de 64 bits, procesador

x64

Máquina virtual de Java (JVM) JDK (jdk-7u67-windows-i586)

Entorno de Desarrollo Integrado

(IDE)

NetBeans IDE 8.0.2

Motor de Base de Datos Postgresql-9.2-1002.jdbc4

Servidor de Aplicaciones GlassFish Server 4.1

Navegador Google Chrome

2 Instalación Software

2.1 JDK

Ingresar el CD/DVD de instalación del sistema de Gestión de Horarios

Académicos, a continuación realizar lo siguiente:

21

Abrir el CD/DVD y encontramos la carpeta SGHA_UCE.

Fig. 3.1 Directorio Principal.

Ingresamos a la carpeta, dentro de la misma encontramos la carpeta

Instaladores, seleccionamos la carpeta correspondiente al sistema operativo

en el cual se va a realizar la instalación.

Fig. 3.2 Instaladores.

Una vez seleccionada el directorio buscamos la carpeta JDK, accedemos a

ella y encontramos el archivo ejecutable, el mismo que se procederá a

instalar como administrador del computador.

Fig. 3.3 Instalador JDK.

Damos click derecho sobre el instalador y seleccionamos ejecutar como

administrador y procedemos a realizar dicha acción seleccionando la opción

Sí que se presenta en la Fig. 3.4

Fig. 3.4 Permitir instalar el JDK.

22

Luego de haber seleccionado la opción si de la figura anterior, nos despliega

la siguiente pantalla de bienvenida de la instalación del JDK.

Fig. 3.5 Bienvenida a la Instalación de JDK.

Seleccionamos Next (Siguiente) para continuar con la instalación, nos

solicita que se escoja la ruta en donde se realizara la instalación del jdk para

la misma se dejara la ruta por default que nos presenta la instalación.

Fig. 3.6 Ruta de Instalación para JDK.

Seleccionamos Next (Siguiente) para continuar con la instalación, tomara

unos minutos mientras finaliza.

23

Una vez que finaliza nos mostrara una pantalla de instalación del JRE, de

igual forma no modificamos la ruta, en esta pantalla nos muestra un path en

donde se realizará la instalación por defecto, damos click en Next

(Siguiente).

Fig. 3.7 Instalación destino del JRE.

La instalación del JRE culmina de manera rápida, esta es la última etapa para

la finalización de la instalación del JDK/JRE, nos muestra la última pantalla

a la cual le damos en Close (Cerrar) de esta manera damos por cerrada la

instalación del JDK.

Fig. 3.8 Finalización de la Instalación JDK.

24

3 Creación de la variable de entorno

3.1 Configuración Variable

Ingresamos a Mi Equipo

Fig. 4.1 Acceso a Mi equipo.

Damos click derecho en la pantalla que se nos muestra y seleccionamos en el

menú desplegable la opción propiedades.

Fig. 4.2 Propiedades de Mi Equipo.

Una vez seleccionada la opción propiedades damos click y nos presentara la

pantalla de Configuración Avanzada del Sistema, en la misma procedemos a

dirigirnos a la parte superior izquierda de la pantalla, seleccionamos la

opción Configuración avanzada del sistema y damos click.

Fig. 4.3 Configuración Avanzada del Sistema.

25

Ingresamos a la opción seleccionada en la Fig. 4.3 y procedemos a realizar la

configuración correspondiente, se nos presenta la pantalla de propiedades del

sistema que a continuación se muestra.

Fig. 4.4 Propiedades del Sistema.

En esta pantalla damos click en el botón Variables de entorno la misma que

nos llevara a la siguiente pantalla.

Fig. 4.5 Variables de entorno.

26

En la pantalla de creación de variables de entorno seleccionamos el botón

nueva, damos click en el para poder realizar la creación de la nueva variable.

Fig. 4.6 Creación de una variable de entorno.

Para la creación de la nueva variable damos click donde señala la fecha de

color azul, se nos muestra la pantalla para la creación de una nueva variable

de entorno, donde señala la flecha de color verde digitamos el nombre de la

variable JAVA_HOME y en valor de la variable colocamos la ruta de

instalación de JDK por defecto será C:\Program Files\Java\jre1.8.0_31 y

damos click en aceptar, al resto de pantallas antecesores abiertas también le

damos aceptar para poder finalizar de manera exitosa la creación de la

variable.

Fig. 4.7 Creación de una variable de entorno JAVA_HOME.

27

4 Instalación de Base de Datos

5.1 Postgresql-9.2-1002

UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE … · Ilustración 7 : Librería Primefaces. ... IDE...

Documents

Transcript of UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE … · Ilustración 7 : Librería Primefaces. ... IDE...