diagrama de clases

UML – Diagrama de clases Daniel Santiago

1

Diagrama de clases

Representación de clases 2

Encapsulación 2

Tipos de datos 3

Firma de los métodos 3

Valores predeterminados 4

Atributos y métodos de clase 4

Atributos calculados 4

Asociaciones entre objetos 5

Cardinalidad de las asociaciones 6

Navegación 7

Clases-asociaciones 7

Restricciones sobre asociaciones 7

Información derivada 8

Objetos compuestos 8

Generalización/Especialización 9

Herencia 9

Interfaz 11

Restricciones 12


2

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:


3

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.


4

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.


5

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:


6

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.


7

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”.


8

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.


9

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.


10

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).


11

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.


12

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.


13

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:

diagrama de clases

Education