Aplicacion web

i
Aplicación Web para el Registro y Control de
Documentos de las Dependencias
Administrativas de la
Universidad Nacional Abierta
Caso de Estudio Centro Local Lara
Informe Final de Práctica Profesional
UNIVERSIDAD NACIONAL ABIERTA
VICE-RECTORADO ACADEMICO
AREA DE INGENIERIA
CARRERA INGENIERIA DE SISTEMAS
Autor: Br. Amarelis del Carmen Ybarra Dugarte C.I. 15.032.367
Tutor Académico: Prof. Pedro Luis Rodríguez C.I. 11.187.871
Tutor Empresarial: Profa. Saibel Ramos C.I.:9.837.306
Centro Local Portuguesa
MARZO, 2014

ii
INDICE GENERAL
Dedicatoria……………………………………………………………………………i
Agradecimientos……………………………………………………………………..ii
Resumen………………………………………………………………………...…..iii
Introducción…………........................................................................................1
CAPITULO I
Planteamiento del problema.............................................................................4
Objetivos……………………………………………………………………………..6
Objetivo general..........................................................................................6
Objetivos específicos……...........................................................................6
Alcance.............................................................................................................7
CAPITULO II
MARCO TEÓRICO....………………………………………………………………9
Ingeniería del Software……...............................................................12
Lenguaje Unificado de Modelado UML…………………………..........14
Objetivos de UML……..............................................................19
Uso del Lenguaje unificado de modelado...............................20
Fases del ciclo de desarrollo que soporta UML…..…………..20
Diagramas que ofrece el UML………………...…………….….21
Modelo cliente-servidor…………………………..…………..….33
Programación orientada a objetos……………………………...34
Servidor Web Seguro……………………………………..…..…36
Páginas Web……………………………………………………...37
Lenguaje SQL…………………………………………………...38

iii
Bases de Datos………………………………………………….40
Modelo Entidad-Relación……………………………………....41
Normalización……………………………………………………44
Lenguaje de Programación PHP………………………….…..50
Common Getaway Interface (CGI)……………………………52
Secure Socket Layer (SSL)……………………………………53
Sistema Operativo GNU/Linux………………………………..57
CAPITULO III
MARCO METODOLÓGICO
Dimensiones del RUP..........................................................................61
Fases…………………..……………......................................................73
Disciplinas………..……………………..................................................80
Modelado del Negocio…............................................................80
Requerimientos...........................................................................81
Análisis y Diseño.........................................................................81
Implementación...........................................................................81
Pruebas…...................................................................................82
Despliegue…………....................................................................82
Gestión y configuración de cambios...........................................82
Gestión del Proyecto……...........................................................83
Entorno…………………..............................................................84
Organización y elementos en RUP.......................................................84
Análisis y diseño de la Metodología RUP………………………………………97
CAPITULO IV

iv
ORGANIZACIÓN Y ANÁLISIS DE LOS RESULTADOS
Modelado del Negocio…………………………………………………………..107
Requerimientos………………………………………………………………….109
Especificaciones Complementarias……………………………………………112
Actores del Sistema……………………………………………………………..113
Casos de Uso………………………………………………………………….…113
Diagramas de Casos de Uso……………………………………………………116
Diagramas de Estado de RED…………………………………………………172
Diagramas de Secuencia………………………………………………………176
Asignación de Operaciones a las Clases (Control de Documentos)………185
Asignación de Operaciones a las Clases (Seguridad)……………….………186
Diagrama de Despliegue…………………………………………………..……187
Diagrama de Base de Datos..……………………………………………..……187
Modelo Entidad Relación de RED……………………………………...………191
Gestión de Proyecto: Escogencia del lenguaje de programación………….192
Escogencia del Gestor de Base de Datos……………………………………193
Actividades de formación………………………………………………………194
Recursos Adicionales……………………………………………………………195
Implementación…………………………………………………………………..195
Desarrollo de componentes y codificación de software……………………..195
Relación de los componentes con la Base de Datos…………………..……196
Funcionalidades del Sistema……………………………………………………197
Interfaz de Usuario……………………………………………………………….197
Interfaz de Acceso al Sistema RED……………………………………………198

v
Interfaz General del sistema RED……………………………………………..199
CAPITULO V
CONCLUSIONES Y
RECOMENDACIONES…………………………………………………….…....224
Bibliografía……………………………………………………………………..…227
Anexos………………………………………………………………………….…231

vi
ÍNDICE DE TABLAS
Tabla Nº 1 Estereotipo Utilizados en
la Notación WAE
31
Tabla Nº 2 Esfuerzo – Horario contra
fases del RUP
73
Tabla Nº 3 Artefactos en las Fases
de RUP
87
Tabla Nº 4 Desarrollo de la RUP
92
Tabla Nº 5 Actores del Sistema
109
Tabla Nº 6 Descripción de los Casos
de Uso
110
Tabla Nº7 Descripción de las tablas
de la Base de Datos
186

vii
INDICE DE FIGURAS
Figura Nº 1 Modelo de Cascada de
Desarrollo de Software
13
Figura Nº 2 Desarrollo de UML, con
sus versiones
16
Figura Nº 3 Casos de Uso 18
Figura Nº 4 Diagramas del UML que
expresan gráficamente un Modelo
21
Figura Nº 5 Ejemplo de Modelo de
Casos d Uso
22
Figura Nº 6 Ejemplo de un Diagrama
de Clases
25
de Colaboración
26
de Secuencia 29
Figura Nº 9 Modelo Cliente Servidor
en un entrono WEB
34
Figura Nº 10 Intercambio de
Información entre un Navegador
Web y un Servidor WEB
37
Figura Nº 11 Tabla en Primera forma
Normal
46
Figura Nº 12 Tabla que no está en
Segunda Forma Normal
47
Figura Nº 13 Tabla Productos 47
Figura Nº 14 Tabla Proveedores 48
Figura Nº 15 Tabla Atletas 49
Figura Nº 16 Tabla Atletas parte 1 49

viii
Figura Nº 17 Tabla Atletas parte 2 49
Figura Nº 18 Transacción usando
cifrado SSl
53
Figura Nº 19 Indicación de una
conexión segura en Navegadores
Web
55
Figura Nº 20 Historia del RUP 60
Figura Nº 21 Disciplinas, fases,
iteraciones del RUP
62
Figura Nº 22 Los Casos de Uso
integran al trabajo
63
Figura Nº 23 Trazabilidad a partir de
los Casos de Uso
64
Figura Nº 24 Evolución de la
arquitectura del sistema
66
Figura Nº 25 Los modelos se
completan, la arquitectura no cambia
drásticamente
67
Figura Nº 26 Una iteración RUP 69
Figura Nº 27 Ciclo de Vida 70
Figura Nº 28 Fases del RUP 71
Figura Nº 29 Recursos utilizados en
las fases del RUP en el tiempo
74
Figura Nº 30 Ciclo evolutivo en la
elaboración de software basado en
RUP
75
Figura Nº 31 Esfuerzo respecto de
los flujos de trabajo
76
Figura Nº 32 Esfuerzo respecto de
las fases
77

ix
Figura Nº 33 Elementos que
conforman el RUO
83
Figura Nº 34 Artefactos en las
disciplinas de la RUP
88
Figura Nº 35 Grado de finalización
de artefactos
89
Figura Nº 36 Comparación entre
diagramas de casos de uso
98
diagramas de objetos
99
diagramas de estados
100
diagramas de actividades
100
diagramas de secuencia
101
diagramas de colaboración
102
Figura Nº 42 Diagramas de
componentes
102
diagramas de despliegue
103
Figura Nº 44 Diagrama del Caso de
Uso Incluir Estado
113
Uso Eliminar Estado
115
Uso Buscar Estado
116
Uso Incluir Tipo Documento
117
Figura Nº 49 Diagrama del Caso de 118

x
Uso Modificar Tipo Documento
Uso Eliminar Tipo Documento
119
Uso Buscar Tipo Documento
120
Uso Incluir Entidad
121
Uso Modificar Entidad
122
Uso Eliminar Entidad
123
Uso Buscar Entidad
124
Uso Incluir Tipo Entidad
124
Uso Modificar Tipo Entidad
125
Uso Eliminar Tipo Entidad
126
Uso Incluir Archivo
128
Uso Modificar Archivo
129
Uso Eliminar Archivo
130
Uso Buscar Archivo
131
Uso Incluir Documento
132
Uso Modificar Documento
133

xi
Uso Eliminar Documento
135
Uso Buscar Documento
136
Uso Incluir Seguimiento
137
Uso Modificar Seguimiento
138
Uso Eliminar Seguimiento
139
Uso Buscar Seguimiento
140
Figura Nº 71 Diagrama de Caso de
Uso Reporte Tipo Documento
141
Uso Reporte Estados
143
Uso Reporte Entidades
144
Uso Reporte Documentos
145
Uso Reporte Archivadores
146
Uso Incluir Sistema
147
Uso Modificar Sistema
148
Uso Eliminar Sistema
149
Uso Buscar Sistema
150
Figura Nº 81 Diagrama de Caso de 151

xii
Uso Incluir Perfil Usuario
Uso Modificar Perfil Usuario
152
Uso Eliminar Perfil Usuario
153
Uso Buscar Perfil Usuario
154
Uso Incluir Cargo Usuario
155
Uso Eliminar Cargo Usuario
157
Uso Buscar Cargo Usuario
158
Uso Incluir Usuario
159
Uso Modificar Usuario
160
Uso Eliminar Usuario
161
Uso Buscar Usuario
162
Figura Nº 93 Modelo General del
Diagrama de Casos de Uso de RED
163
Figura Nº 94 Diagrama de Clases
(Módulo Control de Documentos)
166
Figura Nº 95 Diagrama de clases
(Módulo Seguridad)
167
Usando estereotipos (Control de
documentos)
168
Usando estereotipos (Seguridad)
168

xiii
Figura Nº 98 Diagrama de Estados
(Control de Documentos)
170
Figura Nº 99 Diagrama de Estados
(Seguridad)
171
Figura Nº 100 Diagrama de
Secuencia del Caso de Uso Incluir
Documento
173
Secuencia del Caso de Uso
Modificar Documento
174
Secuencia del Caso de Uso Eliminar
Documento
175
Secuencia del Caso de Uso Buscar
Documento
176
Secuencia del Caso de Uso Incluir
Seguimiento
177
Secuencia del Caso de Uso Modifica
Seguimiento
178
Secuencia del Caso de Uso Eliminar
Seguimiento
179
Secuencia del Caso de Uso Buscar
Seguimiento
180
Secuencia del Caso de Uso Reporte
Documento
181
Despliegue de RED
185

xiv
Figura Nº 110 Lenguaje de
Programación utilizado para el
desarrollo de la aplicación
191
Figura Nº 111 Interfaz del entorno
MySQL Administrator
192
Figura Nº 112 Interfaz de Inicio de
Sesión al sistema RED
269
Figura Nº 113 Interfaz de Principal
del sistema RED
270
Figura Nº 114 Interfaz del Menú del
Módulo Seguridad
271
Figura Nº 115 Interfaz para sistemas 272
Figura Nº 116 Interfaz de Perfiles de
Usuarios
272
Figura Nº 117 Interfaz de Cargos de
Usuarios
273
Figura Nº 118 Interfaz Usuarios 274
Figura Nº 119 Interfaz de salida del
sistema
274
Figura Nº 120 Interfaz para el
Usuario del Menú Definiciones
275
Usuario del Menú Proceso
276
Usuario del Menú Reportes
277
Figura Nº 123 Interfaz para la
Inserción, Eliminación, Modificación
y Búsqueda de Estados
278
Figura Nº 124 Interfaz de Búsqueda
de un Estado
278
Figura Nº 125 Interfaz para la 279

xv
y Búsqueda de Tipo de Documento
y Búsqueda de Entidades
280
de una entidad
281
y Búsqueda de Tipo de Entidades
281
para tipo de Entidades
282
y Búsqueda de Archivos
282
de Archivo
283
y Búsqueda de Documentos
284
de Documentos
285
y Búsqueda de Seguimiento
286
de Seguimiento de Documentos
287
Figura Nº 137 Interfaz para el reporte
de Tipo de Entidades
287
Figura Nº 138 Archivo PDF de Tipo
de Entidades
288
Figura Nº 139 Interfaz de Reporte de
Tipos de Documentos
289

xvi
Figura Nº 140 Archivo PDF de Tipos
de Documentos
290
Tipos de Estados
291
Figura Nº 142 Archivo PDF de
Estados
291
Figura Nº 143 Interfaz de Reporte
Entidades
292
Entidades
293
Archivos
293
Archivos
294
documentos por medio de
Descriptores
295

i
DEDICATORIA
Primero que todo quiero dedicarle éste paso en mi vida profesional a Dios
Todopoderoso y a la Santísima Virgen por darme la virtud y la fortaleza
necesaria para salir siempre adelante, pese a las dificultades; iluminando
cada paso de mi vida.
A mis Padres, Albis y Teodolinda, son ustedes quienes verdaderamente
son los dueños de éste título, sin su apoyo no lo habría logrado, mil gracias
por ser mis guías y un ejemplo de trabajo, esfuerzo y dedicación.
A mi Hermana Theisy, porque nunca dudó de que lograría este triunfo y
con la que compartí cada etapa de este camino, recibiendo siempre una
sonrisa y un apoyo irremplazable.
A mi Tío Jesús Rangel (Q.E.P.D.), quien siempre me motivó a seguir
adelante y a quien prometí terminaría mis estudios. Promesa cumplida.
Sin Ustedes no hubiese podido hacer realidad este sueño.
¡Los Amo!

ii
AGRADECIMIENTOS
A Dios y la Virgen, por ser mis guías, iluminando y protegiendo siempre
mi camino.
A mis Padres y Hermana, por sus consejos, atenciones, cariño y apoyo
incondicional a lo largo de la carrera.
A mi Esposo quien me brindó su apoyo constante y paciencia para que
pudiera terminar esta meta.
A la Universidad Nacional Abierta, mi casa de estudio, por brindarme la
formación académica requerida.
A mis Profesores Carlos Aguirre, Pedro Rodríguez y Saibel Ramos,
por su ayuda, confianza, paciencia, estímulo, calidad profesional y
conocimientos que me ayudaron a finalizar mi trabajo.
A Dra. Dora de Valderrama, Sra. María Peraza y Elizabeht Valladares,
por la comprensión, amistad, confianza, paciencia, ánimos y por darme el
permiso en mi área laboral cuando necesité ausentarme.
En General a todas aquellas personas que de una u otra forma
colaboraron o participaron en mi formación como persona y profesional, hago
extensivo mis más sinceros agradecimientos.
¡Mil Gracias!

iii
RESUMEN
La Sección Académica del Centro Local Lara de la Universidad Nacional
Abierta, es el organismo destinado para estudiar las cuestiones relacionadas
con las funciones de docencia, investigación y extensión que ejerce en dicha
universidad. Para mejorar su funcionamiento surgió la necesidad de
desarrollar un software que automatizara la Recepción y Emisión de
Documentos desde, y para este departamento. La aplicación fue desarrollada
bajo los lineamientos de la Metodología del Proceso Unificado, la cual divide
el desarrollo del proyecto en 4 fases: Inicio, Elaboración, Construcción y
Transición. Con el desarrollo de esta práctica profesional se pretendió
implantar en la Unidad Académica del Centro Local Lara de la Universidad
Nacional Abierta una aplicación que tuviese el siguiente alcance: a) Controlar
los documentos enviados y recibidos de las diferentes áreas y
departamentos del propio centro local. b) Registrar y controlar los
documentos que provienen y/o son enviados a otros centros locales o a nivel
central. c) Optimización de la búsqueda de información que requieren
consultar dichas dependencias en un momento determinado, y que
difícilmente la persona encargada en el departamento. d) Hacer un registro
adecuado de la información generada y recibida en cada departamento. Se
realizó la metodología una iteración por cada fase, se identificaron los
requisitos del departamento y se representaron en un modelo de caso de
uso. Luego se realizó el análisis y diseño de los casos de usos y de las
clases que fueron implementadas. El sistema fue codificado utilizando el
lenguaje de programación PHP (Adobe Dreamweaver CS5). Se utilizó el
sistema manejador de base de datos MySQL Administrator para la
implementación de la base de datos. Palabras claves: Unidad Sección
Académica, recepción, emisión, documentos, búsqueda, metodología.

1
INTRODUCCIÓN
En la actualidad las grandes empresas e instituciones públicas o privadas
requieren inmediatez en el manejo de información, debido a la rapidez con la
que se manejan datos en los diferentes departamentos que conforman
dichas instituciones, los cuales son de vital importancia para el buen
funcionamiento de los mismos. Es por ello que las aplicaciones Web se
están implementando en muchas empresas donde sus procesos
administrativos carecen de bases tecnológicas que ayuden a fortalecer la
estructura comunicacional de las mismas.
A mediados del siglo pasado los cambios tecnológicos se sucedían muy
lentamente, con lo cual las organizaciones disponían del tiempo suficiente
para analizar los factores relevantes y adoptar nuevas decisiones que
condujesen a su buen funcionamiento.
Actualmente, la complejidad de los sistemas va en aumento con la
aparición de nuevas tecnologías en un entorno que cambia sin cesar; el
tiempo que se tarda en transformar una necesidad identificada en el
desarrollo de un nuevo sistema operativo es cada vez más largo y los costos
asociados con el desarrollo, producción, utilización y apoyo de los sistemas
están incrementando.
Para los Ingenieros Carlos Curotto y Pablo Díaz: “En los primeros días los
sitios Web consistían de páginas estáticas, permitiendo una interacción
limitada con el usuario. Al comienzo de los años 90, estas limitaciones fueron
superadas cuando los servidores Web fueron reemplazados para permitir
comunicaciones a través del desarrollo de fragmentos de código que eran
ejecutados del lado del servidor. A partir de entonces las aplicaciones

2
dejaron de ser estáticas y solamente editadas por aquellos “gurúes” del
HTML y se permitieron a usuarios normales interactuar con las aplicaciones
por primera vez.” Este fue un paso fundamental para llegar a la Web que hoy
en día conocemos. Sin la interacción no existiría el comercio electrónico (Ej.:
Amazon.com), el Web-mail (Ej.: Gmail), Internet-banking, blogs, fórums o
comunidades online, entre otros.
A través del tiempo, el conocimiento necesario para construir
aplicaciones ha sido reducido. Hoy día, es relativamente sencillo construir
aplicaciones sofisticadas utilizando las modernas plataformas y lenguajes,
como ser PHP, .NET o Java.
La falta de manejos de sesiones y control de autorización por parte de
Common Gateway Interface (CGI) impidió el desarrollo de aplicaciones Web
comerciales con esa tecnología.
Los desarrolladores Web comenzaron entonces a utilizar lenguajes de
script, como ser JavaScript o PHP para resolver esos problemas.
Básicamente los lenguajes de script son ejecutados en el servidor Web y
como son no compilados son desarrollados e implementados más fácilmente.
El propósito de este trabajo se enmarca dentro de este interés,
enmarcada bajo los lineamientos de la Metodología RUP (Rational Unified
Process) debido a la flexibilidad que tiene de adaptarse a cualquier tipo de
proyecto haciendo uso de buenas prácticas en el desarrollo de software
como desarrollo iterativo, administrativo eficiente de requerimientos y
prototipos incrementales Es por ello que se plantea la realización de una
Aplicación Web para el Registro y Control de Documentos en las
dependencias administrativas de los Centros Locales de la Universidad

3
Nacional Abierta, la cual permitirá la optimización de la búsqueda de
información que requieren consultar en las distintas dependencias en un
momento determinado.
Esta investigación se encuentra formulada de la siguiente manera:
a) Capítulo I: abarca el Planteamiento del Problema, donde se describe la
situación del problema, el trabajo a desarrollar, la situación actual y área
problemática, así como la solución propuesta y los beneficios que la
misma traería, además del Objetivo General y los objetivos Específicos,
que se alcanzan en el desarrollo del proyecto y el Alcance del Trabajo,
en el cual se indicará hasta dónde se llegará con el trabajo, demarcando
los límites del mismo.
b) Capítulo II: engloba el Marco Teórico de la Investigación, incluye los
trabajos de investigación de diferentes autores que hacen referencia al
tema (Desarrollo de Aplicaciones WEB) y las bases teóricas que
ayudaron al desarrollo de la misma.
c) Capítulo III: corresponde al Marco Metodológico, donde se describe la
metodología a utilizar en el desarrollo de la solución propuesta.
d) Capitulo IV: contiene la Organización y Análisis de los Resultados
obtenidos en el trabajo de investigación.
e) Capítulo V: comprende las Conclusiones y Recomendaciones que
arrojaron el trabajo de investigación

4
CAPÍTULO I
PLANTEAMIENTO DEL PROBLEMA
La Unidad Académica del Centro Local Lara de la Universidad Nacional
Abierta (UNA), es el organismo destinado para estudiar las cuestiones
relacionadas con las funciones de docencia, investigación y extensión que
ejerce en dicha universidad, para el Estado Lara específicamente. Siendo
esta dependencia la que se tomará como referencia de estudio para esta
investigación, donde se pretende analizar la forma de cómo llevar de manera
automatizada la recepción y envíos de documentos en este departamento, ya
sea de manera interna o externa en el centro local.
Actualmente dicha entidad presenta la necesidad de un sistema de control
de documentos enviados y recibidos de las diferentes áreas y departamentos
del propio centro local. Es conveniente resaltar que su sistema real es el
físico, lo cual hace que dicha actividad sea lenta y en algunos casos
infructuosa, debido a que se maneja un archivo de documentos (lugar donde
se almacena el material escrito), conllevando a que exista la posibilidad de
que no sea encontrada la información requerida y así ayude a la pérdida de
tiempo y esfuerzo por parte de la persona encargada de su búsqueda. Por
ejemplo, si un profesor que recién encargan para dirigir una oficina como la
de sección académica, (unidad esta que recibe y emite diariamente muchos
documentos), es muy difícil que recuerde documentos que recibió hace un
mes, o su defecto más complicado tener en cuenta documentos que hayan
recibido antes de su gestión, esto hace la gerencia de este tipo de cargos
transitorios muy complicados ya que sin un registro indexado sea físico o

5
automatizado de los documentos procesados se haga un tarea cuesta arriba
y conlleva una pérdida de tiempo muy importante.
Por ello se requiere registrar y controlar los documentos que provienen y/o
son enviados a otros centros locales o a nivel central. Todo esto con la
finalidad de poder consultar en línea con buscadores especiales, (sobre la
intranet del centro local en estudio), la ubicación exacta del documento
solicitado en el archivo físico donde está almacenado el mismo. Dicha
búsqueda será realizada específicamente por una frase del documento, una
fecha, un tema, una dependencia, un remitente, etc.
La realización de una aplicación web para el Registro y Control de
Documentos en las dependencias administrativas de los Centros Locales de
la Universidad Nacional Abierta, permitirá la optimización de la búsqueda de
información que requieren consultar dichas dependencias en un momento
determinado, y que difícilmente la persona encargada en el departamento, en
este caso la Unidad Académica del Centro Local Lara, pueda saberla o en
su defecto recordarla. Además, por medio de dicha aplicación se podrá hacer
un registro adecuado de la información generada y recibida en cada
departamento, teniendo la posibilidad de ordenar electrónicamente la
ubicación de los documentos y hacerlos corresponder con el espacio físico
donde se encuentren.

6
OBJETIVOS
OBJETIVO GENERAL
Desarrollar una Aplicación Web para el Registro y Control de Documentos
de las Dependencias Administrativas de los Centros Locales de la
Universidad Nacional Abierta.
OBJETIVOS ESPECÍFICOS
a) Realizar el modelo del negocio, mediante el estudio y descripción de
las funciones que cumple la Unidad Académica del Centro Local Lara.
b) Especificar los requisitos, que permitan satisfacer las necesidades de
información de los usuarios del sistema que llevará el Registro y
Control de Documentos.
c) Realizar el modelado de diseño y de datos del sistema.
d) Implementar la aplicación web.
e) Realizar las pruebas necesarias para medir el comportamiento y
asegurar el buen funcionamiento de la aplicación web desarrollada.
f) Implantar la aplicación web en la Unidad Académica del Centro Local
Lara.
g) Elaborar el Informe Final de Práctica Profesional.

7
ALCANCE
Las aplicaciones Web ofrecen un complejo arreglo de contenido y
funcionalidad a una amplia población de usuarios finales y se evalúan
mediante criterios tanto técnicos como institucionales.
En base a la motivación del trabajo, en el desarrollo de esta práctica
profesional se pretende implantar en la Unidad Académica del Centro Local
Lara de la Universidad Nacional Abierta una aplicación que resuelva todos o
la mayoría de los problemas presentados como son:
a) Controlar los documentos enviados y recibidos de las diferentes
áreas y departamentos del propio centro local.
b) Registrar y controlar los documentos que provienen y/o son
enviados a otros centros locales o a nivel central. Todo esto con
la finalidad de poder consultar en línea con buscadores especiales,
(sobre la intranet del centro local en estudio), la ubicación exacta
del documento solicitado en el archivo físico donde está
almacenado el mismo. Dicha búsqueda será realizada
específicamente por una frase del documento, una fecha, un
tema, una dependencia, un remitente, etc.

8
c) Optimización de la búsqueda de información que requieren
consultar dichas dependencias en un momento determinado, y que
difícilmente la persona encargada en el departamento, en este
caso la Secretaria y/o Jefe de la Unidad Académica del Centro
Local Lara, pueda saberla o en su defecto recordarla.
d) Hacer un registro adecuado de la información generada y recibida
en cada departamento, teniendo la posibilidad de ordenar
electrónicamente la ubicación de los documentos y hacerlos
corresponder con el espacio físico donde se encuentren.
Sin embargo como toda aplicación, esta no está exenta de presentar
algunas limitaciones, entre las cuales podemos mencionar:
a) Dificultades para obtener en las aplicaciones Web
comportamientos clásicos de aplicaciones stand-alone (Hecho a la
medida).
b) Necesidad de aprendizaje de lenguajes adicionales (HTML,
JavaScript, CSS) que pertenecen al basamento del desarrollo de
aplicaciones Web, para construir apropiadamente la aplicación.
Es importante acotar que la aplicación propuesta posee características
valiosas que nos servirán como punto de partida para resolver el tema
planteado, es decir llevar el registro y control de todos los documentos en las
dependencias administrativas, para así evitar la pérdida de datos e
información y con ello implantar una novedosa aplicación que podrá ser
instalada en cualquier departamento e incluso en instituciones ajenas a la
Universidad Nacional Abierta en un momento dado y de esta forma ayudar al
crecimiento en materia tecnológica a quienes lo requieran.

9
CAPÍTULO II
MARCO TEÓRICO
Dentro de la línea de investigación que se ha realizado a cerca de las
aplicaciones Web sea recopiló información de varios autores que sirvieron
como soporte para llevar a cabo tal investigación. Entre los trabajos más
relevantes que aportaron información (aplicaciones web y metodología a
usar) sobre el tema tratado en este estudio se encuentran:
 Intriago Macias, Ana Yadira (2013), en su trabajo de grado
Desarrollo e Implementación de un Aplicación Web de encuestas de
satisfacción docente y currículum para la Facultad de Ciencias
Informáticas, permite obtener el currículum actualizado y realizar
encuestas online y conocer la satisfacción del docente en las
diferentes áreas, sean estas académicas, gestión, investigación,
vinculación, infraestructura, entre otras.
 Tubay Vergara, José Luis (2010), realizó como tesis de grado
Desarrollo de una Aplicación Web para el control de Avances
Académicos y Asistencia de Docentes, con la cual se puede obtener

10
un control de cada uno de los Docentes en el cumplimiento
académico de una manera fácil y rápida.
 Guariman Rondón, Oscar Enrique (2009), en su trabajo de grado
Diseño de una aplicación Web para la Gestión en Línea de los
Servicios Académicos de una Institución de Educación Superior se
refiere al diseño de una aplicación informática utilizando tecnología
Web. Este permitirá la gestión en línea de los servicios académicos de
la Universidad Bolivariana de Venezuela (UBV), la cual está distribuida
en 5 sedes en todo el territorio nacional. La UBV ofrece Programas de
Formación de Grado que se imparten no sólo en la sede, sino también
en otras instalaciones denominadas “aldeas”. Para la recolección de
información acerca de los procesos que dan soporte a los servicios
académicos como son: las inscripciones, solicitud de documentos,
registro de notas, prosecución del estudiante, entre otros, se
emplearon técnicas como la entrevista y observación directa.
 Blanco, Ignacio Carlos (2008), en su trabajo de tesis denominado
Plataformas de desarrollo de Aplicaciones Web orientadas a
componentes reutilizables, estudia las plataformas de desarrollo de
aplicaciones Web existentes teniendo en cuenta su arquitectura, los
servicios prestados así como también sus fortalezas y debilidades. En
base al análisis comparativo y a un conjunto de requerimientos
necesarios para el desarrollo de aplicaciones Web empresariales se
planteará una posible solución, una plataforma, que cumpla con los
requerimientos y a la vez que resuelva las debilidades encontradas en
las plataformas estudiadas.

11
 Mora Luján, Sergio (2002), en su trabajo sobre Programación sobre
Aplicaciones Web, nos explica que las aplicaciones web permiten la
generación automática de contenido, la creación de páginas
personalizadas según el perfil del usuario o el desarrollo del comercio
electrónico, además permite interactuar con los sistemas informáticos
de gestión de un empresa, como puede ser gestión de clientes,
contabilidad o inventario a través de una página web. También nos
señala que las aplicaciones web se encuentran dentro de las
arquitecturas cliente/servidor.
 Para el año 2001 el estudiante Iván José Puglieser Saroff realizó el
trabajo de grado “Desarrollo del Sistema de Compras
Cliente/Servidor para la Universidad de Oriente, Núcleo
Anzoátegui”, En este trabajo se plantea la necesidad de que en la
Universidad de Oriente Núcleo Anzoátegui se desarrolle un sistema
que permita gestionar las compras de la Universidad de Oriente
núcleo Anzoátegui, para lo cual el estudiante Iván Puglieser diseñó
una herramienta para gestionar el procesamiento de las solicitudes de
compras, ordenes de compras, hojas de análisis e informe de
recepción. El análisis y diseño de esta aplicación fue realizado
mediante la notación UML (Unified Modeling Language) y fue
implantado bajo la tecnología cliente/servidor.
 Para el año 2001 el estudiante Alfredo Molero desarrolló el trabajo
titulado “Diseño de la Intranet de la Escuela de Medicina de la
Universidad de Oriente Núcleo de Anzoátegui”. Donde se plantea
el diseño e implantación de un proyecto de alto nivel tecnológico que
solvente los problemas de comunicación y coordinación de índole
académico-administrativo de la escuela de medicina. Para ello de

12
diseño una infraestructura de hardware y software que conformó la
Intranet de dicha escuela la cual permitió el uso de aplicaciones que
se diseñaron para el uso en la Intranet así como herramientas que
permitieran ayudar al control de las distintas actividades
administrativas.
BASES TEÓRICAS
A continuación se presentarán una serie de conceptos y definiciones
relacionadas con el tema central de este trabajo.
INGENIERÍA DE SOFTWARE
El proceso de ingeniería de software se define como “un conjunto de
etapas parcialmente ordenadas con la intención de lograr un objetivo, en este
caso, la obtención de un producto de software de calidad…".Roger Presman
Ingeniería del Software (Pág…24) El proceso de desarrollo de software “es
aquel en que las necesidades del usuario son traducidas en requerimientos
de software, estos requerimientos transformados en diseño y el diseño
implementado en código, el código es probado, documentado y certificado
para su uso operativo". Concretamente "define quién está haciendo qué,
cuándo hacerlo y cómo alcanzar un cierto objetivo…." (Pág…24).
El proceso de desarrollo de software requiere por un lado un conjunto
de conceptos, una metodología y un lenguaje propio. A este proceso también
se le llama el ciclo de vida del software que comprende cuatro grandes fases:
concepción, elaboración, construcción y transición (véase figura Nº 1).

