Servicios Web para la gestión de información del Departamento de Computación

Texto completo

(1)Universidad Central “Marta Abreu” de las Villas Facultad Matemática, Física y Computación Ingeniería Informática. Trabajo de Diploma. Título: Servicios web para la gestión de información del Departamento de Computación. Autor Alejandro José Roche Benitez. Tutores Dr. Daniel Gálvez Lio Dra. Gheisa Lucía Ferreira Lorenzo. Curso 2014- 2015.

(2) Declaración Jurada. El que suscribe, Alejandro José Roche Benitez, hago constar que el trabajo titulado Servicios web para la gestión de información del Departamento de Computación fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de los estudios de la especialidad de Ingeniería Informática, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.. ________________ Firma del autor. Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. ___________________________ Firma del Tutor. ____________________________ Firma del Jefe del Laboratorio.

(3) Dedicatoria A mi madre por su motivación constante que me ha permitido ser una persona de bien. A mi padre por los ejemplos de perseverancia y constancia que lo caracterizan. A mi abuela por su preocupación y apoyo constante. A mis familiares por su colaboración directa o indirecta en la elaboración de esta tesis. A mi esposa por mantener una relación de apoyo mutuo y constante en nuestra formación profesional..

(4) Agradecimientos. A mis tutores, los Dres. Daniel Gálvez Lio y Gheisa Lucía Ferreira Lorenzo, por su tiempo compartido y por impulsar el desarrollo de mi formación profesional..

(5) Resumen En este trabajo se aborda la problemática referente a la creación de una infraestructura de servicios web para la mejora y optimización del manejo de los datos y la información relacionada con la gestión de los planes de estudio, la carga docente y la autoevaluación de las carreras asociadas al Departamento de Computación. Para el desarrollo e implementación del software se lleva a cabo una evaluación de las formas anteriores con las que se ejecuta el proceso en cuestión, y se utiliza para su migración hacia una plataforma web herramientas tales como el marco de trabajo Symfony 2.4, la arquitectura SOA y el gestor de base de datos PostgreSQL. Como resultado se obtuvo una aplicación web cuya implementación garantiza un mayor control de los procesos anteriormente mencionados, y que además proporciona niveles más altos de flexibilidad, escalabilidad, accesibilidad y reutilización de códigos ejecutables sobre cualquier plataforma..

(6) Abstract This work is related to the creation of a web services infrastructure to improve and optimize the management of data and information related to the management of the curriculum, the teaching load how are associated with the autoevaluation of the careers of the Department of Computer Science. For development and implementation of the software is carried out an assessment of the above ways in which the process is executed in question, and is used for migration to a web platform tools such as the framework Symfony 2.4, SOA and the manager PostgreSQL database. As a result, a Web application was obtained whose implementation ensures greater control of the aforementioned processes, and provides high levels of flexibility, scalability, accessibility and reuse of executable code on any platform..

(7) Tabla de contenido Introducción ........................................................................................................ 1 Capítulo I: Caracterización de la arquitectura SOA y los Servicios Web ............ 5 I.1 Descripción y análisis del problema ........................................................... 5 I. 2 Caracterización de la Arquitectura Orientada a Servicios (SOA) .............. 6 I.2.1 Tratamiento teórico conceptual de la arquitectura SOA ....................... 7 I.2.2 Requerimientos para el despliegue de SOA ........................................ 9 I.3 Caracterización de las tecnologías de programación a utilizar ................ 11 I.3.1 El servicio Web como facilitador tecnológico de SOA........................ 11 I.3.2 Breve descripción de los componentes que integran un Web Services. ................................................................................................................... 12 I.4 El gestor de base de datos PostgreSQL .................................................. 14 I.5 El marco de trabajo Symfony 2.4 ............................................................. 15 I.5.1 Generador de archivos WSDL BeSimpleSoapBundle ....................... 16 I.6 El sistema de infraestructura WAMP........................................................ 17 Capítulo II: Implementación de los Servicios Web para el apoyo a la Autoevaluación de la Carrera y la Carga Docente ........................................... 18 II.1 Declaración de las funciones, atribuciones y obligaciones de los principales actores del software. ................................................................... 18 II.2 Actores y caso de uso del negocio.......................................................... 20 II.3 Descripción de los actores y los casos de uso del sistema a automatizar ...................................................................................................................... 21 Tabla 1. Descripción de los actores del sistema ........................................... 21 II.4 Requisitos funcionales y no funcionales del sistema .............................. 21 II.4.1 Requisitos no funcionales ................................................................. 23 II.5 Diagramas de casos de uso del sistema ................................................. 24 II.6 Descripción de los casos de uso más significativos del sistema ............. 26.

(8) II.7 Paquetes del software ............................................................................. 30 Capítulo III: Descripción de la propuesta de solución ....................................... 32 III.1. Arquitectura del Sistema ....................................................................... 32 III.2 El Modelo-Vista-Controlador (MVC) como patrón de arquitectura ......... 33 III.2.1 El Modelo-Vista-Controlador en Symfony 2.4 .................................. 34 III.3 Diagramas de clases de diseño ............................................................. 35 III. 4 Diagrama de secuencia ........................................................................ 36 III.5 Tratamiento de errores en la validación de los datos. ............................ 39 III.6 Diseño de la base de datos .................................................................... 40 III.6.1 Modelado conceptual de los datos ...................................................... 41 III.6.2 Modelado físico de los datos ........................................................... 43 III.7 Diagrama de componentes .................................................................... 45 III.8 Diagrama de despliegue ........................................................................ 47 Capítulo IV: Pruebas de análisis ...................................................................... 48 IV.1 Descripción de prueba de caja negra .................................................... 48 Conclusiones .................................................................................................... 51 Recomendaciones............................................................................................ 52 Bibliografía ....................................................................................................... 54 Anexos ............................................................................................................. 55 Anexo 1 ......................................................................................................... 55 Anexo 2 ......................................................................................................... 56.

(9) Introducción El perfeccionamiento continuo al que aspira el Ministerio de Educación Superior (MES) en todos sus planes de estudio, tiene por fundamento el logro de un modelo de formación del profesional que integre en sí, tanto el desarrollo de las habilidades necesarias para la cumplimentación de tareas en los diversos perfiles de la producción científica, como la creación de un individuo en consonancia con las problemáticas y necesidades de su nación y época histórica. Con arreglo a ello la Comisión Nacional de Carrera (CNC), elabora un documento denominado Plan de Estudio dentro del cual se encuentra el modelo del profesional1, en el que se declaran las líneas directrices hacia las cuales se orientará el trabajo docente y metodológico y en el cual quedan reflejados los objetivos generales que persiguen las diferentes especialidades en términos del logro de una óptima formación profesional, ética y científica de sus egresados. Sin embargo, la formación científico-profesional del alumnado no ha sido la única meta trazada por el Ministerio de Educación Superior, sino que también es motivo de atención la gestión universitaria concreta para el logro de tal perfeccionamiento. En este sentido es que se crea, mediante la Resolución No. 150/99 del Ministerio de Educación Superior el Sistema Universitario de Programas de Acreditación (SUPRA), cuyo objetivo principal es: “contribuir a la mejora de la calidad de la educación superior en Cuba mediante la certificación al nivel nacional e internacional de programas e instituciones que cumplan requisitos de calidad establecidos”.2 Con motivo de la implementación a gran escala del sistema SUPRA se crea la Junta de Acreditación Nacional, también conocida por la sigla JAN, cuyos objetivos son “(…) promover, organizar, ejecutar y controlar la política de. 1. Esta nomenclatura aparece expresada en el sitio web oficial del MES: www.mes.edu.cu/index.php/47estudiar-en-cuba/27-sistema-universitario-cubano 2 Ibidem.. …1.

