Una guía completa para el diagrama de clases UML

Ejemplo de clase

Un perro tiene estados: color, nombre, raza, así como comportamientos: menear, ladrar, comer. Un objeto es una instancia de una clase.

Notación de clase UML

Una clase representa un concepto que encapsula estado ( atributos ) y comportamiento ( operaciones ). Cada atributo tiene un tipo. Cada  operación  tiene una  firma . El nombre de la clase es la  única información obligatoria .

Nombre de la clase:

• El nombre de la clase aparece en la primera partición.

Atributos de clase:

• Los atributos se muestran en la segunda partición.
• El tipo de atributo se muestra después de los dos puntos.
• Los atributos se asignan a las variables miembro (miembros de datos) en el código.

Operaciones de Clase (Métodos):

• Las operaciones se muestran en la tercera partición. Son servicios que brinda la clase.
• El tipo de retorno de un método se muestra después de los dos puntos al final de la firma del método.
• El tipo de devolución de los parámetros del método se muestra después de los dos puntos que siguen al nombre del parámetro. Las operaciones se asignan a los métodos de clase en el código.

Relaciones de clase

Una clase puede estar involucrada en una o más relaciones con otras clases. Una relación puede ser de uno de los siguientes tipos: (Consulte la figura de la derecha para ver la representación gráfica de las relaciones).

Tipo de relación	Representación grafica
Herencia  (o generalización): Representa una relación «es-un». Un nombre de clase abstracto se muestra en cursiva. SubClass1 y SubClass2 son especializaciones de Super Class. Una línea continua con una punta de flecha hueca que apunta desde la clase secundaria a la principal
Asociación sencilla : Un vínculo estructural entre dos clases de pares. Hay una asociación entre Class1 y Class2 Una línea sólida que conecta dos clases.
Agregación :Un tipo especial de asociación. Representa una relación de “parte de”. Class2 es parte de Class1. Muchas instancias (indicadas por *) de Class2 se pueden asociar con Class1. Los objetos de Class1 y Class2 tienen vidas separadas. Una línea sólida con un rombo sin relleno en el extremo de la asociación conectado a la clase de compuesto
Composición :Un tipo especial de agregación donde las partes se destruyen cuando se destruye el todo. Los objetos de Class2 viven y mueren con Class1. Class2 no puede valerse por sí mismo. Una línea sólida con un rombo lleno en la asociación conectada a la clase de compuesto
dependencia : Existe entre dos clases si los cambios en la definición de una pueden causar cambios en la otra (pero no al revés). Clase1 depende de Clase2 Una línea discontinua con una flecha abierta

Nombres de relaciones

• Los nombres de las relaciones se escriben en el medio de la línea de asociación.
• Los buenos nombres de relaciones tienen sentido cuando los lees en voz alta:
  • “Cada hoja de cálculo  contiene  cierto número de celdas”,
  • “una expresión  se evalúa como  un valor”
• A menudo tienen una  pequeña punta de flecha para mostrar la dirección  en la que leer la relación, por ejemplo, las expresiones se evalúan como valores, pero los valores no se evalúan como expresiones.

Relación – Roles

• Un rol es un propósito direccional de una asociación.
• Los roles se escriben al final de una línea de asociación y describen el propósito que desempeña esa clase en la relación.
  • Por ejemplo, una celda está relacionada con una expresión. La naturaleza de la relación es que la expresión es la  fórmula  de la celda.

Navegabilidad

Las flechas indican si, dada una instancia que participa en una relación, es posible determinar las instancias de la otra clase que están relacionadas con ella.

El diagrama anterior sugiere que,

• Dada una hoja de cálculo, podemos ubicar todas las celdas que contiene, pero eso
  • no podemos determinar a partir de una celda en qué hoja de cálculo está contenida.
• Dada una celda, podemos obtener la expresión y el valor relacionados, pero
  • dado un valor (o expresión) no podemos encontrar la celda de la que esos son atributos.

Visibilidad de atributos de clase y operaciones

En el diseño orientado a objetos, existe una notación de visibilidad para atributos y operaciones. UML identifica cuatro tipos de visibilidad:  pública ,  protegida ,  privada y  de paquete .

Los símbolos +, -, # y ~ antes de un nombre de atributo y operación en una clase indican la visibilidad del atributo y la operación.

• + denota atributos públicos u operaciones
• – denota atributos privados u operaciones
• # denota atributos u operaciones protegidas
• ~ denota atributos u operaciones del paquete

Ejemplo de visibilidad de clase

En el ejemplo anterior:

• atributo1 y op1 de MyClassName son públicos
• atributo3 y op3 están protegidos.
• atributo2 y op2 son privados.