13
La concepción define el alcance del proyecto y desarrolla un caso de
negocio, la elaboración define un plan del proyecto, especifica las
características y fundamenta la arquitectura, la construcción crea el producto
y la transición transfiere el producto a los usuarios.
Figura Nº 1 Modelo de Cascada de Desarrollo de Software.
Fuente: elaboración propia, año: 2014.
Actualmente se encuentra en una etapa de madurez el enfoque OO
(Orientado a Objetos) como paradigma del desarrollo de sistemas de
información. El (OMG) Object Management Group es un consorcio a nivel
internacional que integra a los principales representantes en la industria de la
tecnología de información OO, éste tiene como objetivo central la promoción,
fortalecimiento e impulso de la tecnología OO, propone y adopta por
consenso especificaciones entorno a esta. Una de las especificaciones más
importantes es la adopción en 1998 del Lenguaje de Modelado Unificado o
UML como un estándar, que junto con el Proceso Unificado están
consolidando la tecnología OO.

14
LENGUAJE UNIFICADO DE MODELADO UML
UML surge como respuesta al problema de contar con un lenguaje
estándar para escribir planos de software. Muchas personas han creído ver
UML como solución para todos los problemas sin saber en muchos casos de
lo que se trataba en realidad.
El Lenguaje Unificado de Modelado, UML es una notación estándar para
el modelado de sistemas software, resultado de una propuesta de
estandarización promovida por el consorcio OMG (Object Management
Group),del cual forman parte las empresas más importantes que se dedican
al desarrollo de software, en 1996.
UML representa la unificación de las notaciones de los métodos Booch,
Objectory (Ivar Jacobson) y OMT (James Rumbaugh) siendo su sucesor
directory compatible. Igualmente, UML incorpora ideas de otros metodólogos
entre los que se pueden incluir a Peter Coad, Derek Coleman, Ward
Cunningham, David Harel, Richard Helm, Ralph Johnson, Stephen Mellor,
Bertrand Meyer, Jim Odell, Kenny Rubin, Sally Shlaer, John Vlissides, Paul
Ward, Rebecca Wirfs-Brock y Ed Yourdon.
En Septiembre de 2001 se ha publicada la especificación de la versión1.4.
Es importante recalcar que sólo se trata de una notación, es decir, de una
serie de reglas y recomendaciones para representar modelos. UML no es un
proceso de desarrollo, es decir, no describe los pasos sistemáticos a seguir
para desarrollar software. UML sólo permite documentar y especificar los
elementos creados mediante un lenguaje común describiendo modelos.
El Lenguaje Unificado de Modelado o UML es una técnica para la
especificación de sistemas en todas sus fases. Esta ha sido desarrollada por

15
los más importantes autores en materia de análisis y diseño de sistemas, ha
sido usada con éxito en sistemas hechos para toda clase de industrias
alrededor del mundo: salud, bancos, comunicaciones, aeronáutica, finanzas,
etc.
UML no es un lenguaje de programación. Existen herramientas que
pueden ofrecer generadores de código de UML para una gran variedad de
lenguaje de programación, así como construir modelos por ingeniería inversa
a partir de programas existentes. Este es pues un lenguaje de propósito
general para el modelado orientado a objetos, UML es también un lenguaje
de modelamiento visual que permite una abstracción del sistema y sus
componentes.
En la figura Nº 2 se puede observar el desarrollo de UML y sus versiones
en los años dados, sufriendo revisiones menores, y ciertos participantes en
las diversas versiones.

16
Figura Nº 2. Desarrollo de UML, con sus versiones
Fuente: http://www.usmp.edu.pe/publicaciones/boletin/fia/info21/fig_uml.jpg
UML es un lenguaje de propósito general para el modelado orientado a
objetos, que combina notaciones provenientes desde: Modelado Orientado a
Objetos, Modelado de Datos, Modelado de Componentes, Modelado de
Flujos de Trabajo (Workflows).
En todos los ámbitos de la ingeniería se construyen modelos, en realidad,
simplificaciones de la realidad, para comprender mejor el sistema que vamos
a desarrollar: los arquitectos utilizan y construyen planos (modelos) delos
edificios, los grandes diseñadores de coches preparan modelos en sistemas
existentes con todos los detalles y los ingenieros de software deberían
igualmente construir modelos de los sistemas software.

17
Un enfoque sistemático permite construir estos modelos de una forma
consistente demostrando su utilidad en sistemas de cierto tamaño. Cuando
se trata de un programa de cincuenta, cien líneas, la utilidad del modelado
parece discutible pero cuando involucramos a cientos de desarrolladores
trabajando y compartiendo información, el uso de modelos y el proporcionar
información sobre las decisiones tomadas, es vital no sólo durante el
desarrollo del proyecto, sino una vez finalizado éste, cuando se requiere
algún cambio en el sistema. En realidad, incluso en el proyecto más simple
los desarrolladores hacen algo de modelado, si bien informalmente.
Para la construcción de modelos, hay que centrarse en los detalles
relevantes mientras se ignoran los demás, por lo cual con un único modelo
no tenemos bastante.
Como Inconvenientes en UML se tiene que Como todo en el desarrollo
de software UML presenta ciertos inconvenientes, entre los cuales se pueden
mencionar: Falta integración con respecto de otras técnicas tales como
patrones de diseño, interfaces de usuario, documentación, etc., los ejemplos
aislados, el monopolio de conceptos, técnicas y métodos en torno a UML.
También se prevé varias perspectivas de UML ya que por ser un lenguaje
de propósito general será un lenguaje de modelado orientado a objetos
estándar predominante los próximos años, esto se basa en las siguientes
razones:
 Participación de metodólogos influyentes
 Participación de importantes empresas
 Aceptación del OMG como notación estándar
Se muestran las siguientes evidencias que apoyan lo antedicho:

18
 Herramientas que proveen la notación UML
 “Edición” de libros
 Congresos, cursos, “camisetas”, etc.
Descripción de los diagramas Un modelo captura una vista de un sistema
del mundo real. Es una abstracción de dicho sistema, considerando un cierto
propósito. Así, el modelo describe completamente aquellos aspectos del
sistema que son relevantes al propósito del modelo, y a un apropiado nivel
de detalle. Un diagrama es una representación gráfica de una colección de
elementos de modelado, a menudo dibujada como un grafo con vértices
conectados por arcos
Un proceso de desarrollo de software debe ofrecer un conjunto de
modelos que permitan expresar el producto desde cada una de las
perspectivas de interés. Es aquí donde se hace evidente la importancia de
UML en el contexto de un proceso de desarrollo de software.
El código fuente del sistema es el modelo más detallado del sistema (y
además es ejecutable). Sin embargo, se requieren otros modelos.
Figura Nº 3. Relaciones de enlaces entre modelos
Fuente: http://www.monografias.com/trabajos-pdf5/diagramas-casos-
uso/image001.jpg

19
Cada modelo es completo desde su punto de vista del sistema, sin
embargo, existen relaciones de enlaces entre los diferentes modelos (figura
Nº 3).
Objetivos del lenguaje unificado de modelado.
UML es un lenguaje de modelado que pueden usar todos los modeladores.
No tiene propietario y está basado en el común acuerdo de gran parte de la
comunidad informática.
UML no pretende ser un método de desarrollo completo, pues no incluye
un proceso de desarrollo paso a paso, pero puede manejar todos los
conceptos que se consideran necesarios para utilizar un proceso moderno de
desarrollo, basado en construir una sólida arquitectura para resolver
requisitos dirigidos por casos de uso, por otro lado busca ser tan simple
como sea posible pero manteniendo la capacidad de modelar toda la gama
de sistemas que se necesiten construir. UML necesita ser lo suficientemente
expresivo para manejar todos los conceptos que se originan en un sistema
moderno, tales como la concurrencia y distribución, así como también los
mecanismos de la ingeniería de software como son la encapsulación y
componentes.
Uso del lenguaje unificado de modelado.
UML sirve para hacer modelos que permitan:
a) Visualizar como es un sistema o como de desea.

20
b) Especificar la estructura y/o comportamiento de un sistema.
c) Hacer una plantilla que guíe la construcción de los sistemas
El modelado sirve no solamente para los grandes sistemas; aún en
aplicaciones de pequeño tamaño se obtienen beneficios de modelar, sin
embargo, es un hecho que entre más grande y más complejo es el sistema,
el modelado juega un papel más importante, esto se debe a una razón
simple: se hacen modelos de sistemas complejos porque no se pueden
entender en su totalidad.
El UML es independiente de metodología, por lo que puede ser usada y
lo es en distintas metodología como: Fusion, Objectory, Rational Unified
Process, OMT, ECM, Catalysys, etc. La independencia antes mencionada
permite que las organizaciones adapten el uso de UML a la metodología que
consideren más apropiada.
Fases del ciclo de desarrollo que soporta UML.
Cada diagrama puede ser usado con énfasis distinto en las fase de
desarrollo: análisis, diseño e implementación, un diagrama cualquiera en una
fase de tendrá un estudio lógico, cabe aclarar que aunque UML es orientado
a objetos preferentemente, esto es útil en cualquier modelo tecnológico ya
que es independiente de lenguajes de programación o tecnología
determinada.
Diagramas que ofrece el UML.

21
El UML tiene una notación gráfica muy expresiva que permite
representar en mayor o menor medida todas las fases de un proyecto
informático pasando por el análisis, diseño, implementación y hasta
configuración. Estos gráficos son un conjunto de elementos con sus
relaciones, por otro lado ofrecen una vista del sistema a modelar. Para poder
representar correctamente un sistema UML ofrece una amplia variedad de
diagramas para visualizar el sistema desde varias perspectivas, entre estos
diagramas se tienen los siguientes:
Figura Nº 4 Diagramas del UML que expresan gráficamente un Modelo.
Fuente: elaboración propia, año: 2009.

22
Diagrama de Casos de Usos.
El diagrama de casos de usos representa gráficamente los casos de
uso que tiene un sistema véase figura Nº 5. Se define un caso de uso como
cada interacción supuesta con el sistema a desarrollar donde se representan
los requisitos funcionales. Es decir se está diciendo lo que tiene que hacer un
sistema
Figura Nº 5 Ejemplo de Modelo de Casos de Uso.
Fuente: http: //www.cyta.com.ar/ta0604/v6n4a1.htm, año: 2007
Diagrama de Clase.
Un diagrama de clases sirve para visualizar las relaciones entre las clases
que involucran el sistema, las cuales pueden ser asociativas, de herencia, de
uso y de contenido. Un diagrama de clases está compuesto por los
siguientes elementos:
•Clase: atributos, métodos y visibilidad.

23
• Relaciones: Herencia, Composición, Agregación, Asociación y
Uso.
Clase: Es la unidad básica que encapsula toda la información de un Objeto (un
objeto es una instancia de una clase). A través de ella podemos modelar el entorno
en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).
Relaciones entre Clases: Ahora ya definido el concepto de Clase, es necesario
explicar cómo se pueden interrelacionar dos o más clases (cada uno con
características y objetivos diferentes). Antes es necesario explicar el concepto de
cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el
grado y nivel de dependencia, se anotan en cada extremo de la relación y
éstas pueden ser:
• Uno o muchos: 1...* (1...n)
• 0 o muchos: 0...* (0...n)
• Número fijo: m (m denota el número).
Herencia (Especialización/Generalización): Indica que una subclase hereda
los métodos y atributos especificados por una Súper Clase, por ende la Subclase
además de poseer sus propios métodos y atributos, poseerá las características y
atributos visibles de la Súper Clase (public y protected).
Agregación: Para modelar objetos complejos, n bastan los tipos de datos básicos
que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se
requiere componer objetos que son instancias de clases definidas por el
desarrollador de la aplicación, tenemos dos posibilidades:
• Por Valor: Es un tipo de relación estática, en donde el tiempo de vida
del objeto incluido está condicionado por el tiempo de vida del que lo
incluye. Este tipo de relación es comúnmente llamada Composición

24
(el Objeto base se construye a partir del objeto incluido, es decir, es
"parte/todo").
• Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de
vida del objeto incluido es independiente del que lo incluye. Este tipo
de relación es comúnmente llamada Agregación (el objeto base utiliza
al incluido para su funcionamiento).
Asociación: La relación entre clases conocida como Asociación, permite
asociar objetos que colaboran entre sí. Cabe destacar que no es una relación
fuerte, es decir, el tiempo de vida de un objeto no depende del otro.
Dependencia o Instanciación (uso): Representa un tipo de relación muy
particular, en la que una clase es instanciada (su instanciación es
dependiente de otro objeto/clase). Se denota por una flecha punteada. El
uso más particular de este tipo de relación es para denotar la dependencia
que tiene una clase de otra, como por ejemplo una aplicación gráfica que
instancia una ventana (la creación del Objeto Ventana está condicionado a la
instanciación proveniente desde el objeto Aplicación):

25
Figura Nº 6 Ejemplo de un Diagrama de Clases.
Fuente: http: //es.geocities.com/nacarit_espaa/fase2/t1.html, año: 2007
Diagrama de Colaboración
Un diagrama de colaboración es una forma alternativa al diagrama de
secuencia para mostrar un escenario. Este tipo de diagrama muestra las
interacciones entre objetos y los enlaces entre ellos.
Los diagramas de secuencia proporcionan una forma de ver el
escenario en un orden temporal - qué pasa primero, qué pasa después -, los
clientes entienden fácilmente este tipo de diagramas, por lo que resultan
útiles en las primeras fases de análisis. Por tanto los diagramas de

26
colaboración proporcionan la representación principal de un escenario, ya
que las colaboraciones se organizan entorno a los enlaces de unos objetos
con otros. Este tipo de diagramas se utilizan frecuentemente en la fase de
diseño, véase figura Nº 7 donde se muestra un ejemplo.
Figura Nº 7 Ejemplo de un Diagrama de Colaboración.
Fuente: http: //rtlabnet.wikidot.com/doc: diseno: rcu: editor, año: 2007.
Diagrama de Secuencia
Un diagrama de secuencia es una forma de diagrama de interacción
que muestra los objetos como líneas de vida a lo largo de la página y con sus
interacciones en el tiempo representadas como mensajes dibujados como
flechas desde la línea de vida origen hasta la línea de vida destino. Los
diagramas de secuencia son buenos para mostrar qué objetos se comunican

27
con qué otros objetos y qué mensajes disparan esas comunicaciones. Los
diagramas de secuencia no están pensados para mostrar lógicas de
procedimientos complejos, véase figura Nº 8.
Línea de Vida
Una línea de vida representa un participante individual en un diagrama
de secuencia. Una línea de vida usualmente tiene un rectángulo que
contiene el nombre del objeto. Si el nombre es self entonces eso indica que
la línea de vida representa el clasificador que posee el diagrama de
secuencia.
Algunas veces un diagrama de secuencia tendrá una línea de vida con
un símbolo del elemento actor en la parte superior. Este usualmente sería el
caso si un diagrama de secuencia es contenido por un caso de uso. Los
elementos entidad, control y límite de los diagramas de robustez también
pueden contener líneas de vida.
Mensajes
Los mensajes se muestran como flechas. Los mensajes pueden ser
completos, perdidos o encontrados; síncronos o asíncronos: llamadas o
señales.
Ocurrencia de ejecución
Un rectángulo fino a lo largo de la línea de vida denota la ocurrencia de
ejecución o activación de un foco de control.

28
Mensaje Self
Un mensaje self puede representar una llamada recursiva de una
operación, o un método llamando a otro método perteneciente al mismo
objeto. Este se muestra como cuando crea un foco de control anidado en la
ocurrencia de ejecución de la línea de vida.
Mensajes perdidos y encontrados
Los mensajes perdidos son aquellos que han sido enviados pero que no
han llegado al destino esperado, o que han llegado a un destino que no se
muestra en el diagrama actual. Los mensajes encontrados son aquellos que
llegan de un remitente no conocido, o de un remitente no conocido en el
diagrama actual. Ellos se denotan yendo o llegando desde un elemento de
punto final.
Inicio y final de línea de vida
Una línea de vida se puede crear o destruir durante la escala de tiempo
representada por un diagrama de secuencia. En el último caso, la línea de
vida se termina por un símbolo de detención, representado como una cruz.
En el primer caso, el símbolo al inicio de la línea de vida se muestra en un
nivel más bajo de la página que el símbolo del objeto que causó la creación.
Restricciones de tiempo y duración
En forma predeterminada, un mensaje se muestra como una línea
horizontal. Ya que la línea de vida representa el pasaje de tiempo hacia
abajo, cuando se modela un sistema en tiempo real, o incluso un proceso de

29
negocios en tiempo límite, puede ser importante considerar el tiempo que
toma realizar las acciones.
Al configurar una restricción de duración para un mensaje, el mensaje
se mostrará como una línea inclinada.
Figura Nº 8 Ejemplo de un Diagrama de Secuencia.
Fuente: http: //www.chuidiang.com/ood/metodologia/diagrama_secuencia.php, año: 2007.
Extensión WAE del UML.
Una de las características más relevantes de la notación UML es su
capacidad para absorber nueva semántica sin romper su lógica interna. La
necesidad de implementar complejas arquitecturas con múltiples capas y una
gran dispersión geográfica de nodos, ha supuesto todo un reto al abordar su
modelado y especificación. Jim Conallen ha desarrollado desde 1998 una
extensión de la notación UML denominada WAE “Web Application Extensión”

30
que permite rentabilizar toda la gramática interna de UML para modelar
aplicaciones con elementos específicos de la arquitectura de un entorno
WEB.
La tabla Nº 1, muestra los estereotipos que se utilizan en WAE. Una
página cliente es una unidad de código HTML que es distribuida por el
servidor Web a sus clientes, que son los navegadores Web, los navegadores
interpretan el código y presentan la información que contiene al usuario. Para
obtener una página cliente, el navegador envía al servidor Web la dirección
URL (Uniform Resource Locator) de la página.
Una página servidora, por su parte, es una secuencia de comandos en
algún lenguaje de programación como ser PHP, ASP, JSP, PERL, etc. que
son procesados por el mismo servidor.
Al igual que las páginas cliente la página servidora tienen una URL que
es enviada por el navegador al servidor Web, pero éste, en lugar de distribuir
la página, ejecuta las instrucciones que contiene. Estas instrucciones pueden
ser, por ejemplo, para consultar una base de datos y extraer de ella
información que interesa al usuario del navegador, y terminan generalmente
con la construcción de una página cliente que contiene la información
obtenida, y que es enviada entonces por el servidor Web al navegador para
que se la presente al usuario.
Desde el punto de vista de éste, el servidor Web le envía la página
cliente construida en forma dinámica, en respuesta a la URL de la página
servidora enviada previamente.

31
Tabla Nº 1 Estereotipos Utilizados en la Notación WAE. Estereotipos
para las Clases
Estereotipo Descripción
Server Page
Representa una página Web que tiene scripts
ejecutados por el servidor. Estos scripts
interactúan con los recursos que se
encuentran al alcance del servidor. Sólo puede
mantener relaciones con objetos que se
encuentren en el servidor
Client Page
Representan páginas que son dibujadas por
el navegador web y pueden ser una
combinación de algún o algunos lenguajes de
marcado, scripts del lado del cliente, islas de
datos, etc.
Form
Representa una colección de campos de
entrada que forman parte con una página del
lado cliente (Client Page). Tiene una
correspondencia directa con la etiqueta
<FORM> de XHTML.
ClientScript
Es una colección de scripts del lado del cliente
que existe como un archivo separado y que

32
Object son incluidos mediante una petición
independiente por parte del navegador.
Estereotipos para las Relaciones entre las Clases
Link
Representa un apuntador desde una “client
page” hacia una “client page” o “server page”.
Corresponde directamente con una etiqueta
<a> (ancla) de HTML
Submit
Esta relación siempre se da entre una “form” y
una “server page”, por supuesto, la “server
page” procesa los datos que la “form” le envía
(submits)
Build
Sirve para identificar cuales “server page” son
responsables de la creación de una “client
page”. Una “server page” puede crear varias
“client page”, pero una “client page” sólo
puede ser creada por una sola “server page”.
Esta relación siempre es unidireccional
Redirect
Esta es también una relación unidireccional
que indica que una página Web redirige hacia
otra. En caso de que la página origen sea una
“client page” esta asociación corresponderá
con la “META” etiqueta y valor HTTP-EQUIV
de “Refresh”*.

33
MODELO CLIENTE-SERVIDOR.
La tecnología denominada Cliente/Servidor es utilizada en todas las
aplicaciones de Internet/intranet, un servidor es un ordenador remoto en
algún lugar de la red que proporciona información según la petición véase
figura Nº 9. Un cliente funciona en su computador local que se comunica con
el servidor remoto y pide a éste información. Un servidor típicamente sirve a
una multitud de clientes, ahorrando a cada uno de ellos el problema de tener
la información instalada y almacenada localmente.
Los sistemas Cliente/Servidor pueden ser de muchos tipos,
dependiendo de las aplicaciones que el servidor pone a disposición de los
clientes, entre otros, existen los siguientes:
• Servidor de Impresión: mediante el cual los usuarios imprimen
remotamente.
• Servidor de Archivos: con el cual los clientes comparten y/o
almacenan archivos, a este servicio se le conoce cono Servidor FTP.
• Servidor de Bases de Datos: donde existe uno o varios sistemas de
Base de Datos.
• Servidor de Nombres: el cual convierte las direcciones IP (Protocolo
Internet) en nombres y viceversa también se conoce como Servidor
DNS.
 Servidor Web: el cual sirve páginas Web.
• Servidor de Correo: el cual permite enviar y/o recibir correo
electrónicos mediante un cliente de correo electrónico.

34
Figura Nº 9Modelo Cliente-Servidor en un entorno Web.
Fuente: http://daw-fiec.pbworks.com/f/cliente_servidor2.jpg
PROGRAMACIÓN ORIENTADA A OBJETOS.
El paradigma OO se basa en el concepto de objeto, un objeto es
aquello que tiene estado (propiedades más valores), comportamiento
(acciones y reacciones a mensajes) e identidad (propiedad que lo distingue
de los demás objetos). La estructura y comportamiento de objetos similares
están definidos en una clase común, los términos instancia y objeto son
intercambiables.
Una clase es un conjunto de objetos que comparten una estructura y
comportamiento común, la diferencia entre un objeto y una clase es que un
objeto es una entidad concreta que existe en tiempo y espacio, mientras que
una clase representa una abstracción, la "esencia" de un objeto, tal como
son, de aquí que un objeto no es una clase, sin embargo, una clase puede
ser un objeto.

35
En el enfoque OO las propiedades del objeto son claves, los principios
del modelo OO son:
• Abstracción: Es una descripción simplificada o especificación de un
sistema que enfatiza algunos de los detalles o propiedades del sistema,
mientras suprime otros.
• Encapsulación: Es el proceso de ocultar todos los detalles de un objeto
que no contribuyen a sus características esenciales.
• Modularidad: Es la propiedad de un sistema que ha sido descompuesto
en un conjunto de módulos coherentes e independientes.
• Jerarquía o herencia: Es el orden de las abstracciones organizado por
niveles.
• Tipificación: Es la definición precisa de un objeto de tal forma que
objetos de diferentes tipos no puedan ser intercambiados o cuando
mucho, puedan intercambiarse de manera muy restringida.
• Concurrencia: Es la propiedad que distingue un objeto que está activo
de uno que no lo está.
• Persistencia: Es la propiedad de un objeto a través de la cual su
existencia trasciende el tiempo (es decir, el objeto continua existiendo
después de que su creador ha dejado de existir) y/o el espacio es decir,
la localización del objeto se mueve del espacio de dirección en que fue
creado. Si un modelo que se dice OO no contiene alguno de los
primeros cuatro elementos, entonces no es OO.

36
Los beneficios del enfoque OO.
• El uso del modelo OO ayuda a explotar el poder expresivo de todos los
lenguajes de programación basados en objetos y los orientados a
objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada, y Java.
• El uso del modelo OO alienta el rehúso no solo del software, sino de
diseños completos.
• Produce sistemas que están construidos en formas intermedias estables y
por ello son más resistentes al cambio en especificaciones y tecnología.
SERVIDOR WEB SEGURO.
Existen ocasiones en las que se hace necesario recibir/enviar información
sensible a un Servidor Web, es por ello que se hace imprescindible el contar
con un mecanismo que dé fe de si, un servidor seguro es en quien se cree y
se puede confiar en él a la hora de transmitirle la información. La forma como
se hace es mediante las Autoridades de Certificación (AC), conocidas
informalmente como notarios electrónicos, encargadas de autenticar a los
participantes en transacciones y comunicaciones a través de la red. Su
función es emitir certificados a los usuarios, de manera que se pueda estar
seguro de que el interlocutor (cliente o servidor) es quien pretende ser,
garantizando así la seguridad de las transacciones, véase figura Nº 10.
El certificado de seguridad se concede a una entidad después de
comprobar una serie de referencias, para asegurar la identidad del receptor
de los datos cifrados. Se construye a partir de la clave pública del servidor
solicitante, junto con algunos datos básicos del mismo y es firmado por la

37
autoridad de certificación correspondiente con su clave privada. En la
práctica, se sabe que el servidor es seguro porque en el navegador de
Internet se ve una llave o un candado cerrado en la barra de estado de éste.
Figura Nº 10 Intercambio de Información entre un Navegador Web (cliente) y un Servidor
Web Seguro.
Fuente: http: //neo.lcc.uma.es/evirtual/cdd/tutorial/presentacion/ssl.html, año 2007.
PÁGINAS WEB

38
Una página Web estática incluye un contenido que se muestra del
mismo modo cada vez que se solicita desde un navegador. Un ejemplo de
una página Web estática es una página de servicio al cliente que contiene
información de contacto como por ejemplo: los números de teléfono, los
números de fax y las direcciones de correo electrónico que no suelen
cambiar con frecuencia.
Una página Web estática se crea utilizando sólo HTML lenguaje que
interpretan los navegadores Web. Una página Web estática contiene además
del código HTML, texto, así como otros elementos apropiados para la página
como imágenes y animación, pero no utilizan la información almacenada en
Base de Datos.
El contenido de una página Web dinámica en cambio se genera cuando
el usuario solicita la página. Generalmente el contenido se extrae de una
Base de Datos, lo que permite presentar la información más actual sin volver
a codificar la página Web. Una página Web dinámica actúa como una
plantilla: contiene código para recuperar la información solicitada y dar
formato a la salida.
EL LENGUAJE SQL.
El SQL (Structured Query Language) o Lenguaje de Consultas
Estructurado, es el lenguaje que permite la comunicación con el Sistema
Gestor de Bases de Datos. Es un lenguaje unificado, y lo utilizan todo tipo de
usuarios, desde el administrador de la Base de Datos, hasta el usuario final.
El SQL es un lenguaje no procedimental esto quiere decir que el
usuario especifica Qué quiere, no Cómo ni Dónde conseguirlo. El SQL es

39
relacionalmente completo esto permite la realización de cualquier consulta de
datos.
Las sentencias SQL pertenecen a dos categorías principales: Lenguaje
de Definición de Datos (DDL) y Lenguaje de Manipulación de Datos (DML).
Estos dos lenguajes no son lenguajes en sí mismos, sino que es una forma
de clasificar las sentencias de lenguaje SQL en función de su cometido. La
diferencia principal reside en que el DDL crea objetos en la base de datos y
sus efectos se pueden ver en el diccionario de la base de datos, mientras
que el DML es el que permite consultar, insertar, modificar y eliminar la
información almacenada en los objetos de la base de datos.
El lenguaje SQL está basado en el cálculo relacional de tuplas. Como
resultado, toda consulta formulada utilizando el cálculo relacional de tuplas (o
su equivalente, el álgebra relacional) se pude formular también utilizando
SQL. Hay, sin embargo, capacidades que van más allá del cálculo o del
álgebra relaciona. A continuación se muestra una lista de algunas
características proporcionadas por SQL que no forman parte del álgebra y de
cálculo relacionales:
 Comandos para inserción, borrado o modificación de datos.
 Capacidades aritméticas: En SQL es posible incluir operaciones
aritméticas así como comparaciones, por ejemplo A < B + 3. Nótese
que ni + ni otros operadores aritméticos aparecían en el álgebra
relacional ni en cálculo relacional.
 Asignación y comandos de impresión: es posible imprimir una relación
construida por una consulta y asignar una relación calculada a un
nombre de relación.

40
 Funciones agregadas: Operaciones tales como promedio (average),
suma (sum), máximo (max), etc. se pueden aplicar a las columnas de
una relación para obtener una cantidad única.
LAS BASES DE DATOS
Una base de datos es un conjunto de datos estructurados, en un
soporte de almacenamiento de datos y se puede acceder a ella desde uno o
varios programas. Antes de diseñar una base de datos se debe establecer un
proceso partiendo del mundo real, de manera que sea posible plasmar éste
mediante una serie de datos. La imagen que se obtiene del mundo real se
denomina modelo conceptual y consiste en una serie de elementos que
definen perfectamente lo que se quiere plasmar del mundo real en la base de
datos.
El Sistema Gestor de Bases de Datos (SGBD) es un conjunto de
programas, procedimientos y lenguajes que proporcionan a los usuarios las
herramientas necesarias para operar con una base de datos. Por tanto, el
SGBD actúa como un intermediario entre los usuarios y los datos. Debe
cumplir una serie de funciones como descripción de los datos, de manera
que debe permitir definir los registros, sus campos, sus relaciones de
autorización, etc. Debe manipular los datos permitiendo a los usuarios
insertar, suprimir, modificar y consultar datos de la base de datos y por
último, debe permitir usar la base de datos, dando un interfaz adecuado a
cada tipo de usuario.

41
EL MODELO ENTIDAD-RELACIÓN
Es una técnica de diseño de bases de datos gráfica, que incorpora
información relativa a los datos y la relación existente entre ellos, para poder
así plasmar una visión del mundo real sobre un soporte informático.
Sus características fundamentales son:
1. Reflejan tan sólo la existencia de los datos sin expresar lo que se hace con
ellos.
2. Es independiente de las bases de datos y de los sistemas operativos.
3. Incluye todos los datos que se estudian sin tener en cuenta las
aplicaciones que se van a tratar.
Las entidades se representan como rectángulos, los atributos como
elipses y las relaciones como rombos.
Entidad: Una entidad es un objeto concreto o abstracto que presenta interés
para el sistema y sobre el que se recoge información la cual va a ser
representada en un sistema de base de datos. La mayoría de las entidades
modelan objetos o eventos del mundo real, por ejemplo, clientes, productos o
llamadas de pedidos.
Atributo: Es una unidad básica e indivisible de información acerca de una
entidad o una relación y sirve para identificar y describir a las mismas. Por
ejemplo, si se va a modelar un evento como una llamada al servicio de
asistencia, probablemente se querrá saber quién era el cliente, quién hizo la

42
llamada y cuándo, así como si se resolvió o no el problema. La
determinación de los atributos que hay que incluir en el modelo es un
problema semántico (de significado). Se deben tomar decisiones basadas en
el significado de los datos y en cómo se utilizarán.
Dominio: Un dominio es el conjunto de valores que puede tomar cada uno
de los atributos.
Tabla: Organización de los datos en forma de filas y columnas. Cada fila se
llama tupla, y cada columna dentro de una tupla corresponde al valor de un
atributo para esa tupla.
Relación: Asociación entre entidades. Por ejemplo, un "alumno" "tiene" una
"asignatura".
Tabla relacional: Es una tabla que debe cumplir las siguientes
características:
• Cada fila debe ser única.
• Cada columna debe ser única.
• Los valores de las columnas deben pertenecer al dominio de cada
atributo.
• Debe tener un solo tipo de fila, cuyo formato está definido por el
esquema de la tabla o relación.
• El valor de la columna para cada fila debe ser único.
Clave candidata: Atributo o atributos que pueden distinguir de forma
unívoca una tupla dentro de una tabla. Puede haber varias claves candidatas
para distinguir una misma entidad. Se elegirá como clave candidata aquel
atributo que posea un dominio en el que se tenga valores únicos. Si esto no