(10) acreditación para la Educación Superior del país a través de los órganos auxiliares que dirige”.3 El Sistema Universitario de Programas de Acreditación opera a través de un marco legal que asegura su desempeño y se compone por varios sistemas de evaluación, siendo estos lo siguientes: el Sistema de Evaluación y Acreditación de Maestrías (SEA-M), sistema de Evaluación y Acreditación de Carreras (SEA-CU), el Sistema de Evaluación Institucional y el Sistema de Evaluación y Acreditación de Doctorados (SEA-Dr.) Los sistemas de acreditación, en cualquiera de sus expresiones, son procesos que detentan una serie de procedimientos complejos de recopilación de información, de los cuales la acreditación de la carrera es uno de sus momentos. Según la definición dada por el CONEAU, el sistema de autoevaluación es un “Proceso de estudio de una carrera profesional universitaria, el cual es organizado y conducido por sus propios integrantes, a la luz de los ﬁnes que persiguen y con un conjunto aceptado de estándares de desempeño como referencia”4. De modo que este proceso, que contiene una determinada dinámica basada en parámetros pre-establecidos de carácter obligatorio y un determinado orden de ejecución y manipulación de los datos muestra una tendencia hacia la complejización de sus estándares que, de no implementarse correctamente, puede dar al traste con todo el proyecto. Por estas razones se muestra como esencial para una ejecución óptima de los requisitos y estándares mediante los cuales se rigen estos procesos tipo, disponer de un sistema que permita una fácil interconexión y manejo de los datos correspondientes al proceso de gestión de la carga docente y de la autoevaluación de la carrera por parte del Departamento de Computación. En años anteriores se han desarrollado trabajos de diplomas que abordan esta problemática (Santana, 2013, Sarduy, 2013) y en ambos casos se desarrollaron aplicaciones desktop independientes que comparten la misma 3. Ver en el sitio web oficial del MES: www.mes.edu.cu/index.php/47-estudiar-en-cuba/27-sistemauniversitario-cubano 4 Consejo de Evaluación, Acreditación y Certificación del a Calidad de la Educación Superior Universitaria, Ministerio de la Educación, Perú. …2.

(11) base de datos. La dificultad que presentan las aplicaciones mencionadas reside en que ambas trabajan por separado los roles de los mismos actores por lo que un. usuario. debe. acceder. a. ambas. para. lograr. desarrollar. sus. responsabilidades. En el año 2014 se desarrolla otro trabajo de diploma (Cabrera and Hernández, 2014). en el que se analizan nuevas tecnologías que permitan integrar e. interoperar las diferentes aplicaciones que se han desarrollado con anterioridad para el apoyo a la gestión informática del Departamento de Computación y del CEI. En este trabajo se propone el uso de los servicios web como estrategia a utilizar para resolver los problemas de integración e interoperabilidad que presentan los sistemas desarrollados hasta la actualidad. En consecuencia se propone responder a la actualidad de esta problemática a través de la consecución del siguiente Objetivo General: - Desarrollar servicios web para el manejo de la información asociada al Departamento de Computación y las carreras que atiende, que garanticen el acceso y modificación de la carga docente de los profesores del departamento y apoye la gestión de los procesos de autoevaluación de las carreras atendidas, utilizando tecnologías web. Este objetivo será desarrollado a través de la cumplimentación de los siguientes Objetivos específicos: 1. Diseñar una Base de Datos para almacenar la información que facilite la gestión del Departamento de Computación. 2. Diseñar servicios web referentes a plan de estudio y profesor como servicios web primarios. 3. Implementar los servicios web definidos anteriormente. 4. Validar los servicios web implementados desarrollando nuevos servicios web para la carga docente y el apoyo a la autoevaluación de la carrera. 5. Desarrollar una aplicación de apoyo a la gestión de la autoevaluación y la carga docente de las carreras atendidas por el Departamento de Computación.. …3.

(12) En consonancia con las tareas antes mencionadas se plantean las siguientes preguntas de investigación para guiar el desarrollo del trabajo. 1. ¿Cómo determinar y organizar toda la información necesaria para gestionar la asignación y el control del trabajo de los docentes del Departamento de Computación, en relación al apoyo al proceso de autoevaluación de las carreras atendidas por ese departamento? 2. ¿Cómo desarrollar los servicios web necesarios para el desarrollo de las aplicaciones de control del trabajo de los docentes del Departamento de Computación?. El presente trabajo estará estructurado de acuerdo a la siguiente secuencia lógica:. introducción,. cuatro. capítulos,. conclusiones,. recomendaciones,. bibliografía y 2 anexos. En el capítulo 1 se llevará a cabo el levantamiento teórico y la caracterización de las tecnologías de programación a utilizar en el cuerpo del trabajo y además, se realizará una descripción teórica de las herramientas que se utilicen para la confección del sistema. En el capítulo 2 se abordará lo relacionado a la implementación del sistema así como la presentación de los principales modelos, diagramas y requisitos funcionales y no funcionales que caracterizan el software en cuestión. En el capítulo 3 se describen las propuestas de solución a desarrollar, así como la arquitectura del sistema y los diferentes diagramas que documentan dicha solución. En este capítulo también se explicará el diseño que posee la base de datos de la aplicación. En el capítulo 4 se llevarán a cabo las pruebas de análisis al software -entre ellas la prueba de caja negra-, mediante las cuales se determinará si subsisten errores en la concepción y desarrollo de la aplicación.. …4.

(13) Capítulo I: Caracterización de la arquitectura SOA y los Servicios Web I.1 Descripción y análisis del problema La aplicación original denominada Sistema de Ayuda a la Autoevaluación de la Carrera, por sus siglas SAAC, que dio inicios a este trabajo surge como un sistema de gestión de información para el apoyo al proceso de autoevaluación de la carrera Ciencia de la Computación. Originalmente el sistema fue concebido para que las funcionalidades fueran ejecutadas por el coordinador de carrera, responsable de realizar la autoevaluación de la carrera. En la medida que se profundiza en dicho proceso se manifiesta una tendencia a complejizarse debido a que la autoevaluación de la carrera de Ciencia de la Computación está en manos de varias personas, sean estos: el coordinador de carrera, el jefe de departamento, el vicedecano docente, el director del Centro de Estudios de Informática (CEI), entre otros. Además se maneja un gran volumen de información y este se encuentra disperso entre las personas mencionadas anteriormente. Esta primera versión fue una aplicación desktop (Santana, 2013) en la que se recogía la información de todos los involucrados y se almacenaba en una base de datos -común a otro sistema de trabajo del departamento (Sarduy, 2013)- de la cual se podían obtener reportes de dicha información que servían de base para la autoevaluación, siendo estos: el porciento de doctores, de másteres, de profesores con categoría superior, etc. De acuerdo al diseño de la aplicación original, ésta debía tener necesariamente instalada la biblioteca Java Runtime Enviroment 6 para su ejecución en cada unidad máquina. Por los requerimientos de carácter esencial que presenta el software anteriormente mencionado, el nivel de acceso a la aplicación se encuentra limitado sólo al ordenador donde se cumplen dichas condiciones, además de requerir de una instalación y actualización personalizadas. Se presenta además el agravante de que, de realizarse modificaciones o inclusiones de nuevas funcionalidades en la aplicación, se hace necesario …5.

