Algo de UML básico

Este viernes en la oficina uno de mis compañeros y yo estábamos comentando uno de los tweets de una amiga, en el que decía que no entendía cual es la diferencia entre agregación y composición en UML. Después de algunos minutos hablando comprobamos que aunque supiésemos diferenciar entre los dos, nosotros tampoco podíamos dar una definición técnica correcta de ambos términos. Por esta razón voy a crear una entrada en la que tras documentarme trataré de dejar claro que es composición y que es agregación. Demostrando por otro lado que siempre es interesante volver a las bases de vez en cuando, tanto para refrescarlas como para verlas desde otro nuevo punto de vista.

Definición de libro.

Para empezar utilizaré las definiciones del libro de Tim Weilkiens y Bernd Oestereich, "UML 2 Certification Guide".

"An aggregation is an association expanded by the semantically noncommittal comment that the participating classes have no equal-ranking relationship; instead they represent a whole-parts hierarchy. An aggregation is used to describe how something whole is logically composed of its parts."

"A composition is a strict form of aggregation, where the existence of its parts depends on the whole. The whole is the owner of its parts. It describes how something whole is composed of individual parts."

Vamos, aunque se entiende lo que dicen, después de leer esto me quedo un poco confuso (más que nada porque todavía estoy pescando con lo de noncommital comment; nota mental, tengo que mejorar mi inglés), vamos a ver que dice Martin Fowler en su libro, "UML Distilled Third Edition".

Bueno pues, decir decir no dice mucho, pero los diagramas utilizados por el señor Fowler clarifican bastante.

Agregación

Composición

A ver, tras leer las definiciones y ver los diagramas de ambos libros tenemos una idea bastante concreta de que es cada termino. Utilizamos agregación cuando queremos hablar de una asociación entre clases en la que ambas tienen "vida propia", es decir que ambas forman parte del modelo de negocio por si mismas independientemente de la existencia de la otra. En cambio, utilizamos composición cuando queremos hablar de una clase que hace uso de otras más "pequeñas" para formar un solo concepto del modelo de negocio, es decir una serie de clases que no tienen sentido fuera de ese concepto más general y que no existirían en otro caso dentro del modelo de negocio.

Nota sobre UML.

Para acabar y aunque no está totalmente relacionado con la entrada, me gustaría citar una frase que leí en un "retweet" y que lamentablemente no me acuerdo de su autor, aunque estaría encantado que alguien me lo dijese.

"UML no es malo, lo malo es creer que es la magia para que luego un mono te haga el código"

Cito esta frase porque yo soy de esas personas que creen que UML es una buena herramienta de comunicación (directa, cara a cara a ser posible) pero ni remotamente permite definir de forma completa un sistema en un diseño real (al fin y al cabo en realidad el código fuente es el diseño, ¿o no?).

Bibliografía :-)