Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional...

110
openFWPA Internacional - openEUG - Diseño funcional (03. DiseñoFuncional_openEUG_20111230_v1.0)

Transcript of Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional...

Page 1: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

openFWPA Internacional

- openEUG -

Diseño funcional

(03. DiseñoFuncional_openEUG_20111230_v1.0)

Page 2: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 2 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

ÍNDICE

1. CONTROL DEL DOCUMENTO ...................................................................................................... 10 1.1. Información general ..................................................................................................................... 10

1.2. Histórico de revisiones ................................................................................................................. 10 1.3. Estado del documento .................................................................................................................. 10

2. ANÁLISIS DE REQUISITOS ............................................................................................................ 11 2.1. LISTA DE REQUISITOS FUNCIONALES ............................................................................... 11

2.2. LISTA DE REQUISITOS NO FUNCIONALES ........................................................................ 12 3. ANÁLISIS FUNCIONAL .................................................................................................................. 13

3.1. Modelo de Clases del Dominio .................................................................................................... 13

3.2. Modelo de Procesos de Negocio .................................................................................................. 13 3.3. Modelado de Casos de Uso .......................................................................................................... 13

3.3.1. Modelo de Casos de Uso ....................................................................................................... 13 3.3.2. Definición de actores ............................................................................................................ 14

3.3.3. Definición de Casos de Uso .................................................................................................. 14 3.3.3.1. Caso de Uso – Buscador Expedientes ............................................................................ 15

3.3.3.2. Caso de Uso – Búsqueda de Expedientes ..................................................................... 15 3.3.3.2.1. Descripción ............................................................................................................. 15 3.3.3.2.2. Flujo de eventos ...................................................................................................... 16

3.3.3.2.3. Excepciones ............................................................................................................ 17 3.3.3.3. Caso de Uso – Búsqueda Agrupada de Expedientes..................................................... 17

3.3.3.3.1. Descripción ............................................................................................................. 17 3.3.3.3.2. Flujo de eventos ...................................................................................................... 17

3.3.3.4. Caso de Uso – Tramitar en Bloque ................................................................................ 18 3.3.3.4.1. Introducción ............................................................................................................ 18

3.3.3.4.2. Conceptos ................................................................................................................ 19 3.3.3.5. Caso de Uso – Seleccionar expedientes ......................................................................... 20

3.3.3.5.1. Descripción ............................................................................................................. 20

3.3.3.5.2. Flujo de eventos ...................................................................................................... 20 3.3.3.5.3. Excepciones ............................................................................................................ 20

3.3.3.6. Caso de Uso – Seleccionar Trámite ............................................................................... 21 3.3.3.6.1. Descripción ............................................................................................................. 21 3.3.3.6.2. Flujo de eventos ...................................................................................................... 21

3.3.3.6.3. Excepciones ............................................................................................................ 21 3.3.3.7. Caso de Uso – Punto de extensión de tramitación en bloque ........................................ 21

Page 3: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 3 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.7.1. Descripción ............................................................................................................. 21 3.3.3.7.2. Flujo de eventos ...................................................................................................... 22 3.3.3.7.3. Excepciones ............................................................................................................ 22

3.3.3.8. Caso de Uso – Ejecución de la tramitación en bloque ................................................... 22 3.3.3.8.1. Descripción ............................................................................................................. 22 3.3.3.8.2. Flujo de eventos ...................................................................................................... 22 3.3.3.8.3. Flujo alternativo de eventos .................................................................................... 23 3.3.3.8.4. Excepciones ............................................................................................................ 23

3.3.3.9. Caso de Uso – Consulta del estado de la tramitación en bloque .................................... 23

3.3.3.9.1. Descripción ............................................................................................................. 23 3.3.3.9.2. Flujo de eventos ...................................................................................................... 24 3.3.3.9.3. Cambios a realizar ................................................................................................... 25

3.3.3.9.4. Descripción ............................................................................................................. 26 3.3.3.9.5. Flujo de eventos ...................................................................................................... 26

3.3.3.10. Caso de Uso – Cerrar Fase en Bloque.......................................................................... 26 3.3.3.10.1. Descripción ........................................................................................................... 26 3.3.3.10.2. Flujo de eventos. ................................................................................................... 26

3.3.3.11. Caso de Uso – Visor Expedientes ................................................................................ 27

3.3.3.12. Caso de Uso – Ver Expediente .................................................................................... 27 3.3.3.12.1. Descripción ........................................................................................................... 27 3.3.3.12.2. Flujo de eventos .................................................................................................... 28

3.3.3.12.3. Excepciones .......................................................................................................... 29 3.3.3.13. Caso de Uso – Ver Ficha Catalográfica del Procedimiento ......................................... 29

3.3.3.13.1. Descripción ........................................................................................................... 29 3.3.3.13.2. Flujo de eventos .................................................................................................... 29 3.3.3.13.3. Excepciones .......................................................................................................... 29

3.3.3.14. Caso de Uso – Modificar Expediente .......................................................................... 30 3.3.3.14.1. Descripción ........................................................................................................... 30

3.3.3.14.2. Flujo de eventos .................................................................................................... 30 3.3.3.14.3. Excepciones .......................................................................................................... 30

3.3.3.15. Caso de Uso – Alta del Interesado Principal................................................................ 30

3.3.3.15.1. Descripción ........................................................................................................... 30 3.3.3.15.2. Flujo de eventos .................................................................................................... 31 3.3.3.15.3. Excepciones .......................................................................................................... 31

3.3.3.16. Caso de Uso – Alta de Territorio ................................................................................. 31

3.3.3.16.1. Descripción ........................................................................................................... 31 3.3.3.16.2. Flujo de eventos .................................................................................................... 32 3.3.3.16.3. Excepciones .......................................................................................................... 32

3.3.3.17. Caso de Uso – Modificar Territorio ............................................................................. 32 3.3.3.17.1. Descripción ........................................................................................................... 32

Page 4: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 4 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.17.2. Flujo de eventos .................................................................................................... 33 3.3.3.17.3. Excepciones .......................................................................................................... 33

3.3.3.18. Caso de Uso – Borrar Territorio .................................................................................. 33

3.3.3.18.1. Descripción ........................................................................................................... 33 3.3.3.18.2. Flujo de eventos .................................................................................................... 33 3.3.3.18.3. Excepciones .......................................................................................................... 34

3.3.3.19. Caso de Uso – Alta de Expediente Relacionado .......................................................... 34 3.3.3.19.1. Descripción ........................................................................................................... 34 3.3.3.19.2. Flujo de eventos .................................................................................................... 34

3.3.3.19.3. Excepciones .......................................................................................................... 35 3.3.3.20. Caso de Uso – Modificar Expediente Relacionado ..................................................... 35

3.3.3.20.1. Descripción ........................................................................................................... 35

3.3.3.20.2. Flujo de eventos .................................................................................................... 35 3.3.3.20.3. Excepciones .......................................................................................................... 35

3.3.3.21. Caso de Uso – Borrar Expediente Relacionado ........................................................... 36 3.3.3.21.1. Descripción ........................................................................................................... 36 3.3.3.21.2. Flujo de eventos .................................................................................................... 36

3.3.3.21.3. Excepciones .......................................................................................................... 36

3.3.3.22. Caso de Uso – Creación Expedientes .......................................................................... 37 3.3.3.23. Caso de Uso – Alta Expediente.................................................................................... 37

3.3.3.23.1. Descripción ........................................................................................................... 37

3.3.3.23.2. Flujo de eventos .................................................................................................... 37 3.3.3.23.3. Flujo alternativo .................................................................................................... 38

3.3.3.23.4. Excepciones .......................................................................................................... 38 3.3.3.24. Caso de Uso – Terceros ............................................................................................... 39 3.3.3.25. Caso de Uso – Listar Terceros del Expediente ............................................................ 39

3.3.3.25.1. Descripción ........................................................................................................... 39 3.3.3.25.2. Flujo de eventos .................................................................................................... 40

3.3.3.25.3. Excepciones .......................................................................................................... 40 3.3.3.26. Caso de Uso – Alta Tercero ......................................................................................... 40

3.3.3.26.1. Descripción ........................................................................................................... 40

3.3.3.26.2. Flujo de eventos .................................................................................................... 41 3.3.3.26.3. Flujo alternativo .................................................................................................... 42 3.3.3.26.4. Esquema ................................................................................................................ 43

3.3.3.27. Caso de Uso – Modificar Tercero ................................................................................ 43

3.3.3.27.1. Descripción ........................................................................................................... 43 3.3.3.27.2. Flujo de eventos .................................................................................................... 44 3.3.3.27.3. Excepciones .......................................................................................................... 44

3.3.3.28. Caso de Uso – Borrar Tercero...................................................................................... 44 3.3.3.28.1. Descripción ........................................................................................................... 45

Page 5: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 5 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.28.2. Flujo de eventos .................................................................................................... 45 3.3.3.28.3. Excepciones .......................................................................................................... 45

3.3.3.29. Caso de Uso – Alta Dirección ...................................................................................... 45

3.3.3.29.1. Descripción ........................................................................................................... 45 3.3.3.29.2. Flujo de eventos .................................................................................................... 46 3.3.3.29.3. Excepciones .......................................................................................................... 46

3.3.3.30. Caso de Uso – Modificar Dirección ............................................................................. 46 3.3.3.30.1. Descripción ........................................................................................................... 46 3.3.3.30.2. Flujo de eventos .................................................................................................... 47

3.3.3.30.3. Excepciones .......................................................................................................... 47 3.3.3.31. Caso de Uso – Borrar Dirección .................................................................................. 47

3.3.3.31.1. Descripción ........................................................................................................... 47

3.3.3.31.2. Flujo de eventos .................................................................................................... 48 3.3.3.31.3. Excepciones .......................................................................................................... 48

3.3.3.32. Caso de Uso – Tramitar Expediente ............................................................................ 49 3.3.3.32.1. Descripción ........................................................................................................... 49 3.3.3.32.2. Tramitar ................................................................................................................. 49

3.3.3.32.3. Crear Acto ............................................................................................................. 53

3.3.3.32.4. Cerrar Fase ............................................................................................................ 53 3.3.3.32.5. Volver a Fase Anterior .......................................................................................... 54 3.3.3.32.6. Finalizar Expediente ............................................................................................. 54

3.3.3.32.7. Excepciones .......................................................................................................... 54 3.3.3.33. Caso de Uso – Documentación Aportada .................................................................... 55

3.3.3.34. Caso de Uso - Mostrar Documentación Sin aportar .................................................... 56 3.3.3.34.1. Descripción. .......................................................................................................... 56 3.3.3.34.2. Flujo de eventos. ................................................................................................... 56

3.3.3.34.3. Excepciones. ......................................................................................................... 56 3.3.3.35. Caso de Uso – Advertir Sin Tercero Asignado ............................................................ 56

3.3.3.35.1. Descripción. .......................................................................................................... 56 3.3.3.35.2. Flujo de eventos. ................................................................................................... 57 3.3.3.35.3. Excepciones. ......................................................................................................... 57

3.3.3.36. Caso de Uso – Listar Con Tercero Asignado ............................................................... 57 3.3.3.36.1. Descripción. .......................................................................................................... 57 3.3.3.36.2. Flujo de eventos. ................................................................................................... 58 3.3.3.36.3. Excepciones. ......................................................................................................... 58

3.3.3.37. Caso de Uso – Mostrar Transiciones ........................................................................... 58 3.3.3.37.1. Descripción. .......................................................................................................... 58 3.3.3.37.2. Flujo de eventos. ................................................................................................... 58 3.3.3.37.3. Excepciones. ......................................................................................................... 59

3.3.3.38. Caso de Uso – Transición Con Tercero Asignado ....................................................... 59

Page 6: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 6 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.38.1. Descripción. .......................................................................................................... 59 3.3.3.38.2. Flujo de eventos. ................................................................................................... 59 3.3.3.38.3. Excepciones. ......................................................................................................... 59

3.3.3.39. Caso de Uso – Selección de Soporte ............................................................................ 59 3.3.3.39.1. Descripción. .......................................................................................................... 59 3.3.3.39.2. Flujo de eventos. ................................................................................................... 60 3.3.3.39.3. Excepciones. ......................................................................................................... 60

3.3.3.40. Caso de Uso – Transición En Bloque .......................................................................... 60 3.3.3.40.1. Descripción. .......................................................................................................... 60

3.3.3.40.2. Flujo de eventos. ................................................................................................... 60 3.3.3.40.3. Excepciones. ......................................................................................................... 61

3.3.3.41. Caso de Uso – Datos Transición En Bloque ................................................................ 61

3.3.3.41.1. Descripción. .......................................................................................................... 61 3.3.3.41.2. Flujo de eventos. ................................................................................................... 61

3.3.3.41.3. Excepciones. ......................................................................................................... 61 3.3.3.42. Caso de Uso – Listar Aportados .................................................................................. 61

3.3.3.42.1. Descripción. .......................................................................................................... 61

3.3.3.42.2. Flujo de eventos. ................................................................................................... 62

3.3.3.42.3. Excepciones. ......................................................................................................... 62 3.3.3.43. Caso de Uso – Ordenar ................................................................................................ 63

3.3.3.43.1. Descripción. .......................................................................................................... 63

3.3.3.43.2. Flujo de eventos. ................................................................................................... 63 3.3.3.43.3. Excepciones. ......................................................................................................... 63

3.3.3.44. Caso de Uso – Filtro..................................................................................................... 63 3.3.3.44.1. Descripción. .......................................................................................................... 63 3.3.3.44.2. Flujo de eventos. ................................................................................................... 64

3.3.3.44.3. Excepciones. ......................................................................................................... 64 3.3.3.45. Caso de Uso – Ejecutar Transición .............................................................................. 64

3.3.3.45.1. Descripción. .......................................................................................................... 64 3.3.3.45.2. Flujo de eventos. ................................................................................................... 64 3.3.3.45.3. Excepciones. ......................................................................................................... 65

3.3.3.46. Caso de Uso –Transición Simple ................................................................................. 65 3.3.3.46.1. Descripción. .......................................................................................................... 65 3.3.3.46.2. Flujo de eventos. ................................................................................................... 65 3.3.3.46.3. Excepciones. ......................................................................................................... 65

3.3.3.47. Caso de Uso –Transición Con Interacción ................................................................... 65 3.3.3.47.1. Descripción. .......................................................................................................... 65 3.3.3.47.2. Flujo de eventos. ................................................................................................... 66 3.3.3.47.3. Excepciones. ......................................................................................................... 66

3.3.3.48. Caso de Uso – Crear Tipo De Documento ................................................................... 66

Page 7: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 7 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.48.1. Descripción. .......................................................................................................... 66 3.3.3.48.2. Flujo de eventos. ................................................................................................... 67 3.3.3.48.3. Excepciones. ......................................................................................................... 67

3.3.3.49. Caso de Uso – Alarmas ................................................................................................ 68 3.3.3.50. Caso de Uso – Alta Alarma.......................................................................................... 68

3.3.3.50.1. Descripción ........................................................................................................... 68 3.3.3.50.2. Flujo de eventos .................................................................................................... 69 3.3.3.50.3. Excepciones .......................................................................................................... 69

3.3.3.51. Caso de Uso – Alta Alerta............................................................................................ 69

3.3.3.51.1. Descripción ........................................................................................................... 69 3.3.3.51.2. Flujo de eventos .................................................................................................... 69

3.3.3.52. Caso de Uso – Ver Alarmas ......................................................................................... 70

3.3.3.52.1. Descripción ........................................................................................................... 70 3.3.3.52.2. Flujo de eventos .................................................................................................... 70

3.3.3.52.3. Excepciones .......................................................................................................... 70 3.3.3.53. Caso de Uso – Borrar Alarma ...................................................................................... 70

3.3.3.53.1. Descripción ........................................................................................................... 71

3.3.3.53.2. Flujo de eventos .................................................................................................... 71

3.3.3.53.3. Excepciones .......................................................................................................... 71 3.3.3.54. Caso de Uso – Informes ............................................................................................... 72 3.3.3.55. Caso de Uso – Informes Básicos.................................................................................. 72

3.3.3.55.1. Descripción ........................................................................................................... 72 3.3.3.55.2. Flujo de eventos .................................................................................................... 73

3.3.3.56. Caso de Uso – Colaboración ........................................................................................ 73 3.3.3.56.1. Descripción ........................................................................................................... 73 3.3.3.56.2. Flujo de eventos .................................................................................................... 74

3.3.3.56.3. Flujo de eventos (Ejemplo) ................................................................................... 75 3.3.3.56.4. Roles de Aplicación .............................................................................................. 76

3.3.3.56.5. Grupos de Tramitación .......................................................................................... 77 3.3.3.57. Caso de Uso – Control de Plazos ................................................................................. 78

3.3.3.57.1. Fecha de Inicio ...................................................................................................... 79

3.3.3.57.2. Fecha de Finalización............................................................................................ 80 3.3.3.57.3. Paralizaciones/Reanudaciones .............................................................................. 80 3.3.3.57.4. Trámite de Urgencia .............................................................................................. 81 3.3.3.57.5. Ampliaciones de Plazo .......................................................................................... 81

3.3.3.58. Caso de Uso – Notas sobre Expedientes ...................................................................... 82 3.3.3.58.1. Flujo de eventos .................................................................................................... 82

3.3.3.59. Caso de Uso – Formas finalización de un expediente ................................................ 83 3.3.3.59.1. Flujo de Finalización ............................................................................................. 83 3.3.3.59.2. Flujo de eventos .................................................................................................... 85

Page 8: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 8 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.59.3. Tipos de actos de formas de finalización .............................................................. 87 3.3.3.59.3.1. Finalización con notificación aceptada .......................................................... 87 3.3.3.59.3.2. Finalización con notificación fallida .............................................................. 88

3.3.3.59.3.3. Configuración en catálogo de la Finalización con notificación ..................... 89 3.3.3.59.4. Como deshacer una resolución ............................................................................. 89

3.3.3.59.4.1. Deshacer una resolución sin notificar ............................................................ 89 3.3.3.59.4.2. Deshacer una resolución ya notificada ........................................................... 89

3.3.3.59.4.2.1. Otros tipos de forma de terminación. ...................................................... 89 3.3.3.59.4.3. Anexo - Formas Finalización ......................................................................... 90

3.3.3.60. Caso de Uso – Campos Flexibles ................................................................................. 94 3.3.3.60.1. Tipos de campos flexibles ..................................................................................... 94 3.3.3.60.2. Validaciones de campos ........................................................................................ 95

