Diagramas de clases: crea diagramas es­tru­c­tu­ra­les con UML

Los diagramas de clases son diagramas es­tru­c­tu­ra­les del lenguaje unificado de modelado o UML (unified modeling language). Este lenguaje de modelado visual es un estándar ISO para vi­sua­li­zar los sistemas de la pro­gra­ma­ción orientada a objetos, aunque también permite vi­sua­li­zar procesos de negocio. Con ayuda de elementos gráficos, UML muestra los estados de los sistemas y describe las in­ter­ac­cio­nes entre los elementos que lo componen. Para poder hacerlo, la notación UML define las formas y las líneas para 14 tipos de diagrama.

Este lenguaje de me­ta­mo­de­la­do describe tanto a los elementos del lenguaje como al lenguaje mismo, de­fi­nie­n­do unidades li­n­güí­s­ti­cas para di­fe­re­n­tes niveles. Una de estas unidades en este lenguaje visual es, por ejemplo, el co­m­po­r­ta­mie­n­to, que describe al mismo tiempo a una metaclase y a una de­no­mi­na­ción genérica para todos los factores dinámicos dentro de un sistema. Otra de estas unidades es el objeto, el elemento fu­n­da­me­n­tal de la pro­gra­ma­ción orientada a objetos. Los diagramas de clases UML modelan los objetos como in­s­ta­n­cias de clases. Esto convierte a los diagramas de clases en uno de los diagramas UML más uti­li­za­dos y de mayor im­po­r­ta­n­cia.

Según su función, los diagramas se dividen en dos grandes ca­te­go­rías: los de co­m­po­r­ta­mie­n­to (dinámicos) y los es­tru­c­tu­ra­les (estáticos). Los diagramas de co­m­po­r­ta­mie­n­to vi­sua­li­zan procesos dinámicos. El diagrama de ac­ti­vi­da­des, por ejemplo, muestra grá­fi­ca­me­n­te cómo in­ter­ac­túan las diversas acciones co­n­te­ni­das en un proceso. Por el contrario, los diagramas es­tru­c­tu­ra­les muestran estados estáticos, ilustran los elementos que integran un sistema y qué de­pe­n­de­n­cias tienen entre sí.

Entre los diagramas de co­m­po­r­ta­mie­n­to, los diagramas de in­ter­ac­ción no se limitan a modelar el co­m­po­r­ta­mie­n­to general de un sistema, sino que centran su atención en los flujos de in­fo­r­ma­ción entre los objetos durante la ejecución de un proceso. Aquí se incluyen, por ejemplo, los diagramas de secuencia, que modelan la secuencia cro­no­ló­gi­ca de los mensajes que in­te­r­ca­m­bian los objetos en un caso de uso.

El más utilizado entre los es­tru­c­tu­ra­les o estáticos, el diagrama de clases asigna clases a las in­s­ta­n­cias de objeto en función de sus pro­pie­da­des, lo que implica una cierta de­pe­n­de­n­cia je­rá­r­qui­ca. Al mismo tiempo existen re­la­cio­nes entre las di­fe­re­n­tes clases o entre objetos.

Los diagramas de clases utilizan elementos de sistemas para re­pre­se­n­tar estados grá­fi­ca­me­n­te y, al desglosar las es­tru­c­tu­ras hasta la instancia más pequeña, son idóneos para vi­sua­li­zar ar­qui­te­c­tu­ras de software de­ta­lla­das de las que pueden derivarse pasos concretos de pro­gra­ma­ción. Algunos entornos de pro­gra­ma­ción asistidos por software co­n­vie­r­ten los diagramas UML en marcos de código. Gracias a apli­ca­cio­nes de team sharing, los de­sa­rro­lla­do­res pueden co­mu­ni­car­se entre sí dentro de la misma empresa o con otros re­s­po­n­sa­bles. Para los profanos, un diagrama UML pro­po­r­cio­na una vista general de las es­tru­c­tu­ras y los procesos que se han pla­ni­fi­ca­do. También pueden fo­r­mu­lar­se re­qui­si­tos de sistema para que los im­ple­me­n­ten los de­sa­rro­lla­do­res. Los expertos de TI pueden modelar y modificar los diagramas sin tener que programar entornos o procesos complejos ya en la fase de pla­ni­fi­ca­ción.

¿Cuáles son las áreas de apli­ca­ción de los diagramas de clases?

• Describen tipos dentro de un sistema. El aspecto visual no está vinculado a la apli­ca­ción que vaya a uti­li­zar­se en el futuro, sino que puede im­ple­me­n­tar­se con di­fe­re­n­tes lenguajes de pro­gra­ma­ción y entornos.
• Modelan ar­qui­te­c­tu­ras de software que ya existen. Si se han de montar más co­m­po­ne­n­tes, los diagramas muestran las es­tru­c­tu­ras donde podrían in­te­grar­se. Para los elementos de sistema futuros, los diagramas de clases crean una guía para el código de programa, que puede ser más o menos detallada según se requiera.
• Re­pre­se­n­tan vi­sua­l­me­n­te modelos de datos. Son adecuados para sistemas de diferente co­m­ple­ji­dad.
• En apli­ca­cio­nes con muchas ani­da­cio­nes, la do­cu­me­n­ta­ción y el ma­n­te­ni­mie­n­to pueden ser muy complejos. Los diagramas de clases muestran una vista general del esquema.
• Re­pre­se­n­tan los re­qui­si­tos de un software. Pueden enviarse como archivo de imagen en canales internos, pe­r­mi­tie­n­do a los expertos de de­pa­r­ta­me­n­tos di­fe­re­n­tes comentar e in­te­r­ca­m­biar opiniones sobre la ar­qui­te­c­tu­ra.
• El estándar UML utiliza diagramas de clases para re­pre­se­n­tar vi­sua­l­me­n­te su propia notación.