43
es posible, entonces se usa como clave candidata la combinación de varios
atributos, de manera que esta combinación sí sea única.
Clave principal: Aquella de las claves candidatas que es designada para
distinguir de forma unívoca una tupla dentro de una tabla.
Clave ajena: Se trata de un atributo que es clave principal en otra tabla.
Vista: Una vista es una tabla ficticia cuya definición y tuplas se obtiene a
partir de una o más tablas base. Sus características son:
1. Sus columnas se obtienen a partir de varias tablas base.
2. Pueden estar definidas a partir de otras vistas.
3. Sus datos se obtienen como resultado de una consulta a la base de
datos.
4. Se puede almacenar su estructura.
Se trata de una tabla virtual que no existe como tabla en el disco.
Inconsistencia: Se da cuando se encuentra un valor en una clave ajena no
existente en la entidad donde ésta sea clave principal.
Asociaciones entre entidades
Asociaciones uno-a-uno: Si es cierto que cualquier ejemplar de la entidad
X se puede asociar con tan sólo un ejemplar de la entidad Y, entonces se
dice que la asociación es uno-a-uno. Cuando se elige una asociación uno-a-
uno se debe asegurar de que se mantenga la asociación en todo momento.

44
Asociaciones uno-a-muchos: Es el tipo de asociación más común, donde
un solo ejemplar de una entidad se puede asociar con cero, uno o muchos
ejemplares de otra entidad. Por ejemplo, una persona puede tener varios
números de teléfono.
Asociaciones muchos-a-muchos: Los clientes compran en muchas
tiendas, una tienda tiene muchos clientes. Como este tipo de relaciones no
se puede modelar directamente en una base de datos relacional, se modela
usando una tabla intermedia que tenga una asociación uno-a-muchos con
cada uno de los participantes originales. Por ejemplo, un pedido puede tener
muchos tipos de confección, y un tipo de confección puede aparecer en
varios pedidos.
Normalización
La normalización se encarga de obtener los datos agrupados en
distintas tablas siguiendo una serie de pasos, de tal manera que los datos
obtenidos tienen una estructura óptima para su implementación, gestión y
explotación desde distintas aplicaciones futuras. Una de las ventajas
principales que se obtiene al realizar la normalización es que la información
no estará duplicada innecesariamente dentro de las estructuras: habrá
mínima redundancia.
Dependencia funcional.
Se dice que un atributo B depende funcionalmente de A (A -> B) si cada
valor de A se corresponde con un único valor de B o, visto de otra manera, si
dado A se puede obtener B. Un caso típico podría ser DNI -> Nombre, pues
dado un DNI se puede obtener el nombre de la persona con ese DNI. Existen
reglas que se pueden realizar entre atributos para poder obtener

45
dependencias funcionales adicionalmente. Supóngase que T es una tabla
relacional y X, Y, Z son subconjuntos de atributos de la tabla T.
Reflexividad: Si los valores de un subconjunto de atributos Y están
incluidos dentro de un subconjunto de atributos X, se dice que X depende
funcionalmente de Y (Y -> X).
Aumentación: Si un subconjunto X depende funcionalmente de otro Y,
dicha dependencia se mantendrá aunque se añada otro atributo a los dos
subconjuntos (X -> Y entonces X.a ->Y.a).
Transitividad: Si Y depende funcionalmente de X y Z depende
funcionalmente de Y, entonces Z depende funcionalmente de X (X -> Y e Y -
> Z entonces X -> Z). Por ejemplo, DNI -> NOMBRE y NOMBRE ->
DIRECCIÓN, luego DNI -> DIRECCIÓN.
Dependencia funcional total: Un atributo Y tiene una dependencia
funcional total con otro atributo X si tiene una dependencia funcional con X y
no depende funcionalmente de ningún subconjunto de X. Por ejemplo,
supóngase que una empresa tiene empleados y que una persona puede ser
empleado de varias empresas. Según esto, se podría decir que
DNI.EMPRESA -> NOMBRE, pero esta dependencia no es total porque
también es cierto que DNI -> NOMBRE. Sin embargo, no se puede identificar
el sueldo de un empleado sin saber a qué empresa pertenece, por lo tanto,
DNI.EMPRESA -> SUELDO sí es una dependencia funcional total.

46
Primera Forma Normal (1FN).
Se dice que una tabla está en primera forma normal si todos los valores
que componen a sus tuplas son atómicos: un atributo no puede tener más de
un valor. Para normalizar una tabla que no esté en 1FN han de seguirse los
siguientes pasos:
• Se localizan los atributos correspondientes a la clave principal
• Se realiza una proyección sobre la tabla y así se descompone en
varias, de manera que se hace la proyección de la clave con los
atributos que tengan los valores únicos.
Por ejemplo, la figura Nº 11 muestra una tabla que no está en 1FN:
Figura Nº 11Tabla en Primera Forma Normal.
Fuente:http://www.formauri.es/arrobamasmas/Cursos/index.php?apdo=05&curso=51&cap=4
, año: 2009.
Segunda Forma Normal (2FN).
Esta forma normal se considerará únicamente cuando la clave principal
sea compuesta, si no (la clave principal está formada por un único atributo) la
tabla estaría en segunda forma normal. Se dice que una tabla está en
segunda forma normal si se cumplen las siguientes condiciones:
• Está en 1FN.

47
• Todo atributo secundario (los que no pertenecen a la clave principal)
tiene una dependencia funcional total de la clave completa y no de una
parte de ella.
Para convertir una tabla que no esté en 2FN a 2FN se creará una tabla
con la clave y todas sus dependencias funcionales totales y otra tabla con la
parte de la clave que tiene dependencias con los atributos secundarios.
Por ejemplo, la figura Nº 12 muestra una tabla que no está en 2FN:
Figura Nº 12Tabla que no está en 2FN.
, año: 2009.
Ya que el campo "TeléfonoProveedor" no es dependiente de la clave
candidata {"NombreProducto, "NombreProveedor"} sino únicamente de
"NombreProveedor". Se trata de no representar dos entidades distintas en
una sola tabla.
En este ejemplo, se reorganizan los datos de la siguiente manera:

48
Tabla Productos:
Figura Nº 13Tabla Productos
, año: 2009.
Tabla Proveedores:
Figura Nº 14Tabla Proveedores.
, año: 2009.
Tercera Forma Normal (3FN).
Una tabla está en 3FN si:
• Está en 2FN
• No existen atributos no primarios (no pertenecen a la clave) que son
transitivamente dependientes de cada posible clave de la tabla, o lo que
es lo mismo, un atributo secundario sólo puede ser conocido a través

49
de la clave principal o claves secundarias de la tabla y no por medio de
otro atributo no primario.
Para convertir una tabla a 3FN se realizará una proyección de la clave a
los elementos que no tengan dependencia funcional transitiva y otra tabla
con una nueva clave a los elementos que anteriormente tenían esta
dependencia.
Por ejemplo, la siguiente tabla no está en 3FN:
Tabla Atletas:
Figura Nº 15 Tabla Atletas.
, año: 2009.
Ya que, dado un número de licencia, se puede obtener la edad del
inscrito, y dada la edad del inscrito, se puede averiguar la categoría a la que
pertenece: teniendo entonces una dependencia funcional transitiva.
Evidentemente, dado el número de licencia se puede averiguar la categoría
pero lo importante aquí es que la categoría depende de un atributo que no
forma parte de la clave. Para normalizar, se descompone la tabla en las
siguientes:

50
Figura Nº 16Tabla Atletas parte 1.
, año: 2009.
Figura Nº 17Tabla Atletas parte2.
, año: 2009.
LENGUAJE DE PROGRAMACIÓN PHP.
PHP es un lenguaje de programación interpretado, diseñado
originalmente para la creación de páginas dinámicas. Es usado
principalmente en interpretación del lado del servidor (server-side scripting)
pero actualmente puede ser utilizado desde una interfaz de línea de
comandos o en la creación de otros tipos de programas incluyendo
aplicaciones con interfaz gráfica usando las bibliotecas Qt o GTK+.
PHP es un acrónimo recursivo que significa PHP Hypertext Pre-processor
(inicialmente PHP Tools, o, Personal Home Page Tools). Fue creado
originalmente por Rasmus Lerdof en 1994; sin embargo la implementación

51
principal de PHP es producida ahora por The PHP Group y sirve como el
estándar de facto para PHP al no haber una especificación formal. Publicado
bajo la PHP License, la Free Software Foundation considera esta licencia
como software libre.
Ventajas del lenguaje PHP.
• Es un lenguaje multiplataforma.
• Capacidad de conexión con la mayoría de los manejadores de base de
datos que se utilizan en la actualidad, destaca su conectividad con
MySQL
• Capacidad de expandir su potencial utilizando la enorme cantidad de
módulos (llamados ext's o extensiones).
• Posee una amplia documentación en su página oficial ([2]), entre la cual
se destaca que todas las funciones del sistema están explicadas y
ejemplificadas en un único archivo de ayuda.
• Es libre, por lo que se presenta como una alternativa de fácil acceso
para todos.
• Permite las técnicas de Programación Orientada a Objetos.
• Biblioteca nativa de funciones sumamente amplia e incluida.
• No requiere definición de tipos de variables.
• Tiene manejo de excepciones (desde php5).

52
Desventajas del Lenguaje PHP.
Si bien PHP no obliga a quien lo usa a seguir una determinada
metodología a la hora de programar (muchos otros lenguajes tampoco lo
hacen), aun estando dirigido a alguna en particular, el programador puede
aplicar en su trabajo cualquier técnica de programación y/o desarrollo que le
permita escribir código ordenado, estructurado y manejable.
Un ejemplo de esto son los desarrollos que en PHP se han hecho del
patrón de diseño Modelo Vista Controlador (o MVC), que permiten separar el
tratamiento y acceso a los datos, la lógica de control y la interfaz de usuario
en tres componentes independientes (ver más abajo Frameworks en PHP).
COMMON GATEWAY INTERFACE (CGI).
El CGI (Por sus siglas en inglés "Common Gateway Interface") cambio
la forma de manipular información en el Web. En sí, es un método para la
transmisión de información hacia un compilador instalado en el servidor. Su
función principal es la de añadir una mayor interacción a los documentos
Web que por medio del HTML se presentan de forma estática.
El CGI es utilizado comúnmente para contadores, bases de datos,
motores de búsqueda, formularios, generadores de email automático, foros
de discusión, chats, comercio electrónico, rotadores y mapas de imágenes,
juegos en línea y otros. Esta tecnología tiene la ventaja de correr en el
servidor cuando el usuario lo solicita por lo que es dependiente del servidor y
no de la computadora del usuario.

53
De acuerdo a la traducción de la NCSA: "Un documento HTML es
estático, lo que significa que existe en un estado constante; es un archivo de
texto que no cambia. Un script CGI por otro lado, es ejecutado en tiempo
real, lo que permite que regrese información dinámica”. Por ejemplo, si se
desea conectar las bases de datos de Unix al World Wide Web para permitir
que las personas de todo el mundo la manipulen básicamente, lo se debe
hacer es crear un script CGI que será ejecutado por el servidor para
transmitir información al motor de la base de datos, recibir los resultados y
mostrárselos al cliente. Los programas que maneja el CGI pueden estar
compilados en diferentes lenguajes de programación.
El más popular para el desarrollo de contenidos Web es el lenguaje Perl
de distribución gratuita, aunque también podemos mencionar: C, C++ y Java.
El funcionamiento de esta tecnología es muy sencillo. Los scripts residen en
el servidor, donde son llamados, ejecutados y regresa información de vuelta
al usuario.
SECURE SOCKET LAYER (SSL).
El protocolo SSL es un sistema diseñado y propuesto por Netscape
Communications Corporation. Este se encuentra en la pila OSI entre los
niveles de TCP/IP y de los protocolos HTTP, FTP, SMTP, etc. Proporciona
sus servicios de seguridad cifrando los datos intercambiados entre el servidor
y el cliente con un algoritmo de cifrado simétrico, típicamente el RC4 o IDEA,
y cifrando la clave de sesión de RC4 o IDEA mediante un algoritmo de
cifrado de clave pública, típicamente el RSA. La clave de sesión es la que se
utiliza para cifrar los datos que vienen y van al servidor seguro. Se genera
una clave de sesión distinta para cada transacción, lo cual permite que

54
aunque sea reventada por un atacante en una transacción dada, no sirva
para descifrar futuras transacciones (véase figura Nº 18). El MD5 se usa
como algoritmo de hash.
El SSL proporciona cifrado de datos, autenticación de servidores,
integridad de mensajes y opcionalmente autenticación de cliente para
conexiones TCP/IP. Cuando el cliente pide al servidor seguro una
comunicación segura, el servidor abre un puerto cifrado, gestionado por un
software llamado Protocolo SSL Record, situado encima de TCP. Será el
software de alto nivel, Protocolo SSL Handshake, quien utilice el Protocolo
SSL Record y el puerto abierto para comunicarse de forma segura con el
cliente.
Figura Nº 18Transacción usando Cifrado SSL.
Fuente: http: //www.enelnombredetux.com/project.php?project=pgp, año:2008.
El Protocolo SSL Handshake.
Durante el protocolo SSL Handshake, el cliente y el servidor intercambian
una serie de mensajes para negociar las mejoras de seguridad. Este
protocolo sigue las siguientes seis fases:

55
• La fase “hola”, usada para ponerse de acuerdo sobre el conjunto de
algoritmos para mantener la intimidad y para la autenticación.
• La fase de intercambio de claves, en la que intercambia información
sobre las claves, de modo que al final ambas partes comparten una
clave maestra.
• La fase de producción de clave de sesión, que será la usada para cifrar
los datos intercambiados.
• La fase de verificación del servidor, presente sólo cuando se usa RSA
como algoritmo de intercambio de claves, y sirve para que el cliente
autentique al servidor.
• La fase de autenticación del cliente, en la que el servidor solicita al
cliente un certificado X.509 (si es necesaria la autenticación de cliente).
• Por último, la fase de fin, que indica que ya se puede comenzar la
sesión segura.
Protocolo SSL Record.
El Protocolo SSL Record especifica la forma de encapsular los datos
transmitidos y recibidos. La porción de datos del protocolo tiene tres
componentes:
• MAC-DATA, el código de autenticación del mensaje.
• ACTUAL-DATA, los datos de aplicación a transmitir.
• PADDING-DATA, los datos requeridos para rellenar el mensaje
cuando se usa cifrado en bloque.

56
Cómo saber si una Conexión se está Realizando Mediante SSL.
Los navegadores Web disponen de un icono que lo indica, generalmente
un candado en la parte inferior de la ventana, véase figura Nº 19. Si el
candado está abierto se trata de una conexión normal, y si está cerrado de
una conexión segura. Si hace “doble click” sobre el candado cerrado
aparecerá el Certificado Digital del Servidor Web Seguro.
Figura Nº 19Indicación de una Conexión Segura en Navegadores Web.
Fuente:http://www.microsoft.com/spain/protect/yourself/phishing/spoof.mspx, año:2009
OpenSSL.
El software OpenSSL es un proyecto de software desarrollado por lo
miembros de la comunidad Open Source (código abierto). Es un robusto
juego de herramientas que le ayudan a su sistema a implementar el Secure
Sockets Layer (SSL), así como otros protocolos relacionados con la
seguridad, tales como el Transport Layer Security (TLS). También incluye
una librería de criptografía.

57
SISTEMA OPERATIVO GNU/LINUX
GNU/Linux es un Sistema Operativo, es una implementación de libre
distribución UNIX para computadoras personales (PC), servidores, y
estaciones de trabajo. Fue desarrollado para el i386 y ahora soporta los
procesadores i486, Pentium, Pentium Pro y Pentium II, así como los clones
AMD y Cyrix. También soporta máquinas basadas en SPARC, DEC Alpha,
PowerPC/PowerMac, y Mac/Amiga Motorola 680x0.
Como sistema operativo, GNU/Linux es muy eficiente y tiene un excelente
diseño. Es multitarea, multiusuario, multiplataforma y multiprocesador; en las
plataformas Intel corre en modo protegido; protege la memoria para que un
programa no pueda hacer caer al resto del sistema; carga sólo las partes de
un programa que se usan; comparte la memoria entre programas
aumentando la velocidad y disminuyendo el uso de memoria; usa un sistema
de memoria virtual por páginas; utiliza toda la memoria libre para cache;
permite usar bibliotecas enlazadas tanto estática como dinámicamente; se
distribuye con código fuente; usa hasta 64 consolas virtuales; tiene un
sistema de archivos avanzado pero puede usar los de los otros sistemas; y
soporta redes tanto en TCP/IP como en otros protocolos.
GNU/Linux es una muy buena alternativa frente a los demás sistemas
operativos. Más allá de las ventajas evidentes de costo, ofrece algunas
características muy notables.
En comparación con las otras versiones de Unix para PC, la velocidad y
confiabilidad de GNU/Linux son muy superiores. También está en ventaja

58
sobre la disponibilidad de aplicaciones, ya que no hay mucha difusión de
estos otros Unixes (como Solaris, XENIX o SCO) entre los usuarios de PC
por sus altos costos.
Comparado con sistemas operativos como Microsoft Windows,
GNU/Linux también sale ganando. Los bajos requisitos de hardware permiten
hacer un sistema potente y útil de aquel 486 que algunos guardan en un
armario. Esta misma característica permite aprovechar al máximo las
capacidades de las computadoras más modernas. Es poco práctico tener
una PC con 16 Mb de RAM y ponerle un sistema operativo que ocupa 13
(que es lo que reporta sobre Windows 95 el System Information de
Symantec).
No solo es superior respecto al sistema de multitarea y de administración
de memoria, sino también en la capacidades de networking (conectividad a
redes) y de multiusuario (aun comparando con sistemas multiusuario como
NT). La única desventaja de GNU/Linux frente a estos sistemas, es la menor
disponibilidad de software, pero este problema disminuye con cada nuevo
programa que se escribe para el proyecto GNU, y con algunas empresas que
están desarrollando software comercial para GNU/Linux.

59
CAPÍTULO III
MARCO METODOLÓGICO
En la actualidad, la utilización de metodologías para el desarrollo de
aplicaciones no se pueden descartadas, debido a la necesidad de control de
variables que conlleva el mismo desarrollo, y para la ordenada elaboración
de las aplicaciones, por lo tanto, seguir metodologías y estándares nos llevan
a estar en competitividad en todo momento.
Es de suma importancia conocer el modo como se interrelacionan
metodologías con estándares y herramientas siguiendo un único propósito, el
cual consiste en la elaboración de aplicaciones de manera eficiente,
ordenada y con el menor número de defectos.
Las siglas RUP en ingles significa Rational Unified Process (Proceso
Unificado Racional) es un producto del proceso de ingeniería de software
que proporciona un enfoque disciplinado para asignar tareas y
responsabilidades dentro de una organización del desarrollo. Su meta es
asegurar la producción del software de alta calidad que resuelve las
necesidades de los usuarios dentro de un presupuesto y tiempo

60
establecidos. La metodología RUP nos proporciona disciplinas en las cuales
se encuentran artefactos con lo cual se podrá contar con guías para poder
documentar e implementar de una manera fácil y eficiente, todas las guías
para un buen desarrollo, todo esto dentro de las respectivas fases con las
cuales cuenta.
Según Jacobson, I., Booch, G., Rumbaugh J. (1998) El nombre Proceso
Unificado se usa para describir el proceso genérico que incluye aquellos
elementos que son comunes a la mayoría de los refinamientos existentes.
También permite evitar problemas legales ya que Proceso Unificado Racional
o RUP son marcas registradas por IBM (desde su compra de Rational
Software Corporation en 2003).
Según Grady Booch (2000) un reflejo de lo que hemos visto en el trabajo
con literalmente decenas de miles de proyectos en los últimos 20 años, la
codificación de lo que funciona en las organizaciones exitosas y lo que está
notablemente ausente en los fallidos.
La Figura Nº 20 ilustra la historia de RUP. El antecedente más importante
se ubica en 1967 con la Metodología Ericsson (Ericsson Approach)
elaborada por Ivar Jacobson, una aproximación de desarrollo basada en
componentes, que introdujo el concepto de Caso de Uso. Entre los años de
1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el proceso
de desarrollo Objectory (abreviación de Object Factory).

61
Figura Nº 20: Historia de RUP
Fuente: http://2.bp.blogspot.com/-CiLFgoBq_GM/TdxjrUWtAaI/AAAAAAAAACk/ksc4zv-
Ek6Y/s1600/FIGURA+1.jpg
Posteriormente en 1995 Rational Software Corporation adquiere
Objectory AB y entre1995 y 1997 se desarrolla Rational Objectory Process
(ROP) a partir de Objectory 3.8 y del Enfoque Rational (Rational Approach)
adoptando UML como lenguaje de modelado.
Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y
James Rumbaugh, Rational Software desarrolló e incorporó diversos
elementos para expandir RUP, destacándose especialmente el flujo de
trabajo conocido como modelado del negocio. En junio del 1998 se lanza
Rational Unified Process.
DIMENSIONES DEL RUP
El RUP tiene dos dimensiones:

62
a) El eje horizontal representa tiempo y demuestra los aspectos del
ciclo de vida del proceso.
b) El eje vertical representa las disciplinas, que agrupan actividades
definidas lógicamente por la naturaleza.
La primera dimensión representa el aspecto dinámico del proceso y se
expresa en términos de fases, de iteraciones, y la finalización de las fases.
La segunda dimensión representa el aspecto estático del proceso: cómo
se describe en términos de componentes de proceso, las disciplinas, las
actividades, los flujos de trabajo, los artefactos, y los roles.
En la figura Nº 21 se puede observar como varía el énfasis de cada
disciplina en un cierto plazo en el tiempo, y durante cada una de las fases.
Por ejemplo, en iteraciones tempranas, pasamos más tiempo en
requerimientos, y en las últimas iteraciones pasamos más tiempo en poner
en práctica la realización del proyecto en sí.

63
Figura Nº 21. Disciplinas, fases, iteraciones del RUP
Fuente: http://www.monografias.com/trabajos82/aplicacion-tecnologia-
j2ee/image011.png
Se puede hacer mención de las tres características esenciales que
definen al RUP:
Características esenciales
Los autores de RUP destacan que el proceso de software propuesto por
RUP tiene tres características esenciales: está dirigido por los Casos de Uso,
está centrado en la arquitectura, y es iterativo e incremental.
Proceso dirigido por Casos de Uso

64
Según Kruchten, P. (2000), los Casos de Uso son una técnica de captura
de requisitos que fuerza a pensar en términos de importancia para el usuario
y no sólo en términos de funciones que sería bueno contemplar.
Se define un Caso de Uso como un fragmento de funcionalidad del
sistema que proporciona al usuario un valor añadido. Los Casos de Uso
representan los requisitos funcionales del sistema.
En RUP los Casos de Uso no son sólo una herramienta para
especificarlos requisitos del sistema. También guían su diseño,
implementación y prueba. Los Casos de Uso constituyen un elemento
integrador y una guía del trabajo como se muestra en la Figura Nº 22.
Figura Nº 22: Los Casos de Uso integran el trabajo
Fuente: http://4.bp.blogspot.com/-
DhDJJXg9Y_s/TdxkLmOd5CI/AAAAAAAAACo/39SGhuPI1Cg/s1600/FIGURA+2.jpg
Los Casos de Uso no sólo inician el proceso de desarrollo sino que
proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los

65
artefactos que son generados en las diferentes actividades del proceso de
desarrollo. Como se muestra en la Figura Nº 23, basándose en los Casos de
Uso se crean los modelos de análisis y diseño, luego la implementación que
los lleva a cabo, y se verifica que efectivamente el producto implemente
adecuadamente cada Caso de Uso. Todos los modelos deben estar
sincronizados con el modelo de Casos de Uso.
Figura Nº 23: Trazabilidad a partir de los Casos de Uso
Fuente: http://www.magis.com.co/images/Paquete-Exito_clip_image004.jpg
Proceso centrado en la arquitectura
La arquitectura de un sistema es la organización o estructura de sus
partes más relevantes, lo que permite tener una visión común entre todos los
involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema
completo, necesaria para controlar el desarrollo. La arquitectura involucra los
aspectos estáticos y dinámicos más significativos del sistema, está
relacionada con la toma de decisiones que indican cómo tiene que ser

66
construido el sistema y ayuda a determinar en qué orden. Además la
definición de la arquitectura debe tomar en consideración elementos de
calidad del sistema, rendimiento, reutilización y capacidad de evolución por lo
que debe ser flexible durante todo el proceso de desarrollo. La arquitectura
se ve influenciada por la plataforma software, sistema operativo, gestor de
bases de datos, protocolos, consideraciones de desarrollo como sistemas
heredados. Muchas de estas restricciones constituyen requisitos no
funcionales del sistema.
En el caso de RUP además de utilizar los Casos de Uso para guiar el
proceso se presta especial atención al establecimiento temprano de una
buena arquitectura que no se vea fuertemente impactada ante cambios
posteriores durante la construcción y el mantenimiento. Cada producto tiene
tanto una función como una forma. La función corresponde a la funcionalidad
reflejada en los Casos de Uso y la forma la proporciona la arquitectura.
Existe una interacción entre los Casos de Uso y la arquitectura, los Casos de
Uso deben encajar en la arquitectura cuando se llevan a cabo y la
arquitectura debe permitir el desarrollo de todos los Casos de Uso
requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura
como Casos de Uso deban evolucionar en paralelo durante todo el proceso
de desarrollo de software.
En la Figura Nº 24 se ilustra la evolución de la arquitectura durante las
fases de RUP. Se tiene una arquitectura más robusta en las fases finales del
proyecto. En las fases iníciales lo que se hace es ir consolidando la
arquitectura por medio de baselines y se va modificando dependiendo delas
necesidades del proyecto.

67
Figura Nº 24: Evolución de la arquitectura del sistema
Fuente: http://www.scielo.cl/fbpe/img/formuniv/v6n2/art02-f3.jpg
Es conveniente ver el sistema desde diferentes perspectivas para
comprender mejor el diseño por lo que la arquitectura se representa
mediante varias vistas que se centran en aspectos concretos del sistema,
abstrayéndose de los demás. Para RUP, todas las vistas juntas forman el
llamado modelo 4+1 de la arquitectura según Kruchten, P. (1986), el cual
recibe este nombre porque lo forman las vistas lógica, de implementación, de
proceso y de despliegue, más la de Casos de Uso que es la que da cohesión
a todas.

68
Figura Nº 25: Los modelos se completan, la arquitectura no cambia drásticamente
Fuente: http://nomada.blogs.com/.a/6a00d8341c564953ef017d3d99ec7d970c-pi
Al final de la fase de elaboración se obtiene una baseline de la
arquitectura donde fueron seleccionados una serie de Casos de Uso
arquitectónicamente relevantes (aquellos que ayudan a mitigar los riesgos
más importantes, aquellos que son los más importantes para el usuario y
aquellos que cubran las funcionalidades significativas) Como se observa en
la Figura Nº 25, durante la construcción los diversos modelos van
desarrollándose hasta completarse (según se muestra con las formas
rellenas en la esquina superior derecha). La descripción de la arquitectura sin
embargo, no debería cambiar significativamente (abajo a la derecha) debido
a que la mayor parte de la arquitectura se decidió durante la elaboración. Se
incorporan pocos cambios a la arquitectura (indicados con mayor densidad
de puntos en la figura inferior derecha).

69
Proceso iterativo e incremental
Jacobson, I., Booch, G., Rumbaugh J. (2000), el equilibrio correcto entre
los Casos de Uso y la arquitectura es algo muy parecido al equilibrio de la
forma y la función en el desarrollo del producto, lo cual se consigue con el
tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso
iterativo e incremental en donde el trabajo se divide en partes más pequeñas
o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y
arquitectura se vaya logrando durante cada mini proyecto, así durante todo el
proceso de desarrollo. Cada mini proyecto se puede ver como una iteración
(un recorrido más o menos completo a lo largo de todos los flujos de trabajo
fundamentales) del cual se obtiene un incremento que produce un
crecimiento en el producto.
Una iteración puede realizarse por medio de una cascada como se
muestra en la Figura Nº 26. Se pasa por los flujos fundamentales (Requisitos,
Análisis, Diseño, Implementación y Pruebas), también existe una
planificación de la iteración, un análisis de la iteración y algunas actividades
específicas dela iteración. Al finalizar se realiza una integración de los
resultados con lo obtenido de las iteraciones anteriores.

70
Figura Nº 26: Una iteración RUP
Fuente: http://cocolito.comoj.com/fase.png
El proceso iterativo e incremental consta de una secuencia de iteraciones.
Cada iteración aborda una parte de la funcionalidad total, pasando por
todos los flujos de trabajo relevantes y refinando la arquitectura. Cada
iteración se analiza cuando termina. Se puede determinar si han aparecido
nuevos requisitos o han cambiado los existentes, afectando alas iteraciones
siguientes. Durante la planificación de los detalles de la siguiente iteración, el
equipo también examina cómo afectarán los riesgos que aún quedan al
trabajo en curso. Toda la retroalimentación de la iteración pasada permite
reajustar los objetivos para las siguientes iteraciones. Se continúa con esta
dinámica hasta que se haya finalizado por completo con la versión actual del
producto.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan
varias iteraciones en número variable según el proyecto y en las que se hace

71
un mayor o menor hincapié en los distintas actividades. En la Figura Nº 27 se
muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la
que se encuentre el proyecto RUP.
Figura Nº 27: Ciclo de vida
Fuente: http://3.bp.blogspot.com/_HU3B-2ZsU-
c/TPVxMke0MDI/AAAAAAAAAAM/PSHqGkC41lY/s400/Ciclo+de+vida.jpg
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan
hacia la comprensión del problema y la tecnología, la delimitación del ámbito
del proyecto, la eliminación de los riesgos críticos, y al establecimiento de
una baseline (línea de base)de la arquitectura.
Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en
actividades modelado del negocio y de requisitos. En la fase de elaboración,

72
las iteraciones se orientan al desarrollo de la baseline de la arquitectura,
abarcan más los flujos de trabajo de requerimientos, modelo de negocios
(refinamiento), análisis, diseño y una parte de implementación orientado a la
baseline de la arquitectura. En la fase deconstrucción, se lleva a cabo la
construcción del producto por medio de una serie de iteraciones.
Para cada iteración se selecciona algunos Casos de Uso, se refina su
análisis y diseño y se procede a su implementación y pruebas. Se realiza una
pequeña cascada para cada ciclo. Se realizan tantas iteraciones hasta que
se termine la implementación de la nueva versión del producto. En la fase de
transición se pretende garantizar que se tiene un producto preparado para su
entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas,
pero que dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

73
Figura Nº 28. Fases del RUP
Fuente: http://upload.wikimedia.org/wikipedia/commons/4/4d/Rup_espanol.gif
FASES
El ciclo de vida del software del RUP se descompone en cuatro fases
secuenciales (figura Nº 28). En cada extremo de una fase se realiza una
evaluación (actividad: Revisión del ciclo de vida de la finalización de fase)
para determinar si los objetivos de la fase se han cumplido. Una evaluación
satisfactoria permite que el proyecto se mueva a la próxima fase.
Planeando las fases

