Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA

Texto completo

(1)UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA ESCUELA DE SISTEMAS DPTO. DE COMPUTACIÓN. Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA.. Bachiller: Daniel A. Lobo. S. Tutor (a): Prof. Judith Barrios A. Proyecto de grado presentado ante la ilustre Universidad de Los Andes como requisito final para optar al título de Ingeniero de Sistemas.. Mérida, 28 de mayo de 2008..

(2) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Resumen. En el presente trabajo se propone el desarrollo de un sistema genérico (configurable) para la administración de un laboratorio de computación, siguiendo el marco metodológico que describe el método Watch, siguiendo cada una de las etapas que presenta el mismo: modelado de negocios, ingeniería de requisitos, diseño de la arquitectura, diseño. de componentes, aprovisionamiento de. componentes, ensamblaje de componentes, pruebas y entrega de la aplicación, la implementación del sistema se realizó a través de la herramienta CLEDA, que es un framework para el desarrollo de sistemas y por ultimo se muestra una evaluación de la herramienta CLEDA y del marco metodológico empleado.. Palabras clave: CLEDA, método watch, sistemas de información Web.. i.

(3) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Índice General. Pág.. CAPITULO I:INTRODUCCIÓN ....................................................................... 1 1.1 Definición del problema.......................................................................... 2 1.3 Objetivos ................................................................................................. 2 1.3.1 Objetivo general .................................................................................. 2 1.3.2 Objetivos específicos .......................................................................... 3 CAPITULO II: CONTEXTO DE TRABAJO.................................................... 4 2.1 Ingeniería de software ............................................................................. 4 2.2 Ciclo de desarrollo de software .............................................................. 4 2.2.1 Definición ............................................................................................ 5 2.2.2 Análisis................................................................................................ 6 2.2.3 Especificación ..................................................................................... 6 2.2.4 Diseño del sistema............................................................................... 6 2.2.5 Construcción ....................................................................................... 6 2.2.6 Pruebas y depuración .......................................................................... 6 2.2.7 Instalación y operación ....................................................................... 7 2.2.8 Mantenimiento .................................................................................... 7 2.3 Modelo de proceso de software............................................................... 7 2.4 Método WATCH..................................................................................... 8 2.4.1 Procesos de desarrollo. ...................................................................... 10 2.5 Sistemas de información Web............................................................... 11 2.6 Herramientas de apoyo al desarrollo de software (HDS)...................... 13 2.6.1 Mejoras que Provee el Uso de HDS .................................................. 14 2.7 CLEDA (Create / List / Edit / Delete, Architecture) ............................. 15 2.7.1 Framework de soporte (implementación) ......................................... 15 2.7.2 Ventajas del uso del framework según Minotauro (2007): ............... 17 2.8.3 Desventajas del uso del framework según Minotauro (2007): .......... 18 CAPITULO III: DESARROLLO DEL SISTEMA LABX ............................. 19 3.1 Modelado de negocios........................................................................... 19 3.1.1 Objetivos de un laboratorio de computación ................................... 19 3.1.2 Servicios prestados por un laboratorio de computación ................... 20 3.1.3 Estructura Organizativa de un laboratorio de computación .............. 21 3.1.4 Modelado de procesos de un laboratorio de computación ................ 22 3.2 Ingeniería de requisitos ......................................................................... 26 3.2.1 Requisitos Funcionales ..................................................................... 26 3.2.2 Requisitos no funcionales ................................................................. 27 3.2.3 Especificación de los requisitos del sistema .................................... 28 3.3 Diseño arquitectónico............................................................................ 37 3.3.1 Arquitectura de la aplicación ............................................................ 38. ii.

(4) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. 3.3.2 Subsistemas de la aplicación .................................................................... 40 3.3.3 Diseño de la base de datos ............................................................... 43 3.3.4 Diseño de la Interfaz de Usuario ...................................................... 45 3.4 Aprovisionamiento de componentes ..................................................... 47 3.5 Ensamblaje de componentes ................................................................. 55 3.6 Pruebas de la aplicación ........................................................................ 55 CAPITULO IV: EVALUACIÓN DEL FRAMEWORK CLEDA ................... 57 CAPITULO V: CONCLUSIONES Y RECOMENDACIONES .................... 60 5.1 Conclusiones ......................................................................................... 60 5.2 Recomendaciones .................................................................................. 61 REFERENCIAS BIBLIOGRÁFICAS .............................................................. 62. iii.

(5) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Índice de Tablas. Pág.. Tabla 1. Usuarios del sistema ............................................................................... 30 Tabla 2. Caso de uso: Semestre ............................................................................ 35 Tabla 3. Caso de uso: Nuevo Laboratorio ............................................................. 36 Tabla 4. Caso de uso: Historial de acciones. ......................................................... 36 Tabla 5. Caso de uso: Editar Datos ....................................................................... 37 Tabla 6. Caso de uso: Cambiar Contraseña .......................................................... 37. iv.

(6) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Índice de Figuras Pág.. Figura 1. Ciclo de desarrollo de software .............................................................. 5 Figura 2. Modelo de procesos “WATCH” ............................................................. 9 Figura 3. Arquitectura de los sistemas Web.......................................................... 12 Figura 4. Arquitectura a tres capas ........................................................................ 13 Figura 5. Patrón clásico en una aplicación ............................................................ 16 Figura 6. Objetivos de un laboratorio de computación ......................................... 20 Figura 7. Estructura Organizativa de un laboratorio de computación .................. 21 Figura 8. Procesos principales en un laboratorio de computación ........................ 23 Figura 9. Proceso: Administración de usuarios..................................................... 24 Figura 10. Proceso gestión de recursos ................................................................ 24 Figura 11. Proceso: Manejo de disponibilidad...................................................... 25 Figura 12. Diagrama de clases del sistema ........................................................... 29 Figura 13. Caso de uso: Administrador................................................................. 31 Figura 14. Caso de uso: Configuración ................................................................ 32 Figura 15. Caso de uso: Usuarios ......................................................................... 33 Figura 16. Caso de uso: estudiante, preparador, profesor, tesista ......................... 34 Figura 17. Arquitectura del sistema ...................................................................... 38 Figura 18. Subsistemas de la aplicación. .............................................................. 40 Figura 19. Descripción de cada subsistema. ......................................................... 41 Figura 20. Descripción subsistema: Principal. ...................................................... 42 Figura 21. Descripción subsistema: Configuración. ............................................. 42 Figura 22. Descripción del subsistema: Control de Usuarios. .............................. 43 Figura 23. Diseño de la base de datos. .................................................................. 44 Figura 24. Interfaz de usuario: Pantalla de inicio. ................................................ 45 Figura 25. Interfaz de usuario: Menús desplegables. ............................................ 46 Figura 26. Interfaz de usuario: Formulario Estándar. ........................................... 47 Figura 27. Especificación de la interfaz de FrmCLedaList................................... 48 Figura 28. Diagrama de secuencia CLEDA (FrmCledaList). ............................... 49 Figura 29. Especificación de la interfaz de ExpEditCleda. ................................... 50 Figura 30. Especificación DlgSelectBase. ............................................................ 51 Figura 31. Especificación MessageBox. ............................................................... 52 Figura 32. Especificación frmEditBase................................................................. 52 Figura 33. Especificación DlgOkCancel. .............................................................. 53. v.