3.3.3.60.3. Flujo de eventos .................................................................................................... 97 3.3.3.61. Caso de Uso – Impresión conjunta. ............................................................................ 97

3.3.3.61.1. Descripción ........................................................................................................... 98 3.3.3.61.2. Flujo de eventos. ................................................................................................... 99

3.3.3.62. Caso de Uso – Impresión conjunta de los actos de un expediente. ............................. 99

3.3.3.62.1. Descripción ........................................................................................................... 99

3.3.3.62.2. Flujo de eventos. ................................................................................................... 99 3.3.3.63. Caso de Uso – Impresión conjunta del los documentos de tramitación en bloque. .. 100

3.3.3.63.1. Descripción ......................................................................................................... 100

3.3.3.63.2. Flujo de eventos. ................................................................................................. 100 3.3.3.63.3. Excepciones. ....................................................................................................... 101

3.3.3.64. Caso de Uso – Impresión de conjunta de un acto para varios expedientes. .............. 101 3.3.3.64.1. Descripción ......................................................................................................... 101 3.3.3.64.2. Flujo de eventos. ................................................................................................. 101

4. ARQUITECTURA TECNOLÓGICA .............................................................................................. 102 4.1. ARQUITECTURA..................................................................................................................... 102

4.1.1. FrameworkPA ..................................................................................................................... 103 4.1.2. Bases de Datos .................................................................................................................... 103

4.1.2.1. Esquema de catálogo .................................................................................................... 103

4.1.2.2. Esquema de expedientes .............................................................................................. 103 4.1.3. Service BPEL ...................................................................................................................... 103 4.1.4. Módulo de Autenticación .................................................................................................... 103 4.1.5. Servicio de Número de Expediente ..................................................................................... 104

4.1.6. Servicio de Registro de entrada .......................................................................................... 104 4.1.7. Servicio de Registro de salida ............................................................................................. 104 4.1.8. Módulo de Genéricos .......................................................................................................... 104 4.1.9. Módulo de Terceros ............................................................................................................ 104 4.1.10. Alertas ............................................................................................................................... 104

Page 9: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 9 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

4.1.11. Módulo común de documentación .................................................................................... 104 4.1.11.1.1. Gestor documental .............................................................................................. 105

4.1.12. Modelo de Componentes .................................................................................................. 105

4.1.13. Especificaciones de Integración ........................................................................................ 107 4.1.14. Integración con SAC ......................................................................................................... 107

4.1.14.1. Apuntes en CRM ........................................................................................................ 107 4.1.14.2. Apuntes en el modelo intermedio .............................................................................. 107

4.2. ARQUITECTURA PARA LA TRAMITACIÓN EN BLOQUE. ............................................. 108 4.2.1. Modelo de componentes. .................................................................................................... 108

4.2.1.1. Descripción general del modelo de componentes para la tramitación en bloque. ....... 108 4.2.1.2. Componente: Tramitación en bloque ........................................................................... 109 4.2.1.3. Componente: MTB-Client. .......................................................................................... 109

4.2.1.4. Componente: Gestión Contexto de tramitación. .......................................................... 109 4.2.1.5. Componente: Gestión Carrito. ..................................................................................... 109

4.2.1.6. Componente: Gestión Actos Tramitables. ................................................................... 109 4.2.1.7. Componente: Gestión Resultados Tramitación. ........................................................... 109 4.2.1.8. Componente: Gestión Contexto Tramitación. ............................................................. 110

4.2.1.9. Componente: MTB ...................................................................................................... 110

4.2.1.10. Componente: Validación Tramitación. ...................................................................... 110 4.2.1.11. Componente: Ejecución Tramitación. ........................................................................ 110

4.3. MODELO DINÁMICO ............................................................................................................. 110

4.3.1. Diagrama/s dinámicos ......................................................................................................... 110 4.4. DIAGRAMA DE DESPLIEGUE .............................................................................................. 110

Page 10: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 10 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

1. CONTROL DEL DOCUMENTO

1.1. Información general

Título Análisis funcional

Creado por: Rubén Granda

A revisar por: Consultores Senior: Juan José Parada Vales e Ignacio Álvarez Valdeón

A aprobar por: Jefe de Proyecto: Joaquín Fernández Juárez

1.2. Histórico de revisiones

Versión Fecha Autor Observaciones

0.1 05/01/2011 Rubén Granda

1.0 30/12/2011 Rubén Granda

1.3. Estado del documento

Versión Estado Fecha

0.1 Borrador 05/01/2011

1.0 Definitivo 30/12/2011

Page 11: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 11 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

2. ANÁLISIS DE REQUISITOS

2.1. LISTA DE REQUISITOS FUNCIONALES

ID Descripción Estado Prioridad

RE-1 Búsqueda de Expedientes Crítico

RE-2 Búsqueda Agrupada de Expedientes Crítico

Tramitar en Bloque Crítico

RE-3 Ver Expediente Crítico

RE-4 Ver Ficha Catalográfica del Procedimiento Secundario

RE-5 Modificar Expediente Crítico

RE-6 Alta Interesado Principal Crítico

RE-7 Alta Territorio Crítico

RE-8 Modificar Territorio Crítico

RE-9 Borrar Territorio Crítico

RE-10 Alta Expediente Relacionado Importante

RE-11 Modificar Expediente Relacionado Importante

RE-12 Borrar Expediente Relacionado Importante

RE-13 Alta Expediente Crítico

RE-14 Listar Terceros Crítico

RE-15 Alta Tercero Crítico

RE-16 Modificar Tercero Crítico

RE-17 Borrar Tercero Crítico

RE-18 Alta Dirección Crítico

RE-19 Modificar Dirección Crítico

RE-20 Borrar Dirección Crítico

RE-21 Tramitar Expediente Crítico

RE-22 Ver Documentación Aportada Crítico

RE-23 Aportar Documentación Crítico

RE-24 Editar Documentación Aportada Crítico

RE-25 Alta Alarma Crítico

RE-26 Alta Alerta Crítico

RE-27 Ver Alarmas Crítico

RE-28 Borrar Alarma Crítico

RE-29 Informes Básicos Crítico

RE-30 Informes Avanzados

Page 12: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 12 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

ID Descripción Estado Prioridad

RE-31 Colaboración Crítico

2.2. LISTA DE REQUISITOS NO FUNCIONALES

Especifican propiedades del sistema, como restricciones del entorno o de la implementación

rendimiento, dependencias de la plataforma, requerimientos de interface, facilidad de mantenimiento,

extensibilidad, seguridad, fiabilidad (disponibilidad, exactitud, tiempo medio entre fallos, etc.). Se

recomienda en la descripción especificar de qué tipo de requerimiento se trata.

ID Descripción Estado Prioridad

RN-1 (aprobado, futurible) (crítico, importante o

secundario

RN-2

Page 13: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 13 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3. ANÁLISIS FUNCIONAL

3.1. Modelo de Clases del Dominio

3.2. Modelo de Procesos de Negocio

3.3. Modelado de Casos de Uso

3.3.1. Modelo de Casos de Uso

cd Modelo de Casos de Uso

Empleado Público

(from Actores)

Tramitador

(from Actores)

Buscador

Expedientes

Creación

Expedientes

Informes

Los casos de uso del Empleado

Público <<include>> este como

condición.Autenticación

Visor Expedientes

Terceros

Tramitación

Documentación

Aportada

Alarmas

Aplicación

(from Actores)

Page 14: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 14 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.2. Definición de actores

cd Actores

Tramitador

Aplicación

Empleado Público

Administrador

Nombre Descripción

Empleado Público Representa al personal administrativo del Principado de

Asturias.

Aplicación Representa a los procesos batch de la aplicación.

Administrador Representa al empleado público con permisos de

administración de la aplicación.

Tramitador Representa al empleado público que realiza los trámites

administrativos.

3.3.3. Definición de Casos de Uso

Page 15: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 15 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.1. Caso de Uso – Buscador Expedientes

cd Buscador de Expedientes

Búsqueda de

Expedientes

Empleado Público

(from Actores)

Tramitador

(from Actores)

Tramitar en Bloque(from Modelo de Casos de Uso)

Visor Expedientes

Búsqueda

Agrupada de

Expedientes «include»

3.3.3.2. Caso de Uso – Búsqueda de Expedientes

3.3.3.2.1. Descripción

Permite al actor buscar expedientes utilizando diversos criterios de búsqueda basados en los datos de

los expedientes.

ID Requisito RE-1

Actores Tramitador

Prioridad

Nivel de Riesgo Alto

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla del buscador de expedientes.

El actor establece los criterios de búsqueda.

Postcondiciones La aplicación muestra la lista de expedientes que cumplen el criterio de búsqueda.

Comentarios

Page 16: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 16 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.2.2. Flujo de eventos

Cuando se autentica el empleado público y llega por primera vez al buscador se tiene que ejecutar

automáticamente una búsqueda de todos los expedientes ordenados por criticidad.

El actor está en la pantalla del buscador de expedientes y establece los criterios de búsqueda, y la

aplicación muestra como resultado la lista de expedientes que cumplen dicho criterio.

Los campos de entrada tienen que permitir el uso de comodines, por ejemplo ‘*’.

A partir de esta lista, el actor puede:

Ver el detalle de cada uno de los expedientes

Realizar la tramitación en bloque de los expedientes seleccionados que están en la misma fase

y mismo procedimiento.

Búsqueda con datos del expediente:

Tipo de procedimiento

Fase del procedimiento

Número de expediente

Número de registro

NIF/CIF del interesado principal

Nombre/Razón Social del interesado principal

Asunto del expediente

Expedientes relacionados

Nivel de criticidad del expediente

Estado de archivado

Búsqueda con datos del territorio:

Localidad

Parroquia

Municipio

Provincia

Comunidad Autónoma

Datos de salida de los expedientes encontrados:

Page 17: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 17 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Nivel de criticidad del expediente (el máximo nivel de todas sus alarmas)

Número del expediente

NIF/CIF del interesado principal

Nombre/Razón Social del interesado principal

Asunto del expediente

Fase en la que se encuentra el expediente

Procedimiento al que pertenece el expediente

3.3.3.2.3. Excepciones

Si no se encuentran expedientes, se muestra un mensaje que indica la ausencia de resultados.

3.3.3.3. Caso de Uso – Búsqueda Agrupada de Expedientes

3.3.3.3.1. Descripción

Permite al actor buscar expedientes agrupados por procedimiento y fase utilizando diversos criterios de

búsqueda basados en los datos de los expedientes.

ID Requisito RE-2

Actores Tramitador

Prioridad

Nivel de Riesgo Alto

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla del buscador de expedientes.

El actor establece los criterios de búsqueda.

Postcondiciones La aplicación muestra la lista de expedientes que cumplen el criterio de búsqueda.

Comentarios

3.3.3.3.2. Flujo de eventos

El actor está en la pantalla del buscador de expedientes y establece los criterios de búsqueda, y la

aplicación muestra como resultado la lista de expedientes que cumplen dicho criterio.

Los campos de entrada tienen que permitir el uso de comodines, por ejemplo ‘*’.

A partir de esta lista, el actor puede:

Buscar los expedientes de un procedimiento.

Page 18: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 18 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Buscar los expedientes de un procedimiento en una fase concreta.

Búsqueda con datos del expediente:

Tipo de procedimiento

Fase del procedimiento

Número de expediente

Número de registro

NIF/CIF del interesado principal

Nombre/Razón Social del interesado principal

Asunto del expediente

Expedientes relacionados

Nivel de criticidad del expediente

Estado de archivado

Búsqueda con datos del territorio:

Localidad

Parroquia

Municipio

Provincia

Comunidad Autónoma

Datos de salida de los expedientes encontrados:

Procedimiento

Fases del procedimiento

Número de expedientes en cada fase del procedimiento

3.3.3.4. Caso de Uso – Tramitar en Bloque

3.3.3.4.1. Introducción

Este documento presenta la funcionalidad a desarrollar en el Escritorio Unificado del Gestor para la

inclusión de la tramitación en bloque. Se busca soportar la siguiente casuística:

Sobre la pantalla de búsqueda, seleccionar expedientes arbitrariamente siempre que sean del

mismo procedimiento.

Page 19: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 19 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Sobre la selección dada, elegir un acto del procedimiento en curso y la plantilla asociada.

Para el acto elegido, seleccionar las acciones (comandos) a realizar.

Opcionalmente, se le puede dar un nombre a la tramitación en bloque realizada.

Algunos actos de tramitación en bloque poseerán una pantalla previa a la ejecución de la

tramitación en bloque, a fin de capturar datos relevantes para la ejecución del acto.

Lanzar la tramitación en bloque con los datos anteriores. Esto implica la ejecución secuencial

de los comandos correspondientes al acto, incluyendo: a) comandos incluidos en extensiones a

tipos de acto, b) comandos implementados en aplicaciones de gestión.

Recuperar tramitaciones en bloque anteriores y ver el estado de la tramitación en curso.

Para una tramitación en bloque ya realizada, imprimir la documentación generada, teniendo en

cuenta que ha de ser posible imprimir los acuses de recibo por separado. Esto es necesario

porque el papel o bandeja de la impresora ha de ser distinto (papel preimpreso).

En caso de haber errores en algunos expedientes, informar de éstos (incluye avisos o warnings).

Ofrecer la posibilidad de reintento.

3.3.3.4.2. Conceptos

Estas situaciones se interpretan en función de los siguientes conceptos:

Tramitación en bloque. Ejecución de un acto determinado para un conjunto de expedientes

seleccionados.

Expedientes de tramitación en bloque. Los expedientes seleccionados por el usuario para

ejecutar la tramitación en bloque.

Punto de extensión de la tramitación en bloque. Pantalla que puede lanzarse opcionalmente

al pinchar en ‘Tramitar en Bloque’ para que se capture información adicional que será usada en

el proceso de tramitación en bloque. Por ejemplo, si hace falta una fecha que se usará para

todos los expedientes de la tramitación en bloque, se elaborará un punto de extensión de

tramitación en bloque a fin de que el usuario pueda introducir este dato. Los datos introducidos

serán compartidos por todos los expedientes durante el proceso de tramitación en bloque.

Contexto de tramitación en bloque. Conjunto de datos empleados por la tramitación en

bloque. Debe incluir: el conjunto de expedientes seleccionados, el acto a ejecutar, las acciones

a realizar y los datos obtenidos por el punto de extensión de la tramitación en bloque.

Ejecución de un acto de tramitación en bloque. Cuando se elige un acto, se está solicitando

la ejecución de su máquina de estados. Los usuarios esperan que se ejecuten solo aquellas

acciones dentro de la máquina de estados del acto que son de aplicación para un expediente

dado (por ejemplo, si quiero registrar de salida una notificación de resolución, el sistema no

hará nada en aquellos expedientes que poseen el acto instanciado en estado ACUSAR). Sin

embargo, aprobará y ejecutará el registro de salida en aquellos en que el estado era

BORRADOR). El resultado es que todos los expedientes seleccionados habrán realizado las

Page 20: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 20 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

acciones necesarias para estar en el lugar definido por el usuario al lanzar la tramitación (p.e.

registrados de salida).

Camino de tramitación en bloque. Un camino de tramitación en bloque es un conjunto

ordenado de comandos que se define en catálogo y que se ejecutarán cuando se solicite la

ejecución de un acto.

Tipo de documento. Se definen inicialmente dos tipos de documento – doc. de expediente y

doc. de acuse de recibo. Esta distinción permitirá al usuario imprimir los acuses de recibo por

separado de los documentos generados en el expediente.

Estado de la tramitación en bloque. Información relativa al estado de la tramitación en

bloque, que incluye: nombre de la tramitación en bloque, fechas de inicio y fin, documentación

generada, errores y warnings del proceso.

3.3.3.5. Caso de Uso – Seleccionar expedientes

3.3.3.5.1. Descripción

Permite al usuario seleccionar los expedientes de tramitación en bloque.

ID Requisito

Actores

Prioridad

Nivel de Riesgo

Precondiciones El usuario ha seleccionado un procedimiento en concreto, de manera que

todos los expedientes seleccionables son del mismo procedimiento.

Postcondiciones El usuario seleccionó un conjunto de expedientes

Comentarios

3.3.3.5.2. Flujo de eventos

El sistema muestra la pantalla de búsqueda de expedientes

El usuario selecciona un procedimiento para filtrar la búsqueda. En este punto se habilita la tramitación

en bloque.

El usuario puede seguir introduciendo los criterios de búsqueda adicionales que considere oportunos, y

puede seleccionar uno a uno los expedientes que desee.

También puede solicitar al sistema que seleccione todos o ninguno (borre la selección).

3.3.3.5.3. Excepciones

Page 21: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 21 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.6. Caso de Uso – Seleccionar Trámite

3.3.3.6.1. Descripción

Permite al usuario seleccionar el acto a realizar para los expedientes seleccionados, añadir expedientes

concretos y el camino de tramitación.

ID Requisito

Actores

Prioridad

Nivel de Riesgo

Precondiciones Se ejecutó el caso de uso de selección de expedientes.

Postcondiciones El usuario seleccionó un conjunto de expedientes, un acto y un camino

de tramitación.

Comentarios

3.3.3.6.2. Flujo de eventos

El sistema muestra una lista con los expedientes seleccionados, y permite añadir expedientes

introduciendo su número de expediente. En este caso, el sistema validará que todos los expedientes

seleccionados son del mismo procedimiento.

El usuario puede, opcionalmente, dar un nombre a la tramitación en bloque.

El sistema muestra una lista con los actos del expediente que son susceptibles de tramitación en

bloque. El usuario puede seleccionar un acto de esta lista, e introducir la plantilla a emplear en caso de

que el acto tenga plantillas asociadas.

Asimismo, el usuario puede seleccionar un camino de tramitación en bloque.

Cuando lo desee oportuno, el usuario puede lanzar la tramitación en bloque.

3.3.3.6.3. Excepciones

3.3.3.7. Caso de Uso – Punto de extensión de tramitación en bloque

3.3.3.7.1. Descripción

Permite al usuario introducir información adicional para su uso durante la tramitación en bloque a

través de un punto de extensión.

ID Requisito

Actores

Page 22: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 22 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Prioridad

Nivel de Riesgo

Precondiciones El usuario ejecutó el caso de uso seleccionar trámite

Postcondiciones El usuario introdujo datos adicionales y específicos para el acto

seleccionado.

Comentarios

3.3.3.7.2. Flujo de eventos

El sistema ejecuta el punto de extensión definido en catálogo para el acto seleccionado, caso de existir,

