Patrones Creacionales: Singleton, Factory Method y Abstract Factory

📌 En síntesis: Patrones para el desacoplamiento de instanciación: control de instancia única con Singleton y familias de objetos con Factory Method y Abstract Factory.

Guía técnica desarrollada por el equipo de Proyecto Luna para formación profesional y consulta técnica abierta.

---

Introducción A lo largo del diseño de software, uno de los principales desafíos de la disciplina en informática consiste en tomar decisiones estructurales que no sólo resuelvan un problema inmediato, sino que también permitan que el sistema evolucione de manera ordenada y sostenible en el tiempo. En este contexto, los patrones de diseño surgen como respuestas consolidadas a problemas recurrentes, pero su verdadero valor no reside en su aplicación mecánica, sino en la comprensión profunda del porqué y el cuándo de su uso. Antes de analizar patrones específicos, resulta imprescindible establecer un marco conceptual que permita ordenar estas soluciones, relacionarlas con los objetivos del sistema y vincularlas con los atributos de calidad esperados. La clasificación de los en categorías constituye ese primer marco de comprensión. Distinguir entre patrones orientados a la estructura estática del sistema, patrones centrados en la colaboración dinámica de objetos y patrones vinculados directamente a atributos de calidad permite anticipar el impacto real de una decisión de diseño. Según Debrauwer (2023), esta clasificación ayuda a evitar soluciones rígidas o sobredimensionadas, ya que obliga a reflexionar sobre la naturaleza del problema antes de seleccionar una estrategia de implementación. Desde esta perspectiva, los patrones dejan de ser recetas universales y se transforman en herramientas de razonamiento de diseño. Asimismo, el análisis de atributos de calidad como mantenibilidad, escalabilidad o fiabilidad introduce un criterio esencial para evaluar la pertinencia de cada patrón. Tal como plantean Van der Heyde y Debrauwer (2020), comprender cómo un patrón influye en la arquitectura y en el comportamiento del sistema permite al diseñador anticipar consecuencias, modelarlas en UML y justificar sus decisiones con mayor claridad.

En conjunto, categorías, atributos de calidad y técnicas como el QAW conforman un enfoque integrado que sitúa a los patrones de diseño como decisiones conscientes, alineadas con los requisitos y con la evolución esperada del software.

1. Categorías de patrones Las categorías de constituyen una primera aproximación conceptual para comprender cómo se organizan y aplican las soluciones recurrentes en la disciplina informática. Antes de analizar patrones específicos o estudiar ejemplos concretos de implementación, resulta fundamental reconocer que no todos los patrones actúan en el mismo nivel del sistema ni resuelven los problemas desde la misma perspectiva. Esta clasificación inicial permite ordenar el pensamiento de diseño y anticipar el tipo de impacto que una decisión tendrá sobre la estructura del software y su evolución. En términos generales, las categorías de patrones permiten responder a una pregunta clave del diseño orientado a objetos: ¿el problema se resuelve principalmente mediante la estructura estática del sistema o mediante la colaboración dinámica entre sus componentes? Esta distinción es relevante porque condiciona las herramientas conceptuales que se utilizan, el tipo de relaciones que se modelan y la forma en que el sistema puede adaptarse a futuros cambios. Según Debrauwer (2023), comprender esta separación ayuda a evitar decisiones de diseño rígidas o soluciones sobredimensionadas frente a problemas relativamente simples. Desde la ingeniería de software, clasificar los patrones no implica encasillarlos, sino ofrecer un marco de referencia que facilite su análisis. Las categorías funcionan como un mapa conceptual que orienta al diseñador al momento de evaluar alternativas. En lugar de elegir un patrón por reconocimiento superficial o por costumbre, esta clasificación invita a reflexionar sobre la naturaleza del problema, el tipo de variabilidad presente y el nivel en el que conviene introducir la solución.