(14) realizar una nueva distribución del software a todos los usuarios que trabajan con él. En el análisis realizado por Cabrera y Hernández (2014) con objeto de la discusión de su trabajo de diploma, y en lo referido al tema de la gestión de la carga docente y la acreditación de la carrera de Ciencia de la Computación, que deberían manejar las aplicaciones diseñadas e implementadas por (Sarduy, 2013) aplicaciones hacia una arquitectura basada en servicios web que posibilite una flexibilización y un mayor nivel de accesibilidad a la hora de realizar cambios o interactuar con ellas. Esta descripción del problema da lugar a los epígrafes que continúan en el capítulo y que presentan el marco teórico de la investigación realizada. I. 2 Caracterización de la Arquitectura Orientada a Servicios (SOA) La rápida evolución que presenta el desarrollo de la ciencia y la técnica en el mundo actual marca como parámetro indispensable la necesidad de que sus resultados -representados bajo las disímiles formas que adquiere la tecnología en nuestro tiempo-, garanticen una respuesta rápida ante las transformaciones a las que están expuestas. En este sentido, optimizar los procesos mediante los cuales éstas operan y dotarlos de flexibilidad se ha convertido en un factor determinante para la competitividad y el crecimiento de las organizaciones que las utilizan como base de su desarrollo. Este factor puede verse seriamente alterado si dichos procesos se apoyan en entornos de Tecnologías de Información (IT) que no pueden responder de forma ágil a los cada vez más fluctuantes cambios que afectan el desarrollo de su actividad y potencialidad. Es en este sentido que la visión que debe preponderar como característica propia en las aplicaciones y recursos de IT es la de poseer un grado de accesibilidad y flexibilidad que permita a todo tipo de usuario u organización, facilitar la optimización de sus procesos.. …6.

(15) La inflexibilidad genera costes, reduce la capacidad de respuesta ante los clientes, compromete el cumplimiento con las normativas legales y afecta negativamente a la productividad de los empleados (Corporation, 2006). Para proporcionar un sistema de alta disponibilidad que contribuya a una mayor integración y comunicación entre el software y su futura aplicación, se hace necesaria la utilización de herramientas que garanticen la interacción entre los sistemas y sus aplicaciones, de modo que el diseño de su propia estructura contemple la posibilidad de facilitar cambios a posteriori. Una de las herramientas que proporciona un marco de trabajo viable para la consecución de una infraestructura flexible es la Arquitectura Orientada a Servicios, más conocida por sus siglas en inglés SOA. I.2.1 Tratamiento teórico conceptual de la arquitectura SOA La Arquitectura Orientada a Servicios (SOA) ha sido tratada y definida por varios autores, en su mayoría por empresas y corporaciones internacionales encargadas del desarrollo de la ingeniería de software. Su primera definición fue dada en 1996 por la empresa consultora y de investigación de las tecnologías de la información Gartner Group, con sede en Estados Unidos. Esta la define de la siguiente forma: “SOA es una arquitectura de software que comienza con una definición de interface y construye toda la topología de la aplicación como una topología de interfaces, implementaciones y llamados a interfaces. Sería mejor llamada “arquitectura orientada a interfaces”. SOA es una relación de servicios y consumidores de servicios, ambos suficientemente amplios para representar una función de negocios completa” (Gartner Group, 2002). Como en esta postura SOA es comprendida como una arquitectura que trabaja básicamente en la construcción de una topología de interfaces, y reconociendo que una interfaz es el modo elemental mediante el cual el usuario se comunica con la máquina, se tiene que esta ofrece como beneficio directo una mejor interacción entre usuario-aplicación. Es por tanto, una arquitectura que permite. …7.

(16) lograr una mayor agilidad en la aplicación de cambios a un sistema determinado. Otra de las definiciones principales sobre SOA es la dada por el consorcio internacional World Wide Web, en su abreviatura W3C y citada en (Quiroga, 2011) donde se define como: “Conjunto de componentes, los cuales pueden ser invocados y cuyas descripciones de interfaces pueden ser invocadas y descubiertas”. En lo referente a la aceptación de la anterior definición, el instituto federal estadounidense de investigación y desarrollo -encargado de desarrollar modelos de evaluación y mejora en el desarrollo de software-, denominado Software Engineering Institute (SEI); ha rechazado su supuesto presentando como argumento que ésta sobreestima el papel de los componentes de SOA, no considerando el rol de la práctica y construcción de la arquitectura como partes importantes de su proceso de conformación. Y en este sentido queda definida como: “Estilo resultante de políticas, prácticas y frameworks que permiten que la funcionalidad de una aplicación se pueda proveer y consumir como conjuntos de servicios, con una granularidad relevante para el consumidor. Los servicios pueden invocarse, publicarse y descubrirse y están implementación utilizando una. abstraídos de su. sola forma estándar de interface” (Konrad,. 2009). En este concepto se puede apreciar cómo se va ampliando el espectro de comprensión de la Arquitectura Orientada a Servicios, la cual ya es entendida como un proceso en el cual interactúan diferentes herramientas lógicas. Se le agrega además la utilización de un marco de trabajo determinado, denominado framework o infraestructura digital, con arreglo al cual otro proyecto de software puede ser más fácilmente organizado y desarrollado. Queda determinado, por tanto, que SOA permite o facilita una mejor integración entre aplicaciones.. …8.

(17) Otra definición cardinal referida a la Arquitectura Orientada a Servicios es la expuesta por la corporación multinacional de computadoras, tecnología y consultoría de IT, IBM (International Business Machines), quien la define como: “Una arquitectura de aplicación en la cual todas las funciones se definen como servicios independientes con interfaces invocables bien definidas, que pueden ser. llamadas. en. secuencias. definidas. para. formar. procesos. de. negocios”(Konrad, 2009). Se hace notar en esta conceptuación el hecho de que SOA no tiene una única finalidad, sino que ésta proporciona un marco de reutilización de sus componentes, con lo cual se infiere que sirve como base de ejecución para disímiles aplicaciones. Por lo tanto, SOA se ofrece como generador viable de metodologías flexibles y susceptibles de recibir adaptación mediante una fácil accesibilidad. Por lo ya expuesto, se toma como punto referencial de este trabajo para la comprensión de la Arquitectura Orientada a Servicios el enfoque de la definición dada por la IBM, en conjunto con la conceptuación dada en el año 2014 por Macarena Vera, para quien ésta es: “… un marco de trabajo conceptual que establece una estructura de diseño para la integración de aplicaciones, que permite a las organizaciones unir los objetivos de negocio, en cuanto a flexibilidad de integración con sistemas legados y alineación directa a los procesos de negocio, con la infraestructura de TI”. (Vera, 2014) I.2.2 Requerimientos para el despliegue de SOA. De acuerdo con lo anteriormente expuesto se tiene que la Arquitectura Orientada a Servicios (SOA) no es sólo un arquitectura de servicios, sino que ésta también implica un serie de “…políticas, prácticas y frameworks con los que se garantiza la forma correcta de que los servicios sean provistos y consumidos” (Sprott and Wilkes, 2004).. …9.

(18) Por cuanto se tiene que SOA también proporciona una metodología de trabajo que brinda especial soporte a la actividad de integración y consolidación de datos, para cuya aplicación se precisan de una serie de requerimientos previos para su despliegue. Los requerimientos a tener en cuenta para la implementación de SOA son fundamentalmente cinco: Recursos existentes: Los recursos existentes son aquellos datos de vital importancia para la aplicación así como las aplicaciones que deben ser integradas en los nuevos sistemas. Soportar todo tipo de integración requerida: En este requerimiento se incluye la interacción con los usuarios, así como la conectividad de la aplicación, la integración de procesos y la integración de la información. Permitir el crecimiento de implementaciones y la migración de los recursos: Este requerimiento en especial muestra el aspecto más crítico para las implementaciones de esta arquitectura pues, de acuerdo a como se utilicen los componentes existentes en la aplicación, dependerá la disminución o no del margen de fallos. Construir un marco de componentes estándar: A partir de este requerimiento se hace posible una mayor reutilización de los módulos y sistemas con los que cuenta la aplicación. Permitir implementaciones de nuevos modelos de cómputo Por tanto, que la implementación de SOA surja como un entorno perfecto para lograr altos estándares de evolución hacia modelos de negocios y de colaboración con un elevado perfil de flexibilidad y adaptabilidad, dependerá en gran. medida. de. la. correcta. implementación. de. los. requerimientos. anteriormente señalados.. … 10.