y redirecciona al usuario a la pantalla correspondiente.

El usuario introduce los datos necesarios y pulsa en aceptar.

El sistema almacena en el contexto de tramitación en bloque todos los datos introducidos para su

posterior uso en la tramitación en bloque.

3.3.3.7.3. Excepciones

3.3.3.8. Caso de Uso – Ejecución de la tramitación en bloque

3.3.3.8.1. Descripción

De forma desatendida, el sistema ejecuta la tramitación en bloque.

ID Requisito

Actores

Prioridad

Nivel de Riesgo

Precondiciones El usuario ejecutó el caso de uso de punto de extensión de tramitación en

bloque.

Postcondiciones El sistema realiza la tramitación en bloque.

Comentarios

3.3.3.8.2. Flujo de eventos

El sistema toma la siguiente información, recabada durante los casos de uso anteriores:

Conjunto de expedientes de tramitación en bloque.

Acto de tramitación en bloque.

Camino de tramitación en bloque.

Page 23: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 23 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Contexto de tramitación en bloque.

Para cada expediente seleccionado, realiza las siguientes operaciones:

1. Consulta la lista de tareas para ver el estado del expediente y busca instancias del acto de

tramitación en bloque.

2. Si el acto no está instanciado, lo instancia y coloca la tarea en el estado inicial. Sea T la tarea

creada o hallada en el expediente y T.E el estado actual de la tarea.

3. Toma el camino de tramitación seleccionado CTB= {A1, A2, T.E, Ak, Ak+1, .., An} y busca

T.E en la lista (en posición k-1).

4. Calcula el conjunto CTBE como { Ak, Ak+1, …, An} (CTBE: Camino de Tramitación en

Bloque a Ejecutar, que se corresponde con el conjunto de acciones a realizar para completar las

acciones de CTB).

5. Para cada Ai en CTBE, ejecuta la acción correspondiente.

6. El sistema añade el expediente y los documentos generados durante la ejecución de la

tramitación en bloque al estado de la tramitación en bloque.

3.3.3.8.3. Flujo alternativo de eventos

Puede ocurrir que exista más de un acto por expediente, si éste está configurado en catálogo como de

cardinalidad superior a 1. En este caso, no se realizará ninguna operación sobre el expediente y se

levantará un warning.

TODO: ¿es esta la mejor opción? ¿Se lo debiéramos de preguntar al usuario?

3.3.3.8.4. Excepciones

3.3.3.9. Caso de Uso – Consulta del estado de la tramitación en bloque

3.3.3.9.1. Descripción

El usuario puede consultar el estado de una tramitación en bloque.

ID Requisito

Actores

Prioridad

Nivel de Riesgo

Precondiciones El usuario ejecutó el caso de uso de punto de extensión de tramitación en

bloque.

Postcondiciones El usuario conoce el estado de la tramitación en bloque

Comentarios

Page 24: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 24 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.9.2. Flujo de eventos

El sistema presenta una lista de las tramitaciones en bloque creadas, estén en ejecución o ya hayan

finalizado. El usuario selecciona un procedimiento, y el sistema muestra una lista incluye la siguiente

información:

Nombre

Estado. Puede ser en curso o finalizada.

Fecha de inicio de la TB

Usuario creador

TODO: El usuario puede filtrar los resultados por:

Procedimiento (obligatorio)

Nombre (chequea la inclusión de literal introducido).

Estado

Fecha

El usuario puede seleccionar una tramitación en bloque de la lista, y el sistema le muestra, para cada

acto, la siguiente información:

Número de expediente (TODO: su referencia?). Pinchando en el, puede ir a la pantalla de

tramitar (TODO: le ofrecemos otro enlace para que vaya a la de datos básicos?) para el

expediente dado.

Documentos generados, incluyendo su tipo (si es acuse de recibo o no). Pulsando en cada

documento, puede visualizarlo.

Estado actual de la tarea.

Si posee o no errores o warnings.

El usuario puede seleccionar:

a) todos los documentos generados durante la tramitación en bloque.

b) todos los documentos, excepto los acuses de recibo

c) solo los acuses de recibo

d) documentos individuales

Una vez haya seleccionado los documentos, puede lanzar su impresión.

TODO: Asimismo, puede seleccionar los expedientes que considere oportunos de la lista, y utilizarlos

como lista de expedientes para otra tramitación en bloque.

Page 25: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 25 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.9.3. Cambios a realizar

Los cambios identificados son los siguientes:

Dónde Qué

Pantalla:

Buscador de

expedientes

En la pantalla de tramitación en bloque se añade un botón que se habilita cuando el combo de

procedimiento tiene un valor seleccionado. Para cada expediente, se añade un checkbox para

seleccionar cada expediente en concreto.

Asimismo, se añadirán botones para seleccionar todos los expedientes, o ninguno.

Pantalla:

Selección trámite

Crear la pantalla, teniendo en cuenta que ha de poder aceptar una lista de expedientes

suministrada desde:

a) el buscador.

b) el resultado de una tramitación en bloque (los warnings/errores).

Punto de

extensión 1.

La pantalla de selección de trámite es un punto de extensión.

Punto de

extensión 2.

Una vez se termina con la pantalla de selección de trámite se pasa a otro punto de

extensión.

Motor

tramitación en

bloque

Para los datos obtenidos en las pantallas anteriores, se implementa el algoritmo en el

motor de tramitación en bloque.

Buscador de

tramitación en

bloque

Pantalla de listado y búsqueda de tramitación en bloque

Resultado

tramitación en

bloque

Pantalla donde se listan los documentos generados durante una tramitación en bloque.

Catálogo

Tabla de caminos de tramitación en bloque.

Tabla de relación camino de tramitación en bloque <-> acción_acto

Añadir un campo en la tabla accion para identificar el bean que ejecutará la tramitación en

bloque

Añadir un método al interface de comando para la lógica de tramitación en bloque.

Modelo de datos

del expediente Tabla de histórico de tramitaciones en bloque

Acciones

existentes

Han de refactorizarse para poder ejecutarse en modo desatendido.

Ha de incluirse la capacidad de llamarse a acciones implementadas en gestión, quizás en

otros sistemas. Esto requiere:

a) implementar un comando que invoque remotamente un servicio web con el interface

que nosotros decidamos.

b) Definir un interface de invocación remota (servicio web) que las aplicaciones de

gestión han de implementar para llamar a su acción.

Popup de

documento Añadir el tipo de documento (es un doc. generado, es un acuse de recibo).

Comunicación

horizontal /

motor de

tramitación

Es necesario implementar algún mecanismo (colas/BD/etc) para lanzar la tramitación en

bloque desde el GUI implementado en el horizontal.

Page 26: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 26 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.9.4. Descripción

Permite al actor tramitar expedientes que están en la misma fase y mismo procedimiento.

ID Requisito RE-

Actores Tramitador

Prioridad

Nivel de Riesgo Bajo

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla del buscador de expedientes.

El actor elige el conjunto de expedientes a tramitar de la lista de encontrados en la búsqueda.

Postcondiciones ¿??

Comentarios

3.3.3.9.5. Flujo de eventos

3.3.3.10. Caso de Uso – Cerrar Fase en Bloque.

Este caso de uso permite la cerrar la fase actual para varios expedientes simultáneamente.

3.3.3.10.1. Descripción

ID Requisito

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones Se dispone de un carrito de tramitación en bloque.

Postcondiciones Se cierra la fase de los expedientes seleccionados.

Comentarios

3.3.3.10.2. Flujo de eventos.

El actor Tramitador ha seleccionado un conjunto de expedientes en el carrito de tramitación en

bloque y se encuentra en la pantalla de configuración para iniciar la tramitación en bloque.

El actor pulsa el botón de “Cerrar Fase en Bloque”.

Se inicia el proceso asíncrono, ejecutándose el caso de uso de “Cerrar Fase” para cada uno de

los expedientes seleccionados.

Se muestra una pantalla con el progreso en el que se encuentra el proceso de cerrar fase.

Page 27: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 27 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Al finalizar el proceso se mostrará, los expedientes que se han cerrado con la información de la

nueva fase en la que se encuentra el expediente.

En el caso de que no se pueda cerrar fase en algún expediente seleccionado, se indicará el fallo

y la razón por la cual no ha sido posible cerrar la fase del expediente.

3.3.3.11. Caso de Uso – Visor Expedientes

cd Visor de Expedientes

Empleado Público

(from Actores)

Tramitador

(from Actores)

Modificar

ExpedienteAlta Territorio

Modificar Territorio

Borrar Territorio

Alta Expediente

Relacionado

Modificar

Expediente

Relacionado

Borrar Expediente

Relacionado

Alta Interesado

Principal

(from Modelo de Casos de Uso)

Terceros

(from Modelo de Casos de Uso)

Tramitación

(from Modelo de Casos de Uso)

Documentación

Aportada

Ver Expediente

Ver Ficha

Catalográfica del

Procedimiento

3.3.3.12. Caso de Uso – Ver Expediente

3.3.3.12.1. Descripción

Permite al actor ver los datos de un expediente.

Page 28: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 28 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

ID Requisito RE-3

Actores Tramitador

Prioridad

Nivel de Riesgo Alto

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla del buscador de expedientes.

El actor elige un expediente de la lista de encontrados en la búsqueda.

Postcondiciones La aplicación muestra el detalle del expediente en el visor de expedientes.

Comentarios

3.3.3.12.2. Flujo de eventos

El actor realiza una búsqueda de expedientes, selecciona uno de la lista de encontrados y se le muestra

en el visor de expedientes el detalle del expediente.

Datos básicos del expediente:

Número de expediente

Número de registro

Fecha de inicio de plazo

Fecha de registro

Asunto

Datos particulares del expediente según la familia

Datos del interesado principal del expediente:

NIF/CIF

Nombre/Razón Social

Dirección de notificación

Teléfono

Datos de los territorios del expediente:

Tipo

Municipio

Parroquia

Localidad

Provincia

Page 29: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 29 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Comunidad Autónoma

Datos de los expedientes relacionados con el expediente:

Número de expediente

Asunto del expediente

NIF/CIF del interesado principal

Nombre/Razón Social del interesado principal

Propietario del expediente

3.3.3.12.3. Excepciones

3.3.3.13. Caso de Uso – Ver Ficha Catalográfica del Procedimiento

3.3.3.13.1. Descripción

Permite al actor ver la ficha catalográfica del procedimiento de un expediente.

ID Requisito RE-4

Actores Tramitador

Prioridad

Nivel de Riesgo Alto

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla del visor de expedientes.

El actor elige la opción de ver la ficha catalográfica.

Postcondiciones La aplicación muestra el detalle de la ficha catalográfica del procedimiento.

Comentarios

3.3.3.13.2. Flujo de eventos

El actor está en la pantalla del visor de expedientes y selecciona la opción de ver la ficha catalográfica

del procedimiento del expediente y la aplicación presenta una pantalla con el detalle de la ficha.

3.3.3.13.3. Excepciones

Page 30: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 30 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.14. Caso de Uso – Modificar Expediente

3.3.3.14.1. Descripción

Permite al actor modificar los datos de un expediente.

ID Requisito RE-5

Actores Tramitador

Prioridad

Nivel de Riesgo Alto

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla del visor de expedientes.

El actor modifica los datos del expediente.

Postcondiciones La aplicación actualiza los datos del expediente.

Comentarios

3.3.3.14.2. Flujo de eventos

El actor está en el visor de expedientes con los datos del expediente identificado, modifica los datos

del expediente y la aplicación los actualiza.

Datos básicos del expediente:

Número de expediente

Número de registro

Fecha de inicio de plazo

Fecha de registro

Asunto

Datos particulares del expediente según la familia

3.3.3.14.3. Excepciones

3.3.3.15. Caso de Uso – Alta del Interesado Principal

Permite al actor dar de alta al interesado principal de un expediente.

3.3.3.15.1. Descripción

Page 31: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 31 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

ID Requisito RE-6

Actores Tramitador

Prioridad

Nivel de Riesgo Alto

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla del visor de expedientes y selecciona dar de alta al interesado

principal.

El actor rellena los datos del tercero.

Postcondiciones La aplicación da de alta el tercero asociándolo al expediente como el interesado principal.

Comentarios

3.3.3.15.2. Flujo de eventos

El actor está en la pantalla del visor del expediente y selecciona la opción de dar de alta al interesado

principal, a continuación se le presenta la pantalla de buscar/añadir terceros, la rellena, y la aplicación

da de alta al tercero asociándolo al expediente como el interesado principal.

Una vez que el expediente ya tiene interesado principal, se elimina la opción de dar de alta más

interesados principales, ya que solo puede haber uno por expediente.

Además, la dirección de interesado principal es obligatoria por ser la dirección de notificación por

defecto del expediente.

3.3.3.15.3. Excepciones

3.3.3.16. Caso de Uso – Alta de Territorio

Permite al actor dar de alta territorios asociados a los expedientes.

3.3.3.16.1. Descripción

ID Requisito RE-7

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla del visor de expedientes y selecciona dar de alta un territorio.

El actor rellena los datos del territorio.

Page 32: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 32 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Postcondiciones La aplicación da de alta un nuevo territorio asociado al expediente.

Comentarios

3.3.3.16.2. Flujo de eventos

El actor está en la pantalla del visor del expediente, presentando los territorios en formato tabla y

selecciona la opción de dar de alta un territorio, a continuación se le presenta la pantalla de

introducción de datos de territorios, la rellena, y la aplicación da de alta un nuevo territorio asociado al

expediente.

Datos de territorio:

Peso dentro del expediente

Localización

Municipio

Localidad

Provincia

Comunidad Autónoma

País

3.3.3.16.3. Excepciones

3.3.3.17. Caso de Uso – Modificar Territorio

Permite al actor modificar los territorios asociados a los expedientes.

3.3.3.17.1. Descripción

ID Requisito RE-8

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla del visor de expedientes y selecciona editar un territorio.

El actor modifica los datos del territorio.

Postcondiciones La aplicación actualiza el territorio.

Comentarios

Page 33: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 33 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.17.2. Flujo de eventos

El actor está en la pantalla del visor del expediente, presentando los territorios en formato tabla y

selecciona la opción de editar un territorio, a continuación se le presenta la pantalla de modificación de

datos de territorios, la modifica, y la aplicación actualiza el territorio.

Datos del territorio:

Peso dentro del expediente

Localización

Municipio

Localidad

Provincia

Comunidad Autónoma

País

3.3.3.17.3. Excepciones

3.3.3.18. Caso de Uso – Borrar Territorio

Permite al actor eliminar los territorios asociados a los expedientes.

3.3.3.18.1. Descripción

ID Requisito RE-9

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones El actor está autenticado en la aplicación.

El actor está en la pantalla del visor de expedientes y selecciona eliminar un territorio.

Postcondiciones La aplicación elimina el territorio del expediente.

Comentarios

3.3.3.18.2. Flujo de eventos

El actor está en la pantalla del visor del expediente, presentando los territorios en formato tabla,

selecciona la opción de eliminar un territorio y la aplicación lo borra del expediente.

Page 34: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 34 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Antes de ejecutar la orden de borrado, la aplicación presenta al usuario una pantalla de confirmación

de la orden.

3.3.3.18.3. Excepciones

3.3.3.19. Caso de Uso – Alta de Expediente Relacionado

Permite al actor relacionar expedientes.

3.3.3.19.1. Descripción

ID Requisito RE-10

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla del visor de expedientes y selecciona dar de alta un expediente

relacionado.

El actor rellena los datos de la relación entre los expedientes.

Postcondiciones La aplicación da de alta un nuevo expediente relacionado.

Comentarios

3.3.3.19.2. Flujo de eventos

El actor está en la pantalla del visor del expediente, presentando los expedientes relacionados en

formato tabla y selecciona la opción de dar de alta un expediente relacionado, a continuación se le

presenta la pantalla de gestión de datos del expediente relacionado, la rellena, y la aplicación da de alta

un nuevo expediente relacionado.

Datos de los expedientes relacionados:

Número del expediente relacionado

Asunto del expediente relacionado

Interesado del expediente relacionado

Propietario del expediente relacionado

Descripción de la relación

Page 35: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 35 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.19.3. Excepciones

3.3.3.20. Caso de Uso – Modificar Expediente Relacionado

Permite al actor modificar los expedientes relacionados.

3.3.3.20.1. Descripción

ID Requisito RE-11

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla del visor de expedientes y selecciona modificar un expediente

relacionado.

El actor modifica los datos de la relación entre los expedientes.

Postcondiciones La aplicación actualiza el expediente relacionado.

Comentarios

3.3.3.20.2. Flujo de eventos

El actor está en la pantalla del visor del expediente, presentando los expedientes relacionados en

formato tabla y selecciona la opción de modificar un expediente relacionado, a continuación se le

presenta la pantalla de gestión de datos del expediente relacionado, la modifica, y la aplicación

actualiza el expediente relacionado.

Datos de los expedientes relacionados:

Número del expediente relacionado

Asunto del expediente relacionado

Interesado del expediente relacionado

Propietario del expediente relacionado

Descripción de la relación

3.3.3.20.3. Excepciones

Page 36: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 36 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.21. Caso de Uso – Borrar Expediente Relacionado

Permite al actor eliminar expedientes relacionados.

3.3.3.21.1. Descripción

ID Requisito RE-12

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla del visor de expedientes y selecciona eliminar un expediente

relacionado.

Postcondiciones La aplicación elimina el expediente relacionado.

Comentarios

3.3.3.21.2. Flujo de eventos

El actor está en la pantalla del visor del expediente, presentando los expedientes relacionados en

formato tabla, selecciona la opción de eliminar un expediente relacionado y la aplicación borrar el

expediente relacionado.

Antes de ejecutar la orden de borrado, la aplicación presenta al usuario una pantalla de confirmación

de la orden.

3.3.3.21.3. Excepciones

Page 37: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 37 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.22. Caso de Uso – Creación Expedientes

cd Creación de Expedientes

Alta Expediente

Empleado Público

(from Actores)

Tramitador

(from Actores)

(from Modelo de Casos de Uso)

Visor Expedientes

3.3.3.23. Caso de Uso – Alta Expediente

Permite al actor dar de alta expedientes.

3.3.3.23.1. Descripción

ID Requisito RE-13

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor elige la opción de crear expediente.

El actor rellena los datos del expediente.

Postcondiciones La aplicación da de alta un nuevo expediente.

Comentarios

3.3.3.23.2. Flujo de eventos