Al introducir las categorías de patrones, también se establece un vínculo directo con la programación orientada a objetos. Las decisiones de diseño no se toman únicamente pensando en el código inmediato, sino en cómo ese código se mantendrá, extenderá y comprenderá a lo largo del tiempo. En este sentido, las categorías de patrones permiten anticipar efectos como el grado de acoplamiento, la claridad de las responsabilidades y la facilidad para incorporar nuevos comportamientos sin alterar lo existente. Otro aspecto relevante de esta clasificación es su relación con el modelado UML. Dependiendo de la categoría, los diagramas enfatizarán distintos elementos: jerarquías, asociaciones, dependencias o colaboraciones. Esta diferencia no es meramente gráfica, sino conceptual, ya que refleja cómo se distribuyen las responsabilidades dentro del sistema. Tal como mencionan Van Der Heyde y Debrauwer (2020), un modelado claro ayuda a visualizar tempranamente las consecuencias del diseño elegido. En la práctica de la disciplina informática, las categorías de patrones permiten abordar problemas recurrentes de forma más sistemática. Por ejemplo, en sistemas que crecen de manera progresiva, distinguir correctamente el tipo de patrón a utilizar puede marcar la diferencia entre un diseño flexible y uno difícil de modificar. Asimismo, esta clasificación favorece la comunicación dentro de los equipos de desarrollo, ya que proporciona un lenguaje común para discutir alternativas de solución sin descender de inmediato al detalle del código. 1.1. Patrones GoF Los patrones GoF (Gang of Four) son un conjunto de 23 patrones de diseño que fueron presentados por primera vez en el libro Design Patterns: Elements of Reusable Object-Oriented Software escrito por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides.

Estos patrones ofrecen soluciones probadas para problemas comunes en el diseño de software orientado a objetos. 1.2. Para clases Los para clases se caracterizan por resolver problemas de diseño a partir de la estructura estática del sistema, utilizando principalmente herencia, generalización y clases abstractas. Este tipo de patrones define el comportamiento del software en etapas tempranas del diseño y fija gran parte de sus decisiones en tiempo de compilación. En ingeniería en informática, su estudio resulta clave para comprender cómo se construyen arquitecturas estables y reutilizables desde la base del sistema. Desde un punto de vista conceptual, los patrones para clases permiten organizar el software en jerarquías claras, en las cuales una superclase concentra el comportamiento común y las subclases introducen variaciones controladas. Según Debrauwer (2023), este enfoque es especialmente adecuado cuando el dominio del problema está bien definido y las diferencias entre comportamientos son previsibles, ya que la herencia ofrece un mecanismo directo para extender funcionalidades sin duplicar código. Entre las características principales de los patrones para clases se pueden destacar las siguientes:

• Se apoyan en herencia y métodos abstractos.
• Definen puntos de extensión claros mediante subclases.
• Favorecen la reutilización de código común.
• Presentan una estructura estable, poco cambiante en ejecución. Este tipo de patrones es frecuente en sistemas que requieren consistencia en los procesos. Por ejemplo, cuando varias operaciones siguen un mismo flujo general, pero difieren en un paso

específico. En estos casos, encapsular el algoritmo general en una superclase y delegar los detalles a subclases mejora la claridad y la mantenibilidad del diseño. Ejemplo aplicado Supóngase un sistema de reservas que siempre debe seguir el mismo proceso general, pero que guarda la información en distintos medios. El flujo es fijo, mientras que el método de almacenamiento varía.

Figura 1: Ejemplo en Java del patrón Template Method, donde una clase abstracta define el flujo del proceso d

define el flujo del proceso de reserva y las subclases implementan el paso específico de guardado // Ejemplo de patrón para clases: Template Method abstract class ProcesoReserva { // método plantilla public final void procesar() { validar(); guardar(); registrarAuditoria(); } protected void validar() { System.out.println(“Validación estándar de la reserva”); } protected abstract void guardar(); protected void registrarAuditoria() { System.out.println(“Registro de auditoría”); } } class ReservaBaseDatos extends ProcesoReserva { @Override protected void guardar() { System.out.println(“Guardando reserva en base de datos”); } } class ReservaArchivo extends ProcesoReserva { @Override protected void guardar() { System.out.println(“Guardando reserva en archivo”); } }

En este ejemplo, el algoritmo general queda definido en la clase abstracta, mientras que las subclases concretan el paso variable. Este tipo de solución ilustra claramente cómo los patrones para clases controlan la variación mediante herencia, ya que las clases ReservaBaseDatos y ReservaArchivo heredan de ProcesoReserva, y deben implementar el método abstracto void guardar(). Desde el modelado UML, los patrones para clases se representan principalmente a través de diagramas de clases, donde se destacan las relaciones de generalización y los métodos abstractos. Según Van Der Heyde y Debrauwer (2020), este tipo de diagramas permite identificar rápidamente qué partes del sistema son estables y cuáles están diseñadas para variar, lo que facilita la evaluación temprana del diseño. Ventajas principales

• Claridad estructural del sistema.

• Reutilización de comportamiento común.

• Facilidad para documentar y comprender el diseño.

• Buen soporte para procesos estandarizados. Limitaciones a considerar

• Mayor rigidez frente a cambios no previstos.

• Riesgo de jerarquías profundas o mal diseñadas.