(19) I.3 Caracterización de las tecnologías de programación a utilizar I.3.1 El servicio Web como facilitador tecnológico de SOA Los. servicios. Web. surgen. en. respuesta. a. la. problemática. de. la. interconectividad y comunicación que se hacía imprescindible lograr entre las distintas plataformas y lenguajes de programación. Esta necesidad de estandarización había encontrado anteriormente varios intentos de superación, de los cuales son ejemplos el sistema para la comunicación entre computadoras conectadas a la red, creado por la Microsoft y denominado Distributed Component Object Model (Modelo de Objetos de Componentes Distribuidos, DCOM), y CORBA. Ambas tentativas de consensuar las distintas plataformas existentes y los lenguajes de programación resultaron inoperativas. Según (Brea, 2005), “…tiene la desventaja de que su implementación en un ambiente como es Internet, es casi imposible (muchos firewalls bloquean este tipo de mensajes, lo que hace prácticamente imposible a dos computadoras conectadas por Internet comunicarse)”. Es a partir del año 1999 que se comienza a implementar la estandarización de los Web Services como una vía para el óptimo intercambio de datos entre las diferentes aplicaciones. Además, la interconectabilidad entre programas que éstos permiten también hace posible “…la reutilización de funciones… ya sea para un uso personal en distintos proyectos, para comercializarlos o adquirir prestaciones de terceros”.5 La revisión bibliográfica realizada sobre la temática ha demostrado que el tratamiento y definición del término Web Services cuenta con varias acepciones, las cuales no se diferencian entre sí significativamente. Las discrepancias que se pueden observar en la comparación de las mismas es mayormente de carácter sintáctico. Entre ellas se encuentra la dada en el libro Web Services con C# en el cual éste se encuentra definido como: “…un estándar de comunicación entre. 5. Consultar en: http://www.bdp.com.bo/sistema/usuarios/archivos/capitulogratis.pdf; pp. 17. … 11.

(20) procesos. y. o. componentes,. diseñado. para. ser. multiplataforma. y. multilenguaje…”6 Otro de los autores que han proporcionado una definición del término es Orlando Fabián Brea, para quien un Web Services es “…un sistema software diseñado para soportar la interoperabilidad máquina - máquina a través de una red” (Brea, 2005). Mario Saffirio es otro de los autores que aporta una clara definición en la que expone qué es un Web Services. Este afirma que es una “…forma estandarizada de integrar aplicaciones Web mediante el uso de XML, SOAP, WSDL y UDDI sobre los protocolos de la Internet” (Saffirio, 2006). En esta definición ya se encuentran enunciados cuáles son los diferentes componentes que conforman un Web Services. Según el taller realizado en septiembre de 2012 por el Instituto de Computación de la Universidad de Montevideo, Uruguay; el término Web Services queda definido como un “…servicio o funcionalidad que se encuentra disponible a través de Internet o Intranet, que usa una forma estandarizada de mensajería (generalmente XML), y que no se encuentra atado a ningún sistema operativo ni ningún lenguaje de programación. Además, se puede autodescribir (generalmente vía XML) y puede ser descubierto a través de un mecanismo de búsqueda” (Uruguay, 2012). Debido a las funcionalidades que presentan los Web Services se ha decidido llevar a cabo la realización del objetivo general de este trabajo a través de la creación de un servicio web, mediante el cual se haga factible el desarrollo, gestión y ejecución de la información que requiere el departamento de Computación, en lo referente al proceso de acreditación de las carreras atendidas por este. I.3.2 Breve descripción de los componentes que integran un Web Services. El Web Services realiza sus disímiles funcionalidades a través de cuatro elementos fundamentales7, mediante los cuales se hacen posibles las 6. Ibídem. … 12.

(21) intercomunicaciones e intercambios de datos que éste ofrece como facilidades de uso. Estos elementos son los siguientes: el eXtensible Markup Language (XML), el Web Services Description Language (WSDL), el Simple Object Access Protocol (SOAP) y el Universal Discovery Description and Integration (UDDI). Brevemente se describen las principales características y funciones que estos cumplen como componentes de un Web Services. I.3.2.1 eXtensible Markup Language (XML) El XML fue diseñado fundamentalmente para ejecutar la descripción de datos en los documentos Web. La principal ventaja que éste ofrece es que permite a los diseñadores crear sus propias etiquetas (tags), facilitando con ello una óptima modificación, definición, transmisión, validación e interpretación de datos entre aplicaciones. De modo que se presenta como un lenguaje con alto grado de flexibilidad, que presta más atención al contenido de la información. I.3.2.2 Web Services Description Language (WSDL) El WSDL se conforma en un protocolo, basado fundamentalmente en XML, mediante el cual se presentan los accesos al Web Services. Generalmente puede ser comprendido como un manual de operaciones que indica qué interfaces provee el Web Services, así como cuáles son los tipos de datos necesarios para la utilización del mismo. I.3.2.3 Simple Object Access Protocol (SOAP) SOAP es un protocolo basado en XML y es principalmente el responsable del sistema de comunicación de base existente entre los Web Services. Tiene como característica propia que es independiente de plataforma y de lenguaje, por lo que ofrece un amplio espectro de posibilidades de adaptación. I.3.2.4 Universal Discovery Description and Integration (UDDI) El UDDI conforma un modelo de directorios para los Web Services, cuya función es mantener estandarizada en un formato universal la información que se maneja dentro del mismo, así como sus capacidades, requerimientos y. 7. Confróntese el dato en el siguiente libro: Manual de Web Services en PHP, pp. 1. … 13.

(22) ubicación. De modo general, el UDDI permite conocer cuáles son los servicios que ofrece el Web Services en cuestión. I.4 El gestor de base de datos PostgreSQL PostgreSQL es considerado en la actualidad como “…el gestor de base de datos de código abierto más avanzado…” (PostgreSQL, 1996) el cual, además de incluir. la posibilidad de operar con diferentes tipos de datos como los. numéricos, de punto. flotante, enteros, cadenas de caracteres, cantidades. monetarias, fechas, entre otros; ofrece la posibilidad de que los usuarios puedan hacer fácilmente extensible el sistema y su operatividad. Este gestor de base de datos incorpora cuatro conceptos básicos adicionales tales como: clases, herencia, tipos y funciones; los cuales permiten una mayor facilidad de administración e implementación de estándares. Este reconocido gestor de base de datos utiliza un modelo cliente/servidor multiproceso que garantiza que, de existir un error en uno de los procesos, este no afecte al resto y el sistema siga funcionando sin inconvenientes. Entre sus características que lo postulan como uno de los sistemas de gestión de bases de datos más potentes y robustos del mercado está el hecho de que “…funciona muy bien con grandes cantidades de datos y una alta concurrencia de usuarios accediendo a la vez al sistema” (Martinez, 2010). Otra de sus ventajas es la referida a que al gestor de base de datos PostgreSQL se puede acceder desde varios lenguajes de programación, tales como: C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, PHP, Lisp, Scheme, Qt y muchos otros; además de poseer una amplia. capacidad de. almacenamiento. De acuerdo a las características antes expuestas se decide escoger para el desarrollo de la aplicación web al gestor de base de datos PostgreSQL como soporte para la gestión y almacenamiento de la información con la que opera el Departamento de Computación, en el proceso de acreditación de las carreras.. … 14.