El actor selecciona la opción de creación de expedientes y escoge el procedimiento administrativo del

expediente, a continuación la aplicación presenta la pantalla del visor de expedientes con los campos

vacíos, el actor los rellena y la aplicación da de alta un nuevo expediente.

Page 38: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 38 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Además es obligatorio dar de alta al interesado principal del expediente.

Datos básicos del expediente:

Número de expediente (se obtiene de un servicio externo y no es editable)

Fecha de inicio de plazo (por defecto la del sistema)

Número de registro

Fecha de registro

Asunto (por defecto será el asunto del procedimiento)

Datos particulares del expediente según la familia

3.3.3.23.3. Flujo alternativo

Los datos básicos del expediente y del interesado principal se pueden rellenar de manera automática

mediante la opción de obtenerlos vía lectura del registro de entrada, bajo las condiciones:

1. La fecha de inicio, por defecto, es igual a la fecha de registro.

2. El número de registro es editable.

3. La fecha de registro es editable.

3.3.3.23.4. Excepciones

Cuando se crea el expediente, hay que dar de alta, para el interesado principal, toda la documentación

que tiene que aportar al procedimiento (obligatoria o no), en estado de no entregado, para mostrarlo

posteriormente en el histórico de la documentación aportada al expediente.

Page 39: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 39 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.24. Caso de Uso – Terceros

cd Terceros

Alta Tercero

Borrar Tercero

Listar Terceros del

Expediente

Tramitador

(from Actores)

Empleado Público

(from Actores)

Alta Direccion

Modificar

Direccion

Borrar Direccion

Listar Direcciones

de Terceros

Alta Tercero Sin

Validar

Alta Tercero

Validado

Buscar Tercero

Editar Tercero

Validar Tercero

Modificar Tercero

«extend» «extend»«extend»

«extend»

«include»

3.3.3.25. Caso de Uso – Listar Terceros del Expediente

Permite al actor ver los terceros asociados a un expediente junto con sus direcciones.

3.3.3.25.1. Descripción

ID Requisito RE-14

Actores Tramitador

Page 40: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 40 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Prioridad

Nivel de Riesgo Alta

Precondiciones El actor está autenticado en la aplicación.

El actor está en la pantalla de gestión de terceros del expediente.

Postcondiciones La aplicación muestra la lista de terceros del expediente y sus direcciones.

Comentarios

3.3.3.25.2. Flujo de eventos

El actor selecciona la pantalla de gestión de terceros del expediente y se le muestra una tabla con los

terceros asociados al mismo, resaltando el tercero que corresponde con el interesado principal.

Por cada tercero seleccionado, se muestra una tabla con sus direcciones asociadas, resaltando la

dirección de notificación.

Datos mostrados por cada tercero:

NIF/CIF

Nombre y Apellidos

Relación en el expediente

Dirección de notificación

Teléfono

Datos mostrados por cada dirección:

Tipo de dirección

Descripción de la dirección

3.3.3.25.3. Excepciones

3.3.3.26. Caso de Uso – Alta Tercero

Permite al actor dar de alta terceros asociados a los expedientes, tanto físicos como jurídicos.

3.3.3.26.1. Descripción

Page 41: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 41 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

ID Requisito RE-15

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla de gestión de terceros.

El actor selecciona la opción de dar de alta un tercero y rellena sus datos.

Postcondiciones La aplicación da de alta un nuevo tercero.

Comentarios

3.3.3.26.2. Flujo de eventos

El actor está en la pantalla de gestión de terceros y selecciona la opción de dar de alta un tercero, la

aplicación le presenta la pantalla de buscar/añadir tercero.

Primero se busca al tercero en la base de datos de terceros del Principado por:

a) Tercero Físico NIF/NIE, Nombre y Apellidos

b) Tercero Jurídico CIF y Razón Social

Si el resultado en positivo se muestra la tabla de resultados que cumplen las condiciones de búsqueda

para que el actor identifique el tercero que se añade al expediente estableciéndole además el tipo de

relación con el expediente.

Datos de salida de la búsqueda del tercero:

NIF/CIF

Nombre

Relación con el expediente que establece el actor

Si el resultado en negativo, el actor selecciona la opción de añadir al tercero con o sin identificación

fiscal para validarlo contra la base de datos de terceros del Principado.

a) Sin identificación fiscal no se permitirá terminar el procedimiento y se le establecerá como no

validado.

b) Con identificación fiscal se le dará de alta en la base de datos de Terceros del Principado y se le

establecerá como validado.

Page 42: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 42 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Datos del tercero:

Indicador de interesado principal

NIF/NIE (en caso del tercero con validación)

Nombre

Apellidos

Sexo

Estado Civil

Fecha de Nacimiento

Indicador de si está validado o no

Datos de la dirección postal de notificación del tercero:

Tipo de Vía

Dirección

Localidad

Parroquia

Municipio

Provincia

Comunidad

Teléfonos

Datos de la dirección telemática de notificación del tercero:

Dirección de correo electrónico

Solo puede haber una dirección de notificación, que por defecto, será la dirección postal, en caso de

estar vacía, será la telemática, y si ambas están vacías, ninguna.

3.3.3.26.3. Flujo alternativo

(alta de un organismo)

Page 43: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 43 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.26.4. Esquema

Nuevo Expediente

Añadir

Interesado PrincipalAñadir Organismos

Buscar Tercero(BD Teceros)

Añadir

Tercero Sin Validar

Añadir

Tercero Validado

No se dispone de DNI

Para dar el alta en terceros

Disponible en terceros o

Alta al disponer de NIF/CIF/NIE

Solicitud Alta

Solo una dirección de notificación

Campo NIF/CIF/NIE desabilitado

Persona Físicas

Persona Júdiricas

Se dispone de CIF/NIF/NIE

(subsanar)

Dirección Principal

(BD Terceros)

Direcciones Notificación(n direcciones)

Postales

Telemáticas

También puede ser de notificación

(si no existe otra)

Añadir Tercero al expediente

3.3.3.27. Caso de Uso – Modificar Tercero

Permite al actor modificar los terceros asociados a los expedientes, tanto físicos como jurídicos.

3.3.3.27.1. Descripción

ID Requisito RE-16

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla de gestión de terceros.

El actor selecciona la opción de modificar un tercero y rellena sus datos.

Postcondiciones La aplicación actualiza el tercero.

Comentarios

Page 44: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 44 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.27.2. Flujo de eventos

El actor está en la pantalla de gestión de terceros y selecciona la opción editar/validar un tercero en

función si está validado o no.

a) Si está validado, la aplicación le presenta la pantalla de modificación de los datos de terceros,

el actor los modifica y la aplicación actualiza el tercero.

Datos del tercero:

Indicador de interesado principal

NIF/NIE

Nombre

Apellidos

Sexo

Estado Civil

Fecha de Nacimiento

Indicador de si está validado o no

b) Si no está validado, la aplicación le presenta la pantalla de validar terceros, el actor introduce

los datos a modificar y obligatoriamente el identificador fiscal para validarlo.

Si la validación es positiva, el actor puede actualizar los datos del tercero en el expediente.

Si la validación en negativa, el actor puede dar de alta al tercero en la base de datos de terceros

del Principado y a continuación actualizar los datos en el expediente.

Una vez validado hay que actualizar el indicador de validación del tercero.

3.3.3.27.3. Excepciones

3.3.3.28. Caso de Uso – Borrar Tercero

Permite al actor eliminar los terceros asociados a los expedientes.

Page 45: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 45 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.28.1. Descripción

ID Requisito RE-17

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla de gestión de terceros.

El actor selecciona la opción de eliminar un tercero.

Postcondiciones La aplicación elimina el tercero del expediente.

Comentarios

3.3.3.28.2. Flujo de eventos

El actor está en la pantalla de gestión de terceros, elige la opción de eliminar un tercero y la aplicación

lo borra del expediente.

Antes de ejecutar la orden de borrado, la aplicación presenta al usuario una pantalla de confirmación

de la orden.

3.3.3.28.3. Excepciones

No se permite eliminar al tercero que representa al interesado principal del expediente.

3.3.3.29. Caso de Uso – Alta Dirección

Permite al actor dar de alta direcciones asociadas a los terceros de un expediente.

3.3.3.29.1. Descripción

ID Requisito RE-18

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla de gestión de terceros.

El actor selecciona un tercero y la opción de dar de alta una dirección.

Postcondiciones La aplicación da de alta una nueva dirección al tercero.

Comentarios

Page 46: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 46 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.29.2. Flujo de eventos

El actor está en la pantalla de gestión de terceros, selecciona un tercero para listar sus direcciones,

elige la opción de dar de alta una nueva dirección para ese tercero y la aplicación presenta la pantalla

de introducción de datos de una dirección. El actor rellena los datos y la aplicación da de alta una

nueva dirección mostrándose en la lista de direcciones del tercero.

Datos de la dirección postal del tercero:

Tipo de Vía

Dirección

Localidad

Parroquia

Municipio

Provincia

Comunidad

Teléfonos

Datos de la dirección telemática del tercero:

Dirección de correo electrónico

3.3.3.29.3. Excepciones

3.3.3.30. Caso de Uso – Modificar Dirección

Permite al actor modificar las direcciones asociadas a los terceros de un expediente.

3.3.3.30.1. Descripción

ID Requisito RE-19

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla de gestión de terceros.

El actor selecciona un tercero y la opción de modificar una dirección.

Page 47: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 47 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Postcondiciones La aplicación actualiza la dirección al tercero.

Comentarios

3.3.3.30.2. Flujo de eventos

El actor está en la pantalla de gestión de terceros, selecciona un tercero para listar sus direcciones,

elige la opción de modificar una dirección de ese tercero y la aplicación presenta la pantalla de

modificación de datos de una dirección. El actor modifica los datos y la aplicación actualiza la

dirección mostrándose en la lista de direcciones del tercero.

Datos de la dirección postal del tercero:

Tipo de Vía

Dirección

Localidad

Parroquia

Municipio

Provincia

Comunidad

Teléfonos

Datos de la dirección telemática del tercero:

Dirección de correo electrónico

3.3.3.30.3. Excepciones

3.3.3.31. Caso de Uso – Borrar Dirección

Permite al actor eliminar las direcciones asociados a los terceros de un expediente.

3.3.3.31.1. Descripción

ID Requisito RE-20

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Page 48: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 48 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla de gestión de terceros.

El actor selecciona un tercero y la opción de eliminar una dirección.

Postcondiciones La aplicación elimina la dirección del tercero.

Comentarios

3.3.3.31.2. Flujo de eventos

El actor está en la pantalla de gestión de terceros, selecciona un tercero para listar sus direcciones,

elige la opción de eliminar una dirección de ese tercero y la aplicación la borra del tercero.

Antes de ejecutar la orden de borrado, la aplicación presenta al usuario una pantalla de confirmación

de la orden.

3.3.3.31.3. Excepciones

Si se borra la dirección de notificación, entonces la dirección principal pasa a ser la de notificación por

defecto.

Page 49: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 49 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.32. Caso de Uso – Tramitar Expediente

cd Tramitación

Tramitador

(from Actores)

Empleado Público

(from Actores)

Tramitar

Cerrar Fase

Volv er a Fase

Anterior

Crear Acto

Permite al actor tramitar los expedientes.

3.3.3.32.1. Descripción

ID Requisito RE-21

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones El actor está autenticado en la aplicación.

El actor está en la pantalla de tramitación.

Postcondiciones

Comentarios

3.3.3.32.2. Tramitar

La pantalla de tramitación consta de dos partes

Page 50: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 50 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

1. La lista de actos que el actor ha instanciado hasta el momento (documentos tramitados).

2. La lista de actos, tanto obligatorios como opcionales, que el actor puede instanciar en cada

momento (documentos tramitables en cada fase).

Existen tres tipos de actos:

1. Los actos obligatorios en el que se definen las fases en las que se crean y se cierran

2. Los actos opcionales en cada fase

3. Los actos opcionales durante todo el procedimiento (actos de ordenación)

Los actos de los procedimientos tienen asignados dos tipos de roles:

1. Roles que pueden instanciar el acto

2. Roles al que se le asigna el acto, es decir, los que lo pueden ejecutar

Datos de la lista de actos tramitados, se pueden listar por fase o por procedimiento:

Fase en la que se generó el documento

Nombre del documento

Plantilla utilizada para la generación del documento

Usuario que instanció el acto y por tanto generó el documento

Fecha de creación del documento

Estado del documento

Notas sobre el documento

Los actos tienen asociados una serie de acciones en función de su estado:

Page 51: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 51 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

sm Acto Generico Sin Notificación

Nuevo Acto

Borrador

Aprobado

Finalizado

Eliminar Acto

Acto Genérico Sin Notificación

[Crear]

[Anular]

[Aprobar]

[Finalizar]

[Anular]

Page 52: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 52 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

sm Acto Generico de Notificación

Borrador

Nuevo Acto

Acto Genérico Con Notificación

Aprobado

Registro Salida

Env iado

Esperar Respuesta

Finalizado

Cerrar: solo debería aparecer cuando ha

caducado el plazo del usuario

El tercero envia en plazo la comunicación

o la documentación solicitada

Tipos

- Comunicación

- Notificación

Eliminar Acto

[Editar] [Anular]

[Aprobar]

[Crear]

[Anular]

[Editar]

[Acusar]

[Registrar Salida]

[Acusar]

[Cumplimentar]

[Finalizar][Cerrar]

Datos de la lista de actos tramitables:

Nombre del documento

Page 53: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 53 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Indicador de obligatoriedad del documento

Plantilla a utilizar para generar el documento

Roles que pueden instanciar el acto (separados por comas)

Roles al que se le asigna el acto, es decir, los que lo pueden ejecutar (separados por comas)

La lista de documentos tramitables se irá actualizando en función de la definición de cada una de las

fases, es decir:

Si el documento no es repetible en la fase, se elimina de la lista de documentos tramitables para

evitar la repetición del mismo. Solo volvería a estar disponible si es anulado.

Si el documento es repetible en la fase, se mantiene en la lista de documentos tramitables para

permitir la generación de más documentos de ese tipo.

Si en la fase existe una secuencia de documentos obligatorios, estos irán apareciendo en la lista

de documentos tramitables a la vez que se van generando.

Pueden existir actos que tengan que ser finalizados en una fase concreta, en caso de no hacerse

no se dejará finalizar la fase.

3.3.3.32.3. Crear Acto

El actor selecciona la plantilla del documento a generar y elije la opción de crearlo, la aplicación lo

muestra y lo da de alta en la lista de documentos generados con el estado de “borrador”.

Existen algunos actos, donde al crearlos necesitan de una pantalla previa de introducción de datos

específicos para ese acto.

3.3.3.32.4. Cerrar Fase

El actor puede cerrar la fase actual siempre que todos los actos obligatorios de esa fase estén cerrados.

Flujo de Eventos.

El actor pulsa el botón de cerrar fase.

El sistema actualiza la fase y lanza los actos de instanciación automática.

Page 54: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 54 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Excepciones:

En el caso de haber cerrado ya la fase actual anteriormente, es decir, el actor ha pulsado

“Volver a Fase Anterior”, se actualizará la fase y se lanzarán únicamente los actos de

instanciación automática que son repetibles.

3.3.3.32.5. Volver a Fase Anterior

El actor puede volver a la fase anterior para hacer cambios a los documentos de esa fase.

3.3.3.32.6. Finalizar Expediente

Acuerdo

Caducidad

Desestimar

Desierto

Desistimiento

Error

Estimar

Inadmitir

Renuncia

Silencio

3.3.3.32.7. Excepciones

Page 55: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 55 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.33. Caso de Uso – Documentación Aportada

Page 56: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 56 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.34. Caso de Uso - Mostrar Documentación Sin aportar

Muestra la lista de documentación por aportar.

3.3.3.34.1. Descripción.

ID Requisito RE-34

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones

El actor está autenticado en la aplicación.

El actor identifica un expediente.

El actor selecciona la pantalla de gestión de documentación aportada.

Existe documentación sin aportar.

Postcondiciones La aplicación muestra la lista de documentos sin aportar del expediente.

Comentarios Como se comenta en los casos de uso relacionados, sólo se mostrarán los documento de la

fase en la que se encuentre el expediente.

3.3.3.34.2. Flujo de eventos.

El actor identifica un expediente y selecciona la pantalla de gestión de documentación aportada y la

aplicación muestra la lista de documentos que faltan por aportar del expediente seleccionado.

Para conseguir la lista completa, usa los dos casos de uso siguientes (“Advertir Sin Tercero Asignado”

y “Listar Con Tercero Asignado”)

3.3.3.34.3. Excepciones.

3.3.3.35. Caso de Uso – Advertir Sin Tercero Asignado

Muestra la lista de documentación por aportar, para la cual no existe ningún tercero con el role

necesario relacionado con el expediente.

3.3.3.35.1. Descripción.

ID Requisito RE-35

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones

Se ha seleccionado un expediente para aportar documentación.

Existe documentación sin aportar.

Existe documentación para la que no existen terceros relacionado con el role necesario para el

expediente que se está tratando.

Page 57: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 57 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Postcondiciones La aplicación muestra la lista de documentos sin aportar del expediente, para los cuales no

existen terceros con el role adecuado.

Comentarios Sólo se mostrarán los documento de la fase en la que se encuentre el expediente.

3.3.3.35.2. Flujo de eventos.

Datos mostrados del documento:

Nombre del documento: CIF, CV, etc...

Tipo del documento: Obligatorio u opcional.

Fase: Fase en la que se debe aportar el documento

Role: Role que debe tener el tercero que se relacionará con este documento.

Texto informativo: Se mostrará que el documento está sin aportar y que además no existe

tercero relacionado con el expediente, con los roles necesarios.

Texto informativo: En caso de ser obligatorio, se indicará resaltado mediante un icono de

alerta.

3.3.3.35.3. Excepciones.

3.3.3.36. Caso de Uso – Listar Con Tercero Asignado

Muestra al lista de documentación por aportar, para la cual existe tercero con el role necesario

relacionado con el expediente.

Se buscarán los terceros de expediente. Por cada tercero y según su role, se calcularán los documentos

que debería aportar. Si no se han aportado, se mostrará una línea con los datos del documento.

En esta última situación (documento sin aportar por el tercero), se usará el caso de uso ”Mostrar

Transiciones” para mostrar las acciones posibles usando el soporte por defecto para el documento.

3.3.3.36.1. Descripción.

ID Requisito RE-36

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones

Se ha seleccionado un expediente para aportar documentación.

