en al - 148.206.53.231

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

"PROGRAMA DE PROYECTOS TERMINALES EN INSTITUCIONES DEL SECTOR PUBLICO"

TRIMESTRES : 98-P AL 98-0

ASESOR : M.OMAR LUCIO CABRERA JIMÉNEZ

ALUMNOS : LUVIANO RODRÍGUEZ GEORGINA MORA MUÑOZ PAUL

UNIVERSIDAD AUTONOMA METROPOLITANA

UNIDAD IZTAPALAPA

A’ DIVISION C.B.I.

.)‘ r*‘ CARRERA LIC. COMPUTACIÓN

TITULO “PROGRAMA DE PROYECTOS TERMINALES EN INSTITUCIONES DEL SECTOR PUBLICO”

” 13 DE JULIO DE 1999 <.-

ALUMNOS * ‘GEORGINA LUVIANO RODRIGUEZ 90321809

PAUL MORA MUNOZ 91 223620

ASESOR M. OMAR LUCIO CABRERA JIMENEZ

9=@-

INDICE

INDICE

1. Contexto General. . . . . . . . . . . . . . . . . . . . . . . 1.1 Presentación del Problema. . . . . . . . . . . . . 1.2 Modelo de Requerimiento. . . . . . . . . . . . . . 1.3 Modelo de Use Case. . . . . . . . . . . . . . . . . . 1.4 Modelo de Interfaz. . . . . . . . . . . . . . . . . . . 1.4.1 Descripción GrXica de Pantallas. . . . . 1.4.2 Diagrama de Transiciones de Estados .

1.5 Diagrama de Secuencia y Colaboración. . . 1.6 Diagrama General de Use Cases. . . . . . . .

4 4 4 5 6 6 6 7 7

2 .Transacción Contratación. . . . . . . . . . . . 8 2.1 Modelo de Use Case. . . . . . . . . . . . 8 2.2 Modelo de Interfaz. . . . . . . . . . . . . 10 2.3 Diagrama de transiciones de estados. . . . 1 5 2.4 Diagramas de Secuencia y Colaboración. . 17

. . . . . . . . . . . . . .

3 .Transacción Renuncia. . . . . . . . . . . . . . . . . . . 3.1 Modelo de Use Case. . . . . . . . . . . . . . . . 3.2 Modelo de Interfaz. . . . . . . . . . . . . . . . . 3.3 Diagrama de transiciones de estados. . . 3.4 Diagramas de Secuencia y Colaboración.

23 23 24 26 27

4. Modelo del Dominio del Problema. . . . . . . . . . 29

Anexo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Transacción Consulta. . . . . . . . . . . . . . . . . . .

5.1 Modelo de Use Case. . . . . . . . . . . . . . . . 5.2 Modelo de Interfaz. . . . . . . . . . . . . . . . . 5.3 Diagrama de transiciones de estados. . . 5.4 Diagramas de Secuencia y Colaboración

32 32 32 33 35 36

2

INDICE

. . . . . . . . . . . . . . 6. Transacción Modificaciones 39 6.1 Modelo de Use Case 39 6.2 Modelo de Interfaz. 40 6.3 Diagrama de transiciones de estados. . . . 42 6 .4 Diagramas de Secuencia y Colaboración. 43

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . 7. Transacción Permiso. 46 7.1 Modelo de Use Case. 46 7.2 Modelo de Interfaz. 47 7.3 Diagrama de transiciones de estados. . . . 48 7 .4 Diagramas de Secuencia y Colaboración. 49

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8. Transacción Temporal. . . . . . . . . . . . . . . . . . . 52 8.1 Modelo de Use Case. . . . . . . . . . . . . . . . 8.2 Modelo de Interfaz. . . . . . . . . . . . . . . . . 8.3 Diagrama de transiciones de estados. . . 8.4 Diagramas de Secuencia y Colaboración.

52 53 53 55

9. Transacción Consulta Historial Plaza/Profesor. 9.1 Modelo de Use Case. . . . . . . . . . . . . . . . . 9.2 Modelo de Interfaz. . . . . . . . . . . . . . . . . .

9.4 Diagramas de Secuencia y Colaboración

58 58 59 62 63

9.3 Diagrama de transiciones de estados. . . .

10. Editores.. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 69 70

1 0 . 1 Editor Alta de Plaza. . . . . . . . . . . . . . . . . 10.2 Editor Baja de Plaza. . . . . . . . . . . . . . . . .

1 1.Observaciones Generales. . . . . . . . . . . . . . . . 71

12.Conclusiones. . . . . . . . . . . . . . . . . . . . . . . . . . 73

3

CONTEXTO GENERAL

1. CONTEXTO GENERAL

1 . 1 PRESENTACION DEL PROBLEMA

Este proyecto es un sistema para el departamento de la división de Ciencias Básicas e Ingeniería. El cuál automatizará el control de profesores.

El manejo excesivo de profesores dentro de la División exige una modernización para un mejor control de movimientos que conciernen al profesor. Debido a esto se elaboró el sistema. El cuál facilitará los movimientos que ahí se realizan. Uno de los más utilizados es la Contratación, Recontratación y Renuncias. Además que facilitará la búsqueda de información particular de un profesor.

Este sistema manejará una base de datos Access. La manipulación de los datos se hará con sentencias SQL. Estas sentencias fueron implementadas en el lenguaje Phyton, que fue utilizado para la elaboración del sistema.

El sistema tiene dos módulos que engloban su funcionamiento. El primer módulo contiene el Menú principal que caracteriza al sistema. El segundo módulo contiene todo lo referente a Consulta del Historial.

El módulo principal contendrá las siguientes funciones: Contratación, Recontratación, Consulta, Modificación, Renuncias, Permisos y Temporal.

En el segundo módulo se podrán realizar consulta de su trayectoria laboral como la asignación de las Plazas en la universidad.

1.2 MODELO DE REQUERIMIENTO

El modelo de requerimiento consta de tres partes. El primero es el modelo de Use Case, el segundo es el modelo de Interfaz y el tercero es el Modelo del dominio del problema.

4

CONTEXTO GENERAL

A continuación se mencionan los modelos que contiene cada una de las transacciones.

El modelo de Use Case contiene los pasos más relevantes y al actor que interactua en él.

En el modelo de Interfaz, se mostrarán el juego de pantallas para cada transacción e ilustrará con un autómata el manejo de las pantallas.

En el diagrama de secuencia y colaboración, se visualizan la los distintos objetos entre sí y los manera en que interactuan

métodos que se utilizan en cada uno de ellos.

En el modelo del dominio del problema se ilustran las clases, subclases y la relación entre ellas, así como los atributos que cada uno contiene, con sus respectivas llaves que identifican de manera única a los objetos en la base de datos.

1.3 MODELO DE USE CASE

Enseguida se mencionan todos los Use Case que conforman al sistema y a demás se mostraran los tres primeros Use Cases a detalle que prácticamente son los más utilizados en el sistema. (NOTA : Los demás se muestran en el anexo).

Contratación Renuncia Consulta Modificación Permiso Temporal Consulta Historial Plaza/Profesor

5

CONTEXTO GENERAL

1 . 4 MODELO DE INTEFWAZ

El presente modelo es constituido por dos partes, una es la descripción gráfica de pantallas y la otra es el diagrama de transiciones de estados. Enseguida se menciona las pantallas y diagramas de estados del sistema en sus respectivas partes.

1.4.1 DESCRIPCION GRAFICA DE PANTALLA

Todas las pantallas que interactuan con la interfaz del sistema se mencionan a continuación:

Selección de Clave de plaza (Pantalla principal) Selección de Id de Profesor Captura de datos del dictamen Recontratación Consulta Modificación Renuncia Consulta Historial Plaza/Profesor Permiso Plaza Temporal Historial Plaza Historial Profesor Alta de Plaza Baja de Plaza

1.4.2 DIAGRAMA DE TRANSICION DE ESTADOS

Esta es la segunda parte del modelo de Interfaz, que contiene a los autómatas que controlan el flujo de pantallas para cada una de las transacciones. Enseguida se mencionan los autómatas que controlan alas pantalla del sistema.

Contratación Renuncia Consu Ita Modificación Permiso Temporal Consulta Historial Plaza/Profesor

6

CONTEXTO GENERAL

1.5 DIAGRAMA DE SECUENCIA Y COLABORACION

Todos los diagramas de secuencia y colaboración que se desarrollaron en el sistema se mencionan a continuación:

Contratación Recontratación Renuncia Consulta Modijicación Permiso Temporal Consulta Historial Plaza Consulta Historial Profesor

1.6 DIAGRAMA GENERAL DE USE CASES

Este diagrama muestra la relación de los Use Cases con El Asistente Administrativo y la manera en que interactúan entre sí (fig. 1.6.a).

Consulta Historial PlzlProf

? Contratación por primera vez Recontratación Asis.Adm.de la Secretarí

a Academica de C. B. I I

Fig. 1.6.a

7

TRANSACCION CONTRATACION

2.TRANSACCION CONTRATACION

2 . 1 Modelo de U c de Contratación

Este Use Case contrata a un Profesor por primera vez, así mismo recontrata al Profesor asignándole una plaza. Esto se lleva a cabo mediante los siguientes pasos (mencionando que la generalización contiene la parte de Contratación y Recontratación, a su vez contiene la especialización de las plazas) como se muestra en la fig. 2.1 .a.

Use case CONTRATACION

1.Selección de la plaza(especialización). 2.Caphira de datos del profesor. 3.Modficar las plazas de vacante a CONTRATACION

oaipada .

x -a Asist Mm. de la Seccretari

a Academia de C.B.I. A T

f

Contratación por pnmera wz

A

Use case Contratación por primera yez

1 Selección de la plaza vaaa(espedalización). 2.Caphira de datos del profesor. 3.Modificar las plazas de vacante a

oaipada y registro del Profesor.

Determinadas

Espeaalización

1.Fedia de terminación

Indeterminadas .._I>

Determinada

Espeaalización

1.Fedia de terminación

Use case Reconhtación

1.Selección de la plaza acia(especializaci6n). ZSelección del Id profesor 3.Caphira de datos del profesor. 4.Modificar estatus de plaza y profesor.

Recontratacón

A

-\ L Indeterminada

Fig. 2.1 .a Uc Contratación

8


Generalización

El paso No.1 nos permite seleccionar la Plaza, que se encuentran vacías, es decir que no se encuentran ocupadas por ningún Profesor.

En el paso No.2 se podrá capturar los datos personales y laborales del Profesor.

En el paso No.3 se realiza la modificación del estatus de la plaza.

Contratación por primera vez

El paso No.1 nos permite seleccionar dos tipos de Plaza, las plazas Determinadas e Indeterminadas que se encuentran vacías, es decir que no se encuentran ocupadas por ningún Profesor.


En el paso No.3 se realiza el registro de los datos capturados en el paso anterior, esto se lleva acabo mediante la agregación de una tupla en las tablas de Profesor, HistorialPlz/Prof y al mismo tiempo se cambia el estatus de la plaza.

Recontratación

El paso No.1 nos permite seleccionar dos tipos de Plaza, las plazas Determinadas e Indeterminadas que se encuentran vacías, es decir que no se encuentran ocupadas por ningún Profesor.

El paso No.2 se selecciona el Identificador personal de cada Profesor, que es antes asignado en la Contratación.

9



En el paso No.4 se realiza el registro de los datos capturados en el paso anterior y se cambia tanto el estatus de la Plaza como del Profesor.

(ESPECIALIZACIÓN: Existen dos tipos de plazas las Determinadas e Indeterminadas, la diferencia entre ambas es que las Determinadas contienen un periodo de terminación mientras que la otra no lo tiene)

2.2 MODELO DE INTERFAZ DE CONTRATACION

Enseguida se muestra la fig. 2.2.a que contiene la pantalla principal del sistema (Nota: esta pantalla se muestra solo una vez ya que es utilizada en todas las transacciones) y en lista todas las plazas vacías u ocupadas dependiendo de la transacción que se desee ejecutar.

Fig.

10

2.2.a correspondiente al paso 1 de los primeros siete uc -s .


Al elegir la opción de Agregar de la fig. 2.2.a, este ejecutará la transacción de Contratación del Profesor, previamente seleccionada la Plaza (paso 1 Uc Contratación)por primera vez, para llevar a cabo dicha transacción. Enseguida nos mostrará la pantalla de Captura de datos del Dictamen que contiene tres tabs, como se muestra enseguida en las siguientes pantallas, fig. 2.2.b, fig. 2.2.c,fig 2.2.d.

Fig. 2.2.c Uc Contratación por primera vez paso 2

11


Una vez llenados los tabs con los datos del Profesor(pas0 2 c Contratación) por primera vez y al seleccionar la opción de Aceptar de las figuras 2.2.b7c,d los datos quedarán registrados en la base (paso 3 Uc Contratación) por primera vez y regresará a la pantalla principal fig. 2.2.a, siempre y cuando los datos sean correctos y no existan campos vacíos, de lo contrario mostrará una pantalla con el mensaje del posible error. Como se muestra a continuación, fig. 2.2.e. elegido el botón cancelar de las fig. 2.2.a7b,c,d regresará a la pantalla principal fig. 2.2.a.

Fig. 2.2.e Uc Contratación por primera vez

12


2.2.a MODELO DE INTERF'AZ DE RECONTRATACION

Al elegir la opción de Recontratar de la fig. 2.2.a, este ejecutará la transacción de Recontratación del Profesor, previamente seleccionada la plaza (paso 1 Uc Recontratación) para llevar a cabo dicha transacción. Enseguida nos mostrará la pantalla de Selección del Id Profesor fig. 2.2. a .i.

Fig. 2.2.a.l. Uc Recontratación paso 2.

Al seleccionar uno de los Identificadores (paso 2 Uc Recontratación) y al seleccionar la opción de Aceptar automáticamente te mostrará la pantalla siguiente que contiene los siguientes tabs (fig. 2.2.a.2, fig. 2.2.a.3, fig. 2.2.a.4. )

13


Fig. 2.2.a.3 Uc Recontratación paso 3


14



Una vez llenados el contenido de los tabs y seleccionada la opción de Aceptar nos regresará a la pantalla de selección del Id profesor (fig. 2.2.a. 1), al mismo tiempo que registra los nuevos datos (Uc Recontratación paso 4); también si es seleccionada la opción de Cancelar pero sin registrar los datos en la base de datos.

2.3 DIAGRAMA DE TRANSICI~N DE CONTRATACION

El siguiente autómata de estados nos muestra la manera en que son presentadas las pantallas para la contratación por primera vez y Recontración de un profesor, así, como cada una de las transiciones que el usuario podría efectuar, como se muestra en la fig. 2.3.a.

En la pantalla selección de la Plaza (fig. 2.2.a), muestra todas las Plazas determinadas e Indeterminadas vacantes que se encuentran en ese momento (similar en todos los diagramas de transiciones siguientes), una vez que se ha elegido dicha Plaza y seleccionado la transacción Agregar, pasará a la pantalla de captura del dictamen (fig. 2.2.b), al igual que si selecciona Recontratar, pero

