stringtranslate.com

Diagrama de clases

Jerarquía de diagramas UML 2.5, mostrada como un diagrama de clases. Las clases individuales se representan con un solo compartimento, pero a menudo contienen hasta tres compartimentos.

En ingeniería de software , un diagrama de clases [1] 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 los 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 en código de programación . Los diagramas de clases también se pueden utilizar para el modelado de datos . [2] Las clases en un diagrama de clases representan tanto 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:

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 suelen dividirse en subclases. [3]

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

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 notaciones deben colocarse antes del nombre del miembro: [5]

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 '/'. [6]

Alcance

El UML especifica dos tipos de ámbito para los miembros: instancia y clase . El nombre de la clase aparece como una concatenación subrayada del nombre de la instancia (si existe), dos puntos (':') y el nombre de la clase real. [1]

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

Relaciones

Notación de relaciones UML

Una relación es un término general que abarca 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 en la que existe una conexión semántica entre elementos del modelo dependientes e independientes. [7] Existe entre dos elementos si los cambios en la definición de un elemento (el servidor o el destino) pueden provocar 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 desde el cliente hasta el proveedor.

Asociación

Diagrama de clases, ejemplo de asociación entre dos clases

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 rombo 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 denomina 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. [8]

Existen tres tipos de asociación: asociación simple, agregación compartida y agregación compuesta (composición). Una asociación puede ser navegable en una o más direcciones. La navegabilidad no tiene que especificarse explícitamente. Una flecha con la punta abierta en el lateral 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 del lado de la clase al que no se puede acceder. Por ejemplo, una clase de vuelo se asocia con una clase de avión de manera bidireccional.

Agregación

Diagrama de clases que muestra la agregación entre dos clases. Aquí, un profesor "tiene una" clase que 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 puede tener nombre y 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, casi no hay diferencia entre agregaciones y asociaciones durante la implementación, y el diagrama puede omitir las relaciones de agregación por completo. [9]

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 dependencia fuerte del ciclo de vida con respecto al contenedor. El contenido del contenedor sigue existiendo cuando este se destruye.

En UML , se representa gráficamente como un rombo hueco sobre la clase contenedora con una sola línea que lo 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.

Composición

Dos diagramas de clases. El diagrama de arriba 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 abajo 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). Un 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 relación de agregación compuesta (coloquialmente llamada composición) es una forma más sólida de agregación en la que el agregado controla el ciclo de vida de los elementos que agrega. La representación gráfica es una forma de diamante rellena en el extremo de la línea que conecta la clase o clases contenidas con la clase contenedora.

Diferencias entre composición y agregación

Relación de composición
1. Al intentar representar relaciones entre un todo y una parte en el mundo real, por ejemplo, un motor es una 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. Al representar una relación de software o base de datos, por ejemplo, el motor del 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. [10]
2. Cuando se destruye el contenedor, normalmente no se destruye el contenido, p. ej., un profesor tiene estudiantes; cuando el profesor deja la universidad, los estudiantes no se van junto con el profesor.

Por lo tanto, la relación de agregación es a menudo una contención de "catálogo" para distinguirla de la contención "física" de la composició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

Diagrama de clases que muestra la generalización entre la superclase Persona y las dos subclases Estudiante y Profesor

Esto 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 una generalización de la subclase. En la práctica, esto significa que cualquier instancia del subtipo también es 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 los simios , que es una subclase de los mamíferos , y así sucesivamente. La relación se entiende más fácilmente con la frase 'un A es un 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) _______▻ (superclase)

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

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 "hijo" , subclase , clase derivada , tipo derivado , clase heredada o tipo heredero .

Téngase en cuenta que esta relación no tiene ningún parecido con la relación biológica padre-hijo: el uso de estos términos es extremadamente común, pero puede ser 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 sólo 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 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 a sus usuarios. En los diagramas de componentes, se utiliza la convención gráfica de rótula (los implementadores exponen una pelota o piruleta, mientras que los usuarios muestran una rótula). 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 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 (implementador) -------▻ (interfaz)

Relación general

Diagrama de clases que muestra la dependencia entre la clase "Auto" y la clase "Rueda" (Un ejemplo aún más claro sería "Auto depende de Combustible", porque Auto ya agrega (y no solo usa ) Rueda)

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. En cambio, pueden 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 suele describirse 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, mediante una punta de flecha, que el extremo puntiagudo es visible desde la cola de la flecha. Podemos indicar la propiedad mediante la colocación de una pelota, el papel que desempeñan los elementos de ese extremo proporcionando un nombre para el papel y la multiplicidad de instancias de esa entidad (el rango de número de objetos que participan en la asociación desde la perspectiva del otro extremo).

Análisis de estereotipos

Entidades

Las clases de entidad modelan 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 estereotipada «entidad» sobre el nombre de la clase.

Véase también

Diagramas relacionados

Referencias

  1. ^ ab "Clases". Lenguaje de modelado unificado 2.5.1. Número de documento OMG formal/2017-12-05. Organización de desarrollo de estándares del Object Management Group (OMG SDO). Diciembre de 2017. pág. 194.
  2. ^ Sparks, Geoffrey. "Modelado de bases de datos en UML" . Consultado el 8 de septiembre de 2011 .
  3. ^ Flatt, Amelie; Langner, Arne; Leps, Olof (2022), "Fase I: Asignación de conceptos legales a objetos técnicos" , Desarrollo basado en modelos de perfiles de aplicaciones de Akoma Ntoso , Cham: Springer International Publishing, págs. 13-17, doi :10.1007/978-3-031-14132-4_3, ISBN 978-3-031-14131-7, consultado el 7 de enero de 2023
  4. ^ Scott W. Ambler (2009) Diagramas de clases UML 2. Webdoc 2003-2009. Consultado el 2 de diciembre de 2009.
  5. ^ Ficha de referencia UML, versión 2.1.2, Holub Associates, agosto de 2007 , consultado el 12 de marzo de 2011
  6. ^ "Una propiedad derivada de UML es una propiedad cuyo valor se produce o calcula a partir de otra información, por ejemplo, mediante el uso de otras propiedades". www.uml-diagrams.org . Consultado el 24 de enero de 2019 .
  7. ^ Fowler (2003) UML Distilled: Una breve guía para el lenguaje de modelado de objetos estándar
  8. ^ Selic, Bran (18 de abril de 2013). "Cómo hacerlo bien en el punto" (PDF) . www.omg.org . Object Management Group . Consultado el 26 de noviembre de 2023 .
  9. ^ "Tutorial UML parte 1: diagramas de clases" (PDF) . Archivado desde el original (PDF) el 2007-01-03 . Consultado el 2015-07-18 .
  10. ^ Goodwin, David. "Modelling and Simulation, p. 26" (PDF) . The University of Warwick . Consultado el 28 de noviembre de 2015 .

Enlaces externos