(23) I.5 El marco de trabajo Symfony 2.4 Symfony 2.4 es un marco de trabajo diseñado de acuerdo al patrón Modelo Vista Controlador para el desarrollo de aplicaciones web, el cual proporciona una serie de herramientas encaminadas a optimizar y reducir el tiempo de creación de una aplicación web de alta complejidad. Dentro del espectro de funciones que ofrece este marco de trabajo está que permite al desarrollador la automatización de una amplia gama de tareas desde la reutilización de códigos ya creados. Esta característica dota a la infraestructura digital Symfony 2.4 de una flexibilidad ilimitada que lo hace, además de totalmente configurable, altamente adaptable a un ambiente cambiante de producción. Symfony 2.4 está desarrollado completamente en PHP 5.3 y es compatible con la mayoría de los gestores de bases de datos existentes, tales como: MySQL, PostgreSQL, Oracle y Microsoft SQL Server. Symfony puede ser ejecutado además en diferentes sistemas operativos como: Unix, Linux y Windows. Entre las características que presenta este marco de trabajo se tiene que permite la internacionalización para la traducción del texto de la interfaz, los datos y el contenido de localización. Además los formularios pueden ser validados automáticamente, lo cual asegura mayor integridad en los datos y ofrece la facilidad de crear áreas restringidas que posibilitan un alto grado de seguridad al sistema. El marco de trabajo Symfony 2.4 también posee un enrutamiento y URLs inteligentes que hacen más asequible la navegación dentro de la aplicación. Los plugins que este framework posee proveen además a su estructura un alto nivel de extensibilidad; entre otras funcionalidades no menos importantes. Debido a las facilidades de uso que presenta Symfony 2.4 como marco de trabajo se hace factible su utilización para el proceso de desarrollo de la aplicación propuesta en el cuerpo del presente trabajo, sobre todo en lo referente a los términos de flexibilidad que permite a la hora de satisfacer las. … 15.

(24) necesidades tanto de desarrolladores profesionales como de usuarios no técnicos en el proceso de desarrollo de aplicaciones. I.5.1 Generador de archivos WSDL BeSimpleSoapBundle BeSimpleSoapBundle es una biblioteca desarrollada conjuntamente por Christian Kerl y Francis Besset para construir en Symfony 2 una serie de servicios SOAP y archivos WSDL basados en Servicios Web. Este generador de servicios cuenta con las Anotaciones para describir tanto el nombre del método a utilizar, como los parámetros que se introducen en calidad de datos. A través de las Anotaciones también se describen los resultados o tipos de datos a obtener por el servicio web. Las Anotaciones son comentarios que se encuentran incluidos en el código fuente de la aplicación y que, a diferencia de los comentarios normales, no se ignoran e incluso pueden influir en la ejecución del código. El bundle define varios tipos de datos, tales como: el string, el boolean, el int, el float, el date, el dateTime; y además posee los arreglos que cada uno de los tipos de datos anteriormente mencionados requiere. También el bundle permite crear arreglos asociativos a través de clases mapeadas con las Anotaciones, para después hacer uso de estas.. Figura 1. Método deleteAsignServicio. … 16.

(25) A continuación se explica cómo funciona el método deleteAsignServicio presentado en la Figura 1. @Soap\Method: Define el nombre de la función que identifica los métodos de los servicios web. @Soap\Result: En esta propiedad se define el tipo de dato a devolver por el método. @Soap\Param En esta propiedad se indican los atributos y el tipo de dato del atributo que necesita el método para su ejecución. Puesto que el bundle permite “…utilizar funcionalidades construidas por terceros o empaquetar tus propias funcionalidades…”8, además de crear de forma automática la estructura de los archivos WSDL; este se presenta como una vía idónea para realizar los servicios web que requiere la aplicación propuesta. I.6 El sistema de infraestructura WAMP El sistema de infraestructura digital WAMP deriva su nombre de las cuatro herramientas operativas que utiliza, las cuales son: Windows como sistema operativo; Apache como servidor web; MySQL como gestor de bases de datos y PHP, Perl o Python, como lenguajes de programación. El uso de WAMP como servidor para la aplicación a desarrollar permitirá crear páginas html que podrán ser publicadas en Internet, y además ofrecerá la opción de gestionar datos en ellas. Al mismo tiempo WAMP proporcionará la posibilidad de utilizar varios lenguajes de programación para el desarrollo de dichas aplicaciones web.. 8. Confróntese en: http://librosweb.es/libro/symfony_2_x/capitulo_4/el_sistema_de_bundles.html. … 17.

(26) Capítulo II: Implementación de los Servicios Web para el apoyo a la Autoevaluación de la Carrera y la Carga Docente II.1 Declaración de las funciones, atribuciones y obligaciones de los principales actores del software. De acuerdo con los objetivos que se traza el Ministerio de la Educación Superior en torno a lograr una formación integral del profesional egresado de los institutos de altos estudios, el MES ha elaborado un documento cuyo objetivo es regular y estandarizar los procedimientos y las funciones de los implicados en el proceso de la labor docente educativa, con vistas a mejorar el escenario actual en el cual se desarrolla la misma. En este documento, denominado “Marco regulatorio de la organización: Funciones, atribuciones y obligaciones de las principales autoridades en el eslabón de base y de los colectivos metodológicos asesores”; se especifican cuáles son las programáticas que deben cumplimentar la facultad-carrera, la facultad-multicarrera, el departamento-disciplina, el departamento-carrera, el colectivo de carrera y comisión nacional de carrera; así como las atribuciones y obligaciones de sus titulares, respecto de lograr el constante incremento de la eficacia en las gestiones docentes propuestas como finalidad. Teniendo en cuenta los objetivos específicos por los que se rige el cuerpo del presente trabajo sólo se tomarán en cuenta, -y así aparecen modelados en las funcionalidades con las que cuenta el software creado para darles cumplimiento- aquellas partes del documento anteriormente mencionado en las cuales se definen las funciones, atribuciones y obligaciones de los siguientes titulares: el jefe de departamento y el coordinador del colectivo carrera o coordinador de carrera. En el cuerpo del documento aparecen diseñadas para el jefe de departamento, como representante en sí mismo y máximo responsable de la dirección eficiente y pertinente de las actividades docentes educativas del departamento, una serie de tareas a las cuales debe restringirse su actividad. Algunas de estas tareas son: … 18.

(27) 1- Dirigir el proceso de formación de los profesionales en las disciplinas y asignaturas del departamento, con énfasis en la labor educativa y político ideológica. 2- Dirigir el trabajo de los alumnos ayudantes, de los graduados universitarios en adiestramiento y del personal a tiempo parcial del departamento. 3- Elaborar y controlar los planes de formación posgraduada y superación científico-pedagógica del personal docente de su departamento, de modo que favorezca el tránsito a categorías docentes superiores. 4- Elaborar el plan de trabajo metodológico del departamento y controlar su ejecución, enfatizando en la formación de valores desde la instrucción.. En lo que respecta a las responsabilidades asignadas en el documento al coordinador de colectivo carrera o coordinador de carrera, éste cuenta con una similar programática de actividades a cumplir con arreglo al resultado de las cuales será evaluado en su desempeño docente. Algunas de estas actividades son: 1.. Participar en la elaboración de la estrategia educativa de la carrera y asesorar su implementación en cada año académico.. 2.. Participar en el diseño del plan de estudio, proponer adecuaciones e incluir las modificaciones aprobadas.. 3.. Registrar fortalezas y debilidades en la ejecución del plan de estudio y proponer a la autoridad académica a la cual se subordina, las futuras acciones a desarrollar con vistas a su mejora continua.. 4.. Participar activamente en el proceso de evaluación y acreditación de la carrera en coordinación con la autoridad académica a la cual se subordina.. Del adecuado cumplimiento de los roles asignados a los jefes de departamento y coordinadores de carrera, depende en su totalidad la correcta gestión de la carrera en cuanto a la consecución de los objetivos trazados para el fortalecimiento del eslabón de base.. … 19.

