REPRESENTAR UN PROGRAMA EN DIAGRAMA DE

CLASES

El diagrama de clases representa los objetos de nuestro sistema informático con sus atributos,
métodos y asociaciones que existen entre ellos.
Representación de clases
Los objetos del sistema se representan mediante clases. Una clase está formada por su nombre,
sus atributos y sus métodos, tal y como muestra la figura:

 El nombre de la clase se escribe en singular y con la inicial en mayúscula. Este nombre
debe ser representativo de los objetos que se van a representar.
 Los atributos describen la estructura del objeto, y contienen información sobre éste. Cada
objeto tendrá diferente información, por tanto diferentes valores en sus atributos, pero
todos los objetos de una clase tendrán la misma estructura, es decir, los mismos atributos.
 Los métodos describen el comportamiento de los objetos. Cada método es un conjunto de
instrucciones que pueden modificar los valores de los atributos, o generar algún resultado.
Encapsulación
La encapsulación consiste en ocultar los atributos y métodos de un objeto de manera que el resto
de objetos no los puedan ver. Hay veces en las que algunos atributos y métodos se utilizan de
forma interna en el objeto y no deben estar expuestos a los objetos exteriores.
UML ofrece las siguientes posibilidades de encapsulación, según la visibilidad del elemento, y una
representación gráfica para cada una de ellas:
Privado - el elemento es visible sólo en la clase
Protegido # el elemento es visible en las subclases de la clase
Empaquetado ~ el elemento es visible en las clases del mismo empaquetado
Público + el elemento es visible para todos

La encapsulación se representa con los símbolos del cuadro anterior precediendo el nombre de los
atributos o métodos:

Tipos de datos
En el diagrama de clases debemos especificar el conjunto de posibles valores que puede tomar
cada atributo. Estos valores pueden ser valores numéricos, cadenas de caracteres, booleanos, o
incluso otras clases de nuestro diagrama (aunque esto no es muy común ni recomendable).
Representaremos los tipos de datos de los atributos de la siguiente manera:

UML nos proporciona los siguientes tipos de datos primitivos:
 Integer: números enteros.
 String: texto o cadena de caracteres.
 Boolean: tipo de dato lógico, acepta los valores true/false.
 UnlimitedNatural: número positivos, de 0 a infinito.
Firma de los métodos
Los métodos pueden recibir parámetros y devolver un resultado. También tendremos que
especificar el tipo de datos de los parámetros y los resultados.
Al conjunto formado por el nombre del método, sus parámetros con su nombre y su tipo, y el tipo
de resultado se le conoce como firma del método.

En el ejemplo anterior tenemos la firma de dos métodos: el primero recibe dos parámetros,
param1 de tipo Integer y param2 de tipo String, y devuelve un resultado de tipo Integer. El
segundo método no recibe parámetros ni genera ningún resultado.
Valores predeterminados
Es posible dar valores predeterminados a los atributos y a los parámetros de los métodos. Estos
valores son los que tomarán al crear el objeto. La representación es la siguiente:

Atributos y métodos de clase
Cada objeto contiene un valor específico para cada uno de sus atributos. Por tanto, este valor no
se comparte con el resto de objetos. Si queremos usar valores que sean compartidos por todos los
objetos de una misma clase utilizaremos los atributos de clase.
Los atributos de clase se representan igual que los atributos de los objetos, pero subrayados. No
es obligatorio, pero sí muy recomendable asignar un valor predeterminado a los atributos de
clase.
También podemos crear métodos de clase. Estos métodos sólo manipulan los atributos de clase.

(*) Los atributos y métodos de clase no se heredan.
Atributos calculados
En UML podemos tener atributos cuyo valor viene determinado por el valor de otros atributos.
Estos atributos se representan mediante su nombre precedidos por el signo / y van seguidos de
una función que expresa cómo se calcula su valor.

Asociaciones entre objetos
Las asociaciones sirven para representar los vínculos que existen entre objetos. La asociación tiene
un nombre, y se representa mediante una línea que une las dos clases vinculadas.

Para señalar el sentido de lectura del nombre de la asociación con respecto al nombre de las
clases, éste puede precederse del signo < o seguirse del signo >.
Los extremos de una asociación también pueden recibir un nombre, que representará la función
que desempeñan en la asociación los objetos. En las funciones podemos especificar su tipo de
encapsulamiento (pública, privada, protegida o empaquetada). Esto es así ya que la función la
podemos entender como un atributo cuyo tipo sería la clase situada en el otro extremo de la
asociación.
Las siguientes asociaciones serían equivalentes:

UML nos permite crear asociaciones ternarias y superiores, de la siguiente forma:

También podemos hacer asociaciones unarias, es decir, en las que sólo interviene una clase, que
se relaciona con ella misma. Este tipo de asociación se llama reflexiva. En este tipo de asociación
es preferible poner los nombres de las funciones que desempeña la clase, en lugar del nombre de
la asociación.

Cardinalidad de las asociaciones
Las cardinalidades se ponen en los extremos de la asociación. La cardinalidad situada a la derecha
indica a cuántos objetos de la clase de la derecha está vinculado un objeto de la clase de la
izquierda.
Las cardinalidades las podemos representar mediante un valor o con un intervalo, especificando la
cardinalidad mínima y la máxima. Tenemos las siguientes opciones, con su especificación:
0..1 Cero o una instancia
1 Una instancia
* De cero a varias instancias
1..* De una a varias instancias
M..N Entre M y N instancias
N N instancias

Si no especificamoscardinalidad, por defecto será 1.

