El objetivo de esta tesis doctoral fue desarrollar una propuesta metodológica basada en modelos para la generación de portales de gobierno electrónico que sirva de guía para el desarrollo de portales gubernamentales. Los portales web tienen la capacidad de ofrecer información, servicios y facilitan las transacciones, el éxito de estas funcionalidades depende del diseño de sus interfaces. Con modelos claros y precisos es posible diseñar e implementar interfaces funcionales, por este motivo se seleccionó como método de trabajo el enfoque MDA (Model Driven Architecture), basada en una arquitectura dirigidas por modelos. Con este enfoque se busca modelar las interfaces de usuario con lo que se logró minimizar y optimizar el tiempo horas-hombre que son necesarias para el diseño y construcción de portales de gobierno electrónico. Para validar la metodología se construyó una herramienta basada en las especificaciones de la metodología bajo la cual se desarrolló un portal de gobierno electrónico. Como resultado se obtuvo un portal de gobierno electrónico que cumple con los requisitos mínimos de usabilidad. Una vez aplicada y validada la propuesta la metodológica se concluye que es factible su uso tanto en portales de gobierno electrónico como en otros tipos de portales.

1. UNIVERSIDAD CENTRAL DE VENEZUELA
FACULTAD DE CIENCIAS
POSTGRADO EN CIENCIAS DE LA COMPUTACIÓN
Metodología para el desarrollo de portales de
gobierno electrónico bajo el enfoque MDA
Tesis Doctoral presentado ante la ilustre Universidad
Central de Venezuela por la MSc. Yaskelly Yedra, para
optar al título de Doctora en Ciencias de la
Computación mención ingeniería de software.
Tutor: Dr. Francisco Luengo
Caracas – Venezuela
Marzo 2015

4. A todos aquellos estudiantes e
investigadores que buscan profundizar más
sobre esta área de desarrollo web basado en modelos
A todos aquellos que buscan desarrollar
nuevas metodologías y portales web de una
manera más rápido siguiendo los estándares de la OMG
A ese ser especial que se tomo
el tiempo necesario para leer esta investigación

5. En cada una de las partes
que conforman un todo siempre está
inmerso Dios y el hombre como su instrumento.
Agradezco a Dios, y
a todas las personas que de
alguna manera me ayudaron a concluir
esta investigación, desde mi familia, amigos,
compañeros de trabajo y de estudio, secretarias, empleados,
profesores y especialmente los tutores y guías de esta investigación

6. YEDRA HERNÁNDEZ, YASKELLY YUBISAY. METODOLOGÍA PARA EL DESARROLLO
DE PORTALES DE GOBIERNO ELECTRÓNCO BAJO EL ENFOQUE MDA. Tesis doctoral
para optar al título de Doctora en Ciencias de la Computación. Universidad Central de Venezuela
(UCV). Caracas-Venezuela. 2015. 190 p.
RESUMEN
El objetivo de esta tesis doctoral fue desarrollar una propuesta metodológica basada en modelos
para la generación de portales de gobierno electrónico que sirva de guía para el desarrollo de
portales gubernamentales. Los portales web tienen la capacidad de ofrecer información, servicios
y facilitan las transacciones, el éxito de estas funcionalidades depende del diseño de sus interfaces.
Con modelos claros y precisos es posible diseñar e implementar interfaces funcionales, por este
motivo se seleccionó como método de trabajo el enfoque MDA (Model Driven Architecture),
basada en una arquitectura dirigidas por modelos. Con este enfoque se busca modelar las interfaces
de usuario con lo que se logró minimizar y optimizar el tiempo horas-hombre que son necesarias
para el diseño y construcción de portales de gobierno electrónico. Para validar la metodología se
construyó una herramienta basada en las especificaciones de la metodología bajo la cual se
desarrolló un portal de gobierno electrónico. Como resultado se obtuvo un portal de gobierno
electrónico que cumple con los requisitos mínimos de usabilidad. Una vez aplicada y validada la
propuesta la metodológica se concluye que es factible su uso tanto en portales de gobierno
electrónico como en otros tipos de portales.
Palabras clave: Arquitectura Dirigida por Modelos (MDA), generación de portales, interfaces de
usuario, gobierno electrónico.
Correo electrónico: yyedra@fec.luz.edu.ve

7. YEDRA HERNÁNDEZ, YASKELLY YUBISAY. METHODOLOGY FOR THE
DEVELOPMENT OF WEBSITES OF ELECTRÓNCO GOVERNMENT ABOUT THE
APPROACH MDA. Dissertation for the degree of Doctor of Computer Science. Universidad
Central de Venezuela (UCV). Caracas-Venezuela. 2015. 190 p.
ABSTRACT
The aim of this thesis was to develop a methodology based on models for the generation of e-
government portals that provide guidance for the development of government portals. Web portals
have the ability to provide information, services and facilitate transactions, the success of these
features depends on the design of their interfaces. With clear and accurate models is possible to
design and implement functional interfaces, for this reason it was selected as a working method the
MDA approach (Model Driven Architecture), based on a model-driven architecture. This approach
aims to model user interfaces so that it was possible to minimize and optimize the time man-hours
that are necessary for the design and construction of e-government portals. To validate the
methodology based tool specification methodology under which an e-government portal was
developed was built. As a result of e-government portal that meets the minimum requirements of
usability and accessibility was obtained. Once applied and validated the proposed methodology is
concluded that it is feasible to use both e-government portals and other portals.
key words: Model Driven Architecture (MDA), generation of portals, user interfaces, electronic
government.
Email: yyedra@fec.luz.edu.ve

8. Metodología para el desarrollo de portales de gobierno
electrónico bajo el enfoque MDA
Contenido
CAPÍTULO 1 Introducción........................................................................ 1
1.1. Motivación y justificación............................................................................................. 2
1.2. Planteamiento del problema.......................................................................................... 4
1.2.1. Requerimiento metodológico…………………………………………….…... 6
1.2.2. Interrogantes planteados………………………………………………….…... 7
1.2.3. Solución propuesta………………………………………………………….... 8
1.3. Objetivos....................................................................................................................... 9
1.4. Metodología de trabajo................................................................................................. 10
1.4.1. Relación de objetivo e instrumentos implementados…………………….…... 15
1.5. Estructura de la tesis doctoral........................................................................................ 16
CAPÍTULO 2 Fundamentos teóricos.…………………….……………... 19
2.1. Desarrollo de portales web……………………………………………........................ 19
2.1.1. Características de los portales web……………………………........................ 20
2.2. Ingeniería Dirigida por Modelos (MDE)…………………………………………….. 21
2.3. Arquitectura Dirigida por Modelos (MDA)………………………………………….. 22
2.3.1. Modelos de plataformas en MDA………………………………………….…. 23
2.3.2. Metamodelo – Meta Object Facility (MOF)…………………….……………. 25
2.3.3. Transformación de modelos - Query View Transformation
(QVT)……………………………………………………………………….… 27
2.3.4. Otros estándares……………………………………………………………… 33
2.4. Modelado de interfaces de usuario…………………………..……………………….. 35
2.4.1. Modelo de dominio (MD)…………………………….………………………. 35
2.4.2. Modelo de aplicación (MA)…………………………………….…………….. 35
2.4.3. Modelo de usuario (MU)…………………………..………………………….. 36

9. 2.4.4. Modelo de tarea (MT)…………………………………………………….…... 36
2.4.5. Modelo de dialogo (MD)……………………………………………….…….. 36
2.4.6. Modelo de presentación (MP)………………………………….……………... 37
2.5. Patrones de software……………………………………………………….………… 37
2.5.1. Patrones de análisis…...…………………………………………….………… 37
2.5.2. Patrones arquitectura……………………………………….…………………. 38
2.5.3. Patrones de diseño…………………………………..………………………… 38
2.5.4. Patrones de usabilidad………………………………………………..……….. 39
2.6. Gobierno electrónico…………………………………………………………….…… 41
2.6.1. Portales de gobierno electrónico……………………………………….……... 41
2.6.2. Tipos de portales de gobierno electrónico……………….…………….……... 43
2.6.3. Beneficios del gobierno electrónico……………………………..……………. 46
2.6.4. Modelos de madurez de gobierno electrónico………………………….…….. 48
2.6.5. Ingeniería de requisitos en portales de gobierno electrónico……………….… 51
CAPÍTULO 3 Situación actual de la investigación……………………... 53
3.1. Métodos de desarrollo de aplicaciones basado en MDA………………………….…. 54
3.1.1. OOHDMDA: An MDA approach for OOHDM…………………………….... 54
3.1.2. MIDAS: A Model-Driven Methodology……………………………………... 54
3.1.3. WebSA………………………………………………………….…………….. 55
3.1.4. MDE-UWE………………………………………………………….………... 56
3.1.5. Consistent and Adaptable W2000 Models…………………….……………… 57
3.1.6. MDHDM: Método de Desarrollo de Hipermedia Dirigido por
Modelos.………………….…………………………………………………... 57
3.1.7. OO-Method……………………………………………………………….…... 58
3.1.8. OOWS: Object Oriented Web-Solutions………………………….………….. 59
3.2. Herramientas de software libre más utilizadas en MDA……………………..………. 60
3.3. Herramientas de software comercial más utilizadas en MDA……………….………. 65
3.4. Interfaces de usuario basado en modelos…………………………….………………. 69
3.5. Estado actual del gobierno electrónico……………………..………………………… 70
3.6. Desarrollo de portales de gobierno electrónico dirigido por
modelos………………………………………….…………………………………… 72

10. CAPÍTULO 4: Metodología de desarrollo de portales de gobierno
electrónico bajo MDA 74
4.1. Metodología e ingeniería de software……………………………………………..…. 74
4.2. Modelo independiente de computación (CIM)…………………….………………… 75
4.3. Modelo independiente de plataforma (PIM)…………………………………………. 76
4.4. Modelo específico de plataforma (PSM)…………………………………….………. 76
4.5. Modelo específico de implementación (ISM)…………………………….………….. 77
4.6. Fases de la metodología de desarrollo de portales de gobierno electrónico bajo el
enfoque MDA………………………………………………………………………... 78
CAPÍTULO 5: Validación de la propuesta metodológica…………………. 81
5.1. Modelo Independiente de Computación (CIM)……………………………………… 81
5.1.1. Modelo de negocio……………………………………………………………. 82
5.1.2. Selección del modelos de madurez del gobierno electrónico………………... 83
5.1.3. Modelo de requisitos………………………………………………………….. 84
5.1.4. Validación y pruebas………………………………………………………….. 91
5.2. Modelo Independiente de Plataforma (PIM)…………………………………………. 91
5.2.1. Aplicación del modelo de madurez del gobierno electrónico………………… 92
5.2.2. Modelo de clase………………………………………………………………. 92
5.2.3. Modelo de navegación…………………………………………………...…… 103
5.3. Modelo Específico de Plataforma (PSM)……………………………………………. 104
5.4. Modelo Específico de Implementación (ISM)……………………………………….. 107
5.4.1. Implementación de la interfaz de usuario….…………………………………. 107
5.4.2. Validación del portal de gobierno electrónico………………………………... 108
5.4.3. Puesta en marcha…...…………………………………………………………. 109
CAPÍTULO 6: Modelador YCLY…………………………………………... 110
6.1. Análisis……………………………………………………………………………….. 110
6.1.1. Diagrama de caso de uso del Modelador YCLY…..………………………... 110
6.2. Diseño………………………………………………………………………………... 114

