Generador de Patrones de Diseño (GEPADI)

REPÚBLICA BOLIVARIANA DE VENEZUELA
UNIVERSIDAD DEL ZULIA
FACULTAD EXPERIMENTAL DE CIENCIAS
DIVISIÓN DE PROGRAMAS ESPECIALES
LICENCIATURA EN COMPUTACIÓN
GENERADOR DE PATRONES DE DISEÑO (GEPADI)
Trabajo presentado para optar al ascenso de la categoría de
Profesor Asociado de la Universidad del Zulia
Autor: Profa. Yaskelly Yedra
Maracaibo, 16 de mayo de 2012

Yedra Hernández, Yaskelly Yubisay. GENERADOR DE PATRONES DE DISEÑO. Trabajo de
Ascenso presentado para optar a la categoría de Profesora Asociada. Universidad del Zulia.
Facultad Experimental de Ciencias. Departamento de Computación. Maracaibo. Venezuela.
2012. 115 p.
RESUMEN
Un patrón es la abstracción de una forma concreta que puede repetirse en contextos
específicos. Este concepto se aplica en el desarrollo de software, surgiendo distintos tipos de
patrones como los de análisis, de arquitectura de software, de usabilidad o de interfaz, entre
otros y los de diseño que son el punto central del presente trabajo de ascenso. El objetivo
principal de este trabajo fue desarrollar un Generador de Patrones de Diseño (GEPADI) que
sirva para implementar cualquier plantilla como solución a un problema dado. La metodología
utilizada para desarrollar este generador fue la aplicada por GoF en su libro Patrones de
Diseño: Elementos de Software Orientados a Objetos Reutilizables. Como resultado se obtuvo
una herramienta que genera patrones de diseño en cualquier dominio del desarrollo de software
y a su vez se pueden integrar estos patrones a cualquier aplicación, ya que están guardados en
formato XML. Para validar la herramienta se desarrolló un catálogo de patrones en el dominio
específico de gobierno electrónico creando patrones para este entorno. Se concluyó que el
GEPADI puede generar patrones de diseño para entornos de dominio específico.
Palabras clave: patrón, patrones de diseño, patrones GoF, generador de patrones de diseño
(GEPADI).
Correo electrónico: yyedra@fec.luz.edu.ve

Yedra Hernández, Yaskelly Yubisay. GENERADOR DE PATRONES DE DISEÑO. Trabajo de
Ascenso presentado para optar a la categoría de Profesora Asociada. Universidad del Zulia.
Facultad Experimental de Ciencias. Departamento de Computación. Maracaibo. Venezuela.
2012. 115 p.
ABSTRACT
A pattern is the abstraction of a concrete form that can be replicated in specific contexts. This
concept is applied in the development of software; different types of patterns emerge as the
analysis, software architecture, usability or interface, including design and are the focus of this
work for promotion. The main objective of this work was to develop a Design Pattern Generator
(GEPADI) to serve as a template to implement any solution to a given problem. The
methodology used to develop this generator was applied for in his book GoF Design Patterns:
Elements of Reusable Object-Oriented Software. The result was a tool that generates design
patterns in any domain of software development and in turn these patterns can be integrated to
any application, since they are stored in XML format. To validate the tool was developed a
catalog of patterns in the specific domain of e-government standards for creating this
environment. It was concluded that GEPADI can create design patterns for domain-specific
environments.
Key words: pattern, design patterns, GoF patterns, design pattern generator (GEPADI)
E-mail: yyedra@fec.luz.edu.ve

ÍNDICE GENERAL
pp
VEREDICTO
RESUMEN
ABSTRACT
ÍNDICE GENERAL
ÍNDICE DE ILUSTRACIONES
ÍNDICE DE TABLAS
INTRODUCCIÓN……………………………………………………………………………………. 1
1. PATRONES EN EL DESARROLLO DE SOFTWARE…………………………………….. 2
1.1. Planteamiento del problema……………………………………………………………… 2
1.2. Definición de patrón……………………………………………………………………….. 4
1.3. Patrones de software……………………………………………………………………… 4
1.4. Patrones de diseño………………………………………………………………………… 7
1.4.1. Patrones de diseño de GRASP…………………………………………………... 11
1.4.2. Patrones de diseño de GoF………………………………………………………. 16
2. ESTADO DEL ARTE…………………………………………………………………………… 20
2.1. Generadores de patrones de diseño…………………………………………………….. 20
2.2. Herramientas de modelados de UML……………………………………………………. 25
3. GENERADOR DE PATRONES DE DISEÑO (GEPADI)…………………………………… 27
3.1. Requisitos del Generador de Patrones de Diseño (GEPADI)………………………. 27
3.1.1. Requisitos de software…………………………………………………………….. 27
3.1.2. Requisitos de hardware…………………………………………………………… 27
3.1.3. Requisitos humanos……………………………………………………………….. 27
3.1.4. Requisitos legales………………………………………………………………….. 27
3.1.5. Requisitos funcionales…………………………………………………………….. 28
3.1.6. Requisitos no funcionales…………………………………………………………. 31
3.2. Metodología de trabajo……………………..……………………………………………... 31
3.3. Interfaces de usuario de GEPADI……………………………………………………… 33
3.3.1. Interfaz principal……………………………………………………………………. 33

3.3.2. Interfaz de Patrones…………………………………………………….…………. 34
3.3.3. Interfaz de Consultar………………………………………………………………. 38
3.3.4. Interfaz de Ayuda……………..……………………………………………………. 40
3.4. Beneficios del Generador de Patrones de Diseño...…………………………………… 33
4. VALIDACIÓN DEL GENERADOR…………………………………………………………… 43
4.1. Gobierno Electrónico.……………..………………………………………………………. 43
4.2. Patrones de Diseño en el Gobierno Electrónico...……………………………………... 46
4.2.1. Patrones de Gobierno Electrónico “Info”………………………………………… 47
4.2.2. Patrones de Gobierno Electrónico “Datos del Personal”……..………..……… 49
4.2.3. Patrones de Gobierno Electrónico “Formulario”………………………………… 50
4.2.4. Patrones de Gobierno Electrónico “Formulario BD”….……………………..…. 53
CONCLUSIONES…………………………………………………………………………………….. 57
RECOMENDACIONES………………………………………………………………………………. 59
REFERENCIAS BIBLIOGRÁFICAS………………………………………………………………... 61
ANEXOS………………………………………………………………………………………………. 64
Patrones Ejemplo de Gobierno Electrónico………………………………………….……………. 65

ÍNDICE DE ILUSTRACIONES
pp
Figura 1. Pantalla de PatternBox……………………………………………………………… 21
Figura 2. Pantalla de Pattern Wizard…………………………………………………………. 23
Figura 3. Pantalla de DPAToolkit……………………………………………………………… 24
Figura 4. Plantilla del Patrón abstracto
Figura 5. Vista previa
Figura 6. Vista de código
Figura 7. Pantalla principal del generador…………………………………………………… 29
Figura 8. Barra de título………………………………………………………………………… 30
Figura 9. Barra de menú……………………………………………………………………….. 30
Figura 10. Menú desplegable de Patrones…………………………………………………… 33
Figura 11. Menú desplegable de Patrones/Patrones Abstracto…………………………….. 34
Figura 12. Menú desplegable de Patrones/Patrones Abstracto/Agregar..………………..
Figura 13. Menú desplegable de Patrones/Patrones Ejemplos…………………………….. 34
Figura 14. Menú desplegable de Patrones/Exportar…………………………………………. 34
Figura 15. Menú desplegable Consultar……………………………………………………….. 35
Figura 16. Menú desplegable Consultar/Consultar Patrones……………………………….. 36
Figura 17. Menú desplegable Consultar/Consultar Patrones/Abstracto…………………… 37
Figura 18. Menú desplegable Consultar/Consultar Patrones/Ejemplo……………………... 38
Figura 19. Menú desplegable Ayuda…………………………………………………………… 41
Figura 20. Ventana de Ayuda…………………………………………………………………… 41
Figura 21. Ventana de metodología de Trabajo………………………………………………. 42
Figura 22. Acerca del Generador de Patrones de Diseño…………………………………… 42
Figura 23. Estructura del patrón “Info”…………………………………………………………. 47
Figura 24. Estructura del patrón “Datos del Personal”………………………………………. 49
Figura 25. Estructura del patrón “Formulario”…………………………………………………. 51
Figura 26. Estructura del patrón “Formulario BD”…………………………………………….. 53

ÍNDICE DE TABLAS
pp
Tabla 1. Niveles de Automatización de Patrones…………………………………………... 25
Tabla 2. Componentes del modelo de estado del gobierno electrónico…………………. 46
Tabla 3. Patrones de Gobierno Electrónico “Info”………………………………………….. 48
Tabla 4. Patrones de Gobierno Electrónico “Datos del Personal”………………………... 50
Tabla 5. Patrones de Gobierno Electrónico “Formulario”………………………………….. 52
Tabla 6. Patrones de Gobierno Electrónico “Formulario BD”……………………………... 55

INTRODUCCIÓN
El estudio de patrones abarca diferentes áreas de estudio como la música y la literatura, el
arte, la arquitectura y la psicología. Los recientes enfoques en ingeniería de software
adoptando los patrones de software fueron altamente influenciados por Christopher
Alexander, un investigador de la Universidad de California, Berkeley, quien ha escrito
muchos trabajos sobre patrones encontrados en la arquitectura para casas, edificios, y
comunidades.
Muchas áreas del saber usan patrones de varias maneras: en música y literatura, un patrón
es la estructura o el diseño coherente de una canción o de un libro. En arte, un patrón es la
composición o plan de un trabajo de arte gráfico o plástico. En arquitectura, un patrón es un
diseño o un estilo arquitectónico, o los patrones de comportamiento de las personas, estudio
del que se encarga la psicología.
Los patrones de diseño se presentan como una disciplina de problema-solución que está en
constate evolución entre los diseñadores y desarrolladores que trabajan en el área del
desarrollo de software. Junto a esta evolución han surgido patrones no sólo de diseño, sino
también de análisis, usabilidad y arquitectónicos, pero que no son temas de este trabajo de
ascenso.
Dentro de los patrones de diseño se puede decir que existe dos grandes grupos: los
Patrones Generales de Software para Asignación de Responsabilidades (GRASP) y los
Patrones de diseño de GoF (Gang of Four). Los primeros ayudan al descubrimiento y
asignación de las responsabilidades que deben ser cumplidas en cada caso de uso. Estos
patrones hacen referencia a cuestiones básicas, comunes y fundamentales en el diseño.
Los segundos patrones de diseño, GoF más conocidos como la Banda de los Cuatro), cuyos
autores Gamma, Helm, Johnson y Vlissides publicaron un libro en 1995 que se volvió un
bestseller denominado Patrones de Diseño: Elementos de Software Orientados a Objetos
Reutilizables, donde los patrones de diseño se convierten en imprescindibles para todos los
diseñadores y desarrolladores de software orientado a objetos.
Basado en este bestseller, la autora de este trabajo de ascenso se propuso diseñar y
desarrollar un Generador de Patrones de Diseño (GEPADI) basado en los patrones de
diseño de GoF, en cuanto a sus basamentos teóricos y estructurales. Cabe destacar que
para seleccionar los patrones de GoF se realizó una investigación documental de todos los