15


antes pasa por la pantalla de Id profesor(fig. 2.2.a), en la cuál podrán ser capturados los datos personales y laborales del profesor.

U n a vez capturados estos datos se registrarán en la base de datos, al seleccionar la transacción Aceptar de dicha pantalla regresará a la pantalla Selección de la plaza (fig 2.2.a) o a la pantalla de Id profesor dependiendo de lo que antes halla elegido, considerando las transacciones sin errores de lo contrario mostrará la pantalla de error(fig2.2.e). La transacción Imprimir se describe en la parte de observaciones generales.

DIAGRAlVIA DE TRANSICION DE CONTRATACION

Aceptar

Imprimir Aceptar/ Falta un campo de llenar

Selección Id. Prof. Error

Aceptar. I Reg. Datos,Mod. Aceptar Recontratar Plz.\Mod. hist. Prof.\Pb Cancelar

Mod. Situación Prof.

Reg datos,rnodPlzalReg prof

Fig. 2.3.a flujo de pantallas de Contratación.

16


2.4 DIAGRAMAS DE SECUENCIA Y COLABORACION DE CONTRATACION

Estos diagramas nos permiten ver el momento de creación y duración de cada una de las instancias, esto para los diagramas de secuencia. En cuánto a los diagramas de colaboración nos muestran la manera en que interactúan los diálogos con los objetos y estos a su vez con la base de datos. Esto se muestra en las figuras 2.4.a y 2.4.b.

Diagrama de Secuencia

Enseguida se menciona de una manera general el seguimiento de las instancias para la transacción Contratación. Al momento de ejecución el dialogo de Plazas interactuan con el Objeto Tipo de Plaza, el cual extrae de la base de datos el tipo de plaza (por defualt). Enseguida se observa que el asistente puede elegir el tipo de plaza e interactuar con el objeto Plaza y este obtener las Plazas referentes al Tipo de Plazas antes seleccionadas. Después de esto se selecciona una Plaza del dialogo de Plaza y muestra el Dialogo de Dictámen en la cual se capturan los datos del dictámen, esto pasa al objeto Plaza, Historial y Profesor, el cual cambia su estatus de la Plaza, registra los datos y el Id Profesor respectivamente. Esto se puede ver en la siguiente fig. 2.4.a

17


I I I I

I I

~

I I I I I

,

I I

/

I T I I I I I I I I I I I I I I I I

I I I I I I I I I I 1 I I I I I I I I I

I I I

U Setec. una PIZ 1

I P ConMacion Show(Plz Selec.) '

I V\hiteData(Query) Captura ID Profr. ' Guarda Pro/r.(lD Profr.)

I I I I I I - I I I I I I

I I I I I I I I I I I

Captura days Dicbmen ,

1 , I I I

I I I

I Pceptar

1 I I I I I I I

I I

I I I

GuardaDictarnen

I

CarnbiaStalus I

I 1 I

I 1 I I I I I

I I I I 1

I I I I I I

Fig. 2.4.a

18


Diagrama de Colaboración

Como se hizo mención en el encabezado este diagrama nos muestra todos los puntos para la interacción entre el asistente con los diálogos. Los diálogos con los objetos y estos a su vez con la base de datos.

9: Captura ID Profr. 12: Captura datos Dictamen

13: Aceptar 4 Dialoao de Cautura

del Dictamen 15: Cambia Status 3: Select. Tipo de Plz

6: Selec. una Plz \14: Contrata Plz(Plz)

8: Show(Plz Selec.)

- Plaza 4: Traer T i ~ o de Plz

a Academica de C.B.I.

Dialoqo de Plazas I

1 : Traer Tipo de Plazas i

2: GetData(Query)

Tiuo de ru

I O : Guarda Profr.(lD Profr.)

Profesor 1 /

Accesss + e

18: WriteData(Query) u

Fig. 2 A. b

17: GuardaDictamen i

19


2.4.1 DIAGRAMAS DE SECUENCIA Y COLABORACION DE RECONTRATACION

Estos diagramas nos permiten ver el momento de creación y duración de cada una de las instancias, esto para los diagramas de secuencia. En cuánto a los diagramas de colaboración nos muestran la manera en que interactúan los diálogos con los objetos y estos a su vez con la base de datos. Esto se muestra en las figuras 2.4.1.a y 2.4.1.a

Diagrama de Secuencia Enseguida se menciona de una manera general el seguimiento de las instancias para la transacción Recontratación. Al momento de ejecución el dialogo de Plazas interactuan con el Objeto Tipo de Plaza, el cual extrae de la base de datos el tipo de plaza (por defualt). Enseguida se observa que el asistente puede elegir el tipo de plaza e interactuar con el objeto Plaza y este obtener las Plazas referentes al Tipo de Plazas antes seleccionadas. Después de esto se selecciona el Id Profesor que se va ha recontratar y muestra el Dialogo de Recontratación en la cual se capturan los datos del Profesor que se va ha recontratar, esto pasa al objeto Plaza, Historial y Profesor, el cual cambia su estatus de la Plaza, registra los datos y el Id Profesor respectivamente.

Esto se ve en la siguiente fig. 2.4. La

20


-Q

I I I 1 Traer Tipo P l r I I I . I I n I I I I / I I

U Selec Tipo de P I r

I I

Selec una P l r Recontratación(Se1ec Pir) 1 1 I

I

Selec ID Proir I Show(ID Proir ,PI2 Sehc )

Captura de datos Recontratación

1 Aceptar 1 I c

I i

U I I I

GetDaLpuery) I _ I I I I I I

I I I I I

.

FetData(1D Pmfr.)i I

I I I I I I I I I I I I I I I I I I

I 7 1

icontatadón(P1r)

Cambia Status

I I I I I I I I I I 1 I I I 1 I I I I I I I I I I I I I 1