En los diagramas de clases, la clase es un elemento-modelo y una es­pe­cia­li­za­ción del cla­si­fi­ca­dor en­ca­p­su­la­do (En­ca­p­su­la­te­d­Cla­s­si­fier) y del cla­si­fi­ca­dor de co­m­po­r­ta­mie­n­to (Beha­vio­re­d­Cla­s­si­fier). Comprende un conjunto de in­s­ta­n­cias. Las in­s­ta­n­cias-objeto dentro de una clase comparten las mismas pro­pie­da­des (At­tri­bu­tes) y co­m­po­r­ta­mie­n­tos (Methods), así como la misma semántica, es decir, utilizan los mismos ca­ra­c­te­res con el mismo si­g­ni­fi­ca­do. Esto convierte a la clase en una especie de plantilla para sus objetos, “in­s­ta­n­cia­n­do” los objetos y de­fi­nie­n­do su conducta en el sistema.

Cuando se crea un diagrama de clases, estas pro­pie­da­des se añaden a la notación. En UML, las clases se re­pre­se­n­tan como un re­c­tá­n­gu­lo dibujado con línea continua y compuesto por tres filas ho­ri­zo­n­ta­les. Solo es obli­ga­to­rio modelar la superior porque aquí se define el nombre de la clase. Las otras dos, una que contiene a los atributos (in­te­r­me­dio) y una que expresa las ope­ra­cio­nes o los métodos que puede utilizar la clase (inferior) son op­cio­na­les. Añadiendo a los nombres de estos miembros (atributos y métodos) uno de los símbolos que se detallan a co­n­ti­nua­ción (mo­di­fi­ca­do­res de acceso a miembros), se es­pe­ci­fi­ca su vi­si­bi­li­dad:

• + = pública
• - = privada
• # = protegida
• / = derivada (
• ~ = paquete
• * = aleatoria

Las pro­pie­da­des son elementos in­te­r­de­pe­n­die­n­tes. Los atributos propios de la clase (ow­ne­dA­t­tri­bu­tes) son siempre roles y se conectan por medio de co­ne­c­to­res. Si poseen la propiedad is­Co­m­po­si­te= true (“está compuesto = verdad”), reciben el nombre de partes (Parts).

La propiedad UML es una ca­ra­c­te­rí­s­ti­ca de las es­tru­c­tu­ras que puede tener apli­ca­cio­nes di­fe­re­n­tes. Además de la función de atributo en una clase, también puede re­pre­se­n­tar los extremos en las re­la­cio­nes de aso­cia­ción.

El tipo de propiedad se deriva del nombre del cla­si­fi­ca­dor, pero también se puede es­pe­ci­fi­car un valor estándar para una propiedad, y los mo­di­fi­ca­do­res pueden concretar cómo se comporta:

• Ordenado (notación: isOrdered = true)
• Único (isUnique = true)
• No único (isUnique = false)
• Protegido contra escritura (la propiedad solo puede leerse: is­Rea­dO­n­ly = true)
• Secuencia (la propiedad es una colección ordenada: isUnique = false e isOrdered = true)
• Aso­cia­ción (derivada de su­b­co­n­ju­n­tos: union)
• ID (pertenece a la de­no­mi­na­ción de su cla­si­fi­ca­dor, id)
• Li­mi­ta­ción de propiedad (una li­mi­ta­ción que influye en la propiedad: property-co­n­s­trai­nt)
• Re­de­fi­ni­ción de una propiedad (redefine a una propiedad heredada: redefines [Me­r­k­ma­l­s­na­me])
• Su­b­co­n­ju­n­to de la propiedad (simboliza a una propiedad que es un su­b­co­n­ju­n­to de una propiedad: subsets [Me­r­k­ma­l­s­na­me])

Las ope­ra­cio­nes son funciones de co­m­po­r­ta­mie­n­to y se utilizan en clases, en tipos de datos o en in­te­r­fa­ces. Las ope­ra­cio­nes invocan la instancia de una clase y es­pe­ci­fi­can estos aspectos de una llamada:

• Nombre
• Tipo
• Parámetro
• Li­mi­ta­cio­nes

La operación pertenece al cla­si­fi­ca­dor al cual se subordina, que podría mo­di­fi­car­la re­de­fi­nie­n­do el tipo o el parámetro.

Antes de que una operación se ejecute, se ha de cumplir una serie de co­n­di­cio­nes previas, pero UML no define cómo se comporta la llamada de co­m­po­r­ta­mie­n­to si no se cumplen las co­n­di­cio­nes previas. Se han de es­pe­ci­fi­car también las co­n­di­cio­nes po­s­te­rio­res que se han de cumplir si la operación finaliza. Las co­n­di­cio­nes de campo re­s­tri­n­gen el valor devuelto a un valor que se calcula a partir de sus es­pe­ci­fi­ca­cio­nes y que ha de cumplir con las co­n­di­cio­nes po­s­te­rio­res. Pero mientras se ejecuta, la operación también puede invocar una excepción. Si esto sucede, pro­ba­ble­me­n­te no pueda cumplir con las co­n­di­cio­nes po­s­te­rio­res.

La notación para diagramas de clases prescribe que las ope­ra­cio­nes se escriban en el cuerpo de la clase. Si bien son datos obli­ga­to­rios según el estándar UML, puede pre­s­ci­n­di­r­se de ellos. Solo el nombre es im­pe­ra­ti­vo.

El receptor muestra que un cla­si­fi­ca­dor está preparado para recibir una señal y define qué tipos de señal aceptan las in­s­ta­n­cias de la clase. El receptor recibe el mismo nombre que su señal. Los datos co­rre­s­po­n­die­n­tes se anotan en el cuerpo de la clase en una fila bajo las ope­ra­cio­nes.

Los puertos son co­ne­c­to­res para cla­si­fi­ca­do­res en­ca­p­su­la­dos. Re­pre­se­n­tan el punto en el que los cla­si­fi­ca­do­res in­ter­ac­túan con su entorno. Ex­ce­p­tua­n­do los puertos, los cla­si­fi­ca­do­res en­ca­p­su­la­dos son un sistema cerrado en sí mismo. El hecho de que tanto su es­tru­c­tu­ra como sus elementos de co­m­po­r­ta­mie­n­to estén aislados del sistema restante permite que puedan es­pe­ci­fi­car­se li­bre­me­n­te. Siempre y cuando un sistema cumpla las re­s­tri­c­cio­nes del puerto, el cla­si­fi­ca­dor en­ca­p­su­la­do puede uti­li­zar­se en entornos di­fe­re­n­tes.

UML permite a los cla­si­fi­ca­do­res tener varios puertos. Para cada uno de ellos pueden definirse reglas es­pe­cí­fi­cas. El puerto es una propiedad del cla­si­fi­ca­dor, por lo que las reglas se definen en el campo de las pro­pie­da­des. Entre estas se incluyen los servicios que ofrece el cla­si­fi­ca­dor a su entorno y los que necesita. Para di­fe­re­n­ciar flujos de in­fo­r­ma­ción di­fe­re­n­tes se ha de ide­n­ti­fi­car a los puertos que se han utilizado para ellos.

Los mismos puertos también tienen pro­pie­da­des. Si un puerto ejecuta funciones públicas del cla­si­fi­ca­dor, se indica con la propiedad isService. Si isService = true, el puerto se considera un co­m­po­ne­n­te im­pre­s­ci­n­di­ble de las funciones visibles hacia fuera del cla­si­fi­ca­dor. Si isService = false, el puerto no forma parte de las funciones pri­n­ci­pa­les y, al igual que cualquier otra función interna, puede mo­di­fi­car­se o eli­mi­nar­se.

Los puertos también in­ter­ac­túan con in­te­r­fa­ces, que pueden ser ne­ce­sa­rias o puestas a di­s­po­si­ción (ver apartado In­te­r­fa­ces). La interfaz conectada al puerto es­pe­ci­fi­ca las in­ter­ac­cio­nes que tienen lugar a través del puerto. Como el conector es una propiedad, tiene un tipo. El valor de is­Co­n­ju­ga­ted media entre los tipos y la interfaz del puerto. Si el valor es verdadero, la interfaz requerida puede derivarse del tipo de puerto o del conjunto de in­te­r­fa­ces que realiza el tipo del puerto. La interfaz pro­po­r­cio­na­da se deriva del conjunto de las in­te­r­fa­ces. Si is­Co­n­ju­ga­ted es verdadero, esta interfaz de deriva del tipo.

Si un cla­si­fi­ca­dor en­ca­p­su­la­do genera una instancia, también se crean las in­s­ta­n­cias co­rre­s­po­n­die­n­tes para cada uno de sus puertos. Un puerto mantiene a cada instancia en co­n­co­r­da­n­cia con su tipo y su mu­l­ti­pli­ci­dad (ver más adelante). UML denomina a las in­s­ta­n­cias puntos de in­ter­ac­ción. Cada instancia posee re­fe­re­n­cias únicas que le sirven para di­fe­re­n­ciar las distintas so­li­ci­tu­des para funciones de co­m­po­r­ta­mie­n­to que se dirigen a sus puertos.

Los puertos con la cualidad is­Beha­vior = true envían una petición a la instancia del cla­si­fi­ca­dor. Esta petición asume el co­m­po­r­ta­mie­n­to es­pe­ci­fi­ca­do de la instancia, y es que estos puertos llamados de co­m­po­r­ta­mie­n­to no envían las pe­ti­cio­nes al interior del cla­si­fi­ca­dor. Si en el diagrama de clases no se ha definido ningún co­m­po­r­ta­mie­n­to, los mensajes dirigidos a estos puertos se pierden.

Los puertos se modelan como un pequeño cuadrado en el marco del cla­si­fi­ca­dor al cual pertenece. En el puerto se dibujan las in­te­r­fa­ces ne­ce­sa­rias o puestas a di­s­po­si­ción. Si no es­pe­ci­fi­cas ninguna propiedad especial para el puerto, la interfaz se dibuja sin puerto.

Los co­ne­c­to­res definen co­ne­xio­nes entre dos o más in­s­ta­n­cias. La es­pe­ci­fi­ca­ción permite que se co­mu­ni­quen. Al contrario que las re­la­cio­nes, como la aso­cia­ción, los co­ne­c­to­res no unen cualquier tipo de instancia, sino solo aquellas definidas como elementos de conexión. Los co­ne­c­to­res se modelan como líneas con al menos dos finales que co­rre­s­po­n­den a las in­s­ta­n­cias pa­r­ti­ci­pa­n­tes que asignan un tipo a los elementos su­s­ce­p­ti­bles de co­ne­c­tar­se.

Este parámetro prescribe cuántas in­s­ta­n­cias puede formar una clase es­tru­c­tu­ra­da y restringe los atributos y las ope­ra­cio­nes. Es una parte de la es­tru­c­tu­ra interna, un elemento prescrito en el cuerpo de la clase, y se escribe detrás de los atributos y las ope­ra­cio­nes. En este campo también se incluye la topología. Para unir los nodos (in­s­ta­n­cias objeto) se utilizan rutas de co­mu­ni­ca­ción (Co­m­mu­ni­ca­tio­n­Pa­ths) a redes de topología.

Las mu­l­ti­pli­ci­da­des se escriben así:

<mu­l­ti­pli­ci­dad> : <re­s­tri­c­ción de mu­l­ti­pli­ci­dad> [<De­no­mi­na­ción de orden> , <De­no­mi­na­ción de unicidad>]

Mediante la re­s­tri­c­ción de mu­l­ti­pli­ci­dad se designa un valor fijo o un rango:

• 0 = La clase no de­sa­rro­lla in­s­ta­n­cias (poco frecuente)
• 0..1 = Una o ninguna instancia
• 1 o 1..1 = Solo una instancia
• 0..* o * = Ninguna instancia o varias con un valor máximo in­de­fi­ni­do
• 1..* = Una instancia o más con valor máximo in­de­fi­ni­do

El or­de­na­mie­n­to o el carácter de unicidad puede ex­pre­sar­se como conjunto (set) o con términos separados por coma. En función de si los nodos en el conjunto son únicos o están ordenados, el conjunto obtiene una de­s­cri­p­ción de tipo. En la notación, los conjuntos se describen como ordered/unordered (ordenado / no ordenado) o unique/not unique (único / no único).

Algunos elementos re­s­tri­n­gi­dos se escriben en UML como texto, como un atributo de una clase. La re­s­tri­c­ción se escribe entre corchetes detrás del elemento de texto. Si el pro­pie­ta­rio es un elemento re­pre­se­n­ta­do por un símbolo, la re­s­tri­c­ción se coloca lo más cerca posible de este, de modo que quede claro que ambos elementos están re­la­cio­na­dos se­má­n­ti­ca­me­n­te. Aunque si quieres que la conexión quede aún más clara, escribe la re­s­tri­c­ción en un símbolo de nota adhesiva y conéctala a su pro­pie­ta­rio con una línea di­s­co­n­ti­nua.

Si la re­s­tri­c­ción afecta a dos elementos, se enlaza a los dos pro­pie­ta­rios con una línea di­s­co­n­ti­nua y se escribe en ella la re­s­tri­c­ción entre corchetes. Si se dibuja una punta de flecha en un extremo, se señaliza la posición del pro­pie­ta­rio dentro de un conjunto de elementos re­s­tri­n­gi­dos (co­n­s­trai­ne­dE­le­me­nts). La flecha señaliza un mo­vi­mie­n­to que va de la primera posición a la segunda. Si más de dos elementos poseen la re­s­tri­c­ción, debes utilizar el símbolo de la nota adhesiva y conectar a cada elemento con la re­s­tri­c­ción.

Las líneas co­ne­c­to­ras también se incluyen dentro de los elementos que se re­s­tri­n­gen. Si modelas más de dos líneas del mismo tipo, arrastra la línea di­s­co­n­ti­nua a través de todas las líneas que re­pre­se­n­tan a todos los elementos im­pli­ca­dos.

Los es­te­reo­ti­pos definen a ex­te­n­sio­nes de las me­ta­cla­ses. Siguiendo la es­pe­ci­fi­ca­ción UML, pe­r­te­ne­cen a los perfiles. Si un es­te­reo­ti­po describe pro­pie­da­des de varias me­ta­cla­ses, solo puede describir las in­s­ta­n­cias de una en una mientras se ejecuta. Entre las me­ta­cla­ses, el es­te­reo­ti­po siempre asume un papel de­te­r­mi­na­do porque nunca puede estar solo. Los es­te­reo­ti­pos se modelan siempre en relación con el cla­si­fi­ca­dor al que amplía. La metaclase se conecta con el es­te­reo­ti­po modelando una extensión (Extension).

UML define algunos es­te­reo­ti­pos de clase que amplían un diagrama de clases. Seis son co­n­si­de­ra­dos estándar, pero hay tres que, sin ser estándar, se usan mucho, y con los que puede im­ple­me­n­tar­se el modelo “Model-View-Co­n­tro­ller” (MVC) en UML. Son estos:

• Entidad (<>): el es­te­reo­ti­po Entity define a una clase o a un objeto. Cada instancia re­pre­se­n­ta a una colección de datos, a menudo datos de sistema que se han de guardar durante mucho tiempo. La entidad asume el rol del modelo del patrón MVC. UML conoce este es­te­reo­ti­po, pero lo asigna por defecto a los diagramas de co­m­po­ne­n­tes. En la es­pe­ci­fi­ca­ción no se re­pre­se­n­ta a esta habitual notación. La entidad se modela como un círculo que descansa sobre una línea corta.
• Frontera (<>): la Frontera es un es­te­reo­ti­po para una clase o un objeto. Se co­rre­s­po­n­de apro­xi­ma­da­me­n­te con el elemento View del modelo MVC. La Frontera modela los límites de tu sistema, p. ej., una interfaz de usuario. Suele re­pre­se­n­tar­se grá­fi­ca­me­n­te como un círculo de cuyo lado izquierdo sale una línea que acaba en una línea vertical.
• Control (<>): el elemento de Control re­pre­se­n­ta el Co­n­tro­ller en MVC. Las clases o los objetos con este es­te­reo­ti­po modelan elementos que de­te­r­mi­nan el co­m­po­r­ta­mie­n­to del sistema o los flujos de control. En el estándar UML el es­te­reo­ti­po <> asume tareas similares. La instancia de control se dibuja como un círculo con una flecha encima de la línea.

Los tres es­te­reo­ti­pos pueden dibujarse como clases. En los re­c­tá­n­gu­los se escribe el nombre del es­te­reo­ti­po. Los mo­de­la­do­res aplican estas formas pri­n­ci­pa­l­me­n­te en diagramas de secuencia. Lee nuestro artículo sobre diagramas de secuencia con UML si quieres pro­fu­n­di­zar en los diagramas de entidad-frontera-control.

Los es­te­reo­ti­pos es­ta­n­da­ri­za­dos para diagramas de clases son:

• Foco (<>)
• Auxiliar (<>)
• Tipo (<>)
• Clase de im­ple­me­n­ta­ción (<>)
• Metaclase (<>)
• Utilidad (<>)

La clase foco define la lógica de negocio fu­n­da­me­n­tal o el flujo de control de las clases au­xi­lia­res. Estas apoyan a la clase foco que conecta a uno o más au­xi­lia­res. Define a la clase a la que ayuda de forma implícita iniciando una relación de de­pe­n­de­n­cia (ver más adelante “La relación dirigida”). Si usa clases au­xi­lia­res, las define de forma explícita. El estándar UML re­co­mie­n­da este es­te­reo­ti­po para la fase de diseño en la que se re­pre­se­n­tan los flujos de control entre los co­m­po­ne­n­tes o se determina la lógica de negocio básica.

La clase auxiliar suele co­m­bi­nar­se con la clase foco y asiste por lo general a clases con una posición si­g­ni­fi­ca­ti­va para el sistema. Para ello ejecuta flujos de control en un segundo plano y define lógicas su­b­si­dia­rias. Si asiste a una clase foco, la de­fi­ni­ción es explícita; si hay una relación de de­pe­n­de­n­cia, define a la clase a la que asiste de forma implícita.

La clase tipo es­pe­ci­fi­ca una región para objetos de negocio y es­pe­ci­fi­ca los ope­ra­do­res de estos objetos. El es­te­reo­ti­po de tipo puede ostentar atributos y aso­cia­cio­nes, pero no describe la ejecución física del objeto.

Algunos lenguajes de pro­gra­ma­ción (Java o C++) solo permiten una instancia por clase, pero con UML una instancia puede asignarse a varias clases. La clase apli­ca­ción lanza un puente entre estos dos mundos. Este es­te­reo­ti­po restringe a la clase UML, de­te­r­mi­na­n­do que, bajo él, una instancia solo puede realizar a una clase. La clase apli­ca­ción puede im­ple­me­n­tar tipos di­fe­re­n­tes. Para ejecutar con éxito un cla­si­fi­ca­dor su­bo­r­di­na­do a ella ha de cumplir con dos co­n­di­cio­nes: ha de su­mi­ni­s­trar todas las ope­ra­cio­nes del cla­si­fi­ca­dor y estas han de mostrar el co­m­po­r­ta­mie­n­to que se definió para el cla­si­fi­ca­dor. Los atributos y aso­cia­cio­nes de carácter físico, sin embargo, no han de coincidir.

Como las formas de clase y metaclase no se di­fe­re­n­cian, la etiqueta Metaclass señala que se trata del es­te­reo­ti­po Metaclase. Las in­s­ta­n­cias de esta clase son clases también. Con este es­te­reo­ti­po se trabaja a un nivel superior de ab­s­tra­c­ción.

La clase utilidad no posee in­s­ta­n­cias. Solo etiqueta a una colección de atributos y ope­ra­cio­nes, que son siempre estáticos. Los atributos estáticos no cambian cuando se les llama. Las ope­ra­cio­nes estáticas se aplican en entidades o tipos entidad. Si utilizas la clase utilidad, has de indicar ya al principio los co­rre­s­po­n­die­n­tes valores y ope­ra­cio­nes porque ya no cambiarán. Para señalizar a estos elementos, se subrayan.

También están las in­te­r­fa­ces re­que­ri­das (Required In­te­r­fa­ces), que vi­sua­li­zan una relación de de­pe­n­de­n­cia (ver en “Re­la­cio­nes”). Aquí un elemento necesita a otro elemento para ejecutar todo el potencial de sus funciones propias. En este caso un cla­si­fi­ca­dor (o una de sus in­s­ta­n­cias) necesita una interfaz. La In­te­r­fa­ceU­sa­ge (uso de la interfaz) es­pe­ci­fi­ca qué exi­ge­n­cias se plantean a la interfaz. Para ello una línea une al cla­si­fi­ca­dor con un medio círculo que simboliza a la interfaz. El nombre de la interfaz se escribe en ambos re­pre­se­n­ta­n­tes debajo del círculo o el medio círculo.

Si una clase lega una interfaz a una clase inferior, se ha de modelar la conexión de la interfaz a la clase o instancia su­bo­r­di­na­da. La relación je­rá­r­qui­ca se muestra con el acento ci­r­cu­n­fle­jo (^), p. ej., ^interfaz 1.

Si empleas la notación cuadrada de las in­te­r­fa­ces, dibuja una línea entre los dos nodos. En los diagramas de clases, las líneas modelan las re­la­cio­nes entre clases, in­s­ta­n­cias o co­m­po­ne­n­tes. UML prescribe di­fe­re­n­tes líneas y flechas para funciones y re­la­cio­nes diversas. En este caso, para unir a una clase con la interfaz requerida se utiliza una flecha di­s­co­n­ti­nua con punta abierta. Añade la etiqueta <<use>> a la flecha. Para unir a una interfaz requerida con una clase se utiliza una flecha di­s­co­n­ti­nua con punta cerrada, sin rellenar. La flecha apunta siempre en dirección a la interfaz.

La enu­me­ra­ción es un tipo dato. Re­pre­se­n­tan el valor de la enu­me­ra­ción con un símbolo ti­po­grá­fi­co. Como en la imagen de arriba, se trata se­n­ci­lla­me­n­te de un nombre que re­pre­se­n­ta si­m­bó­li­ca­me­n­te a un valor de­te­r­mi­na­do. Este nombre lo elige el usuario. En la lista “clases de rosa” el nombre “rosa de té” re­pre­se­n­ta al número de rosas de té que tiene una flo­ri­s­te­ría. En el diagrama de clases se dibuja a este cla­si­fi­ca­dor con el símbolo para la clase, un cuadrado. En la parte superior se incluye la etiqueta <<enu­me­ra­tion>>. Esta parte se separa del cuerpo en de­pa­r­ta­me­n­tos con líneas ho­ri­zo­n­ta­les.

Como en otras clases, la enu­me­ra­ción reserva los campos su­pe­rio­res para atributos y ope­ra­cio­nes. Si quedan vacíos, estas secciones se eliminan. En la parte inferior escribe los símbolos para la enu­me­ra­ción. En el caso de una tienda de flores, la enu­me­ra­ción se llamaría “clases de rosas” y en el cuerpo se escribe la lista: rosas de té, rosas Noisette, rosas gallica, rosas Bourbon, rosa majalis.

Los diagramas de clases re­pre­se­n­tan re­la­cio­nes entre elementos de sistema con el fin de que el ob­se­r­va­dor vea qué co­m­po­ne­n­tes necesita el sistema y cómo influyen los unos en los otros. El elemento relación es una clase abstracta y re­pre­se­n­ta a la idea de una relación entre co­m­po­ne­n­tes en el sistema. De este modo no posee una notación especial, pero sus ma­ni­fe­s­ta­cio­nes muestran detalles es­pe­cí­fi­cos que las di­fe­re­n­cian.

En UML las re­la­cio­nes se entienden como líneas entre nodos, así que se modelan ge­ne­ra­l­me­n­te como líneas que pueden ofrecer va­ria­cio­nes (flechas).

La de­fi­ni­ción de las subclases de relación y las in­s­ta­n­cias ha cambiado de UML 1 a UML 2, en parte drá­s­ti­ca­me­n­te. Ori­gi­na­ria­me­n­te había re­la­cio­nes se­má­n­ti­cas, es­tru­c­tu­ra­les y dirigidas. UML cla­si­fi­ca­ba tres re­la­cio­nes (aso­cia­ción, re­s­tri­c­ción y de­pe­n­de­n­cia) entre las re­la­cio­nes se­má­n­ti­cas. En UML 2 las re­s­tri­c­cio­nes ya son elementos em­pa­que­ta­bles, las aso­cia­cio­nes definen algunas fuentes como relación es­tru­c­tu­ral y semántica. La de­pe­n­de­n­cia se clasifica en las re­la­cio­nes di­re­c­cio­na­les.

Queda esperar cómo se verá mo­di­fi­ca­do el estándar en el futuro. Se­gui­da­me­n­te ex­pli­ca­mos los diagramas de clases según UML 2.5, que establece dos subclases para la metaclase relación: la relación de dirección y la aso­cia­ción.

La su­b­e­s­pe­cie co­m­po­si­ción (Composite Ag­gre­ga­tion) describe la relación entre un conjunto de partes y una parte de este todo. Si el sistema elimina el todo (la co­m­po­si­ción o conjunto de partes) también destruye todas las partes, p. ej., si un árbol es el todo, una hoja es una parte, y si el árbol cae víctima de un incendio, este incendio también destruye a las hojas. Para re­pre­se­n­tar a esta relación en un diagrama de clases se dibuja una línea continua entre las in­s­ta­n­cias y se modela un rombo negro en el lado de la co­m­po­si­ción (en nuestro ejemplo, la instancia “árbol”). A este lado se le llama también extremo de la agre­ga­ción.

La segunda su­b­e­s­pe­cie de la agre­ga­ción es la agre­ga­ción co­m­pa­r­ti­da (o agre­ga­ción a secas). Esta relación asi­mé­tri­ca existe entre una propiedad (Property) y una instancia que re­pre­se­n­ta a un conjunto de in­s­ta­n­cias. La relación debería ser directa porque si no una instancia co­m­po­si­ción podría in­te­r­pre­tar­se como parte de sí misma. Esto podría pasar si se modela la relación de de­pe­n­de­n­cia de forma cíclica. La propiedad co­m­pa­r­ti­da puede pe­r­te­ne­cer a varias co­m­po­si­cio­nes. Al mismo tiempo, su instancia puede existir de forma in­de­pe­n­die­n­te a la co­m­po­si­ción. Si el sistema borra a una co­m­po­si­ción (o a todas) la instancia parte puede seguir exi­s­tie­n­do, por eso esta relación se considera débil en co­m­pa­ra­ción con la co­m­po­si­ción.

La aso­cia­ción presenta otra pa­r­ti­cu­la­ri­dad: la clase aso­cia­ción, clase y relación al mismo tiempo. Esto hace que puedan asignarse atributos a la clase aso­cia­ción en el diagrama de clases.

La subclase es­pe­ci­fi­ca la clase general. Esto también significa que la subclase comparte algunas pro­pie­da­des (internas y es­tru­c­tu­ra­les) con la su­pe­r­cla­se, no­r­ma­l­me­n­te los elementos fu­n­da­me­n­ta­les. A este estado se le conoce como herencia. Así, la clase dalia del ejemplo comparte con la su­pe­r­cla­se as­te­rá­ceas la in­flo­re­s­ce­n­cia en forma de cesto. Una cualidad es­pe­cí­fi­ca del género dalia son sus ocho pares de cro­mo­so­mas (otras plantas tienen por lo general solo dos pares de cro­mo­so­mas). Las diversas especies de dalia presentan por ende cua­li­da­des mucho más variadas.

De forma implícita, UML permite la herencia múltiple de modo que pueden modelarse varias subclases, que presentan su­pe­r­cla­ses comunes y di­fe­re­n­tes. Como al­te­r­na­ti­va, también existen varias capas de la ge­ne­ra­li­za­ción. Estas re­la­cio­nes pueden re­pre­se­n­tar­se con la notación de flecha o anidando las subclases en sus su­pe­r­cla­ses. Para ello se modelan todas las subclases pe­r­te­ne­cie­n­tes en el cuerpo de la su­pe­r­cla­se.

El set de ge­ne­ra­li­za­ción (Ge­ne­ra­li­za­tion Set) puede ayudarte a mantener la vista general del diagrama de clases. Este set es un elemento em­pa­que­ta­ble. En UML, los paquetes son co­n­te­ne­do­res para elementos me­n­cio­na­dos que tienen semejanza semántica y podrían mo­di­fi­car­se juntos. Un paquete es un espacio de nombres, pero no una clase. El set de ge­ne­ra­li­za­ción puede asociarse con un cla­si­fi­ca­dor. Este recibe el nombre de Powertype.

El Powertype se modela como cadena en la línea de la ge­ne­ra­li­za­ción de esta forma: {[is­Co­ve­ri­ng Property] , [is­Di­s­joi­nt Property]} : [Nombre del Powertype]. La propiedad is­Co­ve­ri­ng describe si el set está completo. Los valores pueden ser complete (completos) o in­co­m­ple­te (in­co­m­ple­tos). La propiedad is­Di­s­joi­nt declara si el cla­si­fi­ca­dor tiene in­s­ta­n­cias en común. Los valores pueden ser disjoint (no se solapan) o ove­r­la­p­pi­ng (se solapan).

La ab­s­tra­c­ción conecta elementos de capas di­fe­re­n­tes. También puede mostrar pe­r­s­pe­c­ti­vas di­fe­re­n­tes. Los elementos me­n­cio­na­dos en esta relación de de­pe­n­de­n­cia re­pre­se­n­tan al mismo concepto. Según el estándar UML el elemento más es­pe­cí­fi­co es el cliente, que depende del proveedor, el elemento más abstracto. El final de la flecha debería estar en la subclase y la punta en la su­pe­r­cla­se. Pero UML autoriza también una notación inversa. Si es más co­n­ve­nie­n­te que el elemento abstracto depende de su subclase la punta de la flecha se dibuja en el elemento más es­pe­cí­fi­co.

La ab­s­tra­c­ción tiene dos subclases: la rea­li­za­ción (Rea­li­za­tion) y la ma­ni­fe­s­ta­ción (Ma­ni­fe­s­ta­tion).

La rea­li­za­ción se ha me­n­cio­na­do ya en relación con las in­te­r­fa­ces. La rea­li­za­ción de in­te­r­fa­ces (In­te­r­fa­ce­Rea­li­za­tion) es una es­pe­ci­fi­ca­ción de la rea­li­za­ción y describe una relación entre el cla­si­fi­ca­dor y la interfaz. El cla­si­fi­ca­dor utiliza la interfaz para ofrecer un servicio a su cliente. La interfaz ejecuta este servicio, pero para ello el cla­si­fi­ca­dor ha de cumplir el contrato que fija la interfaz. La notación para in­te­r­fa­ces di­s­pue­s­tas y re­que­ri­das se encuentra en el apartado “In­te­r­fa­ces”.

La su­b­s­ti­tu­ción (Su­b­s­ti­tu­tion) es otra relación que es­pe­ci­fi­ca la rea­li­za­ción. Está compuesta por un cla­si­fi­ca­dor su­b­s­ti­tu­to y un contrato su­b­s­ti­tu­to. El cla­si­fi­ca­dor su­b­s­ti­tu­to satisface el contrato del otro cla­si­fi­ca­dor. Durante la ejecución, las in­s­ta­n­cias del cla­si­fi­ca­dor su­b­s­ti­tu­to su­b­s­ti­tu­yen a in­s­ta­n­cias po­te­n­cia­les del contrato su­b­s­ti­tu­to. A di­fe­re­n­cia de la es­pe­cia­li­za­ción, no hay semejanza es­tru­c­tu­ral entre elementos de la su­b­s­ti­tu­ción. En el diagrama de clases, la su­b­s­ti­tu­ción se escribe como una unión de de­pe­n­de­n­cia (línea di­s­co­n­ti­nua con punta abierta) añadiendo la palabra clave <<su­b­s­ti­tu­te>> sobre la línea.

La ma­ni­fe­s­ta­ción, elemento del diagrama de de­s­plie­gue en el que no nos ex­te­n­de­re­mos, describe a una relación entre un artefacto y uno o más elementos de modelado. UML define a los ar­te­fa­c­tos como cla­si­fi­ca­do­res. Si­m­bo­li­zan in­s­ta­n­cias concretas y físicas como carpetas de archivo. La ma­ni­fe­s­ta­ción indica que un artefacto ejecuta a un elemento vinculado, pero, a la inversa, puede si­m­bo­li­zar que hay elementos im­pli­ca­dos en la creación de un artefacto. Tienen la misma notación que las su­b­s­ti­tu­cio­nes y se escribe como <<manifest>>.

La ab­s­tra­c­ción también define a algunos es­te­reo­ti­pos. Estos se incluyen en los perfiles de UML, que se definen cada vez que una metaclase que ya existe se ha de ampliar para un proyecto. La clase es­te­reo­ti­po se utiliza siempre en co­m­bi­na­ción con la metaclase, porque un perfil solo puede modificar lo que ya existe o añadir te­r­mi­no­lo­gía. Desde el estándar UML 2.4.1, los es­te­reo­ti­pos se escriben con mayúscula inicial. Los es­te­reo­ti­pos estándar para una ab­s­tra­c­ción son:

• Derivar (<<Derive>>): un elemento se deriva de otro elemento diferente que ge­ne­ra­l­me­n­te es del mismo tipo.
• Refinar (<<Refine>>): un elemento pro­po­r­cio­na datos de­ta­lla­dos de una clase que también existe en otro elemento. Estos dos elementos se en­cue­n­tran en capas de ab­s­tra­c­ción di­fe­re­n­tes. Por ejemplo, un modelo en un nivel ejecutivo podría refinar su clase “empleado” en relación con la clase “empleado” en la capa de diseño.
• Rastrear (<<Trace>>): di­fe­re­n­tes modelos ma­ni­fie­s­tan aspectos di­fe­re­n­tes de un sistema. Con métodos de rastreo (mapping o tracing) se localizan elementos que re­pre­se­n­tan el mismo concepto en modelos di­fe­re­n­tes, lo que permite entender los cambios en los elementos o en las in­s­tru­c­cio­nes.

El de­s­plie­gue muestra la relación entre un artefacto y su objetivo operativo. En un diagrama UML la línea de de­s­plie­gue parte de uno o más ar­te­fa­c­tos hacia el objetivo (De­plo­y­me­nt Target) y se ide­n­ti­fi­ca con la etiqueta <<deploy>>. Esta de­pe­n­de­n­cia también puede aplicarse en el nivel de las in­s­ta­n­cias. Op­cio­na­l­me­n­te, puede modelarse el artefacto en el cuerpo del objetivo operativo bien dibujando el artefacto como símbolo o enu­me­ra­n­do los ar­te­fa­c­tos de­s­ple­ga­dos. Esta de­pe­n­de­n­cia es una parte de la notación para diagramas de de­s­plie­gue.

El uso describe una relación en la cual el cliente necesita al proveedor para cumplir con todas sus tareas o ejecutar ope­ra­cio­nes. Haciendo esto, el uso pone en práctica la de­pe­n­de­n­cia general como instancia. Esta de­pe­n­de­n­cia ma­ni­fie­s­ta algunas re­la­cio­nes concretas:

• Usar (<<use>>): un elemento utiliza a otro elemento, aunque no está definido del todo cuáles son los pa­r­ti­ci­pa­n­tes de esta relación ni cuál es su utilidad.
• Crear (<<create>>): un cla­si­fi­ca­dor cliente o uno de sus elementos de co­m­po­r­ta­mie­n­to o es­tru­c­tu­ra crea una o más in­s­ta­n­cias del cla­si­fi­ca­dor proveedor.
• Llamar (<<call>>): una operación llama a otra operación. El objetivo puede ser cualquier operación en el entorno de la operación fuente, incluso de cla­si­fi­ca­do­res su­pe­rio­res.
• Enviar (<<send>>): una operación es la fuente, esto es, el cliente. Su objetivo es una señal. La de­pe­n­de­n­cia modela así que la operación envía la señal objetivo.
• Interfaz requerida (Required Interface ----C): la interfaz requerida no existe, al contrario que la de­s­ple­ga­da, en el cla­si­fi­ca­dor. Determina los servicios que necesita un cla­si­fi­ca­dor para ejecutar sus funciones para sus clientes. La de­pe­n­de­n­cia se da entre los cla­si­fi­ca­do­res y las in­te­r­fa­ces (ver apartado “In­te­r­fa­ces”).

Vincular pla­n­ti­llas (Template binding) es la última relación dirigida que encuentra apli­ca­ción en los diagramas de clases. Al crear un diagrama de clases, puede resultar útil elaborar pla­n­ti­llas para las clases. Estas pla­n­ti­llas constan de pa­rá­me­tros, que se incluyen en la firma de la plantilla. La firma es­pe­ci­fi­ca el conjunto ordenado de pa­rá­me­tros dentro de una plantilla. Si modelas clases que no han de ostentar pro­pie­da­des in­di­vi­dua­les, el trabajo es más eficiente si se utilizan pla­n­ti­llas, pero si una clase ha de contener pa­rá­me­tros fijos, se utiliza el template binding. La relación se da entre un elemento conectado y la firma en una plantilla objetivo.

El elemento conectado es te­m­pla­tea­ble, es decir, que puede co­n­ve­r­ti­r­se en una plantilla o co­ne­c­tar­se a otras pla­n­ti­llas. El elemento está conectado porque consta de una conexión a una plantilla. Esta unión describe la es­tru­c­tu­ra del elemento al sustituir pa­rá­me­tros formales de la plantilla por pa­rá­me­tros de calidad.