(28) II.2 Actores y caso de uso del negocio. Con arreglo a las funcionalidades declaradas en el epígrafe anterior respecto de las obligaciones y atribuciones asignadas a los jefes de departamento y de carrera, se pueden determinar los siguientes casos de uso del negocio:. Figura 2. Casos de Uso del Negocio correspondiente al Jefe de Departamento. Figura 3. Casos de Uso del Negocio correspondiente al coordinador de Carrera. … 20.

(29) II.3 Descripción de los actores y los casos de uso del sistema a automatizar En la tabla siguiente se describen cuáles son los actores del sistema y las funciones que ejecutan en la aplicación. Actor. Descripción. Usuario. Este actor tiene la posibilidad de realizar la acción de autentificarse en el sistema y una vez hecho esto puede consultar los reportes.. Jefe de. Este actor hereda las funciones del actor usuario y además. Departamento. tiene la posibilidad de gestionar los datos referentes a los profesores y sus cargas docentes, los alumnos ayudantes y los contenidos de los cursos de postgrados.. Coordinador de. Este actor hereda las funciones del actor usuario y además. Carrera. tiene la posibilidad de gestionar cambios a los planes de estudios, las disciplinas y las asignaturas; así como realizar la evaluación de la carrera. Tabla 1. Descripción de los actores del sistema II.4 Requisitos funcionales y no funcionales del sistema Los requisitos funcionales según (Sommerville, 2002) son “…declaraciones de los servicios o funcionalidades que proveerá el sistema, de la manera en que este. reaccionará a entradas. particulares y de cómo se. comportará. en. situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.” La tipología de los requisitos funcionales en todo caso depende del tipo de software del cual es componente, del tipo de sistema en que se desarrolle y de los posibles usuarios hacia los cuales va dirigido el software. Por ello, y teniendo en cuenta lo anteriormente mencionado, seguidamente se exponen. … 21.

(30) los requisitos funcionales más representativos que se han tenido en cuenta posteriormente en el desarrollo de la aplicación, los cuales son: 1. Gestionar las versiones de los Planes de Estudios asociados a una carrera: El coordinador de carrera es el encargado de insertar, eliminar o modificar los datos del plan de estudio. 2. Gestionar las Asignaturas: El coordinador de carrera es el encargado de insertar, eliminar o modificar los datos de las asignaturas asociadas al plan de estudio correspondiente.  2.1 Adicionar asignatura. En este caso se toma como caso de uso principal a Adicionar asignatura, para hacer referencia de él en la especificación de los casos de uso.  2.2 Eliminar asignatura  2.3 Modificar asignatura 3. Gestionar Profesores: El jefe de departamento es el encargado de insertar, eliminar o modificar los datos correspondientes a los profesores. 4. Gestionar la carga docente de un profesor: El jefe de departamento es el encargado de insertar, eliminar o modificar la información relacionada con la carga docente de los profesores. 5. Gestionar eficiencias verticales y horizontales: El coordinador de carrera es el encargado de insertar, eliminar o modificar los datos de las eficiencias verticales y horizontales. 6. Gestionar alumnos ayudantes: El jefe de departamento es el encargado de insertar, eliminar o modificar los datos de los alumnos ayudantes. 7. Gestionar Cursos de Postgrados: El jefe de departamento es el encargado de insertar, eliminar o modificar los datos asociados a los cursos de postgrados. 8. Gestionar carga docente de Cursos de Postgrados: El jefe de departamento es el encargado de insertar, eliminar o modificar y asignar a los profesores a los diferentes cursos de postgrados. 9. Gestionar solicitud y prestación de servicios: El jefe de departamento es el encargado de insertar, eliminar o modificar los datos relacionados con la solicitud de prestación de los servicios.. … 22.

(31) 10. Consultar reportes: Cualquier usuario del sistema podrá acceder a los reportes que el sistema es capaz de generar. Los reportes que el sistema brinda son los siguientes:  Eficiencia vertical  Evaluación de la Carrera  Claustro anual  Claustro de la carrera  Relación de profesores asignatura del plan de estudio  Relación de los profesores con la especialidad, el grado científico, el título académico y la categoría docente.  Claustro por año académico. II.4.1 Requisitos no funcionales Tomando como base la definición que da el autor antes mencionado -Ian Sommerville- respecto de los requisitos no funcionales, tenemos que estos son “…restricciones. de. los servicios. o funciones. ofrecidos. por el sistema.. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.” Los requisitos no funcionales según el autor son aquellos que “…no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo. y. la. capacidad de almacenamiento”. (Sommerville, 2002) Los. requisitos no funcionales con los que cuenta la aplicación son los siguientes: 1. Portabilidad del sistema: El producto no requiere de instalación puesto que está desarrollado sobre una plataforma web. 2. Restricciones de diseño: El sistema utilizará un gestor de base de datos PostgreSQL y un servidor WAMP además de presentar una arquitectura de tipo SOA. 3. Diseño de la aplicación: La aplicación será diseñada con una interfaz. sencilla, fácil de usar, de manera que agilice y facilite el trabajo con el software.. … 23.

(32) 4. Seguridad: A los usuarios autorizados por el sistema se les garantizarán. el acceso a la información correspondiente. II.5 Diagramas de casos de uso del sistema En las siguientes figuras 5 y 6 se muestran los diagramas de actores y casos de uso válidos para cada uno de los actores del sistema, así como la herencia existente entre estos.. Figura 5. Casos de Uso del Sistema correspondientes al Usuario. Figura 6. Casos de Uso del Sistema correspondientes al Coordinador de Carrera. … 24.

(33) Figura 7. Casos de Uso del Sistema correspondientes al Jefe de Departamento.. Figura 8. Herencia existente entre actores. … 25.

(34) II.6 Descripción de los casos de uso más significativos del sistema La descripción de los casos de uso representa una herramienta lógica de gran importancia para comprender cómo se llevan a cabo las actividades a través de las cuales se opera con el software, desde los casos de uso. Por tanto, describe una secuencia de interacciones que se desarrollarán entre el sistema y sus actores en respuesta a eventos generalmente iniciados por los actores. A continuación se pasan a describir los casos de uso más significativos con los que cuenta el sistema en cuestión. En un primer momento se explica cómo se debe ejecutar la asignación de la carga docente en el nivel de pregrado. Y en un segundo momento se expone cómo se debe realizar la introducción de las asignaturas al sistema.. Caso de uso del. Gestionar la carga docente de un profesor. sistema Actores. Jefe de Departamento. Propósito. Insertar la carga docente del profesor correspondiente a la cantidad de grupos de conferencias, clases prácticas y laboratorios, a impartir de una asignatura respectivamente.. Resumen. El caso de uso del sistema se inicia cuando el jefe de departamento se dispone a planificar a un profesor la asignatura que impartirá en un curso y un semestre respectivamente.. Precondiciones. El Jefe de Departamento debe estar autenticado en el sistema. Se debe haber adicionado con anterioridad al menos un profesor, la cantidad de horas de conferencias, clases prácticas y laboratorios de la asignatura seleccionada. Además, se debe tener con anterioridad la cantidad de grupos del año en que se imparte la asignatura.. … 26.