11. 6.2.1. Diagrama de paquete del Modelador YCLY.………………………………… 114
6.2.2. Diagramas de clases del Modelador YCLY.…..……………………………... 115
6.2.3. Diccionario de datos…...……………………………………………………… 117
6.2.4. Arquitectura del Modelador YCLY…………………………………………... 123
6.3. Implementación………………………………………………………………………. 126
6.3.1. Herramientas de desarrollo…………………………………………………… 126
6.3.2. Desarrollo de los patrones de usabilidad del Modelador YCLY...…………… 126
CAPÍTULO 7: Guía metodológica para el modelado y desarrollo de
portales de gobierno electrónico bajo el enfoque MDA….. 132
7.1. Requisitos del Modelador YCLY…………………………………………………….. 133
7.1.1. Requisitos de hardware……………………………………………………….. 133
7.1.2. Requisitos de software………………………………………………………... 133
7.1.3. Requisitos de recursos humanos……………………………………………… 133
7.1.4. Requisitos legales……………………………………………………………... 134
7.1.5. Requisitos funcionales………………………………………………………... 134
7.2. Guía de instalación del Modelador YCLY…………………………………………… 136
7.3. Módulos del Modelador YCLY……………………………………………………… 140
7.3.1. Módulo principal……………………………………………………………… 140
7.3.1.1. Módulo de configuración…………………………………………... 142
7.3.1.2. Módulo de crear un proyecto……………………………………….. 143
7.3.1.3. Módulo de abrir un proyecto……………………………………….. 156
7.3.1.4. Módulo de ayuda…………………………………………………… 157
7.3.1.5. Módulo de salir……………………………………………………... 159
CAPÍTULO 8: Resultados y aportes…………………...…………………... 160
8.1. Aportes de la metodología………………………………………………………….... 160
8.2. Ventajas de la metodología…………………………………………………………... 161
8.3. Publicaciones y ponencias………………………………………………….………… 161
8.3.1. Ponencia en congreso…………………………………………………………. 161
8.3.2. Revistas científicas……………………………………………………………. 162

12. 8.3.3. Capítulo de libro………………………………………………………………. 162
8.4. Proyectos de investigación generados………………………………………………... 162
8.5. Líneas de investigación generadas…………………………………………………… 163
8.6. Continuidad de esta investigación……………………………………………………. 163
8.7. Futuros trabajos………………………………………………………………………. 164
8.8. Vinculación con centros de investigación……………………………………………. 164
CONCLUSIONES…………………………………………………………... 167
REFERENCIAS……………………………………………………………. 169
APÉNDICE…………………………………………………………………. 181
APÉNDICE A: Instrumento de validación de requisitos….…………………… 181
APÉNDICE B: Evaluación heurística…….……………………………………… 188
APÉNDICE C: Productividad generada de la tesis doctoral..…………….…. 192
APÉNDICE D: Requisitos funcionales para portales de gobierno
electrónico………………………………………………………… 195
APÉNDICE E: Aplicabilidad del Generador de Patrones de Diseño
(GEPADI)…..……………………………………………………... 216
APÉNDICE F: Sistemas transparentes para gobierno electrónico eficientes 232

13. ÍNDICE DE FIGURAS
Fig. pp
1.1. Contexto de la investigación…….………………………..……………………… 12
2.1. Actuación (conceptual) de MDA……………………………………….…………. 23
2.2. Relación entre metamodelo, modelo y lenguaje…………………………………... 25
2.3. Transformación de modelos…………………………………………….………… 28
2.4. Notación del alcance que pueden tener las transformaciones……………….……. 30
3.1. Flujo de trabajo y artefactos del proceso de desarrollo de WebSA……………….. 56
3.2. Método OOWS………………….………………………………………………… 61
3.3. Enfoques, estándares y herramientas de software libre…………………............… 62
3.4. Enfoques, estándares y herramientas de software comercial….………….……..... 66
4.1. Elementos involucrados en el significado de “metodología” dentro de IS……….. 75
4.2. Metodología de desarrollo de portales de gobierno electrónico bajo el enfoque
MDA………………………………………...…………………….......................... 77
5.1. Modelo Independiente de Computación (CIM)…………………………………... 82
5.2. Modelo de caso de uso del portal genérico de gobierno electrónico……………… 86
5.3. Modelo Independiente de Plataforma (PIM)……………………………………… 92
5.4. Estructura del patrón “Info”………………………………………………...…….. 93
5.5. Estructura del patrón “Datos del Personal”……………………………………….. 96
5.6. Estructura del patrón “Formulario”……………………………………………….. 98
5.7. Estructura del patrón “Formulario BD”…………………………………………... 101
5.8. Diagrama de navegación………………………………………………………….. 104
5.9. Modelo Específico de Plataforma (PSM)………………………...……………….. 104
5.10. Modelo de interfaz………………………………………………………………… 106
5.11. Interfaz generada……………………………………………………….…………. 106
5.12. Modelo Específico de Plataforma (ISM)………………………………………….. 107
5.13. Implementación del portal generado…………………………………………...…. 108
6.1. Diagrama de caso de uso del Modelador YCLY………….…………….………… 111
6.2. Diagrama de paquete del Modelador YCLY……………………………………… 115
6.3. Diagrama estático del modelo casos de uso del Modelador YCLY………………. 116

14. Fig. pp
6.4. Diagrama estático del modelo de clases del Modelador YCLY…….…..………… 116
6.5. Diagrama estático del modelo de navegación del Modelador YCLY…………….. 117
6.6. Diagrama estático del modelo de interfaz del Modelador YCLY……….………... 118
6.7. Arquitectura de software del Modelador YCLY………………………………….. 125
6.8. Patrón de interacción System Status Feedback…………………………….…….……. 127
6.9. Patrón de interacción Warning………………………………...…………………..……. 128
6.10. Patrón de interacción Structured Text Entry……………………..……………………. 129
6.11. Patrón de interacción Step by Step…………………………………..………………….. 130
6.12. Patrón de interacción Multilevel Help……………………………………..…………… 131
7.1. Requisitos funcionales del Modelador YCLY………………..……………..…..... 136
7.2. Ventana de descarga de archivos necesarios para instalar el Modelador YCLY… 137
7.3. Ventana de instalación de componente de Microsoft .NET framework 4.0……… 137
7.4. Ventana de asistente de instalación del modelador YCLY……………………….. 138
7.5. Ventana de selección de directorio de instalación………………………………… 138
7.6. Ventana de confirmación de instalación…………………………………………... 139
7.7. Ventana de instalando Modelador YCLY………………………………………… 139
7.8. Ventana de instalación completada……………………………………………….. 140
7.9. Interfaz principal del Modelador YCLY………………………………………….. 141
7.10. Interfaz sin el mensaje de configuración de entorno……………………………… 142
7.11. Configuración del entorno………………………………………………………… 143
7.12. Crear nuevo proyecto……………………..……………………………………… 144
7.13. Plantilla 1………………………………………………………………………….. 146
7.14. Plantilla 2……………………………………………………………………….…. 147
7.15. Plantilla 3………………………………………………………………………..… 148
7.16. Plantilla 4………………………………………………………………………..… 148
7.17. Plantilla 5………………………………………………………………..………… 149
7.18. Información del proyecto…………………...………………………………….…. 149
7.19. Interfaz del modelo de caso de uso- CIM……………………………….………… 150
7.20. Interfaz de la descripción del icono del actor……………………………………... 151
7.21. Interfaz para seleccionar la relación entre clases……………………...………….. 152
7.22. Interfaz del icono de notas………………………………………………………… 152

15. Fig. pp
7.23. Modelo de clase…………………………………………………………………… 153
7.24. Modelo de navegación…………………………………………………………….. 154
7.25. Interfaz de hipervínculos………………………………………………………….. 155
7.26. Interfaz para seleccionar la clase………………………………………………….. 155
7.27. Modelo de interfaz………………………………………………………………… 156
7.28. Modelo de generar proyecto………………………………………………………. 157
7.29. Abrir un proyecto…………………...…………………………………………….. 158
7.30. Módulo de Ayuda…………………………………………………………………. 158

16. ÍNDICE DE TABLAS
Tabla pp
1.1. Redacción de objetivos e instrumentos implementados…….……..………………. 15
2.1. Beneficios del gobierno electrónico……………………………………...………… 47
2.2. Modelo de madurez del gobierno electrónico…………………………..…………. 50
4.1. Fases de la metodología de desarrollo de portales de gobierno electrónico bajo el
enfoque MDA…………………………………………………...…………………. 79
5.1. Modelo de madurez del gobierno electrónico………………….……….…………. 83
5.2. Especificación del caso de uso “Registrarse”…………………..……………….…. 86
5.3. Especificación del caso de uso “Transacción”…………………………………...… 87
5.4. Especificación del caso de uso “Participación”……………………………..…….. 88
5.5. Especificación del caso de uso “Consultar Información”……………..…………... 88
5.6. Especificación del caso de uso “Enviar correo”……………………..……………. 89
5.7. Especificación del caso de uso “Búsqueda”………..…………………………...… 90
5.8. Patrones de gobierno electrónico “Info”……………………..…..……..…………. 95
5.9. Patrones de gobierno electrónico “Datos del Personal”……..….………………..... 97
5.10. Patrones de gobierno electrónico “Formulario”………………….………..…...….. 99
5.11. Patrones de gobierno electrónico “FormularioBD”……………….……….…...…. 102
6.1. Especificación del Caso de Uso “Crear un proy”…………………….……….....… 111
6.2. Especificación del Caso de Uso “Abrir un proy”………………………………...… 112
6.3. Especificación del Caso de Uso “Import/Export proy”…………………………...... 112
6.4. Especificación del Caso de Uso “Configuración”…………………………….…..... 112
6.5. Especificación del Caso de Uso “Ayuda”……………………………….………...... 113
6.6. Ficha de dato de Lienzo.vb……………………………………………………..…... 118
6.7. Ficha de dato de Clase.vb………………………………………………….……..… 119
6.8. Ficha de dato de Actor.vb…………………………………………………..…….… 120
6.9. Ficha de dato de Casosuso.vb…………………………………………………...….. 120
6.10. Ficha de dato de Nota.vb……………………………………………………...……. 121
6.11. Ficha de dato de Relaciones.vb……………………………………………………... 121
6.12. Ficha de dato de Pagina.vb……………………………………………………...….. 121
6.13. Ficha de dato de Puntoinicio.vb………………..…………………………………… 122

17. Tabla pp
6.14. Ficha de dato de Formularioprincipal.vb………………...…………………………. 122
6.15. Ficha de dato de PropPropiedades.vb……………………………………………..... 123
6.16. Resumen de patrones de usabilidad aplicados al modelador YCLY……………….. 131
7.1. Definición de los iconos que se encuentran dentro de la interfaz del modelo de
caso de uso………………………………………………………………………….. 150
7.2. Definición de los iconos que se encuentran dentro de la interfaz del modelo de
clase……………………………………………………………………………….… 153
7.3. Definición de los iconos que se encuentran dentro de la interfaz del modelo de
navegación………………………………………………………………………….. 154

