Tipos de patrones de diseño

Patrones de diseño de bases de datos GRASP.

Patrones de diseño de bases de datos.“Un patrón de diseño es una descripción de clases y objetos comunicándose entre sí adaptada para resolver un problema general de diseño en un contexto particular.”

Con el uso de patrones de diseño se evita la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente. Permite formalizar un vocabulario común entre diseñadores y estandarizar el modo en que se realiza el diseño.

Patrones GRASP

Los patrones GRASP (Patrones de Software para la asignación General de Responsabilidad) constituyen un apoyo para la enseñanza, pues ayudan a entender el diseño de objetos. De los diferentes patrones que ofrece GRASP se ha tenido en cuenta para la modelación del plugin los siguientes:

Tipos de patrones GRASP

Patrón Creador

Patrón Creador:
El patrón Creador guía la asignación de responsabilidades y ayuda a identificar quién debe ser el responsable de la creación de objetos. Se asigna la tarea a una clase de crear cuando, contiene, agrega, compone, almacena o usa otra clase. El propósito fundamental de este patrón es encontrar un creador que se deba conectar con el objeto producido en cualquier evento. El uso de este patrón se evidencia en las clases, editor SQL la cual crea objetos de las clases mensaje y resultado, para realizar sus responsabilidades.

Patrón Experto

Patrón Experto
El patrón experto se usa al asignar responsabilidades. Ofrece como solución asignar las responsabilidades a las clases que tienen la información necesaria para cumplir con estas, para las cuales son creadas sin depender de ninguna otra. Es un principio básico que suele utilizarse en el diseño orientado a objetos. El uso de este patrón se evidencia en la clase principal-Interface la cual asigna responsabilidades a las clases editor-grafico y editorSQL.

Patrón Controlador

Patrón Controlador
El patrón controlador asigna la responsabilidad del manejo de los eventos del sistema a una clase. Este patrón se evidencia en la clase graficalView, la cual es la encargada de controlar y manejar todas las tareas de las clases Field Item y TableItem.

Patrón Alta Cohesión

Alta Cohesión
El patrón alta cohesión es la meta principal que ha de buscarse en todo momento, se debe tener presente en todas las decisiones de diseño. El alto nivel de cohesión es presentado por las clases que tienen responsabilidades moderadas en un área funcional y colaboran con otras para llevar a cabo las tareas, no donde dichas clases abarcan el volumen de las responsabilidades a realizar sin importar su complejidad. Este patrón se evidencia en las clases principal-Interface y consulta donde las mismas colaboran entre sí para lograr ejecutar la función importar consulta.

Patrón Bajo Acoplamiento

Bajo Acoplamiento
El bajo acoplamiento estimula la asignación de responsabilidades de forma tal que la inclusión de éstas no incremente el acoplamiento, es decir, significa asignar una responsabilidad para mantener pocas dependencias entre las clases. Se puede evidenciar el uso de este patrón en la clase Highlighter y principal-interface puesto que Highlighter tiene el número mínimo de dependencias con otras clases.

Patrones GOF

Los patrones GOF (Gang of Four, "Pandilla de los Cuatro") recopilan una serie de patrones de diseños, agrupados en tres categorías: de creación, de estructura y de comportamiento.

Estructurales: Describen las clases y objetos que pueden ser combinados para establecer grandes estructuras y proporcionar nuevas funcionalidades. Estos objetos adicionados pueden ser incluso objetos simples u objetos compuestos.
Comportamiento: Contribuyen a definir la comunicación e iteración entre los objetos de un sistema. Observer (Observador): Define una dependencia de uno a muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos.

Fuente

• Prieto, Félix. Programación III. Sistemas tema 7. Patrones de Diseño. Universidad de Valladolid. 2005.

*Jacobson, Ivar, Booch, Grady y Rumbaugh, James. El proceso unificado de software. Apéndice A1. 2000.

Kaisler, Stephen H. software paradigms. George Washington University. United States of America : s.n., 2005. 0-471-48347-8.

• Küng, Stefan, Onken, Lübbe y Large, Simon. TortoiseSVN. Un cliente de Subversion para Windows. Versión 1.4.1. 2006.
• Letelier, Patricio. Metodologías Ágiles y XP. Departamento de Sistemas informáticos y Computación, Universidad Politécnica de Valencia. Valencia : s.n.
• Los casos de pruebas en la prueba del software.Revista digital LAMPSAKOS. Cristegui, Jose Luis. 3, 2010.
• Mestras, Juan Pavón. Estructura de las Aplicaciones Orientadas a Objetos. El patrón Modelo-Vista-Controlador (MVC). Dep. Ingeniería del Software e Inteligencia Artificial, Universidad Complutense Madrid, Facultad de Informática. Madrid, España : s.n., 2008-2009.
• Ortíz, Yudisney Vázquez y Reyes, Yunior Mesa. Sistemas de Bases de Datos. Espacio de comunicación e intercambio para la comunidad técnica cubana de PostgreSQL. PostgreSQL, Universidad de las Ciencias Informáticas (UCI). Ciudad de la Habana, Cuba : s.n., 2011. pág. 4. 1994-1536.
• Pampillo, Yulenia Manso y Cuadra, Yuleidis Rodríguez. Propuesta de modelo para probar la confiabilidad de los productos desarrollados con PostgreSQL en el Centro de Tecnología y Gestión de Datos (DATEC). Universidad de las Ciencias Informáticas. Cuidad de la Habana, Cuba : s.n., 2010.
• Peñalver, G., Meneses, A. y García, S. sxp, metodología ágil para el desarrollo de software. Universidad de las Ciencias Informáticas. Ciudad de La Habana, Cuba : s.n., 2010. 1er Congreso Iberoaméricano de ingeniería de Proyectos Antofagasta -Chile.
• Pressman, Roger S. Ingeniería de Software. Un enfoque práctico. 6ta edición, Capítulo 14. pág. 19.