• Dependencia fuerte entre superclases y subclases. Estas limitaciones explican por qué, en ingeniería de software, se recomienda aplicar patrones para clases cuando el dominio es estable y las variaciones son acotadas. Debrauwer (2023) señala que una herencia bien diseñada aporta orden y consistencia, pero un uso excesivo o poco reflexivo puede dificultar la evolución del sistema.

La siguiente tabla resume el enfoque de los patrones para clases dentro del diseño orientado a objetos: Aspecto Patrones para clases Mecanismo principal Herencia Momento de variación Diseño y compilación Tipo de estructura Jerárquica Flexibilidad Moderada Riesgo principal Rigidez estructural Tabla 1. Principales enfoques de los patrones para clases dentro del diseño En síntesis, los para clases constituyen una herramienta fundamental para construir arquitecturas claras y coherentes en programación orientada a objetos. Su uso adecuado permite resolver problemas recurrentes mediante estructuras bien definidas, preparando el terreno para comprender, en contraste, los patrones que privilegian la colaboración dinámica entre objetos. 1.3. Para objetos Los para objetos se caracterizan por centrar su solución en la colaboración dinámica entre instancias durante la ejecución del sistema. A diferencia de los patrones para clases, que fijan su estructura principalmente mediante herencia, los patrones para objetos privilegian la composición, la delegación de responsabilidades y el uso de interfaces, permitiendo que el comportamiento del software pueda variar sin modificar la estructura básica de clases. En ingeniería de software, este enfoque resulta especialmente valioso en sistemas que deben adaptarse a cambios frecuentes o incorporar nuevas funcionalidades de forma incremental.

Desde el punto de vista conceptual, los patrones para objetos operan principalmente en tiempo de ejecución. Esto significa que el comportamiento del sistema puede modificarse mediante la sustitución o combinación de objetos, sin necesidad de redefinir jerarquías. Según Debrauwer (2023) señala que este tipo de patrones ofrece una mayor flexibilidad frente a requisitos cambiantes, ya que reduce el acoplamiento entre los componentes del sistema y favorece diseños más evolutivos. Entre las características esenciales de los patrones para objetos se pueden identificar las siguientes: 1. Se basan en composición antes que herencia. 2. Utilizan interfaces para definir contratos de comportamiento. 3. Favorecen el bajo acoplamiento entre componentes. 4. Permiten extender el sistema agregando nuevos objetos, no modificando los existentes. Este enfoque es habitual en sistemas interactivos, aplicaciones distribuidas y arquitecturas orientadas a eventos, donde múltiples componentes deben reaccionar ante cambios sin depender directamente unos de otros. En estos contextos, los patrones para objetos permiten construir soluciones más robustas frente a la evolución del sistema. Ejemplo aplicado Considérese un sistema de reservas de laboratorio que debe notificar a distintos actores cada vez que una reserva se crea, modifica o elimina. Una implementación directa suele derivar en código duplicado y alto acoplamiento. Un patrón para objetos permite resolver este problema separando la lógica de reservas de la lógica de notificación.

Figura 2: Patrón Observer, donde un gestor de reservas notifica eventos a distintos

observadores como alumno, encargado y sistema académico import java.util.ArrayList; import java.util.List; // Interfaz común interface ObservadorReserva { void notificar(String evento, String idReserva); } // Implementaciones concretas class NotificacionAlumno implements ObservadorReserva { public void notificar(String evento, String idReserva) { System.out.println(“Alumno recibe notificación: “ + evento); } } class NotificacionEncargado implements ObservadorReserva { public void notificar(String evento, String idReserva) { System.out.println(“Encargado recibe notificación: “ + evento); } } class NotificacionSistemaAcademico implements ObservadorReserva { public void notificar(String evento, String idReserva) { System.out.println(“Sistema académico registra: “ + evento); } } // Objeto sujeto class GestorReservas { private List observadores = new ArrayList<>(); public void agregarObservador(ObservadorReserva o) { observadores.add(o); } private void notificarTodos(String evento, String idReserva) { for (ObservadorReserva o : observadores) { o.notificar(evento, idReserva); } } public void crearReserva(String idReserva) { notificarTodos(“CREADA”, idReserva); } public void eliminarReserva(String idReserva) { notificarTodos(“ELIMINADA”, idReserva); } }

En este caso, el gestor de reservas no conoce los detalles de cada notificación, solo interactúa con una interfaz común. Este diseño refleja claramente la filosofía de los patrones para objetos: colaboración flexible y desacoplada. Desde el modelado UML, los patrones para objetos se representan enfatizando asociaciones y dependencias más que jerarquías rígidas. Van der Heyde y Debrauwer (2020) señalan que este tipo de diagramas permite visualizar cómo los objetos se comunican y cooperan, mostrando la dinámica del sistema más que su estructura estática. Ventajas principales