18. Introducción
La presente tesis doctoral propone una metodología para el desarrollo de portales de gobierno
electrónico bajo el enfoque de la Arquitectura Dirigida por Modelos (Model Driven Architecture -
MDA-) desarrollada por el OMG (Object Management Group). La Arquitectura Dirigida por
Modelo (MDA) es un concepto basado en modelos que se utiliza para el diseño, desarrollo e
implementación de software. Es importante destacar que dentro del desarrollo de software las
metodologías a seguir constituyen una parte fundamental en el éxito del producto final. Por tal
motivo se creó una metodología para el desarrollo de portales de gobiernos electrónico que a su
vez puede ser aplicada a otros dominios de estudio. Definiéndose dominio como el conjunto
mínimo de propiedades que describen con precisión una familia de problemas en que una
aplicación o sistema computacional está involucrado para su solución (Berard, 1992).
El proceso de desarrollo de software integra varias etapas fundamentales que van desde el análisis,
diseño, implementación, pruebas hasta su mantenimiento. Pero a todo este proceso se le suma el
diseño de las interfaces de usuario, medio de interacción entre el usuario y el software. Estas dos
áreas de conocimiento han generado diferentes enfoques para el desarrollo de portales web, entre
los que se destaca el diseño de interfaces bajo el enfoque de modelos. Este enfoque sugiere una
representación abstracta de todos y cada uno de los aspectos de un sistema, que toma en cuenta
desde los requisitos funcionales hasta sus componentes.
El propósito de esta tesis doctoral fue integrar el enfoque MDA con el enfoque de modelos utilizado
para el desarrollo de interfaces, de esta manera se creó una propuesta metodología para el diseño y
desarrollo de portales de gobierno electrónico. Incluyendo como engranaje las transformaciones

19. 2
que se dan entre los modelos propuestos, permitiendo generar de manera eficaz y eficientes portales
de gobierno electrónico.
1.1. Motivación y justificación
Cuando las aplicaciones de software son construidas con metodologías que no cubren los requisitos
necesarios para el análisis y diseño de los sistemas se presentan diferentes problemas y fallas, los
más comunes de estos problemas están asociados a la interoperabilidad, la usabilidad, la
portabilidad y la integridad. Para evitar estos problemas, los sistemas que se generen deben
establecer una perfecta sincronización entre los elementos requeridos y los estándares existentes
en el desarrollo de aplicaciones, de esta manera, se obtienen sistemas eficientes y eficaces que sean
consistentes con el diseño.
Los portales web no escapan a estos problemas, teniendo estos la capacidad de ofrecer información
y servicios, las interfaces de usuarios son las que permiten que se establezca el vínculo entre el
portal web y el usuario, y un mal diseño de estas interfaces puede dificultar el uso del sistema,
provocando que los usuarios se desinteresen en usar dichos portales.
El uso de modelos brinda la posibilidad de desarrollar aplicaciones de software que cumplan con
los requisitos de usuarios a través del diseño de interfaces. En el caso del diseño de portales web,
los modelos son una herramienta que permiten representar la realidad y las necesidades. Entre las
ventajas que se derivan de utilizar modelos para el diseño de interfaces de usuario (IU) se
encuentran: que pueden ofrecer descripciones más abstractas que las que se pueden alcanzar con
otros enfoques de desarrollo (Wiecha y Boies, 1990; Puerta y Maulsby, 1997); ahorran tiempo en
la elaboración de portales web y disminuyen el riesgo de desviarse de los requisitos funcionales.
Debido a las ventajas de la aplicación del enfoque de modelos en el análisis y diseño de software,
el OMG (Object Management Group) creó y estandarizó el enfoque de la MDA (Arquitectura
Dirigida por Modelos) la cual se define como un enfoque de desarrollo de software basado en
modelos que sirven para dirigir la comprensión, diseño, construcción, implementación, operación
y mantenimiento. La principal aportación que tiene la MDA es la independencia que plantea a la

20. 3
hora de separar la lógica del sistema con respecto a su plataforma de despliegue, pero siempre a
nivel de modelos. Otras de las aportaciones de la MDA son la orientación a la transformación de
modelos y el refinamiento bajo los principios de interoperabilidad, usabilidad, portabilidad e
integridad.
La MDA sirve para el desarrollo de modelos computacionales y es usada como estrategia clave
para entender y especificar una solución a los problemas de software. Está compuesta de
plataformas que permiten desarrollar modelos de software y por lo tanto, generan una disciplina a
partir de la descripción y automatización de aplicaciones de software, en donde los modelos que se
desarrollan presentan un lenguaje bien definido porque tienen una sintaxis propia y un significado
(semántica) que es apropiado para ser interpretado automáticamente por un computador.
La ventaja que tiene el enfoque de la MDA en el desarrollo de software, es que separa los modelos
de diseño, arquitectura y construcción con el fin de no interferir cuando se modifican o actualizan
algunos de esos modelos. En el modelo de diseño se encuentran los requisitos funcionales, mientras
que en el modelo de la arquitectura se plasman los no funcionales, esto hace que, cada una de las
partes del desarrollo de software sea independiente una de la otra. El hecho de que el modelo de
diseño sea independiente permite a los modelos de arquitectura y construcción, soportar los
cambios que se llevan a cabo en los requisitos funcionales.
Los portales web diseñados bajo este enfoque ofrecen un entorno en el que los desarrolladores
pueden diseñar e implementar IU de un modo que pueden especificar, visualizar, modificar y
documentar en cualquier momento del desarrollo sin que esto afecte el resto del diseño del portal
web. Esto se debe a que la MDA está compuesto por plataformas que trabajan de forma
independiente, es decir, que separa las especificaciones funcionales del sistema de la
implementación usando una plataforma tecnológica específica. Lo anterior es sustentado por
Szekely, Sukaviriya, Castells, Muthukumarasamy y Salcher (1996), quienes señalan que “MDA
ofrece la infraestructura necesaria para la automatización de las tareas relacionadas con los
procesos de diseño e implementación de IU”.

21. 4
Por otro lado, el enfoque MDA puede ser utilizado para la creación de metodologías que sirven
para diseñar e implementar IU de una manera sistemática ya que ofrece capacidades para:
 Modelar IU usando diferentes niveles de abstracción.
 Refinar los modelos de forma incremental.
 Reutilizar las especificaciones del IU.
Se necesitó crear una metodológica para desarrollar interfaces de usuario basada en modelos, que
permitió utilizar la tecnología disponible de una forma que integre todos los pasos que se llevan a
cabo para la generación de interfaces bajo el enfoque de la MDA. Para diseñar interfaces de usuario
con la MDA se siguen ciertas tareas: construcción de metamodelos, transformación de modelos,
utilización de lenguajes de programación que generan el código y al final la composición de los
modelos. Todos estos pasos se desarrollan de manera aislada utilizando herramientas específicas
para su construcción. Lo que se buscó con esta propuesta es desarrollar una metodología donde se
integren todas estas tareas.
1.2. Planteamiento del problema
Los modelos son descripciones que van en diferentes direcciones y niveles de abstracción que
recogen las características del sistema a diseñar, identificando tareas, perfiles de usuario y datos
que manipular. Por esta razón, con modelos claros y precisos es posible diseñar e implementar
portales web de calidad que posibiliten que dos o más componentes del sistema intercambien de
manera eficiente información. Por lo tanto, la meta de los diseñadores y desarrolladores de portales
debería ser que sus sistemas adopten tecnologías web eficientes y estandarizadas que satisfagan las
necesidades y expectativas de calidad.
Cuando se desarrollan portales web, el ingeniero de software cuenta con una diversidad de
métodos, modelos, aplicaciones y herramientas, lo que conlleva en muchas ocasiones a generar
interfaces híbridas, que son grandes y complejas, lo cual dificulta su mantenimiento y
modificación, particularmente cuando quien hace el mantenimiento o modificación no maneja en

22. 5
su totalidad los métodos, modelos, aplicaciones y herramientas utilizadas en el desarrollo. Por esta
razón, se hizo necesario plantear una metodología basado en los estándares de la OMG y que fuera
soportada en una herramienta.
Dentro de los diferentes tipos de portales web se encuentran los denominados portales de gobierno
electrónico que son utilizados por la administración pública. Los esfuerzos que se realizan en el
diseño de portales de gobierno electrónico se concentran principalmente en desarrollar aplicaciones
dirigidas a cuatro tipos de servicios: información, interacción, consulta y transacción, que para
Layne y Lee (2001) forman parte del modelo de madurez que ellos proponen. Mientras los tres
primeros tipos de servicios no exigen un reto tecnológico real, los servicios transaccionales son
mucho más difíciles de implementar. Un servicio transaccional podría permitir a los organismos
públicos, organismos privados y a los ciudadanos interactuar con instituciones gubernamentales
para ejecutar funciones específicas, con el fin de aumentar la tramitación burocrática, la
confiabilidad de las aplicaciones y satisfacer las necesidades de los usuarios a través de los servicios
ofrecidos; por ello, uno de los retos en el desarrollo de gobierno electrónico es diseñar portales
orientados a servicios transaccionales, que estén acordes con los estándares planteados por la
ingeniería de software para desarrollar interfaces de usuarios que sean coherentes con los principios
básicos de la interacción humano-computador; con el fin de construir aplicaciones confiables,
funcionales, eficaces y eficientes, y que a la vez sean fáciles de usar por los ciudadanos.
Portales eficientes y eficaces, que respondan tanto a las necesidades de la ciudadanía como a las
de la administración pública, y que a su vez muestren un ambiente de fácil navegación, necesitan
de diseños que cumplan con los requisitos mínimos de calidad (interoperabilidad, usabilidad,
portabilidad, integridad y facilidad en la búsqueda de información) y de seguridad en la ejecución
de transacciones.
Para desarrollar software que permitan construir portales de gobierno electrónico que cumplan con
estos requisitos es necesario crear una metodología propia y específica, que posibilite el diseño de
interacciones que sean apropiados para alcanzar una buena comunicación entre el ciudadano y los
sistemas computarizados. A pesar que existe una amplia diversidad de plataformas y tecnologías
para crear portales, esas tecnologías pueden violar diversos principios de la ingeniería de software

23. 6
que repercuten negativamente en su uso, tales como la falta de interoperabilidad, usabilidad,
portabilidad e integridad que se exigen en un sistema funcional y de calidad. Por ello, generar un
estándar de aplicaciones para gobierno electrónico, es un reto en sí mismo.
En el caso específico del desarrollo de portales de gobierno electrónico, es fundamental además de
tomar en cuenta aspectos técnicos de software y hardware, considerar los aspectos de diseño, tales
como la metodología y las herramientas de modelado (elementos, relaciones, diagramas, reglas
semánticas, mecanismo de aplicación común y otros) a fin de alcanzar sistemas con interfaces de
calidad que forme parte de un estándar global.
1.2.1. Requerimiento metodológico
Para diseñar y generar portales de gobierno electrónico, no existe un estándar metodológico a
seguir, es decir, no se cuenta con requisitos preestablecidos para el desarrollo de esos portales, ni
se cuenta con un entorno de desarrollo que cumplan con los principios de usabilidad, portabilidad
e interoperabilidad.
Por lo anteriormente expuesto, el desarrollo de esta tesis doctoral se justifica por la falta de
metodologías para el desarrollo de portales de gobierno electrónico, específicamente en el Estado
venezolano. En esta tesis doctoral se desarrolló una metodología para desarrollar portales de
gobierno electrónico bajo el enfoque de la MDA, este enfoque está basado en modelos, permitiendo
al ingeniero web trabajar en un mayor nivel de abstracción.
1.2.2. Interrogantes planteadas
Cuando se desarrolla una metodología se debe tener presente algunas interrogantes válidas, con el
propósito de servir de guía en el desarrollo de las aplicaciones; tales interrogantes refieren a los
niveles teóricos y metodológicos en la evaluación de requisitos. Por lo tanto, se plantean las
siguientes preguntas:

