Diagrama de clases ( ing. class diagram ) - un diagrama estructural del lenguaje de modelado UML , que demuestra la estructura general de la jerarquía de clases del sistema , sus cooperaciones, atributos (campos), métodos , interfaces y relaciones (relaciones) entre ellos. Es ampliamente utilizado no solo para documentación y visualización, sino también para diseñar mediante ingeniería directa o inversa [1] .
El propósito de crear un diagrama de clases es una representación gráfica de la estructura estática de los elementos declarativos del sistema (clases, tipos , etc.) También contiene algunos elementos de comportamiento (por ejemplo, operaciones), pero su dinámica debe reflejarse en diagramas de otro tipo ( diagramas de comunicación, diagramas de estado). Para facilitar la percepción, el diagrama de clases también se puede complementar con una representación de paquetes , incluidos los [2] anidados .
Al representar entidades en el mundo real, el desarrollador debe reflejar su estado actual, su comportamiento y sus relaciones mutuas. En cada etapa, la abstracción se hace a partir de detalles sin importancia y conceptos que no se aplican a la realidad (rendimiento, encapsulamiento , visibilidad , etc.). Las clases se pueden ver desde la perspectiva de diferentes niveles. Por regla general, se distinguen por tres principales: el nivel analítico, el nivel de diseño y el nivel de implementación [3] :
El diagrama de clases es un elemento clave en el modelado orientado a objetos. En el diagrama, las clases se presentan en cajas que contienen tres componentes:
UML proporciona mecanismos para representar a los miembros de la clase, como atributos y métodos, e información adicional sobre ellos.
Para establecer la visibilidad de los miembros de la clase (es decir, para cualquier atributo o método), estos símbolos deben colocarse antes del nombre del miembro: [4]
| + | Público |
| - | Privado (Privado) |
| # | Protegido |
| / | Derivado (se puede combinar con otros) |
| ~ | Paquete |
El UML define dos tipos de ámbitos para los miembros: instancia y clasificador , este último con nombres subrayados . [5]
El nombre está subrayado para indicar la pertenencia al clasificador ; de lo contrario, se supone que el ámbito es el ámbito predeterminado.
Una relación es un tipo especial de relación lógica entre entidades, que se muestra en diagramas de clases y objetos . El UML tiene los siguientes tipos de relaciones:
Dependencia denota una relación entre clases tal que un cambio en la especificación de la clase proveedora puede afectar el trabajo de la clase dependiente, pero no viceversa.
AsociaciónUna asociación muestra que los objetos de una entidad (clase) están asociados con objetos de otra entidad de tal manera que puede pasar de objetos de una clase a otra. Es un caso general de composición y agregación.
Por ejemplo, la clase Persona y la clase Escuela tienen una asociación, ya que una persona puede estudiar en una escuela. Una asociación puede recibir el nombre de "estudios en".
Las asociaciones dobles están representadas por una línea sin flechas en los extremos, que conecta dos bloques de clase. Las asociaciones de mayor grado tienen más de dos extremos y están representadas por líneas, un extremo de los cuales va al bloque de clase y el otro al rombo común. En la vista de asociación unidireccional, se agrega una flecha para indicar la dirección de la asociación.
Se puede nombrar una asociación y se pueden etiquetar roles, afiliaciones, indicadores, multiplicadores, visibilidad u otras propiedades al final de la línea que la representa.
AgregaciónLa agregación es un tipo de asociación en la relación entre el todo y sus partes. Como tipo de asociación, se puede nombrar una agregación. Una relación de agregación no puede incluir más de dos clases (contenedor y contenido).
La agregación ocurre cuando una clase es una colección o contenedor de otras. Y por defecto, la agregación se llama agregación por referencia , es decir, cuando la vida útil de las clases contenidas no depende de la vida útil de la clase contenedora. Si el contenedor se destruye, entonces su contenido no lo es.
Gráficamente, una agregación se representa mediante un rombo vacío en un cuadro de clase y una línea desde ese rombo hasta la clase que lo contiene.
ComposiciónLa composición es una versión más estricta de la agregación. También conocido como agregación por valor.
La composición tiene una fuerte dependencia de la vida útil de las instancias de la clase contenedora y las instancias de la clase contenida. Si se destruye el contenedor, también se destruirá todo su contenido.
Representado gráficamente como agregación, pero con un rombo relleno.
Diferencias entre composición y agregaciónTomemos un ejemplo ilustrativo. La habitación es parte del apartamento, por lo que la composición es adecuada aquí, porque la habitación no puede existir sin un apartamento. Y, por ejemplo, los muebles no son una parte integral del apartamento, pero al mismo tiempo, el apartamento contiene muebles, por lo que se debe usar la agregación.
La generalización muestra que una de las dos clases relacionadas ( subtipo ) es una forma especial de la otra ( supertipo ), lo que se denomina generalización de la primera. En la práctica, esto significa que cualquier instancia del subtipo es también una instancia del supertipo. Por ejemplo: los animales son el supertipo de los mamíferos, que a su vez son el supertipo de los primates, y así sucesivamente. Esta relación se describe más fácilmente con la frase "A es B" (los primates son mamíferos, los mamíferos son animales).//
Gráficamente, la generalización está representada por una línea con un triángulo vacío en el supertipo.
La generalización también se conoce como herencia o relación " es una " (o relación "es una").
ImplementaciónLa implementación es una relación entre dos elementos del modelo, en la que un elemento ( cliente ) implementa el comportamiento especificado por el otro ( proveedor ). La realización es una relación de todo-parte. Gráficamente, la implementación se representa de la misma forma que la herencia, pero con una línea de puntos.
Un proveedor suele ser una clase abstracta o una clase de interfaz.
Una dependencia es una forma débil de relación de uso en la que un cambio en la especificación de uno implica un cambio en la especificación del otro sin necesariamente revertirse. Ocurre cuando aparece un objeto, por ejemplo, en forma de parámetro o variable local.
Representado gráficamente por una flecha discontinua que va del elemento dependiente al elemento del que depende.
Hay varias variantes con nombre.
Una dependencia puede ser entre instancias, clases o una instancia y una clase.
Refinamientos de relacionesEl refinamiento tiene que ver con el nivel de detalle. Un paquete refina otro si contiene los mismos elementos pero en una representación más detallada. Por ejemplo, al escribir un libro, probablemente comenzará formulando una oración que resuma brevemente el contenido de cada capítulo. Supongamos que el resumen de cada capítulo se incluye como un elemento separado en el paquete "Propuesta". Supongamos también que "Libro completo" es un paquete cuyos elementos son capítulos completos. En este contexto, el paquete "Libro Completo" es un refinamiento del paquete "Oferta".
Poder de las relaciones (Multiplicidad)La cardinalidad de la relación (multiplicador) significa el número de enlaces entre cada instancia de clase (objeto) al principio de la línea con la instancia de clase al final. Existen los siguientes casos típicos:
| notación | explicación | ejemplo |
| 0..1 | Cero o una instancia | El gato tiene dueño. |
| una | Se requiere una copia | gato tiene una madre |
| 0..* o * | Cero o más instancias | un gato puede o no tener gatitos |
| una..* | Una o más instancias | un gato tiene al menos un lugar donde duerme |
| Lenguaje de modelado unificado | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||
| |||||||||||
| |||||||||||