• Alta flexibilidad frente a cambios.

• Reducción del acoplamiento entre componentes.

• Facilidad para agregar nuevas funcionalidades.

• Mejor alineación con requisitos cambiantes. Limitaciones a considerar

• Mayor número de objetos e interacciones.

• Complejidad en el seguimiento del flujo de ejecución.

• Necesidad de una buena documentación del diseño. Estas limitaciones no invalidan el uso de los patrones para objetos, pero exigen un diseño cuidadoso. Debrauwer (2023) indica que la flexibilidad debe equilibrarse con claridad estructural, evitando soluciones excesivamente fragmentadas que dificulten la comprensión del sistema. La siguiente tabla resume el enfoque de los patrones para objetos:

Aspecto Patrones para objetos Mecanismo principal Composición y delegación Momento de variación Tiempo de ejecución Tipo de estructura Colaborativa Flexibilidad Alta Riesgo principal Complejidad dinámica Tabla 2. Síntesis del enfoque de los patrones para objetos En síntesis, los para objetos constituyen una respuesta eficaz a problemas que requieren adaptabilidad y extensibilidad. Al privilegiar la colaboración entre instancias y el desacoplamiento, estos patrones permiten construir sistemas capaces de evolucionar sin reescribir su estructura central, complementando de forma natural el enfoque más estático de los patrones para clases. 2. Atributos de calidad Los atributos de calidad representan propiedades no funcionales que describen cómo un sistema cumple sus funciones y bajo qué condiciones lo hace. En ingeniería de Software, estos atributos son tan relevantes como los requisitos funcionales, ya que influyen directamente en la mantenibilidad, escalabilidad, rendimiento, fiabilidad y usabilidad del software. Los patrones de diseño adquieren sentido cuando se analizan como mecanismos estructurales y comportamentales que permiten alcanzar estos atributos de manera sistemática. Desde la programación orientada a objetos, los atributos de calidad no suelen resolverse con instrucciones aisladas de código, sino con decisiones de diseño que afectan la organización del sistema.

Según Debrauwer (2023) señala que los encapsulan experiencias previas que permiten responder a problemas recurrentes asociados a la calidad del software, reduciendo la improvisación y favoreciendo soluciones coherentes a largo plazo. Principales atributos de calidad abordados por patrones A continuación, se enumeran los atributos más relevantes y su relación con los : 1. Mantenibilidad

• Capacidad del sistema para ser modificado, corregido o extendido.

• Los patrones reducen la duplicación y clarifican responsabilidades.

• Favorecen cambios localizados en lugar de modificaciones globales. 2. Escalabilidad

• Capacidad de crecer en usuarios, datos o funcionalidades.

• Los patrones ayudan a distribuir responsabilidades y controlar la creación de objetos.

• Permiten preparar el sistema para un crecimiento futuro.

3. Rendimiento

• Relación entre tiempo de respuesta y uso de recursos.
• Algunos patrones optimizan el uso de memoria o evitan operaciones costosas repetidas.

4. Fiabilidad

• Capacidad del sistema para operar de forma consistente ante errores.

• Los patrones pueden aislar fallos y evitar efectos en cascada.

5. Usabilidad

• Facilidad de interacción y comprensión del sistema.

• Determinados patrones favorecen la separación entre lógica y presentación. Ejemplo conceptual de vínculo patrón–atributo Un mismo patrón puede impactar más de un atributo, pero suele existir uno predominante:

• Observer → mantenibilidad y extensibilidad.

• Factory Method → escalabilidad y flexibilidad.

• Singleton → control de recursos y rendimiento.

• Strategy → flexibilidad y usabilidad. Este enfoque evita seleccionar patrones por reconocimiento superficial y obliga a justificar su uso desde la calidad esperada del sistema. Ejemplo aplicado con código Caso: necesidad de cambiar algoritmos de cálculo sin modificar el código cliente, priorizando la mantenibilidad.

Figura 3: Ejemplo en Java del patrón Strategy, en que distintas estrategias de cálculo se

