160
CMMJ - Tlf: (+34) 000 000 000 Convocatoria Diciembre Ingeniería del Software II Curso 2.015-2.016 CMMJ ÍNDICE

Ingenieria de Software II.pdf

  • Upload
    cmmj75

  • View
    15

  • Download
    1

Embed Size (px)

DESCRIPTION

Práctica correspondiente a la asignatura Ingeniería de Software II, convocatoria Septiembre 2.015

Citation preview

Page 1: Ingenieria de Software II.pdf

CMMJ

- Tlf: (+34) 000 000 000

Convocatoria Diciembre

Ingeniería del Software II

Curso 2.015-2.016

CMMJ

ÍNDICE

Page 2: Ingenieria de Software II.pdf

Ingeniería del Software II

2

2

CMMJ - Tlf: (+34) 000 000 000

Consideraciones previas. _________________________________________________ 7

1. Introducción ________________________________________________________ 9

1.1. Propósito _____________________________________________________________ 9

1.2. Alcance _______________________________________________________________ 9

1.3. Personal involucrado___________________________________________________ 10

1.4. Definiciones, acrónimos y abreviaturas. ___________________________________ 10

1.5. Referencias ___________________________________________________________ 11

2. Descripción general _________________________________________________ 11

2.1. Perspectiva del producto _______________________________________________ 11

2.2. Funcionalidad del producto _____________________________________________ 11

2.3. Características de los usuarios __________________________________________ 12

2.4. Restricciones _________________________________________________________ 13

2.5. Suposiciones y dependencias ___________________________________________ 13

3. Requisitos específicos _______________________________________________ 16

3.1. Requisitos comunes de los interfaces _____________________________________ 16

3.1.1. Interfaces de usuario _________________________________________________ 16

3.1.2. Interfaces de comunicación ___________________________________________ 16

3.2. Requisitos funcionales _________________________________________________ 17

3.2.1. Seguridad __________________________________________________________ 17

RF-SEG-001. Autenticación de usuarios _______________________________________________ 17

RF-SEG-002. Creación de sesión de usuario ____________________________________________ 18

RF-SEG-003. Comprobación de sesión de usuario _______________________________________ 19

RF-SEG-004. Purgado de sesión de usuario ____________________________________________ 20

RF-SEG-005. Control de acceso a funcionalidad o acción _________________________________ 20

3.2.2. Categorías __________________________________________________________ 21

RF-CAT-001. Mantenimiento de categorías: alta _________________________________________ 22

RF-CAT-002. Mantenimiento de categorías: búsqueda ___________________________________ 23

RF-CAT-003. Mantenimiento de categorías: edición y borrado _____________________________ 25

3.2.3. Asignaturas _________________________________________________________ 26

RF-ASG-001. Mantenimiento de asignaturas: alta ________________________________________ 27

RF-ASG-002. Mantenimiento de asignaturas: búsqueda __________________________________ 28

RF-ASG-003. Mantenimiento de asignaturas: asignación de profesor. ______________________ 30

RF-ASG-004. Mantenimiento de asignaturas: matriculación de alumno. ____________________ 31

RF-ASG-005. Mantenimiento de asignaturas: desmatriculación de alumno. _________________ 33

RF-ASG-006. Mantenimiento de asignaturas: edición y borrado ___________________________ 35

Page 3: Ingenieria de Software II.pdf

Ingeniería del Software II

3

3

CMMJ - Tlf: (+34) 000 000 000

3.2.4. Usuarios ___________________________________________________________ 38

RF-USU-001. Auto-mantenimiento de datos ____________________________________________ 38

RF-USU-002. Mantenimiento de usuarios: alta __________________________________________ 39

RF-USU-004. Mantenimiento de usuarios: búsqueda _____________________________________ 43

RF-USU-005. Mantenimiento de usuarios: edición y borrado ______________________________ 44

3.2.5. Preguntas __________________________________________________________ 47

RF-PRG-001. Mantenimiento de preguntas de examen: alta _______________________________ 47

RF-PRG-002. Mantenimiento de preguntas de examen: búsqueda __________________________ 50

RF-PRG-003. Mantenimiento de preguntas de examen: edición y borrado ___________________ 51

3.2.6. Modelos de examen __________________________________________________ 55

RF-EXA-001. Mantenimiento de modelos de examen: alta _________________________________ 55

RF-EXA-002. Mantenimiento de modelos de examen: búsqueda ___________________________ 61

RF-EXA-003. Mantenimiento de modelos de examen: edición _____________________________ 63

RF-EXA-004. Mantenimiento de modelos de examen: borrado _____________________________ 66

RF-EXA-005. Mantenimiento de modelos de examen: exportación e impresión. ______________ 67

3.2.7. Convocatorias de examen _____________________________________________ 69

RF-CNV-001. Mantenimiento de convocatorias de examen: alta ____________________________ 69

RF-CNV-002. Mantenimiento de convocatorias de examen: búsqueda ______________________ 72

RF-CNV-003. Mantenimiento de convocatorias de examen: borrado ________________________ 74

3.2.8. Ejecución de exámenes _______________________________________________ 77

RF-EJE-001. Ejecución de exámenes: Ejecución ________________________________________ 77

RF-EJE-002. Ejecución de exámenes: Revisión _________________________________________ 80

3.2.9. Corrección de exámenes ______________________________________________ 83

RF-EVA-001. Evaluación de exámenes: Tipo TEST _______________________________________ 83

RF-EVA-002. Evaluación de exámenes: Tipo DESARROLLO ______________________________ 86

3.3. Requisitos no funcionales __________________________________________ 89

3.3.1. Requisitos de rendimiento ____________________________________________ 89

3.3.2. Seguridad __________________________________________________________ 89

3.3.3. Fiabilidad ___________________________________________________________ 89

3.3.4. Disponibilidad _______________________________________________________ 89

3.3.5. Mantenibilidad ______________________________________________________ 89

3.3.6. Otros requisitos _____________________________________________________ 89

4. Apéndices _________________________________________________________ 90

4.1. Modelo de requisitos ___________________________________________________ 90

4.1.1. Diagramas de casos de uso ___________________________________________ 90

4.1.1.1. Seguridad ________________________________________________________ 90

4.1.1.2. Usuarios _________________________________________________________ 91

4.1.1.3. Categorías ________________________________________________________ 92

Page 4: Ingenieria de Software II.pdf

Ingeniería del Software II

4

4

CMMJ - Tlf: (+34) 000 000 000

4.1.1.4. Asignaturas _______________________________________________________ 93

4.1.1.5. Preguntas ________________________________________________________ 94

4.1.1.6. Modelos de examen ________________________________________________ 94

4.1.1.7. Convocatorias _____________________________________________________ 96

4.1.1.8. Ejecuciones _______________________________________________________ 97

4.1.1.9. Corrección de exámenes ____________________________________________ 98

4.1.2. Especificación de casos de uso ________________________________________ 99

4.1.2.7. RF-EXA-001. Mantenimiento de modelos de examen: alta. _________________ 99

4.1.1.7. RF-CNV-001. Mantenimiento de convocatorias: alta. ____________________ 104

4.1.1.7. RF-CNV-001. Mantenimiento de convocatorias: alta. ____________________ 107

4.2. Modelo de análisis ____________________________________________________ 112

4.2.1. Diagramas de clases ________________________________________________ 112

4.2.1.7. Servicios ________________________________________________________ 113

4.2.1.8. Usuarios ________________________________________________________ 115

4.2.1.9. Seguridad _______________________________________________________ 116

4.2.1.10. Matriculaciones ___________________________________________________ 117

4.2.1.11. Preguntas _______________________________________________________ 118

4.2.1.12. Modelos _________________________________________________________ 119

4.2.1.13. Convocatorias ____________________________________________________ 121

4.1.1.7. Ejecuciones ______________________________________________________ 122

4.1.1.8. Correcciones _____________________________________________________ 123

4.1.1.9. UI ______________________________________________________________ 124

4.1.2. Diagramas de secuencia _____________________________________________ 125

4.1.2.7. Comprobar sesión ________________________________________________ 126

4.1.1.7. Solicitar dato _____________________________________________________ 126

4.1.1.8. Comprobar acceso ________________________________________________ 128

4.1.1.7. Inicio o continuación de ejecución ___________________________________ 129

4.1.1.7. Guardado de ejecución ____________________________________________ 131

4.1.1.8. Auto guardado de la ejecución ______________________________________ 133

4.1.1.9. Crear modelo tipo TEST ____________________________________________ 134

4.1.1.7. Crear convocatoria ________________________________________________ 140

Page 5: Ingenieria de Software II.pdf

Ingeniería del Software II

5

5

CMMJ - Tlf: (+34) 000 000 000

4.1.1.7. Ejecutar examen tipo TEST _________________________________________ 144

4.1.2. Diagramas de paquetes ______________________________________________ 150

4.2. Modelo de análisis ____________________________________________________ 151

4.2.1. Diagramas de estado ________________________________________________ 151

4.2.1.7. Convocatoria _____________________________________________________ 151

4.2.1.8. Ejecución ________________________________________________________ 152

4.2.1.9. Usuario _________________________________________________________ 152

4.2.2. Diagramas de actividades ____________________________________________ 153

4.2.2.7. Alta usuario ______________________________________________________ 153

4.1.1.7. Crear convocatoria ________________________________________________ 153

4.1.1.7. Corregir ejecuciones tipo TEST. _____________________________________ 154

4.1.2. Patrones de diseño _________________________________________________ 156

4.1.2.7. Singleton ________________________________________________________ 156

4.1.2.8. Facade __________________________________________________________ 156

4.1.2.9. Iterator __________________________________________________________ 157

4.2. Modelo de desarrollo e implantación _____________________________________ 158

4.2.1. Diagramas de componentes __________________________________________ 159

4.2.2. Diagramas de despliegue ____________________________________________ 160

Page 6: Ingenieria de Software II.pdf

Ingeniería del Software II

6

6

CMMJ - Tlf: (+34) 000 000 000

Page 7: Ingenieria de Software II.pdf

Ingeniería del Software II

7

7

CMMJ - Tlf: (+34) 000 000 000

Consideraciones previas.

Este documento recoge el trabajo desarrollado por el alumno Carlos Manuel Morón Jiménez

durante la realización de la práctica de evaluación correspondiente a la asignatura “Ingeniería del

Software II” impartida por D. FP García.

El trabajo cubre las especificaciones solicitadas en el enunciado de la práctica que, de forma

resumida, consta de las siguientes partes:

1. Documento de especificación de requisitos en formato IEEE830

2. Modelo de requisitos:

Diagrama de casos de uso

Especificación 3 casos de uso

3. Modelo de análisis:

Diagrama de clases

Diagrama de secuencia o comunicación de 3 casos de uso.

Diagrama de paquetes

4. Modelo de diseño:

Diagrama de estado de 3 clases

Diagrama de actividades de 3 operaciones (clases o flujos de trabajo)

Identificar y justificar el uso de 3 patrones de diseño.

5. Modelo de desarrollo e implantación

Diagrama de componentes

Diagrama de despliegue

Como enunciado de la práctica, se ha facilitado un documento de requisitos preliminar donde

quedan recogidas las funcionalidades más importantes que el sistema a desarrollar debe cumplir.

El carácter estático de este documento y la ausencia de un cliente real detrás del proyecto a

desarrollar justifica la realización de ciertas asunciones que son detalladas en el apartado

correspondiente de la especificación de requisitos realizada.

El formato en el que se presenta esta memoria se corresponde con el estándar IEEE830,

incluyéndose el trabajo de diseño realizado y resto de elementos solicitados en la práctica como

anexos a este.

Page 8: Ingenieria de Software II.pdf

Ingeniería del Software II

8

8

CMMJ - Tlf: (+34) 000 000 000

Page 9: Ingenieria de Software II.pdf

Ingeniería del Software II

9

9

CMMJ - Tlf: (+34) 000 000 000

1. Introducción

1.1. Propósito

Como cualquier obra de ingeniera, la realización de un proyecto informático requiere de la definición del alcance y objetivos que se pretenden lograr. Estos se deducen a partir de las necesidades y deseos expresados por el cliente en los estadios iniciales de la ejecución del mismo, si bien, es común que se vayan refinando durante fases posteriores hasta bien avanzado su desarrollo.

Esta especificación queda justificada por la necesidad de disponer de un soporte documental donde vayan quedando registrados de forma clara, inequívoca y verificable los requisitos y sus evoluciones acordados entre cliente y equipo de desarrollo respecto al sistema software a realizar, de tal forma que desempeñe dos importantes funciones; como pacto vinculante para ambas partes que elimine la aparición de controversias o interpretaciones sobre el contenido del sistema desarrollado y una segunda función de guía para la visualización y comprensión del propio proyecto, pudiendo ser s su vez empleado como soporte para el descubrimiento de nuevas funcionalidades. El acceso a este documento es pertinente para todas las personas que tengan relación con el proyecto, estando especialmente dirigido a aquellas cuya labor pueda verse directa o indirectamente afectada como resultado de la construcción del sistema.

1.2. Alcance

El proyecto se va a identificar con el nombre de “Telexamen”, y tiene como objetivo genérico la construcción de una plataforma que permita la gestión y realización de exámenes de asignaturas forma telemática por parte de los usuarios del sistema, divididos en profesores, alumnos y administradores. Para ello, el sistema deberá incorporar un control de acceso que permita determinar las responsabilidades y capacidades de cada usuario frente al sistema. Por su parte, cada administrador deberá disponer de la funcionalidad que le permita efectuar el mantenimiento de las estructuras de datos que soportan a nivel lógico el sistema, destacando la creación de usuarios, asignaturas así como la asignación de profesores y alumnos a asignaturas. El sistema además deberá incorporar la funcionalidad necesaria para que cada profesor pueda crear exámenes a partir de una batería de preguntas de las asignaturas que tenga asignadas, programar, controlar y definir los criterios de valoración y corrección de las preguntas, así como corregir de forma manual o automática los exámenes.

Page 10: Ingenieria de Software II.pdf

Ingeniería del Software II

10

10

CMMJ - Tlf: (+34) 000 000 000

También deberá dotar al alumno de la capacidad para realizar exámenes, tener constancia de que la realización del examen se ha registrado correctamente, conocer qué exámenes debe realizar en las asignaturas en las que se encuentre adscrito y qué plazo dispone para completarlo.

1.3. Personal involucrado

Nombre FPG

Rol Profesor

Categoría profesional Profesor

Responsabilidades Profesor de la asignatura ISII, tiene encomendada la tarea de representar al cliente en la definición de las funcionalidades y responsabilidad del sistema.

Información de contacto

@ucam.edu

1.4. Definiciones, acrónimos y abreviaturas.

o ACTOR: Persona que interactúa con el sistema

o ASIGNATURA: Materia que se enseña en el centro.

o MODELO DE EXAMEN: Modelo de prueba académica para comprobar los

conocimientos adquiridos sobre una materia concreta.

o EXAMEN: Convocatoria vinculada a una asignatura para la ejecución de un modelo de examen.

o EJECUCIÓN DE EXAMEN: Instancia de examen completada por un alumno.

o CATEGORIA: Clasificación otorgada por el profesor sobre una pregunta o examen.

o BÚSQUEDA APROXIMADA: Modo de búsqueda sobre una campo de una tabla en la que se considera que un registro responde a la búsqueda cuando el literal buscado es igual o parecido al contenido del campo.

o IDENTIFICADOR ÚNICO: Código que designa de forma unívoca a un elemento

dentro de un conjunto de elementos de la misma naturaleza.

Page 11: Ingenieria de Software II.pdf

Ingeniería del Software II

11

11

CMMJ - Tlf: (+34) 000 000 000

o REGISTRO: Unidad de información estructurada, compuesta por un conjunto modelado de datos que abstraen una determinada realidad.

o TABLA: Almacén de registros de la misma naturaleza.

o PERFIL DE USUARIO: Conjunto de datos que identifican a un actor, sus capacidades funcionales y de acceso en el sistema.

o SESION: Representación lógica de la presencia de un actor concreto interactuando con el sistema.

o MARCA DE TIEMPO: Es la representación lógica de un momento concreto en el tiempo con un nivel de precisión determinado. En la aplicación, el nivel de detalle alcanzado cubre fecha y hora completas hasta milisegundos.

1.5. Referencias

Titulo Ruta Fecha Autor

ISW2-1516PRES-Practica-Diciembre

13/10/2015 FP - UCAM

2. Descripción general

2.1. Perspectiva del producto

El producto en construcción va a ser el primer componente de una plataforma de educación a la que en el futuro y según indica el cliente, se irán incorporando nuevos componentes aún por definir, para cristalizar finalmente en un sistema de formación online integral.

2.2. Funcionalidad del producto

A continuación se describen las principales funcionalidades del producto agrupadas en las áreas funcionales identificadas en la definición del producto. SEGURIDAD

Page 12: Ingenieria de Software II.pdf

Ingeniería del Software II

12

12

CMMJ - Tlf: (+34) 000 000 000

Autenticación de usuarios.

Inicio y control de sesión.

Niveles de acceso y funcionalidad por usuario.

USUARIO

Mantenimiento de información del perfil de usuario ADMINISTRACIÓN

Mantenimiento de asignaturas

Mantenimiento de usuarios

Asignaciones asignaturas/usuarios

EXÁMENES

Mantenimiento de categorías

Mantenimiento de preguntas

Mantenimiento de modelos de examen

Convocatoria de exámenes

Realización de exámenes

Corrección de exámenes

Impresión/exportación de exámenes

NOTIFICACIONES

Notificaciones sobre disponibilidad de exámenes

Notificaciones de confirmación de exámenes correctamente finalizados.

2.3. Características de los usuarios

Tipo de usuario Profesor

Formación Docente

Habilidades Capacidad de aprendizaje. Capacidad de análisis, relación de conceptos y planificación. Experiencia en el manejo de herramientas en un entorno web.

Responsabilidades Gestionar, definir y corregir los exámenes que permitan validar los conocimientos adquiridos por los alumnos.

Tipo de usuario Alumno

Page 13: Ingenieria de Software II.pdf

Ingeniería del Software II

13

13

CMMJ - Tlf: (+34) 000 000 000

Formación N/A

Habilidades N/A

Responsabilidades Acreditar la asimilación de conocimientos mediante la realización de los exámenes que determine el profesor.

Tipo de usuario Administrador

Formación Técnica y, opcionalmente, docente

Habilidades Experiencia en aplicaciones de gestión. Conocimientos y experiencia en el empleo de bases de datos y modelos relacionales. Proactividad. Capacidad de análisis y planificación. Capacidad de adaptación y aprendizaje.

Responsabilidades Mantener la información que soporta el funcionamiento lógico del sistema.

2.4. Restricciones

El sistema se deberá diseñar empleando el estándar UML como lenguaje de modelado.

2.5. Suposiciones y dependencias

A continuación, se detallan los presupuestos y asunciones que se han tenido en cuenta durante el desarrollo de este documento:

La autorización de creación de usuarios deberá ser realizada de forma específica por un profesor responsable indicado por el administrador durante el proceso de creación del usuario. Cada profesor dispondrá de un punto en la aplicación donde podrán localizar y autorizar a los usuarios que se les haya encomendado su autorización. Los nuevos usuarios no podrán acceder al sistema hasta que hayan sido autorizados por el profesor correspondiente.

Se asume que a nivel de seguridad, el usuario de tipo ADMINISTRADOR puede realizar cualquier acción catalogada en el sistema, excepto aquellas referidas en el documento preliminar de requisitos ISW2-1516PRES-Practica-Diciembre en las que se especifica que serán realizadas por un usuario de tipo PROFESOR.

El profesor será propietario de sus categorías, sus preguntas, sus modelos de examen.

Page 14: Ingenieria de Software II.pdf

Ingeniería del Software II

14

14

CMMJ - Tlf: (+34) 000 000 000

Las categorías pueden ser empleadas como elementos de catalogación tanto de preguntas como para convocatorias de examen.

Las preguntas tendrán dos modos de ser categorizadas, a través de una asignatura y/o a través de una categoría, siendo necesario que dispongan de, al menos, una de las dos clasificaciones. Una pregunta solo admite una categorización de cada tipo.

El ámbito del conocimiento que evalúan los distintos modelos de examen se define a través de las asignaturas y/o categorías empleadas para etiquetarlos. Un modelo de examen puede tener tantas etiquetas como el profesor estime necesario.

La búsqueda de preguntas para asignar a un modelo de examen siempre será automática y aleatoria, siendo este proceso realizado durante la creación del modelo. El número de preguntas que componen el modelo será expresado por el profesor durante su creación.

La búsqueda automática de preguntas en la batería del profesor para el modelo de examen en crese realizará empleando como criterio de búsqueda el ámbito de conocimiento definido a través de las mencionadas etiquetas. De este modo, el sistema permitirá crear modelos de examen específicos para una asignatura, para varias, para un área de conocimiento, para varias áreas de conocimiento o para la combinación de todos estos elementos, en función de los conocimientos que se pretendan evaluar.

Las preguntas propuestas por el sistema para un modelo de examen serán evaluadas por parte del profesor durante el proceso de creación del modelo, aceptando o rechazado cada una de ellas según su propio criterio.

Las preguntas rechazadas serán sustituidas por otras igualmente pertinentes, no rechazadas y no repetidas respecto a las seleccionadas, y serán nuevamente sometidas al proceso de validación del profesor.

No se podrá crear un modelo cuando no exista un número suficiente de preguntas en la batería de preguntas del profesor consistentes con el ámbito de conocimiento indicado a través de las etiquetas.

No se podrán rechazar más preguntas cuando no queden preguntas sin rechazar o ya empleadas en el modelo dentro de la batería del profesor para el ámbito de conocimiento consignado en el modelo.

El establecimiento de los criterios de valoración y, en su caso, penalización será

realizado durante la creación del modelo de examen.

Cada modelo de examen dispondrá de una valoración para las preguntas y, si procede, unos posibles criterios de penalización que serán establecidos por defecto para todas las preguntas. Durante el proceso de evaluación de las preguntas del modelo, el profesor podrá redefinir de forma individual para una pregunta tanto su valoración como el peso del o de los criterios de penalización ya definidos para el modelo. Así, para una pregunta cuya valoración se hubiera redefinido a 3 puntos y el modelo dispusiese del criterio de restar en caso de error, se podría modificar el peso

Page 15: Ingenieria de Software II.pdf

Ingeniería del Software II

15

15

CMMJ - Tlf: (+34) 000 000 000

de esta pregunta para que en caso de errar su respuesta, se restasen por ejemplo 1.5 puntos en lugar de 1.

La impresión y exportación se podrá realizar sobre los modelos de examen ya existentes en el sistema.

La creación de convocatorias exige la especificación de un modelo de examen a emplear y una asignatura, no siendo necesaria la existencia de una relación entre esta última y el ámbito del conocimiento establecido en el modelo a través de sus etiquetas.

Las convocatorias no se pueden editar, solo podrán crearse y borrarse.

La creación de una convocatoria implica la creación de todas las instancias de ejecución de los alumnos matriculados en la asignatura sobre la que se crea la convocatoria.

Para los exámenes de tipo test, la corrección será automática pero se encontrará supeditada a la acción del profesor responsable de la convocatoria. El profesor podrá invocar el proceso de corrección automático tantas veces como estime necesario siempre y cuando queden ejecuciones pendientes de corregir, siendo responsabilidad del sistema determinar el conjunto de exámenes que se encuentren en disposición de ser corregidos en función del momento en el que se invoque el proceso respecto al periodo de disponibilidad de la convocatoria. El objeto de esta aproximación es facilitar al profesor información sobre la evolución de las ejecuciones realizadas por los alumnos en la convocatoria. En cada invocación el sistema facilitará una pequeña estadística con los exámenes corregidos. Queda por definir qué otros datos formarán parte de esa estadística.

Para los exámenes de tipo desarrollo, la corrección igualmente se encontrará supeditada a una acción del profesor, pero en este caso será manual. El profesor podrá acceder al proceso de corrección manual tantas veces como necesite siempre y cuando queden ejecuciones pendientes de corregir, siendo responsabilidad del sistema determinar el conjunto de exámenes que se encuentren en disposición de ser corregidos en función del momento en el que se invoque el proceso respecto al periodo de disponibilidad de la convocatoria.

Los exámenes que no hayan sido comenzados por los alumnos, sean test o desarrollo, se considerarán como no presentados y no serán formalmente evaluados. El profesor, una vez finalizada la convocatoria, podrá invocar el cierre de estas ejecuciones. Por homogeneidad en cuanto al proceso de corrección, se ha decidido mantener esta aproximación para ambas tipologías de examen.