(7) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. CAPITULO I INTRODUCCIÓN. La gestión administrativa de un laboratorio de computación implica una gran cantidad de procesos y tareas, como por ejemplo: administración de usuarios, controles de acceso, cátedras dictadas,. organización de horarios, inventarios de. hardware y software, mantenimiento de equipos y asesoría a usuarios para el buen uso de los recursos del laboratorio, entre otras labores. Por ende, la ejecución, supervisión y control de dichas tareas y procedimientos resulta muy difícil para un sola persona (por lo general se cuenta con una sola persona para la administración de los laboratorios). Esto puede traer como consecuencia un mal funcionamiento del laboratorio o prestación de servicios deficientes del mismo. Así que surge la necesidad de desarrollar un sistema informático genérico para automatizar las labores asociadas a la gestión de uno o mas laboratorios de computación, siendo este el objeto principal de este trabajo, en el cual se propone el uso un producto de software desarrollado siguiendo el método “WATCH”, que tiene como metáfora un reloj para describir y manipular la complejidad de un proceso de desarrollo de software, e implementado con el framework CLEDA, una herramienta de apoyo para el desarrollo de sistemas de información y aplicaciones Web.. 1.

(8) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. El trabajo esta estructurado en cinco capítulos:  En este capitulo se realiza el planteamiento formal del problema.  Capitulo. contiene el contexto de trabajo donde se detallan los. fundamentos de la metodología y herramientas usadas para el desarrollo e implementación de la aplicación.  Capitulo III: se presenta el desarrollo de cada una de las etapas de el modelo de proceso “Reloj”.  Capitulo IV: esta enfocado a estudia el apoyo real brindado por la herramienta CLEDA.  Capitulo V: en función del producto de software desarrollado y el conocimiento adquirido, se presentan conclusiones y se ofrecen algunas recomendaciones.. 1.1. Definición del problema. Luego de hacer una revisión en la biblioteca de la facultad de ingeniería de la Universidad de los Andes, se verifico que no existe un sistema informático genérico que pueda llevar el control y ejecución de manera eficaz y eficiente, los procesos y tareas asociadas a la gestión administrativa de “uno o más laboratorios de computación”. Este sistema debe contemplar administración de usuarios, gestión de recursos y control de disponibilidad de maquinas.. 1.3. Objetivos. 1.3.1 Objetivo general.  Implantar un sistema informático genérico (configurable) que permita automatizar las labores de gestión administrativa de uno o más laboratorios de computación.. 2.

(9) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. 1.3.2. Objetivos específicos.  Realizar el levantamiento de requisitos que permitan especificar el sistema a detalle.  Documentar los procesos concernientes a la gestión administrativa de un laboratorio de computación utilizando herramientas como UML Business y CLEDA.  Desarrollar el sistema genérico.  Implantar el sistema con la herramienta CLEDA.  Evaluar el apoyo real brindado por la herramienta CLEDA para el desarrollo del sistema.. 3.

(10) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. CAPITULO II CONTEXTO DE TRABAJO. Para el desarrollo del presente trabajo, y el alcance de los objetivos planteados, es necesario abordar las siguientes disciplinas: Ingeniería de software, Desarrollo de software, Modelo de proceso "Reloj" [1], Sistemas de información Web, Herramientas de apoyo al desarrollo de software, CLEDA [2]. Los conceptos más relevantes son presentados e este capitulo.. 2.1. Ingeniería de software. Una disciplina que integra métodos, herramientas y procedimientos para el desarrollo de software de computadora bajo un enfoque de calidad [3].. 2.2. Ciclo de desarrollo de software. El ciclo de desarrollo de software comprende una serie de etapas las cuales son necesarias para producir un producto de software, en la figura que se muestra a continuación se pueden aprecia dichas etapas:. 4.

(11) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Figura 1. Ciclo de desarrollo de software [4] Según Barrios (2006): “una visión generalizada del ciclo de desarrollo de software comprende las siguientes etapas: Definición. Análisis. Especificación. Diseño. Construcción. Pruebas. Operación. Mantenimiento.” 2.2.1 Definición Consiste en el establecimiento de recursos humanos, monetarios, de tiempo y de tecnología requeridos para desarrollar un sistema programado con un objetivo específico.. 5.

(12) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. 2.2.2. Análisis Se centra en definir la situación origen para determinar si realmente un. sistema solventará la situación problemática, así como también establecer en forma precisa cuáles son las actividades que el sistema debe apoyar y cómo las debe apoyar[4]. 2.2.3. Especificación En esta etapa se define, en forma general, el objetivo que debe cumplir el. sistema y cuáles son sus funciones en relación con las actividades que apoyará [4].. 2.2.4 Diseño del sistema Esta etapa consiste en establecer en forma detallada el cómo debe construirse el sistema especificado [4]. Se realizan tres actividades fundamentales: Diseño de la Interfaz. Diseño de los Datos o Base de Datos. Diseño del Sistema Programado.. 2.2.5 Construcción Comprende la codificación y prueba individual de módulos y submódulos, y la implantación de la Base de Datos, para esto se utilizan herramientas de apoyo al desarrollo CASE, Sistemas Manejadores de Base de Datos SMBD, lenguajes de programación 3r. o 4ta. Generación, herramientas de apoyo a la corrida para corregir errores en los programas construidos, etc. [4].. 2.2.6 Pruebas y depuración En esta etapa se realizan pruebas para verificar que el sistema cumple con los requisitos establecidos.. 6.

(13) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Probar un programa es la acción de encontrar errores y fallas de construcción y de definición. Ubicar y corregir esos errores, es la actividad denominada depuración de programas, entre los tipos de pruebas se pueden mencionar: unidades, integración, sistema, aceptación e instalación [4].. 2.2.7 Instalación y operación La instalación de un sistema implica su puesta en funcionamiento en ambiente real. Los usuarios comienzan a utilizarlo cotidianamente como apoyo para las actividades especificadas y dentro del contexto establecido. El sistema puede instalarse y operarse en forma total desde el primer momento o, puede instalarse por partes, las cuales van haciendo operativo el sistema por etapas [4].. 2.2.8 Mantenimiento Siempre existe la posibilidad de encontrar errores dentro de un sistema de información, los cuales deben corregirse inmediatamente; también puede requerirse modificar el modo en que el sistema de información ejecuta ciertas operaciones o la infraestructura sobre la que descansa el sistema de información [4].. 2.3. Modelo de proceso de software. Es un marco metodológico que establece un modo de desarrollar un proyecto o sistema de software, el cual esta basado en un modo especifico de percibir las diversas actividades involucradas en el desarrollo del sistema [4].. Enfoque de ingeniería de sistemas físicos [4]:  Modelo de cascada. 7.

(14) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA.  Modelo V  Modelo “Cleanroom”. Enfoque evolutivo [4]:  Modelo basado en prototipos  Modelo espiral  Modelo incremental  Modelo de versiones. Enfoque formal [4]:  Modelo de transformaciones formales. Enfoque de procesos ágiles [4]:  Modelo de programación extrema XP.. 2.4. Método WATCH. El modelo de procesos del método WATCH es un marco metodológico que describe, en términos generales, un conjunto estructurado de actividades necesarias para producir una aplicación empresarial. Este modelo organiza estas actividades en dos tipos: procesos gerenciales y procesos de desarrollo [1].. Los procesos gerenciales describen las actividades que la gerencia del proyecto(o en su defecto el líder del proyecto) debe realizar para [1]:  Planificar, organizar, dirigir, manejar el grupo de desarrollo y controlar el proyecto de desarrollo de un sistema o aplicación empresarial.  Asegurar la calidad del sistema.  Gestionar la configuración del sistema.. 8.

