UNIVERSIDAD NACIONAL ABIERTA VICE-RECTORADO ACADEMICO AREA DE INGENIERIA CARRERA INGENIERIA DE SISTEMAS

Transcripción

1 UNIVERSIDAD NACIONAL ABIERTA VICE-RECTORADO ACADEMICO AREA DE INGENIERIA CARRERA INGENIERIA DE SISTEMAS 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 Autor: Br. Amarelis del Carmen Ybarra Dugarte C.I Tutor Académico: Prof. Pedro Luis Rodríguez C.I Tutor Empresarial: Profa. Saibel Ramos C.I.: Centro Local Portuguesa MARZO, 2014 i

2 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 Diagramas que ofrece el UML Modelo cliente-servidor Programación orientada a objetos...34 Servidor Web Seguro Páginas Web...37 Lenguaje SQL...38 ii

3 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 Disciplinas 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 iii

4 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 Diagrama de Base de Datos Modelo Entidad Relación de RED 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 Funcionalidades del Sistema 197 Interfaz de Usuario.197 Interfaz de Acceso al Sistema RED 198 iv

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

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

7 INDICE DE FIGURAS Figura Nº 1 Modelo de Cascada de Desarrollo de Software Figura Nº 2 Desarrollo de UML, con sus versiones Figura Nº 3 Casos de Uso 18 Figura Nº 4 Diagramas del UML que expresan gráficamente un Modelo Figura Nº 5 Ejemplo de Modelo de Casos d Uso Figura Nº 6 Ejemplo de un Diagrama de Clases Figura Nº 7 Ejemplo de un Diagrama de Colaboración Figura Nº 8 Ejemplo de un Diagrama de Secuencia 29 Figura Nº 9 Modelo Cliente Servidor en un entrono WEB Figura Nº 10 Intercambio de Información entre un Navegador Web y un Servidor WEB Figura Nº 11 Tabla en Primera forma Normal Figura Nº 12 Tabla que no está en Segunda Forma Normal 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 vii

8 Figura Nº 17 Tabla Atletas parte 2 49 Figura Nº 18 Transacción usando cifrado SSl Figura Nº 19 Indicación de una conexión segura en Navegadores Web Figura Nº 20 Historia del RUP 60 Figura Nº 21 Disciplinas, fases, iteraciones del RUP Figura Nº 22 Los Casos de Uso integran al trabajo Figura Nº 23 Trazabilidad a partir de los Casos de Uso Figura Nº 24 Evolución de la arquitectura del sistema Figura Nº 25 Los modelos se completan, la arquitectura no cambia drásticamente 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 Figura Nº 30 Ciclo evolutivo en la elaboración de software basado en RUP Figura Nº 31 Esfuerzo respecto de los flujos de trabajo Figura Nº 32 Esfuerzo respecto de las fases viii

9 Figura Nº 33 Elementos que conforman el RUO Figura Nº 34 Artefactos en las disciplinas de la RUP Figura Nº 35 Grado de finalización de artefactos Figura Nº 36 Comparación entre diagramas de casos de uso Figura Nº 37 Comparación entre diagramas de objetos Figura Nº 38 Comparación entre diagramas de estados Figura Nº 39 Comparación entre diagramas de actividades Figura Nº 40 Comparación entre diagramas de secuencia Figura Nº 41 Comparación entre diagramas de colaboración Figura Nº 42 Diagramas de componentes Figura Nº 43 Comparación entre diagramas de despliegue Figura Nº 44 Diagrama del Caso de Uso Incluir Estado Figura Nº 46 Diagrama del Caso de Uso Eliminar Estado Figura Nº 47 Diagrama del Caso de Uso Buscar Estado Figura Nº 48 Diagrama del Caso de Uso Incluir Tipo Documento Figura Nº 49 Diagrama del Caso de 118 ix

10 Uso Modificar Tipo Documento Figura Nº 50 Diagrama del Caso de Uso Eliminar Tipo Documento Figura Nº 51 Diagrama del Caso de Uso Buscar Tipo Documento Figura Nº 52 Diagrama del Caso de Uso Incluir Entidad Figura Nº 53 Diagrama del Caso de Uso Modificar Entidad Figura Nº 54 Diagrama del Caso de Uso Eliminar Entidad Figura Nº 55 Diagrama del Caso de Uso Buscar Entidad Figura Nº 56 Diagrama del Caso de Uso Incluir Tipo Entidad Figura Nº 56 Diagrama del Caso de Uso Modificar Tipo Entidad Figura Nº 57 Diagrama del Caso de Uso Eliminar Tipo Entidad Figura Nº 59 Diagrama del Caso de Uso Incluir Archivo Figura Nº 60 Diagrama del Caso de Uso Modificar Archivo Figura Nº 61 Diagrama del Caso de Uso Eliminar Archivo Figura Nº 62 Diagrama del Caso de Uso Buscar Archivo Figura Nº 63 Diagrama del Caso de Uso Incluir Documento Figura Nº 64 Diagrama del Caso de Uso Modificar Documento x

