12. Agregación y composición conceptual: cuándo una parte pertenece a un todo

12.1 Introducción

En un modelo de dominio algunas relaciones expresan una idea de todo y parte. Por ejemplo, una Agenda contiene Franjas horarias, un Pedido contiene Ítems de pedido o una Factura contiene Detalles de factura. Estas relaciones requieren más análisis que una asociación común, porque pueden implicar pertenencia, dependencia de ciclo de vida y reglas de consistencia.

En UML existen notaciones para agregación y composición, pero en modelado de dominio lo más importante no es el símbolo, sino comprender qué significa la relación en el negocio. Debemos preguntar si una parte puede existir sin el todo, si puede cambiar de dueño, si se comparte entre varios todos y qué ocurre cuando el todo desaparece o se cancela.

12.2 Imagen conceptual de todo y parte

12.3 Relación todo-parte

Una relación todo-parte indica que un concepto está formado por otros conceptos. El todo organiza, agrupa o contiene a las partes. Sin embargo, no todas las relaciones de contención tienen el mismo significado. Algunas partes dependen fuertemente del todo; otras pueden existir por separado.

Por ejemplo, un Ítem de pedido suele tener sentido dentro de un Pedido. En cambio, un Producto puede aparecer dentro de muchos pedidos, pero no pertenece exclusivamente a uno. Por eso, Ítem de pedido puede ser parte del Pedido, mientras que Producto se asocia con el ítem sin ser parte exclusiva del pedido.

12.4 Composición conceptual

La composición conceptual representa una relación todo-parte fuerte. La parte tiene sentido dentro del todo y su ciclo de vida suele depender de él. Si el todo deja de existir, la parte normalmente también deja de tener sentido como elemento independiente.

Por ejemplo, un Ítem de pedido pertenece a un Pedido. No tendría sentido conservar un ítem suelto sin pedido asociado. También un Detalle de factura puede depender de la Factura a la que pertenece. En estos casos, la parte suele ser creada, modificada y eliminada bajo las reglas del todo.

12.5 Agregación conceptual

La agregación conceptual representa una relación todo-parte más débil. El todo agrupa o utiliza partes, pero esas partes pueden existir independientemente o incluso compartirse con otros todos.

Por ejemplo, una Especialidad puede agrupar Profesionales o un Catálogo puede agrupar Productos. Los productos no desaparecen necesariamente si se elimina un catálogo. Un Profesional tampoco deja de existir porque se modifique una lista de especialidades.

En muchos modelos conceptuales no hace falta usar el símbolo formal de agregación. Puede alcanzar con una asociación bien nombrada y reglas claras.

12.6 Dependencia de ciclo de vida

Una de las preguntas más importantes es si la parte depende del ciclo de vida del todo. Si la parte nace, cambia y desaparece junto con el todo, estamos cerca de una composición. Si la parte puede existir antes, después o fuera del todo, la relación es más débil.

Por ejemplo, una Franja horaria creada dentro de una Agenda puede depender de esa agenda si no tiene sentido fuera de ella. Pero si el dominio maneja franjas horarias como plantillas reutilizables, entonces podrían existir independientemente.

La respuesta depende del negocio, no de la preferencia del modelador.

12.7 Exclusividad de pertenencia

Otra pregunta importante es si una parte puede pertenecer a más de un todo. En una composición fuerte, la parte normalmente pertenece a un solo todo. Un Ítem de pedido no pertenece a dos pedidos distintos. Un Detalle de factura no pertenece a dos facturas.

En una agregación más débil, puede haber compartición. Un Producto puede aparecer en muchos pedidos. Una Especialidad puede estar asociada a muchos profesionales. Un Documento puede estar relacionado con varios trámites, según el dominio.

12.8 No confundir parte con referencia

Que un concepto esté relacionado con otro no significa que sea parte de él. Un Turno puede estar relacionado con un Paciente, pero el paciente no es parte del turno. Un Pedido puede referenciar un Cliente, pero el cliente no pertenece al pedido. Un Ítem de pedido puede referenciar un Producto, pero el producto no es parte exclusiva del pedido.

Esta diferencia evita modelos incorrectos. Si tratamos como parte algo que solo es una referencia, podemos derivar reglas equivocadas sobre eliminación, modificación o propiedad.

12.9 Ejemplo: Pedido e Ítem de pedido

En un sistema de ventas, Pedido e Ítem de pedido suelen formar una composición conceptual. El pedido contiene ítems, cada ítem pertenece a un pedido, y el ítem no tiene sentido como entidad independiente fuera del pedido.

Sin embargo, Producto no es parte del pedido en el mismo sentido. El ítem puede indicar qué producto se solicitó, pero el producto existe en el catálogo antes y después del pedido. Esta diferencia es clave para no confundir composición con asociación común.

12.10 Ejemplo: Agenda y Franja horaria

En un sistema de turnos, una Agenda puede contener Franjas horarias. Si cada franja se crea específicamente para una agenda concreta y no tiene sentido fuera de ella, podemos pensar en una composición conceptual. La agenda organiza y controla sus franjas.

Pero si el dominio usa plantillas de horarios compartidas por varias agendas, esas plantillas no serían partes exclusivas de una agenda. Podrían modelarse como conceptos independientes asociados a varias agendas.

12.11 Reglas de consistencia

Las relaciones todo-parte suelen tener reglas de consistencia. Por ejemplo, un Pedido no puede confirmarse si no tiene ítems. Una Factura debe tener al menos un detalle. Una Agenda publicada debe contener franjas horarias válidas y no superpuestas.

Estas reglas normalmente pertenecen al todo, porque el todo debe asegurar que sus partes formen una estructura válida. En análisis de dominio, conviene identificar esas reglas aunque todavía no decidamos cómo implementarlas.

12.12 Todo-parte y multiplicidad

Las relaciones todo-parte también tienen multiplicidad. Un Pedido puede tener 1..* Ítems de pedido. Una Factura puede tener 1..* Detalles. Una Agenda puede tener 0..* Franjas si está en preparación, pero 1..* si está publicada.

Cuando combinamos composición con multiplicidad, el modelo se vuelve más preciso: no solo sabemos que hay pertenencia, sino cuántas partes son necesarias o permitidas.

12.13 Tabla comparativa

La siguiente tabla resume diferencias conceptuales:

12.14 Preguntas para decidir

Estas preguntas ayudan a analizar una relación todo-parte:

• ¿La parte puede existir sin el todo?
• ¿La parte pertenece exclusivamente a un solo todo?
• ¿La parte se crea y elimina junto con el todo?
• ¿La parte puede moverse de un todo a otro?
• ¿La parte puede compartirse entre varios todos?
• ¿El todo debe garantizar reglas sobre sus partes?
• ¿La relación representa pertenencia real o solo una referencia?

12.15 Errores frecuentes

Al modelar agregación y composición, suelen aparecer estos errores:

• Usar composición solo porque un concepto aparece visualmente dentro de otro.
• Confundir referencia con pertenencia.
• Tratar como parte exclusiva algo que puede compartirse.
• No analizar si la parte tiene ciclo de vida propio.
• Usar símbolos UML sin poder explicar su significado en el negocio.
• Ignorar reglas de consistencia entre todo y partes.
• No validar con expertos qué ocurre cuando el todo cambia, se cancela o desaparece.

12.16 Qué debes recordar de este tema

• Las relaciones todo-parte requieren analizar pertenencia, dependencia y ciclo de vida.
• La composición conceptual representa una relación fuerte entre todo y parte.
• La agregación conceptual representa una relación más débil o de agrupación.
• No toda asociación es una relación todo-parte.
• Una parte en composición normalmente no se comparte entre varios todos.
• El todo suele proteger reglas de consistencia sobre sus partes.
• La decisión debe basarse en el significado del negocio, no solo en símbolos UML.

12.17 Conclusión

Agregación y composición ayudan a expresar relaciones todo-parte, pero deben usarse con criterio. Lo esencial es comprender si una parte depende del todo, si puede compartirse, si tiene ciclo de vida propio y qué reglas de consistencia existen. El símbolo visual solo tiene valor cuando refleja una decisión conceptual clara.

En el próximo tema estudiaremos generalización y especialización, prestando atención a cuándo las jerarquías son útiles y cuándo agregan complejidad innecesaria.