intercambian dinámicamente para procesar un pago sin modificar la clase principal En este ejemplo, el atributo de calidad dominante es la mantenibilidad, ya que nuevos cálculos se agregan sin modificar la clase principal. Debrauwer (2023) indica que este tipo de solución reduce el impacto de los cambios y mejora la comprensión del diseño. Tabla de relación atributos–decisiones de diseño Atributo de calidad Riesgo común Aporte del patrón mantenibilidad código duplicado separación de responsabilidades escalabilidad crecimiento rígido control de creación y delegación // Atributo principal: mantenibilidad interface EstrategiaCalculo { double calcular(double valor); } class CalculoNormal implements EstrategiaCalculo { public double calcular(double valor) { return valor * 1.19; } } class CalculoPreferente implements EstrategiaCalculo { public double calcular(double valor) { return valor * 1.10; } } class ProcesadorPago { private EstrategiaCalculo estrategia; public void setEstrategia(EstrategiaCalculo estrategia) { this.estrategia = estrategia; } public double procesar(double monto) { return estrategia.calcular(monto); } } Continúa en la siguiente página

Atributo de calidad Riesgo común Aporte del patrón rendimiento operaciones repetidas reutilización y control de recursos fiabilidad fallos encadenados aislamiento de componentes usabilidad lógica mezclada con interfaz separación de capas Tabla 3. Atributos y decisiones de diseño Consideraciones de diseño Al trabajar con atributos de calidad, es importante tener en cuenta que:

• No todos los atributos pueden optimizarse simultáneamente.
• Mejorar un atributo puede afectar negativamente a otro.
• Los patrones no garantizan calidad si se aplican sin análisis previo. Según Debrauwer (2023) señala que el valor real de los patrones aparece cuando se utilizan como respuesta consciente a un atributo de calidad priorizado, y no como soluciones universales aplicables a cualquier problema. En síntesis, los atributos de calidad constituyen el criterio central para evaluar la pertinencia de un patrón de diseño. Comprender su relación permite tomar decisiones de diseño más informadas, alineadas con los objetivos del sistema y coherentes con los principios de la ingeniería de software.

---

📌 QAW (Quality Attribute Workshop)

El QAW es una técnica estructurada que permite identificar, priorizar y analizar atributos de calidad desde etapas tempranas del diseño de un sistema. En el contexto de la ingeniería en informática,

cumple un rol clave al conectar las necesidades del sistema con decisiones de diseño concretas, entre ellas la selección y aplicación de . Su valor principal radica en que desplaza el foco desde soluciones técnicas aisladas hacia una comprensión integral de la calidad esperada del software. Desde la perspectiva del diseño orientado a objetos, el QAW se utiliza como una instancia previa a la definición de la arquitectura. Según Debrauwer (2023) señala que los resultan más efectivos cuando responden a atributos de calidad explícitamente definidos, ya que esto evita aplicar soluciones genéricas a problemas mal formulados. En este sentido, el QAW actúa como un filtro que orienta qué patrones son pertinentes y cuáles no aportan valor real al sistema. El proceso del QAW se basa en la construcción de escenarios de calidad, los cuales describen situaciones concretas que el sistema debe enfrentar. Estos escenarios permiten traducir conceptos abstractos como mantenibilidad o escalabilidad en condiciones observables y evaluables. Etapas esenciales del QAW De forma resumida, el QAW contempla las siguientes etapas: 1. Identificación de actores relevantes

• Usuarios finales.
• Sistemas externos.
• Componentes técnicos críticos.

2. Definición de objetivos del sistema

• Propósito general del software.
• Restricciones técnicas y organizacionales.

3. Identificación de atributos de calidad prioritarios

• Mantenibilidad.
• Escalabilidad.
• Rendimiento.
• Fiabilidad.

4. Construcción de escenarios de calidad

• Qué ocurre.
• Bajo qué condiciones.
• Qué respuesta se espera del sistema.

5. Análisis de implicancias de diseño

• Riesgos asociados.

• Tácticas arquitectónicas posibles.

• compatibles. Ejemplo de escenarios QAW Sistema: gestión de reservas de laboratorio.

• Escenario de mantenibilidad: “Ante la incorporación de un nuevo tipo de notificación, el sistema debe permitir su integración sin modificar las clases existentes de gestión de reservas”.

• Escenario de fiabilidad: “Si un canal de notificación falla, la creación de la reserva no debe verse afectada”.

• Escenario de rendimiento: “El sistema debe notificar a todos los actores asociados a una reserva en menos de 100 milisegundos”.

Estos escenarios orientan directamente las decisiones de diseño. Por ejemplo, frente al primer escenario, resulta coherente optar por patrones que reduzcan el acoplamiento y faciliten extensiones. Debrauwer (2023) indica que este tipo de análisis permite justificar el uso de patrones orientados a la colaboración dinámica de objetos. Relación QAW y El QAW no prescribe patrones específicos, pero sí delimita el espacio de soluciones viables. La relación puede sintetizarse de la siguiente manera:

• El atributo define la prioridad.
• El escenario concreta la necesidad.
• El patrón aporta la estructura de solución. Tabla de ejemplo: Atributo priorizado Escenario Decisión de diseño Mantenibilidad Agregar funcionalidad sin modificar código existente Desacoplamiento mediante interfaces Fiabilidad Fallos parciales sin caída del sistema Aislamiento de responsabilidades Rendimiento Respuesta rápida ante múltiples eventos Control del flujo de ejecución Tabla 4. Relación QAW y Desde el modelado UML, el QAW facilita la identificación de los puntos del sistema en que deben existir extensiones, dependencias o colaboraciones. Van der Heyde y Debrauwer (2020) señalan que cuando los escenarios de calidad están bien definidos, los diagramas reflejan con mayor claridad las decisiones arquitectónicas y reducen ambigüedades en la implementación.

Consideraciones finales El QAW no es una actividad meramente documental, sino una herramienta de razonamiento de diseño. Su correcta aplicación permite:

• Evitar la selección arbitraria de patrones.

• Priorizar atributos de calidad según el contexto real del sistema.

• Reducir retrabajo en etapas posteriores del desarrollo. Debrauwer (2023) señala que integrar el QAW al proceso de diseño fortalece la coherencia entre requisitos, arquitectura y código, lo que convierte a los en respuestas justificadas y no en soluciones genéricas. En síntesis, el Quality Attribute Workshop constituye un puente metodológico entre los atributos de calidad y las decisiones de diseño. Su uso sistemático permite que los se apliquen con criterio, alineados con los objetivos del sistema y con las exigencias reales de calidad en la ingeniería de software. 3. Modelado de requisitos de un patrón El modelado de requisitos de un patrón de diseño constituye una etapa clave para garantizar que la solución adoptada responda efectivamente al problema que se desea resolver. En ingeniería en informática, los patrones no deben aplicarse como estructuras prefabricadas independientes del contexto, sino como respuestas razonadas a necesidades funcionales y atributos de calidad previamente identificados. Modelar los requisitos antes de seleccionar un patrón permite alinear el diseño con los objetivos reales del sistema y evitar decisiones arbitrarias.

Desde la programación orientada a objetos, modelar requisitos implica analizar qué debe hacer el sistema, bajo qué condiciones y con qué restricciones. Según Debrauwer (2023) señala que los patrones adquieren sentido cuando se vinculan explícitamente con los requisitos del dominio, ya que esto permite comprender su rol dentro de la arquitectura y anticipar sus efectos sobre la mantenibilidad y la extensibilidad del software. En este sentido, el modelado de requisitos actúa como un puente entre el análisis del problema y el diseño de la solución. El modelado de requisitos de un patrón se apoya en la identificación de dos grandes tipos de requerimientos: 1. Requisitos funcionales

• Acciones que el sistema debe realizar.
• Interacciones entre usuarios y componentes.
• Flujos principales y alternativos.

2. Requisitos no funcionales

• Atributos de calidad priorizados.
• Restricciones técnicas o de rendimiento.
• Condiciones de operación esperadas. Este análisis permite detectar puntos de variabilidad, es decir, aquellas partes del sistema que probablemente cambiarán con el tiempo. Debrauwer (2023) indica que los suelen ser especialmente útiles cuando existe variabilidad recurrente, ya que proporcionan una estructura estable que encapsula el cambio. Identificación del problema recurrente Un aspecto central del modelado es reconocer si el problema que enfrenta el sistema es recurrente. En ingeniería de software, muchos

problemas aparecen de forma reiterada en distintos proyectos, aunque con contextos específicos. Algunos ejemplos comunes son:

• Necesidad de notificar a múltiples componentes ante un evento.

• Requerimiento de variar algoritmos sin modificar el código cliente.

• Creación controlada de objetos complejos. Cuando estos problemas se identifican correctamente a nivel de requisitos, el uso de un patrón deja de ser una decisión técnica aislada y se transforma en una consecuencia lógica del análisis. Ejemplo de modelado a partir de requisitos Sistema: gestión de reservas de laboratorio. Requisitos identificados:

• El sistema debe permitir crear, modificar y eliminar reservas.

• Cada cambio debe ser comunicado a distintos actores.

• Debe ser posible agregar nuevos tipos de notificación sin modificar la lógica principal. A partir de este modelado, se puede observar:

• Requisito funcional: notificar eventos de reserva.

• Requisito no funcional: mantenibilidad y extensibilidad.

• Variabilidad: tipos de notificación. Este análisis orienta hacia un patrón que desacople la gestión de reservas de la notificación, lo que demuestra cómo el modelado de requisitos precede y justifica la elección del patrón.