(15) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA.  Adiestrar el grupo de desarrollo durante el proceso de ejecución del proyecto.. Los procesos de desarrollo son los procesos técnicos que describen que debe hacer el grupo de desarrollo para producir una aplicación empresarial. Estos procesos se organizan en una estructura de jerárquica formada por fases, pasos y actividades [1].. La siguiente figura muestra la estructura del marco metodológico:. Procesos de desarrollo Modelado de Negocios Entrega de la aplicación. Pruebas de la aplicación. Ingeniería de Requisitos. Procesos gerenciales. Diseño Arquitectónico. Diseño de componentes. Ensamblaje de componentes. Aprovisionamiento de componentes. Figura 2. Modelo de procesos “WATCH” [1].. 9.

(16) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. 2.4.1 Procesos de desarrollo.  Modelado de negocios: El objetivo de esta fase es obtener un conocimiento global y detallado del dominio de la aplicación empresarial; esto es, del sistema de negocios para el cual se desarrolla la aplicación. Este conocimiento se logra a través de un proceso de modelado empresarial que determina los objetivos, procesos, actores, objetos, reglas, eventos y unidades organizacionales del sistema de negocios [1].  Ingeniería de requisitos: El objetivo de esta fase es determinar las necesidades de información y automatización de procesos de negocios, que tienen los usuarios de la aplicación empresarial en desarrollo, mediante la definición y especificación de requisitos [1].  Diseño arquitectónico: Consiste en elaborar un diseño de la arquitectura de la aplicación empresarial que sea apropiada a los requisitos especificados y que establezca los subsistemas de la aplicación, los componentes de cada subsistema, las conexiones entre estos componentes y las restricciones que regulan [1].  Diseño de componentes: Su objetivo principal es elaborar los diseños detallados de los componentes que integran cada una de los subsistemas de la aplicación [1].  Aprovisionamiento de componentes: esta fase se centra en la búsqueda y adaptación de componentes de software reutilizables que cumplan con las especificaciones de los componentes, así como también en el desarrollo de aquellos componentes que no puedan ser localizados o que no satisfagan adecuadamente las especificaciones de componentes [1].. 10.

(17) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA.  Ensamblaje de componentes: esta fase consiste en implementar cada una las capas de la aplicación empresarial mediante el ensamblaje de los componentes que fueron adquiridos, adaptados, suscritos o desarrollados en la fase anterior [1].  Pruebas de la aplicación: aquí se comprueba que la aplicación cumple con los requisitos funcionales y no funcionales descritos en la fase de “Ingeniería de requisitos” [1].  Entrega de la aplicación: consiste en instalar la aplicación en su ambiente de producción, ponerla en operación y entregarla a sus usuarios [1].. El desarrollo de de este proyecto se realizara siguiendo el marco metodológico que describe el método WATCH.. 2.5. Sistemas de información Web. En los últimos años, la rápida expansión de Internet y del uso de intranets corporativas ha supuesto una transformación en las necesidades de información de las organizaciones. En particular esto afecta a la necesidad de que [5]:  La información sea accesible desde cualquier lugar dentro de la organización e incluso desde el exterior.  Esta información sea compartida entre todas las partes interesadas, de manera que todas tengan acceso a la información completa (o a aquella parte que les corresponda según su función) en cada momento. Estas necesidades han provocado un movimiento creciente de cambio de las aplicaciones tradicionales de escritorio hacia los sistemas Web, que por su idiosincrasia, cumplen a la perfección con las necesidades mencionadas anteriormente. Por tanto, los sitios Web tradicionales que se limitaban ha mostrar. 11.

(18) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. información se han convertido en aplicaciones capaces de una interacción más o menos sofisticada con el usuario. Inevitablemente, esto ha provocado un aumento progresivo de la complejidad de estos sistemas y, por ende, la necesidad de buscar opciones de diseño nuevas que permitan dar con la arquitectura óptima que facilite la construcción de los mismos [5]. El usuario interacciona con el sistema Web a través del navegador. Como consecuencia de la actividad del usuario, se envían peticiones al servidor, donde se aloja la aplicación y que normalmente hace uso de una base de datos que almacena toda la información relacionada con la misma. El servidor procesa la petición y devuelve la respuesta al navegador que la presenta al usuario. Por tanto, el sistema se distribuye en tres componentes: el navegador, que presenta la interfaz al usuario; la aplicación, que se encarga de realizar las operaciones necesarias según las acciones llevadas a cabo por éste y la base de datos, donde la información relacionada con la aplicación se hace persistente. Esta distribución se conoce como el modelo o arquitectura de tres capas [5].. Figura 3. Arquitectura de los sistemas Web [5].. En la mayoría de los casos, el navegador suele ser un mero presentador de información (modelo de cliente delgado), y no lleva a cabo ningún procesamiento relacionado con la lógica de negocio. No obstante, con la utilización de applets, código javascript y DHTML la mayoría de los sistemas se sitúan en un punto intermedio entre un modelo de cliente delgado y un modelo de cliente grueso (donde el cliente realiza el procesamiento de la información y el servidor sólo es. 12.

(19) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. responsable de la administración de datos). No obstante el procesamiento realizado en el cliente suele estar relacionado con aspectos de la interfaz (como ocultar o mostrar secciones de la página en función de determinados eventos) y nunca con la lógica de negocio [5]. En la mayoría de los sistemas de este tipo y ortogonalmente a cada una de las capas de despliegue comentadas, se puede dividir la aplicación en tres áreas o niveles [5]:  Nivel de presentación: es el encargado de generar la interfaz de usuario en función de las acciones llevadas a cabo por el mismo.  Nivel de negocio: contiene toda la lógica que modela los procesos de negocio y es donde se realiza todo el procesamiento necesario para atender a las peticiones del usuario.  Nivel de administración de datos: encargado de hacer persistente toda la información, suministra y almacena información para el nivel de negocio.. Figura 4. Arquitectura a tres capas [9].. 2.6. Herramientas de apoyo al desarrollo de software (HDS). Actualmente se considera a las HDS como herramientas basadas en computadoras que asisten el proceso de ciclo de vida de software, consolidadas en la literatura en la forma de Ingeniería de software asistida por computadora. 13.

(20) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. (CASE). Esto es, software que se utiliza para ayudar a las actividades del proceso de software o software que es utilizado para diseñar y para implementar otro software [6]. Permiten automatizar acciones bien definidas, reduciendo también la carga cognitiva del ingeniero de software, quien requiere libertad para concentrarse en los aspectos creativos del proceso. Este soporte se traduce en mejoras a la calidad y la productividad en el diseño y desarrollo [6].. 2.6.1 Mejoras que Provee el Uso de HDS El soporte que brindan las HDS al proceso de desarrollo proporciona importantes ventajas para el equipo de trabajo de ingeriría de software. Estas mejoras se sintetizan en [6]: a) Apoyan a las metodologías y métodos, integrando actividades y propiciando visión de continuidad entre fases metodológicas. b) Mejoran la comunicación entre los actores involucrados, facilitándoles compartir su trabajo y desempeñarlo de forma dinámica e iterativa. c) Establecen métodos efectivos para almacenar y utilizar los datos, lo que permite organizar y correlacionar componentes, para accesarlos a través de un repositorio. d) Agregan eficiencia al mantenimiento, ya que los programas son construidos sobre las mismas estructuras y estándares, facilitando la adherencia a la disciplina de diseño y facilitan también la conversión automática de programas a versiones más recientes de lenguajes de programación. e) Automatizan porciones del análisis y diseños tediosos y propensos a error, con influencia sobre la generación de código, las pruebas y el control. Resalta la consideración de que los beneficios potenciales sólo pueden ser alcanzados si las HDS son utilizadas de forma correcta.. 14.