74
El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales
produce una nueva versión del producto, cada ciclo está compuesto por
fases y cada una de estas fases está compuesta por un número de
iteraciones, estas fases son:
Concepción, Inicio o Estudio de oportunidad
Define el ámbito y objetivos del proyecto Se define la
funcionalidad y capacidades del producto.
Elaboración
Tanto la funcionalidad como el dominio del problema se
estudian en profundidad Se define una arquitectura básica Se planifica
el proyecto considerando recursos disponibles.
Construcción
El producto se desarrolla a través de iteraciones donde cada
iteración involucra tareas de análisis, diseño e implementación Las
fases de estudio y análisis sólo dieron una arquitectura básica que es
aquí refinada de manera incremental conforme se construye (se
permiten cambios en la estructura) Gran parte del trabajo es
programación y pruebas Se documenta tanto el sistema construido
como el manejo del mismo Estafase proporciona un producto
construido junto con la documentación.
Transición
Se libera el producto y se entrega al usuario para un uso real
Se incluyen tareas de marketing, empaquetado atractivo,
instalación, configuración, entrenamiento, soporte,
mantenimiento, etc.

75
Los manuales de usuario se completan y refinan con la información
anterior Estas tareas se realizan también en iteraciones
Todas las fases no son idénticas en términos de tiempo y esfuerzo.
Aunque esto varía considerablemente dependiendo del proyecto, un ciclo
de desarrollo inicial típico para un proyecto de tamaño mediano debe
anticipar la distribución siguiente el esfuerzo y horario:
Tabla Nº 2. Esfuerzo-horario contra fases del RUP
Lo cual se puede representar gráficamente como se muestra en la figura
Nº 29:

76
Figura Nº 29. Recursos utilizados en las fases del RUP en el tiempo.
Fuente:
http://procesosdesoftware.wikispaces.com/file/view/imgrup2.jpg/141480239/imgrup2.jp
g
El modelo cascada según Winston Royce (1970), es un secuencial
modelo del desarrollo del software (un proceso para la creación del software)
en que el desarrollo se considera como fluyendo constantemente hacia abajo
(como a cascada) con las fases de análisis de requisitos, diseño, puesta en
práctica, prueba (validación), integración, y mantenimiento.
Las fases de concepción y elaboración serían considerablemente más
pequeñas.
Algunas herramientas que pueden automatizar una cierta porción del
esfuerzo dela fase de construcción pueden atenuar esto, haciendo que la
fase deconstrucción sea mucho más pequeña que las fases de concepción y
elaboración juntas. Este es precisamente el objetivo del trabajo. Cada paso
con las cuatro fases produce una generación del software. A menos que el
producto "muera", se desarrollará nuevamente repitiendo la misma secuencia

77
las fases de concepción, elaboración, construcción y transición, pero con
diversos énfasis cada fase.
Estos ciclos subsecuentes se llaman los ciclos de la evolución. Mientras
que el producto pasa durante varios ciclos, se producen las nuevas
generaciones. En la figura Nº 30 se muestre este ciclo evolutivo.
Figura Nº 30. Ciclo evolutivo en la elaboración de software basado en el RUP
Fuente: http://inf162scontroldepensiones.files.wordpress.com/2011/09/rup4.jpg
Los ciclos evolutivos pueden ser iniciados por las mejoras sugeridas por
el usuario, cambios en el contexto del usuario, cambios en la tecnología
subyacente, reacción a la competición, etcétera. Los ciclos evolutivos tienen
típicamente fases de concepción y elaboración mucho más cortas, puesto
que la definición y la arquitectura básicas del producto son determinadas por
los ciclos de desarrollo anteriores. Las excepciones a esta regla son los
ciclos evolutivos en los cuales ocurre o surge un producto significativo o una
redefinición arquitectónica.
Esfuerzo respecto de los flujos de trabajo

78
En la figura Nº 31 se muestran ciertos porcentajes, de forma vertical se
muestra el esfuerzo que se tiene que realizar por cada una delas disciplinas
o flujos de trabajo, y los dos porcentajes que se muestran de forma horizontal
son para todo el proyecto.
Explicando más puntualmente la figura Nº 31 se puede observar que
para la obtención de requerimientos o requisitos en la fase de concepción se
empiezan a obtener, en la fase de elaboración tiene su auge y va declinando
en la fase de construcción, realizar todo esto requiere aproximadamente un
15% de esfuerzo, y así sucesivamente con las demás disciplinas. En esta
sección y la siguiente, los porcentajes pueden variar de un proyecto a otro.
Figura Nº 31. Esfuerzo respecto de los flujos de trabajo
Fuente: http://sistemaacademicogrupo5.files.wordpress.com/2012/06/71.jpg?w=610

79
Esfuerzo respecto de las fases
En la figura Nº 32 se muestran dos filas de porcentajes, el primero que es
el esfuerzo realizado por cada fase en forma general e incluyendo las
iteraciones dentro de cada fase; y en la segunda fila, la duración que tiene
aproximadamente en porcentajes del tiempo total del proyecto para cada una
de las fases incluyendo todas las iteraciones que conlleven realizar cada
fase.
Explicando más puntualmente una pequeña parte de la figura Nº 32 se
puede observar que para la fase de construcción se tiene que dedicar más
esfuerzo y mayor duración, siempre y cuando dependiendo de qué disciplina
estemos ejecutando, por ejemplo en la disciplina de implementación se tiene
mucho auge en la fase deconstrucción.
Figura Nº 32. Esfuerzo respecto de las fases
Fuente: http://sistemaacademicogrupo5.files.wordpress.com/2012/06/71.jpg?w=610

80
DISCIPLINAS
Las disciplinas conllevan los flujos de trabajo, los cuales son una
secuencia de pasos para la culminación de cada disciplina, estas disciplinas
se dividen en dos grupos: las primarias y las de apoyo.
Las primarias son las necesarias para la realización de un proyecto de
software, aunque para proyectos no muy grandes se pueden omitir algunas;
entre ellas se tienen: Modelado del Negocio, Requerimientos, Análisis y
Diseño, Implementación, Pruebas, Despliegue. Las de apoyo son las que
como su nombre lo indica sirven de apoyo a las primarias y especifican otras
características en la realización de un proyecto de software; entre estas se
tienen: Entorno, Gestión del Proyecto, Gestión de Configuración y Cambios.
A continuación se describe rápidamente cada una de estas disciplinas.
Modelado del negocio
Esta disciplina tiene como objetivos comprender la estructura y la
dinámica de la organización, comprender problemas actuales e identificar
posibles mejoras, comprender los procesos de negocio. Utiliza el Modelo de
Casos de Uso del Negocio para describir los procesos del negocio y los
clientes, el Modelo de Objetos del Negocio para describir cada Casos de Uso
del Negocio con los Trabajadores, además utilizan los Diagramas de
Actividad y de Clases.

81
Requerimientos
Esta disciplina tiene como objetivos establecer lo que el sistema debe
hacer (Especificar Requisitos), definir los límites del sistema, y una interfaz
de usuario, realizar una estimación del costo y tiempo de desarrollo. Utiliza el
Modelo de Casos de Uso para modelar el Sistema que comprenden los
Casos de Uso, Actores y Relaciones, además utiliza los diagramas de
Estados de cada Casos de Uso y las especificaciones suplementarias.
Análisis y diseño
Esta disciplina define la arquitectura del sistema y tiene como objetivos
trasladar requisitos en especificaciones de implementación, al decir análisis
se refiere a transformar Casos de Uso en clases, y al decir diseño se refiere
a refinar el análisis para poder implementar los diagramas de clases de
análisis de cada Casos de Uso, los diagramas de colaboración de cada
Casos de Uso, el de clases de diseño de cada Caso de Uso, el de secuencia
de diseño de Casos de Uso, el de estados de las clases, el modelo de
despliegue de la arquitectura.
Implementación
Esta disciplina tiene como objetivos implementar las clases de diseño
como componentes (ej. fichero fuente), asignar los componentes a los nodos,
probar los componentes individualmente, integrar los componentes en un
sistema ejecutable (enfoque incremental). Utiliza el Modelo de
Implementación, conjuntamente los Diagramas de Componentes para
comprender cómo se organizan los Componentes y dependen unos de otros.

82
Pruebas
Esta disciplina tiene como objetivos verificar la integración de los
componentes (prueba de integración), verificar que todos los requisitos han
sido implementados (pruebas del sistema), asegurar que los defectos
detectados han sido resueltos antes de la distribución
Despliegue
Esta disciplina tiene como objetivos asegurar que el producto está
preparado para el cliente, proceder a su entrega y recepción por el cliente.
En esta disciplina serializan las actividades de probar el software en su
entorno final (Prueba Beta), empaquetarlo, distribuirlo e instalarlo, así como
la tarea de enseñar al usuario.
Gestión y configuración de cambios
Es esencial para controlar el número de artefactos producidos por la
cantidad de personal que trabajan en un proyecto conjuntamente. Los
controles sobre los cambios son de mucha ayuda ya que evitan confusiones
costosas como la compostura de algo que ya se había arreglado etc., y
aseguran que los resultados de los artefactos no entren en conflicto con
algunos de los siguientes tipos de problemas:
a) Actualización simultánea: Es la actualización de algo elaborado con
anterioridad, sin saber que alguien más lo está actualizando.

83
b) Notificación limitada: Al realizar alguna modificación, no se deja
información sobre lo que se hizo, por lo tanto no se sabe quién, como,
y cuando se hizo.
c) Versiones múltiples: No saber con exactitud, cual es la última versión,
y al final no se tiene un orden sobre que modificaciones se han
realizado a las diversas versiones.
Gestión del proyecto
La gestión de proyectos u objetivo es equilibrar los objetivos competitivos,
administrar el riesgo, y superar restricciones para entregar un producto que
satisface las necesidades e ambos clientes con éxito (los que pagan el
dinero) y los usuarios. Con la Gestión del Proyecto se logra una mejoría en el
manejo de una entrega exitoso de software. En resumen su propósito
consiste en proveer pautas para:
a) Administrar proyectos de software intensivos.
b) Planear, dirigir personal, ejecutar acciones y supervisar proyectos.
c) Administrar el riesgo.
Sin embargo, esta disciplina no intenta cubrir todos los aspectos de
dirección del proyecto. Por ejemplo, no cubre problemas como:
a) Administración de personal: contratando, entrenando, enseñando.
b) Administración del presupuesto: definiendo, asignando.
c) Administración de los contratos con proveedores y clientes.

84
Entorno
Esta disciplina se enfoca sobre las actividades necesarias para configurar
el proceso que engloba el desarrollo de un proyecto y describe las
actividades requeridas para el desarrollo de las pautas que apoyan un
proyecto.
Su propósito es proveer a la organización que desarrollará el software, un
ambiente en el cual basarse, por medio de procesos y herramientas que
apoyen el desarrollo el software.
ORGANIZACIÓN Y ELEMENTOS EN RUP
Ya conociendo varias partes del RUP nos concentraremos ahora en los
elementos que lo componen, entre estos se tienen: Flujos de Trabajo, Detalle
de los Flujos de Trabajo, Actores, Actividades y Artefactos. En la figura Nº 33
se muestran más claramente cómo se representan gráficamente cada uno de
estos elementos y la interrelación entre ellos. Se puede observar que el Flujo
de Trabajo de Requerimientos conlleva varios pasos, cada uno de estos
pasos tiene asociado uno o varios actores, los cuales a su vez son los
encargados de la ejecución de varias actividades, las cuales a la vez están
definidas en artefactos o guías para su realización.

85
Figura Nº 33. Elementos que conforman el RUP
Fuente: http://1.bp.blogspot.com/-rCC4hHbPo2U/T-
Tif5HrhbI/AAAAAAAACQ4/Cwao1CIQ2HA/s1600/dib11.JPG
Actores o roles: Son los personajes encargados de la realización de las
actividades definidas dentro de los flujos de trabajo de cada una de las
disciplinas del RUP, estos actores se dividen en varias categorías: Analistas,
Desarrolladores, Probadores, Encargados, Otros actores. A continuación se
presenta una lista de actores de acorde a las categorías mencionadas con
anterioridad:
Analistas:
a) Analista del Proceso del Negocio.
b) Diseñador del Negocio.
c) Revisor del Modelo del Negocio.
d) Revisor de Requerimientos.

86
e) Analista del Sistema.
f) Especificador de Casos de Uso.
g) Diseñador de Interfaz del Usuario.
Desarrolladores
a) Arquitecto.
b) Revisor de la Arquitectura.
c) Diseñador de Cápsulas.
d) Revisor del Código y Revisor del Diseño.
e) Diseñador de la Base de Datos.
f) Diseñador.
g) Implementador y un Integrador.
Probadores Profesionales
a) Diseñador de Pruebas.
b) Probador.
Encargados
a) Encargado de Control del Cambio.
b) Encargado de la Configuración.
c) Encargado del Despliegue.
d) Ingeniero de Procesos.
e) Encargado de Proyecto.
f) Revisor de Proyecto.
Otros
a) Cualquier trabajador.
b) Artista Gráfico.

87
c) Stakeholder (Parte interesada).
d) Administrador del Sistema.
e) Escritor técnico.
f) Especialista de Herramientas.
Artefactos: Los artefactos son el resultado parcial o final que es producido y
usado por los actores durante el proyecto. Son las entradas y salidas de las
actividades, realizadas por los actores, los cuales utilizan y van produciendo
estos artefactos para tener guías. Un artefacto puede ser un documento, un
modelo o un elemento de modelo.
Conjuntos de artefactos
Se tiene un conjunto de artefactos definidos en cada una de las
disciplinas y utilizadas dentro de ellas por lo actores para la realización de las
mismas, a continuación se definen cada una de estas categorías o grupos de
artefactos dentro de las disciplinas del RUP:
a) Modelado del negocio
Los artefactos del modelado del negocio capturan y presentan el
contexto del negocio del sistema. Los artefactos del modelado del negocio
sirven como entrada y como referencia para los requisitos del sistema.
b) Requerimientos
Los artefactos de requerimientos del sistema capturan y presentan la
información usada en definir las capacidades requeridas del sistema.
c) Análisis y diseño del sistema

88
Los artefactos para el análisis y del diseño capturan y presenta la
información relacionada con la solución a los problemas se presentaron en
los requisitos fijados.
d) Implementación
Los artefactos para la implementación capturan y presentan la
realización de la solución presentada en el análisis y diseño del sistema.
e) Pruebas
Los artefactos desarrollados como productos de las actividades de
prueba y de la evaluación son agrupadas por el actor responsable, con el
cual se lleva un conjunto de documentos de información sobre las pruebas
realizadas y las metodologías de pruebas aplicadas.
f) Despliegue
Los artefactos del despliegue capturan y presentan la información
relacionada con la transitividad del sistema, presentada en la implementación
en el ambiente de la producción.
g) Administración del proyecto
El conjunto de artefactos de la administración del proyecto capturan
los artefactos asociados con el proyecto, el planeamiento y a la ejecución del
proceso.
h) Administración de cambios y configuración
Los artefactos de la configuración y administración del cambio
capturan y presentan la información relacionada con la disciplina de
configuración y administración del cambio.

89
i) Entorno o ambiente
El conjunto de artefactos del ambiente presentan los artefactos que se
utilizan como dirección a través del desarrollo del sistema para asegurar la
consistencia de todos los artefactos producidos.
En la siguiente tabla y en la figura Nº 34 se hace un breve resumen
de los artefactos y su función en las diferentes disciplinas.
TABLA Nº 3: ARTEFACTOS EN LAS FASES DE RUP
Fase Descripción Artefacto
Inicio Durante esta fase de inicio, las iteraciones se
centran con mayor énfasis en las actividades
de modelamiento de la empresa y en sus
requerimientos.
Especificación de
Requisitos
Elaboración
Durante esta fase de elaboración, las
iteraciones se centran al desarrollo de la base
de diseño, encierran más los flujos de trabajo
de requerimientos, modelo de la organización,
análisis, diseño y una parte de implementación
orientada a la base de la construcción
Diagrama de Casos de
Uso
Construcción
Durante esta fase de construcción, se lleva a
cabo la construcción del producto por medio
de una serie de iteraciones las cuales se
seleccionan algunos Casos de Uso, se
redefine su análisis y diseño y se procede a su
implantación y pruebas. En esta fase se
realiza una pequeña cascada para cada ciclo,
se realizan tantas iteraciones hasta que se
termine la nueva implementación del producto.
Diagrama de Clases
Modelo Entidad Relación

90
Implementación
Pasar de los resultados de la fase de Diseño a
implementar el sistema en términos de
componentes tales como ficheros fuente,
ejecutables, scripts, etc.
Diagrama de
Componentes
Ejecutables Documentos
Ficheros con código
fuente de una o varias
clases
Figura Nº 34. Artefactos en las disciplinas de la RUP
Fuente:
http://inf162scontroldepensiones.files.wordpress.com/2011/09/rup111.jpg?w=714

91
Grado de finalización de artefactos: Consiste en cuanto hemos finalizado
del artefacto propuesto, con esto nos referimos por ejemplo, si definimos que
vamos a utilizar un artefacto, este nos dice los lineamientos que necesita
para ser completado, por lo tanto con grado de finalización nos referimos a
cuántos de esos lineamientos del artefacto hemos completado o llenado,
esto en cada una de las disciplinas, de acorde a la fase en que se encuentre,
para entender de mejor manera lo antes dicho se muestra la figura Nº 35, en
la cual se puede observar que en la fase de concepción, en la disciplina de
implementación del sistema los artefactos tienen una poca finalización y van
aumentando progresivamente encada fase hasta llegar a su culminación en
la fase de transición, en la disciplina de ingeniería del negocio los artefactos
tienen una media finalización y sucede lo mismo que con los artefactos de la
disciplina anterior los cuales finalizan también en la fase de transición.
Figura Nº 35. Grado de finalización de artefactos
Fuente:
http://inf162scontroldepensiones.files.wordpress.com/2011/09/rup111.jpg?w=715

92
Con esto se puede mostrar el aumento progresivo de los artefactos en
cada disciplina en la fase dada, teniendo una idea un poco más amplia sobre
el desenvolvimiento del proyecto hablando en términos de sus artefactos.
Podemos afirmar que la metodología RUP cuenta con un enfoque
disciplinado en la asignación de tareas y responsabilidades dentro de una
organización del desarrollo, con la cual se puede mantener una fácil
administración de este proceso.
Para obtener un máximo control de variables que conlleva un desarrollo
de aplicaciones y poder mantener una ordenada implementación de éstas, es
importante seguir metodologías y estándares que nos lleven a estar en
competitividad en todo momento.
Al implementar un Desarrollo Rápido de Aplicaciones de un Sistema
particular, es importante la utilización de Patrones, los cuales ya tienen una
funcionalidad general y han sido predefinidos, y así contar con una base
consistente y previamente elaborada para la implementación del Software.
En la siguiente tabla se detallará con mayor precisión las disciplinas de la
metodología RUP y las diferentes actividades que conllevarán a obtener el
artefacto deseado.

94
Tabla Nº 4 Desarrollo de la RUP
C: comienzo de la construcción del Artefacto
R: refinamiento del artefacto (ampliación, corrección)
Componentes del Up Fases del RUP
Disciplina Actividades Artefacto Inicio Elaboración Construcción Transición
Modelado del
Negocio
Comprender los problemas actuales e
identificar las posibles mejoras mediante
la utilización de casos de uso,
diagramas de actividad y de clases
Modelo del
dominio
C
Requerimientos
Describir los objetivos, funcionalidades y
restricciones en forma concisa, además
de describir requisitos no funcionales.
Definir los términos del dominio del
problema
Modelos de
Casos de
Uso
C R
Visión y
Análisis del
Negocio
C R
Especificaci
ón
Compleme
C R

95
ntaria
Glosario C R
Diseño
Realizar los diagramas descriptivos del
diseño lógico, diagramas de clases del
software, diagramas de interacción,
diagramas de paquetes.
Describir la correlación entre los
componentes del software y los
requerimientos, además de comprender
los esquemas de las bases de datos
Modelo de
Diseño
C R
Documenta
ción de
Arquitectur
a
C
Modelo de
Datos
C R

96
Implementación Construir los códigos fuente, los
ejecutables y las bases de datos, que
conforman la aplicación.
Modelo de
la
Implementa
ción
C R
R
Gestión del
Proyecto
Proponer y seleccionar las herramientas
de desarrollo, actividades de formación
y recursos adicionales.
Plan de
desarrollo
C R R R
Pruebas Describir las partes del sistema que se
probarán y cómo se probarán, además
de comparar el resultado obtenido
contra el esperado.
Modelo de
Pruebas
C R
Entorno
Descripción de los pasos de la
metodología de desarrollo y de los
artefactos que son más adecuados para
la aplicación, es decir adaptar la
metodología para el proyecto a
desarrollar.
Marco de
Desarrollo
C R

97
Análisis y diseño de la Metodología RUP
El RUP propone la utilización de los modelos para la implementación completa
de todas sus fases respectivamente con sus disciplinas:
· Modelo de Casos de Uso del Negocio: Describe la realización de los Casos de
Uso, es realizado en la disciplina de Modelado del Negocio.
· Modelo de Objetos del Negocio: Se utiliza para identificar roles dentro dela
organización, es realizado en la disciplina de Modelado del Negocio.
· Modelo de Casos de Uso: Muestra las interrelaciones entre el sistema y su
ambiente, además sirve como un contrato entre el cliente y los diseñadores. Es
considerado esencial al iniciar las actividades de análisis, diseño y prueba; este
modelo es realizado en la disciplina de Requerimientos.
· Modelo de Análisis: Contiene los resultados del análisis del Caso de Uso, y
contienen instancias del artefacto de Análisis de Clases; es realizado en la
disciplina de Análisis y Diseño.
· Modelo de Diseño: Es un modelo de objetos que describe la realización
del Caso de Uso, y sirve como una abstracción del modelo de implementación y
su código fuente, es utilizado como entrada en las actividades de implementación
y prueba; este modelo es realizado en la disciplina de Análisis y Diseño.
· Modelo de Despliegue: Muestra la configuración de los nodos del proceso en
tiempo de ejecución, muestra los lazos de comunicación entre estos nodos, así
como las de los objetos y componentes que en él se encuentran; es realizado en
la disciplina de Análisis y Diseño.

98
· Modelo de Datos: Es un subconjunto del modelo de implementación que
describe la representación lógica y física de datos persistentes en el sistema.
También incluye cualquier conducta definida en la base de datos como
disparadores, restricciones, etc. Es elaborado en la disciplina de Análisis y Diseño.
· Modelo de Implementación: Es una colección de componentes, y de
subsistemas de aplicación que contienen estos componentes, entre estos están
los entregables, ejecutables, archivos de código fuente. Es realizado en la
disciplina de Implementación.
· Modelo de Pruebas: Es utilizado para la elaboración de las pruebas, y se realiza
en la disciplina de Pruebas.
Estos modelos representan los diagramas que propone el UML para el
desarrollo de modelado de un proyecto de software, con los cuales se puede
representar los propuesto por UML mediante la metodología RUP utilizando las
herramientas que esta provee para la implementación fácil, clara y estructurada de
los diagramas utilizados.
Descripción de estereotipos
Para poder entender la interrelación que tiene UML con RUP se tiene que
saber que el inicio de todo está con los casos de uso, para poder tener una base
sobre lo cual se quiere trabajar, los casos de uso son la base para esta técnica;
luego se procede a la obtención de los diagramas expuestos anteriormente,
dependiendo de cuáles son los necesarios de implementar, luego se procede a la
identificación de los estereotipos, ya que cada uno de estos representan las
funciones que se van a definir dentro de los diagramas, estos diagramas nos
ayudan a entender la lógica del caso de uso expuesto.

99
Las clases, al igual que los demás elementos notacionales del UML, pueden
estar clasificadas de acuerdo a varios criterios, como por ejemplo su objetivo
dentro de un programa. Esta clasificación adicional se puede expresar mediante la
utilización de estereotipos.
Los estereotipos más comunes utilizados para clasificar las clases son:
Entidad (entity), Frontera (boundary), Control (control). Se proponen varias pautas
a seguir a la hora de encontrar las clases de nuestro sistema durante la fase de
análisis. Dichas pautas se centran en la búsqueda de los estereotipos entidad,
control y frontera:
· Una clase entidad modela la información de larga vida y su comportamiento
asociado. Este tipo de clase suele reflejar entidades del mundo real o elementos
necesarios para realizar tareas internas al sistema. También se denominan clase
dominio, ya que suelen tratar con abstracciones de entidades del mundo real.
· Una clase frontera maneja comunicaciones entre el entorno del sistema y el
sistema, suelen proporcionar la interfaz del sistema con un usuario o con otro
sistema, en general, por tanto, modelan las interfaces del sistema. Cuando se trata
de clases que definen la interfaz con otro sistema se refinarán durante la fase de
diseño, para tener en cuenta los protocolos de comunicación elegidos.
· Una clase control modela el comportamiento secuenciado específico de uno o
varios casos de uso. Se trata de clases que coordinan los eventos necesarios para
llevar a cabo el comportamiento que se especifica en el caso de uso, representan
su dinámica.
Enlace del RUP con el UML

100
Conociendo los estereotipos utilizados para la representación de las clases
(Entidad, Control y Frontera), ahora podemos explicar la interrelación que existe
entre el UML y RUP describiendo los diagramas que describe UML y como se
convierten en diagramas del RUP que utilizan estos estereotipos.
El UML proporciona los diagramas de Caso de Uso, al mismo tiempo que el
RUP, la única diferencia es la forma de dibujar los estereotipos, ya que en el RUP
son una elipse con una diagonal al lado derecho (pero esto es para casos de uso
de negocio, los de sistema no tienen la diagonal), y en UML solamente una elipse,
pero en el RUP significa lo mismo a lo que se refiere en UML. En la figura Nº 36 se
muestra lo descrito anteriormente, aunque no nos importa en este caso el motivo
por el cual se hicieron los diagramas, o la utilización que se les dio, ya que
únicamente nos interesa conocer la forma de dibujar ambos diagramas para
conocer sus diferencias:
a) b)
Figura Nº 36. Comparación entre diagramas de casos de uso (a) RUP (b) UML
Fuente: http://www.monografias.com/trabajos-pdf5/diagramas-casos-uso/image002.jpg
Los diagramas de Clases tienen la misma lógica para lo cual fueron creados en
ambos lenguajes, solamente con las diferencias en la forma de dibujar los cuadros
que indican las clases, en el RUP se dibujan los cuadros con una pestaña inferior
derecha doblada, y en UML solamente rectángulos con ángulos rectos; otra

101
característica que se puede observar es que a la hora de ejemplificar las
relaciones uno a uno, uno a muchos etc., se realizan de diferente manera. Pero en
ambos lenguajes se puede observar que los diagramas de clases son lo más
cercano a la elaboración de un modelo Entidad Relación para la puesta en
práctica de la finalización del proyecto de software.
Los diagramas de objetos, difieren únicamente en la forma como se dibujan los
objetos o instancias de las clases, ya que en el RUP se dibujan círculos con una
diagonal en la parte inferior derecha, y en UML como rectángulos con las esquinas
redondeadas, también en RUP no se colocan flechas indicativas, y en UML sí. En
las siguientes figuras se presentan las diferencias planteadas anteriormente, es
importante mencionar que la lógica década figura no nos importa en este
momento, solamente deseamos representarla forma en que se dibujan los objetos,
esto ya que cada una de las figuras Nº 37(a) y 37(b) se refieren a distintos
ejemplos.
a) b)
Figura Nº 37. Comparación entre diagramas de objetos (a) RUP (b) UML
Los siguientes dos diagramas (figura Nº 38(a) y (b)) presentan la forma como se
elabora un diagrama de estados en RUP y UML, se puede observar que de igual
manera se elaboran ambos, únicamente que en el diagrama de UML se muestran

102
unos rectángulos con la esquina superior derecha doblada, que indican notas
sobre este estado.
a) b)
Figura Nº 38. Comparación entre diagramas de estados (a) RUP (b) UML
En los diagramas de actividades se utilizan todos los bloques utilizados en la
elaboración de diagramas de flujo, por lo tanto en ambos lenguajes se utilizan los
mismos, a continuación podemos ver la figura Nº 39 que muestra ejemplos de
ambos lenguajes, aunque el enfoque de cada diagrama presentado es distinto,
solamente se tomaron de ejemplos para ejemplificar los bloques utilizados.

103
a) b)
Figura Nº 39. Comparación entre diagramas de actividades (a) RUP (b) UML
En los diagramas de secuencia se pueden encontrar diferencias leves, como se
puede mostrar en la figura Nº 40 los diagramas de secuencia de UML no llevan los
símbolos que identifican los estereotipos interface (círculo con una raya horizontal
del lado izquierdo y junto a esta otra vertical), control (círculo con una flecha sobre
su borde apuntando al lado izquierdo) y entidad (círculo con una raya horizontal en
la parte inferior del mismo), representados por círculos con características
independientes
Figura Nº 40. Diagrama de secuencia
Fuente:
http://www.humbertocervantes.net/homepage/itzamna/DOCUMENTACION/DiagSeqDis_Inicio
Aplicacion.gif

104
Los diagramas de colaboración se representan similares, con la única
diferencia de los bloques que representan las clases, ya que en el RUP se
representan por medio de los círculos con sus características individuales de
acorde a la función que desempeñan (interfaz, control, entidad), y en UML
solamente como rectángulos. En ambos se colocan las actividades que conllevan
realizar para llegar a una clase determinada, esto se coloca directamente en la
flecha dibujada en la línea que va hacia la clase. Esto se puede observar en la
figura Nº 41.
a)b)
Figura Nº 41. Comparación entre diagramas de colaboración (a) RUP (b) UML
Fuente: http://inf162scontroldepensiones.files.wordpress.com/2011/09/rup27-
1.jpg?w=607&h=325
Dentro de los diagramas de implementación se encuentran los de componentes
(figura Nº 42), los cuales se representan de manera similar en ambos lenguajes,
como se muestra en la figura siguiente.

105
Figura Nº 42. Diagrama de componentes
Fuente: http://www.oocities.org/es/monsalvelaura/fase2/images/Diagramacomponentes.JPG
La diferencia básica en los diagramas de despliegue (figura Nº 43) es que en
UML se dibujan dentro de las cajas los componentes utilizados, en cambio en el
RUP se diagraman de forma separada como se muestran en las figuras
siguientes.
a)

106
b)
Figura Nº 43. Comparación entre diagramas de despliegue (a) RUP (b) UML
Fuente: http://inf162scontroldepensiones.files.wordpress.com/2011/09/rup27-
1.jpg?w=607&h=389
Se puede observar en todos los diagramas presentados anteriormente que la
similitud entre ambos lenguajes es demasiado grande, y es de esperar esto, ya
que RUP utiliza los del UML y por lo tanto recopila todo lo que este lenguaje
necesita para la implementación, y agrega mejoras, siendo una herramienta de
modelado muy eficiente, ya que proporciona todas las herramientas necesarias
para tal función, por lo tanto la funcionalidad completa de UML esta descrita e
implementada por el RUP, solamente mejorando las características como el
cambio de ciertos diagramas de una manera sutil, para diferenciar más claramente
que es lo que se está haciendo y no perder el enfoque de lo que se desea.

107
CAPITULO IV
ORGANIZACIÓN Y ANALISIS DE LOS RESULTADOS
A continuación serán descritas las disciplinas de la Metodología RUP que
se aplicaron en el desarrollo de la Aplicación, así como los artefactos obtenidos en
cada una de las mismas.
Modelado del Negocio
Como se mencionó anteriormente la Unidad de Sección Académica del Centro
Local Lara de la Universidad Nacional Abierta, es el organismo destinado para
estudiar las cuestiones relacionadas con las funciones de docencia, investigación
y extensión que ejerce en dicha universidad.
Actualmente cuenta con un manejo en cuanto a la Recepción y Emisión de
Documentos de forma Manual, lo que conlleva a la pérdida de tiempo y a su
defecto a la pérdida de información, ya que en un momento dado puede ser
posible que sea extraviado algún documento de suma importancia. Los objetos del
dominio representan eventos o hechos que suceden en el ámbito donde se
desenvuelve el sistema. Específicamente en la Unidad Académica suceden los
siguientes eventos respecto a la recepción y emisión de Documentos:

108
- Cuando a la Unidad de Sección Académica llega un documento desde
alguna entidad, ya sean centros locales, unidades de apoyo, Nivel
Central o algún ente externo la secretaria, es la encargada de recibirlo y
firmar una copia la cual será entregada a la persona que lo entrega.
- Luego ella se encarga de registrar el documento, llenando un formulario
en el cual se especificará el tipo de documento que es (circular,
memorandos, resoluciones o comunicado), la entidad de donde se emite
o hacia dónde va dirigido, la fecha de emisión así como también la fecha
de recepción del documento en la Unidad, el asunto sobre que trata dicho
documento y además del número del documento.
- Después de haber realizado la recolección de los datos más importantes,
se dirige hacia el archivo donde será ubicado el documento y lo almacena
en la carpeta correspondiente a la entidad ordenándolo por fecha.
- Al momento de ser solicitado un documento por el jefe de la Unidad, la
secretaria se dirige al archivo físico en donde se encuentra almacenado,
ubica la carpeta de la entidad y lo extrae, sólo con la finalidad de
satisfacer las necesidades inmediatas en cuanto un documento solicitado.
Como pudo apreciarse, la secretaria de la Unidad realiza todos estos
sucesos de forma manual siendo ella la encargada directa de la recepción y
emisión, almacenamiento y organización de los documentos en el archivo físico en
la misma, además lo cual hace que ella sea la única persona capaz de saber la
ubicación exacta de cada uno de los documentos en los archivadores existentes,
esto hace que el Jefe de la Unidad cree una dependencia directa con la secretaria,
al momento de solicitar un documento en específico. Es por ello que es necesario

109
la implantación de un sistema que facilite la organización y búsqueda de los
documentos que son tanto emitidos como recibidos en la Unidad Académica. En
conversación con el Jefe de la Unidad, se planteó la construcción de una
aplicación Web (denominada RED) que preste al usuario el servicio correcto en
cuanto al registro de los documentos (emitidos y recibidos) que son manejados en
dicha unidad y a su vez, contar con un buscador de documentos que permitan la
recuperación inmediata de los mismos mediante descriptores específicos, esto
conducirá a que sea un sistema innovador y de fácil manejo para los usuarios que
lo vayan a utilizar.
Requerimientos
El propósito fundamental de los requerimientos, es guiar el correcto
desarrollo del sistema. Esto se consigue mediante una descripción de los
requisitos del sistema para llegar a un acuerdo con el cliente de lo que debe y no
debe hacer el sistema. La Unidad de Sección Académica del Centro Local Lara
necesita un sistema que abarque las siguientes prestaciones:
1. Permita al usuario el registro de los documentos que son tanto emitidos
como recibidos en la Unidad de Sección Académica del Centro Local Lara
de manera fácil y segura.
2. Ayude a la organización de los Documentos; con esta organización
evitamos la pérdida de tiempo al recuperar la información al momento de
que sea solicitada por el usuario.
3. Facilite al usuario la búsqueda de los Documentos que se registrados en
el sistema,
4. Generar los reportes solicitados por los usuarios del sistema.

110
Cabe destacar que junto con los usuarios que manejarán el sistema se
definieron los siguientes requerimientos:
 Registro de:
- Archivos: contiene los diferentes archivadores físicos que se
encuentran en la Unidad de Sección Académica.
- Estados: contienen los distintos estados que conforman el Estado
Venezolano y donde se encuentran los Centros Locales y Unidades
de Apoyo de la Universidad Nacional Abierta.
- Tipo de Entidades: se refiere a la estructura que posee la
Universidad Nacional Abierta, es decir, centros locales, unidades de
apoyo, unidades o secciones pertenecientes a un centro local, los
departamentos del Nivel Central, así como también los entes que
son externos a la Universidad entre los que se pueden nombrar,
gobernaciones, alcaldías, etc.
- Entidades: contiene las dependencias en que se encuentra
organizada la Universidad.
- Tipo de Documento: se refiere al documento que es recibido o
emitido, es decir, si son memorandos, circulares, comunicados, etc.
- Documentos (Recibidos y/o Emitidos) se refiere a todos los
documentos que pueden ser almacenados en la base de datos.
 Búsqueda, modificación y eliminación de documentos mediante
descriptores, es decir, mediante una palabra clave, rango de fecha, tipo
de documento, entidad que lo emite, entidad que lo recibe, tipo de
entidad, estado y status de la entidad.
 Búsqueda, modificación y eliminación de:

111
- Estados.
- Entidades.
- Tipos de documentos.
- Tipos de Entidades.
- Archivos.
 Generar los diferentes reportes que sean solicitados por los usuarios
en un momento determinado. Dichos reportes pueden ser:
Tipo de Documentos
Entidades
Archivadores
Listado de Documentos
Tipo de Entidades
Estados
 Además del motor de búsqueda que poseerá el sistema también se
encuentra la posibilidad de saber que documentos de los solicitados poseen
seguimiento, es decir, si tienen respuesta del ente al que fue emitido o del
que fue recibido.
 Registro y Actualización de cuentas de Usuario, así como de sus Perfiles y
Cargos.

112
Especificaciones Complementarias
Además de los requerimientos listados anteriormente, el sistema debe
contemplar ciertas especificaciones complementarias, como son:
 Software de fácil ejecución y uso, mediante la utilización de un menú
desplegable que facilita su navegabilidad y salidas del mismo, permitiendo
al usuario conocer en que parte de la aplicación se encuentra. Además de
la validación de campos numéricos y presentación de calendarios para la
selección de las fechas.
 Calidad del entorno visual, es decir con pantallas atractivas para el usuario,
que contarán con la utilización de títulos, menús, ventanas, botones, etc.
 La seguridad del sistema será controlada por contraseña y nombre de
usuario que le serán suministradas a los usuarios con debida autorización
del administrador del sistema.
 El sistema estará documentado por mensajes de error y ayudas
incorporadas.
Actores del sistema propuesto
En RED se identificaron los siguientes actores:

113
Tabla Nº 5 Actores del sistema
Actores Descripción
Secretaria de la Unidad Académica
Representa a la persona que utilizará
el sistema como una herramienta de
apoyo para llevar el control de
documentos existentes en el
departamento, además de poder en
cualquier momento generar un
reporte y presentaciones basados en
datos almacenados.
Administrador del Sistema
Es el responsable por la integridad y
resguardo de la información
almacenada, tiene el máximo
privilegio de uso del sistema y a
través de él se pueden crear,
modificar y eliminar los usuarios.
Casos de Uso
Revisando los requisitos, previamente definidos se extrajeron los siguientes
casos de uso
Tabla Nº 6 Descripción de los Casos de Uso
Casos de Uso Descripción
Caso de uso Incluir Estado Consiste en realizar la inserción de un
Estado perteneciente al Territorio
Venezolano.
Caso de uso Modificar Estado Modifica y actualiza el registro de un
estado seleccionado.
Caso de uso Eliminar Estado Desincorpora un estado elegido.
Caso de Uso Buscar Estado Consiste en buscar en un catálogo de
estados un estado en particular
Caso de uso Incluir Tipo Documento Consiste en realizar la inserción de un
Tipo de Documento.
Caso de uso Modificar Tipo Documento Modifica y actualiza el registro de un
tipo de documento.
Caso de uso Eliminar Tipo Documento Desincorpora un tipo de documento.

114
Caso de Uso Buscar Tipo documento Consiste en buscar en un catálogo de
tipos de documentos un tipo de
documento en particular
Caso de uso Incluir Entidad Consiste en realizar la inserción de una
Entidad.
Caso de uso Modificar Entidad Modifica y actualiza el registro de una
entidad seleccionada.
Caso de uso Eliminar Entidad Desincorpora una entidad elegida.
Caso de Uso Buscar Entidad Consiste en buscar en un catálogo de
entidades una entidad en particular
Caso de uso Incluir Tipo Entidad Consiste en realizar la inserción de un
Tipo de Entidad.
Caso de uso Modificar Tipo Entidad Modifica y actualiza el registro de un
tipo de entidad.
Caso de uso Eliminar Tipo Entidad Desincorpora un tipo de entidad.
Caso de Uso Buscar Tipo Entidad Consiste en buscar en un catálogo de
tipos de entidades un tipo de entidad en
particular
Caso de uso Incluir Archivo Consiste en realizar la inserción del
Archivo.
Caso de uso Modificar Archivo Modifica y actualiza el registro de un
archivo seleccionado.
Caso de uso Eliminar Archivo Desincorpora el archivo elegido.
Caso de Uso Buscar Archivo Consiste en buscar en un catálogo de
archivadores un archivo en particular
Caso de uso Incluir Documento Consiste en realizar la inserción de un
Documento.
Caso de uso Modificar Documento Modifica y actualiza el registro de un
documento seleccionado.
Caso de uso Eliminar Documento Desincorpora un documento elegido.
Caso de Uso Buscar Documento Consiste en buscar en un catálogo de
documentos un documento en
particular

115
Caso de uso Incluir Seguimiento Consiste en realizar la inserción de un
Seguimiento.
Caso de uso Modificar Seguimiento Modifica y actualiza el registro de un
seguimiento seleccionado.
Caso de uso Eliminar Seguimiento Desincorpora un seguimiento elegido.
Caso de Uso Buscar Seguimiento Consiste en buscar en un catálogo de
seguimientos un seguimiento en
particular
Caso de uso Generar Reporte Tipo de
Entidades
Genera un reporte del tipo de entidades
almacenadas
Caso de uso Generar Reporte Tipo de
Documentos
Genera un reporte de los Tipos de
documentos almacenados.
Caso de uso Generar Reporte de
Estados
Genera un reporte de los Estados
almacenados.
Entidades
Genera un reporte de las Entidades
almacenadas.
Documentos
Genera un reporte de los Documentos
(emitidos y/o recibidos) en la Unidad
Académica del Centro Local Lara.
Pueden ser por un rango de tiempo, por
el tipo de documento, por el status del
documento, por la entidad que emite el
documento, por la entidad que recibe el
documento, una palabra clave, por el
tipo de entidad, por un estado y por el
status de la entidad.
Archivadores
Genera un reporte de los Archivos
existentes en la Unidad Académica del
Centro Local Lara.
Caso de uso Ingresar Sistema
Consiste en incluir al sistema las
diferentes operaciones (menús,
opciones y botones) que pueden
realizar un usuario.
Caso de uso Modificar Sistema Modifica y actualiza el registro de las
operaciones que realizará el sistema.
Caso de uso Eliminar Sistema Desincorpora del sistema una
operación elegida.
Caso de Uso Buscar Sistema Consiste en buscar en un catálogo de
sistemas un sistema en particular
Caso de uso Incluir Perfil Usuario Consiste en incluir un perfil de usuario.
Caso de uso Eliminar Perfil Usuario
Elimina y desincorpora un perfil de un
usuario
Caso de uso Modificar Perfil Usuario
Modifica y actualiza un perfil de un
usuario.
Caso de Uso Buscar Perfil Usuario
Consiste en buscar en un catálogo de
perfiles de usuarios un perfil de usuario
en particular
Caso de uso Incluir Cargo Usuario
Consiste en incluir el cargo de un
usuario.

116
Caso de uso Eliminar Cargo Usuario
Elimina y desincorpora el cargo de un
usuario.
Caso de uso Modificar Cargo Usuario
Modifica y actualiza en el sistema un
cargo de un usuario.
Caso de Uso Buscar Cargo Usuario
cargos de usuarios un cargo de usuario
en particular
Caso de uso Incluir Usuario
Consiste en incluir un usuario con su
debida contraseña, la cual le permitirá
navegar por las diferentes opciones
que ofrece el sistema.
Caso de uso Eliminar Usuario Elimina y desincorpora un usuario.
Caso de uso Modificar Usuario Modifica y actualiza un usuario elegido.
Caso de Uso Buscar Usuario
usuarios un usuarios en particular
Diagramas de Casos de Uso
Los diagramas de casos de usos son utilizados para representar la
funcionalidad del sistema, enfocándose en el comportamiento del sistema desde
un punto de vista externo a éste. Para RED fueron definidos los diagramas para
los siguientes Casos de Uso:
Caso de Uso Incluir Estado
Figura Nº 44 Diagrama del Caso de Uso Incluir Estado
RED
Incluir Estado
Secretaria de la
Unidad

117
Caso de Uso Incluir Estado
Descripción Inclusión del nombre de un Estado.
Actores Secretaria de la Unidad. (Iniciador)
Pre Condiciones
Entrar al caso de uso Incluir Estado.
El sistema proporciona el Código del Estado.
Post Condiciones
El sistema lleva a cabo la opción solicitada por el
usuario.
Flujo Principal
1. El usuario selecciona el Menú Definiciones y
selecciona la opción “Estado”
2. La aplicación abre la ventana ESTADOS
3. El usuario pulsa el botón Nuevo.
4. El sistema genera automáticamente el código del
estado que se va a incluir y solicita al usuario el
Nombre del Estado.
5. El usuario ingresa los datos solicitados y pulsa el
botón incluir.
6. El sistema almacena el nuevo estado.
Caso de Uso Modificar Estado
Figura Nº 45 Diagrama del Caso de Uso Modificar Estado
RED
Modificar Estado
Secretaria de la
Unidad

118
Caso de Uso Modificar Estado
Descripción Modificación del nombre de un Estado.
Pre Condiciones
Entrar al caso de uso Modificar Estado.
Post Condiciones
usuario.
Flujo Principal
1. El usuario pulsa el botón Buscar en la pantalla
“Estados”.
2. El sistema despliega un catálogo con los estados
almacenados
3. El usuario selecciona del catálogo el Estado a
Modificar.
4. La aplicación muestra en pantalla el Nombre del
Estado a modificar.
5. El usuario modifica el nombre del estado y pulsa
botón modificar.
6. El sistema actualiza el registro.
Caso de Uso Eliminar Estado
Figura Nº 46 Diagrama del Caso de Uso Eliminar Estado
RED
Eliminar Estado
Secretaria de la
Unidad

119
Caso de Uso Eliminar Estado
Descripción
Eliminación de un Estado que se encuentra
almacenado en el sistema.
Pre Condiciones
Entrar al caso de uso Eliminar Estado.
Post Condiciones
usuario.
Flujo Principal
“Estados”.
almacenados
3. El usuario selecciona del catálogo el Estado a
Eliminar.
4. La aplicación muestra en pantalla los datos del
Estado a eliminar.
5. El usuario visualiza los datos mostrados y pulsa
el botón eliminar.
6. El sistema elimina el registro.
Caso de Uso Buscar Estado
Figura Nº 47 Diagrama del Caso de Uso Buscar Estado
RED
Buscar Estado
Secretaria de la
Unidad

120
Caso de Uso Buscar Estado
Descripción Recupera de la Base de Dato un Estado.
Pre Condiciones
Entrar al caso de uso Buscar Estado.
Post Condiciones
usuario.
Flujo Principal
“Estados.
almacenados.
3. El usuario escoge el Estado que desea visualizar
4. El sistema muestra en pantalla los datos del
Estado seleccionado.
5. El usuario pulsa el botón salir.
6. RED cierra la pantalla “Estados”.
Caso de Uso Incluir Tipo Documento
Figura Nº 48 Diagrama del Caso de Uso Incluir Tipo Documento
RED
Incluir Tipo Documento
Secretaria de la
Unidad

121
Caso de Uso Incluir Tipo Documento
Descripción Inclusión del nombre de un Tipo de Documento.
Pre Condiciones
Entrar al caso de uso Incluir Tipo Documento.
El sistema proporciona el Código del Tipo de
documento.
Post Condiciones
usuario.
Flujo Principal
selecciona la opción “Tipo de Documento”
2. La aplicación abre la ventana TIPO
DOCUMENTO
Tipo de documento que se va a incluir y solicita al
usuario el Nombre del Tipo de Documento.
botón incluir.
6. El sistema almacena el nuevo tipo de documento.
Caso de Uso Modificar Tipo Documento
Figura Nº 49 Diagrama del Caso de Uso Modificar Tipo Documento
RED
Modificar Tipo Documento
Secretaria de la
Unidad

122
Caso de Uso Modificar Tipo Documento
Descripción Modificación del nombre de un Tipo de Documento.
Pre Condiciones
Entrar al caso de uso Modificar Tipo de Documento.
Post Condiciones
usuario.
Flujo Principal
“Tipo Documento”.
2. El sistema despliega un catálogo con los tipos de
documentos almacenados
3. El usuario selecciona del catálogo el tipo de
documento a Modificar.
Tipo de Documento a modificar.
5. El usuario modifica el nombre del tipo de
documento y pulsa botón modificar.
Caso de Uso Eliminar Tipo Documento
Figura Nº 50 Diagrama del Caso de Uso Eliminar Tipo Documento
RED
Eliminar Tipo Documento
Secretaria de la
Unidad

123
Caso de Uso Eliminar Tipo Documento
Descripción
Eliminación de un Tipo de documento que se
encuentra almacenado en el sistema.
Pre Condiciones
Entrar al caso de uso Eliminar Estado.
Post Condiciones
usuario.
Flujo Principal
“Tipo Documento”.
documento a Eliminar.
tipo de documento a eliminar.
el botón eliminar.
Caso de Uso Buscar Tipo Documento
Figura Nº 51 Diagrama del Caso de Uso Buscar Tipo Documento
RED
Buscar Tipo Documento
Secretaria de la
Unidad

124
Caso de Uso Buscar Tipo Documento
Descripción
Recupera de la Base de Dato un Tipo de
documento.
Pre Condiciones
Entrar al caso de uso Buscar Tipo de Documento.
Post Condiciones
usuario.
Flujo Principal
“Tipo Documento.
3. El usuario escoge el Tipo de documento que
desea visualizar
4. El sistema muestra en pantalla los datos del tipo
de documento seleccionado.
Caso de Uso Incluir Entidad
Figura Nº 52 Diagrama del Caso de Uso Incluir Entidad
RED
Incluir Entidad
Secretaria de la
Unidad

125
Caso de Uso Incluir Entidad
Descripción
Inclusión del nombre, descripción, otra
identificación, descripción, tipo de entidad, estado y
el status de una Entidad.
Pre Condiciones
Entrar al caso de uso Incluir Entidad.
El sistema proporciona el Código de la Entidad.
Post Condiciones
usuario.
Flujo Principal
selecciona la opción “Entidades”
2. La aplicación abre la ventana ENTIDADES
4. El sistema genera automáticamente el código de
la entidad que se va a incluir y solicita al usuario el
Nombre, Descripción, Tipo de Entidad, Estado y el
Status de una Entidad
botón incluir.
6. El sistema almacena la nueva entidad.
Caso de Uso Modificar Entidad
Figura Nº 53 Diagrama del Caso de Uso Modificar Entidad
RED
Modificar Entidad
Secretaria de la
Unidad

126
Caso de Uso Modificar Entidad
Descripción
Modificación del nombre, Descripción, Tipo de
Entidad, Estado y el Status de una Entidad.
Pre Condiciones
Entrar al caso de uso Modificar Entidad.
Post Condiciones
usuario.
Flujo Principal
“Entidades”.
2. El sistema despliega un catálogo con las
entidades almacenadas
3. El usuario selecciona del catálogo la entidad a
Modificar.
4. La aplicación muestra en pantalla el Nombre,
Descripción, Tipo de Entidad, Estado y el Status de
una Entidad a modificar.
5. El usuario modifica el nombre Descripción, Tipo
de Entidad, Estado y el Status de una Entidad y
pulsa botón modificar.
Caso de Uso Eliminar Entidad
Figura Nº 54 Diagrama del Caso de Uso Eliminar Entidad
RED
Eliminar Entidad
Secretaria de la
Unidad

127
Caso de Uso Eliminar Entidad
Descripción
Eliminación de una Entidad que se encuentra
Pre Condiciones
Entrar al caso de uso Eliminar Entidad.
Post Condiciones
usuario.
Flujo Principal
“Entidades”.
3. El usuario selecciona del catálogo la entidad a
Eliminar.
4. La aplicación muestra en pantalla los datos de la
entidad a eliminar.
el botón eliminar.
Caso de Uso Buscar Entidad
Figura Nº 55 Diagrama del Caso de Uso Buscar Entidad
RED
Buscar Entidad
Secretaria de la
Unidad

128
Caso de Uso Buscar Entidad
Descripción Recupera de la Base de Dato una Entidad.
Pre Condiciones
Entrar al caso de uso Buscar Entidad.
Post Condiciones
usuario.
Flujo Principal
“Entidades”.
entidades almacenadas.
3. El usuario escoge la Entidad que desea visualizar
4. El sistema muestra en pantalla los datos de la
Entidad seleccionada.
Caso de Uso Incluir Tipo Entidad
Figura Nº 56 Diagrama del Caso de Uso Tipo Entidad
Caso de Uso Incluir Tipo Entidad
Descripción Inclusión del nombre de un tipo de entidad.
Pre Condiciones
Entrar al caso de uso Incluir Tipo Entidad.
El sistema proporciona el Código del Tipo de
Entidad.
Post Condiciones
usuario.
Flujo Principal
selecciona la opción “Tipo Entidades”
2. La aplicación abre la ventana TIPO DE
ENTIDADES
RED
Incluir Tipo Entidad
Secretaria de la
Unidad

129
tipo de entidad que se va a incluir y solicita al
usuario el Nombre de un Tipo de Entidad
botón incluir.
6. El sistema almacena el nuevo tipo de entidad.
Caso de Uso Modificar Tipo Entidad
Figura Nº 57 Diagrama del Caso de Uso Modificar Tipo Entidad
Caso de Uso Modificar Tipo Entidad
Descripción Modificación del nombre de un tipo de Entidad.
Pre Condiciones
Entrar al caso de uso Modificar Tipo Entidad.
Post Condiciones
usuario.
Flujo Principal
“Tipo Entidades”.
2. El sistema despliega un catálogo con los Tipos
de entidades almacenadas
entidad a Modificar.
tipo de Entidad a modificar.
5. El usuario modifica el nombre de un tipo de
Entidad y pulsa botón modificar.
RED
Modificar Tipo Entidad
Secretaria de la
Unidad

130
Caso de Uso Eliminar Tipo Entidad
Figura Nº 58 Diagrama del Caso de Uso Tipo Entidad
Caso de Uso Eliminar Tipo Entidad
Descripción
Eliminación de un Tipo de Entidad que se encuentra
Pre Condiciones
Entrar al caso de uso Eliminar Tipo Entidad.
Post Condiciones
usuario.
Flujo Principal
entidad a Eliminar.
tipo de entidad a eliminar.
el botón eliminar.
RED
Eliminar Tipo Entidad
Secretaria de la
Unidad

131
Caso de Uso Buscar Tipo Entidad
Figura Nº 59 Diagrama del Caso de Uso Buscar Tipo Entidad
Caso de Uso Buscar Tipo Entidad
Descripción Recupera de la Base de Dato un Tipo de Entidad.
Pre Condiciones
Entrar al caso de uso Buscar Tipo Entidad.
Post Condiciones
usuario.
Flujo Principal
2. El sistema despliega un catálogo con los Tipos de
entidades almacenadas.
3. El usuario escoge el Tipo de Entidad que desea
visualizar
4. El sistema muestra en pantalla los datos del tipo
de Entidad seleccionado.
RED
Buscar Tipo Entidad
Secretaria de la
Unidad

132
Caso de Uso Incluir Archivo
Figura Nº 60 Diagrama del Caso de Uso Incluir Archivo
Caso de Uso Incluir Archivo
Descripción
Inclusión del Nombre, Descripción, Ubicación, Tipo
de Archivo y Persona Responsable de un Archivo.
Pre Condiciones
Entrar al caso de uso Incluir Archivo.
El sistema proporciona el Código del Archivo.
Post Condiciones
usuario.
Flujo Principal
selecciona la opción “Archivo”
2. La aplicación abre la ventana ARCHIVADORES
archivo que se va a incluir y solicita al usuario el
Nombre, Descripción, Ubicación, Tipo de Archivo y
Persona Responsable de un Archivo
botón incluir.
6. El sistema almacena el nuevo archivo.
RED
Incluir Archivo
Secretaria de la
Unidad

133
Caso de Uso Modificar Archivo
Figura Nº 61 Diagrama del Caso de Uso Modificar Archivo
Caso de Uso Modificar Archivo
Descripción
Modificación del nombre, Descripción, Ubicación,
Tipo de Archivo y Persona Responsable de un
Archivo.
Pre Condiciones
Entrar al caso de uso Modificar Archivo.
Post Condiciones
usuario.
Flujo Principal
“Archivador”.
2. El sistema despliega un catálogo con los
archivos almacenados
3. El usuario selecciona del catálogo el archivo a
Modificar.
4. La aplicación muestra en pantalla el Nombre,
Descripción, Ubicación, Tipo de Archivo y Persona
Responsable de un Archivo a modificar.
5. El usuario modifica el nombre, Descripción,
Ubicación, Tipo de Archivo y Persona Responsable
de un Archivo y pulsa botón modificar.
RED
Modificar Archivo
Secretaria de la
Unidad

134
Caso de Uso Eliminar Archivo
Figura Nº 62 Diagrama del Caso de Uso Eliminar Archivo
Caso de Uso Eliminar Archivo
Descripción
Eliminación de un Archivo que se encuentra
Pre Condiciones
Entrar al caso de uso Eliminar Archivo.
Post Condiciones
usuario.
Flujo Principal
“Archivador”.
2. El sistema despliega un catálogo con los archivos
almacenados
3. El usuario selecciona del catálogo el archivo a
Eliminar.
archivo a eliminar.
el botón eliminar.
RED
Eliminar Archivo
Secretaria de la
Unidad

135
Caso de Uso Buscar Archivo
Figura Nº 63 Diagrama del Caso de Uso Buscar Archivo
Caso de Uso Buscar Archivo
Descripción Recupera de la Base de Dato un Archivo.
Pre Condiciones
Entrar al caso de uso Buscar Archivo.
Post Condiciones
usuario.
Flujo Principal
“Archivador”.
2. El sistema despliega un catálogo con los archivos
almacenados.
3. El usuario escoge el archivo que desea visualizar
archivo seleccionado.
RED
Buscar Archivo
Secretaria de la
Unidad

136
Caso de Uso Incluir Documento
Figura Nº 64 Diagrama del Caso de Uso Incluir Documento
Descripción
Inclusión del Tipo de Documento, Fecha de
Emisión, Fecha de Recepción, Descripción,
Resumen, Asunto, Archivo, Ubicación, Entidad que
lo Emite, Entidad que lo Recibe, Persona que lo
emite, Status, Número del documento y
Seguimiento de un Documento.
Pre Condiciones
Entrar al caso de uso Incluir Documento.
El sistema proporciona el Código del Documento.
Post Condiciones
usuario.
Flujo Principal
1. El usuario selecciona el Menú Procesos y
selecciona la opción “Documentos”
2. La aplicación abre la ventana DOCUMENTOS
documento que se va a incluir y solicita al usuario el
Tipo de Documento, Fecha de Emisión, Fecha de
Recepción, Descripción, Resumen, Asunto, Archivo,
Ubicación, Entidad que lo Emite, Entidad que lo
Recibe, Persona que lo emite, Status, Número del
documento y Seguimiento de un Documento
botón incluir.
6. El sistema almacena el nuevo documento.
RED
Incluir Documento
Secretaria de la
Unidad

137
Caso de Uso Modificar Documento
Figura Nº 65 Diagrama del Caso de Uso Modificar Documento
Descripción
Modificación del Tipo de Documento, Fecha de
Emisión, Fecha de Recepción, Descripción,
Seguimiento de un Documento
Pre Condiciones
Entrar al caso de uso Modificar Documento.
Post Condiciones
usuario.
Flujo Principal
“Documentos”.
3. El usuario selecciona del catálogo el documento
a Modificar.
4. La aplicación muestra en pantalla el Tipo de
Documento, Fecha de Emisión, Fecha de
Recepción, Descripción, Resumen, Asunto, Archivo,
Ubicación, Entidad que lo Emite, Entidad que lo
Recibe, Persona que lo emite, Status, Número del
documento y Seguimiento de un Documento a
modificar.
RED
Modificar Documento
Secretaria de la
Unidad

138
5. El usuario modifica el Tipo de Documento, Fecha
de Emisión, Fecha de Recepción, Descripción,
Seguimiento de un Documento y pulsa botón
modificar.
Caso de Uso Eliminar Documento
Figura Nº 66 Diagrama del Caso de Uso Eliminar Documento
Descripción
Eliminación de un Documento que se encuentra
Pre Condiciones
Entrar al caso de uso Eliminar Documento.
Post Condiciones
usuario.
Flujo Principal
“Documentos”.
RED
Eliminar Documento
Secretaria de la
Unidad

139
3. El usuario selecciona del catálogo el documento
a Eliminar.
documento a eliminar.
el botón eliminar.
Caso de Uso Buscar Documento
Figura Nº 67 Diagrama del Caso de Uso Buscar Documento
Descripción Recupera de la Base de Dato un Documento.
Pre Condiciones
Entrar al caso de uso Buscar Documento.
Post Condiciones
usuario.
Flujo Principal
“Documentos”.
3. El usuario escoge el documento que desea
visualizar
Documento seleccionado.
RED
Buscar Documento
Secretaria de la
Unidad

140
Caso de Uso Incluir Seguimiento
Figura Nº 68 Diagrama del Caso de Uso Incluir Seguimiento
Descripción
Inclusión de la Fecha de Seguimiento, Documento y
Descripción del Documento al que le va a realizar
un Seguimiento.
Pre Condiciones
Entrar al caso de uso Incluir Seguimiento.
El sistema proporciona el Código del Seguimiento.
Post Condiciones
usuario.
Flujo Principal
1. El usuario selecciona el Menú Procesos y
selecciona la opción “Seguimientos de Documentos”
2. La aplicación abre la ventana SEGUIMIENTO
seguimiento que se va a incluir y solicita al usuario
de la Fecha de Seguimiento, Documento y
Descripción del Documento al que le va a realizar
un Seguimiento
botón incluir.
6. El sistema almacena el nuevo seguimiento.
RED
Incluir Seguimiento
Secretaria de la
Unidad

141
Caso de Uso Modificar Seguimiento
Figura Nº 69 Diagrama del Caso de Uso Modificar Seguimiento
Descripción
Modificación de la Fecha de Seguimiento,
Documento y Descripción del Documento al que le
va a realizar un Seguimiento
Pre Condiciones
Entrar al caso de uso Modificar Seguimiento.
Post Condiciones
usuario.
Flujo Principal
“Seguimiento”.
seguimientos almacenados
3. El usuario selecciona del catálogo el seguimiento
a Modificar.
4. La aplicación muestra en pantalla de la Fecha de
Seguimiento, Documento y Descripción del
Documento al que le va a realizar un Seguimiento a
modificar.
5. El usuario modifica la Fecha de Seguimiento,
Documento y Descripción del Documento al que le
va a realizar un Seguimiento y pulsa botón
modificar.
RED
Modificar Seguimiento
Secretaria de la
Unidad

142
Caso de Uso Eliminar Seguimiento
Figura Nº 70 Diagrama del Caso de Uso Eliminar Seguimiento
Descripción
Eliminación de un Seguimiento que se encuentra
Pre Condiciones
Entrar al caso de uso Eliminar Seguimiento.
Post Condiciones
usuario.
Flujo Principal
“Seguimiento”.
seguimientos almacenados
3. El usuario selecciona del catálogo el seguimiento
a Eliminar.
seguimiento a eliminar.
el botón eliminar.
RED
Eliminar Seguimiento
Secretaria de la
Unidad

143
Caso de Uso Buscar Seguimiento
Figura Nº 71 Diagrama del Caso de Uso Buscar Seguimiento
Descripción Recupera de la Base de Dato un Seguimiento.
Pre Condiciones
Entrar al caso de uso Buscar Seguimiento.
Post Condiciones
usuario.
Flujo Principal
“Seguimientos”.
seguimientos almacenados.
3. El usuario escoge el seguimiento que desea
visualizar
Seguimiento seleccionado.
RED
Buscar Seguimiento
Secretaria de la
Unidad

