Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos

UNIVERSIDAD POLITÉCNICA DE VALENCIA ESCUELA TÉCNICA SUPERIOR DE INFORMÁTICA APLICADA Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos PROYECTO FIN DE CARRERA Autor: Solá Gómez, Diego Directores: Pastor López, Óscar Giachetti Herrera, Giovanni Marín Campusano, Beatriz 13 de Julio de 2010 Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 1 Contenido 1. INTRODUCCIÓN ....................................................................................................................... 15 1.1 Motivación ........................................................................................................................ 15 1.2. Problema .......................................................................................................................... 16 1.3. Objetivos .......................................................................................................................... 17 1.4. Estructura del documento ............................................................................................... 18 2. HERRAMIENTAS DE RECURSOS HUMANOS EN LA ADMINISTRACIÓN PÚBLICA ..................... 20 2.1. El modelo Excarpsus ......................................................................................................... 23 2.1. 1. Valoración de puntos por factor .............................................................................. 24 3. CONTEXTO TECNOLÓGICO ...................................................................................................... 27 3.1. MDD ................................................................................................................................. 27 3.2. OO-Method ...................................................................................................................... 29 3.3 El modelado conceptual con Olivanova ............................................................................ 31 3.3.1 El modelo de objetos .................................................................................................. 31 3.3.2 El Modelo Dinámico ................................................................................................... 33 3.3.3 El Modelo Funcional ................................................................................................... 34 3.3.4 El Modelo de Presentación ........................................................................................ 34 4. ESPACIO DEL PROBLEMA ......................................................................................................... 38 4.1. Resumen de las aplicaciones ............................................................................................ 38 4.1.1 SIESMACRe ................................................................................................................. 38 4.1.2 SIEFAP ......................................................................................................................... 40 4.2. Especificación de Requisitos ............................................................................................. 42 4.2.1. Diagrama de Casos de Uso ........................................................................................ 42 4.2.2. Casos de Uso SIESMACRe .......................................................................................... 44 Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 2 4.2.3 Casos de Uso SIEFAP................................................................................................... 63 4.3. Mapeo Casos de Uso – Modelo ................................................................................... 99 4.3.1 Mapeo de SIESMACRe .............................................................................................. 101 4.3.1 Mapeo de SIEFAP ..................................................................................................... 110 5. ESPACIO DE LA SOLUCIÓN ..................................................................................................... 146 5.1. Transformación de PIM a PSM en OO-Method ............................................................. 146 5.2 Obtención de código con el sistema Olivanova STAR ..................................................... 150 5.3. Preparación de Base de datos ........................................................................................ 154 5.4. Compilación del código y puesta en marcha ................................................................. 156 5.5. El modelo de Implementación ....................................................................................... 160 6. CONCLUSIONES ..................................................................................................................... 190 6.1 OO-Method y Olivanova.................................................................................................. 190 6.2 Situaciones detectadas y posibles mejoras ..................................................................... 191 6.3 Cumplimiento de objetivos y ampliaciones del PFC ....................................................... 194 Anexo I. Inventario del mapeo entre casos de uso y elementos conceptuales. ....................... 199 Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 3 Índice de Figuras Figura 1. Ficha de valoración por puntos de Requisitos Intelectuales. ................................. 26 Figura 2. Esquema de desarrollo MDA .................................................................................. 28 Figura 3. Proceso de Desarrollo de Software utilizando OO-Method. .................................. 30 Figura 4. Ejemplo del Diagrama de clases ............................................................................. 32 Figura 5. Ejemplo del Diagrama de Transición de Estados .................................................... 33 Figura 6. Niveles y elementos del modelo de presentación [22]. ......................................... 35 Figura 7. Diagrama de casos de uso de SIESMACRe – Vista General. ................................... 44 Figura 8. Diagrama de casos de uso para la gestión de categoría. ........................................ 45 Figura 9. Diagrama de casos de uso para la gestión de complemento de destino. .............. 47 Figura 10. Diagrama de casos de uso para la gestión de puesto de trabajo. .......................... 50 Figura 11. Diagrama de casos de uso para la gestión de Comunidad Autónoma. .................. 54 Figura 12. Diagrama de casos de uso para la gestión de número de habitantes. ................... 56 Figura 13. Diagrama de casos de uso para la gestión de plantilla de trabajadores. ............... 59 Figura 14. Diagrama de casos de uso para obtener resultados. ............................................. 61 Figura 15. Diagrama general de casos de uso de SIEFAP. ....................................................... 64 Figura 16. Diagrama de casos de uso para la gestión de empleados. ..................................... 65 Figura 17. Diagrama de casos de uso para la gestión de usuarios. ......................................... 69 Figura 18. Diagrama de casos de uso para la gestión de departamentos. .............................. 71 Figura 19. Diagrama de casos de uso para la gestión de Administraciones. ........................... 73 Figura 20. Diagrama de casos de uso para la gestión de conocimientos. ............................... 76 Figura 21. Diagrama de casos de uso para la gestión de preguntas. ...................................... 78 Figura 22. Diagrama de casos de uso para la gestión de preguntas. ...................................... 82 Figura 23. Diagrama de casos de uso para la gestión de evaluaciones. .................................. 86 Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 4 Figura 24. Diagrama de casos de uso para la gestión de evaluaciones. .................................. 90 Figura 25. Diagrama de casos de uso para realizar evaluación. .............................................. 93 Figura 26. Diagrama de casos de uso para validación de cuestionarios. ................................ 98 Figura 27. Esquema de mapeo SIESMACRe. .......................................................................... 100 Figura 28. Esquema de mapeo SIEFAP. ................................................................................. 100 Figura 29. Modelo de objetos de SIESMACRe. ...................................................................... 101 Figura 30. Modelo de objetos de SIEFAP. .............................................................................. 111 Figura 31. Clases del modelo de objetos de SIEFAP. ............................................................. 112 Figura 32. Modelo de objetos para la Gestión de Empleados. .............................................. 113 Figura 33. Modelo de objetos para la Gestión de Usuarios. ................................................. 116 Figura 34. Modelo de objetos para la Gestión de Departementos. ...................................... 118 Figura 35. Modelo de objetos para la Gestión de Conocimientos. ....................................... 120 Figura 36. Relación de asociación de Subconocimientos. ..................................................... 121 Figura 37. Modelo de objetos para la Gestión de Preguntas. ............................................... 123 Figura 38. Modelo de objetos para la Gestión de Plantillas de Cuestionario. ...................... 126 Figura 39. Modelo de objetos para la Gestión de Evaluaciones. .......................................... 129 Figura 40. Derivación del atributo NivelObtenido de la clase Valoracion_Conocimiento. ... 134 Figura 41. Derivación del atributo PuntacionObtenida de la clase Valoracion_Conocimiento. .............................................................................................................................. 135 Figura 42. Modelo de objetos para la Gestión de Cuestionarios. ......................................... 136 Figura 43. Modelo de objetos para la Realización de la Evaluación. ..................................... 140 Figura 44. Definición de la MDIU Pregunta_PlantillaPIU. ..................................................... 143 Figura 45. Esquema de la arquitectura de tres capas [33] .................................................... 148 Figura 46. Esquema OLIVANOVA Transformation Engine [34]. ............................................. 150 Figura 47. Propiedades generales del Sistema Star............................................................... 151 Figura 48. Perfiles disponibles en Olivanova STAR Client. ..................................................... 152 Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 5 Figura 49. Opciones de transformación de C# .NET 2.0. ....................................................... 153 Figura 50. Opciones de transformación de Desktop C# .NET 2.0. ......................................... 153 Figura 51. Contendido del paquete de C# .NET 2.0. .............................................................. 154 Figura 52. Ejecución de script de creación de tablas ............................................................. 155 Figura 53. Administrador de orígenes ODBC con vptDB. ...................................................... 156 Figura 54. Dependencias del proyecto. ................................................................................. 157 Figura 55. Dependencias del proyecto. ................................................................................. 158 Figura 56. Solución VPT. ........................................................................................................ 158 Figura 57. Configuración de la compilación para plataforma .Net. ....................................... 159 Figura 58. Explorador de componentes COM+ con “VPTrabajoSrv”. .................................... 159 Figura 59. Ventana de identificación de la aplicación. .......................................................... 160 Figura 60. Árbol de Jerarquía de Acciones (HAT). ................................................................. 161 Figura 61. Menú inicial para el agente AdministradorSalarios.............................................. 161 Figura 62. Menú inicial para el agente AdministradorValoracion. ........................................ 161 Figura 63. Argumentos de entrada del servicio create_instance de la clase Empleado. ...... 163 Figura 64. Entrada del servicio de creación de empleado. .................................................... 163 Figura 65. Salida del servicio de creación de empleado. ....................................................... 164 Figura 66. Argumento de salida del servicio create_instance de la clase Empleado. ........... 164 Figura 67. Display Set Empleado............................................................................................ 165 Figura 68. Action Pattern Empleado. ..................................................................................... 165 Figura 69. Navigational Pattern Empleado. .......................................................................... 166 Figura 70. IIU Empleado. ....................................................................................................... 166 Figura 71. IIU Departamento. ................................................................................................ 167 Figura 72. PIU Empleado. ...................................................................................................... 168 Figura 73. Definición de PIU Empleado en el esquema conceptual. ..................................... 168 Figura 74. Definición del Filtro Nombre de la clase Empleado en el esquema conceptual. .. 169 Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 6 Figura 75. Definición de OC EmpleadoFNacAsc de la clase Empleado en el esquema conceptual. ........................................................................................................... 169 Figura 76. Atributo de entrada i_rid_Respuesta3 del servicio CREA_PREGUNTA con posible valor nulo. ............................................................................................................. 170 Figura 77. Event-Condition-Action de SIU CREA_PREGUNTA. ............................................... 171 Figura 78. Entrada de SIU CREA_PREGUNTA. ........................................................................ 171 Figura 79. Especificación de la navegación condicional de la SIU CREA_PREGUNTA. ........... 172 Figura 80. Representación de la Conditional Navigation de la SIU CREA_PREGUNTA. ......... 173 Figura 81. Entrada al servicio de creación de respuesta. ...................................................... 173 Figura 82. Especificación de MDIU Pregunta. ....................................................................... 174 Figura 83. Representación de la MDIU Pregunta. ................................................................. 174 Figura 84. Entrada del servicio de creación de una evaluación. ........................................... 175 Figura 85. Salida del servicio de creación de una evaluación................................................ 175 Figura 86. Visibilidad de PIU Conocimientos para ResponsableAdministracion. ................... 176 Figura 87. Visibilidad de PIU Conocimientos para AdministradorValoracion. ....................... 176 Figura 88. Definición de la visibilidad del agente ResponsableAdministracion sobre la clase Conocimiento. ....................................................................................................... 177 Figura 89. Entrada de servicio de creación de evaluación de conocimiento. ....................... 177 Figura 90. Salida de servicio de creación de evaluación de conocimiento. .......................... 178 Figura 91. MDIU Valoracion. ................................................................................................. 178 Figura 92. Derivación del atributo PuntosConocimiento de la clase Valoracion_Conocimiento. .............................................................................................................................. 179 Figura 93. Restricción incumplida al ejecutar servicio de edición de evaluación de conocimiento. ....................................................................................................... 179 Esta restricción está especificada en el esquema conceptual en la clase Valoracion_Conocimiento, como se observa en la Figura 94. .............................. 180 Figura 94. Restricción definida en la clase Valoracion_Conocimiento. ................................. 180 Figura 95. Entrada de servicio de creación de cuestionario. ................................................. 181 Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 7 Figura 96. IIU Cuestionario. ................................................................................................... 181 Figura 97. PIU Cuestionario para el empleado 12345678A. .................................................. 182 Figura 98. MDIU Plantilla_cuestionarioAcc. .......................................................................... 183 Figura 99. Entrada del servicio responder. ............................................................................ 183 Figura 100. MDIU Plantilla_cuestionarioAcc con respuesta seleccionada. ............................. 184 Figura 101. Modelado funcional del servicio validar_cuestionario. ........................................ 184 Figura 102. Ejecución de servicio de validación de cuestionario. ........................................... 185 Figura 103. MDIU Valoracion. ................................................................................................. 186 Figura 104. MDIU Valoracion_ConocimientoCo. ..................................................................... 186 Figura 105. IIU Cuestionario. ................................................................................................... 187 Figura 106. Precondiciones para el servicio terminar_cuestionario de la clase Cuestionario. 188 Figura 107. Precondición incumplida para SIU terminar_cuestionario. .................................. 188 Figura 108. Defecto de modelado en evaluación de atributos por situación ......................... 192 Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 8 Índice de Tablas Tabla 1. Resultado de la Encuesta de Estructura salarial del INE de 2006 del salario medio por estudios, organizado por sexos y nacionalidad. ............................................... 21 Tabla 2. Caso de uso Alta de Categoría ................................................................................ 45 Tabla 3. Caso de uso Baja de Categoría ................................................................................ 46 Tabla 4. Caso de uso Modificación de salario de Categoría ................................................. 46 Tabla 5. Caso de uso Actualización de salario de Categoría................................................. 46 Tabla 6. Caso de uso consulta de salario de Categoría ........................................................ 47 Tabla 7. Caso de uso Alta de Complemento de Destino ...................................................... 48 Tabla 8. Caso de uso Baja de Complemento de Destino ...................................................... 48 Tabla 9. Caso de uso Modificación de valor económico ...................................................... 48 Tabla 10. Caso de uso Actualización de valor económico ...................................................... 49 Tabla 11. Caso de uso Consulta de valor económico ............................................................. 49 Tabla 12. Caso de uso Alta de Puesto de Trabajo .................................................................. 50 Tabla 13. Caso de uso Baja de puesto de Trabajo .................................................................. 51 Tabla 14. Caso de uso Modificación de nombre de Puesto de Trabajo ................................. 51 Tabla 15. Caso de uso Modificación de la media del salario del Puesto de Trabajo .............. 51 Tabla 16. Caso de uso Modificación de los percentiles del salario del Puesto de Trabajo .... 52 Tabla 17. Caso de uso Actualización de la media del salario ................................................. 52 Tabla 18. Caso de uso Actualización de los percentiles del salario ........................................ 53 Tabla 19. Caso de uso Consulta de la media del salario ......................................................... 53 Tabla 20. Caso de uso Consulta de los percentiles del salario ............................................... 53 Tabla 21. Caso de uso Alta de Comunidad Autónoma ........................................................... 54 Tabla 22. Caso de uso Baja de Comunidad Autónoma .......................................................... 55 Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 15 1. INTRODUCCIÓN En la sociedad actual, donde la información y el conocimiento han adquirido roles fundamentales para desempeñar prácticamente cualquier actividad generadora de valor, la correcta gestión de los recursos humanos toma cada vez más importancia por sobre otros recursos físicos e intangibles. En particular, en la Administración Pública, donde los recursos humanos se tranforman en una interfaz directa hacia los contribuyentes y constituyen la cara visible de las instituciones públicas, contar con una buena gestión de estos recursos para asegurar su buen desempeño y satisfacción por parte de los ciudadanos se torna funamental. Por este motivo, en este Proyecto Final de Carrera se intenta proveer una solución innovadora para la adecuada gestión de los recursos humanos asociado a la Administración Pública. En esta solución se han integrado las últimas técnicas para el desarrollo de sistemas de información siguiendo una filosofía de desarrollo de software dirigido por modelos. A continuación se presenta en más detalle la motivación de este trabajo, se enmarcan los problemas detectados en el contexto de la gestión de recursos humanos en instituciones públicas, y se presentan los objetivos del trabajo asociado a este proyecto. Finalmente, se presenta la esctructura general de este documento. 1.1 Motivación En los Estados europeos del bienestar [1], los ciudadanos tienen unos derechos básicos garantizados. Los Estados son los encargados de velar por que los derechos se cumplan, bien supervisando que las necesidades queden satisfechas por el mercado, o bien proporcionando directamente los servicios que el mercado no llegue a cubrir. El Estado español, a través de las distintas Administraciones Públicas, proporciona algunos de estos servicios básicos. Los recursos económicos para que las Administraciones Públicas puedan cumplir con su papel provienen del dinero de los ciudadanos; destinando la mayor parte de éstos a gastos de personal o Recursos Humanos. La Administración Pública, al igual que las organizaciones privadas, se enfrenta al desafío de asignar las retribuciones de los empleados de forma que satisfagan la equidad externa y el equilibrio interno. Se entiende por equidad externa la similitud entre los mismos cargos de organizaciones diferentes que actúan en el mercado; y por equilibrio interno la comparativa salarial entre los distintos cargos de la misma organización [2]. El concepto de la remuneración salarial se ha abordado, con mayor o menor éxito, para el mercado de trabajo de la actividad privada; existe gran cantidad de consultoras de recursos humanos, como por ejemplo ICSA [¡Error! No se encuentra el origen de la referencia.] o Deloitte [¡Error! No se encuentra el origen de la referencia.], que ofrecen asesoramiento y Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 16 cuentan con estudios y herramientas sobre este tema, como encuestas salariales, referencias salariales, etc. Por contra, para en el ámbito público no se dispone de estas herramientas. Por este motivo, contar con una herramienta adecuada para la gestión salarial en el sector público sería de gran importancia para mejorar la gestión de los recursos económicos del erario público, así como para dotar de una mayor equidad y transparencia a la retribución de los empleados de la Administración Pública. En este trabajo de final de carrera nos proponemos elaborar una solución informática que apunta en esta dirección. Para esto se utilizarán tecnologías de desarrollo dirigido por modelos, que permiten acercarse a una mejor representación del espacio del problema y al mismo tiempo, permiten generar de forma automática los productos de software necesarios para dar soporte a nuestra solución. Así, es posible abordar un tema tan complejo como es la gestión de recursos humanos mediante herramientas y tecnologías de desarrollo de software de vanguardia, asegurando un resultado más cercano a las necesidades de información del sector público. 1.2. Problema En la Administración Pública es necesario considerar diferentes elementos al momento de definir criterios adecuados de retribución a los empleados. Estos criterios pueden depender del nivel de estudios, de la experiencia o años de antigüedad en el puesto, del nivel de responsabilidad, de la peligrosidad del trabajo, del tipo de jornada laboral, etc. Es necesario que estos criterios se establezcan de forma transparente y precisa para alcanzar los objetivos de equidad externa y equilibrio interno. La equidad externa se consigue cuando los empleados perciben que dos puestos iguales en dos Administraciones distintas están igualmente remunerados. En caso que se perciba distinta remuneración para dos puestos aparentemente iguales, se deben establecer y divulgar claramente las diferencias en características y competencias exigidas para acceder a cada puesto. El equilibrio interno se alcanza cuando los empleados entienden que las retribuciones de los distintos puestos de trabajo existentes dentro de una misma organización se explican por las diferencias entre sus competencias y funciones; para conseguirlo, las competencias y funciones de cada puesto de trabajo deben ser definidas de forma objetiva. En definitiva, la consecución de estos dos objetivos necesita de dispositivos que permitan establecer comparaciones tanto entre distintas Administraciones, como entre los puestos de trabajo de la misma Administración. Actualmente, no se conocen mecanismos que permitan a los empleados públicos (o aspirantes a serlo) conocer la información salarial de puestos de trabajo equivalentes en Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 17 distintas Administraciones, para poder valorar si se cumple el criterio de equidad externa. Esta carencia informativa puede provocar el descontento de empleados públicos que, pagados por encima del mercado, consideren que su sueldo es injusto, al no disponer de referencias salariales. También provoca que el aspirante a trabajar en la Administración no tenga medios suficientes para elegir a qué convocatoria presentarse o simplemente decidir si le interesa más el mercado privado de trabajo o el público. La Administración Pública en general también adolece de una metodología de asignación de tareas y competencias a los puestos de trabajo, y de la evaluación de las habilidades de cada empleado para determinar el nivel de adaptación de sus empleados a las exigencias de los puestos de trabajo. Este problema lleva a situaciones en que se dispone de empleados sobrecapacitados (en la mayor parte de los casos) o infracapacitados para las tareas que desempeñan. Además, en muchos casos se puede percibir que la asignación salarial y los premios o compensaciones laborales se deben a criterios subjetivos, no especificados u opacos, lo que crea un clima laboral de desconfianza y desmotivación. Estos dos problemas, la falta de mecanismos para la gestión transparente de salarios en distintas Administraciones Públicas y la inexistencia de una metodología para caracterizar y evaluar objetivamente los puestos de trabajo, provocan descontento y desmotivación en los empleados, lo que afecta notablemente a la productividad y eficiencia de la Administración Pública. A su vez, genera en la ciudadanía un clima de desconfianza en la gestión económica de los servicios que ofrece. 1.3. Objetivos De acuerdo a los antecedentes presentados anteriormente, este Proyecto Final de Carrera tiene como meta principal mejorar la eficiencia en la gestión de los recursos humanos de la Administración Pública, y ayudar de este modo, a mejorar la percepción ciudadana del gasto que se realiza del erario público. Para alcanzar la meta propuesta, es necesario alcanzar los siguientes objetivos específicos: - Facilitar la información necesaria al empleado de la Administración Pública para que pueda comprobar si se cumple el criterio de equidad externa. - Poner a disposición de cualquier ciudadano las estadísticas salariales de la Administración Pública con el fin de dotar de transparencia los gastos destinados al funcionariado. - Permitir desarrollar un modelo de evaluación de empleados de acuerdo a sus conocimientos. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 18 - Facilitar unos criterios objetivos para la asignación salarial y promoción dentro de la Administración Pública. - Favorecer información que ayude a evaluar si se cumple el criterio de equilibrio interno. Para satisfacer los objetivos específicos propuestos nos proponemos elaborar dos sistemas de información que den un soporte adecuado a la gestión de las retribuciones. Estos sistemas de información serán generados mediante las herramientas tecnológicas que actualmente existen para el desarrollo de sistemas de información complejos, como son la definición de modelos conceptuales y la generación automática de productos de software a partir de estos modelos. El primero de los sistemas de información permitirá la publicación de estadísticas de salarios de la Administración Pública local, con el objetivo facilitar a los empleados la comprobación de si se cumple el criterio de equidad externa y dotar de transparencia el gasto del erario público empleado en recursos humanos. El segundo de los sistemas de información permitirá la evaluación de conocimientos o competencias de los empleados de una Administración. Este sistema de información será diseñado con el objetivo de que pueda ser utilizado para un proyecto innovador dirigido a Administraciones Públicas nacionales denominado ©Excarpsus[5]. Excarpsus presenta un modelo de valoración de puestos de trabajo en la Administración Pública local. Los objetivos específicos que pretende cubrir el sistema de información dentro del proyecto Excarpsus son los siguientes: - Ser la herramienta informática que permita desarrollar el modelo de evaluación de empleados Excarpsus. - Facilitar y definir unos criterios objetivos para la asignación salarial y promoción dentro de la Administración Pública. - Proporcionar información que ayude a evaluar si se cumple el criterio de equilibrio interno. 1.4. Estructura del documento Esta memoria de Proyecto Final de Carrera (PFC) se estructura en seis capítulos y un anexo que se describen a continuación:  En el capítulo uno se explica la motivación que hace surgir este PFC y el problema que se intenta resolver con el mismo, además de los objetivos que se desean alcanzar. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 19  En el capítulo dos se presenta el contexto actual de herramientas de gestión de recursos humanos en la Administración Pública. Además, en este capítulo se presenta el modelo Excarpsus, el cual es el modelo de gestión de recursos humanos para el que se construyen los sistemas de información de este PFC.  En el capítulo tres se presenta el Desarrollo Dirigido por Modelos (MDD). MDD es el método de desarrollo elegido para la construcción de estos sistemas, siendo OO-Method la tecnología concreta aplicada a través del conjunto de herramientas Olivanova.  En el capítulo cuatro se hace un análisis del espacio del problema. En este capítulo se especifican los requisitos funcionales de los sistemas de información desarrollados mediante casos de uso y se explica la correspondencia entre cada caso de uso y el elemento del modelo conceptual involucrado en su representación.  En el capítulo cinco se describe el espacio de la solución. En este capítulo se explica el proceso de transformación desde el modelo conceptual hasta el producto final; y posteriormente se muestra cómo se obtiene el código fuente mediante los sistemas Olivanova, los pasos de preparación de la base de datos y cómo se realiza la compilación del código fuente. Finalmente, se muestra cómo la aplicación final representa los conceptos diseñados en el modelo conceptual.  En el capítulo seis se presentan las conclusiones del PFC y las posibles extensiones al trabajo realizado.  En el anexo I se presenta el detalle de los casos de uso y los elementos del modelo conceptual que se utilizan para su representación. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 20 2. HERRAMIENTAS DE RECURSOS HUMANOS EN LA ADMINISTRACIÓN PÚBLICA La sociedad capitalista se organiza en mercados regidos por la ley de la oferta y la demanda. En estos mercados, los productos en los que su oferta sea inferior a la demanda tienden a tener un precio más alto que aquellos en los que la oferta supera a su demanda. El laboral, no es más que otro mercado que se rige, en principio sobre las leyes de la oferta y la demanda. En el mercado laboral, el producto que se comercia es el esfuerzo o conocimiento de los empleados que suele cuantificarse en horas o jornadas de trabajo. Desde un punto de vista económico y siguiendo estrictamente este criterio, el precio de la jornada de trabajo estará dado por el equilibrio entre el hecho de que una organización no dispone de una alternativa más rentable que su empleado y el empleado no encuentra un puesto laboral más rentable que el de la organización en la que trabaja. En otras palabras, “si una empresa paga salarios más altos que el mercado, pierde competitividad. Si paga salarios más bajos que el mercado, pierde a sus empleados” *6]. Desde un punto de vista social, el salario debe ser suficiente para que el trabajador pueda cumplir con sus necesidades básicas. En el caso concreto de España, la Constitución expresa que “todos los españoles tienen el deber de trabajar y el derecho al trabajo, a la libre elección de profesión u oficio, a la promoción a través del trabajo y a una remuneración suficiente para satisfacer sus necesidades y las de su familia, sin que en ningún caso pueda hacerse discriminación por razón de sexo” [7]. Teniendo en cuenta ambas perspectivas, es necesario tener herramientas para conocer el valor nominal de los salarios para que se ajusten al mercado laboral y que, a su vez, sirvan para satisfacer las necesidades básicas de los individuos de la sociedad. Una de estas herramientas es la referencia salarial. Históricamente, la primera referencia salarial conocida es el salario mínimo, establecido por primera vez en el siglo XIX en Australia y Nueva Zelanda [8]. En España, el salario mínimo (llamado Salario Mínimo Interprofesional, en adelante SMI) representa el sueldo mínimo legal que un trabajador puede cobrar independientemente de su dedicación profesional. Además del SMI, existen otras referencias salariales en España, como son las aparecidas en los convenios colectivos1. Estas son referencias que están fijadas por ley o amparadas en una negociación colectiva. Sin embargo, además existen referencias y estudios 1 Convenio colectivo: “Un Convenio Colectivo es el acuerdo suscrito entre los representantes de los trabajadores y de los empresarios para fijar las condiciones de trabajo y productividad en un ámbito laboral determinado” [9]. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 21 de mercado, que sin ser fijadas por ley, están dirigidas a que la empresa privada conozca el valor de los salarios. Para el mercado privado, las empresas consultoras de recursos humanos ofrecen servicios como los estudios de mercado mediante encuestas salariales u otros como la auditoría salarial. La encuesta salarial consiste en recabar información en relación con el nivel de remuneraciones acorde con las tendencias económicas de una región [10]. Ejemplos de esta herramienta son el “Observatorio Salarial” de la consultora de recursos humanos ICSA [11] o las encuestas salariales que ofrecen empresas de internet como salarios.net [¡Error! No se encuentra el origen de la referencia.] o tusalario.es [12]. También el Instituto Nacional de Estadística (INE) realiza una “Encuesta de Estructura Salarial” [13] con carácter cuatrienal. La ¡Error! No se encuentra el origen de la referencia. presenta el resultado de una estadística de media salarial de los trabajadores en España según su nacionalidad, sexo y nivel de estudios publicada por el INE. La auditoría salarial, por su parte, se emplea para conocer la política de remuneraciones aplicada a los distintos niveles de una organización y compararlas con el mercado que compite. Estos servicios también son proporcionados por empresas consultoras de recursos humanos como ICSA o Deloitte [4]. Tabla 1. Resultado de la Encuesta de Estructura salarial del INE de 2006 del salario medio por estudios, organizado por sexos y nacionalidad. I. Sin estudios II. Educación primaria III. Educación secundaria I IV. Educación secundaria II V. Formación profesional de grado medio VI. Formación profesional de grado superior VII. Diplomados universitarios o equivalente VIII. Licenciados, ingenieros superiores y doctores Ambos sexos Total 14.363,99 16.115,33 15.839,69 20.732,53 18.079,05 19.962,21 25.166,90 32.307,43 España 14.804,93 16.500,73 16.045,85 21.139,15 18.180,63 20.064,22 25.351,87 32.481,92 Varones Total 15.996,55 17.971,76 17.718,74 24.418,31 21.436,54 23.313,75 30.474,84 38.598,16 España 16.617,20 18.591,08 18.007,96 25.059,56 21.612,15 23.491,10 30.892,86 38.852,04 Mujeres Total 11.159,21 11.949,30 12.399,34 16.530,53 14.678,69 15.637,70 21.222,51 25.441,05 España 11.457,53 12.092,31 12.499,78 16.691,17 14.752,70 15.678,13 21.310,23 25.593,51 Para el mercado de trabajo público, sin embargo, no existen herramientas que permitan conocer el salario que se paga en las Administraciones. Es necesario y deseable contar con este tipo de información y que esté disponible tanto para empleados, como para gestores de recursos humanos o para candidatos a trabajar en la Administración Pública. Para lograrlo, se deben tener en cuenta los conceptos salariales propios de la Administración Pública, que se fijan en la Ley 7/2007, de 12 de abril, del Estatuto Básico del Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 22 Empleado Público [14]. Los conceptos que se consideran de relevancia para la realización de la referencia salarial que motiva este Proyecto Final de Carrera son los de los funcionarios de carrera. Los artículos 23 y 24 de la citada Ley exponen estos conceptos: Artículo 23. Retribuciones básicas. Las retribuciones básicas, que se fijan en la Ley de Presupuestos Generales del Estado, estarán integradas única y exclusivamente por: a) El sueldo asignado a cada Subgrupo o Grupo de clasificación profesional, en el supuesto de que éste no tenga Subgrupo. b) Los trienios, que consisten en una cantidad, que será igual para cada Subgrupo o Grupo de clasificación profesional, en el supuesto de que éste no tenga Subgrupo, por cada tres años de servicio. Artículo 24. Retribuciones complementarias. La cuantía y estructura de las retribuciones complementarias de los funcionarios se establecerán por las correspondientes leyes de cada Administración Pública atendiendo, entre otros, a los siguientes factores: a) La progresión alcanzada por el funcionario dentro del sistema de carrera administrativa. b) La especial dificultad técnica, responsabilidad, dedicación, incompatibilidad exigible para el desempeño de determinados puestos de trabajo o las condiciones en que se desarrolla el trabajo. c) El grado de interés, iniciativa o esfuerzo con que el funcionario desempeña su trabajo y el rendimiento o resultados obtenidos. d) Los servicios extraordinarios prestados fuera de la jornada normal de trabajo. Por su parte, la dinámica de la negociación colectiva en cada una de las Administraciones, regulada por la Ley 9/1987 de Órganos de Representación al Servicio de las Administraciones Públicas [15], ha hecho que mediante diversas valoraciones o actualizaciones de los salarios fluctúen en cada una de ellas, por lo que las referencias entre comunidades y municipios se ven alteradas. Este Proyecto Final de Carrera pretende ofrecer al conjunto de la ciudadanía una referencia salarial para la Administración Pública local. Ésta debe tener en cuenta los diferentes de los conceptos salariales mencionados en la Ley 7/2007 del Estatuto Básico del Empleado y las variaciones de dichos valores dependiendo de las características de la localidad del puesto de trabajo. Para lograrlo, se parte de una referencia salarial inicial de la Asociación Valenciana de Técnicos de Personal (ATPCV) [16]. El sistema de información que da soporte al uso de esta referencia salarial se llama Sistema de Información de Estimación del Salario mediante el Análisis de Conceptos Retributivos (en adelante, SIESMACRe). Durante la vida útil de este sistema de información, la Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 23 referencia salarial debe ser actualizada para no quedar desfasada, cumplir los objetivos propuestos y ser de utilidad para la sociedad. La Ley 7/2007 del Estatuto Básico del Empleado Público también expresa en su artículo 1 que la Administración Pública debe cumplir el fundamento de “igualdad, mérito y capacidad en el acceso y en la promoción profesional”. Este principio, unido a los puntos a, b y c de retribuciones complementarias, plantea la necesidad de conseguir un sistema objetivo de evaluación de empleados para la asignación retributiva. Para satisfacer esa necesidad, se creó el modelo ©Excarpsus [5] para la valoración de puestos de trabajo en la Administración Pública española. Este modelo tiene dos referentes históricos. El primero de ellos es un proyecto del Departamento de Trabajo de Nueva Zelanda orientado a la función pública en el que se pretendía realizar cuestionarios a los empleados para conocer el nivel en el que se encontraban de acuerdo a unos factores de los puestos de trabajo previamente definidos. El objetivo de este proyecto era garantizar la no discriminación, por razón de género o nacionalidad, en el proceso de valoración de los puestos de trabajo. El segundo referente histórico es el denominado proyecto ISOS [17], de la Universidad Politécnica de Catalunya, que importó a España el trabajo neozelandés, pero lo adaptó a la empresa privada, dejando vacante la aplicación del proyecto para la función pública. Excarpsus propone la adaptación del modelo neozelandés para su uso en la Administración Pública española. Para realizar la valoración de puestos de trabajo en una Administración Pública determinada siguiendo el modelo Excarpsus, se deben definir las competencias de los puestos de trabajo y las habilidades necesarias para llevarlas a cabo. Una vez definidas, se evalúa a los empleados de la Administración a través de cuestionarios de sus habilidades para obtener su adecuación al puesto de trabajo. En el Proyecto Final de Carrera objeto de este documento, se pretende crear también un sistema de información que dé soporte a la aplicación práctica del modelo Excarpsus, concretamente a la gestión de evaluaciones de los empleados. Por tanto, debe gestionar la información relativa a los requisitos de los puestos de trabajo, la creación y asignación de los cuestionarios a los empleados correspondientes y las respuestas y obtención de puntos por dichos empleados. Esta herramienta se denomina Sistema de Información de la Evaluación de Funcionarios de Administraciones Públicas (en adelante, SIEFAP). 2.1. El modelo Excarpsus El Modelo Excarpsus [5] es un método de clasificación de puestos de trabajo de Administraciones Públicas locales y valoración de sus empleados. Es un mecanismo completo para conocer o establecer la política retributiva de las Administraciones en las que se implanta Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 24 y evaluar el rendimiento y la adecuación de los empleados a su puesto de trabajo con respecto al salario que perciben. La aplicación del Modelo Excarpus en una Administración comienza con el análisis y clasificación de los puestos de trabajo de la Administración local particular. Las características mínimas que se necesitan de cada puesto de trabajo son [18]: - Denominación del puesto. - Requisitos exigidos para su desempeño. - Nivel de complemento de destino y específico. - Categoría profesional o régimen jurídico. Entre diferentes Administraciones Públicas locales suele haber diferencias, entre otras, en políticas de retribución y situación económica. Por tanto, además de la clasificación de los puestos de trabajo, se deben conocer otros aspectos importantes de la Administración local. Entre estos se destacan [18]: - Definición exhaustiva de los conceptos retributivos y su percepción; así como establecimiento de los parámetros básicos del mismo. - Determinación de la situación actual y la masa salarial disponible. - Determinación del abanico salarial y su adaptación al mercado. - Fluctuaciones de la masa salarial en función de parámetros determinados por variaciones en el desarrollo de la organización (población, plantilla, competencias, excelencia, etc). - Establecimiento de mecanismos de compensación y actualización de disonancias retributivas tras la alteración de los contenidos. Una vez conocidas las características económicas y de política laboral de la Administración, se debe definir los conocimientos o habilidades exigibles a los puestos de trabajo resultantes de la clasificación. La evaluación a los empleados se realiza en base a estas habilidades. 2.1. 1. Valoración de puntos por factor El método que utiliza el modelo Excarpsus en su valoración es el de valoración de puntos por factor. Excarpsus tiene dos referentes históricos: un proyecto de evaluación de empleados de la función pública realizado por el Departamento de Trabajo de Nueva Zelanda, y el proyecto ISOS [17] de la Universidad Politécnica de Catalunya. Ambos trabajos utilizan también el método de valoración de puntos por factor. Este método fue creado por el norteamericano Merril R. Lott y es el más perfeccionado y utilizado de los métodos para la evaluación de cargos. Es una técnica cuantitativa en donde se asignan valores numéricos (puntos) a cada elemento o aspecto del cargo y se obtiene un valor total por la suma de valores numéricos. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 31 3.3 El modelado conceptual con Olivanova Olivanova Modeler es la herramienta creada por CARE Technologies para el Modelado Conceptual orientado a objetos. Permite la creación, edición y validación formal de modelos conceptuales de alto nivel. El objetivo principal de OLIVANOVA Modeler es construir una especificación formal de un sistema de información de forma que dicha especificación sea validable. La especificación se basa en el lenguaje formal de especificación de sistemas de información orientado a objetos denominado OASIS. El uso de este lenguaje permite asegurar la consistencia, corrección y no ambigüedad de los modelos conceptuales creados, y por lo tanto, de los sistemas de información generados posteriormente de forma automática a partir de los mismos. Para ello dispone de los siguientes modelos que nos permitirán definir un modelo conceptual con el máximo detalle: • Modelo de objetos • Modelo Dinámico • Modelo Funcional • Modelo de Presentación Para definir cada uno de estos modelos, OLIVANOVA Modeler proporciona una serie de patrones de modelado conceptual, un conjunto de diagramas UML y una serie de fórmulas bien formadas, mediante los cuales se puede definir de manera sencilla el modelo conceptual, haciendo que la complejidad de la especificación formal construida sea totalmente transparente al analista. A continuación, se explica brevemente cómo crear un modelo conceptual mediante esta herramienta, viendo los diversos modelos que la componen. 3.3.1 El modelo de objetos El punto de partida para especificar un modelo conceptual mediante OLIVANOVA Modeler es el Modelo de objetos, el cual recoge las propiedades estáticas del sistema de información. En los sistemas de información, podremos identificar diferentes entidades con una estructura y un comportamiento denominados objetos, los cuales pueden ser agrupados en clases en base a sus propiedades. El Modelo de objetos estará formado por las propiedades estáticas de los objetos que lo componen y las relaciones entre ellos. Para especificar el Modelo de Objetos, OLIVANOVA Modeler utiliza una notación gráfica bien definida que se emplea en el Diagrama de Clases. La Figura 4 muestra un ejemplo de un modelo de objetos. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 32 Figura 4. Ejemplo del Diagrama de clases En el Diagrama de Clases se definen tanto las clases identificadas en el sistema, como las relaciones entre dichas clases. Las clases son las unidades básicas de modelado, y en ellas se describe las propiedades estáticas de los objetos (atributos, servicios y restricciones de integridad). Mientras que las relaciones pueden ser de tres tipos: relaciones de agregación, relaciones de especialización y relaciones de agente. Se trata de relaciones estructurales entre las clases. Todas las propiedades de las clases son accesibles desde un mismo diálogo, de forma que se facilita al analista la edición de las mismas. Entre las más importantes cabe destacar los atributos, el conjunto de valores de los cuales definen el estado de cada objeto de esa clase. Por otro lado tenemos los servicios, que pueden ser de tres tipos: - Eventos: son unidades de proceso atómicas, ocurren en un momento específico de tiempo y producen cambios de estado en los objetos. - Transacciones locales: son unidades de proceso que pueden estar compuestas por varios servicios. Cuando se inicia una transacción, tendrá que continuar hasta que termine o volver al estado inicial en el caso de que se produzca algún error. - Operaciones locales: son idénticas a las transacciones locales, pero en caso de fallo no vuelven al estado inicial. Por último, también se pueden definir restricciones de integridad en las clases, se trata de condiciones que se deben cumplir en cualquier instante de tiempo. Olivanova Modeler emplea fórmulas bien formadas para definir propiedades del sistema en todos los modelos que componen el Modelo Conceptual. En el Diagrama de Clases, además de la notación gráfica, se dispone de fórmulas bien formadas para especificar restricciones de Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 33 integridad, transacciones, operaciones, valores por defecto de los atributos, valores de atributos derivados, precondiciones y otros elementos [27]. 3.3.2 El Modelo Dinámico El Modelo Dinámico recoge las propiedades dinámicas de los objetos. En el Modelo Dinámico se definen los estados válidos de los objetos y las secuencias de servicios que producen los cambios entre dichos estados. En este modelo, también se especifica las interacciones entre los distintos objetos. Para ello disponemos de dos diagramas: - Diagrama de Transición de Estados - Diagrama de Interacción de Objetos Diagrama de Transición de Estados El Diagrama de Transición de Estados permite especificar el comportamiento correcto de los objetos, es decir en este diagrama podremos ver los diferentes estados en los que un objeto de una clase puede encontrarse desde que es creado hasta que se destruye, así como las transiciones que ocurren para llegar a ellos. Cada una de dichas transiciones entre estados, estará asociada a un servicio del propio objeto. La Figura 5 muestra un ejemplo de Diagrama de Transición de Estados. Figura 5. Ejemplo del Diagrama de Transición de Estados Para poder especificar el Diagrama de Transición de Estados de una clase, es necesario tener definidos previamente los servicios, puesto que son estos los que provocan las transiciones. Así pues, este diagrama se realiza en un instante posterior a la elaboración del Diagrama de Clases. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 34 Diagrama de Interacción de Objetos En el Diagrama de Interacción de Objetos recoge la manera de interactuar que tienen los objetos en el sistema. Mediante este diagrama, el usuario de la herramienta especifica: • Disparos. Cuando se satisface una determinada condición sobre el estado de cierto objeto, se puede provocar la ejecución de servicios de este mismo objeto o de otros objetos del sistema. A éste método de interacción entre objetos se le denomina disparo. Para su definición se deberá seleccionar el objeto de origen o definición del disparo, el objeto u objetos destino del disparo y el servicio que se ejecutará al activarse el disparo. • Servicios Globales. Pueden ser Transacciones Globales u Operaciones Globales. Es posible definir transacciones u operaciones que engloben a servicios de diversos objetos (usualmente, de clases distintas no relacionadas), para ello se dispone de los servicios globales. Dichos servicios globales se definen mediante una fórmula en la cual se especifica la secuencia de servicios que deben ser ejecutados. [27] 3.3.3 El Modelo Funcional El Modelo Funcional especifica la forma en que la ejecución de eventos modifica el estado de los objetos mediante evaluaciones (fórmulas bien formadas que expresan cómo cambia el valor de un atributo variable ante la ocurrencia de un evento). El Modelo Funcional contiene las evaluaciones para un atributo variable y un evento de una determinada clase. Las evaluaciones únicamente se pueden definir para eventos, nunca para transacciones y operaciones, puesto que los servicios moleculares producen el cambio de estado en los objetos al enlazar la ejecución de diversos eventos. Un atributo podrá ser modificado por varios eventos y un evento podrá modificar a varios atributos. El evento puede modificar al atributo de diversas formas, puede tener en cuenta el valor anterior del mismo, puede incrementar, decrementar o inicializar su valor, o también puede asignarle un valor directamente. Al tener dependencia de las propiedades estáticas de las clases, este modelo también se define con posterioridad al Diagrama de Clases [27]. 3.3.4 El Modelo de Presentación OLIVANOVA Modeler proporciona la posibilidad de especificar la interfaz de usuario del sistema mediante un cuarto modelo, el Modelo de Presentación. Este modelo, que no está incluido en UML y que diferencia positivamente a OLIVANOVA Modeler de las otras herramientas de modelado, tiene como finalidad proporcionar al analista un medio para la captura de los requisitos de interfaz de usuario. De esta manera, permite especificar interfaces abstractas y homogéneas, independientes de consideraciones de diseño. El Modelo de presentación ofrece los patrones de interfaz necesarios para especificar cualquier aplicación de gestión. Mediante estos patrones se recogerán todos los requisitos de la interfaz: Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 35 • Presentación. El formato en que los datos se muestran al usuario. • Navegación. Información relacionada al medio de acceso a los objetos • Búsqueda. Facilidad para encontrar la información • Visibilidad. Los permisos de los usuarios para acceder a la información. • Acceso. Los permisos asociados a las acciones que proporciona el sistema. La combinación de estos patrones permite definir la interfaz de la aplicación tal y como la utilizará el usuario final, de una manera intuitiva y sencilla. El modelo de presentación se estructura en tres niveles de trabajo organizados, de lo general a lo particular. La Figura 6 esquematiza el Modelo de Presentación; se pueden observar los distintos niveles, los elementos que los componen y qué elementos de pueden formar parte de otros de nivel superior [22] [27]. Figura 6. Niveles y elementos del modelo de presentación [22]. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 36 NIVEL 1. El primer nivel contiene el Árbol de Jerarquía de Acciones (Hierarchy Action Tree – HAT en inglés), que permite organizar la manera en que el usuario accederá a la aplicación. Mediante el Árbol de Jerarquía de Acciones se podrá definir el menú de acceso de los diversos tipos de usuarios de la aplicación. NIVEL 2. El segundo nivel contiene las Unidades de Interacción del sistema, los cuales especifican las características de los diálogos de la aplicación generada. La interfaz de usuario se descompone en diversos escenarios que permitirán al usuario ejecutar sus tareas. Las tareas están representadas por patrones del primer nivel de trabajo y son los elementos con los que interactuará el usuario, pero se agrupan en unidades de interacción para presentar la información de forma compacta. Las unidades de interacción pueden ser:  Unidades de Interacción de Servicio (UIS): Representan la interacción entre el usuario de la aplicación y la ejecución de un servicio del sistema.  Unidades de Interacción de Instancia (UIS): Representa la interacción entre el usuario de la aplicación y la información de un objeto específico.  Unidades de Interacción de Población (UIP): Representa la interacción entre el usuario de la aplicación y la información de varios objetos de una clase.  Unidades de Interacción de Maestro Detalle (UIMD): Representa la interacción entre el usuario de la aplicación y un grupo de unidades de interacción del sistema, siguiendo una estructura de maestro – detalle. NIVEL 3. Patrones de presentación. Son las piezas básicas sobre las que se construyen las Unidades de Interacción simples. Mediante estos patrones, se pueden expresar requisitos de interfaz precisos. Cada uno de estos patrones, puede participar en diversas Unidades de Interacción (Vea la Figura 6). Estos elementos pueden ser:  Entrada: Este elemento permite capturar los datos que deben ser ingresados por el usuario del sistema.  Selección definida: Este elemento permite al usuario seleccionar un valor desde una colección de datos existente.  Agrupador de argumentos: Este elemento permite definir la forma en que los argumentos de los servicios serán presentados al usuario.  Dependencia de argumentos: Permite definir relaciones de dependencias entre los valores o estado de un argumento de entrada de un servicio y los valores o estado de otros argumentos de entrada del mismo servicio. La dependencia de argumentos utiliza reglas de tipo ECA (Evento – Condición – Acción) para cada argumento de entrada de un servicio, que tienen la siguiente semántica: cuando un evento de Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 37 interfaz ocurre en un argumento de entrada (por ejemplo cuando el usuario ingresa un valor) se realiza una acción si se cumple una determinada condición.  Precarga de argumentos: Este elemento permite definir un conjunto de objetos que pueden ser seleccionados como argumentos de entrada de un servicio.  Filtro: Este elemento permite definir una condición de selección sobre una población de objetos de una clase. El filtro puede tener variables dato-valuadas y variables objeto-valuadas que pueden tener definido un valor por defecto, una población asociada para seleccionar los valores de las variables objeto-valuadas y precarga de los valores de las variables objeto-valuadas.  Criterio de ordenación: Este elemento permite definir el orden de los objetos presentados en una población, considerando el orden ascendente/descendente sobre los valores de los atributos de los objetos presentes en la población.  Conjunto de visualización: Permite especificar las propiedades de una clase que serán visibles al usuario, y el orden en que se mostrarán dichas propiedades.  Navegación: Permite la visualización de información de los objetos de las clases relacionadas a un objeto de una clase.  Acción: Permite la ejecución de los servicios definidos en las clases sobre un objeto de la clase.  Filtrado Navegacional: Permite acotar la navegación hacia los objetos de las clases relacionadas a un objeto según una condición de filtro.  Inicialización de Argumentos: Permite asignar un valor inicial a los argumentos de entrada de un servicio que se accede directamente desde otro servicio.  Navegación Condicional: Permite navegar a las unidades de interacción luego de la ejecución de un servicio que haya terminado de manera exitosa o fallida. Para seleccionar la unidad de interacción a la que se navegará, es necesario especificar una condición que debe cumplirse cuando se haya ejecutado el servicio. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 38 4. ESPACIO DEL PROBLEMA En este proyecto se desea plantear una solución genérica a la gestión de recursos humanos de Administraciones Públicas. Esta solución se divide en dos sistemas de información, el primero de los cuales es una herramienta que permite realizar una estimación del salario de un funcionario dependiendo de ciertos parámetros. Su nombre es Sistema de Información de Estimación del Salario Mediante el Análisis de Conceptos Retributivos (en adelante, SIESMACRe). El segundo sistema de información es un método de evaluación del funcionariado de una Administración Pública, que recibe el nombre de Sistema de Información para la Evaluación de Funcionarios de las Administraciones Públicas (en adelante, SIEFAP). SIESMACRe va dirigido a usuarios anónimos que deseen conocer el salario que tendrían si fuesen funcionarios, dependiendo de parámetros tales como el tipo de puesto, la Comunidad Autónoma y el tamaño de la población para la que trabaja la Administración o el tamaño de su plantilla de trabajadores. SIEFAP consta de un modelo de evaluación de los empleados de una Administración, con el objetivo de establecer un método de asignación automática de la masa salarial de la Administración. El método de evaluación se basa en la realización de cuestionarios sobre conocimientos por parte del empleado; el método de asignación salarial debe gestionar la información relativa al presupuesto de la Administración y el sueldo que debería tener el empleado de acuerdo con su evaluación de conocimientos. Los usuarios de este segundo sistema son los empleados que se desea evaluar de la Administración, usuarios editores de los cuestionarios, y usuario/s administrador/es. 4.1. Resumen de las aplicaciones A continuación, se explican brevemente los requisitos que deben cumplir los dos sistemas de información. 4.1.1 SIESMACRe La aplicación de la estimación del salario de un funcionario debe gestionar la información relativa a los factores relevantes para el cálculo del salario, los cuales tienen las siguientes características: La CATEGORÍA del funcionario indica el salario bruto tanto anual como mensual que se recibe. La categoría puede tomar los valores A, B, C, D o E. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 39 El COMPLEMENTO DE DESTINO es otro concepto que tiene un valor en términos de salario anual y mensual que percibe el funcionario. El complemento de destino puede tomar valores de 5 a 30. Dependiendo de la categoría del funcionario este rango puede ser más restringido. El COMPLEMENTO ESPECÍFICO es un concepto salarial más que representa una cantidad extra a recibir por parte del funcionario. El valor correspondiente a la CATEGORÍA, el correspondiente al COMPLEMENTO DE DESTINO y el COMPLEMENTO ESPECÍFICO se suman para formar el salario del funcionario. La aplicación resultante informa al usuario del salario calculado y de estadísticas de salarios de trabajadores con puestos similares al suyo, con el objetivo de que pueda comparar sus ingresos con los de funcionarios que desempeñan funciones semejantes. Los parámetros estadísticos son el salario medio, el percentil 10, percentil 25, percentil 50, percentil 75 y percentil 90. Para poder obtener estas estadísticas, el usuario debe introducir la denominación del PUESTO DE TRABAJO, la COMUNIDAD AUTÓNOMA y el NÚMERO DE HABITANTES de la población para la que trabaja la administración y el tamaño de la PLANTILLA de empleados Del PUESTO DE TRABAJO se debe conocer su nombre, la media del salario y los percentiles 10, 25, 50, 75 y 90. El resto de parámetros que se requieren no son valores absolutos, sino que representan un porcentaje sobre las cantidades de cada uno de los parámetros estadísticos ya comentados. La COMUNIDAD AUTÓNOMA tiene un nombre que la identifica y el valor del factor de variación sobre las cantidades absolutas. El NÚMERO DE HABITANTES se representa como un rango con su límite inferior y superior. A cada rango le corresponde un factor de variación sobre las cantidades absolutas. La PLANTILLA se representa también como un rango de empleados, en el que a cada rango le corresponde un factor de variación. Esta aplicación se diseña con la intención de que cualquier usuario anónimo pueda seleccionar los valores que desee de los parámetros anteriores y conocer la estimación y estadísticas del salario a partir de lo introducido. Para que esto sea posible, debe existir una funcionalidad extra para usuario/s administrador/es que permita dar de alta, dar de baja o modificar propiedades de CATEGORÍAS, COMPLEMENTOS DE DESTINO, PUESTOS DE TRABAJO, COMUNIDADES AUTÓNOMAS, NÚMERO DE HABITANTES Y tamaño de las PLANTILLAS de empleados. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 40 4.1.2 SIEFAP El Sistema de Información para la Evaluación de Funcionarios de la Administración Pública (SIEFAP) está definido de acuerdo a la siguiente descripción de características y funcionalidades: Los EMPLEADOS se identifican por su NIF y se necesita al menos la información de su nombre, apellidos, fecha de nacimiento y sexo. El EMPLEADO trabaja para un DEPARTAMENTO, que a su vez pertenece a una ADMINISTRACIÓN. La información que se almacena del DEPARTAMENTO es su nombre, el presupuesto asignado para Recursos Humanos y el número de EMPLEADOS que trabajan en él. La información que se tiene de la ADMINISTRACIÓN es su nombre, el presupuesto del que dispone para Recursos Humanos, el número de DEPARTAMENTOS en los que se divide y el número de EMPLEADOS que trabajan en ella. A un EMPLEADO se le pueden realizar distintas EVALUACIONES de sus conocimientos. Una EVALUACIÓN contiene el número de puntos máximo y los obtenidos por el EMPLEADO, la fecha de creación, la fecha de finalización y un indicador de si la EVALUACIÓN está finalizada. Para representar un CONOCIMIENTO simplemente es necesario su nombre y descripción, pero un CONOCIMIENTO puede tener SUBCONOCIMIENTOS asociados. Por ejemplo, podría existir un CONOCIMIENTO llamado “Aptitudes generales” que se dividiese en los SUBCONOCIMIENTOS “Matemáticas”, “Lectura y comprensión” e “Informática”. La evaluación de los CONOCIMIENTOS de los EMPLEADOS se realiza por medio de CUESTIONARIOS. Los CUESTIONARIOS se responden en base a una PLANTILLA DE CUESTIONARIO que debe estar creada en el sistema antes que se empiece a responder. Cada CUESTIONARIO lo realiza un EMPLEADO y sus respuestas las debe validar un EMPLEADO SUPERVISOR. El EMPLEADO SUPERVISOR tiene las mismas características que un EMPLEADO, pero es necesario que valide y/o corrija las respuestas de los CUESTIONARIOS de los EMPLEADOS que tiene a cargo. La información que se almacena del CUESTIONARIO es la fecha de creación, la fecha en que el EMPLEADO comienza a realizar el CUESTIONARIO, la fecha en la que lo finaliza y las fechas en las que el EMPLEADO SUPERVISOR sugiere una corrección o valida las respuestas. También se debe conocer el estado en el que se encuentra el cuestionario, el peso que tiene dentro de la evaluación del conocimiento, la puntuación obtenida por el EMPLEADO que lo realiza y el porcentaje de puntos obtenidos respecto del total del CUESTIONARIO. Los estados pueden ser “En Edición”, en el que se puede asociar el CUESTIONARIO a la VALORACIÓN; “Preparado”, que indica que está listo para comenzarse; “En Respuesta”, en el que el EMPLEADO responde a las preguntas; “Finalizado”, en el que el EMPLEADO SUPERVISOR Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 47 Tabla 6. Caso de uso consulta de salario de Categoría CASO DE USO 5. Consulta de salario de Categoría. ACTORES Usuario Administrador. PROPÓSITO Consultar las propiedades del salario mensual o anual de la categoría. RESUMEN Se consulta el salario mensual o el salario anual de la categoría. PRECONDICIONES La categoría debe existir en el sistema. POSTCONDICIONES Ninguna. ENTRADAS El tipo de la categoría. SALIDAS El valor del salario mensual o anual de la categoría. CASOS DE USO REFERENTES A LA GESTIÓN DE COMPLEMENTO DE DESTINO El Complemento del Destino es otro de los factores que componen el sueldo de un funcionario. El funcionario, además de su Categoría, tiene un nivel de complemento de destino, dependiendo de la experiencia adquirida o de las competencias específicas para el trabajo que desempeña. La Figura 9 muestra los casos de uso de la gestión del complemento de destino. Figura 9. Diagrama de casos de uso para la gestión de complemento de destino. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 48 Tabla 7. Caso de uso Alta de Complemento de Destino CASO DE USO 6. Alta de Complemento de Destino. ACTORES Usuario Administrador. PROPÓSITO Crear un complemento de destino. RESUMEN Se crea un complemento de destino con las propiedades de tipo, valor económico mensual y valor económico anual. PRECONDICIONES El valor económico mensual debe ser mayor que cero. POSTCONDICIONES - Los datos relativos al complemento de destino quedan almacenados en el sistema. - El valor económico anual se calcula a partir del mensual. ENTRADAS El tipo y el valor mensual correspondiente al tipo de complemento de destino. SALIDAS Mensaje de confirmación de almacenamiento. Tabla 8. Caso de uso Baja de Complemento de Destino CASO DE USO 7. Baja de Complemento de Destino. ACTORES Usuario Administrador. PROPÓSITO Dar de baja un complemento de destino. RESUMEN El complemento de destino se elimina del sistema. PRECONDICIONES El complemento de destino debe existir en el sistema. POSTCONDICIONES Los datos relativos al complemento de destino se eliminan del sistema. ENTRADAS El tipo del complemento de destino. SALIDAS Mensaje de confirmación de la baja. Tabla 9. Caso de uso Modificación de valor económico CASO DE USO 8. Modificación de valor económico. ACTORES Usuario Administrador. PROPÓSITO Modificar las propiedades del valor económico del complemento de destino RESUMEN Se modifican el valor económico mensual el anual del complemento de destino. PRECONDICIONES - El complemento de destino debe existir en el sistema. - El valor económico mensual de entrada debe ser mayor que cero POSTCONDICIONES - El valor económico mensual toma el valor de la entrada. - El valor económico anual se calcula a partir del mensual. ENTRADAS El tipo del complemento de destino y el nuevo valor mensual. SALIDAS Ninguna. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 49 Tabla 10. Caso de uso Actualización de valor económico CASO DE USO 9. Actualización de valor económico. ACTORES Usuario Administrador. PROPÓSITO Modificar las propiedades del valor económico. RESUMEN Se modifica el valor económico anual y mensual mediante un porcentaje al alza o a la baja PRECONDICIONES - El complemento de destino debe existir en el sistema y el valor mensual y anual no puede ser cero. - El valor del porcentaje debe ser mayor que cero. POSTCONDICIONES - El valor mensual y el anual se modifican. - El valor mensual y el anual resultantes deben ser mayores que cero. ENTRADAS El tipo del complemento de destino, el porcentaje de variación y un indicador de si es al alza o a la baja. SALIDAS Ninguna. Tabla 11. Caso de uso Consulta de valor económico CASO DE USO 10. Consulta de valor económico. ACTORES Usuario Administrador. PROPÓSITO Consultar las propiedades del valor económico mensual o anual del complemento de destino. RESUMEN Se consulta el valor económico mensual o anual del complemento de destino. PRECONDICIONES El complemento de destino debe existir en el sistema. POSTCONDICIONES Ninguna. ENTRADAS El tipo del complemento de destino. SALIDAS El valor económico anual o mensual del complemento de destino. CASOS DE USO REFERENTES A LA GESTIÓN DE PUESTO DE TRABAJO El puesto de trabajo es uno de los parámetros en los que se basa la estimación del salario. El sistema debe almacenar el nombre y valores estadísticos del salario. Para gestionar esa información, se especifican los casos de uso de la Figura 10. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 50 Figura 10. Diagrama de casos de uso para la gestión de puesto de trabajo. Tabla 12. Caso de uso Alta de Puesto de Trabajo CASO DE USO 11. Alta de Puesto de Trabajo. ACTORES Usuario Administrador. PROPÓSITO Crear un puesto de trabajo. RESUMEN Se crea un puesto de trabajo con las propiedades de nombre, media de salario y los percentiles 10, 25, 50, 75 y 90 del salario. PRECONDICIONES Ninguna. POSTCONDICIONES - Los datos relativos al Puesto de Trabajo quedan almacenados en el sistema. - Media > 0 - Percentil 10 > 0 - Percentil 10 <= Percentil 25 - Percentil 25 <= Percentil 50 - Percentil 50 <= Percentil 75 - Percentil 75 <= Percentil 90 ENTRADAS El nombre, la media del salario y los percentiles 10, 25, 50, 75 y 90 del salario. SALIDAS Mensaje de confirmación de almacenamiento. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 51 Tabla 13. Caso de uso Baja de puesto de Trabajo CASOS DE USO 12. Baja de Puesto de Trabajo. ACTORES Usuario Administrador. PROPÓSITO Dar de baja un puesto de trabajo. RESUMEN El puesto de trabajo se elimina del sistema. PRECONDICIONES El puesto de trabajo debe existir en el sistema. POSTCONDICIONES Los datos relativos al puesto de trabajo se eliminan del sistema. ENTRADAS El Puesto de Trabajo. SALIDAS Mensaje de confirmación de la baja. Tabla 14. Caso de uso Modificación de nombre de Puesto de Trabajo CASO DE USO 13. Modificación de nombre de Puesto de Trabajo ACTORES Usuario Administrador. PROPÓSITO Modificar el nombre de puesto de trabajo RESUMEN Se modifica el nombre del puesto de trabajo. PRECONDICIONES El puesto de trabajo debe existir en el sistema. POSTCONDICIONES El nombre del puesto de trabajo cambia por el nuevo. ENTRADAS El puesto de trabajo y su nuevo nombre. SALIDAS Mensaje de confirmación del cambio. Tabla 15. Caso de uso Modificación de la media del salario del Puesto de Trabajo CASO DE USO 14. Modificación de la media del salario del Puesto de Trabajo. ACTORES Usuario Administrador. PROPÓSITO Modificar la media del salario del puesto de trabajo RESUMEN Se modifica la media del salario del puesto de trabajo PRECONDICIONES El puesto de trabajo debe existir en el sistema. POSTCONDICIONES - La media del salario toma el valor introducido. - La media del salario debe ser mayor que cero ENTRADAS El puesto de trabajo y la nueva media del salario. SALIDAS Mensaje de confirmación del cambio. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 52 Tabla 16. Caso de uso Modificación de los percentiles del salario del Puesto de Trabajo CASO DE USO 15. Modificación de los percentiles del salario del Puesto de Trabajo. ACTORES Usuario Administrador. PROPÓSITO Modificar los percentiles del salario del puesto de trabajo RESUMEN Se modifican los percentiles 10, 25, 50, 75 y 90 del salario del puesto de trabajo. PRECONDICIONES El puesto de trabajo debe existir en el sistema. POSTCONDICIONES - Los nuevos valores de los percentiles quedan almacenados en el sistema. - Percentil 10 > 0 - Percentil 10 <= Percentil 25 - Percentil 25 <= Percentil 50 - Percentil 50 <= Percentil 75 - Percentil 75 <= Percentil 90 ENTRADAS El Puesto de Trabajo y los nuevos valores de los percentiles. SALIDAS Ninguna. Tabla 17. Caso de uso Actualización de la media del salario CASO DE USO 16. Actualización de la media del salario. ACTORES Usuario Administrador. PROPÓSITO Modificar la media del salario del puesto de trabajo. RESUMEN Se modifica la media según un porcentaje al alza o a la baja. PRECONDICIONES - El puesto de trabajo debe existir en el sistema. - El porcentaje debe ser mayor que cero. POSTCONDICIONES - La media del salario se modifica. - La media del salario debe ser mayor que cero. ENTRADAS El puesto de trabajo, el porcentaje de variación y un indicador de si es al alza o a la baja. SALIDAS Ninguna. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 53 Tabla 18. Caso de uso Actualización de los percentiles del salario CASO DE USO 17. Actualización de los percentiles del salario. ACTORES Usuario Administrador. PROPÓSITO Modificar los percentiles del salario del puesto de trabajo. RESUMEN Se modifican los percentiles según un porcentaje al alza o a la baja. PRECONDICIONES - El puesto de trabajo debe existir en el sistema. - El porcentaje debe ser mayor que cero. POSTCONDICIONES - Los percentiles del salario se modifican. - Los percentiles deben ser mayor que cero. ENTRADAS El Puesto de Trabajo, el porcentaje de variación y un indicador de si es al alza o a la baja. SALIDAS Ninguna. Tabla 19. Caso de uso Consulta de la media del salario CASO DE USO 18. Consulta de la media del salario ACTORES Usuario Administrador. PROPÓSITO Consultar la media del salario. RESUMEN Se consulta la media del salario del puesto de trabajo. PRECONDICIONES El puesto de trabajo debe existir en el sistema. POSTCONDICIONES Ninguna. ENTRADAS El puesto de trabajo. SALIDAS La media del salario del puesto de trabajo. Tabla 20. Caso de uso Consulta de los percentiles del salario CASO DE USO 19. Consulta de los percentiles del salario ACTORES Usuario Administrador. PROPÓSITO Consultar los percentiles del salario. RESUMEN Se consultan los percentiles del salario del puesto de trabajo. PRECONDICIONES El puesto de trabajo debe existir en el sistema. POSTCONDICIONES Ninguna. ENTRADAS El puesto de trabajo. SALIDAS Los percentiles del salario del puesto de trabajo. CASOS DE USO REFERENTES A LA GESTIÓN DE COMUNIDAD AUTÓNOMA La Comunidad Autónoma en la que se trabaja añade un factor que hace variar la estimación del salario. El sistema debe almacenar el nombre y el valor de dicho factor de variación. Para gestionar esa información, se especifican los casos de uso de la Figura 11. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 54 Figura 11. Diagrama de casos de uso para la gestión de Comunidad Autónoma. Tabla 21. Caso de uso Alta de Comunidad Autónoma CASO DE USO 20. Alta de Comunidad Autónoma. ACTORES Usuario Administrador. PROPÓSITO Crear una Comunidad Autónoma. RESUMEN Se crea una Comunidad Autónoma con su nombre y el factor de variación sobre el salario. PRECONDICIONES Ninguna. POSTCONDICIONES Los datos relativos a la Comunidad Autónoma quedan almacenados en el sistema. ENTRADAS El nombre y el factor de variación. SALIDAS Mensaje de confirmación de almacenamiento. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 55 Tabla 22. Caso de uso Baja de Comunidad Autónoma CASO DE USO 21. Baja de Comunidad Autónoma. ACTORES Usuario Administrador. PROPÓSITO Dar de baja una Comunidad Autónoma. RESUMEN La Comunidad Autónoma se elimina del sistema. PRECONDICIONES La Comunidad Autónoma debe existir en el sistema. POSTCONDICIONES Los datos relativos a la Comunidad Autónoma se eliminan del sistema. ENTRADAS La Comunidad Autónoma. SALIDAS Mensaje de confirmación de la baja. Tabla 23. Caso de uso Modificación de nombre de Comunidad Autónoma CASO DE USO 22. Modificación de nombre de Comunidad Autónoma. ACTORES Usuario Administrador. PROPÓSITO Modificar el nombre de Comunidad Autónoma. RESUMEN Se modifica el nombre de la Comunidad Autónoma. PRECONDICIONES La Comunidad Autónoma debe existir en el sistema. POSTCONDICIONES El nombre de la C.A cambia por el nuevo. ENTRADAS La Comunidad Autónoma y el nuevo nombre. SALIDAS Mensaje de confirmación del cambio. Tabla 24. Caso de uso Modificación del factor de Comunidad Autónoma CASO DE USO 23. Modificación del factor de Comunidad Autónoma. ACTORES Usuario Administrador. PROPÓSITO Modificar el factor de variación de la Comunidad Autónoma. RESUMEN Se modifica el factor de variación de la Comunidad Autónoma. PRECONDICIONES La Comunidad Autónoma debe existir en el sistema. POSTCONDICIONES El factor de variación toma el valor introducido. ENTRADAS La Comunidad Autónoma y el nuevo factor de variación. SALIDAS Ninguna. Tabla 25. Caso de uso Consulta del factor de Comunidad Autónoma CASO DE USO 24. Consulta del factor de Comunidad Autónoma. ACTORES Usuario Administrador. PROPÓSITO Consultar el factor de variación de la Comunidad Autónoma. RESUMEN Se consulta el factor de variación de la Comunidad Autónoma. PRECONDICIONES La Comunidad Autónoma debe existir en el sistema. POSTCONDICIONES Ninguna. ENTRADAS La Comunidad Autónoma. SALIDAS El valor del factor de variación de la Comunidad Autónoma. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 56 CASOS DE USO REFERENTES A LA GESTIÓN DE NÚMERO DE HABITANTES El número de habitantes de la población para la que se trabaja añade un factor que hace variar la estimación del salario. El sistema debe almacenar intervalos de número de habitantes y el valor de dicho factor de variación. Para gestionar esa información, se especifican los casos de uso de la Figura 12. Figura 12. Diagrama de casos de uso para la gestión de número de habitantes. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 63 Tabla 37. Caso de uso Cálculo del salario CASO DE USO 36. Cálculo del salario. ACTORES Usuario Anónimo. PROPÓSITO Calcular el salario del usuario a partir de los parámetros de entrada. RESUMEN Se calcula el salario del usuario a partir de la Categoría, el Complemento de Destino y la cantidad percibida como complemento específico PRECONDICIONES Debe ocurrir el caso de uso 35: Obtención de informe POSTCONDICIONES Ninguna. ENTRADAS La Categoría, el Complemento de Destino y el valor del Complemento Específico SALIDAS - Valor anual y mensual de la Categoría - Valor anual y mensual del Complemento de Destino - Valor anual y mensual del complemento específico - Valor anual de la paga extraordinaria - Salario total anual Tabla 38. Caso de uso de Obtención de estadísticas CASO DE USO 37. Obtención de estadísticas. ACTORES Usuario Anónimo. PROPÓSITO Obtener estadísticas de salario para condiciones de trabajo similares a las de entrada. RESUMEN Se calcula la media del salario y los percentiles 10, 25, 50, 75 y 90 dependiendo de los factores de Puesto de Trabajo, Comunidad Autónoma, Número de Habitantes y Plantilla de trabajadores PRECONDICIONES Debe ocurrir el caso de uso 35: Obtención de informe POSTCONDICIONES Ninguna. ENTRADAS El Puesto de Trabajo, la Comunidad Autónoma, el intervalo de Número de Habitantes y el intervalo de Plantilla de trabajadores. SALIDAS - El salario medio. - Los percentiles 10, 25, 50, 75 y 90 del salario - Posición sobre el salario, y los percentiles 10, 25, 50, 75 y 90 (porcentaje del salario real obtenido en el caso de uso 36 con respecto al valor estadístico) 4.2.3 Casos de Uso SIEFAP SIEFAP (Sistema de Información para la Evaluación de Funcionarios de Administraciones Públicas) se diseña con el objetivo de evaluar las aptitudes, conocimientos y competencias de Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 64 la plantilla de funcionarios de cualquier administración pública. Esta evaluación se realiza a través de cuestionarios específicos. El sistema debe ser capaz de permitir la gestión del contenido de dichos cuestionarios y su organización en conocimientos, además de ser la plataforma por la que los empleados contesten a los cuestionarios y consulten el estado de sus evaluaciones. La Figura 15 presenta el diagrama general de casos de uso del sistema SIEFAP, que muestra los actores y los paquetes de casos de uso. Figura 15. Diagrama general de casos de uso de SIEFAP. CASOS DE USO REFERENTES A LA GESTIÓN DE EMPLEADOS Los empleados de la administración deben estar registrados en el sistema. De ellos se debe mantener su NIF, nombre, apellidos, la fecha de nacimiento, el sexo, el salario y el departamento y administración para la que trabaja. Un empleado puede encontrarse en estado “activo”, que le permite interactuar con el sistema, o en estado “inactivo”. En este estado, el empleado no puede interactuar con el sistema, pero la información relacionada no es eliminada. Cuando el empleado está activo, debe pertenecer a un departamento; por el contrario, cuando su estado es inactivo, no pertenece a ningún departamento. Por otra parte, el empleado puede realizar funciones de supervisor de cuestionarios y, para ello, debe considerarse “empleado supervisor”. También existe el rol de Responsable de la Administración, que se corresponde con un empleado que tiene los permisos del Usuario Administrador, pero sólo para la Administración en la que trabaja. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 65 La Figura 16 muestra el diagrama de casos de uso para la gestión de empleados. Figura 16. Diagrama de casos de uso para la gestión de empleados. Tabla 39. Caso de uso Alta de Empleado CASO DE USO 1. Alta de Empleado. ACTORES Usuario Administrador. PROPÓSITO Dar de alta un Empleado en el sistema. RESUMEN Se crea el empleado en el sistema con sus atributos de nombre, apellidos, NIF, fecha de nacimiento y sexo. PRECONDICIONES El Departamento debe existir en el sistema. POSTCONDICIONES Los datos relativos al Empleado quedan almacenados en el sistema. El usuario se crea en estado “Activo”: puede interactuar con el sistema. INCLUYE - Caso de Uso 2: Activar Empleado ENTRADAS El nombre, los apellidos, el NIF del empleado, la fecha de nacimiento, el sexo y el departamento en el que trabaja. SALIDAS Mensaje de confirmación de almacenamiento. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 66 Tabla 40. Caso de uso Activar Empleado CASO DE USO 2. Activar Empleado. ACTORES Usuario Administrador. PROPÓSITO Activar el empleado para que pueda interactuar con el sistema. RESUMEN Se pasa el empleado al estado “Activo”. PRECONDICIONES - El Empleado debe existir en el sistema y estar en estado “Inactivo”. o - Debe ocurrir el caso de uso “1 – Alta de Empleado”. - El Departamento debe existir en el sistema. POSTCONDICIONES - El Empleado pasa a estar en estado “Activo”, con lo que puede interactuar con el sistema. - El Empleado se relaciona con el Departamento de la entrada. ENTRADAS El Empleado y el Departamento. SALIDAS Mensaje de confirmación de la activación. Tabla 41. Caso de uso Desactivar Empleado CASO DE USO 3. Desactivar Empleado. ACTORES Usuario Administrador. PROPÓSITO Desactivar el empleado. RESUMEN Se pasa el Empleado al estado “Inactivo”. PRECONDICIONES - El Empleado debe existir en el sistema y estar en estado “Activo”. POSTCONDICIONES - El Empleado pasa a estar en estado “Inactivo”. - El Empleado deja de pertenecer a ningún Departamento. - El salario del empleado toma el valor 0. ENTRADAS El Empleado SALIDAS Mensaje de confirmación de la desactivación. Tabla 42. Caso de uso Baja de Empleado CASO DE USO 4. Baja de Empleado. ACTORES Usuario Administrador. PROPÓSITO Dar de baja un Empleado RESUMEN Dar de baja un Empleado del sistema, eliminando las relaciones que tenga con las demás entidades. PRECONDICIONES El Empleado debe existir en el sistema. POSTCONDICIONES - Los datos relativos al Empleado se eliminan del sistema. - Se eliminan los Cuestionarios realizados por el empleado, en caso de que los haya. - Se eliminan las Evaluaciones realizadas por el empleado, en caso de que las haya. ENTRADAS El Empleado. SALIDAS Mensaje de confirmación de la baja. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 67 Tabla 43. Caso de uso Modificación de detalles de Empleado CASO DE USO 5. Modificación de detalles de Empleado. ACTORES Usuario Administrador. PROPÓSITO Modificar los detalles del Empleado RESUMEN Modificación de alguno de los siguientes atributos, o de todos ellos: - Nombre - Apellidos - NIF - Fecha de nacimiento - Salario - Sexo PRECONDICIONES - El Empleado debe existir en el sistema. - El Empleado debe estar en estado “Activo”. POSTCONDICIONES Los atributos cambiados toman el nuevo valor. ENTRADAS - El empleado. - El nuevo valor de los atributos que se deseen cambiar. SALIDAS Mensaje de confirmación del cambio. Tabla 44. Caso de uso Convertir Empleado en Supervisor CASO DE USO 6. Convertir Empleado en Supervisor. ACTORES Usuario Administrador. PROPÓSITO Asignar a un empleado el papel de supervisor de Cuestionarios. RESUMEN Se asigna a un empleado el rol de supervisor de cuestionarios. PRECONDICIONES - El Empleado debe existir en el sistema y no debe ser ya supervisor. - El Empleado debe estar en estado “Activo” POSTCONDICIONES - El Empleado pasa a ser supervisor de Cuestionarios, con los permisos asociados que conlleva. - Se almacena la fecha en que se convierte en Supervisor. ENTRADAS El Empleado. SALIDAS Mensaje de confirmación de la asignación del rol. Tabla 45. Caso de uso Abandonar rol de Supervisor CASO DE USO 7. Abandonar rol de Supervisor. ACTORES Usuario Administrador. PROPÓSITO Desasignar a un Empleado Supervisor de este rol. RESUMEN El Empleado Supervisor deja de serlo. PRECONDICIONES El Empleado debe tener el rol de Supervisor. POSTCONDICIONES - El Empleado deja de ser Supervisor de Cuestionarios. - Se almacena la fecha en que abandona el rol de Supervisor. ENTRADAS El Empleado. SALIDAS Mensaje de confirmación de la desasignación del rol. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 68 Tabla 46. Caso de uso Convertir Empleado en Responsable CASO DE USO 8. Convertir Empleado en Responsable. ACTORES Usuario Administrador. PROPÓSITO Asignar a un empleado el papel de Responsable de la Administración. RESUMEN Se asigna a un empleado el rol de responsable de la administración. PRECONDICIONES - El Empleado debe existir en el sistema y no debe ser ya Responsable. - El Empleado debe estar en estado “Activo” POSTCONDICIONES - El Empleado pasa a ser Responsable de la Administración, con los permisos asociados que conlleva. ENTRADAS El Empleado. SALIDAS Mensaje de confirmación de la asignación del rol. Tabla 47. Caso de uso Abandonar rol de Responsable CASO DE USO 9. Abandonar rol de Responsable. ACTORES Usuario Administrador. PROPÓSITO Desasignar a un Responsable de Administración de este rol. RESUMEN El Responsable de Administración deja de serlo. PRECONDICIONES El Empleado debe tener el rol de Responsable. POSTCONDICIONES - El Empleado deja de ser Responsable de Administración. ENTRADAS El Empleado. SALIDAS Mensaje de confirmación de la desasignación del rol. CASOS DE USO REFERENTES A LA GESTIÓN DE USUARIOS Además de los empleados de la Administración, el sistema debe tener otros roles de Usuario con ciertos permisos para poder realizar acciones de mantenimiento del sistema o de mantenimiento de contenidos de las evaluaciones. Para ello, se definen los roles de Usuario Administrador y Usuario Editor, y los casos de uso de la gestión de estos roles se presentan en la Figura 17. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 69 Figura 17. Diagrama de casos de uso para la gestión de usuarios. Tabla 48. Caso de uso Crear Usuario CASO DE USO 10. Crear Usuario. ACTORES Usuario Administrador. PROPÓSITO Crear un nuevo Usuario del sistema. RESUMEN Se crea un nuevo Usuario en el sistema. PRECONDICIONES El nombre de usuario debe ser único. POSTCONDICIONES El nuevo usuario queda registrado en el sistema. ENTRADAS El nombre y la contraseña del usuario. SALIDAS Mensaje de confirmación de almacenamiento. Tabla 49. Caso de uso Borrar Usuario CASO DE USO 11. Borrar Usuario. ACTORES Usuario Administrador. PROPÓSITO Eliminar un Usuario del sistema. RESUMEN Se elimina un Usuario del sistema. PRECONDICIONES El Usuario debe existir en el sistema. POSTCONDICIONES El Usuario se elimina del sistema ENTRADAS El Usuario. SALIDAS Mensaje de confirmación del borrado. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 70 Tabla 50. Caso de uso Convertir usuario en Administrador CASO DE USO 12. Convertir Usuario en Administrador. ACTORES Usuario Administrador. PROPÓSITO Asignar a un Usuario existente en el sistema el rol de Administrador. RESUMEN Se asigna a un Usuario el papel de Administrador. PRECONDICIONES El Usuario debe existir en el sistema. POSTCONDICIONES El usuario pasa a ser Administrador del sistema, con los permisos asociados que conlleva. ENTRADAS El Usuario. SALIDAS Mensaje de confirmación de la asignación del rol. Tabla 51. Caso de uso Abandonar rol de Administrador CASO DE USO 13. Abandonar rol de Administrador. ACTORES Usuario Administrador. PROPÓSITO Desasignar a un Usuario Administrador de este rol. RESUMEN El Usuario Administrador deja de serlo. PRECONDICIONES El Usuario debe existir en el sistema. POSTCONDICIONES El Usuario deja de ser Administrador del sistema. ENTRADAS El nombre del usuario. SALIDAS Mensaje de confirmación de la desasignación del rol. Tabla 52. Caso de uso Convertir Usuario en Editor CASO DE USO 14. Convertir Usuario en Editor. ACTORES Usuario Administrador. PROPÓSITO Asignar a un Usuario existente en el sistema el rol de Editor. RESUMEN Se asigna a un Usuario el papel de Editor. PRECONDICIONES El Usuario debe existir en el sistema. POSTCONDICIONES El usuario pasa a ser Editor, con los permisos asociados que conlleva. ENTRADAS El nombre del Usuario. SALIDAS Mensaje de confirmación de la asignación del rol. Tabla 53. Caso de uso Abandonar rol de Editor CASO DE USO 15. Abandonar rol de Editor. ACTORES Usuario Administrador PROPÓSITO Desasignar a un Usuario Administrador de este rol. RESUMEN El Usuario Editor deja de serlo. PRECONDICIONES El Usuario debe existir en el sistema. POSTCONDICIONES El Usuario deja de ser Editor. ENTRADAS El nombre del usuario. SALIDAS Mensaje de confirmación de la desasignación del rol. CASOS DE USO REFERENTES A LA GESTIÓN DE DEPARTAMENTOS Los empleados están asignados a Departamentos de la Administración. Cada Departamento debe pertenecer a una Administración. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 71 De los Departamentos se debe guardar información de su nombre, del número de empleados que lo forman, el presupuesto que dispone para recursos humanos y el presupuesto gastado en recursos humanos. La Figura 18 presenta los casos de uso de la gestión de departamentos. Figura 18. Diagrama de casos de uso para la gestión de departamentos. Tabla 54. Caso de uso Alta de Departamento CASO DE USO 16. Alta de Departamento. ACTORES Usuario Administrador. PROPÓSITO Dar de alta un Departamento en el sistema. RESUMEN Se crea un departamento en el sistema con su nombre y la administración a la que pertenece. PRECONDICIONES Debe existir la Administración a la que pertenece. POSTCONDICIONES Los datos relativos al Departamento quedan almacenados en el sistema. ENTRADAS El nombre del departamento y la Administración a la que pertenece. SALIDAS Mensaje de confirmación de almacenamiento. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 72 Tabla 55. Caso de uso Baja de Departamento CASO DE USO 17. Baja de Departamento. ACTORES Usuario Administrador. PROPÓSITO Dar de baja un Departamento RESUMEN Se elimina el Departamento del sistema. PRECONDICIONES - El Departamento debe existir en el sistema. - El Departamento no puede tener empleados en Estado “Activo”. POSTCONDICIONES Los datos relativos al Departamento se eliminan del sistema. ENTRADAS El Departamento. SALIDAS Mensaje de confirmación de la baja. Tabla 56. Caso de uso Modificación del nombre del Departamento CASO DE USO 18. Modificación del nombre del Departamento. ACTORES Usuario Administrador. PROPÓSITO Cambiar el nombre del Departamento por uno nuevo. RESUMEN Se modifica el nombre del Departamento. PRECONDICIONES El Departamento debe existir en el sistema. POSTCONDICIONES El nombre del Departamento pasa a tomar el nuevo valor. ENTRADAS El Departamento y el nuevo nombre. SALIDAS Mensaje de confirmación del cambio. Tabla 57. Caso de uso Asignar presupuesto a Departamento CASO DE USO 19. Asignar presupuesto a Departamento. ACTORES Usuario Administrador. PROPÓSITO Asignación del presupuesto del Departamento. RESUMEN Se le asigna presupuesto al Departamento. PRECONDICIONES - El Departamento debe existir en el Sistema. - El presupuesto debe ser mayor que cero. POSTCONDICIONES El presupuesto del Departamento toma el valor que se le asigna. ENTRADAS El Departamento y el presupuesto. SALIDAS Mensaje de confirmación de la asignación. Tabla 58. Caso de uso Consulta de presupuesto del Departamento CASO DE USO 20. Consulta de presupuesto del Departamento. ACTORES Usuario Administrador. PROPÓSITO Consultar el presupuesto que tiene asignado y el dispuesto por el Departamento. RESUMEN Se consulta el presupuesto asignado y el dispuesto para el área de recursos humanos del departamento. PRECONDICIONES El Departamento debe existir en el sistema. POSTCONDICIONES Ninguna ENTRADAS El Departamento SALIDAS El presupuesto asignado y el presupuesto dispuesto. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 79 Tabla 71. Caso de uso Modificar Pregunta CASO DE USO 33. Modificar Pregunta. ACTORES Usuario Editor. PROPÓSITO Modificar una pregunta existente. RESUMEN La modificación de la pregunta tiene cuatro opciones. 1. Modificar el enunciado de la Pregunta. 2. Modificar el enunciado y/o puntuación de una Respuesta asociada. 3. Añadir una Opción de Respuesta. 4. Eliminar una Opción de Respuesta PRECONDICIONES - La Pregunta debe existir en el sistema. - La Pregunta no puede estar siendo utilizada en Cuestionarios. - Para el caso 1 y 3: La pregunta debe existir en el sistema. - Para el caso 2 y 4: La pregunta debe existir en el sistema y tener al menos una opción de Respuesta asociada. POSTCONDICIONES - Para el caso 1: El enunciado de la pregunta toma el nuevo valor. - Para el caso 2: El enunciado y la puntuación de la opción de Respuesta toman los nuevos valores. - Para el caso 3: Se añade una nueva opción de respuesta. - Para el caso 4: La opción de Respuesta se elimina. EXTENSIONES - Para el caso 2 -> Caso de Uso 33: Modificar Respuesta. - Para el caso 3 -> Caso de Uso 32: Crear Respuesta. - Para el caso 4 -> Caso de Uso 34: Eliminar Respuesta. ENTRADAS - Para el caso 1: La pregunta y su nuevo enunciado. - Para el caso 2: La pregunta, la opción de Respuesta, el texto y la puntuación de la Respuesta. - Para el caso 3: La pregunta y la nueva opción de Respuesta. - Para el caso 4: La pregunta y la opción de Respuesta. SALIDAS Ninguna. Tabla 72. Caso de uso Crear respuesta CASO DE USO 34. Crear Respuesta. ACTORES Usuario Editor. PROPÓSITO Crear una Opción de respuesta asociada a una pregunta. RESUMEN Para una pregunta, se crea una opción de respuesta con su texto y puntuación. PRECONDICIONES - La pregunta a la que se le va a asignar no puede estar siendo utilizada en Cuestionarios. - Debe ocurrir el caso de uso “32-Crear Pregunta” o el “33Modificar Pregunta” POSTCONDICIONES La opción de respuesta queda almacenada con su texto y puntuación y se le asigna a la pregunta. ENTRADAS La Pregunta, el texto y la puntuación de la Respuesta. SALIDAS Ninguna. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 80 Tabla 73. Caso de uso Modificar Respuesta CASO DE USO 35. Modificar Respuesta. ACTORES Usuario Editor. PROPÓSITO Modificar una Opción de respuesta asociada a una pregunta. RESUMEN Se modifica una opción de respuesta de una pregunta. PRECONDICIONES - Debe ocurrir el caso de uso “33-Modificar Pregunta”. - La Respuesta debe existir y estar asignada a la Pregunta. POSTCONDICIONES La opción de respuesta queda almacenada con su nuevo texto su nueva puntuación. ENTRADAS La Pregunta, la Respuesta, el nuevo texto y la nueva puntuación de la Respuesta. SALIDAS Ninguna. Tabla 74. Caso de uso Eliminar Respuesta CASO DE USO 36. Eliminar Respuesta. ACTORES Usuario Editor. PROPÓSITO Eliminar una Opción de respuesta asociada a una pregunta. RESUMEN Se elimina una opción de respuesta ya asociada a la pregunta. PRECONDICIONES - Debe ocurrir el caso de uso “33-Modificar Pregunta”. - La Respuesta debe existir y estar asignada a la Pregunta. - La Pregunta debe tener más de una Respuesta asociada; no se puede eliminar la Respuesta si ésta es la única. POSTCONDICIONES La opción de respuesta se elimina del sistema. ENTRADAS La Pregunta y la Respuesta. SALIDAS Ninguna. Tabla 75. Caso de uso Asignar Pregunta a Conocimiento CASO DE USO 37. Asignar Pregunta a Conocimiento. ACTORES Usuarios Editor o Administrador PROPÓSITO Asignar una pregunta a un Conocimiento RESUMEN Se asigna una pregunta a un Conocimiento existente. PRECONDICIONES - El Conocimiento debe existir en el sistema. - La Pregunta debe existir en el sistema o debe ocurrir el caso de uso “32 – Crear Pregunta”. POSTCONDICIONES La pregunta queda asociada al Conocimiento. ENTRADAS La Pregunta y el Conocimiento. SALIDAS Mensaje de confirmación de la asignación. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 81 Tabla 76. Caso de uso Desasignar Pregunta de Conocimiento CASO DE USO 38. Desasignar Pregunta de Conocimiento ACTORES Usuarios Editor o Administrador PROPÓSITO Desasignar una pregunta de un Conocimiento RESUMEN La pregunta deja de estar relacionada con el conocimiento. PRECONDICIONES - El Conocimiento y la Pregunta deben estar relacionados. - La Pregunta debe estar relacionada con más de un Conocimiento. - La pregunta no puede estar siendo utilizada en Plantillas de Cuestionario del mismo Conocimiento del que se desea desasignar. POSTCONDICIONES Se elimina la relación entre la Pregunta y el Conocimiento ENTRADAS La Pregunta y el Conocimiento. SALIDAS Ninguna Por su parte, las “Plantillas de Cuestionario” deben tener un nombre, una descripción y un estado, que indica si la plantilla ya puede ser utilizada en cuestionarios. Cuando la plantilla esté lista para usarse, debe tener también el número de preguntas que la forman y la puntuación máxima que se puede obtener en ella. La creación de Plantillas de Cuestionario implica asociarlas a un Conocimiento existente y que se le añadan Preguntas ya creadas en el sistema. La modificación de una Plantilla de Cuestionario debe permitir que se le añadan o eliminen Preguntas. La Figura 22 presenta los casos de uso de la gestión de plantillas de cuestionario. Las Preguntas y las Plantillas de Cuestionario se relacionan con los Conocimientos. Mientras que una Pregunta puede pertenecer a uno o más Conocimientos, las Plantillas de Cuestionario deben pertenecer siempre sólo a uno, aunque éste pueda variar. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 82 Figura 22. Diagrama de casos de uso para la gestión de preguntas. Tabla 77. Caso de uso Crear Plantilla de Cuestionario CASO DE USO 39. Crear Plantilla de Cuestionario. ACTORES Usuario Editor. PROPÓSITO Crear una Plantilla de Cuestionario. RESUMEN Se crea una Plantilla de Cuestionario con su nombre, su descripción y las preguntas que la componen. PRECONDICIONES Ninguna. POSTCONDICIONES - Los datos relativos a la Plantilla de Cuestionario quedan almacenados en el sistema. - La Plantilla de Cuestionario queda asociada a un Conocimiento. INCLUYE - Caso de Uso 41: Asignar Pregunta a Plantilla de Cuestionario. - Caso de Uso 43: Asignar Plantilla de Cuestionario a Conocimiento. ENTRADAS El nombre y la descripción de la Plantilla de Cuestionario. SALIDAS Mensaje de confirmación de almacenamiento. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 83 Tabla 78. Caso de uso Modificar Plantilla de Cuestionario CASO DE USO 40. Modificar Plantilla de Cuestionario. ACTORES Usuario Editor. PROPÓSITO Modificar una Plantilla de Cuestionario existente. RESUMEN Hay cuatro tipos de modificación de la Plantilla de Cuestionario: 1. Modificación del nombre y/o descripción. 2. Inserción de Preguntas. 3. Eliminación de Preguntas. 4. Cambio de valor de la Pregunta. PRECONDICIONES - La Plantilla de Cuestionario debe existir en el sistema. - La Plantilla no puede estar siendo utilizada en Cuestionarios. - Para el caso 1: La Plantilla de Cuestionario debe existir en el sistema. - Para el caso 2: La Plantilla de Cuestionario y la Pregunta a insertar deben existir en el sistema y estar asociadas al mismo Conocimiento. - Para los casos 3 y 4: La Pregunta debe pertenecer a la Plantilla de Cuestionario. POSTCONDICIONES - Para el caso 1: El nombre de la Plantilla de Cuestionario toma el nuevo valor. - Para el caso 2: La Pregunta queda asociada a la Plantilla de Cuestionario. - Para el caso 3: La Pregunta deja de estar asociada con la Plantilla de Cuestionario. - Para el caso 4: La Pregunta toma el nuevo valor en la Plantilla de Cuestionario EXTENSIONES - Para el caso 2 -> Caso de Uso 39: Asignar Pregunta a Plantilla de Cuestionario. - Para el caso 3 -> Caso de Uso 40: Desasignar Pregunta de Plantilla de Cuestionario. - Para el caso 4 -> Caso de Uso 43: Cambiar valor de Pregunta ENTRADAS - Para el caso 1: La Plantilla de Cuestionario, el nuevo nombre y la nueva descripción. - Para los casos 2 y 3: La Plantilla de Cuestionario y la Pregunta. - Para el caso 4: La Plantilla de Cuestionario, la Pregunta y el nuevo valor SALIDAS Ninguna Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 84 Tabla 79. Caso de uso Asignar Pregunta a Plantilla de Cuestionario CASO DE USO 41. Asignar Pregunta a Plantilla de Cuestionario. ACTORES Usuario Editor PROPÓSITO Añadir una Pregunta a una Plantilla de Cuestionario y asignarle valor. RESUMEN Se añade la pregunta seleccionada a la Plantilla de Cuestionario. PRECONDICIONES - La Pregunta debe existir en el sistema. - El valor de la Pregunta en la Plantilla de Cuestionario no puede ser negativo. - La Pregunta debe estar asociada al Conocimiento de la Plantilla de Cuestionario. - Debe ocurrir el caso de uso “39-Crear Plantilla de Cuestionario” o el “40-Modificar Plantilla de Cuestionario” POSTCONDICIONES La Pregunta queda asociada a la Plantilla de Cuestionario ENTRADAS La Pregunta, la Plantilla de Cuestionario y el valor. SALIDAS Ninguna. Tabla 80. Caso de uso Desasignar Pregunta de Plantilla de Cuestionario CASO DE USO 42. Desasignar Pregunta de Plantilla de Cuestionario. ACTORES Usuario Editor PROPÓSITO Eliminar una Pregunta de una Plantilla de Cuestionario. RESUMEN La Pregunta seleccionada se elimina de la Plantilla de Cuestionario. PRECONDICIONES - La Pregunta debe existir en el sistema y estar relacionada con la Plantilla de Cuestionario. - Debe ocurrir el Caso de Uso “40-Modificar Plantilla de Cuestionario”. POSTCONDICIONES Se elimina la Pregunta de la Plantilla de Cuestionario. ENTRADAS La Pregunta y la Plantilla de Cuestionario. SALIDAS Ninguna. Tabla 81. Caso de uso Cambiar valor de Pregunta CASO DE USO 43. Cambiar valor de Pregunta ACTORES Usuario Editor PROPÓSITO Cambiar el valor de la Pregunta dentro de la Plantilla de Cuestionario RESUMEN Se cambia el valor de la Pregunta para la Plantilla de Cuestionario. PRECONDICIONES - La Pregunta debe existir en el sistema y estar relacionada con la Plantilla de Cuestionario. - Debe ocurrir el Caso de Uso “40-Modificar Plantilla de Cuestionario”. POSTCONDICIONES La Pregunta toma el nuevo valor para la Plantilla de Cuestionario seleccionada. ENTRADAS La Pregunta, la Plantilla de Cuestionario y el nuevo valor. SALIDAS Ninguna. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 85 Tabla 82. Caso de uso Asignar Plantilla de cuestionario a Conocimiento CASO DE USO 44. Asignar Plantilla de cuestionario a Conocimiento ACTORES Usuarios Editor o Administrador PROPÓSITO Asignar una Plantilla de cuestionario a un nuevo Conocimiento RESUMEN Se asigna una Plantilla de Cuestionario a un Conocimiento existente. Si ya estaba asociada a un Conocimiento, se elimina la relación anterior. PRECONDICIONES - El Conocimiento debe existir en el sistema. - La Plantilla de Cuestionario no debe tener Preguntas o - Las Preguntas deben estar asociadas al nuevo Conocimiento. - La Plantilla de Cuestionario debe existir en el sistema o debe ocurrir el caso de uso “39 – Crear Plantilla de Cuestionario”. POSTCONDICIONES La Plantilla de cuestionario queda asociada al Conocimiento. ENTRADAS La Plantilla de cuestionario y el nuevo Conocimiento. SALIDAS Ninguna. CASOS DE USO REFERENTES A LA GESTIÓN DE EVALUACIONES Las Evaluaciones que se realizan a los empleados se dividen en Evaluaciones de Conocimientos. Cada Evaluación se asigna a un Empleado y se debe guardar la fecha de creación, una descripción y el número de puntos totales de la evaluación. La evaluación también tiene tres estados: “Edición”, “Activa”, cuando el empleado puede realizarla; y “Terminada”, cuando está cerrada y sólo guarda datos a nivel informativo. Cuando la evaluación está “Terminada”, se debe guardar su fecha de finalización y el número de puntos obtenidos por el empleado. Las Evaluaciones de Conocimiento que componen la Evaluación global, por su parte, tienen un número de puntos y la suma de ellos debe ser igual a la de la Evaluación global. Los Cuestionarios se asignan sólo a las Evaluaciones de Conocimiento y, una vez realizados, otorgan al Empleado un nivel determinado en el Conocimiento examinado. Este nivel se convierte en un número de puntos obtenidos. La suma de los puntos obtenidos en todas las Evaluaciones de Conocimiento se suman para formar la puntuación obtenida en la Evaluación global. La Figura 23 muestra los casos de uso para la gestión de evaluaciones. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 86 Tabla 83. Caso de uso Crear Evaluación CASO DE USO 45. Crear Evaluación. ACTORES Usuario Administrador. PROPÓSITO Crear una Evaluación asignada a un empleado. RESUMEN Se crea una Evaluación con un número de puntos totales y se asigna para que la realice un Empleado. PRECONDICIONES El Empleado debe existir en el sistema. POSTCONDICIONES - Los datos relativos a la Evaluación quedan almacenados en el sistema. - La evaluación queda en estado de “Edición”. ENTRADAS El Empleado, la fecha de creación, la descripción y los puntos totales. SALIDAS Mensaje de confirmación de la creación. Figura 23. Diagrama de casos de uso para la gestión de evaluaciones. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 87 Tabla 84. Caso de uso Crear Evacuación de Conocimiento CASO DE USO 46. Crear Evaluación de Conocimiento. ACTORES Usuario Administrador. PROPÓSITO Crear una Evaluación de Conocimiento. RESUMEN Se crea una Evaluación de Conocimiento y se le asigna a una Evaluación global. PRECONDICIONES - El Conocimiento debe existir en el sistema. - El Empleado debe existir en el sistema. - La Evaluación global a la que se asigna debe existir en el sistema. - La Evaluación global debe estar en estado de “Edición”. - Si se la Evaluación creada es de un Subconocimiento, el Superconocimiento relacionado debe existir en la Evaluación Global. - El Empleado y el Conocimiento deben pertenecer a la misma Administración - El Empleado debe ser el mismo que el de la Evaluación global a la que se asocia. - El porcentaje de puntos no puede ser inferior a cero ni superior a 100. POSTCONDICIONES - Los datos relativos a la Evaluación de Conocimiento quedan almacenados en el sistema. - La Evaluación de Conocimiento se asigna a una Evaluación global existente. ENTRADAS El Conocimiento, la Evaluación global, el Empleado y el porcentaje de puntos sobre la Evaluación global o de su Superconocimiento. SALIDAS Mensaje de confirmación de almacenamiento. Tabla 85. Caso de uso Editar Evaluación CASO DE USO 47. Editar Evaluación. ACTORES Usuario Administrador. PROPÓSITO Editar una Evaluación. RESUMEN Cambiar los puntos totales o la descripción de una Evaluación global. PRECONDICIONES - La Evaluación debe existir en el sistema. - Sólo se puede modificar en estado de Edición. POSTCONDICIONES - Los puntos totales y/o la descripción toman el nuevo valor. ENTRADAS - La Evaluación, los puntos totales y la descripción. SALIDAS Ninguna. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 88 Tabla 86. Caso de uso Cambiar estado CASO DE USO 48. Cambiar estado. ACTORES Usuario Administrador. PROPÓSITO Cambiar el estado de una Evaluación. RESUMEN Se cambia el estado de una Evaluación. PRECONDICIONES - La Evaluación debe existir en el sistema. - Los cambios de estado aceptados son “Edición” -> “Activa” -> “Terminada”. - Si se cambia a estado Activo, la suma del porcentaje de puntos de las Evaluaciones de Conocimiento que forman una Evaluación global debe ser 100. POSTCONDICIONES - La Evaluación cambia de estado. - Si se cambia a “Terminada”, se debe almacenar la fecha de finalización y se debe calcular el número de puntos obtenidos. ENTRADAS La Evaluación. SALIDAS Ninguna. Tabla 87. Caso de uso Editar Evacuación de Conocimiento CASO DE USO 49. Editar Evaluación de Conocimiento. ACTORES Usuario Administrador. PROPÓSITO Editar el porcentaje de puntos correspondiente a la Evaluación de Conocimiento. RESUMEN Se edita el porcentaje de puntos correspondientes a la Evaluación de Conocimiento. PRECONDICIONES - La Evaluación de Conocimiento debe existir en el sistema. - La Evaluación global asociada debe estar en estado de “Edición”. POSTCONDICIONES El porcentaje de puntos toma el nuevo valor. ENTRADAS El porcentaje de puntos y la Evaluación de Conocimiento. SALIDAS Ninguna. Tabla 88. Caso de uso Eliminar Evaluación CASO DE USO 50. Eliminar Evaluación. ACTORES Usuario Administrador. PROPÓSITO Eliminar una Evaluación del sistema. RESUMEN Se elimina una evaluación del sistema. PRECONDICIONES - La Evaluación debe estar en estado de “Edición”. o - Debe producirse como consecuencia del caso de uso “4-Baja de Empleado”. POSTCONDICIONES - La Evaluación deja de existir en el sistema y se eliminan las relaciones que tenga con el Empleado y/o Evaluaciones de Conocimiento. ENTRADAS La Evaluación. SALIDAS Mensaje de confirmación del borrado. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 95 Tabla 99. Caso de uso Responder Pregunta de Cuestionario CASO DE USO 61. Responder Pregunta de Cuestionario. ACTORES Empleado. PROPÓSITO El Empleado responde a una Pregunta del Cuestionario. RESUMEN El Empleado puede: 1. Seleccionar la opción de respuesta que crea más conveniente de la pregunta que aparece en el cuestionario. 2. Cambiar una opción de respuesta elegida previamente. 3. Borrar una opción de respuesta elegida previamente. PRECONDICIONES - Debe ocurrir el caso de uso “59-Responder Cuestionario”. - El Cuestionario debe estar en estado “En respuesta”. - Para los casos 2 y 3, además, debe haber una opción de respuesta seleccionada. POSTCONDICIONES En los casos 1 y 2, se selecciona la opción de respuesta para la pregunta y el empleado. En el caso 3, la opción de respuesta deja de estar seleccionada. ENTRADAS El Cuestionario, la Respuesta y la Pregunta. SALIDAS Ninguna. Tabla 100. Caso de uso Terminar Cuestionario CASO DE USO 62. Terminar Cuestionario. ACTORES Empleado. PROPÓSITO Marcar el Cuestionario como terminado. RESUMEN El Empleado finaliza el Cuestionario. PRECONDICIONES - Debe ocurrir el caso de uso “59-Responder Cuestionario”. - El Cuestionario debe estar en estado “En respuesta”. - Todas las Preguntas del Cuestionario deben estar respondidas. POSTCONDICIONES - El Cuestionario pasa a estado “Terminado”. - Se almacena la fecha de finalización del cuestionario. ENTRADAS El Cuestionario. SALIDAS Un mensaje que confirma que el cuestionario está finalizado. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 96 Tabla 101. Caso de uso Consultar Detalles Cuestionario CASO DE USO 63. Consultar Detalles Cuestionario. ACTORES Empleado, Empleado Supervisor y Usuario Administrador. PROPÓSITO Consultar los detalles del Cuestionario. RESUMEN El Empleado que responde un Cuestionario, el Empleado Supervisor y el Usuario Administrador pueden consultar la información relativa al mismo. PRECONDICIONES - El Empleado debe ser el encargado de contestar el Cuestionario que desea consultar. o - El Empleado Supervisor debe ser el encargado de validar el Cuestionario. POSTCONDICIONES Ninguna. ENTRADAS El Cuestionario que se desea consultar. SALIDAS - Las fechas de comienzo, corrección, validación y fin del Cuestionario. - La Plantilla del Cuestionario. - Las Respuestas dadas a las Preguntas que forman la Plantilla del Cuestionario y los comentarios del Supervisor a esas Respuestas. - El peso del cuestionario dentro de la Evaluación del Conocimiento. - El estado del cuestionario (En Edición, Preparado, En respuesta, Finalizado y Validado). - El porcentaje de Puntuación obtenida y los puntos correspondientes obtenidos. Tabla 102. Caso de uso Consultar Detalles de Evaluación CASO DE USO 64. Consultar Detalles de Evaluación. ACTORES Empleado y Usuario Administrador PROPÓSITO Consultar los detalles de la Evaluación RESUMEN El Empleado asignado a la Evaluación y el Usuario Administrador pueden consultar los detalles de la misma. PRECONDICIONES El Empleado debe estar asignado a la Evaluación que desea consultar. POSTCONDICIONES Ninguna. ENTRADAS La Evaluación que se desea consultar. SALIDAS - Las fechas de creación y finalización de la Evaluación y su estado (edición, en curso, finalizada). - La descripción de la Evaluación. - Los puntos totales y los puntos obtenidos por el Empleado. - Los Conocimientos en los que se divide y la información relativa a la puntuación de cada uno de ellos. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 97 Tabla 103. Caso de uso Consultar Detalles de Evaluación Del Conocimiento CASO DE USO 65. Consultar Detalles de Evaluación del Conocimiento. ACTORES Empleado, Empleado Supervisor y Usuario Administrador PROPÓSITO Consultar los detalles de la Evaluación del Conocimiento RESUMEN El Empleado asignado a la Evaluación de Conocimiento, el Empleado Supervisor de los Cuestionarios de ese Conocimiento y el Usuario Administrador pueden consultar los detalles de la misma. PRECONDICIONES - El Empleado debe estar asignado a la Evaluación de Conocimiento que desea consultar. - El Empleado Supervisor debe estar relacionado con alguno de los Cuestionarios de la Evaluación de Conocimiento. POSTCONDICIONES Ninguna. ENTRADAS La Evaluación de Conocimiento que se desea consultar. SALIDAS - Los puntos totales de la evaluación del conocimiento y los obtenidos por el empleado. - El número de cuestionarios asignados a la Evaluación del Conocimiento y los que están terminados, validados o en curso. - El porcentaje de puntación de la Evaluación global - El nivel obtenido por el empleado en la Evaluación del Conocimiento cuando está completa. - Los Conocimientos en los que se divide, si los hay. - Los Cuestionarios que forman la Evaluación de Conocimiento. CASOS DE USO REFERENTES A LA VALIDACIÓN DE CUESTIONARIOS En el sistema existe la Figura 26 del Empleado Supervisor, que es el que se asigna a un Cuestionario y tiene la misión de validar o rechazar los cuestionarios que ha realizado otro empleado. La Figura 26 presenta los casos de uso de la validación de cuestionarios. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 98 Figura 26. Diagrama de casos de uso para validación de cuestionarios. Tabla 104. Caso de uso Validar Cuestionario CASO DE USO 66. Validar Cuestionario. ACTORES Empleado Supervisor PROPÓSITO Validar un Cuestionario terminado RESUMEN El Empleado supervisor valida un cuestionario terminado. PRECONDICIONES - El Empleado Supervisor debe estar relacionado con el cuestionario. - El Cuestionario debe estar en estado “Terminado”. POSTCONDICIONES - El Cuestionario pasa a estado “Validado” - Los puntos obtenidos por el empleado son tenidos en cuenta para la evaluación. - Se almacena la fecha de validación ENTRADAS El Cuestionario. SALIDAS Mensaje de confirmación de la validación. Tabla 105. Caso de uso Comenzar Respuesta de Empleado CASO DE USO 67. Comentar Respuesta de Empleado. ACTORES Empleado Supervisor PROPÓSITO Insertar un comentario a una Respuesta de Empleado. RESUMEN El Empleado supervisor inserta un comentario a una Respuesta del Empleado. PRECONDICIONES - El Empleado Supervisor debe estar relacionado con el cuestionario. - El Cuestionario debe estar en estado “Terminado”. POSTCONDICIONES Se inserta el comentario a la Respuesta de Empleado. ENTRADAS La Respuesta de Empleado y el comentario. SALIDAS Ninguna. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 99 Tabla 106. Caso de uso Solicitar corrección Cuestionario CASO DE USO 68. Solicitar corrección Cuestionario. ACTORES Empleado Supervisor. PROPÓSITO Solicitar la corrección de un Cuestionario por parte del Empleado que lo ha realizado. RESUMEN El Empleado Supervisor sugiere al Empleado que corrija el cuestionario porque las respuestas no le parecen apropiadas. PRECONDICIONES - El Empleado Supervisor debe estar relacionado con el cuestionario. - El Cuestionario debe estar en estado “Terminado”. POSTCONDICIONES - El Cuestionario pasa a estado “Preparado”. - Se almacena la fecha de la solicitud de revisión. ENTRADAS El cuestionario. SALIDAS Mensaje de confirmación de la solicitud de revisión. 4.3. Mapeo Casos de Uso – Modelo En el método de desarrollo OO-Method, la transformación entre el modelo de Requisitos y el Modelo conceptual la realiza el analista de forma manual. En el caso que afecta a este PFC, el modelo de Requisitos son los Casos de Uso del apartado 4.2. Especificación de Requisitos. En esta sección se explica el mapeo entre los Casos de Uso y sus entidades en el Modelo Conceptual de Olivanova. En primer lugar, se muestran los esquemas del mapeo de los dos Sistemas de Información que se construyen en este Proyecto. En estos esquemas se muestran los escenarios de Casos de Uso y las clases que del Modelo de Objetos de Olivanova que participan en su diseño. En la Figura 27 se muestra el correspondiente a la aplicación SIESMACRe, mientras que en la Figura 28 está representado el mapeo del sistema SIEFAP. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 100 Figura 27. Esquema de mapeo SIESMACRe. Figura 28. Esquema de mapeo SIEFAP. Después de una visión general, se detalla el mapeo entre casos de uso y las herramientas de diseño disponibles en Olivanova. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 101 4.3.1 Mapeo de SIESMACRe Para la aplicación SIESMACRE (Sistema de Información de Estimación del Salario Mediante el Análisis de Conceptos Retributivos), se diseñan nueve clases: Categoria, ComplemetoDestino, ComunidadAutonoma, Puesto, NHabitantes, Plantilla, Calculadora y AdministradorSalarios. La clase AdministradorSalarios se corresponde con el agente Administrador de los casos de uso. En la Figura 29 se observan las relaciones del modelo de Clases. Cada clase gestiona la información de un concepto salarial y todas ellas se relacionan con la clase Calculadora. La clase Calculadora es la que presenta el informe a partir del valor de los atributos de las instancias seleccionadas de sus clases relacionadas. Figura 29. Modelo de objetos de SIESMACRe. A continuación, se realiza un mapeo entre la Especificación de Requisitos y el Modelo Conceptual. Este mapeo se organiza por los mismos conceptos que los casos de uso presentados en la sección 4.2. Especificación de Requisitos. Así, se presenta la clase, los atributos y los servicios que se diseñan en el modelo para cumplir con las exigencias de la aplicación deseada. Los servicios diseñados son eventos, que aparecen en minúsculas en el documento o transacciones, que aparecen en mayúsculas. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 102 Gestión de Categorías El modelado de los Casos de Uso referentes a la Gestión de Categorías se realiza mediante la clase Categoria. En la siguiente tabla se detallan los atributos y servicios de esta clase y se expone la correspondencia de éstos con los casos de uso. Tabla 107. Correspondencias entre clase Categoria y Gestión de Categorías CLASE Categoria ATRIBUTOS - Tipo - Atributo identificador de la Categoría; tipo de dato String de dos posiciones. - SalarioMensual - Atributo variable; tipo de dato Real. - SalarioAnual - Atributo derivado a partir del SalarioMensual; tipo de dato Real SERVICIOS Y SUS CORRESPONDENCIAS crear_categoria 1. Alta de Categoría borrar_categoria 2. Baja de Categoría modificar_salario 3. Modificación de salario de Categoría actualizar_salario 4. Actualización de salario de Categoría consultar_salarios 5. Consulta de salario de Categoría En los casos de uso, se especifica que el salario anual se calcula en base al mensual. Este cálculo se establece como una Derivación en la clase Categoria en la que el atributo SalarioAnual es 12 veces el atributo SalarioMensual. A su vez, el atributo SalarioMensual tiene una restricción que impide que sea negativo, que es la precondición de 1.-Alta de Categoría. Para representar que el porcentaje de cambio de 4.-Actualización de salario de Categoría. debe ser mayor que cero, se añade una precondición al servicio actualizar_salario. El agente que tiene visibilidad sobre los servicios de la clase es AdministradorSalarios, que puede acceder a su ejecución a través de la Unidad de Interacción de Instancia (IIU, por sus siglas en inglés) Categoria o de la Unidad de Interacción de Población (PIU) Categoria. Gestión de Complemento de Destino El modelado de los Casos de Uso referentes a la Gestión de Complementos de Destino se realiza mediante la clase ComplementoDestino. En la siguiente tabla se detallan los atributos y servicios de esta clase y se expone la correspondencia de éstos con los casos de uso. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 103 Tabla 108. Correspondencias entre clase ComplementoDestino y Gestión de Complementos de Destino CLASE ComplementoDestino ATRIBUTOS - Id_ComplementoDestino - Atributo identificador del Complemento de destino; tipo de dato Natural. - ValorMensual - Atributo variable; tipo de dato Real. - ValorAnual - Atributo derivado a partir del ValorMensual; tipo de dato Real SERVICIOS Y SUS CORRESPONDENCIAS crear_complementoDestino 6. Alta de Complemento de Destino borrar_complementoDestino 7. Baja de Complemento de Destino modificar_valor 8. Modificación de valor económico actualizar_valor 9. Actualización de valor económico consultar_valores 10. Consulta de valor económico En los casos de uso se especifica que el valor anual se calcula en base al mensual. Este cálculo se establece como una Derivación en la clase ComplementoDestino en la que el atributo ValorAnual es 12 veces el atributo ValorMensual. A su vez, el atributo ValorMensual tiene una restricción que impide que sea negativo, que es la precondición de 6.-Alta de Complemento de Destino. El servicio actualizar_valor tiene una precondición que obliga a que el porcentaje de cambio del valor sea mayor que cero, como se especifica en 9.-Actualización de valor económico. El agente que tiene visibilidad sobre los servicios de la clase es AdministradorSalarios, que puede acceder a su ejecución a través de la IIU ComplementoDestino o de la PIU ComplementoDestino. Gestión de Puesto de Trabajo El modelado de los Casos de Uso referentes a la Gestión de Puestos de Trabajo se realiza mediante la clase Puesto. En la siguiente tabla se detallan los atributos y servicios de esta clase y se expone la correspondencia de éstos con los casos de uso. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 104 Tabla 109. Correspondencias entre clase Puesto y Gestión de Puestos de Trabajo CLASE Puesto ATRIBUTOS - Id_Puesto - Atributo identificador del Puesto; tipo de dato Autonumérico. - NombrePuesto - Atributo variable; tipo de dato String de 50 posiciones. Tiene restricción de unicidad - Media - Atributo variable; tipo de dato Real - Percentil10 - Atributo variable; tipo de dato Real - Percentil25 - Atributo variable; tipo de dato Real - Percentil50 - Atributo variable; tipo de dato Real - Percentil75 - Atributo variable; tipo de dato Real - Percentil90 - Atributo variable; tipo de dato Real SERVICIOS Y SUS CORRESPONDENCIAS crear_puesto 11. Alta de Puesto de Trabajo borrar_puesto 12. Baja de Puesto de Trabajo modificar_nombre 13. Modificación de nombre de Puesto de Trabajo modificar_media 14. Modificación de la media del salario del Puesto de Trabajo AUMENTAR_PERCENTILES 15. Modificación de los percentiles del salario del Puesto de Trabajo DISMINUIR_PERCENTILES 15. Modificación de los percentiles del salario del Puesto de Trabajo actualizar_media 16. Actualización de la media del salario actualizar_percentiles 17. Actualización de los percentiles del salario consultar_media 18. Consulta de la media del salario consultar_percentiles 19. Consulta de los percentiles del salario En los casos de uso 11.-Alta de Puesto de Trabajo., 14.-Modificación de la media del salario del Puesto de Trabajo. y 15.-Modificación de los percentiles del salario del Puesto de Trabajo. se especifica que la media y los percentiles tienen que ser mayor que cero y el orden de los percentiles en cuanto a su valor. Estos requisitos se representan en el modelo mediante restricciones de integridad. Para realizar la modificación de los percentiles, se diseñan dos transacciones: AUMENTAR_PERCENTILES, que se utiliza para aumentar su valor, y DISMINUIR_PERCENTILES, que se utiliza para disminuirlo. Ambas transacciones ejecutan los eventos de cambio de cada percentil, pero varían en el orden en que lo hacen para que no se incumplan las restricciones citadas. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 111 Figura 30. Modelo de objetos de SIEFAP. El contenido de estos clusters se puede observar en la Figura 31. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 112 Figura 31. Clases del modelo de objetos de SIEFAP. En esta sección se realiza un mapeo entre los casos de uso del apartado 4.2. Especificación de Requisitos con los elementos del modelo Conceptual que permiten su diseño. Para cada apartado, se explican las clases involucradas, sus atributos y servicios y las relaciones entre clases que intervienen en el diseño. Los servicios diseñados son eventos, que aparecen en minúsculas en el documento o transacciones, que aparecen en mayúsculas. Gestión de Empleados El modelado de los Casos de Uso referentes a la Gestión de Empleados se realiza mediante las clases (Empleado, EmpleadoSupervisor, ResponsableAdministrador y Departamento. Las relaciones entre ellas se pueden ver en la Figura 32. Entre Empleado y Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 113 Departamento existe una relación de asociación porque un Departamento puede tener uno o varios Empleados. Por su parte, el Empleado puede especializarse en EmpleadoSupervisor y en ResponsableAdministracion. La clase ResponsableAdministracion se diseña para ejercer el Rol de Administrador de una única Administración. Figura 32. Modelo de objetos para la Gestión de Empleados. En las siguientes tablas se detallan las clases implicadas en la Gestión de Empleados. Tabla 114. Correspondencias entre clase Empleado y Gestión de Empleados CLASE Empleado ATRIBUTOS - NIF - Atributo identificador de Empleado; tipo de dato String de 9 posiciones. - Nombre - Atributo variable; tipo de dato String de 40 posiciones. - Apellidos - Atributo variable; tipo de dato String de 100 posiciones. - FechaNacimiento - Atributo variable; tipo de dato Fecha. - Salario - Atributo variable; tipo de dato Real. - Sexo - Atributo variable; tipo de dato String de 1 posición. - Estado - Atributo variable; tipo de dato String de 1 posición. SERVICIOS Y SUS CORRESPONDENCIAS create_instance 1. Alta de Empleado ACTIVAR_EMPLEADO 2. Activar Empleado desactivar_empleado 3. Desactivar Empleado BORRAR_EMPLEADO 4. Baja de Empleado Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 114 edit_instance 5. Modificación de detalles de Empleado convertir_supervisor 6. Convertir Empleado en Supervisor convertir_responsable 8. Convertir Empleado en Responsable En la clase Empleado se crea el atributo estado, que puede tomar valores “A” de Activo o “I” de Inactivo. Por defecto, el valor del atributo es “A”. Algunos servicios tienen como precondición que el empleado esté activo, como son edit_instance, convertir_supervisor y convertir_responsable. Para ACTIVAR_EMPLEADO, debe estar Inactivo y para desactivar_empleado debe estar Activo. La transacción ACTIVAR_EMPLEADO se diseña para realizar el borrado del departamento al que pertenecía el empleado y realizar la inserción en el nuevo departamento. La transacción BORRAR_EMPLEADO se diseña para dar de baja del sistema al empleado. Con esta transacción se llama a los eventos de borrado de las clases PesoCuestionario, Cuestionario, Valoracion_Conocimiento y Valoracion para todas las instancias relacionadas con el empleado. Por último se ejecuta el evento de borrado del empleado. Los agentes que tienen visibilidad sobre los servicios de la clase son AdministradorValoracion y ResponsableAdministrador de la administración a la que pertenece el empleado, que pueden acceder a su ejecución a través de la IIU Empleado o de la PIU Empleado. El servicio create_instance también es accesible desde la IIU Departamento y la PIU Departamento. Tabla 115. Correspondencias entre clase EmpleadoSupervisor y Gestión de Empleados CLASE EmpleadoSupervisor ATRIBUTOS Hereda los atributos de la clase Empleado y tiene dos propios. - FechaFin - Atributo variable; tipo de dato fecha. - FechaInicio - Atributo variable; tipo de dato fecha. SERVICIOS Y SUS CORRESPONDENCIAS reconvertir_supervisor 6. Convertir Empleado en Supervisor abandonar_supervisor 7. Abandonar Rol de Supervisor En la clase EmpleadoSupervisor se crean los atributos FechaInicio y FechaFin y los servicios reconvertir_supervisor y abandonar_supervisor para que un mismo Empleado pueda ser y dejar de ser supervisor tantas veces como sea necesario. La instancia de la especialización no se elimina porque puede estar relacionada con Cuestionarios y se controla si el supervisor está activo por el intervalo de fechas. Para realizar cualquiera de estas dos acciones el empleado debe estar activo. Los agentes que tienen visibilidad sobre los servicios de la clase son AdministradorValoracion y ResponsableAdministrador de la administración a la que pertenece Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 115 el supervisor, que pueden acceder a su ejecución a través de la IIU EmpleadoSupervirsor o de la PIU EmpleadoSupervisor. Tabla 116. Correspondencias entre clase ResponsableAdministracion y Gestión de Empleados CLASE ResponsableAdministracion ATRIBUTOS Hereda los atributos de la clase Empleado y tiene dos propios. SERVICIOS Y SUS CORRESPONDENCIAS abandonar_responsable 9. Abandonar Rol de Responsable En la clase ResponsableAdministracion se define una Restricción que obliga a que el empleado esté activo si está especializado en responsable. Los agentes que tienen visibilidad sobre los servicios de la clase son AdministradorValoracion y ResponsableAdministrador de la administración a la que pertenece el responsable, que pueden acceder a su ejecución a través de la IIU ResponsableAdministracion o de la PIU ResponsableAdministracion. Gestión de Usuarios El modelado de los Casos de Uso referentes a la Gestión de Usuarios se realiza mediante las clases Usuario, Usuario_Editor, AdministradorValoracion, AdministradorSalarios y Usuario_Anonimo. Las relaciones entre ellas se pueden ver en la Figura 33. El Usuario puede especializarse en Usuario_Editor, AdministradorValoracion y AdministradorSalarios. Éstas tres clases y Usuario_Anonimo representan algunos de los roles de los dos Sistemas de Información. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 116 Figura 33. Modelo de objetos para la Gestión de Usuarios. En las siguientes tablas se detallan las clases implicadas en la Gestión de Usuarios. Tabla 117. Correspondencias entre clase Usuario y Gestión de Usuarios CLASE Usuario ATRIBUTOS - Nombre_usuario Atributo identificador de Usuario; tipo de dato String de 64 posiciones. SERVICIOS Y SUS CORRESPONDENCIAS crear_usuario 10. Crear Usuario borrar_usuario 11. Borrar Usuario convertir_administrador 12. Convertir Usuario en Administrador (SIEFAC) convertirAdministradorSalarios 12. Convertir Usuario en Administrador (SIESMACRe) convertir_editor 14. Convertir Usuario en Editor Los servicios convertir_administrados y convertirAdministradorSalarios se diseñan para convertir un usuario en administrador de SIEFAP o en administrador de SIESMACRe, respectivamente. Los agentes que tienen visibilidad sobre los servicios de la clase son AdministradorValoracion y AdministradorSalarios, que pueden acceder a su ejecución a través de la IIU Usuario o de la PIU Usuario. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 117 Tabla 118. Correspondencias entre clase Usuario_editor y Gestión de Usuarios CLASE Usuario_editor ATRIBUTOS Hereda los atributos de la clase Usuario. SERVICIOS Y SUS CORRESPONDENCIAS abandonar_editor 15. Abandonar Rol de Editor El agente que tiene visibilidad sobre los servicios de la clase es AdministradorValoracion, que puede acceder a su ejecución a través de la IIU Usuario_Editor o de la PIU Usuario_Editor. Tabla 119. Correspondencias entre clase AdministradorValoracion y Gestión de Usuarios CLASE AdministradorValoracion ATRIBUTOS Hereda los atributos de la clase Usuario. SERVICIOS Y SUS CORRESPONDENCIAS abandonar_administrador 13. Abandonar Rol de Administrador (SIEFAP) El agente que tiene visibilidad sobre los servicios de la clase es AdministradorValoracion, que puede acceder a su ejecución a través de la SIU abandonar_administrador. Tabla 120. Correspondencias entre clase AdministradorSalarios y Gestión de Usuarios CLASE AdministradorSalarios ATRIBUTOS Hereda los atributos de la clase Usuario. SERVICIOS Y SUS CORRESPONDENCIAS abandonar_administrador 13. Abandonar Rol de Administrador (SIESMACRe) El agente que tiene visibilidad sobre los servicios de la clase es AdministradorSalarios, que puede acceder a su ejecución a través de la SIU abandonarAdmSalarios. Gestión de Departamentos El modelado de los Casos de Uso referentes a la Gestión de Departamentos se realiza mediante las clases Departamento y Administracion. Las relaciones entre ellas se pueden ver en la Figura 34. Entre Departamento y Administracion existe una relación de asociación porque una Administracion se puede organizar en varios departamentos. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 118 Figura 34. Modelo de objetos para la Gestión de Departementos. En la siguiente tabla se detalla la clase implicada en la Gestión de Departamentos. Tabla 121. Correspondencias entre clase Departamento y Gestión de Departamentos CLASE Departamento ATRIBUTOS - id_Departamento - Atributo identificador de Departamento; tipo de dato Autonumérico. - Nombre - Atributo variable; tipo de dato Texto. - NEmpleados - Atributo derivado a partir de la relación con la clase Empleado; tipo de dato Natural. - PresupuestoAsignado - Atributo variable; tipo de dato Real. - PresupuestoDispuesto - Atributo derivado a partir del atributo Salario de la clase Empleado; tipo de dato Real. SERVICIOS Y SUS CORRESPONDENCIAS create_instance 16. Alta de Departamento delete_instance 17. Baja de Departamento modificar_nombre 18. Modificación del nombre de Departamento asignar_presupuesto 19. Asignar Presupuesto a Departamento consulta_presupuesto 20. Consulta de Presupuesto de Departamento consultar_emleados 21. Consulta de Empleados de Departamento La clase Departamento se diseña con la Restricción de que el PresupuestoAsignado sea mayor o igual que cero y con dos Derivaciones: el número de empleados es la cantidad de instancias de la clase Empleado en estado Activo relacionadas con el Departamento, mientras que el presupuesto dispuesto es la suma del salario de estos empleados. Para el servicio delete_instance se ha creado una precondición, que impide que un Departamento se pueda borrar si tiene empleados activos asociados. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 119 Los agentes que tienen visibilidad sobre los servicios de la clase son AdministradorValoracion y ResponsableAdministrador de la administración a la que pertenece el departamento, que pueden acceder a su ejecución a través de la IIU Departamento o de la PIU Departamento. Gestión de Administraciones El modelado de los Casos de Uso referentes a la Gestión de Administraciones se realiza mediante la clase Administracion. En la siguiente tabla se detalla la clase implicada en la Gestión de Administraciones. Tabla 122. Correspondencias entre clase Administracion y Gestión de Administraciones CLASE Administracion ATRIBUTOS - id_Administracion - Atributo identificador de Administracion; tipo de dato Autonumérico. - Nombre - Atributo variable; tipo de dato Texto. - NDepartamentos - Atributo derivado a partir de la relación con la clase Departamento; tipo de dato Natural. - NEmpleados - Atributo derivado a partir del atributo NEmpleados de la clase Departamento; tipo de dato Natural. - PresupuestoAsignado - Atributo variable; tipo de dato Real. - PresupuestoDispuesto - Atributo derivado a partir del atributo PresupuestoDispuesto de la clase Departamento; tipo de dato Real. SERVICIOS Y SUS CORRESPONDENCIAS create_instance 22. Alta de Administración BORRAR_ADMINISTRACION 23. Baja de Administración modificar_nombre 24. Modificación del nombre de Administración asignar_presupuesto 25. Asignar Presupuesto a Administración consulta_presupuesto 26. Consulta de Presupuesto de la Administración consultar_emleados 27. Consulta de Empleados de la Administración Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 120 La clase Administracion se diseña con la Restricción de integridad de que el PresupuestoAsignado sea mayor o igual que cero y con tres Derivaciones: el número de departamentos es la cantidad de instancias de la clase Departamento relacionados con la Administracion, el número de empleados es la suma de los empleados de los departamentos relacionados, mientras que el presupuesto dispuesto es la suma del presupuesto dispuesto de los departamentos asociados. La transacción BORRAR_ADMINISTRACION se diseña para dar de baja del sistema la administración. Con esta transacción se llama a los eventos desactivación de los empleados relacionados, en caso de que los hubiere, y a los eventos de borrado de la clase Departamento de todos los departamentos relacionados con la administración. El agente AdministradorValoracion tiene visibilidad sobre todos los servicios de la clase Administracion. Por su parte, el agente ResponsableAdministracion tiene visibilidad sobre los servicios modificar_nombre, asignar_presupuesto, consulta_presupuesto y consultar_empleados de la administración a la que pertenece. Este último agente no puede crear ni eliminar administraciones. Los servicios de esta clase son accesibles a través de la IIU Administracion y de la PIU Administracion. Gestión de Conocimiento El modelado de los Casos de Uso referentes a la Gestión de Conocimientos se realiza mediante las clases Conocimiento y Administracion. Las relaciones entre ellas se pueden ver en la Figura 35. Figura 35. Modelo de objetos para la Gestión de Conocimientos. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 127 CORRESPONDENCIAS edit_instance 40. Modificar Plantilla de Cuestionario InsPlatilla_cue 44. Asignar Plantilla de Cuestionario a Conocimiento En la clase Plantilla_Cuestionario se definen cuatro Derivaciones. Una de estas derivaciones es la cantidad de preguntas que contiene la plantilla de cuestionario y que es la cantidad de instancias de la clase Pregunta_Plantilla relacionadas. Para el cálculo de la puntuación máxima se crea el atributo ValorTotal, que es la suma del atributo Valor de la clase Pregunta_Plantilla, y el atributo PuntuacionMaxima, que es la suma del atributo PuntosMaximos de la clase Pregunta_Plantilla dividido por el atributo Valor. Por último, el atributo Estado se emplea para distinguir si la plantilla está siendo utilizada en cuestionarios: un valor “N” indica que no está siendo utilizado, mientras que si está en uso este atributo toma el valor “S”. El servicio InsPlatilla_cue se establece para realizar la asociación de instancias entre plantillas de cuestionario y conocimientos. Al ser la asociación de cardinalidad máxima 1, este servicio ofrece un cambio de conocimiento asignado. Para eso, se definen dos precondiciones, que obligan a que la Plantilla no esté siendo utilizada en cuestionarios y que todas las preguntas que lo componen estén también relacionadas con el nuevo conocimiento. Para el servicio de modificación de la plantilla de cuestionario también se diseña la precondición de que la plantilla esté en estado “N”. Para visualizar correctamente la plantilla de cuestionario se crea la MDIU Plantilla_cuestionario, que muestra la información de una plantilla de cuestionario y de la población de preguntas relacionadas. En la tabla se detalla la clase Pregunta_Plantilla. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 128 Tabla 128. Correspondencias entre clase Pregunta_Plantilla y Gestión de Plantillas de Cuestionario CLASE Pregunta_Plantilla ATRIBUTOS - id_Platilla_cuestionario - Atributo identificador de Pregunta_Plantilla definido en la clase Plantilla_Cuestionario; tipo de dato Autonumérico. - id_Version - Atributo identificador de Pregunta_Plantilla definido en la clase Plantilla_Cuestionario; tipo de dato Autonumérico. - id_Pregunta - Atributo identificador de Pregunta_Plantilla definido en la clase Pregunta; tipo de dato Autonumérico. - Valor - Atributo variable; tipo de dato Real. - PuntosMaximos - Atributo derivado a partir de PuntuacionMaxima de la clase Pregunta y del atributo Valor; tipo de dato Real. SERVICIOS Y SUS CORRESPONDENCIAS create_instance 41. Asignar Pregunta a Plantilla de Cuestionario edit_instance 42. Desasignar Pregunta de Plantilla de Cuestionario edit_instance 43. Cambiar valor de Pregunta La clase Pregunta_Plantilla tiene sus atributos de identificación definidos en sus clases relacionadas porque sólo puede existir mientras exista la relación entre la plantilla de cuestionario y la pregunta. Se añade una Restricción para indicar que el atributo Valor debe ser mayor o igual que cero. Se diseña también la Derivacion del atributo PuntosMaximos de forma que sea la puntuación máxima de la pregunta por su Valor en la plantilla de cuestionario. Los tres servicios de la clase tienen la precondición de que el atributo Estado de la instancia de la clase Plantilla_Cuestionario valga “N” y el servicio de creación tiene además la precondición de que el conocimiento de la plantilla de cuestionario esté entre los conocimientos relacionados a la pregunta. Los agentes que pueden realizar acciones de Gestión de Plantillas de cuestionario son Usuario_Editor, AdminitradorValoracion y ResponsableAdministrador de la administración a la que pertenecen las plantillas de cuestionario. El Usuario_Editor tiene visibilidad sobre todos estos servicios, mientras que los otros dos agentes sólo pueden ejecutar el servicios InsPlantillaCue. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 129 Los servicios que se diseñan para la Gestión de Preguntas son accesibles desde la IIU Plantilla_Cuestionario, PIU Plantilla_Cuestionario y MDIU Plantilla_Cuestionario. Gestión de Evaluaciones El modelado de los Casos de Uso referentes a la Gestión de Evaluaciones se realiza mediante las clases Valoracion, Valoracion_Conocimiento, Empleado y Conocimiento. Las relaciones entre ellas se pueden ver en la Figura 39. Cada Valoracion se asocia con un Empleado. Las instancias de la clase Valoracion_Conocimiento se deben asociar con un Empleado y un Conocimiento. Entre la clase Valoracion y Valoracion_Conocimiento existe una asociación porque cada Valoracion puede dividirse en una o varias Valoracion_Conocimiento. Figura 39. Modelo de objetos para la Gestión de Evaluaciones. En la siguiente tabla se detalla la clase Valoracion. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 130 Tabla 129. Correspondencias entre clase Valoracion y Gestión de Evaluaciones CLASE Valoracion ATRIBUTOS - id_Valoracion - Atributo identificador de Valoracion; tipo de dato Autonumérico. - Puntos - Atributo variable; tipo de dato Natural. - PuntosObtenidos - Atributo derivado del atributo PuntuacionObtenida de la clase Valoracion_Conocimiento; tipo de dato Real. - FechaCreacion - Atributo constante; tipo de dato Fecha. - FechaFin - Atributo constante; tipo de dato Fecha. - Estado - Atributo variable; tipo de dato String de 1 posición. - Descripcion - Atributo variable; tipo de dato Texto. SERVICIOS Y SUS CORRESPONDENCIAS create_instance 45. Crear Evaluación edit_instance 47. Editar Evaluación cambiar_estado 48. Cambiar estado BORRAR_EVALUACION 50. Eliminar Evaluación En la clase Valoracion, se definen dos Restricciones; una para indicar que el número de puntos totales no puede ser inferior a los obtenidos por el empleado y la otra restringe la asignación de cuestionarios a las evaluaciones de conocimiento relacionadas que no tengan subconocimientos. El valor del atributo derivado PuntosObtenidos se define como la suma del atributo PuntuacionObtenida de las evaluaciones de conocimiento relacionadas que no tienen Superconocimiento. El atributo Estado de la clase Valoracion puede tomar valores “E” de “En Edición”, “A” de “Activo” y “F” de “Finalizado”. En los servicios edit_instance y BORRAR_EVALUACION se crea una Precondición para que sólo se puedan ejecutar en caso de que el estado sea “E”. El servicio cambiar_estado modifica el valor de este atributo mediante evaluaciones de situación en el modelo funcional, de forma que el Estado pasa de “E” a “A” o de “A” a “F”. Este servicio tiene como Precondiciones que se ejecute desde los estados “A” o “E” y que si se ejecuta desde el estado “E”, la suma de los atributos PuntosConocimiento de las instancias de la clase Valoracion_Conocimiento relacionadas y que no tienen Superconocimientos sea igual al atributo Puntos. La transacción BORRAR_EVALUACION borra primero todas las evaluaciones de conocimiento relacionadas y después la evaluación de entrada. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 131 Se crea la MDIU Valoracion, para visualizar de forma conjunta una evaluación y la población de evaluaciones de conocimiento que la forman. En la tabla se detalla la clase Valoracion_Conocimiento. Tabla 130. Correspondencias entre clase Valoracion_Conocimiento y Gestión de Evaluaciones CLASE Valoracion_Conocimiento ATRIBUTOS - id_Valoracion - Atributo identificador de Valoracion_Conocimiento definido en la clase Valoracion; tipo de dato Autonumérico. - NIF - Atributo identificador de Valoracion_Conocimiento definido en la clase Empleado; tipo de dato String de 9 posiciones. - id_Conocimiento - Atributo identificador de Valoracion_Conocimiento definido en la clase Conocimieto; tipo de dato Autonumérico. - NCuestionariosTotales - Atributo derivado a partir de la relación con la clase PesoCuestionario; tipo de dato Natural. - NCuestionariosPendientes - Atributo derivado a partir de los atributos NCuestionariosTotales, NCuestionariosFinalizados y NCuestionariosValidados; tipo de dato Natural. - NCuestionariosFinalizados - Atributo derivado a partir de la relación con la clase PesoCuestionario; tipo de dato Natural. - NCuestionariosValidados - Atributo derivado a partir de la relación con la clase PesoCuestionario; tipo de dato Natural. - NivelObtenido - Atributo derivado a partir del atributo PorcentajePuntuacionObtenida; tipo de dato Natural. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 132 - PuntosConocimiento - Atributo derivado a partir del atributo Puntos de la clase Valoracion y del atributo PorcentajePuntos; tipo de dato Real. PorcentajePuntuacionObtenida - Atributo derivado a partir del atributo PesoPorcentaje de la clase PesoCuestionario; tipo de dato Real. - PuntuacionObtenida - Atributo derivado a partir de los atributos PuntosConocimiento y NivelObtenido; tipo de dato Real. - SumaPesos - Atributo derivado a partir del atributo Peso de la clase PesoCuestionario; tipo de dato Real. - PorcentajePuntos - Atributo variable; tipo de dato Real. SERVICIOS Y SUS CORRESPONDENCIAS create_instance 46. Crear Evaluación de Conocimiento edit_instance 49. Editar Evaluación de Conocimiento BORRAR_VCONOCIMIENTO 51. Eliminar Evaluación de Conocimiento Esta clase tiene sus atributos de identificación definidos en sus clases relacionadas, pues se asocia a un empleado, un conocimiento y una evaluación en el momento de la creación de forma estática, es decir, que no puede cambiar de objeto asociado. En la clase Valoracion_Conocimiento, se definen dos Restricciones; una para indicar que el porcentaje de puntos debe estar entre 0 y 100 y para indicar que si el estado de la evaluación no es “E”, la suma de los puntos de las evaluaciones de subconocimientos debe ser igual a los puntos de su superconocimiento. En esta clase se definen las siguientes derivaciones: - NcuestionariosTotales es la cantidad de objetos de la clase PesoCuestionario relacionados y representa al número de cuestionarios de los que se compone una evaluación de conocimiento. En el caso de que existan evaluaciones de subconocimiento, es la suma de los cuestionarios totales de estas evaluaciones. - NcuestionariosFinalizados es la cantidad de objetos de la clase PesoCuestionario relacionados con estado del cuestionario finalizado y representa al Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 133 número de cuestionarios finalizados que hay en una evaluación de conocimiento. En el caso de que existan evaluaciones de subconocimiento, es la suma de los cuestionarios finalizados de estas evaluaciones. - NcuestionariosValidados es la cantidad de objetos de la clase PesoCuestionario relacionados con estado del cuestionario validado y representa al número de cuestionarios validados por un supervisor en una evaluación de conocimiento. En el caso de que existan evaluaciones de subconocimiento, es la suma de los cuestionarios validados de estas evaluaciones. - NcuestionariosPendientes es la diferencia entre los cuestionarios totales y los finalizados y validados. Representa al número de cuestionarios que aún no se han terminado de responder. - PuntosConocimiento son los puntos máximos que se pueden obtener en la evaluación del conocimiento. Se calcula a partir del atributo PorcentajePuntos y el atributo Puntos de la instancia de la clase Valoración relacionada; en caso de tratarse de un subonocimiento, se calcula a partir del atributo PuntosConocimiento de la evaluación del superconocimiento. - SumaPesos es la suma del atributo Peso de las instancias relacionadas de la clase PesoCuestionario. Este atributo se utiliza en el cálculo del porcentaje de puntos obtenido por un empleado en la evaluación del conocimiento. - PorcentajePuntuacionObtenida se calcula como la suma del atributo PesoPorcentaje de las instancias relacionadas de la clase PesoCuestionario dividido por el valor del atributo SumaPesos. Representa el porcentaje de puntos obtenidos en las respuestas de cuestionarios sobre los puntos totales de la evaluación del conocimiento. - NivelObtenido es un valor entre 0 y 5 que indica la calificación del empleado en la evaluación del conocimiento. Se calcula a partir del atributo PorcentajePuntuacionObtenida. La Figura 40 muestra la derivación correspondiente a este atributo. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 134 Figura 40. Derivación del atributo NivelObtenido de la clase Valoracion_Conocimiento. - PuntuacionObtenida son los puntos que se le suman a la evaluación global del empleado por parte de este conocimiento. Se calcula aplicando un porcentaje del atributo PuntosConocimiento según el valor del atributo NivelObtenido. En caso de que la evaluación sea de un Superconocimiento, se toma el valor de la suma del atributo PuntuacionObtenida de las evaluaciones de sus subconocimientos. La Figura 41 muestra la derivación correspondiente a este atributo. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 135 Figura 41. Derivación del atributo PuntacionObtenida de la clase Valoracion_Conocimiento. Los servicios de Valoracion_Conocimiento tienen la precondición de que el Estado de la evaluación relacionada sea “En Edición”. Además, el servicio de creación de evaluaciones de conocimiento también comprueba en precondiciones que el empleado pertenezca a la administración de entrada y esté relacionado con la evaluación de entrada. Se define también una precondición en el servicio create_instance para asegurar que las evaluaciones de conocimientos que se desean crear tengan ya creadas la evaluación de su superconocimiento. Para el servicio BORRAR_VCONOCIMIENTO se diseña una precondición que impide que se borre una evaluación de conocimiento si aún existen evaluaciones de sus subconocimientos. En cuanto al modelo de presentación, se crea la MDIU Valoracion_ConocimientoCo, para visualizar de forma conjunta la población de evaluaciones de conocimiento y los cuestionarios que las forman. Los agentes que pueden realizar acciones de Gestión de Evaluaciones son AdminitradorValoracion y ResponsableAdministrador de la administración a la que pertenecen los empleados a evaluar. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 136 Los servicios de la clase Valoracion son accesibles desde la IIU Valoracion, PIU Valoracion y MDIU Valoracion. Los servicios de la clase Valoracion_Conocimiento son accesibles desde la IIU Valoracion_Conocimiento, PIU Valoracion_Conocimiento y MDIU Valoracion_ConocimientoCo. El servicio de creación de evaluaciones de conocimiento también es accesible desde las Unidades de Interacción de la clase Valoracion. Gestión de Cuestionarios El modelado de los Casos de Uso referentes a la Gestión de Cuestionarios se realiza mediante las clases Cuestionario, PesoCuestionario, Empleado, EmpleadoSupervisor y Valoracion_Conocimiento. Las relaciones entre ellas se pueden ver en la Figura 42. Cada Cuestionario se asocia a un Empleado y a una Plantilla_Cuestionario. Además, cada Cuestionario debe relacionarse con una instancia de la clase EmpleadoSupervisor. La clase PesoCuestionario representa la relación entre Cuestionario y Valoracion_Conocimiento. Figura 42. Modelo de objetos para la Gestión de Cuestionarios. En la tabla se detalla la clase Cuestionario. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 143 definido para que se muestre sólo la instancia de la clase Respuesta_Empleado que corresponde. Figura 44. Definición de la MDIU Pregunta_PlantillaPIU. Por si parte, los casos de uso referentes a la Consulta de detalles de Cuestionarios, Evaluación y Evaluaciones de Conocimientos no se modelan mediante servicios en alguna de las clases diseñadas. Sólo tienen representación en el modelo de Presentación. En la siguiente tabla se presenta la correspondencia entre el Caso de Uso y las instancias del Modelo de Presentación que los representan. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 144 Tabla 135. Correspondencias entre Instancias del modelo de presentación y Realización de Evaluaciones CASO DE USO INSTANCIAS DEL MODELO DE PRESENTACIÓN 63. Consultar Detalles Cuestionario MDIU Plantilla_CuestionarioCon: Maestro -> IIU Plantilla_CuestionarioAcc Detalle -> MDIU Pregunta_PlantillaPIUCon: Maestro -> PIU Pregunta_PlantillaCon Detalle -> PIU Respuesta_EmpleadoCon Detalle -> PIU RespuestaCon 64. Consultar Detalles Evaluación MDIU Valoracion: Maestro -> IIU Valoracion Detalle -> MDIU Valoracion_Conocimiento 65. Consultar Detalles Evaluación de Conocimiento MDIU Valoracion_ConocimientoCo: Maestro -> PIU Valoracion_Conocimiento Detalle -> PIU PesoCuestionario Los atributos de Valoracion_Conocimiento y de Cuestionario pueden ser consultados por el AdministradorValoracion, el ResponsableAdministrador de la administración correspondiente, el Empleado que los realiza y el EmpleadoSupervisor que los valida. Además, los tres primeros agentes pueden consultar también los atributos de la clase Valoracion. Validar Cuestionario El modelado de los Casos de Uso referentes a la Validación de Cuestionarios se realiza mediante las clases Cuestionario y Respuesta_Empleado. En la siguiente tabla se muestran los servicios de la clase Cuestionario implicados en la Validación de Cuestionarios. Tabla 136. Correspondencias entre clase Cuestionario y Validación de Cuestionarios CLASE Cuestionario SERVICIOS Y SUS CORRESPONDENCIAS validar_cuestionario: 66. Aprobar Cuestionario corregir_cuestionario: 68. Solicitar corrección Cuestionario El servicio validar_cuestionario cambia el estado del cuestionario a “Validado” y asigna valor a las fechas de corrección y de validación. El cambio de estado a “Validado” hace que el atributo PorcentajeObtenido obtenga su valor definitivo y se consiga la puntuación de las evaluaciones de conocimiento y las evaluaciones globales. El servicio corregir_cuestionario cambia el estado del cuestionario a “En Respuesta” y asigna valor a las fechas de corrección. Estos dos servicios tienen que cumplir la Precondición de que el estado del cuestionario sea “Finalizado”. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 145 En la siguiente tabla se muestran los servicios de la clase Respuesta_Empleado implicados en la Validación de Cuestionarios. Tabla 137. Correspondencias entre clase Respuesta_Empleado y Validación de Cuestionarios CLASE Respuesta_Empleado SERVICIOS Y SUS CORRESPONDENCIAS motivo_correccion 67. Comentar Respuesta de Empleado El servicio motivo_correccion permite añadir al empleado supervisor una explicación por la que se sugiere la corrección de una respuesta, siempre que se cumpla la validación de que el cuestionario esté en estado “Finalizado”. Los 3 servicios de la validación de cuestionario son accesibles desde la SIU comenzar_revisión, para el que se ha definido una Navegación Condicional que lleva a la MDIU Plantilla_cuestionarioAcc, presentada en la Figura 44. En el siguiente capítulo se presenta el Espacio de la Solución, donde se cuenta cómo se obtiene el código mediante las herramientas Olivanova, las acciones que hay que realizar para conseguir la aplicación final y se presentan las transformaciones del modelo conceptual al modelo de implementación, la aplicación final. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 146 5. ESPACIO DE LA SOLUCIÓN En el capítulo 3 se han presentado los requisitos funcionales de los Sistemas de Información de este Proyecto Final de Carrera. En términos de de OO-Method, la Especificación de Requisitos se corresponde con el Modelo Independiente de Computación (CIM), mientras que el Esquema Conceptual desarrollado es el Modelo Independiente de Plataforma (PIM). La transformación entre uno y otro modelo se realizado manualmente, mediante un proceso de análisis. En una ingeniería de desarrollo de aplicaciones tradicional, partiendo del esquema conceptual ya definido, se crearía manualmente el Modelo Específico de Plataforma (PSM) para posteriormente conseguir de forma también manual el Modelo de Implementación (IM), o aplicación final. En el desarrollo dirigido por modelos, esta transformación se debe realizar de la manera más automática posible. En este capítulo se presenta cómo se realiza esta transformación. 5.1. Transformación de PIM a PSM en OO-Method OO-Method sugiere que esta transformación se haga de forma sistemática y automática. El proceso por el que se traduce el esquema conceptual a una aplicación se llama Compilación de modelos conceptuales. El esquema conceptual supone un nivel de abstracción superior al código fuente, de igual forma que éste es también un nivel superior al código máquina. De ahí que se utilice el término compilación para nombrar a este proceso. Los lenguajes de programación convencionales no incorporan detalles de la arquitectura hardware, como la organización física de la memoria o el uso de registros. Es el compilador el que añade estos requisitos cuando se genera el lenguaje máquina. De forma análoga, el compilador de modelos debe añadir ciertas características de la plataforma software destino al código fuente generado, las cuales no se especifican en el esquema conceptual, tales como mecanismos de control de la ejecución o estrategias de accesos a datos. Los esquemas conceptuales son totalmente independientes de la plataforma software destino. Esto significa que un mismo esquema conceptual puede compilarse para distintas plataformas. La transformación a la aplicación final se basa en la representación software del conjunto de elementos conceptuales. Por tanto, caracterizar un Compilador de Modelos consiste en determinar las correspondencias entre los elementos conceptuales y sus representaciones software de forma precisa, teniendo en cuenta la arquitectura en la que se van a ejecutar [19]. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 147 La compilación de un modelo conceptual en una aplicación debe ser un proceso determinista que pueda aplicarse de forma sistemática [32]. Para ello, se deben cumplir los siguientes requisitos: - La manera en que el esquema conceptual se representa en un entorno de desarrollo cualquiera debe estar determinada, considerando los aspectos estáticos, dinámicos y de presentación. - Se debe definir la arquitectura de la aplicación resultante. - Se debe establecer una estrategia de ejecución que garantice la equivalencia funcional entre la especificación y su implementación. Estrategia de ejecución de aplicaciones En el proceso de compilación de modelos conceptuales se debe establecer cómo las aplicaciones representarán los elementos definidos en el modelo conceptual. Es decir, se debe asegurar que la semántica de los elementos conceptuales se respeta, para que la aplicación resultante del proceso de transformación (en el espacio de la solución) haga realmente lo diseñado en el esquema (en el espacio del problema). OO-Method propone definir los elementos de modelado, en lugar de los entornos en que las aplicaciones pueden ejecutarse. El resultado es el Modelo de Ejecución Abstracto, que sigue centrando la atención en qué representa y no en cómo se representa. Además, tiene las ventajas de que puede emplearse independientemente de una plataforma destino específica y asegura la equivalencia funcional entre el esquema conceptual y su correspondiente aplicación software obtenida como resultado del proceso. Arquitectura de las aplicaciones La estrategia de ejecución de aplicaciones fija un conjunto de mecanismos que especifican lo que debe implementar una aplicación, pero no especifican el cómo. La arquitectura de la aplicación es la que debe proporcionar medios que indican la manera en que se implementa una aplicación. Por tanto, la definición de una u otra arquitectura es el primer escenario diferencial en el proceso de compilación de modelos conceptuales. La arquitectura de una aplicación debe tener los mecanismos adecuados para representar cada elemento del modelo conceptual, como las clases, los servicios o las relaciones. Estos mecanismos deben interactuar en tiempo real para proporcionar una ejecución de la aplicación equivalente a lo definido en el modelo conceptual. Además de esto, también deben proveer de mecanismos auxiliares como el control de errores, los protocolos de comunicación o el acceso a datos. OO-Method aprovecha que hay un consenso amplio en el mundo del desarrollo de software para la construcción de aplicaciones en tres capas para definir arquitecturas software Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 148 basadas en este esquema. La arquitectura de tres capas consiste en diferenciar una aplicación en los siguientes tres niveles: 1. Capa de presentación, que contiene los componentes para crear la interfaz de usuario. 2. Capa de negocio, en la que están los servicios que implementan la funcionalidad de una aplicación. 3. Capa de persistencia, que tiene los mecanismos para asegurar el almacenamiento de los datos tratados por la aplicación. La Figura 45 presenta gráficamente la arquitectura de tres capas y la comunicación entre cada una de ellas. Figura 45. Esquema de la arquitectura de tres capas [33] La arquitectura de aplicación seleccionada para el proceso de compilación de modelos conceptuales debe proporcionar los mecanismos adecuados tanto para adaptar la funcionalidad de cada uno de los 3 niveles como para asegurar la comunicación entre ellos. Además, la generación de cada uno de los niveles puede hacerse de forma independiente del resto. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 149 Estrategia de transformación El tercer aspecto que completa el proceso, es la estrategia de transformación, entendida como la forma en que se pasa del Modelo Conceptual al Modelo de Aplicación. Se basa en la definición de: 1. Correspondencias, que establecen relaciones entre los elementos del Modelo Conceptual y el Modelo de Aplicación. 2. Transformaciones, que determinan cómo se obtiene la aplicación a partir de cada elemento del Modelo de Aplicación [32]. El objetivo de las correspondencias es definir cómo los elementos del Modelo Conceptual se pueden crear en el Modelo de Aplicación. Es posible que un elemento conceptual tenga varias posibles traducciones a elementos software, o viceversa. Por tanto, en la definición de las correspondencias, se debe elegir la mejor alternativa posible. Las transformaciones definen cómo obtener un fragmento de código a partir de un elemento del Modelo de Aplicación. Cada elemento del Modelo de Aplicación debe tener una transformación asociada. Para definir completamente la estrategia de transformación, pueden ser necesarias varias iteraciones de definición de correspondencias y transformaciones. Por último, se debe tener en cuenta que debe existir un equilibrio entre la Arquitectura de la Aplicación y las transformaciones, puesto que cuanto mejor definida y más completa sea la primera, más sencillas serán la transformaciones. OLIVANOVA Transformation Engines OLIVANOVA Transformation Engines son las implementaciones de diferentes procesos de compilación OO-Method. Cada uno de ellos, implementa un repositorio del Modelo Conceptual, un repositorio del Modelo de Aplicación, una colección de correspondencias y una colección de mapeos [32]. En la Figura 46 se presenta el esquema de un Transformation Engine. Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 150 Figura 46. Esquema OLIVANOVA Transformation Engine [34]. El esquema conceptual se carga a partir de un fichero XML generado por OLIVANOVA Modeler. Las correspondencias son operaciones que leen datos del repositorio del modelo conceptual y lo asignan al repositorio del modelo de aplicación, junto con los valores correspondientes de las propiedades. El repositorio del modelo de aplicación contiene elementos asociados a cada elemento conceptual y a información necesaria para la estrategia de ejecución de aplicación para la plataforma software. Las transformaciones leen datos del repositorio del modelo de aplicación y de las propiedades de cada elemento del modelo para generar y ensamblar los fragmentos de código que harán la aplicación final. 5.2 Obtención de código con el sistema Olivanova STAR Hasta este punto, se ha empleado la herramienta Olivanova Modeler para construir el Modelo Conceptual (PIM) de los sistemas de información que se diseñan en este Proyecto Final de Carrera. La transformación del modelo a código ejecutable se hace de forma automática mediante las Olivanova Transformation Engines. La herramienta Olivanova STAR es la encargada de recibir las peticiones de transformación a código fuente. El proceso para utilizar el sistema STAR comienza con la validación del esquema conceptual. El validador detecta defectos [35] en el modelo, presentando un informe con los Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 151 constructores conceptuales asociados a cada defecto. Una vez corregidos los defectos y con el modelo validado, se genera un fichero XML con la información del modelo conceptual diseñado. Este fichero XML es la entrada del sistema STAR. En la Figura 47, se muestran las propiedades generales de una petición de generación de código. Además de esta información, se deben configurar los perfiles transformación, que contienen la información para que los Olivanova Transformation Engines generen el código fuente. Figura 47. Propiedades generales del Sistema Star. Los servicios de transformación ofrecidos, clasificados por la capa que implementan son los siguientes [34]: A. Para la capa de lógica de negocio: 1. C# .NET 2.0 2. JAVA / EJB2 B. Para la capa de presentación: 1. ASP .NET 2.0 Aplicación práctica de MDA con Olivanova para una aplicación de evaluación de recursos humanos 152 2. C# / .NET 2.0 3. JSF (Java Server Faces) Adicionalmente, se puede solicitar también la generación automática de documentación del modelo y el cálculo del tamaño del programa resultante en puntos de función. En la Figura 48, se pueden ver los perfiles seleccionables en el sistema STAR. Figura 48. Perfiles disponibles en Olivanova STAR Client. Para el caso concreto de este PFC, se ha elegido C# .NET 2.0 para la capa de negocio y Desktop C# .NET 2.0 para la capa de presentación. Estos perfiles se deben configurar para solicitar la transformación. En el perfil correspondiente a la capa de negocio, es necesario especificar el nombre de la aplicación, la Base de Datos que se va a utilizar para la capa de persistencia, el tipo de conexión a ella y el nombre de la conexión. El resto de las propiedades están especificadas por defecto por el sistema STAR y pueden ser modificables por el usuario, por ejemplo la versión del transformation engine utilizado para la generación del código. Para la capa de presentación, se debe especificar el nombre de la aplicación que presenta la interfaz y el nombre de la aplicación que implementa la capa de negocio. La Figura 49 muestra los valores de las opciones de transformación seleccionados para la capa de negocio. Los datos personalizados son el nombre de la aplicación VPTrabajoSrv, el del NameSpace VPTrabajoSrvNS, el tipo de base de datos SQLServer 2000 y el tipo de conexión a la base de datos ODBC y la cadena de conexión DSN=VPTDB. El resto de opciones son las especificadas por defecto. Las opciones de transformación de la capa de presentación son la vista seleccionada para la compilación del modelo, V_Desktop, el nombre de la aplicación cliente VPTrabajoClient y su NameSpace VPTrabajoClientNS y el nombre de la aplicación servidor a la que se conecta