(21) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. El framework CLEDA, el cual será explicado a continuación, puede calificarse como un HDS. 2.7. CLEDA (Create / List / Edit / Delete, Architecture). CLEDA es un framework de software libre, implementado en Java (con una versión en PHP), diseñado para desarrollar sistemas de información y aplicaciones WEB, de alta calidad, a bajos costos y con tiempos de respuesta razonables. Estrategia nacida en un pequeño grupo de desarrollo y orientada en principio hacia la pequeña/mediana empresa [2].. El objetivo principal de CLEDA es encontrar el mejor equilibro posible entre los tres factores anteriores (calidad-tiempo-costo), teniendo en mente a los clientes de la pequeña y mediana industria, quienes son bastante sensibles a estos puntos. Los objetivos específicos son [2]: A corto plazo: ● Mejores tiempos de respuesta (desarrollo de aplicaciones / mantenimiento). ● Orientación hacia la calidad de los productos desarrollados. ● Menores costos de desarrollo. ● Mayor competitividad en el mercado (Nacional / Internacional) [2]. A mediano / largo plazo: ● Estandarizar procesos de desarrollo de software. ● Estandarizar arquitectura de las aplicaciones. ● Alcanzar estándares de calidad formales (ISO, CMM, CEISoft). 2.7.1 Framework de soporte (implementación). La implementación del framework esta centrada en una estrategia basada en patrones de requerimientos y flujos de trabajo, según Minotauro (2007):  El 80% de los requerimientos caen dentro de patrones bien conocidos.. 15.

(22) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA.  Es posible dedicar más atención al 20% de los requerimientos (y reglas de negocio) que no caen dentro de patrones bien conocidos. ud CLEDA. Crear Objeto X. Editar Objeto X. Eliminar Objeto X Actor. Buscar Objeto X. Otras operaciones Objeto X. Editar Filtros de Búsqueda. Figura 5. Patrón clásico en una aplicación [2].. A continuación se presentan algunos de los patrones de requerimientos que cubre el framework en su versión actual [2]:. Estructura general de la aplicación y utilitarios (Clases básicas). Autenticación y administración de usuarios, roles y privilegios. Acceso a los componentes y procesos de la aplicación limitado por los privilegios de los usuarios.. 16.

(23) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Menú dinámico de la aplicación, jerárquico y orientado a privilegios (Configurable por XML). Plantillas y componentes para implementar el patrón CLEDA. Plantillas y componentes para implementar búsquedas filtradas. Plantillas y componentes para implementar asistentes (”wizards”). Plantillas y componentes para parametrizar y generar reportes (generación de reportes en segundo plano). Buzón de reportes y notificaciones. Auditoria básica de las operaciones y transacciones realizadas por los usuarios. Clases utilitarias varias (Validación de formularios, utilidades de calendario, internacionalización).. 2.7.2 Ventajas del uso del framework según Minotauro (2007):  Relación adecuada entre los tiempos de respuesta, la calidad y los costos de desarrollo de una aplicación.  Reducción en los costos de entrenamiento de nuevo personal.  Estandarización y uniformidad en la interfaz de usuario (experiencia uniforme de uso).  Estandarización y simplificación de los procesos de levantamiento de requerimientos.  Relación adecuada entre los actores encargados de las ventas, levantamiento de requerimientos, lideres de proyecto y programadores.  Simplificación de los procesos de documentación de las aplicaciones (Manuales de usuario y de desarrollo).  Calidad y confianza en el código generado.  Mayor escalabilidad y menores costos de mantenimiento a mediano y largo plazo.. 17.

(24) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. 2.8.3. Desventajas del uso del framework según Minotauro (2007):  Pérdida en la flexibilidad del diseño de la interfaz de usuario.  Necesidad de que el proceso de desarrollo esté comprometido desde el principio con la filosofía (Diseñar CLEDA / implementar CLEDA).  El framework está orientada fundamentalmente hacia sistemas de información y aplicaciones WEB.. El framework será usado en este proyecto en la parte de implementación, actividad perteneciente a la fase de aprovisionamiento de componentes del método WATCH descrito en la sección 2.4.. 18.

(25) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. CAPITULO III DESARROLLO DEL SISTEMA LABX. En este capitulo se describe el desarrollo del sistema LabX, siguiendo y desglosando cada una de las etapas del método WATCH: Modelado de negocios, ingeniería de requisitos, diseño arquitectónico, diseño de componentes, aprovisionamiento de componentes, ensamblaje de componentes, pruebas de la aplicación y entrega de la aplicación.. 3.1. Modelado de negocios Como se explico en el capitulo 2, el modelado de negocios se centra en. obtener un conocimiento global y detallado del dominio de la aplicación empresarial; esto es, del sistema de negocios para el cual se desarrolla la aplicación. Este conocimiento se logra a través de un proceso de modelado empresarial que determina los objetivos, procesos, actores, objetos, reglas, eventos y unidades organizacionales del sistema de negocio.. 3.1.1 Objetivos de un laboratorio de computación: los objetivos principales de un laboratorio de computación se describen en el siguiente esquema:. 19.

(26) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Proporcionar el acceso (a estudiantes y profesores) a tecnologías de punta en computación, para que puedan aplicar los conocimientos teóricos adquiridos y desarrollar habilidades con herramientas de última tecnología en el área de sistemas computacionales (bases de datos, sistemas de información, sistemas inteligentes, etc).. Permitir a los estudiantes desarrollar los trabajos prácticos asociados con las materias obligatorias de la opción. Administración de usuarios. Manejo de disponibilidad. Disponer de una infraestructura computacional moderna y de alto nivel que facilite el dictado de cátedras, cursos cortos de actualización, ampliación y perfeccionamiento profesional en las diversas áreas de la computación. Gestión de recursos. Motivar a los usuarios a utilizar herramientas computacionales de alto nivel en la resolución de los problemas planteados en las áreas donde se desempeñan. Dotación, manteniento y acualizacion de equipos y programas. Figura 6. Objetivos de un laboratorio de computación. Tomado de: propuesta de creación de los laboratorios sistemas computacionales I y II.. 3.1.2 Servicios prestados por un laboratorio de computación:. 1.- Garantía de disponibilidad y acceso a los recursos de computación del laboratorio.. 2.- Administración de programas y equipos, se incluye la instalación, prueba, operación, mantenimiento y documentación de los recursos de hardware y software disponibles.. 20.

(27) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. 3.- Asistencia técnica a los usuarios en la utilización de sistemas operativos, lenguajes de programación, sistemas de ventanas e interfaces gráficas, programas especializados, recursos de Internet, sistemas de bases de datos, compiladores, paquetes para el desarrollo de aplicaciones en inteligencia artificial, sistemas operativos y redes, entre otros.. 4.- Adiestramiento a través de dos tipos de cursos: Curso de inducción al laboratorio y curso de adiestramiento en el uso de equipos y programas especializados.. Curso de inducción al uso del Laboratorio: orientado a introducir a los nuevos usuarios en el uso de los programas y equipos que estén a disposición.. Cursos de adiestramiento en el uso de equipos y programas especializados: se ofrecen diversos cursos introductorios y de perfeccionamiento en aquellos sistemas de software que sean de especial interés para los usuarios.. 3.1.3 Estructura Organizativa de un laboratorio de computación: Unidad o Departamento ConsejoTécnico Coordinador del Laboratorio. Sección de administración. Soporte Técnico. Sección de adiestramiento. Mantenimiento. Figura 7. Estructura Organizativa de un laboratorio de computación.. 21.