Relación con el modelado UML El modelado de requisitos también se refleja en las representaciones UML. Según Van der Heyde y Debrauwer (2020), cuando los requisitos están bien definidos, los diagramas muestran con mayor claridad:

• Responsabilidades de cada clase.

• Dependencias necesarias y evitadas.

• Puntos de extensión previstos en el diseño. Esto permite evaluar tempranamente si el diseño propuesto responde a los requisitos o si introduce complejidad innecesaria. Beneficios del modelado de requisitos para patrones Entre los principales beneficios de este enfoque se encuentran:

• Selección fundamentada de .

• Reducción de retrabajo en etapas posteriores.

• Mayor coherencia entre análisis, diseño y código.

• Mejora en la comunicación del diseño dentro del equipo. Debrauwer (2023) señala que uno de los errores más frecuentes en el uso de patrones es aplicarlos sin un modelado previo de requisitos, lo que conduce a soluciones sobredimensionadas o poco alineadas con el problema real. En síntesis, el modelado de requisitos de un patrón de diseño es una actividad esencial en la ingeniería de software. Permite comprender el problema en profundidad, identificar la variabilidad relevante y seleccionar estructuras de diseño coherentes con los objetivos del sistema. De esta forma, los patrones dejan de ser recetas genéricas y se convierten en herramientas estratégicas al servicio de un diseño de software claro, mantenible y alineado con las necesidades reales del sistema.

3.1. Casos de uso Los casos de uso constituyen una herramienta central para el modelado de requisitos y cumplen un rol clave cuando se busca justificar y aplicar un patrón de diseño de manera coherente. En ingeniería en informática, los casos de uso permiten describir cómo interactúan los actores con el sistema, qué funcionalidades se esperan y bajo qué condiciones se ejecutan. Esta información resulta fundamental para identificar problemas recurrentes de diseño y vincularlos con patrones adecuados. Desde la perspectiva del diseño orientado a objetos, los casos de uso no solo capturan requisitos funcionales, sino que también revelan puntos críticos de variabilidad, dependencias excesivas o responsabilidades mal distribuidas. Debrauwer (2023) señala que muchos surgen precisamente al analizar interacciones repetidas o acoplamientos detectados a partir de los casos de uso, más que desde la estructura interna del código. Rol de los casos de uso en la selección de patrones El aporte principal de los casos de uso al modelado de patrones se puede resumir en los siguientes aspectos: 1. Permiten comprender el problema desde la interacción real. 2. Hacen visibles flujos repetidos y excepciones. 3. Identifican actores y responsabilidades involucradas. 4. Facilitan detectar requisitos no funcionales implícitos. Al analizar un conjunto de casos de uso, el diseñador puede reconocer situaciones en que una solución directa generaría código duplicado, alto acoplamiento o baja extensibilidad, condiciones que suelen justificar la aplicación de un patrón de diseño.

Ejemplo de caso de uso base Sistema: reservas de laboratorio. Caso de uso: crear reserva

• Actor principal: alumno

• Actores secundarios: encargado de laboratorio, sistema académico

• Flujo principal:

1. el alumno solicita una reserva indicando fecha y horario 2. el sistema valida disponibilidad 3. el sistema registra la reserva 4. el sistema informa el resultado a los actores correspondientes

• Postcondición: reserva creada y notificaciones enviadas Este caso de uso muestra explícitamente una responsabilidad transversal: la notificación. Si se implementa de forma directa dentro del flujo, cada caso de uso similar replicaría la misma lógica, generando duplicación. Detección del problema de diseño Al extender el análisis a otros casos de uso, se observa el patrón recurrente:

• Modificar reserva → notificar

• Eliminar reserva → notificar A partir de esta observación, se identifican los siguientes elementos: 1. Requisito funcional común: notificar eventos de reserva.

2. Requisito no funcional implícito: facilidad para agregar nuevos tipos de notificación. 3. Punto de variabilidad: destinatarios y canales de notificación. Según Debrauwer (2023), este tipo de repetición funcional detectada en los casos de uso es una señal clara de que el diseño requiere desacoplar responsabilidades, condición que suele resolverse mediante patrones orientados a objetos. Ejemplo de traducción del caso de uso al diseño A partir del modelado del caso de uso, la decisión de diseño se justifica así:

• El gestor de reservas se responsabiliza solo de la lógica de negocio.

• La notificación se delega a componentes independientes.