144
Caso de Uso Generar Reporte Tipo de Documentos
Figura Nº 72 Diagrama del Caso de Uso Reporte Tipo de Documento
Caso de Uso Generar reporte de Tipos de Documentos
Descripción
Genera y visualiza un archivo con extensión .PDF que
lista los tipos de documentos que están almacenados
en el sistema.
Actores Secretaria de la Unidad Académica (Iniciador).
Pre Condiciones
Entrar al caso de uso Generar Reporte Tipos de
Documentos
Post Condiciones
usuario del Sistema sobre el reporte indicado.
Flujo Principal
1. La aplicación muestra la ventana de “Reporte de
Tipos de Documento”
2. El usuario presiona el botón Ver
3. El sistema genera un archivo PDF que contiene
todos los tipos de documentos que están
almacenados y lo muestra en una ventana.
RED
Generar Reporte Tipo de
Documentos
Secretaria de la
Unidad

145
Caso de Uso Generar Reporte Tipo de Entidades
Figura Nº 73 Diagrama del Caso de Uso Reporte Tipo de Entidades
Caso de Uso Generar Reporte de Tipo de Entidades
Descripción
lista los tipos de entidades que están almacenados en
el sistema.
Pre Condiciones
Entrar al caso de uso Generar Reporte Tipos de
Entidades
Post Condiciones
Flujo Principal
Tipos de Entidades”
todos los tipos de entidades que están almacenados y
lo muestra en una ventana.
RED
Generar Reporte Tipo de
Entidades
Secretaria de la
Unidad

146
Caso de Uso Generar Reporte Estados
Figura Nº 74 Diagrama del Caso de Uso Reporte Estados
Caso de Uso Generar Reporte Estados
Descripción
lista los estados que están almacenados en el
sistema.
Pre Condiciones Entrar al caso de uso Generar Reporte Estados
Post Condiciones
Flujo Principal
Estados”
todos los Estados que están almacenados y lo
muestra en una ventana.
RED
Generar Reporte Estados
Secretaria de la
Unidad

147
Caso de Uso Generar Reporte Entidades
Figura Nº 75 Diagrama del Caso de Uso Reporte Entidades
Caso de Uso Generar Reporte Entidades
Descripción
lista las entidades que están almacenadas en el
sistema.
Pre Condiciones Entrar al caso de uso Generar Reporte Entidades
Post Condiciones
Flujo Principal
Entidades”
todas las entidades que están almacenadas y lo
RED
Generar Reporte Entidades
Secretaria de la
Unidad

148
Caso de Uso Generar Reporte de Documentos
Figura Nº 76 Diagrama del Caso de Uso Reporte de Documentos
Caso de Uso Generar Reporte de Documentos
Descripción
Produce reportes por pantalla y con extensión .PDF
de los documentos, dependiendo de la opción elegida
por el usuario, ellos pueden ser por Período de
Tiempo (Desde – Hasta), Tipo de documento, Emisión
y/o Recepción, Entidad que Recibe y Emite, Palabra
clave, Tipo de Entidad, Estado o por el Status de la
Entidad.
Pre Condiciones Entrar al caso de uso Reporte de Documentos
Post Condiciones
Flujo Principal
1. La aplicación muestra una ventana donde se
visualizan diferentes filtros por los que el usuario
puede seleccionar la información que desea que
aparezca en el reporte
2. El usuario selecciona los filtros según su necesidad
y presiona el botón Ver.
3. El sistema muestra en una ventana el archivo PDF
del reporte solicitado.
RED
Generar Reporte de Documentos
Secretaria de la
Unidad

149
Caso de Uso Generar Reporte Archivadores
Figura Nº 77 Diagrama del Caso de Uso Reporte Archivadores
Caso de Uso Generar Reporte Archivadores
Descripción
lista los archivos que están almacenados en el
sistema.
Pre Condiciones Entrar al caso de uso Generar Reporte Archivadores
Post Condiciones
Flujo Principal
Archivos”
todos los archivos que están almacenados y lo
RED
Generar Reporte Archivadores
Secretaria de la
Unidad

150
Caso de Uso Incluir Sistema
Figura Nº 78 Diagrama del Caso de Uso Incluir Sistema
Caso de Uso Incluir Sistema
Descripción
Inclusión de la Descripción, Carpeta y Página que
contendrá el sistema además de los menús,
opciones y botones que lo conforman.
Actores Administrador del sistema (Iniciador)
Pre Condiciones
Entrar al caso de uso Incluir Sistema.
El sistema proporciona el Código del Sistema.
Post Condiciones
usuario.
Flujo Principal
selecciona la opción “Sistemas”
2. La aplicación abre la ventana SISTEMAS
sistemas que se va a incluir y solicita al usuario de
la Descripción, Carpeta y Página que contendrá el
sistema y de los menús, opciones y botones que lo
conforman
botón incluir.
6. El sistema almacena el nuevo sistema.
RED
Incluir Sistema
Secretaria de la
Unidad

151
Caso de Uso Modificar Sistema
Figura Nº 79 Diagrama del Caso de Uso Modificar Sistema
Caso de Uso Modificar Sistema
Descripción
Modificación de la Descripción, Carpeta y Página
que contendrá el sistema además de los menús,
opciones y botones que lo conforman
Actores Administrador del sistema. (Iniciador)
Pre Condiciones
Entrar al caso de uso Modificar Sistema.
Post Condiciones
usuario.
Flujo Principal
“Sistemas”.
sistemas almacenados
3. El usuario selecciona del catálogo el sistema a
Modificar.
4. La aplicación muestra en pantalla de la
Descripción, Carpeta y Página que contendrá el
sistema además de los menús, opciones y botones
a modificar.
5. El usuario modifica de la Descripción, Carpeta y
Página que contendrá el sistema además de los
menús, opciones y botones y pulsa botón modificar.
RED
Modificar Sistema
Secretaria de la
Unidad

152
Caso de Uso Eliminar Sistema
Figura Nº 80 Diagrama del Caso de Uso Eliminar Sistema
Caso de Uso Eliminar Sistema
Descripción Eliminación de un Sistema (menús, opción o botón).
Actores Administrador del sistema (Iniciador).
Pre Condiciones Entrar al caso de uso Eliminar Sistema.
Post Condiciones
usuario.
Flujo Principal
“Sistemas”.
sistemas (menús, opción o botón) almacenados
3. El usuario selecciona del catálogo el sistema
(menús, opción o botón) a Eliminar.
sistema (menús, opción o botón) a eliminar.
el botón eliminar.
RED
Eliminar Sistema
Secretaria de la
Unidad

153
Caso de Uso Buscar Sistema
Figura Nº 81 Diagrama del Caso de Uso Buscar Sistema
Caso de Uso Buscar Sistema
Descripción Recupera de la Base de Dato un Sistema.
Actores Administrador del Sistema (Iniciador).
Pre Condiciones Entrar al caso de uso Buscar Sistema.
Post Condiciones
administrador.
Flujo Principal
“Sistemas”.
sistemas (menús, opciones y botones)
almacenados.
3. El usuario escoge el sistema que desea visualizar
sistema seleccionado.
RED
Buscar Sistema
Secretaria de la
Unidad

154
Caso de Uso Incluir Perfil Usuario
Figura Nº 82 Diagrama del Caso de Uso Incluir Perfil Usuario
Caso de Uso Incluir Perfil Usuario
Descripción
Inclusión de la Descripción y del sistema que va a
manejar un usuario.
Pre Condiciones
Entrar al caso de uso Incluir Perfil Usuario.
El sistema proporciona el Código del Perfil del
Usuario.
Post Condiciones
administrador
Flujo Principal
selecciona la opción “Perfiles de Usuarios”
2. La aplicación abre la ventana PERFILES DE
USUARIOS
perfil de usuario y solicita al usuario de la
Descripción y del sistema que va a manejar
botón incluir.
6. El sistema almacena el nuevo perfil de usuario.
RED
Incluir Perfil Usuario
Secretaria de la
Unidad

155
Caso de Uso Modificar Perfil Usuario
Figura Nº 83 Diagrama del Caso de Uso Modificar Perfil Usuario
Caso de Uso Modificar Perfil Usuario
Descripción
Modificación de la Descripción y el sistema que
manejara un usuario.
Pre Condiciones Entrar al caso de uso Modificar Perfil Usuario.
Post Condiciones
administrador.
Flujo Principal
“Perfiles de Usuarios”.
2. El sistema despliega un catálogo con los perfiles
de usuarios almacenados
3. El usuario selecciona del catálogo el perfil de
usuario a Modificar.
Descripción y el sistema a modificar.
5. El usuario modifica de la Descripción y el sistema
y pulsa botón modificar.
RED
Modificar Perfil Usuario
Secretaria de la
Unidad

156
Caso de Uso Eliminar Perfil Usuario
Figura Nº 84 Diagrama del Caso de Uso Eliminar Perfil Usuario
Caso de Uso Eliminar Perfil Usuario
Descripción Eliminación de un Perfil Usuario.
Pre Condiciones Entrar al caso de uso Eliminar Perfil Usuario.
Post Condiciones
administrador.
Flujo Principal
3. El usuario selecciona del catálogo el perfil de
usuario a Eliminar.
perfil de usuario a eliminar.
el botón eliminar.
RED
Eliminar Perfil Usuario
Secretaria de la
Unidad

157
Figura Nº 85 Diagrama del Caso de Uso Buscar Perfil Usuario
Descripción Recupera de la Base de Dato un Perfil de Usuario.
Pre Condiciones Entrar al caso de uso Buscar Perfil Usuario.
Post Condiciones
administrador.
Flujo Principal
de usuarios almacenados.
3. El usuario escoge el perfil de usuario que desea
visualizar
4. El sistema muestra en pantalla los datos del perfil
de usuario seleccionado.
RED
Buscar Perfil Usuario
Secretaria de la
Unidad

158
Caso de Uso Incluir Cargo Usuario
Figura Nº 86 Diagrama del Caso de Uso Incluir Cargo Usuario
Caso de Uso Incluir Cargo Usuario
Descripción Inclusión de la Descripción del Cargo del Usuario.
Pre Condiciones
Entrar al caso de uso Incluir Cargo Usuario.
El sistema proporciona el Código del Cargo del
Usuario.
Post Condiciones
administrador
Flujo Principal
selecciona la opción “Cargos de Usuarios”
2. La aplicación abre la ventana CARGOS DE
USUARIOS
cargo de usuario y solicita al usuario la Descripción
del cargo de usuario
botón incluir.
6. El sistema almacena el nuevo cargo de usuario.
RED
Incluir Cargo Usuario
Secretaria de la
Unidad

159
Caso de Uso Modificar Cargo Usuario
Figura Nº 87 Diagrama del Caso de Uso Modificar Cargo Usuario
Caso de Uso Modificar Cargo Usuario
Descripción
Modificación de la Descripción del Cargo del
Usuario.
Pre Condiciones Entrar al caso de uso Modificar Cargo Usuario.
Post Condiciones
administrador.
Flujo Principal
“Cargos de Usuarios”.
2. El sistema despliega un catálogo con los cargos
3. El usuario selecciona del catálogo el cargo de
usuario a Modificar.
Descripción del cargo a modificar.
5. El usuario modifica de la Descripción del cargo y
RED
Modificar Cargo Usuario
Secretaria de la
Unidad

160
Caso de Uso Eliminar Cargo Usuario
Figura Nº 88 Diagrama del Caso de Uso Eliminar Cargo Usuario
Caso de Uso Eliminar Cargo Usuario
Descripción Eliminación de un Cargo de Usuario.
Pre Condiciones Entrar al caso de uso Eliminar Cargo Usuario.
Post Condiciones
administrador.
Flujo Principal
3. El usuario selecciona del catálogo el cargo de
usuario a Eliminar.
cargo de usuario a eliminar.
el botón eliminar.
RED
Eliminar Cargo Usuario
Secretaria de la
Unidad

161
Figura Nº 89 Diagrama del Caso de Uso Buscar Cargo Usuario
Descripción Recupera de la Base de Dato un Cargo de Usuario.
Pre Condiciones Entrar al caso de uso Buscar Cargo Usuario.
Post Condiciones
administrador.
Flujo Principal
de usuarios almacenados.
3. El usuario escoge el cargo de usuario que desea
visualizar
cargo de usuario seleccionado.
RED
Buscar Cargo Usuario
Secretaria de la
Unidad

162
Caso de Uso Incluir Usuario
Figura Nº 90 Diagrama del Caso de Uso Incluir Usuario
Caso de Uso Incluir Usuario
Descripción
Inclusión del Usuario, Nombre, Apellido, Cargo,
contraseña y Confirmación de Contraseña.
Pre Condiciones
Entrar al caso de uso Incluir Usuario.
El sistema proporciona el Código del Usuario.
Post Condiciones
administrador
Flujo Principal
selecciona la opción “Usuarios”
2. La aplicación abre la ventana USUARIOS
usuario y solicita Usuario, Nombre, Apellido, Cargo,
contraseña y Confirmación de Contraseña que se
va incluir
botón incluir.
6. El sistema almacena el nuevo usuario.
RED
Incluir Usuario
Secretaria de la
Unidad

163
Caso de Uso Modificar Usuario
Figura Nº 91 Diagrama del Caso de Uso Modificar Usuario
Caso de Uso Modificar Usuario
Descripción
Modificación del Usuario, Nombre, Apellido, Cargo,
Contraseña y confirmación de un Usuario.
Pre Condiciones Entrar al caso de uso Modificar Usuario.
Post Condiciones
administrador.
Flujo Principal
“Usuarios”.
usuarios almacenados
3. El usuario selecciona del catálogo el usuario a
Modificar.
4. La aplicación muestra en pantalla el Usuario,
Nombre, Apellido, Cargo, Contraseña y
confirmación de un Usuario a modificar.
5. El usuario modifica el Usuario, Nombre, Apellido,
Cargo, Contraseña y confirmación de un Usuario y
RED
Modificar Usuario
Secretaria de la
Unidad

164
Caso de Uso Eliminar Usuario
Figura Nº 92 Diagrama del Caso de Uso Eliminar Usuario
Caso de Uso Eliminar Usuario
Descripción Eliminación de un Usuario.
Pre Condiciones Entrar al caso de uso Eliminar Usuario.
Post Condiciones
administrador.
Flujo Principal
“Usuarios”.
2. El sistema despliega un catálogo con los usuarios
almacenados
3. El usuario selecciona del catálogo el usuario a
Eliminar.
usuario a eliminar.
el botón eliminar.
RED
Eliminar Usuario
Secretaria de la
Unidad

165
Figura Nº 93 Diagrama del Caso de Uso Buscar Usuario
Descripción Recupera de la Base de Dato un Usuario.
Pre Condiciones Entrar al caso de uso Buscar Usuario.
Post Condiciones
administrador.
Flujo Principal
“Usuarios”.
2. El sistema despliega un catálogo con los usuarios
almacenados.
3. El administrador escoge el usuario que desea
visualizar
usuario seleccionado.
RED
Buscar Usuario
Secretaria de la
Unidad

166
Figura Nº 94 Modelo General del Diagrama de Casos de Uso de RED
RED
Secretaria de la
Unidad
Incluir Estado
Modificar Estado
Eliminar Estado
Buscar Estado
Incluir Tipo Documento
Modificar Tipo Documento
Eliminar Tipo Documento
Buscar Tipo Documento
Incluir Entidad
Modificar Entidad
Eliminar Entidad
Buscar Entidad
Incluir Tipo Entidad
Modificar Tipo Entidad
Eliminar Tipo Entidad
Buscar Tipo Entidad
Incluir Archivo
Modificar Archivo
Eliminar Archivo
Buscar Archivo
Incluir Documento
Modificar Documento

167
Continuación del Modelo General del Diagrama de Casos de Uso de RED
RED
Eliminar Documento
Buscar Documento
Incluir Seguimiento
Modificar Seguimiento
Eliminar Seguimiento
Buscar Seguimiento
Generar reporte Tipo Documento
Generar reporte Tipo Entidades
Generar reporte Estados
Generar reporte Entidades
Generar reporte Listado de Documentos
Generar reporte Archivo
Ingresar Sistema
Modificar Sistema
Eliminar Sistema
Buscar Sistema
Incluir Perfil Usuario
Modificar Perfil Usuario
Eliminar Perfil Usuario
Buscar Perfil Usuario
Incluir Cargo Usuario
Modificar Cargo Usuario
Eliminar Cargo Usuario
Buscar Cargo Usuario
Administrador del
sistema
Secretaria de la
Unidad

168
Continuación del Modelo General del Diagrama de Casos de Uso de RED
Diseño
Modelo de Datos
El modelo de datos está representado por el diagrama de clases orientado a
visualizar el todo como un conjunto de elementos que se relacionan entre sí. RED
fue dividido en dos módulos (Seguridad y Control de Documentos). El módulo
Seguridad será manejado directamente por el administrador del sistema, mientras
que el de Control de documentos es el que utilizará el usuario. A continuación
definiremos el diagrama de clases para ambos módulos de RED:
RED
Incluir Usuario
Modificar Usuario
Eliminar Usuario
Buscar Usuario
Administrador del
sistema

169
Diagrama de Clases con sus Atributos que forman a RED
(Módulo Control de Documentos)
Usa
Usa
Usa
Usa
Usa
Usa
Figura Nº 95 Diagrama de Clases (Módulo Control de Documentos)
Clase Estado
CódigoEstado
NombredelEstado
Clase Entidad
CódigoEntidades
NombreEntidades
OtraIdentificación
Descripción
CódigoTipodeEntidad
CódigoEstado
StatusdelaEntidad
Clase Tipo Entidad
CódigoTipodeEntidad
NombreTipodeEntidad
Clase Documento
CódigodelDocumento
NombreTipodeDocumento
FechadeEmisióndelDocumento
FechadeRecepcióndelDocumento
DescripcióndelDocumento
ResumendelDocumento
AsuntodelDocumento
CódigoArchivo
UbicacióndelDocumentoenelArchivo
CodigoEntidadqueRecibeelDocumento
CodigoEntidadqueEmiteelDocumento
PersonaqueemiteelDocumento
StatusdelDocumento
NúmerodelDocumento
SeguimientodelDocumento
Clase Archivo
CódigoArchivo
NombreArchivo
DescripciónArchivo
UbicaciónArchivo
TipodeArchivo
PersonaResponsable
Clase Seguimiento
CódigodelSeguimiento
FechadelSeguimiento
CódigodelDocumento
DescripcióndelSeguimiento
Clase Tipo Documento
CódigoTipodeDocumento
NombreTipodeDocumento

170
Diagrama de Clases con sus Atributos que forman a RED
(Módulo Seguridad)
Usa
Usa
Usa
Usa
Figura Nº 96 Diagrama de Clases (Módulo Seguridad)
Clase Perfil de Usuario
CódigodelPerfildeUsuario
DescripcióndelPerfildeUsuarioClase Usuario
Usuario
NombredelUsuario
ApellidodelUsuario
CódigodelCargodelUsuario
ContraseñadelUsuario
ConfirmacióndelaContraseñadelUsuario
CódigodelSistema
CódigodelPerfildelUsuario
Clase Cargo de Usuario
CódigodelCargodeUsuario
DescripcióndelCargodeUsuario
Clase Sistema
CódigodelSistema
DescripcióndelSistema
CarpetadondesealmacenaráelSistema
PáginadeIniciodelSistema
Clase Característica Sistema
CódigodelSistema
DescripciónOpciones
NivelOpción
PáginaOpción
TipoOpción
CódigoOpción
NúmeroFila

171
Diagrama de Clases del Módulo Control de Documentos usando estereotipos
Usa
Clase Estados
Usa
Clase Entidades Clase Tipo de Entidades
Usa Clase Tipo de Documento
Usa
Usa
Clase Archivo
Usa
Clase Documentos
Clase Seguimiento
Figura Nº 97 Diagrama de Clases usando estereotipos (Módulo Control de Documentos)
Diagrama de Clases del Módulo Seguridad usando estereotipos
Usa
Usa Clase Característica Sistema
Clase Sistemas
Usa Clase Perfiles de Usuarios
Clase Usuarios Usa
Clase Cargos de Usuarios
Figura Nº 98 Diagrama de Clases (Módulo Seguridad)

172
Diagrama de Estado de RED
El estado de un sistema de información computarizado es un conjunto
particular de valores de los atributos de ese sistema. A menudo el estado del
sistema se representa mediante una pantalla específica. Cada evento provoca
que el sistema se mueva de estado a estado. Los siguientes diagramas
representan los estados de RED:

173
Figura Nº 99 Diagrama de Estados (Módulo Control de Documentos)
Definiciones
TIPO
ENTIDADES
Definiciones
ENTIDADES
Definiciones
ARCHIVO
Procesos
DOCUMENTOS
Procesos
SEGUIMIENTOS
Reportes
Tipo de
Documentos
Tipo de
Entidades
Estados
Listado de
documentos
Archivos
Definiciones
TIPO
DOCUMENTO
Definiciones
ESTADOS
Ciclo del sistema Recepción y Emisión de Documentos (Módulo Control de Documentos)
Incluir,
Modificar,
Eliminación y
Búsqueda de
Estados
Incluir,
Modificar,
Eliminación y
Búsqueda de
Tipo de
Documento
Incluir,
Modificar,
Eliminación y
Búsqueda de
Tipo de
Entidades
Incluir,
Modificar,
Eliminación y
Búsqueda de
Entidades
Incluir,
Modificar,
Eliminación y
Búsqueda de
Archivos
Incluir,
Modificar,
Eliminación y
Búsqueda de
Documentos
Incluir,
Modificar,
Eliminación y
Búsqueda de
Seguimientos
Generar un
reporte
solicitado
Salir
seleccionado

174
Figura Nº 100 Diagrama de Estados (Módulo Seguridad)
Definiciones
Perfiles de
Usuario
Definiciones
Cargos de
Usuarios
Definiciones
Sistemas
Definiciones
Usuarios
Ciclo del Sistema Recepción y Emisión de Documentos (Módulo Seguridad)
Incluir,
Modificar,
Eliminación y
Búsqueda de
Sistemas.
Incluir,
Modificar,
Eliminación y
Búsqueda de
Perfiles de
Usuario
Incluir,
Modificar,
Eliminación y
Búsqueda de
Cargos de
Usuario
Incluir,
Modificar,
Eliminación y
Búsqueda de
Usuarios
Salir
seleccionado

Para efectos de esta Práctica Profesional los Diagramas de Secuencia se
delimitaron en desarrollar los Casos de Uso Incluir documentos, Modificar
Documentos, Eliminar Documentos, Buscar Documentos, Incluir
Seguimiento, Eliminar Seguimiento, Modificar Seguimiento, Buscar
Seguimiento y Reporte Documento, debido a que son los más funcionales y
en donde se encuentra la esencia de esta aplicación Web, además porque la
Metodología Utilizada (RUP) es incremental e Iterativa.
A continuación se listan los elementos contenidos en los Diagramas de
secuencia de RED (clases, interfaces y algoritmos), para representarlos se
utilizarán los siguientes estereotipos:
Interfaz Algoritmo Clase
 Interfaces:
- Interfaz Documentos.
- Interfaz Seguimientos.
- Interfaz Reportes.
 Clases:
- Clase Documento
- Clase Seguimiento
 Algoritmos:
- Incluir Documento.
- Modificar Documento.
- Eliminar Documento.
- Buscar Documento.
- Incluir Seguimiento.

- Modificar Seguimiento.
- Eliminar Seguimiento.
- Buscar Seguimiento.
- Generar Reporte Documentos.
El diagrama de secuencia es uno de los diagramas más efectivos para
modelar interacción entre objetos. En este caso para RED muestra la
interacción de un conjunto de objetos en la aplicación a través del tiempo.
Figura Nº 101 Diagrama de Secuencia del Caso de Uso Incluir Documento
1. Seleccionar el Menú PROCESOS
USUARIO
2. Escoger la opción DOCUMENTOS
Interfaz
Documentos
Incluir
Documento
Clase
Documento
3. Pulsar el botón NUEVO
6. Transferir los datos
5. Pulsar el botón INCLUIR 8. Crea nuevo documento
11. Muestra Reconocimiento
4. Incluir datos del nuevo documento
9. Enviar reconocimiento

Figura Nº 102 Diagrama de Secuencia del Caso de Uso Modificar Documento
USUARIO
Interfaz
Documentos
Modificar
Documento
Clase
Documento
3. Pulsar el botón Buscar
4. Recuperar datos de todos los
documentos
7. Seleccionar un código de
documento 9. Buscar el documento
seleccionado
16. Mostrar
reconocimiento
6. Mostrar catálogo con todos los
documentos
5. Regresar datos de todos los
documentos
8. Transferir el código del
documento seleccionado
10. Regresar documento
seleccionado
11. Mostrar información del
documento
12. Editar datos del documento y
pulsa el botón Modificar 13. Transferir datos del
documento
14. Solicita actualización
10. Transferir datos del

Figura Nº 103 Diagrama de Secuencia del Caso de Uso Eliminar Documento
USUARIO
Clase Interfaz
Documentos
Eliminar
Documento
Documento
documentos
seleccionado
16. Mostrar
reconocimiento
documentos
documentos
seleccionado
documento
12. Visualizar datos del documento y
pulsa el botón Eliminar 13. Transferir orden del
eliminar documento
14. Eliminar documento

Figura Nº 104 Diagrama de Secuencia del Caso de Uso Buscar Documento
USUARIO
Clase Interfaz
Documentos
Buscar
Documento
Documento
documentos
seleccionado
documentos
documentos
seleccionado
documento

Figura Nº 105 Diagrama de Secuencia del Caso de Uso Incluir Seguimiento
USUARIO
2. Escoger la opción SEGUIMIENTO DE DOCUMENTOS
Clase Interfaz
Seguimiento
Incluir
Seguimiento
Seguimiento
3. Pulsar el botón NUEVO
6. Transferir los datos
5. Pulsar el botón INCLUIR 8. Crea nuevo seguimiento
11. Muestra Reconocimiento
4. Incluir datos del nuevo documento

Figura Nº 106 Diagrama de Secuencia del Caso de Uso Modificar Seguimiento
USUARIO
2. Escoger la opción Seguimiento de Documentos
Clase Interfaz
Seguimiento
Modificar
Seguimiento
Seguimiento
seguimientos
seguimiento 9. Buscar el seguimiento
seleccionado
16. Mostrar
reconocimiento
seguimientos
seguimientos
seguimiento seleccionado
10. Regresar seguimiento
seleccionado
seguimiento
12. Editar datos del seguimiento y
pulsa el botón Modificar 13. Transferir datos del
seguimiento
14. Solicita actualización

Figura Nº 107 Diagrama de Secuencia del Caso de Uso Eliminar Seguimiento
USUARIO
2. Escoger la opción Seguimientos de Documentos
Clase Interfaz
Seguimiento
Eliminar
Seguimiento
Seguimiento
seguimientos
seleccionado
16. Mostrar
reconocimiento
seguimientos
seguimientos
seleccionado
seguimiento
12. Visualizar datos del seguimiento
y pulsa el botón Eliminar 13. Transferir orden del
eliminar seguimiento
14. Eliminar seguimiento

Figura Nº 108 Diagrama de Secuencia del Caso de Uso Buscar Seguimiento
USUARIO
2. Escoger la opción SEGUIMIENTOS DE DOCUMENTOS
Clase Interfaz
Seguimiento
Buscar
Seguimiento
Seguimiento
seguimientos
seleccionado
seguimientos
seguimientos
seleccionado
seguimiento

Caso de Uso Reporte Documento
Figura Nº 109 Diagrama de Secuencia del Caso de Uso Reporte de Documentos
1. Selecciona el Menú REPORTES
USUARIO
2. Escoge la opción DOCUMENTOS
Clase Interfaz
Reporte
Documentos
Reporte
Documento
Documentos
4. Transfiere los datos
7. Selecciona uno o varios filtros
9. Se busca el documento
en la base de Datos
6. se despliega una pantalla con los
filtros por los cuales se puede
solicitar un reporte de documento
5. Regresa información
8. Transfiere los datos
10. Regresa información11. Se abre una pantalla con el
reporte solicitado en un archivo PDF

Asignación de Operaciones a las Clases (Control de Documentos)
Usa
Usa
Usa
Usa
Usa
Usa
Clase Estado
CódigoEstado, 10 caracteres
NombredelEstado, 20 caracteres
.IncluirunEstado ()
EliminarunEstado ()
ModificarunEstado ()
BuscarunEstado ()
Clase Entidad
CódigoEntidades, 10 caracteres
NombreEntidades, 40 caracteres
OtraIdentificación, 25 caracteres
Descripción, texto
CódigoTipodeEntidad, 10 caracteres
CódigoEstado, 10 caracteres
StatusdelaEntidad, 30 caracteres
IncluirunaEntidad ()
EliminarunaEntidad ()
ModificarunaEntidad ()
BuscarunaEntidad ()
Clase Tipo Entidad
CódigoTipodeEntidad, 10 caracteres
NombreTipodeEntidad, 20 caracteres
IncluirunTipodeEntidad ()
EliminarunTipodeEntidad ()
ModificarunTipodeEntidad ()
BuscarunTipodeEntidad ()
Clase Archivo
CódigoArchivo, 10 caracteres
NombreArchivo, 20 caracteres
DescripciónArchivo, texto
UbicaciónArchivo, texto
TipodeArchivo, 25 caracteres
PersonaResponsable, 30 caracteres
IncluirunArchivo ()
EliminarunArchivo()
ModificarunArchivo()
BuscarunArchivo ()
Clase Documento
CódigodelDocumento, 10 caracteres
NombreTipodeDocumento, 10 caracteres
FechadeEmisióndelDocumento, Calendario
FechadeRecepcióndelDocumento, Calendario
DescripcióndelDocumento, Texto
ResumendelDocumento, Texto
AsuntodelDocumento, Texto
CódigoArchivo, 10 caracteres
UbicacióndelDocumentoenelArchivo, Texto
CodigoEntidadqueRecibeelDocumento, 10 caracteres
CodigoEntidadqueEmiteelDocumento, 10 caracteres
PersonaqueemiteelDocumento, 20 caracteres
StatusdelDocumento, 10 caracteres
NúmerodelDocumento, 10 caracteres
SeguimientodelDocumento, 5 caracteres
IncluirunDocumento ()
EliminarunDocumento()
ModificarunDocumento ()
BuscarunDocumento ()
Clase Tipo Documento
CódigoTipodeDocumento, 10 caracteres
NombreTipodeDocumento, 20 caracteres
IncluirunTipodeDocumento ()
EliminarunTipodeDocumento ()
ModificarunTipodeDocumento ()
BuscarunTipodeDocumento ()
Clase Seguimiento
CódigodelSeguimiento, 10 caracteres
FechadelSeguimiento, Calendario
CódigodelDocumento, 10 caracteres
DescripcióndelSeguimiento, texto
IncluirunSeguimiento ()
EliminarunSeguimiento ()
ModificarunSeguimiento ()
BuscarunSeguimiento ()