2
patrones de diseño que existen en el desarrollo de software. Se seleccionó estos tipos de
patrones porque la aplicación que resultaría del diseño y desarrollo del Generador de
Patrones de Diseño (GEPADI) resulta un aporte académico, que sirve para el aprendizaje de
los alumnos de la Licenciatura en Computación.

1. PATRONES EN EL DESARROLLO DE SOFTWARE
Como introducción al capítulo uno (1) se plantea de forma breve el entorno en el cual
se desenvuelve el problema a investigar, así como sus objetivos. Luego se hace un
análisis sobre los patrones y cómo estos se adaptan al desarrollo de software. Se
clasifican según su nivel de abstracción y detalle, y el contexto particular en el cual se
aplican. Para luego entrar en más detalle en los patrones de diseño, específicamente
los de GoF que es el objetivo central de este trabajo de ascenso.
1.1. Planteamiento del problema
Uno de los paradigmas que maneja la programación orientada a objetos es la técnica
de la reutilización y en los últimos años se viene aplicando para el desarrollo de
software. Esto es debido a las ventajas que presenta la reutilización como lo son:
reducción de tiempos, disminución del esfuerzo de mantenimiento, eficiencia,
consistencia, fiabilidad y protección de la inversión en desarrollos, entre otros.
Para aplicar la reutilización existen diferentes mecanismos como los componentes, los
frameworks, los objetos distribuidos y los patrones de diseño. De estos mecanismos
de reutilización, los patrones de diseño son los que se van estudiar para poder
desarrollar el trabajo de ascenso
Este trabajo tiene como objetivo fundamental desarrollar una herramienta que genere
patrones de diseño que sirva de apoyo la enseñanza académica de los mismos. La
idea es que de un modo didáctico la herramienta sirva para la comprensión y
utilización de patrones de diseño de forma clara y correcta en la construcción de
software.
En la búsqueda de una herramienta de software libre que sirva para la generación de
patrones de diseño, sólo se encontraron aquellas que funcionan en forma de plug-in
de eclipse y sólo una está disponible para la plataforma Windows y cuya instalación no
funciona de manera óptima. Por otro lado existen herramientas de modelados de UML
que podría utilizarse como generador de patrones de diseño pero que son
herramientas propiamente creadas para tal fin. De esta manera se pudo constatar que

3
existe un vacío en desarrollo de los patrones de software en cuanto a la ausencia de
una herramienta específica de generación de patrones de diseño.
Formulación del problema
Por los motivos expuestos anteriormente se propone la creación de una herramienta
que funciones como Generador de Patrones de Diseño (GEPADI) que diseñe y
desarrolle catálogos de patrones que sirvan luego para ser exportados a otras
plataformas de trabajo y cumplan así su función de elementos reusables.
Pregunta de investigación
¿Es posible desarrollar un generador de patrones de diseño ejecutable que trabaje de
manera manual y automática, cuyos patrones creados puedan ser incorporados a
cualquier aplicación fácilmente?
Objetivos del Trabajo de Ascenso
El objetivo principal fue el siguiente:
Desarrollar un Generador de Patrones de Diseño (GEPADI) que sirva para
implementar cualquier plantilla como solución a un problema dado.
Para desarrollar este objetivo general es necesario cumplir los siguientes objetivos
específicos:
 Analizar los patrones de diseño desde el punto de vista de un enfoque para
poder focalizar mejor su estudio y así poder llevar la teoría a la práctica a
través del desarrollo de una herramienta.
 Estudiar el estado del arte de las herramientas utilizadas como generadores de
patrones de diseño para encontrar un punto de partida en esta investigación y
también para evaluar la originalidad de la herramienta que se está
proponiendo.
 Analizar cada uno de los requisitos que son necesarios para poner en marcha
la herramienta.
 Diseñar cada uno de las interfaces que va a contener el generador de patrones
de diseño para que el usuario pueda interactuar con ella de manera intuitiva.
 Desarrollar cada uno de los módulos de las interfaces a nivel de programación
para que el generador pueda actuar de manera automática.

4
 Validar la herramienta a través de la creación de un catálogo de patrones
perteneciente a un dominio específico para poder demostrar la utilidad que
tiene el generador a nivel académico y científico.
1.2. Definición de patrón
El concepto de patrón nace de Christopher Alexander cuando en 1977 un libro sobre el
tema, que describen los patrones de utilidad para el diseño y construcción, en el área
de la arquitectura. Esto incluye los patrones de diseño de toda una comunidad, de las
tierras agrícolas a los centros comerciales a lugares de culto y cementerios. Este libro
explica los patrones similares a los grupos de diseño de edificios, como una mansión o
en la escuela, arreglar habitaciones en una casa de acuerdo a su propósito, y el
paisaje exterior del edificio.
Este concepto es transportado al ámbito del desarrollo de software orientado a objetos
y se aplica al diseño. De allí es adoptado para el desarrollo en general y actualmente
se aplica en la mayoría de las etapas del proceso. Los patrones podrían quedar
definidos como soluciones simples y elegantes a problemas específicos y comunes del
diseño orientado a objetos. Son soluciones basadas en la experiencia y que se ha
demostrado que funcionan.
Un patrón se podría definir como una solución recurrente para un problema en un
contexto establecido. Podríamos entender un contexto como un entorno, situación o
condiciones interrelacionadas dentro de las cuales existe algo. Un problema se podría
ver como una cuestión insatisfecha, algo que se necesita investigar y resolver. Un
problema se puede especificar mediante un conjunto de causas y efectos.
Normalmente un problema está restringido al contexto en el que ocurre. La solución
puede hacer alusión a la respuesta al problema dentro del contexto, que nos permite
resolver las dificultades.
Un patrón se puede agrupar en un catálogo de acuerdo a sus principales
características: contexto, problema y solución, junto con otros aspectos importantes,
como causas y consecuencias.
1.3. 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

5
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.
Los patrones pueden aplicarse a nivel de: el 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). Por lo tanto, los patrones se pueden clasificar en patrones de análisis, de
arquitectura, de usabilidad y los que vamos a estudiar en este trabajo que son los
patrones de diseño. A continuación se hace una pequeña descripción de esta
clasificación para luego entrar en detalle en los patrones de diseño.
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 percibir el mundo y de
esta manera se pueden hallar soluciones informáticas a problemas dentro de un
contexto.
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, Page Template, Page Controller y Front Controller, entre otros
Patrones de usabilidad
Para Perzel (1999), un patrón de usabilidad se define como la descripción de
soluciones que mejoran los atributos de usabilidad. Los aspectos de usabilidad
tratados con estos patrones se refieren básicamente a aspectos de interacción entre el

6
usuario y el sistema. Para ello, se centran en la esencia de un problema y su solución,
abstrayendo los aspectos del diseño necesarios para aportar las soluciones.
Dentro del concepto de patrones de usabilidad entra también la definición de patrón de
interacción o patrón de interfaz de usuario, que describe una solución exitosa a un
problema recurrente concerniente a interfaz, en un contexto dado. También se puede
decir que un patrón de interacción es un medio de comunicación que se expresa en
una notación sencilla, a fin de ser entendida por las personas del equipo de diseño de
la interacción (Mahemoff y Johnston, 1998).
A continuación, se nombran algunos de los trabajos donde se recopilan los patrones
más relevantes en el área del desarrollo de interfaces de usuario.
 Patrones de usabilidad de Perzel (1999) para ambientes Web: describen una serie
de patrones orientados a problemas de usabilidad en la Web, abarcando tanto los
ambientes de web estáticos como dinámicos.
 Patrones de interacción de Welie y Traetteberg (2000): están centrados en
presentar soluciones a los problemas que el usuario final tienen al interactuar con
los sistemas. El trabajo de estos dos autores analiza y presenta los patrones de
interacción en las interfaces de usuario donde la usabilidad es la esencia en la
calidad del diseño, en su trabajo exponen patrones que facilitan el diseño de la
interfaces de usuario.
 Colección de patrones de usabilidad de Brighton (Griffiths, 2002): define un
conjunto pequeño de patrones de usabilidad que está orientado más al mundo
industrial que al académico, ya que estos patrones carecen de publicaciones que
destaquen en ambientes académicos. Aun así, son muy referenciados por el resto
de autores dentro del contexto de los patrones de usabilidad, por lo que tienen un
gran reconocimiento dentro de la comunidad científica.
 Patrones de diseño de la interacción de Tidwell (2005): estos patrones son
similares a los propuestos por Wilie y col. (2000) y Perzel (1999). Los protones
propuestos por Tidwell patrones están más orientados a representar aspectos del
diseño de la interfaz que a aspectos de usabilidad exclusivamente. Para Tidwell,
los patrones de interacción son una ayuda para diseñar el modelo conceptual que
hay detrás de la interfaz. Esto quiere decir que los diseñadores empiezan el

7
desarrollo del sistema por el diseño de la interfaz; según las necesidades del
usuario y después diseñan el modelo conceptual que hay detrás de esa interfaz.
También se puede hablar de otros tipos de patrones software, como son:
 Patrones de programación concurrente.
 Patrones de organización del código.
 Patrones de optimización de código.
 Patrones de robustez de código.
 Patrones de la fase de prueba.
 Patrones en la ingeniería de requerimientos
La diferencia entre estos tipos de patrones está en los diferentes niveles de
abstracción y detalle, y del contexto particular en el cual se aplican o de la etapa en el
proceso de desarrollo. Así, Los patrones de análisis se refieren a la etapa de análisis
del ciclo de vida de construcción de software. Los patrones de arquitectura son
estrategias de alto nivel que involucran a los componentes, las propiedades y
mecanismos globales de un sistema.
Para el propósito del presente trabajo de ascensor se consideró necesario analizar en
particular los Patrones de Diseño.
1.4. Patrones de diseño
Orígenes de los patrones de diseño
Las ideas de Alexander fueron utilizadas por Ward Cunningham y Kent Beck para
desarrollar un lenguaje de patrones (compuesto por cinco patrones) como guía de
iniciación a la programación en Smalltalk, presentando su trabajo en la OOPSLA’87
(Object-Oriented Programming Systems and Languages). Posteriormente, Coplien
(1992) fue recopilando y creando un catálogo de Idioms (es un tipo de patrón) propios
de C++ que fue posteriormente publicado en 1992 en su libro Advanced C++
Programming Styles and Idioms.
Durante los años comprendidos entre 1990 y 1994 diversos workshops sobre el tema
tuvieron lugar, especialmente en las diversas ediciones de la OOPSLA, hasta que en
el congreso de OOPSLA’94 Gamma, Helm, Jonhson y Vlissides (normalmente
referenciados como la Banda de los Cuatro – The Gang of Four – o simplemente por
GoF), recopilado su trabajo, que sería publicado en el afamado libro Design Patterns:

8
Elements of Reusable Object-Oriented Software en 1995. Este libro fue considerado
como el mejor libro de orientación a objeto de 1995 y el mejor libro de orientación al
objeto de todos los tiempos por la revista JOOP (Journal of Object Oriented
Programming) en su número de septiembre de 1995. Para conocer con un mayor
detalle la historia de los patrones software se puede visitar la página HistoryOfPatterns
(2011) en el WikiWiki Web de Cunningham.
Definición de los patrones de diseño
Alexander (1977) dice que “Cada patrón describe un problema que ocurre una y otra
vez en nuestro entorno, para describir después el núcleo de la solución a ese
problema, de tal manera que esa solución pueda ser usada más de un millón de veces
sin hacerlo siquiera dos veces de la misma forma”.
Elementos esenciales de un patrón: según Alexander (1977) estos son los cuatro
(4) elementos fundamentales que deben contener toda plantilla de un patrón.
1. Nombre del patrón: describe de alguna manera el problema, la solución y
consecuencia en una o dos palabras. Ampliando de esta manera nuestro
vocabulario de diseño.
2. Problema: aquí se describe el problema y su contexto. Puede ser que se describa
los problemas específicos de diseño, como la forma de representar los algoritmos
como objetos. Se podría describir las clases u objetos de estructuras que son
sintomáticos de un diseño flexible.
3. Solución: describen los elementos que componen el diseño, sus relaciones,
responsabilidades y colaboraciones. La solución no describe un diseño particular de
hormigón o de aplicación, ya que un patrón es como una plantilla que se puede aplicar
en muchas situaciones diferentes. En cambio, el patrón proporciona una descripción
abstracta de un problema de diseño y la forma en la disposición general de los
elementos (Clases y objetos en nuestro caso) los que resuelve.
4. Consecuencia: son los resultados y compromisos de aplicar el patrón. Las
consecuencias para el software se refieren a menudo al espacio y el tiempo de las
compensaciones. Pueden abordar los problemas del lenguaje y la aplicación. Dado
que la reutilización es a menudo un factor en el diseño orientado a objetos, las
consecuencias de un modelo son su impacto en la flexibilidad del sistema,

9
extensibilidad, o la portabilidad. El llistado de estas consecuencias de forma explícita
ayuda a entender y a evaluarlos.
Cualidades de un patrón de diseño
Lea (1994), en su artículo “Christopher Alexander: an Introduction for Object-Oriented
Designers” describe las cualidades que debe tener un patrón de diseño, las cuales se
resumen a continuación:
Encapsulación: cada patrón encapsula un problema bien definido y su solución en un
dominio particular. Los patrones deberían de proporcionar límites claros que ayuden a
cristalizar el entorno del problema y el entorno de la solución empaquetados en un
entramado distinto, con fragmentos interconectados. Los patrones son independientes,
específicos, y formulan con precisión suficiente para dejar en claro cuándo se aplican y
se capturan problemas reales.
Abstracción: los patrones sirven como abstracciones que contienen dominios
conocidos y experiencia, y podrían ocurrir en distintos niveles jerárquicos de
granularidad conceptual.
Extensión y variabilidad: cada patrón debería ser abierto por extensión o
parametrización por otros patrones, de tal forma que pueden aplicarse juntos para
solucionar un gran problema. Un patrón solución debería ser también capaz de realizar
una variedad infinita de implementaciones (de forma individual, y también en
conjunción con otros patrones). Los patrones pueden extenderse hasta arbitrariamente
niveles de detalle fino. Los patrones son utilizados en el desarrollo de software
mediante la búsqueda de una colección de entradas frente a las características
deseables de proyectos en cuestión, donde cada uno de estos a su vez puede requerir
sub-patrones de otros. La experimentación con posibles variantes y las pruebas de las
relaciones entre patrones junto con las limitaciones, ajustes y especializaciones
forman situaciones específicas y de refinamientos. Por ejemplo, mientras que sólo un
pequeño conjunto de patrones normalmente se aplican en el diseño de una cierta
comunidad de viviendas, cada casa será a su vez un micro-patrón. Debido a que los
detalles de las instancias de los patrones están encapsulados, estos pueden variar
dentro de los límites establecidos. Estos datos a menudo impactan y limitan aún más
los de otros modelos relacionados. Pero, de nuevo, esta variabilidad se mantiene
dentro de las fronteras de alto nivel de limitaciones.

10
Generatividad y composición: cada patrón, una vez aplicado, genera un contexto
resultante, el cual concuerda con el contexto inicial de uno o más de uno de los
patrones del catálogo. Está subsecuencia de patrones podría luego ser aplicada
progresivamente para conseguir el objetivo final de generación de un “todo” o solución
completa. Los patrones son aplicados por el principio de evolución fragmentación.
Pero los patrones no son simplemente de naturaleza lineal, más bien esos patrones en
un nivel particular de abstracción y granularidad podrían guiar hacia o ser compuestos
con otros patrones para modificar niveles de escala.
Equilibrio: cada patrón debe realizar algún tipo de balance entre sus efectos y sus
restricciones. Cada patrón se identifica con un espacio de soluciones que contiene un
invariante que minimiza el conflicto entre las fuerzas y sus limitaciones. Cuando un
modelo se utiliza en una aplicación, el equilibrio proporciona una razón para cada paso
del diseño, se remonte las limitaciones del problema. El fundamento que la solución
cumple con este equilibrio puede ser formal, derivación teórica, una abstracción de lo
empírico datos, las observaciones de la estructura en forma natural o los objetos
tradicionales, una serie de ejemplos convincentes, análisis de las soluciones deficiente
o errónea, o cualquier mezcla de estos.
Consecuencias del uso de patrones de diseño
 Los patrones guardan experiencias de diseño orientado a objetos. Además
nombran, evalúan y explican diseños que se repiten a menudo en los sistemas
orientados a objetos.
 Facilitan el aprendizaje de diseñadores junior, y permiten ahorro de tiempo en
la elaboración de diseños puesto que la toma de decisiones es automática;
debido a que ayudan a escoger alternativas de diseño.
 Facilitan la comunicación entre diseñadores debido a que establecen un marco
de referencia de terminología y justificación, puesto que son conocidas las
clases que intervienen en ellos y las interacciones entre los objetos.
 Mejoran la documentación y el mantenimiento de las aplicaciones.

