6.C. Diagramas de Clases - AULA
6.C. Diagramas de Clases - AULA
a de contenidos
1. In
ntroducción.
2. Creación de cla
ases.
3. Atributos.
4. Métodos.
5. Rela
aciones entre cla
ases.
6. Cardinaliidad o multtipliicidad de la
a rela
ación.
7. Generaliización.
8. Agregación y composición.
9. Atributos de enla
ace.
10. Restricciones.
El diagrama de claases puede considerarse el más importante de todos los existentes en UML, encuadrado dentro de los diagramas estructurales,
representa los elementos estáticos del sistema, sus atributos y comportamientos, y como se relacionan entre ellos. A partir de éste se obtendrán las
clases que formarán después el programa informático.
Una clase se representa en el diagrama como un rectángulo divido en tres las, arriba aparece el nombre de
la clase, a continuación los atributos y por último los métodos.
3. Atributos.
Forman la parte estática de la clase. Son un conjunto de variables para las que es preciso de nir:
Su nombre.
Su tipo, puede ser un tipo simple, que coincidirá con el tipo de dato que se seleccione en el lenguaje de programación nal a usar, o
compuesto, pudiendo incluir otra clase.
Ejemplo
o: crear una clase de nombre "Módulo" y que tenga atributos nombre, duración y contenidos con visibilidad privado:
Representan la funcionalidad de la clase, es decir, qué puede hacer. Para de nir un método hay que indicar como mínimo su nombre, parámetros,
el tipo que devuelv
ve y su visibiliidad (similar a la de los atributos). También se debe incluir una descripción del método que aparecerá en la
documentación que se genere del proyecto.
Ejemplo
o: añadir a la clase creada anteriormente los métodos matricular y asignarDuracion con visibilidad pública:
Una rela
ación es una conexión entre dos clases que incluimos en el diagrama.
Se representan como una línea continua. Los mensajes "navegan" por las relaciones entre clases, es decir, los mensajes se envían entre objetos de
clases relacionadas, normalmente en ambas direcciones, aunque a veces la de nición del problema hace necesario que se navegue en una sola
dirección, entonces la línea naliza en punta de !echa. Si no se indica navegabilidad, se tiende a pensar que es bidireccional.
Ejemplo
o: crea una clase nueva llamada Alumno y establece una relación de asociación con el nombre “matrícula” entre ésta y la clase Módulo.
Un concepto muy importante es la cardinaliidad de una rela ación, representa cuantos objetos de una clase se van a relacionar con objetos de otra
clase. En una relación hay dos cardinalidades, una para cada extremo de la relación y pueden tener los siguientes valores:
* Cero o varios
Para la relación casado con, un marido podrá estar soltero o tener una mujer. La relación en la otra dirección tiene la misma cardinalidad.
7. Generaliización.
La generaliización es una propiedad que permite a los objetos ser construidos a partir de otros objetos, es decir, la capacidad de un objeto para
utilizar estructuras de datos y métodos presentes en sus antepasados. También recibe el nombre de herencia.
El objetivo principal de la generalización es la reutiliización, poder utilizar código desarrollado con anterioridad. La herencia supone una clase base y
una jerarquía de clases que contiene las clases derivadas. Las clases derivadas pueden heredar el código y los datos de su clase base, añadiendo su
propio código especial y datos, incluso cambiar aquellos elementos de la clase base que necesitan ser diferentes.
Tipos:
Herencia simplee: una clase puede tener sólo un ascendente inmediato. Es decir, una subclase puede heredar datos y métodos de una
única clase base.
Herencia múlttiple
e: una clase puede tener más de un ascendente inmediato, adquirir datos y métodos de más de una clase. Algunos
lenguajes, como Java, no soportan herencia múltiple.
Representación:
En el diagrama de clases se representa como una asociación en la que el extremo de la clase base tiene un triángulo.
8. Agregación y composición.
Muchas veces una determinada entidad existe como un conjunto de otras entidades. En este tipo de relaciones un objeto componente se integra en
un objeto compuesto. La orientación a objetos recoge este tipo de relaciones como dos conceptos: la agregación y la composición.
La agregación es una asociación binaria que representa una relación todo-parte (pertenece a, tiene un, es parte de). Los ele
ementos parte pueden
existir sin el ele
emento contenedor y no son propiedad suya. Por ejemplo, un centro comercial tiene clientes o un equipo tiene unos miembros. El
tiempo de vida de los objetos no tiene porqué coincidir.
En el siguiente caso, tenemos un ordenador que se construye a partir de piezas sueltas que pueden ser sustituidas y que tienen entidad por si
mismas, por lo que se representa mediante relaciones de agregación. Utilizamos la agregación porque es posible que una caja, ratón o teclado o
una memoria RAM existan con independencia de que pertenezcan a un ordenador o no.
La composición es una agregación fuerte en la que una instancia ‘parte’ está relacionada, como máximo, con una instancia ‘todo’ en un momento
dado, de forma que cuando un objeto ‘todo’ es eliiminado, también son eliiminados sus objetos ‘parte’. Por ejemplo: un rectángulo tiene cuatro
vértices, un centro comercial está organizado mediante un conjunto de secciones de venta, una empresa está formada por departamentos ....
Estas relaciones se representan con un rombo en el extremo de la entidad contenedora. En el caso de la agregación es de color blanco y para la
composición negro. Como en toda relación hay que indicar la cardinalidad.
9. Atributos de enla
ace.
Es posible que tengamos alguna relación en la que sea necesario añadir algún tipo de información que la complete de alguna manera. Cuando esto
ocurre podemos añadir atributos a la
a rela
ación.
Ejemplo
o: cuando un alumno se matricula de un módulo es preciso especi car el curso al que pertenece la matrícula, las notas obtenidas en el
examen y la tarea y la cali cación nal obtenida. Estas características no pertenecen totalmente al alumno ni al módulo sino a la relación especí ca
que se crea entre ellos, que además será diferente si cambia el alumno o el módulo. Por tanto la clase matrícula tiene una relación con el enlace
entre Alumno y Módulo.
10. Restricciones.
En ocasiones la relación entre dos clases está condicionada al cumplimiento de algún requisito, o un parámetro de una clase tiene un valor
constante ...
Cuando se precisa re!ejar una condición que aparece en el enunciado y no disponemos de una notación particular para que quede re!ejada en el
diagrama de clases, es posible mostrarla mediante una re
estricción.
Las restricciones se incluyen mediante una descripción textual encerrada entre llaves.
Ejemplo
o-1
1. Supongamos un ejercicio donde el socio de un club de fútbol desea acceder al palco del estadio. Si esta posibilidad sólo está disponible
para antiguos jugadores del equipo, junto a la línea que relaciona las clases socio y palco, se puede incluir la restricción {sólo para ex-jugadores}.
Ejemplo
o-2
2. Supongamos que la clase producto de un establecimiento tiene un IVA jo del 21%, sea cual sea el tipo de producto que pone a la venta.
Dado que este valor es jo, podría considerarse una constante. En el diagrama de clases podría indicarse con una restricción del tipo {IVA constante
21%}.
11. Pautas para crear diagramas de cla
ase.
A la hora de crear diagramas de clases, la clave está en hacer una buena elección de las clases que sugiere el problema.
Para identi car las clases candidatas a formar parte del diagrama, es recomendable subrayar cada nombre o sintagma nominal que aparece en el
enunciado.
Cuando tengamos la lista completa habrá que estudiar cada clase potencial para ver si, nalmente, es incluida en el diagrama. Para ayudarnos a
decidir, podemos utilizar los siguientes criterios:
La información de la clase es necesaria para que el sistema funcione.
La clase posee un conjunto de atributos que podemos encontrar en cualquier ocurrencia de sus objetos. Si sólo aparece un atributo
normalmente se rechazará y será añadido como atributo de otra clase.
La clase tiene un conjunto de operaciones identi cables que pueden cambiar el valor de sus atributos y son comunes en cualquiera de
sus objetos.
Es una entidad externa que consume o produce información esencial para la producción de cualquier solución en el sistema.