(28) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Consejo técnico: organismo conformado por un grupo de personas, tiene como responsabilidad establecer las normas y políticas bajo los cuales funciona el laboratorio, así como también se encarga de proponer, discutir y avalar los planes de dotación y actualización tanto de equipos como de los sistemas de software especializados que se requieran. Coordinador: esta a carga de de la conducción y administración del laboratorio asesorado por el consejo técnico. Entre sus principales responsabilidades están la planificación, dirección, supervisión y control de las actividades administrativas, soporte técnico y adiestramiento a usuarios. Sección de administración: esta a carga de un personal técnico, sus funciones se corresponde directamente con el soporte técnico a los usuarios y el mantenimiento de equipos, software y programas de aplicación que se encuentren instalados en los equipos del laboratorio.. 3.1.4 Modelado de procesos de un laboratorio de computación. Para describir los procesos que se ejecutan en un laboratorio de computación se utilizó la herramienta UML Business. UML Business es una extensión del leguaje UML, desarrollada por Hans Ericsson y Magnus Penker (2000), está orientada al modelado de procesos de negocio (incorpora nuevos símbolos para modelar procesos de negocio y emplea estereotipos para agregar mayor semántica a los símbolos utilizados), además usa la cadena de valor de Michael Porter para modelar procesos de negocio al más alto nivel y descompone cada proceso de la cadena de valor en sub-procesos de más bajo nivel [7]. Las actividades realizadas dentro de un laboratorio de computación se pueden categorizar dentro de tres procesos fundamentales:. 22.

(29) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. AU1. Administración de Usuarios. GR2. Gestión de Recursos. GD3. Manejo de Disponibilidad. Figura 8. Procesos principales en un laboratorio de computación.. A continuación se describen los procesos utilizando la herramienta UML Business:. Reglas. Actor. Reglamento de la Institución a la que pertenece el laboratorio Reglamento interno de laboratorio. Coordinador. Objetivo Co. Realizar un registro de las personas que tendrán acceso al laboratorio y a todos los recursos que este ofrece. ntro. Re. Cu. m. ple. la. la. gu. Entrada AU1. Salida Requiere. Produce. Registro de los usuarios en el laboratorio Nuevas cuentas de usuario Lista de secciones de las materias adscritas al laboratorio Cambios de sección. cu. ta. Administracion de Usuarios. Ej e. Estudiantes inscritos en las materias adscritas al laboratorio Tesistas que deseen tener acceso al laboratorio Estudiantes no inscritos en las materias adscritas al laboratorio Profesores de las materias adscritas al laboratorio Otros profesores Lista de reparadores. Actor Técnico. Mapa de los procesos de administración de usuarios AU1. Administración de Usuarios. GR2. Gestión de Recursos. GD3. Manejo de Disponibilidad. 23.

(30) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Figura 9. Proceso: Administración de usuarios. El proceso de administración de usuarios tiene un conjunto de actividades entre las cuales se pueden mencionar:. Creación de cuentas de usuarios. Mantenimiento de cuentas de usuario (actualización de datos, cambios de contraseña, depuración de cuentas). Inscribir estudiantes en las respectivas secciones. Controlar el acceso de personas al laboratorio. Asistencia técnica a usuarios del laboratorio. Verificar el cumplimiento del reglamento de uso del laboratorio. Impartir cursos introductorios para el uso del laboratorio o cursos de especialización en cualquier área.. Reglas. Actor. Reglamento de la Institución a la que pertenece el laboratorio Reglamento interno de laboratorio. Coordinador. Objetivo Co. Realizar un control eficiente de los recursos con que cuenta el laboratorio. ntro. Re. Cu. m. ple. la. la. gu. Entrada GR2. Salida Requiere. Produce. Gestión de recursos. Registro detallado de los recursos que son adquiridos y desechados en el laboratorio Registro de mantenimiento de equipos Registro de actualizaciones de software. Ej e. cu. ta. Adquisiciones de hardware y software Actualizaciones de software Reportes de fallas de hardware y software Listado de recursos que se necesitan Servicios y procesos demandados. Actor Técnico. Mapa de los procesos de gestión de recursos AU1. Administración de Usuarios. GR2. Gestión de Recursos. GD3. Manejo de Disponibilidad. Figura 10. Proceso gestión de recursos.. 24.

(31) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Actividades del proceso gestión de recursos:. Hacer cumplir las políticas de administración, mantenimiento de equipos y programas definidas por el concejo técnico. Velar por el buen funcionamiento de laboratorio. Realizar registros del mobiliario con que cuenta el laboratorio. Mantener actualizados los registros de mobiliario. Hacer solicitudes de aquellos recursos que hagan falta. Realizar mantenimiento correctivo y preventivo de los recursos del laboratorio.. Reglas Reglamento de la Institución a la que pertenece el laboratorio Reglamento interno de laboratorio. Objetivo. Coordinador. Permitir a las personas de la organización a la que pertenece el laboratorio o ajenas a esta, apartar de modo exclusivo un lugar de trabajo o un grupo de maquinas del laboratorio para realizar actividades académicas. gu. trola. Re. Con. Actor. Cu. mp. le. la. MD3. Entrada Requiere. Manejo de disponibilidad. Salida. Produce. Notificación de aceptación o rechazo de la reserva realizada.. Ej e. cu t a. Datos de la persona que reserva Tiempo de la reserva Descripción de la reserva Cantidad de maquinas a reservar. Mapa de los procesos de Manejo de disponibilidad AU1. Actor. Administración de Usuarios. GR2. Gestión de Recursos. MD3. Manejo de Disponibilidad. Técnico. Figura 11. Proceso: Manejo de disponibilidad.. 25.

(32) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Actividades para el proceso manejo de disponibilidad:. Velar por el buen funcionamiento del laboratorio para así poder asegurar a sus usuarios la disponibilidad y acceso a los recursos del mismo. Coordinar el horario de secciones y cursos especiales.. 3.2. Ingeniería de requisitos. Como se menciono en el capitulo anterior el objetivo principal de esta fase es determinar las necesidades de información y automatización de procesos de negocios, que tienen los usuarios de la aplicación en desarrollo, mediante la definición y especificación de requisitos. Un requisito “es una propiedad que debe exhibir [cumplir o satisfacer]” un sistema desarrollado o adaptado para resolver un problema particular” (Sawyer y Kontoya, 2001).. Los requisitos se pueden clasificar en dos tipos: Funcionales No Funcionales. 3.2.1 Requisitos Funcionales. Según Barrios (2006): “los requisitos funcionales describen lo que el producto de software deberá hacer (funciones - servicios).. Para el sistema LabX, se determinaron los siguientes requisitos funcionales:. 26.

(33) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Permitir la administración de cualquier número de laboratorios. Autenticación de usuarios. Administrar usuarios, tanto para el sistema como tal, así como para el laboratorio, esto es permitir de forma automática el manejo de las cuentas de usuarios en el servidor de la red del laboratorio. Acceso a los componentes y procesos de la aplicación limitado por los roles y privilegios de los usuarios Manejar materias y secciones dictadas en el laboratorio, validando colisiones entre horarios, limite de cupos por sección etc. Auditoria básica de las operaciones y transacciones realizadas por los usuarios (dentro de una sesión del sistema). Suspensión de usuarios que no cumplan con las reglas internas del laboratorio. Reservas de maquina para los usuarios registrados. Almacenar y actualizar de manera simple los recursos con los que cuenta el laboratorio (maquinas, mobiliario, material de oficina, servidores entre otros). Búsquedas filtradas de objetos.. 3.2.2 Requisitos no funcionales Los requisito no funcionales son aquellos que imponen restricciones y atributos al producto de software que se esta desarrollando, entiéndase por restricciones como aquellas limitaciones que se le impondrán al desarrollo, uso y mantenimiento del software; y atributos como características de calidad que de debe exhibir y bajo cuales deberá operar el software [8].. Para el sistema LabX, se determinaron los siguientes requisitos no funcionales: El sistema debe ser de tipo Web.. 27.