• Cada nuevo tipo de notificación se incorpora sin modificar los casos existentes. Esta traducción directa desde el caso de uso al diseño permite que el patrón seleccionado responda exactamente al requisito modelado, evitando soluciones sobredimensionadas. A continuación, encontrará el Diagrama de Caso de uso de la solución propuesta en el ejemplo:

Figura 4: Propuesta de caso para crear reserva

Tabla de relación casos de uso y patrones Observación en el caso de uso Riesgo de diseño Enfoque estructural Acción repetida en varios casos Duplicación de código Encapsular comportamiento Múltiples actores informados Alto acoplamiento Separar responsabilidades Cambios frecuentes esperados Rigidez del sistema Favorecer extensibilidad Tabla 5. Relación casos de uso y patrones Van der Heyde y Debrauwer (2020) señalan que cuando los casos de uso se utilizan como insumo directo para el diseño, los diagramas UML reflejan mejor la intención del sistema y reducen ambigüedades en la implementación. Crear Reserva Validar disponibilidad Registrar reserva Informar resultado Solicitar reserva indicando fecha y horario <> <> Encargado de laboratorio Sistema académico Alumno <>

Ventajas de usar casos de uso para modelar patrones

• Conectan el patrón con un requisito concreto.
• Facilitan la trazabilidad entre análisis y diseño.
• Evitan aplicar patrones por reconocimiento superficial.
• Mejoran la comunicación del diseño dentro del equipo. En síntesis, los casos de uso permiten modelar los requisitos de un patrón desde la interacción real del sistema con sus actores. Al analizar flujos, repeticiones y variaciones, el diseñador puede identificar problemas recurrentes y seleccionar de forma fundamentada. De este modo, los patrones dejan de ser soluciones abstractas y se convierten en respuestas directas a necesidades claramente modeladas dentro del proceso de ingeniería de software.

---

💡 Conclusión

En conclusión, el estudio integrado de las categorías de patrones de diseño, los atributos de calidad y las técnicas de modelado de requisitos permite comprender que el diseño de software no es una actividad aislada ni puramente técnica, sino un proceso de toma de decisiones fundamentadas. Los patrones adquieren verdadero sentido cuando se entienden como respuestas estructurales y comportamentales a problemas recurrentes, evaluados a la luz de la calidad esperada del sistema y no como soluciones universales aplicables de forma automática. Tal como plantea Debrauwer (2023), la correcta selección de un patrón depende menos del reconocimiento del nombre y más de la comprensión del contexto, la variabilidad y los riesgos asociados. La distinción entre patrones para clases y patrones para objetos evidencia que no todas las problemáticas se resuelven en el mismo nivel del sistema. Mientras unos privilegian la estabilidad estructural, otros favorecen la flexibilidad en el tiempo de ejecución. Esta complementariedad resulta clave para equilibrar orden y adaptabilidad, dos exigencias centrales en sistemas que evolucionan de manera progresiva. A ello se suma el análisis explícito de atributos de calidad, que actúa como criterio orientador para priorizar decisiones y asumir conscientemente los compromisos inherentes al diseño. Herramientas como el QAW y el uso sistemático de casos de uso refuerzan este enfoque, ya que conectan los requisitos reales con decisiones de diseño justificadas. Como señalan Van der Heyde y Debrauwer (2020), cuando el diseño se apoya en un modelado claro, los diagramas y el código reflejan con mayor fidelidad la intención del sistema. En síntesis, integrar patrones, calidad y requisitos permite construir software más comprensible, mantenible y coherente, alineado con los principios de una ingeniería de software reflexiva y sostenible.

Referencias Debrauwer, L. (2023). Los 23 modelos de diseño: descripciones y soluciones ilustradas en UML 2 y Java. Editorial ENI. Van der Heyde, F., y Debrauwer, L. (2020). UML 2.5: iniciación, ejemplos y ejercicios corregidos. Editorial ENI.

---

---

🚀 Potencia tus proyectos tecnológicos con Proyecto Luna

En Proyecto Luna desarrollamos arquitectura de software de alto rendimiento, optimización de bases de datos críticas y soluciones aplicadas de inteligencia artificial y automatización para empresas y profesionales.

• 💼 Soluciones de ingeniería: Conoce nuestras capacidades y casos de estudio en proyectoluna.com/work/.
• 🛡️ Seguridad y auditoría: Orientación técnica y respuesta ante incidentes en ¿Te han hackeado?.
• 📩 Contacto directo: Escríbenos a través de nuestro formulario de contacto o a contacto@proyectoluna.com.

📚 Fuentes y lecturas recomendadas

• Tanenbaum, A. S. (2020). Sistemas y Arquitecturas de Computación.
• Date, C. J. (2019). An Introduction to Database Systems.
• Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts.