Plataforma Web para la Gesión Integral de Conferencias Científico-Técnicas

UNIVERSIDAD DE OVIEDO

ESCUELA POLITÉCNICA DE INGENIERÍA DE GIJÓN

PROYECTO FIN DE CARRERA

"PLATAFORMA WEB PARA LA GESTIÓN INTEGRAL

DE CONFERENCIAS CIENTÍFICO-TÉCNICAS"

DIRECTOR: José Ranilla Pastor

Raquel Cortina Parajón

AUTOR: Héctor Arroyo Santiago

JULIO 2015

MEMORIA PRESENTADA POR

D. HÉCTOR ARROYO SANTIAGO

PARA OPTAR AL TÍTULO DE

INGENIERO TÉCNICO (en Informática de Sistemas)

Agradecimientos

Me gustaría agradecer el trabajo de mis directores de proyecto, Raquel y José, por su ayuda

durante el desarrollo y redacción del mismo, así como a la organización del CMMSE por la

oportunidad que ha supuesto y la confianza depositada en mí.

También quisiera agradecer el apoyo e interés mostrados por mi familia y amigos, cuyas

sugerencias y opiniones han inspirado parte de este proyecto.

Resumen

El presente proyecto tiene como finalidad el desarrollo de un sistema para la gestión de

conferencias científico-técnicas basado en una interfaz web. En particular, la implementación

realizada tiene como objeto la gestión de la 14th International Conference on Computational

and Mathematical Methods in Science and Engineering, que se celebró del 3 al 7 de julio de 2014

en Rota (Cádiz).

La aplicación desarrollada surge a partir de la necesidad de remplazar otra aplicación web

existente, y cubre todos los aspectos principales de la gestión de la conferencia, desde el registro

de los asistentes y el envío de los papers a presentar, hasta la generación de facturas,

justificantes de pago, asistencia y presentación de ponencias, además del envío de

notificaciones por correo electrónico tanto a los asistentes como a los gestores de la misma.

También cubre otros aspectos administrativos, como la generación de estadísticas y listados, la

verificación de pagos y envíos o la gestión de aspectos logísticos, como la disponibilidad de salas

durante el evento o la preparación de etiquetas identificativas de distintos tipos para los

asistentes y el personal.

Para el desarrollo de la interfaz se han utilizado tecnologías web actuales, como HTML5, jQuery

y AJAX, que mejoran la experiencia de los usuarios de la aplicación y minimizan los tiempos de

respuesta; mientras que para implementar la lógica de la aplicación en el lado del servidor se

han utilizado patrones de diseño de software modular ampliamente extendidos y componentes

de amplio uso, teniendo en cuenta y simplificando posibles ampliaciones futuras de la aplicación

resultante.

Además, la aplicación ha sido desarrollada a medida para ejecutarse sobre un servidor Linux,

teniendo en cuenta las particularidades del congreso a gestionar y del entorno hardware y

software disponible.

Palabras Clave

Conferencia

Simposio

Paper

Gestión de Pagos

MVC

ORM

PHP

MySQL

Abstract

This work aims to develop a web-based system for managing scientific-technical conferences.

Specifically, the implementation discussed here is targeted on the 14th International Conference

on Computational and Mathematical Methods in Science and Engineering, held on July 3-7 in

Rota (Cádiz).

The proposed system arises from the need to replace an existing web application, and covers all

major aspects involved on the conference management duties, including from registration of

attendees and papers submission to automatic generation of documentation, such as invoices,

proofs of payment, certificates of attendance and papers presentation, besides sending e-mail

notifications both to attendees and staff members. It also covers other administrative duties,

such as collecting and displaying of statistics and listings, payment handling and various logistics

including availability of rooms during the event or preparation of tags of different types for

attendees and staff members.

The application user interface is built on top of current web technologies, including HTML5 and

AJAX, allowing both a better user experience and lower response times; while the backend has

been engineered using widely used software design patterns and widespread third-party

libraries, thus making easy further improvements and simplifying the overall application

architecture.

In addition, the application has been explicitly developed to run on a Linux server and meet the

CMMSE organizers’ needs, taking into account the features of the CMMSE conference and the

hardware and software environment available on the web server used.

Keywords

Conference

Symposium

Paper

Payment Management

MVC

ORM

PHP

MySQL

Í ndice General

1 PRESENTACION ............................................................................................................................ 17

2 MEMORIA DEL PROYECTO ........................................................................................................... 18

2.1 HOJA DE IDENTIFICACIÓN ................................................................................................................. 18

2.2 TECNOLOGÍAS, PROTOCOLOS Y CONCEPTOS CLAVE ................................................................................ 19

2.2.1 Introducción al protocolo HTTP ............................................................................................ 19

2.2.2 Introducción a HTML............................................................................................................. 21

2.2.3 Introducción a AJAX .............................................................................................................. 24

2.2.4 Introducción a CSS y CSS3 ..................................................................................................... 24

2.2.5 El patrón de diseño MVC....................................................................................................... 26

2.2.6 Introducción a PHP ............................................................................................................... 28

2.2.7 Los sistemas de plantillas para web ..................................................................................... 29

2.3 OBJETO ........................................................................................................................................ 31

2.4 ANTECEDENTES ............................................................................................................................. 31

2.5 NORMAS Y REFERENCIAS.................................................................................................................. 31

2.5.1 Disposiciones legales y normas aplicadas ............................................................................ 31

2.5.2 Métodos, herramientas, modelos, métricas y prototipos ..................................................... 33

2.5.3 Mecanismos de control de calidad aplicados durante la redacción del proyecto ................ 37

2.5.4 Otras referencias .................................................................................................................. 39

2.6 ALCANCE ...................................................................................................................................... 40

2.7 HIPÓTESIS Y RESTRICCIONES ............................................................................................................. 40

3 PLANIFICACIÓN Y PRESUPUESTO ................................................................................................. 41

3.1 PLANIFICACIÓN TEMPORAL ............................................................................................................... 41

3.2 RESUMEN DEL PRESUPUESTO ............................................................................................................ 47

3.3 PRESUPUESTO ............................................................................................................................... 48

3.3.1 Costes relativos a ingeniería ................................................................................................. 48

3.3.2 Costes relativos a bienes, equipos y servicios informáticos .................................................. 48

3.3.3 Costes relativos a consumibles ............................................................................................. 48

3.3.4 Costes relativos a aplicaciones informáticas ........................................................................ 49

4 ESPECIFICACIÓN DEL SISTEMA ..................................................................................................... 50

4.1 DESCRIPCIÓN DE LA SITUACIÓN ACTUAL .............................................................................................. 50

4.2 REQUISITOS INICIALES ..................................................................................................................... 50

4.3 ESTUDIOS DE ALTERNATIVAS Y VIABILIDAD ........................................................................................... 51

4.3.1 Sistemas existentes de gestión de conferencias ................................................................... 51

4.3.2 Gestores de bases de datos .................................................................................................. 52

4.3.3 Servidores web ...................................................................................................................... 54

4.3.4 Lenguajes de programación ................................................................................................. 57

4.3.5 Frameworks .......................................................................................................................... 59

4.3.6 Sistemas de plantillas ........................................................................................................... 60

4.4 DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA .......................................................................................... 61

4.5 ACTORES DEL SISTEMA .................................................................................................................... 63

4.6 CATÁLOGO DE REQUISITOS NO FUNCIONALES ....................................................................................... 64

4.6.1 Requisitos tecnológicos ......................................................................................................... 64

4.6.2 Requisitos de seguridad ........................................................................................................ 65

4.6.3 Requisitos de auditoría (instrumentación) ........................................................................... 65

4.6.4 Requisitos de tiempo de respuesta ....................................................................................... 65

4.7 ANÁLISIS DE REQUISITOS FUNCIONALES ............................................................................................... 66

4.7.1 Aspectos generales ............................................................................................................... 66

4.7.2 Seguridad .............................................................................................................................. 66

4.7.3 Pagos .................................................................................................................................... 67

4.7.4 Simposios .............................................................................................................................. 68

4.7.5 Envío de papers ..................................................................................................................... 68

4.7.6 Salas ...................................................................................................................................... 69

4.7.7 Envío de notificaciones por correo electrónico ..................................................................... 69

4.7.8 Generación de calendarios ................................................................................................... 70

4.7.9 Información estadística ........................................................................................................ 70

4.7.10 Limitación de acceso ........................................................................................................ 71

4.7.11 Generación de documentación ......................................................................................... 71

4.7.12 Excursiones ....................................................................................................................... 72

4.8 ESPECIFICACIÓN DE CASOS DE USO Y ESCENARIOS.................................................................................. 73

4.8.1 Acciones de invitado ............................................................................................................. 73

4.8.2 Acciones comunes ................................................................................................................. 76

4.8.3 Acciones de ponente ............................................................................................................. 80

4.8.4 Acciones de editor ................................................................................................................. 86

4.8.5 Gestión de usuarios .............................................................................................................. 87

4.8.6 Gestión de pagos (general) ................................................................................................... 97

4.8.7 Gestión de facturas ............................................................................................................. 100

4.8.8 Gestión de justificantes de pago ......................................................................................... 106

4.8.9 Gestión de simposios .......................................................................................................... 108

4.8.10 Gestión de salas.............................................................................................................. 111

4.8.11 Gestión de excursiones ................................................................................................... 113

4.8.12 Gestión de papers ........................................................................................................... 114

4.8.13 Configuración de la aplicación ....................................................................................... 120

4.8.14 Información estadística .................................................................................................. 126

5 DISEÑO E IMPLEMENTACIÓN ..................................................................................................... 129

5.1 PARTICIONAMIENTO FÍSICO DE SUBSISTEMAS ..................................................................................... 129

5.2 IMPLEMENTACIÓN DE FUNCIONALIDADES DINÁMICAS DE LA INTERFAZ DE ADMINISTRACIÓN ........................ 131

5.2.1 cmmse.admin ..................................................................................................................... 132

5.2.2 cmmse.admin.json .............................................................................................................. 132

5.2.3 cmmse.admin.users ............................................................................................................ 133

5.2.4 cmmse.admin.invoices ........................................................................................................ 133

5.2.5 cmmse.admin.proofs .......................................................................................................... 134

5.2.6 cmmse.admin.papers ......................................................................................................... 134

5.2.7 cmmse.admin.papers.edittitle ............................................................................................ 134

5.2.8 cmmse.admin.papers.rooms .............................................................................................. 135

5.2.9 cmmse.admin.rooms.edittitle ............................................................................................. 135

5.2.10 cmmse.admin.conferences.edittitle ............................................................................... 135

5.2.11 cmmse.admin.conferences.editdate .............................................................................. 136

5.3 SUBSISTEMAS DE DISEÑO ............................................................................................................... 137

5.4 DISEÑO DE CLASES ........................................................................................................................ 138

5.4.1 \CMMSE .............................................................................................................................. 139

5.4.2 \CMMSE\AutoloaderData .................................................................................................. 140

5.4.3 \CMMSE\Core ..................................................................................................................... 141

5.4.4 \CMMSE\Exceptions ........................................................................................................... 162

5.4.5 \CMMSE\Traits ................................................................................................................... 164

5.4.6 \CMMSE\Doctrine ............................................................................................................... 172

5.4.7 \CMMSE\Decorators ........................................................................................................... 223

5.4.8 \Proxies ............................................................................................................................... 236

5.4.9 \CMMSE\PDFViews ............................................................................................................. 237

5.4.10 \CMMSE\PDFViews\Labels15x25 ................................................................................... 239

5.4.11 \CMMSE\PDFViews\Labels92x625 ................................................................................. 242

5.4.12 \CMMSE\Interfaces ........................................................................................................ 245

5.4.13 \CMMSE\Interfaces\Models ........................................................................................... 247

5.4.14 \CMMSE\Permissions ..................................................................................................... 272

5.4.15 \CMMSE\Models ............................................................................................................ 273

5.4.16 \CMMSE\Models\Factories ............................................................................................ 276

5.4.17 \CMMSE\Controllers ...................................................................................................... 278

5.4.18 \CMMSE\Controllers\User .............................................................................................. 284

5.4.19 \CMMSE\Controllers\Admin .......................................................................................... 292

5.4.20 \CMMSE\Controllers\Admin\JSON ................................................................................. 307

5.4.21 \CMMSE\Controllers\Admin\PDF ................................................................................... 312

5.4.22 \CMMSE\Controllers\Frontcontrollers ........................................................................... 320

5.5 DISEÑO FÍSICO DE DATOS ............................................................................................................... 324

5.5.1 Archivos estáticos internos ................................................................................................. 324

5.5.2 Archivos estáticos públicos ................................................................................................. 324

5.5.3 Archivos de usuario ............................................................................................................. 324

5.5.4 Configuración estática de la aplicación .............................................................................. 325

5.5.5 Modelo entidad-relación de la base de datos ..................................................................... 329

5.5.6 Modelo relacional de la base de datos ............................................................................... 336

5.5.7 Normalización ..................................................................................................................... 341

5.6 DISEÑO DE LA INTERFAZ DE USUARIO ................................................................................................ 347

5.6.1 Interfaz pública ................................................................................................................... 348

5.6.2 Interfaz administrativa ....................................................................................................... 349

6 MANUALES ................................................................................................................................ 351

6.1 MANUAL DE INSTALACIÓN ............................................................................................................. 351

6.1.1 Prerrequisitos ...................................................................................................................... 351

6.1.2 Instalación de la aplicación ................................................................................................. 352

6.1.3 Consideraciones de seguridad ............................................................................................ 356

6.1.4 Configuración inicial de la aplicación ................................................................................. 356

6.2 MANUAL DE USUARIO ................................................................................................................... 363

6.2.1 Registro, login y gestión de cuenta de usuario ................................................................... 363

6.2.2 Envío y gestión de papers ................................................................................................... 370

6.2.3 Gestión de pagos y datos fiscales ....................................................................................... 376

6.2.4 Acceso a los calendarios iCal .............................................................................................. 379

6.3 MANUAL DE ADMINISTRACIÓN ....................................................................................................... 381

6.3.1 Acceso a la interfaz de administración y configuración general......................................... 381

6.3.2 Gestión de salas .................................................................................................................. 382

6.3.3 Gestión de simposios .......................................................................................................... 384

6.3.4 Gestión de excursiones ....................................................................................................... 386

6.3.5 Gestión de usuarios ............................................................................................................ 388

6.3.6 Gestión de pagos: Facturas y justificantes.......................................................................... 406

6.3.7 Gestión de facturas ............................................................................................................. 409

6.3.8 Gestión de justificantes de pago ......................................................................................... 412

6.3.9 Gestión de papers ............................................................................................................... 416

6.3.10 Consulta de información estadística .............................................................................. 424

6.3.11 Registro de editores ........................................................................................................ 427

6.4 MANUAL DE EDITOR ..................................................................................................................... 428

6.4.1 Acceso a la lista de papers enviados ................................................................................... 428

6.4.2 Descarga de papers disponibles ......................................................................................... 429

6.4.3 Acceso a los calendarios iCal .............................................................................................. 429

7 PRUEBAS ................................................................................................................................... 430

7.1 PRUEBAS DE USO EN UN ENTORNO REAL ........................................................................................... 430

7.2 PRUEBAS UNITARIAS ..................................................................................................................... 430

7.2.1 Tests\Core ........................................................................................................................... 431

7.2.2 Tests\Entities ...................................................................................................................... 441

7.2.3 Tests\Entities\Doctrine ....................................................................................................... 445

7.2.4 Tests\Decorators ................................................................................................................ 454

7.2.5 Tests\Models ...................................................................................................................... 458

7.2.6 Tests\Models\Factories ...................................................................................................... 479

7.2.7 Tests\Controllers\Admin\PDF ............................................................................................. 480

8 CONCLUSIONES ......................................................................................................................... 491

9 BIBLIOGRAFÍA ............................................................................................................................ 492

9.1 LIBROS Y ARTÍCULOS ..................................................................................................................... 492

9.2 REFERENCIAS EN INTERNET ............................................................................................................ 492

Conceptos de Ingeniería de Software .............................................................................................. 492

Lenguajes y estándares web ............................................................................................................ 492

Aspectos legales y herramientas de gestión de congresos .............................................................. 493

Herramientas de gestión de software.............................................................................................. 493

Protocolo HTTP y servidores web ..................................................................................................... 494

Librerías ........................................................................................................................................... 494

Casos de prueba y automatización .................................................................................................. 495

Estadísticas ...................................................................................................................................... 495

Otros ................................................................................................................................................ 495

10 APÉNDICES ................................................................................................................................ 496

APENDICE I: ESTADÍSTICAS DE LA EDICIÓN DE 2014 ...................................................................................... 496

Estadísticas demográficas ............................................................................................................... 496

Estadísticas de rendimiento ............................................................................................................. 505

APENDICE II: AMPLIACIONES PROPUESTAS ................................................................................................... 510

Uso del autocargador de clases de Symfony ................................................................................... 510

Alternativas al sistema MVC usado ................................................................................................. 510

Mejoras funcionales generales y de planificación ........................................................................... 512

Mejoras en la gestión de documentación ........................................................................................ 512

Mejoras técnicas generales ............................................................................................................. 513

Mejoras en estadísticas, instrumentación y administración de la aplicación .................................. 514

Cambios considerados en el sistema de pagos ................................................................................ 515

Mejoras de seguridad ...................................................................................................................... 516

Otros cambios a considerar ............................................................................................................. 516

APENDICE III: CONTENIDO DEL CD-ROM ................................................................................................... 517

APENDICE IV: DEFINICIONES Y ABREVIATURAS .............................................................................................. 518

Í ndice de figuras

Figura 2.1: Diagrama cliente-servidor HTTP ......................................................................................... 20

Figura 2.2: Despliegue típico de una aplicación web utilizando un pool de procesos Apache ............... 22

Figura 2.3: Documento HTML básico .................................................................................................... 22

Figura 2.4: Ejemplo de declaración CSS ................................................................................................ 25

Figura 2.5: Arquitectura MVC tradicional ............................................................................................. 27

Figura 2.6: Arquitectura MVC jerárquica .............................................................................................. 28

Figura 2.7: Esquema de funcionamiento de un sistema de plantillas web ............................................ 30

Figura 3.1: Diagrama de Gantt de la planificación temporal del proyecto ............................................ 45

Figura 4.1: Casos de Uso para las acciones de invitado ........................................................................ 76

Figura 4.2: Casos de uso para las acciones comunes ............................................................................ 79

Figura 4.3: Casos de uso para las acciones del perfil de ponente ......................................................... 81

Figura 4.4: Casos de uso para las acciones de papers de ponente ........................................................ 83

Figura 4.5: Casos de uso para las acciones de pago de ponente ........................................................... 86

Figura 4.6: Casos de uso para las acciones de editor ............................................................................ 87

Figura 4.7: Casos de uso para las acciones de gestión de usuarios ....................................................... 89

Figura 4.8: Casos de uso para la descarga de certificados..................................................................... 91

Figura 4.9: Casos de uso para la descarga de etiquetas ........................................................................ 96

Figura 4.10: Casos de uso para la gestión general de pagos ............................................................... 100

Figura 4.11: Casos de uso para la gestión de facturas individuales ..................................................... 102

Figura 4.12: Casos de uso para la descarga de facturas ...................................................................... 104

Figura 4.13: Casos de uso para la asignación automática de los números de factura ......................... 105

Figura 4.14: Casos de uso para la gestión de justificantes .................................................................. 108

Figura 4.15: Casos de uso para la gestión de simposios ...................................................................... 110

Figura 4.16: Casos de uso para la gestión de salas.............................................................................. 112

Figura 4.17: Casos de uso para la gestión de excursiones ................................................................... 114

Figura 4.18: Casos de uso para la gestión de papers........................................................................... 117

Figura 4.19: Casos de uso de descarga de certificados y listado papers .............................................. 120

Figura 4.20: Casos de uso generales de configuración ........................................................................ 122

Figura 4.21: Casos de uso para la configuración de los números de factura ....................................... 123

Figura 4.22: Casos de uso para la configuración de acceso ................................................................. 125

Figura 4.23: Casos de uso para la verificación del envío de correos .................................................... 126

Figura 4.24: Casos de uso para la obtención de información de autores ............................................ 128

Figura 4.25: Casos de uso para la obtención de información estadística ............................................ 128

Figura 5.1: Diagrama de despliegue lógico (detalle de procesos del servidor físico) ........................... 129

Figura 5.2: Diagrama simplificado de sistemas externos usados por la aplicación.............................. 130

Figura 5.3: Diagrama UML general de los espacios de nombres de la aplicación ................................ 137

Figura 5.4: Diagrama UML de las clases utilizadas para implementar el autocargador ....................... 140

Figura 5.5: Diagrama UML de la clase ArrayCache .............................................................................. 142

Figura 5.6: Diagrama UML de las clases Configuration e EMail........................................................... 145

Figura 5.7: Diagrama UMl de la clase HTTP404DieHandler ................................................................. 146

Figura 5.8: Diagrama UML de la clase cEzPDFStreamer ...................................................................... 147

Figura 5.9: Diagrama UML de la clase MailValidator .......................................................................... 148

Figura 5.10: Diagrama UML de la clase OverviewData ....................................................................... 150

Figura 5.11: Diagrama UML de la clase ScriptStats ............................................................................. 152

Figura 5.12: Diagrama UML de las clases AbstractModel, Log4PHPQueryLogger y MySQLiWrapper .. 155

Figura 5.13: Diagrama UML de las clases usadas para implementar las vistas .................................... 158

Figura 5.14: Diagrama UML de las clases base de los controladores .................................................. 161

Figura 5.15: Diagrama UML de los tipos de excepciones de la aplicación ........................................... 163

Figura 5.16: Diagrama UML de los traits de acceso a propiedades de objeto ..................................... 166

Figura 5.17: Diagrama UML de los traits usados para generar y enviar los correos electrónicos ........ 168

Figura 5.18: Diagrama UML del trait para obtener la extensión a partir de un nombre de archivo .... 169

Figura 5.19: Diagrama UML del trait de inicialización de objetos desde instancias compatibles ........ 170

Figura 5.20: Diagrama UML de los traits de obtención de carga media del sistema y descripción de

errores de envío de archivos ..................................................................................................... 171

Figura 5.21: Diagrama UML de la entidad Conference ....................................................................... 174

Figura 5.22: Diagrama UML de la entidad InstrumentationSample .................................................... 182

Figura 5.23: Diagrama UML de la entidad MailerSettings .................................................................. 186

Figura 5.24: Diagrama UML de la entidad Paper ................................................................................ 192

Figura 5.25: Diagrama UML de la entidad PaymentSettings ............................................................... 195

Figura 5.26: Diagrama UML de la entidad PersonTitle ........................................................................ 197

Figura 5.27: Diagrama UML de la entidad Poster ............................................................................... 200

Figura 5.28: Diagrama UML de la entidad Room ................................................................................ 202

Figura 5.29: Diagrama UML de la entidad Session .............................................................................. 204

Figura 5.30: Diagrama UML de la entidad Settings ............................................................................. 210

Figura 5.31: Diagrama UML de la entidad Trip ................................................................................... 212

Figura 5.32: Diagrama UML de la entidad User .................................................................................. 217

Figura 5.33: Diagrama UML de la entidad UserBillingInfo .................................................................. 222

Figura 5.34: Diagrama UML de los decoradores Autor y PagoUsuario ................................................ 224

Figura 5.35: Diagrama UML del decorador Conference ...................................................................... 226

Figura 5.36: Diagrama UML de los decoradores Paper, Poster y Room .............................................. 231

Figura 5.37: Diagrama UML del decorador Settings ........................................................................... 233

Figura 5.38: Diagrama UML del decorador UserBilling ....................................................................... 235

Figura 5.39: Diagrama UML de ejemplo para el proxy generado a partir de la entidad Room ............ 236

Figura 5.40: Diagrama UML de las vistas usadas para generar las etiquetas ...................................... 238

Figura 5.41: Diagrama UML de las interfaces principales ................................................................... 246

Figura 5.42: Diagrama UML general de las interfaces de los modelos ................................................ 247

Figura 5.43: Diagrama UML de la interfaz del modelo del listado de autores ..................................... 248

Figura 5.44: Diagrama UML de la interfaz del modelo de gestión de facturacion ............................... 251

Figura 5.45: Diagrama UML de la interfaz del modelo de gestión de simposios ................................. 253

Figura 5.46: Diagrama UML de la interfaz del modelo de instrumentación ........................................ 254

Figura 5.47: Diagrama UML de la interfaz del modelo del listado de facturas y justificantes ............. 255

Figura 5.48: Diagrama UML de la interfaz del modelo de inicio de sesión .......................................... 257

Figura 5.49: Diagrama UML de la interfaz del modelo de gestión de papers ...................................... 260

Figura 5.50: Diagrama UML de la interfaz del modelo de gestión de pagos........................................ 262

Figura 5.51: Diagrama UML de la interfaz del modelo de gestión de salas ......................................... 264

Figura 5.52: Diagrama UML de la interfaz del modelo de gestión de sesiones ................................... 265

Figura 5.53: Diagrama UML de la interfaz del modelo de configuración ............................................. 267

Figura 5.54: Diagrama UML de la interfaz del modelo de gestión de estadísticas .............................. 268

Figura 5.55: Diagrama UML de la interfaz del modelo de gestión de excursiones .............................. 269

Figura 5.56: Diagrama UML de la interfaz del modelo de gestión de usuarios.................................... 271

Figura 5.57: Diagrama UML de la clase que comprueba si la sesión posee permisos administrativos 272

Figura 5.58: Diagrama UML de la factoría de modelos ....................................................................... 277

Figura 5.59: Diagrama UML de los controladores de las acciones de invitado y editores ................... 278

Figura 5.60: Diagrama UML de los controladores de gestión de papers de las páginas de usuario .... 285

Figura 5.61: Diagrama UML de los controladores de gestión de perfil de las páginas de usuario ....... 291

Figura 5.62: Diagrama UML de los controladores principales de administración................................ 295

Figura 5.63: Diagrama UML de los controladores de las acciones AJAX .............................................. 308

Figura 5.64: Diagrama UML de los controladores PDF de la sección de administración ...................... 313

Figura 5.65: Diagrama UML de los Frontcontrollers ........................................................................... 323

Figura 5.66: Modelo entidad-relación general ................................................................................... 329

Figura 5.67: Modelo entidad-relación de los usuarios y los títulos honoríficos .................................. 330

Figura 5.68: Modelo entidad-relación de los datos de facturación de los usuarios ............................. 331

Figura 5.69: Modelo entidad-relación de papers, posters, simposios y salas ...................................... 332

Figura 5.70: Modelo entidad-relación de las excursiones ................................................................... 332

Figura 5.71: Modelo entidad-relación de las muestras de instrumentación ....................................... 333

Figura 5.72: Modelo entidad-relación de los datos de configuración ................................................. 335

Figura 5.73: Modelo relacional de las tablas de usuarios, papers y conferencias ............................... 337

Figura 5.74: Modelo relacional de las tablas de posters, salas y excursiones ..................................... 338

Figura 5.75: Modelo relacional de la tabla de facturación .................................................................. 338

Figura 5.76: Modelo relacional de las tablas de configuración ........................................................... 339

Figura 5.77: Modelo relacional de las tablas de sesiones e instrumentación ...................................... 340

Figura 5.78: Modelo entidad-relación normalizado de usuarios ......................................................... 342

Figura 5.79: Modelo entidad-relación normalizado de papers, posters, salas y simposios ................. 344

Figura 5.80: Modelo entidad-relación normalizado de los datos de facturación ................................ 345

Figura 5.81: Modelo entidad-relación normalizado de los parámetros de configuración ................... 346

Figura 5.82: Distribución de las pantallas de la interfaz pública ......................................................... 348

Figura 5.83: Distribución general de las pantallas de la interfaz de administración ............................ 349

Figura 5.84: Pantalla de administración con una fila seleccionada y una acción AJAX en curso .......... 350

Figura 5.85: Enlace de retorno a la parte superior de la página .......................................................... 350

Figura 6.1: Copia del instalador al servidor ........................................................................................ 352

Figura 6.2: Comprobaciones iniciales durante la instalación .............................................................. 353

Figura 6.3: Copia de los archivos de la aplicación ............................................................................... 354

Figura 6.4: Finalización de la instalación ............................................................................................ 355

Figura 6.5: Página de inicio de la aplicación recién instalada ............................................................. 355

Figura 6.6: Procedimiento de cambio de la contraseña de administrador .......................................... 358

Figura 6.7: Configuración de acceso y números de factura en un entorno de producción .................. 359

Figura 6.8: Configuración de la información de la edición actual de la conferencia ............................ 360

Figura 6.9: Configuración del servidor SMTP a utilizar en un entorno de producción ......................... 361

Figura 6.10: Formulario para el envío de un correo de prueba ........................................................... 361

Figura 6.11: Salida de depuración mostrada tras el envío de un correo de prueba ............................ 362

Figura 6.12: Correo electrónico de prueba recibido en la dirección proporcionada ............................ 362

Figura 6.13: Formulario de registro de nuevo usuario ........................................................................ 363

Figura 6.14: Notificación enviada confirmando el registro ................................................................. 364

Figura 6.15: Formulario de inicio de sesión ........................................................................................ 365

Figura 6.16: Página principal de la interfaz de ponente ...................................................................... 366

Figura 6.17: Formulario de edición de datos personales .................................................................... 367

Figura 6.18: Formulario de cambio de contraseña ............................................................................. 367

Figura 6.19: Errores mostrados durante la edición del formulario de cambio de contraseña ............. 368

Figura 6.20: Error mostrado al no proporcionar correctamente la contraseña actual ........................ 368

Figura 6.21: Error mostrado cuando la nueva contraseña y su confirmación no coinciden ................. 368

Figura 6.22: Formulario para restablecer la contraseña de usuario .................................................... 369

Figura 6.23: Correo electrónico con la nueva contraseña enviado tras restablecer la misma ............. 369

Figura 6.24: Formulario para el envío de un nuevo paper .................................................................. 370

Figura 6.25: Mensaje mostrado en la página de envío de papers cuando el plazo está cerrado ......... 371

Figura 6.26: Formulario cumplimentado para el envío de un nuevo paper ........................................ 371

Figura 6.27: Formulario de envío de un nuevo paper listando un paper enviado previamente .......... 372

Figura 6.28: Página de detalle de un paper antes de entrar en proceso de revisión ........................... 373

Figura 6.29: Página de detalle de un paper tras entrar en proceso de revisión .................................. 373

Figura 6.30: Correo electrónico de confirmación enviado tras la aceptación de un paper .................. 374

Figura 6.31: Formulario de envío de nuevas versiones de papers ...................................................... 375

Figura 6.32: Formulario de envío de nuevas versiones de papers tras el envío de una revisión ......... 375

Figura 6.33: Página principal de la interfaz de gestión de pagos ........................................................ 376

Figura 6.34: Página de registro y modificación de datos fiscales y envío de justificante de pago ....... 377

Figura 6.35: Pantalla para el envío del justificante de pago antes de su envío ................................... 378

Figura 6.36: Pantalla para el envío del justificante de pago tras su envio ........................................... 378

Figura 6.37: Pantalla para el envío del justificante de pago tras la confirmación del mismo .............. 379

Figura 6.38: Calendario de inicio de los simposios ............................................................................. 380

Figura 6.39: Calendario de exposición de posters .............................................................................. 380

Figura 6.40: Calendario de exposición de posters (formato de agenda) ............................................. 380


Figura 6.42: Interfaz de gestión de salas ............................................................................................ 383

Figura 6.43: Formulario de creación de una nueva sala ..................................................................... 383

Figura 6.44: Formulario de modificación de nombre de sala .............................................................. 384

Figura 6.45: Interfaz de gestión de simposios .................................................................................... 385

Figura 6.46: Formulario de creación de un nuevo simposio ............................................................... 385

Figura 6.47: Edición del nombre de un simposio ................................................................................ 385

Figura 6.48: Edición de la fecha de inicio de un simposio ................................................................... 386

Figura 6.49: Interfaz de gestión de excursiones ................................................................................. 387

Figura 6.50: Creación de una nueva excursión ................................................................................... 387

Figura 6.51: Interfaz de gestión de usuarios ....................................................................................... 388

Figura 6.52: Listado de usuarios adaptado a un ancho de pantalla menor ......................................... 388

Figura 6.55: Listado de usuarios con usuarios seleccionados ............................................................. 389

Figura 6.56: Certificado de asistencia ................................................................................................. 390

Figura 6.57: Botones de descarga de etiquetas .................................................................................. 391

Figura 6.58: Hoja de etiquetas de asistencia (horizontales; 15 x 7,5 cm) ............................................ 392

Figura 6.59: Hoja de etiquetas de asistencia (horizontales; 9,2 x 6,25 cm) ......................................... 393

Figura 6.60: Hojas de etiquetas de asistencia (verticales) .................................................................. 394

Figura 6.61: Hoja de etiquetas de asistencia a la cena de gala (horizontales; 15 x 7,5 cm) ................. 395

Figura 6.62: Hoja de etiquetas de asistencia a la cena de gala (horizontales; 9,2 x 6,25 cm) .............. 396

Figura 6.63: Hoja de etiquetas de asistencia a excursiones (horizontales; 15 x 7,5 cm) ...................... 397

Figura 6.64: Hoja de etiquetas de asistencia a excursiones (horizontales; 9,2 x 6,25 cm) ................... 398

Figura 6.65: Hoja de etiquetas identificativas para los organizadores (horizontales; 15 x 7,5 cm) ...... 399

Figura 6.66: Hoja de etiquetas identificativas para los organizadores (horizontales; 9,2 x 6,25 cm) ... 400

Figura 6.67: Hoja de etiquetas de restaurante (horizontales; 15 x 7,5 cm) ......................................... 401

Figura 6.68: Hoja de tickets de restaurante (horizontales; 9,2 x 6,25 cm) ........................................... 402

Figura 6.69: Hoja de etiquetas en blanco (horizontales; 15 x 7,5 cm) ................................................. 403

Figura 6.70: Hoja de etiquetas en blanco (horizontales; 9,2 x 6,25 cm) .............................................. 404

Figura 6.71: Hoja de etiquetas en blanco (verticales) ......................................................................... 405

Figura 6.72: Notificación de registro de nuevo usuario ...................................................................... 406

Figura 6.73: Menú de acceso a las páginas de gestión de facturas y justificantes de pago ................. 407

Figura 6.74: Formulario de modificación de cuota de inscripción ....................................................... 408

Figura 6.75: Notificación enviada al recibir un nuevo justificante de pago ......................................... 409

Figura 6.76: Interfaz de gestión de facturas ....................................................................................... 409

Figura 6.77: Listado de usuarios con factura solicitada con usuarios seleccionados ........................... 410

Figura 6.78: Factura generada por la aplicación ................................................................................. 411

Figura 6.79: Detalle de la numeración de facturas y facturas listas para imprimir .............................. 412

Figura 6.80: Interfaz de gestión de justificantes de pago simple ........................................................ 413

Figura 6.81: Listado de usuarios con justificantes de pago simple con usuarios seleccionados ......... 414

Figura 6.82: Justificante de pago generado por la aplicación ............................................................. 415

Figura 6.83: Interfaz de gestión de los papers enviados ..................................................................... 416

Figura 6.86: Formulario de edición del ltítulo de paper ...................................................................... 417

Figura 6.87: Notificación enviada a los administradores tras el envío de un nuevo paper .................. 418

Figura 6.88: Nuevo paper listado en la página de administración antes de entrar en revisión ........... 418

Figura 6.89: Notificación enviada a los administradores tras aceptar un paper ................................. 419

Figura 6.90: Notificación enviada a los administradores tras recibir una nueva versión de un paper . 420

Figura 6.91: Formulario de edición de sala y fechas de presentación de posters ................................ 421

Figura 6.92: Listado de papers con papers seleccionados ................................................................... 422

Figura 6.93: Certificado de presentación de ponencia ........................................................................ 423

Figura 6.94: Listado de autores .......................................................................................................... 425

Figura 6.95: Enlace de descarga de la lista de autores en formato Excel ............................................ 425

Figura 6.97: Página de estadísticas agregadas .................................................................................... 426


Figura 6.99: Interfaz de editor ............................................................................................................ 429

Figura 10.1: Número de usuarios registrados por semana................................................................. 497

Figura 10.2: Número de usuarios totales en el sistema por semana ................................................... 497

Figura 10.3: Número de usuarios por país de procedencia ................................................................. 498

Figura 10.4: Número de nuevos papers enviados por semana ........................................................... 499

Figura 10.5: Número de papers totales en el sistema por semana ..................................................... 499

Figura 10.6: Número de papers aceptados por simposio .................................................................... 500

Figura 10.7: Número de solicitudes por navegador (todas las páginas) .............................................. 501

Figura 10.8: Número de solicitudes por navegador (páginas públicas) ............................................... 501

Figura 10.9: Valores muestrales (agregados) de número de solicitudes por navegador ..................... 502

Figura 10.10: Número de solicitudes por S.O. del cliente (todas las páginas) ..................................... 503

Figura 10.11: Número de solicitudes por S.O. del cliente (páginas públicas) ...................................... 503

Figura 10.12: Valores muestrales (agregados) de número de solicitudes por sistema operativo ........ 504

Figura 10.13: Número de solicitudes HTTP por semana ..................................................................... 506

Figura 10.14: Número de sesiones HTTP por semana ......................................................................... 506

Figura 10.15: Uso medio de CPU y memoria por día .......................................................................... 507

Figura 10.16: Parámetros estadísticos generales de uso de CPU, memoria y BBDD ........................... 508

Figura 10.17: Media de tiempo y memoria empleados para generar las páginas ............................... 508

Figura 10.18: Grado absoluto de relación lineal existente entre el uso de CPU y de memoria ........... 509

Figura 10.19: Grado relativo de relación lineal existente entre el uso de CPU y de memoria ............. 509

PresentacIon | Plataforma web para la gestión de conferencias científico-técnicas

Escuela Politécnica de Ingeniería - Universidad de Oviedo | Héctor Arroyo Santiago 17

1 PRESENTACION

El presente proyecto tiene como objetivo el desarrollo y puesta en producción de una aplicación web

para la gestión de una conferencia científico-técnica sobre la aplicación de métodos matemáticos en

problemas de ciencia e ingeniería. La aplicación desarrollada tiene como finalidad la gestión completa

del registro de ponentes, envío de artículos, generación de facturas y recolección de estadísticas,

poniendo especial énfasis en los aspectos relativos al rendimiento, portabilidad y modularidad de sus

componentes.

Este proyecto surge con el objetivo de remplazar una aplicación web existente que la organización

venía utilizando en ediciones anteriores del congreso y teniendo como uno de sus objetivos que se

ejecute sobre un servidor Linux. Para ello se ha realizado un estudio de las funcionalidades cubiertas

por la aplicación original, además de considerar e implementar numerosas mejoras relativas a la

usabilidad, a los tiempos de respuesta de la aplicación y al uso de componentes software actuales,

utilizando librerías de código abierto (open source) como base para la implementación de las diferentes

funcionalidades cubiertas.

De esta forma, se dispone de una aplicación flexible y modular, construida sobre componentes

software ampliamente testados por diferentes comunidades de desarrolladores de aplicaciones tanto

open source como privativas, y que tiene en cuenta y posibilita la implementación de nuevas

funcionalidades con relativa facilidad.

Plataforma web para la gestión de conferencias científico-técnicas | Memoria del proyecto

18 Héctor Arroyo Santiago | Escuela Politécnica de Ingeniería - Universidad de Oviedo

2 MEMORIA DEL PROYECTO

2.1 Hoja de identificación

Plataforma web para la gestión integral de conferencias científico-técnicas.

Cliente:

o International Conference on Computational and Mathematical Methods in Science and

Engineering.

Suministrador:

o Héctor Arroyo Santiago.

Mayo 2015

Resumen: Desarrollo de una aplicación web para la gestión de la 14th International Conference

on Computational and Mathematical Methods in Science and Engineering.

Duración estimada: Octubre 2013 – Mayo 2015.

Coste estimado: 22.685 €

Memoria del proyecto | Plataforma web para la gestión de conferencias científico-técnicas


2.2 Tecnologías, protocolos y conceptos clave

En este apartado se dispone de una introducción a algunas de las tecnologías y conceptos cuyo

conocimiento resulta de capital importancia para comprender el resto de este documento.

2.2.1 Introducción al protocolo HTTP

El Protocolo de Transferencia de Hipertexto (HyperText Transfer Protocol) [HTTP01] es el protocolo

más usado para navegar por Internet, y define los detalles y convenios necesarios para el intercambio

de datos entre un navegador web (cliente) y el sistema que proporciona los contenidos o páginas web

(servidor). HTTP es un protocolo basado en transacciones, y sigue un esquema petición-respuesta

entre el cliente y el servidor. Se sitúa en el nivel superior de la arquitectura TCP/IP (nivel de aplicación)

y hace uso de los mecanismos estándar de TCP para proporcionar fiabilidad en la comunicación.

Un aspecto importante de HTTP es su carácter de protocolo sin estado (stateless): En general, cada

solicitud del cliente es tratada de manera independiente del resto, creando y destruyendo una

conexión dedicada entre el cliente y el servidor para ello1. El funcionamiento sin estado de HTTP es

adecuado para su uso habitual, en el que un usuario solicita una secuencia de páginas y datos asociados

a éstas en un corto intervalo de tiempo, y los contenidos solicitados se encuentran en uno o más

servidores independientes [STAL04].

Otra característica importante de HTTP es que, aunque su nombre hace referencia a la transferencia

de hipertexto, el protocolo no impone ningún tipo de restricción en cuanto al tipo de documentos que

puede gestionar: Los datos son enviados como secuencias de bytes, sin hacer distinción en el

contenido. Esto permite utilizar el mismo protocolo para enviar los contenidos vinculados a una página

web, simplificando la infraestructura necesaria [STAL04].

Tipos de solicitudes

A nivel de protocolo, HTTP define 8 tipos distintos de solicitudes, denominados métodos HTTP. Los

más comunes son GET (para solicitar un recurso a partir de su URI), HEAD (idéntico al anterior pero sin

incluir el cuerpo del documento) y POST (para guardar datos adicionales proporcionados por el cliente

como una nueva entidad subordinada del recurso web identificado por la URI proporcionada)

[SYMF01].

Tipos de respuesta

En respuesta a las solicitudes de los clientes, los servidores retornan un valor numérico de 3 dígitos

conocido como código de respuesta. Éstos se clasifican en 5 tipos denominados clases. Las clases de

respuesta HTTP son 1xx Informational (para respuestas provisionales, como las relativas a

comprobaciones previas para solicitudes posteriores), 2xx Success (que indican que una solicitud es

1 Aunque cliente y servidor pueden acordar reutilizar la misma conexión para varias solicitudes. En este caso se mantiene la conexión TCP pero no el estado previo a nivel de protocolo de aplicación.



soportada y aceptada por el servidor, y se ha procesado correctamente), 3xx Redirection (que indica

que se debe realizar una acción adicional, como una solicitud a una nueva URI, o que los datos en la

memoria caché del navegador están actualizados), 4xx Client Error (si hay errores en la solicitud del

cliente y la naturaleza temporal o definitiva de los mismos) y 5xx Server Error (que indican errores no

atribuibles al cliente al procesar una solicitud válida).

Internet

Cliente

Cliente

Cliente

Servidor

Figura 2.1: Diagrama cliente-servidor HTTP

Sesiones en HTTP

Aunque HTTP es un protocolo sin estado y no proporciona mecanismos para mantener información

asociada a un conjunto de solicitudes de diferentes recursos, en los sitios y aplicaciones web actuales

resulta imprescindible poder identificar y mantener información para cada cliente de manera

individual. Para ello, el servidor envía una cookie como parte de la respuesta a su primera solicitud que

es reenviada por el navegador en las siguientes, de forma que se consigue preservar la información

necesaria asociada al usuario durante el tiempo que éste utiliza la aplicación. Esta cookie contiene un

identificador de sesión (o token) utilizado por el servidor para identificar y localizar los datos del

cliente. La razón de que solo se envíe y reciba un token hacia y desde el cliente atiende a razones de

simplicidad (el cliente solo tiene que gestionar un identificador) y seguridad (la comprobación de la

autenticidad del token se realiza en el servidor, pudiendo implementar mecanismos de seguridad

adicionales como la comprobación de la IP de origen o la revocación de privilegios para tokens que no

hayan sido utilizados durante un periodo de tiempo determinado).

Generación de contenido de forma dinámica

Cuando la World Wide Web surgió a principios de los 90, la mayor parte de sus contenidos eran páginas

estáticas HTML. Sin embargo, a medida que su uso se fue popularizando, surgió la necesidad de

generar las páginas de manera dinámica (esto es, crear el contenido en el momento en el que el

usuario lo solicita). Esto permitió que surgieran webs que respondían a las necesidades de los usuarios,

permitiéndoles interactuar con ellas y obtener información que se actualizaba en tiempo real.

En la actualidad, prácticamente todas las webs más visitadas generan la mayor parte de sus páginas

en el momento en que son solicitadas por el usuario a partir de un programa [ALEX01]. Una búsqueda



en Google retorna un listado de páginas generado a partir de los datos de un índice, los artículos de la

Wikipedia son generados a partir de la información almacenada en una base de datos, Facebook es

una aplicación escrita en PHP y C++ que lee sus datos de una base de datos distribuida [FACEB01].

Para la generación dinámica del contenido en el servidor de aplicación existen diversas alternativas.

Las más comunes son generar el contenido a partir de un programa o script CGI escrito en cualquier

lenguaje de programación, lo cual normalmente implica la creación de un nuevo proceso; o generar el

contenido a partir de un script ejecutado por el servidor dentro de su espacio de direcciones2, como

si se tratase de una llamada a función más dentro del ciclo normal de despacho de solicitudes.

La aplicación desarrollada está implementada utilizando PHP, el cual soporta ambos modos de

operación. En nuestro caso, hemos optado por el segundo enfoque, ya que es el recomendado para la

combinación del servidor web y sistema operativo utilizados [PHP03].

Además, para mejorar los tiempos de carga y disminuir los recursos necesarios en el servidor de bases

de datos, es común utilizar servidores adiciones de memoria caché para guardar copias de los datos

de la aplicación (o páginas completas generadas previamente) en memoria RAM, evitando así los

accesos a disco y la sobrecarga adicional introducida por las comprobaciones de permisos de la base

de datos en las lecturas. Aun así, las escrituras siguen introduciendo importantes latencias, así como

la lógica asociada a mantener la consistencia de datos entre las memorias caché y la base de datos.

2.2.2 Introducción a HTML

El Lenguaje de Marcado de Hipertexto (Hypertext Markup Language) es el sistema surgido a principios

de los 90 para estructurar el contenido de los documentos a mostrar utilizando un navegador web.

Consta de una serie de reglas sintácticas, que definen códigos de marcado o etiquetas insertadas en

los archivos que constituyen las páginas web; y semánticas, que indican al navegador cómo mostrar al

usuario la información. Los elementos que forman los documentos HTML pueden clasificarse en

estructurales (como un párrafo) o en aquellos que definen un comportamiento deseado (como un

salto de línea) [ROB06].

Las reglas que definen la etiquetas HTML válidas y su sintaxis y semántica son mantenidas por el World

Wide Web Consortium (más conocido por la abreviatura W3C), una organización internacional fundada

en 1994 cuyo objetivo es el desarrollo y mantenimiento de los diferentes estándares sobre los que se

basa Internet.

Los elementos HTML pueden anidarse y, para que sean correctos, todos ellos deben estar entre las

etiquetas de apertura y cierre del elemento que lo contiene (denominado padre) [ROB06].

2 Este modo de operación es conocido como “Ejecución como módulo del servidor”.



Internet

Apache

Cliente

Apache Workers

mod_php

core

MySQL Memcached

Figura 2.2: Despliegue típico de una aplicación web utilizando un pool de procesos Apache

El conjunto de reglas sintácticas y semánticas que

debe cumplir un documento HTML es bastante

complejo, y difiere entre versiones del estándar.

Para facilitar la tarea de comprobar si una página

cumple con los estándares, la W3C pone a

disposición de los desarrolladores una herramienta

online en [W3C02] que realiza una comprobación

sintáctica y semántica completa para determinar la

validez de los documentos.

En los últimos años se ha puesto un especial énfasis

en eliminar de HTML la información utilizada para

<!DOCTYPE html> <html> <head> <title>Título de la página</title> </head> <body> <p>Hola mundo!</p> </body> </html>

Figura 2.3: Documento HTML básico



indicar cómo representar su contenido, recomendando el uso de CSS para este propósito y utilizando

HTML como capa estructural [ROB06]. De esta forma, los archivos HTML pasan a ser la fuente de los

contenidos y la estructura básica de las páginas web, mientras que CSS define de forma exhaustiva la

forma de presentarlos mediante un conjunto de reglas independientes y fácilmente intercambiables

en función, por ejemplo, del tipo de dispositivo usado (como un ordenador o un teléfono móvil) o de

sus características (como su resolución o el navegador utilizado).

Para crear una base sólida, escribir documentos HTML sin elementos de presentación y bien

estructurados se ha convertido en la base del diseño web fiel a los estándares, utilizando marcado

semántico de forma que sus elementos sean descriptivos y tengan significado [ROB06].

El nuevo estándar: HTML5

Con el paso del tiempo, HTML fue degenerando en una mezcla de

características introducidas por sus distintas especificaciones, por los

diferentes navegadores que incluían sus propias extensiones al estándar,

por los hábitos de los desarrolladores y por la necesidad de lidiar con los

errores sintácticos de los documentos existentes en la web. Además, el

lenguaje presentaba carencias, y era necesario mejorar la representación

semántica de los documentos. Por otra parte, el mercado actual incluye

nuevos dispositivos, como teléfonos móviles, tablets o televisores, y usos de

los lenguajes del lado del cliente que no se habían tenido en cuenta inicialmente, como la obtención

de datos del servidor de forma asíncrona para alterar el contenido y la presentación de los documentos

en tiempo real. Tradicionalmente estos problemas han sido solventados recurriendo a tecnologías no

estándar (como Flash) que introducen nuevos problemas, como un mayor uso de recursos o el hecho

de atar a usuarios y desarrolladores a productos propietarios.

Para solucionar estos problemas, la W3C publicó en 2012 una versión inicial de la quinta revisión de

HTML como una recomendación candidata3, que constituye una renovación del lenguaje teniendo en

cuenta el escenario actual, y la inclusión de características demandadas por usuarios y desarrolladores.

Entre las características principales de HTML5 están [MOZ01]:

Nuevos elementos semánticos, proporcionando soporte para definir el significado y la

importancia de las diferentes secciones de los documentos de manera nativa.

Posibilidad de referenciar audio y video a través de tags estándar, gestionando los

contenidos en el propio navegador y su control a través de interfaces de usuario programadas

utilizando Javascript tradicional.

Soporte para nuevos elementos de formulario, y la posibilidad de definir la lógica de

validación de éstos directamente como atributos HTML en lugar de necesitar el uso de

lenguajes de scripting para ello.

3 El 28 de Octubre de 2014 la W3C publicó la primera versión completa del estándar HTML5 en [W3C08].



Comunicación bidireccional entre el cliente y el servidor, permitiendo a este último la

notificación de eventos utilizando WebSockets en lugar de necesitar un mecanismo de polling

tradicional e el cliente.

Posibilidad de implementar aplicaciones web multihilo, utilizando WebWorkers para la

ejecución de Javascript en segundo plano.

Soporte nativo para el almacenamiento de información en el cliente, posibilitando la creación

de aplicaciones web que guardan información en el equipo del usuario.

Además, junto a HTML5 se dispone de la tercera versión de CSS, que introduce mejoras para definir

interfaces de usuario modernas, incluyendo bordes redondeados, animaciones, tipografías mejoradas

y acceso al hardware de aceleración gráfica en 3D a través de WebGL.

2.2.3 Introducción a AJAX

Por Javascript Asíncrono y XML (Asynchonous Javascript And XML) se conoce al conjunto de tecnologías

de desarrollo web que permiten la creación de aplicaciones asíncronas en las que el cliente puede

enviar y recibir datos a y desde servidor en segundo plano, sin requerir la recarga de la página actual.

Formalmente, AJAX no se refiere a una única tecnología, sino a un conjunto de ellas, incluyendo HTML

y CSS, DOM, XML y Javascript que, utilizadas de manera simultánea, permiten implementar

aplicaciones web que, hasta cierto punto, se asemejan a las aplicaciones de escritorio tradicionales

en lo referido a los tiempos de respuesta.

Entre las aplicaciones web más conocidas que implementan este modelo de funcionamiento se

incluyen Gmail, Google Maps, Goolge Docs, Twitter o Facebook, y se basan en los estándares HTML y

CSS (para crear una interfaz de usuario interoperable), DOM (para la manipulación dinámica de los

contenidos), XML y JSON (para representar y manipular los datos enviados y recibidos) y Javascript

(utilizado como el lenguaje que une todas las demás tecnologías).

En las aplicaciones web tradicionales, las acciones del usuario, como hacer clic en un botón o

seleccionar un valor de una lista, requerían realizar una solicitud HTTP, tras la cual toda la interfaz de

usuario (la página web) era redibujada. Utilizando AJAX, el usuario puede seguir interactuando con el

sitio mientras la respuesta a sus acciones es procesada en segundo plano por el servidor y el navegador

espera la respuesta a ellas siguiendo un modelo orientado a eventos. Esto permite la implementación

de funciones que antes solo eran posibles en aplicaciones de escritorio, como autocompletado, la

notificación de llegada de nuevos correos electrónicos en tiempo real, sistemas de mensajería

instantánea, interfaces de administración completas de uso sencillo para máquinas virtuales [VBOX01],

o sistemas de gestión de contenido web [AJXL14] o bases de datos [DBADM01].

2.2.4 Introducción a CSS y CSS3

Las hojas de estilo en cascada (Cascading Style Sheets) son utilizadas para definir la apariencia y

formato de los diferentes elementos de una página web (o cualquier otro tipo de documento XML) en

una pantalla de ordenador, móvil u otro dispositivo por medio de una sintaxis sencilla. Publicado



inicialmente en 1996 por la W3C, CSS es considerado una de las tecnologías clave de la web actual y la

práctica totalidad de los sitios web lo utilizan para definir la presentación de sus contenidos.

CSS permite un control total sobre el estilo y formato de los documentos [W3C03], separando el

contenido de la presentación, por medio de reglas o declaraciones sobre estilo de uno o más

elementos. Sintácticamente, cada regla se divide en dos partes: un selector y una declaración de estilo

asociada a éste. A su vez, cada declaración está compuesta por una o más asignaciones de valores a

propiedades del selector.

h1 { color: red; font-weight: bold; }

Figura 2.4: Ejemplo de declaración CSS

Los selectores funcionan como enlace entre el documento y el estilo, especificando qué elementos van

a verse afectados por cada declaración. En el ejemplo anterior, se especifica que los elementos HTML

<h1> deben mostrarse en negrita y color rojo en todos los documentos vinculados a la hoja de estilos

que lo contiene.

Existen 3 formas de asociar estilos a los elementos de un documento: utilizando una hoja de estilos

CSS externa, insertando las reglas directamente en el encabezado de un documento, o insertando los

valores de las propiedades directamente sobre aquellos elementos a modificar. Estos métodos no son

mutuamente excluyentes.

Otro aspecto importante de CSS es la posibilidad de anidar las reglas, por medio de múltiples

declaraciones o utilizando múltiples reglas diferentes aplicables a un mismo elemento. De esta forma

es posible definir el estilo general de un documento, para luego concretarlo en otros archivos o

directamente sobre el marcado HTML, siguiendo un proceso análogo al de herencia y sobrecarga de

los lenguajes de programación.

En general, existen tres tipos de selectores básicos: aquellos que especifican el identificador único del

elemento HTML sobre el que se aplican (precedido de una almohadilla), aquellos que definen una clase

de elementos (precedidos de un punto) y aquellos, más generales, que se aplican a todas las etiquetas

HTML de un tipo dado. Además, pueden utilizarse selectores basados en pseudoclases, que permiten

definir el formato de los elementos basándose en información que no está representada en el árbol

sintáctico del documento (por ejemplo, definir el color de los enlaces que han sido visitados

previamente por el usuario o la apariencia de un botón cuando se pasa el ratón por sobre él).

Novedades de CSS3

En junio de 1999 la W3C publicó los primeros borradores de la tercera versión de

CSS. En general, CSS3 ha sido publicado como diferentes módulos, cada uno con

procesos de revisión y calendarios diferentes, y abarcan aspectos concretos como

el modelo de cajas CSS [W3C04] (box model, relativo al posicionamiento de los

elementos de una página), las imágenes de fondo [W3C05] (permitiendo utilizar

múltiples imágenes como fondo de cualquier elemento y controlar su posición), la

descarga de las fuentes de texto usadas por una página [W3C06] (eliminando así la

tradicional dependencia en las fuentes instaladas en el equipo del cliente) o las



media-queries [W3C07] (que permiten definir declaraciones de estilo condicionales en función del

tamaño u orientación de la pantalla o del tipo de dispositivo).

2.2.5 El patrón de diseño MVC

El patrón Modelo-Vista-Controlador (Model-View-Controller) [GoF94] define el diseño de sistemas de

información como diferentes componentes débilmente acoplados, de forma que la representación

interna de los datos es independiente de la forma en que éstos son mostrados al usuario. Las

aplicaciones construidas siguiendo este patrón quedan, en general, divididas en los siguientes

componentes:

Modelos: Objetos que encapsulan el acceso a los datos de la aplicación, de forma que el

mecanismo de acceso a los mismos y su representación interna es independiente del resto de

la aplicación.

Vistas: Las vistas implementan la forma de interactuar del usuario con la aplicación, siendo las

encargadas de decidir cómo mostrar los datos a éste.

Controladores: Los controladores se encargan de realizar solicitudes a los modelos, de elegir

las vistas a utilizar y de proporcionar a éstas los datos necesarios.

El principal inconveniente de MVC, cuando se utiliza de forma estricta, es el hecho de que, al utilizarse

un único controlador para atender cada solicitud, cada uno debe gestionar también otras partes que

son comunes a toda la aplicación, como la inicialización de sesiones, la comprobación de permisos o la

generación de las partes de la interfaz que son comunes a toda la aplicación o a secciones amplias de

la misma.

MCV en capas: Arquitectura jerárquica

Al desarrollar una aplicación web, a menudo se presentan complicaciones a la hora de definir la

interfaz con el cliente debido a la gran variedad de servidores, plataformas de desarrollo y protocolos

con los que debe lidiar el desarrollador. Entre los factores que hay que tener en cuenta están cómo

estructurar la interfaz y cómo interactuarán los usuarios con ella, cómo separar la lógica encargada de

enviar los datos al cliente en diferentes formatos y cómo gestionar los eventos y el flujo de la

aplicación. Además, hay que tener en cuenta que ciertas partes de la capa de presentación deben ser

consistentes ente páginas (o idénticas), y hay ciertos pasos que deben realizarse indistintamente para

todas las solicitudes (como la creación de conexiones a la base de datos, la gestión de sesiones o la

inicialización de subsistemas comunes a toda la aplicación).

Para simplificar el proceso de desarrollo, mejorar la modularidad de las aplicaciones y facilitar su

mantenimiento surge el Modelo-Vista-Controlador Jerárquico (Hierarchical Model-View-Controller,

[CAI00]). Se trata de una variación del patrón MVC estándar que aumenta la modularidad y facilita la

reusabilidad y el mantenimiento del código, permitiendo, a diferencia del MVC tradicional, que los

controladores pueden realizar sub-solicitudes a otros controladores.



Base de Datos

Controlador

Modelo(s)

Figura 2.5: Arquitectura MVC tradicional

De esta forma cada controlador se encarga de generar parte de la respuesta a enviar al usuario,

delegando el resto en otros controladores y permitiendo la construcción de aplicaciones como un

conjunto de varias capas jerárquicas de modelos, vistas y controladores. Algunas de las ventajas de

HMVC son:

Reduce las dependencias entre partes dispares del programa.

Facilita la reutilización de componentes y módulos.

Aumenta la extensibilidad a la vez que facilita el mantenimiento del código.

La clave para ello está en la posibilidad de realizar sub-solicitudes a otros controladores en lugar de

duplicar código. Por ejemplo, para mostrar una lista de artículos en HTML se envía una solicitud al

controlador de artículos con algunos parámetros, el cual interactúa con el modelo apropiado, y

selecciona una vista para mostrar el contenido. Sin embargo, en lugar de mostrar la lista recibida

directamente en una página independiente, el controlador que realiza la sub-solicitud utiliza la vista

recibida para incrustarla en otra (por ejemplo, una interfaz que lista todas las opciones de

administración).



Base de Datos

Controlador

Modelo(s)

Controlador

Modelo(s)

...

Figura 2.6: Arquitectura MVC jerárquica

2.2.6 Introducción a PHP

PHP (acrónimo recursivo que significa “PHP: Hypertext Preprocesor” o Preprocesador de Hipertexto)

es un lenguaje de programación de propósito general ampliamente usado para el desarrollo de

aplicaciones web. Con una sintaxis que toma elementos de C, Java y Perl, se trata de un lenguaje

diseñado para permitir el desarrollo de páginas web dinámicas de forma rápida, a la vez que permite

construir aplicaciones más complejas utilizando interfaces a librerías de terceros y elementos de la

programación orientada a objetos [PHP04].

El código escrito en PHP puede estar mezclado con código HTML o de otro tipo, o pude usarse junto a

sistemas de plantillas (separando la lógica de negocio de la capa de presentación). Habitualmente los

programas escritos en PHP (también llamados scripts PHP) son procesados por un intérprete enlazado

a un servidor web como una extensión o utilizando una interfaz CGI, tras lo cual se envía el resultado

generado al cliente como respuesta a una solicitud.



A diferencia de los lenguajes de programación tradicionales, PHP usa un sistema de asignación de tipos

de dato débil y dinámico, en el cual las variables no tienen que declararse previamente y pueden pasar

de representar un tipo escalar a otro, un objeto, o dejar de existir dentro de un mismo contexto de

ejecución (por ejemplo, dentro de una única función).

Internamente, PHP está estructurado a partir de un pequeño núcleo (core) que gestiona la

funcionalidad esencial del lenguaje (como el parser o la gestión de variables y tipos) sobre una máquina

virtual que proporciona funcionalidades de bajo nivel (como la gestión de memoria o la representación

interna de datos). Sobre él se apoyan un amplio número de extensiones4 que proporcionan varias

funcionalidades, como manipulación de imágenes, cálculo con números de precisión arbitraria, envío

de correo electrónico o interfaces para utilizar diferentes protocolos de red. Del mismo modo, parte

de las funcionalidades básicas del lenguaje, como los principales tipos de contenedores (pilas, heaps,

listas enlazadas…), iteradores, excepciones e interfaces están implementadas como la extensión

obligatoria (sic) SPL5.

La implementación original de PHP, disponible en php.net, se considera el estándar de facto y está

construida sobre una máquina virtual denominada Zend Engine, que compila en el momento de la

solicitud el código PHP a una representación interna que luego es ejecutada por un intérprete. Debido

al tiempo necesario para ello, existen varios proyectos open source que implementan compiladores

PHP alternativos (como HipHop Virtual Machine [FACEB01] o Parrot).

El uso de PHP para el desarrollo web está ampliamente extendido, existiendo fuentes que estiman que

es utilizado aproximadamente por el 40% de los sitios web actuales6 [WIKI05].

2.2.7 Los sistemas de plantillas para web

Debido a que los documentos HTML son archivos de texto plano, las aplicaciones web pueden ser

desarrolladas de forma directa, escribiendo directamente el código que lo define a través de la salida

estándar 7 (la cual se envía al cliente directamente por el navegador). Esta forma de proceder, aunque

inicialmente más simple y fácil, rápidamente da lugar a aplicaciones difíciles de entender y mantener.

Además, normalmente provoca que cualquier cambio en la capa de presentación deba hacerse en

varios archivos, y da lugar a archivos de código fuente demasiado largos y potenciales inconsistencias.

Los sistemas de plantillas aplican el principio de separación en capas usado en la ingeniería de software

tradicional en las aplicaciones web. De esta forma, la capa de presentación es definida a partir de

archivos independientes que contienen código HTML (o de otro tipo, como CSS o Javascript) y

referencias o etiquetas especiales que son remplazadas por valores reales para generar la respuesta a

enviar al cliente. Esto proporciona una serie de ventajas importantes:

Facilita la separación de responsabilidades, encapsulando en las plantillas los detalles relativos

a la presentación.

4 A día de hoy existen más de 200 extensiones documentadas en php.net. 5 Standard PHP Library (librería estándar de PHP) 6 Enero 2013 7 Esto es bastante común en la programación de scripts CGI utilizando lenguajes tradicionales



Proporciona una forma sencilla de modificar la presentación, al estar definida en un conjunto

de archivos conocido e independiente.

Establece un principio de mínimo privilegio a nivel software, evitando que la capa de

presentación acceda a funciones de modificación de datos o de lógica de negocio.

Permite definir la interfaz de usuario utilizando una sintaxis independiente y, a menudo, más

sencilla que la del resto de la aplicación.

Por otra parte, al utilizar plantillas se incluye una capa adicional en el proceso necesario para generar

las páginas web, con la correspondiente sobrecarga asociada y necesidad de gestión de archivos

adicionales. Para solucionar el primer problema, los sistemas de plantillas modernos permiten

precompilar plantillas (convirtiéndolas en clases PHP o código Java nativo, por ejemplo), o utilizar

sistemas de caché en memoria que evitan el coste asociado a leer las plantillas de disco en cada

solicitud.

Página Web

Plantilla

%header%Welcome…

· …..· …..

[_] [_]

Datos

SistemaDe

Plantillas

Figura 2.7: Esquema de funcionamiento de un sistema de plantillas web



2.3 Objeto

La aplicación desarrollada surge para suplir las carencias de otra aplicación que el congreso venía

utilizando en ediciones anteriores. Se trata de un gestor integrado que permitirá el registro de los

asistentes al congreso, el envío por parte de éstos de los artículos a presentar y sus justificantes de

pago, y la gestión integral de todas las fases de la conferencia por parte de los organizadores de la

misma, incluyendo el ciclo de revisión de artículos, las distintas sesiones que tendrán lugar o la

generación de documentación y listados diversos.

2.4 Antecedentes

La aplicación desarrollada parte de otra utilizada en ediciones anteriores, a la cual viene a sustituir, y

debe cubrir la funcionalidad proporcionada por ella, además de solventar las carencias detectadas en

la misma tras su uso en ediciones anteriores. Para ello se deben realizar los cambios necesarios para

garantizar la modularidad de la aplicación resultante, asegurándonos de que la ampliación posterior

de la misma resulte más sencilla que al inicio del proyecto.

Durante el desarrollo deben de existir los mecanismos necesarios para garantizar el funcionamiento

de las características originales, a la vez que se garantiza que las nuevas lo siguen haciendo de la

manera esperada tras cada iteración. Para este propósito se utilizarán tests unitarios automáticos.

2.5 Normas y referencias

A continuación se incluye un estudio breve sobre normativas aplicables al proyecto, métodos y

herramientas, mecanismos de control de calidad y una introducción a los marcos de trabajo

(frameworks) y librerías utilizadas.

Como complemento a este apartado se incluye, al final del documento a modo de apéndice, una lista

completa de referencias bibliográficas.

2.5.1 Disposiciones legales y normas aplicadas

En este punto se incluyen los aspectos más importantes de las leyes y normativas que son aplicables

al presente proyecto.

Ley Orgánica de Protección de Datos

La aplicación desarrollada está alojada en un servidor en España y es propiedad de una empresa (la

organización del congreso) constituida legalmente en España. Por tanto, debido a que en el proceso

de registro se recogen datos personales de los asistentes, la aplicación está sujeta a la Ley Orgánica de

Protección de Datos (LOPD). Esta ley dicta que, por guardar datos personales, estamos obligados a:

Informar a los usuarios de qué datos personales se recogen.



Informar del propósito con el que se recogen dichos datos.

Proporcionar métodos para consultar, rectificar y dar de baja los datos. Para ello debe

proporcionarse una dirección postal.

Implementar las medidas de seguridad oportunas para proteger los datos, incluyendo solicitar

una contraseña para acceder a ellos.

Para cumplir la ley, durante el proceso de registro se informa al usuario de que todos los datos

proporcionados durante el mismo están sujetos a la LOPD, que el propósito es la gestión del congreso

y se proporciona una dirección postal para efectuar el derecho de rectificación y cancelación. El cuarto

punto se cumple en cuanto que para acceder al sistema, tanto si es como ponente como si es como

administrador, se requiere un nombre de usuario y una contraseña, y el acceso remoto al servidor para

labores administrativas se realiza utilizando conexiones cifradas a través de SSH que también requieren

proporcionar usuario y contraseña. Todos los accesos al sistema quedan debidamente registrados en

la base de datos y/o en archivos de texto.

Legislación sobre cookies

En este apartado se incluye un estudio breve sobre la legislación aplicable a este proyecto sobre el uso

de cookies en sitios web basado en la Guía sobre el uso de cookies [AEPD14] publicada por la Agencia

Española de Protección de Datos (AEPD). Se ha optado por utilizar dicha guía por ser de relevancia la

interpretación hecha por esta institución de la Ley que regula este aspecto. Cabe destacar que, aun

así, la guía de la AEPD es solo una interpretación de la norma y no su texto completo, el cual prevalece

en cualquier caso sobre ella.

La legislación en materia de publicidad y comercio electrónico se rige por la Ley de Servicios de la

Sociedad de Información (LSSI), la cual incluye una normativa sobre el tratamiento de cookies en sitios

web vigente desde el 1 de abril de 2012. En términos generales, esta normativa obliga a los propietarios

de los sitios a informar de forma clara y obtener el consentimiento del usuario antes de utilizar ciertos

tipos de cookies.

Esta ley afecta a todos los profesionales o empresas que presten servicios en España, ya sea por

disponer de domicilio o establecimiento permanente en España, o porque sus servicios estén

orientados a este mercado. La ley distingue cuatro tipos de cookies:

Cookies técnicas: Son aquellas que resultan imprescindibles para proporcionar el servicio de

la aplicación o página web como, por ejemplo, las que almacenan los datos de un pedido

online.

Cookies de personalización: Utilizadas para cambiar las funciones o contenidos del sitio en

función de los datos del navegador, por ejemplo, para cambiar el idioma utilizado en función

de las preferencias del usuario.

Cookies de análisis: Son aquellas utilizadas únicamente con propósitos estadísticos.



Cookies publicitarias: En este grupo se incluyen aquellas cookies cuyo objetivo es almacenar

información sobre las páginas visitadas o el comportamiento del usuario, utilizadas en servicios

como la red publicitaria de Google.

En nuestro caso, la aplicación envía una única cookie, utilizada para mantener el identificador de sesión

del usuario. Según la terminología de la AEPD, atendiendo a la entidad emisora es una cookie propia;

atendiendo a su plazo es una cookie de sesión; y atendiendo a su finalidad es una cookie técnica. Es

utilizada para prestar “un servicio solicitado expresamente por el usuario” y está clasificada como

cookie “de autentificación o identificación del usuario (sesión)”. Este tipo de cookies están

explícitamente excluidas del ámbito de aplicación del artículo 22.2 de la LSI, no siendo necesario ni

informar ni solicitar consentimiento para su uso.

Por otra parte, para que una cookie no esté sujeta al deber de consentimiento informado, es requisito

necesario que su caducidad esté relacionada con su finalidad. Las cookies de sesión de PHP son

borradas tras un intervalo de tiempo configurable en el propio servidor. Además, las cookies no tienen

otra finalidad que la “autentificación o identificación del usuario”, luego no son clasificables por la Ley

de Servicios de Internet dentro del ámbito de aplicación de otros preceptos.

También es importante mencionar que las sesiones identificadas por las cookies del sitio normalmente

estarán asociadas a cuentas de usuarios de los que se guardan datos personales en el servidor. Estos

datos, debido a su naturaleza, están cubiertos por la Ley Orgánica de Protección de Datos.

2.5.2 Métodos, herramientas, modelos, métricas y

prototipos

En este apartado se incluye una introducción, sin carácter exhaustivo ni exclusivo, a diferentes

programas y herramientas software y su uso en el desarrollo de este proyecto.

Mantis

Mantis Bug Tracker es una aplicación de código abierto, basada en una interfaz web, para el

seguimiento de incidencias y errores (bugs). Mantis ha sido utilizado durante todo el desarrollo de la

aplicación para gestionar la lista de características a implementar y los fallos encontrados, permitiendo

llevar un registro de los mismos, incluyendo su estado y prioridad.

Mantis permite agrupar las incidencias en hitos (milestones). En el caso de la aplicación desarrollada,

esta característica ha sido utilizada para agruparlos en iteraciones (sprints), de forma que se ha

realizado una implementación gradual, teniendo siempre una versión funcional disponible.

Otra característica que se ha tenido en cuenta a la hora de utilizar Mantis (y, en general, un sistema de

seguimiento de inicidencias) es que la información de gestión guardada en él puede utilizarse

posteriormente para documentar fielmente las fases del desarrollo del proyecto.



Ant

Apache Ant es una herramienta mutiplataforma similar a GNU make utilizada para automatizar tareas

mecánicas y repetitivas. Aunque normalmente es utilizada en lenguajes compilados para automatizar

el proceso de generación de ficheros ejecutables, en nuestro caso ha sido utilizada para automatizar

procesos auxiliares durante el desarrollo:

Generación de informes de código antiguo en forma de archivos de texto que contienen

listados de los usos de funciones obsoletas, enlaces directos a scripts .php (en lugar de

llamadas a controladores) o líneas de código con marcadores sobre algoritmos incompletos o

con errores potenciales.

Generación automática de documentación e informes de análisis estático del código (por

ejemplo, cantidad de líneas de código, funciones y clases, o complejidad ciclomática media) a

partir de la estructura y los comentarios PHPDoc del propio código.

Ejecución de procesos utilizados como mecanismo de control de calidad del proyecto, como

pruebas unitarias o análisis del código fuente en busca de errores sintácticos.

Automatización de tareas de gestión necesarias, como la eliminación de archivos temporales

creados durante la generación de los informes de cobertura de las pruebas unitarias o la

eliminación tras cada actualización de archivos problemáticos distribuidos con algunas de las

librerías utilizadas.

Copia de los archivos con las fuentes TrueType utilizadas desde una copia auxiliar al directorio

de las librerías tras cada actualización de éstas, pues las fuentes no se distribuyen junto a la

librería utilizada para generar los archivos PDF.

A diferencia de make, Ant utiliza una sintaxis XML para describir las tareas (targets) a ejecutar, lo cual

es más apropiado para este proyecto (ya que, al tratarse de una aplicación web, los desarrolladores

están más familiarizados con su sintaxis general). Otras de las funcionalidades que han resultado de

ayuda son la posibilidad de, utilizando declaraciones sencillas, ejecutar tareas en paralelo (lo cual

reduce a menos de la mitad el tiempo necesario para generar los informes en formato texto y la

búsqueda automática de errores sintácticos), separar las definiciones de las tareas en distintos

archivos XML, o realizar operaciones de creación, copia y eliminación de archivos definiéndolas

directamente como tags XML en lugar de necesitar recurrir a shell scripts.

grep

grep8 es una utilidad de línea de comandos utilizada para buscar líneas en archivos de texto que

coincidan con una expresión regular dada. Fue desarrollado originalmente para UNIX, y actualmente

existen versiones disponibles para los sistemas operativos más utilizados.

grep permite buscar en un archivo concreto, en conjuntos de archivos o en la entrada estándar. Estas

características han sido utilizadas para automatizar búsquedas sobre el código fuente y generar

8 El uso de minúsculas en el nombre es intencionado, y sigue el convenio usado por el manual del proyecto GNU.



informes (por ejemplo, sobre el uso de funciones obsoletas). Además, también ha sido utilizado

durante el desarrollo para realizar búsquedas simples sobre el código fuente en lugar del buscador

integrado en el entorno de desarrollo (como, por ejemplo, la búsqueda de archivos que utilizan una

determinada función a partir de su nombre). También ha sido utilizado en combinación con otras

utilidades, como wc (word count), para realizar estimaciones sobre el esfuerzo necesario y el progreso

de las refactorizaciones realizadas.

Además de su uso para realizar búsquedas en el código fuente, grep también ha sido utilizado para

realizar búsquedas en los archivos de registro (logs) del servidor y de la aplicación, facilitando el análisis

de su uso y la solución de problemas.

PHPLoc

PHPLoc es una utilidad para el análisis estático de código PHP utilizada para generar estadísticas

generales de la complejidad de las aplicaciones desarrolladas. Algunas de las métricas proporcionadas

son:

Número de archivos, directorios y líneas de código, clasificando estas últimas en comentarios

y código real.

Complejidad ciclomática general de la aplicación.

Número de accesos a variables globales y número de atributos y métodos estáticos y de

objetos declarados.

Estructura general de la aplicación, en número de espacios de nombres, interfaces, rasgos

(traits), clases, métodos, funciones y constantes.

Las métricas proporcionadas han sido tenidas en cuenta para determinar la bondad de la aplicación

desarrollada, midiendo, por ejemplo, la cantidad de estado global presente en la aplicación (en forma

de accesos a variables globales y atributos estáticos).

Como el resto de informes de desarrollo, las métricas proporcionadas por PHPLoc han sido generadas

rutinariamente, como parte del proceso general de desarrollo, de manera pseudoautomática a través

de scripts Ant.

PHPUnit

PHPUnit es una aplicación similar a JUnit para la automatización de las pruebas software a realizar

por medio de tests unitarios. Entre las ventajas de este tipo de pruebas están la posibilidad de

automatizarlas (utilizando el mismo lenguaje de programación usado en el resto del proyecto) y la

generación de informes de pruebas fallidas y de la cantidad de código cubierto por ellas.

En este proyecto, PHPUnit se incluye como una librería más dentro del directorio de Composer,

facilitando su gestión y actualización, y eliminando la necesidad de instalarlo globalmente en el sistema

utilizado durante el desarrollo.



NetBeans

NetBeans es un entorno integrado de desarrollo (IDE) open source para aplicaciones escritas en varios

lenguajes, incluyendo Java, C++, PHP y HTML5. El IDE en sí está programado en Java y puede ser

ejecutando en cualquier sistema de escritorio para el cual exista una implementación (libre o

comercial) de la Máquina Virtual Java. NetBeans posee un amplio soporte de tecnologías utilizadas

para el desarrollo general de aplicaciones y, en particular, para el desarrollo de aplicaciones web,

además de características adicionales que facilitan esta labor.

Entre las características interesantes que han sido tenidas en cuenta para elegir este IDE podemos

citar:

- Soporte para el desarrollo de aplicaciones utilizando PHP 5, incluyendo el uso de namespaces,

traits e interfaces (si bien el soporte de estas nuevas características del lenguaje ha sido parcial

en las versiones del IDE disponibles al inicio del proyecto).

- Posibilidad de ejecutar aplicaciones PHP directamente desde el IDE, utilizando el servidor

web integrado en las últimas versiones del intérprete de PHP y mostrando la salida de

depuración detallada generada por la aplicación en tiempo real.

- Autocompletado de código PHP, HTML5, Javascript, CSS3 y, hasta cierto punto, de lenguajes

de shell scripting, facilitado el desarrollo de la aplicación y de los scripts de soporte.

- Acceso integrado a la consola bash de Linux, incluyendo el uso de varias sesiones simultáneas

a través de pestañas.

- Posibilidad de editar simultáneamente múltiples archivos en vistas divididas, incluyendo la

edición de diferentes secciones del mismo archivo desde distintas vistas.

- Soporte básico del lenguaje de plantillas Twig, utilizado en la capa de presentación de la

aplicación desarrollada.

- Soporte para la programación en Javascript con jQuery, utilizado para las partes que

requieren la actualización dinámica de la interfaz de usuario de la aplicación y las solicitudes

HTTP asíncronas realizadas mediante tecnologías AJAX.

- Análisis estático del código, proporcionando consejos en tiempo real para la mejora del código

desarrollado y su estructura, incluyendo características para la refactorización automática del

código.

- Soporte integrado para el desarrollo sobre repositorios de código Git.

- Posibilidad de depurar código PHP instrucción a instrucción utilizando la extensión XDebug.

- Entiende los comentarios PHPDoc de clases, métodos y variables incluidos en el código, lo cual

es especialmente importante en un lenguaje de tipado débil como PHP.



VirtualBox

VirtualBox es un software de virtualización open source mantenido por Oracle que permite la ejecución

de instancias de Windows y Linux, entre otros, sobre sistemas host Linux, Windows, Mac OS X, OS/2 y

Solaris. En este proyecto, VirtualBox ha sido usado para ejecutar servidores Linux (Debian) para la base

de datos del sitio, el repositorio de código y el gestor de incidencias durante el desarrollo, y para

ejecutar un servidor completo (servidor web Apache y servidor de base de datos MySQL) a modo de

prototipo durante la fase de pruebas y la elaboración de la documentación. Además, el presente

documento y los diagramas incluidos en el mismo han sido elaborados utilizando una máquina virtual

que ejecuta Windows Server 2012 R2 y el paquete ofimático Office 2013, ambos adquiridos con

licencias de estudiante proporcionadas por la Universidad de Oviedo.

Se ha optado por Virtualbox en lugar de otras alternativas (como Xen o VMWare) debido a su carácter

gratuito y open source (siguiendo la filosofía del resto de componentes usados durante el desarrollo

del proyecto), su relativa facilidad de instalación y administración como una aplicación estándar del

sistema, la portabilidad ofrecida (al poder ejecutarse en prácticamente cualquier equipo moderno,

sumado a la posibilidad de copiar y realizar backups de sistemas completos a partir de archivos de

imagen del sistema en formato abierto OVF), y el soporte relativamente completo ofrecido por

Windows y las principales distribuciones Linux para el mismo. Además, su uso está ampliamente

extendido tanto en ámbitos académicos como profesionales, y dispone de soporte tanto por parte de

Oracle como por la comunidad de desarrollo asociada a las principales distribuciones y al propio kernel

de Linux, lo cual minimiza la posibilidad de encontrar errores durante su uso que provocarían

complicaciones adicionales en el proyecto.

Como contrapartida, el uso de sistemas de virtualización de cualquier tipo lleva implícita una pérdida

de rendimiento respecto al uso de sistemas operativos sobre el hardware desnudo. Sin embargo, el

equipo utilizado para el desarrollo soporta la virtualización por hardware mediante las extensiones

Intel VT-x y dispone de dos procesadores Xeon de cuatro núcleos, 32 GB de memoria principal y discos

SSD a modo de almacenamiento auxiliar (usado para las imágenes de los sistemas operativos), lo cual

alivia la carga adicional impuesta por el uso de sistemas virtualizados.

2.5.3 Mecanismos de control de calidad aplicados

durante la redacción del proyecto

Durante parte del desarrollo se han desplegado varias versiones parciales de la aplicación, corrigiendo

fallos y realizando ampliaciones sobre un sistema en producción. Para ello se ha tenido en cuenta los

datos generados por las versiones previas, proporcionando los mecanismos necesarios para la

migración de éstos a los nuevos prototipos. Además, se ha dispuesto de mecanismos para cancelar las

actualizaciones en curso y restaurar las versiones objeto de remplazo en caso de que el nuevo

despliegue presentase errores o la migración no se pudiese llevar a cabo con las garantías suficientes.

Para asegurarnos de la calidad de las diferentes versiones desplegadas y, en general, de la aplicación

desarrollada y facilitar la localización de errores y, en su caso, cuándo y dónde se han introducido se

han utilizado cuatro herramientas:



PHPUnit

Utilizando PHPUnit se han definido tests unitarios para partes críticas de la aplicación, asegurándonos

así de que los cambios introducidos en cada versión no introducen errores en partes desarrolladas

previamente. Además, se han utilizado las funcionalidades disponibles para generar informes de

cobertura y pruebas fallidas, teniendo así estadísticas de las partes de la aplicación testadas.

Log4php

Log4php ha sido utilizado como sistema de logging para mostrar mensajes detallados de depuración.

Una de las características clave utilizada es la posibilidad de definir su configuración a través de

archivos XML, de forma que, sin alterar el código fuente, permite definir configuraciones separadas

para el desarrollo (mostrando los mensajes en la consola del intérprete de PHP), para el entorno de

producción (guardando los mensajes en archivos de texto para su análisis posterior cuando ha sido

necesario) y para la ejecución de las baterías de pruebas (ocultando por defecto todos los mensajes de

depuración).

Git

Como sistema de control de versiones del código fuente se ha utilizado Git, de forma que siempre se

ha dispuesto de un histórico de los cambios realizados y la posibilidad de deshacer los cambios que

han introducido problemas. Otra ventaja adicional proporcionada por Git ha sido la independencia del

entorno de desarrollo del repositorio donde se ha almacenado el código, posibilitando (por ejemplo)

la reinstalación del sistema utilizado para la programación (tras la cual solo ha sido necesario volver a

descargar el código fuente del proyecto desde el repositorio en lugar de tener que recurrir a copias de

seguridad realizadas manualmente) y la simplificación del proceso de realización de copias de

seguridad en sistemas externos (utilizando SSH para copiar todo el repositorio, incluyendo el histórico

de cambios, a un disco en la nube de forma periódica).

Duplicity

Duplicity es una utilidad de línea de comandos para la realización de copias de seguridad a través de

la red en sistemas externos. Durante el proyecto ha sido utilizado para realizar copias de seguridad

(tanto incrementales como completas) del repositorio Git y almacenarlas en un sistema remoto e

independiente proporcionado por Livedrive Internet en el Reino Unido. Estas copias de seguridad son

encriptadas utilizando AES-256 y enviadas a través de conexiones SSH. Además, este servidor también

ha sido utilizado para guardar los borradores y archivos asociados de la memoria y documentación del

proyecto.



2.5.4 Otras referencias

A continuación se incluye una introducción a algunos frameworks de desarrollo web utilizados en la

aplicación.

Doctrine

El Proyecto Doctrine es un conjunto de librerías open source utilizadas para proporcionar

servicios de persistencia de objetos en PHP a través de Mapeo Objeto-Relacional (Object-

Relational Mapping, ORM) y una Capa de Abstracción de Base de Datos (Database Abstraction

Layer).

Entre las características principales de Doctrine está la posibilidad de acceder a la información

almacenada en la base de datos como entidades (utilizando conceptos clásicos de Entidad-Relación),

la independencia (hasta cierto punto) del gestor de bases de datos utilizado, la comprobación en

tiempo de ejecución de la integridad de la información (por ejemplo, entidades relacionadas y tipos de

datos) y la optimización automática de los accesos a la base de datos.

Bootstrap

Bootstrap es un framework libre para el desarrollo de interfaces web HTML5,

proporcionando un conjunto de clases CSS e iconos optimizados y probados en

diferentes navegadores y dispositivos. Además, está diseñado específicamente para ser

multidispositivo, simplificando el desarrollo simultáneo para distintos navegadores,

dispositivos (por ejemplo, PCs, teléfonos móviles y tablets) y tamaños de pantalla.

Composer

Composer es un gestor de dependencias para librerías escritas en PHP. A diferencia de

los gestores de dependencias tradicionales (como, por ejemplo, Apt o PEAR), Composer

gestiona dependencias por proyecto, de forma que las librerías utilizadas son

mantenidas como parte del código fuente de éste (y, en nuestro caso, son almacenadas

junto al resto del proyecto en el repositorio Git).

Entre las ventajas de utilizar un gestor de dependencias están la independencia de éstas (y de sus

mecanismos de carga) del resto de la aplicación, la resolución automática, descarga e instalación de

las librerías utilizadas y de las librerías de las cuales dependen éstas, y la posibilidad de actualizar de

forma automática todas las librerías utilizadas (en lugar de tener que actualizarlas una a una).



2.6 Alcance

El sistema desarrollado viene a remplazar una aplicación existente, mejorando su usabilidad y

haciendo más sencillo su posterior mantenimiento. El nuevo sistema se ejecuta sobre un entorno Linux

y ha sido desarrollado utilizando exclusivamente herramientas, componentes y librerías de libre

distribución.

Para ello, se ha reescrito y ampliado la aplicación existente para que haga uso de las nuevas

características disponibles en las últimas versiones de PHP, se ha reestructurado la misma en módulos

bien definidos y se ha simplificado la gestión de las dependencias externas, realizando una separación

explícita entre éstas y la aplicación propiamente dicha, obteniendo como resultado una estructura más

clara del sistema y una disminución de los requisitos computacionales necesarios para la misma.

Además se ha dotado al sistema de una nueva interfaz más moderna tanto en la parte pública como

en la administrativa, utilizando los últimos avances disponibles en tecnologías web, como AJAX y CSS3,

con el objetivo de mejorar la experiencia del usuario y minimizar los tiempos de respuesta.

También se han implementado nuevas características demandadas por la organización del congreso,

como la gestión de las salas disponibles durante la conferencia y excursiones, la generación de

calendarios digitales o la posibilidad de configurar, verificar el funcionamiento y depurar en tiempo

real el sistema de envío de notificaciones por correo electrónico.

2.7 Hipótesis y restricciones

La organización de la conferencia ha establecido que la aplicación a desarrollar debe de ejecutarse

sobre un sistema Linux y no debe incluir dependencias a software que no sea de libre distribución.

Además, las herramientas necesarias para su posterior mantenimiento también deben estar

disponibles bajo licencias open source.

Es necesario disponer de una implementación (al menos parcial) del software a desarrollar en marzo

de 2014 con objeto de poder utilizarlo para gestionar el registro de los primeros asistentes a la

conferencia meses antes de la celebración del congreso y poder así solucionar los posibles errores que

surjan. Para ello, deberán de proporcionarse los mecanismos necesarios para la actualización de la

aplicación estando ésta ya operativa sin pérdida de datos. Además, la aplicación debe ejecutarse sobre

una máquina dentro de la red de la Escuela Politécnica de Ingeniería de la Universidad de Oviedo.

Planificación y presupuesto | Plataforma web para la gestión de conferencias científico-técnicas


3 PLANIFICACIÓN Y PRESUPUESTO

3.1 Planificación temporal

Debido a la necesidad de disponer de una versión funcional de la aplicación en un corto espacio de

tiempo, el desconocimiento inicial del funcionamiento del congreso por parte del desarrollador y la

poca disponibilidad de tiempo para su desarrollo durante los meses iniciales, el proyecto ha sido

desarrollado utilizando un proceso iterativo similar al modelo de desarrollo ágil Scrum. Las principales

características de esta forma de trabajo son:

Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución

completa del producto.

Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos

autoorganizados, que en la calidad de los procesos empleados.

Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un

ciclo secuencial o de cascada.

Las pruebas de la aplicación se han distribuido entre las realizadas sobre la aplicación desplegada en

un sistema en producción con usuarios reales, las realizadas como parte del ciclo normal del desarrollo

y las realizadas en la última etapa del proyecto por medio de tests unitarios.

Scrum divide el proceso de desarrollo en versiones parciales potencialmente entregables (funcionales),

realizadas en plazos o iteraciones denominadas sprints. Estos sprints, a su vez, están agrupados en

diferentes fases en función de los aspectos o funcionalidades de la aplicación tratadas en ellos. Las

pruebas de software se realizan durante todo el ciclo de desarrollo, si bien en nuestro caso, además,

se ha dedicado una iteración adicional al análisis de la cobertura de código. La documentación del

proyecto propiamente dicha se inició durante el decimonoveno sprint.

A continuación se incluye la lista de sprints en los que se ha dividido el desarrollo, agrupados e

incluyendo sus fechas de inicio y fin, junto a una breve lista de las tareas realizadas en cada uno, para

posteriormente mostrar gráficamente la planificación temporal del proyecto mediante un diagrama

de Gantt.

Plataforma web para la gestión de conferencias científico-técnicas | Planificación y presupuesto


Fase 1: Evaluación inicial de la aplicación heredada 2013-10-04 – 2013-10-27

Sprint 1 (2013-10-04 – 2013-10-24)

- Estudio de alternativas: Disponibilidad de versiones de PHP en pirweb9, patrones

de diseño aplicables, y herramientas y librerías útiles. - Modificaciones en la aplicación original para poder ser ejecutada sobre PHP5. - Refactorización básica siguiendo el patrón MVC.

Sprint 2 (2013-10-25 – 2013-10-27)

- Reorganización inicial del código original del panel de administración en

controladores.

Fase 2: Adaptación de la aplicación a MVC 2013-10-28 – 2013-11-18

Sprint 3 (2013-10-28 – 2013-11-02)

- Mayor separación MVC en script principal, login y módulo de gestión de usuarios.

Sprint 4 (2013-11-03 – 2013-11-18)

- Mayor separación MVC en las páginas de la web pública.

Fase 3: Adopción de buenas prácticas de IS 10 2013-11-18 – 2013-12-12

Sprint 5 (2013-11-18 – 2013-11-20)

- Permitir que el directorio de plantillas sea configurable.

Sprint 6 (2013-11-20 – 2013-11-29)

- Remplazar mysql_query() y wrappers MySQL por Doctrine.

Sprint 7 (2013-11-30 – 2013-12-08)

- Convertir las hojas de estilo CSS en plantillas.

- Completar la separación de las páginas de usuario en MVC jerárquico. - Generar los archivos PDF en el directorio temporal del sistema.

Sprint 8 (2013-12-09 – 2013-12-12)

- Cargar el texto de los correos electrónicos generados desde plantillas. - Mover el código para generar los archivos PDF a controladores.

Fase 4: Gestión automática de código y dependencias 2013-12-13 – 2014-01-06

Sprint 9 (2013-12-13 – 2013-12-13)

- Simplificar el formato de los datos usados para la autocarga de clases. - Mostrar el usuario utilizado para hacer login en las páginas de administración.

Sprint 10 (2013-12-14 – 2014-01-06)

- Cargar el sistema de plantillas Twig a través de Composer.

- Usar plantillas para generar los documentos PDF.

- Unificar la generación de documentación PDF del panel de administración en MVC. - Eliminar comprobaciones de permisos redundantes.

Fase 5: Mejoras visuales en las páginas de gestión 2014-01-07 – 2014-01-15

Sprint 11 (2014-01-07 – 2014-01-15)

- Reescribir las vistas del panel de administración utilizando Bootstrap. - Cargar las librerías phpExcel y mPDF utilizando Composer.

9 pirweb.edv.uniovi.es es el nombre del servidor utilizado para hospedar la aplicación. 10 IS hace referencia a las siglas de Ingeniería de Software



Fase 6: Mejoras de rendimiento 2014-01-16 – 2014-02-06

Sprint 12 (2014-01-16 – 2014-02-06)

- Servir cada página de administración desde una URL independiente (HMVC).

- Modificar form actions para no enviar parámetros por GET.

Fase 7: Simplificación y reorganización 2014-02-07 – 2014-02-21

Sprint 13 (2014-02-07 – 2014-02-10)

- Unificar modelos.

- Simplificar espacios de nombres.

Sprint 14 (2014-02-11 – 2014-02-17)

- Instanciar los modelos a partir de sus definiciones de interfaz. - Separar la configuración general y la información personal de la configuración e

información de facturación en la base de datos.

Sprint 15 (2014-02-18 – 2014-02-21)

- Mover la configuración estática a un archivo .ini. - Mover los archivos usados para generar correos electrónicos y PDFs a un directorio

privado.

- Registrar los mensajes de depuración utilizando log4php.

Fase 8: Despliegue de primer prototipo público 2014-02-22 – 2014-04-07

Sprint 16 (2014-02-22 – 2014-03-14)

- Parametrizar las URLs usadas desde las plantillas HTML. - Utilizar Bootstrap en las páginas de editores.

- Permitir que los parámetros de conexión a la BBDD sean configurables.

Sprint 17 (2014-03-15 – 2014-03-27)

- Migración de los datos de la web original desde pirweb. - Permitir modificar la configuración de envío de correo desde la interfaz web.

- Parametrizar el ISBN y hacerlo configurable desde la interfaz web. - Permitir que el plazo de envío pueda abrirse y cerrarse desde la interfaz web. - Utilizar Bootstrap en la web pública.

Sprint 18 (2014-03-28 – 2014-04-07)

- Corrección de errores detectados en prototipo.

- Permitir registrar un ISSN configurable. - Añadir funcionalidades de instrumentación y recolección de estadísticas.

Fase 9: Publicación de calendarios y funciones AJAX 2014-04-08 – 2014-05-06

Sprint 19 (2014-04-08 – 2014-05-06)

- Gestión de fechas y salas de exposición de los posters.

- Editar los títulos y las fechas de conferencias y los títulos de artículos con AJAX.

- Exportar calendarios de conferencias y exposición de posters (iCal). - Resaltar las filas seleccionadas en los listados de las páginas de administración. - Abrir los enlaces a los archivos PDF en pestañas separadas. - Unificar los modelos de justificantes y facturas. - Primer borrador de la documentación.

Sprint 20 (2014-05-07 – 2014-05-07)

- Borrado de salas. - Incluir las fuentes TrueType como parte del proyecto debido a cambios en las

librerías usadas.



Fase 10:Corrección de errores 2014-05-08 – 2014-05-31

Sprint 21 (2014-05-08 – 2014-05-15)

- Corregir un error que impedía enviar nuevas versiones de artículos existentes.

- Permitir la ordenación por fecha en la tabla de artículos.

Sprint 22 (2014-05-16 – 2014-05-31)

- Mejoras gráficas y funcionales en la página de estadísticas. - Corregir errores en los archivos Excel de usuarios y artículos.

- Refactorización de clases del espacio de nombres CMMSE a CMMSE\Core. - Mover la gestión de salas a su propio modelo desde el modelo de artículos.

Fase 11: Cambios no planificados 2014-06-01 – 2014-06-10

Sprint 23 (2014-06-01 – 2014-06-10)

- Añadir referencia a la LOPD en la página de registro.

- Borrar la información de facturación de los usuarios cuando son eliminados. - Incluir nuevos tamaños para las etiquetas. - Añadir soporte para gestionar excusiones. - Generar etiquetas para las excursiones.

Pruebas 2014-02-17 – 2014-06-21

- Definición de pruebas unitarias para todos los modelos, entidades, decoradores,

vistas y controladores usados para generar archivos PDF, y clases del núcleo de la aplicación.

- Análisis de cobertura de código de las pruebas unitarias.

Documentación 2014-04-08 – 2015-05-31

Fase 1 (2014-04-08 – 2014-07-25)

- Redacción de borradores iniciales:

o Introducción a las tecnologías usadas. o Análisis (requisitos, casos de uso, escenarios). o Documentación de pruebas unitarias.

Fase 2 (2014-08-07 – 2014-12-13)

- Finalización de la redacción del apartado de análisis: o Estudio de alternativas consideradas. o Disposiciones legales. o Presupuesto.

o Planificación temporal preliminar. - Diseño:

o Diseño de clases y diagramas UML. o Documentación de diseño de funcionalidades dinámicas. o Diseño físico de datos y normalización.

- Manual de instalación.

- Reestructuración completa del documento.

Fase 3 (2015-03-30 – 2015-05-31)

- Manuales de usuario, administrador y editor. - Actualización del apartado de planificación. - Diseño: Particionamiento físico de subsistemas.

- Correcciones en estructura y presentación. - Apéndices.



Figura 3.1: Diagrama de Gantt de la planificación temporal del proyecto



Durante las fases finales del desarrollo se han realizado varios despliegues de la aplicación en un

sistema en producción. Esto ha permitido la inscripción de los asistentes antes de tener la aplicación

completamente finalizada, a la vez que ha ayudado a detectar y corregir errores de forma rápida

mientras se realizaba una prueba real de su funcionamiento. A continuación se incluye la lista de los

27 despliegues realizados.

Marzo 2014

1 de Marzo de 2014

8 de Marzo de 2014

21 de Marzo de 2014

25 de Marzo de 2014

26 de Marzo de 2014

28 de Marzo de 2014

31 de Marzo de 2014

Abril 2014

3 de Abril de 2014

10 de Abril de 2014

15 de Abril de 2014

16 de Abril de 2014

21 de Abril de 2014

29 de Abril de 2014

30 de Abril de 2014

Mayo 2014

1 de Mayo de 2014

2 de Mayo de 2014

5 de Mayo de 2014

6 de Mayo de 2014

7 de Mayo de 2014

15 de Mayo de 2014

18 de Mayo de 2014

19 de Mayo de 2014

20 de Mayo de 2014

24 de Mayo de 2014

Junio 2014

5 de Junio de 2014

9 de Junio de 2014

10 de Junio de 2014



3.2 Resumen del presupuesto

ITEM CONCEPTO TOTAL

01 Costes relativos de ingeniería 18.240,00 €

02 Costes relativos a bienes, equipos y servicios informáticos 437,05 €

03 Costes relativos a consumibles 71,04 €

04 Costes relativos a aplicaciones informáticas 0,00 €

SUBTOTAL 18.748,09 €

IVA (21%) 3.937,10 €

TOTAL 22.685,19 €



3.3 Presupuesto

A continuación se incluye una estimación detallada de los costes derivados de la realización de

proyecto.

3.3.1 Costes relativos a ingeniería

Concepto Unidad Coste unitario Unidades Coste total

Analista Horas 16,00 € 160 2.560,00 €

Programador Horas 13,00 € 960 12.480,00 €

Pruebas Horas 15,00 € 160 2.400,00 €

Documentación Horas 8,00 € 100 800,00 €

TOTAL 18.240,00 €

3.3.2 Costes relativos a bienes, equipos y servicios

informáticos

Concepto Coste unitario Unidades Coste total

Dell Precision 690 (2ª mano) 165,19 € 1 165,19 €

16 GB RAM DDR2 ECC 159,46 € 1 159,46 €

Copia de seguridad (LiveDrive) Febrero – Septiembre

14,05 € 8 112,40 €

TOTAL 437,05 €

3.3.3 Costes relativos a consumibles

Concepto Coste unitario Unidades Coste total

Tóner 65,85 € 1 65,85 €

A4 – Papel borradores (x500) 2,65 € 1 2,65 €

A4 – Papel memoria (x480) 2,54 € 1 2,54 €

TOTAL 71,04 €



3.3.4 Costes relativos a aplicaciones informáticas

Concepto Coste unitario Unidades Coste obtenido

NetBeans 0,00 € 1 0,00 €

VirtualBox 0,00 € 1 0,00 €

Ubuntu 14 0,00 € 1 0,00 €

Windows 2008 R2 * 700,00 € 1 0,00 €

Office 2013 * 140,00 € 1 0,00 €

Debian 7 0,00 € 1 0,00 €

Apache 0,00 € 1 0,00 €

PHP 0,00 € 1 0,00 €

MySQL 0,00 € 1 0,00 €

Ant 0,00 € 1 0,00 €

PHPUnit 0,00 € 1 0,00 €

PHPLoc 0,00 € 1 0,00 €

TOTAL 0,00 €

(*) Obtenido con una licencia de estudiante

Plataforma web para la gestión de conferencias científico-técnicas | Especificación del sistema


4 ESPECIFICACIÓN DEL SISTEMA

4.1 Descripción de la situación actual

En el momento de iniciar el proyecto ya existía una implementación funcional de la aplicación, la cual

había sido utilizada en las ediciones anteriores del congreso. Esta aplicación se desarrolló ad hoc por

los organizadores, y era modificada en cada edición para adaptarla a las necesidades particulares que

iban surgiendo cada año.

Como consecuencia, existía una gran cantidad de código duplicado, no había una separación clara

entre componentes, y su mantenimiento y ampliación resultaban difíciles.

Además, la aplicación existente se ejecutaba sobre un servidor Windows, con los costes de licencias

que ello suponía; y estaba escrita utilizando una versión obsoleta de PHP, lo cual introducía diversos

problemas de compatibilidad y rendimiento, y potenciales problemas de seguridad al carecer ya de

actualizaciones.

4.2 Requisitos iniciales

La organización de la conferencia ha establecido como requisitos mínimos que el software a desarrollar

debe ejecutarse sobre un entorno Linux dentro de la red de la Universidad de Oviedo y que todas las

herramientas utilizadas deben ser de libre distribución. Además, la aplicación a desarrollar debe cubrir,

al menos, la funcionalidad proporcionada por otra aplicación web utilizada en ediciones anteriores

(registro de usuarios, artículos y cobros, la gestión de los mismos y la generación automática de

certificados y facturas).

Especificación del sistema | Plataforma web para la gestión de conferencias científico-técnicas


4.3 Estudios de alternativas y viabilidad

A continuación se describen de forma breve todas las alternativas de sistemas existentes, lenguajes,

servidores y componentes estudiadas durante la fase de análisis del proyecto.

4.3.1 Sistemas existentes de gestión de conferencias

ConfTool: Conference Management Tool

ConfTool es un sistema basado en una interfaz web para la organización de conferencias científicas,

congresos y seminarios. Ha sido utilizado en más de 1000 eventos y está disponible en más de 10

idiomas [CONFT01].

4.3.1.1.1 Ventajas

Sistema basado en web.

Posee varios roles de usuarios, incluyendo ponentes, administradores, editores y voluntarios.

Permite la realización de pagos mediante PayPal y/o tarjeta de crédito, y definir descuentos.

Permite enviar invitaciones.

Opciones de gestión de horarios

Envío masivo de correos a todos los participantes.

4.3.1.1.2 Inconvenientes

La versión gratuita soporta un máximo de 150 asistentes11.

El proceso de envío solo es configurable en las versiones de pago.

Algunas funcionalidades de facturación solo están disponibles en las versiones de pago.

11 La edición de este año se espera que ronde los 200 asistentes o más.



4.3.2 Gestores de bases de datos

PostgreSQL

PostgreSQL es un gestor de bases de datos relacionales open source sujeto a una licencia BSD (Berkeley

Software Distribution). Publicado inicialmente en 1995, se trata de un servidor de bases de datos

ampliamente testado con un especial énfasis en la extensibilidad y el soporte de los estándares SQL

(Structured Query Language).

4.3.2.1.1 Ventajas

Implementación fiel del estándar SQL.

Gran cantidad de características: GIS, búsqueda fulltext, varias opciones de replicación.

Completamente transaccional, cumpliendo fielmente las características ACID.

Control de acceso a través de multiversionado de datos, mejorando el rendimiento

concurrente.


Su uso en aplicaciones web está menos extendido que el de otras alternativas.

Configuración complicada.

El motor de almacenamiento utilizado no es configurable.

MySQL

MySQL, al igual que PostgreSQL, es un gestor de bases de datos relacionales open source sujeto a una

licencia GNU. Su primera versión data de 1995, y se trata de un servidor de bases de datos popular

cuyo uso en aplicaciones web está ampliamente extendido.

4.3.2.2.1 Ventajas

Uso extendido en aplicaciones web, con soporte para sus principales características de forma

nativa en la mayoría de lenguajes utilizados con ese propósito. Además, la amplia comunidad

de desarrolladores existente facilita la solución de problemas.

Posibilidad de configurar el motor de almacenamiento utilizado para cada tabla según se

necesite mayor rendimiento o un mejor soporte transaccional.

Soporte para texto Unicode y búsquedas indexadas sobre campos de texto completos.


Actualmente su desarrollo está en manos de Oracle, lo cual ha producido críticas respecto a la

forma en que ésta ha gestionado su mantenimiento y la implementación de nuevas

características.



No implementa el estándar SQL de forma completa, incluyendo el soporte para claves foráneas

en algunos de sus motores de almacenamiento.

Solo es completamente transaccional cuando sus tablas utilizan el motor de almacenamiento

InnoDB.

Algunas funcionalidades, como el soporte para claves foráneas, dependen del motor de

almacenamiento utilizado.

MariaDB

MariaDB es un sistema de gestión de bases de datos relacionales derivado de MySQL desarrollado por

voluntarios surgido con el propósito de que éstos mantengan el control del desarrollo de una solución

realmente open source tras la adquisición de MySQL por parte de Oracle. Se trata de un gestor con una

alta compatibilidad con MySQL, permitiendo remplazarlo sin necesidad de realizar cambios en las

librerías y programas existentes, a la vez que proporciona nuevas características no disponibles en sus

competidores.

4.3.2.3.1 Ventajas

Compatible con librerías y programas utilizados para conectar con servidores MySQL sin

necesidad de realizar cambios en ellos.

Soporte para tablas MyISAM (importadas desde MySQL) de forma segura y transaccional,

incluyendo archivos de recuperación de transacciones (log).

Mayor número de motores de almacenamiento respecto a MySQL, incluyendo remplazos

compatibles a nivel binario con MyISAM e InnoDB.

Mejor rendimiento que sus competidores en subconsultas y conversiones entre juegos de

caracteres.

Informe del estado de procesos, mostrando el porcentaje completado para operaciones que

modifican la estructura de la base de datos (como la modificación de la definición de tablas y

la creación de índices) o la carga de datos a partir de archivos.

Soporte para columnas virtuales.


Parte de las características nuevas (respecto a MySQL) requieren soporte adicional en las

librerías y/o programas utilizados.

Uso menos extendido que la distribución MySQL tradicional.



4.3.3 Servidores web

Actualmente12 la mayor parte de los sitios activos (esto es, sitios administrados activamente por

humanos en lugar de ser generados automáticamente para actividades publicitarias) utilizan como

servidor web Apache o, en menor medida, nginx e IIS, representando aproximadamente el 83% de los

sitios web [HTTP04]. A continuación se incluye, para cada uno, una breve introducción, listando sus

principales características.

Apache

El Servidor Web Apache (comúnmente denominado simplemente como Apache) es un servidor web

open soure conocido por haber tenido un papel fundamental en el crecimiento inicial de Internet.

Basado inicialmente en el servidor HTTP de la NSA, su desarrollo se inició en 1995 (momento en el cual

el desarrollo del servidor de la NSA dejó de avanzar) y continúa activamente en la actualidad [APCH01].

Internamente Apache está construido como un conjunto de módulos software que interactúan entre

sí y gestionan las distintas etapas necesarias para procesar cada solicitud de manera colaborativa,

incluyendo la traducción de direcciones, la autentificación, la generación dinámica de contenido o la

gestión de la seguridad.

Como consecuencia de esto, Apache puede ser ejecutado en los sistemas operativos más usados (como

Windows y las principales variantes de UNIX, incluyendo Linux), y es altamente configurable para cubrir

las necesidades particulares de cada aplicación. Entre sus características más notorias están

[APACH01]:

Soporte para hosts virtuales: Esto permite el uso de un único servidor para servir varios

dominios, cada uno con su configuración independiente, sus propios registros de actividad y

sus propios conjuntos de archivos, sirviendo, por tanto, como un contenedor para múltiples

aplicaciones web.

Generación dinámica de contenido: Bien a partir de módulos del servidor, o bien a través de

contenedores de scripts CGI, permite la implementación de aplicaciones que generan los

contenidos a enviar a los usuarios en el momento en que éstos los solicitan.

Compresión transparente de datos: Utilizando gzip o deflate según las preferencias del

navegador, Apache comprime automáticamente las páginas antes de enviarlas al cliente,

ahorrando recursos de red (a costa de aumentar el uso de CPU del servidor).

Reescritura de direcciones URL: Esto permite presentar al cliente una estructura de direcciones

virtual que el servidor mapea de forma automática a los archivos almacenados en el servidor.

Uso como proxy: Uno de los usos típicos de Apache es servir de proxy, bien de forma general

para una red LAN, o bien para diferenciar y asignar las solicitudes a otros servidores en función

del tipo de contenido solicitado, origen u otros parámetros.

Modo de funcionamiento mutihilo y/o multiproceso: Dependiendo del sistema operativo

utilizado y de la configuración del servidor, Apache puede operar utilizando un pool de

12 Junio 2014.



procesos (en el que cada proceso atiende una solicitud cada vez), un único proceso con varios

hilos (utilizando un hilo para cada solicitud individual) o una combinación de éstos.

Por otra parte, Apache ha sido tradicionalmente considerado como un servidor web lento (en

comparación a sus competidores), debido a su modelo multiproceso (usado por defecto en sus

implementaciones UNIX) y a la sobrecarga impuesta por su construcción estrictamente modular. En

sitios web de alto tráfico ésto es normalmente solventado utilizando servidores web software

alternativos para servir la parte estática de la aplicación (como las imágenes), mientras que Apache es

usado únicamente para generar las partes dinámicas de los mismos (en las cuales la latencia a la hora

de servir los contenidos suele depender más de la propia aplicación que del servidor HTTP utilizado).

nginx

El desarrollo de nginx comenzó en 2008 con el objetivo de proporcionar un servidor web

multiprotocolo con un alto grado de concurrencia, alto rendimiento y un uso de memoria reducido. Al

igual que Apache, se trata de un servidor web open source modular apto para ser usado como servidor

HTTP, proxy o de caché (entre otros) y soporta distintas variantes de UNIX. Sin embargo, su soporte

para Windows se considera experimental.

En general, soporta las mismas funcionalidades de Apache (incluyendo hosts virtuales, compresión de

datos, reescritura de direcciones y su uso como proxy), y es comúnmente utilizado como remplazo de

éste en situaciones en las que se requiere un alto rendimiento o un uso reducido de memoria. Además,

puede ser utilizado como servidor proxy de correo (SMTP o POP3).

Entre sus características principales se pueden citar:

Modelo asíncrono de gestión de solicitudes: En lugar de utilizar un proceso o hilo dedicado a

atender cada solicitud, nginx utiliza un enfoque basado en eventos no bloqueante, en el cual

uno o varios procesos esperan a que el sistema operativo informe de que las distintas tareas

necesarias para atender una solicitud se hayan completado, continuando el procesamiento del

resto. Esto permite realizar la E/S a disco o a red de manera simultánea para todos los clientes,

y evita el uso adicional de memoria asociado a mantener procesos dedicados a ello.

Generación dinámica de contenido: Utilizando FastCGI, nginx puede ser utilizado como

servidor de aplicaciones web que se ejecutan como procesos independientes escritas en

cualquier lenguaje de programación.

Limitación de uso de ancho de banda, evitando que los clientes con mayor capacidad de

descarga saturen el servidor y degraden el servicio ofrecido al resto de usuarios.

Soporte nativo para nuevas tecnologías, como el streaming de FLV y MP4, el protocolo SPDY o

WebSockets.

Por otra parte, tradicionalmente el uso de nginx no ha estado tan extendido como el de sus

alternativas, y su desarrollo comenzó más de una década después de sus principales competidores,

por lo que ni ha sido tan testado ni tiene el mismo nivel de uso que éstos, y es utilizado principalmente

en situaciones en las que es permisible sacrificar la compatibilidad y fiabilidad proporcionada por los

sistemas tradicionales para obtener un gran rendimiento. Por esta razón, habitualmente es empleado

únicamente como servidor de datos estáticos o como proxy.



IIS

Internet Information Services (IIS) es un conjunto de servicios para Windows, incluyendo un servidor

web, FTP y de correo electrónico, distribuidos de serie como parte de las versiones de servidor del

sistema operativo. A diferencia de las dos alternativas anteriores, no es multiplataforma y solo puede

ejecutarse sobre Windows, su código fuente es cerrado y requiere poseer (y haber pagado) una licencia

de Windows Server. Entre sus características principales destacan:

Administración centralizada de servidor por medio de una interfaz gráfica, integrada en las

herramientas de administración estándar de Windows Server.

Soporte para la generación dinámica de contenido, soportando aplicaciones ASP.NET de forma

nativa y otros lenguajes, como PHP, como scripts CGI.

Soporte para varios mecanismos de autentificación, incluyendo el control de acceso utilizando

credenciales de Windows o por medio de certificados digitales.

En cualquier caso, IIS no ha sido considerado como una alternativa viable para este proyecto debido a

sus costes de licencia, su naturaleza cerrada y la existencia de otras opciones más extendidas como

contenedores de aplicaciones escritas en PHP.

Aspectos más importantes a tener en cuenta

Las dos alternativas reales para este proyecto son Apache y nginx (ya que ISS solo se ejecuta en

Windows Server y tiene costes de licencias asociados). Los factores determinantes a la hora de

decantarnos por uno u otro son:

Fiabilidad respecto a rendimiento: Apache ejecuta los scripts PHP directamente en su espacio

de memoria, mientras que nginx utiliza procesos FastCGI independientes. Esto hace que los

posibles errores se propaguen al servidor en el caso de Apache (al menos en ciertos casos),

mientras que en nginx solo afectan al proceso que ejecuta el script. Además, nginx gestiona

las solicitudes de forma asíncrona mientras que Apache dedica a cada una un proceso hijo

completo. Por otro lado, los procesos FastCGI requieren memoria y tiempo de CPU adicional

debido a la comunicación entre procesos necesaria.

Conocimiento y soporte del servidor: La información disponible para la configuración de PHP

sobre Apache es mayor al ser la arquitectura tradicional. Además, Apache ha sido utilizado en

anteriores ediciones del congreso, y el servidor físico utilizado hospeda otras aplicaciones, por

lo que cambiar el servidor web requeriría mantener dos servidores web en funcionamiento

sobre la misma máquina o realizar un estudio adicional del impacto que tendría en el resto de

aplicaciones el cambio de servidor web.



4.3.4 Lenguajes de programación

Java EE

Java Platform Enterprise Edition es la distribución de Java de Oracle diseñada para el desarrollo y

despliegue de software empresarial, incluyendo servicios web y de red, siguiendo un diseño basado en

componentes modulares que se ejecutan en un servidor de aplicaciones [WIKI06].

4.3.4.1.1 Ventajas

Lenguaje totalmente orientado a objetos, lo cual facilita la encapsulación y la reutilización de

código.

Tipado estricto de variables, lo cual evita posibles errores debidos a conversiones automáticas

no deseadas y produce un código más claro.

Dispone de un amplio conjunto de librerías, frameworks y utilidades ampliamente testados.


Normalmente es necesario recurrir a frameworks adicionales para desarrollo web, como

Spring, para la gestión de JavaBeans, páginas JSP y el mantenimiento de datos de sesión.

Para la aplicación a desarrollar, utilizar Java imposibilita la reutilización de partes de la

implementación anterior desarrollada sobre PHP.

Los scripts deben ser compilados tras cada cambio realizado durante el desarrollo. En teoría

esto se realiza de forma transparente, en la práctica introduce problemas adicionales.

Para el desarrollo web con Java, a menudo es necesario seguir tediosos procedimientos de

configuración de librerías, conectores JDBC y archivos XML de definición de entorno.



PHP

PHP es un lenguaje de scripting diseñado principalmente para el desarrollo web, pero utilizado también

como lenguaje de propósito general. Posee una sintaxis sencilla y de fácil aprendizaje, y numerosos

componentes pensados especialmente para la creación de aplicaciones web.

Este lenguaje ya ha sido descrito con más detalle en el apartado de introducción de la memoria. De

manera resumida, y para el propósito de este apartado y de este proyecto, podemos citar las siguientes

ventajas e inconvenientes:

4.3.4.2.1 Ventajas

Se trata de un lenguaje de programación pensado desde sus inicios para la programación web,

por lo que dispone de una gran variedad de funcionalidades para este propósito.

Posee una mejor integración que sus competidores con bases de datos MySQL a través de

drivers nativos.

Compilación transparente de los scripts y páginas en el momento de su ejecución, lo cual

facilita el desarrollo. Además, al contrario de lo que ocurreo con algunos de sus competidores,

la compilación en el momento es el modo de funcionamiento esperado.

Permite el despliegue de aplicaciones web en sistemas de producción como programas

compilados a bytecode a través de extensiones de conversión de código, para los casos en los

que se necesite un mayor rendimiento sin sacrificar la facilidad de desarrollo del lenguaje

[FACEB01].

Dispone de repositorios para la instalación y uso de librerías (y sus dependencias) de forma

automatizada13.


Su soporte para la programación orientada a objetos no es tan maduro como el de otros

lenguajes.

La nomenclatura utilizada en gran parte de de su API es caótica.

Tiene un tipado no estricto de variables y parámetros, lo cual posibilita errores debidos a

conversiones automáticas no deseadas.

El desarrollo de su API no sigue un proceso de definición formal, lo que en ocasiones hace que

parte de su funcionalidad y sintaxis cambie de manera sustancial entre versiones (en ocasiones

sin mantener la retrocompatibilidad).

13 Por ejemplo, https://packagist.org para Composer.



4.3.5 Frameworks

Symfony2

Symfony es un framework open source para la creación de aplicaciones web empresariales sobre PHP

pensado para disminuir el tiempo de desarrollo a la vez que proporciona un control total sobre la

configuración y un amplio conjunto de componentes tanto propios como de otros proyectos.

4.3.5.1.1 Ventajas

Utiliza un patrón arquitectónico MVC que facilita la separación entre la lógica de la aplicación,

el acceso a datos y la presentación.

Proporciona autogeneración de código para módulos, modelos, base de datos, etc.

Integra Doctrine como ORM para el acceso a la base de datos.

Incluye soporte nativo para la programación de servicios AJAX.

Dispone de herramientas integradas para el desarrollo, incluyendo el soporte para despliegues

en producción.


La curva de aprendizaje del framework es alta.

Requiere portar la aplicación de una vez de forma prácticamente completa.

Zend Framework 2

Zend Framework 2 es un framework open source para la creación de aplicaciones web estructurado

en forma de componentes débilmente acoplados. Es desarrollado por la misma empresa que está

detrás del motor de PHP y proporciona soporte para las características más usadas en el desarrollo de

sitios web.

4.3.5.2.1 Ventajas

Desarrollado y mantenido por Zend, la empresa detrás del motor predeterminado de PHP.

Proporciona componentes para realizar programación utilizando el patrón MVC.

Permite la generación, envío y recepción de correos electrónicos a través de varios protocolos,

incluyendo POP3 e IMAP, de forma sencilla.

Dispone de un sistema de caché flexible, incluyendo soporte para guardar datos en archivos y

en memoria.


Zend Framework es más una librería de componentes que un framework completo.

Requiere portar la aplicación de una vez de forma prácticamente completa.



4.3.6 Sistemas de plantillas

Twig

Twig es un sistema de plantillas moderno desarrollado por los creadores del framework Symfony.

Desarrollado desde 2009, Twig es un componente integral de Symfony que ha demostrado ser un

sistema de plantillas robusto y seguro. Además es soportado por otros frameworks, incluyendo Zend,

Yii, Codeigniter y Drupal.

4.3.6.1.1 Ventajas

Herencia de plantillas de forma nativa, al ser compiladas como clases PHP.

Escapado automático de caracteres HTML en las variables, además de permitir definir filtros

personalizados.

Soporte para espacios de nombres de plantillas, permitiendo separar, por ejemplo, las

plantillas utilizadas para generar HTML de las utilizadas para generar CSS o correos.

Soporte para internacionalización.

Extensible mediante plugins.


Su sintaxis difiere significativamente de la de PHP (incluyendo la nomenclatura de las variables

y el acceso a datos miembro), lo cual dificulta su aprendizaje.

Smarty

Smarty es uno de los primeros sistemas de plantillas para PHP disponibles. Es famoso por su velocidad,

y durante años fue el estándar de facto para el uso de plantillas en PHP.

4.3.6.2.1 Ventajas

Uno de los sistemas de plantillas más veteranos para PHP.

Su sintaxis es más cercana a PHP que la de otras alternativas (lo cual también puede ser visto

como un inconveniente).

Soporte para varios métodos de escapado de caracteres (por ejemplo, para código HTML y

para código Javascript).


No hay escapado de caracteres por defecto, las plantillas deben declararlo en cada etiqueta.

El tiempo y memoria necesarios para compilar las plantillas es mayor que el de otras

alternativas [SMRT01].



4.4 Descripción de la solución propuesta

Para el desarrollo de la aplicación se ha optado por realizar un desarrollo a medida utilizando la última

versión de PHP disponible (5.5), realizando una implementación incremental de las nuevas

funcionalidades, y la migración de las existentes a partir del código original. El nuevo sistema utilizará

componentes de código abierto sobre un sistema Linux, eliminando los costes asociados a licencias de

software y simplificando la administración al ser un sistema operativo conocido tanto por los

organizadores del congreso como por los desarrolladores de la aplicación.

La utilización de PHP, al ser un lenguaje de amplio uso pensado, principalmente, para el desarrollo de

aplicaciones web, permite utilizar numerosas características, funcionalidades y librerías de terceros

necesarias para el proyecto de una forma sencilla. Por otra parte, las últimas versiones no requieren

el uso de una arquitectura tradicional basada en Apache, sino que permiten la ejecución de

aplicaciones directamente sobre el intérprete del lenguaje (a través de un servidor web básico incluido

por defecto), facilitando el desarrollo y depuración de la aplicación desde un equipo de escritorio Linux

independiente.

Además, facilita el mantenimiento y despliegue de la aplicación, al ser posible realizarlo de forma

automática (al menos parcialmente) a través de shell scripts, utilizando mecanismos nativos (como los

enlaces simbólicos para apuntar a la versión pública actual y el envío de las nuevas versiones a través

de conexiones seguras SFTP). Por otra parte, la posibilidad de realizar conexiones al servidor por medio

de una interfaz de consola segura permite el uso de herramientas UNIX estándar, como grep, para

diagnosticar problemas y realizar cambios en la configuración mediante una terminal de texto. Todos

estos factores resultan de vital importancia para llevar a cabo la administración de bajo nivel de la

aplicación (incluyendo la modificación de la configuración y el análisis de los ficheros de registro) de

forma rápida.

El uso de la última versión de PHP disponible al iniciar el proyecto permite utilizar características

interesantes de la programación orientada a objetos, como el uso de traits para permitir la herencia

horizontal de comportamientos comunes o el uso generalizado de mecanismos de herencia,

composición, y patrones de diseño. Además, el soporte disponible para la autocarga de código permite

simplificar la gestión y carga bajo demanda de las dependencias y de los componentes de la propia

aplicación.

El uso de los mencionados mecanismos orientados a objetos permiten el desarrollo por partes a partir

del código original de la aplicación, permitiendo intercambiar la implementación de las distintas

funcionalidades según se vayan desarrollando y asegurándonos de tener siempre una versión

funcional. Por la misma razón se ha descartado el uso de frameworks completos, como Symfony o

Zend Framework, pues su uso hubiese impedido tener una versión inicial usable en un tiempo

razonable (ya que debería haberse hecho una reescritura completa del sistema de una vez o haber

renunciado a características esenciales para disponer de una versión utilizable en el tiempo previsto).

Todos los componentes utilizados serán de libre distribución, de forma que no haya costes de

adquisición de los mismos, y serán gestionados, principalmente, a través del gestor de dependencias

Composer. Esto permite poder delegar la gestión de dependencias de las librerías utilizadas y facilita

las actualizaciones posteriores. Además, posibilita la gestión de las librerías por proyecto en lugar de



requerir la instalación de las mismas de forma global para todas las aplicaciones del sistema, lo cual

podría dar lugar a conflictos.

Además, el uso de productos desarrollados por la comunidad permite disponer de componentes de

uso extendido y ampliamente testados, minimizando la posibilidad de encontrar errores y facilitando

la obtención de documentación y soporte en caso de ser necesario a través de la web.

Para el acceso a la base de datos se utilizará Doctrine para proporcionar una capa de abstracción

orientada a objetos sobre las tablas SQL tradicionales, lo cual permite –al menos teóricamente–

mantener la independencia entre el gestor de bases de datos utilizado y la implementación de la

aplicación. Esto posibilitaría, en caso de ser necesario, la migración a otro gestor de bases de datos, en

principio incompatible, minimizando la necesidad de cambios en el código fuente de la aplicación.

La base de datos (tanto en producción como en desarrollo) estará gestionada por un servidor MySQL.

Se ha elegido MySQL por razones de compatibilidad y simplicidad, al ser el gestor utilizado en las

versiones previas de la aplicación y por otras aplicaciones hospedadas en el mismo servidor. En

cualquier caso, la aplicación podría utilizar cualquier otro servidor compatible si se considerase

interesante. En concreto, futuras versiones podrían utilizar un servidor MariaDB o Percona Server (que

proporcionan características adicionales respecto al estándar) si la organización lo estima oportuno y

viable teniendo en cuenta el resto de aplicaciones hospedadas.

Como sistema de plantillas se ha optado por utilizar Twig frente a otros debido a su uso extendido, la

disponibilidad de características deseables para la aplicación (en concreto, la posibilidad de definir

espacios de nombres para los archivos de plantillas o la extensibilidad general del proceso de

evaluación de su código), y su conocimiento previo por parte de los desarrolladores.

En el sistema en producción se ha optado por utilizar el clásico Apache, ya que es el servidor sobre el

que se han desarrollado el resto de aplicaciones alojadas en el servidor, y proporciona un equilibrio

entre características y rendimiento razonable para la carga de usuarios esperada.

Para la recolección de información de depuración se utilizará log4php (además de otros métodos), el

cual proporciona una alternativa de alto rendimiento para guardar información detallada no

estructurada sobre las actividades realizadas por la aplicación en cada solicitud en ficheros de texto,

permitiendo, además, acceder a esos mismos datos directamente durante el desarrollo a través de la

consola integrada del servidor nativo de PHP.

Por último, otra característica importante del sistema es su modularidad y extensibilidad. La aplicación

está construida como un conjunto de componentes débilmente acoplados y, en algunos casos (como

en las implementaciones de los modelos), intercambiables fácilmente. Esto permite cambiar las

versiones de las librerías, los conjuntos de plantillas e incluso los modelos utilizados realizando

modificaciones triviales en el código y de forma transparente para el resto de la aplicación. Además,

simplifica la implementación de nuevas características (como funcionalidades adicionales o roles de

usuario).



4.5 Actores del sistema

Durante el análisis de este proyecto se han encontrado cuatro tipos de actores diferentes, que son

descritos a continuación:

Invitado

Usuario de la aplicación no identificado. Un usuario es considerado invitado

mientras no haya proporcionado sus credenciales de acceso, y su interacción con el

sistema está limitada al registro de una nueva cuenta de ponente o la identificación

utilizando una cuenta de ponente, administrador o editor existente.

Ponente

Usuario de la aplicación identificado previamente correspondiente a la cuenta de un

asistente al congreso. Su interacción con el sistema está limitada al envío de

artículos y justificantes de pago, la solicitud de facturas o la modificación de sus

propios datos personales.

Administrador

Usuario de la aplicación identificado previamente perteneciente a la organización

del congreso. Los administradores tienen asignadas únicamente labores de gestión

de la conferencia, incluyendo la modificación y borrado del resto de cuentas de

usuarios, la revisión de pagos y artículos enviados, o la modificación de la

configuración de la aplicación.

Editor

Usuario de la aplicación identificado previamente correspondiente a la cuenta de un

editor de una revista o publicación científica. El acceso al sistema por parte de los

editores se limita al listado y descarga de los artículos enviados.



4.6 Catálogo de requisitos no funcionales

En esta sección se recopilan aquellos requisitos no relacionados con la funcionalidad esperada de la

aplicación. Se trata de condiciones que debe cumplir el entorno software donde se ejecutará la

aplicación o los equipos de los usuarios finales de la misma, aspectos relativos a la seguridad de los

datos almacenados y otros requisitos que es deseable que la aplicación cumpla para proporcionar una

experiencia de usuario positiva.

Los requisitos aquí listados han sido recopilados basándonos en las prácticas habituales existentes en

el desarrollo web, en la lista de restricciones iniciales del proyecto y en los aspectos mejorables

observados en la aplicación que este proyecto viene a remplazar.

Para mantener una estructura similar a la que se seguirá durante el análisis de requisitos funcionales,

a los requisitos aquí listados se les asignará un nombre y un identificador. Para distinguirlos de los

requisitos funcionales, los identificadores de estos requisitos comienzan por NF.

4.6.1 Requisitos tecnológicos

Código Requisito

Nombre Requisito Descripción del Requisito

NF.1.1 Software del servidor La aplicación debe poder ejecutarse sobre un servidor con sistema operativo Linux que utilice Apache 2 como servidor web y permita la ejecución de aplicaciones PHP.

NF.1.2 Versión de PHP La aplicación debe poder ejecutarse sobre un servidor que cuente con una versión de PHP de la rama 5.x igual o mayor que la 5.5.

NF.1.3 Red UniOvi La aplicación debe poder ejecutarse correctamente (y toda su funcionalidad debe estar disponible) en servidores situados en la Red de la Escuela Politécnica de Ingeniería de Gijón.

NF.1.4 Sistema de gestión de bases de datos

La aplicación debe soportar que la base de datos que utiliza esté alojada en un servidor que ejecute una versión de Oracle MySQL de la rama 5.x y disponga del motor de almacenamiento InnoDB (u otro software compatible a nivel API y con características transaccionales similares).

NF.1.5 Software del cliente Los usuarios de la aplicación deben disponer de un navegador actual que soporte los estándares de HTML5 y CSS3 publicados por la W3C.

NF.1.6 Software de los administradores

Los administradores del sitio deben disponer de un navegador que soporte el uso de AJAX (además de cumplir los requisitos del punto NF.1.5)



4.6.2 Requisitos de seguridad

Código Requisito


NF.2.1 Cifrado de las contraseñas almacenadas

El sistema debe almacenar las contraseñas tras aplicarlas un algoritmo de encriptado o reducción criptográfica.

NF.2.2 Deshabilitado completo del acceso al sistema

El sistema dispondrá de un procedimiento para deshabilitar el acceso completo al mismo.

NF.2.3 Finalización automática de sesión

La sesión de usuario debe finalizar automáticamente por inactividad.

4.6.3 Requisitos de auditoría (instrumentación)

Código Requisito


NF.3.1 Almacenamiento de información de instrumentación

Para cada página servida se almacenará, de forma estructurada: identificador de sesión y de usuario, carga media del sistema y memoria utilizada, número de consultas SQL ejecutadas, IP del cliente y del proxy (si lo hubiera y ha sido posible su detección), tipo de solicitud HTTP, información de identificación del navegador del cliente, instante de inicio de la solicitud, instante en el que se almacenaron los datos e información de identificación del servidor que atiende la solicitud.

NF.3.2 Independencia de la gestión de instrumentación

Los datos de instrumentación se almacenarán tras generar la página a enviar al cliente.

4.6.4 Requisitos de tiempo de respuesta

Código Requisito


NF.4.1 Tiempo de generación de las páginas de usuario

Bajo condiciones normales, las páginas públicas deben generarse en un tiempo inferior a 5 segundos.

NF.4.2 Tiempo de generación de las páginas de administración

Bajo condiciones normales, las páginas de administración deben generarse en un tiempo inferior a 10 segundos.

NF.4.3 Tiempo de generación de los archivos de documentación

Bajo condiciones normales y con un volumen inferior a 300 usuarios, los archivos de documentación (PDFs, archivos Excel…) deben generarse en un tiempo inferior a un minuto. Para un volumen de usuarios superior el tiempo necesario para generar los archivos de documentación debe ser proporcional a este último.



4.7 Análisis de requisitos funcionales

A continuación se incluye el listado completo de requisitos funcionales de la aplicación, clasificados

según su tipo en diferentes categorías.

4.7.1 Aspectos generales

Código Requisito


R.1.1 Roles de usuario El sistema debe proporcionar, al menos, dos roles de usuario: administrador y ponente.

R.1.2 Información de ponentes Para los ponentes el sistema almacenará: nombre, apellidos, título honorífico, dirección de correo electrónico, dirección y código postal, país, compañía y número de teléfono.

R.1.3 Validación de direcciones de correo electrónico

El sistema debe impedir que los usuarios se registren utilizando direcciones de correo electrónico no válidas.

R.1.4 Modificación de ponente Los ponentes deben poder modificar sus propios datos de registro, exceptuando su dirección de correo electrónico.

R.1.5 No duplicidad de direcciones de correo electrónico

El sistema debe garantizar que no haya varios usuarios registrados con la misma dirección de correo electrónico.

R.1.6 Listado de usuarios El sistema debe permitir a los administradores acceder a un listado de todos los ponentes registrados.

R.1.7 Borrado de usuarios El sistema debe permitir el borrado de cuentas de los ponentes junto a la información asociada a ellos.

4.7.2 Seguridad

Código Requisito


R.2.1 Solicitud de credenciales de acceso

Los usuarios deberán proporcionar una dirección de correo electrónico (u identificador equivalente) y una contraseña para acceder al sistema.

R.2.2 Cifrado de contraseñas Las contraseñas no deberán almacenarse en texto claro.

R.2.3 Longitud de contraseñas Las contraseñas no podrán ser vacías.

R.2.4 Finalización manual de sesión

Los usuarios deben poder terminar su sesión manualmente.

R.2.5 Modificación de contraseña de ponente

Los ponentes deberán poder modificar su contraseña.

R.2.6 Solicitud de contraseña previa a su modificación

El sistema debe solicitar la contraseña anterior antes de permitir el cambio de contraseña de un usuario.

R.2.7 Solicitud de confirmación de nueva contraseña

El sistema debe solicitar introducir dos veces la nueva contraseña antes de permitir el cambio de contraseña de un usuario.



4.7.3 Pagos

Código Requisito


R.3.1 Envío de justificantes El sistema permitirá el envío de justificantes de pago por parte de los ponentes.

R.3.2 Asociación de compañía a ponente

El sistema permitirá a los ponentes asociar una empresa o institución con su perfil a efectos de facturación.

R.3.3 Generación de facturas El sistema permitirá generar facturas para los ponentes asociados a una empresa o institución.

R.3.4 Generación de justificantes

El sistema permitirá generar justificantes de pago para los ponentes no asociados a una empresa o institución.

R.3.5 Confirmación de pagos El sistema permitirá a los administradores marcar el pago por parte de los ponentes como confirmado.

R.3.6 Modificación de cuota individual

El sistema permitirá a los administradores modificar manualmente la cantidad a pagar por cada usuario de manera individual.

R.3.7 Marcado de facturas listas

El sistema permitirá a los administradores marcar facturas como listas para imprimir.

R.3.8 Modificación cuota por defecto

El sistema permitirá a los administradores configurar la cuota a pagar por defecto para todos los asistentes.

R.3.9 No modificación de facturas listas

El sistema debe impedir modificar las facturas marcadas como listas para imprimir.

R.3.10 Asignación de números de factura de España

El sistema debe permitir la asignación automática de números de factura para los asistentes de España cuyo pago esté confirmado.

R.3.11 Asignación de números de factura de fuera de España

El sistema debe permitir la asignación automática de números de factura para los asistentes de fuera de España cuyo pago esté confirmado.

R.3.12 Independencia de secuencias de números de factura

Las secuencias de números de factura para la asignación automática a asistentes de España y de fuera de España deben ser independientes.

R.3.13 Modificación manual del número de secuencia de facturas de España

El siguiente número de factura a utilizar para la asignación automática de números de factura para los asistentes de España debe ser modificable de forma manual por los administradores.

R.3.14 Modificación manual del número de secuencia de facturas de fuera de España

El siguiente número de factura a utilizar para la asignación automática de números de factura para los asistentes de fuera de España debe ser modificable de forma manual por los administradores.

R.3.15 Acceso a justificantes de pago

El sistema debe mantener y permitir el acceso por parte de los administradores a los justificantes de pago enviados por los asistentes.



4.7.4 Simposios

Código Requisito


R.4.1 Definición de simposios El sistema permitirá a los administradores introducir, para cada simposio celebrado durante la conferencia, su nombre y su fecha y hora de inicio.

R.4.2 Modificación de simposios

El sistema permitirá a los administradores la edición de los datos de los simposios ya definidos.

R.4.3 Eliminación de simposios El sistema permitirá a los administradores el borrado de los simposios ya definidos.

R.4.4 No eliminación de simposios no vacíos

El sistema no permitirá el borrado de simposios mientras haya papers asignados a ellos.

4.7.5 Envío de papers

Código Requisito


R.5.1 Envío de papers El sistema permitirá el envío de papers por parte de los ponentes.

R.5.2 Envío de nuevas versiones de papers

El sistema permitirá un número ilimitado de envíos de nuevas versiones de los papers una vez que el envío original haya sido aprobado.

R.5.3 Solicitud de datos de paper

El sistema solicitará al usuario que envía un paper un título y una lista de autores asociados al mismo.

R.5.4 Comprobación de datos básicos de paper

El sistema comprobará que todos los papers tienen un título no vacío asignado y, al menos, un autor.

R.5.5 Almacenamiento de papers

El sistema mantendrá disponible siempre, al menos, la primera y la última versión enviada de cada paper.

R.5.6 Marcado de papers tipo poster

El sistema permitirá indicar que un paper es de tipo poster al enviarlo.

R.5.7 Borrado de nuevo paper El sistema permitirá el borrado de papers individuales por parte del ponente que los envió mientras éstos no hayan entrado en proceso de revisión.

R.5.8 No borrado de papers en plazo cerrado

El sistema no permitirá a los ponentes el borrado de papers si el plazo de envío está cerrado.

R.5.9 No borrado de papers en proceso de revisión

El sistema no permitirá a los ponentes el borrado de papers una vez que éstos se encuentren en proceso de revisión.

R.5.10 Asociación de salas a posters

El sistema permitirá a los administradores asociar una sala a los papers de tipo poster.

R.5.11 Asociación de fechas a posters

El sistema permitirá a los administradores asociar una fecha y hora de inicio y una fecha y hora de fin de exposición para los papers de tipo poster.

R.5.12 Carácter opcional de la información de gestión de posters

La asociación de fechas y salas a los papers de tipo poster debe ser opcional.



Código Requisito


R.5.13 Deshabilitado de edición de papers.

El sistema debe permitir a los administradores habilitar o deshabilitar el envío y edición de papers por parte de los ponentes.

R.5.14 Edición de título de papers

El sistema debe permitir a los administradores editar el título de cualquier paper enviado.

R.5.15 Listado de papers El sistema debe permitir a los administradores acceder al listado completo de papers enviados.

4.7.6 Salas

Código Requisito


R.6.1 Definición de salas El sistema permitirá a los administradores introducir un nombre para cada sala disponible durante la conferencia.

R.6.2 Edición de salas El sistema permitirá a los administradores la edición del nombre de las salas ya definidas.

R.6.3 Eliminación de salas El sistema permitirá a los administradores el borrado de las salas ya definidas.

R.6.4 No eliminación de salas en uso

El sistema no permitirá el borrado de salas mientras haya posters asignados a ellas.

4.7.7 Envío de notificaciones por correo electrónico

Código Requisito


R.7.1 Notificación registro de nuevo usuario

El sistema enviará una notificación por correo electrónico a una lista de direcciones definida cuando se registre un nuevo usuario.

R.7.2 Notificación envío de nuevo paper

El sistema enviará una notificación por correo electrónico a una lista de direcciones definida cuando los usuarios envíen nuevos papers.

R.7.3 Notificación envío de nueva versión de paper

El sistema enviará una notificación por correo electrónico a una lista de direcciones definida cuando los usuarios suban nuevas versiones de los papers.

R.7.4 Modificación de direcciones receptoras de notificaciones

La lista de direcciones de correo a las que enviar las notificaciones debe ser editable desde el panel de administración.

R.7.5 Edición de configuración de envío de correos

La configuración del envío de correos debe ser editable desde el panel de administración.

R.7.6 Envío de correos de prueba

El sistema debe permitir a los administradores enviar correos de prueba a cualquier dirección para comprobar el funcionamiento del envío de correos.

R.7.7 Envío de correos desde la red EPI

El sistema debe poder enviar correos electrónicos desde un servidor situado en la red de la Escuela de Ingeniería de Gijón.



4.7.8 Generación de calendarios

Código Requisito


R.8.1 Generación de calendarios

Se debe proporcionar acceso a calendarios en formato digital con información de la planificación del congreso.

R.8.2 Actualización de calendarios

Los calendarios deben actualizarse en tiempo real.

R.8.3 Accesibilidad móvil de calendarios

Los calendarios deben poder leerse desde dispositivos móviles Android.

R.8.4 Acceso anónimo a calendarios

Los calendarios deben ser accesibles sin necesidad de autentificación previa.

R.8.5 Calendario de simposios Se debe proporcionar un calendario con los horarios de los simposios.

R.8.6 Calendario de posters Se debe proporcionar un calendario con los horarios de exposición de los posters.

4.7.9 Información estadística

Código Requisito


R.9.1 Muestra de número de papers enviados

El sistema mostrará a los administradores información agregada sobre el número de papers enviados.

R.9.2 Muestra de número de papers aceptados

El sistema mostrará a los administradores información agregada sobre el número y proporción de papers aceptados.

R.9.3 Muestra de número de ponentes registrados

El sistema mostrará a los administradores información sobre el número de ponentes registrados.

R.9.4 Muestra de número y proporción de pagos realizados

El sistema mostrará a los administradores información sobre el número y proporción de ponentes que han pagado.

R.9.5 Representación gráfica del número y proporción de pagos realizados

El sistema mostrará a los administradores gráficamente información sobre el número y proporción de ponentes que han pagado.

R.9.6 Muestra de número y proporción de papers aceptados

El sistema mostrará a los administradores gráficamente información sobre el número y proporción de papers aceptados.

R.9.7 Representación gráfica agregada de la procedencia de los ponentes

El sistema mostrará a los administradores gráficamente información sobre el país de procedencia de los asistentes al congreso.

R.9.8 Listado de autores El sistema mostrará a los administradores un listado de los usuarios registrados con papers enviados.



4.7.10 Limitación de acceso

Código Requisito


R.10.1 Deshabilitar acceso público

El sistema permitirá a los administradores deshabilitar el acceso al sistema para usuarios no administradores.

R.10.2 Deshabilitar nuevos registros

El sistema permitirá a los administradores deshabilitar el registro de nuevos usuarios.

4.7.11 Generación de documentación

Código Requisito


R.11.1 Descargar listado Excel de asistentes

El sistema permitirá a los administradores descargar un listado de los asistentes al congreso en un fichero en formato Excel.

R.11.2 Descargar listado HTML de asistentes

El sistema permitirá a los administradores descargar un listado de los asistentes al congreso en un fichero en formato HTML.

R.11.3 Descargar certificados de asistencia individuales

El sistema permitirá a los administradores generar certificados de asistencia para los ponentes cuyo pago haya sido confirmado.

R.11.4 Descargar todos los certificados de asistencia

El sistema permitirá a los administradores descargar un archivo con todos los certificados de asistencia de los ponentes registrados.

R.11.5 Descargar certificados de asistencia para todos los ponentes con pago confirmado

El sistema permitirá a los administradores descargar un archivo con todos los certificados de asistencia de los ponentes cuyo pago haya sido confirmado.

R.11.6 Descargar etiquetas de ponentes

El sistema permitirá a los administradores descargar un archivo con etiquetas para todos los ponentes.

R.11.7 Descargar etiquetas de restaurante

El sistema permitirá a los administradores descargar un archivo con etiquetas de restaurante genéricas (no nominativas).

R.11.8 Descargar etiquetas asistencia a cenas de gala

El sistema permitirá a los administradores descargar un archivo con etiquetas genéricas (no nominativas) para la asistencia a cenas de gala

R.11.9 Descargar etiquetas de miembros de la organización

El sistema permitirá a los administradores descargar un archivo con etiquetas distintivas para la organización.

R.11.10 Descargar etiquetas de asistencia a excursiones

El sistema permitirá a los administradores descargar un archivo con etiquetas genéricas (no nominativas) para la asistencia a excursiones.

R.11.11 Descargar listado de autores

El sistema permitirá a los administradores descargar un listado de todos los autores, su país de procedencia, organización asociada y número de papers y posters enviados en formato Excel.



Código Requisito


R.11.12 Descargar listado Excel de papers

El sistema permitirá a los administradores descargar un listado de todos los papers, su estado, simposio y autores asociados para todos los papers en formato Excel.

R.11.13 Descargar listado HTML de papers

El sistema permitirá a los administradores descargar un listado de todos los papers, su estado, simposio y autores asociados para todos los papers en formato HTML.

R.11.14 Descargar certificados de presentación de ponencia individuales

El sistema permitirá a los administradores descargar certificados de presentación de ponencias individuales para los papers de los usuarios que hayan pagado.

R.11.15 Descargar todos los certificados de presentación de ponencia

El sistema permitirá a los administradores descargar un archivo con todos los certificados de presentación de ponencia.

R.11.16 Descargar certificados de presentación de ponencia de usuarios que han pagado

El sistema permitirá a los administradores descargar un archivo que contenga únicamente los certificados de presentación de ponencia de los usuarios que hayan pagado.

R.11.17 Descargar subconjunto de certificados de presentación de ponencia

El sistema permitirá a los administradores descargar un archivo que contenga únicamente los certificados de presentación de ponencia de un subconjunto de ponentes seleccionado previamente cuyo pago haya sido confirmado.

R.11.18 Orientación de las etiquetas

El sistema permitirá generar las etiquetas para los asistentes en formato vertical u horizontal.

R.11.19 Tamaño de las etiquetas El sistema permitirá configurar las etiquetas a generar para que su tamaño sea de 15x7,5 cm o 9,2x6,25 cm.

R.11.20 Descargar etiquetas en blanco

El sistema permitirá a los administradores descargar un archivo con etiquetas genéricas (no nominativas) en blanco.

4.7.12 Excursiones

Código Requisito


R.12.1 Definición de excursiones El sistema permitirá a los administradores introducir el destino o nombre de las excursiones o actividades adicionales que tendrán lugar durante la conferencia.

R.12.2 Eliminación de excursiones

El sistema permitirá a los administradores el borrado de las excursiones o actividades definidas previamente.

R.12.3 Modificación de excursiones

El sistema permitirá a los administradores editar el destino o nombre de las excursiones o actividades definidas previamente.



4.8 Especificación de casos de uso y escenarios

A partir de los requisitos de la aplicación, y en función de los distintos roles de usuario (Actores)

encontrados, se ha elaborado el siguiente catálogo de casos de uso de la aplicación. Debido a su

elevado número, el catálogo se ha dividido según el actor involucrado en cada uno. Además, puesto

que la mayor parte de las funcionalidades de la aplicación corresponden a tareas administrativas, los

casos de uso que involucran exclusivamente a los administradores han sido clasificados en

subapartados independientes en función del tipo de entidades que manipulan.

Tras la definición de cada caso se incluye el desarrollo del mismo en detalle en uno o más escenarios.

En éstos, el tipo del usuario que lo inicia debe entenderse como una precondición adicional. Así, en los

escenarios iniciados por un Invitado deben entenderse que existe la precondición inherente “El usuario

no ha iniciado sesión en el sistema”; en los iniciados por un Administrador, “El usuario ha iniciado

sesión con una cuenta de Administrador”; etc.

4.8.1 Acciones de invitado

Caso de Uso 1: Registro de nuevo ponente

A través de un formulario los asistentes proporcionarán sus datos personales y dirección de

correo electrónico para crear una nueva cuenta de ponente.

Escenario 1.1

Precondiciones - El acceso público al sitio está habilitado - El sistema no está en estado cerrado.

Poscondiciones - Los datos del nuevo usuario se habrán almacenado asociadas a una nueva cuenta de ponente.

- Se habrá enviado un correo electrónico de confirmación de registro a los administradores y a la dirección proporcionada por el usuario.

Excepciones Se mostrará un mensaje de error y no se creará la nueva cuenta de Ponente en los siguientes casos: - Si se introducen datos no válidos. - Si la dirección correo electrónico proporcionada ya está asociada a otro

usuario. - Si se produce un error al enviar el mensaje de confirmación de registro a la

dirección correo electrónico proporcionada.

Iniciado por Invitado

Finalizado por Invitado

Descripción Un asistente al congreso introduce sus datos para crear una nueva cuenta de ponente e introducir los datos necesarios para asistir al congreso.

Corresponde al Requisito:

R.1.5, R.2.2, R.2.3



Caso de Uso 2: Login de usuario

Solicita a los usuarios registrados en la aplicación y a los administradores proporcionar sus

credenciales de acceso (dirección de correo electrónico y contraseña) para hacer uso del

sistema.

Escenario 2.1

Precondiciones - El acceso público al sitio está habilitado. - El sistema no está en estado cerrado. - Las credenciales proporcionadas corresponden a una cuenta de ponente.

Poscondiciones Se asocia la cuenta cuyas credenciales han sido proporcionados a la sesión del usuario.

Excepciones - Se mostrará un mensaje de error y la sesión se mantendrá asociada con la cuenta de invitado si las credenciales proporcionadas no corresponden a ningún usuario registrado (dirección de correo electrónico desconocida o contraseña incorrecta).

- Si el acceso público está deshabilitado, se mostrará una página informando de que el acceso público está cerrado.



Descripción Un usuario, no identificado, solicita iniciar sesión en el sistema proporcionando las credenciales de una cuenta de ponente existente.


R.2.1

Escenario 2.2

Precondiciones - El sistema no está en estado cerrado. - Las credenciales proporcionadas corresponden a una cuenta de

administrador.

Poscondiciones Se asocia la cuenta cuyas credenciales han sido proporcionadas a la sesión del usuario.

Excepciones Se mostrará un mensaje de error y la sesión se mantendrá asociada con la cuenta de invitado si las credenciales proporcionadas no corresponden a ningún usuario registrado (direcciónde correo electrónico desconocida o contraseña incorrecta).



Descripción Un usuario, no identificado, solicita iniciar sesión en el sistema proporcionando las credenciales de una cuenta de administrador existente.


R.2.1



Escenario 2.3

Precondiciones - El acceso público al sitio está habilitado. - El sistema no está en estado cerrado. - Las credenciales proporcionadas corresponden a una cuenta de Editor.

Poscondiciones Se asocia la cuenta cuyas credenciales han sido proporcionados a la sesión del usuario.

Excepciones - Se mostrará un mensaje de error y la sesión se mantendrá asociada con la cuenta de invitado si las credenciales proporcionadas no corresponden a ningún usuario registrado (dirección de correo electrónico desconocida o contraseña incorrecta).

- Si el acceso público está deshabilitado, se mostrará una página informando de que el acceso público está cerrado.



Descripción Un usuario, no identificado, solicita iniciar sesión en el sistema proporcionando las credenciales de una cuenta de editor existente.


R.2.1

Caso de Uso 3: Restablecer contraseña perdida

Proporcionando la dirección de correo electrónico utilizada durante el registro, permite a los

ponentes asociar una nueva contraseña aleatoria a su cuenta en caso de haber olvidado la

proporcionada durante el registro.

Escenario 3.1

Precondiciones No existen precondiciones adicionales.

Poscondiciones - La contraseña de la cuenta asociada a la dirección de correo electrónico proporcionada es cambiada por una contraseña aleatoria.

- Se habrá enviado un correo electrónico a la dirección asociada a la cuenta de usuario con la nueva contraseña.

Excepciones No se hará nada si: - La dirección de correo electrónico proporcionada no corresponde con ningún

usuario registrado. - La cuenta asociada a la dirección de correo electrónico proporcionada no es

de ningún ponente (es decir, es de un administrador o editor).


Finalizado por Sistema

Descripción Un usuario que no recuerda la contraseña asociada a su cuenta solicita generar una nueva contraseña para poder acceder al sistema.


R.2.2, R.2.3



Invitado

Registro de nuevo ponente

Login de usuario

Restablecer contraseña perdida

Figura 4.1: Casos de Uso para las acciones de invitado

4.8.2 Acciones comunes

Caso de Uso 4: Descargar calendario de exposición de posters

Cualquier ponente o usuario no identificado podrá acceder a un enlace a un calendario digital

en formato iCal con los horarios de exposición de los posters.

Escenario 4.1


Poscondiciones No hay

Excepciones - Si no hay posters en el sistema se retorna un calendario vacío. - Para los posters cuya fecha de inicio y/o finalización de exposición no esté

definida se utilizará la fecha actual como fecha de inicio y fin de exposición.



Descripción Un usuario, no identificado, solicita acceder al calendario digital con los horarios de exposición de los posters enviados que serán expuestos en el congreso.


R.8.1, R.8.2, R.8.3, R.8.4, R.8.6

Escenario 4.2



Excepciones - Si no hay posters en el sistema se retorna un calendario vacío. - Para los posters cuya fecha de inicio y/o finalización de exposición no esté


Iniciado por Ponente

Finalizado por Ponente

Descripción Un usuario, identificado con una cuenta de ponente, solicita acceder al calendario digital con los horarios de exposición de los posters enviados que serán expuestos en el congreso.


R.8.1, R.8.2, R.8.3, R.8.6



Escenario 4.3



Excepciones - Si no hay posters en el sistema se retornará un calendario vacío. - Para los posters cuya fecha de inicio y/o finalización de exposición no esté


Iniciado por Editor

Finalizado por Editor

Descripción Un usuario, identificado con una cuenta de editor, solicita acceder al calendario digital con los horarios de exposición de los posters enviados que serán expuestos en el congreso.


R.8.1, R.8.2, R.8.3, R.8.6

Caso de Uso 5: Descargar calendario de simposios

Cualquier ponente o usuario no identificado podrá acceder a un enlace a un calendario digital

en formato iCal con los horarios de inicio de las diferentes sesiones (simposios) que se

celebrarán durante el evento.

Escenario 5.1



Excepciones - Si no hay simposios en el sistema se retornará un calendario vacío. - Para los simposios cuya fecha de inicio no esté definida se utilizará la fecha

actual.



Descripción Un usuario, no identificado, solicita acceder al calendario digital con los horarios de inicio de todos los simposios que se celebrarán durante el congreso.


R.8.1, R.8.2, R.8.3, R.8.4, R.8.5

Escenario 5.2




actual.



Descripción Un usuario, identificado con una cuenta de ponente, solicita acceder al calendario digital con los horarios de inicio de todos los simposios que se celebrarán durante el congreso.


R.8.1, R.8.2, R.8.3, R.8.5



Escenario 5.3




actual.

Iniciado por Editor


Descripción Un usuario, identificado con una cuenta de editor, solicita acceder al calendario digital con los horarios de inicio de todos los simposios que se celebrarán durante el congreso.


R.8.1, R.8.2, R.8.3, R.8.5

Caso de Uso 6: Finalizar sesión

Los usuarios previamente identificados podrán solicitar al sistema que finalice su sesión, de

forma que para realizar cualquier acción posterior asociada a su cuenta de ponente o gestión

administrativa requerirá volver a introducir sus credenciales de acceso.

Escenario 6.1


Poscondiciones La sesión del usuario es desvinculada de la cuenta a la que estaba asociada, pasando a ser considerada nuevamente como una sesión de Invitado.

Excepciones Este escenario no contempla situaciones excepcionales



Descripción Un usuario, identificado previamente con una cuenta de ponente, solicita terminar su sesión actual en la aplicación.


R.2.4

Escenario 6.2




Iniciado por Editor


Descripción Un usuario, identificado previamente con una cuenta de editor, solicita terminar su sesión actual en la aplicación.


R.2.4



Escenario 6.3




Iniciado por Administrador


Descripción Un usuario, identificado previamente con una cuenta de administrador, solicita terminar su sesión actual en la aplicación.


R.2.4

InvitadoPonente

AdministradorEditor

Descargar calendario de exposición de posters

Descargar calendario de simposios

Finalizar sesión

Figura 4.2: Casos de uso para las acciones comunes



4.8.3 Acciones de ponente

Caso de Uso 7: Ver datos de ponente

Los ponentes previamente identificados podrán ver los datos personales y dirección de correo

electrónico asociados a su cuenta.

Escenario 7.1






Descripción Un ponente solicita ver los datos personales asociados a su cuenta.


R.1.2

Caso de Uso 8: Modificar datos de ponente

Los ponentes previamente identificados podrán modificar los datos asociados a su cuenta,

como nombre, dirección e institución asociada. No se permite modificar la cuenta de correo

utilizada.

Escenario 8.1


Poscondiciones Los datos del ponente son actualizados en la base de datos.




Descripción Un ponente desea actualizar los datos personales asociados a su cuenta.


R.1.2, R.1.4



Caso de Uso 9: Modificar contraseña

Los ponentes previamente identificados podrán modificar la contraseña usada para

identificarse en el sistema. Por motivos de seguridad, el sistema solicitará también la

contraseña actual asociada a la cuenta.

Escenario 9.1


Poscondiciones La contraseña almacenada para el ponente que realiza la acción es actualizada.

Excepciones Si no se proporciona la contraseña anterior o ésta es incorrecta no se realizan cambios.



Descripción Un ponente desea cambiar la contraseña usada para acceder al sistema.


R.2.5, R.2.6, R.2.7

Ponente

Modificar datos de ponente

Ver datos de ponente

Modificar contraseña

Figura 4.3: Casos de uso para las acciones del perfil de ponente



Caso de Uso 10: Enviar nuevo paper

Los ponentes previamente identificados podrán enviar un archivo digital con el paper a

presentar durante la conferencia indicando, además, su título, autores y el simposio en el que

desean presentarlo.

Escenario 10.1


Poscondiciones - Se creará un nuevo paper en la base de datos asociado a los datos proporcionados.

- Se enviará una notificación por correo electrónico a los administradores informando del nuevo envío

Excepciones El sistema rechazará el envío (informando del motivo del rechazo) si: - Se ha enviado previamente un paper con el mismo título (por cualquier

usuario). - No se ha indicado el título del paper - No se ha indicado el nombre de ninguno de los autores - No se ha indicado el simposio en el cual el usuario desea presentar el paper.



Descripción Un ponente desea enviar un paper nuevo, no enviado previamente.


R.5.1, R.5.3, R.5.4, R.5.5, R.5.6

Caso de Uso 11: Enviar nueva versión de paper

Los ponentes previamente identificados podrán enviar un nuevo archivo digital con una nueva

versión de un paper enviado previamente que haya sido aceptado por los administradores.

Escenario 11.1

Precondiciones - El usuario ha enviado y seleccionado previamente un paper que ha sido aceptado por los administradores.

- El plazo de envío de papers está abierto.

Poscondiciones - El nuevo archivo queda asociado como último envío del paper. - Si hubiese otras versiones del paper enviadas después del envío original, se

borrarán del sistema. - Se enviará una notificación por correo electrónico a los administradores

informando del nuevo envío.

Excepciones El sistema rechazará el envío si el plazo para ello ha sido cerrado.



Descripción Un ponente desea enviar un nuevo archivo para un paper enviado previamente.


R.5.2, R.5.5



Caso de Uso 12: Eliminar paper enviado

Los ponentes previamente identificados podrán eliminar el archivo y los datos asociados a los

papers previamente enviados siempre que éstos no hayan entrado ya en proceso de revisión.

Escenario 12.1

Precondiciones El usuario ha enviado y seleccionado previamente un paper que aún no ha sido aceptado ni ha entrado en proceso de revisión.

Poscondiciones - Se enviará un correo electrónico a los administradores informando de que el paper ha sido eliminado.

- Se enviará un correo electrónico al usuario informando de que el paper ha sido eliminado.

- La información del paper se eliminará de la base de datos.

Excepciones Si no se encuentra el paper indicado el sistema no hace nada.



Descripción Un ponente desea borrar un paper que ha enviado previamente y que aún no ha entrado en proceso de revisión.


R.5.7, R.5.8, R.5.9

Ponente

Enviar nueva versión de paper

Enviar nuevo paper

Eliminar paper enviado

Figura 4.4: Casos de uso para las acciones de papers de ponente



Caso de Uso 13: Enviar justificante de pago

Los ponentes previamente identificados podrán enviar un archivo digital que contenga el

justificante de haber realizado el pago de la cuota de inscripción al congreso.

Escenario 13.1

Precondiciones El pago del usuario no ha sido confirmado por los administradores.

Poscondiciones - Se asociará el archivo enviado a la cuenta del ponente, eliminando cualquier otro justificante enviado previamente.

- Se enviará un correo electrónico a los administradores informando del envío del nuevo justificante.

Excepciones Si hay algún error al leer o guardar el fichero enviado se informará al usuario y no se realizarán cambios en la base de datos.



Descripción Un usuario, cuyo pago no ha sido confirmado, envía un archivo digital que justifica el pago de éste de la cuota de inscripción al congreso.


R.3.1

Caso de Uso 14: Descargar justificante de pago enviado

Los ponentes previamente identificados podrán descargar una copia del justificante de pago,

en caso de que hayan enviado uno previamente.

Escenario 14.1

Precondiciones - El usuario ha enviado previamente un justificante de pago. - El pago del usuario no ha sido confirmado por los administradores.





Descripción Un ponente solicita descargar una copia del archivo de justificante de pago que ha enviado previamente.


R.3.1



Caso de Uso 15: Solicitar factura

Los ponentes previamente identificados que así lo deseen podrán solicitar la emisión de una

factura, proporcionando el nombre que aparecerá en la misma y los datos fiscales (nombre,

dirección y CIF o equivalente) de la institución que se hará cargo del pago.

Escenario 15.1

Precondiciones - El usuario ha enviado previamente un justificante de pago. - El pago del usuario no ha sido confirmado por los administradores.

Poscondiciones Los datos de facturación proporcionados quedan asociados al usuario actual.




Descripción Un ponente introduce los datos de facturación necesarios para que la organización emita una factura que cubra los costes asociados a su inscripción.


R.3.2

Caso de Uso 16: Eliminar datos de factura

Los ponentes previamente identificados que hayan solicitado previamente la emisión de una

factura a nombre de una institución podrán eliminar los datos adicionales asociados a ésta,

tras lo cual el sistema volverá a asociarles un justificante estándar.

Escenario 16.1


Poscondiciones Los datos de facturación proporcionados previamente al usuario (si los hubiese) son eliminados de la base de datos.

Excepciones Si previamente no hubiese datos registrados en el sistema para emitir una factura que cubra los costes asociados a la inscripción del ponente, el sistema no hace nada.



Descripción Un usuario, que previamente ha solicitado la emisión de una factura para sus costes de inscripción, solicita que los datos adicionales de ésta sean eliminados, de forma que se generará un justificante de pago en su lugar.


R.3.2



Ponente

Descargar justificante de pago enviado

Enviar justificante de pago

Solicitar factura

Eliminar datos de factura

Figura 4.5: Casos de uso para las acciones de pago de ponente

4.8.4 Acciones de editor

Caso de Uso 17: Listar papers

Los editores tendrán acceso a un listado con el título y la conferencia asociada a todos los

papers enviados y aceptados.

Escenario 17.1




Iniciado por Editor


Descripción Un editor solicita acceder al listado de los papers aceptados.


R.5.16



Caso de Uso 18: Descargar paper

Los editores podrán descargar cualquier paper enviado que haya sido marcado como aceptado

por los administradores.

Escenario 18.1




Iniciado por Editor


Descripción Un editor solicita la descarga de un paper aceptado desde el listado de papers.


R.5.17

Editor

Descargar paper

Listar papers

Figura 4.6: Casos de uso para las acciones de editor

4.8.5 Gestión de usuarios

Caso de Uso 19: Listar usuarios

Los administradores tendrán acceso a un listado completo de los ponentes registrados en el

que se incluirán los datos asociados a su cuenta, como nombre, dirección, teléfono, institución

asociada y dirección de correo electrónico.

Escenario 19.1





Finalizado por Administrador

Descripción Un administrador solicita acceder al listado con los datos de todos los ponentes registrados.


R.1.6



Caso de Uso 20: Borrar usuario

Los administradores podrán eliminar del sistema la cuenta de cualquier ponente, incluyendo

sus datos de facturación y papers enviados.

Escenario 20.1


Poscondiciones El usuario y todos los ficheros y datos sobre su justificante de pago (si lo hubiera) y los papers enviados desde su cuenta son eliminados del sistema.




Descripción Un administrador solicita el borrado de una cuenta de ponente, incluyendo todos los datos asociados a ella.


R.1.7

Caso de Uso 21: Descargar listado de usuarios

Los administradores podrán descargar un archivo digital que contenga el listado completo de

los usuarios y sus datos más relevantes, incluyendo el nombre de archivo del justificante de

pago enviado, datos fiscales, dirección y dirección de correo asociada.

Escenario 21.1






Descripción Un administrador solicita el listado de todos los usuarios registrados en formato Excel.


R.11.1

Escenario 21.2






Descripción Un administrador solicita el listado de todos los usuarios registrados en formato HTML.


R.11.2



Administrador

Listar usuarios

Borrar usuario

Descargar listado de usuarios

Figura 4.7: Casos de uso para las acciones de gestión de usuarios

Caso de Uso 22: Descargar certificado de asistencia individual

Los administradores podrán descargar un archivo digital que certifique la asistencia al congreso

de un usuario individual, una vez que el pago de éste haya sido confirmado.

Escenario 22.1

Precondiciones El usuario cuyo certificado se solicita ha pagado la cuota de inscripción al congreso.





Descripción Un administrador solicita un archivo con el certificado de asistencia al congreso de un usuario cuyo pago ha sido confirmado.


R.11.3

Caso de Uso 23: Descargar subconjunto de certificados de asistencia

Los administradores podrán descargar un archivo digital que contenga certificados de

asistencia al congreso para un subconjunto de usuarios seleccionados previamente y cuyo

pago haya sido confirmado.

Escenario 23.1



Excepciones Si no se han seleccionado usuarios el PDF generado únicamente contendrá el texto “No se han seleccionado usuarios”.



Descripción Un administrador solicita un archivo con el certificado de asistencia al congreso para un subconjunto de usuarios seleccionados previamente y cuyo pago haya sido confirmado.


R.11.3



Caso de Uso 24: Descargar certificados de asistencia de todos los usuarios

que han pagado


asistencia al congreso de todos los usuarios cuyo pago haya sido confirmado.

Escenario 24.1



Excepciones Si no hay usuarios que hayan pagado se genera un archivo con una página en blanco.



Descripción Un administrador solicita un archivo que contenga el certificado de asistencia al congreso de todos los usuarios cuyo pago ha sido confirmado.


R.11.5

Caso de Uso 25: Descargar certificados de asistencia de todos los usuarios


asistencia al congreso de todos los ponentes registrados.

Escenario 25.1



Excepciones Si no hay ponentes registrados en el sistema se genera un archivo con una página en blanco.



Descripción Un administrador solicita un archivo que contenga el certificado de asistencia al congreso de todos los usuarios registrados.


R.11.4



Administrador

Descargar subconjunto de certificados de asistencia

Descargar certificado de asistencia individual

Descargar certificados de asistencia de todos los usuarios que han pagado

Descargar certificados de asistencia de todos los usuarios

Figura 4.8: Casos de uso para la descarga de certificados

Caso de Uso 26: Descargar etiquetas de los usuarios

Los administradores podrán descargar un archivo digital que contenga etiquetas nominativas

utilizadas para identificar a todos los asistentes al congreso.

Escenario 26.1

Precondiciones El sistema está configurado para generar etiquetas en formato vertical.





Descripción Un administrador solicita un archivo con las etiquetas nominativas para todos los ponentes, en formato vertical.


R.11.6



Escenario 26.2

Precondiciones El sistema está configurado para generar etiquetas en formato horizontal con un tamaño de 15x7,5 cm.





Descripción Un administrador solicita un archivo con las etiquetas nominativas para todos los ponentes, en formato horizontal con un tamaño de 15x7,5cm.


R.11.6

Escenario 26.3

Precondiciones El sistema está configurado para generar etiquetas en formato horizontal con un tamaño de 9,2x6,28 cm.





Descripción Un administrador solicita un archivo con las etiquetas nominativas para todos los ponentes, en formato horizontal con un tamaño de 9,2x6,28cm.


R.11.6

Caso de Uso 27: Descargar etiquetas para cena de gala

Los administradores podrán descargar un archivo digital que contenga etiquetas no

nominativas utilizadas para la asistencia a la cena de gala.

Escenario 27.1

Precondiciones El sistema está configurado para generar etiquetas con un tamaño de 15x7,5 cm.





Descripción Un administrador solicita un archivo con las etiquetas no nominativas para la asistencia a la cena de gala con un tamaño de 15x7,5cm.


R.11.8



Escenario 27.2

Precondiciones El sistema está configurado para generar etiquetas con un tamaño de 9,2x6,28 cm.





Descripción Un administrador solicita un archivo con las etiquetas no nominativas para la asistencia a la cena de gala con un tamaño de 9,2x6,28cm.


R.11.8

Caso de Uso 28: Descargar etiquetas en blanco

Los administradores podrán descargar un archivo digital que contenga un conjunto de

etiquetas con un diseño similar al resto de tipos con el espacio correspondiente al tipo de

etiqueta o nombre de ponente en blanco, de modo que puedan utilizarse para cualquier

propósito no contemplado por la aplicación.

Escenario 28.1

Precondiciones El sistema está configurado para generar etiquetas en formato vertical.





Descripción Un administrador solicita un archivo con etiquetas en blanco, en formato vertical.


R.11.20

Escenario 28.2

Precondiciones El sistema está configurado para generar etiquetas en formato horizontal con un tamaño de 15x7,5 cm.





Descripción Un administrador solicita un archivo con etiquetas en blanco, en formato horizontal con un tamaño de 15x7,5cm.


R.11.20



Escenario 28.3

Precondiciones El sistema está configurado para generar etiquetas en formato horizontal con un tamaño de 9,2x6,28 cm.





Descripción Un administrador solicita un archivo con etiquetas en blanco, en formato horizontal con un tamaño de 9,2x6,28cm.


R.11.20

Caso de Uso 29: Descargar etiquetas de restaurante

Los administradores podrán descargar un archivo digital que contenga etiquetas de

restaurante no nominativas.

Escenario 29.1






Descripción Un administrador solicita descargar un archivo que contenga las etiquetas no nominativas de restaurante con un tamaño de 15x7,5cm.


R.11.7

Escenario 29.2






Descripción Un administrador solicita descargar un archivo que las etiquetas no nominativas de restaurante con un tamaño de 9,2x6,28 cm.


R.11.7



Caso de Uso 30: Descargar etiquetas de la organización


nominativas utilizadas para distinguir a los miembros de la organización del congreso.

Escenario 30.1






Descripción Un administrador solicita descargar un archivo que contenga las etiquetas no nominativas para identificar a los miembros de la organización del congreso con un tamaño de 15x7,5cm.


R.11.9

Escenario 30.2






Descripción Un administrador solicita descargar un archivo que contenga las etiquetas no nominativos para identificar a los miembros de la organización del congreso con un tamaño de 9,2x6,28 cm.


R.11.9

Caso de Uso 31: Descargar etiquetas de excursión


nominativas utilizadas para la asistencia a las excursiones programadas.

Escenario 31.1



Excepciones Si no hay datos de excursiones programadas en el sistema se genera un archivo con una página en blanco.



Descripción Un administrador solicita descargar un archivo que contenga las etiquetas no nominativas para la asistencia a las excursiones programadas con un tamaño de 15x7,5 cm, con una página por excursión programada.


R.11.10



Escenario 31.2



Excepciones Si no hay datos de excursiones programadas en el sistema se genera un archivo con una página en blanco.



Descripción Un administrador solicita descargar un archivo que contenga las etiquetas no nominativas para la asistencia a las excursiones programadas con un tamaño de 9,2x6,28 cm, con una página por excursión programada.


R.11.10

Administrador

Descargar etiquetas para cena de gala

Descargar etiquetas de los usuarios

Descargar etiquetas en blanco

Descargar etiquetas de la organización

Descragar tickets de restaurante

Descargar etiquetas de excursión

Figura 4.9: Casos de uso para la descarga de etiquetas



4.8.6 Gestión de pagos (general)

Caso de Uso 32: Modificar cuota individual

Los administradores podrán, para cualquier usuario individual (haya solicitado o no la emisión

de factura), modificar la cuota de inscripción que éste debe pagar.

Escenario 32.1

Precondiciones - El usuario cuya cuota se modifica ha proporcionado los datos necesarios para emitir una factura.

- La factura del usuario no ha sido marcada como lista para imprimir.

Poscondiciones La cuota a pagar por el ponente es modificada utilizando la cantidad proporcionada.

Excepciones Si no se proporciona una cantidad a pagar (o no se proporciona una cantidad válida), al usuario se le asigna la cuota por defecto.



Descripción Un administrador solicita cambiar la cuota de inscripción a pagar por un usuario que ha solicitado factura.


R.3.6

Escenario 32.2

Precondiciones - El usuario cuya cuota se modifica no ha proporcionado los datos necesarios para emitir una factura.

- La factura del usuario no ha sido marcada como lista para imprimir.

Poscondiciones La cuota a pagar por el ponente es modificada utilizando la cantidad proporcionada.

Excepciones Si no se proporciona una cantidad a pagar (o no se proporciona una cantidad válida), al usuario se le asigna la cuota por defecto.



Descripción Un administrador solicita cambiar la cuota de inscripción a pagar por un usuario que no ha solicitado factura.


R.3.6



Caso de Uso 33: Confirmar pago

Los administradores podrán, para cualquier usuario individual (haya solicitado o no la emisión

de factura), marcar el pago de su cuota de inscripción como confirmado.

Escenario 33.1

Precondiciones - El usuario cuyos datos se modifican ha solicitado factura. - El pago del usuario no ha sido confirmado.

Poscondiciones La información de facturación del usuario es actualizada para indicar que el usuario ha pagado.




Descripción Un administrador confirma el pago de la cuota de inscripción por parte de un usuario que ha solicitado factura.


R.3.5

Escenario 33.2

Precondiciones - El usuario cuyos datos se modifican ha solicitado factura. - El pago del usuario ha sido confirmado. - La factura del usuario no ha sido marcada como lista para imprimir.

Poscondiciones La información de facturación del usuario es actualizada para indicar que el usuario no ha pagado.




Descripción Un administrador elimina la confirmación de pago de la cuota de inscripción de un usuario que ha solicitado factura cuyo pago había sido confirmado previamente.


R.3.5

Escenario 33.3

Precondiciones - El usuario ha iniciado sesión con una cuenta de Administrador. - El usuario cuyos datos se modifican no solicitado factura. - El pago del usuario no ha sido confirmado.

Poscondiciones La información de facturación del usuario es actualizada para indicar que el usuario ha pagado.




Descripción Un administrador confirma el pago de la cuota de inscripción de un usuario que no ha solicitado factura.


R.3.5



Escenario 33.4

Precondiciones - El usuario cuya cuyos datos se modifican no ha solicitado factura. - El pago del usuario ha sido confirmado.

Poscondiciones La información de facturación del usuario es actualizada para indicar que el usuario no ha pagado.




Descripción Un administrador elimina la confirmación de pago de la cuota de inscripción de un usuario que no ha solicitado factura cuyo pago había sido confirmado previamente.


R.3.5

Caso de Uso 34: Ver justificante de pago

Los administradores podrán descargar el justificante de pago de los usuarios que lo hayan

enviado (hayan solicitado o no la emisión de factura).

Escenario 34.1

Precondiciones - El usuario cuyos datos se consultan ha solicitado factura. - El usuario cuyos datos se consultan ha enviado un justificante de pago





Descripción Un administrador solicita descargar el justificante de pago enviado previamente por un usuario que ha solicitado factura.


R.3.15

Escenario 34.2

Precondiciones - El usuario cuyos datos se consultan no ha solicitado factura. - El usuario cuyos datos se consultan ha enviado un justificante de pago





Descripción Un administrador solicita descargar el justificante de pago enviado previamente por un usuario que no ha solicitado factura.


R.3.15



Administrador

Modificar cuota individual

Confirmar pago

Ver justificante de pago

Figura 4.10: Casos de uso para la gestión general de pagos

4.8.7 Gestión de facturas

Caso de Uso 35: Listar facturas

Los administradores tendrán acceso a un listado de todos los usuarios que hayan

proporcionado los datos necesarios para la emisión de una factura.

Escenario 35.1






Descripción Un administrador solicita la lista de usuarios con datos de facturación asignados para la emisión de facturas.


R.3.3, R.3.5



Caso de Uso 36: Asignar número de factura individual

Los administradores podrán, para cualquier usuario que haya solicitado la emisión de factura

y haya enviado un justificante de pago, modificar manualmente el número de la factura

emitida de forma individual.

Escenario 36.1

Precondiciones - El usuario cuyos datos se modifican ha solicitado factura - El pago del usuario ha sido confirmado y su factura no ha sido marcada como

lista para imprimir

Poscondiciones La información de facturación es actualizada para asignar al usuario el número de factura proporcionado.

Excepciones Si el número de factura proporcionado ya está en uso, se mantiene el valor anterior.



Descripción Un administrador solicita cambiar el número de factura asignado a un usuario individual.


R.3.3, R.3.10, R.3.11

Caso de Uso 37: Marcar factura lista para imprimir


y cuyo pago haya sido confirmado, marcar su factura como lista para imprimir (impidiendo

cualquier modificación posterior).

Escenario 37.1


Poscondiciones La información de facturación del usuario es actualizada para reflejar que sus datos han sido confirmados, impidiendo futuras modificaciones.




Descripción Un administrador solicita marcar una factura, cuyo pago está confirmado y con número asignado, como lista para imprimir, impidiendo modificaciones posteriores.


R.3.7, R.3.9



Administrador

Asignar número de factura individual

Listar facturas

Marcar factura lista para imprimir

Figura 4.11: Casos de uso para la gestión de facturas individuales

Caso de Uso 38: Descargar factura individual de ponente


y cuyo pago haya sido confirmado, descargar un archivo con una factura a su nombre para su

posterior impresión.

Escenario 38.1

Precondiciones - El usuario cuya factura se solicita ha proporcionado datos de facturación. - El pago del usuario ha sido confirmado.





Descripción Un administrador solicita descargar un archivo que contenga la factura emitida por la organización a nombre de un usuario que la haya solicitado y cuyo pago esté confirmado.


R.3.3



Caso de Uso 39: Descargar facturas listas para imprimir

Los administradores podrán descargar un archivo digital que contenga las facturas emitidas

que hayan sido marcadas como listas para imprimir.

Escenario 39.1



Excepciones Si no hay facturas marcadas como listas para imprimir se genera un archivo con una página en blanco.



Descripción Un administrador solicita descargar un archivo que contenga todas las facturas emitidas por la organización que hayan sido previamente marcadas como listas para imprimir.


R.3.3

Caso de Uso 40: Descargar subconjunto de facturas de ponentes

Los administradores podrán descargar un archivo digital que contenga las facturas emitidas

para un subconjunto de ponentes cuyo pago ha sido confirmado y las hayan solicitado. Las

facturas de éstos podrán haber sido previamente marcadas o no como listas para imprimir.

Escenario 40.1



Excepciones Si no se selecciona ninguna factura se genera un archivo con una página en blanco.



Descripción Un administrador solicita descargar un archivo que contenga un subconjunto de las facturas emitidas por la organización y marcadas previamente como listas para imprimir.


R.3.3



Administrador

Descargar facturas listas para imprimir

Descargar factura individual de ponente

Descargar subconjunto de facturas de ponentes

Figura 4.12: Casos de uso para la descarga de facturas

Caso de Uso 41: Asignación automática de números de factura para los

ponentes de España

Los administradores podrán solicitar al sistema que asigne automáticamente números de

factura para los ponentes de España que la hayan solicitado y no lo tengan asignado aún.

Escenario 41.1


Poscondiciones Todas las facturas para usuarios de España con pago confirmado que no tuviese número asignado pasan a tener números de factura correlativos.




Descripción Un administrador solicita la asignación automática de números de factura para aquellos usuarios de España que no lo tuvieran asignado aún.


R.3.10



Caso de Uso 42: Asignación automática de números de factura para los

ponentes de fuera de España

Los administradores podrán solicitar al sistema que asigne automáticamente números de

factura para los ponentes de fuera de España que la hayan solicitado y no lo tengan asignado

aún.

Escenario 42.1


Poscondiciones Todas las facturas para usuarios de España con pago confirmado que no tuviese número asignado pasan a tener números de factura correlativos




Descripción Un administrador solicita la asignación automática de números de factura para aquellos usuarios de fuera de España que no lo tuvieran asignado aún.


R.3.11

Administrador

Asignación automática de númerosde factura para los ponentes

de España

Asignación automática de númerosde factura para los ponentes

de fuera de España

Figura 4.13: Casos de uso para la asignación automática de los números de factura



4.8.8 Gestión de justificantes de pago

Caso de Uso 43: Listar justificantes

Los administradores tendrán acceso a un listado de todos los usuarios que no hayan

proporcionado los datos necesarios para la emisión de una factura.

Escenario 43.1






Descripción Un administrador solicita la lista de usuarios sin datos de facturación asignados para la emisión de facturas.


R.3.15

Caso de Uso 44: Descargar justificantes para todos los ponentes

Los administradores podrán descargar un archivo digital que contenga los justificantes de pago

emitidos por la organización para todos los usuarios que no hayan solicitado factura.

Escenario 44.1



Excepciones Si no hay ponentes que no hayan solicitado factura se genera un archivo con una página en blanco.



Descripción Un administrador solicita descargar un archivo que contenga todos los justificantes de pago emitido por la organización para aquellos usuarios que no hayan solicitado factura.


R.3.4, R.3.15



Caso de Uso 45: Descargar justificantes para los ponentes que han

pagado


emitidos por la organización para todos los usuarios que no hayan solicitado factura y cuyo

pago haya sido confirmado.

Escenario 45.1



Excepciones Si no hay ponentes que hayan pagado y que no hayan solicitado factura se genera un archivo con una página en blanco.



Descripción Un administrador solicita descargar un archivo que contenga todos los justificantes de pago emitido por la organización para aquellos usuarios que no hayan solicitado factura y cuyo pago haya sido confirmado.


R.3.4, R.3.15

Caso de Uso 46: Descargar subconjunto de justificantes


emitidos por la organización para un subconjunto de usuarios cuyo pago haya sido confirmado

y no hayan solicitado factura.

Escenario 46.1



Excepciones Si no se selecciona ningún justificante se genera un archivo con una página en blanco.



Descripción Un administrador solicita descargar un archivo que contenga los justificantes para un subconjunto de usuarios que no hayan solicitado factura y cuyo pago haya sido previamente confirmado.


R.3.4, R.3.15



Administrador

Descargar justificantes para todos los ponentes

Listar justificantes

Descargar justificantes paralos ponentes que han pagado

Descargar subconjunto dejustificantes

Figura 4.14: Casos de uso para la gestión de justificantes

4.8.9 Gestión de simposios

Caso de Uso 47: Listar simposios

Los administradores tendrán acceso a un listado con el título, fecha y hora de inicio, y otros

detalles para todos los simposios programados.

Escenario 47.1






Descripción Un administrador solicita acceder al listado de los simposios definidos en el sistema.


R.4.2, R.4.3



Caso de Uso 48: Añadir simposio

Los administradores podrán añadir nuevos simposios proporcionando su título.

Escenario 48.1


Poscondiciones El sistema creará un nuevo simposio con el nombre proporcionado, y éste pasará a estar disponible durante el envío de nuevos papers.

Excepciones Si no se proporciona el nombre del simposio, o el proporcionado es vacío, no se hace nada.



Descripción Un administrador solicita crear un nuevo simposio que tendrá lugar durante la conferencia, indicando su nombre.


R.4.1

Caso de Uso 49: Borrar simposio vacío

Los administradores podrán borrar los simposios existentes de manera individual siempre que

no haya ponencias programada en ellos.

Escenario 49.1

Precondiciones El simposio a borrar no tiene papers asignados.

Poscondiciones El simposio borrado dejará de estar disponible durante el envío de nuevos papers y en los calendarios iCal.




Descripción Un administrador solicita borrar un simposio vacío, esto es, sin papers ni posters asignados.


R.4.3, R.4.4

Caso de Uso 50: Editar nombre de simposio

Los administradores podrán modificar el nombre de los simposios existentes de manera

individual.

Escenario 50.1


Poscondiciones El simposio modificado pasará a tener el nuevo nombre proporcionado.

Excepciones Si se indica un nombre de simposio vacío el sistema no hace nada.



Descripción Un administrador solicita cambiar el título de un simposio definido previamente.


R.4.2



Caso de Uso 51: Editar fecha de inicio de simposio

Los administradores podrán modificar la fecha y hora de inicio planificada para los simposios

definidos de manera individual.

Escenario 51.1


Poscondiciones El simposio modificado pasará a tener como fecha de inicio la fecha proporcionada.

Excepciones Si la nueva fecha de inicio es vacía o no es válida el sistema no hace nada.



Descripción Un administrador solicita cambiar la fecha y hora de inicio de un simposio definido previamente.


R.4.2

Administrador

Añadir simposio

Listar simposios

Borrar simposio vacío

Editar nombre de simposio

Editar fecha de inicio de simposio

Figura 4.15: Casos de uso para la gestión de simposios



4.8.10 Gestión de salas

Caso de Uso 52: Listar salas

Los administradores tendrán acceso a un listado con el nombre y número de posters asignados

a todas las salas disponibles para la celebración de la conferencia.

Escenario 52.1






Descripción Un administrador solicita acceder al listado de las salas definidas en el sistema.


R.6.2, R.6.3

Caso de Uso 53: Añadir sala

Los administradores podrán añadir nuevas salas proporcionando un nombre para ellas.

Escenario 53.1


Poscondiciones El sistema registrará una nueva sala con el nombre proporcionado, y ésta pasará a estar disponible para la asignación de posters.

Excepciones Si no se proporciona el nombre de la sala, o el proporcionado es vacío, no se hace nada.



Descripción Un administrador solicita añadir los datos de una nueva sala disponible durante la conferencia, indicando su nombre.


R.6.1



Caso de Uso 54: Borrar sala vacía

Los administradores podrán borrar las salas existentes de manera individual siempre que no

esté planificada la exposición de posters en ellas.

Escenario 54.1

Precondiciones La sala a borrar no tiene posters asignados.

Poscondiciones La sala borrada dejará de estar disponible en la interfaz de administración para la asignación de posters.




Descripción Un administrador solicita borrar una sala vacía, esto es, sin posters asignados.


R.6.3, R.6.4

Caso de Uso 55: Editar nombre de sala

Los administradores podrán modificar el nombre de las salas existentes de manera individual.

Escenario 55.1


Poscondiciones La sala modificada pasará a tener el nuevo nombre proporcionado.

Excepciones Si se indica un nombre de sala vacío el sistema no hace nada.



Descripción Un administrador solicita cambiar el nombre de una sala definida previamente.


R.6.1, R.6.2

Administrador

Añadir sala

Listar salas

Borrar sala vacía

Editar nombre de sala

Figura 4.16: Casos de uso para la gestión de salas



4.8.11 Gestión de excursiones

Caso de Uso 56: Listar excursiones

Los administradores tendrán acceso a un listado con el nombre de todas las excursiones

planificadas.

Escenario 56.1






Descripción Un administrador solicita acceder al listado de las excursiones definidas en el sistema.


R.12.3

Caso de Uso 57: Añadir excursión

Los administradores podrán añadir nuevas excursiones proporcionando un nombre descriptivo

para ellas.

Escenario 57.1


Poscondiciones El sistema creará una nueva excursión con el nombre proporcionado, y ésta pasará a mostrarse en las etiquetas de excursiones.

Excepciones Si no se proporciona el nombre de la excursión, o el proporcionado es vacío, no se hace nada.



Descripción Un administrador solicita añadir los datos de una nueva excursión que tendrá lugar durante la conferencia, indicando su nombre.


R.12.1



Caso de Uso 58: Borrar excursión

Los administradores podrán borrar las excursiones existentes de manera individual.

Escenario 58.1


Poscondiciones La excursión borrada dejará de estar disponible en la interfaz de administración, y no se mostrará en las etiquetas de las excursiones.




Descripción Un administrador solicita borrar una sala vacía, esto es, sin posters asignados.


R.12.2

Administrador

Añadir excursión

Listar excursiones

Borrar excursión

Figura 4.17: Casos de uso para la gestión de excursiones

4.8.12 Gestión de papers

Caso de Uso 59: Listar papers

Los administradores tendrán acceso a un listado con el título, conferencia asignada, ponente

asociado y fecha de creación para todos los papers enviados por los ponentes.

Escenario 59.1






Descripción Los administradores podrán acceder al listado de todos los papers enviados por los ponentes.


R.5.15



Caso de Uso 60: Descargar paper

Los administradores podrán descargar la primera y última versión de todos los papers enviados

por los ponentes.

Escenario 60.1






Descripción Un administrador solicita descargar un paper enviado previamente por un ponente.


R.5.5

Caso de Uso 61: Editar nombre de paper

Los administradores podrán editar el título asociado a cualquier paper enviado.

Escenario 61.1


Poscondiciones El paper modificado pasará a tener el nuevo nombre proporcionado.

Excepciones Si se indica un nombre de paper vacío el sistema no hace nada.



Descripción Un administrador solicita cambiar el título de un paper enviado por un ponente.


R.5.14

Caso de Uso 62: Marcar inicio de revisión de paper

Los administradores podrán establecer un flag en cualquier paper para indicar que se ha

iniciado su proceso de revisión.

Escenario 62.1


Poscondiciones - El ponente que envió el paper que entra en revisión no podrá modificarlo, ni podrá enviar nuevas versiones hasta que sea aceptado.

- El paper que entra en revisión no podrá ser borrado por el usuario que lo envió.




Descripción Un administrador solicita iniciar el proceso de revisión de un paper, impidiendo su modificación por parte del ponente.


R.5.9



Caso de Uso 63: Aceptar paper

Los administradores podrán establecer que un paper ha sido aceptado siempre que

previamente se haya marcado su proceso de revisión como iniciado.

Escenario 63.1

Precondiciones - El paper a aceptar debe haber entrado previamente en proceso de revisión. - Se enviará un correo electrónico informando de la aceptación del paper al

usuario que lo envió y a los administradores.

Poscondiciones El ponente que envió el paper aceptado no podrá borrarlo, pero sí podrá enviar nuevas versiones del mismo.




Descripción Un administrador solicita marcar un paper como aceptado para su presentación en la conferencia, impidiendo su borrado por parte del ponente.


R.5.2

Caso de Uso 64: Asociar sala a poster

Los administradores podrán indicar la sala en la que se expondrán los papers de tipo poster de

manera individual.

Escenario 64.1

Precondiciones - El paper al que se le asocia una sala debe ser de tipo poster. - Como sala no se asigna la predeterminada (con nombre vacío)

Poscondiciones Los datos sobre la sala y fecha/hora de exposición del poster pasarán a reflejar la información proporcionada.

Excepciones Si se indica una fecha y hora de inicio de exposición posterior a la de fin, la fecha de fin pasará a ser la de inicio y viceversa.



Descripción El administrador podrá asociar una sala y una fecha a los papers de tipo poster


R.5.10, R.5.11

Escenario 64.2

Precondiciones - El paper al que se le asocia una sala debe ser de tipo poster. - Como sala se asigna la predeterminada (con nombre vacío).

Poscondiciones Los datos sobre la fecha/hora de exposición del poster pasarán a reflejar la información proporcionada, y la sala pasará a estar sin definir.

Excepciones Si se indica una fecha y hora de inicio de exposición posterior a la de fin, la fecha de fin pasará a ser la de inicio y viceversa.



Descripción El administrador podrá asociar una sala y una fecha a los papers de tipo poster


R.5.10, R.5.11, R.5.12



Administrador

Descargar paper

Listar papers

Editar nombre de paper

Marcar inicio de revisión de paper

Aceptar paper

Asociar sala a poster

Figura 4.18: Casos de uso para la gestión de papers

Caso de Uso 65: Descargar certificado de presentación de ponencias para

todos los papers

Los administradores podrán descargar un archivo digital que contenga los certificados de

presentación de las ponencias asociadas a todos los papers enviados.

Escenario 65.1



Excepciones Si no hay papers aceptados se genera un archivo con una página en blanco.



Descripción Un administrador solicita descargar un archivo que contenga todos los certificados de presentación de ponencias emitido por la organización para todos los papers aceptados.


R.11.15



Caso de Uso 66: Descargar certificado de presentación de ponencias para

los usuarios que han pagado


presentación de las ponencias asociadas a los papers enviados por usuarios cuyo pago haya

sido confirmado.

Escenario 66.1



Excepciones Si no hay papers aceptados de usuarios cuyo pago haya sido confirmado se genera un archivo con una página en blanco.



Descripción Un administrador solicita descargar todos los certificados de presentación de ponencias emitidos por la organización para todos aquellos papers que hayan sido aceptados y correspondan a usuarios cuyo pago ha sido confirmado.


R.11.16

Caso de Uso 67: Descargar subconjunto de certificados de presentación

de ponencias


presentación de las ponencias asociadas a un subconjunto de papers seleccionados

previamente, siempre que el pago de los autores asociado a los mismos haya sido confirmado.

Escenario 67.1



Excepciones Si no hay papers aceptados de usuarios cuyo pago haya sido confirmado se genera un archivo con una página en blanco.



Descripción Un administrador solicita descargar todos los certificados de presentación de ponencias emitidos por la organización para un subconjunto de papers aceptados enviados por usuarios cuyo pago ha sido confirmado.


R.11.17



Caso de Uso 68: Descargar certificado de presentación de ponencia

individual

Los administradores podrán descargar un archivo digital que contenga el certificado de

presentación de una ponencia asociadas a un paper individual siempre que el autor asociado

al mismo tengan confirmado el pago de su cuota de inscripción al congreso.

Escenario 68.1






Descripción Un administrador solicita descargar un archivo que contenga el certificado de presentación de ponencia emitido por la organización para un papers aceptado enviado por un usuario cuyo pago ha sido confirmado.


R.11.14

Caso de Uso 69: Descargar listado de papers

Los administradores podrán descargar un archivo digital que contenga el listado completo de

todos los papers enviados y sus datos más relevantes, incluyendo su nombre de archivo, título,

autores y estado de aceptación.

Escenario 69.1






Descripción Los administradores podrán descargar un listado de los papers en formato Excel con información sobre éstos y sobre los usuarios que los envían.


R.11.12

Escenario 69.2






Descripción Los administradores podrán descargar un listado con los papers en formato HTML con información sobre éstos y sobre los usuarios que los envían


R.11.13



Administrador

Descargar certificado de presentación de ponenciaspara los usuarios que han pagado

Descargar certificado de presentación de ponencias para todos los papers

Descargar subconjunto de certificados de presentación de ponencias

Descargar certificado de presentaciónde ponencia individual

Descargar listado de papers

Figura 4.19: Casos de uso de descarga de certificados y listado papers

4.8.13 Configuración de la aplicación

Caso de Uso 70: Modificar parámetros de la conferencia

Los administradores podrán modificar los datos descriptivos de la conferencia, incluyendo año,

fechas, lugar de celebración, CIF, cuota de inscripción y parámetros de las etiquetas

autogeneradas, entre otros.

Escenario 70.1


Poscondiciones Los parámetros de la conferencia almacenados en la base de datos pasarán a reflejar los valores proporcionados.

Excepciones - Si el año de la conferencia proporcionado no está comprendido ente 2010 y 2020, se mantendrá el valor anterior.

- Si la URL de la conferencia tiene una sintaxis no válida, o no utiliza el protocolo http:// o https://, se mantendrá la URL anterior.

- Si el valor indicado como cuota es menor o igual a cero, es mayor que 9999, o no es un número válido se mantendrá la cuota anterior.



Descripción Los administradores podrán modificar: año, fecha y lugar del congreso, URL del congreso, CIF, ISBN, ISSN, fechas de firma de facturas y certificados, cuota a pagar, y tamaño y orientación de las etiquetas


R.11.18, R.11.19



Caso de Uso 71: Modificar configuración de envío de correos

Los administradores podrán modificar los datos de conexión y autentificación del servidor de

correo utilizado para el envío de notificaciones a organizadores y ponentes.

Escenario 71.1


Poscondiciones Los parámetros utilizados para el envío de coreos almacenados en la base de datos pasarán a reflejar los valores proporcionados.




Descripción Los administradores podrán modificar los parámetros de conexión al servidor SMTP utilizado para el envío de notificaciones.


R.7.5

Caso de Uso 72: Modificar destino de las notificaciones

Los administradores podrán modificar la lista de direcciones de correo a las cuales enviar

notificaciones administrativas.

Escenario 72.1


Poscondiciones La lista de direcciones de correo electrónico a las que enviar las notificaciones generadas por la aplicación almacenadas en la base de datos pasará a reflejar los valores proporcionados (eliminándose cualquier otra anterior).

Excepciones Si se proporciona un valor vacío el sistema no enviará notificaciones.



Descripción Los administradores podrán modificar la lista de direcciones de correo electrónico a las cuales enviar notificaciones sobre la actividad de administradores y ponentes.


R.7.4



Administrador

Modificar configuración de envío de correos

Modificar parámetros de la conferencia

Modificar destino de las notificaciones

Figura 4.20: Casos de uso generales de configuración

Caso de Uso 73: Modificar número de secuencia para las facturas de

España

Los administradores podrán modificar el siguiente número de secuencia a utilizar para la

asignación automática de números de factura para los ponentes de España.

Escenario 73.1


Poscondiciones El siguiente número a utilizar en la asignación automática de números de factura para las facturas de ponentes de España pasará a ser el proporcionado.

Excepciones Si no se proporciona un número natural se mostrará un error y no se hará nada.



Descripción Los administradores podrán modificar el número de secuencia a partir del cual comenzarán a numerarse las facturas de España. Dicho número será usado la próxima vez que se solicite asignar automáticamente números de factura a los ponentes de España cuyo pago esté confirmado.


R.3.13



Caso de Uso 74: Modificar número de secuencia para las facturas del

resto de países

Los administradores podrán modificar el siguiente número de secuencia a utilizar para la

asignación automática de números de factura para los ponentes de fuera de España.

Escenario 74.1


Poscondiciones El siguiente número a utilizar en la asignación automática de números de factura para las facturas de ponentes de fuera de España pasará a ser el proporcionado.

Excepciones Si no se proporciona un número natural se mostrará un error y no se hará nada.



Descripción Los administradores podrán modificar el número a partir del cual comenzarán a numerarse las facturas de fuera de España. Dicho número será usado la próxima vez que se solicite la asignación automática de números de factura para los ponentes de fuera de España cuyo pago esté confirmado.


R.3.14

Administrador

Modificar número de secuencia para lasfacturas de España

Modificar número de secuencia para lasfacturas del resto de países

Figura 4.21: Casos de uso para la configuración de los números de factura

Caso de Uso 75: Habilitar acceso público

Los administradores podrán habilitar el acceso y registro de nuevas cuentas de ponente en

caso de estar deshabilitado.

Escenario 75.1

Precondiciones El acceso público a la página está deshabilitado.

Poscondiciones El sistema permitirá iniciar sesión a los usuarios cuya cuenta no sea de tipo administrativo.




Descripción Los administradores podrán permitir el acceso al sistema a los ponentes para labores de consulta, modificación de facturas y (bajo ciertas condiciones) envío y modificación de papers.


R.10.1, 10.2



Caso de Uso 76: Deshabilitar acceso público

Los administradores podrán deshabilitar el acceso y registro de nuevas cuentas de ponente en

caso de estar habilitado.

Escenario 76.1

Precondiciones El acceso público a la página está habilitado.

Poscondiciones - El sistema no permitirá iniciar sesión a los usuarios cuya cuenta no sea de tipo administrativo.

- Los usuarios que hubiesen iniciado sesión en el sistema en el momento de deshabilitar el acceso público no podrán realizar más acciones.




Descripción Los administradores podrán restringir el acceso al sistema a los ponentes, evitando que éstos consulten y modifiquen sus datos, incluyendo el envío de papers y justificantes.


R.10.1, R.10.2

Caso de Uso 77: Abrir plazo de envío de papers

Los administradores podrán habilitar el envío de papers (tanto nuevos como revisiones de los

existentes, siempre que se cumplan las condiciones adicionales necesarias) de manera global.

Escenario 77.1

Precondiciones El plazo de envío de papers está cerrado.

Poscondiciones El sistema permitirá a los ponentes el envío de nuevos papers y la modificación de los existentes.




Descripción Los administradores podrán permitir el envío de nuevos papers y la modificación de los existentes para los ponentes.


R.5.13



Caso de Uso 78: Cerrar plazo de envío de papers

Los administradores podrán deshabilitar el envío de papers (tanto nuevos como revisiones de

los existentes) de manera global.

Escenario 78.1

Precondiciones El plazo de envío de papers está abierto.

Poscondiciones El sistema no permitirá a los ponentes el envío de nuevos papers ni modificación de los existentes.




Descripción Los administradores podrán restringir el envío de nuevos papers a los ponentes, sin influir en el resto de acciones permitidas para ellos, incluyendo la modificación de sus datos personales o el envío de justificantes de pago.


R.5.13

Administrador

Deshabilitar acceso público

Habilitar acceso público

Abrir plazo de envío de papers

Cerrar plazo de envío de papers

Figura 4.22: Casos de uso para la configuración de acceso



Caso de Uso 79: Verificar funcionamiento del envío de correos

Los administradores podrán solicitar al sistema el envío de un correo electrónico a una

dirección de correo electrónico concreta para verificar que la configuración de correo actual

funciona correctamente.

Escenario 79.1



Excepciones Si no se proporciona una dirección de correo electrónico de destino el sistema infromará de ello en la salida de depuración, y no intentará la comunicación con el servidor SMTP.



Descripción Para verificar el correcto funcionamiento del sistema de notificaciones con la configuración guardada, los administradores podrán solicitar el envío un correo electrónico a una dirección dada e inspeccionar los mensajes intercambiados entre el sistema y el servidor SMTP.


R.7.6, R.7.7

Administrador

Verificar funcionamiento del envío de correos

Figura 4.23: Casos de uso para la verificación del envío de correos

4.8.14 Información estadística

Caso de Uso 80: Listar autores

Los administradores tendrán acceso a un listado con el nombre, institución asociada, país y

número de papers y posters enviados para todos los usuarios que hayan enviado algún paper.

Escenario 80.1






Descripción Los administradores podrán acceder a una página con el listado de los usuarios registrados que han enviado algún paper.


R.9.8



Caso de Uso 81: Descargar listado de autores

Los administradores podrán descargar un archivo digital con el listado de usuarios que hayan

enviado algún paper y sus datos más relevantes, incluyendo su nombre, institución asociada,

país de procedencia y número de papers y posters enviados.

Escenario 81.1






Descripción Los administradores podrán descargar un listado en formato Excel con la información de los usuarios que han enviado algún paper.


R.11.11

Caso de Uso 82: Ver estadísticas

Los administradores tendrán acceso a una página con información estadística agregada de

asistentes, papers, pagos y países de procedencia.

Escenario 82.1






Descripción Los administradores podrán acceder a una página con estadísticas resumidas sobre usuarios registrados, papers enviados, pagos realizados y países de procedencia.


R.9.1, R.9.2, R.9.3, R.9.4, R.9.5, R.9.6, R.9.7



Figura 4.24: Casos de uso para la obtención de información de autores

Administrador

Ver estadísticas

Figura 4.25: Casos de uso para la obtención de información estadística

AdministradorDescargar listado de autores

Listar autores

Diseño e implementación | Plataforma web para la gestión de conferencias científico-técnicas


5 DISEÑO E IMPLEMENTACIÓN

5.1 Particionamiento físico de subsistemas

Debido a la naturaleza de la aplicación, ésta podría ejecutarse completamente desde un único servidor

(servidor web, de envío de correos y base de datos) o distribuir los distintos componentes en

servidores físicos independientes. Además, el estado global de la aplicación queda definido a partir de

los datos de la base de datos y los archivos enviados, por lo que podrían utilizarse múltiples servidores

web siempre que éstos dispongan de un sistema de archivos distribuido (como NFS) donde guardar los

archivos enviados por los ponentes y la información de las sesiones de usuario activas. El uso de

múltiples servidores físicos para la base de datos sería posible utilizando esquemas de replicación

multi-master estándar de MySQL, de forma que todas las escrituras se realizarían en todos los

servidores físicos, mientras que las lecturas se realizarían de forma distribuida.

En cualquier caso, para la carga esperada es suficiente un único servidor físico que gestione tanto las

solicitudes HTTP como la base de datos, por lo que ha sido la solución adoptada. Aun así, existen

subsistemas secundarios externos a la propia aplicación, pero que son esenciales para su correcto

funcionamiento, como los propios sistemas de acceso a Internet y los servidores SMTP utilizados para

el envío de correos electrónicos. En nuestro caso, al estar ubicados en una red académica estatal, el

acceso a Internet está proporcionado por RedIRIS, mientras que el servicio de envío de correo utilizado

está proporcionado por Google (aunque podría utilizarse cualquier otro proveedor en ambos casos).

« »

: pirweb

« »

« »« »

« »

: webcmmse: webcmmse

: cmmse Schema

...

« »

Figura 5.1: Diagrama de despliegue lógico (detalle de procesos del servidor físico)

Plataforma web para la gestión de conferencias científico-técnicas | Diseño e implementación


RedIRIS

Internet

Google

Figura 5.2: Diagrama simplificado de sistemas externos usados por la aplicación



5.2 Implementación de funcionalidades dinámicas de la

interfaz de administración

Utilizando Javascript, la aplicación permite realizar llamadas a algunos controladores de administración

por medio de funcionalidades de RPC asíncrono conocidas comúnmente como AJAX. Estas llamadas

invocan a las acciones definidas por los controladores del espacio de nombres

\CMMSE\Controllers\Admin\JSON y modifican el estado de papers, simposios, facturas y justificantes

sin necesidad de recargar completamente las páginas desde las que se realizan. En su lugar, se envía

una solicitud al servidor en segundo plano y, en función de la respuesta, se actualizan partes de las

páginas, modificando el DOM de los elementos afectados por el cambio utilizando jQuery (por

ejemplo, mostrando u ocultando controles adicionales, o actualizando el valor de campos de texto).

La invocación de estas acciones está sujeta a los mecanismos de seguridad estándar del sitio, y

retornan un objeto JSON con los nuevos datos, o un código y (en ciertos casos) un mensaje de error si

no es posible técnicamente realizar el cambio (por ejemplo, si el servidor MySQL retorna un error) o si

el usuario no dispone de permisos para ello (por ejemplo, si la sesión del administrador que solicita el

cambio ha expirado).

Además, existen otros métodos auxiliares encargados de la inicialización de la interfaz de

administración, incluyendo la ordenación y el resaltado de filas seleccionadas de las tablas en el lado

del cliente, el cambio del target de los enlaces a PDFs (lo cual hace que ciertas descargas, como las

facturas y los papers, se abran en pestañas nuevas de manera predeterminada) o la inclusión dinámica

de un botón para volver a la parte superior de la página en aquellas que incluyen listados que requieran

el uso de scroll para recorrerse de forma completa.

El código Javascript asociado a la interfaz de administración se encuentra en el archivo admin.js del

subdirectorio static de webcmmse. Al igual que en la implementación de la aplicación del lado del

servidor, las funciones aquí descritas están organizadas emulando espacios de nombres a partir de un

objeto global cmmse que incluye, a su vez, otros objetos para representar la jerarquía de métodos de

administración.

Las propiedades y métodos aquí descritos se corresponden con propiedades de los citados objetos.

Todos los objetos son estáticos, es decir, contienen únicamente métodos y no guardan estado interno,

recurriendo a los valores expuestos por el DOM del documento HTML en los casos en los que es

necesario.



5.2.1 cmmse.admin

Inicialización de ordenación de tablas

Función anónima utilizada para inicializar el plugin jQuery Tablesorter sobre los listados (de usuarios,

papers, simposios, etc).

Inicialización del enlace de regreso a la parte superior del panel de administración.

Función anónima utilizada para mostrar un enlace que permita volver a la parte superior del panel de

administración, animando el desplazamiento tras hacer clic sobre él.

Inicialización de los objetivos de los enlaces de descarga del panel de administración

Función anónima invocada tras la carga del DOM del panel de administración que comprueba que la

URI de la página actual se corresponde con alguna del panel de administración y, en ese caso, invoca

a cmmse.admin.change_targets().

change_targets() : void

Cambia el atributo objetivo (target) de los enlaces del panel de administración que apuntan a las URIs

de descarga de archivos PDF generados dinámicamente (justificantes de pagos confirmados, facturas,

certificados de asistencia…) y enviados por los usuarios (justificantes y papers enviados por éstos).

5.2.2 cmmse.admin.json

endpoint_base_uri : string

String que contiene la URL base para las llamadas a funciones AJAX. La implementación actual apunta

a la URI /webcmmse/index.php/admin/json/.

uris : string[]

Vector que contiene las URIs, relativas a endpoint_base_uri (descrito anteriormente), utilizadas para

invocar las distintas acciones AJAX del panel de administración.

getURI(string args….) : string

Función variadica encargada de generar una URI a partir de la URI base y de los parámetros utilizados

para su invocación14.

doRequest(string endpoint, string callback, object|string postData) : boolean

Función utilizada para iniciar una solicitud asíncrona a la URI indicada como parámetro. Si el parámetro

postData es distinto de null, se enviará su contenido como parámetros POST (realizando las

conversiones oportunas para su transmisión a través de la red).

14 Por ejemplo, las llamadas a cmmse.admin.json.getURI(cmmse.admin.json.uris.set_paidflag, uid, flag) se corresponden con URIs tipo /webcmmse/index.php/admin/json/set_paidflag/<uid>/<flag>.



Además, la llamada a la función mostrará una animación y un mensaje en la parte superior del panel

de administración para indicar que se está esperando la respuesta del servidor a la solicitud realizada.

Tras obtener respuesta, se remplazará el mensaje anterior para indicar si la solicitud ha sido ejecutada

satisfactoriamente (mostrando “Cambios guardados”) o se han producido errores (mostrando “Error”

o un mensaje de error específico, en caso de que el servidor lo haya proporcionado). En caso de que

no se produzcan errores, se inicializará un temporizador para ocultar el mensaje informativo dos

segundos después de mostrarse.

Esta función retorna falso siempre, de forma que se impide, en los casos en que es aplicable, que el

navegador siga los enlaces al hacer clic en ellos, de forma que las distintas acciones se realizan

exclusivamente utilizando AJAX en lugar de solicitar una nueva página, a la vez que se permite seguir

los enlaces de la manera estándar en los navegadores que no soportan solicitudes AJAX.

5.2.3 cmmse.admin.users

allowOverflow() : void

Función invocada para mostrar los campos ocultos de la lista de ponentes del panel de administración.

Es invocada cuando un administrador situado en la lista de usuarios solicita que se muestren los

campos de la tabla de usuarios ocultados automáticamente al utilizar una resolución de pantalla

demasiado baja o tener la ventana del navegador redimensionada a un tamaño inferior al necesario

para mostrar todos los datos de forma clara.

5.2.4 cmmse.admin.invoices

setpaidflag(integer uid, integer flag) :void

Realiza una solicitud AJAX para confirmar o eliminar la confirmación de pago del usuario asociado a un

justificante desde la lista de usuarios que han solicitado factura, mostrando, ocultando, habilitando

y/o deshabilitando controles adicionales para el mismo en función del nuevo estado.

setbillprint(integer uid, integer flag) : void

Realiza una solicitud AJAX para marcar el flag que indica si la factura asociada a un usuario dado está

lista para ser impresa, deshabilitando todos los controles asociados al mismo para impedir su

modificación posterior.

set_billno(integer uid) : void

Realiza una solicitud AJAX para cambiar el número de factura de un usuario al valor indicado en el

cuadro de texto asociado al mismo.

set_fee(integer uid) : void

Realiza una solicitud AJAX para cambiar la cuota a pagar por un usuario al valor indicado en el cuadro

de texto asociado al mismo. En caso de que el cuadro de texto esté vacío, solicita asignarle la cuota

por defecto.



getbillstatus(integer uid, string callback) : object

Realiza una solicitud AJAX para obtener la información de facturación asociada al usuario indicado,

incluyendo, entre otros, si se ha confirmado el pago, el número de factura, si la factura está lista para

imprimir o el nombre de archivo del justificante enviado.

5.2.5 cmmse.admin.proofs

setpaidflag(integer uid, integer flag) : void

Realiza una solicitud AJAX para establecer o eliminar la confirmación de pago del usuario asociado a

un justificante desde la lista de usuarios que no han solicitado factura, mostrando, ocultando,

habilitando y/o deshabilitando controles adicionales para el mismo en función del nuevo estado.

set_fee(integer uid) : void

Realiza una solicitud AJAX para cambiar la cuota a pagar o asignar la cuota por defecto a un usuario

que no ha solicitado factura, y muestra u oculta la etiqueta que indica si el usuario tiene asigada la

cuota por defecto.

5.2.6 cmmse.admin.papers

setdecisionflag(integer paper_id, boolean decision) : void

Realiza una solicitud AJAX para establecer o eliminar el flag que indica que un paper ha entrado en

proceso de revisión, mostrando, ocultando, habilitando y/o deshabilitando controles adicionales para

el mismo en función del nuevo estado.

setacceptedflag(integer paper_id, integer iduser, boolean accepted) : void

Realiza una solicitud AJAX para establecer o eliminar el flag que indica que un paper ha sido aceptado

para su presentación en el congreso, mostrando, ocultando, habilitando y/o deshabilitando controles

adicionales para el mismo en función del nuevo estado.

5.2.7 cmmse.admin.papers.edittitle

show_input(integer paper_id) : void

Muestra los controles asociados a un paper para permitir la edición del título del mismo.

save(integer paper_id) : void

Realiza una solicitud AJAX para cambiar el título del paper indicado utilizando el valor actual del cuadro

de texto asociado al mismo.

cancel(integer paper_id) : void

Oculta los controles de edición del nombre para el paper indicado.



5.2.8 cmmse.admin.papers.rooms

show_input(integer paper_id) : void

Muestra los controles asociados a un paper (de tipo poster) para permitir la edición de la sala y fechas

asignadas para la exposición del mismo.

save(integer paper_id) : void

Realiza una solicitud AJAX para cambiar la sala y fechas asignadas para la exposición del paper (de tipo

poster) indicado.

cancel(integer paper_id) : void

Oculta los controles de edición de sala y fechas asignadas para la exposición del paper (de tipo poster)

indicado.

5.2.9 cmmse.admin.rooms.edittitle

show_input(integer room_id) : void

Muestra los controles asociados a una sala para permitir la edición del nombre de la misma.

save(integer room_id) : void

Realiza una solicitud AJAX para cambiar el nombre de una sala utilizando el valor actual del cuadro de

texto asociado a la misma.

cancel(integer room_id) : void

Oculta los controles de edición del nombre de la sala indicada.

5.2.10 cmmse.admin.conferences.edittitle

show_input(integer conference_id) : void

Muestra los controles asociados a un simposio para permitir la edición del título del mismo.

save(integer conference_id) : void

Realiza una solicitud AJAX para cambiar el título del simposio indicado utilizando el valor actual del

cuadro de texto asociado al mismo.

cancel(integer conference_id) : void

Oculta los controles de edición del título del simposio indicado.



5.2.11 cmmse.admin.conferences.editdate

show_input(integer conference_id) : void

Muestra los controles asociados a un simposio para permitir la edición de la fecha y hora de inicio del

mismo.

save(integer conference_id) : void

Realiza una solicitud AJAX para cambiar la fecha y hora de inicio del simposio indicado utilizando el

valor actual del cuadro de texto asociado al mismo.

cancel(integer conference_id) : void

Oculta los controles de edición de la fecha y hora de inicio del simposio indicado.



5.3 Subsistemas de diseño

La aplicación está estructurada en un total de 23 espacios de nombres jerárquicos, 16 definiciones de

interfaz, 9 traits y 126 clases (de las cuales 6 son abstractas). El diseño de estos espacios de nombres

sigue la jerarquía expresada en el siguiente diagrama UML:

Permissions Core

Doctrine Decorators

Exceptions Traits

Permissions Controllers

Labels92x625

Labels15x75

Models

Factories

User

Frontcontrollers

JSON

PDF

AutoloaderData

Figura 5.3: Diagrama UML general de los espacios de nombres de la aplicación



Existen espacios de nombres adicionales generados de forma automática para los proxys de Doctrine

y otros correspondientes a librerías (todos ellos fuera de \CMMSE). Además, los elementos que

constituyen la interfaz gráfica de la aplicación no están, en general, contenidos en espacios de nombres

tradicionales, sino que están definidos utilizando plantillas de texto ubicadas en un directorio

independiente15.

5.4 Diseño de clases

A continuación se describe la estructura lógica de la aplicación, partiendo de los componentes básicos

hasta llegar a aquellos más complejos construidos a partir de los primeros. La implementación de la

aplicación está contenida en el espacio de nombres \CMMSE, el cual encapsula al autocargador de

componentes de la aplicación y al resto de espacios de nombres.

En los diagramas de las siguientes secciones se han omitido los espacios de nombres anidados, salvo

en los casos en los que se ha considerado relevante representarlos. Igualmente, por brevedad, se han

omitido las secciones de atributos y constantes en aquellas clases que no poseen propiedades o no

definen constantes propias.

15 El mecanismo general y el listado de los diferentes componentes que constituyen la interfaz de usuario están detallados en los apartados Diseño de la interfaz de usuario y Diseño físico de datos.



5.4.1 \CMMSE

Espacio de nombres raíz de la aplicación, que contiene al autocargador de componentes y al resto de

espacios de nombres.

Autoloader

Esta clase se encarga de cargar los archivos que contienen el código del resto de componentes del sitio

bajo demanda, utilizando los mecanismos provistos por el lenguaje para este propósito.

5.4.1.1.1 Constantes

REQUIRED_VERSION : string

Contiene la versión mínima de PHP necesaria para el funcionamiento de la aplicación. En la

versión actual de la aplicación esta constante toma el valor “5.5.0”.

5.4.1.1.2 Métodos

public static function checkPHPVersion() : void

Comprueba si está soportada la versión de PHP sobre la que se está ejecutando la aplicación.

En caso de no estarlo, retorna una página de error interno al cliente como respuesta a todas

las solicitudes, impidiendo la ejecución del resto de componentes de la aplicación.

public static function autoload(string $class) : void

Busca el componente indicado como parámetro a partir de los datos del espacio de nombres

\CMMSE\AutoloaderData y sus descendientes y, si el componente está definido, carga el

archivo con su código fuente. Esta función es llamada automáticamente por el intérprete de

PHP para la carga de componentes bajo demanda.

protected static function initLog4php() : void

Inicializa el sistema de logging log4php utilizado por la aplicación.

protected static function initExceptionHandler() : void

Inicializa el gestor de excepciones del sitio, convirtiendo los errores estándar del lenguaje en

excepciones capturables.

public static function init() : void

Inicializa el gestor de librerías Composer y el entorno básico del sitio: autocargardor de clases,

sistema de logging y configuración.



5.4.2 \CMMSE\AutoloaderData

Espacio de nombres con la información necesaria para cargar los archivos de código fuente del resto

de la aplicación. Las clases y espacios de nombres contenidos aquí emulan la jerarquía del resto de

componentes de la aplicación y son utilizados por el autocargador para encontrar el archivo de código

fuente correspondiente a cada clase, trait e interfaz.

Autoloader

+ REQUIRED_VERSION : string = '5.5.0'

+ checkPHPVersion() : void

+ init() : void+ autoload(string $class) : void

# initLog4php() : void# initExceptionHandler() : void

__ROOT__ CMMSE

Core

+ AbstractModel : string = 'core/abstract_model.inc.php'

...+ ArrayCache : string = 'core/array_cache.inc.php'

Doctrine

+ Conference : string = entities/doctrine/conference.inc.php'...

__ROOT__

...

Labels92x625

...

Labels92x625

...

__ROOT__

...

Models

...

__ROOT__

...

User

...

FrontControllers

...

__ROOT__

...

PDF

...

JSON

...

<< usa >>

Figura 5.4: Diagrama UML de las clases utilizadas para implementar el autocargador



5.4.3 \CMMSE\Core

Este espacio de nombres contiene los componentes que forman parte del núcleo de la aplicación,

sobre los cuales se construye el resto.

ArrayCache

Implementación de una caché de datos simple para Doctrine sobre arrays asociativos de PHP. La

implementación está realizada por herencia a partir de la clase proporcionada por Doctrine para el

mismo propósito, extendiéndola para proporcionar estadísticas de su rendimiento.

Los métodos protegidos definidos por esta clase basan su implementación en la de la clase de la que

extienden y son llamados por los métodos públicos de ésta (que definen la interfaz real con el resto de

objetos de Doctrine) dinámicamente (utilizando enlace en tiempo de ejecución).

Los métodos cuya herencia es directa (es decir, aquellos que no se han redefinido para guardar

estadísticas) no se muestran.

5.4.3.1.1 Atributos

protected $hits: integer

Número de aciertos en la caché.

protected $misses: integer

Número de fallos en la caché.

5.4.3.1.2 Métodos

protected function updateStats(string $key) : void

Comprueba a través de la clase padre si existen datos almacenados con la clave dada,

incrementando en una unidad el número de aciertos o fallos registrados.

protected function doFetch(string $key) : mixed

Obtiene el valor asociado a la clave dada, o falso en caso de error.

protected function doContains(string $key) : boolean

Comprueba si existe un valor guardado previamente asociado a la clave dada.

protected function doGetStats() : integer[]

Genera un array con la estructura esperada por Doctrine con estadísticas de número de

aciertos y fallos. Las estadísticas de otro tipo (tiempo de uso del caché, memoria usada y

memoria disponible) no son reportadas (se retornan como null), ya que la API de Doctrine no

requiere retornar valores para todas las métricas posibles.

Como índices del array retornado se utilizan las definiciones de constante proporcionadas por

la interfaz genérica \Doctrine\Common\Cache\Cache de Doctrine.



ArrayCache

# misses : integer

# doGetStats() : integer[]

# hits : integer

# updateStats() : void# doFetch() : mixed# doContains() : boolean

ArrayCache


- data : mixed[]

# doFetch() : void# doContains() : boolean

# doSave() : boolean

# doFlush() : boolean# doDelete() : boolean

CacheProvider


+ DOCTRINE_NAMESPACE_CACHEKEY : string = 'doctrineNamespaceCacheKey[%s]'

+ setNamespace($namespace : string) : void

# doContains() : boolean

# doSave() : boolean

# doFlush() : boolean# doDelete() : boolean

<<Interfaz>>

Cache

+ STATS_MEMORY_AVAILABLE : string = 'memory_available'

+ STATS_MISSES : string = 'misses'+ STATS_HITS : string = 'hits'

- namespace : string- namespaceVersion : string

# doFetch() : void

+ flushAll() : boolean

+ getNamespace() : string

+ contains(string $id) : boolean

+ getStats() : integer[]

+ save(string $id, mixed $data[, integer $lifetime]) : boolean

+ fetch(string $id) : mixed

+ delete(string $id) : boolean

+ deleteAll() : boolean

- getNamespaceVersion() : string- getNamespaceCacheKey() : string- getNamespacedId(string $id) : string

+ contains(string $id) : boolean

+ getStats() : integer[]

+ save(string $id, mixed $data[, integer $lifetime]) : boolean

+ fetch(string $id) : mixed

+ delete(string $id) : boolean

+ STATS_MEMORY_USAGE : string = 'memory_usage'+ STATS_UPTIME : string = 'uptime'

Figura 5.5: Diagrama UML de la clase ArrayCache



Configuration

Implementación de un lector de la configuración estática del sitio (almacenada en archivos .ini). Esta

clase implementa el patrón de diseño singleton, pudiendo existir como máximo una única instancia de

la misma, a la cual se accede a través de un método estático de la propia clase.

El constructor de esta clase es de ámbito protegido y no puede ser instanciada directamente.

5.4.3.2.1 Atributos

protected $reader: \ezcConfigurationIniReader

Referencia a una instancia de un lector de archivos .ini de ezComponents.

protected $cfg: \ezcConfiguration

Referencia a una instancia de un objeto de ezComponents utilizado para leer información de

configuración de manera independiente a la plataforma y el formato de archivo.

protected $data: string[][]

Matriz 2D utilizada para mantener los datos de configuración leídos. Esta matriz es accedida

utilizando pares (nombre de sección, nombre de parámetro).

protected $log: \Logger

Referencia al logger a través del cual registrar los mensajes de depuración producidos durante

la lectura de la configuración.

5.4.3.2.2 Métodos

protected static function __construct() : void

Crea una nueva instancia de un objeto usado para acceder a la configuración estática del sitio

tras la lectura del archivo .ini que la almacena.

Excepción: Si el archivo de configuración de la aplicación no existe o no es accesible, se lanza

una excepción capturable de tipo \CMMSE\Exceptions\GenericException.

public static function getInstance ([boolean $force_reload]) : \CMMSE\Core\Configuration

Retorna una referencia a una instancia de la clase, creándola ad hoc o reutilizando una

existente. Si el parámetro opcional toma como valor cierto la llamada al método retornará una

nueva instancia de la clase, lo cual provoca que vuelva a leerse la configuración desde disco.

Nota: La posibilidad de volver a leer los datos de disco se proporciona para facilitar el diseño

de pruebas automáticas, su uso con otros propósitos está desaconsejado.

Nota: En caso de ser invocada a través de una clase que extienda ésta, getInstance() retornará

una instancia de la nueva clase utilizando la característica de enlace estático en tiempo de

ejecución (late static binding) del lenguaje.



public function __get (string $key) : object

Retorna un objeto anónimo con los datos de configuración estáticos de la sección identificada

por la clave dada. En caso de no existir una sección con el nombre solicitado (o si ésta no

contiene directivas de configuración), el objeto retornado no contendrá datos.

Este método es un método mágico invocado automáticamente en los casos en los que se

acceda al objeto utilizando la sintaxis $configuracion->sección. Los datos de configuración de

la sección solicitada serán accesibles a través de la sintaxis de lectura de propiedades de objeto

estándar del lenguaje (por ejemplo, utilizando $seccion->atributo o $configuracion->seccion-

>atributo).

public function __isset (string $key) : boolean

Comprueba si existe una sección identificada por la clave dada.

Este método es un método mágico invocado automáticamente en los casos en los que se

compruebe la existencia de una sección de configuración utilizando la sintaxis

isset($configuracion->sección).

public function getRootPath() : string

Obtiene y retorna la ruta del directorio raíz real de la aplicación, resolviendo enlaces simbólicos

y componentes que referencien a directorios relativos (como “/./” y “/../”). 16 El término

“directorio raíz” se refiere a la ruta absoluta “canonizada” a partir de la cual se encuentran

todos los archivos de la aplicación (públicos y privados) y contiene, entre otros, a los directorios

webcmmse, private y scripts.

Email

Esta clase proporciona una interfaz sencilla para representar los correos electrónicos a enviar por la

aplicación. Es utilizada por los controladores para definir los mensajes de correo enviar, y es pasada

como parámetro a las funciones de envío de correo electrónico.

5.4.3.3.1 Atributos

public $subject: string

Asunto del correo electrónico.

public $from: string

Remitente del correo electrónico.

public $to: string

Destinatario del correo electrónico.

public $body: string

Texto plano del correo electrónico. Los correos enviados por la aplicación no soportan tipos

especiales, como código HTML, en el cuerpo del documento.

16 La semántica de este método equivale a la que se esperaría de una implementación de realpath() conforme a POSIX al ser llamada sobre el directorio raíz de la aplicación.



5.4.3.3.2 Métodos

Esta clase no define métodos propios.

Configuration

# $reader : \ezConfigurationIniReader# $cfg : \ezConfiguration

+ __isset(string $key) : boolean

# $log : \Logger# $data : string[][]

# __construct() : void

+ __get(string $key) : object

+ getRootPath() : string+ getInstance([boolean $force_reload]) : Configuration

EMail

+ $subject : string

+ $body : string+ $to : string+ $from : strnig

Logger

ezConfiguration

ezConfigurationIniReader

Figura 5.6: Diagrama UML de las clases Configuration e EMail

HTTP404DieHandler

Esta clase proporciona el gestor por defecto utilizado por los controladores cuando no es posible

“encaminar” una URL, es decir, cuando alguna de las partes de la URL solicitada no coincide con

ninguna acción declarada en la sucesión de controladores instanciados y no existe una acción para la

captura de parámetros aleatorios.

La acción realizada por este gestor para el tratamiento de URLs no encaminables es el envío al cliente

de un código de error 404 HTTP de página no encontrada junto al texto “404” y la finalización del

procesamiento de la solicitud actual.

5.4.3.4.1 Métodos

public function __invoke() : void

Envía un encabezado de error 404 HTTP de página no encontrada al cliente y finaliza la

ejecución de la solicitud actual (utilizando die()). Este método mágico es llamado cuando una



instancia de la clase es utilizada como si fuese una función17, permitiendo así el uso de estos

objetos como callbacks válidos.

AbstractController HTTP404DieHandler

+__invoke() : void

Figura 5.7: Diagrama UMl de la clase HTTP404DieHandler

cEzPDFStreamer

Esta clase proporciona mecanismos para gestionar el envío de archivos PDF al navegador del cliente.

5.4.3.5.1 Métodos

public function __construct(\Cezpdf $object) : void

Crea una nueva instancia de un objeto utilizado para el envío de archivos PDF a partir de un

objeto de bajo nivel de la librería ezComponents.

public function stream([string $filename]) : void

Envía al buffer de salida actual (normalmente la conexión establecida con el cliente) los datos

del objeto PDF utilizado durante la invocación del constructor, junto a los encabezados HTTP

que indican su tipo y tamaño. Tras el envío del contenido, esta función no finaliza la ejecución

del script actual.

El archivo se genera utilizando los wrappers proporcionados por PHP para datos temporales,

generando el contenido inicialmente en memoria y pasando al uso de archivos en disco si el

contenido generado sobrepasa los 5 MB, proporcionando velocidad para archivos pequeños y

uso reducido de recursos para archivos grandes.

Si se omite el nombre de archivo, el PDF enviado tendrá el nombre por defecto

downloaded.pdf.

public static function mPDF_stream(\mPDF $document [, string $filename]) : void

Envía al buffer de salida actual (normalmente la conexión establecida con el cliente) los datos

del objeto mPDF utilizado como parámetro, junto a los encabezados HTTP que indican su tipo

y tamaño. Tras el envío del contenido, esta función no finaliza la ejecución del script actual.

Si se omite el nombre de archivo, el PDF enviado tendrá el nombre por defecto doc.pdf.

public static function stream_html_as_pdf(string $html [, string $filename]) : void

Genera un archivo PDF a partir del contenido HTML pasado como parámetro y lo envía al buffer

de salida actual (normalmente la conexión establecida con el cliente) junto a los encabezados

17 En programación, un objeto que permiten este tipo de uso suele denominarse function object.



HTTP que indican su tipo y tamaño. Tras el envío del contenido, esta función no finaliza la

ejecución del script actual.

Los metadatos del archivo generado, como su título, asunto, palabras clave y autor se toman

de los tags <meta> del código HTML, si en éste están definidos.

Si se omite el nombre de archivo, el PDF enviado tendrá el nombre por defecto download.pdf.

public static function stream_html_array_as_pdf(string[] $html [, string $filename]) : void

Genera un archivo PDF a partir de un array con el código HTML que representa el contenido

de las páginas del mismo y lo envía al buffer de salida actual (normalmente, la conexión

establecida con el cliente) junto a los encabezados HTTP que indican su tipo y tamaño. Tras el

envío del contenido, esta función no finaliza la ejecución del script actual.

Los metadatos del archivo generado, como su título, asunto, palabras clave y autor se toman

de los tags <meta> del código HTML, si en éste están definidos.

Si se omite el nombre de archivo, el PDF enviado tendrá el nombre por defecto download.pdf.

cEzPDFStreamer

# $intern : \Cezpdf

+ __construct(\Cezpdf $object) : void

+ stream_html_array_as_pdf(string[] $html[, string $filename]) : void+ stream_html_as_pdf(string $html[, string $filename]) : void+ mPDF_stream(\mPDF $document[, string $filename]) : void+ stream([string $filename]) : void

<<Usa>>

index.php

Figura 5.8: Diagrama UML de la clase cEzPDFStreamer



MailValidator

+ rfc3696_strip_comments(string $comment, string $email [, string $replace]) : string

Signup

+ validate(string $email) : boolean

+ is_rfc3696_valid_email_address(string $email) : boolean

<<Usa>>

Figura 5.9: Diagrama UML de la clase MailValidator

MailValidator

Esta clase proporciona un validador de direcciones de correo electrónico de acuerdo al formato

especificado en el RFC 3696. El código de esta clase es una adaptación básica de un validador

programado por Cal Henderson licenciado dualmente bajo las licencias open source Creative Commons

BY-SA y GPLv3.

5.4.3.6.1 Métodos

public static function validate(string $email) : boolean

Comprueba si la sintaxis de una dirección de correo electrónico es válida. Este método es un

alias de is_rfc3696_valid_email_address().

public static function rfc3696_strip_comments($comment, $email [, $replace]) : string

Elimina los comentarios que pueda haber en una dirección de correo electrónico

proporcionada.

public static function is_rfc3696_valid_email_address($email) : boolean

Comprueba si la sintaxis de una dirección de correo electrónico es válida.



OverviewData

Esta clase implementa objetos para representar las estadísticas generales agregadas sobre el número

de usuarios registrados, autores, envíos de papers e ingresos.

5.4.3.7.1 Atributos

public $ingresos: integer

Cantidad de dinero recaudada.

public $totalpapers: integer

Número de papers registrados en el sistema.

public $totalpapersaceptados: integer

Número de papers registrados en el sistema en estado aceptado.

public $totalusuarios: integer

Número de usuarios registrados en el sistema.

public $totalusuariospago: integer

Número de usuarios registrados en el sistema cuyo pago ha sido confirmado.

public $totalautores: integer

Número de usuarios registrados en el sistema que han enviado algún paper.

public $totalautorespago: integer

Número de usuarios registrados en el sistema que han enviado algún paper y cuyo pago ha

sido confirmado.

public $totalpaperspago: integer

Número de papers enviados por usuarios cuyo pago ha sido confirmado.

public $ratio_papersperautor: float

Proporción entre papers enviados y autores registrados (es decir, teniendo en cuenta

solamente a aquellos usuarios que han enviado, al menos, un paper).

public $ratio_acceptedperauthor: float

Proporción entre papers aceptados y autores registrados (es decir, teniendo en cuenta

solamente a aquellos usuarios que han enviado, al menos, un paper).

public $ratio_papersperauthorsthatpaid: float

Proporción entre papers enviados y autores registrados cuyo pago ha sido confirmado (es

decir, teniendo en cuenta solamente a aquellos usuarios que han enviado, al menos, un paper

y han pagado).

public $ratio_acceptedpapersperauthorsthatpaid: float

Proporción entre papers aceptados y autores registrados cuyo pago ha sido confirmado (es

decir, teniendo en cuenta solamente a aquellos usuarios que han enviado, al menos, un paper

y han pagado).



5.4.3.7.2 Métodos

public function recalculateRatios() : void

Calcula y establece el valor de las propiedades que representan las diferentes proporciones

entre los datos. En caso de que el número de autores y/o el número de autores que han pagado

sean cero, el o los ratios correspondientes tomarán el valor cero.

<<Interfaz>>

IStatsOverviewData

+ $ratio_acceptedpapersperauthorsthatpaid : float

+ recalculateRatios() : void

+ $ingresos : integer

+ $ratio_papersperauthorsthatpaid : float

+ $totalpapers : integer

+ $ratio_acceptedperauthor : float

+ $totalusuariospago : integer

+ $ratio_papersperauthor : float

+ $totalautores : integer

+ $totalpapersaceptados : integer+ $totalusuarios : integer

+ $totalpaperspago : integer+ $totalautorespago : integer

<<Usa>>

Figura 5.10: Diagrama UML de la clase OverviewData

ScriptStats

Clase para obtener y calcular estadísticas generales de ejecución del script actual a partir de los datos

de entorno disponibles, de los proporcionados por el modelo base y de otros parámetros

proporcionados manualmente.

5.4.3.8.1 Atributos

protected static $start: float

Instante de inicio de ejecución del script.

5.4.3.8.2 Métodos

public static function saveStartTime([float $microtime]) : void

Almacena el timestamp en el que se ha realizado la solicitud de la página actual. Si no se

proporciona el instante de inicio de solicitud, toma como valor el instante (aproximado) de

llamada al método.

public static function guessStartTime() : float

Retorna el valor del instante de inicio de la solicitud de la página actual de la forma más precisa

posible. La implementación actual retornará el valor en coma flotante del instante de inicio de



la solicitud proporcionado por el servidor si dicho valor está disponible (ya que éste es

almacenado por el intérprete antes de ejecutar la aplicación), utilizando el valor proporcionado

previamente a través saveStartTime() como último recurso.

public static function guessElapsedTime() : float

Retorna el número de segundos transcurridos (aproximadamente) entre el instante de llamada

al método y el menor timestamp de inicio de la solicitud actual disponible como un número en

coma flotante.

public static function guessElapsedTimeAsString() : string

Retorna el número de segundos transcurridos (aproximadamente) entre el instante de llamada

al método y el menor timestamp de inicio de la solicitud actual disponible como una cadena

de texto que representa un número en coma flotante redondeado a dos decimales.

public static function getQueryCount() : integer

Retorna el número de consultas SQL ejecutadas directamente contra la base de datos (es decir,

sin utilizar el ORM). Este valor es proporcionado por el modelo base (AbstractModel).

public static function getPeakMemoryUsage() : integer

Retorna la cantidad de memoria máxima utilizada por PHP hasta el momento en kilobytes,

redondeada a dos decimales.

Este método utiliza la función memory_get_peak_usage() del gestor de memoria de PHP,

indicando que no tenga en cuenta la memoria total solicitada por la máquina virtual Zend al

sistema operativo (que siempre solicita segmentos que sean múltiplos de una cantidad fija18),

sino solo aquella que ha sido utilizada directamente por la aplicación PHP.

Log4PHPQueryLogger

Wrapper para registrar las consultas SQL ejecutadas por Doctrine a través de Log4php.

5.4.3.9.1 Atributos

protected $log: \Logger

Referencia al logger a través del cual registrar las consultas SQL.

protected $dbPlatform : \Doctrine\DBAL\Platforms\AbstractPlatform

Tipo de gestor de bases de datos utilizado por Doctrine.

public static $count: integer

Número de consultas totales registradas a través de todas las instancias de la clase.

18 En general, la máquina virtual solicita al sistema operativo regiones de memoria que sean potencias de 2 y mantiene diferentes pools de memoria según el tamaño solicitado por el script (para datos de hasta 4KB, datos con un tamaño múltiplo de 4KB y datos con un tamaño múltiplo de 2MB), además de la memoria extra usada internamente por la máquina virtual para mantener datos adicionales asociados a la solicitud actual y su propia instancia dentro del proceso del servidor web.



ScriptStats

+ saveStartTime([float $microtime]) : void

+ $start : float

<<Usa>>

index.php

AdminController

css.php

+ guessStartTime() : float

+ getPeakMemoryUsage() : integer

+ guessElapsedTimeAsString() : string+ getQueryCount() : integer

+ guessElapsedTime() : float

Figura 5.11: Diagrama UML de la clase ScriptStats

5.4.3.9.2 Métodos

public function __construct(\Logger $parent, \Doctrine\DBAL\Platforms\AbstractPlatform

$dbPlatform) : void

Crea una nueva instancia de un objeto utilizado para el envío de archivos PDF.

public function startQuery(string $sql [, mixed[] $params [, mixed[] $types]]) : void

Registra el inicio de una consulta SQL a través de log4php.

public function stopQuery() : void

Registra el final de una consulta SQL. La implementación actual no hace nada19.

MysqliWrapper

Capa de abstracción básica para realizar consultas directamente al servidor MySQL.

5.4.3.10.1 Atributos

public $counter: integer

Número de consultas SQL realizadas a través de la instancia actual.

public static $counter_static: integer

Número de consultas SQL realizadas a través de todas las instancias de la clase.

19 Esta funcionalidad podría utilizarse, por ejemplo, para registrar el tiempo necesario para ejecutar cada consulta en una ampliación posterior.



5.4.3.10.2 Métodos

public function __construct(string $host , string $user, string $pass) : void

Crea una nueva instancia de un objeto para acceder directamente al servidor MySQL utilizado.

public function query(string $query [, integer $resultmode]) : mixed

Ejecuta una consulta SQL, actualizando los contadores internos de número de consultas.

El parámetro $resultmode representa la forma deseada de obtener los resultados. Consulte la

documentación de mysqli_query() de la API de PHP para obtener una lista de los valores

admitidos para este parámetro.

Retorna falso si se han producido errores. En otro caso:

Para consultas SELECT, SHOW, DESCRIBE o EXPLAIN retornará una instancia de

\mysqli_result.

Para otras consultas (incluyendo UPDATE y DELETE) retornará cierto.

AbstractModel

Implementación del modelo base, que proporciona métodos y objetos sobre los que construir el resto.

Entre las funcionalidades que proporciona se encuentra el acceso al gestor de entidades relacionales,

métodos para realizar consultas “directas” a la base de datos, caché, y logging.

Esta clase es abstracta (no puede ser instanciada).


protected $affected_rows : integer

Número de filas modificadas por la última llamada a query().

protected $log : \Logger

Referencia a la instancia del logger log4php utilizado por la instancia actual.

protected $em : \Doctrine\ORM\EntityManager

Referencia al gestor de entidades Doctrine utilizado por el modelo actual.

protected static $cache : \Doctrine\Common\Cache\Cache

Referencia global a la instancia de cache utilizada por Doctrine para todos los modelos de la

aplicación.

protected static $initialized : boolean

Flag que indica si la referencia global al gestor de entidades Doctrine ha sido inicializada

previamente.

protected static $instance : \Doctrine\ORM\EntityManager

Referencia global a la instancia del gestor de entidades Doctrine utilizada por todos los

modelos.



5.4.3.11.2 Métodos

public final function __construct() : void

Crea una instancia nueva de un modelo, obteniendo un logger para el modelo particular

invocado e inicializando la conexión global a la base de datos utilizada por todos los modelos

si fuera necesario. Este constructor no puede ser redefinido por los modelos concretos al

extender el modelo abstracto.

public static function getConnection() : \CMMSE\Core\MySQLiWrapper

Retorna una instancia a la conexión MySQLi utilizada por el modelo para realizar consultas

directas sobre la base de datos, creándola bajo demanda si fuese necesario.

rotected function select(string $table, string[] $conditions, [string[] $fields]) : \mysqli_result

Ejecuta una consulta SELECT * FORM tabla WHERE … simple sobre la tabla indicada y

retorna una referencia a un objeto que representa el conjunto de resultados obtenido. Este

método se proporciona por razones de compatibilidad (su uso está desaconsejado),

prefiriéndose el uso del gestor de entidades en detrimento de éste siempre que sea posible.

protected function selectjoin(string[] $tables, string[] $join_clauses, string[] $conditions,

[string[] $fields]) : \mysqli_result

Ejecuta una consulta SELECT * FORM tabla LEFT JOIN … WHERE … sobre la tabla

indicada y retorna una referencia a un objeto que representa el conjunto de resultados

obtenido. Este método se proporciona por razones de compatibilidad (su uso está

desaconsejado), prefiriéndose el uso del gestor de entidades en detrimento de éste siempre

que sea posible.

protected static function getBoolean(mixed $value) : boolean

Retorna el valor booleano asociado al valor numérico proporcionado. Se considera que un

valor equivale a cierto si es distinto de cero siguiendo las reglas estándar de conversión débil

de tipos de PHP (esto es, sin atender al tipo de dato proporcionado, permitiendo así convertir

en booleano valores de cadena como “0”).

protected function initializeDoctrine() : void

Inicializa la instancia interna del gestor de entidades Doctrine utilizado los modelos. Este

método interno es invocado durante la instanciación del primer modelo utilizado por la

aplicación; las invocaciones posteriores no producen ningún efecto.

public static function getCacheStats() : mixed

Retorna un array asociativo con estadísticas de acceso a la caché global utilizado por Doctrine

en todos los modelos, o null en caso de error.



AbstractModel

# $log : Log4PHPQueryLogger

# getBoolean() : boolean

Log4PHPQueryLogger

# $count : integer

+ __construct(\Logger $parent, AbstractPlatform $dbPlatform)

MySQLiWrapper

+ $counter : integer

+ query(...) : mixed

EntityManager

<<Interfaz>>

SQLLogger

+ startQuery(string $sql[, mixed[] $params[, mixed[] $types]) : void

# $affected_rows : integer# $em : \Doctrine\ORM\EntityManager

# $instance : AbstractModel

ArrayCache

# $hits : integer

# updateStats(string $id) : void

ArrayCache

- $data : mixed[]

# doFetch(...) : mixed

\mysqli

...

+ query(string $query [, int $resultmode]) : mixed

# $cache : \Doctrine\Common\Cache\Cache# $initialized : boolean

+ __construct() : void

+ getCacheStats() : int[]+ getConnection() : MySQLiWrapper

# select(...) : \mysqli_result# selectjoin(...) : \mysqli_result# initializeDoctrine() : void

+ $counter_static : integer

+ __construct(string $host, string $user, string $pass) : void

+ $affected_rows : integer

+ __construct(...) : void

+ select_db(string $name) : boolean...

+ stopQuery() : void

# $misses : integer

# doFetch(string $id) : mixed

# doGetStats() : integer[]# doContains(string $id) : boolean

# $log : \Logger# $dbPlatform : string

+ stopQuery() : void

+ startQuery(string $sql[, mixed[] $params[, mixed[] $types]]) : void

# doFlush() : boolean

# doContains(...): boolean# doSave(...) : boolean# doDelete(..) : boolean

# doGetStats() : null

Figura 5.12: Diagrama UML de las clases AbstractModel, Log4PHPQueryLogger y MySQLiWrapper



View

Clase base que representa el concepto genérico de vista. Es utilizada como padre de aquellas que

implementan métodos concretos de representación de datos (como la representación a partir de

plantillas o generadores PDF). Se trata de una clase de interfaz que no implementa ninguna

funcionalidad específica.


5.4.3.12.1 Métodos


Template

Implementación de vistas construidas a partir de plantillas de texto que soporta el acceso y la

modificación a las variables a remplazar en la plantilla utilizando la sintaxis de arrays.


protected $bindings : string[]

Array asociativo con los valores a remplazar.

protected $t : \Twig_TemplateInterface

Referencia a la plantilla Twig utilizada internamente.

Métodos

public function __construct(string $path, [callable[] $filters, callable[] $functions, callable[]

$extensions) : void

Crea una nueva instancia de plantilla a partir de su ruta absoluta o relativa en el sistema de

archivos, o a partir de su ruta dentro de un espacio de nombres de plantilla definido (por

ejemplo, indicando @html/admin/stats como ruta). Se reconocen los siguientes espacios de

nombres:

@html: Para una ruta tipo @html/path_plantilla, se cargará el archivo

twig_templates/html/path_plantilla.html.tpl

@css: Para una ruta tipo @css/path_plantilla, se cargará el archivo

twig_templates/css/path_plantilla.tpl.css

@email: Para una ruta tipo @email/path_plantilla, se cargará el archivo

twig_templates/email/path_plantilla.txt.tpl

@pdf: Para una ruta tipo @pdf/path_plantilla, se cargará el archivo

twig_templates/pdf/path_plantilla.html.tpl

@testing: Para una ruta tipo @testing/path_plantilla, se cargará el archivo

twig_templates/testing/path_plantilla.tpl



public function __toString() : string

Procesa la plantilla actual, generando un string a partir de su contenido y de los valores

proporcionados hasta el momento, o null si se produce un error.

public function offsetExists(mixed $offset) : boolean

Comprueba si se ha definido una variable de plantilla.

public function offsetGet(mixed $offset) : mixed

Retorna el valor asociado a una variable de plantilla o null si la variable solicitada no esté

definida

public function offsetSet(mixed $offset, mixed $value) : void

Establece el valor de una variable de plantilla.

public function offsetUnset(mixed $offset) : void

Retorna el valor asociado a una variable de plantilla.

PDFView

Clase base que representa el concepto genérico de “vista PDF”. Es utilizada como padre de aquellas

que implementan métodos concretos de generación de archivos PDF. Se trata de una clase de interfaz

que no implementa ninguna funcionalidad específica.


5.4.3.14.1 Métodos

abstract public function generar() : \cEzPDF

Retorna una instancia de un objeto que representa el archivo PDF generado.

Este método es abstracto, su propósito es forzar su redefinición en las clases hijas.

PDFResponse

Clase base que encapsula los datos necesarios para la generación de archivos PDF a partir de plantillas.


public $template : \CMMSE\Core\Template

Referencia a la plantilla a utilizar para generar el PDF.

public $filename : string

Nombre del archivo a enviar al cliente.

public $error_code : integer

Código de error producido al generar la respuesta, o cero si no ha habido errores.



5.4.3.15.2 Métodos

public function __construct(\CMMSE\Core\Template $template, string $filename, [integer

$error_code]) : void

Crea una nueva instancia que representa los datos de un archivo PDF a partir de una plantilla.

El archivo se enviará utilizando el nombre de archivo indicado. En caso de error, se retornará

el código del mismo en el parámetro pasado por referencia $error_code.

View

PDFResponse

+ $error_code : integer

+ __construct(\CMMSE\Core\Template $template, string $filename, [integer $error_code]) : void

Template

# $t : \Twig_TemplateInterface

+ __construct(string $path[, callable[] $filters [, callable[] $functions [, callable[] $extensions ]]]) : void

PDFView

+ generar() : \Cezpdf

# $bindings : string[]

+ offsetUnset(string $offset) : void

+ __toString() : string

+ offsetSet(string $offset, mixed $value) : void

+ offsetExists(string $offset) : boolean+ offsetGet(string $offset) : mixed

<<Interfaz>>

ArrayAccess

+ offsetExists(mixed $offset) : boolean

+ offsetUnset(mixed $offset) : void

+ offsetGet(mixed $offset) : mixed+ offsetSet(mixed $offset, mixed $value) : void

+ $template : \CMMSE\Core\Template+ $filename : string

EtiquetasBlancoVertical EtiquetasTodosVertical

….

<<Usa>>

Index.php

Figura 5.13: Diagrama UML de las clases usadas para implementar las vistas



Controller

Implementación del controlador base.



protected $log : \Logger

Referencia a la instancia del logger log4php utilizado por la instancia actual.

protected $parent : \CMMSE\Core\Controller

Referencia al controlador que ha instanciado al controlador actual, o null si se ha instanciado

directamente.

protected $modelFactory : \CMMSE\Interfaces\ModelFactory

Referencia a una instancia de la implementación de la factoría proveedora de instancias de

modelos utilizada por el controlador actual.

protected $handler404 : callable

Función, método, function object o equivalente a llamar por el controlador actual en caso de

que la URI no pueda ser enrutada.

5.4.3.16.2 Métodos

public final function __construct([Controller &$parent]) : void

Crea una nueva instancia de un controlador. En caso de existir, se permite el paso de una

referencia al controlador que instancia al actual.

Este método no puede ser redefinido por las clases hijas.

public function set404Handler(callable $callback) : void

Establece la función, método o equivalente a ejecutar en caso de que una URI no pueda ser

“encaminada”, es decir, cuando el cliente solicita una página que no existe.

Como valor de $callback se podrá utilizar un nombre de función o método, o un function object

o equivalente.

public function call404Handler() : mixed

Llama a la función, método o equivalente definida para ejecutarse en caso de que una URI no

pueda ser “encaminada”. En caso de no haber sido definido, se llamará al controlador por

defecto, que consiste en retornar un código de error HTTP 404 y finalizar la solicitud actual.

Retorna el valor devuelto por el controlador de errores 404 definido.

protected function assertParameterCountIsValid(string $methodName, integer

$parameterCount, integer $parametersForwarded) : boolean

Comprueba que el número de parámetros proporcionados coincide con los necesarios para

invocar la acción indicada, registrando un error en el archivo de depuración en disco de no ser

así.



public function getModel(string $modelInterface) : \CMMSE\Interfaces\IModel

Obtiene una instancia de un modelo a partir del FQN de su interfaz.

Excepción: Si se solicita una instancia para una interfaz desconocida, se lanza una excepción

capturable de tipo \Exception.

public function chainRequest($class, string[] $args) : mixed

Encadena el remanente no procesado aún de la URI para ser procesado por un controlador

identificado por el FQN dado. Si los argumentos proporcionados no pueden ser encaminados

a través del controlador indicado, se invoca al controlador de errores 404 configurado. Si la

solicitud se ha podido encaminar, retorna los datos devueltos por la acción invocada; en otro

caso, el resultado devuelto por el controlador de errores definido.

FrontController

Implementación base de los controladores de primer nivel, encargados de la conversión inicial de la

URI solicitada por el cliente en una lista de parámetros y llamar a la acción oportuna para iniciar el

procesamiento de la misma20.


5.4.3.17.1 Métodos

public static function redirectIfURLIsIncorrect() : void

Comprueba que la URI solicitada tiene un formato correcto, enviando al cliente una redirección

HTTP con la URI correcta (y finalizando la ejecución de la solicitud actual) de no ser así.

Una URI se considera incorrecta desde el punto de vista del núcleo de la aplicación si no

termina en “.php” (solicitudes tipo /webcmmse/index.php) o con un backslash (tipo

/webcmmse/index.php/admin/). La URI a la que se redirige al cliente se forma a partir de la

original, concatenando un backslash al final de la misma.

Por ejemplo, /webcmmse/index.php se convierte en /webcmmse/index.php/;

/webcmmse/index.php/admin se convierte en /webcmmse/index.php/admin/. Esto se hace

así para que no haya URIs diferentes para una misma página, simplificando así el resto del

código encargado de “encaminar” las solicitudes.

public function dispatch_request() : mixed

Obtiene la URI solicitada por el cliente a partir de las variables de entorno del script actual y la

“encamina” a través de una instancia del controlador actual utilizando chainRequest().

Excepción: Si no se puede determinar la URI solicitada a partir de las variables de entorno, se

lanza una excepción capturable de tipo \Exception.

protected static function getRequestArgs () : string[]

Lee la URI solicitada y la convierte en un array de parámetros de solicitud. La URI se obtiene

en función de los datos puestos a disposición del script por el runtime de PHP (que dependerán

20 En desarrollo web este proceso es llamado normalmente despachar la solicitud.



del tipo de servidor y configuración, variando, por ejemplo, entre configuraciones FastCGI y la

SAPI de Apache). También se tendrá en cuenta posibles configuraciones con mod_rewrite.

Excepción: Si no se puede determinar la URI solicitada se lanza una excepción capturable de

tipo \Exception.

Controller

# $parent : Controller

# assertParameterCountIsValid(...) : boolean

Logger

<<Interfaz>>

ModelFactory

+ getModel(string $modelInterface) : \CMMSE\Interfaces\IModel

FrontController

+ redirectIfURLIsIncorrect() : void

# $log : \Logger

# handler404 : \CMMSE\Core\HTTP404DieHandler# $modelFactory : \CMMSE\Interfaces\ModelFactory

+ __construct([Controller $parent]) : void+ set404Handler(callable $callback) : void+ call404Handler() : mixed

# getModel(string $modelInterface) : \CMMSE\Interfaces\IModel

+ chainRequest(string $class, string[+ $args) : string

# getRequestArgs() : string[]+ dispatchRequest() : string

HTTP404DieHandler

+ __invoke() : void

Figura 5.14: Diagrama UML de las clases base de los controladores



5.4.4 \CMMSE\Exceptions

Este espacio de nombres contiene las excepciones propias de la aplicación.

GenericException

Clase usada para definir un tipo de excepción genérica de manera semántica sobre las excepciones

nativas del lenguaje. Carece de funcionalidad propia, y su propósito es distinguir las excepciones

generadas por la aplicación de aquellas generadas por el propio lenguaje y las librerías de terceros.

5.4.4.1.1 Métodos


ForbiddenException

Clase usada para indicar que una solicitud de página o acción no está permitida para las credenciales

asociadas a la sesión actual.

5.4.4.2.1 Métodos


UnauthenticatedException

Clase usada para indicar que una solicitud de página o acción no está permitida por realizarse desde

una sesión de un usuario sin autenticar.

5.4.4.3.1 Métodos


UnknownUserException

Clase usada para indicar que una solicitud de página o acción no está permitida por realizarse indicando

un usuario que no existe.

5.4.4.4.1 Métodos




WrongPasswordException

Clase usada para indicar que la contraseña proporcionada en una solicitud de página o acción es

incorrecta.

5.4.4.5.1 Métodos


Exception

GenericException

ForbiddenException

UnknownUserException

UnauthenticatedException

WrongPasswordException

Figura 5.15: Diagrama UML de los tipos de excepciones de la aplicación



5.4.5 \CMMSE\Traits

Espacio de nombres con la implementación de funcionalidades genéricas por medio de rasgos (traits)

que posibilitan la herencia horizontal de código compartido por varias clases.

ArrayAccessAccessors

Implementación genérica de los métodos de la interfaz de PHP ArrayAccess como alias de los métodos

tipo getPropiedad() y setPropiedad() de las entidades, permitiendo así acceder a dichos métodos

utilizando la sintaxis de acceso a arrays. Este tipo de acceso es utilizado desde las plantillas.

5.4.5.1.1 Métodos

public function offsetExists(string $offset) : boolean

Mapea los accesos isset($obj['clave']) como ($obj->getClave()!==null), es decir, asume que la

semántica asociada a que una clave exista equivale a que su nombre es válido para el objeto

actual y su valor no es nulo.

Excepción: Si se solicita una clave para la cual no existe un getter, se lanza una excepción


public function offsetSet(string $offset, mixed $value) : void

Mapea los accesos $obj['clave'] = $valor como $obj->setClave($valor), es decir, asume que la

semántica asociada al cambio de valor de una clave equivale a una llamada al setter

correspondiente.

Excepción: Si se solicita una clave para la cual no existe un setter, se lanza una excepción


public function offsetGet(string $offset) : mixed

Mapea los accesos de lectura a $obj['clave'] como $obj->getClave(), es decir, asume que la

semántica asociada a la lectura del valor de una clave equivale una llamada al getter

correspondiente.



public function offsetUnset(string $offset) : void

Mapea las expresiones del lenguaje tipo unset($obj['clave']) como $obj->setClave(null), es

decir, asume que la semántica asociada a la eliminación del valor de una clave equivale una

llamada al setter correspondiente con un valor nulo como parámetro.





MagicAccessors

Implementación genérica de los métodos mágicos de PHP para acceder a propiedades de objeto como

alias de métodos tipo getPropiedad() / setPropiedad() utilizada desde las entidades, permitiendo así

acceder a dichos métodos utilizando la sintaxis de acceso a propiedades de objeto. Este tipo de acceso

es utilizado desde los controladores.

Los métodos proporcionados aquí solo tienen efecto al acceder a propiedades no declaradas o no

visibles desde el contexto de llamada. En otro caso se aplican los mecanismos de acceso a propiedades

normales del lenguaje.

5.4.5.2.1 Métodos

public function __isset(string $offset) : boolean

Mapea los accesos isset($obj->propiedad) como ($obj->getPropiedad()!==null), es decir, asume

que la semántica asociada a que una propiedad exista equivale a que su nombre es válido para

el objeto actual y su valor no es nulo.



public function __set(string $offset, mixed $value) : void

Mapea los accesos $obj->clave = $valor como $obj->setClave($valor), es decir, asume que la

semántica asociada al cambio de valor de una propiedad equivale a una llamada al setter

correspondiente.



public function __get(string $offset) : mixed

Mapea los accesos de lectura a $obj->clave como $obj->getClave(), es decir, asume que la

semántica asociada a la lectura del valor de una propiedad equivale una llamada al getter

correspondiente.



public function __unset(string $offset) : void

Mapea las expresiones del lenguaje tipo unset($obj->clave) como $obj->setClave(null), es decir,

asume que la semántica asociada a la eliminación del valor de una propiedad equivale una

llamada al setter correspondiente con un valor nulo como parámetro.





ArrayAccessAccessors

+ offsetGet(string $offset) : mixed

+ offsetExists(string $offset) : boolean

+ offsetSet(string $offset, mixed $value) : void+ offsetUnset(string $offset) : void

MagicAccessors

+ __isset(string $offset) : boolean

+ __get(string $offset) : mixed+ __set(string $offset, mixed $value) : void+ __unset(string $offset) : void

\CMMSE\Doctrine

<<Usa>>

Figura 5.16: Diagrama UML de los traits de acceso a propiedades de objeto

EMailTemplateHelpers

Proporciona métodos para establecer el asunto de los correos electrónicos desde las plantillas a partir

de las cuales se genera su contenido. Para ello, la clase que implemente este trait debe instanciar las

plantillas de los correos como

new \CMMSE\Template('@namespace/ruta', [], ['subject' => __CLASS__.'::set_subject'] );

y en la plantilla debe establecerse el asunto con un tag tipo

{{ subject("CMMSE %d submit New paper of %s",email.year,email.author) }} Para obtener el asunto se deberá llamar a self::get_subject() después de haber llamado al método

__toString() de la plantilla o de realizar un cast de la misma a string, lo cual provoca que se procese su

código.



5.4.5.3.1 Atributos

protected static $last_email_subject : string

Asunto obtenido por la última llamada a set_subject() realizada desde la plantilla.

5.4.5.3.2 Métodos

public static function set_subject(string $va_args [, …]) : void

Establece el asunto, utilizando una sintaxis análoga a la función sprintf().

protected static function get_subject() : string

Retorna el último asunto establecido.

protected static function get_email_template(string $path[, $prefix] ) : \CMMSE\Core\Template

Obtiene una instancia de plantilla para el identificador y namespace indicados. Si no se indica,

por defecto se buscan las plantillas en el espacio de nombres @email.

Mailer

Implementación de métodos para el envío de correos electrónicos utilizando los parámetros SMTP

indicados en la configuración del sitio. La implementación actual envía los correos utilizando la librería

open source PHPMailer.

5.4.5.4.1 Métodos

public static function send_email2(\CMMSE\Doctrine\Settings $settings, \CMMSE\Core\Email

$mail [, string[] $attachmentData [, string[] $attachmentfileName]]) : boolean

Envía un correo electrónico. Retorna cierto si se ha enviado el correo electrónico

correctamente, falso en otro caso.

Parámetros:

\CMMSE\Doctrine\Setting $settings: Datos de configuración del sitio.

\CMMSE\Core\EMail $mail: Objeto que representa el mensaje a enviar.

string[] $attachmentData: Si se proporciona éste y el siguiente parámetro, datos de archivos adjuntos a enviar.

string[] $attachmentfileName: Si se proporciona éste y el parámetro anterior, nombres de archivo de los archivos adjuntos a enviar.

public static function send_email_multi_attachment (\CMMSE\Doctrine\Settings $settings,

\CMMSE\Core\Email $mail [, string[] $attachmentData [, string[]

$attachmentfileName]]) : boolean

Envía un correo electrónico.

Este método es un alias del método anterior.



public static function send_email_for_debug (\CMMSE\Doctrine\Settings $settings,

\CMMSE\Core\Email $mail, string $debugout) : boolean

Envía un correo electrónico guardando la salida de depuración de los mensajes intercambiados

entre la aplicación y el servidor SMTP. Retorna cierto si se ha enviado el correo electrónico


Parámetros:

\CMMSE\Doctrine\Setting $settings: Datos de configuración del sitio.

\CMMSE\Core\EMail $mail: Objeto que representa el correo electrónico a enviar.

string[] $attachmentData: Datos de archivos adjuntos a enviar.

string[] $attachmentfileName: Nombres de archivo de los archivos adjuntos.

string $debugout: Referencia a un string donde guardar los mensajes de depuración.

protected static function doSendMail(\CMMSE\Core\Email $mail, string[] $attachmentData,

string[] $attachmentfileName [, string $debug]) : boolean

Envía un correo electrónico guardando la salida de depuración de los mensajes intercambiados

entre la aplicación y el servidor SMTP. Retorna cierto si se ha enviado el correo electrónico


Parámetros:

\CMMSE\Core\EMail $mail: Objeto que representa el correo electrónico a enviar.

string[] $attachmentData: Datos de archivos adjuntos a enviar.

string[] $attachmentfileName: Nombres de archivo de los archivos.

string $debug: Referencia a un string donde guardar los mensajes de depuración.

Mailer

+ send_email2(...) : boolean

# doSendMail(...) : boolean

+ send_email_for_debug(...) : boolean+ send_email_multi_attachment(...) : boolean

EMailTemplateHelpers

# $last_email_subject : string

+ set_subject(string $va_args [, ...]) : void+ get_subject() : string+ get_email_template(string $path[, string $prefix]) : \CMMSE\Core\Template

\CMMSE\Controllers

<<Usa>>

Figura 5.17: Diagrama UML de los traits usados para generar y enviar los correos electrónicos



ExtensionGetter

Proporciona un método para obtener la extensión (tipo de archivo) a partir de un nombre de archivo,

path completo o URL.

5.4.5.5.1 Métodos

public function getExtension(string $filename) : string

Obtener la extensión de un archivo a partir de su nombre o ruta, en minúsculas.

Excepción: Si el nombre de archivo proporcionado es o equivale a una cadena vacía el

comportamiento de este método no está definido.

ExtensionGetter

+ getExtension(string $filename) : string

Facturas

Figura 5.18: Diagrama UML del trait para obtener la extensión a partir de un nombre de archivo

CopyConstructor

Implementación genérica de métodos para facilitar la creación de nuevas instancias de objetos a partir

de instancias de sus clases padre. Es utilizado para simplificar la implementación de decoradores de

solo lectura.

5.4.5.6.1 Métodos

protected function assertSharesParent(object $source) : void

Función auxiliar que lanza una excepción si el objeto a partir del cual se construye una instancia

no es de un tipo que sea ancestro de su tipo de objeto, es decir, si la clase del nuevo objeto no

es un descendiente del objeto original.

Excepción: Si el tipo de $source no es un ancestro de la clase actual.



protected function copyPropertiesFrom(object $source) : void

Copia el valor de las propiedades accesibles del objeto de origen a los atributos

correspondientes de la instancia actual. Las propiedades cuyos nombres empiecen por ‘__’ se

consideran especiales y no son copiadas21.

Excepción: Si el tipo de $source no es un ancestro de la clase actual.

CopyCtor

# copyPropertiesFrom(object $source) : void

\CMMSE\Decorators

# assertSharesParent(object $source) : void

<<Usa>>

Figura 5.19: Diagrama UML del trait de inicialización de objetos desde instancias compatibles

SystemLoadGetter

Implementación de un método para obtener valores de carga media del sistema, siempre que el

servidor sobre el que se ejecuta la aplicación lo permita.

5.4.5.7.1 Métodos

public static function getLoadString() : string

Obtener un string con los valores medios de carga UNIX de los últimos 1, 5 y 15 minutos

separados por comas. En sistemas que no soporten la función sys_getloadavg() (como

Windows) se retorna el string “N/A”.

21 En particular, el copiarlas causa problemas con las entidades de Doctrine (que utilizan la nomenclatura indicada para definir inicializadores).



UploadErrStrGetter

Implementación de un método para obtener mensajes descriptivos en ingles de los códigos de error

retornados por PHP en el envío de archivos desde el cliente al servidor.

5.4.5.8.1 Métodos

protected static function getUploadErrorString(integer $code) : string

Obtener la descripción en inglés del error de envío de archivos asociado al código de la familia

UPLOAD_ERR_* proporcionado, o Unknown error si el código de error proporcionado es

desconocido.

SystemLoadGetter

+ getLoadString() : string

UploadErrStrGetter

# getUploadErrorString(integer $code) : string

AdminController

...

...

Homepage

...

...

AbstractPaperController

...

...

Factura

...

...

<<Usa>>

<<Usa>>

Figura 5.20: Diagrama UML de los traits de obtención de carga media del sistema y descripción de errores de envío de archivos



5.4.6 \CMMSE\Doctrine

Este espacio de nombres contiene las clases utilizadas por el ORM (Doctrine) como interfaz a los datos

de la base de datos, proporcionando un modelo entidad-relación sobre las tablas relacionales. Para

cada clase y sus atributos se indica, además, las anotaciones utilizadas para definir la correspondencia

con las tablas y columnas del modelo relacional de la base de datos. Estas anotaciones están

precedidas del símbolo ‘@’, puede consultarse su documentación detallada en [DOC01].

El acceso a los atributos protegidos de las entidades se realiza utilizando métodos mágicos de acceso

utilizando la sintaxis de acceso a arrays y atributos heredados de los traits. Para ello, estas clases hacen

uso de los traits ArrayAccessAccessors y MagicAccessors.

Conference

Entidad que representa los datos de los simposios.

@Entity: Esta clase representa entidades de primer nivel del modelo E-R.

@Table(name=”conferencias”): Esta entidad representa los datos almacenados en la tabla

conferencias.

5.4.6.1.1 Atributos

protected $idconf : integer

Identificador del simposio en la base de datos.

@Id: Este atributo es una clave primaria de la tabla.

@GeneratedValue: El valor de este atributo es autogenerado por el SGBD.

@Column(type=”integer”, name=”idconf”, unique=true, nullable=false):

Este atributo se corresponde con la columna idconf de tipo entero.

Este atributo es único para todas las entidades.

Este atributo no puede tomar un valor nulo.

protected $title : string

Título del simposio.

@Column(type="string", name="title"): Este atributo se corresponde con la columna title de

tipo cadena.

protected $begin : \DateTime

Fecha y hora de inicio del simposio.

@Column(type="datetime", name="ts_begin"): Este atributo se corresponde con la

columna ts_begin de tipo fecha y hora.

5.4.6.1.2 Métodos

public function getId() : integer

Obtiene el identificador del simposio actual, o null si la entidad no se corresponde con datos

almacenados (aún) en la base de datos.



public function getIdConf() : integer

Obtiene el identificador del simposio actual.

Este método es un alias del anterior.

public function getTitle() : string

Obtiene el título del simposio actual.

public function getBegin() : \DateTime

Obtiene la fecha y hora de inicio del simposio actual, o null si la fecha y hora no han sido

establecidos.

public function setId(integer $id) : void

Establece el identificador del simposio actual.

public function setIdConf(integer $id) : void

Establece el identificador del simposio actual.


public function setTitle(string $title) : void

Establece el título del simposio actual.

public function setBegin([\DateTime $begin]) : void

Establece la fecha y hora de inicio del simposio actual. Si se omite el parámetro de la función,

borra la fecha y hora asociadas actualmente.



<<Interfaz>>

ArrayAccess

...

Conference

# $idconf : integer

+ getId() : integer

# $title : string# $begin : \DateTime

+ getIdConf() : integer+ getTitle() : string

+ setBegin([\DateTime $begin]) : void

+ getBegin() : \DateTime

+ setTitle(string $title) : void

+ setId(integer $id) : void+ setIdConf(integer $id) : void

ArrayAccess

...

MagicAccessors

...

Figura 5.21: Diagrama UML de la entidad Conference



InstrumentationSample

Entidad que representa una muestra de los datos de instrumentación recogidos por la aplicación para

una solicitud.


@Table(name=”instrumentation”): Esta entidad representa los datos almacenados en la tabla

instrumentation.

5.4.6.2.1 Atributos

protected $id: integer

Identificador de la muestra actual en la base de datos.



@Column(type=”integer”, name=”sample_id”, unique=true, nullable=false):

Este atributo se corresponde con la columna simple_id de tipo entero.



protected $session_id : integer

Identificador de la sesión que ha realizado la solicitud.

@Column(type="integer", name="sid"): Este atributo se corresponde con la columna sid de

tipo entero.

protected $user_id : integer

Identificador del usuario que ha realizado la solicitud.

@Column(type="integer", name="uid"): Este atributo se corresponde con la columna uid de

tipo entero.

protected $is_admin : boolean

Flag que indica si el usuario que ha realizado la solicitud es un administrador.

@Column(type="integer", name="is_admin"): Este atributo se corresponde con la columna

sid de tipo cadena.

protected $load1 : float

Carga media del sistema del último minuto en el momento en el que se realizó la solicitud.

@Column(type="float", name="load1"): Este atributo se corresponde con la columna load1

de tipo decimal.


Carga media del sistema de los últimos 5 minutos en el momento en el que se realizó la

solicitud.

@Column(type="float", name="load5"): Este atributo se corresponde con la columna load5

de tipo decimal.




Carga media del sistema de los últimos 15 minutos en el momento en el que se realizó la

solicitud.

@Column(type="float", name="load15"): Este atributo se corresponde con la columna

load15 de tipo decimal.

protected $mem_peak : integer

Cantidad máxima de memoria usada por el intérprete PHP para procesar la solicitud.

@Column(type="integer", name="max_mem_usage"): Este atributo se corresponde con la

columna max_mem_usage de tipo entero.

protected $num_queries_doctrine : integer

Número de consultas SQL realizadas a la base de datos a través de Doctrine durante la

solicitud.

@Column(type="integer", name="num_queries_doctrine"): Este atributo se corresponde

con la columna num_queries_doctrine de tipo entero.

protected $num_queries_mysqli : integer

Número de consultas SQL realizadas a la base de datos a través de MySQLi durante la

solicitud.

@Column(type="integer", name="num_queries_mysqli"): Este atributo se corresponde con

la columna num_queries_mysqli de tipo entero.

protected $remote_addr : string

IP del cliente o proxy que realizó la solicitud.

@Column(type="string", name="remote_addr"): Este atributo se corresponde con la

columna remote_addr de tipo cadena.

protected $forwarded_for : string

IP del cliente real que realizó la solicitud, en caso de haberla realizado a través de un proxy.

@Column(type="text", name="forwarded_for"): Este atributo se corresponde con la

columna forwarded_for de tipo cadena sin longitud máxima.

protected $request_method : string

Método HTTP utilizado por el cliente para realizar la solicitud.

@Column(type="string", name="request_method"): Este atributo se corresponde con la

columna request_method de tipo cadena.

protected $uri : string

URI solicitada por el cliente.

@Column(type="string", name="uri "): Este atributo se corresponde con la columna uri de

tipo cadena.

protected $host : string

Nombre de host utilizado por el cliente para referirse al servidor que atendió la solicitud.

@Column(type="string", name="host "): Este atributo se corresponde con la columna host

de tipo cadena.



protected $user_agent: string

Identificador del navegador utilizado por el cliente, si se ha proporcionado.

@Column(type="text", name="user_agent "): Este atributo se corresponde con la columna

user_agent de tipo cadena sin longitud máxima.

protected $ts_begin : \DateTime

Fecha y hora del instante en el que se inició el procesamiento de la solicitud del cliente.



protected $ts_saved : \DateTime

Fecha y hora del instante en el que se guardaron los datos de instrumentación de la solicitud

actual.

@Column(type="datetime", name="ts_saved"): Este atributo se corresponde con la

columna ts_saved de tipo fecha y hora.

protected $micro_ts_begin : float

Timestamp del instante en el que se inició el procesamiento de la solicitud del cliente, con

precisión de microsegundos.

@Column(type="decimal", name="micro_ts_begin"): Este atributo se corresponde con la

columna micro_ts_begin de tipo decimal.

protected $micro_ts_saved : float

Timestamp del instante en el que se guardaron los datos de instrumentación de la solicitud

del cliente, con precisión de microsegundos.

@Column(type="decimal", name="micro_ts_saved"): Este atributo se corresponde con la

columna micro_ts_saved de tipo dcimal.

protected $sysname : string

Nombre del sistema (“Linux”, “Windows”) instalado en el servidor que atendió la solicitud.

@Column(type="string", name="sysname"): Este atributo se corresponde con la columna

sysname de tipo cadena.

protected $nodename : string

Nombre del nodo (nombre del host o hostname) que atendió la solicitud actual.

@Column(type="string", name="nodename"): Este atributo se corresponde con la columna

nodename de tipo cadena.

protected $release : string

Versión del sistema operativo instalado en el servidor que atendió la solicitud actual.

@Column(type="string", name="release"): Este atributo se corresponde con la columna

release de tipo cadena.

protected $version : string

Tag de compilación del sistema operativo instalado en el servidor que atendió la solicitud

actual.

@Column(type="string", name="version"): Este atributo se corresponde con la columna

release de tipo cadena.



5.4.6.2.2 Métodos


Obtiene el identificador de la muestra actual, o null si la entidad no se corresponde con datos


public function getSession_id() : integer

Obtiene el identificador de la sesión asociada a la muestra actual, o null si no había ninguna

asociada.

public function getUser_id() : integer

Obtiene el identificador del usuario asociado a la muestra actual, o null si no había ninguno

asociado.

public function getIs_admin() : boolean

Obtiene el flag que indica si el usuario asociado a la muestra actual es un administrador.

public function getNum_queries_doctrine() : integer

Obtiene el número de consultas a la base de datos realizadas a través de Doctrine durante la

solicitud asociada a la muestra actual.

public function getNum_queries_mysqli() : integer

Obtiene el número de consultas a la base de datos realizadas a través de MySQLi durante la


public function getLoad1 () : float

Obtiene la carga media del sistema registrada para el último minuto durante la solicitud

asociada a la muestra actual.

public function getLoad5() : float

Obtiene la carga media del sistema registrada para los últimos 5 minutos durante la solicitud


public function getLoad15 () : float

Obtiene la carga media del sistema registrada para los últimos 15 minutos durante la solicitud


public function getMemPeak () : integer

Obtiene la cantidad máxima de memoria utilizada por el intérprete de PHP para procesar la


public function getRemote_addr () : string

Obtiene la IP del cliente o proxy que realizó la solicitud asociada a la muestra actual.

public function getForwarded_for() : string

Obtiene la IP del cliente real que realizó la solicitud asociada a la muestra actual, en caso de

haberla realizado a través de un proxy.



public function getRequest_method() : string

Obtiene el método HTTP utilizado por el cliente para realizar la solicitud asociada a la muestra

actual.

public function getUri() : string

Obtiene la URI solicitada por el cliente.

public function getHost() : string

Obtiene el nombre de host utilizado por el cliente para referirse al servidor que atendió la


public function getUserAgent() : string

Obtiene el Identificador del navegador utilizado por el cliente durante la solicitud asociada a

la muestra actual, si se ha proporcionado, o null.

public function geTs_begin() : \DateTime

Obtiene la fecha y hora del instante en el que se inició el procesamiento de la solicitud asociada

a la muestra actual.

public function geTs_saved() : \DateTime

Obtiene la fecha y hora del instante en el que se guardaron los datos de instrumentación para

la solicitud asociada a la muestra actual.

public function gMicroTs_begin() : \DateTime

Obtiene el timestamp del instante en el que se inició el procesamiento de la solicitud asociada

a la muestra actual, con precisión de microsegundos.

public function getMicroTs_saved() : \DateTime

Obtiene el timestamp del instante en el que se guardaron los datos de instrumentación para

la solicitud asociada a la muestra actual, con precisión de microsegundos.

public function getSysname() : string

Obtiene el nombre del sistema (“Linux”, “Windows”) instalado en el servidor que atendió la


public function getNodename() : string

Obtiene el nombre del nodo (nombre del host o hostname) del servidor que atendió la solicitud


public function getRelease() : string

Obtiene la versión del sistema operativo instalado en el servidor que atendió la solicitud


public function getVersion() : string

Obtiene el tag de compilación del sistema operativo instalado en el servidor que atendió la



Establece el identificador de la muestra actual.



public function setSession_id(integer $session_id) : void

Establece el identificador de la sesión asociada a la muestra actual.

public function setUser_id(integer $user_id) : void

Establece el identificador del usuario asociado a la muestra actual.

public function setIs_admin(boolean $is_admin) : void

Establece el flag que indica si el usuario asociado a la muestra actual es un administrador.

public function setNum_queries_doctrine(integer $num_queries) : void

Establece el número de consultas a la base de datos realizadas a través de Doctrine durante la

solicitud asociada a la muestra actual

public function setNum_queries_mysqli(integer $num_queries) : void

Establece el número de consultas a la base de datos realizadas a través de MySQLi durante la

solicitud asociada a la muestra actual

public function setLoad1(float $load) : void

Establece la carga media del sistema registrada para el último minuto durante la solicitud



Establece la carga media del sistema registrada para los últimos 5 minutos durante la solicitud



Establece la carga media del sistema registrada para los últimos 15 minutos durante la solicitud


public function setMemPeak(integer $mem_peak) : void

Establece la cantidad máxima de memoria registrada durante la solicitud asociada a la muestra

actual.

public function setRemote_addr(string $remote_addr) : void

Establece la IP del cliente o proxy que realizó la solicitud asociada a la muestra actual.

public function setForwarded_for(string $forwarded_for) : void

Establece la IP del cliente real que realizó la solicitud asociada a la muestra actual, en caso de

haberla realizado a través de un proxy.

public function setRequest_method(string $request_method) : void

Establece el método HTTP utilizado por el cliente para realizar la solicitud asociada a la muestra

actual

public function setUri (string $uri) : void

Establece la URI solicitada por el cliente.

public function setHost(string $host) : void

Establece el nombre de host utilizado por el cliente para referirse al servidor que atendió la




public function setUserAgent(string $user_agent) : void

Establece el identificador del navegador utilizado por el cliente durante la solicitud asociada a

la muestra actual.

public function setTs_begin(\DateTime $ts_begin) : void

Establece la fecha y hora del instante impreciso en el que se inició el procesamiento de la

solicitud asociada a la muestra actual, a partir de un objeto que representa la fecha y hora.

public function setTs_saved(\DateTime $ts_saved) : void

Establece la fecha y hora del instante impreciso en el que se guardaron los datos de

instrumentación para la solicitud asociada a la muestra actual, a partir de un objeto que

representa la fecha y hora.

public function setMicroTs_begin(float $ts_begin) : void

Establece la fecha y hora del instante preciso en el que se inició el procesamiento de la solicitud

asociada a la muestra actual, a partir de un número en coma flotante que representa un

timestamp con precisión de microsegundos.

public function setMicroTs_saved(float $ts_saved) : void

Establece la fecha y hora del instante en el que se guardaron los datos de instrumentación para

la solicitud asociada a la muestra actual, a partir de un número en coma flotante que

representa un timestamp con precisión de microsegundos.

public function setSysname(string $sysname) : string

Establece el nombre del sistema (“Linux”, “Windows”) instalado en el servidor que atendió la


public function setNodename(string $nodename) : void

Establece el nombre del nodo (nombre del host o hostname) del servidor que atendió la


public function setRelease(string $release) : string

Establece la versión del sistema operativo instalado en el servidor que atendió la solicitud


public function setVersion(string $version) : string

Establece el tag de compilación del sistema operativo instalado en el servidor que atendió la




<<Interfaz>>

ArrayAccess

...

InstrumentationSample

# $id : integer# $user_id : integer

+ getId() : integer

+ setUserID(integer $id) : void+ setId(integer $id) : void

ArrayAccess

...

MagicAccessors

...

+ getUserID() : integer

# $remote_addr : string

+ getRemote_addr() : string

...

...

# $uri : string...

+ getURI() : string

+ setRemote_addr(string $addr) : void+ setURI(string $uri) : void

Figura 5.22: Diagrama UML de la entidad InstrumentationSample



MailerSettings

Entidad que representa los datos de configuración para el envío de correos.


@Table(name=”mailer_settings”): Esta entidad representa los datos almacenados en la tabla

mailer_settings.

5.4.6.3.1 Atributos


Identificador de la fila de la base de datos que almacena los datos de configuración. En la

implementación actual el valor de este atributo siempre es uno.



@Column(type=”integer”, name=”server_id”, unique=true, nullable=false):

Este atributo se corresponde con la columna server_id de tipo entero.



protected $host : string

Nombre de host del servidor de correo SMTP a utilizar.

@Column(type="string", name="host"): Este atributo se corresponde con la columna host

de tipo cadena.

protected $port : integer

Puerto a usar para conectar con el servidor SMTP a utilizar.

@Column(type="integer", name="port"): Este atributo se corresponde con la columna port

de tipo entero.

protected $user : string

Nombre de usuario a usar para conectar con el servidor SMTP a utilizar.

@Column(type="string", name="user"): Este atributo se corresponde con la columna user

de tipo cadena.

protected $pass : string

Contraseña a usar para conectar con el servidor SMTP a utilizar.

@Column(type="string", name="pass"): Este atributo se corresponde con la columna pass

de tipo cadena.

protected $from_addr : string

Dirección de correo electrónico de origen de los correos enviados.

@Column(type="string", name="from_addr"): Este atributo se corresponde con la columna

pass de tipo cadena.



protected $from_name : string

Nombre de origen a usar en los correos enviados.

@Column(type="string", name="from_name"): Este atributo se corresponde con la columna

from_name de tipo cadena.

protected $encryption: string

Tipo de encriptación a utilizar en la conexión con el servidor SMTP. Los tipos válidos son “”

(una cadena vacía, para no usar encriptación), “tls” y “ssl”.

@Column(type="string", name="encryption"): Este atributo se corresponde con la columna

encryption de tipo cadena.

protected $smtp_auth: boolean

Determina si utilizar o no autentificación SMTP en la conexión con el servidor SMTP.

@Column(type="boolean", name="smtp_auth"): Este atributo se corresponde con la

columna smtp_auth de tipo booleano.

protected $enabled: boolean

Determina si el envío de correos está habilitado.

@Column(type="boolean", name="enabled"): Este atributo se corresponde con la columna

enabled de tipo booleano.

5.4.6.3.2 Métodos


Obtiene el identificador de la fila de la base de datos que almacena los datos de configuración

de correo.

public function getHost() : string

Obtiene el nombre de host del servidor de correo SMTP a utilizar.

public function getPort() : integer

Obtiene el puerto del servidor de correo SMTP a utilizar.

public function getUser() : string

Obtiene el nombre de usuario utilizado para conectar con el servidor de correo SMTP a utilizar.

public function getPass() : string

Obtiene la contraseña utilizada para conectar con el servidor de correo SMTP a utilizar.

public function getFromAddr() : string

Obtiene la dirección de correo electrónico de origen a utilizar como remitente de los correos

enviados.

public function getFromName() : string

Obtiene el nombre de origen a utilizar como remitente de los correos enviados.

public function getEncryption() : string

Obtiene el tipo de encriptación a utilizar en la conexión con el servidor SMTP. Los tipos válidos

son “” (una cadena vacía, para no usar encriptación), “tls” y “ssl”.



public function getSMTPAuth() : boolean

Obtiene el flag booleano que indica si el servidor SMTP requiere autentificación.

public function getEnabled() : boolean

Obtiene el flag booleano que indica si está habilitado el envío de correos.


Establece el identificador de la fila de la base de datos que almacena los datos de configuración

de correo.

public function setHost(string $host) : void

Establece el nombre de host del servidor de correo SMTP a utilizar.

public function setPort(integer $port) : void

Establece el puerto del servidor de correo SMTP a utilizar.

public function setUser(string $user) : void

Establece el nombre de usuario utilizado para conectar con el servidor de correo SMTP a

utilizar.

public function setPass(string $pass) : void

Establece la contraseña utilizada para conectar con el servidor de correo SMTP a utilizar.

public function setFromAddr(string $from_addr) : void

Establece la dirección de correo electrónico de origen a utilizar como remitente de los correos

enviados.

public function setFromName(string $from_name) : void

Establece el nombre de origen a utilizar como remitente de los correos enviados.

public function setEncryption(string $encryption) : void

Establece el tipo de encriptación a utilizar en la conexión con el servidor SMTP. Los tipos válidos

son “” (una cadena vacía, para no usar encriptación), “tls” y “ssl”.

public function setSMTPAuth(boolean $smtp_auth) : void

Establece el flag booleano que indica si el servidor SMTP requiere autentificación.

public function setEnabled(boolean $enabled) : void

Establece el flag booleano que indica si está habilitado el envío de correos.



<<Interfaz>>

ArrayAccess

...

MailerSettings

# $sid : integer# $host : string

+ getId() : integer

+ setHost(string $year) : void+ setId(integer $id) : void

ArrayAccess

...

MagicAccessors

...

+ getHost() : string

+ setPort(integer $port) : void

# $port : integer...

+ getPort() : integer

...

...

Figura 5.23: Diagrama UML de la entidad MailerSettings



Paper

Entidad que representa los datos de los papers enviados.


@Table(name=”papers”): Esta entidad representa los datos almacenados en la tabla papers.

5.4.6.4.1 Atributos

protected $id : integer

Identificador del paper en la base de datos.



@Column(type=”integer”, name=”idpaper”, unique=true, nullable=false):

Este atributo se corresponde con la columna idpaper de tipo entero.



protected $user_id : integer

Identificador del usuario que ha enviado el paper.

@Column(type="integer", name="iduser "): Este atributo se corresponde con la columna

iduser de tipo entero.

protected $conference : \CMMSE\Doctrine\Conference

Referencia a la conferencia asociada al paper.

@OneToOne(targetEntity=”CMMSE\Doctrine\Conference”): Este atributo referencia una

entidad de \CMMSE\Doctrine\Conference.

@JoinColumn(name=”idconf”, referencedColumnName=”idconf”):

Este atributo se corresponde con la columna idconf.

Este atributo coincide con el valor de la columna idconf de la tabla asociada a la

entidad referenciada.

protected $filename : string

Nombre de primer archivo enviado asociado al paper.

@Column(type="string", name="filename"): Este atributo se corresponde con la columna

filename de tipo cadena.

protected $newfilename : string

Nombre de último archivo enviado asociado al paper.

@Column(type="string", name="newfilename"): Este atributo se corresponde con la

columna newfilename de tipo cadena.


Título del paper.


tipo cadena.



protected $date : string

Fecha de envío del paper como una cadena de texto formateada.

@Column(type="string", name="date"): Este atributo se corresponde con la columna date

de tipo cadena.

protected $poster : boolean

Flag que indica si el paper es un poster.

@Column(type="boolean", name="poster"): Este atributo se corresponde con la columna

poster de tipo booleano.

protected $author1 : string

Nombre del primer autor asignado al paper.

@Column(type="string", name="author1"): Este atributo se corresponde con la columna

author1 de tipo cadena.


Nombre del segundo autor asignado al paper.




Nombre del tercer autor asignado al paper.




Nombre del cuarto autor asignado al paper, o null si no se ha indicado.




Nombre del quinto autor asignado al paper, o null si no se ha indicado.




Nombre del sexto autor asignado al paper. o null si no se ha indicado.




Nombre del séptimo autor asignado al paper, o null si no se ha indicado.




Nombre del octavo autor asignado al paper, o null si no se ha indicado.






Nombre del noveno autor asignado al paper, o null si no se ha indicado.



protected $decision : boolean

Flag que indica si el paper ha entrado en proceso de revisión.

@Column(type="boolean", name="decision"): Este atributo se corresponde con la columna

decision de tipo cadena.

protected $aceptado : boolean

Flag que indica si el paper ha sido marcado como aceptado.

@Column(type="boolean", name="aceptado"): Este atributo se corresponde con la

columna aceptado de tipo cadena.

protected $created : \DataTime

Fecha y hora de creación de los datos del paper en la base de datos.

@Column(type="datetime", name="created"): Este atributo se corresponde con la columna

created de tipo fecha y hora.

5.4.6.4.2 Métodos


Obtiene el identificador del paper actual.

public function getUserId() : integer

Obtiene el identificador del usuario que envió el paper actual.

public function getConferenceId() : integer

Obtiene el identificador del simposio asociado el paper actual.

public function getConference() : \CMMSE\Doctrine\Conference

Obtiene una instancia del simposio asociado al paper actual.

public function getFilename() : string

Obtiene el nombre de primer archivo enviado asociado al paper actual.

public function getNewFilename() : string

Obtiene el nombre de último archivo enviado asociado al paper actual.

public function getTitile () : string

Obtiene el título del paper actual.

public function getDate() : string

Obtiene la fecha y hora de envío del paper actual como una cadena de texto.

public function getPoster() : boolean

Obtiene un flag que indica si el paper actual es de tipo poster.



public function getAuthor1() : string

Obtiene el nombre del primer autor asignado al paper actual.


Obtiene el nombre del segundo autor asignado al paper actual.


Obtiene el nombre del tercer autor asignado al paper actual.


Obtiene el nombre del cuarto autor asignado al paper actual.


Obtiene el nombre del quinto autor asignado al paper actual.


Obtiene el nombre del sexto autor asignado al paper actual.


Obtiene el nombre del séptimo autor asignado al paper actual.


Obtiene el nombre del octavo autor asignado al paper actual.


Obtiene el nombre del noveno autor asignado al paper actual.

public function getDecision() : boolean

Obtiene el flag que indica si el paper actual ha entrado en proceso de revisión.

public function getAceptado() : boolean

Obtiene el flag que indica si el paper actual ha sido marcado como aceptado.

public function getCreated() : \DateTime

Obtiene un objeto que representa la fecha y hora de creación de los datos del paper en la base

de datos.


Establece el identificador del paper actual.

public function setUserId(integer $id) : void

Establece el identificador del usuario que envió el paper actual.

public function setConference(\CMMSE\Doctrine\Conference $conf) : void

Establece el simposio al que está asociado el paper actual.

public function setFilename(string $filename) : void

Establece el nombre de primer archivo enviado asociado al paper actual.

public function setNewFilename(string $newfilename) : void

Establece el nombre de último archivo enviado asociado al paper actual.




Establece el título del paper actual.

public function setDate(string $title) : void

Establece la fecha y hora de envío (como una cadena) del paper actual.

public function setPoster(boolean $poster) : void

Establece el flag que indica si el paper actual es de tipo poster.

public function setAuthor1(string $author) : void

Establece el nombre del primer autor asignado al paper actual.


Establece el nombre del segundo autor asignado al paper actual.


Establece el nombre del tercer autor asignado al paper actual.


Establece el nombre del cuarto autor asignado al paper actual.


Establece el nombre del quinto autor asignado al paper actual.


Establece el nombre del sexto autor asignado al paper actual.


Establece el nombre del séptimo autor asignado al paper actual.


Establece el nombre del octavo autor asignado al paper actual.


Establece el nombre del noveno autor asignado al paper actual.

public function setDecision(boolean $decision) : boolean

Establece el flag que indica si el paper actual ha entrado en proceso de revisión.

public function setAceptado(boolean $aceptado) : boolean

Establece el flag que indica si el paper actual ha sido marcado como aceptado.

public function setCreated(\DateTime $created) : \DateTime

Establece la fecha y hora de creación de los datos del paper en la base de datos.



<<Interfaz>>

ArrayAccess

...

Paper

# $id : integer# $user_id : integer

+ getId() : integer

+ setUserID(integer $id) : void+ setId(integer $id) : void

ArrayAccess

...

MagicAccessors

...

+ getUserID() : integer

# $conference : Conference

+ getConference() : Conference

...

...

# $title : string...

+ getTitle() : sring

+ setConference(Conference $c) : void+ setTitle(string $title) : void

Figura 5.24: Diagrama UML de la entidad Paper



PaymentSettings

Entidad que representa los datos de configuración de pagos.


@Table(name=”payment_settings”): Esta entidad representa los datos almacenados en la

tabla payment_settings.

5.4.6.5.1 Atributos


Identificador de la fila de la base de datos que almacena los datos de configuración de pagos.

En la implementación actual el valor de este atributo siempre es uno.



@Column(type=”integer”, name=”row_id”, unique=true, nullable=false):

Este atributo se corresponde con la columna title_id de tipo entero.



protected $spain_invoice_next_seq_id : integer

Siguiente número de factura libre para las facturas de España.

@Column(type=" integer ", name="spain_invoice_next_seq_id"): Este atributo se

corresponde con la columna spain_invoice_next_seq_id de tipo entero.

protected $out_invoice_next_seq_id : integer

Siguiente número de factura libre para las facturas de fuera España.

@Column(type=" integer ", name="out_invoice_next_seq_id"): Este atributo se

corresponde con la columna out_invoice_next_seq_id de tipo entero.

protected $red_invoice_next_seq_id : integer

Siguiente número de factura libre para las facturas de la Red.

@Column(type=" integer ", name="red_invoice_next_seq_id"): Este atributo se

corresponde con la columna red_invoice_next_seq_id de tipo entero.

protected $fees : integer

Cuota de inscripción a pagar.

@Column(type="integer", name="fees"): Este atributo se corresponde con la columna fees

de tipo entero.

protected $red_fees : integer

Cuota de inscripción a pagar.

@Column(type="integer", name="red_fees"): Este atributo se corresponde con la columna

red_fees de tipo entero.



5.4.6.5.2 Métodos


Obtiene el identificador de la fila de la base de datos que almacena los datos de configuración

de pagos.

public function getSpain_invoice_next_seq_id() : integer

Obtiene el siguiente número de secuencia para las facturas de España.

public function getOut_invoice_next_seq_id() : integer

Obtiene el siguiente número de factura para las facturas de fuera de España.

public function getRed_invoice_next_seq_id() : integer

Obtiene el siguiente número de factura para las facturas de la Red.

public function getFees() : integer

Obtiene la cantidad a pagar, en euros, como cuota de inscripción por defecto.

public function getRed_fees() : integer

Obtiene la cantidad a pagar, en euros, como cuota de inscripción por defecto para los usuarios

pertenecientes a la Red.


Establece el identificador de la fila de la base de datos que almacena los datos de configuración

de pagos.

public function setSpain_invoice_next_seq_id(integer $id) : void

Establece el siguiente número de secuencia para las facturas de España.

public function setOut_invoice_next_seq_id(integer $id) : void

Establece el siguiente número de factura para las facturas de fuera de España.

public function setRed_invoice_next_seq_id(integer $id) : void

Establece el siguiente número de factura para las facturas de la Red.

public function setFees(integer $id) : void

Establece la cantidad a pagar, en euros, como cuota de inscripción por defecto.

public function setRed_fees(integer $id) : void

Establece la cantidad a pagar, en euros, como cuota de inscripción por defecto para los

usuarios pertenecientes a la Red.



<<Interfaz>>

ArrayAccess

...

PaymentSettings

# $sid : integer

+ getId() : integer

# $spain_invoice_next_seq_id : integer

+ getOut_invoice_next_seq_id() : integer

+ setOut_invoice_next_seq_id(integer $year) : void+ setSpain_invoice_next_seq_id(integer $id) : void

ArrayAccess

...

MagicAccessors

...

+ getRed_invoice_next_seq_id() : integer

+ setRed_invoice_next_seq_id(integer $id) : void

# $out_invoice_next_seq_id : integer

# $red_fees : integer

+ getFees() : integer+ getRed_fees() : integer

# $fees : integer# $red_invoice_next_seq_id : integer

+ setId(integer $id) : void

+ setFees(integer $fees) : void+ setRed_fees(integer $fees) : void

+ getSpain_invoice_next_seq_id() : integer

Figura 5.25: Diagrama UML de la entidad PaymentSettings



PersonTitle

Entidad que representa los datos de los posibles títulos asignados a los ponentes, como Señor, Señora

o Doctor.


@Table(name=”person_titles”): Esta entidad representa los datos almacenados en la tabla

person_titles.

5.4.6.6.1 Atributos


Identificador del título en la base de datos.



@Column(type=”integer”, name=”title_id”, unique=true, nullable=false):

Este atributo se corresponde con la columna title_id de tipo entero.



protected $title_key : string

Clave del título (utilizada en los formularios).

@Column(type="string", name="title_key"): Este atributo se corresponde con la columna

title_key de tipo cadena.


Nombre del título.


tipo cadena.

5.4.6.6.2 Métodos


Obtiene el identificador del título actual.

public function getTitleKey() : string

Obtiene la clave del título actual utilizada en los formularios.


Obtiene el nombre del título actual.


Establece el identificador del título actual.

public function setTitleKey (string $name) : void

Establece la clave del título actual utilizada en los formularios.


Establece el nombre del título actual.



<<Interfaz>>

ArrayAccess

...

PersonTitle

# $id : integer

+ getId() : integer

# $title_key : string

+ getTitleKey() : string

+ setTitleKey(string $title_key) : void+ setId(integer $id) : void

ArrayAccess

...

MagicAccessors

...

# $title : string

+ getTitle() : string

+ setTitle(string $title) : void

Figura 5.26: Diagrama UML de la entidad PersonTitle



Poster

Entidad que representa los datos adicionales asociados a los papers de tipo poster.


@Table(name=”poster”): Esta entidad representa los datos almacenados en la tabla poster.

5.4.6.7.1 Atributos


Identificador del poster en la base de datos.



@Column(type=”integer”, name=”poster_id”, unique=true, nullable=false):

Este atributo se corresponde con la columna poster_id de tipo entero.



protected $paper: \CMMSE\Doctrine\Paper

Referencia al paper asociado al poster.


@OneToOne(targetEntity=”CMMSE\Doctrine\Poster”): Este atributo apunta a una entidad

de \CMMSE\Doctrine\Paper.

@JoinColumn(name=”paper_id”, referencedColumnName=”idpaper”):

Este atributo se corresponde con la columna paper_id.

Este atributo coincide con el valor de la columna idpaper de la tabla asociada a la


protected $ts_begin : \DataTime

Fecha y hora de inicio de exposición del poster.



protected $ts_end : \DataTime

Fecha y hora de fin de exposición del poster.

@Column(type="datetime", name="ts_end"): Este atributo se corresponde con la columna

ts_end de tipo fecha y hora.

protected $room: \CMMSE\Doctrine\Room

Referencia a la sala asociada al poster.

@OneToOne(targetEntity=”CMMSE\Doctrine\Room”): Este atributo apunta a una entidad

de \CMMSE\Doctrine\Room.

@JoinColumn(name=”room”, referencedColumnName=”room_id”):

Este atributo se corresponde con la columna room.

Este atributo coincide con el valor de la columna room_id de la tabla asociada a la




5.4.6.7.2 Métodos


Obtiene el identificador del poster actual.

public function getPaper() : \CMMSE\Doctrine\Paper

Obtiene una instancia del paper asociado al poster actual.

public function geTs_begin() : \DateTime

Obtiene la fecha y hora de inicio de exposición del poster.

public function geTs_end() : \DateTime

Obtiene la fecha y hora de fin de exposición del poster.

public function getRoom () : \CMMSE\Doctrine\Room

Obtiene una instancia de la sala asociada al poster actual, o null si no se ha asociado ninguna.


Establece el identificador del poster actual.

public function setPaper(\CMMSE\Doctrine\Paper $paper) : void

Establece el paper asociado al poster actual.

public function seTs_begin(\DateTime $ts_begin) : void

Establece la fecha y hora de inicio de exposición del poster.

public function seTs_end(\DateTime $ts_end) : void

Establece la fecha y hora de fin de exposición del poster.

public function setRoom([\CMMSE\Doctrine\Room $room]) : void

Establece la sala asociada al poster actual. Si se utiliza sin parámetros, se elimina la asociación

con cualquier sala que pudiese existir.



<<Interfaz>>

ArrayAccess

...

Poster

# $id : integer

+ getId() : integer

# $paper : Poster

+ getPaper() : Paper

+ setPaper(Paper $paper) : void+ setId(integer $id) : void

ArrayAccess

...

MagicAccessors

...

# $room : Room

+ getTs_begin() : \DateTime

+ setTs_begin(\DateTime $ts) : void

# $ts_begin : \DateTime# $ts_end : \DateTime

+ getTs_end() : \DateTime+ getRoom() : Room

+ setTs_end(\DateTime $ts) : void+ setRoom(Room $room) : void

Figura 5.27: Diagrama UML de la entidad Poster



Room

Entidad que representa los datos de las salas.


@Table(name=”rooms”): Esta entidad representa los datos almacenados en la tabla rooms.

5.4.6.8.1 Atributos


Identificador de la sala en la base de datos.



@Column(type=”integer”, name=”room_id”, unique=true, nullable=false):

Este atributo se corresponde con la columna room_id de tipo entero.



protected $name : string

Nombre de la sala.

@Column(type="string", name="name"): Este atributo se corresponde con la columna name

de tipo cadena.

5.4.6.8.2 Métodos


Obtiene el identificador de la sala actual, o null si la entidad no se corresponde con datos


public function getName() : string

Obtiene el nombre de la sala actual.


Establece el identificador de la sala actual.

public function setName(string $name) : void

Establece el nombre de la sala actual.



<<Interfaz>>

ArrayAccess

...

Room

# $id : integer

+ getId() : integer

# $name : string

+ getName() : string

+ setName(string $title) : void+ setId(integer $id) : void

ArrayAccess

...

MagicAccessors

...

Figura 5.28: Diagrama UML de la entidad Room



Session

Entidad que representa los datos de las sesiones de usuario.


@Table(name=”session”): Esta entidad representa los datos almacenados en la tabla sessions.

5.4.6.9.1 Atributos

protected $sid: integer

Identificador de la sala en la base de datos.



@Column(type=”integer”, name=”sid”, unique=true, nullable=false):

Este atributo se corresponde con la columna sid de tipo entero.



protected $hash : string

Hash de la sesión.

@Column(type="string", name="hash"): Este atributo se corresponde con la columna hash

de tipo cadena.

protected $data : string

Datos de la sesión serializados.

@Column(type="string", name="data"): Este atributo se corresponde con la columna data

de tipo cadena.

protected $expired : integer

Entero que representa si la sesión ha expirado. El valor 0 indica que la sesión ha expirado,

cualquier otro indica lo contrario.

@Column(type="integer", name="expired"): Este atributo se corresponde con la columna

expired de tipo entero.

5.4.6.9.2 Métodos


Obtiene el identificador de la sesión actual.

public function getHash() : string

Obtiene el hash de la sesión actual.

public function getData() : string

Obtiene los datos de sesión serializados.

public function getExpired() : integer

Obtiene el flag que indica si la sesión ha expirado, como un entero. El valor 0 indica que la

sesión ha expirado, cualquier otro indica lo contrario.




Establece el identificador de la sesión actual.

public function setHash(string $name) : void

Establece el hash de la sala actual.

public function setData(string $data) : void

Establece los datos asociados a la sesión serializados.

public function setExpired(integer $expired) : void

Establece el flag que indica si la sesión ha expirado. Si se le pasa cualquier valor distinto de cero

como parámetro se marca la sesión como expirada y viceversa.

<<Interfaz>>

ArrayAccess

...

Session

# $sid : integer

+ getId() : integer

# $hash : string

+ getHash() : string

+ setHash(string $hash) : void+ setId(integer $id) : void

ArrayAccess

...

MagicAccessors

...

+ getData() : string

+ setData(string $data) : void

# $data : string# $expired : integer

+ getExpired() : boolean

+ setExpired(integer $expired) : void

Figura 5.29: Diagrama UML de la entidad Session



Settings

Entidad que representa los datos de configuración de la aplicación.


@Table(name=”settings”): Esta entidad representa los datos almacenados en la tabla settings.



Identificador de la fila de la base de datos que almacena los datos de configuración de la

aplicación. En la implementación actual el valor de este atributo siempre es uno.



@Column(type=”integer”, name=”idsetting”, unique=true, nullable=false):

Este atributo se corresponde con la columna idsetting de tipo entero.



protected $year : integer

Año de celebración (edición) de la conferencia.

@Column(type="string", name="yearconf"): Este atributo se corresponde con la columna

yearconf de tipo entero.

protected $date : string

Fecha(s) de celebración de la conferencia, como una cadena de texto.

@Column(type="string", name="dateconf"): Este atributo se corresponde con la columna

dateconf de tipo cadena.

protected $place : string

Lugar de celebración de la conferencia.

@Column(type="string", name="placeconf"): Este atributo se corresponde con la columna

placeconf de tipo cadena.

protected $url : string

URL de la web de la conferencia.

@Column(type="string", name="urlconf"): Este atributo se corresponde con la columna

urlconf de tipo cadena.

protected $date_facturas : string

Fecha(s) a mostrar en las facturas generadas, como una cadena de texto.

@Column(type="string", name="datefirmafact"): Este atributo se corresponde con la

columna datefirmafact de tipo cadena.

protected $date_certificados : string

Fecha(s) a mostrar en los certificados generadas, como una cadena de texto.

@Column(type="string", name="datefirmacert"): Este atributo se corresponde con la

columna datefirmacert de tipo cadena.



protected $cif: string

CIF de la organización del congreso.

@Column(type="string", name="cif"): Este atributo se corresponde con la columna cif de

tipo cadena.

protected $isbn: string

ISBN de la publicación que contendrá los papers presentados en el congreso.

@Column(type="string", name="isbn"): Este atributo se corresponde con la columna isbn de

tipo cadena.

protected $issn: string

ISSN de la publicación que contendrá los papers presentados en el congreso.

@Column(type="string", name="issn"): Este atributo se corresponde con la columna issn de

tipo cadena.

protected $email: string

Lista de direcciones de correo électrónico concatenadas a las que se enviarán las

notificaciones.

@Column(type="string", name="email"): Este atributo se corresponde con la columna issn

de tipo cadena.

protected $closed: boolean

Flag que indica si el acceso público a la aplicación está habilitado.

@Column(type="boolean", name="bbddonoff"): Este atributo se corresponde con la

columna bbddonoff de tipo booleano.

protected $red_cif: string

CIF del patrocinador de la conferencia, si lo hubiera, o null.

@Column(type="string", name="red_cif"): Este atributo se corresponde con la columna

red_cif de tipo cadena.

protected $red_name: string

Nombre del patrocinador de la conferencia, si lo hubiera, o null.

@Column(type="string", name="red_name"): Este atributo se corresponde con la columna

red_name de tipo cadena.

protected $red_address: string

Dirección del patrocinador de la conferencia, si lo hubiera, o null.

@Column(type="string", name="red_address"): Este atributo se corresponde con la

columna red_address de tipo cadena.

protected $red_company: string

Nombre de la compañía patrocinadora de la conferencia (a nombre de la cual se emiten las

facturas), si lo hubiera, o null.

@Column(type="strng", name="red_company"): Este atributo se corresponde con la

columna red_company de tipo cadena.



protected $tipoetiqueta: integer

Entero que representa el tipo de etiquetas (horizontal/vertical) a generar.

@Column(type="integer", name="tipoetiqueta"): Este atributo se corresponde con la

columna tipoetiqueta de tipo entero.

protected $sizeetiqueta: integer

Entero que representa el tamaño de las etiquetas a generar.

@Column(type="integer", name="sizeetiqueta"): Este atributo se corresponde con la

columna sizeetiqueta de tipo entero.

protected $plazo_cerrado: boolean

Booleano que indica si el plazo de envío de papers está cerrado.

@Column(type="boolean", name="plazo_cerrado "): Este atributo se corresponde con la

columna plazo_cerrado de tipo booleano.

5.4.6.10.2 Métodos

public function getIsDefault() : boolean

Obtiene un flag que indica si los datos de configuración representados por la instancia actual

han sido leídos desde la base de datos.


Obtiene el identificador de la fila de la base de datos que almacena los datos de configuración.

public function getIdSetting() : integer



public function getYear() : integer

Obtiene el año de celebración (edición) de la conferencia configurado.


Obtiene la(s) fecha(s) configurada(s) de celebración de la conferencia, como una cadena de

texto.

public function getPlace() : string

Obtiene el lugar de celebración de la conferencia.

public function getURL() : string

Obtiene la URL de la web de la conferencia.

public function getDateFacturas() : string

Obtiene la(s) fecha(s) a mostrar en las facturas generadas, como una cadena de texto.

public function getDateCertificados() : string

Obtiene la(s) fecha(s) a mostrar en los certificados generados, como una cadena de texto.

public function getCIF() : string

Obtiene el CIF asociado a la organización de la conferencia.



public function getISBN() : string

Obtiene el ISBN de la publicación que contendrá los papers presentados en el congreso.

public function getISSN() : string

Obtiene el ISSN de la publicación que contendrá los papers presentados en el congreso.

public function getEMail() : string

Obtiene una cadena de texto con la lista de direcciones de correo electrónico concatenadas a

las que se enviarán las notificaciones.

public function getClosed() : boolean

Obtiene el flag que indica si el acceso público a la aplicación está habilitado.

public function getRedCIF() : string

Obtiene el CIF del patrocinador de la conferencia, si lo hubiera, o null.

public function getRedName() : string

Obtiene el nombre del patrocinador de la conferencia, si lo hubiera, o null si no hay

patrocinador.

public function getRedAddress() : string

Obtiene la dirección de facturación del patrocinador de la conferencia, si lo hubiera, o null si

no hay patrocinador.

public function getRedCompany() : string

Obtiene el nombre de la compañía patrocinadora de la conferencia (a nombre de la cual se

emiten las facturas), si la hubiera, o null si no hay patrocinador.

public function getTipoEtiqueta() : integer

Obtiene el tipo de etiquetas (horizontal/vertical) a generar, representado como un entero. El

valor 0 indica etiquetas verticales; el valor 1, horizontales; otros valores no están definidos y

provocan que se generen etiquetas verticales.

public function getSizeEtiqueta() : integer

Obtiene el tamaño de las etiquetas a generar, representado como un entero. En la

implementación actual, el valor 9 representa etiquetas de 9,2x6,25cm; el valor 15, 15x7,5cm;

otros valores no están definidos y provocan que se generen etiquetas de 15x7,5cm.

public function getPlazoCerrado() : boolean

Obtiene un flag que indica si el plazo de envío de papers está cerrado.



public function setIdSetting(integer $id) : void





public function setYear(integer $year) : void

Obtiene el año de celebración (edición) de la conferencia configurado.

public function setDate(string $date) : void

Establece la(s) fecha(s) de celebración de la conferencia, como una cadena de texto.

public function setPlace(string $place) : void

Establece el lugar de celebración de la conferencia.

public function setURL(string $url) : void

Establece la URL de la web de la conferencia.

public function setDateFacturas(string $date) : void

Establece la(s) fecha(s) a mostrar en las facturas generadas, como una cadena de texto.

public function setDateCertificados(string $date) : void

Establece la(s) fecha(s) a mostrar en los certificados generados, como una cadena de texto.

public function setCIF(string $cif) : void

Establece el CIF asociado a la organización de la conferencia.

public function setISBN(string $isbn) : void

Establece el ISBN de la publicación que contendrá los papers presentados en el congreso.

public function setISSN(string $issn) : void

Establece el ISSN de la publicación que contendrá los papers presentados en el congreso.

public function setEMail(string $email) : void

Establece la lista de direcciones de correo electrónico a las que se enviarán las notificaciones

a partir de una lista de direcciones de correo concatenadas (separadas por comas).

public function setClosed(boolean $closed) : void

Establece el flag que indica si el acceso público a la aplicación está habilitado.

public function setRedCIF(string $cif) : void

Establece el CIF del patrocinador de la conferencia, si lo hubiera, o null si no hay

patrocinador.

public function setRedName(string $red_name) : void

Establece el nombre del patrocinador de la conferencia, si lo hubiera, o null si no hay

patrocinador.

public function setRedAddress(string $red_address) : void

Establece la dirección de facturación del patrocinador de la conferencia, si lo hubiera, o null si

no hay patrocinador.

public function setRedCompany(string $red_company) : void

Establece el nombre de la compañía patrocinadora de la conferencia (a nombre de la cual se

emiten las facturas), si la hubiera, o null si no hay patrocinador.



public function setTipoEtiqueta(integer $tipo_etiqueta) : void

Establece el tipo de etiquetas a generar. El valor 0 representa etiquetas verticales; el valor 1,

horizontales; otros valores no están definidos y provocan que se generen etiquetas verticales.

public function setSizeEtiqueta(integer $size_etiqueta) : void

Obtiene el tamaño de las etiquetas a generar. En la implementación actual, el valor 9

representa etiquetas de 9,2x6,25cm; el valor 15, 15x7,5cm; otros valores no están definidos y

provocan que se generen etiquetas de 15x7,5cm.

public function setPlazoCerrado(boolean $cerrado) : void

Obtiene un flag que indica si el plazo de envío de papers está cerrado.

<<Interfaz>>

ArrayAccess

...

Settings

# $sid : integer

+ getIsDefault() : boolean

# $year : string

+ getId() : integer

+ setYear(integer $year) : void+ setId(integer $id) : void

ArrayAccess

...

MagicAccessors

...

+ getYear() : integer

+ setPlace(string $place) : void

# $place : string...

+ getPlace() : string

...

...

Figura 5.30: Diagrama UML de la entidad Settings



Trip

Entidad que representa los datos de las excursiones.


@Table(name=”trips”): Esta entidad representa los datos almacenados en la tabla trips.



Identificador de la excursión en la base de datos.



@Column(type=”integer”, name=”trip_id”, unique=true, nullable=false):

Este atributo se corresponde con la columna trip_id de tipo entero.



protected $name : string

Nombre de la excursión.

@Column(type="string", name="name"): Este atributo se corresponde con la columna name

de tipo cadena.

5.4.6.11.2 Métodos


Obtiene el identificador de la excursión actual, o null si la entidad no se corresponde con datos


public function getName() : string

Obtiene el nombre de la excursión actual.


Establece el identificador de la excursión actual.

public function setName(string $name) : void

Establece el nombre de la excursión actual.



<<Interfaz>>

ArrayAccess

...

Trip

# $id : integer

+ getId() : integer

# $name : string

+ getName() : string

+ setName(string $title) : void+ setId(integer $id) : void

ArrayAccess

...

MagicAccessors

...

Figura 5.31: Diagrama UML de la entidad Trip



User

Entidad que representa los datos básicos asociados a los usuarios.


@Table(name=”usuarios”): Esta entidad representa los datos almacenados en la tabla trips.



Identificador del usuario en la base de datos.



@Column(type=”integer”, name=”iduser”, unique=true, nullable=false):

Este atributo se corresponde con la columna iduser de tipo entero.



protected $password : string

Contraseña del usuario codificada con MD5.

@Column(type="string", name="password"): Este atributo se corresponde con la columna

password de tipo cadena.

protected $firstname : string

Nombre de pila del usuario.

@Column(type="string", name="firstname"): Este atributo se corresponde con la columna

firstname de tipo cadena.

protected $lastname : string

Apellidos del usuario.

@Column(type="string", name="lastname"): Este atributo se corresponde con la columna

lastname de tipo cadena.

protected $email : string

Dirección de correo electrónico del usuario.

@Column(type="string", name="email"): Este atributo se corresponde con la columna

lastname de tipo cadena.

protected $company : string

Nombre de la compañía o institución a la que pertenece el usuario.

@Column(type="string", name="company"): Este atributo se corresponde con la columna

company de tipo cadena.


Título honorífico aplicado al usuario.


tipo cadena.



protected $country : string

País de origen del usuario.

@Column(type="string", name="country", nullable=false): Este atributo se corresponde con

la columna country de tipo cadena.

protected $state : string

Estado, comunidad autónoma o subdivisión análoga de origen del usuario.

@Column(type="string", name="state", nullable=true): Este atributo se corresponde con la

columna state de tipo cadena.

protected $city : string

Ciudad de origen del usuario.

@Column(type="string", name="city", nullable=true): Este atributo se corresponde con la

columna city de tipo cadena.

protected $address : string

Dirección del usuario (texto libre).

@Column(type="string", name="address", nullable=true): Este atributo se corresponde con

la columna address de tipo cadena.

protected $postalcode : string

Código postal del usuario.

@Column(type="string", name="postalcode", nullable=true): Este atributo se corresponde

con la columna postalcode de tipo cadena.

protected $telephone : string

Número de teléfono del usuario.

@Column(type="string", name="telephone", nullable=true): Este atributo se corresponde

con la columna telephone de tipo cadena.

protected $factura : string

Nombre del archivo de justificante de pago enviado por el usuario, o null si no ha enviado

ninguno.

@Column(type="string", name="factura", nullable=true): Este atributo se corresponde con

la columna factura de tipo cadena.

protected $fees : string

Cuota de inscripción para el usuario (en euros), o null si tiene asignada la cuota por defecto.

@Column(type="string", name="fees", nullable=true): Este atributo se corresponde con la

columna factura de tipo cadena.

protected $type : string

Tipo de usuario.

@Column(type="string", name="type", nullable=false): Este atributo se corresponde con la

columna factura de tipo cadena.



5.4.6.12.3 Métodos


Obtiene el identificador del usuario actual.

public function getPassword() : string

Obtiene el password (cifrado) del usuario.

public function getFirstname() : string

Obtiene el nombre de pila del usuario.

public function getLastname() : string

Obtiene el apellido del usuario.

public function getEmail() : string

Obtiene la dirección de correo electrónico del usuario.

public function getCompany() : string

Obtiene el nombre de la compañía o institución del usuario, o null si el usuario no tiene uno

asignado.


Obtiene el título honorífico asociado al usuario.

public function getCountry() : string

Obtiene el nombre del país del usuario.

public function getState() : string

Obtiene el nombre del estado, comunidad autónoma o subdivisión análoga de origen del

usuario, o null si el usuario no tiene uno asignado.

public function getCity() : string

Obtiene la ciudad de origen del usuario, o null si el usuario no tiene una asignada.

public function getAddress() : string

Obtiene la dirección del usuario tal como éste la ha indicado (texto libre), o null si el usuario no

tiene una asignada.

public function getPostalcode() : string

Obtiene el código postal del usuario, o null si el usuario no tiene uno asignado.

public function getTelephone() : string

Obtiene el número de teléfono del usuario, o null si el usuario no tiene uno asignado.

public function getFactura() : string

Obtiene el nombre del archvo enviado como justificante de pago por el usuario actual, o null si

el usuario no ha enviado ninguno.


Obtiene la cuota de inscripción a pagar por el usuario (en euros), o null si tiene asignada la

cuota por defecto.



public function getType() : integer

Obtiene el tipo de cuenta del usuario como un entero. El valor 1 representa las cuentas de

administrador; el 2, las de ponente; el 3, las de editor.


Establece el identificador del usuario actual.

public function setPassword(string $password) : void

Establece el password (encriptado) del usuario.

public function setFirstname(string $firstname) : void

Establece el nombre de pila del usuario.

public function setLastname(string $lastname) : void

Establece el apellido del usuario.

public function setEmail(string $email) : void

Establece el password (encriptado) del usuario.

public function setCompany(string $company) : void

Establece el nombre de la compañía o institución del usuario.


Establece el título honorífico asociado al usuario.

public function setCountry(string $country) : void

Establece el nombre del país del usuario.

public function setState(string $state) : void

Establece el estado, comunidad autónoma o subdivisión análoga de origen del usuario.

public function setCity(string $city) : void

Establece la ciudad de origen del usuario.

public function setAddress(string $address) : void

Establece la dirección del usuario como texto libre.

public function setPostalcode(string $postalcode) : void

Establece el código postal del usuario.

public function setTelephone(string $telephone) : void

Establece el número de teléfono del usuario.

public function setFactura(string $factura) : void

Establece el nombre de archivo del justificante de pago enviado por el usuario.

public function setFees(string $fees) : void

Establece la cuota de inscripción a pagar por el usuario.

public function setType(string $type) : void

Establece el tipo de cuenta del usuario.



<<Interfaz>>

ArrayAccess

...

User

# $sid : integer# $password : string

+ getId() : integer

+ setPassword(string $year) : void+ setId(integer $id) : void

ArrayAccess

...

MagicAccessors

...

+ getPassword() : string

# $firstname : string

+ getFirstname() : string

...

...

# $lastname : string...

+ getLastname() : string

+ setFirstname(string $firstname) : void+ setLastname(string $lastname) : void

Figura 5.32: Diagrama UML de la entidad User



UserBillingInfo

Entidad que representa los datos básicos asociados a los usuarios.


@Table(name=”facturacion”): Esta entidad representa los datos almacenados en la tabla

facturacion.



Identificador del usuario en la base de datos cuyos datos de facturación representa este

objeto.



@Column(type=”integer”, name=”iduser”, unique=true, nullable=false):

Este atributo se corresponde con la columna iduser de tipo entero.



protected $user: \CMMSE\Doctrine\User

Referencia al usuario asociado a los datos de facturación.


@OneToOne(targetEntity=”CMMSE\Doctrine\User”): Este atributo apunta a una entidad de

\CMMSE\Doctrine\User.

@JoinColumn(name=”iduser”, referencedColumnName=”iduser”):

Este atributo se corresponde con la columna iduser.

Este atributo coincide con el valor de la columna iduser de la tabla asociada a la entidad

referenciada.

protected $factura : string

Nombre de archivo del justificante de pago enviado por el usuario.

@Column(type="string", name="factura", nullable=true):Este atributo se corresponde con

la columna factura de tipo cadena.

protected $pago : boolean

Flag que indica si el pago del usuario ha sido confirmado.

@Column(type="boolean", name="pago", nullable=false): Este atributo se corresponde con

la columna pago de tipo booleano.

protected $billnumber : integer

Número de factura asignado al usuario.

@Column(type="integer", name="billnumber", nullable=true): Este atributo se corresponde

con la columna billnumber de tipo entero.



protected $billcif : string

CIF a usar en la factura del usuario.

@Column(type="string", name="billcif", nullable=true): Este atributo se corresponde con la

columna billcif de tipo cadena.

protected $billcompany : string

Compañía que pagará la factura del usuario.

@Column(type="string", name="billcompany", nullable=true): Este atributo se corresponde

con la columna billcompany de tipo cadena.

protected $billaddress : string

Dirección de facturación para la emisión de la factura del usuario.

@Column(type="string", name="billaddress", nullable=true): Este atributo se corresponde

con la columna billaddress de tipo cadena.

protected $billname : string

Nombre del beneficiario para la emisión de la factura del usuario.

@Column(type="string", name="billname", nullable=true): Este atributo se corresponde

con la columna billname de tipo cadena.

protected $bill_red : string

Flag que indica si la factura emitida es de un usuario patrocinado.

@Column(type="boolean", name="bill_red", nullable=false): Este atributo se corresponde

con la columna bill_red de tipo booleano.

protected $billnumber_red : string

Número de la factura según la numeración del patrocinador.

@Column(type="integer", name="billnumber_red", nullable=false): Este atributo se

corresponde con la columna bill_red de tipo entero.

protected $fees : integer

Cuota de inscripción, en euros.

@Column(type="integer", name="fees ", nullable=false): Este atributo se corresponde con

la columna fees de tipo entero.

protected $billprint : boolean

Flag que indica si la factura del usuario está lista para ser impresa.

@Column(type="boolean", name="billprint ", nullable=false): Este atributo se corresponde

con la columna billprint de tipo booleano.

5.4.6.13.2 Métodos


Obtiene el identificador del usuario cuyos datos de facturación representa el objeto actual, o

null si la entidad no se corresponde con datos almacenados (aún) en la base de datos.

public function getUser() : \CMMSE\Doctrine\User

Obtiene una instancia de un objeto que representa al usuario asociado a los datos de

facturación representados por el objeto actual.



public function getFactura() : string

Obtiene el nombre de archivo del justificante de pago enviado por el usuario asociado a los

datos de facturación representados por el objeto actual.

public function getPago() : boolean

Obtiene el flag que indica si el pago del usuario asociado a los datos de facturación

representados por el objeto actual ha sido confirmado.

public function getBillnumber() : integer

Obtiene el número de factura asignado al usuario asociado a los datos de facturación

representados por el objeto actual, o null en caso de que no se le haya asignado uno.

public function getBillCIF() : string

Obtiene el CIF del usuario asociado a los datos de facturación representados por el objeto

actual, o null en caso de que no se haya indicado.

public function getBillCompany() : string

Obtiene el nombre de la compañía, empresa o institución que se encargará del pago de la

factura del usuario asociado a los datos de facturación representados por el objeto actual, o

null en caso de que no se haya indicado.

public function getBillAddress() : string

Obtiene la dirección de facturación a utilizar en la factura generada para el usuario asociado a

los datos de facturación representados por el objeto actual, o null en caso de que no se haya

indicado.

public function getBillName() : string

Obtiene el nombre del beneficiario para la emisión de la factura generada para el usuario

asociado a los datos de facturación representados por el objeto actual, o null en caso de que

no se haya indicado.

public function getBill_red() : boolean

Obtiene el flag que indica si los datos de facturación representados por el objeto actual se

correspondes con un usuario patrocinado.

public function getBillnumber_red() : integer

Obtiene el número de factura del patrocinador asignado al usuario asociado a los datos de

facturación representados por el objeto actual, o null en caso de que no se le haya asignado

uno.


Obtiene la cuota de inscripción a pagar, en euros, por el usuario asociado a los datos de

facturación representados por el objeto actual, o null en caso de que tenga asignada la cuota

por defecto.

public function getBillprint() : integer

Obtiene el flag que indica si la factura del usuario representado por el objeto actual está lista

para ser impresa.




Establece el identificador del usuario cuyos datos de facturación representa el objeto actual.

public function setUser(\CMMSE\Doctrine\User $user) : void

Establece el usuario asociado a los datos de facturación representados por el objeto actual.

public function setFactura(string $factura) : void

Establece el nombre de archivo del justificante de pago enviado por el usuario asociado a los

datos de facturación representados por el objeto actual.

public function setPago(boolean $pago) : void

Establece el flag que indica si el pago del usuario ha sido confirmado asociado a los datos de


public function setBillnumber(integer $billnumber) : void

Establece el número de factura asignado al usuario asociado a los datos de facturación

representados por el objeto actual.

public function setBillCIF(string $billcif) : void

Establece el CIF del usuario asociado a los datos de facturación representados por el objeto

actual.

public function setBillCompany(string $billcompany) : void

Establece el nombre de la compañía, empresa o institución que se encargará del pago de la

factura del usuario asociado a los datos de facturación representados por el objeto actual.

public function setBillAddress(string $billaddress) : void

Establece la dirección de facturación a utilizar en la factura generada para el usuario asociado

a los datos de facturación representados por el objeto actual.

public function setBillName(string $billname) : void

Establece el nombre del beneficiario para la emisión de la factura generada para el usuario

asociado a los datos de facturación representados por el objeto actual.

public function setBill_red(boolean $bill_red) : void

Establece el flag que indica si los datos de facturación representados por el objeto actual se

correspondes con un usuario patrocinado.

public function setBillnumber_red(integer $billnumber_red) : void

Establece el número de factura del patrocinador asignado al usuario asociado a los datos de


public function setFees(integer $fees) : void

Establece la cuota de inscripción a pagar, en euros, por el usuario asociado a los datos de

facturación representados por el objeto actual, o null para asignarle la cuota por defecto.

public function setBillprint(integer $billprint) : void

Establece el flag que indica si la factura del usuario representado por el objeto actual está lista

para ser impresa.



<<Interfaz>>

ArrayAccess

...

UserBillingInfo

# $sid : integer# $user : User

+ getId() : integer

+ setUser(User $u) : void+ setId(integer $id) : void

ArrayAccess

...

MagicAccessors

...

+ getUser() : User

# $factura : string

+ getFactura() : string

...

...

# $pago : boolean...

+ getPago() : boolean

+ setFactura(string $factura) : void+ setPago(boolean $pago) : void

Figura 5.33: Diagrama UML de la entidad UserBillingInfo



5.4.7 \CMMSE\Decorators

Espacio de nombres que contiene clases usadas para extender las entidades con funcionalidades

adicionales. Estas clases son utilizadas, principalmente, para proporcionar a las plantillas HTML los

atributos originales con otros formatos (como formatos adicionales para fechas) o para añadir

atributos derivados de los datos disponibles (por ejemplo, añadir a los usuarios un atributo que indique

si ha pagado la cuota de inscripción).

Autor

Decorador que extiende las entidades que representan a los usuarios para proporcionar campos

adicionales con el número de papers y posters enviados.

5.4.7.1.1 Atributos

protected $numPapers: integer

Número de papers enviados por el usuario.

protected $numPosters : integer

Número de papers de tipo poster enviados por el usuario.

5.4.7.1.2 Métodos

public function __construct(\CMMSE\Doctrine\User $source, integer $num_papers, integer

$num_posters) : void

Crea una nueva instancia del decorador a partir de una instancia de usuario y el número de

papers y posters que éste ha enviado.

public function getNumPapers() : integer

Obtiene el número de papers enviados por el usuario.

public function getNumPosters() : integer

Obtiene el número de papers de tipo poster enviados por el usuario.



PagoUsuario

Decorador que extiende las entidades que representan a los usuarios para proporcionar un campo

adicional que indica si ha pagado.

5.4.7.2.1 Atributos

protected $pago: boolean

Flag que indica si el pago del usuario ha sido confirmado.

5.4.7.2.2 Métodos

public function __construct(\CMMSE\Doctrine\User $source, boolean $haPagado) : void

Crea una nueva instancia del decorador a partir de una instancia de usuario y un booleano que

indique si ha pagado o no.


Obtiene el flag que indicia si el usuario ha pagado.

User

Autor

# $numPosters : integer

+ getNumPapers() : integer

CopyConstructor

# copyPropertiesFrom(object $src) : void

# $numPapers : integer


+ getNumPosters() : integer

PagoUsuario

# $pago : boolean


Figura 5.34: Diagrama UML de los decoradores Autor y PagoUsuario



Conference

Decorador que extiende las entidades que representan los simposios para proporcionar datos

adicionales sobre el número de papers presentados en ellas y su fecha y hora de inicio en formatos

adicionales.

5.4.7.3.1 Atributos

protected $numPapers: integer

Número de papers enviados por el usuario.

protected $numPosters : integer

Número de papers de tipo poster enviados por el usuario.

5.4.7.3.2 Métodos

public function __construct(\CMMSE\Doctrine\Conference $source, integer $num_papers,

integer $num_posters) : void

Crea una nueva instancia del decorador a partir de una instancia de simposio y el número de

papers y posters presentados en él.

public function getNunPapers() : integer

Obtiene el número de papers presentados en el simposio.


Obtiene el número de papers de tipo poster presentados en el simposio.

public function getBeginDateTime() : \DateTime

Obtiene la fecha de inicio del simposio.

public function getBegin() : string

Obtiene la fecha de inicio del simposio en el formato “<dia de la semana (3 letras)>, <dia del

mes (2 dígitos)> <nombre del mes (3 letras)> <año (4 dígitos)> <hora>:<minutos>:<segundos>”.

Por ejemplo, “Thu, 10 Apr 2014 12:00:00”.

public function getBeginAsUNIXTimestamp() : string

Obtiene la fecha de inicio del simposio como un timestamp UNIX.

public function getBeginAsISO8601() : string

Obtiene la fecha de inicio del simposio en el formato ISO-8601, por ejemplo “2014-04-

10T12:00:00+00:00”

public function getBeginForDTLocal() : string

Obtiene la fecha de inicio del simposio en el formato esperado por los tags <input> de tipo

datetime-local de HTML5.



Conference

Conference


+ getNumPapers() : integer

CopyConstructor




+ getNumPosters() : integer

+ getBeginAsUNIXTimestamp() : string

+ getBeginDateTime() : \DateTime+ getBegin() : string

+ getBeginAsISO8601() : string+ getBeginForDTLocal() : string

Figura 5.35: Diagrama UML del decorador Conference



Paper

Decorador que extiende las entidades que representan los papers para proporcionar datos adicionales

para los listados.

5.4.7.4.1 Atributos

protected $posterData: \CMMSE\Decoratos\Poster

Decorador con datos adicionales para papers de tipo poster.

protected $dia: string

Número de día de envío del paper.

protected $mes: string

Número de mes de envío del paper, con ceros iniciales

protected $anio: string

Año de envío del paper.

protected $hora: string

Hora de envío del paper.

protected $ampm: string

String que indica si la hora es anterior o posterior al mediodía.

protected $email: string

Dirección de correo electrónico del usuario que envió el paper.

protected $pago: boolean

Flag que indica si el pago del usuario que envió el paper ha sido confirmado.

5.4.7.4.2 Métodos

public function __construct(\CMMSE\Doctrine\Paper $source, boolean $pago, string $email [,

\CMMSE\Decorators\Poster $posterData]) : void

Crea una nueva instancia del decorador a partir de una instancia de un paper.

public function getEMail() : string

Obtiene la dirección de correo electrónico del usuario que envió el paper.


Obtiene el flag que indicia si el usuario ha pagado.

public function getDia() : string

Obtiene el número de día de envío del paper.

public function getMes() : string

Obtiene el número de mes de envío del paper.

public function getAnio() : string

Obtiene el año de envío del paper.



public function getHora() : string

Obtiene la hora de envío del paper.

public function getAMPM() : string

Retorna el string “AM” o “PM” según si la hora es anterior o posterior al mediodía.

public function getIDPaper() : integer

Obtiene el identificador del paper.

public function getIDUser() : integer

Obtiene el identificador del usuario que envió el paper.

public function getIDConf() : integer

Obtiene el identificador de la conferencia asociada al paper.

public function getDateUNIX() : string

Obtiene la fecha de envío del paper como un timestamp UNIX.

public function getPoster() : \CMMSE\Decorators\Poster

Obtiene la información adicional de poster, si ésta ha sido proporcionada en la llamada al

constructor.


Obtiene la fecha de envío del paper como un timestamp UNIX.

public function getTitle_Conference() : string

Obtiene el título de la conferencia en la que se presentará el paper.

public function getHasPoster() : boolean

Obtiene un flag que indica si el paper actual tiene asociado un poster.

public function getDecision() : string

Obtiene el flag de decisión como una cadena, retornando ‘1’ para el valor cierto y ‘0’ para el

valor falso.

public function getAceptado() : string

Obtiene el flag de aceptación como una cadena, retornando ‘1’ para el valor cierto y ‘0’ para el

valor falso.



Poster

Decorador que extiende las entidades que representan los posters para añadir formatos adicionales a

sus fechas de exposición.

5.4.7.5.1 Métodos

public function __construct(\CMMSE\Doctrine\Poster $source) : void

Crea una nueva instancia del decorador a partir de una instancia de un poster.

public function getBegin() : string

Obtiene la fecha de inicio de exposición del poster en el formato “<dia de la semana (3 letras)>,

<dia del mes (2 dígitos)> <nombre del mes (3 letras)> <año (4 dígitos)>

<hora>:<minutos>:<segundos>”. Por ejemplo, “Thu, 10 Apr 2014 12:00:00”.

public function getBegin_NoSeconds() : string

Obtiene la fecha de inicio de exposición del poster en el formato “<dia de la semana (3 letras)>,

<dia del mes (2 dígitos)> <nombre del mes (3 letras)> <año (4 dígitos)> <hora>:<minutos>”. Por

ejemplo, “Thu, 10 Apr 2014 12:00”.

public function getBeginAsUNIXTimestamp() : string

Obtiene la fecha de inicio de exposición del poster como un timestamp UNIX.

public function getBeginAsISO8601() : string

Obtiene la fecha de inicio de exposición del poster según el formato ISO-8601. Por ejemplo,

2014-04-10T15:52:01+0000.

public function getBeginForDTLocal() : string

Obtiene la fecha de inicio de exposición del poster en el formato esperado por los tags <input>

de tipo datetime-local de HTML5.

public function getEnd() : string

Obtiene la fecha de fin de exposición del poster en el formato “<dia de la semana (3 letras)>,

<dia del mes (2 dígitos)> <nombre del mes (3 letras)> <año (4 dígitos)>

<hora>:<minutos>:<segundos>”. Por ejemplo, “Thu, 10 Apr 2014 12:00:00”.

public function getEnd_NoSeconds() : string

Obtiene la fecha de fin de exposición del poster en el formato “<dia de la semana (3 letras)>,

<dia del mes (2 dígitos)> <nombre del mes (3 letras)> <año (4 dígitos)> <hora>:<minutos>”. Por

ejemplo, “Thu, 10 Apr 2014 12:00”.

public function getEndAsUNIXTimestamp() : string

Obtiene la fecha de fin de exposición del poster como un timestamp UNIX.

public function getEndAsISO8601() : string

Obtiene la fecha de fin de exposición del poster según el formato ISO-8601. Por ejemplo, 2014-

04-10T15:52:01+0000.



public function getEndForDTLocal() : string

Obtiene la fecha de fin de exposición del poster en el formato esperado por los tags <input>

de tipo datetime-local de HTML5.

Room

Decorador que extiende las entidades que representan las salas para proporcionar datos adicionales

sobre los posters presentados en ellas.

5.4.7.6.1 Atributos

protected $posters: \CMMSE\Doctrine\Poster[]

Array con los posters presentados en la sala.

5.4.7.6.2 Métodos

public function __construct(\CMMSE\Doctrine\Room $source, \CMMSE\Doctrine\Poster[]

$posters) : void

Crea una nueva instancia del decorador a partir de una instancia de una sala y un array con los

posters presentados en ella.


Obtiene el número de posters expuestos en la sala.

public function getPosterList() : \CMMSE\Doctrine\Poster[]

Obtiene la lista de posters presentados en la sala.



Poster

Poster


+ getBegin() : string

CopyConstructor




+ getEndForDTLocal() : string

Paper

# $pago : boolean

+ getEMail() : string

Room

# $posters : Poster[]


Room

+ getNumPosters() : int+ getPosterList() : Poster[]

+ getBeginAsISO8601() : string

+ getEnd_NoSeconds() : string

+ getBeginAsUNIXTimestamp()+ getBegin_NoSeconds(): string

+ getEndAsUNIXTimestamp()

+ getBeginForDTLocal() : string

+ getEndAsISO8601() : string

+ getEnd() : string

# $email : string

# $posterData : Poster

# $mes : string

# $ampm : string

# $dia : string

# $hora : string# $anio : string

+ getAcptado() : integer



+ getHora() : string

+ getDecision() : integer

+ getDia() : string

+ getPoster() : Poster

+ getIDUser() : integer

+ getHasPoster() : bool

+ getDate() : string

+ getIDPaper() : integer

+ getIDConf() : integer+ getDateUNIX() :string

+ getMes() : string+ getAnio() : string

+ getAMPM() : string

+ getTitle_Conferencia() : string

Figura 5.36: Diagrama UML de los decoradores Paper, Poster y Room



Settings

Decorador que extiende la información de configuración del sitio añadiendo nombres alternativos para

sus campos.

5.4.7.7.1 Métodos

public function __construct(\CMMSE\Doctrine\Settings $source) : void

Crea una nueva instancia del decorador a partir de una instancia de la configuración del sitio.

public function get__isDefault() : boolean


no han sido leídos desde la base de datos.

public function __isDefault() : boolean


no han sido leídos desde la base de datos.

public function getYearConf() : integer

Obtiene el año de celebración de la conferencia.

public function getDateConf() : string

Obtiene un string que representa la fecha de celebración de la conferencia.

public function getPlaceConf() : string

Obtiene un string que representa el lugar de celebración de la conferencia.

public function getURLConf() : string

Obtiene un string con la URL de la web de la conferencia.

public function getDateFirmaFact() : string

Obtiene un string que representa la fecha a mostrar en las facturas emitidas.

public function getDateFirmaCert () : string

Obtiene un string que representa la fecha a mostrar en los certificados de presentación.



Settings

Settings

+ get__isDefault() : boolean

CopyConstructor



+ __isDefault() : boolean

+ getDateFirmaFact() : string

+ getDateConf() : string+ getYearConf() : integer

+ getPlaceConf() : string+ getURLConf() : string

+ getDateFirmaCert() : string

Figura 5.37: Diagrama UML del decorador Settings



UserBilling

Decorador que extiende las entidades que representan los datos de facturación de los usuarios para

proporcionar campos adicionales.

5.4.7.8.1 Atributos

protected $extension: string

Extensión del archivo que contiene la factura del usuario.

protected $single_image : boolean

Flag que indica si la factura del usuario es una imagen.

protected $default_fee : integer

Cuota de inscripción a pagar por defecto.

5.4.7.8.2 Métodos

public function __construct(\CMMSE\Doctrine\UserBillingInfo $source, string $extension,

boolean $single_image, integer $defaultFee) : void

Crea una nueva instancia del decorador a partir de una instancia de la información de

facturación del usuario, la extensión del archivo que contiene el justificante de pago enviado,

un flag que indica si el justificante es una imagen y la cuota de inscripción por defecto.

public function getExtension () : string

Obtiene la extensión del nombre de archivo que contiene el justificante de pago enviado por

el usuario.

public function getSingleImage() : boolean

Obtiene un flag que indica si el justificante de pago enviado por el usuario es un archivo de

imagen.

public function getSingle_Image() : boolean

Obtiene un flag que indica si el justificante de pago enviado por el usuario es un archivo de

imagen.


public function getPagado() : boolean

Obtiene un flag que indica si el pago del usuario ha sido confirmado.

public function getAuto() : boolean

Obtiene un flag que indica si el usuario tiene asignada la cuota por defecto.

public function getCuota() : integer

Obtiene la cuota a pagar por el usuario.



UserBillingInfo

UserBilling

# $default_fee : integer

+ getExtension() : string

CopyConstructor


# $extension : string


+ getSingleImage() : string

+ getPagado() : boolean+ getSingle_Image() : string

+ getAuto() : boolean+ getCuota() : integer

# $single_image : boolean

Figura 5.38: Diagrama UML del decorador UserBilling



5.4.8 \Proxies

Este espacio de nombres contiene proxys autogenerados por Doctrine para aquellas entidades que

contienen referencias a otras entidades. Estos proxys extienden a las entidades originales y su

propósito es construir de forma automática y transparente las instancias de las clases referenciadas

antes de su uso.

Se autogeneran proxys para las entidades Conference, Paper, Room y User.

<<Interfaz>>

Proxy

Room

...

...

...

...+ getId() : integer

+ setId(integer $id) : void

Room

Figura 5.39: Diagrama UML de ejemplo para el proxy generado a partir de la entidad Room



5.4.9 \CMMSE\PDFViews

Este espacio de nombres y sus descendientes contienen clases que representan las vistas usadas para

generar las páginas de etiquetas. Estas vistas están implementadas como clases independientes que

contienen llamadas directas a los métodos de la librería ezPDF debido a la dificultad de definir las

páginas de etiquetas de manera uniforme utilizando CSS y HTML.

Etiquetas

Vista genérica que contiene los atributos y operaciones compartidas por todas las vistas usadas para

generar archivos PDF de etiquetas.


5.4.9.1.1 Atributos

protected $settingsModel: \CMMSE\Interfaces\Models\ISettings

Referencia al modelo de configuración utilizado.

protected $settings: \CMMSE\Doctrine\Settings

Referencia a la configuración dinámica utilizada.

5.4.9.1.2 Métodos

public function __construct(\CMMSE\Interfaces\Models\ISettings $settingsModel) : void

Crea una nueva instancia del generador a partir de una instancia del modelo de configuración.



EtiquetasBlancoVertical

+ generar() : \CezPDF

View PDFView


<<Interfaz>>

IUser

<<Interfaz>>

ISettings

<<Interfaz>>

ITrips

EtiquetasTodosVertical

# $userModel : IUser


EtiquetasHorizontalRestaurant


EtiquetasBlancoHorizontal


EtiquetasHorizontalOrgan


EtiquetasHorizontalExcursion

# $tripsModel : ITrips

EtiquetasHorizontalDinnerGala


EtiquetasTodosHorizontal


+ generar() : \CezPDF+ __construct(ISettings, IUser) : void

Etiquetas

# $settingsModel : ISettings









# $tripsModel : ITrips




+ __construct(ISettings, ITrips) : void



+ generar() : \CezPDF+ __construct(ISettings, IUser) : void

# $settings : Settings

+ __construct(ISettings, ITrips) : void+ generar() : \CezPDF


<< Usa >>

Figura 5.40: Diagrama UML de las vistas usadas para generar las etiquetas



EtiquetasBlancoVertical

Vista que implementa la generación de archivos PDF con 8 etiquetas en blanco en sentido vertical.

5.4.9.2.1 Métodos

public function generar () : \Cezpdf

Genera un PDF con una página A4 que contiene 8 etiquetas en blanco en sentido vertical y

devuelve una referencia al objeto que lo representa.

EtiquetasTodosVertical

Vista que implementa la generación de archivos PDF con las etiquetas nominativas para todos los

ponentes. Los archivos generados contienen con 4 etiquetas por página en sentido vertical.

5.4.9.3.1 Atributos

protected $userModel: \CMMSE\Interfaces\Models\IUser

Referencia al modelo de usuarios utilizado.

5.4.9.3.2 Métodos

public function __construct(\CMMSE\Interfaces\Models\ISettings $settingsModel,

\CMMSE\Interfaces\Models\IUser $userModel) : void

Crea una nueva instancia del generador a partir de una instancia del modelo de configuración

y del modelo de usuarios.


Genera un PDF que contiene 4 etiquetas nominativas en sentido vertical por página y devuelve

una referencia al objeto que lo representa.

5.4.10 \CMMSE\PDFViews\Labels15x25

Este espacio de nombres contiene clases que representan las vistas usadas para generar las páginas

de etiquetas con tamaño 15 x 7,5 cm.


Vista que implementa la generación de archivos PDF con 4 etiquetas en blanco en sentido horizontal

y tamaño 15 x 7,5 cm.

5.4.10.1.1 Métodos


Genera un PDF con una página A4 que contiene 4 etiquetas en blanco en sentido horizontal y





Vista que implementa la generación de archivos PDF con 4 etiquetas para asistir a la cena de gala en

sentido horizontal y tamaño 15 x 7,5 cm.

5.4.10.2.1 Métodos


Genera un PDF con una página A4 que contiene 4 etiquetas para asistir a la cena de gala en

sentido horizontal y devuelve una referencia al objeto que lo representa.


Vista que implementa la generación de archivos PDF con 4 etiquetas por página para asistir a las

excursiones en sentido horizontal y tamaño 15 x 7,5 cm. Cada página contiene las etiquetas para una

de las excursiones programadas.


protected $tripsModel: \CMMSE\Interfaces\Models\ITrips

Referencia al modelo de excursiones utilizado.

5.4.10.3.2 Métodos


\CMMSE\Interfaces\Models\ITrips $tripsModel) : void


y del modelo de excursiones.


Genera un PDF con tantas páginas A4 como excursiones haya programadas y devuelve una

referencia al objeto que lo representa. Cada página contiene 4 etiquetas en sentido horizontal

para asistir a una de las excursiones.


Vista que implementa la generación de archivos PDF con 4 etiquetas por página para distinguir a los

miembros de la organización en sentido horizontal y tamaño 15 x 7,5 cm.

5.4.10.4.1 Métodos


Genera un PDF con una página A4 que contiene 4 etiquetas en sentido horizontal no

nominativas para distinguir a los miembros de la organización del congreso y devuelve una

referencia al objeto que lo representa.




Vista que implementa la generación de archivos PDF con 4 etiquetas de restaurante no nominativas

por página en sentido horizontal y tamaño 15 x 7,5 cm.

5.4.10.5.1 Métodos


Genera un PDF con una página A4 que contiene 4 etiquetas de restaurante no nominativas en




ponentes. Los archivos generados contienen con 4 etiquetas por página en sentido horizontal y tamaño

15 x 7,5 cm.




5.4.10.6.2 Métodos






Genera un PDF que contiene 4 etiquetas nominativas en sentido horizontal por página y




5.4.11 \CMMSE\PDFViews\Labels92x625

Este espacio de nombres contiene clases que representan las vistas usadas para generar las páginas

de etiquetas con tamaño 9,2 x 6,25 cm.


Vista que implementa la generación de archivos PDF con 4 etiquetas en blanco en sentido horizontal

y tamaño 9,2 x 6,25 cm.

5.4.11.1.1 Métodos


Genera un PDF con una página A4 que contiene 8 etiquetas en blanco en sentido horizontal y



Vista que implementa la generación de archivos PDF con 8 etiquetas para asistir a la cena de gala en

sentido horizontal y tamaño 9,2 x 6,25 cm.

5.4.11.2.1 Métodos


Genera un PDF con una página A4 que contiene 8 etiquetas para asistir a la cena de gala en



Vista que implementa la generación de archivos PDF con 8 etiquetas por página para asistir a las

excursiones en sentido horizontal y tamaño 9,2 x 6,25 cm. Cada página contiene las etiquetas para una

de las excursiones programadas.


protected $tripsModel: \CMMSE\Interfaces\Models\ITrips

Referencia al modelo de excursiones utilizado.

5.4.11.3.2 Métodos


\CMMSE\Interfaces\Models\ITrips $tripsModel) : void


y del modelo de excursiones.




Genera un PDF con tantas páginas A4 como excursiones haya programadas y devuelve una

referencia al objeto que lo representa. Cada página contiene 8 etiquetas en sentido horizontal

para asistir a una de las excursiones.


Vista que implementa la generación de archivos PDF con 8 etiquetas por página para distinguir a los

miembros de la organización en sentido horizontal y tamaño 9,2 x 6,25 cm.

5.4.11.4.1 Métodos


Genera un PDF con una página A4 que contiene 8 etiquetas en sentido horizontal no

nominativas para distinguir a los miembros de la organización del congreso y devuelve una

referencia al objeto que lo representa.


Vista que implementa la generación de archivos PDF con 8 etiquetas de restaurante no nominativas

por página en sentido horizontal y tamaño 9,2 x 6,25 cm.

5.4.11.5.1 Métodos


Genera un PDF con una página A4 que contiene 4 etiquetas de restaurante no nominativas en




ponentes. Los archivos generados contienen con 8 etiquetas por página en sentido horizontal y tamaño

9,2 x 6,25 cm.




5.4.11.6.2 Métodos








Genera un PDF que contiene 8 etiquetas nominativas en sentido horizontal por página y




5.4.12 \CMMSE\Interfaces

Este espacio de nombres y sus descendientes contienen la interfaz esperada para diferentes

componentes de la aplicación.

IModel

Interfaz padre de la que heredan las interfaces de los modelos del sitio.

5.4.12.1.1 Métodos

Esta interfaz no define métodos propios.

IPermissionCheck

Interfaz usada por las clases que implementan la comprobación de permisos necesarios de la sesión

actual para realizar diferentes acciones.

5.4.12.2.1 Métodos

public function assertHasPermission(mixed[] $sessionData,


Comprueba que la sesión pasada como parámetro tiene permiso para ver el contenido

solicidado. Este método debe ser redefinido por los objetos concretos que implementen la

interfaz, y debe lanzar una excepción en caso de que la sesión no reuna los requisitos

necesarios.

onConstruct

Interfaz implementada por los controladores que requieren ejecutar código adicional tras su

instanciación.

5.4.12.3.1 Métodos

public function onConstruct() : void

Método a ejecutar en las instancias de los objetos recién creados. Este método debe ser

redefinido por los controladores que requieran realizar operaciones adicionales tras su

instanciación, como la obtención de referencias a modelos o la creación de objetos internos.



ModelFactory

Interfaz implementada por las clases encargadas de proporcionar instancias de los modelos de la

aplicación.

5.4.12.4.1 Métodos

public function getModel(string $modelInterface) : \CMMSE\Interfaces\IModel

Retorna una referencia a un modelo a partir del FQN de su interfaz. En caso de que se solicite

un modelo a partir de una interfaz desconocida, la función debe lanzar una excepción.

<<Interfaz>>

onConstruct

+ onConstruct() : void

<<Interfaz>>

ModelFactory

+ getModel(string $fwn) : IModel

<<Interfaz>>

IPermissionCheck

+ assertHasPermission(...) : void

<<Interfaz>>

IModel

<<Interfaz>>

IAuthors

...

<<Interfaz>>

IUser

...

<<Proporciona>>

...

Figura 5.41: Diagrama UML de las interfaces principales



5.4.13 \CMMSE\Interfaces\Models

Este espacio de nombres y sus descendientes contienen las interfaces esperadas para los modelos de

la aplicación y que son usadas para instanciarlos.

<<Interfaz>>

IModel

<<Interfaz>>

IAuthors

...

<<Interfaz>>

IConferences

...

<<Interfaz>>

IInvoices

...

<<Interfaz>>

IPapers

...

<<Interfaz>>

IRooms

...

<<Interfaz>>

ISettings

...

<<Interfaz>>

ITrips

...

<<Interfaz>>

IBilling

...

<<Interfaz>>

IInstrumentation

...

<<Interfaz>>

ILogin

...

<<Interfaz>>

IPayments

...

<<Interfaz>>

ISession

...

<<Interfaz>>

IStats

...

<<Interfaz>>

IUser

...

Figura 5.42: Diagrama UML general de las interfaces de los modelos



IAuthors

Interfaz del modelo de la página del listado de autores.

5.4.13.1.1 Métodos

public function getList(\CMMSE\Interfaces\Models\IPapers $paperModel,

\CMMSE\Interfaces\Models\IUser $userModel) :\CMMSE\Decorators\Autor[]

Obtiene la lista de autores utilizando los métodos de las instancias de los modelos de papers y

usuarios proporcionadas.

<<Interfaz>>

IModel

<<Interfaz>>

IAuthors

+ getList(IPapers $paperModel,IUser $userModel) : \CMMSE\Decorators\Autor[]

Autor User

<< Proporciona >>

Figura 5.43: Diagrama UML de la interfaz del modelo del listado de autores



IBilling

Interfaz del modelo con las operaciones de facturación.

5.4.13.2.1 Métodos

public function setUserBillFile(integer $user_id, string $filename) : boolean

Asocia el nombre de archivo dado como justificante de pago del usuario asociado al

identificador proporcionado.

public function setUserFees(integer $user_id, integer $cuota) : boolean

Actualiza la cuota a pagar por el usuario asociado al identificador proporcionado.

public function setBillPrintFlag(integer $user_id, boolean $flag) : boolean

Actualiza el flag que indica si la factura del usuario asociado al identificador proporcionado está

lista para imprimirse.

public function setUserBillInfo(integer $user_id, string $company. string $address, string $cif,

boolean $red, string $billname) : boolean

Actualiza la información de facturación del usuario asociado al identificador proporcionado.

Exceptuando el identificador de usuario y el flag de pertenencia a la red, cualquier parámetro

pasado como null hará que la información correspondiente existente sea borrada de la base

de datos (pasando a tomar el valor por defecto).

public function createUserBillingInfo(integer $user_id) : boolean

Crea los datos de facturación vacíos (por defecto) para el usuario asociado al identificador

proporcionado. Es utilizado durante el registro de usuarios.

public function deleteUserBillingInfo(integer $user_id) : boolean

Elimina los datos de facturación del usuario asociado al identificador proporcionado, si existen.

Es utilizado durante el borrado de usuarios.

public function updateBillNumberRed(integer $user_id, integer $billno) : boolean

Actualiza el número de factura emitida por el patrocinador para el usuario indicado. Si se pasa

null como número de factura, se elimina el número de factura del patrocinador asociado al

usuario, en caso de existir.

public function updateBillRedFlag(integer $user_id, boolean $flag) : boolean

Actualiza el flag que indica que un usuario pertenece a la red, es decir, si el patrocinador cubre

toda o parte de su cuota de inscripción.

public function getUserBillingInfo(integer $user_id) : \CMMSE\Doctrine\UserBillingInfo

Obtiene la información de facturación del usuario indicado.

public function getUsersThatHavePaid ([integer $typeuser]) : mixed[][]

Retorna una lista de arrays asociativos con la información de los usuarios que han pagado. Si

se indica un tipo de usuario, el array devuelto solo incluirá a los usuarios del tipo indicado.



public function getUsersNeedingInvoice(boolean $pago) : mixed[][]

Retorna una lista de arrays asociativos con la información de los usuarios que han solicitado

factura. Si se asigna el valor cierto a su parámetro, solo retorna la información de los usuarios

cuyo pago haya sido confirmado.

public function getUsersPendingBillRedNumberFromSpain() :

\CMMSE\Doctrine\UserBillingInfo[]

Retorna una lista con la información de facturación de los usuarios de España de tipo ponente,

con CIF y compañía asignados, pertenecientes a la red, que hayan pagado y que no tengan aún

asignado un número de factura de la red.

public function getUsersWithUnassignedBillNumberFromSpain() :


Retorna una lista con la información de facturación de los usuarios de España de tipo ponente,

con CIF y compañía asignados, que hayan pagado y que no tengan aún asignado un número de

factura.

public function getUsersWithUnassignedBillNumberNotFromSpain() :


Retorna una lista con la información de facturación de los usuarios de fuera de España de tipo

ponente, con CIF y compañía asignados, que hayan pagado y que no tengan aún asignado un

número de factura.

public function getUsersWithAssignedBillNumber([boolean $billprint]) : mixed[][]

Retorna una lista de arrays asociativos con la información de facturación de los usuarios de tipo

ponente, con CIF y compañía asignados, que tengan asignado un número de factura y,

opcionalmente, cuyas facturas estén marcadas como listas para imprimir.

public function updateBillNumber(integer $iduser, integer $billnumber) : boolean

Actualiza el número de factura asociado al usuario con el identificador dado.

public function getBillingInfoByBillNumber(integer $billnumber) :

\CMMSE\Doctrine\UserBillingInfo

Obtiene la información de facturación de un usuario cuyo número de factura asignado coincida

con el número dado. En caso de no existir un usuario con el número de factura indicado, se

retorna null.

public function setPaidFlag(integer $iduser, boolean $paid) : boolean

Cambia el valor del flag que indica si el pago del usuario indicado ha sido confirmado.

public function getPaidFlag(integer $iduser) : boolean

Obtiene el valor del flag que indica si el pago del usuario indicado ha sido confirmado.

public function deleteBillNumber(integer $iduser) : boolean

Borra (poniendo a null) el número de factura asignado al usuario indicado.



<<Interfaz>>

IModel

<<Interfaz>>

IBilling

+ setUserBillFile(integer $user_id, string $filename) : boolean

UserBillingInfo

<< Proporciona >>

+ setBillPrintFlag(integer $user_id, boolean $flag) : boolean+ setUserFees(integer $user_id, integer $cuota) : boolean

+ createUserBillingInfo(integer $user_id) : boolean

+ setUserBillInfo(integer $user_id, string $company, string $address, string $cif, boolean $red, string $billname) : boolean

+ deleteUserBillingInfo(integer $user_id) : void

+ updateBillRedFlag(insteger $user_id, boolean $flag) : boolean

+ updateBillNumberRed(integer $user_id, integer $billno) : boolean

+ getUserBillingInfo(integer $user_id) : \CMMSE\Doctrine\UserBillingInfo+ getUsersThatHavePaid([integer $typeuser]) : mixed[][]

+ getUsersPendingBillRedNumberFromSpain() : \CMMSE\Doctrine\UserBillingInfo[]

+ getUsersNeedingInvoice([boolean $pago]) : mixed[][]

+ getUsersWithUnassignedBillNumberFromSpain() : \CMMSE\Doctrine\UserBillingInfo[]+ getUsersWithUnassignedBillNumberNotFromSpain() : \CMMSE\Doctrine\UserBillingInfo[]+ getUsersWithAssignedBillNumber([boolean $billprint]) : mixed[][]+ updateBillNumber(integer $user_id, integer $billno) : boolean

+ deleteBillNumber(integer $user_id) : boolean

+ getBillingInfoByBillNumber(integer $billno) : \CMMSE\Doctrine\UserBillingInfo+ setPaidFlag(integer $user_id, boolean $paid) : boolean+ getPaidFlag(integer $user_id) : boolean

Figura 5.44: Diagrama UML de la interfaz del modelo de gestión de facturacion



IConferences

Interfaz del modelo con las operaciones de gestión de los simposios.

5.4.13.3.1 Métodos

public function addConference(string $title) : \CMMSE\Doctrine\Conference

Crea un nuevo simposio con el título dado y retorna una referencia al objeto que lo representa.

public function editTitle(integer $conference_id, string $title) : \CMMSE\Doctrine\Conference

Cambia el título del simposio con el identificador proporcionado y retorna una referencia al

objeto que lo representa. En caso de no existir un simposio con el identificador dado este

método no hace nada y retorna null.

public function editBeginDate(integer $conference_id, \DateTime $new_date) :

\CMMSE\Doctrine\Conference

Cambia la fecha y hora de inicio del simposio con el identificador proporcionado y retorna una

referencia al mismo. En caso de no existir un simposio con el identificador dado este método

no hace nada y retorna null.

public function deleteConference(integer $conference_id) : void

Elimina del simposio con el identificador proporcionado. En caso de no existir un simposio con

el identificador dado este método no hace nada.

public function getConferenceList() : \CMMSE\Decorators\Conference[]

Obtiene una lista con la información de todos los simposios existentes en la base de datos.

public function getConference(integer $id) : \CMMSE\Doctrine\Conference

Obtiene un objeto que representa el simposio asociado al identificador proporcionado. En caso

de no existir un simposio con el identificador dado este método retorna null.

public function getConferenceDecorator(integer $id) : \CMMSE\Decorators\Conference

Obtiene un decorador con información adicional del simposio asociado al identificador

proporcionado. En caso de no existir un simposio con el identificador dado este método

retorna null.



<<Interfaz>>

IModel

<<Interfaz>>

IConferences

+ addConference(string $name) : \CMMSE\Doctrine\Conference

Conference

<< Proporciona >>

+ editBeginDate(integer $id, \DateTime $new_date) : \CMMSE\Doctrine\Conference

+ editTitle(integer $id, string $name) : \CMMSE\Doctrine\Conference

+ getConference(integer $id) : \CMMSE\Doctrine\Conference+ deleteConference(integer $id) : void

+ getConferenceDecorator(integer $id) : \CMMSE\Decorators\Conference

Conference

+ getConferenceList() : \CMMSE\Decorators\Conference[]

Figura 5.45: Diagrama UML de la interfaz del modelo de gestión de simposios



IInstrumentation

Interfaz del modelo con las operaciones de recolección de datos de instrumentación

5.4.13.4.1 Métodos

public function saveData() : void

Guarda información estadística relativa a la solicitud actual.

public function saveStartTime () : void

Guarda el instante actual como el de inicio de la solicitud actual.

<<Interfaz>>

IModel

<<Interfaz>>

IInstrumentation

+ saveData() : void+ saveStartTime() : void

Figura 5.46: Diagrama UML de la interfaz del modelo de instrumentación

IInvoices

Interfaz del modelo con las operaciones para listar justificantes y facturas.

5.4.13.5.1 Métodos

public function getExtension(string $filename) : string

Obtiene la extensión de un archivo a partir de su nombre.

public function getAll(integer $default_fees) : \CMMSE\Doctrine\UserBillingInfo[]

Obtiene la información de facturación de todos los ponentes.



public function getProofs(integer $default_fees) : \CMMSE\Doctrine\UserBillingInfo[]

Obtiene la información de facturación de todos los ponentes que no han solicitado factura.

public function getInvoices(integer $default_fees) : \CMMSE\Doctrine\UserBillingInfo[]

Obtiene la información de facturación de todos los ponentes que han solicitado factura.

public function getUserInvoice(integer $user_id, integer $default_fees) : object

Obtiene la información de facturación de un ponente a partir de su identificador de usuario.

<<Interfaz>>

IModel

<<Interfaz>>

IInvoices

+ getExtension() : string

UserBillingInfo

<< Proporciona >>

+ getAll(integer $default_fees) : \CMMSE\Doctrine\UserBilingInfo[]

+ getInvoices(integer $default_fees) : \CMMSE\Doctrine\UserBilingInfo[]

+ getProofs(integer $default_fees) : \CMMSE\Doctrine\UserBilingInfo[]

+ getUserInvoice(integer $user_id, integer $default_fees) : object

Figura 5.47: Diagrama UML de la interfaz del modelo del listado de facturas y justificantes



ILogin

Interfaz del modelo con las operaciones de validación de credenciales de inicio de sesión de los

usuarios.

5.4.13.6.1 Métodos

public function setSessionUser(mixed[] &$sessoinData, \CMMSE\Doctrine\User $user) : void

Asocia el usuario indicado a una sesión.

public function logout(midex[] &$sessionData) : void

Asocia el identificador del usuario anónimo (no autentificado) a la sesión proporcionada.

public function hasCredetials(midex[] &$post) : boolean

Comprueba si se han proporcionado los datos necesarios para la autentificación.

public function getUserForCredentials(mixed[] &$post) : \CMMSE\Doctrine\User

Comprueba que las credenciales proporcionadas corresponden a un usuario existente,

devolviendo una instancia del mismo en caso afirmativo.



<<Interfaz>>

IModel

<<Interfaz>>

ILogin

+ setSessionUser(mixed[] &$sessionData, \CMMSE\Doctrine\User $user) : void

User

<< Proporciona >>

+ hasCredentials(string[] $post) : boolean+ logout(midex[] &$sessionData) : void

+ getUserForCredentials(string[] $post) : \CMMSE\Doctrine\User

Figura 5.48: Diagrama UML de la interfaz del modelo de inicio de sesión



IPapers

Interfaz del modelo con las operaciones de gestión de los papers.

5.4.13.7.1 Métodos

public function getPapersLocalPath() : string

Obtiene la ruta absoluta del directorio del servidor donde se almacenan los papers enviados.

public function setPaperDates(integer $paper_id, \DateTime $start, \DateTime $end) : boolean

Guarda el rango de fechas de exposición de un poster.

public function setPaperRoom(integer $paper_id[, \CMMSE\Doctrine\Room $r]) : boolean

Modifica o elimina la asociación de un paper de tipo poster y la sala donde se expone.

public function getPaperPosterInfo(integer $paper_id) : \CMMSE\Doctrine\Poster

Obtiene la información adicional (fechas y sala) asociada a los papers de tipo poster.

public function getPosterCountForUser(integer $user_id) : integer

Obtiene el número de posters enviados por un ponente a partir de su identificador de usuario.

public function getPaperCountForUser(integer $user_id) : integer

Obtiene el número de papers enviados por un ponente, incluidos los posters, a partir de su

identificador de usuario.

public function setAcceptedFlag(integer $paper_id, boolean $accepted) : boolean

Marca o desmarca un paper como aceptado.

public function setDecisionFlag(integer $paper_id, boolean $decision) : boolean

Marca o desmarca un paper como en proceso de revisión.

public function getAcceptedPapers([integer $user_id]) : string[][]

Obtiene la lista de papers aceptados, completa o para un usuario determinado, como arrays

de cadenas de texto.

public function deleteUserPapersFromDB(integer $user_id) : void

Elimina los registros asociados a los papers enviados por el usuario indicado de la base de datos.

Los archivos enviados se mantienen en el servidor.

public function getPaperTitlesForUser(integer $user_id) : string[]

Obtiene una lista con los títulos de los papers enviados por el usuario indicado.

public function getPaperListForUser(integer $user_id) : object[][]

Obtiene la lista de papers enviados por el usuario indicado como arrays de cadenas de texto.

public function getUserPaper(integer $paper_id, integer $user_id) : string[]

Obtiene la información de un paper como arrays de cadenas de texto a partir de su

identificador y el del usuario que lo envió.



public function getUserPaperByTitle(integer $user_id, string $title) :

\CMMSE\Doctrine\Paper[]

Obtiene la información de los papers de un usuario determinado a partir de su identificador de

usuario y del título del mismo. La comparación con el título se realiza utilizando el operador

SQL LIKE.

public function getPapersByTitle(string $title) : \CMMSE\Doctrine\Paper[]

Obtiene la información de los papers cuyo título coincida el título dado. La comparación con el

título se realiza utilizando el operador SQL LIKE.

public function getPaper(integer $paper_id) : \CMMSE\Doctrine\Paper

Obtiene la información de un paper como un objeto a partir de su identificador.

public function setPaperTitle(integer $paper_id, string $title) : void

Cambia el título del paper indicado.

public function resetNewPaperFilename(integer $paper_id, integer $user_id) : void

Borra el valor del campo que almacena el nombre de archivo del último envío del paper

indicado.

public function setNewPaperFilename(integer $paper_id, integer $user_id, string $filename) :

boolean

Cambia el valor del campo que almacena el nombre de archivo del último envío del paper

indicado.

public function setPaperFilename(integer $paper_id, integer $user_id, string $filename) :

boolean

Cambia el valor del campo que almacena el nombre de archivo del primer envío del paper

indicado.

public function insertNewPaper(integer $user_id, integer $conference_id, string $filename,

string $fecha, boolean $poster, string[] $authors, integer &$paper_id) :

\CMMSE\Doctrine\Paper

Almacena los datos de un nuevo paper en la base de datos.

public function deletePaper(integer $paper_id, integer $user_id) : boolean

Elimina un paper dado su identificador y el del usuario que lo envió.

public function getPosterList([boolean $accepted]) : \CMMSE\Decorators\Poster[]

Obtiene la lista de posters, opcionalmente filtrados por estado (aceptados o no).

public function getPaperList() : \CMMSE\Doctrine\Paper[]

Obtiene la lista con todos los papers de la base de datos.

public function getDecoratorList() : \CMMSE\Decorators\Paper[]

Obtiene la lista con todos los papers de la base de datos envueltos en decoradores.



<<Interfaz>>

IModel

<<Interfaz>>

IPapers

+ getPapersLocalPath() : string

Paper

<< Proporciona >>

+ setPaperRoom(integer $paper_id, \CMMSE\Doctrine\Room $r) : boolean

+ setPapersDates(integer $paper_id, \DateTime $start, \DateTime $end) : boolean

+ getPosterCountForUser(integer $user_id) : integer

+ getPaperPosterInfo(integer $paper_id) : \CMMSE\Doctrine\Poster

+ getPaperCountForUser(integer $user_id) : integer

+ setDecisionFlag(integer $paper_id, boolean $flag) : boolean+ setAcceptedFlag(integer $paper_id, boolean $flag) : boolean

+ getAcceptedPapers([integer $user_id]) : string[][]+ deleteUserPapersFromDB(integer $user_id) : void

+ getPaperListForUser([integer $user_id]) : object[]+ getPaperTitlesForUser(integer $user_id) : string[]

+ getUserPaper(integer $paper_id, integer $user_id) : string[]+ getUserPaperByTitle(integer $user_id, string $title) : \CMMSE\Doctrine\Paper[]+ getPapersByTitle(string $title) : \CMMSE\Doctrine\Paper[]+ getPaper(integer $paper_id) : \CMMSE\Doctrine\Paper

+ setPaperFilename(integer $paper_id, string $filename) : boolean

+ setPaperTitle(integer $paper_id, string $title) : void+ resetNewPaperFilename(integer $paper_id, integer $user_id) : void+ setNewPaperFilename(integer $paper_id, integer $user_id, string $filename) : boolean

Poster Poster Paper

+ insertNewPaper(integer $user_id, integer $conference_id, string $filename, string $fecha, boolean $poster, string[] $authors, integer &$paper_id) : \CMMSE\Doctrine\Paper

+ getDecoratorList() : \CMMSE\Decorators\Paper[]

+ deletePaper(integer $paper_id, integer $user_id) : boolean+ getPosterList[boolean $accepted]) : \CMMSE\Decorators\Poster[]+ getPaperList() : \CMMSE\Doctrine\Paper[]

Figura 5.49: Diagrama UML de la interfaz del modelo de gestión de papers



IPayments

Interfaz del modelo con las operaciones de gestión de la configuración de pagos.

5.4.13.8.1 Métodos

public function getWritelock() : void

Obtiene un bloqueo exclusivo de escritura sobre los datos de configuración de pagos22.

public function releaseWritelock() : void

Libera un bloqueo exclusivo de escritura sobre los datos de configuración de pagos adquirido

previamente.

public function getPaymentSettings() : \CMMSE\Doctrine\PaymentSettings

Obtiene los datos de configuración de los pagos.

public function setPaymentSettings(\CMMSE\Doctrine\PaymentSettings $settings) :

\CMMSE\Doctrine\PaymentSettings

Modifica la configuración de pagos a partir de los datos proporcionados, y libera cualquier

bloqueo exclusivo de escritura que pudiese haber sobre éstos.

22 Utilizado para evitar condiciones de carrera en caso de que varias sesiones de administrador soliciten de forma simultánea la asignación automática de números de factura para aquellas que no lo tengan asignado aún.



<<Interfaz>>

IModel

<<Interfaz>>

IPayments

+ getWriteLock() : void

PaymentSettings

<< Proporciona >>

+ getPaymentSettings() : \CMMSE\Doctrine\PaymentSettings+ releaseWriteLock() : void

+ setPaymentSettings(\CMMSE\Doctrine\PaymentSettings $settings) : \CMMSE\Doctrine\PaymentSettings

Figura 5.50: Diagrama UML de la interfaz del modelo de gestión de pagos



IRooms

Interfaz del modelo con las operaciones de gestión de salas.

5.4.13.9.1 Métodos

public function createRoom(string $name) : integer

Crea una nueva sala con el nombre indicado y retorna su identificador.

public function setRoomName(integer $id, string $name) : void

Edita el nombre de una sala existente.

public function deleteRoom(integer $id) : void

Elimina una sala existente.

public function getRoomList() : \CMMSe\Doctrine\Room[]

Obtiene la lista de salas existentes.

public function getRoom(integer $id) : \CMMSE\Doctrine\Room

Obtiene los datos de una sala existente a partir de su identificador.

public function getExtendedRoomInfo(\CMMSE\Doctrine\Room $room) :

\CMMSE\Decorators\Room

Obtiene un decorador con datos adicionales sobre el número de posters de una sala existente.



<<Interfaz>>

IModel

<<Interfaz>>

IRooms

+ createRoom(string $name) : integer

Room

<< Proporciona >>

+ deleteRoom(integer $id) : void+ setRoomName(integer $id, string $name) : void

+ getRoom(integer $id) : \CMMSE\Doctrine\Room+ getRoomList() : \CMMSE\Doctrine\Room[]

+ getRoomExtendedInfo(\CMMSE\Doctrine\Room $room) : \CMMSE\Decorators\Room

Room

Figura 5.51: Diagrama UML de la interfaz del modelo de gestión de salas



ISession

Interfaz del modelo con las operaciones de gestión de las sesiones de usuario.

5.4.13.10.1 Métodos

public function startSession() : void

Inicia una sesión nueva o continúa una existente.

<<Interfaz>>

ISession

+ startSession() : void

Session

<< Usa >>

<<Interfaz>>

SessionHandlerInterface

<<Interfaz>>

IModel

Figura 5.52: Diagrama UML de la interfaz del modelo de gestión de sesiones



ISettings

Interfaz del modelo con las operaciones de gestión de la configuración.

5.4.13.11.1 Métodos

public function getSettings() : \CMMSE\Doctrine\Settings

Obtiene la configuración del sitio almacenada en la base de datos.

public function setSettings(\CMMSE\Doctrine\Settings $settings) : void

Guarda en la base de datos la configuración del sitio.

public function getMailSettings() : \CMMSE\Doctrine\MailerSettings

Obtiene la configuración de envío de correos almacenada en la base de datos.

public function setMailSettings(\CMMSE\Doctrine\MailerSettings $settings) : void

Guarda la configuración de envío de correos almacenada en la base de datos.

public function getTipoEtiqueta() : integer

Obtiene el tipo de etiqueta configurado.

public function setPlazo(boolean $cerrado) : boolean

Abre o cierra el plazo de envío de papers.

public function setRedSettings(string $name, string $company, string $address, string $cif) :

boolean

Modifica la configuración relativa al patrocinador de la conferencia.

public function setMail([string[] $mail]) : boolean

Modifica la lista de direcciones de correo a las que enviar las notificaciones.

public function setDBOpen(boolean $open) : boolean

Habilita o deshabilita el registro de usuarios.



<<Interfaz>>

IModel

<<Interfaz>>

ISettings

+ getSettings() : \CMMSE\Doctrine\Settings

Settings

<< Proporciona >>

+ getMailSettings() : \CMMSE\Doctrine\MailerSettings+ setSettings(\CMMSE\Doctrine\Settings $settings) : void

+ getTipoEtiqueta() : integer

+ setMailSettings(\CMMSE\Doctrine\MailerSettings $settings) : void

+ setPlazo(boolean $cerrado) : boolean

MailerSettings

+ setRedSettings(string $name, string $company, string $address, string $cif) : boolean+ setMail([string[] $mail]) : boolean+ setDBOpen(boolean $open) : boolean

Figura 5.53: Diagrama UML de la interfaz del modelo de configuración



IStats

Interfaz del modelo con las operaciones de obtención de los datos de la página de estadísticas del

panel de administración.

5.4.13.12.1 Métodos

public function getCountryRatios() : integer[]

Obtiene el número de asistentes de cada país, retornándolo como un array de enteros

indexado por el nombre del mismo.

public function getValues(\CMMSE\Doctrine\PaymentSettings &$payments) :

\CMMSE\Core\OverviewData

Retorna un conjunto de datos estadísticos básicos sobre los ingresos, los usuarios y los papers

del congreso.

<<Interfaz>>

IModel

<<Interfaz>>

IStats

+ getCountryRatios() : integer[]

OverviewData

<< Proporciona >>

+ getValues(\CMMSE\Doctrine\PaymentSettings $settings) : \CMMSE\Core\OverviewData

Figura 5.54: Diagrama UML de la interfaz del modelo de gestión de estadísticas



ITrips

Interfaz del modelo con las operaciones de gestión de excursiones.

5.4.13.13.1 Métodos

public function createTrip(string $name) : integer

Crea una nueva excursión a partir de su nombre descriptivo y retorna su identificador.

public function setTripName(integer $id, string $name) : void

Edita el nombre de una excursión existente.

public function deleteTrip(integer $id) : void

Elimina una excursión existente.

public function getTripList() : \CMMSe\Doctrine\Trip[]

Obtiene la lista de excursiones existentes.

public function getTrip(integer $id) : \CMMSE\Doctrine\Trip

Obtiene los datos de una excursión existente a partir de su identificador.

<<Interfaz>>

IModel

<<Interfaz>>

ITrips

+ createTrip(string $name) : integer

Trip

<< Proporciona >>

+ deleteTrip(integer $id) : void+ setTripName(integer $id, string $name) : void

+ getTrip(integer $id) : \CMMSE\Doctrine\Trip+ getTripList() : \CMMSE\Doctrine\Trip[]

Figura 5.55: Diagrama UML de la interfaz del modelo de gestión de excursiones



IUser

Interfaz del modelo con las operaciones de gestión de usuarios.

5.4.13.14.1 Métodos

public function getTitles() : string[]

Obtiene la lista de títulos honoríficos almacenados en la base de datos como cadenas de texto.

public function getRandomPasowrd() : string

Obtiene una contraseña aleatoria.

public function testUserPassword(integer $user_id, string $password) : boolean

Comprueba si una contraseña coincide con la del usuario correspondiente al identificador

proporcionado.

public function setUserPassword(integer $user_id, string $password) : boolea

Modifica la contraseña del usuario correspondiente al identificador proporcionado.

public function listUsers([integer $type]) : mixed[][]

Obtiene la lista de usuarios como arrays de valores escalares, opcionalmente filtrada por tipo.

public function fetchUserEntityByEMail(string $email) : \CMMSE\doctrine\User

Obtiene la información asociada al usuario asociado a la dirección de correo electrónico

proporcionada.

public function updateUser(integer $userid, string $firstName, string $lastName, string

$company, string $address, string $person_title, string $country, string $state, string

$city, string $postalcode, string $telephone) : boolean

Modifica la información de un usuario.

public function getUserObj(integer $id) : \CMMSE\Doctrine\User

Obtiene información del usuario con el identificador indicado.

public function getUsers(integer[] $ids) : \CMMSE\Doctrine\User[]

Obtiene información de los usuarios con los identificadores indicados.

public function getSpeakers() : \CMMSE\Doctrine\User[]

Obtiene la lista de ponentes.

public function deleteUserFromDB(integer $user_id) : void

Elimina la información del usuario indicado de la base de datos.

public function insertUser(mixed[] $post) : integer

Registra la información de un nuevo en la base de datos. Esta función no crea una entrada de

facturación asociada al usuario.



<<Interfaz>>

IModel

<<Interfaz>>

IUser

+ getTitles() : string[]

User

<< Proporciona >>

+ testUserPassword(integer $user_id, string $password) : boolean+ getRandomPassword() : string

+ listUsers([integer $type]) : mixed[]+ setUserPassword(integer $user_id, string $password) : boolean

+ fetchUserEntityByEMail(string $email) : \CMMSE\Doctrine\User

+ insertUser(string[] $post) : integer

+ updateUser(integer $id, string $firstName, string $lastName, string $company, string address, string $person_title, string $country, string $state, string $city, string $postalcode, string $telephone) : boolean

+ deleteUserFromDB(integer $user_id) : void+ getSpeakers() : \CMMSE\Doctrine\User[]

+ getUserObj(integer $id) : \CMMSE\Doctrine\User+ getUsers(integer[] $ids) : \CMMSE\Doctrine\User[]

Figura 5.56: Diagrama UML de la interfaz del modelo de gestión de usuarios



5.4.14 \CMMSE\Permissions

Este espacio de nombres contiene clases utilizadas para realizar comprobaciones de permisos.

Admin

Implementa la comprobación de permisos para las páginas de administración.

5.4.14.1.1 Métodos

public function assertHasPerission(mixed[] $session_data, \CMMSE\Interfaces\Models\IUser

&$userModel) : void

Comprueba que la sesión proporcionada corresponde a un usuario identificado con permisos

administrativos. En caso de no ser así lanza una excepción de tipo UnauthenticatedException

o ForbiddenException del espacio de nombres \CMMSE\Exceptions.

<<Interfaz>>

IPermissionCheck


Admin


Figura 5.57: Diagrama UML de la clase que comprueba si la sesión posee permisos administrativos



5.4.15 \CMMSE\Models

Este espacio de nombres contiene los modelos de la aplicación, implementados a partir de las

interfaces de \CMMSE\Interfaces\Models.

Autores

Implementación del modelo utilizado en la página del listado de autores.

5.4.15.1.1 Métodos

Los métodos proporcionados por este modelo y su semántica se corresponden con los de su interfaz,

\CMMSE\Interfaces\Models\IAuthors.

Conferencias

Implementación del modelo con las operaciones de gestión de los simposios.

5.4.15.2.1 Métodos


\CMMSE\Interfaces\Models\IConferences.

Facturacion

Implementación del modelo con las operaciones de facturación.

5.4.15.3.1 Métodos


\CMMSE\Interfaces\Models\IBilling.

Facturas

Implementación del modelo con las operaciones de obtención de datos de facturas y justificantes de

pago.


protected static $allowed_extensions: string[]

Lista de extensiones de archivo válidas para los justificantes enviados por los usuarios.

5.4.15.4.2 Métodos


\CMMSE\Interfaces\Models\IInvoices.



Instrumentation

Implementación del modelo utilizado para recolectar datos de instrumentación.

5.4.15.5.1 Métodos


\CMMSE\Interfaces\Models\IInstrumentation.

Login

Implementación del modelo con las operaciones de validación de credenciales de inicio de sesión de

los usuarios.

5.4.15.6.1 Métodos


\CMMSE\Interfaces\Models\ILogin.

Papers

Implementación del modelo con las operaciones de gestión de papers.

5.4.15.7.1 Métodos


\CMMSE\Interfaces\Models\IPapers.

Payments

Implementación del modelo con las operaciones de gestión de la configuración de pagos.


protected $row_id: integer

Identificador de la fila de la base de datos que contiene la configuración de pagos.

5.4.15.8.2 Métodos


\CMMSE\Interfaces\Models\IPayments.



Rooms

Implementación del modelo con las operaciones de gestión de salas.

5.4.15.9.1 Métodos


\CMMSE\Interfaces\Models\IRooms.

Session

Implementación del modelo con las operaciones de gestión de sesiones de usuario. Los datos de las

sesiones se almacenan en la base de datos.

5.4.15.10.1 Métodos

Los métodos proporcionados por este modelo y su semántica se corresponden con los de sus interfaes,

\CMMSE\Interfaces\Models\ISession y \SessionHandler.

Settings

Implementación del modelo con las operaciones de gestión de la configuración.

5.4.15.11.1 Métodos


\CMMSE\Interfaces\Models\ISettings.

Stats

Implementación del modelo con las operaciones de obtención de los datos de la página de estadísticas

del panel de administración.

5.4.15.12.1 Métodos


\CMMSE\Interfaces\Models\IStats.

Trips

Implementación del modelo con las operaciones de gestión de las excursiones.

5.4.15.13.1 Métodos


\CMMSE\Interfaces\Models\ITrips.



User

Implementación del modelo con las operaciones de gestión de usuarios.

5.4.15.14.1 Métodos


\CMMSE\Interfaces\Models\IUser.

5.4.16 \CMMSE\Models\Factories

Este espacio de nombres contiene las factorías usadas internamente por los controladores para

instanciar los modelos.

La implementación actual contiene una única factoría en este espacio de nombres, siendo posible en

futuras ampliaciones añadir factorías alternativas y/o factorías que hereden y extiendan la actual. De

esta forma se permite, de un modo sencillo, modificar la aplicación para utilizar implementaciones

alternativas de los modelos que aumenten el rendimiento y/o añadan soporte para otros almacenes

de datos: mecanismos de caché de datos (APC, Memcached…), almacenamiento de las entidades en

un gestor de bases de datos distinto de MySQL, uso de gestores de datos NoSQL, almacenamiento

selectivo de entidades en bases de datos o archivos independientes23, características de versionado de

los datos…

ModelFactory

Implementación de la factoría encargada de proporcionar instancias de los modelos a los

controladores.

5.4.16.1.1 Métodos

public static function getModel(string $modelInterface) : \CMMSE\Core\AbstractModel

Obtiene una instancia de un modelo a partir del FQN de su interfaz.

23 Por ejemplo, se podrían almacenar los datos de instrumentación en ficheros en lugar de en la base de datos.



<<Interfaz>>

IAuthors

...

<<Interfaz>>

IUser

...

Autores

...

User

...

ModelFactory

+ getModel(string $fqn)

AbstractController

# getModel($fqn)

Login Calendar

<<Interfaz>>

ModelFactory

+ getModel(string $fqn)

...

...

...

...

...

BBDD

Figura 5.58: Diagrama UML de la factoría de modelos



5.4.17 \CMMSE\Controllers

Este espacio de nombres y sus descendientes contienen los controladores de la aplicación. En este

espacio de nombres raíz se encuentran los controladores de las partes de la aplicación accesibles sin

necesidad de autenticación y el controlador de las páginas de los editores.

Calendar Download

Editor Login

Recover Signup

Controller

<<Interfaz>>

onConstruct


Figura 5.59: Diagrama UML de los controladores de las acciones de invitado y editores



Calendar

Implementación del controlador para la descarga de calendarios iCal. Los calendarios son generados

asumiendo que las fechas y horas almacenadas de la base de datos están escritas para la zona horaria

española (Europe/Madrid, con un incremento de 2 horas respecto a UTC-DST).


protected $conferenceModel : \CMMSE\Interfaces\Models\IConferences

Referencia al modelo de gestión de conferencias utilizado.

protected $papersModel : \CMMSE\Interfaces\Models\IPapers

Referencia al modelo de gestión de papers utilizado.

protected $userModel : \CMMSE\Interfaces\Models\IUser

Referencia al modelo de gestión de usuarios utilizado.

5.4.17.1.2 Métodos


Método invocado al crear nuevas instancias de la clase, encargado de inicializar las instancias

de los modelos utilizados por el controlador.

public function action_conferences() : string

Genera una respuesta en formato iCal con el calendario de conferencias, enviando, además,

los encabezados que indican el tipo de archivo directamente al cliente.

public function action_posters() : string

Genera una respuesta en formato iCal con el calendario de exposición de los posters, enviando,

además, los encabezados que indican el tipo de archivo directamente al cliente.

Download

Implementación de un controlador para la descarga de los papers enviados desde las páginas de

ponentes.




protected $settingsModel : \CMMSE\Interfaces\Models\ISettings

Referencia al modelo de configuración dinámica utilizado.

protected $papersBaseURI : string

URI base para la descarga de papers.

protected $config : \CMMSE\Core\Configuration

Referencia a la configuración estática de la aplicación.



5.4.17.2.2 Métodos



de los modelos y los atributos utilizados por el controlador.

public function any(string[] $args) : string

Acción invocada al solicitar la descarga de un paper. Este método envía directamente los

encabezados y los datos del archivo solicitado, finalizando tras ello el tratamiento de la solicitud

actual.

Editor

Implementación del controlador encargado de generar los listados de papers para los editores.


protected $conferencesModel : \CMMSE\Interfaces\Models\IConferences






protected $sessionModel : \CMMSE\Interfaces\Models\ISession

Referencia al modelo de gestión de sesiones utilizado.

5.4.17.3.2 Métodos




public function default_action() : \CMMSE\Core\Template

Acción invocada al solicitar el listado de papers para los editores.



Login

Implementación del controlador encargado de gestionar la identificación de usuarios registrados y

administradores.


protected $model : \CMMSE\Interfaces\Models\ILogin

Referencia al modelo de gestión de identificación de usuarios utilizado.





protected $settings : \CMMSE\Doctrine\Settings




5.4.17.4.2 Métodos





Acción invocada al solicitar el formulario de login o al enviar las credenciales de autentificación.

public function action_logout() : \CMMSE\Core\Template

Acción invocada al solicitar la finalización de la sesión de usuario actual.

protected function getPublicClosedPage() : string

Método interno utilizado para generar una página con un mensaje de error, en los casos en los

que el usuario que se identifica no se aun administrador y el acceso a las páginas públicas está

deshabilitado.

protected function getLoginForm([string $error]) : string

Método interno utilizado por la acción por defecto para generar el código HTML del formulario

de login.

protected function getLoginForm([string $error]) : string

Método interno utilizado por la acción por defecto que comprueba los datos de inicio de sesión

proporcionados y redirige o genera la página correspondiente.



Recover

Implementación del controlador encargado de gestionar las solicitudes de restablecimiento de

contraseña.








5.4.17.5.2 Métodos





Acción invocada al solicitar el formulario para introducir los datos de la cuenta cuya contraseña

se solicita restablecer.

public function action_post() : \CMMSE\Core\Template

Acción invocada al enviar los datos de la cuenta de ponente cuya contraseña se solicita

restablecer.

Signup

Implementación del controlador encargado de gestionar las solicitudes de alta de nuevos ponentes.




protected $billingModel : \CMMSE\Interfaces\Models\IBilling

Referencia al modelo de facturación utilizado.







5.4.17.6.2 Métodos





Acción invocada al solicitar y/o enviar el formulario con los datos de la nueva cuenta de

ponente a crear. En caso de estar enviando los datos del formulario y no producirse errores en

la creación de la nueva cuenta, la acción redirige al formulario de login.

protected function sendAdminNotificationEMail(string $firstName, string $lastName, string

$mail) : void

Método interno invocado tras la creación nuevas cuentas de usuario encargado de enviar la

notificación de nuevo usuario registrado a las cuentas de los gestores de la conferencia

configuradas en la aplicación.

protected function sendConfirmationEMail(string $to, string $firstName) : boolean

Método interno invocado tras la creación nuevas cuentas de usuario encargado de enviar el

correo electrónico de confirmación de registro a la cuenta de correo proporcionada por el

usuario. En caso de que haya errores en el envío del el correo por parte de esta función, el

registro del nuevo usuario (iniciado por default_action() )no se lleva a cabo.



5.4.18 \CMMSE\Controllers\User

Este espacio de nombres contiene los controladores de las páginas accesibles para los ponentes

identificados.

AbstractPaperController

Implementación de un controlador base abstracto con la funcionalidad común a todas las páginas de

la sección de papers de las páginas de ponente.




protected $paperModel : \CMMSE\Interfaces\Models\IPapers








5.4.18.1.2 Métodos




protected static function getPostAuthors() : string[]

Método auxiliar para obtener un array con los nombres de autores proporcionados por el

ponente al enviar un nuevo paper.

protected static function getPaperDownloadURL(string $archivo) : string

Método auxiliar para obtener la URL completa de descarga de un paper a partir de su nombre

de archivo, la configuración de la aplicación y el host utilizado para acceder al sitio.

protected static function getPaperLocalPath(string $basename) : string

Método auxiliar para obtener la ruta local del servidor donde se guarda el paper indicado.



Controller

AbstractPaperControllerPaperPlazoCerrado

NewPaper Paper OnePaper

<<Interfaz>>

onConstruct


Figura 5.60: Diagrama UML de los controladores de gestión de papers de las páginas de usuario



Paper

Implementación del controlador para las páginas de la sección de papers de las páginas de ponente.

5.4.18.2.1 Métodos

public function any(array $a) : \CMMSE\Core\Template

Método invocado al solicitar la página de un paper concreto del usuario, encadenando la

solicitud al controlador OnePaper.


Acción invocada al solicitar el formulario de envío de un nuevo paper o seleccionar uno enviado

previamente para su modificación.

public function action_submit_new() : void

Acción invocada al enviar el formulario con los datos de un nuevo paper, encadenando la

solicitud al controlador NewPaper.

NewPaper

Implementación del controlador encargado de gestionar el envío de nuevos papers.

5.4.18.3.1 Métodos

public function default_action() : string

Acción invocada al enviar un nuevo paper. Tras el envío, esta acción envía una notificación a

los administradores y redirige a la lista de papers enviados por el usuario.

public function sendNewPaperNotification(string $correspauthor, string $correspmail, string

$archivo, integer $idconf, string $title, string $author) : void

Método interno encargado de enviar el correo electrónico de notificación de envío de nuevo

paper a los administradores.

OnePaper

Implementación del controlador de gestión de un paper ya enviado en las páginas de usuario.

5.4.18.4.1 Métodos

public function any(array $a) : \CMMSE\Core\Template

Acción invocada al solicitar la página con la interfaz de gestión de un paper enviado

previamente.

public function action_upload(array $a) : void

Acción invocada al enviar un archivo con la nueva versión de un paper. Tras guardar la nueva

versión, este método redirige a la página de gestión del paper.



public function action_delete(array $a) : void

Acción invocada al solicitar la eliminación de un paper. Tras la eliminación, este método

redirige a la lista de papers del usuario.

protected function doSaveNewPaper(integer $paper_id, integer $user_id, string

$original_filename, string $localpath) : void

Método interno encargado de guardar los archivos enviados y actualizar los datos del paper en

la base de datos.

protected function doUserPaperDeletion(integer $user_id, integer $paper_id) : void

Método interno encargado de eliminar los archivos asociados a un paper enviado previamente,

actualizar los datos de la base de datos y enviar notificaciones de ello a los administradores.

protected function sendNewPaperSubmitNotification(string $correspauthor, string

$correspemail, string $archivo) : void

Método interno encargado de enviar las notificaciones del envío de un nuevo paper a los

administradores.

PaperPlazoCerrado

Implementación del controlador encargado de mostrar una página informativa a los ponentes al entrar

en la sección de papers cuando el envío de éstos está deshabilitado.



Referencia al modelo de gestión de simposios utilizado.











5.4.18.5.2 Métodos







Acción encargada de mostrar una página a los usuarios informando de que el plazo de envío

de papers ha finalizado, impidiendo el envío de nuevos papers y la modificación de los ya

enviados.

public function any(array $args) : \CMMSE\Core\Template

Acción encargada de impedir la modificación de un paper ya existente si el plazo de envío está

cerrado cuando se accede utilizando una URL que incluye el identificador de un paper,

mostrando una página al usuario informando de que el plazo de envío de papers ha finalizado.

Factura

Implementación del controlador para las páginas de la sección de facturas de las páginas de ponente.


protected $invoiceModel : \CMMSE\Interfaces\Models\IInvoices

Referencia al modelo de gestión de facturas utilizado.

protected $facturacionModel : \CMMSE\Interfaces\Models\IBilling

Referencia al modelo de gestión de facturación utilizado.







5.4.18.6.2 Métodos





Acción invocada al solicitar el formulario de envío del justificante de pago.

public function action_delete(array $args) : void

Acción invocada al solicitar la eliminación de los datos de facturación enviados previamente

por el usuario. Tras la eliminación, esta acción redirige a la acción por defecto.

public function action_setbillinfo() : void

Acción invocada al enviar los datos necesarios para emitir una factura para el usuario. Tras ello,

esta acción redirige a la acción por defecto.



public function action_sendinvoice() : void

Acción invocada al enviar el archivo con el justificante del pago del usuario. Este método guarda

el justificante y envía una notificación por correo electrónico a los administradores. Tras ello,

esta acción redirige a la acción por defecto.

UserChange

Implementación del controlador que permite a los ponentes identificados cambiar sus datos de

registro en el congreso.






5.4.18.7.2 Métodos





Acción encargada de generar el formulario enviado a los usuarios para editar sus datos de

registro en el congreso y de recibir los nuevos datos modificados.

protected function handlePost(integer $user_id, string[] $post) : boolean

Método auxiliar usado para actualizar los datos del usuario a partir de los suministrados a

través del formulario de edición.

UserHome

Implementación del controlador raíz de las páginas enviadas a los ponentes identificados previamente

en la aplicación. La labor principal de este controlador es comprobar que la sesión del cliente se

corresponde con un ponente identificado y, en ese caso, redirigir la solicitud al controlador adecuado

según la URI solicitada.












public $user : \CMMSE\Doctrine\User

Referencia a un objeto que representa al usuario identificado en la aplicación. Es utilizado para

exponer su información al resto de controladores, de forma que estos puedan mostrar su

información en las páginas generadas (como su dirección de correo electrónico o enlaces a las

acciones de gestión de su cuenta).

5.4.18.8.2 Métodos





Acción encargada de mostrar una página a los usuarios identificados con enlaces a las distintas

acciones disponibles e información básica sobre su cuenta.

protected function checkCredentials() : void

Método interno para comprobar la información de usuario asociada a la sesión actual y, en

caso de no corresponderse con un usuario identificado, redirigir a la página de login. Este

método es invocado como primer paso en todas las acciones de este controlador.

public function action_paper(array $args) : \CMMSE\Core\Template

Acción invocada al solicitar las páginas de gestión de papers, encadenando la solicitud al

controlador de usuarios Paper.

public function action_invoice (array $args) : \CMMSE\Core\Template

Acción invocada al solicitar las páginas de gestión de pagos, encadenando la solicitud al

controlador de usuarios Factura.

public function action_setpassword(array $args) : \CMMSE\Core\Template

Acción invocada al solicitar las páginas de cambio de contraseña, encadenando la solicitud al

controlador de usuarios UserPass.

public function action_change (array $args) : \CMMSE\Core\Template

Acción invocada al solicitar las páginas de cambio de datos de usuario, encadenando la solicitud

al controlador de usuarios UserChange.



UserPass

Implementación del controlador encargado de mostrar el formulario para cambiar la contraseña en las

páginas de ponentes.






5.4.18.9.2 Métodos





Acción encargada de mostrar una página a los usuarios identificados con un formulario para

cambiar la contraseña de su cuenta.

UserChange UserHome UserPass Factura

Controller

Figura 5.61: Diagrama UML de los controladores de gestión de perfil de las páginas de usuario



5.4.19 \CMMSE\Controllers\Admin

Este espacio de nombres contiene los controladores de las páginas accesibles para los administradores

identificados previamente.

AdminController

Implementación del controlador raíz de las páginas de administración. La labor principal de este

controlador es comprobar que la sesión del cliente se corresponde con un administrador identificado

y, en ese caso, “encaminar” la solicitud al controlador adecuado según la URI solicitada.




protected $sesessionModel : \CMMSE\Interfaces\Models\ISettings


protected $current_tab : string

Indica cual es la sección de administración solicitada al resto de controladores.

5.4.19.1.2 Métodos




public function checkCredentials([boolean $redirect [, boolean $ajax]]) : void

Método interno usado para comprobar si el usuario actual es un administrador y, en caso

contrario dirigir al usuario a la página de login o generar una respuesta JSON de error en

función del tipo de contenido solicitado.

public function getAdminView(string $sectionData) : \CMMSE\Core\Template

Método interno usado para generar las páginas HTML de la interfaz de administración a partir

del contenido HTML generado por los subcontroladores, la plantilla que define el HTML base

de la interfaz, las estadísticas de rendimiento de la solicitud actual y la configuración del sitio.


Acción invocada por defecto cuando no se especifica una subsección del panel de

administración. La implementación actual se comporta como si se hubiese solicitado la sección

de administración de usuarios.

public function action_json(array $args) : string

Acción invocada al solicitar la realización de una acción asíncrona por medio de AJAX. Este

método toma los datos proporcionados por el controlador

\CMMSE\Controllers\Admin\JSONController y los retorna al usuario en formato JSON,

generando, además, el encabezado HTTP necesario de tipo de contenido.



public function action_download(array $args) : string

Acción invocada para generar los archivos de los listados descargables desde el panel de

administración, encadenando la solicitud al controlador \CMMSE\Controllers\Admin

\Download.

public function action_pdfs(array $args) : \CMMSE\Core\PDFResponse

Acción invocada para generar los archivos PDF descargables desde el panel de administración,

encadenando la solicitud al controlador \CMMSE\Controllers\Admin \PDFs.

public function action_users(array $args) : \CMMSE\Core\Template

Acción invocada para generar la interfaz de administración de usuarios, encadenando la

solicitud al controlador \CMMSE\Controllers\Admin \Usuarios.

public function action_justificantes(array $args) : \CMMSE\Core\Template

Acción invocada para generar la interfaz de administración de justificantes de pago,

encadenando la solicitud al controlador \CMMSE\Controllers\Admin \Facturas.

public function action_facturas(array $args) : \CMMSE\Core\Template

Acción invocada para generar la interfaz de administración de facturas, encadenando la

solicitud al controlador \CMMSE\Controllers\Admin \Justificantes.

public function action_conferencias(array $args) : \CMMSE\Core\Template

Acción invocada para generar la interfaz de administración de simposios, encadenando la

solicitud al controlador \CMMSE\Controllers\Admin \Conferencias.

public function action_autores() : \CMMSE\Core\Template

Acción invocada para generar el listado de autores de la interfaz de administración,

encadenando la solicitud al controlador \CMMSE\Controllers\Admin \Autores.

public function action_papers(array $args) : \CMMSE\Core\Template

Acción invocada para generar la interfaz de administración de papers enviados, encadenando

la solicitud al controlador \CMMSE\Controllers\Admin \Papers.

public function action_rooms(array $args) : \CMMSE\Core\Template

Acción invocada para generar la interfaz de administración de salas disponibles, encadenando

la solicitud al controlador \CMMSE\Controllers\Admin \Rooms.

public function action_trips(array $args) : \CMMSE\Core\Template

Acción invocada para generar la interfaz de administración de excursiones, encadenando la

solicitud al controlador \CMMSE\Controllers\Admin \Trips.

public function action_resumen() : \CMMSE\Core\Template

Acción invocada para generar la página de estadísticas generales del congreso, encadenando

la solicitud al controlador \CMMSE\Controllers\Admin \Stats.

public function action_settings(array $args) : \CMMSE\Core\Template

Acción invocada para generar la interfaz de administración general de la aplicación,

encadenando la solicitud al controlador \CMMSE\Controllers\Admin \Settings.



Autores

Implementación del controlador encargado del listado de autores de las páginas de administración.


protected $autorModel : \CMMSE\Interfaces\Models\IAuthors

Referencia al modelo de gestión de autores utilizado.





5.4.19.2.2 Métodos





Acción encargada de generar el listado de autores a partir de los datos proporcionados por los

modelos.



Controller<<Interfaz>>

onConstruct

<<Interfaz>>

IModel

<<Interfaz>>

IUser

<<Interfaz>>

ISession

AdminController

<< instancia >>1

1

Autores Download

Facturas Justificantes Papers

PDFs Rooms Settings

Conferencias

UsuariosTripsStats

JSONController

...

...

Figura 5.62: Diagrama UML de los controladores principales de administración



Conferencias

Implementación del controlador encargado de la administración de simposios.






5.4.19.3.2 Métodos





Acción encargada de generar el listado de simposios y las estadísticas y acciones disponibles

para cada uno a partir de los datos proporcionados por los modelos.

public function action_add_conference() : void

Acción invocada al solicitar la creación de un simposio, proporcionando su título. Tras la

creación, este método redirige al listado de simposios del panel de administración.

public function action_delete_conference(array $args) : void

Acción invocada al solicitar la eliminación de un simposio. Tras la eliminación, este método

redirige al listado de simposios del panel de administración.

Download

Implementación del controlador encargado de generar los archivos de los listados descargables desde

el panel de administración.


protected $invoicesModel : \CMMSE\Interfaces\Models\IInvoices




protected $paymentsModel : \CMMSE\Interfaces\Models\IPayments

Referencia al modelo de gestión de la configuración de pagos utilizado.

protected $authorModel : \CMMSE\Interfaces\Models\IAuthors

Referencia al modelo de gestión de autores utilizado.









5.4.19.4.2 Métodos




public function action_users_html() : \CMMSE\Core\Template

Acción invocada al solicitar la descarga del listado de ponentes en formato HTML.

public function action_users_excel() : void

Acción invocada al solicitar la descarga del listado de ponentes en formato Excel. Este método

no retorna, y escribe su salida directamente al buffer de salida.

public function action_papers_html() : \CMMSE\Core\Template

Acción invocada al solicitar la descarga del listado de ponentes en formato HTML.

public function action_papers_excel() : void

Acción invocada al solicitar la descarga del listado de ponentes en formato Excel. Este método

no retorna, y escribe su salida directamente al buffer de salida.

public function action_autores_excel() : void

Acción invocada al solicitar la descarga del listado de autores (usuarios que han enviado algún

paper) en formato Excel. Este método no retorna, y escribe su salida directamente al buffer de

salida.

protected function sendExcelHTTPHeaders(string $filename) : void

Método interno encargado de enviar los encabezados HTTP necesarios para que el cliente

reconozca los datos enviados como un archivo Excel.

Facturas

Implementación del controlador encargado de la sección de gestión de facturas del panel de

administración.


protected $facturaModel : \CMMSE\Interfaces\Models\IInvoices

Referencia al modelo de gestión de justificantes de pago utilizado.











protected $payments : \CMMSE\Doctrine\PaymentSettings

Referencia a la configuración de pagos utilizada.

5.4.19.5.2 Métodos





Acción encargada de generar la página con el listado de información de los usuarios que no han

solicitado factura y las opciones disponibles para cada uno.

public function action_set_paidflag(array $args) : void

Acción encargada de cambiar el flag de la base de datos que indica si el pago de un usuario que

ha solicitado factura está confirmado. Tras el cambio, este método redirige al listado de

usuarios que han solicitado factura.

public function action_savefees (array $args) : void

Acción invocada al solicitar cambiar manualmente la cantidad a pagar por un usuario concreto

que ha solicitado factura. Tras el cambio, este método redirige al listado de usuarios que han

solicitado factura.

public function action_set_billok(array $args) : void

Acción invocada al solicitar marcar una factura como lista para imprimir. Tras el cambio, este

método redirige al listado de usuarios que han solicitado factura.

public function action_set_seqno_spain() : void

Acción invocada al solicitar asignar automáticamente un número de factura para todos los

usuarios de España cuyo pago está confirmado que hayan solicitado factura, y que no tienen

un número asignado aún. Tras el cambio, este método redirige al listado de usuarios que han

solicitado factura.

public function action_set_numfactout() : void

Acción invocada al solicitar asignar automáticamente un número de factura para todos los

usuarios de fuera de España cuyo pago está confirmado que hayan solicitado factura, y que no

tienen un número asignado aún. Tras el cambio, este método redirige al listado de usuarios

que han solicitado factura.



public function action_saveone(array $args) : void

Acción invocada al solicitar cambiar el número de factura de un usuario, o borrar el asignado.

Tras el cambio, este método redirige al listado de usuarios que han solicitado factura.

Justificantes

Implementación del controlador encargado de la sección de gestión de justificantes de pago del panel

de administración.




protected $pagosModel : \CMMSE\Interfaces\Models\IPayments


protected $justificantesModel : \CMMSE\Interfaces\Models\IInvoices




5.4.19.6.2 Métodos





Acción encargada de generar la página con el listado de información de los usuarios que no

requieren factura y las opciones disponibles para cada uno.

public function action_set_paidflag(array $args) : void

Acción encargada de cambiar el flag de la base de datos que indica si el pago de un usuario que

no ha solicitado factura está confirmado. Tras el cambio, este método redirige al listado de

usuarios que no han solicitado factura.

public function action_save_feesone(array $args) : void

Acción invocada al solicitar cambiar manualmente la cantidad a pagar por un usuario concreto

que no ha solicitado factura. Tras el cambio, este método redirige al listado de usuarios que no

han solicitado factura.

Papers

Implementación del controlador encargado de la sección de gestión de papers del panel de

administración.








protected $roomsModel : \CMMSE\Interfaces\Models\IRooms

Referencia al modelo de gestión de salas utilizado.







5.4.19.7.2 Métodos





Acción encargada de generar la página con el listado de papers enviados y las opciones

disponibles para cada uno.

public function action_decision(array $args) : void

Acción encargada de cambiar el flag de la base de datos que indica si un paper ha entrado en

proceso de revisión. Tras el cambio, este método redirige al listado de papers enviados.

public function action_aceptar(array $args) : void

Acción encargada de cambiar el flag de la base de datos que indica si un paper ha sido aceptado

para su presentación en el congreso. Tras el cambio, este método envía una notificación al

autor y a la lista de direcciones configuradas y redirige al listado de papers enviados.

public function action_edit_title(array $args) : void

Acción encargada de cambiar el título de un paper desde el panel de administración sin utilizar

AJAX. Tras el cambio, este método redirige al listado de papers enviados.

public function sendAcceptedMailToAdmin(integer $paperID, integer $userID) : void

Método interno usado para enviar una notificación por correo electrónico a los

administradores informando de que un paper ha sido aceptado para su presentación en el

congreso.



public function sendAcceptedMailToCorrespondingAuthor(integer $paperID, integer $userID)

: void

Método interno usado para enviar una notificación por correo electrónico al autor asociado a

un paper informando de que éste ha sido aceptado para su presentación en el congreso.

PDFs

Implementación del controlador raíz para los archivos PDF generados desde las páginas de

administración. La labor principal de este controlador es comprobar que la sesión del cliente se

corresponde con un administrador identificado y, en ese caso, “encaminar” la solicitud al controlador

adecuado según la URI solicitada.




5.4.19.8.2 Métodos




public function action_etiquetas(array $args) : \CMMSE\Core\PDFResponse

Acción invocada al solicitar generar alguno de los PDFs de etiquetas, que retorna los datos

proporcionados por \CMMSE\Controllers\Admin\PDF\Etiquetas sin modificar para que las

capas superiores generen el archivo PDF correspondiente a partir de ellos.

public function action_facturas(array $args) : \CMMSE\Core\PDFResponse

Acción invocada al solicitar generar alguno de los PDFs de las facturas, que retorna los datos

proporcionados por \CMMSE\Controllers\Admin\PDF\Facturas sin modificar para que las

capas superiores generen el archivo PDF correspondiente a partir de ellos.

public function action_justificantes(array $args) : \CMMSE\Core\PDFResponse

Acción invocada al solicitar generar alguno de los PDFs de los justificantes de pago, que retorna

los datos proporcionados por \CMMSE\Controllers\Admin\PDF\Justificantes sin modificar para

que las capas superiores generen el archivo PDF correspondiente a partir de ellos.

public function action_ponencias(array $args) : \CMMSE\Core\PDFResponse

Acción invocada al solicitar generar alguno de los PDFs con los certificados de presentación de

ponencias, que retorna los datos proporcionados por

\CMMSE\Controllers\Admin\PDF\Ponencias sin modificar para que las capas superiores

generen el archivo PDF correspondiente a partir de ellos.

public function action_certificados(array $args) : \CMMSE\Core\PDFResponse

Acción invocada al solicitar generar alguno de los PDFs con los certificados de asistencia al

congreso, que retorna los datos proporcionados por



\CMMSE\Controllers\Admin\PDF\Certificados sin modificar para que las capas superiores

generen el archivo PDF correspondiente a partir de ellos.

Rooms

Implementación del controlador encargado de la administración de salas.


protected $roomModel : \CMMSE\Interfaces\Models\IRooms




5.4.19.9.2 Métodos





Acción encargada de generar el listado de salas y acciones disponibles para cada una a partir

de los datos proporcionados por el modelo.

public function action_add_room() : void

Acción invocada al solicitar la creación de una sala, proporcionando su nombre. Tras la

creación, este método redirige al listado de salas del panel de administración.

public function action_delete_room(array $args) : void

Acción invocada al solicitar la eliminación de una sala. Tras la eliminación, este método redirige

al listado de salas del panel de administración.

Settings

Implementación del controlador encargado de la sección de configuración de la aplicación del panel

de administración.














5.4.19.10.2 Métodos





Acción encargada de generar la página con los formularios de configuración de la aplicación.

public function action_set_invoicespain() : void

Acción invocada al solicitar cambiar el número de la siguiente factura emitida para los ponentes

de España. Tras el cambio, este método redirige a la página de configuración de la aplicación.

public function action_set_invoiceothers() : void

Acción invocada al solicitar cambiar el número de la siguiente factura emitida para los

ponentes de fuera de España. Tras el cambio, este método redirige a la página de configuración

de la aplicación.

public function action_change_term() : void

Acción invocada al solicitar abrir o cerrar el plazo de envío de papers. Tras el cambio, este

método redirige a la página de configuración de la aplicación.

public function action_change_public_access() : void

Acción invocada al solicitar abrir o cerrar el acceso público a la página. Tras el cambio, este

método redirige a la página de configuración de la aplicación.

public function action_set_conference_params() : void

Acción invocada al solicitar cambiar los parámetros básicos de la conferencia, incluyendo año,

fechas, lugar, CIF e ISBN. Tras el cambio, este método redirige a la página de configuración de

la aplicación.

public function action_set_email_server() : void

Acción invocada al solicitar cambiar los datos del servidor SMTP utilizado para el envío de

correos. Tras el cambio, este método redirige a la página de configuración de la aplicación.

public function action_test_email () : \CMMSE\Core\Template

Acción invocada al solicitar comprobar el funcionamiento del envío de correos con la última

configuración guardada, proporcionando la salida de depuración detallada con los mensajes

intercambiados entre la aplicación y el servidor SMTP al intentar el envío de un correo de

prueba a una dirección indicada previamente.



public function action_set_email () : \CMMSE\Core\Template

Acción invocada al solicitar cambiar la lista de direcciones de correo a las que enviar las

notificaciones de la aplicación. Tras el cambio, este método redirige a la página de

configuración de la aplicación.

Stats

Implementación del controlador encargado de generar la página de estadísticas del panel de

administración.


protected $statsModel : \CMMSE\Interfaces\Models\IStats

Referencia al modelo de estadísticas utilizado.









5.4.19.11.2 Métodos




public function default_action () : \CMMSE\Core\Template

Acción encargada de generar la página con las estadísticas básicas de la conferencia a partir de

los datos disponibles en la base de datos.

Trips

Implementación del controlador encargado de la administración de excursiones.


protected $tripsModel : \CMMSE\Interfaces\Models\ITrips

Referencia al modelo de gestión de excursiones utilizado.





5.4.19.12.2 Métodos





Acción encargada de generar el listado de excursiones programadas y acciones disponibles

para cada una a partir de los datos proporcionados por el modelo.

public function action_add_trip() : void

Acción invocada al solicitar la creación de una excursión, proporcionando su nombre. Tras la

creación, este método redirige al listado de excursiones del panel de administración.

public function action_delete_trip(array $args) : void

Acción invocada al solicitar la eliminación de una excursión. Tras la eliminación, este método

redirige al listado de excursiones del panel de administración.

Usuarios

Implementación del controlador encargado de la administración de las cuentas de ponente.


protected static $actions_default : string[][]

Matriz asociativa con las URIs de los controladores usados para generar las etiquetas cuando

parte de éstas deben estar orientadas en sentido vertical.

protected static $actions_etiqueta1 : string[][]

Matriz asociativa con las URIs de los controladores usados para generar las etiquetas cuando

todas ellas deben estar orientadas en sentido horizontal.















5.4.19.13.2 Métodos





Acción encargada de generar el listado de usuarios y las acciones disponibles para cada una a

partir de los datos proporcionados por el modelo.

public function action_delete(array $args) : void

Acción invocada al solicitar la eliminación de un usuario y todos los usuarios asociados a él.

Tras la eliminación, este método envía una respuesta de redirección HTTP para dirigir al

navegador al listado de usuarios del panel de administración.



5.4.20 \CMMSE\Controllers\Admin\JSON

Este espacio de nombres contiene los controladores usados para realizar las diferentes acciones AJAX

del panel de administración.

JSONController

Implementación del controlador raíz de las acciones AJAX de las páginas de administración. La labor

principal de este controlador es encadenar la solicitud al controlador adecuado según la URI solicitada.




protected $sesessionModel : \CMMSE\Interfaces\Models\ISettings


5.4.20.1.2 Métodos




public function action_pagos(array $args) : string[]

Acción invocada al solicitar la realización de una acción asíncrona de gestión de pagos por

medio de AJAX. Este método toma los datos proporcionados por el controlador

\CMMSE\Controllers\Admin\JSON\Pagos y los retorna sin cambios al controlador de

administración.

public function action_papers(array $args) : string[]

Acción invocada al solicitar la realización de una acción asíncrona de gestión de papers por


\CMMSE\Controllers\Admin\JSON\Papers y los retorna sin cambios al controlador de

administración.

public function action_conferencias(array $args) : string[]

Acción invocada al solicitar la realización de una acción asíncrona de gestión de simposios por


\CMMSE\Controllers\Admin\JSON\Conferencias y los retorna sin cambios al controlador de

administración.



public function action_rooms(array $args) : string[]

Acción invocada al solicitar la realización de una acción asíncrona de gestión de salas por medio

de AJAX. Este método toma los datos proporcionados por el controlador

\CMMSE\Controllers\Admin\JSON\Rooms y los retorna sin cambios al controlador de

administración.

JSONController

Conferencias Pagos Papers Rooms

Controller

<< instancia >>

Figura 5.63: Diagrama UML de los controladores de las acciones AJAX

Conferencias

Implementación del controlador encargado de las acciones AJAX de administración de simposios.



Referencia al modelo de gestión de simposios utilizado.





5.4.20.2.2 Métodos




public function action_edit_title(string[] $params) : string[]

Acción invocada al solicitar la modificación del título de un simposio utilizando AJAX.

public function action_edit_date(string[] $params) : string[][]

Acción invocada al solicitar la modificación de la fecha de inicio de un simposio utilizando AJAX.

Pagos

Implementación del controlador encargado de las acciones AJAX de gestión de pagos.




protected $facturasModel : \CMMSE\Interfaces\Models\IInvoices

Referencia al modelo de gestión de justificantes de pago y facturas utilizado.







5.4.20.3.2 Métodos




public function action_setpaidflag(string[] $params) : string[]

Acción invocada al solicitar la modificación del flag que indica que un usuario ha pagado

utilizando AJAX.

public function action_setbillprintflag(string[] $params) : string[]

Acción invocada al solicitar la modificación del flag que indica que la factura de un usuario está

lista para imprimirse utilizando AJAX.

public function action_setbillno(string[] $params) : string[]

Acción invocada al solicitar la modificación del número de factura de un usuario utilizando

AJAX.



public function action_setfee(string[] $params) : string[]

Acción invocada al solicitar la modificación de la cuota a pagar por un usuario (o restablecer a

la cuota por defecto) utilizando AJAX.

public function action_getbillstatus(string[] $params) : string[]

Acción invocada al solicitar los datos del pago de un usuario (estado, número de factura,

archivo con el justificante, cuota…) utilizando AJAX.

Papers

Implementación del controlador encargado de las acciones AJAX de administración de salas.






5.4.20.4.2 Métodos




public function action_edittitle (string[] $params) : string[]

Acción invocada al solicitar la modificación del título de un paper utilizando AJAX.

public function action_edit_room(string[] $params) : string[][]

Acción invocada al solicitar la modificación de la sala y las fechas de exposición de un poster

utilizando AJAX.

public function action_setdecisionflag (string[] $params) : string[]

Acción invocada al solicitar la modificación del flag de decisión de un paper utilizando AJAX.

public function action_setacceptedflag(string[] $params) : string[]

Acción invocada al solicitar la modificación del flag de aceptación de un paper utilizando AJAX.

Tras el cambio, este método envía una notificación al autor y a la lista de direcciones

configuradas.

protected function parseSentDates(string[] $params) : mixed[]

Método interno utilizado para interpretar las fechas enviadas de exposición de un poster. Este

método retorna un array con un entero que representa el identificador del paper y dos objetos

\DateTime que representan la fecha de inicio y fin de exposición.



Rooms

Implementación del controlador encargado de las acciones AJAX de administración de salas.






5.4.20.5.2 Métodos




public function action_edit_name(string[] $params) : string[]

Acción invocada al solicitar la modificación del nombre de una sala utilizando AJAX.



5.4.21 \CMMSE\Controllers\Admin\PDF

Este espacio de nombres contiene los controladores utilizados para generar los distintos archivos PDF

accesibles desde el panel de administración.

Certificados

Implementación del controlador encargado de generar los certificados PDF de asistencia al congreso.










5.4.21.1.2 Métodos




public function action_one(string[] $params) : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el certificado de asistencia de un único usuario.

public function action_seleccionados() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el certificado de asistencia de un conjunto de usuarios

seleccionados desde la página de administración de usuarios.

public function action_todos() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el certificado de asistencia de todos los usuarios registrados.

public function action_todos_pagado() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el certificado de asistencia de todos los usuarios registrados cuyo

pago ha sido confirmado.



\CMMSE\PDFViews

Certificados Etiquetas Facturas Justificates Ponencias

Controller

<< usa >>

Figura 5.64: Diagrama UML de los controladores PDF de la sección de administración



Etiquetas

Implementación del controlador encargado de generar las etiquetas en formato PDF.


protected $tripsModel : \CMMSE\Interfaces\Models\ITrips

Referencia al modelo de gestión de excursiones utilizado.





5.4.21.2.2 Constantes

FN_ALL_H : string

Contiene el nombre de archivo base para los archivos que contienen las etiquetas de todos los

usuarios en sentido horizontal.

FN_ALL_V : string

Contiene el nombre de archivo base para los archivos que contienen las etiquetas de todos los

usuarios en sentido vertical.

FN_BLANK_H : string

Contiene el nombre de archivo base para los archivos que contienen las etiquetas en blanco

en sentido horizontal.

FN_BLANK_V : string

Contiene el nombre de archivo base para los archivos que contienen las etiquetas en blanco

en sentido vertical.

FN_REST_H : string

Contiene el nombre de archivo base para los archivos que contienen las etiquetas de

restaurante.

FN_ORG_H : string

Contiene el nombre de archivo base para los archivos que contienen las etiquetas para los

miembros de la organización del congreso.

FN_EXC_H : string

Contiene el nombre de archivo base para los archivos que contienen las etiquetas para la

asistencia a excursiones.

FN_EXC_H : string

Contiene el nombre de archivo base para los archivos que contienen las etiquetas para la

asistencia a la cena de gala.



5.4.21.2.3 Métodos




public function action_blanco_vertical() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el PDF con las etiquetas en blanco en sentido vertical.

public function action_blanco_horizontal15() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el PDF con las etiquetas en blanco en sentido horizontal con un

tamaño de 15x7,5 cm.

public function action_blanco_horizontal9() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el PDF con las etiquetas en blanco en sentido horizontal con un

tamaño de 9,2x6,25 cm.

public function action_todos_vertical() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el PDF con las etiquetas nominativas para todos los ponentes en

sentido vertical.

public function action_todos_horizontal15() : \CMMSE\Core\PDFResponse


sentido horizontal con un tamaño de 15x7,5 cm.

public function action_todos_horizontal9() : \CMMSE\Core\PDFResponse


sentido horizontal con un tamaño de 9,2x6,25 cm.

public function action_horizontal_restaurant15() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el PDF con las etiquetas de restaurante en sentido horizontal con

un tamaño de 15x7,5 cm.

public function action_horizontal_restaurant9() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el PDF con las etiquetas de restaurante en sentido horizontal con

un tamaño de 9,2x6,25 cm.

public function action_horizontal_organ15() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el PDF con las etiquetas distintivas para los miembros de la

organización en sentido horizontal con un tamaño de 15x7,5 cm.

public function action_horizontal_organ9() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el PDF con las etiquetas distintivas para los miembros de la

organización en sentido horizontal con un tamaño de 9,2x6,25 cm.

public function action_horizontal_excursion15() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el PDF con las etiquetas para la asistencia a las excursiones

programadas en sentido horizontal con un tamaño de 15x7,5 cm.



public function action_horizontal_excursion9() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el PDF con las etiquetas para la asistencia a las excursiones

programadas en sentido horizontal con un tamaño de 9,2x6,28 cm.

public function action_horizontal_dinnergala15() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el PDF con las etiquetas para la asistencia a la cena de gala en

sentido horizontal con un tamaño de 15x7,5 cm.

public function action_horizontal_dinnergala9() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el PDF con las etiquetas para la asistencia a la cena de gala en

sentido horizontal con un tamaño de 9,2x6,28 cm.

Facturas

Implementación del controlador encargado de generar las facturas en formato PDF.
















5.4.21.3.2 Métodos





Acción invocada al solicitar la factura de un único usuario.



public function action_one_todo(string[] $params) : \CMMSE\Core\PDFResponse

Acción invocada al solicitar la factura de un único usuario usando como cuota, en caso de que

no se haya establecido una cuota personalizada para él, la cuota de inscripción multiplicada

por el número de papers enviados (o por 1 en caso de que no haya enviado ninguno).


Acción invocada al solicitar la factura de todos los usuarios que la han solicitado y tienen

asignado un número de factura.

public function action_todos_listas() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar la factura de todos los usuarios que la han solicitado, tienen

asignado un número de factura y sus facturas han sido marcadas como listas para imprimir.

public function action_todos_listas_paganportodo() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar la factura de todos los usuarios que la han solicitado, tienen

asignado un número de factura y sus facturas han sido marcadas como listas para imprimir

usando como cuota, para cada usuario sin una cuota personalizada establecida, la cuota de

inscripción multiplicada por el número de papers enviados (o por 1 en caso de que no haya

enviado ninguno).


Acción invocada al solicitar la factura de un conjunto de usuarios seleccionados desde la página

de facturas.

public function action_todos_seleccionados_paganportodo() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar la factura de un conjunto de usuarios seleccionados desde la página

de facturas con número de factura asignado, usando como cuota, para cada usuario sin una

cuota personalizada establecida, la cuota de inscripción multiplicada por el número de papers

enviados (o por 1 en caso de que no haya enviado ninguno).


Acción invocada al solicitar la factura de todos los usuarios registrados con número de factura

asignado.

public function action_todos_paganportodo() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar la factura de todos los usuarios registrados con número de factura

asignado usando como cuota, para cada usuario sin una cuota personalizada establecida, la

cuota de inscripción multiplicada por el número de papers enviados (o por 1 en caso de que no

haya enviado ninguno).

Justificantes

Implementación del controlador encargado de generar los justificantes de pago en formato PDF.


protected $factModel : \CMMSE\Interfaces\Models\IBilling
















5.4.21.4.2 Métodos





Acción invocada al solicitar los justificantes de pago de todos los usuarios que no han solicitado

factura.

public function action_todos_paganportodo() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar los justificantes de pago de todos los usuarios que no han solicitado

factura, usando como cuota, para cada usuario sin una cuota personalizada establecida, la

cuota de inscripción multiplicada por el número de papers enviados (o por 1 en caso de que no

haya enviado ninguno).

public function action_todospagado() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el justificante de pago de todos los usuarios que no han solicitado

factura y cuyo pago ha sido confirmado.

public function action_todospagado_paganportodo() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar el justificante de pago de todos los usuarios que no han solicitado

factura y cuyo pago ha sido confirmado, usando como cuota, para cada usuario sin una cuota

personalizada establecida, la cuota de inscripción multiplicada por el número de papers



Acción invocada al solicitar los justificantes de pago de un conjunto de usuarios seleccionados

desde la página de justificantes.



public function action_seleccionados_paganportodo() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar los justificantes de pago de un conjunto de usuarios seleccionados

desde la página de justificantes, usando como cuota, para cada usuario sin una cuota

personalizada establecida, la cuota de inscripción multiplicada por el número de papers


Ponencias

Implementación del controlador encargado de generar los certificados de presentación de ponencia

en formato PDF.












5.4.21.5.2 Métodos





Acción invocada al solicitar el certificado de la ponencia de un único paper.


Acción invocada al solicitar los certificados de presentación de las ponencias para todos los

papers aceptados.

public function action_todospagado() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar los certificados de presentación de todas las ponencias presentadas

por usuarios cuyo pago ha sido confirmado.

public function action_seleccionadas() : \CMMSE\Core\PDFResponse

Acción invocada al solicitar los certificados de presentación de un conjunto de ponencias

seleccionados desde la lista de papers enviados.



5.4.22 \CMMSE\Controllers\Frontcontrollers

Este espacio de nombres contiene los controladores raíz de la aplicación. Éstos son invocados en

primer lugar en respuesta a las solicitudes de los clientes y se encargan de generar una respuesta,

generalmente realizando nuevas solicitudes a otros controladores.

CSS

Implementación del controlador raíz encargado de generar las hojas de estilo CSS de forma dinámica

a partir de plantillas basándose en la configuración de directorios del sitio almacenada en los archivos

de configuración.

5.4.22.1.1 Métodos

protected function getCSS(string $template) : \CMMSE\Core\Template

Método interno utilizado para generar una hora de estilos CSS a partir de la plantilla

identificada por el parámetro proporcionado, en la cual remplaza las referencias a la URI base

de los archivos estáticos y de otras plantillas CSS que pudiesen estar presentes en la plantilla

indicada por sus valores reales, además de enviar los encabezados HTTP necesarios de tipo de

contenido para indicar que el archivo es una hoja de estilos.


Esta acción es invocada cuando no se especifica que hoja de estilos se desea obtener y retorna

una hoja de estilos vacía.

public function action_admin() : \CMMSE\Core\Template

Acción invocada al solicitar la hoja de estilos del panel de administración.

public function action_cmxform() : \CMMSE\Core\Template

Acción invocada al solicitar la hoja de estilos con declaraciones adicionales para formularios,

importada desde la hoja de estilos screen usada en las páginas de usuario.

public function action_estilo() : \CMMSE\Core\Template

Acción invocada al solicitar la hoja de estilos general de la aplicación, la cual incluye el estilo

principal de párrafos, encabezados y validación de contraseñas con jQuery.

public function action_fancybox() : \CMMSE\Core\Template

Acción invocada al solicitar la hoja de estilos asociada al plugin jQuery usado en el panel de

administración para mostrar los justificantes de pago enviados de tipo imagen sin necesidad

de cargar una página nueva.

public function action_reset() : \CMMSE\Core\Template

Acción invocada al solicitar la hoja de estilos encargada de restablecer los estilos por defecto

del navegador para párrafos, enlaces, encabezados, listas y formularios, importada desde la

hoja de estilos screen usada en las páginas de usuario.



public function action_screen() : \CMMSE\Core\Template

Acción invocada al solicitar la hoja de estilos para pantallas estándar, usada en las páginas de

usuario.

public function action_stickyfooter() : \CMMSE\Core\Template

Acción invocada al solicitar la hoja de estilos con las declaraciones necesarias para mantener

el pie de página de las páginas de administración y usuarios en la parte inferior de la ventana

del navegador.

public function action_user() : \CMMSE\Core\Template

Acción invocada al solicitar la hoja de estilos general de las páginas públicas.

Homepage

Implementación del controlador principal de la aplicación, encargado de encaminar las solicitudes al

subcontrolador adecuado, además de realizar las comprobaciones necesarias para permitir o denegar

el acceso a partes de la aplicación en función de la configuración actual de la misma.


protected $instrumentationModel : \CMMSE\Interfaces\Models\IInstrumentation

Referencia al modelo de instrumentación utilizado.


Referencia al modelo de gestión de sesiones de usuario utilizado.





protected $config : \CMMSE\Doctrine\Configuration


5.4.22.2.2 Métodos



de los modelos utilizados por el controlador. Además, este método guarda el instante de inicio

de la solicitud actual de forma que pueda ser almacenado más adelante en la tabla de

instrumentación.

public function __destruct() : void

Método invocado cuando se han destruido todas las referencias al controlador principal, lo

cual ocurre al finalizar la solicitud actual. Este método se encarga de añadir una entrada en los

archivos de registro de la aplicación informando del final de la solicitud y la carga media del

sistema, además de solicitar al modelo de instrumentación que recolecte y guarde en la base

de datos información de depuración.



protected function getClosedPage() : string

Método interno usado para enviar al cliente un estado HTTP 410 (que indica que la aplicación

ya no está disponible) junto a un mensaje que indica que el acceso completo al sistema está

cerrado. Es usado desde las acciones del controlador cuando el acceso a la aplicación ha sido

deshabilitado completamente desde el archivo de configuración.

protected function getPublicClosedPage() : string

Método interno usado para enviar al cliente un estado HTTP 410 (que indica que la aplicación

ya no está disponible) junto a un mensaje que indica que el acceso público al sistema está

cerrado. Es usado desde las acciones del controlador cuando el acceso a la aplicación ha sido

deshabilitado para los usuarios que no sean administradores desde la interfaz de

administración.


Esta acción es invocada cuando se accede a la página de inicio de la aplicación y muestra

información general sobre la misma y, si la configuración lo permite, enlaces para iniciar sesión

o crear una nueva cuenta de ponente.

public function action_bootstrap(string[] $params) : string

Acción invocada al solicitar una hoja de estilos, un archivo con código Javascript o un archivo

de fuentes TTF del framework Bootstrap, utilizado como base de la interfaz gráfica de la

aplicación. Además del contenido propiamente dicho, este método envía al cliente los

encabezados HTTP necesarios para que éste reconozca el tipo de datos enviados.

public function action_editor(string[] $params) : \CMMSE\Core\Template

Acción invocada al solicitar las páginas de los editores, encadenando la solicitud al controlador

\CMMSE\Controllers\Editor.

public function action_admin(string[] $params) : mixed

Acción invocada al solicitar una página de la interfaz de administración, encadenando la

solicitud al controlador \CMMSE\Controllers\Admin\AdminController.

public function action_user(string[] $params) : \CMMSE\Core\Template


solicitud al controlador \CMMSE\Controllers\User\UserHome.

public function action_calendar(string[] $params) : string

Acción invocada al solicitar un calendario en formato iCal, encadenando la solicitud al

controlador \CMMSE\Controllers\Calendar.

public function action_download(string[] $params) : void


solicitud al controlador \CMMSE\Controllers\User\Download. Exceptuando las solicitudes de

documentos HTML, el controlador invocado envía directamente los datos solicitados al cliente

y cierra la conexión, lo cual hace que la invocación de este método no retorne.

public function action_recover(string[] $params) : \CMMSE\Core\Template

Acción invocada al solicitar restablecer la contraseña de una cuenta de ponente, encadenando

la solicitud al controlador \CMMSE\Controllers\Recover.



public function action_login(string[] $params) : \CMMSE\Core\Template

Acción invocada al solicitar el formulario para introducir las credenciales de acceso a la

aplicación, introducir dichas credenciales o solicitar la finalización de la sesión actual,

encadenando la solicitud al controlador \CMMSE\Controllers\Login.

public function action_register(string[] $params) : \CMMSE\Core\Template

Acción invocada al solicitar el formulario de registro de un nuevo usuario o al introducir los

datos necesarios para ello, encadenando la solicitud al controlador

\CMMSE\Controllers\Signup.

Homepage

+ default_action() : Template

CSS

......+ action_user(string[] $args) : mixed

# getCSS(string $template) : Template+ default_action() : Template+ action_admin(string[] $args) : mixed+ action_estilo() : Template

\CMMSE\Models

Controller

Frontcontroller

+ dispatch_request() : mixed...

Figura 5.65: Diagrama UML de los Frontcontrollers



5.5 Diseño físico de datos

En este apartado se describe cómo y dónde se almacenan los datos utilizados internamente y/o

gestionados por la aplicación, entre los que se encuentra la configuración básica, los archivos utilizados

para generar las páginas y la documentación, las imágenes proporcionadas a los clientes para mostrar

la interfaz de usuario a partir del código HTML y CSS, y los archivos enviados por los ponentes. En los

últimos apartados se detalla la estructura de los datos almacenados por la aplicación en la base de

datos y un estudio de los cambios necesarios en la misma para su normalización.

El directorio webcmmse, mencionado en los siguientes apartados, está ubicado por defecto en

/var/www/webcmmse.

5.5.1 Archivos estáticos internos

Los archivos estáticos, como las imágenes y fuentes TrueType utilizadas para generar los PDFs o los

archivos adjuntos a los correos que notifican la aceptación de un paper, se encuentran en los

directorios indicados en la sección “files” del archivo de configuración (por defecto apuntan al

directorio “data” relativo al directorio padre de webcmmse).

Las plantillas usadas paga generar las páginas HTML, las hojas de estilo CSS, los correos electrónicos y

los documentos PDF están ubicadas en el directorio twig_templates ubicado en webcmmse. Este

directorio no es configurable.

5.5.2 Archivos estáticos públicos

Los archivos estáticos accesibles públicamente a través de solicitudes HTTP, como scripts Javascript no

generados dinámicamente o imágenes, se encuentran ubicados en los directorios, relativos a

webcmmse, static (en el caso de las imágenes), js (para los scripts Javascript) y tablesorter (para los

scripts Javascript de ordenación de tablas en el cliente). Las rutas de estos directorios son configurables

modificando los parámetros correspondientes del archivo de configuración.

5.5.3 Archivos de usuario

Los archivos enviados por los usuarios se almacenan en los directorios, relativos a webcmmse, papers

(para los papers enviados) y facturas (para los justificantes de pago enviados). El servidor web necesita

tener permisos de escritura sobre estos directorios y sus contenidos para el correcto funcionamiento

de la aplicación.



5.5.4 Configuración estática de la aplicación

La configuración estática comprende todos aquellos datos que, por su naturaleza, no pueden ser

almacenados en la base de datos (por ejemplo, las propias credenciales de acceso a la misma), o

información que se ha decidido no mantener en la base de datos para simplificar la administración, al

tratarse de parámetros que rara vez varían. Además, los parámetros del registro de depuración

(log4php) también son configurables.

La aplicación utiliza dos archivos de configuración, log4php.xml y webcmmse.ini, que deberán estar

situados en el subdirectorio conf dentro del directorio raíz de instalación (normalmente

/var/www/conf). Estos archivos son generados automáticamente durante la instalación a partir de la

información proporcionada durante la misma.

log4php.xml

Este archivo es utilizado para configurar el sistema de logging, por ejemplo para mostrar los mensajes

de depuración en consola (en el caso de sistemas de de desarrollo basados en el servidor web

integrado de PHP) o guardarlos en disco para su análisis posterior en caso de ser necesario.

Consulte la documentación de log4php24 para obtener más detalles sobre la sintaxis y las opciones

configurables desde este archivo.

webcmmse.ini

Este archivo contiene la configuración estática completa de la aplicación a excepción de la

configuración del sistema de logging. Se trata de un archivo .ini tradicional dividido en 4 secciones. Los

parámetros de tipo URI contienen un string representando una dirección entre comillas relativa al

hostname del servidor web (salvo que se indique otra cosa); los valores admitidos en los campos de

tipo boolean son true y false (sin comillas).

Sección “web”

Parámetro Tipo Ejemplo

open boolean open = true

Habilita o deshabilita el acceso completo a la aplicación. El valor false provoca que la pantalla

principal muestre el mensaje “System closed” en lugar de los enlaces de registro y login, y el

intento de acceso a cualquier otra URL retornará el mensaje “The system is closed”.

root URI root = "/webcmmse"

URI base de la aplicación.

24 https://logging.apache.org/log4php/




base_uri URI base_uri = "/webcmmse/index.php/"

URI base de acceso a las páginas dinámicas.

base_css_uri URI base_css_uri ="/webcmmse/css.php/"

URI base a partir de la cual se construyen las direcciones de acceso a las hojas de estilo

CSS generadas dinámicamente.

static_base_uri URI static_base_uri="/webcmmse/static/"

URI base de los archivos estáticos de la interfaz de usuario (imágenes).

favicon_uri URI favicon_uri = "/webcmmse/static/favicon32.png"

URI del favicon (icono mostrado en marcadores) de la aplicación.

bootstrap_css_root URI bootstrap_css_root =

"/webcmmse/index.php/bootstrap/css/"

URI base de acceso a las hojas de estilo de Bootstrap.

bootstrap_js_root URI bootstrap_js_root =

"/webcmmse/index.php/bootstrap/js/"

URI base de acceso a los archivos javascript de Bootstrap.

tablesorter_js_uri URI tablesorter_js_uri =

"/webcmmse/tablesorter/jquery.tablesorter.min.js"

URI del script de ordenación de tablas en el lado del cliente.

fancybox_js_uri URI fancybox_js_uri =

"/webcmmse/js/jquery.fancybox.js"

URI del script usado para mostrar las facturas enviadas como imágenes en un lightbox.

jquery_plugin_root URI jquery_plugin_root = "/webcmmse/js/"

URI base de los plugins de jQuery (validadores de formularios).

admin_js_uri URI admin_js_uri = "/webcmmse/js/admin.js"

URI del script con las funcionalidades dinámicas de las páginas de administración.

use_errorexception boolean use_errorexception = false

Indica si los errores estándar de PHP deben convertirse en excepciones. Solo debe tomar

el valor true en entornos de desarrollo.

paper_download_

base_uri

URI paper_download_base_uri = "papers/"

URI relativa a la base de la aplicación (parámetro root) para descargar los papers enviados.




paper_base_ local_path URI paper_base_local_path = "webcmmse/papers"

Path relativo al directorio padre de webcmmse donde almacenar los papers.

invoice_download_

base_uri

URI invoice_download_base_uri = "facturas/"

URI relativa a la base de la aplicación (parámetro root) para descargar los justificantes de

pago enviados.

invoice_base_ local_path URI invoice_base_local_path="webcmmse/facturas"

Path relativo al directorio padre de webcmmse donde almacenar los justificantes de pago

enviados.

paper_email_

download_protocol

IANA URI

scheme

paper_email_download_protocol = "http"

Protocolo de las direcciones de descarga de papers mostradas en los correos enviados.

paper_email_

download_host

Domain

name o IP

paper_email_download_host =

"pirweb.edv.uniovi.es"

Nombre de host o IP usado en las direcciones de descarga de papers mostradas en los

correos enviados.

paper_email_

download_prepend

URI paper_email_download_prepend ="download/"

Cadena de texto incluida entre base_uri y el nombre de archivo de los papers usada para

generar los enlaces de descarga de papers incluídos en los correos enviados.

Sección “files”


data_path URI relativa data_path ="data"

Path relativo al directorio padre de webcmmse donde se encuentran los archivos de datos

auxiliares (imágenes para los PDFs y archivo CSV con la lista de países).

font_path URI relativa font_path = "data/fonts"

Path relativo a la URI base con las fuentes TrueType usadas para generar los PDFs.

paper_templates URI relativa paper_templates = "cmmse2014.cls, word.zip"

Nombre de los archivos (situados en el data_path y separados por comas) a adjuntar en

los correos electrónicos que notifican a los ponentes de que un paper ha sido aceptado.



Sección “database”


host Domain name o IP host ="localhost"

Nombre de host o IP usado para conectar al servidor MySQL que hospeda la base de datos

de la aplicación.

user string user = "cmmse"

Nombre de usuario usado para conectar al servidor MySQL que hospeda la base de datos

de la aplicación.

pass string pass = "MySQLCmmse"

Contraseña usada para conectar al servidor MySQL que hospeda la base de datos de la

aplicación.

name string name = "cmmse"

Nombre de la base de datos usada por la aplicación.

Sección “doctrine”

Estos parámetros se usan para acceder a la base de datos a través del ORM (Doctrine) y sus valores

deben coincidir con los de la sección anterior.


host Domain name o IP host ="localhost"

Nombre de host o IP usado para conectar al servidor MySQL que hospeda la base de datos

de la aplicación.

user string user = "cmmse"

Nombre de usuario usado para conectar al servidor MySQL que hospeda la base de datos

de la aplicación.

pass string pass = "MySQLCmmse"

Contraseña usada para conectar al servidor MySQL que hospeda la base de datos de la

aplicación.

name string name = "cmmse"

Nombre de la base de datos usada por la aplicación.

driver string driver = "mysqli"

Driver de Doctrine usado para acceder a la base de datos.



5.5.5 Modelo entidad-relación de la base de datos

El modelo entidad-relación general de los datos almacenados en la base de datos por la aplicación es

el siguiente:

Sala

se expone en

Poster

ES_UN

PaperUsuario envia

TítuloHonorífico

tiene un

FacturacionUsuario

se corresponde con

Simposio

MuestraInstrumentacion

presentado en

Sesión

generada en

estando logueado

Excursión

n

11

n

n1

1

1

0,1

n

n

0,1 0,1

n

ConfiguraciónPagos

ConfiguraciónEMail

ConfiguraciónGeneral

Figura 5.66: Modelo entidad-relación general

Esta figura solo describe el modelo entidad-relación parcialmente. A continuación se incluyen las

diferentes entidades del mismo de forma detallada.



Modelo entidad-relación: Usuario y TítuloHonrífico

Las entidades Usuario representan a los ponentes, administradores y editores, mientras que los títulos

honoríficos representan las opciones que los ponentes pueden seleccionar al registrarse (Mr., Ms.,

Prof.).

Por razones de compatibilidad, asociada a los títulos honoríficos se incluye una clave alfanumérica

utilizada internamente por la aplicación (en lugar de la clave primaria ID), y asociados a los usuarios se

incluye el nombre de archivo del justificante de pago enviado (si lo hubiese enviado y bajo el nombre

factura) y la cuota a pagar por el usuario (o null si no difiere de la cuota por defecto).

Usuario

TítuloHonorífico

tiene un

ID Título Clave

ID

Contraseña

Nombre

Apellidos

E-Mail

Compañía

DatosDireccion

Teléfono

DatosNombre

País Estado Ciudad

Dirección CódigoPostal

Factura

Cuota

n

1

Tipo

FechaAlta

Figura 5.67: Modelo entidad-relación de los usuarios y los títulos honoríficos

Modelo entidad-relación: FacturacionUsuario

Las entidades FacturacionUsuario representan los datos utilizados para la gestión de pagos asociados

a cada ponente. En los casos en los que no esté contemplado que el usuario realice pagos

(Administradores), esta tabla almacena valores nulos para él (nuevamente por razones de

compatibilidad con el código original), resultando en una relación con cardinalidad 1 en ambos

extremos.



Usuario

FacturacionUsuario

se corresponde con

ID

JustificantePago

Pagó?

NúmeroFactura

CIFCompañía

Dirección

NombreBeneficiario

PerteneceREDNúmeroFacturaRED

Cuota

ListaParaImprimir EstadoDatosRED

DatosFactura

1

1

Figura 5.68: Modelo entidad-relación de los datos de facturación de los usuarios

Modelo entidad-relación: Paper, Poster, Simposio y Sala

Las entidades Paper representan las publicaciones enviadas por los ponentes para presentar en el

congreso. Almacenan su título, la lista de autores, la fecha de envío (tanto formateada como en forma

de fecha SQL, esta última identificada por el atributo FechaCreación), su estado (si ha entrado en

revisión y si ha sido aceptada) y los archivos asociados al primer y último envío.

Para los papers que incluyen un poster, se dispone de la entidad débil Poster. Los Posters, que

dependen funcionalmente del Paper asociado a ellos (con el cual comparten el identificador),

almacenan información adicional para que los administradores gestionen en qué sala y en qué

intervalo de fechas será expuesto.

Por razones de compatibilidad, la lista de autores se almacena junto al paper (existiendo un límite de

9 autores por paper), y el estado se almacena como dos flags binarios (que indican si ha entrado en

proceso de revisión y, si es el caso, si tras la revisión ha sido aceptada su publicación).



Sala

se expone en

Poster

ID

Nombre

ES_UN

Paper

Usuario

enviado por

Simposio presentado en

ID FechaInicio

Título

ID

InicioExposición

FinExposición

FechaCreación

ID

Autores

Archivos

Título Fechas

Estado

PrimerEnvío

ÚltimoEnvío

FechaEnvío

FechaCreación

EnRevisión

Aceptado

Autor2

Autor4Autor3

Autor5

Autor6

Autor7

Autor8

Autor9Autor1

1

n1 n

1

n

Figura 5.69: Modelo entidad-relación de papers, posters, simposios y salas

Modelo entidad-relación: Excursión

Las entidades Excursión representan los datos de las excursiones y actividades complementarias que

se realizarán durante la conferencia. Se trata de entidades simples que solo almacenan un identificador

y un nombre descriptivo, y que no forman parte de ninguna relación con otras entidades.

Excursión

ID Nombre

Figura 5.70: Modelo entidad-relación de las excursiones



Modelo entidad-relación: MuestraInstrumentación y Sesión

La información de las sesiones se guarda en una tabla que mantiene los datos desestructurados de la

misma junto a su identificador, hash de sesión (utilizado para localizar sus datos sin enviar su clave

primaria a través de la red 25 ) y un flag que indica si ha expirado. Los datos de esta tabla son

referenciados desde otra en la que se guarda información de depuración de la aplicación.

Usuario

MuestraInstrumentacion

Sesión

generada en estando conectado

ID Hash Datos Expiró

ID

Carga del Sistema

Consultas BDIdentificación

del Cliente

Solicitud

Identificación del Servidor

Instantes de Muestreo

Nodo

SistemaOperativo

DistribuciónSO

VersiónSO

1min

5min

15min

MemoriaMáxima

Consultas MySQLi

Consultas Doctrnie

IP_Real

IP_Remota

Inicio Fin

Entero Decimal Entero Decimal

HostServidor

MétodoHTTP

URI

0,1

n

0,1

n

Navegador

Figura 5.71: Modelo entidad-relación de las muestras de instrumentación

25 Enviar las claves primarias de sesión a través de la red en lugar de su hash permitiría a un atacante realizar un secuestro de sesión de manera trivial (probando identificadores enteros de forma secuencial).



Modelo entidad-relación: ConfiguraciónGeneral,

ConfiguraciónPagos y ConfiguraciónEMail

La configuración de la aplicación se almacena en 3 tablas. La tabla de configuración general almacena:

El año, fecha, lugar de celebración y URL del sitio web de la conferencia

El CIF de la organización, el ISBN y el ISSN asociados a las publicaciones

Una lista no normalizada con las direcciones de correo electrónico concatenadas a los que

enviar las notificaciones

La fecha de emisión de las facturas y los certificados de asistencia

Flags que indican si el acceso público a la página y el envío de papers están habilitados

Información asociada al patrocinador de la conferencia, en caso de haya uno

La configuración de envío de correos se almacena en una tabla aparte. Contiene información para

realizar la conexión al servidor de correo y la dirección de correo electrónico de origen de los mismos.

La configuración de los pagos y los números de factura disponibles se almacenan en otra tabla, que

contiene la cantidad a pagar en concepto de inscripción, la cantidad a pagar por aquellos usuarios que

cuenten con patrocinador (si lo hubiera) y el último número de factura usado para las facturas de

España, del extranjero y de los usuarios patrocinados.



ConfiguraciónPagos

ConfiguraciónEMail


ID

Año

Fecha

Localización

URL

FechaFacturas

FechaCertificados

CIF

ISBN

ISSN

ListaEmails

AccesoCerrado

InfoRED

CIF Nombre

DirecciónNombreComañía

ParametrosEtiquetas

Tipo Tamaño

PlazoCerrado

IDHost

Puerto

Usuario

Contraseña

Remitente

ParametrosConexión

Dirección

Nombre

TipoEncriptaciónAutentificación

SMTP

ID

NumSecuenciaFacturas

España

Extranjero

RED

Cuota

Estándar RED

Figura 5.72: Modelo entidad-relación de los datos de configuración



5.5.6 Modelo relacional de la base de datos

La estructura de las tablas utilizadas en la aplicación se muestra a continuación a través de varios

diagramas. Los atributos unidos a través de flechas representan claves foráneas (apuntando hacia el

identificador de la tabla original de la cual toma su valor la columna del otro extremo), los marcados

como “CP” representan las claves primarias.

La correspondencia con el modelo entidad-relación descrito anteriormente es prácticamente directa.

Por tanto, lo dicho para entidades y atributos es aplicable a las tablas y sus columnas.



conferencias

idconfCP

title

ts_begin

papers

idpaperCP

iduser

author6

author7

idconf

newfilename

author4

filename

author1

author2

title

poster

date

author5

author3

author9

aceptado

decision

author8

created

usuarios

iduserCP

password

firstname

postalcode

country

lastname

title

email

company

address

city

state

typeuser

telephone

factura

fees

created

person_titles

title_idCP

title_key

title

Figura 5.73: Modelo relacional de las tablas de usuarios, papers y conferencias



papers

paper_idCP

poster

poster_idCP

paper_id

ts_end

ts_begin

created

room

rooms

room_idCP

name

trips

trip_idCP

name

...

Figura 5.74: Modelo relacional de las tablas de posters, salas y excursiones

facturacion

iduserCP

factura

pago

billnumber

billaddress

fees

bill_red

billcompany

billcif

billname

billnumber_red

billprint

usuarios

iduserCP

...

Figura 5.75: Modelo relacional de la tabla de facturación



settings

idsettingCP

yearconf

bbddonoff

dateconf

placeconf

email

issn

isbn

cif

datefirmacert

urlconf

datefirmafact

red_cif

red_company

red_name

red_address

plazo_cerrado

tipoetiqueta

sizeetiqueta

mailer_settings

server_idCP

host

port

smtp_auth

from_addr

user

pass

from_name

encryption_type

enabled

payment_settings

row_idCP

spain_invoice_next_seq_id

out_invoice_next_seq_id

red_fees

red_invoice_next_seq_id

fees

Figura 5.76: Modelo relacional de las tablas de configuración



sessions

sidCP

hash

data

expired

instrumentation

sample_idCP

sid

uid

is_admin

ts_begin

forwarded_for

host

uri

load1

user_agent

request_method

num_queries_doctrine

remote_addr

num_queries_mysqli

load5

max_mem_usage

load15

ts_saved

version

micro_ts_saved

micro_ts_begin

sysname

release

nodename

usuarios

iduserCP

...

Figura 5.77: Modelo relacional de las tablas de sesiones e instrumentación



5.5.7 Normalización

Los requisitos para que una tabla cumpla, al menos, la primera forma normal son:

1. No hay orden de arriba-a-abajo en las filas.

2. No hay orden de izquierda-a-derecha en las filas.

3. No hay filas duplicadas.

4. Cada intersección de fila-y-columna contiene exactamente un valor del dominio aplicable (y

nada más).

5. Todas las columnas son regulares (es decir, las filas no contienen componentes como

identificadores o timestamps ocultos).

El diseño de la base de datos utilizada por la aplicación cumple los 3 primeros requisitos. Sin embargo,

su estructura fue inicialmente proporcionada por la organización del congreso, y no se ha llevado a

cabo su normalización (lo cual hubiese requerido modificaciones en partes de la aplicación que ya eran

completamente funcionales) por falta de tiempo.

A continuación se incluye la estructura normalizada equivalente a la original para las principales

entidades26. Este modelo contiene multitud de entidades débiles (cuya dependencia funcional respecto

a otras entidades es total) para satisfacer los requisitos 4 y 5.

26 Técnicamente la normalización debería realizarse a partir de la estructura de las tablas y no del modelo E-R original. Para los propósitos de este apartado debe asumirse que una entidad corresponde a una tabla, todo atributo mostrado se corresponde con una única columna y las relaciones que incluyen un nombre requieren la creación de tablas adicionales (las que no, o bien heredan identificadores o los almacenan en una columna de la tabla correspondiente a la entidad con cardinalidad variable).



Modelo entidad-relación normalizado: Usuario

En este caso se crearían tablas adicionales para cada tipo de usuario, desapareciendo el campo tipo

(que se obtendría comprobando en qué tabla existe una entrada para un identificador de usuario

dado).

Se añade una tabla adicional para mantener los nombres de usuario, referenciada desde las tablas de

editor y ponente. El valor efectivo de los atributos originales Compañía, País, Estado, Ciudad,

TítuloHonorifico, Dirección, CódigoPostal y Teléfono pasan a tablas separadas, añadiendo, además,

tablas adicionales para relacionarlas en todos los casos excepto para país (que se almacenaría en la

propia tabla de Ponentes por ser un atributo obligatorio).

Usuario

TítuloHonorífico1:N

ID

Título

Clave

ID

Contraseña

NombreApellidos

E-Mail

Nombre

Nombre

Nombre

Dirección

CódigoPostal

n 1

Tipo FechaAlta

Ponente

NombreUsuario

Dirección ID

CódigoPostal

País

Estado

Ciudad

ES_UN

NOTA: tipo se infiere de la

ocurrencia del ID en las otras tablas

Nombre

Compañía

ID

ID

ID

ID

ponente-título

1:N

ponente-compañía

1:N

1:N

ponente-estado

1:N

ponente-ciudad

ID

1:N

n 0,1ponente-direccion

1:Nn 0,1

ponente-cp

Dirección

Teléfono ID1:N

n 0,1ponente-direccion

n 0,1

n 1

n 0,1

n 0,1

Editor Administrador

1:N 1:N

n n

1 1

Figura 5.78: Modelo entidad-relación normalizado de usuarios



Modelo entidad-relación normalizado: Papers, Posters, Salas y

Conferencias

Para los papers se crearía una tabla adicional para diferenciar si son o no de tipo poster. Esta tabla

guardaría una lista de los IDs de los papers que lo son. Además, se crearía una tabla para guardar la

sala en la que se exponen (en caso de estar definida) y una tabla para guardar las fechas de exposición

(nuevamente, en caso de estar definidas, siendo ambas fechas obligatorias para cumplir el requisito

de no existencia de valores nulos). La tabla de fechas es una entidad débil que comparte la clave

primaria con el poster al que pertenece, del cual depende funcionalmente. El identificador del ponente

que envía un paper y el simposio en el que se presenta se almacenan en la propia tabla de papers, ya

que nunca pueden tomar valores nulos.

Se añaden otras dos tablas adicionales, una para almacenar los nombres de los archivos enviados

(como una entidad débil con su propio identificador y el identificador del paper al que pertenece) y

otra para los autores. Para relacionar estos últimos con los papers se incluye una tabla más que guarda

pares (IDPaper,IDAutor) junto a la posición dentro de la lista de autores del paper. Para cumplir el

requisito de no permitir tuplas duplicadas (y reducir el espacio de almacenamiento necesario), las

entradas de la tabla de autores se comparten entre papers y se utiliza la tabla paper-autor para

mantener la relación entre papers y autores.



Sala 1:N

Poster

ID

Nombre

ES_UN

PaperPonente 1:N

Simposio 1:N

ID FechaInicioTítulo

ID

InicioExposición

FinExposición

FechaCreación

FechaPoster 1:1

Título Estado

ArchivoPaper

1:N

AutoresPaper

N:N

ID Nombre

Timestamp

ID Nombre

0,1

1poster-sala

1...n

1

1...n

1...n

paper-autor

0,1

0...n

1 0...n

1 0...n

NumSecuencia

Figura 5.79: Modelo entidad-relación normalizado de papers, posters, salas y simposios



Modelo entidad-relación normalizado: Facturación

A partir de la tabla de facturación original se crean cuatro tablas adicionales para guardar los datos

que originalmente podían tomar valores nulos. De esta forma tenemos una tabla que representa una

entidad débil asociada a los ponentes (con los cuales comparte clave primaria) donde se guarda el flag

que indica si se ha realizado el pago y si pertenece al conjunto de ponentes patrocinados por la “red”

(inicialmente ambos toman el valor falso para todos los ponentes).

Se añade una tabla de cuotas, que contendrá la cantidad a pagar por los ponentes en el caso de que

éstos no tengan asignada la cuota por defecto. Para los casos en los que la cantidad a pagar por el

ponente sea la predeterminada esta tabla no tendrá un registro asociado.

Los números de factura se almacenan en otra tabla, asociados a los IDs de usuarios, para aquellos

usuarios a los que se les haya asignado. De manera similar se almacenan los nombres de archivo de los

justificantes enviados. Además, se añade una tabla adicional con los datos necesarios para emitir las

facturas: CIF, nombre de la Compañía, Dirección, Nombre del Beneficiario y el flag que indica si la

factura está Lista para Imprimir. Todos sus campos son obligatorios.

Ponente FacturacionUsuario1:1

JustificanteFactura

Pagó?

Número

CIFCompañía Dirección

NombreBeneficiario

PerteneceRED?

Cuota

ListaParaImprimir

ArchivoFactura

CuotasNúmerosFactura

DatosEmisiónFactura

1:1 1:1

1:11:1

IDUsuario

0,1 0,1

11

11

0,10,1

Figura 5.80: Modelo entidad-relación normalizado de los datos de facturación



Modelo entidad-relación normalizado: Configuración

A partir de la tabla de configuración original se crea una tabla para la configuración general, en la cual

se almacenarían los parámetros que no pueden tomar valores nulos: año y fecha de la conferencia,

fechas en las que se emiten las facturas y los justificantes, URL de la conferencia, CIF, ISBN y dos flags

que indican si el plazo de envío y el acceso público al sitio están o no habilitados. También se incluirían

dos columnas con el tipo y tamaño de las etiquetas.

En el caso de que se quisiera que alguno de los parámetros descritos anteriormente pudiese tomar

valores nulos, se tendrían que crear nuevas tablas asociados a ellos.

Para los parámetros opcionales se crearían tres tablas nuevas. El ISSN se guardarían en una tabla

independiente (vacía si no se dispone de él) asociado a un ID compartido con la tabla de configuración

general. La configuración de la Red, si existe, se almacenaría también en su propia tabla siguiendo un

método similar (considerando todos sus campos como obligatorios). Las diferentes direcciones a las

que enviar las notificaciones se almacenarían en una nueva tabla, asociadas al ID de la tabla de

configuración general, además de a su propio identificador de fila.


ConfiguraciónISSN ConfiguraciónNotificaciones ConfiguraciónRED

1:1 1:N 1:1

1 1 1

ISSN

0, 1 0, n 0, 1

EMail CIF

NombreCompañia

Dirección

Nombre

ID

ISBN

Año Fecha URL CIF

PlazoCerrado AccesoCerrado

FechaFacturas

FechaJustificantes

ParametrosEtiquetas

Tipo

Tamaño

Figura 5.81: Modelo entidad-relación normalizado de los parámetros de configuración



5.6 Diseño de la interfaz de usuario

La distribución de controles y el uso de la aplicación está descrito en detalle en los manuales; en esta

sección se detallan los criterios generales y tecnologías usadas para la construcción de la interfaz de

usuario.

Toda la interfaz de usuario está construida sobre el framework de presentación web Bootstrap,

haciendo uso de CSS3 y HTML5. En general, durante el diseño de la interfaz de usuario se han

distinguido dos roles generales: Por una parte, las páginas accesibles públicamente (bien como

Invitado o identificado con una cuenta de ponente), y por otra las páginas usadas para la gestión y

administración del congreso y la aplicación. Cada uno de ellos tiene asociado un conjunto distinto de

necesidades y prioridades:

En las páginas públicas, se considera prioritario el aspecto estético de la aplicación y su

funcionamiento correcto en el mayor número posible de navegadores web. Por tanto, se ha

prescindido del uso de funcionalidades avanzadas Javascript (incluyendo AJAX) y (en la medida

de lo posible) de parte de las nuevas tecnologías ofrecidas por HTML5. Las páginas públicas

están diseñadas para un ancho mínimo de pantalla de 1024 pixels, si bien se adaptan y son

usables en dispositivos con resoluciones de pantalla menores utilizando las funcionalidades

que Bootstrap proporciona para ello.

En la página de administración, se considera prioritario el aspecto funcional de la aplicación

respecto al soporte de un mayor número de navegadores (en particular, navegadores

antiguos). Por tanto, parte de las funcionalidades sólo están disponibles en navegadores que

soporten AJAX, CSS3 y HTML5 de forma razonablemente completa. Las páginas de

administración están diseñadas para un ancho mínimo de pantalla de 1400 pixeles, si bien se

han tomado ciertas medidas para proporcionar una interfaz usable (al menos parcialmente)

para resoluciones menores, incluyendo el remplazo de botones por versiones de menor

tamaño o la ocultación de ciertos datos bajo determinadas condiciones.

En ambos casos se ha tenido especial cuidado en no requierir el uso de scroll horizontal para la

visualización de las páginas (salvo en aquellos casos, dentro de la interfaz de administración, en los

que es técnicamente imposible).

Los archivos que contienen la implementación de la interfaz de usuario (Javascript, HTML y CSS) se

encuentran en los directorios descritos en los primeros apartados de la sección Diseño físico de datos.



5.6.1 Interfaz pública

Las páginas públicas muestran el logotipo de la conferencia ocupando la mayor parte de la mitad

superior de la página (1), reservando la parte inferior para los datos y formularios. En las páginas

accesibles una vez el usuario se ha identificado se muestra un menú de navegación (2) entre el logotipo

de la conferencia y el contenido propiamente dicho. Todas las páginas muestran en su parte inferior

información sobre los administradores del sitio y dos enlaces para la descarga de calendarios iCal (3).

La mayor parte de los controles de los formularios están definidos utilizando las clases CSS que

Bootstrap proporciona para ello, mostrándose el botón por defecto para el envío de los formularios

en azul (4) y los botones que pueden provocar una pérdida de datos (borrado de justificantes,

papers,…) en rojo o naranja (5). El resto de botones se muestran en color blanco. Para facilitar su

localización, los botones tienen el doble de tamaño que el estándar.

Figura 5.82: Distribución de las pantallas de la interfaz pública



5.6.2 Interfaz administrativa

Las páginas de administración muestran un menú de navegación en la parte superior (1) con enlaces a

los diferentes módulos junto al logotipo de la conferencia (en caso de disponer de ancho de pantalla

suficiente) y un enlace para cerrar sesión (2). Este meú es visible en todo momento, quedando anclado

a la parte superior del chrome27 del navegador. Ya que la longitud de los listados y de las páginas de

estadísticas mostradas se prevé considerable, para ahorrar espacio, no se muestra un logotipo a

tamaño completo como sí ocurre en las páginas de usuario, facilitando así la navegabilidad. En la parte

inferior se muestra un pie de página similar al mostrado en las páginas públicas. Para proporcionar una

experiencia de uso lo más cómoda y simple posible, se usan tonos claros en toda la interfaz de

administración, y el fondo de la misma no incluye imágenes o efectos de ningún tipo.

Al igual que en la interfaz pública, los controles de los formularios están definidos utilizando Bootstrap,

y los botones se muestran en distintos colores (3) en función de su naturaleza (azul para los botones

por defecto o aquellos que enlazan a las acciones más comunes, blanco para acciones secundarias,

verde para descarga de documentación relativa a facturación y rojo o naranja para aquellos que

enlazan a acciones que pueden provocar pérdida de información). En los casos en los que se muestran

direcciones de correo electrónico, éstas están definidas como enlaces que se abrirán con la aplicación

de envío de correo que el navegador del usuario tenga asociada a los enlaces mailto (4).

Figura 5.83: Distribución general de las pantallas de la interfaz de administración

La interfaz de administración hace un uso intensivo de funcionalidades de la librería jQuery, HTML5 y

Javascript y, por tanto, requiere que el navegador usado los soporte de forma completa. Los listados

de datos pueden ser ordenados haciendo clic en los encabezados de las mismas (5), realizándose dicho

ordenamiento en el cliente en lugar de requerir una recarga completa de la página (mejorando los

tiempos de respuesta y disminuyendo, además, el número de solicitudes HTTP enviadas al servidor); y

el color de fondo de las filas de los mismos intercala tonos claros y oscuros para ayudar a distinguir los

correspondientes a cada una. En caso de seleccionar parte de los registros de un listado (usando el

checkbox disponible en algunos de ellos), la fila completa será resaltada en naranja para facilitar su

localización posterior en caso de ser necesario. Igualmente, la fila sobre la que se encuentre el ratón

mostrará un color de fondo ligeramente más oscuro.

27 Aquí chrome se refiere al término genérico usado en el diseño de interfaces de usuario (que define la parte visible o útil de una interfaz de usuario) y no al navegador de Google.



Figura 5.84: Pantalla de administración con una fila seleccionada y una acción AJAX en curso

Exceptuando la creación y el borrado de entidades (usuarios, salas, simposios…), todas las acciones de

edición de datos se realizan utilizando AJAX, evitando así la recarga de la página y la necesidad de

realizar desplazamientos adicionales en los listados. Mientras están en curso, las acciones AJAX

muestran una animación en la esquina superior derecha de la pantalla, que será remplazada por un

mensaje informativo tras completarse. En función del éxito o no de dicha acción, el mensaje se

mostrará en verde (y desaparecerá en dos segundos) o rojo (y quedará fijo hasta que el usuario realice

otra acción que implique una llamada AJAX o cambie de página).

Para ayudar en el desplazamiento en los listados,

en el momento en que se realice un scroll vertical

se mostrará un enlace en la esquina inferior

derecha que lleva al inicio de la página (sin

recargarla) al hacer clic sobre él. Esto es útil, por

ejemplo, al revisar un listado de usuarios,

marcando parte de ellos, para luego solicitar

únicamente los certificados de asistencia de los

usuarios seleccionados.

Por último, cabe destacar que en el caso del listado

de usuarios, al ser el que muestra el mayor número

de atributos, parte de las columnas serán ocultadas automáticamente (y los botones serán

remplazados por un icono de menor tamaño) en el caso de que el ancho de la pantalla no sea suficiente

para mostrarl su contenido de forma clara. Esta acción puede deshacerse a través de un botón que se

mostrará a tal efecto en la parte superior de la página (provocando que se habilite también el

desplazamiento horizontal en la página).

Figura 5.85: Enlace de retorno a la parte superior de la página

Manuales | Plataforma web para la gestión de conferencias científico-técnicas


6 MANUALES

6.1 Manual de instalación

6.1.1 Prerrequisitos

Para la instalación de la aplicación será necesario disponer de una máquina que ejecute un sistema

operativo GNU/Linux actual y sobre el cual se esté ejecutando el servidor HTTP Apache con PHP 5.5

como módulo, y que éste no vaya a utilizarse para ejecutar ninguna otra aplicación ni servir ninguna

otra web28. Además, debe ejecutar el servidor de bases de datos MySQL de Oracle, y se debe de

disponer de un usuario en el mismo con permisos suficientes para crear una nueva base de datos,

nuevas tablas en la misma y ejecutar scripts .sql desde la sesión de terminal desde la que se ejecute la

instalación29.

Se asume que el usuario que realiza la instalación lo hace desde una terminal Bourne-Again SHell (bash)

de manera local o a través de una conexión SSH remota30. Se recomienda, aunque podría no ser

necesario, disponer de permisos para establecer el bit de ejecución del shell script utilizado para

realizar la instalación (en caso de no disponer de éstos, es posible que pueda ser ejecutado

anteponiendo el nombre del ejecutable del shell, de la forma /bin/bash script.sh).

Además, se asume que el usuario está familiarizado con el uso de las herramientas estándar de

GNU/Linux en línea de comandos y que el servidor dispone de acceso a Internet durante el proceso de

instalación (aunque esto podría no ser necesario en redes locales).

El proceso de instalación descrito en los siguientes apartados está pensado para llevarse a cabo sobre

una máquina (física o virtual) que ejecute Debian. El proceso podría variar en caso de utilizar otra

distribución Linux, aunque no deberían existir diferencias significativas.

Antes de continuar con el proceso de instalación es recomendable comprobar que la configuración del

servidor y/o de la red de la que forme parte permite realizar conexiones al servidor Apache desde el

exterior, y permite a los scripts PHP ejecutados por éste la conexión a los servidores adicionales (locales

o remotos) a utilizar (MySQL, SMTP, …). En concreto, se recomienda comprobar que, si los hubiera, los

firewalls (locales, como iptables, o cualquier otro presente en la red utilizada) y la configuración de

seguridad (en caso de utilizar módulos de seguridad como SELinux o AppArmor) permiten realizar

conexiones a servidores de correo desde el proceso del servidor web.

28 La aplicación asume que es servida desde el directorio webcmmse de la raíz pública del servidor web. Además, se crearán directorios adicionales en la raíz pública para archivos de datos y configuración, entre otros. 29 Otros permisos adicionales, como LOAD DATA INFILE, no son necesarios, ya que la instalación de la base de datos se realizará leyendo un archivo .sql desde la sesión local de usuario hacia el servidor. 30 El proceso de instalación aquí descrito no tiene en cuenta posibles riesgos de seguridad derivados del uso de una conexión remota no encriptada al servidor, como el envío de contraseñas en texto plano a través de redes públicas.

Plataforma web para la gestión de conferencias científico-técnicas | Manuales


6.1.2 Instalación de la aplicación

Para realizar el proceso de instalación deberá disponer de una copia del script de instalación, junto a

los subdirectorios que lo acompañan, en la máquina a utilizar como servidor y situarse en el directorio

que contiene el script install.sh como usuario root. En caso de tratarse de una máquina virtual o

remota, antes de iniciar la instalación deberá copiar a ella el instalador. Si la máquina de destino

permite conexiones SSH, normalmente podrá copiar el instalador utilizando los siguientes comandos

desde la máquina de origen:

cd directorio-del-instalador scp –r . root@maquina-destino:/directorio/destino

Figura 6.1: Copia del instalador al servidor

Como usuario root, deberá dar permisos de ejecución al script de instalación (chmod +x install.sh) y

posteriormente ejecutarlo (./install.sh). Tenga en cuenta que si realiza la instalación directamente

desde un medio extraíble, como un CD, es posible que el sistema tenga configurada la opción noexec

para el mismo y, por tanto, no permita la ejecución de programas desde él. En este caso deberá

ejecutarlo anteponiendo el nombre del ejecutable del intérprete (/bin/bash ./install.sh).

La primera fase de la instalación realizará una serie de comprobaciones en el sistema y preguntará los

parámetros de configuración a utilizar (directorio de instalación y credenciales de acceso a la base de

datos).



Figura 6.2: Comprobaciones iniciales durante la instalación

En el caso de que el instalador no pueda encontrar en el sistema alguno de los componentes

necesarios, ejecute como root

apt-get install php5 php5-cli libapache2-mod-php5

apt-get install php5-mysqlnd php5-json php5-imagick php5-gd



para instalar PHP junto a las extensiones necesarias, la consola de comandos de éste y el módulo de

Apache utilizado para permitir el uso de PHP, y vuelva a intentar la instalación. En caso de utilizar una

distribución Linux distinta de Debian, necesitará utilizar el comando equivalente de su gestor de

paquetes o una instalación desde el código fuente de PHP disponible en http://www.php.net 31.

Durante la instalación se le pedirá que proporcione el directorio de destino. El valor por defecto,

/var/www, será el correcto para la mayor parte de instalaciones en equipos que no vayan a ser

utilizados como servidor de otras aplicaciones web adiciones. Si no es el caso, tenga en cuenta que se

crearán 5 subdirectorios (“webcmmse”, “conf”, “data”, “private” y “scripts”) en la ruta que indique32.

Figura 6.3: Copia de los archivos de la aplicación

Tras la copia de archivos, el programa de instalación le solicitará los parámetros de conexión a la base

de datos (host, usuario, contraseña y base de datos a crear). La aplicación utilizara los parámetros que

indique33 para realizar una conexión estándar34 al servidor MySQL y crear una nueva base de datos con

el nombre que indique (si no existiese previamente) y las tablas necesarias junto a un usuario

administrador por defecto. Tenga en cuenta que la contraseña no será enmascarada (y será visible en

pantalla) mientras la teclee.

Tras crear la base de datos, se crearán archivos de configuración por defecto a partir de los datos

proporcionados durante la instalación.

31 La instalación y configuración de Apache, PHP y MySQL (y sus dependencias) está fuera del alcance de este manual. 32 Si existiesen conflictos entre los archivos de la aplicación y cualquier otro preexistente, se aconseja realizar la instalación en otro directorio y configurar un host virtual en Apache para la aplicación. 33 Utilizar “localhost” como dirección del servidor MySQL puede provocar que se intente conectar al servidor utilizando sockets UNIX. En caso de ser necesario, generalmente podrá forzar el uso de conexiones TCP utilizando “127.0.0.1” como dirección del servidor. 34 Utilizando los métodos que PHP dispone a tal efecto. La aplicación asume que la conexión al servidor MySQL es segura y, por tanto, no dispone de métodos de configuración más avanzados, como el uso explícito de sockets UNIX o la encriptación de la conexión por medio de SSL.



Figura 6.4: Finalización de la instalación

Una vez finalizada la instalación, la aplicación será accesible en el subdirectorio webcmmse del servidor

web. En caso de haber realizado la instalación en el directorio raíz público del servidor, podrá acceder

a ella en http://<ip del servidor>/webcmmse/index.php

Figura 6.5: Página de inicio de la aplicación recién instalada



6.1.3 Consideraciones de seguridad

Tenga en cuenta que la aplicación instalada mediante el procedimiento del apartado anterior tendrá

asignados los permisos de acceso a los archivos por defecto, lo cual puede impedir que el servidor web

acceda a ellos total o parcialmente. Se aconseja tomar las siguientes precauciones:

- Dar acceso de solo lectura y entrada en los directorios webcmmse, conf y data para el usuario

bajo el cual se ejecuta el servidor web.

- Mantener el acceso completo (lectura y escritura, además del permiso de entrada (x)) a los

directorios webcmmse/facturas y webcmmse/papers para el usuario bajo el cual se ejecuta el

servidor web35.

- Impedir que el servidor web sirva archivos de los directorios conf, data, private y scripts, bien

creando archivos .htaccess en los mismos, o bien a través de la configuración global del

servidor almacenada (normalmente) en el archivo /etc/httpd/conf/httpd.conf.

6.1.4 Configuración inicial de la aplicación

Tras la instalación inicial, que únicamente crea los archivos y la base de datos y genera la configuración

estática, será necesario realizar una serie de comprobaciones y ajustes antes de utilizar la aplicación

en un entorno de producción.

En general, las tareas de configuración deberán realizarse siguiendo los siguientes subapartados en el

orden en que son expuestos.

Rutas de archivo

La aplicación por defecto está configurada para operar desde el directorio webcmmse de la raíz del

servidor web. En caso de que esto no sea adecuado (por ejemplo, porque ha cambiado el nombre del

directorio o está sirviendo la página utilizando hosts virtuales) deberá editarse el archivo webcmmse.ini

(dentro del directorio conf) para remplazar todas las referencias a webcmmse en las rutas relativas de

la sección “web” por el nombre del directorio raíz utilizado.

La referencia a CMMSE_BASE_DIR de los comentarios del archivo de configuración se refiere al

directorio padre de webcmmse, es decir, el indicado como directorio de destino durante la instalación.

Conversión de errores PHP en excepciones

La aplicación, por defecto, está configurada para convertir en excepciones todos los errores que se

produzcan durante su ejecución en lugar de mostrar éstos como mensajes informativos en los

contenidos generados (HTML, CSS…). Esto permite capturar los errores y finalizar mostrando un

mensaje de “Error interno” al usuario (junto a un encabezado HTTP 500 de Error Interno del Servidor)

35 En caso de no disponer de permiso de escritura en estos directorios, la aplicación informará de ello en la página de configuración general de la interfaz de administración.



en lugar del mensaje de error generado por PHP, que puede representar un riesgo de seguridad al

contener, generalmente, el nombre de archivo y línea en la que se produce el error.

El valor por defecto debería ser el adecuado en la práctica totalidad de situaciones. Sin embargo, si se

necesita revertir el control de errores a su comportamiento por defecto se deberá cambiar el valor del

parámetro use_errorexception de webcmmse.ini a false. Si fuera necesario, se aconseja, además,

modificar la configuración del propio servidor web para que oculte los errores y no los muestre en los

contenidos generados.

Registro de depuración en disco

Inicialmente la aplicación está configurada para no registrar los mensajes de depuración de su

actividad en archivos de disco y, en su lugar, los muestra en la consola de errores del intérprete de PHP

(que para el servidor integrado de desarrollo de PHP será la salida estándar que éste tenga asociada).

Esto es apropiado para la depuración de errores durante el desarrollo; sin embargo, no es adecuado

para un entorno de producción.

Para cambiar el comportamiento del registro de errores deberá modificar la configuración del

componente log4php utilizado por la aplicación a través del archivo log4php.xml del directorio conf.

Como medida de seguridad se recomienda guardar el registro de depuración en un archivo en disco,

partiendo del archivo de ejemplo log4php-di143.xml situado en el mismo directorio y modificando la

ruta en la que se generan los archivos de registro. Tenga en cuenta que el directorio que indique aquí

no será generado automáticamente, y deberá crearlo previamente y asignar permisos de escritura en

el mismo para el usuario bajo el que se ejecute el servidor web.

Cambio de la contraseña de root por defecto

La aplicación no dispone de un método para cambiar la contraseña de administración directamente

(desde la interfaz web) por razones de seguridad. En lugar de ello, se dispone de un shell script que

deberá ejecutarse en el servidor para realizar el cambio.

Desde una sesión de consola en el servidor (local o remota), deberá situarse en el directorio de scripts

de la aplicación (/var/www/scripts si ha utilizado la ruta por defecto) y ejecutar

./set_root_password.sh. Tras ello, se utilizará el intérprete PHP-cli del servidor y la configuración de la

aplicación para solicitarle la contraseña actual de administrador y, si es correcta, la nueva contraseña.

Parámetros de la conferencia y de envío de correo

Tras la instalación y la configuración inicial de los parámetros básicos de la aplicación (incluyendo el

cambio de la contraseña de administrador), deberá configurar los parámetros de la conferencia y de

envío de correos electrónicos. Éstos últimos son usados para el envío de notificaciones, entre las cuales

se encuentran avisos a los administradores sobre papers enviados y pagos realizados, y mensajes

informativos para los ponentes sobre el estado de envío de sus papers. Tenga en cuenta que estos

parámetros también podrán ser modificados de nuevo más adelante si fuese necesario, y que los

cambios en los mismos tienen efecto de forma inmediata.



Figura 6.6: Procedimiento de cambio de la contraseña de administrador

Tras iniciar sesión en la aplicación como administrador, deberá acceder a la sección de configuración

utilizando el enlace a la misma de la barra superior. Se mostrará una nueva página en la que podrá

habilitar el acceso público y el envío de papers, y establecer los números de factura.

Además, se le mostrará la ruta de los directorios que usa la aplicación para almacenar los papers y

justificantes de pago enviados por los usuarios, y se le informará en caso de que el la aplicación haya

detectado la imposibilidad de utilizar los citados directorios debido a problemas con los permisos del

sistema de archivos o limitaciones asociadas al usuario o al proceso del servidor web (lo cual impedirá

el envío de los mismos desde las páginas públicas).



El primer grupo de parámetros, relativos a la información de la conferencia, tendrá asignados

parámetros por defecto tras la instalación, y deberá modificarlos para reflejar los datos reales de la

conferencia y la edición de la misma a administrar por la aplicación. Este grupo incluye datos sobre las

fechas de celebración, lugar, URL de la página informativa de la presente edición, identificadores para

las publicaciones, identificador fiscal (para las facturas generadas), cuota de inscripción y parámetros

asociados al diseño de las etiquetas generadas. Todos los parámetros podrán ser modificados

posteriormente; sin embargo, se recomienda completar este grupo de parámetros (o revisar que los

valores por defecto son correctos) como paso inicial de configuración tras la instalación.

Figura 6.7: Configuración de acceso y números de factura en un entorno de producción

Cada grupo de parámetros debe configurarse de forma independiente. Cuando termine de completar

el formulario de Información de la conferencia utilice el botón “Guardar” situado al final del mismo

para escribir los cambios en la base de datos.



Figura 6.8: Configuración de la información de la edición actual de la conferencia

A continuación deberá configurar los parámetros de envío de correos: servidor SMTP a utilizar, tipo de

encriptación y datos de autentificación del mismo (si fuesen necesarios), y la dirección y nombre del

remitente de los correos enviados automáticamente por el sistema. Cuando termine de definir la

configuración de la conexión deberá guardarla utilizando el botón “Guardar” situado al final de los

campos disponibles a tal efecto.

También podrá definir una lista de direcciones de correo a las cuales enviar las notificaciones

automáticas generadas por la aplicación. Podrá dejar la lista en blanco (lo cual deshabilita las

notificaciones) o especificar una o varias direcciones a las que enviarlas separadas por comas. Como

en los casos anteriores, tras modificar la lista de destinatarios de las notificaciones utilice el botón

“Guardar” situado bajo ésta para guardar los cambios introducidos.



Figura 6.9: Configuración del servidor SMTP a utilizar en un entorno de producción

Por último, se recomienda que verifique que el envío de correo funciona correctamente, comprobando

que no hay problemas en los parámetros de conexión y autentificación SMTP o restricciones de otro

tipo en la red del servidor que impidan que éste envíe las notificaciones. Para ello, introduzca una

dirección de correo a la cual usted tenga acceso en el cuadro de texto situado junto a la etiqueta

“Enviar e-mail de prueba a” (al final de la página) y pulse sobre el botón “Comprobar funcionamiento”.

Figura 6.10: Formulario para el envío de un correo de prueba

Este proceso puede demorarse unos segundos. Si todo es correcto deberá ser redirigido a una página

con información de depuración (los mensajes intercambiados entre la aplicación y el servidor SMTP),

y llegará un correo electrónico de prueba breve a la dirección que haya indicado. En caso de haberse

producido errores, podrá verlos en la salida de depuración mostrada.

En algunos casos la salida de depuración podría mostrarse en blanco y el correo electrónico no llegará

a enviarse. Generalmente esto es síntoma de problemas a nivel de red (por ejemplo, restricciones de

firewalls software, como iptables, o de la red local en la que se encuentra el servidor).

Una vez que haya configurado todos los parámetros de la pestaña de configuración se recomienda que

siga los pasos del manual de administración para introducir la información de los simposios que



tendrán lugar durante el congreso, las salas de las que se dispondrá y las excursiones que se llevarán

a cabo.

Figura 6.11: Salida de depuración mostrada tras el envío de un correo de prueba

Figura 6.12: Correo electrónico de prueba recibido en la dirección proporcionada



6.2 Manual de usuario

6.2.1 Registro, login y gestión de cuenta de usuario

Registro de nuevo usuario

Para registrarse en la conferencia, deberá acceder al formulario para introducir sus datos a través del

botón “Register now” disponible en la página de inicio de la aplicación. Se le solicitarán sus datos

personales (incluyendo nombre, dirección y teléfono), una dirección de correo electrónico y una

contraseña.

Figura 6.13: Formulario de registro de nuevo usuario

Tenga en cuenta que la dirección de correo electrónico introducida no podrá ser modificada

posteriormente, y será usada tanto a modo de nombre de usuario para acceder a la aplicación como

para el envío de notificaciones automáticas y de los organizadores de la conferencia.



Tras completar y enviar el formulario, si los datos introducidos son correctos, se le redirigirá a la página

de inicio de sesión. Además, se le enviará un correo electrónico a la dirección proporcionada

confirmando su registro.

Figura 6.14: Notificación enviada confirmando el registro



Login de usuario

Para acceder a la aplicación deberá acceder al formulario de inicio de sesión a través del botón “Login”

disponible en la página de inicio.

Figura 6.15: Formulario de inicio de sesión

En el formulario deberá introducir la dirección de correo electrónico utilizada durante el registro y su

contraseña, y hacer clic sobre el botón “Login”. Si los datos son correctos se le redirigirá a la página

principal de la interfaz de ponente, donde se le mostrará su información de registro.



Figura 6.16: Página principal de la interfaz de ponente

En cualquier momento podrá finalizar su sesión en la aplicación utilizando el enlace “Log out” situado

a la derecha del menú superior. Además, dependiendo de la configuración del servidor, es posible que

su sesión sea finalizada automáticamente por la aplicación tras un periodo prolongado de inactividad

en la misma.

Modificar datos personales

Una vez identificado en la aplicación con su cuenta de ponente, podrá modificar sus datos personales

a través del enlace etiquetado con su dirección de correo electrónico disponible en la parte superior

derecha de la aplicación. Este enlace está disponible en todas las páginas mientras se encuentre

identificado en la aplicación36.

Una vez en la página de edición de perfil, se le mostrará un formulario done podrá modificar su

nombre, institución asociada, dirección y teléfono. Tenga en cuenta que la dirección e institución

asociada introducidos aquí pueden ser distintos de los utilizados para emitir la factura para el pago de

los gastos de inscripción, ya que éstos son tratados de forma independiente.

Tras modificar sus datos, haga clic en el botón “Save” para guardarlos y volver a la página principal de

la interfaz de ponente. Si, por el contrario, decide que no quiere mantener los cambios realizados

36 La funcionalidad del botón “Change data” de la página principal de la interfaz de ponente es equivalente a la del enlace mencionado, y permite acceder al mismo formulario.



puede utilizar el botón “Return” para volver a la página principal de la interfaz de ponente sin

guardarlos.

Figura 6.17: Formulario de edición de datos personales

Modificar contraseña

Para modificar su contraseña deberá acceder a la página principal de la aplicación (utilizando el enlace

etiquetado como “Home” de la esquina superior izquierda) y hacer clic en el botón “Change Password”.

Se le mostrará una nueva página con tres campos de texto en los que deberá introducir su contraseña

actual y la nueva contraseña. Las contraseñas se mostrarán enmascaradas mientras las teclee. Tenga

en cuenta, además, que la nueva contraseña deberá introducirse dos veces para evitar posibles

errores.

Figura 6.18: Formulario de cambio de contraseña



La contraseña de usuario debe tener una longitud mínima de 6 caracteres, y en caso de que la nueva

contraseña introducida no cumpla este requisito se le informará de ello tras introducir su valor (antes

de su envío). En caso de que introduzca incorrectamente la contraseña anterior, se le volverá a mostrar

el formulario de edición y su contraseña no será modificada. De manera similar, no se realizarán

cambios si la nueva contraseña y su confirmación no coinciden.

Figura 6.19: Errores mostrados durante la edición del formulario de cambio de contraseña

Figura 6.20: Error mostrado al no proporcionar correctamente la contraseña actual

Figura 6.21: Error mostrado cuando la nueva contraseña y su confirmación no coinciden

Tras introducir los datos y hacer clic en el botón “Save”, si los datos son correctos, el sistema actualizará

la contraseña asociada a su cuenta de usuario y será redirigido a la página principal de la interfaz de

ponente. En caso de que decida no cambiar su contraseña mientras está en el formulario, puede volver

a la página principal de la interfaz de ponente utilizando el botón “Return”. Si utiliza cualquier otro

enlace de la interfaz mientras se encuentra en esta página su contraseña tampoco será modificada.



Restablecer contraseña perdida

Si ha olvidado su contraseña, podrá restablecerla a través del enlace “Lost password?” disponible en

el formulario de login de usuario. En la siguiente página se le pedirá que introduzca la dirección de

correo electrónico asociada a su cuenta. Una vez la haya introducido, haga clic en el botón “Send new

password”; si la dirección proporcionada es correcta, se le enviará su nueva contraseña por correo

electrónico y será llevado al formulario de login.

Figura 6.22: Formulario para restablecer la contraseña de usuario

Deberá haber recibido un correo electrónico en la dirección asociada a su cuenta que contendrá su

nueva contraseña, que podrá utilizar en el formulario de login. Una vez identificado en la aplicación,

podrá cambiar su contraseña por otra que le sea más fácil de recordar siguiendo los pasos del apartado

anterior.

Figura 6.23: Correo electrónico con la nueva contraseña enviado tras restablecer la misma



6.2.2 Envío y gestión de papers

Envío de un nuevo paper

Para enviar un nuevo paper deberá acceder a la pestaña “Paper” identificado con su cuenta de

ponente. En caso de que el plazo de envío esté abierto, se le mostrará un formulario donde podrá

introducir los datos del paper y seleccionar el archivo a enviar.

Figura 6.24: Formulario para el envío de un nuevo paper

En caso de que el plazo de envío se encuentre cerrado (bien por no haberse iniciado aún o por haber

terminado), se le mostrará un mensaje informándole de ello en lugar del formulario anterior.

Introduzca los datos del formulario y seleccione el archivo que contiene el artículo a presentar en la

conferencia. Deberá seleccionar una de las sesiones disponibles en “Special Session &

Minisymposiums”, introducir el título del artículo, la lista de autores37 (hasta 9) y marcar el checkbox

correspondiente en caso de que haya preparado un poster asociado al artículo.

37 Su cuenta quedará asociada al paper como corresponding author, el cual no es necesariamente parte de los autores del mismo. Desde el punto de vista de la aplicación esto significa que su cuenta de usuario será la única habilitada para su gestión, incluyendo el envío de nuevas versiones. Además, su cuenta será asociada al mismo a efectos contables (su presentación estará sujeta a la confirmación del pago de la cuota de inscripción desde su cuenta de usuario).



Figura 6.25: Mensaje mostrado en la página de envío de papers cuando el plazo está cerrado

El archivo enviado en este paso, el título y la lista de autores no podrán ser modificados por usted

posteriormente, aunque sí podrá enviar un nuevo archivo asociado al artículo.

Figura 6.26: Formulario cumplimentado para el envío de un nuevo paper

Tras terminar de cumplimentar el formulario, haga clic en el botón “Submit” para enviar los datos del

artículo. Tenga en cuenta que el envío del artículo no garantiza su presentación en el congreso; tras el

envío los administradores iniciarán un proceso de revisión del mismo. Tanto al iniciarse la revisión de



un artículo como en el momento en el que es aceptado para su presentación en el congreso se le

enviará un mensaje por correo electrónico informándole de ello.

Además, para evitar que dos o más ponentes envíen un mismo paper (por ejemplo, un paper del que

varios usuarios son coautores), el sistema no permitirá el envío de un paper cuyo título coincida con el

de algún otro paper enviado previamente por cualquier usuario.

En caso de que desee enviar varios archivos en el envío inicial o en el envío de la versión definitiva,

podrá hacerlo enviando un archivo comprimido con tantos archivos como desee (siempre que el

tamaño del archivo enviado no supere los límites establecidos en el servidor web).

Cuando el envío se complete, será llevado nuevamente a la página de envío de papers, la cual ahora

mostrará el paper recién enviado en la parte superior. Los papers mostrados en la parte superior

permiten acceder a una página para gestionar los mismos y ver su estado; la funcionalidad del

formulario inferior seguirá estando asociada al envío de papers nuevos.

Figura 6.27: Formulario de envío de un nuevo paper listando un paper enviado previamente



Información y borrado de papers enviados

Desde la sección de papers, haciendo clic sobre el icono situado sobre el título de alguno de los papers

enviados, podrá acceder a la página de detalle del mismo. En esta página podrá ver el título del

simposio al que está asociado, su título y un indicador sobre si el mismo fue enviado como paper con

poster asociado. Además, se le mostrará la lista de autores.

Mientras el paper no haya entrado en revisión también podrá eliminarlo utilizando el botón “Delete”.

Tenga en cuenta que esta acción no puede deshacerse, aunque podrá repetir el proceso de envío.

Figura 6.28: Página de detalle de un paper antes de entrar en proceso de revisión

Figura 6.29: Página de detalle de un paper tras entrar en proceso de revisión



Una vez que los organizadores hayan revisado y aceptado el artículo enviado para su presentación en

el congreso, recibirá un correo electrónico de confirmación con instrucciones e información adicional.

Además, al acceder a la página de detalle del paper enviado, se le permitirá enviar un archivo adicional

que será asociado a éste como una nueva versión38.

Figura 6.30: Correo electrónico de confirmación enviado tras la aceptación de un paper

38 Sólo se permite un archivo adicional asociado a cada paper. Típicamente esta funcionalidad es usada para enviar la versión definitiva (revisada) del paper a presentar o un archivo con el poster asociado al paper (si lo hay). En caso de necesitar enviar más de un archivo adicional, puede subirlos al servidor en un archivo comprimido, o enviarlos por correo electrónico a la dirección indicada en la notificación de aceptación del paper.



Envío de nueva versión de un paper existente

Desde la página de detalle de los papers, para aquellos que ya hayan sido revisados y aceptados por

los organizadores para su presentación en el congreso, podrá enviar versiones revisadas de los mismos.

Para ello deberá incluir un nuevo archivo a enviar en el campo “New versión of paper”. Tenga en cuenta

que solo se mantendrá en el servidor los archivos asociados al envío original y al último envío del paper.

Figura 6.31: Formulario de envío de nuevas versiones de papers

Tras el nuevo envío, volverá a ser llevado a la página de detalle del paper, en la cual ahora aparecerá

listado el nombre de archivo de la última versión enviada.

Figura 6.32: Formulario de envío de nuevas versiones de papers tras el envío de una revisión

Tenga en cuenta, además, que no podrá enviar nuevas versiones de los papers una vez que el plazo de

envío esté cerrado: en este caso la aplicación le informará de ello mostrando la misma pantalla que en

el caso de envío de nuevo paper cuando el plazo está cerrado.



6.2.3 Gestión de pagos y datos fiscales

Tras registrarse en el congreso, deberá acreditar el pago de la cuota de inscripción a través de la

aplicación. Para realizar el pago deberá consultar la cantidad a ingresar y el número de cuenta en la

página de información general del congreso39, y obtener un archivo electrónico que acredite el pago a

través de la página web de su banco, solicitándolo en una sucursal física o escaneando el comprobante

en papel facilitado por su entidad bancaria.

La aplicación contempla dos modalidades de pago, dependiendo de si desea que se genere una factura

a pagar por una institución (por ejemplo, si su compañía o universidad se hará cargo del pago) o si solo

desea un justificante que acredite el pago. En el primer caso deberá proporcionar información

adicional para la emisión de una factura numerada (nombre de la institución que realizará el pago y

CIF asociado o número de identificación tributaria equivalente en su país de origen); en el segundo

caso no necesitará proporcionar información adicional y se le proporcionará una prueba de pago no

numerada. Los datos introducidos permitirán a los organizadores generar la documentación que

acredita el pago, la cual se le proporcionará físicamente y/o por correo electrónico según la

organización estime oportuno.

Una vez identificado en la aplicación, podrá acceder a la página de gestión de pagos a través de la

pestaña ”Payments / Invoices” del menú principal de la interfaz de ponente.

Figura 6.33: Página principal de la interfaz de gestión de pagos

39 http://gsii.der.usal.es/cmmse2014/ para la edición de 2014



Registro y modificación de datos fiscales

Al hacer clic en el enlace “Payments / Invoices” del menú superior de la interfaz de ponente accederá

a la página de gestión de pagos. Una vez en ella, si desea que la organización emita una factura

numerada asociada al pago de su cuota de inscripción, deberá hacer clic sobre el botón etiquetado

“Do you need invoice? Click here”, tras lo cual se le mostrará un formulario donde introducir los datos

de la factura a emitir.

Los datos que introduzca en esta página serán asociados a su cuenta de usuario, y no tienen que

coincidir necesariamente con los datos utilizados durante el proceso de registro. Por ejemplo, la

institución que pagará la factura puede diferir de la utilizada durante el proceso de registro de su

cuenta de usuario.

Para la emisión de la factura deberá completar todos los campos: su nombre tal como desea que se

muestre en la factura, nombre de la institución que correrá con los gastos, su número de identificación

fiscal y su dirección postal. Si no ha introducido estos datos previamente, inicialmente se le mostrará

el formulario en blanco (y el campo nombre mostrará un valor por defecto a partir de sus datos

personales); en otro caso se mostrarán los datos proporcionados previamente y podrá modificarlos.

Figura 6.34: Página de registro y modificación de datos fiscales y envío de justificante de pago

Borrado de datos fiscales

Por defecto el sistema genera justificantes de pago simples para los gastos de inscripción. En caso de

que haya solicitado la emisión de una factura numerada (proporcionando para ello todos los datos

necesarios siguiendo los pasos del apartado anterior) y más adelante prefiera un justificante de pago

no asociado a una institución en su lugar, podrá acceder a la pantalla de gestión de pagos y hacer clic

en el botón “Delete invoice info, don’t need it”. El sistema borrará los datos adicionales guardados y

la organización le proporcionará un justificante de pago simple en su lugar.



Envío de justificante de pago

Desde la pantalla de gestión de pagos, una vez haya efectuado el ingreso de la cuota de inscripción

siguiendo los pasos de la página web de la conferencia, deberá enviar un justificante de pago en

formato digital. Para ello, deberá seleccionar el archivo que contenga el justificante a través del campo

“Proof of Payment” y hacer clic en el botón “Save”. Solo se permite realizar este paso mientras el pago

no se haya confirmado.

Figura 6.35: Pantalla para el envío del justificante de pago antes de su envío

Tras el envío, la pantalla anterior cambiará mostrando un botón que le permitirá visualizar el archivo

enviado.

Figura 6.36: Pantalla para el envío del justificante de pago tras su envio

En caso de que sea necesario, podrá enviar un nuevo justificante siguiendo el procedimiento anterior

tantas veces como desee (por ejemplo, en caso de que se equivoque al seleccionar el archivo a enviar)

mientras su pago de la cuota de inscripción no haya sido confirmado por parte de los organizadores.

Una vez que su pago se confirme, los datos de pago introducidos no podrán ser modificados.



Proceso de confirmación del pago

Tras el envío inicial del justificante, podrá modificar los datos del mismo (en caso de solicitar factura:

nombre, CIF e institución que correrá con los gastos) o enviar un nuevo justificante de pago hasta que

los organizadores confirmen manualmente el pago de su cuota de inscripción.

En caso de no haber solicitado factura numerada, tras la confirmación del pago no podrá enviar un

nuevo justificante. Sin embargo, podrá proporcionar la información adicional necesaria para la emisión

de factura. Si lo hace, el pago necesitará pasar nuevamente por el proceso de confirmación por parte

de los organizadores, durante el cual se le asignará un número de factura.

Cuando su pago haya sido confirmado, se le informará de ello en la pantalla de gestión de pagos.

Además, en caso de haber solicitado factura, se le mostrará la información utilizada para la emisión de

la misma.

Figura 6.37: Pantalla para el envío del justificante de pago tras la confirmación del mismo

6.2.4 Acceso a los calendarios iCal

La aplicación pone a disposición de los usuarios de calendarios en formato electrónico iCal con la

programación de exposición de posters y la fecha y hora de inicio de cada simposio. Para acceder a

ellos, desde las páginas de ponente, dispondrá de dos enlaces en la parte interior junto a la etiqueta

“Download iCal”. El acceso a los calendarios no requiere registro ni login previos.

Estos calendarios pueden ser o bien descargados para luego ser abiertos con una aplicación de gestión

de calendarios, o bien importados directamente (copiando y pegando su URL) a otros servicios como

Google Calendar. Normalmente esta última opción permite, además, mantener el calendario

actualizado con los últimos cambios de horarios registrados en la aplicación y consultarlos desde

dispositivos móviles, y es el uso que se espera de los mismos por parte de los ponentes.



Figura 6.38: Calendario de inicio de los simposios

Figura 6.39: Calendario de exposición de posters

Figura 6.40: Calendario de exposición de posters (formato de agenda)



6.3 Manual de administración

6.3.1 Acceso a la interfaz de administración y

configuración general

Acceso a la interfaz de administración

Para acceder a la interfaz de administración deberá acceder al formulario de inicio de sesión a través

del botón “Login” disponible en la página de inicio.


Como e-mail deberá introducir “root”, y como contraseña la utilizada durante la instalación. Tras hacer

clic sobre el botón “Login”, si los datos son correctos, se le redirigirá a la interfaz de administración.

Por defecto se le mostrará la página de gestión de usuarios.

En cualquier momento podrá finalizar su sesión en la aplicación utilizando el enlace “Logout”

disponible en el submenú mostrado tras hacer clic en el enlace etiquetado con el nombre de usuario

usado para acceder a la interfaz de administración (este enlace está situado a la derecha del menú

superior). Además, dependiendo de la configuración del servidor, es posible que su sesión sea

finalizada automáticamente por la aplicación tras un periodo prolongado de inactividad en la misma.



Configuración general de la aplicación

A través del enlace “Configuración” disponible en el menú superior de la interfaz de administración

podrá acceder a una página para modificar los parámetros generales de la conferencia (año, fechas,

estilo de los documentos generados, numeración de las facturas…) y obtener información sobre los

directorios utilizados para guardar los archivos enviados por los usuarios.

Para obtener información detallada sobre el uso y modificación de estos parámetros y la información

mostrada en esta página, refiérase al apartado “Configuración de parámetros y de envío de correos”

del Manual de instalación.

Además de los parámetros anteriores, dispondrá de botones para habilitar o deshabilitar el acceso

público (es decir, el registro y la identificación con cuentas de ponente) y para habilitar o deshabilitar

el plazo de envío de papers:

- Deshabilitar el acceso público provoca que los ponentes vean el mensaje “Public access is

closed” al intentar hacer login (tras enviar sus credenciales), lo cual impide el uso completo de

la aplicación para todos los usuarios a excepción de los administradores.

- Deshabilitar el envío de papers hace que los ponentes previamente identificados vean el

mensaje “Submission closed” en la pestaña de gestión de papers, lo cual impide únicamente

el envío de nuevos papers y la modificación de los existentes por parte de los ponentes.

6.3.2 Gestión de salas

La aplicación permite registrar las salas que estarán disponibles durante la celebración del congreso.

Para ello deberá acceder a la opción “Salas” disponible en el menú superior de la interfaz de

administración. Las salas introducidas aquí podrán ser asignadas más adelante a la exposición de

papers de tipo poster.

En esta página se le mostrará un listado con el nombre de las salas actualmente registradas junto al

número de posters asignados a las mismas y un botón que permite su borrado. Además, dispondrá de

un formulario en la parte superior para la creación de nuevas salas.



Figura 6.42: Interfaz de gestión de salas

Creación de nueva sala

Para registrar una nueva sala, desde la interfaz de gestión de salas, deberá introducir su nombre en el

campo de texto disponible en la parte superior de la página y hacer clic en el botón “Add new room”.

Tras ello se recargará el listado de salas, mostrando la nueva sala en el mismo.

Figura 6.43: Formulario de creación de una nueva sala

Edición de sala

Desde la interfaz de gestión de salas podrá modificar el nombre de las salas existentes. Para ello deberá

hacer clic en el botón “Edit” disponible a la derecha de los nombres de éstas, tras lo cual el nombre de

la sala seleccionada será remplazado por un cuadro de texto. Una vez introducido el nuevo nombre

podrá guardarlo permanentemente utilizando el botón verde, tras lo cual se le mostrará el listado de

salas actualizado.



Figura 6.44: Formulario de modificación de nombre de sala

También podrá cancelar la edición del nombre de la sala haciendo clic en el botón rojo marcado con

un aspa.

Borrado de sala

Para borrar una sala existente, desde el listado de salas, deberá utilizar el botón etiquetado como

“Delete” disponible en la última columna para la sala que desee eliminar. Tenga en cuenta que solo se

permite el borrado de salas que no estén asignadas a ningún poster40. La aplicación no le pedirá

confirmación para el borrado, pues podrá deshacerse introduciendo una nueva sala con el nombre de

la sala borrada. Tras realizar el borrado se recargará la página, mostrando el listado sin la sala

eliminada.

6.3.3 Gestión de simposios

Antes de habilitar el acceso público a la página, se recomienda definir los simposios en los que se

organizará el congreso. Durante el envío de los papers, los usuarios seleccionarán el simposio que

crean más adecuado para su presentación. Es recomendable, además, incluir un simposio genérico

para los envíos que no encajen en ninguna de las categorías predefinidas.

Para introducir los datos de los simposios deberá acceder a la opción “Conferencias” disponible en el

menú superior de la interfaz de administración. Los simposios introducidos aquí serán los que serán

mostrados a los usuarios durante el envío de nuevos papers. Además, las fechas de inicio que se

introduzcan aquí serán usadas en los calendarios iCal disponibles de forma pública para los ponentes.

En esta página se le mostrará un listado con el nombre de los simposios definidos actualmente junto

a su fecha y hora de inicio previstas, además de botones para la edición de sus atributos y el borrado

de aquellos que no tengan papers asignados. Además, dispondrá de un formulario en la parte superior

de la página para definir nuevos simposios.

40 En caso de que no esté permitido el borrado de una sala, el botón de borrado correspondiente a la misma se mostrará en color gris para indicar que la acción está deshabilitada.



Figura 6.45: Interfaz de gestión de simposios

Creación de un nuevo simposio

Para registrar un nuevo simposio, desde la interfaz de gestión de simposios, deberá introducir su

nombre en el campo de texto disponible en la parte superior de la página y hacer clic en el botón “Add

new conference”. Tras ello, se recargará el listado de simposios, mostrando el simposio recién creado

en el mismo.

Figura 6.46: Formulario de creación de un nuevo simposio

Edición de simposio

Desde la interfaz de gestión de simposios podrá modificar el nombre de los simposios existentes. Para

ello deberá hacer clic en el botón “Edit” disponible a la derecha de los nombres de éstos, tras lo cual

el nombre del simposio seleccionado será remplazado por un cuadro de texto. Una vez introducido el

nuevo nombre podrá guardarlo permanentemente utilizando el botón verde, tras lo cual se le mostrará

el listado de simposios actualizado.

Figura 6.47: Edición del nombre de un simposio



Además, podrá modificar la fecha y hora de inicio de un simposio haciendo clic en el botón “Edit”

situado a la derecha de la fecha y hora configurada actualmente. Tras ello, se le mostrará un calendario

donde podrá seleccionar la nueva fecha41 . Igualmente, seleccionando la hora programada podrá

cambiarla, introduciendo un nuevo valor con el teclado o usando las flechas disponibles a la derecha

del valor actual. Tras introducir la nueva fecha y hora podrá guardarla permanentemente utilizando el

botón verde, tras lo cual se le mostrará el listado de simposios actualizado.

Figura 6.48: Edición de la fecha de inicio de un simposio

Borrado de simposios

Para borrar simposio, desde el listado de simposios, deberá utilizar el botón etiquetado como “Delete”

disponible en la última columna para el simposio que desee eliminar. Tenga en cuenta que solo se

permite el borrado de simposios que no tengan papers asignados 42 . La aplicación no le pedirá

confirmación para el borrado, pues podrá deshacerse introduciendo un nuevo simposio con el nombre

del simposio borrado. Tras realizar el borrado se recargará la página, mostrando el listado de simposios

actualizado.

6.3.4 Gestión de excursiones

La aplicación permite a los administradores un registro y gestión básico de todas aquellas actividades

adicionales que no se corresponden con el ámbito estándar de la conferencia, como visitas organizadas

o la asistencia a eventos lúdicos o culturales durante los días en los que se celebra, y que no están

relacionadas necesariamente con la presentación de papers o la exposición de resultados de estudios

académicos. En adelante, nos referiremos a las distintas actividades adicionales gestionadas desde

esta sección bajo el término genérico Excursiones.

Para acceder a la página de gestión de excursiones deberá acceder a la opción “Excursiones” disponible

en el menú superior de la interfaz de administración. Las actividades introducidas aquí serán utilizadas

41 Dependiendo del grado de soporte de su navegador del estándar HTML5, es posible que la edición de la fecha y hora utilizando los controles aquí descritos no esté disponible. En tal caso, deberá introducir la nueva fecha y hora a través de un cuadro de texto tradicional, respetando el formato utilizado por el valor que se muestre por defecto. En cualquier caso, el formato de la fecha y hora introducidas aquí será validado en última instancia por la aplicación que se ejecuta en el servidor web. 42 En caso de que no esté permitido el borrado de un simposio, el botón de borrado correspondiente al misma se mostrará en color gris para indicar que la acción está deshabilitada.



más adelante para generar las hojas de etiquetas correspondientes. En esta página se le mostrará un

listado con el nombre de las actividades actualmente registradas junto a un botón que permite su

borrado. Además, dispondrá de un formulario en la parte superior para el registro de nuevas

excursiones programadas.

Figura 6.49: Interfaz de gestión de excursiones

Registro de una nueva excursión

Para registrar una nueva excursión, desde la página de gestión de excursiones, deberá introducir su

nombre en el campo de texto disponible en la parte superior de la página y hacer clic en el botón “Add

new trip”. Tras ello, se recargará el listado, mostrando la excursión recién creada en el mismo.

Figura 6.50: Creación de una nueva excursión

Borrado de los datos de una excursión

Para borrar una excursión, desde el listado de excursiones, deberá utilizar el botón etiquetado como

“Delete” disponible en la última columna para la excursión que desee eliminar. La aplicación no le

pedirá confirmación para el borrado, pues podrá deshacerse introduciendo una nueva excursión con

el nombre de la excursión borrada. Tras realizar el borrado se recargará la página, mostrando el listado

de excursiones actualizado.



6.3.5 Gestión de usuarios

Para gestionar los ponentes registrados deberá acceder a la opción “Usuarios” disponible en el menú

superior de la interfaz de administración. Desde esta pantalla podrá ver una lista con todos los

ponentes registrados, borrar ponentes de forma individual, generar los certificados de asistencia

asociados todos o parte de ellos y descargar distintos tipos de hojas de etiquetas.

En esta página se le mostrará un listado con el nombre de todos los ponentes registrados hasta el

momento, su institución asociada, ciudad, estado y país, la dirección de correo electrónico usada para

el registro, su dirección postal y su teléfono. Además, en la parte superior de la página dispondrá de

enlaces para la descarga de certificados de asistencia, de hojas de etiquetas y del propio listado de

usuarios.

Figura 6.51: Interfaz de gestión de usuarios

En función del ancho de pantalla del dispositivo usado para acceder al panel de administración, es

posible que parte de las columnas de datos sean ocultadas automáticamente, o que los botones de

descarga de certificado y borrado para los usuarios individuales sean remplazados por versiones con

un ancho menor. En caso de ser necesario, este efecto podrá ser revertido utilizando el botón

“Deshacer” disponible junto al mensaje informativo mostrado en la parte superior del listado.

Figura 6.52: Listado de usuarios adaptado a un ancho de pantalla menor

En la parte superior derecha de la página dispondrá de un botón con una lista desplegable para

descargar el listado de usuarios completo en un archivo independiente en formato Excel o HTML.



Descarga de certificados de asistencia

La aplicación permite la descarga de certificados que acrediten la asistencia al congreso a nombre de

los ponentes registrados. Para ello deberá acceder a su página de gestión utilizando el enlace

correspondiente de la parte superior de la página.

El archivo PDF generado contendrá una página por cada certificado solicitado. La descarga de

certificados de asistencia puede realizarse de cuatro formas diferentes:

- Mediante enlaces situados en la segunda columna del listado, disponible únicamente para

aquellos usuarios que hayan pagado la cuota de inscripción, si dicho pago ha sido confirmado.

Estos enlaces tienen la apariencia de un botón azul con la etiqueta “Certificado”.

- Seleccionando un subconjunto de usuarios, utilizando el checkbox disponible en la primera

columna para aquellos que cumplan los requisitos del apartado anterior y haciendo clic en el

botón azul “Certificados asistencia seleccionados” situado en la parte superior de la página.

- Solicitando todos los certificados de los usuarios que cumplan los requisitos del primer caso,

haciendo clic en el botón blanco “Certificados de asistencia han pagado” situado en la parte

superior de la página.

- Solicitando certificados para todos los usuarios (sin importar si el pago ha sido confirmado),

haciendo clic en el botón “Certificados asistencia todos” situado en la parte superior de la

página.

En el caso de seleccionar un subconjunto de ponentes, las filas correspondientes a los ponentes

seleccionados serán resaltadas en el momento en que marque el checkbox correspondiente.

Figura 6.53: Listado de usuarios con usuarios seleccionados



Figura 6.54: Certificado de asistencia



Descarga de etiquetas

La aplicación permite la descarga de hojas de etiquetas de diferentes tipos con el propósito de

identificar a los asistentes y a los organizadores durante el congreso. Para ello deberá acceder a la

página de gestión de usuarios utilizando el enlace correspondiente de la parte superior de la página.

La aplicación proporciona los siguientes tipos de etiquetas:

- Etiquetas identificativas para los asistentes al congreso.

Se generará un documento con varias páginas que contendrá una etiqueta por cada

ponente registrado. Las etiquetas indicarán el nombre del ponente, su institución

asociada y su país de procedencia. El color de fondo de estas etiquetas será azul.

- Etiquetas para la asistencia a la Cena de Gala celebrada durante el congreso.

Se generará un documento con una única página con varias etiquetas no nominativas

con la leyenda “Dinner Gala”. El color de fondo de estas etiquetas será verde.

- Etiquetas para la asistencia a las excursiones y actividades adicionales.

Se generará un documento con una página por cada actividad programada. Cada

página contendrá etiquetas para la asistencia a una única actividad (mostrando el

título de la misma). El color de estas etiquetas será morado.

- Etiquetas identificativas para los miembros de la organización.


con la leyenda “Organization”. El color de estas etiquetas será rojo.

- Etiquetas de restaurante.


con la leyenda “Restaurant Ticket”. El color de estas etiquetas será amarillo.

- Etiquetas en blanco.

Se generará un documento con una única página con varias etiquetas (similares a las

etiquetas de asistencia) con un recuadro en blanco. Estas etiquetas están pensadas

para ser usadas para cualquier otro propósito no contemplado durante el desarrollo

de la aplicación.

Para descargar los archivos PDF con las etiquetas, deberá acceder a la página de gestión de usuarios y

utilizar los botones situados en la parte superior de la misma. El tamaño y la orientación de las

etiquetas generadas variará en función de la configuración de la aplicación. Para obtener información

detallada sobre la modificación de estos parámetros, refiérase al apartado “Configuración de

parámetros y de envío de correos” del Manual de instalación.

Figura 6.55: Botones de descarga de etiquetas



Figura 6.56: Hoja de etiquetas de asistencia (horizontales; 15 x 7,5 cm)



Figura 6.57: Hoja de etiquetas de asistencia (horizontales; 9,2 x 6,25 cm)



Figura 6.58: Hojas de etiquetas de asistencia (verticales)



Figura 6.59: Hoja de etiquetas de asistencia a la cena de gala (horizontales; 15 x 7,5 cm)



Figura 6.60: Hoja de etiquetas de asistencia a la cena de gala (horizontales; 9,2 x 6,25 cm)



Figura 6.61: Hoja de etiquetas de asistencia a excursiones (horizontales; 15 x 7,5 cm)



Figura 6.62: Hoja de etiquetas de asistencia a excursiones (horizontales; 9,2 x 6,25 cm)



Figura 6.63: Hoja de etiquetas identificativas para los organizadores (horizontales; 15 x 7,5 cm)



Figura 6.64: Hoja de etiquetas identificativas para los organizadores (horizontales; 9,2 x 6,25 cm)



Figura 6.65: Hoja de etiquetas de restaurante (horizontales; 15 x 7,5 cm)



Figura 6.66: Hoja de tickets de restaurante (horizontales; 9,2 x 6,25 cm)



Figura 6.67: Hoja de etiquetas en blanco (horizontales; 15 x 7,5 cm)



Figura 6.68: Hoja de etiquetas en blanco (horizontales; 9,2 x 6,25 cm)



Figura 6.69: Hoja de etiquetas en blanco (verticales)



Borrado de usuario

Para borrar un usuario, desde el listado de usuarios, deberá utilizar el botón etiquetado como “Delete”

disponible en la última columna para el usuario que desee eliminar. La aplicación le pedirá

confirmación para el borrado43. Tras realizar el borrado se recargará la página, mostrando el listado de

usuarios actualizado.

El borrado de un usuario implica la eliminación de forma permanente de todos sus datos asociados

(papers, justificantes de pago e información de facturación, incluyendo todos los archivos subidos por

el usuario al servidor). Esta acción no puede deshacerse.

Notificaciones de registro de usuario

Tras el registro de un nuevo ponente, la aplicación enviará un correo electrónico notificando la

creación del nuevo usuario a la lista de direcciones de correo configuradas en la pestaña de

Configuración general. Los mensajes de correo generados serán similares al siguiente:

Figura 6.70: Notificación de registro de nuevo usuario

6.3.6 Gestión de pagos: Facturas y justificantes

La aplicación permite gestionar el pago individual de cada ponente en función de los datos que éste

proporcione. Se distinguen dos casos: aquellos ponentes que han solicitado la emisión de una factura

numerada y aquellos que no lo han hecho.

En el primer caso, el ponente habrá indicado a nombre de quién desea que se emita la factura, qué

institución (académica, comercial…) se hará cargo del pago, una dirección postal y un número de

identificación fiscal asociado a la misma (por ejemplo, un CIF en el caso de instituciones españolas o

43 En caso de que su navegador no soporte Javascript o se encuentre deshabilitado, no se le pedirá confirmación.



un Identificador de Contribuyente (Taxpayer ID) en el caso de empresas estadounidenses)44. Utilizando

estos datos, el sistema generará una factura numerada.

En el segundo caso, el ponente no habrá proporcionado los datos del apartado anterior (o, si los ha

proporcionado, se trata de datos incompletos o que han sido eliminados posteriormente por el propio

ponente). Por tanto, el sistema generará un justificante simple, asociado al nombre del ponente y

firmado por la organización del congreso, que podrá ser utilizado para acreditar que el pago de la cuota

de inscripción se ha realizado.

Por defecto, el sistema genera justificantes de pago simples. Mientras el pago de su cuota de

inscripción no haya sido confirmado, los ponentes son libres de cambiar de un tipo de documento a

otro proporcionando o borrando los datos fiscales necesarios desde las páginas de gestión de su cuenta

de usuario.

Al hacer clic en la opción “Pagos” del menú superior de la interfaz de administración se mostrará un

menú con las opciones Facturas y Justificantes. Escogiendo una u otra opción accederá al listado de

usuarios que han solicitado factura o al listado de aquellos que no lo han hecho.

Figura 6.71: Menú de acceso a las páginas de gestión de facturas y justificantes de pago

En los siguientes subapartados se indica cómo realizar las acciones que son comunes tanto para los

usuarios que solicitan factura numerada como para aquellos que solo han solicitado un justificante

simple, mientras que el resto de acciones de gestión (que dependen de la modalidad de pago) están

detalladas en los apartados específicos de Gestión de facturas y Gestión de justificantes de pago.

Modificación de cuotas de inscripción

Por defecto, los ponentes tienen asignada una cuota predeterminada (modificable desde la pestaña

de Configuración general) pero, en caso de ser necesario, la aplicación permite modificar la cuota de

inscripción a pagar de forma individual por cualquier usuario45.

Para ello, tanto para los ponentes que han solicitado factura como para los que no lo han hecho, y para

cada uno de ellos, se dispone de un cuadro de texto en la columna etiquetada como “Total a pagar”.

44 Debido a la variedad de formatos de identificadores fiscales existentes en el mundo y al carácter internacional del congreso, la aplicación no realiza ningún tipo de validación del formato del identificador proporcionado por los usuarios. 45 La modificación de las cuotas de inscripción individuales requiere que el navegador utilizado soporte realizar solicitudes HTTP en segundo plano (AJAX).



En el caso de los ponentes que han solicitado factura, la modificación de la cuota de inscripción sólo

puede realizarse para aquellos cuya factura no haya sido marcada como Lista para imprimir, en cuyo

caso la fila correspondiente mostrará el valor a pagar pero no permitirá su modificación. Para los

ponentes que no han solicitado factura (y, por tanto, solo requieren un justificante de pago simple) la

modificación de su cuota de inscripción puede realizarse en cualquier momento.

Tras modificar el valor mostrado y hacer clic en el botón “Guardar” disponible a su derecha la nueva

cuota de inscripción para el usuario quedará registrada en la base de datos, y será la que se utilice

posteriormente para generar su factura o su justificante de pago.

Figura 6.72: Formulario de modificación de cuota de inscripción

Igualmente, para volver a asignar la cuota por defecto a un usuario, podrá borrar el valor mostrado

(esto es, dejar el recuadro de texto en blanco) y hacer clic en el botón “Guardar”. Tras ello, su cuota

de inscripción personalizada será borrada de la base de datos y el cuadro de texto volverá a mostrar la

cuota por defecto.

Los usuarios a los que no se ha asignado una cuota de inscripción personalizada muestran el texto

“(auto)” junto al cuadro de texto usado para modificarla.

Confirmación de pagos

Para cada usuario mostrado en los listados (tanto de facturas como de justificantes simples) se dispone,

en la columna etiquetada como “Pagado”, de un enlace indicando si el pago del usuario ha sido

confirmado (esto es, el pago ya ha sido confirmado para los usuarios en los que este enlace muestra

el texto “Yes” y viceversa). Al hacer clic en dicho enlace el pago cambiará de estado, pasando a estar

confirmado o no en función de cuál fuera su estado anterior.

Esta acción puede ser revertida en cualquier momento haciendo clic de nuevo en el enlace, con la

excepción de aquellos usuarios que han solicitado factura y ésta ha sido marcada como Lista para

imprimir. En el caso de usuarios que no han indicado los datos necesarios para emitir una factura,

podrán hacerlo aunque el pago de su cuota de inscripción haya sido confirmado, tras lo cual un

administrador deberá revisar dichos datos, asignar un número de factura y marcar su factura como

Lista para imprimir. Los usuarios que solicitan factura no pueden modificar los datos de pago una vez

que el pago ha sido confirmado (aunque sí podrán consultar los datos proporcionados).

Para facilitar la labor de los administradores, la aplicación notificará por correo electrónico a la lista de

direcciones configurada para este propósito cada vez que un usuario envíe un justificante de pago.



Figura 6.73: Notificación enviada al recibir un nuevo justificante de pago

6.3.7 Gestión de facturas

Para gestionar los pagos de los usuarios que hayan solicitado la emisión de una factura numerada

deberá acceder a la opción “Facturas” disponible al hacer clic en el enlace “Pagos” disponible en el

menú superior de la interfaz de administración. Desde esta pantalla podrá acceder a la lista con los

datos básicos (nombre, dirección de correo electrónico y país) de todos los ponentes que han solicitado

factura numerada, ver los documentos que éstos han enviado para acreditar el pago, modificar la cuota

a pagar de manera individual y los números de factura, confirmar pagos y generar las facturas que

acreditan que el pago correspondiente ha sido confirmado por los organizadores. Además, dispondrá

de dos botones para asignar números de factura secuenciales de manera automática para todos los

ponentes.

La página de gestión de facturas mostrará una fila por cada ponente que haya solicitado factura. En

ellas, para los ponentes que hayan enviado previamente un documento para justificar el pago,

dispondrá de un enlace para descargar el archivo enviado (a través del botón etiquetado como

“Justificante” disponible en las filas correspondientes), además de los controles necesarios para

realizar las diferentes acciones de gestión individuales.

Figura 6.74: Interfaz de gestión de facturas



Descarga de facturas

En la parte superior de la página dispondrá de dos botones para descargar en un único archivo PDF las

facturas generadas por la aplicación. En función de qué usuarios se desee considerar, la aplicación

permite obtener las facturas de tres formas diferentes:

- Seleccionando un subconjunto de los usuarios que han solicitado factura, de entre aquellos

cuyo pago ha sido confirmado, utilizando el checkbox disponible para éstos en la primera

columna del listado y haciendo clic en el botón verde “Descargar facturas seleccionados”

situado en la parte superior de la página.

- Solicitando las facturas de todos los usuarios que la hayan solicitado, cumplan los requisitos

del apartado anterior y cuya factura haya sido revisada y marcada como lista para imprimir,

haciendo clic en el botón verde “Descargar facturas listas para imprimir”.

- Solicitando la factura de un único usuario cuyo pago haya sido confirmado, haciendo clic en el

botón “Factura” de la fila asociada al usuario correspondiente.



Figura 6.75: Listado de usuarios con factura solicitada con usuarios seleccionados

Asignación de números de factura

Antes de marcar una factura como lista para imprimir, es necesario que se le asigne a ésta un número

de factura. Para ello se dispone de un cuadro de texto en la columna “Número de factura” que permite

modificarlo. Además, se dispone de dos botones en la parte superior del listado para asignar de forma

automática los números de factura para todos los ponentes que residan en España y para aquellos que

residan en el extranjero.

En el caso de la asignación automática de números de factura, se asignarán números correlativos a

partir de los datos introducidos en la pestaña de Configuración general. Los números de factura se

asignan de forma creciente en el caso de las facturas para España y de forma decreciente para el

extranjero.



Figura 6.76: Factura generada por la aplicación



Confirmación de datos de factura

Tras revisar los datos de pago de un usuario y la asignación de un número de factura, deberá confirmar

los datos marcando el checkbox “Lista para imprimir” asociado a la misma (situado en la primera

columna). Esta acción hará que las facturas correspondientes sean incluidas en el archivo descargable

de facturas listas, y no puede ser deshecha. Además, impide que el ponente modifique los datos

relativos al pago desde la pestaña correspondiente de la interfaz pública.

Figura 6.77: Detalle de la numeración de facturas y facturas listas para imprimir

6.3.8 Gestión de justificantes de pago

Para gestionar los pagos de los usuarios que no hayan solicitado factura deberá acceder a la opción

“Justificantes” disponible al hacer clic en el enlace “Pagos” disponible en el menú superior de la interfaz

de administración. Desde esta pantalla podrá acceder a la lista con los datos básicos (nombre, dirección

de correo electrónico y país) de todos los ponentes que no han solicitado factura numerada, ver los

documentos que éstos han enviado para acreditar el pago, modificar la cuota a pagar de manera

individual, confirmar pagos y generar los certificados de pago (“justificantes”) que acreditan que el

pago correspondiente ha sido confirmado por los organizadores.

La página de gestión de justificantes mostrará una fila por cada ponente que no haya solicitado factura.

En ellas, para los ponentes que hayan enviado previamente un documento para justificar el pago,

dispondrá de un enlace para descargar el archivo enviado (a través del botón etiquetado como

“Justificante” disponible en las filas correspondientes), además de los controles necesarios para

realizar las diferentes acciones de gestión individuales.



Figura 6.78: Interfaz de gestión de justificantes de pago simple

Descarga de justificantes de pago

En la parte superior de la página dispondrá de tres botones para descargar en un único archivo PDF los

certificados de pago generados por la aplicación. En función de qué usuarios se desee considerar, la

aplicación permite obtener los certificados de tres formas diferentes:

- Seleccionando un subconjunto de los usuarios que no han solicitado factura, de entre aquellos

cuyo pago ha sido confirmado, utilizando el checkbox disponible para éstos en la primera

columna del listado y haciendo clic en el botón verde “Descargar justificante seleccionados”


- Solicitando los certificados de pago de todos los usuarios que no hayan solicitado factura y

cumplan los requisitos del apartado anterior, haciendo clic en el botón verde “Descargar

justificante todos han pagado”

- Solicitando certificados de pago para para todos los usuarios que no hayan solicitado factura

(sin importar si el pago ha sido confirmado), haciendo clic en el botón “Descargar justificante

todos”





Figura 6.79: Listado de usuarios con justificantes de pago simple con usuarios seleccionados



Figura 6.80: Justificante de pago generado por la aplicación



6.3.9 Gestión de papers

Para gestionar los papers enviados deberá acceder a la opción “Papers” disponible en el menú superior

de la interfaz de administración. Desde esta pantalla podrá gestionar el ciclo de revisión de los papers,

gestionar posters y solicitar los certificados de presentación asociados todos o parte de los papers

registrados en el sistema. En esta página se le mostrará un listado con el título de todos los papers

enviados hasta el momento, sus fechas de envío, la dirección de correo electrónico del usuario que lo

envió y el simposio al cual está asociado. Además, en la parte superior de la página dispondrá de

enlaces para descargar certificados de presentación de ponencias y del propio listado.

Figura 6.81: Interfaz de gestión de los papers enviados

Junto a cada paper, y en función del número de archivos enviados asociados a cada uno, se mostrará

uno o dos botones etiquetados como “File 1” y “File 2” para su descarga. También dispondrá de dos

botones en la parte superior derecha para descargar el listado de papers en un archivo independiente

en formato Excel o HTML.



Modificación del título de un paper

La aplicación permite a los administradores editar los títulos de los papers registrados en el sistema,

de forma que puedan corregirse errores cometidos por los usuarios durante su envío o modificarlos

por cualquier otra razón que se estime conveniente. Para ello, desde la pantalla de gestión de papers,

deberá localizar el paper que desea modificar y hacer clic sobre su título; el título del paper será

remplazado por un cuadro de texto para modificarlo.

Para guardar los cambios de deberá hacer clic sobre el botón marcado en verde situado junto al cuadro

de texto usado para editar el título.

Figura 6.82: Formulario de edición del ltítulo de paper

Los datos mostrados se actualizarán en el momento, y se mostrará un mensaje en la parte superior de

la página informando de que los cambios han sido guardados. En caso de que después de haber

iniciado la edición decida mantener el título anterior podrá utilizar el botón marcado en rojo (situado

junto al anterior)46.

Proceso de revisión y aceptación de un paper

Tras el envío de un paper por parte de los ponentes, el proceso de revisión del mismo pasa por la

notificación del envío a los administradores, la confirmación de su recepción (marcando el paper como

En proceso de revisión) y finalmente su aceptación, si procede. Una vez que un paper ha sido aceptado,

el ponente dispone de la opción de enviar nuevas versiones del paper y/o archivos adicionales

relacionados con el mismo. Algunos de los cambios en el estado del proceso de revisión implican,

además, el envío de notificaciones por correo electrónico a las direcciones de correo configuradas con

este propósito y/o al ponente que realiza el envío.

46 Si el navegador lo soporta, la modificación de los títulos se realiza utilizando solicitudes HTTP en segundo plano (AJAX), por lo que el resto de cambios que hubiese pendientes durante la misma no se perderán. En otro caso, será llevado a una nueva página para realizar la modificación.



Figura 6.83: Notificación enviada a los administradores tras el envío de un nuevo paper

Inmediatamente después de producirse el envío de un nuevo paper, el sistema enviará una notificación

a los administradores con los datos del mismo. Tras ello, el paper se mostrará en la lista de envíos de

la sección de Papers de la interfaz de gestión, junto a la fecha del envío, el simposio elegido por el

ponente para su presentación, la dirección de correo electrónico del ponente y una indicación según

si el paper ha sido enviado como poster o no. En caso afirmativo, además, se podrá editar la sala y la

fecha y hora de inicio y fin de la exposición del mismo.

Figura 6.84: Nuevo paper listado en la página de administración antes de entrar en revisión

Tras la recepción del paper, un administrador podrá descargarlo para proceder a su revisión haciendo

clic en el botón etiquetado como “File 1” de la entrada correspondiente de la lista de papers enviados.

Para indicar el inicio de la misma, el administrador deberá marcar el checkbox “Iniciada revisión”47.

47 Para marcar el inicio de proceso de revisión de un paper es necesario que el navegador del administrador que realiza el proceso soporte la realización de solicitudes AJAX. El inicio del proceso de revisión de un paper no implica el envío de notificaciones a los administradores ni a los ponentes.



Esta acción impide el borrado del paper por parte del ponente, el cual verá un mensaje informando de

este hecho en la página asociada al paper de la sección de Papers de la interfaz de gestión de ponentes.

El inicio del proceso de revisión de un paper es registrado en la base de datos, y puede demorarse

tanto como sea necesario. En particular, un administrador puede iniciar el proceso de revisión de un

paper, descargar el archivo asociado para su revisión y terminar la misma (aceptando el paper o

desmarcando el campo “Iniciada revisión”) en distintos momentos, iniciando una nueva sesión en la

aplicación con la cuenta de administración días después de haber iniciado la revisión. Igualmente el

proceso de finalización de revisión o la aceptación del paper puede realizarse desde un equipo y/o una

IP diferente a la que inició el proceso.

Para aceptar un paper para su presentación en el congreso, una vez que éste ha entrado en proceso

de revisión, deberá hacer clic en el campo “Aceptado” asociado al mismo48. Tras marcar un paper como

aceptado, el sistema enviará sendas notificaciones al ponente que lo envío y a la lista de direcciones

configurada para recibir notificaciones administrativas, y puede demorarse unos segundos.

Figura 6.85: Notificación enviada a los administradores tras aceptar un paper

Tras la aceptación de un paper, el ponente que lo envió podrá enviar un archivo adicional asociado al

mismo. En este caso se notificará de ello a los administradores por correo electrónico, pero el paper

se mantendrá en estado aceptado. El ponente podrá enviar un segundo archivo (sic) tantas veces como

desee, pero solo se mantendrán los archivos asociados al primer y al último envío de cada paper.

Todos los envíos implican el envío de notificaciones a las direcciones de correo electrónico

configuradas con este propósito. El archivo asociado al segundo envío de un paper, en caso de haberse

producido, puede descargarse haciendo clic en el botón etiquetado como “File 2” de la entrada

correspondiente de la lista de papers enviados.

48 Para aceptar un paper es necesario que el navegador del administrador que realiza el proceso soporte el uso de solicitudes HTTP en segundo plano (AJAX).



Figura 6.86: Notificación enviada a los administradores tras recibir una nueva versión de un paper

Tenga en cuenta que la aceptación de un paper implica el envío de un mensaje de correo electrónico

informando de ello al ponente asociado al mismo y que, aunque está soportado por la aplicación,

aceptar varias veces un paper (tras desmarcarlo como aceptado) implica el envío de varios mensajes

al ponente (uno por cada vez que se acepta), por lo que este proceso debe realizarse con cuidado. Por

favor, refiérase a la sección “Envío y gestión de papers” del manual de usuario para ver un ejemplo del

correo electrónico enviado al ponente en el momento en que uno de sus papers es aceptado por los

administradores.

Modificación de salas asignadas a la exposición de posters

Para los papers enviados como posters, la aplicación permite el registro de la sala en la que serán

expuestos y las fechas y horas de inicio y fin de exposición. Para ello, desde la pantalla de gestión de

papers, deberá localizar el poster que desea modificar y hacer clic sobre el enlace Editar situado junto

al intervalo de fechas y horas asignadas actualmente para el mismo.

El valor actual será remplazado por un formulario donde podrá seleccionar una sala y el horario. Para

facilitar la gestión, se permite seleccionar una sala en blanco (por ejemplo, en caso de que el lugar de

exposición no haya sido escogido o si sus datos no están aún en el sistema). Para guardar los cambios

de deberá hacer clic sobre el botón marcado en verde situado al final del formulario. En caso de que

tras iniciar la edición decida mantener los valores anteriores podrá utilizar el botón marcado en rojo49.

49 La modificación de la sala y las fechas asignadas requiere que el navegador soporte solicitudes HTTP en segundo plano (AJAX). El resto de cambios que hubiese pendientes durante esta acción no se perderán.



Figura 6.87: Formulario de edición de sala y fechas de presentación de posters



Descarga de certificados de presentación de ponencias

La aplicación permite la descarga de certificados que acrediten la presentación de las ponencias a

nombre de los usuarios asociados al envío de cada paper. Para ello deberá acceder a su página de

gestión utilizando el enlace correspondiente de la parte superior de la página.

El archivo PDF generado contendrá una página por cada certificado solicitado. La descarga de

certificados de presentación de ponencias puede realizarse de cuatro formas diferentes:

- Mediante enlaces situados en la última columna del listado, disponible únicamente para

aquellos papers aceptados cuyo ponente asociado haya pagado la cuota de inscripción, si dicho

pago ha sido confirmado. Estos enlaces tienen la apariencia de un botón azul con la etiqueta

“Certificado”.

- Seleccionando un subconjunto de papers aceptados, utilizando el checkbox disponible en la

penúltima columna para aquellos que cumplan los requisitos del apartado anterior y haciendo

clic en el botón verde “Certificados de ponencias seleccionadas” situado en la parte superior

de la página.

- Solicitando todos los certificados de los papers que cumplan los requisitos del primer caso,

haciendo clic en el botón verde “Certificados de ponencias han pagado” situado en la parte

superior de la página.

- Solicitando todos los certificados de los papers aceptados (sin importar si el ponente asociado

ha realizado el pago), haciendo clic en el botón verde “Certificados de ponencias todos”


En el caso de seleccionar un subconjunto de papers, las filas correspondientes a los papers

seleccionados serán resaltadas en el momento en que seleccione el checkbox correspondiente.

Figura 6.88: Listado de papers con papers seleccionados



Figura 6.89: Certificado de presentación de ponencia



6.3.10 Consulta de información estadística

Además de las labores de gestión de las distintas entidades asociadas al congreso (como la revisión de

papers, la definición de simposios y actividades, o la gestión de pagos), la aplicación permite la consulta

de una serie de datos estadísticos básicos generados a partir de la información recogida como parte

del uso que los ponentes hacen de la misma.

La interfaz dispone de dos módulos para la consulta de datos estadísticos. El primero de ellos muestra

qué usuarios han enviado papers para su presentación en el congreso, el número de envíos y datos

sobre su procedencia, además de permitir descargar un informe asociado. El segundo muestra un

resumen estadístico básico agregado sobre los papers enviados, los usuarios registrados y la

información de procedencia disponible sobre éstos.

Además, la aplicación guarda en la base de datos, de forma estructurada, información adicional sobre

el uso de la misma. Esta información incluye, para cada solicitud HTTP recibida:

IP del cliente que realiza la solicitud.

URI solicitada.

Número de consultas SQL y método utilizado (a través del ORM o consulta directa sobre la

BBDD).

Presencia de proxy y, en su caso, IP real que realiza la solicitud (si ha sido posible su detección).

Navegador y sistema operativo del cliente (si ha proporcionado esta información).

Fecha y hora de inicio y fin de la solicitud (calculadas en el servidor), y carga media del sistema

en el instante de finalización de la misma.

IP, nombre, sistema operativo y versión del mismo instalados en el servidor que atiende la

solicitud50.

Esta información no es accesible directamente desde la interfaz web, pero puede consultarse mediante

una conexión directa a la base de datos utilizando SQL. Se registra también información de depuración

detallada para todas las solicitudes en archivos .log. Esta información incluye modelos involucrados, el

texto de las consultas SQL realizadas, controladores ejecutados y métodos invocados en los mismos,

entre otros, y está pensada para la detección y corrección de errores graves en la aplicación en caso

de ser necesario.

50 En nuestro caso se dispone de un único servidor y estos datos son idénticos para todas las muestras. Sin embargo, podrían ser útiles en configuraciones con varios servidores web frontend o para diagnosticar errores producidos por actualizaciones del kernel, cambios en la configuración de red y/o en sistemas redundantes que dispongan de varios servidores web ejecutándose en diferentes distribuciones Linux o variantes de UNIX (BSD, Solaris, …).



Listado de autores

A través de la opción “Autores” disponible en el menú superior de la interfaz de administración se

dispone de un listado de todos los usuarios registrados que han enviado algún paper para su

presentación en el congreso. Para cada uno de ellos se muestran nombre y apellidos, institución

asociada, país de procedencia, número de papers enviados y cuántos de ellos son de tipo poster.

Figura 6.90: Listado de autores

Además, en la parte inferior de la página, se dispone de un enlace para descargar los datos del listado,

incluyendo además la dirección de correo asociada a cada usuario, en un archivo Excel.

Figura 6.91: Enlace de descarga de la lista de autores en formato Excel

Información estadística agregada

Para acceder a las estadísticas generales deberá utilizar el enlace “Resumen” disponible en el menú

superior. A partir de los datos disponibles esta página muestra:

- Número total de papers enviados y papers aceptados.

- Número de ponentes registrados, y número de ponentes cuyo pago ha sido confirmado.

- Proporción de papers aceptados y totales por autor, y por autor cuyo pago ha sido confirmado.

- Países de procedencia de los usuarios (gráficamente, mediante un mapa del mundo).

Al pasar el ratón por encima de las gráficas de proporción de papers aceptados y usuarios que han

pagado se muestra un popup indicando los datos correspondientes a cada parte de la gráfica.

Igualmente, el mapa de países de procedencia mostrado en la parte inferior permite una vista

detallada del número total de ponentes de cada país al pasar el ratón sobre cada uno de ellos.

Al igual que ocurre en el listado de autores, la información de esta página se actualiza en tiempo real

en función de los datos registrados en el sistema cada vez que es cargada.



Figura 6.92: Página de estadísticas agregadas



6.3.11 Registro de editores

La versión actual de la aplicación no dispone de un mecanismo integrado para el registro de editores

o la asignación de permisos de editor a usuarios existentes (al tratarse de una funcionalidad raramente

utilizada). Por tanto, este proceso deberá realizarse de forma manual a través de una conexión directa

a la base de datos de la aplicación.

Para convertir una cuenta de ponente existente en una cuenta de editor deberá utilizar un programa

cliente MySQL para conectarse al servidor de base de datos utilizado y ejecutar la siguiente consulta

SQL una vez seleccionada la base de datos utilizada por la palicación (remplazando [email protected] por la

dirección de correo del usuario a modificar):

SELECT iduser,firstname,lastname,email FROM usuarios WHERE email = ‘[email protected]’;

La consulta anterior deberá mostrar el ID del usuario, nombre y apellidos asociados a la dirección de

correo proporcionada. Si los datos son correctos y coinciden con los del usuario que desea modificar,

ejecute la siguiente consulta replazando el valor 123 mostrado en ella por el valor de identificador de

usuario obtenido por la consulta SELECT anterior (mostrado en la columna “iduser”):

UPDATE usuarios SET typeuser=3 WHERE id=123

Tras ello, cuando el usuario que acaba de modificar inicie sesión, será llevado a la interfaz de editor en

lugar de a la de ponente.



6.4 Manual de editor

6.4.1 Acceso a la lista de papers enviados

Para acceder a la lista de papers deberá acceder al formulario de inicio de sesión a través del botón

“Login” disponible en la página de inicio.


Para iniciar sesión deberá introducir los datos facilitados por la organización. Tenga en cuenta que

como e-mail deberá introducir el nombre de usuario que le proporcione la organización, el cual no

tendrá necesariamente el formato de una dirección de correo. Tras hacer clic sobre el botón “Login”,

si los datos son correctos, se le redirigirá a la lista de papers enviados.

En cualquier momento podrá finalizar su sesión en la aplicación utilizando el enlace “Logout”

disponible a la derecha del menú superior (este menú será siempre visible en la parte superior de la

página, incluso cuando realice scroll para desplazarse por la lista de papers). Además, dependiendo de

la configuración del servidor, es posible que su sesión sea finalizada automáticamente por la aplicación

tras un periodo prolongado de inactividad en la misma.



6.4.2 Descarga de papers disponibles

Tras iniciar sesión, accederá a un listado simple de todos los papers enviados. Para cada uno se le

mostrará el título del paper y del simposio al que está asignado, y un icono para la descarga del archivo

asciado.

Figura 6.94: Interfaz de editor

6.4.3 Acceso a los calendarios iCal

La aplicación pone a disposición de los usuarios de calendarios en formato electrónico ICal con la

programación de exposición de posters y la fecha y hora de inicio de cada simposio. Para acceder a

ellos, desde las páginas de ponente, dispondrá de dos enlaces en la parte interior junto a la etiqueta

“Download iCal”. El acceso a los calendarios no requiere registro ni login previos.

Por favor, refiérase al apartado de “Acceso a los calendarios iCal” del manual de usuario para obtener

más detalles sobre su uso y un ejemplo de los datos disponibles al importar los calendarios a Google

Calendar u otro servicio similar.

Plataforma web para la gestión de conferencias científico-técnicas | Pruebas


7 PRUEBAS

7.1 Pruebas de uso en un entorno real

A partir del 1 de Marzo de 2014 se han puesto en producción de forma periódica versiones parciales

de la aplicación (prototipos), que han sido usadas por los ponentes y los organizadores para la

inscripción y gestión del congreso hasta su finalización. Durante este periodo se ha seguido una

metodología de trabajo basada en versiones parcialmente funcionales, dando prioridad a la

implementación de nuevas funcionalidades a medida que era necesario su uso en función de los

propios plazos de las distintas fases de inscripción y envío de papers requeridos por la organización.

En este periodo la implementación de nuevas funcionalidades se ha llevado a cabo de forma

simultánea a la corrección de los errores detectados en los distintos prototipos a medida que iban

surgiendo. Para esta labor, ha resultado de capital importancia los mecanismos de instrumentación y

registro de depuración (log4php) presentes en la aplicación, así como el feedback proporcionado por

los organizadores y los propios asistentes al congreso.

7.2 Pruebas unitarias

Durante el desarrollo se han definido pruebas unitarias para comprobar el correcto funcionamiento

de partes clave de la aplicación. Esto ha permitido la automatización de parte de las pruebas necesarias

y la detección automática de errores surgidos durante el desarrollo.

Estas pruebas no cubren casos de uso completos. En lugar de ello, están diseñadas para testear los

diferentes componentes de la aplicación de forma individual y automática, como mecanismo para

garantizar la calidad de la aplicación desarrollada durante todo el proceso y evitar posibles problemas

de regresión introducidos en las sucesivas iteraciones.

Para la implementación de estas pruebas se ha utilizado el framework open source PHPUnit. Estas

pruebas no cubren la aplicación completa. En lugar de ello se han centrado principalmente en la

verificación automática de los modelos y la documentación electrónica generada por la aplicación,

garantizando la consistencia de los modelos de datos entre sí y respecto a la información almacenada

en la base de datos, y las postcondiciones definidas sobre los datos generados por sus métodos.

En total se han definido 347 pruebas que se corresponden con TestCases de PHPUnit, realizando un

total de 3971 comprobaciones básicas (asserts) de las postcondiciones que deben cumplir los

resultados retornados por diferentes métodos de la aplicación. Para cada una se incluye su

identificador, una descripción, el resultado esperado y el resultado obtenido. El conjunto de baterías

incluye 4 pruebas cuyo resultado no es satisfactorio debido a funcionalidades que no pueden ser

testeadas de forma automática o a errores reales en la validación de direcciones de correo. Estas

pruebas han sido documentadas debidamente en los apartados correspondientes.

Pruebas | Plataforma web para la gestión de conferencias científico-técnicas


7.2.1 Tests\Core

AbstractControllerTestCase

Identificador Core\AbstractControllerTestCase#testGetModel

Descripción Comprueba que la obtención desde los controladores de instancias de modelos a partir de sus interfaces funciona correctamente.

R. Esperado Obtención de una instancia de un modelo que implemente la interfaz solicitada y herede del modelo abstracto.

Resultado Satisfactorio

Identificador Core\AbstractControllerTestCase#testOnConstruct

Descripción Comprueba que se invoca al método de inicialización definido por los controladores si éstos implementan la interfaz necesaria, y que no se producen errores para los controladores que no implementan dicha interfaz.

R. Esperado El método de inicialización es invocado para aquellos controladores que implementan la interfaz necesaria. El método de inicialización no es invocado para aquellos controladores que no implementan la interfaz necesaria.


Identificador Core\AbstractControllerTestCase#testChainRequestNoParams

Descripción Comprueba que la invocación de acciones de controladores sin proporcionar parámetros funciona correctamente.

R. Esperado Obtención de la respuesta generada por la acción del controlador invocada.


Identificador Core\AbstractControllerTestCase#testChainRequestNoParamsWithParam

Descripción Comprueba que la invocación de acciones de controladores que no esperan parámetros proporcionando parámetros funciona correctamente y produce una llamada al controlador de errores definido.

R. Esperado Invocación del manejador de errores de página no encontrada.


Identificador Core\AbstractControllerTestCase#testChainRequestDefaultAction

Descripción Comprueba que la invocación de la acción por defecto para controladores que la han definido funciona correctamente.

R. Esperado Obtención de la respuesta generada por la acción por defecto del controlador.


Identificador Core\AbstractControllerTestCase#testChainRequestNoDefaultAction

Descripción Comprueba que la invocación de la acción por defecto para controladores que no la han definido funciona correctamente y produce una llamada al controlador de errores definido.





Identificador Core\AbstractControllerTestCase#testChainRequestOneParamWithParam

Descripción Comprueba que la invocación de acciones de controladores que esperan parámetros cuando éstos se proporcionan funciona correctamente y produce una llamada a la acción correspondiente.

R. Esperado Obtención de la respuesta generada por la acción invocada


Identificador Core\AbstractControllerTestCase#testChainRequestOneParamNoParams

Descripción Comprueba que la invocación de acciones de controladores que esperan parámetros cuando se le proporciona un array con cero parámetros funciona correctamente y no produce una llamada al controlador de errores definido.

R. Esperado Obtención de la respuesta generada por la acción invocada sin que se invoque al controlador de errores.


Identificador Core\AbstractControllerTestCase#testChainRequestCatchAllAction

Descripción Comprueba que la invocación de la acción de captura de solicitudes aleatorias de un controlador, cuando ésta ha sido definida, funciona correctamente y no produce una llamada al controlador de errores definido.

R. Esperado Obtención de la respuesta generada por la acción por defecto sin que se produzcan errores.


Identificador Core\AbstractControllerTestCase#testChainRequestCatchAllWrongSignature

Descripción Comprueba que la acción de captura de solicitudes aleatorias de un controlador, cuando los parámetros de ésta no han sido definidos correctamente, no llega a invocarse.

R. Esperado La función de captura de solicitudes aleatorias no es invocada.


Identificador Core\AbstractControllerTestCase#testNoRoute

Descripción Comprueba que la llamada a acciones no definidas por un controlador, cuando éste no define una acción de captura de solicitudes aleatorias, produce una llamada al controlador de errores definido.



AbstractFrontControlerTestCase

Identificador Core\AbstractFrontControllerTestCase#testDispatchNoURIInfo

Descripción Comprueba que el frontcontroller base lanza una excepción en caso de el servidor no haya proporcionado la URI de la página solicitada.

R. Esperado La función encargada de despachar las solicitudes HTTP recibidas produce una excepción.




Identificador Core\AbstractFrontControllerTestCase#testDispatchRequestURI

Descripción Comprueba que el frontcontroller base redirige las solicitudes a la acción oportuna basándose en la URI solicitada y devuelve el resultado generado por ella.

R. Esperado La función encargada de despachar las solicitudes HTTP recibidas retorna el contenido generado por la acción correcta del controlador Homepage.


Identificador Core\AbstractFrontControllerTestCase#testDispatchPathInfo

Descripción Comprueba que el frontcontroller base redirige las solicitudes a la acción oportuna basándose en la variable de entorno CGI PATH_INFO si ésta está definida y devuelve el resultado generado por ésta.

R. Esperado La función encargada de despachar las solicitudes HTTP recibidas retorna el contenido generado por la acción correcta del controlador invocado.


Identificador Core\AbstractFrontControllerTestCase#testDispatchRequestURI_indexphp

Descripción Comprueba que el frontcontroller base redirige las solicitudes a la acción por defecto cuando la URI de la solicitud solo contiene el nombre del punto de entrada predeterminado de la aplicación (index.php)

R. Esperado La función encargada de despachar las solicitudes HTTP recibidas retorna el contenido generado por la acción por defecto del controlador invocado.


ArrayCacheTestCase

Identificador Core\ArrayCacheTestCase#testInheritance

Descripción Comprueba que la implementación del caché de datos utilizado para las consultas a través del Doctrine es compatible con éste y hereda del caché de datos de doctrine basado en arrays PHP.

R. Esperado La creación de instancias de \CMMSE\Core\ArrayCache no produce errores y son consideradas instancias de \Doctrine\Common\Cache\ArrayCache, pudiendo ser utilizadas en lugar de éstas.


Identificador Core\ArrayCacheTestCase#testFetchNotEmpty

Descripción Comprueba que la lectura de datos para claves almacenadas previamente en caché no produce errores y que la llamada al método que comprueba si dichas claves están almacenadas en caché informa correctamente de su existencia.

R. Esperado La lectura de claves definidas retorna los datos asociados previamente a éstas, y la comprobación de existencia de las mismas retorna cierto.




Identificador Core\ArrayCacheTestCase#testFetchEmpty

Descripción Comprueba que la lectura de datos para claves no almacenadas previamente en caché falla (sin producir excepciones) y que la llamada al método que comprueba si dichas claves están almacenadas en caché informa de su no existencia después de realizar un intento de lectura de éstas. En particular, estas comprobaciones se realizan sobre una instancia de caché vacía.

R. Esperado Tanto el intento de lectura de claves no definidas como la comprobación de existencia de éstas retornan falso.


Identificador Core\ArrayCacheTestCase#testDelete

Descripción Comprueba que el borrado de datos asociados a claves definidas previamente funciona correctamente, provocando que la lectura y la comprobación de existencia de éstas posterior a su borrado retornan los resultados esperados según la especificación de la API de Doctrine.

R. Esperado Tanto la lectura como la comprobación de existencia de claves borradas retorna falso sin afectar a la lectura y comprobación de existencia de otras claves definidas antes del borrado.


Identificador Core\ArrayCacheTestCase#testStats

Descripción Comprueba que la lectura y la comprobación de existencia tanto de claves definidas como no definidas previamente actualiza correctamente los contadores internos de número de aciertos y fallos de la caché, y que la llamada al método de lectura de dichos contadores los retorna en el formato esperado.

R. Esperado La lectura de claves borradas y no borradas retorna los valores esperados. Además, las estadísticas de número de aciertos y fallos retornadas posteriormente son consistentes con las operaciones realizadas.


ConfigurationTestCase

Identificador Core\ConfigurationTestCase#testGetInstance

Descripción Comprueba que el método de instanciación de la configuración retorna una instancia de la clase que representa la configuración estática del sitio.

R. Esperado Se obtiene una instancia de \CMMSE\Core\Configuration.


Identificador Core\ConfigurationTestCase#testIsSingleton

Descripción Comprueba que las llamadas sucesivas al método de instanciación de la configuración del sitio retornan siempre referencias al mismo objeto en lugar de crear nuevas instancias.

R. Esperado Dos solicitudes de instanciación de la configuración del sitio retornan referencias al mismo objeto, y sus hashes internos (identificadores únicos de instancia) coinciden.




Identificador Core\ConfigurationTestCase#testGetRootPath

Descripción Comprueba que la obtención de la ruta del directorio raíz de la aplicación retorna la ruta correcta, calculada en función de la ruta (conocida) del archivo que contiene el código de esta prueba unitaria.

R. Esperado La ruta del directorio obtenido por Configuration::getRootPath() y la calculada en función del archivo del test coinciden.


Identificador Core\ConfigurationTestCase#testHasKeys

Descripción Comprueba que la prueba de existencia de las claves definidas en el archivo de configuración a través de la clase Configuration coincide con las claves obtenidas mediante una una lectura de bajo nivel del mismo archivo.

R. Esperado Las claves obtenidas mediante la lectura directa del archivo de configuración producen cierto al realizarse una prueba de existencia de éstas sobre una instancia de la clase Configuration.


Identificador Core\ConfigurationTestCase#testGetKeys

Descripción Comprueba que la lectura del valor asociado a las claves definidas en el archivo de configuración a través de la clase Configuration coincide con el valor leído mediante una lectura de bajo nivel del mismo archivo.

R. Esperado Las claves y valores obtenidos mediante la lectura directa del archivo de configuración coinciden con los valores leídos a través de la clase Configuration.


MailValidatorTestCase

Identificador Core\MailValidatorTestCase#testGetInstance

Descripción Comprueba que la creación de nuevas instancias del validador de direcciones de correo electrónico se realiza sin errores.

R. Esperado La creación de una nueva instancia de la clase \CMMSE\Core\MailValidator sin errores.


Identificador Core\MailValidatorTestCase#testInvalidEMailsExpectedFail

Descripción Este test unitario contiene direcciones de correo electrónico no válidas [MAIL01] que se sabe que son marcadas incorrectamente como válidas por el validador: - [email protected] (Joe Smith) - [email protected] Hay que mencionar que, aunque las direcciones de este tipo sean consideradas como válidas, la aplicación no permite el registro de usuarios con ellas al retornarse un error al enviar el correo electrónico de confirmación a las mismas desde el servidor SMTP.

R. Esperado El método de validación retorna falso para todas las direcciones de la lista.

Resultado No satisfactorio



Identificador Core\MailValidatorTestCase#testValidIPv6EMails

Descripción Comprueba que el validador de direcciones de correo electrónico define como válidas las direcciones del siguiente conjunto de direcciones válidas que utilizan una dirección IPv6 en la parte de dominio: - first.last@[IPv6:::12.34.56.78] - first.last@[IPv6:1111:2222:3333::4444:12.34.56.78] - first.last@[IPv6:1111:2222:3333:4444:5555:6666:12.34.56.78] - first.last@[IPv6:::1111:2222:3333:4444:5555:6666] - first.last@[IPv6:1111:2222:3333::4444:5555:6666] - first.last@[IPv6:1111:2222:3333:4444:5555:6666::] - test@[IPv6:1111:2222:3333:4444:5555:6666:7777:8888] - first.last@[IPv6:1111:2222:3333:4444:5555:6666:7777:8888] - test@[IPv6:1111:2222:3333:4444:5555::8888] - test@[IPv6:::3333:4444:5555:6666:7777:8888] Hay que mencionar que, aunque sean consideradas como válidas direcciones de correo que utilizan una IPv6 en la parte de dominio, la aplicación no permitirá utilizarlas durante el registro mientras el servidor SMTP utilizado no se encuentre en una red IPv6.

R. Esperado El método de validación retorna cierto para todas las direcciones de la lista.


Identificador Core\MailValidatorTestCase#testValidEMailsExpectedFail

Descripción Este test unitario contiene direcciones de correo electrónico válidas que contienen acentos, caracteres cirílicos, kanji, griegos o signos de puntuación, o utilizan direcciones IP en la parte de dominio sin delimitar; que se sabe que son marcadas incorrectamente como no válidas por el validador: - [email protected] - \[email protected] - very."(),:;<>[]".VERY."very@\\ very"[email protected] - Pelé@example.com - δοκιμή@παράδειγμα.δοκιμή

- 甲斐@黒川.日本 - чебурашка@ящик-с-апельсинами.рф





Identificador Core\MailValidatorTestCase#testValidEmails

Descripción Comprueba que el validador de direcciones de correo electrónico define como válidas las direcciones del siguiente conjunto de direcciones válidas [MAIL01] [MAIL02]: - [email protected] - [email protected] - [email protected] - [email protected] - email@[123.123.123.123] - "email"@example.com - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghiklm@iana.

org - much."more\ unusual"@example.com - very.unusual."@"[email protected] - "Abc\@def"@example.com - "Fred Bloggs"@example.com - "Joe\\Blow"@example.com - "Abc@def"@example.com - customer/[email protected] - !def!xyz%[email protected] - [email protected] - [email protected]



Identificador Core\MailValidatorTestCase#testInvalidIPv6ExpectedFail

Descripción Este test unitario contiene direcciones de correo electrónico no válidas [MAIL02] que se sabe que son marcadas incorrectamente como válidas por el validador: - test@[IPv6:1111:2222:3333:4444:5555:6666::7777:8888] - test@[IPv6:1111:2222:3333:4444:5555:6666:255.255.255.255] - test@[IPv6:1111:2222:3333:4444:::255.255.255.255] - test@[IPv6:1111:2222:3333:4444::255.255.255.255] - test@[IPv6:::] - test@[IPv6:1111:2222:3333:4444:5555:6666:7777:255.255.255.255] Hay que mencionar que, aunque las direcciones de este tipo sean consideradas como válidas, la aplicación no permite el registro de usuarios con ellas al retornarse un error al enviar el correo electrónico de confirmación a las mismas desde el servidor SMTP.





Identificador Core\MailValidatorTestCase#testInvalidEmails

Descripción Comprueba que el validador de direcciones de correo electrónico define como no válidas las direcciones del siguiente conjunto de direcciones de correo electrónico no válidas [MAIL01] [MAIL02]: - plainaddress - #@%^%#$@#$@#.com - @example.com - Joe Smith <[email protected]> - email.example.com - email@[email protected] - [email protected] - [email protected] - [email protected]

- あいうえお@example.com - email@example - [email protected] - [email protected] - [email protected] - [email protected] - email@[323.123.123.123] - email@[123.323.123.123] - email@[123.123.323.123] - email@[123.123.123.323] - abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghiklmn@ian

a.org - abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghiklm@abcd

efghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghikl.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghikl.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijkl

- [email protected] - A@b@[email protected] - "(),:;<>[\]@example.com - just"not"[email protected] - this\ is"really"not\[email protected]



OverviewDataTestCase

Identificador Core\OverviewDataTestCase#testNullRatios

Descripción Comprueba que el cálculo de las razones matemáticas (ratios) produce valores nulos (cero) al calcularlos sobre un conjunto de datos sin inicializar.

R. Esperado Las razones matemáticas (papers aceptados por autor, papers aceptados por número de autores que han pagado, papers por autor y papers por autores que han pagado) son iguales a cero.




Identificador Core\OverviewDataTestCase#testNotNullRatios

Descripción Comprueba que el cálculo de las razones matemáticas (ratios) sobre un conjunto de valores conocido produce los resultados correctos.

R. Esperado Las razones matemáticas (papers aceptados por autor, papers aceptados por número de autores que han pagado, papers por autor y papers por autores que han pagado) son iguales a los valores esperados para un conjunto de datos conocido.


ScriptStatsTestCase

Identificador Core\ScriptStatsTestCase#testPeakMemUsage

Descripción Comprueba que el valor de cantidad de memoria máxima utilizada obtenida por \CMMSE\Core\ScriptStats coincide con el valor de memoria máxima utilizada esperado obtenido previamente de manera directa.

R. Esperado El valor retornado por ScriptStats coincide con el valor obtenido previamente de manera directa.


Identificador Core\ ScriptStatsTestCase#testQueryCount

Descripción Comprueba que el número de consultas SQL ejecutadas reportado por ScriptStats es factible.

R. Esperado Un entero estrictamente mayor que cero.


Identificador Core\ ScriptStatsTestCase#testGuessElapsedTime

Descripción Comprueba que el valor de tiempo estimado de ejecución del script actual es correcto partiendo de un instante de inicio de ejecución del script actual conocido, y que su lectura como texto (string) coincide con el valor numérico.

R. Esperado El valor de tiempo estimado de ejecución es el esperado, y coincide con el valor leído como texto.


TemplateTestCase

Identificador Core\TemplateTestCase#testNewInstanceHTML

Descripción Comprueba que la creación de nuevas instancias de plantillas a partir de un archivo conocido del namespace @html no produce errores.

R. Esperado Se obtiene una instancia nueva de la plantilla sin generarse excepciones.


Identificador Core\TemplateTestCase#testNewInstanceEMail

Descripción Comprueba que la creación de nuevas instancias de plantillas a partir de un archivo de texto conocido que define el asunto y texto de un correo electrónico no produce errores y genera un mensaje con el asunto esperado.

R. Esperado El asunto del mensaje generado coincide con el asunto definido en la plantilla, y utiliza correctamente los parámetros proporcionados a ésta.




Identificador Core\TemplateTestCase#testNewInstanceCSS

Descripción Comprueba que la creación de nuevas instancias de plantillas a partir de un archivo conocido del namespace @css no produce errores.

R. Esperado Se obtiene una instancia nueva de la plantilla sin generarse excepciones.


Identificador Core\TemplateTestCase#testSetValues

Descripción Comprueba que la comprobación de existencia de valores para etiquetas de plantilla definidos y no definidos y la asignación de valores a éstas funciona correctamente.

R. Esperado La comprobación de existencia de un valor no definido retorna falso y viceversa, y la lectura de valores retorna los datos asignados previamente.


Identificador Core\TemplateTestCase#testGetNullValue

Descripción Comprueba que la lectura de valores para etiquetas no definidas previamente retorna valores nulos.

R. Esperado El valor de una etiqueta no definida se retorna como null.


Identificador Core\TemplateTestCase#testUnsetValues

Descripción Comprueba que la eliminación de valores de etiquetas funciona correctamente y solo afecta a la etiqueta correspondiente.

R. Esperado La comprobación de existencia de valor para una etiqueta cuyo valor ha sido definido y eliminado previamente retorna falso, sin afectar a los valores esperados para otras etiquetas definidas.


Identificador Core\TemplateTestCase#testRender

Descripción Comprueba que la solicitud de renderizado de una plantilla conocida funciona correctamente.

R. Esperado El renderizado de la plantilla retorna una cadena de texto de longitud no nula.


Identificador Core\TemplateTestCase#testFilterFunction

Descripción Comprueba que el renderizado de plantillas que hacen uso de funciones de filtrado en sus etiquetas funciona correctamente.

R. Esperado El renderizado de la plantilla retorna una cadena de texto con el resultado de aplicar la función de filtrado, y dicho resultado coincide con el resultado esperado calculado previamente de forma independiente.


Identificador Core\TemplateTestCase#testSyntaxError

Descripción Comprueba que el renderizado de plantillas que contienen errores sintácticos retorna un resultado vacío sin generar excepciones.

R. Esperado El renderizado retorna una cadena vacía.




7.2.2 Tests\Entities

PropertyScopeConferenceTestCase

Identificador Entities\PropertyScopeConferenceTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\Conference es accesible.

R. Esperado La función interna que comprueba la existencia de clases retorna cierto.


Identificador Entities\PropertyScopeConferenceTestCase#testPropertyScope

Descripción Comprueba que la clase \CMMSE\Doctrine\Conference no contiene propiedades públicas definidas, realizándose todo el acceso a sus datos a través de sus métodos de lectura y modificación.

R. Esperado La enumeración de propiedades públicas de la clase retorna un conjunto vacío.


PropoertyScopeInstrumentationSampleTestCase

Identificador Entities\PropertyScopeInstrumentationTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\InstrumentationSample es accesible.



Identificador Entities\PropertyScopeInstrumentationTestCase#testPropertyScope

Descripción Comprueba que la clase \CMMSE\Doctrine\InstrumentationSample no contiene propiedades públicas definidas, realizándose todo el acceso a sus datos a través de sus métodos de lectura y modificación.



PropertyScopeMailerSettingsTestCase

Identificador Entities\PropertyScopeMailerSettingsTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\MailerSettings es accesible.



Identificador Entities\PropertyScopeMailerSettingsTestCase#testPropertyScope

Descripción Comprueba que la clase \CMMSE\Doctrine\MailerSettings no contiene propiedades públicas definidas, realizándose todo el acceso a sus datos a través de sus métodos de lectura y modificación.





PropertyScopePaperTestCase

Identificador Entities\PropertyScopePaperTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\Paper es accesible.



Identificador Entities\PropertyScopePaperTestCase#testPropertyScope

Descripción Comprueba que la clase \CMMSE\Doctrine\Paper no contiene propiedades públicas definidas, realizándose todo el acceso a sus datos a través de sus métodos de lectura y modificación.



PropertyScopePaymentSettingsTestCase

Identificador Entities\PropertyScopePaymentSettingsTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\PaymentSettings es accesible.



Identificador Entities\PropertyScopePaymentSettingsTestCase#testtPropertyScope

Descripción Comprueba que la clase \CMMSE\Doctrine\PaymentSettings no contiene propiedades públicas definidas, realizándose todo el acceso a sus datos a través de sus métodos de lectura y modificación.



PropertyScopePersonTitleTestCase

Identificador Entities\PropertyScopePersonTitleTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\PersonTitle es accesible.



Identificador Entities\PropertyScopePersonTitleTestCase#testPropertyScope

Descripción Comprueba que la clase \CMMSE\Doctrine\PersonTitle no contiene propiedades públicas definidas, realizándose todo el acceso a sus datos a través de sus métodos de lectura y modificación.





PropertyScopePosterTestCase

Identificador Entities\PropertyScopePosterTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\Poster es accesible.



Identificador Entities\PropertyScopePosterTestCase#testPropertyScope

Descripción Comprueba que la clase \CMMSE\Doctrine\Poster no contiene propiedades públicas definidas, realizándose todo el acceso a sus datos a través de sus métodos de lectura y modificación.



PropertyScopeRoomTestCase

Identificador Entities\PropertyScopeRoomTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\Room es accesible.



Identificador Entities\PropertyScopeRoomTestCase#testPropertyScope

Descripción Comprueba que la clase \CMMSE\Doctrine\Room no contiene propiedades públicas definidas, realizándose todo el acceso a sus datos a través de sus métodos de lectura y modificación.



PropertyScopeSessionTestCase

Identificador Entities\PropertyScopeSessionTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\Session es accesible.



Identificador Entities\PropertyScopeSessionTestCase#testPropertyScope

Descripción Comprueba que la clase \CMMSE\Doctrine\Session no contiene propiedades públicas definidas, realizándose todo el acceso a sus datos a través de sus métodos de lectura y modificación.





PropertyScopeSettingsTestCase

Identificador Entities\PropertyScopeSettingsTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\Settings es accesible.



Identificador Entities\PropertyScopeSettingsTestCase#testPropertyScope

Descripción Comprueba que la clase \CMMSE\Doctrine\Settings no contiene propiedades públicas definidas, realizándose todo el acceso a sus datos a través de sus métodos de lectura y modificación.



PropertyScopeUserTestCase

Identificador Entities\PropertyScopeUserTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\User es accesible.



Identificador Entities\PropertyScopeUserTestCase#testPropertyScope

Descripción Comprueba que la clase \CMMSE\Doctrine\User no contiene propiedades públicas definidas, realizándose todo el acceso a sus datos a través de sus métodos de lectura y modificación.



PropertyScopeUserBillingInfoTestCase

Identificador Entities\PropertyScopeUserBillingInfoTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\UserBillingInfo es accesible.



Identificador Entities\PropertyScopeUserBillingInfoTestCase#testPropertyScope

Descripción Comprueba que la clase \CMMSE\Doctrine\UserBillingInfo no contiene propiedades públicas definidas, realizándose todo el acceso a sus datos a través de sus métodos de lectura y modificación.





7.2.3 Tests\Entities\Doctrine

ConferenceTestCase

Identificador Entities\Doctrine\ConferenceTestCase#testExists




Identificador Entities\Doctrine\ConferenceTestCase#testFetchByID

Descripción Comprueba que la obtención de una instancia conocida de \CMMSE\Doctrine\Conference a través del EntityManager de Doctrine no produce errores.

R. Esperado Se obtiene una referencia no nula a una instancia de la clase con el identificador esperado.


Identificador Entities\Doctrine\ConferenceTestCase#testGetters

Descripción Comprueba que los valores devueltos por los distintos métodos de lectura de datos son consistentes entre sí.

R. Esperado Todos los métodos de lectura de datos referidos al mismo atributo retornan el mismo valor.


Identificador Entities\Doctrine\ConferenceTestCase#testSetters

Descripción Comprueba que los métodos de modificación de datos funcionan correctamente y cambian el estado interno de la clase de la forma esperada.

R. Esperado El estado interno del objeto se modifica, y la posterior lectura de los datos modificados retorna los valores esperados.


Identificador Entities\Doctrine\ConferenceTestCase#testAccessors

Descripción Comprueba que la escritura de datos utilizando la sintaxis de array y los métodos mágicos de PHP funcionan correctamente.



InstrumentationTestCase

Identificador Entities\Doctrine\InstrumentationTestCase#testExists






Identificador Entities\Doctrine\InstrumentationTestCase#testFetchByID

Descripción Comprueba que la obtención de una instancia conocida de \CMMSE\Doctrine\Instrumentation a través del EntityManager de Doctrine no produce errores.



Identificador Entities\Doctrine\InstrumentationTestCase#testGetters




Identificador Entities\Doctrine\InstrumentationTestCase#testSetters




MailerSettingsTestCase

Identificador Entities\Doctrine\MailerSettingsTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\MailerSettings es accesible.



Identificador Entities\Doctrine\MailerSettingsTestCase#testFetchByID

Descripción Comprueba que la obtención de una instancia conocida de \CMMSE\Doctrine\MailerSettings a través del EntityManager de Doctrine no produce errores.



Identificador Entities\Doctrine\MailerSettingsTestCase#testGetters




Identificador Entities\Doctrine\MailerSettingsTestCase#testSetters






Identificador Entities\Doctrine\MailerSettingsTestCase#testAccessors




PaperTestCase

Identificador Entities\Doctrine\PaperTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\Paper es accesible.



Identificador Entities\Doctrine\PaperTestCase#testFetchRandom

Descripción Comprueba que la obtención de una instancia aleatoria de \CMMSE\Doctrine\Paper a través del EntityManager de Doctrine no produce errores.

R. Esperado Se obtiene una referencia no nula a una instancia de la clase.


Identificador Entities\Doctrine\PaperTestCase#testGetters




Identificador Entities\Doctrine\PaperTestCase#testSetters




PaymentSettingsTestCase

Identificador Entities\Doctrine\PaymentSettingsTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\PaymentSettings es accesible.



Identificador Entities\Doctrine\PaymentSettingsTestCase#testFetch

Descripción Comprueba que la obtención de una instancia conocida de \CMMSE\Doctrine\PaymentSettings a través del EntityManager de Doctrine no produce errores.





Identificador Entities\Doctrine\PaymentSettingsTestCase#testGetters




Identificador Entities\Doctrine\PaymentSettingsTestCase#testSetters




PersonTitleTestCase

Identificador Entities\Doctrine\PersonTitleTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\PersonTitle es accesible.



Identificador Entities\Doctrine\PersonTitleTestCase#testFetchByID

Descripción Comprueba que la obtención de una instancia conocida de \CMMSE\Doctrine\PersonTitle a través del EntityManager de Doctrine no produce errores.



Identificador Entities\Doctrine\PersonTitleTestCase#testGetters




Identificador Entities\Doctrine\PersonTitleTestCase#testSetters




Identificador Entities\Doctrine\PersonTitleTestCase#testAccessors






PosterTestCase

Identificador Entities\Doctrine\Poster#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\Poster es accesible.



Identificador Entities\Doctrine\PosterTestCase#testFetchOne

Descripción Comprueba que la obtención de una instancia aleatoria de \CMMSE\Doctrine\Poster a través del EntityManager de Doctrine no produce errores.



Identificador Entities\Doctrine\PosterTestCase#testGetters

Descripción Comprueba que los valores devueltos por los distintos métodos de lectura de datos son consistentes entre sí, incluyendo la sala y el paper referenciados por el poster.



Identificador Entities\Doctrine\PosterTestCase#testSetters




Identificador Entities\Doctrine\PosterTestCase#testAccessors




RoomTestCase

Identificador Entities\Doctrine\RoomTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\Room es accesible.



Identificador Entities\Doctrine\RoomTestCase#testFetchByID

Descripción Comprueba que la obtención de una instancia conocida de \CMMSE\Doctrine\Room a través del EntityManager de Doctrine no produce errores.





Identificador Entities\Doctrine\RoomTestCase#testGetters




Identificador Entities\Doctrine\RoomTestCase#testSetters




Identificador Entities\Doctrine\RoomTestCase#testAccessors




SessionTestCase

Identificador Entities\Doctrine\SessionTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\Session es accesible.



Identificador Entities\Doctrine\SessionTestCase#testCreateSession

Descripción Comprueba que no se producen errores en la creación y posterior lectura de los objetos que representan las sesiones de usuario, ni en la lectura de los datos asociados a éstas.

R. Esperado La creación, instanciación y lectura de los objetos de sesión no producen errores, y la lectura de los datos de éstas coincide con los datos asignados previamente.


Identificador Entities\Doctrine\SessionTestCase#testGetters

Descripción Comprueba que los valores devueltos por los distintos métodos de lectura de datos identificativos y de gestión de sesión son consistentes entre sí.



Identificador Entities\Doctrine\SessionTestCase#testSetters

Descripción Comprueba que los métodos de modificación de datos identificativos de sesión funcionan correctamente y cambian el estado interno de la clase de la forma esperada.





Identificador Entities\Doctrine\SessionTestCase#testSetters2

Descripción Comprueba que la modificación de datos identificativos de sesión a través de los métodos de modificación de atributos mágicos de PHP funcionan correctamente y cambian el estado interno de la clase de la forma esperada.



SettingsTestCase

Identificador Entities\Doctrine\SettingsTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\Settings es accesible.



Identificador Entities\Doctrine\SettingsTestCase#testFetchEmpty

Descripción Comprueba que la lectura de un objeto vacío de configuración a través del método getEmptySettings() del modelo de sesiones retorna un objeto en el estado esperado.

R. Esperado Una referencia no nula a un objeto de configuración con un ID nulo y el flag que indica que no ha sido inicializado desde la base de datos a cierto.


Identificador Entities\Doctrine\SettingsTestCase#testFetchSettings

Descripción Comprueba que la lectura de un objeto de configuración con los valores actuales almacenados en la base de datos retorna un objeto en el estado esperado.

R. Esperado Una referencia no nula a un objeto de configuración con un ID no nulo e igual a 1 y el flag que indica que no ha sido inicializado desde la base de datos a falso.


Identificador Entities\Doctrine\SettingsTestCase#testGetters

Descripción Comprueba que los valores devueltos por los distintos métodos de lectura de los datos de configuración son consistentes entre sí.



Identificador Entities\Doctrine\SettingsTestCase#testSetters

Descripción Comprueba que los métodos de modificación de datos de configuración funcionan correctamente y cambian el estado interno de la clase de la forma esperada





TripTestCase

Identificador Entities\Doctrine\TripTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\Trip es accesible.



Identificador Entities\Doctrine\TripTestCase#testFetchByID

Descripción Comprueba que la obtención de una instancia conocida de \CMMSE\Doctrine\Trip a través del EntityManager de Doctrine no produce errores.



Identificador Entities\Doctrine\TripTestCase#testGetters

Descripción Comprueba que los valores devueltos por los distintos métodos de lectura de los datos del objeto son consistentes entre sí.



Identificador Entities\Doctrine\TripTestCase#testSetters




Identificador Entities\Doctrine\TripTestCase#testAccessors




UserTestCase

Identificador Entities\Doctrine\UserTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\User es accesible.



Identificador Entities\Doctrine\UserTestCase#testFetchByID

Descripción Comprueba que la obtención de una instancia conocida de \CMMSE\Doctrine\User a través del EntityManager de Doctrine no produce errores.





Identificador Entities\Doctrine\UserTestCase#testGetters




Identificador Entities\Doctrine\UserTestCase#testSetters




Identificador Entities\Doctrine\UserTestCase#testAccessors




UserBillingInfoTestCase

Identificador Entities\Doctrine\UserBillingInfoTestCase#testExists

Descripción Comprueba que la clase \CMMSE\Doctrine\UserBillingInfo es accesible.



Identificador Entities\Doctrine\UserBillingInfoTestCase#testFetchRandom

Descripción Comprueba que la obtención de una instancia aleatoria de \CMMSE\Doctrine\UserBillingInfo a través del EntityManager de Doctrine no produce errores.



Identificador Entities\Doctrine\UserBillingInfoTestCase#testGetters




Identificador Entities\Doctrine\UserBillingInfoTestCase#testSetters






7.2.4 Tests\Decorators

ConferenceTestCase

Identificador Decorators\ConferenceTestCase#testInheritance

Descripción Comprueba que la creación de una nueva instancia del decorador a partir de una entidad funciona correctamente.

R. Esperado La instancia del decorador es considerada una subclase de la entidad a partir de la cual ha sido instanciado, y los atributos compartidos con ésta tienen los mismos valores.


Identificador Decorators\ConferenceTestCase#testGetters

Descripción Comprueba que los métodos de lectura para valores adicionales definidos por el decorador retornan los valores esperados.

R. Esperado Los métodos de lectura de los atributos adicionales definidos en el decorador retornan los valores esperados en función de los parámetros utilizados durante su instanciación y de los atributos del objeto a partir del cual ha sido instanciado.


PagoUsuarioTestCase

Identificador Decorators\PagoUsuarioTestCase#testInheritance




Identificador Decorators\PagoUsuarioTestCase#testGetters


R. Esperado Los métodos de lectura de los atributos adicionales definidos en el decorador retornan los valores esperados en función de los parámetros utilizados durante su instanciación.


PaperTestCase

Identificador Decorators\PaperTestCase#testInheritance






Identificador Decorators\PaperTestCase#testGetters


R. Esperado Los métodos de lectura de los atributos adicionales definidos en el decorador retornan los valores esperados en función de los parámetros utilizados durante su instanciación.


Identificador Decorators\PaperTestCase#testPosterGetters

Descripción Comprueba que los métodos de lectura para valores adicionales definidos por el decorador retornan los valores esperados cuando se proporcionan los atributos adicionales definidos para los posters.

R. Esperado Los métodos de lectura de los atributos adicionales definidos en el decorador retornan los valores esperados en función de los parámetros utilizados durante su instanciación, y los atributos adicionales para los posters coinciden.


Identificador Decorators\PaperTestCase#testPaperDateGetters

Descripción Comprueba que los métodos de lectura para los valores adicionales de fecha definidos por el decorador retornan los valores esperados cuando se proporcionan los atributos adicionales definidos para los posters.

R. Esperado Los métodos de lectura de los atributos adicionales definidos en el decorador retornan los valores esperados en función de los parámetros utilizados durante su instanciación, y los atributos adicionales derivados de la fecha de exposición del poster coinciden.


PosterTestCase

Identificador Decorators\PosterTestCase#testInheritance




Identificador Decorators\PosterTestCase#testGetters

Descripción Comprueba que los métodos de lectura para los valores adicionales de fecha definidos por el decorador retornan los valores esperados.

R. Esperado Los métodos de lectura de los atributos adicionales definidos en el decorador retornan los valores esperados en función de los atributos del objeto a partir del cual ha sido instanciado, y los distintos métodos de representación de fechas coinciden entre sí.




Identificador Decorators\PosterTestCase#testDeletePoster

Descripción Comprueba que la creación de un nuevo paper de tipo poster y su posterior eliminación funciona correctamente.

R. Esperado La creación y eliminación se realiza sin producirse excepciones, y los métodos que retornan el número de posters enviados por un usuario para el ponente asignado al poster creado retornan los valores esperados.


RoomTestCase

Identificador Decorators\RoomTestCase#testInheritance




Identificador Decorators\RoomTestCase#testGetters

Descripción Comprueba que los métodos de lectura para los valores adicionales que gestionan la lista de posters asignados a la sala instanciada retornan los valores esperados.

R. Esperado La lista de posters retornada por el decorador coincide con la utilizada para su instanciación, y el método que retorna el número de posters asignados a la sala contiene el número esperado.


SettingsTestCase

Identificador Decorators\SettingsTestCase#testInheritance




Identificador Decorators\SettingsTestCase#testFetchEmpty

Descripción Comprueba que la creación de una nueva instancia del decorador a partir de una entidad considerada vacía funciona correctamente

R. Esperado Los métodos derivados de los originales que informan de que los datos de la instancia no han sido inicializados a partir de datos leídos de la base de datos retornan cierto, y el método que retorna el identificador asociado en la base de datos para los datos retorna null.




Identificador Decorators\SettingsTestCase#testGetters

Descripción Comprueba que los métodos para obtener los datos de configuración a través de nombres alternativos funcionan correctamente.

R. Esperado Los métodos originales y los alternativos retornan los mismos valores.


UserBillingTestCase

Identificador Decorators\UserBillingTestCase#testInheritance




Identificador Decorators\UserBillingTestCase#testGetters

Descripción Comprueba que los métodos de lectura para los valores adicionales definidos por el decorador retornan los valores esperados.

R. Esperado Los métodos de lectura de los atributos adicionales definidos en el decorador retornan los valores esperados en función de los atributos del objeto a partir del cual ha sido instanciado y de los valores proporcionados en su instanciación.


Identificador Decorators\UserBillingTestCase#testGettersDefaultFee

Descripción Comprueba que los métodos de lectura para los valores adicionales definidos por el decorador retornan los valores esperados cuando se proporciona un valor por defecto para la cuota y los datos de un usuario sin una cuota específica asignada.

R. Esperado Los métodos de lectura de los atributos adicionales definidos en el decorador retornan los valores esperados en función de los atributos del objeto a partir del cual ha sido instanciado y de los valores proporcionados en su instanciación. Como cuota del usuario se retorna la cuota por defecto definida.


Identificador Decorators\UserBillingTestCase#testNoDefaultFee

Descripción Comprueba que los métodos de lectura para los valores adicionales definidos por el decorador retornan los valores esperados cuando se proporciona un valor por defecto para la cuota y los datos de un usuario con una cuota específica asignada.

R. Esperado Los métodos de lectura de los atributos adicionales definidos en el decorador retornan los valores esperados en función de los atributos del objeto a partir del cual ha sido instanciado y de los valores proporcionados en su instanciación. Como cuota del usuario no se retorna la cuota por defecto definida.




Identificador Decorators\UserBillingTestCase#testGettersPaid

Descripción Comprueba que los métodos de lectura para los valores adicionales definidos por el decorador retornan los valores esperados cuando se proporcionan los datos de un usuario cuyo pago ha sido confirmado.

R. Esperado Los métodos de lectura de los atributos adicionales definidos en el decorador retornan los valores esperados en función de los atributos del objeto a partir del cual ha sido instanciado y de los valores proporcionados en su instanciación. El flag que indica si el usuario ha pagado y sus alias retornan cierto.


Identificador Decorators\UserBillingTestCase#testGettersNotPaid

Descripción Comprueba que los métodos de lectura para los valores adicionales definidos por el decorador retornan los valores esperados cuando se proporcionan los datos de un usuario cuyo pago no ha sido confirmado.

R. Esperado Los métodos de lectura de los atributos adicionales definidos en el decorador retornan los valores esperados en función de los atributos del objeto a partir del cual ha sido instanciado y de los valores proporcionados en su instanciación. El flag que indica si el usuario ha pagado y sus alias retornan falso.


7.2.5 Tests\Models

AutoresTestCase

Identificador Models\AutoresTestCase#testGetList

Descripción Comprueba que la obtención del listado de autores funciona correctamente.

R. Esperado Una lista no vacía que contiene únicamente instancias de \CMMSE\Decorators\Autor en la que todos ellos tienen su tipo establecido a Ponente y sus números de papers y posters son enteros mayores o iguales que cero.


ConferenciasTestCase

Identificador Models\ConferenciasTestCase#test

Descripción Comprueba que la creación de nuevas conferencias (simposios) a través del modelo de conferencias funciona correctamente.

R. Esperado Un nuevo objeto \CMMSE\Doctrine\Conference no nulo cuya fecha de creación está establecida entre los instantes de llamada y retorno del método addConference() y cuyo título coincide con el esperado.


Identificador Models\ConferenciasTestCase#testEditTitle

Descripción Comprueba que la modificación del título de una conferencia existente a través del modelo de conferencias funciona correctamente.

R. Esperado La lectura posterior de la misma conferencia tras su modificación retorna una conferencia con el nuevo título.




Identificador Models\ConferenciasTestCase#testDeleteConference

Descripción Comprueba que la eliminación, a través del modelo de conferencias, de una conferencia creada previamente funciona correctamente.

R. Esperado El borrado de la conferencia se completa sin producirse errores, y un intento posterior de lectura de la misma retorna una referencia nula.


Identificador Models\ConferenciasTestCase#testGetDecorator

Descripción Comprueba que la solicitud al modelo de un decorador a partir de una conferencia creada previamente funciona correctamente

R. Esperado Se obtiene una referencia al decorador solicitado, y sus atributos coinciden con los de la conferencia a partir de la cual ha sido creado.


Identificador Models\ConferenciasTestCase#testGetDecoratorNullConf

Descripción Comprueba que la solicitud al modelo de un decorador a partir del identificador de una conferencia inexistente retorna el resultado esperado.

R. Esperado El método retorna null y no se generan excepciones.


Identificador Models\ConferenciasTestCase#testEditBeginDate

Descripción Comprueba que la modificación de la fecha de inicio de una conferencia creada previamente a través del modelo de conferencias funciona correctamente.

R. Esperado La lectura posterior de la misma conferencia tras su modificación retorna una conferencia con la nueva fecha de inicio.


Identificador Models\ConferenciasTestCase#testgetList

Descripción Comprueba que el listado de conferencias a través del modelo de conferencias funciona correctamente. Para ello se crea una nueva conferencia que debe ser retornada en el listado.

R. Esperado Una lista que contiene una conferencia conocida creada previamente.


FacturacionTestCase

Identificador Models\FacturacionTestCase#testGetUserBillingInfo

Descripción Comprueba que la obtención de la información de facturación para un ponente aleatorio funciona correctamente.

R. Esperado La información de facturación del ponente utilizado en la llamada al modelo.


Identificador Models\FacturacionTestCase#testGetUserBillingInfoWrongUser

Descripción Comprueba que la solicitud de la información de facturación para un ponente inexistente funciona correctamente.

R. Esperado La llamada al modelo produce una excepción.




Identificador Models\FacturacionTestCase#testGetUsersNoBillNoFromSpain

Descripción Comprueba que la obtención del listado de usuarios de España sin número de factura asignado funciona correctamente.

R. Esperado Una lista con el número de usuarios esperado (obtenido de forma independiente) en la que éstos tienen el tipo establecido a ponente, el país a España, su CIF y compañía son no nulos y su número de factura es nulo.


Identificador Models\FacturacionTestCase#testGetUsersNoBillRedNoFromSpain

Descripción Comprueba que la obtención del listado de usuarios de España sin número de factura asignado pertenecientes a la red funciona correctamente.

R. Esperado Una lista con el número de usuarios esperado (obtenido de forma independiente) en la que éstos tienen el tipo establecido a ponente, el país a España, su CIF y compañía son no nulos y su número de factura asociado a la red es nulo.


Identificador Models\FacturacionTestCase#testGetUsersWithUnassignedBillNumberNotFromSpain

Descripción Comprueba que la obtención del listado de usuarios de fuera de España sin número de factura asignado funciona correctamente.

R. Esperado Una lista con el número de usuarios esperado (obtenido de forma independiente) en la que éstos tienen el tipo establecido a ponente, su país no es España, su CIF y compañía son no nulos y su número de factura es nulo.


Identificador Models\FacturacionTestCase#testSetUserBillInfo

Descripción Comprueba que la modificación de los datos de facturación de un usuario a través del modelo de facturación funciona correctamente.

R. Esperado La llamada para modificar los datos retorna cierto, y la lectura posterior de los datos de facturación retorna los nuevos datos.


Identificador Models\FacturacionTestCase#testCreateUserBillingInfo

Descripción Comprueba que la creación de los datos de facturación para nuevos ponentes funciona correctamente.

R. Esperado La llamada para crear los nuevos datos de facturación retorna cierto, y la lectura posterior de éstos retorna los datos por defecto esperados.


Identificador Models\FacturacionTestCase#testDeleteUserBillingInfo

Descripción Comprueba que la eliminación de los datos de facturación asociados a un usuario funciona correctamente.

R. Esperado El borrado de los datos de facturación asociados a un usuario recién creado no produce excepciones, y el intento de lectura posterior de éstos retorna null.




Identificador Models\FacturacionTestCase#testSetPaidFlag

Descripción Comprueba que la modificación del flag que indica que un usuario ha pagado se realiza correctamente.

R. Esperado Las modificaciones del flag retornan cierto, y las lecturas posteriores de los datos de facturación del usuario coinciden con el estado esperado.


Identificador Models\FacturacionTestCase#testSetBillPrintFlago

Descripción Comprueba que la modificación del flag que indica que la factura de un usuario está lista para imprimirse se realiza correctamente.



Identificador Models\FacturacionTestCase#testGetPaidFlag

Descripción Comprueba que la lectura directa a través del modelo del flag que indica que un usuario ha pagado funciona correctamente.

R. Esperado La lectura del flag retorna el valor esperado tras cada modificación.


Identificador Models\FacturacionTestCase#testUpdateBillNumber

Descripción Comprueba que la modificación directa a través del modelo del número de factura asociado a un usuario funciona correctamente.

R. Esperado La modificación del número de factura de un usuario utilizando un entero aleatorio retorna cierto, y las lecturas posteriores de los datos de facturación del usuario coinciden con el estado esperado.


Identificador Models\FacturacionTestCase#testUpdateBillNumberRed

Descripción Comprueba que la modificación directa a través del modelo del número de factura de red asociado a un usuario funciona correctamente.

R. Esperado La modificación del número de factura de red de un usuario utilizando un entero aleatorio retorna cierto, y las lecturas posteriores de los datos de facturación del usuario coinciden con el estado esperado.


Identificador Models\FacturacionTestCase#testUpdateBillRedFlag

Descripción Comprueba que la modificación directa a través del modelo del flag que indica que un usuario pertenece a la red funciona correctamente.



Identificador Models\FacturacionTestCase#testDeleteBillNumber

Descripción Comprueba que el borrado directo a través del modelo del número de factura asociado a un usuario funciona correctamente.

R. Esperado El borrado del número de factura retorna cierto, y las lecturas posteriores de los datos de facturación de usuario coinciden con el estado esperado.




Identificador Models\FacturacionTestCase#testSetUserBillFile

Descripción Comprueba que la modificación directa a través del modelo del nombre de archivo del justificante de pago enviado por un usuario funciona correctamente.

R. Esperado La modificación del nombre de archivo del justificante de pago asociado al usuario retorna cierto, y las lecturas posteriores de sus datos de facturación coinciden con el estado esperado.


Identificador Models\FacturacionTestCase#testSetUserBillFileWrongUser

Descripción Comprueba que la modificación directa a través del modelo del nombre de archivo del justificante de pago asociado a un usuario inexistente funciona correctamente.

R. Esperado La llamada al modelo retorna falso sin lanzar excepciones.


Identificador Models\FacturacionTestCase#testSetUserFees

Descripción Comprueba que la modificación directa a través del modelo de la cuota a pagar por un usuario funciona correctamente.

R. Esperado La llamada al modelo retorna cierto, y las lecturas posteriores de los datos de facturación del usuario coinciden con el estado esperado.


Identificador Models\FacturacionTestCase#testSetUserFeesWrongUser

Descripción Comprueba que la modificación directa a través del modelo de la cuota a pagar por un usuario inexistente funciona correctamente.



Identificador Models\FacturacionTestCase#testSetUserFeesWrongFees

Descripción Comprueba que la modificación directa a través del modelo de la cuota a pagar por un usuario cuando se usa una cantidad no válida funciona correctamente.



Identificador Models\FacturacionTestCase#testGetUsersWithUnassignedBillNumberFromSpain

Descripción Comprueba que la obtención del listado de usuarios de España sin número de factura asignado funciona correctamente.

R. Esperado Una lista de usuarios en la que éstos tienen el tipo establecido a ponente, su país es España, su CIF y compañía son no nulos, su número de factura es nulo y su flag de pago tiene valor cierto.


FacturasTestCase

Identificador Models\FacturasTestCase#testGetAll

Descripción Comprueba que la obtención del listado de facturas y justificantes funciona correctamente.

R. Esperado Se retorna un listado con tantos elementos como ponentes, sin duplicados, y que solo contiene datos de facturación para usuarios de tipo ponente.




Identificador Decorators\FacturasTestCase#testGetAllDefaultFee

Descripción Comprueba que la obtención del listado de facturas y justificantes retorna correctamente a los usuarios sin cuota específica asignada.

R. Esperado Se retorna un listado con tantos elementos como ponentes, sin duplicados, que solo contiene datos de facturación para usuarios de tipo ponente, y que contiene a un usuario creado previamente sin cuota específica asignada. Para éste, la cuota retornada es igual a la cuota por defecto.


Identificador Models\FacturasTestCase#testNonDefaultFee

Descripción Comprueba que la obtención del listado de facturas y justificantes retorna correctamente a los usuarios con cuota específica asignada.

R. Esperado Se retorna un listado con tantos elementos como ponentes, sin duplicados, y que contiene a un usuario creado previamente con cuota específica asignada. Para éste, la cuota retornada es distinta de la cuota por defecto.


Identificador Models\FacturasTestCase#testGetProofs

Descripción Comprueba que la obtención del listado de justificantes de pago funciona correctamente.

R. Esperado Se retorna un listado sin duplicados, que solo contiene datos de facturación para usuarios de tipo ponente sin CIF y compañía asignados y con un número de elementos menor o igual al número de ponentes.


Identificador Models\FacturasTestCase#testGetProofsDefaultFee

Descripción Comprueba que la obtención del listado de justificantes de pago retorna correctamente a los usuarios sin cuota específica asignada.

R. Esperado Se retorna un listado sin duplicados, que solo contiene datos de facturación para usuarios de tipo ponente sin CIF y compañía asignados, con un número de elementos menor o igual al número de ponentes, y que contiene a un usuario creado previamente sin CIF ni compañía y sin cuota específica asignada.


Identificador Models\FacturasTestCase#testGetProofsNonDefaultFee

Descripción Comprueba que la obtención del listado de justificantes de pago retorna correctamente a los usuarios con cuota específica asignada.

R. Esperado Se retorna un listado sin duplicados, que solo contiene datos de facturación para usuarios de tipo ponente sin CIF y compañía asignados, con un número de elementos menor o igual al número de ponentes, y que contiene a un usuario creado previamente sin CIF ni compañía y con cuota específica asignada.


Identificador Models\FacturasTestCase#testGetInvoices

Descripción Comprueba que la obtención del listado de facturas funciona correctamente.

R. Esperado Se retorna un listado sin duplicados, que solo contiene datos de facturación para usuarios de tipo ponente con CIF y compañía asignados y con un número de elementos menor o igual al número de ponentes.




Identificador Models\FacturasTestCase#testProofsAndInvoicesDontIntersect

Descripción Comprueba que los conjuntos de facturas y justificantes no intersectan, es decir, los ponentes retornados en la lista de justificantes no aparecen en la lista de facturas y viceversa.

R. Esperado La intersección de los conjuntos de IDs de usuario retornados en la lista de facturas y en la lista de justificantes es vacía.


Identificador Models\FacturasTestCase#testGetUserInvoice

Descripción Comprueba que la obtención de los datos de facturación de un usuario sin CIF y compañía asignados funciona correctamente.

R. Esperado Para un usuario sin CIF y compañía asignados, los datos retornados por el modelo coinciden con los datos leídos en la prueba de forma independiente.


InstrumentationTestCase

Identificador Models\InstrumentationTestCase#testSaveStartTime

Descripción Comprueba que el modelo de instrumentación guarda correctamente el instante de inicio de ejecución de script.

R. Esperado El instante de inicio retornado por el modelo no es nulo y está comprendido entre los instantes inmediatamente anterior y posterior de la llamada al método que almacena el timestamp de inicio de ejecución del script.


Identificador Models\InstrumentationTestCase#testMySQLQueryCount

Descripción Comprueba que el modelo de instrumentación retorna un número de consultas SQL factible.

R. Esperado Un entero mayor o igual que cero.


Identificador Models\InstrumentationTestCase#testGetServerKey

Descripción Comprueba que el modelo de instrumentación obtiene correctamente valores aleatorios referidos al entorno de ejecución del servidor.

R. Esperado El valor retornado para una clave aleatoria de $_SERVER coincide con el valor leído directamente desde la superglobal.


Identificador Models\InstrumentationTestCase#testSaveData

Descripción Comprueba que al guardar los datos de instrumentación no se produce una excepción.

R. Esperado La llamada al método que guarda los datos de instrumentación retorna sin producir excepciones.




Identificador Models\InstrumentationTestCase#testLoadAvg

Descripción Comprueba que la llamada para obtener los valores medios de carga del sistema de los últimos 1, 5 y 15 minutos funciona correctamente.

R. Esperado Un array con 3 números en coma flotante que representan los valores medios de carga del sistema de los últimos 1, 5 y 15 minutos.


Identificador Models\InstrumentationTestCase#testUname

Descripción Comprueba que la llamada para obtener información de identificación del servidor que ejecuta la aplicación funciona correctamente.

R. Esperado Un array con 5 strings.


Identificador Models\InstrumentationTestCase#testGetInstrumentationData

Descripción Comprueba que el método interno del modelo que genera un objeto que representa los datos de instrumentación para la solicitud actual funciona correctamente y retorna valores factibles.

R. Esperado Un objeto InstrumentationSample cuya cantidad de memoria pico utilizada por el script es mayor o igual a la cantidad obtenida de forma independiente, y cuyos instantes (en coma flotante y redondeados) de inicio de ejecución son menores que los instantes de almacenamiento en la base de datos.


LoginTestCase

Identificador Models\LoginTestCase#testGetUserForCredentialsCorrectPassword

Descripción Comprueba que la obtención de una instancia de usuario a partir de unas credenciales de acceso válidos conocidos funciona correctamente.

R. Esperado Un objeto usuario asociado a las credenciales dados.


Identificador Models\LoginTestCase#testGetUserForCredentialsWrongPassword

Descripción Comprueba que la obtención de una instancia de usuario a partir de un usuario existente y una contraseña incorrecta funciona de la forma esperada.

R. Esperado La llamada al método produce una excepción.


Identificador Models\LoginTestCase#testGetUserForCredentialsWrongLogin

Descripción Comprueba que la obtención de una instancia de usuario a partir de un usuario inexistente funciona de la forma esperada.



Identificador Models\LoginTestCase#testEmptyCredentials

Descripción Comprueba que el método que valida los datos de inicio de sesión proporcionados por el usuario funciona correctamente cuando se le proporciona un array vacío como credenciales.





Identificador Models\LoginTestCase#testCredentialsNoArray

Descripción Comprueba que el método que valida los datos de inicio de sesión proporcionados por el usuario funciona correctamente cuando se le proporcionan un valor nulo como credenciales.



Identificador Models\LoginTestCase#testCredentialsOK

Descripción Comprueba que el método que valida los datos de inicio de sesión proporcionados por el usuario funciona correctamente cuando se le proporciona un array con credenciales válidos.

R. Esperado La llamada al método retorna cierto.


Identificador Models\LoginTestCase#testLogout

Descripción Comprueba que el método de finalización de sesión funciona correctamente cuando es llamado sobre los datos de una sesión de un usuario identificado.

R. Esperado Los datos de la sesión son modificados de forma que el identificador del usuario actual es borrado, el campo que indica el identificador de usuario anterior es actualizado, el campo que indica si la sesión corresponde a un administrador es puesto a falso y el campo que indica si la sesión correspondía previamente a un administrador toma el valor esperado.


Identificador Models\LoginTestCase#testSetSessionUser

Descripción Comprueba que el método que asocia una sesión a un usuario funciona correctamente al aplicarse sobre una sesión de invitado.

R. Esperado El usuario asociado a la sesión es actualizado y coincide con el utilizado en la llamada previa.


PapersTestCase

Identificador Models\PapersTestCase#testGetPaperList

Descripción Comprueba que el método que lista los papers enviados funciona correctamente.

R. Esperado La llamada al método retorna un array de instancias de \CMMSE\Doctrine\Paper.


Identificador Models\PapersTestCase#testGetDecoratorList

Descripción Comprueba que el método que retorna la lista de decoradores para todos los papers enviados funciona correctamente.

R. Esperado La llamada al método retorna un array de instancias de \CMMSE\Decorators\Paper con tantos elementos como papers hay en la base de datos. Además, para los papers de tipo poster los objetos devueltos contienen la información adicional asociada a éstos.




Identificador Models\PapersTestCase#testGetDecoratorListWrongUser

Descripción Comprueba que el método que retorna la lista de decoradores para todos los papers enviados tiene el funcionamiento esperado cuando existen papers asignados a usuarios inexistentes.



Identificador Models\PapersTestCase#testGetPaper

Descripción Comprueba que el método que obtiene la información asociada a un paper concreto funciona correctamente.

R. Esperado La llamada al método retorna una instancia que representa al paper esperado.


Identificador Models\PapersTestCase#testSetPaperFilename

Descripción Comprueba que el método que modifica el nombre de archivo asociado al primer envío de un paper funciona correctamente.

R. Esperado La llamada al método no produce excepciones, y la lectura posterior de los datos asociados al paper refleja el cambio realizado.


Identificador Models\PapersTestCase#testSetPaperNewFilename

Descripción Comprueba que el método que modifica el nombre de archivo asociado al último envío de un paper funciona correctamente.



Identificador Models\PapersTestCase#testResetPaperNewFilename

Descripción Comprueba que el borrado del nombre de archivo asociado al último envío de un paper funciona correctamente.



Identificador Models\PapersTestCase#testSetDecisionFlag

Descripción Comprueba que la modificación del flag de decisión asociado a un paper funciona correctamente.



Identificador Models\PapersTestCase#testSetAcceptedFlag

Descripción Comprueba que la modificación del flag que indica que un paper ha sido aceptado funciona correctamente.





Identificador Models\PapersTestCase#testSetPaperTitle

Descripción Comprueba que el cambio del título de un paper funciona correctamente.



Identificador Models\PapersTestCase#testGetPapersByTitle

Descripción Comprueba que el listado de papers cuyo título es igual a uno conocido funciona correctamente.

R. Esperado La llamada al método devuelve una lista con un único paper cuyo título coincide con el esperado.


Identificador Models\PapersTestCase#test

Descripción Comprueba que el listado de papers de un ponente cuyo título es igual a uno conocido funciona correctamente.

R. Esperado La llamada al método devuelve una lista que contiene un paper conocido cuyo título coincide con el esperado y cuyo usuario asociado es igual al esperado.


Identificador Models\PapersTestCase#testGetPosterInfoNoPoster

Descripción Comprueba que la solicitud de información asociada a un poster, al realizarse sobre un paper que no es de tipo poster, retorna el resultado esperado.

R. Esperado La llamada al método retorna falso sin producir excepciones.


Identificador Models\PapersTestCase#testDeletePaper

Descripción Comprueba que el borrado de un paper conocido funciona correctamente.

R. Esperado La llamada al método retorna cierto sin producir excepciones.


Identificador Models\PapersTestCase#testGetPapersLocalPath

Descripción Comprueba que el método que retorna el directorio local donde se almacenan los archivos de los papers funciona correctamente.

R. Esperado La llamada al método retorna un string que representa la ruta de un directorio sobre el cual el servidor posee permisos de escritura.


Identificador Models\PapersTestCase#testGetPostersListAll

Descripción Comprueba que el método que lista los papers de tipo poster funciona correctamente.

R. Esperado La llamada al método retorna un array de decoradores de tipo Poster, y el paper asociado a los mismos es de tipo poster.




Identificador Models\PapersTestCase#testGetPosterListAccepted

Descripción Comprueba que el método que lista los papers de tipo poster, cuando se solicita que solo se listen aquellos que han sido aceptados, funciona correctamente.

R. Esperado La llamada al método retorna un array de decoradores de tipo poster cuyo paper asociado es de tipo poster y está en estado aceptado, y contiene como máximo tantos elementos como papers han sido enviados.


Identificador Models\PapersTestCase#testGetPosterListNotAccepted

Descripción Comprueba que el método que lista los papers de tipo poster, cuando se solicita que solo se listen aquellos que no han sido aceptados, funciona correctamente.

R. Esperado La llamada al método retorna un array de decoradores de tipo poster cuyo paper asociado es de tipo poster y no está en estado aceptado, y contiene como máximo tantos elementos como papers han sido enviados.


Identificador Models\PapersTestCase#testGetPosterListTypesDontIntersect

Descripción Comprueba que los conjuntos de posters aceptados y no aceptados no intersectan, es decir, los posters retornados en la lista de aceptados no aparecen en la lista de no aceptados y viceversa.

R. Esperado La intersección de los conjuntos de IDs de posters retornados en ambas listas es vacía.


Identificador Models\PapersTestCase#testGetDecoratorListCount

Descripción Comprueba que el método que lista todos los papers incluyendo información adicional funciona correctamente.

R. Esperado La llamada al método retorna un array con tantos decoradores como papers han sido enviados, y el tipo de dato de sus elementos es el correcto.


Identificador Models\PapersTestCase#testGetUserPaper

Descripción Comprueba que el método para obtener información de un paper a partir de su identificador y del usuario que lo envió funciona correctamente.

R. Esperado La llamada al método retorna un paper cuyo identificador, título y usuario asociado coinciden con los esperados.


Identificador Models\PapersTestCase#testGetUserPaperVarAuthors

Descripción Comprueba que el método para obtener información de un paper a partir de su identificador y del usuario que lo envió retorna un paper cuya información de autores es correcta.

R. Esperado La llamada al método retorna un paper para el cual, siendo n el número de autores asignados, los primeros n autores son no nulos y los siguientes (9-n) autores son nulos.




Identificador Models\PapersTestCase#testGetPaperListForUser

Descripción Comprueba que el método que lista todos los papers para un usuario funciona correctamente.

R. Esperado La lista de papers retornada contiene un número de elementos igual al número de papers (obtenido de forma independiente) asignados al usuario indicado, y contiene un paper aleatorio asignado al usuario obtenido previamente.


Identificador Models\PapersTestCase#testGetPaperTitlesForUser

Descripción Comprueba que el listado de títulos de papers para un usuario funcoina correctamente.

R. Esperado La lista de títulos contiene tantos elementos como papers hay asignados al usuario, y no contiene títulos que no correspondan a papers del usuario.


PapersDeleteTestCase

Identificador Models\PapersDeleteTestCase#testDeleteUserPapers

Descripción Comprueba que la eliminación de todos los papers asociados a un usuario funciona correctamente.

R. Esperado El número de papers asociados a un usuario se es igual a cero tras el borrado de éstos, y el número total de papers en el sistema se decrementa en una cantidad igual al número de papers asociados al usuario.


PapersInsertTestCase

Identificador Models\PapersInsertTestCase#testInsertPaper

Descripción Comprueba que la creación de nuevos papers en la base de datos funciona correctamente.

R. Esperado La llamada al método de creación de nuevo paper retorna el identificador del paper creado, su lectura posterior retorna una instancia de Paper con los valores esperados, y el número de papers totales en el sistema y asociados al usuario se incrementan en una unidad.


PaymentsTestCase

Identificador Models\PaymentsTestCase#testLocks

Descripción Comprueba que la llamada a los métodos de obtención y liberación de bloqueos sobre la tabla de configuración de pagos funciona correctamente.

R. Esperado Las llamadas al modelo para obtener y liberar el bloqueo sobre la tabla de configuración de pagos no producen excepciones.




Identificador Models\PaymentsTestCase#testGetPaymentSettings

Descripción Comprueba que la lectura de la configuración de pagos funciona correctamente.

R. Esperado La llamada al modelo para obtener los datos de configuración de pagos retorna una instancia de la clase PaymentSettings.


Identificador Models\PaymentsTestCase#testSetPaymentSettings

Descripción Comprueba que la modificación de la configuración de pagos a través del método proporcionado por el modelo funciona correctamente.

R. Esperado La llamada al método no produce excepciones.


Identificador Models\PaymentsTestCase#testGetPaymentSettingsExceptions

Descripción Comprueba que el intento de lectura de la configuración de pagos, cuando ésta no está disponible, produce una excepción. Para ello se modifica el identificador de configuración esperado por el modelo en la base de datos.



PosterTestCase

Identificador Models\PosterTestCase#testInsertPoster

Descripción Comprueba que la creación de un nuevo paper de tipo poster a través del modelo funciona correctamente.

R. Esperado La llamada al método no produce excepciones y retorna una instancia de tipo Paper con los valores esperados. El número total de papers enviados y asociados al usuario se incrementan en una unidad.


Identificador Models\PosterTestCase#testSetDates

Descripción Comprueba que la modificación de las fechas asociadas a un poster a través del modelo funciona correctamente.

R. Esperado La llamada al método de modificación de fechas retorna cierto, y la lectura posterior de los datos adicionales de poster asociados al paper retorna un objeto con las fechas esperadas.


Identificador Models\PosterTestCase#testSetDatesWrongID

Descripción Comprueba que la modificación de fechas para papers inexistentes funciona correctamente.

R. Esperado La llamada al método de modificación de fechas retorna falso sin producir excepciones.


Identificador Models\PosterTestCase#testSetRoom

Descripción Comprueba que la modificación de la sala asociada a un paper a través del modelo funciona correctamente.

R. Esperado La llamada al método que obtiene la información adicional del poster retorna una instancia con la nueva sala asociada.




Identificador Models\PosterTestCase#testUnsetRoom

Descripción Comprueba que la eliminación de la asociación de una sala a un paper funciona correctamente.

R. Esperado La llamada al método que obtiene información adicional del poster tras la eliminación de su asociación con una sala retorna una instancia con la sala establecida a null.


Identificador Models\PosterTestCase#testSetRoomWrongID

Descripción Comprueba que la modificación de la sala asociada a un paper inexistente funciona de la manera esperada.

R. Esperado La llamada al método de modificación retorna falso sin producir excepciones.


Identificador Models\PosterTestCase#testDeletePoster

Descripción Comprueba que la eliminación de papers de tipo poster funciona correctamente.

R. Esperado La llamada al método de borrado sobre un poster creado previamente funciona correctamente, y el intento de lectura posterior retorna null.


RoomsTestCase

Identificador Models\RoomsTestCase#testCreateAndDeleteRoom

Descripción Comprueba que la creación y posterior eliminación de una sala a través del modelo funciona correctamente.

R. Esperado La llamada al método de creación de la nueva sala retorna el identificador de la sala creada y su borrado posterior no produce excepciones.


Identificador Models\RoomsTestCase#testGetRoom

Descripción Comprueba que la obtención de los datos de una sala a partir de su identificador a través del modelo funciona correctamente.

R. Esperado La llamada al método del modelo retorna una instancia de la sala solicitada.


Identificador Models\RoomsTestCase#testGetNonExistingRoom

Descripción Comprueba que la obtención de los datos de una sala a partir de un identificador de sala inexistente funciona de la manera esperada.

R. Esperado La llamada al método del modelo produce una excepción.


Identificador Models\RoomsTestCase#testSetRoomName

Descripción Comprueba que la modificación del nombre de una sala a través del modelo funciona correctamente.

R. Esperado La llamada al método del modelo para modificar el nombre de la sala no produce excepciones, y la lectura posterior de sus datos retorna un objeto con el nuevo nombre.




Identificador Models\RoomsTestCase#testGetExtendedRoomInfo

Descripción Comprueba que la solicitud de los datos adicionales de una sala existente funciona correctamente.

R. Esperado La llamada al modelo retorna una instancia de \CMMSE\Decorators\Room cuyo identificador coincide con el solicitado.


Identificador Models\RoomsTestCase#testGetRoomList

Descripción Comprueba que el listado de las salas funciona correctamente.

R. Esperado La llamada al método retorna una lista de salas con tantos elementos como salas existen en la base de datos ordenados alfabéticamente por el nombre de sala en sentido decreciente.


Identificador Models\RoomsTestCase#testDeleteNonExistingRoom

Descripción Comprueba que la solicitud de borrado de una sala a partir de un identificador de sala inexistente funciona de la manera esperada.



SessionTestCase

Identificador Models\SessionTestCase#testOpenCloseSession

Descripción Comprueba que la apertura y cierre de una sesión a través del modelo funciona correctamente.

R. Esperado La apertura y cierre de la sesión se realiza correctamente. Esta prueba no se ha realizado al ser imposible el envío de cookies de sesión desde PHPUnit.


Identificador Models\SessionTestCase#testReadWrite

Descripción Comprueba que la escritura de los datos de sesión y posterior lectura de los mismos funciona correctamente y los resultados obtenidos son coherentes entre sí.

R. Esperado La escritura de los datos de una nueva sesión retorna cierto, y la posterior lectura de los mismos retorna los datos proporcionados previamente.


Identificador Models\SessionTestCase#testReadNonExisting

Descripción Comprueba que la lectura de los datos de sesión para sesiones inexistentes retorna el resultado esperado por el gestor interno de sesiones de PHP.

R. Esperado La solicitud de lectura a partir de un identificador de sesión inexistente retorna una cadena vacía.


Identificador Models\SessionTestCase#testDestroy

Descripción Comprueba que el borrado de los datos de sesión para sesiones creadas previamente funciona de la forma esperada por el gestor interno de sesiones de PHP.

R. Esperado La llamada al método de destrucción de sesión retorna cierto, y una posterior solicitud de lectura de la sesión retorna una cadena vacía.




Identificador Models\SessionTestCase#testGC

Descripción Comprueba que la llamada al recolector de basura para sesiones inactivas funciona de la forma esperada por PHP.



Identificador Models\SessionTestCase#testOpen

Descripción Comprueba que la llamada al método de apertura de sesiones funciona de la forma esperada por PHP.



Identificador Models\SessionTestCase#testClose

Descripción Comprueba que la llamada al método de cierre de sesión funciona de la forma esperada por PHP.



SettingsTestCase

Identificador Models\SettingsTestCase#testGetSettings

Descripción Comprueba que la lectura de la configuración del sitio a través del modelo funciona correctamente.

R. Esperado La llamada al método retorna una instancia de \CMMSE\Doctrine\Settings.


Identificador Models\SettingsTestCase#testGetSettingsNotFound

Descripción Comprueba que la lectura de la configuración del sitio a través del modelo utilizando un identificador de fila de la base de datos incorrecto funciona correctamente.

R. Esperado La llamada al método cuando éste utiliza un identificador de fila incorrecto retorna una instancia de \CMMSE\Doctrine\Settings por defecto.


Identificador Models\SettingsTestCase#testSetSettings

Descripción Comprueba que la llamada al método de modificación de la configuración del sitio a través del modelo a partir de una instancia de configuración válida funciona correctamente.

R. Esperado La llamada al método de modificación no produce excepciones.


Identificador Models\SettingsTestCase#testGetMailSettings

Descripción Comprueba que la lectura de la configuración de envío de correos a través del modelo funciona correctamente.

R. Esperado La llamada al método retorna una instancia de \CMMSE\Doctrine\MailerSettings.




Identificador Models\SettingsTestCase#testGetMailSettingsNotFound

Descripción Comprueba que la lectura de la configuración de envío de correos a través del modelo utilizando un identificador de fila de la base de datos incorrecto funciona correctamente.

R. Esperado La llamada al método cuando éste utiliza un identificador de fila incorrecto retorna una instancia de \CMMSE\Doctrine\MailerSettings por defecto.


Identificador Models\SettingsTestCase#testSetMailerSettings

Descripción Comprueba que la llamada al método de modificación de la configuración de envío de correos a través del modelo a partir de una instancia de configuración de envío de correos válida funciona correctamente.

R. Esperado La llamada al método de modificación no produce excepciones.


Identificador Models\SettingsTestCase#testGetTipoEtiqueta

Descripción Comprueba que la lectura del tipo de etiqueta configurado a través del modelo funciona correctamente.

R. Esperado La llamada al método de obtención del tipo de etiqueta configurado retorna un entero.


Identificador Models\SettingsTestCase#testSetPlazo

Descripción Comprueba que el cambio del estado de plazo de envío (abierto o cerrado) se produce correctamente.

R. Esperado La llamada al método de cambio del estado de plazo de envío para establecer un valor opuesto al estado actual funciona correctamente, y la lectura posterior de la configuración retorna una instancia de configuración con el nuevo valor.


Identificador Models\SettingsTestCase#testSetDBOpen

Descripción Comprueba que el cambio del estado de apertura de la base de datos se produce correctamente.

R. Esperado La llamada al método de cambio del estado apertura de la base de datos para establecer un valor opuesto al estado actual funciona correctamente, y la lectura posterior de la configuración retorna una instancia de configuración con el nuevo valor.


Identificador Models\SettingsTestCase#testSetRedSettings

Descripción Comprueba que la modificación de la configuración de los parámetros de la red a través del modelo funciona correctamente.

R. Esperado La llamada al método de modificación de la configuración de la red no produce excepciones, y la lectura posterior de la configuración retorna una instancia de configuración con los nuevos valores.




Identificador Models\SettingsTestCase#testSetNullMail

Descripción Comprueba que el cambio de las direcciones de correo a las que enviar notificaciones se produce correctamente cuando se desea borrar las asignadas.

R. Esperado La llamada al método de cambio de las direcciones de correo a las que enviar notificaciones sin parámetros elimina las direcciones configuradas, y la lectura posterior de las mismas retorna un valor nulo.


StatsTestCase

Identificador Models\StatsTestCase#testGetValues

Descripción Comprueba que los valores estadísticos se calculan correctamente.

R. Esperado Los totales obtenidos a través del modelo coinciden con valores calculados previamente de forma independiente, y los valores totales referidos al total de entidades de cada tipo y referidos a subconjuntos de éstas coinciden entre sí.


Identificador Models\StatsTestCase#testGetCountryRatios

Descripción Comprueba que los valores de número de ponentes por país son consistentes con el número de ponentes registrados.

R. Esperado La suma del número de ponentes obtenidos para de cada país coincide con el número total de ponentes registrados.


TripsTestCase

Identificador Models\TripsTestCase#testCreateAndDeleteTrip

Descripción Comprueba que la creación y posterior eliminación de una excursión a través del modelo funciona correctamente.

R. Esperado La llamada al método de creación de la nueva excursión retorna el identificador de la excursión creada y su borrado posterior no produce excepciones.


Identificador Models\TripsTestCase#testGetTrip

Descripción Comprueba que la obtención de los datos de una excursión a partir de su identificador a través del modelo funciona correctamente.

R. Esperado La llamada al método del modelo retorna una instancia de la excursión solicitada.


Identificador Models\TripsTestCase#testGetNonExistingTrip

Descripción Comprueba que la obtención de los datos de una excursión a partir de un identificador de excursión inexistente funciona de la manera esperada.





Identificador Models\TripsTestCase#testSetTripName

Descripción Comprueba que la modificación del nombre de una excursión a través del modelo funciona correctamente.

R. Esperado La llamada al método del modelo para modificar el nombre de la excursión no produce excepciones, y la lectura posterior de sus datos retorna un objeto con el nuevo nombre.


Identificador Models\TripsTestCase#testGetTripList

Descripción Comprueba que el listado de las excursiones funciona correctamente.

R. Esperado La llamada al método retorna una lista de excursiones con tantos elementos como excursiones existen en la base de datos ordenados alfabéticamente en sentido decreciente por el nombre de sala.


Identificador Models\TripsTestCase#testDeleteNonExistingTrip

Descripción Comprueba que la solicitud de borrado de una excursión a partir de un identificador de excursión inexistente funciona de la manera esperada.



UserTestCase

Identificador Models\UserTestCase#testGetTitles

Descripción Comprueba que el listado de títulos honoríficos guardados en la base de datos funciona correctamente.

R. Esperado La llamada al método del modelo retorna un array con los mismos títulos obtenidos a través de una lectura independiente de la base de datos.


Identificador Models\UserTestCase#testGetRandomPassword

Descripción Comprueba que la generación de una contraseña aleatoria funciona correctamente.

R. Esperado La llamada al método del modelo produce un string con una contraseña no nula de longitud mayor o igual a 10.


Identificador Models\UserTestCase#testGetUserObj

Descripción Comprueba que la obtención de los datos de un usuario conocido funciona correctamente.

R. Esperado La llamada al método retorna una instancia de usuario cuyo identificador coincide con el de un usuario creado previamente.


Identificador Models\UserTestCase#testGetUserObjWrongID

Descripción Comprueba que la obtención de los datos de un usuario a partir de un identificador de usuario inexistente funciona de la manera esperada.

R. Esperado La llamada al método del modelo produce una excepción de tipo \CMMSE\Exceptions\UnknownUserException.




Identificador Models\UserTestCase#testGetUsers

Descripción Comprueba que la obtención de los datos de un conjunto de usuarios conocido a partir de sus identificadores funciona correctamente.

R. Esperado La llamada al método proporcionando retorna un array que contiene únicamente el identificador de un usuario conocido (creado previamente) retorna un array de instancias de \CMMSE\Doctrine\User que contiene como único elemento al usuario creado.


Identificador Models\UserTestCase#testGetUsersEmptyIDs

Descripción Comprueba que la obtención de los datos de un conjunto de usuarios vacío funciona correctamente.

R. Esperado La llamada al método retorna un array vacío sin producir excepciones.


Identificador Models\UserTestCase#testGetUsersWrongIDs

Descripción Comprueba que la obtención de los datos de un conjunto de usuarios inexistente funciona de la manera esperada.

R. Esperado La llamada al método proporcionando un array que contiene únicamente el identificador de un usuario inexistente produce una excepción de tipo \CMMSE\Exceptions\UnknownUserException.


Identificador Models\UserTestCase#testTestUserPassword

Descripción Comprueba que el método de comprobación de contraseña para un usuario con contraseña conocida funciona de la manera esperada cuando se proporciona la contraseña correcta



Identificador Models\UserTestCase#testSetUserPassword

Descripción Comprueba que el método del modelo de modificación de contraseñas de usuario funciona correctamente.

R. Esperado La creación de un nuevo usuario utilizando una contraseña conocida retorna un usuario cuyo hash de contraseña coincide con el de la contraseña utilizada, y la posterior modificación de la misma modifica el hash de contraseña al valor esperado.


Identificador Models\UserTestCase#testDeleteUser

Descripción Comprueba que la eliminación de usuarios a través del modelo funciona correctamente.

R. Esperado La llamada al método de borrado no produce excepciones, y el intento de lectura directa posterior del mismo retorna null.




Identificador Models\UserTestCase#testInsertUser

Descripción Comprueba que la creación de nuevos usuarios a través del modelo funciona correctamente.

R. Esperado La llamada al método de creación de nuevo usuario no produce excepciones, retorna un identificador de usuario positivo, y la lectura posterior del mismo retorna una instancia con los datos esperados.


Identificador Models\UserTestCase#testUpdateUser

Descripción Comprueba que la modificación de los datos de usuarios existentes funciona correctamente.

R. Esperado La llamada al método de modificación retorna cierto, y la lectura posterior de los datos asociados al mismo retorna una instancia con los datos actualizados.


Identificador Models\UserTestCase#testUpdateUserWrongUser

Descripción Comprueba que la modificación de los datos de usuarios inexistentes funciona correctamente.

R. Esperado La llamada al método de modificación utilizando un identificador de usuario inexistente retorna falso y no produce excepciones.


7.2.6 Tests\Models\Factories

ModelFactoryTestCase

Identificador Models\Factories\ModelFactoryTestCase#testGetModel

Descripción Comprueba que la instanciación de modelos a partir de interfaces conocidas funciona correctamente.

R. Esperado Para cada interfaz, se retorna un objeto que implementa la interfaz de modelo solicitada.


Identificador Models\Factories\ModelFactoryTestCase#testGetNonExistingModel

Descripción Comprueba que la instanciación de modelos a partir de interfaces desconocidas funciona de la manera esperada.

R. Esperado La llamada al método de obtención de modelo utilizando una interfaz inexistente produce una excepción.




7.2.7 Tests\Controllers\Admin\PDF

CertificadosTestCase

Identificador Controllers\Admin\PDF\CertificadosTestCase#testGetAll

Descripción Comprueba que el archivo PDF que contiene todos los certificados de asistencia se genera correctamente.

R. Esperado La acción para obtener todos los certificados del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es certificates_all.pdf que contiene tantas páginas como ponentes hay registrados, y éstas son de tipo plantilla.


Identificador Controllers\Admin\PDF\CertificadosTestCase#testGetAllPaid

Descripción Comprueba que el archivo PDF que contiene todos los certificados de asistencia para los ponentes que han pagado se genera correctamente.

R. Esperado La acción para obtener todos los certificados del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es certificates_all_paid.pdf que contiene tantas páginas como ponentes han pagado, y éstas son de tipo plantilla.


Identificador Controllers\Admin\PDF\CertificadosTestCase#testGetOne

Descripción Comprueba que el archivo PDF que contiene el certificado de asistencia de un único ponente se genera correctamente.

R. Esperado La acción para obtener el certificado de un ponente del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es certificate.pdf que contiene una única página, y ésta es de tipo plantilla.


Identificador Controllers\Admin\PDF\CertificadosTestCase#testGetOneEmptyID

Descripción Comprueba que el archivo PDF que contiene el certificado de asistencia de un único ponente genera la respuesta esperada cuando no se proporciona un ID de usuario.

R. Esperado La acción para obtener el certificado de un ponente del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es nulo, sin páginas, y con valor 4040 para el campo que representa el código de error.


Identificador Controllers\Admin\PDF\CertificadosTestCase#testGetOneNegativeID

Descripción Comprueba que el archivo PDF que contiene el certificado de asistencia de un único ponente genera la respuesta esperada cuando se proporciona un ID de usuario negativo.

R. Esperado La acción para obtener el certificado de un ponente del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es nulo, sin páginas, y con valor 4040 para el campo que representa el código de error.




Identificador Controllers\Admin\PDF\CertificadosTestCase#testGetSelected

Descripción Comprueba que el archivo PDF que contiene el certificado de asistencia de un conjunto de ponentes se genera correctamente.

R. Esperado La acción para obtener el certificado de un conjunto de ponentes retorna una instancia de la clase PDFResponse cuyo nombre de archivo es certificates_selected.pdf, que contiene tantas páginas como usuarios en el conjunto de ponentes solicitado, y éstas son de tipo plantilla.


Identificador Controllers\Admin\PDF\CertificadosTestCase#testGetSelectedNoSelection

Descripción Comprueba que el archivo PDF que contiene el certificado de asistencia de un conjunto de ponentes se genera correctamente cuando no se seleccionan ponentes.

R. Esperado La acción para obtener el certificado de un conjunto de ponentes cuando éste es vacío retorna una instancia de la clase PDFResponse cuyo nombre de archivo es certificates_selected.pdf, que contiene una única página que contiene un mensaje de error de tipo string.


Etiquetas15TestCase

Identificador Controllers\Admin\PDF\Etiquetas15TestCase#testGetTodos_Horizontal15

Descripción Comprueba que el archivo PDF que contiene las etiquetas horizontales de tamaño 15x7.5cm para los ponentes registrados se genera correctamente.

R. Esperado La llamada al controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es etiquetas_todos_horizontal15x75.pdf, que contiene una instancia de una vista PDF que genera un documento con el número de páginas esperado en función del número de ponentes registrados.


Identificador Controllers\Admin\PDF\Etiquetas15TestCase#testGetTodos_Vertical

Descripción Comprueba que el archivo PDF que contiene las etiquetas verticales para los ponentes registrados se genera correctamente.

R. Esperado La llamada al controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es etiquetas_todos_vertical.pdf, que contiene una instancia de una vista PDF que genera un documento con el número de páginas esperado en función del número de ponentes registrados.


Identificador Controllers\Admin\PDF\Etiquetas15TestCase#testGetBlanco_Horizontal15

Descripción Comprueba que el archivo PDF que contiene las etiquetas en blanco horizontales de tamaño 15x7.5cm se genera correctamente.

R. Esperado La llamada al controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es etiquetas_blanco_horizontal15x75.pdf, que contiene una instancia de una vista PDF que genera un documento con una única página.




Identificador Controllers\Admin\PDF\Etiquetas15TestCase#testGetBlanco_Vertical

Descripción Comprueba que el archivo PDF que contiene las etiquetas en blanco verticales de tamaño 15x7.5cm se genera correctamente.

R. Esperado La llamada al controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es etiquetas_blanco_horizontal15x75.pdf, que contiene una instancia de una vista PDF que genera un documento con una única página.


Identificador Controllers\Admin\PDF\Etiquetas15TestCase#testGetDinnerGala_Horizontal15

Descripción Comprueba que el archivo PDF que contiene las etiquetas para la cena de gala horizontales de tamaño 15x7.5cm se genera correctamente.

R. Esperado La llamada al controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es etiquetas_dinnergala_horizontal15x75.pdf, que contiene una instancia de una vista PDF que genera un documento con una única página.


Identificador Controllers\Admin\PDF\Etiquetas15TestCase#testGetExcursion_Horizontal15

Descripción Comprueba que el archivo PDF que contiene las etiquetas horizontales para la asistencia a excursiones de tamaño 15x7.5cm se genera correctamente.

R. Esperado La llamada al controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es etiquetas_excursion_horizontal15x75.pdf, que contiene una instancia de una vista PDF que genera un documento con tantas páginas como excursiones hay programadas.


Identificador Controllers\Admin\PDF\Etiquetas15TestCase#testGetOrgan_Horizontal15

Descripción Comprueba que el archivo PDF que contiene las etiquetas distintivas para los miembros de la organización de tamaño 15x7.5cm se genera correctamente.

R. Esperado La llamada al controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es etiquetas_organ_horizontal15x75.pdf, que contiene una instancia de una vista PDF que genera un documento con una única página.


Identificador Controllers\Admin\PDF\Etiquetas15TestCase#testGetRestaurant_Horizontal15

Descripción Comprueba que el archivo PDF que contiene las etiquetas de restaurante de tamaño 15x7.5cm se genera correctamente.

R. Esperado La llamada al controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es etiquetas_restaurant_horizontal15x75.pdf, que contiene una instancia de una vista PDF que genera un documento con una única página.




Etiquetas9TestCase

Identificador Controllers\Admin\PDF\Etiquetas9TestCase#testGetTodos_Horizontal9

Descripción Comprueba que el archivo PDF que contiene las etiquetas horizontales de tamaño 9.2x6.25cm para los ponentes registrados se genera correctamente.

R. Esperado La llamada al controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es etiquetas_todos_horizontal9.2x6.25.pdf, que contiene una instancia de una vista PDF que genera un documento con el número de páginas esperado en función del número de ponentes registrados.


Identificador Controllers\Admin\PDF\Etiquetas9TestCase#testGetBlanco_Horizontal9

Descripción Comprueba que el archivo PDF que contiene las etiquetas en blanco horizontales de tamaño 9.2x6.25cm se genera correctamente.

R. Esperado La llamada al controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es etiquetas_blanco_horizontal9.2x6.25.pdf, que contiene una instancia de una vista PDF que genera un documento con una única página.


Identificador Controllers\Admin\PDF\Etiquetas9TestCase#testGetDinnerGala_Horizontal9

Descripción Comprueba que el archivo PDF que contiene las etiquetas para la cena de gala horizontales de tamaño 9.2x6.25cm se genera correctamente.

R. Esperado La llamada al controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es etiquetas_dinnergala_horizontal9.2x6.25.pdf, que contiene una instancia de una vista PDF que genera un documento con una única página.


Identificador Controllers\Admin\PDF\Etiquetas9TestCase#testGetExcursion_Horizontal9

Descripción Comprueba que el archivo PDF que contiene las etiquetas horizontales para la asistencia a excursiones de tamaño 9.2x6.25cm se genera correctamente.

R. Esperado La llamada al controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es etiquetas_excursion_horizontal9.2x6.25.pdf, que contiene una instancia de una vista PDF que genera un documento con tantas páginas como excursiones hay programadas.


Identificador Controllers\Admin\PDF\Etiquetas9TestCase#testGetOrgan_Horizontal9

Descripción Comprueba que el archivo PDF que contiene las etiquetas distintivas para los miembros de la organización de tamaño 9.2x6.25cm se genera correctamente.

R. Esperado La llamada al controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es etiquetas_organ_horizontal9.2x6.25.pdf, que contiene una instancia de una vista PDF que genera un documento con una única página.




Identificador Controllers\Admin\PDF\Etiquetas9TestCase#testGetRestaurant_Horizontal9

Descripción Comprueba que el archivo PDF que contiene las etiquetas de restaurante de tamaño 9.2x6.25cm se genera correctamente.

R. Esperado La llamada al controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es etiquetas_restaurant_horizontal9.2x6.25.pdf, que contiene una instancia de una vista PDF que genera un documento con una única página.


FacturasTestCase

Identificador Controllers\Admin\PDF\FacturasTestCase#testGetOne

Descripción Comprueba que el archivo PDF que contiene la factura de un único usuario se genera correctamente.

R. Esperado La acción para obtener la factura de un usuario del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es invoice.pdf que contiene una única página, y ésta es de tipo plantilla.


Identificador Controllers\Admin\PDF\FacturasTestCase#testGetOneNoPapers

Descripción Comprueba que el archivo PDF que contiene la factura de un único usuario sin papers enviados se genera correctamente.

R. Esperado La acción para obtener la factura de un usuario sin papers enviados del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es invoice.pdf que contiene una única página, y ésta es de tipo plantilla.


Identificador Controllers\Admin\PDF\FacturasTestCase#testGetOneEmptyID

Descripción Comprueba que el archivo PDF que contiene la factura de un único usuario cuando no se especifica un ID de usuario funciona de la manera esperada.

R. Esperado La acción para obtener la factura de un usuario del controlador retorna una instancia de la clase PDFResponse sin nombre de archivo asociado ni contenido, y con valor 4040 para el campo que representa el código de error.


Identificador Controllers\Admin\PDF\FacturasTestCase#testGetOneNegativeID

Descripción Comprueba que el archivo PDF que contiene la factura de un único usuario cuando se especifica un ID de usuario negativo funciona de la manera esperada.



Identificador Controllers\Admin\PDF\FacturasTestCase#testGetOnePayForAll

Descripción Comprueba que el archivo PDF que contiene la factura de un único usuario, cuando se indica que debe pagar por todos los papers aceptados, funciona de la manera esperada.

R. Esperado La acción para obtener la factura de un usuario del controlador, pagando por todos los papers enviados, retorna una instancia de la clase PDFResponse cuyo nombre de archivo es invoice.pdf que contiene una única página, y ésta es de tipo plantilla.




Identificador Controllers\Admin\PDF\FacturasTestCase#testGetOnePayForAllNoPapers

Descripción Comprueba que el archivo PDF que contiene la factura de un único usuario, cuando se indica que debe pagar por todos los papers aceptados, funciona de la manera esperada cuando el usuario no ha enviado ningún paper.

R. Esperado La acción para obtener la factura de un usuario del controlador pagando por todos los papers enviados, cuando el usuario no ha enviado papers, retorna una instancia de la clase PDFResponse cuyo nombre de archivo es invoice.pdf que contiene una única página, y ésta es de tipo plantilla.


Identificador Controllers\Admin\PDF\FacturasTestCase#testGetOnePayForAllEmptyID

Descripción Comprueba que el archivo PDF que contiene la factura de un único usuario, cuando se indica que debe pagar por todos los papers enviados, funciona de la manera esperada cuando no se especifica un ID de usuario.



Identificador Controllers\Admin\PDF\FacturasTestCase#testGetOnePayForAllNegativeID

Descripción Comprueba que el archivo PDF que contiene la factura de un único usuario, cuando se indica que debe pagar por todos los papers enviados, funciona de la manera esperada cuando se especifica un ID de usuario no válido (negativo).

R. Esperado La acción para obtener la factura de un usuario del controlador retorna una instancia de la clase PDFResponse sin nombre de archivo asociado ni contenido, y con valor 4040 para el campo que representa el código de error


Identificador Controllers\Admin\PDF\FacturasTestCase#testGetAll

Descripción Comprueba que el archivo PDF que contiene la factura de todos los usuarios funciona de la manera esperada.

R. Esperado La acción del controlador para obtener la factura de todos los usuarios registrados retorna una instancia de la clase PDFResponse cuyo nombre de archivo es invoices_all.pdf que contiene tantas páginas como usuarios han solicitado factura, y éstas son de tipo plantilla.


Identificador Controllers\Admin\PDF\FacturasTestCase#testGetAllPayForAll

Descripción Comprueba que el archivo PDF que contiene las facturas de todos los usuarios funciona de la manera esperada cuando se indica que deben pagar por todos los papers enviados.

R. Esperado La acción del controlador para obtener la factura de todos los usuarios registrados (pagando por todos los papers enviados) retorna una instancia de la clase PDFResponse cuyo nombre de archivo es invoices_all_payforall.pdf que contiene tantas páginas como usuarios han solicitado factura, y éstas son de tipo plantilla.




Identificador Controllers\Admin\PDF\FacturasTestCase#testGetAllTypesCountMatch

Descripción Comprueba que los archivos PDF que contienen las facturas de todos los usuarios pagando únicamente la cuota de inscripción y pagando por todos los papers enviados son consistentes entre sí.

R. Esperado Las acciones del controlador para obtener las facturas de todos los usuarios pagando únicamente la cuota de inscripción y pagando por todos los papers enviados retornan archivos con el mismo número de páginas.


Identificador Controllers\Admin\PDF\FacturasTestCase#testGetAllReady

Descripción Comprueba que el archivo PDF que contiene todas las facturas listas para imprimir funciona correctamente.

R. Esperado La acción del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es invoices_all_ready.pdf que contiene tantas páginas como usuarios han solicitado factura, tienen número de factura asignado y sus facturas han sido marcadas como listas para imprimir.


Identificador Controllers\Admin\PDF\FacturasTestCase#testGetAllReadyPayForAll

Descripción Comprueba que el archivo PDF que contiene todas las facturas listas para imprimir, pagando por todos los papers enviados, funciona correctamente.

R. Esperado La acción del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es invoices_all_ready_payforall.pdf que contiene tantas páginas como usuarios han solicitado factura, tienen número de factura asignado y sus facturas han sido marcadas como listas para imprimir.


Identificador Controllers\Admin\PDF\FacturasTestCase#testGetAllReadyTypesCountMatch

Descripción Comprueba que los archivos PDF que contienen las facturas de todos los usuarios marcadas como listas para imprimir pagando únicamente la cuota de inscripción y pagando por todos los papers enviados son consistentes entre sí.

R. Esperado Las acciones del controlador para obtener las facturas de todos los usuarios listas para imprimir pagando únicamente la cuota de inscripción y pagando por todos los papers enviados retornan archivos con el mismo número de páginas.


Identificador Controllers\Admin\PDF\FacturasTestCase#testGetSelected

Descripción Comprueba que los archivos PDF que contienen las facturas, pagando únicamente la cuota de inscripción, de usuarios seleccionados aleatoriamente de entre aquellos que tienen asignado número de factura funciona correctamente.

R. Esperado La acción del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es invoices_selected.pdf que contiene tantas páginas como IDs de usuarios distintos se han proporcionado.




Identificador Controllers\Admin\PDF\FacturasTestCase#testGetSelectedPayForAll

Descripción Comprueba que los archivos PDF que contienen las facturas, pagando por todos los papers enviados, de usuarios seleccionados aleatoriamente de entre aquellos que tienen asignado número de factura funciona correctamente.

R. Esperado La acción del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es invoices_selected_payforall.pdf que contiene tantas páginas como IDs de usuarios distintos se han proporcionado.


Identificador Controllers\Admin\PDF\FacturasTestCase#testGetSelectedTypesCountMatch

Descripción Comprueba que los archivos PDF que contienen las facturas de un subconjunto de usuarios seleccionados cuando se indica que paguen únicamente la cuota de inscripción y cuando se indica que paguen por todos los papers enviados son consistentes entre sí.

R. Esperado Las acciones del controlador para obtener las facturas de un subconjunto de usuarios seleccionados pagando únicamente la cuota de inscripción y pagando por todos los papers enviados retornan archivos con el mismo número de páginas.


JustificantesTestCase

Identificador Controllers\Admin\PDF\JustificantesTestCase#testGetAll

Descripción Comprueba que el archivo PDF que contiene los justificantes de pago de todos los usuarios funciona de la manera esperada.

R. Esperado La acción del controlador para obtener los justificantes de todos los usuarios registrados retorna una instancia de la clase PDFResponse cuyo nombre de archivo es proofofpayment_all.pdf que contiene tantas páginas como usuarios no han solicitado factura, y éstas son de tipo plantilla.


Identificador Controllers\Admin\PDF\JustificantesTestCase#testGetAllPayForAll

Descripción Comprueba que el archivo PDF que contiene los justificantes de pago de todos los usuarios funciona de la manera esperada cuando se indica que deben pagar por todos los papers enviados.

R. Esperado La acción del controlador para obtener los justificantes de todos los usuarios registrados (pagando por todos los papers enviados) retorna una instancia de la clase PDFResponse cuyo nombre de archivo es proofofpayment_all_paid_payforall.pdf que contiene tantas páginas como usuarios no han solicitado factura, y éstas son de tipo plantilla.


Identificador Controllers\Admin\PDF\JustificantesTestCase#testGetAllTypesCountMatch

Descripción Comprueba que los archivos PDF que contienen los justificantes de pago de todos los usuarios pagando únicamente la cuota de inscripción y pagando por todos los papers enviados son consistentes entre sí.

R. Esperado Las acciones del controlador para obtener los justificantes de todos los usuarios pagando únicamente la cuota de inscripción y pagando por todos los papers enviados retornan archivos con el mismo número de páginas.




Identificador Controllers\Admin\PDF\JustificantesTestCase#testGetAllPaid

Descripción Comprueba que el archivo PDF que contiene todos los justificantes de los usuarios cuyo pago ha sido confirmado funciona correctamente.

R. Esperado La acción del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es proofofpayment_all_paid.pdf que contiene tantas páginas como usuarios no han solicitado factura y su pago ha sido confirmado.


Identificador Controllers\Admin\PDF\JustificantesTestCase#testGetAllPaidPayForAll

Descripción Comprueba que los archivos PDF que contienen los justificantes de pago, pagando por todos los papers enviados, de todos los usuarios que no han solicitado factura funciona correctamente.

R. Esperado La acción del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es proofofpayment_all_paid.pdf que contiene tantas páginas como usuarios con pago confirmado no han solicitado factura.


Identificador Controllers\Admin\PDF\JustificantesTestCase#testGetAllPaidTypesCountMatch

Descripción Comprueba que los archivos PDF que contienen los justificantes de pago de todos los usuarios cuyo pago ha sido confirmado pagando únicamente la cuota de inscripción y pagando por todos los papers enviados son consistentes entre sí.

R. Esperado Las acciones del controlador para obtener los justificantes de todos los usuarios pagando únicamente la cuota de inscripción y pagando por todos los papers enviados retornan archivos con el mismo número de páginas.


Identificador Controllers\Admin\PDF\JustificantesTestCase#testGetSelected

Descripción Comprueba que los archivos PDF que contienen los justificantes de pago, pagando únicamente la cuota de inscripción, de usuarios seleccionados aleatoriamente de entre aquellos cuyo pago ha sido confirmado funciona correctamente.

R. Esperado La acción del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es profofpayment_selected.pdf que contiene tantas páginas como IDs de usuarios distintos se han proporcionado.


Identificador Controllers\Admin\PDF\JustificantesTestCase#testGetSelectedPayForAll

Descripción Comprueba que los archivos PDF que contienen los justificantes de pago, pagando por todos los papers enviados, de usuarios seleccionados aleatoriamente de entre aquellos que no tienen asignado número de factura funciona correctamente.

R. Esperado La acción del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es invoices_selected_payforall.pdf que contiene tantas páginas como IDs de usuarios distintos se han proporcionado.




PonenciasTestCase

Identificador Controllers\Admin\PDF\PonenciasTestCase#testGetOne

Descripción Comprueba que el archivo PDF que contiene el documento que certifica la presentación de una ponencia se genera correctamente.

R. Esperado La acción del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es seminar_certificate.pdf que contiene una única página, y ésta es de tipo plantilla.


Identificador Controllers\Admin\PDF\PonenciasTestCase#testGetOneEmptyID

Descripción Comprueba que la solicitud del archivo PDF que contiene el documento que certifica la presentación de una ponencia genera la respuesta esperada cuando no se proporciona un ID de paper.

R. Esperado La acción del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es nulo, sin páginas, y con valor 4040 para el campo que representa el código de error.


Identificador Controllers\Admin\PDF\PonenciasTestCase#testGetOneNegativeID

Descripción Comprueba que la solicitud del archivo PDF que contiene el documento que certifica la presentación de una ponencia genera la respuesta esperada cuando se proporciona un ID de paper negativo.

R. Esperado La acción del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es nulo, sin páginas, y con valor 4040 para el campo que representa el código de error.


Identificador Controllers\Admin\PDF\PonenciasTestCase#testGetAll

Descripción Comprueba que el archivo PDF que contiene todos los certificados de presentación de ponencias se generan correctamente.

R. Esperado La acción del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es seminar_certificate_all.pdf que contiene tantas páginas como papers aceptados hay en el sistema, y éstas son de tipo plantilla.


Identificador Controllers\Admin\PDF\PonenciasTestCase#testGetAllPaid

Descripción Comprueba que el archivo PDF que contiene todos los certificados de presentación de ponencias para los usuarios que han pagado se generan correctamente.

R. Esperado La acción del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es seminar_certificate_all_paid.pdf que contiene tantas páginas como papers aceptados de ponentes que han pagado la cuota de inscripción hay en el sistema, y éstas son de tipo plantilla.




Identificador Controllers\Admin\PDF\PonenciasTestCase#testGetSelected

Descripción Comprueba que el archivo PDF que contiene los certificados presentación de ponencias para un subconjunto de papers seleccionado aleatoriamente se genera correctamente.

R. Esperado La acción del controlador retorna una instancia de la clase PDFResponse cuyo nombre de archivo es seminar_certificate_selected.pdf que contiene tantas páginas como papers hay en el conjunto seleccionado, y éstas son de tipo plantilla.


Conclusiones | Plataforma web para la gestión de conferencias científico-técnicas


8 CONCLUSIONES

Al iniciar el estudio de este proyecto rápidamente me di cuenta de la cantidad de aspectos que debía

resolver, y cómo la aplicación de patrones de diseño teóricos existentes podían ser de utilidad en esta

labor. Personalmente he descubierto que el uso de librerías y herramientas existentes junto a los

mencionados patrones arquitectónicos descritos en la memoria son una herramienta capital en la

construcción de sistemas complejos. En concreto, considero especialmente positivos los

conocimientos adquiridos relativos a la gestión automática de dependencias de software, la

construcción modular de aplicaciones por capas utilizando MVC, o conceptos hasta ahora

desconocidos para mí como la testabilidad de un proyecto.

Pese a que hay aspectos mejorables y algunas ideas que finalmente no han podido llevarse a cabo,

estoy satisfecho con el resultado obtenido, y considero que personalmente este proyecto ha sido una

importante fuente de aprendizaje.

Plataforma web para la gestión de conferencias científico-técnicas | Bibliografía


9 BIBLIOGRAFÍA

En esta sección se listan libros y páginas web utilizadas como referencia durante el desarrollo de la

aplicación y la redacción del presente documento. Se trata, principalmente, de APIs de los lenguajes

de programación y librerías utilizadas, documentos que definen los estándares y protocolos sobre los

que está construida, y otras fuentes que describen la base teórica que justifica las soluciones

adoptadas en el proyecto.

9.1 Libros y artículos

[GoF94] Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John. ”Design Patterns: Elements of

Reusable Object-Oriented Software”. Addison-Wesley. 1995. ISBN 978-0-201-63361-0.

[STAL04] Stallings, William. “Comunicaciones y redes de computadores, Séptima edición”. Pearson

Educación/Prentice Hall. 2004. ISBN 978-84-205-4110-5.

[ROB06] Robbins, Jennifer. “Web Design in a Nutshell, 3rd Edition”. O’Reilly Media Inc. 2006. ISBN

978-0-596-00987-8.

[W3C03] World Wide Web Consortium. “Guías breves de tecnologías W3C”. Oficina del W3C en

España/Fundación CTIC. 2005.

9.2 Referencias en Internet

Conceptos de Ingeniería de Software

[WIK01] Wikipedia Contributors. “Model View Controller”. http://en.wikipedia.org/wiki/Model–

view–controller. 2013.

[CAI00] Cai, Jason; Kapila, Ranjit; Pal, Gaurav. “HMVC: The layered pattern for developing strong

client tiers”. http://www.javaworld.com/article/2076128/. 2000.

Lenguajes y estándares web

[PHP14] The PHP Group. “PHP Documentation”. http://www.php.net/docs.php. 2014.

[PHP01] The PHP Group. “PUT method support”. http://php.net/manual/ro/features.file-upload.put-

method.php. 2014.

[PHP02] The PHP Group. “PHP Language Reference: Overloading”.

https://www.php.net/manual/en/language.oop5.overloading.php. 2014.

[PHP03] The PHP Group. “PHP Installation FAQ”.

http://php.net/manual/en/faq.installation.php#faq.installation.apache2. 2014.

[PHP04] The PHP Group. “PHP: Preface”. http://www.php.net/manual/en/preface.php. 2014.

[WIKI05] Wikipedia Contributors. “PHP”. http://en.wikipedia.org/wiki/PHP. 2013.

[WIKI06] Wikipedia Contributors. “Java Platform, Enterprise Edition”.

http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition. 2014.

Bibliografía | Plataforma web para la gestión de conferencias científico-técnicas


[MOZ01] Mozilla Developer Network & Collaborators. “Guia HTML para desarrolladores: HTML5”.

https://developer.mozilla.org/es/docs/HTML/HTML5. 2014.

[W3C01] World Wide Web Consortium. “HTML5: A vocabulary and associated APIs for HTML and

XHTML. Chapter 5: Loading Web pages”. http://www.w3.org/TR/html5/browsers.html. 2014.

[W3C02] World Wide Web Consortium. “Markup Validation Service”. http://validator.w3.org/. 2014.

[W3C04] World Wide Web Consortium. “CSS3 basic box model”. http://www.w3.org/TR/css3-box/.

2014.

[W3C05] World Wide Web Consortium. “CSS Backgrounds and Borders Module Level 3”.

http://www.w3.org/TR/css3-background/. 2014.

[W3C06] World Wide Web Consortium. “CSS fonts Module Level 3”. ttp://www.w3.org/TR/css-fonts-

3/. 2014.

[W3C07] World Wide Web Consortium. “Media Queries”. http://www.w3.org/TR/css3-

mediaqueries/. 2014.

[W3C08] World Wide Web Consortium. “HTML5: A vocabulary and associated APIs for HTML and

XHTML. W3C Recommendation 28 October 2014”. http://www.w3.org/TR/2014/REC-html5-

20141028/. 2014.

[MOZ02] Mozilla Developer Network & Collaborators . “JavaScript reference: Arguments object”.

https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/arguments. 2014.

Aspectos legales y herramientas de gestión de

congresos

[AEPD14] Agencia Española de Protección de Datos. “Guía sobre el uso de las cookies”.

http://www.agpd.es/portalwebAGPD/canaldocumentacion/publicaciones/common/Guias/Guia_Coo

kies.pdf. 2014.

[WIKI04] Wikipedia Contributors. “Código de identificación fiscal”.

http://es.wikipedia.org/wiki/Código_de_identificación_fiscal. 2014.

[CONFT01] ConfTool GmbH. “ConfTool: Conference and Event Management Software”.

http://www.conftool.net/. 2014.

[AJXL14] Shatalov , Alexander. “Ajaxel CMS demo”. http://demo.ajaxel.com. 2014.

[DBADM01] Bintintan, Andrei. “Webdbadmin”. http://www.webdbadmin.com. 2014.

Herramientas de gestión de software

[KERN01] Git Contributors. “git-shortlog Manual Page”.

https://www.kernel.org/pub/software/scm/git/docs/git-shortlog.html. 2014.

[VBOX01] Moore, Ian & phpVirtualBox Contributors. “phpVirtualBox: A web-based front-end to

VirtualBox written in PHP”. http://sourceforge.net/projects/phpvirtualbox/. 2014.

Plataforma web para la gestión de conferencias científico-técnicas | Bibliografía


Protocolo HTTP y servidores web

[HTTP01] The Internet Engineering Task Force. “Request for Comments 2616: Hypertext Transfer

Protocol 1.1”. http://tools.ietf.org/html/rfc2616. 2014.

[HTTP02] The Internet Engineering Task Force. “Request for Comments 2818: HTTP Over TLS”.

http://tools.ietf.org/html/rfc2818. 2014.

[HTTP03] The Internet Engineering Task Force. “Request for Comments 2660: Secure Hypertext

Transfer Protocol”. http://tools.ietf.org/html/rfc2660. 2014.

[SYMF01] SensioLabs & Symfony Contributors. “Symfony 2 and HTTP Fundamentals”.

http://symfony.com/doc/current/book/http_fundamentals.html. 2014.

[APCH01] Wikipedia Contributors. “Apache HTTP Server”.

http://en.wikipedia.org/wiki/Apache_HTTP_Server. 2014.

[FACEB01] Zhao, Haiping. “HipHop for PHP: Move Fast”.

https://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php--move-fast/. 2014.

Librerías

[DOC01] Doctrine Team. “Doctrine 2 ORM’s documentation”. http://docs.doctrine-

project.org/en/2.0.x/. 2014.

[DOC03] Eberlei, Benjamin; Blanco, Guilherme; Wage, Jonathan; Borschel, Roman. “Doctrine Entity

Manager API Documentation”. http://www.doctrine-project.org/api/orm/2.2/class-

Doctrine.ORM.EntityManager.html. 2014.

[TWIG01] SensioLabs & Twig Contributors. “Twig Documentation”.

http://twig.sensiolabs.org/documentation. 2014.

[CAL01] Mitchell, Brady. “Creating iCalendar (ics) files with PHP”. http://bradym.net/php/creating-

icalendar-ics-files-with-php.html. 2014.

[CAL02] Visinoni, Luke. “qcal: An object-oriented iCalendar library written for PHP5”.

https://code.google.com/p/qcal/. 2014.

[EZ01] ez Systems AS. “ezPublish Documentation”. http://pubsvn.ez.no/doxygen/4.0/html/. 2014.

[JQRY01] The jQuery Team. “jQuery API Documentation”. https://api.jquery.com/. 2014.

[JQRY08] StackOverflow Contributors. “Sort date field with tablesorter”.

http://stackoverflow.com/questions/9568473/sort-date-field-with-tablesorter. 2014.

[SYMF02] SensioLabs & Symfony Contributors. “ClassLoader (The Symfony Components)”.

http://symfony.com/doc/2.6/components/class_loader/index.html. 2015.

[SYMF03] SensioLabs & Symfony Contributors. “Cache a ClassLoader (The Symfony Components)”.

http://symfony.com/doc/current/components/class_loader/cache_class_loader.html. 2015.

[SMRT01] Potencier, Fabien. “Templating Engines in PHP”.

http://fabien.potencier.org/article/34/templating-engines-in-php. 2015.

Bibliografía | Plataforma web para la gestión de conferencias científico-técnicas


Casos de prueba y automatización

[WIKI03] Wikipedia Contributors. “Caso de prueba”. http://es.wikipedia.org/wiki/Caso_de_prueba.

2014.

[PHPU01] Bergmann, Sebastian & PHPUnit Documentation Contributors. “PHPUnit Manual:

Assertions”. http://phpunit.de/manual/3.7/en/appendixes.assertions.html. 2014.

[PHPU02] Bergmann, Sebastian & PHPUnit Documentation Contributors. “PHPUnit Manual:

Incomplete and Skipped Tests”. http://phpunit.de/manual/3.7/en/incomplete-and-skipped-

tests.html. 2014.

[PHPU03] Bergmann, Sebastian & PHPUnit Documentation Contributors. “PHPUnit Manual: Writing

Tests for PHPUnit”. http://phpunit.de/manual/3.7/en/writing-tests-for-phpunit.html. 2014.

[MAIL01] Chaiyochlarb, Chan. “Email Addresses Test Cases”.

http://blogs.msdn.com/b/testing123/archive/2009/02/05/email-address-test-cases.aspx. 2014.

[MAIL02] Skeggs , Eli. “node-isemail Test Cases and Error Codes”.

https://github.com/globesherpa/node-isemail/blob/master/test/isemail.js. 2014.

[ANT01] Apache Software Foundation & Ant Project Contributors. “Apache Ant Manual”.

http://ant.apache.org/manual/. 2014.

Estadísticas

[GOG01] Google, Inc. “Google Loader Developer’s Guide”. https://developers.google.com/loader/.

2014.

[JPGR01] Asial Corporation. “JpGraph Documentation”. http://jpgraph.net/. 2015.

[HTTP04] Netcraft Ltd. “June 2014 Netcraft Web Server Survey”.

http://news.netcraft.com/archives/2014/06/06/june-2014-web-server-survey.html. 2014.

[ALEX01] Alexa Internet, Inc. “Alexa Top 500 Global Sites”. http://www.alexa.com/topsites. 2014.

Otros

[PAYP01] PayPal, Inc. “PayPal Developer: Website Payments Pro”.

https://developer.paypal.com/docs/classic/paypal-payments-pro/integration-

guide/WPWebsitePaymentsPro/. 2015.

[IACR01] Wang, Xiaoyun; Feng, Dengguo; Lai, Xuejia; Yu, Hongbo. “Collisions for Hash Functions

MD4, MD5, HAVAL-128 and RIPEMD”. http://eprint.iacr.org/2004/199. 2004.

[PHP05] The PHP Group. “Hash de contraseñas”. http://php.net/manual/es/faq.passwords.php.

2015.

Plataforma web para la gestión de conferencias científico-técnicas | Apéndices


10 APÉNDICES

APENDICE I: Estadísticas de la edición de 2014

Estadísticas demográficas

Las siguientes estadísticas se han generado a partir de una muestra obtenida durante la edición de

2014 (hasta el 4 de julio).

Usuarios 203 Ponentes 201 (99,01 %) Autores 159 (78,33 %)

Papers N/D 51 Aceptados N/D

Simposios 32 Excursiones 2

Medias de papers

Por autor N/D

Por simposio (totales) N/D

Por simposio (aceptados) N/D

Ponentes

Que han solicitado factura 79 (38,92 %)

Que no han solicitado factura 124 (61,08 %)

51 Los valores estadísticos asociados a los números de papers presentados han sido ocultados a petición de la organización del congreso.

Apéndices | Plataforma web para la gestión de conferencias científico-técnicas


Figura 10.1: Número de usuarios registrados por semana

Figura 10.2: Número de usuarios totales en el sistema por semana



Figura 10.3: Número de usuarios por país de procedencia



Figura 10.4: Número de nuevos papers enviados por semana

Figura 10.5: Número de papers totales en el sistema por semana



Figura 10.6: Número de papers aceptados por simposio



Figura 10.7: Número de solicitudes por navegador (todas las páginas)

Figura 10.8: Número de solicitudes por navegador (páginas públicas)



Navegadores usados por número de solicitudes

Navegador Total % del total Páginas públicas

% de las p. públicas

Chrome 10+ 31 255 46,44 % 27 998 44,78 %

Firefox 23 781 35,34 % 22 406 35,84 % Firefox 4+ 23 156 34,41 % 21 781 34,84 % Firefox (otras) 625 0,93 % 625 1,00 %

IE 7 444 11,06 % 7 359 11,77 % IE 11 3 330 4,95 % 3 245 5,19 % IE 10 282 0,42 % 282 0,45 % IE 9 2 175 3,23 % 2 175 3,48 % IE 8 676 1,00 % 676 1,08 % IE (otras) 981 1,46 % 981 1,57 %

Safari 3 865 5,75 % 3 801 6,08 % Safari 5+ 3 848 5,72 % 3 784 6,05 % Safari (otras) 17 0,03 % 17 0,03 %

Opera 154 0,23 % 154 0,24 % Opera 12+ 26 0,04 % 26 0,04 % Opera (otras) 128 0,19 % 128 0,20 %

Bots 224 0,33 % 224 0,36 %

Otros 580 0,86 % 579 0,93 %

TOTAL 67 303 100 % 62 521 100 %

Figura 10.9: Valores muestrales (agregados) de número de solicitudes por navegador

La tabla anterior muestra el número de solicitudes por navegador, desglosando el número total por

versión de navegador y según si la solicitud se realiza desde una sesión de administrador o no.

Esta separación se realiza a partir de la primera versión de cada navegador con soporte relativamente

completo para HTML5 que, en general, se corresponde a las versiones publicadas en marzo de 2011

(coincidiendo aproximadamente con el Last Call del grupo de trabajo de la W3C para HTML5). En el

caso de Internet Explorer, se realiza una separación más explícita por versiones, al ser el navegador

por defecto de facto en el sistema operativo más extendido (Windows) y el que más diferencias

presenta en el soporte para HTML5 entre sus distintas versiones52.

El número de solicitudes considerado en este apartado solo tiene en cuenta páginas generadas

dinámicamente (utilizando PHP). Por tanto, no incluye solicitudes de elementos estáticos, como

imágenes o archivos PDF enviados por los ponentes (justificantes de pago y papers). Sin embargo, sí

incluye archivos descargables, imágenes y hojas de estilo generadas por scripts, como certificados de

asistencia, gráficas estadísticas o archivos CSS.

52 Internet Explorer 8 es la primera versión del navegador de Microsoft en soportar HTML5 (al menos, de manera parcial). Internet Explorer 9 dispone de un soporte más completo, y es la primera versión que pasa el test ACID3.



Figura 10.10: Número de solicitudes por S.O. del cliente (todas las páginas)

Figura 10.11: Número de solicitudes por S.O. del cliente (páginas públicas)



Sistemas Operativos usados por número de solicitudes

Sistema Operativo Total % del total Páginas públicas

% de las p. públicas

Windows 41 112 61,08 % 38 615 61,77 % Windows 7 29 847 44,35 % 27 482 43,96 % Windows XP 6 227 9,25 % 6 095 9,75 % Windows 8 1 287 1,91 % 1 287 2,06 % Windows 8.1 1 442 2,14 % 1 442 2,31 % Windows Vista 2 309 3,43 % 2 309 3,69 %

GNU/Linux 18 121 26,92 % 15 899 25,43 % Ubuntu 14 257 21,18 % 12 068 19,3 % Android 342 0,51 % 319 0,51 % Otros 3 521 5,23 % 3 512 5,62 %

OS X 7 570 11,24 % 7 506 12,00 % iOS 609 0,9 % 545 0,87 % Mac OS X 6 961 10,34 % 6 961 11,13 %

Bots 224 0,33 % 224 0,36 %

Desconocido 277 0,41 % 277 0,44 %

TOTAL 67 304 100 % 62 521 100 %

Figura 10.12: Valores muestrales (agregados) de número de solicitudes por sistema operativo

La tabla anterior muestra el número de solicitudes por sistema operativo y versión, según los datos

reportados por el navegador y/o inferidos en función del tipo navegador, desglosando el número total

por versión y según si la solicitud se realiza desde una sesión de administrador o no.

El número de solicitudes considerado en este apartado solo tiene en cuenta páginas generadas

dinámicamente (utilizando PHP). Por tanto, no incluye solicitudes de elementos estáticos, como

imágenes o archivos PDF enviados por los ponentes (justificantes de pago y papers). Sin embargo, sí

incluye archivos descargables, imágenes y hojas de estilo generadas por scripts, como certificados de

asistencia, gráficas estadísticas o archivos CSS.



Estadísticas de rendimiento

Las estadísticas de este apartado se han generado a partir de una muestra obtenida durante la edición

de 2014 (hasta el 4 de julio). Durante este periodo, la aplicación y su base de datos han estado

hospedadas en un servidor web utilizado, además, para la web de los grupos de investigación de

Recuperación de Información y Computación Paralela de la Universidad de Oviedo. El servidor está

hospedado físicamente en la Escuela Politécnica de Ingeniería de Gijón y, por tanto, hace uso de su red

para acceder a Internet. La conexión ofrece una velocidad aproximada de acceso a Internet de 20Mbps.

El servidor utilizado dispone de un procesador Intel Core i3-2100 de doble núcleo (con 4 procesadores

lógicos) a 3.10 GHz y 3MB de memoria caché compartida, 8 GB de memoria RAM DDR3, un disco (no

SSD) de 500 Gb y una tarjeta de red gigabit full duplex. El sistema utiliza una distribución CentOS 6.5

de 64 bits con un kernel Linux 2.6.32 con soporte SMP. Se utiliza Apache 2.2.15 de 64 bits como servidor

web con un modelo de procesamiento multiproceso (prefork) sin hilos. El sistema utiliza PHP 5.5.9 para

generar las páginas dinámicas y MySQL 5.5.73 para hospedar la base de datos de la aplicación. La

conexión entre el servidor MySQL y los scripts PHP se realiza utilizando el driver nativo (mysqlnd) de

este último utilizando sockets UNIX.

Las estadísticas de uso de CPU mostradas en este apartado reflejan la carga media global del sistema,

la cual incluye tanto el uso de CPU del servidor web como de la base de datos (además de otros

procesos que pudiese haber en el sistema), medida en el momento que se finaliza la generación de la

página correspondiente. Las estadísticas de uso de memoria reflejan únicamente el uso máximo de

memoria realizado por el script PHP que lo recopila, excluyendo, por tanto, el uso de memoria de otros

servicios (como MySQL) y de otras solicitudes que pudiesen estar siendo atendidas simultáneamente.



Figura 10.13: Número de solicitudes HTTP por semana

Figura 10.14: Número de sesiones HTTP por semana



Las gráficas anteriores contienen las medidas recogidas del 21 de marzo al 27 de julio de 2014, y

muestran, agregadas por semanas, el número de solicitudes HTTP recibidas que corresponden con

scripts PHP (excluyendo, por tanto, los archivos estáticos) y el número de sesiones creadas tras

proporcionar un nombre de usuario y contraseña.

La siguiente gráfica muestra de forma conjunta el uso de memoria (escala de a derecha, en megabytes)

y la carga media del sistema53 (escala de la izquierda, en número de procesos) a partir de los datos de

las 68.807 muestras disponibles en este periodo. Estos datos se corresponden con muestras tomadas

al finalizar cada solicitud, es decir, no se corresponden con muestras tomadas de forma contínua a

intervalos de tiempo fijos. Para mantener la claridad de la gráfica, las etiquetas del eje x solo se

muestran cada 10 días, si bien la gráfica sí muestra la media de cada día de forma agregada. La cantidad

medida incluye la memoria usada por el core de PHP (su máquina virtual, Zend Engine) además de la

asignada a los datos del propio script.

En la gráfica se puede apreciar cómo la cantidad de memoria máxima necesaria para atender cada

solicitud individual permanece relativamente constante (alrededor de 3MB). Se aprecian picos

considerables al final del periodo medido, correspondientes a las fechas más próximas al inicio del

congreso (en las cuales el sistema es usado de forma activa por los administradores para revisiones de

última hora y generación de documentación54).

Figura 10.15: Uso medio de CPU y memoria por día

53 Definida como el valor de carga tradicional UNIX correspondiente a la longitud media de la cola de procesos listos en el minuto previo al instante en el que se realiza la medición. Para interpretar este valor hay que tener en cuenta, además, que el servidor utilizado disponde de 4 procesadores lógicos. 54 La generación de documentación (y especialmente aquella necesaria para todos los ponentes registrados, como etiquetas y certificados) consume una cantidad de memoria y CPU notablemente superior al resto de la aplicación.



Las siguientes tablas muestran de forma más detallada los valores de carga media UNIX medidos desde

el 21 de marzo al 3 de julio (inclusive) al finalizar cada solicitud para todas muestras tomadas como

parte de la ejecución de las páginas dinámicas; y la cantidad de tiempo (en segundos), memoria (en

bytes) y número de consultas SQL necesarias en promedio para generar las páginas dinámicas. Los

valores de tiempo mostrados están redondeados a dos decimales; no se muestra la parte decimal del

valor medio para las variables enteras de tipo discreto (que en este caso representan cantidades de

memoria o número de consultas).

Máximo Mínimo Medio Desv. Típica

1 minuto 2.84 0.01 0.17 0.1512

5 minutos 1.31 0.01 0.11 0.0629

15 minutos 0.53 0.01 0.06 0.0417

Memoria 30 146 560 4 456 448 6 402 426 2 556 625.4381

Nº Consultas 559 0 6 24.730

Figura 10.16: Parámetros estadísticos generales de uso de CPU, memoria y BBDD

El valor máximo mostrado en la tabla anterior pone de manifiesto que han existido picos de carga,

pero no han tenido una duración considerable (dichos picos se dan en la carga media sostenida durante

1 y 5 minutos, pero no durante 15). La cantidad de memoria y el número de consultas medio por página

se encuentran dentro de los límites razonables, si bien los valores máximos (correspondientes a la

generación de documentación en el caso de la memoria y al listado de papers en el caso de las

consultas) tienden a dispararse.

Tiempo 55 Memoria Nº Consultas

PDFs 0.5627000000 s 25 422 449 bytes 7.6174 c.

Certificados 0.7080772727 s 26 119 074 bytes 5.8205 c.

Resto 0.3546369851 s 6 388 911 bytes 6.0728 c.

Figura 10.17: Media de tiempo y memoria empleados para generar las páginas

La tabla anterior indica que los PDFs necesitan de media 4 veces la memoria necesaria para el resto de

páginas, pero generalmente no existen diferencias perceptibles por el usuario en el tiempo de

respuesta. Se muestra de forma detallada los valores para los PDFs de certificados de asistencia para

reflejar que requieren en promedio un 25% más de tiempo y una cantidad de memoria ligeramente

superior que el resto. El número de consultas necesario para generar los PDFs no presenta diferencias

significativas respecto al resto de páginas.

55 Nótese que estos tiempos medios cumplen sobradamente los requisitos iniciales NF.4.x relativos al tiempo máximo admisible bajo condiciones normales necesario para generar las páginas.



Examinando los datos disponibles de forma detallada, se ha determinado que las páginas de usuario

(públicas) que más memoria requieren (de media) son las de envió de papers (hasta 13 MB); las que

menos, la descrga de un paper y el index (entre 6 y 7 MB), las hojas de estilo CSS y los archivos con

código Javascript (estos dos últimos casos generados únicamente a partir de una plantilla y los datos

de configuración estáticos).

Para comprobar que los valores máximos de carga media del sistema de los últimos 1, 5 y 15 minutos

corresponden a aumentos puntuales, y que las mediciones tienen sentido estadístico, se ha calculado

la covarianza existente entre ellos (por ejemplo, cuánto varía la carga media de los últimos 5 minutos

cuando aumenta la carga del último minuto). También se ha calculado la relación estadística existente

entre la carga de CPU (medida en el último minuto) y la memoria usada. Por último, para completar el

estudio, también se han calculado sus coeficientes de correlación.

Covarianza 1 minuto 5 minutos 15 minutos Memoria

1 minuto 0.022882 0.0074883 0.0026004 -3689.5779

5 minutos 0.0074883 0.0039582 0.0019058 N/D

15 minutos 0.0026004 0.0019058 0.0017394 N/D

Memoria -3689.5779 N/D N/D 6 536 333 630 753.721

Figura 10.18: Grado absoluto de relación lineal existente entre el uso de CPU y de memoria

Tal como se esperaba, los valores obtenidos reflejan una dependencia directa (positiva) entre las

mediciones de carga de CPU56. A partir de los valores mostrados puede deducirse que los aumentos

en la carga del sistema son generalmente puntuales. En el caso de la memoria, indica las grandes

diferencias existentes en los requisitos de memoria de los diferentes scripts (en particular, entre las

páginas que forman la interfaz y los scripts usados para generar la documentación).

Correlación 1 minuto 5 minutos 15 minutos Memoria

1 minuto 1.0000000 0.7868403 0.4121735 -0.0095403

5 minutos 0.7868403 1.0000000 0.7262973 N/D

15 minutos 0.4121735 0.7262973 1.0000000 N/D

Memoria -0.0095403 N/D N/D 1.0000000

Figura 10.19: Grado relativo de relación lineal existente entre el uso de CPU y de memoria

El coeficiente de correlación de Pearson calculado indica, como se esperaba, que hay una buena

correlación positiva entre los valores de carga calculados, y que esta correlación es mayor cuanto

mayor sea la proximidad entre los intervalos de tiempo que reflejan. En el caso de la memoria, indica

que, en general, las páginas tienden o bien a usar grandes cantidades de memoria o bien a usar grandes

cantidades de CPU, sin que las variaciones sean tan pronunciadas como en los otros casos.

56 Los valores de la diagonal principal equivalen, por definición, a la varianza de cada medida.



APENDICE II: Ampliaciones propuestas

El propósito de este apartado es proporcionar una pequeña lista de posibles ampliaciones y mejoras

en la aplicación desarrollada, basada en deficiencias o aspectos mejorables detectados en la misma

durante su desarrollo. En general, esta lista se centra en mejorar la estructura de la aplicación y facilitar

su mantenimiento posterior implementando prácticas de uso común en de ingenierá de software y

web, y en proporcionar ideas que sirvan de punto de partida para el desarrollo de nuevas

funcionalidades.

Uso del autocargador de clases de Symfony

Actualmente la aplicación hace uso de un autocargador de clases programado ad hoc para la misma.

Este autocargador es funcional y rápido, al tener un mapa estático de los archivos de código fuente

correspondientes a cada tipo de objeto de la aplicación (clase, trait e intefaz del sistema). Sin embargo,

el uso de esta solución lleva implícita la necesidad de actualizar el mapa de tipos del sistema cada vez

que una clase es renombrada o eliminada, o cada vez que una nueva clase es añadida. Como posible

ampliación se recomienda remplazar el autocargador usado por una implementación genérica open

source y, en concreto, se recomienda usar el autocargador de Symfony [SYMF02].

Entre las ventajas del mismo se encuentra la potencial mejora de la estructura de los nombres de

archivos y directorios de código fuente (al tener que seguir un esquema de nombrado estándar) y la

eliminación del mapa de tipos de la aplicación (y, con ella, la necesidad de actualizarlo cada vez que se

añaden o eliminan tipos al sistema). Estas ventajas compensarían los potenciales inconvenientes de

este enfoque, entre los cuales se encontraría un pequeño incremento de los tiempos de carga (que

podría subsanarse con los sistemas de caché que Symfony dispone para este propósito [SYMF03]) o la

introducción de una dependencia adicional en la aplicación (que podría ser gestionada por Composer

al igual que ocurre con el resto de librerías).

Alternativas al sistema MVC usado

La implementación actual del sistema MVC de la aplicación está basada en controladores jerárquicos

(HMVC) [CAI00], en la cual cada controlador gestiona una pequeña parte de la creación de la página a

enviar y delega el resto en otro controlador secundario. Éste, a su vez, puede generar su parte de forma

íntegra o llamando a más controladores antes de retornar una respuesta al controlador que lo invocó.

Pese a las ventajas obvias de este enfoque, durante el desarrollo ha resultado evidente que la

implementación HMVC en esta esta aplicación concreta introduce cientas complicaciones a la hora de

depurar errores o implementar nuevas funcionalidades, como son:

Dificultad para comprender el flujo seguido al procesar una solicitud, debido al gran número

de controladores involucrados en el proceso.

Introducción de dependencias entre controladores, ya que los controladores padre tienen

que encargarse de construir el código HTML de las vistas parciales a partir del código generado

por los hijos, y éstos deben de tener en cuenta la estructura del código generado en los niveles



superiores, lo cual rompe el principio de separación entre Vistas y Controladores (debido a que

éstos últimos necesitan conocer detalles sobre la jerarquía existente entre las primeras).

Además, en ciertos casos, los controladores hijos necesitan acceder a campos del padre para

actualizar atributos usados en las capas superiores para modificar partes de las vistas.

Dependencia completa de la estructura de las URLs de las páginas de la aplicación en función

de la estructura de los controladores, al construirse éstas a partir de los de nombres de los

métodos invocados.

Dificultad para retornar respuestas no HTML en los controladores inferiores como respuesta

a condiciones detectadas en éstos, como encabezados HTTP de redirección. En estos casos,

además, se requiere la finalización abrupta de la solicitud, enviado los datos directamente al

cliente y cancelando el procesamiento posterior del código de finalización de todos los

controladores superiores (usado, por ejemplo, la sentencia exit del lenguaje), lo cual resulta

una flagrante violación de los principios de Ingeniería del Software relativos a la

estructuración por capas y responsabilidad única.

Como alternativa, se recomienda que revisiones posteriores de la aplicación implementen un sistema

MVC puro [GoF94] en el que un único método de un controlador gestione toda la lógica de negocio

asociada a cada solicitud, basándose para ello en la URL completa en lugar de procesarla por partes en

distintos niveles. De esta forma, toda la lógica principal asociada a cada página o documento generado

estaría contenida en un único punto y se eliminarían las complicaciones de HMVC mencionadas

previamente. Para ello, se aconseja partir de una implementación MVC tradicional existente (como el

HttpKernel de Symfony y las clases base que este framework proporciona para controladores) a partir

de la siguiente lista de consideraciones a la hora de resolver los nuevos problemas que este nuevo

enfoque podría suponer:

Utilización de plantillas jerárquicas en lugar de incluir unas en otras a mano, a través del

mecanismo de herencia a nivel de plantillas que proporciona la librería utilizada actualmente

(Twig). De esta forma, la mayor parte de los aspectos relativos a la capa de presentación

quedarían contenidos en un único nivel, liberando a los controladores de las funciones

relativas a la construcción de HTML por partes y de la necesidad de concocer la jerarquía

existente entre las plantillas que constituyen las vistas.

Uso de mecanismos de herencia tradicionales o componentes comunes desde los

controladores (por ejemplo, utilizando sistemas de inyección de dependencias). De esta forma,

las partes que el sistema actual implementa en los controladores padre (como la

comprobación de permisos) pasarían a estar compartidas de forma sencilla, y toda URL estaría

unívocamente asociada a un único controlador mediante un sistema de mapeo de rutas. Esto

separaría la lógica de control de la estructura de URLs utilizada y permitiría que las URLs (que

pasarían a ser configurables) puedan ser referenciadas por los controladores para generar las

direcciones necesarias en los archivos HTML en lugar de estar éstas directamente incluídas en

las plantillas.

Almacenamiento del estado global de la solicitud, en caso de que fuese necesario, en un

contenedor externo a los propios controladores. El (único) controlador invocado dispondría



de una referencia a un objeto usado para acceder directamente a la información de dicho

estado global de forma uniforme.

A partir de las anteriores consideraciones se permitiría, además de solucionar los mencionados

problemas, reducir en cierta medida la cantidad de código de la aplicación (incluyendo la eliminación

del sistema MVC ad hoc utilizado actualmente) y, con ello, la complejidad de la misma.

Mejoras funcionales generales y de planificación

En este grupo podrían citarse:

Ampliaciones en las funcionalidades relacionadas con los horarios, como la posibilidad de

gestionar de forma completa los horarios de presentación de ponencias desde la propia

aplicación (incluyendo su visualización en las páginas de administración), la generación de

archivos PDF para imprimir los horarios y la exportación de los mismos a formato iCal al igual

que se hace ahora con la hora de inicio de los simposios y los horarios de exposición de los

posters. De forma complementaria, la asignación de salas a cualquier tipo de paper permitiría

gestionar de forma completa los horarios de uso de las salas durante todo el congreso.

La posibilidad de gestionar envíos a revistas científicas, permitiendo que los ponentes soliciten

la publicación de sus papers a partir de una lista de revistas gestionada desde la interfaz de

administración. Esta funcionalidad fue solicitada por los organizadores tras poner los

primeros prototipos en funcionamiento, pero se descartó por falta de tiempo. Para su

implementación podría usarse como punto de partida el código de gestión de alguna de las

entidades sencillas, como el relativo a salas o excursiones.

El envío de correos electrónicos a los ponentes de forma individual o masiva. Esta

funcionalidad, solicitada por los organizadores tras las últimas etapas del desarrollo,

simplificaría el envío de información de última hora a los asistentes (utilizando las direcciones

de correo proporcionadas durante el registro) e información relativa a la organización de la

conferencia a los administradores (utilizando las direcciones de la lista de notificaciones).

Mejoras en la gestión de documentación

En este punto se sugiere la implementación de un sistema de gestión centralizado de todos los archivos

enviados. En concreto, se incluiría una nueva entidad genérica, Envío, encargada de representar de

forma abstracta un archivo enviado, y se permitiría referirse a ella utilizando un identificador propio.

De esta forma se simplificaría la gestión de envíos, al asociarlos a una única entidad, y se permitiría

que éstos tengan varios archivos asociados a modo de versiones. Cada archivo asociado a un Envío

podría tener, además, anotaciones adicionales (como “poster” o “versión revisada”), y cada una de las

entidades actuales (papers y justificantes de pago) pasaría a tener una única referencia a un envio

genérico. El sistema de gestión conjunta sugerido se encargaría de la lógica necesaria para

proporcionar las URLs de descarga o la asignación de nombres de archivo.



Entre las ventajas potenciales de este enfoque se podrían citar:

La integración del código de envío de diferentes verisones de los papers en el gestor general

de envíos. Esto simplificaría el código y reduciría la posibilidad de introducir errores al

modificar los diferentes módulos de la aplicación. En caso de que éstos se produzcan, se

simplificaría su depuración.

La posibilidad de mantener en el sistema todas las versiones de los justificantes de pago y

papers, de forma que puedan ser recuperados si fuese necesario en caso de errores por parte

de los usuarios.

La posibilidad de auditar desde qué sesiones e IPs se han realizado los envíos y la hora de éstos

de una forma sencilla. Para ello bastaría con incluir en el Envío una referencia a la muestra de

la tabla de instrumentación asociada a la solicitud HTTP desde la que se originó.

El uso de borrados virtuales (soft deletes), de forma que los archivos antiguos se marcan como

borrados pero no llegan a ser eliminados de forma física del sistema.

Mejoras técnicas generales

La principal mejora técnica recomendada consiste en la migración de todas las consultas SQL

realizadas por la aplicación directamente sobre la base de datos para que sean realizadas a través del

ORM (Doctrine). Esto está considerado como uno de los cambios técnicos más prioritarios, pues

eliminaría el actual sistema dual de acceso a la base de datos (reduciendo la complejidad de los

modelos) y permitiría la implementación de un sistema de caché de datos de forma trivial utilizando

los mecanismos que Doctrine proporciona para ello. Este sistema podría almacenar los datos utilizando

una caché por proceso (como APC) o una caché distribuída (como Memcached).

Por otra parte, se recomienda considerar el uso de solicitures AJAX para un mayor número de casos

de uso, realizando las solicitudes y el análisis sintáctico de las respuestas utilizando las funciones que

jQuery proporciona para ello, y generando el código JSON a enviar a través de las funciones

proporcionadas de forma nativa por PHP. Entre las funcionalidades administrativas que podrían utilizar

este tipo de solicitudes se incluye la apertura y cierre del plazo de envío de papers y el acceso público,

la creación y borrado de entidades (salas, excursiones,..) o la asignación automática de números de

factura.

Además, se recomienda considerar la adaptación del código de la aplicación para que haga uso de las

nuevas funcionalidades de PHP 7 una vez que la nueva versión del lenguaje sea publicada de forma

estable. Entre estas características a considerar se incluye el type hinting de los tipos de dato de los

parámetros escalares de las funciones (por ejemplo, para indicar el tipo de dato admitido (string,

entero…) en cada parámetro de las URLs) y los tipos de retorno (lo cual ayudaría en la depuracíon de

la aplicación y minimizaría los posibles errores). Además, se espera que la nueva versión incluya

mejoras de rendimiento en los casos en los que se indique los tipos de los parámetros y variables, al

permitir que el lenguaje realice optimizaciones de forma automática y transparente para el

programador. En caso de seguir estas recomendaciones para los parámetros de los controladores,

también permitiría marcar los parámetros como obligatorios u opcionales en la propia firma de los



métodos de los controladores. En cualquier caso, y en caso hacer uso de una implementación MVC

alternativa a la actual, habría que tener en cuenta si ésta soporta las nuevas características

mencionadas.

Por último, sería recomendable realizar una normalización de la estructura de la base de datos

utilizada por la aplicación. La estructura actual está fuertemente influenciada por la utilizada en

versiones previas (con las que comparte la mayor parte de puntos débiles) y no cumple los estándares

de normalización más elementales (en concreto, los dictados por la Primera Forma Normal definida

por Edgar Codd en 1971 y aceptada universalmente).

Para esta tarea se recomienda utilizar el estudio de normalización incluído al final del apartado “Diseño

físico de datos” como punto de partida. No obstante, en caso de llevar a cabo la normalización, se

deberá tener en cuenta las complicaciones adicionales en la mantenibilidad provocadas por la

previsible necesidad de doblar el número actual de tablas de la base de datos y entidades débiles

asociadas a éstas. Una opción intermedia consistiría en realizar una normalización selectiva de las

partes más problemáticas (como las que afectan a datos duplicados) en lugar de realizar una

normalización completa.

Mejoras en estadísticas, instrumentación y

administración de la aplicación

En este grupo se recomienda añadir un nuevo módulo en las páginas de administración para mostrar

los datos de instrumentación recogidos en tiempo real y la utilización de estos, junto a los datos

disponibles de ediciones anteriores, para mostrar estadísticas y gráficas de evolución de la edición

actual, como el número de papers enviados y ponentes registrados actualmente y en función de los

días transcurridos desde el inicio del plazo de envío. Igualmente, estos datos podrían mostarse de

forma comparativa respecto a los datos disponibles de otras ediciones.

Las gráficas mostradas podrían ser similares a las disponibles en el Apéndice I de este documento, e

incluso podrían implementarse a partir del código PHP utilizado para generarlas (este código está

disponible en el CD-ROM incluído en la memoria).

También se ha considerado la inclusión de opciones de diagnóstico en la interfaz de administración,

como la comprobación de que los archivos de papers y justificantes son consistentes con los datos

guardados en la BBDD (ayudando en la depuración en caso de que se produzcan errores en el sistema

de archivos del servidor y en la detección de errores en la aplicación).

Por último, para simplificar la recuperación de datos en caso de que se produzcan errores graves,

también se ha considerado la posibilidad de realizar backups desde la propia interfaz de

administración. Dado el volumen relativamente bajo de datos a gestionar, sería admisible generar los

archivos de copia de seguridad directamente desde las páginas de administración. En otro caso, las

copias de seguridad podrían gestionarse mediante un shell script independiente, que permitiría

realizar las copias de seguridad de manera periódica (utilizando cron) y enviarlas automáticamente a

un servidor remoto.



Cambios considerados en el sistema de pagos

Inicialmente se consideró permitir realizar el pago de la cuota de inscripción a través de un sistema de

pagos online. En concreto se consideró el uso de PayPal como proveedor de pagos por ser la opción

más extendida. Las potenciales ventajas de su uso incluyen:

La posibilidad de integrar el pago de la cuota de inscripción a través de Internet, al igual que

el resto del proceso de inscripción, agilizando el proceso.

La verificiacón automática y en el momento de los pagos realizados, utilizando la API que

PayPal dispone para ello [PAYP01], pudiendo así evitar tener que realizar la comprobación

manualmente (al menos en algunos casos). En cualquier caso, probablemente esto no sea de

utilidad para aquellos usuarios que soliciten factura (puesto que estos requieren la asignación

de números de factura; además, normalmente estos pagos deben realizarse por instituciones

externas, como Universidades, y empresas privadas, y ser registrados en sus sistemas de

contabilidad tradicionales). Si así fuera, podría aplicarse, al menos, para agilizar los pagos de

los usuarios que solo requieran un justificante simple (que representan el 61% de los usuarios

registrados en la edición de 2014).

La existencia de opciones de pago utilizando tarjetas de crédito y débito, para poder

beneficierse de las ventajas anteriormente citadas en los casos en los que el usuario no

disponga de cuenta de PayPal.

Finalmente se decidió mantener el sistema de pagos tradicional y su verificación manual para la edición

de 2014. En cualquier caso, se incluyen estas notas aquí a modo de propuesta en caso de que la

organización considere cambiar el sistema de pagos en un futuro.

Por otra parte, la aplicación dispone de una implementación parcial de un sistema de patrocinadores

(deonimado “RED”), de forma que la cuota de inscripción puede ser pagada total o parcialmente por

una empresa para parte de los ponentes. Las ediciones recientes no han hecho uso de este sistema y,

por tanto, su implementación ha sido portada desde la aplicación original únicamente de manera

básica. En concreto, la estructura de la base de datos dispone de campos para la información de los

patrocinadores, los modelos de configuración y facturación disponen de métodos para establecer los

datos del patrocinador y asignar usuarios al mismo, y las facturas se generan descontando la parte de

la cuota cubierta por el patrocinador (cero en 2014). Sin embargo, para utilizar este sistema en

ediciones posteriores será necesario definir e implementar los cambios necesarios en la interfaz de

usuario para permitir la configuración del sistema de patrocinadores y la asignación de usuarios al

patroinador.



Mejoras de seguridad

Actualmente la aplicación utiliza el algoritmo de reducción criptográfica MD5 como alternativa al

almacenamiento de las contraseñas en texto claro. Sin embargo, se sabe que este algoritmo presenta

problemas de seguridad desde que se encontraron casos de colisión de hash en el mismo [IACR01]

[PHP05].

Como alternativa, se aconseja el uso de un sistema estándar de encriptación de contraseñas más

robusto, como las funciones de generación de contraseñas password_hash() y password_verify()

introducidas en PHP5.6 y que incluyen funcionalidades para rehashear las contraseñas almacenadas,

adaptando los valores almacenados cuando se detectan vulnerabilidades en las implementaciones

utilizadas para generar los valores almacenados previamente en la base de datos.

Otros cambios a considerar

La interfaz de administración contiene partes en español y partes en inglés, herencia de las versiones

iniciales de la misma. Se recomienda comprobar en qué casos ocurre esto y modificarlos

convenientemente en uno u otro sentido para que sean consistentes entre si.

Por otra parte, la aplicación contempla un rol de editor, pensado para permitir a miembros de

publicaciones científicas (como revistas) la descarga de los papers enviados con el propósito de que

publiquen aquellos que consideren interesantes. Sin embargo, esta funcionalidad podría ampliarse

para que puedan seleccionar los papers que les interesen desde la propia interfaz web, utilizando la

aplicación del CMMSE como mediadora en el proceso de adquisición de los papers a pubicar (que

podría incluir, si se desea, el pago por parte del autor del paper al editor para su publicación o

viceversa). Como alternativa, la aplicación podría servir simplemente para facilitar la puesta en

contacto entre ambas partes, proporcionando la dirección de correo 57 del ponente al editor e

informando al ponente de que un editor está interesado en su paper.

Además, la aplicación debería permitir añadir editores desde la propia interfaz web en lugar de

requerir la realización de consultas de forma manual sobre la base de datos.

57 Se debe tener en cuenta que permitir el acceso a datos de usuario y papers enviados a un tercero (el editor) probablemente requiera actualizar o añadir propósitos y/o partes involucradas en la nota relativa a la LOPD mostrada en el formulario de registro.



APENDICE III: Contenido del CD-ROM

En este apartado se detalla el contenido del CD-ROM que acompaña a la documentación impresa,

describiendo cada uno de los directorios presentes en el directorio raíz del mismo.

cmmse-plots-2014

Código fuente de los scripts utilizados para generar las gráficas del apartado de estadísticas.

cobertura-tests

Informes generados por PHPUnit sobre las partes del código fuente de la aplicación cubiertas

por los tests unitarios en formato HTML. El índice de los mismos es accesible a través del archivo

index.html.

documentacion

Archivos digitales con una copia de este documento y archivos asociados (imágenes, esquemas

UML…).

También se incluye una versión más extensa del apartado de introducción a Tecnologías y

protocolos extraída de los primeros borradores de la memoria, una hoja de cálculo en formato

OpenDocument con la correspondencia entre los escenartios de los casos de uso y los apartados

de los manuales, y una copia de la Guía de uso de cookies de la Agencia Española de Protección

de Datos.

instalador

Shell script de instalación de la aplicación junto a los archivos asociados al mismo.

phpdoc

Documentación autogenerada a partir del código fuente de la aplicación y los comentarios

incluídos en el mismo.

webcmmse-src

Código fuente de la aplicación obtenido a partir del repositorio utilizado durante el desarrollo.



APENDICE IV: Definiciones y abreviaturas

A continuación se incluye una lista de definiciones a modo de referencia rápida para facilitar la lectura

del resto del documento.

AJAX (Asynchronous Javascript And XML)

Se denomina Javascript asíncrono y XML al conjunto de tecnologías que permiten el desarrollo

de aplicaciones web en las que una parte de las mismas se ejecuta en el navegador del cliente,

frente al modelo tradicional en el que las acciones del usuario implican la solicitud de una nueva

página al servidor y la recarga completa de la interfaz de usuario.

Android

Sistema operativo open source basado en Linux y diseñado, principalmente, para dispositivos

móviles y tabletas.

CGI (Common Gateway Interface)

En el contexto asociado a las aplicaciones web, el protocoloo de Interfaz de Entrada Común es

utilizado para la comunicación entre un servidor web y un proceso independiente encargado de

generar las páginas web enviadas al usuario, permitiendo la implementación de aplicaciones

web en cualquier lenguaje de programación.

Cliente (redes)

En informática, se denomina cliente a aquel elemento (hardware o software) o persona física

que accede a los servicios proporcionados por un sistema servidor. En el contexto de esta

aplicación, se denomina cliente tanto al equipo hardware y al navegador utilizado como al

propio usuario final que utiliza la aplicación.

Controlador

Objeto software encargado de atender las solicitudes del cliente, convirtiéndolas en solicitudes

a los modelos y/o a otros controladores, generando la respuesta a mostrar al usuario por medio

de una o varias vistas.

Cookie

En informática, se denomina cookie a una pequeña información enviada desde el servidor web

al cliente como parte de las respuestas a las solicitudes efectuadas, y que éste reenvía en las

siguientes, permitiendo al servidor conocer la actividad previa del usuario. Entre sus funciones

se encuentran el control de usuarios identificados en aplicaciones web o la obtención de los

hábitos de navegación de éstos con fines publicitarios.

Decorador

En ingeniería de software, se denomina decorador, envoltorio, o wrapper a aquel objeto que

posibilita modificar la interfaz externa de otros objetos, añadiendo a éstos funcionalidades o

representaciones adicionales de sus datos sin influir en su comportamiento y sin modificar su

implementación.



DNS (Domain Naming System)

El Sistema de Nombres de Dominio es un sistema global, jerárquico y distribuido utilizado para

traducir nombres de host (por ejemplo, www.uniovi.es) a direcciones IP.

DOM (Document Object Model)

El Modelo de Objetos de Documento es una interfaz estándar de programación que posibilita la

representación de documentos HTML y XML, así como su modificación dinámica utilizando

Javascript.

Drag & drop

En informática, se denomina drag & drop (arrastrar y soltar) a la acción de mover con el ratón

objetos entre ventanas o partes de éstas. Habitualmente los objetos arrastrados son archivos

(por ejemplo, para copiarlos, moverlos o abrirlos con un programa), pero también pueden ser

otro tipo de elementos en función de la aplicación utilizada.

Entidad

En ingeniería de software, una entidad es una abstracción de alto nivel que permite separar el

significado conceptual de un objeto de dominio de la aplicación de la representación física y el

acceso real a los datos almacenados.

GPL (General Public License)

La Licencia Pública General es una licencia (aplicada comúnmente a elementos software) que

garantiza a los usuarios finales la libertad de usar, estudiar, compartir y modificar los elementos

sujetos a ella.

HTTP (HyperText Transfer Protocol)

El Protocolo de Transferencia de Hipertexto es un protocolo de aplicación utilizado para el

intercambio de datos (como páginas web o imágenes) a través de redes informáticas. Este

protocolo es utilizado como la base sobre la que se construye la World Wide Web.

IDE (Integrated Development Environment)

Un Entorno de Desarrollo Integrado es un programa informático compuesto por un conjunto de

herramientas que facilitan el desarrollo de software.

Interfaz (programación)

En ingeniería de software, una interfaz es un conjunto de características que debe cumplir una

clase para ser apta para una necesidad concreta. En particular, las interfaces permiten separar

la forma de utilizar un componente software de su implementación particular.

IP (Internet Protocol address)

Una dirección IP es una etiqueta numérica que identifica de manera lógica, jerárquica y unívoca

a un dispositivo (habitualmente una computadora) dentro de una red informática. Además, “IP”

es comúnmente utilizado para referirse al protocolo de red basado en direcciones de este tipo.

Linux

Sistema operativo open source de amplio uso en redes informáticas y dispositivos móviles.



Logger

Objeto encargado de recolectar mensajes generados por otros objetos para el posterior análisis

y depuración de una aplicación y la detección de posibles problemas y sus causas a posteriori.

Main-in-the-Middle

En criptografía, los ataques de intermediario son aquellos en los que el atacante adquiere la

capacidad de leer y modificar los mensajes intercambiados entre dos partes legítimas sin que

éstas conozcan el hecho de que la comunicación ha sido comprometida.

Modelo

En ingeniería de software, un modelo representa y gestiona la información sobre la cual opera

un sistema, proporcionando mecanismos de alto nivel para su uso y modificación.

MVC (Model-View-Controller)

Patrón de arquitectura de software que separa la lógica de negocio, los datos y la representación

de éstos mediante abstracciones bien definidas, facilitando el desarrollo de aplicaciones y su

posterior mantenimiento.

MySQLi (MySQL Improved)

Extensión de PHP para la comunicación con servidores MySQL que proporciona una interfaz de

programación orientada a objetos y el acceso a funcionalidades modernas como el soporte para

consultas preparadas, transacciones, múltiples juegos de caracteres o procedimientos

almacenados. Se trata de la opción recomendada para nuevos proyectos.

Open Source

Expresión utilizada para referirse a programas y librerías informáticas cuyo código fuente es

desarrollado y distribuido libremente.

ORM (Object Relational Mapper)

El mapeo objeto-relacional es una técnica de programación para la conversión y uso

transparente de datos de un sistema de almacenamiento tradicional (archivos, bases de datos,

etc) como entidades, creando, en la práctica, una base de datos virtual orientada a objetos sobre

una base de datos relacional.

Proceso

En informática, se denomina proceso a una instancia de un programa durante su ejecución,

incluyendo la información y recursos necesarios para ello (como las instrucciones del mismo, el

estado del procesador o la memoria necesaria para almacenar sus datos).

Plantilla (template)

Los archivos de plantilla definen cómo presentar los datos de una aplicación a partir de

documentos de texto genéricos, posibilitando el desarrollo y la modificación de la interfaz de

usuario de manera independiente del resto de la aplicación.



Proxy (programación)

En ingeniería de software, un proxy es una clase utilizada para proporcionar una interfaz

alternativa de otro objeto. En la aplicación desarrollada, los proxys son objetos generados de

manera automática a partir de las entidades y posibilitan posponer el acceso a la base de datos

para mejorar el rendimiento.

Proxy (redes)

En una red informática, un servidor proxy es un sistema físico o aplicación que actúa como

intermediario entre el cliente y el servidor final, encaminando las solicitudes y las respuestas

entre éstos. Es usado para el control y auditoría de los contenidos solicitados por los usuarios

de una red, el ahorro ancho de banda al proporcionar el acceso a redes externas (como Internet)

o el acceso a redes de forma anónima.

Servidor

Sistema físico y/o software que responde a solicitudes realizadas a través de una red

informática, proporcionando servicios como el acceso a bases de datos, páginas web o correo

electrónico.

Test Unitario

Programa breve utilizado para comprobar el correcto funcionamiento de elementos aislados de

una aplicación, permitiendo la automatización de las pruebas realizadas y la rápida detección de

errores surgidos durante el desarrollo.

Trait

Los traits (o rasgos) proporcionan un mecanismo de reutilización de código horizontal en

lenguajes de programación orientados a objetos de herencia simple, permitiendo heredar la

implemetación de métodos adicionales sin modificar la jerarquía tradicional respecto a otras

clases.

Túnel TCP/IP

En informática, se denomina túnel a la utilización de un protocolo de red para encapsular otro,

por ejemplo, para acceder a los servicios de una máquina a través una conexión segura con una

tercera (evitando que el sistema de destino conozca la IP de origen real), para conectar a redes

IPv6 desde redes IPv4 o para acceder a servicios no permitidos desde la red del usuario utilizando

otros que sí lo están (como FTP sobre HTTP).

URL (Uniform Resource Locator)

Un Localizador de Recurso Uniforme, conocido informalmente como dirección web, es un tipo

de URI que contiene una referencia completa a un recurso, incluyendo el protocolo, el nombre

del host o IP donde está alojado y (opcionalmente) el usuario y la contraseña necesarios para

acceder a él.

URI (Uniform Resource Identifier)

Un Identificador de Recurso Uniforme es un tipo de identificador asociado a los recursos de una

red de forma unívoca. Se trata de una extensión de las URLs añadiendo a éstas la posibilidad de

incluir elementos adicionales como parámetros de formularios o referencias a secciones

concretas del documento apuntado (fragmentos).



Vista

En ingeniería de software, las vistas proporcionan al usuario la representación de los datos

proporcionados por los modelos de la aplicación en un formato adecuado, como una página

web, un archivo PDF o una hoja de cálculo.

WebSocket

Protocolo de comunicación bidireccional entre un cliente y un servidor HTTP, permitiendo a este

último el envío de información en cualquier momento (en lugar de poder hacerlo únicamente

como respuesta a una solicitud). Las comunicaciones WebSocket se realizan a través de los

puertos estándar de HTTP y HTTPS, utilizando una conexión creada por el cliente que el servidor

no cierra, y permiten notificaciones y actualizaciones de estado en tiempo real a solicitud del

servidor.

WWW (World Wide Web)

Sistema de documentos vinculados a través de enlaces de hipertexto construido sobre HTTP y

HTML que permite el acceso a páginas web que contienen texto, imágenes, video y otros datos

multimedia, y la navegación entre ellas.

Technology

Plataforma Web para la Gesión Integral de Conferencias Científico-Técnicas