Hace tiempo te dejé una presentación powerpoint de introducción a los patrones, tiempo atrás hablamos de dónde viene la palabra patrón aplicada al mundo del software. Después de más de 20 años de patrones (cómo te comentaba también), el tema he evolucionado mucho y hay mucho qué contar, en esta ocasión quiero tocar el tema de nuevo y aclarar algo que genera confusión: los tipos de patrones que hay.
Si bien los patrones nacieron principalmente en niveles de abstracción bajos (implementación y diseño), con el tiempo su evolución extendió a casi todas las áreas relacionadas con la creación de software.
Entrando en el tema, los patrones se clasifican generalmente en función de su nivel de abstracción. Y la clasificación más popular es la de Buschmann (1996), que define tres niveles de abstracción:
- Patrones Arquitectónicos: Se centran en la estructura del sistema, en la definición de subsistemas, sus responsabilidades y reglas sobre las relaciones entre ellos. Proporcionan un conjunto predefinido de subsistemas, sus responsabilidades y las líneas guía para organizar sus relaciones. Existen trabajos muy conocidos y prestigiosos, como los de Buschmann (1996) o Shaw y Garlan (1996).
- Patrones de Diseño: Esquemas para refinar los subsistemas o componentes de sistema software o sus relaciones. Describen una estructura recurrente y común que resuelve un problema de diseño dentro de un contexto, como los descritos por Gamma (1995). También los patrones GRASP estarían en esta categoría.
- Patrones de Codificación o Idiomas (Idioms): Patrones que ayudan a implementar aspectos particulares del diseño en un lenguaje de programación específico, como los descritos por Coplien (1991).
Si bien la anterior clasificación es la más conocida sería recomenable añadir a la anterior los…
- Patrones Conceptuales o de Análisis, como los Analysis Patterns: Reusable Object Models (OBT) de Fowler (1996).
No obstante, aparte de la clasificación por niveles de abstracción, no podemos olvidar otras categorías, como, por ejemplo:
- Anti-patrones (Antipatterns), si un patrón es “una buena práctica” un antipatrón es una “lección aprendida”. Fueron inicialmente propuestos por Koenig (1995) en la mítica revista JOOP. Por lo general, existen dos variedades: los que describen una mala solución a un problema y los que describen cómo salir de una mala situación y cómo llegar a una buena.
- Patrones para dominios y tecnologías específicas, aplicables sólo en dominios concretos, centrados en entornos web, tiempo real y sistemas embebidos, requisitos, gestión de configuración (el libro de Berczuk y Appleton, 2002, que en ocasiones hemos aquí comentado), relacionados con la tecnología Java (por ejemplo, los de Marinescu, 2002; los de Grand, etc.), gestión del conocimiento, computación ubicua (los de Landay y Borriello, 2003), etc.
- Patrones organizacionales, metodologías y de procesos, para la planificación de proyectos a gran escala, gestión, etc. Ejemplo de esta categoría son los patrones Scrum.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Echo en falta los Patrones de Integración (EIP) de los que el estándar oficioso se ciñe básicamente al libro de estos señores:
http://www.eaipatterns.com/index.html
Donde quedan los patrones de requisitos de software en tu clasificación? Os dejo la URL de PABRE nuestro framework sobre patrones de requisitos. http://www.upc.edu/gessi/PABRE/.
Otra importante referència a este tipo de patrones es el libro de Withall: http://www.withallyourequire.com.
Saludos,
Carme