unidad acadÉmica de ingenierÍa civil...

UNIDAD ACADÉMICA DE INGENIERÍA CIVIL

CARRERA DE INGENIERÍA DE SISTEMAS

TEMA: ANALISIS DE UN SISTEMA INFORMÁTICO DE GESTIÓN DE PROGRAMAS DE

DOCTORADO UTILIZANDO DIAGRAMAS UML PARA LA ESCUELA POLITÉCNICA AMAZÓNICA

TRABAJO PRÁCTICO DEL EXAMEN COMPLEXIVO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERA DE SISTEMAS

AUTORA: MINDA VERA GIANELLA ANAIS

MACHALA|EL ORO

1

1. INTRODUCCION

Las unidades académicas a partir de los últimos años han ido evolucionando a la par

de la tecnología y requieren que sus servicios educativos estén apoyados por sistemas

informáticos, ya que ”Un sistema de información es un conjunto formal de procesos

que, operando sobre una colección de datos estructurada según las necesidades de la

empresa, recopilan, elaboran y distribuyen la información (o parte de ella) necesaria

para las operaciones de dicha empresa y para las actividades de dirección y control

correspondientes (decisiones) para desempeñar su actividad de acuerdo a su

estrategia de negocio” (Andreu, 1998)

Para gestionar de manera eficaz la información se necesita primeramente de un

análisis de las actividades así como también de los requerimientos de la institución

logrando así un diseño adecuado con la finalidad de asegurar un buen camino para el

desarrollo del software. Se ha realizado este trabajo tomando en cuenta la problemática

descrita en el caso práctico de estudio, para ello se ha utilizado una metodología de

diseño orientado a objetos, apta y adaptable para trabajar en proyectos de gran

magnitud de información.

1.1. MARCO CONTEXTUAL

La Universidad Politécnica Amazónica ofrece a su estudiantado cursos de doctorado, y

debido a la acogida de los mismos maneja una gran cantidad de datos que de forma

manual sería imposible organizar de manera rápida, por estas razones es que la

institución necesita de un sistema de información que le permita gestionar de manera

eficaz todas las actividades referentes al departamento de cursos de doctorado.

1.2. PROBLEMA

El departamento de cursos de doctorado dictados en la Escuela Politécnica Amazónica

no cuenta con el apoyo de un sistema informático mediante el cual se registren los

cursos impartidos en una base de datos para su gestión incluyendo también la

información relacionada a las personas involucradas en dichas actividades académicas

que pueden ser estudiantes de doctorado o profesores, teniendo en cuenta también los

requerimientos que han sido especificados en el caso de estudio para así otorgar un

sistema ágil y eficaz que automatice la gestión referente a los cursos de doctorados de

la institución.

2

Por ello se plantea el siguiente problema, que consiste en la necesidad de analizar y

diseñar todos los procesos llevados a cabo en los programas de doctorado organizados

por los departamentos de la Escuela Politécnica Amazónica, evitando de esta manera

posibles errores en las posteriores etapas de desarrollo de un sistema informático que

cumpla con las funciones de gestión de información de dichos programas de doctorado

de manera eficaz.

1.3. OBJETIVO GENERAL

Analizar y diseñar un sistema de gestión de programas de doctorado realizados en la

Escuela Politécnica Amazónica, a través de la aplicación de una metodología orientada

a objetos ICONIX, para que se lleve de manera organizada la información generada en

el campo administrativo y académico de los programas de doctorado.

2. DESARROLLO

2.1. MARCO TEÓRICO

2.1.1. ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

“El análisis y diseño orientado a objetos constituyen un enfoque distinto de desarrollo

de sistemas. Estas técnicas se basan en los conceptos de la programación orientada a

objetos, que han sido codificados en UML, un lenguaje estandarizado de modelación

en el cual los objetos generados no solo incluyen código referente a los datos sino

también instrucciones acerca de las operaciones que se realizarán sobre los datos.”

(Kendall, 2005)

2.1.2. LENGUAJE UML

“El UML es un lenguaje de modelado, y no un método. La mayor parte de los métodos

consisten, al menos en un principio en un lenguaje y en un proceso para modelar. El

lenguaje de modelado es la notación (principalmente gráfica) de que se valen los

métodos para expresar los diseños. El proceso es la orientación que nos dan sobre los

pasos a seguir para hacer el diseño.” (Martin Fowler, 1999).

3

2.1.2.1. DIAGRAMA DE CASOS DE USO

“Muestran los actores y casos de uso del sistema, se utilizan con regularidad durante el

modelado del sistema para poder representar lo que cada uno de los usuarios realiza

desde su perspectiva.” (Booch, 1999)

2.1.2.2. DIAGRAMA DE CLASES