Una convocatoria se considerará finalizada cuando su periodo de disponibilidad haya expirada y se hayan corregido y cerrados según corresponda todas sus ejecuciones.

La seguridad se realizará mediante el empleo de servicios y roles, posibilitando en un futuro una especificación más fina del control de acceso y visibilidad de los

Page 16: Ingenieria de Software II.pdf

Ingeniería del Software II

16

16

CMMJ - Tlf: (+34) 000 000 000

elementos y/o funcionalidades del sistema. En una primera aproximación, se definirán tres roles equivalentes a las tres tipologías de usuario detectadas

Este documento no cubre la especificación física o maquetación del interfaz gráfico, si bien si define las funcionalidades que podrán ser empleadas desde este. Se asume que habrá un servicio que dará respuesta al interfaz y que será el que interactúe con los servicios de la aplicación.

Se asume que el sistema será desarrollado de tal forma que solo serán visibles los servicios a través de sus interfaces, quedando las implementaciones ocultas.

Se asume que se habrá una plataforma de correo accesible al sistema a través de la cual se podrán realizar las notificaciones que el sistema necesita realizar. Esta plataforma empleará el protocolo estándar SMTP para el envío de correos.

Se asume que habrá una plataforma de base de datos relacional a disposición del sistema en la que se persistirán las estructuras de datos del sistema.

3. Requisitos específicos

3.1. Requisitos comunes de los interfaces

Tal y como se indica en el documento preliminar de requisitos facilitado ISW2-1516PRES-Practica-Diciembre facilitado por el cliente, la aplicación debe desarrollarse para que sea ejecutada en entornos web, de tal forma la identificación y catalogación de interfaces deberá ser acorde al empleo de este tipo de tecnologías.

3.1.1. Interfaces de usuario

Pendiente de definición, condicionado a las capacidades de un entorno WEB.

3.1.2. Interfaces de comunicación

Todos los elementos que forman parte del sistema se encuentran inmersos en una red, de tal forma que todas las interdependencias que puedan existir entre ellos quedarán resueltas mediante la incorporación de los protocolos de comunicación estándar correspondientes.

Page 17: Ingenieria de Software II.pdf

Ingeniería del Software II

17

17

CMMJ - Tlf: (+34) 000 000 000

Pasando a concretar las comunicaciones identificadas, el sistema deberá comunicarse con otros sistemas para el envío de notificaciones a través de correo electrónico. Tal y como se indica en el apartado ¡Error! No se encuentra el origen de la referencia. de ste documento, el protocolo que incorporará esta plataforma será el protocolo SMTP o protocolo para transferencia simple de correo”. Este es un protocolo de red utilizado para el intercambio de mensajes de correo electrónico entre computadoras u otros dispositivos. Por otro lado, dado que se trata de una aplicación web, la comunicación entre los clientes, sean internos o externos, y la propia aplicación se realizarán empleando el protocolo HTTPS, que garantiza la máxima seguridad. Ello implica que el sistema deberá ser registrado y obtener un certificado de una autoridad certificadora. Las comunicaciones realizadas por la propia aplicación se realizarán empleando servicios

3.2. Requisitos funcionales

A partir del documento preliminar de requisitos facilitado ISW2-1516PRES-Practica-Diciembre facilitado por el cliente, se ha realizado la identificación de los requisitos funcionales incluidos a continuación, agrupados por áreas para su mejor comprensión.

3.2.1. Seguridad

Se incluyen en este apartado los requisitos identificados vinculados a la seguridad, accesibilidad y visibilidad de usuarios y elementos de la aplicación.

Id y nombre del requisito RF-SEG-001. Autenticación de usuarios

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Descripción El sistema solo permite el acceso a aquellos usuarios que, estando previamente registrados, faciliten la correcta combinación de credenciales.

Entradas - Correo electrónico de usuario - Password de usuario

Secuencia de operación Se busca la combinación de correo electrónico y password facilitados por el actor en los campos que albergan esta información de la tabla de usuarios del sistema. Se comprueba que el estado que muestra el registro de usuario localizado es AUTORIZADO y se retorna el identificador del

Page 18: Ingenieria de Software II.pdf

Ingeniería del Software II

18

18

CMMJ - Tlf: (+34) 000 000 000

usuario contenido en el registro localizado.

Salidas - Identificador de usuario

Errores Si no se localiza ninguna entrada en la tabla que responda a los datos facilitados, se impedirá el acceso y se generará un mensaje indicando esta circunstancia. Si el estado del usuario no es AUTORIZADO se impedirá el acceso y se generará un mensaje indicando tal circunstancia.

Id y nombre del requisito RF-SEG-002. Creación de sesión de usuario

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Descripción El sistema podrá crear una sesión de usuario cuando la autenticación haya ofrecido un resultado positivo. Una sesión de usuario es una abstracción de la presencia de un usuario concreto interactuando con el sistema y sirve para que el sistema sepa quién está interactuando con él. La sesión de usuario alberga la información que constituye el perfil de usuario compuesta por el identificador único del usuario que está interactuando con el sistema, su tipo y una marca de tiempo que contiene el momento de última interacción entre el usuario al que representa la sesión y el sistema. La sesión será asignada con un identificador único de sesión generado por el sistema que permitirá su posterior referenciación y acceso. La sesión de usuario se guarda en un almacén temporal, de forma que sea recuperable en base al identificador de sesión único.

Entradas - Identificador único de usuario - Tipo de usuario

Secuencia de operación El sistema comprueba que el perfil de usuario recibido tenga contenido. El sistema crea una nueva instancia de sesión en la que deposita los datos recibidos en la entrada y asigna la marca de tiempo que refleja el momento de última actividad de la sesión. El sistema genera y asigna a la sesión un identificador aleatorio y único compuesto por 30 caracteres alfanuméricos que

Page 19: Ingenieria de Software II.pdf

Ingeniería del Software II

19

19

CMMJ - Tlf: (+34) 000 000 000

garantice la unicidad de la misma frente al resto de sesiones vivas. A continuación incluirá la sesión construida en un almacenamiento temporal, de tal forma que pueda ser nuevamente accedida mediante el identificador único asignado. Finalmente, devuelve el identificador de sesión generado.

Salidas - Identificador de sesión

Errores Si el perfil de usuario es vacio, no se permite la creación de la sesión de usuario, se aborta la acción y se genera un mensaje informando de tal circunstancia.

Id y nombre del requisito RF-SEG-003. Comprobación de sesión de usuario

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación Las sesiones de usuario se mantendrán vigentes en el sistema siempre y cuando el usuario al que representa esté realizando un uso efectivo de la misma. Periódicamente el sistema purgará las sesiones no activas.

Entradas - Identificador de sesión - Tiempo de pervivencia de una sesión

Secuencia de operación Se recibe un identificador de sesión y tratará de recuperar la sesión correspondiente al identificador del almacenamiento temporal. Con la sesión recuperada, el sistema determinará su vigencia comprobando el tiempo transcurrido entre la última interacción reflejado en la marca de tiempo de la última actividad de la sesión y el momento actual. Si la sesión se considera viva, el sistema actualizará la marca de tiempo de la sesión y la volverá a persistir en el almacenamiento temporal, devolviéndose nuevamente el identificador recibido. En caso contrario, el sistema eliminará la sesión del almacenamiento temporal, descartará la sesión recuperada y generará un mensaje de error informando sobre la expiración de la sesión.

Page 20: Ingenieria de Software II.pdf

Ingeniería del Software II

20

20

CMMJ - Tlf: (+34) 000 000 000

Salidas - Identificador de sesión.

Errores En caso de la que él identificador de sesión recibido no tenga correspondencia con una sesión almacenada en el repositorio temporal, el sistema aborta la acción y genera un mensaje de error indicando que la sesión está expirada y se le conducirá a la página de acceso al sistema.

Id y nombre del requisito RF-SEG-004. Purgado de sesión de usuario

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación Las sesiones de purgaran de forma periódica cuando haya transcurrido un tiempo determinado desde su última actividad. La periodicidad con la que se comprobará la necesidad de purgar las sesiones deberá ser mayor que el tiempo durante el cual una sesión se considera viva. Periódicamente el sistema purgará las sesiones no activas.

Entradas - Identificador de sesión - Intervalo de ejecución del proceso. - Tiempo de pervivencia de una sesión

Secuencia de operación Con la periodicidad establecida en el parámetro intervalo de ejecución del proceso, el sistema accederá al almacenamiento temporal de sesiones y comprobar la vigencia de todas ellas. La comprobación de vigencia y acciones a realizar se realiza según lo descrito en el requisito funcional RF-SEG-004, con la particularidad de que no se actualizará la marca de última interacción de las sesiones evaluadas, ni se generará ningún mensaje.

Salidas - N/A

Errores

Id y nombre del requisito RF-SEG-005. Control de acceso a funcionalidad o acción

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Page 21: Ingenieria de Software II.pdf

Ingeniería del Software II

21

21

CMMJ - Tlf: (+34) 000 000 000

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Descripción El sistema controlara y, en su caso, impedirá el acceso a funcionalidades cuando el tipo de usuario del actor que esté intentando acceder a la funcionalidad o realizar la acción no tenga correspondencia con ninguno de los tipos de usuario que dicha funcionalidad o acción tenga autorizados.

Entradas - Identificador de sesión - Tipos de usuario autorizados. - Descripción de la funcionalidad o acción

Secuencia de operación Se tratará de recuperar la sesión de usuario correspondiente al identificador de sesión recibido en el almacenamiento temporal de sesiones, siguiendo las especificaciones establecidas en el RF-SEG-003. Si el valor del tipo de usuario autorizado recibido es vacio, se considera que cualquier usuario está autorizado para realizar la acción solicitada no se realizará ninguna otra comprobación En caso contrario, con el perfil obtenido de la sesión, se comprobará que el tipo de usuario que refleje se corresponde con alguno de los tipos de usuario autorizados recibidos. Si se encuentra coincidencia se considerara que el usuario dispone de privilegios para acceder a la funcionalidad o realizar la acción.

Salidas - N/A

Errores En caso de la que él identificador de sesión recibido no tenga correspondencia con una sesión almacenada en el repositorio temporal, el sistema aborta la acción y generará un mensaje de error indicando que la sesión está expirada y se le conducirá a la página de acceso al sistema. En caso de que el tipo de usuario contenido en el perfil de usuario recibido sea distinto del recibido como autorizado, se aborta la acción y se genera un mensaje indicando que el usuario no tiene privilegios acceder a la funcionalidad o ejecutar la acción descrita en el parámetro de entrada correspondiente.

3.2.2. Categorías

Se incluyen en este apartado los requisitos identificados en documento preliminar de requisitos vinculados a la especificación de categorías

Page 22: Ingenieria de Software II.pdf

Ingeniería del Software II

22

22

CMMJ - Tlf: (+34) 000 000 000

Id y nombre del requisito RF-CAT-001. Mantenimiento de categorías: alta

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la creación de categorías nuevas, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo PROFESOR, ya que son privativas de él. El sistema provee de un formulario donde el actor rellena los campos categoría y descripción de categoría. Este formulario contiene a su vez dos botones, uno para crear la asignatura con los datos incluidos en el formulario y otro para cancelar la creación. El sistema informará al actor del resultado de la acción.

Entradas - Identificador de sesión

Secuencia de operación Se comprueba que el actor puede realizar la acción de crear categorías aplicando la funcionalidad recogida en el punto 0 y sabiendo que esta solo se encuentra habilitada para usuario de tipo PROFESOR Se mostrará al actor un formulario con los campos categoría y descripción de categoría. En el formulario también se muestran dos botones, uno con el texto “crear” y otro con el texto “cancelar” Si el actor pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. Si el actor pulsa el botón crear, el sistema comprobará que los datos presentes en los campos del formulario son correctos aplicando las siguientes reglas:

- Todos los campos han de tener valor. - Código y descripción de la categoría son alfanuméricos y

podrán recibir cualquier valor cuya longitud no supere la estipulada en el modelado de las tablas que los contengan.

A continuación se realizará una búsqueda en la tabla de categorías verificando que no exista ninguna otra asignatura con el mismo código y cuyo identificador único de profesor propietario coincida con el identificador único del usuario contenido en el perfil de usuario del actor. Cuando no se localice ninguna entrada en esta tabla, se

Page 23: Ingenieria de Software II.pdf

Ingeniería del Software II

23

23

CMMJ - Tlf: (+34) 000 000 000

insertará un nuevo registro en la misma con los siguientes datos:

- Identificador único de la categoría generado - Identificador único deI profesor propietario, que será

rellenado con el identificador único del usuario contenido en el perfil de usuario del actor

- Código de la categoría - Descripción de la categoría - Estado de la categoría, rellenado con el valor ACTIVA

Se mostrará un mensaje informando sobre la correcta finalización de la acción y se retornará la categoría creada.

Salidas - Mensajes - Datos creados de la nueva categoría

Errores Si alguno de los datos no cumple las condiciones de validación, se aborta la acción y se genera un mensaje indicando tal circunstancia, detallando cuál o cuáles de los datos no cumple la validación. Si se localizar una categoría en la tabla de categorías que dispone del mismo código de categoría e identificador único de profesor propietario que el identificador único del usuario contenido en el perfil de usuario del actor, se detiene la acción y se genera un mensaje donde se informa que ya existe una categoría igual en el sistema. En caso de que los datos hayan sido concurrentemente manipulados por otra sesión del mismo usuario o cualquier otra casuística que evite la actualización de los datos, se mostrará un error informando y se cancelará la acción.

Id y nombre del requisito RF-CAT-002. Mantenimiento de categorías: búsqueda

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la búsqueda de categorías, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo PROFESOR o ADMINSTRADOR. El sistema provee de un formulario donde el actor podrá determinar los criterios para realizar la búsqueda y los botones para efectuar la búsqueda o cancelar la acción.

Page 24: Ingenieria de Software II.pdf

Ingeniería del Software II

24

24

CMMJ - Tlf: (+34) 000 000 000

No hay obligatoriedad de indicar ningún criterio para realizar la búsqueda. El sistema le mostrará en un listado los resultados de la consulta realizada

Entradas - Identificador de sesión - Criterios adicionales.

Secuencia de operación Se comprueba que el actor puede realizar la acción de buscar categorías aplicando la funcionalidad recogida en el punto 0 y sabiendo que esta solo se encuentra habilitada para usuarios de tipo ADMINISTRADOR o PROFESOR. Se mostrará al actor un formulario con el campo identificador único de la categoría, código de la categoría, estado de la categoría y descripción de la categoría. En el formulario también se muestran dos botones, uno con el texto “buscar” y otro con el texto “cancelar” Si el actor pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. Si el actor pulsa el botón buscar, el sistema compondrá los criterios a aplicar para la búsqueda con los datos proporcionados en el formulario, siendo la búsqueda que realice sobre el campo descripción de la categoría aproximada. A los criterios especificados, se añadirán los criterios adicionales recibidos en la entrada y además, si el tipo de usuario del actor es PROFESOR, se añadirá un nuevo criterio para capturar únicamente las asignaturas que son de su propiedad. Si no se ha incluido ningún dato en el formulario y los filtros adicionales no disponen de contenido, se realizará una búsqueda sin más filtros que los dependientes del tipo de de usuario. Con los registros localizados, se generará un listado compuesto por el identificador único de la categoría, el código, el estado y la descripción, ordenado por código (a-z) Dicho listado se muestra al actor en el mismo formulario de búsqueda, de tal forma que este pueda seleccionar una de las categorías contenidas en la tabla, que será retornada o bien cancelar la búsqueda a través del botón correspondiente.

Salidas - Mensajes - Datos de la categoría seleccionada.

Errores Cuando alguno de los filtros adicionales no esté definido sobre ninguno de los campos presentes en el formulario de búsqueda se generará un error informando tal circunstancia y abortando

Page 25: Ingenieria de Software II.pdf

Ingeniería del Software II

25

25

CMMJ - Tlf: (+34) 000 000 000

el proceso de búsqueda.

Id y nombre del requisito RF-CAT-003. Mantenimiento de categorías: edición y

borrado

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la edición y borrado de categorías, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo PROFESOR o ADMINSTRADOR. El sistema provee de un formulario donde el usuario podrá visualizar los campos identificador único de la categoría, estado de la categoría y descripción, de los cuales solo serán editables los tres últimos. El formulario mostrará además tres botones, uno para borrar la categoría, otro para modificar la categoría con los cambios realizados sobre los datos y un tercer botón para cancelar la acción.

Entradas - Identificador de sesión - Identificador único de categoría

Secuencia de operación Se comprueba que el actor puede realizar la acción de edición y baja de categorías aplicando la funcionalidad recogida en el punto 0 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ADMINISTRADOR y PROFESOR. El sistema accederá a la tabla de categorías para localizar el registro de categoría que responda al identificador único de categoría recibido en la entrada. A continuación se mostrará al actor un formulario cargado con la información del registro localizado. En este formulario figurarán los campos identificador único de la categoría, código de categoría y descripción, de los cuales solo serán editables los dos últimos, junto con tres botones; uno con el texto “borrar”, otro con el texto “actualizar” y un tercero con el texto “cancelar” Si pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. Si pulsa el botón actualizar, el sistema comprobará que los datos rellenados por el usuario en los campos del formulario son correctos aplicando las siguientes reglas:

Page 26: Ingenieria de Software II.pdf

Ingeniería del Software II

26

26

CMMJ - Tlf: (+34) 000 000 000

- Todos los datos han de tener valor. - Código y descripción de la categoría son alfanuméricos y

podrán recibir cualquier valor cuya longitud no supere la estipulada en el modelado de las tablas que los contenga.

- El campo estado solo permite los valores ACTIVA e INACTIVA

Si los datos cumplen con estas validaciones, serán almacenados en el registro de la tabla de categorías identificado por el identificador único de la categoría recibido en la entrada y se mostrará un mensaje al actor indicándole que los cambios se han almacenado correctamente. Si pulsa el botón borrar, el sistema mostrará un cuadro de texto para que el actor confirme la acción. Si el actor confirma la acción el sistema comprobará si la categoría se encuentra utilizada en alguna entidad relacionada de la aplicación, concretamente en preguntas o en exámenes, en cuyo caso no realizará un borrado físico sino que simplemente el sistema cambiara el estado de la categoría a INACTIVO Si no ha sido empleado en ningún otro punto, se realizará el borrado físico del registro.

Finalmente el sistema después de realizar el borrado, mostrará un mensaje informando sobre la correcta realización del proceso detallando si procede el tipo de borrado aplicado y se cerrará el formulario, retornando los datos del a categoría modificada o eliminada.

Salidas - Mensajes - Datos modificados de la categoría

Errores Si no se localiza la información a editar/borrar a partir del identificador único recibido, se cancelará la acción y se mostrará un mensaje indicando tal circunstancia, cerrándose el formulario. Si alguno de los datos no cumple las condiciones de validación cuando el actor haya optado por el botón “actualizar”, se aborta la acción y se genera un mensaje indicando tal circunstancia, detallando cuál o cuáles de los datos no cumple la validación, pero no se cierra el formulario.

3.2.3. Asignaturas

Page 27: Ingenieria de Software II.pdf

Ingeniería del Software II

27

27

CMMJ - Tlf: (+34) 000 000 000

Se incluyen en este apartado los requisitos identificados vinculados con las tareas administrativas genéricas de la aplicación relacionadas con las asignaturas.

Id y nombre del requisito RF-ASG-001. Mantenimiento de asignaturas: alta

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la creación de asignaturas nuevas, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo ADMINISTRADOR. El sistema provee de un formulario donde el actor rellena los campos código de asignatura y nombre Este formulario contiene a su vez dos botones, uno para crear la asignatura con los datos incluidos en el formulario y otro para cancelar la creación. El sistema informará al actor del resultado de la acción.

Entradas - Identificador de sesión

Secuencia de operación Se comprueba que el actor puede realizar la acción de crear asignaturas aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ADMINISTADOR Se mostrará al actor un formulario con los campos código y nombre de la asignatura. En el formulario también se muestran dos botones, uno con el texto “crear” y otro con el texto “cancelar” Si el actor pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. Si el actor pulsa el botón crear, el sistema comprobará que los datos presentes en los campos del formulario son correctos aplicando las siguientes reglas:

- Todos los datos recibidos han de tener valor. - Código y nombre de la asignatura son alfanuméricos y

podrán recibir cualquier valor cuya longitud no supere la estipulada en el modelado de las tablas que los contengan.

A continuación se realizará una búsqueda en la tabla de asignaturas verificando que no exista ninguna otra asignatura con el mismo código.

Page 28: Ingenieria de Software II.pdf

Ingeniería del Software II

28

28

CMMJ - Tlf: (+34) 000 000 000

Finalmente se insertará una nueva asignatura en la tabla de asignatura con:

- Los datos del formulario - Un identificador único para la asignatura generado.

Se retornará un mensaje con el identificador único de la asignatura creada informando sobre la correcta finalización de la acción y los datos de la asignatura

Salidas - Mensaje - Datos creados de la nueva asignatura

Errores Si alguno de los datos no cumple las condiciones de validación, se detiene la acción y se genera un mensaje indicando tal circunstancia, detallando cuál o cuáles de los datos no cumple la validación, permaneciendo en el formulario de edición. Si se localizar una asignatura en la tabla de asignaturas que dispone del mismo código de asignatura, se detiene la acción y se genera un mensaje donde se informa que ya existe una asignatura en el sistema, permaneciendo en el formulario de edición En caso de que los datos hayan sido concurrentemente manipulados por otra sesión del mismo usuario o cualquier otra casuística que evite la actualización de los datos, se mostrará un error informando y se cancelará la acción.

Id y nombre del requisito RF-ASG-002. Mantenimiento de asignaturas: búsqueda

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la búsqueda de asignaturas, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo ADMINISTRADOR o PROFESOR. El sistema provee de un formulario donde el actor podrá determinar los criterios para realizar la búsqueda y los botones para efectuar la búsqueda o cancelar la acción. No hay obligatoriedad de indicar ningún criterio para realizar la búsqueda

Page 29: Ingenieria de Software II.pdf

Ingeniería del Software II

29

29

CMMJ - Tlf: (+34) 000 000 000

El sistema le mostrará en un listado los resultados de la consulta realizada

Entradas - Identificador de sesión - Criterios adicionales.

Secuencia de operación Se comprueba que el actor puede realizar la acción de buscar asignaturas aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ADMINISTRADOR y PROFESOR Se mostrará al actor un formulario con los campos identificador único de la asignatura, código de asignatura, nombre de la asignatura y, en caso de que se trate de un usuario de tipo ADMINSITRADOR, una marca para indicar si se quieren localizar asignaturas asignadas a un profesor o sin consignar aun. En el formulario también se muestran dos botones, uno con el texto “buscar” y otro con el texto “cancelar” Si el actor pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. Si el actor pulsa el botón buscar, el sistema generará un conjunto de criterios de búsqueda con las contenido especificado por el actor en el formulario. A estos, se añadirán los criterios adicionales recibidos en la entrada y además, si el tipo de usuario del actor es PROFESOR, se añadirá un nuevo criterio para capturar únicamente las asignaturas que son de su propiedad. Si no se ha incluido ningún dato en el formulario y los filtros adicionales no disponen de contenido, se realizará una búsqueda sin más filtros que los dependientes del tipo de de usuario. Con los registros localizados, se generará un listado compuesto por el identificador único de la asignatura, el nombre, la descripción u el estado de asignación. Dicho listado se muestra al actor en el mismo formulario de búsqueda, de tal forma que este pueda seleccionar una de las asignaturas contenidas en la tabla cuyo identificador será retornado o bien cancelar la búsqueda a través del botón correspondiente.

Salidas - Identificador único de asignatura

Errores Cuando alguno de los filtros adicionales no esté definido sobre ninguno de los campos presentes en el formulario de búsqueda se generará un error informando tal circunstancia y abortando el proceso de búsqueda.

Page 30: Ingenieria de Software II.pdf

Ingeniería del Software II

30

30

CMMJ - Tlf: (+34) 000 000 000

Id y nombre del requisito RF-ASG-003. Mantenimiento de asignaturas: asignación de

