Diseño y programación orientada a objetos. Elementos y componentes software: objetos, clases, herencia, métodos, sobrecarga. Ventajas e inconvenientes. Patrones de diseño y lenguaje de modelado unificado (UML).

Tema desarrollado para el ejercicio único del Cuerpo de Técnicos Auxiliares de Informática de la Administración del Estado. Es el tema 4 del bloque III «Desarrollo de sistemas», que en nuestra numeración interna es el tema 18 de 33.

Cuánto pesa y cómo pregunta. Este es el tema del bloque III que más ha crecido en las últimas convocatorias. En 2026 el tribunal preguntó, en la misma prueba, el patrón Observer, la diferencia entre Factory Method y Abstract Factory, el patrón Decorator, la sobrescritura frente a la sobrecarga y el significado del guion en un diagrama de clases. Y no es una racha: en 2024 ya había caído la definición de generalización, la afirmación falsa sobre UML y el diagrama de secuencia, que ha vuelto a salir dos veces más.

Y cómo hay que estudiarlo. Aquí el tribunal no pide programar: pide reconocer una definición. Las preguntas son casi siempre de la forma «¿qué concepto se está aplicando?» o «¿qué patrón resuelve esto?», con un enunciado que describe una situación y cuatro nombres debajo. Por eso este apunte va con las definiciones en la forma exacta en la que el tribunal las escribe, y con la pareja confundible al lado de cada una: sobrecarga y sobrescritura, agregación y composición, clase abstracta e interfaz, Factory Method y Abstract Factory, diagrama de secuencia y de comunicación.

Índice

1. De lo estructurado a lo orientado a objetos
   • Qué problema vino a resolver
   • Los cuatro pilares
2. Elementos: objeto, clase, atributo y método
   • Clase e instancia
   • Atributos y métodos, de instancia y de clase
   • Constructor, destructor y ciclo de vida
   • Visibilidad
   • Mensajes y responsabilidades
3. Abstracción y encapsulación
4. Herencia
   • Generalización y especialización
   • Herencia simple, múltiple y el problema del diamante
   • Clases abstractas e interfaces
   • Composición frente a herencia
5. Polimorfismo, sobrecarga y sobrescritura
6. Paquetes, componentes y otros elementos
7. Ventajas e inconvenientes del paradigma
8. Principios de diseño
9. Patrones de diseño
   • Qué es un patrón y de dónde salen
   • Creacionales
   • Estructurales
   • De comportamiento
   • Los cuatro que ya ha preguntado el tribunal
   • GRASP: los patrones de asignación de responsabilidades
   • Patrones de arquitectura
10. El lenguaje de modelado unificado
    • Qué es UML y, sobre todo, qué NO es
    • Los catorce diagramas
    • El diagrama de clases
    • Las relaciones entre clases
    • Casos de uso
    • Secuencia y comunicación
    • Los demás diagramas
    • UML dentro de Métrica v3
11. Objetos y bases de datos
12. Cuadros para memorizar
13. Lo que ya ha preguntado el tribunal

1. De lo estructurado a lo orientado a objetos

1.1. Qué problema vino a resolver

La programación estructurada organiza el programa por lo que hace: procedimientos que operan sobre datos que están fuera de ellos. Funciona bien mientras el programa es pequeño, y se rompe por un sitio muy concreto: los datos están separados del código que los manipula, así que cualquier procedimiento puede tocarlos, nadie es responsable de mantenerlos coherentes y un cambio en la estructura de datos obliga a revisar todo lo que la usa.

La orientación a objetos le da la vuelta: organiza el programa por lo que hay, no por lo que se hace. Un objeto reúne en una sola unidad los datos y las operaciones que trabajan con ellos, y esa unidad se hace responsable de su propia coherencia. El programa deja de ser una secuencia de llamadas y pasa a ser un conjunto de objetos que se envían mensajes.

El paradigma no es nuevo: nació con Simula 67, se popularizó con Smalltalk en los años setenta y se hizo dominante en los noventa con C++ y Java. Hoy casi todos los lenguajes de uso general son multiparadigma y admiten programar orientado a objetos, estructurado y funcional a la vez, así que lo que se estudia aquí es un estilo disponible, no un compartimento cerrado.

1.2. Los cuatro pilares

Cualquier manual los enumera igual, y conviene tenerlos con una frase cada uno porque el tribunal pregunta por su nombre a partir de la descripción:

Pilar	En una frase
Abstracción	Quedarse con lo esencial de una entidad del problema y descartar el resto, definiéndola por lo que hace y no por cómo lo hace.
Encapsulación	Reunir datos y operaciones en una unidad y ocultar el estado interno, de modo que solo se pueda tocar a través de la interfaz publicada.
Herencia	Definir una clase a partir de otra, reutilizando lo que tiene y añadiendo o especializando lo que haga falta.
Polimorfismo	Que el mismo mensaje produzca comportamientos distintos según el objeto que lo reciba.

Algunos autores añaden un quinto, la modularidad, y otros separan la abstracción de la encapsulación con más cuidado del que se suele. Para el examen basta con los cuatro y con no confundir los dos primeros: abstraer es decidir qué se muestra; encapsular es impedir que se vea lo demás. Uno es una decisión de diseño y el otro, un mecanismo del lenguaje.

2. Elementos: objeto, clase, atributo y método

2.1. Clase e instancia

Una clase es la plantilla: describe qué datos tendrá un objeto de ese tipo y qué operaciones admitirá. Un objeto es un ejemplar concreto de esa plantilla, con sus valores propios, y por eso se lo llama también instancia. La relación es la misma que hay entre un tipo de entidad y una ocurrencia en el modelo de datos, o entre un programa y un proceso en el sistema operativo: uno es la definición y el otro, el ejemplar vivo.

De una misma clase pueden existir miles de objetos a la vez, cada uno con su identidad —es otro objeto aunque sus valores coincidan—, su estado —el valor de sus atributos en cada momento— y su comportamiento —lo que sabe hacer, que es común a todos los de su clase—. Esas tres palabras son las que el tribunal usa para describir un objeto, y conviene tenerlas juntas: identidad, estado y comportamiento.

2.2. Atributos y métodos, de instancia y de clase

Los miembros de una clase son de dos tipos —atributos, que son los datos, y métodos, que son las operaciones— y cada uno puede ser de dos ámbitos:

Ámbito	Qué significa	Ejemplo
De instancia	Cada objeto tiene su propia copia. Es lo normal.	El nombre de un empleado, su método para calcular la antigüedad.
De clase (estáticos)	Uno solo, compartido por todos los objetos de la clase. Existe aunque no se haya creado ningún objeto.	Un contador de cuántos empleados se han creado, o una constante.

Un detalle que se pregunta: un método de clase no puede acceder a los atributos de instancia, porque no sabe de qué objeto se trataría. Al revés sí: un método de instancia puede usar lo que es de la clase.

2.3. Constructor, destructor y ciclo de vida

El constructor es el método especial que se ejecuta al crear el objeto y deja sus atributos en un estado válido. Sus rasgos:

• Se llama igual que la clase y no devuelve nada, ni siquiera vacío.
• Puede haber varios sobrecargados, con distintas listas de parámetros, para admitir varias formas de crear el objeto.
• Si no se escribe ninguno, la mayoría de los lenguajes proporcionan uno por defecto sin parámetros. En cuanto se escribe uno propio, ese regalo desaparece.

El destructor es su simétrico y ahí los lenguajes se separan: en C++ hay que gestionar la memoria a mano y el destructor es una pieza central; en Java, C# y la mayoría de los modernos existe un recolector de basura que libera los objetos sin referencias, y por eso el destructor casi desaparece y se sustituye por mecanismos explícitos de cierre de recursos.

2.4. Visibilidad

Cada miembro de una clase se declara con un modificador de acceso que dice desde dónde se puede usar. Los tres universales, más el de paquete que añaden algunos lenguajes:

Visibilidad	Quién puede usarlo	Símbolo en UML
Público	Cualquiera.	+ (signo más)
Privado	Solo la propia clase.	− (guion o signo menos)
Protegido	La propia clase y sus subclases.	# (almohadilla)
De paquete	Las clases del mismo paquete. Es lo que Java aplica cuando no se escribe modificador.	~ (virgulilla)

🚨 La pregunta de la convocatoria extraordinaria de 2026 fue exactamente esta columna de la derecha: «en un diagrama de clases UML, ¿qué significado tiene el símbolo de resta colocado antes del nombre de un atributo o método?» → indica que el elemento tiene visibilidad privada. Los cuatro símbolos hay que sabérselos, porque el distractor natural es confundir el guion con la almohadilla.

La regla de diseño que va con esto es constante: atributos privados, métodos públicos los que forman la interfaz. El acceso a los datos se ofrece, si hace falta, mediante métodos de consulta y de modificación, lo que permite validar, calcular al vuelo o cambiar la representación interna sin que nadie de fuera se entere.

2.5. Mensajes y responsabilidades

En el vocabulario original del paradigma, un objeto no «llama a un método» de otro: le envía un mensaje, y es el objeto que lo recibe quien decide qué hacer. La diferencia parece retórica y no lo es: el emisor no sabe —ni tiene por qué saber— de qué clase concreta es el receptor, y de ahí sale el polimorfismo entero.

De ese vocabulario viene también el criterio con el que se reparte el trabajo entre clases: cada clase tiene unas responsabilidades, y el buen diseño consiste en que cada responsabilidad viva en la clase que tiene los datos para cumplirla. Cuando un método necesita constantemente datos de otro objeto, la señal es que está en la clase equivocada.

3. Abstracción y encapsulación

La abstracción es una decisión: qué del mundo real entra en el modelo. Una clase Empleado no representa a una persona, representa lo que de una persona le importa a la aplicación de nóminas, y por eso la misma persona será otra clase distinta en la aplicación de formación. Abstraer bien es quedarse con lo esencial para este problema, y de ahí que no exista el modelo «correcto» en abstracto.

La encapsulación es el mecanismo que protege esa decisión: los datos se declaran privados y el acceso pasa por la interfaz publicada. Sus tres consecuencias prácticas se preguntan:

1. Se puede cambiar la implementación sin tocar a quien la usa, siempre que la interfaz se mantenga. Es la misma independencia que persigue un tipo abstracto de datos.
2. Se puede validar. Si el atributo es privado y solo se modifica por un método, ese método puede rechazar los valores imposibles y el objeto nunca queda en un estado inválido.
3. Se reduce el acoplamiento, porque la superficie de contacto entre dos clases es la interfaz y no su estructura interna.

⚠️ Un aviso que conviene interiorizar: generar mecánicamente un método de consulta y otro de modificación para cada atributo no es encapsular. Si todos los atributos son accesibles y modificables desde fuera, el objeto sigue siendo una estructura de datos con adornos y ninguna de las tres ventajas anteriores se cumple. Encapsular es publicar operaciones con sentido, no aberturas para cada campo.

4. Herencia

4.1. Generalización y especialización

La herencia permite definir una clase a partir de otra. La de arriba se llama superclase, clase base o padre; la de abajo, subclase, clase derivada o hija. Y la relación se lee en los dos sentidos: de abajo arriba es una generalización —se abstrae lo común— y de arriba abajo, una especialización.

🚨 El tribunal preguntó su definición dos veces, y la dio por buena en esta forma exacta: una relación de generalización entre clases «implica que la subclase hereda las propiedades, el comportamiento y las relaciones de la superclase, a la vez que puede añadir sus propias propiedades, relaciones y comportamiento». Merece leerse dos veces porque tiene dos mitades y tres sustantivos, y los distractores atacan siempre lo mismo:

• Se heredan tres cosas, no dos: propiedades, comportamiento y relaciones. Las relaciones que la superclase tenga con otras clases valen también para la subclase.
• La subclase puede añadir lo suyo. No es una copia congelada: la herencia sirve precisamente para extender.

El criterio para decidir si algo debe heredar es la relación «es un»: un Funcionario es un Empleado, luego puede heredar. Si la frase que sale natural es «tiene un», lo que corresponde no es herencia sino composición, y confundirlas es el error de diseño más caro del paradigma.

4.2. Herencia simple, múltiple y el problema del diamante

La herencia simple admite una sola superclase; la múltiple, varias. Y la múltiple trae un problema conocido con nombre propio:

Si dos superclases heredan a su vez de una común y definen el mismo método, la clase de abajo hereda dos versiones del mismo miembro y el lenguaje tiene que decidir cuál vale. Es el problema del diamante, por la forma del diagrama, y cada lenguaje lo resuelve a su manera: C++ la admite y ofrece la herencia virtual para desambiguar; Java y C# la prohíben entre clases y solo la permiten entre interfaces, que al no tener estado no arrastran el conflicto; Python la admite y fija un orden de resolución determinista.

4.3. Clases abstractas e interfaces

Son las dos formas de declarar un contrato sin implementarlo del todo, y el tribunal las cruza:

	Clase abstracta	Interfaz
¿Se puede instanciar?	No	No
¿Puede tener métodos ya implementados?	Sí, puede estar implementada a medias	Tradicionalmente no; los lenguajes modernos admiten métodos por defecto
¿Puede tener atributos de estado?	Sí	No, solo constantes
¿Cuántas se pueden heredar o implementar?	Una en Java y C#	Varias
Qué expresa	Una relación «es un» con código compartido	Una capacidad: «sabe hacer esto»

La regla práctica que se deduce del cuadro: si hay código que compartir, clase abstracta; si lo que se quiere es que clases sin relación entre sí ofrezcan la misma operación, interfaz. Y como las interfaces se pueden implementar varias, son la vía por la que Java y C# recuperan buena parte de lo que la herencia múltiple daba, sin su problema.

🚨 Con esto se resuelve una pregunta que el tribunal repitió en cuatro convocatorias sobre los tipos abstractos de datos, pidiendo la afirmación INCORRECTA. La falsa decía: «en Java, una estructura de datos (interface) debe implementar todas las operaciones definidas en su TAD (class)». Está invertido: en Java el tipo abstracto —el contrato, lo que se puede hacer— se expresa con una interfaz, y la estructura de datos —la implementación concreta— es la clase que la implementa. La frase cambia los dos términos de sitio, y quien no tenga clara la correspondencia la lee como razonable.

4.4. Composición frente a herencia

La herencia es el mecanismo más vistoso del paradigma y también el más abusado. Su problema es que crea el acoplamiento más fuerte que existe entre dos clases: la subclase depende de los detalles internos de la superclase, y un cambio arriba rompe abajo sin previo aviso. A eso se lo llama el problema de la clase base frágil.

La alternativa es la composición: en lugar de heredar de una clase, se guarda un objeto de ella como atributo y se le delega lo que haga falta. Se pierde el automatismo y se gana flexibilidad, porque el objeto interno se puede sustituir en tiempo de ejecución y porque la clase de fuera solo depende de la interfaz que use.

De ahí el consejo clásico del propio libro de patrones: preferir la composición a la herencia. No es una prohibición: es un orden de preferencia, y la herencia sigue siendo la respuesta cuando la relación «es un» es real y estable.

5. Polimorfismo, sobrecarga y sobrescritura

Polimorfismo significa «muchas formas»: que el mismo mensaje produzca comportamientos distintos según quién lo reciba. Se manifiesta de varias maneras, y las dos que el tribunal pregunta —una en 2026 y otra en 2023— son estas, que además se confunden entre sí por el parecido del nombre:

	Sobrecarga (overloading)	Sobrescritura (overriding)