Existe documentación sin aportar para la que existen terceros relacionado con el role

necesario para el expediente que se está tratando.

Postcondiciones La aplicación muestra la lista de documentos sin aportar del expediente, para los cuales no

existen terceros con el role adecuado.

Comentarios Sólo se mostrarán los documento de la fase en la que se encuentre el expediente.

Page 58: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 58 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.36.2. Flujo de eventos.

Datos mostrados del documento:

Nombre del documento: CIF, CV, etc...

Tipo del documento: Obligatorio u opcional.

Fase: Fase en la que se debe aportar el documento

Role: Role que debe tener el tercero que se relacionará con este documento.

Texto informativo: Se mostrará que el documento está sin aportar.

Texto informativo: En caso de ser obligatorio se indicará resaltado mediante un icono de alerta.

Datos mostrados del tercero:

Identificación Fiscal.

Soporte. Combo con el soporte por defecto seleccionado. Ver caso de uso “Selección de

Soporte”, ya que ciertos soportes no se mostrarán.

Datos mostrado de las transiciones:

Se usará el caso de uso “Mostrar Transiciones” para mostrar las transiciones que se pueden

ejecutar, en función del role del tercero, del soporte por defecto y el documento.

3.3.3.36.3. Excepciones.

3.3.3.37. Caso de Uso – Mostrar Transiciones

Muestra la lista de acciones que se pueden ejecutar sobre el documentos.

Las acciones dependen del role del tercero y el soporte.

3.3.3.37.1. Descripción.

ID Requisito RE-37

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones

Se ha seleccionado un expediente para aportar documentación.

Se ha seleccionado un documento y un tercero.

Se ha seleccionado un soporte.

Postcondiciones Lista las acciones que se pueden realizar sobre el documento para el role, soporte indicado y

estado.

Comentarios Si no se indica estado, se muestran las transiciones por defecto (transiciones iniciales).

3.3.3.37.2. Flujo de eventos.

Page 59: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 59 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Se indicará el documento, el role y el soporte, y se mostrará la lista de transiciones que se pueden

ejecutar.

Todas las transiciones pueden tener asociada un comentario y un icono.

3.3.3.37.3. Excepciones.

3.3.3.38. Caso de Uso – Transición Con Tercero Asignado

El actor aporta un documento para el tercero – soporte seleccionado.

Se realiza la aportación ejecutando una de las transiciones que se muestran para este

documento/role/soporte usando el caso de uso “Mostrar Transiciones”.

El documento se añade al workflow.

3.3.3.38.1. Descripción.

ID Requisito RE-38

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones

Se ha seleccionado un expediente para aportar documentación.

Se ha seleccionado un documento y un tercero.

Se ha seleccionado un soporte.

Existe documentación sin aportar para la que existen terceros relacionado con el role

necesario para el expediente que se está tratando.

Postcondiciones

Comentarios

3.3.3.38.2. Flujo de eventos.

Se indicará el documento, el role y el soporte, y se ejecutará la transición seleccionada.

3.3.3.38.3. Excepciones.

3.3.3.39. Caso de Uso – Selección de Soporte

El actor selecciona un soporte de un tercero / documento.

3.3.3.39.1. Descripción.

Page 60: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 60 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

ID Requisito RE-39

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones

Se ha seleccionado un expediente para aportar documentación.

Se ha seleccionado un documento y un tercero.

Existe documentación sin aportar para la que el tercero/role.

Postcondiciones

Lista de nuevo los soportes, con la nueva selección.

Refresca la lista de acciones usando el caso de uso “Mostrar Transiciones”

El check de selección para el caso de uso “Aportar En Bloque” se habilitará o deshabilitará en

función de se el soporte es o no “PAPEL”.

Comentarios No todos los soportes se mostrarán ya que algunos no permiten interacción con el usuario.

3.3.3.39.2. Flujo de eventos.

Se indicará el documento, el role y el soporte. En función de estos datos se refrescará la línea

correspondiente a este documento / tercero.

3.3.3.39.3. Excepciones.

3.3.3.40. Caso de Uso – Transición En Bloque

El actor ejecuta una transición para un grupo de documentos al mismo tiempo.

3.3.3.40.1. Descripción.

ID Requisito RE-39

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones

Se ha seleccionado un expediente para aportar documentación.

El soporte para los documentos que se puedan seleccionar sólo puede ser papel.

Se han seleccionado una serie de documentos / tercero.

Postcondiciones Seguimos el proceso de aportación en bloque mediante el caso de uso “Datos Aportación En

Bloque”

Comentarios

3.3.3.40.2. Flujo de eventos.

En este punto, sólo los checks con soporte papel estarán habilitados.

Page 61: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 61 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

El actor selecciona una lista de terceros / documento / soporte mediante checks en cada uno de los

documentos mostrados.

Se ejecutará la transición por defecto para la “transición en bloque”, que nos llevará al caso de uso

“Datos Transición En Bloque”

3.3.3.40.3. Excepciones.

3.3.3.41. Caso de Uso – Datos Transición En Bloque

El actor facilitará los datos necesarios para aportar en bloque.

3.3.3.41.1. Descripción.

ID Requisito RE-39

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones

Se ha seleccionado un expediente para aportar documentación.

Se han seleccionado una serie de documentos / tercero.

El soporte para los documentos seleccionados sólo puede ser papel.

Postcondiciones Ejecutamos la transición por defecto para transiciones en bloque.

Comentarios Se lista la información de los documentos seleccionados.

3.3.3.41.2. Flujo de eventos.

Llegamos a este punto desde “Transición En Bloque”.

Se mostrará la lista de los documentos sobre los que se realizará la transición.

Se pedirán los siguientes datos:

Fecha de aportación.

Observaciones.

3.3.3.41.3. Excepciones.

3.3.3.42. Caso de Uso – Listar Aportados

Muestra al actor los documentos dentro del workflow del expediente seleccionado.

3.3.3.42.1. Descripción.

Page 62: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 62 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

ID Requisito RE-39

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones

El actor está autenticado en la aplicación.

El actor identifica un expediente.

El actor selecciona la pantalla de gestión de documentación aportada.

Existe documentación aportada.

Postcondiciones La aplicación muestra la lista de documentos aportados del expediente.

Comentarios

Se mostraran todos los documentos aportados, aunque sean de otra fase.

En caso de que los documentos estén filtrados, deberá estar claramente indicado.

En caso de que los documentos estén ordenados, deberá estar claramente indicado.

3.3.3.42.2. Flujo de eventos.

El actor identifica un expediente y selecciona la pantalla de gestión de documentación aportada.

La aplicación muestra la lista de documentos que se encuentran en el workflow de documentación

aportada del expediente seleccionado.

Se mostrarán la siguiente información:

Datos mostrados del documento:

Nombre del documento: CIF, CV, etc...

Carácter: Exigible, Voluntario y opciones.

Fase: Fase en la que se debe aportar el documento

Role: Role que debe tener el tercero que se relacionará con este documento.

Casos particulares sobre atributos:

Los estados tienen atributos para marcarlos.

Un caso de ejemplo, serán los estados marcados como subsanables.

Datos mostrados del tercero:

Identificación Fiscal.

Soporte. Soporte con que se realizó la aportación.

Datos mostrado de las transiciones:

Se usará el caso de uso “Mostrar Transiciones” para mostrar las transiciones que se pueden

ejecutar, en función del role del tercero, del soporte por defecto y el documento.

3.3.3.42.3. Excepciones.

Page 63: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 63 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.43. Caso de Uso – Ordenar

El actor selecciona el orden en que se muestran los documentos de la lista del caso anterior “Listar

Aportados”

3.3.3.43.1. Descripción.

ID Requisito RE-39

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones

El actor está autenticado en la aplicación.

El actor identifica un expediente.

El actor selecciona la pantalla de gestión de documentación aportada.

El actor selecciona un orden.

Existe documentación aportada.

Postcondiciones Pasa directamente al caso de uso “Listar Aportados”, pero la lista ahora se mostrará ordenada.

Comentarios

3.3.3.43.2. Flujo de eventos.

El actor identifica un expediente y selecciona la pantalla de gestión de documentación aportada.

El actor selecciona un orden.

Los ordenes posibles son: Nombre de documento, Estado, Fase, Role, Soporte, Identificador fiscal,

3.3.3.43.3. Excepciones.

3.3.3.44. Caso de Uso – Filtro

El actor indica el filtro por que se desea filtrar la lista del caso de uso “Listar Aportado”.

3.3.3.44.1. Descripción.

ID Requisito RE-39

Actores Tramitador

Prioridad

Nivel de Riesgo

Page 64: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 64 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Precondiciones

El actor está autenticado en la aplicación.

El actor identifica un expediente.

El actor selecciona la pantalla de gestión de documentación aportada.

El actor selecciona un orden.

Existe documentación aportada.

Postcondiciones Pasa directamente al caso de uso “Listar Aportados”, pero la lista ahora se mostrará filtrada.

Comentarios

3.3.3.44.2. Flujo de eventos.

El actor identifica un expediente y selecciona la pantalla de gestión de documentación aportada.

El actor indica el filtro.

El filtro se realizará sobre los campos Nombre de documento, Estado, Fase, Role, Soporte,

Identificador fiscal,

3.3.3.44.3. Excepciones.

3.3.3.45. Caso de Uso – Ejecutar Transición

El actor selecciona una de las transiciones mostradas por el caso de uso “Mostrar Transiciones”

3.3.3.45.1. Descripción.

ID Requisito RE-39

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones

El actor está autenticado en la aplicación.

El actor identifica un expediente.

El actor selecciona la pantalla de gestión de documentación aportada.

Existe documentación aportada y por cada documento se han mostrado las transiciones

disponibles.

Postcondiciones Ejecuta la transición, mediante los casos de uso “Transición Simple” o “Transición Con

Interacción”.

Comentarios

3.3.3.45.2. Flujo de eventos.

Existirá una transición que nos lleve a un pseudos estado “No Aportado”.

En realidad, esta transición borrará el documento!

Page 65: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 65 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.45.3. Excepciones.

3.3.3.46. Caso de Uso –Transición Simple

Se ejecuta la transición en un solo paso.

3.3.3.46.1. Descripción.

ID Requisito RE-39

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones

El actor está autenticado en la aplicación.

El actor identifica un expediente.

El actor selecciona la pantalla de gestión de documentación aportada.

Existe documentación aportada y por cada documento se han mostrado las transiciones

disponibles.

Postcondiciones Ejecuta la transición.

Comentarios

3.3.3.46.2. Flujo de eventos.

El actor identifica un expediente y selecciona la pantalla de gestión de documentación aportada.

Se selecciona una transición de la lista de transiciones de uno de los documentos aportados.

Se ejecuta la transición.

3.3.3.46.3. Excepciones.

3.3.3.47. Caso de Uso –Transición Con Interacción

Se ejecuta la transición con pantallas intermedias que requieren interaccionar con el actor.

3.3.3.47.1. Descripción.

ID Requisito RE-39

Actores Tramitador

Prioridad

Nivel de Riesgo

Page 66: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 66 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Precondiciones

El actor está autenticado en la aplicación.

El actor identifica un expediente.

El actor selecciona la pantalla de gestión de documentación aportada.

Existe documentación aportada y por cada documento se han mostrado las transiciones

disponibles.

Postcondiciones

Comentarios

3.3.3.47.2. Flujo de eventos.

El actor identifica un expediente y selecciona la pantalla de gestión de documentación aportada.

Se selecciona una transición de la lista de transiciones de uno de los documentos aportados.

Nos lleva a las pantallas específica de la transición que interactúan con el usuario.

La pantalla de interacción con el usuario nos pedirá:

Documento a adjuntar.

Fecha de aportación.

Observaciones.

La pantalla de interacción nos mostrará:

Los datos del tercero.

Los datos del documento.

La pantalla definida es genérica para las transiciones con interacción con el usuario. Es posible que

para cierto tipo de transiciones existan pantallas específicas.

3.3.3.47.3. Excepciones.

3.3.3.48. Caso de Uso – Crear Tipo De Documento

El actor añade un nuevo tipo de documento a la documentación por aportar.

3.3.3.48.1. Descripción.

ID Requisito RE-39

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones

El actor está autenticado en la aplicación.

El actor identifica un expediente.

El actor selecciona la pantalla de gestión de documentación aportada.

Page 67: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 67 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Postcondiciones

Comentarios

3.3.3.48.2. Flujo de eventos.

El actor identifica un expediente y selecciona la pantalla de gestión de documentación aportada.

Seleccionamos “añadir nuevo tipo de documento” y nos pedirá:

Fase:

Role:

Carácter: Exigible, Voluntario y opciones.

Nombre: Nombre de la documentación.

Soporte:

Al insertarlo, nos lo añadirá dentro del grupo de documentación por aportar.

3.3.3.48.3. Excepciones.

Page 68: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 68 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.49. Caso de Uso – Alarmas

cd Alarmas

Empleado Público

(from Actores)

Tramitador

(from Actores)

Borrar Alarma

Ver Alarmas

Alta Alarma

Aplicación

(from Actores)

Alta Alerta

3.3.3.50. Caso de Uso – Alta Alarma

La aplicación da de alta alarmas sobre expedientes en función de unas condiciones definidas.

3.3.3.50.1. Descripción

ID Requisito RE-25

Actores Aplicación

Prioridad

Nivel de Riesgo Alta

Precondiciones La aplicación detecta una posibilidad de alarma sobre un expediente.

Page 69: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 69 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Postcondiciones La aplicación da de alta la alarma vinculándola al expediente.

Comentarios

3.3.3.50.2. Flujo de eventos

La aplicación evalúa las condiciones de disparo de las alarmas de los expedientes y al detectar la

posibilidad de alarma sobre uno de ellos, la da de alta y la vincula al expediente.

3.3.3.50.3. Excepciones

3.3.3.51. Caso de Uso – Alta Alerta

Permite al actor dar de alta alertas propias asociadas a los expedientes.

3.3.3.51.1. Descripción

ID Requisito RE-26

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla de gestión de alarmas asociadas a un expediente.

El actor selecciona la opción de añadir una alerta y la define.

Postcondiciones La aplicación da de alta la alerta.

Comentarios

3.3.3.51.2. Flujo de eventos

El actor está en la pantalla de gestión de alarmas asociadas a un expediente y elige la opción de añadir

una alerta, la aplicación muestra la pantalla de definición de alertas. El actor estable los datos de la

alerta y la aplicación la da de alta.

Datos de la alerta:

Número del expediente sobre el que se estable de la alerta

Fecha en la que se ha de activar la alerta

Descripción de la alerta

Page 70: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 70 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Nivel de criticidad de la alerta (alta, media, baja)

3.3.3.52. Caso de Uso – Ver Alarmas

Permite al actor ver las alarmas asociados a los expedientes.

3.3.3.52.1. Descripción

ID Requisito RE-27

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor identifica un expediente.

El actor selecciona la pantalla de gestión de alarmas del expediente.

Postcondiciones La aplicación muestra la lista de alarmas del expediente.

Comentarios

3.3.3.52.2. Flujo de eventos

El actor identifica un expediente y selecciona la pantalla de gestión de alarmas y la aplicación muestra

la lista de alarmas vinculadas al expediente.

Datos de las alarmas:

Nivel de criticidad de la alarma (alta, media, baja)

Descripción de la alarma

3.3.3.52.3. Excepciones

3.3.3.53. Caso de Uso – Borrar Alarma

Permite al actor eliminar las alarmas asociados a los expedientes.

Page 71: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 71 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.53.1. Descripción

ID Requisito RE-28

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla de gestión de alarmas asociadas a un expediente.

El actor selecciona una alarma y la opción de eliminarla.

Postcondiciones La aplicación elimina la alarma del expediente.

Comentarios

3.3.3.53.2. Flujo de eventos

El actor está en la pantalla de gestión de alarmas asociadas a un expediente, elige la opción de eliminar

una alarma y la aplicación la borra desvinculándola del expediente.

Antes de ejecutar la orden de borrado, la aplicación presenta al usuario una pantalla de confirmación

de la orden.

3.3.3.53.3. Excepciones

Page 72: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 72 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.54. Caso de Uso – Informes

cd Informes

Informes Básicos

Tramitador

(from Actores)

Empleado Público

(from Actores)

Informes

Av anzados

3.3.3.55. Caso de Uso – Informes Básicos

Permite al actor generar informes básicos sobre los expedientes.

3.3.3.55.1. Descripción

ID Requisito RE-29

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Precondiciones

El actor está autenticado en la aplicación.

El actor está en la pantalla de gestión de informes.

El actor selecciona el tipo de informe que quiere generar.

El actor elige los expedientes sobre los que se quieren generar el informe.

Postcondiciones La aplicación genera el informe con los expedientes seleccionados.

Comentarios

Page 73: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 73 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.55.2. Flujo de eventos

NOMBRE DEL INFORME RESULTADO

Expedientes por territorio Expedientes agrupados por las distintas divisiones territoriales

Expedientes por tercero Expedientes de un tercero determinado

Listados agrupados por

“objetos de negocio”

*Definición muy general

por ejemplo: los expedientes agrupados por monte, por centro de valoración de

discapacidades, por tipo de proyecto, etc.

Importe concedido por

territorio

¿ familia subvenciones?

Cantidad (solicitada, concedida, revocada, etc.) por división territorial

Informe a un órgano de

decisión

¿familia subvenciones?

Resumen de los expedientes: solicitante, proyecto, cantidad solicitada, territorio y

cualquier otra información susceptible de ser útil para tomar una decisión

Expedientes (o documentos o

trámites) creados por autor

Informe para la jefatura de servicio que servirá de control del rendimiento de su

personal

Tiempo de tramitación Información del tiempo que se tarda en ejecutar cierto trámite (la resolución por

ejemplo), tanto de forma agrupada (para que de una idea del tiempo medio de

tramitación) como de forma individual

Documentación pendiente Lista por expediente de los documentos obligatorios y necesarios pendientes de

entrega.

3.3.3.56. Caso de Uso – Colaboración

Permite que distintos actos de un procedimiento sean tramitados por distintos grupos de tramitación,

de tal manera que todos colaboran en el expediente.

3.3.3.56.1. Descripción

ID Requisito RE-32

Actores Tramitador

Prioridad

Nivel de Riesgo Alta

Page 74: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 74 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Precondiciones El actor está autenticado en la aplicación.

El actor está en la pantalla de bandeja de entrada/salida de colaboraciones.

Postcondiciones

Comentarios