“Muestran un conjunto de clases y sus relaciones, proporcionan una perspectiva

estática del sistema, es decir, representan su diseño estructural.” (Booch, 1999)

2.1.2.3. DIAGRAMA DE OBJETOS

“Muestran un conjunto de objetos y sus relaciones, una situación concreta en un

momento predeterminado. Representan instantáneas de instancias de los elementos

que aparecen en el diagrama de clases. Un diagrama de objetos expresa la parte

estática de una interacción. Para ver los aspectos dinámicos de la interacción se utiliza

los diagramas de interacción, es decir diagramas de secuencia y diagramas de

comunicación/colaboración.” (Booch, 1999)

2.1.2.4. DIAGRAMAS DE INTERACCIÓN

Los diagramas de interacción tratan de demostrar la comunicación entre los objetos y

relaciones a través de los mensajes Muestran una interacción concreta: un conjunto de

objetos y sus relaciones, junto a los mensajes que se envían entre ellos. Un diagrama

de secuencia se puede transformar mecánicamente en un diagrama de comunicación y

viceversa.

2.1.2.4.1. DIAGRAMA DE SECUENCIA

Los diagramas de secuencia representan el orden temporal de los mensajes que se

intercambian entre las diferentes interfaces y actores que participan en el sistema.

4

2.1.2.4.2. DIAGRAMA DE COLABORACIÓN

Organizan de manera estructurada a los objetos o entidades que realizan peticiones

dentro del sistema, es decir, que realizan intercambio de mensajes.

2.1.3. DICCIONARIO DE DATOS

El diccionario de datos contiene descripciones de los datos registrados en las tablas de

la base de datos, se van detallando aspectos de cada una de las variables contenidas

en cada tabla (descripciones, significados, estructuras, consideraciones de seguridad,

etc.). Gracias a estos se puede determinar lo que requiere el sistema, y es de gran

ayuda en el diseño del proyecto.

2.1.4. HERRAMIENTA “DIA”

Ilustración 1: Logo del editor de diagramas DIA Fuente: http://3.bp.blogspot.com/-wjLh9Je9uAo/VH9XbDFLDnI/AAAAAAAAEzc/XRRg_KGj6Bo/s1600/DIA_1.PNG

El programa de libre uso, Dia, es una herramienta muy útil a la hora de realizar

diagramas UML en la etapa de análisis y diseño de un sistema ya que dispone de

múltiples opciones necesarias para crearlos o modificarlos, distintas formas

geométricas para insertar en los diagramas y un entorno cuadriculado que permite

distribuir uniformemente los elementos que componen a nuestros diagramas. Además

brinda la opción de exportar nuestro diagramado en diferentes extensiones de archivos

de imagen.

5

2.2.- MARCO METODOLÓGICO

Para la resolución de la problemática planteada en este caso de estudio se hace uso

de una metodología orientada a objetos, ágil y dinámica, denominada ICONIX. que nos

indica las fases o etapas del proceso de desarrollo de software, de las cuales en el

presente trabajo se destacan la fase de Análisis de requisitos y la fase de Análisis y

Diseño preliminar.

2.2.1. METODOLOGIA ICONIX

Ilustración 2: Logo de ICONIX Fuente: http://ima.udg.edu

Según (EcuRed Enciclopedia cubana, 2014) “Iconix es una metodología pesada-ligera

de Desarrollo del Software cuyo ciclo de vida iterativo e incremental y se lleva mediante

casos de uso para lograr como resultado la obtención del sistema final.“

2.2.1.1. FASES DE ICONIX

Según (EcuRed Enciclopedia cubana, 2014) “Iconix está compuesto de cuatro fases. El

análisis de requisitos, luego el análisis y diseño preliminar, seguido de la fase de diseño

y finalmente la implementación.”

Metodología ICONIX

Etapa Actividad Técnica Entregable

Análisis de

Requerimientos

Establecer

requerimientos de

funcionalidad.

Entrevistas, encuestas

a personas integradas

al proyecto.

Documento: Listado de

requerimientos.

Modelar los casos de

uso. Diagrama de

Casos de uso.

Lenguaje UML.

Diagrama y

especificación de Casos

de Uso.

Análisis y

Diseño

Preliminar

Se analiza el

proyecto Lenguaje UML. Diagrama de Clases.

Modelo de datos.

6

Diseño

Detallado

Asignar

Comportamiento. Diagrama de

Secuencia.

Lenguaje UML.

Diagrama de Secuencia

por cada caso de uso.

Diagrama de Clases.

Modelo de Datos.

Implementación Generar Código Código Fuente

Realizar pruebas

funcionales.

Iteración el

usuario final. Software funcionando