(35) Descripción. Ventana 1. Flujo normal de los eventos Acción del actor. Respuesta del sistema. 1. El Jefe de Departamento elige el enlace Planificar Asignatura.. 2. El sistema muestra la Ventana 1 para la inserción de los datos.. 3. El Jefe de Departamento entra el nombre del profesor en (D). 5. Seguidamente se escoge el nombre de la asignatura en (A). 7. Los grupos de conferencias se seleccionan en (E). 9. Las clases prácticas se insertan en (B). 11. Los grupos de laboratorio se introducen en (C). 13. Luego se presiona (F) para guardar los datos.. 4. El sistema despliega (G) para la selección del profesor. 6. Se despliega (H) para elegir la asignatura. 8. El sistema despliega (K) para la selección de los grupos de conferencia. 10. Para la selección de los grupos de clase práctica se despliega (I). 12. El sistema despliega (J) para elegir los grupos de laboratorio. 14. Si los datos están correctos, el sistema los procesa y los almacena en la base de datos.. … 27.

(36) Flujo alternativo de los eventos Campo repetido o que ya ha sido introducido.. 16. Para salir de la ventana de error se presiona (M).. Post-condiciones.. Caso de uso del sistema Actores. 15. Si los datos están incorrectos se muestra la ventana de error (L). 17. El sistema muestra la ventana 1 (continua paso 1). Se guarda en la base de datos una nueva carga docente del profesor asignado y la asignatura a impartir. Adicionar asignatura. Coordinador de Carrera.. Propósito. Insertar una asignatura al sistema.. Resumen. El caso de uso del sistema se inicia cuando el Coordinador de Carrera adiciona una asignatura correspondiente a un plan de estudio.. Precondiciones. El Coordinador de Carrera debe estar autenticado en el sistema. Se debe haber adicionado con anterioridad un plan de estudio con sus disciplinas y asignaturas. Descripción. … 28.

(37) Flujo normal de los eventos Acción del actor. Respuesta del sistema. 1. El Coordinador de Carrera elige la. 2. El sistema muestra la ventana 1 para la. opción Adicionar Asignatura.. inserción de los datos.. 3. El usuario inserta el nombre de la asignatura en (A). 4. El total de horas de la asignatura se inserta en (B). 5. Se selecciona la disciplina en (C). 6.. 7.. seleccionar la disciplina.. Seguidamente. se. escoge. el. El. sistema. despliega. (H). para. nombre del plan de estudio en (D).. 8. Se despliega (I) para seleccionar plan de. 9. Posteriormente se selecciona el. estudio.. tipo de currículo en (E).. 10. Para seleccionar tipo de currículo se. 11. El año se elige en (F).. despliega (J).. 13. El tipo de evaluación de las. 12.. asignaturas se escoge en (G).. seleccionar el año.. 15. Luego se presiona (O) para. 14. El sistema muestra (K) para elegir tipo. guardar los datos.. de evaluación.. El. sistema. despliega. (L). para. 16. Si los datos están correctos, el sistema los procesa y los almacena en la base de datos.. … 29.

(38) Flujo alternativo de los eventos Campo Nombre de la Asignatura vacío o con valores numéricos. 3. El usuario inserta el nombre de la asignatura en (A).. 4. Se muestra la ventana (M). 5. El sistema comprueba que el campo no esté vacío o contenga valores numéricos. 6. El sistema muestra la ventana 1 (continúa paso 1).. Campo Total de Horas vacío o con valores alfabéticos. 3. El total de horas de la asignatura se inserta en (B).. 4. Se muestra la ventana (N). 5. El sistema comprueba que el campo no esté vacío o contenga valores numéricos. 6. El sistema muestra la ventana 1 (continúa paso 1).. Post-condiciones. Se guarda en la base de datos una nueva relación entre plan de estudio y asignatura.. II.7 Paquetes del software Los diagramas de paquetes son un tipo de modelado que muestra cómo se divide en agrupaciones lógicas un sistema, de acuerdo a las relaciones de interdependencia que presentan dichas agrupaciones. Por tanto, a través de los diagramas de paquetes se puede descomponer, para la fácil comprensión de la estructura de una aplicación, la jerarquía lógica que presenta el sistema. Las agrupaciones lógicas que presenta la aplicación desarrollada en este trabajo son las siguientes: - Controller: Es el encargado de gestionar toda la lógica del software para su correcto funcionamiento. - Entity: Son las clases del sistema que se transformarán en las tablas de la base de datos. … 30.

(39) - Resources: En este paquete se encuentra todo lo relacionado con las vistas y las rutas de la aplicación. - Form: Contiene todos los formularios a utilizar en el sistema. - Util: En esta agrupación se almacena lo referente a aquellos códigos que presentan un alto grado de reutilización. - Services: Este paquete contiene todos los servicios web creados en la aplicación. Dado lo anteriormente expuesto, a continuación se muestra el diagrama de paquetes que contiene la aplicación.. Figura 9. Diagrama de paquetes. … 31.

(40) Capítulo III: Descripción de la propuesta de solución En este capítulo se analiza la propuesta de solución computacional al problema planteado, describiendo los servicios web diseñados, la arquitectura del sistema y se muestran los diagramas de clase y de secuencia, entre otros elementos de apoyo a la comprensión de la solución. III.1. Arquitectura del Sistema Puesto que el sistema presenta una arquitectura SOA es necesario definir los principales servicios web con los que se realizará la gestión de los datos. En un primer momento se crean los siguientes servicios web primarios: 1. PlanEstudioService: es responsable se gestionar todo lo relacionado con las disciplinas, las asignaturas y los planes de estudio del Departamento de Computación. 2. ProfesorService: a través de éste se muestran los profesores del departamento, el grado científico y categoría que presentan. Estos representan la base de los servicios web ya pues que de ellos se los que siguen a continuación reutilizan parte del código de estos primarios. Otro servicio creado es CargaDocenteService. Este tiene la particularidad que reutiliza códigos de los servicios web mencionados anteriormente y es el encargado de planificar la carga docente de los profesores, distribuir las carreras por curso y semestres, se encarga de la planificación de los cursos de postgrado y pregrado entre otras funciones. Por último se crea otro servicio web llamado AutoevaluacionServices este que reutiliza código de los tres servicios web mencionados con anterioridad y es el responsable de crear la autoevaluación de la carrera en un curso determinado. En la siguiente figura 10 se muestra esquema referido a cómo queda la infraestructura de los servicios web, así como su relación con la aplicación.. … 32.

(41) Aplicación Web. CargaDocenteService. PlanEstudioService. AutoevaluacionServices. ProfesoresService. Infraestructura de Servicios Web Figura 10. Infraestructura de Servicios Web. III.2 El Modelo-Vista-Controlador (MVC) como patrón de arquitectura El Modelo-Vista-Controlador es un patrón de diseño que descompone en tres capas a una aplicación, siendo estas: el Modelo, la Vista y el Controlador. En el Modelo se representan los datos de la aplicación que contienen la forma lógica de manipular y acceder a la gestión de la información. Cada dato que sea parte persistente de la aplicación debe quedar reflejado en el modelo de objetos y los servicios que se expongan en él deben de ser lo suficientemente genéricos como para soportar a una variedad de clientes. La Vista es la responsable de mostrar el estado en el que se encuentra el modelo. Además, dentro de la Vista se encuentran encapsuladas las representaciones semánticas con las que opera la aplicación. Como consecuencia, la Vista puede actualizarse por ella misma cuando algún cambio efectuado en el Modelo le ha sido comunicado. … 33.