Asignación de Operaciones a las Clases (Módulo Seguridad)
Usa Usa
Usa
Usa
Clase Usuario
Usuario, 10 caracteres
NombredelUsuario, 20 caracteres
ApellidodelUsuario, 20 caracteres
CódigodelCargodelUsuario, 3 caracteres
ContraseñadelUsuario, 100 caracteres
ConfirmacióndelaContraseñadelUsuario, 100 caracteres
CódigodelSistema, 4 caracteres
CódigodelPerfildelUsuario, 4 caracteres
IncluirunUsuario ()
EliminarunUsuario ()
ModificarunUsuario ()
BuscarunUsuario ()
Clase Perfil de Usuario
CódigodelPerfildeUsuario, 4 caracteres
DescripcióndelPerfildeUsuario, 45 caracteres
IncluirunPerfildeUsuario ()
EliminarunPerfildeUsuario ()
ModificarunPerfildeUsuario ()
BuscarunPerfildeUsusario ()
Clase Cargo de Usuario
CódigodelCargodeUsuario, 4 caracteres
DescripcióndelCargodeUsuario, 30 caracteres
IncluirunCargodeUsuario ()
EliminarunCargodeUsuario ()
ModificarunCargodeUsuario ()
BuscarunCargodeUsuario ()
Clase Sistema
DescripcióndelSistema, 50 caracteres
CarpetaddelModulo, 50 caracteres
PáginadeIniciodelSistema, 50 caracteres
IncluirunSistema ()
EliminarunSistema ()
ModificarunSistema ()
BuscarunSistema ()
Clase Característica Sistema
DescripciónOpciones, 45 caracteres
NivelOpción, 10 caracteres
PáginaOpción, 100 caracteres
TipoOpción, 1 carácter
CódigoOpción, Entero
NúmeroFila, Entero
Operacionesquepermitiraalsistemasufuncionalidad (menus,
botones, opciones)

Diagrama de Despliegue
El siguiente diagrama describe las configuraciones de la red mediante
nodos. El nodo administrador estará compuesto por el sistema RED con su
respectiva configuración de administrador y será utilizado por el actor
administrador del sistema, mientras el nodo Cliente contendrá el sistema
configurado para el uso de clientes y será manipulado por los demás actores
del sistema.
Figura Nº110 Diagrama de Despliegue de RED
Diagrama de Base de Datos
El modelo de datos que utiliza RED es el modelo relacional.
Las tablas o relaciones necesarias para llevar a cabo los casos de uso
son: redmarchivador, redmentidades, redmestados, redmtipo_documento,
redmtipo_entidades, redpdocumentos, redpseguimientos, segtcsistemas,
RED

segtcusuarios, seftcperfilesdeusuarios y segtcargousuarios las cuales se
describen en la tabla Nº 7.
Tabla Nº 7 Descripción de las tablas de la Base de Datos
Tablas Entidad Descripción
Redmarchivador
Campo Key Valor Desc.
Cod_archi X Varchar(10) Código Archivo
Nom_archi Varchar(20) Nombre
Archivo
Desc_archi Text Descripción
Archivo
Des_ubi_archi Text Ubicación
Archivo
Tipo_archi Varchar(25) Tipo Archivo
(activo,Pasivo)
Perso_respon Varchar(30) Persona
Responsable
Esta tabla almacena los
archivadores que utilizará
el sistema. Posee una
clave principal.
redmtipo_entidades
cod_ti_entidad X Varchar(10) Código Tipo
Entidad
nom_ti_entidad Varchar(20) Nombre Tipo
Entidad
tipos de entidades que
utilizará el sistema.
Posee una clave
principal.
redmtipo_document
o
cod_ti_doc X Varchar(10) Código Tipo
Documento
nom_ti_doc Varchar(20) Nombre Tipo
Documento
tipos de documentos que
Posee una clave
principal.
Redmestados
cod_esta X Varchar(10) Código
Estado
nom_esta Varchar(20) Nombre
Estado
estados que utilizará el
sistema. Posee una
clave principal.
Redpseguimientos
cod_segui X Varchar(10) Código
Seguimiento
fec_segui Date Fecha del
Seguimiento
cod_docu 0 Varchar(10) Código del
Documento
desc_segui text Descripción
Seguimiento
seguimientos de los
documentos que utilizará
el sistema. Posee una
clave principal y una
foránea (0).
Campo Key Valor Desc. Esta tabla almacenará
las entidades que

Redmentidades
co_entidad X Varchar(10) Codigo
Entidad
nom_entidad Varchar(40) Nombre
Entidad
Cod_esta 0 Varchar(10) Código
Estado
Cod_ti_entidad 0 Varchar(10) Codigo Tipo
Entidad
Descri_entidad Text Descripción
Entidad
Stat_entidad Varchar(30) Status de la
Entidad
Id_entidad Varchar(25) Cédula
Posee una clave principal
y dos claves foráneas
(0).
Redpdocumentos
Cod_docu X Varchar(10) Código
Documento
Cod_ti_doc 0 Varchar(10) Código Tipo
documento
Fec_ori_docu Date FechaEmisio
n documento
Fec_rec_doc Date FechaRecep.
Documento
Descri_docu Text Descripción
Documento
Resu_docu Text Resumen
Documento
Asun_docu Text Asunto
Documento
Cod_archi 0 Varchar(10) Código
Archivo
Ubi_archi 0 Text Ubicación
Documento
Co_entidad_emit
e
0 Varchar(10) Código
Entidad Emite
Nom_pers_emi Varchar(20) Persona que
Emite
Stat_ti_docu Varchar(10) Status tipo
Documento
Num_docu Varchar(10) Número
Documento
Stat_segui 0 Varchar(5) Seguimiento
Si/No
Co_entidad_recib
e
0 Varchar(10) Código
Entidad Recib
Esta tabla almacenará
los documentos
(recibidos y/o emitidos)
que utilizará el sistema.
y cinco claves foráneas
(0).
Segtcsistemas Campo key Valor Desc.
Codsis X Varchar(4) Código Sistema
los sistemas (menús,
opciones, botones) que

Nomsis Varchar(50) Nombre Sistema
Pagini Varchar(50) Página Inicio
Nomcar Varchar(50) Nombre Cargo
Segtcusuarios Campo key Valor Desc.
Logusu X Varchar(10) Usuario
Pasusu Varchar(100) Clave
Nomusu Varchar(25) Nombre
Usuario
Apeusu Varchar(25) Apellido
Usuario
Codcar Varchar(3) Codigo Cargo
Nomfot Varchar(50) Nmbre Foto
Tipfot Varchar(20) Tipo Foto
Tamfot integer Tamaño Foto
datfot longblog Foto
los usuarios que pueden
manejar el sistema.
Segtcperfilesusuari
os
Campo key Valor Desc.
codper X Varchar(4) Código Perfil
nomper Varchar(45) Nombre Perfil
codsis Varchar(10) Código
Sistema
los perfiles de usuario.
Segtcargousuarios Campo key Valor Desc.
codcar X Varchar(3) Código Cargo
Nomcar Varchar(30) Nombre Cargo
los cargos de usuario.
En el modelo Entidad Relación que se presentará a continuación solo se
presentará el Módulo Control de Documentos, debido a que es el que
directamente manejará el Usuario.

Modelo Entidad Relación de RED

Podemos determinar que al finalizar la disciplina de diseño, hemos
refinado suficientemente el modelo de caso de uso, el diagrama de clase y
las relaciones entre estos para representar la mayor parte de los requisitos
del sistema.
Durante la siguiente disciplina entraremos en otro ciclo para mejorar
algunos detalles que se hacen visibles solo al momento de la
implementación.
Gestión del Proyecto
Escogencia del lenguaje de programación
Durante la ejecución de la Disciplina de Gestión del Proyecto se
escogió como lenguaje de programación PHP (Hipertext Pre-processor)
debido a que es un lenguaje de programación pensado para utilizarse en
desarrollos Web, por lo que es ideal para brindar mayor dinamismo a una
página Web y acceso a base de datos.
Como interfaz para la programación del lenguaje PHP se escogió el
Software Adobe Dreamweaver CS5 versión 11.0 (ver Fig. 110)

Figura Nº 111 Lenguaje de Programación utilizado para el desarrollo de la aplicación
Escogencia del Gestor de Base de Datos
Para la elaboración de la base de dato utilizada en RED se empleó el
gestor de base de datos MySQL ya que es un sistema de base de dato
relacional, multihilo y multiusuario para lo cual se utilizó la herramienta
gráfica del software MySQL Administrator versión 1.2.12, debido a que es
fácil de utilizar, compacta, ágil, funcional y muy rápida para manejar las base
de datos de MySQL como se observa en la figura Nº 112.

Figura Nº 112 Interfaz del entorno MySQL Administrator
Actividades de formación
Como actividades de formación para el desarrollo de aplicación
podemos mencionar las charlas dictadas por el tutor académico, lo que
llevaron a la mejor comprensión del lenguaje de programación utilizado y al
mejor desempeño en el manejo del Gestor de Base de Datos.

Recursos Adicionales
Cabe destacar que fue de suma importancia la exportación de librerías,
las cuales son útiles en cuanto a al montaje de las interfaces y de fácil
ejecución.
Implementación
El objetivo principal de este flujo de trabajo en RED es extender el
resultado al finalizar la iteración con la integración y pruebas del sistema, es
la versión operativa inicial representada por el 100% de los casos de uso, el
desarrollo de componentes y codificación del software, su relación con la
base de datos, integración de módulos y la explicación acerca de la
funcionalidades del sistema.
Desarrollo de componentes y codificación de Software
En esta parte de desarrollo de componentes y codificación de software,
extraeremos una parte del sistema, el componente que engloba
Documentos formados por reda_documentos.php, redn_documento.php,
redjdocumentos.js, redr_documentos.php, cls_documentos.php,
conaseguridadacceso.php, conaseguridad.php y conasuperior.php. (Ver
Anexo Nº 1)
Relación de los componentes con la Base de Datos

