UML para los más pequeños: diagrama de clases





¡Ave, codificador! Un diagrama de clases UML ilustra la estructura de un sistema, describiendo clases, sus atributos, métodos y relaciones entre objetos.



Incluso los niños más pequeños saben que UML proviene del Lenguaje de modelado unificado, si en ruso, entonces, un lenguaje de modelado unificado, que, como dice la leyenda, se desarrolló cuando tíos y tías serios finalmente se cansaron de nadar en una variedad de círculos, rayas y nubes.



Para aquellos que son demasiado perezosos para leer:



El personaje principal







Primero, recordemos qué es una clase. En pocas palabras, una clase es una plantilla para crear objetos que proporciona valores de estado inicial: inicialización de campos variables e implementación del comportamiento de campos y métodos.



Esencialmente, una clase describe lo que puede ser un objeto.







Una clase representa un concepto que describe el estado (atributos) y el comportamiento (métodos). Cada atributo tiene su propio tipo, cada método tiene su propia firma, pero en el diagrama de clases solo se requiere que se complete la información del nombre de la clase, lo cual es lógico: incluso los mejores psíquicos del mundo no podrán entender qué es este cuadrado sin nombre y a qué se refiere generalmente.



El nombre de la clase se escribe en la división superior, seguido de los atributos de la clase, cuyos tipos se escriben después de los dos puntos, y finalmente, en la división inferior, hay métodos.



El tipo que puede devolver un método se escribe después de los dos puntos al final de la firma del método. Los modificadores de alcance se muestran delante de los atributos y métodos de la clase.







Cada parámetro de un método también puede tener una descripción de la dirección del método: in, out, inout.

En esta ilustración, el método1 usa p1 como entrada y el método usa de alguna manera el valor de p1, y el método no cambia p1.



El método 2 toma p2 como parámetro de E / S, el método usa de alguna manera el valor p2 y toma la salida del método, pero el método en sí también puede cambiar p2.



Method3 usa p3 como un parámetro de salida, en otras palabras, el parámetro sirve como un repositorio para el valor de salida del método.



Perspectivas sobre los diagramas de clases en el ciclo de vida del desarrollo de software



Podemos usar diagramas de clases en diferentes etapas del ciclo de vida del desarrollo de software y, por lo general, modelar diagramas de clases gradualmente desde tres perspectivas diferentes a medida que avanzamos en los niveles de detalle.







La perspectiva conceptual es cuando los diagramas se interpretan como una descripción de cosas en el mundo real. Así, si tomamos una perspectiva conceptual, dibujamos un diagrama que representa los conceptos en el área de estudio. Estos conceptos están relacionados con las clases que los implementan. La perspectiva conceptual se considera independiente del lenguaje.







Una perspectiva de especificación es cuando los diagramas se interpretan como una descripción de abstracciones de software o componentes con especificaciones e interfaces, pero no vinculados a una implementación específica.







Una perspectiva de implementación es cuando los diagramas se interpretan como una descripción de implementaciones de software en una tecnología y un lenguaje en particular.

Por lo tanto, si toma una perspectiva de implementación, está considerando la implementación de software.



Tipos de relaciones



A continuación, presentaré seis tipos principales de notación de relaciones de clase que son más comunes en los diagramas UML.



Asociación.





Al igual que los enlaces que conectan objetos, las asociaciones enlazan clases. Para que los objetos estén conectados, debe haber una asociación entre ellos.



Si asumimos que tenemos dos clases que interactúan entre sí, se debe trazar una línea de conexión continua entre ellas, indicando la asociación en el diagrama. A menudo también podemos ver un verbo que transmite su significado.



Además, también podemos especificar la multiplicidad, es decir, el número de objetos que pueden participar en la relación. La multiplicidad se especifica como una lista de intervalos separados por comas, en la que cada intervalo se representa como un mínimo-máximo.



Por ejemplo, un estudiante puede aprender de muchos profesores.

Pero un maestro puede enseñar a muchos estudiantes.



Herencia







O a veces también se le llama - generalización.



Como sugiere el nombre, esta es una representación esquemática de la relación entre una clase padre y sus descendientes. La flecha hueca siempre apunta hacia la clase principal.

Un ejemplo clásico de herencia: las clases cuadrado, rectángulo y círculo, que heredan de la clase de figura principal.



Tenemos derecho a representar la herencia tanto por separado para cada clase como a combinarlos.

Si la herencia proviene de una clase abstracta, entonces el nombre de dicha clase padre se escribe en cursiva.



Implementación







Por lo general, esto significa la relación entre una interfaz y los objetos que implementan esta interfaz.



Por ejemplo, la interfaz del propietario tiene métodos para comprar y vender propiedad privada, y la relación de las clases Persona y Corporación que implementan esta interfaz se indicará en el diagrama mediante una línea discontinua con una flecha que apunta hacia la interfaz.



Dependencia Un







objeto de una clase puede utilizar un objeto de otra clase en su método.

Si el objeto no se almacena en el campo de clase, este tipo de relación entre clases se modela como una dependencia.



La dependencia es, de hecho, un caso especial de asociación de dos clases, en este caso, los cambios en una clase conllevarán inexorablemente cambios en la otra.



Por ejemplo, la clase Person tiene un método hasRead con el parámetro de entrada book, que devuelve verdadero si, por ejemplo, la persona ha leído un libro.



Una dependencia se indica mediante una línea discontinua con una flecha que apunta a la clase de la que dependen, por ejemplo, los métodos de otra clase.



Agregación







Un tipo especial de relación entre clases donde una clase es parte de otra.



Por ejemplo, el lugar de trabajo de un programador consta de una silla, una mesa, una computadora y un ventilador, pero si se elimina la clase "lugar de trabajo", simplemente tendremos todas estas clases, solo por separado.



La agregación se muestra como una línea continua con un diamante hueco dirigido desde las clases que forman parte de una clase a una clase de agregación.



Composición







De hecho, una especie de agregación, solo en este caso, las clases que forman parte de otra clase se destruyen cuando se destruye la clase del agregador.



Por ejemplo, nuestro cuerpo está formado por órganos, pero por sí mismos no son viables.



La composición se indica de forma similar a la agregación, pero esta vez el diamante está completamente relleno.



Finalchka



El UML puede ser muy útil para los principiantes que se encuentran en la etapa de comprender "qué debe ir de dónde y de qué heredado". Como dicen nuestros colegas de habla inglesa: “ayuda ver cómo se ve todo el bosque detrás de los troncos de los árboles”.



Por lo tanto, antes de comenzar su proyecto, aunque pequeño, pero sorprendente, no tome el código de inmediato. Primero, diseñe la arquitectura de su aplicación en UML.



¡Cra!



All Articles