24. 7
 ¿Son las metodologías existentes, para desarrollar software, apropiadas para modelar
portales web bajo estándares?
 ¿Podría la Arquitectura Dirigida por Modelos (MDA) utilizarse para desarrollar una
metodología para generar portales de gobierno electrónico?
 ¿Podría una metodología creada bajo los principios de la Arquitectura Dirigida por Modelos
(MDA) ayudar a optimizar el tiempo de desarrollo de portales de gobierno electrónico?
 ¿Será posible crear un estándar particular para el desarrollo de portales de gobierno
electrónico utilizando la MDA? y sí es así, ¿podrá este estándar mejorar la usabilidad de
los portales creados?
 ¿Qué requisitos deberían considerarse para desarrollar un portal de gobierno electrónico
bajo el enfoque MDA?
 ¿Qué tipo de transformaciones son necesarias realizar para desarrollar portales de gobierno
electrónico bajo el enfoque MDA?
1.2.3. Solución propuesta
Por todo lo anteriormente expuesto se propuso la creación de una metodología específica para el
diseño de portales gobierno electrónico, bajo el enfoque de la Arquitectura Dirigida por Modelos
(MDA), con el objeto de proveer una guía a las organizaciones gubernamentales para los sistemas
de la administración pública.
Este trabajo ofrece una alternativa computacional para mejorar la interoperabilidad, la usabilidad,
la portabilidad y la integridad de los portales de gobierno electrónico, ya que esta metodología
permite el análisis, diseño, implementación y operación de portales de gobierno electrónico,
beneficiando a la administración pública en su propósito de desarrollar sistemas de gobierno
electrónico bajo estándares abiertos. De tal manera que al desarrollar componentes de sistemas para
gobierno electrónico en estándares abiertos, se tiene la habilidad de intercambiar información que
facilita la interoperabilidad entre los organismos públicos, organizaciones privadas y los
ciudadanos.

25. 8
Los beneficiarios de esta metodología son: a) los diseñadores de portales, porque ellos pueden
tomar los requisitos funcionales del portal gubernamental para generar y desarrollar sus propios
portales; b) los ingenieros de software por contar con una metodología para desarrollar interfaces
basadas en modelos estandarizados; c) la administración pública porque cuentan con una
metodología que puede establecer lineamientos para el diseño y manejo de portales de gobierno
electrónico que cumplan con los estándares de la W3C (World Wide Web Consortium), y con los
estándares de calidad de interoperabilidad, usabilidad, portabilidad e integridad; d) la ciudadanía,
porque una vez que la administración pública implemente la metodología, el ciudadano tendrá a su
disponibilidad un sistema usable dedicado a las transacciones cotidianas de los servicios públicos
que le facilitará la comunicación entre ellos y el Estado. En este sentido, Delgado (2007) define un
modelo de interfaz como una descripción (abstracción) de los aspectos que involucran el diseño y
desarrollo de una interfaz de usuario (IU), incluyendo cada uno de sus componentes.
Esta tesis doctoral está dirigida a los computistas especializados en el desarrollo de portales web,
a los ingenieros de modelo, ingenieros de requisitos y otros especialistas que pudieran estar
interesados en conocer y manejar las técnicas propias en el desarrollo de aplicaciones de software
para ambientes web y particularmente, a los diseñadores de portales de gobierno electrónico,
porque les servirá de guía para la construcción de estrategias de políticas públicas basadas en
tecnologías de información de ambientes web; y por último, a los ciudadanos interesados en el uso
de portales para interactuar con la administración del Estado.
1.3. Objetivos
Con la finalidad de desarrollar una metodología para construir portales de gobierno electrónico
bajo la Arquitectura Dirigida por Modelos, que pueda ser adoptada por la administración pública,
para contribuir con su propósito de implementar un modelo eficiente de administración
automatizada, en el desarrollo de portales de gobierno electrónico, se planteó el siguiente objetivo
general y los objetivos específicos que le dan soporte-

26. 9
Objetivo general
Desarrollar una metodología bajo el enfoque de la Arquitectura Dirigida por Modelos (MDA) para
construir portales de gobierno electrónico.
Objetivos específicos
Para cumplir con el objetivo general, se definieron una serie de objetivos específicos que se listan
a continuación:
 Diseñar una metodología bajo el enfoque MDA que permita generar portales de gobierno
electrónico.
 Definir los requisitos para portales de gobierno electrónico.
 Diseñar los patrones conceptuales a partir de modelos, para generar interfaces de usuario.
 Diseñar los modelos para especificar los requisitos en cada fase de la metodología.
 Aplicar las trasformaciones necesarias para convertir los diferentes modelos en un dominio
específico.
 Validar la metodología mediante la implementación de un portal de gobierno electrónico.
 Proveer una guía de usuario a las organizaciones gubernamentales para el manejo de
portales de gobierno electrónico a través del enfoque MDA.
1.4. Metodología de trabajo
La práctica de la ciencia se ve reflejada en la ingeniería, cuyo propósito práctico es generar
métodos, productos y soluciones reales a problemas del mundo real, por esta razón se puede decir
que la ingeniería tiene una naturaleza tecnológica (Chavarriaga, 2002). Por lo antes expuesto, se
puede decir que esta investigación fue de tipo tecnológica, ya que para crear el objeto de estudio
se aplicaron métodos y principios de las diversas ciencias y disciplinas para la creación,
construcción y mejoramiento de productos, utilizando en este caso tecnologías como MDA, UML
(Unified Modeling Language-UML-), XML (en inglés, Extensible Markup Language), XSLT

27. 10
(Extensible Stylesheet Language Transformations - XSLT), Visual Studio 2013, patrones
conceptuales, siendo paradigmas que contribuyen a la generación de nuevos conocimientos.
Marcos (2002), afirma que los problemas que pueden llegar a resolver la ingeniería de software
son de tipo ingenieril, en este sentido el objeto de estudio fue la creación de una metodología para
el desarrollo de portales de gobierno electrónico bajo el enfoque MDA.
La investigación también se puede considerar de tipo conceptual, ya que permite la integración de
conceptos tanto de la ingeniería de software como de interacción humano-computador en el
paradigma de MDA. Se manejaron las teorías de compiladores, base de datos y lenguaje de
restricciones, que están vinculados con la herramienta que soporta la metodología creada. Este tipo
de investigación se apoya en Granollers (2003) y Granollers, Lorés y Perdrix (2003).
El contexto de investigación que se aplica en esta tesis doctoral es el descrito por Klimosky (1985),
quien sostiene que los epistemólogos al referirse a la problemática del conocimiento científico,
consideran tres contextos, en donde esta tesis doctoral se refleja: 1) el contexto de descubrimiento;
2) el contexto de justificación y 3) el contexto de aplicación, tal como se observar en la figura 1.1.
Hacer una propuesta metodológica para desarrollar portales de gobierno electrónico bajo el enfoque
MDA que sea consecuencia de una investigación involucra procesos que son necesarios definir.
Por tanto, es ineludible comenzar por definir los contextos fundamentales que envolvieron esta
investigación.
1) El contexto de descubrimiento abarca todo lo relativo a la manera en que los científicos
arriban a sus conjeturas, hipótesis o afirmaciones. En este ámbito, Marcos (2002) define
dos áreas objeto y fenómeno. El objeto de estudio en la ingeniería de software, difiere del
objeto de estudio de las ciencias formales, humanas y naturales. Mientras las ciencias se
ocupan de estudiar objetos ya existentes, las ciencias de la ingeniería se ocupan de estudiar
los métodos y técnicas para la creación de nuevos objetos e incluso de crear estos métodos
y técnicas. Los objetos de estudio en esta investigación fueron las metodologías basadas en
MDA, las herramientas que manejan modelos y en los portales de gobierno electrónico.

28. 11
Los fenómenos de estudio se centraron en los lineamientos de gobierno electrónico, en la
transformación de modelos, en las interfaces de usuario y en los principios básicos de
usabilidad.
2) El contexto de justificación (figura 1.1) se basó en los métodos aplicados para
desarrollar la propuesta metodológica y sustentarla con teorías propias de la ingeniería de
software y la interacción humano-computador.
Figura 1.1. Contexto de la investigación
Adaptación del trabajo de Barchini (2006).
Los métodos de investigación en las ciencias de la computación son todas aquellas
estrategias lógicas, razonamientos matemáticos, procedimientos aplicados para la

29. 12
construcción de modelos, y otras tantas utilizadas en la ingeniería de software con el
propósito de formalizar el conocimiento ingenieril que permite crear modelos validos de
aplicaciones de software. Los métodos permiten investigar los fenómenos observables de
estudio nombrados anteriormente. Entre los métodos tenemos el enfoque de la MDA, las
metodologías de desarrollo de software y las metodologías de interfaces de usuario. Estos
métodos permitieron desarrollar y evaluar tanto la propuesta metodológica como la
herramienta en la cual se sustentó.
Las teorías sustentan el desarrollo de la nueva propuesta tecnológica. Las teorías estudiadas
en esta tesis doctoral abarcaron la ingeniería de software y la interacción humano-
computador. Se estudiaron también, los lenguajes de restricciones, las bases de datos y la
teoría de compiladores. Estás teorías fueron los pilares fundamentales para sustentar esta
investigación.
3) Como contexto de aplicación (o tecnológico) se ofrece una herramienta de trabajo
para las organizaciones gubernamentales que sirve de guía metodológica fundamentada en
la Arquitectura Dirigida por Modelos (MDA) para el desarrollo de portales de gobierno
electrónico. En este contexto se llevó a la práctica todos los conocimientos adquiridos en
relación con el diseño de interfaces que son presentados como un producto final para el
beneficio de la sociedad.
Instrumentos de aplicación:
1) Lenguaje de Modelado Unificado (Unified Modeling Language-UML-), el objetivo es
recoger e integral todos los requisitos funcionales y no funcionales de la propuesta, lo cual
va a ayudar definir conceptualmente los elementos de modelado a través de un
metamodelado formal.
2) Lenguaje de Marcas Extensibles - XML (en inglés, Extensible Markup Language),
empleado para poder realizar la exportación e importación de modelos, esto garantiza la
interoperabilidad de la herramienta aportada.

30. 13
3) Lenguaje Extensible de Hojas de Estilo - XSL (en inglés, Extensible Stylesheet Language),
es una familia de lenguajes basados en el estándar XML que permite describir cómo la
información contenida en un documento XML cualquiera es transformada o formateada
para su presentación en un medio. Entre los lenguajes que la conforman esta el XSLT
(Extensible Stylesheet Language Transformations).
4) Patrones conceptuales para diseñar y desarrollar los diferentes módulos de la metodología.
Entre los patrones conceptuales que se manejaron están los patrones de diseño, de
interacción o usabilidad y los de arquitectura.
5) Visual Studio 2013 para el desarrollo de la herramienta que validó la propuesta
metodológica.
Para la construcción de los modelos y las transformaciones de estos, mediante el enfoque de la
MDA, se emplearon los estándares de la OMG como: UML (Unified Modeling Language), MOF
(Meta Object Facility), QVT (Query View Transformation) y XMI (XML, Metadata Interchange).
Los pasos seguidos para la construcción de la metodología de desarrollo para portales de gobierno
electrónico bajo el enfoque MDA, fueron los siguientes.
1. Se realizó una investigación documental sobre los portales de gobierno electrónico y el
enfoque de Arquitectura Dirigida por Modelos (MDA).
2. Se analizaron y compararon las diferentes metodologías basadas en modelos para el
desarrollo de interfaces de usuario.
3. Se analizaron y compararon las diferentes metodologías aplicadas en el desarrollo de
interfaces de usuario bajo el enfoque MDA.
4. Una vez concluida el análisis de la situación actual de la investigación, se procedió a
construir una metodología que se adaptara a los lineamientos de calidad para crear portales
de gobierno electrónico bajo el enfoque MDA.
5. Se elaboró un caso genérico de portal de gobierno electrónico para poder explicar y
demostrar la propuesta metodológica bajo el enfoque MDA.
6. Se validó la propuesta metodológica a través del desarrollo de una herramienta de escritorio
que la sustentara, denominada Modelador YCLY, la cual siguió el ciclo de vida de
desarrollo de software tradicional: análisis, diseño e implementación.

31. 14
7. Se elaboró la guía metodológica para el modelado y desarrollo de portales de gobierno
electrónico bajo el enfoque MDA.
8. Se analizaron y discutieron los resultados, y en base a ellos se hicieron ciertas
recomendaciones para mejorar la herramienta que soporta la metodología que se propuso.
Por último se presentaron las conclusiones.
Para el desarrollo de las interfaces de usuario que componen el portal web se aplicaron los patrones
de interacción también conocidos como patrones de usabilidad. Así como los métodos de
hipermedia desarrollados por Korch (2000) que se centran en el modelado de hipermedia a partir
de modelos de clases. Se aplicó el método este método de hipermedia porque plantea la solución
de la navegación entre las diferentes interfaces, y de esta manera se puede modelar la interfaz final.
1.4.1. Relación de objetivos e instrumentos implementados
En la tabla 1.1 se puede observar las relaciones entre los objetivos específicos de la tesis y los
instrumentos que se implementaron, entre los cuales se observan herramientas o métodos según
sea el objetivo.
Tabla 1.1. Relación de objetivos e instrumentos implementados
Objetivos Herramienta o método
 Diseñar una metodología bajo el
enfoque MDA que permita generar
portales de gobierno electrónico.
Estudio documental sobre las diferentes
metodologías que existen en la ingeniería de
software para el desarrollo de modelo.
 Definir los requisitos para portales
de gobierno electrónico.
Aplicación de modelo de caso de uso de UML.
 Diseñar los patrones conceptuales a
partir de modelos, para generar
interfaces de usuario.
Desarrolló de una herramienta llamada GEPADI
(Generador de Patrones de Diseño) para generar
patrones de diseño de gobierno electrónico.
 Diseñar los modelos para especificar
los requisitos en cada fase de la
metodología.
Desarrollo de un marco de trabajo (framework) en
el entorno de Visual Studio 2013 llamado
Modelador YCLY. En este framework se
desarrollaron los conceptos de los modelos que
componen la propuesta metodológica.

32. 15
Objetivos Herramienta o método
 Aplicar las trasformaciones
necesarias para convertir los
diferentes modelos a un dominio
específico.
Transformaciones programadas por la autora, no
se utilizó ningún plug-in externo.
 Validar la metodología mediante la
implementación de un portal de
gobierno electrónico.
Diseño y desarrollo un portal de gobierno
electrónico bajo lo metodología planteada en esta
tesis doctoral.
 Proveer una guía de usuario a las
organizaciones gubernamentales
para la creación de portales de
gobierno electrónico a través del
enfoque MDA.
Guía a disposición de los entes gubernamentales
de manera física y electrónica.
1.5. Estructura de la tesis doctoral
La tesis doctoral se estructuró en 8 capítulos, cuya descripción se presenta a continuación:
CAPÍTULO 1. Se presenta el planteamiento del problema, su justificación y motivación. Se
plantea el objetivo central de la investigación y los objetivos específicos que lo sustentan. Se
explica la metodología aplicada y el contexto donde se desarrolló.
CAPÍTULO 2. Sienta las bases teóricas de la investigación. Se describe el enfoque MDA y los
estándares que lo soportan. Se nombran y explican los diferentes métodos y modelos utilizados
para el desarrollo de las interfaces de usuario y se define los portales de gobierno electrónico.
CAPÍTULO 3. Revisa la situación actual de la investigación en cuestión de los métodos y
metodologías que existen para desarrollar portales tanto en el área de la ingeniería de software
como de la interacción humano-computador. También se nombran algunas metodologías basadas
en MDA, y las herramientas que soportar estás metodologías que sirven para modelar portales web.
Por último se presenta la situación actual del gobierno electrónico tanto a nivel nacional como
internacional. El objetivo de este capítulo es mostrar cómo se encuentran actualmente las diferentes
metodologías utilizadas para el desarrollo de portales web.

33. 16
CAPÍTULO 4. Propone la metodología para el análisis, diseño e implementación de portales de
gobierno electrónico bajo la Arquitectura Dirigida por Modelos (MDA), en ella se incorpora los
principales requisitos funcionales y no funcionales. Se describe los modelos que son necesarios
aplicar en cada una de las etapas de la metodología. Con esto se cumple el objetivo 1 y 4 de la tesis
doctoral.
CAPÍTULO 5. Se analizó y desarrollo un caso de estudio genérico de portal de gobierno
electrónico, siguiendo la propuesta metodológica planteada en el capítulo anterior. Se definieron
los requisitos funcionales y no funcionales para los portales de gobierno electrónico haciendo un
estudio etnográfico y documental sobre los diferentes portales gubernamentales más visitados en
la web. Se utilizaron los modelos de casos de uso de UML para su representación. De esta manera
se da cumplimiento al objetivo 2. Se desarrollaron los patrones conceptuales, a partir de modelos
para generar las interfaces de usuario, mostrando todos los patrones de diseño que fueron generados
para el dominio específico de gobierno electrónico. De esta manera se da cumplimiento al objetivo
3. Por último, se definieron las directrices de las transformaciones necesarias para convertir los
diferentes modelos a un modelo de dominio específico. Se presentan las reglas de transformación
y su respectiva aplicación a través del lenguaje de transformaciones XSL (Extensible Stylesheet
Language Transformations - XSLT). De esta manera se da cumpliendo al objetivo 5. Con esto se
culmina la prueba de validación de la metodología propuesta, con la implementación del caso de
estudio de un portal genérico de gobierno electrónico. De esta manera se da cumplimiento al
objetivo 6 de esta tesis doctoral.
CAPÍTULO 6. Se muestra los resultados del desarrollo de una herramienta denominada
Modelador YCLY que sustentó de manera computacional la propuesta metodológica, dicha
herramienta sirvió como marco de trabajo (framework) para el desarrollo del caso de estudio desde
su análisis hasta su implementación. De esta manera los basamentos teóricos se llevaron a la
práctica para su respectiva validación y puesta en marcha. Provee la documentación técnica del
Modelador YCLY. Muestra en detalle los casos de uso, especificaciones; el diccionario de datos;
los patrones de diseño y de usabilidad aplicados.
CAPÍTULO 7. Provee una guía al usuario y a las organizaciones gubernamentales para la
implementación de la propuesta metodológica en el Modelador YCLY o en cualquier otra

34. 17
herramienta de modelado que sustente el enfoque MDA. Con esto se le da cumplimiento al objetivo
7.
CAPÍTULO 8. Discute los aportes de la propuesta metodológica, las características que son
soportadas por el Modelador YCLY, ventajas y restricciones de la metodología. Se presentan las
publicaciones, ponencias realizadas hasta el momento y los trabajos futuros, la vinculación que
surgió con otros centros de investigación debido a la búsqueda de información. Por últimos se dan
las conclusiones finales.

35. 1
Fundamentos teóricos
Este capítulo corresponde a la investigación documental sobre el desarrollo de portales web, sus
características y los servicios que prestan; la Ingeniería Dirigida por Modelos (Model Driven
Architecture -MDE-) y dentro de ésta la Arquitectura Dirigida por Modelos (Model Driven
Architecture -MDA-); por último, se presenta una revisión sobre gobierno electrónico, con la
finalidad de proporcionar el marco teórico del desarrollo de una metodología para el desarrollo de
portales de gobierno electrónico bajo el enfoque MDA.
2.1. Portales web
Un portal web es un conjunto de páginas web que funcionan como interfaces (puentes) que
comunican al usuario con el sitio web visitado, éste puede ser, una institución, una empresa, una
red social, un buscador, una aplicación, un ente gubernamental, entre otros. En el caso específico
de un ente gubernamental, el portal ofrece información y servicios propios de la administración
pública (Estado) para el ciudadano.
El término portal significa puerta grande, representa el punto de partida para la interacción entre
los procesos del negocio y los usuarios que necesitan diversa información y servicios. Estos deben
satisfacer los requisitos para los que fueron diseñados de una manera confiable. Permiten al usuario
interactuar con diferentes fuentes de información, procesos de negocio, aplicaciones y personas,
según un perfil personalizado de acuerdo a sus necesidades y su rol en la organización (Vega,
2005).

36. 21
2.1.1. Características de los portales web
Las características de los portales web varían según sus objetivos, sus usos, los usuarios a los que
van dirigidos, sus temáticas, pero en general presentan las siguientes características:
• Funcionan como un punto único de acceso a los contenidos que pertenecen al dominio del
portal.
• Ofrecen diversos servicios.
• Permiten el acceso a información, tanto estática como dinámica.
• Integran herramientas de interacción como correo electrónico, encuestas, comunidades,
foros o grupos de discusión y chats, entre otros.
• Se integran con otras aplicaciones.
• Ofrecen mecanismos de organización y búsqueda de información.
• Permiten el acceso a recursos en línea.
Los portales web se encargan de satisfacer necesidades de negocios, basados en el uso de la
tecnología web, según Vega (2005) un portal web provee:
• Acceso personalizado (el usuario define lo que quiere ver).
• Filtrado automático de contenido basado en las preferencias del usuario (se recupera sólo
lo que se necesita).
• Integración de múltiples sistemas (el usuario obtiene directamente de los sistemas lo que
necesita para hacer su trabajo).
• Escalabilidad (el usuario experimenta cada vez mejores tiempos de respuesta en sus
búsquedas, con menor inversión en hardware en cada actualización).
• Administración de contenido (el usuario encuentra los documentos y conocimientos que
necesita para ser efectivo).
• Ofrecen diferentes niveles de seguridad según sea el caso.
• Soporte para las comunidades (los empleados, clientes y proveedores pueden colaborar en
línea).

37. 22
• Ambiente de desarrollo compatible (el conjunto de herramientas tecnológicas que permite
relacionar todos los tipos de software en uso).
2.2. Ingeniería Dirigida por Modelos
Desde hace algunos años, las investigaciones en Ingeniería de Software para el desarrollo de
tecnologías para crear aplicaciones y sistemas, se han sustentado en la Ingeniería Dirigida por
Modelos - MDE (en inglés, Model Driven Engineering), la cual se centra en la creación de modelos
con un alto nivel de abstracción, para aumentar la productividad, elevando la compatibilidad entre
los sistemas, simplificando el proceso de diseño. Uno de los objetivos que busca es aumentar la
productividad, elevando al máximo la compatibilidad entre los sistemas, simplificando el proceso
de diseño.
La Ingeniería Dirigida por Modelos tiene dos ejes fundamentales. El primero es la separación entre
la especificación de la “funcionalidad” esencial del sistema y la “implementación” de dicha
funcionalidad usando plataformas tecnológicas específicas. El segundo es la consideración de los
modelos como los conductores primarios o guías en todos los aspectos del desarrollo de
aplicaciones de software.
Miller y Mukerji (2001) sostienen que un modelo es “la descripción o especificación de un sistema
y su ambiente, que es frecuentemente representado como una combinación de dibujos y texto”,
donde el texto puede estar en un lenguaje de modelado o en lenguaje natural. Kleppe, Warmery
Bast (2003) lo definen como “una descripción de un sistema, escrito en un lenguaje bien definido”,
mientras que un lenguaje de modelado lo definen como “el lenguaje usado para expresar el
modelo”; donde el modelado se define como “la actividad que consiste en definir un modelo a
través de un lenguaje”.
Martínez et al (2012), afirman que el uso de prácticas de ingeniería dirigida por modelos aumenta
significativamente la productividad y la satisfacción de la nueva generación de desarrolladores
web, independientemente del dominio de la aplicación. Sin embargo, el modelado de actividades

38. 23
que no vaya acompañados de un entorno de generación robusto puede hacer que la productividad
y la satisfacción disminuyan significativamente.
2.3. Arquitectura Dirigida por Modelos
La Arquitectura Dirigida por Modelos es un enfoque de desarrollo de software creado por el
consorcio OMG (Object Management Group) que emplea estándares propios. Su objetivo es
alcanzar un nivel de abstracción centrándose en la definición de las estructuras y el comportamiento
del sistema, sin tener en cuenta la aplicación de la tecnología subyacente.
Para Miller y Mukerji (2001) consiste en una aproximación al diseño de sistemas de información
que separa las especificaciones de funcionalidad, de las especificaciones de implementación,
independientemente de las plataformas tecnológicas que se vayan a utilizar.
A pesar de la existencia de numerosos métodos y enfoques que utilizan el modelado como parte de
las técnicas de desarrollo de sistemas software, un aspecto característico de MDA es la utilización
de estándares, especificando la funcionalidad del sistema a través de múltiples plataformas y de un
mapeo de estándares, que permiten la integración y la interoperabilidad de diferentes aplicaciones
en una forma explícita sobre los modelos del sistema.
Bajo MDA un conjunto de subsistemas y tecnologías proveen, con una funcionalidad coherente,
un modelo que puede ser usado en el desarrollo de cualquier aplicación de software, sin tener en
cuenta los detalles de implementación. Además define una arquitectura que proporciona un
conjunto de directrices (guías) para la estructuración de las especificaciones que se expresan en un
modelo; de esta manera, se eleva el nivel de abstracción, al prestar mayor atención al modelo
conceptual y a las trasformaciones que se generan entre ellos.

39. 24
2.3.1. Modelos en Arquitectura Dirigida por Modelos
Uno de los factores claves del éxito de MDA es su énfasis en los modelos, ofreciendo un marco
conceptual para el uso y transformación de estos, siendo estas transformaciones el corazón del
desarrollo de software. Por ello, la necesidad de conceptualizar técnicamente el proceso de
transformación de un modelo abstracto a una plataforma específica, considerando la lógica del
negocio, los aspectos técnicos asociados al desarrollo de aplicaciones y las plataformas que se
utilizan.
En MDA se separan los aspectos del negocio y la lógica de aplicación de los aspectos que
corresponden a las plataformas tecnológicas. La figura 2.1 representa gráficamente la forma en que
conceptualmente actúa MDA.
Figura 2.1. Actuación (conceptual) de MDA
En MDA existen dos modelos de plataformas: el Modelo Independiente de la Plataforma (Platform
Independent Model, PIM), que se refiere a un alto nivel de abstracción, que es independiente de
cualquier tecnología de implementación y el Modelo Específico de la Plataforma (Platform Specific
Model, PSM), que se refiere a la plataforma que especifica el sistema en términos de las
construcciones de implementación que están disponibles en alguna tecnología específica conocida.
De manera que, un modelo en MDA es siempre de tipo PIM o de tipo PSM, sin embargo, es muy
Modelo Implementación de códigoTransformaciónModelo Implementación de códigoTransformación

40. 25
difícil establecer una línea divisoria entre una plataforma específica y una plataforma
independiente.
En MDA, los modelos PIM son expresados inicialmente en un lenguaje de modelado que es
independiente de la plataforma. El modelo independiente de la plataforma es posteriormente
traducido a un modelo específico de plataforma (PSM), mediante la asignación (mapeo) del PIM,
por medio de un lenguaje de aplicación o plataforma (por ejemplo, Java) que utiliza para ello reglas
formales. De manera que el núcleo del concepto de MDA consiste en una serie de estándares del
OMG.
Aunque es difícil trazar la línea que separa ambos modelos, el Modelo Independiente de la
Plataforma corresponde a una descripción de la funcionalidad del sistema que es independiente de
las características de implementación de una plataforma determinada; esta plataforma PIM presenta
un grado de independencia que puede ser usada por otras plataformas de similar tipo. Por lo tanto,
una PIM corresponde a una descripción de la funcionalidad del sistema que es independiente de
las características de implementación de plataformas específicas.
El Modelo Específico de la Plataforma es una descripción del sistema en términos de una
plataforma específica. Un PSM combina las especificaciones de la PIM con los detalles que
explican las formas que el sistema utilizará un determinado tipo de plataforma. Es, por lo tanto,
una descripción (especificación) del sistema a nivel de código.
En resumen, MDA describe una forma de modelar aplicaciones en plataformas que son
independientes, al permitir, por medios fáciles pero sistemáticos, convertir tales modelos en código
específico de una plataforma. En la práctica, el centro de las modificaciones, rediseño, mejoras y
correcciones está en el modelo, en lugar de estar en el código implementado.

41. 26
2.3.2. Metamodelo - Meta Object Facility (MOF)
Un modelo que representa un lenguaje de modelamiento es un “metamodelo” (Seidewitz, 2003).
El metamodelado es un mecanismo que permite construir formalmente lenguajes de modelado y
describe los posible modelos que pueden ser expresados usando un lenguaje.
Un metamodelo está compuesto por conceptos y relaciones que se presentan en un momento dado;
en tal sentido, un metamodelo es una referencia a la formulación rigurosa de un esquema
conceptual (ontología) que facilita la comunicación y el intercambio de información entre
diferentes sistemas y entidades para la construcción de modelos.
Cuando un modelo es construido según un metamodelo bien definido, se dice que el modelo está
conforme con el metamodelo. También, es común afirmar que tal modelo es una instancia del
metamodelo (Solís, 2008). Tal como lo expresa la figura 2.2 el modelo es una instancia basada en
un metamodelo. La relación entre un modelo y un metamodelo es llamada la instancia de la
relación.
Figura 2.2. Relación entre metamodelo, modelo y lenguaje
(Fuente: Overbeek, 2006)
El metamodelado trabaja con diversos niveles de abstracción que son definidos en la arquitectura,
estos pueden ser: nivel M3 (“meta-metamodelo”) que corresponde al nivel más abstracto, donde se
encuentra el MOF, que permite definir metamodelos concretos (como el del lenguaje UML). Nivel
M2 (“metamodelo”), que sus elementos corresponden a los lenguajes de modelado, por ejemplo el
UML (conceptos a este nivel pueden ser Clase, Atributo, Asociación). Nivel M1 (“modelo del
Metamodelo Lenguaje
Modelo
<<instancia de>>
<<representa>>
<<expresar
utilizando>>
Metamodelo Lenguaje
Modelo
<<instancia de>>
<<representa>>
<<expresar
utilizando>>

42. 27
sistema”), sus elementos son modelos de datos, por ejemplo entidades como “Estudiante”, “Auto”,
atributos como “nombre”, relaciones entre estas entidades. Nivel M0 (“instancias”) que modela o
representa al sistema real. Sus elementos son datos, por ejemplo “Mario Martínez”, que vive en
“Av. Lecuna, 126”.
Para realizar cualquier transformación, MDA necesita de modelos para expresarlos en un lenguaje
basado en MOF (Meta Object Facility). MOF tiene como función permitir la interoperación de
herramientas de metamodelado, y de las que dan soporte al proceso de desarrollo software basado
en MDA (Solís, 2008). MOF proporciona el estándar para las transformaciones de modelos y el
intercambio de las construcciones que se utilizan en MDA. MOF constituye la base para el
intercambio y la interoperabilidad del modelado/metadatos, y es el mecanismo mediante el cual los
modelos son analizados en XMI (XML, Metadata Interchange). MOF, define las interfaces de
programación para la manipulación de los modelos y sus instancias que abarca el ciclo de vida de
MDA (Miller y Mukerji, 2001).
Esto garantiza que los modelos pueden ser almacenados en un repositorio compatible con MOF,
los cuales son analizados y transformados por herramientas compatibles, que luego son traducidos
al XMI para el transporte por la red. Sin embargo, la transformación no limita los tipos de modelos
que pueden utilizar los lenguajes basados en MOF.UML -Unified Modeling Language-, y CWM -
Common Warehouse Metamodel-(ambos del OMG) son buenos ejemplos de lenguajes de
modelado basados en MOF, pero no son obligatorios cuando se trabaja con MOF (Portal OMG,
2009).
2.3.3. Trasformación de modelos - Query View Transformation (QVT)
Kleppe et al. (2003) definen una transformación como la generación automática de un modelo
destino a partir de un modelo origen, de acuerdo a una especificación dada. Miller y Mukerji (2001)
definen la transformación como el proceso de convertir un modelo en otro del mismo sistema.
Desde estas sencillas explicaciones de lo que es una transformación podemos suponer que en MDA
las transformaciones se dan entre modelos, la mayoría de las veces con el uso de herramientas

43. 28
específicas y apropiadas para la transformación. Con esas herramientas el modelo es transformado
en otros modelos, o en un código o en documentación.
La transformación de modelos según Sendall y Kozaczynski (2003) puede efectuarse de tres
formas: a) Mediante la manipulación directa del modelo a través de una API (Application
Programming Interface); b) A través de una representación intermedia que permita a otras
herramientas manipular el modelo; c) Mediante un lenguaje de transformación de modelos que
tenga construcciones específicas para ello. En el caso de MDA, la forma más usada es mediante
lenguajes de transformación.
Estos lenguajes de transformación son compatibles con el estándar QVT; ejemplos de estos
lenguajes son el VIATRA o ATLAS. Para realizar éstas transformaciones, existen reglas propias.
La figura 2.3 representa, de forma genérica, el proceso de transformación que se da entre las
diferentes plataformas de modelos.
La función de transformación define las correspondencias abstractas entre elementos de los
metamodelos de entrada y los de salida. Kleppe et al. (2003) definen una correspondencia entre
modelos, como por ejemplo la ejecución de una función de transformación, es decir, la relación
entre los elementos concretos de un modelo de entrada y otro de salida no se conocen hasta que se
ejecuta la transformación.
Figura 2.3. Transformación de modelos
(Miller y Mukerji, 2003).
PIM
PSM
Transformación
PIM
PSM
Transformación

44. 29
Solís (2008) cita el siguiente ejemplo, “una función de transformación (compuesta por una sola
regla) podría ser Todo X se transforma en un Y, (correspondencia abstracta); en cambio, si la
entrada es un modelo M1 = {X1,X2}, al aplicar la transformación se obtiene M2 = {Y1, Y2}, y se
establecen las siguientes correspondencias (X1, Y1) y (X2, Y2)”.
Las transformaciones de modelos se ejecutan en una plataforma de transformación, que se compone
de uno o más metamodelos, que sirven para definir los metamodelos de entrada y salida de las
funciones de transformación, un lenguaje de transformación y un entorno tecnológico de ejecución.
Un término aplicado a esta combinación de elementos conforman el de espacio tecnológico
(Kurtev, Bézivin, Jouault y Valduriez, 2006).
QVT (Query View Transformation) define el modo en que han de llevarse a cabo las
transformaciones entre modelos cuyos lenguajes han sido definidos usando MOF. QVT describe
tres lenguajes complementarios cuyo propósito es definir transformaciones entre modelos en el
marco de MDA. Dos de ellos llamados Relations y Core, son de naturaleza declarativa. El tercero
Operational Mappings es imperativo. La definición de estos tres lenguajes incorpora en su sintaxis
el lenguaje estándar OCL (Object Constraint Language) para expresar consultas (queries) a los
modelos en una notación ampliamente conocida y utilizada (OMG, QVT, 2008). Los lenguajes que
componen QVT ofrecen mecanismos de trazabilidad entre elementos de uno o varios modelos. El
flujo de ejecución de las transformaciones determina implícitamente la información de las trazas.
A partir de la estandarización promovida por QVT y atendiendo a las necesidades prácticas de la
transformación de modelos, surgen diversas estrategias de transformación que van más allá del uso
de elementos del metamodelo. Para ello, se definen mecanismos de transformación basados en
reglas, tipos de elementos, patrones, información de la plataforma y otros modelos e información
adicional (Miller y Mukerji, 2003).
Reglas de transformación
El proceso de automatizar y utilizar un modelo como entrada y producir uno o más modelos como
salida, siguen un conjunto de reglas de transformación que se conocen como transformación de
modelos (Sendall y Kozaczynski, 2003). El proceso de transformación de modelos se efectúa a

45. 30
través de una función de correspondencia o transformación, que es compuesta por un conjunto de
reglas de transformación (Kleppe et al., 2003). La entrada de la función de transformación
corresponde al conjunto de modelos, cuyos metamodelos pertenecen al dominio de la función. La
salida es un conjunto de modelos que pertenecen a un conjunto de metamodelos de salida.
Las reglas se aplican para transformar PIM a PIM que van generalmente asociadas a los pasos que
se suceden entre el modelado de la especificación, el análisis y el diseño. Esto quiere decir que se
permiten transformaciones verticales y/u horizontales. Las transformaciones verticales son
aquellas que se realizan entre los diferentes niveles de abstracción (PIM y PSM) y las horizontales,
son aquellas que se realizan entre los diferentes modelos de un mismo nivel de abstracción. Así por
ejemplo, se pueden dar las siguientes transformaciones: PIM a PSM que se realizan cuando el PIM
está suficientemente refinado y se transforma en un modelo dependiente de la infraestructura final
de ejecución; cuando un PIM se transforma en uno o varios PSM; PSM a PSM que son necesarios
para la realización y despliegue de componentes; PSM a PIM que permiten la abstracción de
modelos a partir de implementaciones específicas de una plataforma y dependientes de una
tecnología concreta (Cáceres y Marcos, 2003).
Muchos tipos de herramientas de transformación se han desarrollado con el fin de aplicar el enfoque
de MDA. Czarnecki y Helsen (2003) han realizado una taxonomía de las técnicas de
transformación existentes, al aplicar un análisis de dominio para la transformación de enfoques de
modelos existentes. El resultado de las transformaciones posibles se expresa en la figura 2.4. En
esencia, el diagrama de función define la taxonomía, que no pretende ser normativa, sino una guía
para la transformación.
La Regla de transformación refiere al acceso al modelo fuente y el objeto, a través de la expresión
de variables (algunas veces expresadas como metavariables), los patrones que son fragmentos de
modelos con ninguna o alguna variable y la lógica que expresa las restricciones computacionales
en los elementos del modelo.

46. 31
Figura 2.4. Notación del alcance que pueden tener las transformaciones
(Czarnecki y Helsen, 2003)
El Alcance de la aplicación de la regla refiere a las reglas que permiten a una transformación
restringir las partes de un modelo que participa en la transformación.
La Relación entre el modelo fuente y el modelo objeto refiere que algunos enfoques tratan de la
creación de algunos modelos, pero en otras ocasiones el modelo fuente y el objeto refiere al mismo
modelo.
La Estrategia de aplicación de la regla refiere a que se necesita de una estrategia de aplicación
para que la regla sea aplicada en un sitio específico dentro del alcance del modelo fuente.
La Programación de la regla refiere a los mecanismos que sirven para determinar el orden en el
que las reglas individuales se deben aplicar. Existen cuatro formas particulares parea la
programación: forma, selección de la regla, interacción de la regla y el ajuste de las fases.
Organización de la regla refiere a la composición y estructuración de las reglas de transformación
múltiple.
Transformación de Modelos
Programación de la regla
Organización de la regla
Estrategia de aplicación
de la regla
Relación entre modelo
fuente y el modelo objeto
Alcance de la aplicación
de la regla
Regla de transformación
Direccionalidad
Enlaces de trazabilidad
Leyenda:
Característica opcional
Característica obligatoria
Transformación de Modelos
Programación de la regla
Organización de la regla
Estrategia de aplicación
de la regla
Relación entre modelo
fuente y el modelo objeto
Alcance de la aplicación
de la regla
Regla de transformación
Direccionalidad
Enlaces de trazabilidad
Leyenda:
Característica opcional
Característica obligatoria

47. 32
Enlaces de trazabilidad refiere a que las transformaciones pueden registrar los vínculos entre la
fuente y los elementos de destino. Estos vínculos pueden ser útiles en la realización de análisis de
impacto, la sincronización entre modelos, basado en el modelo de depuración y en determinar el
objetivo de una transformación.
Direccionalidad refiere a que aunque las reglas de transformación suelen ser diseñados para tener
un carácter funcional, las transformaciones pueden ser unidireccionales o bidireccionales y ello
define la forma en que será computado.
Niveles y métodos de transformación de modelos
El estado actual de las técnicas de transformación usadas en MDA no puede estar dirigido por los
temas de confiabilidad, por ello, no han sido ampliamente aplicados a modelos con atributos de
confiabilidad. Integrar MDA con mecanismos para construir confiabilidad requiere un
conocimiento profundo y aplicado, además de los estándares, herramientas y técnicas (Brown, y
McDermid, 2007).
Existen diferentes herramientas que dan apoyo a la trasformación de modelos, estás pueden ser de
tipo manual o automática (asistida por computadora). Para realizar las trasformaciones de PIM a
PSM en la actualidad hay cuatro (4) enfoques de transformación: 1) la transformación manual, 2)
la transformación de un PIM que está preparada usando un perfil (UML), 3) la transformación
usando patrones, y 4) la trasformación automática (Miller y Mukerji, 2003).
Transformación manual: con el fin de hacer la transformación de PIM a PSM, las decisiones de
diseño deben estar establecidas, éstas se pueden hacer durante el proceso de desarrollo de un diseño
que cumplan con los requisitos de ingeniería. Este enfoque es útil, debido a que estás decisiones
son consideradas y adoptadas en el contexto de un determinado diseño de la aplicación.
Transformación de un PIM usando perfil: un PIM puede estar completado usando un perfil UML
de la plataforma independiente, este modelo puede ser transformado en un PSM usando una
segunda expresión de perfil de UML de la plataforma específica. La transformación puede implicar
marcar el PIM utilizando marcas previstas con el perfil de la plataforma específica. Los

48. 33
mecanismos de extensión de los perfiles de UML (versión 2.0) pueden incluir las especificaciones
de operación, esto quiere decir, que las reglas de transformación pueden ser especificadas
utilizando las operaciones, lo que permite la especificación de una transformación de un perfil
UML.
Transformación usando patrones y marcas: los patrones pueden ser utilizados en la especificación
de un mapeo o trazabilidad. Esta trazabilidad incluye un patrón y sus correspondientes marcas para
algunos elementos de ese modelo. Por ejemplo, las transformaciones del modelo de las marcas
especificadas se utilizan para preparar un marco PIM. Los elementos marcados de la PIM se
transforman de acuerdo con el patrón para producir el PSM.
El mapeo es un conjunto de normas y técnicas utilizadas para modificar un modelo, y de esta
manera obtener otro. El mapeo se utiliza para la transformación de:
a) PIM a PIM: perfeccionamiento del modelo;
b) PIM a PSM: el PIM es lo suficientemente refinado como para ser proyectado para en la
infraestructura de la ejecución;
c) PSM a PSM: la realización de componentes y de despliegue;
d) PSM a PIM: abstracción de modelos de implementaciones existentes, en una determinada
tecnología o en un modelo de plataforma independiente.
Varios patrones pueden ser combinados para producir un nuevo modelo, incluso nuevas marcas
pueden ser especificadas para el uso de un nuevo modelo. En los tipos de transformaciones de
modelo, las reglas podrían especificar todos los elementos de un PIM que coincidan con un patrón
particular, para que se transformen en instancias de otro patrón en el PSM.
Trasformación automática: hay contextos en los que un PIM puede proporcionar toda la
información necesaria para la aplicación, y no hay necesidad de añadir marcas o perfiles adicionales
de datos, con el fin de ser capaz de generar código. En tal contexto, es posible que un desarrollador
de aplicaciones construya un PIM que se complete como una clasificación, estructura, invariantes,
y pre y postcondiciones. El desarrollador puede especificar el comportamiento requerido
directamente en el modelo, mediante una acción del lenguaje. Esto hace que el PIM se complete