Los componentes se relacionan con las siguientes tablas por medio de las
siguientes llamadas:
require_once("clases/clstipo_documento.php"); mediante este
parámetro se relaciona con tabla tipo_documento
require_once("clases/clsarchivador.php"); mediante este parámetro
se relaciona con la tabla archivo
require_once("clsentidades.php"); se relaciona con la tabla entidades
require_once("clases/clstipo_entidades.php"); se relaciona con la
tabla tipo entidades.
insert nto
redpdocumentos(COD_DOCU,COD_TI_DOC,FEC_ORI_DOCU,FEC_REC_
DOCU,DESCRI_DOCU,RESU_DOCU,ASUN_DOCU,COD_ARCHI,UBI_DO
CU,CO_ENTIDAD_EMITE,CO_ENTIDAD_RECIBE,NOM_PERS_EMI,STAT_
TI_DOCU,NUM_DOCU,STAT_SEGUI)values('$this->COD_DOCU','$this-
>COD_TI_DOC',$this->FEC_ORI_DOCU,$this->FEC_REC_DOCU,'$this-
>DESCRI_DOCU','$this->RESU_DOCU','$this->ASUN_DOCU','$this-
>COD_ARCHI','$this->UBI_DOCU','$this->CO_ENTIDAD_EMITE','$this-
>CO_ENTIDAD_RECIBE','$this->NOM_PERS_EMI','$this-
>STAT_TI_DOCU','$this->NUM_DOCU','$this->STAT_SEGUI')"; se
relaciona con la tabla documentos
Integración de los módulos
La integración de los módulos será realizada mediante las siguientes
llamadas:
require_once("conaseguridad.php");

require_once("conaseguridadacceso.php");
require_once("conasuperior.php");
<script language="javascript" src="jsi/redjdocumentos.js"></script>
require_once("clases/cls_documentos.php");
Funcionalidades del Sistema
Para describir las funcionalidades del sistema a continuación se
presentan las diferentes interfaces de RED con una breve explicación de las
mismas:
Interfaz de Usuario
La interfaz de usuario es la forma en que los usuarios pueden
comunicarse con un computador y comprende todos los puntos de contacto
entre el usuario y el equipo, es la parte de una aplicación que el usuario ve y
con la cual interactúa, ello incluye las ventanas con sus elementos: barra de
desplazamiento, cajas de texto, combos, botones, menús, entre otros.
Interfaz de Acceso al Sistema RED
Esta interfaz es la primera que consigue el usuario al intentar ingresar al
sistema a través de la cual debe registrarse para obtener acceso, es
importante mencionar que los usuarios deben ser registrados mediante una
cuenta administradora. En la figura Nº 113 se muestra el prototipo de la

pantalla de acceso que le ofrecerá al usuario los campos necesarios para
introducir sus datos de identificación requeridos para poder acceder al
sistema, en donde:
 Usuario: es el nombre con el cual se identifica al usuario en el Sistema
 Contraseña: es la clave de seguridad perteneciente a cada usuario.
Figura Nº 113 Interfaz de Inicio de Sesión al Sistema RED
Una vez que el usuario ha introducido los datos de inicio de sesión
correctamente el sistema activa la interfaz principal del sistema, donde
encontrará el menú principal del sistema, el cual le permitirá acceder a cada
uno de los módulos que componen la aplicación (Módulo Seguridad y módulo
control de Documentos), dependiendo del perfil de usuario que posea. (Ver
Fig. 6.1.)

Interfaz General del Sistema RED
Esta interfaz es la que le permitirá al usuario realizar las diversas
opciones permitidas dependiendo de su privilegio una vez que obtenga el
acceso al sistema, La figura Nº 114 muestra la pantalla general a través de la
cual se enlazarán todas las interfaces disponibles
Figura Nº 114 Interfaz de Principal del Sistema RED
Menú para el Módulo Seguridad
Es el menú principal del sistema para el usuario Perfil Administrador, le
permite al usuario ver las diferentes acciones que puede realizar. Está
compuesto por una serie de botones con el nombre de cada módulo y

haciendo click sobre ellos mostrará las diferentes opciones que tienen cada
uno. (Ver Fig. 114)
Figura Nº 115 Interfaz del Menú del Módulo Seguridad
A continuación serán mostradas las interfaces de RED para las opciones
Sistemas, Cargos de Usuario, Perfil de Usuario y Usuarios, las cuales son
manejadas directamente por el Administrador del Sistema.

Figura Nº 116 Interfaz para Sistemas (Selección de menús, opciones y botones)
Figura Nº 117 Interfaz de Perfiles de Usuarios

Figura Nº 118 Interfaz de Cargos de Usuarios

Figura Nº 119 Interfaz de Usuarios
Figura Nº 120 Interfaz de Salida del Sistema

Menú para el Módulo Control de Documentos
Es el módulo que podrá manejar cualquier usuario debidamente
autorizado. A continuación serán presentadas las interfaces de RED para los
menús Definiciones, Procesos y Reportes con sus debidas opciones y
botones:
Figura Nº 121 Interfaz para el Usuario del Menú Definiciones

Figura Nº 122 Interfaz para el Usuario del Menú Procesos

Figura Nº 123 Interfaz para el Usuario del Menú Reportes
Luego de haber definido los diferentes menús que puede manejar el
usuario en el sistema, mostraremos las interfaces de cada una de las
opciones que aparecen en pantalla.
Figura Nº 124 Interfaz para la Inserción, Eliminación, Modificación y Búsqueda de
Estados

Figura Nº 125 Interfaz de Búsqueda de un Estado
Figura Nº 126 Interfaz de Inserción, Modificación, Eliminación y Búsqueda de un Tipo
de Documento

Figura Nº 127 Interfaz de Búsqueda de un Tipo de Documento
Figura Nº 128 Interfaz de Inclusión, Eliminación, Modificación y Búsqueda de
Entidades

Figura Nº 129 Interfaz de Búsqueda de una Entidad
Figura Nº 130 Interfaz de Inclusión, Eliminación, Modificación y Búsqueda para Tipo de
Entidades

Figura Nº 131 Interfaz de Búsqueda para Tipo de Entidades
Figura Nº 132 Interfaz de Inserción, Eliminación, Modificación y Búsqueda de Archivo

Figura Nº 133 Interfaz de Búsqueda de Archivos

Figura Nº 134 Interfaz de Inserción, Eliminación, Modificación y Búsqueda de
Documentos

Figura Nº 135 Interfaz para Búsqueda de Documentos
Figura Nº 136 Interfaz de Inserción, Eliminación, Modificación y Búsqueda de un
Seguimiento

Figura Nº 137 Interfaz de Búsqueda para el Seguimiento de Documentos
Figura Nº 138 Interfaz para el Reporte Tipo de Entidades

Figura Nº 139 Archivo PDF de Tipo de Entidades

Figura Nº 140 Interfaz de Reporte de Tipos de Documentos
Figura Nº 141 Archivo PDF de Tipos de Documentos

Figura Nº 142 Interfaz de Reporte de Estados
Figura Nº 143 Archivo PDF de Estados

Figura Nº 144 Interfaz de Reporte de Entidades
Figura Nº 145 Archivo PDF de Entidades

Figura Nº 146 Interfaz de Reporte de Archivos
Figura Nº 147 Archivo PDF de Archivos

Figura Nº 148 Interfaz de Reporte de Documentos por medio de Descriptores

CAPITULO V
CONCLUSIONES Y RECOMENDACIONES
A través de la presente investigación se logró el cumplimiento de los
objetivos, llegando a las siguientes conclusiones:
1. Con la realización de este trabajo se logró establecer un modelo
del negocio para la Unidad Académica del Centro Local Lara, con
el fin de describir sus funciones, lográndose determinar los
requerimientos sistémicos para solucionar el problema planteado
sobre el registro y control de documentos enviados y recibidos de
dicha unidad.
2. A someter este trabajo a las primeras pruebas por los usuarios
principales del mismo, se pudo observar que lo requerido del
sistema actual se vio reflejado en las funciones del sistema
implantado.
3. En cuanto al modelado del sistema se puede concluir que existen
vacíos en cuanto al uso explícito del modelado orientado a objeto,
máxime cuando en nuestra carrera no vemos materias que nos
den un aprendizaje apropiado de este tipo de modelado.
4. En cuanto a la implantación del sistema se logró realizar en las
oficinas de computación del Centro Local Lara de la Universidad
Nacional Abierta, observándose dos situaciones bien importantes:

a. El Centro Local no posee equipos servidores adecuados
para hacer una correcta implantación, sin embargo, gracias
a la disposición de los profesores del área de sistemas y
computación, lograron adecuar un equipo que fungiera
como servidor.
b. Para implantar este sistema requiere de unas condiciones
básicas en cuanto a software que deben ser consideradas.
Para la implantación inicial en el Centro Local Lara, no hubo
problemas, para otros centros locales que requieran este
sistema se debe hacer un manual de implantación,
adjuntándoles los softwares necesarios para tal fin.
5. Al poner en marcha este sistema se logró facilitar el registro y
control de documentos que se emiten y reciben en la unidad
académica, teniendo como resultado principal, la ubicación efectiva
de los mismos. Direccionándolos de acuerdo a motores de
búsquedas que referencian los documentos en ubicaciones físicas
determinadas.
6. El Sistema facilita la gestión administrativa del jefe de la unidad
académica, ya que le permite conseguir documentos asociados a
temas específicos, filtrándolos con el motor de búsqueda usando
palabras claves y/o rangos de fechas.

Por otra parte, esta investigación se obtuvo las siguientes
recomendaciones:
1. Definir previamente la plataforma tecnológica donde se implantará el
sistema, (Servidor e Intranet).
2. Pensar en un futuro, bajo el desarrollo de otro proyecto académico, la
integración de este sistema en una base de datos única a nivel
nacional.
3. Preparar un plan de adecuaciones y mejoras de este sistema con el
uso de pasantes y/o personal adscrito a la unidad de computación.
4. Proponer estudiantes posibles graduandos, para que realicen
proyectos como este, y dejen a nuestra alma mater, productos que
mejoren sus procesos administrativos.
5. El sistema podrá ser usado en todos los centros locales de la
Universidad Nacional Abierta, si así lo solicitasen.

BIBLIOGRAFÍA
1. Álvarez G., (1997). “Web Seguro”.
www.iec.csic.es/criptonomicon/web.html.
2. Bendahan M., (1997). “Proceso de Desarrollo de Software”.
http://www.monografias.com/trabajos5/desof/desof.shtml.
3. Booch, G., (1996). “Análisis y Diseño Orientado a Objetos”, 2da
edición. Ed. Addison-Wesley / Díaz de Santos, México.
4. Castillo P., (2004). “Páginas Web Estáticas vs. Páginas Web
Dinámicas”. http://www.articulo.org/idx/15/2039/Negocios-en-
Internet/article/Paginas-Web-Estaticas-vs-Paginas-Web-Dinamicas.html
5. CETTICO (Centro de Transferencia Tecnológica en Informática y
Comunicaciones), (1997). "Enciclopedia de Informática y
Comunicación Teleinformática", 1era edición, Editorial CULTURAL
S.A., España.
6. Elmansri R. y Navathe S., (1994). "Fundamentos de Bases de Datos".
Editorial Adison -Wesley Iberoamericana, España.
7. Enciclopedia Wikipedia,(2008).
http://es.wikipedia.org/wiki/Desarrollo_de_software.
8. Galantón A. y Arocha O., (1999). “Modernización de los Sistemas
Automatizados de Admisión, Inscripción de Estudiantes de Nuevo
Ingreso y Validación de la Programación Académica del Núcleo de

Anzoátegui de la Universidad de Oriente”, Trabajo de Grado de
Ingeniería en Computación, Universidad de Oriente, Venezuela.
9. Guevara J., (1998). “Desarrollo e Implantación de los Servicios
Académicos del Departamento de Computación y Sistemas,
usando Tecnología WWW”, Trabajo de Grado de Ingeniería en
Computación, Universidad de Oriente, Venezuela.
10. Jacobson I, Booch G, Rumbaugh J., (1999). “El Proceso Unificado
de Desarrollo de Software”, Ed. Addison Wesley, México.
11. James R, Ivar J, Grody B., (2002). “El Lenguaje Unificado de
Modelado. Manual de Referencia”, 1era edición, Editorial Prentice
Hall, México.
12. Jesús T. y Kronos., (1997). “Sistemas de bases de datos y SGBD”.
http://tramullas.com/documatica/2.html.
13. Kon M.,(1997). “El Software Libre”.
http://www.monografias.com/trabajos12/elsoflib/elsoflib.shtml.
14. Larman C., (1999). "UML y patrones. Introducción al Análisis y
Diseño Orientado a Objetos", 1era edición, Editorial Prentice Hall,
España.
15. Marcias C y Orozco S. (sd), “Uso de UML en aplicaciones Web:
páginas y relaciones”.
http://www.milestone.com.mx/articulos/uso_de_uml_en_aplicaciones_w
eb.htm

16. Marténez M., (2005). “Páginas Web Dinámicas”.
http://www.mati.unam.mx/index.php?option=com_content&task=view&id
=100&Itemid=50.
17. Molero A., (2001). “Diseño de la Intranet de la Escuela de Medicina
de la Universidad de Oriente Núcleo de Anzoátegui”. Trabajo de
Grado de Escuela de Medicina, Universidad de Oriente, Venezuela.
18. Montes B. y Navarro A, (2002). “Estudio de la Aplicación de UML en
el Modelado de Sistemas Organizacionales Inteligentes”. Trabajo
de Grado Ingeniería de Sistemas, Universidad de Oriente, Venezuela.
19. Orallo E., (2007). “El lenguaje Unificado de Modelado (UML)”.
http://www.disca.upv.es/enheror/pdf/ActaUML.PDF
20. Puglieser I., (1995). “Sistema de Gestión de Datos para el
Departamento de Compras del Núcleo Anzoátegui de la
Universidad de Oriente”, Trabajo de Grado de Ingeniería en
Computación, Universidad de Oriente, Venezuela.
21. Reyes A., (2005). “Conceptos y principios orientado a objetos”.
http://www.elguille.info/colabora/NET2005/Percynet_Conceptosyprincipi
osorientadoaobjetos.htm.
22. Tanenbaum A., (1997)."Redes de Computadoras". 3era edición,
Editorial Prentice Hall, México.
23. Valle J., (2005). "Definición Modelo Cliente Servidor"

.http://www.monografias.com/trabajos24/arquitectura-cliente-
servidor/arquitectura-cliente-servidor.shtml.

ANEXO Nº 1: CODIGO FUENTE DE LA OPCION DOCUMENTOS
Reda_documentos.php
<?
$acc_codopc="24";
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Documentos</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link href="css/tablas.css" rel="stylesheet" type="text/css">
<link href="css/ventanas.css" rel="stylesheet" type="text/css">
<link href="css/general.css" rel="stylesheet" type="text/css">
<link href="css/datepickercontrol.css" rel="stylesheet" type="text/css">
</head>
<body leftmargin="0" topmargin="0">
<form method="post" name="form1">

<td width="719" height="22" class="titulo-pagina">DOCUMENTOS</td>
</tr>
</table>
</td>
</tr>
<tr>
<td> 
</td>
</tr>
<tr>
<td>
<table width="650" height="138" border="0" align="center"
cellpadding="0" cellspacing="0" class="formato-blanco">
<tr>
<td><p> </p>
<tr class="titulo-nuevo">
<td height="22" colspan="3">Datos de los Documentos </td>
</tr>
<tr>

<td width="136" height="22"> </td>
<td width="398" height="20"><div align="left"></div></td>
</tr>
<tr>
<td width="136" height="22"><div
align="right">Código </div></td>
<td width="398" height="20"><div align="left">
<input name="txtCOD_DOCU" type="text" id="txtCOD_DOCU"
onBlur="buscarperderfocoCOD_DOCU()"
onKeyDown="buscarenterCOD_DOCU(event)" maxlength="10">
<a href="javascript: catalogo();"><img src="imagenes/botbuscar.gif"
width="80" height="20" border="0"></a><a href="javascript: nuevo();"><img
src="imagenes/botnuevo.gif" width="80" height="20"
border="0"></a></div></td>
</tr>
<tr>
<td height="22"><div align="right">Tipo de Documento</div></td>
<td height="20">
<select name="cmbCOD_TI_DOC" id="cmbCOD_TI_DOC">
<option value="-">Seleccione Uno</option>

<?
require_once("clases/clstipo_documento.php");
$objtc=new clstipo_documento();
$objtc->llenarcomboCOD_TI_DOC();
?>
</select>
</td>
<td height="20"> </td>
</tr>
<tr>
<td width="136" height="22"><div align="right">Fecha de
Emisión </div></td>
<input name="txtFEC_ORI_DOCU" type="text" id="txtFEC_ORI_DOCU"
datepicker="true"></div></td>
</tr>
<tr>
<td height="22"><div align="right">Fecha de Recepcion </div></td>

<input name="txtFEC_REC_DOCU" type="text" id="txtFEC_REC_DOCU"
datepicker="true">
</div></td>
</tr>
<tr>
<td height="22"><div align="right">Descripcion del Documento</div></td>
<td height="20"><textarea name="txtDESCRI_DOCU" cols="40" rows="4"
id="txtDESCRI_DOCU" onChange="frmamayusculas(this)"></textarea></td>
</tr>
<tr>
<td height="22"><div align="right">Resumen del Documento</div></td>
<td height="20"><textarea name="txtRESU_DOCU" cols="40" rows="4"
id="txtRESU_DOCU" onChange="frmamayusculas(this)"></textarea></td>
</tr>
<tr>
<td height="22"><div align="right">Asunto del Documento</div></td>
<td height="20"><input name="txtASUN_DOCU" type="text"
id="txtASUN_DOCU" size="60" maxlength="60"
onChange="frmamayusculas(this)"></td>

</tr>
<tr>
<td height="22"><div align="right">Archivo</div></td>
<td height="20">
<select name="cmbCOD_ARCHI" id="cmbCOD_ARCHI">
<option value="-">Seleccione Uno</option>
<?
require_once("clases/clsarchivador.php");
$objtc=new clsarchivador();
$objtc->llenarcomboARCHI();
?>
</select>
</td>
</tr>
<tr>
<td height="22"><div align="right">Ubicación del
Documento</div></td>
<td height="20"><textarea name="txtUBI_DOCU" cols="40" rows="3"
id="txtUBI_DOCU" onChange="frmamayusculas(this)"></textarea></td>

</tr>
<tr>
<td height="22"><div align="right"> Entidad que Recibe</div></td>
<td height="20"><input name="txtCO_ENTIDAD_RECIBE" type="text"
id="txtCO_ENTIDAD_RECIBE" onChange="frmamayusculas(this)"
size="12">
<input type="button" name="button2" id="button2" value="..."
onClick="catalogoCO_ENTIDAD_RECIBE()"></td>
</tr>
<tr>
<td height="22"><div align="right"> Entidad que Emite</div></td>
<td height="20"><input name="txtCO_ENTIDAD_EMITE" type="text"
id="txtCO_ENTIDAD_EMITE" onChange="frmamayusculas(this)" size="12">
<input type="button" name="button" id="button" value="..."
onClick="catalogoCO_ENTIDAD_EMITE()"></td>
</tr>
<tr>
<td height="22"><div align="right">Persona que lo Emite</div></td>

<td height="20"><input name="txtNOM_PERS_EMI" type="text"
id="txtNOM_PERS_EMI" size="40" maxlength="40"
</tr>
<tr>
<td height="22"><div align="right">Status del Documento</div></td>
<td height="20"><div align="left">
<select name="cmbSTAT_TI_DOCU" id="cmbSTAT_TI_DOCU">
<option value="-">Seleccionar uno</option>
<option value="EMISION">EMISION</option>
<option value="RECEPCION">RECEPCION</option>
</select></div></td>
</tr>
<tr>
<td height="22"><div align="right">Numero del Documento</div></td>
<td height="20"><input name="txtNUM_DOCU" type="integer"
id="txtNUM_DOCU" size="20" maxlength="40"
</tr>

<tr>
<td height="22"><div align="right">Segumiento</div></td>
<td height="20"><div align="left">
<select name="cmbSTAT_SEGUI" id="cmbSTAT_SEGUI">
<option value="NO">NO</option>
<option value="SI">SI</option>
</select></div></td>
</tr>
</table>
<p> 
</p>
<br>
<?
require_once("seghbotonesimec.php");
acc_verbotonesimec($acc_codsis,$_SESSION["logusu"],"49","50","51"
);
?>
<p align="center">  </p>
<p>  </p>
<p> </p></td>

</tr>
</table>
</td>
</tr>
<tr>
<td> 
</td>
</tr>
</table>
</td>
</tr>
</table>
<input type="hidden" name="txtoperacion" id="txtoperacion">
<input type="hidden" name="txtfila" id="txtfila">
<input type="hidden" name="txtCOD_DOCUC" id="txtCOD_DOCUC">
</form>
</body>
<script language="javascript">
function buscarperderfocoCOD_DOCU()
{

f=document.form1;
if (f.txtCOD_DOCU.value!="")
{ f
f.txtCOD_DOCU.value=completarcerosizquierda(f.txtCOD_DOCU.value,10);
f.txtoperacion.value="buscar";
ejecutar();
}
}
function buscarenterCOD_DOCU(e)
{
f=document.form1;
if (e.keyCode==13)
{
f.cmbCOD_TI_DOC.focus();
f.txtFEC_ORI_DOCU.focus();
f.txtFEC_REC_DOCU.focus();
f.txtDESCRI_DOCU.focus();
f.txtRESU_DOCU.focus();
f.txtASUN_DOCU.focus();
f.cmbCOD_ARCHI.focus();

f.txtDES_UBI_ARCHI.focus();
f.txtCO_ENTIDAD_EMITE.focus();
f.txtCO_ENTIDAD_RECIBE.focus();
f.txtNOM_PERS_EMI.focus();
f.cmbSTAT_TI_DOCU.focus();
f.txtNUM_DOCU.focus();
f.cmbSTAT_SEGUI.focus();
}
}
function incluir()
{
f=document.form1;
if (camposvalidos())
{
f.txtoperacion.value="incluir";
ejecutar();
}
}
function modificar()
{

f=document.form1;
if (camposvalidos())
{
f.txtoperacion.value="modificar";
ejecutar();
}
}
function eliminar()
{
f=document.form1;
if (confirm("¿Está seguro de eliminar este registro?"))
{
f.txtoperacion.value="eliminar";
ejecutar();
}
}
function camposvalidos()
{
valido=false;
f=document.form1;

if (f.txtCOD_DOCU.value=="")
{
alert("El código del Archivo no puede estar en blanco");
f.txtCOD_DOCU.focus();
}
else if (f.cmbCOD_TI_DOC.value=="")
{
alert("El Tipo de Documento no puede estar en blanco");
}
else if (f.txtFEC_ORI_DOCU.value=="")
{
alert("La Fecha de Transcripcion no puede estar en blanco");
}
else if (f.txtFEC_REC_DOCU.value=="")
{
alert("La Fecha de Recepcion no puede estar en blanco");
}

else if (f.txtDESCRI_DOCU.value=="")
{
alert("La Descripcion del Documento no puede estar en blanco");
}
else if (f.txtASUN_DOCU.value=="")
{
alert("El Asunto del Documento no puede estar en blanco");
}
else if (f.cmbCOD_ARCHI.value=="")
{
alert("El Codigo de Archivo no puede estar en blanco");
f.cmbCOD_ARCHI.focus();
}
else if (f.txtUBI_DOCU.value=="")
{
alert("La Ubicación del Achivo no puede estar en blanco");
f.txtUBI_DOCU.focus();
}

else if (f.txtCO_ENTIDAD_EMITE.value=="")
{
alert("La Entidad del Documento no puede estar en blanco");
}
else if (f.txtCO_ENTIDAD_RECIBE.value=="")
{
alert("La Entidad del Documento no puede estar en blanco");
}
else if (f.txtNOM_PERS_EMI.value=="")
{
alert("La Persona que lo emite no puede estar en blanco");
}
else if (f.cmbSTAT_TI_DOCU.value=="-")
{
alert("Debe seleccionar el tipo de documento");
}

else if (f.txtNUM_DOCU.value=="")
{
alert("El Numero del Documento no puede estar en blanco");
}
else if (f.cmbSTAT_SEGUI.value=="")
{
alert("El Status del Seguimiento del Documento no puede estar en
blanco");
}
else
{
valido=true;
}
return valido;
}
function catalogo()
{
pagina="catalogo.php?txtarchivo=clscatdocumentos";

{
pagina="catalogo.php?txtarchivo=clscatentidadesrecibe";
}
function cerrarcatalogoCO_ENTIDAD_RECIBE()
{
window.setTimeout("buscarperderfocoCO_ENTIDAD_RECIBE()",500);
}
function buscarperderfocoCO_ENTIDAD_RECIBE()
{
}
function nuevo()
{
f=document.form1;
limpiar();
f.txtCOD_DOCU.value="0";

f.txtRESU_DOCU.focus();
f.txtCOD_ARCHI.focus();
f.cmbUBI_DOCU.focus();
}
</script>
<script language="JavaScript" src="js/validacionestecla.js"></script>
<script language="JavaScript" src="js/validaciones.js"></script>
<script language="JavaScript" src="js/funciones.js"></script>
<script language="javascript" src="js/comun.js"></script>
<script language="javascript" src="js/botones.js"></script>

$obj->DESCRI_DOCU=utf8_decode($_POST["txtDESCRI_DOCU"]);
$obj->RESU_DOCU=utf8_decode($_POST["txtRESU_DOCU"]);
$obj->ASUN_DOCU=utf8_decode($_POST["txtASUN_DOCU"]);
$obj->COD_ARCHI=utf8_decode($_POST["cmbCOD_ARCHI"]);
$obj->UBI_DOCU=utf8_decode($_POST["txtUBI_DOCU"]);
$obj-
>CO_ENTIDAD_EMITE=utf8_decode($_POST["txtCO_ENTIDAD_EMITE"]);
$obj-
>CO_ENTIDAD_RECIBE=utf8_decode($_POST["txtCO_ENTIDAD_RECIBE"
]);
$obj-
>NOM_PERS_EMI=utf8_decode($_POST["txtNOM_PERS_EMI"]);
$obj-
>STAT_TI_DOCU=utf8_decode($_POST["cmbSTAT_TI_DOCU"]);
$obj->NUM_DOCU=utf8_decode($_POST["txtNUM_DOCU"]);
$obj->STAT_SEGUI=utf8_decode($_POST["cmbSTAT_SEGUI"]);
}
$operacion="";
$operacion=utf8_decode($_POST["txtoperacion"]);
$respuestaxml="@@@incorrecto@@@";
if ($operacion=="buscar")
{

$encontrado="no";
$enc=$obj->buscar();
if ($enc)
{
$encontrado="si";
}
$respuestaxml=$obj->toxml($operacion,$encontrado);
}
if ($operacion=="buscar COD_DOC_SEGUI")
{
$encontrado="no";
$obj->COD_DOCU=utf8_decode($_POST["txtCOD_DOC_SEGUI"]);
$enc=$obj->buscar();
if ($enc)
{
$encontrado="si";
}
$respuestaxml=$obj->toxml($operacion,$encontrado);
}

if ($operacion=="incluir")
{
$exitoso="no";
recibir();
$n=$obj->incluir();
if ($n>0)
{
$exitoso="si";
$objsucesos->registrar($_SESSION["logusu"],"Registro capitulo
".$obj->COD_DOCU);
}
else if ($n<0)
{
$exitoso="error";
}
$respuestaxml = '<?xml version="1.0"
standalone="yes"?><capitulos><exitoso>'.$exitoso.'</exitoso><operacion>'.$
operacion.'</operacion><COD_DOCU>'.$obj-
>COD_DOCU.'</COD_DOCU></capitulos>';
}
if ($operacion=="modificar")
{

$exitoso="no";
recibir();
$n=$obj->modificar();
if ($n>0)
{
$exitoso="si";
$objsucesos->registrar($_SESSION["logusu"],"Actualizo capitulo
".$obj->COD_DOCU);
}
else if ($n<0)
{
$exitoso="error";
}
}
if ($operacion=="eliminar")
{
$exitoso="no";

$n=$obj->eliminar();
if ($n>0)
{
$exitoso="si";
$objsucesos->registrar($_SESSION["logusu"],"Elimino capitulo
".$obj->COD_DOCU);
}
else if ($n<0)
{
$exitoso="error";
}
}
header("Content-Type: text/xml;charset=UTF-8");
print utf8_encode($respuestaxml);
?>
Cls_documentos.php
<?

require_once("clsbd.php");
require_once("clscamposvacios.php");
require_once("clscombo.php");
require_once("clsfecha.php");
require_once("clsentidades.php");
require_once("clstipo_documento.php");
class cls_documentos
{
var $objbd;
var $COD_DOCU="";
var $COD_TI_DOC="";
var $FEC_ORI_DOCU="";
var $FEC_REC_DOCU="";
var $DESCRI_DOCU="";
var $RESU_DOCU="";
var $ASUN_DOCU="";
var $COD_ARCHI="";
var $UBI_DOCU="";
var $CO_ENTIDAD_EMITE="";
var $CO_ENTIDAD_RECIBE="";

var $NOM_PERS_EMI="";
var $STAT_TI_DOCU="";
var $NUM_DOCU="";
var $STAT_SEGUI="";
var $objCO_ENTIDAD_EMITE;
var $objCOD_TI_DOC;
function cls_documentos()
{
$this->objbd=new clsbd();
$this->objCO_ENTIDAD_EMITE=new clsentidades();
$this->objCOD_TI_DOC=new clstipo_documento();
}
function buscar()
{
$enc=false;
$objbd=$this->objbd;
$sql="select
redpdocumentos.*,date_format(FEC_ORI_DOCU,'%d/%m/%Y') as
FECHA_ORI_DOCU,date_format(FEC_REC_DOCU,'%d/%m/%Y') as
FECHA_REC_DOCU from redpdocumentos where (COD_DOCU='$this-
>COD_DOCU')";
$tb=$objbd->select($sql);

if ($row=$objbd->next($tb))
{
$enc=true;
$this->COD_DOCU=$row["COD_DOCU"];
$this->COD_TI_DOC=$row["COD_TI_DOC"];
$this->objCOD_TI_DOC->COD_TI_DOC=$this->COD_TI_DOC;
$this->objCOD_TI_DOC->buscar();
$this->FEC_ORI_DOCU=$row["FECHA_ORI_DOCU"];
$this->FEC_REC_DOCU=$row["FECHA_REC_DOCU"];
$this->DESCRI_DOCU=$row["DESCRI_DOCU"];
$this->RESU_DOCU=$row["RESU_DOCU"];
$this->ASUN_DOCU=$row["ASUN_DOCU"];
$this->COD_ARCHI=$row["COD_ARCHI"];
$this->UBI_DOCU=$row["UBI_DOCU"];
$this->CO_ENTIDAD_EMITE=$row["CO_ENTIDAD_EMITE"];
$this->objCO_ENTIDAD_EMITE->CO_ENTIDAD=$this-
>CO_ENTIDAD_EMITE;
$this->objCO_ENTIDAD_EMITE->buscar();
$this-
>CO_ENTIDAD_RECIBE=$row["CO_ENTIDAD_RECIBE"];
$this->NOM_PERS_EMI=$row["NOM_PERS_EMI"];

$this->STAT_TI_DOCU=$row["STAT_TI_DOCU"];
$this->NUM_DOCU=$row["NUM_DOCU"];
$this->STAT_SEGUI=$row["STAT_SEGUI"];
}
return $enc;
}
function incluir()
{
$objfecha=new clsfecha();
$this->FEC_ORI_DOCU=$objfecha->getfechaparagestor($this-
>FEC_ORI_DOCU);
$this->FEC_REC_DOCU=$objfecha->getfechaparagestor($this-
>FEC_REC_DOCU);
$this->COD_DOCU=$objbd-
>generarcodigo("redpdocumentos","COD_DOCU",10);
$sql="insert into
redpdocumentos(COD_DOCU,COD_TI_DOC,FEC_ORI_DOCU,FEC_REC_
DOCU,DESCRI_DOCU,RESU_DOCU,ASUN_DOCU,COD_ARCHI,UBI_DO
CU,CO_ENTIDAD_EMITE,CO_ENTIDAD_RECIBE,NOM_PERS_EMI,STAT_
TI_DOCU,NUM_DOCU,STAT_SEGUI) values('$this->COD_DOCU','$this-
>COD_TI_DOC',$this->FEC_ORI_DOCU,$this->FEC_REC_DOCU,'$this-
>DESCRI_DOCU','$this->RESU_DOCU','$this->ASUN_DOCU','$this-
>COD_ARCHI','$this->UBI_DOCU','$this->CO_ENTIDAD_EMITE','$this-

>CO_ENTIDAD_RECIBE','$this->NOM_PERS_EMI','$this-
>STAT_TI_DOCU','$this->NUM_DOCU','$this->STAT_SEGUI')";
//print $sql;
$n=$objbd->execute($sql);
return $n;
}
function modificar()
{
$objfecha=new clsfecha();
$this->FEC_ORI_DOCU=$objfecha->getfechaparagestor($this-
>FEC_ORI_DOCU);
$this->FEC_REC_DOCU=$objfecha->getfechaparagestor($this-
>FEC_REC_DOCU);
$sql="update redpdocumentos set COD_DOCU='$this-
>COD_DOCU',COD_TI_DOC='$this-
>COD_TI_DOC',FEC_ORI_DOCU=$this-
>FEC_ORI_DOCU,FEC_REC_DOCU=$this-
>FEC_REC_DOCU,DESCRI_DOCU='$this-
>DESCRI_DOCU',RESU_DOCU='$this-
>RESU_DOCU',ASUN_DOCU='$this->ASUN_DOCU',COD_ARCHI='$this-
>COD_ARCHI',UBI_DOCU='$this-
>UBI_DOCU',CO_ENTIDAD_EMITE='$this-
>CO_ENTIDAD_EMITE',CO_ENTIDAD_RECIBE='$this-
>CO_ENTIDAD_RECIBE',NOM_PERS_EMI='$this-

>NOM_PERS_EMI',STAT_TI_DOCU='$this-
>STAT_TI_DOCU',NUM_DOCU='$this->NUM_DOCU',STAT_SEGUI='$this-
>STAT_SEGUI' WHERE (COD_DOCU='$this->COD_DOCU')";
return $n;
}
function eliminar()
{
$n=0;
$sql="delete from redpdocumentos WHERE (COD_DOCU='$this-
>COD_DOCU')";
return $n;
}
function toxml($operacion,$encontrado)
{
$objcamposvacios=new clscamposvacios();
$respuestaxml = "<?xml version="1.0"
standalone="yes"?><documentos><encontrado>$encontrado</encontrado>
<operacion>$operacion</operacion><COD_DOCU>$this-
>COD_DOCU</COD_DOCU><COD_TI_DOC>$this-
>COD_TI_DOC</COD_TI_DOC><NOM_TI_DOC>".$this->objCOD_TI_DOC-

>NOM_TI_DOC."</NOM_TI_DOC><FEC_ORI_DOCU>$this-
>FEC_ORI_DOCU</FEC_ORI_DOCU><FEC_REC_DOCU>$this-
>FEC_REC_DOCU</FEC_REC_DOCU><DESCRI_DOCU>$this-
>DESCRI_DOCU</DESCRI_DOCU><RESU_DOCU>$this-
>RESU_DOCU</RESU_DOCU><ASUN_DOCU>$this-
>ASUN_DOCU</ASUN_DOCU><COD_ARCHI>$this-
>COD_ARCHI</COD_ARCHI><UBI_DOCU>$this-
>UBI_DOCU</UBI_DOCU><CO_ENTIDAD_EMITE>$this-
>CO_ENTIDAD_EMITE</CO_ENTIDAD_EMITE><NOM_ENTIDAD_EMITE>
".$this->objCO_ENTIDAD_EMITE-
>NOM_ENTIDAD."</NOM_ENTIDAD_EMITE><CO_ENTIDAD_RECIBE>$thi
s-
>CO_ENTIDAD_RECIBE</CO_ENTIDAD_RECIBE><NOM_PERS_EMI>$thi
s->NOM_PERS_EMI</NOM_PERS_EMI><STAT_TI_DOCU>$this-
>STAT_TI_DOCU</STAT_TI_DOCU><NUM_DOCU>$this-
>NUM_DOCU</NUM_DOCU><STAT_SEGUI>$this-
>STAT_SEGUI</STAT_SEGUI></documentos>";
$respuestaxml=$objcamposvacios->evitarvacios($respuestaxml);
return $respuestaxml;
}
function toxmldet($operacion,$encontrado,$fila)
{
$objcamposvacios=new clscamposvacios();
$respuestaxml = "<?xml version="1.0"
standalone="yes"?><documentos><encontrado>$encontrado</encontrado>
<operacion>$operacion</operacion><COD_DOCUC>$this-

>COD_DOCU</COD_DOCUC><COD_TI_DOCC>$this-
>COD_TI_DOC</COD_TI_DOCC><FEC_ORI_DOCUC>$this-
>FEC_ORI_DOCU</FEC_ORI_DOCUC><FEC_REC_DOCUC>$this-
>FEC_REC_DOCU</FEC_REC_DOCUC><DESCRI_DOCUC>$this-
>DESCRI_DOCU</DESCRI_DOCUC><RESU_DOCUC>$this-
>RESU_DOCU</RESU_DOCUC><ASUN_DOCUC>$this-
>ASUN_DOCU</ASUN_DOCUC><COD_ARCHIC>$this-
>COD_ARCHI</COD_ARCHIC><UBI_DOCUC>$this-
>UBI_DOCU</UBI_DOCUC><CO_ENTIDAD_EMITEC>$this-
>CO_ENTIDAD_EMITE</CO_ENTIDAD_EMITEC><CO_ENTIDAD_RECIBE
C>$this-
>CO_ENTIDAD_RECIBE</CO_ENTIDAD_RECIBEC><NOM_PERS_EMIC>
$this->NOM_PERS_EMI</NOM_PERS_EMIC><STAT_TI_DOCUC>$this-
>STAT_TI_DOCU</STAT_TI_DOCUC><NUM_DOCUC>$this-
>NUM_DOCU</NUM_DOCUC><STAT_SEGUIC>$this-
>STAT_SEGUI</STAT_SEGUIC><fila>$fila</fila></documentos>";
$respuestaxml=$objcamposvacios->evitarvacios($respuestaxml);
return $respuestaxml;
}
function llenarcomboSEGUI()
{
$objcombo=new clscombo();
$sql="select COD_DOCU,NUM_DOCU from redpdocumentos order by
NUM_DOCU";
$objcombo->llenarcombosql($sql,"COD_DOCU","NUM_DOCU","");

}
}
?>
Redjdocumentos.js
var objfrm=new Array();
objfrm[0]="txtoperacion";
objfrm[1]="txtCOD_DOCU";
objfrm[2]="cmbCOD_TI_DOC";
objfrm[3]="txtFEC_ORI_DOCU";
objfrm[4]="txtFEC_REC_DOCU";
objfrm[5]="txtDESCRI_DOCU";
objfrm[6]="txtRESU_DOCU";
objfrm[7]="txtASUN_DOCU";
objfrm[8]="cmbCOD_ARCHI";
objfrm[9]="txtUBI_DOCU";
objfrm[10]="txtCO_ENTIDAD_EMITE";
objfrm[11]="txtNOM_PERS_EMI";
objfrm[12]="cmbSTAT_TI_DOCU";
objfrm[13]="txtNUM_DOCU";

objfrm[14]="cmbSTAT_SEGUI";
objfrm[15]="txtCO_ENTIDAD_RECIBE";
var buscarxml=new Array();
buscarxml[0]="operacion";
buscarxml[1]="COD_DOCU";
buscarxml[2]="COD_TI_DOC";
buscarxml[3]="FEC_ORI_DOCU";
buscarxml[4]="FEC_REC_DOCU";
buscarxml[5]="DESCRI_DOCU";
buscarxml[6]="RESU_DOCU";
buscarxml[7]="ASUN_DOCU";
buscarxml[8]="COD_ARCHI";
buscarxml[9]="UBI_DOCU";
buscarxml[10]="CO_ENTIDAD_EMITE";
buscarxml[11]="NOM_PERS_EMI";
buscarxml[12]="STAT_TI_DOCU";
buscarxml[13]="NUM_DOCU";
buscarxml[14]="STAT_SEGUI";
buscarxml[15]="CO_ENTIDAD_RECIBE";

var ncampos=16;
function ejecutar()
{
iralservidor("redn_documentos.php",objfrm,ncampos);
}
function respuestaServidor()
{
f=document.form1;
if (http_request.readyState == 4)
{
if (http_request.status == 200)
{
//alert(http_request.responseText);
//f.txterror.value=http_request.responseText;
if (http_request.responseText.indexOf('@@@incorrecto@@@') ==
-1)
{

var xmlDocument = http_request.responseXML;
var operacion =
xmlDocument.getElementsByTagName('operacion').item(0).firstChild.data;
if (operacion=="buscar")
{
aux=f.txtCOD_DOCU.value;
limpiar();
f.txtCOD_DOCU.value=aux;
var encontrado =
xmlDocument.getElementsByTagName('encontrado').item(0).firstChild.data;
if (encontrado=="si")
{
f=document.form1;
for (i=0;i<ncampos;i++)
{
var data =
xmlDocument.getElementsByTagName(buscarxml[i]).item(0).firstChild.data;
f.elements[objfrm[i]].value=limpiarvacios(data);

}
botonesModificar();
}
else
{
botonesIncluir();
f.elements["txtCOD_DOCU"].value="0";
}
}
else if (operacion=="incluir")
{
var exitoso =
xmlDocument.getElementsByTagName('exitoso').item(0).firstChild.data;
var COD_DOCU =
xmlDocument.getElementsByTagName('COD_DOCU').item(0).firstChild.data;
alert("Registro Incluido "+COD_DOCU);
limpiar();

}
else if (operacion=="modificar")
{
var exitoso =
mensajemodificar(exitoso);
limpiar();
}
else if (operacion=="eliminar")
{
var exitoso =
mensajeeliminar(exitoso);
limpiar();
}
isWorking = false;

}
}
else
{
alert('Hay un problema con la solicitud de datos');
}
}
}
function limpiar()
{
limpiarbotones();
f=document.form1;
f.txtCOD_DOCU.value="";
f.cmbCOD_TI_DOC.selectedIndex=0;
f.txtFEC_ORI_DOCU.value="";
f.txtFEC_REC_DOCU.value="";
f.txtDESCRI_DOCU.value="";

f.txtRESU_DOCU.value="";
f.txtASUN_DOCU.value="";
f.cmbCOD_ARCHI.selectedIndex=0;
f.txtUBI_DOCU.value="";
f.txtCO_ENTIDAD_EMITE.value="";
f.txtCO_ENTIDAD_RECIBE.value="";
f.txtNOM_PERS_EMI.value="";
f.cmbSTAT_TI_DOCU.selectedIndex=0;
f.txtNUM_DOCU.value="";
f.cmbSTAT_SEGUI.selectedIndex=0;
}
Redr_documentos.php
<?
$acc_codopc="46";
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Documentos</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link href="css/tablas.css" rel="stylesheet" type="text/css">
<link href="css/ventanas.css" rel="stylesheet" type="text/css">
<link href="css/general.css" rel="stylesheet" type="text/css">
<link href="css/datepickercontrol.css" rel="stylesheet" type="text/css">
</head>
<body leftmargin="0" topmargin="0">
<p> </p>
<form method="post" name="form1">
<script language="JavaScript" src="js/menu.js"></script>
<tr>
<td align="center">

</tr>
<tr>
<td>
<tr class="titulo-pagina">
<td width="719" height="22" class="titulo-pagina">DOCUMENTOS</td>
</tr>
</table>
</td>
</tr>
<tr>
<td> 
</td>
</tr>

<tr>
<td>
<table width="650" height="138" border="0" align="center"
cellpadding="0" cellspacing="0" class="formato-blanco">
<tr>
<td bgcolor="#CCCCCC"><p> </p>
<tr class="titulo-nuevo">
<td height="22" colspan="3">Listado de Documentos Por:</td>
</tr>
<tr>
</tr>
<tr>
<td height="20"><div align="right">Emisiòn Desde:</div></td>

<td height="20"><input name="txtFEC_ORI_DOCU_DESDE" type="text"
id="txtFEC_ORI_DOCU_DESDE" datepicker="true"></td>
</tr>
<tr>
<td width="191" height="20"><div align="right">Emisiòn
Hasta:</div></td>
<td width="395" height="20"><input name="txtFEC_ORI_DOCU_HASTA"
type="text" id="txtFEC_ORI_DOCU_HASTA" datepicker="true"></td>
</tr>
<tr>
<td height="22" colspan="3"> </td>
</tr>
<tr>
<td height="20"><div align="right">Tipo de Documento</div></td>
<td height="20"><select name="cmbCOD_TI_DOC" id="cmbCOD_TI_DOC">
<option value="-">---</option>
<?
require_once("clases/clstipo_documento.php");
$objtc=new clstipo_documento();

$objtc->llenarcomboCOD_TI_DOC();
?>
</select></td>
</tr>
<tr>
</tr>
<tr>
<td height="20"><div align="right">Status del Documento</div></td>
<td height="20"><select name="cmbSTAT_TI_DOCU"
id="cmbSTAT_TI_DOCU">
<option value="-"> --- </option>
<option value="EMISION">EMISION</option>
<option value="RECEPCION">RECEPCION</option>
</select></td>
</tr>
<tr>

</tr>
<tr>
<td height="20"><div align="right">Entidad que Emite el
<td height="20"><input name="txtCO_ENTIDAD_EMITE" type="text"
id="txtCO_ENTIDAD_EMITE" onChange="frmamayusculas(this)" size="12">
onClick="catalogoCO_ENTIDAD_EMITE()"></td>
</tr>
<tr>
</tr>
<tr>
<td height="20"><div align="right">Entidad que Recibe el
<td height="20"><input name="txtCO_ENTIDAD_RECIBE" type="text"
id="txtCO_ENTIDAD_RECIBE" onChange="frmamayusculas(this)"
size="12">

onClick="catalogoCO_ENTIDAD_RECIBE()"></td>
</tr>
<tr>
</tr>
<tr>
<td height="20"><div align="right">Palabra Clave</div></td>
<td height="20"><a href="javascript: reporte();">
<input name="txtpalabra" type="text" id="txtpalabra" size="30"
maxlength="30">
</a></td>
</tr>
<tr>
</tr>
<tr>

<td height="20"><div align="right">Tipo de Entidad que Emite</div></td>
<td height="20"><select name="cmbCOD_TI_ENTIDAD_EMITE"
id="cmbCOD_TI_ENTIDAD_EMITE">
<?
require_once("clases/clstipo_entidades.php");
$objCOD_TI_ENTI=new clstipo_entidades();
$objCOD_TI_ENTI->llenarcomboCOD_TI_ENTIDAD();
?>
</select></td>
</tr>
<tr>
<td height="20"><div align="right">Tipo de Entidad que Recibe</div></td>
<td height="20"><select name="cmbCOD_TI_ENTIDAD_RECIBE"
id="cmbCOD_TI_ENTIDAD_RECIBE">
<?
require_once("clases/clstipo_entidades.php");
$objCOD_TI_ENTI=new clstipo_entidades();

$objCOD_TI_ENTI->llenarcomboCOD_TI_ENTIDAD();
?>
</select></td>
</tr>
<tr>
</tr>
<tr>
</tr>
<tr>
<td height="20"><div align="right">Status de la Entidad que Emite</div></td>
<td height="20"><select name="cmbSTAT_ENTIDAD_EMITE"
id="cmbSTAT_ENTIDAD_EMITE">
<option value="INTERNO UNA">INTERNO UNA</option>

<option value="OFICINA INTERNA">OFICINA INTERNA</option>
<option value="EXTERNO UNA">EXTERNO UNA</option>
<option value="PROFESOR UNA">PROFESOR UNA</option>
<option value="ESTUDIANTE UNA">ESTUDIANTE UNA</option>
</select>
<a href="javascript: reporte();"></a></td>
</tr>
<tr>
<td height="20"><div align="right">Status de la Entidad que
Recibe</div></td>
<td height="20"><select name="cmbSTAT_ENTIDAD_RECIBE"
id="cmbSTAT_ENTIDAD_RECIBE">
<option value="INTERNO UNA">INTERNO UNA</option>
<option value="OFICINA INTERNA">OFICINA INTERNA</option>
<option value="EXTERNO UNA">EXTERNO UNA</option>
<option value="PROFESOR UNA">PROFESOR UNA</option>
<option value="ESTUDIANTE UNA">ESTUDIANTE UNA</option>
</select>

</td>
</tr>
<tr>
<td> 
</td>
</tr>
</table>
</td>
</tr>
</table>
<input type="hidden" name="txtoperacion" id="txtoperacion">
<input type="hidden" name="txtfila" id="txtfila">
<input type="hidden" name="txtCOD_DOCUC" id="txtCOD_DOCUC">
</form>
</body>

p=p+"&cmbCOD_TI_ENTIDAD_EMITE="+encodeURIComponent(f.cm
bCOD_TI_ENTIDAD_EMITE.value);
p=p+"&cmbCOD_TI_ENTIDAD_RECIBE="+encodeURIComponent(f.c
mbCOD_TI_ENTIDAD_RECIBE.value);
p=p+"&txtpalabra="+encodeURIComponent(f.txtpalabra.value);
//p=p+encodeURIComponent(p);
pagina="redrpdfdocumentos.php"+p;
window.open(pagina,"repdocumentos","menubar=no,toolbar=no,scroll
bars=yes,left=50,top=50,width=700,height=500,resizable=yes,location=no");
}
function catalogoCO_ENTIDAD_EMITE()
{
pagina="catalogo.php?txtarchivo=clscatentidadesemite";
}
function cerrarcatalogoCO_ENTIDAD_EMITE()
{
window.setTimeout("buscarperderfocoCO_ENTIDAD_EMITE()",500);

}
function buscarperderfocoCO_ENTIDAD_EMITE()
{
}
function catalogoCO_ENTIDAD_RECIBE()
{
pagina="catalogo.php?txtarchivo=clscatentidadesrecibe";
}
function cerrarcatalogoCO_ENTIDAD_RECIBE()
{
window.setTimeout("buscarperderfocoCO_ENTIDAD_RECIBE()",500);
}
</script>

<tr>
<td width="94%" valign="bottom">
<tr>
<td width="535" align="left">
<div style="position:relative">
<script language="JavaScript"><!--
var menu1 = new MENU("top");
menu1.floatMenu = false;
menu1.mainArrows = false;
menu1.mainBGColor = "#003366";
menu1.mainBorderWidth = 1;
menu1.mainItemWidth = 165;
menu1.mainItemFontSize = 12;
menu1.mainItem3D = 0;
menu1.mainItemColor = "#003366";
menu1.mainItemFontColor = "white";
menu1.mainItemHilight = "#006699";
menu1.subBGColor = "#006699";

menu1.subItemWidth = 165;
menu1.subItemColor = "#003366";
menu1.subItemHilight = "#EE7C15";
menu1.subItemFontColor = "#FFFFFF";
menu1.subItemFontHilight = "#FFFFFF";
menu1.mainItemPadding = 3;
menu1.subItemPadding = 3;
menu1.mainItemSpacer = 0;
menu1.mainItemFontHilight = "#FFFFFF";
menu1.subBorderWidth = 1;
menu1.mainBorderWidth = 1;
menu1.mainTop = -12;
menu1.mainLeft = 0;
<?
require_once("clases/clsaccesousuarios.php");
$objsupacc=new clsaccesousuarios();
$menu=$objsupacc-
>getOpcionesSistemas($acc_codsis,$_SESSION["logusu"]);

$nm=count($menu);
for ($i=0;$i<$nm;$i++)
{
$desopc=$menu[$i][0];
$pagopc=$menu[$i][1];
$nivopc=$menu[$i][2];
$tipopc=$menu[$i][3];
if ($tipopc=="M")
{
?>
menu1.entry(<? print $nivopc+1; ?>, 14, "<? print $desopc; ?>");
<?
}
else
{
?>
menu1.entry(<? print $nivopc+1; ?>, 14, "<? print $desopc; ?>","<?
print $pagopc; ?>","","");
<?
}

}
?>
menu1.create();
//--></script>
</div>
</td>
<td width="491" align="left"> 
</td>
</tr>
</table>
</td>
<td width="6%">

<?
require_once("clases/clsusuarios.php");
require_once("clases/clsutilidades.php");
$objutil=new clsutilidades();
$nusu=$objutil->codigoaleatorio();
$objusufot=new clsusuarios();
$objusufot->logusu=$_SESSION["logusu"];
$objusufot->buscar();
//$rutafotousu="imagenes/usuariosinfoto.jpg";
if ($objusufot->nomfot!="")
{
$rutafotousu="segaobtenerfotousuario.php?id=".$objusufot-
>logusu."&tipo=normal&na=$nusu";
}
?>
<img src="<? print $rutafotousu;?>" width="70" height="100">
</td>
</tr>

</table>
</td>
</tr>
</table>
Conaseguridadacceso.php
<?
require_once("clases/clsaccesousuarios.php");
$usuok=false;
$acc_codsis="0002";
if ($acc_codopc!="")
{
$usuok=tieneacceso($acc_codopc);
}
else
{
$usuok=tieneaccesosistema();
}
if (!$usuok)

{
header("Location: $paginaerroracceso");
}
function tieneacceso($codopc)
{
global $acc_codsis;
$codsis=$acc_codsis;
$objacc=new clsaccesousuarios();
$logusu=$_SESSION["logusu"];
$tieneacceso=$objacc->getPermitirAcceso($logusu,$codsis,$codopc);
return $tieneacceso;
}
function tieneaccesosistema()
{
global $acc_codsis;
$codsis=$acc_codsis;
$objacc=new clsaccesousuarios();
$logusu=$_SESSION["logusu"];

$tieneacceso=$objacc->getPermitirAccesoSistema($logusu,$codsis);
return $tieneacceso;
}
?>
Conaseguridad.php
<?
session_start();
$usuok=false;
if (isset($_SESSION["logusu"]))
{
if ($_SESSION["logusu"]!="")
{
$usuok=true;
}
}
$paginaerroracceso="conaerroracceso.php";
if (!$usuok)

{
header("Location: $paginaerroracceso");
}
?>

Aplicacion web

Más contenido relacionado

Destacado (20)

Similar a Aplicacion web (20)

Último (11)

Aplicacion web