profesor.

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la consignación de un profesor responsable por asignatura, si bien esta consignación solo se puede efectuar cuando el actor que está realizando la acción sea un usuario de tipo ADMINISTRADOR. Cualquier usuario del sistema que sea de tipo PROFESOR podrá ser asignado a una asignatura, sin embargo, una asignatura solo podrá tener asignado un PROFESOR. Todas las asignaturas pueden ser asignadas o reasignadas a un profesor mientras se encuentren activas. El sistema facilitará la búsqueda de la asignatura a asignar y posteriormente la del profesor que se desea consignar en la asignatura. La selección de ambos elementos implicará la asignación del profesor a la asignatura. El sistema informará al usuario del resultado de la acción.

Entradas - Identificador de sesión

Secuencia de operación Se comprueba que el actor puede realizar la acción de asignar profesores a asignaturas aplicando la funcionalidad recogida en el punto 0 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ADMINISTADOR. El sistema a continuación proporcionara un interfaz para la búsqueda de asignaturas tal y como está planteado en el requisito RF-ASG-002 El usuario marcará en el listado la asignatura que desea asignar y a continuación se le proporcionará un nuevo interfaz para la búsqueda de profesores, tal y como está planteado en el requisito RF-USU-004, aplicando un filtro adicional en la búsqueda que acote los candidatos a aquellos usuarios cuyo tipo de usuario sea PROFESOR y su estado sea AUTORIZADO. El actor podrá realizar tantas búsquedas como necesite hasta localizar al profesor que desea asignar. Si finalmente desiste y cancela la acción de búsqueda, también se cancelara la

Page 31: Ingenieria de Software II.pdf

Ingeniería del Software II

31

31

CMMJ - Tlf: (+34) 000 000 000

asignatura seleccionada y podrá comenzarse el proceso desde el principio. Cuando el actor selecciona en el listado de búsqueda de usuarios el usuario de tipo PROFESOR que desea consignar en la asignatura, el sistema le mostrará un mensaje pidiéndole confirmación sobre la acción de asignar el profesor seleccionado a la asignatura seleccionada. Si el actor no confirma la acción, el sistema volverá a facilitarle la opción de seguir buscando usuarios PROFESOR. Si el actor confirma la asignación, el sistema actualizara en el registro de la asignatura seleccionada en la tabla de asignaturas el valor del campo identificador único del profesor asignado, asignándole el identificador del usuario seleccionado por el actor del listado de búsqueda de usuarios. El sistema mostrará un mensaje confirmando la realización de la acción y volverá a facilitarle la opción de seguir buscando asignaturas para asignar. Si el usuario cancela la búsqueda de asignaturas, se cerrará el formulario y finalizará la acción.

Salidas - Mensaje - Datos creados de la asignación del profesor a la asignatura

Errores En caso de que los datos hayan sido concurrentemente manipulados por otra sesión del mismo usuario o cualquier otra casuística que evite la actualización de los datos, se mostrará un error informando y se cancelará la acción.

Id y nombre del requisito RF-ASG-004. Mantenimiento de asignaturas: matriculación

de alumno.

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la matriculación o asignación de varios alumnos a una asignatura, si bien esta solo se puede efectuar cuando el actor que está realizando la acción de asignarlos sea un usuario de tipo ADMINISTRADOR. Cualquier usuario del sistema que sea de tipo ALUMNO podrá ser asignado a una o varias asignaturas.

Page 32: Ingenieria de Software II.pdf

Ingeniería del Software II

32

32

CMMJ - Tlf: (+34) 000 000 000

Solo se podrán asignar usuarios de tipo ALUMNO cuyo estado sea AUTORIZADO. El sistema facilitará la búsqueda de la asignatura a asignar y posteriormente la del usuario al que se desea matricular en ella. La selección de ambos elementos implicará la asignación del alumno a la asignatura. El sistema informará al usuario del resultado de la acción.

Entradas - Identificador de sesión

Secuencia de operación Se comprueba que el actor puede realizar la acción de matricular alumnos en asignaturas aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuarios de tipo ADMINISTRADOR. El sistema a continuación proporcionara un interfaz para la búsqueda de asignaturas, tal y como está planteado en el requisito RF-ASG-002. El actor marcará en el listado la asignatura que desea asignar y a continuación se le proporcionará un nuevo interfaz para la búsqueda de alumnos, tal y como está planteado en el requisito RF-USU-004, aplicando un filtro adicional en la búsqueda que acote resultados a usuarios cuyo tipo de usuario sea ALUMNO y su estado sea AUTORIZADO. El actor podrá realizar tantas búsquedas como necesite para localizar el alumno que desea asignar. Si finalmente desiste y cancela la acción de búsqueda, también se cancelara la asignatura seleccionada y podrá comenzarse el proceso desde el principio. Si finalmente el actor selecciona en el listado de búsqueda de alumnos el usuario que desea asignar a la asignatura, el sistema le mostrará un mensaje pidiéndole confirmación sobre esta acción. Si el actor no confirma la acción, el sistema volverá a facilitarle la opción de seguir buscando alumnos. Si el actor confirma la asignación, el sistema buscara en la tabla matriculaciones registros que muestren la misma combinación de identificador único de alumno e identificador único de asignatura respecto a los seleccionados en los formularios de búsqueda con el fin de determinar si el alumno ya ha sido matriculado en la asignatura con anterioridad. Cuando no se localice ninguna entrada en esta tabla, se insertará un nuevo registro en la misma con ambos indicadores,

Page 33: Ingenieria de Software II.pdf

Ingeniería del Software II

33

33

CMMJ - Tlf: (+34) 000 000 000

la fecha en la que se ha realizado la asignación y un nuevo identificador único generado. El sistema mostrará un mensaje confirmando la realización de la acción y volverá a facilitarle la opción de seguir buscando asignaturas para asignar. Si el usuario cancela la búsqueda de asignaturas, se cerrará el formulario y finalizará la acción.

Salidas - Mensaje - Datos creados de la matriculación del alumno en la

asignatura

Errores Cuando ya exista una entrada en la tabla de asignaciones de alumnos a asignaturas coincidente con los identificadores de asignatura y usuario seleccionados con el actor, se mostrará un mensaje al actor informando de tal circunstancia y se cancelará la asignación retornándose al principio del proceso. En caso de que los datos hayan sido concurrentemente manipulados por otra sesión del mismo usuario o cualquier otra casuística que evite la actualización de los datos, se mostrará un error informando y se cancelará la acción.

Id y nombre del requisito RF-ASG-005. Mantenimiento de asignaturas:

desmatriculación de alumno.

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la desmatriculación o desasignación de alumnos a asignaturas, si bien esta acción solo se puede efectuar cuando el actor que está realizando la acción sea un usuario de tipo ADMINISTRADOR. El sistema facilitará la búsqueda del alumno a desasignar y posteriormente mostrará un listado de todas las asignaturas asignadas vigentes. El actor podrá entonces seleccionar qué asignatura desea desasignar y confirmar la acción. El sistema informará al usuario del resultado de la acción.

Entradas - Identificador de sesión

Secuencia de operación Se comprueba que el actor puede realizar la acción de des-matricular alumnos de asignaturas aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se

Page 34: Ingenieria de Software II.pdf

Ingeniería del Software II

34

34

CMMJ - Tlf: (+34) 000 000 000

encuentra habilitada para usuario de tipo ADMINISTRADOR. El sistema a continuación proporcionara un interfaz para la búsqueda de asignaturas tal y como está planteado en el requisito RF-ASG-002, aplicando un filtro adicional en la búsqueda que acote los resultados a usuarios cuyo tipo de usuario sea ALUMNO y su estado sea AUTORIZADO. El usuario marcará en el listado al alumno que desea desasignar y a continuación el sistema realizará una búsqueda en la tabla de matriculaciones, recopilando todos los registros que muestren coincidencia en su campo identificador único del alumno asignado con el identificador único del alumno previamente seleccionado. Con la información de matriculaciones del alumno recopilada, se accederá a la tabla con el fin de recabar la información del código de asignatura y nombre, necesarios para componer un listado que el actor pueda entender. Combinado los resultados obtenidos en las consultas realizadas, el sistema compondrá una lista donde cada entrada contendrá los siguientes datos: Identificador único del registro de matriculación, nombre del alumno, código de la asignatura y nombre de la asignatura. El listado compuesto se mostrará al actor en la pantalla de tal forma que el actor pueda marcar en él la asignatura que desea desasignar acompañado de un botón con el texto “cancelar”. Si el actor aprieta el botón cancelar, la acción se cancela y se vuelve comenzar la función desde el principio. Si por el contrario marca una asignatura, el sistema le mostrará un mensaje pidiéndole confirmación sobre esta acción. Si el actor no confirma la acción, el sistema volverá a facilitarle la opción de seguir buscando alumnos. Si el actor confirma la des-asignación, el buscará y borrará en todas las tablas que corresponde las entradas vinculadas con la asignación del usuario a la asignatura en proceso de desasignación, a saber:

- Matriculaciones - Ejecuciones de examen

El sistema mostrará un mensaje confirmando la realización de la acción y volverá a facilitarle la opción de seguir buscando asignaturas para asignar. Si el usuario cancela la búsqueda de asignaturas, se cerrará el

Page 35: Ingenieria de Software II.pdf

Ingeniería del Software II

35

35

CMMJ - Tlf: (+34) 000 000 000

formulario y finalizará la acción.

Salidas - Mensaje - Datos borrados de la matriculación del alumno en la

asignatura - Datos borrados de ejecuciones de examen del alumno en la

asignatura

Errores Cuando no exista ninguna entrada en la tabla de matriculaciones coincidente con el de usuario seleccionado por el actor, se mostrará un mensaje al actor informando de tal circunstancia y se cancelará la des-asignación retornándose al principio del proceso. En caso de que los datos hayan sido concurrentemente manipulados por otra sesión del mismo usuario o cualquier otra casuística que evite la actualización de los datos, se mostrará un error informando y se cancelará la acción.

Id y nombre del requisito RF-ASG-006. Mantenimiento de asignaturas: edición y

borrado

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la edición y borrado de asignaturas, si bien solo el usuario con rol ADMINISTRADOR podrá realizar este tipo de acciones. El sistema provee de un formulario donde el usuario podrá visualizar los campos código de asignatura y nombre de la asignatura y modificar su contenido. El formulario mostrará además tres botones, uno para borrar la asignatura, otro para modificar la asignatura con los cambios realizados sobre los datos y un tercer botón para cancelar la acción.

Entradas - Identificador de sesión - Identificador único de usuario

Secuencia de operación Se comprueba que el actor puede realizar la acción de edición y baja de asignaturas aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ADMINISTRADOR. El sistema accederá a la tabla de usuarios para localizar el usuario que responda al identificador único recibido en la

Page 36: Ingenieria de Software II.pdf

Ingeniería del Software II

36

36

CMMJ - Tlf: (+34) 000 000 000

entrada. A continuación se mostrará al actor un formulario cargado con la información del registro del usuario localizado. En este formulario figurarán el identificador único del usuario, la fecha de alta, el estado y la fecha de autorización como datos no editables, mientras que el resto, esto es, nombre, dirección electrónica y contraseña si lo serán. En el formulario también se muestran tres botones, uno con el texto “borrar”, otro con el texto “actualizar” y un tercero con el texto “cancelar” Si pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. Si pulsa el botón actualizar, el sistema comprobará que los datos rellenados por el usuario en los campos del formulario son correctos aplicando las siguientes reglas:

- Todos los datos recibidos han de tener valor. - El correo electrónico debe tener disponer de un formato

consistente con la naturaleza de este dato. - La contraseña debe tener una longitud mínima de 6

posiciones y debe incluir mayúsculas, minúsculas y números

Si los datos cumplen con estas validaciones, serán actualizados en el registro de la tabla de usuarios identificado por el identificador único del usuario recibido en la entrada y se mostrará un mensaje al actor indicándole que los cambios se han almacenado correctamente. Si pulsa el botón borrar, el sistema mostrará un cuadro de texto para que el actor confirme la acción y en caso afirmativo, el sistema buscará y borrará en todas las tablas que corresponde las entradas vinculadas con el usuario en proceso de borrado, a saber:

- Ejecuciones de exámenes - Matriculaciones - Asignaturas

Finalmente el sistema después de realizar el borrado, mostrará un mensaje informando sobre la correcta realización del proceso y se cerrará el formulario.

Salidas - Mensaje - Datos borrados de ejecuciones de examen del alumno en la

asignatura - Datos borrados de matriculaciones del alumno en la

Page 37: Ingenieria de Software II.pdf

Ingeniería del Software II

37

37

CMMJ - Tlf: (+34) 000 000 000

asignatura. - Datos borrados de la asignatura

Errores Si no se localiza la información a editar/borrar a partir del identificador único recibido, se cancelará la acción y se mostrará un mensaje indicando tal circunstancia, cerrándose el formulario. Si alguno de los datos no cumple las condiciones de validación cuando el actor ha pulsado el botón de actualizar, se detiene la acción y se genera un mensaje indicando tal circunstancia, detallando cuál o cuáles de los datos no cumple la validación, permaneciendo en el formulario de edición.

Page 38: Ingenieria de Software II.pdf

Ingeniería del Software II

38

38

CMMJ - Tlf: (+34) 000 000 000

3.2.4. Usuarios

Se incluyen en este apartado los requisitos identificados vinculados con las tareas

administrativas genéricas de la aplicación relacionadas con el mantenimiento de usuarios.

Id y nombre del requisito RF-USU-001. Auto-mantenimiento de datos

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la modificación por parte del propio usuario de la dirección de correo y contraseña. El sistema provee de un formulario donde el actor podrá ver el contenido actual de ambos datos y modificarlo. Este formulario contiene a su vez dos botones, uno para confirmar la acción y otro para cancelarla. El sistema informará al usuario del resultado de la acción.

Entradas - Identificador de sesión

Secuencia de operación Se comprueba que el actor puede realizar la acción de mantener datos de usuario aplicando la funcionalidad recogida en el punto RF-SEG-005 Con el identificador único de usuario recuperado de la sesión, se accederá a la tabla de usuarios para recuperar los datos correspondientes al nombre, correo electrónico y contraseña. Los datos recuperados serán mostrados al usuario en una vista de edición donde el actor podrá manipularlos todos excepto el nombre. En dicha pantalla se mostrarán dos botones, uno para cancelar los cambios y otro para aplicarlos. Cuando el actor pulsa el botón de aplicar, el sistema comprobará que los nuevos valores proporcionados sean validos aplicando las siguientes reglas:

- Todos los datos recibidos han de tener valor. - El correo electrónico debe tener disponer de un formato

consistente con la naturaleza de este dato. - La contraseña debe tener una longitud mínima de 6

posiciones y debe incluir mayúsculas, minúsculas y números

Page 39: Ingenieria de Software II.pdf

Ingeniería del Software II

39

39

CMMJ - Tlf: (+34) 000 000 000

Se realizará una búsqueda en la tabla de usuarios del correo electrónico indicado por el usuario con el fin de confirmar que no existe otro usuario en el sistema con esa misma dirección de correo. Si los datos cumplen con estas validaciones, serán actualizados en el registro de la tabla de usuarios identificado por el identificador único de usuario que está en la sesión y se mostrará un mensaje al usuario indicándole que los cambios se han almacenado correctamente. Si por el contrario el actor pulsa el botón cancelar, se descartarán los cambios que se hayan podido realizar hasta ese momento y se mostrará un mensaje indicando que la acción ha sido cancelada.

Salidas - Mensaje - Datos modificados de usuario

Errores En caso de que no se localice el registro de usuario en base al identificador único almacenado en la sesión, se cancelará la acción y se generará un mensaje de error indicando que no es posible realizarla. En caso de que los datos nuevos datos suministrados por el actor no cumplan las validaciones formales descritas, se mostrará un mensaje informando de qué dato está incorrectamente formado, permaneciendo en el formulario de edición. Si se localiza algún usuario ya registrado en el sistema que tenga la misma dirección de correo electrónico que el usuario en edición y no sea el usuario en edición, detiene la acción y se genera un mensaje indicando tal circunstancia, permaneciendo en el formulario de edición. En caso de que los datos hayan sido concurrentemente manipulados por otra sesión del mismo usuario o cualquier otra casuística que evite la actualización de los datos, se mostrará un error informando y se cancelará la acción.

Id y nombre del requisito RF-USU-002. Mantenimiento de usuarios: alta

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Page 40: Ingenieria de Software II.pdf

Ingeniería del Software II

40

40

CMMJ - Tlf: (+34) 000 000 000

Especificación El sistema permite la creación de usuarios nuevos, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo ADMINISTRADOR. Adicionalmente, la creación de un nuevo usuario deberá contar con la autorización de un usuario de tipo PROFESOR. El sistema provee de un formulario donde el actor rellena los campos nombre, dirección de correo electrónico, contraseña y tipo de usuario del nuevo usuario a crear, así como el correo electrónico del usuario PROFESOR que debe autorizar la creación del nuevo usuario. Este formulario contiene a su vez dos botones, uno para confirmar la acción y otro para cancelarla. El sistema informará al usuario del resultado de la acción.

Entradas - Identificador de sesión

Secuencia de operación Se comprueba que el actor puede realizar la acción de crear usuarios aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ADMINISTADOR. Se mostrará al actor un formulario con los campos nombre, dirección electrónica, contraseña, tipo de usuario y dirección de correo electrónico del profesar autorizador. En el formulario también se muestran dos botones, uno con el texto “crear” y otro con el texto “cancelar” Si el actor pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. Si el actor pulsa el botón crear, el sistema comprobará que los datos incluidos en los campos del formulario son correctos aplicando las siguientes reglas:

- Todos los datos recibidos han de tener valor. - El nombre del usuario debe tener estar compuesto de al

menos dos palabras de más de una letra cada una de ellas.

- El correo electrónico del nuevo usuario debe disponer de un formato consistente con la naturaleza de este dato.

- La contraseña del nuevo usuario debe tener una longitud mínima de 6 posiciones y debe incluir mayúsculas, minúsculas y números

- El correo electrónico del PROFESOR autorizador debe disponer de un formato consistente con la naturaleza de este dato.

Page 41: Ingenieria de Software II.pdf

Ingeniería del Software II

41

41

CMMJ - Tlf: (+34) 000 000 000

Se realizará una búsqueda en la tabla de usuarios del correo electrónico indicado para el nuevo usuario con el fin de confirmar que no existe un usuario en el sistema con esa misma dirección de correo. Se realizará una búsqueda en la tabla de usuarios del correo electrónico indicado para el usuario autorizador, se recupera el identificador único del mismo y se confirma que el tipo del usuario localizado es PROFESOR Se genera y envía un correo electrónico al usuario autorizador informándole de que hay usuarios en trámite de creación que requieren su aprobación. Se crea un nuevo registro en la tabla de usuarios incluyendo un identificador único de usuario generado, su nombre, dirección de correo electrónico, contraseña, fecha de alta, tipo de usuario y el identificador único del usuario PROFESOR autorizador y se le asigna el valor PENDIENTE DE AUTORIZAR en el campo de estado del usuario

Salidas - Mensaje - Datos de nuevo usuario creado. - Correo electrónico al profesor responsable de la

autorización del alta del alumno.

Errores Si alguno de los datos no cumple las condiciones de validación, se detiene la acción y se genera un mensaje indicando tal circunstancia, detallando cuál o cuáles de los datos no cumple la validación, permaneciendo en el formulario de edición. Si se localiza algún usuario ya registrado en el sistema que tenga la misma dirección de correo electrónico que el usuario en creación, detiene la acción y se genera un mensaje indicando tal circunstancia, permaneciendo en el formulario de edición. Si no se localiza ningún usuario a partir del correo electrónico facilitado del usuario autorizador o el usuario localizado no es de tipo PROFESOR, se detiene la acción y se genera un mensaje indicando tal circunstancia, permaneciendo en el formulario de edición. Si el envío del correo electrónico al usuario autorizador falla por cualquier causa, se detiene la acción y se genera un mensaje informando sobre este circunstancia y detallando en la medida de lo posible el motivo por el cual el envío del correo al usuario autorizador ha fallado. En caso de que los datos hayan sido concurrentemente manipulados por otra sesión del mismo usuario o cualquier otra casuística que evite la actualización de los datos, se mostrará

Page 42: Ingenieria de Software II.pdf

Ingeniería del Software II

42

42

CMMJ - Tlf: (+34) 000 000 000

un error informando y se cancelará la acción

Id y nombre del requisito RF-USU-003. Mantenimiento de usuarios: autorización de

altas.

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la autorización de altas de usuarios, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo PROFESOR. Un usuario PROFESOR solo podrá autorizar las altas de los usuarios que lo referencien como usuario autorizador. El sistema provee de un formulario donde se muestra un listado con los usuarios pendientes de autorizar vinculados al actor, donde este podrá autorizar aquellos que desee mediante un botón vinculado a cada usuario de la lista. El sistema informará al usuario del resultado de la acción.

Entradas - Identificador de sesión

Secuencia de operación Se comprueba que el actor puede realizar la acción de autorizar altas de usuario aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo PROFESOR. Se accede a la tabla de usuarios y se genera un listado con los datos de identificador único, nombre, correo electrónico, tipo de usuario y fecha de alta de los registros que reflejen en el campo estado el valor “PENDIENTE DE AUTORIZAR” y en el campo identificador único del usuario autorizador el mismo valor que el identificador único del actor presente en la sesión. Si el listado generado no tiene entradas, se le mostrara un mensaje al actor indicándole que no tiene usuarios pendientes de autorizar y se cerrara el formulario. Este listado se muestra al actor incluyéndose en cada línea un botón con el texto “autorizar”. Si el actor puede pulsar el botón de una entrada del listado concreta, el sistema recuperara el identificador único de ese usuario y procederá a localizar el registro en la tabla de usuarios para a continuación actualizar el valor del campo estado a “AUTORIZADO” y asignar una marca de tiempo del momento de

Page 43: Ingenieria de Software II.pdf

Ingeniería del Software II

43

43

CMMJ - Tlf: (+34) 000 000 000

la acción en el campo fecha de autorización. Tras la correcta actualización de la información, el sistema mostrará al usuario un mensaje informándole del resultado positivo de la autorización y le preguntará si desea autorizar a más usuarios. Si el usuario confirma indica que si, el sistema volverá nuevamente al inicio del procesamiento descrito en este requisito. En caso contrario, se cerrará el formulario.

Salidas - Mensaje - Datos de usuario modificado.

Errores En caso de que los datos hayan sido concurrentemente manipulados por otra sesión del mismo usuario o cualquier otra casuística que evite la actualización de los datos, se mostrará un error informando y se cancelará la acción

Id y nombre del requisito RF-USU-004. Mantenimiento de usuarios: búsqueda

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la consulta de usuarios, si bien solo el usuario de tipo ADMINISTRADOR podrá realizar este tipo de acciones. El sistema provee de un formulario donde el actor podrá rellenar los campos identificador único, nombre, dirección de correo electrónico, tipo de usuario y estado de usuario así como dos botones, uno para confirmar la consulta y otro para cancelarla. El sistema le mostrará en un listado los resultados de la consulta realizada

Entradas - Identificador de sesión - Filtros adicionales.

Secuencia de operación Se comprueba que el actor puede realizar la acción de consultar usuarios aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ADMINISTRADOR. Se muestra al actor un formulario con los campos identificador único, nombre, dirección de correo electrónico y tipo de usuario. En el formulario también se muestran dos botones, uno con el texto “buscar” y otro con el texto “cancelar”

Page 44: Ingenieria de Software II.pdf

Ingeniería del Software II

44

44

CMMJ - Tlf: (+34) 000 000 000

Si el actor pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. Si el actor pulsa el botón buscar, el sistema realiza una búsqueda en la tabla de usuarios con los datos proporcionados en el formulario a los que añadirá los filtros adicionales recibidos en la entrada. Si no se ha incluido ningún dato en el formulario y los filtros adicionales no disponen de contenido, se realizará una búsqueda sin filtros. Con los registros localizados, se generará un listado compuesto por el identificador único del usuario, el nombre, su dirección de correo electrónico, su tipo, su fecha de alta, su fecha de autorización y su estado ordenado por nombre (a-z). Dicho listado se muestra al actor en el mismo formulario de búsqueda, de tal forma que se pueda seleccionar uno de los usuarios contenidos en la tabla cuyo identificador será retornado, o bien cancelar la búsqueda a través del botón correspondiente.

Salidas - Datos del usuario seleccionado.

Errores Cuando alguno de los filtros adicionales no esté definido sobre ninguno de los campos presentes en el formulario de búsqueda se generará un error informando tal circunstancia y abortando el proceso de búsqueda.