correctamente.

Tabla 1: Etapas de la metodología ICONIX Desarrollado por: Gianella Minda

2.2.1.1.1 Fase de Análisis de Requisitos

Según (Universitat de Girona, pág. 1) <<Primero se arma un Modelo de Dominio, es

decir un Diagrama de Clases muy simplificado. Solamente se incluyen los objetos de

los cuales se necesita almacenar su información en el sistema.>> En la etapa de

análisis de requisitos se pone atención a los requerimientos descritos en el caso de

estudio, dichas especificaciones son las que se utilizan para pasar a la etapa de diseño

y así, en base a éstas, se elaboran los diagramas solicitados.

2.2.1.1.1.1. Diagrama de casos de uso

En este diagrama se mostrarán los principales actores y el modo como se relacionan

entre ellos dentro de un diagrama de casos de uso de alto nivel, seguido después de

diagramas de casos de usos específicos, donde primordialmente se debe identificar a

los actores que participan en el sistema a desarrollar.

2.2.1.1.1.2. Identificación de actores

De acuerdo a las funcionalidades del sistema se ha detectado claramente 5. Actores

con roles diferentes:

Administrador: es quien tendrá acceso a todas las funcionalidades

del programa y quien registrará a las personas que van a tener

acceso al sistema

Profesor: Es quien se encontrará laborando en la institución y que

tendrá acceso a módulos como el de gestión de notas

Secretaria: Llevará a cabo los procesos de matriculación de nuevos

estudiantes y asignaciones de cursos a nivel facultad o área.

7

Secretaria Administrativa: Registra al nuevo personal y labora a

nivel global de la institución

Estudiante: Es quien podrá acceder a cursos de doctorado en la

institución con un registro de matrícula y notas académicas.

Persona: Es un usuario del sistema que aún no pasa por el proceso

de matriculación.

Ilustración 3: Actores del Sistema de Gestion de Programas de Doctorado

Desarrollado por: Gianella Minda

2.2.1.1.2 Fase de Análisis y Diseño preliminar

En esta etapa se debe especificar el comportamiento del sistema por medio de un

diagrama de secuencia.

El diagrama de secuencia muestra la comunicación entre los objetos dentro de una

vista temporal donde muestra las opciones o eventos que podrían tomar los casos de

uso. Una vez realizado se pueden determinar los métodos de las clases del sistema ya

que se ve la interacción entre los objetos y los actores.

2.3. RESULTADOS

En la problemática de este caso práctico, una vez dadas las especificaciones, se

solicita como primer punto el desarrollo de un diagrama de caso de uso, el cual se

realizó identificando primeramente a los actores principales que intervienen en el

sistema y los eventos que realizan, además de ir señalando las relaciones que existen

entre ellos, luego utilizando el editor de diagramas DIA y sus diferentes herramientas y

conectores se fue plasmando dicho diagrama cuidando de que dichas conexiones no

se crucen entre sí. (Véase Anexo 1)

En el segundo punto se ha pedido un cuadro de actores y relaciones, el cual se pudo

resolver especificando los casos de uso del diagrama anterior, dándoles en dicho

8

cuadro una identificación, su nombre de caso de uso, los actores que la generan, su

propósito, una breve descripción, tipo, y las condiciones previas para que se cumplan.

(Véase Anexo 2)

En el siguiente punto se pide realizar un diagrama de clase para lo cual se toman las

principales tablas del caso práctico, que consisten en los actores y eventos del sistema

cuyos datos deben ser guardados en el sistema, relacionados entre sí y con sus

respectivos atributos y métodos. (Véase Anexo 3)

Además en el cuarto punto se solicita elaborar un diagrama de objetos; para

desarrollarlo se tomó en cuenta el diagrama de clases ya que son similares pero con la

diferencia de que este diagrama es orientado a objetos y en él se definen además de

los campos, el tipo de variable de cada uno de ellos. (Véase Anexo 4)

En el siguiente literal se ha tomado cada objeto que participa en el sistema y dentro de

un cuadro se va definiendo campo por campo, su nombre, descripción, tipo de dato,

contenido y se puntualiza la relación que tiene a su vez con otros campos. (Véase

Anexo 5)

En este literal se da solución al literal donde se pide la elaboración del modelo entidad

relación de la base de datos, este es el paso más importante y el punto de partida para

desarrollar este caso práctico ya que en este modelo se ubican, como su nombre lo

indica, las entidades y relaciones que existen dentro del sistema, es decir los objetos

de los que queremos almacenar información y cómo se comunican entre ellos. (Véase

Anexo 6)

En cuanto al diseño físico de la base de datos se lo realizó partiendo desde el modelo