Dónde ocurre	En la misma clase (o heredada)	Entre superclase y subclase
Los métodos comparten	El nombre	El nombre y la lista de parámetros
Se distinguen por	La lista de parámetros: número, tipo u orden	Nada: son idénticos en su firma
Para qué	Ofrecer varias formas de invocar lo mismo	Especializar el comportamiento heredado
Cuándo se resuelve	Al compilar (enlace estático)	Al ejecutar (enlace dinámico)

🚨 La pregunta de 2026, en los dos modelos, decía: «en una arquitectura de herencia simple, si una subclase define un método con la misma lista de parámetros que un método de su superclase para especializar su comportamiento, ¿qué concepto se está aplicando?» → sobrescritura. Las dos pistas están en el enunciado y son suficientes: misma lista de parámetros descarta la sobrecarga, que exige que la lista cambie; y especializar el comportamiento heredado es literalmente para lo que sirve la sobrescritura.

🚨 Y la de 2023 preguntaba lo contrario desde el otro lado: «C++ permite especificar más de una función con el mismo nombre en el mismo ámbito, ¿cómo se denominan?» → funciones sobrecargadas. Aquí la pista es el mismo ámbito: no hay dos clases, luego no puede haber sobrescritura.

La pieza que hace funcionar a la sobrescritura es el enlace dinámico: cuando se invoca un método sobre una referencia, el sistema no mira el tipo declarado de la referencia sino la clase real del objeto que hay dentro, y ejecuta la versión de esa clase. Es lo que permite recorrer una lista de figuras llamando a «dibujar» y que cada una se dibuje a su manera sin un solo condicional. En C++ hay que pedirlo declarando el método como virtual; en Java es el comportamiento por omisión.

Junto a estas dos, conviene reconocer otras dos formas del mismo fenómeno que aparecen en los manuales: el polimorfismo paramétrico, que es lo que dan los genéricos —una misma clase Lista que sirve para cualquier tipo—, y el polimorfismo de subtipos, que es el que acabamos de describir y el que se da por supuesto cuando se dice «polimorfismo» a secas.

5.4. El ejemplo que lo explica todo

El polimorfismo se entiende de golpe con un caso mínimo. Supongamos una jerarquía de documentos del expediente electrónico:

abstract class Documento {
    protected String titulo;
    public abstract String obtenerFormato();
    public String describir() {
        return titulo + " (" + obtenerFormato() + ")";
    }
}

class DocumentoPdf extends Documento {
    public String obtenerFormato() { return "PDF/A"; }
}

class DocumentoXml extends Documento {
    public String obtenerFormato() { return "XML firmado"; }
}

Tres cosas ocurren aquí a la vez, y las tres se preguntan:

1. La clase de arriba es abstracta y declara un método sin cuerpo. No se puede crear un Documento a secas: solo tiene sentido crear uno de los concretos.
2. El método describir está implementado en la superclase y sin embargo funciona distinto para cada subclase, porque llama a un método que cada una resuelve a su manera. Eso es exactamente lo que quiere decir «una clase abstracta puede estar implementada a medias».
3. Si se guardan los dos objetos en una lista de Documento y se recorre llamando a describir, cada uno responde con su formato sin un solo condicional. Añadir un tercer formato mañana consiste en escribir una clase nueva y no tocar nada de lo anterior: eso es el principio de abierto/cerrado en acción.

Y de aquí sale también la diferencia con la sobrecarga, que es de otra naturaleza. Si en la misma clase se escriben dos métodos describir, uno sin parámetros y otro que recibe un idioma, hay sobrecarga: dos operaciones distintas que comparten nombre por comodidad, y el compilador decide cuál llamar mirando los argumentos. Nada de eso tiene que ver con la herencia.

5.5. Enlace estático y enlace dinámico

La pregunta técnica de fondo es cuándo se decide qué código se ejecuta, y hay dos respuestas:

	Enlace estático	Enlace dinámico
Cuándo se decide	Al compilar	Al ejecutar
Con qué se decide	El tipo declarado de la referencia	La clase real del objeto
Qué resuelve	La sobrecarga y los métodos estáticos, finales y privados	La sobrescritura
Coste	Ninguno	Una indirección por llamada, a través de la tabla de métodos virtuales

⚠️ Y aquí está la diferencia entre lenguajes que conviene tener presente: en Java el enlace dinámico es el comportamiento por omisión para los métodos de instancia, mientras que en C++ hay que pedirlo declarando el método como virtual. Si en C++ se olvida esa palabra, la llamada se resuelve por el tipo declarado y la subclase no llega a intervenir: el programa compila, se ejecuta y hace lo que no se esperaba. Es uno de los errores más difíciles de ver de todo el paradigma, porque no falla, sino que acierta la respuesta equivocada.

5.6. La referencia al propio objeto y a la superclase

Dentro de un método, dos palabras reservadas permiten hablar del propio objeto y de lo heredado:

• La referencia al objeto actual —this en Java, C++ y C#, self en Python— sirve para desambiguar cuando un parámetro se llama igual que un atributo, y para que un constructor llame a otro de la misma clase.
• La referencia a la superclase —super en Java, base en C#— permite invocar la versión heredada de un método que se está sobrescribiendo, que es el patrón habitual: hacer lo que hacía el padre y además lo propio.

Con ellas va una regla que se pregunta: el constructor de la subclase invoca siempre, primero, al de la superclase. Si no se escribe la llamada, el compilador la inserta apuntando al constructor sin parámetros; y si la superclase no tiene ninguno sin parámetros porque escribió otro propio, el programa no compila. De ahí sale una cadena de construcción que va de la clase más general a la más concreta, y una de destrucción que recorre el camino inverso.

5.7. Igualdad e identidad: los dos métodos que van juntos

Dos objetos pueden ser el mismo objeto o ser objetos distintos con los mismos valores, y esa diferencia tiene consecuencias prácticas todos los días:

• La identidad pregunta si las dos referencias apuntan al mismo sitio. En Java es lo que compara el operador de igualdad cuando se aplica a objetos.
• La igualdad pregunta si los dos objetos representan lo mismo, y eso lo decide la clase reescribiendo el método correspondiente. Dos expedientes con el mismo número son iguales aunque sean dos objetos.

La regla que se olvida y da errores silenciosos: quien reescribe el método de igualdad tiene que reescribir también el de resumen, porque las colecciones basadas en dispersión usan el segundo para colocar el objeto y el primero para compararlo. Si uno dice que dos objetos son iguales y el otro los coloca en cubos distintos, el objeto se guarda y después no se encuentra. Es exactamente el mismo razonamiento de la tabla hash del tema de estructuras de datos, aplicado aquí.

⚠️ Y conviene recordar el caso vecino, que el tribunal preguntó en 2026 desde el otro lado: en Java los tipos primitivos no son objetos y no tienen métodos, así que llamar al método de igualdad sobre un entero da error de compilación. Para compararlos se usa el operador.

5.8. Objetos inmutables

Un objeto es inmutable cuando su estado no cambia después de construirse. Se consigue declarando los atributos como constantes, no ofreciendo métodos de modificación y devolviendo copias de lo que sea mutable dentro.

Cuesta un poco más de memoria y compensa por tres razones que se preguntan como ventajas del paradigma bien aplicado: un objeto inmutable es seguro entre hilos sin sincronizar nada, se puede compartir y cachear sin miedo, y no puede quedar en un estado inválido porque no cambia. Es la razón de que las cadenas de texto sean inmutables en Java y en C#, y de que para concatenarlas dentro de un bucle haya que usar un constructor de cadenas en lugar del operador.

6. Paquetes, componentes y otros elementos

El enunciado oficial habla de «elementos y componentes software», así que conviene tener nombrados los que están por encima de la clase:

• Paquete o espacio de nombres: agrupa clases relacionadas y evita que dos clases con el mismo nombre choquen. En Java define además un nivel de visibilidad propio.
• Componente: una unidad de software sustituible que ofrece unas interfaces y requiere otras, y que se despliega como una pieza. Es el nivel al que se piensa la arquitectura, por encima de las clases.
• Biblioteca y marco de trabajo: las dos son código de terceros, y se distinguen por quién manda. En una biblioteca es tu código el que la llama; en un marco es el marco el que llama a tu código, y a esa inversión se la conoce como principio de Hollywood.
• Genéricos: clases y métodos parametrizados por un tipo, que permiten escribir una vez lo que serviría para muchos tipos sin renunciar a la comprobación en tiempo de compilación.
• Excepciones: el mecanismo por el que un método comunica que no ha podido cumplir su contrato. Encajan aquí porque forman parte de la interfaz de una clase tanto como sus métodos.

7. Ventajas e inconvenientes del paradigma

El enunciado del tema los nombra expresamente, así que van enumerados y con honestidad, que es como se preguntan.

Ventajas	Inconvenientes
Reutilización: la herencia y la composición permiten aprovechar código ya escrito y probado.	Curva de aprendizaje: diseñar bien con objetos cuesta más que escribir procedimientos, y un diseño mediocre es peor que no tener diseño.
Mantenibilidad: el cambio queda contenido dentro de la clase responsable.	Sobrecarga de rendimiento: el enlace dinámico, la creación de objetos y la indirección tienen un coste, notable en sistemas empotrados o de tiempo real.
Modelado natural: las clases se parecen a las entidades del problema, así que el usuario entiende el modelo.	Sobreingeniería: la tentación de crear jerarquías profundas y patrones donde bastaba una función.
Encapsulación: el estado se protege y se puede validar en un solo sitio.	Acoplamiento por herencia: el problema de la clase base frágil, ya visto.
Polimorfismo: se añade un caso nuevo creando una clase, sin tocar el código existente.	Desajuste con el almacenamiento relacional: guardar objetos en tablas obliga a traducir, y de ahí nacen los mapeadores.
Trabajo en equipo: la interfaz publicada permite repartir clases entre personas.	Dispersión de la lógica: seguir una operación puede exigir saltar por diez clases, lo que dificulta leer el código de un tirón.

La lectura honesta del cuadro es que casi todos los inconvenientes son de mal uso y casi todas las ventajas exigen disciplina. El paradigma no garantiza nada por sí solo: una jerarquía mal planteada produce código más rígido que el procedimiento más tosco.

8. Principios de diseño

8.1. Cohesión y acoplamiento

Son los dos criterios de siempre y siguen valiendo aquí, aplicados a la clase en lugar del módulo. La cohesión mide cuánto tienen que ver entre sí las responsabilidades que hay dentro de una clase, y cuanto más alta, mejor. El acoplamiento mide cuánto depende una clase de las demás, y cuanto más bajo, mejor. La regla se pregunta tal cual: alta cohesión y bajo acoplamiento.

Y hay una jerarquía de acoplamientos que conviene reconocer, de peor a mejor: compartir estado global es lo peor; heredar es lo siguiente; conocer la clase concreta de a quién se llama viene después; y depender solo de una interfaz es lo más flojo y lo deseable.

8.2. SOLID

Cinco principios que resumen buena parte de lo que se ha aprendido sobre diseño orientado a objetos. Van con su nombre y su frase, porque es como se preguntan:

Letra	Principio	Qué dice
S	Responsabilidad única	Una clase debe tener una sola razón para cambiar. Si dos motivos distintos obligan a tocarla, son dos clases.
O	Abierto/cerrado	Abierta a la extensión, cerrada a la modificación: añadir un caso nuevo debería ser crear una clase, no editar la existente.
L	Sustitución de Liskov	Un objeto de una subclase debe poder sustituir a uno de su superclase sin que el programa se rompa. Si la subclase rompe una promesa de la superclase, la herencia está mal planteada.
I	Segregación de interfaces	Mejor varias interfaces pequeñas que una grande: nadie debería depender de métodos que no usa.
D	Inversión de dependencias	Depender de abstracciones, no de implementaciones concretas. Es la base de la inyección de dependencias.

8.3. Los otros principios con nombre

• No te repitas: cada pieza de conocimiento debe tener una representación única en el sistema. Duplicar código duplica los sitios donde corregir el error.
• Hazlo simple: entre dos diseños que funcionan, el más simple. La complejidad se paga todos los días.
• No lo vas a necesitar: no construir hoy la flexibilidad que quizá haga falta mañana, porque casi siempre hace falta otra distinta.
• Ley de Demeter o principio del menor conocimiento: un objeto debe hablar solo con sus vecinos inmediatos, no encadenar llamadas a través de terceros. Su síntoma es la cadena de puntos que atraviesa tres objetos.

9. Patrones de diseño

9.1. Qué es un patrón y de dónde salen

Un patrón de diseño es una solución probada a un problema recurrente de diseño, descrita de forma que se pueda aplicar a situaciones distintas. No es código listo para copiar: es una plantilla de estructura y de responsabilidades, y cada aplicación concreta se escribe a medida.

El catálogo de referencia es el libro Design Patterns de 1994, escrito por cuatro autores a los que se conoce como el Gang of Four —la «banda de los cuatro»—, y por eso los patrones de ese catálogo se citan como patrones GoF. Son veintitrés y se reparten en tres familias según lo que resuelven:

Familia	De qué se ocupa	Cuántos
Creacionales	De cómo se crean los objetos, desacoplando al cliente de la clase concreta que se instancia.	5
Estructurales	De cómo se componen clases y objetos para formar estructuras mayores.	7
De comportamiento	De cómo se comunican y reparten responsabilidades los objetos.	11

Saber a qué familia pertenece cada patrón resuelve media pregunta, porque el enunciado del tribunal suele decirlo: cuando en 2026 preguntó «qué patrón de comportamiento se utiliza para…», la palabra «comportamiento» ya descartaba a todos los creacionales y estructurales que hubiera entre las opciones.

9.2. Patrones creacionales

Patrón	Qué resuelve
Singleton	Garantizar que de una clase exista una sola instancia y dar un punto de acceso global a ella. Es el más conocido y el más criticado, porque introduce estado global disfrazado.
Factory Method (método de fabricación)	Definir una operación para crear un objeto y dejar que las subclases decidan qué clase concreta se instancia. Crea objetos de un mismo tipo.
Abstract Factory (fábrica abstracta)	Ofrecer una interfaz para crear familias de objetos relacionados sin especificar sus clases concretas. Crea objetos de una misma familia.
Builder (constructor)	Separar la construcción de un objeto complejo de su representación, de modo que el mismo proceso pueda producir objetos distintos. Es la respuesta al constructor con quince parámetros.
Prototype (prototipo)	Crear objetos clonando un ejemplar existente en lugar de construirlos desde cero.

🚨 La pregunta de la convocatoria extraordinaria de 2026 pedía la diferencia fundamental entre los dos primeros de fabricación, y la respuesta que dio por buena es exactamente esta: «Factory Method sirve para crear objetos de un mismo tipo, mientras que Abstract Factory permite crear objetos de una misma familia». La forma corta de retenerlo: uno fabrica productos, la otra fabrica juegos de productos que van juntos —todos los controles de una interfaz de un mismo estilo, todos los objetos de acceso a datos de un mismo gestor—.

9.3. Patrones estructurales

Patrón	Qué resuelve
Adapter (adaptador)	Convertir la interfaz de una clase en otra que el cliente espera, de modo que puedan trabajar juntas clases que no fueron diseñadas para ello. Es el patrón de la pieza heredada que no se puede tocar.
Decorator (decorador)	Añadir funcionalidad a un objeto dinámicamente, envolviéndolo en otro que comparte su interfaz. Es la alternativa flexible a crear una subclase por cada combinación.
Facade (fachada)	Ofrecer una interfaz única y sencilla a un subsistema complicado, para que el cliente no tenga que conocer sus piezas.
Proxy (apoderado)	Poner un sustituto delante de un objeto para controlar el acceso: carga diferida, control de permisos, invocación remota o registro.
Composite (compuesto)	Tratar de forma uniforme objetos individuales y agrupaciones de objetos, componiéndolos en estructuras de árbol.
Bridge (puente)	Separar una abstracción de su implementación para que las dos puedan variar por su cuenta.
Flyweight (peso ligero)	Compartir el estado común entre muchos objetos pequeños para no multiplicar la memoria.