Id y nombre del requisito RF-USU-005. Mantenimiento de usuarios: edición y borrado

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la edición y borrado usuarios, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo ADMINSITRADOR El sistema provee de un formulario donde el usuario podrá visualizar los campos código de asignatura, nombre y año académico de una asignatura y modificar su contenido. El formulario mostrará además tres botones, uno para borrar la asignatura, otro para modificar la asignatura con los cambios realizados sobre los datos y un tercer botón para cancelar la acción.

Entradas - Identificador de sesión - Identificador único de usuario

Page 45: Ingenieria de Software II.pdf

Ingeniería del Software II

45

45

CMMJ - Tlf: (+34) 000 000 000

Secuencia de operación Se comprueba que el actor puede realizar la acción de edición y borrado de usuarios aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ADMINISTRADOR. El sistema accederá a la tabla de usuarios para localizar el usuario que responda al identificador único recibido en la entrada. A continuación se mostrará al actor un formulario cargado con la información del registro del usuario localizado. En este formulario figurarán el identificador único del usuario, la fecha de alta, el estado y la fecha de autorización como datos no editables, mientras que el resto, esto es, nombre, dirección electrónica y contraseña si lo serán. En el formulario también se muestran tres botones, uno con el texto “borrar”, otro con el texto “actualizar” y un tercero con el texto “cancelar” Si pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. Si pulsa el botón actualizar, el sistema comprobará que los datos rellenados por el usuario en los campos del formulario son correctos aplicando las siguientes reglas:

- Todos los datos recibidos han de tener valor. - El correo electrónico debe tener disponer de un formato

consistente con la naturaleza de este dato. - La contraseña debe tener una longitud mínima de 6

posiciones y debe incluir mayúsculas, minúsculas y números

Se realizará una búsqueda en la tabla de usuarios del correo electrónico indicado por el usuario con el fin de confirmar que no existe otro usuario en el sistema con esa misma dirección de correo. Si los datos cumplen con estas validaciones, serán almacenados en el registro de la tabla de usuarios identificado por el identificador único del usuario recibido en la entrada y se mostrará un mensaje al actor indicándole que los cambios se han almacenado correctamente. Si pulsa el botón borrar, el sistema mostrará un cuadro de texto para que el actor confirme la acción y en caso afirmativo, el sistema buscará y borrará en todas las tablas que corresponde las entradas vinculadas con el usuario en proceso de borrado, a saber:

Page 46: Ingenieria de Software II.pdf

Ingeniería del Software II

46

46

CMMJ - Tlf: (+34) 000 000 000

- Asignaciones de alumnos a asignaturas - Ejecuciones de exámenes - Asignaturas (no se borrara, solo se deshará la relación

con el usuario PROFESOR si procede) - Usuarios.

Finalmente el sistema después de realizar el borrado, mostrará un mensaje informando sobre la correcta realización del proceso y se cerrará el formulario.

Salidas - Mensaje - Datos del usuario actualizado o borrado

Errores Si no se localiza la información a editar/borrar a partir del identificador único recibido, se cancelará la acción y se mostrará un mensaje indicando tal circunstancia, cerrándose el formulario. Si alguno de los datos no cumple las condiciones de validación cuando el usuario haya optado por el botón “actualizar”, se detiene la acción y se genera un mensaje indicando tal circunstancia, detallando cuál o cuáles de los datos no cumple la validación, permaneciendo en el formulario de edición. Si el actor ha pulsado el botón actualizar y se localiza algún usuario ya registrado en el sistema que tenga la misma dirección de correo electrónico que el usuario en edición y no sea el usuario en edición, detiene la acción y se genera un mensaje indicando tal circunstancia, permaneciendo en el formulario de edición.

Page 47: Ingenieria de Software II.pdf

Ingeniería del Software II

47

47

CMMJ - Tlf: (+34) 000 000 000

3.2.5. Preguntas

Se incluyen en este apartado los requisitos identificados vinculados con las tareas genéricas

de la aplicación relacionadas con el mantenimiento de preguntas del profesor.

Id y nombre del requisito RF-PRG-001. Mantenimiento de preguntas de examen: alta

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la creación de preguntas de examen nuevas, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo PROFESOR. El sistema provee de un formulario donde el actor podrá rellenar los campos: - Tipo de pregunta - Texto de la pregunta - Código de asignatura - Categoría de la pregunta Los campos tipo de pregunta y texto son obligatorios. Respecto a los otros, se deberá indicar valor para al menos uno de los dos. Si el tipo de pregunta indicado es de tipo test el formulario adaptará su aspecto para que el actor añada la respuesta correcta y además de esta un mínimo de una y un máximo de 4 respuestas adicionales incorrectas. El código de asignatura indicado deberá corresponderse con un código de asignatura que el usuario PROFESOR tenga asignada. El formulario proporcionará un botón para ayudar a buscar las asignaturas. La categoría de la indicado deberá corresponderse con un categoría propiedad del usuario PROFESOR tenga asignada. El formulario proporcionará un botón para ayudar a buscar las categorías. Este formulario contiene a además otros dos botones, uno para confirmar la acción y otro para cancelarla. El sistema informará al usuario del resultado de la acción.

Page 48: Ingenieria de Software II.pdf

Ingeniería del Software II

48

48

CMMJ - Tlf: (+34) 000 000 000

Entradas - Identificador de sesión

Secuencia de operación Se comprueba que el actor puede realizar la acción de crear preguntas aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo PROFESOR. Se mostrará al actor un formulario con los campos tipo de pregunta, donde podrá escoger entre los valores TEST y DESARROLLO, texto de la pregunta, código de la asignatura acompañado de un botón buscar y categoría de la asignatura, acompañado también de un botón buscar. En el formulario también se muestran otros dos botones, uno con el texto “crear” y otro con el texto “cancelar” Si el actor pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. El botón buscar vinculado a la asignatura facilitará una función de búsqueda de asignaturas idéntica a la descrita en el requisito RF-ASG-002. Se mostrarán en el campo del formulario código de asignatura el dato correspondiente de la asignatura seleccionada. El botón buscar vinculado a la categoría facilitará una función de búsqueda de categorías idéntica a la descrita en el requisito RF-CAT-002. Se mostrarán en el campo del formulario categoría el dato correspondiente de la categoría seleccionada. Si el actor pulsa el botón crear, el sistema comprobará que los datos incluidos en los campos del formulario son correctos aplicando las siguientes reglas:

- El campo tipo de pregunta contiene uno de estos posibles valores: TEST o DESARROLLO

- El campo texto de la pregunta contiene un valor alfanumérico con una longitudes mínima y máxima de 10 y 255 posiciones respectivamente.

- Se deberá haber proporcionado obligatoriamente el código de asignatura o la referencia, pudiéndose proporcionar los dos.

- El campo código de asignatura, si se proporciona, deberá contener un valor que tenga correspondencia con alguna de las asignaturas asignadas al profesor.

- El campo categoría, si se proporciona, deberá contener un valor que tenga correspondencia con alguna de las categorías propiedad del profesor.

Si el tipo de pregunta indicado es TEST, adicionalmente se aplicarán las siguientes reglas de validación sobre el contenido del formulario:

Page 49: Ingenieria de Software II.pdf

Ingeniería del Software II

49

49

CMMJ - Tlf: (+34) 000 000 000

- El campo respuesta correcta contiene un valor alfanumérico con una longitudes mínima y máxima de 10 y 255 posiciones respectivamente

- El campo respuesta incorrecta 1 contiene un valor alfanumérico con una longitudes mínima y máxima de 10 y 255 posiciones respectivamente.

- El campo respuesta incorrecta 2, si contiene valor, deberá ser un valor alfanumérico con una longitudes mínima y máxima de 10 y 255 posiciones respectivamente.

- El campo respuesta incorrecta 3, si contiene valor, deberá ser un alfanumérico con una longitudes mínima y máxima de 10 y 255 posiciones respectivamente.

- El campo respuesta incorrecta 4, si contiene valor, deberá ser un alfanumérico con una longitudes mínima y máxima de 10 y 255 posiciones respectivamente.

El sistema generará un registro en la tabla de pregunta incluyendo:

- Un identificador único de la pregunta generado - El identificador único del perfil del usuario de tipo

PROFESOR que está creando la pregunta. - La fecha en la que se está creando la pregunta. - El estado de la pregunta con el valor ACTIVA. - El código de asignatura de la pregunta, si se ha indicado - La categoría de la pregunta, si se ha indicado. - El tipo de la pregunta - El texto de la pregunta - El texto de la respuesta correcta si la pregunta es de tipo

test. - El texto de la respuesta errónea 1 si la pregunta es de

tipo test - El texto del resto de las respuestas erróneas si la

pregunta es de tipo testa y han sido indicados en los campos correspondientes.

Finalmente, se mostrará un mensaje al actor informándole del la correcta finalización de la acción y preguntándole sobre si quiere crear otra pregunta. Si responde que si, el sistema vaciará el formulario y comenzara nuevamente el proceso. En caso negativo, el formulario se cerrara.

Salidas - Mensaje - Datos de la nueva pregunta creada.

Errores Si alguno de los datos suministrador para la creación de la nueva pregunta no cumple las condiciones de validación, se aborta la acción y se genera un mensaje indicando tal circunstancia, detallando cuál o cuáles de los datos no cumple la validación.

Page 50: Ingenieria de Software II.pdf

Ingeniería del Software II

50

50

CMMJ - Tlf: (+34) 000 000 000

En caso de cualquier otra casuística que evite la actualización de los datos, se mostrará un error informando y se cancelará la acción

Id y nombre del requisito RF-PRG-002. Mantenimiento de preguntas de examen:

búsqueda

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la búsqueda de preguntas de examen, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo PROFESOR o ADMINISTRADOR. El sistema provee de un formulario donde el actor podrá determinar los criterios para realizar la búsqueda y los botones para efectuar la búsqueda o cancelar la acción. No hay obligatoriedad de indicar ningún criterio para realizar la búsqueda El sistema le mostrará en un listado los resultados de la consulta realizada

Entradas - Identificador de sesión - Criterios adicionales.

Secuencia de operación Se comprueba que el actor puede realizar la acción de buscar preguntas aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ADMINISTRADOR y PROFESOR. Se mostrará al actor un formulario con los campos identificador único de la pregunta, tipo de pregunta, estado de la pregunta, código de asignatura de la pregunta y categoría de la pregunta. En el formulario también se muestran dos botones, uno con el texto “buscar” y otro con el texto “cancelar” Los campos categoría y asignatura se mostrarán el mismo comportamiento que el detallado en el RF-PRG-001, con la diferencia de que la acotación por usuario en la búsqueda de elementos solo se realizará cuando este sea de tipo PROFESOR, dado que un usuario de tipo ADMINISTRADOR tiene acceso a todas las asignaturas. Si el actor pulsa el botón cancelar, el sistema cancela la acción

Page 51: Ingenieria de Software II.pdf

Ingeniería del Software II

51

51

CMMJ - Tlf: (+34) 000 000 000

y se cierra el formulario. Si el actor pulsa el botón buscar, el sistema realiza una búsqueda en la tabla de preguntas con los datos proporcionados en el formulario a los que añadirá los filtros adicionales recibidos en la entrada. Cuando el tipo de usuario del actor sea PROFESOR, se incluirá un filtro adicional con el identificador único del usuario del actor. Si no se ha incluido ningún dato en el formulario y los filtros adicionales no disponen de contenido, se realizará una búsqueda sin más filtros que el que haya podido añadirse a raíz de la tipología del usuario. Con los registros localizados, se generará un listado compuesto por el identificador único de la pregunta, el propietario, el tipo de la pregunta, la asignatura de la pregunta, la categoría de la pregunta y el texto de la pregunta, ordenado ascendentemente por todos los campos retornados. Dicho listado se muestra al actor en el mismo formulario de búsqueda, pudiendo ordenarlo por cualquiera de los campos que compone el listado. El actor podrá seleccionar una de las preguntas contenidas en el listado cuyo identificador será retornado o bien cancelar la búsqueda a través del botón correspondiente.

Salidas - Datos de la pregunta seleccionada

Errores N/A

Id y nombre del requisito RF-PRG-003. Mantenimiento de preguntas de examen:

edición y borrado

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la edición y borrado de peguntas de examen, si bien solo los usuarios con de tipo ADMINISTRADOR o PROFESOR podrán realizar este tipo de acciones. El sistema provee de un formulario donde el actor podrá visualizar y modificar los campos que constituyen el registro de la pregunta, excepto el identificador único. Al igual que el alta, el formulario mostrara un botones de

Page 52: Ingenieria de Software II.pdf

Ingeniería del Software II

52

52

CMMJ - Tlf: (+34) 000 000 000

búsqueda con el texto buscar al lado de los campos categoría y código de asignatura. El formulario mostrará además tres botones, uno para borrar la pregunta, otro para modificar la pregunta con los cambios realizados sobre los campos del formulario y un tercer botón para cancelar la acción. Cuando una pregunta haya sido empleada en un examen, la solicitud de borrado no se hará efectiva sino que el sistema realizará un borrado lógico asignando al campo estado de la pregunta el valor INACTIVA. El actor podrá también actualizar este campo si lo considera oportuno, para eliminarla lógicamente o reactivarla.

Entradas - Identificador de sesión - Identificador único de pregunta

Secuencia de operación Se comprueba que el actor puede realizar la acción de edición y baja de preguntas aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuarios de tipo ADMINISTRADOR o PROFESOR El sistema accederá a la tabla de preguntas para localizar la pregunta que responda al identificador único recibido en la entrada. A continuación se mostrará al actor un formulario cargado con la información del registro de pregunta localizado, donde solo el campo identificador único de la pregunta e identificador único del profesor nos serán editables. El resto de campos mostrados si lo serán y son:

- Tipo de pregunta - Estado de la pregunta - Texto de la pregunta - Código de asignatura - Categoría de la pregunta.

Solo cuando valor del campo tipo de pregunta sea TEST, el formulario también mostrará los siguientes campos :

- Respuesta correcta - Respuesta incorrecta 1 - Respuesta incorrecta 2 - Respuesta incorrecta 3 - Respuesta incorrecta 4

Si el actor modificar el contenido del campo tipo de pregunta, el formulario mostrara u ocultara los campos de respuesta convenientemente.

Page 53: Ingenieria de Software II.pdf

Ingeniería del Software II

53

53

CMMJ - Tlf: (+34) 000 000 000

Al igual que el alta y la búsqueda, los campos código de asignatura y categoría de asignatura irán acompañados de un botón buscar para facilitar la localización de valores para estos campos y cuyo comportamiento ha quedado ampliamente explicado en el RF-PRG-002 Si pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. Si pulsa el botón actualizar, el sistema comprobará que los datos rellenados por el usuario en los campos del formulario son correctos aplicando las siguientes reglas:

- El campo tipo de pregunta contiene uno de estos posibles valores: TEST o DESARROLLO

- El campo estado de la pregunta contiene uno de estos posibles valores: ACTIVA o INACTIVA

- El campo texto de la pregunta contiene un valor alfanumérico con una longitudes mínima y máxima de 10 y 255 posiciones respectivamente.

- El campo código de asignatura, si se proporciona, deberá contener un valor que tenga correspondencia con alguna de las asignaturas asignadas al profesor propietario de la pregunta.

- El campo categoría, si se proporciona, deberá contener un valor que tenga correspondencia con alguna de las categorías propiedad del profesor propietario de la pregunta.

Si el tipo de pregunta indicado es TEST, adicionalmente se aplicarán las siguientes reglas de validación sobre el contenido del formulario:

- El campo respuesta correcta contiene un valor alfanumérico con una longitudes mínima y máxima de 10 y 255 posiciones respectivamente

- El campo respuesta incorrecta 1 contiene un valor alfanumérico con una longitudes mínima y máxima de 10 y 255 posiciones respectivamente.

- El campo respuesta incorrecta 2, si contiene valor, deberá ser un valor alfanumérico con una longitudes mínima y máxima de 10 y 255 posiciones respectivamente.

- El campo respuesta incorrecta 3, si contiene valor, deberá ser un alfanumérico con una longitudes mínima y máxima de 10 y 255 posiciones respectivamente.

- El campo respuesta incorrecta 4, si contiene valor, deberá ser un alfanumérico con una longitudes mínima y máxima de 10 y 255 posiciones respectivamente.

Page 54: Ingenieria de Software II.pdf

Ingeniería del Software II

54

54

CMMJ - Tlf: (+34) 000 000 000

Si los datos cumplen con estas validaciones, serán almacenados en el registro de la tabla de preguntas identificado por el identificador único del usuario recibido en la entrada y se mostrará un mensaje al actor indicándole que los cambios se han almacenado correctamente. Si pulsa el botón borrar, el sistema mostrará un cuadro de texto para que el actor confirme la acción y en caso afirmativo, el sistema buscará en la tabla de preguntas por examen todas las posibles referencia a la pregunta en proceso de borrado mediante el identificador único de la pregunta. Si se localiza alguna referencia, el sistema asignará automáticamente al campo estado de la pregunta el valor INACTIVA. En caso contrario, el sistema eliminará de todas las tablas que corresponde las entradas vinculadas con la pregunta en proceso de borrado, a saber:

- Preguntas por examen - Preguntas

Finalmente el sistema después de realizar el borrado, mostrará un mensaje informando sobre la correcta realización del proceso, detallando si el borrado realizado ha sido físico o lógico, y se cerrará el formulario.

Salidas - Mensaje - Datos de la pregunta actualizada

ó - Datos de la pregunta por examen borrada - Datos de la pregunta borrada

Errores Si no se localiza la información a editar/borrar a partir del identificador único recibido, se cancelará la acción y se mostrará un mensaje indicando tal circunstancia, cerrándose el formulario. Si alguno de los datos no cumple las condiciones de validación cuando el usuario haya optado por el botón “actualizar”, se aborta la acción y se genera un mensaje indicando tal circunstancia, detallando cuál o cuáles de los datos no cumple la validación, pero no se cierra el formulario.

Page 55: Ingenieria de Software II.pdf

Ingeniería del Software II

55

55

CMMJ - Tlf: (+34) 000 000 000

3.2.6. Modelos de examen

Se incluyen en este apartado los requisitos identificados vinculados con las tareas genéricas

de la aplicación relacionadas con el mantenimiento de preguntas del profesor.

Id y nombre del requisito RF-EXA-001. Mantenimiento de modelos de examen: alta

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la creación de modelos de examen, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo PROFESOR. El modelo de examen es un elemento genérico, utilizable posteriormente para generar exámenes de distintas asignaturas. El sistema propondrá al actor una serie de preguntas sucesivas para determinar las características fundamentales del examen a crear, a saber:

- Nombre del examen - Tipo de modelo de examen - Ámbito de las preguntas a incluir. - Número de preguntas - Puntuación por defecto de las preguntas - Criterios de penalización en corrección, si procede. - Duración del examen.

Tras contestar a las cuestiones planteadas, el sistema seleccionará automáticamente y de forma aleatoria las preguntas del examen de forma consistente a los criterios definidos por el actor. La selección no tendrá preguntas repetidas, si bien, las preguntas podrán haber sido utilizadas o no en otros exámenes. El proceso finalizará notificando por correo electrónico a los alumnos que deben realizar el examen de su creación y mostrando al actor un mensaje informando sobre la correcta composición del examen.

Entradas - Identificador de sesión

Secuencia de operación Se comprueba que el actor puede realizar la acción de crear modelos de examen aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo PROFESOR.

Page 56: Ingenieria de Software II.pdf

Ingeniería del Software II

56

56

CMMJ - Tlf: (+34) 000 000 000

Para crear el examen, el sistema mostrar un formulario donde comenzará a realizar una serie de preguntas de forma secuencial, de tal modo que el usuario irá avanzando en el cuestionario según vaya contestando preguntas. En cada pregunta, el sistema mostrará tres botones, anterior, siguiente y cancelar. Si el actor pulsa el botón cancelar se aborta la acción y se cierra el formulario. Si el actor pulsa el botón anterior se mostrará la pregunta anterior junto con la respuesta a esta facilitada por el actor, posibilitando su modificación. Si se retrocede hasta la primera pregunta del cuestionario el sistema no permitirá retroceder más. Sea como fuere, cuando se pulsa el botón anterior la respuesta dada a la pregunta actual se conservará mostrándose cuando el usuario vuelva a pasar por esta pregunta. Si el actor pulsa el botón siguiente, el sistema realizará la validación que corresponda sobre la respuesta dada por el actor a la cuestión planteada, pasando a la siguiente pregunta del formulario cuando la respuesta sea considerada válida. En caso de que no se valide la pregunta, se mostrará un mensaje indicativo del motivo por el cual no se acepta la respuesta proporcionada y no será posible avanzar a la siguiente cuestión. El sistema no mostrará la siguiente pregunta si la respuesta de la pregunta anterior no cumple los criterios de validación lógica establecidos. El usuario podrá retroceder en cualquier momento a la pregunta La secuencia de preguntas es la siguiente:

- ¿Qué nombre desea otorgar al modelo de examen?

Esta pregunta es de respuesta obligatoria y no podrá existir en el sistema otro modelo de examen con el mismo nombre propiedad del actor que está creando el examen. Admite un valor alfanumérico de hasta 100 posiciones.

- ¿Qué tipo de examen quiere crear?,

El sistema dará dos opciones de selección excluyentes entre sí, de las que el usuario deberá seleccionar obligatoriamente una de ellas. Las opciones disponibles son TEST y DESARROLLO.

- ¿A qué asignaturas desea acotar las preguntas del

examen?

Page 57: Ingenieria de Software II.pdf

Ingeniería del Software II

57

57

CMMJ - Tlf: (+34) 000 000 000

La respuesta a esta pregunta es opcional, pero si se indica una respuesta, su contenido deberá tenga correspondencia con las asignaturas asignadas al profesor que creando el modelo de examen. Se podrán indicar varias asignaturas. Esta respuesta también permitirá establecer que solo se desean incluir preguntas que no se encuentren vinculadas a asignaturas Junto a la pregunta se mostrará un botón que facilitará una función de búsqueda de asignaturas idéntica a la descrita en el requisito RF-ASG-002 para que el actor pueda localizar las asignaturas que necesite. Las asignaturas que vaya seleccionando irán constituyendo la respuesta a la pregunta en el formulario, pudiendo también eliminar asignaturas ya presentes en la respuesta.

- ¿A qué categoría desea acotar las preguntas del examen? La respuesta a esta pregunta es opcional, pero si se indica una respuesta, su contenido deberá tenga correspondencia con las categorías propiedad del profesor que está creando el modelo de examen. Se podrán indicar varias categorías. Junto a la pregunta se mostrará un botón que facilitará una función de búsqueda de categorías idéntica a la descrita en el requisito RF-CAT-002 para que el actor pueda localizar las categorías que necesite. Las categorías que vaya seleccionando irán constituyendo la respuesta a la pregunta en el formulario, pudiendo también eliminar categorías ya presentes en la respuesta. La respuesta a esta pregunta se convertirá en obligatoria si el usuario no ha contestado la pregunta anterior relativa a la acotación por asignaturas.

- ¿Cuántas preguntas va a tener el examen? De respuesta obligatoria, la respuesta deberá ser numérica. El sistema comprobará además que el número de preguntas indicado es menor o igual al número de preguntas activas disponibles vinculadas al profesor cumplen las características de tipología, asignatura y, si

Page 58: Ingenieria de Software II.pdf

Ingeniería del Software II

58

58

CMMJ - Tlf: (+34) 000 000 000

se ha incluido, la categoría indicadas por el actor anteriormente.

- ¿En cuánto tiempo se otorga para la realización del examen por parte de los alumnos? De respuesta obligatoria, la respuesta deberá ser numérica mayor que cero y servirá para establecer el tiempo en minutos que el usuario puede tardar en realizar el examen.

- ¿Qué puntuación desea asignar a cada pregunta por defecto? De respuesta obligatoria, la respuesta deberá ser numérica mayor a 0.

- Si el tipo de examen indicado es TEST, junto a esta pregunta se le requerirá que especifique los criterios de penalización a aplicar, permitiéndole seleccionar de forma no excluyente entre las siguientes opciones: Restar en bloque: 3 preguntas erróneas restan una

pregunta correcta.

Restar en blanco: cada pregunta no contestada resta X puntos, debiendo el actor explicitar si marca esta opción cuántos puntos resta. El valor deberá ser numérico mayor o igual a 0.