(34) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. El servidor y los clientes donde se instalará el sistema deben operar con distribuciones Linux.. 3.2.3 Especificación de los requisitos del sistema. Los requisitos del sistema se especifican mediante dos tipos de técnicas:. Estáticas. Dinámicas.. Las técnicas estáticas especifican la estructura y el comportamiento de los objetos de datos que maneja el sistema en términos de tipos abstractos de datos (por ejemplo diagrama de clase en UML) y las técnicas dinámicas especifican la parte funcional del sistema, interacción entre los objetos, usuarios y el sistema (por ejemplo tablas de decisión, descripciones funcionales o casos de uso en UML) [8].. A continuación se muestra el diagrama de clases en UML para el sistema LabX.. 28.

(35) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Figura 12. Diagrama de clases del sistema. 29.

(36) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. La parte dinámica del sistema se especificara median diagramas de casos de uso en UML, estos se concentran en los modos de uso que tendrá el sistema según los diferentes tipos de usuarios y definen los componentes del sistema que intervienen en esta interacción [8]. En la siguiente tabla se muestran los usuarios del sistema:. Tipo de usuario Administrador. Descripción Coordinador. y. el. técnico. del. laboratorio entre otros. Estudiantes. Estudiantes. que. cursan. materias. dictadas en el laboratorio Profesores. Profesores que dictan materias en el laboratorio. Profesores Externos. Profesores que no dictan materias en el laboratorio.. Tesistas. Estudiantes que se encuentran cursando el proyecto final de carrera.. Preparadores. Estudiantes que son preparadores de materias que se dictan el laboratorio.. Tabla 1. Usuarios del sistema. Diagramas de casos de uso para el sistema LabX:. 30.

(37) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. ud Caso de Uso: Admninistrador. CONFIGURACIÓN. «extend». PRINCIPAL «extend» USUARIOS. RECURSOS. «include» SOFTWARE RECURSOS DE LABORATORIO. «include». «include» PC´S. ADMINISTRADOR. CONTROL DE DISPONIBILIDAD. «include». RESERVAS. EDITAR DATOS. MI PERFIL. «include». «include». CAMBIAR CONTRASEÑA. Figura 13. Caso de uso: Administrador. 31.

(38) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. ud Caso de uso: Confugración. Escuelas. «include» DEPARTAMENTOS. «include» GENERAL «include». MATERIAS. «include». SECCIONES. NUEVO LABORATORIO «include» LABORATORIOS. ASDMINISTRADOR «include». LISTA DE LABORATORIOS. CORREO ELECTRÓNICO. Figura 14. Caso de uso: Configuración. 32.

(39) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. ud Caso de uso: Usuarios. ESTUDIANTES. «include». PROFESORES. «include» CONTROL DE USUARIOS. «include». PREPARADORES. «include» TESISTAS «include». «include» USUARIOS ESPECIALES. PROFESORES EXTERNOS HISTORIAL DE ACCIONES ADMINISTRADOR. ADMINISTAR ROLES. Figura 15. Caso de uso: Usuarios. 33.

(40) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. ud Caso de Uso: estudiante, profesor, preparador, profesor externo, tesista. CONTROL DE DISPONIBILIDAD. «include». RESERVAS. «invokes». Estudiante, profesor, preparador, profesor externo, tesista. EDITAR DATOS «invokes» «include» MI PERFIL. «include» CAMBIAR CONTRASEÑA. Figura 16. Caso de uso: estudiante, preparador, profesor, profesor externo, tesista. El caso de uso mostrado anteriormente engloba la funcionalidad para el resto de los usuarios del sistema.. Descripción de los casos uso:. Caso de uso: Semestre. Propósito: Editar los datos del objeto semestre. Actor: Administrador.. Acción de los actores. Respuesta del sistema. 1.- El administrador pide realizar una modificación sobre el objeto semestre. 2.- Pide que modifique los datos (fecha 3.- El usuario introduce los datos.. de inicio, fecha de culminación y. 34.

(41) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. código).. 4.- Valida que los datos son correctos.. 5.- Actualiza la base de datos. Tabla 2. Caso de uso: Semestre Los casos de uso: Escuelas, departamentos, materias secciones, lista de laboratorios, estudiantes, profesores, profesores externos, tesista, usuarios especiales, administrar roles, recursos, software, PC’s y reservas cumplen con lo que Minotauro (2007) define como “Patrón clásico de requerimiento” mostrado en el capitulo II (Ver Figura 4).. Caso de uso: Nuevo Laboratorio. Propósito: Crear un nuevo laboratorio. Actor: Administrador.. Acción de los actores. Respuesta del sistema. 1.- Pide ingresar un nuevo laboratorio.. 3.- El usuario introduce el nombre de la 2.- Pide que ingrese la escuela a la que escuela.. va a pertenecer el laboratorio.. 6.- El usuario introduce el nombre del 4.- Valida que los datos son correctos. laboratorio. 5.- Pide que introduzca el nombre del 9.- El usuario introduce los datos laboratorio. correspondientes. 7.- Valida que los datos son correctos.. 35.

(42) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. 8.-. Pide. que. introduzca. la. configuración de reservas (tiempos y cantidades máximas de reservas para cada tipo de usuario).. 10.- Valida que los datos son correctos.. 11.- Actualiza la base de datos. Tabla 3. Caso de uso: Nuevo Laboratorio. Caso de uso: Historial de acciones. Propósito: Ver el historial de acciones de los usuarios con privilegios de administración. Actor: Administrador.. Acción de los actores. Respuesta del sistema. 1.- El administrador pide ver el historial de acciones de los usuarios. 2.- Muestra el historial de acciones de los usuarios. Tabla 4. Caso de uso: Historial de acciones.. Caso de uso: Editar Datos. Propósito: Editar los datos personales de un usuario. Actor: cualquier tipo de usuario.. Acción de los actores. Respuesta del sistema. 1.- El usuario pide modificar los datos de su perfil.. 36.

(43) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. 2.- Pide que edita los datos(numero de 3.- El usuario introduce los datos teléfono, dirección, e-mail) respectivos. 4.- Valida que los datos son correctos. 5.-Actualiza la base de datos. Tabla 5. Caso de uso: Editar Datos. Caso de uso: Cambiar Contraseña. Propósito: Cambiar la contraseña de un usuario. Actor: cualquier tipo de usuario.. Acción de los actores. Respuesta del sistema. 1.- El usuario pide modificar su contraseña. 2.- Pide que ingrese la contraseña vieja 3.- El usuario introduce las respectivas y la nueva contraseñas 4.- Valida que la contraseña vieja sea la correcta. 5.-Actualiza la base de datos. Tabla 6. Caso de uso: Cambiar Contraseña. 3.3. Diseño arquitectónico Como se menciono en el capitulo II el objetivo de esta fase es elaborar un. diseño detallado de la arquitectura de la aplicación, que sea apropiada a los requisitos especificados, que establezca los subsistemas de la aplicación y los componentes de cada subsistema.. 37.