entidad relación y aquí se definen en cada entidad los atributos o campos que poseen,

sus relaciones y cardinalidad, con este modelo ya es posible generar nuestro archivo

físico de la base de datos en un gestor. (Véase Anexo 7)

En el último punto se solicita realizar diagramas de interacción, que comprenden

diagramas de secuencia y de colaboración, en el primer caso se toman las entidades y

se representa la secuencia de mensajes y la transferencia de control entre un objeto y

otro. (Véase Anexo 8). Mientras que el diagrama de colaboración consiste en ubicar a

9

las entidades y la forma en como estas deberían interactuar con las interfaces del

sistema a desarrollar. (Véase Anexo 9).

3. CONCLUSIONES

En este trabajo práctico se ha analizado y diseñado un sistema de gestión de

programas de doctorado para la Escuela Politécnica Amazónica mediante la aplicación

de metodología orientada a objetos, se ha hecho caso de cada requerimiento indicado

en el caso de estudio dando como resultado diagramas con información clara y

concisa, lo cual reafirma la importancia de no ir directamente a la codificación y llevar

ordenadamente un proceso previo de análisis y diseño en proyectos de sistemas

informáticos de esta magnitud para garantizar la eficacia y minimizar el impacto y

número de errores en las siguientes etapas de desarrollo de un software.

Realizar el análisis y diseño orientado a objetos del sistema informático de Gestión de

Programas de Doctorado de la Escuela Politécnica Amazónica requiere tiempo pero es

justificable en vista a los beneficios de ello, como el lograr a través del modelamiento

UML una comprensión de alto nivel de las entidades y actividades involucradas. Todas

estas actividades que fueron llevadas a cabo durante al desarrollo de este trabajo

práctico se realizaron en beneficio de la institución, específicamente en cuanto a los

programas de doctorado que imparte buscando agilizar sus procesos de registros a

través de un sistema informático.

10

4. REFERENCIAS BIBLIOGRÁFICAS

EcuRed Enciclopedia cubana. (2014). Recuperado el 15 de Mayo de 2014, de

http://www.ecured.cu/index.php/ICONIX

Andreu, R. (1998). Estrategia y Sistemas de Información. Mc-Graw Hill.

Belduma, F. J. (2015). repositorio.uisrael.edu.ec. Obtenido de

http://repositorio.uisrael.edu.ec/bitstream/47000/647/1/UISRAEL-EC-ELDT-378.242-93.pdf

Booch, G. R. (1999). El lenguaje unificado de modelado (Vol. 1). Addison-Wesley.

Carla Patricia de San Martin. (2010). Metodologia ICONIX. Recuperado el 08 de octubre de 2015, de

http://www.portalhuarpe.com.ar/Seminario09/archivos/MetodologiaICONIX.pdf

GONZALES, I. D. (2013). repository.upb.edu. Obtenido de

http://repository.upb.edu.co:8080/jspui/bitstream/123456789/2146/1/digital_23726.pdf

Kendall, J. E. (2005). Análisis y Diseño de Sistemas. Pearson Educacion.

Martin Fowler, K. S. (1999). UML gota a got. Pearson.

Salinas, P. (30 de Octubre de 1996). Tutorial de UML. Recuperado el 13 de Abril de 2014, de

http://users.dcc.uchile.cl/~psalinas/uml/modelo.html

Universitat de Girona. (s.f.). Recuperado el 15 de Mayo de 2014, de http://ima.udg.edu/~sellares/EINF-

ES2/Present1011/MetodoPesadesICONIX.pdf

11

5. ANEXOS

ANEXO 1: DIAGRAMA DE CASO DE USO - ALTO NIVEL

Anexo 1: Alto Nivel del Sistema de Gestion de Programas de Doctorado

12

ANEXO 1-2: DIAGRAMA CASO DE USO - ESPECÍFICO

Anexo 1-2: Diagrama de Caso de Uso Específico - Gestión Programas de Doctorado

Anexo 1-1: Diagrama de Caso de Uso Específico - Gestion Administrativo

13

Anexo 1-4: Diagrama Caso de Uso Específico - Gestión Tutoría

Anexo 1-3: Diagrama de Caso de Uso Específico - Gestion Becas

14

Anexo 1-5: Diagrama de Caso de Uso Extendido - Gestión Listar

15

ANEXO 2: CUADRO DE ACTORES Y RELACIONES

Identificación: CU1

Caso de Uso: Gestión Administrativa

Actores: Secretaria Administrativa

Propósito: Que se registren todas las facultades departamentos y áreas de la universidad.

Descripción: La secretaria ingresa al sistema y luego registra la facultad, el departamento y el área donde el imparte clases

Tipo: Primario y esencial.

