Diagramas de clases

Las clases representan los bloques de construccin ms importantes de cualquier sistema

orientado a objetos. Una clase es una descripcin de un conjunto de objetos que comparten los
mismos atributos, operaciones, relaciones y semntica. La representacin grfica de clases en
UML se muestra en la siguiente figura.

Esta notacin es independiente de cualquier lenguaje de programacin. El primer bloque de la

figura representa el nombre de la clase, el segundo bloque contiene los atributos, y el tercer
bloque contiene las operaciones. El nombre de la clase puede ser simple (ej: Figura) o puede
indicar el camino completo (paquete) donde reside la clase (ej: Grafico::Figura). En la
definicin de los atributos se pueden incluir sus tipos (ej: altura:Real). Lo mismo para las
operaciones (ej: mover(a:int,b:int):boolean).
No es necesario mostrar todas las caractersticas. A veces las clases tienen tantas caractersticas,
que no es conveniente mostrarlas todas. En estos casos tambin se pueden organizar las
caractersticas usando estereotipos. Por ejemplo:

Responsabilidades
Una responsabilidad es un contrato o una obligacin de una clase. Al modelar clases, un buen
comienzo consiste en especificar las responsabilidades de los elementos. Una clase bien
estructurada tiene al menos una responsabilidad (debera tener pocas). Grficamente, las
respondabilidades se expresan en una seccin al final de la clase. Por ejemplo:

Uso de clases
Modelar el vocabulario de un sistema: Para modelar el vocabulario de un sistema, hay que
identificar aquellas cosas que utilizan los usuarios para describir el problema o la solucin. Para
esto se pueden utilizar tarjetas CRC y anlisis basado en casos de uso. Una vez identificadas las
abstracciones, hay que identificar sus responsabilidades. El siguiente es un ejemplo del modelado
del vocabulario de un sistema.

Modelar la distribucin de responsabilidades: Para modelar la distrubucin de

responsabilidades en un sistema, hay que identificar un conjunto de clases que colaboren entre
ellas para llevar a cabo algn comportamiento. Luego hay que identificar el conjunto de

responsabilidades para cada clase. Por ejemplo:

Observe cmo estas clases colaboran de forma que ninguna clase hace mucho ni muy poco.
Relaciones
Las clases casi nunca se encuentran aisladas. Por lo general la mayora de ellas colaboran con
otras de varias maneras. Por tanto, al modelar un sistema tambin hay que modelar la forma en
que las clases se ralacionan. En el modelado orientado a objetos hay tres tipos de relaciones:
dependencias, generalizaciones y asociaciones.

Una dependencia es una relacin de uso, que declara que un cambio en la especificacin de un
elemento (por ejemplo la clase Evento) puede afectar a otro elemento que la utiliza (por
ejemplo la clase Ventana), pero no necesariamente a la inversa (la flecha va dirigida hacia el
elemento del cual se depende). Una dependencia quiere decir que un elemento utiliza a otro.
Una generalizacin conecta una clase general (llamada superclase o padre) con otra clase ms

especializada (llamada subclase o hijo). Es una relacin "es-un" o "es-una". Por ejemplo, el
CuadroDialogo es una Ventana.
Las asociaciones son relaciones estructurales entre instancias, que especifican que los objetos de
un elemento estn conectados con los objetos de otro. Es legal que los objetos de una clases estn
conectados con objetos de la misma clase. Hay cuatro tipos de "adornos" que se le pueden poner
a estas relaciones: nombre, rol, multiplicidad y agregacin. Ejemplo:

Nombre: Una asociacin puede tener un nombre, que se utiliza para describir la naturaleza de la
relacin. Para evitar ambigedades, se puede indicar una direccin al nombre, es decir, la
direccin en que se debe leer el nombre.
Rol: Un rol es la cara que la clase de un extremo de la asociacin presenta a la clase del otro
extremo. Es el rol que juega la clase en la asociacin.
Multiplicidad: Representa el nmero de objetos que pueden conectarse a travs de una relacin
de asociacin. Se puede indicar una multiplicidad de exactamente uno (1), cero o uno (0..1),
muchos (0..*), o uno o ms (1..*). Tambin se puede indicar un valor exacto (por ejemplo, 3).
Agregacin: A veces se desea modelar una relacin de tipo "todo/parte", en la cual una clase
representa algo grande (el todo), que consta de elementos ms pequeos (las partes). Este tipo de
relacin se denomina agregacin, y es una relacin "tiene-un" o "tiene-una". Ejemplo:

Composicin: La composicin es un tipo especial de asociacin, que tambin modela relaciones

"todo/parte". La diferencia es que tiene una fuerte relacin de pertenencia y vidas coincidentes de
la parte con el todo. Las "partes" pueden crearse despus del "todo", pero una vez creadas, viven
y mueren con el "todo" (se pueden eliminar explcitamente antes). Quiere decir que una "parte",
solamente puede estar relacionada con un "todo". Ejemplo:

En el siguiente ejemplo se muestran algunas de la relaciones antes descritas. Observen el poder

de expresin de esta notacin.

Algunos conceptos
Para diferenciar a las clases abstractas, el nombre de stas se pone en cursiva. Las clases
abstractas no pueden tener instancias directas. La visibilidad de una caracterstica especifica si
puede ser utilizada por otros objetos. Hay tres niveles de visibilidad en UML: public
(cualquiera la puede usar, la caracterstica es precedida por el smbolo +), protected
(cualquier descendiente la puede utilizar, se especifica con el smbolo #), y private
(solamente la propia clase la usa, se especifica con el smbolo -). El alcance de una caracterstica
define si la caracterstica aparece en cada instancia de la clase, o si slo hay una caracterstica
para todas las instancias. Para definir alcance de clase, las caractersticas se subrayan. Por
defecto, las caractersticas tienen alcance de instancia. Ejemplo:

Hay otras propiedades poco utilizadas. Por ejemplo, leaf, que indica que una clase es una hoja,
y por tanto no permite que otras clases herenden caractersticas de ella. La propiedad root

indica que una clase no puede tener padres. Por ejemplo:

La multiplicidad define el nmero de instancias que puede tener una clase. Esta es 0, 1 o n. Por
defecto, las clases tienen multiplicidad n. Si se quiere definir una multiplicidad diferente de n,
hay que especificarla. Por ejemplo:

Esto quiere decir que la clase ControladorRed solamente puede tener una instancia. A su
vez, para esta clase pueden haber dos o ms puertoConsola.