🚨 Dos de esta tabla han caído literalmente. En 2023, en un supuesto práctico: «se ha heredado una librería compilada que realiza la conexión a un servicio de Cl@ve PIN, ¿qué patrón permite reutilizar este objeto?» → Adaptador. Las tres palabras que resuelven la pregunta son librería compilada —no se puede modificar—, heredada —ya existe— y reutilizar: hay que envolverla, no reescribirla. Y en 2026: «indique cuál de las definiciones se corresponde con el patrón Decorator» → «proporciona el poder agregar una nueva funcionalidad a un objeto dinámicamente». La palabra que lo delata es dinámicamente: en tiempo de ejecución, sobre un objeto ya creado, no en tiempo de compilación creando una subclase.

9.4. Patrones de comportamiento

Patrón	Qué resuelve
Observer (observador)	Definir una dependencia de uno a muchos de modo que, cuando un objeto cambia de estado, se notifique automáticamente a todos los que dependen de él, manteniendo un acoplamiento débil.
Strategy (estrategia)	Encapsular una familia de algoritmos intercambiables y poder elegir uno en tiempo de ejecución.
Template Method (método plantilla)	Definir el esqueleto de un algoritmo en la superclase y dejar que las subclases rellenen algunos pasos.
Command (orden)	Encapsular una petición como un objeto, lo que permite encolarla, registrarla y deshacerla.
Iterator (iterador)	Recorrer los elementos de una colección sin exponer su estructura interna.
State (estado)	Que un objeto cambie de comportamiento cuando cambia su estado interno, como si cambiara de clase.
Chain of Responsibility	Pasar una petición por una cadena de manejadores hasta que uno la atiende.
Mediator, Memento, Visitor, Interpreter	Centralizar la comunicación entre objetos; guardar y restaurar un estado sin romper la encapsulación; separar un algoritmo de la estructura sobre la que opera; e interpretar una gramática.

🚨 Observer cayó en los dos modelos de 2026 con el enunciado calcado de su definición: «¿qué patrón de diseño de comportamiento se utiliza para notificar automáticamente a múltiples objetos sobre los cambios de estado de un sujeto, manteniendo un acoplamiento débil?». Las cuatro pistas están en la frase, y la última es la que lo separa de cualquier solución a mano: el sujeto no conoce a sus observadores más que por una interfaz, y por eso se pueden añadir y quitar sin tocarlo.

9.5. Los cuatro que ya ha preguntado el tribunal, juntos

Patrón	Familia	La frase que lo delata en el enunciado
Observer	Comportamiento	«Notificar automáticamente a múltiples objetos», «acoplamiento débil»
Adapter	Estructural	«Reutilizar» una pieza «heredada» o «compilada» que no se puede tocar
Decorator	Estructural	«Agregar una nueva funcionalidad a un objeto dinámicamente»
Factory Method / Abstract Factory	Creacionales	«Mismo tipo» frente a «misma familia»

9.6. GRASP: los patrones de asignación de responsabilidades

🚨 Este apartado sale de una pregunta que el tribunal ha puesto dos veces —en el ingreso libre y en la promoción interna de 2023— y que no se contesta con la Banda de los Cuatro. Las siglas GRASP son General Responsibility Assignment Software Patterns: patrones generales de software para la asignación de responsabilidades en el diseño orientado a objetos. Esa definición es, palabra por palabra, el enunciado oficial.

La diferencia con los patrones GoF conviene tenerla clara, porque es lo que hace reconocible la pregunta:

• Los GoF resuelven un problema concreto de construcción: cómo crear un objeto, cómo envolverlo, cómo avisar a los interesados. Son recetas con estructura de clases.
• Los GRASP resuelven una pregunta anterior y más básica: ¿a qué clase le toca hacer esto? No son recetas de código, son criterios para repartir el trabajo entre las clases. Por eso se estudian antes de los GoF y no compiten con ellos.

Los nueve patrones GRASP, con el criterio que impone cada uno:

Patrón	Qué dice	Ejemplo en un expediente administrativo
Experto en información	La responsabilidad se asigna a la clase que tiene los datos necesarios para cumplirla.	El importe total de una solicitud lo calcula la propia solicitud, que es quien conoce sus líneas.
Creador	Crea el objeto quien lo contiene, lo agrega, lo usa de cerca o tiene sus datos de inicialización.	El expediente crea sus documentos, no una clase externa de utilidades.
Controlador	Los sucesos que llegan de fuera los recibe una clase controladora, no la interfaz ni el objeto de negocio.	El controlador de la sede recibe «registrar solicitud» y delega; la pantalla no llama al repositorio.
Bajo acoplamiento	Repartir de forma que cada clase dependa del menor número posible de otras.	Si el cambio de una tabla obliga a tocar seis clases, el reparto está mal hecho.
Alta cohesión	Cada clase debe tener responsabilidades relacionadas entre sí y pocas.	Una clase que valida, notifica, imprime y archiva no está cohesionada: son cuatro clases.
Polimorfismo	Cuando el comportamiento varía por tipo, se resuelve con tipos polimórficos, no con una cadena de condicionales.	Cada tipo de notificación sabe enviarse; no hay un switch por canal.
Fabricación pura	Se inventa una clase que no existe en el dominio para no romper la cohesión de las que sí.	Un repositorio o un servicio de firma: no son conceptos del expediente, pero evitan cargarlo.
Indirección	Se interpone un intermediario entre dos elementos para que no se acoplen directamente.	Una interfaz de pasarela de pagos entre la aplicación y el banco concreto.
Variaciones protegidas	Se identifica lo que va a cambiar y se envuelve en una interfaz estable.	El acceso al registro se hace contra una interfaz, para que cambiar de plataforma no propague.

Los cuatro últimos son fáciles de confundir entre sí, y la regla para separarlos es corta: fabricación pura inventa una clase que el dominio no tiene; indirección mete un tercero entre dos que ya existían; variaciones protegidas es la razón por la que se hace, no el cómo; y polimorfismo es el mecanismo concreto con el que suele hacerse.

⚠️ Las tres opciones que el tribunal puso al lado de GRASP también hay que saber descartarlas, porque son reales y suenan igual de bien:

• OOD (Object-Oriented Design) es el nombre genérico del diseño orientado a objetos: la disciplina entera, no un catálogo de patrones. Es la trampa exacta de la pregunta, porque el enunciado dice «en el diseño orientado a objetos» y quien lee en diagonal marca la sigla que repite esas palabras.
• Booch es Grady Booch y su método de análisis y diseño orientado a objetos de los años noventa, con notación propia. No asigna responsabilidades: es una de las tres metodologías que se fundieron para dar UML, junto con las de Rumbaugh y Jacobson. Cae también en el apartado de UML, así que este nombre se estudia una vez y sirve dos veces.
• Fan-in y fan-out son métricas de acoplamiento estructural: cuántos módulos llaman a uno (fan-in) y a cuántos llama él (fan-out). Miden lo que GRASP intenta gobernar, pero son un número, no un patrón. Un fan-out alto es el síntoma medible del acoplamiento que el patrón de bajo acoplamiento quiere evitar.

9.7. Antipatrones

Junto al catálogo de lo que funciona existe el de lo que no, y sus nombres también aparecen en la literatura profesional:

• Objeto todopoderoso: una clase que lo hace todo y lo sabe todo. Es el síntoma de cohesión nula.
• Código espagueti: flujo de control enredado, sin estructura reconocible.
• Martillo de oro: aplicar la misma solución a cualquier problema porque es la que se conoce.
• Programación por copia y pega: duplicar en lugar de abstraer, con lo que el error se corrige en un sitio y sobrevive en cuatro.

9.8. Patrones de arquitectura