(44) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Se puede definir arquitectura de software como una colección de componentes computacionales o simplemente componentes, en un conjunto con una descripción de las interacciones entre esos componentes (Garlan y Shaw, 1993). El sistema LabX sigue un patrón de arquitectura a tres capas, como el descrito en el capitulo II, sección: sistemas de información Web.. 3.3.1. Arquitectura de la aplicación La arquitectura de la aplicación se encuentra estructurada en capas: la capa. de presentación donde se encuentran los componentes encargados de generar la interfaz de usuario; capa de lógica de negocios: contiene los componentes que controlan los procesos de negocio así como también el procesamiento necesario para atender las peticiones del usuario y por ultimo la capa de datos que tiene los componentes necesarios para el almacenamiento de la información.. Capa de presentación. ECHO2 ECHO2. Capa de lógica de negocios. CLEDAECHO CLEDAECHO. CLEDACOMMONS CLEDACOMMONS. CLEDAI18N CLEDAI18N. Capa de datos. HIBERNATE HIBERNATE. JDBC JDBC NAVEGADOR NAVEGADOR WEB WEB. LabX.Logica LabX.Logica. LabX.Modelo LabX.Modelo LabX.Util LabX.Util. Figura 17. Arquitectura del sistema. 38.

(45) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Echo2 es un framework para el desarrollo de aplicaciones Web orientado a objetos y basado en eventos. Echo2 abstrae la naturaleza de petición-respuesta HTTP y le permite centrarse en las interacciones de la aplicación utilizando los paradigmas de orientación a objetos y control de eventos habituales en la mayoría de las tecnologías de cliente rico. Gracias a esto, Echo no necesita conocer HTML, HTTP, JavaScript. Las aplicaciones pueden ser instaladas en cualquier contenedor de servlets Java. Echo es software de código abierto distribuido bajo los términos de la licencia LGPL [10].. Los paquetes CledaEcho, CledaCommons y CledaI18N son paquetes provistos por CLEDA y contienen todas las clases y componentes que conforman el framework, a continuación se muestran los componentes y clases principales del paquete CledaEcho el cual provee los componentes que conforma la herramienta:  FrmCledaList.  ExpCledaEdit.  DlgLogin.  DlgSelectBase.  FrmEditBase.  PnlWizardBase.  FrmWizardBase.  DlgOkCancel.  SelecTableModel.  MessageBox.  DlgchangePassword.. El paquete LabX.Logica contiene los componentes encargados del el manejo de los procesos: Control de usuarios, gestión de recursos y manejo de disponibilidad descritos en la sección 3.1 de este capitulo.. 39.

(46) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. El paquete LabX.Util contiene clases y pequeñas funciones utilitarias para apoyar a los componentes del paquete LabX.logica.. Hibernate es una capa de persistencia objeto/relacional (código abierto) y un generador de sentencia SQL. Permite diseñar objetos persistentes que podrán incluir polimorfismo, relaciones, colecciones, y un gran numero de tipos de datos. De manera muy rápida y optimizada se pueden generar Bases de datos en cualquiera de los entornos soportados: Oracle, DB2, Mysql, entre otros [11].. JDBC es el acrónimo de Java Database Connectivity, posee un API que permite la ejecución de operaciones sobre base de datos desde el lenguaje de programación Java independientemente del sistema operativo donde se ejecute o de la base de datos a la cual se accede utilizando SQL del modelo de base de datos que se utilice [12].. Un servlet es un objeto que se ejecuta en un servidor o contenedor JEE, fue especialmente diseñado para ofrecer contenido dinámico desde un servidor Web [13].. El paquete LabX.Modelo contiene las clases que representan el modelo de datos del sistema.. 3.3.2 Subsistemas de la aplicación:. Figura 18. Subsistemas de la aplicación.. 40.

(47) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Como se observa en la figura 18, la aplicación contiene cuatro subsistemas donde se engloba toda la funcionalidad del sistema, a continuación se describirá a detalle cada uno de lo s subsistemas y los componentes necesarios para que éstos logren realizar su objetivo a cabalidad:. Figura 19. Descripción de cada subsistema. El subsistema Disponibilidad es el encargado del manejo de las reservas de maquinas del laboratorio, cuenta con un componente llamado “Reservas”, este componente debe permitir: crear, editar y eliminar instancias del objeto reserva además de validar los datos que estas contienen, Mi Perfil tiene como función la actualización de datos de un usuario, esta formado por dos componentes sencillos: “Cambiar contraseña”, como su nombre lo indica se encarga de el cambio de la contraseña de un usuario, el componente debe permitir la verificación de usuario por medio de la contraseña vieja y luego debe solicitar la nueva contraseña con su respectiva confirmación; “Editar Datos”, su objetivo es el de actualizar los datos personales de un usuario, el componente debe validar que los datos introducidos son correctos. Recursos, su función es manejar de manera simple los recursos del laboratorio, para esto cuenta con tres componentes: “Recursos”, “PC’s” y “Software”, estos componentes deber permitir la creación, búsqueda, edición y eliminación de las instancias de objetos: Recurso, PC y software. Por ultimo se tiene el subsistema Principal, el cual se encarga de la gestión de los objetos principales del laboratorio, cuenta con dos subsistemas: Configuración y Usuarios los cuales se detallan a continuación;. 41.

(48) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Figura 20. Descripción subsistema: Principal. Configuración administra todos aquellos objetos inherentes al laboratorio: Semestre, Escuelas, Departamentos, Materias y Secciones, así como la creación y configuración de nuevas instancias del objeto laboratorio en la aplicación para esto cuenta con dos subsistemas: General y Laboratorios, un componente (“CorreoElectrónico”):. Figura 21. Descripción subsistema: Configuración. General esta formado por cinco componentes para manejar los objetos: Escuela, Departamento, Materia y Sección, dichos componente deben permitir crear, buscar, editar y eliminar instancias de los objetos ya mencionados así como validar que los datos de los mismos sean correctos. Laboratorios por su parte se encarga de la creación y configuración de los objetos de tipo laboratorio, esto lo hace por medio de dos componentes:”Nuevo Laboratorio” y “Laboratorios”, el primer componente debe ser un ayudante (“Wizard”) en otras palabras debe contener una serie de pantallas con los pasos necesarios para crear el objetos y debe permitir la navegación entre dichas pantallas; el segundo componente (“Laboratorios”) debe permitir listar, buscar, editar y eliminar objetos de tipo de. 42.

(49) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. laboratorio y por ultimo el componente “Correo Electrónico” debe permitir configurar los datos del servidor de correo por el cual serán enviados los emails de información a los usuarios del sistemas.. Usuarios controla toda la funcionalidad referente a los usuarios del sistema, lo hace a través de los componentes “Administrar Roles”, “Historial de Acciones” y el subsistema Control de Usuarios:. Figura 22. Descripción del subsistema: Control de Usuarios. Control de Usuarios contiene componentes para la creación, búsqueda y eliminación de los distintitos tipos de usuario del sistemas; “Historial de Acciones” es un componente de visualización el cual muestra las acciones realizadas por los usuarios durante una sesión del sistema y “Administrar Roles” se encarga de la creación y actualización de los roles que pueden tener los usuarios dentro de la aplicación.. Todos los componentes que conforman los subsistemas de la aplicación se encuentran ubicados en la capa de lógica de negocios de la arquitectura del sistema. 3.3.3 Diseño de la base de datos En la figura que se muestra a continuación se describe el diseño de la base de datos para el sistema LabX:. 43.

(50) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Figura 23. Diseño de la base de datos.. 44.

