Prefacio
Hay muchos tipos de diagramas UML, pero no es necesario dominar todos los diagramas UML para completar el trabajo de diseño y análisis del sistema. En términos generales, en los diagramas UML, siempre que domine el uso de diagramas de clases, diagramas de casos de uso y diagramas de secuencia, podrá completar la mayor parte del trabajo . En otras palabras, si dominas el 20% de UML, puedes hacer el 80% de las cosas. Para los programadores, el más utilizado es el diagrama de clases .
Tabla de contenido
1. ¿Qué es un diagrama de clases?
2. Representación de clases en diagramas de clases.
3. Representación de clases, abstracciones, interfaces y paquetes concretos en diagramas de clases.
Representar clases concretas en diagramas de clases UML.
Representar clases abstractas en diagramas de clases UML
Representar interfaces en diagramas de clases UML
Representar paquetes en diagramas de clases UML
4. Representación de relaciones en diagramas de clases.
La diferencia entre agregación y composición en el desarrollo de Java.
1. ¿Qué es un diagrama de clases?
El diagrama de clases es el diagrama más utilizado e importante en el modelado de sistemas orientado a objetos y es la base para definir otros diagramas. El diagrama de clases es principalmente un modelo estático que se utiliza para mostrar las clases, las interfaces del sistema y las estructuras estáticas y las relaciones entre ellas. Los elementos más básicos de un diagrama de clases son las clases y las interfaces. Después de que el diseñador de software diseña el diagrama de clases, el programador puede usar código para implementar el contenido del diagrama de clases.
2. Representación de clases en diagramas de clases.
El icono de clase consta de tres partes : la primera parte es el nombre de la clase , la segunda parte son los atributos y la tercera parte es la operación.
- "+" significa
public;- "-" significa
private;- "#" significa
protected;- Representado sin símbolos
default
Un nombre de clase es único dentro de su espacio de nombres. Los nombres de las clases comienzan con una letra mayúscula , omitiendo espacios entre varias palabras.
Las propiedades y operaciones deben ser inequívocas dentro del alcance de la clase. Los atributos y operaciones comienzan con una letra minúscula , la primera letra de las palabras siguientes está en mayúscula y también se omiten los espacios.
- Formato de especificación de propiedad :
Nombre de propiedad de visibilidad: tipo[multiplicidad] = predeterminado{cadena de propiedad}
- Formato de especificación de operación :
Nombre de la operación de visibilidad (nombre del parámetro: tipo): valor de retorno {cadena de propiedad}
3. Representación de clases, abstracciones, interfaces y paquetes concretos en diagramas de clases.
Representar clases concretas en diagramas de clases UML.
Una clase específica está representada por un cuadro rectangular en el diagrama de clases, que se divide en tres capas: la primera capa es el nombre de la clase. El segundo nivel son las variables miembro de la clase; el tercer nivel son los métodos de la clase. Las variables miembro y los modificadores de acceso antes de los métodos se representan mediante símbolos:
Representar clases abstractas en diagramas de clases UML
Las clases abstractas también se representan mediante cuadros rectangulares en los diagramas de clases UML, pero los nombres de las clases y los nombres de los métodos abstractos de las clases abstractas se representan en cursiva.
Representar interfaces en diagramas de clases UML
La interfaz también está representada por un cuadro rectangular en el diagrama de clases, pero lo que se diferencia de la representación de la clase es que la interfaz está representada por el constructor <<interfaz>> en la parte superior de la primera capa del diagrama de clases. A continuación se muestra el nombre de la interfaz y la segunda capa es el método.
Además, hay otra representación de la interfaz, comúnmente conocida como representación de paleta, que es una paleta (círculo + línea continua) encima de la clase. Al lado del círculo está el nombre de la interfaz y los métodos de la interfaz aparecen en la clase de implementación.
Representar paquetes en diagramas de clases UML
Las clases e interfaces generalmente aparecen en paquetes. La representación de paquetes en diagramas de clases UML
4. Representación de relaciones en diagramas de clases.
Existe una cierta relación entre clases, clases e interfaces e interfaces, y generalmente hay conexiones en los diagramas de clases UML para indicar las relaciones entre ellas. Hay seis tipos de relaciones, a saber, relaciones de implementación, relaciones de generalización, relaciones de asociación, relaciones de dependencia, relaciones de agregación y relaciones de combinación.
darse cuenta de la relación
La relación de implementación se refiere a la relación entre la interfaz y su clase de implementación. En los diagramas de clases UML, las relaciones de implementación se representan mediante flechas compuestas de triángulos huecos y líneas de puntos, que apuntan desde la clase de implementación a la interfaz. En el código Java, las relaciones de implementación se pueden traducir directamente en palabras clave. implements
relación de generalización
La generalización se refiere a la relación de herencia entre objetos. Si se establece la relación "es un" entre el objeto A y el objeto B, entonces existe una relación de herencia entre los dos: el objeto B es el objeto padre y el objeto A es el objeto hijo. Por ejemplo, si un empleado con salario anual "es un" empleado, es obvio que existe una relación de herencia entre el objeto Salario del empleado con salario anual y el objeto Empleado. El objeto Empleado es el objeto principal y el objeto Salario es el hijo. objeto.
En el diagrama de clases UML, la relación de generalización está representada por una flecha compuesta por un triángulo abierto y una línea continua, que apunta desde la clase secundaria a la clase principal. En el código Java, las relaciones generalizadas entre objetos se pueden traducir directamente a palabras clave extends.
relación de conexión
La asociación se refiere a la conexión entre objetos, que permite que un objeto conozca las propiedades y métodos de otro objeto. En Java, la representación en código de una asociación es que un objeto contiene una referencia a otro objeto. En otras palabras, si el código de clase de un objeto contiene una referencia a otro objeto, entonces los dos objetos están asociados.
Hay asociaciones unidireccionales y asociaciones bidireccionales. Si dos objetos conocen (es decir, pueden llamar) las propiedades y operaciones públicas del otro, entonces los dos objetos tienen una asociación bidireccional. Si sólo un objeto conoce (es decir, puede llamar) las propiedades y operaciones públicas de otro objeto, entonces se trata de una asociación unidireccional. La mayoría de las asociaciones son asociaciones unidireccionales, que son más fáciles de establecer y mantener y ayudan a encontrar clases reutilizables.
También existe una autocorrelación entre las dos asociaciones.
En los diagramas UML, las relaciones bidireccionales se representan mediante líneas continuas con flechas dobles o líneas dobles continuas sin flechas. Una asociación unidireccional está representada por una línea continua con una flecha que apunta al objeto que se asocia. Esto es navegación (Navegatity).
Lo siguiente indica que Empleado está asociado con TimeCard, que es una asociación unidireccional.
Un objeto puede contener una matriz o colección de otros objetos. En UML, esto se representa colocando una expresión de multiplicidad al final de la línea de asociación. Una expresión de multiplicidad puede ser un número, un rango o una combinación de ellos. Ejemplos de expresiones permitidas por multiplicidad son:
- Número: Cantidad exacta
*O0..*: significa 0 a más0..1: representa 0 o 1, a menudo implementado con una referencia nula en Java1..*: Indica de 1 a múltiple
Las relaciones de asociación se dividen en tres tipos: asociación de dependencia, asociación de agregación y asociación combinada.
Dependencias
La relación de dependencia es una relación de asociación débil. Si el objeto A usa el objeto B, pero la relación con B no es demasiado obvia, esta relación puede considerarse como una relación de dependencia. Si el objeto A depende del objeto B, entonces A "usa a" B. Por ejemplo, la relación entre un conductor y un automóvil: cuando el conductor usa el automóvil, existe una relación de dependencia entre los dos.
En el diagrama de clases UML, la relación de dependencia está representada por una flecha punteada, que apunta desde el usuario a la parte utilizada, lo que indica que el objeto del usuario tiene una referencia al objeto utilizado.
La expresión de código específica de dependencia en Java es que B es una variable local en el constructor o método de A , un parámetro de un método o constructor , el valor de retorno de un método , o A llama a un método estático de B.
A continuación utilizamos el código Java que se muestra en el Listado de código 1 y el Listado de código 2 para demostrar la dependencia entre objetos y objetos.
代码清单1所示的B类定义了一个成员变量 field1，一个普通方法 method1() 和一个静态方法 method2()。
//代码清单1 B.java
public class B {
public String field1; //成员变量
public void method1() {
System.println("在类B的方法1中");
}
public static void method2() { //静态方法
System.out.println("在类B的静态方法2中");
}
}
代码清单2所示的A类依赖于B类，在A类中定义了四个方法，分别演示四种依赖形式。
/* 代码清单2 A.java
A依赖于B
*/
public class A {
public void method1() {
//A依赖于B的第一种表现形式：B为A的局部变量
B b = new B();
b.method1();
}
public void method2() {
//A依赖于B的第二种表现形式： 调用B的静态方法
B.method2();
}
public void method3(B b) {
//A依赖于B的第三种表现形式：B作为A的方法参数
String s = b.field1;
}
//A依赖于B的第四种表现形式：B作为A的方法的返回值
public B method4() {
return new B();
}
}relación de agregación
La agregación es un caso especial de relación de asociación, que refleja la relación de propiedad entre el todo y la parte, es decir, la relación "tiene". En este momento, el todo y las partes son separables. Pueden tener sus propios ciclos de vida ( al igual que los automóviles y los neumáticos, cuando el automóvil se destruye, no significa que los neumáticos también se destruyan ) . Las partes pueden pertenecer a múltiples enteros. objetos También puede ser compartido por múltiples objetos generales, por lo que las relaciones de agregación a menudo se denominan relaciones de compartición. Por ejemplo, en la relación entre los departamentos de la empresa y los empleados, un empleado puede pertenecer a varios departamentos y, si se retira un departamento, los empleados pueden transferirse a otros departamentos.
En el diagrama UML, la relación de agregación está representada por un diamante hueco más una flecha sólida. El diamante hueco está en todo el lado y la flecha apunta al lado parcial.
Relación de combinación
La composición es también un caso especial de asociación y también encarna la relación de inclusión entre el todo y sus partes, es decir, la relación "contiene un". Pero en este momento, el todo y la parte son inseparables, y la parte no se puede compartir con otros todos.El objeto en su conjunto es responsable del ciclo de vida del objeto parcial. Esta relación es más fuerte que la agregación y también se denomina agregación fuerte. Si Ase combinan B, Aes necesario conocer Bla vida útil, que puede ser Aresponsable de la generación o la versión B, o Aconocer la generación y la versión de alguna manera B.
Por ejemplo, una persona contiene cabeza, tronco y extremidades, y sus ciclos de vida son consistentes. Cuando una persona nace, la cabeza, el tronco y las extremidades nacen al mismo tiempo. Cuando una persona muere, la cabeza, el tronco y las extremidades que forman parte del cuerpo humano mueren al mismo tiempo.
En el diagrama UML, la relación de combinación está representada por un diamante sólido más una flecha sólida. El diamante sólido está en todo el lado y la flecha apunta al lado parcial.
La diferencia entre agregación y composición en el desarrollo de Java.
En forma de código Java, los objetos parciales en la relación de agregación y combinación son una variable miembro del objeto general. Sin embargo, en el desarrollo de aplicaciones reales, a veces es difícil distinguir si la relación entre dos objetos es una agregación o una combinación. En Java, la agregación y la composición no se pueden distinguir del código de clase en sí. Si se debe distinguir, entonces si se debe eliminar parte del objeto al eliminar el objeto completo, entonces es una relación de combinación; de lo contrario, puede ser una relación de agregación. Desde una perspectiva empresarial, si el objeto en su conjunto requiere la participación de algunos objetos para completar sus responsabilidades, entonces la relación entre los dos es una combinación; de lo contrario, es una relación de agregación.
Por ejemplo, automóviles y neumáticos, automóviles en su conjunto y neumáticos como piezas. Si se utiliza en un entorno empresarial de venta de automóviles usados, existe una relación de agregación entre los dos. Debido a que el neumático es una parte integral del automóvil, éste y el automóvil se pueden producir por separado y luego ensamblar y usar, pero el automóvil se puede reemplazar con neumáticos nuevos y los neumáticos también se pueden quitar para usarlos en otros automóviles. Si se utiliza en el entorno empresarial de sistemas de conducción, el automóvil no puede completar la tarea de conducción sin neumáticos y existe una relación combinada entre los dos. Otro ejemplo es la relación entre pedidos y artículos de pedido en el negocio de las librerías en línea: si el pedido no tiene un artículo de pedido, el negocio de pedidos no se puede completar, por lo que la relación entre los dos es una combinación. En cuanto a la relación entre el carrito de compras y el producto, debido a que el ciclo de vida del producto no está controlado por el carrito de compras y el producto puede ser compartido por varios carritos de compras, existe una relación de agregación entre los dos.