11 Figura Nº 65 Diagrama del Caso de Uso Eliminar Documento Figura Nº 66 Diagrama del Caso de Uso Buscar Documento Figura Nº 67 Diagrama del Caso de Uso Incluir Seguimiento Figura Nº 68 Diagrama del Caso de Uso Modificar Seguimiento Figura Nº 69 Diagrama del Caso de Uso Eliminar Seguimiento Figura Nº 70 Diagrama del Caso de Uso Buscar Seguimiento Figura Nº 71 Diagrama de Caso de Uso Reporte Tipo Documento Figura Nº 73 Diagrama de Caso de Uso Reporte Estados Figura Nº 74 Diagrama de Caso de Uso Reporte Entidades Figura Nº 75 Diagrama de Caso de Uso Reporte Documentos Figura Nº 76 Diagrama de Caso de Uso Reporte Archivadores Figura Nº 77 Diagrama de Caso de Uso Incluir Sistema Figura Nº 78 Diagrama de Caso de Uso Modificar Sistema Figura Nº 79 Diagrama de Caso de Uso Eliminar Sistema Figura Nº 80 Diagrama de Caso de Uso Buscar Sistema Figura Nº 81 Diagrama de Caso de 151 xi

12 Uso Incluir Perfil Usuario Figura Nº 82 Diagrama de Caso de Uso Modificar Perfil Usuario Figura Nº 83 Diagrama de Caso de Uso Eliminar Perfil Usuario Figura Nº 84 Diagrama de Caso de Uso Buscar Perfil Usuario Figura Nº 85 Diagrama de Caso de Uso Incluir Cargo Usuario Figura Nº 87 Diagrama de Caso de Uso Eliminar Cargo Usuario Figura Nº 88 Diagrama de Caso de Uso Buscar Cargo Usuario Figura Nº 89 Diagrama de Caso de Uso Incluir Usuario Figura Nº 90 Diagrama de Caso de Uso Modificar Usuario Figura Nº 91 Diagrama de Caso de Uso Eliminar Usuario Figura Nº 92 Diagrama de Caso de Uso Buscar Usuario Figura Nº 93 Modelo General del Diagrama de Casos de Uso de RED Figura Nº 94 Diagrama de Clases (Módulo Control de Documentos) Figura Nº 95 Diagrama de clases (Módulo Seguridad) Figura Nº 96 Diagrama de Clases Usando estereotipos (Control de documentos) Figura Nº 97 Diagrama de Clases Usando estereotipos (Seguridad) xii

13 Figura Nº 98 Diagrama de Estados (Control de Documentos) Figura Nº 99 Diagrama de Estados (Seguridad) Figura Nº 100 Diagrama de Secuencia del Caso de Uso Incluir Documento Figura Nº 101 Diagrama de Secuencia del Caso de Uso Modificar Documento Figura Nº 102 Diagrama de Secuencia del Caso de Uso Eliminar Documento Figura Nº 103 Diagrama de Secuencia del Caso de Uso Buscar Documento Figura Nº 104 Diagrama de Secuencia del Caso de Uso Incluir Seguimiento Figura Nº 105 Diagrama de Secuencia del Caso de Uso Modifica Seguimiento Figura Nº 106 Diagrama de Secuencia del Caso de Uso Eliminar Seguimiento Figura Nº 107 Diagrama de Secuencia del Caso de Uso Buscar Seguimiento Figura Nº 108 Diagrama de Secuencia del Caso de Uso Reporte Documento Figura Nº 109 Diagrama de Despliegue de RED xiii

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

15 Inserción, Eliminación, Modificación y Búsqueda de Tipo de Documento Figura Nº 127 Interfaz para la Inserción, Eliminación, Modificación y Búsqueda de Entidades Figura Nº 128 Interfaz de Búsqueda de una entidad Figura Nº 129 Interfaz para la Inserción, Eliminación, Modificación y Búsqueda de Tipo de Entidades Figura Nº 130 Interfaz de Búsqueda para tipo de Entidades Figura Nº 131 Interfaz para la Inserción, Eliminación, Modificación y Búsqueda de Archivos Figura Nº 132 Interfaz de Búsqueda de Archivo Figura Nº 133 Interfaz para la Inserción, Eliminación, Modificación y Búsqueda de Documentos Figura Nº 134 Interfaz de Búsqueda de Documentos Figura Nº 135 Interfaz para la Inserción, Eliminación, Modificación y Búsqueda de Seguimiento Figura Nº 136 Interfaz de Búsqueda de Seguimiento de Documentos Figura Nº 137 Interfaz para el reporte de Tipo de Entidades Figura Nº 138 Archivo PDF de Tipo de Entidades Figura Nº 139 Interfaz de Reporte de Tipos de Documentos xv

16 Figura Nº 140 Archivo PDF de Tipos de Documentos Figura Nº 141 Interfaz de Reporte de Tipos de Estados Figura Nº 142 Archivo PDF de Estados Figura Nº 143 Interfaz de Reporte Entidades Figura Nº 144 Archivo PDF de Entidades Figura Nº 145 Interfaz de Reporte de Archivos Figura Nº 146 Archivo PDF de Archivos Figura Nº 147 Interfaz de Reporte de documentos por medio de Descriptores xvi

17 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! i

18 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! ii

19 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. iii

20 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 1

21 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 2

22 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 3

23 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 4

24 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. 5

25 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. 6

26 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. 7

27 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. 8

28 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 9

29 un control de cada uno de los académico de una manera fácil y rápida. Docentes en el cumplimiento 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. 10

30 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 11

31 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). 12

32 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: 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. 13

33 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 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 14

34 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. 15

35 Figura Nº 2. Desarrollo de UML, con sus versiones Fuente: 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. 16

36 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: 17

37 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: 18

38 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. 19

39 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. 20

40 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:

41 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: // 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. 22

42 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 23

43 (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): 24

44 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 25

45 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: 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 26

46 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. 27

47 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 28

48 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: // año: 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 29