Diagrama de clase
| Tipos de diagramas UML |
|---|
| Diagramas estructurales UML |
| Diagramas de comportamiento UML |
|
Jerarquía de diagramas UML 2.5, que se muestra como un diagrama de clases. Las clases individuales están representadas con un solo compartimento, pero a menudo contienen hasta tres compartimentos. En ingeniería de software, un diagrama de clases en el Lenguaje de modelado unificado (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 las 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 el modelado de datos. Las clases en un diagrama de clases representan los elementos principales, las interacciones en la aplicación y las clases que se van a programar.
En el diagrama, las clases se representan con cajas que contienen tres compartimentos:
- El compartimento superior contiene el nombre de la clase. Está impreso en negrita y centrado, y la primera letra está en mayúscula.
- El compartimento del medio contiene los atributos de la clase. Están alineados a la izquierda y la primera letra está en minúscula.
- El compartimento inferior contiene las operaciones que puede ejecutar la clase. También están alineados a la izquierda y la primera letra está en minúscula.
Una clase con tres compartimentos. En el diseño de un sistema, se identifican varias clases y se agrupan 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 a menudo se dividen en subclases.
Para describir con más detalle el comportamiento de los sistemas, estos diagramas de clases pueden complementarse con un diagrama de estados o una máquina de estados UML.
- 1 miembros
- 1.1 Visibilidad
- 1.2 Alcance
- 2 Relaciones
- 2.1 Relaciones a nivel de instancia
- 2.1.1 Dependencia
- 2.1.2 Asociación
- 2.1.3 Agregación
- 2.1.4 Composición
- 2.1.5 Diferencias entre composición y agregación
- 2.2 Relaciones a nivel de clase
- 2.2.1 Generalización / Herencia
- 2.2.2 Realización / Implementación
- 2.3 Relación general
- 2.3.1 Dependencia
- 2.4 Multiplicidad
- 2.1 Relaciones a nivel de instancia
- 3 Estereotipos de análisis
- 3.1 Entidades
- 4 Ver también
- 5 referencias
- 6 Enlaces externos
Miembros
UML proporciona mecanismos para representar miembros de 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 anotaciones deben colocarse antes del nombre del miembro:
+ | Público |
- | Privado |
# | Protegido |
~ | Paquete |
Una propiedad derivada es una propiedad cuyo valor (o valores) se produce o se calcula a partir de otra información, por ejemplo, mediante el uso de valores de otras propiedades.
Una propiedad derivada se muestra con su nombre precedido por una barra diagonal '/'.
Alcance
UML especifica dos tipos de alcance para los miembros: instancia y clase, y este último está representado por nombres subrayados.
- Los miembros de la instancia tienen como ámbito una instancia específica.
- Los valores de los atributos pueden variar entre instancias
- La invocación del método puede afectar el estado de la instancia (es decir, cambiar los atributos de la instancia)
- Los miembros de la clase se reconocen comúnmente como "estáticos" en muchos lenguajes de programación. El ámbito es la propia clase.
- Los valores de los atributos son iguales para todas las instancias
- La invocación del método no afecta el estado del clasificador
Para indicar un alcance de clasificador para un miembro, su nombre debe estar subrayado. De lo contrario, el alcance de la instancia se asume de forma predeterminada.
Relaciones
Notación de relaciones UML 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 objetos y clases. UML define las siguientes relaciones:
Relaciones a nivel de instancia
Dependencia
Una dependencia es 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
Ejemplo de diagrama de clases de asociación entre dos clases Una asociación representa una familia de vínculos. Una asociación binaria (con dos extremos) normalmente se representa como una línea. Una asociación puede vincular cualquier número de clases. Una asociación con tres enlaces se denomina asociación ternaria. Se puede nombrar una asociación y los extremos de una asociación se pueden adornar con nombres de roles, indicadores de propiedad, multiplicidad, visibilidad y otras propiedades. Hay cuatro tipos diferentes de asociación: bidireccional, unidireccional, agregación (incluye agregación de composición) y reflexiva. Las asociaciones bidireccionales y unidireccionales son las más comunes. Por ejemplo, una clase de vuelo está asociada con una clase de avión bidireccionalmente. La asociación representa la relación estática compartida entre los objetos de dos clases.
Agregación
Diagrama de clases que muestra la agregación entre dos clases. Aquí, un profesor "tiene" una clase para enseñar. La agregación es una variante de la relación de asociación "tiene una"; 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' una clase que enseñar. Como tipo de asociación, una agregación se puede nombrar y tener los mismos adornos que una asociación. Sin embargo, una agregación no puede involucrar más de dos clases; debe ser una asociación binaria. Además, apenas hay una diferencia entre agregaciones y asociaciones durante la implementación, y el diagrama puede omitir las relaciones de agregación por completo.
La agregación puede ocurrir cuando una clase es una colección o un contenedor de otras clases, pero las clases contenidas no tienen una fuerte dependencia del ciclo de vida del contenedor. El contenido del contenedor todavía existe cuando se destruye el contenedor.
En UML, se representa gráficamente como una forma de diamante hueco en la clase contenedora con una sola línea que la conecta a 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.
Ejemplo: biblioteca y estudiantes. Aquí el estudiante puede existir sin biblioteca, la relación entre estudiante y biblioteca es agregación.
Composición
Diagramas de dos clases. El diagrama de la parte superior muestra la composición entre dos clases: un automóvil tiene exactamente un carburador y un carburador es parte de un automóvil. Los carburadores no pueden existir como partes separadas, separadas de un automóvil específico. El diagrama de la parte inferior muestra la agregación entre dos clases: un estanque tiene cero o más patos y un pato tiene como máximo un estanque (a la vez). El pato puede existir por separado de un estanque, por ejemplo, puede vivir cerca de un lago. Cuando destruimos un estanque, normalmente no matamos a todos los patos. La representación UML de una relación de composición muestra la composición como una forma de diamante relleno en el extremo de la clase contenedora de las líneas que conectan 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 partes enteras del mundo real, por ejemplo, un motor es parte de un automóvil.
- 2. Cuando se destruye el contenedor, también se destruye el contenido, por ejemplo, una universidad y sus departamentos.
- Relación de agregación
- 1. Cuando se representa una relación de software o base de datos, por ejemplo, el motor de modelo de automóvil ENG01 es parte de un modelo de automóvil CM01, ya que el motor, ENG01, también puede ser parte de un modelo de automóvil diferente.
- 2. Cuando se destruye el contenedor, el contenido generalmente no se destruye, por ejemplo, un profesor tiene estudiantes; cuando el profesor muere, los estudiantes no mueren con ellos.
Por lo tanto, la relación de agregación es a menudo contención "de catálogo" para distinguirla de la contención "física" de la composición.
Relaciones a nivel de clase
Generalización / Herencia
Diagrama de clases que muestra la generalización entre la superclase Persona y las dos subclases Estudiante y Profesor Indica que una de las dos clases relacionadas (la subclase) se considera una forma especializada de la otra (el súper tipo) y la superclase se considera una 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 simios, que es una subclase de mamíferos, etc. La relación se entiende más fácilmente por la frase "una A es una B" (un ser 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 con uno o más subtipos.
La relación de generalización también se conoce como herencia o relación "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 se conoce también como el "niño", subclase, clase derivada, tipo derivado, heredando clase, o heredar tipo.
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 inducir a error.
- 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 en 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 especifica el otro elemento del modelo (el proveedor).
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 encaje (los implementadores exponen una bola o piruleta, mientras que los usuarios muestran un encaje). Las realizaciones solo se pueden mostrar en diagramas de clases o componentes. Una realización es una relación entre clases, interfaces, componentes y paquetes que conecta un elemento de cliente con un elemento de proveedor. Una relación de realización entre clases / componentes e interfaces muestra que la clase / componente realiza las operaciones ofrecidas por la interfaz.
symbolic of realization -------▻
Relación general
Diagrama de clases que muestra la dependencia entre la clase "Coche" y la clase "Rueda" (un ejemplo aún más claro sería "El coche depende de la rueda", porque el coche ya agrega (y no solo usa) la rueda) Dependencia
La dependencia es una forma más débil de vínculo que indica que una clase depende de otra porque la usa 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. Esto es diferente de una asociación, donde un atributo de la clase dependiente es una instancia de la clase independiente. 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 función 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 una B" (una gata tiene gatitos, los gatitos tienen una 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 por la ubicación de una pelota, el papel que juegan los elementos de ese extremo al proporcionar un nombre para el papel, y la multiplicidad de instancias de esa entidad (el rango de la cantidad de objetos que participan en la asociación desde la perspectiva del otro extremo).
| 0 | Sin instancias (raro) |
| 0..1 | Sin instancias, o una instancia |
| 1 | Exactamente una instancia |
| 1..1 | Exactamente una instancia |
| 0.. * | Cero o más instancias |
| * | Cero o más instancias |
| 1.. * | Una o más instancias |
Estereotipos de análisis
Entidades
Las clases de entidad modelan la información de larga duración que maneja 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 de estereotipo de «entidad» sobre el nombre de la clase.
Ver también
- Diagramas relacionados
Referencias
enlaces externos
 | Wikimedia Commons tiene medios relacionados con Diagrama de clases. |