Condiciones Previas: La secretaria Administrativa debe haberse logeado previamente Anexo 2: Cuadro de Actores y Relaciones del Sistema de Gestión de Programas de Doctorado


Caso de Uso: Gestión Programa Doctorado


Propósito: Registrar los cursos de doctorado que se van a impartir en la universidad

Descripción: La secretaria ingresa al sistema y luego va a la opción gestionar programa doctorado luego ingresa la promoción, el aula, el horario y el temario


Condiciones Previas: CU1

16


Caso de Uso: Gestión Becas


Propósito: Registrar las becas que se darán, los requisitos a cumplirse para obtenerla y observar quien las solicita.

Descripción:

La secretaria ingresa al sistema y luego va a la opción gestión becas en donde registrara la información necesaria de la beca así como a los estudiantes que la solicitan, podrá solo otorgar becas a estudiantes que cumplan todos los requisitos


Condiciones Previas: CU1, CU2


Caso de Uso: Gestión Matricula

Actores: Secretaria Administrativa, Persona, Profesor

Propósito: Matricular a las personas o profesores que soliciten realizar un curso de doctorado

Descripción: La secretaria ingresa al sistema y luego va a la opción matricula acá se encargara de crear al estudiante con sus datos personales, además agrega las

17

asignaturas y las formas de pago, los profesores no podrán matricularse en el mismo doctorado que ellos ya hayan realizado.


Condiciones Previas: CU1, CU2


Caso de Uso: Gestión Tutoría

Actores: Secretaria Administrativa, Profesores, Estudiante

Propósito: Saber quiénes son doctores y así mismo asignarles tutorados a los docentes y tutores a los estudiantes.

Descripción: La secretaria ingresa al sistema y luego va a la opción gestión tutoría, una vez en esta opción se podrá listar a todos los doctores según la facultad y se les asignara tutorados.


Condiciones Previas:

CU1, CU2, CU4


Caso de Uso: Gestión notas

Actores: Profesor

Propósito: Ingresar las notas de cada uno de los estudiantes a quien imparte clase.

Descripción: El profesor ingresa las notas de cada uno de sus estudiantes, así mismo permite crear actas de notas finales.



CU1, CU2, CU4

18


Caso de Uso: Gestión reportes


Propósito: Generar reportes tanto de docentes, tutores, estudiantes y notas finales

Descripción:

La secretaria ingresa al sistema y luego va a la opción gestión reportes, puede imprimir los reportes que quiere con respecto a los profesores y tutores orientados a ayudar a los estudiantes, así también el reporte de los estudiantes que siguen el curso y por último el reporte de notas finales.



CU1, CU2, CU4, CU5, CU6


Caso de Uso: Gestión Listar

Actores: Estudiante

Propósito: Poder visualizar las notas y la matricula del estudiante

Descripción: El estudiante ingresa al sistema y va a la opción Gestión listar en la cual podrá observar sus notas finales, también podrá observar información sobre su matrícula.



CU1, CU2, CU4, CU5, CU6

19


Caso de Uso: Gestión sistema

Actores: Administrador

Propósito: Gestionar usuarios, realizar respaldos y generar reportes generales.

Descripción:

El administrador puede entrar al sistema de forma completa sin restricciones él se encargara de crear usuarios de diferentes niveles de acceso, además podrá realizar respaldo de la base de datos y generar reportes generales completos y detallados.



Que el administrador este registrado en la base de datos

20

ANEXO 3: DIAGRAMA DE CLASES

Anexo 2: Diagrama de Clases de Sistema de Gestion de Programas de Doctorado

21

ANEXO 4: DIAGRAMA DE OBJETOS

Anexo 4: Diagrama de Objetos del Sistema de Programas de Doctorado

22

ANEXO 5: DICCIONARIO DE DATOS

Tabla: Areas

CAMPOS

Campo Tipo de Dato Null Key Default Extra Privilegios Comentarios

Id_Area character varying(5) NO PRI auto_increment select,insert,update,references

NomBRE_Area character varying(50) NO select,insert,update,references

Foreign Key (Relación)

Id Tabla de Referencia Columna Fuente Columna Objetivo Información Extra

FK_Id_Departamento Departamentos Id_Departamento Id_Departamento ON DELETE NO ACTION ON UPDATE NO ACTION

Tabla: Aula

CAMPOS


Id_Aula character varying(5) NO PRI auto_increment select,insert,update,references

Nombre_Aula character varying(50) NO select,insert,update,references

23

Tabla: Horario

CAMPOS


Id_Horario character varying(5) NO PRI auto_increment select,insert,update,references

Nombre_Horario character varying(50) NO select,insert,update,references