En el ejemplo anterior, un trabajador tiene un jefe y un jefe tiene uno o varios trabajadores.
Navegación
Las asociaciones anteriores tienen una navegabilidad bidireccional, es decir, es posible determinar
los vínculos de la asociación desde un objeto de cada clase de origen. Pero las asociaciones
bidireccionales son más complejas de realizar para los desarrolladores, por tanto conviene
evitarlas si podemos.
Para representar la navegabilidad de una asociación en una dirección, ésta se representa en forma
de flecha:

Clases-asociaciones
A veces una asociación lleva una información propia, que depende de cada relación entre objetos
concretos de las clases asociadas. En estos casos, la asociación que describe los vínculos recibe el
estatus de clase y sus instancias son elementos de la asociación.
Al igual que el resto de clases, estas asociaciones pueden tener atributos y métodos, incluso
asociaciones con otras clases.


Restricciones sobre asociaciones
A parte de la multiplicidad, es posible expresas otras restricciones sobre las asociaciones:
 Xor: une varias asociaciones ligadas a una misma clase básica. Una instancia de la clase
básica puede participar como máximo en una de las asociaciones unidas por “xor”.


 Subset: indica que una asociación es un subconjunto de otra asociación.

Información derivada
Un elemento (atributo o asociación) es derivado si se puede calcular a partir de otros elementos.
Estos elementos derivados se incluyen cuando mejoran la claridad del modelo conceptual.
La representación gráfica de un atributo derivado se hace de la siguiente forma:

El texto que acompaña al gráfico se conoce como regla de derivación.
A continuación vemos una asociación derivada:

Objetos compuestos
La composición es un tipo especial de asociación, en la que se vincula un objeto complejo con los
objetos que lo constituyen (sus componentes).
Existen dos formas de composición:
 Fuerte (o composición): los componentes que constituyen el objeto compuesto no pueden
ser compartidos por varios objetos compuestos. La cardinalidad máxima, del lado del
objeto compuesto, es uno. Si eliminamos el objeto compuesto, se eliminan
automáticamente sus componentes.

 Débil (o agregación): los componentes pueden ser compartidos por varios compuestos. Si
eliminamos el objeto compuesto, no se eliminan necesariamente sus componentes.


Generalización/Especialización
Una clase es más específica que otra si todos los objetos que la componen son a su vez objetos de
otra clase. La clase más específica es una subclase de la otra clase. Esta última, más general, recibe
el nombre de superclase.

En el ejemplo anterior, Persona es la superclase, que generaliza a las subclases Estudiante y
Profesor. Por otro lado, estas dos últimas clases especializan a la superclase Persona. Todas las
instancias de Estudiante y Profesor son a su vez instancias de Persona.
Herencia
Como se ha dicho, las instancias de una clase son también instancias de su superclase. Por
consiguiente, heredan los atributos y métodos definidos en la superclase, además de los atributos
y métodos introducidos en la clase.
Como se apuntó en el apartado “Atributos y métodos de clase”, las subclases no heredan los
atributos y métodos de clase que pueda tener la superclase.

En el ejemplo, un estudiante tiene un número de expediente y un método estudiar, pero además
tiene un dni y un nombre, y los métodos nacer y comer. El estudiante hereda los atributos y
métodos de la persona. Con el profesor pasa lo mismo.
Existen cuatro tipos de herencia, las cuales UML nos permite especificar con las palabras entre
llaves siguientes:
 {incomplete}: no todas las instancias de la superclase tienen su equivalencia en una de las
subclases.
 {complete}: todas las instancias de la superclase tienen su equivalente en una de las
subclases.
 {disjoint}: las subclases no tienen ninguna instancia en común.
 {overlapping}: las subclases pueden tener una o varias instancias en común.

En el ejemplo anterior, todas las personas son hombre o mujeres (complete), pero no puede haber
una persona que sea hombre y mujer a la vez (disjoint).

En el ejemplo anterior, no todas las personas son trabajadores o estudiantes (incomplete), y
puede haber personas que sean trabajadores y estudiantes a la vez (overlapping).
Para terminar con este apartado, cabe destacar que UML admite la herencia múltiple, es decir,
que una subclase herede de varias superclases. Conviene evitar estos diseños, ya que son pocos
los lenguajes de programación que soportan la herencia múltiple.
Interfaz
Una interfaz es una clase abstracta, es decir, una clase que no tiene atributos, y sus métodos no
contienen ninguna implementación. Las interfaces se utilizan para especificar los métodos de una
clase. Sólo contiene las cabeceras de éstos, no su implementación.
La representación gráfica de las interfaces se realiza de la siguiente manera:

La interfaz programador tiene el método programar, que no está implementado. Éste se
implementará en las clases ProgramadorJava y ProgramadorCobol, cada método con una
implementanción específica, ya que no se actuará igual un programador en Java que uno en Cobol.
Las interfaces también pueden representarse de otra forma, llamada forma abreviada, aunque la
más común en los diagramas de clases es la anterior, o forma expandida. La forma abreviada se
suele usar en los diagramas de componentes:

Las clases también pueden depender de una interfaz para realizar sus operaciones. La interfaz se
emplea entonces como tipo dentro de la clase (atributo, parámetro o variable local de uno de los
métodos).

En el ejemplo anterior, para poder realizar un programa necesitamos programadores. Por tanto la
clase Programa depende de la interfaz Programador.
La forma abreviada de representar la misma relación de dependencia de la clase Programa con la
interfaz Programador se representa de la siguiente forma.


Restricciones
Las restricciones que no se pueden especificar gráficamente con la notación UML se especifican de
forma textual.
La especificación textual se puede hacer con lenguaje natural, con OCL
(ObjectConstraintLanguage), etc.
Ejemplo de especificación de restricciones textuales: