Diagrama de clase

En ingeniería de software, un diagrama de clases en el Lenguaje Unificado de Modelado (UML) es un tipo de diagrama de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos) y relaciones entre objetos.

El diagrama de clases es el componente principal del modelado orientado a objetos. Se utiliza para el modelado conceptual general de la estructura de la aplicación y para el modelado detallado, traduciendo los modelos a código de programación. Los diagramas de clases también se pueden utilizar para modelar datos. Las clases en un diagrama de clases representan tanto los elementos principales, las interacciones en la aplicación y las clases a programar.

En el diagrama, las clases se representan con cuadros que contienen tres compartimentos:

• El compartimiento superior contiene el nombre de la clase. Se imprime en negrita y centrada, y la primera letra es capitalizada.
• El compartimiento medio contiene los atributos de la clase. Están alineados a la izquierda y la primera letra es minúscula.
• El compartimiento inferior contiene las operaciones que la clase puede ejecutar. También se alinean con la izquierda y la primera letra es minúscula.

En el diseño de un sistema, se identifican y agrupan varias clases en un diagrama de clases que ayuda a determinar las relaciones estáticas entre ellas. En el modelado detallado, las clases del diseño conceptual suelen dividirse en subclases.

Para describir mejor el comportamiento de los sistemas, estos diagramas de clases se pueden complementar con un diagrama de estados o una máquina de estados UML.

Miembros

UML proporciona mecanismos para representar miembros de una clase, como atributos y métodos, e información adicional sobre ellos, como constructores.

Visibilidad

Para especificar la visibilidad de un miembro de la clase (es decir, cualquier atributo o método), estas notaciones deben colocarse antes de los miembros' nombre:

<table class="wikitable+Público -Privado #Protegido ~Paquete

Una propiedad derivada es una propiedad cuyo valor (o valores) se produce o calcula a partir de otra información, por ejemplo, utilizando valores de otras propiedades.

Una propiedad derivada se muestra con su nombre precedido por una barra diagonal '/'.

Alcance

El UML especifica dos tipos de ámbito para los miembros: instancia y clase, y este último está representado por nombres subrayados.

• Miembros de urgencia se encuentran en una instancia específica.
  • Los valores atributos pueden variar entre casos
  • La invocación del método puede afectar el estado de la instancia (es decir, los atributos de la instancia de cambio)
• Miembros de clase son comúnmente reconocidos como "estáticos" en muchos lenguajes de programación. El objetivo es la clase misma.
  • Los valores atributos son iguales para todos los casos
  • El método de invocación no afecta al estado del clasificador

Para indicar el alcance del clasificador para un miembro, su nombre debe estar subrayado. De lo contrario, el alcance de la instancia se asume de forma predeterminada.

Relaciones

Una relación es un término general que cubre los tipos específicos de conexiones lógicas que se encuentran en los diagramas de clases y objetos. UML define las siguientes relaciones:

Relaciones a nivel de instancia

Dependencia

Una dependencia es un tipo de asociación donde existe una conexión semántica entre elementos del modelo dependientes e independientes. Existe entre dos elementos si los cambios en la definición de un elemento (el servidor o el destino) pueden causar cambios en el otro (el cliente o la fuente). Esta asociación es unidireccional. Una dependencia se muestra como una línea discontinua con una flecha abierta que apunta del cliente al proveedor.

Asociación

Una asociación representa una familia de vínculos estructurales. Una asociación binaria se representa como una línea continua entre dos clases. Una asociación reflexiva es una asociación binaria entre la clase y ella misma. Una asociación entre más de dos clases se representa como un diamante conectado con una línea continua a cada una de las clases asociadas. Una asociación entre tres clases es una asociación ternaria. Una asociación entre más clases se llama asociación n-aria.

Se puede nombrar una asociación y los extremos de una asociación se pueden adornar con nombres de roles, indicadores de agregación, multiplicidad, visibilidad, navegabilidad y otras propiedades. La notación de puntos, por ejemplo, permite representar con un pequeño punto en el lado de una clase que el extremo de la asociación es propiedad del otro lado.

Hay tres tipos de asociación: asociación simple, agregación compartida, agregación compuesta (composición). Una asociación puede ser navegable en una o más direcciones. No es necesario especificar explícitamente la navegabilidad. Una flecha con punta abierta en el costado de una clase documenta que se puede acceder a la clase de manera eficiente en tiempo de ejecución desde el lado opuesto. Una navegación unidireccional se muestra con una pequeña cruz en la línea de asociación en el lado de la clase a la que no se puede llegar. Por ejemplo, una clase de vuelo está asociada a una clase de avión de forma bidireccional.

Agregación

Agregación es una variante de la función "tiene un" relación de asociación; La agregación es más específica que la asociación. Es una asociación que representa una relación parte-todo o parte de. Como se muestra en la imagen, un profesor 'tiene un' clase para enseñar. Como tipo de asociación, una agregación puede tener nombre y tener los mismos adornos que una asociación. Sin embargo, una agregación no podrá involucrar más de dos clases; debe ser una asociación binaria. Además, apenas hay diferencia entre agregaciones y asociaciones durante la implementación, y el diagrama puede omitir por completo las relaciones de agregación.

La

agregación puede ocurrir cuando una clase es una colección o contenedor de otras clases, pero las clases contenidas no tienen una dependencia del ciclo de vida fuerte en el contenedor. El contenido del contenedor todavía existe cuando se destruye el contenedor.

En UML, se representa gráficamente como una forma de diamante hueca en la clase contenedora con una sola línea que la conecta con la clase contenida. El agregado es semánticamente un objeto extendido que se trata como una unidad en muchas operaciones, aunque físicamente está formado por varios objetos menores.

Composición

La relación de agregación compuesta (coloquialmente llamada composición) es una forma más fuerte de agregación donde el agregado controla el ciclo de vida de los elementos que agrega. La representación gráfica es una forma de diamante relleno en el extremo de la clase contenedora de la línea que conecta las clases contenidas con la clase contenedora.

Diferencias entre composición y agregación

Relación de composición

1. Al intentar representar relaciones de todo el mundo real, por ejemplo, un motor es parte de un coche.

2. Cuando el contenedor es destruido, el contenido también se destruye, por ejemplo, una universidad y sus departamentos.

Relación de agregación

1. Al representar una relación de software o de base de datos, por ejemplo, motor de modelo de coche ENG01 es parte de un modelo de coche CM01, como el motor, ENG01, tal vez también parte de un modelo de coche diferente.

2. Cuando el contenedor es destruido, el contenido generalmente no se destruye, por ejemplo, un profesor tiene estudiantes; cuando el profesor sale de la universidad los estudiantes no salen junto con el profesor.

Por lo tanto, la relación de agregación suele ser de tipo "catálogo" contención para distinguirla de la contención "física" de la composición. contención. UML 2 no especifica ninguna semántica para la agregación en comparación con la asociación simple.

Relaciones a nivel de clase

Generalización/Herencia

Indica que una de las dos clases relacionadas (la subclase) se considera una forma especializada de la otra (el supertipo) y la superclase se considera a Generalización de la subclase. En la práctica, esto significa que cualquier instancia del subtipo es también una instancia de la superclase. Un árbol ejemplar de generalizaciones de esta forma se encuentra en la clasificación biológica: los humanos son una subclase de simio, que a su vez es una subclase de mamífero, y así sucesivamente. La relación se entiende más fácilmente con la frase "una A es una B". (un humano es un mamífero, un mamífero es un animal).

La representación gráfica UML de una generalización es una forma de triángulo hueco en el extremo de la superclase de la línea (o árbol de líneas) que la conecta a uno o más subtipos.

 simbólico de realización (subclase) ______ (superclass)

La relación de generalización también se conoce como relación herencia o "es una".

La superclase (clase base) en la relación de generalización también se conoce como "padre", superclase, clase base o tipo base.

El subtipo en la relación de especialización también se conoce como "niño", subclase, derivado. clase, tipo derivado, clase heredera o tipo heredado.

Tenga en cuenta que esta relación no se parece en nada a la relación biológica entre padres e hijos: el uso de estos términos es extremadamente común, pero puede resultar engañoso.

A es un tipo de B

Por ejemplo, "un roble es un tipo de árbol", "un automóvil es un tipo de vehículo"

La generalización solo se puede mostrar en diagramas de clases y diagramas de casos de uso.

Realización/Implementación

En el modelado UML, una relación de realización es una relación entre dos elementos del modelo, en la que un elemento del modelo (el cliente) realiza (implementa o ejecuta) el comportamiento que el otro elemento del modelo (el proveedor) especifica.

La representación gráfica UML de una Realización es una forma de triángulo hueco en el extremo de la interfaz de la línea discontinua (o árbol de líneas) que la conecta a uno o más implementadores. Se utiliza una punta de flecha simple en el extremo de la interfaz de la línea discontinua que la conecta con sus usuarios. En los diagramas de componentes, se utiliza la convención gráfica de bola y cavidad (los implementadores exponen una bola o paleta, mientras que los usuarios muestran una cavidad). Las realizaciones sólo se pueden mostrar en diagramas de clases o de componentes. Una realización es una relación entre clases, interfaces, componentes y paquetes que conecta un elemento cliente con un elemento proveedor. Una relación de realización entre clases/componentes e interfaces muestra que la clase/componente realiza las operaciones ofrecidas por la interfaz.

 simbólico de realización (implementer) -----▻ (interface)

Relación general

Dependencia

La dependencia puede ser una forma más débil de vínculo que indica que una clase depende de otra porque la utiliza en algún momento. Una clase depende de otra si la clase independiente es una variable de parámetro o una variable local de un método de la clase dependiente. A veces la relación entre dos clases es muy débil. No se implementan con variables miembro en absoluto. Más bien, podrían implementarse como argumentos de funciones miembro.

Multiplicidad

Esta relación de asociación indica que (al menos) una de las dos clases relacionadas hace referencia a la otra. Esta relación generalmente se describe como "A tiene un B" (una madre gata tiene gatitos, los gatitos tienen una madre gata).

La representación UML de una asociación es una línea que conecta las dos clases asociadas. En cada extremo de la línea hay una notación opcional. Por ejemplo, podemos indicar, usando una punta de flecha, que el extremo puntiagudo es visible desde la cola de la flecha. Podemos indicar la propiedad mediante la ubicación de una pelota, el papel que desempeñan los elementos de ese fin proporcionando un nombre para el papel y la multiplicidad de instancias de esa entidad (el rango de cantidad de objetos que participar en la asociación desde la perspectiva del otro extremo).

0	No instances (rare)
0.1	No hay casos ni una instancia
1	Exactamente una instancia
1..1	Exactamente una instancia
0.. *	Cero o más casos
*	Cero o más casos
1.. *	Uno o más casos

Estereotipos de análisis

Entidades

Las clases de entidad modelan la información de larga duración manejada por el sistema y, a veces, el comportamiento asociado con la información. No deben identificarse como tablas de bases de datos u otros almacenes de datos.

Se dibujan como círculos con una línea corta unida a la parte inferior del círculo. Alternativamente, se pueden dibujar como clases normales con la notación estereotipada de «entidad» encima del nombre de la clase.