3.3.3.56.2. Flujo de eventos

Permite que distintos actos de un procedimiento sean tramitados por distintos grupos de tramitación,

de tal manera que todos colaboran en el expediente.

El usuario selecciona la pantalla que contiene la bandeja de entrada/salida de colaboraciones que

contiene la lista de expedientes que están siendo tramitados bajo colaboración por el resto de grupos de

tramitación. Esta bandeja tiene un indicador del número de expedientes que contiene para no tener que

acceder a ella cuando esté vacía.

Cada vez que un expediente pasa de un grupo de tramitación a otro, ya sea de forma automática o

mediante un acto de delegación, la aplicación genera una entrada en la bandeja correspondiente.

Cada vez que una colaboración es finalizada, se muestra un icono de “ok” delante del número del

expediente, en cambio si es anulada, se muestra un icono de “anulación”.

Las colaboraciones finalizadas o anuladas se pueden eliminar, (para mayor comodidad, habrá un

opción de eliminar todas las colaboraciones para no tener que ir una a una)

Entrada:

Número de Expediente Grupo Colaboración

Origen

Fecha Inicio

Delegación

Fecha Fin Delegación

Salida:

Número de Expediente Grupo Colaboración

Destino

Fecha Inicio

Delegación

Fecha Fin Delegación

El usuario selecciona el expediente correspondiente y se le nuestra su detalle para la tramitación.

Page 75: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 75 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.56.3. Flujo de eventos (Ejemplo)

A continuación se muestra un ejemplo de configuración de colaboración entre dos grupos de

tramitación diferentes sobre un mismo expediente, en todo caso cada flujo dependerá de la

configuración que se haya realizado en el catálogo para un procedimiento determinado.

Se parte de la base de que existen dos grupos uno de ellos es el grupo que tramita el procedimiento

administrativo y solicita al otro grupo (colaborador) un informe (en este caso una EPIA) , el grupo que

colabora con el informe recibe un aviso de que tiene que realizar el informe, lo realiza y finalmente el

grupo que lo solicitó puede revisarlo.

El funcionamiento que se configura a continuación hace referencia al siguiente modo de ejecución, en

cualquier caso si se desease otro funcionamiento el sistema es suficientemente flexible para ser

configurado con otros tipos de actos.

1.- Existen dos grupos de colaboración: PACGroup grupo que realiza la tramitación de todo el

procedimiento y PACColaborador (podría ser por ejemplo “Cultura”) que es el grupo que va a

participar puntualmente en el mismo mediante la realización de un informe.

2- Ambos usuarios tienen su bandeja de “Colaboración” sin entradas.

3.- El usuario PACGroup instancia el acto “Petición de Informe EPIA a Cultura” , esto hace que en la

zona de “Colaboración “ del escritorio aparezca para el grupo PACGroup el expediente en la

“bandeja de Salida” además para el usuario PACColaborador aparecerá en la zona de “Colaboración “

del escritorio el expediente en la “bandeja de Entrada”

4.- El usuario PACGroup conoce que no se ha realizado todavía el informe puesto que en su bandeja

de salida no aparece como finalizada mediante los iconos correspondientes.

5.- El usuario PACColaborador sabe que tiene que realizar algún documento puesto que tiene 1

mensaje en su buzón de entrada dentro de “Colaboración”, pinchando sobre el número de expediente y

en la pantalla de “Tramitar” sabe lo que tiene que hacer , en este caso “Informe EPIA” .

6.- El “Informe EPIA” ha sido configurado en el catálogo para que tras su finalización se dé por

finalizada la colaboración entre ambos grupos de colaboración , la pestaña “Colaboración” vuelve a

estar a 0 para ambos grupos.

7.- El usuario PACGroup conoce que el informe ha sido realizado puesto que en su bandeja de Salida

ya figura la tarea como “Colaboración finalizada” y accediendo al expediente puede ver el informe

que ha realizado el otro grupo colaborador.

8.- Para ambos grupos pueden mantener en las bandejas de entrada salida las colaboraciones previas o

bien eliminarlas si no fuesen de su interés.

Page 76: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 76 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.56.4. Roles de Aplicación

Los roles de aplicación son los perfiles que permiten operar con la aplicación, existen dos tipos de

roles:

1. Rol de Consulta, perfil que sólo permite la lectura de la información y la inhabilitación o

eliminación de las acciones (links de acciones, botones de acciones, etc.)

2. Rol de Tramitación, perfil que permite el uso total de la aplicación, tanto a nivel de datos como

de acciones.

Pantalla Rol de Consulta Rol de Tramitación

Buscador Básico Si Si

Buscador Agrupado Si Si

Crear Expediente No Si

Datos Expediente

campos En modo “solo lectura” En modo edición

acciones No Si

Terceros

acciones No Si

Doc. Aportada

campos En modo “solo lectura” En modo edición

acciones No Si

Tramitar

actos Visualización de los

documentos

Si

acciones No Si

Informes Si Si

Modo “solo lectura”, los campos se muestran en etiquetas o en su defecto en los controles

correspondientes pero en el estado de no-edición.

Nota:

Para cada procedimiento, hay un grupo de más alto nivel (“super grupo”) al que tienen que pertenecer

todos los usuarios asociados al procedimiento, este grupo tiene rol de consulta.

Para dar permisos de tramitación hay que dar de alta otro grupo a nivel de procedimiento con el sufijo

_RW.

ejemplo:

Page 77: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 77 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

NombreGrupoProcedimiento: Rol de Consulta

NombreGrupoProcedimiento_RW: Rol de Tramitación

3.3.3.56.5. Grupos de Tramitación

En el caso concreto de la tramitación, las tareas asignadas a cada grupo de tramitación en el catálogo

tendrán asignado un rol propio (‘Escritura’ | ‘Lectura’) que permitirá o no actuar sobre dichas tareas.

Nota:

Habrá, para cada procedimiento, un grupo de más alto nivel (“super grupo”) al que tienen que

pertenecer todos los usuarios asociados al procedimiento.

Ejemplo de definición en el fichero de autorizaciones:

<!DOCTYPE users

PUBLIC "-//Framework PA - Team//DTD Authorized Users Configuration 1.3F//ES"

"authorized-users.dtd">

<users>

<user username="admin" password="admin" type="EMPLOYEE" >

<principals>

<principal name="USERNAME" value="admin"/>

<principal name="NAME" value="Administrador"/>

<principal name="SURNAME1" value=""/>

<principal name="SURNAME2" value=""/>

<principal name="NIF/NIE" value="12345678Z" identifier="true"/>

<principal name="ID THIRD PARTY" value="2192"/>

<principal name="AGENT USER TYPE" value="AGENT USER TYPE"/>

<principal name="ORGANIZATIONAL UNIT ID" value="1001"/>

<principal name="ORGANIZATIONAL UNIT NAME" value="Consejería de Vivienda"/>

</principals>

<roles>

<role name="Tramitador">

<domainRole name="MiProcedimiento" value="MiProcedimiento" procedure="yes"/>

<domainRole name="MiProcedimiento" value="MiProcedimiento" procedure="no"/>

<domainRole name="Grupo 1" value="Grupo1" procedure="no"/>

<domainRole name="Grupo 2" value="Grupo2" procedure="no"/>

<domainRole name="Grupo N" value="GrupoN" procedure="no"/>

</role>

</roles>

</user>

Page 78: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 78 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

<users>

3.3.3.57. Caso de Uso – Control de Plazos

Page 79: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 79 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

El plazo de un procedimiento viene dado por la “fecha de inicio” hasta la “fecha de notificación de la

resolución”. Generalmente el plazo máximo de un procedimiento es de 3 meses, dejando la posibilidad

de permitir la configuración este plazo en el catálogo para cada uno de los procedimientos.

El control de plazos que se va a manejar en la aplicación es “semi-automático”, es decir, los plazos no

se van a manejar automáticamente puesto que es necesario que el tramitador sea consciente de los

mismos.

3.3.3.57.1. Fecha de Inicio

La forma en que se añade/actualiza la fecha de inicio se parametriza en el catálogo, es decir, por cada

procedimiento se indica la manera en la cual se puede establecer la fecha de inicio, existen varios

casos:

a) Cuando se crea el expediente, en ese instante, se establece la fecha de inicio.

b) Cuando viene del registro de entrada (leer registro).

c) Parametrizar en el catálogo una fecha fija, por ejemplo, el procedimiento X comienza el 30 de

junio.

d) Cuando se notifica un documento del mismo expediente, por ejemplo, se crea un expediente

(no se pone fecha de inicio), se hacen varios trámites y tras la notificación al ciudadano, en ese

instante se actualiza la fecha de inicio.

e) Cuando el expediente es una convocatoria, se establece la fecha de inicio al día siguiente de la

finalización de la presentación de todas las solicitudes.

Siempre que se establece la fecha de inicio de un expediente, se fijará la fecha teórica de fin y se dará

de alta una alarma de fin de plazo del expediente.

En el momento que se realiza el registro de salida de notificación de la resolución (fecha fin) se

eliminará la alarma anterior.

En cualquier caso en el que se modifique la fecha de inicio, se tiene que recalcular los plazos que

afectan a la duración del expediente:

1. Actualizar la fecha fin.

2. Desplazar la alarma que indica el fin de plazo del expediente.

Nota:

Page 80: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 80 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Las alarmas de los expediente estarán tipificadas para diferenciar aquellas de control de plazos del

resto, y siempre que se establece una alarma de control de plazos, en realidad, se darán de alta dos

alarmas

1 - alarma de alerta en la fecha correspondiente

2 - alarma de aviso en la (fecha correspondiente - % duración del plazo)

3.3.3.57.2. Fecha de Finalización

Para los actos de notificación, la fecha de fin de plazo está asociada a las acciones

“cumplimentar/cumplimentar fallida”, aunque después se pueda volver a acusar, la fecha es a partir de

la fecha del acuse de recibo.

Para los actos que NO hay que notificar individualmente, sino colectivamente, requieren una

publicación en el BOPA, con lo que la fecha de fin de plazo viene delimitada por la acción “finalizar”

del acto “publicación en BOPA”, el cual es de generación de documentación.

En cualquier caso, siempre se eliminará la alarma de fin de plazo.

3.3.3.57.3. Paralizaciones/Reanudaciones

Consiste en paralizar los plazos de un expediente y la posibilidad de reanudarlos de tal manera que el

cómputo del tiempo que el expediente ha estado paralizado no supere un valor dado.

Existirá un acto de paralización, que será un acto de notificación que tras la acción de cumplimentar se

paralizará el expediente con la fecha de acuse de recibo.

Paralizar el expediente implica:

Establecer la fecha de paralización en el expediente

Desactivar las alarmas del expediente

Crear una alarma que avise que llegó el tiempo de desparalizar el expediente cuando caduque

A los expedientes paralizados se les identificará con un icono en el buscador de expedientes

permitiendo además búsquedas de los que están paralizados.

A un expediente paralizado, no se le permitirá el cierre de la fase en la que está.

Page 81: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 81 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Existirá un acto de reanudación, que será un acto de notificación que tras la acción de cumplimentar se

reanudará el expediente con la fecha de acuse de recibo.

Reanudar el expediente implica:

Poner la fecha de paralización del expediente a nulo

Eliminar la alarma de plazo máximo de paralización

Recalcular las alarmas del expediente teniendo en cuenta el tiempo de paralización

Recalcular el tiempo acumulado de paralización

Si la cumplimentación es fallida, se utilizará el mecanismo de publicación en BOPA y se tendrá en

cuenta la fecha de publicación.

Se tendrá un control de fechas de paralización y reanudación para calcular el número de días que hay

que aumentar la fecha de fin del expediente, actualizando además las correspondientes alarmas de

plazos.

Nota:

Se necesitará la utilización de un CALENDARIO LABORAL para manejar tanto los días hábiles

como los días naturales, así como plazos de meses.

3.3.3.57.4. Trámite de Urgencia

Consiste en un acto el cual reduce a la mitad todos los plazos a nivel de expediente (no de

procedimiento) con lo que existirá un acto de tipo “Urgencia” que tras la notificación al ciudadano se

reducirá la fecha fin y las alarmas de plazos a la mitad.

Otra posibilidad es crear el expediente ya con carácter “urgente” que tendrá los plazos reducidos a la

mitad de tiempo que lo que indica el procedimiento al que pertenece.

3.3.3.57.5. Ampliaciones de Plazo

La ampliación de plazo no afecta a la vida de un expediente, solamente afecta a determinados actos,

por ejemplo, en un acto en concreto de subsanación en lugar de 10 días para enviar la documentación,

se le puede permitir 15. Pero solo se hace a nivel de ese acto y nunca al expediente.

Page 82: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 82 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.58. Caso de Uso – Notas sobre Expedientes

Permite al usuario introducir notas de carácter recordatorio, anotación, etc. sobre los expedientes

cd Notas

Modificar Nota

Nuev a Nota

Eliminar Nota

Listar Notas

Tramitador

3.3.3.58.1. Flujo de eventos

El usuario selecciona la pantalla de gestión de notas donde puede realizar las siguientes acciones:

Dar de alta una nota nueva introduciendo el texto de la misma.

Modificar una nota dada de alta previamente.

Eliminar una nota dada de alta previamente.

Listar las notas dadas de alta.

Page 83: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 83 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Una vez dada de alta una nota, se reflejará en el buscador de expedientes con un icono indicando su

existencia sobre el expediente.

3.3.3.59. Caso de Uso – Formas finalización de un expediente

Este caso de uso describe las formas de finalización de un expediente, en él se reflejan los tipos de

finalización, así como los tipos de actos necesarios para la correcta configuración en el catálogo

3.3.3.59.1. Flujo de Finalización

Page 84: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 84 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

cd Tipo Terminacion

Finalizar Expediente

Expediente

¿ fase "Archivo" ?

Inicio

Fin

Actualizar Fecha Fin

Actualizar Tipo

Terminación

Mov er a Fase de

Archiv o

Establecer Estado

Archiv ado

[si]

[no]

Page 85: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 85 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Todas las formas de finalización, excepto “solicitud fuera de plazo”1, tienen que tener una resolución

y una notificación2.

A continuación se describen las acciones que se ejecutarán cuando un expediente se dé por finalizado,

exceptuando “Solicitud fuera de plazo” y una resolución normal de un expediente.

3.3.3.59.2. Flujo de eventos

Actualizar en el expediente la fecha de finalización.

Actualizar en el expediente el tipo de finalización, depende del acto instanciado.

Actualizar en la pantalla de datos básicos la fecha y forma de finalización.

Mover el expediente a la última fase de del procedimiento

Marcar el expediente como Archivado.

1 Finalización por convenio: No hay resolución hay acuerdo o convenio (documento) + notificación

Inadmisión por causas formales (fuera de plazo p.ej): En procedimientos concurrentes la Resolución determina los

inadmitidos. En realidad no es una Resolución, es una “declaración” pero a los efectos prácticos equivale.

Caducidad (silencio) de la Administración: ¿cómo se Finaliza y pasa a Archivo?--> Los procedimientos sancionadores

mediante una Resolución de archivo o sobreseimiento(es prácticamente lo mismo) por caducidad . Para el resto de

expedientes, la situación puede ser la anterior o un poco mas compleja, pues aparece una nueva solicitud del ciudadano, si

el silencio es estimatorio: solicitud de certificación de acto presunto (equivale a resolución)

2 Entendiendo que Notificación comprende los tres tipos posibles: Notificación personal, Publicación, y Publicación-

Notificación

Page 86: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 86 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

cd Casos de Uso

Sin Generacion de Documentacion

Con Generacion de

Dcoumentacion

Tramitador

Finalizacion por

Inadmision por

Plazo

TERMINAR

TERMINAR sin

Archiv oTERMINAR

Estableciendo

Fase

Finalizacion por

Resolucion

Finalizar

Expediente

Finalizar con

Notificacion Valida Finalizar con

Notificacion Fallida

Publicacion en

BOPA

Finalizacion por

Silencio

Administrativ o

Establecer Fase

Final

Finalizacion por

Desestimineto

Expreso

Finalizacion por

Renuncia

Finalizacion por

Caducidad

Finalidad por

Caducidad por

Inactiv idad de la

Administracion

Finalizacion por

Pacto

Finalizacion por

Causa

Sobrev enida

Finalizacion por

Desestimiento por

No Subsanacion

«include»

fase = [configurable]fase = Archivofase = Archivo

«include»

Page 87: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 87 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.59.3. Tipos de actos de formas de finalización

Basado en los siguientes puntos se hacen necesarios los siguientes tipos de actos:

o “Resolución con terminación” que es de tipo generación de documentación + la fecha de

finalización al expediente + el tipo de finalización al expediente , aunque realmente no se

visualiza en el expediente hasta que se notifica al ciudadano.l

o “Notificación de Resolución” este es un acto de notificación en el que una vez

cumplimentada la fecha de acuse es realmente cuando marca el expediene como finalizado.

o “Resolución y finalización” que es de tipo generación de documentación pero además sí

que finaliza el expediente.

o “Paso a Archivo” que mueve el expediente a la última fase del procedimiento, tanto en el

flujo BPEL como en el expediente, aunque realmente el expediente ya esté finalizado este

acto es el mueve el expediente de fase.

o “Vuelta desde Archivo” esto es un nuevo acto que se puede instanciar desde la fase de

Archivo y lo que hace es que elimina la forma de terminación , quita el flag de Archivado y

aparece una pantalla donde le permite indicar al tramitador a qué fase quiere volver.

A continuación se detallan los posibles flujos que corresponderían a una terminación de expediente:

3.3.3.59.3.1. Finalización con notificación aceptada

Finalización de un expediente cuando el ciudadano ha recibido la notificación y se ha dado por

notificado: Desistimiento por no subsanación, Desistimiento expreso, Renuncia, Caducidad,

Caducidad por inactividad de la Administración, Terminación por pacto o convenio y Archivo por

causa sobrevenida.

I. El tramitador crea el acto “Resolución de .....” Ante la última acción de finalizar

a. Actualizar en el expediente la fecha de finalización.

b. Actualizar en el expediente el tipo de finalización, depende del acto instanciado.

c. Aparece el acto dependiente que es “Notificación de la resolución” que se detalla a

continuación.

II. El tramitador instancia el acto “Notificación de ....” y pasa por los estados y acciones

siguientes: aprobar, Registrar Salida acusar y recibir.

a. Ante la última acción que será “Validar” además de finalizar dicho acto se pone

también una alarma de ‘Pasar a Archivo’ ”