Por encima de los patrones de diseño están los de arquitectura, que organizan el sistema entero. Los que conviene reconocer:

Patrón	Cómo reparte el sistema
Modelo-Vista-Controlador (MVC)	El modelo guarda los datos y las reglas; la vista los presenta; el controlador recibe la interacción y coordina a los otros dos. Es el patrón de casi todos los marcos web.
Arquitectura en capas	Presentación, lógica de negocio y acceso a datos, cada capa hablando solo con la de debajo.
MVVM	Variante de MVC con un modelo de vista que expone los datos ya preparados para la interfaz. Es el de las plataformas con enlace de datos.
Microservicios	El sistema se parte en servicios pequeños e independientes, cada uno con su propio despliegue y sus propios datos.
Inyección de dependencias	Un contenedor externo proporciona a cada objeto las piezas que necesita, en lugar de que él las cree. Es la aplicación práctica del principio de inversión de dependencias.

9.8. Dos patrones escritos, para no confundirlos nunca más

Los patrones se aprenden mal de memoria y bien viéndolos. Van los dos que el tribunal ha preguntado con más detalle.

Observer, el de la notificación automática. El problema es este: un objeto cambia y varios tienen que enterarse, pero no queremos que el que cambia conozca a los que se enteran, porque entonces habría que tocarlo cada vez que aparece uno nuevo. La solución tiene tres piezas:

interface Observador {
    void actualizar(Expediente e);
}

class Expediente {                       // el SUJETO
    private List<Observador> observadores = new ArrayList<>();
    private String estado;

    public void suscribir(Observador o) { observadores.add(o); }

    public void cambiarEstado(String nuevo) {
        this.estado = nuevo;
        for (Observador o : observadores) o.actualizar(this);
    }
}

Fíjate en lo que no hay ahí: el expediente no menciona ni al registro de auditoría, ni al servicio de avisos, ni al panel de estadísticas. Solo conoce una interfaz, y por eso se pueden añadir observadores nuevos sin tocar una línea de esta clase. Eso es lo que el enunciado del examen llama acoplamiento débil, y es la palabra que delata el patrón.

Adapter, el de la pieza que no se puede tocar. El problema es el opuesto: existe una clase que hace lo que necesitamos pero con otra interfaz, y no podemos modificarla porque viene compilada de fuera. La solución es envolverla:

interface Verificador {                   // lo que ESPERA nuestro código
    boolean comprobar(String documento);
}

class AdaptadorClavePin implements Verificador {
    private final LibreriaClavePin externa;   // la pieza heredada

    public boolean comprobar(String documento) {
        return externa.validaUsuario(documento) == 0;
    }
}

El adaptador implementa nuestra interfaz y por dentro traduce la llamada a la de la biblioteca ajena, incluida la conversión del resultado. Nuestro código nunca ve la biblioteca, así que el día que se sustituya por otra bastará con escribir otro adaptador. Es exactamente el supuesto de 2023: una librería compilada de Cl@ve PIN que hay que reutilizar sin poder modificarla.

Y la confusión que conviene deshacer de una vez: Adapter y Decorator se parecen porque los dos envuelven un objeto, y se distinguen por para qué. El adaptador cambia la interfaz y no toca el comportamiento; el decorador conserva la interfaz y añade comportamiento. Uno traduce, el otro suma.

9.9. Cuándo NO usar un patrón

Conviene cerrar el epígrafe con la advertencia que todos los autores repiten y que ningún opositor memoriza: un patrón resuelve un problema que hay que tener. Aplicarlo sin ese problema añade clases, indirecciones y nombres raros a cambio de nada, y produce un código más difícil de leer que el ingenuo que venía a mejorar.

Las tres señales de que un patrón sobra son bastante fiables: que haya una sola implementación de la interfaz que se ha creado para desacoplar; que la fábrica devuelva siempre la misma clase; y que haya que explicar el diseño a quien lea el código para que entienda una operación que en dos líneas se habría entendido sola. El criterio profesional es el mismo que el de la normalización en bases de datos: se aplica hasta donde resuelve un problema real, y ni un paso más.

10. El lenguaje de modelado unificado

10.1. Qué es UML y, sobre todo, qué NO es

UML —Unified Modeling Language— es un lenguaje gráfico de modelado normalizado por el Object Management Group. Nació a mediados de los noventa de la unificación de tres notaciones que competían entre sí, las de Booch, Rumbaugh y Jacobson, de donde le viene el nombre.

Y aquí está la pregunta que el tribunal ha hecho, y que se falla por no leer una palabra:

🚨 En 2024 pidió la afirmación INCORRECTA sobre UML, y la falsa era: «muestra únicamente el modelado estático de un sistema software, que puede utilizarse en las diferentes fases de su ciclo de desarrollo». Es falsa por esas dos palabras: UML modela lo estático y lo dinámico, y de hecho la mitad de sus diagramas son de comportamiento. La segunda parte de la frase sí es cierta —se usa en todas las fases—, y ese es el truco: la opción mezcla algo verdadero con la palabra que la vuelve falsa.

Cuatro precisiones más que conviene tener claras porque son la fuente natural de distractores:

• UML no es una metodología. No dice en qué orden hacer las cosas ni qué entregar en cada fase: es una notación. La metodología es otra cosa —Métrica v3, un método ágil— y usa UML como herramienta.
• UML no es un lenguaje de programación. No se ejecuta. Existen herramientas que generan código a partir de los diagramas y viceversa, pero eso es una función de la herramienta, no del lenguaje.
• UML no es exclusivo de la orientación a objetos en la práctica, aunque nació para ella y su diagrama central sea el de clases.
• No hay obligación de dibujarlos todos. Un proyecto real usa tres o cuatro diagramas; dibujar los catorce es una señal de que se está documentando en vez de diseñando.

10.2. Los catorce diagramas

La versión 2 de UML define catorce tipos de diagrama, repartidos en dos grandes grupos. Esta clasificación es la que hay que llevar aprendida, porque las preguntas suelen dar una descripción y pedir el diagrama:

Grupo	Diagramas	Qué representan
Estructurales (lo estático)	Clases, objetos, componentes, despliegue, paquetes, estructura compuesta, perfiles	Qué piezas hay y cómo se relacionan, sin hablar del tiempo.
De comportamiento (lo dinámico)	Casos de uso, actividad, máquina de estados, y los de interacción: secuencia, comunicación, tiempos y visión general de interacción	Qué ocurre, en qué orden y quién hace qué.

Los cuatro diagramas de interacción —secuencia, comunicación, tiempos y visión general— forman un subgrupo dentro de los de comportamiento, y esa jerarquía en dos niveles es la que a veces se pregunta.

10.3. El diagrama de clases

Es el diagrama central del modelado orientado a objetos: describe la estructura del sistema mostrando sus clases, sus atributos y las relaciones entre ellas. Cada clase se dibuja como un rectángulo dividido en tres compartimentos:

1. El nombre de la clase, en la parte de arriba. Si es abstracta, en cursiva.
2. Los atributos, con su visibilidad, su nombre y su tipo.
3. Los métodos u operaciones, con su visibilidad, su nombre, sus parámetros y el tipo devuelto.

Y delante de cada atributo y de cada método va el símbolo de visibilidad, que es la pregunta ya vista: + público, − privado, # protegido y ~ de paquete. Los miembros estáticos se escriben subrayados.

10.4. Las relaciones entre clases

El otro contenido del diagrama de clases son las líneas, y cada una tiene su símbolo y su significado. Esta tabla es la que resuelve las preguntas de «qué relación es esta»:

Relación	Cómo se dibuja	Qué significa
Asociación	Línea simple	Las dos clases se conocen y colaboran. Es la relación por defecto.
Agregación	Línea con rombo hueco en el lado del todo	Relación «tiene un» débil: la parte puede existir sin el todo y puede compartirse. Un departamento tiene empleados, y el empleado sigue existiendo si el departamento desaparece.
Composición	Línea con rombo relleno en el lado del todo	Relación «tiene un» fuerte: la parte no existe sin el todo y no se comparte. Si se destruye el pedido, se destruyen sus líneas.
Generalización	Línea con triángulo hueco apuntando a la superclase	Herencia: relación «es un».
Realización	Línea discontinua con triángulo hueco	Una clase implementa una interfaz.
Dependencia	Flecha discontinua	Una clase usa a otra de forma puntual —como parámetro, como valor devuelto— sin guardarla.

La pareja que más se confunde es agregación y composición, y se distinguen por una sola pregunta: ¿la parte puede vivir sin el todo? Si sí, agregación y rombo hueco; si no, composición y rombo relleno. La regla mnemotécnica: el rombo relleno mata, porque al destruir el todo se lleva por delante las partes.

Sobre cada extremo de una asociación se escribe la multiplicidad, con la notación de intervalo: 1, 0..1, 0..*, 1..* o un número exacto. ⚠️ Y con ella viene la trampa de la que se avisa siempre al pasar del modelo entidad/relación a UML: la multiplicidad se coloca en el extremo contrario a donde la notación clásica de Chen pone la cardinalidad, así que el mismo dibujo significa cosas distintas según la notación.

10.5. Casos de uso

El diagrama de casos de uso describe el sistema desde fuera: qué puede hacer con él cada tipo de usuario. Sus elementos son tres:

• El actor, dibujado como un monigote: un rol externo que interactúa con el sistema. Puede ser una persona o otro sistema, y eso se pregunta: el actor no es necesariamente humano.
• El caso de uso, una elipse con el nombre de la funcionalidad, expresada como una acción completa con valor para el actor.
• La frontera del sistema, el rectángulo que separa lo que es el sistema de lo que no.

Entre casos de uso hay dos relaciones que se confunden y que conviene fijar: include señala un comportamiento que siempre se ejecuta como parte del caso base y se extrae para no repetirlo, y extend señala uno opcional que solo ocurre en ciertas condiciones. La forma corta: incluir es obligatorio, extender es opcional.

10.6. Secuencia y comunicación

🚨 El diagrama de secuencia es, con diferencia, el más preguntado de UML: ha caído tres veces, y siempre con la misma definición. «En UML, ¿qué tipo de diagrama se utiliza para representar la interacción entre objetos o participantes mediante los mensajes que se intercambian entre ellos?» → diagrama de secuencia. Los distractores fueron el de clases, el de despliegue, el de componentes, el de paquetes, el de objetos y hasta el de entidad/relación, que ni siquiera es UML.

Cómo se dibuja: los participantes se colocan en la parte superior, de cada uno baja una línea de vida vertical, y los mensajes se dibujan como flechas horizontales entre ellas. El tiempo transcurre hacia abajo, y esa es la clave: la secuencia se lee de arriba abajo. Los rectángulos estrechos sobre la línea de vida son las activaciones, es decir, los periodos en que ese objeto está ejecutando algo.

Su hermano es el diagrama de comunicación —antes llamado de colaboración—, que muestra exactamente la misma información con otra disposición: los objetos se colocan libremente, unidos por enlaces, y los mensajes van numerados para indicar el orden. La diferencia: uno destaca cuándo ocurre cada cosa y el otro, quién habla con quién. Son intercambiables, y por eso a los dos se los llama diagramas de interacción.

🚨 Del uso práctico salió otra pregunta, en dos modelos de 2024: un proceso que implica «la autenticación del usuario, la firma de la solicitud, el guardado en base de datos, la generación de un asiento registral y la generación de un justificante» se representa con un diagrama de secuencia. La pista es que hay varios participantes intercambiando mensajes en un orden: no es una estructura, es un flujo de conversación.

10.7. Los demás diagramas

Diagrama	Qué muestra
De componentes	🚨 Cómo se divide el sistema en componentes y las dependencias entre ellos. Cayó con esa definición literal, y su distractor era el de clases, que describe estructura pero a nivel de clase y no de componente desplegable.
De despliegue	Los nodos físicos —servidores, dispositivos— y qué artefactos se ejecutan en cada uno. Es el diagrama de la infraestructura.
De objetos	Una foto del sistema en un instante: instancias concretas con sus valores, en lugar de clases.
De paquetes	La organización del modelo en paquetes y sus dependencias.
De actividad	El flujo de trabajo paso a paso, con decisiones, bifurcaciones y ejecución en paralelo. Es el más parecido a un diagrama de flujo clásico, y el que se usa para modelar un procedimiento administrativo.
De máquina de estados	Los estados por los que pasa un objeto y las transiciones entre ellos. El ejemplo de manual es el ciclo de vida de un expediente.
De estructura compuesta, de tiempos, de visión general, de perfiles	Los cuatro menos usados: el interior de una clase compleja, la evolución temporal precisa, la combinación de interacciones y la extensión del propio UML.

La forma rápida de no fallar una pregunta de «qué diagrama usarías»: si el enunciado habla de estructura, es estructural; si habla de orden, de flujo o de estados, es de comportamiento. Y dentro de los de comportamiento, si hay mensajes entre participantes es de secuencia; si hay pasos y decisiones, de actividad; si hay estados de una cosa, de máquina de estados.

10.8. UML dentro de Métrica v3

La metodología de la Administración admite las dos vías —el modelado estructurado clásico y la orientación a objetos— y para la segunda usa UML. 🚨 De ahí salió una pregunta con su vocabulario propio: «según Métrica v3, ¿cuál es el diagrama que describe en detalle un determinado escenario de un caso de uso?» → el diagrama de interacción. La palabra clave es escenario: el caso de uso describe la funcionalidad en general y el diagrama de interacción baja al detalle de un recorrido concreto, con sus objetos y sus mensajes.

Conviene retener también dónde encaja cada cosa dentro de los procesos de la metodología: el modelo de clases se elabora en el análisis del sistema de información, junto al de casos de uso y los de interacción; y el diseño de clases, con sus detalles de implementación, en el proceso de diseño.

11. Objetos y bases de datos

El paradigma choca con el almacenamiento relacional, y de ese choque salen tres conceptos que el tribunal ha preguntado.

El primero es el desajuste de impedancia objeto-relacional: los lenguajes manejan objetos con identidad, herencia y métodos, mientras que el modelo relacional solo entiende tablas de valores atómicos. Traducir de uno a otro cuesta y pierde semántica, y por eso existen las bases de datos orientadas a objetos, los gestores objeto-relacionales y, sobre todo, los mapeadores objeto-relacionales.

El segundo es el identificador de objeto. 🚨 El tribunal preguntó por él en dos modelos de 2026, y la respuesta correcta es que está generado por el sistema. Sus tres propiedades van juntas: es único, es inmutable y lo genera el gestor, con independencia de los valores del objeto. Ahí está la diferencia capital con la clave primaria relacional, que es un valor del propio registro, la elige el diseñador y puede cambiar.

El tercero son los constructores de tipo de colección, que son las formas en que una base de datos de objetos agrupa varios elementos. 🚨 La pregunta, también de 2026, pedía cuál NO lo es, y la respuesta era «columna», que pertenece al vocabulario relacional y no al de objetos. Los que sí lo son se cuentan con los dedos: conjunto —sin repetidos y sin orden—, bolsa —admite repetidos—, lista —ordenada— y matriz —de tamaño fijo y acceso por índice—.

11.1. Cómo se guarda una jerarquía en tablas

Si la aplicación es orientada a objetos y la base de datos es relacional, en algún momento hay que decidir cómo se guarda una jerarquía de clases, y solo hay tres respuestas posibles. Son las mismas tres que ofrece el paso del modelo entidad/relación al relacional, vistas ahora desde el lado del código:

Estrategia	Cómo se guarda	Precio
Una tabla por jerarquía	Una sola tabla con las columnas de todas las clases y una columna discriminadora que dice de qué clase es cada fila.	Muchas columnas vacías, y la mayoría no pueden declararse obligatorias.
Una tabla por clase concreta	Una tabla por cada subtipo, repitiendo en todas las columnas comunes.	Consultar «todos los documentos» obliga a unir varias tablas.
Una tabla por clase	Una tabla para la superclase y una por subclase, enlazadas por la clave.	Cada lectura de un objeto concreto exige una reunión.

Ninguna es la buena en abstracto: la primera es la más rápida y la menos limpia, la tercera la más normalizada y la más lenta. Los mapeadores objeto-relacionales las implementan las tres y dejan elegir con una anotación, que es justo lo que convierte la decisión en explícita en lugar de accidental.

11.2. La persistencia, en tres piezas

Guardar objetos exige resolver tres cosas, y conviene tenerlas nombradas porque aparecen en los enunciados:

• La identidad: qué distingue a un objeto de otro cuando los dos vuelven de la base de datos. En el mundo relacional lo resuelve la clave primaria; en el de objetos, el identificador que genera el sistema.
• La carga: cuándo se traen los objetos relacionados. Traerlos todos de golpe es cómodo y puede arrastrar media base de datos; traerlos cuando se pidan es lo habitual, y es la razón de que una consulta que parecía barata dispare cien consultas más sin que nadie lo vea.
• La transaccionalidad: un cambio en un objeto puede tocar varias tablas, y las dos escrituras tienen que ir en la misma unidad de trabajo o ninguna.

Sobre esas tres piezas se construyen las especificaciones y los productos que el tribunal ha nombrado —la de persistencia de la plataforma Java con su lenguaje de consulta orientado a objetos, y los mapeadores del mundo .NET y de los lenguajes dinámicos—, y por eso quien entienda las tres reconoce cualquiera de ellos aunque nunca lo haya usado.

11.3. Un diagrama de clases leído de un vistazo

Cierra el tema el ejercicio que el tribunal plantea en los supuestos: le ponen delante un diagrama y le preguntan qué dice. El método es siempre el mismo y son cuatro pasos.

Primero, las cajas. Cada rectángulo es una clase; si el nombre va en cursiva, es abstracta. En el segundo compartimento están los atributos y en el tercero los métodos, y delante de cada uno el símbolo de visibilidad: el guion es privado y es el que más se pregunta.

Segundo, los triángulos. Todo triángulo hueco apuntando hacia arriba es una herencia, y ahí se lee la relación «es un». Si la línea es continua, la clase de abajo hereda de una clase; si es discontinua, implementa una interfaz. Esa diferencia de trazo es la que separa la generalización de la realización.

Tercero, los rombos. Cualquier rombo indica una relación «tiene un», y lo único que hay que mirar es si está relleno. Hueco: la parte sobrevive al todo. Relleno: la parte muere con el todo. Un pedido y sus líneas van con rombo relleno; un departamento y sus empleados, con rombo hueco.

Y cuarto, los números de los extremos. La multiplicidad se lee empezando por el extremo contrario al que se quiere describir, y esa es la única regla que hay que interiorizar porque es contraintuitiva: si en el extremo del departamento pone 1 y en el del empleado pone 0..*, se lee «un departamento tiene cero o muchos empleados, y cada empleado pertenece a un departamento». Quien haya venido del modelo entidad/relación tiene que hacer aquí el cambio de chip, porque allí la cardinalidad se coloca justo al revés.

Con esos cuatro pasos se contesta cualquier pregunta de lectura de diagrama sin haber visto nunca ese dominio, que es exactamente lo que el supuesto práctico pide: no conocer la aplicación, sino saber leer la notación.

12. Cuadros para memorizar

12.1. Las parejas que el tribunal intercambia

Pareja	Lo que las separa
Sobrecarga / Sobrescritura	La lista de parámetros: cambia en la sobrecarga, es la misma en la sobrescritura
Agregación / Composición	Si la parte vive sin el todo: sí, rombo hueco; no, rombo relleno
Clase abstracta / Interfaz	Código compartido y una sola, frente a contrato puro y varias
Factory Method / Abstract Factory	Objetos de un mismo tipo frente a objetos de una misma familia
Secuencia / Comunicación	La misma información: uno destaca el tiempo, el otro quién habla con quién
include / extend	Comportamiento obligatorio frente a opcional
Biblioteca / Marco	Tu código la llama, frente a que él llama a tu código

12.2. Los símbolos de UML

Símbolo	Significado
+ · − · # · ~	Público · privado · protegido · de paquete
Rombo hueco · rombo relleno	Agregación · composición
Triángulo hueco, línea continua · discontinua	Generalización (herencia) · realización (implementa interfaz)
Flecha discontinua	Dependencia
Nombre en cursiva · miembro subrayado	Clase abstracta · miembro estático
Monigote · elipse · rectángulo de frontera	Actor · caso de uso · límite del sistema

12.3. Las listas cerradas

Lista	Elementos
Pilares de la orientación a objetos	Abstracción, encapsulación, herencia y polimorfismo
Lo que describe a un objeto	Identidad, estado y comportamiento
Lo que hereda una subclase	Propiedades, comportamiento y relaciones
Familias de patrones GoF	Creacionales (5), estructurales (7) y de comportamiento (11): 23 en total
SOLID	Responsabilidad única, abierto/cerrado, sustitución de Liskov, segregación de interfaces, inversión de dependencias
Grupos de diagramas UML	Estructurales y de comportamiento; dentro de los segundos, los de interacción
Constructores de colección en bases de objetos	Conjunto, bolsa, lista y matriz (columna NO)
Propiedades del identificador de objeto	Único, inmutable y generado por el sistema

13. Lo que ya ha preguntado el tribunal

Lo preguntado	Veces	La respuesta
Método con la misma lista de parámetros que el de la superclase	2	Sobrescritura (overriding)
Varias funciones con el mismo nombre en el mismo ámbito, en C++	1	Funciones sobrecargadas
Qué implica una relación de generalización	2	La subclase hereda propiedades, comportamiento y relaciones, y puede añadir las suyas
Patrón de comportamiento que notifica cambios de estado	2	Observer
Factory Method frente a Abstract Factory	1	Mismo tipo frente a misma familia
Definición del patrón Decorator	1	Agregar funcionalidad a un objeto dinámicamente
Reutilizar una librería compilada heredada	1	Adaptador
El símbolo de resta en un diagrama de clases	1	Visibilidad privada
Diagrama de interacción entre objetos mediante mensajes	3	Diagrama de secuencia
Señale la INCORRECTA sobre UML	1	La falsa: que muestra únicamente el modelado estático
Diagrama que muestra la división en componentes y sus dependencias	1	Diagrama de componentes
Diagrama que detalla un escenario de un caso de uso, según Métrica	1	Diagrama de interacción
Sobre el identificador de objeto (OID)	2	Está generado por el sistema
Cuál NO es constructor de tipo de colección	2	Columna
Señale la INCORRECTA sobre los tipos abstractos de datos	4	La falsa invierte interfaz y clase en Java

Cómo estudiar este tema, en tres reglas. Primera: aprende las definiciones en la forma en que las escribe el tribunal, no con tus palabras. Las preguntas son de reconocimiento, y la opción correcta suele ser una frase de manual reproducida casi literalmente; la falsa, esa misma frase con una palabra cambiada —«únicamente», «rojos» por «negros», «tipo» por «familia»—. Segunda: estudia por parejas confundibles, que es como el tema está construido y como el tribunal lo pregunta; el cuadro 12.1 es el resumen de todo el tema. Y tercera: con los patrones, memoriza la familia antes que el nombre, porque el enunciado casi siempre dice si es creacional, estructural o de comportamiento, y esa sola palabra descarta dos opciones antes de empezar a pensar.

Recuerda la aritmética del ejercicio: cada error descuenta un tercio y los blancos no penalizan. En un tema de definiciones como este, descartar dos opciones es casi siempre posible —los distractores inventados cantan—, y con dos fuera merece la pena arriesgar.