49. 34
computacionalmente, es decir, el PIM, que contiene toda la información necesaria para producir
un código de programa de computadora. En este contexto, el desarrollador no necesita ver un PSM,
ni tampoco es necesario añadir información adicional al PIM, distinta de la que dispone la
herramienta de transformación. La herramienta interpreta el modelo directamente o transforma el
modelo directamente al código del programa.
2.3.4. Otros estándares
La web se ha vuelto la plataforma preferida para aplicaciones de cualquier tamaño; al menos parece
haber un anhelo por alcanzar enfoques cada vez más fáciles y lógicos para desarrollar. Esto ha
generado una aparición de gran cantidad de plataformas web, lo que ha permitido el desarrollo de
aplicaciones similares, pero usando sintaxis y artefactos diferentes.
Cabe destacar que el enfoque MDA utiliza otros estándares, adicionales al MOF y QVT analizados
anteriormente. Por ejemplo, la arquitectura de metamodelado MOF además de estar acompañado
del estándar QVT, también puede utilizar el estándar XMI (XML, Metadata Interchange). Otros
estándares usados en MDA son: UML (Unified Modeling Language), CWM (Common Warehouse
Metamodel), entre otros que conforman el consorcio OMG.
UML - Unified Modeling Language: se refiere a la modelación de la arquitectura, los objetos, las
interacciones entre los objetos, el modelado de datos y los aspectos del ciclo de vida de la
aplicación, así como los aspectos de diseño del desarrollo basado en componentes, incluyendo la
construcción y montaje. Los artefactos capturados en los modelos UML (en términos de clases,
interfaces, casos de uso, gráficos de actividad, etc) puede ser fácilmente exportados a otras
herramientas utilizando el estándar XMI (Miller y Mukerji, 2001).
Cada especificación diseñada bajo el enfoque MDA tiene como base normativa, dos niveles de
modelos: un modelo independiente de plataforma (PIM), y uno o más modelos específicos de
plataforma (PSM). Para muchas especificaciones, estas se definirán en UML, que es el lenguaje de
modelado estándar del OMG. Es común utilizar el estándar UML para el manejo de las

50. 35
especificaciones, más no es un requisito necesario, ya que el estándar MOF es la base de modelado
obligatorio para MDA (Portal OMG, 2009).
UML 2.0 es la actual versión, adaptada a las necesidades de MDA, esta nueva versión mejora el
rendimiento empresarial, servicios arquitectónicos, estructurales, y el modelado de
comportamiento.
XMI - XML, Metadata Interchange: es un lenguaje para permitirles a los usuarios desarrolladores
de software el intercambio de modelos UML. Es una especificación del OMG definida con el
objetivo de facilitar el intercambio de modelos entre herramientas de modelado y repositorios
repositorios de metadatos basados en la especificación (Miller y Mukerji, 2001).
Una de las razones de la aceptación de XMI como lenguaje de intercambio de modelos es la
tecnología ya desarrollada alrededor de XSLT (Extensible Stylesheet Language Transformations),
un modelo de procesamiento de documentos XML que incluye a la vez el lenguaje para describir
las reglas de transformación. De esta forma se pueden construir diversas plantillas, que permiten
generar documentos, recorrer su estructura y realizar transformaciones (Quintero y Anaya, 2007).
XMI se ha utilizado para hacer artefactos UML (utilizando el DTD de XMI UML), para diseñar
almacenes de datos (Data Warehouse) y artefactos de bases de datos (usando la DTD XMI CWM),
las definiciones de interfaz de CORBA (usando la DTD IDL), y las interfaces de Java y las de
clases (usando una DTD Java). En síntesis, se puede decir que, XMI está unido al mundo del
modelado (UML) y de los metadatos (MOF y XML).
CWM - Common Warehouse Metamodel: es el almacén de datos (Data Warehouse) estándar del
OMG. Cubre el ciclo de vida completo de diseño, creación y gestión de aplicaciones de almacén
de datos. Es probablemente el mejor ejemplo hasta la fecha de aplicación del paradigma de la MDA
a un área de especifica de aplicación (Miller y Mukerji, 2001).

51. 36
2.4. Modelado de interfaces de usuario (IU)
Las metodologías más comunes que se han utilizado para el desarrollo de IU basadas en modelos
han usado los modelos de dominio (MDO), modelo de aplicación (MA), modelo de usuario (MU),
modelo de tareas (MT), modelo de diálogo (MD), modelo de presentación (MP).
2.4.1. Modelo de dominio (MDO)
El modelo de dominio recoge información de los objetos que manipula el usuario, con sus
características y el comportamiento que ofrecerán los mismos. Para especificar el modelo de
dominio, lo habitual, es utilizar diagramas de clases de UML, pero también se pueden utilizar
diagramas entidad-relación (Delgado, 2007). Como ejemplos del desarrollo de interfaces bajo el
modelo de dominio se puede nombrar MECANO, MOBI-D, DIANE+, TRIDENT, GENIUS,
JANUS, AME y Teallach.
2.4.2. Modelo de aplicación (MA)
Este modelo describe las propiedades relevantes de la aplicación para el IU. El modelo especifica
de forma independiente la información sobre una aplicación en cuanto a cómo hay que mostrar los
objetos o cómo se invocan las distintas operaciones. Generalmente se especifica usando una
jerarquía de clases y algunos autores lo consideran equivalente al MDO (Delgado, 2007).
2.4.3. Modelo de usuario (MU)
El modelo de usuario recoge las características de los usuarios finales. Un modelo de usuarios
describe a los futuros usuarios del sistema según sus habilidades, su conocimiento de la aplicación
o la información que deben procesar (Delgado, 2007).

52. 37
2.4.4. Modelo de tareas (MT)
Describe las tareas que los usuarios pueden realizar en la aplicación así como la relación entre ellas.
El modelo de tareas, describe las tareas que el usuario puede realizar incluyendo subtareas, sus
objetivos, y los procedimientos usados para alcanzar los objetivos. Un modelo de tareas queda
descrito por un objetivo, las acciones necesarias para alcanzarlo y un plan de selección de las
acciones. Las tareas, que pueden ser de diferentes tipos, se representan utilizando una
descomposición jerárquica de las acciones involucradas en su desarrollo, haciéndose uso de
notaciones que serán presentadas en un apartado posterior (Delgado, 2007).
Para especificar el modelo de tareas, lo habitual, es utilizar la notación TKS (Task Knowledge
Structures), la ACG (Activity Chaining Graphs), la CCT (Concur Task Trees), la HTA
(Hierarchical Task Analysis), el GOMS (Goal-Operations-Methods-Selection) y la UAN (User
Action Notation). Como ejemplos de desarrollo de interfaces de usuario bajo el modelo de tareas
se pueden nombrar las herramientas de ADEPT y TADEUS.
2.4.5. Modelo de diálogos (MD)
El modelo de diálogos define las características y los procesos del diálogo humano computador en
un modelo de interfaz. Muchas veces el modelo de tareas y el modelo de diálogos se clasifican
dentro de un único modelo denominado modelo de tareas y diálogos (MTD). Ambos modelos
describen las posibles tareas que los usuarios pueden realizar en su interacción con la aplicación,
pero a diferentes niveles de abstracción. La idea de relacionar estos dos modelos es que muchas
veces tienen funciones parecidas y se pueden solapar muchas veces (Delgado,2007).
2.4.6. Modelo de presentación (MP)
El modelo de presentación describe los aspectos visuales de la interfaz. Se suele dividir en dos
submodelos: el modelo de presentación abstracto (MPA) y el modelo de presentación concreto
(MPC).El MPA provee una vista abstracta de un interfaz que es independiente del modelo concreto

53. 38
subyacente y el MPC es la instancia concreta de un interfaz que puede ser presentado a un usuario,
Puede haber muchas instancias concretas de un modelo de presentación abstracto (Delgado, 2007).
2.5. Patrones de Software
Los patrones de software son un conjunto de soluciones que se le dan a determinados problemas,
y que pueden ser utilizados en diferentes contextos de trabajo. Los patrones de software deben
documentarse para formar un catálogo de referencia según sea el contexto de aplicación. De esta
manera se optimiza el tiempo de los desarrolladores de software ya que cuentan con soluciones
prediseñadas, que sólo en algunos casos deben tener creatividad para adaptarlos a las necesidades
del dominio.
En la ingeniería de software los patrones pueden aplicarse a nivel del: análisis de requisito, el diseño
de la arquitectura, el diseño detallado, la interacción con el usuario y el código (Bonillo, 2006).
Con lo que puede establecerse la siguiente clasificación:
2.5.1. Patrones de análisis
Este tipo de patrones los dio a conocer por primera vez Fowler (1997) en su libro “Analysis
Patterns”, los define como un grupo de conceptos que representan una construcción común en el
modelado de negocios. Puede ser relevante para un único dominio, o puede abarcar muchos
dominios. La idea central es la construcción de escenarios utilizando patrones. Se pretende tener
una visión más conceptual y estructural de las situaciones, con el fin de identificar la naturaleza
intrínseca de las mismas. Con esa visión, es posible determinar el tipo de escenario correspondiente
a cada situación y así, elegir un patrón de un catálogo, rehusando su estructura con el fin de derivar
el escenario más fácil y directamente. Estos patrones son importantes porque nos ayudan a entender
cómo la gente percibe el mundo y de esta manera se pueden hallar soluciones informáticas a
problemas dentro de un contexto.

54. 39
2.5.2. Patrones de arquitectura
Son esquemas que expresan la estructura fundamental de un sistema de software. Proporciona un
conjunto predefinido de subsistemas, especifica sus responsabilidades, e incluye las normas y
directrices para la organización de las relaciones entre ellos (Buschmann, Meunier, Rohnert,
Sommmerld y Stal, 1996). Los patrones más conocidos dentro de esta categoría son: Master-View-
Controller (MVC), Page Template, Page Controller y Front Controller, entre otros.
2.5.3. Patrones de diseño
Son patrones de un nivel de abstracción menor que los patrones de arquitectura, por eso también
se les conoce con el nombre de patrones de micro-arquitectura. Están por lo tanto más próximos a
lo que sería el código fuente final. Están relacionados con el diseño de objetos y frameworks de
pequeños y medianos sistemas. Gamma, Helm, Johnson y Vlissides (llamados Gang of Four, GoF)
en 1994 documentaron 23 patrones de diseño clasificados según su propósito de la siguiente
manera.
 De Creación: estos patrones tratan de crear instancias de objetos. Ayudan a crear un sistema
independiente de cómo los objetos se crean, componen, y representar. Un patrón de
creación de clase utiliza la herencia como un mecanismo para lograr la instanciación de la
clase, mientras que un patrón creacional de objeto va a delegar la creación de instancias de
otro objeto. Dentro de estos patrones se encuentran: el Abstract Factory, Builder, Factory
Method, Prototypy y Singleton.
 De Estructura: estos patrones describen cómo las clases y los objetos se componen para
formar estructuras más grandes y proporcionar de esa manera nuevas funcionalidades. Los
patrones estructurales de clase utilizan la herencia para componer interfaces o
implementaciones. Los patrones estructurales de objetos crean objetos complejos
agregando objetos individuales, de esta manera se llega a las grandes estructuras. Dentro
de estos patrones se encuentran: Adapter, Bridge, Composite, Decorator, Facade,
Flyweight, Proxy.