Aplicación web para trabajo colaborativo : Aplicación web para corrección automática de pruebas
Texto completo
(2) 2. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(3) Agradecimientos y dedicatoria Dedico este trabajo a la memoria de mi padre, mi familia, hermanos y primos, y amigos que han estado a mi lado estos meses de elaboración de este trabajo. Agradezco la colaboración de mis tutores y profesores, a los que les debo la formación y conocimientos adquiridos en el área de la Ingeniería de Sistemas.. 2.
(4) i. Prefacio El presente Trabajo de Final de Carrera (TFC) pertenece al área de Aplicaciones Web para el Trabajo Colaborativo y consiste en desarrollar una Aplicación Web para la Corrección Automática de Pruebas. La tecnología utilizada para la implementación es Java Enterprise Edition (JEE), que permite adaptar un desarrollo tipo Modelo Vista Controlador (MVC) empleando las diferentes especificaciones del estándar Enterpries Java Beans (EJB), Context Dependence Injection (CDI) y Java Server Faces (JSF). En la introducción inicial describimos el proyecto y su organización, así como el plan de trabajo. Los capítulos posteriores describen con modelos UML (Unified Modeling Language) las especificaciones de los requisitos, su análisis y diseño, para lo que se emplean diferentes diagramas de clases, casos de uso, secuencia, etc. El capítulo de implementación detalla los sistemas, servidor web JEE Wildfly (JBopss) y MariaDB o MySQL de base de datos, la estructura de paquetes de código de los diferentes niveles o capas del estándar y el desarrollo de sus componentes.. Francisco J. Godoy Suárez. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo.
(5) ii. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(6) Índice general. Prefacio. i. Índice. i. 1. Introducción. 1. 1.1. Descripción del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.2. Organización del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3. 1.2.1. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3. 1.2.2. Relación de actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. 1.3. Estimación y Viabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8. 1.3.1. Estimaciones iniciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8. 1.3.2. Viabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8. 1.4. Plan de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9. 1.4.1. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9. 2. Especificación de requisitos 2.1. Contexto. 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12. 2.1.1. Modelo del dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.2. Glosario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.3. Modelo del negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2. Guiones o Escenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3. Requisitos funcionales. Modelo de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.1. Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.2. Requisitos funcionales (RF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.3. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3.4. Documentación textual de los casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . 22 iii.
(7) ÍNDICE GENERAL. iv. 2.3.5. Requisitos de la interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.4. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.4.1. Distribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.4.2. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.4.3. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4.4. Usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3. Análisis. 27. 3.1. Paquetes de análisis y de servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2. Revisión de los casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3. Especificación de las clases del análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.1. Clases de entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.2. Atributos de las clases de entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3.3. Relaciones entre clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3.4. Clases frontera, control y entidad. Diagrama de Robustez . . . . . . . . . . . . . . . . . . 36 3.4. Especificación formal de los casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.5. Análisis de la interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.6. Diagrama estático del análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4. Diseño. 41. 4.1. Diseño arquitectónico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.1.1. Nodos y configuración de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.1.2. Subsistemas e interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2. Realización de los casos de uso-diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2.1. Subsistema Administración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2.2. Subsistema Gestión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51. 4.2.3. Subsistema Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2.4. Subsistema Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.3. Diagrama estático de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.3.1. Normalización de los nombres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.3.2. Reutilización de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.3.3. Adaptación de la herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3.4. Sustitución de las interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3.5. Mejoras del rendimiento agrupando clases . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(8) ÍNDICE GENERAL. v. 4.3.6. Especificación de las operaciones implícitas . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.3.7. Referencias a las clases frontera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.3.8. Clase Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.3.9. Cohesión y acoplamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59. 4.3.10. Diagrama estático del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.4. Diseño de la persistencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.4.1. Diseño de la base de datos. Esquema E/R . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.4.2. Supresión de la herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.4.3. Modelo Relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.5. Diseño de la interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.5.1. Elaboración de una guía de estilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.5.2. Diseño IGU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.5.3. Evaluación del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.6. Diseño de los subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5. Implementación. 67. 5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.2. Implementar la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.3. Integrar el sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.4. Implementar los subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.5. Implementar las clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.5.1. Código de las clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.6. Implementar la base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Bibliografía. 73. Anexo I. 75. 5.7. Documentación textual de los casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.8. Especificación formal de los casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.8.1. CU-Subsistema Administración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.8.2. CU-Subsistema Gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.8.3. CU-Subsistema Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.8.4. CU-Subsistema Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.8.5. CU-Subsistema Comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Francisco J. Godoy Suárez. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo.
(9) ÍNDICE GENERAL. vi. Anexo II. 93. 5.9. Realización Casos de Uso - Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.9.1. Subsistema Administración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.9.2. Subsistema Gestión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99. 5.9.3. Subsistema Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.9.4. Subsistema Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.10. Guión SQL para crear la BD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 5.11. Plantilla de la hoja de estilo en cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(10) Índice de figuras 1.1. Matriz CSCW o Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.2. Modelos del Proceso Unificado de desarrollo de software . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.3. Etapas. Ciclo de vida clásico o en cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3. 1.4. Flujos de trabajo en las diferentes fases de un ciclo . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. 1.5. Calendario de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9. 1.6. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9. 2.1. Interfaz gráfica de Moodle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Elaboración de preguntas con JQuiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3. Modelo del dominio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14. 2.4. Modelo Entidad - Relación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15. 2.5. Modelo de datos relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.6. Diagrama de casos de uso del modelo de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.7. Diagrama de objetos del modelo de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.8. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.9. Interfaz de usuario (IU): Inicia Sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.10. Interfaz de usuario (IU): Edita Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.11. Interfaz de usuario (IU): Edita/Crea Grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1. Modelo del análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2. Arquitectura Modelo, Vista, Control.. Modelo del análisis basado en el modelo de casos de uso 27. 3.3. Atributos esenciales y subtipos (estereotipos) de una clase del análisis . . . . . . . . . . . . . . . 28 3.4. Modelo de tres dimensiones con los correspondientes estereotipos de objeto . . . . . . . . . . . . 28 3.5. Paquetes de análisis y de servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.6. Semántica de la Asociación n-aria en UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32. 3.7. Diagrama de Clases del modelo del dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 vii.
(11) ÍNDICE DE FIGURAS. viii. 3.8. Herencia. Relación de generalización. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.9. Asociaciones del rol del docente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.10. Asociaciones del rol del administrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.11. Asociaciones del rol del estudiante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.12. Asociaciones de agregación y composición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.13. Diagrama de Robustez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.14. IU - Alta/Edición Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.15. Diagrama Estático del Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.1. Jerarquía de subsitemas. Modelo diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2. Requisitos del modelado de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3. Req. del modelo de aplicaciones web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.4. Metamodelos de los modelos de diseño UWE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.5. Arquitectura de una aplicación web JEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.6. Proceso de generación UWE4JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.7. Nodos y Protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.8. Nodos, conexiones de red y protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.9. Subsistemas de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.10. Subsistemas de servicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46. 4.11. Arquitectura del modelo de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.12. Interfaces del modelo de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.13. Dependencias entre subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.14. Matriz de dependencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.15. Caso de uso - diseño: atributos clave y asociaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.16. Colaboraciones que realizan Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.17. Casos de uso del paquete. Traza al subsistema Administración . . . . . . . . . . . . . . . . . . . . 50 4.18. Casos de uso del paquete. Traza al subsistema Gestión . . . . . . . . . . . . . . . . . . . . . . . . 51 4.19. Casos de uso del paquete. Traza al subsistema Pruebas . . . . . . . . . . . . . . . . . . . . . . . . 52 4.20. Casos de uso del paquete. Traza al subsistema Seguridad . . . . . . . . . . . . . . . . . . . . . . . 53 4.21. Clase de diseño: atributos y asociaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.22. Modelo estático del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.23. Nomenclatura de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.24. Diagrama Clases Entidad del Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.25. Usuario - Herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(12) ÍNDICE DE FIGURAS. ix. 4.26. Herencia de las clases Pregunta y Respuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.27. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.28. Modelado de la clase PruebaEvaluacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.29. Página inicial de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.30. Diagrama web del inicio de sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.31. Diagrama Estático del Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.32. Modelo E/R de Chen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.33. Relación de generalización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.34. Representación de la generalización- especialización . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.35. Modelo relacional de la herencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62. 4.36. Diagramas DDL genérico y Modelo Relacional MySQL de la BD . . . . . . . . . . . . . . . . . . 63 4.37. IU de Inicio de Sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.38. Controles estándar de IU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64. 4.39. Elementos básicos de IGU para edición datos. Formularios. . . . . . . . . . . . . . . . . . . . . . 65 4.40. Subsistemas, componentes y niveles JEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.41. Relaciones entre Componentes de Implementación y Clases de del Diseño . . . . . . . . . . . . . 66 5.1. Arquitectura Componentes MVC.. Contenedores Servidor JEE. . . . . . . . . . . . . . . . . . 67. 5.2. Relación entre componentes de implementación y artefactos que manifiesta cuales los realizan . . 69 5.3. Servicios de contenedor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.4. Diagrama colaboración CU-08 Alta Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.5. Diagrama secuencia CU-08 Alta Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.6. Diagrama actividad CU-19 Crea Prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.7. Diagrama de colaboración CU-19 Crea Prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.8. Diagrama de actividad CU-33 Realiza Prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.9. Diagrama de colaboración CU-33 Realiza Prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.10. Diagrama de actividad CU-37 Iniciar Sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.11. Diagrama de colaboración CU-37 Iniciar Sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.12. Diagrama de colaboración CU-41 Enviar mensaje . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.13. Estructura de la colaboración Administra Grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.14. Relaciones con clases del diseño y subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.15. Diagrama de secuencia para Administra Grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.16. Estructura de la colaboración Administra Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . 97. 5.17. Relaciones con clases del diseño y subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Francisco J. Godoy Suárez. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo.
(13) ÍNDICE DE FIGURAS. x. 5.18. Diagrama de secuencia para Administra Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.19. Estructura de la colaboración Gestiona Asignatura . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.20. Relaciones con clases del diseño y subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.21. Diagrama de secuencia para Gestiona Asignatura . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.22. Estructura de la colaboración Gestiona Prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.23. Relaciones con clases del diseño y subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.24. Diagrama de secuencia para Gestiona Prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.25. Estructura de la colaboración Gestiona Pregunta . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.26. Relaciones con clases del diseño y subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.27. Diagrama de secuencia para Gestiona Pregunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.28. Estructura de la colaboración Publica Prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.29. Relaciones con clases del diseño y subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.30. Diagrama de secuencia para Publica Prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.31. Estructura de la colaboración Realiza Prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.32. Relaciones con clases del diseño y subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.33. Diagrama secuencia para Realiza Prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.34. Diagrama de clases: Relaciones CU-34. Diagrama del caso de uso CU-34 . . . . . . . . . . . . . . 109 5.35. Estructura de la colaboración Consulta Prueba Profesor . . . . . . . . . . . . . . . . . . . . . . . 109 5.36. Estructura de la colaboración Consulta Prueba Alumno . . . . . . . . . . . . . . . . . . . . . . . 110 5.37. Relaciones con clases del diseño y subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.38. Diagrama de secuencia para Consulta Prueba Profesor . . . . . . . . . . . . . . . . . . . . . . . . 111 5.39. Diagrama de secuencia para Consulta Prueba Alumno . . . . . . . . . . . . . . . . . . . . . . . . 112 5.40. Estructura de la colaboración Iniciar Sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.41. Relaciones con clases del diseño y subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.42. Diagrama de secuencia para Iniciar Sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(14) Capítulo 1 Introducción Actualmente los entornos de aprendizaje basados en la cooperación y colaboración de equipos de trabajo, presentan nuevas alternativas de apoyo al proceso de enseñanza y aprendizaje [1], tanto en las instituciones educativas como en organizaciones empresariales. Los entornos de trabajo colaborativo, basados en tecnologías de CSCW (Computer Supported Cooperative Work) [2], están permitiendo la capacitación y el trabajo colaborativo en diferentes ámbitos de la sociedad. Una de las maneras más comunes de conceptualizar los sistemas CSCW es considerar el contexto del uso del sistema.Una de tales conceptualizaciones es la matriz de CSCW, que aparece por primera vez en 1988 por Johansen y también en Baecker (1995) [3]. La matriz considera contextos de trabajo en dos dimensiones. En primer lugar, si la localización o distribución geográfica de la colaboración es común, y en segundo lugar si las personas colaboran de forma síncrona o asíncrona en el tiempo.. Figura 1.1: Matriz CSCW o Groupware La colaboración tiene una contribución bastante influyente en el aprendizaje. El estudio llevado a cabo por Springer, Stanne y Donovan [4] mostró que el aprendizaje conjunto de pequeños grupos incrementa el rendimiento de estudiantes en áreas como son las Ciencias, Matemáticas, Ingeniería y Tecnología. Durante los últimos años se han desarrollado numerosas aplicaciones web para corrección automática de ejercicios en diversas disciplinas (Ver ejemplos como [5], [6], [7]). 1.1.. Descripción del proyecto. El dominio u objetivo de este proyecto es dar soporte informático a la realización y evaluación automática de problemas o pruebas relacionadas con un área temática o asignatura, y que han sido elaboradas por los profesores asociados a las mismas. Consideramos límites del dominio, es decir, no es nuestro objetivo, implementar funcionalidades de orga1.
(15) 2. CAPÍTULO 1. INTRODUCCIÓN. nización de asignaturas, cursos y/o materiales asociados a las mismas, que en el ámbito de la docencia son habituales. Así como tampoco abordar, en su totalidad, las posibles tareas, dando a entender con ello, que la complejidad de las preguntas y respuestas que las componen puede ser de amplitud a considerar. El dominio comprenderá aquellas tareas, que, compuestas de preguntas y respuestas simples, tras su elaboración por parte de los profesores, se publicarán en Internet para su realización por los alumnos y corrección automática por el sistema. Estas preguntas serán del tipo verdadero o falso o a elegir entre varias opciones, con la posible inclusión de texto adicional, tanto para respuestas como de razonamientos.. 1.1.1.. Objetivos. El propósito principal del presente proyecto es diseñar una aplicación web para trabajo en grupo siguiendo las pautas básicas de la Ingeniería del Software a la hora de acometer el ciclo de vida del desarrollo de programas informáticos. Así como también adoptar las fases comunes en la definición y planificación de un proyecto de este tipo. Este objetivo general se realizará en varios etapas o fases adoptando un ciclo de vida iterativo e incremental basado en el modelo del Proceso Unificado de Rational Unified Process. Un modelo es una representación, en cierto medio, de algo en el mismo u otro medio. El modelo capta los aspectos importantes de lo que estamos modelando, desde cierto punto de vista, y simplifica u omite el resto. Se expresa en un medio adecuado, en el caso de un sistema software está construido en un lenguaje de modelado, en nuestro caso será UML. El modelo tiene semántica y notación y puede adoptar varios formatos que incluyen texto y gráficos. El modelo pretende ser más fácil de usar para ciertos propósitos que el sistema final. El Proceso Unificado de desarrollo de software proporciona un conjunto de modelos elegido para satisfacer las necesidades de información del proyecto con el cual comenzar. Este conjunto de modelos hace claro el sistema para todos los usuarios, en general, incluye a clientes o usuarios y diseñadores [8].. Figura 1.2: Modelos del Proceso Unificado de desarrollo de software El objetivo funcional de este proyecto es implementar una aplicación web dinámica JEE para un entorno de trabajo colaborativo que facilite al consultor o profesor crear pruebas de auto-corrección para, posteriormente, publicarlas a través de la red a disposición del alumnado para su realización y posterior análisis. Concretamente, pretendemos: • Analizar aplicaciones o entornos web para trabajo colaborativo similares desde el punto de vista de su funcionalidad, amigabilidad, diseño, etc, a la hora de calificar de manera automática pruebas de evaluación. • Definir y Planificar un proyecto de aplicación web dinámica que, basada en las experiencias anteriores y las nuevas necesidades de estos entornos, permita afrontar dicha tarea. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(16) 3. 1.2. ORGANIZACIÓN DEL PROYECTO. • Crear la documentación respectiva al Plan de Trabajo, objetivos, estimaciones y viabilidad del trabajo. • Analizar las diferentes tecnologías Web y JEE de las que se compondrá la herramienta a crear. • Realizar el diseño e implementación de una aplicación web dinámica JEE que permita evaluar pruebas de manera automática vía web utilizando los componentes elegidos de los estudios anteriores. • La publicación de la documentación pertinente de la misma: planificación, diseño UML, guías de usuario de la aplicación JEE, documentación Java, etc. • La implantación de la aplicación y la documentación como servicio en un servidor Web. • Obtener información de los conocimientos sobre el área temática escogida, el Álgebra Lineal, de los alumnos mediante el estudio de la información recopilada en los formularios cumplimentados, que se almacenará en la base de datos del servidor web.. 1.2.. Organización del proyecto. En el Trabajo Final de Carrera destacamos los siguientes roles asociados a los diferentes participantes: • Usuarios de la aplicación del entorno de trabajo colaborativo • Director del Proyecto • Equipo de desarrollo de la herramienta a diseñar • Gestor del Proyecto responsable de la planificación y costes • Otros posibles roles ligados a terceros (p.e. la universidad o la administración pública) La definición y ejecución de los elementos comunes del proyecto de manera adecuada, que podemos llamar metodología, es clave para garantizar el éxito del mismo, así como la de los diferentes rasgos específicos relativos a tecnología, diseño conceptual y físico, implantación, etc [9]. Los métodos y técnicas de la Ingeniería del Software suscriben el marco delimitado por las diferentes etapas que se distinguen en el ciclo de vida del software. El ciclo de vida del software está constituido por un conjunto de fases de desarrollo así como por otras etapas previas y posteriores a éstas [10].. 1.2.1.. Metodología. En el presente proyecto se adoptarán las diferentes fases previstas en el modelo del ciclo de vida en cascada o clásico del software que muestra la figura. Ciclo iterativo que se caracteriza por la obtención en cada etapa de objetivos y documentos que serán la información de Figura 1.3: Etapas. Ciclo de vida clásico o en cascada partida para la etapa siguiente. La documentación elaborada se facilitará en cuatro entregas a la finalización de las diferentes etapas como se especifica a continuación: 1. Análisis Previo: Formulación propuesta y Planificación. 2. Análisis: Especificación de Requisitos y Análisis. Francisco J. Godoy Suárez. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo.
(17) 4. CAPÍTULO 1. INTRODUCCIÓN. 3. Diseño: Modelo estático y dinámico. 4. Desarrollo y Despliegue, Pruebas y Mantenimiento: Se agruparán en una única entrega final por ser la etapa con más tiempo asignado. Incluirá la memoria del proyecto, la codificación y guía de usuario, más una presentación virtual. Este método presenta algunos inconvenientes, no es realista, sobre todo en lo que respecta al análisis de requisitos de forma completa. Podría ser válido si las etapas que van del análisis de requisitos a la prueba no abordan todo el conjunto del software, sino sólo una parte cada vez. Es decir, analizaremos las funcionalidades con cierta autonomía de entre todos los requisitos iniciales, las diseñaremos, desarrollaremos y probaremos. Entonces tenemos un ciclo de vida iterativo e incremental basado en el ciclo de vida en cascada, similar al basado en el modelo del Proceso Unificado de Rational Unified Process. El modelo del ciclo de vida del software del Proceso Unificado es iterativo e incremental y se repite en ciclos que lo constituyen. Cada ciclo consta de cuatro fases, inicio, elaboración, construcción y transición, subdividas a su vez en iteraciones que concluyen con una Figura 1.4: Flujos de trabajo en las versión del producto [8]. Los flujos de trabajo de cada iteración se diferentes fases de un ciclo corresponden con el ciclo de vida en cascada como muestra la figura.. 1.2.2.. Relación de actividades. Las actividades se agruparán en cuatro grandes fases asociadas a los hitos de control que se corresponden con la entrega de documentación descrita en el apartado anterior. Estas fases se dividirán a su vez en subfases con sus correspondientes actividades o tareas. 1. Fase de formalización de la propuesta y planificación Tarea que se acomete en profundidad resultando en la elaboración del Plan de Trabajo. Se corresponde con la fase inicial del proyecto y entrega de este documento. a) Concepto de proyecto Recopilación y análisis preliminar de información y documentación referente a proyectos de aplicaciones web para entornos de trabajo colaborativo. b) Requisitos de la propuesta Recopilación y análisis preliminar de información y documentación de aplicaciones de corrección automática de pruebas. c) Descripción Definición y análisis del dominio. 1) Objetivos Análisis de propósitos a alcanzar. d ) Organización Fases, participantes y elementos del proyecto. 1) Metodología Analizar y optar por el ciclo de vida del proceso en el marco de la Ingeniería del Software y desarrollo de proyectos. 2) Fases y relación de tareas Este apartado. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(18) 5. 1.2. ORGANIZACIÓN DEL PROYECTO. e) Estimaciones y viabilidad Estudiar como realizar las estimaciones. Análisis de viabilidad. 1) Estimación inicial Elección del método de cálculo para las estimaciones. 2) Viabilidad Técnica, operativa y económica. f ) Plan de Trabajo Asignación de tiempo y recursos a las actividades y sus correspondientes informes. 1) Diagrama de Gantt 2) Hitos de control 3) Informe de Costes 2. Fase de especificación de requisitos y análisis Recopilar información detallada de los requisitos funcionales y de la interfaz de usuario de la aplicación y realizar su especificación dirigida por casos de uso. Revisión de casos de uso y obtención del modelo de análisis. a) Información inicial Recogida de requisitos. Entrevista con un profesor. b) Modelo del dominio Tipos de clases más importantes. c) Modelo del negocio Diagramas de casos de uso, actividad e interacción. d ) Glosario del modelo del negocio e) Los guiones Operaciones frecuentes de los actores. f ) Casos de uso. Requisitos funcionales Identificación de los casos de uso. 1) Actores Roles en los casos de uso. 2) Diagrama de casos de uso 3) Documentación textual g) Requisitos de la interfaz de usuario Relativos a la interfaz gráfica de usuario que permitirá la realización de los diferentes casos de uso. 1) Diseño lógico de IU Requisitos de la interfaz (RI) 2) Diseño Físico de IU Prototipo IU de varios casos de uso. h) Requisitos NO funcionales Restricciones impuestas por la tecnología 1) 2) 3) 4). Distribución Rendimiento Seguridad Usabilidad. Francisco J. Godoy Suárez. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo.
(19) 6. CAPÍTULO 1. INTRODUCCIÓN. i ) Análisis y revisión de los casos de uso Traducir los requisitos a lenguaje formal empleando el método del Proceso Unificado y el lenguaje unificado de modelado (Unified Modeling Language, UML). 1) Paquetes de análisis y de servicios Documentación dividida en paquetes UML. 2) Revisión de los casos de uso. 3) Identificación de las clases de análisis Frontera, Entidad y Control. Asociaciones y relaciones. 4) Especificación formal de los casos de uso Estructura estática del software. 5) Análisis de la interfaz de usuario Esquema de ventanas asociadas a clases frontera. 6) Diagrama estático del dominio 3. Fase de Diseño Aplicar las notaciones y conceptos de UML siguiendo el ciclo de vida del Rational Unified Process para obtener el modelo de diseño. a) Diseño arquitectónico Establecer la configuración de la red, establecer los subsistemas, sus interfaces e interdependencias. 1) Configurar la red Nodos, interconexiones, protocolos, respecto al ancho de banda, fiabilidad y calidad. 2) Establecer los subsistemas Propios o reutilizados de sistema o de capa intermedia (middleware). b) Diseño de los casos de uso Diseño de la implementación de los casos de uso partiendo del diagrama de colaboración de la etapa de análisis. c) Revisión del diagrama estático de diseño Reexaminar e incluir el resto de clases al diagrama estático de diseño de la etapa de análisis. 1) 2) 3) 4) 5) 6) 7) 8) 9). Normalización de los nombres Reutilización de clases Adaptación de la herencia Sustitución de las interfaces Mejoras del rendimiento agrupando clases Especificación de las operaciones implícitas Referencias a las clases de frontera Clase Inicial Cohesión y acoplamiento. d ) Diseño de la persistencia Transformación del diseño lógico al modelo relacional. 1) Diseño de la base de datos. Esquema E/R 2) Gestores de disco e) Diseño de la interfaz de usuario Representación de los datos, implementación de los diálogos y diseño de ventanas. 1) Elaboración de una guía de estilo 2) Diseño IGU UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(20) 7. 1.2. ORGANIZACIÓN DEL PROYECTO. 3) Evaluación del diseño f ) Diseño de los subsistemas Especificar los subsistemas de la actividad 3.1.2: clases y sus interdependencias a nivel de clase y operación. Comprobar la implementación de la interfaz entre los subsistemas y clases. 4. Fase de Implementación y Despliegue Elección del entorno de desarrollo y transcripción del modelo lógico de la fase de diseño a componentes, fuentes Java (JEE), scripts SQL, etc. Generar el modelo de implementación. a) Implementar la arquitectura Identificación de componentes significativos y de su despliegue en los diferentes contenedores del servidor JEE. b) Integrar el sistema Plan de integración de construcciones. c) Implementar los subsistemas Mantenimiento de los contenidos de los subsistemas. d ) Implementar las clases Elaborar los componentes fichero. 1) Generar código a partir de las clases 2) Implementar las operaciones 3) Implementar interfaces de los componentes e) Implementar la base de datos Generar los scripts SQL de la base de datos a partir del modelo de diseño. f ) Realizar pruebas de unidad De especificación (pruebas de caja negra) y estructura (pruebas de caja blanca). 5. Fase de Prueba Verificar el resultado de la implementación probando cada construcción. a) Diseñar y Planificar pruebas Elaborar casos de prueba de integración, sistema y regresión. Identificar y estructurar los procedimientos de prueba. b) Implementar las pruebas Crear componentes de prueba de los procedimientos de prueba automáticos. c) Realizar las pruebas Realizar, evaluar y resumir las pruebas de integración. 6. Memoria y Presentación Recopilación de la información del proyecto generada en las fases anteriores en diferentes formatos. a) Documento en formato texto Memoria del proyecto en formato pdf. b) Documento con formato de presentación Diapositivas de presentación del proyecto en formato pdf. c) Documento de video-presentación virtual Video y presentación virtual del proyecto. Francisco J. Godoy Suárez. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo.
(21) 8. CAPÍTULO 1. INTRODUCCIÓN. 1.3.. Estimación y Viabilidad. El objetivo o dominio del presente proyecto dista mucho de ser un sistema de e-learning completo por varias razones, entre ellas el plazo de tiempo para su ejecución y la amplitud y complejidad de una solución total. Esperamos abarcar los requisitos funcionales mínimos necesarios que se requieran. El calendario laboral constará de 36 horas semanales, de las cuales 20 serán de Lunes a Viernes y 16 entre Sábado y Domingo. En cuanto a recursos técnicos y operativos se procurará optar por la solución más económica o gratuita de los mismos cuya plataforma permita el estudio, di sea entornos de trabajo colaborativo.. 1.3.1.. Estimaciones iniciales. La estimación del tiempo a emplear en la realización de las tareas se basa en el siguiente cálculo. Se tiene en cuenta la estimación optimista, pesimista y más probable de la duración del proyecto. Asignándoles una probabilidad del 15 %, 20 % y 65 % respectivamente. E = EO ∗ P O + EM P ∗ P M P + EP ∗ P P A la hora de la estimación del coste del proyecto asignaremos a los recursos (personales o materiales) un coste por hora. Para personas responderá a un coste habitual por horas similar al que se paga por estos servicios. Para los materiales calcularemos el coste por hora según su precio de compra, período de amortización y porcentaje de beneficio.. 1.3.2.. Viabilidad. 1. Técnica La infraestructura que el presente proyecto requiere es de coste asequible. El desarrollo puede implementarse en cualquier ordenador de sobremesa o portátil medianamente moderno donde montar un servidor web local. Las necesidades de software y librerías serán cubiertas por software desarrollado y distribuido libremente (open source). 2. Operativa El trabajo será gestionado y revisado periódicamente por el director del proyecto, que realizará un seguimiento del equipo de desarrollo del mismo. La aplicación se estima sea amigable para los participantes o actores que dispondrán de la misma para la creación, publicación, realización y auto corrección de pruebas. Se entregará una guía de usuario de la herramienta con la memoria y se dispondrá también de la misma en el servicio web. 3. Económica Para los recursos humanos estableceremos un coste por hora de 10 euros, cantidad con la que estimaremos el coste/beneficio del proyecto que aparece en el informe de costes. Los recursos técnicos, un ordenador mínimo, establecemos el coste por hora en 0,6 euros. El despliegue de la aplicación en un servidor de hospedaje depende del proveedor del servicio. Se presentan varias soluciones en el informe de costes posterior.. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(22) 9. 1.4. PLAN DE TRABAJO. 1.4.. Plan de Trabajo. El calendario de trabajo mencionado se observa en la siguiente figura.. Figura 1.5: Calendario de trabajo. 1.4.1.. Diagrama de Gantt. Describe la planificación de las fases del proyecto y las actividades respectivas.. Figura 1.6: Diagrama de Gantt. Francisco J. Godoy Suárez. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo.
(23) 10. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. CAPÍTULO 1. INTRODUCCIÓN. Francisco J. Godoy Suárez.
(24) Capítulo 2 Especificación de requisitos El propósito fundamental del flujo de trabajo de los requisitos del Proceso Unificado es guiar el desarrollo hacia el sistema correcto mediante una descripción de los requisitos del mismo de acuerdo con usuarios y desarrolladores de lo que el sistema debe hacer[32]. Este flujo de trabajo incluye los siguientes pasos que pueden realizarse de manera coetánea: • Enumerar los requisitos candidatos: consiste en identificar todos los posibles requisitos que son susceptibles de ser implementados por el sistema. Estos requisitos forman la lista de características utilizada para la planificación del trabajo, algunas de las cuales se convierten en requisitos y se transforman en artefactos como casos de uso. • Comprender el contexto del sistema: hay dos aproximaciones para expresarlo de forma utilizable por desarrolladores de software: modelado del dominio y modelado del negocio. Un modelo del dominio describe los conceptos importantes del contexto como objetos del dominio, enlazando unos con otros. La identificación y asignación de un nombre para estos objetos se utilizará para desarrollar un Glosario de términos. El modelo del negocio describe los procesos (existentes u observados) con el objetivo de comprenderlos. • Capturar los requisitos funcionales: identifica los requisitos funcionales utilizando los casos de uso. Además de los casos de uso, los analistas deben especificar la apariencia de la interfaz de usuario. • Capturar los requisitos no funcionales: identifica propiedades del sistema como restricciones del entorno y de implementación, rendimiento, dependencias de la plataforma, facilidad de mantenimiento, extensibilidad, fiabilidad y otras. El modelado de requerimientos para una aplicación web (webapp) dinámica depende de factores como el tamaño y complejidad del incremento de la misma, el número y modo de interacción de los usuarios, el entorno y la infraestructura en la que se aloja u hospeda, etc[12]. Estas características se representan con un conjunto de modelos, de ellos los principales son: • Modelo de contenido: identifica el espectro completo de contenido que proporciona la webapp. • Modelo de interacción: se compone de uno o más diagramas UML de casos de uso, secuencia, estado y prototipos de la interfaz de usuario. • Modelo funcional : se realiza una descripción detallada de todas las funciones y operaciones. • Modelo de navegación: Debe atenderse a los requerimientos generales de navegación. • Modelo de configuración: describe el entorno e infraestructura donde reside la webapp, empleando el diagrama de despliegue UML.. 11.
(25) 12. CAPÍTULO 2. ESPECIFICACIÓN DE REQUISITOS. 2.1.. Contexto. El trabajo a desarrollar se limita al de una aplicación web dinámica que permita a profesores y alumnos elaborar, realizar y consultar pruebas de auto corrección en un entorno de trabajo colaborativo de enseñanza y aprendizaje (e-learning) empleando las tecnologías de la información y comunicación (TIC) en el marco del aprendizaje colaborativo apoyado con ordenadores (CSCL, Computer Supported Collaborative Learning). Las herramientas de gestión de pruebas mediante tecnología web se pueden clasificar en tres categorías[13][14]: • Entornos virtuales de formación: que ayudan al profesor a gestionar módulos o cursos de enseñanza (distribución de contenidos, intercambios con los alumnos a través de correo electrónico, foros de discusión o chats y evaluación de los alumnos). Ejemplos: WebCT, Learning Space, Edustance, Moodle, etc. • Herramientas de autor: consisten en software destinado a su vez a la creación de programas a modo de ejercicios o tareas. Ejemplos de este tipo son: Hot Potatoes, Quia!, JClic, etc. • Software específico de servidor más complejo: tanto para la creación y publicación de los exámenes, como para recoger los resultados de los estudiantes. Ejemplos de este software son: Perception y Quiz Factory. El gestor de contenidos más conocido en entornos virtuales de formación es Moodle (Modular Object-Oriented Dynamic Learning Environment), un Sistema de Gestión de Cursos de Código Abierto (Open Source Course Management System, CMS), conocido también como Sistema de Gestión del Aprendizaje (Learning Management System, LMS) o como Entorno de Aprendizaje Virtual (Virtual Learning Environment, VLE)[15]. Moodle es un paquete de software para la creación de cursos y sitios Web basados en Internet. Se distribuye gratuitamente como Software libre (Open Source) (bajo la Licencia Pública GNU). Es multiplataforma y está diseñado con PHP y una base de datos MySQL. Hot Potatoes es de las herramientas de autor más extendidas. Ha sido desarrollada por el Centro de Humanidades de la Universidad de Victoria (UVIC), en Canadá, incluye seis aplicaciones, que permiten crear cuestionarios interactivos de opción múltiple y respuesta corta (JQuiz), de frase desordenada (JMix), crucigrama (JCross), emparejar (JMatch), rellenar huecos (JCloze) y unidades enlazadas a partir de varios ejercicios (The Masher). Es un programa gratuito, no es de código abierto y la versión Java es multiplataforma al ejecutarse sobre la máquina virtual[16]. Los fundamentos en los que se basa el proceso de enseñanza-aprendizaje delimitan la definición del concepto de evaluación al procedimiento mediante el cual los profesores, empleando pruebas, medidas y criterios, interpretan los resultados alcanzados por el alumno o sistema de enseñanza en general o sobre alguna faceta particular del mismo. Las funciones de la evaluación del aprendizaje (orientar, formar y sumar) van asociadas al instante en el que se realiza el proceso de evaluación (inicial, continuo o final)[17].. Figura 2.1: Interfaz gráfica de Moodle. Figura 2.2: Elaboración de preguntas con JQuiz. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(26) 13. 2.1. CONTEXTO. Entre los instrumentos o técnicas de evaluación nos encontramos con: • Técnicas objetivas donde realizamos una valoración cuantitativa: cuestionarios de elección múltiple, de doble alternativa, asociar parejas, completar los espacios en blanco en una frase o párrafo, identificar objetos mediante rompecabezas o puzzles, etc. Similares a las utilizadas por el Centro de Humanidades de la Universidad de Victoria (Canada) en la aplicación mencionada, Hot Potatoes. • Técnicas subjetivas donde realizamos una valoración cualitativa: exposición oral y redacción, resolución de problemas y casos prácticos. • Técnicas mixtas Las técnicas objetivas tienen un alcance fijo y conocido por lo que su implementación es más sencilla. En las técnicas subjetivas su alcance es más abierto y hay que delimitar el problema para permitir la auto-corrección, por ejemplo para la resolución de problemas se podría aplicar un algoritmo para resolver cada uno de los problemas, pero el algoritmo deberíamos definirlo nosotros[18]. El propósito de este proyecto es implementar una aplicación web dinámica empleando tecnología Java Enterprise Edition que facilite al consultor o profesor crear pruebas de auto-corrección para, posteriormente, publicarlas a través de la red a disposición del alumnado para su realización y posterior análisis. El escenario de trabajo descrito, la documentación consultada de aplicaciones similares y la entrevista realizada a un profesor abarcan inicialmente, desde el punto de vista funcional, las características siguientes: − Ofrecer escenarios para los diferentes roles de usuario: alumno, docente, administrador, etc. − Registrar a los usuarios tras solicitarlo. − Gestionar (crear, borrar, modificar, etc) usuarios y grupos de ellos por parte de los docentes administradores. − Editar y modificar los perfiles de los usuarios registrados tras iniciar la sesión. − Enviar mensajes entre usuarios y del sistema a usuarios. − Planificar (elaborar, eliminar, publicar, actualizar, asociar, consultar y obtener estadísticas, etc) las pruebas de evaluación por los profesores. − Realizar y consultar pruebas de auto-corrección por los alumnos. − Gestionar (crear, eliminar, modificar, etc) los diferentes tipos de preguntas y sus respuestas por parte de los docentes. − Administrar (añadir, borrar, cambiar, etc) asignaturas o áreas temáticas a las que se asociarán las pruebas de auto-corrección y los grupos de usuarios. − Cursar o asociar asignaturas por parte de los alumnos. Los siguientes apartados, el modelo del dominio, el modelo del negocio y el glosario de términos, modelan el contexto de la aplicación descrito.. Francisco J. Godoy Suárez. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo.
(27) 14. 2.1.1.. CAPÍTULO 2. ESPECIFICACIÓN DE REQUISITOS. Modelo del dominio. El objeto de este apartado es comprender y describir de manera inicial y simplificada las clases u objetos más importantes dentro del contexto del sistema anteriormente descrito y sus principales características o atributos. Las clases restantes o candidatas a formar parte del modelo se incluyen de forma sintetizada en la posterior sección del Glosario, que junto con el modelo del dominio detallan el contexto de la aplicación. El modelo del dominio se describe mediante diagramas UML, especialmente por medio de diagramas de clases[32]. El diagrama de la figura 1.3 muestra de manera orientativa las clases principales del dominio, así como algunos de los atributos o propiedades de las mismas. La figura posterior muestra las clases más relevantes dentro del contexto del sistema. El usuario (generalización) forma (se agrega a) grupos que se asocian a asignaturas que cursan. Según el rol, el profesor, (generalización de administrador) imparte asignaturas y elabora pruebas que se les incluyen y que están compuestas de preguntas que tienen respuestas. Los docentes administradores gestionan los grupos y administran usuarios. Y los usuarios con el rol de alumno cursan asignaturas y realizan pruebas respondiendo las preguntas que contienen.. Figura 2.3: Modelo del dominio. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(28) 15. 2.1. CONTEXTO. La siguiente figura emplea el modelo entidad - relación (E/R) propuesto por Chen (1976/77) como modelo conceptual de datos, proporcionando una vista unificada de los mismos consistente en entidades e interrelaciones. También se modelan posibles características o atributos de las relaciones de multiplicidad muchos a muchos.. Figura 2.4: Modelo Entidad - Relación El modelo de datos relacional que sigue transforma estas asociaciones de multiplicidad muchos a muchos del modelo UML en las entidades pertinentes. Ha sido elaborado con MySQL del script DDL obtenido de la transformación mencionada. Obsérvese que el tipo de datos boolean (bool) es sinónimo de tinyint[20].. Figura 2.5: Modelo de datos relacional. Francisco J. Godoy Suárez. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo.
(29) 16. CAPÍTULO 2. ESPECIFICACIÓN DE REQUISITOS. 2.1.2.. Glosario. Definición de términos1 comunes que se utilizan para describir las clases importantes y candidatas del sistema de entre las que seleccionaremos las clases entidad del modelo del análisis. Las clases del dominio y este glosario de términos se utilizan en el desarrollo de los modelos de casos de uso y del análisis.. Administrador: Alumno: Asignatura: Curso: Grupo: Matrícula: Pregunta: Profesor: Prueba: Respuesta: Tema: Usuario:. Usuario de la aplicación con permisos y niveles de acceso máximos. Normalmente un profesor o docente. Usuario de la aplicación con permisos para cursar asignaturas, realizar pruebas y editar su perfil. Compendio de temas y pruebas asociadas, de ciertas características, que reciben un nombre. Tratado sobre una materia explicada o destinada a serlo durante cierto tiempo. Conjunto de alumnos que asisten al mismo grado de estudios. Conjunto de usuarios de privilegios específicos. Conjunto de gente que se ha matriculado. Acción y efecto de matricular o matricularse. Cuestión, planteada de diversa manera, relativa a un determinado tema. Usuario del sistema con permisos de acceso para gestionar asignaturas, temas, preguntas y respuestas. Grupo de un determinado número de preguntas y respuestas. Enunciado asociado a una pregunta que puede ser o no correcta. Unidades de contenido en que se divide un programa de estudios. Persona, con diferentes roles, que interacciona con las funcionalidades del sistema.. La clase candidata Tema caracteriza parte del todo que es la clase Asignatura, es decir, se agrega a ésta como la Prueba. Por esta razón consideramos que no es objeto de modelarse inicialmente, así como por estimar suficiente que una Prueba es de unas características o temática según a que Asignatura se asocia. Por otro lado, la clase candidata Curso, se considera modelada con la asociación de las clases Grupo y Asignatura. En la definición anterior se menciona al grupo de alumnos y a la materia (temática, asignatura) en el tiempo. Finalmente, la clase candidata Matrícula es modelada con la asociación entre las clases Alumno y Asignatura. Considerando que la matrícula es el acto de cursar una asignatura por un alumno durante un período de tiempo.. 1 En alguna definición se ha citado textualmente parte de la descripción que ofrece la Real Academia Española en el diccionario de su página web [21].. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(30) 17. 2.1. CONTEXTO. 2.1.3.. Modelo del negocio. Esta sección describe el sistema desde la perspectiva de su uso, y esquematiza cómo proporciona valor a sus usuarios. A grandes rasgos, detalla los procesos y entidades del contexto del software o sistema en términos de casos de uso y actores que se corresponden con los procesos y los usuarios, respectivamente [32] [22]. El modelo del negocio es soportado por dos tipos de modelos UML, los modelos de casos de uso y los modelos de objetos [23]. Se utilizan diagramas de casos de uso y de objetos, así como diagramas de interacción y actividad para explicar los casos de uso. La figura ilustra inicialmente casos de uso generales del modelo del negocio que describen la funcionalidad más general del sistema. Estos objetivos funcionales que facilita el sistema se especificarán con más detalle en la próxima sección de requisitos funcionales con el modelo de casos de uso. El modelo describe mediante casos de uso y a groso modo las actividades que realizan los actores que son usuarios registrados tras iniciar la sesión en el sistema según el rol que ejercen, profesor, administrador o alumno. Otros actores como el usuario, la generalización de los mencionados, u otros sistemas de gestión como el de base de datos, mensajería o estadísticas se consideraran en la sección posterior mencionada y en el modelo del análisis con la revisión de los casos de uso.. Figura 2.6: Diagrama de casos de uso del modelo de negocio. Por medio de colaboraciones en el diagrama de la figura modelamos los objetos y los enlaces implicados en la implementación de una interacción . Es un diagrama de clases que contiene roles de clasificador y de asociación ligados respectivamente a los objetos y enlaces que pueden ocurrir cuando se instancia la colaboración[24]. Mediante dichos diagramas identificamos los objetos asociados a entidades del modelo del dominio que utilizan los actores o trabajadores para realizar los casos de uso del modelo del negocio expuestos anteriormente[32][22]. Figura 2.7: Diagrama de objetos del modelo de negocio. Francisco J. Godoy Suárez. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo.
(31) 18. CAPÍTULO 2. ESPECIFICACIÓN DE REQUISITOS. 2.2.. Guiones o Escenarios. El escenario o guión de un caso de uso detalla la serie de operaciones más frecuentes que los usuarios llevan a cabo en las sesiones con el software. Los guiones expresan la interacción correspondiente entre el usuario y el software: conviene indicar las excepciones, casos particulares y precondiciones[22]. Se denomina escenario a cada secuencia específica de acciones que ilustra un comportamiento. Normalmente, se usa un diagrama de secuencia para especificar el flujo principal de un caso de uso, y variaciones de ese diagrama para reflejar las excepciones[25]. Describiremos de manera textual en tres guiones básicos, asociados a cada uno de los roles de usuario o actores, las acciones que determinarán los casos de uso y sus flujos principales y excepcionales, que se analizarán en profundidad en el modelo de casos de uso y su posterior revisión en la parte del análisis. • Administrador: Tras iniciar la sesión, gestiona usuarios y grupos. Crea, borra, modifica y lista profesores, alumnos y grupos. Introducirá los datos característicos de los usuarios y grupos mediante formularios web y agregará a los usuarios a uno o más grupos. Habitualmente este rol es desempeñado por un profesor incluido en el grupo de administradores.. • Profesor: Ingresa al sistema para elaborar las preguntas y respuestas que componen las pruebas de forman parte de las asignaturas. Gestiona la edición, creación y eliminación de asignaturas, pruebas, preguntas y por tanto sus respuestas. Además puede pertenecer al grupo de los administradores. Obtiene de las asignaturas que imparte los listados de puntuación de las pruebas que realizan los alumnos, pudiendo consultar la prueba de un determinado alumno.. • Alumno: Las sesiones tendrán como objetivo realizar pruebas de auto-corrección de las asignaturas que cursan, que serán registradas para permitir la posterior consulta de la puntuación. También puede modificar las características de su perfil de usuario. No puede pertenecer al grupo de administradores. Mantiene mensajería para comunicarse con los profesores que imparten las asignaturas que cursan.. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(32) 2.3. REQUISITOS FUNCIONALES. MODELO DE CASOS DE USO. 2.3.. 19. Requisitos funcionales. Modelo de Casos de Uso. El Proceso Unificado de desarrollo de software esta dirigido por los casos de uso, centrado en la arquitectura y es iterativo e incremental. Los Casos de Uso proporcionan un medio sistemático e intuitivo de capturar requisitos funcionales centrándose en el valor añadido para el usuario. Dirigen todo el proceso de desarrollo debido a que la mayoría de las actividades como el análisis, diseño y prueba se llevan a cabo partiendo de los casos de uso. El diseño y la prueba pueden también planificarse y coordinarse en términos de casos de uso [32]. Normalmente, un sistema tiene muchos tipos de usuarios. Cada tipo de usuario se representa por un actor. Los actores utilizan el sistema interaccionando con los casos de uso. Un caso de uso es una secuencia de acciones que el sistema lleva a cabo para ofrecer algún resultado de valor para un actor. El modelo de casos de uso esta compuesto por todos los actores y todos los casos de uso de un sistema.. 2.3.1.. Actores. Los usuarios que acceden al sistema no tendrán los mismos intereses y privilegios, perseguirán fines distintos, jugarán un papel diferente. Para ello el entorno debe permitir asignar un rol distinto a cada uno de ellos. Desde nuestro punto de vista y en el marco del e-Learning, tres son los roles básicos de los usuarios del sistema: • Administrador: Se encarga de gestionar usuarios y grupos, así como los recursos del sistema siguiendo el guión anteriormente citado. Normalmente este rol lo desempeña un docente. • Profesor: Administra y elabora los recursos para la formación de los alumnos: asignaturas, temas, pruebas, preguntas y respuestas, siguiendo el correspondiente guión anterior. Mantiene comunicación con los grupos de alumnos asociados a las asignaturas que imparte para mediante el sistema de mensajería. • Alumno: Realiza las pruebas asociadas a las asignaturas que cursa y obtiene su calificación. Como indica el respectivo guión, gestiona su perfil y pruebas. Se relaciona con otros alumnos y los profesores correspondientes mediante mensajería. Los subsistemas de la plataforma deben proporcionar las funciones requeridas para ejercer los diferentes roles de usuario, funcionalidades que se modelan mediante casos de uso.. 2.3.2.. Requisitos funcionales (RF). Las funcionalidades están asociadas a los diferentes roles del dominio mencionados:. 2.3.2.1.. Administrador. El administrador, típicamente un docente, es el actor encargado de gestionar todos los aspectos del sistema. Desglosando los casos de uso del subsistema de Administración del modelo del negocio,tenemos: (RF 01). Administrar Grupos:. Crear, eliminar y modificar grupos. Relacionar las asignaturas y los grupos que las cursan. Obtener listados y estadísticas del grupo.. (RF 02). Administrar Usuario:. Agregar, borrar y editar la información de los usuarios. Asociarles las asignaturas que imparten. Listar los profesores e información relacionada.. (RF 03). Asocia Usuario:. Caso de uso para relacionar las asignaturas el usuario docente que la imparte o alumno que la cursa.. Francisco J. Godoy Suárez. Asignatura. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo.
(33) 20. CAPÍTULO 2. ESPECIFICACIÓN DE REQUISITOS. 2.3.2.2.. Profesor. Los docentes son los actores encargados de gestionar las áreas temáticas y sus pruebas, así como los alumnos y los grupos de éstos. Sus funciones incluyen: (RF 04). Gestionar Asignaturas:. Crear, eliminar y modificar asignaturas. Asociar los grupos a las asignaturas. Obtener listados y estadísticas de la asignatura.. (RF 05). Gestionar Pruebas:. Crear, eliminar y actualizar las pruebas de auto-corrección. Asociar temas a la pruebas. Agregar preguntas y respuestas a la prueba. Obtener informes de resultados y estadísticas de las pruebas.. (RF 06). Publicar Pruebas:. Activar la prueba y comunicarlo a los alumnos enviando un mensaje al sistema de mensajería.. (RF 07). Gestionar Preguntas:. Elaborar, borrar y modificar preguntas. Asignar respuesta/s, ciertas o no, a las preguntas. Obtener listados y estadísticas de las preguntas.. (RF 08). Gestionar Respuestas:. Crear, eliminar y modificar las respuestas. Obtener listados de las respuestas de los alumnos.. 2.3.2.3.. Alumno. Es la persona matriculada en la asignatura que realiza las pruebas propuestas para las asignatura. Durante la realización de las mismas deben contar con la posibilidad de consultar los resultados obtenidos de manera automática. (RF 9). Realizar Pruebas:. Cumplimenta y obtiene la calificación de las pruebas relacionadas con las asignaturas que cursa.. (RF 10). Consultar Pruebas:. Lista y comprueba la puntuación obtenida de las diferentes pruebas realizadas que forman parte de las asignaturas que cursa.. 2.3.2.4.. Requisitos funcionales comunes. Funcionalidades generales a disposición de todos los actores. (RF 11). Iniciar sesión:. Para poder realizar las funciones según quien sea el actor o rol del usuario registrado que acceda al sistema.. (RF 12). Editar Perfil:. El usuario, tras el inicio de sesión, puede modificar los datos de su perfil, es decir, contraseña y datos de registro.. (RF 13). Solicitar Registro:. Los diferentes roles de usuario que el sistema proporciona requieren de un registro previo a solicitar.. (RF 14). Enviar Mensaje:. Funcionalidad que permite el envío de mensajes entre los usuarios del sistema.. (RF 15). Cargar Entorno:. Según el usuario que inicie la sesión se mostrará la interfaz del rol correspondiente.. (RF 16). Cerrar Sesión:. El actor sale del sistema retornando a la página de inicio de la aplicación web.. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
(34) 2.3. REQUISITOS FUNCIONALES. MODELO DE CASOS DE USO. 2.3.3.. 21. Diagrama de Casos de Uso. El siguiente diagrama modela los requisitos funcionales de los diferentes actores como casos de uso. Del modelo del negocio cada caso de uso general descrito incluye otro de edición con el fin de listar los datos. Figura 2.8: Diagrama de Casos de Uso El subsistema de Seguridad modela los requisitos funcionales de mayor riesgo comunes a los diferentes roles de usuario. El caso de uso Iniciar Sesión estará en el flujo principal en todas las operaciones anteriores asociadas a los diferentes subsitemas y actores o usuarios. Por tanto, deben haber solicitado registrarse mediante la funcionalidad o caso de uso correspondiente Solicitar Registro. El servicio de mensajería entre usuarios, modelado por el caso de uso Enviar Mensaje, permitirá la intercomunicación entre los diferentes actores o roles de usuario mediante el subsistema de mensajes que es parte del sistema y se ha modelado con un actor, así como el subsistema de gestión de base de datos (SGBD). Francisco J. Godoy Suárez. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo.
(35) 22. CAPÍTULO 2. ESPECIFICACIÓN DE REQUISITOS. 2.3.4.. Documentación textual de los casos de uso. El objetivo principal de este apartado es describir el flujo de sucesos en detalle de cada caso de uso, incluyendo como comienza, termina e interactua con los actores. Se detallan los tres primeros casos de uso, el resto en el Anexo I. La información de cada caso de uso está estructurada en una plantilla de la forma que sigue: • Cabecera: Número y nombre del caso de uso, descripción de la funcionalidad, actores implicados y casos de uso relacionados. • Cuerpo: Pre-condición o definición del estado inicial, flujo de sucesos o secuencia de acciones, alternativas de proceso y excepciones así como pos-condición o posibles estados finales. • Final: Excepciones y cuestiones que hay que aclarar. CU - 01 Descripción Actores Casos de uso relacionados Pre-condición Flujo de sucesos. Administra Grupo Inicia la gestión de los grupos con el caso de uso relacionado que incluye Administrador Editar Grupos Iniciar sesión con el rol de Administrador 1. Seleccionar la opción de menú de gestión de grupos. Pos-condición Excepciones. Realizar el caso de uso que incluye. CU - 02. Editar Grupos Al solicitar la gestión de grupos de usuarios se muestra lista éstos para su edición en la interfaz de usuario Administrador Administra Grupo, Crear Grupo, Eliminar Grupo y Modifica Grupo Acceso al sistema como administrador. Descripción Actores Casos de uso relacionados Pre-condición Flujo de sucesos. 1. Selección de los grupos de la base de datos 2. Mostrar la lista en páginas de pantalla. Pos-condición Excepciones. Listado de los grupos en la interfaz gráfica de usuario. CU - 03 Descripción Actores Casos de uso relacionados Pre-condición. Crea Grupo Se da alta a un nuevo grupo Administrador Editar Grupos Iniciar la edición de grupos como Administrador. Flujo de sucesos Pos-condición Excepciones. 1. Introducir nombre del grupo 2. Seleccionar los permisos de acceso 3. Grabar el alta del grupo Hay un nuevo grupo en el sistema. UOC 15/16(2) - TFC Aplicaciones Web para Trabajo Colaborativo. Francisco J. Godoy Suárez.
Figure
Documento similar
(Banco de España) Mancebo, Pascual (U. de Alicante) Marco, Mariluz (U. de València) Marhuenda, Francisco (U. de Alicante) Marhuenda, Joaquín (U. de Alicante) Marquerie,
diabetes, chronic respiratory disease and cancer) targeted in the Global Action Plan on NCDs as well as other noncommunicable conditions of particular concern in the European
Tejidos de origen humano o sus derivados que sean inviables o hayan sido transformados en inviables con una función accesoria.. Células de origen humano o sus derivados que
En la contrastación de las hipótesis de investigación se usaron pruebas paramétricas y no paramétrica previo análisis de la normalidad de los datos pretest y postest,
En este sentido, puede defenderse que, si la Administración está habilitada normativamente para actuar en una determinada materia mediante actuaciones formales, ejerciendo
Este mismo régimen de deberes tiene sentido cuando la actuación de reforma o renovación significa un cambio radical de la morfología urbana, normalmente acompa- ñado por un cambio
Se propone desarrollar una aplicación que permita Gestionar los AP en Cuba y para ello controle los servicios de Certificación y Cancelación de AP y mantenga actualizada la
Además se emplean los métodos empíricos tales como: el análisis de las fuentes de información, empleado para obtener resultados confiables relacionados con las pruebas