El acceso para cada uno de estos tipos de visibilidad se muestra a continuación para miembros de diferentes clases.

Multiplicidad

Cuántos objetos de cada clase participan en las relaciones y la multiplicidad se puede expresar como:

• Exactamente uno – 1
• Cero o uno – 0..1
• Muchos – 0..* o *
• Uno o más – 1..*
• Número exacto – por ejemplo, 3..4 o 6
• O una relación compleja, por ejemplo, 0..1, 3..4, 6.* significaría cualquier número de objetos distintos de 2 o 5

Ejemplo de multiplicidad

• Requisito: Un Estudiante puede tomar muchos Cursos y muchos Estudiantes pueden inscribirse en un Curso.
• En el siguiente ejemplo, el  diagrama de clases  (a la izquierda) describe la declaración del requisito anterior para el modelo estático, mientras que el diagrama de objetos (a la derecha) muestra la instantánea (una instancia del diagrama de clases) de la inscripción del curso para los cursos Ingeniería de Software y Gestión de Bases de Datos respectivamente)

Ejemplo de agregación: computadora y partes

• Una agregación es un caso especial de asociación que denota una jerarquía «consiste en»
• El agregado es la clase principal, los componentes son las clases secundarias

Ejemplo de herencia: taxonomía de celdas

• La herencia es otro caso especial de una asociación que denota una especie de jerarquía.
• La herencia simplifica el modelo de análisis al introducir una taxonomía
• Las clases secundarias heredan los atributos y operaciones de la clase principal.

Diagrama de clase: ejemplo de herramienta de diagrama

Un diagrama de clases también puede tener notas adjuntas a clases o relaciones. Las notas se muestran en gris.

En el ejemplo anterior:

Podemos interpretar el significado del diagrama de clases anterior leyendo los puntos de la siguiente manera.

1. La forma es una clase abstracta. Se muestra en cursiva.
2. La forma es una superclase. Círculo, Rectángulo y Polígono se derivan de Forma. En otras palabras, un círculo es una forma. Esta es una relación de generalización/herencia.
3. Existe una asociación entre DialogBox y DataController.
4. La forma es parte de la ventana. Esta es una relación de agregación. La forma puede existir sin Ventana.
5. El punto es parte del círculo. Esta es una relación de composición. El punto no puede existir sin un círculo.
6. La ventana depende del evento. Sin embargo, Event no depende de Window.
7. Los atributos de Circle son radio y centro. Esta es una clase de entidad.
8. Los nombres de los métodos de Circle son area(), circum(), setCenter() y setRadius().
9. El radio del parámetro en Circle es un parámetro de tipo float.
10. El método area() de la clase Circle devuelve un valor de tipo double.
11. Los atributos y nombres de métodos de Rectangle están ocultos. Algunas otras clases en el diagrama también tienen sus atributos y nombres de métodos ocultos.

Tratar con un sistema complejo: ¿diagrama de clase única o múltiple?

Inevitablemente, si está modelando un sistema grande o un área comercial grande, habrá numerosas entidades que deberá considerar. ¿Deberíamos usar un diagrama de clases múltiple o único para modelar el problema? La respuesta es:

• En lugar de modelar cada entidad y sus relaciones en un solo diagrama de clases, es mejor usar diagramas de clases múltiples.
• Dividir un sistema en múltiples diagramas de clases hace que el sistema sea más fácil de entender, especialmente si cada diagrama es una representación gráfica de una parte específica del sistema.

Perspectivas del diagrama de clases en el ciclo de vida del desarrollo de software

Podemos usar diagramas de clase en diferentes fases de desarrollo de un  ciclo de vida de desarrollo de software  y, por lo general, modelar diagramas de clase en tres perspectivas diferentes (niveles de detalle) progresivamente a medida que avanzamos:

Perspectiva conceptual : Los diagramas se interpretan como que describen cosas en el mundo real. Por lo tanto, si toma la perspectiva conceptual, dibuja un diagrama que representa los conceptos en el dominio en estudio. Estos conceptos se relacionarán naturalmente con las clases que los implementan. La perspectiva conceptual se  considera independiente del lenguaje .

Perspectiva de especificación : los diagramas se interpretan como una descripción de abstracciones o componentes de software con especificaciones e interfaces, pero sin compromiso con una implementación particular. Por lo tanto, si toma la perspectiva de la especificación, estamos  viendo las interfaces del software , no la implementación.

Perspectiva de implementación : Los diagramas se interpretan como una descripción de las implementaciones de software en una tecnología y un  lenguaje en particular . Por lo tanto, si toma la perspectiva de la implementación, estamos  viendo la implementación del software .