HERNANDEZ - 148.206.53.84148.206.53.84/tesiuami/UAM4363.pdf · 3.2 Modelo de Use Cases 3.3 Modelo...

SISTEMA DE INFORMACldN PARA EL DEPARTAMENTO DE ECONOMíA ~

UNIVERSIDAD AUTONOMA METROPOLITANA

UNIDAD:

DIVISI~N:

CARRERA:

MATERIA:

TíTULO:

FECHA:

ALUMNOS:

IZTAPALAPA 2 2 5 8 8 5

CIENCIAS BASICAS E INGENIERíA

LICENCIATURA EN COMPUTACIóN

PROYECTO DE INVESTIGACION I Y II

ANALISIS Y DISEÑO DE UN SISTEMA DE

INF0RMAClt)N PARA EL DEPARTAMENTO DE

ECONOM~A

23 de Enero del 2001

GWENDY PATRlCiA HERNANDEZ TREJO

LENNIN PEREZ PEÑA

MATRICULAS: 9421 7386

9421 7691

ASESOR: ELISA GONZÁLEZ DEL VALLE CAMPOAMOR

SISTEMA DE INFORMACldN PARA EL DEPARTAMENTO DE ECONOMíA

Contenido 2 2 5 8 8 5

Pag.

1 Objetivos

I. I Generales

1.2 Personales

2, Introducción

3. Proceso de Análisis

3.1 modelo dc Requerimientos

3.2 Modelo de Use Cases

3.3 Modelo de Interfaz

3.4 Dominio del problema

3.5 Diagrama de clases

4. Proceso de Diseño

5. Implementación de Base de datos

5. I ?dodelo Relaciona1

5.2 Modelo Esencial

5.3 Modelo de Ambiente

5

8

9

18

19

20

41

42

43

43

SISTEMA DE INFORMACldN PARA EL DEPARTAMENTO DE ECONOMiA

3 . OBJETIVOS

1.1 OBJETIVOS GENERALES.

Basándose en las necesidades de la jefatura de economía de tomar decisiones

relacionadas con las funciones de investigación, docencia y difusión se requiere el

disponer de información actualizada e interrelaclonada para el cumplimiento de los

objetivos del departamento.

Las ventajas que se obtendrán con el sistema serán. ~ c