Una vez que el actor ha contestado todas las preguntas, el sistema realizará una selección automática aleatoria de tantas preguntas como se haya indicado por el actor en el cuestionario. El conjunto seleccionado estará constituido por preguntas ACTIVAS propiedad del actor y no podrá tener entradas repetidas, si bien, sí podrán emplearse preguntas que ya hayan sido empleadas en otro examen. Las preguntas seleccionadas serán consistentes en cuanto tipo y también en cuanto a asignaturas y/o categorías, en función de las respuestas consignadas por el actor a estas cuestiones. Tras la selección, el sistema comenzará a mostrarlas de una en una en pantalla para que el actor mediante un botón la confirme o rechace como parte del modelo de examen. Además, también mostrará un botón para cancelar la creación del modelo de examen y un cuarto botón con la opción confirmar todas, que posibilitará que el actor pueda aceptar todas las preguntas de una sola vez sin tener que revisarlas una a una y pasando directamente a la fase de confirmar la creación del examen que veremos más adelante.

Page 59: Ingenieria de Software II.pdf

Ingeniería del Software II

59

59

CMMJ - Tlf: (+34) 000 000 000

Durante la revisión individual de las preguntas se permite a su vez la redefinición de su valoración y, si el examen es de tipo test, sus criterios de penalización. La redefinición de estos criterios es opcional, conservando la valoración por defecto y los criterios de penalización consignados por el actor en el cuestionario si este no realiza ningún cambio. La redefinición de la valoración posibilitará que el actor establezca un valor a la pregunta distinto del valor por defecto. Si se redefine, el nuevo valor asignado deberá cumplir las mismas validaciones que el valor por defecto. La redefinición de los criterios de penalización solo se podrá realizar sobre los criterios de penalización indicados en el cuestionario por el actor.

- Si se ha activado la opción de restar en bloque, se podrá redefinir el número de preguntas falladas a las que equivale un fallo en la pregunta. Así, se podrá establecer por ejemplo que cuando se falle una pregunta considerada relevante, compute como dos preguntas falladas o al revés, para preguntas poco relevantes, reducir su valor de equivalencia. Sea como fuere, la nueva equivalencia deberá ser un número entero o decimal mayor o igual a 0.

- Si se ha activado la opción de restar en blanco, se podrá modificar el valor a restar para la pregunta concreta, debiendo este ser un número entero o decimal mayor o igual a 0.

Si el actor rechaza una pregunta, el sistema seleccionará una pregunta nueva de entre el conjunto de preguntas pertinentes, disponibles y no empleadas en este examen de la batería, mostrándola en ese mismo formulario. Si no quedasen preguntas a utilizar, el sistema informará al actor de tal circunstancia y descartará la acción de rechazo expresada. Cuando haya confirmado y, si procede, redefinido la puntuación y/o los criterios de penalización de todas las preguntas recopiladas por el sistema para el examen, el sistema mostrará al actor un botón para confirmar la creación del examen y un segundo botón para cancelarla. Si el actor pulsa el botón de cancelar, el sistema cancelará la creación del examen y cerrará el formulario. Si el actor pulsa el botón crear el sistema generará y guardará un registro en la tabla de exámenes con los siguientes datos:

- Identificador único del modelo de examen generado

Page 60: Ingenieria de Software II.pdf

Ingeniería del Software II

60

60

CMMJ - Tlf: (+34) 000 000 000

- Nombre del modelo de examen - Tipo de examen - Valor por defecto de la pregunta. - Tiempo para la ejecución del examen.

Si el examen es de tipo test, además se almacenará:

- Indicador de aplicación de criterio de penalización de restar por bloques

- Indicador de aplicación de criterio de penalización de restar en blanco.

- Valor a restar por defecto al aplicar en el criterio de penalización de restar en blanco.

Cada categoría y/o asignatura que se haya designado como criterio para la selección automática de las preguntas se almacenarán individualmente como etiquetas del modelo de examen y en la tabla de etiquetas del modelo de examen. Así, por cada uno de los elementos indicados se generará y guardará una etiqueta en la mencionada tabla con la siguiente información

- Indicador único de la etiqueta de examen. - Tipo de etiqueta, que podrás recibir en esta caso dos

valores, MOD_ASIGNATURA para cada asignatura de acotación y MOD_CATEGORIA para categoría de acotación empleada.

- Identificador único del elemento categoría o asignatura empleados, según corresponda.

- Identificador único del modelo de examen. Además, también se generarán y almacenarán en la tabla de preguntas por examen un registro por cada pregunta que el sistema haya seleccionado y que el actor haya confirmado para formar parte del examen con los siguientes datos:

- Identificador único de la pregunta -examen - Identificador único del examen - Identificador único de la pregunta - Numero de orden - Valor de la pregunta, que será el valor por defecto

indicado por el actor en el cuestionario de creación del examen o en su caso, el valor que le actor haya redefinido en cada pregunta durante el proceso de confirmación.

Cuando se trate de un examen tipo test, se almacenarán además los siguientes datos:

- Si el examen tiene activada la opción de restar por bloques, el valor de equivalencia a aplicar. Dicho valor

Page 61: Ingenieria de Software II.pdf

Ingeniería del Software II

61

61

CMMJ - Tlf: (+34) 000 000 000

será de una unidad o en su caso, el valor de equivalencia que el actor haya redefinido en cada pregunta durante el proceso de confirmación.

- Si el examen tiene activada la opción de restar en blanco, el valor de resta a aplicar. Dicho valor será el valor genérico indicado por el actor durante la activación del criterio de restar en blanco o en su caso, el valor que el actor haya en cada pregunta durante el proceso de confirmación.

Finalmente, se mostrará un mensaje al actor informándole del la correcta finalización del proceso de creación del examen y el formulario se cerrará.

Salidas - Mensaje - Datos del modelo de examen creado. - Datos de las nuevas etiquetas del modelo de examen

vinculadas al modelo de examen creado - Datos de las nuevas asignaciones de preguntas al modelo

de examen creado.

Errores Si alguno de los datos suministrados para la creación del modelo de examen no cumple las condiciones de validación, se aborta la acción y se genera un mensaje indicando tal circunstancia, detallando cuál o cuáles de los datos no cumple la validación. En caso de cualquier otra casuística que evite la actualización de los datos, se mostrará un error informando y se cancelará la acción

Id y nombre del requisito RF-EXA-002. Mantenimiento de modelos de examen:

búsqueda

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la búsqueda de modelos de examen, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo PROFESOR o ADMINISTRADOR. El sistema provee de un formulario donde el actor podrá determinar los criterios para realizar la búsqueda y los botones para efectuar la búsqueda o cancelar la acción. No hay obligatoriedad de indicar ningún criterio para realizar la

Page 62: Ingenieria de Software II.pdf

Ingeniería del Software II

62

62

CMMJ - Tlf: (+34) 000 000 000

búsqueda El sistema le mostrará en un listado los resultados de la consulta realizada

Entradas - Identificador de sesión - Criterios adicionales.

Secuencia de operación Se comprueba que el actor puede realizar la acción de buscar modelos de examen aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ADMINISTRADOR y PROFESOR. Se muestra al actor un formulario con los campos identificador único del modelo examen, nombre, tipo de modelo de examen, asignaturas de acotación y categorías de acotación. En el formulario también se muestran dos botones, uno con el texto “buscar” y otro con el texto “cancelar” Los campos de categorías y asignaturas se mostrarán acompañados cada uno de ellos un botón que incorporará una funcionalidad que facilitará al actor seleccionar una o varias de las asignaturas o categorías, según corresponda, a las que se encuentre vinculado profesor. Si el actor pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. Si el actor pulsa el botón buscar, el sistema utilizará los datos proporcionados en el formulario para realizar una búsqueda en la tabla de modelos de examen y, si se hubieran suministrado datos de categoría o asignatura para realizar la búsqueda, también sobre la tabla de etiquetas del modelo de examen, localizando los exámenes que cumplieran ambas restricciones. A estos criterios habrá que añadir los posible criterios adicionales recibidos en la entrada y las restricciones del actor cuando este represente a un usuario de tipo PROFESOR, ya que estos solo podrán acceder al conjunto de exámenes creados por ellos mismos. Si no se ha incluido ningún dato en el formulario y los filtros adicionales no disponen de contenido, se realizará una búsqueda de modelos de examen sin más filtros que los derivados de la tipología del usuario. Con los registros localizados, se generará un listado compuesto por el identificador único del examen, el tipo del examen y el nombre. Dicho listado se muestra al actor en el mismo formulario de búsqueda, de tal forma que se pueda seleccionar uno de los modelos de examen contenidos en la tabla cuyos datos serán

Page 63: Ingenieria de Software II.pdf

Ingeniería del Software II

63

63

CMMJ - Tlf: (+34) 000 000 000

retornados, o bien cancelar la búsqueda a través del botón correspondiente.

Salidas - Datos del modelo de examen localizado

Errores N/A

Id y nombre del requisito RF-EXA-003. Mantenimiento de modelos de examen:

edición

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la edición de modelos de examen, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo PROFESOR o ADMINSTRADOR La edición seguirá el mismo modelo de trabajo planteado en la creación del modelo y plasmado en el requisito RG-EXA-001, con la lógica particularidad de que no se creará un modelo nuevo ni se seleccionarán automáticamente preguntas nuevas a no ser que el usuario las rechace de forma individual durante la fase de evaluación, en cuyo caso el sistema sí tratara de proporcionar una nueva pregunta en sustitución de la rechazada automáticamente. Finalmente el sistema después de completar la acción, mostrará un mensaje informando sobre la correcta actualización del modelo y se cerrará el formulario.

Entradas - Identificador de sesión - Identificador único del modelo de examen

Secuencia de operación Se comprueba que el actor puede realizar la acción de editar modelos de examen aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ADMINISTRADOR y PROFESOR. Con el identificador único del modelo de examen recibido, el sistema accederá a la tabla de modelos de examen, de etiquetas de modelo examen y de preguntas por examen con el fin de recopilar toda la información que constituye el modelo del examen a editar. A continuación, el sistema mostrará al usuario la primera de las preguntas del conjunto de cuestiones planteadas durante el proceso de creación del examen expuesto en el RF-EXA-001, siendo de aplicación las mismas pautas de comportamiento

Page 64: Ingenieria de Software II.pdf

Ingeniería del Software II

64

64

CMMJ - Tlf: (+34) 000 000 000

descritas en dicho punto. Tras completar el cuestionario y antes de comenzar nuevamente a mostrar las preguntas que se seleccionaron en su momento para su confirmación, el sistema realizará dos comprobaciones: - Comprobará si han sido redefinidos los criterios de

valoración y/o evaluación por parte del usuario, en cuyo caso, actualizará de forma consistente los criterios de valoración y evaluación, si procediese, de las preguntas que se vieran afectadas por estos cambios.

- Comprobará si las preguntas vinculadas al modelo de examen siguen siendo consistentes con las nuevas especificaciones del examen redefinidas por el actor en el cuestionario. Si alguna pregunta hubiese dejado de ser consistente con las nuevas especificaciones y/o el número de preguntas del examen hubiese sido cambiado por el actor, el sistema las desvinculará del modelo e informará al usuario de esta circunstancia. Así, si el número de preguntas resultante en el conjunto fuese menor que el número de preguntas especificado, el sistema tratará de seleccionar tantas nuevas preguntas como sean necesarias que cumplan las características del modelo de examen establecidas en el cuestionario. Si por el contrario el contenido del conjunto de preguntas fuese mayor que el número de preguntas debido a una redefinición a la baja de este por parte del actor, el sistema no dejará finalizar la confirmación hasta que este no descarte tantas como sean necesarias. Cuando el conjunto de preguntas del modelo de examen resulta modificado como consecuencia de la redefinición de las características del modelo por parte del actor, el sistema inhabilita el botón confirmar todas y será necesaria la confirmación individual de todas la preguntas del conjunto seleccionado, mostrando una marca que permita al usuario identificar las nuevas y/o mostrando un contador del número de preguntas que el usuario deberá descartar para adaptar el total de preguntas del conjunto al número de preguntas especificado. Si el usuario rechaza una pregunta, el sistema no propondrá otra a menos que el total de preguntas del conjunto quede por debajo del número de preguntas esperado. Las nuevas preguntas incluidas de forma automática tendrán especificados los criterios de valoración y evaluación por defecto que haya especificado el actor en el

Page 65: Ingenieria de Software II.pdf

Ingeniería del Software II

65

65

CMMJ - Tlf: (+34) 000 000 000

cuestionario, pudiendo estos criterios ser re-definidos por el actor durante su confirmación, al igual que con el resto de preguntas. Tras completar la revisión de todas las preguntas, serán re-secuenciadas y se mostrarán al actor dos botones, cancelar y actualizar.

Si el actor pulsa el botón de cancelar, el sistema cancelará la actualización del examen y cerrará el formulario. Si el actor pulsa el botón actualizar el sistema comprobará que el número de preguntas presentes en el conjunto sea igual al número de preguntas esperado, impidiendo la acción y mostrando un mensaje en caso contrario. Si todas las validaciones indicadas se cumplen, el sistema actualizará el registro del modelo de examen identificado en la tabla de modelo con los nuevos datos del cuestionario. Se eliminarán todas las entradas de la tabla etiqueta de modelo de examen que se correspondan con alguna de las categorías y/o asignaturas que hayan sido eliminadas en las respuestas correspondientes del cuestionario por parte del actor y se incluirán todas las nuevas designaciones de categoría y/o asignatura que no existiesen en su respuesta previa. Los datos a incluir en cada registro nuevo de la tabla de etiquetas son los mismos que los descritos en el proceso de alta de modelos de examen descritos en RF-EXA-001. Se eliminarán todas las entradas de la tabla preguntas por examen de las preguntas desechadas por incumplir criterios y/o descartadas por el usuario durante la evaluación y se incluirán si procede todas que nuevas que se hayan confirmado, siguiendo la misma pauta que en el RF-EXA-001 de inserción. Además, actualizarán las restantes con el fin de que reflejen el nuevo número de secuencia asignado y los nuevos criterios de valoración y evaluación designados por el usuario, si procede. Finalmente, se mostrará un mensaje al actor informándole del la correcta finalización del proceso de actualización del modelo de examen el formulario se cerrara

Salidas - Mensaje - Datos del modelo de examen actualizado - Datos de las nuevas etiqueta de modelo de examen

vinculadas al modelo de examen creadas - Datos de las etiquetas de modelo de examen vinculadas al

modelo de examen eliminadas - Datos de las nuevas asignaciones creadas de preguntas al

modelo de examen

Page 66: Ingenieria de Software II.pdf

Ingeniería del Software II

66

66

CMMJ - Tlf: (+34) 000 000 000

- Datos de las asignaciones actualizadas de preguntas al modelo de examen

- Datos de las asignaciones eliminadas de preguntas al modelo de examen.

Errores Si no se localiza la información a editar a partir del identificador único recibido, se cancelará la acción y se mostrará un mensaje indicando tal circunstancia, cerrándose el formulario. Si alguno de los datos suministrados para la actualización del modelo de examen no cumple las condiciones de validación, se aborta la acción y se genera un mensaje indicando tal circunstancia, detallando cuál o cuáles de los datos no cumple la validación. Si como resultado de la modificación de las características del examen, el número de preguntas que cumplen los criterios no alcanza el número de preguntas configurado, se aborta la acción, mostrando al usuario un mensaje y saliendo del formulario. En caso de cualquier otra casuística que evite la actualización de los datos, se mostrará un error informando y se cancelará la acción.

Id y nombre del requisito RF-EXA-004. Mantenimiento de modelos de examen:

borrado

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la borrado de modelos de examen, si bien solo el usuario con de tipo ADMINISTRADOR o PROFESOR. El sistema provee de un formulario donde el usuario podrá visualizar el identificador único del modelo de examen, su nombre, su tipo y sus etiqueta de modelo de examen (asignaturas y categorías) El formulario mostrará además dos botones, uno para borrar el modelo y otro para cancelar la acción.

Entradas - Identificador de sesión - Identificador único del modelo de examen

Secuencia de operación Se comprueba que el actor puede realizar la acción de borrado de modelos de examen aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra

Page 67: Ingenieria de Software II.pdf

Ingeniería del Software II

67

67

CMMJ - Tlf: (+34) 000 000 000

habilitada para usuario de tipo ADMINISTRADOR o PROFESOR El sistema accederá a las tablas de modelos de examen, etiqueta de modelo de examen y preguntas por examen para eliminar todas las entradas vinculadas al identificador único de modelo de examen recibido. Adicionalmente, accederá a la entidad de ejecuciones de examen y eliminará todas las ejecuciones de examen que se hayan realizado a partir del modelo de examen borrado. Finalmente el sistema después de realizar el borrado, mostrará un mensaje informando sobre la correcta realización del proceso y se cerrará el formulario.

Salidas - Mensaje - Datos del modelo de examen borrado - Datos de las etiqueta de modelo de examen vinculadas al

modelo de examen borrado - Datos de las asignaciones de preguntas al modelo de

examen borrado - Datos de las ejecuciones realizadas a partir de los datos del

modelo de examen borrado.

Errores Si no se localiza la información a borrar a partir del identificador único recibido, se cancelará la acción y se mostrará un mensaje indicando tal circunstancia, cerrándose el formulario.

Id y nombre del requisito RF-EXA-005. Mantenimiento de modelos de examen:

exportación e impresión.

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la impresión y exportación de modelos de examen, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo PROFESOR o ADMINISTRADOR. El usuario podrá realizar la búsqueda de un modelo de examen concreto y proceder a su impresión o exportación a un formato por determinar.

Entradas - Identificador de sesión

Secuencia de operación Se comprueba que el actor puede realizar la acción de imprimir y exportar modelos de examen aplicando la funcionalidad

Page 68: Ingenieria de Software II.pdf

Ingeniería del Software II

68

68

CMMJ - Tlf: (+34) 000 000 000

recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ADMINISTRADOR y PROFESOR. Este requisito se apoyará en la funcionalidad de búsqueda ya descrita en el RF-EXA-002. Tras seleccionar el modelo el actor podrá elegir entre imprimir el modelo o exportarlo. La información sometida a este procedimiento será la información relevante del modelo de examen, las preguntas y, si procede, las respuestas. Tanto los posibles formatos de exportación como el aspecto del documento a imprimir quedan a expensas de una futura definición por parte del cliente.

Salidas - Documento compuesto resultante.

Errores N/A

Page 69: Ingenieria de Software II.pdf

Ingeniería del Software II

69

69

CMMJ - Tlf: (+34) 000 000 000

3.2.7. Convocatorias de examen

Se incluyen en este apartado los requisitos identificados vinculados con las tareas genéricas

de la aplicación relacionadas con el mantenimiento de convocatorias de examen.

Id y nombre del requisito RF-CNV-001. Mantenimiento de convocatorias de examen:

alta

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la creación de convocatorias de examen, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo PROFESOR. El sistema provee de un formulario donde el actor deberá indicar obligatoriamente el modelo de examen que quiere emplear en la convocatoria, de entre el conjunto de modelos poseídos por el profesor. El actor deberá definir obligatoriamente la asignatura sobre la que se quiere generar la convocatoria, de entre el conjunto de asignaturas asignadas al profesor. El actor opcionalmente podrá establecer una categoría a la convocatoria del examen, de entre el conjunto de categorías propiedad del profesor. (primer parcial, unidad 1,…) El actor deberá establecer de forma obligatoria la planificación de la convocatoria en términos de plazo de vigencia de la misma El formulario ofrecerá ayudas para la localización de los modelos de examen, asignaturas y categorías, junto con dos botones para confirmar la creación de la convocatoria y la cancelación. El sistema localizará y notificará a los alumnos afectados por la creación de la nueva convocatoria de esta circunstancia.

Entradas - Identificador de sesión - Criterios adicionales.

Secuencia de operación Se comprueba que el actor puede realizar la acción de crear convocatorias aplicando la funcionalidad recogida en el punto

Page 70: Ingenieria de Software II.pdf

Ingeniería del Software II

70

70

CMMJ - Tlf: (+34) 000 000 000

RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo PROFESOR. Se mostrará al actor un formulario con varios grupos de datos solicitándole la información necesaria para la creación de la convocatoria: - Modelo de examen: Contendrá tres campos no editables y

un botón de búsqueda. Los campos serán identificador único del modelo de examen, tipo de examen y nombre del modelo de examen. El botón buscar facilitará una función de búsqueda de modelos de examen idéntica a la descrita en el requisito RF-EXA-002. Se mostrarán en los campos no editables del formulario los datos del conjunto de datos del modelo de examen seleccionado obtenidos que correspondan. La selección de un modelo de examen es de carácter obligatorio.

- Asignatura: Contendrá dos campos no editables, código y

nombre de la asignatura, y un botón de búsqueda. Este botón facilitará una función de búsqueda de asignaturas idéntica a la descrita en el requisito RF-ASG-002. Se mostrarán en los campos no editables del formulario los datos del conjunto de datos de la asignatura seleccionada obtenidos que correspondan. La selección de una asignatura es de carácter obligatorio.

- Categoría: Contendrá un campo no editable y un botón de

búsqueda. Este botón facilitará una función de búsqueda de categorías idéntica a la descrita en el requisito RF-CAT-002. Se mostrarán en los campos no editables del formulario los datos del conjunto de datos de la asignatura seleccionada obtenidos que correspondan. La selección de una asignatura es de carácter obligatorio.

- Planificación: Contendrá 2 campos tipo marca de tiempo a

través de los cuales el usuario podrá establecer la ventana de tiempo durante la cual la convocatoria tiene vigencia, es decir, desde cuando hasta cuándo estará disponible el examen para su realización.

- Las fechas seleccionadas solo podrán ser mayores o

iguales que el momento en el que se realice la acción y consistentes, entendiendo por consistencia que la marca de tiempo designada como límite inferior del rango sea menor que la designada como límite superior y que la diferencia entre ambas marcas sea mayor o igual al número de minutos estipulado como tiempo máximo para la realización del examen establecido en el modelo de examen empleado en la convocatoria.

Page 71: Ingenieria de Software II.pdf

Ingeniería del Software II

71

71

CMMJ - Tlf: (+34) 000 000 000

En el formulario también se muestran dos botones, uno con el texto “aceptar” y otro con el texto “cancelar” Si el actor pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. Si el actor pulsa el botón crear el sistema generará y guardará un registro en la tabla de convocatorias con los siguientes datos:

- Identificador único de la convocatoria generada - Identificador único del modelo de examen a emplear. - Identificador único de la asignatura seleccionada - Identificador único de la categoría seleccionada - Marca de tiempo de inicio de la convocatoria - Marca de tiempo de finalización de la convocatoria - Marca de tiempo de corrección de la convocatoria, sin

valor en el momento del alta. Adicionalmente, se localizará en la tabla de matriculaciones a todos los alumnos que se encuentren vinculados a la asignatura de la convocatoria y se generará un registro en la tabla de ejecuciones de examen por cada uno de los alumnos localizados con la siguiente información:

- Identificador único de la ejecución generada - Identificador único de la convocatoria - Identificador único del alumno - Indicador de notificado al alumno. - Estado de la ejecución que será PENDIENTE - Tiempo consumido, con valor inicial asignado 0 - Comentario del profesor, que tendrá un valor vacio

Por cada registro insertado en la tabla de ejecuciones de examen, se crearán tantos registros en la tabla de respuestas de examen como preguntas formen parte del modelo de examen seleccionado en la convocatoria. La información guardada en cada registro de la tabla respuestas generado es la siguiente:

- Identificador único de la respuesta generada - Identificador único de la convocatoria - Identificador único de la pregunta (obtenida a través del

modelo de examen de la convocatoria) - Respuesta, que tendrá valor vacio. - Puntuación, que tendrá valor 0

Con la información de los alumnos recabada, se enviará un correo a cada uno de ellos donde se les informará de la creación de una convocatoria que les afecta. El sistema marcará el indicador de notificado en el registro de la ejecución

Page 72: Ingenieria de Software II.pdf

Ingeniería del Software II

72

72

CMMJ - Tlf: (+34) 000 000 000

del examen cuando el envío del correo se haya realizado sin incidencias. Tras el envío de la convocatoria a todos los alumnos y la asignación de la correspondiente marca a todos los registros de ejecución de examen relacionados, el sistema mostrará por pantalla un mensaje al actor informándole de la correcta finalización del proceso de creación de la convocatoria y junto con una lista de los alumnos a los que no se ha podido notificar para que el profesor realice las acciones oportunas. Dicho listado podrá ser impreso. Finalmente, el formulario se cerrará.