FK_Id_Curso Curso Id_Curso Id_Curso ON DELETE NO ACTION ON UPDATE NO ACTION

Tabla: Becas

CAMPOS


Id_Beca character varying(5) NO PRI auto_increment select,insert,update,references

Nombre_Beca character varying(50) NO select,insert,update,references

Promocion character varying(50) select,insert,update,references

Cuantia character varying(50) select,insert,update,references

24

Tabla: Curso

CAMPOS


Id_Curso character varying(5) NO PRI auto_increment select,insert,update,references

Nombre_Curso character varying(50) NO select,insert,update,references



FK_Id_Aula Aula Id_ Aula Id_ Aula ON DELETE NO ACTION ON UPDATE NO ACTION

FK_Id_Doctor Doctor Id_ Doctor Id_ Doctor ON DELETE NO ACTION ON UPDATE NO ACTION

FK_Id_Promocion Promocion Id_ Promocion Id_ Promocion ON DELETE NO ACTION ON UPDATE NO ACTION

FK_Id_Temario Temario Id_ Temario Id_ Temario ON DELETE NO ACTION ON UPDATE NO ACTION

Tabla: Departamentos

CAMPOS


Id_Departamento character varying(5) NO PRI auto_increment select,insert,update,references

Nombre_Departamento character varying(50) NO select,insert,update,references

25

Tabla: Estudiante

CAMPOS


Id_Estudiante character varying(5) NO PRI auto_increment select,insert,update,references



FK_Cedula_Persona Persona Cedula_Persona Cedula_Persona ON DELETE NO ACTION ON UPDATE NO ACTION

Tabla: Facultad

CAMPOS


Id_Facultad character varying(5) NO PRI auto_increment select,insert,update,references

Nombre_Facultad character varying(50) NO select,insert,update,references

Decano character varying(50) select,insert,update,references

Tabla: Matricula

CAMPOS


Cod_Matricula character varying(5) NO PRI auto_increment select,insert,update,references

Fecha_Matricula date NO select,insert,update,references

Valor_Matricula numeric NO select,insert,update,references

Tipo_Matricula character varying(25) NO select,insert,update,references



FK_Id_Estudiante Estudiante Id_Estudiante Id_Estudiante ON DELETE NO ACTION ON UPDATE NO ACTION

26

Tabla: Notas

CAMPOS


Id_Notas character varying(5) NO PRI auto_increment select,insert,update,references

Calificacion_Final numeric NO select,insert,update,references



FK_Cod_Matricula Matricula Cod_Matricula Cod_Matricula ON DELETE NO ACTION ON UPDATE NO ACTION

FK_Id_Curso Curso Id_Curso Id_Curso ON DELETE NO ACTION ON UPDATE NO ACTION

Tabla: Persona

CAMPOS


Cedula_Persona character varying(10) NO PRI auto_increment select,insert,update,references

Apellido_ Persona character varying(50) NO select,insert,update,references