~ WriteDa&(Queryj I 1 I 1 I \

I I I I Recontratacbn(1D Proir.) I I I I I I XambiaStatus 1 ! I I I I I I I I

Guarda Reconbataci6n I

I I I I I I I I

,

WritsData(üuery' I- WriteData(Queryj 1 . .

I 1

I I I I 1 I

, ,

Fig. 2.4.1 .a Uc Recontratación

21




1: Traer Tipo Plz

2: getData(Query)

1 O: Selec. ID Profr. 8: GetData(lD Profr.)

4 - 1

7: RecontrataciÓn(Se1ec. Plz) \

13: keptar \

3: Selec. Tipo de Plz / 6: Selec. una P l r 12: Captura de datos Recontratadon

5: GetDatá(Query) 16: V\hiteData(Query)

.)

m I

21: V\hiteData((

7: Recontrataaón(1D Profr.

20: Guarda Remntratacic

de P l r Recontratación

14: RecontatauÓn(P1r)

Fig. 2.4.1.b Uc Recontratación

22

TRANSACCION RENUNCIA

3.TRANSACCION RENUNCIA

3 . 1 Modelo de Uc Renuncia

Mediante este Use Case se desliga la situación laboral del Profesor con la Institución, ya sea por terminación del periodo de la Plaza determinada o por renuncia a la Plaza, esto se lleva a cabo mediante los siguientes pasos; como se muestra en la fig. 3.1 .a.

Use case RENUNCIA

1 Selección de la Plaza ocupada

2.Registro de la fecha de baja del Profesor.

3.Cam bio de estatus de Plaza ,

REN UN CIA (especialización). k i s t . A m . de la Secretaría Academics de C.B.I.

Determ inada lnderminada

Especialización

1 .Fecha de terminación

Fig. 3.1 .a Uc Renuncia

23


3.2 MODELO DE INTERFAZ DE RENUNCIA

Cuando seleccione la opción de Eliminar en la pantalla principal (fig. 2.2.a) este realizará la transacción de Renuncia del Profesor. Una vez seleccionada la plaza (paso 1 Uc Renuncia), se mostrará la pantalla que contienen los siguientes tabs, con los datos del profesor a eliminar como se muestra a continuación, fig. 3.2.a, fig. 3.2.b, fig. 3.2.c.

Fig. 3.2.a Uc renuncia paso 2

24


Fig. 3.2.b Uc renuncia paso 2

Fig. 3.2.c Uc renuncia paso 2

25

TRANSACCION RENüNCIA , ’ -

Una vez capturada la fecha de renuncia del profesor y seleccionado la opción de Aceptar de dichos tabs se registrará la baja del Profesor (Uc renuncia paso 2), al mismo tiempo que le cambia el estatus a la Plaza y al Profesor(pas0 3 Uc Renuncia), regresándo a la pantalla principal (fig. 2.2.a). Al igual si es seleccionada la opción de Cancelar, que cancela la baja del profesor.

3.3 DIAGRAlVIA DE TRANSICIÓN DE RENUNCIA

El siguiente autómata de estados nos muestra la manera en que son presentadas las pantallas de la transacción de renuncia de un profesor, así, como cada una de las transiciones que se muestra en la fig.3.3.a.

En este autómata primero nos muestra la pantalla selección de la plaza (fig 2.2.a), la cuál nos en lista todas las Plazas que se encuentran asignadas a un Profesor, para dar de baja a un Profesor, se selecciona la Plaza correspondiente al Profesor y la transacción de Eliminar, la cuál nos presenta la pantalla de renuncia(fig. 3.2.a), esta pantalla nos muestra los datos personales y laborales del profesor, una vez capturada la fecha de renuncia y elegida la opción de Aceptar, se registrará en la base de datos la baja del profesor y actualizará el estatus de la plaza como del profesor, regresando a la pantalla principal (fig. 2.2.a). La transición Imprimir queda pendiente para un desarrollo futuro.

26


DIAGRAMA DE TRANSICIÓN DE RENUNCIA

Fig. 3.3.a flujo de pantallas de Renuncia

3.4 DIAGRAlVIA DE SECUENCIA Y COLABORACION DE RENUNCIA

Estos diagramas nos permiten ver el momento de creación y duración de cada una de las instancias, esto para los diagramas de secuencia. En cuánto a los diagramas de colaboración nos muestran la manera en que interactúan los diálogos con los objetos y estos a su vez con la base de datos. Esto se muestra en las figuras. 3.4.a y 3.4.b.

27


I I I

I I I I

. GetDaia(Query) I TraerData(Pl2)

I I -0


Enseguida se menciona de una manera general el seguimiento de las instancias para la transacción Renuncia. Al momento de ejecución el dialogo de Plazas interactuan con el Objeto Tipo de Plaza, el cual extrae de la base de datos el tipo de plaza (por defualt). Enseguida se observa que el asistente puede elegir el tipo de plaza e interactuar con el objeto Plaza y este obtener las Plazas referentes al Tipo de Plazas antes seleccionadas. Después de esto se selecciona una Plaza del dialogo de Plaza y muestra el Dialogo de Renuncia en la cual se capturan los datos del Profesor y la Fecha de Terminación, esto pasa al objeto Plaza, Historial y Profesor, el cual cambia su estatus de la Plaza, registra los datos y el Id Profesor respectivamente. Esto se muestra en la siguiente fig. 3.4.a

o &

I I 'Traer Tipo de PIz'

I I I I I I

I I I

I I I

Get Data(Query) .

I I I I I I I

Guarda R e n u n a a

Renunda(lD Profr) 1 1 I I I Cambia Status I I I I WriteData(Query)/

1 I I

I I 4- I

I I I I I I I

Fig. 3.4.a Uc Renuncia

I I I I I I

28

MODELO DEL DOMINIO DEL PROBLEMA

Diagrama de colaboración


: Asist. Adrrl, a Academ

19: Cambia Status

1 1 : Captura fechTerm 1 2 : Aceptar

! la Cecretarí I de C.B.I.

1 O: GetData

7: Renuncia

1 6 : Guarda Renuncia

5: Get Data(Query) 1 5 : WiteData(Query)

2: Get Data(Query)

1 1 : Traer Tipo de Plz

Fig. 3.4.b Uc Renuncia

4. MODELO DEL DOMINIO DEL PROBLEMA

20: WriteData(Query) \1

,Query)

I

En el siguiente modelo se mostrarán los objetos de información utilizados en el sistema y su relación entre ellos, además los atributos y los métodos que a cada uno le corresponde, mediante un diagrama de clases, como se muestra en la fig. 4.a.

29


DIAGRAMA DE CLASES

- -

I / i \

I I /

\

Figura 4.a Diagrama de clases.

La fig. 4.a muestra las clases y subclases existentes en el sistema y la relación que existe entre de cada una de ellas, haciendo notar que la clase Plaza y Profesor tienen una relación de muchos a muchos, la cual es simplificada mediante la clase Historial Prof/Plz.

30


Plaza

Profesor

La clase Plaza contiene dos subclases que son. Determinada e Indeterminada, por lo que heredan tanto métodos como atributos de la clase Plaza. Mediante esta clase se hace el recorrido hacia las demás clases, por lo que es la clase principal del sistema. Como se puede notar las demás clases tienen asociaciones de uno a muchos. Las llaves de cada clase y subclase se en listan en la tabla 4.b,

dichas llaves pueden estar formadas por uno o varios atributos.

Cve Plz

Id Prof

I CLASE I SUBCLASE 1 LLAVE(ATRIBUT0) I

Entidad Administrativa

Unidad

División

Departamento

Id Adm

Id Uni

Id Div

Id Depto

Historial ProfPlz

Tipo de plaza

Categoría

Cve PlzíId Prof Fech Ini

Id Tp

Id Categ

Nivel

I Area

Id Nivel

I Id Area ~~ I

Tiempo Dedicación I Id TPd Determinada Indeterminada

CvePiz Cve P M d Temp

Tabla 4.b Diagrama de clases

31

TRANSACCION CONSULTA

ANEXO

En esta parte del reporte se a describirán las transacciones restantes del sistema en el siguiente orden UC's, la descripción gráfica de pantallas, los diagramas de transición de estados y diagramas de Colaboración y Secuencia.

5.TRANSACCION CONSULTA

5.1 MODELO DE UC CASE

Mediante el siguiente Use Case se puede realizar la consulta a un Profesor que se encuentra laborando en la Universidad. La consulta se lleva a cabo mediante los siguientes pasos que se muestran en la fig. 5.1 .a.

CONSULTA Asis.Adrn.de la Secretaría Pcadernica de C.B.1

Determinada

Use case CONSULTA

1 .Selección de la plaza.(especialimción) 2.Visualización de tabs.

a Indeterminada

Especialización

1 .Fecha de terminación

Fig. 5.1.a Uc Consulta

32


El paso No.1 nos permite seleccionar dos tipos de Plaza, las Determinadas y las Indeterminadas, que se encuentran ocupadas por un Profesor.

En el paso No.2 se visualizan los datos del Profesor perteneciente a la Plaza antes seleccionada y podrá realizar la consulta tanto en sus datos personales como laborales.

5.2 MODELO DE INTEFWAZ DE CONSULTA

Cuando seleccione la opción de Consultar en la pantalla principal (fig. 2.2.a) este realizará la transacción de Consulta del Profesor, esta consulta es en base a la Plaza que ocupa y a la entidad administrativa a la que pertenece. Dicha transacción se mostrará el los siguientes figuras, fig. 5.2.a, fig. 5.2.b, fig. 5.2.c.

33


Fig. 5.2.b. Paso 2 del Use Case Consulta.

Fig. 5.2.c paso 2 del use case Consulta.

34


A

Aceptar

5.3 DIAGRAMA DE TRANSICION DE CONSULTA

Aceptar I por no selecconar Aceptar.Seleccionar plz. no ocupada

v

El siguiente autómata de estados nos muestra la manera en que son presentadas las pantallas para la consulta de un Profesor, así, como cada una de las transiciones que el usuario podría efectuar, como se muestra en la fig. 5.3.a.

Se tiene la primera pantalla que es selección de la Plaza (fig. 2.2.a), donde muestra todas las claves de Plaza tanto Determinadas como Indeterminadas, que se encuentran asignadas a un Profesor, una vez seleccionada una Plaza y la transacción consultar nos lleva a una pantalla Consulta de Profesor (fig. 5.2.a),donde muestra los datos personales y laborales de un profesor que tiene asignada la Plaza antes seleccionada, una vez seleccionada la transacción de cancelar regresará a la pantalla Selección de la Plaza, (pantalla principal). La transacción de imprimir queda pendiente para un desarrollo futuro.

DIAGRAMA DE TRANSICIONES CONSULTA

35


5.4 DIAGRAMA DE SECUENCIA Y COLABORACION DE CONSULTA

Estos diagramas nos permiten ver el momento de creación y duración de cada una de las instancias, esto para los diagramas de secuencia. En cuánto a los diagramas de colaboración nos muestran la manera en que interactúan los diálogos con los objetos y estos a su vez con la base de datos. Esto se muestra en las figuras 5.2.4.a y 5.4.b.

Diagrama de secuencia

Enseguida se menciona de una manera general el seguimiento de las instancias para la transacción Consulta. Al momento de ejecución el diálogo de Plazas interactuan con el Objeto Tipo de Plaza, el cual extrae de la base de datos el tipo de plaza (por defualt).

Enseguida se observa que el asistente puede elegir el tipo de plaza e interactuar con el objeto Plaza y este obtener las Plazas referentes al Tipo de Plazas antes seleccionadas. Después de esto se selecciona una Plaza del dialogo de Plaza y muestra el Dialogo de Consulta.

36


jmyy l r l Consulta

A : Asis.Adm.de la Secretari

a Academica de C.B.1 I I I I

I I I I I I

Selc Tipo Plz I

I I Traer Tipo de Plz

I I I I

\ / I I

GetData(Quer)i) I I

I i I J I I I

Seiec una PIZ 5

Consulta

I I Traer Plzflipo PlzSelc)

I

GetDad(Query) I I \ I I I I

1 I I I I I I I

7 1 Show Plz

-----e3 I I I

I I I 1 I I I I I I I

Fig. 5.4.a Uc Consulta

I 1 I I I I I I I I I I

37


His tori al + Consulta



3: Selc Tipo Plz 6: Selec una Plz

n 7: Consulta 8: Show Plz 9: TraerData (Piz)

I / \ : Asis.Adm.de la Secretarí

a Academica de C.B.1 1 : Traer Tipo de Plz

4: Traer Plz(Tipo PlzSelc)

1

I 1 O: GetData(Query)

Access - + 2: GetData(Query) 5: GetData(Query)

Fig. 5.4.b Uc Consulta

38

TRANSACCION MODIFICACIONES

6.TRANSACCION MODIFICACIONES

6.1 MODELO DE UC MODIFICACIONES

Mediante el siguiente Use Case se puede realizar el cambio de asignación de una Plaza, a un Profesor o modificar los datos personales del Profesor. La transacción de Modificaciones se lleva a cabo mediante los siguientes pasos que se muestran en la fig. 6.1 .a.

CAMBIO Asis.Adm de la Secretaria Academica de C.BI. 4

Use case CAMBIO

1 .Selección de la plaza(especializaciÓn). 2.Cambio de datos personales del profesor. 3.Registro de los cambios

Indeterminada Indeterminada

Especialización

Fecha de terminación

Fig. 6.1 .a Uc Modificaciones

El paso No.1 nos permite seleccionar dos tipos de Plaza, las Determinadas y las Indeterminadas, que se encuentran ocupadas por un Profesor.

En el paso No.2 se podrá capturar los nuevos datos personales del Profesor así como los datos de la nueva Plaza.

39

~


En el paso No.3 se realizan el registro de los datos capturados en el paso anterior, modificando los nuevos datos en la tabla Profesor e Historial Plaza/Profesor.

6.2 MODELO INTERFAZ DE MODIFICACION

Cuando seleccione la opción de Modificar en la pantalla principal (fig. 2.2.a),se realizará los cambios de información en los tabs del Profesor, Plaza, Entidad Administrativa (fig. 6.2.a.b,c paso 2 del Uc Modificaciones). Una vez realizado las modificaciones correspondientes, se actualizará la base de datos(paso 3 del Uc Modificación) y se regresará a la pantalla principal. A continuación se mostrarán las pantallas con los tabs de dichas transacciones fig. 6.2.a, fig. 6.2.b, fig. 6.2.c.

Fig. 6.2.a paso 2 del use case Modificación.

40


41


6.3 DIAGRAMA DE TRANSICIONES DE MODIFICACIÓN

El siguiente autómata de estados nos muestra la manera en que son presentadas las pantallas para el cambio de situación de un profesor, así, como cada una de las transiciones que el usuario podría efectuar, como se muestra en la fig. 6.3.a.

Se tiene la primera pantalla que es selección de la plaza (fig. 2.2.a), donde muestra todas las claves de Plaza que se encuentran asignadas a un Profesor tanto Determinadas como Indeterminadas, una vez seleccionada una Plaza y la transacción Cambio nos lleva a una pantalla Modificaciones (fig. 6.2.a) donde muestra los datos personales y laborales de un Profesor que pertenecen a la clave de Plaza antes seleccionada, se hacen las modificaciones que se requieran y al elegir la opción Aceptar se hará la modificación respectiva a la base de datos. Una vez seleccionada la transición de cancelar regresará a la pantalla Selección de la Plaza (pantalla principal).

DIAGRAMA DE TRANSICIONES MODIFICAR

E Aceptar

Modificaciones

Aceptar

I

Aceptar I no selecciona r nada, seiecciwiar piz

vacia. Aceptar

Aceptar i campos vacios

Fig. 6.3.a flujo de pantallas de Modificación.

42


6.4 DIAGRAlMA DE SECUENCIA Y COLABORACION DE MODIFICACIONES


Diagrama de secuencia

Enseguida se menciona de una manera general el seguimiento de las instancias para la transacción Modificaciones. Al momento de ejecución, el dialogo de Plazas interactuan con el Objeto Tipo de Plaza, el cual extrae de la base de datos el tipo de plaza (por defualt). Enseguida se observa que el asistente puede elegir el tipo de plaza e interactuar con el objeto Plaza y este obtener las Plazas referentes al Tipo de Plazas antes seleccionadas. Después de esto se selecciona una Plaza del dialogo de Plaza y muestra el Dialogo de Modificación en la cual se capturan los nuevos datos, esto pasa al Historial y se actualiza la base de datos.

43


I I I -

: Asis.Adm db la Secretari a Academilca de C.BI.

I I I

Seiec TIDO Plz

I I

I

1

I 'L

- I

Seiec. una PIZ u 'II 4

Modificación Show(Plz)

\ / I Captura nuews datos

I u I I I

I I 1 I I I I I I I I I

' TraerData(P1z) \ I I /

I I I I ! I I

GetData(Query)

'o I I I I I I I I I

I I I I Aceptar I I I

Fig. 6.4.a Uc Modificación

44




9: TraerDaia(P1z) 11: Captura nuems datos

--+ 12: Aceptar 13: CambioData(Modificaciones Dialono de

-- Modificación

Dialono de - Plaza - Plaza

5: Get D a t a ( Q u e r y ) i \ I 1: Traer Tipo de Plz

10: GetData(Query) 14: Update(query)

I" 2: Get Data(Query) . Access -72 Tipo de

Fig. 6.4.b Uc Modificación

45

TRANSACCION PERMISO

7. TRANSACCION DE PERMISO

7.1 MODELO DE UC PERMISO

Mediante el siguiente Use Case se puede realizar la transacción Permiso esto solo se podrá hacer si el Profesor ocupa una Plaza de tiempo Indeterminada. Este se lleva a cabo mediante los siguientes pasos que se muestran en la fig. 7.1 .a.

Use case PERMISO

1 Selección de la plaza Indeterminada. 2.Captura de tipo de permiso 3.Registro de permiso. 4.Cam bio de estatus de Plza y Profesor. PERMISO As is A i m ,de la Secretaría

Academica de C.B.I.

Fig. 7.1 .a

El paso No.1 nos permite seleccionar la plaza de tipo Indeterminado.

En el paso No.2 se podrá capturar los datos del tipo de permiso que se le asignará al Profesor.

En el paso No.3 se realiza el registro de los datos capturados en el paso anterior.

En el paso No. 4 se cambia el estatus a la Plaza como al Profesor.

46

TRANSACCION PERMISO

7.2 MODELO DE INTERFAZ DE PERMISO

Al elegir la opción Permiso de la fig. 2.2.a, este ejecutará la transacción de Permiso del Profesor, este Permiso solo podrá llevarse a cabo para las Plazas Indeterminadas, una vez que es seleccionada la Plaza(paso 1 del Uc Permiso) y ejecutará la transacción permiso mostrará la pantalla siguiente fig. 7.2.a.

Fig. 7.2.a. Paso 2 del Uc Permiso

En la que se podrá capturar los datos de Permiso. Una vez capturada dicha información, quedará registrada en la base de datos (paso 2 y 3 Uc Permiso), siempre y cuando no haya campos vacíos, de lo contrario se mostrará una pantalla de Error como en la fig. 2.2.e.

47

TRANSACCION PERMISO

Permiso Selección de la Plz Indeterminada

7.3 DIAGRAMA DE TRANSICIÓN DE PEWISO

A Aceptar.,/ Reg. Permiso en Ta

b Historial Mod. TPlz Mod. TProf.

El siguiente autómata de estados nos muestra la manera en que son presentadas las pantallas de Permiso de un Profesor, así, como cada una de las transiciones que se muestra en la fig. 7.3.a.

n

Primeramente, se presenta la pantalla de Selección de la Plaza (fig. 2.2.a), en donde únicamente contiene las Plazas de tipo Indeterminado debido a que son las únicas que pueden generar permiso por no tener un periodo laboral determinado.

Una vez que se h a seleccionado la Plaza, nos llevará a la pantalla de Permiso por medio de la opción Permiso (fig. 7.2.a). En dicha pantalla se capturan los datos y por medio de la transacción Aceptar se registran los datos en la BD y regresa a la pantalla Selección de Plaza. La transición Imprimir queda pendiente para un desarrollo futuro.

DIAGRAMA DE TRANSICIONES PERMISO

Aceptar Aceptar. I No selecciona plz selecciona plz

vacia

Error

Aceptar Aceptar / Falta de datos

I I J

Fig. 7.3.a flujo de pantallas de Permiso.

48

TRANSACCION PERMISO

7.4 DIAGRAMA DE SECUENCIA Y COLABORACION DE PERMISO



Enseguida se menciona de una manera general el seguimiento de las instancias para la transacción Permiso. Al momento de ejecución el dialogo de Plazas interactuan con el Objeto Tipo de Plaza, el cual extrae de la base de datos el tipo de plaza, en este caso son Plazas de tipo Indeterminado. Enseguida se observa que el asistente selecciona una Plaza e interactuar con el objeto Dialogo de Permiso y este a su vez con el Historial, para así obtener las Plazas referentes al Tipo de Plazas antes seleccionadas.

Después de esto se capturan los datos del Permiso, esto pasa al objeto Plaza, Historial y Profesor, el cual cambia su estatus de la Plaza, registra los datos y el Id Profesor respectivamente.

49

TRANSACCION PERMISO

7

~~~~~~~~~

A : Acis.Wm.de la Secretarí Permiso

a Academ ica de C.B.I. I ' Traer PIS Indeterminadas I I I I I 1 GetData(Query) I

'U I I I I I I

I I I I I

GetData(Query) I

I I I

1 I I I

I I I

I \ ,

I -1 CambiaStatus 1

Perm iso(Piz)

u Captura Permiso I

m I I I I

I

GuardaPerm ¡so WriteData(Query)

I I I

Permiso(lDProf) j I I

I I I I I I I I I I I

I CambiaStatus

I Write Data (CWJ ry)

I I I I I

I 1 I I I I

Fig. 7.4.a Uc Permiso

50

TRANSACCION PERMISO



Fig. 7.4.b Uc Permiso

51

TRANSACCION TEMPORAL

8.TRANSACCION DE TEMPORAL

8.1.MODELO DE UC TEMPORAL

Mediante el siguiente Use Case se puede dar de alta una Plaza. Esta alta es solamente para Plazas Temporales. La alta de la Plaza se lleva a cabo mediante los siguientes pasos que se muestran en la fig. 8.1 .a.

Use case PLAZATEMPORAL

1 Selección de la Plz. Indetetminada. 2.Generación de la Plaza Temporal. 3.Registro de la Plaza Temporal.

PLAZATEMPORAL Asis.Adm.de la Secretaría 4.Cambio de status de la Plz Indeterminada

Academica de C.B.I.

Fig. 8.1 .a Uc Temporal

El paso No.1 nos permite seleccionar la Plaza de tipo Indeterminado.

En el paso No.2 se podrá capturar los datos de la nueva Plaza Temporal.

En el paso No.3 se realizan el registro de los datos capturados en el paso anterior.

Paso No. 4 se realiza el cambio de estatus tanto para Plaza como Profesor.

52


8.2 MODELO DE INTERFAZ DE TEMPORAL

Al elegir la opción Temporal de la fig. 2.2.a, este ejecutará la transacción de crear una Plaza Temporal para el Profesor, esta Plaza Temporal solo podrá crearse para Plazas Indeterminadas. Una vez que se seleccione la Plaza(paso 1 Uc Plaza Temporal), y elegida la opción Temporal se mostrará la pantalla siguiente fig. 8.2.a.

Fig. 8.2.a. Paso 2 Uc Temporal

Una vez capturados los datos correspondientes a la Plaza Temporal (paso 2 Uc Temporal), se podrá registrar la nueva Plaza (paso 3 Uc Temporal), para poder ser asignada a un Profesor.

8.3 DIAGRA~VLA DE TRANSICI~N DE PLAZA TEMPORAL

El siguiente autómata de estados nos muestra la manera en que son presentadas las pantallas para la generación de Plaza Temporal de un Profesor, así, como cada una de las transiciones que se muestra en la fig. 8.3.a.

53


A Aceptar I Reg. Plz. Tempcfal Mod.

Status Plz. Indeterminada.

Aceptar I No selecciona piz selecciona piz vacia

Aceptar

La pantalla inicial que solo muestra las Plaza Indeterminada (fig. 2.2.a), es decir, las Plazas que no tienen fecha de terminación. Al seleccionar una de las claves de Plaza y seleccionar la opción Temporal, nos lleva a la pantalla de Generación de Plaza Temporal fig. 8.2.a.

Aceptar I Falta de datos

v

Una vez que se ha elegido la opción de Aceptar, se registra en la base de datos la nueva Plaza y regresa a la pantalla principal fig. 2.2.a.

DIAGRAMA DE TRANSICIONES PLAZA TEMPORAL

Fig. 8.3.a flujo de pantallas de Generación Plaza Temporal.

54


8.4 DIAGRAMA DE SECUENCIA Y COLABORACION DE TEMPORAL



Enseguida se menciona de una manera general el seguimiento de las instancias para la transacción Temporal. Al momento de ejecución el dialogo de Plazas interactuan con el Objeto Tipo de Plaza, el cual extrae de la base de datos el tipo de plaza(por default). Enseguida se observa que el asistente puede elegir el tipo de plaza e interactuar con el objeto Plaza y este obtener las Plazas referentes al Tipo de Plazas antes seleccionadas. Después de esto se selecciona una Plaza del dialogo de Plaza y muestra el Dialogo de Temporal en la cual se capturan los datos de la Plaza Temporal, esto pasa al objeto Plaza, Historial y Profesor, el cual cambia su estatus de la Plaza, registra los datos y el Id Profesor respectivamente.

55

: Asis.Adrn.die la Seuetarí a Academica de C.B.I.


Selec una Plz

I

I I I I

I I

\ I I I I I I I

I

Tern pora I 1 I I 1

GetDat&Query)

I I I I I

ihow(Plz Selec) ,

3-i I I I I Captura PlzTernporal

I Aceptar I

I 0 juarda Tern poral(P1zTern p) -A

WriteDab(Query) I l l I \ ,

I I

GuardaTernporal(P1zTernp) I

4 I I

WriteData(Query)

1 I I I

Fig. 8.4.a Uc Temporal

56


+ Historial + Dialogo Temporal


Access

-


Dialono de - Plaza

_Ii - Plaza

: Psis.Fdm.i a Academ

I la Secretarí 6: Traer Plz

I O : Guarda Temporal(P1zTemp)

1: Traere Plzlndeterminada .

_J

1

Fig. 8.4.b Uc Temporal

57

TRANSACCION CONSULTA HISTORIAL PLAZAPROFESOR

9.TRANSACCION CONSULTA HISTORIAL PLAZA/PROFESOR

9 . 1 MODELO DE UC CONSULTA HOISTORIAL PLAZA/PROFESOR

Mediante el siguiente Use Case se puede realizar la consulta al historial de Plaza/Profesor. La consulta se lleva a cabo mediante los siguientes pasos que se muestran en la fig.9.l.a.

HISTORIA Asis Adm .de la Secretaría kademica de C.B.I.

Use case CONSULTAHISTORIAL

1 .Selección del identificador(especialización). 2.Wsualimción de los datos.

Historial Plaza Historial Plaza

Use case CONSULTAHISTORW- Profesor Use case CONSULTAHISTORIAL Plaza

1 .Selección del ID del Profesor. 2.Visualimción de los datos del Profesor.

1 .Selección de la clave de la Plz. 2.Visualimción de los datos de la Plz.

Fig. 9.1 .a. Uc Consulta Historial PlazalProfesor

58

TRANSACCION CONSULTA HISTORIAL PLAZNPROFESOR

Consulta Historial

El paso No.1 nos permite seleccionar las claves que estuvieron asignadas a un Profesor.

En el paso No.2 se visualizan los datos de la clave seleccionada anteriormente.

Consulta Historial Plaza

El paso No. 1 nos permite seleccionar la clave de la Plaza.

En el paso No.2 se visualizan los datos de los Profesores que Plaza antes seleccionada, estuvieron relacionados con la clave la

durante la existencia de la Plaza en la Universidad.

Consulta Historial Profesor

El paso No. 1 nos permite seleccionar la clave del Profesor.

En el paso No.2 se visualizan los datos de las Plazas que estuvieron relacionados con el Profesor durante su estancia en la Universidad.

9.2 MODELO DE INTERFAZ DE CONSULTA HISTORIAL PLAZA/PROFESOR

Enseguida se muestra las pantallas que proporcionan las consultas al historial, tanto para Plaza como para Profesor fig. 9.2.a.

59

TRANSACCION CONSULTA HISTORIAL PLAZA/PROFESOR

Fig. 9.2.a. paso 1 Uc Historial PlzaiProf

Dentro del combo box se tiene las opciones de Plaza y Profesor, al elegir la opción de Plaza o del Profesor, la pantalla Historial Plza/Prof mostrará las claves de las Plazas o ID de los Profesores dentro del list box, dependiendo de la opción que se haya elegido anteriormente, en el cual podrá elegirse una de ellas para conocer la trayectoria de la Plaza o Profesor, es decir por que Profesor ha sido ocupada las Plazas y viceversa dentro de la Universidad, enseguida se muestran la pantalla que muestran los datos de las consultas. fig.9.2.b y fig.9.2.c. (paso 2 Uc Consulta Historial).

60

TRANSACCION CONSULTA HISTORIAL PLAZAiPROFESOR

PLAZA

la Universidad, así, como las claves de la Plaza que se le ha asignado a algún Profesor.

Esta pantalla nos muestra la trayectoria de la Plaza dentro de

IH ISTORIAL PLAZA1

Fig. 9.2.b. Paso 2 Uc Consulta Historial Plaza

Una vez seleccionado la clave de la Plaza (paso 1 Uc Consulta Historial Plaza. Dentro de la pantalla Historial Plaza fig. 9.2.b, se podrá consultar (paso 2 del Uc consulta Historial Plaza) todo lo relacionado a la trayectoria de una Plaza en la Universidad.

PROFESOR Esta pantalla nos muestra la trayectoria laboral del Profesor

dentro de la Universidad, así, como las claves de la Plaza que se le ha asignado.

61


[HISTORIAL PROFESOR^

Fig. 9.2.c. Paso 2 Uc Consulta Hiostorial Profesor

Una vez seleccionado el Id Profesor(pas0 1 Uc Consulta Historial Profesor. Dentro de la pantalla Historial Profesor fig.9.2.a, se podrá consultar (paso 2 Uc Consulta Historial Profesor) todo lo relacionado del Profesor con la Universidad.

9.3 DIAGRAMA DE TRANSICIÓN DE CONSULTA AL HISTORIAL DE PLAZA/PROFESOR.

El siguiente autómata de estados nos muestra la manera en que son presentadas las pantallas para consulta al historial de la Plaza/Profesor, así, como cada una de las transiciones que se muestra en el la fig. 9.3.a.

Como primera pantalla, tenemos la Selección de Clave de Plaza e ID de Profesor (fig. 9.2.a), al elegir una de las Plazas o ID de

62

TRANSACCION CONSULTA HISTORIAL PLAZARROFESOR

A

Aceptar

Profesor se muestra la pantalla de Historial Plaza (fig. 9.2.b) o la pantalla de Historial Profesor fig. 9.2.c, dependiendo de la opción que se haya elegido, la opción Cancelar regresa a la pantalla de Selección de la Plaza/Profesor. La transición de Imprimir queda pendiente para un desarrollo futuro.

Aceptar I por no seleccionar Cve. Plaza.

V

Im primir

n Aceptar Id + His to ria I Profes or

Fig. 9.3.a Uc Consulta Historial PlazalProfesor

9.4 DIAGRAMA DE SECUENCIA Y COLABORACION DE CONSULTA HISTOFUAL PLAZA

Estos diagramas nos permiten ver el momento de creación y duración de cada una de las instancias, esto para los diagramas de secuencia. En cuánto a los diagramas de colaboración nos muestran la manera en que interactúan los diálogos con los objetos y éstos a su vez con la base de datos.

63

TRANSACCION CONSULTA HISTORIAL PLAZA/PROFESOR

GetData(Query) I I

I I I

i I I I -1

Esto se muestra en las figuras 9.4.a y 9.4.b.


Enseguida se menciona de una manera general el seguimiento de las instancias para la transacción Consulta Historial Plaza. Al momento de ejecución el dialogo de Plazas interactuan con el Objeto Plaza, el cual extrae de la base de datos todas las Plazas. Enseguida se observa que el asistente selecciona una Plaza del dialogo de Plaza y muestra el Dialogo de Historial Plaza.

+ A

: AsisNclm.d'e la Secretarí a kadernika de C.B.I. -

' Seiec una PIZ

'u Aceptar I

1 I I I I I

Show(Plz) \ /

I I I I I I I i I

41 GetData(Query) TraerData(P1z) I I

11- I

Fig. 9.4.a Uc Consulta Historial Plaza

64


~

+ 4 Access Plaza -

: Asis.Adm.de la Secretar¡ a Academica de C.B.I.

~

5: Show(Plz) i 7'

7: GetData(Query)

6: TraerData(P1z)

Historial

I

,rial 1 Fig. 9.4.b Uc Consulta Historial Plaza

65

TRANSACCION CONSULTA HISTORIAL PLAZNPROFESOR

9.4.a DIAGRAMA DE SECUENCIA Y COLABORACION DE CONSULTA HISTORIAL PROFESOR

Estos diagramas nos permiten ver el momento de creación y duración de cada una de las instancias, esto para los diagramas de secuencia. En cuánto a los diagramas de colaboración nos muestran la manera en que interactúan los diálogos con los objetos y estos a su vez con la base de datos. Esto se muestra en las figuras 9.4.a.l y 9.4. a.2


Enseguida se menciona de una manera general el seguimiento de las instancias para la transacción Consulta Historial Profesor. Al momento de ejecución el dialogo de Plazas interactuan con el Objeto Profesor, el cual extrae de la base de datos todos los Profesores. Enseguida se observa que el asistente selecciona una Plaza del dialogo de Profesor y muestra el Dialogo Historial de Profesor.

66

TRANSACCION CONSULTA HISTORIAL PLAZAíPROFESOR

Profesor Profesor

4 : AsisAdm.de la Secretrí a AcademiCa de C.B.I.

I Setec una PIZ

I I I I I I Traer Todos los Profs I 1 1

I 1

L 7 I

I I I I

I ~ I I I I I I ’I I I I I

Aceptar , 4

I I I I I -rT TraerData(1D Prof) GetData(Queyh

I I

Show(lD Prof)

‘ I

U I

67

Fig. 9.4.a.l Uc Consulta Historial Profesor

TRANSACCION CONSULTA HISTORIAL PLAZAlPROFESOR

Dialoqo Historial Profesor ~ + ACUXS 1


Historial Profesor


-73 - His

: Acis.Adm.de la Secretrí a Academica de C.B.I.

5: Show(lD Prof)

7: GetData(Query

Fig 9.4.a.2 Uc Consulta Historial Profesor

68

EDITOR ALTA PLAZA

10. EDITORES

10.1 EDITOR DE ALTA DE PLAZA

Este editor nos permite dar de alta nuevas Plazas. Dentro de esta pantalla pueden ser capturados los datos de la nueva Plaza, que posteriormente será registradas en la tabla Plazas fig. 10.1 .a.

Fig. 10.l.a Editor Alta Plaza

69

EDITOR BAJA PLAZA

10.2 EDITOR DE BAJA DE PLAZA

Este editor nos permite dar de baja a las Plazas. Dentro de esta pantalla, se en listan las claves de las Plazas Fig10.2.a. Si se va ha dar de baja alguna de ellas, solo es necesario seleccionar la Plaza a dar de baja y elegir la opción eliminar.

Una vez echo esto la Plaza quedará eliminada de la base de datos.

Fig. 10.2.a Editor Baja Plaza

70

OBSERVACIONES GENERALES

1 1. OBSERVACIONES GENERALES

En esta sección del reporte se mencionarán la forma en que quedo implementado el sistema como primera versión y algunos puntos del diseño que no se implementaron. También se mencionará que en la segunda versión quedaron puntos faltantes en cuanto a implementación se refiere, ya que estos si fueron diseñados.

Para la primera versión el punto faltante fue los reportes en todas las transacciones. Dichas transacciones se observan en la figura 4.1 .a, también en lista todas las plazas disponibles para cada transacción. Esta figura muestra la manera en que quede implementada la pantalla principal del sistema. A continuación se muestran las pantallas para cada transacción descrita en la fig. 2.2.a.

CONTRATACI~N Y RECONTRATACI~N

Las pantallas siguientes (fig.2.2.a,2.2.b72.2.c y 2.2.d) muestran el contenido para llevar a cabo la contratación del profesor y las pantallas siguientes (fig.2.2 .a. 1,2.2 .a.2,2.2 .a.3,2.2 .a.4) muestran el contenido para llevar a cabo la Recontratación de un Profesor.

En esta transacción se muestran las siguientes pantallas (fig 6.2.a, 6.2.b, 6.2.c) en las cuales se puede observar los campos que puedan ser modificados, tanto en la parte laboral como personal del profesor.

CONSULTA

Las siguientes pantallas (figuras 5.2.a, 5.2.b y 5.2.c), muestra la manera en que se pueden observar los datos del profesor tanto laboral como personal.

71

OBSERVACIONES GENERALES

RENUNCIA

Para esta transacción se tienen las pantallas (fig. 3.2.a, 3.2.b,3.2.c) donde nos permite observar antes de eliminar al profesor, sus datos, enseguida se muestra la fig. 3.2.d, que nos avisa con afirmaciones la eliminación o no.

Enseguida se tiene dos transacciones de consulta al historial de la plaza y del profesor.

CONSULTA HISTORIAL PLAZA/PROFESOR

Las pantallas siguientes fig. 9.2.a, 9.2.b y 9.2.c nos permite seleccionar la Plaza o el Profesor del cuál queremos ver su trayectoria o ver por que Profesor ha sido ocupada.

72

CONCLUSIONES

12. CONCLUSIONES

Uno de los principales objetivos en este proyecto fue llevar a cabo el desarrollo del sistema que serviría de apoyo a la Secretaría Académica de C.B.1, para un mejor manejo y control de los Profesores de esta Unidad.

Durante el desarrollo del sistema se pudo analizar dos versiones, una de las cuales se llevó a la implementación e instalación de la misma, quedando la segunda versión en periodo de análisis. Por lo que se puede concluir que el objetivo principal se llevó acabo. Y en cuanto a esta segunda versión, debido al corto tiempo y a las pocas facilidades de acceso a las instalaciones de centro de computo, no se pudo implementar la segunda versión.

En términos generales se puede decir que se obtuvo un conocimiento muy amplio en cuanto a sus distintas etapas correspondiendo estas al Análisis y Diseño de Sistemas de Información.

73

en al - 148.206.53.231

Documents