1. Apoyar la toma de decisiones de la jefatura del departamento de economía. , _.(

2. Disponibilidad de información actualizada correspondiente a profesores, P proyectos de investigación y docencia de las licenciaturas de economía y

y

,"

: . . -. .

'' ... -. - I"

.. . . I administración, como para la planeación de actividades del departamento.

. _

I. -. 5.. '

PI-. - (J-,

1 ' _

9 h +.

UNIVERSIDAD AUTONOMA METROPOLITANA -2-

SISTEMA DE INFORMAC16N PARA EL DEPARTAMENTO DE ECONOMíA

1.2 OBJETIVOS PERSONALES

- Aplicar los conocimientos adquiridos en el análisis, diseño y desarrollo de

sistemas en un proyecto, el cual será el inicio nuestra vida como

profesionistas.

- Aplicar la metodología UML (Unified Model Languge) en el análisis y diseño

del sistema, la cual hoy en día es una de las más utilizadas en las empresas

de consultoría y desarrollo de sistemas.

- Aplicar la herramienta Rational Rose para el análisis y diseño de sistemas, la

cual tiene gran ahge y aceptación en el mundo de los sistemas.

- Aplicar la ingeniería de software orientada a objetos, utilizando una

herramienta de desarrollo como Visual Basic

~ ~

UNIVERSIDAD AUTONOMA METROPOLITANA ~~~~ ~ ~ ~

- 3 -


3. PROCESO DE ANALISIS

3.1 ELABORACIóN DEL MODELO DE REQUISITOS.

El Modelo de Requisitos es el destilado de la especificación de requerimientos

puesto en un formato estándar, que permite su actualización sin pervertir la

estructura original. Incorpora el requerimiento funcional con retroalimentación de I

usuario. Establece la estructura funcional del sistema. Describe los casos de

prueba más relevantes. Este modelo consta de tres partes: Modelo de Use Cases,

Modelo de Interfaz, Modelo del Dominio del Problema.

Modelo de Use Cases.

En la primera entrevista con el Departamento de Economía se realizó el

levantamiento de requisitos. De esta entrevista se obtuvo la siguiente información,

la cual servirá para elaborar nuestro Modelo de Uses Cases.

Registro de:

Los profesores que pertenecen al departamento de economía.

u Las publicaciones de estos profesores.

Los proyectos de investigación que se realizan o se realizaron en el

departamento.

Los cursos que se imparten en el departamento, a los cuales se les

denomina educación continua.

El equipo de computo con el que cuenta cada profesor.

Las instituciones que participan en algunos proyectos de investigación.

Los convenios que se tienen con las instituciones antes mencionadas.

l . Asignaciones de:

Profesores a proyectos de investigación.

Instituciones a convenios.

Profesores a publicaciones.

Instituciones a proyectos de investigación.

UNIVERSIDAD AUTONOMA METROPOLITANA - 5 -


2. Consultas.

De profesores

Publicaciones

Proyectos

A estas operaciones se les llama USE CASES. Un Use Case es la descripción

genérica de las transacciones, es decir de las interacciones que tiene el sistema

con algunos agentes externos. Por lo tanto los USE CASES para este sistema de

información son:

UC1 Registro de profesores:

Captura los datos del profesor

Guardar el registro

UC2 Registro de convenios:

Captura los datos del convenio

Guardar el registro

UC3 Registro de educación continua:

Captura los datos del curso

Guardar el registro

UC4 Registro de publicaciones:

Captura los datos de la publicación

Guardar el registro

UC5 Registro de equipo de computo:

Capturar el número de inventario

Seleccionar el profesor

Capturar los datos del equipo de computo

= Guardar el registro

UC6 Registro de proyectos de investigación:

Captura los datos del proyecto de investigación

Guardar el registro

UC7 Registro de instituciones:

_ _ ~ ~ ~



9 Captura los datos de la institución

9 Guardar el registro

UC8 Asignación de profesores con proyectos de investigación:

9 Seleccionar el profesor al que se le va a signar el proyecto

Seleccionar el proyecto a asignar

9 Hacer la asignación

UC9 Asignación de instituciones a proyectos de investigación:

9 Seleccionar un proyecto al cual se le va asignar una institución

9 Seleccionar la institución

m Introducir la información adicional para asociar con el proyecto

Realizar la asociación

UClO Asignación de profesores con publicaciones:

Seleccionar el profesor al que se le va asignar la publicación

9 Seleccionar la publicación a asignar


UC11 Asigrlacibn de instituciones con convenios:

9 Seleccionar la institución a la que se le va a signar el convenio

9 Seleccionar el convenio a asignar


UCl2 Consulta de profesores

Capturar el número económico del profesor

9 Imprimir reporte

El actor principal que estará interactuando de manera directa con el sistema

será un capturista o secretaria.

Can toda este información se diseña el Modelo de Use Cases, el cual

representa las interacciones que tiene el actor con cada uno de los use cases. El

capturista alimenta al sistema con la información que es proporcionada por el

departamento de economía.



3.2 MODELO DE USE CASES

Las flechas indican hacia que lado fluye la información. Si las flechas se dirigen

del capturista a un Use Case significa que es este quien tiene que proporcionar la

información, en casc contrario, el Use Case le regresará algún o resultado al

capturista.

Las flechas con la punta más ancha que llegan al Use Case de Consulta

representan especializaciones, debido a que también son consultas (se realizan

exactamente los mismo pasos) pero ahora estas consultas se hacen para conocer

algunos datos adicionales al profesor, tales como cuántas publicaciones tienen o

en qué proyectos estan participando o participaron por ejemplo.



3.3 MODELO DE INTERFAZ

Una vez determinado el Modelo de Use Cases, el siguiente paso es realizar el

Modelo de lnterfaz que sirve para mostrarle al usuario, por medio de pantallas, lo

que éI con palabras nos señaló como requisitos. Este modelo consta de

Diagramas de Estado que sirven para representar las pantallas y como se van a

mover hacia atrás. Existe un Diagrama de Estado para cada Use Case del

sistema.

Diagrama de Estados de Registro de Profesores.

Este diagrama tiene un estado inicial (círculo negro) que llega a una pantalla

(rectángulo con leyenda) en el que el usuario puede plantear acciones a realizar,

por ejemplo, la captura de los datos del profesor o salir de la pantalla. Si se decide

por capturar los datos del profesor pasará a otra pantalla o botón para dar de alta

el registro y seguir capturando más registros. Cuando decida salir de la pantalla

principal (registro de los datos del profesor) el usuario debe seleccionar la opción

de “salir” y llegará a un estado final (círculo negro con marco).

Existe una pantalla más: ERROR. Esta pantalla se mostrará si los datos del

profesor son incorrectos y al mismo tiempo permitirá regresar a la pantalla de

captura de datos para hacer las correcciones necesarias. De igual manera, si los



datos del profesor están duplicados o bien si existe un problema con la base de

datos se enviará al usuario un mensaje de error y se le permitirá regresar a la

pantalla principal.

A continuación se muestran los Diagramas de Estado para Use Cases de

Registro de Convenios, Proyectos, Publicaciones, Educación Continua,

Instituciones, Equipo de Computo y Consulta.

Diagrama de Estado de Registro de Convenios.

UNIVERSIDAD AUTONOMA METROPOLITANA - 1 0 -

SISTEMA DE INFORMAC16N PARA EL DEPARTAMENTO DE ECONOMiA

Diagrama de Estado de Registro de Publicaciones. 2 2 5 8 f j 5

Diagrama de Estado de Registro de Proyectos de Investigación.


Diagrama de Estado de Registro de Educación Continua.

Diagrama de Estado de Registro de Instituciones.

* 'e


SISTEMA DE INFORMAC16N PARA EL DEPARTAMENTO DE ECONOMíA . Diagrama de Estado de Registro de Equipo de Computo.

Este diagrama tiene un estado inicial (círculo negro) que llega a una pantalla

(rectángulo con leyenda) en el que el usuario puede plantear acciones a realizar,

por ejemplo, la captura de los datos del equipo de computo con que cuenta un

profesor o salir de la pantalla. Si se decide por capturar los datos del equipo

pasará a otra pantalla o botón para seleccionar el número económico del profesor

al que se le esta registrando el equipo, en esta pantalla también tendrá dos

opciones: pasar a otra pantalla o regresar a la pantalla inicial (capturar el número

de inventario). De esta nueva pantalla podrá elegir dos caminos: regresar a la

anterior pantalla o cambiarse a otra donde capturará los datos adicionales del

equipo que se está registrando, esta pantalla también cuenta con las opciones

antes mencionadas. La última pantalla con que cuenta este registro de equipo es

la de guardar el registro. Cuando decida salir de la pantalla principal (registro de

los datos del equipo) el usuario debe seleccionar la opción de “salir” y llegará a un

estado final (circulo negro con marco).



Existe una pantalla más: ERROR. Esta pantalla se mostrará si los datos del

equipo son incorrectos y al mismo tiempo permitirá regresar a la pantalla de

captura de datos para hacer las correcciones necesarias. De igual manera, si los

datos del equipo o los del profesor están duplicados o bien si existe un problema

con la base de datos se enviará al usuario un mensaje de error y se le permitirá

regresar a la pantalla principal.

Diagrama de Estado de Consulta.

J i

Los Diagramas de Estado de las especializaciones de este Use Case, es decir

Consultas de Publicaciones y Proyectos de Investigación por Profesor son

exactamente iguales al diagrama anterior.

UNIVERSIDAD AUTONOMA METROPOLITANA - 14-


Diaqrama de Estado de Asignación de Instituciones a Convenios.

Este miodelo, al igual que los anteriores, tiene los mismos componelftes: un

estado inicial, un estado final, unos rectángulos que representan estados y líneas

que representan acciones. v

Este diagrama explica cómo el capturista puede asignar una institucidn a un

convenio. De la pantalla principal (selección de la institución) tiene dos opciones,

salir de esta o capturar la clave de la institución, si decide capturar la clave de la institución pasará a otra pantalla donde seleccionará un convenio para después

realizar la asignación. Una vez realizada esta asignación deberá dar un clic a un

botón para realizar una asignación.

Como se puede observar en la figura, también existe una pantalla de error a la

cual se llegará en caso de que la clave de la institución no exista o este duplicada

o se haya cometido un error al seleccionar el convenio. También existirá un error



si no se pudo realizar la asignación, o bien, si no se pudo guardar el registro en la

base de datos. En cualquiera de todos estos casos las pantallas permiten regresar

a la pantalla anterior a la pantalla principal.

Los diagramas de Estado de Asignación de Instituciones a Proyectos, de

Asignación de Profesores a Proyectos, de Asignación de Profesores a

Publicaciones que continuación se presentan trabajan de la misma forma que el

antes descrito.

DiaQrama de Estado de Asimación de Instituciones a Provectos.

L



Diaqrama de Estado de Asinnación de Profesores a Provectos.

UNIVERSIDAD AUTONOMA METROPOLITANA - 17-


Diagrama de Estado de Asignación de Profesores a Publicaciones.

3.4 MODELO DEL DOMINIO DEL PROBLEMA.

El Modelo del Dominio del Problema tiene como objetivo principal identificar los

objetos de información y las relaciones que guardan entre sí. Lo anterior se

plasma en un Diagrama de Clases.

Un Objeto es todo aquello que pueda distinguirse dentro del universo de la

aplicación que es Único. Los objetos tienen propiedades o estados y la única forma

de afectar estas propiedades y estados es a través de los comportamientos que

exhibe el objeto.

Una Clase es una plantilla o molde. Es una ayuda notacional para establecer

las propiedades y funciones que serán comunes a todos los objetos que se

generen a partir de ella.



3.5 DIAGRAMA DE CLASES

LJNIVERSIDAD AUTONOMA METROPOLITANA - 19-


4. PROCESO DE DISEÑO.

El Proceso de Diseño plantea el detalle de la interacción de los objetos,

incorporando restricciones físicas de la plataforma de cómputo o bien de los

requerimientos. Este proceso consta de dos modelos: de Diseño y de

Implantación.

Para realizar el Modelo de Diseño es necesario elaborar Diagramas de

Colaboración. Un Diagrama de Colaboración es un diagrama de interacción que

muestra la secuencia de mensajes que implementan una operación o interacción.

Cada Diagrama de Colaboracidn provee de una vista de las interacciones o

relaciones estructurales que ocurren entre objetos.

Estos Diagramas de Colaboración están compuestos por elementos:

Obietos representados por rectángulos. Estos objetos pueden ser de control

porque ejecutan alguna acción que el usuario no ve, sus nombres deben

comenzar con oC;-o bien, pantallas cuyos nombres deben comenzar con el

prefijo oP,

Flechas que representan el flujo de las operaciones que se deben realizar para

continuar con la aplicación. Estas flechas tienen números, estos sirven para

indicar el orden en que se deben realizar las operaciones o interacciones entre

los objetos y el usuario.

Los Diagramas de Colaboración deben de mostrar al usuario como serán las

pantallas en donde este capturará o se le mostrará la información de cada Use

Case. Es por esta razón que cada diagrama debe ir acompañado de su respectiva

pantalla.

A continuación se presentan los Diagramas de Colaboración, las pantallas y la

codificación de los Use Cases que forman parte de este sistema de información.



Registro de Profesor. 2 2 5 8 8 5

UNIVERSIDAD AUTONOMA METROPOLITANA -21 -


Diagramas de Colaboración del Reqistro de Profesores.

El programa comienza cuando el capturista se posiciona en un objeto llamado

oPnumeconomico, que es una pantalla donde se debe capturar el número

económico del profesor al cual se quiere dar de alta eta la Base de Datos. Una vez

realizada esta operación el programa debe revisar que dicho número no este dado

de alta en la base de datos, esta función se llama validanumeconomico y la realiza

un objeto de control Jamado oCnumeconomico es cual se comunica con la Base

de Datos (oBD) a través de una instrucción SQL (instrucciones para manipular la

información de la Base de Datos), esta interacción con la Base de Datos, como ya

se mencionó, es totalmente transparente para el usuario. El siguiente paso es

mostrar una pantalla llamada oPdafospersonales que contenga tanto el número

económico y el nombre del profesor, enseguida el usuario debe capturar los datos

personales del profesor. Una vez capturados los datos personales del profesor se

mostrará otra pantalla llamada oPdafos-laborales para registrar dichos datos. De

igual manera se mostrarán dos pantallas más, la pantalla llamada oPsifuación-

académica y oPestudios. AI final de todas estas pantallas el capturista debe



seleccionar un botón para guardar el registro, esta operación será realizada por

objetos de control: oCguarda-registro, oCguarda-esfudios para después ser

insertados en la Base de Datos.

UNIVERSIDAD AUTONOMA MtTROPOLlTANA -23-


Registro de Publicaciones.

Diagrama de Colaboración del Reqistro de Publicaciones.

L

" L



Renistro de Provectos de Investinación.

Diagrama de Colaboración del Registro de Proyectos de Investiaación.

UNIVERSIDAD AUTONOMA METROPOLITANA -~ ~

- 25 -


Registro de Instituciones.

Diaqrama de Colaboraci6n del Registro de Instituciones.



Registro de Convenios.

Diagrama de Colaboración del Registro de Convenios.

L

I

L

1'


Registro de Equipo de Computo.



Diagrama de Colaboración del Registro de Equipo de ComDuto.



Reaistro de Educación Continua.



Diagrama de Colaboración del Reqistro de Educación Continua.

< . , /. ' I . :,:.:> * : ,' . f 'ri ,$ -:_ *', ,. . i'..i., : *?

I . < ., , .: i . .~ , ... . . . I(: I!. 2 : . . . . . . . . .

I I

f'



Asignación de Profesores a Publicaciones.

UNIVERSIDAD AUTONOMA METROPOLITANA ~~~

- 32 -


Diagrama de Colaboración de Asignación de Profesores a Publicaciones.

L

I I I



Asignación de Profesores a Provectos.

Diagrama de Colaboración de Asignación de Profesores a Provectos.

I

1

- UNIVERSIDAD AUTONOMA METROPOLITANA - 34 -


Asignación de Instituciones a Convenios.


SISTEMA DE INFORMACI6N PARA EL DEPARTAMENTO DE ECONOMíA

Diagrama de Colaboración de Asignación de Instituciones a Convenios.

L

I i 1

1


SISTEMA DE INFORMACION FARA EL DEPARTAMENTO DE ECONOMíA

Asignación de Instituciones a Proyectos.

UNIVERSIDAD AUTONOMA MkTROPOLITANA - 37 -

SISTEMA DE INFORMACI6N PARA EL DEPARTAMENTO DE ECONOMíA

Información Adicional de la institución.

Diagrama de Colaboración de Asignación de Instituciones a Proyectos.

t



Consulta de Profesores.

- Diagrama de Colaboración de Consulta de Profesores.

Los diagramas de colaboración de las especializaciones son muy parecidos al

diagrama anterior. Lo Único que los diferencia es un objeto de control que en lugar

de extraer la información adicional de los profesores de la Base de Datos extrae

las publicaciones y los proyectos de investigación asociados a un profesor en

particular.



A continuación se muestran los Diagramas de Colaboración de la Consulta de

Publicaciones y Proyectos por Profesores.

Consulta Publicaciones v Proyectos por Profesor.

Diagrama de Colaboración de Consulta de Publicaciones por Profesores.

Diagrama de Colaboración de Consulta de Proyectos por Profesores.


SISTEMA DE INFORMACI6N PARA EL DEPARTAMENTO DE ECONOMíA 2 2 5 8 8 5

El Modelo de Implementación consta de dos partes: la implementación de la

Base de Datos y la Programación.

5. IMPLEMENTACIÓN DE LA BASE DE DATOS.

Una Base de Datos es un conjunto integrado de datos, los cuales se almacenan

en archivos, siendo controlados centralmente. Así mismo, los archivos se

interrelacionan entre sí.

En esta etapa todos los objetos persistentes deben de estar en la base de

datos. Un objeto persistente es aquel que dura más allá de la duración del

programa que lo creo.

El Modelo del Domino del Problema se transforma en un Modelo Relacional.

Las transformaciones que debe sufrir el Diagrama de Clases para ser un Modelo

relacionas son:

1. Las clases se transforman en relaciones, también llamadas tablas.

2. Los atributos en columnas de las tablas.

3. Las asociaciones en relaciones.



5.1 MODELO RELACIONAL

En este modelo se representan las tablas, los atributos de cada una de ellas,

las relaciones que guardan y las cardinalidades entre ellas. Los campos en

negritas representan los campos llave de cada tabla.

Las tablas Asignación de Proyectos, Asignación de Publicaciones, Instituciones

participantes y Participación en convenios, son llamadas tablas relacionales. Estas

tablas se usan para quitar asociaciones entre tablas de muchos a muchos ( o o . . ~ ) .

Estas tablas contendrán la información generada a partir de los procedimientos de

las clases Asignación de Proyectos, Asignación de Publicaciones, Instituciones

participantes y Participación en convenios que se muestran en el diagrama de

clases. La tabla de estudios se llena cuando el capturista registra a un profesor.



5.2 MODELO ESENCIAL.

Este modelo tiene como finalidad extraer la funcionalidad esencial del

sistema sin tomar en cuenta ninguna consideración de implementación. Esta

compuesto por dos modelos:

Modelo de Ambiente. Aquí se plantea todo aquello que rodea al sistema, es

decir, ve al sistema como una caja negra. Describe al sistema y su interacción

con el entorno.

Modelo de Comportamiento. Este modelo ve al sistema por dentro, es decir, su

funcionamiento. Este modelo sólo sirve para indicar al programador las

funciones y procedimientos que debe realizar el sistema.

5.3 MODELO DE AMBIENTE.

Esta formado por:

Propósito del Sistemc

Sistema de Información para el Departamento de Economía

El sistema permitirá disponer de información actualizada e interrelacionada de

las funciones de investigación, las publicaciones y el equipo de computo de la

planta académica, además de las relaciones que se tienen con otras instituciones

y la educación continua que se brinda para el cumplimiento de los objetivos del

departamento de economía de la Universidad Autónoma Metropolitana unidad

Iztapalapa.

Diagrama de Contexto. Aquí se muestra un esquema de caja negra que describe

los flujos de información que entran y salen del sistema, así como las fuentes y

destinos de dicha información.

UNIVERSIDAD AUTONOMA METROPOLITANA -43 -

; j c z 9 c z v)

L

iy C "I z

v)

-

o

c "I

v)

%

2 z

l-

o "I C z v) "I 9

%

Date post:	18-Oct-2018
Category:	Documents
Upload:	lequynh
View:	212 times
Download:	0 times

HERNANDEZ - 148.206.53.84148.206.53.84/tesiuami/UAM4363.pdf · 3.2 Modelo de Use Cases 3.3 Modelo...

Documents