11
Existen dos tipos de patrones de diseño: patrones de diseño GRASP y los patrones de
diseño de GoF los cuales se explican a continuación.
1.4.1. Patrones de diseño GRASP (General Responsability Assignment Software
Patterns)
Los Patrones Generales de Software para Asignación de Responsabilidades como se
le denomina en español, “describen los principios fundamentales de diseño de objetos
y la asignación de responsabilidades, expresados como patrones” Craig Larman
(2004).
Las responsabilidades están relacionadas con las obligaciones de un objeto en cuanto
su comportamiento, estás se representa a través de diagramas de interacción. Las
responsabilidades pueden pertenecer principalmente a dos categorías: hacer y
conocer.
Entre las responsabilidades de un objeto relacionadas con hacer podemos encontrar:
• Hacer algo en uno mismo.
• Iniciar una acción en otros objetos.
• Controlar y coordinar actividades en otros objetos.
Entre las responsabilidades relacionadas con conocer se encuentran:
• Estar enterado de los datos privados encapsulados.
• Estar enterado de la existencia de objetos conexos.
• Estar enterado de cosas que se puede derivar o calcular.
Las responsabilidades se asignan a las clases de los objetos durante el diseño de
objetos. Por ejemplo, podría declarar que “una Venta es responsable de la creación de
una LineaDeVenta” (un hacer), o “una Venta es responsable de conocer su total” (un
conocer”. Las responsabilidades relevantes relacionadas con conocer a menudo se
pueden inferir a partir del modelo del dominio, debido a los atributos y asociaciones
que describe.
Cada clase tiene ciertas responsabilidades, que son cumplidas a través de sus
métodos, y por la forma en que colabora con las otras clases. Las decisiones poco
acertadas sobre la asignación de responsabilidades de cada clase, dan origen a

12
sistemas y componentes frágiles y difíciles de mantener, entender, reutilizar o
extender.
Estructura de los Patrones GRASP
Al igual que otros autores en el área de patrones de software, Larman (2004) propone
su propia estructura para explicar los patrones de diseño que propone en su libro
“UML y Patrones” donde expones los patrones de GRASP.
Nombre del patrón: Experto en información
Solución: Asignar una responsabilidad a la clase que tiene la
información para cumplirla.
Problema que resuelve: ¿Cuál es el principio básico mediante el cual
asignaremos responsabilidades a los objetos?
Esta estructura es la que utiliza Larman (2004) para explicar cada uno de los patrones
generales de software de asignación de responsabilidades que propones. Y a través
de esta estructura se puede apreciar que un patrón, es una es una descripción de un
problema y la solución, a la que se da un nombre, y que se puede aplicar a nuevos
contextos.
Tipos de Patrones de GRASP:
 Patrón Experto en Información
Solución: Asignar una responsabilidad al experto en información, la clase que
cuenta con la información necesaria para cumplir la responsabilidad.
Problema: ¿Cuál es el principio fundamental en virtud del cual se asignan las
responsabilidades en diseño orientado a objetos?
Un modelo de clase puede definir docenas y hasta cientos de clases de
software, y una aplicación tal vez requiera el cumplimiento de cientos o miles
de responsabilidades. Durante el diseño orientado a objetos, cuando se definen
las interacciones entre los objetos, tomamos decisiones sobre la asignación de
responsabilidades a las clases. Si se hacen de forma adecuada los sistemas
tienden a ser más fáciles de entender, mantener y ampliar, y se nos presenta la
oportunidad de reutilizar los componentes en futuras aplicaciones.

13
 Patrón Creador
Solución: Asignar a la clase B la responsabilidad de crear una instancia de
clase A en uno de los siguientes casos:
• B agrega los objetos A.
• B contiene los objetos A.
• B registra las instancias de los objetos A.
• B utiliza específicamente los objetos A.
• B tiene los datos de inicialización que serán transmitidos a A cuando
este objeto sea creado (así que B es un experto respecto a la creación
de A).
B es un Creador de los objetos A.
Si existe más de una opción, prefiera a la clase B que contenga la clase A.
Problema: ¿Quién debería ser responsable de crear una nueva instancia de
alguna clase?
La creación de objetos es una de las actividades más frecuentes en un sistema
orientado a objetos. En consecuencia, es conveniente contar con un principio
general para asignar las responsabilidades concernientes a ella. El diseño bien
asignado, puede soportar un bajo acoplamiento, una mayor claridad, el
encapsulamiento y la reutilización.
 Patrón Bajo Acoplamiento
Solución: Asignar una responsabilidad para mantener bajo acoplamiento.
Problema: ¿Cómo dar a una clase dependencia escasa y a un aumento de la
reutilización?
El acoplamiento es una medida de la fuerza con que la clase está conectada a
otras clases, con que las conoce y con que recurre a ellas. Una clase con bajo
acoplamiento no depende de muchas otras, depende del contexto.
Una clase con Alto acoplamiento recurre a muchas otras, este tipo de clases no
es conveniente, pues presentan los siguientes problemas:
• Los cambios de las clases afines ocasionan cambios locales.
• Son más difíciles de entender cuando están aisladas

14
• Son más difíciles de reutilizar por que se requiere la presencia de otras
clases de las que dependen.
 Patrón Alta cohesión
Solución: Asignar una responsabilidad de modo que la cohesión siga siendo
alta.
Problema: ¿Cómo mantener la complejidad dentro de límites manejables?
En la perspectiva del diseño orientado a objetos, la cohesión es una medida de
cuan relacionadas y enfocadas están las responsabilidades de una clase. Una
alta cohesión caracteriza a las clases con responsabilidades estrechamente
relacionadas que no realicen un trabajo enorme.
Una clase con baja cohesión hace muchas cosas no afines o un trabajo
excesivo. No conviene este tipo de clases pues presentan los siguientes
problemas:
• Son difíciles de comprender.
• Son difíciles de reutilizar.
• Son difíciles de conservar.
• Son delicadas, las afectan constantemente los cambios.
Las clases con baja cohesión a menudo representan un alto grado de
abstracción o han asumido responsabilidades que deberían haber delegado a
otros objetos.
 Controlador
Solución: Asignar la responsabilidad del manejo de un mensaje de los eventos
de un sistema a una clase que represente una de las siguientes opciones:
• El sistema global (controlador de fachada).
• La empresa u organización global (controlador de fachada).
• Algo en el mundo real que es activo (por ejemplo el papel de una
persona) y que pueda participar en la tarea (controlador de tareas).
• Un manejador artificial de todos los eventos del sistema de un caso de
uso, generalmente denominados “Manejador <nombre caso de uso>”
(Controlador de casos de uso).

15
Se debe usar la misma clase de controlador con todos los eventos del sistema
en el mismo caso de uso. En la lista no figuran las clases ventana, aplicación,
vista ni documento, estas clases no deben ejecutar las tareas asociadas a los
eventos del sistema; generalmente las reciben y las delegan al controlador.
Problema: ¿Quién debería encargarse de atender un evento del sistema.
Un evento del sistema es un evento de alto nivel generado por un actor
externo; es un evento de entrada externa. Se asocia a operaciones del sistema:
las que emite en respuesta a los eventos del sistema.
 Polimorfismo
Solución: Cuando las alternativas o comportamientos relacionados varían
según el tipo (clase), asigne la responsabilidad para el comportamiento,
(utilizando operaciones polimórficas) a los tipos para los que varía el
comportamiento1
. No deben hacerse comprobaciones acerca del tipo del objeto
y no debe utilizarse la lógica condicional para llevar a cabo alternativas
diferentes basadas en el tipo.
Problema: ¿Cómo manejar las alternativas basadas en el tipo?
• La variación condicional es fundamental en el desarrollo de software
• Si se diseña una programa utilizando sentencias de la lógica
condicional, en el momento que aparezca una nueva variación, se
requerirán modificaciones en la lógica de los casos.
• Esto dificulta que el software se extienda con facilidad como nuevas
variaciones porque se tiende a necesitar cambios en varios sitios.
¿Cómo crear componentes software conectables?
• Viendo los componentes en las relaciones cliente-servidor, ¿cómo se
puede sustituir un componente servidor por otro, sin afectar al cliente?
 Fabricación Pura
Solución: Asignar un conjunto de responsabilidades altamente cohesivo a una
clase artificial o de conveniencia que no representa un concepto del dominio
del problema, algo inventariado para soportar alta cohesión, bajo acoplamiento
y reutilización.
1
El polimorfismo tiene varios significados relacionados. En este contexto, significa, “asignar el mismo nombre a
servicios en diferentes objetos” (Coad, 1995) cuando los servicios son parecidos o están relacionados.

16
Problema: ¿Qué objetos deberían tener la responsabilidad cuando no quiere
violar los objetos del Patrón de Alta Cohesión y Bajo Acoplamiento, u otro, pero
las soluciones que ofrece el Expertos (por ejemplo) no son adecuadas?
 Indirección
Solución: Asignar la responsabilidad a un objeto intermedio que medie entre
otros componentes o servicios de manera que no se acoplen directamente. El
intermediario crea una indirección entre los otros componentes.
Problema: ¿Dónde asignar una responsabilidad, para evitar el acoplamiento
directo entre dos (o más) cosas? ¿Cómo desacoplar los objetos de manera que
se soporte el bajo acoplamiento y el potencial para reutilizar permanezca más
alto?
 Variaciones Protegidas
Solución: Identifique los puntos de variaciones previstas o de inestabilidad;
asigne responsabilidades para crear una interfaz estable alrededor de ellos.
Problema: ¿Cómo diseñar objetos, subsistemas y sistemas de manera que las
variaciones o inestabilidades en estos elementos no tengan un impacto no
deseable en otros elementos?
1.4.2. Patrones de diseño GoF
Los patrones GoF, llamados así por Gang of Four, que en español significa Banda de
los Cuatro, formada por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides,
publicaron un libro en 1995 titulado: “Patrones de Diseño: Elementos de Software
Orientados a Objetos Reutilizables” donde describen 23 patrones clasificados según
su propósito. Con este libro se abrió un nuevo capítulo en el diseño y desarrollo de
software. Ellos clasifican los patrones de diseño en tres (3) categorías basadas en su
propósito: creacionales, estructurales y de comportamiento. A continuación se explican
cada uno de ellos y los patrones que lo contienen.

17
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:
 Abstract Factory: Proporciona una interfaz para crear familias de objetos
relacionados sin especificar sus clases concretas
 Builder: Separa la construcción de un objeto complejo de su representación
 Factory Method: Define una interfaz para crear un objeto, pero deja que sean
las subclases las que decidan que clase instanciar.
 Prototype: Especifica los tipos de objetos a crear por medio de una instancia
prototípica, y crea nuevos objetos copiando este prototipo
 Singleton: Garantiza que una clase solo tenga una instancia y proporciona un
punto de acceso global a la misma.
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: Convierte la interfaz de una clase en otra distinta, que es la que
esperan los clientes.
 Bridge: Desacopla una abstracción de su implementación, de manera que
puedan variar de forma independiente.
 Composite: Combina objetos en estructuras de árboles para representar
jerarquías de parte-todo.
 Decorator: Añade dinámicamente nuevas responsabilidades a un objeto.
Alternativa de la herencia.
 Facade: Proporciona una interfaz unificada para un conjunto de interfaces de
un subsistema.
 Flyweight: Usa el compartimiento para permitir un gran número de objetos de
grano fino de forma eficiente.

18
 Proxy: Proporciona un sustituto o representante de otro objeto para controlar el
acceso a este.
De Comportamiento: tienen que ver con los algoritmos y la asignación de
responsabilidades entre objetos. Los patrones del comportamiento no sólo describir los
patrones de los objetos o clases, sino también los patrones de comunicación entre
ellos. Los patrones de comportamiento de clase usan la herencia para distribuir el
comportamiento entre clases. Los patrones de comportamiento de objetos nos
permiten analizar los patrones de comunicación entre objetos interconectados. Dentro
de estos patrones se encuentran:
 Chain of Responsibility: Evita acoplar el emisor de una petición a su receptor, al
dar a más de un objeto la posibilidad de responder a la petición.
 Command: Encapsula una petición en un objeto, permitiendo así entre otras
cosas parametrizar a los clientes con distintas peticiones, encolar o llevar un
registro de las mismas.
 Interpreter: Dado un lenguaje, define una representación de su gramática junto
con un intérprete que usa dicha representación para interpretar las sentencias
del lenguaje.
 Iterator: Proporciona un modo de acceder secuencialmente a los elementos de
un objeto agregado sin exponer su representación interna
 Mediator: Define un objeto que encapsula cómo interactúan un conjunto de
objetos.
 Memento: Representa y externaliza el estado interno de un objeto sin violar su
encapsulación
 Observer: Defina una dependencia de uno a muchos entre objetos, de forma
que cuando un objeto cambia de estado, se notifican y se actualizan
automáticamente todos los objetos que dependen de él.
 State: Permite que un objeto modifique su comportamiento cada vez que
cambia su estado interno.
 Strategy: Define una familia de algoritmos, encapsula cada uno de ellos y los
hace intercambiables.
 Template Method: Define en una operación el esqueleto de un algoritmo
delegando en las subclases algunos de sus pasos.

19
 Visitor: Representa una operación sobre los elementos de una estructura de
objetos. Permite definir una nueva operación sin cambiar las clases de los
elementos sobre los que opera.

2. ESTADO DEL ARTE
Desde que Gamma, Helm, Johnson y Vlissides se unieron en 1995 para escribir el libro
“Patrones de Diseño: Elementos de Software Orientados a Objetos Reutilizables”, el
número de patrones de diseño se vio incrementado y hoy podemos contar con una
infinidad de patrones. Existen en Internet muchos repositorios de patrones de diseño que
son continuamente actualizados, mantenidos y documentados. Uno de los primeros
establecidos en 1995 se llama “Portland Pattern Repository” y se mantienen por Ward
Cunningham. Pero, en estos repositorios muchas veces no se consiguen patrones de
diseño para ciertos dominios específicos, y de allí la necesidad de recurrir a un generador
de patrones de diseño.
A parte de que existen estos repositorios de patrones de diseños existen en área de
investigación del desarrollo de software algunos generadores de patrones de software que
han surgido y otras herramientas como los modeladores de UML que se prestan para esta
tarea pero que no están creadas para tal fin. Este capítulo trata sobre el estado del arte de
estas herramientas, esto se hizo con la finalidad de encontrar un punto de partida para
esta investigación y para también evaluar la originalidad de la herramienta que se está
proponiendo.
2.1. Generadores de patrones de diseño
En el área de los generadores de patrones de diseño se encontraron tres (3) herramientas
que funcionan en forma de plug-in1
bajo Eclipse, y una (1) que se puede correr o ejecutar
(.exe) bajo el sistema operativo Windows, a continuación se describen de forma breve:
 PatternBox (2011) es un editor de patrones de diseño para Eclipse, este editor
crea las clases en Java y las interfaces se pueden personalizar según las
necesidades de la aplicación. La mayoría de los enfoques son dominados por el
asistente, esto significa que el usuario debe completar la instancia de los patrones
de diseño una vez terminado el proceso de generación del patrón. Una de las
1
es una aplicación que se relaciona con otra para aportarle una función nueva y generalmente muy específica. Esta
aplicación adicional es ejecutada por la aplicación principal e interactúan por medio de la API (Interfaz de programación de
aplicaciones).

21
 ventajas que presenta el PatternBox es que tiene la libertad y flexibilidad para
introducir nuevos patrón cuando se desee.
PatternBox (2011) tiene un generador de plantillas basado en código. El generador
hace uso de las herramientas de Eclipse Java Development Tooling (JDT) y el
Plug-in Development Environment (PDE). Ambas herramientas deben estar
disponibles para ejecutar el plug-in. El mecanismo de plantilla basado en XML
permite definir las plantillas de código propio. El plug-in de PatternBox incluye 16
patrones de diseño de GoF. En la Figura 1 se muestra una pantalla de
PatternBox.
Figura 1. Pantalla de PatternBox (2011)

22
Comparado el PatternBox con el GEPADI, el GEPADI no es un plu-in de Eclipse,
es un ejecutable (.exe) bajo la plataforma de Windows. También tiene un
generador de plantillas que trabaja con XML. Aún no contiene ningún patrón de
diseño de GoF pero se pueden incluir en su biblioteca como cualquier otro patrón
de diseño.
 AlphaWorks Design Pattern Toolkit (2011): Este es un plug-in de Eclipse en la
misma línea como PatternBox. En el portal de la aplicación hacen mención a: “El
patrón se puede considerar como una transformación entre la definición de la
aplicación de entrada y el conjunto de artefactos de origen generado. Hay
etiquetas de plantilla que le permiten transformar la definición de la aplicación en
una forma intermedia XML”.
Comparado el AlphaWorks Design Pattern Toolkit con el GEPADI, el GEPADI no
es un plu-in de Eclipse, es un ejecutable (.exe) bajo la plataforma de Windows y se
puede decir que trabaja con plantillas una vez que están creadas en la biblioteca,
pero también se pueden ir creando a través del llenado de formulario que son
guardado en formato XML.
 Pattern Wizard (Vandyke, 2009): es un plug-in que funciona bajo la plataforma de
Eclipse. Este es un generador de patrones de diseño que utiliza Wizard para su
creación y generación. Funciona de la siguiente manera: el control comienza con
el objeto PatternWizard. Se pasa el control a la página principal, que muestra una
selección de modelos y lenguajes. Con base en esa entrada, el Wizard genera una
nueva página y la presenta al usuario al hacer clic en el botón Siguiente. Esta
nueva página pide al usuario que añada archivos al modelo, en diferentes
funciones dependiendo del modelo específico. Esta página se llama MainPage
<pattern>, donde <pattern> es el nombre específico elegido. Si el Wizard requiere
más información para generar el modelo, el control pasa a otra página del
asistente. Esta página se llama MatchPage <pattern>, en este sentido el usuario
coincide con la información del patrón. En cualquier caso, la última página hace las
modificaciones necesarias para que el código y el control vuelvan al Pattern

23
Wizard para cerrar la herramienta. En la Figura 2 se muestra una pantalla de
Pattern Wizard.
Comparado el Pattern Wizard con el GEPADI, este no utiliza Wizard para la
creación de sus patrones de diseño, la construcción del mismo se basa en el
llenado de un formulario.
Figura 2. Pantalla de Pattern Wizard
 Design Pattern Automation Toolkit (DPAToolkit, 2011): es una herramienta para
ayudar en el desarrollo de software a través de patrones de diseño. El diseño se
puede visualizar a través de diagramas de clases y los patrones de diseño que se
generan se pueden incorporar en cualquier diseño fácilmente.
DPAToolkit contiene los 23 patrones de diseño de GoF. Aparte de estos, los
usuarios pueden desarrollar sus propios patrones de diseño y añadirlos a sus
diseños o intercambiarlos con otras aplicaciones, esto es gracias a que están

24
guardados en formato XML. DPAToolkit viene con los generadores de código
siguiente: C#, C++, Java, VB.NET. Nuevos generadores de código puede ser
fácilmente conectado a la aplicación.
 Esta herramienta muestra el uso de patrones de diseño en varios idiomas. Tiene
una manera de crear nuevos patrones de diseño (que no sean los patrones GoF)
desde el lado del cliente utilizando un lenguaje de descripción de patrones. Sin
embargo, esta herramienta no modificar el código existente para ajustarse al
patrón, sólo la que ésta genera. Para su instalación se requiere Windows Vista,
XP, NT o 2000, además del Microsoft .NET Framework Version 3.5 o el más
reciente. En la Figura 3 se muestra una pantalla de DPAToolkit.
Figura 3. Pantalla de DPAToolkit (2011)
Comparado el DPAToolkit con el GEPADI, el GEPADI también puede visualizarse
los patrones de diseño a través de los diagramas de clase y se pueden exportar a
cualquier diseño que permita XML. El GEPADI aún no contienes los 23 patrones

25
de diseño de GoF pero se pueden incluir en su biblioteca como cualquier otro
patrón de diseño. Y al igual que DPAToolkit trabaja bajo la plataforma de Windows
y genera código en Java, VB.NET y C#.
2.2. Herramientas de modelados de UML
Existen otras herramientas específicamente de UML (área de modelado de UML) que se
pueden adaptar a la generación de patrones de diseño, pero que no están diseñadas
propiamente para este fin, como lo son: MVCASE Tool (2003) y las que se muestran en la
Tabla 1, tomada de Bulka (2003).
Tabla 1 Niveles de Automatización de Patrones
(Bulka; 2003)
Nivel de
Automatización
Descripción Ventaja Desventaja
Plantillas Simples
ej. UMLStudio
Almacena la estructura
de la solución de un
patrón.
Inserta un grupo
relacionado de clases en
el área de trabajo.
Estructuras pre
construidas que
ahorran tiempo en la
construcción de
modelos.
Es necesario el manual de
personalización.
Plantillas Parametrizadas
ej. TogetherJ
ej. ModelMaker
ej. Cogent
Solicita la clase en el
cuadro de dialogo y el
nombre de los método
antes de insertar un
grupo de clases
relacionadas al área de
trabajo.
Integra las clases de
patrones recién
creados con las
clases existen.
Introducir los nombres de
las clases y los métodos
puede ser tedioso y
propenso a errores.
Patrones Inteligentes
ej. ModelMaker
Las clases que se han
insertado como parte de
los patrones
automáticamente e
inteligentemente
responden a cambios en
otras partes del modelo
de UML.
La integridad de los
patrones se
mantiene.
Si no se es conocedor del
área, el desarrollo puede
tenderse a confusión a
sentirse limitado cuando el
modelo se autocambia.
Hay que dejar en claro que estas son herramientas de automatización de diseño que al
final, crean clases y métodos específicos en el área de trabajo de UML. No automatizan el
diseño, el usuario al final debe analizar el contexto y luego elegir el patrón de uso.

26
El enfoque de Plantillas Simples se puede definir como un cátalo de patrones de diseño
por el cual el usuario navega y visualiza miniaturas de varios diseños. El usuario
selecciona una aplicación de patrones de diseño y posteriormente aparece en el área de
trabajo. Finalmente, el usuario realiza las modificaciones necesarias a los nombres de
clase y el método.
El enfoque de las Plantillas Parametrizadas permiten fijar las pautas a las clases
existentes y ofrecer la posibilidad de personalizar los aspectos de la aplicación de la
plantilla utilizando el asistente cuadros de diálogo. Una desventaja de plantillas
parametrizadas es que suelen ser encerrados en cuadro de diálogo, escribir y recordar los
nombres de clases y métodos es tedioso y propenso a errores, a menos que se
proporciones un centro de navegación o biblioteca con los nombres.
Y por último está el enfoque de Patrones Inteligentes que da un paso en la automatización
de diseño y ofrece la idea de que los patrones son dinámicas de primera clase en un
modelo UML. Una vez aplicado, la herramienta de modelado recuerda que las clases
están involucradas en el patrón y protege activamente el patrón de daños accidentales.
Además, como parte del cambio de modelo, las clases y métodos empleados en el
modelo se actualizan automáticamente a medida que sea necesario. Por ejemplo, si
cambia el nombre del método, el código en el método de la clase también se modifica de
forma automática, de esta manera se llama al método que cambio el nombre. Del mismo
modo, si un método se elimina, el método de la clase también se elimina.
El diseño orientado a objetos y los patrones de modelado en UML son notaciones
complejas, el diseñador de software debe entender y saber cómo seleccionar las opciones
apropiadas que ofrece los cuadros de diálogo del asistente. Así, el papel del programador
como del diseñador no es automática, aunque algunas herramientas en cierto modo a
ayudan a este proceso, así por ejemplo, Cogent, por Budinsky y col. y Vlissides (1996)
ofrecen asistentes, documentación en línea y mucho más ayuda sensible al contexto para
ayudar a las deliberaciones del diseñador.
Se puede concluir que entre los niveles de automatización de los patrones el GEPADI
(Generador de Patrones de Diseño) se encuentra en el enfoque de Patrones Inteligente
con la diferencia que se puede ir modificando a medida que se va construyendo el patrón.

3. GENERADOR DE PATRONES DE DISEÑO (GEPADI)
En este capítulo se desarrolla todo lo relacionado al generador de patrones de diseño,
comenzando por los requisitos necesarios para su uso, como está estructurado y desarrollado,
como funciona cada una de sus interfaces y los beneficios que aporta al desarrollo de software
y a la investigación en el área de la ingeniera de software.
3.1. Requisitos del Generador de Patrones de Diseño (GEPADI)
Los requisitos que se tomaron en cuentan para el desarrollo del GEPADI fueron a nivel de
software, hardware, humanos y legales.
3.1.1. Requisitos de software
Para la instalación del ejecutable del generador se requiere:
 Windows 7 profesional 32 bits
3.1.2. Requisitos de hardware
Los requisitos de hardware mínimos son:
 Procesador Pentium 1.8 Ghz
 Memoria RAM 2.00 GB
 Espacio disponible en disco 10 GB
 Unidad de DVD
3.1.3. Requisitos humanos
Toda persona que desee y necesite utilizar el generador de patrones de diseño debe estar en
conocimiento de qué son los patrones dentro de la ingeniería de software y su aplicación.
3.1.4. Requisitos legales
Este generador fue diseñado y desarrollado sólo para fines de investigación, teniendo como
primer resultado la generación de los patrones de diseño en el dominio especifico de gobierno
electrónico, como se demuestra en el siguiente capítulo.

28
3.1.5. Requisitos funcionales
Para facilitar el trabajo con los patrones de diseño, de forma que el usuario pueda aplicarlos
fácilmente, el generador cumple con los siguientes aspectos:
 A partir de los elementos que constituyen un patrón de diseño, generar automáticamente
la declaración de clases, relaciones, atributos y métodos, y permitir hacer cambios sobre
los elementos generados.
 Mantiene la integridad del significado de los patrones implicados en un sistema, es decir,
se debe comprobar que no se rompe la estructura de una instancia de un patrón tras
una acción (eliminar un atributo,...). Por este motivo, se deberá llevar un control sobre
las clases que participan en patrones y las ajenas a los mismos.
 Es una herramienta que está diseñada para crear e integrar nuevos patrones y de esta
manera se va alimentando el catálogo de patrones que maneja actualmente el GEPADI.
 El usuario puede guardar los patrones de diseño desarrollado, así como sus ejemplos.
También es capaz de añadir, eliminar y modificar elementos individuales del patrón de
diseño (clases, métodos, relaciones…).
 Cuenta con una ayuda clara y práctica sobre la forma en la que los patrones de diseño
pueden ser aplicados, explica el manejo de la herramienta. Todo esto sirve para darle
soporte a la herramienta y proporciona una ayuda al usuario en cuanto al manejo de la
herramienta.
Un aspecto importante y que está incluida en la metodología de trabajo, es la forma en la que
se va a mostrar la información al usuario. La herramienta muestra una visión clara del diseño,
de las acciones disponibles y cómo dichas acciones afectan al usuario. Algunas de las distintas
perspectivas en que se muestra el patrón de diseño al usuario son:
 Información: en esta parte se muestra lo que es la plantilla del patrón de diseño, en ella
está incluida toda la descripción de patrón, contiene gran parte de la metodología de
trabajo. En la Figura 4 se observa un ejemplo de como el GEPADI muestra la
información del patrón abstracto “Info”.

29
Figura 4. Plantilla del patrón abstracto
 Vista Previa: se muestra gráficamente la estructura del patrón en forma de diagrama de
clase. A partir de esta vista, se puede copiar el diagrama y exportar en cualquier formato
gráfico (formatos GIF, BMP…), desde esta vista también se puede imprimir la estructura
del patrón. En la Figura 5 se observa un ejemplo de como el GEPADI muestra la vista
previa.

30
Figura 5. Vista previa
 Código: cada estructura o diagrama de clases puede ser generado automático en
diferentes código, bien sea en Java, VB. Net o C#. Este código es producido en un
fichero que es directamente compilable, que representa el esqueleto de la aplicación que
se ha diseñado. En la Figura 6 se observa un ejemplo de como el GEPADI muestra los
diferentes código en que es implementado la clase.
Figura 6. Vista de código

31
3.1.6. Requisitos no funcionales
Los requisitos no funcionales que se tomaron en cuentan para desarrollo del generador fueron
los siguientes:
 La portabilidad, todo patrón que se desarrolle en GEPADI puede ser exportado a
cualquier otra herramienta de modelado que maneje el formato XML
3.2. Metodología de trabajo
La metodología de trabajo utilizada para desarrollar el Generador de Patrones de Diseño
(GEPADI) fue la aplicada por GoF en su libro Patrones de Diseño: Elementos de Software
Orientados a Objetos Reutilizables, específicamente la aplicada para describir cada uno de los
elementos que contiene la plantilla de los patrones de diseño.
Plantilla de un patrón dentro de GEPADI
La metodología de trabajo para describir un patrón de diseño varía dependiendo del autor que
se seleccione, y a pesar de que esos autores han propuesto plantillas ligeramente distintas, la
mayoría definen los mismos conceptos básicos, un nombre de patrón, definición de un
problema, su solución y consecuencia, es decir, una forma básica basada en el libro de
Alexander (1977) como se vio el capítulo uno (1).
Los fundamentos en los cuales se basó la metodología de trabajo del Generador Patrones de
Diseño (GEPADI) para describir sus patrones fue el utilizado por GoF, esto es debido a su
sencillez y porque brinda un formato consistente, a través de plantillas, lo cual le da una
estructura uniforme a la información que se muestra en la interfaz. Por otro lado con esta
plantilla que está más o menos estandarizada es mucho más fácil aprender, comparar y utilizar
los patrones de diseño, debido a la practicidad de su estructura. Y como es una metodología de
trabajo conocida entre los diseñadores puede constituirse efectivamente en un medio de
comunicación uniforme entre desarrolladores de software.
Cada patrón del GEPADI se adapta a la metodología de trabajo utilizada por GoF que no es
más que la descripción del patrón de diseño constituida por un nombre, intención, motivación,
consecuencia, y otros elementos que la constituyen. A continuación se definen en detalle cada
uno de esos elementos:

32
 Nombre del patrón: este transmite la esencia del patrón de manera significativa, por lo
general se expresa en inglés. Un buen nombre es de vital importancia, ya que pasara a
formar parte del vocabulario que conforman los repositorio de los patrones de diseño y
será reconocido dentro de la comunidad de desarrolladores de software.
 Clasificación del patrón: se clasifica según el libro de GoF en: de creación, estructural
o de comportamiento, pero en este trabajo de ascenso los patrones de diseño no se
limitaran a esta clasificación.
 Propósito: representa una breve declaración que responde a las siguientes preguntas:
¿Cuál es el patrón de diseño hacer?, ¿cuál es su razón y su intención? Y ¿qué problema
pretende resolver el patrón?
 También conocido como: otros nombres de uso común para el patrón de diseño.
 Motivación: es el escenario que ilustra un problema de diseño y cómo las estructuras
de clases y objetos en el patrón resuelven el problema. El escenario ayuda a entender la
descripción más abstracta del patrón que sigue.
 Aplicabilidad: usos comunes y criterios de aplicabilidad del patrón, respondiendo a las
siguientes preguntas: ¿Cuáles son las situaciones en las que se puede aplicar el patrón
de diseño?, ¿cuáles son los ejemplos de los medianos diseños en el que el patrón
puede aplicarse?, ¿cómo se puede reconocer esas situaciones?
 Estructura: la estructura de los patrones de diseño viene a estar representada por
diagramas de clase de UML 2.0. A diferencia de la metodología de GoF aquí no se
utilizan los diagramas de interacción para ilustrar la secuencia de peticiones y
colaboraciones entre objetos.
 Participantes: enumeración y descripción de las entidades abstractas (y sus roles) que
participan en el patrón. Vienen a ser las clases y/o los objetos que participan en el
patrón de diseño y sus responsabilidades.
 Colaboraciones: explicación de las interrelaciones que se dan entre los participantes.
Cómo los participantes colaboran para llevar a cabo sus responsabilidades.
 Consecuencias: consecuencias positivas y negativas en el diseño derivadas de la
aplicación del patrón.
 Implementación: técnicas o comentarios oportunos de cara a la implementación del
patrón, respondiendo a preguntas como estás: ¿Qué dificultades, sugerencias o técnicas
deben tener en cuenta al implementarse el patrón?, ¿hay cuestiones específicas del
lenguaje?
 Código de ejemplo: fragmentos de código que ilustran cómo se puede implementar el
patrón de diseño en VisualBasic, Java o C# (en GEPADI).

33
 Usos conocidos: ejemplos del patrón de diseño encontrado en los sistemas reales. Se
incluye por lo menos dos ejemplos de los diferentes dominios.
 Patrones relacionados: Referencias cruzadas con otros patrones, respondiendo a
preguntas como estás: ¿Qué patrones de diseño están estrechamente relacionados con
este?, ¿cuáles son las diferencias más importantes?
3.3. Interfaces de usuario de GEPADI
Las interfaces de usuario del Generador de Patrones de Diseño las constituyen todas aquellas
pantallas con las cuales el usuario va a interactuar, estas son: la interfaz principal, la interfaz de
patrones, consultar y ayuda. Para acceder a la Interfaz de patrones y consultar será a través de
los menús desplegables que se encuentra en la barra de menú que se encuentra en la interfaz
principal. A continuación se explicara cada una de las interfaces.
3.3.1. Interfaz principal
La interfaz principal está constituida por la barra de título y la barra de menú, en la parte central
se encuentra el logo del generador de patrones de diseño. En la Figura 7 se pueden ver los
elementos que conforman la interfaz principal.
Barra de menúBarra de título
Cerrar
Maximizar
Minimizar

34
Figura 7. Pantalla principal del generador
Barra de título: está ubicada en la parte superior de la pantalla principal y lleva por nombre
“Generador de Patrones de Diseño (GEPADI)”, en la Figura 8 se puede observar la barra de
título del generador.
Figura 8. Barra de título
Barra de menú: está ubicada debajo de la barra de título, está compuesta por los menús:
Patrones, Consultar y Ayuda, como se muestra en la Figura 9. A través de esta barra de menú
se tendrá acceso a las interfaces de Patrones, Consultar y Acerca de.
Figura 9. Barra de menú
3.3.2. Interfaz de Patrones
La interfaz de Patrones la constituyen los patrones abstractos, los patrones ejemplos y exportar,
como se observa en la Figura 10.
Figura 10. Menú desplegable de Patrones
 Patrones Abstractos: se puede definir que un patrón es la abstracción de una forma
concreta que puede repetirse en contextos específicos. En la Figura 11 se muestra la

35
ventana correspondiente a la creación y edición de estos patrones. Los elementos que
constituyen esta ventana son: agregar, modificar, eliminar y cerrar.
Figura 11. Menú desplegable de Patrones/Patrones Abstracto
 Agregar patrón abstracto: la Figura 12 muestra la ventana donde se refleja la plantilla
del patrón, esta contiene: nombre, tipo, intención (propósito), motivación, aplicabilidad,
colaboración, consecuencia, implementación, patrones ejemplos y patrones
relacionados. Todos estos elementos constituyen parte de la metodología de trabajo,
quedando en otra ventana la vista previa (que constituye la estructura del patrón) y el
código; ambos conforman también parte de la metodología de trabajo.
En la parte inferior se encuentra para agregar o eliminar los Atributos de cada patrón
conformado por los siguientes elementos. Tipo de atributo, nombre, tipo, modificador y
descripción. Una vez ingresado la información de los atributos se ve reflejado en la parte
inferior.

36
Figura 12. Menú desplegable de Patrones/Patrones Abstracto/Agregar
 Patrones Ejemplos: estos patrones representan de manera práctica los patrones
abstractos. En la Figura 13 se muestra la ventana donde se refleja la plantilla del patrón
ejemplo, esta contiene: patrones, tipo, nombre y solución.
En la parte inferior se encuentra para agregar o eliminar los Atributos de cada patrón
conformado por los siguientes elementos. Tipo de atributo, nombre, tipo, modificador y
descripción. Una vez ingresado la información de los atributos se ve reflejado en la parte
inferior.

37
Figura 13. Menú desplegable de Patrones/Patrones Ejemplos
 Exportar: con esta interfaz se puede exportar todos los patrones de diseño a cualquier
plataforma o aplicación que soporte XML, como se puede observar en la Figura 14.

38
Figura 14. Menú desplegable de Patrones/Exportar
3.3.3. Interfaz de Consultar
La interfaz de Consultar la constituyen los patrones a consultar (Consultar Patrones), que son
los abstractos y los ejemplos, los que fueron creados y modificados en la interfaz de patrones
explicada en la sección anterior en las Figuras 15 y 16 se pueden observar el menú
desplegable de Consultar y Consultar Patrones respectivamente .
Figura 15. Menú desplegable Consultar

39
Figura 16. Menú desplegable Consultar/Consultar Patrones
 Consultar Patrones Abstracto: muestra todos los patrones abstractos que hasta el
momento se han elaborado en el GEPADI como se muestra en la Figura 17, contiene
los siguientes elementos: información (plantilla del patrón), código (muestra el código en
java, VB. Net y C#), vista previa (muestra la representación gráfica en forma de
diagrama de clases) y cerrar (para salir de la ventana de consulta).
Figura 17. Menú desplegable Consultar/Consultar Patrones/Abstracto

40
 Consultar Patrones Ejemplos: muestra todos los patrones abstractos que hasta el
momento se han elaborado en el GEPADI como se muestra en la Figura 18, contiene
los siguientes elementos: información, código (muestra el código en java, VB. Net y C#),
vista previa (muestra la representación gráfica en forma de diagrama de clases) y cerrar
(para salir de la ventana de consulta).
Figura 18. Menú desplegable Consultar/Consultar Patrones/Ejemplo
3.3.4. Interfaz de Ayuda
La interfaz de Ayuda está conformada por Ayuda, Metodología de trabajo y Acerca del
generador como se muestra en la Figura 19.

41
Figura 19. Menú desplegable Ayuda
 Ayuda: muestra una guía de usuario de como se maneja el GEPADI y a descripción de
sus principales pantallas como se muestra en la Figura 20.
Figura 20. Ventana de Ayuda
 Metodología de Trabajo: describe cada uno de los elementos que constituyen la
metodología de trabajo en la que se basó el GEPADI para crear la plantilla del patrón.
En la Figura 21 se observa la ventana correspondiente a la metodología de trabajo.

42
 Acerca del Generador: hace referencia al título de la herramienta, su versión, el
departamento al cual pertenece, así como la universidad donde fue desarrollado. Y al
final se presenta una pequeña descripción de la naturaleza y finalidad del trabajo. En la
Figuras 22 se puede observar la ventana respectiva.
Figura 22. Acerca del Generador de Patrones de Diseño
Figura 21. Ventana de Metodología de trabajo

43
3.4. Beneficios del Generador de Patrón de Diseño (GEPADI)
 La herramienta permite crear, ver y modificar la información de cada patrón de diseño.
 A medida que vamos construyendo el patrón de diseño podemos irlo visualizando.
 La transformación de los distintos patrones a código: Java, VB.net y C#.
 Se pueden crean patrones de dominio específicos y así alimentar los repositorios que se
encuentran en internet o que sirvan de apoyo para los trabajos de investigación.
 Debido a que se utilizó XML para el intercambio de datos, se puede fácilmente importar
o exportar cualquier información que se desarrolló en el generador, esto lo convierte en
una herramienta de soporte para otras plataformas de trabajo.
 El patrón de diseño generado puede ser exportado a plataformas de trabajos MDA, y ser
transformados de manera directa a modelos de navegación o modelos de interfaces
según sea el caso de aplicación.
 Al exportar el patrón de diseño a una herramienta de modelado puede convertirse de
una vez en tablas que conforman las bases de datos.

4. VALIDACIÓN DEL GENERADOR
Para validar el Generador de Patrones de Diseño, se generó una serie de patrones en el
área de gobierno electrónico. Estos vienen a ser el caso práctico en el cual se realizaron las
pruebas del generador de parones de diseños. Cabe mencionar que se pueden diseñar y
desarrollar cualquier patrón de diseño abstracto que cumplan con los requisitos exigidos
como regla universal (nombrados en el capítulo 3) de toda clase.
4.1. Gobierno Electrónico
El concepto de gobierno electrónico siempre está vinculado con el uso de las tecnologías de
la información y la comunicación (TIC) ya que está vinculado con los procesos internos de
gobierno y con los procesos externos de interacción entre el estado y los ciudadanos.
Otros de los conceptos que se pueden mencionar son:
 Para Banco Mundial, el Gobierno Electrónico refiere al uso por parte de las agencias
gubernamentales de las TIC, que tienen la capacidad de transformar las relaciones
con el ciudadano, las empresas y otras agencias gubernamentales.
 Es el uso de las tecnologías de información y comunicación por parte de las
instituciones de gobierno, para mejorar cualitativamente los servicios e información
ofrecidos a los ciudadanos, aumentar la eficiencia y eficacia de la gestión pública e
incrementar sustantivamente la transparencia del sector público y la participación
ciudadana (OEA, 2006).
 Para el Banco Interamericano de Desarrollo (2003), “Desde un punto de vista
tecnológico, el Gobierno Electrónico (...) es la capacidad que ofrecen las TIC para
desarrollar y ofrecer información y servicios públicos a través de medios telemáticos,
habitualmente Internet”.
Como se puede observar en estas definiciones las TIC siempre están inmersas, pero tratan
de ir más allá del simple hecho de ser un instrumento tecnológico, ellas tratan de mejorar la
gestión del Estado, su transformación y el ofrecimiento de servicios oportunos para el
ciudadanos y funcionarios, ellas buscan aumentar la transparencia del Estado, aumentar los
participación en la gestión pública e incentivar la democracia participativa e inclusión social.

44
Portal de gobierno electrónico
Para el Centro Nacional de Tecnología de Información (Venezuela) un portal de gobierno
electrónico es un portal de información pública y servicios que provee una ventana única a
disposición de los ciudadanos en los ámbitos: informativo, comunicacional, transaccional y
estadístico vía Internet. Otra definición de portal de gobierno que se puede citar es la de
Gant y Johnson (2002) quienes lo ven como una puerta de acceso al Estado a través de la
Internet, que provee tanto a entidades externas como a personal de gobierno un punto único
de acceso en línea a recursos e información de estado.
Componentes de un gobierno electrónico
Existe varios investigadores que describen los componentes de un gobierno electrónico a
través de los llamado modelo de madurez, estos componentes varían según el enfoquen de
los autores, pero se asemejan entre ellos. En este apartado tratamos de integrar todos estos
componentes, para hacer un solo modelo de madurez.
El primer modelo de madurez es de Presencia, también llamado catálogo, este componente
focaliza la presencia del gobierno en los portales web, los ciudadanos pueden navegar y
hacer búsquedas de cualquier información contenida en el portal (Layne y Lee; 2001; UN y
ASPA; 2002).
El segundo modelo de madurez es Información, este componente sirve como página inicial,
o puerta de entrada para acceder a otras páginas útiles donde se pueda localizar
información de distintos departamentos, direcciones o dependencias de gobierno. En este
componente, los usuarios pueden encontrar información actualizada y especializada.
Además cuenta con motores de búsqueda internos y/o externos. La esencia de este
componente es la disponibilidad de información (Hiller y Bélanger; 2001; Layne y Lee; 2001;
Moon, 2002; UN y ASPA, 2002; Holden, Norris y Fletcher, 2003).
El tercer modelo de madurez es la Interacción, en este componente se pueden encontrar
algunos sitios que utilizan contraseñas para proteger los datos o la identidad de sus
usuarios, garantizando también información personalizada y la protección de documentos.
Se puede tener acceso a leyes, publicaciones gubernamentales, reportes que se pueden
obtener directamente de los sitios y transmitirse a sus computadoras personales para ser
revisados posteriormente sin necesidad de conexión. Se cuenta con correos electrónicos de
funcionarios y servidores públicos, lo que facilita la interacción entre gobierno y ciudadanos.
Precisamente, la esencia de este componente es la posibilidad de interacción por diversos

45
medios entre el gobierno y los ciudadanos (Hiller y Bélanger, 2001; Moon, 2002; UN y
ASPA, 2002).
El cuarto modelo de madurez llamado Transacción, se encuentran los portales de e-
gobierno que se conectan a los sistemas internos mediante interfaces para permitir
transacciones entre el ciudadano y gobierno, consiste en poner en línea las bases de datos
mediante interfaces para facilitar las transacciones. Este componente utiliza todo el potencial
de Internet para proveer servicios públicos. Los ciudadanos pueden realizar transacciones
seguras, confiables y rápidas usando la red. Por ejemplo, si un ciudadano tiene que renovar
su licencia, puede hacerlo a través de esta vía y realizar el pago en línea. La esencia de
este componente es la posibilidad de realizar transacciones y obtener servicios completos
directamente desde el portal, incluyendo la posibilidad de pagarlos de forma electrónica.
(Hiller y Bélanger, 2001; Layne y Lee, 2001; Moon, 2002; UN y ASPA, 2002; Holden, Norris
y Fletcher, 2003).
El quinto modelo de estado, se puede denominar Integración, en él se observan dos tipos de
integración: vertical y horizontal. Una integración vertical se produce cuando entre las
funciones y servicios que se prestan tanto locales, estatales y federales se conecta a las
diferentes bases de datos. Por ejemplo, el sistema de registro de una licencia de conducir
del estado de DMV podría estar conectado con la base de datos nacional de licencias para
realizar un cruce de chequeo. Una integración horizontal se produce cuando se da el cruce
de diferentes funciones y servicios, también permite la creación de los servicios externos a
partir de la interacción entre distintas entidades de la administración pública. (Hiller y
Bélanger, 2001; Moon, 2002; UN y ASPA, 2002; Layne y Lee, 2001; Holden, Norris y
Fletcher, 2003).
El sexto modelo de madurez es la Participación Política, este componente supone que el
ciudadano no sólo interactúa con el gobierno, sino que el usuario participa activamente en la
toma de decisiones gubernamentales. En esta etapa existe la posibilidad de que los
ciudadanos opinen sobre proyectos de ley, políticas públicas o decisiones gubernamentales;
de igual forma puede existir el voto electrónico sobre asuntos públicos u otras formas de
participar políticamente a través de los sitios gubernamentales. La esencia de este
componente es entonces la posibilidad de participación por parte de los ciudadanos (Hiller y
Bélanger, 2001; Moon, 2002).

46
La Tabla 2 resume los componentes del modelo de estado del gobierno electrónico.
Tabla 2 Componentes del modelo de estado del gobierno electrónico
(Sandoval, Gil; 2005)
Componente del
Gobierno
Electrónico
Características
Presencia
• Información gubernamental limitada.
• Pocas páginas web hechas por agencias aisladas.
• Información estática acerca de la estructura y servicios del
gobierno.
Información
• Número mayor de páginas web.
• Portal que contiene ligas a la mayoría de las dependencias
estatales.
• Información más dinámica (actualizaciones frecuentes).
Interacción
• Los formatos pueden ser descargados.
• Comunicación a través del correo electrónico.
• Uso de máquinas y programas de búsqueda.
• Uso de chats, foros y otras formas interactivas de
comunicación (relacionadas al servicio).
• Posibilidad de configurar (archivo de ciudadanía, uso de
contraseñas).
Transacción
• Servicios en línea (seguros), incluyendo pagos electrónicos
(tarjetas de crédito).
• Mayor oportunidad de personalización (uso de contraseñas,
archivo de ciudadanía, etc.).
• Portal organizado acorde a las necesidades de las personas
en lugar de las estructuras gubernamentales.
Integración
• Portal de servicio con un punto único de salida y pago
(agencias múltiples, misma función, diferentes niveles de
gobierno).
Participación
Política
• Participación de la ciudadanía en decisiones
gubernamentales, voto electrónico, encuestas en línea.
4.2. Patrones de Diseño en el Gobierno Electrónico
Basados en los componentes del modelo de estado del gobierno electrónico (tabla 1), se
procedió a diseñar cada uno de los patrones que componen este dominio específico, para
satisfacer los principales requisitos de usuarios que se reflejan en la mencionan en la
anterior tabla.

47
 Nombre del patrón: Info.
 Tipo: patrón abstracto.
 Propósito: asegura que una clase guarde información estática.
 Motivación: hay veces que se requiere de una clase para el llenado de información
estática pero de diferentes contenido.
 Aplicabilidad: se aplica en los casos que la información no cambia a menudo.
 Estructura: en la Figura 23 se muestra la estructura del patrón.
Figura 23. Estructura del patrón “Info”
 Participantes: sólo la clase Info que define los atributos de contenido, descripción, enlace,
foto, título, video.
 Colaboraciones: no existen colaboraciones.
 Consecuencias: una consecuencia positiva es que ayuda al llenado de la información.
 Implementación: el patrón se puede exportar a otras herramientas de trabajos ya que se
guarda en formato XML.
 Ejemplo de código: el código en el cual se genera el patrón es Java, VB. Net y C#.
Código en Java VB.net
Class Info{
Public void setContenido (String value){
}
Public String getContenido ( ){
}
Public void setDescripcion (String value){
}
Public String getDescripcion ( ){
}
Class Info
Public Property Contenido as String
Get
End Get
Set(byval value as String)
End Set
End Property
Public Property Descripcion as String
Get

48
Public void setEnlace (String value){
}
Public String getEnlace ( ){
}
Public void setFoto (String value){
}
Public String getFoto ( ){
}
Public void settitulo (String value){
}
Public String gettitulo ( ){
}
Public void setVideo (String value){
}
Public String getVideo ( ){
}
}
End Get
End Set
End Property
Public Property Enlace as String
Get
End Get
End Set
End Property
Public Property Foto as String
Get
End Get
End Set
End Property
Public Property titulo as String
Get
End Get
End Set
End Property
Public Property Video as String
Get
End Get
End Set
End Property
 Usos conocidos (patrones ejemplos): la siguiente Tabla 3 muestra la relación que existe
entre los componentes de gobierno electrónico y los patrones ejemplos que se pudieron
generar con la ayuda del GEPADI una vez generado el patrón de diseño “Info” para el
dominio específico, en este caso gobierno electrónico.
Tabla 3 Patrones de Gobierno Electrónico “Info”
Componente del
Gobierno
Electrónico
Patrones de Gobierno Electrónico “Info”
(Patrones Ejemplos)
Presencia
 Funciones
 Localización física
 Misión
 Nombre del portal
 Objetivos
 Organigrama
 Presentación
 Visión
Información
 Ayuda
 Calendario de actividades
 Enlace de interés
 Eventos
 Mapa de sitio
 Noticias
 Otros enlaces
 Política de privacidad y condición

49
Componente del
Gobierno
Electrónico
Patrones de Gobierno Electrónico “Info”
(Patrones Ejemplos)
 Preguntas frecuentes
Interacción
 Leyes
 Procedimientos de los trámites
 Patrones relacionados: Singleton.
 Nombre del patrón: Datos del Personal.
 Propósito: asegura que una clase guarde la información de un personal.
 Motivación: cuando se necesita llenar información del personal de la institución, del portal
o de los ciudadanos.
 Aplicabilidad. se aplica en los casos que se necesite llenar información personal de algún
empleado que labore para la institución o ciudadano que se registre en el portal de
gobierno electrónico.
Figura 24. Estructura del patrón “Datos del Personal”
 Participantes: sólo la clase Datos del Personal que define los atributos cargo, correo,
extensión, nombre, teléfonos.
 Consecuencias: una consecuencia positiva es que ayuda al llenado de la información.

50
Class Datos_del_Personal{
Public void setCargo (String value){
}
Public String getCargo ( ){
}
Public void setCorreo (String value){
}
Public String getCorreo ( ){
}
Public void setExtencion (String value){
}
Public String getExtencion ( ){
}
Public void setnombre (String value){
}
Public String getnombre ( ){
}
Public void setTelefonos (String value){
}
Public String getTelefonos ( ){
}
}
Class Datos_del_Personal
Public Property Cargo as String
Get
End Get
End Set
End Property
Public Property Correo as String
Get
End Get
End Set
End Property
Public Property Extencion as String
Get
End Get
End Set
End Property
Public Property nombre as String
Get
End Get
End Set
End Property
Public Property Telefonos as String
Get
End Get
End Set
End Property
End Class
generar con la ayuda del GEPADI una vez generado el patrón de diseño “Datos del
Personal” para el dominio específico, en este caso gobierno electrónico.
Tabla 4 Patrones de Gobierno Electrónico “Datos del Personal”
Componente del
Gobierno
Electrónico
Patrones de Gobierno Electrónico “Datos del Personal”
(Patrones Ejemplos)
Presencia
 Directorio institucional
 Directorio relacionado con el portal
 Contactenos
 Patrones relacionados: Singleton, Info

51
 Nombre del patrón: Formulario.
 Propósito: asegurar el llenado de los formularios que más se utilizan en la interacción
que se da entre el gobierno y el ciudadano.
 Motivación: cuando se necesita generar formularios automáticamente.
 Aplicabilidad. para la generación de formulación que permite la generación de
interacción entre el gobierno y el ciudadano como el chat, el foro, la encuesta, entre
otros.
Figura 25. Estructura del patrón “Formulario”
 Participantes: sólo la clase Formulario que define los atributos contenido, Correo, emisor,
ID, nombre, sugerencia, título, con el método enviar.
 Consecuencias: una consecuencia positiva es el llenado y la generación del formulario
automáticamente.
Class Formulario{
Private Stringm_nombre
Public void setCONTENIDO (String value){
Class Formulario
Private m_nombre as String
Public Property CONTENIDO as String

52
}
Public String getCONTENIDO ( ){
}
Public void setCORREO (String value){
}
Public String getCORREO ( ){
}
Public void setEMISOR (String value){
}
Public String getEMISOR ( ){
}
Public void setID (String value){
}
Public String getID ( ){
}
Public void setNOMBRE (String value){
}
Public String getNOMBRE ( ){
}
Public void setSUGERENCIA (String
value){
}
Public String getSUGERENCIA ( ){
}
Public void setTITULO (String value){
}
Public String getTITULO ( ){
}
Public Function ENVIAR as Ninguno
End Function
}
}
Get
End Get
End Set
End Property
Public Property CORREO as String
Get
End Get
End Set
End Property
Public Property EMISOR as String
Get
End Get
End Set
End Property
Public Property ID as String
Get
End Get
End Set
End Property
Public Property NOMBRE as String
Get
End Get
End Set
End Property
Public Property SUGERENCIA as String
Get
End Get
End Set
End Property
Public Property TITULO as String
Get
End Get
End Set
End Property
End Function
End Class
generar con la ayuda del GEPADI una vez generado el patrón de diseño “Formulario”
para el dominio específico, en este caso gobierno electrónico.
Tabla 5 Patrones de Gobierno Electrónico “Formulario”
(Yedra, 2012)
Componente del
Gobierno
Electrónico
Patrones de Gobierno Electrónico “Formulario”
(Patrones Ejemplos)
Interacción
 Sugerencias
Participación  Chat

53
Componente del
Gobierno
Electrónico
Patrones de Gobierno Electrónico “Formulario”
(Patrones Ejemplos)
política  Correo
 Encuesta
 Foro
 Voto electrónico
 Patrones relacionados: Singleton, FormularioBD.
 Nombre del patrón: Formulario BD.
 Propósito: crear estructuras de datos relacionadas con base de datos (por ejemplo sus
métodos).
 Motivación:
 Cuando se necesitan hacer conexiones a diferentes bases de datos y también hacer
cruce de diferentes funciones y servicios.
 Permitir la creación de los servicios externos a partir de la interacción entre distintas
entidades de la administración pública.
 Cuando se necesita consultar diferentes bases de datos.
 Aplicabilidad: a todas las entidades de la administración pública que manejen base de
datos.
Figura 26. Estructura del patrón “Formulario BD”

54
 Participantes: sólo la clase Formulario BD que define los atributos contenido, correo,
emisor, ID, nombre, sugerencia, título, con los métodos: conectar, consultar, eliminar
registro, enviar datos, insertar registro, modificar registro.
 Consecuencias: una consecuencia positiva es la comunicación que se da entre las
diferentes bases de datos, bien sea para consultar datos o crear servicios.
Class Formulario_BD{
Private Stringm_nombre
Public void setCONTENIDO (String value){
}
Public String getCONTENIDO ( ){
}
Public void setCORREO (String value){
}
Public String getCORREO ( ){
}
Public void setEMISOR (String value){
}
Public String getEMISOR ( ){
}
Public void setID (String value){
}
Public String getID ( ){
}
Public void setNOMBRE (String value){
}
Public String getNOMBRE ( ){
}
Public void setSUGERENCIA (String value){
}
Public String getSUGERENCIA ( ){
}
Public void setTITULO (String value){
}
Public String getTITULO ( ){
}
End Function
}
}
Class Formulario_BD
Private m_nombre as String
Public Property CONTENIDO as String
Get
End Get
End Set
End Property
Public Property CORREO as String
Get
End Get
End Set
End Property
Public Property EMISOR as String
Get
End Get
End Set
End Property
Public Property ID as String
Get
End Get
End Set
End Property
Public Property NOMBRE as String
Get
End Get
End Set
End Property
Public Property SUGERENCIA as String
Get
End Get
End Set
End Property
Public Property TITULO as String
Get
End Get
End Set
End Property
End Function
End Class

55
generar con la ayuda del GEPADI una vez generado el patrón de diseño “FormularioBD”
para el dominio específico, en este caso gobierno electrónico.
Tabla 6 Patrones de Gobierno Electrónico “FormularioBD”
Componente del
gobierno
electrónico
Patrones de Gobierno Electrónico “FormularioBD”
(Patrones Ejemplos)
Interacción
 Registro de ciudadano
Transacción
 Trámite
Integración
 Horizontal
 Vertical
 Patrones relacionados: Formulario, Singleton

Generador de Patrones de Diseño (GEPADI)

Generador de Patrones de Diseño (GEPADI)

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (18)

Similar a Generador de Patrones de Diseño (GEPADI)

Similar a Generador de Patrones de Diseño (GEPADI) (20)

Más de Yaskelly Yedra

Más de Yaskelly Yedra (12)

Generador de Patrones de Diseño (GEPADI)