III. El tramitador instancia el acto “Paso a Archivo” el cual:

Page 88: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 88 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

a. Una vez instanciado deshabilita el botón de “Fase siguiente”.

b. Mover el expediente a la fase “Archivo”, esto tiene una implicación y es que todos

los procedimientos tendrán obligatoriamente esta fase.

c. Marcar el expediente como Archivado.

d. No se destruye el proceso BPEL.

3.3.3.59.3.2. Finalización con notificación fallida

Finalización de un expediente cuando el ciudadano no se ha dado por notificado3, por ejemplo que no

vive en la dirección que tiene en el expediente:

I. El tramitador crea el acto “Resolución de .....” Ante la última acción de finalizar

a. Actualizar en el expediente la fecha de finalización.

b. Actualizar en el expediente el tipo de finalización, depende del acto instanciado.

c. Aparece el acto dependiente que es “Notificación de la resolución” que se detalla a

continuación.

II. El tramitador instancia el acto “Notificación de ....” y pasa por los estados y acciones

siguientes: aprobar, Registrar Salida acusar y recibir.

Ante la última acción que será “Comunicación Fallida4” el acto de notificación se

finalizaría y además se tendría que instanciar el acto “Publicación en el BOPA”5, este acto

queda sería deseable que el propio escritorio lo instanciase automáticamente en otro caso el

personal que tramita sería el encargado de instanciarlo manualmente.

III. El tramitador instancia el acto de “Publicación en BOPA” además de finalizar dicho acto se

pone también una alarma de ‘Pasar a Archivo’ y se visualiza el acto siguiente “Paso a

Archivo”

IV. El tramitador instancia el acto “Paso a Archivo” el cual:

a. Una vez instanciado deshabilita el botón de “Fase siguiente”.

b. Mover el expediente a la fase “Archivo”, esto tiene una implicación y es que todos los

procedimientos tendrán obligatoriamente esta fase.

c. Marcar el expediente como Archivado.

d. No se destruye el proceso BPEL.

3 Aclaración: “no se ha dado por notificado” es equívoco. Debe poner “no se ha podido practicar la notificación”. Si la

notificación es rechazada, el efecto equivale a cuando se podido realizar. 4 Cambiar Fallida por “no practicada”

5 Y publicación en Tablón de edictos del Ayuntamiento

Page 89: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 89 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

3.3.3.59.3.3. Configuración en catálogo de la Finalización con notificación

La configuración en el catálogo se describe en el documento de ayuda proporcionado con el core

de tramitación, aquí se describen a priori los posibles actos:

o Crear el acto de resolución: un acto de este tipo dentro de un procedimiento se asociaría al

“acto_fase” un tipo de acto “Resolución” y se le indicaría el nombre del acto, ej:

“Resolución por desistimiento” por Renuncia, por caducidad etc...Además se le indicaría al

“acto_fase” el “tipo_terminación” desistimiento, renuncia etc...

o Crear el acto de “Notificación de la resolución” de tipo “Notificación de Resolución” e

indicaría que es dependiente del acto anterior (solo se vería una vez instanciado la

resolución).

o Crear el acto de “Publicación en BOPA” e indicaría que es dependiente del acto anterior