(51) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. 3.3.4 Diseño de la Interfaz de Usuario La interfaz de usuario es creada a través del framework Echo2, la interfaces de usuarios de Echo están compuestas por componentes reutilizables que permiten controlar la estructura de la pagina y sus interacciones. La aproximación a orientación a componentes es muy similar a la que se encuentra en otras tecnologías de interfaz utilizadas en otros entornos orientados a objetos, como el Swing de Java o el Visual Basic de Microsoft. Esto puede entenderse mejor observando las siguientes figuras:. Pantalla de inicio:. Figura 24. Interfaz de usuario: Pantalla de inicio. La pantalla de inicio contiene un pequeño formulario formado por campos de texto en los cuales el usuario debe introducir su login (nombre de usuario) y contraseña, para ingresar al sistema.. 45.

(52) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Menús:. Barra de Menús. Menú s Despl egabl es. Figura 25. Interfaz de usuario: Menús desplegables. La pantalla principal de la aplicación, contiene una barra con menús desplegables donde presentan los subsistemas de la aplicación descritos en el diseño arquitectónico.. Formulario Estándar:. La figura 26 muestra la pantalla de un formulario estándar de CLEDA, este permite: crear, editar, buscar y eliminar objetos, contiene dos botones en la parte superior: uno para crear nuevos objetos y el otro para eliminar conjuntos de objetos, los objetos almacenados se listan como secciones expandibles, las cuales se muestran con una barra el cual contiene una sección de titulo para identificar el objeto, además de los botones para editar y eliminar el objeto en cuestión, en modo expandido cuenta con un panel para mostrar los atributos del objeto.. 46.

(53) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Botón de cerrar ventana Botones de eliminar (Seleccionados) y crear nuevo elemento. Sección expandible. Botones eliminar y editar objeto. Botón de marcar objeto. Sección de paginamiento. Botones de filtros y actualizar Ventana. Figura 26. Interfaz de usuario: Formulario Estándar. Es importante resaltar que no se realizo un diseño de las pantallas como tal, debido. a que los componentes del framework CLEDA proporcionan la. interfaz de usuario.. 3.4. Aprovisionamiento de componentes. Los componentes base para el desarrollo. de la aplicación fueron obtenidos. directamente de la empresa Minotauro C.A ya que pertenecen a la segunda versión de CLEDA la cual aun no ha sido publicada oficialmente porque se encuentre en la parte final de su desarrollo, a continuación se hará la especificación y descripción de los componentes provistos por la herramienta para sustituir a los descritos en la sección 3.3.2:. 47.

(54) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. cd Especificacion FrmListCleda FrmCledaList + + # # # # # # # #. FrmCledaList() : void init(boolean, String) : void initTopComponent() : void btnAddClicked(ActionEvent) : void initEFilter() : void initBasePageableTableModel() : void initMBase() : MBase initQueryCreator() : void btnDeleteClicked(CledaEditEvent) : void btnDleteAllClicked() : void. Figura 27. Especificación de la interfaz de FrmCLedaList. Excepciones: Definidas por el usuario en la implementación. Precondiciones Operaciones: Ninguna. Post-condiciones Operaciones: Ninguna Restricciones del componente: El componente solo puede listar elementos de tipo ExpEditCleda (Sección Expandible mostrada en el diseño de interfaz de usuario, el componente es provisto por CLEDA) Comportamiento: componente para listar, crear, eliminar y realizar búsquedas filtradas de objetos, también contiene por omisión los formularios para editar las búsquedas y cuenta con una sección de paginamiento para los casos en que el número de elementos es mayor al que se puede mostrar en el formulario. Invariantes: Cuando uno. de los elementos que lista el componente. (ExpEditCleda) se encuentra en modo Edición, se bloquea toda la funcionalidad del componente hasta que el elemento que esta siendo editado regrese al estado Solo Lectura.. A continuación se muestra un diagrama de secuencia UML donde se puede apreciar el flujo de control de eventos en la implementación de un patrón clásico de requerimientos (CLEDA FrmCledaList) como el descrito en el capitulo II (Ver figura 4):. 48.

(55) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. sd Interaccion CLEDA Crear. Buscar. Editar. Eliminar. Actor. Crea Obj. Valida datos de Obj Obj creado exitosamente. Busca Obj Editar Obj. Valida datos de Obj. Obj editado exitosamente. Eliminar Obj. Confirmación Obj Eliminado exitosamente. Eliminar uno o mas Obj Verificación si hay Obj Seleccionados Obj(s) eliminado(s) exitosamente. Figura 28. Diagrama de secuencia CLEDA (FrmCledaList).. 49.

(56) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. cd ExpEditCleda ExpEditCleda + + + + + + # # # # # # # # # # # # # # # # # #. ExpEditCleda() : void init(GMBase, int, Status) : void getStatus() : Status setStatus(Status) : void getIndex() : int getData() : GMBase btnDelClicked() : void btnCanClicked() : void btnEdtClicked() : void btnSavClicked() : void preUpdate(Session) : void posUpdate(Session) : void posUpdate() : void preCreate(Session) : void posCreate(Session) : void posCreate() : void enableGUI(boolean) : void validateGUI() : List<String> setTitleBarColor() : void setColor(Color) : void initGUI() : void updateGUIFromData(Session) : void updateDataFromGUI(Session) : void updateTitleFromData() : String. Figura 29. Especificación de la interfaz de ExpEditCleda. Excepciones: Definidas por el usuario en la implementación. Precondiciones Operaciones: Ninguna. Post-condiciones Operaciones: Ninguna Restricciones del componente: El componente solo almacena objetos que hereden de la clase MBase, provista por la librería. Comportamiento: componente para mostrar y editar los datos de un objeto, para poder acceder a los atributos del objeto que contiene se debe hacer click con el ratón el la barra de titulo del mismo, también cuenta con botones de editar y eliminar, al activar el botón de editar el componente permite al usuario acceder a los atributos del objeto, esto se debe a que el estado inicial del componente es solo de lectura, estando en modo edición, se muestran los botones de salvar y cancelar, cuando se selecciona la operación salvar el componente activa un mecanismo de validación, el cual evaluará las condiciones establecidas por el usuario en la implementación y según el resultado actualizará o no el objeto en cuestión.. 50.

(57) Sistema genérico para la gestión de un laboratorio de computación implementado con la herramienta CLEDA. Invariantes: el componente tiene dos estados, solo lectura es el estado por omisión, se pueden ver los atributos pero no editarlos y el modo edición con el cual si se pueden editar los atributos del objeto.. cd DlgSelectBase DlgSelectBase + + # # #. DlgSelectBase() : void init(int, boolean, boolean, Set<GMBase>, String) : void initBasePageableTableModel() : SelectTableModel<GMBase> initQueryCreator() : void initEFilter() : void. Figura 30. Especificación DlgSelectBase. Excepciones: Definidas por el usuario en la implementación. Precondiciones Operaciones: Ninguna. Post-condiciones Operaciones: Ninguna Restricciones del componente: La base del componente es un objeto de tipo Tabla que provee la librería llamado: SelecTableModel, esta tabla solo puede contener objetos de tipo MBase. Comportamiento: componente para listar objetos seleccionables, la selección puede ser simple (solo se puede seleccionar un objeto) o múltiple (se puede seleccionar varios elementos), el componente cuenta con dos botones, guardar y cancelar para salvar o no las acciones realizadas, el componente también contiene un combo con el cual se pueden ver elementos según estén seleccionados o no y también posee el mecanismo de búsqueda filtrada por los atributos del objeto que almacena. Invariantes: ninguna.. 51.