Nombre_ Persona character varying(50 NO select,insert,update,references

Genero character varying(1) NO 'M', 'F' select,insert,update,references

Titulo_tercernivel character varying(50) NO select,insert,update,references

Ciudad character varying(25) select,insert,update,references

Pais character varying(25) select,insert,update,references

Email character varying(50) select,insert,update,references

Estado_civil character varying(25) select,insert,update,references

Fecha_nacimiento Date select,insert,update,references

Direccion character varying(50) select,insert,update,references

Telefono character varying(10) select,insert,update,references

27

Tabla: Personal

CAMPOS


Cedula_Personal character varying(5) NO PRI auto_increment select,insert,update,references

Nombre_Personal character varying(50) NO select,insert,update,references

Apellido_Personal character varying(50) NO select,insert,update,references

Genero character varying(1) NO 'M', 'F' select,insert,update,references

Email character varying(50) NO select,insert,update,references

Cargo character varying(50) NO select,insert,update,references

Tabla: Profesores

CAMPOS


Id_Profesor character varying(10) NO PRI auto_increment select,insert,update,references

Catedratico character varying(50) NO 'S', 'N' select,insert,update,references



FK_Cedula_Persona Persona Cedula_Persona Cedula_Persona ON DELETE NO ACTION ON UPDATE NO ACTION

Tabla: Programas

CAMPOS


Id_Programa character varying(5) NO PRI auto_increment select,insert,update,references

Nombre_Programa character varying(50) NO select,insert,update,references



FK_Id_Departamento Departamento Id_Departamento Id_Departamento ON DELETE NO ACTION ON UPDATE NO ACTION

28

Tabla: Promocion

CAMPOS


Id_Promocion character varying(5) NO PRI auto_increment select,insert,update,references

Numero_Promocion character varying(50) NO select,insert,update,references



FK_Id_Programa Programa Id_Programa Id_Programa ON DELETE NO ACTION ON UPDATE NO ACTION

Tabla: Temario

CAMPOS


Id_Temario character varying(5) NO PRI auto_increment select,insert,update,references

Asignatura character varying(25) NO select,insert,update,references

Total_Horas character varying(3) NO select,insert,update,references

Tabla: Especialidad

CAMPOS


Id_Especialidad character varying(5) NO PRI auto_increment select,insert,update,references

Nombre_ Especialidad character varying(50) NO select,insert,update,references



FK_Id_Doctor Doctor Id_Doctor Id_Doctor ON DELETE NO ACTION ON UPDATE NO ACTION

29

Tabla: Solicitud

CAMPOS


Id_Solicitud character varying(5) NO PRI auto_increment select,insert,update,references

Detalle_Solicitud character varying(1) NO 'S', 'N' select,insert,update,references



FK_ Id_Becas Becas Id_Becas Id_Becas ON DELETE NO ACTION ON UPDATE NO ACTION

FK_Id_Estudiante Estudiante Id_ Estudiante Id_ Estudiante ON DELETE NO ACTION ON UPDATE NO ACTION

Tabla: Detalle_Solicitud

CAMPOS


Id_Detalle_Solicitud character varying(5) NO PRI auto_increment select,insert,update,references



FK_ Id_Solicitud Solicitud Id_Solicitud Id_Solicitud ON DELETE NO ACTION ON UPDATE NO ACTION

FK_Id_Requisito Requisito Id_Requisito Id_Requisito ON DELETE NO ACTION ON UPDATE NO ACTION

Tabla: Detalle_Tutoria

CAMPOS


Id_Detalle_Tutoria character varying(5) NO PRI auto_increment select,insert,update,references



FK_Id_Doctor Doctor Id_ Doctor Id_ Doctor ON DELETE NO ACTION ON UPDATE NO ACTION

FK_Id_Estudiante Estudiante Id_ Estudiante Id_ Estudiante ON DELETE NO ACTION ON UPDATE NO ACTION

30

Tabla: Detalle_Area_Personal

CAMPOS


Id_Detalle_Area_Personal character varying(5) NO PRI auto_increment select,insert,update,references



FK_Cedula_Personal Personal Cedula _ Personal Cedula _ Personal ON DELETE NO ACTION ON UPDATE NO ACTION

FK_Id_Area Area Id_Area Id_Area ON DELETE NO ACTION ON UPDATE NO ACTION

Tabla: Requisitos

CAMPOS


Id_Requisito character varying(5) NO PRI auto_increment select,insert,update,references

Detalle_Requisito character varying(50) NO select,insert,update,references



FK_Id_Requisito Requisito Id_Requisito Id_Requisito ON DELETE NO ACTION ON UPDATE NO ACTION

FK_Id_Solicitud Id_Solicitud FK_Id_Solicitud FK_Id_Solicitud ON DELETE NO ACTION ON UPDATE NO ACTION

31

ANEXO 6: DIAGRAMA ENTIDAD RELACION DE LA BASE DE DATOS

Anexo 6: Modelo Entidad Relación del sistema de gestión de programas de doctorado

32

ANEXO 7: DISEÑO FISICO DE LA BASE DE DATOS

Anexo 7: Diseño Físico de la base de datos

33

ANEXO 8: DIAGRAMA DE SECUENCIA Y COLABORACION

Diagrama de secuencia de registro de persona.

Diagrama de Colaboración de Registro de Persona

Persona : <Actor

Name>

Persona : <Actor

Name>

Ingreso al

Sistema

Ingreso al

Sistema

UsuarioUsuario Menu PrincipalMenu Principal Gesrionar

Registro

Gesrionar

Registro

Llenar camposLlenar campos

Ingresar usuario y contraseña

Buscar Usuario ()

Validar Usuario

Usuario Encontrado

Ingreso al Menu Principal

Ingreso a Gestionar Registro

Ingresar Información

Guardar Información

Registro Guardado

PERSONA : <Actor

Name>

Ingreso al

Sistema

Usuario

Menu

Principal

Gestionar

Registro

Llenar

Campos

3:

8:

1: 2:

4:

5:

6: 7:

9:

34

Diagrama de Secuencia Registro de Matricula

Diagrama de Colaboración Registro de Matricula

: Secretaria : Secretaria

Ingreso al

sistema

Ingreso al

sistema

UsuarioUsuario Menu PrincipalMenu Principal Gestionar

Matricula

Gestionar

Matricula

PersonaPersona Cursos y

asignaturas

Cursos y

asignaturas

Forma de pagoForma de pago

Ingresar Usuario y contraseña

Buscar Usuario ()

Usuario Encontrado()

Validar Usuario


Ingreso a Gestionar Matricula

Buscar Persona()

Persona Encontrada()

Persona previamente

registrada

Buscar Curso y asignatura()

Cursos y asignaturas

previamente registrados

Curso y asignaturas encontrado()

Seleccionar Forma de Pago()

Forma de pagos a

seleccionar

Agregar forma de pago()

Guardar e imprimir()

SECRETARIA : <Actor

Name>

Ingreso al

Sistema

Usuario

Menu

Principal

Gestionar

Matricula

Persona

Cursos y

Asignaturas

Forma de

Pago

3:

8:

11: 14:

16:

1: 2:

4:

5:

6: 7:

9:

10:

12: 13:

15:

35

Diagrama de secuencia Registro de maestro

Diagrama de Colaboración Registro de Maestro

Profesor : <Actor

Name>

Profesor : <Actor

Name>

Ingreso al

sistema

Ingreso al

sistema

UsuarioUsuario Menu PrincipalMenu Principal Getionar

Registro

Getionar

RegistroLLenar camposLLenar campos


Buscar Maestro ()

Mestro Encontrado


Validar Maestro

Ingreso a Gestionar Registro


Registro Guardado


MAESTRO : <Actor

Name>

Ingreso al

Sistema

Usuario

Menu

Principal

Gestionar

Registro

Llenar

Campos

3:

8:

1: 2:

4:

5:

6: 7:

9:

36

Diagrama de secuencia Registro de Notas y Faltas

Diagrama de Colaboración Registro de Notas y Faltas

Profesor : <Actor

Name>

Profesor : <Actor

Name>

Ingresar al

sistema

Ingresar al

sistema

UsuarioUsuario Menu PrincipalMenu Principal Gestionar Notas

y Faltas

Gestionar Notas

y Faltas

AsignaturasAsignaturas Notas y FaltasNotas y Faltas


Buscar Maestro ()

Mestro Encontrado

Validar Maestro


Ingreso a Gestionar notas y

notas

Buscar Asignatura()

Asignatura encontrada

Mostrar lista de estudiantes en

asignatura()

Ingresar notas y faltas

Guardar notas y faltas

Notas y faltas guardadas

37

Diagrama de secuencia de Registrar curso

Diagrama de Colaboración Registrar curso

PROFESOR : <Actor

Name>

Ingreso al

Sistema

Usuario

Menu

Principal

Gestionar Notas

y Faltas

Asignaturas

Notas y

Faltas

3:

8:

11:

1: 2:

4:

5:

6: 7:

9:

10:

12:

Secretaria de Departamento

: <Actor Name>

Secretaria de Departamento

: <Actor Name>

Ingresar al

Sistema

Ingresar al

Sistema


Cursos

Gestionar

Cursos

Temario, Aula y

Horario

Temario, Aula y

Horario


Buscar usuario ()

Secretaria Encontrada


Validar usuario

Seleccionar Registro

de cursos

Agregar información sobre el

curso


Curso, temario, aula y horario

guardados

38

Diagrama de Secuencia Registrar y asignar personal

SECRETARIA DE

DEPARTAMENTO : <Actor Name>

Ingresar al

Sistema

Usuario

Menu

Principal

Gestionar

Curso

Temario, Aula,

Horario

3:

8:

1: 2:

4:

5:

6: 7:

9:

39

Diagrama de Colaboración Registrar y asignar personal

Secretario de Departamentos :

<Actor Name>

Secretario de Departamentos :

<Actor Name>

Ingreso al

Sistema

Ingreso al

Sistema


Personal

Gestionar

Personal

Registrar

Personal

Registrar

Personal

Asignar

Personal

Asignar

Personal

CatedráticosCatedráticos Solicitar

Personal

Solicitar

PersonalProfesor : <Actor

Name>

Profesor : <Actor

Name>


Buscar Usuario ()

Secretaria

Encontrada

Validar Usuario


Ingreso a Gestionar Personal



Registro Guardado

Listar Personal()

Buscar catedraticos()

Guardar personal

Personal asignado

Asignación completada

Busca Personal asignado

Visual iza personal

Solicitud Completa

SECRETARIA DE DEPARTAMENTO :

<Actor Name>

Ingresar al

Sistema

Usuario

Menu

Principal

Gestionar

Personal

Registrar

Personal

Asignar

Personal

Catedráticos Solicitar

PersonalPROFESOR : <Actor Name>

3:

8:

12:

18:

16

1: 2:

4:

5:

6: 7:

9:

10: 14:

11:

13:

17:

15:

unidad acadÉmica de ingenierÍa civil...

Documents