(solo se vería una vez instanciado la resolución.

o Crear el acto de “Paso a Archivo” e indicaría que es dependiente del acto anterior (solo se

vería una vez finalizada la notificación anterior).

3.3.3.59.4. Como deshacer una resolución6

3.3.3.59.4.1. Deshacer una resolución sin notificar

Por ejemplo el tramitador hacer una resolución y la finaliza, crea el acto de notificación pero aún no lo

ha resuelto es decir que no se ha notificado, en este caso el tramitador tiene que eliminar el acto de

notificación aún sin registrar de salida, y como no puede eliminar la resolución antigua puesto que está

finalizada tiene que crear otro documento de resolución, es decir el documento válido de la resolución

sería el más nuevo.

3.3.3.59.4.2. Deshacer una resolución ya notificada

Por ejemplo el tramitador hace una resolución, la finaliza y la notifica al ciudadano. En este caso tiene

que volver a notificar al ciudadano de la nueva resolución pero no se anula la resolución previa.

3.3.3.59.4.2.1. Otros tipos de forma de terminación.

6 Este apartado nos lleva (de nuevo) a la rectificación de errores de actos firmes (es decir, ya notificados). Si se detecta un

error (material o aritmético), dice la norma , que se evidencie por si sólo, sin afectar a la esencia jurídica del acto, se corrige

mediante un Acuerdo de Rectificación (a instancias de parte o de oficio) que es notificado al interesado (como una

resolución). Si el error afecta a la esencia jurídica o causa indefensión al administrado, se entra de lleno en el

Procedimiento Anulatorio.

Page 90: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 90 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Finalización por “Inadmisión por plazo”, este es un acto que no genera ningún documento y su

finalidad es que al ser instanciado él mismo se finaliza, y desencadena todas las acciones que se

han mostrado en “TERMINAR”, este acto es útil para que quede en el expediente el porqué se ha

ido a una fase cuando le faltan actos obligatorios en fases previas.

Por lo tanto se hace necesario crear un tipo de acto “Terminación Sin documentación” . Para

configurar un acto de este tipo dentro de un procedimiento se asociaría a “acto_fase” un tipo de

acto “Terminación Sin documentación” y se le indicaría el nombre del acto, ej: “Inadmision por

plazo” y además se le indicaría al “acto_fase” el “tipo_terminación”

Finalización por “Silencio administrativo” esto es un acto sin documentación que se visualizará

cuando haya pasado un plazo definido, cuando se instancia este acto no genera ningún documento

y su finalidad es que al ser instanciado él mismo se finaliza, y desencadena todas las acciones que

se han mostrado en “TERMINAR”.

Por lo tanto se hace necesario crear un tipo de acto “Terminación Sin documentación” . Para

configurar un acto de este tipo dentro de un procedimiento se asociaría a “acto_fase” un tipo de

acto “Terminación Sin documentación” y se le indicaría el nombre del acto, ej: “Inadmision por

plazo” y además se le indicaría al “acto_fase” el “tipo_terminación” y también se le indicaría al

“acto_fase” la fase a la que irá al terminar.

3.3.3.59.4.3. Anexo - Formas Finalización

Tipo de

Finalización

Normativa Evento Pasos de la Fase de

Finalización

Resolución Artículo 89 Ley 30/92. Contenido.

1. La resolución que ponga fin al procedimiento decidirá todas las cuestiones planteadas por los interesados y aquellas otras derivadas del mismo. Cuando se trate de cuestiones conexas que no hubieran sido planteadas por los interesados, el órgano competente podrá pronunciarse sobre las mismas, poniéndolo antes de manifiesto en aquéllos por un plazo no superior a quince días, para que formulen las alegaciones que estimen pertinentes y aporten, en su caso, los medios de prueba. 2. En los procedimientos tramitados a solicitud del interesado, la resolución será congruente con las peticiones formuladas por éste, sin que en ningún caso pueda

Emisión de la

resolución

Resolución.

Notificación de la resolución

Page 91: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 91 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Tipo de

Finalización

Normativa Evento Pasos de la Fase de

Finalización agravar su situación inicial y sin perjuicio de la potestad de la Administración de incoar de oficio un nuevo procedimiento, si procede. 3. Las resoluciones contendrán la decisión, que será motivada en los casos a que se refiere el artículo 54. Expresarán, además, los recursos que contra la misma procedan, órgano administrativo o judicial ante el que hubieran de presentarse y plazo para interponerlos, sin perjuicio de que los interesados puedan ejercitar cualquier otro que estimen oportuno. 4. En ningún caso podrá la Administración abstenerse de resolver so pretexto de silencio, oscuridad o insuficiencia de los preceptos legales aplicables al caso, aunque podrá resolver la inadmisión de las solicitudes de reconocimiento de derechos no previstos en el Ordenamiento Jurídico o manifiestamente carentes de fundamento, sin perjuicio del derecho de petición previsto por el artículo 29 de la Constitución. 5. La aceptación de informes o dictámenes servirá de motivación a la resolución cuando se incorporen al texto de la misma.

Inadmisión por

causas

formales

(plazo, no

cumplir

requisitos..)7

Solicitud fuera

de plazo, no

cumplir

requisitos

necesarios…

Declaración

(Resolución) de

inadmisión

Notificación de

la resolución

Inadmisión Art 89.4 Ley 30/92 … la Administración…podrá resolver la inadmisión de las solicitudes de reconocimiento de derechos no previstos en el Ordenamiento Jurídico o manifiestamente carentes de fundamento…

Solicitud con

pretensiones

sobre derechos

no previstos en

el

ordenamiento,

carentes de

fundamento..

Acta o informe

previo

(normalmente)

Resolución de

inadmisión

Notificación de

la resolución

Desistimiento

por no

Artículo 42. Ley 30/92 Obligación de resolver. (Modificado por Ley 4/1999)

No subsanación

de la solicitud. Resolución de

desistimiento

7 En

Page 92: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 92 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Tipo de

Finalización

Normativa Evento Pasos de la Fase de

Finalización

subsanación En los casos de prescripción, renuncia del derecho, caducidad del procedimiento o desistimiento de la solicitud, así como la desaparición sobrevenida del objeto del procedimiento, la resolución consistirá en la declaración de la circunstancia que concurra en cada caso, con indicación de los hechos producidos y las normas aplicables Artículo 90 Ley 30/92. Ejercicio.

1. Todo interesado podrá desistir de su solicitud o, cuando ello no esté prohibido por el Ordenamiento Jurídico, renunciar a sus derechos. 2. Si el escrito de iniciación se hubiera formulado por dos o más interesados, el desistimiento o la renuncia sólo afectará a aquellos que la hubiesen formulado.

de subsanación.

Notificación de

la resolución

Desistimiento

expreso

Idem Escrito con

desistimiento. Resolución de

desistimiento

expreso.

Notificación de

la resolución

Renuncia Idem No ejercicio del

derecho. Estudio de

Viabilidad

jurídica

Resolución de

renuncia

(admisión

/inadmisión).

Notificación de

la resolución.

Notificación a

terceros

afectados

Instancias de

continuación

Page 93: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 93 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Tipo de

Finalización

Normativa Evento Pasos de la Fase de

Finalización

Caducidad Artículo 92 Ley 30/92. Requisitos y efectos. 1. En los procedimientos iniciados a solicitud del interesado, cuando se produzca su paralización por causa imputable al mismo, la Administración le advertirá que, transcurridos tres meses, se producirá la caducidad del mismo. Consumido este plazo sin que el particular requerido realice las actividades necesarias para reanudar la tramitación, la Administración acordará el archivo de las actuaciones, notificándoselo al interesado. Contra la resolución que declare la caducidad procederán los recursos pertinentes. 2. No podrá acordarse la caducidad por la simple inactividad del interesado en la cumplimentación de trámites, siempre que no sean indispensables para dictar resolución. Dicha inactividad no tendrá otro efecto que la pérdida de su derecho al referido trámite. 3. La caducidad no producirá por sí sola la prescripción de las acciones del particular o de la Administración, pero los procedimientos caducados no interrumpirán el plazo de prescripción. 4. Podrá no ser aplicable la caducidad en el supuesto de que la cuestión suscitada afecte al interés general, o fuera conveniente suscitarla para su definición y esclarecimiento.

No

continuación

del

procedimiento

por inactividad

del solicitante

en un plazo de

tiempo.

Resolución de

la caducidad.

Notificación de

la caducidad.

Caducidad por

inactividad de

la

Administración

p.ej. en el RD 1339/1993 Reglamento procedimiento potestad sancionadora

Artículo 6. Prescripción y archivo de las actuaciones.

2. Transcurridos dos meses desde la fecha en que se inició el procedimiento sin haberse practicado la notificación de éste al imputado, se procederá al archivo de las actuaciones, notificándoselo al imputado, sin perjuicio de las responsabilidades en que se hubiera podido incurrir

Caducidad del

procedimiento

por inactividad

de la

Administración.

Resolución de

la caducidad

(sobreseimiento

y/o archivo).

Notificación de

la caducidad.

Terminación

por pacto o

convenio

Artículo 42 Artículo 42. Obligación de resolver. (Modificado por Ley 4/1999)

Acuerdo entre

el interesado y

la

No existe

obligación de

resolución

Page 94: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 94 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Tipo de

Finalización

Normativa Evento Pasos de la Fase de

Finalización 1. La Administración está obligada a dictar resolución expresa en todos los procedimientos y a notificarla cualquiera que sea su forma de iniciación. En los casos de prescripción, renuncia del derecho, caducidad del procedimiento o desistimiento de la solicitud, así como la desaparación sobrevenida del objeto del procedimiento, la resolución consistirá en la declaración de la circunstancia que concurra en cada caso, con indicación de los hechos producidos y las normas aplicables. Se exceptúan de la obligación, a que se refiere el párrafo primero, los supuestos de terminación del procedimiento por pacto o convenio, asi como los procedimientos relativos al ejercicio de derechos sometidos únicamente al deber de comunicación previa a la Administración.

administración

Archivo por

causa

sobrevenida

Artículo 87 Ley 30/92. Terminación.

También producirá la terminación del procedimiento la imposibilidad material de continuarlo por causas sobrevenidas. La resolución que se dicte deberá ser motivada

en todo caso.

Archivo del

expediente por

imposibilidad

material de

continuarlo

Resolución de

archivo

Notificación del

Archivo

3.3.3.60. Caso de Uso – Campos Flexibles

A continuación se describe la extensión del escritorio de tramitación genérico para utilizar campos

dinámicos “flexibles” en determinadas pantallas. En determinados procedimientos se usa un modelo de

datos de gestión particular sencillo. Normalmente sería necesario extender el tramitador construyendo

una aplicación completa de gestión para cubrir estos datos particulares que escapan al ámbito del

tramitador genérico.

Se plantea por tanto la necesidad de extender el tramitador para incluir estos datos en las pantallas ya

existentes, de modo que puedan ser incluidos los campos necesarios. Estos campos “flexibles” serán

configurados en el Catálogo de procedimientos, mientras que el valor de los mismos se almacenará a

nivel de datos de expediente.

3.3.3.60.1. Tipos de campos flexibles

Page 95: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 95 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

La tipología de campos flexibles que se contempla será un subconjunto de los tipos de datos que

pueden incluirse en un formulario HTML clásico. Se contemplan los siguientes tipos de campo –entre

paréntesis los elementos HTML con los que se relacionan-

Campo de texto simple (textfield, textarea): Campo de texto que almacena un dato de texto

único.

Campo de tipo calendario (calendar): Campo que almacena una fecha.

Selección sencilla desde lista (combo, option) Se muestra un listado de valores del cual se

selecciona un valor único.

Selección múltiple desde lista (checkbox). Se muestra un listado de valores del cual se

selecciona uno o varios valores.

3.3.3.60.2. Validaciones de campos

Se contempla la validación sencilla de campos flexibles, realizándose esta de modo individual respecto

a otros datos existentes (es decir, no se consideran validaciones cruzadas con otros datos).

Las validaciones que se realizarán sobre los campos serán las mismas que actualmente permite realizar

el FWK-PA a través del plugin de Struts “org.apache.struts.validator.ValidatorPlugIn”, que se

encuentra definidas en el fichero “validator-rules.xml”.

Required

Integer / Long / Float

Date

CreditCard

Email

Url

Nif / Cif / Nie

Básicamente se podrán usar las validaciones asociadas a un elemento único.

Page 96: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 96 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

ANEXO, MODELO DE DATOS

Se muestra a continuación el modelo de datos del catálogo con las tablas que intervienen en la construcción de campos flexibles.

El modelo de datos se distribuye en dos esquemas diferentes: catálogo (diseño de campos flexibles) y expediente (datos flexibles de cada expediente concreto).

cd Catalogo

CAMPO_PERSONALIZABLE

*PK «Column» CN_CAMPO: NUMBER(10)

*FK «Column» CN_TIPO_CAMPO: NUMBER(10)

* «Column» TE_ETIQUETA: VARCHAR2(50)

+ «PK» PK_CAMPO_PERSONALIZABLE(NUMBER)

+ «FK» FK_CAMPO_PERSONALIZ_TIPO_CAMPO(NUMBER)

CAMPO_PROCEDIMIENTO

*pfK «Column» CN_PROCEDIMIENTO: NUMBER(10)

*pfK «Column» CN_CAMPO: NUMBER(10)

* «Column» TE_ETIQUETA: VARCHAR2(50)

* «column» CN_PUNTO_INTEGRACION: NUMBER(10)

+ «PK» PK_CAMPO_PROCEDIMIENTO(NUMBER, NUMBER)

+ «FK» FK_CAMPO_PROCEDI_CAMPO_PERSONA(NUMBER)

+ «FK» FK_CAMPO_PROCEDI_PROCEDIMIENTO(NUMBER)

TIPO_CAMPO

*PK «Column» CN_TIPO_CAMPO: NUMBER(10)

* «Column» TE_DESCRIPCION: VARCHAR2(50)

+ «PK» PK_TIPO_CAMPO(NUMBER)

VALIDACION_CAMPO

*pfK «column» CN_VALIDACION_CAMPO: NUMBER(10)

FK «column» CN_CAMPO: NUMBER(10)

«column» CN_TIPO_VALIDACION: NUMBER(10)

+ «FK» FK_CN_CAMPO(NUMBER)

+ «FK» FK_CN_VALIDACION_CAMPO(NUMBER)

+ «PK» PK_VALIDACION_CAMPO(NUMBER)

TIPO_VALIDACION_CAMPO

*PK «column» CN_TIPO_VALIDACION_CAMPO: NUMBER(10)

«column» TE_NOMBRE_VALIDACION: VARCHAR2(150)

«column» TE_TIPO_VALIDACION: VARCHAR2(150)

+ «PK» PK_TIPO_VALIDACION_CAMPO(NUMBER)

VALOR_CAMPO

* «column» CN_CAMPO: NUMBER(10)

* «column» TE_VALOR: VARCHAR2(150)

«column» FL_VALOR_DEFECTO: CHAR(1)

+ «FK» FK_CN_CAMPO(NUMBER)

+CN_VALIDACION_CAMPO

+PK_TIPO_VALIDACION_CAMPO

+CN_CAMPO+PK_CAMPO_PERSONALIZABLE

0..*+FK_CAMPO_PROCEDI_CAMPO_PERSONA

(CN_CAMPO = CN_CAMPO)

1+PK_CAMPO_PERSONALIZABLE

0..*+FK_CAMPO_PERSONALIZ_TIPO_CAMPO

(CN_TIPO_CAMPO = CN_TIPO_CAMPO)

1+PK_TIPO_CAMPO

+CN_CAMPO+PK_CAMPO_PERSONALIZABLE

Page 97: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 97 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

cd Expediente

DATO_FLEXIBLE

*PK «column» CN_DATO_FLEXIBLE: NUMBER(10)

* «column» CN_EXPEDIENTE: NUMBER(10)

* «column» CN_CAMPO: NUMBER(10)

+ «PK» PK_VALOR_CAMPO_FLEXIBLE(NUMBER)

VALOR_DATO_FLEXIBLE

*FK «column» CN_DATO_FLEXIBLE: NUMBER(10)

* «column» TE_VALOR: VARCHAR2(150)

+ «FK» FK_CN_DATO_FLEXIBLE(NUMBER)

+CN_DATO_FLEXIBLE

+PK_VALOR_CAMPO_FLEXIBLE

3.3.3.60.3. Flujo de eventos

Este capítulo es dependiente de la configuración que se haya realizado para un procedimiento

determinado. Para esto es necesario realizar dicha configuración basándose en el documento de

configuración de Catálogo.

Una vez definido correctamente se podrán añadir, borrar o modificar los campos que se hayan

parametrizado.

3.3.3.61. Caso de Uso – Impresión conjunta.

Page 98: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 98 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

ud impresion conjunta

Tramitador

(from Actores)

Impresion

Conjunta

Impresión de los

actos de un

expediente

Impresión de los

documentos de

tramitación en bloque

Imprersión de un Acto

para v arios

expedientes

«extend»

«extend»

«extend»

El caso de uso de impresión conjunta representa la funcionalidad de generar, a partir de una lista de

documentos almacenados en el Modulo Común de Gestión de Documentación, que sean de tipo RTF,

generar un documento como resultado de la concatenación de la lista de documentos que se le pasan

como parámetro.

Este documento generado, será de carácter temporal y lo servirá Modulo Común de Gestión de

Documentación, no quedando persistido en el Gestor Documental.

El objetivo de este documento generado será la impresión en un solo paso de la lista de documentos

citada.

Este caso de uso sirve como base para todos los casos de uso de Impresión Conjunta.

3.3.3.61.1. Descripción

ID Requisito

Actores Tramitador

Page 99: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 99 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Prioridad

Nivel de Riesgo

Precondiciones Se tiene una lista de documentos RTF almacenados en el Modulo Común de Gestión de

Documentación.

Postcondiciones Se genera un único documento como concatenación de la lista de los documentos RTF.

Comentarios

3.3.3.61.2. Flujo de eventos.

Se recibe como entrada una lista de documentos RTF almacenados en el Modulo Común de

Gestión Documental.

El Modulo Común genera un único documento RTF como resultado de la concatenación de los

documentos que se le pasan.

El Modulo Común genera una URL de carácter temporal para servir el documento generado.

La aplicación además de mostrar el enlace al documento, manda a la cola de impresión el

documento.

3.3.3.62. Caso de Uso – Impresión conjunta de los actos de un expediente.

Este caso de uso permite la Impresión conjunta de los actos de un expediente.

3.3.3.62.1. Descripción

ID Requisito

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones Se accede a la pantalla de tramitar.

Postcondiciones Se imprime un único documento como concatenación de los actos del expediente.

Comentarios

3.3.3.62.2. Flujo de eventos.

El actor Tramitador selecciona un expediente y accede a la pantalla de tramitar.

Page 100: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 100 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

En la pantalla de tramitar se muestran los documentos asociados a los actos de un expediente,

bien se muestran todos los del expediente, los de la fase actual o los de la revisión actual.

Se pulsa el botón de imprimir todos los documentos mostrados. Independientemente de que el

resultado se muestre paginado, la impresión se hará sobre todos los documentos del expediente,

los de la fase actual o los de la revisión actual según el actor Tramitador escoja.

Con la lista de documentos mostrados se ejecuta el caso de uso de “Impresión Conjunta”.

Se muestra la URL con el documento generado y se encola para imprimir el documento

generado.

3.3.3.63. Caso de Uso – Impresión conjunta del los documentos de tramitación en bloque.

Este caso de uso permite la Impresión conjunta de los documentos generados en una tramitación en

bloque.

3.3.3.63.1. Descripción

ID Requisito

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones El actor se encuentra en la pantalla de resultados para una tramitación en bloque.

Postcondiciones Se imprime un único documento como concatenación de los documentos de tramitación en

bloque.

Comentarios

3.3.3.63.2. Flujo de eventos.

El actor Tramitador se encuentra en el resultado de una tramitación en bloque, bien por que

acaba de terminar la ejecución de la tramitación, o bien por que la ha recuperado del histórico de

tramitaciones.

En la pantalla del resultado de tramitación se muestran los documentos generados para esa

tramitación.

Se mostrará checks para cada documento que indicará que ese documento pertenece a la

impresión conjunta, todos los checks estarán activos por defecto. En el caso de que los

resultados estén paginados existirá la opción de “Marcar todos” o “Desmarcar todos”.

Se pulsa el botón de imprimir todos los documentos marcados.

Con la lista de documentos marcados se ejecuta el caso de uso de “Impresión Conjunta”.

Page 101: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 101 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Se muestra la URL con el documento generado y se encola para imprimir el documento

generado.

3.3.3.63.3. Excepciones.

A la hora de generar el documento concatenado no se tendrá en cuenta los documentos de acuse de

recibo, quedando fuera de la impresión conjunta.

3.3.3.64. Caso de Uso – Impresión de conjunta de un acto para varios expedientes.

Este caso de uso permite la Impresión conjunta de un mismo acto para varios expedientes.

3.3.3.64.1. Descripción

ID Requisito

Actores Tramitador

Prioridad

Nivel de Riesgo

Precondiciones Se dispone de un carrito de tramitación en bloque.

Postcondiciones Se imprime un único documento como concatenación de los documentos asociados a un acto

para un conjunto de expedientes de tramitación en bloque.

Comentarios

3.3.3.64.2. Flujo de eventos.

El actor Tramitador ha seleccionado un conjunto de expedientes en el carrito de tramitación en

bloque y se encuentra en la pantalla de configuración para iniciar la tramitación en bloque.

Se selecciona el acto en un desplegable pudiendo filtrar los actos por fase.

Se pulsa el botón de imprimir el acto, para todos los expedientes del carrito.

Se advierte al usuario de los expedientes que no tienen instanciado el acto seleccionado,

mostrando una lista de los mismos dandoles la opción de instanciarlo en este momento o de

excluirlos de la “impresión conjunta”. Quizas no se tramitable en bloque.

Se obtiene los documentos asociados al acto seleccionado para cada unos de los expedientes, y

con la lista de documentos, se ejecuta el caso de uso de “Impresión Conjunta”. En el caso de que

un expediente tenga varios documentos instanciados del mismo acto se imprimirán todos ellos.

Se muestra la URL con el documento generado y se encola para imprimir el documento

generado.

Page 102: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 102 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

4. ARQUITECTURA TECNOLÓGICA

4.1. ARQUITECTURA

El Escritorio Unificado del Gestor (EUG) se compone de varios sistemas horizontales (subvenciones,

registros, etc…), cada uno de estos sistemas horizontales se han creado usando en Framework de

Tramitación el cual provee de multitud de funcionalidades descritas en otros apartados (creación de

expedientes, visor, documentación, tramitación etc…), cada uno de los sistemas horizontales son

aplicaciones J2EE realizadas con el Framework del Principado de Asturias y por lo tanto son

aplicaciones que se despliegan individualmente pero que pueden integrarse entre sí y que tienen la

misma apariencia.

A continuación se describen los componentes y subsistemas que utiliza o han sido utilizados para la

creación del EUG:

Page 103: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 103 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

4.1.1. FrameworkPA

El EUG ha sido creado con el Framework del Principado de Asturias para garantizar la estandarización

de las aplicaciones..

4.1.2. Bases de Datos

El EUG se apoya en 2 esquemas de bases de datos donde se almacena la información tanto del

procedimiento administrativo como de los expedientes que son creados en el mismo:

4.1.2.1. Esquema de catálogo

Este esquema de base de datos es único para todos los procedimientos administrativos, en él se define,

parametriza y configura tanto el flujo del procedimiento administrativo (Fases, actos, plantillas etc…),

como la configuración de la integración entre el EUG con los diferentes sistemas de gestión (urls de

gestión, nuevos puntos de menú de gestión etc…).

4.1.2.2. Esquema de expedientes

Este esquema es utilizado para almacenar todos los datos de los expedientes que se crean dentro del

EUG.

4.1.3. Service BPEL

Se utiliza la capa “serviceBPEL” que es una capa intermedia para usar el servicio Worklist (lista de

tareas) del producto ORACLE BPEL para realizar el flujo administrativo de un expediente, en la

worklist se crea una tarea por cada uno de los actos administrativos. Cada procedimiento

administrativo tiene que tener creado un proceso BPEL con sus fases para que un expediente pueda

crear sus actos.

4.1.4. Módulo de Autenticación

Se corresponde con el sistema de registro de entrada de usuarios a las aplicaciones del

Principado de Asturias., este módulo permite la autenticación y autorización de los usuarios en

el escritorio, habilita a los usuarios a trabajar en determinados procedimientos administrativos

con diferentes roles.

Page 104: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 104 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

4.1.5. Servicio de Número de Expediente

El número de expedientes es un número utilizado por otras herramientas de tramitación del

Principado, para ello existe un servicio que es consumido por el EUG para la obtención de este

número de expediente.

4.1.6. Servicio de Registro de entrada

El EUG se integra con el Registro de entrada para obtener la información capturada a través del

registro de entrada y ser accedida para completar automáticamente los datos del expediente.

4.1.7. Servicio de Registro de salida

El EUG se integra con el Registro de salida obtener números de registro de salida lo que posibilita el

incorporarlos automáticamente a los documentos.

4.1.8. Módulo de Genéricos

El EUG se integra directamente con la base de datos de genéricos del Principado de Asturias, esto se

realiza para la definición del territorio de un expediente.

4.1.9. Módulo de Terceros

El EUG se integra directamente con la base de datos de terceros del Principado de Asturias, esto es

usado para dar de alta todos los afectados de un expediente.

4.1.10. Alertas

El EUG proporciona un sistema de alertas y alarmas, actualmente está incorporado dentro del propio

escritorio aunque su destino final será realizar un módulo común de alertas y alarmas reutilizable por

todos los sistemas del Principado de Asturias.

4.1.11. Módulo común de documentación

El EUG se integra con el M.C. de documentación para la creación de documentos dentro del mismo,

principalmente es utilizado en la funcionalidad de tramitación donde normalmente los actos están

asociados con la generación de documentos, también se hace uso para la gestión de la documentación

aportada al expediente.

Page 105: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 105 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

4.1.11.1.1. Gestor documental

Para el funcionamiento del M.C. de documentación es necesario la disponibilidad de un

Se corresponde con el sistema de almacenamiento de los documentos asociados a los trámites

administrativos del Principado de Asturias, actualmente es usado INVESDOC.

SIEBEL

Se corresponde con el CRM del Principado de Asturias.

4.1.12. Modelo de Componentes

Page 106: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 106 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

id Modelo de Componentes

Catálogo de

ProcedimientosSIEBELGestor

Documental

«MC»

módulos

comunes::

Autenticación

«MC»

módulos

comunes::SMS

«MC»

módulos

comunes::

Registro

Telemático

«MC»

módulos

comunes::

Cambio de

Estado

«MC»

módulos

comunes::Inicio

Solicitud

«MC»

módulos

comunes::

Terceros

«MC»

módulos

comunes::

Genéricos

Framework

Sistema de

Gestion

Aplicacion de

Tramitacion

Horizontal

Modulo de

Generacion

Documentos

Repositorio

Parametrizacion

Repositorio

Alertas

Repositorio

Procedimientos

Modulo Comun

Alertes

Repositorio

mantenido y

gestionado por el

Servicio de

Modernización

Estos tramitadores, son

aplicaciones horizontales

especializadas por familia de

procedimientos.

Repositorio

Plantillas

Seguramente este

repositorio se

encontrará alojado

en el propio gestor

documental

Repositorio

expedientes

El repositorio de parametrización

permitirán adecuar el interfaz y

añadirle ciertos automatismos a los

procedimientos incluidos en el

tramitador genérico.

Repositorio

Objetos Gestión

Repositorio

Generico

Expedientes

Este repositoio,

que debería ser

único por unidad

funcional,

almacenará tanto

los objetos de

gestión como los

expedientes a los

que afectan.

Este repositorio es "virtual" y

se corresponde a un esquema

de BB.DD. con TODOS los

datos que obligatoriamente

debe contener un expediente.

Page 107: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 107 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

4.1.13. Especificaciones de Integración

Módulo Se integra con Características

4.1.14. Integración con SAC

4.1.14.1. Apuntes en CRM

Por cada apunte en SIEBEL definir:

Trámite

Evento

SR/Actividad

Categoría

Tipo

Subtipo 1

Subtipo 2

Asunto 1

4.1.14.2. Apuntes en el modelo intermedio

Por cada apunte en el modelo intermedio definir:

Trámite

Situación administrativa

Estado actual

Objeto del expediente

Nombre del hito

Unidad tramitadora

Plazo de resolución

Page 108: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 108 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

Fecha de finalización

Datos adicionales

4.2. ARQUITECTURA PARA LA TRAMITACIÓN EN BLOQUE.

4.2.1. Modelo de componentes.

id Modelo de Componentes

PAC

HorizontalPAC

fwpaet-core

Tramitacion Bloque

GestionCarrito

GestionActos-

AccionesTramitables

GestionResultados-

Tramitacion

MTB-CLIENT

MTB

ValidacionTramitacion

EjecuccionTramitacion

RecepcionTramitacion

Gestion de

contexto de

tramitacion

bloque

«artifact»

CATALOGO

«artifact»

TramitadorDSResultado de la tramitacion

consulta estado tramitacion

4.2.1.1. Descripción general del modelo de componentes para la tramitación en bloque.

El modelo de componentes de la tramitación en bloque se puede dividir a grandes rasgos en dos partes,

la primera es el Motor de Tramitación en Bloque (MTB) que es el encargado de realizar de forma

asíncrona la tramitación en bloque.

Page 109: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 109 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

La segunda parte, es el cliente del Motor de tramitación, que está integrado como parte del PAC o en

su defecto del sistema horizontal que corresponda. El cliente de tramitación en bloque tiene la

responsabilidad de enviar los expedientes tramitables a al Motor de tramitación, así como consultar el

estado de la tramitación en bloque que se deja en la base de datos de tramitación.

4.2.1.2. Componente: Tramitación en bloque

Se integra en el PAC o su defecto en el horizontal correspondiente, tiene como responsabilidad la

servir y obtener los resultados del Motor de Tramitación y se divide en los componentes MTB-Client,

Gestión Carrito, Gestión Actos Tramitables, Gestión Resultados Tramitación, Gestión Contexto

Tramitación , que se describen a continuación.

4.2.1.3. Componente: MTB-Client.

Este componente es el encargado de enviar a al MTB, la petición de tramitación en bloque de un

carrito de tramitación previamente persistido, así como de persistir el contexto de tramitación para que

el MTB sea capaz de tramitar de manera asíncrona los expedientes de un carrito.

4.2.1.4. Componente: Gestión Contexto de tramitación.

Este componente se encarga de gestionar y persistir el contexto de la tramitación en bloque, que será el

conjunto de datos necesarios para ejecutar la tramitación en bloque de manera asíncrona.

4.2.1.5. Componente: Gestión Carrito.

El componente de gestión del carrito se encargará de gestionar la persistencia de el grupo de

expedientes que se quiere tramitar conjuntamente. Para ello antes de realizar la tramitación en bloque

se persistirá la lista de expedientes agrupándolos en un carrito de tramitación.

4.2.1.6. Componente: Gestión Actos Tramitables.

Este componente gestiona los actos que están disponibles para la tramitación en bloque, así como los

caminos de tramitación para cada acto tramitable. Los actos tramitables son los que aparecerán para

seleccionar en función del procedimiento y expedientes seleccionados para tramitar en bloque.

4.2.1.7. Componente: Gestión Resultados Tramitación.

Este componte se encarga de mostrar los resultados obtenidos tras la ejecución de la tramitación,

obtendrá los resultados que se han persistido en el esquema del TramitadorDS.

Page 110: Diseño funcional 03. DiseñoFuncional openEUG 20111230 v1 · Proyecto OpenFWPA Internacional openEUG Página 3 de 110 Estado Definitivo Documento Diseño funcional Cluster TIC ()

Proyecto OpenFWPA Internacional

openEUG

Página 110 de 110

Estado Definitivo

Documento Diseño funcional

Cluster TIC (www.clustertic.net) 03. DiseñoFuncional_openEUG_20111230_v1.0.doc 30/12/2011

4.2.1.8. Componente: Gestión Contexto Tramitación.

Este componente se encarga de gestionar la necesidad de introducir unos datos de contexto para que se

pueda ejecutar la tramitación sin intervención del usuario. Para ello antes de empezar la tramitación en

bloque se solicitará al usuario datos de contexto, se persistirán y se pasarán como parámetro al MTB.

4.2.1.9. Componente: MTB

El componente MTB se encarga de ejecutar la tramitación en bloque, a partir de los datos en el carrito

y los datos de contexto, ejecuta los actos correspondientes de manera asíncrona sin intervención del

usuario, dejando los resultados en el esquema del TramitadorDS.

4.2.1.10. Componente: Validación Tramitación.

Este componente válida que la tramitación en bloque sea consistente, de manera que no se ejecuten

actos que dejen la tramitación en estado inconsistente, y que los actos se ejecuten en la fase y

cardinalidad adecuada.

4.2.1.11. Componente: Ejecución Tramitación.

Este es el principal componente del MTB, realiza la ejecución y actualización del estado de los

trámites para cada expediente de la tramitación en bloque.

4.3. MODELO DINÁMICO

Si se desea, especificar algún tipo de comportamiento dinámico entre componentes, puede hacerse

aquí. Puede ser necesario añadir algún diagrama de secuencia, estados, actividad…

4.3.1. Diagrama/s dinámicos

Si fuera necesario, añadir aquí los diagramas de la vista dinámica que correspondan.

4.4. DIAGRAMA DE DESPLIEGUE

El motor de la tramitación en bloque está incrustado dentro de los sistemas horizontal.