Sei sulla pagina 1di 12

REPRESENTAR UN PROGRAMA EN DIAGRAMA DE

CLASES

El diagrama de clases representa los objetos de nuestro sistema informtico con sus atributos,
mtodos y asociaciones que existen entre ellos.
Representacin de clases
Los objetos del sistema se representan mediante clases. Una clase est formada por su nombre,
sus atributos y sus mtodos, tal y como muestra la figura:

El nombre de la clase se escribe en singular y con la inicial en mayscula. Este nombre
debe ser representativo de los objetos que se van a representar.
Los atributos describen la estructura del objeto, y contienen informacin sobre ste. Cada
objeto tendr diferente informacin, por tanto diferentes valores en sus atributos, pero
todos los objetos de una clase tendrn la misma estructura, es decir, los mismos atributos.
Los mtodos describen el comportamiento de los objetos. Cada mtodo es un conjunto de
instrucciones que pueden modificar los valores de los atributos, o generar algn resultado.
Encapsulacin
La encapsulacin consiste en ocultar los atributos y mtodos de un objeto de manera que el resto
de objetos no los puedan ver. Hay veces en las que algunos atributos y mtodos se utilizan de
forma interna en el objeto y no deben estar expuestos a los objetos exteriores.
UML ofrece las siguientes posibilidades de encapsulacin, segn la visibilidad del elemento, y una
representacin grfica para cada una de ellas:
Privado - el elemento es visible slo 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
Pblico + el elemento es visible para todos

La encapsulacin se representa con los smbolos del cuadro anterior precediendo el nombre de los
atributos o mtodos:

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 numricos, cadenas de caracteres, booleanos, o
incluso otras clases de nuestro diagrama (aunque esto no es muy comn ni recomendable).
Representaremos los tipos de datos de los atributos de la siguiente manera:

UML nos proporciona los siguientes tipos de datos primitivos:
Integer: nmeros enteros.
String: texto o cadena de caracteres.
Boolean: tipo de dato lgico, acepta los valores true/false.
UnlimitedNatural: nmero positivos, de 0 a infinito.
Firma de los mtodos
Los mtodos pueden recibir parmetros y devolver un resultado. Tambin tendremos que
especificar el tipo de datos de los parmetros y los resultados.
Al conjunto formado por el nombre del mtodo, sus parmetros con su nombre y su tipo, y el tipo
de resultado se le conoce como firma del mtodo.

En el ejemplo anterior tenemos la firma de dos mtodos: el primero recibe dos parmetros,
param1 de tipo Integer y param2 de tipo String, y devuelve un resultado de tipo Integer. El
segundo mtodo no recibe parmetros ni genera ningn resultado.
Valores predeterminados
Es posible dar valores predeterminados a los atributos y a los parmetros de los mtodos. Estos
valores son los que tomarn al crear el objeto. La representacin es la siguiente:

Atributos y mtodos de clase
Cada objeto contiene un valor especfico 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.
Tambin podemos crear mtodos de clase. Estos mtodos slo manipulan los atributos de clase.

(*) Los atributos y mtodos 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 funcin que expresa cmo se calcula su valor.

Asociaciones entre objetos
Las asociaciones sirven para representar los vnculos que existen entre objetos. La asociacin tiene
un nombre, y se representa mediante una lnea que une las dos clases vinculadas.

Para sealar el sentido de lectura del nombre de la asociacin con respecto al nombre de las
clases, ste puede precederse del signo < o seguirse del signo >.
Los extremos de una asociacin tambin pueden recibir un nombre, que representar la funcin
que desempean en la asociacin los objetos. En las funciones podemos especificar su tipo de
encapsulamiento (pblica, privada, protegida o empaquetada). Esto es as ya que la funcin la
podemos entender como un atributo cuyo tipo sera la clase situada en el otro extremo de la
asociacin.
Las siguientes asociaciones seran equivalentes:

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

Tambin podemos hacer asociaciones unarias, es decir, en las que slo interviene una clase, que
se relaciona con ella misma. Este tipo de asociacin se llama reflexiva. En este tipo de asociacin
es preferible poner los nombres de las funciones que desempea la clase, en lugar del nombre de
la asociacin.

Cardinalidad de las asociaciones
Las cardinalidades se ponen en los extremos de la asociacin. La cardinalidad situada a la derecha
indica a cuntos 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 mnima y la mxima. Tenemos las siguientes opciones, con su especificacin:
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.
Navegacin
Las asociaciones anteriores tienen una navegabilidad bidireccional, es decir, es posible determinar
los vnculos de la asociacin desde un objeto de cada clase de origen. Pero las asociaciones
bidireccionales son ms complejas de realizar para los desarrolladores, por tanto conviene
evitarlas si podemos.
Para representar la navegabilidad de una asociacin en una direccin, sta se representa en forma
de flecha:

Clases-asociaciones
A veces una asociacin lleva una informacin propia, que depende de cada relacin entre objetos
concretos de las clases asociadas. En estos casos, la asociacin que describe los vnculos recibe el
estatus de clase y sus instancias son elementos de la asociacin.
Al igual que el resto de clases, estas asociaciones pueden tener atributos y mtodos, 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 bsica. Una instancia de la clase
bsica puede participar como mximo en una de las asociaciones unidas por xor.


Subset: indica que una asociacin es un subconjunto de otra asociacin.

Informacin derivada
Un elemento (atributo o asociacin) es derivado si se puede calcular a partir de otros elementos.
Estos elementos derivados se incluyen cuando mejoran la claridad del modelo conceptual.
La representacin grfica de un atributo derivado se hace de la siguiente forma:

El texto que acompaa al grfico se conoce como regla de derivacin.
A continuacin vemos una asociacin derivada:

Objetos compuestos
La composicin es un tipo especial de asociacin, en la que se vincula un objeto complejo con los
objetos que lo constituyen (sus componentes).
Existen dos formas de composicin:
Fuerte (o composicin): los componentes que constituyen el objeto compuesto no pueden
ser compartidos por varios objetos compuestos. La cardinalidad mxima, del lado del
objeto compuesto, es uno. Si eliminamos el objeto compuesto, se eliminan
automticamente sus componentes.

Dbil (o agregacin): los componentes pueden ser compartidos por varios compuestos. Si
eliminamos el objeto compuesto, no se eliminan necesariamente sus componentes.


Generalizacin/Especializacin
Una clase es ms especfica que otra si todos los objetos que la componen son a su vez objetos de
otra clase. La clase ms especfica es una subclase de la otra clase. Esta ltima, ms 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 tambin instancias de su superclase. Por
consiguiente, heredan los atributos y mtodos definidos en la superclase, adems de los atributos
y mtodos introducidos en la clase.
Como se apunt en el apartado Atributos y mtodos de clase, las subclases no heredan los
atributos y mtodos de clase que pueda tener la superclase.

En el ejemplo, un estudiante tiene un nmero de expediente y un mtodo estudiar, pero adems
tiene un dni y un nombre, y los mtodos nacer y comer. El estudiante hereda los atributos y
mtodos 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 comn.
{overlapping}: las subclases pueden tener una o varias instancias en comn.

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 mltiple, es decir,
que una subclase herede de varias superclases. Conviene evitar estos diseos, ya que son pocos
los lenguajes de programacin que soportan la herencia mltiple.
Interfaz
Una interfaz es una clase abstracta, es decir, una clase que no tiene atributos, y sus mtodos no
contienen ninguna implementacin. Las interfaces se utilizan para especificar los mtodos de una
clase. Slo contiene las cabeceras de stos, no su implementacin.
La representacin grfica de las interfaces se realiza de la siguiente manera:

La interfaz programador tiene el mtodo programar, que no est implementado. ste se
implementar en las clases ProgramadorJava y ProgramadorCobol, cada mtodo con una
implementancin especfica, ya que no se actuar igual un programador en Java que uno en Cobol.
Las interfaces tambin pueden representarse de otra forma, llamada forma abreviada, aunque la
ms comn en los diagramas de clases es la anterior, o forma expandida. La forma abreviada se
suele usar en los diagramas de componentes:

Las clases tambin pueden depender de una interfaz para realizar sus operaciones. La interfaz se
emplea entonces como tipo dentro de la clase (atributo, parmetro o variable local de uno de los
mtodos).

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 relacin de dependencia de la clase Programa con la
interfaz Programador se representa de la siguiente forma.


Restricciones
Las restricciones que no se pueden especificar grficamente con la notacin UML se especifican de
forma textual.
La especificacin textual se puede hacer con lenguaje natural, con OCL
(ObjectConstraintLanguage), etc.
Ejemplo de especificacin de restricciones textuales:

Potrebbero piacerti anche