Como ya viste UML significa Unified Modeling Language el cual es un lenguaje estándar de modelado de sistemas orientados a objetos.
Esto significa que tendremos una manera gráfica de representar una situación, justo como hemos venido viendo. A continuación te voy a presentar los elementos que puedes utilizar para hacer estas representaciones.
Las clases se representan así:
En la parte superior se colocan los atributos o propiedades, y debajo las operaciones de la clase. Notarás que el primer caracter con el que empiezan es un símbolo. Este denotará la visibilidad del atributo o método, esto es un término que tiene que ver con Encapsulamiento y veremos más adelante a detalle.
Estos son los niveles de visibilidad que puedes tener:
- private + public # protected ~ default
Una forma de representar las relaciones que tendrá un elemento con otro es a través de las flechas en UML, y aquí tenemos varios tipos, estos son los más comunes:
Asociación
Como su nombre lo dice, notarás que cada vez que esté referenciada este tipo de flecha significará que ese elemento contiene al otro en su definición. La flecha apuntará hacia la dependencia.
Con esto vemos que la ClaseA está asociada y depende de la ClaseB.
Herencia
Siempre que veamos este tipo de flecha se estará expresando la herencia.
La dirección de la flecha irá desde el hijo hasta el padre.
Con esto vemos que la ClaseB hereda de la ClaseA
Agregación
Este se parece a la asociación en que un elemento dependerá del otro, pero en este caso será: Un elemento dependerá de muchos otros. Aquí tomamos como referencia la multiplicidad del elemento. Lo que comúnmente conocerías en Bases de Datos como Relaciones uno a muchos.
Con esto decimos que la ClaseA contiene varios elementos de la ClaseB. Estos últimos son comúnmente representados con listas o colecciones de datos.
Composición
Este es similar al anterior solo que su relación es totalmente compenetrada de tal modo que conceptualmente una de estas clases no podría vivir si no existiera la otra.
Con esto terminamos nuestro primer módulo. Vamos al siguiente para entender cómo podemos hacer un análisis y utilizar estos elementos para construir nuestro diagrama de clases de Uber.
La Agregación y Composición no me habían quedado claros, así que busqué y encontré este diagrama que me resultó muy útil:
En la composición, el elemento Tree depende completamente del elemento Leaf, siendo el caso de que si el elemento Leaf desapareciera también lo haría el elemento Tree.
Mientras que en la agregación si el elemento Book desaparece, o se vuelve 0, (esto me imagino que lo explicarán más adelante) el elemento Book Shop no lo haría.
(Para futuras clases) Hice un diagrama UML integrando las propiedades de cada clase, si identifican un error por favor comenta. Les dejo el template y el sitio donde pueden crear el suyo y añadir nuevas clases, propiedades y comportamientos. -Template -Sitio para editar template (select open existing diagram)
Muy fácil encontré algunas cosas mas en Internet pero no se si apliquen :c tal vez es por la versión o algo pero si algo me despejan la duda aquí lo dejo
Se que en ocasiones no se puede profundizar de todo en un tema, pero encontré este libro que me parece puede ser de utilidad al no sobre simplificar, pero tampoco excede en profundidad.
Si ya tomaron el curso de fundamentos de base de datos es un poco más fácil entrar al UML, ya que guarda relación con los diagramas físicos que se realizan al darle forma a una base de datos.
Después de profundizar el tema y hacer apuntes un tema que se expuso de manera rapida tiene una amplia connotación, hubiera sido bueno de disponer de material adicional y no verlo de forma superficial, saludos.
IMPORTANTE Aplicar UML al momento de programar, es como tomar en cuenta los pasos que vas a seguir antes de caer en el codigo y que flujo y utildiad va a tener el proyecto, en vez de pasar al codigo directamente entre prueba y error.
Sé que a veces la teoría suele no importarnos mucho cuando iniciamos a programar, pero ya llevo un año programando y veo que hoy en día tiene un gran valor, recomiendo que cuando tengan tiempo revisen la historia de como surgió y los demás símbolos.
nose por que mi cerebro quisiera que la dirección de las flechas fuera alrevez, ejem, el padre apunte al hijo. pero pondré un NOT a toda las direcciones de las flechas y listo hahaha
Este tema me recuerda a los diagramas de flujo, no se que tan relacionados estén pero me llena de nostalgia recordarlos y poder aprender más de otro tipo de diagramas 😄
Y pensar que cuando tome estas clases en la escuela casi no le poníamos atención, lo tomábamos como que era para rellenar el temario de la materia y que en la practica no se utilizaba. Pero pues tampoco nos explicaban en que lo íbamos a utilizar a la hora de trabajar como desarrollador y que seria una distinción entre un junior a un senior; Tal vez le hubiera puesto la misma atención que la diagramación en base de datos jeje
Saludos comunidad.
El análisis de objetos aún me cuesta mucho. Sus comentarios al respecto me ayudan mucho. Gracias
Para mí el proceso es el siguiente:
Un perro es rescatado y llevado a un centro de adopción.
Una persona interesada solicita hacerse cargo del perro.
El centro evalúa la solicitud y determina si la persona cumple con los requisitos.
Si el paso anterior es + se culmina el proceso y se entrega el perro a su nuevo amo.
De este análisis obtuve 4 objetos:
Perro
Adoptante
Oficina (sede del centro de adopción)
La adopción
Mi diagrama UML es el siguiente:
Las clases se representan de la siguiente manera:
.
.
Que contienen clases(titulo), atributos(propiedades), métodos(funciones) y relaciones.
. La visibilidad: Define la accebilidad para ese atributo o método que se definen de la siguiente manera:
.
Privado (-): Cada método o atributo son privados, ninguna clase o subclase puede acceder a ellos.
.
Público (+): Cada método o atributo son públicos, y cualquier clase o subclase puede acceder a ellos.
.
Protegido (#): Solo la misma clase o subclase pueden acceder a ellos
.
Paquete/defecto (~): Define la visibilidad del paquete o por defecto lo que significa y que puede ser usada por un paquete.
.
. Relaciones
.
Abstracción: Las clases abstractas van escritas en cursiva y es un concepto o una idea que no está asociado a ningún caso concreto.
.
Herencia: La dirección de la flecha irá desde el hijo hasta el padre, que indica que el hijo hereda los atributos y métodos de la super clase convirtiéndolos en subclases o clase derivada. Su representación es la siguiente:
.
.
Asociación: Es una relación de tipo básica que son independientes una de la otra y se usa para denotar que una clase se correlaciona en algún momento con otra clase. Su representación es la siguiente:
.
![Untitled (2).png]
.
Agregación: Especifica un todo y sus partes, donde un elemento dependerá de muchos otros. Aquí se toma como referencia la multiplicidad del elemento. Lo que comúnmente se conoce como Bases de Datos de Relaciones uno a muchos. Su representación es la siguiente:
.
.
Composición: Es una relación en la cuál no puede depender sin el todo, es decir, cuando un objeto determinado no podría existir sin su componente principal. Su representación es la siguiente:
.
.
Multiplicidad: Permite definir sus restricciones numéricas en las relaciones.
. Ejemplo:
.
.
El resumen fue hecho gracias a este video, por si gustan verlo que es bastante entretenido.
.
Espero haya sido útil este contenido. 💚🚀
Asociación: Dependencia
Herencia: La dirección de la flecha irá desde el hijo hasta el padre
Agregación: Un elemento dependerá de muchos otros. Aquí tomamos como referencia la multiplicidad del elemento
Composición: Este es similar al anterior solo que su relación es totalmente compenetrada de tal modo que conceptualmente una de estas clases no podría vivir si no existiera la otra.
recien lo noto yo no se si alguien mas aca no lo sabia pero si le das print al texto que esta aca a tu mano izq (si estas en computadora ) te guardas el archivo como pdf y pues te ahorras la apuntadera que es un caos.
Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. … Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario.
este tema es abordado de forma muy general pero la profe lo coloca como el primer paso para abordar la POO, así las cosas se debería plantear otra estrategia de pedagogía para estos casos
Hola tengo una pregunta la profe en vídeo anterior ah esta lectura que si quisiéramos aprender mas sobre este tema investigara mas ingeniera de software aqui en plazti ahi curso o una carrera sobre eso tema de ingeniera de software?
Interesante en la universidad no le puse tanta atención, estoy viendo la necesidad de dar orden y fijar un norte para así ser mas eficiente en el desarrollo
La herencia es específica de la programación orientada a objetos, donde una clase nueva se crea a partir de una clase existente. La herencia (a la que habitualmente se denomina subclase) proviene del hecho de que la subclase (la nueva clase creada) contiene las atributos y métodos de la clase primaria. La principal ventaja de la herencia es la capacidad para definir atributos y métodos nuevos para la subclase, que luego se aplican a los atributos y métodos heredados.
Para hacer representaciones UML se deben usar ciertos símbolos y convenciones para que la traducción del problema a sus soluciones sea fácilmente entendida…
Se usa un recuadro dividido para representar a las CLASES. en la parte superior va el nombre de la clase. En el siguiente nivel se colocan los atributos (los atributos son precedidos por los siguientes signos: - private, +public, # protected, ~default).
Se definen como relaciones: Asociación (flecha), herencia (flecha), agregación (línea y rombo), composición (línea y rombo).
¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.