¿Qué es un diagrama de clase?
Supongamos que tiene que diseñar un sistema. Antes de implementar un montón de clases, querrás tener una comprensión conceptual del sistema, es decir, ¿qué clases necesito? ¿Qué funcionalidad e información tendrán estas clases? ¿Cómo interactúan entre ellos? ¿Quién puede ver estas clases? Y así.
Ahí es donde entran los diagramas de clase. Los diagramas de clase son una forma ordenada de visualizar las clases en su sistema antes de comenzar a codificarlas. Son una representación estática de la estructura de su sistema.
Este es un diagrama bastante simple. Sin embargo, a medida que su sistema escala y crece, se hace cada vez más difícil hacer un seguimiento de todas estas relaciones. Tener un diagrama preciso, organizado y directo para hacer eso por usted es esencial para el éxito de su sistema.
¿Por qué necesitamos diagramas de clases?
- Planificar y modelar con anticipación hace que la programación sea mucho más fácil.
- Además de eso, hacer cambios en los diagramas de clase es fácil, mientras que codificar diferentes funciones después del hecho es un poco molesto.
- Cuando alguien quiere construir una casa, no solo agarran un martillo y se ponen a trabajar. Deben tener un plan, un plan de diseño, para poder ANALIZAR y modificar su sistema.
- No necesita muchos conocimientos técnicos / específicos del idioma para comprenderlo.
Algunas cosas técnicas
Representación de clase en UML
Una clase se representa como una caja con 3 compartimentos. El superior contiene el nombre de la clase. El del medio contiene los atributos de la clase y el último contiene los métodos de la clase. Me gusta esto:
Se adhieren a la siguiente convención:
nombre de atributo: tipo
nombre del método (parámetro: tipo)
- si desea establecer un valor predeterminado para un atributo, haga lo mismo que el saldo anterior: dólares = 0
- Si un método no toma ningún parámetro, deje los paréntesis vacíos. Ej: checkBalance ()
Visibilidad de los miembros de la clase
Los miembros de la clase (atributos y métodos) tienen asignada una visibilidad específica. Consulte la tabla a continuación para ver cómo representarlos en UML.
Especifiquemos la visibilidad de los miembros de la clase BankAccount anterior.
Hicimos que el “propietario” y el saldo fueran privados, así como el método de retiro . Pero mantuvimos el método de depósito público. (Cualquiera puede poner dinero, pero no todos pueden sacar dinero. Como a nosotros nos gusta).
Relaciones
Asociación
Una relación entre dos clases separadas. Se une a dos entidades completamente separadas. Existen 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.
Esto se puede especificar usando multiplicidad (uno a uno, uno a muchos, muchos a muchos, etc.).
Una implementación típica en Java es mediante el uso de un campo de instancia. La relación puede ser bidireccional con cada clase sosteniendo una referencia a la otra.
Herencia
indica que el niño (subclase) se considera una forma especializada del padre (superclase). Por ejemplo, considere lo siguiente:
Arriba tenemos una clase de padres animales con todos los campos de miembros públicos. Puede ver las flechas que se originan en las clases de pato, pez y cebra que indican que heredan todos los miembros de la clase de animales. No solo eso, sino que también implementan sus propios campos de miembros únicos. Puede ver que la clase de pato tiene un método swim () y un método quack ().
Realización / Implementación
Una relación entre dos elementos modelo, en la que un elemento modelo implementa / ejecuta el comportamiento que especifica el otro elemento modelo.
Dependencia
Agregación
Una forma especial de asociación que es una relación unidireccional (también conocida como unidireccional) entre clases. La mejor manera de entender esta relación es llamarla una relación “tiene una” o “es parte de”. Por ejemplo, considere las dos clases: Monedero y Dinero. Una billetera “tiene” dinero. Pero el dinero no necesariamente necesita tener una billetera, por lo que es una relación unidireccional.
Composición
Una forma restringida de agregación en la que dos entidades (o puede decir clases) son altamente dependientes entre sí.
Un humano necesita un corazón para vivir y un corazón necesita un cuerpo humano para funcionar. En otras palabras, cuando las clases (entidades) dependen unas de otras y su vida útil es la misma (si una muere, entonces otra también), entonces es una composición.
Multiplicidad
después de especificar específicamente el tipo de relación de asociación conectando las clases, también puede declarar la cardinalidad entre las entidades asociadas. Por ejemplo:
El diagrama UML anterior muestra que una casa tiene exactamente una cocina, exactamente un baño, al menos un dormitorio (puede tener muchos), exactamente un buzón y, como máximo, una hipoteca (cero o una).