Salidas - Mensaje - Datos de la nueva convocatoria de examen creada - Datos de las nuevas ejecuciones de examen creadas - Datos de las nuevas respuestas de examen creadas. - Correos electrónicos a los alumnos afectados - Lista imprimible de los alumnos a los que no se ha podido

notificar.

Errores Si alguno de los datos suministrados para la creación de la convocatoria no cumple las condiciones de validación, se aborta la acción y se genera un mensaje indicando tal circunstancia, detallando cuál o cuáles de los datos no cumple la validación. En caso de cualquier otra casuística que evite la actualización de los datos, se mostrará un error informando y se cancelará la acción. Si no se consigue notificar a un ningún alumno, se cancela la creación de la convocatoria, mostrando un mensaje al usuario indicando que el servicio de correo no funciona.

Id y nombre del requisito RF-CNV-002. Mantenimiento de convocatorias de examen:

búsqueda

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la búsqueda de convocatorias de examen, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo PROFESOR o ADMINISTRADOR. El sistema provee de un formulario donde el actor podrá determinar los criterios para realizar la búsqueda y los botones para efectuar la búsqueda o cancelar la acción.

Page 73: Ingenieria de Software II.pdf

Ingeniería del Software II

73

73

CMMJ - Tlf: (+34) 000 000 000

No hay obligatoriedad de indicar ningún criterio para realizar la búsqueda El sistema le mostrará en un listado los resultados de la consulta realizada

Entradas - Identificador de sesión - Criterios adicionales.

Secuencia de operación Se comprueba que el actor puede realizar la acción de buscar convocatorias aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ADMINISTRADOR y PROFESOR. Se muestran varios bloques de datos para el suministro de los datos a emplear en la localización de convocatorias de examen, donde ninguno de los datos es obligatorio. Modelo de examen: Contendrá tres campos no editables y un botón de búsqueda. Los campos serán identificador único del modelo de examen, tipo de examen y nombre del modelo de examen. El botón buscar facilitará una función de búsqueda de modelos de examen idéntica a la descrita en el requisito RF-EXA-002. Se mostrarán en los campos no editables del formulario los datos del conjunto de datos del modelo de examen seleccionado obtenidos que correspondan. Asignatura: Contendrá dos campos no editables, código y nombre de la asignatura, y un botón de búsqueda. Este botón facilitará una función de búsqueda de asignaturas idéntica a la descrita en el requisito RF-ASG-002. Se mostrarán en los campos no editables del formulario los datos del conjunto de datos de la asignatura seleccionada obtenidos que correspondan. Categoría: Contendrá un campo no editable y un botón de búsqueda. Este botón facilitará una función de búsqueda de categorías idéntica a la descrita en el requisito RF-CAT-002. Se mostrarán en los campos no editables del formulario los datos del conjunto de datos de la asignatura seleccionada obtenidos que correspondan. Planificación: Contendrá 2 campos tipo marca de tiempo a través de los cuales el actor podrá establecer la ventana de tiempo a la que quiere acotar la búsqueda de convocatorias y una marca donde establecerá si esta ventana de búsqueda la quiere acotar sobre la marca de inicio de la convocatoria o la fecha de finalización de la convocatoria. En el formulario también se muestran dos botones, uno con el texto “buscar” y otro con el texto “cancelar”

Page 74: Ingenieria de Software II.pdf

Ingeniería del Software II

74

74

CMMJ - Tlf: (+34) 000 000 000

Si el actor pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. Si el actor pulsa el botón buscar, el sistema aplicará los criterios de búsqueda definidos en el formulario sobre la tabla de convocatorias de examen, a los que se añadirán los posible criterios adicionales recibidos en la entrada. Adicionalmente, cuando el actor que esté realizando la búsqueda sea de tipo profesor, el sistema acotará la búsqueda a solo la convocatoria cuyas asignaturas sean asignaturas que tenga asignadas el profesor. De este modo, ante búsquedas sin criterios, estás quedarán acotadas a la información pertinente, en función del usuario que la realice. Con los registros localizados, se generará un listado donde se mostrará de forma legible el identificador único de la convocatoria, las fechas de programación, el código de asignatura, la categoría asignada, el tipo del modelo de examen y el nombre del modelo de examen. Dicho listado se muestra al actor en el mismo formulario de búsqueda, de tal forma que se pueda seleccionar uno de las convocatorias contenidas en la tabla cuyos datos serán retornados, o bien cancelar la búsqueda a través del botón correspondiente.

Salidas - Datos de la convocatoria seleccionada

Errores N/A

Id y nombre del requisito RF-CNV-003. Mantenimiento de convocatorias de examen:

borrado

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema solo permite el borrado de convocatorias de examen, si bien solo cuando el actor que está realizando la acción sea un usuario de tipo PROFESOR o ADMINISTRADOR. El sistema provee de un formulario donde se mostrarán los datos de la convocatoria y dos botones, eliminar y cancelar. Tras solicitar confirmación sobre el borrado de la convocatoria, el sistema eliminar la convocatoria y todas las ejecuciones

Page 75: Ingenieria de Software II.pdf

Ingeniería del Software II

75

75

CMMJ - Tlf: (+34) 000 000 000

vinculadas a la misma. El sistema localizará y notificará a los alumnos afectados por la eliminación de la convocatoria de esta circunstancia. El sistema mostrará un mensaje al usuario informándole sobre la correcta realización del borrado de la convocatoria

Entradas - Identificador de sesión - Identificador único de la convocatoria

Secuencia de operación Se comprueba que el actor puede realizar la acción de eliminar convocatorias aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ADMINISTRADOR y PROFESOR. Se muestran varios bloques de datos con la información de la convocatoria que se desea borrar, recuperando los datos a partir del identificador único de convocatoria recibido. La disposición y agrupación de datos en la pantalla seguirá la misma filosofía descrita en el RF-CNV-001 de creación de convocatoria, con la particularidad de que ninguno de los datos mostrados será editable. En el formulario también se muestran dos botones, uno con el texto “eliminar” y otro con el texto “cancelar” Si el actor pulsa el botón cancelar, el sistema cancela la acción y se cierra el formulario. Si el actor pulsa el botón eliminar, el sistema solicitará que se confirme el deseo de borrar la convocatoria, informándole que se borrarán todas las ejecuciones de examen realizadas, completadas o no, por parte de los alumnos. El sistema localizará y borrará todas las entradas vinculadas a la convocatoria a borrar en las tablas:

- Respuestas de examen - Ejecuciones de examen - Convocatorias de examen

Si la ventana dispuesta para la realización del examen de la convocatoria no hubiese terminado, el sistema recabará a través de la tabla de matriculaciones y alumnos la información necesaria de los alumnos afectados, a quienes se les notificará por correo de la cancelación de la convocatoria que les afectaba. Tras el envío el sistema mostrará por pantalla un mensaje al actor informándole de la correcta finalización del proceso de

Page 76: Ingenieria de Software II.pdf

Ingeniería del Software II

76

76

CMMJ - Tlf: (+34) 000 000 000

eliminación de la convocatoria y junto con una lista de los alumnos a los que no se ha podido notificar para que el profesor realice las acciones oportunas. Dicho listado podrá ser impreso.

Salidas - Datos de la convocatoria seleccionada

Errores Si no se localiza la información a borrar a partir del identificador único recibido, se cancelará la acción y se mostrará un mensaje indicando tal circunstancia, cerrándose el formulario.

Page 77: Ingenieria de Software II.pdf

Ingeniería del Software II

77

77

CMMJ - Tlf: (+34) 000 000 000

3.2.8. Ejecución de exámenes

Se incluyen en este apartado los requisitos identificados vinculados con las tareas genéricas

de la aplicación relacionadas con la ejecución de exámenes.

Id y nombre del requisito RF-EJE-001. Ejecución de exámenes: Ejecución

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la ejecución de exámenes actores que representen a usuarios de tipo ALUMNO. Un alumno solo podrá realizar una única ejecución de un examen, si bien, podrá acceder a esta y posponerla tantas veces como desee, quedando su estado congelado de tal forma que la siguiente vez que acceda, esta se muestre exactamente igual que cuando la dejó. La accesibilidad quedará condicionada a las siguientes causas:

- Que el momento en el que acceda se encuentre en el

plazo de disponibilidad acotado por la convocatoria, - Que quede tiempo para su realización - Que el alumno no la haya entregado.

Para acceder a las ejecuciones, el sistema mostrará al actor un listado de las ejecuciones que tenga asignadas. Dicho listado tendrá los datos de la asignatura, el tipo de examen, el estado de la ejecución, las fechas de apertura y cierre de la ejecución y la puntuación obtenida. El actor podrá seleccionar y acceder a cualquiera de las ejecuciones del listado, teniendo en cuenta las restricciones indicadas anteriormente. Tras acceder a una de ellas, el sistema le irá mostrando de forma sucesiva las preguntas que constituyen el examen, posibilitando que el actor se desplace por ellas. Cada respuesta aportada será guardada sin necesidad de que el alumno indique su voluntad de guardarla. En todo momento se le mostrarán los botones que le habiliten para navegar entre las distintas preguntas y un tercer botón para posponer la ejecución. En la última pregunta se le mostrará además un botón que le permitirá entregar el examen, quedando de esta forma el examen como ENTREGADO.

Page 78: Ingenieria de Software II.pdf

Ingeniería del Software II

78

78

CMMJ - Tlf: (+34) 000 000 000

El orden en el que se le muestren las preguntas y respuestas en los exámenes tipo test será diferente para cada alumno,

Entradas - Identificador de sesión

Secuencia de operación Se comprueba que el actor puede realizar la acción de ejecutar de exámenes aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ALUMNO. El sistema accederá a la tabla de convocatorias de examen para recuperar todas aquellas vinculadas al identificador único del actor presente en el perfil de usuario del actor. El sistema recuperará la información de esta tabla así como la información de la tabla de asignaturas y convocatorias que permita construir un listado donde el actor pueda visualizar los datos de la asignatura, el tipo de examen, el estado de la ejecución, las fechas de apertura y cierre de la ejecución y la puntuación obtenida. Las ejecuciones de examen pueden tener los siguientes estados:

- PENDIENTE - EN CURSO - ENTREGADO - CORREGIDO - NO PRESENTADO

El listado se mostrará al usuario ordenado descendentemente por la fecha de cierre de la ventana de disponibilidad del examen, si bien el actor podrá establecer los criterios de ordenación que le parezca en base a los campos contenidos en el listado. El actor podrá acceder a una ejecución para completarla cuando se cumplan todas las siguientes condiciones:

- El momento en el que acceda se encuentre en el plazo

de disponibilidad acotado por la convocatoria, - Quede tiempo para su realización - La ejecución se encuentre en estado PENDIENTE o EN

CURSO Antes de mostrar al alumno el contenido del examen y cuando este sea tipo test, el sistema realizará una ordenación de las preguntas y respuestas empleando una función determinista en la que se emplee como argumento el identificador único del alumno y que garantice una variabilidad en la secuencia de las preguntas única y en las respuestas lo suficientemente amplia respecto a la ordenación generada para cualquier otro alumno. En caso de que no sea tipo test, se empleará la secuencia

Page 79: Ingenieria de Software II.pdf

Ingeniería del Software II

79

79

CMMJ - Tlf: (+34) 000 000 000

contenida en las preguntas vinculadas al modelo de examen. Cuando el actor acceda por primera vez a una ejecución, el sistema actualizará el estado de esta en la tabla de ejecuciones a EN CURSO y podrá en marcha un contador de tiempo. Cuando el usuario interactúe con los botones o cuando el contador de tiempo supere un umbral de autoguardado establecido, el sistema persistirá la situación de la ejecución en ese momento. Para ello realizará las siguientes acciones:

- En la tabla de ejecuciones, acumulará el tiempo que refleje el contador de tiempo sobre el campo tiempo consumido, inicializando de nuevo el contador a 0 y almacenando el número de secuencia de la pregunta en la que se encuentre cuando haya pulsado el botón. Cuando el campo tiempo consumido en la ejecución haya acumulado una cantidad que supere el tiempo establecido en el modelo de examen para su realización o cuando el momento en el que el usuario haya interactuado con los botones del formulario se encuentre fuera de la ventana de disponibilidad establecida en la convocatoria, el sistema cambiará automáticamente el estado del examen a ENTREGADO, informará al alumno que ha consumido el tiempo estipulado para la ejecución del examen y cerrará el formulario de la ejecución.

- En la tabla de respuestas, actualizará la respuesta consignada en la pregunta en la que se encontrase cuando haya pulsado el botón o se haya producido un ciclo automático de guardado. Cuando el tipo del examen sea test, almacenará el número de orden relativo de la respuesta de entre el conjunto de respuestas a una pregunta.

Cuando el examen sea tipo TEST, las respuestas, tanto la correcta como el resto serán mostradas en bajo un patrón de selección única, mientras que cuando sea de desarrollo se mostrará una caja de texto donde el alumno podrá introducir por teclado la respuesta. El sistema mostrará cuatro botones en el formulario

- Anterior: Navega a la pregunta anterior de la ejecución según el orden que corresponda al alumno. Cuando se encuentre en la primera pregunta, este botón no se mostrará.

- Siguiente: Navega a la pregunta anterior de la ejecución

Page 80: Ingenieria de Software II.pdf

Ingeniería del Software II

80

80

CMMJ - Tlf: (+34) 000 000 000

según el orden que corresponda al alumno. Cuando se encuentre en la última pregunta, este botón no se mostrará.

- Posponer: Suspende la ejecución del examen, pudiendo

ser retomada posteriormente. Ocasiona la salida del formulario.

- Entregar: Solo se muestra en la última pregunta y

ocasiona el cambio del estado del examen de EN CURSO a ENTREGADO. Ocasiona la salida del formulario. Cuando el usuario pulse este botón y el sistema haya almacenado toda la información en el sistema, enviará un correo electrónico al alumno indicándole que el examen se ha entregado correctamente.

Cualquier acción realizada por el actor o cualquier evento de los catalogados que comporte el cierre del formulario será mostrada mediante un mensaje explicativo al actor.

Salidas - Mensaje - Datos de la ejecución de examen actualizados - Datos de las respuestas del examen actualizados.

Errores En caso de cualquier casuística que evite la actualización de los datos, se mostrará un error informando y se cancelará la acción.

Id y nombre del requisito RF-EJE-002. Ejecución de exámenes: Revisión

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la revisión de ejecuciones de exámenes por parte de actores que representen a usuarios de tipo ALUMNO. Un actor solo podrá acceder a la revisión de las ejecuciones de examen cuando la ejecución ya se haya sido corregida y la vigencia de la convocatoria haya expirado, teniendo solo acceso a las ejecuciones que le son pertinentes. Para acceder a las ejecuciones, el sistema mostrará al actor un listado de las ejecuciones a las que tenga acceso. Dicho listado tendrá los datos de la asignatura, el tipo de examen, el estado de la ejecución, las fechas de apertura y cierre de la ejecución, su estado y la puntuación obtenida.

Page 81: Ingenieria de Software II.pdf

Ingeniería del Software II

81

81

CMMJ - Tlf: (+34) 000 000 000

La puntuación solo se mostrará cuando el estado del examen sea CORREGIDO y haya expirado el tiempo de disponibilidad de la convocatoria respecto al momento en el que se esté realizando la consulta. Estas mismas limitaciones son de aplicación en cuando el actor intente acceder a una de las ejecuciones, pudiendo revisar solo las que cumplan dichas restricciones. Tras acceder a una de ellas, el sistema le irá mostrando de forma sucesiva las preguntas que constituyen el examen y la respuesta correcta marcada o complementada por el profesor si procede, en función del tipo de examen.

Entradas - Identificador de sesión - Criterios adicionales

Secuencia de operación Se comprueba que el actor puede realizar la acción de revisar exámenes aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo ALUMNO La revisión de una ejecución consiste en el acceso a una ejecución cuya disponibilidad establecida en su convocatoria haya expirado. El sistema recopilara y mostrará al actor un listado de las ejecuciones a las que tenga acceso en función de su relación con ellas, tal y como se ha descrito en la especificación del requisito. A los criterios ya mencionados, se sumarán los posibles criterios adicionales presentes en la entrada que podrán restringir aun más el conjunto de ejecuciones a mostrar. Dicho listado tendrá los datos de la asignatura, el tipo de examen, el estado de la ejecución, las fechas de apertura y cierre de la ejecución y la puntuación obtenida. El actor podrá seleccionar y acceder a cualquiera de las ejecuciones del listado, teniendo en cuenta las restricciones indicadas anteriormente cuando se cumplan todas las siguientes condiciones:

- Que el momento en el que acceda sea posterior al plazo de disponibilidad acotado por la convocatoria,

- Que el estado de la ejecución del examen sea CORREGIDO.

Las preguntas serán mostradas en el mismo orden en el que se presentaron durante la realización del examen, utilizándose para su cálculo la misma estrategia empleada entonces, es decir, una función determinista a partir del identificador único del usuario ejecutor del examen.

Page 82: Ingenieria de Software II.pdf

Ingeniería del Software II

82

82

CMMJ - Tlf: (+34) 000 000 000

Cuando el examen sea tipo test aparecerá marcada la respuesta correcta determinada a partir de la información presente en el modelo de examen empleado en la convocatoria y la puntuación resultante de la evaluación de la respuesta. Este puntaje será positivo o negativo como resultado de la aplicación de los criterios de valoración y evaluación genéricos definidos en el modelo de examen, los criterios de valoración y evaluación que se hayan podido ser redefinidos sobre la pregunta de forma específica, la consignación de respuesta a la pregunta y su correspondencia con la respuesta correcta. En caso de que sea a desarrollar, se mostrará el puntaje que haya asignado el profesor a la respuesta. El sistema mostrará tres botones en el formulario

- Anterior: Navega a la pregunta anterior de la ejecución según el orden que corresponda al alumno. Cuando se encuentre en la primera pregunta, este botón no se mostrará.

- Siguiente: Navega a la pregunta anterior de la ejecución

según el orden que corresponda al alumno. Cuando se encuentre en la última pregunta, este botón no se mostrará.

- Cancelar: Finaliza la revisión del examen por parte del

alumno y ocasiona la salida del formulario.

Salidas N/A

Errores N/A

Page 83: Ingenieria de Software II.pdf

Ingeniería del Software II

83

83

CMMJ - Tlf: (+34) 000 000 000

3.2.9. Corrección de exámenes

Se incluyen en este apartado los requisitos identificados vinculados con las tareas genéricas

de la aplicación relacionadas con la corrección de de exámenes.

Id y nombre del requisito RF-EVA-001. Evaluación de exámenes: Tipo TEST

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la ejecución de exámenes actores que representen a usuarios de tipo PROFESOR. Un profesor solo podrá acceder y corregir las ejecuciones de examen de cuya convocatoria sea responsable. El actor podrá realizar ese proceso tantas veces como desee a lo largo del tiempo sobre una misma convocatoria siempre y cuando queden ejecuciones por corregir, disponiendo así de la posibilidad de avanzar en las tareas de corrección según vayan siendo entregadas las ejecuciones por parte de los alumnos. Al actor se le facilitará la búsqueda de sus convocatorias y tras seleccionar una, además de mostrarle la información relevante de la misma, se recopilará y ofrecerá un listado con todas las ejecuciones vinculadas a aquella disponibles para ser corregidas. El contenido del conjunto de ejecuciones disponibles para ser corregidas dependerá del momento en el que se realice la acción de corregir. Si se realiza antes de que finalice el plazo de vigencia de la convocatoria, el conjunto estará compuesto las ejecuciones que hayan sido entregadas por parte de los alumnos. Por el contrario, si la acción se realiza una vez expirado el plazo de disponibilidad de la convocatoria, el conjunto estará constituido por todas las ejecuciones vinculadas a la convocatoria no procesadas con anterioridad. El sistema proveerá de un botón corregir mediante el cual se evaluarán de forma automática el contenido recopilado en el conjunto. Calculará y asignará calificación a todas las ejecuciones cuyo estado sea EN CURSO y ENTREGADO y transitándolas al estado CORREGIDO, mientras que las que se encuentren en estado PENDIENTE simplemente serán actualizadas al estado NO PRESENTADO, quedándose sin

Page 84: Ingenieria de Software II.pdf

Ingeniería del Software II

84

84

CMMJ - Tlf: (+34) 000 000 000

puntuación. Cuando todas las ejecuciones de la convocatoria hayan sido sometidas al proceso de calificación, la convocatoria se considerará completada y no podrá ser nuevamente sometida a un proceso de corrección. El cálculo de la calificación se realizará a partir del los criterios de valoración y, si procede, penalización definidos en el modelo de examen empleado en la convocatoria. Tras completar la acción de corrección el sistema le mostrará al actor el número de exámenes totales, procesados, corregidos y no presentados de la convocatoria.

Entradas - Identificador de sesión

Secuencia de operación Se comprueba que el actor puede realizar la acción de evaluar ejecuciones de examen aplicando la funcionalidad recogida en el punto RF-SEG-005 y sabiendo que esta solo se encuentra habilitada para usuario de tipo PROFESOR. Al actor se le facilitará la búsqueda de convocatorias replicando la funcionalidad descrita en el RF-CNV-002, mediante la cual podrá designar la convocatoria sobre la cual desea realizar la corrección, sin embargo no podrá designar aquellas convocatorias que dispongan de fecha de corrección y por lo tanto no dispongan de ejecuciones pendientes de evaluar. El sistema compondrá y mostrará en un formulario no editable con los datos de la convocatoria correspondientes a asignatura, tipo de examen, categoría y plazos. A continuación el sistema realizará una búsqueda de las ejecuciones vinculadas a la convocatoria seleccionada aplicando una estrategia de búsqueda diferente en función del momento en el que se esté realizando la acción. Si se realiza ANTES de que finalice el plazo de vigencia de la convocatoria, se aplicará un criterio de filtrado que recopile solo aquellas ejecuciones de examen cuyo estado sea ENTREGADO, dejando por tanto fuera de esta selección al conjunto de ejecuciones que aun se puedan encuentran en proceso de realización por parte de los alumnos. Por el contrario, si la acción se realiza una vez expirado el plazo de disponibilidad de la convocatoria, se entiende que todas las ejecuciones no corregidas previamente se encuentran en disposición de ser evaluadas, por lo que únicamente se dejarán fuera de este conjunto las ejecuciones que muestren un estado CORREGIDO.

Page 85: Ingenieria de Software II.pdf

Ingeniería del Software II

85

85

CMMJ - Tlf: (+34) 000 000 000

El sistema mostrará dos botones, uno para salir y otro que permitirá invocar la calificación automática de todas las ejecuciones vinculadas. Cuando el actor pulsa el botón corregir el sistema actuará de la siguiente manera en función del estado de la ejecución en función del estado de la ejecución:

- PENDIENTE: Su estado será actualizado a NO

PRESENTADO y no se consignará puntuación.

- EN CURSO: El sistema calculará su calificación y su estado será actualizado a CORREGIDO.

- ENTREGADO: El sistema calculará su calificación y su estado será actualizado a CORREGIDO.

Para el cálculo del puntaje a asignar a cada ejecución de examen, el sistema aplicará las pautas de valoración y, si procede, penalización, tanto generales como específicas por pregunta, consignadas en el modelo de examen empleado en la convocatoria. La puntuación resultante de la calificación de una ejecución de examen no podrá ser menor que 0. En cualquier caso, el profesor podrá acceder de forma individual a una ejecución de examen concreta y consignar los comentarios que considere oportunos a nivel de ejecución de examen. Cuando como consecuencia de la corrección de las ejecuciones vinculadas a la convocatoria, el sistema determine que no quedan ejecuciones pendientes de ser corregidas, procederá a actualizar la convocatoria con una marca de tiempo en el campo fecha de corrección de la convocatoria, inhabilitándola para ser sometida a un nuevo proceso de corrección. Así, el proceso de corrección actualizará por tanto la siguiente información

Por convocatoria: - Fecha de corrección de la convocatoria (si procede)

Por ejecución del alumno: - Estado - Calificación (si procede) - Comentarios del profesor (si procede)

Por respuesta del alumno - Calificación de la respuesta (si procede)

Page 86: Ingenieria de Software II.pdf

Ingeniería del Software II

86

86

CMMJ - Tlf: (+34) 000 000 000

Tras completar la acción de corrección el sistema le mostrará al actor el número de exámenes totales, procesados, corregidos y no presentados de la convocatoria. Finalmente, se refrescará el listado de ejecuciones mostrado por pantalla pudiéndose visualizar el nuevo estado y calificación de las ejecuciones.