(42) El Controlador es el responsable, a su vez, de interceptar y traducir las entradas de los usuarios en acciones ejecutables para el modelo. Además, es responsable de seleccionar la siguiente Vista de acuerdo a los datos que el usuario introduce en el sistema. III.2.1 El Modelo-Vista-Controlador en Symfony 2.4 La arquitectura Modelo-Vista-Controlador es utilizada por una variedad de framework entre los cuales se encuentra Symfony 2.4. Como el marco de trabajo que se ha elegido para el desarrollo de la aplicación web a que hace referencia este trabajo es precisamente ésta versión de Symfony, se hace imprescindible pasar a explicar cómo este framework hace uso y comprende la funcionalidad de dicha arquitectura. Symfony2 en general es un marco de trabajo que basa gran parte de su funcionamiento en la arquitectura MVC sin embargo, y según la declaración de su creador Fabien Potencier “"Symfony2 no es un framework MVC. Symfony2 sólo proporciona herramientas para la parte del Controlador y de la Vista.” (Potencier, 2011) En el siguiente esquema se muestra como Symfony2 aplica los principios fundamentales del Modelo-Vista-Controlador.. Figura 11. Esquema simplificado de la arquitectura interna de Symfony2. … 34.

(43) La forma con la que Symfony2 opera con la arquitectura Modelo-VistaControlador es la siguiente: 1. Cuando un usuario realiza algún tipo de petición a la aplicación, Symfony2 ejecuta el Controlador asociado a la página seleccionada. Un controlador es una clase PHP en la que se puede ejecutar cualquier código. 2. El Controlador solicita al Modelo los datos. El Modelo es una clase PHP especializada en obtener normalmente información de una base de datos. 3. Con los datos devueltos por el Modelo, el Controlador solicita a la Vista que cree una página mediante una plantilla y que inserte los datos del Modelo. 5. El Controlador entrega al servidor la página creada por la Vista. A modo de conclusión se puede afirmar que la forma con la cual Symfony2 opera con el Modelo-Vista-Controlador se resume de la siguiente manera: “...1) el Controlador manda y ordena, 2) el Modelo busca la información que se le pide, 3) la Vista crea páginas con plantillas y datos.” (Eguiluz, 2012) III.3 Diagramas de clases de diseño Un diagrama de clases es un tipo de diagrama estático mediante el cual se describe la estructura que posee un sistema a través de la exposición de sus clases y atributos, así como de las relaciones existentes entre ellos. Los diagramas de clases son generalmente utilizados durante el proceso de análisis y diseño de los sistemas, proceso en el cual se crean tanto el diseño conceptual de la información que se manejará en el sistema como los componentes que se encargarán del funcionamiento y la relación entre unos y otros. En los diagramas de clases de diseño se personifican los requerimientos que presenta una aplicación determinada a través de la descomposición del software en las entidades que lo componen. Por tanto, mediante el modelado del diagrama de clases de diseño se ofrece la representación de un objeto real en base a la descripción de su funcionamiento. En la siguiente figura se. … 35.

(44) muestra cómo se encuentra estructurado de forma general el diagrama de clases de diseño de la aplicación.. Figura 12. Diagrama de clases de diseño. Desde la clase principal el usuario elige el enlace planificar carga docente, el cual pasa a través de la clase controladora de nombre PlanificacionController y esta. crea. una. página. cliente. conformada. por. el. formulario. AsignaturaProfesorType. Una vez que se insertan los datos la información es enviada a la clase controladora PlanificacionController para guardar los datos referentes en la clase modelo denominada AsignaturaProfesor. III. 4 Diagrama de secuencia Los diagramas de secuencia son frecuentemente utilizados en etapas definidas de la producción de un software tales como: las fases de elaboración y construcción, así como de los flujos de análisis y diseño de una aplicación.. … 36.

(45) Como a través de los diagramas de secuencia se proporciona una forma de mirar un escenario basada en el tiempo, éstos resultan una herramienta de gran utilidad a la hora de mostrar cómo se realizan los casos de uso y cómo se comporta la interacción dada entre los determinados objetos o entidades del software. A continuación se muestran y explican los diagramas de secuencia para los casos de uso siguientes: Gestionar la carga docente de un profesor y Adicionar asignatura.. Figura 13. Diagrama de secuencia: Gestionar la carga docente de un profesor. El diagrama anterior muestra los pasos lógicos a seguir para que el sistema asigne la carga de pregrado a un profesor. Para ejecutar esta opción el Jefe de Departamento elige el enlace Planificar Carga Docente y, seguidamente, el sistema le muestra un formulario con los datos obligatorios a llenar. Una vez insertados los datos el sistema los envía a la clase controladora CargaDocenteController, la cual se encarga de validar la información recibida. Posteriormente. la. información. validada. se. envía. a. la. clase. CargaDocenteServices, en la cual se encuentra el servicio web encargado de insertar la información en la base de datos. Seguidamente el usuario, en este … 37.

(46) caso específico el Jefe de Departamento, recibe una notificación que confirma que todos los datos han sido procesados correctamente. Hacer notar que en el diagrama anterior, a la hora de almacenar la información en la base de datos, el sistema hace uso de los servicios web –en particular del servicio web CargaDocenteService- declarados en la infraestructura mostrada en la figura 10. En la siguiente figura se expone el diagrama de secuencia denominado Adicionar asignatura, que muestra un procedimiento análogo al anterior, solo que en este caso el Coordinador de Carrera adiciona una asignatura al sistema, utilizando para ello el servicio web declarado en la figura 10 y denominado PlanEstudioService.. Figura 14. Diagrama de secuencia: Adicionar asignatura. … 38.

(47) III.5 Tratamiento de errores en la validación de los datos. De forma general, el tratamiento de errores es un procedimiento que puede ser dado de disímiles formas, de acuerdo al tipo de error que se quiera gestionar. En el caso aplicado a nuestro sistema, el tratamiento de errores se ha realizado principalmente de acuerdo a tres formas: 1- El tratamiento de errores basado en las expresiones regulares de búsqueda. Esta forma consiste en comparar una serie de caracteres que forman un patrón con un conjunto externo de caracteres, con vistas a detectar las posibles coincidencias.. Este tipo de tratamiento de errores se utiliza principalmente en la parte del cliente. Para ello se utilizan dos librerías básicas mootools.js y formcheck.js. En esta última librería se declaran las reglas o patrones que se introducen cuando los formularios de Symfony2 son creados. En la figura 15 se muestran las reglas utilizadas en la aplicación para la validación de los datos.. Figura 15. Reglas utilizadas para el tratamiento de errores.. Hacer notar que dentro del atributo class mostrado en la Figura 16 se encuentra encapsulada la forma de utilizar las reglas definidas para los formularios de Symfony2 utilizados en la aplicación. … 39.

(48) Figura 16. Validaciones en los formularios de Symfoy2.. 2- El tratamiento de errores por medio del lanzamiento de excepciones. Este tipo de error de sistema ocurre con poca frecuencia pero, aún así se hace imprescindible contar con un manejo de errores de esta clase pues, a través de él se logra que las fallas de ejecución del software se reduzcan al mínimo posible. Por tanto, el tratamiento de errores por vía del manejo de excepciones permite crear una aplicación robusta y flexible, con un alto nivel de tolerancia de errores del sistema, lo cual posibilita que el programa se pueda seguir ejecutando sin verse afectado por dichas incongruencias. 3- El tratamiento de errores por aserciones. La validación de datos por aserción en Symfony2, que en el caso de esta aplicación es la infraestructura digital que se utiliza, “…se configura en las entidades, no en los formularios.” (Eguiluz, 2012) De esta manera las reglas de la captura y validación de los datos se encuentran especificadas desde la base del programa, permitiéndose con ello una detección temprana de errores. La forma específica a través de la cual Symfony ejecuta la validación de los datos son las Anotaciones.. III.6 Diseño de la base de datos La modelación de la base de datos es un elemento fundamental para expresar de acuerdo a un orden lógico, cómo se encuentran dispuestas las diversas entidades que conforman una base de datos. De modo que, a través del modelado de la base de datos se propicia una mejor comprensión de los tipos … 40.