Diagramas de clases

Diagramas de clases
Las clases representan los bloques de construcción más importantes de cualquier sistema
orientado a objetos. Una clase es una descripción de un conjunto de objetos que comparten los
mismos atributos, operaciones, relaciones y semántica. La representación gráfica de clases en
UML se muestra en la siguiente figura.
Esta notación es independiente de cualquier lenguaje de programación. 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
definición 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 características. A veces las clases tienen tantas características,
que no es conveniente mostrarlas todas. En estos casos también se pueden organizar las
características usando estereotipos. Por ejemplo:
Responsabilidades
Una responsabilidad es un contrato o una obligación 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 (debería tener pocas). Gráficamente, las
respondabilidades se expresan en una sección 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 solución. Para
esto se pueden utilizar tarjetas CRC y análisis 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 distribución de responsabilidades: Para modelar la distrubución de
responsabilidades en un sistema, hay que identificar un conjunto de clases que colaboren entre
ellas para llevar a cabo algún comportamiento. Luego hay que identificar el conjunto de
responsabilidades para cada clase. Por ejemplo:
Observe cómo 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 mayoría de ellas colaboran con
otras de varias maneras. Por tanto, al modelar un sistema también 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 relación de uso, que declara que un cambio en la especificación 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 generalización conecta una clase general (llamada superclase o padre) con otra clase más
especializada (llamada subclase o hijo). Es una relación "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 están conectados con los objetos de otro. Es legal que los objetos de una clases estén
conectados con objetos de la misma clase. Hay cuatro tipos de "adornos" que se le pueden poner
a estas relaciones: nombre, rol, multiplicidad y agregación. Ejemplo:
Nombre: Una asociación puede tener un nombre, que se utiliza para describir la naturaleza de la
relación. Para evitar ambigüedades, se puede indicar una dirección al nombre, es decir, la
dirección en que se debe leer el nombre.
Rol: Un rol es la cara que la clase de un extremo de la asociación presenta a la clase del otro
extremo. Es el rol que juega la clase en la asociación.
Multiplicidad: Representa el número de objetos que pueden conectarse a través de una relación
de asociación. Se puede indicar una multiplicidad de exactamente uno (1), cero o uno (0..1),
muchos (0..*), o uno o más (1..*). También se puede indicar un valor exacto (por ejemplo, 3).
Agregación: A veces se desea modelar una relación de tipo "todo/parte", en la cual una clase
representa algo grande (el todo), que consta de elementos más pequeños (las partes). Este tipo de
relación se denomina agregación, y es una relación "tiene-un" o "tiene-una". Ejemplo:
Composición: La composición es un tipo especial de asociación, que también modela relaciones
"todo/parte". La diferencia es que tiene una fuerte relación de pertenencia y vidas coincidentes de
la parte con el todo. Las "partes" pueden crearse después del "todo", pero una vez creadas, viven
y mueren con el "todo" (se pueden eliminar explícitamente 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 expresión de esta notación.
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 característica especifica si
puede ser utilizada por otros objetos. Hay tres niveles de visibilidad en UML: public
(cualquiera la puede usar, la característica es precedida por el símbolo +), protected
(cualquier descendiente la puede utilizar, se especifica con el símbolo #), y private
(solamente la propia clase la usa, se especifica con el símbolo -). El alcance de una característica
define si la característica aparece en cada instancia de la clase, o si sólo hay una característica
para todas las instancias. Para definir alcance de clase, las características se subrayan. Por
defecto, las características 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 características de ella. La propiedad root
indica que una clase no puede tener padres. Por ejemplo:
La multiplicidad define el número 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 más puertoConsola.