Salidas - Mensaje - Datos de la convocatoria actualizados - Datos de la ejecución de examen actualizados - Datos de las respuestas del examen actualizadas.

Errores En caso de cualquier casuística que evite la actualización de los datos, se mostrará un error informando y se cancelará la acción.

Id y nombre del requisito RF-EVA-002. Evaluación de exámenes: Tipo DESARROLLO

Tipo Requisito Restricción

Versión 1.0

Fuente del requisito FP

Prioridad del requisito Alta/Esencial Media/Deseado

Baja/ Opcional

Especificación El sistema permite la ejecución de exámenes actores que representen a usuarios de tipo PROFESOR. La especificación de este requisito es gemela a descrita en RF-EVA-001 excepto en las acciones relativas específicamente a la propia corrección. A diferencia de aquel punto, el sistema NO proveerá de un botón de corrección automática de todas las ejecuciones disponibles para ser corregidas, sino que el proceso de corrección estará constituido de dos partes, una automática y otra manual. La parte automática permitirá llevar a cabo la evaluación de las ejecuciones no realizadas por el alumno, pudiéndose completar a través del correspondiente botón. Esta arte simplemente asignará el estado NO PRESENTADO a las ejecuciones que cumplan los criterios para ser consideradas como tal, descritos con anterioridad en el RF-EVA-001. Por su parte, el componente manual requerirá del acceso y evaluación de las ejecuciones completadas total o parcialmente por parte del alumno. Le evaluación manual de una ejecución consistirá en la revisión de todas y cada una de las respuestas, consignadas o no por parte del alumno, en la ejecución del examen y otorgarle puntuación según el criterio del profesor

Page 87: Ingenieria de Software II.pdf

Ingeniería del Software II

87

87

CMMJ - Tlf: (+34) 000 000 000

evaluador. Tras asignar puntuación a todas ellas, el profesor podrá confirmar la calificación resultante, momento en el cual la ejecución se considerará completada, reflejándose esta circunstancia a través de su estado. Tras pulsar el botón de salir y antes de cerrar el formulario, el sistema le mostrará al actor el número de evaluaciones completadas y el de pendientes.

Entradas - Identificador de sesión

Secuencia de operación Dado que la secuencia de operaciones de este requisito es compartida con el RF-EVA-001, se va exponer únicamente las partes en las que se observan diferencias. En cualquier caso, se recomienza al lector que repase la especificación del RF-EVA-001, sobre todo en lo que respecta a las consideraciones sobre los criterios a aplicar para la selección del conjunto de evaluaciones disponibles para evaluar y sus dependencias con el periodo de disponibilidad de la convocatoria y el momento en el que se esté realizando la corrección. El actor no dispondrá de un botón corregir como el presente en el RF-EVA-001. Sin embargo, cuando el momento en el que esté realizando la corrección sea posterior al momento de cierre de la convocatoria, si tendrá a su alcance un botón “cerrar no presentados” cuyo comportamiento será el mismo que el definido para el botón “corregir” en el RF-EVA-001, sin embargo, su ámbito de afectación quedará acotado el conjunto de evaluaciones que reflejen el estado PENDIENTE. El listado puesto a disposición del actor para la corrección manual de las ejecuciones solo permitirá el acceso a las ejecuciones cuyo estado sea ENTEGADO o EN CURSO, de tal forma que el actor sólo podrá realizar la evaluación del conjunto de ejecuciones que reflejen este estado. Al acceder a una ejecución para su evaluación, el sistema mostrará en un formulario los datos del alumno que ha realizado la ejecución, las características principales de la evaluación a la que pertenece la ejecución, así como el estado de la propia ejecución. De forma similar a la descrita en el RF-EJE-002, el actor podrá acceder y desplazarse por el conjunto de preguntas que conforman el modelo de examen y visualizar las respuestas consignadas por el alumno. Adicionalmente, se mostrará una campo para que pueda consignar la calificación a cada pregunta, mostrando un valor 0 por defecto. El desplazamiento hacia adelante o hacia atrás sobre el conjunto de preguntas supondrá el almacenamiento automático en la respuesta correspondiente de la puntuación consignada por el profesor.

Page 88: Ingenieria de Software II.pdf

Ingeniería del Software II

88

88

CMMJ - Tlf: (+34) 000 000 000

Al alcanzar la última pregunta, el sistema mostrará un botón para cerrar la calificación del examen. Al pulsarlo, el sistema mostrará al actor un formulario donde se mostrará la suma de las puntuaciones consignadas y le posibilitara la inclusión de observaciones sobre la ejecución. Tras esta confirmación se asignará la puntuación totalizada a la ejecución del examen y se actualizará su estado, que pasará a ser CORREGIDO, cerrándose el formulario de corrección y volviendo al formulario anterior con la convocatoria el conjunto de ejecuciones correspondientes. Tras cualquier acción de corrección realizada por el actor se correspondiente a la parte automática o manual, el listado de ejecuciones actualizará su contenido con la información actual.

Salidas - Mensaje - Datos de la convocatoria actualizados - Datos de la ejecución de examen actualizados - Datos de las respuestas del examen actualizados.

Errores En caso de cualquier casuística que evite la actualización de los datos, se mostrará un error informando y se cancelará la acción.

Page 89: Ingenieria de Software II.pdf

Ingeniería del Software II

89

89

CMMJ - Tlf: (+34) 000 000 000

3.3. Requisitos no funcionales

3.3.1. Requisitos de rendimiento

Por determinar, si bien, se estima que el rendimiento deberá ser aquel que permita calificar la experiencia del usuario de la aplicación como ágil.

3.3.2. Seguridad

El sistema garantizará el acceso exclusivo a la aplicación de usuarios registrados y habilitados, mediante la interposición de controles de acceso por usuario y password y verificación de capacidad de acceso. El sistema almacenara en archivos de log todos los accesos e intentos de acceso, guardando la fecha, hora, dirección ip desde la que se ha realizado el acceso, usuario de acceso y resultado del acceso.

3.3.3. Fiabilidad

A definir por parte del cliente.

3.3.4. Disponibilidad

El establecimiento de umbrales de disponibilidad y su correspondiente evaluación no entra dentro del ámbito de este proyecto.

3.3.5. Mantenibilidad

Dado el cariz evolutivo del proyecto planteado de cara a futuras ampliaciones, se considera

necesario que la facilidad de mantenimiento y adaptación a futuros requisitos derivados de

la incorporación de nuevos módulos sea alta.

3.3.6. Otros requisitos

El sistema deberá cumplir con los establecido en la Ley Orgánica 15/1999 de Protección de datos de carácter personal.

Page 90: Ingenieria de Software II.pdf

Ingeniería del Software II

90

90

CMMJ - Tlf: (+34) 000 000 000

4. Apéndices

4.1. Modelo de requisitos

4.1.1. Diagramas de casos de uso

Dado el nivel de detalle que se ha querido abarcar en la práctica, el diagrama de casos de uso se ha construido en diferentes partes. La secuencia en la que se incluyen en el documento trata de seguir un orden lógico que facilite su manejo y comprensión, ya que existen referencias de uso entre algunos de ellos.

4.1.1.1. Seguridad

El diagrama de seguridad representa el control de sesiones, el control de acceso y

visibilidad de funciones, así como el purgado de sesiones inactivas.

Page 91: Ingenieria de Software II.pdf

Ingeniería del Software II

91

91

CMMJ - Tlf: (+34) 000 000 000

4.1.1.2. Usuarios

El diagrama de usuarios comprende todas las situaciones vinculadas con el

mantenimiento de usuarios incluyendo la autorización de usuarios.

Page 92: Ingenieria de Software II.pdf

Ingeniería del Software II

92

92

CMMJ - Tlf: (+34) 000 000 000

4.1.1.3. Categorías

El diagrama de categorías comprende todas las situaciones vinculadas con el

mantenimiento de categorías.

Page 93: Ingenieria de Software II.pdf

Ingeniería del Software II

93

93

CMMJ - Tlf: (+34) 000 000 000

4.1.1.4. Asignaturas

El diagrama de asignatura comprende todas las situaciones vinculadas con el

mantenimiento de asignaturas, incluyendo la asignación de profesores y la matriculación

y des-matriculación de alumnos.

Page 94: Ingenieria de Software II.pdf

Ingeniería del Software II

94

94

CMMJ - Tlf: (+34) 000 000 000

4.1.1.5. Preguntas

El diagrama de preguntas comprende todas las situaciones vinculadas con el

mantenimiento de preguntas.

4.1.1.6. Modelos de examen

El diagrama de preguntas comprende todas las situaciones vinculadas con el

mantenimiento de modelos de examen, incluyendo la exportación/impresión de modelos.

Page 95: Ingenieria de Software II.pdf

CMMJ - Tlf: (+34) 000 000 000

Page 96: Ingenieria de Software II.pdf

Ingeniería del Software II

96

CMMJ - Tlf: (+34) 000 000 000

4.1.1.7. Convocatorias

El diagrama de convocatorias comprende todas las situaciones vinculadas con el

mantenimiento de convocatorias, incluyendo la notificación a los alumnos afectados.

Recordamos que las convocatorias no se pueden editar.

Page 97: Ingenieria de Software II.pdf

Ingeniería del Software II

97

CMMJ - Tlf: (+34) 000 000 000

4.1.1.8. Ejecuciones

El diagrama de ejecuciones comprende todas las situaciones vinculadas con el acceso y

realización de ejecuciones de examen por parte de un alumno, incluyendo la notificación

a los alumnos que completan una ejecución.

Page 98: Ingenieria de Software II.pdf

Ingeniería del Software II

98

98

CMMJ - Tlf: (+34) 000 000 000

4.1.1.9. Corrección de exámenes

El diagrama de ejecuciones comprende todas las situaciones vinculadas con el acceso y

corrección de ejecuciones de examen por parte de un profesor. Destacar en este caso

que los procesos de corrección de exámenes tipo TEST y tipo DESARROLLO, aun

teniendo una parte común en su inicio, son bastante diferentes en cuanto a su

mecánica.

Page 99: Ingenieria de Software II.pdf

Ingeniería del Software II

99

99

CMMJ - Tlf: (+34) 000 000 000

4.1.2. Especificación de casos de uso

4.1.2.7. RF-EXA-001. Mantenimiento de modelos de examen: alta.

La creación y edición de modelos de examen se ha planteado como un wizard en la que

el profesor podrá ir seleccionando los elementos que definirán el modelo.

Tras completar la especificación, el sistema busca aleatoriamente el conjunto de

preguntas que cumplen sus especificaciones y las somete a su aprobación.

RF-EXA-001 Mantenimiento de modelos de examen: alta

Versión 1.0 2015/11/10

Autores FP

Fuentes N/A

Objetivos asociados Crear modelos de examen

Descripción El sistema deberá comportarse tal como se describe en el caso de uso cuando el usuario quiera crear un modelo de examen nuevo

Precondición El actor debe haberse autenticado ante el sistema.

Paso Acción

Secuencia normal 1

El usuario solicita al sistema comenzar el proceso de creación de un nuevo modelo de examen

2

El sistema comprueba que el usuario puede realizar la acción de crear modelos de examen aplicando el caso de uso "Acceder a funcionalidad" (RF-SEG-005) y sabiendo que esta solo se encuentra habilitada para usuarios de tipo PROFESOR.

3

El sistema solicita al usuario que seleccione el tipo de examen que desea crear, dándole la opción de seleccionar entre dos opciones "TEST" y "DESARROLLO"

4 El sistema muestra los botones "Siguiente" y "Abandonar" al usuario

5 El usuario selecciona el tipo de examen que desea crear

6 El usuario pincha en el botón "Siguiente"

7

El sistema solicita al usuario que introduzca el nombre del modelo de examen que desea crear

8

El sistema muestra los botones "Anterior", "Siguiente" y "Abandonar" al usuario

Page 100: Ingenieria de Software II.pdf

Ingeniería del Software II

100

100

CMMJ - Tlf: (+34) 000 000 000

9

El usuario proporciona al sistema el nombre del modelo de examen que desea crear

10 El usuario pincha en el botón "Siguiente"

11 El sistema solicita al usuario que especifique el ámbito de las preguntas de la auto-selección mediante la especificación de un conjunto de asignaturas y/o categorías a las que acotar dicha selección.

12 El sistema permite al usuario establecer los criterios el ámbito de las preguntas mediante la realización del caso de uso "Establecer ámbito de preguntas"

13

El sistema muestra los botones "Anterior", "Siguiente" y "Abandonar" al usuario

14 El usuario pulsa el botón "Siguiente"

15

El sistema solicita al usuario que indique el número de preguntas que va a contener el modelo de examen.

16

El sistema muestra los botones "Anterior", "Siguiente" y "Abandonar" al usuario

17

El usuario introduce el número de preguntas que va a contener el modelo de examen

18 El usuario pulsa el botón "Siguiente"

19

El sistema solicita al usuario que indique el tiempo en minutos del que va a disfrutar el alumno para la realización del examen.

20

El sistema muestra los botones "Anterior", "Siguiente" y "Abandonar" al usuario

21 El usuario introduce el tiempo en minutos del que va a constar el examen.

22 El usuario pulsa el botón "Siguiente"

23

El sistema solicita al usuario que indique el valor por defecto de las preguntas.

24

El sistema muestra los botones "Anterior", "Siguiente" y "Abandonar" al usuario

25

El sistema permite al usuario introducir el valor por defecto de las preguntas mediante la realización del caso de uso "Establecer valoración por defecto".

26 El usuario pulsa el botón "Siguiente"

27

Si el tipo de examen seleccionado por el usuario fue TEST, se realizan los siguientes pasos

Paso Acción

27.1

El sistema solicita al usuario que indique si quiere aplicar criterios de penalización de resta en grupo y/o resta en blanco.

27.2

Si el usuario contesta afirmativamente, el sistema permite al usuario establecer los criterios de penalización mediante la realización del caso de uso "Establecer criterios de penalización por defecto"

Page 101: Ingenieria de Software II.pdf

Ingeniería del Software II

101

101

CMMJ - Tlf: (+34) 000 000 000

28

El sistema muestra los botones "Anterior", "Seleccionar preguntas" y "Abandonar" al usuario

29 El usuario pulsa el botón "Seleccionar preguntas"

30

El sistema realiza la selección automática de preguntas del modelo de examen mediante la realización del caso de uso "Seleccionar automáticamente preguntas", que básicamente consiste en una búsqueda automática sobre la batería de preguntas propiedad del usuario, recopilando tantas preguntas únicas como el número indicado por el usuario en el paso 17, del tipo consistente con el tipo del examen indicado por el usuario en el paso 9 y que se encuentren asignadas a alguna de las categorías si se han suministrado y a alguna de las asignaturas si se han suministrado, consignadas por el usuario en el paso 12.

31

El sistema permitirá al usuario la evaluación de las preguntas seleccionadas mediante la realización del caso de uso "Evaluar pregunta". Por la interés de este de cara a la creación del modelo de examen, se incluye su especificación a continuación

32

El sistema mostrará al usuario la primera de las preguntas de la selección realizada pendiente de aprobar.

33 El sistema permite al usuario redefinir opcionalmente el valor específico para la pregunta mediante la realización del caso de uso "Establecer valoración por pregunta".

34

Si el usuario no redefine el valor específico de la pregunta, el sistema le asignará el valor por defecto indicado por el usuario en el paso 24.

35

Si el tipo de examen seleccionado por el usuario fue TEST, se realizan los siguientes pasos

Paso Acción

35.1

Si se han incluido criterios de penalización, el sistema solicita al usuario que indique si desea realizar la redefinición de los criterios de penalización de forma específica para la pregunta.

35.2

Si el usuario contesta afirmativamente, el sistema permite al usuario la redefinición de forma individual en la pregunta de los criterios establecidos en el paso 27.2, mediante la realización del caso de uso "Establecer criterios de penalización por pregunta"

35.3

En caso contrario, la pregunta es asignada con los criterios de penalización que hayan sido establecidos por defecto en el paso 27.2

36

El sistema muestra los botones "Aprobar", "Aprobar todas", "Rechazar" y "Abandonar" al usuario.

37 Si el usuario pulsa el botón "Rechazar", se realizan los siguientes pasos

Paso Acción

Page 102: Ingenieria de Software II.pdf

Ingeniería del Software II

102

102

CMMJ - Tlf: (+34) 000 000 000

37.1

El sistema descarta la pregunta y realiza la selección automática de una nueva pregunta mediante la realización del caso de uso "Seleccionar automáticamente preguntas", que pasará a formar parte del conjunto de preguntas por aprobar. La nueva pregunta seleccionada no podrá estar en el conjunto de preguntas ya seleccionado ni en el conjunto de preguntas ya rechazadas.

37.2 El sistema volverá al paso 32.

38

Si el usuario pulsa el botón "Aprobar todas", se realizan los siguientes pasos

Paso Acción

38.1

El sistema considerará aprobadas todas las preguntas de la selección aun pendientes de aprobar asignándoles los criterios de valoración y penalización por defecto, pasando a conformar todas ellas el modelo de examen.

38.2 El sistema avanzará al paso 40

39 Si el usuario pulsa el botón "Aprobar", se realizan los siguientes pasos

Paso Acción

39.1

El sistema considerará aprobada la pregunta y esta pasa a formar parte de la evaluación.

39.2

Si quedan preguntas del conjunto por aprobar, el sistema volverá al paso 32.

40 El sistema muestra los botones "Crear modelo" y "Cancelar"

41 El usuario pulsa el botón "Crear modelo"

42

El sistema almacena el modelo de examen con las especificaciones suministradas por el usuario.

43

El sistema muestra al usuario una notificación de confirmación informándole del éxito del proceso

44 El usuario confirma la visualización de la notificación.

45

El sistema cierra el caso de uso y redirige al usuario a la pantalla principal de la aplicación.

Postcondición El sistema ha registrado un nuevo modelo de examen vinculado al profesor que ha realizado la acción

Excepciones Paso Acción

2 El usuario no dispone de una sesión activa en el sistema

E2.1.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E2.1.2 El sistema abortará la ejecución del caso de uso y desconectará al usuario de la aplicación.

2 El usuario no dispone de permisos para crear convocatorias

E2.2.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E2.2.2 El sistema aborta la ejecución del caso de uso.

Page 103: Ingenieria de Software II.pdf

Ingeniería del Software II

103

103

CMMJ - Tlf: (+34) 000 000 000

6 El usuario no ha seleccionado el tipo de examen a crear.

E6.1.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E6.1.2 El sistema impide el desplazamiento hasta que el usuario no

incluya un nombre para el modelo de examen

10 El usuario no ha facilitado un nombre para el modelo de examen

E10.1.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E10.1.2 El sistema impide el desplazamiento hasta que el usuario no

haya seleccionado un tipo de examen.

14

El usuario no ha definido el ámbito para la posterior selección de preguntas.

E14.1.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E14.1.2

El sistema impide el desplazamiento hasta que el usuario no establezca al menos un valor para, al menos, uno de los dos criterios de acotación contemplados en el ámbito.

18 El usuario no ha facilitado un valor numérico entero mayor que 0 para definir el número de preguntas.

E18.1.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E18.1.2 El sistema impide el desplazamiento hasta que el usuario no

incluya un valor numérico entero mayor que 0.

26

El usuario no ha facilitado un valor numérico entero o decimal mayor que 0 para definir el valor por defecto de cada pregunta.

E26.1.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E26.1.2 El sistema impide el desplazamiento hasta que el usuario no

incluya un valor numérico entero o decimal mayor que 0.

27.2

El usuario ha indicado que desea emplear el criterio de penalización borrar en blanco, pero el valor de penalización no es un valor numérico entero o decimal mayor que 0.

E27-2.1.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E27-1.1.2 El sistema impide el desplazamiento hasta que el usuario no

incluya un valor numérico entero o decimal mayor que 0.

30

El usuario no dispone del volumen de preguntas suficientes que cumplan las especificaciones establecidas en el modelo en construcción

E30.1.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E30.1.2 El sistema no permitirá la creación del caso de uso en el paso final.

33 El usuario no ha facilitado un valor numérico entero o decimal mayor que 0 para definir el valor específico de una pregunta.

Page 104: Ingenieria de Software II.pdf

Ingeniería del Software II

104

104

CMMJ - Tlf: (+34) 000 000 000

E33.1.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E33.1.2

El sistema impide cualquier acción, excepto la cancelación del caso de uso, hasta que el usuario no incluya un valor numérico entero o decimal mayor que 0.

35.2

El usuario ha redefinido los valores de trabajo en alguno de los criterios de penalización empleados, pero el valor no es numérico entero o decimal mayor que 0.

E35-1.1.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia y del criterio de penalización afectado.

E35-1.1.2

El sistema impide el desplazamiento hasta que el usuario no incluya un valor numérico entero o decimal mayor que 0 en el criterio de penalización específico establecido que ha generado el error.

37.1 El usuario no dispone del volumen de preguntas suficientes que cumplan las especificaciones establecidas en el modelo en construcción

E37-1.1.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E37-1.1.2 El sistema cancela el rechazo de la pregunta y no permite

rechazar más durante el resto del caso de uso.

Frecuencia esperada Baja

Importancia Muy importante

Comentarios

Por cuestiones de claridad, se ha optado por incluir la secuencia normal de ejecución del caso de uso "Aprobar pregunta", cuya especificación se desarrolla de los pasos 31 a 42. El modo de interrogación al usuario tendrá el formato de WIZARD hasta el punto en el que el usuario pulsa el botón "Seleccionar preguntas"

4.1.1.7. RF-CNV-001. Mantenimiento de convocatorias: alta.

RF-EXA-001 Mantenimiento convocatorias: alta

Versión 1.0 2015/11/10

Autores FP

Fuentes N/A

Objetivos asociados Crear convocatorias de examen

Page 105: Ingenieria de Software II.pdf

Ingeniería del Software II

105

105

CMMJ - Tlf: (+34) 000 000 000

Descripción El sistema deberá comportarse tal como se describe en el caso de uso cuando el usuario quiera crear una convocatoria de examen.

Precondición El actor debe haberse autenticado ante el sistema.

Paso Acción

Secuencia normal 1

El usuario solicita al sistema comenzar el proceso de creación de una nueva convocatoria de examen

2

El sistema comprueba que el usuario puede realizar la acción de crear modelos de examen aplicando el caso de uso "Acceder a funcionalidad" (RF-SEG-005) y sabiendo que esta solo se encuentra habilitada para usuarios de tipo PROFESOR.

3

El sistema solicita al usuario que defina las características de la convocatoria a crear, facilitándole la búsqueda de los elementos ya catalogados en el sistema de su propiedad o .vinculados a él mediante los botones "Buscar modelo de examen", "Buscar asignatura" y "Buscar categoría"

4

El sistema muestra los botones "Crear convocatoria" y "Abandonar" al usuario.

5

El usuario desea introducir los datos del modelo de examen a utilizar en la convocatoria y pulsa el botón "Buscar modelo de examen"

6 El sistema permite al usuario la búsqueda del modelo de examen a utilizar en la convocatoria mediante la realización del caso de uso "Buscar modelo de examen"

7

El usuario desea introducir la asignatura en la que va a crear la convocatoria y pulsa el botón "Buscar asignatura"

8

El sistema permite al usuario la búsqueda de la asignatura a la que asignar la convocatoria mediante la realización del caso de uso "Buscar asignatura"

9

El usuario desea asignar una categoría a la convocatoria y pulsa el botón "Buscar categoría"

10

El sistema permite al usuario la búsqueda de la categoría a asignar a la convocatoria mediante la realización del caso de uso "Buscar categoría"

11

El usuario incluye las fechas de inicio y fin de disponibilidad de la convocatoria.

12 El usuario pulsa el botón "Crear convocatoria"

13 El sistema localiza a todos los alumnos que se encuentran matriculados en la asignatura sobre la que se está creando la convocatoria y envía un correo electrónico a cada uno de ellos informándole de esta circunstancia.

14 Si alguno de los envíos falla, el sistema guarda temporalmente los datos del alumno afectado por el envió fallado.

Page 106: Ingenieria de Software II.pdf

Ingeniería del Software II

106

106

CMMJ - Tlf: (+34) 000 000 000

15

El sistema almacena la nueva convocatoria, así como también genera y almacena por cada alumno matriculado en la asignatura afectada una copia del examen a realizar. Las preguntas y respuestas (si procede) de la copia de cada alumno se dispondrán en un orden único de cada copia, empleando el sistema para el cálculo de esta secuencia de orden una función determinista que tome como semilla el identificador del alumno.

16

El sistema muestra al usuario una notificación de confirmación informándole del éxito del proceso, así como la relación almacenada previamente de aquellos alumnos a los que no se ha podido notificar, permitiendo al usuario imprimir esta relación.

17 El usuario confirma la visualización de la notificación.

18

El sistema cierra el caso de uso y redirige al usuario a la pantalla principal de la aplicación.

Postcondición El sistema ha registrado una nueva convocatoria de examen, ha preparado y generado las copias a realizar por los alumnos matriculados en la asignatura y los ha notificado sobre la presencia de una nueva convocatoria que los afecta.

Excepciones Paso Acción

2 El usuario no dispone de una sesión activa en el sistema

E2.1.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E2.1.2 El sistema abortará la ejecución del caso de uso y desconectará al usuario de la aplicación.

12 La fecha de fin del periodo de disponibilidad es anterior a la fecha de inicio.

E12.1.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E12.1.2

El sistema impedirá la creación del caso de uso hasta que el usuario no establezca consistentemente las fechas del intervalo de disponibilidad.

12

La duración del intervalo de disponibilidad definido es inferior al tiempo de realización definido en el modelo de examen.

E12.2.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E12.2.2

El sistema impedirá la creación del caso de uso hasta que el usuario no establezca consistentemente las fechas del intervalo respecto al tiempo de realización del examen.

12 Las fechas de inicio o fin del intervalo de disponibilidad no tienen un formato válido.

E12.3.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E12.3.2 El sistema impedirá la creación del caso de uso hasta que las fechas sean correctas.

12 El usuario no ha asignado dato del modelo de examen, asignatura o plazo de disponibilidad.

Page 107: Ingenieria de Software II.pdf

Ingeniería del Software II

107

107

CMMJ - Tlf: (+34) 000 000 000

E12.4.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E12.4.2 El sistema impedirá la creación del caso de uso hasta que el

usuario establezca los datos que faltan.

Frecuencia esperada Media

Importancia Muy importante

Comentarios La realización de los casos de uso "Buscar modelo de examen", "Buscar asignatura" y "Buscar categoría" contempla la acotación en las búsquedas a los elementos propiedad o asignados al usuario que está creando la convocatoria. Las fechas que definen los límites del intervalo de disponibilidad se pueden establecer con una precisión de minutos.

4.1.1.7. RF-CNV-001. Mantenimiento de convocatorias: alta.

RF-EJE-001 Ejecución de exámenes: ejecución

Versión 1.0 2015/11/10

Autores FP

Fuentes N/A

Objetivos asociados Ejecutar convocatorias de examen

Descripción El sistema deberá comportarse tal como se describe en el caso de uso cuando el usuario quiera ejecutar una convocatoria de examen.

Precondición El actor debe haberse autenticado ante el sistema.

Paso Acción

Secuencia normal 1

El usuario solicita al sistema comenzar el proceso de ejecución de una convocatoria de examen.

2

El sistema comprueba que el usuario puede realizar la acción de realizar ejecuciones de examen aplicando el caso de uso "Acceder a funcionalidad" (RF-SEG-005) y sabiendo que esta solo se encuentra habilitada para usuarios de tipo ALUMNO.

3

El sistema realizará una búsqueda de las convocatorias que afectan al usuario mediante la realización del caso de uso "Buscar convocatoria".

4

Por cada convocatoria localizada, el sistema localizará la información relativa a la ejecución realizada por el alumno sobre la convocatoria.

Page 108: Ingenieria de Software II.pdf

Ingeniería del Software II

108

108

CMMJ - Tlf: (+34) 000 000 000

5

El sistema mostrará al usuario un listado con los datos localizados, mostrándole la información de la asignatura de la convocatoria, el tipo de modelo de examen, la ventana de disponibilidad, el plazo para su realización y el estado de la ejecución realizada por el alumno hasta el momento.

6

El usuario seleccionara la convocatoria cuya ejecución desea comenzar o retomar.

7

El sistema recopila la información de la ejecución vinculada a la convocatoria seleccionada por el alumno.

8 El sistema abre un formulario de ejecución donde se muestra la información relevante de la convocatoria en ejecución, incluyendo el tiempo restante para la realización de la convocatoria.

9

En función del estado de la ejecución, el sistema realizará alternativamente alguno de esto pasos:

Paso Acción

9.1

Si el estado de la ejecución es PENDIENTE, el sistema mostrará la primera pregunta de la copia del examen generada para el alumno.

9.2

Si estado de la ejecución es EN CURSO, el sistema mostrará la pregunta de la copia del examen en la que se encuentre la ejecución.

10

El sistema actualiza el estado de la ejecución del examen del alumno al estado "EN CURSO"

11

El sistema realizará de forma recurrente el caso de uso "Comprobar tiempos", que consiste en que el sistema pone en marcha un contador de tiempo y cuando este alcance un umbral establecido, actúa de la siguiente manera:

Paso Acción

11.1

El sistema almacenará la ejecución en el estado en el que se encuentre en ese momento, incluyendo la respuesta a la pregunta en curso, el número de orden de la pregunta en curso y acumulará el tiempo del contado al totalizador de tiempo consumido en la ejecución del examen.

11.2

Si el tiempo acumulado en el totalizador de tiempo de la ejecución supera el plazo de tiempo establecido en el modelo del examen, el sistema modificará el estado del examen a "ENTREGADO", generará un mensaje de estado sobre la circunstancia ocurrida y el caso de uso continuara en el paso 15.

Page 109: Ingenieria de Software II.pdf

Ingeniería del Software II

109

109

CMMJ - Tlf: (+34) 000 000 000

11.3

Si el momento en el que se alcance el umbral establecido fuese posterior a la ventana de disponibilidad de la convocatoria, el sistema modificará el estado del examen a "ENTREGADO", generará un mensaje de estado sobre la circunstancia ocurrida y el caso de uso continuara en el paso 15.

11.4

Si no se dan ninguna de las situaciones expresadas en los dos pasos anteriores, el sistema realiza un nuevo caso de uso "Comprobar tiempos".

12 En función del número de orden de la pregunta mostrada, el sistema mostrará una serie de botones para que el usuario pueda navegar entre las preguntas y gestionar la ejecución del examen:

Paso Acción

12.1

Si el numero de orden de la pregunta es 1, el sistema mostrará los botones "Siguiente" y "Salir"

12.2

Si el número de orden de la pregunta se corresponde con el número total de preguntas que constituyen el examen, el sistema mostrará los botones "Anterior", "Salir" y "Entregar"

12.3

En el resto de números de orden, el sistema mostrará los botones "Anterior", "Salir" y "Siguiente"

13

En función del tipo de del modelo de examen, TEST o DESARROLLO, el habilitará un modelo de respuesta diferente.

Paso Acción

13.1

Si el modelo del examen es tipo TEST, el sistema permitirá al alumno que conteste mediante la realización del caso de uso "Responder pregunta TEST".

13.2

Si el modelo del examen es tipo DESARROLLO, el sistema permitirá al alumno que conteste mediante la realización del caso de uso "Responder pregunta DESARROLLO".

14

En función de la disponibilidad de botones y del botón pulsado por el usuario, el sistema actuará de una de las siguientes maneras:

Paso Acción

14.1

Si el usuario pulsa el botón "Salir", el sistema almacenara la ejecución en curso en el estado en el que se encuentre en el momento en el que el usuario haya pulsado el botón, incluyendo la respuesta a la pregunta en curso, el número de orden de la pregunta en curso y el tiempo consumido, saltando la ejecución al paso 15

14.2

Si el usuario pulsa el botón "Anterior", el sistema almacenara la ejecución en curso en el estado en el que se encuentre en el momento en el que el usuario haya pulsado el botón, incluyendo la respuesta a la pregunta en curso, el tiempo consumido y estableciendo que la pregunta en curso es la pregunta inmediatamente anterior a la pregunta en la que el usuario ha pulsado el botón anterior.

Page 110: Ingenieria de Software II.pdf

Ingeniería del Software II

110

110

CMMJ - Tlf: (+34) 000 000 000

14.3

Si el usuario pulsa el botón "Siguiente", el sistema almacenara la ejecución en curso en el estado en el que se encuentre en el momento en el que el usuario haya pulsado el botón, incluyendo la respuesta a la pregunta en curso, el tiempo consumido y estableciendo que la pregunta en curso es la pregunta inmediatamente posterior a la pregunta en la que el usuario ha pulsado el botón “Anterior”.

14.4

Si el usuario pulsa el botón "Entregar" el sistema almacenara la ejecución en curso incluyendo la respuesta a la pregunta en curso, el tiempo consumido y actualizará el estado de la ejecución a "ENTREGADO", generará un mensaje informativo sobre saltando la ejecución al paso 15.

15 El sistema mostrará para que el usuario confirme el mensaje informativo generado en los pasos 11.2, 11.3, 14.1 o 14.4.

16 El usuario confirma la visualización de la notificación.

17

El sistema cierra el caso de uso y redirige al usuario a la pantalla principal de la aplicación.

Postcondición El sistema ha registrado la ejecución total o parcial de una convocatoria de un alumno, quedando igualmente registradas las respuestas consignadas por el alumno durante la ejecución.

Excepciones Paso Acción

2 El usuario no dispone de una sesión activa en el sistema

E2.1.1

El sistema mostrará un mensaje informándole al usuario de esta circunstancia

E2.1.2 El sistema abortará la ejecución del caso de uso y desconectará al usuario de la aplicación.

Frecuencia esperada Alta

Importancia Muy importante

Comentarios La realización del caso de uso "Buscar convocatoria" contempla la acotación en las búsquedas a las convocatorias de asignaturas en las que se encuentra matriculado el alumno, cuyo periodo de disponibilidad haya comenzado y no haya expirado y cuyo estado sea PENDIENTE o EN CURSO. Por cuestiones de claridad, se ha optado por incluir la secuencia normal de ejecución del caso de uso "Comprobar tiempo", cuya especificación se desarrolla en el paso 11. El umbral de tiempo contra el que se realiza la comprobación será un parámetro de la aplicación.

Page 111: Ingenieria de Software II.pdf

Ingeniería del Software II

111

111

CMMJ - Tlf: (+34) 000 000 000

Page 112: Ingenieria de Software II.pdf

Ingeniería del Software II

112

CMMJ - Tlf: (+34) 000 000 000

4.2. Modelo de análisis

4.2.1. Diagramas de clases

Al igual que en el modelado de casos de uso, el diagrama de clases se ha construido en diferentes partes e igualmente, la secuencia en la que se incluyen en el documento trata de seguir un orden lógico que facilite su manejo y comprensión. Dado que el desarrollo del interfaz gráfico no se ha asumido como parte del proyecto, en primera instancia se muestra la batería de servicios que conforman la aplicación y sus respectivas implementaciones, para pasar a continuación a mostrar el modelado de las entidades funcionales lógicas que componen el sistema y las relaciones existentes en ellos.

Page 113: Ingenieria de Software II.pdf

Ingeniería del Software II

113

113

CMMJ - Tlf: (+34) 000 000 000

4.2.1.7. Servicios

Page 114: Ingenieria de Software II.pdf

Ingeniería del Software II

114

114

CMMJ - Tlf: (+34) 000 000 000

Page 115: Ingenieria de Software II.pdf

Ingeniería del Software II 115

CMMJ - Tlf: (+34) 000 000 000

4.2.1.8. Usuarios

Page 116: Ingenieria de Software II.pdf

Ingeniería del Software II 116

CMMJ - Tlf: (+34) 000 000 000

4.2.1.9. Seguridad

Page 117: Ingenieria de Software II.pdf

Ingeniería del Software II 117

117

CMMJ - Tlf: (+34) 000 000 000

4.2.1.10. Matriculaciones

Page 118: Ingenieria de Software II.pdf

Ingeniería del Software II 118

118

CMMJ - Tlf: (+34) 000 000 000

4.2.1.11. Preguntas

Page 119: Ingenieria de Software II.pdf

Ingeniería del Software II 119

119

CMMJ - Tlf: (+34) 000 000 000

4.2.1.12. Modelos

Page 120: Ingenieria de Software II.pdf

Ingeniería del Software II 120

120

CMMJ - Tlf: (+34) 000 000 000

Page 121: Ingenieria de Software II.pdf

Ingeniería del Software II 121

121

CMMJ - Tlf: (+34) 000 000 000

4.2.1.13. Convocatorias

Page 122: Ingenieria de Software II.pdf

Ingeniería del Software II 122

122

CMMJ - Tlf: (+34) 000 000 000

4.1.1.7. Ejecuciones

Page 123: Ingenieria de Software II.pdf

Ingeniería del Software II 123

123

CMMJ - Tlf: (+34) 000 000 000

4.1.1.8. Correcciones

Page 124: Ingenieria de Software II.pdf

Ingeniería del Software II 124

124

CMMJ - Tlf: (+34) 000 000 000

4.1.1.9. UI

En este diagrama se incluyen solamente las clases que son han quedado sin desarrollar.

Page 125: Ingenieria de Software II.pdf

Ingeniería del Software II

125

CMMJ - Tlf: (+34) 000 000 000

4.1.2. Diagramas de secuencia

Con el objetivo es dotar de una visión completa del proceso de ejecutar exámenes desde

sus inicios, los diagramas de secuencia que se han seleccionado para representar son los

siguientes:

Alta de un modelo de examen tipo test

Alta de una convocatoria test

Ejecución de un examen tipo test

Sin embargo, en todos ellos se hacen uso de funcionalidades o referencias a diagramas de

secuencia que si bien no son el objeto de este apartado, dotan de mayor conocimiento

sobre lo que hará el sistema al lector. Por este motivo, se incluirán en primera instancia los

diagramas auxiliares para, a continuación, mostrar los tres diagramas objeto de la práctica.

La secuencia en la que se incluyen los diagramas auxiliares en el documento trata de seguir

el mismo criterio de continuidad lógica empleado en puntos anteriores.

Page 126: Ingenieria de Software II.pdf

Ingeniería del Software II

126

126

CMMJ - Tlf: (+34) 000 000 000

4.1.2.7. Comprobar sesión

Comprueba y mantiene el estado de una sesión de usuario.

4.1.1.7. Solicitar dato

Representa el ciclo de mostrar y adquirir un dato en el interfaz gráfico, incluyendo la

validación de la sesión cuando el usuario confirma el dato.

Page 127: Ingenieria de Software II.pdf

Ingeniería del Software II

127

127

CMMJ - Tlf: (+34) 000 000 000

Page 128: Ingenieria de Software II.pdf

Ingeniería del Software II 128

CMMJ - Tlf: (+34) 000 000 000

4.1.1.8. Comprobar acceso

Muestra la secuencia que valida cada acción que pretende realizar el usuario en el sistema. Implícitamente se realiza la

validación de la sesión del usuario.

Comprueba si la acción solicitada se encuentra autorizada para el usuario actor.

Page 129: Ingenieria de Software II.pdf

Ingeniería del Software II 129

129

CMMJ - Tlf: (+34) 000 000 000

4.1.1.7. Inicio o continuación de ejecución

Muestra la secuencia de acciones que tienen lugar cuando un usuario accede a una ejecución para realizarla.

En primera instancia, se invoca instancia al iterador que, por un lado, ordena las preguntas del examen de forma única, pero

consistente para el mismo usuario entre distintos accesos, empleando un algoritmo de ordenación determinista que tome

como semilla un dato único del usuario. Su segunda misión es mantener facilitar la navegación entre las preguntas y facilitar

los métodos de control correspondientes para que le interfaz sepa qué botones de navegación mostrar.

Posteriormente se evalúa y se actualiza el estado de la ejecución, ya que los usuarios pueden empezarlas y dejarlas siempre

que quieran.

Por último, es en este diagrama donde también tiene lugar la inicialización del autoguardador de la ejecución.

Page 130: Ingenieria de Software II.pdf

Ingeniería del Software II 130

130

CMMJ - Tlf: (+34) 000 000 000

Page 131: Ingenieria de Software II.pdf

Ingeniería del Software II 131

131

CMMJ - Tlf: (+34) 000 000 000

4.1.1.7. Guardado de ejecución

Este diagrama muestra la secuencia de acciones que tienen lugar cuando se produce un guardado de la ejecución,

independientemente de quien lo invoque.

Page 132: Ingenieria de Software II.pdf

Ingeniería del Software II 132

132

CMMJ - Tlf: (+34) 000 000 000

Page 133: Ingenieria de Software II.pdf

Ingeniería del Software II 133

133

CMMJ - Tlf: (+34) 000 000 000

4.1.1.8. Auto guardado de la ejecución

Muestra la secuencia que se ejecuta para el autoguardado de la ejecución cuando un usuario accede a ella para trabajarla.

Page 134: Ingenieria de Software II.pdf

Ingeniería del Software II 134

134

CMMJ - Tlf: (+34) 000 000 000

4.1.1.9. Crear modelo tipo TEST

Page 135: Ingenieria de Software II.pdf

Ingeniería del Software II 135

135

CMMJ - Tlf: (+34) 000 000 000

Page 136: Ingenieria de Software II.pdf

Ingeniería del Software II 136

136

CMMJ - Tlf: (+34) 000 000 000

Page 137: Ingenieria de Software II.pdf

Ingeniería del Software II 137

137

CMMJ - Tlf: (+34) 000 000 000

Page 138: Ingenieria de Software II.pdf

Ingeniería del Software II 138

138

CMMJ - Tlf: (+34) 000 000 000

Page 139: Ingenieria de Software II.pdf

Ingeniería del Software II 139

139

CMMJ - Tlf: (+34) 000 000 000

Page 140: Ingenieria de Software II.pdf

Ingeniería del Software II 140

140

CMMJ - Tlf: (+34) 000 000 000

4.1.1.7. Crear convocatoria

Page 141: Ingenieria de Software II.pdf

Ingeniería del Software II 141

141

CMMJ - Tlf: (+34) 000 000 000

Page 142: Ingenieria de Software II.pdf

Ingeniería del Software II 142

142

CMMJ - Tlf: (+34) 000 000 000

Page 143: Ingenieria de Software II.pdf

Ingeniería del Software II 143

143

CMMJ - Tlf: (+34) 000 000 000

Page 144: Ingenieria de Software II.pdf

Ingeniería del Software II 144

144

CMMJ - Tlf: (+34) 000 000 000

4.1.1.7. Ejecutar examen tipo TEST

Page 145: Ingenieria de Software II.pdf

Ingeniería del Software II 145

145

CMMJ - Tlf: (+34) 000 000 000

Page 146: Ingenieria de Software II.pdf

Ingeniería del Software II 146

146

CMMJ - Tlf: (+34) 000 000 000

Page 147: Ingenieria de Software II.pdf

Ingeniería del Software II 147

147

CMMJ - Tlf: (+34) 000 000 000

Page 148: Ingenieria de Software II.pdf

Ingeniería del Software II 148

148

CMMJ - Tlf: (+34) 000 000 000

Page 149: Ingenieria de Software II.pdf

Ingeniería del Software II 149

149

CMMJ - Tlf: (+34) 000 000 000

Page 150: Ingenieria de Software II.pdf

Ingeniería del Software II 150

CMMJ - Tlf: (+34) 000 000 000

4.1.2. Diagramas de paquetes

Page 151: Ingenieria de Software II.pdf

Ingeniería del Software II

151

CMMJ - Tlf: (+34) 000 000 000

4.2. Modelo de análisis

4.2.1. Diagramas de estado

4.2.1.7. Convocatoria

Page 152: Ingenieria de Software II.pdf

Ingeniería del Software II

152

152

CMMJ - Tlf: (+34) 000 000 000

4.2.1.8. Ejecución

4.2.1.9. Usuario

Page 153: Ingenieria de Software II.pdf

Ingeniería del Software II

153

153

CMMJ - Tlf: (+34) 000 000 000

4.2.2. Diagramas de actividades

4.2.2.7. Alta usuario

4.1.1.7. Crear convocatoria

Page 154: Ingenieria de Software II.pdf

Ingeniería del Software II

154

154

CMMJ - Tlf: (+34) 000 000 000

4.1.1.7. Corregir ejecuciones tipo TEST.

Page 155: Ingenieria de Software II.pdf

Ingeniería del Software II

155

155

CMMJ - Tlf: (+34) 000 000 000

Page 156: Ingenieria de Software II.pdf

Ingeniería del Software II

156

156

CMMJ - Tlf: (+34) 000 000 000

4.1.2. Patrones de diseño

4.1.2.7. Singleton

El patrón singleton es un patrón de diseño diseñado para restringir la creación de

objetos pertenecientes a una clase o el valor de un tipo a un único objeto.

Su intención consiste en garantizar que una clase sólo tenga una instancia y

proporcionar un punto de acceso global a ella.

Se implementa creando en nuestra clase un método que crea una instancia del objeto

sólo si todavía no existe alguna y asegurando que la clase no pueda ser nuevamente

regulando la visibilidad del constructor con modificadores como protegido o privado.

El patrón de diseño singleton podría emplearse en la clase SessionManager que

detenta el almacenamiento y gestión de las sesiones de los usuarios.

4.1.2.8. Facade

Dado que el sistema en diseño está arquitecturizado bajo la forma de un conjunto de

componentes que poseen sus propia interfaces como:

• El componente Modelos:

o ModelService

o QuestionService

o CategoryService.

• El componente Exámenes:

o CorrectionService

o CallService

o ExecutionService

o

• El componente Matrículas

o SubjectService

o EnrollmentService

Page 157: Ingenieria de Software II.pdf

Ingeniería del Software II

157

157

CMMJ - Tlf: (+34) 000 000 000

• El componente Seguridad

o SessionService

o SecurityService

• El componente Usuarios

o UserService

La clase UIController podría ser implementada bajo el patrón facade que ofrece una

interfaz unificada, sencilla y común. Este patrón queda definido por la existencia de un

interfaz de servicios con un nivel más elevado de abstracción que, por un lado, no

expone los servicios de los componentes del sistema que no son necesarios desde el

punto de vista de la web y por otro, aporta unos servicios con un mayor nivel de

abstracción o mayor carga lógica articulados a través del acceso a uno o varios de los

servicios expuestos por los interfaces de los componentes.

4.1.2.9. Iterator

El acceso a las preguntas de cada ejecución de examen debe poder realizarse de forma

secuencial, permitiendo la recuperación de la pregunta en curso así como la navegación

hacia adelante y hacia atrás sobre el conjunto. Además, las preguntas (y sus

respuestas) deben ser proporcionadas en un orden único para cada alumno.

El desplazamiento por dichas preguntas se podría realizar mediante la implementación

de un patrón Iterator. Este patrón proporciona una solución que pueda ser configurada

según el tipo de elementos que componen la colección.

Sin embargo, en nuestro diseño, las preguntas deben ser ordenadas de forma única en

cada ejecución. Esta ordenación única se aportaría de forma desacoplada mediante un

interfaz que exponga un método para ordenación. La clase que implemente este

interfaz, deberá garantizar un orden único y consistente (determinista) para los

elementos de la lista.

Presentamos por tanto dos clases abstractas genéricas:

• Iterador es una clase abstracta genérica que incluye los métodos de control de

desplazamiento

• SortedIteratorProvider es a su vez una clase abstracta genérica que incluye los

métodos que crean, inicializan y devuelven una instancia de Iterador.

Y un interfaz para la implementación de la función de ordenación deseada.

Page 158: Ingenieria de Software II.pdf

Ingeniería del Software II

158

158

CMMJ - Tlf: (+34) 000 000 000

• Sortable es un interfaz que expone un método sort.

A continuación es posible crear las subclases concretas de estas dos clases abstractas

genéricas, subclases que relacionan en particular los parámetros de genericidad con los

tipos utilizados en la aplicación, así como una clase concreta que implemente el interfaz

de ordenación y que realice la ordenación deseada.

Se ha incluido una superclase SortableElement de la que deberían heredar todos los

elementos que deseen ser empleados en la ordenación. No olvidemos que estamos

componiendo un patrón iterator ligeramente modificado para que se garantice una

ordenación determinada.

4.2. Modelo de desarrollo e implantación

Page 159: Ingenieria de Software II.pdf

Ingeniería del Software II 159

CMMJ - Tlf: (+34) 000 000 000

4.2.1. Diagramas de componentes

Page 160: Ingenieria de Software II.pdf

Ingeniería del Software II

160

CMMJ - Tlf: (+34) 000 000 000

4.2.2. Diagramas de despliegue