Propuesta para Trabajo de Grado - Trabajos de Grado de la...
Transcript of Propuesta para Trabajo de Grado - Trabajos de Grado de la...
PA111-01 MODELO DE ARQUITECTURA DE SISTEMA DEL VOTO ELECTRÓNICO EN EL
MUNICIPIO DE CHOACHÍ
DANIEL YESID CACERES RINCON
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIA
MAESTRÍA EN INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
BOGOTÁ, D.C.
2012
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página i
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
PA111-01
MODELO DE ARQUITECTURA DE SISTEMA DEL VOTO ELECTRÓNICO EN
EL MUNICIPIO DE CHOACHÍ
Autor:
Daniel Yesid Cáceres Rincón
MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO
DE LOS REQUISITOS PARA OPTAR AL TITULO DE
MAGÍSTER EN INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
Director
Ing. Rafael Andrés González Rivera, PhD.
Comité de Evaluación del Trabajo de Grado
Ing. Diego Torres, MA.
Ing. Miguel Torres, Msc.
Página web del Trabajo de Grado
http://pegasus.javeriana.edu.co/~PA111-01
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIA
MAESTRÍA EN INGENIERIA DE SISTEMAS Y COMPUTACIÓN
BOGOTÁ, D.C.
Enero, 2012
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página ii
PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
Rector Magnífico
Joaquín Emilio Sánchez García S.J.
Decano Académico Facultad de Ingeniería
Ingeniero Luis David Prieto Martínez
Decano del Medio Universitario Facultad de Ingeniería
Padre Sergio Bernal Restrepo S.J.
Director Maestría en Ingeniería de Sistemas y Computación
Ingeniero Enrique González Guerrero
Director Departamento de Ingeniería de Sistemas
Ingeniero César Julio Bustacara Medina
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página iii
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Artículo 23 de la Resolución No. 1 de Junio de 1946
“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus
proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral
católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que
se vean en ellos el anhelo de buscar la verdad y la Justicia”
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página iv
AGRADECIMIENTOS
Quiero dar agradecimientos muy especiales en primer lugar a mis padres, por permitirme tener la oportunidad de realizar esta maestría, a mi director de proyecto quien me guio durante todo el tiempo para poder lograr la meta de este proyecto. De igual forma, agradezco al registra-dor municipal de Choachí Dr. Jorge Díaz, al personero de Choachí Dr. Diego Julián Pardo Rincón, a los ingenieros Julio Carreño y José Niño quienes estuvieron siempre muy colaboradores conmigo y con el desarro-llo del proyecto.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página v
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Contenido
INTRODUCCIÓN ..............................................................................................................1
I - OBJETIVOS ................................................................................................................3
1. OBJETIVOS ..................................................................................................................3 1.1 Objetivo General ........................................................................................................... 3 1.2 Objetivos Específicos..................................................................................................... 3 1.3 Definiciones ................................................................................................................... 4 1.4 Acrónimos ...................................................................................................................... 4
II – MARCO TEÓRICO ...................................................................................................5
III - MÉTODO .................................................................................................................6
IV – MODELO DE ARQUITECTURA DE SISTEMA ...........................................................9
1. MODELO DE ARQUITECTURA EMPRESARIAL ...............................................................9 1.1 Selección de Vistas ...................................................................................................... 10 1.2 Actores ......................................................................................................................... 10 1.3 Stakeholders ................................................................................................................ 12 1.4 Vista Introductoria (Introductory Viewpoint) ............................................................. 13 1.5 Vista de la Organización (Organization Viewpoint) ................................................... 18 1.6 Vista de Co-operación de Actores (Actor Co-operation viewpoint) ........................... 19 1.7 Vista de Proceso de Negocio (Business Process Viewpoint) ...................................... 20 1.8 Vista de Co-operación del Proceso de Negocio (Business Process Co-operation
Viewpoint) ......................................................................................................................... 25 1.9 Vista de Comportamiento de la Aplicación (Application Behavior Viewpoint) .......... 27 1.10 Vista de Infraestructura (Infrastructure Viewpoint) ................................................. 30
2. MODELO DE ARQUITECTURA DE SOFTWARE .............................................................31 2.1 Identificación y Selección de Patrones de Negocio ..................................................... 35 2.2 Introducción al Patrón de Arquitectura N-Tier .......................................................... 38 2.3 Identificación y Selección de Patrones de Diseño ....................................................... 39
3. DISEÑO DE LA BASE DE DATOS PARA EL VOTO ELECTRÓNICO ..................................48 3.1 Diseño Lógico de la Base de Datos para el Proceso de Inscripción de Electores y
Candidatos......................................................................................................................... 48 3.2 Diseño Lógico de la Base de Datos para el Proceso de Votación .............................. 48
V – PROTOTIPO Y VALIDACIÓN ..................................................................................51
1. PROTOTIPO ................................................................................................................51
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página vi
2. VALIDACIÓN DE LA ARQUITECTURA EMPRESARIAL ..................................................52 2.1 Validación Sintáctica realizada por el Ing. José C. Niño ........................................... 53 2.2 Validación Semántica realizada por el Registrador municipal de Choachí, Dr. Jorge
A. Díaz ............................................................................................................................... 54
3. VALIDACIÓN DE LA ARQUITECTURA DE SOFTWARE ..................................................54 3.1 Validación según ATAM .............................................................................................. 54 3.2 Validación TAM .......................................................................................................... 57
VI - CONCLUSIONES ....................................................................................................60
VII – TRABAJO FUTURO ..............................................................................................63
VIII – BIBLIOGRAFÍA ..................................................................................................64
IX – ANEXOS ................................................................................................................69
1. ANEXO A ..................................................................................................................69
2. ANEXO B ...................................................................................................................89
3. ANEXO C ...................................................................................................................90
4. ANEXO D ..................................................................................................................93
5. ANEXO E ...................................................................................................................98
6. ANEXO F .................................................................................................................105
7. ANEXO G ................................................................................................................107
8. ANEXO H ................................................................................................................108
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página vii
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Lista de Tablas
Tabla 1. Definiciones ................................................................................................................ 4
Tabla 2. Acrónimos ................................................................................................................... 4
Tabla 3. Capas y vistas............................................................................................................ 10
Tabla 4. Actores ...................................................................................................................... 12
Tabla 5. Stakeholders .............................................................................................................. 13
Tabla 6. Arquitectura empresarial: Stakeholders vs Actores .................................................. 13
Tabla 7. Mapeo de Actores CU actual vs Actores Arquitectura Empresarial vs Actores CU E-
Vote2 ....................................................................................................................................... 33
Tabla 8. Procesos de la registraduría municipal de Choachí vs Procesos según BPTrends.
Autor: Daniel Cáceres. ............................................................................................................ 35
Tabla 9. Patrones de negocio de Forster vs Procesos de negocio de la Registraduría municipal
de Choachí. Autor: Daniel Cáceres ......................................................................................... 36
Tabla 10. Patrones de negocio de Forster vs Procesos de negocio de la Registraduría
municipal de Choachí. Autor: Daniel Cáceres ........................................................................ 37
Tabla 11. Patrones de negocio de Kim et Al. vs Procesos de negocio de la Registraduría
municipal de Choachí. Autor: Daniel Cáceres. ....................................................................... 38
Tabla 12. Aplicaciones vs Atributos de calidad ...................................................................... 41
Tabla 13. Aplicaciones vs Atributos de Calidad según Khosravi y Guéhéneuc ..................... 41
Tabla 14. Aplicación Registro Candidato vs Patrones de diseño ............................................ 42
Tabla 15. Aplicación registro elector vs Patrones de diseño .................................................. 42
Tabla 16. Aplicación votación vs Patrones de diseño ............................................................. 42
Tabla 17. Aplicación resultados escrutinio vs Patrones de diseño .......................................... 43
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página viii
Tabla 18. Relación de patrones en el nivel 1 de diseño .......................................................... 46
Tabla 19. Resumen Aplicación de ATAM sobre la arquitectura de sistema del voto
electrónico ............................................................................................................................... 56
Tabla 20. Patrón Service Factory - CU Almacenar formularios en DB .................................. 57
Tabla 21. Patrón Service Factory – CU Almacenar registro electores ................................... 57
Tabla 22. Resultados registrador TAM ................................................................................... 59
Tabla 23. Resultados ciudadanos TAM .................................................................................. 59
Tabla 24. Descripción de los patrones de Web Services ........................................................ 90
Tabla 25. Elector ..................................................................................................................... 90
Tabla 26. Cierre proceso electoral .......................................................................................... 90
Tabla 27. Inicio proceso Electoral .......................................................................................... 90
Tabla 28. Proceso electoral ..................................................................................................... 91
Tabla 29. Municipio ................................................................................................................ 91
Tabla 30. Departamento .......................................................................................................... 91
Tabla 31. Inscripción elector ................................................................................................... 92
Tabla 32. Inscripción candidato .............................................................................................. 92
Tabla 33. Cargo candidato ...................................................................................................... 92
Tabla 34. Aval ......................................................................................................................... 92
Tabla 35. Partido político ........................................................................................................ 93
Tabla 36. Tipo Aval ................................................................................................................ 93
Tabla 37. Puesto ...................................................................................................................... 93
Tabla 38. Mesa ........................................................................................................................ 93
Tabla 39. Boletín ..................................................................................................................... 94
Tabla 40. Cargo jurado ........................................................................................................... 94
Tabla 41. Jurado ...................................................................................................................... 94
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página ix
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Tabla 42. Participantes ............................................................................................................ 94
Tabla 43. Otro tipo .................................................................................................................. 95
Tabla 44. Inscrip ..................................................................................................................... 95
Tabla 45. Candidato ................................................................................................................ 95
Tabla 46. Partido ..................................................................................................................... 96
Tabla 47. Candidato consulta .................................................................................................. 96
Tabla 48. Voto alcaldía ........................................................................................................... 96
Tabla 49. Voto concejo ........................................................................................................... 96
Tabla 50. Voto consulta .......................................................................................................... 96
Tabla 51. Voto ........................................................................................................................ 97
Tabla 52. Corporación ............................................................................................................ 97
Tabla 53. Casos de Uso y atributos de calidad para validación ATAM ............................... 112
Tabla 54. Patrón Service Factory - CU Almacenar formularios en DB ................................ 113
Tabla 55. Patrón Service Factory - CU Almacenar registro candidatos ............................... 114
Tabla 56. Patrón Service Factory - CU Almacenar registro electores .................................. 114
Tabla 57. Patrón Business Process (Composition) - CU Almacenar conteo preliminar ....... 114
Tabla 58. Patrón Business Process (Composition) - CU Almacenar reports ........................ 115
Tabla 59. Patrón Business Process (Composition) - CU Almacenar votos del sistema ........ 115
Tabla 60. Patrón Business Process (Composition) - CU Bajar servicio jornada de votación 116
Tabla 61. Patrón Business Process (Composition) - CU Bajar servicio post-elección ......... 116
Tabla 62. Patrón Business Process (Composition) - CU Bajar servicios de validación
biométrica y código de barras ............................................................................................... 116
Tabla 63. Patrón Business Process (Composition) - CU Cerrar jornada post-elección ........ 117
Tabla 64. Patrón Business Process (Composition) - CU Cerrar jornada de votación ........... 117
Tabla 65. Patrón Service Factory - CU Cerrar proceso de inscripciones candidatos ............ 118
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página x
Tabla 66. Patrón Service Factory - CU Cerrar proceso de inscripciones electores .............. 118
Tabla 67. Patrón Business Process (Composition) - CU Crear DB de registro .................... 118
Tabla 68. Patrón Business Process (Composition) - CU Crear DB de votos ........................ 119
Tabla 69. Patrón Business Process (Composition) - CU Crear formularios E-24/E-26 ....... 119
Tabla 70. Patrón Service Factory - CU Crear una DB de registro candidatos ...................... 120
Tabla 71. Patrón Service Factory - CU Crear una DB de registro electores ......................... 120
Tabla 72. Patrón Business Process (Composition) - CU Generar certificado electoral ........ 120
Tabla 73. Patrón Business Process (Composition) - CU Generar certificado inscripción
alcaldía .................................................................................................................................. 121
Tabla 74. Patrón Business Process (Composition) - CU Generar certificado inscripción
concejo .................................................................................................................................. 121
Tabla 75. Patrón Business Process (Composition) - CU Generar certificado inscripción
electoral ................................................................................................................................. 121
Tabla 76. Patrón Business Process (Composition) - CU Habilitar acceso a la interface de
votación ................................................................................................................................. 122
Tabla 77. Patrón Service Factory - CU Iniciar proceso inscripciones candidatos ................ 122
Tabla 78. Patrón Service Factory - CU Iniciar proceso inscripciones electores ................... 123
Tabla 79. Patrón Business Process (Composition) - CU Iniciar jornada de votación ........... 123
Tabla 80. Patrón Business Process (Composition) - CU Iniciar servicio jornada votación .. 123
Tabla 81. Patrón Business Process (Composition) - CU Iniciar servicios jornada post-elección
.............................................................................................................................................. 124
Tabla 82. Patrón Business Process (Composition) - CU Iniciar servicio jornada post-elección
.............................................................................................................................................. 124
Tabla 83. Patrón Business Process (Composition) - CU Iniciar servicio de validación
biométrica y código de barras ............................................................................................... 124
Tabla 84. Patrón Business Process (Composition) - CU Monitorear el sistema de votación 125
Tabla 85. Patrón Service Factory - CU Validar el elector en jornada de votación ............... 125
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página xi
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Tabla 86. Patrón Service Factory - CU Validar mediante lector biométrico y código de barras
en jornada de inscripción ...................................................................................................... 126
Lista de Figuras
Figura 1. Modelo de la Ciencia basada en el diseño. Fuente: [38]. .......................................... 7
Figura 2. Vista introductoria (previa) ..................................................................................... 14
Figura 3. Vista de la organización (previa) ............................................................................. 18
Figura 4. Vista de co-operación de actores (previa) ............................................................... 19
Figura 5. Vista de proceso de negocio (previa) ...................................................................... 20
Figura 6. Vista de co-operacion del proceso de negocio (previa) ........................................... 25
Figura 7. Vista de comportamiento de la aplicación (previa) ................................................. 28
Figura 8. Vista de Infraestructura (previa) .............................................................................. 30
Figura 9. Estado actual de la registraduría municipal de Choachí con respecto al voto (previa)
................................................................................................................................................ 32
Figura 10. Estado deseado del voto electrónico en el municipio de Choachí (previa) ........... 34
Figura 11. Diseño de alto nivel: Patrón arquitectónico general N-Tier para el voto electrónico
................................................................................................................................................ 38
Figura 12. Tabla de comparación atributos de calidad vs patrones de diseño. Autor: Khosravi
y Guéhéneuc. Modificada por: Anónimo. ............................................................................... 40
Figura 13. Mapeo de aplicaciones a patrones GOF y a patrones de Web Services ................ 44
Figura 14. Diseño detallado (nivel 1): Patrón N-Tier más Patrones Web Services ................ 45
Figura 15. Diseño detallado (nivel 2) del voto electrónico ..................................................... 47
Figura 16. Modelo lógico del proceso de inscripción de candidatos y electores .................... 49
Figura 17. Modelo lógico del proceso de votación ................................................................. 50
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página xii
Figura 18. Modelo BPMN del subproceso de Inscripción de candidatos y electores ............. 51
Figura 19. Inscripción del candidato ....................................................................................... 52
Figura 20. Modelo de Aceptación de la Tecnología. Fuente: Davis [69] ............................... 58
Figura 21. Vista introductoria parte A. ................................................................................... 70
Figura 22. Vista introductoria parte B .................................................................................... 71
Figura 23. Vista introductoria parte C .................................................................................... 72
Figura 24. Vista de la organización ........................................................................................ 73
Figura 25. Vista de co-operación de actor .............................................................................. 74
Figura 26. Vista del proceso de negocio parte A .................................................................... 75
Figura 27. Vista del proceso de negocio parte B .................................................................... 76
Figura 28. Vista del proceso de negocio parte C .................................................................... 77
Figura 29. Vista de co-operación del proceso de negocio parte A .......................................... 78
Figura 30. Vista de co-operación del proceso de negocio parte B .......................................... 79
Figura 31. Vista de co-operación del proceso de negocio parte C .......................................... 80
Figura 32. Vista de co-operación del proceso de negocio parte D .......................................... 81
Figura 33. Vista del comportamiento de la aplicación parte A ............................................... 82
Figura 34. Vista del comportamiento de la aplicación parte B ............................................... 83
Figura 35. Vista del comportamiento de la aplicación parte C ............................................... 84
Figura 36. Vista del comportamiento de la aplicación parte D ............................................... 85
Figura 37. Vista de infraestructura .......................................................................................... 86
Figura 38. Estado actual de la registraduría municipal de Choachí para el voto .................... 87
Figura 39. Estado ideal de la registraduría municipal de Choachí para el voto electrónico ... 88
Figura 40. Modelo BPMN del proceso electoral .................................................................... 98
Figura 41. Modelo BPMN del subproceso de inscripción ...................................................... 99
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página xiii
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Figura 42. Modelo BPMN del subproceso de inscripción de candidatos ............................. 100
Figura 43. Modelo BPMN del subproceso de inscripción de electores ................................ 101
Figura 44. Modelo BPMN del subproceso de votación ........................................................ 102
Figura 45. Modelo BPMN del subproceso de votación para alcaldía ................................... 103
Figura 46. Modelo BPMN del subproceso de votación para concejo ................................... 104
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página xiv
ABSTRACT
This document describes the process that took place during the project in order to build a
viable electronic voting system architecture to implement in the municipality of Choachí,
understanding the needs of the project environment defined by the Registraduría and the
population, and linking them to the construction of the proposal from the business as the
software field.
RESUMEN
El presente documento describe todo el proceso que se llevó a cabo durante el desarrollo del
proyecto para lograr construir una arquitectura de sistema viable para implementar en el
municipio de Choachí el voto electrónico, entendiendo las necesidades del entorno del pro-
yecto definidos por la registraduría y la población, y ligándolas a la construcción de la pro-
puesta desde el ámbito empresarial como el ámbito software.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página xv
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
RESUMEN EJECUTIVO
El presente documento describe la totalidad del proceso que se llevó a cabo durante el desa-
rrollo del proyecto para lograr construir una arquitectura de sistema viable para implementar
en el municipio de Choachí el voto electrónico.
Factores como el hecho de que Colombia no tuviera implementado nada con respecto al voto
electrónico a pesar de la connotación que esta ha tenido en el mundo, la ausencia electoral
reconocida por la población como diferencias al actual sistema de votación, necesidad de
complementar las leyes que se han creado para reducir el fraude y la corrupción electoral, la
consideración de ampliar el marco electoral para los discapacitados sin restringirlos a su re-
conocimiento con un tiempo demasiado lejano de la fecha electoral y reducir o abolir los
problemas judiciales post-electorales por incertidumbre en la calidad de los escrutinios son
elementos que hicieron dar cabida a plantear este proyecto
De ahí, que la problemática que se planteara se contemplara en 2 partes: por un lado se debía
analizar la capacidad del municipio de Choachí para implementar un sistema de voto electró-
nico basado en la legislación actual colombiana así como en los parámetros de la Registradu-
ría Nacional del Estado Civil; y por el otro lado, se debía reconocer cual sería la arquitectura
de mayor viabilidad a nivel de seguridad, auditabilidad y usabilidad para desarrollarla en el
municipio.
Entendiendo las necesidades del entorno del proyecto, definidos por la registraduría y la po-
blación, y luego analizando distintos elementos teóricos del voto electrónico (así como los
desarrollos actuales – arquitecturas - que se han planteado para el mismo en los países donde
se ha implementado) como metodologías para la construcción de arquitecturas tanto empresa-
riales como de software, se constituyó el modelo de arquitectura de sistema para el voto elec-
trónico que se expone a lo largo de este documento.
El uso de la metodología de la ciencia basada en el diseño, que sirvió de método para el desa-
rrollo de este proyecto, nos indujo como parte esencial del proceso que se debía realizar vali-
daciones de cualquier proceso que se desarrollara, así como de cualquier resultado que se
obtuviera. Este paso permitió no solo garantizar sino aumentar la relevancia y rigor de la
propuesta gracias a las validaciones que se implementaron tanto en la arquitectura empresa-
rial como en la arquitectura de software.
Aspectos como la amplia colaboración del personero municipal y del registrador municipal
de Choachí hicieron factible interactuar y hacer profundidad en la captura de información
necesaria para la constitución de este modelo, así como la colaboración de algunos ciudada-
nos para la posterior validación del modelo de arquitectura, permitiendo reflejar que los pro-
yectos desarrollados en la academia pueden tener un impacto positivo en la población desde
que se tenga en cuenta sus necesidades y no se impongan soluciones por mas validez teórica
que tengan, ya que esa validez no da soporte a que la población acepte esas propuestas bajo
presión y/o por obligación.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página xvi
Cabe resaltar que los resultados (documentos) obtenidos durante el transcurso del proyecto
tuvieron varias iteraciones o revisiones, destacando que fue un proceso auto evaluativo, a
pesar que la cantidad de iteraciones del proyecto como conjunto fue una sola debido a la
complejidad de realizar mas sobre el modelo, ya que se salía del alcance planteado dentro del
mismo.
Como resultado final de este proyecto, se obtuvo un modelo de arquitectura de sistema, do-
cumentos de validación de la arquitectura de sistema (desglosado en validación de la arqui-
tectura empresarial así como de la arquitectura de software) y un prototipo de interfaces fun-
cional del proceso de inscripción de candidatos y electores así como del proceso de votación.
Las conclusiones obtenidas de este proyecto permiten destacar que el modelo de arquitectura
de sistema realizado es una solución que integra no solo la forma de implementar el voto sino
su relación con el entorno organizacional que lo controla, demostrando que esta solución es
nueva desde cualquier perspectiva de ingeniería, así como para Colombia, eliminando la con-
cepción de que hay que construir siempre dispositivos Hardware para soportar el voto elec-
trónico. A la vez, esta arquitectura de sistema permite ser una guía de los procesos y de la
forma de dar soporte, a nivel tecnológico y organizacional, al dinamismo propio de la regis-
traduría municipal de Choachí y nacional (en caso de implementarse).
Conjuntamente, el modelo de arquitectura de sistema desarrollado permitiría reducir el im-
pacto ambiental que producen las elecciones, al ahorrar en el consumo de papel para los tarje-
tones electorales y reducir la cantidad de tinta utilizada en los mismos, también como en la
reducción de los costos de transporte, fomentando un efecto positivo sobre el medio ambiente
Interpretando la arquitectura de sistema por partes permite concluir: primero, desde el punto
de vista de la arquitectura empresarial que la creación de ésta, permitirá a la registraduría
municipal de Choachí ser eficiente con el paso del tiempo, ya que en la actualidad no se había
realizado ningún tipo de metodología para reconocer los procesos, actores y elementos que
hacen parte de la línea estratégica de votación. Además, facilitará generar puntos de medición
o indicadores sobre actividades, tareas o procesos para permitir llevar un control de la organi-
zación y su evolución mediante análisis cuantitativos, análisis de brechas entre otras formas
de medición.
Segundo, desde la arquitectura de software, ésta se diseño mediante un esquema basado en
patrones para dar fortaleza conceptual y practica a la solución ya que trabaja sobre unas es-
tructuras que se plantearon para dar solución a problemas precisos, permitiendo analizar y
detectar problemas en otros ámbitos que no cubren los patrones desde su diseño y mejorando
la trazabilidad del proyecto.
Adjunto a esta disposición, se concluye también que la decisión de implementar servicios
web para la constitución de las aplicaciones es una ventaja para cualquier proceso electoral,
ya que facilita que los puestos de votación sean desplazables y accesibles desde cualquier
lugar donde se tenga conexión a internet gracias a la ligereza que ofrecen los servicios web en
la construcción de cualquier aplicación. Asimismo, los servicios web son un impulso para la
registraduría, en caso de implementar este modelo, para permitir la implementación de una
arquitectura orientada a servicios que permita maximizar la eficiencia y eficacia de las otras
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página xvii
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
líneas estratégicas de la registraduría que no fueron analizadas en el presente proyecto (ya
que no eran afines).
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 1
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
INTRODUCCIÓN
La evolución en la forma de votar de ciertos países del mundo ha cambiado hacia el desarro-
llo de soluciones para mejorar los procesos electorales con ayuda de la ingeniería de sistemas
y la ingeniería electrónica, de allí que aparezca el concepto de voto electrónico (en inglés e-
voting o e-vote [1][2][3]) como los mecanismos diseñados para emitir y contar los sufragios
en un único acto, a través de algún sistema informático, instalado y en funcionamiento en el
lugar mismo donde el elector concurre a expresar su voluntad política [4].
Desde 1960 se han creado herramientas para el voto electrónico como el sistema de votación
automatizado mediante tarjetas perforadas, el sistema de escaneo de papeletas de votación
[5], el sistema de votación de Registro o Grabación Electrónica Directa [6] y el sistema de
votación por internet [7]. La generación de estas formas de votación electrónica no representó
solo soluciones sino también conflictos. Países como Holanda, Luxemburgo e Irlanda sufrie-
ron problemas con estos sistemas y desistieron de seguirlos usando por los altos costos que
les represento construir en la mayoría de ellos las urnas electrónicas, en otros casos la descon-
fianza de la gente al uso sin capacitación de estas herramientas ya que el factor de transparen-
cia siempre fue puesto en duda, y en Luxemburgo los problemas que se dieron fueron el he-
cho de que no se ofrecía calidad en la seguridad de la información de los votantes ni claridad
en el manejo de este sistema para la comunidad electoral.
Colombia planteó la implementación del voto electrónico a través del plan de Gobierno en
Línea [8] pero a la fecha no ha mostrado avance alguno en eso. Los múltiples problemas de
administración de políticas estatales, los vacíos en la legislación colombiana con respecto a la
informática, los problemas de la Registraduría y la omisión de las desigualdades entre los
distintos municipios que conforman al país han sido limitantes para que este sistema se intro-
duzca, implemente y ponga en marcha. A pesar de estos sucesos, han ocurrido pilotos de
votación electrónica en Colombia [9][10].
Las metodologías de desarrollo y los modelos de arquitecturas de software de votación elec-
trónica publicados no han considerado explícitamente la agilidad de uso ni la agilidad del
proceso pre-electoral debido a que no le han dado suficiente importancia a técnicas efectivas
en el manejo de seguridad y usabilidad [11] en la etapa pre-electoral, ni a técnicas en agilidad
para la captura de los votos y la interacción de los usuarios con estos sistemas como ocurrió
en los Estados Unidos con el caso de Diebold, donde esta empresa generó unas máquinas
para el voto electrónico fraudulentas sin los respectivos procedimientos de prueba antes de su
salida a venta del producto, lo que le genero diversas demandas por ejemplo del estado de
California hacia la empresa Diebold Inc. [12][13][14].
Por eso es importante entender que implementar una arquitectura de software es insuficiente
para satisfacer las necesidades del voto electrónico, ya que la arquitectura de software es solo
el conjunto de estructuras necesarias para razonar sobre el sistema, que comprende elementos
de software, las relaciones entre ellos y las propiedades de ambos [15]. Es decir que represen-
ta una solución que no mide el impacto que pueda tener en la comunidad con la que debe
interactuar ni en las entidades encargadas de este servicio, ya que deben restructurarse para
darle la debida importancia al proceso. De allí que sea fundamental construir una arquitectura
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 2
de sistema1
, la cual es la integración de la arquitectura empresarial (descripción de la estruc-
tura de la empresa, la composición de los componentes empresariales y sus relaciones con el
ambiente externo, y los principios guías para los requerimientos –análisis-, diseño y evolu-
ción de una empresa [16]) y la arquitectura de software, ya que mediante ésta se espera cons-
truir el soporte del servicio ofrecido reconociendo procesos, roles, apoyo organizacional,
implicaciones de la legislación, de la seguridad y de la calidad en general, y no solo el hecho
de construir un software para los votos sin el respectivo análisis de su impacto. Para el caso,
arquitectura empresarial se refiere a la Registraduría municipal de Choachí y el proceso de
negocio a la votación electrónica.
1
Es una respuesta a las dificultades conceptuales y prácticas de la descripción y el diseño de sistemas complejos.
La Arquitectura de Sistemas ayuda a describir de manera coherente y eficiente el diseño de sistemas complejos,
tales como: a) un sistema industrial, b) una infraestructura de TI, (Arquitectura empresarial/ software), c) una
organización (la Arquitectura Organizacional), d) un negocio (Arquitectura de negocio), e) un proyecto (Proyecto
de Arquitectura) [39]
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 3
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
I - OBJETIVOS
El problema de estudio que se planteó en este proyecto era analizar la capacidad del munici-
pio de Choachí para implementar un sistema de voto electrónico basado en la legislación
actual colombiana así como en los parámetros de la registraduría nacional del estado civil.
Este problema se describió con los siguientes objetivos:
1. Objetivos
1.1 Objetivo General
Diseñar una arquitectura de sistema que pueda ser adoptada como modelo para la implemen-
tación del voto electrónico en el municipio de Choachí (Cundinamarca).
1.2 Objetivos Específicos
• Identificar el concepto y el estado del arte del Voto electrónico (e-vote o e-
voting), relacionando los conceptos de diferentes autores e investigadores del te-
ma, experiencias y políticas de organismos internacionales con los sistemas ya
implementados en países como Brasil, Estados Unidos, la Unión Europea (o Sui-
za), y Australia, principalmente, analizando el impacto económico y social que se
ha venido presentando donde se ha implementado el voto electrónico.
• Analizar las distintas arquitecturas disponibles del voto electrónico en los países
nombrados o en otros
• Identificar las necesidades tanto de la registraduría municipal como de la pobla-
ción (una muestra selectiva) del municipio de Choachí
• Diseñar un modelo de arquitectura de sistema para la implementación del voto
electrónico que cumpla con las necesidades identificadas del municipio de Choa-
chí
• Desarrollar componentes funcionales (interfaces de usuario y modelos de datos)
como complemento del modelo de arquitectura de sistema de voto electrónico
En consecuencia se debería determinar cuál sería la arquitectura de sistema de voto electróni-
co de mayor viabilidad a nivel de seguridad, agilidad y usabilidad para desarrollarlo en el
municipio [17]. Ésta arquitectura también deberá servir de guía para la implementación del
voto electrónico en municipios del mismo tipo de categoría a nivel nacional.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 4
1.3 Definiciones
Archimate Es un lenguaje que complementa TOGAF, ya que proporciona un con-
junto de conceptos independiente del proveedor, incluyendo una repre-
sentación gráfica, que ayuda a crear un modelo coherente e integrado
"por debajo de la línea de flotación", que puede ser representado en la
forma de puntos de vista de TOGAF.
The Open
Group Archi-
tecture Frame-
work
TOGAF es un marco de trabajo estándar de arquitectura para la indus-
tria que puede ser utilizado libremente por cualquier organización que
desee desarrollar una arquitectura de sistemas de información para su
uso dentro de una organización.
Actor Alguien o algo externo al sistema que interactúa con él.
Vista - Archi-
mate
se define como una parte de una descripción de la arquitectura que se
ocupa de un conjunto de preocupaciones relacionadas y se dirige a un
conjunto de actores
Punto de Vista
- Archimate
Establece los conceptos, modelos, técnicas de análisis, y visualizacio-
nes que son proporcionados por la vista.
Capa – Archi-
mate
Clasificación que se da en el lenguaje Archimate para agrupar servi-
cios según su funcionalidad especificando 3 partes del diseño: capa de
negocio, capa de aplicación, capa de tecnología.
Tabla 1. Definiciones
1.4 Acrónimos
TOGAF The Open Group Architecture Framework
ADM Architecture Development Method
UML Unified Modeling Language
BPM Business Process Management
Tabla 2. Acrónimos
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 5
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
II – MARCO TEÓRICO
La evolución se presenta en varios aspectos, de allí que se presenten desarrollos de soluciones
para mejorar los procesos electorales con ayuda de la ingeniería de sistemas y la ingeniería
electrónica. Estos desarrollos hacen que aparezca el concepto de voto electrónico (en inglés
e-voting o e-vote) [18][19][20][21][22].
La definición más clásica de voto electrónico la podemos ver por ejemplo en la enciclopedia
británica, la cual dice que el voto electrónico “es una forma de votación mediada por compu-
tadora en la cual los votantes hacen sus selecciones con la ayuda de un computadora” [23].
Entidades como la Red de Conocimientos electorales ACE define el e-voting como la "vota-
ción electrónica" y hace alusión a la opción de utilizar medios electrónicos para votar en los
referendos y las elecciones” [24]. El argentino Busaniche define el voto electrónico como
“los mecanismos diseñados para emitir y contar los sufragios en un único acto, a través de
algún sistema informático, instalado y en funcionamiento en el lugar mismo donde el elector
concurre a expresar su voluntad política” [25].
Según el observatorio electoral latinoamericano, define el voto electrónico como “la referen-
cia a todos los actos electorales factibles de ser llevados a cabo apelando a la tecnología de
la información. Estos incluyen el registro de los ciudadanos, la confección de mapas de los
distritos electorales, la gerencia, administración y logística electoral, el ejercicio del voto en
sí mismo, culminando con los escrutinios, la trasmisión de resultados y su certificación ofi-
cial” [26]. Este concepto será el que usaremos de guía para el desarrollo del modelo de arqui-
tectura del sistema para la implementación el voto electrónico en el municipio de Choachí.
Ahora, teniendo claro el concepto de voto electrónico debemos tener en cuenta que el desa-
rrollo de este proyecto en cualquier lugar del mundo tiene que ser tan libre, secreto, fiable y
seguro como los sistemas de votación que no implican el uso de medios electrónicos.
El progreso del voto electrónico se ha visto desarrollado desde 1960 donde aparece por pri-
mera vez el sistema de votación automatizado con tarjetas perforadas [27] y del cual han
seguido apareciendo variedad de herramientas o sistemas con el pasar de los años y las mejo-
ras de tecnología: tarjeta perforada votomatic [27], tarjeta perforada datavote [27], sistemas
de escaneo de papeletas de votación [27][28], sistemas de votación de registro o grabación
electrónica directa (DRE) [27][29], sistema de votación por internet [27][30], votación SMS
[31][32], sistema de votación mediante tecnología de respuesta interactiva de voz (IVR)
[32][33][34], y sistemas DRE con comprobante de auditoria de papel verificado por el votan-
te (VVPAT) [35][36][37].
En la era de las tecnologías de la información, Colombia ha progresado paulatinamente desa-
rrollando políticas nacionales y algunas modificaciones a ciertas leyes. A pesar de eso, Co-
lombia no ha tenido en ningún momento ningún sistema de votación electrónica, lo único que
el país tiene es la publicación de los resultados vía internet, proceso posterior al conteo que se
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 6
hace por cada mesa. Esta publicación de los resultados se hace pasando las planillas con los
resultados a mano que entrega cada presidente de mesa al encargado del puesto de votación.
Si bien es cierto que con su aparición el voto electrónico presento problemas de auditabilidad,
seguridad y usabilidad, es cierto también que los desarrollos que se han presentado con el
tiempo han tratado de solucionar estos problemas. Grandes soluciones se han generado, pero
el factor delimitante que no permite verlos en ejecución en la vida real la mayoría de veces
son los altos costos de su implementación.
Ahora, algo muy radical con respecto al voto electrónico seria delimitar el progreso de alguna
de estas herramientas; es decir, cerrar la apertura intelectual generando una ley que obligue a
desarrollar solo un tipo de sistema para el voto electrónico. Esta decisión generaría unos pros
y unos contras, a nivel de pros el más impactante se daría en que el mundo científico estaría
enfocado a solucionar una sola serie de problemas propios del sistema que se haya definido,
pero en los contras el más relevante sería que se generarían monopolios de construcción de
estos sistemas. Además, los costos estarían ligados solo a ese sistema lo que limitaría la capa-
cidad de países en desarrollo a adquirir estos sistemas. Es por eso que mantener una apertura
en la votación electrónica aunque tarde un poco en la corrección de los respectivos problemas
permite a todo el mundo motivarse a pasar a estos sistemas, manteniendo claro que la demo-
cracia es de todos y no de unos pocos.
III - MÉTODO
El diseño del modelo de arquitectura de sistema para la implementación del voto electrónico
en el municipio de Choachí se dividirá en 3 fases principales consecutivas:
• Análisis del entorno.
• Análisis de la base del conocimiento.
• Construcción y evaluación de la arquitectura de sistema.
Estas fases se articulan entre sí y con los objetivos específicos nombrados anteriormente, todo
fundamentado en la ciencia basada en el diseño [38], donde el objetivo de la ciencia basada
en el diseño es la solución de problemas del mundo real utilizando conocimiento disciplinar y
que esta solución hecha mediante la construcción y evaluación iterativa sea útil, haciendo
aclaración en que el origen del problema no es disciplinar.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 7
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Figura 1. Modelo de la Ciencia basada en el diseño. Fuente: [38].
En la fase del entorno se define el problema del espacio donde se encuentra el fenómeno de
interés. Para este trabajo de grado, el entorno se compone de la gente, organizaciones (de
negocio) y sus tecnologías existentes o planeadas en el municipio de Choachí. En el problema
de interés se encuentran las metas, tareas, problemas y oportunidades que definen las necesi-
dades del negocio como son percibidas por la gente dentro de la organización. Tales percep-
ciones están moldeadas por las funciones, capacidades y características de las personas dentro
de la organización.
Además se busca que las necesidades del negocio sean juzgadas y evaluadas dentro del con-
texto de las estrategias organizacionales, estructura, cultura y procesos existentes del negocio.
Ellas son ubicadas con relación a la infraestructura tecnológica existente, aplicaciones, arqui-
tecturas de comunicación y capacidades de desarrollo. Todas estas necesidades definen la
necesidad del negocio o el “problema” como lo percibe el investigador.
Para el desarrollo de esta fase se realizaron las siguientes actividades:
A. Definición del problema con relación al entorno.
B. Definición de las funciones, capacidades, y características de las personas que inter-
actúan con el entorno.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 8
C. Definición de la organización donde se va a resolver el “problema”, reconociendo las
estrategias que tiene, la estructura y contexto cultural, y los procesos que lleva a ca-
bo.
D. Definición, reconocimiento y descripción de la tecnología disponible a nivel de infra-
estructura, aplicaciones, arquitecturas de comunicación y capacidades de desarrollo.
E. Captura de los requerimientos funcionales y no funcionales de los stakeholders me-
diante entrevistas.
F. Definición y validación de los requerimientos (por ejemplo, utilizando técnicas de re-
colección de requerimientos y herramientas como UML).
La fase del análisis de la base del conocimiento provee la materia prima mediante la cual se
lleva a cabo la investigación. La base del conocimiento está compuesta de fundamentos y
metodologías. Lo más importante de la investigación y los resultados de las disciplinas de
referencia es que provee teorías fundamentales, marcos, instrumentos, conceptos, modelos,
métodos e instanciaciones que serán usados en la etapa de desarrollo/construcción de la in-
vestigación.
Para el desarrollo de esta fase se realizaron las siguientes actividades:
A. Desarrollo del documento de requerimientos del modelo de arquitectura del sis-
tema.
B. Definición y clasificación de los fundamentos del voto electrónico y de las arqui-
tecturas (tanto empresariales como de software) en: teorías, conceptos, metodo-
logías, métodos, instanciaciones.
C. Definición del proceso metodológico para la votación electrónica: modelos ac-
tuales de votación electrónica, formalismos, métricas y criterios de validación de
los modelos publicados sobre votación electrónica (si existen, de lo contrario
ajustarlo con base a la validación que se aplica al gobierno electrónico).
D. Definición del proceso metodológico para arquitectura: modelos para la descrip-
ción de arquitecturas (TOGAF, ZACKMAN, estilos arquitectónicos, patrones ar-
quitectónicos y/o de diseño), modelos para escenarios de arquitectura (por ejem-
plo FAAM), formalismos, métricas y criterios de validación de las arquitecturas
(por ejemplo SACAM, modelo de madurez para arquitecturas empresariales, eva-
luación con expertos, Feature comparison), métodos para la prueba de arquitectu-
ras (por ejemplo Technology Acceptance Model (TAM)).
E. Definición del proceso metodológico para el desarrollo de prototipos (por ejem-
plo, OPM, metodología de creación de prototipos).
F. Desarrollo del documento del estado del arte del voto electrónico.
La fase de construcción y evaluación del modelo de arquitectura de sistema se desarrolla
basado en las metodologías seleccionadas en la etapa anterior que proporcionan los criterios a
usar en la fase de justificación/evaluación. El rigor de esta fase se logra mediante la aplica-
ción adecuada de los fundamentos y metodologías existentes.
Para el desarrollo de esta fase se realizaron las siguientes actividades:
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 9
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
A. Diseño y descripción de la arquitectura empresarial.
B. Evaluación de la arquitectura empresarial (comparación con modelos propuestos
identificados en la base del conocimiento a nivel empresarial o mediante la evalua-
ción de un experto) (iterativo con el punto A.).
C. Diseño y descripción de la arquitectura de software.
D. Evaluación de la arquitectura de software mediante triangulación (comparación con
modelos de arquitectura de software propuestos identificados en la base del conoci-
miento, y evaluación del usuario sobre aceptabilidad del modelo) (iterativo con el
punto C.).
E. Desarrollo del documento de integración de arquitectura del sistema de voto electró-
nico (arquitectura empresarial y arquitectura de software).
F. Desarrollo de los prototipos de la arquitectura de software que instancian una prueba
de concepto de la arquitectura de sistema diseñada (interfaces y modelo de datos).
En la ciencia del diseño, los métodos computacionales y matemáticos son usados principal-
mente para evaluar la calidad y efectividad de los artefactos, sin embargo, las técnicas empí-
ricas también pueden ser empleadas.
.
IV – MODELO DE ARQUITECTURA DE SISTEMA
La propuesta desarrollada en este proyecto conocida como Arquitectura de Sistema, busca
ofrecer un esquema completo de voto electrónico para el municipio de Choachí mediante la
integración de los modelos de arquitectura empresarial y arquitectura de software para au-
mentar la fortaleza de la solución.
1. Modelo de Arquitectura Empresarial
La Registraduría municipal de Choachí así como la Registraduría Nacional del Estado Civil
no tienen un esquema del proceso de votación en ninguna forma Empresarial, así como tam-
poco una base para desarrollar una herramienta software. Por esta razón, se desarrolló de
manera clara el modelo que más representa la arquitectura empresarial ideal que integre un
software para agilizar los procesos, empleando un lenguaje sencillo y directo, así como gráfi-
cos y puntos de vista de acuerdo a la metodología utilizada.
La arquitectura se basará en el modelo ‘TOGAF ADM’ que representa Archimate [40], el
cual contendrá las capas de negocio, aplicación y tecnología, y los puntos de vista más repre-
sentativos a nivel de diseño.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 10
1.1 Selección de Vistas
Hay que aclarar que lo que Archimate maneja como puntos de vista2
se ajustara para la com-
presión de los lectores como vistas según la definición de la IEEE: “Una representación de
todo un sistema desde la perspectiva de un conjunto relacionado de las preocupaciones”
[41].
Las vistas que se trabajaron y se presentan en este documento son los más significativos con
base a problemática del proyecto y que son de mayor prioridad para la perspectiva de la inge-
niería de sistemas.
Capa Vista (viewpoint según Archimate)
Negocio – Aplicación – Tecnología Introductorio (introductory)
Negocio Organización (organization)
Negocio Co-operación de actores (actor co-operation)
Negocio – Aplicación Proceso de negocio (Business Process)
Negocio – Aplicación Co-operación del Proceso de negocio (Business Pro-
cess co-operation)
Aplicación Comportamiento de la aplicación (Application beha-
vior)
Tecnología Infraestructura (Infrastructure)
Tabla 3. Capas y vistas
1.2 Actores
Actor Descripción Puntos de vista
El candidato es quien interactúa con
el proceso inscripción candidato
para registrar su candidatura en un
municipio y hacerla oficial ante la
registraduría municipal y nacional.
Cabe aclarar que al registrase el
candidato pasa a ser un elector tam-
Introductorio
Organización
Co-operación de actor
Co-operación de proceso de
negocio
2
Establece los conceptos, modelos, técnicas de análisis, y visualizaciones que son proporcionados por la vista
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 11
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
bién.
El registrador es quien valida las
inscripciones tanto de candidatos
como de electores. Además es quien
realiza el escrutinio para dar el resul-
tado final junto con el juez. También
puede ejercer de jurado en alguna
mesa de votación
Introductorio
Organización
Co-operación de actor
Co-operación de proceso de
negocio
Proceso de negocio
El elector es quien interactúa con el
proceso inscripción elector. Poste-
rior a esto, el elector es el único que
puede realizar una votación en el
sistema.
Introductorio
Organización
Co-operación de actor
Co-operación de proceso de
negocio
El juez solo participa como colabo-
rador del registrador para realizar el
proceso del escrutinio.
Introductorio
Organización
Co-operación de actor
Co-operación de proceso de
negocio
El auxiliar es una persona que puede
ser asignada en determinados mo-
mentos por el registrador para reali-
zar solamente la tarea de inscribir
electores en la etapa de inscripción.
En la etapa del proceso de votación
el auxiliar puede ejercer de jurado,
autorizando el ingreso del elector al
dispositivo de votación.
Introductorio
Organización
Co-operación de actor
Co-operación de proceso de
negocio
El jurado es la persona encargada de
autorizar durante proceso de vota-
ción el ingreso del elector al disposi-
tivo de votación
Introductorio
Co-operación de proceso de
negocio
El personal de back office es el en-
cargado de dar soporte sobre la ad-
ministración del sistema de voto
electrónico. Dentro de esto se consi-
dera que debe haber una persona
para todo el sistema, una para el
control de electores y otra para el
control de candidatos
Organización
Co-operación de actor
Proceso de negocio
Co-operación de proceso de
negocio
Infraestructura
Comportamiento de la apli-
cación
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 12
El desarrollador es el encargado de
implementar el sistema de voto elec-
trónico y las peticiones nuevas que
se le soliciten al sistema por parte
del registrador nacional del estado
civil representado por el registrador
municipal.
Proceso de negocio
Co-operación de proceso de
negocio
Infraestructura
Comportamiento de la apli-
cación
Tabla 4. Actores
Se debe considerar también que un momento dado en el sistema, el elector puede ser Jurado
como puede ser candidato. Las relaciones entre actores se presentan a continuación:
• Un jurado puede ser elector en el proceso de votación
• Un candidato puede ser elector en el proceso de votación
• Un auxiliar puede ejecutar como jurado en el proceso de votación
• Un auxiliar puede ser elector en el proceso de votación
1.3 Stakeholders
Stakeholder Descripción Puntos de vista
Administrador
El administrador es el encargado de
ejercer un monitoreo continuo a los
procesos y de solucionar inconvenien-
tes en tiempos cortos que se presenten
sobre la arquitectura empresarial.
Además de esto, es quien asigna los
tipos de perfiles a los usuarios.
Introductorio
Organización
Co-operación de proceso
de negocio
Comportamiento de la
aplicación
Usuario El usuario es quien se interesa en co-
nocer que mejoras le ofrecerá la arqui-
tectura y con cuales procesos él podrá
interactuar.
Introductorio
Co-operación de proceso
de negocio
Manager El manager es la figura dentro de la
empresa que apoya totalmente el desa-
rrollo de la arquitectura, a la vez que
es el encargado de aprobar tanto las
soluciones como el presupuesto desti-
nado para el proyecto de arquitectura
empresarial
Introductorio
Organización
Co-operación de actor
Proceso de negocio
Co-operación de proceso
de negocio
Comportamiento de la
aplicación
Infraestructura
Desarrollador El desarrollador es la persona encar-
gada de implementar las aplicaciones
necesarias o sugeridas en la arquitec-
Comportamiento de la
aplicación
Infraestructura
Proceso de negocio
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 13
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
tura empresarial Co-operación de Proceso
de negocio
Co-operación de actor
Tabla 5. Stakeholders
Teniendo en cuenta los stakeholders, los actores y a la vez su asociación con las vistas defini-
das, la relación entre ellos queda plasmada de la siguiente forma:
STAKEHOLDERS ACTORES
Administrador Jefe Back Office, Administrador electores, Administrador candidatos
Usuario Elector, Juez, Jurado, Candidato, Registrador, Registrador Munici-
pal, Auxiliar/Secretaria
Manager Registrador, Registrador Municipal
Desarrollador Desarrollador
Tabla 6. Arquitectura empresarial: Stakeholders vs Actores
Cabe destacar que durante la creación de la vistas se tuvo en cuenta no solo la opinión de los
stakeholders, sino también la del director del proyecto y los conceptos estudiados y adquiri-
dos sobre arquitectura empresarial, el lenguaje Archimate así como del lenguaje BPMN por
el autor del proyecto; todo las decisiones fueron soportadas en los atributos de calidad que se
plasmaron en el documento de casos de uso y requerimientos dando prioridad a la auditabili-
dad, seguridad y usabilidad.
1.4 Vista Introductoria (Introductory Viewpoint)
El diagrama de vista introductoria representa la forma general de cómo un cliente opera con
alguno de los servicios ofrecidos por la registraduría y el soporte que tiene de forma global
cada proceso para poderse llevar acabo.
A grandes rasgos en el punto de vista introductorio se puede apreciar los procesos que pueden
ser automatizados y reducir tiempos y falencias.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 14
Figura 2. Vista introductoria (previa)
La figura 2 se puede ver completa en el Anexo A figuras 27, 28 y 29.
En este punto de vista se puede tener una apreciación de alto nivel de toda la línea estratégica
de votación dentro de la registraduría municipal de Choachí.
a. Candidato
Aquí se aprecia que el Candidato interactúa con 3 servicios de negocio ligados a un proceso
llamado Inscripción Candidato: registrar inscripción candidato, modificar inscripción can-
didato, entregar certificación candidatura; y un servicio ligado al proceso Inscripción elec-
tor: entregar certificación inscripción.
Proceso de inscripción de candidato
El servicio de Registro de inscripción de candidato ejecuta el proceso de inscripción de can-
didato partiendo del subproceso de validar candidato, el cual se lleva acabo sobre la aplica-
ción MorphoCheck de la empresa SAGEM, la cual utiliza la validación biométrica y de códi-
go de barras sobre la cedula del candidato gracias a la conexión que tiene con el servidor
MorphoCheck de Bogotá para solicitar esta información. Si la validación es correcta, se pro-
sigue con el subproceso de registrar candidato, el cual usa una aplicación llamada aplicación
registro candidatos en la cual se hace captura de los datos solicitados por la registraduría para
validar la inscripción (esta aplicación funcionara sobre el mainframe ubicado en la registradu-
ría municipal de Choachí). Luego el sistema debe generar un aviso de confirmación que se da
dentro del subproceso de confirmación, para terminar con el subproceso de certificación ins-
cripción candidato, el cual genera a partir de los datos capturados por la aplicación registro
candidatos el certificado de inscripción de candidato que se entregara mediante el servicio
entregar certificación candidatura.
Además de esto, en el momento de confirmar el registro como candidato se habilita de forma
transparente tanto para el candidato como para el registrador el registro del candidato como
elector (registrar elector), el cual también ejecuta una confirmación y posterior certificación
de inscripción como elector (certificación inscripción elector) que se le entregara a la par con
la certificación de candidatura al candidato
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 15
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
El otro servicio con el que interactúa el candidato es el de modificar inscripción candidato, el
cual solo está habilitado durante un lapso de tiempo definido por el registrador y puede modi-
ficar su registro bajo unas políticas de la Registraduría. Si cumple con esto, el registrador
podrá accesar al sistema y modificar el registro del candidato y generar sus nuevos certifica-
dos.
b. Elector
Con respecto al actor Elector, él interactúa con 4 servicios de negocios repartidos en 2 proce-
sos: Los servicios de Registrar inscripción elector y Entregar certificado inscripción perte-
necen al proceso Inscripción elector; mientras que Registrar votación y entregar certificado
votación pertenecen al proceso Votación.
Proceso Inscripción elector
Cuando el elector interactúa con el servicio de Registrar inscripción elector se ejecuta el
proceso Inscripción elector, dentro del cual se inicia el subproceso Validar elector que invoca
a la aplicación MorphoCheck para validar que la identidad del elector que se va a registrar
sea la verdadera. Después de validar la identidad, se activa el subproceso Registrar Elector el
cual accede a la aplicación de registro llamada aplicación registro elector donde se almace-
nan los datos otorgados por el Elector. Esta aplicación funcionaria sobre el mainframe ubica-
do en la Registraduría municipal de Choachí.
Después del registro, el subproceso de confirmación si ha sido satisfactorio el registro mos-
trara un mensaje de confirmación para dar continuación al subproceso de certificación ins-
cripción elector, donde se generara el certificado de inscripción con los datos ingresados por
el elector para entregárselos a través del servicio Entregar certificado votación.
Proceso Votación
A nivel del proceso de votación, el elector interactúa con el servicio de Registrar Votación.
Este servicio inicia dentro del proceso de votación el subproceso de validación elector/mesa,
el cual compara los datos del elector con los almacenados en la Aplicación Registro Electo-
res. Si el registro existe, se da inicio al subproceso de realizar votación donde el elector in-
teractúa con la Aplicación votación conectada al nodo voto-frame en la cual podrá realizar su
votación por alcalde como por concejal. Al terminar la votación, en el subproceso confirma-
ción le saldrá en pantalla un mensaje de confirmación sobre las opciones que acaba de reali-
zar, colocando en decisión del elector, seguir o volver a votar. Cuando decida seguir, el sub-
proceso de certificación jornada electoral recurrirá a la Aplicación votación para generar el
certificado respectivo y entregárselo al elector mediante el servicio Entregar certificado vota-
ción.
Es importante reconocer que el rol de candidato para el proceso de votación no existe, ya que
un candidato por más que realice su registro y sea una figura de elección popular tiene dere-
cho a ejercer su voto, por tanto se considerara un elector más.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 16
c. Registrador
El actor registrador ejerce como veedor y como la persona encargada de ejecutar el sistema
en los procesos de inscripción candidatos, inscripción elector, votación. Además tiene facul-
tades para realizar las inscripciones de candidatos y electores, así como de ejercer de jurado
en el proceso de votación.
Los servicios con los cuales el registrador interactúa con el sistema son: Cerrar inscripción
candidatos del proceso cierre inscripción candidatos; Cerrar inscripción electores del proce-
so cierre inscripción electores; Habilitar jornada electoral del proceso votación.
Proceso cierre inscripción de candidatos
El registrador interactúa con el servicio Cerrar inscripción candidatos el cual da inicio al
proceso de cierre inscripción de candidatos activando el subproceso de validación de usua-
rio, mediante el cual se valida la identidad del Registrador con la base de datos propia del
sistema de votación conocida como Aplicación usuarios sistema la cual está conectada al
Mainframe ubicado en la Registraduría municipal de Choachí.
Después de confirmar la validación del registrador, se da inicio al subproceso de verificación
final candidatos donde se cierra el ingreso de datos a la aplicación registro candidatos y se
genera un reporte con la totalidad de candidatos registrados. Luego de generar este reporte, se
inicia el subproceso Envío de candidatos a la registraduría nacional del estado civil (Bogotá)
donde se envía el reporte vía web al servidor de la Registraduría Nacional del Estado Civil.
Proceso cierre inscripción electores
Además, el registrador interactúa también con el servicio Cerrar inscripción electores el cual
da inicio al proceso de cierre inscripción de electores activando el subproceso de validación
de usuario, mediante el cual se valida la identidad del Registrador con la base de datos propia
del sistema de votación conocida como Aplicación usuarios sistema la cual está conectada al
Mainframe ubicado en la Registraduría municipal de Choachí.
Después de confirmar la validación del registrador, se da inicio al subproceso de verificación
final electores donde se cierra el ingreso de datos a la aplicación registro electores y se gene-
ra un reporte con la totalidad de electores registrados. Luego de generar este reporte, se inicia
el subproceso Envío de electores a la registraduría nacional del estado civil (Bogotá) donde
se envía el reporte vía web al servidor de la Registraduría Nacional del Estado Civil.
Proceso votación
A nivel del proceso de votación, el registrador interactúa con el servicio de Habilitar jornada
electoral. Este servicio inicia y finaliza todo el proceso de votación, ya que es el registrador
quien tiene la potestad de autorizar que funcione el sistema de voto electrónico el día de las
elecciones así como de determinar cuando se finaliza la jornada electoral.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 17
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
d. Registrador y Juez
Proceso escrutinio de resultado
El servicio realizar escrutinio debe ser ejecutado tanto por el Registrador como por el Juez
en paralelo. Este servicio da inicio al proceso escrutinio de resultado, el cual empieza con el
subproceso de validación de usuario, donde se verifica la identidad del Registrador y del
Juez con la base de datos propia del sistema de votación conocida como Aplicación usuarios
sistema, la cual está conectada al Mainframe ubicado en la Registraduría municipal de Choa-
chí. Luego de la validación exitosa, se inicia el subproceso conteo de votos, el cual utiliza los
votos registrados y almacenados que están asociados con la aplicación votación para generar
los resultados mediante unas consultas sencillas.
Al generar los resultados se activa el subproceso Confirmación/Aprobación donde se guarda-
ran estos resultados para ser posteriormente enviados en el subproceso envío de resultados a
la registraduría nacional del estado civil (Bogotá) vía web, y luego imprimirlos como parte
del subproceso publicación de resultados y concluir con el proceso de escrutinio de resulta-
dos.
A nivel de infraestructura se aprecia que tanto el servidor MORPHOCHECK, el nodo Main-
frame, el nodo voto-frame están enlazados mediante conexión a internet o dado el momento
de la implementación mediante la Red de Alta Velocidad del Estado Colombiano (RAVEC).
e. Auxiliar / Secretaria y Jurado
Proceso votación
El auxiliar/secretaria o Jurado interactúan con 2 subprocesos del proceso de votación: prime-
ro con el subproceso de validación elector/mesa y luego con el subproceso de certificación
jornada electoral. Desde el subproceso de validación elector/mesa el auxiliar/secretaria o
jurado es quien verifica que el elector que se acercó al puesto de votación a realizar su voto si
este apto para votar en ese puesto, revisando la identidad del elector (cedula y validación
biométrica) contra la base de electores inscritos del municipio. Posteriormente de eso y al
finalizar el elector de ejercer su derecho al voto, el auxiliar/secretaria o jurado será el encar-
gado de revisar el certificado electoral, imprimirlo y entregarlo.
f. Auxiliar / Secretaria
Proceso inscripción elector
El auxiliar/secretaria esta encargado de supervisar todo el proceso de inscripción de electores,
permaneciendo pendiente de todas las actividades que realiza el sistema. El no interactúa con
ninguno de los servicios de este proceso como agente iniciador sino como guía del desarrollo
del mismo.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 18
1.5 Vista de la Organización (Organization Viewpoint)
Esta vista es una expresión sobre el organigrama que se reconoce en la registraduría munici-
pal de Choachí y el nuevo rol que se agregaría en el mismo como es el del back office. La
importancia de reconocer los roles del organigrama y su interacción permitirá establecer las
políticas necesarias para controlar los procesos y subprocesos a los cuales serán asignados,
además de identificar y establecer acciones coordinadas entre los roles en algún momento y
sobre algún proceso o subproceso.
Figura 3. Vista de la organización (previa)
La figura 3 se puede ver completa en el Anexo A figura 30.
Además, la estructuración de esta vista es significativa, ya que el hecho de automatizar cier-
tos procesos de la línea estratégica de votación, debe incluir tener gente capacitada para dar
solvencia rápida a cualquier situación que se presente, además de resaltar quienes estarían
directamente trabajando con el sistema.
De allí, que se haga este diseño organizacional para establecer:
• Primero, cada rol tenga su asignación de tarea y/o proceso
• Segundo, exista una jerarquía dentro de la organización, que permita reconocer
líderes o jefes de proceso como líderes o jefes de estrategia, permitiendo que no
halla anarquía e irresponsabilidades laborales sobre las tareas, subprocesos o pro-
cesos que estén asignados y permitiendo ejercer labores de control; de esta forma
se permite tener control estricto sobre quienes interactúan en el sistema, en caso
de detectar manipulaciones del sistema para beneficiar agentes externos.
• Tercero, halla coordinación por tareas o metas, permitiendo reconocer que roles
pueden ser reubicados, reasignados o eliminados con base a las metas que debie-
ran realizar sobre cada tarea o subproceso (esta perspectiva se realiza de acuerdo
a los procesos que existan y lo que busque la empresa lograr con ellos. Se puede
asignar o aclarar dentro de la vista de procesos de negocio)
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 19
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
La estructura se ve representada por el registrador nacional quien podría ejercer casi todas las
funciones (excepto las de back office y desarrollador, de allí que estén resaltadas en otro co-
lor, que corresponde a la capa de aplicaciones – otro tipo de personal). Como un subemplea-
do, quien ejercería las veces de Registrador bajo ciertas jurisdicciones está el registrador mu-
nicipal quien sería el jefe y supervisor del sistema y quien debe tener una conversación e
interacción transparente con la gente encargada del back office y desarrollo ya que ellos, de
igual forma deben tener en cada municipio un actor para servir de apoyo.
Aparte de la gente de back office y desarrollo, el registrador tiene relación horizontal con el
juez quien solo podrá intervenir en el sistema dado el momento de realizar el escrutinio de
resultados, para todo lo demás es un agente que no debe intervenir en el sistema.
Debajo del registrador municipal esta auxiliar/secretaria quien podrá ejecutar unas acciones
asignadas por el registrador municipal e informadas a la gente de back office para que autori-
ce el uso del sistema en dichas acciones, pero que en todo momento pueden ser supervisadas
por el registrador municipal.
1.6 Vista de Co-operación de Actores (Actor Co-operation viewpoint)
El valor de esta vista es identificar la interacción entre los actores y los agentes externos a la
organización, complementando la vista de organización (explicado en el punto anterior) para
ver claramente cómo y con quien interactúa cada rol, permitiendo identificar cada rol a im-
plementar para mejorar la seguridad. Además de esto, permite ejercer una auditabilidad clara
y precisa sobre cada rol sin confundir u omitir ninguna de sus actividades.
Figura 4. Vista de co-operación de actores (previa)
La figura 4 se puede ver completa en el Anexo A figura 31.
En esta vista se puede apreciar por una parte que tanto el registrador municipal como auxi-
liar/secretaria pueden relacionarse con el elector mediante la interacción directa con él, defi-
niendo esta interfaz como charla, a través de la cual realizaran la captura de los datos que se
necesiten en los respectivos procesos donde intervenga el elector. A la vez se puede apreciar
que la asignación de un jurado esta ligado la mayoría de veces a que sea el mismo elector y la
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 20
comunicación con los jurados por parte del registrador o el auxiliar/secretaria se da de la
misma forma que con elector: de forma oral.
Además, el registrador es el único que puede interactuar con el candidato para la captura de
los datos necesarios donde este participa mediante 2 tipos de interfaz que son habilitados
como políticas de la registraduría: uno vía charla que es la interacción frente a frente entre
registrador-candidato, y la otra opción es mediante vía teléfono. Hay que hacer la salvedad
que la vía del teléfono es solo bajo condiciones especiales, puesto que el registro del candida-
to de primera vez nunca será permitido por este medio.
Con respecto al personal de back office, la colaboración entre ellos con los demás roles se da
en la siguiente manera:
• Entre el registrador municipal y el actor de back office, la interacción entre ellos
se da mediante el flujo bidireccional de intercambio de formatos de registro elec-
trónico de los electores, así como el de candidatos.
• Entre auxiliar/secretaria y el actor de back office, la interacción se da solamente
con el flujo bidireccional de intercambio de formatos de registro de electores.
• Entre desarrollador y back office se da mediante la entrega de actualizaciones,
mientras que entre back office y desarrollador se da mediante la solicitud de
creación y actualización de reportes así como peticiones para la asignación de
servicios.
Para concluir esta vista, esta la relación del desarrollador con la organización: el desarrollador
se relaciona con el registrador municipal mediante el envío de actualizaciones intermediadas
con el personal de back office, mientras que la relación del registrador municipal hacia el
desarrollador se da mediante el envío de requerimientos para el sistema.
1.7 Vista de Proceso de Negocio (Business Process Viewpoint)
Esta vista refleja al detalle los procesos y subprocesos que se alinearon y que se podrían au-
tomatizar para mejorar la calidad de la votación en Choachí. Además establece que clase de
archivos se deben generar para aumentar la seguridad del proceso y a su vez facilitar audito-
rias posteriores con los registros de cada archivo mediante la verificación de historiales de
acceso, modificación y creación.
Figura 5. Vista de proceso de negocio (previa)
La figura 5 completa la puede ver en el anexo A figuras 32, 33 y 34.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 21
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Los procesos que se llevan a cabo en esta línea estratégica son 6: Inscripción de candidatos,
inscripción de electores, votación, cierre de inscripción candidatos, cierre de inscripción
electores, escrutinio de resultado.
a. Proceso Inscripción candidato
Este proceso se da inicio por un evento que se denota como habilitación inscripción candida-
turas, el cual se programa según las fechas entregadas por la Registraduría Nacional del Esta-
do Civil. Estas fechas son las mismas para cualquier registraduría municipal, por tanto son las
que permitirán que cuando se solicite el servicio si están las fechas activas lo permita hacer,
de lo contrario no.
Al ejecutarse habilitación inscripción candidaturas se activa el subproceso de validar candi-
dato. Este subproceso esta a su vez conformado de 2 subprocesos más: Validar identidad y
validar Aval. Validar identidad es el subproceso encargado de comparar mediante el uso de
lector biométrico y de código de barras la identidad del candidato con la almacenada en el
sistema MORPHOCHECK. Aquí se deberá generar un archivo temporal que permita verificar
los datos ingresados por el sistema para comparar con MORPHOCHECK y que permita su
posterior lectura para generar el registro del candidato evitando redundancia en la recaptura
de datos.
Después de Validar la identidad, se pasa al subproceso de validar aval donde se verifica de
forma manual que lleve el certificado de aceptación de un partido o movimiento político y de
igual forma el pasado judicial actualizado. Si todos los requisitos están completos se concluye
el subproceso validar candidato y se activa el subproceso Registrar candidato.
En el subproceso Registrar candidato se lee el archivo temporal generado por
MORPHOCHECK para crear dos archivos: un nuevo archivo llamado candidato file donde se
guardara el registro del candidato (nombre, apellido, edad, partido político, lugar de residen-
cia, cedula, nacionalidad) -se generaran n archivos candidato file donde n es el número de
candidatos que vayan a registrarse-. El otro nuevo archivo llamado registro candidato tendrá
los datos del candidato almacenados en el archivo candidato file más un numero seriado de
registro, más un atributo que cuente las veces que ha modificado su registro, más el número
que le quedara asignado según el número de candidatos inscritos previamente que pertenez-
can a su partido político integrando de esta manera los datos que trae el formato manual de
inscripción de candidato más unos datos extra para mejorar la seguridad y auditabilidad del
proceso.
Estos archivos pueden ser modificados en caso que el candidato lo solicite bajo las políticas
establecidas por la Registraduría Nacional del Estado Civil.
Luego de crear los archivos, se finaliza el subproceso Registrar Candidato y se inicia el sub-
proceso Confirmación donde para poder confirmar el sistema debe leer el archivo candidato
file y el archivo registro candidato, verificando de esta manera que se efectuó satisfactoria-
mente el registro y mostrando luego en pantalla un mensaje de confirmación. Automática-
mente al mostrar el mensaje de confirmación, deberá copiar los datos del archivo candidato
file que sean iguales a los que solicita el sistema para crear el archivo Elector File, de esta
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 22
manera con el registro de una persona como candidato automáticamente hará el de elector
evitando la redundancia de procesos y validaciones.
Al mostrar este mensaje, se da por finalizado el subproceso de Confirmación y se activa el
último subproceso que es Certificación inscripción candidato. En este subproceso lo que se
hace es leer el archivo candidato file para generar un nuevo archivo llamado certificado can-
didato file, el cual tendrá aparte de los datos de candidato file la fecha, hora, municipio y un
número seriado de certificación.
b. Proceso Inscripción elector
Este proceso se da inicio por el evento habilitación inscripción votantes, el cual se programa
según las fechas entregadas por la Registraduría Nacional del Estado Civil. Estas fechas son
las mismas para cualquier registraduría municipal, por tanto son las que permitirán que cuan-
do se solicite el servicio si están las fechas activas lo permita hacer, de lo contrario no.
Al ejecutarse habilitación inscripción votantes se activa el subproceso de validar elector.
Este subproceso está compuesto del subproceso Validar identidad, el cual se encarga de
comparar mediante el uso de lector biométrico y de código de barras la identidad del candida-
to con la almacenada en la aplicación MORPHOCHECK. Aquí se deberá generar un archivo
temporal (al igual que con el proceso inscripción candidato) que permita verificar los datos
ingresados por el sistema para comparar con MORPHOCHECK y que permita su posterior
lectura para generar el registro del elector evitando redundancia en la recaptura de datos.
En el subproceso Registrar elector se lee el archivo temporal generado por
MORPHOCHECK para crear dos archivos: un nuevo archivo llamado elector file donde se
guardara el registro del elector (nombre, apellido, edad, cedula, nacionalidad, un atributo de
lugar de residencia) -se generaran n archivos candidato file donde n es el número de candida-
tos que vayan a registrarse-. El otro nuevo archivo llamado registro candidato tendrá los
datos del elector almacenados en el archivo elector file más un numero seriado de registro, un
atributo de último lugar donde voto y un atributo de mesa donde quedo inscrito, integrando
de esta manera los datos que trae el formato manual de inscripción de elector más unos datos
extra para mejorar la seguridad y auditabilidad del proceso.
Luego de crear los archivos, se finaliza el subproceso Registrar elector y se inicia el subpro-
ceso Confirmación donde para poder confirmar el sistema debe leer el archivo elector file y el
archivo registro elector, verificando de esta manera que se efectuó satisfactoriamente el re-
gistro y mostrando luego en pantalla un mensaje de confirmación.
Al mostrar este mensaje, se da por finalizado el subproceso de Confirmación y se activa el
último subproceso que es Certificación inscripción elector. En este subproceso lo que se hace
es leer el archivo elector file para generar un nuevo archivo llamado certificado elector file, el
cual tendrá aparte de los datos de elector file la fecha, hora, municipio y un número seriado
de certificación.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 23
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
c. Proceso Cierre inscripción candidatos
El proceso se da inicio gracias al evento Finalización jornada inscripción candidatos, el cual
ocurre como una política de la Registraduría Nacional del Estado civil para limitar el proceso
de inscripciones y que no quede activo siempre. Al ocurrir este evento, se da activa el proceso
cierre inscripción candidatos, el cual comienza por el subproceso validación de usuario. Este
subproceso lo que hace es validar el usuario del sistema (registrador y auxiliar/secretaria)
frente a un archivo de registro previo que tiene el sistema llamado usuario file para garanti-
zar perfiles de acceso aumentando los niveles de seguridad del proceso, evitando que perso-
nas externas a los identificados dentro del punto de vista organización puedan interactuar con
el sistema.
Luego de validar el usuario satisfactoriamente, se inicia el subproceso verificación final can-
didatos. Este subproceso lo que hace es leer el archivo de Registro Candidato y traerlo como
un archivo XML (se usa XML porque es un lenguaje universal, es extensible, porque el anali-
zador es un componente estándar que evita bugs y acelera el desarrollo de aplicaciones, por-
que en caso de cambios a nivel de los desarrolladores este archivo es sencillo de entender en
su estructura y procesarla) junto con algunas consultas con las respectivas políticas de seguri-
dad. Al generar el archivo XML, se da inicio al subproceso envío de candidatos a la registra-
duría nacional del estado civil (Bogotá) en el cual el archivo XML generado es enviado vía
Web al servidor de la Registraduría Nacional del Estado Civil.
d. Proceso Cierre inscripción electores
El proceso se da inicio gracias al evento Finalización jornada inscripción electores, el cual
ocurre como una política de la Registraduría Nacional del Estado civil para limitar el proceso
de inscripciones y que no quede activo siempre. Al ocurrir este evento, se da activa el proceso
cierre inscripción electores, el cual comienza por el subproceso validación de usuario. Este
subproceso lo que hace es validar el usuario del sistema (registrador y auxiliar/secretaria)
frente a un archivo de registro previo que tiene el sistema llamado usuario file para garanti-
zar perfiles de acceso aumentando los niveles de seguridad del proceso, evitando que perso-
nas externas a los identificados dentro del punto de vista organización puedan interactuar con
el sistema.
Luego de validar el usuario satisfactoriamente, se inicia el subproceso verificación final elec-
tores, el cual lo que hace es leer el archivo de Registro elector y traerlo como un archivo
XML junto con algunas consultas con las respectivas políticas de seguridad. Al generar el
archivo XML, se da inicio al subproceso envío de electores a la registraduría nacional del
estado civil (Bogotá) en el cual el archivo XML generado es enviado vía Web al servidor de
la Registraduría Nacional del Estado Civil.
e. Proceso votación
El proceso votación se da inicio por el evento habilitación jornada electoral, el cual está
asignado/programado según el cronograma de la Registraduría Nacional del Estado Civil. La
duración de este evento es de 1 día empezando la recepción de votos a las 7am y finalizándo-
lo a las 4pm del mismo día.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 24
Al activarse este evento se inicia el subproceso Validación elector/mesa, el cual lo que hace
es verificar que la persona que se está presentando al puesto de votación si este registrado en
el archivo elector file. Si se confirma que está registrado y que está en la mesa de votación
pertinente se pasa al siguiente subproceso llamado Realizar votación.
El subproceso Realizar votación consta de 2 acciones: votar por alcaldía y por concejo. La
acción votación alcaldía genera el archivo Votación alcaldía file, el cual almacena la infor-
mación del candidato por alcaldía que selecciono; mientras que la acción votar concejo gene-
ra otro archivo llamado votación concejo file, el cual almacena la información del candidato
por concejo. Paralelo a eso, se crea un archivo llamado Registro votación el cual recopilaría
la información que traen los formularios tarjetón alcaldía y tarjetón concejo para compilarlos
en un solo archivo. Es decir el archivo Registro votación llevaría los datos de votación alcal-
día file y votación concejo file más unos atributos extras como un numero seriado de voto por
mesa de votación, el número de mesa, la hora, la fecha.
Al finalizar la creación de estos 3 archivos, se pasa al subproceso Confirmación donde el
sistema debe intentar leer los archivos previamente generados, si los lee satisfactoriamente
presentara en pantalla un mensaje de aprobación para finalizar este subproceso.
Luego, se inicia el ultimo subproceso llamado Certificación Jornada electoral, el cual gene-
rara un documento que certifique que el elector si ejerció su derecho. La generación de este
documento se da mediante la lectura del archivo elector file para abstraer los datos necesarios
y crear un nuevo archivo llamado certificado votación file, el cual, además de los datos toma-
dos de elector file, tendrá fecha, hora, numero de votante de esa mesa y la mesa de votación
como atributos extra; esto será la fuente para imprimir el certificado de votación.
f. Proceso Escrutinio de resultado
Este último proceso se inicia bajo el evento jornada electoral finalizada, quien se programa a
dar inicio después de que pasa el evento habilitación jornada electoral, es decir después de las
4pm del día de elecciones puede ejecutarse este proceso.
Se comienza con el subproceso de validación de usuario, el cual lo que hace es validar el
usuario del sistema (registrador y juez) frente a un archivo de registro previo que tiene el
sistema llamado usuario file para garantizar perfiles de acceso aumentando los niveles de
seguridad del proceso, evitando que personas externas a los identificados dentro del punto de
vista organización puedan interactuar con el sistema.
Luego de esto, se inicia el subproceso conteo de votos, el cual consta de accesar la base de
datos donde se encuentran los archivos votación concejo file y votación alcaldía file, leerlos y
generar un script para realizar el conteo respectivo por partido político y por candidato. Antes
de finalizar el subproceso se crea el archivo Registro Escrutinio el cual recopila los datos que
trae el formulario E-24 y E-26 (formato e-24 y formato E-26) de manera manual. Al finalizar
ese script se da inicio al subproceso confirmación/aprobación donde los resultados generados
por el script se almacenan por separado en 2 archivos nuevos aparte del archivo Registro
escrutinio: escrutinio concejo file y escrutinio alcaldía file. Luego de generados, saldrá en
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 25
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
pantalla al registrador y juez si están de acuerdo con los resultados generados, de ser así, se
finalizara el subproceso Confirmación/aprobación y se pasara al siguiente subproceso.
Luego de confirmación/aprobación se inicia automática el subproceso envío de resultados a
la registraduría nacional del estado civil (Bogotá) donde se transforman los archivos escruti-
nio concejo file y escrutinio alcaldía file en archivos formato XML con las respectivas nor-
mas de seguridad para ser enviado vía Web a los servidores de la Registraduría Nacional del
Estado Civil en Bogotá. Concluido este envío, se finaliza el subproceso y se iniciara el sub-
proceso de Publicación de resultados en el cual, se mostrara la información resumida del
archivo Registro escrutinio.
1.8 Vista de Co-operación del Proceso de Negocio (Business Process Co-operation Viewpoint)
Esta Vista refleja claramente que actores interactúan con cual servicio, a la vez, como cada
servicio es soportado por los procesos y subprocesos que se reconocieron y cuales se mejora-
ron con aplicaciones software en el diseño para la votación electrónica en Choachí. Esto per-
mite definir los tipos de perfiles a generar y sus alcances dentro del sistema mejorando la
seguridad de voto.
Figura 6. Vista de co-operacion del proceso de negocio (previa)
La figura 6 completa la puede ver en el anexo A figuras 35, 36, 37, 38.
En esta vista los procesos que se llevan a cabo son los mismos que se ilustraron en la vista
anterior: Inscripción de candidatos, inscripción de electores, votación, cierre de inscripción
candidatos, cierre de inscripción electores, escrutinio de resultado.
a. Proceso inscripción candidato
Este proceso es solicitado bajo 3 servicios de negocio con los cuales interactúa solamente el
actor candidato: el servicio de registrar inscripción candidato, el servicio de modificar ins-
cripción candidato y el servicio de entregar certificación candidatura.
Cuando el candidato solicita el servicio de registrar inscripción candidato se corre el proceso
inscripción de candidato desde el comienzo con el subproceso validar candidato.
Si el candidato solicita el servicio de modificar inscripción candidato no es necesario realizar
todo el subproceso de validar candidato ya que solo necesita verificar la identidad y seguir
con el subproceso de Registrar candidato ya que el candidato ya debe estar registrado.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 26
Si el candidato solicita el servicio entregar certificación candidatura solo interactuara con el
ultimo subproceso llamado Certificación inscripción candidato.
El subproceso de validar candidato esta soportado en el servicio de aplicación llamado Servi-
cio MORPHOCHECK. Los subprocesos Registrar candidato y Certificación inscripción
candidato están soportados en el servicio de aplicación Servicio registro candidato.
b. Proceso Inscripción elector
El proceso de inscripción electores recibe los servicios ejecutados por el actor elector. En este
proceso hay 2 servicios de negocio que son ofrecidos al elector: el servicio de registrar ins-
cripción elector y el servicio entregar certificado inscripción.
El servicio Registrar inscripción elector esta soportado por todo el proceso de inscripción
elector iniciando desde el subproceso de validad elector. Mientras que, el servicio entregar
certificado inscripción esta soportado solo en el último subproceso llamado certificación
inscripción elector.
A su vez, el subproceso validar elector tiene el soporte del servicio de aplicación llamado
Servicio MORPHOCHECK, mientras que los subprocesos registrar elector y certificación
inscripción elector tienen el soporte del servicio de aplicación Servicio registro elector.
Se resalta que la función de guía de este proceso lo puede ejecutar tanto el registrador muni-
cipal como el auxiliar/secretaria.
c. Proceso Cierre inscripción candidatos
En este proceso solo interactúa el actor registrador mediante el único servicio de negocio que
se ofrece: cierre inscripción candidatos.
Este servicio esta soportado por todo el proceso, y se empieza desde el subproceso de valida-
ción de usuario.
El subproceso de validación de usuario esta soportado en el servicio de aplicación llamado
servicio usuarios sistema; mientras que el subproceso de verificación final candidatos esta
soportado en el servicio de aplicación Servicio registro candidato.
d. Proceso Cierre inscripción electores
En este proceso solo interactúa el actor registrador mediante el único servicio de negocio que
se ofrece: cierre inscripción electores.
Este servicio esta soportado por todo el proceso, y se empieza desde el subproceso de valida-
ción de usuario.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 27
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
El subproceso de validación de usuario esta soportado en el servicio de aplicación llamado
servicio usuarios sistema; mientras que el subproceso de verificación final electores esta
soportado en el servicio de aplicación Servicio registro elector.
e. Proceso votación
El proceso de votación tiene como actores al registrador y al elector. El registrador interac-
túa con el servicio de habilitar jornada electoral, el cual consiste de permitir al sistema ini-
ciarse y finalizarse según lo pauta la registraduría nacional del estado civil bajo la acción del
registrador. Este servicio se encarga de que el resto de subprocesos pueda inicializarse.
El elector interactúa con 2 servicios que tienen el soporte de este proceso: servicio de Regis-
trar votación y servicio de entregar certificado votación.
El servicio de registrar votación ejecuta la totalidad del proceso votación, iniciando por el
subproceso de validación elector/mesa; mientras que el servicio entregar certificado votación
solo utiliza el ultimo subproceso llamado certificación jornada electoral.
El subproceso de validación elector/mesa esta soportado en el servicio de aplicación llamado
servicio registro elector. Los subprocesos realizar votación y certificación jornada electoral
están soportados por el servicio de aplicación llamado servicio votación.
Los actores encargados de supervisar dentro de la ejecución los subprocesos de validación
elector/mesa y certificación jornada electoral son el auxiliar/secretaria y el jurado.
f. Proceso Escrutinio de resultado
En este proceso interactúa en paralelo tanto el actor registrador como el juez mediante el
único servicio de negocio que se ofrece: Realizar escrutinio.
Este servicio esta soportado por todo el proceso, y se empieza desde el subproceso de valida-
ción de usuario.
El subproceso de validación de usuario esta soportado en el servicio de aplicación llamado
servicio usuarios sistema; el subproceso de conteo de votos esta soportado en el servicio de
aplicación Servicio votación y los subprocesos de confirmación/aprobación, envío de resul-
tados a la registraduría nacional del estado civil (Bogotá) y publicación de resultados están
soportados en el servicio de aplicación llamado Servicio resultados.
1.9 Vista de Comportamiento de la Aplicación (Application Behavior Viewpoint)
Esta vista es el elemento integrador de la arquitectura empresarial con la arquitectura de
software, ya que desde aquí, se puede apreciar dentro del proceso que desarrollo software
serviría para soportar los procesos que posee la empresa o que se han diseñado para mejorar
el rendimiento de la empresa en búsqueda de cumplir con la estrategia de la empresa.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 28
Figura 7. Vista de comportamiento de la aplicación (previa)
La figura 7 completa la puede ver en el anexo A figuras 39, 40, 41 y 42.
En este punto, debido a que se darían las pautas para seguir la construcción de la arquitectura
de software, se escoge que el lenguaje para el intercambio de información a emplear en el
sistema de voto electrónico será el XML. La decisión se toma basada en 2 aspectos: el prime-
ro, que el lenguaje XML no necesita un desarrollo específico de aplicaciones para que los
datos contenidos en los documentos sean comprendidos por la persona que maneja la infor-
mación. Los mismos datos XML pueden ser presentados tanto en un browser WEB como en
una aplicación interna (asumiendo que existe una interfaz de aplicación) sin ninguna manipu-
lación adicional o programa especial; y segundo porque dentro de los márgenes legales que
rigen a las entidades del estado se desarrollo un estándar para la comunicación entre dichos
entes llamado GEL-XML [42]. Esta política se constituyo gracias al proyecto de Gobierno En
Linea (GEL) de la presidencia de la república de Colombia, en el cual se estipula la creación
del estándar GEL-XML para el intercambio de información entre entidades del estado con
determinados parámetros de seguridad.
A partir de este punto, hay que anotar que las aplicaciones que se desarrollen serán tipo Web
Services para permitir desarrollos ligeros y de fácil compenetración con el lenguaje XML
definido previamente.
a. Aplicación MORPHOCHECK
Esta aplicación ya la tiene creada la Registraduría municipal de Choachí y da soporte al ser-
vicio de aplicación Servicio MORPHOCHECK. Fue adquirida por la registraduría nacional
del estado civil para facilitar la verificación de identidades y es utilizado en las distintas regis-
tradurías municipales para garantizar la entrega de documentos a los verdaderos dueños. Hay
que aclarar que ni el candidato ni el elector podrán solicitar interactuar con la aplicación ni
con el servicio MORPHOCHECK a ningún nivel, debido a que esos actores solo interactúan
con los servicios de negocio y no con el resto de procesos o servicios que se dan en las capas
de aplicación y tecnología. Además, MORPHOCHECK (en todas sus formas: en capa de
aplicación y/o de tecnología) es de uso privativo de la registraduría y se utilizara para aumen-
tar la seguridad en el proceso del voto. De esta aplicación solamente se utilizara a los archi-
vos Petición cedula data, huella dactilar data, y el ID persona file que es donde se almacena
toda la información de los ciudadanos.
Su uso será el siguiente: el registrador solicita la cedula del elector/candidato, lee el código
de barras de la cedula con el dispositivo de lectura biométrica y de código de barras, la apli-
cación MORPHOCHECK confirma el número y los datos parciales, el registrador solicita al
elector/candidato colocar su huella digital en el dispositivo y luego la aplicación
MORPHOCHECK confirma que la huella leída es de la persona que está en el documento.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 29
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
b. Aplicación Registro Candidatos
Esta aplicación debe ser creada, y daría soporte al servicio de aplicación Servicio Registro
Candidato. Esta aplicación debe cumplir con 2 funciones: la función de creación registro
candidato y actualización registro candidato. La función de creación registro candidato se
encargara de validar los datos leídos de la persona en ID Persona File, crearle un registro en
el archivo candidato data y almacenarlo en el archivo registro candidato file data.
Por otra parte, la función actualización registro candidato para poder accesar al registro y
modificarlo deberá leer el archivo ID Persona File, para luego modificarlo en el archivo can-
didato data y finalmente almacenar esta modificación en el archivo registro candidato file
data
c. Aplicación Registro electores
Esta aplicación debe ser creada, y dará soporte al servicio de aplicación Servicio Registro
Elector. Esta aplicación debe cumplir con la función de creación registro elector. La función
de creación registro elector se encargara de validar los datos leídos de la persona mediante la
lectura del archivo ID Persona file, crearle un registro en el archivo elector data y almacenar-
lo en el archivo registro elector file data.
d. Aplicación votación
Esta aplicación debe crearse y dará soporte al servicio de aplicación Servicio votación. Esta
aplicación consta de 2 funciones: una llamada validación de identidad que usara el archivo
Registro Elector File Data para garantizar que la persona que se acerca a la mesa de votación
es quien está registrada. La otra función es votación.
A la vez, la función votación está compuesta de 2 sub-funciones más: votación alcaldía y
votación concejo. La sub-función votación alcaldía inicia por seleccionar la opción de vota-
ción por alcaldía en el menú que se despliegue, seguidamente el elector en Escoger candida-
to/Partido por alcaldía seleccionara sobre la lista de candidatos inscritos su favorito, esto se
almacenara en un archivo llamado alcaldía data. Seguidamente la aplicación en confirmación
voto por alcaldía deberá mostrar una pantalla pidiendo al elector confirmar su opción. Al
confirmar la opción, su voto se almacenara (almacenar voto alcaldía) en el archivo Votación
alcaldía file data.
Al finalizar esta opción, se volverá al menú de selección, solo que la opción Votación por
alcaldía saldrá deshabilitada al ya haberse realizado.
La sub-función votación concejo inicia por seleccionar la opción de votación por concejo en
el menú que se despliegue, seguidamente el elector en Escoger candidato/Partido por conce-
jo seleccionara sobre la lista de candidatos inscritos su favorito, esto se almacenara en un
archivo llamado concejo data. Seguidamente la aplicación en confirmación voto por concejo
deberá mostrar una pantalla pidiendo al elector confirmar su opción. Al confirmar la opción,
su voto se almacenara (almacenar voto concejo) en el archivo Votación concejo file data.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 30
La sub-función Votación se finalizara generando el certificado electoral para el elector.
e. Aplicación Resultados Escrutinio
Esta aplicación solo podrá ser accesada después de finalizada la jornada electoral y revisando
que se hallan realizados votos. Esta aplicación también deberá ser creada como la mayoría de
aplicaciones y dará soporte al servicio de aplicación Resultados escrutinio.
La aplicación tiene una función llamada conteo/confirmación votos. Esta aplicación funciona-
ra ejecutando primero un script de consulta sobre la base de datos para contar votos, luego de
estos, los resultados se generaran en un formato similar al formato manual E-24, estos datos
quedaran almacenados en el archivo E-24 data. Luego de generado este formato aparecerá
una pantalla con la vista de cómo quedo generado el formato y saldrá un mensaje solicitando
confirmación del formato generado, si se aprueba se almacenara en un archivo llamado E-24
file data.
Luego de aprobar el formato E-24, se generan los resultados respectivos al antiguo formulario
manual E-26, estos datos quedaran en un archivo llamado E-26 data. Posterior a esto, apare-
cerá una pantalla con la vista de cómo quedo generado el formato y saldrá un mensaje solici-
tando confirmación del formato generado, si se aprueba se almacenara en un archivo llamado
E-26 file data. Finalizado este archivo, se enviaran vía Web el archivo E-24 file data y el E-
26 file data a la registraduría nacional del estado civil con las respectivas políticas de seguri-
dad estimadas por este ente.
1.10 Vista de Infraestructura (Infrastructure Viewpoint)
Esta vista ilustra la infraestructura necesaria para dar cumplimiento a los requisitos identifi-
cados dentro del diseño de procesos de negocio que se generó, para poder llevar acabo (en el
debido momento) la implementación del voto electrónico en el municipio de Choachí.
Figura 8. Vista de Infraestructura (previa)
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 31
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
La figura 8 completa la puede ver en el anexo A figura 43.
A nivel de la registraduría de Choachí se requieren: 2 equipos de cómputo que ya se tienen,
una conexión a Internet o en su defecto a la Red de Alta Velocidad del Estado Colombiano
(RAVEC) y un mainframe donde estará el software para manejo de bases de datos DBMS, un
software para el manejo de mensajes Message Queing y el software de la aplicación Registro
Web Service y Escrutinio
A nivel de zona electoral, se debe tener n equipos de cómputo, donde cada equipo representa-
ra una estación o mesa para votar. Además de esto, un mainframe que se llamará votoframe,
el cual tendrá el software Votación, el software Escrutinio y el software DBMS para almace-
nar los votos. Estos equipos y el votoframe deben estar conectados a internet o en su defecto
a RAVEC para permitir el proceso de escrutinio posterior y generar replicación de la DBMS
al mainframe de la registraduría para aumentar la seguridad de la información.
Los demás elementos son ajenos a la implementación pero se hace una suposición de la com-
posición de estos para una futura simulación.
2. Modelo de Arquitectura de Software
El proceso de diseño de unas aplicaciones para dar vida al voto electrónico en el municipio de
Choachí no puede ser un proceso improvisado y mucho menos empírico. Es por eso, que
como elemento innovador e integrador se vio necesario reconocer previamente la estructura
de la línea estratégica del voto en la Registraduría municipal de Choachí para reconocer cada
uno de los procesos que componen esta línea, su funcionamiento e identificar los puntos débi-
les o de mejora que se podían trabajar dentro de esta línea estrategia.
Este elemento lo trabajamos como la Arquitectura empresarial de la Registraduría municipal
de Choachí (documento anterior), en la cual se identificaron todos los procesos propios del
voto, además de pensarse y posteriormente establecerse en la vista de comportamiento de la
aplicación una serie de aplicaciones necesarias para soportar las mejoras en los procesos co-
mo son: MORPHOCHECK, registro de candidatos, registro de electores, votación, y escruti-
nio de resultados. Cabe resaltar que, de estas aplicaciones se descarta la creación de
MORPHOCHECK ya que es un producto adquirido por la Registraduría Nacional del Estado
Civil, la cual en el momento de implementación de este modelo de Arquitectura de Sistema,
le podría solicitar a la empresa SAGEM (creadora de MORPHOCHECK) diseñar una interfa-
ce para integrar los datos que se requieran de esta aplicación para el resto del modelo de ar-
quitectura de software para el voto electrónico en el municipio de Choachí.
Basado en la vista de comportamiento de la aplicación, se hace un proceso de valoración del
estado actual de la registraduría al estado deseado mediante el proceso de diseño de casos de
uso, para poder apreciar lo que se necesita, como se necesita y quienes interactuarían con la
herramienta a desarrollar.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 32
Figura 9. Estado actual de la registraduría municipal de Choachí con respecto al voto (previa)
Para la figura completa, vea el anexo A figura 44.
En el caso de uso actual, se puede apreciar que todos los procesos que se llevan a cabo en
Choachí son de forma manual, no hay ninguno con soporte tecnológico o automatizado, e
influyen muchos actores.
Basado en el estado actual, se plantea un estado deseado para el voto, donde ya no será el
voto de forma manual sino se busca obtener el voto electrónico para el municipio.
A partir del modelo de caso de uso votación actual se planteó la re-estructuración del modelo
para poder acoplar el voto electrónico de acuerdo a la reglamentación actual de la Registradu-
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 33
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
ría Nacional del Estado Civil. Dentro de los elementos que se modificaron con este modelo
As Is – To Be, donde el As Is representa el estado actual (CU votación actual) y el To Be el
ideal para el voto electrónico (CU E-vote2), se destaca no solo la inclusión de nuevos casos
de uso sino las modificaciones a nivel de actores donde se eliminaron algunos de ellos y se
crearon otros en equilibrio del ideal planteado para el voto electrónico en el municipio de
Choachí. Se tiene en cuenta que para definir los actores finales, quienes están en el CU E-
vote2, se migró de los actores actuales a los necesarios por la arquitectura empresarial, y pos-
teriormente a su relación en la implementación de la arquitectura de software.
ACTORES CASOS DE USO
VOTACION ACTUAL
ACTORES
ARQUITECTURA
EMPRESARIAL
ACTORES CASOS DE
USO E-VOTE2
Registrador Registrador Registrador
Elector Elector Elector
Juez Juez Juez
Candidato Candidato Candidato
Auxiliar Auxiliar Auxiliar
Jurado Jurado Sistema
Alcalde Desarrollador
Testigo Back Office
Tabla 7. Mapeo de Actores CU actual vs Actores Arquitectura Empresarial vs Actores CU E-
Vote2
La función del testigo la puede asumir cualquier elector por lo cual es innecesaria. De
igual forma, la presencia del alcalde para el antiguo traslado del arca triclave tampo-
co será necesaria, por tanto su presencia como actor definido no es necesaria.
Por otra parte, el actor Jurado desaparece físicamente a nivel del diseño de software a
pesar que se mantiene en la arquitectura empresarial, esto se da a que un elector pue-
de ser jurado asignándolo no como un actor sino como un rol que puede desempeñar.
El desarrollador y los cargos de Back office son asignados en el actor sistema y difie-
ren dependiendo del rol.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 34
Figura 10. Estado deseado del voto electrónico en el municipio de Choachí (previa)
Para ver la figura completa ver anexo A figura 45.
Para el estado deseado del voto electrónico, se espera mejorar la seguridad de los procesos
que constituyen esta línea estratégica y otorgarle nuevas formas de auditabilidad a los mismos
en cualquier momento. Además de intentar mejorar el funcionamiento de estos procesos me-
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 35
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
diante la automatización o implementación de herramientas tecnologías para cumplir con el
voto.
2.1 Identificación y Selección de Patrones de Negocio
Con base en la arquitectura empresarial definida anteriormente, se puede establecer según la
metodología BPTrends [43], una relación de los procesos que tiene la Registraduría munici-
pal de Choachí contra el uso los mismos como procesos intensivos definidos como procesos
intensivos en sistemas, procesos intensivos en personas, procesos intensivos en decisión y
procesos.
Procesos intensi-
vos en sistemas
Procesos
intensivos en
personas
Procesos
intensivos en
decisión
Procesos
intensivos en
documentos
Proceso de inscrip-
ción de candidato
x x
Proceso inscripción
de electores
x x
Proceso cierre de
candidatos
x x
Proceso cierre de
electores
x x
Proceso de votación x x
Proceso de escruti-
nio de resultados
x x
Tabla 8. Procesos de la registraduría municipal de Choachí vs Procesos según BPTrends. Autor:
Daniel Cáceres.
Este mapeo entre procesos y procesos intensivos sirve como elemento de identificación pre-
vio para poder establecer que si sea necesario automatizar algunos procesos o reorganizarlos.
Según se aprecia en la tabla 8, se ve que los procesos de la registraduría si pueden ser aptos
para ser automatizados lo que a su vez trae el reorganizar algunos.
Teniendo claro que según el análisis de BPTrends la arquitectura empresarial (específicamen-
te la vista de comportamiento de la aplicación) tiene toda la viabilidad, se debe buscar una
forma de relacionar ese modelo a un diseño de arquitectura de software.
La mejor forma de hacerlo, es mediante la identificación de patrones de negocio (los cuales
darán mayor fortaleza a la arquitectura empresarial) que posteriormente puedan ser mapeados
a patrones de software (tanto de arquitectura como de diseño) ligándola directamente a la
arquitectura empresarial con la arquitectura de software.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 36
Forster plantea en [44] unos patrones de mejora de los procesos de negocio que se clasifican
en 4 tipos: Patrones básicos de control de flujo, Patrones avanzados de ramificación y sincro-
nización, patrones estructurales y patrones de múltiples instancias. Según Forster, describe
estos patrones de mejora de procesos de negocio como un intento para describir soluciones
satisfactorias para modelar los pasos de mejora operacionales de un proceso de negocio.
Basado en este concepto, los procesos de negocio del voto electrónico fueron mapeados a
estos patrones, identificándolos mediante el subproceso perteneciente a cada proceso del mo-
delo de arquitectura empresarial de mayor influencia para el diseño según la definición de
cada patrón de negocio.
Patrones básicos
de control de
flujo
Patrones avanza-
dos de ramifica-
ción y sincroni-
zación
patrones
estructurales
patrones
de múlti-
ples ins-
tancias
Proceso de inscrip-
ción de candidato
Morphocheck
Proceso inscripción
de electores
Morphocheck
Proceso cierre de
candidatos
Omitir validación
usuario (registra-
dor)
Proceso cierre de
electores
Omitir validación
usuario (registra-
dor)
Proceso de votación Morphocheck
Proceso de escruti-
nio de resultados
Omitir publicación
resultados físicos
Tabla 9. Patrones de negocio de Forster vs Procesos de negocio de la Registraduría municipal de
Choachí. Autor: Daniel Cáceres
Según el mapeo, los patrones de negocio que reflejan las necesidades de los procesos defini-
dos en la arquitectura empresarial por mayor cantidad de procesos relacionados son los Pa-
trones básicos de control de flujo y los patrones estructurales.
El problema que trae estos patrones, es que para llevarlos a un nivel más bajo hay que estar
ligado obligatoriamente al Framework de Forster. Dada esta situación, se buscó unos patrones
de negocio más específicos, situación que nos llevó a encontrar en la base del conocimiento
información de Kim et. Al. Según Kim et al. en [45] comentan que los patrones de Forster
pueden ser ajustados a un nivel de detalle más concreto sin emplear su framework. Lo prime-
ro que plantean Kim et al es que se le cambie el término de patrones de mejora de procesos de
negocio por patrones de cambio de procesos de negocio, y luego definen 3 nuevas categorías
con base a los patrones definidos anteriormente por Forster y los patrones asociados a cada
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 37
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
categoría: Patrones de extensión/borrado de actividad, Patrones de fusión/cambio de activi-
dad, y patrones de división/cambio de actividad.
Dentro del documento de Kim et al, no presenta una relación directa con los patrones de
Forster, solo dice que los tomo como base. Para este documento, el autor realiza una relación
de los patrones de Forster con los de Kim et al basándose en los conceptos y términos defini-
dos en sus artículos previamente citados.
PATRONES DE FORSTER PATRONES DE KIM ET AL
Patrones básicos de control de flujo Patrones de extensión/borrado
de actividad
Patrones avanzados de ramificación y
sincronización
Patrones de fusión/cambio de
actividad
patrones estructurales Patrones de fusión/cambio de
actividad
patrones de múltiples instancia patrones de división/cambio de
actividad
Tabla 10. Patrones de negocio de Forster vs Procesos de negocio de la Registraduría municipal
de Choachí. Autor: Daniel Cáceres
El resultado de esta tabla refleja que los procesos de negocio de la Registraduría municipal de
Choachí con respecto a la línea estrategia del voto según el esquema de Kim et al, estarían
reflejados en los patrones de extensión/borrado y fusión/cambio de actividad. Basado en esta
comparación, para ir a un nivel de detalle más específico y no mantener la generalidad que
representaba los patrones de Forster, se presenta la siguiente tabla donde se mapearan los
procesos de negocio de la registraduría versus los patrones de Kim et. Al, identificando el
patrón especifico de negocio de cada clasificación con el respectivo proceso de negocio.
Patrones de exten-
sión/borrado de acti-
vidad
Patrones de fu-
sión/cambio de acti-
vidad
Patrones de
división/cambio
de actividad.
Proceso de
inscripción de
candidato
Patrón de cambio de
contenido de actividad
Proceso ins-
cripción de
electores
Patrón de cambio de
contenido de actividad
Proceso cierre
de candidatos
Patrón de borra-
do/desvió de actividad
Proceso cierre
de electores
Patrón de borra-
do/desvió de actividad
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 38
Proceso de
votación
Patrón de cambio de
contenido de actividad
Proceso de
escrutinio de
resultados
Patrón de borra-
do/desvió de actividad
Tabla 11. Patrones de negocio de Kim et Al. vs Procesos de negocio de la Registraduría munici-
pal de Choachí. Autor: Daniel Cáceres.
Debido a que los patrones de negocio identificados son el Patrón de cambio de contenido de
actividad y el patrón de borrado/desvió de actividad, pertenecientes a dos categorías de clasi-
ficación de patrones diferentes como lo son el "fusión/cambio de actividad” y el “exten-
sión/borrado de actividad”, se buscó dentro de la base del conocimiento la forma de asociar-
los al diseño del software. Vistos estos patrones y debido a la diferencia entre ellos dada su
clasificación, se encontró que la implementación de estos patrones de negocio en software
sólo se puede hacer mediante un patrón arquitectónico definido como el patrón layers [46] o
Layered architecture pattern [47].
Considerando que el patrón layers su objetivo es descomponer en su-btareas la estructura del
software donde cada sub-tarea tiene una función especificada, se utilizará el patrón N-Tier
[48] como la aproximación más clara de este patrón para su implementación en un web servi-
ce.
2.2 Introducción al Patrón de Arquitectura N-Tier
El patrón N-Tier es una generalización de la arquitectura de tres capas. La arquitectura de 3
capas consiste en una capa de presentación, una de negocio y una de bases de datos y la lógi-
ca asociada es ésta, cuando se intenta incorporar en este arquitectura de 3 capas la parte de los
servicios web se presentan problemas de flexibilidad con la arquitectura. Esto hace que se
requiera incorporar una capa adicional de tal suerte que surge la arquitectura N-Ter como se
muestra continuación:
Cliente
Presentación / Web
Lógica de negocio
Persistencia
Figura 11. Diseño de alto nivel: Patrón arquitectónico general N-Tier para el voto electrónico
Ya con un patrón de arquitectura definido para el software, podemos empezar a ir a un nivel
de más detalle.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 39
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
2.3 Identificación y Selección de Patrones de Diseño
Hay muchas formas para poder usar e interpretar los casos de uso (y sus respectivos requeri-
mientos) para llegar a su implementación. Una de las formas que tiene mayor solicitud por la
calidad en que se desarrolla la solución es mediante el mapeo de estos casos de uso a atribu-
tos de calidad. Pero, ¿a qué nos referimos con calidad? Definiciones hay muchas, pero la que
mayor representación tiene en el mundo de la ingeniería de sistemas (en especial la ingeniería
del software) es la definición que da la IEEE en el Standard 729-1983:
“La totalidad de los rasgos y las características de un producto de software que le
confieren la capacidad de satisfacer determinadas necesidades: por ejemplo, cum-
plimiento de las especificaciones.
El grado en que el software posee una combinación deseada de atributos.
El grado en que un cliente o un usuario percibe que el software cumple con sus ex-
pectativas compuesto.
Las características de composición de un software que determinan el grado en que el
software en uso complacerá las expectativas del cliente”.
De estos conceptos de la IEEE, el enfoque se hará sobre la segunda definición, donde se ha-
bla de la combinación deseada de atributos. Basados en este concepto, deducimos que los
atributos de calidad son características que tienen relación directa con el lenguaje de progra-
mación y el entorno para el cual se va a implementar el producto software.
Distintos modelos de los atributos de calidad han sido inventados como el modelo de McCall
[49], el modelo de Boehm [50], el modelo FURPS [51], el estándar ISO/IEC 9126 [52], el
modelo Dromey [53], el modelo de estrella [54], el modelo de redes bayesianas [55] y el mo-
delo “nutshell” de Khosravi y Guéhéneuc [56] que será el modelo que usaremos para nues-
tros atributos de calidad.
Pero reconocer estos atributos de calidad no significa que el desarrollo ya sea de calidad. De
allí, que diversos autores buscaran la forma de crear algún tipo de estándar en el desarrollo
software para mejorar la producción del mismo, y uno de esos autores fue Eric Gamma y su
grupo quienes crearon los “Patrones de diseño” [57].
Posteriormente, diversos autores generaron vínculos entre los atributos de calidad y los patro-
nes de diseño. Para este desarrollo se tomó en cuenta la tabla de comparación de Khosravi y
Guéhéneuc sin los atributos de independencia del software ni independencia del hardware,
donde dependiendo de la calificación de todos los atributos del modelo “Nutshell” se le asig-
naba un patrón de diseño.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 40
Figura 12. Tabla de comparación atributos de calidad vs patrones de diseño. Autor: Khosravi y
Guéhéneuc. Modificada por: Anónimo.
Basado en estos conceptos, se reconocieron los atributos de calidad del software para voto
electrónico a desarrollar y se les asigno una calificación. Para ser más específico, se califica-
ron los atributos de calidad por cada aplicación para poder mirar que tipo de patrón se puede
identificar como esencial por aplicación. La clasificación se hace con los parámetros de Exce-
llent (E), Good (G), Fair (F), Bad (B), y Poor (P) que define Khosravi y Guéhéneuc.
La asignación de calificación por atributo de calidad se hace con base en la información obte-
nida mediante la entrevista con el Registrador municipal, los atributos de calidad del docu-
mento de casos de uso y requerimientos, junto con el conocimiento adquirido mediante la
base del conocimiento en la interpretación de las definiciones de los atributos de calidad que
aglomera Khosravi y Guéhéneuc en su artículo.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 41
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Registro
candidato
Registro
electores
Voto Resultados
Usabilidad (6) E E E E
Formación (5) E E E E
Simplicidad (2) E E E E
Tolerancia al error (9) G G E E
Capacidad de expansión (8) G F E E
Generalidad (3) G G G G
Modularidad (4) E E E E
Operatividad (7) E E E E
Expendability3
(1) E E E E
Tabla 12. Aplicaciones vs Atributos de calidad
Después de haber calificados los atributos, se busca cual patrón de diseño se puede acoplar.
Para este proyecto se trabajará con patrones base por aplicación a pesar de las múltiples coin-
cidencias entre características y atributos de las cuatro aplicaciones a trabajar (registro candi-
dato, registro electores, voto, resultado).
1 2 3 4 5 6 7 8 9
Registro candidato E E G E E E E G G
Registro electores E E G E E E E F G
Voto E E G E E E E E E
Resultado E E G E E E E E E
Tabla 13. Aplicaciones vs Atributos de Calidad según Khosravi y Guéhéneuc
Según esto, no hay un patrón que acierte en su totalidad con cada aplicación. Los parecidos
son:
Registro candidato E E G E E E E G G
Patrón probabilidad
de acierto
Abstract Factory E E G G G G G G G 0.55555556
3
Se deja el término en ingles ya que no tiene una traducción clara para el lector.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 42
Decorator E E G F G G G G F 0.44444444
Iterator E E G F G F F G G 0.55555556
Tabla 14. Aplicación Registro Candidato vs Patrones de diseño
El patrón para la aplicación de registro de candidatos que se va a utilizar en el diseño es Abs-
tract Factory debido a que es un patrón de creación que abstrae el tipo concreto de objeto
producido es decir no cambia si el objeto a crear es de otro tipo. En nuestro caso las caracte-
rísticas del candidato puedan cambiar pero sin importar estos cambios su forma de interpreta-
ción será la misma. No obstante se ve reflejado el patrón Iterator en la aplicación debido a
que ésta también debe soportar el proceso de cierre de candidatos en el cual se bloquea el
ingreso de nuevos registros y se genera un conteo de la totalidad de los candidatos inscritos.
Registro electo-
res
E E G E E E E F G
Patrón probabilidad
de acierto
Abstract Factory E E G G G G G G G 0.44444444
Decorator E E G F G G G G F 0.33333333
Iterator E E G F G F F G G 0.44444444
Tabla 15. Aplicación registro elector vs Patrones de diseño
El registro de electores es Abstract Factory debido a la similitud de este proceso con el proce-
so de registro candidatos, salvo que los registros de los electores no pueden modificarse.
Aplicación vota-
ción
E E G E E E E E E
Patrón probabilidad
de acierto
Abstract Factory E E G G G G G G G 0.33333333
Decorator E E G F G G G G F 0.33333333
Iterator E E G F G F F G G 0.55555556
Tabla 16. Aplicación votación vs Patrones de diseño
El patrón que se escoge para el proceso de votación es el Iterator debido a que este patrón
facilita el recorrido de la selección de opción por candidato, es decir permitirá que el elector
pueda fácilmente anular o devolver una opción seleccionada ya sea por alcaldía o por conce-
jo.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 43
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Resultados escruti-
nio
E E G E E E E E E
Patrón probabilidad
de acierto
Abstract Factory E E G G G G G G G 0.33333333
Decorator E E G F G G G G F 0.33333333
Iterator E E G F G F F G G 0.55555556
Tabla 17. Aplicación resultados escrutinio vs Patrones de diseño
Por cada uno de los candidatos como por partido se deben hacer recorridos sobre los registros
almacenados para generar los resultados de la votación, es por esto que el patrón Iterator es
quien permite realizar ésta navegación.
Definidos los patrones de diseño por aplicación, hay que hacer una aproximación de estos a
los patrones para Web Services debido a que el diseño de este sistema de voto electrónico
debe ser diseñado y en su momento implementado para Web Services debido a la ligereza
que ofrece las aplicaciones construidas con web services, ademas de las políticas nacionales
de sitios web definidos dentro de la Registraduría Nacional del Estado Civil y en el programa
Gobierno en línea, proceso que fue narrado en el documento de arquitectura empresarial du-
rante la construcción de la vista de comportamiento de la aplicación, donde se justifica el uso
del lenguaje XML para el intercambio de información y la orientación hacia los web services.
Considerando esta restricción y entendiendo que los patrones de diseño pueden ser utilizados
en lenguajes de programación como C++, C# y Java con sus respectivos cambios ajustados al
lenguaje, se escoge para este proyecto diseñar la arquitectura de software con base en el len-
guaje Java debido a la fortaleza en seguridad y las estructuras a nivel de patrones que para
Web Services ofrece Java [48][58][59], situación que no ofrece Microsoft; esto complemen-
tado con la especificación de propiedad intelectual que se hizo de la propuesta completa don-
de se especificó el uso de software libre con licencia GPL versión 3, aceptada tanto por el
director de la tesis como por el evaluador de la propuesta.
Según Monday [48], los patrones que se acercan al Abstract Factory y al Iterator de los patro-
nes GOF son: El patrón Service Factory y el Business Process (Composition).
El patrón Service Factory es un patrón que tiene sus raíces el patrón GOF Abstract Factory.
La idea de este patrón es simple: debe aislar los puntos de la variabilidad en bloques de códi-
go de contenido fácilmente. Es decir, el uso de este patrón es para abstraer su aplicación fuera
de los detalles de escoger un servicio web socio. La responsabilidad del Service Factory es
seleccionar una de las implementaciones de servicio y retornar una implementación trabajan-
do que se adhiera a la interface común de la aplicación.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 44
El patrón Business Process (Composition) es un patrón cuya intención es ilustrar y proveer
una guía para combinar las actividades de negocio en un único y consumible Web Service
con una interface bien definida. Este patrón también es un intento para cambiar la mentalidad
de la perspectiva orientada a objetos del lenguaje java a una perspectiva de procesos de nego-
cio.
Siguiendo estos conceptos, la relación de las aplicaciones a los patrones de diseño y luego a
los patrones de Web Services se ilustra en la figura 13.
Basados en la figura 13, se puede apreciar que las aplicaciones de registro candidato y regis-
tro electores comparten el mismo patrón GOF como de Web Services, de igual forma la apli-
cación Votación con la aplicación Resultado Escrutinio. Con base a esto, se integran estos
patrones de web services al patrón arquitectónico definido anteriormente, el cual es el N-Tier.
La figura 14 ilustra la integración de estos patrones Web Services. Esta figura nos permite
observar del lado izquierdo el nombre de cada una de las capas, en el centro se ve la estructu-
ra del patrón Service Factory y al lado derecho se aprecia la figura del patrón Business Pro-
cess (composition).
Aplicación Registro
candidato
Aplicación
Registro electores
Aplicación votación
Aplicación resultado escrutinio
Abstract Factory Abstract Factory Iterator Iterator
Service Factory(Web
Service Pattern)
Service Factory(Web
Service Pattern)
Business Process (Composition
pattern)
Business Process (Composition
pattern)
Figura 13. Mapeo de aplicaciones a patrones GOF y a patrones de Web Services
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 45
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Capa Negocio
Capa presentación
Capa persistencia
Capa Cliente
Application
InterfaceBusinessProcess
Interface Business ActivityBusinessProcessImpl
Directory (ServiceLocator)
Application
ServiceFactory
InterfaceService
ServiceImplA ServiceImplB
BusinessActivityImpl
LinkedListActivitySequence
data
Figura 14. Diseño detallado (nivel 1): Patrón N-Tier más Patrones Web Services
Profundizando el diseño, relacionamos también más patrones dentro de cada uno de los de
Web services ya definidos. De allí, que se relacionen de la siguiente forma:
Para el Service Factory: Para el Business Process (composition)
La clase Application con el patrón Intercep-
ting Filter
la clase Application con el patrón Intercepting
Filter
La clase InterfaceService con el patrón
Front Controller
la clase InterfaceBusinessActivity con el pa-
trón Front Controller
La clase ServiceFactory con el patrón Ser-
vice to worker
la clase InterfaceBusinessProcess con el pa-
trón Front Controller
La clase Directory con el patrón Service
Locator
la clase BusinessProcessImpl con el patrón
Dispatcher View
La clase ServiceImplA y ServiceImplB con la clase BusinessActivityImpl con el patrón
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 46
el patrón Service Activator. Business Delegate
la clase LinkedListActivitySequence con el
patrón Value List Handler
la clase Data con el patrón Transfer Object y
el Composite Entity
Tabla 18. Relación de patrones en el nivel 1 de diseño
La descripción de los patrones se presenta en el anexo B.
De esta manera, el diseño más detallado, a nivel 2, quedaría construido de la siguiente mane-
ra:
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 47
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
CAPA DE INTEGRACIÓN
CAPA DE CLIENTE
CAPA DE PRESENTACIÓN
CAPA DE NEGOCIO
Intercepting Filter
Entrega el control a
FrontContoller
Front Controller
DispatcherView
ServiceTo Worker
Business Delegate
ServiceLocator
Value List
Handler
Composite Entity
TransferObject
ServiceActivator
El front Controller con el intercepting
DECORA en contenido la
interfaz y el front controler decide como se quiere
decorar si añadiendo objetos
compuestos a la interfaz o
mostrando ayudas contextuales, según
la acción del usuario
Se ITERA a través de los servicios y existe
la positibilidad de despachar a quien
lo requiera por medio del front
controller o también la posibilidad de
buscar un servicio en caso que se
tengan elementos tercerizados con
servicios y para ello es el patrón Service
To worker
Si se requiere un objeto de la lista es el patrón Transfer Object el que se
encarga de decidir a que objeto de datos
decirle y en este sentido se acceden a los objetos de datos
a través de una referencia única,
actuando esta parte en un todo como un singletón en el cual no se sabe como se produjo el objeto. De otra parte si los
objetos que se van a obtener tienen una
única forma para darle sentido de
SINGLETON o ABSTRACT FACTORY cuando se accede a
los servicios es usando el Service
Activator
Despacha controlDe procesamiento
Liviano para que múltiples Usuarios puedan
Acceder al sistema sin demoras
Controla procesamiento de
interfaz gráfica
Accede a objetos de negocio
LocalizaServicios
Encapsula datos
Maneja la Granularidad a los
ComponentesDe negocio
Despacha sincrónico procesamiento
Accede a lista de negocio
Intercepting Filter
Entrega el control a
ServiceLocator
Figura 15. Diseño detallado (nivel 2) del voto electrónico
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 48
3. Diseño de la Base de Datos para el Voto Electrónico
El diseño de la base de datos se crea teniendo en cuenta los actores y elementos de interac-
ción para el sistema de voto electrónico.
El modelo de Bases de datos se construyo bajo la necesidad de dar mayor soporte a la arqui-
tectura de software ya diseñada y teniendo en cuenta aspectos como el material electoral (car-
tillas de preparación de jurados), información de la registraduría municipal (como los tipos
de formularios que se emplean en la línea estratégica de votación), información adquirida
mediante documentación de la registraduría nacional del estado civil en su pagina web y ex-
periencia tanto del registrador municipal así como del autor.
A continuación se muestran los elementos que se interpretaron para la construcción del dise-
ño lógico de base de datos tanto para el proceso de inscripciones como para el proceso de
votación, donde se bosquejó un estado ideal donde los partidos políticos estén interconecta-
dos con la registraduría para la asignación de avales de candidatos y el diagrama lógico de la
base de datos planteada:
3.1 Diseño Lógico de la Base de Datos para el Proceso de Inscripción de Electores y Candidatos
La descripción de las entidades y los atributos se puede apreciar en el anexo C. A continua-
ción se presenta el modelo lógico de la base de datos para el proceso de inscripción de electo-
res y candidatos (Figura 16).
3.2 Diseño Lógico de la Base de Datos para el Proceso de Votación
Debido a que el modelo lógico de base de datos para votación utiliza algunas de las tablas que
se emplearon en el modelo de inscripción se presenta una breve descripción de las entidades
que se creen necesarias aclarar. La totalidad de las descripciones de las entidades y sus atribu-
tos se encuentran en el anexo D.
La entidad inscrip se crea como una copia de la entidad inscripción_elector solo que no con la
totalidad de los atributos. La entidad Inscripcion_candidato del modelo de votación es la
misma entidad inscripcion_candidato del modelo de inscripción, solo que no se dibujó con
sus respectivas conexiones para facilidad de entendimiento.
La entidad partido se duplica ya que en el momento de la jornada de votación pueden haberse
realizado alianzas que no estaban cuando se realizó la inscripción pero que posteriormente se
efectuaron bajo coordinación de la registraduría en su sede central (Bogotá).
La tabla Corporación se crea para poder facilitar la consulta de boletines. El término de cor-
poración se da para los cargos a escoger que hayan: presidencia, referendos, consultas parti-
distas, alcaldía, concejo, gobernación, asamblea, cámara y senado.
Según la descripción presentada, se ilustra el modelo lógico del proceso de votación en la
figura 17.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 49
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Figura 16. Modelo lógico del proceso de inscripción de candidatos y electores
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 50
Figura 17. Modelo lógico del proceso de votación
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 51
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
V – PROTOTIPO Y VALIDACIÓN
Según la ciencia basada en el diseño, la forma de instanciar el resultado propuesto es median-
te un artefacto, el cual para este proyecto fue un prototipo de interfaces de usuario para el
proceso de inscripción de electores y candidatos así como para el proceso de votación.
1. Prototipo
Este prototipo se llevó a cabo implementando tanto la parte de la arquitectura empresarial
como la arquitectura de software. Para poder implementar la parte de la arquitectura empresa-
rial se interpretaron las vistas desarrolladas en Archimate y se mapearon mediante el modela-
do de Business Process Modeling Notation versión 2.0 (BPMN 2.0). A continuación se pre-
sentan algunos modelos BPMN desarrollados para el prototipo, la totalidad de modelos se
pueden apreciar en el anexo E.:
Figura 18. Modelo BPMN del subproceso de Inscripción de candidatos y electores
Posterior al diseño de los procesos, se desarrollaron Web services para emplear de forma
práctica la arquitectura empresarial así como el manejo de bases de datos. Este prototipo se
hizo empleando la herramienta Bizagi debido a que es de las herramientas gratuitas mas esta-
bles que se encuentran para el manejo de procesos de negocio (BPMS). Bizagi se utilizó para
orquestar los procesos de negocios junto con los web services desarrollados y el DBMS se-
leccionado. Además, Bizagi permite la asignación de roles y usuarios para aumentar paráme-
tros de seguridad y mejorar la auditoria sobre quien manda cada proceso y/o subproceso
A continuación se presentan una imagen del prototipo de interfaces:
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 52
Figura 19. Inscripción del candidato
El video del prototipo de interfaces se puede apreciar en los siguientes sitios web:
http://pegasus.javeriana.edu.co/~PA111-01-eVoto/video/videoprototipo.avi
http://sites.google.com/site/danielcaceresrincon/schedule/videoprototipo.mp4
La validación del proyecto se realizó en 2 partes: la validación de la arquitectura empresarial
y la validación de la arquitectura de software.
2. Validación de la Arquitectura Empresarial
La percepción personal del autor de validación sea que científicamente, cualquier solución
que se plantee debe ser evaluada en su entorno bajo unos criterios que se establecen por con-
venio en las entidades que dirigen el desarrollo de propuestas de cierta área del conocimiento.
Así como el autor tiene una percepción personal de validación, hay muchas definiciones co-
mo se muestra a continuación:
La guía EURACHEM [60] establece que la validación de métodos es el proceso de
verificar que un método es apropiado para un propósito dado, es decir, para usarse en
la solución de un problema analítico particular.
La versión más reciente de la definición de validación se presenta en la norma ISO
9000:2000 [61] donde establece que la validación es “la confirmación y provisión de
evidencia objetiva de que se cumplen los requisitos para un uso o aplicación previs-
ta”.
Según Kuechler [62], en la ciencia basada en el diseño, la relación de un artefacto di-
señado con la teoría que lo soporta es de extensión y refinamiento. De allí que Gon-
zález [62], plantee que la validación científica basada en el diseño puede ser lograda
mediante artefactos de simulación, aclarando que la validación y evaluación de un
artefacto debe verse desde el punto de vista de la simulación, donde se puede apoyar
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 53
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
la evaluación de los artefactos mediante el suministro de un ambiente artificial para
probar su utilidad potencial y por lo tanto la validación de la teoría subyacente
Al ser la forma de dar certeza a una solución propuesta, la validación es requerida en normas
sobre sistemas de gestión de la calidad [63], sobre software (ver documento de arquitectura
de software) y sobre los procesos de negocio una empresa [64].
Por último, Khatri et. Al, proponen un concepto de validación donde examinaron los efectos
del conocimiento del dominio de los sistemas de información y el conocimiento del dominio
de aplicación de los mismos en diferentes tipos de tareas de comprensión de esquema: tareas
de comprensión sintáctica y semántica y el esquema basado en tareas de resolución de pro-
blemas [65]. Para el desarrollo de su estudio, utilizaron la teoría del ajuste cognitivo para
establecer las diferencias teóricas en el papel del conocimiento del dominio de aplicación
entre los diferentes tipos de tareas de comprensión del esquema
La parte sintáctica busca evaluar el tema a la raíz del concepto, es decir, la teoría y metodo-
logía; mientras que la parte semántica busca evaluar el tema desde los efectos e implicaciones
prácticos y reales del tópico a validar. Cabe aclarar que esta validación semántica es distinta
de la que promueve Weber et. al [66]. La última parte, la del esquema basado en tareas de
resolución de problemas busca encontrar y evaluar la relación indirecta entre la representa-
ción del problema y los requerimientos de una tarea.
Como resultado de este estudio, Khatri et al concluyen que mientras el conocimiento del
dominio es importante para resolver todo tipo de esquemas conceptuales para la resolución de
tareas en ámbitos de aplicación conocidos y desconocidos, la función de los conocimientos
del dominio de aplicación surten efecto dependiendo del tipo de tarea bajo investigación. De
allí, que sea importante entender que el punto de vista del aspecto real y cotidiano del posible
uso de la solución otorgado por gente que lo vaya a emplear o utilizar es un gran complemen-
to del punto de vista de validación de la solución mediante el proceso científico.
Para este proyecto se decidió emplear parte de la metodología de validación de Khatri et. al
[65] ya que permite analizar de dos formas compuestas la arquitectura empresarial permitien-
do presentar mayor punto de calidad en el resultado esperado y permitiendo ver la validación
desde 2 puntos de vista diferentes. La validación sintáctica se complementó con el esquema
de validación de modelos de madurez de arquitecturas empresariales, el cual fue realizado por
un experto en el área de arquitectura empresarial, el Ing. José C. Niño; mientras que la vali-
dación semántica se complementó con el esquema de validación por un experto quien para
este proyecto es el Registrador Municipal de Choachí, Dr. Jorge A. Díaz.
2.1 Validación Sintáctica realizada por el Ing. José C. Niño
Del análisis realizado por el Ing. José Niño (ver anexo F) se rescatan como elementos para
modificar en una segunda iteración del sistema generar el restante de los puntos vistas para
aumentar la calidad del detalle permitiendo justificar mejor los costos del desarrollo de las
aplicaciones. Tambien considera importante analizar la arquitectura empresarial desde algun
framework de arquitectura empresarial como otra forma de validación aumentando la calidad
de las metodologías ya presentadas. Por utlimo, como consejo ve necesario integrar al muni-
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 54
cipio directamente en el proyecto para que se tengan en cuenta aspectos como un repositorio
para el proyecto y la adquisición de herramientas para dar pleno soporte a la arquitectura
desarrollada.
2.2 Validación Semántica realizada por el Registrador municipal de Choachí, Dr. Jorge A. Díaz
Por parte del Registrador municipal en el análisis de su validación (anexo G), se puede apre-
ciar que a pesar de ser una primera propuesta este modelo, cumple con los requisitos del voto
sin alterar ninguno de los estamentos de la registraduría nacional del estado civil. Las suge-
rencia del registrador municipal se da hacia el punto de revisar los costos para poderlo hacer
mas accesible, debido a que si el proyecto es iniciado por la registraduría municipal solamen-
te, sin apoyo de ningún otro ente nacional, departamental o municipal, seria un costo alto de
pagar para la registraduría municipal.
3. Validación de la Arquitectura de Software
La validación de la arquitectura de software nos debía garantizar que lo realizado en el diseño
cumplía con alguna guía internacional para la construcción de software, conjuntamente, debi-
do a que fue construido un artefacto que representara esa arquitectura se debía realizar no
solo de forma teórica sino también practica la validación de la arquitectura. Además, era
necesario fundamentar lo robusto que fueron los resultados en cada arquitectura, desde los
conceptos tenidos en cuneta hasta los diseños finales.
De allí, que dentro de la búsqueda en la base del conocimiento y evaluando entre los distintos
tipos de validación que existen para arquitecturas de software se empleara la validación según
ATAM, pues era la que de forma teórica nos permitía evaluar a fondo la calidad del diseño.
No obstante, para validar el prototipo se encontró dentro de las múltiples opciones para vali-
dación de artefactos, que la más adecuada para el prototipo de interfaces funcional creado era
la validación TAM, la cual permitía acercar a los futuros usuarios a la primera iteración real
de la arquitectura.
3.1 Validación según ATAM
El método Architecture Tradeoff Analysis Method – ATAM - según Clements et. Al [67]
[68], es un método que evalúa las consecuencias de las decisiones arquitectónicas a la luz de
los requisitos de los atributos de calidad. ATAM trabaja sobre tres áreas: la noción de estilos
arquitectónicos, las comunidades de análisis de atributos de calidad, y el método de análisis
de arquitecturas de software (Software Architecture Analysis Method – SACAM).
Una de las implicaciones de usar ATAM es que puede ser aplicado al principio del ciclo de
desarrollo de software. De allí que las mayores metas de ATAM sean:
a) Obtener y refinar una declaración precisa del manejo de los requisitos de los atributos
de calidad de la arquitectura.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 55
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
b) Obtener y refinar una declaración precisa de las decisiones de diseño arquitectónico.
c) Evaluar las decisiones de diseño arquitectónico para determinar si dan una respuesta
satisfactoria a las exigencias de calidad.
3.1.1 Presentación de los factores de negocio
Identificando los requerimientos iniciales del sistema se puede visualizar la relación entre
estos requerimientos, los atributos de calidad del sistema y los elementos que están relaciona-
dos con la consecución de estos atributos a nivel de la arquitectura. Este trabajo dará luces
para establecer los escenarios que se tendrán para cada factor de negocio. Lo importante del
método es que una vez se tenga formalizado que el diseño global de la arquitectura ha sido
completamente válido a la luz de los requerimientos, se procede a elaborar los elementos de
diseño para verificar que siguen cumpliendo las especificaciones originales y para este paso
se puede aplicar nuevamente y recursivamente el método. Sin embargo, este tipo de situacio-
nes generalmente se acostumbran a dejar cuando se está haciendo implementaciones modula-
res y se tienen que modificar diseños concretos específicos del lenguaje de programación en
el que se implemente.
Debido a la extensión de los requerimientos del sistema, el análisis se realizara sobre los ca-
sos de uso que reúnen muchos de los requerimientos del sistema. Para ver la tabla completa ir
al anexo H.
Casos de uso Atributo de cali-
dad asociado al
requerimiento
inicial. El que
más prima
Proceso de
negocio que se
relaciona con
dicho requeri-
miento
Elementos de
arquitectura
que intervie-
nen en el
sistema.
Escenarios más relevan-
tes al interior
Almacenar for-
mularios en DB
Modularidad Aplicación Re-
gistro candidato
Service Fac-
tory Pattern
Esc1: Al momento de in-
gresar el formulario otro
usuario desea consultarlo y
modificarlo al mismo tiem-
po
Esc2: En caso de migrarse
la DB a la que acceden los
servicios
Almacenar repor-
tes
Capacidad de ex-
pansión
Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Esc1: Antes de haber ce-
rrado la jornada de inscrip-
ciones de candidatos o de
electores, se requiere tener
un informe sobre los regis-
tros efectuados
Almacenar votos Simplicidad Aplicación vo- Business Pro- Esc1: Se da inicio a la jor-
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 56
del sistema tación cess nada de votación y se pre-
senta un elector que no está
inscrito en el municipio
Bajar Servicio
Jornada de Vota-
ción
Tolerancia al error Aplicación vo-
tación
Business Pro-
cess
Esc1: Se presentan alterca-
dos de orden público en el
puesto de votación y se
requiere bajar los servicios
antes de la hora estipulada
CerrarProcesoDe
Inscripciones
electores
Operatividad Aplicación Re-
gistro elector
Service Fac-
tory Pattern
Esc1: Intento de ingreso
del nuevo registro de elec-
tor después de cerrar el
proceso
Crear formulario
E-24/E-26
Usabilidad Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Es1: Generar un formulario
de un proceso no estipula-
do
Generar certifica-
do electoral
Expendability Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Esc1: Un usuario que se
inscribió pero no votó re-
clame el certificado electo-
ral
Validar el elector
en jornada de
votación
Generalidad Aplicación Re-
gistro elector
Service Fac-
tory Pattern
Esc1: Se presenta un elec-
tor con una cedula falsa y
pretende votar
Validar mediante
lector biométrico
y de código de
barras en jornada
de inscripción
Formación Aplicación vo-
tación
Service Fac-
tory Pattern
Esc1: Se presenta un elec-
tor con una cedula falsa y
pretende inscribirse.
Tabla 19. Resumen Aplicación de ATAM sobre la arquitectura de sistema del voto electrónico
3.1.2 Análisis de resultados
Con base en la tabla anterior, se procede a dar explicación de cómo la arquitectura y los atri-
butos de calidad definidos si son importantes para la mayoría de escenarios propuestos:
Patrón Service Factory Pattern
Caso de uso Almacenar formularios en DB
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 57
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Lo que permite
el patrón
Permite utilizar el patrón me-
diador para mitigar las diferen-
cias entre servicios
Cuando el tiempo para una transición
llega usted podría configurar la factoría
para localizar el nuevo sistema de persis-
tencia de los datos
Situaciones
Excepcionales
Al momento de ingresar el
formulario otro usuario desea
consultarlo y modificarlo al
mismo tiempo
En caso de migrarse la DB a la que acce-
den los servicios
Justificación Las diferencias en los servicios
de consulta y de modificación
pueden ser mitigadas mediante
el patrón mediator
Lo formularios acceden a una factoría
que permite localizar el nuevo sistema de
persistencia de datos
Resultado Tanto las consultas como las
modificaciones pueden ser
realizadas desde dos usuarios
diferentes
El sistema se libera de tener dependencia
con respecto a la localización de la base
de datos y esto permite agilidad en futu-
ras migraciones de los sistemas de per-
sistencia
Tabla 20. Patrón Service Factory - CU Almacenar formularios en DB
Patrón Service Factory Pattern
Caso de uso Almacenar Registro Electores
Lo que permite Se podría usar para relacionar objetos de negocio con colecciones de obje-
tos
Situaciones
Excepcionales
La creación de un registro de elector que ya existe
Justificación
El Service Factory permite establecer relaciones directas con la colección
de objetos creados previamente evitando crear redundancias en la capa de
persistencia
Resultado La aplicación del Service Factory permite bajos niveles de redundancia en
los registros de la base de datos
Tabla 21. Patrón Service Factory – CU Almacenar registro electores
El resto de tablas de explicación de los patrones ajustados a los casos de uso se presentan en
el anexo F.
3.2 Validación TAM
El Modelo de Aceptación de la Tecnología (Technology Acceptance Model - TAM) de Davis
[69] es una teoría de los sistemas de información que modela cómo los usuarios llegan a
aceptar y utilizar una tecnología. El modelo sugiere que cuando a los usuarios se les presenta
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 58
una nueva tecnología, una serie de factores influyen en su decisión sobre cómo y cuándo la
van a utilizar, dicho de otra forma, sirven de base para determinar las actitudes enfocadas al
uso del sistema. Estos factores son:
• PU (Perceived usefulness, Utilidad Percibida): “el grado en que una persona cree que el
uso de un determinado sistema mejora su rendimiento en el trabajo”.
• FUP (Perceived ease-of-use, Percepción de facilidad de uso): “el grado en que una persona
cree que utilizando un sistema en particular, podrá liberarse del esfuerzo que le conlleva
realizar un trabajo” [70].
Variables
externas
Utilidad
percibida
Facilidad de uso
percibida
Intención de
comportamiento
Uso del sistema
actual
Figura 20. Modelo de Aceptación de la Tecnología. Fuente: Davis [69]
Para este proyecto, el usuario elegirá entre dos sistemas con funciones idénticas: el sistema de
registro tradicional y votación de la registraduría municipal de Choachí y el sistema propues-
to en el proyecto representado mediante el prototipo funcional de interfaces de usuario de
inscripción de electores y candidatos.
La forma de realizar esta validación se dio mediante el siguiente formulario de encuesta que
se presentó al registrador municipal, al personero municipal y a un ciudadano al azar. Se to-
mó como guía el tipo de encuesta realizado por Orantes [71], con respectivos ajustes para el
entorno en el cual se va a aplicar, además de controlar las opciones de votación de 7 opciones
como maneja orantes a 5 (totalmente de acuerdo - 5, de acuerdo - 4, ni acuerdo ni desacuerdo
- 3, en desacuerdo - 2, totalmente en desacuerdo - 1):
Hay que aclarar que de las 14 preguntas, solo el registrador debía contestarlas todas. Las otras
dos personas al solo interactuar como quienes recibían la inscripción y como votantes res-
pondieron solo las preguntas de facilidad de uso y de actitud hacia el uso.
El resultado por parte del registrador fue:
¿Es fácil aprender a operar el nuevo sistema? 5
¿Es fácil acceder al sistema para hacer lo que deseo? 4
¿Es fácil aumentar mi experiencia gracias al uso del nuevo sistema? 5
¿El nuevo sistema es fácil de utilizar? 5
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 59
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
¿Sería fácil llegar a ser un experto en el manejo del sistema 4
¿El uso del nuevo sistema me ayuda a hacer las tareas más rápido? 5
¿El uso del nuevo sistema mejoraría el funcionamiento de mi trabajo dentro de la
registraduría?
5
¿El uso del nuevo sistema aumenta mi productividad dentro de la registraduría? 5
¿El uso del nuevo sistema incrementa mi efectividad dentro de la registraduría? 4
¿El nuevo sistema es de utilidad dentro de la registraduría? 4
¿Usar el nuevo sistema es una buena idea? 4
¿Usar el nuevo sistema es una inteligente idea? 4
¿Me gusta la idea de usar el nuevo sistema? 4
¿Usar el nuevo sistema me parece (placentero/no-placentero)? 3
Tabla 22. Resultados registrador TAM
El resultado del Personero (Diego Pardo) y de un votante de las pasadas elecciones en el mu-
nicipio (Benedicta Rincón) fue:
Preguntas Diego Pardo Benedicta Rincón
¿Es fácil aprender a operar el nuevo sistema? 5 5
¿Es fácil acceder al sistema para hacer lo que deseo? 4 4
¿Es fácil aumentar mi experiencia gracias al uso del
nuevo sistema?
5 5
¿El nuevo sistema es fácil de utilizar? 5 5
¿Sería fácil llegar a ser un experto en el manejo del
sistema
4 4
¿Usar el nuevo sistema es una buena idea? 4 4
¿Usar el nuevo sistema es una inteligente idea? 4 4
¿Me gusta la idea de usar el nuevo sistema? 4 4
¿Usar el nuevo sistema me parece (placentero/no-
placentero)?
3 3
Tabla 23. Resultados ciudadanos TAM
Las validaciones realizadas para toda la arquitectura nos llevan a deducir que aunque esta
propuesta de voto electrónica dentro de esquemas complejos o mundiales sea una fase inicial
o de estudios guías, se presenta como el camino o pauta para poder implementar una solución
tecnológica manteniendo la coherencia de la solución con el problema desde donde se origi-
na, ya que en Colombia, no se ha presentado modelo de arquitectura similar (solo pilotos
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 60
sobre aplicaciones). Factores como la comprensión de la realidad colombiana y de su ente
gestor de las elecciones, así como la presentación de un prototipo y un nivel de aceptación
aceptable del mismo por parte de los futuros usuarios permite entender que este proyecto sea
visto una vía de innovación real no muy lejana para Colombia.
VI - CONCLUSIONES
El hecho de presentar una propuesta que integre no solo la forma de implementar el voto sino
su relación con el entorno organizacional que lo controla es nueva desde cualquier perspecti-
va de ingeniería, así como para Colombia, ya que no se ha presentado modelo de arquitectura
similar como se apreció durante el estudio del estado del arte del voto electrónico mundial y
en Colombia.
De forma general, se puede apreciar que el desarrollo de esta arquitectura de sistema permite
ser una guía de los procesos y de la forma de dar soporte, a nivel tecnológico y organizacio-
nal, al dinamismo propio de la registraduría municipal de Choachí y nacional, permitiendo
identificar claramente cómo funcionan sus procesos, la dependencia de sus actividades y
presentando una solución que incluye, por una parte nueva tecnología y por otra, identificar y
mejorar las aplicaciones y/o soluciones tecnologías que ya se tenga para la mejora y agilidad
de ciertos procesos relacionados a la línea estratégica del voto. El hecho de desarrollar una
arquitectura de sistema como solución integrada fortalece la propuesta de votación electróni-
ca, porque permite mantener coherencia entre la realidad del voto y una solución propuesta
que ya se empieza a ver como una prioridad, como lo manifestó el Registrador Nacional Car-
los Ariel Sánchez Torres después de las elecciones del día 30 de octubre donde expreso que
la implementación del voto electrónico en Colombia debe ser gradual, como se hizo en Bra-
sil, en donde comenzó su utilización en algunas elecciones de tipo local y fue expandiéndose
paulatinamente [72].
Igualmente, La comunidad a la que aplica el proyecto contaría con una herramienta que per-
mitiría disminuir el ausentismo electoral y brindaría en un futuro mayor cobertura a los dis-
capacitados, debido a las facilidades que este modelo otorgaría remplazando los antiguos
tarjetones electorales.
A nivel de detalle, esta arquitectura empresarial permitirá a la registraduría municipal de
Choachí ser dinámica con el paso del tiempo, ya que en la actualidad no se había realizado
ningún tipo de metodología para reconocer los procesos, actores y elementos que hacen parte
de la línea estratégica de votación. Al mismo tiempo, permitirá realizar modificaciones en sus
procesos sin sufrir grandes traumas, debido a que la arquitectura empresarial da la ventaja de
reconocer fácilmente los procesos y evitar colapsar toda una línea estratégica. Asimismo, esta
arquitectura facilita generar puntos de medición o indicadores sobre actividades, tareas o
procesos para permitir llevar un control de la organización y su evolución mediante análisis
cuantitativos, análisis de brechas entre otras formas de medición, factor que actualmente no
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 61
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
se tiene debido a lo artesanal que es esta línea estratégica, elemento que no permitía tener
históricos de análisis en tiempo real como ningún control de proceso ni cuantitativo ni cuali-
tativo.
Basados en la validación semántica del experto, se puede apreciar que desde el punto de vista
del registrador se cumple con la identificación clara de los procesos y no se omite ninguno
dentro de la concepción de la solución tanto empresarial como previa del software. Esto per-
mite al lector entender que la viabilidad conceptual en la representación de la línea estratégica
del voto con esta arquitectura (el elemento empresarial) tiene un soporte adecuado para la
realidad colombiana, en este caso para la realidad de un municipio de categoría sexta como
Choachí.
Desde el punto de la validación sintáctica también podemos concluir que a pesar de que es
una primera muestra de cómo se puede realizar el voto electrónico en el municipio, cumple
con las condiciones necesarias para implementarse y poder ser evaluada a futuro como lo
manifiesta la validación que tuvo esta arquitectura según el modelo de madurez de arquitectu-
ras empresariales.
A nivel del detalle de la arquitectura de software, se puede concluir que el desarrollo del di-
seño propuesto permite dar solidez conceptual y estructural a la propuesta de Votación elec-
trónica y su futura implementación, ya que al plantear un desarrollo mediante un esquema
basado en patrones desde el inicio, se trabaja sobre unas estructuras que se plantearon para
dar solución a problemas precisos, además permite analizar y detectar problemas en otros
ámbitos que no cubran los patrones desde su diseño ahorrando los costos futuros de solución
si ya se ha implementado, debido a que se llegaría al punto específico del problema gracias a
la trazabilidad que permite este diseño.
Igualmente, el uso de servicios web como forma de implementación para la futura aplicación
es una ventaja para cualquier proceso electoral que se lleve a cabo en Choachí o en la nación,
ya que facilita que los puestos de votación sean desplazables y accesibles desde cualquier
lugar donde se tenga conexión a internet (alámbrica, inalámbrica, satelital o móvil). Además,
el hecho de implementarse de forma electrónica (empleado desde cualquier equipo de cómpu-
to designado por la registraduría municipal o nacional con unos requisitos mínimos) permite
aumentar la capacidad de auditoria de todo el proceso electoral, así como la seguridad, por-
que se implementarían controles sobre cada una de las acciones que se realicen sobre el sis-
tema como: control de acceso de usuarios gracias a la integración propuesta con el sistema
morphocheck, logs de inserción, modificación y borrado de datos, entre otros, elementos que
serán de respaldo en el momento de realizar cualquier jornada de votación electrónica.
Otra ventaja de usar servicios web como forma de implementación del voto electrónico es el
manejo de la información electoral, porque el uso de servicios web permite que la informa-
ción almacenada no este solamente en el equipo donde se realiza sino que se pueda almacenar
en un servidor externo físicamente del lugar de votación, garantizando la calidad de los votos
y rompiendo vulnerabilidades físicas, gracias a que la información no va a estar solo en un
lugar, factor que implícitamente mejora la seguridad y auditabilidad del proceso en cualquier
momento. Dentro del proceso de diseño de la propuesta software con Servicios Web, se es-
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 62
cogió como lenguaje de programación Java, porque a la fecha es el lenguaje de programa-
ción en servicios web que mayor fortaleza a nivel de seguridad ofrece frente a Microsoft.
Además, el hecho de desarrollar e implementar Web services como parte de la arquitectura
propuesta tiene gran valor ya que es un paso importante para permitir la implementación de
una futura arquitectura orientada a servicios (SOA) [73] que permita la maximización y glo-
balización de la propuesta mediante la integración con las otras líneas estratégicas de la regis-
traduría. Esto se da porque los web services proveen un acercamiento a la computación dis-
tribuida para integrar aplicaciones extremadamente heterogéneas sobre internet ya que es
independiente del lenguaje de programación, sistema operativo y hardware.
Como complemento de esto, se plantea también el diseño del modelo de la base de datos ideal
para la propuesta de diseño de software presentada, dando coherencia a los conceptos mane-
jados en la arquitectura empresarial y empleando el conocimiento adquirido dentro del desa-
rrollo del proyecto para aumentar las fortalezas de la presente propuesta.
Al ser un proyecto de grado, la arquitectura de sistema se implementó como un prototipo de
interfaces de usuario, el cual para no perder la concepción de sistema se implementó usando
Bizagi para el modelado de los procesos integrándolo con web services y el respectivo mane-
jo de bases de datos. A pesar de ser solo un prototipo de interfaces de usuario su aceptación
por parte de los futuros usuarios fue más que aceptable como lo demuestra la validación
TAM realizada, lo que permite pensar que el camino recorrido con este proyecto no fue en
vano y que puede servir de pauta para nuevas propuestas que arranquen de cero como pro-
puestas que decidan mejorar el presente proyecto. Asimismo, este proyecto no representa
ningún compromiso de la Registraduría municipal con la sociedad y por tanto no tiene reper-
cusiones económicas. Dado el caso de implementarlo, las implicaciones que trae un proyecto
como este serían elevadas para el municipio si se aprueba de forma local y no nacional debi-
do a que la registraduría municipal correría con todos los gastos sobre el presupuesto asigna-
do, de allí que se tenga implicaciones fuertes en 3 aspectos: costos de adquisición, entrena-
miento y recursos.
Por ende, el modelo de arquitectura generado, si se llegara a implementar por la Registraduría
Nacional del Estado Civil o por la registraduría municipal, permitiría reducir el impacto am-
biental que producen las elecciones, al ahorrar en el consumo de papel para los tarjetones
electorales y reducir la cantidad de tinta utilizada en los mismos, además de la reducción en
los costos de transporte, fomentando un efecto positivo sobre el medio ambiente.
Analizando este modelo, así como entendiendo todas las pautas y políticas que con el paso
del tiempo se han presentado para que Colombia pueda tener voto electrónico, lo importante a
tener en cuenta es el impacto social que puede tener el mismo y que la forma en que se im-
plemente el voto electrónico no aumente la brecha digital que ya existe en Colombia pasando
a vulnerar el derecho a votar de cualquier ciudadano colombiano por ignorancia o rechazo a
la herramienta.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 63
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
VII – TRABAJO FUTURO
Como trabajo futuro se espera que basado en la arquitectura empresarial planteada se extien-
dan de las 7 vistas propuestas a las 14 vistas empresariales que trae Archimate para aumentar
la calidad del soporte conceptual. Además de eso, se espera que a quien le interese el tema
pueda seguir refinando el modelo de arquitectura empresarial de la registraduría y agregarle
procesos paralelos de otra línea de estrategia.
Desde el punto de vista de implementación (recordando que el artefacto construido fue un
prototipo de interfaces de usuario) se puede mejorar la asignación de usuarios y/o roles para
las cargas dentro de los procesos de la línea estratégica de votación, ya sea utilizando los
modelos BPMN generados en este proyecto y mejorándolos sobre Bizagi o utilizando los
modelos BPMN y mejorándolos sobre JBPMN.
También se puede plantear a nivel de arquitectura de software realizar el mapeo del diseño
actual de Java Web Services a Microsoft Web Services buscando identificar posibles mejoras
en seguridad desde el modelo en Microsoft, o confirmando la fortaleza del modelo en Java o
validándolo mediante una comparación directa con el modelo propuesto en este proyecto.
Asimismo, se espera integrar la parte de avales de los partidos políticos con la registraduría
municipal mediante el uso de servicios web para reducir los pocos aspectos físicos planteados
que pueden ser vulnerables de falsificación dentro del modelo propuesto.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 64
VIII – BIBLIOGRAFÍA
[1] CALTECH-MIT Voting Technology Project. “Voting: What is, what could be”. Massa-
chusetts Institute of Technology. USA. 2001.
[2] Rössler, T. “e-Voting A Survey and Introduction”. Secure Information Technology Center
- Austria.2005.
[3] Smith, E., Macintosh, A. “E-Voting: Powerful Symbol of e-Democracy”. ELECTRONIC
GOVERNMENT: Lecture Notes in Computer Science. Volume 2739. 2003.
[4] Busaniche, B., Heinz F., Rezinovskyt, A. “Voto electrónico: los riesgos de una ilusión”.
Fundación Vía Libre. 1ra edición. 2008.
[5] Chaum, D., Carback, R., Clark, J., Essex, A., Popoveniuc, S., Rivest, R., Ryan, P., Shen,
E., Sherman, A. “Scantegrity II: End-to-End Verifiability for Optical Scan Election Systems
using Invisible Ink Confirmation Codes”. EVT'08 Proceedings of the conference on Electron-
ic voting technology. USENIX Association Berkeley. USA. 2008.
[6] Davis III, J., Thomas, S. “Direct recording electronic voting machine and voting pro-
cess”. Election Products, Inc., ILT Corp. USA. 2001. Disponible en:
http://www.freepatentsonline.com/5583329.html.
[7] Kiayias, A., Korman, M., Walluck, D. “An Internet Voting System Supporting User Pri-
vacy”. in Proc. of the 22nd Annual Computer Security Applications Conference (ACSAC
'06). Pp: 165-174. 2006.
[8] Ministerio de Tecnologías de la Información y las Comunicaciones. “Manual para la
implementación de la Estrategia de Gobierno en línea”. Reglamentado mediante el Decreto
1151. 2008.
[9] Alvarez, R.M., Katz, G., Llamosa, R., Martinez, H.E. “Assessing voters' attitudes towards
electronic voting in latin america: Evidence from Colombia's 2007 E-voting pilot”. Lecture
Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and
Lecture Notes in Bioinformatics) 5767 LNCS. Pp: 75-91. 2009
[10] Periódico El Tiempo. “Implementarán plan piloto de voto electrónico en elecciones en
Bolívar”. Artículo. 2010. Disponible en:
http://www.eltiempo.com/colombia/cartagena/ARTICULO-WEB-
NEW_NOTA_INTERIOR-8162702.html
[11] Alonso, L. "Aspectos tecnológicos del voto electrónico". Documento de trabajo #17.
ONPE. Lima. 2007.
[12] Fitrakis, B. “Diebold, Electronic Voting and the Vast Right-Wing Conspiracy”. Free
Press. USA. 2004. Disponible en: http://www.commondreams.org/views04/0225-05.htm.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 65
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[13] Lockyer, B. “CA Sues Diebold For E-Vote Machine False Claims”. San Francisco
Reuters. 2004. Disponible en: http://www.rense.com/general57/machine.htm.
[14] Lemos, R. “Diebold voting systems critically flawed”. SecurityFocus. 2006. Disponible
en: http://www.securityfocus.com/news/11391.
[15] Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Merson, P., Nord,
R., Stafford, J. “Documenting Software Architectures: Views and Beyond”. Second Edition.
Boston: Addison-Wesley. 2010.
[16] Weill, P. “Innovating with information systems: what do the most agile firms in the
world do?”. Sixth e-Business Conference – MIT Sloan School of Management. Spain. 2007.
[17] Oostveen, A., Van den Besselaar, P. “Internet voting technologies and civic participa-
tion, the users perspective”. Javnost / The Public. Vol. XI, No.1. Pp: 61-78. 2004
[18] Rössler, T. “e-Voting A Survey and Introduction”. Secure Information Technology Cen-
ter - Austria. 2004.
[19] Duong, D., Nguyen, P., Pham, J., Wheeler, T. “eVoting Survey Analysis”. Portland State
University. 2004.
[20] Clowers, J. “I E-vote, U I-vote, Why Can’t We All Just Vote?!: A Survey of the Changing
Face of the American Election”. Gonzaga Law Review - HeinOnline. 2006
[21] Smith, E., Macintosh, A. “E-Voting: Powerful Symbol of e-Democracy”.
ELECTRONIC GOVERNMENT: Lecture Notes in Computer Science. Volume 2739. 2009
[22] CALTECH-MIT Voting Technology Project. “Voting: What is, what could be”. Massa-
chusetts Institute of Technology. USA. 2001.
[23]Encyclopædia Britannica. "Electronic voting". Encyclopædia Britannica Online.
EncyclopædiaBritannica. 2011. Disponible en:
http://www.britannica.com/EBchecked/topic/1472946/electronic-voting
[24] Red de Conocimiento Electoral ACE. “Definición e-voting”. 2011. Disponible en:
http://aceproject.org/ace-es/focus/fo_e-voting/fo_e-voting-what-is-e-voting
[25] Busaniche, B., Heinz F., Rezinovskyt, A. “Voto electrónico: los riesgos de una ilusión”.
Fundación Vía Libre, 1ra edición. 2008.
[26] Rial, J. “Definición del voto electrónico (4.)”. Observatorio Electoral Latinoamericano.
2011. Disponible en: http://www.observatorioelectoral.org/biblioteca/?bookID=26&page=1
[27] Red de Conocimiento Electoral. “Modelos de Sistemas de Votación Computarizados”.
2011. Disponible en: http://aceproject.org/main/espanol/em/emf02.htm
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 66
[28] Chaum, D., Carback, R., Clark, J., Essex, A., Popoveniuc, S., Rivest, R., Ryan, P., Shen,
E., Sherman, A. “Scantegrity II: End-to-End Verifiability for Optical Scan Election Systems
using Invisible Ink Confirmation Codes”. EVT'08 Proceedings of the conference on Electron-
ic voting technology. USENIX Association Berkeley. USA. 2008
[29] Davis III, J., Thomas, S. “Direct recording electronic voting machine and voting pro-
cess”. Election Products, Inc., ILT Corp. USA. 2002. Disponible en
http://www.freepatentsonline.com/5583329.html.
[30] Kiayias, A., Korman, M., Walluck, D. “An Internet Voting System Supporting User Pri-
vacy”. In Proc. of the 22nd Annual Computer Security Applications Conference (ACSAC
'06). Pp: 165-174. 2006.
[31] Gloversure. “Gloversure: sms voting, sms Vote”. 2010. Disponible en:
http://www.gloversure.co.uk/sms_vote.html
[32] Joaquim, R., Zúquete, A., Ferreira, P. “REVS – A Robust Electronic Voting System”.
IADIS International Journal of WWW/Internet. Volume 1. Issue: 2. 2003.
[33] Xenakis, A., Macintosh, A. “Procedural Security in Electronic Voting”. Proceedings of
the 37th Hawaii International Conference on System Sciences. 2004
[34] Wikipedia. “Definición de Interactive Voice Response”. Wikipedia. 2011. Disponible
en: http://es.wikipedia.org/wiki/Interactive_Voice_Response
[35] Mercuri, R. “A better ballot box?”. Spectrum, IEEE. Volume: 39 Issue:10. Pp:46 – 50.
2002. ISSN: 0018-9235
[36] Mercuri, R. “Facts About Voter Verified Paper Ballots”. Voter Verified Paper allots --
An Informational Brochure. 2011. Disponible en:
http://www.notablesoftware.com/evote.html
[37] Goggin, S., Byrne, M. “An Examination of the Auditability of Voter Verified Paper Audit
Trail (VVPAT) Ballots”. USENIX/ACURATE Electronic Voting Tecnhology Workshop
2007.
[38] Hevner, A., March, S., Park, J., Ram, S. “Design Science in Information Systems Re-
search”. MIS Quarterly. Volume 28. Issue :1. Pp. 75-105. 2004.
[39] Golden, B. "What is systems Architecture?". Article for Complex Systems Design &
Management. 2010. Disponible en:
http://www.lix.polytechnique.fr/~golden/systems_architecture.html
[40] The Open Group Archimate. “Archimate 1.0 Technical standard specification”. The
Open Group. 2009. Disponible en: http://www.opengroup.org/archimate/doc/ts_archimate/
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 67
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[41] Institute of Electrical and Electronics Engineers. “1471-2000 – IEEE Recommended
Practice for Architectural Description for Software-Intensive Sysyems”. IEEE Standards
Association. 2000. Disponible en: http://standards.ieee.org/findstds/standard/1471-2000.html
[42] Ministerio de Tecnologías de la Información y las Comunicaciones. “GEL-XML: Len-
guaje estándar de intercambio de información: notas explicativas a la arquitectura de da-
tos”. República de Colombia. 2009. Disponible en:
http://programa.gobiernoenlinea.gov.co/apc-aa-
fi-
les/5854534aee4eee4102f0bd5ca294791f/GEL_MV_RG_002_Notas_Arquitectura_Datos_V
5.2.pdf
[43] Harmon, P. “Business Process Methodologies”. BPTrends - Business Process Trends.
Volumen 5. Number 20. 2007
[44] Forster, F. “The Idea behind Business Process Improvement: Toward a Business Process
Improvement Pattern Framework”. BPTrends – Business Process Trends. 2006
[45] Kim, D., Kim, M., Kim, H. “Dynamic Business Process Management based on Process
Change Patterns”. International Conference on Convergence Information Technology. Pp:
1154 – 1161. 2007.
[46] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. “Pattern-Oriented
Software Architecture Volume 1: a system of patterns”. Wiley. Vol 1. Pp: 31. 1996
[47] United States Government. “US treasury architecture development guidance (TADG)”.
Sección 7. 2002. Disponible en: http://www.ustreas.gov/teaf/tadg.pdf.
[48] Monday, P. “Web Services Patterns: Java Edition”. Apress. 1 Edition. 2003
[49] Lawrence Pfleeger, S. “Software Engineering Theory and practice”. Beohm McCall
ISO Model. Prentice Hall. 2001.
[50] Boehm, B.W., Brown, J.R., Lipow, M. “Quantitative evaluation of software quality”.
International Conference on Software Engineering, Proceedings of the 2nd international con-
ference on Software engineering (2nd). Pp: 592-605. 1976.
[51] Grady, R., Caswell, D. “Software Metrics: Establishing a Company-wide Program”.
Prentice Hall. Pp: 159. 1987. ISBN 0138218447.
[52] ISO/IEC 9126-1. “Software engineering – product quality – Part 1: Quality Model”.
First edition. 2001.
[53] Dromey, R.G. “A model for software product quality”. IEEE Transactions on Software
Engineering 21. Volumen 2. 1995.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 68
[54] Fitzpatrick, R. “Software quality definitions and strategic issues”. Staffordshire Univer-
sity. 1996.
[55] Neil, M., Fenton, N. “Predicting software quality using bayesian belief networks”.
NASA/Goddard Space Flight Centre. 1996.
[56] Khosravi, K., Gueheneuc, Y.G. “A Quality Model for Design Patterns”. Technical Re-
port 1249. University of Montreal. 2004.
[57] Gamma, E., Helm, R., Johnson, R., Vlissides, J. “Design Patterns Elements of Reusable
Object-Oriented Software”. Addison-Wesley Pub Co. 1995
[58] Nagappan, R., Skoczylas, R., Sriganesh, R.P. “Developing Java Web Service: Architect-
ing and developing secure web services using java”. Wiley Publishing. ISBN 0-471-23640-3.
2003.
[59] Lakshminarayanan, S. “Oracle Web Services Manager: securing your web services”.
Packt publishing. First published. 2008. ISBN 978-1-847193-83-4.
[60] EURACHEM. “The Fitness for Purpose of Analytical Methods: A Laboratory Guide to
Method Validation and Related Topics”. EURACHEM Guide. 1998. Disponible en:
http://www.eurachem.ul.pt/
[61] Sistemas de gestión de la calidad. “Principios y vocabulario”. NMX-CC-9000-IMNC-
2001. 2001
[62] Gonzalez, Rafael A. "Validation of Crisis Response Simulation within the Design Sci-
ence Framework". ICIS 2009 Proceedings. Paper 87. 2009. Disponible en:
http://aisel.aisnet.org/icis2009/87
[63] Sistemas de gestión de la calidad. “Requisitos”. NMX-CC-9001-IMNC-2001. 2001
[64] Majewski, M., Han, Q., Wurster, A. “Business Process Validation”. University of
Augsburg. 2009
[65] Khatri, V., Vessey, I., Ramesh, V., Clay, P., Park, S. “Understanding conceptual sche-
mas: exploring the role of application and IS Domain knowledge”. Information Systems
Research. Vol. 17, Number 1. Pp: 81-99. 2006.
[66] Weber, I., Hoffmann, J., Mendling, J. “Semantic Business Process Validation”. In Proc.
of International workshop on Semantic Business Process Management. 2008.
[67] Clements, P., Kazman, R., Klein, M. “Evaluating software Architectures: methods and
case studies”. Addison-Wesley Professional. 1st edition. 2001.
[68] Clements, P., Kazman, R., Klein, M. “ATAM: Method for architecture evaluation –
Technical Report”. Technical Report . CMU/SEI-2000-TR-004. 2000.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 69
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[69] Davis, F.D. “User acceptance of information technology: system characteristics, user
perceptions and behavioural impacts”. International Journal of Man-Machine Studies. Vol-
ume 38. Pp: 475-487. 1993
[70] Davis, F.; Bagozzi, R.; and Warshaw, R. “User Acceptance of Computer Technology: A
Comparison of Two Theoretical Models”. Management Science. Volume 35. Pp: 982-1003.
1989
[71] Orantes Jiménez, S.D. “Viabilidad del Modelo de Aceptación de la Tecnología en las
empresas mexicanas. Una aproximación a las actitudes y percepciones de los usuarios de las
tecnologías de la información”. Revista Digital Universitaria. Volumen 12. Número 1. 2011.
ISSN: 1067-6079
[72] Sánchez Torres, C. “Registraduría está lista para el voto electrónico, pero han faltado
recursos”. Revista Electrónica Nuestra Huella Digital. Edición No. 57. Año V. 2011. Dispo-
nible en:
http://www.registraduria.gov.co/rev_electro/2011/rev_elec_nov/revista_nov2011.html#06
[73] Endrei, M., Ang, J., Arsanjani, A., Chua, S., Comte, P., Krogdahl, P., Luo, M., Newling,
T. "Patterns: Service-oriented architecture and web services". IBM. International Technical
support organization. 2004
IX – ANEXOS
1. Anexo A
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 70
Figura 21. Vista introductoria parte A.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 71
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Figura 22. Vista introductoria parte B
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 72
Figura 23. Vista introductoria parte C
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 73
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Figura 24. Vista de la organización
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 74
Figura 25. Vista de co-operación de actor
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 75
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Figura 26. Vista del proceso de negocio parte A
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 76
Figura 27. Vista del proceso de negocio parte B
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 77
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Figura 28. Vista del proceso de negocio parte C
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 78
Figura 29. Vista de co-operación del proceso de negocio parte A
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 79
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Figura 30. Vista de co-operación del proceso de negocio parte B
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 80
Figura 31. Vista de co-operación del proceso de negocio parte C
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 81
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Figura 32. Vista de co-operación del proceso de negocio parte D
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 82
Figura 33. Vista del comportamiento de la aplicación parte A
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 83
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Figura 34. Vista del comportamiento de la aplicación parte B
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 84
Figura 35. Vista del comportamiento de la aplicación parte C
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 85
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Figura 36. Vista del comportamiento de la aplicación parte D
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 86
Figura 37. Vista de infraestructura
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 87
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Figura 38. Estado actual de la registraduría municipal de Choachí para el voto
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 88
Figura 39. Estado ideal de la registraduría municipal de Choachí para el voto electrónico
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 89
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
2. Anexo B
CAPA DEL CLIENTE
Decorating Filter
/ Intercepting
Filter
Un objeto que está entre el cliente y los componentes Web. Este procesa
las peticiones y las respuestas.
CAPA DE PRESENTACION
Front Controller/
Front Component
Un objeto que acepta todos los requerimientos de un cliente y los direc-
ciona a manejadores apropiados. El patrón Front Controller podría divi-
dir la funcionalidad en 2 diferentes objetos: el Front Controller y el Dis-
patcher. En ese caso, El Front Controller acepta todos los requerimientos
de un cliente y realiza la autenticación, y el Dispatcher direcciona los
requerimientos a manejadores apropiada.
Service To Wor-
ker
Es como el patrón de diseño MVC con el Controlador actuando como
Front Controller pero con una cosa importante: aquí el Dispatcher (el
cual es parte del Front Controller) usa View Helpers a gran escala y ayu-
da en el manejo de la vista.
Dispatcher View Es como el patrón de diseño MVC con el controlador actuando como
Front Controller pero con un asunto importante: aquí el Dispatcher (el
cual es parte del Front Controller) no usa View Helpers y realiza muy
poco trabajo en el manejo de la vista. El manejo de la vista es manejado
por los mismos componentes de la Vista.
CAPA DE NEGOCIO
Business Delega-
te
Un objeto que reside en la capa de presentación y en beneficio de los
otros componentes de la capa de presentación llama a métodos remotos
en los objetos de la capa de negocios.
Value List Han-
dler/ Page-by-
Page Iterator/
Paged List
Es un objeto que maneja la ejecución de consultas SQL, caché y proce-
samiento del resultado. Usualmente implementado como beans de se-
sión.
Service Locator Consiste en utilizar un objeto Service Locutor para abstraer toda la utili-
zación JNDI y para ocultar las complejidades de la creación del contexto
inicial, de búsqueda de objetos home EJB y recreación de objetos EJB.
Varios clientes pueden reutilizar el objeto Service Locutor para reducir
la complejidad del código, proporcionando un punto de control.
CAPA DE PERSISTENCIA
Service Activator Se utiliza para recibir peticiones y mensajes asíncronos de los clientes.
Cuando se recibe un mensaje, el Service Activator localiza e invoca a los
métodos de los componentes de negocio necesarios para cumplir la peti-
ción de forma asíncrona.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 90
Value Object/
Data Transfer
Object/ Replicate
Object
Un objeto serializable para la transferencia de datos sobre la red.
Aggregate Entity
/ composite entity
Un bean entidad que es construido o es agregado a otros beans de enti-
dad.
Tabla 24. Descripción de los patrones de Web Services
3. Anexo C
Entidad Elector
Num_cedula (PK) Integer
Nombres Varchar(50)
Apellidos Varchar(50)
Lugar_exp_ced Varchar(50)
Direccion_residencia Varchar(50)
Teléfono Integer
Es_jurado Boolean (1)
Tabla 25. Elector
Entidad Inicio_Proceso_electoral
Fecha_inicio Date
Hora_inicio Time
Num_proc_elec (PF) Integer
Tabla 27. Inicio proceso Electoral
Entidad Cierre_Proceso_electoral
Fecha_cierre Date
Hora_cierre Time
Num_proc_elec (PF) Integer
Tabla 26. Cierre proceso electoral
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 91
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Entidad Proceso_electoral
Nombre_proc_elec Varchar(50)
Num_proc_elec (PK) Integer
Tabla 28. Proceso electoral
Entidad Municipio
Cod_mpio (PK) Integer
Nom_mpio Varchar (50)
Cod_dpto (PF) Integer
Num_hab Integer
Tabla 29. Municipio
Entidad Inscripcion_elector
Num_form_insc_elector (PK) Integer
Ultimo_lugar_votacion Varchar (50)
Num_cedula (F) Integer
Cod_mpio (PF) Integer
Cod_dpto (PF) Integer
Entidad Departamento
Cod_dpto (PK) Integer
Nombre_dpto Varchar (50)
Prom_votantes NUMERIC (9,2)
Pot_elect Integer
Region Varchar(50)
Tabla 30. Departamento
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 92
Num_proc_elec (PF) Integer
Num_proc_elec1 (PF) Integer
Tabla 31. Inscripción elector
Entidad Inscripcion_candidato
Num_form_insc_candidato (PK) Integer
Certificado_residencia_notarial Boolean (1)
Num_cedula (F) Integer
Cod_mpio (PF) Integer
Cod_dpto (PF) Integer
Num_proc_elec (PF) Integer
Num_proc_elec1 (PF) Integer
Id_cargo (PF) Integer
Ultimo_lugar_votacion Varchar (50)
Num_aval (PF) Integer
Tabla 32. Inscripción candidato
Entidad Cargo_Candidato
Id_cargo Integer
Nombre_cargo Varchar (50)
Tabla 33. Cargo candidato
Entidad Aval
Fecha_aval Date
Hora_aval Time
Num_tipo (FK) Integer
Num_aval (PK) Integer
Num_partido (FK) Integer
Tabla 34. Aval
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 93
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Entidad Partido_politico
Num_partido Integer
Nombre_partido Varchar (50)
Tabla 35. Partido político
4. Anexo D
Entidad Puesto
Cod_pto (PK) Integer
Nombre_pto NVarchar
Cod_mpio1 (PF) Integer
Cod_dpto1 (PF) Integer
Zona Integer
Tabla 37. Puesto
Entidad Mesa
Num_mesa (PK) Integer
Pot_votantes Integer
Cod_pto1 (PF) Integer
Cod_mpio1 (PF) Integer
Cod_dpto1 (PF) Integer
Tabla 38. Mesa
Entidad Tipo_Aval
Num_tipo Integer
Nombre_aval Varchar (50)
Tabla 36. Tipo Aval
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 94
Entidad Boletín
Numero_boletin (PK) Integer
Hora Time
Fecha Date
Num_mesa (PF) Integer
Cod_pto1 (PF) Integer
Cod_mpio1 (PF) Integer
Cod_dpto1 (PF) Integer
Mesa_informadas Integer
Id_corporacion (F) Integer
Tabla 39. Boletín
Entidad Cargo_jurado
Id_cargo (PK) Integer
Nombre_cargo Varchar (50)
Tabla 40. Cargo jurado
Entidad Jurado
Material Varchar
Hora_entrada Time
Hora salida time
Id_cargo (PF) Integer
Fecha Date
Tabla 41. Jurado
Entidad Participantes
Cedula (PK) Integer
Nombre Varchar(50)
Num_participante Integer
Tabla 42. Participantes
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 95
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Entidad Otro_tipo
Id_otrotipo (PK) Integer
Nombre_puesto Varchar(50)
Tabla 43. Otro tipo
La entidad inscrip se crea como una copia de la entidad inscripción_elector solo que no con la
totalidad de los atributos.
Entidad Inscrip
Num_mesa (PF) Integer
Cod_pto1 (PF) Integer
Cod_mpio1 (PF) Integer
Cod_dpto1 (PF) Integer
Num_cedula (F) Integer
Num_form_insc_elector (PK) Integer
Tabla 44. Inscrip
La entidad Inscripcion_candidato del modelo de votación es la misma entidad inscrip-
cion_candidato del modelo de inscripción, solo que no se dibujó con sus respectivas conexio-
nes para facilidad de entendimiento.
Entidad Candidato
Num_candidato (PK) Integer
Cod_partido (PF) Integer
Num_form_insc_candidato (F) Integer
Cod_mpio (F) Integer
Cod_dpto (F) Integer
Id_cargo (F) Integer
Num_aval (F) Integer
Tabla 45. Candidato
La entidad partido se duplica ya que en el momento de la jornada de votación pueden haberse
realizado alianzas que no estaban cuando se realizó la inscripción pero que posteriormente se
efectuaron bajo coordinación de la registraduría en su sede central (Bogotá).
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 96
Entidad Partido
Cod_partido (PK) Integer
Nombre partido Varchar (50)
Tabla 46. Partido
Entidad Candidato_consulta
Cod_candidato_con (PK) Integer
Tabla 47. Candidato consulta
Entidad Voto_alcaldia
Cod_partido (PF) Integer
Num_candidato (PF) Integer
Tabla 48. Voto alcaldía
Entidad Voto_Concejo
Cod_partido (PF) Integer
Num_candidato (PF) Integer
Tabla 49. Voto concejo
Entidad Voto_consulta
Cod_candidato_con (PF) Integer
Tabla 50. Voto consulta
Entidad Voto
Num_voto (PK) Integer
Voto_blanco Boolean (1)
Num_mesa (PF) Integer
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 97
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Cod_pto1 (PF) Integer
Cod_mpio1 (PF) Integer
Cod_dpto1 (PF) Integer
Id_corporacion (PF) Integer
Fecha Date
hora Time
Tabla 51. Voto
La tabla Corporación se crea para poder facilitar la consulta de boletines. El término de cor-
poración se da para los cargos a escoger que hallan: presidencia, referendos, consultas parti-
distas, alcaldía, concejo, gobernación, asamblea, cámara y senado.
Entidad Corporacion
Id_corporacion (PK) Integer
Tipo_corporacion Varchar (50)
Tabla 52. Corporación
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 98
5. Anexo E
Figura 40. Modelo BPMN del proceso electoral
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 99
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Figura 41. Modelo BPMN del subproceso de inscripción
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 100
Figura 42. Modelo BPMN del subproceso de inscripción de candidatos
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 101
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Figura 43. Modelo BPMN del subproceso de inscripción de electores
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 102
Figura 44. Modelo BPMN del subproceso de votación
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 103
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Figura 45. Modelo BPMN del subproceso de votación para alcaldía
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 104
Figura 46. Modelo BPMN del subproceso de votación para concejo
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 105
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
6. Anexo F
Validación Sintáctica realizada por el Ing. José C. Niño
Buenos días Daniel,
Primero que todo, es necesario entender que los modelos de madurez de arquitectura Empre-
sarial evalúan el nivel de capacidad que tiene una organización, para controlar y gerenciar
proyectos de este tipo.
Por esta razón muchos de los elementos de un modelo de madurez se pueden evaluar sola-
mente cuando el proyecto se encuentra en desarrollo o implementación.
En el modelo de madurez que propone el Carnegie-Mellon, el estado actual de su proyecto
puede evaluarse contra los parámetros del nivel 1 de Arquitectura Empresarial, el cual se
llama Estado inicial.
Dentro de este nivel, Se evalúan:
Arquitectura Empresarial:
Se debe garantizar que las definiciones se encuentren acordadas: Dentro del documento las
definiciones se encuentran especificadas y claramente documentadas, generalmente las defi-
niciones de los elementos las realizan los líderes funcionales.
Repositorio de Arquitectura Empresarial:
En este nivel puede que solamente el equipo de Arquitectura Empresarial tenga acceso al
Repositorio, siempre y cuando le brinde información al proyecto: Dentro del documento se
muestra claramente la notación y los puntos de vista (Archimate), los cuales especificaron
como insumo para el desarrollo de las aplicaciones.
Proceso de desarrollo de Arquitectura Empresarial:
En este nivel es suficiente con que el proceso sea utilizado por el equipo de Arquitectura
Empresarial: Dentro del documento se especifica que el proceso de desarrollo se Arquitectu-
ra se realizará utilizando la metodología ADM y el Framework TOGAF.
Objetivo de la Arquitectura Empresarial:
En este nivel se deben tener claros los dominios de los servicios, los principios y tener un
grado de detalle general de los elementos de la arquitectura Empresarial: Dentro de los
puntos de vista que se elaboraron dentro del documento, se pueden observar los servicios
planteados a nivel negocio, aplicaciones e infraestructura necesarios para continuar con el
proceso de desarrollo de la Arquitectura.
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 106
En conclusión, considero que la propuesta actual de proyecto de Arquitectura Empresarial
se encuentra en la etapa inicial y que es un buen insumo para el desarrollo del mismo.
Le recomiendo que haga énfasis en puntos de vista en los cuales pueda detallar un poco más
aspectos de seguridad de la solución y que el cálculo de los costos sea justificado por una
metodología que le permita tener más claros los valores esperados del proyecto (Especial-
mente para el desarrollo de las Aplicaciones).
Por otra parte, es necesario que el municipio o el líder del proyecto tenga en cuenta que
necesita un repositorio para el proyecto y herramientas que soporten TOGAF, Archimate y
los elementos de Arquitectura y diseño de Software necesarios para la Arquitectura, diseño,
desarrollo y mantenimiento de los elementos que definan (tanto Arquitectura empresarial,
como de Software).
Con respecto a su solicitud de dar una calificación a cada uno de los siguientes elementos,
considero que deben tener la siguiente nota:
Coherencia en los conceptos de arquitectura empresarial (5.0)
Los conceptos de Arquitectura expuestos en el documento concuerdan con los defini-
dos en los estándares internacionales.
Representación de los Procesos del voto de la registraduría municipal de Choachí
(5.0)
Aunque no conozco los procesos definidos por el municipio (El cual debe realizar la
validación), se encuentran correctamente diseñados y documentados desde el punto
de vista del lenguaje de notación.
Contenido (4.5)
Aunque desde el punto de vista de notación de las vistas y puntos de vista el docu-
mento es completo, creo que puede mejorarse con elementos de la metodología y del
Framework de Arquitectura Empresarial.
Calidad del documento.(4.8)
Aunque considero que le faltan algunos de los elementos relacionados en el numeral
anterior, la calidad del documento presentado es alta.
Cordialmente,
Ing. José Niño.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 107
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
7. Anexo G
Validación Semántica realizada por el Registrador municipal de Choachí, Dr. Jorge A.
Díaz
Ingeniero Daniel Yesid Cáceres Rincón:
Reciba Cordial Saludo.
Analizando el documento de arquitectura empresarial con respecto al funcionamiento y aná-
lisis de los procesos de la registraduría municipal para el voto, presento la validación solici-
tada en los parámetros asignados por el Ingeniero Daniel Cáceres:
Identificación y Representación de la registraduría municipal dentro del documento:
(4.8)
o El documento representa una situación futura de la registraduría municipal
manteniendo su misión y visión, sin vulnerar su identidad ni perder su esen-
cia con la propuesta enseñada.
Identificación y Representación de los Procesos del voto dentro del documento: (5.0)
o Dentro del contenido del documento se aprecia claramente los procesos ac-
tuales, los sugeridos y la función de los mismos propuestos por el ingeniero;
Manteniendo coherencia con lo que el ingeniero identifico como línea estra-
tégica del voto electrónico dentro de su propuesta.
Contenido del documento: (4.8)
o El contenido y tamaño del documento es adecuado para la explicación de la
propuesta de arquitectura empresarial desarrollada por el ingeniero Daniel
Cáceres
Calidad del documento: (5)
o El documento es coherente en todas sus descripciones sin llegar a ser dema-
siado extenso. La calidad desde el punto de vista gramatical y conceptual es
correcta.
Claridad del documento: (4.8)
o El documento de arquitectura empresarial presenta la descripción clara de
todos los elementos contenidos sin necesidad de recurrir a tecnicismos de di-
fícil comprensión para ubicar a cualquier lector que no sea solo del área de
ingeniería.
Atentamente,
Jorge Alberto Díaz Duque
Registrador Municipal del Estado Civil
Choachí, Cundinamarca
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 108
8. Anexo H
Casos de uso Atributo de cali-
dad asociado al
requerimiento
inicial. El que
más prima
Proceso de
negocio que se
relaciona con
dicho requeri-
miento
Elementos de
arquitectura
que intervie-
nen en el
sistema.
Escenarios más
relevantes al
interior
Almacenar for-
mularios en DB
Modularidad Aplicación Re-
gistro candidato
Service Fac-
tory Pattern
Esc1: Al momen-
to de ingresar el
formulario otro
usuario desea
consultarlo y
modificarlo al
mismo tiempo
Esc2: En caso de
migrarse la DB a
la que acceden los
servicios
Almacenar regis-
tro candidatos en
DB
Modularidad Aplicación Re-
gistro candidato
Service Fac-
tory Pattern
Esc1: Al momen-
to de ingresar el
registro, otro
usuario desea
consultarlo y
modificarlo al
mismo tiempo
Esc2: Al momen-
to de ingresar el
registro, otro
usuario desea
consultarlo y
modificarlo al
mismo tiempo
Almacenar regis-
tro electores en
DB
Modularidad Aplicación Re-
gistro elector
Service Fac-
tory Pattern
Esc1: La creación
de un registro de
elector que ya
existe
Almacenar repor-
tes
Capacidad de ex-
pansión
Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Esc1: Antes de
haber cerrado la
jornada de ins-
cripciones de
candidatos o de
electores, se re-
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 109
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
quiere tener un
informe sobre los
registros efectua-
dos
Almacenar con-
teo preliminar
Capacidad de ex-
pansión
Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Esc1: Antes de
haber cerrado la
jornada de vota-
ciones se requiere
tener un informe
sobre los votos
hasta ahora escru-
tados
Almacenar votos
del sistema
Simplicidad Aplicación vo-
tación
Business Pro-
cess
Esc1: Se da inicio
a la jornada de
votación y se
presenta un elec-
tor que no está
inscrito en el
municipio
Bajar Servicio
Jornada de Vota-
ción
Tolerancia al error Aplicación vo-
tación
Business Pro-
cess
Esc1: Se presen-
tan altercados de
orden público en
el puesto de vota-
ción y se requiere
bajar los servicios
antes de la hora
estipulada
Bajar Servicio
Post-Elección
Tolerancia al error Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Esc1: Alternados
de orden público
mientras se hace
el conteo de los
votos
Bajar servicio de
validación biomé-
trica y código de
barras
Tolerancia al error Aplicación vo-
tación
Business Pro-
cess
Esc1: El sistema
SAGEM tiene
fallos o hay re-
portes de error del
sistema SAGEM
Cerrar Jornada
Post-Elección
Operatividad Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Esc1: El servicio
jornada de vota-
ción fue abierto
después de su
cierre
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 110
Cerrar Jornada de
Votación
Operatividad Aplicación vo-
tación
Business Pro-
cess
Esc1: Intento de
ingreso de datos a
la aplicación des-
pués de cerrada la
jornada
Cerrar Proceso
De Inscripciones
candidatos
Operatividad Aplicación Re-
gistro candidato
Service Fac-
tory Pattern
Esc1: Intento de
ingreso del nuevo
registro de candi-
dato después de
cerrar el proceso
CerrarProcesoDe
Inscripciones
electores
Operatividad Aplicación Re-
gistro elector
Service Fac-
tory Pattern
Esc1: Intento de
ingreso del nuevo
registro de elector
después de cerrar
el proceso
Crear DB de re-
portes
Modularidad Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Esc1: Se necesita
una nueva base de
datos para una
nueva jornada
electoral.
Crear DB de vo-
tos
Modularidad Aplicación vo-
tación
Business Pro-
cess
Esc1: Se necesita
una nueva base de
datos para una
nueva jornada
electoral
Crear formulario
E-24/E-26
Usabilidad Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Es1: Generar un
formulario de un
proceso no estipu-
lado
Crear una DB de
registro electores
Modularidad Aplicación Re-
gistro elector
Service Fac-
tory Pattern
Esc1: Intento de
copia de registro
de elector
Crear una DB de
registro candida-
tos
Modularidad Aplicación Re-
gistro candidato
Service Fac-
tory Pattern
Esc1: Un candi-
dato se va a regis-
trar como elector
en otro municipio
Generar certifica-
do electoral
Expendability Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Esc1: Un usuario
que se inscribió
pero no votó re-
clame el certifi-
cado electoral
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 111
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Generar certifica-
do inscripción
alcaldía
Expendability Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Esc1: Un elector
que se inscribió
reclama el certifi-
cado de inscrip-
ción alcalde
Generar certifica-
do inscripción
concejo
Expendability Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Esc1: Un elector
que se inscribió
reclama el certifi-
cado de inscrip-
ción concejo
Generar certifica-
do inscripción
electoral
Expendability Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Esc1: Un elector
que no se inscri-
bió reclama el
certificado de
inscripción elec-
toral
Habilitar acceso a
la interface de
votación
Tolerancia al error Aplicación vo-
tación
Business Pro-
cess
Esc1: Un usuario
no registrado
intenta acceder a
la interface de
votación de forma
remota
Iniciar proceso
Inscripciones
candidatos
Usabilidad Aplicación Re-
gistro candidato
Service Fac-
tory Pattern
Esc1: Se realiza
la inscripción de
un candidato,
pero la registradu-
ría que la inscrip-
ción de electores
aún no había ini-
ciado
Iniciar Proceso
Inscripciones
Electores
Usabilidad Aplicación Re-
gistro elector
Service Fac-
tory Pattern
Esc1: Un candi-
dato desea ser
registrado con sus
datos de elector
Iniciar Jornada de
Votación
Tolerancia al error Aplicación vo-
tación
Business Pro-
cess
Esc1: Se intenta
iniciar la jornada
de votación sin
haber cerrado el
proceso de regis-
tro de candidatos
y registro de elec-
tores
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 112
Iniciar Servicio
Jornada Votación
Tolerancia al error Aplicación vo-
tación
Business Pro-
cess
Esc1: Se intenta
acceder al servi-
cio web de jorna-
da de votación sin
haber iniciado el
proceso jornada
votación
Iniciar Jornada
Post-Elección
Tolerancia al error Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Esc1: Se intenta
iniciar la jornada
post-elección sin
haber cerrado la
jornada de vota-
ción
Iniciar Servicio
Jornada Post-
Elección
Tolerancia al error Aplicación re-
sultado escruti-
nio
Business Pro-
cess
Esc1: Se intenta
acceder al servi-
cio web de jorna-
da post-elección
sin haber iniciado
el proceso jornada
post-elección
Iniciar servicio de
validación biomé-
trica y de código
de barras
Tolerancia al error Aplicación vo-
tación
Business Pro-
cess
Esc1: Se intenta
registrar un elec-
tor sin validar su
identidad
Monitorear el
sistema de vota-
ción
Tolerancia al error Aplicación vo-
tación
Business Pro-
cess
Esc1: Hay un
puesto de vota-
ción que está
fallando.
Validar el elector
en jornada de
votación
Generalidad Aplicación Re-
gistro elector
Service Fac-
tory Pattern
Esc1: Se presenta
un elector con
una cedula falsa y
pretende votar
Validar mediante
lector biométrico
y de código de
barras en jornada
de inscripción
Formación Aplicación vo-
tación
Service Fac-
tory Pattern
Esc1: Se presenta
un elector con
una cedula falsa y
pretende inscri-
birse.
Tabla 53. Casos de Uso y atributos de calidad para validación ATAM
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 113
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Patrón Service Factory Pattern
Caso de uso Almacenar formularios en DB
Lo que permite
el patrón
Permite utilizar el patrón me-
diador para mitigar las diferen-
cias entre servicios
Cuando el tiempo para una transición
llega usted podría configurar la factoría
para localizar el nuevo sistema de persis-
tencia de los datos
Situaciones
Excepcionales
Al momento de ingresar el
formulario otro usuario desea
consultarlo y modificarlo al
mismo tiempo
En caso de migrarse la DB a la que acce-
den los servicios
Justificación Las diferencias en los servicios
de consulta y de modificación
pueden ser mitigadas mediante
el patrón mediator
Lo formularios acceden a una factoría
que permite localizar el nuevo sistema de
persistencia de datos
Resultado Tanto las consultas como las
modificaciones pueden ser
realizadas desde dos usuarios
diferentes
El sistema se libera de tener dependencia
con respecto a la localización de la base
de datos y esto permite agilidad en futu-
ras migraciones de los sistemas de per-
sistencia
Tabla 54. Patrón Service Factory - CU Almacenar formularios en DB
Patrón Service Factory Pattern
Caso de uso Almacenar Registro candidatos
Lo que permite
Permite utilizar el patrón me-
diador para mitigar las diferen-
cias entre servicios
Implica que se deben mantener estánda-
res para permitir el desarrollo de interfa-
ces propias como para los clientes
Situaciones
Excepcionales
Al momento de ingresar el
registro, otro usuario desea
consultarlo y modificarlo al
mismo tiempo
Al momento de ingresar el registro, otro
usuario desea consultarlo y modificarlo
al mismo tiempo
Justificación
Las diferencias en acceso y
modificación pueden ser miti-
gadas mediante el patrón me-
diator
Mediante interfaces se puede independi-
zar el acceso a la consulta del registro y a
la modificación
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 114
Resultado
Tanto el acceso como las modi-
ficaciones pueden ser realizadas
desde dos usuarios diferentes
No restringe el rendimiento de un servi-
cio cuando acceda ya sea para consulta o
modificación
Tabla 55. Patrón Service Factory - CU Almacenar registro candidatos
Patrón Service Factory Pattern
Caso de uso Almacenar Registro Electores
Lo que permite Se podria usar para relacionar objetos de negocio con colecciones de obje-
tos
Situaciones
Excepcionales
La creación de un registro de elector que ya existe
Justificación El Service Factory permite establecer relaciones directas con la colección
de objetos creados previamente evitando crear redundancias en la capa de
persistencia
Resultado La aplicación del Service Factory permite bajos niveles de redundancia en
los registros de la base de datos
Tabla 56. Patrón Service Factory - CU Almacenar registro electores
Patrón Business Process (Composition) Pattern
Caso de uso Almacenar Conteo Preliminar
Lo que permite Tiene un tipo de modelo proxy para conectar las representaciones de datos a
través de una red y para acceder a los datos el cliente del web service debe
recrear el modelo de objeto en el servidor en su propio lenguaje
Situaciones
Excepcionales
Antes de haber cerrado la jornada de votaciones se requiere tener un infor-
me sobre los votos hasta ahora escrutados
Justificación Los clientes haciendo uso de las capacidades del patrón pueden generar
copias del modelo de objetos del servidor
Resultado Se pueden obtener copias temporales aprovechando el uso del patrón
Tabla 57. Patrón Business Process (Composition) - CU Almacenar conteo preliminar
Patrón Business Process (Composition) Pattern
Caso de uso Almacenar Reportes
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 115
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Lo que permite Tiene un tipo de modelo proxy para conectar las representaciones de datos a
través de una red y para acceder a los datos el cliente del web service debe
recrear el modelo de objeto en el servidor en su propio lenguaje
Situaciones
Excepcionales
Antes de haber cerrado la jornada de inscripciones de candidatos o de elec-
tores, se requiere tener un informe sobre los registros efectuados
Justificación Los clientes haciendo uso de las capacidades del patrón pueden generar
copias del modelo de objetos del servidor que contengan información sobre
los registros efectuados
Resultado Se pueden obtener reportes temporales aprovechando el uso del patrón
Tabla 58. Patrón Business Process (Composition) - CU Almacenar reports
Patrón Business Process (Composition) Pattern
Caso de uso Almacenar votos del sistema
Lo que permite Hay pasos o entradas en los proceso de negocio que involucran la coordina-
ción de procesos y actividades previas
Situaciones
Excepcionales
Se da inicio a la jornada de votación y se presenta un elector que no está
inscrito en el municipio
Justificación Para poder ejecutar el almacenamiento del voto de cualquier elector antes
que este acceda al sistema de votación se debe verificar en la base de datos
de inscripción de electores que el elector se halla inscrito en el municipio
Resultado El sistema almacena el voto siempre y cuando el elector haya sido validado
Tabla 59. Patrón Business Process (Composition) - CU Almacenar votos del sistema
Patrón Business Process (Composition) Pattern
Caso de uso Bajar Servicio Jornada de Votación
Lo que permite Un proceso de negocio en los servicios web es una composición de las acti-
vidades de negocio que pueden o no pueden ser otros servicios web. / La
intención del patrón es ilustrar y proveer una guía para combinar las activi-
dades de negocio en un único y consumible servicio web con una interface
bien definida
Situaciones
Excepcionales
Se presentan altercados de orden público en el puesto de votación y se re-
quiere bajar los servicios antes de la hora estipulada
Justificación Las actividades y procesos que componen la aplicación de votación deben
ser tenidas en cuenta para bajar el servicio de la jornada de votación
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 116
Resultado Los servicios que se encuentren en ejecución se cierran adecuadamente y
posteriormente el sistema cierra la aplicación de votación
Tabla 60. Patrón Business Process (Composition) - CU Bajar servicio jornada de votación
Patrón Business Process (Composition) Pattern
Caso de uso Bajar Servicio Post-Elección
Lo que permite La intención del patrón es ilustrar y proveer una guía para combinar las
actividades de negocio en un único y consumible servicio web con una
interface bien definida
Situaciones
Excepcionales
Alternados de orden público mientras se hace el conteo de los votos
Justificación Dado que se puede acceder mediante un único servicio web no importa que
el lugar de acceso al servicio no esté físicamente donde se presentan los
problemas de orden público y donde se encuentra la base de datos donde se
van a almacenar los datos
Resultado Se puede realizar el conteo de los votos desde otro lugar
Tabla 61. Patrón Business Process (Composition) - CU Bajar servicio post-elección
Patrón Business Process (Composition) Pattern
Caso de uso Bajar servicio de validación biométrica y código de barras
Lo que permite Hay pasos o entradas en los proceso de negocio que involucran la coordina-
ción de procesos y actividades externas
Situaciones
Excepcionales
El sistema SAGEM tiene fallos o hay reportes de error del sistema SAGEM
Justificación Si no se está usando la validación con el sistema SAGEM mantener cone-
xiones con dicho sistema baja el rendimiento
Resultado Mejoramiento del rendimiento
Tabla 62. Patrón Business Process (Composition) - CU Bajar servicios de validación biométrica y
código de barras
Patrón Business Process (Composition) Pattern
Caso de uso Cerrar Jornada Post-Elección
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 117
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Lo que permite Un proceso de negocio en los servicios web es una composición de las acti-
vidades de negocio que pueden o no pueden ser otros servicios web
Situaciones
Excepcionales
El servicio jornada de votación fue abierto después de su cierre
Justificación Para poderse cerrar la jornada post-elección tuvo que haberse ejecutado el
servicio jornada post-elección que depende directamente de haber cerrado
el servicio jornada de votación
Resultado El sistema anularía cualquier modificación realizada sobre la base de datos
después de la primera fecha de cierre del servicio jornada de votación
Tabla 63. Patrón Business Process (Composition) - CU Cerrar jornada post-elección
Patrón Business Process (Composition) Pattern
Caso de uso Cerrar Jornada de Votación
Lo que permite Hay pasos o entradas en los proceso de negocio que involucran la coordina-
ción de procesos y actividades externas
Situaciones
Excepcionales
Intento de ingreso de datos a la aplicación después de cerrada la jornada
Justificación El hecho de realizar el cierre de la jornada evita fraudes en la jornada elec-
toral ya que esta acción de cierre de la jornada funcionara como impedi-
mento de seguridad ante los próximos eventos de ingreso de datos después
de cerrada la jornada
Resultado El sistema no permite ingresos de nuevos registros a la base de datos una
vez cerradas las jornadas electorales
Tabla 64. Patrón Business Process (Composition) - CU Cerrar jornada de votación
Patrón Service Factory Pattern
Caso de uso Cerrar Proceso De Inscripciones candidatos
Lo que permite Aislar la selección de servicios y la lógica de instanciación
Situaciones
Excepcionales
Intento de ingreso del nuevo registro de candidato después de cerrar el pro-
ceso
Justificación Usando el patrón Service Factory se facilita la restricción de acceso al ser-
vicio web, en este caso sería el servicio de registro de candidato, por lo
tanto no habría forma de ingresar nuevos registros de candidatos
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 118
Resultado El sistema no permite después del cierre del proceso el almacenamiento de
nuevas inscripciones o modificaciones del candidato
Tabla 65. Patrón Service Factory - CU Cerrar proceso de inscripciones candidatos
Patrón Service Factory Pattern
Caso de uso Cerrar Proceso De Inscripciones electores
Lo que permite Aislar la selección de servicios y la lógica de instanciación
Situaciones
Excepcionales
Intento de ingreso del nuevo registro de elector después de cerrar el proceso
Justificación Usando el patrón Service Factory se facilita la restricción de acceso al ser-
vicio web, en este caso sería el servicio de registro de elector, por lo tanto
no habría forma de ingresar nuevos registros de electores
Resultado El sistema no permite después del cierre del proceso el almacenamiento de
nuevas inscripciones de elector
Tabla 66. Patrón Service Factory - CU Cerrar proceso de inscripciones electores
Patrón Business Process (Composition) Pattern
Caso de uso Crear DB de reportes
Lo que permite Una faceta del proceso de negocio direcciona la estructura de un proceso de
negocio y la otra faceta direcciona como estandarizar las interfaces para los
proceso de negocio
Situaciones
Excepcionales
Se necesita una nueva base de datos para una nueva jornada electoral
Justificación El hecho de crear una nueva base de datos no afecta la estructura lógica del
proceso de negocio
Resultado La BD creada es fácilmente direccionable por los servicios gracias al mane-
jo del patrón business process composition
Tabla 67. Patrón Business Process (Composition) - CU Crear DB de registro
Patrón Business Process (Composition) Pattern
Caso de uso Crear DB de votos
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 119
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Lo que permite Una faceta del proceso de negocio direcciona la estructura de un proceso de
negocio y la otra faceta direcciona como estandarizar las interfaces para los
proceso de negocio
Situaciones
Excepcionales
Se necesita una nueva base de datos para una nueva jornada electoral
Justificación El hecho de crear una nueva base de datos no afecta la estructura lógica del
proceso de negocio
Resultado La BD creada es fácilmente direccionable por los servicios gracias al mane-
jo del patrón business process composition
Tabla 68. Patrón Business Process (Composition) - CU Crear DB de votos
Patrón Business Process (Composition) Pattern
Caso de uso Crear formulario E-24/E-26
Lo que permite El proceso de negocio es una abstracción de la lógica compleja de negocio
que consiste de uno o más actividades de negocio. La lógica y el flujo de las
actividades y el flujo que los datos toman a través de proceso de negocio
Situaciones
Excepcionales
Generar un formulario de un proceso no estipulado
Justificación El patrón permite ajustar dentro del flujo de los procesos de negocio que
actividad o subproceso puede ser automatizado como es el caso de un for-
mulario
Resultado El sistema no permite la generación de formularios que no estén definidos y
vinculados dentro del flujo de los procesos de negocio
Tabla 69. Patrón Business Process (Composition) - CU Crear formularios E-24/E-26
Patrón Service Factory Pattern
Caso de uso Crear una DB de registro candidatos
Lo que permite Cuando el tiempo para una transición llega usted podría configurar la facto-
ría para localizar el nuevo sistema de persistencia de los datos
Situaciones
Excepcionales
Un candidato se va a registrar como elector en otro municipio
Justificación El patrón permite hacer la replicación de datos gracias a a configuración de
una factoría para el registro desde la aplicación registro candidato a la apli-
cación registro elector
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 120
Resultado Cuando se cree la BD de candidato se permita replicar parte de la informa-
ción de este registro a la base de datos de electores. Por tanto el candidato
que desee registrarse como elector en otro municipio no lo podrá hacer
Tabla 70. Patrón Service Factory - CU Crear una DB de registro candidatos
Patrón Service Factory Pattern
Caso de uso Crear una DB de registro electores
Lo que permite Aislar la selección de servicios y la lógica de instanciación
Situaciones
Excepcionales
Intento de copia de registro de elector
Justificación Este patrón permite que solo la información que se usa en el servicio pueda
ser empleada para crear el registro del elector, evitando que esta informa-
ción pueda ser duplicada o solicitada en otro servicio externo como si lo
hace el registro candidato
Resultado Solo mediante el servicio de registrar elector se puede crear dicho registro
Tabla 71. Patrón Service Factory - CU Crear una DB de registro electores
Patrón Business Process (Composition) Pattern
Caso de uso Generar certificado electoral
Lo que permite Un proceso de negocio en los servicios web es una composición de las acti-
vidades de negocio que pueden o no pueden ser otros servicios web
Situaciones
Excepcionales
Un usuario que se inscribió pero no votó reclame el certificado electoral
Justificación Gracias al patrón se puede establecer que el servicio de generar certificado
sea una composición del servicio registrar elector y el servicio votación
Resultado El sistema no permite la generación de certificados electorales a personas
que no hayan sido registrados en el municipio para votar y que no hayan
realizado la acción de votar
Tabla 72. Patrón Business Process (Composition) - CU Generar certificado electoral
Patrón Business Process (Composition) Pattern
Caso de uso Generar certificado inscripción alcaldía
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 121
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Lo que permite Un proceso de negocio en los servicios web es una composición de las acti-
vidades de negocio que pueden o no pueden ser otros servicios web
Situaciones
Excepcionales
Un elector que se inscribió reclama el certificado de inscripción alcalde
Justificación Gracias al patrón se puede establecer que el servicio de generar certificado
sea una composición del servicio registrar candidato
Resultado El sistema no permite la generación de certificados de inscripción de candi-
dato a la alcaldía a personas que no hayan sido registrados como candidatos
Tabla 73. Patrón Business Process (Composition) - CU Generar certificado inscripción alcaldía
Patrón Business Process (Composition) Pattern
Caso de uso Generar certificado inscripción concejo
Lo que permite Un proceso de negocio en los servicios web es una composición de las acti-
vidades de negocio que pueden o no pueden ser otros servicios web
Situaciones
Excepcionales
Un elector que se inscribió reclama el certificado de inscripción concejo
Justificación Gracias al patrón se puede establecer que el servicio de generar certificado
sea una composición del servicio registrar candidato
Resultado El sistema no permite la generación de certificados de inscripción de candi-
dato al concejo a personas que no hayan sido registrados como candidatos
Tabla 74. Patrón Business Process (Composition) - CU Generar certificado inscripción concejo
Patrón Business Process (Composition) Pattern
Caso de uso Generar certificado inscripción electoral
Lo que permite Un proceso de negocio en los servicios web es una composición de las acti-
vidades de negocio que pueden o no pueden ser otros servicios web
Situaciones
Excepcionales
Un elector que no se inscribió reclama el certificado de inscripción electoral
Justificación Gracias al patrón se puede establecer que el servicio de generar certificado
sea una composición del servicio registrar elector
Resultado El sistema no permite la generación de certificados de inscripción electoral
a personas que no hayan sido registrados como electores
Tabla 75. Patrón Business Process (Composition) - CU Generar certificado inscripción electoral
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 122
Patrón Business Process (Composition) Pattern
Caso de uso Habilitar acceso a la interface de votación
Lo que permite Una faceta del proceso de negocio direcciona la estructura de un proceso de
negocio y la otra faceta direcciona como estandarizar las interfaces para los
proceso de negocio
Situaciones
Excepcionales
Un usuario no registrado intenta acceder a la interface de votación de forma
remota
Justificación El acceso de un usuario no registrado no está direccionado dentro de la
estructura del proceso de negocio, ni mucho menos estandarizado para usar
las interfaces del proceso
Resultado El sistema no permite el acceso del usuario no registrado
Tabla 76. Patrón Business Process (Composition) - CU Habilitar acceso a la interface de votación
Patrón Service Factory Pattern
Caso de uso Iniciar proceso Inscripciones candidatos
Lo que permite Permite utilizar el patrón mediador para mitigar las diferencias entres servi-
cios
Situaciones
Excepcionales
Se realiza la inscripción de un candidato, pero la registraduría que la ins-
cripción de electores aún no había iniciado
Justificación El patrón service factory da flexibilidad en la integración del patrón media-
tor
Resultado Dado el servicio de inscripción de candidato se pueda utilizar información
parcial de su registro para usarla en el registro de elector mediante el patrón
mediator
Tabla 77. Patrón Service Factory - CU Iniciar proceso inscripciones candidatos
Patrón Service Factory Pattern
Caso de uso Iniciar Proceso Inscripciones Electores
Lo que permite Aislar la selección de servicios y la lógica de instanciación
Situaciones
Excepcionales
Un candidato desea ser registrado con sus datos de elector
Justificación El hecho que un elector se registre no implica que tenga que hacer un regis-
tro como candidato, por lo tanto el registro para electores estará definido
dentro de la temporalidad de duración del proceso
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 123
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Resultado El servicio web que realiza el registro del elector crea solamente en la base
de datos de electores este registro
Tabla 78. Patrón Service Factory - CU Iniciar proceso inscripciones electores
Patrón Business Process (Composition) Pattern
Caso de uso Iniciar Jornada de Votación
Lo que permite Un proceso de negocio en los servicios web es una composición de las acti-
vidades de negocio que pueden o no pueden ser otros servicios web
Situaciones
Excepcionales
Se intenta iniciar la jornada de votación sin haber cerrado el proceso de
registro de candidatos y registro de electores
Justificación La jornada de iniciación de jornada de votación no se puede realizar si no se
ha llevado a cabo el proceso de registro de candidatos y de electores
Resultado El sistema no debe permitir el inicio de la jornada de votación
Tabla 79. Patrón Business Process (Composition) - CU Iniciar jornada de votación
Patrón Business Process (Composition) Pattern
Caso de uso Iniciar Servicio Jornada Votación
Lo que permite Una faceta del proceso de negocio direcciona la estructura de un proceso de
negocio y la otra faceta direcciona como estandarizar las interfaces para los
proceso de negocio
Situaciones
Excepcionales
Se intenta acceder al servicio web de jornada de votación sin haber iniciado
el proceso jornada votación
Justificación Debido a que no se ha iniciado el proceso de negocio de jornada votación
(elemento esencial de la estructura de proceso) no se puede dar cabida a
invocar el servicio web que permite iniciar la jornada de votación
Resultado No se permite invocar el servicio web
Tabla 80. Patrón Business Process (Composition) - CU Iniciar servicio jornada votación
Patrón Business Process (Composition) Pattern
Caso de uso Iniciar Jornada Post-Elección
Lo que permite Un proceso de negocio en los servicios web es una composición de las acti-
vidades de negocio que pueden o no pueden ser otros servicios web
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 124
Situaciones
Excepcionales
Se intenta iniciar la jornada post-elección sin haber cerrado la jornada de
votación
Justificación Hasta que no se ha cerrado la jornada de votación no se puede iniciar la
jornada post-elección
Resultado El sistema no debe permitir el inicio de la jornada post-elección
Tabla 81. Patrón Business Process (Composition) - CU Iniciar servicios jornada post-elección
Patrón Business Process (Composition) Pattern
Caso de uso Iniciar Servicio Jornada Post-Elección
Lo que permite Una faceta del proceso de negocio direcciona la estructura de un proceso de
negocio y la otra faceta direcciona como estandarizar las interfaces para los
proceso de negocio
Situaciones
Excepcionales
Se intenta acceder al servicio web de jornada post-elección sin haber inicia-
do el proceso jornada post-elección
Justificación Debido a que no se ha iniciado el proceso de negocio de jornada post-
elección (elemento esencial de la estructura de proceso) no se puede dar
cabida a invocar el servicio web que permite iniciar la jornada post-elección
Resultado No se permite invocar el servicio web
Tabla 82. Patrón Business Process (Composition) - CU Iniciar servicio jornada post-elección
Patrón Business Process (Composition) Pattern
Caso de uso Iniciar servicio de validación biométrica y de código de barras
Lo que permite Tiene un tipo de modelo proxy para conectar las representaciones de datos a
través de una red y para acceder a los datos el cliente del web service debe
recrear el modelo de objeto en el servidor en su propio lenguaje
Situaciones
Excepcionales
Se intenta registrar un elector sin validar su identidad
Justificación Dado que el patrón permite establecer la conexión con el servidor SAGEM
para la aplicación morphocheck mediante un modelo proxy, si no establece
la conexión el sistema no deberá permitir el registro de ningún elector
Resultado No se permite el registro del elector
Tabla 83. Patrón Business Process (Composition) - CU Iniciar servicio de validación biométrica y
código de barras
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Modalidad de Profundización
Página 125
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Patrón Business Process (Composition) Pattern
Caso de uso Monitorear el sistema de votación
Lo que permite Un proceso de negocio en los servicios web es una composición de las acti-
vidades de negocio que pueden o no pueden ser otros servicios web
Situaciones
Excepcionales
Hay un puesto de votación que está fallando
Justificación El patrón business process composition permite el uso a nivel de diseño de
patrones como el observer que son útiles para el monitoreo de los objetos
de negocio
Resultado La acción de monitorear refleja los puntos que tienen fallos en el sistema
Tabla 84. Patrón Business Process (Composition) - CU Monitorear el sistema de votación
Patrón Service Factory Pattern
Caso de uso Validar el elector en jornada de votación
Lo que permite Se podría usar para relacionar objetos de negocio con colecciones de obje-
tos
Situaciones
Excepcionales
Se presenta un elector con una cedula falsa y pretende votar
Justificación La identificación del usuario se maneja como un objeto de negocio el cual
se compara con la colección de objetos de negocio almacenados en el servi-
dor SAGEM de la aplicación morphocheck
Resultado El sistema para permitir la votación debe validar la identificación del elec-
tor
Tabla 85. Patrón Service Factory - CU Validar el elector en jornada de votación
Patrón Service Factory Pattern
Caso de uso Validar mediante lector biométrico y de código de barras en jornada de
inscripción
Lo que permite Se podría usar para relacionar objetos de negocio con colecciones de obje-
tos
Situaciones
Excepcionales
Se presenta un elector con una cedula falsa y pretende inscribirse
Ingeniería de Sistemas Grupo de Investigación ISTAR – PA111-01
Página 126
Justificación La identificación del usuario se maneja como un objeto de negocio el cual
se compara con la colección de objetos de negocio almacenados en el servi-
dor SAGEM de la aplicación morphocheck
Resultado El sistema para registrar al elector no permite la creación del registro si la
validación es falsa
Tabla 86. Patrón Service Factory - CU Validar mediante lector biométrico y código de barras en
jornada de inscripción